Einer der jungen Player auf dem Markt für Disaster Recovery-Lösungen ist Hystax, ein russisches Startup im Jahr 2016. Da das Thema Disaster Recovery sehr beliebt ist und der Markt äußerst umkämpft ist, hat sich das Startup entschieden, den Schwerpunkt auf die Migration zwischen verschiedenen Cloud-Infrastrukturen zu legen. Ein Produkt, mit dem Sie eine einfache und schnelle Migration in die Cloud organisieren können, wäre für Onlantas Kunden – Benutzer – sehr nützlich . So lernte ich Hystax kennen und begann, seine Funktionen zu testen. Und was dabei herausgekommen ist, erzähle ich in diesem Artikel.
Das Hauptmerkmal von Hystax ist seine umfassende Funktionalität zur Unterstützung verschiedener Virtualisierungsplattformen, Gastbetriebssysteme und Cloud-Dienste, die es ermöglicht, Ihre Arbeitslasten von überall und überall zu verschieben.
Dadurch können Sie nicht nur DR-Lösungen erstellen, um die Fehlertoleranz von Diensten zu verbessern, sondern auch Ressourcen schnell und flexibel zwischen verschiedenen Standorten und Hyperscalern migrieren, um Kosteneinsparungen zu steigern und die aktuell beste Lösung für einen bestimmten Dienst auszuwählen. Neben den im Titelbild aufgeführten Plattformen kooperiert das Unternehmen auch aktiv mit russischen Cloud-Anbietern: Yandex.Cloud, CROC Cloud Services, Mail.ru und vielen anderen. Erwähnenswert ist auch, dass das Unternehmen im Jahr 2020 ein Forschungs- und Entwicklungszentrum in Skolkovo eröffnet hat.
Die Wahl einer Lösung durch eine große Anzahl von Marktteilnehmern weist auf eine gute Preispolitik und eine hohe Anwendbarkeit des Produkts hin, die wir in der Praxis testen wollten.
Unsere Testaufgabe besteht also darin, von meiner VMware-Testsite und meinen physischen Maschinen auf die Site des Anbieters zu migrieren, auf der auch VMware ausgeführt wird. Ja, es gibt viele Lösungen, die eine solche Migration umsetzen können, aber wir halten Hystax für ein universelles Tool und das Testen der Migration in allen möglichen Kombinationen ist einfach eine unrealistische Aufgabe. Ja, und die Oncloud.ru-Cloud basiert speziell auf VMware, daher interessiert uns diese Plattform als Ziel in größerem Maße. Als nächstes beschreibe ich das Grundprinzip der Funktionsweise, das insgesamt plattformunabhängig ist und VMware von jeder Seite durch eine Plattform eines anderen Anbieters ersetzt werden kann.
Der erste Schritt ist die Bereitstellung von Hystax Acura, dem Bedienfeld des Systems.
Es erweitert sich aus der Vorlage. Aus irgendeinem Grund war es in unserem Fall nicht ganz richtig und statt der empfohlenen 8 CPU wurden 16 GB mit der Hälfte der Ressourcen bereitgestellt. Daher müssen Sie daran denken, sie zu ändern, da sonst die Infrastruktur innerhalb der VM, auf der alles aufbaut, einfach nicht mit Containern startet und das Portal nicht verfügbar ist. IN Die benötigten Ressourcen werden detailliert beschrieben, ebenso wie Ports für alle Systemkomponenten.
Und es gab auch Schwierigkeiten beim Festlegen der IP-Adresse über die Vorlage, also haben wir sie über die Konsole geändert. Danach können Sie zur Admin-Weboberfläche gehen und den Erstkonfigurationsassistenten abschließen.
Endpunkt – IP oder FQDN unseres vCenters.
Login und Passwort – hier ist alles klar.
Der Ziel-ESXi-Hostname ist einer der Hosts in unserem Cluster, auf den repliziert wird.
Der Zieldatenspeicher ist einer der Datenspeicher in unserem Cluster, auf den repliziert wird.
Öffentliche IP des Hystax Acura Control Panels – die Adresse, unter der das Control Panel verfügbar sein wird.
Eine kleine Klarstellung zum Host und Datenspeicher ist erforderlich. Tatsache ist, dass die Hystax-Replikation auf Host- und Datenspeicherebene funktioniert. Als nächstes erkläre ich Ihnen, wie Sie den Host und den Datenspeicher für den Mandanten ändern können, aber das Problem ist ein anderes. Hystax unterstützt kein Ressourcen-Pooling, d.h. Die Replik wird immer im Stammverzeichnis des Clusters angezeigt (zum Zeitpunkt des Schreibens dieses Materials haben die Jungs von Hystax eine aktualisierte Version veröffentlicht, in der sie meinen Funktionswunsch bezüglich der Unterstützung von Ressourcenpools schnell umgesetzt haben). Auch vCloud Director wird nicht unterstützt, d.h. Wenn, wie in meinem Fall, der Mieter nicht über Administratorrechte für den gesamten Cluster, sondern nur für einen bestimmten Ressourcenpool verfügt und wir Hystax Zugriff gewährt haben, kann er diese VMs unabhängig replizieren und ausführen, aber er wird sie nicht in der VMware-Infrastruktur sehen können, auf die er Zugriff hat, und dementsprechend virtuelle Maschinen weiter verwalten können. Der Clusteradministrator muss die VM in den richtigen Ressourcenpool verschieben oder in vCloud Director importieren.
Warum konzentriere ich mich so sehr auf diese Momente? Denn soweit ich das Konzept des Produkts verstehe, sollte der Kunde in der Lage sein, jede Migration oder DR mithilfe des Acura-Panels selbstständig umzusetzen. Bisher liegt die VMware-Unterstützung jedoch etwas hinter der Unterstützung für denselben OpenStack zurück, wo solche Mechanismen bereits implementiert wurden.
Aber zurück zum Einsatz. Nach der Ersteinrichtung des Panels müssen wir zunächst den ersten Mandanten in unserem System anlegen.
Alle Felder hier sind klar, ich werde Ihnen nur etwas über das Cloud-Feld erzählen. Wir haben bereits eine „Standard“-Cloud, die wir bei der Erstkonfiguration erstellt haben. Wenn wir jedoch in der Lage sein möchten, jeden Mandanten in seinem eigenen Datenspeicher und in seinem eigenen Ressourcenpool unterzubringen, können wir dies umsetzen, indem wir für jeden unserer Kunden separate Clouds erstellen.
Beim Hinzufügen einer neuen Cloud geben wir die gleichen Parameter wie bei der Erstkonfiguration an (wir können sogar den gleichen Host verwenden), geben den für einen bestimmten Kunden erforderlichen Datenspeicher an und können nun in den zusätzlichen Parametern bereits individuell festlegen erforderliche Poolressource {"resource_pool" :"YOUR_POOL_NAME"}
Wie Sie vielleicht bemerkt haben, gibt es bei der Erstellung eines Mandanten nichts über die Zuteilung von Ressourcen oder irgendeine Art von Quoten – im System gibt es nichts davon. Sie können den Mandanten nicht hinsichtlich der Anzahl gleichzeitiger Replikate, der Anzahl der Maschinen für die Replikation oder durch andere Parameter begrenzen. Wir haben also den ersten Mieter erstellt. Nun gibt es eine nicht ganz logische, aber zwingende Sache – die Installation eines Cloud-Agenten. Dies ist unlogisch, da der Agent auf der Seite eines bestimmten Kunden heruntergeladen wird.
Gleichzeitig ist es nicht an den erstellten Mandanten gebunden und alle unsere Kunden werden damit arbeiten (oder mehrere, wenn wir sie bereitstellen). Ein Agent unterstützt 10 gleichzeitige Sitzungen. Eine Sitzung zählt als ein Auto. Es spielt keine Rolle, wie viele Festplatten es hat. Bisher gibt es in Acura selbst keinen Mechanismus zur Skalierung von Agents für VMware. Es gibt noch einen weiteren unangenehmen Moment: Wir können die „Auslastung“ dieses Agenten im Acura-Panel nicht betrachten, um zu entscheiden, ob wir mehr bereitstellen müssen oder die aktuelle Installation ausreicht. Im Ergebnis sieht der Ständer so aus:
Der nächste Schritt zum Zugriff auf das Portal unseres Kunden ist die Erstellung eines Kontos (und zunächst auch einer Rolle, die auf diesen Benutzer angewendet wird).
Nun kann unser Kunde das Portal selbstständig nutzen. Er muss lediglich Agenten vom Portal herunterladen und auf seiner Seite installieren. Es gibt drei Arten von Agenten: Linux, Windows und VMware.
Die ersten beiden werden auf physikalischen oder virtuellen Maschinen auf jedem Nicht-VMware-Hypervisor installiert. Hier ist keine zusätzliche Konfiguration erforderlich, der Agent lädt herunter und weiß bereits, wo er klopfen muss, und buchstäblich in einer Minute wird das Auto im Acura-Panel sichtbar sein. Beim VMware-Agenten ist die Situation etwas komplizierter. Das Problem besteht darin, dass auch der Agent für VMware vom Portal heruntergeladen wird, der bereits vorbereitet ist und über die erforderliche Konfiguration verfügt. Aber der VMware-Agent muss nicht nur über unser Acura-Portal Bescheid wissen, sondern auch über das Virtualisierungssystem, auf dem er bereitgestellt wird.
Tatsächlich werden wir vom System aufgefordert, diese Daten anzugeben, wenn Sie den VMware-Agenten zum ersten Mal herunterladen. Das Problem besteht darin, dass in unserem Zeitalter der universellen Liebe zur Sicherheit nicht jeder sein Admin-Passwort auf dem Portal eines anderen angeben möchte, was durchaus verständlich ist. Von innen heraus kann der Agent nach der Bereitstellung in keiner Weise konfiguriert werden (Sie können nur seine Netzwerkeinstellungen ändern). Hier sehe ich Schwierigkeiten bei besonders vorsichtigen Kunden.
Nach der Installation der Agenten können wir also zum Acura-Panel zurückkehren und alle unsere Autos sehen.
Da ich seit mehr als einem Tag mit dem System arbeite, habe ich Maschinen in verschiedenen Zuständen. Alle befinden sich in der Standardgruppe, es ist jedoch möglich, bei Bedarf separate Gruppen zu erstellen und Maschinen dorthin zu übertragen. Dies hat keinerlei Auswirkungen – lediglich die logische Darstellung der Daten und deren Gruppierung für eine komfortablere Arbeit. Das erste und wichtigste, was wir danach tun müssen, ist, den Migrationsprozess zu starten. Wir können dies sowohl manuell erzwingen als auch einen Zeitplan erstellen, auch in großen Mengen für alle Maschinen gleichzeitig.
Ich möchte Sie daran erinnern, dass Hystax als Produkt für die Migration positioniert wurde. Daher ist es nicht verwunderlich, dass wir zum Betrieb unserer replizierten Maschinen einen DR-Plan erstellen müssen. Sie können einen Plan für Maschinen erstellen, die sich bereits im Status „Synchronisiert“ befinden. Sie können sowohl für eine bestimmte VM als auch für alle Maschinen gleichzeitig generieren.
Der Parametersatz beim Generieren eines DR-Plans hängt von der Infrastruktur ab, auf die Sie migrieren möchten. Für eine VMware-Umgebung ist ein minimaler Satz an Optionen verfügbar. Re-IP für Maschinen wird ebenfalls nicht unterstützt. In diesem Zusammenhang interessieren uns folgende Punkte: in der Beschreibung der VM der Parameter „Subnetz“: „VMNetwork“, wo wir die VM an ein bestimmtes Netzwerk im Cluster binden. Rang – relevant bei der Migration mehrerer VMs, bestimmt die Reihenfolge, in der sie gestartet werden. Flavor beschreibt die VM-Konfiguration, in diesem Fall 1 CPU, 2 GB RAM. Im Abschnitt „Subnetze“ definieren wir, dass „Subnetz“: „VMNetwork“ mit dem „VM-Netzwerk“ von VMware verknüpft ist.
Beim Erstellen eines DR-Plans gibt es keine Möglichkeit, Festplatten auf verschiedene Datenspeicher aufzuteilen. Sie befinden sich im selben Datenspeicher, der für diese Client-Cloud definiert wurde. Wenn Sie Festplatten unterschiedlicher Klassen haben, kann dies zu einigen Schwierigkeiten beim Starten der Maschine führen. Nach dem Starten und „Trennen“ der VM von Hystax wird dies auch der Fall sein erfordern separate Migrationsdatenträger zu den erforderlichen Datenspeichern. Dann müssen wir nur noch unseren DR-Plan ausführen und darauf warten, dass unsere Autos steigen. Auch der P2V/V2V-Konvertierungsprozess braucht Zeit. Auf meiner größten 100-GB-Testmaschine mit drei Festplatten dauerte dies maximal 10 Minuten.
Danach sollten Sie die laufende VM, die darauf befindlichen Dienste, die Datenkonsistenz und andere Prüfungen überprüfen.
Dann haben wir zwei Möglichkeiten:
- Löschen – Löschen Sie einen laufenden DR-Plan. Durch diese Aktion wird einfach die laufende VM heruntergefahren. Diese Repliken werden nirgendwo hingehen.
- Abtrennen – das nachgebildete Auto vom Acura abreißen, d. h. den Migrationsprozess tatsächlich abschließen.
Vorteile der Lösung:
- einfache Installation und Konfiguration sowohl auf der Client- als auch auf der Anbieterseite;
- Einfaches Einrichten der Migration, Erstellen eines DR-Plans und Starten von Replikaten;
- Support und Entwickler reagieren recht schnell auf die gefundenen Probleme und beheben diese mit Plattform- oder Agent-Updates.
Cons
- Unzureichende VMware-Unterstützung.
- Das Fehlen einer Quote für Mieter auf der Plattform.
Ich habe auch eine Funktionsanfrage gestellt, die wir dem Anbieter übergeben haben:
- Nutzungsüberwachung und Bereitstellung über die Acura Management Console für Cloud Agents;
- Verfügbarkeit von Kontingenten für Mieter;
- die Möglichkeit, die Anzahl gleichzeitiger Replikationen und die Geschwindigkeit für jeden Mandanten zu begrenzen;
- Unterstützung für VMware vCloud Director;
- Unterstützung für Ressourcenpools (wurde während des Tests implementiert);
- die Möglichkeit, den VMware-Agenten vom Agenten selbst aus zu konfigurieren, ohne Anmeldeinformationen von der Client-Infrastruktur im Acura-Panel einzugeben;
- „Visualisierung“ des Prozesses des Startens einer VM beim Starten eines DR-Plans.
Das Einzige, worüber ich mich sehr beschwert habe, war die Dokumentation. Ich mag keine „Black Boxes“ und bevorzuge es, wenn eine detaillierte Dokumentation darüber vorhanden ist, wie das Produkt darin funktioniert. Und wenn das Produkt für AWS und OpenStack noch mehr oder weniger beschrieben wird, gibt es für VMware nur sehr wenig Dokumentation.
Es gibt eine Installationsanleitung, die nur die Bereitstellung des Acura-Panels beschreibt und in der kein Wort über die Notwendigkeit eines Cloud-Agenten verloren geht. Es liegen vollständige Spezifikationen für das Produkt vor, was gut ist. Es gibt eine Dokumentation, die das Setup „von und nach“ am Beispiel von AWS und OpenStack beschreibt (obwohl es mich eher an einen Blogbeitrag erinnert), und es gibt eine sehr kleine Wissensdatenbank.
Im Allgemeinen ist dies nicht ganz das Dokumentationsformat, das ich beispielsweise von größeren Anbietern gewohnt bin, sodass ich mich nicht ganz wohl fühlte. Gleichzeitig habe ich in dieser Dokumentation keine Antworten auf einige Nuancen des Systembetriebs „im Inneren“ gefunden – ich musste viele Fragen mit dem technischen Support klären, was den Prozess der Bereitstellung des Standes und des Tests eher verzögerte .
Zusammenfassend kann ich sagen, dass mir das Produkt und die Herangehensweise des Unternehmens an die Umsetzung der Aufgabe im Allgemeinen gefallen haben. Ja, es gibt Mängel, es gibt einen wirklich kritischen Mangel an Funktionalität (in Verbindung mit VMware). Es ist zu erkennen, dass sich das Unternehmen zunächst immer noch auf öffentliche Clouds, insbesondere AWS, konzentriert, und für einige wird dies ausreichen. Ein so einfaches und praktisches Produkt zu haben, ist heute, wo sich viele Unternehmen für eine Multi-Cloud-Strategie entscheiden, äußerst wichtig. Angesichts des im Vergleich zur Konkurrenz deutlich günstigeren Preises macht dies das Produkt äußerst attraktiv.
Wir suchen ein Team . Vielleicht bist du es?
Source: habr.com