Configuración de la replicación entre clústeres de Elasticsearch para alta disponibilidad

Puede hacer que la búsqueda sea más resistente durante el mantenimiento, las conmutaciones por error y las actualizaciones en una implementación de alta disponibilidad habilitando la replicación entre clústeres (CCR) de Elasticsearch.

En este artículo

Acerca de la replicación entre clústeres de Elasticsearch

GitHub Enterprise Server usa Elasticsearch para impulsar la búsqueda entre problemas, solicitudes de incorporación de cambios, repositorios, proyectos y versiones, y los recuentos que se muestran en toda la interfaz web. Dado que la búsqueda es fundamental para el producto, la confiabilidad de Elasticsearch afecta directamente a la administración diaria de la instancia.

En una configuración de alta disponibilidad (HA), GitHub Enterprise Server usa un modelo líder/seguidor. El dispositivo principal recibe todas las operaciones de escritura y el tráfico, y los dispositivos de réplica permanecen sincronizados como instancias en espera de solo lectura que pueden asumir el control si falla el dispositivo principal. Para obtener más información, vea Acerca de la configuración de alta disponibilidad.

En versiones anteriores, Elasticsearch no admitía este modelo líder o seguidor directamente. Para replicar datos de búsqueda, GitHub Enterprise Server ejecutó un único clúster de Elasticsearch que abarcaba los dispositivos principal y de réplica. Este enfoque funcionó, pero introdujo una clase de problemas: Elasticsearch podría mover una partición principal (la partición responsable de recibir y validar escrituras) en un dispositivo de réplica. Si esa réplica se desconectaba para el mantenimiento, la instancia podría entrar en un estado bloqueado, ya que la réplica esperaba que Elasticsearch estuviera en buen estado, mientras que Elasticsearch no podía volver a estar en buen estado hasta que la réplica se volvió a unir.

Elasticsearch Cross-Cluster Replication (CCR) quita esta dependencia. En lugar de un clúster que abarca cada dispositivo, cada dispositivo se ejecuta como un clúster de Elasticsearch independiente de un solo nodo. Después, CCR replica los datos de índice entre estos clústeres mediante un patrón líder o seguidor admitido de forma nativa. Los datos solo se copian después de que se conserven de forma duradera en los segmentos subyacentes de Lucene, por lo que las réplicas siempre siguen los datos que se han escrito de forma segura. Como resultado, un fragmento primario crítico ya no puede quedar bloqueado en una réplica de solo lectura.

Benefits

  • Menos actualizaciones bloqueadas y ventanas de mantenimiento. Al quitar la dependencia circular entre los dispositivos principal y de réplica durante el mantenimiento, se reduce el riesgo de que una instancia se bloquee.
  • Protección de datos más sólida. Los datos solo se replican después de guardarlos de forma duradera, lo que ayuda a evitar daños en el índice durante las conmutaciones por error.
  • Operaciones más sencillas. El patrón reduce la necesidad de reparaciones manuales de índices que antes se producían cuando los pasos de mantenimiento se realizaban en un orden incorrecto.

Availability

Elasticsearch CCR es compatible a partir de la versión GitHub Enterprise Server 3.19.1. La característica es opcional. GitHub planea convertir CCR en la arquitectura de búsqueda de alta disponibilidad predeterminada en el transcurso de los dos próximos años, por lo que tiene tiempo para probarla y enviar comentarios antes de que pase a ser la opción predeterminada.

Requirements

Antes de habilitar CCR, confirme lo siguiente.

  • La instancia ejecuta GitHub Enterprise Server 3.19.1 o una versión posterior.
  • La instancia está configurada para alta disponibilidad con al menos dos dispositivos (una principal y una o varias réplicas).
  • Dispone de una licencia GitHub Enterprise Server actualizada que incluye el permiso de Elasticsearch necesario para CCR. Póngase en contacto Equipo de ventas de GitHub con o Soporte de GitHub para que su empresa esté habilitada para la nueva licencia y, a continuación, descargue el archivo de licencia actualizado.

Advertencia: Cuando CCR está activado, la comprobación previa a la actualización requiere una licencia válida con CCR habilitado. Si la marca está habilitada y se produce un error en la comprobación de licencia, la actualización no continuará. Asegúrese de que la licencia actualizada está instalada antes de habilitar la característica o la actualización. Si no está seguro de si la licencia incluye el derecho de Elasticsearch, póngase en contacto con Soporte de GitHub.

Habilitación de la replicación entre clústeres de Elasticsearch

Nota: La migración puede tardar mucho tiempo en función del tamaño de la instancia, ya que los datos de búsqueda se consolidan en el principal antes de reiniciar la replicación. Planee habilitar CCR durante una ventana de mantenimiento y pruebe primero el proceso en un entorno que no sea de producción. Para obtener más información, vea Actualizar su instancia.

  1. Póngase en contacto con Soporte de GitHub y solicite acceso a la nueva arquitectura de búsqueda HA. GitHub habilitará su empresa para que pueda descargar la licencia necesaria con CCR habilitado.

  2. Descargue la licencia actualizada y cárguelo en la instancia. Para obtener más información, vea Descarga de la licencia para GitHub Enterprise.

  3. En el dispositivo principal, habilite la característica.

    ghe-config app.elasticsearch.ccr true

  4. Aplique la configuración ejecutando una ejecución de configuración o actualizando la instancia a 3.19.1 o posterior.

    ghe-config-apply

  5. Cuando se reinicia la instancia, Elasticsearch migra la instalación al nuevo método de replicación. Esta migración consolida los datos de búsqueda en la base de datos principal, finaliza el clúster que anteriormente abarcaba los dispositivos y reinicia la replicación mediante CCR. Durante la migración, GitHub Enterprise Server asocia seguidores a los índices de búsqueda existentes y habilita una regla de seguimiento automático para que los índices creados en el futuro se sigan automáticamente.

Uso de la replicación entre clústeres de Elasticsearch

Comprobación de la replicación

Una vez completada la migración, la búsqueda continúa funcionando normalmente y no se requiere ningún cambio en la forma en que los usuarios buscan. Para confirmar el correcto funcionamiento de la replicación, genere un paquete de soporte, que incluye información sobre el estado de CCR para su revisión. Para obtener más información, vea Proporcionar datos al soporte técnico de GitHub.

Conmutación por error y recuperación ante desastres

Sigue usando las utilidades estándar de replicación de alta disponibilidad para administrar réplicas y realizar la conmutación por error. Para obtener más información, vea Iniciar una tolerancia de fallos a tu aparato de réplica y Recuperar una configuración de disponibilidad alta.

Después de una conmutación por error con CCR habilitado, el dispositivo promovido se convierte en el nuevo líder de búsqueda, y las réplicas vuelven a seguir los índices de este como parte del proceso de recuperación estándar. Si encuentra errores relacionados con la replicación de búsqueda durante o después de una conmutación por error, póngase en contacto con Soporte de GitHub.

Deshabilitación de la replicación entre clústeres de Elasticsearch

Advertencia: No deshabilite CCR en una instancia de producción sin instrucciones de Soporte de GitHub. Deshabilitar CCR no es una operación de autoservicio rutinaria. La desactivación de la característica puede desencadenar la eliminación de datos de réplica de Elasticsearch como parte de volver al modo anterior.

Si necesita volver a la arquitectura de búsqueda anterior, póngase en contacto con Soporte de GitHub antes de realizar cualquier cambio. GitHub le ayudará a confirmar que la licencia, el estado de replicación y la ruta de actualización se controlan de forma segura.

Lectura adicional