Planeamiento de capacidad mediante Azure Site Recovery
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) desde 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 conmuta por error a una ubicación secundaria para acceder a las aplicaciones. Tan pronto como el sitio primario vuelva a ejecutarse, puede conmutar por recuperación 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:
- Marca de Azure Stack Hub donde se ejecutan las máquinas virtuales de inquilino.
-
Entorno de destino :
- Donde se ejecuta azure Site Recovery proveedor de recursos.
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 se ve y más el diseño de la aplicación?
Tamaños de máquina virtual, el número de discos y cómo está asociada cada máquina virtual 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 implicaciones generales 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:
Cuota:
- Debe tener una cuota suficiente para crear el dispositivo de máquina virtual de Azure Site Recovery. Necesita uno o varios, según el 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 producir un error 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 de 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 de destino
En el entorno de destino, hay dos partes que se deben tener en cuenta para el planeamiento de la capacidad:
Los requisitos de servicio de 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 una perspectiva de 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 (RP) de Site Recovery.
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 | vCore | Memoria | Tamaño del disco |
|---|---|---|---|
| Azure Site Recovery | 12 | 42 GB | 1,4 TB |
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 siguiente lista no está completa y debe tratarse como punto de partida:
Tamaño de máquina virtual, número de discos, tamaño del 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 que se van a procesar por lotes 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.
- RPO que se puede lograr para 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 proceso:
- 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. La asignación de cuota suficiente debe estar en vigor 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é usada:
Si hay una conmutación por error, durante las operaciones normales, multiplique el número de discos replicados por el RPO medio. Por ejemplo, puede tener (2 MB * 250s). Normalmente, la cuenta de almacenamiento en caché es de unos 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 medio durante un día completo.
Importante
Si algunas partes de Azure Site Recovery no funcionan, pero otras funcionan, puede haber como máximo un día de diferencia en la cuenta de almacenamiento antes de que Azure Site Recovery decida agotar el tiempo de espera.
Conmutación por recuperació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 vea el uso máximo con la suma de 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 las 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 | Total OPS | Bottleneck |
|---|---|---|---|
| 68 | 136 MB/s | 68 | storage |
| 60 | 120 MB/s | 2048 | storage |
| 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 que admite Azure Site Recovery. Los cambios inferiores a 8 Kb se tratan como 8 Kb.
Para realizar pruebas adicionales, 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 hemos probado 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 que genera a intervalos aleatorios, al menos dos veces por hora, bloques aleatorios que totaliza 5 Gb de datos 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 se 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 cargas de trabajo de aplicaciones y soluciones tienen ciertos 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 sepa de forma nativa que se ejecute o que ciertos componentes puedan ejecutarse en varios 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 servidores 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.
Ajuste del tamaño de los entornos de destino:
- Si usa el origen y el destino de una manera 1:1, asigne un poco más almacenamiento en el 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. Según el tipo de datos y los cambios esperados, y las directivas de replicación que tengan un almacenamiento de 1,5x a 2x más en el destino garantizan que los procesos de conmutación por error no presentan ningún problema.
- 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, está reduciendo 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 bcDR y validar periódicamente. Puede hacerlo mediante procesos de conmutación por error de prueba o moviendo todas las cargas de trabajo para validar los flujos de un extremo a otro.