L'une des jeunes entreprises sur le marché des solutions de récupération après sinistre est Hystax, une startup russe créée en 2016. Étant donné que le sujet de la récupération après sinistre est très populaire et que la concurrence sur le marché est extrêmement forte, la startup a décidé de se concentrer sur la migration entre différentes infrastructures cloud. Un produit permettant une migration simple et rapide vers le cloud serait très utile également pour les clients de la société « Onlanta » — utilisateurs. . C'est ainsi que j'ai fait connaissance avec Hystax et commencé à tester ses capacités. Ce que j'en ai retiré, je vais vous le raconter dans cet article.
La principale caractéristique de Hystax est sa large fonctionnalité de support pour différentes plateformes de virtualisation, systèmes d'exploitation invités et services cloud, ce qui permet de transférer vos charges de travail d'où que ce soit vers n'importe où.
Cela permet de créer non seulement des solutions de récupération après sinistre pour améliorer la résilience des services, mais aussi de migrer rapidement et de manière flexible des ressources entre différentes plateformes et hyperscalers pour maximiser les économies et choisir la meilleure solution pour un service spécifique à un moment donné. En plus des plateformes listées sur l'image principale, l'entreprise collabore également activement avec des fournisseurs de cloud russes : Yandex.Cloud, KROK « Cloud Services », Mail.ru et bien d'autres. Il convient également de noter qu'en 2020, l'entreprise a ouvert un centre de R&D situé à Skolkovo.
Le choix d'une solution par de nombreux acteurs sur le marché témoigne d'une bonne politique tarifaire et d'une haute applicabilité du produit, ce que nous avons décidé de vérifier en pratique.
Ainsi, notre tâche de test consistera à migrer de ma plateforme de test VMware et de machines physiques vers la plateforme d'un fournisseur également sous VMware. Oui, il existe de nombreuses solutions qui peuvent effectuer une telle migration, mais nous considérons Hystax comme un outil universel, et tester la migration dans toutes les combinaisons possibles est tout simplement une tâche irréaliste. De plus, le cloud Oncloud.ru est construit précisément sur VMware, donc cette plateforme comme cible nous intéresse particulièrement. Je vais maintenant décrire le principe de fonctionnement de base, qui ne dépend en général pas de la plateforme, et VMware peut être remplacé par la plateforme d'un autre fournisseur.
La première étape consiste à déployer Hystax Acura, qui est le panneau de contrôle du système.
Il se déploie à partir d'un modèle. Pour une raison quelconque, dans notre cas, il n'était pas tout à fait correct et au lieu des 8 CPU recommandés et de 16 Go, il se déployait avec des ressources deux fois inférieures. Il ne faut donc pas oublier de les modifier, sinon l'infrastructure à l'intérieur de la VM, sur laquelle tout est construit, ne se lancera tout simplement pas et le portail sera inaccessible. À sont décrites en détail les ressources requises ainsi que les ports pour tous les composants du système.
Et il y a également eu des difficultés pour définir l'adresse IP via le modèle, donc nous l'avons modifiée depuis la console. Après cela, vous pouvez accéder à l'interface web de l'administration et remplir l'assistant de configuration initial.
Point de terminaison – l'adresse IP ou le FQDN de notre vCenter.
Login et mot de passe – ici c'est clair.
Nom d'hôte ESXi cible – un des hôtes de notre cluster vers lequel la réplication sera effectuée.
Datastore cible – un des datastores de notre cluster vers lequel la réplication sera effectuée.
Adresse IP publique du panneau de contrôle Hystax Acura – l'adresse par laquelle le panneau de contrôle sera accessible.
Il est nécessaire de préciser légèrement l'hôte et le datastore. En effet, la réplication Hystax fonctionne au niveau de l'hôte et du datastore. Je vais expliquer comment changer l'hôte et le datastore pour le locataire, mais le problème est différent. Hystax ne prend pas en charge le travail avec les pools de ressources, c'est-à-dire que la réplication se fera toujours dans la racine du cluster (au moment de la rédaction de cet article, l'équipe de Hystax a publié une version mise à jour dans laquelle ils ont rapidement intégré ma demande de fonctionnalité concernant le support des pools de ressources). vCloud Director n'est pas non plus pris en charge, c'est-à-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écifique, et que nous avons donné accès à Hystax, il pourra répliquer et démarrer ces VM de manière autonome, mais il ne pourra pas les voir dans l'infrastructure VMware à laquelle il a accès et, par conséquent, gérer ensuite les machines virtuelles. Il est nécessaire que l'administrateur du cluster déplace la VM dans le bon pool de ressources ou l'importer dans vCloud Director.
Pourquoi est-ce que je mets autant l'accent sur ces points ? Parce que, d'après ma compréhension du concept du produit, le client doit être capable de réaliser lui-même toute migration ou DR via le panneau Acura. Cependant, le support de VMware est encore un peu en retard par rapport à celui d'OpenStack, où de tels mécanismes sont déjà en place.
Mais revenons au déploiement. Tout d'abord, après la configuration initiale du panneau, nous devons créer le premier locataire dans notre système.
Tous les champs ici sont clairs, je vais seulement parler du champ Cloud. Nous avons déjà un nuage « par défaut » que nous avons créé lors de la configuration initiale. Mais si nous souhaitons avoir la possibilité de placer chaque locataire sur son propre datastore et dans son propre pool de ressources, nous pouvons le réaliser en créant des nuages distincts pour chacun de nos clients.
Dans le formulaire d'ajout d'un nouveau nuage, nous indiquons les mêmes paramètres que lors de la configuration initiale (nous pouvons même utiliser le même hôte), préciser le datastore nécessaire pour le client spécifique, et maintenant, dans les paramètres supplémentaires, nous pouvons déjà indiquer individuellement le pool de ressources nécessaire {«resource_pool»: «YOUR_POOL_NAME»}.
Comme vous avez pu le remarquer, dans le formulaire de création 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ème. Il n'est pas possible de limiter un locataire en fonction du nombre de répliques simultanées, du nombre de machines à répliquer ou selon d'autres paramètres. Ainsi, nous avons créé le premier locataire. Maintenant, il y a une chose qui n'est pas tout à fait logique, mais qui est nécessaire - l'installation de l'agent Cloud. Cela n'a pas de sens, car l'agent est téléchargé sur la page d'un client particulier.
Cependant, il ne se lie pas au tenant créé, et tous nos clients travailleront par son intermédiaire (ou par plusieurs, si nous les déployons). Un agent prend en charge 10 sessions simultanées. Une session est considérée comme une machine. Peu importe le nombre de disques qu'elle possède. À ce jour, il n'existe pas de mécanisme pour mettre à l'échelle les agents au sein d'Acura sous VMware. Il y a aussi un autre problème désagréable – nous n'avons pas la possibilité, à partir du panneau d'Acura, de vérifier l'« utilisation » de cet agent pour décider s'il est nécessaire de déployer un autre ou si l'installation actuelle est suffisante. En fin de compte, le stand se présente comme suit :
La prochaine étape pour accéder au portail de notre client consiste à créer un compte (et au préalable, un rôle qui sera attribué à cet utilisateur).
Maintenant, notre client peut utiliser le portail de manière autonome. Tout ce qu'il doit faire est de télécharger les agents depuis le portail et de les installer de son côté. Il existe trois types d'agents : Linux, Windows et VMware.
Les 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écessaire de configurer quoi que ce soit de plus, l'agent est téléchargé et sait déjà où 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ème est que l'agent pour VMware est également téléchargé depuis le portail, déjà préparé et contenant la configuration nécessaire. Mais l'agent VMware, en plus de connaître notre portail Acura, doit également connaître le système de virtualisation sur lequel il sera déployé.
En fait, ce sont ces données que le système nous demandera d'indiquer lors du premier téléchargement de l'agent VMware. Le problème est qu'à notre époque, avec cet amour général pour la sécurité, peu de gens voudront indiquer leur mot de passe administrateur sur un portail étranger, ce qui est tout à fait compréhensible. De l'intérieur, après le déploiement, l'agent ne peut plus être configuré (on ne peut changer que ses paramètres réseau). Ici, je prévois des difficultés avec des clients particulièrement prudents.
Ainsi, après l'installation des agents, nous pouvons revenir au panneau d'Acura et voir toutes nos machines.
Étant donné que je travaille avec le système depuis un certain temps, j'ai des machines dans divers états. Elles sont toutes dans le groupe Default, mais il est possible de créer des groupes séparés et d'y transférer les machines selon vos besoins. Cela n'affecte rien – c'est juste une représentation logique des données et leur regroupement pour un travail plus pratique. La première et la plus importante chose à faire après cela est de lancer le processus de migration. Nous pouvons le faire soit manuellement de manière forcée, soit configurer un calendrier, y compris de manière massive pour toutes les machines à la fois.
Je rappelle que Hystax se positionnait comme un produit de migration. Il n'est donc pas surprenant que pour démarrer nos machines répliquées, nous devions créer un plan DR. Ce plan peut être établi pour des machines qui sont déjà en état Sync. Il est possible de le générer pour une VM spécifique ou pour toutes les machines en même temps.
L'ensemble des paramètres lors de la génération du plan DR variera en fonction de l'infrastructure vers laquelle vous migrez. Un minimum de paramètres 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éressons aux points suivants : dans la description de la VM, le paramètre « subnet » : « VMNetwork », où nous associons la VM à un réseau spécifique dans le cluster. Le Rank est pertinent lors de la migration de plusieurs VM, il détermine l'ordre de leur démarrage. Le Flavor décrit la configuration de la VM, dans ce cas – 1CPU, 2GB RAM. Dans la section subnets, nous définissons que le « subnet » : « VMNetwork » est associé au réseau « VM Network » de VMware.
Lors de la création du plan DR, il n'est pas possible de « disperser » les disques sur différents datastores. Ils seront sur le même datastore qui a été défini pour ce cloud client, et si vous avez des disques de classes différentes, cela peut poser des difficultés lors du démarrage de la machine, et après le démarrage et le « découplage » de la VM par rapport à Hystax, nécessitera également une migration séparée des disques vers les datastores appropriés. Ensuite, il ne nous reste plus qu'à lancer notre plan DR et attendre que nos machines se mettent en marche. Le processus de conversion P2V/V2V prend également du temps. Sur ma plus grande machine de test de 100 Go avec trois disques, cela a pris au maximum 10 minutes.
Après cela, il convient de vérifier la VM en cours d'exécution, les services sur celle-ci, la cohérence des données et d'effectuer d'autres vérifications.
Ensuite, nous avons deux options :
- Supprimer – éteindre le plan DR en cours. Cette action éteindra simplement la VM en cours. Les données de réplication resteront intactes.
- Détacher – déconnecter la machine répliquée d'Acura, c'est-à-dire terminer effectivement le processus de migration.
Avantages de la solution :
- facilité d'installation et de configuration tant du côté client que fournisseur ;
- simplicité de configuration de la migration, de la création du plan DR et du lancement des répliques ;
- le support et les développeurs réagissent assez rapidement aux problèmes rencontrés et les corrigent via des mises à jour de la plateforme ou des agents.
Inconvénients
- Support insuffisant pour VMware.
- Absence de toute forme de quota pour les locataires de la part de la plateforme.
J'ai également rédigé une demande de fonctionnalités que nous avons soumise au fournisseur :
- surveillance de l'utilisation et déploiement depuis la console de gestion d'Acura pour les agents Cloud ;
- introduction de quotas pour les locataires ;
- capacité à limiter le nombre de réplications simultanées et la vitesse pour chaque locataire ;
- support de VMware vCloud Director ;
- support des pools de ressources (réalisé lors des tests) ;
- possibilité de configurer l'agent VMware depuis l'agent lui-même, sans avoir à entrer les informations d'identification de l'infrastructure client dans le panneau d'Acura ;
- « visualisation » du processus de lancement de la VM lors du démarrage du plan DR.
La seule chose qui m'a vraiment dérangé, c'est la documentation. Je n'aime pas beaucoup les «boîtes noires» et je préfère avoir une documentation détaillée sur le fonctionnement interne du produit. Et tandis que la documentation pour AWS et OpenStack est relativement correcte, celle pour VMware est extrêmement limitée.
Il existe un guide d'installation qui décrit uniquement le déploiement du panneau d'Acura, sans mentionner que le Cloud-agent est également nécessaire. Il y a un ensemble complet de spécifications sur le produit, ce qui est positif. Il existe une documentation qui décrit la configuration « de A à Z » avec des exemples pour AWS et OpenStack (bien que cela ressemble davantage à un article de blog), ainsi qu'une très petite base de connaissances.
Dans l'ensemble, ce n'est pas tout à fait le format de documentation auquel je suis habitué, disons, auprès de fournisseurs plus importants, donc je n'étais pas vraiment à l'aise. De plus, je n'ai pas trouvé de réponses à certaines nuances du fonctionnement du système « en interne » dans cette documentation – de nombreuses questions ont dû être clarifiées avec le support technique, ce qui a considérablement retardé le processus de déploiement de l'environnement et des tests.
En résumé, je peux dire que, dans l'ensemble, le produit et l'approche de l'entreprise pour réaliser la tâche m'ont plu. Oui, il y a des lacunes, et il manque effectivement des fonctionnalités critiques (en lien avec VMware). On voit que, avant tout, l'entreprise se concentre sur les clouds publics, en particulier AWS, et cela suffira peut-être pour certains. Disposer d'un produit si simple et pratique aujourd'hui, alors que de nombreuses entreprises choisissent une stratégie multicloud, est extrêmement important. Compte tenu du prix beaucoup plus bas par rapport à la concurrence, cela rend le produit très attrayant.
Nous cherchons à rejoindre notre équipe . Peut-être que vous êtes la personne idéale ?
Source : habr.com
