{"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 durch die Clouds","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Einer der j\u00fcngeren Akteure auf dem Markt f\u00fcr Disaster-Recovery-L\u00f6sungen ist das Unternehmen Hystax \u2013 ein russisches Start-up aus dem Jahr 2016. Da das Thema Notfallwiederherstellung sehr popul\u00e4r ist und die Konkurrenz auf dem Markt enorm 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\u00f6glicht, w\u00e4re auch f\u00fcr die Kunden von \"Onlanta\" sehr n\u00fctzlich \u2013 den Nutzern. Oncloud.ru<\/a><\/noindex>. So kam ich mit Hystax in Kontakt und begann, seine M\u00f6glichkeiten zu testen. Was daraus geworden ist, berichtige ich in diesem Artikel.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDas Hauptmerkmal von Hystax ist seine breite Funktionalit\u00e4t zur Unterst\u00fctzung verschiedener Virtualisierungsplattformen, Betriebssysteme und Cloud-Dienste, was es erm\u00f6glicht, Ihre Arbeitslasten von \u00fcberall her und wohin auch immer zu verlagern.<\/p>\n

Dies erm\u00f6glicht die Schaffung von nicht nur DR-L\u00f6sungen 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\u00f6sung f\u00fcr einen bestimmten Dienst zu einem bestimmten Zeitpunkt zu w\u00e4hlen. Neben den auf dem Titelbild genannten Plattformen arbeitet das Unternehmen auch aktiv mit russischen Cloud-Anbietern zusammen: Yandex.Cloud, KROK \u201eCloud-Dienste\u201c, Mail.ru und vielen anderen. Au\u00dferdem ist zu erw\u00e4hnen, dass das Unternehmen 2020 ein F&E-Zentrum gegr\u00fcndet hat, das sich in Skolkovo befindet.\u00a0<\/p>\n

Die Wahl eines bestimmten L\u00f6sungsansatzes durch viele Akteure auf dem Markt spricht f\u00fcr eine gute Preispolitik und hohe Anwendbarkeit des Produkts, was wir in der Praxis \u00fcberpr\u00fcfen wollten.<\/p>\n

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\u00f6sungen, die eine solche Migration erm\u00f6glichen, aber wir betrachten Hystax als ein universelles Mittel, und die Migration in allen m\u00f6glichen Kombinationen zu testen, ist einfach eine unrealistische Aufgabe. Au\u00dferdem ist die Cloud Oncloud.ru speziell auf VMware aufgebaut, deswegen interessiert uns diese Plattform als Ziel in hohem Ma\u00dfe. Im Folgenden werde ich das Grundprinzip der Funktionsweise beschreiben, das insgesamt nicht von der Plattform abh\u00e4ngt, und VMware kann von jeder Seite durch eine Plattform eines anderen Anbieters ersetzt werden.\u00a0<\/p>\n

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

\"Hystax<\/a><\/noindex>
\nEs 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 \u00e4ndern, andernfalls kann die Infrastruktur innerhalb der VM, auf der alles aufgebaut ist, einfach nicht gestartet werden und das Portal wird nicht verf\u00fcgbar sein. In Bereitstellungsanforderungen<\/a><\/noindex> sind die ben\u00f6tigten Ressourcen sowie die Ports f\u00fcr alle Systemkomponenten ausf\u00fchrlich beschrieben.\u00a0<\/p>\n

Auch bei der Zuweisung der IP-Adresse \u00fcber die Vorlage gab es Schwierigkeiten, sodass wir sie \u00fcber die Konsole \u00e4ndern mussten. Danach kann man in die Weboberfl\u00e4che des Admin-Panels wechseln und den anf\u00e4nglichen 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 das ist klar.\u00a0
\nHostname des Ziel-ESXi \u2013 einer der Hosts unseres Clusters, auf den die Replikation erfolgen wird.\u00a0
\nZieldatenspeicher \u2013 einer der Datenspeicher unseres Clusters, auf den die Replikation erfolgen wird.
\n\u00d6ffentliche IP des Hystax Acura Control Panels \u2013 die Adresse, unter der das Control Panel verf\u00fcgbar sein wird.<\/p>\n

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\u00e4ter erkl\u00e4ren, wie man f\u00fcr den Tenant den Host und den Datenspeicher wechseln kann, aber das Problem ist ein anderes. Hystax unterst\u00fctzt nicht die Arbeit mit Ressourcen-Pools, das hei\u00dft, 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\u00f6ffentlicht, in der schnell mein Feature-Request zur Unterst\u00fctzung von Ressourcen-Pools implementiert wurde). Auch vCloud Director wird nicht unterst\u00fctzt, das hei\u00dft, wenn, wie in meinem Fall, der Tenant keine Administratorrechte f\u00fcr den gesamten Cluster hat, sondern nur f\u00fcr einen bestimmten Ressourcen-Pool, und wir Hystax Zugriff gew\u00e4hrt 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\u00fcnschten Ressourcen-Pool 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 in der Lage sein sollte, jede Migration oder DR selbst\u00e4ndig \u00fcber das Acura-Panel zu realisieren. Die Unterst\u00fctzung von VMware hinkt jedoch etwas hinter der Unterst\u00fctzung von OpenStack hinterher, wo solche Mechanismen bereits implementiert sind.\u00a0<\/p>\n

Kehren wir zur Bereitstellung zur\u00fcck. Zuerst m\u00fcssen wir nach der urspr\u00fcnglichen Einstellung des Panels den ersten Tenant in unserem System erstellen.<\/p>\n

\"Hystax<\/a><\/noindex>
\nAlle Felder sind hier nachvollziehbar, 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 jeden Tenant in seinem eigenen Datastore und in seinen eigenen Ressourcenpool platzieren m\u00f6chten, k\u00f6nnen wir dies durch die Erstellung separater Clouds f\u00fcr jeden unserer Kunden realisieren.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIm Formular zur Hinzuf\u00fcgung einer neuen Cloud geben wir dieselben Parameter an wie bei der urspr\u00fcnglichen Konfiguration (wir k\u00f6nnen sogar denselben Host verwenden), 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 {\u201eresource_pool\u201c: \u201eYOUR_POOL_NAME\u201c}\u00a0<\/p>\n

Wie Sie vielleicht bemerkt haben, gibt es im Formular zur Erstellung eines Tenants nichts \u00fcber Ressourcenzuweisungen oder Quoten \u2013 das ist alles nicht im System vorhanden. Es ist nicht m\u00f6glich, einen Tenant in der Anzahl der gleichzeitigen Replikate, der Anzahl der Maschinen f\u00fcr die Replikation oder durch andere Parameter zu beschr\u00e4nken. So, wir haben den ersten Tenant erstellt. Jetzt gibt es eine nicht ganz logische, aber notwendige Sache \u2013 die Installation des Cloud-Agenten. 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 \u00fcber ihn werden alle unsere Kunden arbeiten (oder \u00fcber mehrere, wenn wir sie bereitstellen). Ein Agent unterst\u00fctzt 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 \u2013 wir haben nicht die M\u00f6glichkeit, \u00fcber 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:<\/p>\n

\"Hystax<\/a><\/noindex>
\nDer n\u00e4chste Schritt f\u00fcr den Zugang zum Portal unseres Kunden besteht darin, ein Benutzerkonto zu erstellen (und zuvor 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 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 physischen Maschinen oder auf virtuellen Maschinen auf einem beliebigen Hypervisor, der nicht VMware ist, installiert. Hier ist keine zus\u00e4tzliche Konfiguration erforderlich; der Agent wird heruntergeladen und wei\u00df 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\u00fcr VMware ebenfalls bereits vorbereitet und mit der notwendigen Konfiguration vom Portal heruntergeladen wird. Aber der VMware-Agent muss zus\u00e4tzlich zum Wissen \u00fcber unser Acura-Portal auch Informationen \u00fcber das Virtualisierungssystem haben, auf dem er bereitgestellt wird.<\/p>\n

\"Hystax<\/a><\/noindex>
\nEigentlich 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\u00e4ndlich ist. Von innen, nach der Bereitstellung, l\u00e4sst sich der Agent nicht mehr konfigurieren (man kann nur seine Netzwerkeinstellungen \u00e4ndern). Hier sehe ich Schwierigkeiten mit besonders vorsichtigen Kunden.\u00a0<\/p>\n

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

\"Hystax<\/a><\/noindex>
\nDa ich bereits seit mehreren Tagen mit dem System arbeite, habe ich Maschinen in verschiedenen Zust\u00e4nden. Alle sind in der Gruppe Default, aber es besteht die M\u00f6glichkeit, separate Gruppen zu erstellen und die Maschinen dorthin zu verschieben, wie Sie es ben\u00f6tigen. Dies hat keinen Einfluss auf etwas \u2013 es handelt sich nur um eine logische Datenpr\u00e4sentation und Gruppierung f\u00fcr eine bequemere Arbeit. Das Erste und Wichtigste, was wir danach tun m\u00fcssen, ist, den Migrationsprozess zu starten. Wir k\u00f6nnen dies sowohl manuell und zwangsl\u00e4ufig als auch durch die Einrichtung eines Zeitplans tun, auch massenhaft f\u00fcr alle Maschinen gleichzeitig.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIch erinnere daran, dass Hystax sich als Produkt f\u00fcr Migration positioniert hat. Daher ist es nicht \u00fcberraschend, dass wir f\u00fcr den Start unserer replizierten Maschinen einen DR-Plan erstellen m\u00fcssen. Der Plan kann f\u00fcr Maschinen erstellt werden, die sich bereits im Zustand Synced befinden. Man kann ihn sowohl f\u00fcr eine bestimmte VM als auch f\u00fcr alle Maschinen auf einmal generieren.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDer Satz an Parametern beim Generieren des DR-Plans wird je nach Infrastruktur, in die Sie migrieren m\u00f6chten, variieren. F\u00fcr die VMware-Umgebung ist eine minimale Anzahl von Parametern verf\u00fcgbar. Zudem wird Re-IP f\u00fcr Maschinen nicht unterst\u00fctzt. In diesem Plan interessieren uns folgende Punkte: Im Beschreibung der VM ist der Parameter \u201esubnet\u201c: \u201eVMNetwork\u201c, wo wir die VM mit einem bestimmten Netzwerk im Cluster verkn\u00fcpfen. Rank ist relevant, wenn mehrere VMs migriert werden, da er die Reihenfolge ihres Starts bestimmt. Flavor beschreibt die Konfiguration der VM, in diesem Fall \u2013 1CPU, 2GB RAM. Im Abschnitt subnets definieren wir, dass \u201esubnet\u201c: \u201eVMNetwork\u201c mit dem Netzwerk \u201eVM Network\u201c von VMware assoziiert ist.\u00a0<\/p>\n

Beim Erstellen eines DR-Plans gibt es keine M\u00f6glichkeit, die Festplatten auf verschiedene Datastores zu verteilen. Sie befinden sich im selben Datastore, der f\u00fcr 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 \u201eTrennung\u201c der VM von Hystax erfordert es eine separate Migration der Festplatten auf die erforderlichen Datastores. Danach m\u00fcssen wir nur noch unseren DR-Plan ausf\u00fchren und warten, bis unsere Maschinen hochgefahren sind. Der Prozess der P2V\/V2V-Konvertierung ben\u00f6tigt ebenfalls Zeit. Bei meiner gr\u00f6\u00dften Testmaschine mit 100 GB und drei Festplatten hat es maximal 10 Minuten gedauert.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDanach sollte die gestartete VM, die darauf befindlichen Dienste, die Konsistenz der Daten sowie weitere Pr\u00fcfungen \u00fcberpr\u00fcft werden.\u00a0<\/p>\n

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

    \n
  1. L\u00f6schen \u2013 den gestarteten DR-Plan entfernen. Diese Aktion wird einfach die gestartete VM herunterfahren. Die Daten der Replikate gehen dadurch nicht verloren.\u00a0<\/li>\n
  2. Trennen \u2013 die replizierte Maschine von Acura abtrennen, d.h. den Migrationsprozess tats\u00e4chlich beenden.\u00a0<\/li>\n<\/ol>\n

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