iSCSI Storage Luns im Vsphere Umfeld

[Gelöschtes Mitglied 184103]

Hallo,

Wir haben eine Dell MD3200i + 2x MD1200 als neues Storage bekommen, das an 2 ESXer angeschlossen.
An Platten sind 24x 3TB 7,2k SATA Platten und 12x 600GB 10k SAS Platten an der MD angeschlossen.
Konfiguriert ist bisher ein Diskpool mit den 24 SATA Platten und ein Diskpool mit den 12 SAS Platten.

Geplant ist eine VM mit einer 30TB Lun für Bildablage und ein Oracle Datenbankserver.

Wie handhabt ihr iSCSI LUNS? Direkt der VM oder dem ESX zuweisen und dann einen Datastore erstellen bzw. als RDM-LUN durchschleifen (eine LUN muss 30TB groß sein für Bildspeicher Archiv, da geht ja nur RDM oder direkt der VM zuweisen)?

Getestet habe ich bisher VMDKs auf Datastore und direkt die LUN der VM zuzuweisen (RDM-LUN noch nicht).
Die Performance scheint so ziemlich identisch zu sein (habe mit HDspeed und Atto getestet).

Wie testet ihr eure Storage Performance am besten mit halbwegs realistischen Workload Szenarien was auch was zu Latenzen und IOPS sagt (IOMeter?)?

Wenn jemand noch tolle Tipps hat zur MD3200i immer her damit (bzgl. Cache Einstellungen, Blocksize, Raidlevel etc.)


MfG

Fahnder

 

[fdsonne]

Also von VMware gibts ne Appliance, die im Hintergrund IOMeter nutzt... Nennt sich VMware I/O analyser und bringt ein paar vorgefertigte Templates mit, sowie die Möglichkeit, geplante "Tests" auf das Storage loszulassen. Wäre ggf. ne Option.

Ansonsten hängt die Konfig massiv davon ab, was du genau machen willst.

Aber ja, du hast recht. Herkömmliche VMDK Files gehen wenn mich nicht alles täuscht auch in der 5.1er Version nur bis 2TB pro VMDK. Man könnte nun mehrere dieser anlegen und in der VM wieder zusammen packen -> Möglichkeit 1.
Alternativ eben RDM nutzen -> Möglichkeit 2
Oder direkt der VM das iSCSI LUN anhängen und den ESX ganz außen vor lassen -> Möglichkeit 3

Angeblich sollen RDMs etwas schneller sein, als die VMDK Variante. Ob sich das schlussendlich aber bemerkbar macht, steht auf nem anderen Blatt.

Da du aber von Bildablage schreibst, wäre eventuell interessant, was damit genau gemeint ist.

 

[Gelöschtes Mitglied 184103]

Hallo,

die Analyzer Appliance habe ich mir auch schon runtergeladen gehabt, bin bisher noch nicht dazu gekommen da mal reinzuschauen.
Die beiden ESX Server laufen noch unter 5.0 U2. Das Maximum bei VMDKs ist aber auch bei 5.1 leider noch 2 TB.
Der Vorteil von mehreren LUNs wäre, dass beide Controllereinheiten arbeiten würden und bei einer großen nur ein Controller. Da müsste ich aber mal schauen, ob der Controller überhaupt limitiert, denn ich habe je nur 4 dedizierte iSCSI GBit NICs in den ESXern (Jeder Controller hat 4 GBit NICs).

Bei der Bildablage geht es um Röntgenbilder und CT Aufnahmen, die von den medizinischen Geräten dort abgelegt werden sollen und dann auf wenigen (~10) Clients betrachtet werden können.

Interessanter wird es da schon bei den Datastores für die Datenbankserver.
Aus den 12 600GB SAS Disks muss ich einen 3TB Speicherbereich erstellen, der möglichst schnell ist. Als Raidlevel bietet der MD3200 0,1,5,6,10 oder einen Diskpool, der wohl ähnlich wie Raid 6 arbeiten soll aber schnellere Rebuildzeiten hat (soll sich erst ab 20+ Disks bemerkbar machen pro Pool). Raid 10 wäre da denke ich die beste Wahl oder?
Und dann gibts noch Einstellungen zu Sektorgrößen, da wäre bei den Bilddaten die größte und bei der Datenbank eher eine kleine sinnvoll?

Ach ich seh gerad in der Software ist auch eine Performance Analyse Funktion drin.
Werd ich mal morgen noch ein bisschen testen.

 

[fdsonne]

Das Raidlevel sollte nach dem Workload gewählt werden. Raid 10 wird wohl ohne irgendwelche Sonderlocken ala Caches usw. am schnellsten für Random 4-8k DP Zugriffe agieren. Auch erhöht man idR die IOPS sowohl beim lesen als auch beim schreiben mit der HDD Anzahl.
Das größere Problem könnten die 30TB für die Bilder werden.
Man macht einfach kein Raid 5 oder 6 über so viele HDDs am Stück. Einfach weil die Ausfallwarscheinlichkeit doch steigt... Dazu dürfte ein Rebuild im Fehlerfall wohl extrem lange dauern bei 24x3TB HDDs.
Das ganze klingt für mich aber fast (außer dem DB Teil) nach ner simplen Fileablage und eventuell wäre man hier besser beraten, wenn man sich da nen anständigen Unterbau in Sachen OS beschafft, der beispielsweise ZFS kann. Um vor allem auch die Vorteile im Bezug auf das Filesystem nutzen zu können. Das ganze kann dann zwar auch virtuell ablaufen, nur gibts ggf. bei der Umsetzung ein paar Sachen zu beachten.

Thema Anbindung, hier kommt es drauf an, was dir da wichtig ist.
Man könnte ne Art Portbündlung realisieren mit den 2x4 NICs für die iSCSI Anbindung. Da du aber von 4 NICs sprichst, schaut das für mich nach 1GBit Interfacens aus. -> was auch gleichsam den Nachteil hat, das eben entsprechend viele gleichzeitige Zugriffe von nöten sind, um überhaupt mehr wie 1GBit Speed zu bekommen.
Beachten sollte man, wenn möglich, die iSCSI Infrastruktur vom Rest der Netzwerkanbindung physisch zu trennen. Bestenfalls eigene Switches, damit eben keine Lastenprobleme entstehen.
Auf den ESXen kann man mehrere NICs über mehrere "Serviceskonsolen" redundant und/oder loadbalanced konfigurieren -> um vor Ausfällen bei der iSCSI Anbindung zu schützen. Dann sollte man aber auch mindestens zwei Switches haben, wo der Traffic drüber läuft und sowohl das Storage, als auch die ESXen doppelt redundant dort anbinden. (also je mindestens einen Port pro ESX und Storage an je mindestens einen Switch) -> das ganze dann auf ESX Seite mit zwei Pfaden konfigurieren. Per default im Software iSCSI Initiator geht das eigentlich ganz simpel. Wenn du Hardwarebased iSCSI Initiatoren verwendest, müsste man schauen, wie man das dort konfiguriert...


PS: weil du es oben ansprachst, es arbeiten nicht per se beide Controllerkarten am Storage
Das muss eingestellt werden, sofern es überhaupt geht! Denn für gewöhlich wird bei solchen "Einsteiger-Storages" immer nur jeweils eine "Raidgruppe" von einem Controller verwaltet. Also ein Controller kann mehrere Raidgruppen verwalten, aber eine Raidgruppe kann nur von einem einzigen Controller verwaltet werden. Im Fehlerfall des Controllers switcht das Gerät zum anderen. Es laufen aber nicht beide gleichzeitig!
Und je nach ESX Konfiguration kann es sogar passieren, das der Host jeweils nur immer einen Controller selbst anspricht. Hier muss man definitiv aufpassen, sonst erzeugt man künstlich Flaschenhälse durch mehrfaches und unnötiges Switchen der Controller.
Wichtig ist auch vorher! zu überlegen, was in Sachen Ausfällen alles verkraftbar sein soll. Ich glaube zu wissen, diese Dell Büchsen sind alle samt nur Active/Passive Modelle. Im Falle eines Ausfalls vom Controller selbst oder des Pfades zum Controller, sollte also auch einkalkuliert werden, dass dies vertretbar ist...

EDIT: aber mal was anderes...
Wieso eigentlich iSCSI?
Ich mein, 1GBit bei iSCSI und dann 30TB+ an Kapazität? -> das dauert ewig bis man die Daten da drauf hat, weil schlicht das Interface extrem zeitig limitieren wird. Da hilft wie angesprochen nur, die Disks in kleinere Stückchen den ESX Hosts zu servieren um möglichst alle Pfade auch belegen zu können. Aber selbst dort wird es wohl bei zwei ESXen bei maximal zwei gleichzeitigen Pfaden bleiben
Die beiden angesprochen DAS Lösungen haben da zumindest den Vorteil der deutlich schnelleren Anbindung... Mehr geht halt bei iSCSI nur mit 10GBit Infrastruktur. Nur kost das in Summe dann mindestens so viel wie 8GBit Fiberchannel -> und ist in Sachen Latenz und Ansprechverhalten sogar noch ein kleines Stück weit langsamer.

 

[Gelöschtes Mitglied 184103]

Hallo,

erstmal Danke für die Antwort

Das mit den 24 Platten als einzelnes Raid 6 machte mir auch Bauchschmerzen, aber es ist kein richtiges Raid 6.
Dell nennt das Dynamic Disk Pool und so wie ich die Whitepaper verstanden habe, ist das ganze minimal langsamer als klassisches Raid 6 hat aber gerade den Vorteil, wesentlich schnellere Rebuildzeiten zu haben.

Warum man nicht einfach DAS genommen hat auf dedizierten Servern weiß ich nicht.

Die beiden ESXer stehen in unterschiedlichen Räumen. Jeder ESxer hat eine zusätzliche Quadport GBit NIC bekommen.
Es wurden 4 Switche mitgeliefert und davon sind 2 pro Raum verbaut.

Die DELL steht in Raum 1 und beide Controller sind mit je 2 Ports auf einem der Switche angeschlossen.
Der ESX dort ist mit je 2 Ports an beide Switches angeschlossen.

Per Fibre sind die Switches miteinander verbunden und der 2. ESX ist mit je 2 Ports an beiden Switches in Raum 2 angeschlossen.

Die 4 NICs auf den ESXern sind als jeweils als eigener VMKernel Port in unterschiedlichen Subnetzen und VLANs konfiguriert. Jumboframes und Flowcontrol ist auch aktiv.
Jeder ESX sieht zu jeder LUN 8 Pfade, wobei die DELL Aktiv/Passiv ist, also immer nur ein Controller eine LUN verwaltet und nur bei Fehlern umgeschwenkt wird, so dass pro LUN immer nur maximal 4 Pfade aktiv und 4 Pfade Stand-by sind.
Das Teaming scheint auch zu funktionieren, so ca. 350MB/s sind lesend drin.

Hier mal die Skizze aus dem Dell VMware Guide zu dem Teil: http://img5.fotos-hochladen.net/uploads/verkabelungisc7icu51oja2.png

Habe das von der Konfiguration alles so gemacht, wie die Dellis das vorgeschlagen haben, hoffentlich läuft das.

Naja ich habe jetzt erstmal 3 Wochen Urlaub. Mal schauen, was das so gibt


MfG

Fahnder

edit:
Da ich hier zu Hause meinen Openindiana ZFS Filer schätzen gelernt habe, wäre so eine ZFS Storage Büchse für mich natürlich sehr interessant gewesen, aber da wir unsere HW von "oben" geschickt bekommen, hatte ich da nix zu entscheiden