Wie funktioniert eine HPE Store Virtual VSA

By | 17. Februar 2017

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

 

 

4 thoughts on “Wie funktioniert eine HPE Store Virtual VSA

  1. Peter

    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

    Reply
    1. DerSchmitz Post author

      Hallo Peter, bei einer ungeraden 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.

      Reply
  2. Peter

    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?

    Reply
    1. DerSchmitz Post author

      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.

      Reply

Kommentar verfassen