De rien au centre de données avec VXLAN / EVPN ou comment cuisiner Cumulus Linux. Partie 1

Au cours des six derniers mois, nous avons réussi à travailler sur un projet important et intéressant, qui comprenait tout: de l'installation de l'équipement à la création d'un seul domaine VXLAN / EVPN dans 4 centres de données. Car J'avais beaucoup d'expérience et beaucoup de bosses dans le processus, j'ai décidé qu'écrire quelques articles sur ce sujet serait la meilleure solution. J'ai décidé de rendre la première partie plus générale et introductive. La conception cible de l'usine sera révélée dans la section suivante.

Présentation de Cumulus Linux. Installation matérielle et configuration initiale

Voici une introduction au début des travaux:

1. Équipement acheté
2. Racks loués
3. Lignes vers les anciens centres de données posées

Le premier matériel à livrer était 4 x Mellanox SN2410 avec Cumulus Linux pré-installé. Au début, nous ne comprenions toujours pas à quoi tout ressemblerait (cela ne se développera qu'au stade de l'implémentation VXLAN / EVPN), par conséquent, nous avons décidé de les élever comme de simples commutateurs L3 avec CLAG (Analogue of MLAG from Cumulus). Auparavant, ni moi ni mes collègues n'avions beaucoup d'expérience avec Cumulus, donc tout était dans une certaine mesure nouveau, puis à peu près cela.

Pas de licence - pas de ports

Par défaut, lorsque vous allumez l'appareil, seuls 2 ports vous sont disponibles: console et eth0 (également appelé port de gestion). Pour débloquer les ports 25G / 100G, vous devez ajouter une licence. Et il devient immédiatement clair que Linux au nom du logiciel n'est pas pour rien, puisque après l'installation de la licence, vous devez redémarrer le démon switchd via «systemctl restart switchd.service» (en fait, l'absence de licence empêche simplement ce démon de démarrer).



La prochaine chose qui vous rappellera immédiatement qu'il s'agit toujours de Linux, sera la mise à jour de l'appareil en utilisant la mise à niveau apt-get, comme dans un Ubuntu ordinaire, mais il n'est pas toujours possible de mettre à jour de cette façon. Lorsque vous passez d'une version à une autre, par exemple de la version 3.1.1 à la version 4.1.1, vous devez installer une nouvelle image, ce qui implique de réinitialiser les configurations par défaut. Mais cela enregistre que DHCP est activé sur l'interface de gestion dans la configuration par défaut, ce qui vous permet de reprendre le contrôle.

Système de validation

En tant que personne qui a beaucoup travaillé avec Juniper, pour moi des choses comme les rollbacks, la validation de validation, etc. n'étaient pas nouveaux, mais ont réussi à marcher sur quelques râteaux.



La première chose que j'ai rencontrée était la numérotation de retour arrière pour cumulus, en raison de l'habitude de restaurer 1 == dernière configuration de travail. Je pilote cette commande avec une grande confiance pour annuler les dernières modifications. Mais quelle a été ma surprise lorsque le matériel a tout simplement disparu sous contrôle, et pendant un certain temps, je n'ai pas compris ce qui s'était passé. Puis, après avoir lu la documentation de cumulus, il est devenu clair ce qui s'était passé: en exécutant la commande «net rollback 1» au lieu de revenir à la dernière configuration, je suis revenu à la configuration du PREMIER appareil. (Et encore une fois, DHCP a enregistré du fiasco dans la configuration par défaut)





La deuxième chose à laquelle j'ai dû faire face était l'algorithme de confirmation de validation: contrairement à l'habituel «commit confirm 10», où dans les 10 minutes vous devez à nouveau écrire «commit», Cumulus avait sa propre vision de cette fonctionnalité. Votre «confirmation de validation» consiste simplement à appuyer sur Entrée après avoir entré une commande, ce qui peut vous jouer une blague cruelle si la connectivité n'est pas perdue immédiatement après la validation.

Première topologie

L'étape suivante consistait à élaborer la logique des commutateurs entre eux, à ce stade, le matériel était seulement installé et testé, il n'était pas encore question de schémas cibles. Mais l'une des conditions était que les serveurs connectés à différentes paires MLAG doivent être dans le même domaine L2. Je ne voulais pas faire de l'une des paires une simple L2, et il a donc été décidé d'augmenter la connectivité L3 via SVI, OSPF a été choisi pour le routage, car il était déjà utilisé dans les centres de données plus anciens, ce qui facilitait la connexion de l'infrastructure à l'étape suivante.







Ce diagramme montre le diagramme physique + la division des appareils en paires, tous les liens du diagramme fonctionnent en mode Trunk.







Comme mentionné, toute la connectivité L3 se fait via SVI, par conséquent, seuls 2 appareils sur 4 ont une adresse IP dans chaque Vlan, ce qui vous permet de créer une sorte de bundle L3 p2p.

Commandes de base pour les personnes intéressées

Conclusion

J'espère que quelqu'un trouvera cet article intéressant. J'aimerais voir des commentaires: ce qu'il faut ajouter et ce qui est complètement inutile. Dans le prochain article, nous passerons déjà au plus intéressant - à la conception du réseau cible et à la configuration VXLAN / EVPN. Et à l'avenir, un article sur l'automatisation VXLAN / EVPN à l'aide de Python est possible.