Types et fonctionnalités de réplication
Quels sont les différents types de répliques employés dans un déploiement HA ?
Il existe trois types de réplicas dans un déploiement haute disponibilité (HA) :
-
Répliques passives
-
Réplique active
-
Réplicas de cache (appelés caches de référentiel).
**Les réplicas passifs** synchronisent simplement les données de l’instance principale et ne gèrent aucun GitHub trafic. Toutefois, les opérateurs peuvent promouvoir une réplique passive en réplique primaire lorsque cela s’avère nécessaire.
Un réplica géographique est un exemple de réplica actif (ces termes sont souvent utilisés de façon interchangeable). Les répliques actives synchronisent les données à partir de la réplique principale. Un réplica actif peut également traiter directement le trafic de GitHub ou le transmettre au serveur principal.
**Les réplicas de cache** synchronisent simultanément les données Git et Git Large File Storage (Git LFS) depuis le nœud primaire. Les répliques de cache sont destinées aux environnements caractérisés par un volume élevé de lectures, tels que les fermes CI. Elles n’autorisent que les opérations de lecture, de récupération ou de clonage pour les référentiels dont elles possèdent une copie locale. Pour tous les autres référentiels, ils retournent une erreur. Elles refusent systématiquement les pushes en renvoyant un message d’échec.
Tous les types de répliques peuvent-ils être promus au statut de réplique principale ?
Seuls les réplicas passifs et actifs peuvent être promus en réplica principal. Les répliques de cache ne peuvent pas être promues en réplique principale.
Est-ce qu'un seul déploiement peut avoir tous les réplicas ?
Un déploiement unique peut inclure des répliques actives, des répliques passives et des répliques de cache simultanément.
L’instance principale attend-elle que les réplicas se synchronisent avant d’effectuer les écritures ?
L’instance principale n’attend pas les réplicas pour les opérations d'écriture. Dans une architecture HA, une push est transmise vers la réplique principale ainsi que vers toutes les répliques passives et actives. Toutefois, comme le nœud principal constitue l’unique nœud votant, la push est considérée comme acceptée dès lors qu’elle réussit sur la réplique principale.
Configuration requise pour la communication et le réseau
Quelles entités peuvent communiquer avec les répliques actives ?
L'instance principale communique avec les répliques actives pour synchroniser les données et gérer les requêtes que celles-ci transmettent à l'instance principale. GitHub Web, API et Git (provenant aussi bien d’utilisateurs que d’automatisations) peut être dirigé directement vers les répliques actives. C’est pourquoi il est important de configurer DNS afin que le trafic destiné à un réplica actif l’atteigne réellement.
Quelles entités peuvent communiquer avec des réplicas passifs ?
L’instance principale communique avec les réplicas passifs pour synchroniser les données. Les réplicas passifs ne reçoivent ni ne traitent aucun autre trafic de GitHub.
Quelles entités peuvent communiquer avec les réplicas de cache ?
Le trafic Git en lecture seule, provenant majoritairement d’automatisations telles que les fermes CI, peut être acheminé vers les répliques de cache et traité par celles-ci. Pour l’activer, vous devez configurer votre DNS pour diriger le trafic approprié vers le réplica du cache. Les répliques de cache ne sont pas conçues pour gérer le trafic utilisateur ni le trafic de transmission.
Les répliques doivent-elles être colocalisées avec la réplique principale ?
La colocalisation des répliques avec le primaire n’est pas obligatoire. Par définition, une réplique géographique se situe à distance du primaire et n’est pas hébergée dans le même centre de données. Les répliques de cache ne comportent pas non plus d’exigence de colocalisation.
Il est toutefois recommandé qu’au moins une réplique passive soit colocalisée avec le primaire dans le même centre de données afin de réduire le délai de basculement en cas de défaillance du primaire. En cas de panne complète du centre de données, il est possible de promouvoir une réplique passive distribuée géographiquement.
Quelles sont les exigences de latence entre le serveur principal et les répliques ?
Le serveur principal et les répliques actives doivent respecter des contraintes strictes de latence. Entre le serveur principal et les répliques passives, ainsi qu’entre le serveur principal et les répliques de cache, des recommandations de latence sont également définies. Pour plus d’informations, consultez « Création d’une réplique à haute disponibilité » et « Surveillance d’une configuration de haute disponibilité ». Des latences réseau supérieures aux valeurs requises et recommandées peuvent entraîner un retard constant des réplicas.
Accès administratif et surveillance
La Management Console est-elle disponible sur les répliques ?
La variable Management Console n’est disponible ni sur les répliques passives ni sur les répliques de cache. Elle est accessible uniquement sur les répliques actives (celles-ci redirigeant la majorité des requêtes vers le primaire).
Est-il possible de se connecter en SSH à des répliques ?
Un opérateur disposant d'un accès administrateur via le shell peut se connecter en SSH à l'un des réplicas. Les opérateurs peuvent ajouter leurs clés publiques à la nouvelle réplique via Management Console avant que la réplique ne soit intégrée au cluster. Pour plus d’informations, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».
Comment fonctionnent les bundles de support pour les réplicas ?
Vous pouvez générer un bundle de cluster ou un bundle spécifique au nœud. Un ensemble de clusters inclut des bundles de tous les nœuds du déploiement haute disponibilité, tandis qu’un bundle spécifique au nœud contient des données d’un seul nœud.
Les réplicas peuvent-ils être surveillés et comment ?
Toutes les répliques peuvent être surveillées. La variable Management Console sur l’instance primaire fournit des tableaux de bord pour l’ensemble des nœuds, y compris les nœuds de réplique passifs et actifs du déploiement.
En outre, vous pouvez exporter des métriques et des journaux à partir de tous les nœuds d’un déploiement vers des plateformes de supervision tierces.
Pour savoir comment surveiller l’état de la réplication des données entre les nœuds de réplica, consultez Surveillance d’une configuration de haute disponibilité.
Différence entre les réplicas et les sauvegardes
Les réplicas et les sauvegardes sont-ils identiques ?
Les réplicas et les sauvegardes ne sont pas identiques. Ils servent des objectifs différents.
Les sauvegardes sont utilisées pour créer des copies de vos données qui peuvent être restaurées dans un autre environnement GitHub Enterprise Server. Les clients utilisent souvent des sauvegardes pour récupérer des sinistres ou créer de nouvelles installations. En bref, les données de sauvegarde sont utilisées pour restaurer une autre instance de GitHub Enterprise Server, tandis que les répliques sont conçues pour la haute disponibilité et la redondance en temps réel.
Les répliques sont elles-mêmes des instances GitHub Enterprise Server. Backup-host ne constitue pas une installation GitHub Enterprise Server.
Quel logiciel s’exécute-t-il sur des réplicas ?
Les répliques correspondent à une installation distincte de GitHub Enterprise Server. L’instance principale et toutes les répliques doivent utiliser la même version de GitHub Enterprise Server.
Opérations de maintenance
Quelle est la séquence recommandée d’opérations pour les mises à niveau ?
- Activez la fenêtre de maintenance sur l’instance principale ainsi que sur toutes les répliques.
- Arrêtez la réplication sur tous les réplicas.
- Migrez la version principale vers la version cible.
- Mettez à niveau les réplicas vers la même version cible. Toutes les répliques peuvent être mises à niveau en parallèle.
- Une fois toutes les mises à niveau terminées, redémarrez le processus de réplication.
- Fermez la fenêtre de maintenance.
Parfois, les clients peuvent souhaiter reporter la mise à niveau des réplicas vers une date ultérieure. Dans ce cas, supprimez le nœud de réplica du déploiement et convertissez-le en nœud autonome. Mettez-le à niveau vers la même version que le serveur principal, puis ajoutez-le au déploiement.
Quelle est la séquence d'opérations recommandée pour le hotpatching ?
Le correctif à chaud peut être appliqué avec des perturbations minimales. Vous pouvez d’abord appliquer le correctif à chaud sur l’instance principale, puis sur les répliques.
Choix du type de réplica approprié
Quand utiliser des réplicas passifs ?
Si vous recherchez une haute disponibilité et souhaitez disposer d’une instance actualisée vers laquelle basculer en cas de défaillance de l’instance principale, les répliques passives constituent la solution appropriée. La plupart de nos clients utilisent des répliques passives.
Quand utiliser des réplicas géographiques ?
Si vous disposez d’une main-d’œuvre de développeur géographiquement distribuée, la configuration de réplicas géographiques peut aider les utilisateurs dans des régions spécifiques. Par exemple, imaginez une entreprise multinationale avec des équipes d’ingénierie en Amérique du Nord, en Europe et en Asie. Si l’instance principale se trouve aux États-Unis, le déploiement d’un géoréplica en Europe peut améliorer considérablement les performances des opérations de lecture pour les utilisateurs européens. Toutefois, la même chose ne peut pas être dite pour les opérations d’écriture. Toutes les écritures doivent être enregistrées simultanément sur les répliques géographiques et sur l’instance principale avant la finalisation de l’opération. La distance géographique entre le primaire et les réplicas augmente la latence, ce qui peut ralentir les opérations d'écriture.
Quand utiliser des réplicas de cache ?
Lorsque les usages impliquent un volume important de lectures, comme dans les fermes CI, les répliques de cache s’avèrent plus adaptées. Voici quelques scénarios dans lesquels les répliques de cache présentent un intérêt.
- Une entreprise disposant d’un petit bureau satellite dans une région avec une bande passante limitée au centre de données principal, où les développeurs ont besoin d’un accès plus rapide aux référentiels, mais ne nécessitent pas d’accès en écriture.
- Une organisation exécutant des travaux CI/CD dans un centre de données distant qui doit cloner fréquemment des référentiels et souhaite réduire le trafic réseau vers l’instance principale.
Par conception, les répliques de cache impliquent certains compromis. Les répliques de cache présentent une cohérence éventuelle et ne garantissent pas toujours l’accès à la version la plus récente du référentiel. Des webhooks sont toutefois déclenchés lorsque les dernières modifications sont enregistrées sur la réplique, ce qui permet de lancer les tâches CI/CD correspondantes. Très peu de clients GitHub utilisent des réplicas de cache.