doc-locale/fr-fr/administration/geo/replication/multiple_servers.md
{{< details >}}
{{< /details >}}
Ce document décrit une architecture de référence minimale pour l'exécution de Geo dans une configuration multi-nœuds. Si votre configuration multi-nœuds diffère de celle décrite, il est possible d'adapter ces instructions à vos besoins.
Ce guide s'applique aux installations avec plusieurs nœuds d'application (Sidekiq ou GitLab Rails). Pour les installations à nœud unique avec PostgreSQL externe, suivez Configurer Geo pour deux sites à nœud unique (avec des services PostgreSQL externes), et adaptez votre configuration si vous utilisez d'autres services externes.
source du diagramme - membres de l'équipe GitLab uniquement
Le diagramme de topologie suppose que les sites Geo principal et secondaire sont situés dans deux emplacements distincts, sur leur propre réseau virtuel avec des adresses IP privées. Le réseau est configuré de telle sorte que toutes les machines dans un emplacement géographique peuvent communiquer entre elles en utilisant leurs adresses IP privées. Les adresses IP indiquées sont des exemples et peuvent être différentes selon la topologie réseau de votre déploiement.
La seule façon externe d'accéder aux deux sites Geo est via HTTPS sur gitlab.us.example.com et gitlab.eu.example.com dans l'exemple précédent.
[!note] Les sites Geo principal et secondaire doivent pouvoir communiquer entre eux via HTTPS.
En raison de la complexité supplémentaire liée à la configuration de cette configuration pour PostgreSQL et Redis, elle n'est pas couverte par cette documentation Geo multi-nœuds.
Pour plus d'informations sur la configuration d'un cluster PostgreSQL multi-nœuds et d'un cluster Redis à l'aide du package Linux, voir :
[!note] Il est possible d'utiliser des services hébergés dans le cloud pour PostgreSQL et Redis, mais cela dépasse la portée de ce document.
Un site GitLab sert de site Geo principal. Utilisez la documentation sur les architectures de référence GitLab pour effectuer cette configuration. Vous pouvez utiliser différentes tailles d'architecture de référence pour chaque site Geo. Si vous disposez déjà d'une instance GitLab fonctionnelle en cours d'utilisation, elle peut être utilisée comme site principal.
Le deuxième site GitLab sert de site Geo secondaire. Là encore, utilisez la documentation sur les architectures de référence GitLab pour effectuer cette configuration. Il est conseillé de vous connecter et de le tester. Toutefois, sachez que ses données sont effacées dans le cadre du processus de réplication depuis le site principal.
Les étapes suivantes permettent à un site GitLab de servir de site Geo principal.
[!note] N'utilisez pas
geo_primary_role, car il est destiné à un site à nœud unique.
Modifiez /etc/gitlab/gitlab.rb et ajoutez ce qui suit :
##
## The unique identifier for the Geo site. See
## https://docs.gitlab.com/administration/geo_sites/#common-settings
##
gitlab_rails['geo_node_name'] = '<site_name_here>'
##
## Disable automatic migrations
##
gitlab_rails['auto_migrate'] = false
Après avoir effectué ces modifications, reconfigurez GitLab pour que les modifications prennent effet.
Exécutez la commande suivante sur l'un des nœuds frontend :
sudo gitlab-ctl set-geo-primary-node
[!note] PostgreSQL et Redis doivent déjà avoir été désactivés sur les nœuds d'application lors de la configuration typique de GitLab multi-nœuds. Les connexions des nœuds d'application aux services sur les nœuds backend doivent également avoir été configurées. Consultez la documentation sur la configuration multi-nœuds pour PostgreSQL et Redis.
Un site secondaire est similaire à tout autre site GitLab multi-nœuds, avec trois différences majeures :
geo-logcursorPar conséquent, nous configurons les composants multi-nœuds un par un et incluons les déviations par rapport à la configuration multi-nœuds standard. Cependant, nous recommandons vivement de configurer d'abord un tout nouveau site GitLab, comme s'il ne faisait pas partie d'une configuration Geo. Cela permet de vérifier qu'il s'agit d'un site GitLab fonctionnel. Et ce n'est qu'ensuite qu'il doit être modifié pour être utilisé comme site Geo secondaire. Cela aide à distinguer les problèmes de configuration Geo des problèmes de configuration multi-nœuds sans rapport.
Configurez les services suivants, en utilisant à nouveau la documentation multi-nœuds non-Geo :
[!note] NFS peut être utilisé à la place de Gitaly, mais n'est pas recommandé.
La base de données de suivi Geo ne peut pas être exécutée dans un cluster PostgreSQL multi-nœuds, voir Configuration du cluster Patroni pour la base de données PostgreSQL de suivi.
Vous pouvez exécuter la base de données de suivi Geo sur un seul nœud comme suit :
Générez un hash MD5 du mot de passe souhaité pour l'utilisateur de base de données que l'application GitLab utilise pour accéder à la base de données de suivi :
Le nom d'utilisateur (gitlab_geo par défaut) est incorporé dans le hash.
gitlab-ctl pg-password-md5 gitlab_geo
# Enter password: <your_tracking_db_password_here>
# Confirm password: <your_tracking_db_password_here>
# fca0b89a972d69f00eb3ec98a5838484
Utilisez ce hash pour renseigner <tracking_database_password_md5_hash> à l'étape suivante.
Sur la machine sur laquelle la base de données de suivi Geo est destinée à s'exécuter, ajoutez ce qui suit à /etc/gitlab/gitlab.rb :
##
## Enable the Geo secondary tracking database
##
geo_postgresql['enable'] = true
geo_postgresql['listen_address'] = '<ip_address_of_this_host>'
geo_postgresql['sql_user_password'] = '<tracking_database_password_md5_hash>'
##
## Configure PostgreSQL connection to the replica database
##
geo_postgresql['md5_auth_cidr_addresses'] = ['<replica_database_ip>/32']
gitlab_rails['db_host'] = '<replica_database_ip>'
# Prevent reconfigure from attempting to run migrations on the replica database
gitlab_rails['auto_migrate'] = false
Désactivez les mises à niveau automatiques de PostgreSQL pour éviter tout temps d'arrêt involontaire lors de la mise à niveau de GitLab. Tenez compte des mises en garde connues lors de la mise à niveau de PostgreSQL avec Geo. En particulier pour les environnements plus importants, les mises à niveau de PostgreSQL doivent être planifiées et exécutées de manière réfléchie. En conséquence et à l'avenir, assurez-vous que les mises à niveau de PostgreSQL font partie des activités de maintenance régulières.
Après avoir effectué ces modifications, reconfigurez GitLab pour que les modifications prennent effet.
Si vous utilisez une instance PostgreSQL externe, référez-vous également à Geo avec des instances PostgreSQL externes.
Suivez les instructions de réplication de base de données Geo.
Si vous utilisez une instance PostgreSQL externe, référez-vous également à Geo avec des instances PostgreSQL externes.
Après avoir activé la réplication en continu, gitlab-rake db:migrate:status:geo échoue jusqu'à ce que la configuration du site secondaire soit terminée, notamment Configuration Geo - Étape 3. Ajouter le site secondaire.
[!note] N'utilisez pas
geo_secondary_role, car il est destiné à un site à nœud unique.
Dans le schéma d'architecture minimal, deux machines exécutent les services d'application GitLab. Ces services sont activés sélectivement dans la configuration.
Configurez les nœuds d'application GitLab Rails en suivant les étapes pertinentes décrites dans les architectures de référence, puis effectuez les modifications suivantes :
Modifiez /etc/gitlab/gitlab.rb sur chaque nœud d'application du site Geo secondaire, et ajoutez ce qui suit :
##
## Enable GitLab application services. The application_role enables many services.
## Alternatively, you can choose to enable or disable specific services on
## different nodes to aid in horizontal scaling and separation of concerns.
##
roles ['application_role']
## `application_role` already enables this. You only need this line if
## you selectively enable individual services that depend on Rails, like
## `puma`, `sidekiq`, `geo-logcursor`, and so on.
gitlab_rails['enable'] = true
##
## Enable Geo Log Cursor service
##
geo_logcursor['enable'] = true
##
## The unique identifier for the Geo site. See
## https://docs.gitlab.com/administration/geo_sites/#common-settings
##
gitlab_rails['geo_node_name'] = '<site_name_here>'
##
## Disable automatic migrations
##
gitlab_rails['auto_migrate'] = false
##
## Configure the connection to the tracking database
##
geo_secondary['enable'] = true
geo_secondary['db_host'] = '<geo_tracking_db_host>'
geo_secondary['db_password'] = '<geo_tracking_db_password>'
##
## Configure connection to the streaming replica database, if you haven't
## already
##
gitlab_rails['db_host'] = '<replica_database_host>'
gitlab_rails['db_password'] = '<replica_database_password>'
##
## Configure connection to Redis, if you haven't already
##
gitlab_rails['redis_host'] = '<redis_host>'
gitlab_rails['redis_password'] = '<redis_password>'
##
## If you are using custom users not managed by Omnibus, you need to specify
## UIDs and GIDs like below, and ensure they match between nodes in a
## cluster to avoid permissions issues
##
user['uid'] = 9000
user['gid'] = 9000
web_server['uid'] = 9001
web_server['gid'] = 9001
registry['uid'] = 9002
registry['gid'] = 9002
[!warning] Si vous avez configuré le cluster PostgreSQL à l'aide du package Linux et avez défini
postgresql['sql_user_password'] = 'md5 digest of secret', gardez à l'esprit quegitlab_rails['db_password']etgeo_secondary['db_password']contiennent les mots de passe en clair. Ces configurations sont utilisées pour permettre aux nœuds Rails de se connecter aux bases de données.
Assurez-vous que l'adresse IP du nœud actuel est répertoriée dans le paramètre postgresql['md5_auth_cidr_addresses'] de la base de données réplica en lecture afin de permettre à Rails sur ce nœud de se connecter à PostgreSQL.
Après avoir effectué ces modifications, reconfigurez GitLab pour que les modifications prennent effet.
Dans la topologie de présentation de l'architecture, les services GitLab suivants sont activés sur les nœuds « frontend » :
geo-logcursorgitlab-pagesgitlab-workhorselogrotatenginxregistryremote-syslogsidekiqpumaVérifiez l'existence de ces services en exécutant sudo gitlab-ctl status sur les nœuds d'application frontend.
Le schéma d'architecture minimal montre un répartiteur de charge à chaque emplacement géographique pour acheminer le trafic vers les nœuds d'application.
Voir Répartiteur de charge pour GitLab avec plusieurs nœuds pour plus d'informations.
Le schéma d'architecture minimal montre tous les services d'application s'exécutant ensemble sur les mêmes machines. Cependant, pour plusieurs nœuds, nous recommandons vivement d'exécuter tous les services séparément.
Par exemple, un nœud Sidekiq pourrait être configuré de manière similaire aux nœuds d'application frontend documentés précédemment, avec quelques modifications pour n'exécuter que le service sidekiq :
Modifiez /etc/gitlab/gitlab.rb sur chaque nœud Sidekiq du site Geo secondaire, et ajoutez ce qui suit :
##
## Enable the Sidekiq service
##
sidekiq['enable'] = true
gitlab_rails['enable'] = true
##
## The unique identifier for the Geo site. See
## https://docs.gitlab.com/administration/geo_sites/#common-settings
##
gitlab_rails['geo_node_name'] = '<site_name_here>'
##
## Disable automatic migrations
##
gitlab_rails['auto_migrate'] = false
##
## Configure the connection to the tracking database
##
geo_secondary['enable'] = true
geo_secondary['db_host'] = '<geo_tracking_db_host>'
geo_secondary['db_password'] = '<geo_tracking_db_password>'
##
## Configure connection to the streaming replica database, if you haven't
## already
##
gitlab_rails['db_host'] = '<replica_database_host>'
gitlab_rails['db_password'] = '<replica_database_password>'
##
## Configure connection to Redis, if you haven't already
##
gitlab_rails['redis_host'] = '<redis_host>'
gitlab_rails['redis_password'] = '<redis_password>'
##
## If you are using custom users not managed by Omnibus, you need to specify
## UIDs and GIDs like below, and ensure they match between nodes in a
## cluster to avoid permissions issues
##
user['uid'] = 9000
user['gid'] = 9000
web_server['uid'] = 9001
web_server['gid'] = 9001
registry['uid'] = 9002
registry['gid'] = 9002
Vous pouvez de même configurer un nœud pour n'exécuter que le service geo-logcursor avec geo_logcursor['enable'] = true et désactiver Sidekiq avec sidekiq['enable'] = false.
Ces nœuds n'ont pas besoin d'être rattachés au répartiteur de charge.