Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Como organización, es imperativo adoptar una estrategia de continuidad empresarial y recuperación ante desastres (BCDR) que mantenga los datos seguros, las aplicaciones disponibles y las cargas de trabajo en línea durante interrupciones planeadas y no planeadas.
A través de la replicación de cargas de trabajo de máquinas virtuales (VM) de un sitio primario a una ubicación secundaria, Azure Site Recovery en Azure Stack Hub proporciona servicios que pueden admitir la seguridad de los datos de la organización, la disponibilidad de las aplicaciones y las cargas de trabajo durante las interrupciones. Por ejemplo, cuando se produce una interrupción en el sitio primario, se cambia a una ubicación secundaria para acceder a tus aplicaciones. Tan pronto como el sitio primario vuelva a estar operativo, puede volver a cambiar a él. Para obtener más información, consulte Acerca de Site Recovery.
Para habilitar la replicación de máquinas virtuales en dos stamps de Azure Stack Hub, configure dos entornos:
-
Entorno de origen:
- La instancia de Azure Stack Hub donde se ejecutan las máquinas virtuales de cliente.
-
Entorno de destino :
- Donde se ejecuta el proveedor de recursos de Azure Site Recovery.
Un componente esencial para el éxito de un plan de continuidad empresarial y recuperación ante desastres es el planeamiento de la capacidad. Durante el planeamiento de la capacidad, hay algunos factores que se deben tener en cuenta:
Objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO) para las cargas de trabajo específicas que desea proteger.
Cargas de trabajo y las características de la aplicación:
- Frecuencia con la que cambian los datos dentro de la máquina virtual correspondiente.
- ¿Cuántos datos se generan o quitan?
- ¿Cómo es el diseño de la aplicación y qué más ofrece?
Tamaños de máquina virtual, el número de discos y cómo cada máquina virtual está vinculada a otras máquinas virtuales.
- En el caso de las soluciones que requieren varias máquinas virtuales, comprenda en qué orden deben iniciarse esas máquinas virtuales.
Ancho de banda de red entre los entornos de origen y destino. Este componente puede afectar a los RPO.
Cada uno de estos puntos es importante y tiene amplias implicaciones al crear un plan BCDR.
En las secciones siguientes se enumeran los puntos principales que se deben tener en cuenta desde una perspectiva de Azure Site Recovery. Cada plan de BCDR es diferente y se basa en los detalles de las cargas de trabajo que planea proteger. Por lo tanto, esta lista no es completa.
Consideraciones sobre el origen
En el entorno de origen, Azure Stack Hub ejecuta el dispositivo de máquina virtual de Azure Site Recovery. La máquina virtual es una máquina virtual de Standard_DS4_v2 (8 vCPU, memoria de 28 Gb, 32 discos de datos) que se ejecuta en la suscripción de usuario de Azure Stack Hub.
En el entorno de origen, tenga en cuenta las siguientes áreas:
Quota:
- Debe tener cuota suficiente para crear el dispositivo de máquina virtual de Azure Site Recovery. Necesita uno o varios, en función del plan general.
Almacenamiento para el dispositivo de máquina virtual de Azure Site Recovery:
El propio dispositivo de máquina virtual de Azure Site Recovery tiene los requisitos de datos definidos por su tamaño de máquina virtual.
Al planear la capacidad, asegúrese de que la máquina virtual del dispositivo tiene suficiente almacenamiento para ejercer los mecanismos de conmutación por recuperación y volver a proteger.
Nota:
Si hay limitaciones de almacenamiento, la conmutación por recuperación y la re-protección pueden fallar con un error Se produjo un error interno. Los usuarios deben comprobar los registros de eventos en el dispositivo para confirmar el error real de Azure Resource Manager. Para más información, consulte Problemas conocidos de Azure Site Recovery.
Ancho de banda:
- La replicación inicial genera un uso elevado del ancho de banda.
- Los cambios en cada máquina virtual se replican, en función de las directivas de replicación y de cada tipo de aplicación.
Consideraciones sobre el objetivo
En el entorno de destino, hay dos partes que se deben tener en cuenta para el planeamiento de la capacidad:
Requisitos del servicio Azure Site Recovery: cuánto se consume para ejecutar Azure Site Recovery, sin proteger necesariamente las cargas de trabajo.
Requisitos de cargas de trabajo protegidas.
El entorno de destino requiere que se cree un almacén de Azure Site Recovery para cada dispositivo de Site Recovery para proteger las máquinas virtuales del origen (un dispositivo por almacén). Aunque esto no es una limitación desde la perspectiva de la capacidad, se debe tener en cuenta al planear el diseño del entorno general.
Recursos de RP de Azure Site Recovery
La instalación de Azure Site Recovery en Azure Stack Hub requiere que instale el proveedor de recursos de Site Recovery (RP).
Nota:
Con Microsoft.SiteRecovery-1.2301.2216.2287, Azure Site Recovery en Azure Stack Hub no requiere Event Hubs como dependencia.
Este servicio se crea en la suscripción de administrador de Azure Stack Hub y se administra mediante azure Stack Hub, por lo que no se requiere ninguna configuración. Sin embargo, al igual que con cualquier servicio, estos recursos consumen memoria, almacenamiento y tienen determinadas vCPU asignadas:
| Servicio | Núcleo virtual | Memoria | Tamaño del disco |
|---|---|---|---|
| Recuperación del Sitio de Azure | 18 | 64 GB | 384 GB |
Nota:
Estos recursos son servicios de Azure Stack Hub en el lado de administración de Azure Stack Hub. Una vez instalado, la plataforma administra estos recursos.
Cargas de trabajo protegidas
Al crear el plan BCDR, tenga en cuenta todos los aspectos de las cargas de trabajo protegidas. La lista siguiente no está completa y debe tratarse como punto de partida:
Tamaño de máquina virtual, número de discos, tamaño de disco, IOPS, renovación de datos y nuevos datos creados.
Consideraciones sobre el ancho de banda de red:
- Ancho de banda de red necesario para la replicación diferencial.
- Cantidad de rendimiento, en el entorno de destino, que Azure Site Recovery puede obtener del entorno de origen.
- Número de máquinas virtuales a agrupar en un lote a la vez. Este número se basa en el ancho de banda estimado para completar la replicación inicial en un período de tiempo determinado.
- El RPO que se puede lograr con un ancho de banda determinado.
- Efecto en el RPO deseado si se aprovisiona un ancho de banda inferior.
Consideraciones sobre el almacenamiento:
- Cantidad de datos necesarios para la replicación inicial.
- Cuántos puntos de recuperación se mantienen y cómo aumentan los datos, para cada máquina virtual protegida, durante estos intervalos.
- Cuántas cuotas se deben asignar a las suscripciones de usuario de Azure Stack Hub de destino, de modo que los usuarios tengan suficiente asignación.
- La cuenta de almacenamiento en caché para la replicación.
Consideraciones de cómputo:
- Cuando se produce la conmutación por error, las máquinas virtuales se inician en las suscripciones de usuario de Azure Stack Hub de destino. Debe haber suficiente asignación de cuota para poder iniciar estos recursos de máquina virtual.
- Durante la protección de la máquina virtual, cuando la máquina virtual protegida está activa en el entorno de origen, no se consumen recursos relacionados con la máquina virtual, como vCPU, memoria, etc. en el entorno de destino. Estos recursos solo son relevantes durante un proceso de conmutación por error, como la conmutación por error de prueba.
Para el ámbito de Azure Site Recovery en Azure Stack Hub, este es un punto de partida para los cálculos, especialmente para la cuenta de almacenamiento en caché que se usa:
Si hay una conmutación por error, durante las operaciones normales, multiplique el número de discos replicados por el RPO promedio. Por ejemplo, puede tener (2 MB * 250 s). La cuenta de almacenamiento en caché suele tener unos pocos KB a 500 MB por disco.
Si hay una conmutación por error, dado un peor escenario, multiplique el número de discos replicados por el RPO promedio durante un día completo.
Importante
Si algunas partes de Azure Site Recovery no funcionan, pero otras sí, puede haber como máximo un día de registros de cambios en la cuenta de almacenamiento antes de que Azure Site Recovery decida expirar el tiempo de espera.
Reversión a la nueva máquina virtual. Calcule la suma del tamaño de los discos de cada lote.
- Todo el disco debe copiarse en la cuenta de almacenamiento en caché para que se aplique la máquina virtual de destino, ya que el destino es un disco vacío.
- Los datos asociados se eliminan una vez copiados, pero es probable que se alcance el uso máximo sumando todos los tamaños de disco.
Cree el plan BDCR en función de los detalles de la solución que está intentando proteger.
En la tabla siguiente se muestra un ejemplo de pruebas que se ejecutan en nuestros entornos. Puede usar esta información para obtener una línea base para su propia aplicación, pero cada carga de trabajo difiere:
Configuración
| Tamaño de bloque | Rendimiento/disco |
|---|---|
| 2 MB | 2 MB/s |
| 64 KB | 2 MB/s |
| 8 KB | 1 MB/s |
| 8 KB | 2 MB/s |
Resultado
| Número de discos admitidos | Rendimiento total | OPS total | Bottleneck |
|---|---|---|---|
| 68 | 136 MB/s | 68 | almacenamiento |
| 60 | 120 MB/s | 2048 | almacenamiento |
| 28 | 28 MB/s | 3584 | CPU y memoria de Azure Site Recovery |
| 16 | 32 MB/s | 4096 |
Nota:
8 Kb es el tamaño de bloque más pequeño de los datos compatibles con Azure Site Recovery. Los cambios inferiores a 8 Kb se tratan como 8 Kb.
Para probar más, hemos generado un tipo coherente de carga de trabajo; por ejemplo, los cambios de almacenamiento coherentes en bloques de 8 Kb que su total son de hasta 1 MB/s por disco. Este escenario no es probable en una carga de trabajo real, dado que los cambios pueden producirse en varias horas del día o en picos de varios tamaños.
Para replicar estos patrones aleatorios, también probamos escenarios con:
- 120 máquinas virtuales (80 Windows, 40 Linux) protegidas a través del mismo dispositivo de máquina virtual de Azure Site Recovery.
Cada máquina virtual genera, a intervalos aleatorios, al menos dos veces por hora, bloques aleatorios que totalizan 5 GB de datos distribuidos en cinco archivos.
La replicación se realizó correctamente en todas las 120 máquinas virtuales con una carga baja a media en los servicios de Azure Site Recovery.
Nota:
Estos números solo se deben usar como línea base. No escalan necesariamente linealmente. Agregar otro lote del mismo número de máquinas virtuales podría tener menos impacto que el inicial. Los resultados dependen en gran medida del tipo de cargas de trabajo usadas.
¿Cómo debe planear y probar?
Las aplicaciones y las cargas de trabajo de solución tienen determinados requisitos de objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO). El diseño eficaz de continuidad empresarial y recuperación ante desastres (BCDR) aprovecha las funcionalidades de nivel de plataforma que cumplen estos requisitos, ya que usamos los mecanismos específicos de la solución. Para diseñar funcionalidades de BCDR, capture los requisitos de recuperación ante desastres de la plataforma (DR) y tenga en cuenta todos estos factores en el diseño:
Requisitos de disponibilidad de datos y aplicaciones:
- Requisitos de RTO y RPO para cada carga de trabajo.
- Compatibilidad con patrones de disponibilidad activo-activo y activo-pasivo.
Compatibilidad con implementaciones de varias regiones para la conmutación por error, con proximidad de componentes para el rendimiento. Es posible que experimente operaciones de aplicación con una funcionalidad reducida o un rendimiento degradado durante una interrupción.
Nota:
Es posible que la aplicación tenga la capacidad nativa de ejecutarse o que incluya determinados componentes compatibles con múltiples entornos de Azure Stack Hub. En ese caso, puede usar Azure Site Recovery para replicar solo las máquinas virtuales con los componentes que no tienen esta funcionalidad; por ejemplo, una solución de tipo front-end o back-end, en la que puede implementar los front-end en entornos de Azure Stack Hub.
Evite el uso de intervalos de direcciones IP superpuestos en redes de producción y de recuperación ante desastres.
- Las redes de producción y de recuperación ante desastres que tienen direcciones IP superpuestas requieren un proceso de conmutación por error que puede complicar y retrasar la conmutación por error de la aplicación. Cuando sea posible, planee una arquitectura de red de BCDR que proporcione una conectividad simultánea a todos los sitios.
Dimensionamiento de los entornos objetivo:
- Si usa el origen y el destino de manera 1:1, asigne un poco más de almacenamiento en su entorno de destino. Esto se debe a la forma en que se produce el historial de los marcadores de disco. Esta asignación no es un aumento de 2 veces, ya que solo incluye cambios en los datos. Dependiendo del tipo de datos y los cambios esperados, así como de las políticas de replicación, contar con un almacenamiento entre 1,5x y 2x más en el destino asegura que los procesos de conmutación por error no presenten inconvenientes.
- Es posible que considere la posibilidad de tener el entorno de Azure Stack Hub de destino como destino para varios orígenes de Azure Stack Hub. En este caso, va a reducir el costo general, pero debe planear lo que sucede cuando determinadas cargas de trabajo bajen; por ejemplo, qué origen se debe priorizar.
- Si el entorno de destino se usa para ejecutar otras cargas de trabajo, el plan BCDR debe incluir el comportamiento de estas cargas de trabajo. Por ejemplo, puede ejecutar las máquinas virtuales de desarrollo y pruebas en el entorno de destino y, si se produce un problema con el entorno de origen, puede desactivar todas las máquinas virtuales del destino para asegurarse de que hay suficientes recursos disponibles para iniciar las máquinas virtuales protegidas.
Debe probar el BCDR y validarlo periódicamente. Puede hacerlo mediante procesos de conmutación por error de prueba o trasladando las cargas de trabajo completas para validar los flujos de extremo a extremo.