Servicio Amazon OpenSearch es un servicio totalmente administrado que puede utilizar para implementar y operar OpenSearch y clústeres de Elasticsearch heredados, de manera rentable, a escala en la nube de AWS. El servicio le facilita realizar análisis de registros interactivos, monitoreo de aplicaciones en tiempo real, búsqueda de sitios web y más al ofrecer las últimas versiones de OpenSearch, support300t para 19 versiones de Elasticsearch (versiones 1.5 a 7.10) y capacidades de visualización impulsadas por OpenSearch Dashboards y Kibana (versiones 1.5 a 7.10).

OpenSearch Service anunció el apoyo de replicación entre clústeres el 5 de octubre de 2021. Con la replicación entre clústeres para OpenSearch Service, puede replicar índices con baja latencia de un dominio a otro en la misma o en diferentes regiones de AWS sin necesidad de tecnologías adicionales. La replicación entre clústeres proporciona consistencia secuencial mientras copia continuamente datos del índice líder al índice seguidor. La coherencia secuencial garantiza que el líder y el seguidor devuelvan el mismo conjunto de resultados después de aplicar las operaciones en los índices en el mismo orden. La replicación entre clústeres está diseñada para minimizar el retraso en la entrega entre el índice líder y el seguidor. Los tiempos de entrega típicos son menos de un minuto. Puede monitorear continuamente el estado de la replicación a través de las API. Además, si tiene índices que siguen un patrón de índice, puede crear reglas de seguimiento automático y se replicarán automáticamente.

En esta publicación, le mostramos cómo usar estas funciones para garantizar la disponibilidad de sus datos mediante la replicación entre clústeres con OpenSearch Service.

Beneficios de la replicación entre clústeres

La replicación entre clústeres es útil para casos de uso relacionados con la proximidad de datos, la recuperación ante desastres y los patrones de múltiples clústeres.

La proximidad de datos ayuda a reducir la latencia y el tiempo de respuesta al acercar los datos a su usuario o servidor de aplicaciones. Por ejemplo, puede replicar datos de una región, us-west-2 (líder), a varias regiones de todo el mundo que actúan como seguidores, eu-west-1, ap-south-1, ca-central-1, y así sucesivamente, donde el seguidor puede sondear al líder para sincronizar datos nuevos o actualizados en el líder. En el siguiente diagrama, los datos se replican desde un clúster de producción en us-west-2 a varios clústeres disponibles localmente cerca del usuario o la aplicación.

En el caso de la recuperación ante desastres, puede tener uno o más clústeres de seguidores en la misma región o en regiones diferentes y, siempre que tenga un clúster activo, puede atender solicitudes de lectura a los usuarios. En el siguiente diagrama, los datos se replican desde un clúster de producción a dos clústeres de recuperación ante desastres diferentes.

A partir de hoy, la replicación entre clústeres admite lectura activa/activa y escritura activa/pasiva, como se muestra en el siguiente diagrama.

Con esta implementación, puede resolver el problema de lectura si su líder se cae, pero ¿qué pasa con la escritura? En el momento de escribir este artículo, la replicación entre clústeres no admite ningún tipo de mecanismo de conmutación por error para convertir a su seguidor en el líder. En este escenario, es posible que deba hacer algunas tareas domésticas adicionales para que su dominio de seguidor se convierta en el líder y comience a aceptar solicitudes de escritura. Esta publicación muestra los pasos para configurar la replicación entre clústeres y minimizar el tiempo de inactividad haciendo avanzar a su seguidor para que sea el líder.

Configurar la replicación entre clústeres

Para configurar la replicación entre clústeres, complete los siguientes pasos:

1. Cree dos clústeres en dos regiones, por ejemplo leader-east (líder) y follower-west (seguidor).
   La replicación entre clústeres funciona en un modelo de extracción, donde el usuario crea una conexión saliente en el dominio del seguidor, y el seguidor sigue sondeando al líder para sincronizar con documentos nuevos o actualizados para un índice.
2. Ir al dominio del seguidor (follower-west) y cree una solicitud para una conexión saliente. Especifique el alias para esta conexión como follower-west.
3. Vaya al dominio líder, localice la conexión entrante y apruebe la conexión entrante desde follower-west.
4. Edite la configuración de seguridad y agregue la siguiente política de acceso para permitir ESCrossClusterGet en el dominio líder, que es leader-east:

   {
         "Effect": "Allow",
         "Principal": {
           "AWS": "*"
         },
         "Action": "es:ESCrossClusterGet",
         "Resource": "arn:aws:es:us-east-2:xxx-accountidxx:domain/leader-east"
   }

5. Cree un índice líder (en el dominio líder) o ignore este paso si ya tiene un índice para replicar:

   PUT catalog

6. Navegue a OpenSearch Dashboards para el dominio seguidor-oeste.
7. En Herramientas de desarrollo tab, ejecute el siguiente comando (o use curl para conectarse directamente):

   PUT _plugins/_replication/catalog-rep/_start
       {
          "leader_alias": "ccr-for-west",
          "leader_index": "catalog",
           "use_roles":{
             "leader_cluster_role": "cross_cluster_replication_leader_full_access",
             "follower_cluster_role": "cross_cluster_replication_follower_full_access"
          }
       }

8. Confirme la replicación:

   GET _plugins/_replication/catalog-rep/_status

9. Indexe algunos documentos en el índice principal; el siguiente comando indexa documentos en el catálogo index id:1:

   POST catalog/_doc
   {
     "id": "1"
   }

10. Ahora vaya al dominio del seguidor y confirme que los documentos se replican ejecutando la siguiente consulta de búsqueda:

    Request:
    GET catalog/_search
    
    Response:
    {
    ...
       "hits" : [
          {
            "_index" : "catalog",
            "_type" : "_doc",
            "_id" : "hg3YsYIBcxKtCcyhNyp4",
            "_score" : 1.0,
            "_source" : {
              "id" : "1"
            }
          }
        ]
      }
    }

Pausar y detener la replicación

Cuando su replicación se está ejecutando, puede usar estos pasos para pausar y detener la replicación.

Puede usar la siguiente API para pausar la replicación, por ejemplo, mientras depura un problema o carga en el líder. Asegúrese de agregar un cuerpo vacío con la solicitud.

POST _plugins/_replication/catalog-rep/_pause
    {}

Si pausa la replicación, debe reanudarla dentro de las 12 horas. Si no puede reanudarlo dentro de las 12 horas, debe detener la replicación, eliminar el índice de seguidores y reiniciar la replicación del líder.

Detener la replicación hace que el índice de seguidores deje de seguir al líder y se convierta en un índice estándar. Utilice el siguiente código para detener la replicación:

POST _plugins/_replication/catalog-rep/_stop
    {}    

Tenga en cuenta que no puede reiniciar la replicación en este índice después de detenerlo.

Seguimiento automático

Puede definir un conjunto de reglas de replicación contra un único dominio líder que replique automáticamente los índices que coincidan con un patrón específico.

Cuando un índice en el dominio líder coincide con uno de los patrones (por ejemplo, logstash-*), se crea un índice de seguidor coincidente en el dominio de seguidor. El siguiente código es una regla de replicación de ejemplo para seguimiento automático:

POST _plugins/_replication/_autofollow
    {
      "leader_alias" : "follower-west",
       "name": "rule-name",
       "pattern": "logstash-*",
      "use_roles":{
          "leader_cluster_role": "cross_cluster_replication_leader_full_access",
          "follower_cluster_role": "cross_cluster_replication_follower_full_access"
       }
    }

Elimine la regla de replicación para dejar de replicar nuevos índices que coincidan con el patrón:

DELETE _plugins/_replication/_autofollow
    {
       "leader_alias" : "follower-west",
       "name": "rule-name"
    } 

Supervise las métricas de replicación entre clústeres

OpenSearch Service proporciona métricas para monitorear la replicación entre clústeres que pueden ayudarlo a conocer el estado de la replicación junto con su rendimiento. Por ejemplo, ReplicationRate puede ayudarlo a comprender la tasa promedio de operaciones de replicación por segundo, y ReplicationNumSyncingIndices puede ayudarlo a conocer la cantidad de índices con el estado de replicación SYNCING. Para obtener más detalles sobre todas las métricas proporcionadas por OpenSearch Service para la replicación entre clústeres, consulte Métricas de replicación entre clústeres.

Recuperarse del fracaso

En este punto, tenemos dos dominios de OpenSearch Service que se ejecutan en dos regiones diferentes. Consideremos un escenario en el que ocurre un evento desastroso en la Región con su dominio de líder y el líder cae. En este punto, aún puede servir tráfico de lectura desde el dominio del seguidor, pero no se aplican actualizaciones adicionales porque el seguidor no puede leer desde el líder. En este escenario, puede utilizar los siguientes pasos para hacer que su seguidor avance hasta convertirse en líder:

1. Vaya a su dominio seguidor y detenga la replicación:

   POST _plugins/_replication/catalog-rep/_stop
   {}

   Después de que la replicación se detiene en el dominio del seguidor, su índice de seguidores actúa como un índice normal.

2. En este punto, puede comenzar a enviar tráfico de escritura al seguidor.

De esta manera, puede hacer avanzar su dominio de seguidor para convertirse en líder y enrutar su tráfico de escritura al seguidor, lo que ayuda a evitar la pérdida de datos para nuevos conjuntos de cambios y actualizaciones.

Tenga en cuenta que hay un pequeño retraso (menos de un minuto) entre la sincronización líder-seguidor. Además, podría haber una pequeña pérdida de datos en el dominio del seguidor que se indexó al líder y no se sincronizó con el seguidor (especialmente cuando el líder dejó de funcionar y el seguidor no tuvo la oportunidad de sondear los cambios y actualizaciones). Para este escenario, debe tener un mecanismo en su canal de ingesta para reproducir los datos al seguidor cuando su líder se cae.

Ahora, ¿qué pasa si el líder vuelve a estar en línea después de un cierto período de tiempo? En este momento, no puede volver a iniciar la replicación desde su seguidor para sincronizar el delta con el líder. Incluso si intenta configurar la replicación de seguidor a líder, fallará con un error. Después de haber usado un índice para una conexión líder-seguidor, no puede volver a usar el mismo índice para crear una nueva replicación. ¿Entonces que haces ahora?

En este escenario, puede utilizar los siguientes pasos para configurar una conexión líder-seguidor en la dirección opuesta:

1. Elimine el índice del líder anterior.
2. Configure la replicación entre regiones en la dirección opuesta con su nuevo líder (follower-west) y nuevo seguidor (leader-east).
3. Inicie la replicación en el nuevo seguidor (que era su antiguo líder) y sincronice los datos.

Esto ejecuta la sincronización de todos los datos nuevamente para ese índice y puede llevar tiempo dependiendo del tamaño del índice porque arrancará el índice y comenzará la replicación desde cero. Además, incurrirá en gastos estándar Costos de transferencia de datos de AWS para los datos transferidos con esta replicación. De esta manera, puedes adelantar a tu seguidor (follower-west) ser líder y hacer tu líder (leader-east) el nuevo seguidor.

Conclusión

En esta publicación, le mostramos cómo puede usar la replicación entre clústeres para sincronizar datos entre los índices de líder y seguidor. También demostramos cómo puede hacer avanzar a su seguidor para que se convierta en líder en caso de que su líder se caiga. Esto puede ayudarlo a atender el tráfico en caso de cualquier escenario de desastre.

Si tiene comentarios sobre esta publicación, envíe sus comentarios en la sección de comentarios. Si tiene preguntas sobre esta publicación, inicie un nuevo hilo en el Foro del servicio Amazon OpenSearch or póngase en contacto con el soporte de AWS.

Sobre la autora

Prashant Agrawal es un arquitecto de soluciones especializado en búsquedas con OpenSearch Service. Trabaja en estrecha colaboración con los clientes para ayudarlos a migrar sus cargas de trabajo a la nube y ayuda a los clientes existentes a ajustar sus clústeres para lograr un mejor rendimiento y ahorrar costos. Antes de unirse a AWS, ayudó a varios clientes a usar OpenSearch y Elasticsearch para sus casos de uso de búsqueda y análisis de registros. Cuando no está trabajando, puedes encontrarlo viajando y explorando nuevos lugares. En resumen, le gusta hacer Comer → Viajar → Repetir.