SANsymphony trifft Veeam Backup and Replication – Ende gut, alles gut!
(der folgende Artikel wurde automatisch aus dem englischen Original übersetzt)
Fragen, Ergänzungen oder Anmerkungen zu diesem Artikel: melter[at]idicos.de
Seit Dezember 2019 ist das Plugin für den populären DataCore SANsymphony SDS veröffentlicht. Realisiert wurde es auf die einzig richtige Art und Weise: Mit voller Unterstützung und Validierung durch Veeam.
In dieser Artikelserie werden wir verschiedene Aspekte des Plugins behandeln:
Umfang, Funktionen und Lizenzanforderungen (einfach weiterlesen…)
Das vExpert-Programm wurde von VMware gegründet, um Mitglieder der Community für die Verbreitung und Bekanntmachung der Produkte und Dienstleistungen von VMware zu belohnen. Jedes Jahr wird der Titel vExpert an Personen verliehen, die in herausragender Weise zur Gemeinschaft beigetragen haben. Das können Blogger, Autoren, öffentliche Redner, VMUG-Leader, VMTN-Mitglieder, VCDX und andere IT-Experten sein, die ihr Wissen teilen und weitergeben.
Ja, es gibt Vorteile und Vergünstigungen (darauf werde ich später zurückkommen), aber darum geht es eigentlich nicht. Als vExpert geht es nicht darum, was man zurück bekommt, sondern was man selbst geben kann. Viele vExperts investieren einen großen Teil ihrer Freizeit in die Gemeinschaft. Die Vorbereitung eines Blog-Posts, einer VMUG-Präsentation oder die Organisation einer VMUG-Sitzung nimmt viel Zeit in Anspruch. Für diese Community-Arbeiter wurde das vExpert-Programm ins Leben gerufen.
Seit ich dem vExpert-Programm beigetreten bin, habe ich viele Freunde in der Community gewonnen. Auch wurde ich als Neuling von erfahrenen vExperts sehr herzlich willkommen geheißen. Um hier nur einige zu nennen: Ather Beg aus Großbritannien, Andreas (Lessi) Lesslhumer aus Österreich und Vladan Seget aus Reunion.
Datenbestände an zwei Orten identisch zu halten, wird in der hochverfügbaren IT immer wichtiger. War dies noch vor einigen Jahren ein sehr teurer Luxus für das Enterprise Segment, so dringt diese Anforderung in den letzten Jahren immer weiter in den SMB Bereich vor. Diese Methode nennt man Spiegel und sie kann prinzipiell auf zwei Arten umgesetzt werden:
asynchron – Der Datenabgleich erfolgt in definierten Intervallen. Dazwischen herrscht eine Differenz zwischen Quelle und Ziel.
synchron – Der Abgleich erfolgt transaktionsgenau, sodaß der Datenbestand zu jedem Zeitpunkt auf beiden Seiten identisch ist. Ein Schreibvorgang gilt erst als abgeschlossen, wenn auch Spiegelziel den Schreibvorgang bestätigt hat.
Eine Voraussetzung für Hochverfügbarkeit ist die Spiegelung der Daten (synchron, oder asynchron). Sind die Daten an zwei Orten (Rechenzentren) vorhanden stellt sich eine weitere Designfrage: Soll das Speicherziel als Kopie für den Notfall fungieren (Active-Passive), oder soll an beiden Orten aktiv mit den Daten gearbeitet werden (Active-Active)?
Active-Passive – In diesem Fall wird nur auf der aktiven Seite gearbeitet und die Daten auf die passive Seite übertragen (synchron oder asynchron). im Fehlerfall wird automatisch oder manuell (je nach Modell) umgeschaltet und die vorher passive Seite wird zur aktiven Seite. Sie bleibt dies, bis eine erneute Umkehr ausgelöst wird (Failback). Der Vorteil dieses Verfahrens ist, dass auch im Fehlerfall konstante Leistung garantiert werden kann. Die Ausstattung der passiven Seite muss natürlich identisch mit der aktiven sein. Der Nachteil besteht darin, dass nur maximal 50% der Ressourcen genutzt werden. Die anderen 50% stehen für den Fehlerfall bereit.
Active-Active – Hier werden die Ressourcen beider Seiten parallel genutzt und die Hardware kann somit effizienter eingesetzt werden. Dies bedingt aber, dass im Fehlerfall die Hälfte der Ressourcen wegfällt und somit nicht die volle Leistung garantiert werden kann. Active-Active Designs erfordern einen Synchronspiegel, da beide Seiten mit identischen Daten arbeiten müssen.
Active-Active Cluster gibt es in vielfacher Ausprägung. Es gibt klassischen SAN-Storage mit integrierter Spiegelfunktion, oder Software-defined-Storage (sds) bei der die Spiegelung nicht in Hardware, sondern in der Software-Schicht erfolgt. Ein Beispiel dafür ist DataCore SANsymphony. Eine Sonderrolle nimmt hier der VMware vSAN Stretched Cluster ein, der aber nicht Gegenstand dieser Betrachtung sein wird.
Ich werde im folgenden Abschnitt auf eine Besonderheit von LUN basierten active-active Konstrukten eingehen, die leider oft übersehen wird, aber im Fehlerfall zu Datenverlust führen kann. VMware vSAN ist hiervon nicht betroffen, da dessen Stretched Cluster auf einem grundlegend anderen Verfahren beruht.
Kürzlich hatte ich das Vergnügen, einen älteren ESXi 6.0 Host auf Version 6.7U3 zu aktualisieren. Kurz nachdem ich im Update-Manger auf “Standardisieren” klickte, brach der Prozess mit folgender Fehlermeldung ab:
Cannot execute upgrade script on host
Diese Fehlermeldung ist nicht wirklich spezifisch. Wenn man sie googelt, findert man etwa ein Dutzend möglicher Usachen für das Scheitern. Diese können z.B. sein:
Custom ISOs mit falscher Signatur für intel i40en Treiber Paket
Probleme mit FDM Agent (HA)
Keiner der oben genannten Punkte passte zu dem von mir beobachteten Problem. Ein guter Ausgangspunkt sollte ein Blick in vua.log auf dem betroffenen Host sein.
less /var/log/vua.log
Leider half das auch nicht weiter. Also schauten wir (nochmals) in die VMware Upgrade Matrix. Ein direktes Upgrade von ESXi 6.0 auf auf ESXi 6.7 U3 ist erlaubt, aber mit Einschränkung in einer kleinen Fussnote.
KB 76555 besagt, dass es ein Problem mit veralteten VIB Zertifikaten auf Hosts unterhalb einer bestimmten Buildnummer gibt.
ESXi 6.0 GA vor Build 9239799
ESXi 6.5 GA vor Build 8294253
Tatsächlich hatte unser ESXi Host eine Buildnummer von 7967664 (U3e), die sich im kritischen Bereich befand. Wir mussten also einige Patches nachinstallieren bis zum Stand Juni 2018 (ESXi600-201807001). Danch funktioniete das Upgrade problemlos.
Was war schiefgelaufen?
Natürlich hatten wir die Matrix während der Planungsphase Anfang März 2020 überprüft. Das ist eine Standardprozedur. Leider hat sich in der Zwischenzeit an der Matrix etwas geändert (die Fußnote wurde hinzugefügt). KB 76555 wurde im Mai 2020 aktualisiert, und das Problem betrifft Upgrades auf ESXi 6.7 Versionen nach dem 28. April 2020.
Was kann man daraus lernen? Unmittelbar vor Beginn der praktischen Arbeiten an einem Projekt nochmals alle Abhängigkeiten überprüfen.