Fiabilidad en Azure Batch
En este artículo se describe la compatibilidad con la fiabilidad en Azure Batch, se aborda la resistencia intrarregional con zonas de disponibilidad y se incluyen vínculos a información sobre la recuperación entre regiones y continuidad empresarial.
Compatibilidad de zonas de disponibilidad
Las zonas de disponibilidad de Azure son al menos tres grupos de centros de datos físicamente independientes dentro de cada región de Azure. Los centros de datos de cada zona están equipados con infraestructura de alimentación, refrigeración y red independientes. En el caso de un error en la zona local, las zonas de disponibilidad están diseñadas de manera que, si se ve afectada una zona, los servicios, la capacidad y la alta disponibilidad regionales serán proporcionadas por las dos zonas restantes.
Estos errores pueden abarcar desde errores de software y hardware hasta eventos como terremotos, inundaciones e incendios. La tolerancia a los errores se logra con la redundancia y el aislamiento lógico de los servicios de Azure. Para más información sobre las zonas de disponibilidad en Azure, consulte Regiones y zonas de disponibilidad.
Los servicios habilitados para zonas de disponibilidad de Azure están diseñados para proporcionar el nivel adecuado de confiabilidad y flexibilidad. Se pueden configurar de dos maneras. Pueden tener redundancia de zona, con una replicación automática entre zonas o ser zonales, con instancias ancladas a una zona específica. También puede combinar ambos enfoques. Para más información sobre la arquitectura zonal frente a la arquitectura con redundancia de zona, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.
Batch mantiene la paridad con Azure con la compatibilidad de las zonas de disponibilidad.
Prerrequisitos
Para las cuentas de Batch del modo de suscripción de usuario, asegúrese de que la suscripción en la que va a crear el grupo no tenga una restricción de oferta de zona en la SKU de máquina virtual solicitada. Para ver si la suscripción no tiene restricciones, llame a la API de enumeración de SKU de recursos y compruebe el campo
ResourceSkuRestrictions. Si existe una restricción de zona, puede enviar una incidencia de soporte técnico para quitar la restricción de zona.Como InfiniBand no admite la comunicación entre zonas, no puede crear un grupo con una directiva de zona si tiene habilitada la comunicación entre nodos y usa una SKU de máquina virtual que admite InfiniBand.
Batch mantiene la paridad con Azure con la compatibilidad de las zonas de disponibilidad. Para usar la opción de zona, el grupo se debe crear en una región de Azure compatible con las zonas de disponibilidad.
Para asignar el grupo de Batch en las zonas de disponibilidad, la región de Azure en la que se creó el grupo debe admitir la SKU de máquina virtual solicitada en más de una zona. Para validar que la región admite la SKU de máquina virtual solicitada en más de una zona, llame a la API de enumeración de SKU de recursos y compruebe el campo
locationInfoderesourceSku. Asegúrese de que se admite más de una zona para la SKU de máquina virtual solicitada. También puede usar la CLI de Azure para enumerar todas las SKU de recursos disponibles con el siguiente comando:az vm list-skus
Creación de un grupo de Azure Batch en zonas de disponibilidad
Para obtener ejemplos sobre cómo crear un grupo de Batch en zonas de disponibilidad, consulte Creación de un grupo de Azure Batch en zonas de disponibilidad.
Obtenga más información acerca de cómo crear cuentas de Batch con Azure Portal, la CLI de Azure, Powershell o Batch Management API.
Experiencia a nivel de zona
Durante la interrupción de una zona, los nodos de esa zona dejan de estar disponibles. Los nodos de ese mismo grupo de nodos de otras zonas no se ven afectados y siguen estando disponibles.
La cuenta de Azure Batch no reasigna ni crea nodos nuevos para compensar los nodos que han quedado fuera de servicio debido a la interrupción. Los usuarios deben agregar más nodos al grupo de nodos, que luego se asignan desde otras zonas en estado correcto.
Tolerancia a errores
Para prepararse para un posible error de zona de disponibilidad, debe sobreaprovisionar la capacidad del servicio para asegurarse de que la solución puede tolerar un tercio de la pérdida de capacidad y seguir funcionando sin degradar el rendimiento durante interrupciones en toda la zona. Como la plataforma distribuye las máquinas virtuales entre tres zonas y debe tener en cuenta al menos el error de una de ellas, multiplique el número máximo de instancias de carga de trabajo por un factor de zonas/(zonas-1) o 3/2. Por ejemplo, si la carga de trabajo máxima típica necesita cuatro instancias, debería aprovisionar seis instancias: (2/3 * 6 instancias) = 4 instancias.
Migración de zonas de disponibilidad
No se puede migrar un grupo de Batch existente a la compatibilidad con la zona de disponibilidad. Si desea recrear el grupo de Batch entre zonas de disponibilidad, consulte Creación de un grupo de Azure Batch entre zonas de disponibilidad.
Recuperación ante desastres entre regiones y continuidad empresarial
Azure Batch está disponible en todas las regiones de Azure. Sin embargo cuando se crea una cuenta de Batch, se debe asociar con una región específica. Todas las operaciones posteriores para dicha cuenta de Batch solo se aplican a esa región. Por ejemplo, se crean los grupos y las máquinas virtuales (VM) asociadas en la misma región que la cuenta de Batch.
Al diseñar una aplicación que usa Batch, debe considerar la posibilidad de que Batch no esté disponible en una región. Es posible que encuentre una situación poco frecuente en la que haya un problema con la región como un todo, con el servicio completo de Batch en la región o con su cuenta de Batch específica.
Si la aplicación o solución que usa Batch siempre debe estar disponible, se debe diseñar para conmutarse por error a otra región o para que la carga de trabajo siempre se divida en dos o más regiones. Ambos enfoques requieren al menos dos cuentas de Batch y que cada cuenta se encuentre en una región distinta.
La responsabilidad de configurar la recuperación ante desastres entre regiones con Azure Batch es suya. Si ejecuta varias cuentas de Batch en regiones específicas y aprovecha las zonas de disponibilidad, la aplicación puede cumplir los objetivos de recuperación ante desastres cuando una de las cuentas de Batch deje de estar disponible.
Al proporcionar la capacidad de conmutación por error a una región alternativa, se deben tener en cuenta todos los componentes de una solución. No basta con tener simplemente una segunda cuenta de Batch. Por ejemplo, en la mayoría de las aplicaciones de Batch, se requiere una cuenta de almacenamiento de Azure. La cuenta de almacenamiento y la cuenta de Batch deben estar en la misma región para lograr un rendimiento aceptable.
Tenga en cuenta lo siguiente a la hora de diseñar una solución con conmutación por error:
Cree previamente todos los servicios necesarios en cada región, como la cuenta de Batch y la de almacenamiento. No se suele aplicar ningún cargo por tener cuentas creadas y los cargos se generan solo cuando se usa la cuenta o se almacenan datos.
Asegúrese con tiempo de que se establecen las cuotas adecuadas para todas las cuentas de Batch de suscripción de usuario para asignar el número necesario de núcleos mediante la cuenta de Batch.
Use scripts o plantillas para automatizar la implementación de la aplicación en una región.
Mantenga actualizados los archivos binarios de aplicación y los datos de referencia en todas las regiones. Mantenerlos actualizados garantizará que la región se pueda conectar rápidamente sin necesidad de esperar a que los archivos se carguen y se implementen. Por ejemplo, considere el caso en el que se almacena una aplicación personalizada para instalar en los nodos del grupo y se hace referencia a ella mediante paquetes de aplicación de Batch. Cuando se publica una actualización de la aplicación, se debe cargar en cada cuenta de Batch y hacer referencia a ella mediante la configuración del grupo (o convertir la versión más reciente en la versión predeterminada).
En la aplicación que realice llamadas a Batch, al almacenamiento y a cualquier otro servicio, cambie los clientes o la carga con facilidad a regiones distintas.
Considere la posibilidad de cambiar con frecuencia a una región alternativa como parte del funcionamiento normal. Por ejemplo, si tiene dos implementaciones en regiones distintas, cambie a la región alternativa cada mes.
La duración del tiempo de recuperación ante un desastre depende de la configuración que elija. Batch es independiente respecto a si usa varias cuentas o una sola cuenta. En las configuraciones de tipo activo-activo, en las que dos instancias de Batch reciben tráfico simultáneamente, la recuperación ante desastres es más rápida que en el caso de una configuración de tipo activo-pasivo. La configuración que elija debe basarse en las necesidades empresariales (regiones diferentes, requisitos de latencia) y las consideraciones técnicas.
Recuperación ante desastres de una sola región
La forma de implementar la recuperación ante desastres en Batch es la misma, tanto si trabaja en una zona geográfica de una sola región o de varias regiones. Las únicas diferencias son las SKU que usa para el almacenamiento y si tiene previsto usar la misma cuenta de almacenamiento o una diferente en todas las regiones.
Pruebas de recuperación ante desastres
Debe realizar sus propias pruebas de recuperación ante desastres de la solución habilitada para Batch. Se considera un procedimiento recomendado para permitir cambiar de forma sencilla entre la carga de cliente y servicio en diferentes regiones.
Probar el plan de recuperación ante desastres para Batch puede ser tan sencillo como alternar cuentas de Batch. Por ejemplo, podría confiar en una sola cuenta de Batch en una región específica durante un día operativo. A continuación, el día siguiente, podría cambiar a una segunda cuenta de Batch en otra región. La recuperación ante desastres se administra principalmente en el lado cliente. Este enfoque de varias cuentas para la recuperación ante desastres se encarga de las expectativas de RTO y RPO en zonas geográficas de una sola región o de varias regiones.
Capacidad y resistencia proactiva de recuperación ante desastres
Microsoft y sus clientes operan bajo el modelo de responsabilidad compartida. Microsoft es responsable de la resistencia de la plataforma y la infraestructura. La responsabilidad de abordar la recuperación ante desastres para cualquier servicio específico que implemente y controle es suya. Para asegurarse de que la recuperación sea proactiva:
Siempre debe implementar previamente recursos secundarios. La implementación previa de recursos secundarios es necesaria porque no hay ninguna garantía de capacidad en el momento del impacto para aquellos que no han asignado previamente dichos recursos.
Cree previamente todos los servicios necesarios en cada región, como las cuentas de Batch y las cuentas de almacenamiento asociadas. No se aplica ningún cargo por crear nuevas cuentas; solo se generan cargos cuando se usa la cuenta o se almacenan datos.
Asegúrese de establecer las cuotas adecuadas en todas las suscripciones de antemano, de forma que pueda asignar el número necesario de núcleos mediante la cuenta de Batch. Al igual que en otros servicios de Azure, existen límites en determinados recursos asociados con el servicio Batch. Muchos de ellos son cuotas predeterminadas que Azure aplica en el nivel de cuenta o suscripción. Tenga en cuenta estas cuotas al diseñar y escalar verticalmente sus cargas de trabajo de Batch.
Nota:
Si planea ejecutar cargas de trabajo de producción en Batch, es posible que tenga que aumentar el valor predeterminado de una o varias de las cuotas. Para generar una cuota, puede solicitar un aumento de la cuota sin cargo alguno. Para obtener más información, consulte Solicitud de un aumento de cuota.
Storage
Debe configurar el almacenamiento de Batch para asegurarse de que se realiza una copia de seguridad de los datos entre regiones; la responsabilidad del cliente es el enfoque predeterminado. La mayoría de las soluciones de Batch usan Azure Storage para almacenar los archivos de recursos y los archivos de salida. Por ejemplo, las tareas de Batch (incluidas las tareas estándar, las de inicio, las de preparación de trabajos y las de liberación de trabajos) especifican normalmente archivos de recursos que residen en cuentas de almacenamiento. Las cuentas de almacenamiento también almacenan los datos que se procesan y los datos de salida que se generan. Comprender la posible pérdida de datos en las regiones de las operaciones de servicio es una consideración importante. También debe confirmar si los datos se pueden reescribir o si son de solo lectura.
Batch admite los siguientes tipos de cuentas de almacenamiento de Azure:
- Cuentas de uso general v2 (GPv2)
- Cuentas de uso general v1 (GPv1)
- Cuentas de Blob Storage (actualmente admitidas para grupos en la configuración de máquina virtual)
Para más información sobre las cuentas de almacenamiento, vea Introducción a las cuentas de Azure Storage.
Puede asociar una cuenta de almacenamiento con su cuenta de Batch cuando crea la cuenta o llevar a cabo este paso en otro momento.
Si va a configurar una cuenta de almacenamiento independiente para cada región en la que está disponible el servicio, debe usar cuentas de almacenamiento con redundancia de zona (ZRS). Use cuentas de almacenamiento con redundancia de zona geográfica (GZRS) si va a usar la misma cuenta de almacenamiento en varias regiones emparejadas. En el caso de las zonas geográficas que contienen una sola región, debe crear una cuenta de almacenamiento con redundancia de zona (ZRS), ya que el almacenamiento con redundancia de zona geográfica no está disponible.
El planeamiento de capacidad es otra consideración importante respecto al almacenamiento y debe abordarse de forma proactiva. Al elegir una cuenta de almacenamiento, tenga en cuenta los requisitos de costo y rendimiento. Por ejemplo, las opciones de cuenta GPv2 y de Blob Storage admiten mayores límites de capacidad y escalabilidad si se compara con GPv1. (Póngase en contacto con el servicio de soporte técnico de Azure para solicitar un aumento en el límite de almacenamiento). Estas opciones de cuenta pueden mejorar el rendimiento de las soluciones de Batch que contienen un gran número de tareas en paralelo que se leen o escriben en la cuenta de almacenamiento.
Cuando una cuenta de almacenamiento está vinculada a una cuenta de Batch, imagínese que se trata de la cuenta de almacenamiento automático. Se requiere una cuenta de almacenamiento automático si tiene previsto usar la funcionalidad de paquetes de aplicación, ya que se usa para almacenar los archivos ZIP de los paquetes de aplicación. También se puede usar una cuenta de almacenamiento automático para los archivos de recursos de tarea; dado que la cuenta de almacenamiento automático ya está vinculada a la cuenta de Batch, esto evita la necesidad de que las direcciones URL de firma de acceso compartido (SAS) accedan a los archivos de recursos.