Azrael hat geschrieben:Hallo Joerg,
Vielen Dank für Deine Antwort.
Wir haben für die Virtualisierung extra ein FC-Netzwerk eingerichtet, das auch redundant ausgelegt ist.
Ok, also FC.
Zu1) In einem Datastore hat man die Möglichkeit 32 LUNs einzubinden. Wie viel Datastores nun in einem Datacenter bzw. einem ESX Host/Cluster zugewiesen werden können weiß ich nicht. In der „alten“ Umgebung mit ESX 3.5 haben wir schon über 60 Datastores mit je einer 500 GB LUN worauf mehrere VMs laufen.
An die Moeglichkeit an Extends hatte ich garnicht gedacht und das erklaert auch deine Zahlenspielerreihen. Da mit bisheute keiner die Vorteile von Extends erklaeren konnte und ich mir nur einen kurzzeitigen kleinen Anwendungfall vorstellen kann kann ich dir nicht empfehlen auf Extends zu setzen.
Warum ich nach Storagetyp und Anzahl frage ist folgendes: Haettet ihr NFS gehabt, bei Netapp ja nicht unueblich, dann waere das Limit 64 Mounts = Datastores gewesen. Bei FC darfst du nun bis zu 255/256 LUNS dem ESX präsentieren. Somit auch hier die Gefahr das bei deiner Strategie mit einer VM pro Datastore dir irgendwann mal die LUNs ausgehen. Ausserdem machst du dich da bei deinem StorageAdmin unbeliebt.
IIRC bilde ich mir immer nich ein das bei Extends die erste LUN immer noch am wichtigsen ist und bei Verlust der ganze DS dahin ist. Fehlt ein Mittelstueck so ist das nur Halbtragisch weil die Teile davor und dahinter ansprechbar sind.
Was ich aber fuer unmoeglich halte in deinem Interesse ist die Kontrolle wo welche VM nun letztendlich liegt. Der DS wird vom Anfang her befuellt und sorgt dafuer das die ersten LUNs voll sind waerend dessen die hinteren sich langweilen weil sie noch leer sind.
Zu2) Ob das Storage einen Connection Limit hat weiß ich leider nicht. Ich weiß aber, dass die LUNs mit 4 Pfaden angebunden wurden.
Spielt bei FC keien Rolle und waere nur zum Tragen gekommen bei der Anbindung von IP basiertem Storage.
Zu3) Wir haben derzeit eine 5 TB Raidgruppe (NetApp) wovon uns bis jetzt ein Teil als LUNs zur Verfügung gestellt werden (Testzwecke)
Zu4) Weiß nicht so ganz was du meinst? Eine VM mit mehreren Disk kann ich natürlich auf mehrere Datastores verteilen. Der Plan (was von der Sotrage Abteilung gefordert wird) ist die einzelnen Platten auf verschiedene Datastores zu verteilen: Datastore 1. Für die Systempartionen der VMs. Datastore 2. Für die Daten der VMs so wie ein Datastore für die Datenbank usw. Grund: Mittels Dedublikation können wir den Plattenplatz (NetApp) verringern und gemeinsam genutzte Dateien mittels Cache schneller bereitstellen.
Fuer das KISS Konzept und somit eine VM imer zusammenhalten in einem DS.
Pro:
- Einfachere Dokumentation
- Es folgt einem dem Konzentrations Gedanken von VMware alle Daten "zusammen" in einm Verz.
- Bei Ausfall der LUN sind weniger VMs betroffen als wenn die Systemplatten einer groesseren Anzahl von VMs in dem Datastore liegen
- Restore//Recovery einfacher
Contra:
- Snapshot verlangern die IO Belastung wieder auf Systemplatten LUN. Die Speicherplatzueberwachung ist hier essientiell
- Blocksize fuer den DS muss immer gleich oder groesser sein wie die der Datenplatten LUN (Sehe ich aber nicht als Nachteil und wuerde generell 8MB waehlen sofern von Netapp Seite da nichts gegenspricht)
- Evlt. Performance Verlust sofern man ueberhaupt sagen kann ob die Last auf System oder Datenplatten liegt. Weniger effektiv wenn man nur einen Typ von RAID Gruppe hatt. Sprich wenn man sagen koennte wir haben hier RAID10 fuer unsere Datenbank Datenplatten
- Evtl. weniger effektives De-Duplizierung*
* Magst du uns verraten wie granular dieses Feature wirkt bzw. ist es nur Pro LUN oder auch etwas globaler? Wenn es "nur" pro LUN ist dann ist das natuerlich eins der Killerargurmente fuer die Aufteilung nach System- und Datenplatten um den groesstmoeglichen Vorteil daraus zuziehen.
Zu5) Snapshots werden genutzt für das einspielen von Patchen. Läuft die Maschine nach dem Patchen wird der Snap entfernt.
Wie schon erwaehnt wuerde Snapshots dein Konzept kurzfristig stoeren. Liegen die Snapshot laenger rum wird das ganze sogar hinfaellig.
Zu6) Kann ich derzeit nicht gucken (habe Urlaub aber mache mir trotzdem Gedanken)
Solche Mitarbeiter sind Lobenswert. Morgends die Ersten, Abends die Letzten, am Wochenende die Einzigen und auch im Urlaub in Gedanken auf der Arbeit
Zu7) kann ich leider nicht gucken.
Zu8) Das machen wir derzeit auch. Systemdisk SCSI 0:0 der Rest auf 0:1 usw.
Das ist doch der Standard und unter Umstaenden mal ein Bottleneck. Jeder virtuelle Kontroller hat eine begrenzte Warteschlange welche Anforderungen aufnehmen kann. Kann diese nicht schnell genug abgearbeitet werden so wird die VM ausgebremst.
Mir geht es einfach darum, was wäre das beste:
1. 1 VM pro Datastore / LUN
2. Mehrere VMs auf einem Datstore (eine 500 GB LUN) derzeit bei ESX3.5 und EVA umgesetzt.
3. Mehrere VMs auf einem Datastore, das aus mehreren LUNs besteht (32 * 25 GB oder 10 GB)
Hast du nicht 4. vergessen wo du die vDisks aus deinen VMs auf verschiedene Datastores verteilen willst?
Zu 1.
- Anzahl LUNs explodiert bei hoher Anzahl VMs,
- Wirkt dein De-Duplizierungs feature hier effektiv?
- Hoher Verschnitt da ja immer ein paar GB an freiem Speichergebraucht wird fuer Snapshots)
Zu 2.
- Standardmethode. Evtl. mal eine Charakterisierung der VMs machen bzw. Performancecharts auswerten um IO lastige VMs nicht zusammen in einem DS zuhaben.
Zu 3.
- Nein
Bitte lass mir mal das TR zukommen damit ich heute mal was zum lesen habe
.
Gruss
Joerg
