Étude de cas
InfrastructureModerniser un parc de load balancers sans interruption
Contexte
Acteur français de l’hébergement PaaS : le trafic des clients passe par un parc de load balancers open source, installés sur des VM réparties dans plusieurs régions, auxquels s’ajoutent des load balancers dédiés privés. Le parc s’était construit par ajouts successifs, et d’une VM à l’autre ni l’OS ni le moteur n’étaient à la même version. Résultat : chaque intervention demandait de réapprendre l’état de la machine sur laquelle on tombait.
Le défi
Mettre le parc à plat sans jamais couper le service : ramener toutes les VM, load balancers dédiés privés compris, sur une base identique, migrer région par région en commençant par les moins fréquentées, et se donner de quoi lire l’état des versions d’un coup d’œil plutôt qu’au détour d’un incident.
Hétérogénéité
Ni l’OS ni le load balancer n’étaient au même niveau d’une VM à l’autre. Deux machines remplissaient donc la même fonction avec deux comportements différents.
Pas de fenêtre de maintenance
Le parc porte du trafic client en continu. Impossible de réserver une plage de coupure : la migration devait se faire en place, sur des machines qui servent.
Ordre de migration
Commencer par les régions les moins fréquentées donne de la marge pour ajuster la procédure et mesurer les effets du changement. Les plus sollicitées passent en dernier, quand il n’y a plus rien à apprendre.
Visibilité
Sans état des versions consolidé, impossible de dire où en était la migration ni ce qu’il restait à traiter. Les tableaux de bord ne servaient pas qu’à piloter : ils devaient rester après.
L’approche
01 · La mise à plat
Une base commune pour tout le parc
L’objectif n’était pas d’ajouter des machines mais de faire converger celles qui existaient : le même OS et la même version du load balancer partout, load balancers dédiés privés compris. Une cible unique, pour que l’exploitation et les montées de version redeviennent prévisibles.
02 · Le déploiement
Des playbooks Ansible tenus à jour
Le parc se déploie par Ansible. Les playbooks ont été repris et maintenus pour que la cible s’applique à toutes les VM de la même façon : une région s’installe comme la précédente, sans commande particulière à retenir.
03 · L’ordre
Région par région, du moins fréquenté au plus fréquenté
La migration a été planifiée région par région, en partant des moins fréquentées : c’est là qu’on éprouve la procédure, qu’on corrige les playbooks et qu’on regarde ce que le changement produit sur du trafic réel. Les régions les plus sollicitées passent en dernier, une fois la mécanique déjà jouée ailleurs.
04 · La bascule
Sans indisponibilité, machine par machine
Le trafic sort de la machine pendant l’intervention, puis y revient une fois la nouvelle version en place. Les load balancers dédiés privés suivent le même chemin que le parc mutualisé. Aucune fenêtre de coupure n’a été demandée aux clients.
05 · Le suivi
Des tableaux de bord de versions
Un suivi consolidé des versions des composants, par VM et par région, construit sous Metabase : on voit l’avancement de la migration, ce qu’il reste à traiter, et l’écart entre deux machines se repère avant de devenir un incident. Ces tableaux de bord survivent à la migration, sans quoi le parc repart dans l’hétérogénéité.
Les résultats
Parc homogène
Toutes les VM sont passées sur la même base d’OS et de load balancer, load balancers dédiés privés compris.
Zéro coupure
La migration s’est faite région par région, machine par machine, sans indisponibilité de service.
MCO simplifiée
Une seule version à connaître et des playbooks qui s’appliquent partout : la maintenance courante ne se traite plus au cas par cas.
Fiabilité
Le parc a gagné en fiabilité : des machines identiques se comportent de la même façon, et un incident se diagnostique dans un contexte connu.
Évolutivité
Ajouter une région ou une VM revient à rejouer les playbooks, au lieu de reproduire à la main une installation particulière.
Versions sous contrôle
L’état des composants se lit sur un tableau de bord : l’hétérogénéité se voit, au lieu d’être découverte pendant un incident.
La stack
OS et moteur
- Exherbo Linux
- Sozu
Déploiement
- Ansible
- Ansible Molecule
- Git
Suivi
- Metabase