Las organizaciones que exigen los mayores requisitos de tiempo de actividad deben ser capaces de soportar interrupciones más importantes, como la pérdida de una zona de disponibilidad (AZ) completa. Aunque el aprovisionamiento de un clúster de Kubernetes que abarca varias AZ es una tarea sencilla en los proveedores de la nube administrada, existen requisitos administrativos adicionales que deben tenerse en cuenta durante las fases de implementación, configuración y operativa del software ArcGIS Enterprise on Kubernetes.
En las secciones siguientes se describen las consideraciones que deben tenerse en cuenta antes de configurar la organización, los efectos previstos de la pérdida de funcionalidad dentro de una AZ, y cómo un administrador puede verificar el estado del sistema subyacente tras la recuperación de la funcionalidad en esa AZ.
Como mínimo, el clúster de Kubernetes donde se implemente la aplicación debe cumplir los siguientes requisitos:
- Los grupos de nodos trabajadores abarcan al menos tres AZ.
- Existe la capacidad adecuada de nodos trabajadores para reequilibrar todas las cargas de trabajo en dos AZ durante una interrupción.
implementación y configuración
Cuando se implementa ArcGIS Enterprise on Kubernetes en un clúster multi-AZ, la presencia de cargas de trabajo con estado significa que existe una dependencia de AZ de discos asociados cuando se utilizan dispositivos de almacenamiento en bloques.
Para garantizar que las réplicas asociadas de cada statefulset se distribuyen por la topología adecuada, se ha introducido una nueva propiedad, K8S_AVAILABILITY_TOPOLOGY_KEY, en el archivo de propiedades de implementación que debe actualizarse antes de ejecutar la secuencia de comandos de implementación. Actualizar esta propiedad a cualquier valor distinto de kubernetes.io/hostname introduce una especificación topologySpreadConstraint en los statefulsets, que garantiza que no se tenga un balance desigual o réplicas en una única AZ. La calve de la etiqueta del nodo AZ en la mayoría de proveedores de la nube es topology.kubernetes.io/zone.
Para garantizar la máxima disponibilidad durante la configuración de la organización, configure la organización mediante el perfil de arquitectura de disponibilidad mejorada. Este es el único perfil que garantiza una cobertura adecuada para todas las cargas de trabajo con estado en caso de fallo de una AZ.
Incluso cuando se utiliza el perfil de arquitectura de disponibilidad mejorada, hay una serie de implementaciones que permanecen en una única réplica, ya que varían mucho en función de los requisitos específicos de la organización. Tenga en cuenta las siguientes implementaciones para escalar por encima de una única réplica para reducir adicionalmente el tiempo de inactividad:
- arcgis-enterprise-apps
- arcgis-enterprise-manager
- arcgis-enterprise-portal
- arcgis-enterprise-web-style-app
- arcgis-help
- arcgis-javascript-api
- arcgis-service-api
- arcgis-service-lifecycle-manager
- arcgis-featureserver-webhook-processor
- arcgis-gpserver-webhook-processor
Cada una de las implementaciones enumeradas anteriormente, excepto arcgis-enterprise-web-style-app, tarda menos tiempo en reiniciarse tras una pérdida de AZ en comparación con el proceso de conmutación por error del data store relacional. El escalado a una réplica adicional de todas las implementaciones enumeradas añade aproximadamente 1 CPU y 0,5 GiB de RAM adicionales a las solicitudes totales del espacio de nombres y 5 CPU y 2,5 GiB de RAM adicionales a los límites totales del espacio de nombres.
Al publicar servicios, defina todos los servicios dedicados para que se ejecuten como mínimo dos pods para garantizar que no haya interrupciones durante la reprogramación. Escale las implementaciones de instancias compartidas al menos a dos réplicas con el mismo propósito.
Efectos de una pérdida de AZ
El significado y el impacto de la pérdida de una AZ varía en función de los servicios en la nube afectados. La pérdida de un servicio concreto, como cálculo o almacenamiento, puede tener un impacto significativo en las cargas de trabajo en ejecución, mientras que otras interrupciones basadas en la red, como la resolución de DNS o los aumentos bruscos de latencia, pueden afectar a la forma en que los microservicios pueden comunicarse entre sí.
Durante la conmutación por error del almacén relacional, algunas funciones como inicio de sesión, edición del servicio de entidades alojadas y carga de capas alojadas pueden degradarse durante un breve periodo de tiempo. Cuando la instancia en espera termina de convertirse en principal, todas las funcionalidades de la organización deben volver a un estado estable.
Verificación del estado de la organización
Los administradores pueden utilizar los informes de comprobación de estado integrados para evaluar el estado de su sitio. También pueden revisar las cargas de trabajo del espacio de nombres para detectar problemas de inicio de pods y otras dificultades que puedan surgir.
Durante una interrupción de AZ
Si se pierde una AZ al utilizar el almacenamiento en bloques para los PV, los pods statefulset no pueden reprogramarse en otras AZ debido a los requisitos de afinidad de volúmenes.
Para los data stores que lo requieran, se mantiene un quórum para que los servicios asociados puedan funcionar en un estado degradado. Dado que el almacén relacional es un componente central del que dependen otros servicios, la espera se puede restablecer a través de la API de admin. Esto elimina el statefulset y el PVC asociado, y creará un nuevo statefulset. Esto permite a la instancia en espera sincronizarse con la principal después de trasladarse a una de las AZ restantes.
Después de una interrupción de AZ
Cuando se restablecen los servicios en la AZ que experimenta una interrupción, reinicie las cargas de trabajo asociadas que estaban bloqueadas en un estado pendiente, lo que puede confirmarse a través de la API Kubernetes.
Si los servicios no pueden restaurarse en una AZ existente, asegúrese de que el clúster tenga un mínimo de tres AZ restantes. Si no es así, extienda el clúster hasta una AZ adicional. Una vez hecho esto, cree una copia de seguridad, desinstale y vuelva a instalar, y realice una operación de restauración a partir de la copia de seguridad..