Seite 1 von 1

Szenario: Systemplatte im Datastore, Daten als iSCSI-LUN

Verfasst: 22.12.2011, 10:23
von weigeltchen
Wir planen für den produktiven Einsatz folgendes Szenario mit VMWare Essentials.

Auf zwei ESXi-Maschinen sollen 10 VM gehostet werden. Das sind 2008-, 2003-Server, XP-WS funktional Fileserver mit 500-700 GB Platte, Mailserver mit 500 GB Platte, Logserver mit 200-300GB Platte, eine Appliance mit 200 GB, kleinerer SQL-Server und weiterer Spielkram. Weiterer Plattenspeicherbedarf für alles mögliche um die 2 – 3 TB. Die VM werden auf beide Host verteilt.

Die Datastores sollen auf einem iSCI-SAN angelegt werden, wahrscheinlich OPEN-e.
Ein RAID 6 mit 15k SAS-Platten, ein RAID 6 mit SATA-Platten.

Die Host sollen keine lokalen Platten bekommen, für ESXi entweder USB oder SSD. Als Hardware werden IBM-Server x3650 oder so eingesetzt. Zu den internen NIC kommt noch eine 2 oder 4 Port Karte für die iSCSI-Anbindung über einen separaten Switch dazu.

Wir stellen uns vor, die Systemplatten der VM’s in einem oder mehreren Datastores auf dem SAS-RAID abzulegen. Die Datenplatten sollen als iSCI-LUN gemountet werden. Das sollen dann je nach Einsatzzweck LUN auf dem SATA-RAID z.b. der Fileserver oder LUN auf dem schnellen RAID für den Mailserver, SQL usw. sein.

Durch die Trennung der System- und Datenplatten wollen wir den Sicherungsprozeß der VM entzerren, weil unterschiedliche Ansätze möglich sind.

Ist das ein praktikabler Ansatz?

Verfasst: 22.12.2011, 10:37
von PeterDA
Hi,
1. ich würde wenn es sich vermeiden läßt in den VMs keine iSCSI LUNs mappen. Sondern alles per VMDKs abbilden. Problem ist wenn man Platten braucht die Größer als 2TB-512k sind. Was bei dir aber wohl nicht der Falll ist.

2. Ich würde die VMDKs nicht in unterschiedliche Datastores legen, dass kann meiner Erfahrung nur immer wieder zu Problemen führen.

3. pNICs, hier auf jeden Fall ein 4 Port Karte, eher sogar 2 x 4 Port. Der x3650 hat 2 interne NICs.

Gruß Peter

Verfasst: 22.12.2011, 13:36
von deathrow
2. Ich würde die VMDKs nicht in unterschiedliche Datastores legen, dass kann meiner Erfahrung nur immer wieder zu Problemen führen.


Ich hatte bisher damit keine Probleme. Wo gabs da Ärger bei Dir?

Danke!
:wave

Verfasst: 22.12.2011, 14:09
von Supi
http://vmware-forum.de/viewtopic.php?p= ... ht=#130796

Und von Blazilla oder irix ein HP bzw Dell Angebot für 2 Host + ISCSI Storage ala MD3200 oder P2000 machen lassen.

Denn ein Open-E San ist auch nur ein Rechner, der nicht die Ausfallsicherheit einer SAN mit 2 Controllern bietet.

Anhand der Anforderungen sollte/muss für solch eine Umgebung wohl auch das Budget da sein. ( ca 15-20K?)
Die Backupgeschichte nicht vergessen, vielleicht noch eine dritten kleinen Host mit Bandlaufwerk?

Verfasst: 22.12.2011, 14:21
von PeterDA
Hi,
war, damals mehr ein Layer 8 Problem ....

Wenn ich mich recht entsinne gab es da aber auc Problem mit Snapshots wenn die beiden DS unterscheidliche Blockgrößen hatten.

Gruß Peter

Verfasst: 22.12.2011, 14:39
von kastlr
Hallo Peter,

wenn du alle vmdk's einer VM nur auf eine physikalische LUN packst, hast du auch nur einen Abnehmer für die IO Last.
Gerade bei VM's mit erhöhter IO Last ist so ein Ansatz kontraproduktiv.

In der "alten" physikalischen Welt wurden solche Systeme immer aus gutem Grund mit mehreren LUN's ausgestattet, damit sich die IO Last über mehrere LUN's verteilt.
Und da IO's nicht "virtualisiert" werden, hat sich daran auch mit VMware nichts geändert.

Gruß
Ralf

Verfasst: 22.12.2011, 14:51
von irix
@weigeltchen
Also machen kann man es...... wuerde auch Sinn machen wenn das SAN eine iSCSI Intergation fuer das GuestOS haette damit das OS Snaps triggern kann bzw. dieses Mountet um ein Exchange/SQL/File wieder herzustellen.

Aber das bietet Open-E ja nicht und somit waere es nicht meine Empfehlung. Ich wuerde es uieber VMDKs machen um somit VMware Snaps zu haben und auch Unabhaengig zusein. Ein svMotion/Migration bleibt so moeglich genau wie ein Kloning oder das erstellen von Replikaten.

Gruss
Joerg