Hey Leute,
ich installiere gerade für unser Branchoffice einen VMware Host.
Das heißt es wird nur einen Host geben ohne SAN Storage oder ähnlichen, die Gäste bleiben auf den Festplatten auf dem Host. Bis jetzt habe ich meine vSphere 5.1 Hosts immer mit der Standardinstallation installiert da im Anschluss ich sowieso den gemeinsamen Storage per FC an alle Hosts angebunden habe. Jetzt frage ich mich soll ich bei diesem Host bei dem die Gäste auf den gleichen HD's liegen (RAID 5) auch die Standardinstallation ausführen oder gibt es da eine Empfehlung von VMware oder von euch was am besten wäre?
VG
an alle
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Empfehlung für Partitionierung
-
Dayworker
- King of the Hill
- Beiträge: 13658
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Die Stripesize ist für mich sowohl vom Controller (unterstützte Stripesizes) als auch Plattenanzahl, Plattenblocksize (512Byte oder 4KiB) und der Dateigrösse (viele kleine Dateien bzw Fragmente oder große sequentielle verarbeitbare Dateien) abhängig.
Festplatten erreichen ihre maximale IO-Raten immer nur bei sequentiellen Zugriffen, von daher wäre eine möglichst große Stripesize von Vorteil. Eine Stripesize von 64KiB bedeutet aber nicht nur, daß alle 64KiB auf das nächsten Raidmitglied geschwenkt wird, sondern in dieser Größe werden dann auch kleinere Dateien bzw Fragmente durch den Controller verarbeitet. Solange die Stripesize also kleiner als die zu schreibenden Daten ist, sind alle Raidmitglieder in eine IO-Operation involviert und ansonsten bedient nur die Spindel mit den angeforderten Daten die Anfrage. In letzterem Fall hast du dann einen Performancegewinn von Null, da das Raid5 seine Lesestärke nicht ausspielen kann.
VMDKs sind zwar mehrere GiB groß, was eine große Stripesize begünstigen würde, allerdings fordern eigentlich alle Betriebssysteme intern RAM-Blöcke zu 4KiB (Desktop-OS) bzw bis zu 4MiB (Server-OS mit aktiven "Large Pages") an und schreiben ihre Daten in Cluster/Block-Größen zwischen 0.5 bis 64KiB weg. Das macht beispielsweise auch das Dilemma nachvollziehbar, wenn du VMs mit völlig gegensätzlichen Zugriffscharakteristika (Beispiel Datenbank und Videoschnitt) auf derselben Raidgruppe ablegen willst.
Wie du siehst, ist das eine Wissenschaft für sich und wird meist durch die vorhandenen Einstellmöglichkeiten der Controller-Firmware vereinfacht.
Einzig die Option "Caching" kann dir jeder beantworten. Plattencache auf "aus", Schreibcache auf dem Controller mit aktiver BBU oder gleichwertigem Flashmodul auf "an".
Festplatten erreichen ihre maximale IO-Raten immer nur bei sequentiellen Zugriffen, von daher wäre eine möglichst große Stripesize von Vorteil. Eine Stripesize von 64KiB bedeutet aber nicht nur, daß alle 64KiB auf das nächsten Raidmitglied geschwenkt wird, sondern in dieser Größe werden dann auch kleinere Dateien bzw Fragmente durch den Controller verarbeitet. Solange die Stripesize also kleiner als die zu schreibenden Daten ist, sind alle Raidmitglieder in eine IO-Operation involviert und ansonsten bedient nur die Spindel mit den angeforderten Daten die Anfrage. In letzterem Fall hast du dann einen Performancegewinn von Null, da das Raid5 seine Lesestärke nicht ausspielen kann.
VMDKs sind zwar mehrere GiB groß, was eine große Stripesize begünstigen würde, allerdings fordern eigentlich alle Betriebssysteme intern RAM-Blöcke zu 4KiB (Desktop-OS) bzw bis zu 4MiB (Server-OS mit aktiven "Large Pages") an und schreiben ihre Daten in Cluster/Block-Größen zwischen 0.5 bis 64KiB weg. Das macht beispielsweise auch das Dilemma nachvollziehbar, wenn du VMs mit völlig gegensätzlichen Zugriffscharakteristika (Beispiel Datenbank und Videoschnitt) auf derselben Raidgruppe ablegen willst.
Wie du siehst, ist das eine Wissenschaft für sich und wird meist durch die vorhandenen Einstellmöglichkeiten der Controller-Firmware vereinfacht.
Einzig die Option "Caching" kann dir jeder beantworten. Plattencache auf "aus", Schreibcache auf dem Controller mit aktiver BBU oder gleichwertigem Flashmodul auf "an".
Man sollte hier zwischen Stripesize und Chunksize unterscheiden. Chunksize x Plattenanzahl ergibt die Stripesize.
Einfache Faustregel: Will man IOPS haben, dann sollte der durchschnittliche IO kleiner sein als die Chunksize. Damit ist sichergestellt, dass sich nur eine Disk um einen IO kümmert. Will man MB/s, dann sollte der durchschnittliche IO größer sein als die Chunksize.
In der Tat nutzt z.B. Windows Server ab 2008 für bestimmte IO Operationen sog. Large Blocks. Der VMkernel kann diese an das Storage durchreichen, ist aber auch limiterit. Die maximale IO Größe kann angepasst werden (Disk.DiskMaxIOSize). Es ist aber zu überprüfen, ob das auch zum Storage passt. Manche Storage mögen es nicht, wenn man ihnen allzu große Blöcke vor die Füße wirft.
Am Ende des Tages ist IO in virtuellen Serverumgebungen random IO, was das Sizing nicht einfacher macht. Kurzum: Wenn du deine durchschnittliche IO Größe nicht kennst, übernimmt die Defaulteinstellungen des Controllers.
Einfache Faustregel: Will man IOPS haben, dann sollte der durchschnittliche IO kleiner sein als die Chunksize. Damit ist sichergestellt, dass sich nur eine Disk um einen IO kümmert. Will man MB/s, dann sollte der durchschnittliche IO größer sein als die Chunksize.
- Applikationen mit gegensätzlichen IO Anforderungen nicht auf den gleichen Platten mischen
- IO (sequential oder random) in Arrays isolieren
- Mehrere logische Laufwerke in einem Array bei random IO
- Ein logisches Laufwerk pro Array bei sequential IO
In der Tat nutzt z.B. Windows Server ab 2008 für bestimmte IO Operationen sog. Large Blocks. Der VMkernel kann diese an das Storage durchreichen, ist aber auch limiterit. Die maximale IO Größe kann angepasst werden (Disk.DiskMaxIOSize). Es ist aber zu überprüfen, ob das auch zum Storage passt. Manche Storage mögen es nicht, wenn man ihnen allzu große Blöcke vor die Füße wirft.
Am Ende des Tages ist IO in virtuellen Serverumgebungen random IO, was das Sizing nicht einfacher macht. Kurzum: Wenn du deine durchschnittliche IO Größe nicht kennst, übernimmt die Defaulteinstellungen des Controllers.
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste