Moin,
da mich die Suche nicht weitergebracht hat, meine konkrete Frage:
Ich möchte 8 virtuelle Server auf einem ESX-Cluster einrichten, alle mit einer Minimal-OS-Platte, aber 3 davon erhalten jeweils eine zusätzliche Platte für Massendaten.
Diese 3 Server werden einiges an File-I/O - leisten müssen. Macht es deshalb Sinn, die OS-Platten der Server alle auf einem SAN-Topf einzurichten und die I/O-intensiven zusätzlichen Platten in separaten SAN-Töpfen?
Ich könnte mir vorstellen, dass dann auf dem einen SAN-Topf (auf dem die OS-Platten der VMs liegen) relative Ruhe herrscht und auf den anderen SAN-Töpfen mit ordentlich I/O deutlich mehr los ist.
Oder wird das Ganze dadurch nur kompliziert und bringt nix?
Zur Konfig:
2 ESX-Hosts mit jeweils 2 Quad-Core CPUs, 16G RAM und doppelpfadiger FC-Anbindung.
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!
Platten von VMs auf mehrere SANs verteilen?
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Mahlzeit,
um deine Frage beantworten zu können, müßten wir eigentlich die IO Last und dein SAN Design kennen.
Eigentlich sind Fileserver gar nicht so IO Lastig, große Datenbanken haben dort deutlich höhere Anforderungen.
Wie dem auch sei, bei hohen IO Lasten solltest du dedizierte LUNs verwenden, damit du mehrere Devices hast, über die sich die IO Anfragen verteilen.
Ob du den LUN's ein VMFS spendierst oder diese als RDM direkt in die VM mountest, ist relativ egal.
RDM's sind zwar schneller, aber wir reden hier gerade einmal über 5-10% mehr Performance, für die du einige VMware Features opfern mußt.
Allerdings mußt du natürlich das Design deines SAN Storages berücksichtigen, es macht z.B. keinen Sinn, im SAN ein RAID 5 Device anzulegen, das dann zwei LUN's bereitstellt, welche richtig unter Last genommen werden.
Hoffe das hilft dir ein bisschen.
Gruß
Ralf
um deine Frage beantworten zu können, müßten wir eigentlich die IO Last und dein SAN Design kennen.
Eigentlich sind Fileserver gar nicht so IO Lastig, große Datenbanken haben dort deutlich höhere Anforderungen.
Wie dem auch sei, bei hohen IO Lasten solltest du dedizierte LUNs verwenden, damit du mehrere Devices hast, über die sich die IO Anfragen verteilen.
Ob du den LUN's ein VMFS spendierst oder diese als RDM direkt in die VM mountest, ist relativ egal.
RDM's sind zwar schneller, aber wir reden hier gerade einmal über 5-10% mehr Performance, für die du einige VMware Features opfern mußt.
Allerdings mußt du natürlich das Design deines SAN Storages berücksichtigen, es macht z.B. keinen Sinn, im SAN ein RAID 5 Device anzulegen, das dann zwei LUN's bereitstellt, welche richtig unter Last genommen werden.
Hoffe das hilft dir ein bisschen.
Gruß
Ralf
Auch Mahlzeit und danke für die schnelle Antwort! 
Bei den 3 besonderen VMs handelt es sich um Netinstall-Server, welche Software-Pakete vorhalten und verteilen. Also keine Datenbanken, wie z. B. MSSQL oder Oracle, eher Shares.
Zum SAN kannn ich nicht viel sagen, ist leider ausserhalb meines (Wissens-)Horizonts.
Nur so viel: ich verwende keine RDMs, sondern gehe immer über VMFS, das hat bisher auch gut funktioniert.
Mich irritiert eher die Aussicht, dass die VMs dann immer mit mehreren LUN's eine Verbindung halten (C-Platte auf LUN-OS, D-Platte auf LUN-x), was doch schnell unübersichtlich wird.
Meine bisherige Philosophie war, alle Files für eine VM immer zusammen auf einer LUN zu lassen. War übersichtlich und gut zu warten, aber vielleicht gibt es ja gute Gründe, das nicht mehr zu tun.
Gruß
Wumpel
Bei den 3 besonderen VMs handelt es sich um Netinstall-Server, welche Software-Pakete vorhalten und verteilen. Also keine Datenbanken, wie z. B. MSSQL oder Oracle, eher Shares.
Zum SAN kannn ich nicht viel sagen, ist leider ausserhalb meines (Wissens-)Horizonts.
Nur so viel: ich verwende keine RDMs, sondern gehe immer über VMFS, das hat bisher auch gut funktioniert.
Mich irritiert eher die Aussicht, dass die VMs dann immer mit mehreren LUN's eine Verbindung halten (C-Platte auf LUN-OS, D-Platte auf LUN-x), was doch schnell unübersichtlich wird.
Meine bisherige Philosophie war, alle Files für eine VM immer zusammen auf einer LUN zu lassen. War übersichtlich und gut zu warten, aber vielleicht gibt es ja gute Gründe, das nicht mehr zu tun.
Gruß
Wumpel
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
an deiner Philosophie ist auch nichts auszusetzen, solange du das Thema Performance nicht betrachtest.
Und auch dann hängt es immer noch von der IO Last ab, die deine System erzeugen.
Es ist halt nun mal so, das eine LUN nur eine gewisse Anzahl von IO/sec bedienen kann.
Willst du mehr machen, brauchst du zusätzliche LUN's.
Wenn du dann ein SAN Array einsetzt, muß dies die Last auch unter Verwendung von Cache und Disk Performance stemmen können.
Das sollte in deinem Fall sicher kein Problem sein, aber da du nicht weißt, wie die dir bereitgestellten LUN's im Array erzeugt werden, kann hier eine ungünstige Konfiguration durchaus dazu führen, das deine LUN's nicht schnell genug sind.
Aber du hast doch sicherlich jetzt schon NetInstall Server im Einsatz, hast du dafür keine Performance Daten?
Ich glaube nämlich nicht, das diese Systeme generell eine hohe Last erzeugen, hier geht es eher um einzelne Peaks.
Und dann stellt sich die Frage, ob du dein System so konfigurieren möchtest, das es auch die Peaks ohne Probleme bedienen kann.
Ich persönlich empfinde es nicht als sonderlich unübersichtlich, die vmdk Dateien über mehrere LUN's zu verteilen.
Schließlich wird in jedem verwendetem Datastore ein Verzeichnis für die VM angelegt, die diese virtuelle Disk nutzt.
Aber meine Test Umgebung ist auch etwas größer, aktuell habe ich 126 LUN's in drei verschiedenen Storage Arrays in use.
Gruß
Ralf
an deiner Philosophie ist auch nichts auszusetzen, solange du das Thema Performance nicht betrachtest.
Und auch dann hängt es immer noch von der IO Last ab, die deine System erzeugen.
Es ist halt nun mal so, das eine LUN nur eine gewisse Anzahl von IO/sec bedienen kann.
Willst du mehr machen, brauchst du zusätzliche LUN's.
Wenn du dann ein SAN Array einsetzt, muß dies die Last auch unter Verwendung von Cache und Disk Performance stemmen können.
Das sollte in deinem Fall sicher kein Problem sein, aber da du nicht weißt, wie die dir bereitgestellten LUN's im Array erzeugt werden, kann hier eine ungünstige Konfiguration durchaus dazu führen, das deine LUN's nicht schnell genug sind.
Aber du hast doch sicherlich jetzt schon NetInstall Server im Einsatz, hast du dafür keine Performance Daten?
Ich glaube nämlich nicht, das diese Systeme generell eine hohe Last erzeugen, hier geht es eher um einzelne Peaks.
Und dann stellt sich die Frage, ob du dein System so konfigurieren möchtest, das es auch die Peaks ohne Probleme bedienen kann.
Ich persönlich empfinde es nicht als sonderlich unübersichtlich, die vmdk Dateien über mehrere LUN's zu verteilen.
Schließlich wird in jedem verwendetem Datastore ein Verzeichnis für die VM angelegt, die diese virtuelle Disk nutzt.
Aber meine Test Umgebung ist auch etwas größer, aktuell habe ich 126 LUN's in drei verschiedenen Storage Arrays in use.
Gruß
Ralf
Ich halte es auch so, die vDisks je nach I/O-Erfordernissen auf verschiedene LUNs und/oder Storage Arrays zu verteilen. Früher fand ich es besser handzuhaben, die Dateien an einem Ort zu haben und konsequent zu benennen, aber seit ich immer weniger mit vmkfstools und Skripten hantiere und mehr über das VC und Veeam regele, ist das nicht mehr so kritisch.
Eine Richtigstellung noch:
Die IOps haben weniger mit der LUN als dem Storage Array zu tun, auf dem die LUN liegt (Controller, FC/SAS/SATA-Platten, Geschwindigkeit und Anzahl der Platten, RAID-Level). Du meinst möglicherweise SCSI Reservations. Es gibt sicherlich Empfehlungen von VMware, wieviele VMs maximal auf einer LUN laufen sollten, aber ich habe sie nicht parat.
Georg.
Eine Richtigstellung noch:
Es ist halt nun mal so, das eine LUN nur eine gewisse Anzahl von IO/sec bedienen kann.
Die IOps haben weniger mit der LUN als dem Storage Array zu tun, auf dem die LUN liegt (Controller, FC/SAS/SATA-Platten, Geschwindigkeit und Anzahl der Platten, RAID-Level). Du meinst möglicherweise SCSI Reservations. Es gibt sicherlich Empfehlungen von VMware, wieviele VMs maximal auf einer LUN laufen sollten, aber ich habe sie nicht parat.
Georg.
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Georg,
natürlich hast du bezüglich der LUN's recht, schließlich handelt es sich hier im eigentlichen Sinne ebenfalls um virtuelle Devices, nur das diese vom Storage Array bereitgestellt werden.
Aber wegen dieser Bemerkung wollte ich darauf nicht weiter eingehen, SAN Performance ist eine Wissenschaft für sich.
Gruß
Ralf
natürlich hast du bezüglich der LUN's recht, schließlich handelt es sich hier im eigentlichen Sinne ebenfalls um virtuelle Devices, nur das diese vom Storage Array bereitgestellt werden.
Zum SAN kannn ich nicht viel sagen, ist leider ausserhalb meines (Wissens-)Horizonts.
Aber wegen dieser Bemerkung wollte ich darauf nicht weiter eingehen, SAN Performance ist eine Wissenschaft für sich.
Gruß
Ralf
GTMK hat geschrieben:
Du meinst möglicherweise SCSI Reservations. Es gibt sicherlich Empfehlungen von VMware, wieviele VMs maximal auf einer LUN laufen sollten, aber ich habe sie nicht parat.
Hi,
sicherlich sollte man auf die SCSI Reservations achten. Hier die Empfehlung von VMware:
Empfehlenswert für den Start sind LUNs von 250-500GB, maximal 1 TB, auf denen jeweils 5-10 VMs liegen, je nach Leistungsanforderung.
Missachtet man das, kann es zu starken Performanceeinbrüchen kommen.
Gruß,
cFu
-
Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
Mahlzeit,
danke für eure lebhafte Diskussion! Es sind doch einige Denkanstöße dabei, die weiter verfolgen werde.
Zuerst werde ich mal zusehen, dass ich I/O-Daten von den derzeitigen Netinstall-Servern bekomme, dann habe ich schon mal einen Richtwert.
Wenn ich dann jedem der drei Hauptserver eine eigene LUN spendiere, dann, denke ich, bin ich erst mal auf der sicheren Seite. Die anderen, kleinen VMs für Orgmaster und Repl-Dienste bekommen einen Sammeltopf.
Wenn die VMs dann aktiv werden, werde ich sie mir mal genauer mit Veeam ansehen. Ist eine gute Gelegenheit, sich auch mal mit diesem Tool vertraut zu machen
danke für eure lebhafte Diskussion! Es sind doch einige Denkanstöße dabei, die weiter verfolgen werde.
Zuerst werde ich mal zusehen, dass ich I/O-Daten von den derzeitigen Netinstall-Servern bekomme, dann habe ich schon mal einen Richtwert.
Wenn ich dann jedem der drei Hauptserver eine eigene LUN spendiere, dann, denke ich, bin ich erst mal auf der sicheren Seite. Die anderen, kleinen VMs für Orgmaster und Repl-Dienste bekommen einen Sammeltopf.
Wenn die VMs dann aktiv werden, werde ich sie mir mal genauer mit Veeam ansehen. Ist eine gute Gelegenheit, sich auch mal mit diesem Tool vertraut zu machen
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste