Système de gestion de configuration réseau de filtrage Qrator

TL; DR: Description de l'architecture client-serveur de notre système de gestion de configuration réseau interne, QControl. Il est basé sur un protocole de transport à deux couches qui fonctionne avec des messages compressés au format gzip sans décompression entre les points de terminaison. Les routeurs et points de terminaison distribués reçoivent des mises à jour de configuration, et le protocole lui-même permet l'installation de relais intermédiaires localisés. Le système est construit sur le principe sauvegarde différentielle (« récent-stable », expliqué ci-dessous) et utilise le langage de requête JMESpath ainsi que le moteur de création de modèles Jinja pour restituer les fichiers de configuration.

Qrator Labs exploite un réseau d'atténuation des attaques distribué à l'échelle mondiale. Notre réseau fonctionne selon le principe anycast et les sous-réseaux sont annoncés via BGP. Étant un réseau Anycast BGP physiquement situé dans plusieurs régions de la Terre, nous pouvons traiter et filtrer le trafic illégitime plus près du cœur de l'Internet - les opérateurs de niveau 1.

D’un autre côté, être un réseau géographiquement distribué n’est pas facile. La communication entre les points de présence du réseau est essentielle pour que le fournisseur de services de sécurité dispose d'une configuration cohérente de tous les nœuds du réseau, et les mette à jour en temps opportun. Par conséquent, afin de fournir le niveau de service de base le plus élevé possible au consommateur, nous devions trouver un moyen de synchroniser de manière fiable les données de configuration sur tous les continents.

Au commencement était la Parole. Il est rapidement devenu un protocole de communication nécessitant une mise à jour.

La pierre angulaire de l'existence de QControl, et en même temps la principale raison pour laquelle on consacre beaucoup de temps et de ressources à la construction de ce type de protocole, est la nécessité d'obtenir une source unique de configuration faisant autorité et, finalement, de synchroniser nos points de présence. avec ça. Le stockage lui-même n’était qu’une des nombreuses exigences lors du développement de QControl. De plus, nous avions également besoin d'intégrations avec les services existants et planifiés aux points de présence (POP), de méthodes intelligentes (et personnalisables) pour la validation des données, ainsi que de contrôle d'accès. En plus de cela, nous voulions également contrôler un tel système à l'aide de commandes plutôt que de modifier des fichiers. Avant QControl, les données étaient envoyées aux points de présence presque manuellement. Si l’un des points de présence n’était pas disponible et que nous oubliions de le mettre à jour par la suite, la configuration se retrouverait désynchronisée et nous perdrions du temps à le remettre en marche.

En conséquence, nous avons proposé le schéma suivant :

Le serveur de configuration est responsable de la validation et du stockage des données ; le routeur dispose de plusieurs points de terminaison qui reçoivent et diffusent les mises à jour de configuration des clients et des équipes d'assistance vers le serveur, et du serveur vers les points de présence.

La qualité de la connexion Internet varie encore considérablement à travers le monde - pour illustrer ce point, regardons un simple MTR de Prague, en République tchèque, à Singapour et Hong Kong.

MTR de Prague à Singapour

Même chose à Hong Kong

Une latence élevée signifie une vitesse plus faible. De plus, il y a une perte de paquets. La largeur des canaux ne compense pas ce problème, qui doit toujours être pris en compte lors de la construction de systèmes décentralisés.

La configuration complète d'un point de présence représente une quantité importante de données qui doivent être envoyées à de nombreux destinataires via des connexions peu fiables. Heureusement, même si la configuration change constamment, elle se produit par petits incréments.

Conception récente et stable

On peut dire que construire un réseau distribué basé sur le principe des mises à jour incrémentielles est une solution assez évidente. Mais il y a beaucoup de problèmes avec les différences. Nous devons sauvegarder toutes les différences entre les points de référence, et également pouvoir les renvoyer au cas où quelqu'un aurait manqué une partie des données. Chaque destination doit les appliquer dans un ordre strictement spécifié. Typiquement, dans le cas de plusieurs destinations, une telle opération peut prendre beaucoup de temps. Le destinataire doit également pouvoir demander les pièces manquantes et, bien entendu, la partie centrale doit répondre correctement à une telle demande, en envoyant uniquement les données manquantes.

En conséquence, nous sommes arrivés à une solution plutôt intéressante - nous n'avons qu'une seule couche de référence, fixe, appelons-la stable, et une seule différence pour elle - récente. Chaque récent est basé sur le dernier stable généré et suffit à reconstruire les données de configuration. Dès que le nouveau et récent arrive à destination, l’ancien n’est plus nécessaire.

Il ne reste plus qu'à envoyer de temps en temps une nouvelle configuration stable, par exemple parce que la récente est devenue trop volumineuse. Ce qui est également important ici, c'est que nous envoyons toutes ces mises à jour en mode diffusion/multidiffusion, sans nous soucier des destinataires individuels et de leur capacité à rassembler des éléments de données. Une fois que nous sommes sûrs que tout le monde a la bonne écurie, nous envoyons uniquement les nouvelles et récentes. Vaut-il la peine de préciser que cela fonctionne ? Travaux. Stable est mis en cache sur le serveur de configuration et les destinataires, récent est créé selon les besoins.

Architecture du transport à deux niveaux

Pourquoi avons-nous construit notre transport sur deux niveaux ? La réponse est assez simple : nous voulions dissocier le routage de la logique de haut niveau, en nous inspirant du modèle OSI avec ses couches transport et application. Nous avons utilisé Thrift pour le rôle de protocole de transport et le format de sérialisation msgpack pour le format de haut niveau des messages de contrôle. C'est pourquoi le routeur (exécutant la multidiffusion/diffusion/relais) ne regarde pas à l'intérieur de msgpack, ne décompresse ni ne regroupe le contenu et transfère uniquement les données.

Thrift (de l'anglais - « thrift », prononcé [θrift]) est un langage de description d'interface utilisé pour définir et créer des services pour différents langages de programmation. Il s'agit d'un framework pour les appels de procédures distantes (RPC). Combine un pipeline logiciel avec un moteur de génération de code pour développer des services qui fonctionnent plus ou moins efficacement et facilement entre les langages.

Nous avons choisi le framework Thrift en raison du RPC et de la prise en charge de nombreux langages. Comme d'habitude, les parties faciles étaient le client et le serveur. Cependant, le routeur s'est avéré être un problème difficile à résoudre, en partie à cause de l'absence de solution prête à l'emploi au cours de notre développement.

Il existe d'autres options, comme protobuf / gRPC, cependant, lorsque nous avons démarré notre projet, gRPC était assez nouveau et nous n'avons pas osé l'adopter.

Bien sûr, nous pourrions (et en fait aurions dû) construire notre propre vélo. Il serait plus facile de créer un protocole répondant à nos besoins car l'architecture client-serveur est relativement simple à mettre en œuvre par rapport à la construction d'un routeur sur Thrift. D’une manière ou d’une autre, il existe un biais traditionnel en faveur des protocoles auto-écrits et des implémentations de bibliothèques populaires (pour cause) ; en outre, lors des discussions, la question revient toujours : « Comment allons-nous porter cela dans d’autres langages ? » Nous avons donc immédiatement rejeté l'idée du vélo.

Msgpack est similaire à JSON, mais plus rapide et plus petit. Il s'agit d'un format de sérialisation de données binaires qui permet d'échanger des données entre plusieurs langues.

Au premier niveau, nous avons Thrift avec le minimum d'informations nécessaire au routeur pour transmettre le message. Au deuxième niveau se trouvent les structures msgpack packagées.

Nous avons choisi msgpack car il est plus rapide et plus compact que JSON. Mais plus important encore, il prend en charge les types de données personnalisés, ce qui nous permet d'utiliser des fonctionnalités intéressantes telles que la transmission de binaires bruts ou d'objets spéciaux indiquant l'absence de données, ce qui était important pour notre schéma « récent-stable ».

Chemin JMES
JMESPath est un langage de requête JSON.
C'est exactement à quoi ressemble la description que nous obtenons de la documentation officielle de JMESPath, mais en fait, elle fait bien plus que cela. JMESPath vous permet de rechercher et de filtrer des sous-arbres dans une structure arborescente arbitraire et d'appliquer des modifications aux données à la volée. Il vous permet également d'ajouter des filtres spéciaux et des procédures de transformation de données. Bien sûr, cela nécessite un effort cérébral pour comprendre.

Jinja
Pour certains consommateurs, nous devons transformer la configuration en fichier. Nous utilisons donc un moteur de modèles et Jinja est le choix évident. Avec son aide, nous générons un fichier de configuration à partir du modèle et des données reçues à destination.

Pour générer un fichier de configuration, nous avons besoin d'une requête JMESPath, d'un modèle pour l'emplacement du fichier dans le FS et d'un modèle pour la configuration elle-même. C'est également une bonne idée à ce stade de clarifier les autorisations des fichiers. Tout cela a été combiné avec succès dans un seul fichier - avant le début du modèle de configuration, nous avons mis un en-tête au format YAML qui décrit le reste.

Par exemple:

---
selector: "[@][?@.fft._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft]
...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}


Afin de créer un fichier de configuration pour un nouveau service, nous ajoutons uniquement un nouveau fichier modèle. Aucune modification du code source ou du logiciel sur les points de présence n'est requise.

Qu’est-ce qui a changé depuis la mise en ligne de QControl ? La première et la plus importante chose est la livraison cohérente et fiable des mises à jour de configuration à tous les nœuds du réseau. La seconde est de recevoir un outil puissant pour vérifier la configuration et y apporter des modifications par notre équipe d'assistance, ainsi que par les consommateurs du service.

Nous avons pu faire tout cela en utilisant le schéma de mise à jour stable et récente pour simplifier la communication entre le serveur de configuration et les destinataires de la configuration. Utilisation d'un protocole à deux couches pour prendre en charge une méthode de routage des données indépendante du contenu. Intégration réussie d'un moteur de génération de configuration basé sur Jinja dans un réseau de filtrage distribué. Ce système prend en charge un large éventail de méthodes de configuration pour nos périphériques distribués et hétérogènes.

Merci pour votre aide dans la rédaction du matériel. VolanDamrod, sérénité, Non.

version anglaise Publier.

Source: habr.com