Si vous utilisez Site Recovery Manager comme solution de continuité d'activité et de récupération d'urgence pour vos ressources vSphere, vous pouvez configurer VMware Aria Automation pour continuer à gérer les ressources, même si elles sont déplacées par SRM vers un emplacement secondaire.
La mobilité des charges de travail est actuellement prise en charge pour les ressources déployées sur vSphere. Les ressources de charge de travail incluent les machines virtuelles, les disques et le réseau de machine virtuelle. En raison de limitations de Site Recovery Manager, les disques de première classe ne sont pas inclus.
La mobilité des charges de travail fonctionne uniquement avec SRM. Si vous déplacez des charges de travail à l'aide d'un outil non-SRM, VMware Aria Automation perd la capacité de gérer les ressources, quels que soient les paramètres d'association de sites du compte et les paramètres de mobilité des charges de travail du projet.
Après le basculement des ressources du site principal vers le site secondaire, les informations sur les ressources sur le site secondaire sont rapprochées lors de la collecte de données. Le processus de rapprochement complet peut prendre plusieurs cycles de collecte pour se terminer. Si des erreurs sont générées.
Avant de commencer
- Assurez-vous que les sites principal et secondaire appartiennent au même projet.
- Pour comprendre comment gérer les ressources après un basculement, vérifiez les considérations suivantes.
Considérations Solutions Après le basculement des ressources du site principal vers le site secondaire, les informations sur les ressources sur le site secondaire sont rapprochées lors de la collecte de données. Le processus de rapprochement complet peut prendre plusieurs cycles de collecte pour se terminer. Si vous rencontrez des erreurs, vous pouvez consulter les journaux SRM pour identifier le problème. Les ressources de stockage n’appartiennent pas à une zone de cloud après le rapprochement sur le nouveau site. Après le basculement, les quotas de stockage peuvent être inexacts et l'allocation de nouveaux disques peut échouer, selon la nouvelle topologie de vCenter. Aucune Certaines actions peuvent ne pas fonctionner sur le site secondaire si les stratégies sont différentes du site principal. Par exemple, certaines balises peuvent ne pas exister sur la nouvelle banque de données vCenter et ne sont pas rapprochées lorsque les ressources sont déplacées. Si les ressources sont conservées sur la banque de données sur le site secondaire, vous devez mettre à jour les balises sur la nouvelle instance de vCenter pour garantir la conformité continue avec vos stratégies.
Une autre solution consiste à mettre en miroir les sites, y compris les stratégies et les balises.
La plupart des actions de jour 2 liées aux machines, aux disques et aux réseaux de machine virtuelle sont prises en charge.
Les actions de jour 2 suivantes ne sont pas prises en charge sur le site secondaire.
- Modification des réseaux lorsque vous utilisez l'action Mettre à jour le déploiement.
Toute action qui consomme plus de ressources (telle que l'ajout ou le redimensionnement de disques) est limitée par les ressources disponibles.
Les disques de première classe ne sont pas pris en charge en raison de limitations de Site Recovery Manager. Aucune Si vous ne reprotégez pas les ressources sur le site secondaire avant de modifier une ressource dans le cadre du développement itératif ou de la gestion générale des ressources, SRM génère une erreur et la ressource n'est pas déplacée lorsque vous revenez vers le site principal. Après le basculement, reprotégez les ressources sur le site secondaire pour vous assurer que SRM est informé des modifications. La reprotection garantit que vos ressources peuvent revenir vers le site principal avec une interruption minimale.
Une autre solution consiste à utiliser un plug-in VMware Aria Automation Orchestrator qui ajoute les machines récemment provisionnées dans les groupes de protection Site Recovery Manager. Le guide du plug-in est disponible sur la page de la documentation SRM.
Si le développement itératif se poursuit sur le site secondaire, les ressources détruites ne sont pas récupérables. Si le déplacement vers le site secondaire est temporaire, envisagez l'arrêt de toutes les actions destructrices jusqu'à ce que vous reveniez vers le site principal.
Configurer VMware Site Recovery Manager
Assurez-vous que les ressources gérées par VMware Aria Automation sont configurées pour prendre en charge la mobilité des charges de travail. Pour plus d'informations, reportez-vous à la documentation de Site Recovery Manager.
- Identifiez vos instances principale et secondaire de vCenter.
- Créez un groupe de protection pour les ressources.
- Créez un plan de récupération pour les ressources.
Associez les comptes principal et secondaire dans VMware Aria Automation.
VMware Aria Automation doit être informé des autres comptes de cloud utilisés par SRM pour le groupe de protection et le plan de récupération.
Les autres comptes doivent appartenir au même projet que le compte principal.
- Dans Automation Assembler, sélectionnez et assurez-vous que les comptes de cloud principal et secondaire sont configurés.
- Ouvrez le compte principal et localisez la section Association de sites.
- Cliquez sur Ajouter et sélectionnez le compte de cloud secondaire.
- Pour prendre en charge la migration de nouveau vers le site principal, activez l'option Bidirectionnel.
- Cliquez sur Enregistrer.
