Dans un univers ou l'on est abreuvé à longeur de journée d'offres Cloud, il est utile de rappeler les bases de ce que peut être une informatique en réseau bien maîtrisée avec ses propres serveurs dans son propre environnement hébergé (que ce soit dans la salle serveur de son entreprise ou au sein d'un environnement de hosting chez OVH, OnLine ou autres…).

Les serveurs sont relativement chers et surtout les compétences pour monter sa propre architecture sont difficiles à trouver. Mais une fois surmonté ces deux difficultés, il possible de parvenir à créer une architecture magnifique et à moindre frais. Le choix entre OPEX (Cloud) et CAPEX (hosting autonome) prends ici tout son relief.
 

Au bout du compte vous bénéficierez :

• d'un hardware de meilleure qualité
• d'un prix global nettement moins cher
• d'une performance incomparable
• d'une maîtrise totale de votre architecture
• d'une confidentialité incomparable
• d'une sécurité sur mesure sans commune mesure avec quelque solution cloud que ce soit.

 

L'objectif de cet article est de présenter une architecture cible, facilement répliquable, simple à apréhender et de donner toutes les références pour permettre sa bonne mise en œuvre.

 

Design initial de la solution

La clé du succès : une architecture solide

Le premier point à prendre en compte si vous décidez de monter votre propre infrastructure de hosting, c'est de bien ségmenter votre réseau en fonction de vos besoins. Cette ségmentation aura un impact sur de nombreux aspects du projet. On pourra citer :

• la sécurité
• la performance globale
• la simplicité de mise en œuvre et
• la simplicité d'utilisation
• la capacité de sauvegarde
• la résilience de la solution

 

On prendra donc soin de lister au sein d'un tableau les besoins fonctionnels et dans la foulée on établiera un "plan réseau" qui définiera la ségmentation de notre architecture.

Liste des VLANs

Zone	Besoin fonctionnel	Zone cible	Allocation IP Privée
Administration	Gestion de l’infrastructure hyperviseurs et infra physique (routeurs, switchs, …)	VLAN 10	10.1.10.0/24
Transfert data	Réservé communication inter-hyperviseurs	VLAN 11	10.1.11.0/24
Serveurs Telco	Assurer l’interco avec certains clients / autres DC	VLAN 12	10.1.12.0/24
Vers Internet	VLAN d'interconnexion vers Internet (fourni par votre opérateur)	VLAN 20	1.2.3.4/24
Serveurs production	Assurer la production du service pour les utilisateurs	VLAN 100	192.168.100.0/24
Serveurs tests	Permettre la conduite des tests pré-production	VLAN 110	192.168.110.0/24
Serveurs BDD	Assurer le stockage des données	VLAN 120	192.168.120.0/24
Serveurs clients	Permettre aux clients d’accéder à leurs données	VLAN 130	192.168.130.0/24
Serveurs Web	Offrir un accès direct aux services via Internet	VLAN 140	192.168.140.0/24
Serveurs backup	Autoriser un backup direct des serveurs dans l’infra vers stockage NAS	VLAN 150	192.168.150.0/24

 Il est important de bien distinguer les besoins liés à l'administration (nécessaires en tout état de cause) des besoins opérationnels (fonction de votre activité).
 

S'il peut vous sembler un peu "abusif" d'opérer une telle ségmentation, sachez qu'avec les méthodes de virtualisation utilisées et une fois la couche réseau paramétrée, le déploiement d'un serveur sera aussi simple que vous ayez cinq, vingt ou cent VLANs. Il est donc opportun de bien ségmenter ce réseau par rapport à vos besoins.

Une fois l'architecture définie, prenez le temps de d'identifier les "communications inter-VLANs". Ces communications définieront soit les ACLs (niveau switch) - soit la politique de filtrage opérée au niveau de votre pare-feu ou de votre Hyperviseur (via son firewall intégré dans le cas de Proxmox). On fera donc un second tableau qui précisera ces communications :

 

Communication inter-VLANs

De / Vers	VLAN 10	VLAN 11	VLAN 12	VLAN 20	VLAN 100	VLAN 110	VLAN 120	VLAN 130	VLAN 140	VLAN 150
VLAN 10	X
VLAN 11		X
VLAN 12			X
VLAN 20				X
VLAN 100				X	X		X			X
VLAN 110				X		X	X			X
VLAN 120							X			X
VLAN 130				X			X	X		X
VLAN 140				X			X		X	X
VLAN 150							X			X

Passé ces deux premières étapes, vous disposerez d'une bonne base pour la mise en œuvre de votre réseau.
Le tableau présenté ci-dessus ne constitue pas une feuille de route, mais doit simplement permettre d'assurer une étanchéité entre des VLANs qui n'ont aucune raison de communiquer les uns avec les autres.

A ce tableau, il conviendra d'ajouter les blocs d'IPs publiques que votre opérateur vous aura attribué et qui constitueront votre gateway vers l'Internet.
 

La performance de votre réseau en question

Il est important de comprendre les possibilités offertes par l'architecture que vous êtes entrain de mettre en œuvre.
La question centrale qui doit sous-tendre votre reflexion est la suivante : les VLANs doivent-ils remonter vers mon firewall afin d'être filtrés ou peuvent-ils directement communiquer au niveau de mes switchs ?
La différence en terme de performance est fondamentale. En effet, quel que soit les performances de vos firewalls, il est improbables (impossible dans le cadre de pfSense ou OPNSense) qu'ils atteignent des performances équivalentes à celles de vos Switchs.
Le meilleur des firewalls réussira à traiter vos flux avec un débit de 3 ou 4 Gbps là ou un switch 10G permettra un traitement proche de 10 Gbps !

Le choix d'un filtrage optimum réalisé par votre firewall doit donc être soutenu par une réflexion sur la nécessité de "remonter" ces flux vers votre firewall.

Au niveau de votre hyperviseur, nous vous recommandons d'utiliser le package OpenVSwitch qui est inclus avec Proxmox.
Attention ! Une version à jour du package OpenVSwitch est essentielle pour permettre un fonctionnement opérationnel de la solution, le package à jour se trouve dans le repertoire "Enterprise" de Proxmox. Il est donc impératif d'avoir une version permettant l'accès au repertoire Entreprise Proxmox. Si vous ne possédez pas ce type d'accès, vous pouvez en faire l'acquisition auprès de notre société (le coût est aproximativement de 70€ / processeur et cela permet au projet de fonctionner dans de bonnes conditions).

 

Mise en œuvre de la solution

Vous avez maintenant les idées claires sur la structure de votre réseau et les communications de haut niveau entre les différents VLANs.
Il faut maintenant se concentrer sur la mise en œuvre de votre solution de "cloud privée" (marketing quand tu nous tiens) !

Choix des switchs

Cet élément incontournable de votre réseau doit permettre le transport fluide des données au niveau L2 ou L3.
Suivant le niveau de redondance souhaité, vous pourrez être améné à déployer des technologies du type IRF (Inteligent Resilient Framework pour les switchs HP) ou vPC (chez Cisco).
La norme nouvelle IEEE  qui soutient cela est le 802.1aq.  Ces différents protocoles permettent entre autre d'éviter les boucles L2 qui peuvent survenir et sont un remplacement des normes vieillissantes telles que Spanning-Tree.

Pour des architectures plus simples, il est parfaitement posible de se limiter à une implémentation de switchs performants avec un bon support des VLANs.
Pour plus de granularité, on choisira exclusivement des switchs "manageables".
 

Choix d'un opérateur pour votre DC

Si vous avez décidé de déployer votre infrastructure virtualisée dans un data-center, il est parfaitement possible de le déployer chez OVH. Dans ce cas là, je vous recommande de demander à ce que vos IPs publiques soient routés sur un /29 qui permet d'assurer le routage et le transport de l'ensemble de vos IPs.

Cette solution offre d'importants avantages en terme de sécurité, en effet, elle permet :

1. de disposer de l'intégralité de vos IP (les 254 adresses d'un bloc /24 par exemple)
2. d'assurer un filtrage complet des flux depuis et vers l'Internet sans avoir à recourir à des solutions alambiquées (bridge d'interfaces)
3. d'ajouter très simplement de nouveaux blocs d'IPs sur votre réseau
4. de disposer de vos propres gateways pour vos blocs d'IP
5. de limiter le plus possible votre dépendance envers votre opérateur
6. de pouvoir déployer simplement du CARP

Si vous souhaitez monter une solution basée sur Ceph (système distribué), il est parfaitement possible d'avoir une baie chez chaque opérateur en fonction de vos choix de prédilection.
Avec un peu plus de travail au niveau réseau, vous aurez ainsi une solution 100% redondante et en mesure de garantir un uptime de 100% sur vos services critiques.
 

Déploiement dans votre DC

Enfin le grand jour est arrivé !
Vous disposez de votre carte d'accès permanent au DC, vos empreintes biométriques vous permettent l'accès au saint de saint.

Là il convient de bien penser à disposer d'une réglette électrique qui vous permette de visualiser votre consommation électrique. Pourquoi ?
Parceque les opérateur de Data Center facturent deux choses : la bande passante (pour certain d'entre eux) et l'éléctricité (pour tous).
Si vous ne connaissez pas votre consommation électrique, vous risquez fort de vous retrouver avec le pire de ce qui peut survenir dans votre baie : qu'elle disjoncte (et je vous garantie que vous voulez à tout prix éviter cela) !

Prenez le temps de bien réfléchir à la structure de votre baie (ou place-t-on les serveurs, les switchs, le firewall, les réglettes éléctriques, … ?). C'est essentiel car on a vite fait de se retrouver avec des centaines de fils dans tout les sens alors qu'il aurait été si simple de les câbler correctement.
Et lorsque vous viendrez changer un système en urgence à 2h du matin un dimanche, je vous garantie que vous préférerez la baie de droite !

Donc vos switchs sont branchés, le brassage est nickel, vous avez pris contact avec l'opérateur et il a bien routé vos IPs vers votre baie.

Vous pouvez maintenant commencer à configurer vos switchs, puis votre firewall, afin de filtrer les flux de façon cohérente.
Vous avez configuré les trunks sur vos switchs afin qu'ils assurent le transport de vos flux vers votre hyperviseur, vous pouvez maintenant configuer le réseau de votre hyperviseur (le fameux OpenVSwitch).
Ici, il faut clairement comprendre ce que l'on fait car il y a pas mal de concepts différents (Bridge, Bond, VLANs, Multicast, …) et peu de place pour l'approximation. On se reportera à la documentation oficielle d'OpenVSwitch sur Proxmox ou à celle d'OpenVSwitch sur Debian.

J'en entends qui disent : "mais pourquoi faire tout cela ?" - eh bien c'est très simple : une fois configuré, vous n'aurez plus qu'à sélectionner l'appartenance d'un container ou d'un KVM à un ou plusieurs VLANs d'un simple click !
Et "oui" cela fait gagner énormément de temps et c'est très pratique - de plus si vous souhaitez avoir vos KVM répartis sur plusieurs Hyperviseurs et la capacité de les migrer d'un simple click, il est nécessaire que chaque hyperviseur dispose d'une configuration réseau identique.

 

Côté chiffrage cela donne quoi ?

L'argent, toujour l'argent !
On va donc proposer un rapide chiffrage "à la louche" du déploiement de quatre serveurs dans une baie chez OVH.

Les coûts fixes :

Poste	Prix en €	Quantité	Total
Serveur Proxmox	5000	3	20.000
Serveur Storage (4 cœurs 8 threads cadencé à 2.6GHz - 2x 8TB SAS - 128GB DDR4)	5000	1	5.000
Switch L3 manageable	1500	2	3.000
Firewall FWA-6005	1500	2	3.000
Réglette électrique manageable Eaton (E-PDU)	650	1	650
Total			26.500 €

 

Les coûts variables :

Poste	Prix en €	Quantité	Total
Housing OVH 1/2 baie	699	12 x 4 ans	8.388
Total			33.552 €

 

 

Comparaison avec une offre standard Hosting sur quatre ans :

Poste	Prix en € / mois	Quantité	Total
Serveur FS-48T-H OVH - Storage CPU :  Intel  Xeon E5-2620v3 - 6c/12t - 2,4GHz RAM :  64Go DDR4 ECC 1866 MHz)	354	12 x 4 ans	16.992
Serveur EG-256-L OVH - Proxmox CPU :  Intel  Xeon E5-2687Wv4 - 12c/24t - 3GHz RAM :  256Go DDR4 ECC 2133 MHz Disques :  SoftRaid  2x4To	409,99	12 x 4 ans x 3 serveurs	59.038
Firewall ?	-	-	-
Total			76.030 €

 

Résultat après 4 années d'exploitation :

Poste	Prix en €
Housing + Serveurs autonomes	60.052
Hosting Serveurs dédiés OVH	76.030
Différence	- 15.978

Notre conclusion est donc sans appel : il est nettement plus avantageux d'assurer la propre exploitation de ses serveurs, surtout si l'on prend en compte le contexte de ce que fournis OVH et l'absence totale de sécurité sur l'ensemble de l'infrastructure "Serveur dédiés" qu'ils proposent.
La comparaison est ici opérée avec OVH, mais elle serait quasi identique chez Online.

Le prix, la qualité, l'efficacité est meilleure si l'on opte pour une infra auto-hébergée.
 

---

Si vous avez un projets Proxmox, ZFS, CEPH, d'architecutre réseau, n'hésitez pas à nous contacter.