Avec cette pièce magique du script Cisco ACI, vous pouvez rapidement configurer votre réseau.L'usine de réseau pour le centre de données Cisco ACI existe depuis cinq ans, mais rien n'a été dit à ce sujet chez Habr, j'ai donc décidé de le réparer un peu. Je vais vous dire de ma propre expérience ce que c'est, à quoi il est bon et où il a un râteau.
De quoi s'agit-il et d'où vient-il?
Au moment de l'annonce de ACI (Application Centric Infrastructure) en 2013, les concurrents attaquaient les approches traditionnelles des réseaux de centres de données sur trois côtés à la fois.
D'une part, les solutions SDN de «première génération» basées sur OpenFlow promettaient de rendre les réseaux plus flexibles et moins chers à la fois. L'idée était de prendre des décisions, traditionnellement effectuées par le logiciel propriétaire des commutateurs, sur le contrôleur central.
Ce contrôleur aurait une vision unique de tout ce qui se passait et, sur cette base, programmerait le matériel de tous les commutateurs au niveau des règles de traitement de flux spécifiques.
D'autre part, les solutions réseau de superposition ont permis de mettre en œuvre les politiques de connectivité et de sécurité nécessaires sans aucune modification du réseau physique, en créant des tunnels logiciels entre les hôtes virtualisés. L'exemple le plus célèbre de cette approche a été la décision de Nicira, qui à cette époque avait déjà été acquise par VMWare pour 1,26 milliard de dollars et a donné naissance à l'actuel VMWare NSX. À un certain point de la situation, Nicira a été cofondée par les mêmes personnes qui se tenaient auparavant aux origines d'OpenFlow, affirmant maintenant
qu'OpenFlow ne convient pas à la construction d'une usine de centre de données.
Enfin, les puces de commutation disponibles sur le marché libre (ce qu'on appelle le silicium marchand) ont atteint un degré de maturité auquel elles sont devenues une menace réelle pour les fabricants de commutateurs traditionnels. Auparavant, chaque fournisseur développait lui-même des puces pour ses commutateurs, mais au fil du temps, les puces de fabricants tiers, principalement de Br®adcom, ont commencé à réduire la distance avec les puces du fournisseur en termes de fonctions et en termes de rapport prix / performances qu'elles dépassaient. Par conséquent, beaucoup pensaient que les jours des commutateurs sur des puces de leur propre conception étaient comptés.
ACI était la «réponse asymétrique» de Cisco (ou plutôt, Insieme, qui a été fondée par ses anciens employés), à tout cela.
Quelle est la différence avec OpenFlow?
En termes de distribution des fonctions, ACI est en fait l'opposé d'OpenFlow.
Dans l'architecture OpenFlow, le contrôleur est responsable de la prescription des règles détaillées (flux)
dans le matériel de tous les commutateurs, c'est-à-dire dans un grand réseau, il peut être responsable de la maintenance et, surtout, de la modification de dizaines de millions d'enregistrements sur des centaines de points du réseau, donc ses performances et sa fiabilité dans une mise en œuvre à grande échelle deviennent un goulot d'étranglement.
ACI utilise l'approche inverse: le contrôleur existe bien sûr également, mais les commutateurs reçoivent de lui des politiques déclaratives de haut niveau, et le commutateur lui-même les rend dans les détails des paramètres spécifiques du matériel. Le contrôleur peut être redémarré ou éteint complètement, et rien de mauvais n'arrivera au réseau, sauf, bien sûr, le manque de contrôle en ce moment. Fait intéressant, il existe des situations dans ACI dans lesquelles OpenFlow est toujours utilisé, mais localement au sein de l'hôte pour la programmation d'Open vSwitch.
ACI est entièrement construit sur le transport de superposition basé sur VXLAN, mais inclut en même temps le transport IP sous-jacent dans le cadre d'une solution unique. Cisco a appelé cela le terme «superposition intégrée». En tant que point de terminaison pour les superpositions dans ACI, dans la plupart des cas, des commutateurs d'usine sont utilisés (ils le font à la vitesse du canal). Les hôtes ne sont pas tenus de connaître quoi que ce soit sur l'usine, les encapsulations, etc., cependant, dans certains cas (par exemple, pour connecter des hôtes OpenStack), le trafic VXLAN peut également leur être apporté.
Les superpositions sont utilisées dans ACI non seulement pour fournir une connectivité flexible via le réseau de transport, mais aussi pour transmettre des méta-informations (elles sont utilisées, par exemple, pour appliquer des politiques de sécurité).
Les puces Broadcom étaient auparavant utilisées par Cisco dans la série de commutateurs Nexus 3000. La famille Nexus 9000, spécialement conçue pour prendre en charge ACI, a initialement implémenté un modèle hybride appelé Merchant +. Le commutateur utilisait simultanément la nouvelle puce Broadcom Trident 2 et la puce de développement Cisco qui la complète, réalisant toute la magie d'ACI. Apparemment, cela a permis d'accélérer la sortie du produit et de réduire le prix du commutateur à un niveau proche des modèles juste pour Trident 2. Cette approche était suffisante pour les deux à trois premières années de fourniture d'ACI. Pendant ce temps, Cisco a développé et lancé la nouvelle génération de Nexus 9000 sur ses propres puces avec plus de performances et de fonctionnalités, mais au même niveau de prix. Les spécifications externes en termes d'interaction en usine sont entièrement préservées. Dans le même temps, le remplissage interne a complètement changé: quelque chose comme le refactoring, mais pour le fer.
Fonctionnement de l'architecture Cisco ACI
Dans le cas le plus simple, ACI est construit sur la topologie du réseau Clos ou, comme on dit souvent, Spine-Leaf. Les commutateurs au niveau de la colonne vertébrale peuvent aller de deux (ou un, si nous ne nous soucions pas de la tolérance aux pannes) à six. En conséquence, plus il y en a, plus la tolérance aux pannes (réduction de la bande passante et de la fiabilité en cas d'accident ou de maintenance d'une colonne vertébrale) et les performances globales sont élevées. Toutes les connexions externes vont aux commutateurs de niveau feuille: ce sont les serveurs, et la connexion aux réseaux externes via L2 ou L3, et la connexion des contrôleurs APIC. En général, avec ACI, non seulement la configuration, mais aussi la collecte de statistiques, la surveillance des pannes, etc. - tout se fait via l'interface des contrôleurs, qui sont trois dans les implémentations de taille standard.
Vous n'avez jamais besoin de vous connecter aux commutateurs avec la console, même pour démarrer le réseau: le contrôleur lui-même détecte les commutateurs et récupère l'usine à partir d'eux, y compris les paramètres de tous les protocoles de service.Par conséquent, il est très important d'enregistrer les numéros de série de l'équipement installé lors de l'installation afin que vous n'ayez pas à deviner quel commutateur quel rack est situé. Pour dépanner, vous pouvez vous connecter aux commutateurs via SSH si nécessaire: ils utilisent les commandes Cisco show habituelles assez soigneusement.
À l'intérieur, l'usine utilise le transport IP, il n'y a donc pas de Spanning Tree et d'autres horreurs du passé: tous les liens sont impliqués et la convergence en cas de panne est très rapide. Le trafic d'usine est transmis via des tunnels VXLAN. Plus précisément, Cisco lui-même appelle l'encapsulation iVXLAN, et il diffère du VXLAN habituel en ce que les champs réservés dans l'en-tête du réseau sont utilisés pour transmettre des informations de surcharge, principalement sur la relation du trafic avec le groupe EPG. Cela vous permet de mettre en œuvre les règles d'interaction entre les groupes dans l'équipement, en utilisant leurs numéros de la même manière que les adresses sont utilisées dans les listes d'accès ordinaires.
Les tunnels vous permettent de vous étirer à travers le transport IP interne et les segments L2 et L3 (c'est-à-dire VRF). Dans ce cas, la passerelle par défaut est distribuée. Cela signifie que chaque commutateur est impliqué dans l'acheminement du trafic entrant dans l'usine. En termes de logique de transfert de trafic, ACI est similaire à une usine basée sur VXLAN / EVPN.
Si oui, quelles sont les différences? Pour le reste!
La principale différence que vous rencontrez dans ACI est la façon dont les serveurs sont connectés au réseau. Dans les réseaux traditionnels, l'inclusion de serveurs physiques et de machines virtuelles va aux VLAN, et tout le reste en danse: connectivité, sécurité, etc. L'ACI utilise une conception que Cisco appelle EPG (End-point Group), d'où il n'y a nulle part s'échapper. Est-il possible de l'assimiler à un VLAN? Oui, mais dans ce cas, il y a une chance de perdre la plupart de ce que donne ACI.
Concernant EPG, toutes les règles d'accès sont formulées, et l'ACI utilise par défaut le principe de la «liste blanche», c'est-à-dire que seul le trafic est autorisé, dont la transmission est explicitement autorisée. Autrement dit, nous pouvons créer des groupes EPG «Web» et «MySQL» et définir une règle qui autorise l'interaction entre eux uniquement sur le port 3306. Cela fonctionnera sans référence aux adresses réseau et même au sein du même sous-réseau!
Nous avons des clients qui ont choisi ACI précisément en raison de cette fonctionnalité, car elle vous permet de restreindre l'accès entre les serveurs (virtuels ou physiques - peu importe) sans les faire glisser entre les sous-réseaux, et donc sans toucher à l'adressage. Oui, oui, nous savons que personne ne prescrit les adresses IP dans les configurations d'application avec ses mains, non?
Les règles de circulation ACI sont appelées contrats. Dans un tel contrat, un ou plusieurs groupes ou niveaux dans une application à plusieurs niveaux deviennent un fournisseur de services (par exemple, un service de base de données), d'autres deviennent un consommateur. Un contrat peut simplement ignorer le trafic, ou il peut faire quelque chose de plus délicat, par exemple, le diriger vers un pare-feu ou un équilibreur, et également modifier la valeur de QoS.
Comment les serveurs entrent-ils dans ces groupes? S'il s'agit de serveurs physiques ou de quelque chose connecté au réseau existant dans lequel nous avons créé la jonction VLAN, alors pour les placer dans l'EPG, vous devrez pointer vers le port du commutateur et le VLAN utilisé dessus. Comme vous pouvez le voir, les VLAN apparaissent là où vous ne pouvez pas vous en passer.
Si les serveurs sont des machines virtuelles, il suffit de se référer à l'environnement de virtualisation connecté, puis tout se passera de lui-même: un groupe de ports (en termes de VMWare) sera créé pour connecter la VM, les VLAN ou VXLAN nécessaires seront attribués, ils seront enregistrés sur les ports de commutation nécessaires, etc. Donc, bien que ACI soit construit autour d'un réseau physique, les connexions pour les serveurs virtuels semblent beaucoup plus simples que pour les serveurs physiques. ACI dispose déjà d'un ensemble avec VMWare et MS Hyper-V, ainsi que la prise en charge de la virtualisation OpenStack et RedHat. À un moment donné, la prise en charge intégrée des plates-formes de conteneurs est apparue: Kubernetes, OpenShift, Cloud Foundry, et elle s'applique à la fois à l'application et à la surveillance des stratégies, c'est-à-dire que l'administrateur réseau peut immédiatement voir quels hôtes fonctionnent sur quels hôtes et à quels groupes ils appartiennent.
En plus d'être inclus dans un groupe de ports particulier, les serveurs virtuels ont des propriétés supplémentaires: nom, attributs, etc., qui peuvent être utilisées comme critères pour les transférer vers un autre groupe, par exemple, lorsque vous renommez une machine virtuelle ou lorsqu'elle a une balise supplémentaire. Cisco appelle ces groupes de micro-segmentation, bien que dans l'ensemble, la conception elle-même avec la possibilité de créer de nombreux segments de sécurité comme EPG dans le même sous-réseau soit également une micro-segmentation. Eh bien, le vendeur sait mieux.
Les EPG eux-mêmes sont des constructions purement logiques qui ne sont pas liées à des commutateurs, serveurs, etc. spécifiques, de sorte qu'avec eux et les constructions basées sur eux (applications et locataires), vous pouvez faire des choses difficiles à faire sur des réseaux réguliers, par exemple à cloner. Par conséquent, disons qu'il est très facile de créer un clone d'un environnement productif afin d'obtenir un environnement de test qui est garanti identique au productif. Cela peut être fait manuellement, mais mieux (et plus facilement) - via l'API.
En général, la logique de contrôle dans ACI est complètement différente de ce que vous rencontrez habituellement
dans les réseaux traditionnels du même Cisco: l'interface logicielle est principale et l'interface graphique ou la CLI sont secondaires, car elles fonctionnent via la même API. Par conséquent, presque tous ceux qui traitent avec ACI, après un certain temps, commencent à naviguer dans le modèle d'objet utilisé pour le contrôle et à automatiser quelque chose pour leurs besoins. La façon la plus simple de le faire est d'utiliser Python: il existe des outils prêts à l'emploi pratiques.
Râteau promis
Le problème principal est que beaucoup de choses dans ACI sont faites différemment. Pour commencer à travailler avec elle normalement, vous devez réapprendre. Cela est particulièrement vrai pour les équipes d'exploitation de réseau chez les gros clients, où les ingénieurs sont engagés depuis des années dans la «prescription de VLAN» pour les applications. Le fait que maintenant les VLAN ne sont plus des VLAN, et pour installer de nouveaux réseaux dans des hôtes virtualisés, vous n'avez pas du tout besoin de créer des VLAN avec vos mains, "époustoufle" complètement les networkers traditionnels et vous oblige à vous accrocher à des approches familières. Il convient de noter que Cisco a essayé d'adoucir légèrement la pilule et a ajouté une CLI "NXOS-like" au contrôleur, qui vous permet de configurer à partir d'une interface similaire aux commutateurs traditionnels. Mais encore, pour commencer à utiliser ACI normalement, vous devrez comprendre comment cela fonctionne.
Du point de vue du prix sur les réseaux ACI de grande et moyenne taille, il n'est pratiquement pas différent des réseaux traditionnels sur les équipements Cisco, car les mêmes commutateurs sont utilisés pour les construire (le Nexus 9000 peut fonctionner à la fois en ACI et en mode traditionnel, et maintenant le «cheval de bataille» principal pour les nouveaux projets de centres de données). Mais pour les centres de données à deux commutateurs, la disponibilité des contrôleurs et de l'architecture Spine-Leaf, bien sûr, se fait sentir. Une usine Mini ACI est récemment apparue, dans laquelle deux des trois contrôleurs sont remplacés par des machines virtuelles. Cela vous permet de réduire la différence de coût, mais cela persiste. Ainsi, pour le client, le choix est dicté par son intérêt pour les fonctions de sécurité, l'intégration avec la virtualisation, un point de gestion unique et plus encore.