Redondance du réseau : comment empêcher une défaillance d’un seul commutateur de détruire l’ensemble de votre système

10

Vous avez vu les diagrammes. Réseaux de bus. Topologies en anneau. Ils ont tous un défaut fatal. Une seule rupture de chaîne et tout s’arrête.

Les réseaux vedettes semblent plus sûrs. Vous disposez d’un interrupteur central. Chaque nœud s’y connecte. Si un ordinateur tombe en panne, les autres restent en ligne. Mais il y a un piège. Cet interrupteur central ? C’est un point d’échec unique.

Regardez la configuration ci-dessous.

![Description du diagramme : Un réseau avec le commutateur A, le commutateur B et le commutateur C. Les nœuds sont connectés à chaque commutateur. Les commutateurs A et C sont connectés au commutateur B.]

Dans ce scénario, le commutateur B constitue l’épine dorsale. Il connecte le commutateur A et le commutateur C.

Si le commutateur A échoue, les nœuds sur A s’éteignent. Mais les nœuds B et C communiquent toujours entre eux. Idem si le commutateur C échoue. Panne partielle. Maniable.

Mais si le Switch B meurt ?

Tout va à zéro. Tout le réseau s’effondre. Pourquoi? Parce que B est le pont. Pas de pont, pas de circulation.

C’est là que la redondance entre en jeu. Il ne s’agit pas seulement de disposer d’une alimentation de secours ou de disques durs supplémentaires. Il s’agit de résilience architecturale.

Et si nous modifiions la disposition physique ?

Imaginez ajouter un lien direct entre le commutateur A et le commutateur C. Un segment redondant.

Désormais, si le commutateur B échoue, A peut toujours parler à C. Le chemin change. Le trafic se déroute. Le réseau reste actif.

C’est le cœur de la redondance du réseau. Ce n’est pas magique. C’est juste une deuxième façon d’aller du point X au point Y.

Mais ajouter du câble ne suffit pas. Vous avez besoin de protocoles qui comprennent cette redondance. Sinon, vous créez des boucles. Et les boucles crashent les réseaux plus rapidement qu’un commutateur mort.

Nous ne faisons ici qu’effleurer la surface. Le vrai travail se produit lorsque vous commencez à parler de protocoles Spanning Tree et de temps de basculement.

Mais il faut d’abord voir le problème. Et le problème est simple.

Dépendance à un seul point de défaillance.

Éliminez cela et vous survivrez au prochain problème matériel.

Le premier interrupteur meurt. Le second prend le relais. Le trafic continue de circuler.

C’est la beauté de la redondance réseau. Vous avez tué le point d’échec unique. Si un élément matériel se bloque, la boucle reste fermée. Le réseau respire.

Mais maintenant nous sommes confrontés à un nouveau problème.

La boucle de la mort

Imaginez deux interrupteurs connectés par deux câbles différents. Ou peut-être qu’un troisième interrupteur rejoint la fête. Maintenant, vous avez des chemins partout.

Cela fonctionne très bien pour la redondance. Jusqu’à ce que ce ne soit pas le cas.

Lorsqu’un commutateur envoie une trame et ne sait pas où elle va, il l’inonde sur chaque port. Dans une topologie linéaire simple, cette trame atteint la fin et s’arrête. En boucle ? Ça rebondit pour toujours.

Les émissions se multiplient. Les trames Unicast rebondissent dans les deux sens. Du coup, votre réseau n’est pas seulement lent. C’est mort. Le processeur de chaque commutateur atteint 100 %. Les paquets tombent. Toute l’infrastructure s’arrête.

C’est la tempête de diffusion. Ce n’est pas une fonctionnalité. C’est un exercice d’incendie.

Arrêter la boucle

Alors, comment conserver la redondance physique sans le chaos logique ?

Il faut un protocole. Quelque chose qui dit : “Hé, je vois deux chemins. Je vais en bloquer un. Si celui-ci se brise, je débloquerai l’autre.”

Saisissez Spanning Tree Protocol (STP).

Cela existe depuis les années 80. C’est vieux. C’est maladroit. Mais ça marche. STP examine tous les liens entre les commutateurs. Il calcule le meilleur chemin vers le pont racine (le commutateur principal). Ensuite, il met tous les autres liens redondants dans un état de blocage.

Le trafic circule. La ligne de secours reste là, inactive. Prêt.

Si le câble primaire est coupé ? Le port bloquant se réveille. Il devient actif. Le réseau guérit.

Cela prend cependant quelques secondes. Peut-être trente. Pendant ce temps, les utilisateurs regardent les barres de chargement.

La solution la plus rapide : Rapid Spanning Tree

Trente secondes, c’est une éternité dans le temps du serveur. Si vous exploitez un centre de données, ou même simplement un bureau occupé, un temps d’arrêt de trente secondes est inacceptable.

Saisissez Rapid Spanning Tree Protocol (RSTP) ou 802.1w.

C’est la même idée de base. Bloquez les liens redondants. Débloquez-les en cas de besoin. Mais RSTP réduit le temps de convergence de quelques secondes à quelques fractions de seconde.

Pour ce faire, il renégocie plus rapidement les rôles des ports. Il n’attend pas les délais d’attente. Ça parle. C’est lui qui décide. Cela agit.

Lequel devriez-vous utiliser ?

Si vous construisez un réseau moderne, vous n’utilisez pas le STP de base. Vous utilisez RSTP. Ou son cousin, Multiple Spanning Tree Protocol (MSTP), qui vous permet d’exécuter différents spanning tree pour différents VLAN.

Pourquoi?

Parce que vous souhaiterez peut-être que les VLAN voix empruntent un chemin différent de celui des VLAN de données. MSTP vous permet d’équilibrer cette charge. Ou du moins, gardez-les à l’écart les uns des autres.

Si vous utilisez du matériel Cisco, vous consultez probablement PVST+ (Per-VLAN Spanning Tree). C’est exclusif. Il exécute une instance STP distincte pour chaque VLAN.

C’est lourd sur le processeur. Mais cela vous donne un contrôle granulaire.

L’essentiel

Le licenciement n’est pas négociable