Configurar movilidad de cargas de trabajo en VMware Aria Automation
VMware Aria Automation
Si utiliza Site Recovery Manager como solución de continuidad empresarial y recuperación ante desastres para los recursos de
vSphere
, puede configurar VMware Aria Automation
para seguir administrando los recursos, incluso si SRM los mueve a una ubicación secundaria. Actualmente, la movilidad de cargas de trabajo es compatible con los recursos implementados en
vSphere
. Los recursos de cargas de trabajo incluyen máquinas virtuales, discos y red de máquinas virtuales. Debido a las limitaciones de Site Recovery Manager, no se incluyen discos de primera clase.La movilidad de cargas de trabajo solo funciona con SRM. Si reubica cargas de trabajo mediante una herramienta que no es de SRM,
VMware Aria Automation
pierde la capacidad de administrar los recursos independientemente de la asociación del sitio de cuenta y la configuración de movilidad de cargas de trabajo del proyecto. Después de que los recursos conmutan por error del sitio principal al sitio secundario, la información sobre los recursos del sitio secundario se concilia durante la recopilación de datos. El proceso de reconciliación completo puede tardar varios ciclos de recopilación en completarse.
Antes de comenzar
- Asegúrese de que el sitio principal y el secundario pertenezcan al mismo proyecto.
- Para comprender cómo puede administrar los recursos después de una conmutación por error, revise las siguientes consideraciones.ConsideracionesSolucionesDespués de que los recursos conmutan por error del sitio principal al sitio secundario, la información sobre los recursos del sitio secundario se concilia durante la recopilación de datos. El proceso de reconciliación completo puede tardar varios ciclos de recopilación en completarse.Si encuentra errores, puede revisar los registros de SRM para identificar el problema.Los recursos de almacenamiento no pertenecen a una zona de nube después de la conciliación en el nuevo sitio. Después de la conmutación por error, es posible que las cuotas de almacenamiento no sean precisas y que se produzca un error en la asignación de discos nuevos, según la nueva topología devCenter.NingunaEs posible que algunas acciones no funcionen en el sitio secundario si las directivas son diferentes del sitio principal.Por ejemplo, es posible que algunas etiquetas no existan en el nuevo almacén de datos devCentery que no se concilien cuando se mueven los recursos. Si los recursos permanecen en el almacén de datos del sitio secundario, debe actualizar las etiquetas en el nuevovCenterpara garantizar el cumplimiento continuo de las directivas.Una solución alternativa consiste en reflejar los sitios, incluidas las directivas y las etiquetas.Se admiten la mayoría de las acciones del día 2 relacionadas con máquinas, discos y redes de máquinas virtuales.Las siguientes acciones del día 2 no se admiten en el sitio secundario.
- Cambiar las redes cuando se utiliza la acción Actualizar implementación.
Cualquier acción que consuma más recursos, como agregar o cambiar el tamaño de discos, está limitada por los recursos disponibles.No se admiten discos de primera clase debido a limitaciones de Site Recovery Manager.NingunaSi no vuelve a proteger los recursos en el sitio secundario antes de modificar un recurso como parte del desarrollo iterativo o la administración general de recursos, SRM genera un error y el recurso no se mueve cuando realiza conmutación por recuperación al sitio principal.Después de la conmutación por error, vuelva a proteger los recursos en el sitio secundario para asegurarse de que SRM esté al tanto de los cambios. Volver a proteger garantiza que los recursos puedan realizar una conmutación por recuperación al sitio principal con una interrupción mínima.Una solución alternativa es utilizar un complemento deAutomation Orchestratorque agregue máquinas aprovisionadas recientemente en grupos de protección de Site Recovery Manager. La guía del complemento está disponible en la página de documentación de SRM.Si el desarrollo iterativo continúa en el sitio secundario, los recursos destruidos no se pueden recuperar.Si el traslado al sitio secundario es temporal, considere la posibilidad de detener las acciones destructivas hasta que realice conmutación por recuperación al sitio principal.
Configurar VMware Site Recovery Manager
Asegúrese de que los recursos que administra
VMware Aria Automation
estén configurados para admitir la movilidad de cargas de trabajo. Consulte la documentación de Site Recovery Manager para obtener más información. - Identifique las instancias principal y secundaria devCenter.
- Cree un grupo de protección para los recursos.
- Cree un plan de recuperación para los recursos.
Asocie las cuentas principal y secundaria en VMware Aria Automation
VMware Aria Automation
VMware Aria Automation
deben conocer las cuentas de nube alternativas que utiliza SRM para el grupo de protección y el plan de recuperación.Las cuentas alternativas deben pertenecer al mismo proyecto que la cuenta principal.
- EnAutomation Assembler, seleccione y asegúrese de que las cuentas de nube principal y secundaria estén configuradas.
- Abra la cuenta principal y localice la secciónAsociación de sitio.
- Haga clic enAgregary seleccione la cuenta de nube secundaria.
- Para admitir la migración de nuevo al sitio principal, active el botón de alternanciaBidireccional.
- Haga clic enGuardar.