der Performance-post ....

[dtla]

Hallo!

Nach der Inbetriebnahme der Storage Einheit haben wir Perfomance Tests durchgeführt. Allerdings erscheinen uns die erreichten Werte zu niedrig.

Test 1: Kopieren von 1,5 GB großen Dateien zwischen 2 virtuellen Maschinen (Win Server 2003 SP2, 2 vCPU, 4 GB RAM, OS liegt im SAN, VMXNET3 Netzwerkadapter)

Dabei wird eine Übertragungsrate von ca 25 MB/s erreicht.

Test 2:

Internes kopieren von Dateien auf einer Win7 Maschine (2 vCPU, 2GB RAM, OS im SAN, VMXNET3 Adapter)

Dabei wird eine Übertragungsrate von ca 70 MB/s erreicht.

Anbei noch ein (vermutlich wenig aussagekräftiger) HD Tune Screenshot (win7):




Infrastruktur:

3x Dell Poweredge R905 Server (3x 15K SAS intern, Raid 5)
Equallogic PS6000VX (Raid50), Firmware 4.3.5
2x Dell Powerconnect 6224 Firmware 2.2.0.3 (Stack)
ESXi 4.01 Dell Edition

Die Anbindung der Storage-Einheit erfolgt über 4 Leitungen eines Controllers an die Switche.

Anbindung des Hosts an die Switche erfolgt ebenfalls über 4 Leitungen (4x Broadcom Netxtreme II BCM5708, VMware Round Robin aktiviert)

Für den internen Datenverkehr steht ein Anschluss der Intel Pro 1000 Dual zur Verfügung.

Für das Management wirde der zweite Pro1000 Anschluss verwendet.

Die Konfiguration der Switch Ports über die iSCSI Traffic abgewickelt wird wurde nach den Empfehlungen der DELL Configuration Guideline vorgenommen:

- Spanning Treee deaktiviert
- Flusskontolle global aktiviert
- Jumbo Frames aktiviert (9216)
- Fast Link aktiviert
- Strom Control (unicast) deaktiviert

Screenshot Netzwerk:




Für Vergleichwerte bzw. Vorschläge zur Optimierung wären wir dankbar.

Gruß DTLA

[steffan]

Hallo dtla

Hast du zu deiner Frage schon anderweitig eine Antwort erhalten?

Ich habe ein ähnliches Setup mit Powerconnect 6248 Switches und erlebe die gleichen Performance Werte die in deinem Beitrag auch zu sehen sind.

Gruss
Steffan

[Schnurpf]

Hallo Jungs,
leider bin ich auf diesen Mini-Thread erst jetzt gestoßen. Trotzdem will ich mal antworten, vielleicht nützt es ja noch.
Auf den ersten Blick scheinen mir die ermittelten Werte ganz vernünftig zu sein.
Was unsere EqualLogic-Kunden stets vergessen, ist, dass der erreichbare Durchsatz der EQL-Systeme fast immer durch die erzielbare I/O begrenzt ist und NICHT durch die Anzahl der Gigabit-Ethernet-Interfaces. Ein Denkfehler, den übrigens die Hardliner aus dem Fibre-Channel-Umfeld ebenfalls häufig machen - und dann aber stets über das angeblich langsame iSCSI lamentieren.
Also: In deinem Setup mit nur einer PS6000XV hast Du 4 aktive GigE-Links, theoretisch könntest Du also einen Durchsatz von mehr als 4x 100MB erzielen - aber das ist in realen Szenarien illusorisch.
Deine Konfiguration ist RAID50, also sind von den 16 Disks nur 12 I/O-aktiv (16 minus 2x Hotspare minus 2x RAID5-Parity).
Ein "klassischer" Test ist das Kopieren von Dateien aus einem NTFS-Filesystem. NTFS arbeitet mit 4k-großen Blöcken, also ist die I/O-Size 4k. Bei etwa 50% Random Access und 50% Sequential Access (guter Fileserver-Mix) mit etwa 70% Lesen und 30% Schreiben schafft eine 15k SAS-Disk um etwa 120 I/Os.
Also: 12 x 120 x 4KB = 5760 KB/s ~ 5.8 MB/s. Die EqualLogic-Boxen sind cache-optimierte Monster, mit Hilfe des Caches verdoppelt sich der Durchsatz in der Praxis nahezu, daher sieht man in der Regel den doppelten Durchsatz, also um 10 MB/s.
Dieser Wert wird UNABHÄNGIG davon erreicht, ob man seinen MS-Server virtuelll oder physisch fährt. Deutlich höhere Werte KÖNNEN NUR erreicht werden, wenn überwiegend sequenziell gelesen/geschrieben wird. Bei paritätsbildenden RAIDs (wie z.B. RAID50) kommt noch hinzu, dass wegen des immanenten Read-Before-Write die Schreib-Performance etwa 30% niedriger liegt als beim Lesen, aber auch hier gilt, dass das stark von der "Randomness" abhängig ist. Bei stark verteilten Zugriffen ist der einzig limitierenden Faktor die maximal erzielbare I/O - und die hängt bei EQL-Systemen (wie auch bei anderen) im Wesentlichen von der Anzahl der Disks ab.
Wenn man sein iSCSI-Netzwerk auf maximalen Durchsatz testen will, dann muss man also die Physik der Platten aus dem Test eliminieren. Das geht sehr schön mit dem Tool IOmeter. Wir haben damit, - bei richtiger Einstellung: große Blocksize (64 MB), 100% sequential Read-, aus einer PS6000E (SATA!) bereits mehr als 330 MB/s aus einer ESX-virtuellen Maschine heraus gemessen - und zwar "locker aus dem Stand".
Wir (die Firma ad rem IT) lieben die EqualLogic-Systeme. Richtig optimiert fahren die Dinger in VMware/ESX-Umgebungen so gut wie alles andere an die Wand.
Der oft gehörte Jammer über die Performance liegt häufig am sub-optimal bis grottig iSCSI-optimierten Netzwerk und extrem häufig an zu wenig I/O (sprich: zu wenig Platten). Letzteres ist angesichts des Preises verständlich - ich möchte aber betonen, dass die Dell/EqualLogic-Storages im Vergleich zu ähnlich starken Enterprise-Systemen anderer Hersteller eher günstig sind. Und dann ist da ja noch das Bedienkonzept - da gibt es wenig Vergleichbares.
Stehe gerne für weitere Fragen zur Verfügung.
Gruß
Schnurpf

[osu]

Hallo Schnurpf,

bei deiner Berechnung werden aber die RAID5-Parity mit gezählt!

Also sind es 14 und keine 12 Platte!
Eine 15k SAS bringt auch heute so um die 180I/Os und nicht nur 120I/Os

[bla!zilla]

Ein "klassischer" Test ist das Kopieren von Dateien aus einem NTFS-Filesystem. NTFS arbeitet mit 4k-großen Blöcken, also ist die I/O-Size 4k.

Sorry, aber das ist leider falsch. Die Blockgröße mag 4 KB sein, aber die I/O Größe hat damit wenig zu tun. Bei Exchange bis Version 2003 mag das so sein, aber bei Fileservern stimmt das nicht. Da schwankt die I/O Größe mit der Filegröße.

Wir (die Firma ad rem IT) lieben die EqualLogic-Systeme. Richtig optimiert fahren die Dinger in VMware/ESX-Umgebungen so gut wie alles andere an die Wand.

Auch nicht ganz korrekt. Es gibt bei den EQL Boxen einige "Feinheiten", die die Kisten für den Produkteinsatz einfach disqualifizieren. Das musste z.B. DELL in direkten Gesprächen gerne mal zugeben (z.B. Striping über Boxen verringert die Verfügbarkeit, da bei Downtime einer Box das Volume offline geht)

Letzteres ist angesichts des Preises verständlich - ich möchte aber betonen, dass die Dell/EqualLogic-Storages im Vergleich zu ähnlich starken Enterprise-Systemen anderer Hersteller eher günstig sind. Und dann ist da ja noch das Bedienkonzept - da gibt es wenig Vergleichbares.

Ich habe bisher jeden Deal gegen EQL gewonnen. Meist mit HP P4000.

[Schnurpf]

Hallo,
ich bin überrascht, dass ein so "alter" Thread so schnell neues Leben bekommt. Danke erstmal an alle für eure Posts!
Seit mehr als zwei Jahren arbeite ich u.a. als Trainer, Consultant, Event-Leiter, Vortragender etc. europaweit (EMEA) für HP speziell in Sachen Lefthand (heute P4000). Ich weiß also ein bisserl was über diese Storages.
Mit iSCSI beschäftige ich mich, seit es iSCSI gibt. Die ersten EQL-Systeme in Deutschland wurden von mir verkauft.
Wir (ad rem IT) gehen vorurteilslos an das Thema Dell/EqualLogic versus HP/Lefthand: wir vertreiben beide mit Leidenschaft !

@osu: Bei RAID-50-Konfiguration eines EQL-Members werden standardmäßig zwei Hot-Spares angelegt (vom CLI aus geht es auch ohne!), bleiben 14 Platten. Diese wiederum werden in zwei gespiegelte RAID-5-Sets aufgeteilt. Also hat jeder RAID-5-Set 7 Platten. Bei Schreibzugriffen auf einen Set von Disks im RAID-5-Verbund wird stets auf einer dieser Disks die Parity geschrieben, bei Lesezugriffen wird stets die Platte mit der Parity im Stripe nicht gelesen, was bedeutet, dass bei Zugriffen über alle Platten des RAID-Sets hinweg jeweils eine Platte nichts zu den produktiv nutzbaren I/Os beiträgt. Im Falle eines EQL-RAID-50-Members sind also in jedem 7-Platten-RAID-5 nur 6 Disks I/O-aktiv, zusammen also 2 x 6 Disks. In Summe hat also so ein RAID-50-Member 12 I/O-aktive Platten - und genau das habe ich auch bei der Berechnung der max. erzielbaren I/O berücksichtigt.

@osu: Die I/O, die eine Platte bringt, hängt vom Zugriffsprofil ab - die 120 I/Os, auf die ich mich in meinem o.a. Post bezog, sind ein typischer Wert für eine 15k SAS-Platte bei 50% random / 50% sequential-, 70% Read / 30% Write-Zugriff. Natürlich schafft so eine Platte auch 180 I/Os (und sogar viel mehr), wenn insbesondere der Random-Anteil klein(er) ist. Sehr schön kann man das auf einer Website von Microsoft sehen, die für bestimmte MS-Anwendungen typische I/Os für bestimmte Plattentypen spezifizieren. Hab' leider den Link nicht parat, kann aber mal danach suchen ...

@bla!zilla: Da haben wir beide Recht. Tatsächlich ändert sich die I/O-Size, mit der Windows/NTFS arbeitet, mit der Filegröße. In der Praxis aber kommen bei Filesystem-Aktivität tdennoch fast ausschließlich 4k große I/Os vor. Das liegt ganz simpel daran, dass rein statistisch auf einem "typischen" Windows-Fileserver fast ausschließlich kleine (man möchte sogar sagen: winzige) Files rumliegen, und im Verhältnis nur sehr wenige sehr große Dateien (die dann in der Tat mit größeren I/O-Sizes behandelt werden).
Andere Anwendungen, wie SQL-Server, Oracle, Exchange etc. verwenden wieder andere I/O-Sizes, nicht selten unterschiedlich große, aber das steht auf einem anderen Blatt. Ich sprach ja explizit vom Kopieren von Dateien in NTFS-Filesystemen.
Dass dtla bei seinen Tests (deutlich) höheren Durchsatz als den von mir genannten erzielte, liegt übrigens u.a. an dem von bla!zilla genannten Effekt: Bei großen Files wird mit größeren I/O-Sizes gearbeitet, und schon geht der Durchsatz (!) rauf. dtla hat vergleichsweise "riesige" 1.5 GB-Files zum Testen benutzt. Außerdem dürfte damit auch ein deutlich höherer Sequential-Anteil zum Tragen kommen, ebenfalls ein Grund für die höhere Performance. Meine Zahlen darf jeder gerne selbst überprüfen, wie gesagt, am besten geht das mit IOmeter - ich kenne kein anderes Tool, bei dem man so gut die Zugriffsprofile einstellen kann.

und nochmal @bla!zilla: Bezüglich der Verfügbarkeit von EQL-Systemen: Das Striping über Komponenten hinweg verringert bei JEDEM Storage, das aus einzelnen Komponenten aufgebaut wird, die potentielle Verfügbarkeit. Das gilt insbesondere für die Lefthands, wo jeder Node ein PC mit allen PC-typischen Single-Points-of-Failures ist. Ein EQL-Member dagegen ist in sich redundant und hat keinen Single-Point-of-Failure. Daher MÜSSEN Lefthand/P4000-Storages seriöserweise stets im HA-Mirror betrieben werden (zumindest für die wichtigen Daten), was bei EQL-Systemen nicht der Fall ist. Der Betrieb mittels Network-RAID-1 (Lefthands HA-Mirror) treibt aber die Kosten eines Lefthand-Systems gehörig nach oben. Naja, dafür hat EQL bis heute keine echte HA-Lösung.

@all: Man sieht, beide Lösungen haben ihre Vor- und Nachteile - die Wahl hängt letztlich davon ab, was genau man erreichen will bzw. welche Vorgaben man hat.

Zuguterletzt (@bla!zilla) geht es euch aber wohl wie uns: Es ist weniger der Mitbewerb aus dem iSCSI-Lager, der einem das Leben schwer macht, sondern insbesondere NetApp, gegen die man sich positionieren muss. Wir müssen leider häufig erfahren, dass wir gegen NetApp nicht aufgrund technischer Argumente das Nachsehen haben, sondern an deren exzellentem Markteting scheitern - vornhem ausgedrückt!

Ich wünsch' euch allen HOHE I/O !
Gruß
Schnurpf

[bla!zilla]

Du bist Trainer und Consultant? Ich auch, willkommen im Club.

@bla!zilla: Da haben wir beide Recht. Tatsächlich ändert sich die I/O-Size, mit der Windows/NTFS arbeitet, mit der Filegröße. In der Praxis aber kommen bei Filesystem-Aktivität tdennoch fast ausschließlich 4k große I/Os vor. Das liegt ganz simpel daran, dass rein statistisch auf einem "typischen" Windows-Fileserver fast ausschließlich kleine (man möchte sogar sagen: winzige) Files rumliegen, und im Verhältnis nur sehr wenige sehr große Dateien (die dann in der Tat mit größeren I/O-Sizes behandelt werden).

Das ändert nichts an der Tatsache, dass die durchschnittliche Dateigröße >4 KB liegt. Die festen IOs sind eher bei Datenbanken zu finden (je nach DB/ Anwendung variiert das). Aber Fileserver haben zu 99% >4 KB, außer ich betreibe da Anwendungen die wirklich unverhältnismäßig viele kleine Dateien haben.

und nochmal @bla!zilla: Bezüglich der Verfügbarkeit von EQL-Systemen: Das Striping über Komponenten hinweg verringert bei JEDEM Storage, das aus einzelnen Komponenten aufgebaut wird, die potentielle Verfügbarkeit. Das gilt insbesondere für die Lefthands, wo jeder Node ein PC mit allen PC-typischen Single-Points-of-Failures ist. Ein EQL-Member dagegen ist in sich redundant und hat keinen Single-Point-of-Failure. Daher MÜSSEN Lefthand/P4000-Storages seriöserweise stets im HA-Mirror betrieben werden (zumindest für die wichtigen Daten), was bei EQL-Systemen nicht der Fall ist. Der Betrieb mittels Network-RAID-1 (Lefthands HA-Mirror) treibt aber die Kosten eines Lefthand-Systems gehörig nach oben. Naja, dafür hat EQL bis heute keine echte HA-Lösung.

Sorry, aber wenn ich Daten auf EINEN EQL Node lege, und der geht hops, dann sind meine Daten auch weg. Daten auf EINEM Node zu halten ist IMMER quatsch. Die Verfügbarkeit von einem DL185 ist nicht niedriger als von einem EQL Node. Wenn ich Daten redundant halte (z.B. 2-Way Replication bei LH), dann habe ich echte Redundanz. Wenn ich Volumes über ZWEI oder mehr EQL Nodes ziehe, dann verringert sich meine Verfügbarkeit im Gegensatz zu einem Einzelnode, eben durch das Striping. Und das kann ich NICHT verhindern (wurde von DELL bestätigt). Ist auch rein mathematisch logisch (Wahrscheinlichkeitsrechnung). Wenn ich bei LH meine Daten über zwei Nodes verteile (RAID 0), dann trifft das gleiche zu, wie bei EQL. Mache ich 2-way Replication zwischen zwei Nodes, dann habe ich eine höhere Verfügbarkeit. Wenn ich meine Daten über vier Nodes verteile, und eine 2-way Replication nutze, dann ist meine Verfügbarkeit immer noch besser, als bei EQL, da meine Daten nur beim Ausfall von zwei Nodes, die den gleichen Block halten, hopps sind. Und eben diese Redundanz, Daten über mehrere Boxen verteilen, habe ich bei EQL schlicht und ergreifend nicht. In einem LH Cluster kann ich Nodes offline nehmen, bei EQL nicht, sobald ich Daten über die Boxen verteile. Und das disqualifiziert die Büchse einfach.

@all: Man sieht, beide Lösungen haben ihre Vor- und Nachteile - die Wahl hängt letztlich davon ab, was genau man erreichen will bzw. welche Vorgaben man hat.

Wie gesagt: Bisher hab ich jeden Deal gegen EQL gewonnen.

Zuguterletzt (@bla!zilla) geht es euch aber wohl wie uns: Es ist weniger der Mitbewerb aus dem iSCSI-Lager, der einem das Leben schwer macht, sondern insbesondere NetApp, gegen die man sich positionieren muss. Wir müssen leider häufig erfahren, dass wir gegen NetApp nicht aufgrund technischer Argumente das Nachsehen haben, sondern an deren exzellentem Markteting scheitern - vornhem ausgedrückt!

NetApp baut sehr brauchbare Kisten. Man sollte sich davon trennen verkaufen zu wollen, was im Portfolio ist. Viel mehr sollte man die Lösung verkaufen, die für den Kunden die Beste ist. Und es ist keine Schande (das musste auch ich lernen...), auch vor NetApp mal den Hut zu ziehen.

[Tschoergez]

Servus Jungs!
Da sammeln sich doch in so nem alten Thread super Infos zu Storage allgemein und iSCSI im speziellen... wäre ein guter Kandidat für nen sticky-post (bin leider in den "neuen" Foren kein Moderator ).

Wenn jetzt noch jemand so ausführlich zur Netapp schreib, haben wir einen nicht-gesponserten Competition-Guide .

Bei der Netapp seh ich den Vorteil, dass die halt alles kann (wenn man dafür bezahlt). Die Preise lassen sich aber schlecht vergleichen, da jeder Hersteller tolle Projektpreise macht. (v.a. wenns ans Geschäftsjahresende geht und die Salies noch ihre Ziele/Boni verbessern wollen).

Viele Grüße,
Jörg

[Schnurpf]

Hallo,
dieser Blog bekommt ja tatsächlich ein "zweites Leben", gefällt mir, danke an alle für's Mitmachen und den Feedback!
@bla!zilla: ein Lefthand-Node ist und bleibt ein PC mit PC-typischen Single-Points-of-Failures. Und über die Verfügbarkeit von PC-Systemen müssen wir ja wohl nicht diskutieren, oder? Ich gehe mal fest davon aus, dass auch Du JEDES Lefthand-System clusterst, und Du wirst wohl wissen, warum!
Ein EqualLogic-Array ist ein in sich voll redundantes System - man kann sehr wohl ein einzelnes Array sicher und sinnvoll nutzen. Ein-Member-Konfigurationen sind daher bei EQL auch die typische Einstiegsgröße für "kleine" Kunden.
Lefthand-Systeme werden (zumindest von uns) immer mit einer geraden Anzahl Nodes verkauft - man MUSS sie redundant einsetzen, weil einzelne Nodes einfach zu unsicher sind. Nicht umsonst sind die Einstiegs-Konfigurationen bei HP/Lefthand die sog. Starter-Kits - und die bestehen aus ZWEI Nodes, natürlich bei entsprechendem Preis.
In den Jahren, die ich mit Lefthand zu tun habe, sind mir bereits einige Nodes gestorben bzw. ausgefallen, was auch zu erwarten war. Da wir bei Kunden aber stets geclusterte Systeme verkauft haben, haben wir noch nie produktive Daten verloren. Nur mal so zur Info: noch nie (!) hatte ich einen Ausfall eines EQL-Nodes!
Ich sehe den "sweet spot" für die HP Lefthand-Storages bei Kunden, die echte High Availibilty über eine gewisse Distanz hinweg (z.B. zwei räumlich getrennte Rechenzentren) realisieren wollen. Da ist die P4000-Serie preislich kaum zu schlagen, und aufgrund der systemimanenten Sicherheit von Network-RAID-1 auch unglaublich robust - insbesondere auch beim Failback. Und damit bla!zilla ruhig schlafen kann ( ): Dieses Szenario können EqualLogic-Systeme so nicht abdecken, da sie, zumindetst bis jetzt, das Feature eines synchronen Mirrors nicht anbieten.

@Tschoergez: Einen Competition-Guide wollte ich eigentlich NICHT lostreten.
Wenn ein Kunde ein universell einsetzbares Storage für unterschiedliche Infrastrukturen (wirklich) benötigt, dann ist er mit EqualLogic-/Lefthand-Produkten, die speziell nur iSCSI unterstützen, generell falsch beraten. Umgekehrt heißt das nicht automatisch, dass er dann NetApp kaufen sollte - allerdings sorgt das unglaublich gute Marketing dieses Herstellers dafür, dass der Begriff "Unified Storage" in unser aller Köpfe automatisch mit "NetApp" übersetzt wird - Hut ab, dass haben die gut hinbekommen.

Ich möchte noch erwähnen, dass, - nach meinem Empfinden -, die Kundenzufriedenheit bei EqualLogic- und Lefthand-Käufern extrem hoch ist, und über die Jahre eher noch steigt (insbesondere nach Nachkäufen). Zugegebenermaßen ebenfalls ganz subjektiv habe ich die Erfahrung gemacht, dass das bei NetApp-Kunden deutlich weniger positiv ist. Das gibt, zumindest mir, immer stark zu denken!

Weiterhin HOHE I/O !
Gruß
Schnurpf

[affabanana]

Hallo zusammen

hat die EQL nicht auch nur eine Backplane Platte wie die Hp P2000 MSA.

Wenn Dir diese abraucht ist auch das Storage TOT....??

Oder hab ich das falsch im Kopf.


gruass affabanana

[Schnurpf]

Hallo,
@affabanana: Ja, die Backplane ist natürlich nur einmal vorhanden. Da macht EqualLogic genau das, was alle anderen Hersteller auch machen: "passive" Bauteile wie z.B. Backplanes, Gehäuse, Kabel etc. werden per se nicht als mögliche Fehlerquelle gesehen. Mit einigem Grund, denn ein solches passives Element kann eigentlich nur durch Einwirkung VON AUßEN (z.B. Feuer) ausfallen, und das gilt natürlich nicht als systemimanenter Single-Point-of-Failure. Will man sich gegen solche Einflüsse ebenfalls absichern, hilft eigentlich nur die doppelte Auslegung aller Komponeneten, möglichst an einem räumlich getrennten Ort, und das vollsynchrone Spiegeln der Daten zwischen diesen redundanten Komponenten.

Wieviel Verfügbarkeit braucht nun der Mensch? Hier mal eine kleine Überlegung:
Ein PC-System, wie z.B. ein Lefthand-Node, habe eine über die Zeit gemittelte Verfügbarkeit von, - sagen wir mal -, 95 Prozent. Das mag zwar für einen PC eher zu hoch gegriffen sein, aber man sollte berücksichtigen, dass ein Lefthand-Node ein qualitativ hochwertiger Server und nicht ein Feld-, Wald- und Wiesen-PC ist. Jeder Node funktioniere völlig unabhängig von jedem anderen Node. In einem NICHT geclusterten Lefthand-System von 5 Nodes seien die Daten über alle 5 Nodes (ähnlich RAID-0) verteilt, fällt also auch nur einer aus, ist die Verfügbarkeit Null, sprich das System steht. Wie hoch ist nun die Gesamtverfügbarkeit des 5-Node-Systems?
Falls ich mich nicht irre, ist es das Produkt aus den Einzelverfügbarkeiten, also 95% mal 95% mal ... usw., sprich 0,95 hoch 5. Ergebnis: Ein solches System hat nur noch eine Verfügbarkeit von ~ 77,4%, was für ein Storage schlicht inakzeptabel ist. Daher MÜSSEN Lefthand-Nodes seriöserweise redundant ausgelegt werden - wie gesagt, mit allen Konsequenzen, insbesondere den Preis betreffend.
Glauben wir der Behauptung von EqualLogic, dass deren Arrays in sich hochverfügbar sind, und dafür sprechen redundante Controller, redundante Netzteile, Redundanz in den Platten-RAIDs etc., dann hat ein EQL-Array per definitionem eine Verfügbarkeit von 99,9999%. Bei gleicher Konfiguration, also der Verteilung aller Daten über 5 Members und der (richtigen) Behauptung, die Verfügbarkeit ist Null, wenn auch nur ein Member ausfiele, dann hätte eine solche EQL-Group die Gesamtverfügbarkeit von 0,999999 hoch 5, also eine Verfügbarkeit von 99,9995%.

Damit ist klar, warum EQL-System ungeclustert eingesetzt werden können und Lefthand-Systeme eben nicht. Und damit ist auch klar, warum ich Lefthand-Syteme als ein phantastisches iSCSI-Storage in HA-Umgebungen ansehe: Weil dieses Produkt durch das Network-RAID-Feature per se HA-fähig ist, und das extrem elegant, robust und simpel. Wer mal ein Recovery eines Lefthand-Systems nach dem Ausfall einer Site gesehen hat (das können Hirnamputierte im Wesentlichen mit 3 Klicks erledigen), der weiß, wovon ich rede.

Aber nicht jeder Kunde braucht "echte" HA und will für die doppelte Auslegung aller Komponenten zahlen, und so ein Kunde wird sich sicher auch für EqualLogic interessieren. Jenseits der Verfügbarkeitsdebatte gibt es nämlich viele gute Gründe für EQL, z.B. was die Applikationsünterstützung anbelangt und die Integration in virtuelle Umgebungen. Und das mag für viele Kunden eben wichtiger sein. Wie gesagt - it depends !

Haltet die Pausenzeiten ein !
Schnurpf

[GTMK]

Moin,

ich mische mich an dieser Stelle auch einmal ein...

Wir haben kürzlich ein LH-Cluster beschafft, bestehend aus 4 Nodes, das allerdings noch nicht produktiv ist. Im Rennen waren EQL und LH, ausschlaggebend war letzten Endes der Preis und die Möglichkeit, über zwei Standorte zu synchronisieren und eben nicht nur zu replizieren. Ich hatte hier im Forum im Vorfeld nach Erfahrungen gefragt, auch danach, ob schon jemandem eine EQL um die Ohren geflogen ist. Ich weiß von keinem solchen Fall. Robust scheinen beide Lösungen, ich habe die LH noch nicht gegen die Wand fahren können. Vom _Gefühl_ her würde ich die Hardware der EQL als höherwertig einstufen, und ich hätte mich wohl dazu durchringen können, über zwei Knoten zu stripen. Ob die Vorbehalte gegen x86-Hardware wirklich so zutreffend sind... auf x86 setzen auch andere, mir fallen da etwa Isilon oder Sun Unified Storage ein.

Die EQL hat einen (abhängig vom speziellen Einsatzszenario) großen Nachteil: Snapshots werden wegen der Blockgröße von 16 MB sehr schnell sehr groß. Setzt man also - vor allem bei schnell veränderlichen Datenbeständen - Snapshots ein, benötigt man bei EQL deutlich mehr Bruttokapazität. Bestechend ist dagegen die VMware- und Windows-Integration, und das Monitoring bei der LH ist ziemlich rudimentär. Ich bin mal gespannt, was SAN/iQ 9 an der Stelle bringt. Ich glaube aber nicht, dass in absehbarer Zeit bei EQL ein synchroner Spiegel kommt.

Georg.

[Schnurpf]

Hallo GMTK,

gratuliere zur Wahl des Storages. Ist "über zwei Standorte zu synchronisieren" ein Kriterium, dann kann eigentlich die Wahl nur auf Lefthand fallen.

Auf das Feature "synchrone Spiegelung" warten EQL-Kunden und wir schon seit Jahren. Wir glauben übrigens auch nicht, dass sich diesbezüglich bald was tut. Es scheint uns so, dass EQL einen anderen Weg geht und statt dessen lieber die Applikationsunterstüzung beständig weiterentwickelt. Mit einem eigenen MPIO-Stack für ESX und VAAI haben sie gerade jetzt wieder echte Sahnestücke abgeliefert.

Den schnellen Kapazitätsverbrauch bei Snapshots kann ich nur bestätigen, es wird in der Tat mit 16 MB großen sog. Superblocks allokiert. Das führt bei hochvolatilen Volumes schnell zum Verbrauch von Snapshot-Space. EQL addressiert das Thema dadurch, dass in der (übrigens sehr guten) Dokumentation stets empfohlen wird, schnellveränderliche Daten wie Logs, Swaps, Temp-Space, Auslagerungsdateien, Indexe etc. auf separate LUNs zu legen. Dadurch wachsen bzw. verändern sich die eigentlichen Datenvolumes dann im Wesentlichen nur noch linear und der Snapshot-Overhead wird minimal. Wir machen das tunlichst so (ist eh' guter Stil) und haben damit den Snapshot-Kapazitätsverbrauch gut im Griff.

Interessant ist, dass EqualLogic-Storages eine sog. Kollokation beherrschen, d.h. sie setzen im Hintergrund aus vielen angebrochenen 16 MB Superblocks sukzessive wenige voll gefüllte Superblocks zusammen und "leeren" die wenig gefüllten. Das bringt zwar Performance, leider werden die geleerten Superblöcke nicht wieder released und die allokierte Kapazität wird nicht wieder freigegeben. Man kann das übrigens sehr schön bei der Replikation sehen, da ist nämlich der Overhead, ganz anders als bei den Snapshots, sehr gering.

Und ein letztes Wort zu x86-Hardware (als Storage-System): Es spricht vieles dafür (welche Plattform sonst liefert soviel "Wumms" für sowenig Geld?). Die geringere Verfügbarkeit muss allerdings durch Clustern abgefangen werden. Aber: benötigt man sowieso geclusterten Storage, also "echte" HA, na, dann passt es doch !

Gruß
Schnurpf

[bla!zilla]

99,9999% bei EQL? Das will ich sehen... Ich erreiche mit normalen Servern (z.B. ProLiants) und Windows 99,99%. Kann ich dir relativ einfach darlegen, für sowas gibt es Reports aus Managementsystemen. Ich habe auch einige LHs draußen und davon ist noch keiner gestorben.

[GTMK]

99,9999% bei EQL? Das will ich sehen...

Ich auch! Dafür sind die 95 % Verfügbarkeit auf der anderen Seite deutlich zu niedrig angesetzt. Der letzte x86-Server, der in meinem Bereich (ungefähr 10 Maschinen) wegen eines Hardwaredefekts über den Deister gegangen ist, datiert von ungefähr 2003. (Ich klopfe mal ganz schnell auf Holz....).

Dass ein EQL-Knoten insgesamt eine höhere Verfügbarkeit aufweist als ein LH-Knoten, will ich trotzdem wohl glauben.

Um nochmal auf das eigentliche Thema zurückzukommen: 2 LH-Nodes (RAID-5, Network RAID-1) waren in meinen Tests (Exchange LoadGen 2007, JetStress 2004) etwa so schnell wie ein einzelner mit RAID-10 konfigurierter PS6000XV-Knoten. Mit RAID-50 fällt die EQL ab. Das Ergebnis ist aber wegen der höheren Anzahl der Spindeln bei der LH nicht unbedingt eine Überraschung.

Ach ja, noch etwas: Dass die LH ohne Hot Spares arbeitet, finde ich persönlich nicht so toll.

Georg.

[Schnurpf]

Hallo,
nunja, Theorie und Praxis ...
Per Definitionem ist High Availability (HA) nunmal mit den berühmten vier Neunern hinter dem Komma definiert, sprich einer Verfügbarkeit von 99,9999%.
Aber ich gebe euch Recht, 99,9999% Verfügbarkeit riecht nach grauer Theorie. Um auf dem Teppich zu bleiben, sollte man mit einer vernünftigen Größe arbeiten. Aber selbst wenn wir für ein EQL-Member "NUR" 99,9% ansetzen (was einer tausendmal kleineren Verfügbarkeit entspricht, um mal den Zahlenwahnsinn zu verdeutlichen), kämen wir bei meinem 5-Member-Beispiel auf eine Verfügbarkeit von 0,999 hoch 5, immer noch 99,5%
Umgekehrt lass' ich mich ja bei einem LH-Node auf eine 98%ige Verfügbarkeit ein (was aber definitv NICHT meiner eigenen Erfahrung entspricht, wie gesagt, ich hatte schon mehrere defekte UND mehrere "aufgehängte" Nodes), dann käme ich für die Lefthand-Konfiguration mit 5-Nodes auf eine Verfügbarkeit von 0,98 hoch 5, also 90,4% - immer noch schlicht inakzeptabel.

Abseits der Theorie und der mehr oder weniger der Realität entsprechenden Berechnung der Verfügbarkeit (einmal in 5 Jahren den Strom abstellen müssen, z.B. um die USV zu wechseln, und alle Berechnung ist Makulatur), ist der Unterschied zwischen EQL-Arrays und Lefthand-Nodes diesbezüglich offensichtlich.

Es bleibt dabei - ein PC KANN sehr wohl als Storage-Node genutzt werden, IST aber in der Realität einfach nicht sicher genug. Macht ja nix, dann muss er eben geclustert werden, und genau das machen wir (und offensichtlich ihr auch) ja auch.
Damit aber wird klar, warum es so unterschiedliche "sweet spots" für den Einsatz von Lefthand und EqualLogic-Storages gibt.

@Georg: Angesichts der Tatsache, dass Lefthand-Nodes eigentlich stets geclustert gefahren werden müssen, sind Hot Spares verzichtbar - fällt ein Node aufgrund eines multiplen Plattenfehlers aus, ist da ja noch sein Cluster-Partner da. Ich würde sogar sagen, sei froh, dass Lefthand keine Hot Spares einsetzt, denn das Verhältnis von Netto- zu Brutto-Kapazität ist bei Leftand sowieso schon ein EXTREM TRAURIGES Kapitel. Um nicht zu sagen, eine klaffende Wunde, in die insbesondere die Vertriebler von NetApp gerne viel Salz streuen, ist doch deren Netto-/Brutto-Verhältnis aufgrund von RAID-DP und des Dual-Head-Ansazes eher sehr gut.

Zum Thema Performance: Ehrlich, ich trau' mich gar nicht, das Thema hier zu adressieren, weil ich aus Erfahrung weiß, wie viele Leute das als ihr persönliches Anliegen und ihren ureigensten, heiligen Gral ansehen. Lasst mich mal so sagen: Häufig werden beim Vergleich zwischen LH und EQL Äpfel und Birnen verglichen. Meistens deshalb, weil bei Lefthand stets geclusterte Systeme eingesetzt werden und deshalb sehr viel mehr Spindeln verwendet werden. Sehr wohltuend, dass Georg alias GMTK genau das bei seinem Performance-Vergleich explizit erwähnt hat!

Gruß
Schnurpf

[dtla]

Erfreulich das hier inzw. eine interessante Diskussion entflammt ist.

Anbei noch ein paar aufschlussreichere IOmeter Screens unseres Setups - Kommentare erwünscht:

######## TEST NAME: Max Throughput-100%Read
size,% of size,% reads,% random,delay,burst,align,reply
32768,100,100,0,0,1,0,0



######## TEST NAME: RealLife-60%Rand-65%Read
size,% of size,% reads,% random,delay,burst,align,reply
8192,100,65,60,0,1,0,0



######## TEST NAME: Max Throughput-50%Read
size,% of size,% reads,% random,delay,burst,align,reply
32768,100,50,0,0,1,0,0



######## TEST NAME: Random-8k-70%Read
size,% of size,% reads,% random,delay,burst,align,reply
8192,100,70,100,0,1,0,0

[bla!zilla]

Test mit einer VM und einem Worker sind nicht realistisch. Da müssen schon mehr Worker und auch mehr VMs ran, um an wirklich realistische Werte zu kommen.

Aber trotzdem interessante Werte. Zumindest für einen direkten Vergleich nützlich, sofern das eigene System mit den gleichen Angaben getestet wird.

[dtla]

Settings wurden von diesem Thread übernommen:
http://communities.vmware.com/thread/73745

Vorschläge zu realistischeren Settings sind natürlich willkommen.

[Schnurpf]

Hallo an alle,
das läuft ja wirlich heiß hier...

@dtla: Da Du und wahrscheinlich auch bla!zilla offensichtlich Lefthand-Systeme benchmarken, werde ich mir die EqualLogic vornehmen - dann können wir vergleichen. Ich bin wirklich gespannt.
Tippen würde ich, dass die Lefthands unter Hyper-V wegen des speziellen MPIO-Treibers, der das Lesen und Schreiben von allen Nodes gleichzeitig ermöglicht, vorne liegen sollten. Umgekehrt erwarte ich unter ESX die EqualLogics vorne zu sehen, mit dem gleichen Argument (optimierter MPIO-Treiber). Aber ich lass' mich gerne überraschen.

Jetzt mal zum Test: Nach meiner Erfahrung ändert sich am Testergebnis (zumindest unter VMware ESX) durch mehr Worker und mehr VMs eher wenig. Mehr Worker führen in der Regel zu geringfügig höheren Resultaten, mehr VMs ändern nur dann etwas, wenn die soviel Last erzeugen, dass der Host in die Knie geht - aber wen interessieren Ergebnisse unter diesen Bedingungen? Mehr VMs machen darüber hinaus die Auswertung der Resultate schwierig, da die IOmeter-Werte aus allen VMs aggregiert werden müssten.
Ich gebe zu, mehr Worker und mehr VMs simulieren ein Multi-User-/multi-Applikations- Szenario realisitischer - aber das gilt doch wohl eher für die Host-Seite. Dem Storage ist es doch eher egal, ob die 30000 I/Os von einem oder von 10 Instanzen generiert werden, oder?
Ich habe da noch ein Argument aus der Praxis: Zumindest unter ESX ist die Queue Depth standardmäßig 32 (oder waren's 30?) I/Os tief. Passt man die IOmeter-Settings entsprechend an, dann laufen kurz nach dem Start eines IOmeter-Tests die Queues voll, die Latenz steigt auf "32 x I/O-Execution-Time + ein-bisserl" und danach steht die Performance des Storages wie aus Stein gemeißelt fest, kommen da noch so viele VMs bzw. Worker.

@bla!zilla: Was ist dein Argument für mehr VMs?

Zuguterletzt möchte ich ja nicht wieder Äpfel mit Birnen vergleichen, und daher sollten wir uns auf das gleiche OS in der VM, gleiche Anzahl und Typen von Disks und den RAID-Level einigen. Die Queue Depth in IOmeter bitte bei Test unter ESX auf 32 setzen. Höhere Werte verzerren meiner Meinung nach zu sehr die Ergebnisse (zu hohe Latenz) und machen sie eher unrealistisch. Welche Anwendung arbeitet schon mit Queue Depths größer 32?

Und ganz zuletzt: Ich muss auch noch arbeiten - schade eigentlich.
Es wird also etwas (ein paar Tage) dauern, bis ich Ergebnisse liefern kann.
Bis dahin sollten wir die Zeit nutzen und uns auf ein gemeinsames Setup einigen.

Jungs, ich find' das spannend, dieser Thread könnte ziemlich einmalig werden!
Danke schonmal vorab an euch alle !
Gruß
Schnurpf

P.S.: Übrigens: Wie groß ist die Standard-Queue-Depth unter Hyper-V?

[Schnurpf]

Ich kann's mir nicht verkneifen: Die Werte von dtla zeigen einfach die traurige Wahrheit, der sich ALLE MIR BEKANNTEN STORAGES auf diesem Planeten NICHT ENTZIEHEN können: Der maximal erzielbare Durchsatz klebt schlicht an der Anzahl der I/Os - und die wiederum hängt fast immer nur von der Anzahl der Disks ab. Ist diese niedrig, kommt einfach kein Durchsatz zustande.
An die Betonfraktion der Fibre Channel-Fanatiker ("aber ich habe doch 8-Gig-Links und ihr iSCSI-Kümmerlinge nur 1-Gig-Interfaces"): Seht euch mal die Fakten an. In den allermeisten Szenarien ist selbst ein 1-Gigabit-Link nur sehr schwer auch nur annähernd zu sättigen, und braucht es wirklich mehr, dann gibt's weitere 1-Gig-Links per Ethernet en masse für kleines Geld. Bei euch auch?
Gruß und weiterhin Hohe I/O!
Schnurpf
P.S.: Vielleicht ändern ja SSDs bzw. kombinierte Storages aus konventionellen Platten mit SSDs als Riesen-Sekundär-Cache die Storage-Welt (siehe bei EqualLogic). Aber mein Gott - was kostet mich nächstes Jahr ein 10-Gig-Ethernet-Interface? Übernächstes Jahr bekommen wir die zum Schweine-Füttern-Preis.

[eini]

gelöscht von mir selber!

[bla!zilla]

Ich kann's mir nicht verkneifen: Die Werte von dtla zeigen einfach die traurige Wahrheit, der sich ALLE MIR BEKANNTEN STORAGES auf diesem Planeten NICHT ENTZIEHEN können: Der maximal erzielbare Durchsatz klebt schlicht an der Anzahl der I/Os - und die wiederum hängt fast immer nur von der Anzahl der Disks ab. Ist diese niedrig, kommt einfach kein Durchsatz zustande.

Hast du noch mehr so Weißheiten??? Das "MB/S = IOPS x Transfer Size" ist, sollte wohl jeder verstanden haben.

An die Betonfraktion der Fibre Channel-Fanatiker ("aber ich habe doch 8-Gig-Links und ihr iSCSI-Kümmerlinge nur 1-Gig-Interfaces"): Seht euch mal die Fakten an. In den allermeisten Szenarien ist selbst ein 1-Gigabit-Link nur sehr schwer auch nur annähernd zu sättigen, und braucht es wirklich mehr, dann gibt's weitere 1-Gig-Links per Ethernet en masse für kleines Geld. Bei euch auch?

Siehst du die Betonfraktion hier irgendwo? Es kommt auf den Usecase beim Kunden an, ob FC oder iSCSI zum Einsatz kommt. Eine ganz einfach, faktenorientierte Sachlage.

[kastlr]

Hallo zusammen,

meines Erachtens ist es völlig falsch, das Thema Storage und Performance am verwendeten Protokoll fest zu machen.

Ob ich nun FC, FCoE, iSCSI oder NFS im ESX Umfeld einsetze, alles muß sich mindestens folgenden Fragen unterwerfen.
- Ist die erforderliche Verfügbarkeit gewährleistet?
- Genügt die Lösung unseren heutigen/zukünftigen Performance Ansprüchen?
- Wie viele Systeme teilen sich den Storage?
- Passt es in meine vohandene Infrastruktur?
- Existieren besondere BuRa (Backup & Restore) Anforderungen?
- Stimmt das Kosten/Nutzen Verhältnis?
....
..
.

Das eigentliche Problem ist aber, das kaum ein Kunde alle diese Fragen wirklich beantworten kann.
Bei Klein- und Mittelstandskunden gibt es kaum Storageadministratoren, bei Großkunden wird die Lösung von einer Vielzahl von Systemen mit den unterschiedlichsten Anforderungen genutzt, die sich im Verlaufe eines Tages massiv ändern können.

Daher ist es aus Sicht des Storage völlig egal, unter Verwendung welchen Protokolls die Hosts darauf zugreifen.
Natürlich hat jedes Protokol Stärken und Schwächen, aber im Grunde genommen spielen Sie bei einem vernünftigen Design keine große Rolle.

Einfach deswegen, weil Sie in der zeitlichen Gesamtbetrachtung kaum Auswirkungen zeigen können.

Moderne Rechner arbeiten intern im Nano Sekunden Bereich, das ist den Faktor 10^6 mal schneller als eine Disk.
Die aktuellen internen Bus Systeme arbeiten im MHz Bereich, dies ist immer noch um den Faktor 10^3 schneller als eine Disk.

Aus Sicht der Storage Performance ist es also vollkommen egal, welches Protokol ihr einsetzt, solange ihr beim Design keine elementaren Fehler einbaut!

Ich bin zwar kein Mitglied der Betonfraktion aus dem FC Bereich, aber einen 1 GigaBit Link zu sättigen ist kein großes Problem.
Das gilt aber auch für 4, 8 oder 10 GBit.

Du solltest nämlich nicht das Host Interface betrachten, sondern dein Storage Interface.
Ist das Host Interface der Engpass, kriegt der Host einfach noch ein weiteres Interface und der Drops ist gelutscht.

Völlig anders liegt der Fall, aber, wenn der Engpass am Storage Array Interface auftritt.
Und aus der Praxis kann ich sagen, das er fast immer hier auftritt!

Solange sich nur ca. 20 Host ein Array teilen ist das alles kein großes Problem, aber in den Rechenzentren von Großkunden teilen sich eine Vielzahl von Hosts ein Storage Array.

Und dann zählt nur noch dein Storage Design, ist das schlecht, ist alles andere nur Kosmetik.

Insofern muß ich dir zustimmen, die Anzahl der Disks muß zur Anforderung passen.
Und da gerade im ESX Umfeld fast ausschließlich Random IO's produziert werden, sollte man diese Art von IO Load auch als Grundlage seiner Berechungen annehmen.

Und beim Thema ESX, VAAI, FAST Cache, Tiered Storage Design und Multiprotokol Unterstützung führt aktuell kein Weg an EMC vorbei!
Ich kenne zwar die Preise von EMC (und EqualLogic) nicht, aber in den aktuellen CX4 & Celerra Arrays sind bereits heute alle Funktionen vorhanden.
Und soweit ich weiß, garantiert EMC, das kein anderer Hersteller in der Lage ist, bei gleicher Anzahl der verbauten Disks soviel Kapazität bereitzustellen wie EMC.

Bin mal gespannt wie es hier weiter geht.

Gruß
Ralf

[Schnurpf]

Hallo an alle,

ich geb's ja zu, der Post bezüglich der FC-Fraktion war eher eine Frust-Reaktion auf einen Kundentermin der letzten Woche. Mea culpa! Aus euren Reaktionen entnehme ich, dass ihr noch nie den Satz gehört habt: "iSCSI ist doch langsam" ...

@bla!zilla: Wie gut, dass Du es auschließlich mit kompetenten Leuten zu tun hast. Von meinen Kunden wissen nämlichen die Wenigsten, dass I/O x Blocksize = Durchsatz ist. Meine Kunden tendieren dagegen, und das ziemlich beratungsresistent, ihren Kapazitätsbedarf mit der maximal kleinsten Anzahl an Platten zu decken UND am Ende über die mangelnde Performance zu meckern.

kastlr bringt meine Erfahrung (mit kleinen und mittelständischen Kunden) auf den Punkt, ohne Storage-Fachleute bzw. entsprechende Kenntnisse können Fragen nach I/O-Bedarf etc. oft nicht beantworten werden. Trotzdem vermeiden es viele, eine herstellerunabhängige Beratung zu bezahlen.
Bezüglich der Aussagen von bzw. über EMC ... nun, ich für meinen Teil habe zu lange für zu viele US-Storage-Hersteller gearbeitet, um irgendwelchen Marketing-Aussagen noch irgendeine Beachtung zu schenken. kastlr, frag' dich selbst, welchen Wert solche Aussagen haben, welchen Realitätsgehalt und welchen Bestand?

Niemand kann völlig herstellerunabhängig sein, da jeder nur eine begrenzte Zahl an Systemen von einer begrenzten Zahl an Herstellern kennen kann. Insofern ist eine Vorauswahl im Kopf des Consultants immer schon gegeben. Diese banale Weisheit mal vorweg genommen, stimme ich kastlr zu, kundenspezifisches Storage-Design ist der richtige Weg zu einer Storage-Lösung. Aber, kastlr, irgendwas daran würde nicht stimmen, wenn "hinten" immer EMC herauskommt, oder?

Gruß
Schnurpf

P.S.: @eini: Sicher war dein Beitrag der gehaltvollste. Wie schade, dass Du ihn selbst gelöscht hast - hat dich der Mut verlassen?