Avec l'aide de ce morceau magique de script Cisco ACI, vous pouvez rapidement configurer un réseau.
L'usine réseau du centre de données Cisco ACI existe depuis cinq ans, mais Habré n'en a pas vraiment parlé, alors j'ai décidé de le réparer un peu. Je vais vous dire d'après ma propre expérience ce que c'est, à quoi ça sert et où il a un râteau.
Qu'est-ce que c'est et d'où vient-il ?
Au moment où ACI (Application Centric Infrastructure) a été annoncé en 2013, les concurrents avançaient sur les approches traditionnelles des réseaux de centres de données de 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 en même temps. L'idée était de déplacer la prise de décision traditionnellement effectuée par un logiciel de commutation propriétaire vers un contrôleur central.
Ce contrôleur aurait une vision unique de tout ce qui se passe et, sur cette base, programmerait le matériel de tous les commutateurs au niveau des règles de traitement des flux spécifiques.
D'autre part, les solutions de réseau superposé 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 connu de cette approche était Nicira, qui avait déjà été acquis par VMWare pour 1,26 milliard de dollars et a donné naissance à l'actuel VMWare NSX. Un peu de piquant à la situation a été ajouté par le fait que les co-fondateurs de Nicira étaient les mêmes personnes qui étaient auparavant à l'origine d'OpenFlow, disant maintenant que pour construire une usine de centres de données .
Et enfin, les puces de commutation disponibles sur le marché libre (ce qu'on appelle le silicium marchand) ont atteint un stade de maturité où elles sont devenues une véritable menace pour les fabricants de commutateurs traditionnels. Si auparavant, chaque fournisseur développait indépendamment des puces pour ses commutateurs, au fil du temps, les puces de fabricants tiers, principalement de Broadcom, ont commencé à réduire la distance avec les puces des fournisseurs en termes de fonctions et les ont dépassées en termes de rapport prix / performances. Par conséquent, beaucoup pensaient que les jours des commutateurs sur les puces de leur propre conception étaient comptés.
ACI est devenue la "réponse asymétrique" de Cisco (plus précisément, sa société Insieme, fondée par ses anciens employés) à tout ce qui précède.
Quelle est la différence avec OpenFlow ?
En termes de répartition des fonctions, ACI est en fait l'opposé d'OpenFlow.
Dans l'architecture OpenFlow, le contrôleur est responsable de l'écriture 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 à des centaines de points du réseau, de sorte que ses performances et sa fiabilité deviennent un goulot d'étranglement dans un grande implémentation.
ACI utilise l'approche inverse : bien sûr, il existe également un contrôleur, mais les commutateurs en reçoivent des politiques déclaratives de haut niveau, et le commutateur lui-même effectue leur rendu dans les détails de paramètres spécifiques du matériel. Le contrôleur peut être redémarré ou complètement éteint, et rien de mal 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 Open vSwitch.
ACI est entièrement construit sur le transport de superposition basé sur VXLAN, mais inclut 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 de la liaison). Les hôtes ne sont pas tenus 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 leur être acheminé.
Les superpositions sont utilisées dans ACI non seulement pour fournir une connectivité flexible via le réseau de transport, mais également pour transférer des méta-informations (elles sont utilisées, par exemple, pour appliquer des politiques de sécurité).
Les puces de Broadcom étaient auparavant utilisées par Cisco dans les commutateurs de la série Nexus 3000. Dans la famille Nexus 9000, spécialement lancée pour prendre en charge l'ACI, un modèle hybride a été initialement implémenté, appelé Merchant +. Le commutateur utilisait simultanément la nouvelle puce Broadcom Trident 2 et une puce complémentaire développée par Cisco, qui met en œuvre toute la magie de l'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 simplement basés sur Trident 2. Cette approche était suffisante pour les deux ou trois premières années de livraisons ACI. Pendant ce temps, Cisco a développé et lancé la prochaine 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 dans l'usine sont totalement conservées. Dans le même temps, le remplissage interne a complètement changé : quelque chose comme un 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 Klose, 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 ils sont nombreux, plus la tolérance aux pannes est élevée (plus la bande passante et la réduction de fiabilité en cas d'accident ou de maintenance d'un Spine sont faibles) et les performances globales. Toutes les connexions externes vont aux commutateurs de niveau feuille : ce sont des serveurs, et s'amarrant avec des réseaux externes via L2 ou L3, et connectant 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, dont il existe 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 en assemble une usine, y compris les paramètres de tous les protocoles de service, donc, soit dit en passant, il est très important de notez les numéros de série de l'équipement en cours d'installation lors de l'installation, de sorte que plus tard vous n'ayez pas à deviner quel commutateur se trouve dans quel rack se trouve. Pour le dépannage, si nécessaire, vous pouvez vous connecter aux commutateurs via SSH : ils reproduisent assez fidèlement les commandes show habituelles de Cisco.
En interne, l'usine utilise le transport IP, il n'y a donc pas de Spanning Tree et autres horreurs du passé dedans : tous les liens sont impliqués, et la convergence en cas de panne est très rapide. Le trafic dans la structure est transmis via des tunnels basés sur VXLAN. Plus précisément, Cisco lui-même appelle l'encapsulation iVXLAN, et il diffère du VXLAN ordinaire en ce que les champs réservés dans l'en-tête du réseau sont utilisés pour transmettre des informations de service, principalement sur la relation du trafic avec le groupe EPG. Cela vous permet d'implémenter 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 permettent à la fois aux segments L2 et aux segments L3 (c'est-à-dire VRF) d'être étirés via le transport IP interne. Dans ce cas, la passerelle par défaut est distribuée. Cela signifie que chaque commutateur est responsable du routage du trafic entrant dans la matrice. En termes de logique de flux de trafic, ACI est similaire à une structure VXLAN/EVPN.
Si oui, quelles sont les différences ? Tout le reste!
La première différence que vous rencontrez avec ACI est la façon dont les serveurs sont connectés au réseau. Dans les réseaux traditionnels, l'inclusion des serveurs physiques et des machines virtuelles va aux VLAN, et tout le reste en découle : connectivité, sécurité, etc. Dans ACI, une conception est utilisée que Cisco appelle EPG (End-point Group), à partir de laquelle il n'y a nulle part où s'enfuir. Est-il possible de l'assimiler à VLAN? Oui, mais dans ce cas, il y a une chance de perdre la plupart de ce que l'ACI donne.
En ce qui concerne EPG, toutes les règles d'accès sont formulées, et dans ACI, le principe de la «liste blanche» est utilisé par défaut, c'est-à-dire que seul le trafic est autorisé, dont le passage est explicitement autorisé. Autrement dit, nous pouvons créer les groupes EPG "Web" et "MySQL" et définir une règle qui autorise la communication entre eux uniquement sur le port 3306. Cela fonctionnera sans être lié 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 à cause de cette fonctionnalité, car elle permet de restreindre l'accès entre les serveurs (virtuels ou physiques - peu importe) sans les faire glisser entre les sous-réseaux, c'est-à-dire sans toucher à l'adressage. Oui, oui, nous savons que personne ne prescrit à la main les adresses IP dans les configurations d'application, n'est-ce pas ?
Les règles de trafic dans ACI sont appelées contrats. Dans un tel contrat, un ou plusieurs groupes ou niveaux d'une application multiniveau deviennent un fournisseur de services (par exemple, un service de base de données), d'autres deviennent un consommateur. Le contrat peut simplement transmettre 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 QoS.
Comment les serveurs entrent-ils dans ces groupes ? S'il s'agit de serveurs physiques ou de quelque chose inclus dans un réseau existant dans lequel nous avons créé un tronc 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, alors il suffit de se référer à l'environnement de virtualisation connecté, et ensuite tout se passera tout seul : un groupe de ports sera créé (en termes de VMWare) pour connecter la VM, les VLAN ou VXLAN nécessaires seront être attribués, ils seront enregistrés sur les ports de commutation nécessaires, etc. Ainsi, bien qu'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'une connectivité intégrée avec VMWare et MS Hyper-V, ainsi que de la prise en charge d'OpenStack et de la virtualisation RedHat. À partir d'un certain moment, le support intégré des plates-formes de conteneurs est également apparu : Kubernetes, OpenShift, Cloud Foundry, alors qu'il concerne à la fois l'application des politiques et la surveillance, c'est-à-dire que l'administrateur réseau peut immédiatement voir sur quels hôtes fonctionnent les pods 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, lorsqu'une VM est renommée ou qu'une balise supplémentaire apparaît dans il. Cisco appelle cela des 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é sous la forme d'EPG sur 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, non liées à des commutateurs, serveurs, etc. spécifiques, vous pouvez donc faire des choses avec eux et des constructions basées sur eux (applications et locataires) qui sont difficiles à faire dans les réseaux ordinaires, comme le clonage. Du coup, disons qu'il est très facile de cloner un environnement de production afin d'obtenir un environnement de test garanti identique à l'environnement de production. Vous pouvez le faire manuellement, mais c'est mieux (et plus facile) via l'API.
En général, la logique de contrôle dans ACI n'est pas du tout similaire à 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 toutes les personnes impliquées dans ACI, après un certain temps, commencent à naviguer dans le modèle objet utilisé pour la gestion et à automatiser quelque chose pour répondre à leurs besoins. La façon la plus simple de le faire est de partir de Python : il existe des outils prêts à l'emploi pratiques pour cela.
Râteau promis
Le principal problème est que beaucoup de choses dans ACI sont faites différemment. Pour commencer à travailler normalement, vous devez vous recycler. Cela est particulièrement vrai pour les équipes d'exploitation réseau des grands clients, où les ingénieurs « prescrivent des VLAN » depuis des années sur demande. Le fait que les VLAN ne soient plus des VLAN et que vous n'ayez plus besoin de créer des VLAN à la main pour établir de nouveaux réseaux dans des hôtes virtualisés fait complètement sauter le toit des réseaux traditionnels et les oblige à s'accrocher à des approches familières. A noter que Cisco a essayé de faire un peu passer la pilule et a ajouté une CLI « NXOS-like » au contrôleur, qui permet de faire la configuration depuis une interface similaire aux switchs traditionnels. Mais encore, pour commencer à utiliser ACI normalement, vous devez comprendre comment cela fonctionne.
En termes de prix, à grande et moyenne échelles, les réseaux ACI ne diffèrent pas réellement des réseaux traditionnels sur les équipements Cisco, puisque les mêmes commutateurs sont utilisés pour les construire (les Nexus 9000 peuvent fonctionner en ACI et en mode traditionnel et sont devenus aujourd'hui les principaux "cheval de bataille" pour les nouveaux projets de centres de données). Mais pour les centres de données de deux commutateurs, la présence de contrôleurs et d'architecture Spine-Leaf, bien sûr, se fait sentir. Récemment, une usine Mini ACI est apparue, dans laquelle deux des trois contrôleurs sont remplacés par des machines virtuelles. Cela réduit la différence de coût, mais il reste toujours. Ainsi, pour le client, le choix est dicté par son intérêt pour les fonctionnalités de sécurité, l'intégration avec la virtualisation, un point de contrôle unique, etc.
Source: habr.com