L'un des jeunes acteurs du marché des solutions de reprise après sinistre est Hystax, une startup russe née en 2016. Le thème de la reprise après sinistre étant très populaire et le marché extrêmement compétitif, la startup a décidé de se concentrer sur la migration entre différentes infrastructures cloud. Un produit permettant d'organiser une migration simple et rapide vers le cloud serait également très utile pour les clients - utilisateurs d'Onlanta. . C’est ainsi que j’ai découvert Hystax et que j’ai commencé à tester ses capacités. Je vais vous dire ce qui en est arrivé dans cet article.
La principale caractéristique d'Hystax est sa large fonctionnalité permettant de prendre en charge diverses plates-formes de virtualisation, systèmes d'exploitation invités et services cloud, ce qui permet de transférer vos charges de travail de n'importe où, n'importe où.
Cela vous permet non seulement de créer des solutions DR pour augmenter la tolérance aux pannes des services, mais également de migrer rapidement et de manière flexible les ressources entre différents sites et hyperscalers afin d'augmenter les économies de coûts et de sélectionner la meilleure solution pour un service spécifique à un moment donné. En plus des plates-formes répertoriées dans l'image du titre, la société coopère également activement avec des fournisseurs de cloud russes : Yandex.Cloud, CROC 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 un grand nombre d'acteurs du marché indique une bonne politique tarifaire et une grande applicabilité du produit, que nous avons décidé de tester en pratique.
Ainsi, notre tâche de test consistera à migrer de mon site de test VMware et de mes machines physiques vers le site du fournisseur, également géré par VMware. Oui, il existe de nombreuses solutions permettant d'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. Et le cloud Oncloud.ru est construit spécifiquement sur VMware, donc cette plateforme en tant que cible nous intéresse davantage. Ensuite, je décrirai le principe de fonctionnement de base, qui est généralement indépendant de la plate-forme, et VMware de n'importe quel côté peut être remplacé par une plate-forme 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éroule à partir du modèle. Pour une raison quelconque, dans notre cas, ce n'était pas tout à fait correct et au lieu des 8 CPU recommandés, 16 Go ont été déployés avec la moitié des ressources. Par conséquent, vous devez vous rappeler de les modifier, sinon l'infrastructure de conteneurs à l'intérieur de la VM, sur laquelle tout est construit, ne démarrera tout simplement pas et le portail sera inaccessible. DANS Les ressources requises sont décrites en détail, ainsi que les ports pour tous les composants du système.
Il y avait également des difficultés à définir l'adresse IP via un modèle, nous l'avons donc modifiée depuis la console. Après cela, vous pouvez accéder à l'interface Web d'administration et terminer l'assistant de configuration initiale.
Point de terminaison – IP ou FQDN de notre vCenter.
Identifiant et mot de passe – c'est clair.
Le nom d'hôte ESXi cible est l'un des hôtes de notre cluster sur lequel la réplication sera effectuée.
La banque de données cible est l'une des banques de données de notre cluster vers laquelle la réplication sera effectuée.
IP publique du panneau de commande Hystax Acura – l'adresse à laquelle le panneau de commande sera disponible.
Une petite précision s'impose concernant l'hébergeur et la banque de données. Le fait est que la réplication Hystax fonctionne au niveau de l'hôte et de la banque de données. Ensuite, je vais vous expliquer comment modifier l'hôte et la banque de données d'un locataire, mais le problème est différent. Hystax ne prend pas en charge l'utilisation de pools de ressources, c'est-à-dire la réplique ira toujours à la racine du cluster (au moment de la rédaction de ce document, les gars de Hystax ont publié une version mise à jour, dans laquelle ils ont rapidement implémenté ma demande de fonctionnalité concernant la prise en charge des pools de ressources). vCloud Director n'est pas non plus pris en charge, c'est-à-dire si, comme dans mon cas, le locataire n'a pas de droits d'administrateur sur l'ensemble du cluster, mais uniquement sur un pool de ressources spécifique, et que nous avons donné accès à Hystax, alors il pourra répliquer et lancer indépendamment ces VM, mais il le fera ne pas pouvoir les voir dans l'infrastructure VMware, à laquelle il a accès et, par conséquent, gère en outre les machines virtuelles. Il est nécessaire que l'administrateur du cluster déplace la VM vers le pool de ressources souhaité ou l'importe dans vCloud Director.
Pourquoi est-ce que je me concentre autant sur ces points ? Parce que, pour autant que je comprenne le concept du produit, le client doit être en mesure de mettre en œuvre de manière indépendante toute migration ou reprise après sinistre à l'aide du panneau Acura. Mais jusqu'à présent, le support de VMware est légèrement en retard par rapport au niveau de support d'OpenStack, où des mécanismes similaires ont déjà été implémentés.
Mais revenons au déploiement. Tout d'abord, après la configuration initiale du panel, nous devons créer le premier locataire dans notre système.
Tous les champs ici sont clairs, je ne vous parlerai que du champ Cloud. Nous disposons déjà d'un cloud « par défaut » que nous avons créé lors de la configuration initiale. Mais si nous voulons pouvoir placer chaque locataire sur son propre magasin de données et dans son propre pool de ressources, nous pouvons le mettre en œuvre en créant des cloud séparés pour chacun de nos clients.
Dans le formulaire d'ajout d'un nouveau cloud, nous spécifions les mêmes paramètres que lors de la configuration initiale (nous pouvons même utiliser le même hôte), indiquons la banque de données requise pour un client spécifique, et maintenant dans des paramètres supplémentaires, nous pouvons spécifier individuellement la ressource requise pool {"resource_pool" : "YOUR_POOL_NAME"}
Comme vous l'avez peut-être remarqué, dans le formulaire de création de locataire, il n'y a rien sur l'allocation des ressources ou les quotas - il n'y a rien de tout cela dans le système. Il est impossible de limiter un locataire en nombre de répliques simultanées, en nombre de machines à réplication ou par tout autre paramètre. Nous avons donc créé le premier locataire. Il y a maintenant une chose pas tout à fait logique, mais obligatoire : installer un agent Cloud. C'est illogique, puisque l'agent est téléchargé sur la page d'un client spécifique.
En même temps, il n'est pas lié au locataire créé, et tous nos clients travailleront via lui (ou via plusieurs, si nous les déployons). Un agent prend en charge 10 sessions simultanées. Une machine compte pour une session. Peu importe le nombre de disques dont il dispose. À ce jour, il n'existe aucun mécanisme de mise à l'échelle des agents dans Acura lui-même sous VMware. Il y a encore un moment désagréable - nous n'avons pas la possibilité d'examiner la « élimination » de cet agent du panel Acura afin de conclure si nous devons en déployer davantage ou si l'installation actuelle est suffisante. En conséquence, le stand ressemble à ceci :
La prochaine étape pour accéder à notre portail client consiste à créer un compte (et d'abord, un rôle qui s'appliquera à cet utilisateur).
Notre client peut désormais utiliser le portail de manière indépendante. Il lui suffit 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 sont installés sur physique ou sur des machines virtuelles sur tout hyperviseur autre que VMware. 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ù frapper, et littéralement dans une minute, la voiture sera visible dans le panneau Acura. Avec l'agent VMware, la situation est un peu plus compliquée. 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 en plus de connaître notre portail Acura, un agent VMware doit également connaître le système de virtualisation sur lequel il sera déployé.
En fait, le système nous demandera de fournir ces données lors du premier téléchargement de l'agent VMware. Le problème est qu’à notre époque d’amour universel pour la sécurité, tout le monde ne voudra pas indiquer son mot de passe administrateur sur le portail de quelqu’un d’autre, ce qui est tout à fait compréhensible. De l'intérieur, après déploiement, l'agent ne peut en aucun cas être configuré (vous pouvez uniquement modifier ses paramètres réseau). Ici, je prévois des difficultés avec des clients particulièrement prudents.
Ainsi, après avoir installé les agents, nous pouvons revenir au panneau Acura et voir toutes nos voitures.
Depuis que je travaille avec le système depuis plusieurs jours maintenant, j'ai des voitures dans différents états. Je les ai tous dans le groupe par défaut, mais il est possible de créer des groupes séparés et de leur transférer des voitures selon vos besoins. Cela n'affecte rien - seulement une présentation logique des données et leur regroupement pour un travail plus pratique. La première et la plus importante chose que nous devons faire après cela est de démarrer le processus de migration. Nous pouvons le faire soit manuellement, soit en établissant un calendrier, y compris en masse pour toutes les machines à la fois.
Je vous rappelle qu'Hystax s'est positionné comme un produit de migration. Il n’est donc pas surprenant que pour faire fonctionner nos machines répliquées, nous devions créer un plan de reprise après sinistre. Le plan peut être élaboré pour les machines qui sont déjà à l'état synchronisé. Vous pouvez générer à la fois pour une VM spécifique et pour toutes les machines à la fois.
L'ensemble des paramètres lors de la génération d'un plan DR différera en fonction de l'infrastructure vers laquelle vous migrerez. Un ensemble minimal de paramètres est disponible pour l'environnement VMware. La re-IP pour les machines n'est pas non plus prise en charge. A cet égard, nous nous intéressons aux points suivants : dans la description de la VM, le paramètre « subnet » : « VMNetwork », où l'on lie la VM à un réseau spécifique du cluster. Rank – pertinent lors de la migration de plusieurs VM ; il détermine l’ordre dans lequel elles sont lancées. Flavor – décrit la configuration de la VM, dans ce cas – 1 CPU, 2 Go de RAM. Dans la section sous-réseaux, nous définissons ce « sous-réseau » : « VMNetwork » est associé au « VM Network » VMware.
Lors de la création d’un plan de reprise après sinistre, il n’existe aucun moyen de « répartir » les disques entre différentes banques de données. Ils seront situés sur le même magasin de données qui a été défini pour ce cloud client, et si vous disposez de disques de classes différentes, cela peut entraîner quelques difficultés au démarrage de la machine, et après avoir démarré et « séparé » la VM d'Hystax, cela sera également nécessitent une migration de disques distincte vers les banques de données requises. Il ne nous reste plus qu’à lancer notre plan DR et attendre que nos voitures montent en puissance. Le processus de conversion P2V/V2V prend également du temps. Sur ma plus grande machine de test, 100 Go avec trois disques, cela a pris au maximum 10 minutes.
Après cela, vous devez vérifier la VM en cours d'exécution, les services qui s'y trouvent, la cohérence des données et effectuer d'autres vérifications.
Nous avons alors deux manières :
- Supprimer – supprime le plan DR en cours d'exécution. Cette action arrêtera simplement la VM en cours d’exécution. Ces répliques ne mèneront nulle part.
- Détacher – arrachez une voiture répliquée d’une Acura, c’est-à-dire terminer réellement le processus de migration.
Avantages de la solution :
- facilité d'installation et de configuration tant par le client que par le fournisseur ;
- facilité de configuration de la migration, de création d'un plan de reprise après sinistre et de lancement de réplicas ;
- le support et les développeurs réagissent assez rapidement aux problèmes détectés et les corrigent à l’aide de mises à jour de plateforme ou d’agent.
Moins
- Prise en charge insuffisante de VMware.
- Absence de tout quota de locataires de la plateforme.
J'ai également compilé une demande de fonctionnalité, que nous avons soumise au fournisseur :
- surveillance de l'utilisation et déploiement depuis la console de gestion Acura pour les agents Cloud ;
- disponibilité de quotas pour les locataires ;
- la possibilité de limiter le nombre de réplications simultanées et la vitesse pour chaque locataire ;
- Prise en charge de VMware vCloud Director ;
- prise en charge des pools de ressources (implémentées lors des tests) ;
- la possibilité de configurer l'agent VMware à partir de l'agent lui-même, sans saisir les informations d'identification de l'infrastructure client dans le panneau Acura ;
- « visualisation » du processus de démarrage de la VM lors de l'exécution du plan DR.
La seule chose qui m'a valu de grosses critiques était la documentation. Je n'aime pas vraiment les "boîtes noires" et je préfère qu'il y ait une documentation détaillée sur le fonctionnement du produit à l'intérieur. Et si pour AWS et OpenStack le produit est décrit encore plus ou moins, alors pour VMware il y a très peu de documentation.
Il existe un guide d'installation qui décrit uniquement le déploiement du panneau Acura, et il n'y a pas un mot sur le fait qu'un agent Cloud est également nécessaire. Il existe un ensemble complet de spécifications de produits, ce qui est une bonne chose. Il existe une documentation qui décrit la configuration « du début à la fin » en utilisant AWS et OpenStack comme exemple (même si cela ressemble plus à un article de blog pour moi), et il existe une très petite base de connaissances.
En général, ce n'est pas tout à fait le format de documentation auquel je suis habitué, par exemple chez les grands fournisseurs, donc je n'étais pas tout à fait à l'aise. Dans le même temps, je n'ai jamais trouvé de réponses sur certaines des nuances du fonctionnement du système « à l'intérieur » 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 du stand et de conduite. essai.
Pour résumer, je peux dire qu’en général j’ai aimé le produit et l’approche de l’entreprise face à la tâche. Oui, il y a des défauts, il y a un manque de fonctionnalités vraiment critique (en lien avec VMware). Force est de constater que, tout d'abord, l'entreprise se concentre toujours sur les cloud publics, notamment AWS, et pour certains cela suffira. Disposer d'un produit aussi simple et pratique aujourd'hui, alors que de nombreuses entreprises choisissent une stratégie multi-cloud, est extrêmement important. Compte tenu du prix beaucoup plus bas par rapport aux concurrents, cela rend le produit extrêmement attractif.
Nous recherchons un membre de l'équipe . C'est peut-être toi ?
Source: habr.com