Gestion efficace et fiable des clusters à toute échelle avec Tupperware
Aujourd'hui le nous avons présenté Tupperware, notre système de gestion de cluster qui orchestre les conteneurs sur des millions de serveurs exécutant presque tous nos services. Nous avons déployé Tupperware pour la première fois en 2011, et depuis lors, notre infrastructure est passée de à tout . Pendant tout ce temps, Tupperware n'est pas resté immobile et s'est développé avec nous. Nous vous montrerons comment Tupperware offre une gestion de cluster de première classe, notamment une prise en charge pratique des services avec état, un panneau de contrôle unique pour tous les centres de données et la possibilité de répartir la capacité entre les services en temps réel. Nous partagerons également les leçons que nous avons apprises à mesure que notre infrastructure évolue.
Tupperware effectue différentes tâches. Les développeurs d'applications l'utilisent pour fournir et gérer des applications. Il regroupe le code de l'application et ses dépendances dans une image et le transmet aux serveurs sous forme de conteneurs. Les conteneurs assurent l'isolation entre les applications sur le même serveur afin que les développeurs gèrent la logique de l'application et n'aient pas à se soucier de la recherche de serveurs ou de la gestion des mises à jour. Tupperware surveille également les performances du serveur et s'il détecte une panne, il transfère les conteneurs du serveur problématique.
Les ingénieurs en planification de capacité utilisent Tupperware pour allouer la capacité du serveur aux équipes en fonction du budget et des contraintes. Ils l'utilisent également pour améliorer l'utilisation du serveur. Les opérateurs de centres de données se tournent vers Tupperware pour distribuer correctement les conteneurs dans les centres de données et arrêter ou déplacer les conteneurs pendant la maintenance. Grâce à cela, la maintenance des serveurs, des réseaux et des équipements nécessite une intervention humaine minimale.
Architecture Tupperware
L'architecture Tupperware PRN est l'une des régions de nos centres de données. La région est constituée de plusieurs bâtiments de centres de données (PRN1 et PRN2) situés à proximité. Nous prévoyons de créer un panneau de contrôle qui gérera tous les serveurs d'une région.
Les développeurs d'applications fournissent des services sous la forme de tâches Tupperware. Une tâche se compose de plusieurs conteneurs, et ils exécutent tous généralement le même code d'application.
Tupperware est responsable de l'approvisionnement des conteneurs et de la gestion de leur cycle de vie. Il se compose de plusieurs éléments :
- L'interface Tupperware fournit des API pour l'interface utilisateur, la CLI et d'autres outils d'automatisation grâce auxquels vous pouvez interagir avec Tupperware. Ils cachent toute la structure interne aux propriétaires de travaux Tupperware.
- Tupperware Scheduler est un panneau de contrôle chargé de gérer le cycle de vie des conteneurs et des tâches. Il est déployé aux niveaux régional et mondial, où le planificateur régional gère les serveurs d'une région et le planificateur global gère les serveurs de différentes régions. Le planificateur est divisé en fragments et chaque fragment gère un ensemble de tâches.
- Le proxy de planification de Tupperware masque le partitionnement interne et fournit un panneau de verre unique pratique pour les utilisateurs de Tupperware.
- L'allocateur Tupperware attribue des conteneurs aux serveurs. Le planificateur gère l'arrêt, le démarrage, la mise à jour et le basculement des conteneurs. Actuellement, un seul allocateur peut gérer la région entière sans la diviser en fragments. (Notez la différence de terminologie. Par exemple, le planificateur de Tupperware correspond au panneau de commande de , et l'allocateur Tupperware est appelé planificateur dans Kubernetes.)
- Le courtier de ressources stocke la source de vérité pour les événements du serveur et du service. Nous exploitons un courtier de ressources pour chaque centre de données et il stocke toutes les informations sur les serveurs de ce centre de données. Le courtier de ressources et le système de gestion de capacité, ou système de provisionnement des ressources, décident dynamiquement quel planificateur contrôle quel serveur. Le service de vérification de l'état surveille les serveurs et stocke les données sur leur état dans le courtier de ressources. Si un serveur rencontre des problèmes ou nécessite une maintenance, le courtier de ressources demande à l'allocateur et au planificateur d'arrêter les conteneurs ou de les déplacer vers d'autres serveurs.
- L'agent Tupperware est un démon exécuté sur chaque serveur qui gère le provisionnement et la suppression des conteneurs. Les applications s'exécutent dans un conteneur, ce qui leur confère plus d'isolation et de reproductibilité. Sur Nous avons déjà décrit comment les conteneurs Tupperware individuels sont créés à l'aide d'images, btrfs, cgroupv2 et systemd.
Caractéristiques distinctives de Tupperware
Tupperware est similaire à bien des égards à d'autres systèmes de gestion de cluster tels que Kubernetes et , mais il y a aussi des différences :
- Prise en charge intégrée des services avec état.
- Un panneau de contrôle unique pour les serveurs de différents centres de données afin d'automatiser la livraison des conteneurs en fonction de l'intention, de la mise hors service des clusters et de la maintenance.
- Division claire du panneau de commande pour le zoom.
- L'informatique élastique vous permet de répartir la puissance entre les services en temps réel.
Nous avons développé ces fonctionnalités intéressantes pour prendre en charge une variété d'applications avec et sans état sur une vaste flotte mondiale de serveurs partagés.
Prise en charge intégrée des services avec état.
Tupperware exploite une variété de services avec état critiques qui stockent des données produit persistantes pour Facebook, Instagram, Messenger et WhatsApp. Il peut s'agir de grands magasins de paires clé-valeur (par ex. ) et la surveillance des référentiels de données (par exemple, и ). Maintenir des services avec état n'est pas facile, car le système doit garantir que l'approvisionnement en conteneurs peut résister à des perturbations à grande échelle, notamment des pannes de réseau ou des coupures de courant. Et tandis que les techniques conventionnelles, telles que la distribution de conteneurs entre domaines de pannes, fonctionnent bien pour les services sans état, les services avec état nécessitent une prise en charge supplémentaire.
Par exemple, si une panne de serveur rend une réplique de base de données indisponible, devez-vous activer la maintenance automatique qui mettra à jour les cœurs de 50 serveurs à partir d'un pool de 10 50 ? Cela dépend de la situation. Si l’un de ces 2 serveurs possède une autre réplique de la même base de données, mieux vaut attendre et ne pas perdre XNUMX répliques d’un coup. Afin de prendre des décisions dynamiques concernant la maintenance et les performances du système, nous avons besoin d'informations sur la réplication interne des données et la logique de placement de chaque service avec état.
L'interface TaskControl permet aux services avec état d'influencer les décisions qui affectent la disponibilité des données. Grâce à cette interface, le planificateur informe les applications externes des opérations du conteneur (redémarrage, mise à jour, migration, maintenance). Un service avec état implémente un contrôleur qui indique à Tupperware quand il est sûr d'effectuer chaque opération, et ces opérations peuvent être permutées ou retardées temporairement. Dans l'exemple ci-dessus, le contrôleur de base de données pourrait demander à Tupperware de mettre à jour 49 des 50 serveurs, mais de laisser un serveur spécifique (X) tranquille pour le moment. Par conséquent, si la période de mise à jour du noyau passe et que la base de données ne parvient toujours pas à restaurer la réplique problématique, Tupperware mettra toujours à jour le serveur X.
De nombreux services avec état de Tupperware n'utilisent pas TaskControl directement, mais via ShardManager, une plate-forme commune pour créer des services avec état sur Facebook. Avec Tupperware, les développeurs peuvent spécifier leur intention quant à la manière exacte dont les conteneurs doivent être distribués dans les centres de données. Avec ShardManager, les développeurs précisent leur intention quant à la manière dont les fragments de données doivent être distribués entre les conteneurs. ShardManager est conscient du placement des données et de la réplication de ses applications et communique avec Tupperware via l'interface TaskControl pour planifier les opérations du conteneur sans implication directe de l'application. Cette intégration simplifie grandement la gestion des services avec état, mais TaskControl est capable de faire bien plus. Par exemple, notre niveau Web étendu est sans état et utilise TaskControl pour ajuster dynamiquement le taux de mises à jour entre les conteneurs. Finalement par jour sans compromettre la disponibilité.
Gestion des serveurs dans les centres de données
Lorsque Tupperware a été lancé pour la première fois en 2011, chaque cluster de serveurs était géré par un planificateur distinct. À l'époque, un cluster Facebook était un groupe de racks de serveurs connectés à un commutateur réseau, et le centre de données abritait plusieurs clusters. Le planificateur ne pouvait gérer que les serveurs d'un seul cluster, ce qui signifie que la tâche ne pouvait pas s'étendre sur plusieurs clusters. Notre infrastructure s'est développée, nous avons de plus en plus radié les clusters. Étant donné que Tupperware ne pouvait pas déplacer le travail du cluster mis hors service vers d'autres clusters sans modifications, cela a nécessité beaucoup d'efforts et une coordination minutieuse entre les développeurs d'applications et les opérateurs du centre de données. Ce processus entraînait un gaspillage de ressources lorsque les serveurs étaient inactifs pendant des mois en raison des procédures de mise hors service.
Nous avons créé un courtier de ressources pour résoudre le problème de déclassement du cluster et coordonner d'autres types de tâches de maintenance. Le courtier de ressources garde une trace de toutes les informations physiques associées à un serveur et décide dynamiquement quel planificateur contrôle chaque serveur. La liaison dynamique des serveurs aux planificateurs permet à ce dernier de gérer des serveurs dans différents centres de données. Étant donné qu'une tâche Tupperware n'est plus limitée à un seul cluster, les utilisateurs de Tupperware peuvent spécifier comment les conteneurs doivent être distribués entre les domaines de pannes. Par exemple, un développeur peut déclarer son intention (par exemple : « exécuter mon travail sur 2 domaines de pannes dans la région PRN ») sans spécifier de zones de disponibilité spécifiques. Tupperware trouvera lui-même des serveurs adaptés pour mettre en œuvre cette intention, même si le cluster ou le service est mis hors service.
Évolutif pour prendre en charge l’ensemble du système mondial
Historiquement, notre infrastructure a été divisée en centaines de pools de serveurs dédiés pour des équipes individuelles. En raison de la fragmentation et du manque de normes, nous avions des coûts opérationnels élevés et les serveurs inactifs étaient plus difficiles à réutiliser. Lors de la conférence de l'année dernière nous avons présenté , qui devrait fédérer notre infrastructure en un grand parc de serveurs unique. Mais un parc de serveurs unique présente ses propres difficultés. Il doit répondre à certaines exigences :
- Évolutivité. Notre infrastructure s'est développée à mesure que nous avons ajouté des centres de données dans chaque région. Les serveurs sont devenus plus petits et plus économes en énergie, ils sont donc beaucoup plus nombreux dans chaque région. Par conséquent, un seul planificateur par région ne peut pas gérer le nombre de conteneurs pouvant être exécutés sur des centaines de milliers de serveurs dans chaque région.
- Fiabilité. Même si le planificateur peut être étendu à ce point, la portée étendue du planificateur signifie qu'il existe un risque plus élevé d'erreurs et qu'une région entière de conteneurs pourrait devenir ingérable.
- Tolérance aux pannes. En cas de panne majeure de l'infrastructure (par exemple, les serveurs exécutant le planificateur tombent en panne en raison d'une panne de réseau ou d'une panne de courant), les conséquences négatives ne devraient affecter qu'une partie des serveurs de la région.
- Facilité d'utilisation Il peut sembler que vous deviez exécuter plusieurs planificateurs indépendants pour une même région. Mais d'un point de vue pratique, un point d'entrée unique dans le pool partagé d'une région facilite la gestion de la capacité et des emplois.
Nous avons divisé le planificateur en fragments pour résoudre les problèmes de maintenance d'un grand pool partagé. Chaque partition du planificateur gère son propre ensemble de tâches dans la région, ce qui réduit le risque associé au planificateur. À mesure que le pool partagé s'agrandit, nous pouvons ajouter davantage de fragments de planificateur. Pour les utilisateurs de Tupperware, les fragments et les proxys du planificateur ressemblent à un seul panneau de contrôle. Ils n’ont pas besoin de travailler avec un tas de fragments qui orchestrent les tâches. Les fragments de planificateur sont fondamentalement différents des planificateurs de cluster que nous utilisions auparavant, lorsque le panneau de contrôle était partitionné sans diviser statiquement le pool partagé de serveurs en fonction de la topologie du réseau.
Améliorez l’efficacité d’utilisation avec Elastic Computing
Plus notre infrastructure est grande, plus il est important d'utiliser nos serveurs efficacement pour optimiser les coûts d'infrastructure et réduire la charge. Il existe deux manières d'augmenter l'efficacité de l'utilisation du serveur :
- Informatique élastique : réduisez les services en ligne pendant les heures creuses et utilisez des serveurs libérés pour les charges de travail hors ligne, telles que les tâches d'apprentissage automatique et MapReduce.
- Surcharge : placez les services en ligne et les charges de travail par lots sur les mêmes serveurs afin que les charges de travail par lots s'exécutent avec une faible priorité.
Le goulot d'étranglement dans nos centres de données est . Par conséquent, nous préférons les petits serveurs économes en énergie qui, ensemble, fournissent plus de puissance de traitement. Malheureusement, sur les petits serveurs avec peu de CPU et de mémoire, la surcharge est moins efficace. Bien sûr, nous pouvons placer plusieurs conteneurs de petits services sur un petit serveur économe en énergie qui consomme peu de ressources processeur et de mémoire, mais les gros services auront de faibles performances dans cette situation. Nous conseillons donc aux développeurs de nos gros services de les optimiser afin qu'ils utilisent l'intégralité des serveurs.
Fondamentalement, nous améliorons l’efficacité de l’utilisation grâce au calcul élastique. Bon nombre de nos principaux services, tels que le fil d'actualité, la fonction de messagerie et le niveau Web frontal, varient en fonction de l'heure de la journée. Nous réduisons intentionnellement les services en ligne pendant les heures calmes et utilisons des serveurs libérés pour les charges de travail hors ligne, telles que les tâches d'apprentissage automatique et MapReduce.
Nous savons par expérience qu'il est préférable de provisionner des serveurs entiers sous forme d'unités de capacité élastique, car les grands services sont à la fois de grands donateurs et de grands consommateurs de capacité élastique et sont optimisés pour utiliser des serveurs entiers. Lorsque le serveur est libéré du service en ligne pendant les heures calmes, le courtier de ressources loue le serveur au planificateur pour qu'il y exécute des charges de travail hors ligne. Si le service en ligne connaît une charge de pointe, le courtier en ressources rappelle rapidement le serveur emprunté et, avec le planificateur, le renvoie au service en ligne.
Leçons apprises et projets pour l’avenir
Au cours des 8 dernières années, nous avons développé Tupperware pour suivre la croissance rapide de Facebook. Nous partageons ce que nous avons appris et espérons que cela aidera d’autres à gérer des infrastructures à croissance rapide :
- Établissez une connexion flexible entre le panneau de contrôle et les serveurs qu’il gère. Cette flexibilité permet au panneau de contrôle de gérer des serveurs dans différents centres de données, aide à automatiser la mise hors service et la maintenance des clusters et permet une allocation dynamique de capacité à l'aide de l'informatique élastique.
- Avec un seul panneau de contrôle dans la région, il devient plus pratique de travailler avec des tâches et de gérer plus facilement une grande flotte de serveurs partagés. A noter que le panneau de contrôle conserve un point d'entrée unique, même si sa structure interne est séparée pour des raisons d'échelle ou de tolérance aux pannes.
- À l'aide d'un modèle de plugin, le panneau de contrôle peut informer les applications externes des opérations à venir sur les conteneurs. De plus, les services avec état peuvent utiliser l'interface du plugin pour personnaliser la gestion des conteneurs. Avec ce modèle de plugin, le panneau de contrôle offre une simplicité tout en servant efficacement de nombreux services avec état différents.
- Nous pensons que l'informatique élastique, dans laquelle nous supprimons des serveurs entiers des services donateurs pour les tâches par lots, l'apprentissage automatique et d'autres services non urgents, est le moyen optimal d'améliorer l'efficacité des petits serveurs économes en énergie.
Nous commençons tout juste à mettre en œuvre . Actuellement, environ 20 % de nos serveurs se trouvent dans un pool partagé. Pour atteindre 100 %, de nombreux problèmes doivent être résolus, notamment le maintien d'un pool de stockage partagé, l'automatisation de la maintenance, la gestion des exigences entre locataires, l'amélioration de l'utilisation des serveurs et l'amélioration de la prise en charge des charges de travail d'apprentissage automatique. Nous avons hâte de relever ces défis et de partager nos réussites.
Source: habr.com