Temps d'effet
Ce blog fait suite à « Quel est un bon plan de contrôle pour exploiter un grand nombre de clusters Kubernetes » . Le blog précédent décrivait l'approche unique de Volterra en matière d'opérations de flotte pour gérer une flotte de sites et applications d'infrastructure. Ce blog spécifique décrit un défi majeur de dérive de configuration auquel est confrontée une équipe d'exploitation lorsqu'elle effectue des modifications de configuration sur un grand nombre de clusters ou de sites. J’appelle ce défi « Le temps de l’effet ».
Qu'est-ce que le délai d'effet ?
On peut simplement le décrire comme le temps qu’il faut pour que l’intention d’une opération prenne effet. Voici quelques exemples :
- Combien de temps faudra-t-il pour que la configuration de ma politique de sécurité prenne effet sur tous mes sites ?
- Combien de temps faudra-t-il pour que la dernière version de mon application soit propagée sur tous les sites ?
- Combien de temps faudra-t-il pour mettre à niveau le système d’exploitation ou le logiciel d’infrastructure sur tous mes sites répartis dans le monde entier ?
Pourquoi est-ce important ?
Cette question peut être répondue à travers quelques exemples concrets de clients :
- Meltdown et Spectre — Après l’annonce de Meltdown/Spectre, la principale préoccupation de chaque RSSI était de savoir comment corriger rapidement le système d’exploitation de toute leur infrastructure. L'équipe d'exploitation était mesurée toutes les heures pour que son intention (c'est-à-dire la mise à niveau de la version du système d'exploitation) prenne effet.
- Vous avez sûrement entendu parler de la flotte de distributeurs automatiques qui a provoqué une attaque par déni de service sur une université ? Voici le TL;DR au cas où vous n'auriez pas suivi cette attaque : les pirates ont exploité une vulnérabilité zero-day et installé des logiciels malveillants qui se sont connectés à d'autres distributeurs automatiques et ont créé une flotte de robots de vente. Il a ensuite envoyé d’énormes volumes de trafic et provoqué une attaque par déni de service sur l’université. Après avoir détecté l'attaque, l'université a dû configurer des règles de politique réseau sur chaque distributeur automatique, un par un, pour empêcher l'accès au serveur de commande et de contrôle. Il était extrêmement important pour eux que leur intention (c’est-à-dire bloquer l’accès à un site Web spécifique) soit effective immédiatement sur tous les distributeurs automatiques afin d’arrêter l’hémorragie.
Le délai d’effet est important pour plusieurs catégories telles que les logiciels d’infrastructure, les logiciels application , la politique réseau et la politique de sécurité.
Quel est le défi?
La gravité du défi est particulièrement ressentie lorsque l’équipe d’exploitation doit gérer
- Une grande échelle de sites
- Sites répartis dans le monde entier
- Environnements hétérogènes, c'est-à-dire sites dans des clouds privés, publics, de télécommunications et des appareils périphériques
- Connectivité incohérente pour les sites
Un excellent exemple d’une telle équipe d’exploitation d’un constructeur automobile responsable de la mise à jour du logiciel et de la gestion de la connectivité de ses automobiles (ci-après dénommés sites clients). Le déploiement typique comprendrait un centre de données privé à partir duquel l'équipe d'exploitation contrôle ses véhicules à l'échelle mondiale (ou régionalement selon la structure organisationnelle).
Pour comprendre le défi, examinons les solutions dont dispose l’équipe opérationnelle. La plupart des solutions proposent des logiciels de gestion hébergés dans le centre de données privé d'un client pour gérer de manière centralisée la grande échelle des sites distribués. Lorsque le constructeur automobile configure une politique qui doit être appliquée à tous les véhicules, le logiciel de gestion central télécharge essentiellement un script de configuration sur chaque véhicule, un par un. Le script de configuration peut être un playbook Ansible ou un graphique Helm qui exécute une série de commandes de configuration sur chaque site. Ceci peut être visualisé comme indiqué dans le diagramme ci-dessous.
Le problème est que le temps d’effet est directement proportionnel au nombre de sites. Les fournisseurs de logiciels de gestion centralisée diront que tant que toutes les opérations peuvent être effectuées à distance et de manière automatisée, c'est le meilleur résultat qui puisse être obtenu.
Volterra n’est pas d’accord et nous pouvons le prouver dans ce blog. Nous avons construit un plan de contrôle distribué avec une approche architecturale hiérarchique et évolutive conçue pour garantir un délai d'effet minimal.
Architecture Volterra pour un temps de mise en œuvre minimal
Les éléments fondamentaux pour obtenir un délai d'effet minimal sont :
- Architecture arborescente hiérarchique
- Plan de contrôle distribué spécialement conçu
Un aperçu architectural de haut niveau est présenté ci-après.
L’approche de l’architecture hiérarchique de Volterra consiste à créer une arborescence de nœuds pour la distribution de la configuration. Chaque nœud effectue un stockage et une transmission, c'est-à-dire qu'il stocke la configuration localement, puis la transmet à ses enfants. Le mieux est de décrire cela à l’aide d’un exemple. Lorsqu'un utilisateur configure un objet tel qu'une politique réseau, sur la console Volterra, le plan de contrôle et de gestion distribue la configuration aux enfants immédiats, les bords régionaux (RE). Chaque RE effectue un stockage de configuration localement et le transmet à ses enfants. Les enfants de RE sont des sites clients connectés à cette RE.
Une architecture arborescente hiérarchique garantit un délai d'effet minimal. Le temps d’effet est limité par le nombre de niveaux dans l’arbre et le nombre d’enfants par nœud. Le nombre maximum de niveaux dans l'arborescence est de trois (contrôleur → RE → site client). Le nombre d'enfants par nœud est directement proportionnel au nombre de sites connectés à RE. Une instance de service est générée sur le RE pour gérer la configuration d'un ensemble de sites. Le plan de contrôle évolutif de Volterra génère de nouvelles instances de service, à la demande, en cas d'augmentation du nombre de sites connectés au RE.
Configuration de test
La mesure du temps d'effet a été réalisée sur une grande échelle de sites clients connectés à deux périphéries régionales situées à New York (NY8-NYC) et à Paris (PA4-PAR). Les sites clients étaient répartis dans le monde entier à Santa Clara (Californie), Houston (Texas), Madrid (Espagne), Prague (République tchèque), Londres (Royaume-Uni), etc. De plus, les sites clients se trouvaient dans des environnements hétérogènes tels qu'AWS, les machines virtuelles (ESXi), les passerelles Edge, notamment les Intel NUC et Fitlet2.
Le portail client et le plan de contrôle global de Volterra fonctionnaient dans Azure (Washington-IAD). Les sites clients ont été répartis sur plusieurs espaces de noms et locataires pour représenter un environnement d’exploitation réel.
Les conditions de défaillance ont été simulées en supprimant les instances de service sur le RE et en utilisant des liaisons de connectivité de mauvaise qualité entre le RE et les sites clients. Une vue instantanée d’un segment de l’ensemble de la flotte, dans un seul espace de noms, est présentée dans la Figure 3.
Méthodologie de test
Les journaux d'audit, avec horodatages, sont capturés dans le système Volterra chaque fois que des objets sont configurés sur la console Volterra et que la configuration est appliquée sur chaque site client. Le temps de propagation a été mesuré comme la différence de temps entre la configuration sur le portail et l' application de la configuration sur le site client. Un processus détaillé étape par étape est décrit ci-après.
- Configurer les objets sur le portail client.
- Mesurez l'heure de début comme l'heure de création de l'objet sur le portail client (appelé ci-après le contrôleur global Volterra). Voir la figure 4 par exemple.
- Mesurez l'heure de fin comme l'heure de création de l'objet sur le site client. Voir la figure 5 par exemple.
Notez que les captures d’écran affichées sont échantillonnées et ne font pas référence à la même itération de mesure.
Heure de début de la configuration
Heure de fin de configuration
Résultats des tests
Les résultats des tests des temps de propagation sont présentés dans les figures 6 et 7. Le graphique de la figure 6 indique que la plupart des échantillons de mesure avaient un temps de propagation compris entre 0 et 400 ms. Cela signifie que tous les sites clients sont mis à jour avec une nouvelle configuration entre 0 et 400 ms. Comme mentionné précédemment, les conditions de défaillance ont été simulées en redémarrant les services sur le RE et en introduisant des pannes/retards de connectivité sur le site client. Le temps de propagation de la configuration est plus long dans ces conditions de défaillance et varie de 600 ms à 9 secondes, dans ces tests spécifiques, selon le type de défaillance. Par exemple, une panne de connectivité entre les sites RE et client augmentera le temps nécessaire à la configuration pour atteindre le site client. Cependant, l'avantage du plan de contrôle distribué de Volterra est qu'il suit le paradigme de la configuration finalement cohérente, c'est-à-dire qu'il continue de réessayer pour garantir que la configuration sur tous les sites clients est alignée sur l'intention définie par le client.
Le graphique de la figure 7 indique que 85 % du temps, tous les sites clients sont mis à jour avec une nouvelle configuration dans un délai de 322 millisecondes. Dans le cas où des conditions de défaillance sont introduites, certains sites clients pourraient connaître un temps de propagation d'environ 3 à 9 secondes.
Clause de non-responsabilité: Ces mesures sont étroitement liées à la topologie, à l’échelle, à l’environnement de déploiement et aux situations de défaillance simulées. Nous n’avons pas mesuré toutes les situations de défaillance possibles ou d’autres environnements. Nous ne pouvons donc pas faire de déclarations sur le délai de propagation dans d’autres situations ou environnements qui n’ont pas été testés. Par exemple, en cas de défaillance d'un cluster Kubernetes, le système devra attendre la détection de la défaillance, redémarrer et réessayer la configuration, ce qui entraînera un délai de propagation plus élevé.