En 2010, l'entreprise il y avait 50 serveurs et un modèle de réseau simple : backend, frontend et pare-feu. Le nombre de serveurs a augmenté, le modèle est devenu plus complexe : staging, VLAN isolés avec ACL, puis VPN avec VRF, VLAN avec ACL sur L2, VRF avec ACL sur L3. La tête tourne ? Ce sera plus amusant plus tard.
Lorsqu'il y avait 16 000 serveurs, il devenait impossible de travailler sans problème avec autant de segments hétérogènes. Nous avons donc trouvé une autre solution. Nous avons pris la pile Netfilter, y avons ajouté Consul comme source de données et nous avons obtenu un pare-feu distribué rapide. Ils ont remplacé les ACL sur les routeurs et les ont utilisés comme pare-feu externe et interne. Pour gérer dynamiquement l'outil, nous avons développé le système BEFW, qui a été utilisé partout : de la gestion des accès des utilisateurs au réseau de produits à l'isolation des segments de réseau les uns des autres.
Il vous expliquera comment tout cela fonctionne et pourquoi vous devriez examiner de plus près ce système. Ivan Agarkov () est le chef du groupe de sécurité des infrastructures de la division Maintenance du centre de développement de l'entreprise à Minsk. Ivan est un fan de SELinux, adore Perl et écrit du code. En tant que chef du groupe de sécurité des informations, il travaille régulièrement avec les journaux, les sauvegardes et la R&D pour protéger Wargaming des pirates informatiques et assurer le fonctionnement de tous les serveurs de jeux de l'entreprise.
Les informations historiques
Avant de vous expliquer comment nous y sommes parvenus, je vais vous expliquer comment nous en sommes arrivés là et pourquoi cela était nécessaire. Pour ce faire, remontons 9 ans en arrière : 2010, World of Tanks vient d'apparaître. Wargaming comptait environ 50 serveurs.
Graphique de croissance des serveurs de l'entreprise.
Nous avions un modèle de réseau. Pour cette époque, c’était optimal.
Modèle de réseau en 2010.
Il y a des méchants en amont qui veulent nous briser, mais il y a un pare-feu. Il n'y a pas de pare-feu sur le backend, mais il y a 50 serveurs, nous les connaissons tous. Tout fonctionne bien.
En 4 ans, le parc de serveurs a été multiplié par 100, pour atteindre 5000 XNUMX. Les premiers réseaux isolés sont apparus - staging : ils ne pouvaient pas passer en production, et il y avait souvent des choses qui pouvaient être dangereuses.
Modèle de réseau en 2014.
Par inertie, nous avons utilisé les mêmes éléments matériels, et tout le travail a été effectué sur des VLAN isolés : des ACL sont écrites sur les VLAN, qui autorisent ou refusent une sorte de connexion.
En 2016, le nombre de serveurs a atteint 8000 XNUMX. Wargaming a absorbé d'autres studios et des réseaux d'affiliation supplémentaires sont apparus. Ils semblent être les nôtres, mais pas tout à fait : le VLAN ne fonctionne souvent pas pour les partenaires, il faut utiliser un VPN avec VRF, l'isolation devient plus compliquée. Le mélange d'isolation ACL a augmenté.
Modèle de réseau en 2016.
Début 2018, le parc de machines s'élevait à 16 000. Il y avait 6 segments, et nous ne comptions pas le reste, y compris ceux fermés dans lesquels étaient stockées les données financières. Des réseaux de conteneurs (Kubernetes), DevOps, des réseaux cloud connectés via VPN, par exemple depuis un IVS, sont apparus. Il y avait beaucoup de règles – c'était douloureux.
Modèle de réseau et méthodes d'isolement en 2018.
Pour l'isolation, nous avons utilisé : VLAN avec ACL sur L2, VRF avec ACL sur L3, VPN et bien plus encore. Trop.
Problèmes
Tout le monde vit avec ACL et VLAN. Qu'est-ce qui ne va pas? Harold répondra à cette question en cachant la douleur.
Il y avait de nombreux problèmes, mais il y en avait cinq de taille.
- Augmentation géométrique des prix pour les nouvelles règles. Chaque nouvelle règle prenait plus de temps à ajouter que la précédente, car il fallait d'abord voir si une telle règle existait déjà.
- Pas de pare-feu à l'intérieur des segments. Les segments étaient en quelque sorte séparés les uns des autres et il n'y avait déjà pas assez de ressources à l'intérieur.
- Les règles ont été appliquées pendant longtemps. Les opérateurs pouvaient rédiger une règle locale à la main en une heure. La mondiale a duré plusieurs jours.
- Difficultés avec les règles d'audit. Plus précisément, ce n’était pas possible. Les premières règles ont été rédigées en 2010 et la plupart de leurs auteurs ne travaillaient plus pour l'entreprise.
- Faible niveau de contrôle des infrastructures. C’est là le principal problème : nous ne savions pas très bien ce qui se passait dans notre pays.
Voici à quoi ressemblait un ingénieur réseau en 2018 lorsqu'il a entendu : « Besoin d'un peu plus d'ACL. »
Решения
Début 2018, il a été décidé d’agir.
Le prix des intégrations est en constante augmentation. Le point de départ était que les grands centres de données ont cessé de prendre en charge les VLAN et les ACL isolés parce que les appareils manquaient de mémoire.
Solution : nous avons supprimé le facteur humain et automatisé au maximum la fourniture d'accès.
Les nouvelles règles mettent beaucoup de temps à s'appliquer. Solution : accélérer l’application des règles, la rendre distribuée et parallèle. Cela nécessite un système distribué pour que les règles soient livrées elles-mêmes, sans rsync ni SFTP à un millier de systèmes.
Pas de pare-feu à l'intérieur des segments. Un pare-feu au sein des segments a commencé à nous apparaître lorsque différents services sont apparus au sein du même réseau. Solution : utilisez un pare-feu au niveau de l'hôte - des pare-feu basés sur l'hôte. Presque partout où nous avons Linux, et partout où nous avons iptables, ce n'est pas un problème.
Difficultés avec les règles d'audit. Solution : Conservez toutes les règles au même endroit pour examen et gestion, afin que nous puissions tout auditer.
Faible niveau de contrôle sur les infrastructures. Solution : faire l'inventaire de tous les services et des accès entre eux.
Il s’agit plus d’une démarche administrative que technique. Parfois, nous avons 200 à 300 nouveautés par semaine, notamment pendant les promotions et les jours fériés. De plus, cela ne concerne qu'une seule équipe de notre DevOps. Avec autant de versions, il est impossible de voir quels ports, IP et intégrations sont nécessaires. Nous avions donc besoin de responsables de service spécialement formés qui demandaient aux équipes : « Qu’y a-t-il de toute façon et pourquoi en avez-vous parlé ?
Après tout ce que nous avons lancé, un ingénieur réseau en 2019 a commencé à ressembler à ceci.
Consul
Nous avons décidé de mettre tout ce que nous trouverions avec l'aide des gestionnaires de services dans Consul et d'écrire les règles iptables à partir de là.
Comment avons-nous décidé de faire cela ?
- Nous collecterons tous les services, réseaux et utilisateurs.
- Créons des règles iptables basées sur elles.
- Nous automatisons le contrôle.
- ....
- PROFIT.
Consul n'est pas une API distante, elle peut s'exécuter sur chaque nœud et écrire sur iptables. Il ne reste plus qu'à proposer des contrôles automatiques qui nettoieront les choses inutiles, et la plupart des problèmes seront résolus ! Nous réglerons le reste au fur et à mesure.
Pourquoi Consul ?
A fait ses preuves. En 2014-15, nous l'avons utilisé comme backend pour Vault, dans lequel nous stockons les mots de passe.
Ne perd pas de données. Pendant la durée d'utilisation, Consul n'a perdu aucune donnée lors d'un seul accident. C'est un énorme avantage pour un système de gestion de pare-feu.
Les connexions P2P accélèrent la propagation du changement. Avec le P2P, tous les changements arrivent rapidement, pas besoin d’attendre des heures.
API REST pratique. Nous avons également envisagé Apache ZooKeeper, mais il ne dispose pas d'API REST, vous devrez donc installer des béquilles.
Fonctionne à la fois comme Key Vault (KV) et comme répertoire (Service Discovery). Vous pouvez stocker simultanément des services, des catalogues et des centres de données. C'est pratique non seulement pour nous, mais aussi pour les équipes voisines, car lorsque nous construisons un service mondial, nous voyons grand.
Écrit en Go, qui fait partie de la pile Wargaming. Nous aimons ce langage, nous avons de nombreux développeurs Go.
Système ACL puissant. Dans Consul, vous pouvez utiliser les ACL pour contrôler qui écrit quoi. Nous garantissons que les règles de pare-feu ne chevaucheront rien d'autre et cela ne nous posera aucun problème.
Mais Consul a aussi ses inconvénients.
- N'évolue pas au sein d'un centre de données, sauf si vous disposez d'une version professionnelle. Il n’est évolutif que par fédération.
- Très dépendant de la qualité du réseau et de la charge du serveur. Consul ne fonctionnera pas correctement en tant que serveur sur un serveur occupé s'il y a des retards dans le réseau, par exemple une vitesse inégale. Cela est dû aux connexions P2P et aux modèles de distribution de mises à jour.
- Difficulté à surveiller la disponibilité. En statut consul, il peut dire que tout va bien, mais il est mort depuis longtemps.
Nous avons résolu la plupart de ces problèmes en utilisant Consul, c'est pourquoi nous l'avons choisi. L'entreprise envisage un backend alternatif, mais nous avons appris à gérer les problèmes et vivons actuellement avec Consul.
Comment fonctionne Consul
Nous installerons trois à cinq serveurs dans un centre de données conditionnel. Un ou deux serveurs ne fonctionneront pas : ils ne pourront pas organiser un quorum et décider qui a raison et qui a tort lorsque les données ne correspondent pas. Plus de cinq n’a aucun sens, la productivité diminuera.
Les clients se connectent aux serveurs dans n'importe quel ordre : les mêmes agents, uniquement avec le flag server = false.
Après cela, les clients reçoivent une liste de connexions P2P et établissent des connexions entre eux.
Au niveau mondial, nous connectons plusieurs centres de données. Ils se connectent également en P2P et communiquent.
Lorsque l'on souhaite récupérer des données d'un autre centre de données, la requête passe de serveur en serveur. Ce schéma est appelé Protocole de service. Le protocole Serf, comme Consul, est développé par HashiCorp.
Quelques faits importants sur Consul
Consul dispose d'une documentation décrivant son fonctionnement. Je ne donnerai que des faits sélectionnés qui valent la peine d'être connus.
Les serveurs du Consul sélectionnent un maître parmi les votants. Consul sélectionne un maître dans la liste des serveurs pour chaque centre de données, et toutes les demandes lui sont adressées uniquement, quel que soit le nombre de serveurs. Le gel principal ne conduit pas à la réélection. Si le maître n'est pas sélectionné, les demandes ne sont traitées par personne.
Vouliez-vous une mise à l’échelle horizontale ? Désolé, non.
Une requête adressée à un autre centre de données va de maître à maître, quel que soit le serveur auquel elle parvient. Le maître sélectionné reçoit 100 % de la charge, à l'exception de la charge sur les demandes forward. Tous les serveurs du centre de données disposent d'une copie à jour des données, mais un seul répond.
La seule façon d’évoluer est d’activer le mode obsolète sur le client.
En mode obsolète, vous pouvez répondre sans quorum. Il s'agit d'un mode dans lequel nous abandonnons la cohérence des données, mais lisons un peu plus vite que d'habitude, et n'importe quel serveur répond. Naturellement, enregistrement uniquement via le master.
Consul ne copie pas les données entre les centres de données. Lorsqu'une fédération est constituée, chaque serveur ne disposera que de ses propres données. Pour d’autres, il se tourne toujours vers quelqu’un d’autre.
L'atomicité des opérations n'est pas garantie en dehors d'une transaction. N'oubliez pas que vous n'êtes pas le seul à pouvoir changer les choses. Si vous le souhaitez différemment, effectuez une transaction avec un verrou.
Les opérations de blocage ne garantissent pas le verrouillage. La demande va de maître à maître, et non directement, il n'y a donc aucune garantie que le blocage fonctionnera lorsque vous bloquez, par exemple, dans un autre centre de données.
ACL ne garantit pas non plus l'accès (dans de nombreux cas). L'ACL peut ne pas fonctionner car elle est stockée dans un centre de données de fédération : dans le centre de données ACL (DC primaire). Si le DC ne vous répond pas, l'ACL ne fonctionnera pas.
Un maître gelé entraînera le gel de la fédération entière. Par exemple, il y a 10 centres de données dans une fédération, un d'entre eux a un mauvais réseau et un maître tombe en panne. Tous ceux qui communiquent avec lui seront coincés en cercle : il y a une demande, il n'y a pas de réponse, le fil se bloque. Il n’y a aucun moyen de savoir quand cela se produira ; dans une heure ou deux, la fédération entière tombera. Vous ne pouvez rien y faire.
Le statut, le quorum et les élections sont gérés par un fil distinct. La réélection n'aura pas lieu, le statut ne montrera rien. Vous pensez avoir un consul en direct, vous demandez, et rien ne se passe – il n'y a pas de réponse. En même temps, le statut montre que tout va bien.
Nous avons rencontré ce problème et avons dû reconstruire des parties spécifiques des centres de données pour l'éviter.
La version professionnelle de Consul Enterprise ne présente pas certains des inconvénients ci-dessus. Il a de nombreuses fonctions utiles : sélection des électeurs, répartition, mise à l'échelle. Il n'y a qu'un seul « mais » : le système de licence pour un système distribué est très coûteux.
Piratage de la vie: rm -rf /var/lib/consul - un remède contre toutes les maladies de l'agent. Si quelque chose ne fonctionne pas pour vous, supprimez simplement vos données et téléchargez-les à partir d'une copie. Très probablement, Consul fonctionnera.
BEFW
Parlons maintenant de ce que nous avons ajouté à Consul.
est un acronyme pour BackEndFireWtous. J'ai dû nommer le produit d'une manière ou d'une autre lorsque j'ai créé le référentiel afin d'y insérer les premiers commits de test. Ce nom demeure.
Modèles de règles
Les règles sont écrites dans la syntaxe iptables.
- -N BEFW
- -P ENTREE DROP
- -A INPUT -m état—état RELATED,ETABLISHED -j ACCEPT
- -A ENTRÉE -i lo -j ACCEPTER
- -A ENTRÉE -j BEFW
Tout entre dans la chaîne BEFW, sauf ESTABLISHED, RELATED et localhost. Le modèle peut être n'importe quoi, ce n'est qu'un exemple.
En quoi BEFW est-il utile ?
Services
Nous avons un service, il a toujours un port, un nœud sur lequel il s'exécute. Depuis notre nœud, nous pouvons demander localement à l'agent et découvrir que nous disposons d'une sorte de service. Vous pouvez également mettre des balises.
Tout service exécuté et enregistré auprès de Consul se transforme en règle iptables. Nous avons SSH - port ouvert 22. Le script Bash est simple : curl et iptables, rien d'autre n'est nécessaire.
clients
Comment ouvrir l’accès non pas à tout le monde, mais de manière sélective ? Ajoutez des listes IP au stockage KV par nom de service.
Par exemple, nous voulons que tout le monde sur le dixième réseau puisse accéder au service SSH_TCP_22. Ajouter un petit champ TTL ? et maintenant nous avons des permis temporaires, par exemple pour une journée.
Accéder
Nous connectons les services et les clients : nous avons un service, le stockage KV est prêt pour chacun. Désormais, nous donnons accès non pas à tout le monde, mais de manière sélective.
Groupe
Si nous écrivons des milliers d'adresses IP pour y accéder à chaque fois, nous allons nous fatiguer. Imaginons des groupements - un sous-ensemble distinct dans KV. Appelons-le Alias (ou groupes) et stockons-y les groupes selon le même principe.
Connectons-nous : nous pouvons désormais ouvrir SSH non pas spécifiquement pour le P2P, mais pour un groupe entier ou plusieurs groupes. De la même manière, il existe TTL - vous pouvez ajouter à un groupe et supprimer temporairement du groupe.
intégration
Notre problème est le facteur humain et l’automatisation. Jusqu'à présent, nous l'avons résolu de cette façon.
Nous travaillons avec Puppet, et leur transférons tout ce qui concerne le système (code d'application). Puppetdb (PostgreSQL standard) stocke une liste des services qui y sont exécutés, ils peuvent être trouvés par type de ressource. Vous y découvrirez qui postule et où. Nous disposons également d’un système de pull request et de demande de fusion pour cela.
Nous avons écrit befw-sync, une solution simple qui facilite le transfert de données. Tout d'abord, puppetdb accède aux cookies de synchronisation. Une API HTTP y est configurée : nous demandons de quels services nous disposons, ce qui doit être fait. Ensuite, ils font une demande au consul.
Y a-t-il une intégration ? Oui : ils ont écrit les règles et permis d’accepter les Pull Requests. Avez-vous besoin d'un certain port ou ajoutez un hôte à un groupe ? Pull Request, review - plus besoin de « Trouvez 200 autres ACL et essayez de faire quelque chose à ce sujet. »
Optimisation
Le ping de localhost avec une chaîne de règles vide prend 0,075 ms.
Ajoutons 10 000 adresses iptables à cette chaîne. En conséquence, le ping augmentera 5 fois : iptables est complètement linéaire, le traitement de chaque adresse prend un certain temps.
Pour un pare-feu où nous migrons des milliers d’ACL, nous avons beaucoup de règles, ce qui introduit de la latence. C'est mauvais pour les protocoles de jeu.
Mais si on met 10 000 adresses en ipset Le ping diminuera même.
Le fait est que « O » (complexité de l'algorithme) pour ipset est toujours égal à 1, quel que soit le nombre de règles. Certes, il y a une limitation : il ne peut pas y avoir plus de règles 65535 XNUMX. Pour l'instant, nous vivons avec ceci : vous pouvez les combiner, les étendre, créer deux ipsets en un.
stockage
Une suite logique du processus d'itération consiste à stocker des informations sur les clients du service dans ipset.
Maintenant, nous avons le même SSH, et nous n'écrivons pas 100 IP à la fois, mais définissons le nom de l'ipset avec lequel nous devons communiquer, et la règle suivante DROP. Cela peut être converti en une seule règle « Qui n’est pas là, DROP », mais c’est plus clair.
Nous avons maintenant des règles et des ensembles. La tâche principale est de créer un ensemble avant d'écrire la règle, sinon iptables n'écrira pas la règle.
Régime général
Sous forme de schéma, tout ce que j'ai dit ressemble à ceci.
Nous nous engageons auprès de Puppet, tout est envoyé à l'hébergeur, les services ici, ipset là, et quiconque n'y est pas inscrit n'est pas autorisé.
Autoriser et refuser
Pour sauver rapidement le monde ou désactiver rapidement quelqu'un, au début de toutes les chaînes, nous avons créé deux ipsets : rules_allow и rules_deny. Comment ça fonctionne?
Par exemple, quelqu'un crée une charge sur notre Web avec des robots. Auparavant, il fallait trouver son adresse IP à partir des journaux, la transmettre aux ingénieurs réseau, afin qu'ils puissent trouver la source du trafic et le bannir. Cela semble différent maintenant.
On l’envoie au Consul, on attend 2,5 secondes, et c’est fait. Puisque Consul distribue rapidement via P2P, il fonctionne partout, dans n'importe quelle partie du monde.
Une fois, j'ai complètement arrêté WOT à cause d'une erreur avec le pare-feu. rules_allow - c'est notre assurance contre de tels cas. Si nous avons fait une erreur quelque part avec le pare-feu, quelque chose est bloqué quelque part, nous pouvons toujours envoyer un message conditionnel 0.0/0pour tout récupérer rapidement. Plus tard, nous réparerons tout à la main.
D'autres ensembles
Vous pouvez ajouter n'importe quel autre ensemble dans l'espace $IPSETS$.
Pour quoi? Parfois, quelqu'un a besoin d'ipset, par exemple, pour émuler l'arrêt d'une partie du cluster. N'importe qui peut apporter n'importe quel ensemble, le nommer, et il sera récupéré auprès du Consul. Dans le même temps, les ensembles peuvent soit participer aux règles iptables, soit agir en équipe NOOP: La cohérence sera maintenue par le démon.
Membres
Auparavant, c'était comme ça : l'utilisateur se connectait au réseau et recevait des paramètres via le domaine. Avant l’avènement des pare-feu de nouvelle génération, Cisco ne savait pas comment comprendre où se trouvait l’utilisateur et où se trouvait l’adresse IP. Par conséquent, l’accès était accordé uniquement via le nom d’hôte de la machine.
Qu'avons-nous fait? Nous sommes restés bloqués au moment où nous avons reçu l'adresse. Il s'agit généralement de dot1x, Wi-Fi ou VPN - tout passe par RADIUS. Pour chaque utilisateur, nous créons un groupe par nom d'utilisateur et y plaçons une IP avec un TTL égal à son dhcp.lease - dès son expiration, la règle disparaîtra.
Nous pouvons désormais ouvrir l'accès aux services, comme à d'autres groupes, par nom d'utilisateur. Nous avons simplifié les noms d'hôtes lorsqu'ils changent, et nous avons soulagé les ingénieurs réseau car ils n'ont plus besoin de Cisco. Désormais, les ingénieurs enregistrent eux-mêmes l'accès à leurs serveurs.
Isolation
Parallèlement, nous avons commencé à démonter l’isolation. Les responsables de services ont fait un inventaire et nous avons analysé tous nos réseaux. Divisons-les en mêmes groupes, et sur les serveurs nécessaires, les groupes ont été ajoutés, par exemple pour refuser. Désormais, le même isolement de mise en scène aboutit aux règles de refus de la production, mais pas à la production elle-même.
Le schéma fonctionne rapidement et simplement : nous supprimons toutes les ACL des serveurs, déchargeons le matériel et réduisons le nombre de VLAN isolés.
Contrôle d'intégrité
Auparavant, nous avions un déclencheur spécial qui signalait lorsque quelqu'un modifiait manuellement une règle de pare-feu. J'écrivais un énorme linter pour vérifier les règles de pare-feu, c'était difficile. L'intégrité est désormais contrôlée par BEFW. Il veille avec zèle à ce que les règles qu'il établit ne changent pas. Si quelqu'un modifie les règles du pare-feu, cela modifiera tout. « J'ai rapidement créé un proxy pour pouvoir travailler à domicile » : de telles options n'existent plus.
BEFW contrôle l'ipset des services et liste dans befw.conf, les règles des services de la chaîne BEFW. Mais il ne surveille pas les autres chaînes, règles et autres ipsets.
Protection contre les accidents
BEFW stocke toujours le dernier bon état connu directement dans la structure binaire state.bin. Si quelque chose ne va pas, il revient toujours à cet état.bin.
Il s'agit d'une assurance contre le fonctionnement instable du Consul, lorsqu'il n'a pas envoyé de données ou que quelqu'un a fait une erreur et a utilisé des règles qui ne peuvent pas être appliquées. Pour garantir que nous ne nous retrouvons pas sans pare-feu, BEFW reviendra au dernier état si une erreur se produit à un moment donné.
Dans les situations critiques, c'est la garantie que nous nous retrouverons avec un pare-feu fonctionnel. Nous ouvrons tous les réseaux gris dans l'espoir que l'administrateur viendra le réparer. Un jour, je mettrai cela dans les configurations, mais maintenant nous n'avons que trois réseaux gris : 10/8, 172/12 et 192.168/16. Au sein de notre Consul, c’est une fonctionnalité importante qui nous aide à nous développer davantage.
Démo : pendant le reportage, Ivan présente le mode démo de BEFW. C'est plus facile de regarder la démonstration . Code source de démonstration disponible .
Pièges
Je vais vous parler des bugs que nous avons rencontrés.
ipset ajoute l'ensemble 0.0.0.0/0. Que se passe-t-il si vous ajoutez 0.0.0.0/0 à ipset ? Est-ce que toutes les adresses IP seront ajoutées ? L'accès à Internet sera-t-il disponible ?
Non, nous aurons un bug qui nous coûtera deux heures d'arrêt. De plus, le bug n'a pas fonctionné depuis 2016, il se trouve dans RedHat Bugzilla sous le numéro #1297092, et nous l'avons trouvé par hasard - à partir du rapport d'un développeur.
C'est désormais une règle stricte chez BEFW que 0.0.0.0/0 se transforme en deux adresses : 0.0.0.0/1 и 128.0.0.0/1.
ensemble de restauration ipset < fichier. Que fait ipset quand vous lui dites restore? Pensez-vous que cela fonctionne de la même manière qu'iptables ? Est-ce que ça va récupérer des données ?
Rien de tel - cela fait une fusion, et les anciennes adresses ne vont nulle part, vous ne bloquez pas l'accès.
Nous avons trouvé un bug lors du test de l'isolation. Il existe désormais un système assez complexe - au lieu de restore menée create tempalors restore flush temp и restore temp. En fin d'échange : pour l'atomicité, car si vous le faites en premier flush et à ce moment-là, un paquet arrive, il sera rejeté et quelque chose se passera mal. Il y a donc là un peu de magie noire.
consul kv get -datacenter=other. Comme je l'ai dit, nous pensons que nous demandons des données, mais nous obtiendrons soit des données, soit une erreur. Nous pouvons le faire via Consul localement, mais dans ce cas, les deux se bloqueront.
Le client Consul local est un wrapper sur l'API HTTP. Mais il se bloque et ne répond pas à Ctrl+C, ou Ctrl+Z, ou quoi que ce soit, seulement kill -9 dans la prochaine console. Nous avons rencontré ce problème lorsque nous construisions un grand cluster. Mais nous n’avons pas encore de solution ; nous nous préparons à corriger cette erreur dans Consul.
Le chef du consul ne répond pas. Notre maître du centre de données ne répond pas, nous pensons : « Peut-être que l'algorithme de resélection fonctionnera maintenant ?
Non, ça ne marchera pas, et le suivi ne montrera rien : le consul dira qu'il y a un indice d'engagement, qu'un leader a été trouvé, que tout va bien.
Comment pouvons-nous gérer cela ? service consul restart en cron toutes les heures. Si vous disposez de 50 serveurs, ce n’est pas grave. Quand ils seront 16 000, vous comprendrez comment ça marche.
Conclusion
En conséquence, nous avons bénéficié des avantages suivants :
- Couverture à 100 % de toutes les machines Linux.
- Vitesse
- Automatisation.
- Nous avons libéré les ingénieurs matériels et réseaux de l’esclavage.
- Des possibilités d'intégration sont apparues qui sont presque illimitées : même avec Kubernetes, même avec Ansible, même avec Python.
Moins: Consul, avec lequel nous devons désormais vivre, et le coût très élevé de l'erreur. A titre d'exemple, une fois à 6 heures (heure de grande écoute en Russie), j'éditais quelque chose dans les listes de réseaux. À l’époque, chez BEFW, nous ne faisions que réaliser de l’isolation. Je me suis trompé quelque part, il semble que j'ai indiqué le mauvais masque, mais tout est tombé en deux secondes. Le monitoring s’allume, l’accompagnateur de garde arrive en courant : « Nous avons tout ! » Le chef du département est devenu gris lorsqu'il a expliqué à l'entreprise pourquoi cela s'était produit.
Le coût de l’erreur est si élevé que nous avons mis au point notre propre procédure de prévention complexe. Si vous implémentez cela sur un grand site de production, vous n'avez pas besoin de donner un jeton principal sur Consul à tout le monde. Cela finira mal.
Coût. J'ai écrit du code pendant 400 heures seul. Mon équipe de 4 personnes consacre 10 heures par mois à l'accompagnement de chacun. Par rapport au prix de n’importe quel pare-feu nouvelle génération, c’est gratuit.
Plans Le plan à long terme est de trouver un moyen de transport alternatif pour remplacer ou compléter Consul. Ce sera peut-être Kafka ou quelque chose de similaire. Mais dans les années à venir, nous vivrons sur Consul.
Plans immédiats : intégration avec Fail2ban, avec monitoring, avec nftables, éventuellement avec d'autres distributions, métriques, monitoring avancé, optimisation. Le support de Kubernetes est également quelque part dans les plans, car nous avons maintenant plusieurs clusters et nous le souhaitons.
Plus d'informations sur les plans :
- recherche d'anomalies dans le trafic ;
- gestion de cartes de réseau ;
- Prise en charge de Kubernetes ;
- assembler des packages pour tous les systèmes ;
- Interface utilisateur Web.
Nous travaillons constamment à l'extension de la configuration, à l'augmentation des métriques et à l'optimisation.
Rejoignez le projet. Le projet s'est avéré sympa, mais malheureusement, il s'agit toujours d'un projet individuel. Venir à et essayer de faire quelque chose : s'engager, tester, proposer quelque chose, donner son avis.
En attendant, nous nous préparons , qui aura lieu les 6 et 7 avril à Saint-Pétersbourg, et nous invitons les développeurs de systèmes à forte charge . Les orateurs expérimentés savent déjà quoi faire, mais pour ceux qui débutent, nous recommandons au moins . Participer à la conférence en tant que conférencier présente de nombreux avantages. Vous pouvez lire lesquels, par exemple, à la fin .
Source: habr.com