Welches Raidset, und LUN aufteilung?

[V2AP]

Hallo VMware Community,

bin neu in diesem Forum, und habe auch gleich eine frage.
Ich habe schon die ein oder andere kleinere (z.B. Vsphere installation und 2-3 TByte VMFS Pool in einem Server.) Vsphere installation bei Kunden aufgestellt.
Jetzt habe ich einen Kunden der das ganze etwas größer aufziehen möchte, sprich BladeCenter mit von 5 Blades auf denen Vsphere Enterprise installiert wird.
Angebunden werden die Blades an ein 8Gbits/s FC SAN 24 TByte Brutto (12 x 2 TByte Nearline SAS bzw.SATA Platten 7.200 UpM) kapazität mit HA, VMotion konfiguration usw.

Da mein Kunde leider nicht so viel Geld auf einmal ausgeben wollte, ist leider mom. kein Backup SAN mehr im Budget mit eingeplant.

Hier liegt auch schon mein erstes Problem bzw. Gewissenskonflikt: (Habe mich schon viel informiert und Dokus gelesen, aber wurde nicht wirklich schlau. Ich hoffe jetzt auf eure Erfahrungswerte)

Ich bin jetzt auf Sicherheit gegangen, und habe das Raidset im SAN Raid 6 + HS konfiguriert. Sprich ich hätte jetzt ein Volume mit knapp 17 TByte netto zur Verfügung.
Habe auch schon kurz überlegt ob ich das SAN aus Performance Gründen Raid 5 + HS konfiguriere, aber es dauert halt schon ein
bisschen bis 2 TByte nach einem Plattenausfall wieder hergestellt werden.
Und beim Rebuild stehen die restlichen Platten ziemlich unter "stress", heißt das eine weitere Platte während des Rebuilds ausfällt ist nicht ganz ausgeschlossen.
Darum würde ich lieber auf Nummer sicher gehen. Aber wenn die Performance wirklich so miserabel ist, bringst natürlich auch nix.

SAN Storage ist ein Fujitsu Eternus DX80 mit Dual Controller mit 4GByte Cache und Intel Xeon Prozessor.
Wie ist denn eure Erfahrung mit Raid 6 ? Ist die Performance wirklich so übel, vorallem bei solchen High End Raids ?

Auf denn 5 Blade Vsphere Server sollen 8 ziemlich Performante Worklfow und Softproof Server aufgeteilt werden, sowie nicht so Performante Server wie z.B. FTP, FileServer, DNS Server, Webserver, Datev usw.
Insgesamt gehe ich von 18 - 22 virtuellen Server aus. Gesamt Kapazität würde ich auf 10 - 12 TByte schätzen.

Wie sollte ich denn am besten die LUN's aufteilen ? Mein Vorschlag wären hier 4 Luns in denen sich je 2 Worklfow bzw. Softproof Server befinden. Und einen LUN für den Rest. Also gesamt 5 LUN's
Wäre das so in Ordnung ?
Da ja bei VMFS-5 Dateisystemen die ab vSphere 5 unterstützt werden, kann die maximale Filesystemgröße von 64 TB mit einem einzelnen RAID Volume bereitgestellt werden.
Kann ich mir eventuell das ganze LUN Gedöns sparen. Vielleicht doch nur einen 17 TB LUN. Ist das eventuell sinnvoll ?

Wie gesagt, ich habe leider mit so einen großen VMware konfig noch keine Erfahrung sammeln können, und hoffe hier auf eure Hilfe.

Vielen Dank, und einen schönen Tag noch.

Grüße
V2AP

[bla!zilla]

Jetzt habe ich einen Kunden der das ganze etwas größer aufziehen möchte, sprich BladeCenter mit von 5 Blades auf denen Vsphere Enterprise installiert wird. Angebunden werden die Blades an ein 8Gbits/s FC SAN 24 TByte Brutto (12 x 2 TByte Nearline SAS bzw.SATA Platten 7.200 UpM) kapazität mit HA, VMotion konfiguration usw.

Das sieht jetzt nicht so aus, als ob du mit solchen Installationen Erfahrung hast. Speziell Bladeserver sind noch mal etwas anders in der Handhabung und erfordern meist etwas andere Vorgehensweisen bei der Netzwerkanbindung, bedingt durch den Einsatz von embedded Switches o.ä.

Ich bin jetzt auf Sicherheit gegangen, und habe das Raidset im SAN Raid 6 + HS konfiguriert. Sprich ich hätte jetzt ein Volume mit knapp 17 TByte netto zur Verfügung.

Warum RAID 6? Bei 12 Disks Nearline SAS wird das Ganze ziemlich lahm werden. Wie viele Maschinen will dein Kunde betreiben?

Habe auch schon kurz überlegt ob ich das SAN aus Performance Gründen Raid 5 + HS konfiguriere, aber es dauert halt schon ein bisschen bis 2 TByte nach einem Plattenausfall wieder hergestellt werden.

Noch mal die Frage nach dem Workload: Was will dein Kunde da machen? Deine Überlegungen hinsichtlich Recoveryzeiten und Ausfallwahrscheinlichkeiten sind richtig, aber deuten auch schon auf einen Designfehler hin.

Und beim Rebuild stehen die restlichen Platten ziemlich unter "stress", heißt das eine weitere Platte während des Rebuilds ausfällt ist nicht ganz ausgeschlossen.

Kommt darauf an wie man sie hält... Nearline SATA mögen auf Dauer keinen random IO.

Darum würde ich lieber auf Nummer sicher gehen. Aber wenn die Performance wirklich so miserabel ist, bringst natürlich auch nix.

Und das wird sie...

SAN Storage ist ein Fujitsu Eternus DX80 mit Dual Controller mit 4GByte Cache und Intel Xeon Prozessor.
Wie ist denn eure Erfahrung mit Raid 6 ? Ist die Performance wirklich so übel, vorallem bei solchen High End Raids ?

Ja wird sie, vor allem bei kleinem random Write IO. Das ist Prinzipbedingt.

Auf denn 5 Blade Vsphere Server sollen 8 ziemlich Performante Worklfow und Softproof Server aufgeteilt werden, sowie nicht so Performante Server wie z.B. FTP, FileServer, DNS Server, Webserver, Datev usw.
Insgesamt gehe ich von 18 - 22 virtuellen Server aus. Gesamt Kapazität würde ich auf 10 - 12 TByte schätzen.

Du hast zu wenig Platten.

Wie sollte ich denn am besten die LUN's aufteilen ? Mein Vorschlag wären hier 4 Luns in denen sich je 2 Worklfow bzw. Softproof Server befinden. Und einen LUN für den Rest. Also gesamt 5 LUN's
Wäre das so in Ordnung ?

Mehrere Volumes in einem Array sind suboptimal. Der konkurrierende IO könnte dir die Performance noch weiter versauen.

Da ja bei VMFS-5 Dateisystemen die ab vSphere 5 unterstützt werden, kann die maximale Filesystemgröße von 64 TB mit einem einzelnen RAID Volume bereitgestellt werden.
Kann ich mir eventuell das ganze LUN Gedöns sparen. Vielleicht doch nur einen 17 TB LUN. Ist das eventuell sinnvoll ?

Nein. Keine gute Idee.

Wie gesagt, ich habe leider mit so einen großen VMware konfig noch keine Erfahrung sammeln können, und hoffe hier auf eure Hilfe.

Leider ist dein Plattendesign für die Installation in die Hose gengangen. Zu dem Rest des Setups kann ich nichts sagen. Wie sieht es mit dem Rest aus? Dual Fabric oder was willst du da aufbauen? Wie willst du zonen?

[V2AP]

Hallo bla!zilla,

du hast recht. Ich habe mit solch einer konfig noch keine Erfahrung. Das System bzw. dieses Setup habe ich so vorgesetzt bekommen.

Warum RAID 6? Bei 12 Disks Nearline SAS wird das Ganze ziemlich lahm werden. Wie viele Maschinen will dein Kunde betreiben?

Wie kann ich denn hier das optimale Ergebniss in sachen Raidlevel und Performacne erzielen? Wie würdest Du hier verfahren?
Es sollten auf dieser Umgebung ungefähr 18 Virtuelle Server laufen.

Noch mal die Frage nach dem Workload: Was will dein Kunde da machen? Deine Überlegungen hinsichtlich Recoveryzeiten und Ausfallwahrscheinlichkeiten sind richtig, aber deuten auch schon auf einen Designfehler hin.

Wie gesagt, ich ginge auch davon aus, das es noch ein Backup Raid geben wird. Das ist leider nicht der Fall. Jetzt muss ich einen guten Mittelweg aus Sicherheit und Performance finden. Was meinst Du genau mit Workload?

Mehrere Volumes in einem Array sind suboptimal. Der konkurrierende IO könnte dir die Performance noch weiter versauen.

Was schlägst Du vor? Besser die Volumes am Raid anlegen, und diese dan den Blades bzw. VSphrer zuweißen?

Danke für deine hilfe

[bla!zilla]

Was sind das genau für Platten? Nearline SATA mit 7,2k RPM? Angesichts von 12 Platten á 2 TB würde ich eher in Richtung folgender Config gehen: 3x RAID 1+0 mit jeweis vier Platten. Auf Spares würde ich in dem Fall verzichten. Macht 4 TB pro Virtual Disk nutzbar. Ich würde dann ein Volume á 4 TB für VMware bereitstellen, so das du am Ende drei Datastores mit je 4 TB und VMFS-5 hast. Damit dürftest du aus der Umgebung die maximale Leistung mit entsprechender Verfügbarkeit rausholen.

Rawdevices würde ich in dem Konstrukt gar nicht nutzen.

Das Workload bezeichnet die erforderlichen IOPS (Read/ Write und Verhältnis). Das muss normalerweise vor dem Projekt ermittelt werden. Und anhand dieser Daten muss das Sizing vorgenommen werden.

[V2AP]

Servus bla!zilla,

super, vielen vielen dank für deinen Tip.

so ich habe das Raid jetzt hier bei mir im Büro stehen. Es sind 3,5 Zoll 2TByte Seagate SAS bzw. SATA Platten.

Würde eigentlich folgende konstellation auch gehen: 2x Raid5 á 5 Platten + 2 HS
Macht 8 TB pro virtual Disk. Haben dan quasi zwei 8 TB Volumes die ich den 5 Blades zur verfügung stellen kann.

Wäre das eventuell auch möglich. Mach das auf VMware sicht Sinn?

Es geht nur darum, das ich dem Kunden dann 2 optionen zur verfügung stellen kann.
Ich perönlich würde auch auf deine vorgeschlagene Raid 10 konfig tendieren. Weiß bloß noch nicht wie der Kunde reagiert wenn ich Ihm sage das bei der Raid 10 konfig, die hälfte des Storages flötten geht.

[stahly]

Die wichtigste Antwort fehlt immer noch: Wie viele IOPS werden es? (Worklaod)

Ich habe dutzende VMs, die ich auf einem SATA Raid6 laufen lassen könnte.

Wenn es aber ein dicker DB-Server wird, ist ein Raid 10 mit 4 Platten noch zu wenig! Dann brächte ich mehr Spindeln... (>3.000 IOPS sind keine Seltenheit)

[bla!zilla]

so ich habe das Raid jetzt hier bei mir im Büro stehen. Es sind 3,5 Zoll 2TByte Seagate SAS bzw. SATA Platten.

Ja was denn nun? SAS oder SATA?

Würde eigentlich folgende konstellation auch gehen: 2x Raid5 á 5 Platten + 2 HS
Macht 8 TB pro virtual Disk. Haben dan quasi zwei 8 TB Volumes die ich den 5 Blades zur verfügung stellen kann.

8 TB für ein VMFS halte ich für zu groß.

Es geht nur darum, das ich dem Kunden dann 2 optionen zur verfügung stellen kann.
Ich perönlich würde auch auf deine vorgeschlagene Raid 10 konfig tendieren. Weiß bloß noch nicht wie der Kunde reagiert wenn ich Ihm sage das bei der Raid 10 konfig, die hälfte des Storages flötten geht.

Ja frag ihn doch.

[MarcelMertens]

Als Systemanbieter sollte man den Kunden schon beraten.
Wenn du meinst ein RAID10 ist sinnvoller dann solltest du das den Kunden vernünftig argumentieren. Wenn der Kunde trotzdem der Meinung ist dass ein RAID5 ausreichend ist, wirds halt so gemacht und schriftlich festgehalten.
Ich kann nur konform gehen was Patrik schreibt. 2TB SATA Disks im Produktivbetrieb machen eingentlich wenig bis garkeinen sinn. Du bekommst zwar viel Speicherplatz aber dafür eine sehr schlechte Performance. Aus diesem Grund verwendet man bei solchen kleineren Installation ehr 300 oder 450GB SAS HDDs mit 10k.
Die 2TB SATA Disks sind eigentlich nur dann zu gebrauchen wenn ich viel Platz mit wenig Performance benötige (Archivsysteme usw).

[Skywalker]

hab ich das richtig gelesen? einen teuren fc switch aber billige 7,2k platten? was bringen dir 8gbit bei lahmen platten?
ich würde dann eher auf 10k oder 15k mit iscsi gehen.

kein backupsan finde ich auch schon grob fahrlässig. kauf dir lieber zwei kleine nonname san anstatt eines grossen. die kosten sind dann ähnlich, du bist aber deutlich flexibler unterwegs.

[MarcelMertens]

Was soll ein Backupsan sein?

[Skywalker]

ja einfach ein zweiter storage, egal ob jetzt standby oder produktiv.

[MarcelMertens]

ok, Backup Storage vestehe ich, Backup SAN ist für mich eine zweite Verkabelung (nicht zuverwechseln mit redundante Verkabelung).

Ein Plattenshelf ist ein SPOF. Aber die Daten sind ja durch ein RAID schon redundant. Wenn ich ein Vernünftiges Backup habe, welches außerhalb des Rechenzentrums gelagert wird muß ich mir die Frage stellen:

- Ist mir ein gespiegeltes/repliziertes Storage in einen anderen Brandabschnitt das Geld mehr Wert. Denn wann wird dieses nötig?Bei Brand/Wasser oder andere "höhere Gewalt" im RZ. Dann ist aber meistens alles andere auch hin. Ich hätte zwar meine Daten noch an einen anderen Ort, die Application Server, Client Switching, Verkabelung usw sind aber meistens nicht redundant.

[Skywalker]

jein, wenn man zwei kleine storage server kauft, ist das nicht automatisch doppelt so teuer.
das teuerste am storage sind die schnell drehenden platten. und die anzahl bleibt ja identisch.

ich meine: falls 16x platten insgesamt geplant sind. je einen server mit je 8x platten.

es ist sehr unwahrscheinlich das aus technischen gründen ein array ausfällt. aber so einfache dinge wie zb.: admin stolpert über patchkabel und und reist nic aus server, kaffeetasse fliegt um etc... alles schon vorgekommen

[bla!zilla]

jein, wenn man zwei kleine storage server kauft, ist das nicht automatisch doppelt so teuer.

Jeden wir jetzt von NAS oder SAN?

das teuerste am storage sind die schnell drehenden platten. und die anzahl bleibt ja identisch.

Dafür hast du deine Kapazität auf zwei Server verteilt.

es ist sehr unwahrscheinlich das aus technischen gründen ein array ausfällt. aber so einfache dinge wie zb.: admin stolpert über patchkabel und und reist nic aus server, kaffeetasse fliegt um etc... alles schon vorgekommen

Wenn sauber verkabelt ist, dann stolpert niemand über ein Kabel. Und Kaffee hat im RZ nichts zu suchen.

[MarcelMertens]

du meinst also verteilung der VMs auf zwei kleine Arrays statt auf ein großes?
Klar, ich fehlerfall verliere ich nur 50%, aber die anderen 50% sind offline.
Einfluss von außen ist sowieso irellevant, weil einen Autonomen Storage der seinen admin erschießt gibt es (leider) nicht . Daher ist die Betrachtung von Adminfehlern usw eigentlich außen vor (Bedienfreundlichkeit mal ausgenommen).

[Skywalker]

Jeden wir jetzt von NAS oder SAN?

spielt ja keine rolle, ob du auf der kiste direkt nen fileserver installierst oder ein san draus machst. der preis ist ja gleich. oder wie meinst du deine frage?

das teuerste am storage sind die schnell drehenden platten. und die anzahl bleibt ja identisch.

Dafür hast du deine Kapazität auf zwei Server verteilt.
--> stimmt, das muss man an die wünsche anpassen. hat vor und nachteile.

es ist sehr unwahrscheinlich das aus technischen gründen ein array ausfällt. aber so einfache dinge wie zb.: admin stolpert über patchkabel und und reist nic aus server, kaffeetasse fliegt um etc... alles schon vorgekommen

Wenn sauber verkabelt ist, dann stolpert niemand über ein Kabel. Und Kaffee hat im RZ nichts zu suchen.

-stimtm auch teilweise, damit wollte ich nur auf "faktor mensch" aufmerksam machen. ich hab mal nen stromkabel ausversehen gezogen weil mein hemd dran hängen geblieben ist. frag mich nicht wie so was passieren konnte. war zum glück ein redundantes netzteil.