Acerca de las topologías de implementación para GitHub Enterprise Server
Puede implementar las máquinas virtuales de una instancia GitHub Enterprise Server en distintas topologías según el entorno y las necesidades de los usuarios.
-
Para respaldar un plan para la recuperación ante desastres y complementar las copias de seguridad, o para mejorar el rendimiento de red y escritura para los usuarios distribuidos geográficamente, puedes configurar una alta disponibilidad. En una configuración de alta disponibilidad, un nodo actúa como principal y los demás como réplicas. Para más información, consulta Acerca de la configuración de alta disponibilidad.
-
Para proporcionar escalado horizontal para entornos con decenas de miles de desarrolladores, hay disponible una topología de clúster. La agrupación en clústeres aborda situaciones en las que un único nodo principal experimentaría regularmente el agotamiento de recursos. Esta configuración conlleva una planeación cuidadosa y una sobrecarga administrativa adicional. GitHub trabajará con usted para determinar su idoneidad para la agrupación en clústeres. Para más información, consulta Acerca de las agrupaciones.
Escenarios de fallas
Tanto la alta disponibilidad (HA, por sus siglas en inglés) como la agrupación en clústeres brindan redundancia al eliminar el nodo único como punto de error. Pueden brindar disponibilidad en estos escenarios:
- Bloqueos de software, ya sea debido a un error del sistema operativo o a aplicaciones irrecuperables.
- Errores de hardware, incluido hardware de almacenamiento, CPU, RAM, interfaces de red, etc.
- Errores del sistema del host de virtualización, que incluyen eventos de mantenimiento programado y no planeado para AWS, Azure, or GCP.
- Cortes lógicos o físicos en la red, si el dispositivo de conmutación por error está en una red independiente a la que no le afecta el error.
Escalabilidad
La agrupación proporciona una mejor escalabilidad al distribuir la carga en múltiples nodos. Este escalado horizontal puede ser conveniente para algunas organizaciones con decenas de miles de programadores. En HA, el escalado del appliance depende exclusivamente del nodo principal y la carga no se distribuye al servidor réplica.
Diferencias en el método de conmutación por falla y configuración
| Característica | Configuración de conmutación | Método de conmutación por error |
|---|---|---|
| Configuración de alta disponibilidad | Registro de DNS con un TTL bajo que apunta al aparato principal o balanceador de carga. | Debes impulsar manualmente el aparato de réplica en las configuraciones de conmutación DNS y balanceador de carga. |
| Agrupación en clústeres | El registro DNS debe apuntar a un balanceador de carga. | Si falla un nodo detrás de un balanceador de carga, el tráfico se envía automáticamente a los otros nodos de funcionamiento. |
Copia de seguridad y recuperación ante desastres
Ni la alta disponibilidad ni la agrupación en clústeres debe considerarse como un reemplazo de las copias de seguridad habituales. Para más información, consulta Configuración de copias de seguridad en la instancia con utilidades de copia de seguridad.
Supervisión
Las características de disponibilidad, especialmente las que tienen conmutación automática por error como la agrupación en clústeres, pueden enmascarar un error dado que el servicio generalmente no se ve interrumpido aunque se produzca algún error. Tanto si estás usando alta disponibilidad como agrupación en clústeres, supervisar el estado de cada instancia es importante para que puedas estar al tanto cuando se produce un error. Para más información sobre la supervisión, consulta Límites de alerta recomendados y Supervisión del estado del clúster.