Bevor noch jemand auf den Gedanken kommt, dass NetApp mich für die letzten Blog-Beiträge bezahlt hat, hier nun ein Beitrag zur HPE Store Virtual VSA.
In diesem Beitrag stelle ich die Funktionsweise einer HPE Store Virtual VSA vor.
Wer für eine IT-Landschaft verantwortlich ist, steht alle Jahre wieder vor der Entscheidung welche Storage Lösung für die lokale Infrastruktur in Frage kommt. Der Markt für Shared Storage Lösungen ist voll von Anbietern. Einer besser als der Andere (Natürlich).
Der Chef möchte auf jeden Fall…
eine Ausfallsicherheit, falls Gebäude A abrennt, soll die IT in Gebäude B noch weiter laufen und die Daten noch alle da sein.
…klar Chef kriegen wir hin.
wir nehmen ein Metro-Cluster gespiegeltes System. Das nimmt uns alle Sorgen und ist auch noch voll performant.
Euer Chef bekommt dann kurz Schnappatmung als er den Preis sieht und ist sich dann ziemlich sicher, dass was günstigeres braucht.
Um aus dieser Misere raus zu kommen beginnen wir einfach mal bei der Hardware. Unsere Ebene 0
Ebene 0: Die Hardware
Wir besorgen uns zwei Intel basierte Server. In diesem Fall zwei HPE DL380 G9, bestücken die Dinger mit 10 Festplatten, bauen über die 10 Festplatten ein RAID5 mit einer Spare Disk.
Ebene 1: Das Logische
Danach erstellen wir zwei logische Laufwerke. Ein kleines und ein sehr großes.
Ebene 2: Der Host
Bitte installiert an dieser Stelle auf beiden Servern VMWare vSphere ESX 5.5 oder höher. Wenn die Installation abgeschlossen ist und ihr auf die ESX Host per vSphere Client kommt, dann sucht nach neuen Datenspeichern und fügt die in Ebene 1 erstellten Logischen Laufwerke als lokale Datenspeicher hinzu.
Beide ESX Hosts haben nun lokale Datenspeicher. Jeder Host hat zwei Datenspeicher. Einen kleinen und einen großen.
Ebene 3: Die VSA virtual Machine
Nun erstellen wir auf jedem ESXi Host eine VSA virtual Machine. Diese bekommt eine riesig große vmdk-Festplatte in eurem großen Datastore.
Ebene 4: Die VSA Logik
An dieser Stelle vereinfachen wir das ganze jetzt extrem und sagen einfach, dass ich in der VSA virtuelle Volumes erstelle.
Natürlich gehört es dazu, dass ich eine HPE Centralized Management Console (CMC) Installiere, die beiden ESXi sich per iSCSI HBA“sehen“ können, meine Verkabelung und mein VLAN tagging korrekt ist, ich einen VSA Cluster stellt habe, etc. Ich möchte in diesem Blogpost aber auf einem höheren Level „fliegen“.
Ebene 5: Die Redundanz
Wenn meine beiden VSA virtual Machines sauber laufen, diese sich „sehen“ können, erstelle ich einen Spiegel über die virtuellen Volumes. Im Falle dieser Konstellation wird dies ein RAID10 sein. Alles was links geschrieben wird, wird auch rechts geschrieben. Hierbei ist dringend auf Latenzvorgaben seitens HPE zu achten. Ich kann so viel verraten: Mit einer 100 MBit Verbindung geht das nicht. Denken wir besser über 1 GBit oder noch besser 10 GBit nach. Je nach Entfernung, Medium, IOPS, etc.
Ebene 6: Der DataStore
Bis hier hin mitgekommen? Super! Wir haben also aus unseren lokalen ESXi Hosts lokalen Speicher zur Verfügung gestellt, darauf eine VSA virtual Machine erstellt, dieser virtual Machine eine riesen VMDK Datei auf unserem lokalen Storage gegeben. Da drauf ein virtual Volume erstellt und das auch noch zum anderen ESXi host gespiegelt.
Nun Sagen wir unseren ESXi Hosts nur noch, dass sie sich bitte per iSCSI an den VSA Cluster wenden sollen, wenn sie Datastores brauchen und schon haben wir das VSA Konstrukt fertig.
Auf diese VSA DataStores lege ich dann meine anderen virtuellen Maschinen und bin damit vor dem Verlust einer Seite halbwegs geschützt.
Aber was ist wenn ein ESXi Host mit seinem lokalem Speicher ausfällt oder neu gestartet wird ?
- Ihr habt vSphere HA die VMs klatschen aus und starten auf dem anderen Host wieder an
- Die VSA sagt euch, dass sie degraded ist. (Jop ist korrekt eine Seite ist weg. Das RAID 10 wird wieder neu aufgebaut)
- Tja vielleicht fehlt hier was in den Zeichnungen? Natürlich sollte eine 3. Instanz entscheiden können welche VSA gerade down ist. daher muss ein FOM (Fail Over Manager) irgendwo stehen
Wie ist die Performance?
- Raid 10 im selben Rack mit 10 GbE? Nicht schlecht!
- Raid 10 im selben Rack mit 1 GbE? Kannste machen, ist aber scheiße!
- Raid 10 über zwei Standorte mit 500m Entfernung ? Leute echt jetzt ? iSCSI RAID 10? Wer erwartet da Performance?
Puuuh.. Ich hoffe ihr habt eine Idee davon bekommen, was HPE Store Virtual VSA bedeutet. Ein bisschen ausführlicher werde ich dann in weiteren Blogbeiträgen.
Gruß
DerSchmitz
Schöne Ausführung, vor Allem sehr gut visualisiert, danke dafür!
Was mich bei VSA nur interessiert ist, wie HPE sich in dem Kontext einen automatischen Shutdown im Falle eines Stromausfalls vorstellt?
Für üblich würde ich eine vCenter Server Appliance ebenfalls auf den VSA-Cluster legen, aber wie können dann die VSA-nodes selbst herunter gefahren werden, wenn die vCSA selbst Bestand davon ist?
Das könnte mit meinem Verständnis nur dann zuverlässig funktionieren, wenn man die vCSA auf dem dritten Host – also ohne Redundanz – laufen lässt, damit sie den geordneten Shutdown koordinieren kann.
beste Grüße,
Peter
Hallo Peter, bei einer gerade Anzahl an VSA Knoten ist ein Zeuge erforderlich. Dieser kann als Appliance an einer dritten Location laufen. Auf den ESX Hosts lasse ich auf den lokalen Platten eine vMA von VMWare laufen und dadrin beispielsweise ein Plugin von APC um die Hosts geordnet herunter zu fahren.
Bei einer GERADEN Anzahl ist ein Zeuge notwendig…
Sorry da hab ich mich vertippt. Danke für den Hinweis.
Hallo Andre, ich fahre das übliche Mindest-Setup mit zwei Storage-Knoten plus einen FOM auf drittem ESX Host. Einen Shutdown-Manager (vMA) plane ich auf dem dritten Host neben dem vorhandenen FOM. Allerdings befindet sich dieser bisher nicht an einem dritten Standort, was nicht optimal ist. Einen vierten Host mö
Was meinst Du mit „ein Zeuge“, bei ungerader Anzahl von VSA-Knoten?
„Raid 10 über zwei Standorte mit 500m Entfernung ? Leute echt jetzt ? iSCSI RAID 10? Wer erwartet da Performance?“
Warum keine 10GBE über 500m? Was spricht dagegen?
Hi Peter, mit Zeugen meinte ich den FOM. Hast du aber eine VSA über drei Standorte oder eine ungerade Anzahl an Knoten benötigts du den FOM nicht zwingend. Es ist nämlich immer eine Meinungsmehrheit vorhanden wenn du drei oder mehr ungerade Knoten hast.
10 GbE im RAID 10 über 500m sind schon okay. Ist aber für Workloads bei denen es auf niedrige Latenzen ankommt nicht gerade optimal. Da hängt es dann auch stark davon ab mit welchen Platten die Nodes bestückt sind.
Latenz? Bei einem richtigen 10Gbit Switch wie z.B. HPE FlexFabric 5700 über iSCSI und 420m gab es noch nie Probleme. Zumal ein SSD-Tiering viel abfangen kann.
Datenblatt:
High-performance switching
Cut-through and non-blocking architecture delivers low latency (~1.5 microsecond for 10GbE)
for very demanding enterprise applications.
Hallo Gunnar, Danke für deinen Kommentar. Bei der Latenz geht es nicht nur um die Switching Kapazität. Ich persönlich setze die 5700er und 5900er von HPE sehr gerne ein. Die Dinger sind gut und haben eine fette Backplane. Die Latenz kommt zum Einem durch die Strecke und das Übertragungsmedium zustande, zum Anderen durch die Zeit, die das Remote System zum Acknowledge des Writes braucht. Ja eine VSA „kann“ performen. Dabei kommt es natürlich auf den workload an. Leider wird HPE die VSA in ihrer jetzigen Form langsam ausklingen lassen und sie durch Nimble Produkte ersetzen. Die VSA wird nicht weiterentwickelt, erhält aber noch 4-5 Jahre Support.
RAID5 im Ebene 0? Keine RAID 10 oder 6??
Ausfall eines Laufwerks und währen des Rebuild noch eine und Du verlierst deine RAID…oder?