{"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\/fr\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam","title":{"rendered":"Hystax Cloud Migration : sautons d'un cloud \u00e0 l'autre","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

L'un des jeunes acteurs du march\u00e9 des solutions de r\u00e9cup\u00e9ration apr\u00e8s sinistre est Hystax - une start-up russe fond\u00e9e en 2016. \u00c9tant donn\u00e9 que le sujet de la r\u00e9cup\u00e9ration apr\u00e8s sinistre est tr\u00e8s populaire et que la concurrence sur le march\u00e9 est extr\u00eame, la start-up a d\u00e9cid\u00e9 de se concentrer sur la migration entre diff\u00e9rentes infrastructures cloud. Un produit permettant une migration simple et rapide vers le cloud serait \u00e9galement tr\u00e8s utile pour les clients de la soci\u00e9t\u00e9 \u00ab\u041e\u043d\u043b\u0430\u043d\u0442\u0430\u00bb - utilisateurs. Oncloud.ru<\/a><\/noindex>. C'est ainsi que j'ai fait connaissance avec Hystax et commenc\u00e9 \u00e0 tester ses capacit\u00e9s. Ce que j'en ai retir\u00e9, je vais vous le raconter dans cet article.<\/p>\n

\"Hystax<\/a><\/noindex>
\nLa principale caract\u00e9ristique de Hystax est sa large fonctionnalit\u00e9 de support pour diff\u00e9rentes plateformes de virtualisation, syst\u00e8mes d'exploitation invit\u00e9s et services cloud, ce qui permet de transf\u00e9rer vos charges de travail d'o\u00f9 que ce soit vers n'importe o\u00f9.<\/p>\n

Cela permet de cr\u00e9er non seulement des solutions de r\u00e9cup\u00e9ration apr\u00e8s sinistre pour am\u00e9liorer la r\u00e9silience des services, mais aussi de migrer rapidement et de mani\u00e8re flexible des ressources entre diff\u00e9rentes plateformes et hyperscalers pour maximiser les \u00e9conomies et choisir la meilleure solution pour un service sp\u00e9cifique \u00e0 un moment donn\u00e9. En plus des plateformes list\u00e9es sur l'image principale, l'entreprise collabore \u00e9galement activement avec des fournisseurs de cloud russes : Yandex.Cloud, KROK \u00ab Cloud Services \u00bb, Mail.ru et bien d'autres. Il convient \u00e9galement de noter qu'en 2020, l'entreprise a ouvert un centre de R&D situ\u00e9 \u00e0 Skolkovo.\u00a0<\/p>\n

Le choix d'une solution par de nombreux acteurs sur le march\u00e9 t\u00e9moigne d'une bonne politique tarifaire et d'une haute applicabilit\u00e9 du produit, ce que nous avons d\u00e9cid\u00e9 de v\u00e9rifier en pratique.<\/p>\n

Ainsi, notre t\u00e2che de test consistera \u00e0 migrer de ma plateforme de test VMware et de machines physiques vers la plateforme d'un fournisseur \u00e9galement sous VMware. Oui, il existe de nombreuses solutions qui peuvent effectuer une telle migration, mais nous consid\u00e9rons Hystax comme un outil universel, et tester la migration dans toutes les combinaisons possibles est tout simplement une t\u00e2che irr\u00e9aliste. De plus, le cloud Oncloud.ru est construit pr\u00e9cis\u00e9ment sur VMware, donc cette plateforme comme cible nous int\u00e9resse particuli\u00e8rement. Je vais maintenant d\u00e9crire le principe de fonctionnement de base, qui ne d\u00e9pend en g\u00e9n\u00e9ral pas de la plateforme, et VMware peut \u00eatre remplac\u00e9 par la plateforme d'un autre fournisseur.\u00a0<\/p>\n

La premi\u00e8re \u00e9tape consiste \u00e0 d\u00e9ployer Hystax Acura, qui est le panneau de contr\u00f4le du syst\u00e8me.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIl se d\u00e9ploie \u00e0 partir d'un mod\u00e8le. Pour une raison quelconque, dans notre cas, il n'\u00e9tait pas tout \u00e0 fait correct et au lieu des 8 CPU recommand\u00e9s et de 16 Go, il se d\u00e9ployait avec des ressources deux fois inf\u00e9rieures. Il ne faut donc pas oublier de les modifier, sinon l'infrastructure \u00e0 l'int\u00e9rieur de la VM, sur laquelle tout est construit, ne se lancera tout simplement pas et le portail sera inaccessible. \u00c0 Exigences de d\u00e9ploiement<\/a><\/noindex> sont d\u00e9crites en d\u00e9tail les ressources requises ainsi que les ports pour tous les composants du syst\u00e8me.\u00a0<\/p>\n

Et il y a \u00e9galement eu des difficult\u00e9s pour d\u00e9finir l'adresse IP via le mod\u00e8le, donc nous l'avons modifi\u00e9e depuis la console. Apr\u00e8s cela, vous pouvez acc\u00e9der \u00e0 l'interface web de l'administration et remplir l'assistant de configuration initial.\u00a0<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nPoint de terminaison \u2013 l'adresse IP ou le FQDN de notre vCenter.\u00a0
\nLogin et mot de passe \u2013 ici c'est clair.\u00a0
\nNom d'h\u00f4te ESXi cible \u2013 un des h\u00f4tes de notre cluster vers lequel la r\u00e9plication sera effectu\u00e9e.\u00a0
\nDatastore cible \u2013 un des datastores de notre cluster vers lequel la r\u00e9plication sera effectu\u00e9e.
\nAdresse IP publique du panneau de contr\u00f4le Hystax Acura \u2013 l'adresse par laquelle le panneau de contr\u00f4le sera accessible.<\/p>\n

Il est n\u00e9cessaire de pr\u00e9ciser l\u00e9g\u00e8rement l'h\u00f4te et le datastore. En effet, la r\u00e9plication Hystax fonctionne au niveau de l'h\u00f4te et du datastore. Je vais expliquer comment changer l'h\u00f4te et le datastore pour le locataire, mais le probl\u00e8me est diff\u00e9rent. Hystax ne prend pas en charge le travail avec les pools de ressources, c'est-\u00e0-dire que la r\u00e9plication se fera toujours dans la racine du cluster (au moment de la r\u00e9daction de cet article, l'\u00e9quipe de Hystax a publi\u00e9 une version mise \u00e0 jour dans laquelle ils ont rapidement int\u00e9gr\u00e9 ma demande de fonctionnalit\u00e9 concernant le support des pools de ressources). vCloud Director n'est pas non plus pris en charge, c'est-\u00e0-dire que, comme dans mon cas, si le locataire n'a pas les droits d'administrateur sur l'ensemble du cluster, mais seulement sur un pool de ressources sp\u00e9cifique, et que nous avons donn\u00e9 acc\u00e8s \u00e0 Hystax, il pourra r\u00e9pliquer et d\u00e9marrer ces VM de mani\u00e8re autonome, mais il ne pourra pas les voir dans l'infrastructure VMware \u00e0 laquelle il a acc\u00e8s et, par cons\u00e9quent, g\u00e9rer ensuite les machines virtuelles. Il est n\u00e9cessaire que l'administrateur du cluster d\u00e9place la VM dans le bon pool de ressources ou l'importer dans vCloud Director.<\/p>\n

Pourquoi est-ce que je mets autant l'accent sur ces points ? Parce que, d'apr\u00e8s ma compr\u00e9hension du concept du produit, le client doit \u00eatre capable de r\u00e9aliser lui-m\u00eame toute migration ou DR via le panneau Acura. Cependant, le support de VMware est encore un peu en retard par rapport \u00e0 celui d'OpenStack, o\u00f9 de tels m\u00e9canismes sont d\u00e9j\u00e0 en place.\u00a0<\/p>\n

Mais revenons au d\u00e9ploiement. Tout d'abord, apr\u00e8s la configuration initiale du panneau, nous devons cr\u00e9er le premier locataire dans notre syst\u00e8me.<\/p>\n

\"Hystax<\/a><\/noindex>
\nTous les champs ici sont clairs, je vais seulement parler du champ Cloud. Nous avons d\u00e9j\u00e0 un nuage \u00ab par d\u00e9faut \u00bb que nous avons cr\u00e9\u00e9 lors de la configuration initiale. Mais si nous souhaitons avoir la possibilit\u00e9 de placer chaque locataire sur son propre datastore et dans son propre pool de ressources, nous pouvons le r\u00e9aliser en cr\u00e9ant des nuages distincts pour chacun de nos clients.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDans le formulaire d'ajout d'un nouveau nuage, nous indiquons les m\u00eames param\u00e8tres que lors de la configuration initiale (nous pouvons m\u00eame utiliser le m\u00eame h\u00f4te), pr\u00e9ciser le datastore n\u00e9cessaire pour le client sp\u00e9cifique, et maintenant, dans les param\u00e8tres suppl\u00e9mentaires, nous pouvons d\u00e9j\u00e0 indiquer individuellement le pool de ressources n\u00e9cessaire {\u00abresource_pool\u00bb: \u00abYOUR_POOL_NAME\u00bb}.\u00a0<\/p>\n

Comme vous avez pu le remarquer, dans le formulaire de cr\u00e9ation de locataire, il n'y a rien sur l'attribution des ressources ou sur des quotas - rien de tout cela n'existe dans le syst\u00e8me. Il n'est pas possible de limiter un locataire en fonction du nombre de r\u00e9pliques simultan\u00e9es, du nombre de machines \u00e0 r\u00e9pliquer ou selon d'autres param\u00e8tres. Ainsi, nous avons cr\u00e9\u00e9 le premier locataire. Maintenant, il y a une chose qui n'est pas tout \u00e0 fait logique, mais qui est n\u00e9cessaire - l'installation de l'agent Cloud. Cela n'a pas de sens, car l'agent est t\u00e9l\u00e9charg\u00e9 sur la page d'un client particulier.<\/p>\n

\"Hystax<\/a><\/noindex>
\nCependant, il ne se lie pas au tenant cr\u00e9\u00e9, et tous nos clients travailleront par son interm\u00e9diaire (ou par plusieurs, si nous les d\u00e9ployons). Un agent prend en charge 10 sessions simultan\u00e9es. Une session est consid\u00e9r\u00e9e comme une machine. Peu importe le nombre de disques qu'elle poss\u00e8de. \u00c0 ce jour, il n'existe pas de m\u00e9canisme pour mettre \u00e0 l'\u00e9chelle les agents au sein d'Acura sous VMware. Il y a aussi un autre probl\u00e8me d\u00e9sagr\u00e9able \u2013 nous n'avons pas la possibilit\u00e9, \u00e0 partir du panneau d'Acura, de v\u00e9rifier l'\u00ab utilisation \u00bb de cet agent pour d\u00e9cider s'il est n\u00e9cessaire de d\u00e9ployer un autre ou si l'installation actuelle est suffisante. En fin de compte, le stand se pr\u00e9sente comme suit :<\/p>\n

\"Hystax<\/a><\/noindex>
\nLa prochaine \u00e9tape pour acc\u00e9der au portail de notre client consiste \u00e0 cr\u00e9er un compte (et au pr\u00e9alable, un r\u00f4le qui sera attribu\u00e9 \u00e0 cet utilisateur).<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nMaintenant, notre client peut utiliser le portail de mani\u00e8re autonome. Tout ce qu'il doit faire est de t\u00e9l\u00e9charger les agents depuis le portail et de les installer de son c\u00f4t\u00e9. Il existe trois types d'agents : Linux, Windows et VMware.<\/p>\n

\"Hystax<\/a><\/noindex>
\nLes deux premiers s'installent sur des machines physiques ou sur des machines virtuelles sur tout hyperviseur, autre que VMware. Ici, il n'est pas n\u00e9cessaire de configurer quoi que ce soit de plus, l'agent est t\u00e9l\u00e9charg\u00e9 et sait d\u00e9j\u00e0 o\u00f9 se connecter, et en moins d'une minute, la machine sera visible dans le panneau d'Acura. La situation avec l'agent VMware est un peu plus complexe. Le probl\u00e8me est que l'agent pour VMware est \u00e9galement t\u00e9l\u00e9charg\u00e9 depuis le portail, d\u00e9j\u00e0 pr\u00e9par\u00e9 et contenant la configuration n\u00e9cessaire. Mais l'agent VMware, en plus de conna\u00eetre notre portail Acura, doit \u00e9galement conna\u00eetre le syst\u00e8me de virtualisation sur lequel il sera d\u00e9ploy\u00e9.<\/p>\n

\"Hystax<\/a><\/noindex>
\nEn fait, ce sont ces donn\u00e9es que le syst\u00e8me nous demandera d'indiquer lors du premier t\u00e9l\u00e9chargement de l'agent VMware. Le probl\u00e8me est qu'\u00e0 notre \u00e9poque, avec cet amour g\u00e9n\u00e9ral pour la s\u00e9curit\u00e9, peu de gens voudront indiquer leur mot de passe administrateur sur un portail \u00e9tranger, ce qui est tout \u00e0 fait compr\u00e9hensible. De l'int\u00e9rieur, apr\u00e8s le d\u00e9ploiement, l'agent ne peut plus \u00eatre configur\u00e9 (on ne peut changer que ses param\u00e8tres r\u00e9seau). Ici, je pr\u00e9vois des difficult\u00e9s avec des clients particuli\u00e8rement prudents.\u00a0<\/p>\n

Ainsi, apr\u00e8s l'installation des agents, nous pouvons revenir au panneau d'Acura et voir toutes nos machines.<\/p>\n

\"Hystax<\/a><\/noindex>
\n\u00c9tant donn\u00e9 que je travaille avec le syst\u00e8me depuis un certain temps, j'ai des machines dans divers \u00e9tats. Elles sont toutes dans le groupe Default, mais il est possible de cr\u00e9er des groupes s\u00e9par\u00e9s et d'y transf\u00e9rer les machines selon vos besoins. Cela n'affecte rien \u2013 c'est juste une repr\u00e9sentation logique des donn\u00e9es et leur regroupement pour un travail plus pratique. La premi\u00e8re et la plus importante chose \u00e0 faire apr\u00e8s cela est de lancer le processus de migration. Nous pouvons le faire soit manuellement de mani\u00e8re forc\u00e9e, soit configurer un calendrier, y compris de mani\u00e8re massive pour toutes les machines \u00e0 la fois.<\/p>\n

\"Hystax<\/a><\/noindex>
\nJe rappelle que Hystax se positionnait comme un produit de migration. Il n'est donc pas surprenant que pour d\u00e9marrer nos machines r\u00e9pliqu\u00e9es, nous devions cr\u00e9er un plan DR. Ce plan peut \u00eatre \u00e9tabli pour des machines qui sont d\u00e9j\u00e0 en \u00e9tat Sync. Il est possible de le g\u00e9n\u00e9rer pour une VM sp\u00e9cifique ou pour toutes les machines en m\u00eame temps.<\/p>\n

\"Hystax<\/a><\/noindex>
\nL'ensemble des param\u00e8tres lors de la g\u00e9n\u00e9ration du plan DR variera en fonction de l'infrastructure vers laquelle vous migrez. Un minimum de param\u00e8tres est disponible pour un environnement VMware. De plus, le Re-IP n'est pas pris en charge pour les machines. Dans ce plan, nous nous int\u00e9ressons aux points suivants : dans la description de la VM, le param\u00e8tre \u00ab subnet \u00bb : \u00ab VMNetwork \u00bb, o\u00f9 nous associons la VM \u00e0 un r\u00e9seau sp\u00e9cifique dans le cluster. Le Rank est pertinent lors de la migration de plusieurs VM, il d\u00e9termine l'ordre de leur d\u00e9marrage. Le Flavor d\u00e9crit la configuration de la VM, dans ce cas \u2013 1CPU, 2GB RAM. Dans la section subnets, nous d\u00e9finissons que le \u00ab subnet \u00bb : \u00ab VMNetwork \u00bb est associ\u00e9 au r\u00e9seau \u00ab VM Network \u00bb de VMware.\u00a0<\/p>\n

Lors de la cr\u00e9ation du plan DR, il n'est pas possible de \u00ab disperser \u00bb les disques sur diff\u00e9rents datastores. Ils seront sur le m\u00eame datastore qui a \u00e9t\u00e9 d\u00e9fini pour ce cloud client, et si vous avez des disques de classes diff\u00e9rentes, cela peut poser des difficult\u00e9s lors du d\u00e9marrage de la machine, et apr\u00e8s le d\u00e9marrage et le \u00ab d\u00e9couplage \u00bb de la VM par rapport \u00e0 Hystax, n\u00e9cessitera \u00e9galement une migration s\u00e9par\u00e9e des disques vers les datastores appropri\u00e9s. Ensuite, il ne nous reste plus qu'\u00e0 lancer notre plan DR et attendre que nos machines se mettent en marche. Le processus de conversion P2V\/V2V prend \u00e9galement du temps. Sur ma plus grande machine de test de 100 Go avec trois disques, cela a pris au maximum 10 minutes.<\/p>\n

\"Hystax<\/a><\/noindex>
\nApr\u00e8s cela, il convient de v\u00e9rifier la VM en cours d'ex\u00e9cution, les services sur celle-ci, la coh\u00e9rence des donn\u00e9es et d'effectuer d'autres v\u00e9rifications.\u00a0<\/p>\n

Ensuite, nous avons deux options :\u00a0<\/p>\n

    \n
  1. Supprimer \u2013 \u00e9teindre le plan DR en cours. Cette action \u00e9teindra simplement la VM en cours. Les donn\u00e9es de r\u00e9plication resteront intactes.\u00a0<\/li>\n
  2. D\u00e9tacher \u2013 d\u00e9connecter la machine r\u00e9pliqu\u00e9e d'Acura, c'est-\u00e0-dire terminer effectivement le processus de migration.\u00a0<\/li>\n<\/ol>\n

    \nAvantages de la solution :<\/strong>\u00a0<\/p>\n