Tipos de réplica y capacidades
¿Cuáles son los distintos tipos de réplicas que se usan en una implementación de alta disponibilidad?
Hay tres tipos de réplicas en un entorno de alta disponibilidad:
-
Réplicas pasivas
-
Réplica activa
-
Réplicas de caché (conocidas como cachés de repositorio).
**Las réplicas pasivas** simplemente sincronizan datos de la instancia principal y no controlan ningún tráfico GitHub . Sin embargo, los usuarios pueden promover una réplica pasiva a principal si es necesario.
Una réplica geográfica es un ejemplo de una réplica activa (estos términos a menudo se usan indistintamente). Las réplicas activas sincronizan los datos de la principal. Una réplica activa también puede procesar directamente el tráfico de GitHub o dirigirlo al servidor principal.
**Las réplicas de caché** sincronizan los datos de Git y Git Large File Storage (Git LFS) desde la principal. Las réplicas almacenadas en caché están diseñadas para escenarios de lectura intensiva, como granjas de CI. Solo aceptan lecturas/recuperaciones/clones para repositorios de los que tienen una copia local. Para cualquier otro repositorio, devolverán un error. Siempre rechazan los pushes con un mensaje de error.
¿Se pueden promover todos los tipos de réplica a principal?
Solo se pueden promover réplicas pasivas y activas a principal. Las réplicas almacenadas en caché no se pueden promover a principal.
¿Puede una sola implementación tener todas las réplicas?
Una sola implementación puede incluir réplicas activas, réplicas pasivas y réplicas de caché todas a la vez.
¿La instancia principal espera en réplicas para las escrituras?
La instancia principal no espera en réplicas para las escrituras. En alta disponibilidad, una inserción escribe en la réplica principal y también en todas las réplicas pasivas y activas. Sin embargo, dado que el nodo principal es el único nodo de votación, la inserción se considera aceptada cuando se realiza correctamente en el nodo principal.
Requisitos de comunicación y red
¿Qué entidades pueden comunicarse con réplicas activas?
La instancia principal se comunica con las réplicas activas para sincronizar los datos y gestionar las solicitudes que las réplicas activas redirigen de nuevo a la principal. El tráfico web, de API y de Git de GitHub (generado por humanos y automatizaciones) se puede enrutar directamente a las réplicas activas. Por eso es importante configurar DNS para que el tráfico destinado a una réplica activa llegue realmente.
¿Qué entidades pueden comunicarse con réplicas pasivas?
La instancia principal se comunica con réplicas pasivas para sincronizar datos. Las réplicas pasivas no reciben ni procesan ningún otro tráfico GitHub .
¿Qué entidades pueden comunicarse con las réplicas de caché?
El tráfico de Git de solo lectura, que proviene principalmente de automatizaciones como las granjas de CI, se pueden enrutar y procesar por las réplicas almacenadas en caché. Para habilitarlo, debe configurar el DNS para dirigir el tráfico pertinente a la réplica de caché. Las réplicas de caché no están diseñadas para atender el tráfico de usuario ni para gestionar el tráfico push.
¿Deben las réplicas estar ubicadas cerca del primario?
No es necesario que las réplicas se encuentren conjuntamente con la principal. Por definición, una réplica geográfica está geográficamente alejada de la principal y no en el mismo centro de datos. Las réplicas almacenadas en caché tampoco tienen requisitos de coubicación.
Sin embargo, se recomienda que al menos una réplica pasiva se coubique con la principal en el mismo centro de datos para una conmutación por error más rápida durante una interrupción de la principal. En caso de una interrupción completa del centro de datos, puede promover una réplica pasiva distribuida geográficamente.
¿Cuáles son los requisitos de latencia entre la réplica principal y las réplicas?
Las réplicas principales y activas tienen requisitos estrictos de latencia. Las réplicas principales y pasivas, así como las réplicas principales y de caché, tienen requisitos de latencia recomendados. Para más información, consulta Crear una réplica de alta disponibilidad y Supervisión de una configuración de alta disponibilidad. Las latencias de red más allá de los valores necesarios y recomendados pueden hacer que las réplicas se retrasan constantemente.
Acceso administrativo y supervisión
¿Los datos Consola de administración están disponibles en las réplicas?
La Consola de administración no está disponible en réplicas pasivas ni en réplicas almacenadas en caché. Solo está disponible en réplicas activas (las réplicas activas reenvían la mayoría de las solicitudes a la principal).
¿Es posible usar SSH en réplicas?
Un operador con acceso al shell administrativo puede conectarse mediante SSH a cualquiera de las réplicas. Los operadores pueden agregar sus claves públicas a la nueva réplica a través de Consola de administración antes de agregar la réplica al clúster. Para más información, consulta Acceder al shell administrativo (SSH).
¿Cómo funcionan los paquetes de soporte para réplicas?
Puede generar una agrupación de clústeres o una agrupación específica del nodo. Un paquete de clústeres incluye paquetes de todos los nodos de la implementación de alta disponibilidad, mientras que un paquete específico del nodo contiene datos de un solo nodo.
¿Se pueden supervisar las réplicas y cómo?
Todas las réplicas se pueden supervisar. La Consola de administración en la instancia principal proporciona paneles para todos los nodos, incluidos los nodos de réplica pasiva y activa en la implementación.
Además, puede exportar métricas y registros de todos los nodos de una implementación a plataformas de supervisión de terceros.
Para obtener información sobre cómo supervisar el estado de la replicación de datos entre los nodos de réplica, consulte Supervisión de una configuración de alta disponibilidad.
Diferencia entre réplicas y copias de seguridad
¿Las réplicas y las copias de seguridad son las mismas?
Las réplicas y las copias de seguridad no son las mismas. Sirven para diferentes propósitos.
Las copias de seguridad se usan para crear copias de los datos que se pueden restaurar en otro entorno de GitHub Enterprise Server . Los clientes suelen usar copias de seguridad para recuperarse de desastres o crear nuevas instalaciones. En resumen, los datos de copia de seguridad se utilizan para restaurar otra instancia de GitHub Enterprise Server, mientras que las réplicas están diseñadas para garantizar alta disponibilidad y redundancia en tiempo real.
Las propias réplicas son instancias de GitHub Enterprise Server. El host de la copia de seguridad no es una instalación de GitHub Enterprise Server.
¿Qué software se ejecuta en réplicas?
Las réplicas son una instalación independiente de GitHub Enterprise Server. La instancia principal y todas las réplicas deberían estar ejecutando la misma versión de GitHub Enterprise Server.
Operaciones de mantenimiento
¿Cuál es la secuencia recomendada de operaciones para las actualizaciones?
- Inicie la ventana de mantenimiento en la instancia primaria y en todas las réplicas.
- Detenga la replicación en todas las réplicas.
- Actualice la principal a la versión de destino.
- Actualice las réplicas a la misma versión de destino. Todas las réplicas se pueden actualizar en paralelo.
- Una vez completadas todas las actualizaciones, reinicie el proceso de replicación.
- Cierre la ventana de mantenimiento.
En ocasiones, es posible que los clientes quieran posponer la actualización de réplicas a un momento posterior. En ese caso, quite el nodo de réplica de la implementación y conviértelo en un nodo independiente. Actualícelo a la misma versión que la principal y, a continuación, agréguela de nuevo a la implementación.
¿Cuál es la secuencia recomendada de operaciones para el almacenamiento en caliente?
La aplicación de revisiones en caliente se puede realizar con muy poca interrupción. Puede aplicar revisiones en caliente a la principal y, a continuación, a las réplicas.
Elección del tipo de réplica correcto
¿Cuándo usar réplicas pasivas?
Si necesita alta disponibilidad y desea que una instancia actualizada conmute por error en caso de que la principal deje de funcionar, las réplicas pasivas son la mejor opción. La mayoría de nuestros clientes usan réplicas pasivas.
¿Cuándo usar réplicas geográficas?
Si tiene un personal de desarrollador distribuido geográficamente, la configuración de réplicas geográficas puede ayudar a los usuarios en regiones específicas. Por ejemplo, imagine una empresa multinacional con equipos de ingeniería en Norteamérica, Europa y Asia. Si la instancia principal se encuentra en Estados Unidos, la implementación de una réplica geográfica en Europa puede mejorar significativamente el rendimiento de las operaciones de lectura para los usuarios europeos. Sin embargo, no se puede decir lo mismo para las operaciones de escritura. Todas las escrituras deben llegar tanto a las réplicas geográficas como a la principal antes de que se complete la operación. La distancia geográfica entre la primaria y las réplicas aumenta la latencia, lo que puede afectar a las operaciones de escritura.
¿Cuándo usar réplicas de caché?
Si los casos de uso son de lectura intensiva, como las granjas de CI, las réplicas almacenadas en caché son una mejor opción. Estos son algunos escenarios en los que las réplicas de caché tienen sentido:
- Una empresa con una pequeña oficina satélite en una región con ancho de banda limitado al centro de datos principal, donde los desarrolladores necesitan acceso más rápido a los repositorios, pero no requieren acceso de escritura.
- Una organización que ejecuta trabajos de CI/CD en un centro de datos remoto que necesita clonar repositorios con frecuencia y quiere minimizar el tráfico de red a la instancia principal.
Por diseño, las réplicas almacenadas en caché incluyen desventajas. Las réplicas almacenadas en caché son finalmente coherentes y no siempre sirven el contenido del repositorio más reciente. Sin embargo, existen webhooks que se activan cuando los cambios más recientes llegan a la réplica, permitiendo así que se lancen los trabajos de CI/CD correspondientes. Muy pocos GitHub los clientes usan réplicas de caché.