Comment LinkedIn a modernisé l’infra LDAP de son cluster Hadoop
En l’absence d’environnement de test, autant construire un nouveau cluster plutôt que d’adapter l’ancien.
LinkedIn a suivi ce raisonnement dans le cadre de la modernisation de l’infrastructure LDAP-Kerberos sécurisant sa plate-forme Hadoop.
La démarche a eu pour contexte une migration massive vers Azure Linux, qui a remplacé CentOS 7 (voir notre article à ce sujet).
Un socle 389 Directory Server
Le cluster Hadoop de LinkedIn réunit aujourd’hui environ 10 milliards d’objets. Sa taille avoisine les 5 exaoctets. L’infrastructure LDAP-Kerberos qui lui est adossée a son propre cluster. Les deux briques sont cohébergées pour éviter les appels réseau. La première, fondée sur des serveurs 389-ds, sert de data store à la seconde.
L’ensemble gère environ 1 million de requêtes par minute, pour trois grands cas d’usage :
- Stocker les principaux Kerberos du périmètre Hadoop
- Effectuer les recherches d’utilisateurs et de groupes sur les hôtes Linux du cluster Hadoop
- Alimenter le plan de contrôle HDFS pour mettre en œuvre les permissions d’accès aux fichiers
Divers points de défaillance unique dans l’ancienne infra
Dans l’ancienne configuration, l’infra LDAP-Kerberos se répartissait sur 2 datacenters. Un cluster comprenait :
- Des instances primaires gérant les opérations d’écriture
- Des workers gérant les opérations de lecture
- Des hubs gérant la réplication des données des instances primaires vers les workers
Le trafic en écriture était dirigé vers une instance primaire dans un datacenter, lequel répliquait les transactions vers une instance primaire dans l’autre datacenter.
Chaque datacenter hébergeait un hub et plusieurs workers en scale-out. L’équilibrage de la charge entre les workers était assurée par HAProxy. Les clients accédaient à l’annuaire via une URL qui résolvait les adresses IP de 4 instances HAProxy en utilisant un DNS round-robin.
Ce système présentait des limites :
- Points de défaillance unique au niveau des instances primaires (risque d’échec des écritures lorsque l’une d’elles tombe) et des hubs (risque de désynchronisation des workers)
- Activités de maintenance complexifiées par ces points de défaillance
- Instances paramétrées manuellement à l’aide d’un savoir informel
- Absence d’environnement de test
- Cluster utilisant RHEL/CentOS, que LinkedIn avait presque entièrement abandonné
LinkedIn adopte une topologie en étoile
Pour éliminer les points de défaillance unique, 4 instances primaires ont été configurées en étoile. Deux dans chaque datacenter, chacune répliquant vers et depuis toutes les autres. Cette architecture favorise la maintenance, ainsi que le basculement d’un datacenter à l’autre.
Chaque datacenter héberge 3 hubs. Tous réceptionnent le trafic de réplication de l’ensemble des instances primaires (pas seulement celles situées dans le même datacenter). Ils peuvent ensuite répliquer vers tous les workers de leur datacenter respectif.
Pour le trafic en lecture, LinkedIn n’a pas effectué de changements majeurs. La répartition se fait toutefois désormais à l’appui de 8 instances HAProxy (4 dans chaque datacenter).
Éviter les conflits en écriture : l’astuce CNAME
Le modèle de cohérence de LDAP proscrivait tout acheminement du trafic en écriture vers plusieurs instances primaires en simultané (risque de conflits). L’option backup de HAProxy donc a été envisagée pour le diriger systématiquement vers la même instance primaire et ne basculer vers une autre qu’en cas d’indisponibilité. Elle n’a cependant pas été retenue vu la délicatesse de faire fonctionner un serveur d’annuaire sécurisé par GSS-API (authentification Kerberos pour LDAP lui-même) derrière un load balancer.
Lorsqu’un client utilise GSS-API pour accéder à un serveur d’annuaire, il s’appuie sur un principal de service qui inclut le nom DNS du service. Ce nom, il l’obtient par une recherche inversée sur l’adresse IP finale détectée pour le serveur d’annuaire.
Pour que l’authentification du client réussisse, le serveur doit avoir un keytab qui contient le principal de service en question. Le problème pour LinkedIn a été que le client utilise le nom DNS du load balancer dans le principal de service, et qu’il utilise ce load balancer en tant que proxy. Le nom DNS du load balancer doit donc être présent dans le keytab.
Ce n’est pas problématique tant qu’on peut faire en sorte que la recherche DNS inversée pour toutes les adresses IP d’instances du load balancer résolve le même nom. Ce n’était pas possible avec le système de découverte de services par DNS mis en place chez LinkedIn.
Il a donc été décidé d’utiliser un CNAME pointant vers l’instance primaire voulue. Pour gérer les actions de maintenance et les incidents, il fallait un mécanisme automatisé par lequel ce CNAME serait « basculé » vers une autre instance primaire. LinkedIn l’a concrétisé avec un service externe qui contrôle en continu les ports kadmind (749) et ldaps (636) et bascule si nécessaire en mettant à jour le DNS.
Standardiser pour automatiser
Pour simplifier davantage la maintenance, LinkedIn a migré cette infrastructure LDAP-Kerberos sur sa stack de déploiement standardisée. Les deux composantes y ont été définies comme services, avec des commandes de contrôle utilisées par l’agent de déploiement. Cela a permis d’automatiser des tâches comme la création d’index LDAP, le paramétrage de la réplication et le rafraîchissement des certificats TLS.
La réplication est intégrée dans la commande « start » pour le service LDAP. Elle découvre automatiquement les fournisseurs pour une instance donnée en s’appuyant sur la topologie de déploiement. Ainsi, un worker tentera de découvrir les hubs situés dans le même datacenter que lui, puis de négocier avec eux des accords de réplication. Une fois la jonction établie, le fournisseur pousse régulièrement les changements vers le consommateur, de manière incrémentale.
Deux tâches cron pour superviser les workers
LinkedIn a construit un cluster de test et un cluster de préprod, ce dernier étant intégré à un CI/CD pour effectuer les tests d’intégration.
La migration a démarré par le trafic en lecture (le plus simple à gérer grâce à l’usage existant de HAProxy). Pour s’assurer que les workers de l’ancien et du nouveau cluster restent synchronisés, une réplication a été paramétrée entre l’ancienne instance primaire et la nouvelle. Le trafic a alors été progressivement redirigé en modifiant les workers enregistrés dans HAProxy.
Afin que tous les workers soient à jour, LinkedIn a introduit un mécanisme de supervision du délai de réplication. Il implique deux tâches cron. L’une horodate, toutes les 30 minutes, un enregistrement LDAP x sur l’ancienne instance primaire. L’autre s’exécute sur les workers : toutes les minutes, elle calcul le délai de réplication. La formule : temps actuel – (valeur de x dans ce worker + 30 minutes).
Une minute d’interruption pour basculer les écritures
Pour le trafic en écriture, il a d’abord été envisagé d’exploiter le dual write afin de parvenir à un basculement sans interruption. L’idée a été abandonnée à défaut d’une manière simple d’activer ce mécanisme sur TCP avec un proxy. Il s’agissait par ailleurs d’éviter la complexité d’un système de commit/rollback pour assurer la persistance des écritures entre les deux clusters.
Partant, LinkedIn a toléré une interruption d’environ 1 minute. Il s’est basé sur l’URL utilisée par les clients produisant du trafic en écriture. Cette URL contenait un enregistrement DNS A pointant vers l’adresse IP de l’ancienne instance primaire. Il a fait en sorte d’éteindre cette instance puis d’intervertir l’enregistrement DNS avec un enregistrement CNAME pointant vers le nouveau cluster. Grandes étapes de la démarche :
- Réduire le TTL de l’enregistrement à 1 minute
- Arrêter la réplication entre l’ancienne instance primaire et la nouvelle
- Éteindre l’ancienne instance
- Créer, dans le système DNS, une transaction unique qui supprime l’ancien enregistrement et crée le nouveau
- Valider les écritures vers le nouveau cluster une fois les changements DNS propagés
La définition d’un TTL d’une minute a offert une forme de garantie, en facilitant le retour du trafic en écriture vers l’ancien cluster en cas de problème.
Pour couvrir le cas où il aurait fallu revenir complètement à l’ancien cluster, LinkedIn s’est appuyé sur une sauvegarde périodique du changelog de réplication des nouvelles instances primaires. Ce backup aurait contenu les transactions réalisées sur les 14 derniers jours. Un script idempotent aurait alors appliqué une diff.
Illustration principale © Alexey Novikov – Adobe Stock
The post Comment LinkedIn a modernisé l’infra LDAP de son cluster Hadoop appeared first on Silicon.fr.




