Archiv für die Kategorie ‘HA’

Beispiel eines vmware High Availabe Stretched Clusters

Auch wenn dieses Thema schon weit ausgedehnt wurde, z.B. von Duncan Epping und Frank Denneman in Ihrem Deep Dive Buch , möchte ich ein Design Beispiel aus meiner Vergangenheit  hier gerne wiedergeben.

Beim Aufräumen alter Dokumente bin ich auf ein Konzeptpapier gestossen welches Grundlage dieses Artikels ist. Es diente damals dazu eine ältere vmware Produktionsumgebung die neu aufgebaut werden sollte so zu designen, das alle üblichen High Availability (HA) Fälle von der Umgebung möglichst automatisch bzw. mit geringem administrativen Eingriffen verfügbar bleibt. Also die üblichen Ziele: Hohe Verfügbarkeit mit möglichst minimalen Downtimes für alle Unternehmenswichtigen Services.

Ich denke das dieses Beispiel gut aufzeigt wie mit „normalen“, heute verfügbaren Mitteln, ohne Exorbitantem finanziellem Aufwand dieses Anforderung erfüllbar ist.

Ausgangssituation

Im genannten Umfeld war eine alte vmware 3.5 Umgebung sowohl Server- als auch Storage-seitig durch neues Equipment zu ersetzen. Um dem erwarteten Datenzuwachs Rechung zu tragen sollte goßzügig genug geplant werden. Ausserdem stand der Aspekt des möglichst einfachen, zeitlich kurzem und für die Anwender nicht spürbaren Umzugs auf die neue Umgebung im Anforderungs Katalog.

Die vmware 3.5 Umgebung war auf zwei Gebäude verteilt, die über Glasfaserleitungen miteinander verbunden sind (Distanz ca. 50 – 100 m). Somit kam das Konzept für einen sogenannten „Stretched Cluster“ zum Einsatz.

Bei einem Stretched Cluster sprechen wir von einer vmware vSphere Umgebung die sich auf zwei Räume / Gebäude / Brandabschnitte verteilt, aber von einem einzigen vCenter Server verwaltet wird.

 

Komplette Übersicht - vmware vSphere Stretched Cluster

Bild 1: Komplette Übersicht – vmware vSphere Stretched Cluster

Diese Bild zeigt den Architekturplan des gesamten Projektes und nimmt natürlich einige Elemente der Lösung vorweg.

Die Komponenten der Lösung

Wie man am Bild 1 sicher erkennen kann, besteht die Lösung aus folgenden Komponenten (ich nenne Hersteller nur dann wenn es für die Erklärung zwingend notwendig ist, anderfalls sind hier verschiedene Hersteller als Lieferanten einsetzbar):

  1. Auf Seite A und aus Seite B werden jeweils eine gleiche Anzahl gleicher Server als ESXi Hosts aufgesetzt.
  2. Auf beiden Seiten werden gleiche Storage Systeme installiert.
  3. Auf jeder Seite wird eine DataCore SDS mit SanSymphony V installiert

Zu den Details: In beiden Server Räumen der Seite A und Seite B werden praktisch indentische Hardware Umgebungen aufgebaut, beide Seiten sind autark betreibbar! Die Server und Storage Systeme sind so auszulegen das im Worst-Case eine Seite allein die gesamte Last tragen kann.

Verbunden sind hierbei die Storage Systeme via Fibre Channel (in diesem Fall 8GB, es könnte aber auch mit iSCSI gearbeitet werden. Da DataCore in der planten Version kein NFS unterstützte sähe eine NFS basierte Lösung etwas anders aus). Die DataStores werden jeweils via synchronem Spiegel auf die andere Seite gespiegelt und stehen auch dort zur Verfügung.

Bitte denken Sie daran auch das vSphere Management Netz so redundant auszulegen, das später alle Ausfall Scenarien abgedeckt werden (warum heiß der „Single Point of Failure“ nur so ;-))

Das die Storage Verbindungen und natürlich auch das Produktivnetz (im Bild Hausnetz) redundant ausgelegt werden ist sicher selbstverständlich.

Die ganze Lösung wurde als sog. Non-Uniform stretched vSphere Cluster realisiert.

Uniform stretched Cluster

Ein Uniform stretched Cluster bedeutet das alle Hosts und alle Storage Systeme so verbunden sind das alle alles zu jederzeit „sehen“. Das heisst die ESXi Hosts haben permanent Zugriff auf alle Datastores jeder Seite.

Non-Uniform stretched Cluster

Ein Non-Uniform stretched Cluste bedeutet das die Hosts einer Seite auch nur „aktiv“ mit den Datastores der Storage Systeme dieser Seite verbunden sind. Im Fehlerfall muß nun eine, wie auch immer geartete Lösung dafür sorgen das auf die jeweils andere Seite geschwenkt wird. Die Daten werden also „nur“ auf Storage Ebene repliziert (synchron oder asynchron). Hier bieten viele große Storage Hersteller eigene Plugins für „gutes“ Geld an.

Ausfall Scenarien

Betrachten wir nun nacheinander die verschiedenen Ausfall Scenarien und wie sich die Umgebung dann jeweils verhalten soll.

Ausfall eines Hostes auf einer Seite

Fällt ein Host einer Seite des Clusters aus, so greift vmware vSphere HA und startet die gecrashten VMs auf den verbleibenden Hosts dieser Seite neu. Damit das funktioniert sollte via DRS Rules und den dort konfigurierbaren Affiniti Rules über Gruppen eine „Sollte immer auf dieser Hostgruppe laufen“ Regel definiert werden. Diese erkläre ich jetzt hier nicht, vielleicht in einem anderen Artikel irgendwann. Kurzgesagt bedeutet diese Regel, das VMs im Normalfall möglichst auf bestimmten ESXi Hosts einer Gruppe laufen sollen. DRS sorgt dann dafür das dieses so ist. In unserem Fall haben wir zwei Hostgruppe: Hosts der Seite A und Hosts der Seite B. Hintergrund: Wir arbeiten mit einem Non-Uniform Cluster und die VMs auf den Hosts der Seite A sollen auch das Storage der Seite A nutzen um z.B. mögliche Laufzeiten (und Latenzen) zur anderen Seite zu minimieren.

Bild 2: HA-Host einer Seite fällt aus

Bild 2: HA-Host einer Seite fällt aus

Ausfall eines Datastores einer Seite

Falls ein Datastore einer Seite ausfällt (siehe Bild 3) so kommt es darauf an was genau unter „Ausfall“ zu verstehen ist. Fällt „nur“ eine Platte des Storage Systems aus, so haben wir hoffentlich kein direktes Problem für unsere VMs da dort durch RAID usw. der Fehler für den Host und die VMs transparent abgefangen wird. Sollte es dagegen zu einem Totalausfall eines Storage Bereiches dieser Seite kommen, fallen die VMs herunter und vmware HA kann zum Einsatz kommen, allerdings nur dann, wenn jetzt auf die gespiegelten Daten der anderen Seite zugegriffen werden kann!

Dazu muss jetzt, wie vorher (unter Non-Uniform Cluster) beschrieben, jemand die Storage Pfade „umschalten“, sprich die gespigelten Datastores der Seite B nun als aktiv an die Seite A anbinden. Unsere Lösung die hier projektiert wurde basiert auf  DataCore SANsymphony, welches einen transparenten Failover bereitstellt. Dieser schaltet im Normalfall so schnell um, das vmware HA garnicht erst zum Einsatz kommen muss. DataCore sorgt in unserem Fall auch für den Synchronen Spiegel.

Bild 3: HA Datastore einer Seite fällt aus

Bild 3: HA Datastore einer Seite fällt aus

Ausfall einer gesamten Host Cluster Seite

Kommen wir nun zu dem Fall das uns eine gesamte vmware Cluster Seite ausfällt. Hier greift wieder vmware HA, denn wir haben ja in unserer DRS Rule gesagt „sollte“, nicht „darf nur“. HA versucht nun die VMs der Seite A die ja mit den Hosts gestorben sind auf der Seite B neu zu starten. Geht das? Tja in unserem Fall müssen die Synchronen Datastores die von Seite A auf Seite B gespiegelt wurden dort „aktiv“ sein, oder kurz gesagt müsste jemand die Datastores der Seite A auf den Hosts der Seite B „aktiv“ schalten! Somit haben wir zwei Möglichkeiten. Diese können gern im Anschluß diskutiert werden.

Bild 4: Komplette ESXi Cluster Seite fällt aus

Bild 4: Komplette ESXi Cluster Seite fällt aus

Bitte daran denken, daß in diesem Fall auch die vCenter Server VM betroffen sein kann. Das bedeutet allerdings nur, das für die Zeit des wideranstartens durch vmware vSphere HA kein DRS läuft! DRS ist eines der wenigen Funktionen die nur funktionieren wenn der vCenter Server läuft.

Ausfall einer Seite ohne virtuelle Storage Pools

Betrachten wir im Anschluß an den vorhergehenden Failure Fall nun den Ausfall einer ganzen Seite, sowohl Hosts als auch Storage. Was hier passiert ist etwas aufwändiger. In diesem Fall haben wir keine virtuellen Storage Pools, sondern „klassische“ Anbindung. Es läuft so ähnlich wie unter „Ausfall eines Datastores einer Seite“ ab. Irgendjemand (z.B. via Skript) muß die Synchon gespiegelten Datastores der Seite A auf Seite B den Hosts der Seite B „aktiv“ schalten. Nun sehen diese Hosts die VMs und vSphere HA kann mit dem Restart der VM beginnen. Knackpunkt ist hier die Umschaltung der Storage Pfade. Wie gesagt „Irgendjemand“ muss das tun! Nur ist der Irgendjemand dann auch da und sieht das Chaos kommen ;-( ?

 

Bild 5: Ausfall einer kompletten Seite - Hosts und Storage

Bild 5: Ausfall einer kompletten Seite – Hosts und Storage

Ich selbst bin KEIN Freund von solchen „Desaster-Skripten“ denn die wollen gepflegt sein (bei jedem Storage Umbau usw. muss nachgepflegt werden). Storage Pfade sind auch nicht gerade „lesefreundlich“ und entsprechendes KnowHow sollte vorrätig sein.

Ausfall einer Seite mit virtuellen Storage Pools

Aus den genannten Gründen im letzten Abschnitt habe ich damals die Lösung mit sogenannten virtuellen Pools favorisiert. Hierbei sollte in diesem Konzept, DataCore einer der Pioniere der Storage Virtualisierung zum Einsatz kommen. DataCore stellt den angebunden ESXi Hosts virtuelle Datastores zur Verfügung die auf virtuellen Storage Pools beruhen. Diese virtuellen Pools bestehen aus Storage Bereichen beider Seiten und beinhalten unter anderem den Synchronen Spiegel von Seite A auf Seite B. Somit ist für die ESXi Host der komplette Storage Aufbau intransparent. Sie sehen nur den Pool. Fällt uns nun das Storage System einer Seite, oder die gesamte Seite aus, so sorgt DataCore dafür das die ESXi Hosts weiter den Pools so sehen als sei alles in Ordnung! Im Fall des Ausfalls der gesammten Seite muss allerdings vSphere HA auch noch arbeiten. Da dieses aber, bei korrekter Implementierung (siehe z.B. hier) absolut zuverlässig arbeitet, sollte die tatsächliche Downtime selbst in diesem Extrem-Fall relativ kurz sein. Das Schöne dabei ist, das eigentlich niemand „geweckt“ werden muss. Das System arbeitet alleine an der Wiederherstellung.

 

Bild 6: Totalausfall einer Seite mit virtuellen Pools

Bild 6: Totalausfall einer Seite mit virtuellen Pools

Abschussbemerkungen

Auch wenn ich selbst hier DataCore präferiere, kann das gezeigte Scenario auch mit anderen Storage Lösungen ähnlich aufgebaut werden. Ausserdem sollte trotz solch einer Lösung NIE auf ein funktionierendes Backup Konzept mit entsprechender Lösung verzichtet werden (soll es tatsächlich geben 😉 )

Übrigens kann DataCore durch seine „Proxied Volume“ Funktion auch beim Umzug einer alten- auf eine neue Storage Lösung sehr gute Dienste leisten.

Über eine Diskussion dieser Lösung würde ich mich freuen, denn soweit mir bekannt ist wurde diese Konzept aus verschiedenen Gründen nie umgesetzt. Schade oder?

Somit ist es mir gelungen durch ein paar „Nachteinsätze“ doch wieder einen Artikel zu erstellen.

 

Online Project Management

Kurze Vorstellung des Buches „VMware vSphere Resource Management Essentials“

In diesem Beitrag möchte ich ein recht neues Buch aus dem Packt Publishing Verlag (erschienen im Feb. 2014) vorstellen. Dieses Buch wurde mir freundlicherweise als eBook von Packt Publishing zur Verfügung gestellt. Dieser Verlag hat in der letzten Zeit einige sehr interessante Bücher gerade zu VMware Themen herausgebracht. Einige davon habe ich selbst gelesen und muß sagen das die Bücher zwar sehr unterschiedlich von der „Tiefe“ der Wissensvermittlung sind, aber meistens recht praxisnah mit hohem „Daily use“.

 © by Packt Publishing

© by Packt Publishing

Inhalte des Buches

Der Titel des Buches war für mich etwas irreführend. Das heißt nicht das er komplett falsch währe, nur habe ich mir etwas anderes darunter vorgestellt. Eher ein Buch welches einen Einführung in die VMware Metriken gibt, ähnlich dem im Artikel („vmware Performance Management – die wichtigsten Metriken“ ) beschriebenen nur ausführlicher mit mehr Hintergrund.

Es werden durchaus wichtige Metriken besprochen und erklärt, aber der Schwerpunkt ist eher ein allgemeiner.

Zu den Inhalten:

von dem neuen App HA über Ballooning, DRS, Cluster Maximums bis zu VAAI dem vCenter Operations Manager im Überblick wird alles angesprochen was einen angehenden VMware Consultant oder Administrator interessieren könnte.

Kenner der Plattform finden sicher auch den einen oder anderen interessanten Aspekt, sind aber aus meiner Sicht nicht die ersten Adressaten dieses Buches.

Kritikpunkt

Einzige echte Kritik von meiner Seite ist: VMware Metriken werden meist NUR mit ihrem ESXTOP Bezeichner angesprochen! Ein Beginner kann aber z.B.  unter Umständen mit %RDY wenig anfangen. Eine kuze Erklärung das damit CPU.Ready gemeint ist würde enorm helfen. Hier sollte in einer späteren Auflage nachgearbeitet werden. Oder es gibt einen Anhang in welchem die wichtigsten Metriken zusammengestellt werden.

Fazit

Ich denke der Autor möchte einen guten Überblick über die Plattform VMware vSphere 5.5 geben. Dieses ist gelungen! So ziemlich alle Themen die auch im VMware Kurs „vSphere Install Configure Manage 5.5“ behandelt werden, werden hier angesprochen und z.T. vertieft. Somit ist dieses Buch aus meiner Sicht eine sehr gute Quelle um sich auf den VCP-DCV 5 vorzubereiten.

Sehr gut finde ich, das zu vielen Bereichen auch hilfreiche oder weiterführende KB Artikel angeführt werden (KB = KnowLedge Base). Das fehlt mir in einigen Büchern zu VMware.

Daher kann man der Zielgruppe „angehende“ VMware Consultants und Administratoren, besonders als Ergänzung zum vSphere ICM 5.5 Kurs, dieses Buch wärmstens empfehlen. Kenner der Plattform sollten dagegen erst einen Blick in das Buch werfen um nicht enttäuscht zu sein. Aber auch die finden sicher einige Fakten die sie so vielleicht nicht wußten.

Angesichts des anvisierten €-Preises macht man auf keinen Fall etwas falsches wenn man sich, als Mensch im vSphere Umfeld, dieses Buch zulegt (siehe Buchlink am Anfang).

Weitere Bücher aus gleichem Verlag die ich habe und empfehlen kann:

Learning PowerCLI

Learning PowerCLI

Sehr schöne Einführung in die Power Shell Schnittstelle von VMware.

 

 

 

 

 

 

Troubelshooting vSphere Storage

Troubelshooting vSphere Storage

Wer sich nicht vor der Command Line scheut und im VMware Storage Bereich Troubleshooting betreiben muß ist hier  genau richtig.

vmware HA – Alte und wichtige Funktionalität, in vSphere 5 völlig neu erstellt, aber immer wieder falsch verstanden

vmware HA ist mittlerweile fast bis in die kleinste Edition gewandert. In vSphere 5 wurde HA komplett neu von vmware geschrieben. Trotzdem gibt es immer wieder Unklarheiten, Falschkonfiguratione und div. „Unwissen“ über Einstellmöglichkeiten.

Ein kurzes Vorwort zur geplanten Serie von Artikeln

In meinen Augen ist der vmware Mitarbeiter und Blogger Duncan Epping (http://www.yellow-bricks.com) der Guru in Sachen HA und auch DRS.

Ich möchte nun hier einige dieser sehr nützlichen Artikel in deutsch wiedergeben und geg. ergänzen. Mein besonderer Dank geht hier an Duncen der mir auf Anfrage sofort erlaubt hat Seine Artikel als Grundlage zu nutzen! Am Ende meines Artikels verweise ich daher immer auf das Original.
__________________________________________________

Host isolation response – Was ist das?

HA oder High Availability als vmware Funktion ist gedacht den Ausfall eine ESX/ESXi Hostes abzufangen in dem die, auf dem ausgefallenen Host laufenden VMs auf den verbleibenden Hosts neu gestartet werden.

Soweit so klar. Betrachtet man die Funktionsweise von vmware HA dann kommt man leicht zu dem Schluß: „Was passiert wenn der Host gar nicht ausgefallen ist, sondern nur HA einen Ausfall meldet?“ Dieses würde passieren wenn die ESX/ESXi Hosts des HA Clusters keinen Heartbeat von einem Host mehr erhalten (repektive der Master).

Der so isolierte Host wird sich selbst ebenfalls als isoliert betrachten (genauer Ablauf wir jetzt hier nicht behandelt). Was soll dieser Host nun mit seinen VMs tun?

vmware HA Prinzipaufbau

vmware sieht für diese Fall drei Möglichkeiten vor:

Diese bedeuten:

  • Leave powered on     := „Du erkennst Dich isoliert! Lass Deine VMs eingeschaltet“ (Default)
  • Power off                     := „Du erkennst Dich isoliert! Schalten Deinen VMs den Strom ab“
  • Shut down                   := „Du erkennst Dich isoliert! Fahre Deine VMs herunter“

Duncan Epping hat nun eine sehr nette Tabelle veröffentlicht die Hinweise gibt was in welcher Situation einzustellen sinnvoll sein kann:

Wie wahrscheinlich ist es das der Host noch Zugriff auf den Datastore hat? Wie wahrscheinlich ist es das der Host noch Zugriff auf das VM Netzwerk hat? Empfohlene Isolation Response Policy Erklärung
Wahrscheinlich Wahrscheinlich Leave Powered On Die VMs laufen einwandfrei, warum sollen sie ausgeschaltet werden?
Wahrscheinlich Nicht Wahrscheinlich Entweder Leave Powered On oder Shutdown Wähle Shutdown um HA zu erlauben die VMs auf den verbleibenden Hosts zu restarten, da diese wahrscheinlich auch Datastore Zugriff haben.
Nicht Wahrscheinlich Wahrscheinlich Power Off Nutze Power Off um zu verhindern das zwei Instanzen der gleichen VM Zugriff auf das VM Netz haben
Nicht Wahrscheinlich Nicht Wahrscheinlich Leave Powered On oder Power Off Wähle Leave Powered On wenn es möglich ist den Netzwerk- oder Datastore-Ausfall zu beheben. Anderfalls Wähle Power Off

Besten Dank an Duncan und hier der Link zum Original Artikel:
Which isolation response should I use?