Combiner des projets dans différents centres de données

Dans cet article, nous examinerons pourquoi l'approche traditionnelle de combinaison des réseaux locaux au niveau L2 est inefficace avec une augmentation significative du nombre d'équipements, ainsi que les problèmes que nous avons pu résoudre dans le processus de combinaison de projets situés sur différents sites.

Circuit L2 normal

À mesure que l'infrastructure informatique se développe dans le centre de données, les clients doivent combiner serveurs, stockage et pare-feu en un seul réseau. Pour cela, Selectel suggère initialement d'utiliser un réseau local.

Le réseau local est organisé comme un réseau "campus" classique au sein du même centre de données, seuls les commutateurs d'accès sont situés directement dans les racks avec les serveurs. Les commutateurs d'accès sont en outre combinés en un seul commutateur de couche d'agrégation. Chaque client peut commander une connexion au réseau local pour tout appareil qu'il loue ou place avec nous dans le centre de données.

Pour organiser un réseau local, des commutateurs d'accès et d'agrégation dédiés sont utilisés afin que les problèmes du réseau Internet n'affectent pas le réseau local.


Peu importe dans quel rack se trouve le prochain serveur - Selectel combine les serveurs en un seul réseau local, et vous n'avez pas à penser aux commutateurs ou à l'emplacement du serveur. Vous pouvez commander un serveur lorsque cela est nécessaire et il sera connecté au réseau local.

L2 fonctionne très bien lorsque la taille du centre de données est petite, lorsque tous les racks ne sont pas pleins. Mais à mesure que le nombre de racks, de serveurs dans les racks, de commutateurs, de clients augmente, le circuit devient beaucoup plus difficile à entretenir.


Les serveurs d'un client peuvent être situés dans plusieurs centres de données pour garantir la tolérance aux catastrophes ou s'il est impossible de placer le serveur dans un centre de données existant (par exemple, tous les racks et tous les emplacements sont occupés). Entre plusieurs centres de données, la connectivité est également nécessaire - entre les serveurs d'un réseau local.

À mesure que le nombre de centres de données, de racks, de serveurs augmente, le circuit devient plus compliqué. Dans un premier temps, la connectivité entre les serveurs de différents centres de données s'est effectuée simplement au niveau des commutateurs d'agrégation utilisant la technologie VLAN.


Mais l'espace d'identification des VLAN est très limité (4095 ID de VLAN). Ainsi, pour chaque centre de données, vous devez utiliser votre propre ensemble de VLAN, ce qui réduit le nombre d'identifiants possibles pouvant être utilisés entre les centres de données.

Problèmes L2

Lors de l'utilisation d'un schéma au niveau L2 à l'aide d'un VLAN, un fonctionnement incorrect de l'un des serveurs du centre de données peut entraîner des interruptions dans la fourniture de services sur d'autres serveurs. Les problèmes les plus courants sont les suivants:

• Problèmes avec STP (Spanning-Tree Protocol)
• Problèmes avec Broadcast Storms
• Problèmes avec un traitement de multidiffusion incorrect
• Facteur humain (transfert de lien, transfert de VLAN)
• Problèmes d'organisation de réservation pour L2
• Problèmes avec le trafic unicast inconnu
• Problèmes avec le nombre d'adresses MAC

Les problèmes avec STP sont souvent liés aux paramètres des serveurs clients ou de l'équipement client. Contrairement aux points d'échange de trafic populaires, nous ne pouvons pas filtrer complètement STP sur les ports d'accès et les ports de désactivation lorsqu'une PDU STP arrive. Chez STP, un certain nombre de fabricants d'équipements de réseau implémentent des fonctionnalités de base des commutateurs de centre de données comme la détection de boucles dans le réseau.

Si STP ne fonctionne pas correctement côté client, le domaine STP entier d'au moins un commutateur d'accès peut être affecté. L'utilisation d'extensions STP, telles que MSTP, n'est pas non plus une solution, car le nombre de ports, VLAN, commutateurs dépasse souvent l'évolutivité architecturale du protocole STP.

Diffusion

Le réseau du centre de données peut être construit sur des appareils de différents fabricants. Parfois, même les différences dans la version du logiciel du commutateur sont suffisantes pour que les commutateurs gèrent STP différemment. Ainsi, par exemple, dans le centre de données Dubrovka 3 , il y a 280 racks, ce qui dépasse le nombre maximal possible de commutateurs dans un domaine STP.

Avec l'utilisation généralisée de STP dans un tel réseau, le temps de réponse à tout changement, en particulier, la simple activation ou désactivation du port, dépassera tous les seuils d'attente. Vous ne voulez pas que lorsque l'un des clients active le port, votre connectivité réseau disparaisse pendant plusieurs minutes?

Les problèmes de trafic de diffusion surviennent souvent à la fois en raison d'actions incorrectes sur le serveur (par exemple, la création d'un pont entre plusieurs ports de serveur), ainsi qu'en raison d'une configuration logicielle incorrecte sur les serveurs. Nous essayons de niveler les problèmes possibles avec la quantité de trafic de diffusion qui arrive à notre réseau. Mais nous pouvons le faire sur un port de connexion de serveur, et si 5 serveurs sont inclus dans un commutateur, chacun ne dépassant pas les seuils définis, alors ensemble, ils peuvent générer suffisamment de trafic pour déclencher le contrôle sur le commutateur d'agrégation. D'après notre propre pratique, les problèmes liés à une tempête de diffusion côté serveur peuvent être causés par une défaillance spécifique de la carte réseau du serveur.

En protégeant l'intégralité du réseau, le commutateur d'agrégation «mettra» le port sur lequel l'anomalie du réseau s'est produite. Malheureusement, cela entraînera l'inopérabilité des cinq serveurs à l'origine de cet incident, ainsi que l'inopérabilité d'autres serveurs (jusqu'à plusieurs racks dans le centre de données).

Multidiffusion

Les problèmes de traitement incorrect du trafic de multidiffusion sont des problèmes très spécifiques qui surviennent dans le complexe en raison d'un fonctionnement incorrect du logiciel sur le serveur et du logiciel sur le commutateur. Par exemple, Corosync est configuré en mode multidiffusion entre plusieurs serveurs. L'échange de Hello-paquets se fait régulièrement en petits volumes. Mais dans certains cas, les serveurs sur lesquels Corosync est installé peuvent transmettre un grand nombre de paquets. Ce volume nécessite déjà soit une configuration spéciale des commutateurs, soit l'utilisation des mécanismes de traitement appropriés (jointure IGMP et autres). En cas de mauvais fonctionnement des mécanismes ou lorsque des seuils sont déclenchés, des interruptions de service peuvent affecter d'autres clients. Bien sûr, moins il y a de clients sur le commutateur, moins il est probable que des problèmes d'un autre client se produisent.

Le facteur humain est un type de problème plutôt imprévu qui peut survenir lors de l'utilisation d'équipements réseau. Lorsque l'administrateur réseau est seul et qu'il construit son travail avec compétence, documente les actions et réfléchit aux conséquences de ses actions, la probabilité d'erreur est alors assez faible. Mais lorsque la quantité d’équipement en fonctionnement du centre de données augmente, quand il y a beaucoup d’employés, quand il y a beaucoup de tâches, alors une approche complètement différente de l’organisation du travail est nécessaire.

Certains types d'actions typiques sont automatisés pour éviter les erreurs humaines, mais de nombreux types d'actions ne peuvent pas être automatisés pour le moment, ou le prix de l'automatisation de telles actions est déraisonnablement élevé. Par exemple, la commutation physique des cordons de brassage sur un panneau de brassage, la connexion de nouveaux liens, le remplacement de liens existants. Tout ce qui concerne le contact physique avec SCS. Oui, il existe des panneaux de brassage qui permettent de commuter à distance, mais ils sont très chers, nécessitent beaucoup de travail préparatoire et sont très limités dans leurs capacités.

Aucun panneau de brassage automatique ne posera un nouveau câble si nécessaire. Vous pouvez faire une erreur lors de la configuration d'un commutateur ou d'un routeur. Indiquez le mauvais numéro de port, le numéro VLAN, à sceller lorsque vous entrez une valeur numérique. Lorsque vous spécifiez des paramètres supplémentaires, ne tenez pas compte de leur influence sur la configuration existante. Avec la complexité croissante du schéma, compliquant le schéma de redondance (par exemple, en raison du schéma actuel atteignant la limite de mise à l'échelle), la probabilité d'erreurs humaines augmente. Tout le monde peut avoir une erreur humaine, que l'appareil soit à l'étape de configuration, un serveur, un commutateur, un routeur ou une sorte de périphérique de transit.

Organiser la redondance sur L2, à première vue, semble être une tâche simple pour les petits réseaux. Le cours Cisco ICND couvre les bases de l'utilisation de STP en tant que protocole initialement conçu pour fournir une redondance L2. STP a beaucoup de restrictions qui sont appelées «par conception» dans ce protocole. Nous ne devons pas oublier que tout domaine STP a une "largeur" ​​très limitée, c'est-à-dire que le nombre de périphériques dans un domaine STP est assez petit par rapport au nombre de racks dans le centre de données. Le protocole STP dans sa version originale divise les liens en utilisé et sauvegarde, ce qui ne permet pas une utilisation complète des liaisons montantes pendant le fonctionnement normal.

L'utilisation d'autres protocoles de réservation L2 impose ses limites. Par exemple, ERPS (Ethernet Ring Protection Switching) - pour la topologie physique utilisée, pour le nombre de sonneries sur un appareil, pour l'utilisation de toutes les liaisons. L'utilisation d'autres protocoles implique, en règle générale, des modifications propriétaires de différents fabricants ou limite la construction du réseau à une technologie sélectionnée (par exemple, l'usine TRILL / SPBm utilisant l'équipement Avaya).

Unicast inconnu

Je voudrais surtout souligner le sous-type de problèmes avec le trafic unicast inconnu. Qu'est ce que c'est Trafic destiné à une adresse IP spécifique via L3, mais diffusé sur le réseau via L2, c'est-à-dire qu'il est transmis à tous les ports appartenant à ce VLAN. Cette situation peut se produire pour un certain nombre de raisons, par exemple, lors de la réception de DDoS vers une adresse IP inoccupée. Ou si, lors d'une faute de frappe dans la configuration du serveur, une adresse qui n'existe pas sur le réseau a été spécifiée comme sauvegarde, et sur le serveur il y a historiquement un enregistrement ARP statique à cette adresse. Unicast inconnu apparaît lorsque toutes les entrées dans les tables ARP sont présentes, mais en l'absence de l'adresse MAC du récepteur dans les tables de commutation des commutateurs de transit.

Par exemple, le port derrière lequel se trouve l'hôte réseau avec l'adresse donnée passe très souvent à l'état désactivé. Ce type de trafic est limité par les commutateurs de transit et est souvent servi de la même manière que la diffusion ou la multidiffusion. Mais contrairement à eux, le trafic unicast inconnu peut être initié "à partir d'Internet", et pas seulement à partir du réseau du client. Le risque de trafic unicast inconnu est particulièrement élevé lorsque les règles de filtrage sur les routeurs frontaliers permettent l'usurpation d'adresses IP de l'extérieur.

Même le simple nombre d'adresses MAC peut parfois être un problème. Il semblerait qu'avec une taille de centre de données de 200 racks, 40 serveurs par rack, il est peu probable que le nombre d'adresses MAC dépasse largement le nombre de serveurs dans le centre de données. Mais ce n'est plus une affirmation vraie, car l'un des systèmes de virtualisation peut être lancé sur les serveurs, et chaque machine virtuelle peut être représentée par son adresse MAC, voire plusieurs (lors de l'émulation de plusieurs cartes réseau dans une machine virtuelle, par exemple). Au total, nous pouvons obtenir plus de plusieurs milliers d'adresses MAC légitimes à partir d'un rack sur 40 serveurs.

Un tel nombre d'adresses MAC peut affecter la plénitude de la table de commutation sur certains modèles de commutateurs. De plus, pour certains modèles de commutateurs, lors du remplissage de la table de commutation, le hachage est utilisé et certaines adresses MAC peuvent provoquer des collisions de hachage conduisant à l'apparition d'un trafic de monodiffusion inconnu. La recherche aléatoire d'adresses MAC sur un serveur loué à une vitesse de, disons, 4 000 adresses par seconde, peut entraîner un débordement de la table de commutation sur le commutateur d'accès. Naturellement, les commutateurs appliquent des restrictions sur le nombre d'adresses MAC qui peuvent être apprises sur les ports de commutateur, mais selon la mise en œuvre spécifique de ce mécanisme, les données peuvent être interprétées de différentes manières.

Encore une fois, l'envoi de trafic à l'adresse MAC filtrée par ce mécanisme entraîne l'apparition d'un trafic unicast inconnu. La chose la plus désagréable dans cette situation est que les interrupteurs sont rarement testés par le fabricant pour l'auto-guérison après les cas avec débordement de la table de commutation. Un seul débordement de la table, provoqué, par exemple, par une erreur d'un client dans les paramètres hping ou dans l'écriture d'un script qui surveille son infrastructure, peut entraîner un redémarrage du commutateur et une interruption de la communication pour tous les serveurs situés dans le rack. Si un tel débordement se produit sur le commutateur de niveau d'agrégation, le redémarrage du commutateur peut entraîner une interruption de 15 minutes de l'ensemble du réseau local du centre de données.

Je voudrais souligner que l'utilisation de L2 n'est justifiée que pour des cas limités et impose de nombreuses restrictions. La taille du segment, le nombre de segments L2 - ce sont tous les paramètres qui doivent être évalués chaque fois que vous ajoutez un nouveau VLAN avec la connectivité L2. Et plus les segments L2 sont petits, plus le réseau est simple et, par conséquent, plus fiable.

Cas d'utilisation typiques de L2

Comme déjà mentionné, avec le développement progressif des infrastructures dans un centre de données, un réseau local L2 est utilisé. Malheureusement, cette utilisation est également impliquée dans le développement de projets dans un autre centre de données ou dans une autre technologie (par exemple, des machines virtuelles dans le cloud).

Liaison front-end et back-end, sauvegarde

En règle générale, l'utilisation d'un réseau local commence par la séparation des fonctionnalités des services frontaux et principaux, en allouant le SGBD à un serveur distinct (pour améliorer les performances, pour séparer le type de système d'exploitation sur le serveur d'applications et le SGBD). Initialement, l'utilisation de L2 à ces fins semble justifiée, dans le segment il n'y a que quelques serveurs, souvent ils sont même situés dans le même rack.


Les serveurs sont inclus dans un VLAN, dans un ou plusieurs commutateurs. À mesure que la quantité d'équipement augmente, de plus en plus de nouveaux serveurs sont inclus dans les commutateurs de nouveaux racks du centre de données, à partir desquels le domaine L2 commence à se développer en largeur.


De nouveaux serveurs apparaissent, notamment des serveurs de base de données de sauvegarde, des serveurs de sauvegarde, etc. Tant que le projet vit dans un centre de données, les problèmes de mise à l'échelle ne se posent généralement pas. Les développeurs d'applications s'habituent simplement au fait que sur le prochain serveur du réseau local, l'adresse IP ne change que dans le dernier octet, et vous n'avez pas besoin d'écrire de règles de routage distinctes.

Les développeurs sont invités à appliquer un schéma similaire lorsque le projet se développe, lorsque les serveurs suivants sont déjà loués dans un autre centre de données ou lorsqu'une partie du projet se déplace vers les machines virtuelles dans le cloud . Dans l'image, tout semble très simple et beau:


Il semblerait que vous ayez juste besoin de connecter deux commutateurs d'agrégation dans DC1 et DC2 avec un VLAN. Mais qu'est-ce qui se cache derrière cette simple action?

Réservation de ressources

Tout d'abord, nous augmentons la largeur du domaine L2, de sorte que tous les problèmes potentiels du réseau local de DC1 peuvent survenir dans DC2. Qui aimera que ses serveurs soient situés dans DC2, et l'incident lié à l'inaccessibilité du réseau local se produira en raison d'actions incorrectes à l'intérieur de DC1?

Deuxièmement, vous devez prendre soin de sauvegarder ce VLAN. Le commutateur d'agrégation dans chaque centre de données est le point de défaillance. Le câble entre les centres de données est un autre point de défaillance. Chaque point de défaillance doit être réservé. Deux commutateurs d'agrégation, deux câbles des commutateurs d'agrégation aux commutateurs d'accès, deux câbles entre les centres de données ... Chaque fois que le nombre de composants augmente, et le circuit devient plus compliqué.


La complexité du schéma est due à la nécessité de réserver chaque élément du système. Pour une sauvegarde complète des appareils et des liens, vous devez dupliquer presque tous les éléments. Sur un réseau aussi important, il n'est plus possible d'utiliser STP pour organiser les sauvegardes. Il serait possible de présenter tous les éléments du réseau, en particulier les commutateurs d'accès, en tant que composants du nuage MPLS, puis la redondance serait obtenue en raison de la fonctionnalité du protocole MPLS.

Mais les appareils MPLS sont généralement deux fois plus chers que les appareils non MPLS. Et il convient de noter que le commutateur MPU en 1U, qui a un bon degré d'évolutivité, la mise en œuvre de la fonctionnalité MPLS complète dans le plan de contrôle, dans la pratique, n'existait que récemment. En conséquence, je veux me débarrasser ou minimiser l'impact des problèmes L2 sur le réseau existant, mais en même temps garder la possibilité de réserver des ressources.

Transition vers L3

Si chaque lien du réseau est représenté comme un segment IP distinct et chaque périphérique comme un routeur distinct, nous n'avons pas besoin de redondance au niveau L2. La redondance des liaisons et des routeurs est assurée par des protocoles de routage dynamique et une redondance de routage dans le réseau.

À l'intérieur du centre de données, nous pouvons enregistrer les schémas d'interaction entre les serveurs existants via L2, et l'accès aux serveurs dans un autre centre de données se fera via L3.


Ainsi, les centres de données sont interconnectés par la connectivité L3. Autrement dit, il est émulé qu'un routeur est installé entre les centres de données (en fait, plusieurs, pour la sauvegarde). Cela vous permet de diviser les domaines L2 entre les centres de données, d'utiliser votre propre VLAN dans chaque centre de données et de communiquer entre eux. Pour chaque client, vous pouvez utiliser des plages d'adresses IP répétitives, les réseaux sont complètement isolés les uns des autres et vous ne pouvez pas accéder au réseau d'un autre client à partir du réseau d'un client (sauf lorsque les deux clients acceptent une telle connexion).

Nous vous recommandons d'utiliser des segments IP de l'adressage 10.0.0.0/8 pour les réseaux locaux. Pour le premier centre de données, le réseau sera, par exemple, 10.0.1.0/24, pour le second - 10.0.2.0/24. Selectel sur le routeur prescrit l'adresse IP de ce sous-réseau. En règle générale, les adresses .250-.254 sont réservées aux périphériques réseau Selectel, et une adresse .254 sert de passerelle vers d'autres réseaux locaux. L'itinéraire est attribué à tous les appareils de tous les centres de données:

route add 10.0.0.0 mask 255.0.0.0 gw 10.0.x.254

Où x est le numéro du centre de données. En raison de cette route, les serveurs des centres de données se «voient» par routage.


La présence d'un tel itinéraire simplifie la mise à l'échelle du schéma dans le cas, par exemple, de l'apparition d'un troisième centre de données. Ensuite, pour les serveurs du troisième centre de données, les adresses IP de la plage suivante, 10.0.3.0/24, sont enregistrées, sur le routeur - l'adresse 10.0.3.254.


Une caractéristique distinctive de la mise en œuvre d'un tel système est qu'il ne nécessite pas de réservation supplémentaire en cas de défaillance du centre de données ou des canaux de communication externes. Ainsi, par exemple, si le centre de données 1 tombe en panne, la connexion entre le centre de données 2 et le centre de données 3 est complètement préservée, et lors de la mise en œuvre du schéma avec le flux L2 entre les centres de données via l'un d'eux, comme dans la figure:


La connexion entre le centre de données 2 et le centre de données 3 dépend de l'efficacité du centre de données 1. Ou bien, l'organisation de liaisons supplémentaires et l'utilisation de schémas de réservation L2 complexes sont nécessaires. Et tout en enregistrant le schéma L2, l'ensemble du réseau est toujours très sensible aux commutations incorrectes, à la formation de boucles de commutation, à diverses tempêtes de trafic et à d'autres problèmes.

Segments L3 dans les projets

En plus d'utiliser différents segments L3 dans différents centres de données, il est logique d'allouer un réseau L3 distinct pour les serveurs de différents projets, souvent réalisés à l'aide de technologies différentes. Par exemple, des serveurs matériels dans le centre de données dans un sous-réseau IP, des serveurs virtuels dans le même centre de données, mais dans le cloud VMware, dans un autre sous-réseau IP, certains serveurs liés à la mise en scène dans le troisième sous-réseau IP . Ensuite, des erreurs aléatoires dans l'un des segments ne conduisent pas à une panne complète de tous les serveurs inclus dans le réseau local.

Réservation de routeur

Tout cela est impressionnant, mais il y a un seul point d'échec entre les projets - c'est le routeur. Que faire dans ce cas? En fait, le routeur n'est pas seul. Deux routeurs sont alloués pour chaque centre de données et pour chaque client, ils forment Virtual IP .254 en utilisant le protocole VRRP.

L'utilisation de VRRP entre deux appareils adjacents avec un segment L2 commun est justifiée. Pour les centres de données géographiquement distribués, différents routeurs sont utilisés et MPLS est organisé entre eux. Ainsi, chaque client se connectant au réseau local de cette manière est connecté à un L3VPN distinct conçu pour lui sur ces routeurs MPLS. Et le schéma, en approximation de la réalité, ressemble à ceci:


L'adresse de passerelle pour chaque segment .254 est réservée par VRRP entre les deux routeurs.

Conclusion

En résumant tout ce qui précède - le changement du type de réseau local de L2 à L3 nous a permis de maintenir la capacité de mise à l'échelle, a augmenté le niveau de fiabilité et de tolérance aux pannes, et nous a également permis de mettre en œuvre des plans de redondance supplémentaires. De plus, cela a contourné les restrictions et les «pièges» existants de L2.

À mesure que les projets et les centres de données se développent, les solutions standard existantes atteignent leur limite d'évolutivité. Cela signifie qu'ils ne sont plus adaptés à une résolution efficace des problèmes. Les exigences de fiabilité et de stabilité du système dans son ensemble sont en constante augmentation, ce qui à son tour affecte le processus de planification. Il est important de prendre en compte le fait que des prévisions de croissance optimistes doivent être prises en compte afin qu’à l’avenir il n’existe aucun système qui ne puisse pas être mis à l’échelle.

Dites-nous - utilisez-vous déjà L3VPN? Rendez-vous dans les commentaires.