Gestion de serveurs : comment LinkedIn est passé à l'échelle
Publié par Clément Bohic le - mis à jour à
LinkedIn évoque le développement de son approche « Metal as a Service », qui gouverne aujourd'hui la gestion de ses serveurs sur site.
Comment éviter les échecs en cas d'indisponibilité de la console IPMI ? LinkedIn travaille sur des options de contournement dans le cadre de son approche « Metal as a Service » (MaaS).
Celle-ci gouverne aujourd'hui la gestion des serveurs sur site de l'entreprise. Une tâche désormais dévolue aux SRE, et non plus à l'équipe d'ingénieurs de production.
Avant MaaS, Jira était le centre de gravité. Les démarches de mise à jour des serveurs passaient par des tickets... et donc une délégation aux ingés en question. Cela induisait des temps de latence autant pour isoler les problèmes que pour les traiter.
Donner la main aux SRE a impliqué de leur fournir un outil auquel ils pourraient accéder directement. Il en existait bien un, mais l'activation était manuelle et supposait des prérequis. Une solution était d'en exposer les fonctionnalités (upgrade, redémarrage, effacement de disque, décommissionnement...) par API. LinkedIn souhaitait par ailleurs introduire un traitement en lots.
Il a été décidé de donner accès à l'API via une application Flask gérée avec systemd, Active Directory assurant l'association et l'authentification des utilisateurs. On a alors mis en place divers points de terminaison pour, entre autres, obtenir des statistiques sur l'exécution des requêtes, annuler des lots et évaluer le nombre d'upgrades en cours sur l'ensemble du parc. On y a ajouté une couche d'alerting sur la base d'un outil maison (Iris) associé à un bus interne évitant de passer systématiquement par l'API.
Authentification, redondance, cohérence... Les limites du MVP
À l'origine, le déploiement était monoserveur, avec une base PostgreSQL et un cache Redis. Les échanges se faisaient sur HTTP. Les requêtes validées redescendaient vers l'outil AutoBuild, qui pouvait réaliser les opérations demandées.
Effectuer ces opérations exigeait les authentifiants adéquats. Solution retenue : les placer dans un magasin GPG interne sur lequel un ingénieur devait s'identifier à chaque redémarrage du service.
Dans un tel déploiement, les workers fonctionnent en tandem sans partager de mémoire ni de connexions à la base SQL. Il est d'autant plus délicat d'assurer la cohérence des données pour que soient correctement détectés les chevauchements de requêtes (LinkedIn avait, par exemple, ajouté un contrôle invalidant un lot si au moins un des hôtes se trouvait déjà dans un autre batch).
Dans ce contexte, MaaS n'a pu, initialement, traiter qu'une requête à la fois, avec un délai de 2 minutes entre chacune. La question du HTTP restait à résoudre ; la gestion des authentifiants, à améliorer. La disponibilité aussi : à ce stade, pas de redondance, aussi bien au niveau global qu'au niveau des dépendances.
Kafka, KMS interne, MySQL managé : les choix de LinkedIn
Dans les grandes lignes, LinkedIn a opté pour un découplage de la détection des chevauchements. Il a levé les limites de requêtes sur l'API et instauré une file d'attente reposant sur Kafka.
Pour assurer une redondance en actif-actif entre plusieurs datacenters, on a choisi une conception de type mutex. Avec un datastore relationnel comme « source de vérité » et un verrouillage au niveau des lignes pour garantir l'isolation.
Pour équilibrer le trafic, on a envisagé HAProxy... puis écarté l'option, qui aurait requis de déployer des noeuds supplémentaires. On n'a pas non plus retenu le combo « IP virtuelle + ucarp », la version expérimentée exigeant que tous les hôtes rattachés à l'IP soient sur le même sous-réseau. L'élu fut finalement un service interne de proxy : DNSDisco.
En parallèle, les authentifiants ont été migrés vers un KMS interne, avec une ACL et une interface REST, ouvrant la voie à des déploiements « en un clic ». LinkedIn a en outre activé mTLS en complément à l'authentification Active Directory.
Illustration principale © itchaznong - Adobe Stock