En tant que fournisseur d’infrastructures cloud opérant ses propres datacenters et son propre réseau, OVH dispose d’une position privilégiée pour observer et anticiper l’évolution des usages en matière de trafic.

Ce positionnement au cœur des échanges numériques a permis, il y a déjà plusieurs années, l’établissement d’un constat clair : si les flux d’informations étaient historiquement verticaux (« nord-sud », c’est-à-dire des datacenters vers l’extérieur), les flux horizontaux (« ouest-est », c’est-à-dire les flux internes à une infrastructure) augmentent de manière exponentielle. Ils représentent même un trafic parfois plus important que celui des flux sortants ! Les machines, qui travaillent désormais en grappe, ont en effet besoin d’échanger de plus en plus de données entre elles. Et ce de manière privée, sans passer par le réseau public (internet).

Il peut par exemple s’agir d’infrastructures n-tiers, potentiellement réparties entre plusieurs sites dans le cadre d’un plan de reprise ou de continuité d’activité (PRA/PCA), ou encore de clusters big data nourris par une production de données en constante hausse. Plus récemment, l’essor de l’IoT (des équipements connectés aux ressources très limitées) et les architectures logicielles orientées microservices (facilitées par la « containérisation ») rendent nécessaire de déporter toujours plus de calculs dans les datacenters et, donc, de faire communiquer entre elles les différentes machines le composant.

Ces infrastructures sont le reflet de trois impératifs des projets IT modernes : disposer de ressources de calcul suffisantes pour traiter efficacement des volumes de données de plus en plus massifs, garantir la haute disponibilité des applications et assurer une sécurité maximale à son infrastructure.

Le vRack, un service précurseur

C’est dans ce contexte qu’OVH a conçu en interne et déployé dès 2009 la technologie vRack (« Virtual Rack », ou baie virtuelle), pour interconnecter les machines entre elles. Très en avance sur son temps lors de son lancement, le vRack permet l’interconnexion privée des serveurs, qu’ils se situent au sein d’un même datacenter ou dans différents centres de données d’OVH.

Particularité notable de la technologie vRack : elle s’appuie sur un réseau OVH physique et dédié, permettant ainsi une interconnexion horizontale sans passer par le réseau public ! Débits en hausse, latences en baisse et gains de sécurité en sont les principaux bénéfices immédiats, tout en permettant une grande flexibilité et une grande simplicité dans la gestion de l’infrastructure. Par exemple, si un bloc d’IP est attribué à un VLAN, le routage est alors réalisé dynamiquement au sein du réseau privé. Ceci épargne aux administrateurs la mise en place d’un plan d’adressage IP spécifique, notamment dans le cadre d’une infrastructure multi-datacenters.

Avec le vRack, les utilisateurs peuvent donc interconnecter les différentes briques de leurs infrastructures. Y compris quand il s’agit de ressources de nature différentes : serveurs physiques ou virtuels (Public Cloud, Private Cloud) et même ressources internes de l’entreprise, grâce au vRack Connect (connexion de votre réseau d’entreprise à votre réseau privé chez OVH). Cela facilite la mise en place à grande échelle de solutions de cloud hybride.

Plus qu’une fonctionnalité complémentaire, le vRack est aujourd’hui devenu l’une des pierres angulaires d’un grand nombre d’infrastructures client. OVH est d’ailleurs le premier utilisateur de la technologie, utilisée en interne pour la conception d’un grand nombre de solutions (Private Cloud, Exchange, Public Cloud, etc.), démontrant ainsi sa robustesse.

Crucial dans la création d’infrastructures, le vRack est proposé gratuitement et embarqué dans le coût global pour la plupart des produits concernés, au même titre que la protection anti-DDOS, le tout sans limite de volume de trafic ! En tant que client, vous bénéficiez systématiquement et en continu du maximum de la bande passante contractuelle liée à votre offre (ou de la capacité maximale de la carte réseau privée intégrée au sein de votre serveur dédié).

Retour sur une itération continue

Novateur, le vRack a évolué au fil des années et des améliorations apportées par les équipes d’OVH. Les besoins des entreprises pour ce type d’interconnexion se sont accrus et diversifiés, comme anticipé lors du lancement de cette technologie, amenant le vRack à passer par différents pivots techniques. S’il était nécessaire de composer avec les technologies réseau existantes en 2009 (non pensées pour ce type d’usage), ces dernières ont beaucoup évolué et ont notamment connu la révolution de la virtualisation.

vRack 1.0

Ainsi, le vRack 1.0 était disponible sur une région unique (RBX) et offrait un seul VLAN, basé sur la technologie éponyme. Concrètement, il s’agissait d’un réseau privé virtuellement créé à l’intérieur du réseau public, qui ne permettait « que » d’interconnecter entre eux des serveurs dédiés.

vRack 1.5

Le vRack 1.5 a nécessité l’ajout d’une seconde carte réseau sur les serveurs. Un réseau privé parallèle au réseau public, physique cette fois, a également dû être déployé au sein des datacenters OVH ; ils ont d’ailleurs été recâblés pour cela !

Lors de cette étape, le vRack est devenu multizone. Les clients ont pu interconnecter gratuitement des serveurs entre les quatre principales régions géographiques alors proposées par OVH : RBX (France), SBG (France), BHS (Canada) et GRA (France). Une proposition de valeur assez inédite chez les fournisseurs de cloud.

C’est aussi à ce moment que l’offre Private Cloud est devenue compatible avec le vRack. En interconnectant datacenters virtuels et machines dédiées, les utilisateurs ont pu bénéficier de plus de puissance brute afin, par exemple, d’exploiter de lourdes bases de données.

vRack 2.0

Le vRack 2.0 est intimement lié à l’adoption de la technologie QinQ. Celle-ci permet, entre autres, de créer plusieurs VLAN au sein d’une même trame Ethernet, à l’aide de tags.

Le vRack 2.0 a également offert la possibilité à chaque utilisateur de créer plusieurs VLAN – jusqu’à 4 000 – afin d’augmenter le niveau d’isolation de leur infrastructure. En segmentant l’installation en compartiments étanches d’un point de vue réseau, elle devient notamment plus difficile à pénétrer depuis l’extérieur.

Enfin, c’est à ce stade que le vRack a été utilisé en tant que composant de base de l’offre Private Cloud. En effet, pour communiquer entre elles, les machines virtuelles (VM) d’un Private Cloud OVH emploient cette technologie.

vRack 3.0, une nouvelle dimension

Le vRack 3.0, quant à lui, est bien plus qu’une évolution. Un véritable pivot technologique, que la simple incrémentation du numéro de version de laisse pas paraître.

Déjà en production depuis deux ans pour tout l’univers serveurs dédiés (serveurs compatibles vRack), il revoit en profondeur son architecture et les technologies employées.

Des couches techniques revues

Contrairement aux précédentes versions, le vRack 3.0 ne s’appuie plus sur QinQ mais sur la technologie VxLAN. Plusieurs avantages découlent de ce choix, à commencer par le nombre de VLAN adressables. Basé sur le protocole 802.1Q, le QinQ ne permet pas nativement d’adresser plus de 4 096 VLAN. Si ce nombre reste confortable, le passage au VxLAN porte cette limite théorique à plus de 16 millions sur un même domaine !

Par ailleurs, grâce au transit de trames directement au niveau 2 en UDP, cette technologie rend possible une segmentation VLAN en dehors d’un domaine Ethernet unique, permettant ainsi de s’affranchir de ce dernier. Dans le cadre d’un datacenter virtuel, le VxLAN étend aussi considérablement les réseaux de couche 2, offrant plus de souplesse et de flexibilité aux administrateurs.

Notons également que le vRack 3.0 respecte le fonctionnement des réseaux privés implémentés nativement dans OpenStack Neutron. Conséquence : les réseaux privés vRack 3.0 entre des instances Public Cloud OVH sont pilotables via l’API native d’OpenStack ! Un degré d’intégration et de transparence appréciable, permettant de simplifier la gestion d’une infrastructure complexe. On notera d’ailleurs que, contrairement aux standards du marché, les clients Public Cloud d’OVH ne se voient pas facturer le trafic inter-datacenter.

Une nouvelle architecture

Dans cette version, l’architecture du système vRack et les infrastructures sous-jacentes ont été revues de fond en comble. L’objectif est d’offrir un service plus scalable, plus résilient et sans « noisy neighbor effect » (surconsommation de ressources par d’autres utilisateurs).

Quelques éléments de contexte s’imposent afin de mieux saisir l’ampleur de ce changement de design, ainsi que les avantages induits.

À partir du vRack 1.5, des routeurs « G5 » ont été déployés pour jouer le rôle de passerelles entre les datacenters d’OVH pour le trafic vRack. Il s’agit d’équipements hautement disponibles (deux cartes de supervision peuvent basculer l’une vers l’autre en cas de problème), dotés d’une puissance de calcul élevée pour supporter d’importants échanges. Leur présence était rendue nécessaires par l’infrastructure centralisée mise en place pour les premières versions du vRack, chaque zone géographique étant dotée de son équipement. Cependant, un matériel a des limites physiques. Bien que parfaitement dimensionnée et robuste, cette architecture n’était donc pas scalable à l’infini.

FIGURE 1 : Architecture globale du vRack 2.0

À l’inverse, le vRack 3.0 repose sur un schéma segmenté composé de plusieurs cellules elles-mêmes distribuées : il n’y a plus de point central ou de passage unique obligé dans chaque zone géographique !

Le réseau vRack multiplie ainsi les points d’échange au sein des datacenters, permettant en outre une amélioration sensible des débits et des latences. Par exemple, deux machines situées dans un même centre de données verront leur connexion vRack s’établir directement, sans passage par un autre emplacement.

De plus, la segmentation induite par cette infrastructure distribuée évite tout phénomène de « noisy neighboor ». Le trafic général étant réparti sur un nombre virtuellement illimité d’échangeurs, il devient en effet possible de créer une multitude de cellules indépendantes les unes des autres.

L’ensemble permet également d’augmenter la résilience de l’infrastructure, en limitant fortement le périmètre d’une éventuelle défaillance côté client. Les utilisateurs peuvent ajuster plus finement la répartition de leurs machines virtuelles, en les plaçant dans différentes zones au sein d’une même région ou d’un même datacenter, sans compromettre l’ensemble de l’installation en cas de coupure d’une cellule (notons que du côté d’OVH, l’ensemble des éléments critiques composant le vRack sont redondés, dans des emplacements différents).

FIGURE 2 : Architecture globale du vRack 3.0

Le vRack 3.0 est ainsi l’aboutissement d’une évolution progressive. S’appuyant initialement sur une infrastructure plutôt monolithique, il est devenu un véritable réseau « full mesh » (totalement décentralisé). Afin de toujours continuer à anticiper les besoins de ses utilisateurs, le vRack est maintenant capable de grandir tout aussi facilement verticalement, pour ajuster ses capacités de traitement, qu’horizontalement, afin de garantir sa scalabilité.

« Il y a trois ans, les flux d’information étaient essentiellement verticaux, c’est-à-dire depuis nos datacentres vers l’extérieur, vers Internet, explique Octave Klaba. Aujourd’hui, une partie croissante de ces flux sont horizontaux : les machines ont besoin d’échanger des données entre elles, rapidement et de manière sécurisée. » Il s’agit d’infrastructures n-tiers de sites e-commerce exploitant un pool de VPS et serveurs physiques (les uns utilisés comme frontaux web, les autres hébergeant des bases de données isolées de l’Internet public). Ou encore des plateformes Big Data. « Il y a quelques années, le Web était statique. L’utilisateur se connectait aux machines pour recevoir un contenu standard. Puis le Web est devenu dynamique, les applications générant les contenus selon les demandes de l’utilisateur, ce qui a nécessité des machines plus puissantes. Aujourd’hui, les objets connectés – du poste de travail au smartphone – sont des coquilles vides, aux ressources très limitées. Toute l’intelligence est déportée au sein des datacentres. Les serveurs travaillent en cluster pour générer et exploiter de grands volumes de données, avant de retourner sur les terminaux des utilisateurs le « résultat ». »

Cette évolution majeure, OVH l’a décelée bien avant les autres : « Notre force réside dans le nombre et le haut niveau de nos utilisateurs à travers le monde, poursuit Octave. Les besoins remontés hier par quelques startups très innovantes préfiguraient les besoins du plus grand nombre aujourd’hui. »

vRack 1.5 : un réseau privé multidatacentre pour interconnecter serveurs et clouds dédiés

Pour répondre à cette demande d’un réseau privé entre les machines, dès 2009 OVH.com lançait le vRack 1.0. L’objectif : permettre à un utilisateur de rassembler plusieurs serveurs dédiés au sein d’une baie virtuelle. Une fonctionnalité alors disponible à la condition que les différentes machines soient hébergées sur le même site, en l’occurrence à Roubaix.

Depuis, OVH.com a étendu son parc de datacentres en s’implantant à Strasbourg et Gravelines en France, et Beauharnois au Canada . Sa gamme de services s’est par ailleurs considérablement élargie, avec l’arrivée des serveurs de stockage , VPS , solutions de clouds public ( RunAbove ) et privé ( Dedicated Cloud ), clusters Big Data , etc. « Les clients ont éclaté leur parc de machines sur plusieurs centres de données, puis ils ont diversifié la composition de leurs infrastructures en associant aux ressources physiques des ressources cloud. Naturellement, ils ont réclamé un moyen d’interconnecter, toujours via un réseau privé, ces différents services », explique Mehdi Bekkai, chef de produits serveurs dédiés.

Un défi lancé aux ingénieurs d’OVH.com : « Nous avons consulté les équipementiers. Pas seulement ceux avec lesquels nous travaillions déjà. Ils n’avaient pas anticipé ce nouveau besoin – en fait un véritable changement de paradigme dans la manière de concevoir le réseau. Il était impensable d’attendre que leur R&D sur le sujet aboutisse ; nous devions proposer à nos clients des solutions immédiatement exploitables », se souvient Guillaume Delabre de l’équipe réseau d’OVH.com. « Il fallait notamment trouver comment transporter les vRacks de nos clients d’un datacentre à l’autre. Nous avons pour cela combiné plusieurs technologies, en détournant certaines d’entre elles de leur usage premier. Cela s’est concrétisé à l’été 2013 par le déploiement d’un réseau parallèle à celui qui connecte nos centres de données à l’Internet. Pour connecter les machines à ce réseau privé, une seconde carte réseau a été intégrée aux nouvelles gammes de serveurs éligibles au vRack. Et l’ensemble de ce réseau bis a été câblé. »

Un travail de fourmi : les techniciens des datacentres ont déroulé près de 2 000 kilomètres de câbles en à peine trois mois. « Nous pensons que le vRack est incontournable pour tous les clients disposant de plusieurs services chez OVH.com, explique Mehdi. C’est pourquoi nous l’avons déployé à grande échelle. Il est maintenant inclus dans une grande partie des offres. »

Répondre aux usages d’aujourd’hui et de demain

Le vRack 1.5, c’est la possibilité de connecter différents services OVH.com entre eux, au sein d’un ou plusieurs réseaux privés sécurisés (VLAN) : serveurs de la gamme Infrastructure , Dedicated Cloud (gammes Enterprise et Infrastructure), serveurs de stockage, serveurs Big Data. Le tout en quelques clics dans l’espace client ou via l’ API OVH , et avec un effet immédiat. Ainsi interconnectés, les serveurs physiques et virtuels, les VM, s’échangent les données plus rapidement, sans que celles-ci ne transitent par le réseau public. Donc en toute sécurité. L’utilisateur bénéficie au sein du vRack d’une capacité de 1, 10 ou 40 Gbps, suivant les caractéristiques de ses machines et de leur carte réseau. Mehdi Bekkai, chef de produit serveurs dédiés, dresse l’inventaire des usages actuels du vRack : « L’utilisation la plus évidente est d’isoler les serveurs critiques du web, et donc des attaques et intrusions. L’architecture n-tiers, qui devient la norme pour les projets importants (e-commerce, intranets…), tant pour des questions de performances que de sécurité, est aujourd’hui plus facile à déployer.

Le vRack, en permettant une transmission des données plus rapide et plus sûre, profite également aux utilisateurs qui mettent en œuvre une infrastructure redondée ou distribuée entre plusieurs datacentres distants. Cela dans le cadre d’un PRA/PCA, ou pour organiser la répartition de la charge en fonction de l’origine géographique des utilisateurs. Dans ce cas, le vRack permet de synchroniser les différents éléments de l’infrastructure. Pour les mêmes raisons, les entreprises plébiscitent le vRack pour le backup de données critiques vers un serveur de stockage par exemple. Ou encore pour coupler à leur Dedicated Cloud – hébergeant de multiples frontaux web – des serveurs dédiés destinés à maximiser les performances de leurs bases de données SQL.

Enfin, les utilisateurs s’épargnent l’élaboration du plan d’adressage IP des différents éléments de leur infrastructure, souvent complexe et chronophage. Un bloc d’IP peut être attribué à un VLAN et le routage est réalisé dynamiquement au sein du réseau privé, grâce au protocole ARP. Plus besoin non plus de modifier les règles des pare-feu pour autoriser les IP privées des machines dernièrement ajoutées. La gestion des pics de charge ou le redimensionnement de l’infrastructure par extension horizontale sont facilités. »

Jusqu’à 4 000 VLAN par vRack pour isoler chacun de ses clients et connecter les applications entre elles

« Certains clients, utilisateurs satisfaits par le vRack, nous ont demandé d’aller encore plus loin. Des revendeurs souhaitaient par exemple isoler, au sein de leur vRack, chacun de leurs clients – à qui ils allouent par exemple plusieurs machines virtuelles. Ou encore de grandes entreprises, qui désirent compartimenter leur infrastructure et en filtrer les accès de façon très fine. » En clair, il était nécessaire de pousser les possibilités d’isolation au sein même du réseau privé physique reliant les différents services d’un même utilisateur. « Nous avons opté pour une technologie qui permet d’encapsuler des VLAN au sein d’un VLAN, rapporte Guillaume. Concrètement, un vRack est déployé entre les différents services d’un client, c’est-à-dire une connexion physique entre les différents ports des machines. Et, au sein de ce vRack, le client a la possibilité de créer jusqu’à 4 000 VLAN. Le trafic de chacun d’entre eux est tagué, de façon à pouvoir être encapsulé et décapsulé en n’importe quel point du réseau privé configuré par l’utilisateur. Détail qui a son importance, l’utilisateur peut taguer lui-même chacun de ses VLAN, c’est-à-dire choisir le numéro de chacun des sous-réseaux qui relieront les services de son choix. » Aujourd’hui, les clients du Dedicated Cloud profitent déjà de cette élévation du nombre du VLAN disponible (vRack 2.0).

D’ici quelques semaines, les possesseurs de serveurs dédiés éligibles disposeront également d’un vRack pouvant contenir jusqu’à 4 000 VLAN. « La possibilité de combiner, au sein du vRack, ressources physiques et virtuelles, et celle de multiplier les VLAN sont d’autant plus intéressantes qu’il sera bientôt possible de répartir la charge entre différents services interconnectés par un VLAN, grâce à l’IP load balancing », ajoute Mehdi.

Dedicated Connect : interconnecter son datacentre interne aux datacentres OVH pour créer des clouds hybrides

« Des entreprises souhaitent externaliser tout ou partie de leur SI, en isolant cette infrastructure externe au sein d’un réseau privé. Pour eux, la meilleure solution consiste à bénéficier d’une connexion privée directe depuis leurs bureaux, leurs datacentres, jusqu’à nos datacentres, de façon à ce que les connexions et les données ne transitent pas par le réseau public, qui est par définition une zone de confiance faible », explique Mehdi. Les équipes d’OVH.com ont donc déployé de nouveaux routeurs pour recevoir les connexions fibrées des utilisateurs directement au sein des différents points de présence (PoP) du réseau mondial d’OVH.com. À ce jour, plusieurs dizaines de clients d’OVH.com profitent d’ores et déjà de cette option « Dedicated Connect », soit une connexion directe, 100 % privée, sans limite de bande passante ni de trafic, via un ou deux ports 1 ou 10 Gbps, entre leur SI interne et l’extension de celui-ci au sein des infrastructures OVH.com.

En supportant VXLAN, le vRack s’adapte à l’évolution du marché de l’hébergement d’applications, du IaaS vers le PaaS

« Nos clients se sont aperçus qu’ils passaient plus de temps à mettre en production leurs applications qu’à les coder. Un comble ! », rapporte Mehdi. » Ainsi s’explique le succès croissant de la technologie des conteneurs logiciels (LXC), dans lesquels le développeur charge une application et ses dépendances, de sorte que celle-ci fonctionne sur tout type de ressource. « La création d’un conteneur est quasi-instantanée, quand une VM peut mettre plusieurs minutes à booter. Cette technologie, portée par des projets comme Docker, se révèle donc idéale pour étendre dynamiquement des systèmes distribués sur de nouvelles ressources (scalabilité horizontale). Ces conteneurs peuvent prendre place sur une machine nue comme sur une VM, l’avantage étant de pouvoir basculer cette dernière d’un serveur à l’autre pour assurer une meilleure disponibilité ». Le vRack – on y revient ! – est un élément essentiel de ce nouveau type d’architecture : les 4 000 VLAN disponibles au sein du vRack peuvent supporter, chacun, la création de 16 millions de VXLAN. Ceci en toute transparence pour l’utilisateur : « La complexité du vRack est masquée par l’API : le développeur programme et automatise la création de ces réseaux privés par de simples appels. Techniquement, peu lui importe que le VLAN déployé soit en fait un VLAN encapsulé ou encore un VXLAN : ce qu’il voit, c’est que cela fonctionne immédiatement. » Les développeurs se font devops, sans avoir nécessairement besoin de compétences poussées en matière de réseau. « Nous sommes entrés dans l’ère du Software Defined Network, conclut Octave. Mais les équipementiers ne nous ont pas encore rattrapés… Faute de trouver chez eux le matériel adéquat, nous concevons aujourd’hui notre propre routeur virtuel pour que, à moyen terme, chaque utilisateur puisse gérer encore plus précisément ce millefeuille de réseaux, y ajouter des fonctionnalités et des services. Ce routeur, en réalité un software développé par nos ingénieurs qui tournera sur un serveur standard, permettra par exemple d’interconnecter via le vRack des serveurs et clouds dédiés avec de nouveaux services, VPS, ressources du public cloud (RunAbove), VPN. Ou encore un accès xDSL fourni par OVH.com. Soit une version « light » du Dedicated Connect. Mais ce n’est pas tout : ce routeur, point de convergence de tous les réseaux privés d’un utilisateur, sera également capable de réaliser du load-balancing de niveaux 7 (http), 3 et 4 (IP). » Affaires à suivre.

* Selon une enquête du cabinet Gartner publiée en septembre 2013, 70 % des entreprises interrogées indiquent que le cloud hybride allait faire partie de leur stratégie d’ici 2015.