Haute disponibilite et scaling
La haute disponibilite GitLab se construit en distribuant les composants sur plusieurs noeuds et en eliminant les points de defaillance uniques. L'architecture se complexifie rapidement : HA GitLab est un projet d'infrastructure non trivial qui se justifie pour les organisations ayant une dependance critique sur la disponibilite de leur forge.
Composants a rendre HA
- PostgreSQL : Patroni (HA PostgreSQL gere par GitLab Omnibus) avec Consul pour la decouverte de service et PgBouncer pour le connection pooling
- Redis : Redis Sentinel (3 noeuds minimum) ou Redis Cluster
- Gitaly : Gitaly Cluster (Praefect) distribue les depots avec replication synchrone et failover automatique
- Puma + Sidekiq : plusieurs noeuds applicatifs derriere un load balancer
- Object Storage : naturellement redondant si on utilise S3 ou un Minio cluster
Gitaly Cluster (Praefect)
Praefect est le proxy devant les noeuds Gitaly. Il intercepte toutes les operations Git et les repercute sur les replicas. En cas de defaillance d'un noeud Gitaly, Praefect bascule automatiquement vers un replica. La replication peut etre synchrone (toutes les ecritures attendues sur tous les noeuds, plus lent) ou asynchrone (meilleure perf, risque de perte de donnees minimale en cas de crash).
Load balancing
Les noeuds applicatifs (Puma, Sidekiq, Workhorse) sont mis derriere un load balancer externe (HAProxy, NGINX, ou un load balancer cloud). Les sessions HTTP sont stateless (Redis gere les sessions), donc n'importe quel algorithme de load balancing fonctionne. Les connexions WebSocket (terminal web, notifications live) necessitent la persistance de session au niveau du LB.
GitLab sur Kubernetes
Le chart Helm officiel deploie GitLab sur Kubernetes avec tous ses composants. C'est l'approche la plus elastique : autoscaling des pods Puma et Sidekiq selon la charge. En contrepartie, c'est aussi l'approche la plus complexe a operer : le chart a des dizaines de parametres, les mises a jour necessitent une comprehension fine des dependances.
Compromis operationnels
La HA GitLab demande : plus de machines, plus de coordination operationnelle, des procedures de maintenance plus complexes, des competences sur Patroni, Consul et Gitaly Cluster. Le SLA cible doit justifier cet investissement. Pour beaucoup d'organisations, une bonne politique de backup + restauration rapide (RTO de quelques heures) est plus pertinente qu'une architecture HA a 3 noeuds.