Zur DATEV-Community

DATEV Community Archiv

Zurück zur Foren-Übersicht Zurück zum Forum

Virtualisierung der Server

ARCHIV

Sie befinden sich im Archiv der DATEV-Community

Die DATEV-Newsgroup wurde im November 2015 zur DATEV-Community. Diese Seiten sind ein Archiv der Beiträge aus der bisherigen DATEV-Newsgroup. Sie können hier nicht kommentieren oder neue Themen einstellen. Für neue Kommentare oder Beiträge melden Sie sich einfach in der DATEV-Community an.

zur DATEV-Community

    Einträge 1-15 / 31

    Seite 1 von 3

  • Rainer Niembs
    04.08.2010 10:27 Uhr

    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

  • Xaver Brunner
    12.08.2010 20:08 Uhr

    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.

  • Rainer Niembs
    28.02.2011 14:26 Uhr

    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...

  • Armin Wolf
    28.02.2011 15:03 Uhr
    Zitat von Rainer Niembs

    die Performance von Datev Pro grotten schlecht

    Können Sie das bitte konkretisieren.
    Was benötigt bei welchem Mausklick wie viele Sekunden zum Starten?
    z.B.

    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)

  • Rainer Niembs
    01.03.2011 12:48 Uhr

    @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

  • System Administrator
    01.03.2011 14:01 Uhr

    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?

  • Rainer Niembs
    01.03.2011 15:42 Uhr

    @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!

  • Armin Wolf
    01.03.2011 16:03 Uhr

    > 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.

  • Rainer Niembs
    01.03.2011 16:34 Uhr

    @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.

  • Armin Wolf
    01.03.2011 19:13 Uhr
    Zitat von Rainer Niembs

    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.

    Auf meinem lokalen Rechner habe ich System, temp- Dateien und Daten auf 3 verschiedenen (langsamen) 1 TB- Platten. Daher pendelt die Zugriffszeit zwischen Null und 5 MS bei den relevanten Zugriffen.

    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)

  • Olaf Meyer
    01.03.2011 22:34 Uhr
  • Rainer Niembs
    02.03.2011 09:07 Uhr

    @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?

  • Rainer Niembs
    02.03.2011 09:51 Uhr

    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!

  • Rainer Niembs
    18.03.2011 21:48 Uhr

    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!

  • Stephan Schuler
    18.03.2011 22:56 Uhr

    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.