KingKompass 0 Geschrieben 9. Juni 2015 Autor Melden Teilen Geschrieben 9. Juni 2015 Virtuelle Festplatten nie partitionieren, sondern immer einzelne anlegen. Gruß, Nils Hallo, dann die Frage, lieber zwei VHDX Dateien, jeweils für C: und D: (OS und Daten) oder eine VHDX Datei und alles auf Laufwerk C: (OS und Daten) Danke und Gruß Michael Zitieren Link zu diesem Kommentar
NorbertFe 1.800 Geschrieben 9. Juni 2015 Melden Teilen Geschrieben 9. Juni 2015 Na wenn du vorher partitionieren wolltest, warum willst du es jetzt auf einmal in eine Partition werfen? Zitieren Link zu diesem Kommentar
KingKompass 0 Geschrieben 9. Juni 2015 Autor Melden Teilen Geschrieben 9. Juni 2015 Es gibt die Empfehlungen feste min und max Werte einem SQL Server zuzuweisen und den Max Wert etwas (mit etwas ist 4-8GB gemein) unter dem Verfügbaren Ram zu konfigurieren (damit das OS auch noch Ram zum arbeiten hat). Hallo, ich denke einen ähnlichen Denkansatz hatte der Datevmitarbeiter auch , ob das nun pauschal richtig ist, ist dann ja noch ein anderes Thema. Gruß Michael Na wenn du vorher partitionieren wolltest, warum willst du es jetzt auf einmal in eine Partition werfen? Hallo, sorry, dann habe ich mich wohl falsch ausgedrückt, ich war bzw bin für alles offen ;-) hatte aber bei meinen drei Varianten keinen direkten Favoriten. Moin, Virtuelle Festplatten nie partitionieren, sondern immer einzelne anlegen. Gruß, Nils Nach dem Statement von Nils fällt eine Option von meinen Dreien weg und daher die Frage, lieber zwei VHDX Dateien, jeweils für C: und D: (OS und Daten) oder eine VHDX Datei und alles auf Laufwerk C: (OS und Daten). Danke und Gruß Michael Zitieren Link zu diesem Kommentar
NilsK 2.785 Geschrieben 9. Juni 2015 Melden Teilen Geschrieben 9. Juni 2015 Moin, bei Servern dieser Art immer mehrere virtuelle Disks. Hier könnte auch eine Aufteilung in System, Logs und Datenbanken sinnvoll sein. Gruß, Nils Zitieren Link zu diesem Kommentar
NorbertFe 1.800 Geschrieben 9. Juni 2015 Melden Teilen Geschrieben 9. Juni 2015 Als Hinweis. Bei partitionierung verlierst du die Flexibilität mal eben jedes Volume und jede Partition vergrößern zu können. Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 10. Juni 2015 Melden Teilen Geschrieben 10. Juni 2015 Moin, beim SQL würde ich mich einfach an die Herstellervorgaben halten, egal ob es sinnvoll erscheint oder nicht. Das kann im Supportfall einige Diskussionen ersparen. Softwarehersteller machen häufig übertrieben anmutende Angaben. Da sie die individuellen Umgebungen der Kunden nicht kennen, haben sie in vielen Fällen auch keine andere Wahl. Natürlich kann man auch einen Consultant buchen, der ein genaues Sizing vornimmt. Der kostet aber meistens mehr als die paar GB RAM und ein oder zwei zusätzliche vCPU. Zitieren Link zu diesem Kommentar
Nobbyaushb 1.359 Geschrieben 10. Juni 2015 Melden Teilen Geschrieben 10. Juni 2015 Ich zu dem ganzen nur sagen, was Michael Korp mal auf einer Veranstaltung gesagt hat. Zitat: wenn man eine virtuelle Maschine genauso sized wie eine physische, hat man aus das richtige Ergebnis. Aus unserer Sicht (wir haben ca. 40 virtuelle Server in einem Hyper-V-Cluster) kann ich das bestätigen. Datev: wir haben unsere beiden Datev-Server virtualisiert mittels disk2vhd. Nach dem Umzug meinten die User, was wir denn gemacht hätten, die Datev-Umgebung wäre gefühlt doppelt so schnell. Just my 2 Cents... ;) Zitieren Link zu diesem Kommentar
NilsK 2.785 Geschrieben 10. Juni 2015 Melden Teilen Geschrieben 10. Juni 2015 Moin, beim SQL würde ich mich einfach an die Herstellervorgaben halten, egal ob es sinnvoll erscheint oder nicht. im Grundsatz schon - bei den hier genannten Dimensionen kommen aber schnell noch andere Faktoren hinzu. Einen 50-GB-Brocken etwa kann man in einem Cluster nur dann sinnvoll betreiben, wenn auf den anderen Nodes eben diese 50 GB auch frei bleiben, damit ein Failover funktionieren kann. Da ist man dann schnell bei etwas mehr als "ein paar GB zusätzlich" ... Gruß, Nils Zitieren Link zu diesem Kommentar
testperson 1.529 Geschrieben 10. Juni 2015 Melden Teilen Geschrieben 10. Juni 2015 Hi, ich finde das Sizing sehr sportlich. Hat DATEV sich das System mal angesehen bzw. war es auch die DATEV direkt oder ein Systempartner der DATEV? In diesem Bereich würde ich definitiv DMS vom Rest trennen, alleine wegen Backup bzw. eher Restore. Aber aus der ferne ist das alles sehr schwer zu beurteilen. Generell hat DATEV die ein oder andere "Besonderheit" und virtualisiert dann noch die ein oder andere "Besonderheit" mehr ;) Gruß Jan Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 10. Juni 2015 Melden Teilen Geschrieben 10. Juni 2015 Moin, im Grundsatz schon - bei den hier genannten Dimensionen kommen aber schnell noch andere Faktoren hinzu. Einen 50-GB-Brocken etwa kann man in einem Cluster nur dann sinnvoll betreiben, wenn auf den anderen Nodes eben diese 50 GB auch frei bleiben, damit ein Failover funktionieren kann. Da ist man dann schnell bei etwas mehr als "ein paar GB zusätzlich" ... Gruß, Nils Bei einem 50 GB SQL Server mache ich mir auch Gedanken über NUMA, Backup & Restore usw. Die Frage ist nur: Plane ich meine Infrastruktur nach den Anwendungen, wähle ich die Anwendungen anhand der Infrastruktur aus oder betreibe ich etwas dazwischen? Dabei geht es nicht um den Regelbetrieb, sondern den Störfall und ggf. resultierende Haftungsfragen. Zitieren Link zu diesem Kommentar
KingKompass 0 Geschrieben 10. Juni 2015 Autor Melden Teilen Geschrieben 10. Juni 2015 Moin, bei Servern dieser Art immer mehrere virtuelle Disks. Hier könnte auch eine Aufteilung in System, Logs und Datenbanken sinnvoll sein. Gruß, Nils Hallo, danke, dann werde ich System und Datenbanken in einer separaten VHDX unterbringen. Als Hinweis. Bei partitionierung verlierst du die Flexibilität mal eben jedes Volume und jede Partition vergrößern zu können. Hallo, der Hinweis ist richtig und wichtig , hatte ich auch auf dem Schirm, hätte mich aber davon abbringen lassen , wenn ich in dieser Konstellationen mit "zu viel" Performanceeinbußen im Vergleich zu den anderen beiden Varianten zu rechnen hätte. Danke ! Moin, beim SQL würde ich mich einfach an die Herstellervorgaben halten, egal ob es sinnvoll erscheint oder nicht. Das kann im Supportfall einige Diskussionen ersparen. Softwarehersteller machen häufig übertrieben anmutende Angaben. Da sie die individuellen Umgebungen der Kunden nicht kennen, haben sie in vielen Fällen auch keine andere Wahl. Natürlich kann man auch einen Consultant buchen, der ein genaues Sizing vornimmt. Der kostet aber meistens mehr als die paar GB RAM und ein oder zwei zusätzliche vCPU. Hallo, da sich die Herstellerangaben (Datev) mit euren Tipps und Empfehlungen größtenteils decken, werde ich es auch so machen. Danke ! Hi, ich finde das Sizing sehr sportlich. Hat DATEV sich das System mal angesehen bzw. war es auch die DATEV direkt oder ein Systempartner der DATEV? In diesem Bereich würde ich definitiv DMS vom Rest trennen, alleine wegen Backup bzw. eher Restore. Aber aus der ferne ist das alles sehr schwer zu beurteilen. Generell hat DATEV die ein oder andere "Besonderheit" und virtualisiert dann noch die ein oder andere "Besonderheit" mehr ;) Gruß Jan Hallo, ja, es war die Datev direkt und kein Systempartner. Ich denke der Datevmitarbeiter stützt sich auf das, was ich ihm per Mail geschrieben habe und eventuell zieht er die Informationen aus den übertragenen Servicetoolaufzeichnungen mit dazu, die stehen der Datev auch zur Verfügung, damit hätte er grobe Kenntnisse über die Hardwareausstattung fast aller Server. In wie fern meinst du denn, dass das Sizing sportlich ist ? Das mit der DMS Trennung steht noch aus , dazu wird noch ein betreuender Datev-Systempartner angesprochen der sich ausschließlich um das DMS System kümmert. Danke ! Gruß Michael Zitieren Link zu diesem Kommentar
Daniel -MSFT- 129 Geschrieben 21. Juni 2015 Melden Teilen Geschrieben 21. Juni 2015 (bearbeitet) Nochmal zum Einfluss der Grafikkarte auf die Performance. Auf dem Virtualisierungshost aktiviert man bloss nicht eine 3D-beschleunigte Grafikkarte. Also kein Aero. Das geht dann deutlich auf die Performance, wenn der Server kein Second-Level Address Translation (SLAT) kann. Für Client Hyper-V ist deswegen SLAT-Support der CPU zwingend erforderlich. AMD verwendet dafür die Bezeichnungen Rapid Virtualization Indexing (RVI) oder Nested Page Tables, Intel Extended Page Tables (EPT). bearbeitet 21. Juni 2015 von Daniel -MSFT- Zitieren Link zu diesem Kommentar
KingKompass 0 Geschrieben 3. September 2015 Autor Melden Teilen Geschrieben 3. September 2015 Hallo, ich hatte ja bereits geschrieben das ich ein Feedback geben werde, wenn die Umstellung (Serverumzug) durch ist. Letzten Freitag war es dann endlich soweit , hatten in einem ersten Anlauf noch Probleme mit dem Server-Anpassungsassistenten der Datev gehabt, dieser lief dann aber am Freitag fehlerfrei durch und das System wurde auf den neuen HyperV Host migriert. Nun habe ich aber ein extremes Performanceproblem bei den Datevanwendungen. Nach einigen Tests die Datev von Haus aus mitliefert (Laufzeitfaktorenmessung Servicetool, ...) bin ich auf das Tool "PingFile" der Datev gestoßen. Ursprünglich wird das Tool zum groben messen von Netzwerkverbindungen genutzt (50MB Pakete senden empfangen und dann die Zeit auswerten), wird aber auch empfohlen für die Fehlerdiagnose für Harddisk Performance. Referenzwerte der Datev: PC System: über 1000MBit/s Datevfileserver: über 3500MBit/s Der alte physikalische Server der Kanzlei hatte einen Wert von 2800MBit/s. Der neue Server (MS Server 2012R2) hatte im Mai 2015 vor der Installation der Hyper-V Rolle einen fabelhaften Wert von 13.181 MBit/s. Das resultiert wahrscheinlich aus den vier Intel Server SSDs (S3700) im Raid 10 Verbund. Nach der Installation der Hyper-V Rolle und dem Serverumzug ist diese Performance sowohl auf dem Host selbst , als auch in der VM auf einen sehr schlechten Wert von 1800 MBit/s eingebrochen. Der Intel Raidcontroller gibt keine Fehlermeldungen und auch die SSDs melden keine Smart oder sonstige Fehler, von daher kann ich mir die Einbußen nicht erklären. Auch das zweite Array im neuen Server zwei 100GB Intel S37000 SSDs im Raid 1 Verbund liefert das gleiche Ergebnis. Ich bin leider total ratlos und frustriert. Hardwareausstattung: 2x Intel Xeon E5-2623v3 Intel Raidcontroller RS25AB080 2x 100GB Intel S3700 SSD RAID 1 für den Host 4x 400GB Intel S3700 SSD RAID 10 für die VMs 64GB RAM Hyper-V 2012R2 VM1 => DC , fixed Disk VHDX, 1vCPU , 4GB RAM VM2 => Datevserrver, fixed Disk , 6vCPU , 50 GB RAM Das einzige was ich gefunden habe um das Problem zu fassen wäre ein fehlerhaftes Allignment oder Blocksize der SSDs in Bezug auf die VMs. Leider stecke ich da nicht so wirklich drin im Thema und bräuchte eure Hilfe, falls es das Problem sein sollte. Die SSDs haben laut Raidcontroller eine Logical Sector Size von 512B und eine Physikal Sector Size von 4KB und gelten damit als 512e Laufwerke. Angeblich kann es genau in dieser Konstellation , besonders beim Einsatz von SSDs (512e), Probleme mit der Performance geben , Stichwort RMW (read-modify-write) . Vielen Dank schon einmal im voraus für jeden hilfreichen TIPP oder Ansatz der zu Lösung meines Problems führt ! Gruß Michael Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 3. September 2015 Melden Teilen Geschrieben 3. September 2015 Dem Dateiserver gibt Du mal nur 2 vCPU, auf keinen Fall 6. Deine Xeons haben nur 4 Cores. Damit bringst Du NUMA durcheinander. 2 vCPU sollten für einen Fileserver reichen. Ich hoffe mal, dass in der Parent Partition nicht (absolut nichts) anderes als Hype-V läuft. Zitieren Link zu diesem Kommentar
NilsK 2.785 Geschrieben 3. September 2015 Melden Teilen Geschrieben 3. September 2015 Moin, möglicherweise liegt hier ein VMQ-Problem vor. Prüfe mal mit der PowerShell auf dem Host die VMQ-Konfiguration: Get-NetAdapterVmq Steht irgendwo bei "Enabled" die Angabe "True"? Gruß, Nils Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.