Einer der jungen Akteure auf dem Markt für Disaster-Recovery-Lösungen ist das Unternehmen Hystax – ein russisches Startup aus dem Jahr 2016. Da das Thema der Notfallwiederherstellung sehr populär ist und der Wettbewerb auf dem Markt extrem hoch ist, hat sich das Startup entschieden, 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" — Nutzer von . So kam ich zu Hystax und begann, seine Möglichkeiten zu testen. Was dabei herausgekommen ist, werde ich in diesem Artikel erläutern.
Das Hauptmerkmal von Hystax ist die breite Funktionalität zur Unterstützung verschiedener Virtualisierungsplattformen, Gastbetriebssysteme und Cloud-Services, was Ihnen ermöglicht, Ihre Arbeitslasten von überall hin zu migrieren und zu transferieren.
Dies ermöglicht nicht nur die Erstellung von DR-Lösungen zur Erhöhung der Ausfallsicherheit von Diensten, sondern auch eine schnelle und flexible Migration von Ressourcen zwischen verschiedenen Plattformen und Hyperscalern, um Kosten zu sparen und die beste Lösung für einen bestimmten Dienst zum aktuellen Zeitpunkt zu finden. Neben den auf dem Titelbild genannten Plattformen arbeitet das Unternehmen auch aktiv mit russischen Cloud-Anbietern zusammen: Yandex.Cloud, KROK „Cloud Services“, Mail.ru und vielen anderen. Es ist auch erwähnenswert, dass das Unternehmen im Jahr 2020 ein F&E-Zentrum in Skolkowo eröffnet hat.
Die Wahl einer Lösung durch viele Akteure auf dem Markt spricht für eine gute Preispolitik und hohe Anwendbarkeit des Produkts, was wir nun in der Praxis erproben möchten.
Unsere Testaufgabe besteht darin, von meiner VMware-Testumgebung und physischen Maschinen auf die Plattform des Anbieters zu migrieren, die ebenfalls VMware verwendet. Es gibt viele Lösungen, die eine solche Migration ermöglichen, aber wir betrachten Hystax als die universelle Lösung. Eine umfassende Testmigration in allen möglichen Kombinationen ist einfach unrealistisch. Zudem ist die Cloud von Oncloud.ru auf VMware aufgebaut, weshalb uns diese Plattform als Ziel interessiert. Im Folgenden werde ich die grundlegenden Funktionsweise beschreiben, die im Allgemeinen nicht von der Plattform abhängt; VMware kann ohne Weiteres durch die Plattform eines anderen Anbieters ersetzt werden.
Im ersten Schritt muss Hystax Acura bereitgestellt werden, das ist das Verwaltungsdashboard des Systems.
Es wird aus einer Vorlage bereitgestellt. Aus irgendeinem Grund war diese in unserem Fall nicht ganz korrekt und anstelle der empfohlenen 8 CPU und 16 GB wurde es mit halb so vielen Ressourcen bereitgestellt. Daher ist es wichtig, diese zu ändern, da die Containerinfrastruktur innerhalb der VM, auf der alles aufgebaut ist, sonst einfach nicht gestartet werden kann und das Portal nicht erreichbar ist. Die erforderlichen Ressourcen sowie die Ports für alle Systemkomponenten werden ausführlich beschrieben.
Auch bei der Zuweisung der IP-Adresse über das Template gab es Schwierigkeiten, sodass wir diese über die Konsole änderten. Danach kann man in die Weboberfläche des Administrationsbereichs wechseln und den ursprünglichen Konfigurationsassistenten ausfüllen.
Endpoint – die IP oder FQDN unseres vCenter.
Login und Passwort – hier ist alles klar.
Target ESXi-Hostname – einer der Hosts unseres Clusters, auf den die Replikation stattfinden wird.
Target Datastore – einer der Datastores unseres Clusters, auf den die Replikation stattfinden wird.
Hystax Acura Control Panel Public IP – die Adresse, unter der das Kontrollpaneel verfügbar sein wird.
Es ist eine kleine Klarstellung bezüglich des Hosts und des Datastores erforderlich. Das liegt daran, dass die Hystax-Replikation auf der Ebene des Hosts und des Datastores funktioniert. Im Folgenden werde ich erläutern, wie man für einen Tenant den Host und den Datastore ändern kann, aber das Problem liegt woanders. Hystax unterstützt nicht die Arbeit mit Ressourcengruppen, d.h. die Replikation erfolgt immer im Wurzelverzeichnis des Clusters (zum Zeitpunkt der Erstellung dieses Materials haben die Kollegen von Hystax eine aktualisierte Version veröffentlicht, in der sie schnell meine Funktionserweiterung zur Unterstützung von Ressourcengruppen integriert haben). Auch vCloud Director wird nicht unterstützt, d.h. wenn, wie in meinem Fall, der Tenant keine Administratorrechte für das gesamte Cluster hat, sondern nur für eine bestimmte Ressourcengruppe, und wir Zugang zu Hystax gewähren, könnte er selbstständig diese VMs replizieren und starten, aber er könnte sie in der VMware-Infrastruktur, auf die er Zugriff hat, nicht sehen und folglich auch nicht weiter die virtuellen Maschinen verwalten. Es ist erforderlich, dass der Clusteradministrator die VM in die gewünschte Ressourcengruppe 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 die Möglichkeit haben sollte, jede Migration oder DR selbstständig über das Acura-Panel durchzuführen. Doch bisher bleibt die Unterstützung von VMware leicht hinter dem Niveau der Unterstützung von OpenStack zurück, wo ähnliche Mechanismen bereits implementiert sind.
Aber zurück zur Bereitstellung. Zuerst müssen wir nach der ersten Konfiguration des Panels den ersten Mandanten in unserem System erstellen.
Die Felder hier sind klar, 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 jedem Mandanten die Möglichkeit geben wollen, eigenen Speicherplatz und einen eigenen Ressourcenpool zuzuweisen, können wir das durch die Erstellung separater Clouds für jeden unserer Kunden umsetzen.
Im Formular zur Hinzufügung einer neuen Cloud geben wir die gleichen Parameter an wie bei der ursprünglichen Konfiguration (wir können sogar denselben Host verwenden), wir 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, fehlt im Formular zur Erstellung eines Tenants jegliche Information zur Ressourcenzuteilung oder Quoten – das System enthält nichts davon. Es ist nicht möglich, einen Tenant hinsichtlich der Anzahl gleichzeitiger Replikate, der Anzahl der Maschinen für die Replikation oder anderen Parametern zu beschränken. Nun haben wir den ersten Tenant erstellt. Jetzt gibt es eine nicht ganz logische, aber notwendige Anforderung – die Installation des Cloud-Agents. Sie ist unlogisch, da der Agent auf der Seite des jeweiligen Kunden heruntergeladen wird.
Dabei bindet er sich nicht an den erstellten Tenant, und darüber hinaus werden alle unsere Kunden (oder mehrere, falls wir sie deployen) arbeiten. Ein Agent unterstützt 10 gleichzeitige Sitzungen. Eine Sitzung wird als eine Maschine betrachtet. Dabei ist es unerheblich, wie viele Festplatten sie hat. Bislang gibt es in Acura unter VMware keinen Mechanismus zur Skalierung der Agenten. Ein weiterer unangenehmer Punkt – wir können aus dem Acura-Dashboard nicht auf die "Auslastung" dieses Agenten zugreifen, um festzustellen, ob wir noch einen weiteren bereitstellen müssen oder ob die aktuelle Installation ausreicht. Letztendlich sieht der Stand folgendermaßen aus:
Der nächste Schritt, um auf das Portal unseres Kunden zuzugreifen, besteht darin, ein Benutzerkonto zu erstellen (und vorher 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 sie auf seiner Seite zu installieren. Es gibt drei Arten von Agenten: Linux, Windows und VMware.
Die ersten beiden werden auf physische oder virtuelle Maschinen unter jedem Hypervisor, der nicht VMware ist, platziert. Hier ist keine zusätzliche Konfiguration erforderlich, der Agent wird heruntergeladen und weiß bereits, wo er hin muss, und innerhalb von nur einer Minute wird die Maschine im Acura-Dashboard sichtbar sein. Bei VMware ist die Situation etwas komplexer. Das Problem ist, dass der Agent für VMware ebenfalls vorab vom Portal heruntergeladen wird und die erforderliche Konfiguration bereits enthält. Aber der VMware-Agent muss, neben dem Wissen über unser Acura-Portal, auch über das Virtualisierungssystem Bescheid wissen, auf dem er bereitgestellt wird.
Diese Daten wird das System uns beim ersten Herunterladen des VMware-Agents anfordern. Das Problem ist, dass in unserem Zeitalter, in dem Sicherheit großgeschrieben wird, nicht jeder bereit ist, sein Admin-Passwort auf einem fremden Portal anzugeben, was voll und ganz nachvollziehbar ist. Von innen, nach der Bereitstellung, kann der Agent nicht mehr konfiguriert werden (man kann nur seine Netzwerkeinstellungen ändern). Hier erwarte ich Schwierigkeiten mit besonders vorsichtigen Kunden.
Nachdem wir die Agenten installiert haben, können wir zum Acura-Dashboard zurückkehren und all unsere Maschinen sehen.
Da ich bereits einige Zeit mit dem System arbeite, habe ich Maschinen in verschiedenen Zuständen. Alle befinden sich in der Gruppe Default, jedoch besteht die Möglichkeit, separate Gruppen zu erstellen und Maschinen nach Bedarf zu verschieben. Das hat auf die Funktionalität keinen Einfluss – es handelt sich lediglich um eine logische Datenpräsentation und Gruppierung, um die Arbeit zu erleichtern. Das Erste und Wichtigste, was wir danach tun müssen, ist, den Migrationsprozess zu starten. Dies können wir entweder manuell und gezielt oder per Zeitplan für alle Maschinen gleichzeitig erledigen.
Ich erinnere daran, dass Hystax als Produkt für Migration positioniert wurde. Daher ist es nicht überraschend, dass wir einen DR-Plan erstellen müssen, um unsere replizierten Maschinen zu starten. Der Plan kann für Maschinen erstellt werden, die sich bereits im Zustand 'Synced' befinden. Dabei kann ein Plan sowohl für eine bestimmte VM als auch für alle Maschinen auf einmal generiert werden.
Die Parameter beim Generieren eines DR-Plans variieren je nach der Infrastruktur, in die Sie migrieren möchten. Für die VMware-Umgebung steht eine minimalistische Parametergruppe zur Verfügung. Re-IP für Maschinen wird ebenfalls nicht unterstützt. In diesem Plan interessieren uns folgende Punkte: Im VM-Beschreibung ist der Parameter "subnet": "VMNetwork", wo wir die VM an ein bestimmtes Netzwerk im Cluster binden. Rank ist wichtig bei der Migration mehrerer VMs und legt die Reihenfolge ihres Starts fest. 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 ist es nicht möglich, die Festplatten auf verschiedene Datastores zu verteilen. Sie werden im selben Datastore gespeichert, der für diese Kunden-Cloud bestimmt wurde. Wenn Sie Festplatten unterschiedlicher Klassen haben, kann dies beim Start der Maschine zu Problemen führen. Außerdem erfordert es nach dem Start der VM und dem 'Abkoppeln' von Hystax eine separate Migration der Festplatten auf die entsprechenden Datastores. Danach bleibt uns nur noch, unseren DR-Plan zu starten und zu warten, bis unsere Maschinen hochgefahren sind. Der P2V/V2V-Konvertierungsprozess benötigt ebenfalls Zeit. Auf meiner größten Testmaschine mit 100 GB und drei Festplatten dauerte es maximal 10 Minuten.
Anschließend sollten Sie die gestartete VM, die darauf laufenden Dienste, die Konsistenz der Daten und weitere Überprüfungen prüfen.
Nun stehen uns zwei Wege offen:
- Löschen – den gestarteten DR-Plan entfernen. Diese Aktion schaltet lediglich die laufende VM aus. Die Daten der Replikate gehen dabei nicht verloren.
- Abkoppeln – die replizierte Maschine von Acura trennen, d. h. den Migrationsprozess faktisch abschließen.
Vorteile der Lösung:
- einfache Installation und Konfiguration sowohl für den Kunden als auch für den Anbieter;
- einfache Konfiguration der Migration, Erstellung des DR-Plans und Start der Replikate;
- Die Unterstützung und die Entwickler reagieren recht schnell auf entdeckte Probleme und beheben diese durch Aktualisierungen der Plattform oder Agenten.
Nachteile
- Unzureichende Unterstützung für Vmware.
- Fehlende Quoten für Tenants seitens der Plattform.
Ich habe auch einen Feature Request erstellt, den wir dem Anbieter übergeben haben:
- Überwachung der Nutzung und Deployment über das Verwaltungsconsole von Acura für Cloud-Agenten;
- Festlegung von Quoten für Tenants;
- Möglichkeit zur Begrenzung der Anzahl gleichzeitiger Replikationen und der Geschwindigkeit für jeden Tenant;
- Unterstützung von VMware vCloud Director;
- Unterstützung von Ressourcen-Pools (wurde während der Tests implementiert);
- Möglichkeit zur Konfiguration des VMware-Agenten durch den Agenten selbst, ohne Eingabe von Anmeldedaten der Kundeninfrastruktur in das Acura-Panel;
- „Visualisierung“ des Prozesses beim Starten von VMs während der Ausführung des DR-Plans.
Das einzige, was mir große Beschwerden bereitet hat, ist die Dokumentation. Ich mag „Black Boxes“ nicht besonders und bevorzuge es, wenn eine detaillierte Dokumentation darüber vorhanden ist, wie das Produkt im Inneren funktioniert. Während das Produkt für AWS und OpenStack noch mehr oder weniger beschrieben wird, gibt es für VMware extrem wenig Dokumentation.
Es gibt ein Installationshandbuch, das nur die Bereitstellung des Acura-Panels beschreibt und nicht erwähnt, dass auch ein Cloud-Agent erforderlich ist. Es gibt ein umfassendes Set an Produktspezifikationen, was positiv ist. Die Dokumentation beschreibt die Einrichtung „von A bis Z“ am Beispiel von AWS und OpenStack (obwohl sie eher wie ein Blogbeitrag wirkt), und es gibt eine sehr kleine Wissensdatenbank.
Insgesamt entspricht dies nicht ganz dem Dokumentationsformat, das ich gewohnt bin, sagen wir mal, von größeren Anbietern, sodass ich mich nicht ganz wohlfühlte. Gleichzeitig konnte ich die Antworten auf einige Feinheiten der internen Systemarbeit in dieser Dokumentation nicht finden – viele Fragen musste ich bei der technischen Unterstützung klären, was den Bereitstellungsprozess und das Testing erheblich verzögerte.
Zusammenfassend kann ich sagen, dass mir das Produkt und der Ansatz des Unternehmens zur Umsetzung der Aufgabe insgesamt gefallen haben. Ja, es gibt Verbesserungspotenzial, und es besteht tatsächlich eine kritische Funktionalitätslücke (in der Verbindung mit VMware). Es ist offensichtlich, dass das Unternehmen in erster Linie auf öffentliche Cloud-Lösungen, insbesondere AWS, ausgerichtet ist, und für einige wird dies ausreichen. In der heutigen Zeit, in der viele Unternehmen eine Multi-Cloud-Strategie wählen, ist das Angebot eines so einfachen und benutzerfreundlichen Produkts von großer Bedeutung. Angesichts des deutlich niedrigeren Preises im Vergleich zu Mitbewerbern macht dies das Produkt äußerst attraktiv.
Wir suchen in unserem Team . Vielleicht sind Sie genau der/die Richtige?
Quelle: habr.com
