Évaluez les liaisons dans la partie médiane du schéma. Nous y reviendrons plus tard
À un moment donné, vous pourriez réaliser que de grands réseaux complexes en L2 sont irrémédiablement malades. En premier lieu, en raison des problèmes liés au traitement du trafic BUM et à l' fonctionnement du protocole STP. En second lieu, en raison d'une architecture globalement obsolète. Cela entraîne des problèmes désagréables tels que les temps d'arrêt et des difficultés de gestion.
Nous avons eu deux projets parallèles où les clients ont objectivement évalué tous les avantages et inconvénients des options et ont choisi deux solutions d'overlay différentes que nous avons mises en œuvre.
Nous avons eu l'occasion de comparer précisément la mise en œuvre. Pas l'exploitation, de cela il vaut mieux parler dans deux ou trois ans.
Alors, qu'est-ce qu'une fabric réseau avec des réseaux superposés et le SDN ?
Que faire des problèmes persistants de l'architecture réseau classique ?
Chaque année, de nouvelles technologies et idées font leur apparition. En pratique, le besoin urgent de remodeler les réseaux n'est pas apparu depuis longtemps, car il est encore possible de tout faire manuellement selon les anciennes méthodes éprouvées. Eh bien, et alors, même si nous sommes au vingt et unième siècle ? Après tout, un admin doit travailler et non rester coincé dans son bureau.
Ensuite, a commencé le boom de construction de grands centres de données. À ce moment-là, il est devenu clair que la limite de développement de l'architecture classique avait été atteinte non seulement en termes de fonctionnalité, de tolérance aux pannes, de scalabilité. Et l'une des solutions à ces problèmes a été l'idée de construire des réseaux superposés sur un backbone routable.
De plus, avec l'augmentation des échelles des réseaux, le problème de la gestion de telles fabric à grande échelle est devenu crucial, d'où l'émergence de solutions de réseaux définis par logiciel permettant de gérer toute l'infrastructure réseau comme un tout. Et lorsque le réseau est géré depuis un point central, il devient plus facile pour d'autres composants de l'infrastructure IT d'interagir avec lui, et ces processus d'interaction sont plus simples à automatiser.
Pratiquement chaque grand fabricant non seulement d'équipements réseau, mais aussi de virtualisation, propose dans son portefeuille des variantes de telles solutions.
Il ne reste plus qu'à comprendre ce qui convient à quels besoins. Par exemple, pour les grandes entreprises disposant d'une bonne équipe de développeurs et d'exploitation, les solutions standard des fournisseurs ne satisfont pas toujours tous les besoins, et elles se tournent vers le développement de leurs propres solutions SD (Software Defined). Par exemple, ce sont des fournisseurs de cloud qui élargissent constamment leur gamme de services offerts à leurs clients, et les solutions standard ne peuvent tout simplement pas suivre leurs besoins.
Pour les entreprises de taille moyenne, les fonctionnalités proposées par le fournisseur sous forme de solution standard suffisent dans 99 % des cas.
Qu'est-ce que les réseaux superposés ?
Quelle est l'idée des réseaux superposés ? En substance, vous prenez un réseau routable classique et construisez un autre réseau par-dessus pour obtenir plus de fonctionnalités. Le plus souvent, il s'agit d'une répartition efficace de la charge sur les équipements et les lignes de communication, d'une augmentation significative de la scalabilité, d'une fiabilité améliorée et d'un tas d'avantages en matière de sécurité (grâce à la segmentation). De plus, les solutions SDN offrent une administration flexible et très, très conviviale, rendant le réseau plus transparent pour ses utilisateurs.
En général, si les réseaux locaux avaient été inventés dans les années 2010, ils ne ressembleraient pas du tout à ce qui nous est légué par les militaires des années 1970.
D'un point de vue technologique dans la construction d'usines utilisant des réseaux superposés, il existe actuellement de nombreuses réalisations de fabricants et de projets Internet RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve, etc.). Oui, il existe des normes, mais la mise en œuvre de ces normes par différents fabricants peut varier, c'est pourquoi, lors de la création de telles usines, il est encore théoriquement possible de se passer totalement de l'enfermement fournisseur.
La situation avec les solutions SD est encore plus compliquée, chaque fournisseur a sa propre vision. Il existe des solutions complètement ouvertes, que l'on peut théoriquement modifier soi-même, ainsi que des solutions totalement fermées.
Cisco propose sa version de SDN pour les centres de données — ACI. Évidemment, c'est une solution 100 % propriétaire en ce qui concerne le choix du matériel réseau, mais elle s'intègre entièrement avec des systèmes de virtualisation, de containerisation, de sécurité, d'orchestration, des équilibreurs de charge, etc. Mais en réalité, c'est quand même une sorte de boîte noire, sans possibilité d'accès complet à tous les processus internes. Tous les clients ne se montrent pas d'accord avec cette option, car on dépend entièrement de la qualité du code de la solution et de sa mise en œuvre, mais d'un autre côté, le fabricant dispose d'un des meilleurs services de support technique au monde et possède une équipe dédiée uniquement à cette solution. Pour le premier projet, la solution choisie était précisément Cisco ACI.
Pour le deuxième projet, une solution de Juniper a été sélectionnée. Le fabricant dispose également de son propre SDN pour les centres de données, mais le client a décidé de renoncer à l'implémentation de SDN. La technologie de construction du réseau choisie était une usine EVPN VXLAN sans utilisation de contrôleurs centralisés.
À quoi ça sert
La création d'une usine permet de construire un réseau facilement évolutif, résilient et fiable. L'architecture (leaf-spine) prend en compte les particularités des centres de données (chemins de circulation du trafic, minimisation des délais et des goulets d'étranglement dans le réseau). Les solutions SD dans les centres de données permettent de gérer très facilement, rapidement et de manière flexible cette usine, en l'intégrant dans l'écosystème des centres de données.
Les deux clients devaient construire des centres de données de secours pour assurer la résilience, en plus de cela, le trafic entre les centres de données devait être chiffré.
Le premier client considérait déjà les solutions sans usine comme un standard possible de ses réseaux, mais lors des tests, ils rencontrèrent des problèmes de compatibilité STP entre plusieurs fournisseurs de matériel. Des arrêts de service se produisaient, entraînant des pannes de services. Pour le client, c'était critique.
Cisco était déjà la norme d'entreprise du client, ils ont examiné ACI et d'autres options et ont décidé de choisir cette solution. L'automatisation de la gestion d'une seule touche via un contrôleur unique leur a plu. Les services se configurent plus rapidement et sont plus faciles à gérer. Ils ont décidé de sécuriser le trafic en lançant MACSec entre les commutateurs IPN et SPINE. Cela a permis d'éviter un goulot d'étranglement avec le crypto-pass, d'économiser sur ceux-ci et d'utiliser au maximum la bande passante.
Le deuxième client a choisi une solution sans contrôleur de Juniper, car leur centre de données existant avait déjà une petite installation avec une mise en œuvre de la fabrique EVPN VXLAN. Cependant, celle-ci n'était pas redondante (un seul commutateur était utilisé). Ils ont décidé d'étendre l'infrastructure du centre de données principal et de construire une fabrique dans un centre de données de secours. L'EVPN existant n'était pas utilisé pleinement : l'encapsulation VXLAN n'était en fait pas appliquée, puisque tous les hôtes étaient connectés à un seul commutateur et que toutes les adresses MAC et /32 des hôtes étaient locales, le commutateur servant de passerelle pour eux, sans d'autres appareils où il aurait été nécessaire de construire des tunnels VXLAN. Ils ont décidé de sécuriser le trafic en utilisant la technologie IPSEC entre les pare-feux (la performance de l'IPS était suffisante).
Ils ont également examiné ACI, mais ont décidé qu'à cause du verrouillage du fournisseur, ils devraient acheter trop de matériel, y compris remplacer le nouvel équipement récemment acquis, ce qui n'a tout simplement pas de sens économique. Oui, la fabrique Cisco s'intègre à tout, mais à l'intérieur de la fabrique elle-même, seuls ses appareils sont possibles.
D'autre part, comme mentionné précédemment, il n'est pas si facile de mixer une fabrique EVPN VXLAN avec n'importe quel fournisseur voisin, car les mises en œuvre du protocole diffèrent. C'est comme essayer de faire coexister Cisco et Huawei dans un même réseau — les standards peuvent être communs, mais il faudra se plier à certaines conditions. Étant donné qu'il s'agit d'une banque, et que les tests de compatibilité prendraient beaucoup de temps, ils ont décidé qu'il valait mieux s'approvisionner auprès du même fournisseur maintenant, sans trop s'emballer avec des fonctionnalités en dehors des bases.
Plan de migration
Deux centres de données basés sur ACI :
Organisation de l'interaction entre les Data Centers. La solution Multi-Pod a été choisie — chaque Data Center est un pod. Les exigences de mise à l'échelle en termes de nombre de commutateurs et de latences entre les pods (RTT inférieur à 50 ms) ont été prises en compte. Il a été décidé de ne pas construire une solution Multi-Site pour faciliter la gestion (une interface de gestion unique est utilisée pour la solution Multi-Pod, alors qu'il aurait fallu deux interfaces pour Multi-Site, ou nécessiter un orchestrateur Multi-Site), et étant donné qu'il n'était pas nécessaire de faire de la sauvegarde géographique des sites.
En ce qui concerne la migration des services du réseau Legacy, l'option la plus transparente a été choisie, celle de transférer progressivement les VLAN correspondant à certains services.
Pour la migration, un EPG (End-point group) correspondant à chaque VLAN a été créé sur la fabrique. D'abord, le réseau a été étendu entre l'ancienne réseau et la fabrique en L2, puis après la migration de tous les hôtes, la passerelle a été transférée vers la fabrique, et l'interaction entre l'EPG et le réseau existant était effectuée via L3OUT, l'interaction entre L3OUT et EPG étant décrite à l'aide de contrats. Schéma approximatif :
Schéma approximatif de la plupart des politiques de la fabrique ACI représentées sur l'image ci-dessous. Toute la configuration est fondée sur des politiques imbriquées dans d'autres politiques, et ainsi de suite. Au début, il est très difficile de s'y retrouver, mais progressivement, comme l'expérience le montre, les administrateurs réseau s'habituent à cette structure en environ un mois, et c'est seulement après qu'ils comprennent à quel point elle est pratique.
Comparaison
Dans la solution Cisco ACI, il faut acheter plus de matériel (des commutateurs distincts pour l'interaction Inter-Pod et des contrôleurs APIC), ce qui a rendu cette solution plus coûteuse. La solution Juniper n'a pas nécessité l'achat de contrôleurs et de matériel auxiliaire ; il a été possible d'utiliser partiellement le matériel existant du client.
Voici l'architecture EVPN VXLAN de la fabrique pour deux Data Centers du second projet :
Avec ACI, vous obtenez une solution prête à l'emploi — pas besoin de fouiller, pas besoin d'optimiser. Lors de la première rencontre avec l'usine, aucun développeur n'est nécessaire, aucune personne de soutien pour le code et l'automatisation. Il suffit juste d'exploiter, beaucoup de configurations peuvent être effectuées via un assistant, ce qui n'est pas toujours un avantage, surtout pour ceux qui sont habitués à la ligne de commande. Dans tous les cas, il faut du temps pour réadapter son esprit à de nouveaux rails, à la spécificité des réglages via des politiques et à la gestion de multiples politiques imbriquées. Il est très souhaitable, en plus de cela, d'avoir une structure claire pour nommer les politiques et les objets. En cas de problème dans la logique de fonctionnement du contrôleur, il ne peut être résolu que par le support technique.
Avec EVPN — c'est la console. Souffre ou réjouis-toi. Une interface familière pour les anciens. Oui, il y a une configuration standard et des guides. Vous devrez consulter les documentations. Différentes structures, tout est clair et détaillé.
Naturellement, dans les deux cas, il est préférable, lors de la migration, de commencer par migrer les services les moins critiques, par exemple, les environnements de test, et seulement ensuite, après avoir corrigé tous les bogues, de passer aux services de production. Et ne pas configurer un vendredi soir. Ne croyez pas le fournisseur quand il dit que tout ira bien, il vaut toujours mieux prendre des précautions.
Avec ACI, vous payez plus, bien que Cisco promeuve activement cette solution et offre souvent de bonnes remises, mais vous économisez sur la maintenance. La gestion et toute automatisation de l'usine EVPN sans contrôleur nécessitent des investissements et des dépenses régulières — surveillance, automatisation, mise en œuvre de nouveaux services. En même temps, le démarrage initial avec ACI prend 30 à 40 % de temps en plus. Cela s'explique par le fait que l'ensemble des profils et politiques nécessaires prend plus de temps à créer, mais au fur et à mesure que le réseau se développe, le nombre de configurations requises diminue. Vous utilisez déjà des politiques, profils et objets créés à l'avance. Vous pouvez configurer flexible la segmentation et la sécurité, gérer de manière centralisée les contrats qui régissent les interactions entre les EPG — la charge de travail diminue soudainement.
Avec EVPN, il faut configurer chaque appareil dans l'usine, le risque d'erreur est plus élevé.
Si ACI met plus de temps à s'implanter, alors EVPN a presque mis deux fois plus de temps à être débogué. Dans le cas de Cisco, on peut toujours appeler un ingénieur de support pour poser des questions sur le réseau dans son ensemble (car cela est couvert comme solution), alors qu'avec Juniper Networks, vous n'achetez que le matériel, et c'est cela qui est couvert. Les paquets ont quitté l'appareil ? Eh bien, d'accord, maintenant ce sont vos problèmes. Mais vous pouvez poser une question sur le choix de la solution ou la conception du réseau — et dans ce cas, il est conseillé d'acheter un service professionnel, moyennant des frais supplémentaires.
Le support ACI est vraiment excellent, car il est séparé : une équipe distincte est exclusivement dédiée à cela. Il y a même des spécialistes russophones. Le guide est détaillé, les solutions sont prédéfinies. Ils examinent et conseillent. Ils valident rapidement le design, ce qui est souvent important. Juniper Networks fait également la même chose, mais de manière beaucoup plus lente (c'était notre expérience, mais cela devrait s'être amélioré, selon les rumeurs), ce qui vous oblige à faire tout par vous-même là où un ingénieur de solutions pourrait vous conseiller.
Cisco ACI prend en charge l'intégration avec les systèmes de virtualisation et de conteneurisation (VMware, Kubernetes, Hyper-V) et la gestion centralisée. Il existe des services réseau et de sécurité — équilibrage, pare-feu, WAF, IPS, etc. Une bonne micro-segmentation par défaut. Dans la deuxième solution, l'intégration avec les services réseau est complexe, et il est préférable de se renseigner à l'avance sur les forums avec ceux qui l'ont fait.
Conclusion
Pour chaque cas particulier, il est nécessaire de sélectionner une solution, non seulement en fonction du coût du matériel, mais également en tenant compte des dépenses d'exploitation futures et des principaux problèmes auxquels le client est actuellement confronté, ainsi que des plans de développement de l'infrastructure informatique.
ACI, en raison d'équipements supplémentaires, est devenu plus cher, mais c'est une solution prête à l'emploi sans nécessité d'ajustements, tandis que la deuxième solution est plus complexe et coûteuse en termes d'exploitation, mais moins chère.
Si vous souhaitez discuter du coût potentiel de la mise en place d'une infrastructure réseau chez différents fournisseurs, et quelle architecture est nécessaire, nous pouvons nous rencontrer et en discuter. Pour une ébauche préliminaire de l'architecture (avec laquelle vous pouvez estimer les budgets), nous vous conseillerons gratuitement, tandis que le développement détaillé est, bien entendu, payant.
Vladimir Kleptche, réseaux d'entreprise.
Source : habr.com
