Empfehlung/Erfahrungsbericht Storage für ESX im Unternehmen

[Crow]

Moin zusammen,

ich überlege mal ein Konzept zu erarbeiten welches unsere "historisch" gewachsene Server- und Storagestruktur auf einen performanteren sowie einfacher zu administrierenden Stand bringt.

Grundentscheidung ist definitiv zu einer vollständigen Virtualisierungslösung aus dem Hause Vmware gefallen... wir setzen zwar schon eine vollständige Virtualisierung auf Citrix XenServer Basis in einem unserer RZ´s ein jedoch war das damals eher eine politische Entscheidung... nunja egal worum gehts?

Ich suche derzeit nach Leuten die mir mit Erfahrungsberichte bzw. Empfehlungen im Bereich des Storage weiterhelfen können! Leider gibt es gerade im prof. Bereich viel zu wenig Tests / Reviews...

Benötigt werden nach ersten Schätzungen rund 4 TB wobei durchaus 7,2k SATA und 15k SAS gemischt werden könnten! Virtualisiert werden MS 2003 DC´s, Exchange 2000 (2010 ist geplant), Warenwirtschaftssysteme, SalesLogix als TicketSystem, W2k3 FileServer, Terminalserver, div. Clientbetriebssysteme als Testmaschinen zur Softwareentwicklung, etliche Datenbankserver zum Test und Entwicklung etc... das Übliche!

Durch die Installation/Administration einer HP MSA2000fc kenne ich zumindest das Gerät schon sehr gut - Geschwindigkeit ist soweit gut aber die Administration ist eine Katastrophe... die Weboberfläche ist ein Witz!

Netapp habe ich letztens bei zwei Veranstaltungen kennengelernt... coole Ideen und augenscheinlich auch fähige Mitarbeiter... Preislich aber imho für uns indiskutabel...

So nun kommt ihr ins Spiel

Wer kann mir mit Erfahrungen weiterhelfen? Interessant wäre natürlich auch immer der grobe Preis einer dargestellten Lösung!

Danke schonmal


Grüße
Kai

 

[Morpheus2200]

Wie willst du das Storage denn anbinden? Über iSCSI?
Brauchst du da nur nen Datastore-Bereich für deine ESX(i) Server oder sollen die VMs direkt aufs Storage zugreifen?

Netapp bietet viele features die du wenn du nur Platz für VMs brauchst nicht brauchst aber mitbezahlst.

Mach dir mal eine Liste an Anforderungen und welche features interessant sind, auf der Grundlage kannst du dir ein passendes Gerät aussuchen. Jede Empfehlung die ich auf basis deiner Informationen geben kann ist wertlos.

Was musst du (im Betrieb?) vergrößern/verkleinern können? (luns volumes oder agregate)
Performanceanforderungen?
Budget?
Wie oft musst du an die Kiste ran und was an der Storage-Aufteilung ändern?
Muss das Storage wachsen können?
Wie läuft das Backup?
Was kennst du außer der HP Kiste?
Welche RAID-level willst/musst du fahren?

 

[Crow]

Wie willst du das Storage denn anbinden? Über iSCSI? iSCSI ist geplant - FC wird denke ich aufgrund der Infrastruktur deutlich teurer
Brauchst du da nur nen Datastore-Bereich für deine ESX(i) Server oder sollen die VMs direkt aufs Storage zugreifen? Nur die VM´s sollen auf dem Storage laufen

Netapp bietet viele features die du wenn du nur Platz für VMs brauchst nicht brauchst aber mitbezahlst.

Mach dir mal eine Liste an Anforderungen und welche features interessant sind, auf der Grundlage kannst du dir ein passendes Gerät aussuchen. Jede Empfehlung die ich auf basis deiner Informationen geben kann ist wertlos.

Was musst du (im Betrieb?) vergrößern/verkleinern können? (luns volumes oder agregate) puh naja kann man das vorher abschätzen? Ich denke wenn dann vergrössern
Performanceanforderungen? muss kein absolutes High End sein - Firma hat ca 80 User
Budget? denke mal max 10-12k - Leasing find ich interessant - Erfahrungen?
Wie oft musst du an die Kiste ran und was an der Storage-Aufteilung ändern? selten
Muss das Storage wachsen können?jupp
Wie läuft das Backup? derzeit noch auf Band - denke später auf ein günstigeres NAS
Was kennst du außer der HP Kiste? aktiv nichts - nur in der Demo von Netapp
Welche RAID-level willst/musst du fahren? Bis jetzt immer RAID-5 - überlege aber auf RAID-1/10 zu gehen? Verspreche mir mehr Dichte pro RAID?

Ich hoffe das reicht dir erstmal

 

[H_M_Murdock]

Für den VM-Betrieb wird oft RAID 10 empfohlen, gerade auch von erfahrenen Experten und auch theoretische Zahlen belegen die höhere I/O bei gleicher Plattenanzahl von einem RAID 10 gegenüber einem RAID 5/6.
Aus persönlicher Erfahrung kann ich dazu mangels Vergleich leider nichts sagen aber es wird wohl was dran sein.

Gerade was die Storage-Planung angeht kann ich dir die Lektüre folgenden Buches empfehlen -> Link
Dort wird nicht nur auf die Eigenheiten mancher Storagelösung eingegangen sondern auch Empfehlungen zur Storageinfrastruktur (auch iSCSI) gegeben und welche grundlegenden Unterschiede es zwischen unterschiedlichen Storage-Produkten gibt.
Auch wie man das ganze dann am vernünftigstem am ESX konfiguriert wird natürlich beschrieben.

Wir verwenden hier @work in unserer Umgebung mit 2 ESX Servern ein Fujitsu Eternus DX60 das per iSCSI angebunden ist.
Da sind jetzt 8x 450 GB 15k SAS Platten drin die im RAID 6 laufen mit knapp 30 VMs drauf.
Allerdings ist nicht viel dabei was massiv I/O verlangt, sehr viele Clientsysteme haben wir virtualisiert, 2 Druckserver, 2 Webserver mit recht wenig Aktivität, DNS, DHCP.
Von dem her war RAID 6 nicht wirklich ein Fehler, Performancengpässe haben wir auch noch keine bemerkt.

Dabei muss ich im Nachhinein sagen (auch nachdem ich jetzt das Buch kenn) dass wir ein paar Fehler gemacht haben.

So ein Eternux DX60 ist eine der preiswerteren Lösungen und kann auch noch um ein Shelf für zusätzliche 12 Platten erweitert werden.
Soweit ich mich erinnern kann lag unsere Lösung genau in deinem Preisbereich.

Zur Administration kann ich leider nicht wahnsinnig viel sagen weil wir das Ding nur einmal eingerichtet haben und dann wars gut.
Hin und wieder legen wir halt weitere Volumes an (wir halten uns an die Grundregel nicht mehr als 10 VMs pro Volume was auch sinnvoll ist wegen der SCSI Locks).

 

[Crow]

Für den VM-Betrieb wird oft RAID 10 empfohlen, gerade auch von erfahrenen Experten und auch theoretische Zahlen belegen die höhere I/O bei gleicher Plattenanzahl von einem RAID 10 gegenüber einem RAID 5/6.
Aus persönlicher Erfahrung kann ich dazu mangels Vergleich leider nichts sagen aber es wird wohl was dran sein.

Gerade was die Storage-Planung angeht kann ich dir die Lektüre folgenden Buches empfehlen -> Link
Dort wird nicht nur auf die Eigenheiten mancher Storagelösung eingegangen sondern auch Empfehlungen zur Storageinfrastruktur (auch iSCSI) gegeben und welche grundlegenden Unterschiede es zwischen unterschiedlichen Storage-Produkten gibt.
Auch wie man das ganze dann am vernünftigstem am ESX konfiguriert wird natürlich beschrieben.

Wir verwenden hier @work in unserer Umgebung mit 2 ESX Servern ein Fujitsu Eternus DX60 das per iSCSI angebunden ist.
Da sind jetzt 8x 450 GB 15k SAS Platten drin die im RAID 6 laufen mit knapp 30 VMs drauf.
Allerdings ist nicht viel dabei was massiv I/O verlangt, sehr viele Clientsysteme haben wir virtualisiert, 2 Druckserver, 2 Webserver mit recht wenig Aktivität, DNS, DHCP.
Von dem her war RAID 6 nicht wirklich ein Fehler, Performancengpässe haben wir auch noch keine bemerkt.

Dabei muss ich im Nachhinein sagen (auch nachdem ich jetzt das Buch kenn) dass wir ein paar Fehler gemacht haben.

So ein Eternux DX60 ist eine der preiswerteren Lösungen und kann auch noch um ein Shelf für zusätzliche 12 Platten erweitert werden.
Soweit ich mich erinnern kann lag unsere Lösung genau in deinem Preisbereich.

Zur Administration kann ich leider nicht wahnsinnig viel sagen weil wir das Ding nur einmal eingerichtet haben und dann wars gut.
Hin und wieder legen wir halt weitere Volumes an (wir halten uns an die Grundregel nicht mehr als 10 VMs pro Volume was auch sinnvoll ist wegen der SCSI Locks).

Danke für die Buchempfehlung! Ich schau mal ob die Firma mir das bezahlt

Die Eternus DX60 habe ich mir auch schonmal angeschaut - unser Hardwarelieferant ist auch Fujitsu-Händler.. maybe frag ich den einfach mal was sowas kosten würde!

Ihr habt also ein RAID-6 über die 8 Platten und dann 3-4 Volumes darin? Ich hab bis jetzt immer kleinere RAID Gruppen gemacht weil ich dachte somit die iops der einzelnen RAID Gruppen zu maximieren? Somit hab ich auf einem RAID-5 Last aber die anderen haben noch Reserven um auch noch Lastspitzen abzufangen? Oder ist das die falsche Herangehensweise?


Grüße
Kai

 

[H_M_Murdock]

Wir sind aktuell glaub ich bei ca. 6-8 Volumes, muss später mal nachschauen.
Alles auf einem einzigen RAID 6 Verbund.

Ich denke dass deine Intension durch mehrere RAID Gruppen die I/Os pro RAID zu beschränken auch nicht falsch ist.

Prinzpiell gibt es halt 2 Faktoren die zu beachten sind.
Das ist einmal die gesamte I/O Last die du durch die VMs hast und zum anderen die SCSI Locks (gerade die Thematik ist in dem Buch gut erklärt).
SCSI Locks heißt im Prinzip dass bei bestimmten Vorgängen auf dem VMFS Volume der Zugriff aufs komplette Volume kurzzeitig gesperrt ist und je mehr VMs du drauf liegen hast desto mehr Locks hastd u.
Eine erhöhte Anzahl SCSI Locks hast du vor allem auch durch den Einsatz von Thin Provisioning bei VMDK Files und der intensiven Nutzung von VM Snapshots, weshalb auch allgemein dazu geraten wird damit sparsam umzugehen.

Das ist im Prinzip das ganze Geheimnis warum man nicht zu viele VMs pro Volume betreiben soll.

In wie weit das aufteilen einer großen Anzahl Platten in mehrere RAID Verbünde sinnvoll ist oder nicht kann ich dir leider nicht beantworten.
Dass ein RAID Verbund aus 12 Platten mehr IOPS macht als eines aus 6 Platten ist dir sicherlich klar.
Evtl machts ja Sinn einen RAID Verbund zu erstellen auf dem nur wenige I/O intensive VMs laufen und den Rest anderweitig unterzubringen, aber wie gesagt haben wir in unserer Umgebung weder VMs die übermäßig viel I/O Last erzeugen noch bisher - trotz einer RAID Konfiguration über die man sicherlich streiten kann - mit Performanceproblemen zu kämpfen gehabt, deshalb kann ich leider auch nur das nachplappern was ich gehört und gelesen hab, da können dir hier andere sicherlich weiter helfen.

Lt. dem VMWare Buch gibts Storage-Systeme (HP EVA wars glaub ich) bei denen ein RAID Verbund immer über sämtliche Platten angelegt wird (wobei die Platten jeweils nur zum Teil für einen RAID Verbund genutzt werden) was den IOPS enorm auf die Sprünge hilft. Du hast also meinetwegen 500 Platten im System, legst einen RAID Verbund mit 500 GB an und dann liegt auf jeder Platte 1 GB davon.

Da gibts sicherlich wieder Systemspezifische Unterschiede.

 

[fdsonne]

Ich kann hier vllt auch meine Erfahrungen preisgeben...

Wir hatten bis Herbst 2009 eine MSA2012i (Dual Controller iSCSI) mit getrunkter iSCSI Anbindung sowohl auf ESX als auch auf Storage Seite.
HDDs waren 3x300GB SAS 15k im Raid 5 für die Betriebssysteme sowie 6x750GB SATA 7.2k im Raid 5 als Datenpartitionen.

Die Performance war in meinen Augen unter aller Sau. Rein der normale Betrieb lief ganz brauchbar, die Zugriffe auf den Fileserver (ca. 700GB auf dem Raid 5) gingen brauchbar fix. Größere Probleme mit unangebehmen Wartezeiten gab es im Bereich Datenbank Server sowie Exchange. (welche ebenso auf diesem einen Raidvolume lagen)

Nach einem größeren Umbau ist es jetzt eine MSA2312fc (Dual Controller FibreChannel 8GBit)
Das ganze ist um längen fixer...
Dabei sind 8x450GB SAS 15k, zwei Raid 10 Arrays mit je vier HDDs sowie 4x750GB SATA 7.2k im Raid 5 für die Daten.
Alle Betriebssystempartitionen der ca. 30 VMs liegen auf dem ersten Raid 10 Array. Datenpartitionen der Datenbank/Exchange Server liegen auf dem zweiten Raid 10 Array und die Fileserver/Nutzerdaten liegen auf dem Raid 5 Array.

Wie angesprochen, durch die FC Anbindung hat sich der Speed gerade bei vielen gleichzeitigen Zugriffen massiv verbessert.


Ich Rate in derartigen Größenordnungen schon zu FC. FC ist nicht wirklich viel teurer. Bringt in meinen Augen aber deutlich mehr Performance mit sich...
Solange man nur ein Storage sowie ein ESX im Einsatz hat, kann man auch auf die FC Switches verzichten und die Storage Library direkt an den Server anbinden.
Uns hat die MSA inkl. zweier FC Switches, sowie drei HBAs und den 8x450GB SAS HDDs ich glaube im Bereich 15-17k€ gekostet. Rein Listenpreistechnisch offiziell das doppelte Da sind dann deine Einkäufer gefragt in die Preisverhandlungen mit dem Händler zu gehen...



Grundsätzlich bleibt bei der Planung wohl zu erwähnen. Es macht Sinn die HDD Arrays aufzusplitten um die Last möglichst gut zu verteilen.
Im VM Umfeld zählen massiv die Zugriffszeiten. Wenn man also langsame HDDs nimmt, kann eine einzige VM schon das komplette Storage lahm legen... Sehr ungünstig
Ebenso macht es halt Sinn was Datenbanken/ExchangeServer sowie Betriebssystempartitionen anbelangt auf schnelle SAS HDDs oder SSDs zu setzen. Um die Random Zugriffe möglichst gut abfedern zu können.
Und noch ein wichtiger Punkt ist die RAM Ausstattung des ESX Servers. Hat dieser zu wenig RAM, so wird geswappt, das ist extrem Performancevernichtend aber noch auszuhalten. Viel schlimmer ist es, wenn die VM selbst anfangen muss zu swappen, sprich das Windows in der VM selbst massiv die Auslagerungsdatei nutzen muss. Denn das drückt das Storage massiv in die Knie und sowas kann man selbst nicht mit super fixen SSDs abfangen und macht vieles zu nichte... Hier ist mehr RAM also wirklich manchmal Gold wert anstatt das Storage unnötig aufzublasen...


Womit ich unsere ESX Server oder besser das Storage aber immernoch klein kriege sind ESX Host Updates und darauffolgend das Update der VMWare Tools.
Bei uns sind alle VMs auf drei ESXen aufgeteilt. Aber das Storage ist physisch immer das gleiche. Wenn ich also die VMWare Tools update will jede VM idR danach einen Reboot haben... Selbst bei nur 5-7 VMs gleichzeit beim Booten macht das Storage schon schlapp. Bootzeiten von teilweise 30min und mehr pro VM sind dann keine Seltenheit. Das Problem liegt wohl daran, das eben beim Booten erstmal nichts im RAM ist und alles von der HDD geladen werden muss. Gerade größere SQL/Exchange Server erzeugen erstmal massive Last dabei.
Man sollte also aufpassen hier nicht zu übertreiben mit dem gleichzeitigen Boot bzw. mit gleichzeitigen Aktionen. Ansonsten wenn sich das alles eingependelt hat, so läuft das alles sehr sehr fix...

 

[jraf]

Ich würde mich an dieser Stelle fdsonne anschliessen, kann die Aussagen im Wesentlichen bestätigen. Wir haben hier im Unternehmen darauf verzichtet, die Datenbankserver zu virtualisieren - wir benötigen eine sehr gute Performance bei vielen großen Datenbanken. Dies ist unserer Erfahrung nach unter VMWare nicht bzw. nur mit großem Aufwand zu realisieren (extrem performante Speichersysteme und Infrastruktur nötig).

Wenn wirklich alle Systeme virtualisiert werden sollen ist ein Speichersystem mit möglichst vielen, schnellen SAS-Festplatten und Multichannel FC-Anbindung die erste Wahl.

 

[Crow]

Hallo zusammen,

danke schonmal für eure Erfahrungen aus dem Alltag

Da ich derzeit von einer Reihe von Dell Servern positiv überrascht bin hab ich mich dort auch mal umgeschaut und dabei folgende Config zusammengestellt:

1x MD3200i (iSCSI) 12x600GB SAS 15k für ca 12.000€

Hat jemand Erfahrungen mit der Einstiegsserie von dem Dell Storage?

Und zum Thema iSCSI vs FC: Wie ich schon sagte war ich vor einigen Wochen bei Netapp in Düsseldorf - dort war der Tonus "Besser iSCSI da FC schwieriger zu beherrschen ist und selten wirklich spürbar schneller ist" ... Mit bei der Veranstaltung war noch ein Techniker von Netapp der diese Aussage auch untermauert hat?


Grüße
Kai

 

[fdsonne]

Ja was heist schwieriger zu beherschen!? Diese Aussage halte ich für Unfug... Im Grunde ist es das gleiche in Bund. Nur eben mit LWL. Wirklich viel anders ist es nicht.

Was halt hinzukommt. Wenn man ein kleines System hat, wo die Datenrate mit ca. 100MB/sec+- am Ende ist, wird man sicher keine Performancezuwächse spüren. Ebenso wo es nicht wirklich viel und stark auf Zugriffszeiten ankommt.
Das Problem bei iSCSI ist in meinen Augen ebenso die Latenz. Das ganze ist nach wie vor Ethernet und da gibt es einen recht großen Overhead, der bei FC wegfällt (zumindest fast) Und das 1GBit Problem bekommt man nicht durch Trunken weg... Zumindest nicht so einfach. Da helfen nur richtig 10Gbit NICs bzw. ein 10GBit Controller. Aber das treibt den Preis wieder massiv in die Höhe und stellt andere Anforderungen an den Switch.

FC hat rein vom Speed her mit 4GBit schonmal das vierfache an möglicher Datenrate zu bieten. Mit 8GBit das achtfache.
Nur mal blöd angenommen, du willst ein Backup to Disk fahren. So schafft dein iSCSI Produkt im wirklichem max. 125MB/sec. Das drücken die im Beispiel 12 SAS 15k Platten spielend nebenbei ab.
Mit FC kannst du hier die 4GBit locker ausfahren...

Ich fahre hier meine ESX Backups über ein Script mit VCB direkt vom Storage auf unseren Backup Server (der hat nen FC HBA) mit weit über 300MB/sec schreibend auf das Backup Volume... Mit iSCSI von der alten MSA sind da gerade mal um die 100MB/sec drin. Trotz identischer HDDs aus der gleichen Serie...



Aber mal was anderes, was ist denn an der Weboberfläche der MSA eine Katastrophe? Auch wenn ich mich damit auch nicht richtig anfreunden kann, weil vieles bisschen versteckt ist, wenn man weis wo man klicken muss, geht das locker von der Hand...
Und rein funktional ist das Ding auch sehr brauchbar... Ansonsten halt per CLI, wem das besser gefällt. Kabel wird ja mitgeliefert... das ganze gepaart mit nem RS232 TerminalServer erreichbar über SSH/Telnet geht das auch über Remote zu steuern...

 

[Crow]

Naja meine WebGui sieht wie im Anhang zu sehen aus... das finde ich schon echt nicht mehr zeitgemäß! Zumal viele Einstellungen wirklich versteckt und/oder unsinnig positioniert sind. (imho)

Grüße
Kai

 

[fdsonne]

ja was erwartest du?
Ob die Optik schick ist oder nicht ist doch das nebensächlichste was es überhaupt gibt... funktionieren muss es... Und ganz ehrlcih, ich nutze lieber so ne altback Optik als irgendwelchen neumodischen Java sonstwas Mist, wo erstens das subjektive Arbeitsempfinden unter aller Sau ist und vor allem, wo ich noch irgendwelche Software brauch damit das überhaupt erstmal aufgeht und ich das nutzen kann...

Ich hatte das Vergnügen gestern erst mit der NetSightSuite von Enterasys. Alles schick alles gut, alles Java
Das ganze unter Windows 7 x64 zum laufen zu bringen ist ein Krampf. Was hat geholfen, viertuelles XP (also den XP Modus von 7)
Der letzte Husten ist sowas...

Vor allem wenn man über Remote verbunden ist, womöglich irgendwo im Hinterland, über ne grottige 56k oder GPRS Handyverbindung, da ist alles was Bund ist das letzte, was man gebrauchen kann...

 

[Crow]

Naja ich erwarte auch kein Java um Gottes willen aber nen bischen hübscher und logisch geordnete Optionen sind auch nicht so schlimm... Aber gut warscheinlich ist das Geschmackssache!

Edit: hier mal nen Video von nem Client zum Dell MD3200 *klick*
Irgendwie spricht mich sowas deutlich mehr an... hübsch, logisch aber dabei nicht überfrachtet! Frage ist nur ob die Dell Kisten was
können

Grüße

 

[fdsonne]

Naja ich erwarte auch kein Java um Gottes willen aber nen bischen hübscher und logisch geordnete Optionen sind auch nicht so schlimm... Aber gut warscheinlich ist das Geschmackssache!

Edit: hier mal nen Video von nem Client zum Dell MD3200 *klick*
Irgendwie spricht mich sowas deutlich mehr an... hübsch, logisch aber dabei nicht überfrachtet! Frage ist nur ob die Dell Kisten was
können

Grüße

Das ist aber kein Webtools sondern eine Software so wie ich das sehe... Sprich das ist nicht direkt im Browser aufgemacht.
Wenn das durch ein Webzugriffstools geladen wird, dann definitiv Java

Und wie gesagt, ob das nun hübsch ist oder nicht sollte dem Systemadmin ziemlich egal sein.

Übrigens, HP bietet sowas auch an, ob nun für die MSA2000 auch weis ich nicht, aber die internen Controller haben auch so ein klicki bunti Verwaltungstool für Windows im Lieferumfang...
Für die 2312fc sieht die Weboberfläche übrigens so aus:

 

[Morpheus2200]

Wie viele ESX Kisten habt ihr eigentlich?

Wenn VMs anfangen zu swappen kann man den Effekt ein bisschen mit lokalem Storage am ESX abfedern. Swap partitionen einfach direkt vom ESX-Datastore (lokale Platten) nehmen und man macht sich das richtige Storage nicht dicht. Probleme gibts da nur beim Transfer ganzer VMs zwischen mehreren ESX-Servern. Aber eigentlich sollte man dem besser mit viel RAM vorbeugen.

Dell ist nicht gerade mein Lieblingshersteller wenn es um Storage geht, kann daran liegen das ich bei Einstiegsprodukten bei Problemen erstmal nach Firmwarestand gefragt werde und wenn der nicht aktuell sondern unglaubliche 2 Monate alt ist (gibt ständig neue war mein Eindruck) gibts keine wirkliche Hilfe bis das System auf den aktuellen Stand gebracht wird. Natürlich ist damit immer eine downtime verbunden.

Denk mal an das Horrorszenario wenn das Storage steht und schau dir genau die Supportkonditionen an. Bei uns gabs nach dem Gedankenspiel als zentrales Storage dann doch nen etwas teureren Netapp Toaster, der hat auch schon nen Stromausfall ohne Probleme überstanden und lief ein knappes Jahr problemfrei ohne unterbrechungen. 1 oder 2 HDs wurden in der Zeit getauscht.
Für ISCSI ist ne Netapp eigentlich verschwendung, aber storage kann man besser beim Storage-spezi kaufen, der lässt einen auch nicht im Regen stehen wenn dann doch mal was dran ist.

Wenns doch nen reines SAS RAID wird hast du vielleicht auch noch nen bisschen Reserve für nen Rebuild.
Ich hab mich letztens mit jemandem von DataDirect unterhalten, die können rebuilds ohne Performance-einbußen.
Damit musste der natürlich ein bisschen prahlen, aber da ist mir mal aufgefallen wie blöd das in performance-kritischen Bereichen kommt wenn ständig 1-2TB HDs rebuilded werden (die bauen größere Kisten wo dann über Zeit natürlich auch mehrere Platten ausfallen).
Dauert ja schon ne weile. Sollte man auf jeden Fall berücksichtigen, denn eine HD kanns immer mal erwischen. Schön das man dann noch die Daten hat aber wenn man ohne das es unerträglich langsam wird weiterarbeiten kann ists noch schöner

 

[Crow]

Das ist aber kein Webtools sondern eine Software so wie ich das sehe... Sprich das ist nicht direkt im Browser aufgemacht.
Wenn das durch ein Webzugriffstools geladen wird, dann definitiv Java

Und wie gesagt, ob das nun hübsch ist oder nicht sollte dem Systemadmin ziemlich egal sein.

Übrigens, HP bietet sowas auch an, ob nun für die MSA2000 auch weis ich nicht, aber die internen Controller haben auch so ein klicki bunti Verwaltungstool für Windows im Lieferumfang...
Für die 2312fc sieht die Weboberfläche übrigens so aus:

Also die Weboberfläche ist doch schon viel ansprechender! Ohne KlickiBunti
Erinnert mich an die unseres C3000 Blade Centers!

@Fr@ddy:

Derzeit haben wir 3x ESXi Kisten mit lokalem SATA Storage.. darauf laufen 43 VMs! Wobei man sagen muss das wir Software entwickeln ergo extrem viele Testdatenbankmaschinen und/oder Clients brauchen! Das 100%ig gelbe vom Ei ists aber trotzdem nicht da nunmal auch schon einige richtige Produktivserver (interne Warenwirtschaft, Terminalserver für Aussendienst etc) darauf laufen.. Performance ist ok aber nicht immer berauschend...

Unsere restlichen ca 15 Server sind derzeit noch physikalisch... ich plane 5 1HE ESX Host´s mit eben dem zentralen Storage um die Performance und Administrationsfähigkeit wieder auf sehr gutes Niveau zu bringen!


Grüße
Kai

 

[fdsonne]

Das Problem wird aber dennoch sein. Wenn du aus jetzt 3 ESXen + 15 physischen Server mit je eigenem Storage nun 5 ESXen mit einem einzigen zentralen Storage machst, das eben dieses Storage richtig Bumms haben muss, damit der Schuss nicht nach hinten los geht.

Gerade Datenbanken sind nicht sonderlich gut performant in virtuellen Umgebungen. Man kann das ganze etwas eindämmen über RAW Device Mapping aber erkauft sich damit auch Nachteile.

Wenn es vorrangig um DBs geht würde ich wohl einen dicken Datenbankserver mit ordentlich internem Storage hinstellen, zur Not auch zwei geclustert im Load sharing Mode oder ähnliches um die Last zu verteilen und ein physisch zentrales Storage für eben die DBs.
Ob das ganze über iSCSI gut geht ist in meinen Augen fraglich. Grade DBs stehen auf niedrige Latenzen und das ist bei iSCSI in meinen Augen so im Vergleich zu FC nicht gegeben...

 

[Morpheus2200]

Da habe ich ähnliche bedenken.
Kannst du produktiv und Testsysteme nicht trennen?

Gerade test-DB-Server die auch mal richtig load abbekommen können dir eine iSCSI Lösung ganzschön dicht machen.
Wäre doch schade wenn die produktivsysteme darunter leiden oder?

Also ich hab hier alles wo keine kritischen Daten liegen wenn möglich auf lokales Storage verfrachtet. Hab von den Maschinen noch ein Backup und wenn mal was passiert hab ich die Kisten in x minuten wieder online.

Alles was produktiv und wichtig ist kann auf iSCSI devices unseres zentralen Storages zugreifen. Mag nicht schön sein, aber die performance leidet nicht so extrem.

Greif lieber zu einer FC Lösung und log und analysiere einfach mal was deine Kisten an IO verursachen.
Mit flotter Hardware und viel Geld kannst du IO vielleicht um Faktoren zwischen 2 und 5 verbessern aber wenn du da aber jetzt 3-4 mal so viele VMs wie bisher drauf zugreifen lässt gewinnst du da wenig.
Bekommst eher noch Probleme da es halt immer mal wieder Fälle gibt, wo eine Kiste sich nimmt was da ist und dann gucken die anderen in die Röhre.

VMs sind toll, man kann viele kleine Kisten wunderbar virtualisieren spart sich viel Arbeit und Hardware aber der limitierende Faktor wird ganz schnell IO wenn performance gefragt ist.
CPU und RAM bekommt man mitlerweile mehr in einen Server als man für eine einzelne Kiste wirklich braucht aber das IO subsystem ist doch eigentlich wenn man was flottes braucht eigentlich immer zu langsam solange sich da noch wirklich Platten drehen.
Mit VMs lastest du die Resourcen schöner aus, für CPU und RAM ist das kein Problem weil man mehr hat als man braucht IO dagegen ist ja meist schon bei DB-Servern mit eigener Hardware der limitierende Faktor.

Nimm das schnellste was du bekommen kannst, es wird immernoch das Nadelöhr in deiner Umgebung.
Da du kein richtiges QOS für Storage hinbekommst ist es wichtig, performancekritische VMs auf andere volumes zu legen als die anderen Kisten. IO steht dir halt immer pro RAID-set zur verfügung.

 

[Crow]

Puh ich merk schon das die Dimensionierung eines solchen Systems wirklich schwierig ist wenn man wirklich den realen Workload nicht vernünftig einschätzen kann

Als Beispiel: In unserem RZ laufen auf 1x HP MSA2012fc mit 15x 300GB 15k @ 5x RAID-5
24x Datenbankserver (2x Citrix XenServer)
30x MS 2003 R2 Terminalserver (3x Virtuozzo Server)

Da arbeiten somit produktiv in etwa 250 Clients (Apotheken) und erzeugen imho kaum Last! (Siehe Screenshot im Anhang)


Grüße
Kai

 

[Morpheus2200]

Rechner die nix tun machen kein IO.
Kannst du nicht einfach mal nen Performancemonitor laufen lassen auf deinen Kisten. peak-IO Werte wären ja mal interessant.

 

[Backbone]

Für rund 11.000€(netto) gibts auch schon eine Fujitsu Eternus DX80 mit 1x8Gbit FibreChannel Controller und 12x 450GB 15k SAS Platten. 3 Jahre Vor Ort Service inkl.

Das ist dann zumindest kein ganz kleines Einstiegsmodell mehr, dafür kann ist die Kiste richtig schnell und bietet reichlich Erweiterungsmöglichkeiten. Eine DX60 würde ich nur in Betracht ziehen, wenn klar ist, dass es kaum Erweiterungen geben wird.

Backbone

 

[Crow]

Für rund 11.000€(netto) gibts auch schon eine Fujitsu Eternus DX80 mit 1x8Gbit FibreChannel Controller und 12x 450GB 15k SAS Platten. 3 Jahre Vor Ort Service inkl.

Das ist dann zumindest kein ganz kleines Einstiegsmodell mehr, dafür kann ist die Kiste richtig schnell und bietet reichlich Erweiterungsmöglichkeiten. Eine DX60 würde ich nur in Betracht ziehen, wenn klar ist, dass es kaum Erweiterungen geben wird.

Backbone

Was würde denn eine Eternus DX60 in der Konfig kosten? Einfach mal als Rechenbeispiel!

Grüße
Kai

 

[H_M_Murdock]

Was übrigens im VMWare Buch das ich ansprach empfohlen wird ist, in Verbindung mit iSCSI einen dedizierten Switch für das iSCSI Netz zu verwenden der nen ordentlichen Backplane Durchsatz hat.

Wobei das natürlich auch stark von der Größe des iSCSI Netzwerks abhängt, aber es wird explizit davor gewarnt das ganze mit auf nen LAN Switch zu hängen.

Fürs Eternus DX60 komm ich mit 3 Jahre Vor Ort Service, Antrittszeit NBD 5x9 auf:
15.110 EUR Listenpreis mit 2x FC 4 GBit Dualport
14.460 EUR Listenpreis mit 2x iSCSI Controller
Je 12x 450 GB 15k 3,5" HDDs

Listenpreis/2 und MwSt drauf kommt dann recht gut an den Endpreis hin, wobei ich nicht weiß zu welchen Bedingungen du einkaufen kannst.
Also der Unterschied ist hier nicht wirklich dramatisch, kommen halt bei den Servern noch die FC Controller dazu (dafür sparst du ein paar LAN Ports) und ein FC Switch (oder mehrere, aber wie gesagt bräuchtest du für iSCSI wenn du's richtig machen willst auch nochmal extra nen Ethernen Switch der was taugt).

 

[jraf]

Zwecks Ausfallsicherheit/Redundanz würde ich im FC-Storage Bereich immer mit Multipath arbeiten - 2 Controller sowohl am Storage als auch im Server und dazu zwei passende FC Switches. Sicherlich treibt das den Preis nach oben, bei einem 24/7 Produktivsystem schläft man damit aber ruhiger

Wie oben schon angesprochen würde ich versuchen Produktiv- und Testsysteme voneinander zu trennen. Beim Testsystem ist denke ich Performance und Verfügbarkeit weniger kritisch, von daher kann man da an der Hardwarebasis ein bisschen sparen.

Die Aussage, dass FC selten spürbar schneller ist als iSCSI halte ich nicht wirklich für vertretbar, insbesondere bei einer performanten Infrastruktur und Anwendungen mit massivem I/O Bedarf. Gut, wenn ich 10GBit Ethernet einsetze mag das schon sein - aber den Preisvorteil von iSCSI gegenüber FC kann man dann vergessen.

 

[fdsonne]

Was übrigens im VMWare Buch das ich ansprach empfohlen wird ist, in Verbindung mit iSCSI einen dedizierten Switch für das iSCSI Netz zu verwenden der nen ordentlichen Backplane Durchsatz hat.

Wobei das natürlich auch stark von der Größe des iSCSI Netzwerks abhängt, aber es wird explizit davor gewarnt das ganze mit auf nen LAN Switch zu hängen.

Das ist in meinen Augen Quark... Zumindest, wenn man ordentliche aktive Technik im LAN Bereich im Einsatz hat.
Heutige quasi Mittelklasse stackabel Switches haben Backplane Durchsatzraten von weit über 100GBit/sec. Das deckt man man nicht eben mit ner kleinen iSCSI Library ab... Selbst wenn da der komplette User Traffic des ~80 Mann Unternehmens über den selben Stack läuft, gibts keine Flaschenhälse...
Normal reicht auch bei ner einfachen ungetrunkten Dual Port iSCSI Controllerkiste ein kleiner günstig Switch, sofern es wirklich ein Switch ist

Und zur Not gibts immernoch QoS/CoS, bzw. Priorisierung allgemein...

Die Aussage, dass FC selten spürbar schneller ist als iSCSI halte ich nicht wirklich für vertretbar, insbesondere bei einer performanten Infrastruktur und Anwendungen mit massivem I/O Bedarf. Gut, wenn ich 10GBit Ethernet einsetze mag das schon sein - aber den Preisvorteil von iSCSI gegenüber FC kann man dann vergessen.

Bei 10GBit Ethernet erreichst du zwar die höhere sequenzielle Datenrate, dem Latenzproblem und dem Overhead kommst du so aber immernoch nicht wirklich auf die Schliche

 

[gea]

Wenn High-End Storage gefragt ist und net-app zu teuer ist?
(ZFS is m.E. sogar noch erheblich moderner)

mein Tipp is da ganz eindeutig ein ZFS-Server, entweder Oracle Solaris oder NexentaStor (kommerziell mit Support) oder NexentaCore oder Opensolaris/ OpenIndiana falls es freie Software sein soll. Dazu SSD Storage oder wenistens ein SSD Read oder Write Cache (wird von ZFS direkt unterstützt) und die Performance per NFS ist ok. (zumal bei NFS die VM's und Snapshots -auch per SMB wenns sein soll- zugänglich sind wg move/ copy/ clone/ backup )

Raid 5/6 oder ZFS Raid Z1-3 wuerde ich nicht machen, immer raid1 oder raid 10, am Besten mit SSD Platten.

Wir virtualisieren seit neuestem sogar die ZFS NFS-Storageserver (NexentaCore) in unseren VMware esxi-Server (auf vti-d Mainbaoards um die Platten/ Controller per pci-passthrough an den Storagserver durchzureichen).

gea

 

[fdsonne]

SSDs sind schön und gut, nur leider bisschen teuer... Für 4TB Nutzdaten wie im Startpost steht kost das mehr wie 10-12t€. Wenn man dann noch auf Raid 1 oder 10 setzt, wo quasi die hälfte verloren geht, so muss das Storage schon mit 8TB ausgebaut sein.

Mal ganz davon ab halte ich von SSDs gerade im Serverproduktivbereich noch nicht sooo viel aufgrund der etwas eingeschränken Schreibzyklen... Gut man könnte hier auf SLC Speicher setzen, aber das treibt den Preis gleich noch weiter hoch.

 

[Backbone]

Es gibt auch ganz offiziel Storage-Produkte mit SSDs, aber wie du schon sagst, das wird arg teuer. Und echte Vorteile kann man auch nur dort erwarten wo es viele verteilte Zugriffe gibt, etwa bei Datenbanken.

Backbone

 

[Crow]

Also erstmal danke für die vielen Erfahrungen und Denkanstösse!

Meine derzeitige Planung umfasst 2x Dell MD3200i mit jeweils 12x 300GB SAS 15k
Diese Lösung kostet zwar mit rund 17k mehr als erst geplant aber ich denke durch die höhere Spindelanzahl sowie der Verteilung auf 2x Storage-Systeme wird unsere Anforderung eher erreicht.

Zusätzlich finde ich das Leasing Angebot von Dell sehr interessant! Ich mein ich bin kein Kaufmann aber eine hohe Anfangsinvestition in eine geringe monatliche Belastung umzuwandeln ist für uns bedingt durch eine nicht recht schmale Kapitalbasis interessant! Es werden ja neben dem Storage noch mind. 5 Rechenknechte gekauft - die könnten direkt ins Leasing mit einfließen!


Grüße
Kai Oeste

 

[fdsonne]

Wie schon erwähnt würde ich in der Größenordnung nicht mehr auf iSCSI setzen... Und vor allem macht es in meinen Augen wenig(er) Sinn hier zwei dieser Kisten hinzustellen, wenn eine Kiste auch auf zwei oder mehr Enclosures erweiterbar ist...

Ich würde wie gesagt eher zu FC Raten, Dualcontroller in einer Kiste und dann auf zwei Enclosures... Sollte sich preislich nicht wirklich viel nehmen... Es sei denn du willst da 30 Hosts anklemmen und brauchst dementsprechend dicke FC Switche sowie auch 30 HBAs...