{"id":96767,"date":"2020-10-14T14:43:02","date_gmt":"2020-10-14T12:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam"},"modified":"2020-10-14T14:43:02","modified_gmt":"2020-10-14T12:43:02","slug":"hystax-cloud-migration-skachem-po-oblakam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam","title":{"rendered":"Hystax Cloud Migration: Wir springen von Cloud zu Cloud","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u041e\u0434\u043d\u0438\u043c \u0438\u0437 \u043c\u043e\u043b\u043e\u0434\u044b\u0445 \u0438\u0433\u0440\u043e\u043a\u043e\u0432 \u043d\u0430 \u0440\u044b\u043d\u043a\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Disaster Recovery \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Hystax \u2013 \u0440\u043e\u0441\u0441\u0438\u0439\u0441\u043a\u0438\u0439 \u0441\u0442\u0430\u0440\u0442\u0430\u043f 2016 \u0433\u043e\u0434\u0430. \u041f\u043e\u0441\u043a\u043e\u043b\u044c\u043a\u0443 \u0442\u0435\u043c\u0430 \u0430\u0432\u0430\u0440\u0438\u0439\u043d\u043e\u0433\u043e \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f \u043e\u0447\u0435\u043d\u044c \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u0430, \u0438 \u043d\u0430 \u0440\u044b\u043d\u043a\u0435 \u043a\u0440\u0430\u0439\u043d\u0435 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043a\u043e\u043d\u043a\u0443\u0440\u0435\u043d\u0446\u0438\u044f, \u0441\u0442\u0430\u0440\u0442\u0430\u043f \u0440\u0435\u0448\u0438\u043b \u0441\u0444\u043e\u043a\u0443\u0441\u0438\u0440\u043e\u0432\u0430\u0442\u044c\u0441\u044f \u043d\u0430 \u043c\u0438\u0433\u0440\u0430\u0446\u0438\u0438 \u043c\u0435\u0436\u0434\u0443 \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u043c\u0438 \u043e\u0431\u043b\u0430\u0447\u043d\u044b\u043c\u0438 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430\u043c\u0438. \u041f\u0440\u043e\u0434\u0443\u043a\u0442, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0438\u0439 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u0430\u0442\u044c \u043f\u0440\u043e\u0441\u0442\u0443\u044e \u0438 \u0431\u044b\u0441\u0442\u0440\u0443\u044e \u043c\u0438\u0433\u0440\u0430\u0446\u0438\u044e \u0432 \u043e\u0431\u043b\u0430\u043a\u043e, \u0431\u044b\u043b \u0431\u044b \u043e\u0447\u0435\u043d\u044c \u043f\u043e\u043b\u0435\u0437\u0435\u043d \u0438 \u043a\u043b\u0438\u0435\u043d\u0442\u0430\u043c \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u00ab\u041e\u043d\u043b\u0430\u043d\u0442\u0430\u00bb —\u00a0 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f\u043c Oncloud.ru<\/a><\/noindex>. So kam ich zu Hystax und begann, seine M\u00f6glichkeiten zu testen. Was dabei herausgekommen ist, werde ich in diesem Artikel erl\u00e4utern.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDas Hauptmerkmal von Hystax ist die breite Funktionalit\u00e4t zur Unterst\u00fctzung verschiedener Virtualisierungsplattformen, Gastbetriebssysteme und Cloud-Services, was Ihnen erm\u00f6glicht, Ihre Arbeitslasten von \u00fcberall hin zu migrieren und zu transferieren.<\/p>\n

Dies erm\u00f6glicht nicht nur die Erstellung von DR-L\u00f6sungen zur Erh\u00f6hung 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\u00f6sung f\u00fcr 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 \u201eCloud Services\u201c, Mail.ru und vielen anderen. Es ist auch erw\u00e4hnenswert, dass das Unternehmen im Jahr 2020 ein F&E-Zentrum in Skolkowo er\u00f6ffnet hat.\u00a0<\/p>\n

Die Wahl einer L\u00f6sung durch viele Akteure auf dem Markt spricht f\u00fcr eine gute Preispolitik und hohe Anwendbarkeit des Produkts, was wir nun in der Praxis erproben m\u00f6chten.<\/p>\n

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\u00f6sungen, die eine solche Migration erm\u00f6glichen, aber wir betrachten Hystax als die universelle L\u00f6sung. Eine umfassende Testmigration in allen m\u00f6glichen 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\u00e4ngt; VMware kann ohne Weiteres durch die Plattform eines anderen Anbieters ersetzt werden.\u00a0<\/p>\n

Im ersten Schritt muss Hystax Acura bereitgestellt werden, das ist das Verwaltungsdashboard des Systems.<\/p>\n

\"Hystax<\/a><\/noindex>
\nEs 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 \u00e4ndern, da die Containerinfrastruktur innerhalb der VM, auf der alles aufgebaut ist, sonst einfach nicht gestartet werden kann und das Portal nicht erreichbar ist. Bereitstellungsanforderungen<\/a><\/noindex> Die erforderlichen Ressourcen sowie die Ports f\u00fcr alle Systemkomponenten werden ausf\u00fchrlich beschrieben.\u00a0<\/p>\n

Auch bei der Zuweisung der IP-Adresse \u00fcber das Template gab es Schwierigkeiten, sodass wir diese \u00fcber die Konsole \u00e4nderten. Danach kann man in die Weboberfl\u00e4che des Administrationsbereichs wechseln und den urspr\u00fcnglichen Konfigurationsassistenten ausf\u00fcllen.\u00a0<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nEndpoint \u2013 die IP oder FQDN unseres vCenter.\u00a0
\nLogin und Passwort \u2013 hier ist alles klar.\u00a0
\nTarget ESXi-Hostname \u2013 einer der Hosts unseres Clusters, auf den die Replikation stattfinden wird.\u00a0
\nTarget Datastore \u2013 einer der Datastores unseres Clusters, auf den die Replikation stattfinden wird.
\nHystax Acura Control Panel Public IP \u2013 die Adresse, unter der das Kontrollpaneel verf\u00fcgbar sein wird.<\/p>\n

Es ist eine kleine Klarstellung bez\u00fcglich 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\u00e4utern, wie man f\u00fcr einen Tenant den Host und den Datastore \u00e4ndern kann, aber das Problem liegt woanders. Hystax unterst\u00fctzt 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\u00f6ffentlicht, in der sie schnell meine Funktionserweiterung zur Unterst\u00fctzung von Ressourcengruppen integriert haben). Auch vCloud Director wird nicht unterst\u00fctzt, d.h. wenn, wie in meinem Fall, der Tenant keine Administratorrechte f\u00fcr das gesamte Cluster hat, sondern nur f\u00fcr eine bestimmte Ressourcengruppe, und wir Zugang zu Hystax gew\u00e4hren, k\u00f6nnte er selbstst\u00e4ndig diese VMs replizieren und starten, aber er k\u00f6nnte 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\u00fcnschte Ressourcengruppe verschiebt oder in vCloud Director importiert.<\/p>\n

Warum lege ich so viel Wert auf diese Punkte? Weil, soweit ich das Konzept des Produkts verstehe, der Kunde die M\u00f6glichkeit haben sollte, jede Migration oder DR selbstst\u00e4ndig \u00fcber das Acura-Panel durchzuf\u00fchren. Doch bisher bleibt die Unterst\u00fctzung von VMware leicht hinter dem Niveau der Unterst\u00fctzung von OpenStack zur\u00fcck, wo \u00e4hnliche Mechanismen bereits implementiert sind.\u00a0<\/p>\n

Aber zur\u00fcck zur Bereitstellung. Zuerst m\u00fcssen wir nach der ersten Konfiguration des Panels den ersten Mandanten in unserem System erstellen.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDie Felder hier sind klar, ich werde nur das Feld Cloud erl\u00e4utern. Wir haben bereits eine \"Standard\"-Cloud, die wir bei der urspr\u00fcnglichen Konfiguration erstellt haben. Wenn wir jedoch jedem Mandanten die M\u00f6glichkeit geben wollen, eigenen Speicherplatz und einen eigenen Ressourcenpool zuzuweisen, k\u00f6nnen wir das durch die Erstellung separater Clouds f\u00fcr jeden unserer Kunden umsetzen.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIm Formular zur Hinzuf\u00fcgung einer neuen Cloud geben wir die gleichen Parameter an wie bei der urspr\u00fcnglichen Konfiguration (wir k\u00f6nnen sogar denselben Host verwenden), wir geben den f\u00fcr den jeweiligen Kunden ben\u00f6tigten Datastore an, und jetzt k\u00f6nnen wir in den zus\u00e4tzlichen Parametern bereits individuell den erforderlichen Ressourcenpool angeben {\u00abresource_pool\u00bb: \u00abYOUR_POOL_NAME\u00bb}\u00a0<\/p>\n

Wie Sie vielleicht bemerkt haben, fehlt im Formular zur Erstellung eines Tenants jegliche Information zur Ressourcenzuteilung oder Quoten \u2013 das System enth\u00e4lt nichts davon. Es ist nicht m\u00f6glich, einen Tenant hinsichtlich der Anzahl gleichzeitiger Replikate, der Anzahl der Maschinen f\u00fcr die Replikation oder anderen Parametern zu beschr\u00e4nken. Nun haben wir den ersten Tenant erstellt. Jetzt gibt es eine nicht ganz logische, aber notwendige Anforderung \u2013 die Installation des Cloud-Agents. Sie ist unlogisch, da der Agent auf der Seite des jeweiligen Kunden heruntergeladen wird.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDabei bindet er sich nicht an den erstellten Tenant, und dar\u00fcber hinaus werden alle unsere Kunden (oder mehrere, falls wir sie deployen) arbeiten. Ein Agent unterst\u00fctzt 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 \u2013 wir k\u00f6nnen aus dem Acura-Dashboard nicht auf die \"Auslastung\" dieses Agenten zugreifen, um festzustellen, ob wir noch einen weiteren bereitstellen m\u00fcssen oder ob die aktuelle Installation ausreicht. Letztendlich sieht der Stand folgenderma\u00dfen aus:<\/p>\n

\"Hystax<\/a><\/noindex>
\nDer n\u00e4chste Schritt, um auf das Portal unseres Kunden zuzugreifen, besteht darin, ein Benutzerkonto zu erstellen (und vorher auch eine Rolle, die diesem Benutzer zugewiesen wird).<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nJetzt kann unser Kunde das Portal selbstst\u00e4ndig 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.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDie ersten beiden werden auf physische oder virtuelle Maschinen unter jedem Hypervisor, der nicht VMware ist, platziert. Hier ist keine zus\u00e4tzliche Konfiguration erforderlich, der Agent wird heruntergeladen und wei\u00df 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\u00fcr VMware ebenfalls vorab vom Portal heruntergeladen wird und die erforderliche Konfiguration bereits enth\u00e4lt. Aber der VMware-Agent muss, neben dem Wissen \u00fcber unser Acura-Portal, auch \u00fcber das Virtualisierungssystem Bescheid wissen, auf dem er bereitgestellt wird.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDiese Daten wird das System uns beim ersten Herunterladen des VMware-Agents anfordern. Das Problem ist, dass in unserem Zeitalter, in dem Sicherheit gro\u00dfgeschrieben 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 \u00e4ndern). Hier erwarte ich Schwierigkeiten mit besonders vorsichtigen Kunden.\u00a0<\/p>\n

Nachdem wir die Agenten installiert haben, k\u00f6nnen wir zum Acura-Dashboard zur\u00fcckkehren und all unsere Maschinen sehen.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDa ich bereits einige Zeit mit dem System arbeite, habe ich Maschinen in verschiedenen Zust\u00e4nden. Alle befinden sich in der Gruppe Default, jedoch besteht die M\u00f6glichkeit, separate Gruppen zu erstellen und Maschinen nach Bedarf zu verschieben. Das hat auf die Funktionalit\u00e4t keinen Einfluss \u2013 es handelt sich lediglich um eine logische Datenpr\u00e4sentation und Gruppierung, um die Arbeit zu erleichtern. Das Erste und Wichtigste, was wir danach tun m\u00fcssen, ist, den Migrationsprozess zu starten. Dies k\u00f6nnen wir entweder manuell und gezielt oder per Zeitplan f\u00fcr alle Maschinen gleichzeitig erledigen.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIch erinnere daran, dass Hystax als Produkt f\u00fcr Migration positioniert wurde. Daher ist es nicht \u00fcberraschend, dass wir einen DR-Plan erstellen m\u00fcssen, um unsere replizierten Maschinen zu starten. Der Plan kann f\u00fcr Maschinen erstellt werden, die sich bereits im Zustand 'Synced' befinden. Dabei kann ein Plan sowohl f\u00fcr eine bestimmte VM als auch f\u00fcr alle Maschinen auf einmal generiert werden.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDie Parameter beim Generieren eines DR-Plans variieren je nach der Infrastruktur, in die Sie migrieren m\u00f6chten. F\u00fcr die VMware-Umgebung steht eine minimalistische Parametergruppe zur Verf\u00fcgung. Re-IP f\u00fcr Maschinen wird ebenfalls nicht unterst\u00fctzt. 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 \u2013 1CPU, 2GB RAM. Im Abschnitt subnets definieren wir, dass \"subnet\": \"VMNetwork\" mit dem Netzwerk \"VM Network\" von VMware assoziiert ist.\u00a0<\/p>\n

Beim Erstellen eines DR-Plans ist es nicht m\u00f6glich, die Festplatten auf verschiedene Datastores zu verteilen. Sie werden im selben Datastore gespeichert, der f\u00fcr diese Kunden-Cloud bestimmt wurde. Wenn Sie Festplatten unterschiedlicher Klassen haben, kann dies beim Start der Maschine zu Problemen f\u00fchren. Au\u00dferdem 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\u00f6tigt ebenfalls Zeit. Auf meiner gr\u00f6\u00dften Testmaschine mit 100 GB und drei Festplatten dauerte es maximal 10 Minuten.<\/p>\n

\"Hystax<\/a><\/noindex>
\nAnschlie\u00dfend sollten Sie die gestartete VM, die darauf laufenden Dienste, die Konsistenz der Daten und weitere \u00dcberpr\u00fcfungen pr\u00fcfen.\u00a0<\/p>\n

Nun stehen uns zwei Wege offen:\u00a0<\/p>\n

    \n
  1. L\u00f6schen \u2013 den gestarteten DR-Plan entfernen. Diese Aktion schaltet lediglich die laufende VM aus. Die Daten der Replikate gehen dabei nicht verloren.\u00a0<\/li>\n
  2. Abkoppeln \u2013 die replizierte Maschine von Acura trennen, d. h. den Migrationsprozess faktisch abschlie\u00dfen.\u00a0<\/li>\n<\/ol>\n

    \nVorteile der L\u00f6sung:<\/strong>\u00a0<\/p>\n