Virtualisierung der Server

Hallo,

für einen Kunden steht die Umstellung vom Windows2000 an der bisher als Datenserver genutzt wurde. Dieser soll gegen einen Windows 2008 R2 mit Virtualisierung ersetzt werden. Auf diesem System soll der DatenServer, der WTS und der KommServer virtualisiert werden.

Gibt es Erfahrungen bezüglich des Raid-Arrays ob es besser ist das System auf unterschiedliche Raid1 zu legen:

System = eignens Raid1, Datenserver und Kommserver = eigenes Raid1, WTS = eigenes Raid1

Oder macht es Sinn den Datenserver, Kommserver und den WTS auf ein schnelles Raid10 legen kann?

System = eignens Raid1, Datenserver, Kommserver und WTS = eigenes Raid10

Gibt es bei dem Raid1 oder Raid10 performance Vorteile wenn man die Partitionen entsprechend wählt?

Danke,
MfG
Rainer Niembs

Ich vermute Du willst MS HyperV als Hypervisor benutzen. Da würde ich ein einziges RAID Array einrichten.
Speed bringt dir das RAID10. Wobei aktuelle RAID-Controller und Platten auch super Performant sind mit RAID5 oder RAID6.

Hallo,

ich wollte mal meine Erfahrungen mit dem Hyper-V Server auf Basis von Windows 2008 R2 sprechen. Für das Basisystem wurde ein Raid1 benutzt und für den FileServer, TerminalServer und KommServer war ein Raid10 angedacht. Beim testen des ganzen hatte sich herausgestellt das die Performance von Datev Pro grotten schlecht war auf dem Raid10. Wir haben dann umgestellt und haben aus dem Raid10 zwei Raid1 gemacht und den FileServer und den TerminalServer getrennt auf den beiden Raid1 abgelegt. Der KommSerer wurde auf das Raid1 gelegt wo auch der TerminalServer liegt. Die Performance ist etwas besser geworden, aber von einem "zügigen Arbeiten" kann nicht die Rede sein.

Mir stellt sich die Frage ob Datev Pro allgemein so langsam und zäh ist oder ob hier wirklich die Platten zu langsam sind. Dann bleibt eigentlich nur auf SSDs auszuweisen was mit erheblichen Kosten verbunden wäre.

Evtl. hat noch jemand Erfahrungen mit Virtualisierung von Datev Pro und ein paar Tipps...

die Performance von Datev Pro grotten schlecht

Start ArbeitsplatzPro: 48 Sekunden
2. Aufruf: 31 Sekunden
ReWePro: Erste Jahresabschlußbuchung möglich: Weiter 53 Sekunden
Stammdaten 1. Aufruf: 12 Sekunden
Stammdaten 2. Aufruf: 4 Sekunden

Welche Hardware nutzen Sie?

z.B.
MS Windows 7 64-bit SP1
Intel Core 2 Quad Q8200 @ 2.33GHzie
8.0GB Dual-Kanal DDR2 @ 398MHz (6-6-6-18)

@Herr Wolf,

die User der Praxis melden mir dass das Verhalten von Datev Pro sehr träge ist im Vergleich zum Datev in der Version 23! Da ich nicht selber mit Datev arbeite kann ich das nicht beurteilen.

Die Hardware des Virtualisierungsservers ist:
Windows Server 2008 R2 SP1
AMD Phenom II X6 1055T 125W, 6x 2.80GHz
16GB PC3-10667U CL7-7-7-21
6x 1TB SATA 7200rpm (3x Raid1)
Auf dem Virtualisierungsserver laufen 3 Systeme:
Windows Server 2008 R2 SP1 -> Fileserver
Windows XP SP3 -> KommServer
Windows 2003 Server SP3 -> Terminalserver

In der Kanzlei arbeiten insgesamt 5 User

Start Arbeitsplatz Pro: ca. 65 Sekunden
2. Aufruf: ca 45 Sekunden
DokOrg: ca 19 Sekunden
Posten, Fristen und Entsch: ca. 14 Sekunden

Hallo Herr Niembs,

grundsätzlich ist von SATA-Festplatten in Ihrem Umfeld, auch wenn es sich nur um 5 User handelt, abzuraten.
Weitere Punkte:
2008R2 SP1 ist von Datev noch nicht freigegeben.
Für den Fileserver würde ich alleine schon 16GB reservieren.
Ist der Host als "normales" OS installiert und laufen dort noch andere Dienste?
Welcher RAID-Controller wird eingesetzt? Mit BBU?

@SystemAdmin,

mir ist durchaus bewusst das wenn ich hier 6x SAS Platten mit einem TOP-Raid-Controller einbaue, dazu noch am Besten 64 GB Speicher und noch ein schönes hochperformantes NAS das dann auch Datev Pro "vernünftig" läuft.

Jetzt stellt sich mir nur die Frage ob es Sinn und Zweck ist den Mehraufwand von ca. 10TSD Euro einzusetzten um 5 User die mit Datev Pro arbeiten zufrieden zu stellen. Vorher war doch auch annehmbares Arbeiten möglich und da wurde deutlich schlechtere Hardware eingesetzt.

Zur Info, der FileServer läuft mit Dynamic-Memory auf dem Hyper-V Server und zieht nichtmal 4GB Speicher! Also warum 16GB dafür "verschwenden"? Da Raid1 wird ein ganz normaler Controller von Promise ohne BBU eingesetzt! Auf dem Host laufen keine weiteren Dienste!

> die User der Praxis melden mir dass das Verhalten von Datev Pro sehr träge ist im Vergleich
> zum Datev in der Version 23! Da ich nicht selber mit Datev arbeite kann ich das nicht beurteilen.

Sie nutzen hoffentlich Gigabit- LAN, da sehr viel Grafische Elemente übertragen werden.

> Die Hardware des Virtualisierungsservers ist:
> Windows Server 2008 R2 SP1

Wird in den nächsten Tagen freigegeben.
(Bei mir macht das SP1 auf dem lokalen Arbeitsplatz keinerlei Probleme.)

> AMD Phenom II X6 1055T 125W, 6x 2.80GHz

für 5 Arbeitsplätze sollte das reichen.

> 16GB PC3-10667U CL7-7-7-21

Zumindest für 1* flott ArbeitsplatzPro starten muß das reichen.

> 6x 1TB SATA 7200rpm (3x Raid1)

Auf dem Windvsw1- Laufwerk verwaltet DATEV unendlich viele Kleinstdateien.
Hier muß eine Schnelle Platte her. WD- Raptoren oder SSD- Platten für kürzeste
Zugriffe.
Die DATEV- Installation hat möglicherweise den Cache komplett deaktiviert.

Zusätzlich legt der SQL- Server auf seinem Homeverzeichnis C:\ seine temporären
Daten ab, so daß auch hier höchste Performance gut wäre.

> Auf dem Virtualisierungsserver laufen 3 Systeme:
> Windows Server 2008 R2 SP1 -> Fileserver
> Windows XP SP3 -> KommServer
> Windows 2003 Server SP3 -> Terminalserver

Ist die Kommunikation performant und zu 100% korrekt konfiguriert

> In der Kanzlei arbeiten insgesamt 5 User

Folgende Messung sicherlich nur bei einem User:

> Start Arbeitsplatz Pro: ca. 65 Sekunden
> 2. Aufruf: ca 45 Sekunden
> DokOrg: ca 19 Sekunden
> Posten, Fristen und Entsch: ca. 14 Sekunden[/zitat]

Diese Zeiten sind typisch für einen Einzelarbeitsplatz, wenn Daten und System
auf der gleichen Festplatte liegen, und aus Sicherheitsgründen der Schreibcache
deaktiviert, aber die DATEV- Virenschutz- Software alles scannt.

Was sagt der Ressourcenmonitor (Taskmanager) betreffs der Antwortzeiten
der Datenträger?

-> die kritischen Dinge auf separate physikalische Datenträger.

@Herr Wolf,

danke für den Beitrag!

> 6x 1TB SATA 7200rpm (3x Raid1)

> Auf dem Windvsw1- Laufwerk verwaltet DATEV unendlich viele Kleinstdateien.
> Hier muß eine Schnelle Platte her. WD- Raptoren oder SSD- Platten für kürzeste
> Zugriffe.
> Die DATEV- Installation hat möglicherweise den Cache komplett deaktiviert.

> Zusätzlich legt der SQL- Server auf seinem Homeverzeichnis C:\ seine temporären
> Daten ab, so daß auch hier höchste Performance gut wäre."

Das wäre auch der nächste Schritt, allerdings bin ich mir über den Sicherheitsstand der aktuellen SSDs nicht ganz klar. Ich habe schon einige SSDs gesehen die nach kürzester Zeit ihren Geist aufgegeben haben und das ohne groß vorher etwaige Anstalten gemacht haben... Deshalb bin ich hier noch etwas vorsichtig.

> Ist die Kommunikation performant und zu 100% korrekt konfiguriert

Dadurch das sich alle User per RDP auf den Terminalserver einwählen arbeiten so zu sagen alle direkt auf dem System. Durch einen Virtuellen Switch sind die einzelnen Systeme mit 10GBit verbunden. Das Netzwerk stellt somit meiner Meinung nach keine Hürde da!

> Diese Zeiten sind typisch für einen Einzelarbeitsplatz, wenn Daten und System
> auf der gleichen Festplatte liegen, und aus Sicherheitsgründen der Schreibcache
> deaktiviert, aber die DATEV- Virenschutz- Software alles scannt.

> Was sagt der Ressourcenmonitor (Taskmanager) betreffs der Antwortzeiten
> der Datenträger?

Ja, der Virenscanner ist aktiv und Scannt im Hintergrund. System und Datenplatte sind ebenfalls auf einem Laufwerk. Die Antwortzeiten laut Taskmanager liegen in einem bereich von 0-20MS. Der Virtuelle IDE Controller erlaubt nicht die aktivierung des Schreibcaches.

Wenn ich jetzt das Raid1 auf dem der Fileserver läuft durch eine SSD austausche sollte das merklich Geschwindigkeit bringen, aber auf Kosten der Sicherheit.

Ja, der Virenscanner ist aktiv und Scannt im Hintergrund. System und Datenplatte sind ebenfalls auf einem Laufwerk. Die Antwortzeiten laut Taskmanager liegen in einem bereich von 0-20MS. Der Virtuelle IDE Controller erlaubt nicht die aktivierung des Schreibcaches.

Interessant, daß ausgerechnet das Swap- Laufwerk beim Öffnen der Stammdaten mehrere Sekunden auf knapp 100% Auslastung steht (8 GB bei 64 Bit, davon 6,81GB verwendet)

Hallo Herr Niembs,

haben Sie folgende Dokumente bearbeitet:

Laufzeit- oder Verbindungsprobleme bei der Kommunikation mit einem Windows Server 2003 oder Windows Server 2003 R2

Laufzeitverhalten - Performance -Verbesserungen von DATEV-Programmen

Mfg
Olaf Meyer

@Herr Meyer,

für die Grundinstallation Datev Version 23 hatte ich mich mit diesen Themen Beschäftigt und auch getestet. Müssen diese Tests mit jeder Datev Version erneut ausgeführt werden?

Ich habe nun nochmal das Laufzeitverhalten überprüft und den Virenscanner auf den Fileserver deaktiviert. Von der Laufzeit her gab es keine Probleme laut Tool! Der Patch wurde schon eingespielt!

Ich lasse nun nochmals testen und hoffe das es etwas gebracht hat!

So, mal zur Information, ich habe eben mal Tests mit einer SSD gemacht auf der ich jetzt mal abwechselnd den Fileserver und den Terminalserver gelegt habe.

Also beim Fileserver war die Ernüchterng sehr groß! Kaum eine Beschleunigung beim Starten von Datev Pro. Also ich dann den WTS auf die SSD konfiguriert habe war dann doch eine merkliche Beschleunigung auszumachen.

Jetzt frage ich mich nur gerade ob das sein kann... Eigentlich sollte doch der Fileserver von einer SSD profitieren können und somit die Beschleunigung schneller sein...

Allerdings habe ich jetzt auch noch keine großen Datenbankanwendungen gestartet!

Hallo Herr Niembs.

Welche Daten liegen denn auf Ihrem Fileserver? Wenn Ihrer etwa so genutzt wie meiner würde ich genau den von Ihnen beobachteten Effekt erwarten: So gut wie keinen.

Die zu startenden Programme liegen auf dem Terminalserver. Bis zur ersten Anfrage von Nutzdaten (also die Zeit die Sie warten müssen bis Sie im Programm auf "Datei/Öffnen" klicken können) ist der File- und Datenbankserver annähernd unbeteiligt (wenn man von Kleinigkeiten wie der kurzen Anfrage an den LiMa absieht). Die "gefühlte Reaktionszeit" dürfte deshalb vom Fileserver unabhängig sein.

Evtl. lässt sich die Benutzeranmeldung am WTS verkürzen, wenn sie Roaming Profiles auf dem Fileserver liegen haben. Auf der anderen Seite würde ich hier aber eher davon ausgehen, dass die Netzwerkverbindung zwischen WTS und Fileserver der Flaschenhals beim Anmeldevorgang ist. Wenn dann die Roaming Profiles auf dem Fileserver die großen Verzeichnisse (Desktop, Eigene Dateien, Anwendungsdaten) nicht innerhalb der Profile tragen sondern diese direkt auf den Netzwerkshare verlinken (was bewirkt dass beim Anmeldevorgang nicht das gesamte große Benutzerprofil vom Fileserver anf den WTS kopiert wird sondern nur ein geringer Teil davon) dürfte sich der Einfluss der Festplatte des Fileserver auf die Zeit der Benutzeranmeldung am WTS sogar von "sehr gering" auf "nicht spürbar" reduzieren.

Am Fileserver habe ich eigentlich nie nennenswerte Festplattennutzung, eben weil die Anwendungsprogramme ohnehin auf dem Terminalserver liegen. Die Daten des Datenbankservers hat dieser im Idealfall ohnehin im Arbeitsspeicher. Natürlich geht das bei so einzigen GB Nutzdaten nur in Grenzen, aber gegen Engpässe in er Datenbank hilft mehr RAM häufig besser als schnellere Festplatten. Jedenfalls in den Dimensionen von DATEV-Anwendungen mit fünf zugreifenden Mitarbeitern. Ega wie viel RAM ich dem Datenbankserver geben, verwenden kann der den immer.

Dass die SSD am WTS diesen spürbar flüssiger macht würde ich ebenfalls genau so erwarten. Wie gesagt, da liegen die Programme die Sie starten und damit die Dateien die Sie anfassen -- und das vermutlich im Regelfall bei jedem Programmstart erneut.

Wie das Herr Wolf schon angedeutet hat: Die SSD würde ich Ihnen als Cache der Datenbank empfehlen. Ob Sie davon so viele anschaffen wollen das die komplette Datenbank dort Platz hat (heißt zwei Stück davon im RAID1 am Controller) oder die SSDs eher klein wählen und wirklich nur den Datenbankcache dorthin auslagern kann ich nicht weiter beurteilen. Das hängt hauptsächlich davon ab, wie viel der Datenbank der Server laden, im RAM halten und ggf. in den Cache legen möchte, bzw. welchen Anteil der Daten der Server im Gegenzug häufiger von der Festplatte liest.

Stellen Sie gerade in einem Zug von Echtblech auf Virtualisierung und von Pre-Pro auf Pro um? Mich würde bei identischer Hardware interessieren, ob die Nicht-Pro-Variante bei Ihnen ein ähnlich wenig zufriedenstellendes Bild abgibt. Ich kann Ihnen nämlich nur Nicht-Pro-Erfahrungen gepaart mit allgemeinem Wissen über WTS, Datenbank und Virtualisierung in Nicht-Datev-Umgebungen bieten.

Weiterhin muss ich sagen, dass ich mich ausschließlich mit VMware auskenne, nicht mit Hyper-V.

Auf einem ESX würde ich Ihnen empfehlen, im Betrieb alle verfügbaren Leistungsdaten zu vergleichen. Ob die VMs gerade auf "IO-Wait" stehen (heißt so viel wie: Die Festplatte tut was und die CPU wartet darauf), der Host gerade die VMs swapt (in Summe mehr RAM-Zuteilung an die VMs als RAM zur Verfügung steht, keine gute Idee weil dann die Festplatte als RAM-Erstaz herhalten muss), die VMs selbst swappen (den VMs zu wenig RAM zugewiesen, auch keine gute Idee, aus dem gleichen Grund nur auf einem anderen Level in der Virtualisierung), die CPU gerae auf Anschlag steht (die Gründe sind vielfältig), all das wären Faktoren die ich prüfen und ggf. überarbeiten würde.

Ich habe gelesen, dass Sie einen RAID-Controller ohne BBU betreiben. Das sollten Sie so schnell wie möglich ändern. Langfristig wollen Sie ein System nicht auf einer nicht-redundanten Platte betreiben, da sind wir uns sicherlich einig. Heißt langfristig muss die SSD auch mindestens durch eine zweite im RAID1 realisiert sein.
Die BBU hat einen recht relevanten Effekt: Ohne BBU läuft der Controller mit Sicherheit mit Write-Through, mit BBU dageen mit Write-Back. Grob kann man sagen, dass Write-Through dem Betriebssystem erst den Erfolg einer Schreiboperation positiv beantwortet, wenn die Daten auf der Festplatte gelandet sind. Beim Write-Back antwortet der Controller, sobald er sich sicher ist dass die zu schreibenden Daten im internen Cache des Controllers angelangt sind. Ohne BBU wird bei Schreibvorgängen der Cache des Controllers praktisch ignoriert.
Dazu kommt, dass einige Controller im RAID-Betrieb die Festplatte anweisen, sogar den festplatteninternen Cache nicht zu verwenden. Nur dadurch ist sichergestellt, dass die Festplatten nach einem Systemausfall auch wirklich den im RAID gewünschten Zustand haben.

Hier liegt übrigens ein gewaltiger Nachteil so gut wie aller SATA-SSDs: Der RAID-Controller sendet zwar den SSDs die Anweisung, auf keinen Fall den internen Puffer zu verwenden, die SSD behauptet auch das zu tun. Trotzdem wird er aber verwendet. Es gibt nur eine Hand voll (zwei oder drei, wenn ich mich recht entsinne) SSDs bei denen der interne Puffer wirklich wirksam deaktiviert werden kann.

Grüße,
Stephan Schuler.