Dans cet article, nous parlerons brièvement du mécanisme de réplication Hyper-V avec des outils intégrés. Malheureusement, pour une raison quelconque, ce mécanisme est extrêmement rarement utilisé par quelqu'un et à la place voler "achetez" des produits tels que Veeam Backup, mais utilisez-le uniquement pour créer des répliques de VM.
La réplication Hyper-V permet de faire une copie complète d'une VM vers un autre hyperviseur (serveur) et maintient cette copie à jour en permanence. Ainsi, en cas d'effondrement total de l'hyperviseur principal, vous, en tant qu'administrateur de l'environnement de virtualisation, après avoir pris la décision "Le serveur principal ne peut pas être restauré et vous devez exécuter la VM sur l'hyperviseur de secours", dépensez juste quelques minutes pour allumer cette machine virtuelle avec une quantité de données perdues ne dépassant pas 0,5/5/15 minutes (selon le réglage). De plus, si le système d'exploitation invité est également Windows (d'une génération non inférieure à la 9ème version), puis en utilisant le service VSS conjointement avec les composants d'intégration, vous obtiendrez même les bases de données SGBD qui fonctionnaient au moment de la création d'une copie des données pour l'hyperviseur de sauvegarde.
Une fois la réplication configurée, l'hyperviseur principal crée des fichiers de disque virtuel delta et les transfère au serveur de réplique (serveur de sauvegarde), et le serveur de réplique, après l'avoir reçu, le fusionne avec le disque virtuel principal. Selon les paramètres, vous pouvez obtenir aussi répliques cohérentes avec les applications (le même service VSS). De telles copies "cohérentes" garantissent que toutes les données qu'elles contiennent seront cohérentes, et même dans MS SQL, MySQL, PostgreSQL et d'autres SGBD, même ceux qui sont lourdement chargés seront sur le serveur réplica avec leurs bases de données dans un état cohérent, et dans le cas où d'un plantage inattendu du serveur principal, vous aurez la possibilité de prendre le dernier état de la réplique (avec un minimum de données perdues, mais avec le risque que la base de données soit dans un état corrompu), ou revenir à un point antérieur, mais cohérent avec les applications (VSS). Et vous obtiendrez des transactions complètes à 100% dans la base de données.
En fonction de vos paramètres de réplication Hyper-V, vous pouvez configurer la fréquence de transfert du réplica (non cohérente) toutes les 30 secondes, 5 minutes, 15 minutes. Bien que si vous creusez plus profondément dans Windows, vous pouvez définir d'autres options, nous vous déconseillons de le faire. Mais vous ne pouvez obtenir des points de restauration cohérents (VSS) que si vous disposez de votre système d'exploitation invité Windows, qu'il possède et exécute le service VSS et que vous activez dans les paramètres de réplication la fréquence à laquelle vous devez créer un point de restauration "cohérent". Par défaut, Microsoft suggère de le faire une fois toutes les 4 heures et de faire un point incohérent toutes les heures. Tous ces paramètres peuvent également être modifiés dans les entrailles de Windows, mais ici nous vous déconseillons fortement de le faire. Au maximum, vous pouvez modifier la fréquence des copies cohérentes à toutes les 3, 2 ou 1 heure. Mais il ne faut pas oublier que lors de la création d'un point cohérent, toutes les applications du système d'exploitation invité cessent presque complètement de répondre aux appels et ralentissent considérablement.
Exigences pour la teinture:
- Vos hyperviseurs doivent être membres d'un domaine. N'oubliez pas que si vos contrôleurs de domaine sont eux-mêmes des machines virtuelles, vous devez en avoir au moins deux et sur des hyperviseurs différents. Parce qu'au moment du chargement de l'hyperviseur, il ne détectera pas de contrôleur de domaine disponible, et si en raison d'une sorte de défaillance de l'environnement de virtualisation ou de la machine virtuelle elle-même avec DomainController, vous n'aurez pas non plus accès à l'hyperviseur. Sur les hyperviseurs, nous vous recommandons d'installer AD qui n'est en aucun cas lié au domaine principal de l'entreprise. Dans celui-ci, créez des comptes uniquement pour les administrateurs de l'environnement de virtualisation. Allouez le segment de réseau de l'hyperviseur à un VLAN séparé (au moins), mais il est préférable d'allouer des commutateurs séparés pour au moins 10Gbe. Limitez l'accès à ce segment de réseau de manière à ce que les administrateurs de l'environnement de virtualisation ne puissent pas se connecter aux hyperviseurs à partir de n'importe quel point en tant que segment local, sans parler d'Internet.
- Le sous-système disque de votre hyperviseur doit être suffisamment performant, puisque le mécanisme de réplication utilise presque 2 fois plus d'opérations avec le sous-système disque sur l'hyperviseur principal.
- Sur les hyperviseurs, dans les paramètres locaux du pare-feu, vous devez activer l'autorisation de se connecter via TCP/80 et/ou TCP/443 pour la transmission des répliques (Microsoft vous le rappellera lors de la configuration).
Procédure de configuration de la réplication :
Sélectionnez la machine virtuelle dans la liste et sur le côté droit du gestionnaire de contrôle Hyper-V, cliquez sur "Activer la réplication". Sur le premier écran, saisissez nom du serveur du partenaire de réplication (tout doit déjà être configuré sur ce partenaire, y compris open TCP/80 ou TCP/443) et cliquez sur "Suivant":
Sélectionnez le mode de transfert de données avec ou sans cryptage. Nous vous déconseillons fortement d'activer le chiffrement si vos données sont transmises dans un segment privé. Mais si vous devez configurer le chiffrement, vous devez comprendre ce qu'est le chiffrement asymétrique, configurer correctement l'autorité de certification dans le domaine et obtenir les certificats corrects sur les deux serveurs. Vous devez également prendre en compte le facteur de charge CPU excessive sur les deux serveurs.
Ici, vous pouvez configurer les disques virtuels à répliquer. Par exemple, si vous n'avez pas beaucoup d'espace libre sur votre serveur partenaire et que vous ne souhaitez pas, par exemple, répliquer le cache WSUS du service, alors vous pouvez exclure le disque WSUS de la réplication. Veuillez noter que l'ajouter "à la volée" ne fonctionnera plus à l'avenir et vous devrez recréer les paramètres de réplication. Vous pouvez recréer de deux manières :
- Supprimez la machine virtuelle sur le serveur réplica.
- Supprimez les paramètres de réplication, recréez-les et transférez le réplica initial vers la VM précédemment répliquée. Avec une telle restauration, la réplication initiale ne sera pas complètement transférée, mais un disque qui n'a pas été répliqué auparavant arrivera sur le serveur de réplique avec le nom de disque virtuel non pas comme vous l'avez spécifié sur le serveur principal, mais sous la forme d'un long GUID .
Sur cet écran, vous pouvez choisir la fréquence d'envoi d'une réplique au serveur de réplique. Gardez à l'esprit qu'envoyer trop souvent surchargera à la fois le serveur d'envoi et le serveur de réception. L'envoi d'une réplique trop rarement peut entraîner des problèmes de fusion des modifications reçues du côté de la réplique.
Lors de la configuration de points supplémentaires, gardez à l'esprit que le serveur réplica doit disposer d'un espace libre égal au nombre de modifications pour le nombre d'heures sélectionné (premier paramètre). Rappelez-vous également que le service VSS est disponible uniquement sur les systèmes d'exploitation Windows et fonctionne correctement en tandem avec Hyper-V et un système d'exploitation invité Windows de version 9 ou supérieure. Un autre facteur important est une diminution notable des performances du système d'exploitation invité au moment de la création du point VSS. Si le système invité est très chargé et effectue ce point toutes les heures, vous obtiendrez l'effet d'une dégradation des performances toutes les heures.
Si tout est clair avec le transfert de la réplique initiale sur le réseau, alors avec le transfert sur le support et "Utiliser l'existant..." Il y a quelques nuances à connaître.
- Pour transférer la réplique initiale sur le support, vous devez charger ces données sur ce support. Et cela peut être fait en exportant simplement la VM vers le support. Mais il y a une "nuance", qui sera discutée ci-dessous.
- Si vous avez déjà une réplique de votre VM sur un serveur de réplique, vous pouvez démarrer la réplication en utilisant l'option "Utiliser une VM existante..." pour accélérer le processus. Veuillez noter qu'Hyper-V détermine quelle VM est la même sur le réplica, non pas par son nom dans le gestionnaire, mais par GUID (paramètre de VM interne). Par conséquent, peu importe le nom exact de votre machine virtuelle sur le réplica. Si au moment du démarrage d'une telle réplication il n'y avait pas de disques virtuels sur le serveur réplique, alors ils seront chargés sur le serveur réplique, mais le nom de fichier de ce disque virtuel ne contiendra pas le nom comme sur le serveur source, mais le GUID. Ce mécanisme est utile dans les cas où vous avez ajouté un autre disque à la VM d'origine et que vous devez ajouter ce disque à la réplication.
Après avoir mis en place la réplication, le « snapshot » (Point de retour) sera automatiquement supprimé de l'envoi de la réplique initiale sur le serveur principal et la procédure automatique de transfert de toutes les modifications vers le serveur réplique commencera.
Les avantages de cette solution sont évidents, mais je vais tout de même les noter :
- Disponible dans la configuration de base du système d'exploitation Windows Server.
- Extrêmement facile à mettre en place même pour un débutant.
- Garantit l'intégrité des données à l'intérieur de la machine virtuelle pour le système d'exploitation invité Windows.
- En cas de panne du serveur principal ou de la machine virtuelle elle-même, vous aurez besoin de 1 à 5 minutes pour vérifier l'état des points de récupération sur le serveur réplica et effectuer un basculement.
- Il existe des points de retour pendant 24 heures, puis vous pouvez revenir non pas au dernier état (lorsque les données à l'intérieur de la machine virtuelle étaient déjà corrompues), mais choisir l'heure du point de récupération.
- La possibilité de configurer "la réplication étendue sur le 3e serveur, ce qui vous donne l'assurance que dans les circonstances les plus négatives, vous disposez d'une autre copie de l'intégralité de la machine virtuelle.
Mais il y a aussi des aspects négatifs de cette décision :
- En cas de panne du serveur principal, la VM sur le serveur réplica ne s'allumera pas d'elle-même (intervention humaine nécessaire).
- Performances légèrement réduites en raison du coût excessif du sous-système de fichiers pour créer des fichiers de données qui doivent être transférés vers la réplique.
- La réplication peut cesser de fonctionner spontanément.
Si personne n'aura de questions particulières avec le premier point, et qu'il est clair pour tout le monde que si vous avez besoin d'un niveau de tolérance aux pannes encore plus élevé, alors vous devez utiliser le "Failover Cluster" et tout est clair avec le deuxième point, et c'est une caractéristique de la technologie et la diminution des performances n'est pas significative, alors avec le troisième point est le problème. N'engagez pas une personne spéciale qui viendra vérifier toutes les 15 minutes.
Pour ce faire, nous avons développé un capteur pour le système de surveillance PRTG et le publierons bientôt sur notre site Web. GitHub. Pour Zabbix, ce sera également prêt, mais un peu plus tard. Vous pouvez prendre ce capteur et le réécrire vous-même puisqu'il est écrit en PowerShell.