Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Configuración de un dominio multi-AZ en Amazon OpenSearch Service

Para evitar la pérdida de datos y minimizar el tiempo de inactividad del clúster de Amazon OpenSearch Service en caso de interrupción del servicio, puede distribuir los nodos en dos o tres zonas de disponibilidad de la misma región, una configuración conocida como Multi-AZ. Las zonas de disponibilidad son ubicaciones aisladas dentro de cada región de AWS.

Para los dominios que ejecutan cargas de trabajo de producción, recomendamos la opción de implementación de Multi-AZ con modo de espera, que crea la siguiente configuración:

El resto de esta sección contiene explicaciones y contextos sobre estas configuraciones.

Multi-AZ con modo de espera

Multi-AZ con modo de espera es una opción de implementación para los dominios de Amazon OpenSearch Service que ofrece una disponibilidad del 99,99 %, un rendimiento uniforme para las cargas de trabajo de producción y una configuración y administración de dominios simplificadas. Cuando utilice Multi-AZ con modo de espera, los dominios son resistentes a los fallos de infraestructura, sin que ello afecte al rendimiento ni a la disponibilidad. Esta opción de implementación cumple con este estándar al exigir una serie de prácticas recomendadas, como un recuento específico de nodos de datos, un recuento de nodos maestros, un tipo de instancia, un recuento de réplicas, la configuración de las actualizaciones de software y la activación del ajuste automático.

Al utilizar Multi-AZ con modo de espera, OpenSearch Service crea un dominio en tres zonas de disponibilidad, cada una de las cuales contiene una copia completa de los datos y los datos se distribuyen equitativamente en cada una de las zonas. Su dominio reserva los nodos de una de estas zonas como en espera, lo que significa que no atienden solicitudes de búsqueda. Cuando OpenSearch Service detecta un fallo en la infraestructura subyacente, activa automáticamente los nodos en espera en menos de un minuto. El dominio sigue atendiendo las solicitudes de indexación y búsqueda, y cualquier impacto se limita al tiempo que se tarda en realizar la conmutación por error. No hay redistribución de los datos o los recursos, por lo que el rendimiento del clúster no se ve afectado y no hay riesgo de que se degrade la disponibilidad. Multi-AZ con modo de espera está disponible sin costo adicional.

Tiene dos opciones para crear un dominio con el modo de espera en AWS Management Console. En primer lugar, puede crear un dominio con el método de Creación fácil y OpenSearch Service utilizará automáticamente una configuración predeterminada, que incluye lo siguiente:

También puede elegir el método de Creación estándar y seleccionar Dominio con modo de espera como opción de implementación. Esto le permite personalizar su dominio sin dejar de utilizar las características clave del modo de espera, como tres zonas y tres nodos maestros. Recomendamos elegir un recuento de nodos de datos que sea múltiplo de tres (el número de zonas de disponibilidad).

Una vez que haya creado su dominio, puede ir a las páginas de detalles del dominio y, en la pestaña Configuración del clúster, confirmar que en las zonas de disponibilidad aparezca 3-AZ con modo de espera.

Si tiene problemas para migrar un dominio existente a Multi-AZ con modo de espera, consulte Error migrating to Multi-AZ with Standby en la guía de solución de problemas.

Limitaciones

Al configurar un dominio con Multi-AZ con modo de espera, tenga en cuenta las siguientes limitaciones:

Multi-AZ sin modo de espera

El servicio OpenSearch sigue siendo compatible con Multi-AZ sin modo de espera, lo que ofrece una disponibilidad del 99,9 %. Los nodos se distribuyen en las zonas de disponibilidad y la disponibilidad depende del número de zonas de disponibilidad y de las copias de los datos. Mientras que en el modo de espera hay que configurar el dominio según las prácticas recomendadas, sin el modo de espera puede elegir su propio número de zonas de disponibilidad, nodos y réplicas. No recomendamos esta opción a menos que tenga flujos de trabajo existentes que se verían interrumpidos al crear dominios con el modo de espera.

Si elige esta opción, le recomendamos que seleccione tres zonas de disponibilidad para seguir siendo resistente a los errores de nodos, discos y zonas de disponibilidad única. Cuando se produce un error, el clúster redistribuye los datos entre los recursos restantes para mantener la disponibilidad y la redundancia. Este movimiento de datos aumenta el uso de recursos en el clúster y puede afectar al rendimiento. Si el clúster no tiene el tamaño adecuado, puede experimentar una disminución de la disponibilidad, lo que en gran medida va en contra del propósito de las zonas de disponibilidad múltiples.

La única forma de configurar un dominio sin modo de espera en el AWS Management Console es elegir el método de creación Creación estándar y seleccionar Dominio sin modo de espera como opción de implementación.

Distribución de particiones

Si habilita Multi-AZ sin modo de espera, debe haber al menos una réplica por cada índice del clúster. Sin réplicas, OpenSearch Service no puede distribuir copias de sus datos a otras zonas de disponibilidad. Afortunadamente, la configuración predeterminada para cualquier índice es un recuento de réplicas de 1. Como se muestra en el siguiente diagrama, OpenSearch Service hace lo mejor posible para distribuir las particiones principales y sus particiones de réplica correspondientes entre diferentes zonas.

Además de distribuir las particiones por zona de disponibilidad, OpenSearch Service las distribuye también por nodo. Sin embargo, ciertas configuraciones de dominio pueden generar un número desequilibrado de particiones. Imagine el siguiente dominio:

En esta situación, OpenSearch Service tiene que sobrecargar uno de los nodos para distribuir la carga de las particiones principales y replicadas entre las zonas, tal y como se muestra en el siguiente diagrama.

Para evitar este tipo de situaciones, que pueden ejercer demasiada presión sobre determinados nodos y perjudicar el rendimiento, le recomendamos que elija multi-AZ con modo de espera o que elija un número de instancias que sea múltiplo de tres cuando planee tener dos o más réplicas por cada índice.

Distribución de nodos maestros dedicados

Aunque seleccione dos zonas de disponibilidad al configurar el dominio, OpenSearch Service distribuirá automáticamente los nodos principales dedicados en tres zonas de disponibilidad. Esta distribución ayuda a evitar el tiempo de inactividad del clúster si una zona experimenta una interrupción del servicio. Si está utilizando los tres nodos principales dedicados recomendados y una zona de disponibilidad deja de funcionar, el clúster seguirá teniendo un quorum (2) de nodos principales dedicados y podrá seleccionar un nuevo nodo principal. En el siguiente diagrama, se muestra esta configuración.

Si selecciona un tipo de instancia de una generación anterior que no esté disponible en tres zonas de disponibilidad, pueden producirse las siguientes situaciones:

Interrupción de las zonas de disponibilidad

No es frecuente que el servicio se interrumpa en las zonas de disponibilidad, pero puede ocurrir. En la siguiente tabla, se muestran diferentes configuraciones de Multi-AZ y los comportamientos durante una interrupción. La última fila de la tabla se aplica a Multi-AZ con modo de espera, mientras que todas las demás filas tienen configuraciones que solo se aplican a Multi-AZ sin modo de espera.

En todas las configuraciones, independientemente de la causa, los errores en los nodos pueden hacer que los nodos de datos restantes del clúster experimenten un periodo de aumento de la carga mientras OpenSearch Service configura automáticamente nuevos nodos para sustituir a los que faltan.

Por ejemplo, en caso de que se interrumpa una zona de disponibilidad de una configuración de tres zonas, solo dos tercios de los nodos de datos tendrán que procesar tantas solicitudes como lleguen al clúster. A medida que se procesen estas solicitudes, los nodos restantes irán replicando particiones en los nuevos nodos tan pronto como se conecten, lo que podría afectar aún más al rendimiento. Si la disponibilidad es esencial para la carga de trabajo, considere la posibilidad de añadir más recursos al clúster para mitigar este problema.