Avec ce morceau magique de script Cisco ACI, vous pouvez configurer rapidement le réseau.
La fabrique de réseau pour le Datacenter Cisco ACI existe depuis cinq ans, mais il n'y a pas beaucoup d'informations à ce sujet sur Habr, donc j'ai décidé d'y remédier un peu. Je vais partager mon expérience, expliquer ce que c'est, quels en sont les avantages et où se trouvent les écueils.
Qu'est-ce que c'est et d'où vient-il ?
Au moment de l'annonce de l'ACI (Application Centric Infrastructure) en 2013, les approches traditionnelles des réseaux de Datacenter étaient attaquées simultanément par des concurrents de trois côtés.
D'une part, les solutions SDN de « première génération » basées sur OpenFlow promettaient de rendre les réseaux à la fois plus flexibles et moins coûteux. L'idée était de transférer la prise de décision, traditionnellement effectuée par le logiciel propriétaire des commutateurs, vers un contrôleur central.
Ce contrôleur aurait une vision unifiée de tout ce qui se passe et, en fonction de cela, programmerait le matériel de tous les commutateurs en fonction de règles spécifiques pour le traitement des flux.
D'autre part, les solutions réseau en superposition permettaient de réaliser la connectivité souhaitée et les politiques de sécurité sans aucune modification de l'infrastructure physique, en construisant des tunnels logiciels entre des hôtes virtualisés. L'exemple le plus connu de cette approche était la solution de Nicira, qui avait déjà été acquise par VMWare pour 1,26 milliard de dollars et avait donné naissance à l'actuel VMWare NSX. La situation était d'autant plus piquante que les co-fondateurs de Nicira étaient les mêmes personnes qui avaient auparavant contribué aux débuts d'OpenFlow, maintenant affirmant que pour construire la fabrique du Datacenter, .
Enfin, les puces de commutation disponibles sur le marché (ce qu'on appelle le silicium marchand) avaient atteint un niveau de maturité où elles devenaient une véritable menace pour les fabricants traditionnels de commutateurs. Autrefois, chaque fournisseur développait lui-même des puces pour ses commutateurs, mais avec le temps, les puces des fabricants tiers, notamment celles de Brоadcom, avaient commencé à réduire l'écart avec les puces propriétaires en termes de fonctionnalités, et en rapport coût/performance, elles les surpassaient. C'est pourquoi beaucoup considéraient que les jours des commutateurs dotés de puces développées en interne étaient comptés.
L'ACI est devenue la « réponse asymétrique » de Cisco (plus précisément, de la société Insieme, intégrée dans Cisco et fondée par d'anciens employés) à tout cela.
Quelle est la différence avec OpenFlow ?
En termes de répartition des fonctions, l'ACI est en fait l'opposée d'OpenFlow.
Dans l'architecture OpenFlow, le contrôleur est responsable de l'écriture de règles détaillées (flux)
dans le matériel de tous les commutateurs, c'est-à-dire que dans un grand réseau, il peut être responsable de la gestion et, surtout, de la modification de dizaines de millions d'enregistrements dans des centaines de points du réseau, c'est pourquoi sa performance et sa fiabilité dans une grande implémentation deviennent un goulet d'étranglement.
Dans ACI, une approche inverse est utilisée : il y a aussi un contrôleur, mais les commutateurs reçoivent de lui des politiques déclaratives de haut niveau, et leur rendu en détails spécifiques de configuration matérielle est effectué par le commutateur lui-même. Le contrôleur peut être redémarré ou même éteint, et rien de grave ne se produira dans le réseau, sauf, bien sûr, l'absence à ce moment-là de la possibilité de gestion. Il est intéressant de noter qu'il existe des situations dans ACI où OpenFlow est tout de même utilisé, mais localement au sein de l'hôte pour la programmation de l'Open vSwitch.
L'ACI est entièrement construite sur un transport en overlay basé sur VXLAN, mais elle inclut également, dans le cadre d'une solution unique, le transport IP sous-jacent. Cisco a appelé cela « overlay intégré ». En tant que point de terminaison des overlays dans ACI, des commutateurs de la fabrique sont utilisés dans la plupart des cas (ils le font à la vitesse du canal). Les hôtes n'ont pas besoin de savoir quoi que ce soit sur la fabrique, l'encapsulation, etc., cependant, dans certains cas (par exemple, pour connecter des hôtes OpenStack), le trafic VXLAN peut également les atteindre.
Les overlays en ACI sont utilisés non seulement pour assurer une connectivité flexible via le réseau de transport, mais aussi pour transmettre des métainformations (elles sont utilisées, par exemple, pour l'application de politiques de sécurité).
Les puces de Broadcom ont été utilisées par Cisco dans les commutateurs de la série Nexus 3000. Dans la famille Nexus 9000, spécialement conçue pour prendre en charge l'ACI, un modèle hybride a été initialement mis en œuvre, appelé Merchant+. Dans le commutateur, la nouvelle puce Broadcom Trident 2 et une puce complémentaire développée par Cisco, qui exécute toute la magie de l'ACI, ont été utilisées simultanément. Cela a apparemment permis d'accélérer le lancement du produit et de réduire le prix du commutateur à un niveau proche de celui des modèles uniquement basés sur le Trident 2. Cette approche a suffi pour les deux à trois premières années de fourniture de l'ACI. Pendant ce temps, Cisco a développé et lancé sur le marché la génération suivante de Nexus 9000, déjà basée sur ses propres puces, avec des performances et un ensemble de fonctionnalités améliorées, mais au même niveau de prix. Les spécifications externes, en termes d'interaction dans l'usine, sont restées complètement intactes. Cependant, l'intérieur a complètement changé : c'est comme une refonte, mais pour le matériel.
Comment est architecturé Cisco ACI
Dans le cas le plus simple, l'ACI est construit selon une topologie de réseau Clos, ou, comme on l'appelle souvent, Spine-Leaf. Il peut y avoir entre deux (ou un, si la tolérance aux pannes ne nous préoccupe pas) et six commutateurs de niveau Spine. Ainsi, plus il y en a, plus la tolérance aux pannes est élevée (la réduction de bande passante et de fiabilité lors d'une défaillance ou d'une maintenance d'un Spine est plus faible) et la performance globale. Toutes les connexions externes passent par les commutateurs de niveau Leaf : il s'agit à la fois de serveurs, d'interconnexions avec des réseaux externes par L2 ou L3, et de connexions aux contrôleurs APIC. En général, avec l'ACI, non seulement la configuration, mais aussi la collecte de statistiques, la surveillance des pannes, etc. — tout cela se fait via l'interface des contrôleurs, qui, dans des déploiements de taille normale, sont trois.
Il n'est jamais nécessaire de se connecter aux commutateurs via la console, même pour démarrer le réseau : le contrôleur découvre lui-même les commutateurs et les assemble en une usine, y compris les paramètres de tous les protocoles de service. C'est pourquoi, d'ailleurs, il est très important d'écrire les numéros de série des équipements installés lors du montage, afin de ne pas se demander quel commutateur se trouve dans quelle baie. Pour le dépannage, il est possible de se connecter aux commutateurs via SSH si nécessaire : ils reproduisent assez fidèlement les commandes de base de Cisco.
À l'intérieur, l'usine utilise un transport IP, donc il n'y a pas de Spanning Tree ni d'autres horreurs du passé : tous les liens sont utilisés, et la convergence en cas de défaillance est très rapide. Le trafic dans l'usine est transmis via des tunnels basés sur VXLAN. Pour être plus précis, Cisco appelle cette encapsulation iVXLAN, qui diffère du VXLAN standard par le fait que les champs réservés dans l'en-tête réseau sont utilisés pour transmettre des informations de service, principalement sur la relation du trafic avec le groupe EPG. Cela permet d'implémenter des règles d'interaction entre les groupes dans le matériel, en utilisant leurs numéros tout comme les adresses sont utilisées dans les listes d'accès ordinaires.
Les tunnels permettent d'étendre à la fois les segments L2 et L3 (c'est-à-dire VRF) via le transport IP interne. Le gateway par défaut est distribué. Cela signifie que chaque commutateur s'occupe de la routage du trafic entrant dans l'usine. En termes de logique de transmission de trafic, l'ACI ressemble à une usine basée sur VXLAN/EVPN.
Si oui, quelles sont les différences ? Dans tout le reste !
La première différence que l'on rencontre dans l'ACI est la façon dont les serveurs sont connectés au réseau. Dans les réseaux traditionnels, la connexion tant des serveurs physiques que des machines virtuelles se fait dans des VLANs, et tout le reste dépend de cela : connectivité, sécurité, etc. Dans l'ACI, en revanche, une construction appelée EPG (End-point Group) est utilisée, dont on ne peut pas se passer. Peut-on l'assimiler à un VLAN ? Oui, mais dans ce cas, il y a un risque de perdre une grande partie de ce que l'ACI offre.
Toutes les règles d'accès sont formulées par rapport à l'EPG, et dans l'ACI, par défaut, le principe de la « liste blanche » est utilisé, c'est-à-dire que seul le trafic explicitement autorisé est permis. Cela signifie que nous pouvons créer des groupes EPG « Web » et « MySQL » et définir une règle autorisant l'interaction entre eux uniquement sur le port 3306. Cela fonctionnera sans lien aux adresses réseau et même au sein d'un même sous-réseau !
Nous avons des clients qui ont choisi l'ACI précisément en raison de cette fonctionnalité, car elle permet de restreindre les accès entre les serveurs (virtuels ou physiques - peu importe), sans les déplacer entre les sous-réseaux, et donc sans toucher à l'adressage. Oui, nous savons, personne n'écrit les configurations à la main, n'est-ce pas ? adresses IP dans les configurations d'applications, n'est-ce pas ?
Les règles de routage du trafic dans ACI sont appelées des contrats. Dans un tel contrat, un ou plusieurs groupes ou niveaux dans une application à plusieurs niveaux deviennent le fournisseur de services (par exemple, un service de base de données), tandis que d'autres en sont les consommateurs. Le contrat peut simplement laisser passer le trafic, ou faire quelque chose de plus sophistiqué, comme le rediriger vers un pare-feu ou un répartiteur de charge, et changer également la valeur QoS.
Comment les serveurs sont-ils intégrés dans ces groupes ? S'il s'agit de serveurs physiques ou de quelque chose intégré dans un réseau existant, pour lequel nous avons créé un tronc VLAN, il faudra indiquer le port du commutateur et le VLAN utilisé pour les placer dans l'EPG. Comme nous le voyons, les VLAN apparaissent là où ils sont indispensables.
En revanche, si les serveurs sont des machines virtuelles, il suffit de référencer l'environnement de virtualisation connecté, et tout se mettra en place automatiquement : un groupe de ports sera créé (pour parler en termes de VMWare) pour connecter les VM, les VLAN ou VXLAN nécessaires seront assignés sur les ports appropriés des commutateurs, etc. Ainsi, bien que l'ACI soit construit autour d'un réseau physique, la connexion pour les serveurs virtuels semble beaucoup plus simple que pour les physiques. L'ACI intègre déjà des liaisons avec VMWare et MS Hyper-V, ainsi qu'un support pour OpenStack et RedHat Virtualization. Depuis un certain moment, un support intégré pour les plateformes de conteneurs a également été ajouté : Kubernetes, OpenShift, Cloud Foundry, et cela inclut l'application de politiques et la surveillance, ce qui permet à l'administrateur réseau de voir immédiatement sur quels hôtes quels pods fonctionnent et dans quels groupes ils se trouvent.
En plus de l'inclusion dans un groupe de ports spécifique, les serveurs virtuels possèdent des propriétés supplémentaires : nom, attributs, etc., qui peuvent être utilisés comme critères pour les déplacer dans un autre groupe, par exemple, lors du renommage d'une VM ou de l'ajout d'un tag supplémentaire. Cisco appelle cela des groupes de micro-segmentation, bien qu'en réalité, la possibilité de créer de nombreux segments de sécurité sous forme d'EPG dans le même sous-réseau soit également une forme de micro-segmentation. Enfin, le fournisseur en sait mieux.
Les EPG sont des constructions purement logiques, non liées à des commutateurs, serveurs, etc. spécifiques, ce qui permet des opérations difficiles à réaliser dans des réseaux classiques, comme la clonage. Par conséquent, il est très facile de créer un clone d'un environnement de production pour obtenir un environnement de test systématiquement identique à la production. Cela peut être fait manuellement, mais il est préférable (et plus simple) de le faire via l'API.
En général, la logique de gestion dans ACI est complètement différente de ce que l'on rencontre habituellement
dans les réseaux traditionnels de Cisco : l'interface logicielle est primaire, tandis que l'interface graphique ou la CLI sont secondaires, car elles fonctionnent via la même API. Ainsi, presque tout le monde qui travaille avec ACI finit par s'orienter dans le modèle d'objet utilisé pour la gestion et à automatiser certaines tâches selon ses besoins. C'est le plus facile à faire depuis Python : il existe des outils pratiques prêts à l'emploi.
Les pièges promis
Le principal problème est que de nombreuses choses dans ACI sont faites différemment. Pour commencer à travailler correctement avec, il faut réapprendre. Cela concerne particulièrement les équipes de réseau dans de grandes entreprises, où les ingénieurs ont passé des années à s'occuper de la "configuration des VLANs" sur demande. Ce qui était auparavant un VLAN n'est plus un VLAN, et il n'est même plus nécessaire de créer des VLANs manuellement pour trancher de nouveaux réseaux sur des hôtes virtualisés, ce qui déroute complètement les professionnels du réseau traditionnels et les pousse à s'accrocher à leurs approches habituelles. Il convient de noter que Cisco a essayé d'adoucir un peu la transition en ajoutant une CLI "similaire à NXOS" dans le contrôleur, permettant la configuration via une interface ressemblant à celle des commutateurs traditionnels. Cependant, pour commencer à utiliser ACI correctement, il faudra comprendre comment cela fonctionne.
En ce qui concerne les prix pour les réseaux ACI à grande et moyenne échelle, il n'y a pas de véritable différence par rapport aux réseaux traditionnels sur équipement Cisco, car ils utilisent les mêmes commutateurs (les Nexus 9000 peuvent fonctionner à la fois en mode ACI et en mode traditionnel et sont devenus le « cheval de bataille » principal pour les nouveaux projets de centre de données). En revanche, pour les centres de données utilisant deux commutateurs, la présence de contrôleurs et l'architecture Spine-Leaf se font bien sentir. Récemment, une Mini ACI-fabrique a été mise en place, où deux des trois contrôleurs sont remplacés par des machines virtuelles. Cela permet de réduire l'écart de coût, mais il reste néanmoins. Ainsi, le choix pour le client dépend de son intérêt pour les fonctionnalités de sécurité, l'intégration avec la virtualisation, le point de contrôle unique, et plus encore.
Source : habr.com
