La fonctionnalité « VCN Transit Routing » introduite en novembre dernier sur OCI (Oracle Cloud Infrastructure) permet d’élaborer des architectures réseaux supportant des cas d’usages avancés, s’appuyant entre autre sur la topologie « Hub-and-Spoke ».
Dans cet article, je vous présente :
– les concepts d’architecture hub-and-spoke,
– les différences entre hub-and-spoke et full-mesh
– les caractéristiques et avantages de chacun,
– les différentes variantes de topologie hub-and-spoke possibles avec OCI,
– puis les mécanismes OCI permettant de mettre en oeuvre ces architectures.
Dans les prochains articles, j’aborderai les détails d’implémentation de chacun des scénarios présentés.
Qu’est ce qu’une topologie réseau Hub-and-Spoke?
Hub-and-Spoke fait référence à la roue de vélo, avec son moyeu (hub) et ses rayons (spoke).
Le modèle Hub-and-Spoke est un concept pouvant s’appliquer à tout type de réseau. Prenons l’exemple d’un réseau de vols pour une compagnie aérienne, organisé autour d’aéroports majeurs (hub), d’une constellation d’aéroports régionaux reliés aux hubs, avec néanmoins du point-à-point lorsque c’est pertinent. L’avantage principal est de pouvoir atteindre plus de destinations avec moins de liens.
En informatique, le modèle d’architecture hub-and-spoke (Également appelé « réseau en étoile ») permet d’interconnecter plusieurs réseaux entre eux, à l’aide d’un point central.
Le modèle hub-and-spoke s’oppose aux réseaux maillés (mesh networks), mettant en oeuvre une liaison directe entre chaque point du réseau.
Comparativement à un modèle maillé, la principale caractéristique d’un modèle hub-and-spoke est la réduction du nombre de liens nécessaires pour interconnecter l’ensemble des points d’un réseau. Cette caractéristique devient déterminante à mesure que le nombre de noeuds augmente.
A titre d’exemple, voici un tableau comparant le nombre de liens nécessaires pour interconnecter l’ensemble des noeuds du réseau :
| Nombre de Liens | Hub-and-Spoke | Full-Mesh |
|---|---|---|
| 3 | 2 | 3 |
| 4 | 3 | 6 |
| 5 | 4 | 10 |
| 6 | 5 | 15 |
| 7 | 6 | 21 |
| 8 | 7 | 28 |
Un réseau full mesh suit la formule ci-dessous pour déterminer le nombre de liens nécessaires :
L = N x (N – 1)/2
*Avec L pour Liens et N pour Noeuds
Le nombre de liens nécessaire au fur-et-à-mesure que le réseau grandit est exponentiel.
Le modèle maillé (full-mesh) excelle lorsque la latence est le critère déterminant, grâce à une connexion directe et sans intermédiaire entre deux points du réseau.
Un réseau hub-and-spoke est linéaire, avec néanmoins un « coût » initial d’un noeud supplémentaire dans le réseau (induit par le hub) :
L = N – 1
Le modèle maillé a cependant comme avantage une connexion directe et sans intermédiaire entre deux points du réseau : il conserve donc tout son intérêt dans certains cas.
Il est bien évidemment possible de mixer les deux modèles d’interconnexion au sein d’une même architecture réseau afin d’obtenir une topologie spécifiquement adaptée à la situation.
Enfin, le modèle Hub-and-Spoke est un concept de mise en réseau au sens large : prenons l’exemple d’un réseau de vols pour une compagnie aérienne, organisé autour d’aéroports majeurs (hub), d’une constellation d’aéroports régionaux reliés aux hubs, avec néanmoins du point-à-point lorsque c’est pertinent. On comprend vite l’intérêt du modèle lorsqu’il est nécessaire d’interconnecter deux hubs : plus de destinations accessibles avec moins de liens.
Ce schéma peut aussi faire référence à plusieurs VCN et régions OCI : les concepts d’interconnexion restent les mêmes.
Pourquoi une topologie réseau Hub-and-Spoke dans OCI?
Cela permet d’utiliser un VCN1 central pouvant offrir de la connectivité à d’autres VCN de la même région cloud. Sans cette capacité, un design à plusieurs VCN nécessiterait que chaque VCN ait sa propre connexion aux réseaux on-premises (n x VPN, n x liens FastConnect, etc …).
1. Mutualiser les accès on-premises
Le premier bénéfice est de mutualiser les accès au réseau on-premises pour plusieurs VCN :
- le VCN central (HUB) porte les connexions vers les réseaux on-premises à l’aide de la DRG2,
- Les autres VCN (SPOKE) établissent un peering avec le VCN HUB et accèdent par rebond aux réseaux derrière le VCN HUB.
Le VCN « HUB » n’est utilisé qu’en transit par les VCN « SPOKE » : il route le traffic selon les règles mises en place.
Réduire le nombre de liaisons aux réseaux distants (via VPN IPSec ou liaison dédiée), permet de :
- réduire la charge administrative,
- renforcer la sécurité globale en ayant moins de points d’entré à contrôler,
- réduire les coûts dans le cas des liaisons dédiées.
Lorsque le traffic arrive depuis un VCN « SPOKE » dans le VCN HUB :
- Il peut être redirigé directement vers la DRG du VCN HUB (qui prendra à son tour la décision d’aiguillage selon la connectivité en place),
- Il peut être redirigé vers une instance présente dans un sous-réseau du VCN HUB.
La 2nd option permet par exemple de mettre en oeuvre une appliance de sécurité tierce pour tout traffic traversant le VCN HUB.
2. Simplifier les architectures multi-région/multi-VCN
Ce scénario s’apparente au premier, à la différence que la connexion au réseau tier sur le VCN HUB n’est pas un réseau on-premises, mais le réseau d’une autre région OCI : on connecte deux réseaux en étoile à l’aide d’une connexion point-à-point.
On cumule ici plusieurs fonctions OCI :
- Remote Peering Connection (RPC) : pour interconnecter deux VCN HUB dans deux régions OCI, via le backbone privé OCI,
- VCN Transit Routing : pour partager cette liaison RPC avec d’autres VCN dans chaque région.
3. Centraliser les liaisons de VCN à VCN d’une même région
Avant la fonctionnalité VCN Transit Routing, il était déjà possible d’effectuer des connexions point-à-point entre deux VCN (peering), à l’aide d’une LPG3. Cette topologie s’appuie sur le modèle de réseaux maillés, et comme vu précédemment peut vite atteindre des limites ou devenir compliqué à gérer en terme de nombre de liens.
La fonction « VCN Transit Routing » permet désormais d’interconnecter les VCNs d’une même région à l’aide d’un VCN central.
Un des intérêts de cette topologie est de pouvoir positionner un élément de sécurité central dans le VCN HUB, qui pourra contrôler le traffic Est/Ouest. Cela permet également d’interconnecter plusieurs VCNs ensemble, en allant au-delà des limites actuelles de LPG par VCN (par défaut, 10 LPG par VCN).
Comment créer une topologie Hub-and-Spoke dans OCI?
Dans le contexte OCI, une topologie hub-and-spoke se construit autour des VCNs, LPGs, DRGs et tables de routage. La nouveauté se matérialise par le fait que l’on peut désormais attacher une table de routage à une DRG et à une LPG, en plus de celles attachées aux sous-réseaux.
Ces deux nouveaux attachements de tables de routage utilisées de concert permettent de définir le chemin que devra emprunter chaque paquet entrant dans le VCN de transit :
- le traffic arrivant sur une LPG peut être aiguillé :
- vers la DRG du VCN (sortir de la région cloud),
- vers l’IP d’une instance présente dans le VCN (ex: appliance réseau & sécurité).
- le traffic arrivant sur une DRG peut être aiguillé vers une LPG du VCN (pour ressortir ensuite vers le VCN spoke associé) ou vers une IP d’instance présente dans le VCN HUB (ex: appliance réseau & sécurité).
Le schéma suivant illustre chacune des tables de routage à configurer afin d’activer une communication Est/Ouest entre les VCN 2 & VCN3.
Les éléments réseaux définis dans notre topologie cloud sont logiques (ce sont des éléments du SDN OCI), et sont bien évidemment découplés de la topologie physique du réseau OCID . D’après les tests que j’ai pu effectuer, le modèle Hub-and-Spoke OCI et les DRG/LPG ajoutés à l’architecture n’ont pas d’impact sur la latence, comparativement à un modèle point-à-point : nous sommes toujours sous la millisecond pour des communications intra-région.
Les prochains articles traiterons en détail de l’implémentation des 3 scénarios présentés :
- Mutualiser les accès on-premises & multi-cloud,
- Simplifier les architectures OCI multi-région/multi-VCN,
- Centraliser les liaisons VCN à VCN d’une même région.
Ils comporterons un synoptique des actions de configurations ainsi que du code Terraform permettant de recréer la topologie présentée.
Laisser un commentaire