Erfahrungen mit HP VSA als Alternative zu physikalischer SAN?

Hallo Forenmitglieder!

In unserer Firma betreiben wir aktuell einen älteren VSphere 4.1 Cluster auf 3 Hosts und mit den Platten in einer IBM DS 3524.
Die aktuelle Überlegung ist, auf 2 Hosts mit je lokalen Platten (und SSD) umzusteigen. Statt der SAN soll eine HP VSA zum Einsatz kommen.

Alles schön und gut... transparentes Failover wäre auch gegeben.... aber wie sieht es mit der Performance aus?
Ich habe einen "Seitenhieb" bekommen, dass ich hier Performance Probleme mit der VSA bekommen werde.
Kennt das / hat das jemand?

Kann mir jemand mehr zur VSA sagen, ob diese wirklich so viel Leistungseinbruch im Vergleich zu unserer "alten" DS 3524 mit sich bringt??

Alternativ muss ich 2 V3700 besorgen und mit Veeam replizieren und 2 unterschiedliche LUNs sichtbar machen für den Failover...

Ich freue mich über Meinungen dazu!

Thx!
mfg Terrean

Hallo

die Frage ist, was du oder ihr von der VSA erwartet?! Und was ihr darauf betreiben wollt. Am besten schaust du dir mal die Performancedaten der ESX-Hosts an.
Dahinter steckt das Produkt, welches du auch als Lefthand bzw. heute HP P4000 Store Virtal kennst. Hierbei handelt es sich um iSCSI.
Interessant ist vorallem die Anbindung. Wenn das nur mit Gbit LAN passiert wirst du da mit gut 100M/s im Streaming rechnen können. Wenn es dir auf IOPS ankommt, stellen sich die Fragen wie Raid Leben, Menge der Platten und Rotationsgeschwindigkeit. Bei 10Gbit LAN sieht die welt anders aus, da könnten eher die Platten den Bottleneck makieren.
Wichtig ist auf jeden Fall ein HW-Raidcontroller mit möglichst großen Cache.

Ich weiß dass wir das für Kunden Einsetzen, sowohl in Hardware als auch die ein oder andere VSA Lösung. Ich kenne auch Kunden die das selbst betreiben. Den einzigen Knackpunkt den ich insgesamt kenne, ist die Krux mit dem 1Gbit LAN und Sequentiellen IO. Gerade bei Backup Operationen oder anderen großen Streams merkt man das halt schon deutlich. Ansonsten gibt es aber keine allzugroßen Probleme im laufenden Betrieb. Es handelt sich bei den Fällen die ich kenne aber auch nich um Datenbanken.

Die VSA(iSCSI) ist halt durch sein Prinzip langsamer als das SAN.
Du hast halt das weniger an Performance, was durch den Sync auf den anderen Host flöten geht.
Teilweise wird das durch Loadbalancing via Heartbeat ausgeglichen.

Ich hatte in den ersten Versionen Probleme mit der VSA was Sync usw angeht, bis hin zum Totalausfall(kompletter Neuinstall nötig).
Teilweise gab es Probleme zwischen ESXi Updates und den VSAs.
Da VMWare ja nun ihr eigenes vSAN haben und nicht mehr das HP VSA(vorher VMWare VSA) hast du bei Problemen, das typische hin und her geschubste zwischen HP und VMWare.

Alternativ kannst du eben vSAN von VMWare einsetzen. Das ist sogar schneller als dein SAN. Brauchts aber eine SSD pro Host.

Wir setzen nur noch SAN oder vSAN ein.

Hallo,

Danke schonmal für die Antworten!
Eckdaten der geplanten neuen Hosts:
2 Hosts, je:

IBM x3650 M4
Xeon E5-2630v2, 6-core, 2,6Ghz , 2 Sockel
256 GB RAM
2x 240GB SSD
14x 900GB 10k SAS HDD
ServeRAID M5100 SSD 2GB Flash Upgrade f. Raid5
M4 Plus HDD Expander Kit


...also 2100 IOps für die Disks ohne RAID Penalty eingerechnet (ob Raid5, Raid6 oder Raid10 weiss ich noch nicht)
SSD ebenso nicht eingerechnet.

Die Server würden je an die (ebenso neuen) Core Switches HP 5406 zl (aktuelle Planung) angeschlossen werden. Je nachdem 10GBE oder SFP+

Miteinander werden die CoreSwitche dann über Glas vernetzt werden (weiss nicht ob ich hier 10GB schaffe, ansonsten ein Trunk über mehrere Anschlüsse)


Wir betreiben ca. 20 virtuelle Server. Exchange wird wegfallen, auch sind keine nennenswert großen Datenbanken darauf - die sind extern "in der Cloud"

Ich bin noch etwas stutzig, hier von der Hardware SAN auf die virtuelle SAN zu gehen.
Anlass hat hier auch ein anderer Distributor gegeben, der durch diesen 3-fachen Virtualisierungsaufbau einen 30-60% I/O Performanceverlust attestiert... Also erst die Appliance, dann den Blockspeicher als iSCSI freigeben und in der VMWare dann nochmal angebunden, als VMFS virtualisiert und darauf die VMDKs (3. Virtualisierungsschicht)

Gerade das "hin und her Geschubse" zwischen VMWare und HP will ich vermeiden. Und einen Totalausfall sowieso..

Sonst hätte ich gern die V3700 in zweifacher Ausführung, nur ist halt kein transparentes Failover gegeben. Wobei mir eine Variante mit Veeam, das einfach zwischen 2 unterschiedliche LUNs repliziert, auch gefallen könnte...

Wir sind kein IT-Unternehmen und müssen uns hier mehr auf Automatismen und externe Dienstleister verlassen...

Die Frage ist halt, was eure jetzige Umgebung durchsetzt an IOPS.

Ich kann dir aus der Praxis als IT-Dienstleister für große Kunden sagen, dass es sowohl möglich ist mit einem oder zwei Hardware Servern eine große Storage Box lahmzulegen und andersherum kann man mit einem ganzen Fuhrpark an Servern eine Storage Box auch langweilen.

10Gbit bringt dir auf jeden Fall nur was für iSCSI, wenn du es auch über die Switche weiter reichen kannst.

30% würde ich eher als Max ansehen. 60% ist meiner Meinung nach Blödsinn und reines Verkaufsgeblubber.
Den Nachweis würde ich gern mal sehen.

Ich kann dir nur zum virtual SAN von VMWare raten.
Ist bereits im ESXi implementiert(keine Installation), einfach zu konfigurieren und hat richtig Leistung durch die SSD.
Du brauchst auch kein Hardware-Raid. Hat auch den Vorteil dass du es konfortabel erweitern kannst. (einfach Platte dazu stecken-fertig)
Die Redundanz etc baut sich das vSAN selbst.
Und eben alles aus einem Hause.
Allerdings kommt es auch darauf an was die 20 Virtuellen so an Bedarf generieren.

Das die HP VSA nict so das wahre ist, sieht man auch daran dass HP einem die schon seit einer ganzen Weile regelrecht hinterher wirft.
Die 1TB Variante war glaube ich kostenlos. Und zu jedem DL380 gabs sogar die 2er umsonst dazu.

Wieder Danke für eure Antworten.
IOPs Bedarf wurde ehrlich gesagt wenig überwacht... laut einem 24h Monitoring mit dem IBM Storage Manager Performance Monitor waren es auf den 3 Raid5 LUNs total 1785, 953 und 1997 IOs maximal.

Was die einzelnen Server dediziert BRAUCHEN kann ich leider zu wenig sagen. Helfen die Screenshots anbei dabei?

@ ymahakuesser
Du meinst schon die VMWare VSA...?
Ich finde hier widersprüchliche Infos. Zb. dass sie im Vergleich zur HP VSA eher schlecht abschneidet.
http://3cvguy.com/vsphere-vsa-vs-hp-p4000-vsa/
(Den link habe ich genommen wegen der Tabelle.)


Sorry, wenn ich hier mit viel Halbwissen hantiere, aber ich bin mehr ein Mädchen-für-alles-Admin bei uns und kann mich lediglich in der Freizeit fortbilden ;-)

Und hier auch noch was Aktuelles aus dem vCenter:

Die VMWare VSA ist die HP VSA. Wurde nur von VMWare unter eigenem Namen vertrieben.
Die ist aber vor kurzem von VMWare virtual SAN(eigene Lösung) abgelöst worden.
http://www.vmware.com/de/products/virtual-san/

VMWare virtual SAN(vSAN nicht VSA) ist mit VSA kaum vergleichbar.
Sie haben beide das gleiche Ziel, sind aber grundverschieden aufgebaut.
VSA ist ja nur pro Host eine virtuelle Appliance mit virtueller Disk die lokal auf dem Host liegt und auf den anderen Host und seiner Appliance synchronisiert wird,
und dann mittels iSCSI dem ESXi-Hosts als iSCSI-SAN wiederrum präsentiert wird.
Mit allen Performancenachteilen von iSCSI usw.
Erweitern usw ist ein riesen Aufwand.

Bei vSAN nimmt der ESXi einfach alle Laufwerke, egal wie groß und schnell, egal ob JBOD, Hardware- oder Software-RAID, egal ob IDE, SATA, SAS oder FC und wirft diese in einen Pool, baut sich daraus seinen redundanten Store zusammen und beschleunigt das Ganze mit einer SSD.
(gibt aber natürlich gewisse Hardwarevorraussetzungen als Supportbedingung)
Von der Geschwidigkeit her ist es, bei vergleichbarer Dimensionierung, schneller als jedes Entry/Mid-Level-SAN.

Das Ganze ist selbst für Leien einfach übern vSphere-Client bzw. vCenter konfigurierbar.
Mitlerweile wird vSAN selbst bei größeren Clustern (20-32Nodes)eingesetz und erreicht in solchen Systemen leicht 2mio IOS.

Nicht umsonst werden selbst SANs mitlerweile intern "virtualisiert".(leienhaft erklärt)

Wenn man sich das Bild vom Controller Anschaut, müsstet du für "gleiche" Performance deine Lösung für diese Eckpunkte Planen

~2100IOPS (netto!)
~34% Read Anteil (recht wenig, wie ich finde)
ggf. ~ 24% Cache Hits (Sind Quasi Kostenfreie Lese Operationen)