VMware und NetApp Storage Best Practices

[Azrael]

Hallo zusammen,

Beitrag Editiert:

Die Antworten:

http://www.netapp.com/us/library/technical-reports/tr-3749.html


Gruß
Azrael[/url]

[irix]

Moin,

du hast uns leider nicht verraten auf welche weise dein Storage angebunden ist (NFS, FC, iSCSI) und bei letzterem ob SW oder HW. Die welche NetAPP haben wuerde es bestimmt auch interressiern welche NetAPP denn genau.

Zu deinem geplantem Vorhaben: Fragen welche du dir bitte mal beanworten solltest:

1. Wieviele LUNs bzw. NFS Mounts sind mit einem ESX Host moeglich?
2. Hat das Storage ein Connection Limit welches man bei iSCSI/NFS durchaus schnell erreichen kann bei entsprechender Anzahl von ESX Hosts, mehreren Pfaden pro LUN sowie evtl. Backup Servern welche auch MPIO machen.
3. Hab ihr Multithier Storage das heist verschiedene Raidgroups bzw. LUNs welche fuer unterschiedliche Charakteristika eingerichtet worden sind?
4. Wie gross schaetzt du den Vorteil durch das Verhalten von 1 VM == 1 Ordner und nicht verteilt auf N Ordern in N Datastores ein?
5. Werden Snapshots benutzt und wenn ja zu welchem Zweck? Die Snapshots aller VMDKs liegen generell immer per Default im Konfigurationsverz. der VM. Das heisst die schoene Verteilung auf verschiedene Datastores hat man gerade nichtig gemacht (in Teilen)
6. Wieviele CMDs pro VM/LUN werden denn erreicht und wie hoch ist die DiskLatency (alles ueber esxtop)
7. Wie gross ist die Queue fuer den entsprechenden HBA und ist dieser schon voll?
8. Jeder virtuelle Controller hat auch eine Queue. Wer konsequent ist haengt jede vDisk an einen einzelnen Contoller
9. An das Alignment der System und Datenplatte wurde gedacht? (Linux, XP, W2k3)

Allgemeines:
- Viele "kleine" LUNs bedeuten auch immer viel Verschnitt da ein DS ja nicht bis 100% belegt werden kann
- Bei 400 VM erreicht man doch schon automatisch eine Verteilung. Dies weiter auf VM Ebene zu bringen wuerde ich nur im Notfall machen
- Bei VMDKs verteil auf N Datastores bitte auf die Blocksize Problematik achten im Zusammenhang mit Snapshots. Unter vSphere wird das nun abgefangen und der Snapshot wird verweigert wenn die Blocksize nicht gleich oder groesser ist

Wie haben hier leider kein Multithier Storage und das Storage kann auch nur eine Raidgruppe pro Array. Bei den SAP VMs wurde noch drauf geachtet das jede Platte ein LUN ist bis wir mit dem Upgrade auf vSphere das Connection Limit im Storage erreicht hatten.

Gruss
Joerg

[Azrael]

Hallo Joerg,
Vielen Dank für Deine Antwort.

leider kann ich Dir nicht alle Fragen beantworten. Da ich von der Storage Seite nicht so den Plan habe.

Wir haben für die Virtualisierung extra ein FC-Netzwerk eingerichtet, das auch redundant ausgelegt ist.

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.

Zu2) Ob das Storage einen Connection Limit hat weiß ich leider nicht. Ich weiß aber, dass die LUNs mit 4 Pfaden angebunden wurden.

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.

Zu5) Snapshots werden genutzt für das einspielen von Patchen. Läuft die Maschine nach dem Patchen wird der Snap entfernt.

Zu6) Kann ich derzeit nicht gucken (habe Urlaub aber mache mir trotzdem Gedanken) 

Zu7) kann ich leider nicht gucken.

Zu8) Das machen wir derzeit auch. Systemdisk SCSI 0:0 der Rest auf 0:1 usw.

Zu9) Jegliche Maschinen, die auf das neue System kommen (NetApp, vSphere) werden bzw. sind Aligned. W2k8 ist ja schon perfekt 

Wir haben schon durch den Einsatz von NetApp und vSphere schon eine Verbesserung zu dem „alten“ System ESX 3.5 und HP EVA.
Da wir durch die alte Konstellation Performance Probleme haben, möchten wir dies von Anfang an bei der neuen Umgebung vermeiden.
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)

Wenn noch Fragen anfallen können die gestellt werden.

Gruß
Azrael

[xalepopi]

Hallo Azrael,

hast du einen NOW Account? Wenn nicht, unbedingt anlegen, da ihr ja NetApp Customer seid oder einen deiner Storagekollegen fragen. Es gibt von NetApp einen Technical Report Namens TR-3749 - NetApp and VMware vSphere Storage Best Practices. Dort werden die empfohlenen Konfigurationen im FC, iSCSI und NFS Umfeld erläutert und erklärt. Ich denke, in diesem werden die meißten deiner Fragen beantwortet. Müssten deine Kollegen aber eigentlich auch wissen. Der TR ist sehr gut beschrieben und ich implementiere in den meißten Fällen nach diesen Vorgaben. Kommst du nicht an den TR ran, bitte eine kurze PN.

Viele Grüße aus Köln...

[Azrael]

Hallo Xalepopi,

vielen Dank für deine Antwort.

Habe das Dokument heruntergeladen.

http://www.netapp.com/us/library/technical-reports/tr-3749.html

Schöne Grüße und einen Guten Rutsch ins neue Jahr
Azrael

[irix]

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

[Azrael]

Hallo irix,

vielen Dank für deine Antwort.

ich muss mich wohl mit meinem Chef zusammensetzten und das ganze besprechen.

Ob wir nun die "alte" Vorgehensweise beibehalten oder nicht. Ich werde die Vor und Nachteile ihm sagen und dann werden wir mal gucken.

Über De-Duplizierung kann ich Dir bis jetzt nur die Theorie bzw. vom hören sagen Informationen geben.
Die Storage Abteilung betreibt auch SAP Systeme mit NetApp. Dort wurde das DD. eingeschaltet. Mir wurde gesagt, dass sie mit DD. mehr als 60% Plattenplatz sparen konnten.

Des Weiteren ist die Idee:
Systempartitionen auf eine LUN zu konsolidieren. Daraufhin aktivieren wir DD. und sparen somit eine Menge Platz, da die Systeme alle gleich sind (W2k8).

Einen weiteren Vorteil von DD. ist:
Nehmen wir an, jede virtuelle Maschine hat eine Testdatei „test.txt“ auf dem Desktop. Somit wird diese Datei nur einmal auf dem Storage Blockweise hinterlegt. Gibt es eine Anfrage auf die Datei, somit wird diese in den Cache geladen und steht für alle Systeme im Cache zur Verfügung. (Schneller)

Ich hoffe ich konnte das einigermaßen erklären (Schriftlich ist das etwas doof)

Allgemeine Vorteile von DD.
1) Verringerung von Speicherplatz
2) Bessere Zugriffszeiten auf Dateien die mehrmals benötigt werden (Theorie)

DD. haben wir leider im Bereich von VMware noch nicht getestet. Das wird aber noch gemacht. Ich kann dir dann bescheid geben, wenn wir den Test durchgeführt haben.

Gruß
Azrael

[bas123]

Hallo,

Thema ist zwar schon älter aber das Testergebniss hätte mich interessiert.
Wie sieht es aus? Funktioniert die De-Duplizierung von NetApp? Wird eingehalten was versprochen wird?

Allgemein würde mich interessieren ob FC überhaupt DD unterstützt.

Beste Grüße,
bas

[straight_way]

Servus,

auch mal meinen Senf dazu gebe:

Also zum Thema DD:

Da ihr das ganze auf einer Netapp fahrt, brauchst du die Systemplatten der VMs nicht zwingend auf Datastore1 und Datenplatten auf Datastore2 ablegen, da die DeDuplizierung auf Volume Ebene abläuft.

Das bedeutet du hast z.B. ein Volume, das heißt "VMFS_Volume1"
in diesem Volume werden deine LUNs erstellt "VMFS_Datastore1" / "VMFS_Datastore2" usw. das sieht dann von der Struktur her ungefähr so aus:

- "VMFS_Volume1" (ist ein Netapp FlexVol(ume) )
- "VMFS_Datastore1" (ist eine LUN die vom ESX als Datastore gemappt werden kann)
- "VMFS_Datastore2" (ist eine LUN die vom ESX als Datastore gemappt werden kann)

Die LUNs, also das was dein ESX zu Gesicht bekommt, sind auf der Netapp einfach gesprochen nur ein Verzeichnis/eine Datei innerhalb des Volumes.
Da wie oben erwähnt DeDup auf Volume Ebene arbeitet kannst du ganz entspannt z.B. mehere 500GB LUNs/Datastores erstellen und dann alle Dateien
einer VM an einer Stelle zusammenhalten (in einem Verzeichnis) und hast trotzdem den Nutzen von DeDup, da die LUNs sich innerhalb eines "Volumes" befinden.

Der Vorteil den du natürlich hast, wenn du, wie du es selbst beschrieben hast, deine Systempartitionen auf einer LUN (dann aber auch in einem separaten Volume!!)
zusammfasst und nur dort DeDup aktivierst ist, dass die Netapp auch nur auf diesem einen Volume nach gleichen Blöcken zum deduplizieren suchen muss.
-> Sprich es wird weniger Leistung und somit auch Zeit für den DeDup Vorgang benötigt.

Wieviel Leistung allerdings benötigt wird kann leider nicht beurteilen.

Wobei man natürlich immer in Abhängigkeit der eigenen Umgebung entscheiden muss welche Strategie man wählen möchte. Alles hat wie immer im mLeben einen Vor- und meistens auch gleichzeitig irgendeinen Nachteil.