Configuration de la réplication inter-clusters Elasticsearch pour la haute disponibilité

À propos de la réplication inter-clusters Elasticsearch

GitHub Enterprise Server utilise Elasticsearch pour assurer la recherche dans les tickets, les pull requests, les dépôts, ainsi que les pages Projets et Versions, et les compteurs affichés dans toute l’interface web. Étant donné que la recherche est essentielle au produit, la fiabilité d’Elasticsearch affecte directement l’administration quotidienne de votre instance.

Dans une configuration haute disponibilité(HA), GitHub Enterprise Server utilise un modèle leader/suiveur. L’appliance principale reçoit l’intégralité des écritures et du trafic, et les appliances de réplication demeurent synchronisées en tant que systèmes de secours en lecture seule pouvant prendre le relais si l’appliance principale tombe en panne. Pour plus d’informations, consultez « À propos de la configuration de la haute disponibilité ».

Dans les versions antérieures, Elasticsearch ne prenait pas directement en charge ce modèle leader/suiveur. Pour répliquer les données de recherche, GitHub Enterprise Server un seul cluster Elasticsearch a été exécuté, couvrant les appliances principales et de réplication. Cette approche a fonctionné, mais elle a introduit une classe de problèmes : Elasticsearch pouvait déplacer une partition principale (la partition responsable de la réception et de la validation des écritures) sur une appliance réplica. Si ce réplica était ensuite mis hors ligne pour maintenance, l’instance pouvait se retrouver dans un état verrouillé, car le réplica attendait qu’Elasticsearch revienne à un état sain, alors qu’Elasticsearch ne pouvait pas revenir à un état sain tant que le réplica n’avait pas réintégré le cluster.

Elasticsearch Cross-Cluster Replication (CCR) supprime cette dépendance. Au lieu d’un cluster couvrant chaque appliance, chaque appliance s’exécute en tant que cluster Elasticsearch à nœud unique indépendant. CCR réplique ensuite les données d’index entre ces clusters à l’aide d’un schéma leader/suiveur nativement pris en charge. Les données ne sont copiées qu’après avoir été enregistrées de manière durable dans les segments Lucene sous-jacents, de sorte que les répliques suivent toujours des données qui ont été écrites de façon fiable. Par conséquent, un shard primaire critique ne peut plus se retrouver coincé sur une réplique en lecture seule.

Benefits

Moins de mises à niveau verrouillées et de fenêtres de maintenance. La suppression de la dépendance circulaire entre les appliances principales et réplicas pendant la maintenance réduit le risque de blocage d’une instance.
Protection renforcée des données. Les données sont répliquées uniquement une fois qu’elles sont enregistrées durablement, ce qui permet d’empêcher la corruption d’index pendant les basculements.
Opérations plus simples. Ce modèle réduit le besoin de réparations manuelles de l’index, auparavant nécessaires lorsque les étapes de maintenance étaient effectuées dans le mauvais ordre.

Availability

Elasticsearch CCR est pris en charge à partir de GitHub Enterprise Server 3.19.1. La fonctionnalité est facultative. GitHub prévoit de faire de CCR l’architecture de recherche HA par défaut au cours des deux prochaines années, afin que vous ayez le temps de la tester et de faire part de vos commentaires avant qu’elle ne devienne l’architecture par défaut.

Requirements

Avant d’activer le CRC, confirmez ce qui suit.

Votre instance exécute GitHub Enterprise Server la version 3.19.1 ou ultérieure.
Votre instance est configurée pour la haute disponibilité avec au moins deux appliances (une appliance principale et une ou plusieurs répliques).
Vous disposez d’une licence GitHub Enterprise Server mise à jour qui inclut l’autorisation Elasticsearch requise pour CCR. Contactez L’équipe commerciale GitHub ou Support GitHub afin que votre entreprise soit activée avec la nouvelle licence, puis téléchargez le fichier de licence mis à jour.

Avertissement : Lorsque le CCR est activé, la vérification préalable à la mise à niveau nécessite une licence valide prenant en charge le CCR. Si l’indicateur est activé et que la vérification de la licence échoue, la mise à niveau ne se poursuit pas. Vérifiez que votre licence mise à jour est installée avant d’activer la fonctionnalité ou la mise à niveau. Si vous ne savez pas si votre licence inclut le droit Elasticsearch, contactez Support GitHub.

Activer la réplication entre clusters Elasticsearch

Note: La migration peut prendre beaucoup de temps en fonction de la taille de votre instance, car les données de recherche sont consolidées sur le serveur principal avant le redémarrage de la réplication. Planifiez d’abord l’activation du CRC pendant une fenêtre de maintenance et testez le processus dans un environnement hors production. Pour plus d’informations, consultez « Mise à niveau de votre instance ».

Contactez Support GitHub pour demander l’accès à la nouvelle architecture de recherche HA. GitHub active votre entreprise afin que vous puissiez télécharger la licence compatible avec le CCR requise.
Téléchargez votre licence mise à jour et chargez-la sur votre instance. Pour plus d’informations, consultez « Téléchargement de votre licence pour GitHub Entreprise ».
Sur l’appliance principale, activez la fonctionnalité.
```
ghe-config app.elasticsearch.ccr true
```
Appliquez la configuration en exécutant une exécution de configuration ou en mettant à niveau l’instance vers la version 3.19.1 ou ultérieure.
```
ghe-config-apply
```
Lorsque l’instance redémarre, Elasticsearch migre l’installation vers la nouvelle méthode de réplication. Cette migration consolide les données de recherche sur le nœud principal, met fin au cluster qui s’étendait auparavant sur plusieurs équipements et redémarre la réplication à l’aide de CCR. Pendant la migration, GitHub Enterprise Server attache des abonnés à vos index de recherche existants et active une règle de suivi automatique afin que tous les index créés à l’avenir soient suivis automatiquement.

Utiliser la réplication entre clusters d’Elasticsearch

Vérification de la réplication

Une fois la migration terminée, la recherche continue de fonctionner normalement et aucune modification n’est requise dans la façon dont les utilisateurs recherchent. Pour confirmer l’intégrité de la réplication, générez un bundle de support, qui inclut les informations d’état du CRC à examiner. Pour plus d’informations, consultez « Fourniture de données au support GitHub ».

Basculement et reprise après sinistre

Vous continuez à utiliser les utilitaires standard de réplication haute disponibilité pour gérer les réplicas et effectuer le basculement. Pour plus d’informations, consultez « Lancement d’un basculement vers votre appliance réplica » et « Récupération d’une configuration à haute disponibilité ».

Après un basculement avec CCR activé, l’appliance promue devient le nouveau leader pour la recherche, et les réplicas se remettent à suivre ses index dans le cadre du processus de récupération standard. Si vous rencontrez des erreurs liées à la réplication de la recherche pendant ou après un basculement, contactez Support GitHub.

Désactivation de la réplication entre clusters d’Elasticsearch

Avertissement : Ne désactivez pas CCR sur une instance de production sans les conseils de Support GitHub. La désactivation du CRC n’est pas une opération en libre-service courante. La désactivation de la fonctionnalité peut déclencher la suppression des données Elasticsearch réplica dans le cadre du retour au mode précédent.

Si vous devez revenir à l’architecture de recherche précédente, contactez Support GitHub avant d’apporter des modifications. GitHub vous aidera à confirmer que votre licence, l’état de réplication et le chemin de mise à niveau sont gérés en toute sécurité.