Confiabilidad en Azure HDInsight en Azure Kubernetes Service
Nota:
Retiraremos Azure HDInsight en AKS el 31 de enero de 2025. Antes del 31 de enero de 2025, deberá migrar las cargas de trabajo a Microsoft Fabric o un producto equivalente de Azure para evitar la terminación repentina de las cargas de trabajo. Los clústeres restantes de la suscripción se detendrán y quitarán del host.
Solo el soporte técnico básico estará disponible hasta la fecha de retirada.
Importante
Esta funcionalidad actualmente está en su versión preliminar. En Términos de uso complementarios para las versiones preliminares de Microsoft Azure encontrará más términos legales que se aplican a las características de Azure que están en versión beta, en versión preliminar, o que todavía no se han lanzado con disponibilidad general. Para más información sobre esta versión preliminar específica, consulte la Información de Azure HDInsight sobre la versión preliminar de AKS. Para plantear preguntas o sugerencias sobre la característica, envíe una solicitud en AskHDInsight con los detalles y síganos para obtener más actualizaciones sobre Comunidad de Azure HDInsight.
En este artículo, se describe la compatibilidad con la confiabilidad en Azure HDInsight en Azure Kubernetes Service (AKS) y la recuperación ante desastres y continuidad empresarial.
Compatibilidad de zonas de disponibilidad
Las zonas de disponibilidad son grupos físicamente separados de centros de datos dentro de cada región de Azure. Cuando se produce un error en una zona, los servicios pueden conmutar por error a una de las zonas restantes.
Para más información sobre las zonas de disponibilidad en Azure, consulte ¿Qué son las zonas de disponibilidad?.
Azure HDInsight en AKS admite zonas de disponibilidad aprovechando la capacidad de Azure Kubernetes Service para crear grupos de nodos con redundancia de zona. Puede seleccionar en qué zonas de disponibilidad se implementarán el grupo de clústeres y el clúster durante su creación. Una vez creado el grupo de clústeres o el clúster, no puede cambiar las zonas de disponibilidad.
Requisitos previos
Las zonas de disponibilidad solo se admiten para la versión del grupo de clústeres >=
1.2y la versión del clúster >=1.2.1.Azure HDInsight en AKS solo tiene una SKU predeterminada y admite zonas de disponibilidad siempre que la región de Azure tenga compatibilidad con zonas de disponibilidad.
Las regiones siguientes no admiten zonas de disponibilidad:
América Europa Oriente Medio África Asia Pacífico Oeste de EE. UU. Norte de Alemania Es posible que algunas SKU de máquina virtual no admitan todas las zonas de disponibilidad de una región. Si selecciona esas SKU, HDInsight en grupos de clústeres o clústeres de AKS tampoco admite las zonas de disponibilidad correspondientes.
Mejoras de SLA
No hay un Acuerdo de Nivel de Servicio mayor para Azure HDInsight en clústeres de AKS con las zonas de disponibilidad habilitadas.
Creación de un recurso con la zona de disponibilidad habilitada
Grupos de clústeres: puede seleccionar una o varias zonas de disponibilidad durante la creación del grupo de clústeres después de seleccionar la región.
Clústeres: puede seleccionar una o varias zonas de disponibilidad durante la creación del clúster.
Tolerancia a errores
Para prepararse para los errores de la zona de disponibilidad, se recomienda aprovisionar en exceso la capacidad de servicio para asegurarse de que el clúster pueda tolerar la pérdida de capacidad de una zona de disponibilidad y seguir funcionando sin degradar el rendimiento durante las interrupciones de toda la zona. Por ejemplo, si habilita 3 zonas de disponibilidad, el clúster debe tolerar 1/3 de los nodos inactivos (redondear hasta el entero más cercano).
Experiencia a nivel de zona
Azure HDInsight en el servicio AKS tiene redundancia de zona. Durante una interrupción en toda la zona, el cliente debe esperar una degradación del rendimiento debido a la caída de la capacidad. Los clientes todavía pueden crear nuevos grupos de clústeres y clústeres en las zonas de disponibilidad que no se ven afectadas. Los clústeres existentes pueden funcionar con una capacidad reducida. En la documentación, se proporcionan recomendaciones y procedimientos recomendados para cargas de trabajo de código abierto individuales.
Recuperación ante desastres y continuidad empresarial
La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.
En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.
El servicio del plano de control y las bases de datos de Azure HDInsight en AKS se implementan en regiones de Azure. Entre estas regiones, las instancias de Azure HDInsight en AKS y las instancias de base de datos están aisladas. Cuando se produce una interrupción en el nivel de región, una región está inactiva. Todos los recursos de esta región, incluido el RP (proveedor de recursos) del plano de control de Azure HDInsight en AKS, la base de datos del plano de control de Azure HDInsight en AKS y todos los clústeres de clientes de esta región. En este caso, solo podemos esperar a que finalice la interrupción regional. Cuando se recupera completamente la interrupción zonal, el servicio Azure HDInsight en AKS vuelve a estar activo y todos los clústeres de clientes vuelven a la normalidad. Es posible que encuentre algunos problemas debido a la incoherencia de los datos después de la interrupción y puede necesitar una corrección manual en función de las cargas de trabajo de aplicación.
Recuperación ante desastres entre regiones
Azure HDInsight en AKS actualmente no admite la conmutación por error entre regiones. La mejora de la continuidad empresarial mediante la recuperación ante desastres de alta disponibilidad entre regiones requiere diseños arquitectónicos de mayor complejidad y un costo más alto. Los clientes pueden optar por diseñar su propia solución para realizar copias de seguridad de datos clave y estado del trabajo en diferentes regiones.
Detección, notificación y administración de interrupciones
Use las herramientas de supervisión de Azure en HDInsight en AKS para detectar comportamientos anómalos en el clúster y establecer las notificaciones de alerta correspondientes. Puede habilitar Log Analytics de varias maneras y usar el servicio Prometheus administrado con paneles de Azure Grafana para la supervisión. Para obtener más información, vea Integración de Azure Monitor.
Suscríbase a las alertas de estado de Azure para recibir notificaciones sobre problemas de servicio, mantenimiento planeado, avisos de estado y seguridad para una suscripción, un servicio o una región. Las notificaciones de estado que incluyen la causa del problema y la hora de llegada estimada resuelta le ayudan a ejecutar mejor la conmutación por error y la conmutación por recuperación. Para más información, consulte Administración del estado del servicio y Documentación de Azure Service Health.
Recuperación ante desastres de una sola región
Actualmente, Azure HDInsight en AKS solo tiene una oferta de servicio estándar y los clústeres se crean en una única región geográfica. Los clientes son responsables de la configuración de la recuperación ante desastres en función de los requisitos de la aplicación.
Capacidad y resistencia proactiva de la recuperación ante desastres
Azure HDInsight en AKS y sus clientes operan con el modelo de responsabilidad compartida, lo que significa que el cliente debe abordar los requisitos de recuperación ante desastres para el servicio que implementan y controlan. Para asegurarse de que la recuperación sea proactiva, los clientes siempre tienen que implementar previamente regiones secundarias, ya que no hay ninguna garantía de que haya capacidad en el momento del impacto para aquellos que no han asignado previamente.
A diferencia de HDInsight, las máquinas virtuales que se usan en clústeres de HDInsight en AKS requieren la misma cuota que las máquinas virtuales de Azure. Para más información, consulte Planeamiento de capacidad.
Contenido relacionado
Para más información sobre los elementos que se describen en este artículo, consulte: