Le vRack : réseaux privés chez OVH

Le vRack est une technologie de réseau privé mise au point par OVH afin de permettre a ses clients de disposer d’un réseau privé multi-produits : serveur dédié, public Cloud, private Cloud, …

Le vRack permet un cloisonnement des échanges et une totale isolation du trafic entre les clients de OVH et permet donc d’accroitre la sécurité des échanges sur votre infrastructure et vous ouvres de nouvelles opportunités en terme de sécurité par la mise en place d’une isolation au niveau de votre trafic.

Ici, nous nous focaliserons sur son utilisation avec des serveurs dédiés.

Concrètement, lorsque votre serveur est compatible vRack, celui-ci dispose d’au moins 2 cartes réseaux (que nous appellerons dans la suite de ce billet eth0 (le réseau « publique ») et eth1 (le réseau « privé ») en 1/10/40Gbps et prochainement 25Gbps.

La première, eth0, vous permet d’accéder a Internet via le réseau OVH. La seconde, eth1, est la carte réseau qui sera ajoutée dans votre vRack. C’est donc sur cette dernière que transiterons vos échanges privés.

Comment ça fonctionne le vRack ?

Pour commencer, revenons sur le nom de ce service : vRack pour « virtual rack » soit « baie virtuelle » en français. Comprenez par là que le vRack simule le fonctionne d’un switch de baie.

En quelques mots, imaginez que l’ensemble de vos serveurs OVH et ce quelques soit le datacenter (Roubaix, Gravelines, Strasbourg, Beauharnois, Warsaw, Sydney, Singapour, …), se trouvent tous dans la même baie, connectés au même switch.

Ici, les aficionados du réseau devrait commencer à comprendre ce que cela implique 😉

En effet, qui dit « même switch » dit « switching » et non « routing » : le vRack simule un réseau pur Layer 2 (cf. modèle OSI) : liberté d’adressage IP et MAC, de protocols, multicast, … Il n’y a pas de routeur entre vos serveurs, ceux-ci se trouvent dans le même réseau L2.

D’après les documentations publique disponible chez OVH, le vRack utilise deux technologies : les VLAN (802.1q) et les VxLAN. Au niveau du serveur, OVH va « tirer » un vlan jusqu’au port réseau vRack de celui-ci (la carte réseau « eth1 » de votre serveur).

De votre côté, au niveau du serveur, il ne vous reste plus qu’à configurer votre carte réseau.

Il s’agit de votre vLAN dédié, seul votre trafic y sera injecté, vous garantissant une isolation de celui-ci vis à vis de la backbone publique de OVH (Internet) et des autres clients.

Dans ce vLAN, vous allez avoir la possibilité d’utiliser jusqu’a 4092 VLAN différents. Par défaut et sans autre configuration de votre part, c’est le VLAN 0 (aussi appelé « vLAN Natif ») qui sera accessible à votre serveur tout en vous laissant la possibilité de « taguer » des interfaces additionnelles sur d’autres VLAN afin de mettre en place une isolation de votre trafic (exemple : des VMs « Web » dispose de deux carte réseaux virtuelles : la première dans le VLAN 10, lui permettant de dialoguer avec son load balancer, la seconde dans le VLAN 20, lui permettant d’échanger avec les serveurs de base de données).

Au niveau de votre vRack, vous êtes libre d’utiliser l’adressage IP de votre choix. Il est toutefois recommandé d’utiliser les plages d’IP privées prévues pour cela à savoir :

• 172.16.0.0/12
• 192.168.0.0/16
• 10.0.0.0/8

Vous devez également vous assurer que chaque serveur dispose d’une IP et d’une adresse MAC unique sans quoi vous risquez de provoquer des dysfonctionnements.

« Le vRack c’est trop cool, moi aussi je veux un vRack ! »

Rien de plus simple.
Pour ce faire il vous suffit de suivre ces guides disponible chez OVH :

• Commander un vRack 
• Ajouter ou enlever un serveur dans un vRack via le manager
• Configuration simple d’un serveur dans un vRack
• Configuration d’un serveur dans un vlan du vRack

Exemple d’utilisation

Maintenant nous disposons d’un vRack et nos serveurs sont configurés dans celui-ci. Super. Mais qu’est-ce qu’on peut en faire ? 🙂

Ici, je vais citer un cas d’utilisation assez simple à mettre en place et que je détaillerai plus en détail dans un autre article : un serveur de base de données en failover avec bascule automatique vers le serveur slave en cas de panne du master.

Dans ce scénarios, nous disposons de deux serveur de base de données SQL (MariaDB) configuré en réplication master / slave. Par l’utilisation d’un logiciel tier tel que Keepalived ou corosync, il est possible de mettre en place une bascule automatique de serveur en cas de défaillance du premier.

Prenons pour exemple l’IP qui portera notre service SQL : 172.16.1.100

Cette IP sera « flottante », c’est à dire que celle-ci sera associée a l’un ou l’autre de nos deux serveurs suivant le besoin. Nos serveurs disposes chacun d’une IP unique : sql1 : 172.16.1.1 / sql2 : 172.16.1.2. En temps normal notre IP flottante sera également associée a sql1. Keepalived se chargera de tester régulièrement si le serveur sql1 est fonctionnel. En cas de détection d’une défaillance, l’IP flottante sera automatiquement configurée sur le serveur sql2 afin que celui-ci puisse assurer la continuité du service.

Si vous souhaitez plus d’exemple d’utilisation ou que le détail de la mise en place du serveur SQL vous intéresse, n’hésitez pas à l’indiquer dans les commentaires ! 🙂