Hystax Cloud Migration: Wir springen durch die Clouds

Einer der jungen Akteure auf dem Markt der Disaster Recovery-Lösungen ist das Unternehmen Hystax – ein russisches Start-up aus dem Jahr 2016. Da das Thema der Notfallwiederherstellung sehr populär ist und der Wettbewerb auf dem Markt extrem hoch ist, entschloss sich das Start-up, sich auf die Migration zwischen verschiedenen Cloud-Infrastrukturen zu konzentrieren. Ein Produkt, das eine einfache und schnelle Migration in die Cloud ermöglicht, wäre auch für die Kunden von „Onlanta“ – Nutzern – von großem Nutzen. Oncloud.ru. So kam ich mit Hystax in Kontakt und begann, seine Möglichkeiten zu testen. Was daraus geworden ist, berichtige ich in diesem Artikel.

Das Hauptmerkmal von Hystax ist seine breite Funktionalität zur Unterstützung verschiedener Virtualisierungsplattformen, Betriebssysteme und Cloud-Dienste, was es ermöglicht, Ihre Arbeitslasten von überall her und wohin auch immer zu verlagern.

Dies ermöglicht die Schaffung von nicht nur DR-Lösungen zur Verbesserung der Ausfallsicherheit von Diensten, sondern auch eine flexible, schnelle Migration von Ressourcen zwischen verschiedenen Plattformen und Hyperscalern, um Kosten zu sparen und die beste Lösung für einen bestimmten Dienst zu einem bestimmten Zeitpunkt zu wählen. Neben den auf dem Titelbild genannten Plattformen arbeitet das Unternehmen auch aktiv mit russischen Cloud-Anbietern zusammen: Yandex.Cloud, KROK „Cloud-Dienste“, Mail.ru und vielen anderen. Außerdem ist zu erwähnen, dass das Unternehmen 2020 ein F&E-Zentrum gegründet hat, das sich in Skolkovo befindet. 

Die Wahl eines bestimmten Lösungsansatzes durch viele Akteure auf dem Markt spricht für eine gute Preispolitik und hohe Anwendbarkeit des Produkts, was wir in der Praxis überprüfen wollten.

Also wird unsere Testaufgabe darin bestehen, von meiner Testumgebung VMware und physischen Maschinen zu einer Plattform des Anbieters zu migrieren, die ebenfalls unter VMware verwaltet wird. Ja, es gibt viele Lösungen, die eine solche Migration ermöglichen, aber wir betrachten Hystax als ein universelles Mittel, und die Migration in allen möglichen Kombinationen zu testen, ist einfach eine unrealistische Aufgabe. Außerdem ist die Cloud Oncloud.ru speziell auf VMware aufgebaut, deswegen interessiert uns diese Plattform als Ziel in hohem Maße. Im Folgenden werde ich das Grundprinzip der Funktionsweise beschreiben, das insgesamt nicht von der Plattform abhängt, und VMware kann von jeder Seite durch eine Plattform eines anderen Anbieters ersetzt werden. 

Im ersten Schritt muss Hystax Acura, das Control Panel des Systems, bereitgestellt werden.

Es wird aus einer Vorlage erstellt. Aus irgendeinem Grund war in unserem Fall die Vorlage nicht ganz korrekt und anstelle der empfohlenen 8 CPU und 16 GB wurde sie mit halb so vielen Ressourcen bereitgestellt. Daher darf man nicht vergessen, diese zu ändern, andernfalls kann die Infrastruktur innerhalb der VM, auf der alles aufgebaut ist, einfach nicht gestartet werden und das Portal wird nicht verfügbar sein. In Bereitstellungsanforderungen sind die benötigten Ressourcen sowie die Ports für alle Systemkomponenten ausführlich beschrieben. 

Auch bei der Zuweisung der IP-Adresse über die Vorlage gab es Schwierigkeiten, sodass wir sie über die Konsole ändern mussten. Danach kann man in die Weboberfläche des Admin-Panels wechseln und den anfänglichen Konfigurationsassistenten ausfüllen. 

Endpoint – die IP oder FQDN unseres vCenter. 
Login und Passwort – das ist klar. 
Hostname des Ziel-ESXi – einer der Hosts unseres Clusters, auf den die Replikation erfolgen wird. 
Zieldatenspeicher – einer der Datenspeicher unseres Clusters, auf den die Replikation erfolgen wird.
Öffentliche IP des Hystax Acura Control Panels – die Adresse, unter der das Control Panel verfügbar sein wird.

Es ist eine kleine Klarstellung zum Host und Datenspeicher erforderlich. Die Sache ist, dass die Replikation von Hystax auf der Ebene des Hosts und des Datenspeichers funktioniert. Ich werde später erklären, wie man für den Tenant den Host und den Datenspeicher wechseln kann, aber das Problem ist ein anderes. Hystax unterstützt nicht die Arbeit mit Ressourcen-Pools, das heißt, die Replikation wird immer in das Stammverzeichnis des Clusters erfolgen (zum Zeitpunkt des Schreibens dieses Materials haben die Leute von Hystax eine aktualisierte Version veröffentlicht, in der schnell mein Feature-Request zur Unterstützung von Ressourcen-Pools implementiert wurde). Auch vCloud Director wird nicht unterstützt, das heißt, wenn, wie in meinem Fall, der Tenant keine Administratorrechte für den gesamten Cluster hat, sondern nur für einen bestimmten Ressourcen-Pool, und wir Hystax Zugriff gewährt haben, kann es die VMs selbst replizieren und starten, aber es wird sie nicht in der VMware-Infrastruktur sehen, auf die es Zugriff hat, und folglich auch nicht weiter verwalten. Es ist notwendig, dass der Cluster-Administrator die VM in den gewünschten Ressourcen-Pool verschiebt oder in vCloud Director importiert.

Warum lege ich so viel Wert auf diese Punkte? Weil, soweit ich das Konzept des Produkts verstehe, der Kunde in der Lage sein sollte, jede Migration oder DR selbständig über das Acura-Panel zu realisieren. Die Unterstützung von VMware hinkt jedoch etwas hinter der Unterstützung von OpenStack hinterher, wo solche Mechanismen bereits implementiert sind. 

Kehren wir zur Bereitstellung zurück. Zuerst müssen wir nach der ursprünglichen Einstellung des Panels den ersten Tenant in unserem System erstellen.

Alle Felder sind hier nachvollziehbar, ich werde nur das Feld Cloud erläutern. Wir haben bereits eine 'Standard'-Cloud, die wir bei der ursprünglichen Konfiguration erstellt haben. Wenn wir jedoch jeden Tenant in seinem eigenen Datastore und in seinen eigenen Ressourcenpool platzieren möchten, können wir dies durch die Erstellung separater Clouds für jeden unserer Kunden realisieren.

Im Formular zur Hinzufügung einer neuen Cloud geben wir dieselben Parameter an wie bei der ursprünglichen Konfiguration (wir können sogar denselben Host verwenden), geben den für den jeweiligen Kunden benötigten Datastore an, und jetzt können wir in den zusätzlichen Parametern bereits individuell den erforderlichen Ressourcenpool angeben {„resource_pool“: „YOUR_POOL_NAME“} 

Wie Sie vielleicht bemerkt haben, gibt es im Formular zur Erstellung eines Tenants nichts über Ressourcenzuweisungen oder Quoten – das ist alles nicht im System vorhanden. Es ist nicht möglich, einen Tenant in der Anzahl der gleichzeitigen Replikate, der Anzahl der Maschinen für die Replikation oder durch andere Parameter zu beschränken. So, wir haben den ersten Tenant erstellt. Jetzt gibt es eine nicht ganz logische, aber notwendige Sache – die Installation des Cloud-Agenten. Sie ist unlogisch, da der Agent auf der Seite des jeweiligen Kunden heruntergeladen wird.

Dabei bindet er sich nicht an den erstellten Tenant, und über ihn werden alle unsere Kunden arbeiten (oder über mehrere, wenn wir sie bereitstellen). Ein Agent unterstützt 10 gleichzeitige Sitzungen. Eine Sitzung wird als ein Rechner betrachtet. Dabei ist es unerheblich, wie viele Festplatten er hat. Bis heute gibt es in Acura unter VMware keinen Mechanismus zur Skalierung der Agenten. Es gibt noch einen weiteren unangenehmen Punkt – wir haben nicht die Möglichkeit, über das Acura-Dashboard die "Auslastung" dieses Agents einzusehen, um zu entscheiden, ob wir weitere bereitstellen oder ob die aktuelle Installation ausreichend ist. Das Ergebnis sieht wie folgt aus:

Der nächste Schritt für den Zugang zum Portal unseres Kunden besteht darin, ein Benutzerkonto zu erstellen (und zuvor auch eine Rolle, die diesem Benutzer zugewiesen wird).

Jetzt kann unser Kunde das Portal selbstständig nutzen. Alles, was er tun muss, ist, die Agenten vom Portal herunterzuladen und auf seiner Seite zu installieren. Es gibt drei Arten von Agenten: Linux, Windows und VMware.

Die ersten beiden werden auf physischen Maschinen oder auf virtuellen Maschinen auf einem beliebigen Hypervisor, der nicht VMware ist, installiert. Hier ist keine zusätzliche Konfiguration erforderlich; der Agent wird heruntergeladen und weiß bereits, wo er sich melden muss, und innerhalb einer Minute wird die Maschine im Acura-Dashboard sichtbar sein. Die Situation mit dem VMware-Agenten ist etwas komplizierter. Das Problem ist, dass der Agent für VMware ebenfalls bereits vorbereitet und mit der notwendigen Konfiguration vom Portal heruntergeladen wird. Aber der VMware-Agent muss zusätzlich zum Wissen über unser Acura-Portal auch Informationen über das Virtualisierungssystem haben, auf dem er bereitgestellt wird.

Eigentlich werden diese Daten von der Software beim ersten Herunterladen des VMware-Agenten abgefragt. Das Problem ist, dass in unserem Zeitalter der allgemeinen Sicherheitsliebe nicht alle bereit sein werden, ihr Administratorpasswort auf einem fremden Portal anzugeben, was durchaus verständlich ist. Von innen, nach der Bereitstellung, lässt sich der Agent nicht mehr konfigurieren (man kann nur seine Netzwerkeinstellungen ändern). Hier sehe ich Schwierigkeiten mit besonders vorsichtigen Kunden. 

Nachdem wir die Agenten installiert haben, können wir also zum Acura-Dashboard zurückkehren und alle unsere Maschinen sehen.

Da ich bereits seit mehreren Tagen mit dem System arbeite, habe ich Maschinen in verschiedenen Zuständen. Alle sind in der Gruppe Default, aber es besteht die Möglichkeit, separate Gruppen zu erstellen und die Maschinen dorthin zu verschieben, wie Sie es benötigen. Dies hat keinen Einfluss auf etwas – es handelt sich nur um eine logische Datenpräsentation und Gruppierung für eine bequemere Arbeit. Das Erste und Wichtigste, was wir danach tun müssen, ist, den Migrationsprozess zu starten. Wir können dies sowohl manuell und zwangsläufig als auch durch die Einrichtung eines Zeitplans tun, auch massenhaft für alle Maschinen gleichzeitig.

Ich erinnere daran, dass Hystax sich als Produkt für Migration positioniert hat. Daher ist es nicht überraschend, dass wir für den Start unserer replizierten Maschinen einen DR-Plan erstellen müssen. Der Plan kann für Maschinen erstellt werden, die sich bereits im Zustand Synced befinden. Man kann ihn sowohl für eine bestimmte VM als auch für alle Maschinen auf einmal generieren.

Der Satz an Parametern beim Generieren des DR-Plans wird je nach Infrastruktur, in die Sie migrieren möchten, variieren. Für die VMware-Umgebung ist eine minimale Anzahl von Parametern verfügbar. Zudem wird Re-IP für Maschinen nicht unterstützt. In diesem Plan interessieren uns folgende Punkte: Im Beschreibung der VM ist der Parameter „subnet“: „VMNetwork“, wo wir die VM mit einem bestimmten Netzwerk im Cluster verknüpfen. Rank ist relevant, wenn mehrere VMs migriert werden, da er die Reihenfolge ihres Starts bestimmt. Flavor beschreibt die Konfiguration der VM, in diesem Fall – 1CPU, 2GB RAM. Im Abschnitt subnets definieren wir, dass „subnet“: „VMNetwork“ mit dem Netzwerk „VM Network“ von VMware assoziiert ist. 

Beim Erstellen eines DR-Plans gibt es keine Möglichkeit, die Festplatten auf verschiedene Datastores zu verteilen. Sie befinden sich im selben Datastore, der für diese Kunden-Cloud definiert wurde, und wenn Ihre Festplatten verschiedener Klassen sind, kann dies beim Start der Maschine einige Schwierigkeiten verursachen. Und nach dem Start und der „Trennung“ der VM von Hystax erfordert es eine separate Migration der Festplatten auf die erforderlichen Datastores. Danach müssen wir nur noch unseren DR-Plan ausführen und warten, bis unsere Maschinen hochgefahren sind. Der Prozess der P2V/V2V-Konvertierung benötigt ebenfalls Zeit. Bei meiner größten Testmaschine mit 100 GB und drei Festplatten hat es maximal 10 Minuten gedauert.

Danach sollte die gestartete VM, die darauf befindlichen Dienste, die Konsistenz der Daten sowie weitere Prüfungen überprüft werden. 

Danach stehen uns zwei Wege offen: 

1. Löschen – den gestarteten DR-Plan entfernen. Diese Aktion wird einfach die gestartete VM herunterfahren. Die Daten der Replikate gehen dadurch nicht verloren. 
2. Trennen – die replizierte Maschine von Acura abtrennen, d.h. den Migrationsprozess tatsächlich beenden. 

Vorteile der Lösung: 

• einfache Installation und Einrichtung sowohl auf der Kunden- als auch auf der Anbieterseite; 
• einfache Migrationseinrichtung, Erstellung eines DR-Plans und Start von Replikaten;
• der Support und die Entwickler reagieren schnell auf entdeckte Probleme und beheben diese durch Updates der Plattform oder der Agenten. 

Nachteile 

• Unzureichender Support für Vmware.
• Fehlen jeglicher Quotas für Tenant von Seiten der Plattform. 

Ich habe auch eine Feature-Request erstellt, die wir dem Anbieter übermittelt haben:

1. Überwachung der Nutzung und Deployment aus der Verwaltungs-Konsole von Acura für Cloud-Agenten;
2. Vorhandensein von Quotas für Tenant; 
3. Möglichkeit, die Anzahl gleichzeitiger Replikationen und die Geschwindigkeit für jeden Tenant zu begrenzen; 
4. Unterstützung von VMware vCloud Director; 
5. Unterstützung von Ressourcenpools (wurde während der Testphase implementiert);
6. Möglichkeit, den VMware-Agenten vom Agenten selbst zu konfigurieren, ohne Anmeldedaten aus der Kundeninfrastruktur im Acura-Dashboard einzugeben;
7.  „Visualisierung“ des VM-Startprozesses beim Start des DR-Plans. 

Das Einzige, was mir große Beschwerden bereitete, war die Dokumentation. Ich mag keine „schwarzen Kästen“ und bevorzuge es, wenn es eine detaillierte Dokumentation darüber gibt, wie das Produkt intern funktioniert. Und während das Produkt für AWS und OpenStack noch mehr oder weniger beschrieben ist, gibt es für VMware extrem wenig Dokumentation. 

Es gibt ein Installationshandbuch, das nur die Bereitstellung des Acura-Dashboards beschreibt, und wo kein Wort darüber steht, dass auch ein Cloud-Agent benötigt wird. Es gibt einen vollständigen Satz von Produktspezifikationen, was gut ist. Es gibt eine Dokumentation, die die Konfiguration „von A bis Z“ am Beispiel von AWS und OpenStack beschreibt (obwohl sie mich eher an einen Blogbeitrag erinnert), und es gibt eine sehr kleine Wissensdatenbank. 

Insgesamt ist dies nicht ganz das Dokumentationsformat, an das ich gewöhnt bin, sagen wir mal, bei größeren Anbietern, weshalb ich mich nicht ganz wohl fühlte. Dabei habe ich keine Antworten zu einigen Nuancen der internen Funktionsweise des Systems in dieser Dokumentation gefunden – viele Fragen musste ich beim technischen Support klären, und das hat den Prozess der Bereitstellung des Standes und der Durchführung von Tests erheblich verzögert. 

Zusammenfassend kann ich sagen, dass mir das Produkt und der Ansatz des Unternehmens zur Umsetzung der Aufgabe insgesamt gut gefallen haben. Ja, es gibt Verbesserungsbedarf, es gibt wirklich kritische Funktionseinschränkungen (in Verbindung mit VMware). Es ist offensichtlich, dass das Unternehmen in erster Linie auf öffentliche Clouds, insbesondere AWS, ausgerichtet ist, und für manche wird das ausreichend sein. Die Verfügbarkeit eines so einfachen und benutzerfreundlichen Produkts heute, wo viele Unternehmen eine Multi-Cloud-Strategie wählen, ist äußerst wichtig. Angesichts des deutlich niedrigeren Preises im Vergleich zu Wettbewerbern macht das Produkt äußerst attraktiv.

Wir suchen einen Lead-Systemingenieur für Monitoring-Systeme. Vielleicht sind Sie genau der/die Richtige?

Quelle: habr.com