Citation:
mais je n'arrive jusqu'à présent pas à appréhender ce terme
Je te rassure, un grand monsieur qui s'appelle Robert Metcalfe, l'inventeur du réseau Ethernet, a avoué qu'il n'y comprenait pas grand chose non plus à tout ce bazar.
Citation:
Je voudrais qu'on m'explique ce concept, son fonctionnement , ses motivations et ses apports et ses offres sur le marché. Aussi l'impact de SDN par rapport aux plans de controle et de données et de leur séparation.
La littérature sur le SDN est assez abstraite puisque tout ça est en cours de gestation (même s'il existe tout de même des applications concrètes).
Commençons par le commencement... Avec par exemple, un routeur :-)
Un routeur remplit deux fonctions.
La fonction première, c'est de passer les paquets entre ses interfaces. C'est la responsabilité du Data Plane (qu'on appelle aussi Forwarding Plane).
Evidemment, afin que le Data Plane encapsule un paquet vers telle ou telle interface sortante, le routeur doit avoir une connaissance suffisante de la topologie du réseau. La collecte de ces informations est réalisée dans le Control Plane. C'est ici que le routeur va gérer les protocoles de routage, les adjacences et construire ses tables.
Le Control Plane, c'est un peu la "tête" de la bestiole et le Forwarding Plane, les muscles :lol:
Inutile de dire que ces équipements sont devenus de plus en plus complexes. Ils nécessitent beaucoup de recherche et développement (au niveau des ASIC notamment). En plus, il faut des personnels de plus en plus pointus pour les déployer et les maintenir.
Pour s'en convaincre, prenons l'exemple du nouvel utilisateur qu'on veut connecter sur un switch d'étage avec un téléphone IP muni d'un PC. Voyez un peu le bazar :- je dois configurer un VLAN Voice et un VLAN Data sur le port du switch,
- je dois ensuite veiller à ce que les VLAN soient bien tirés jusqu'à leur gateway (et ça passe parfois par plusieurs switches/routeurs intermédiaires),
- ah mince, j'ai oublié la QoS, il faut que je repasse sur tous les switches/routeurs pour configurer ça,
- ooops, le copier/coller des commandes QoS fonctionnent pas sur cet équipement, c'est vrai qu'on l'a changé la semaine dernière,
- ah oui, j'oubliais les ouvertures de flux pour ce nouvel utilisateur,
- etc
Donc beaucoup de misères, de temps et d'énergie pour déployer cet utilisateur qui se demande pourquoi il n'est toujours pas connecté au réseau alors qu'il a démarré ce nouveau job il y a 3 jours :aie:
Passons maintenant à un deuxième concept important, celui de "l'orientation" du traffic dans une grosse infra de type data center.
Le design des datacenters est orienté "Nord-Sud".
Code:
1
2
3
4
5
6
7
8
9
| NORD
C1--------------C2 / \ Serveurs physiques
/ \ / \ |
/ \ / \ |
/ \ / \ |
D1 D2 D3 D4 |
/ \ / \ / \ / \ |
A1 A2 A3 A4 A5 A6 A7 A8 \ / Utilisateurs
SUD |
Parce dans que les archis traditionnelles clients/serveurs, les utilisateurs sont généralement "on the edge" (switches d'accès, les A1, A2, etc) et accèdent à des serveurs physiques concentrés dans une salle informatique.
La virtualisation a révolutionné ce schéma puisque la densité de VM dans la couche distribution (D1, D2, D3, D4) explose, et qu'il y a de plus en plus de traffic inter-VM.
Pensez par exemple aux applications qui requêtent sur des bases de données virtualisées, qui effectuent leur traitement, puis qui présentent les résultats sur un serveur Web ou autre, serveur bien sûr virtualisé. En définitive, la virtualisation a augmenté de façon dramatique les besoins en bande passante pour ce traffic dit "Est-Ouest", et la structure traditionnelle "Nord/Sud" des data centers devient un point de faible parce qu'une simple communication Est-Ouest entre VM1 et VM2 devient Sud-Nord-Sud (parce que même si des liens physiques sont tirés entre D1, D2, D3 et D4, ils seront généralement blocking pour les VLAN portés par C1 et C2). Par voie de conséquence, ce traffic Est-Ouest, grandissant, augmente la charge du trunk C1-C2 qui nécessite des upgrades réguliers.
Code:
1
2
3
4
5
6
7
8
9
10
| C1--------------C2
/ \ / \
VM1 / \ / \ VM2
\ / \ / \ /
D1 D2 D3 D4
/ \ / \ / \ / \
A1 A2 A3 A4 A5 A6 A7 A8
OUEST <------------------------------> EST
VM1 VM2 |
SDN propose donc une nouvelle approche des réseaux qui sépare le Control Plane du Forwarding Plane.
Le principe consiste à centraliser les fonctions du Control Plane dans une machine dédiée, le contrôleur SDN (vous entendrez aussi le terme d'Orchestrateur SDN).
SDN devrait donc permettre, entre autres :- une meilleure automatisation des changements réseau,
- une plus grande flexibilité architecturale (cette fameuse "agilité" tant recherchée) puisque les fonctions du réseau sont alors virtualisables.
On parle aussi de "programmabilité" du réseau. D'où l'appellation Software Defined Networking.
Reprenons maintenant l'exemple de l'utilisateur à déployer sur un switch d'accès en supposant qu'on soit dans un monde SDN idéal :lol:
Sur l'Orchestrateur, on sélectionne un profil, "Utilisateur ToIP+PC" par exemple. Et lorsqu'on applique ce profil sur le port du switch :- le port du switch est automagiquement configuré,
- les VLANs Voice et Data sont tirés,
- la QoS est configurée partout où c'est nécessaire.
Si c'est en plus quelqu'un de la Comptabilité, on pourrait aussi rajouter un profil spécifique d'utilisateur au port :- les access-lists pour que l'utilisateur puisse accéder à certaines parties du réseau seraient alors créées,
- les flux nécessaires seraient ouverts sur les firewalls,
- les droits requis pour certains serveurs seraient mis à jour également,
- etc.
Supposons également que j'aie déployé une nouvelle VM dans mon data center. En quelques clics de souris, je vais pouvoir reconfigurer dynamiquement les vSwitches et les trunks entre mes équipements réseau pour utiliser les liens de backup entre D1, D2, D3 et D4. Ainsi, je pourrai transporter certains flux "Est-Ouest" et éviter de charger mes core routers.
Code:
1
2
3
4
5
6
7
8
9
| C1--------------C2
/ \ / \
VM / \ / \ VM
\ / \ / \ /
D1 ---- D2 ---- D3 ---- D4
/ \ / \ / \ / \
A1 A2 A3 A4 A5 A6 A7 A8
OUEST <------------------------------> EST |
Un dernier exemple concret mettant en jeu un firewall :)
Dans la configuration suivante, un firewall filtre le traffic entre 2 réseaux A et B.
Code:
1
2
3
4
5
6
7
8
9
10
11
| +---+ +----+ +---+
| A |--------| FW |--------| B |
+---+ +----+ +---+
\ /
\ /
\ /
\ /
\ /
+----------+
| switch |
+----------+ |
Dans les architectures traditionnelles, le flux de A vers B traverse le FW lorsqu'il est autorisé.
SDN permettra de dérouler l'arbre des événements suivant :- le premier paquet d'un flux arrive sur le firewall,
- le firewall vérifie ses règles, constate que le flux est autorisé, envoie le paquet vers B,
- le firewall notifie A, B et le switch que ce flux est permis,
- à partir du 2ème paquet, le flux est directement switché vers le réseau B sans passer par le firewall.
Donc moins de latence de bout-en-bout, moins de travail pour le firewall, et une meilleure expérience utilisateur (pensez aux flux multimedia par exemple).
J'imagine même que dans le futur on pourrait embarquer A, B, switch et FW dans la même appliance. Il y a peut-être une startup à monter :-)
En conclusion, SDN est sensé ouvrir donc de nouvelles perspectives dans la façon de déployer et maintenir des systèmes d'informations.
J'ai donné un aperçu du SDN dans les couches basses switching/routing mais SDN se décline dans d'autres segments. Et d'après ce que j'ai pu constater, SDN semble pénétrer beaucoup d'infras au travers du storage (je pense par exemple à NSX de VMWare). Côté équipementiers, j'ai un faible pour Arista et son EoS qui me semble actuellement assez abouti par rapport à des concurrents habituels comme Cisco et Juniper. Il y a aussi des choses intéressantes qui se passent du côté d'Alcatel-Lucent et Ericsson (pour info, le codeur historique de IP-EIGRP, Russ White est passé chez Ericsson, c'est pas pour rien non plus).
Une chose est certaine, la normalisation n'est pas figée, aussi chaque constructeur possède sa propre solution SDN. Et contrairement à ce que certains pensent, les switches/routeurs sont loin d'être une espèce en voie de disparition. Aucun ensemble de boîtes SDN n'est capable de remplacer les bons vieux routeurs OSPF de nos grands-mères :lol:
Enfin, pour l'instant...
Steph
