[DE] PernixData FVP – Fault Domains erklärt


Heute geht es um ein weiteres FVP Feature, die so genannten „Fault Domains“ (FD) und wo diese hilfreich bzw. ein Muss sind.

Wie in einem kürzlich aktualisierten Artikel beschrieben, ist die deutschsprachige Region noch immer bekannt dafür, verhältnismäßig häufig synchron gespiegelte Storage Systeme einzusetzen. Diesen Anforderungen muss FVP als Storage Performance Plattform natürlich entsprechend berücksichtigen.

Kommt mit FVP die Lesende- und Schreibende-Beschleunigung Beschleunigung zum Einsatz, so möchte man nicht nur sicherstellen, dass zusätzliche Kopien zwecks Fehlertoleranz geschrieben werden, sondern auch steuern, wo dies geschieht.

Mittels Fault Domains ist es möglich die eigenen physikalischen Gegebenheiten nachzubilden, um so Kontrolle darüber zu gewinnen, wo die zusätzlichen Kopien geschrieben werden. Dies ist also ein Muss, wenn es um die Kombination mit synchron gespielten Storage Systemen geht, vor allem dann, wenn dies Storage Systeme räumlich getrennt stehen.FVPwFD2

Noch ein paar Worte zu dem synchron gespiegelten Storage Systemen. Als Anforderungen aus Sicht von FVP, muss es sich bei dem darunterliegenden Storage System um ein vMSC kompatibles System handeln, bei dem alle Datastores in beiden Rechenzentren zugreifbar und im Fehlerfall auch wirklich beschreibbar sein müssen. Ideale Beispiele dafür wären EMC VPLEX, IBM SVC, DataCore SANsymphony-V, welche alle einen nonuniform Zugriff ermöglichen, indem immer alle Datastores in beiden RZs beschreibbar sind (Active/Active). Eine Array basierte Replikation, welche im Fehlerfall ein manuelles Eingreifen wie z.B. das Mounten von Datastores erfordert, kann somit nicht mit FVP und der Schreibenden-Beschleunigung kombiniert werden.

Nun zur Konfiguration, hierzu sind nur wenige Schritte nötig. Zunächst begibt man sich auf den Configuration Tab eines FVP Clusters und dann zum Unterpunkt Fault Domains.FaultDomains

Über den Button Add Fault Domain legt man einfach eine neue Domäne an und fügt anschließend die gewünschten ESXi Hosts über das + hinzu. Dies wird einfach für das zweite Rechenzentrum wiederholt.

Abschließend klickt man auf das + bei den Targets. Damit teilt man der Software mit, dass die Hosts aus RZ1, mit denen in RZ2 kommunizieren sollen.

Konfiguriert man anschließend eine VM oder einen Datastore für den Write-Back Modus, so ist es jetzt bei der Auswahl der Peer Hosts möglich, die Anzahl der Kopien wie folgt zu definieren.ConfigureWBwFD

  • In same Fault Domain“ – Das bedeutet, dass die zusätzliche(n) Kopie(n) für die Fehlertoleranz nur innerhalb der gleichen Fault Domain, sprich Gruppe von Hosts im gleichen RZ, stattfindet und NICHT auch im andere RZ geschrieben wird.
  • In different Fault Domain(s)“ – Umgekehrt wird damit wird festgelegt, dass die Kopie(n) auf jeden Fall auf einem Host der jeweils anderen Fault Domain, sprich auf einem Host im jeweils anderen RZ, geschrieben werden müssen.

Tipp: Es ist auch eine Kombination machbar. Pro VM/Datastore lassen sich bis zu zwei zusätzliche Kopien definieren. somit darf es auch eine Kopie in der lokalen FD und zusätzlich eine in der zweiten FD geben.

Wenn die definierte Write Policy nicht erfüllt werden kann, weil beispielsweise die Netzwerkkommunikation gestört ist, so wechseln die VMs im schlimmsten Fall für den Zeitraum der Störung auf den Write-Through Modus, also die rein Lesende-Beschleunigung.

Was die Verwendung der Fault Domains angeht, so ist dies nicht limitiert auf ganze Rechenzentren, sondern kann auch dazu genutzt werden, um z.B. Blade Chassis übergreifend die Fehlertoleranz zu gewährleisten. Dies ist vor allem dann interessant, wenn man als Beschleunigungsmedium RAM einsetzt. Denn somit kann man dem flüchtigen Medium RAM ein höheres Maß an Fehlertoleranz verleihen, indem die geschriebenen Daten Blade Chassis oder Rack übergreifend repliziert werden. Oder man stellt so sicher, dass die Writes ein Rack oder Blade Chassis nicht verlassen, um so die Latenz ggf. gezielt optimieren zu können.

Print Friendly

Related Post

It's only fair to share...Tweet about this on TwitterShare on LinkedInEmail this to someone

Leave a comment

Your email address will not be published. Required fields are marked *