Confiabilidad en Azure Operator Nexus
Importante
Esta funcionalidad actualmente está en su versión preliminar. Las versiones preliminares están a su disposición con la condición de que acepte los términos de uso adicionales.
Este artículo describe el soporte de confiabilidad en Azure Operator Nexus y cubre la resistencia intrarregional con zonas de disponibilidad. Para obtener información general más detallada sobre la confiabilidad de Azure, consulte Confiabilidad de Azure.
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 obtener 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.
Azure Operator Nexus ofrece implementaciones con redundancia de zona de disponibilidad de forma predeterminada. Los componentes de Operator Nexus, como Cluster Manager y Network Fabric Controller, se implementan en un clúster de Azure Kubernetes Service (AKS) habilitado con zonas de disponibilidad. Otras dependencias de servicio, como el servicio de cuenta de almacenamiento y KeyVault, también se configuran con redundancia de zona de disponibilidad.
Nota:
La instancia de Operator Nexus On-Premises implementa un diseño de varios bastidores que proporciona redundancia física en todos los niveles de la pila. Cada bastidor está diseñado como un dominio de error o zona Nexus. Las cargas de trabajo del cliente se pueden implementar en varios bastidores o nodos, lo que básicamente proporciona una experiencia de zona de varias disponibilidad similar.
Experiencia de baja de zona de disponibilidad de Azure
En un escenario de reducción de zona de disponibilidad, las llamadas API en el clúster y los proveedores de recursos seguirán funcionando sin interrupción. No habría ningún impacto en las cargas de trabajo de inquilino locales que se están ejecutando actualmente o en la capacidad de crear nuevas cargas de trabajo de inquilino. Además, no se debe producir ninguna pérdida de datos, ya que se garantiza la resistencia de Operator Nexus y otros tipos de recursos.
Compatibilidad con la conmutación por error de zona de disponibilidad de Azure
En el caso de un error de zona de disponibilidad, la reconexión a otra zona de disponibilidad de Azure es automática y no requiere ninguna interacción del usuario.
Disponibilidad en implementaciones de instancias de Operator Nexus
Garantizar la disponibilidad en las implementaciones de carga de trabajo de Azure Operator Nexus es una responsabilidad dividida. Como se indicó en la sección anterior, los recursos basados en Operator Nexus AKS se implementan con redundancia de zona de disponibilidad. En esta sección, se consideran los procedimientos recomendados para la disponibilidad de cargas de trabajo locales.
En general, los destinos de disponibilidad se logran mediante implementaciones locales y con redundancia geográfica.
Zona Nexus: un mecanismo para la redundancia de carga de trabajo local
Las instancias locales del operador Nexus constan de un diseño de varios bastidores que proporciona redundancia física en todos los niveles de la pila. Cada bastidor se designa como un dominio de error y, por lo tanto, se puede configurar como una zona Nexus donde estas zonas pueden y, preferiblemente, deben usarse para implementaciones de cargas de trabajo con redundancia local.
Instancia de Nexus: un mecanismo para la redundancia de cargas de trabajo geográficas
Las instancias locales de Nexus se hospedan en una región de Azure específica. Como se indicó anteriormente, los servicios de Azure usados y los recursos de Nexus se implementan en varias zonas de disponibilidad de esa región de Azure.
Las instancias de Nexus que están distribuidas geográficamente, es decir, no en el mismo centro de datos del operador (posiblemente ni siquiera en la misma región geográfica) y alojadas en diferentes regiones de Azure deben utilizarse para implementar cargas de trabajo de forma redundante para la redundancia geográfica.
Advertencia
La implementación de cargas de trabajo en, por ejemplo, dos instancias de Nexus distribuidas geográficamente no son suficientes para lograr una verdadera redundancia geográfica a menos que las instancias de Nexus con redundancia geográfica se hospeden en diferentes regiones de Azure.
En el improbable caso de que una región de Azure deje de estar disponible, los servicios de Azure, así como los recursos de Nexus de esa región también quedarán no disponibles. Aunque esto no afecta a la ejecución de cargas de trabajo, evita funcionalidades como iniciar nuevas cargas de trabajo, análisis, etc.
Varias instancias de Nexus en la misma ubicación geográfica
Hay escenarios en los que es necesario implementar varias instancias de Nexus en la misma ubicación geográfica. Obviamente, la redundancia geográfica de la carga de trabajo no se logra mediante la implementación de cargas de trabajo en instancias de Nexus en la misma ubicación geográfica.
Una consideración en el diseño de confiabilidad, aparte de la disponibilidad, es la resistencia y la capacidad de recuperarse de errores. La recuperación de errores y la capacidad de cumplir los objetivos de tiempo de recuperación requiere que se limite el radio de "explosión" o impacto de los errores. En el escenario en el que se implementan varias instancias de Nexus en la misma ubicación geográfica, el diseño resistente exige que estas instancias de Nexus se hospeden en diferentes regiones de Azure. Por lo tanto, cuando se produce un error en una región de Azure, su impacto se limita a una instancia de Nexus.