Construire un cloud chez soi
« Le cloud c’est juste l’ordinateur de quelqu’un d’autre ». Vous avez sans doute déjà entendu cette phrase, peut-être un peu moins en 2026, mais il y a à peine 10 ans de cela, c’était la phrase fétiche des anti-cloud.
Cette phrase signifie que le cloud c’est juste un fournisseur qui vous met à disposition une machine pour que vous n’ayez pas vous-même à vous occuper de cette machine.
C’était déjà réducteur il y a 10 ans, mais peut-on en vouloir aux utilisateurs de finalement ne voir qu’un fournisseur de machines virtuelles et donc de ne pas voir la différence entre ce qu’on appelle un Cloud Provider et un hébergeur classique ? C’est vrai que dans les deux cas on pourrait résumer ça, côté client, à « l’ordinateur de quelqu’un d’autre ».
10 ans après, un peu tard peut-être donc, il est temps d’expliquer simplement à tout le monde ce qu’est le cloud. Et pour cela quoi de mieux que de commencer à en construire un !
Les premiere briques
Alors par quoi commencer ? On peut commencer par découper notre cloud en trois briques assez fondamentales qui serviront ensuite à construire par-dessus des services, voire d’autres briques pour d’autres services.
Ces fondamentaux sont :
- Des réseaux isolés logiquement pour chaque client, chaque client constituant un tenant.
- Du calcul, c’est-à-dire les ressources sur lesquelles vont tourner nos workloads, sous forme de VM ou pas d’ailleurs.
- Du stockage, qui peut être de l’espace disque ou même du stockage objet.
Le tout, organisé ou orchestré par une couche logicielle qu’on nomme le Control Plane !
« Oui mais le cloud c’est des centaines, voire des milliers de machines, comment je peux construire ça chez moi ? »
Pas de panique mon ami. Il n’est pas question ici de mettre des tas d’ordinateurs en réseau ensemble et de contrôler leur configuration ou leur distribution à distance.
Enfin, vous le pouvez si vous le souhaitez, mais on peut simuler le fonctionnement d'un cloud bien plus facilement.
Nous allons simplement avoir besoin d’une distribution Linux et d’un peu d’imagination pour simuler de façon correcte ce que l’on souhaite représenter.
L’isolation réseau des tenants
Commençons par un problème simple à résoudre. Si nous avons deux clients, que l’on nommera Alice et Bob (habituez-vous à Alice et Bob car ils vont devenir vos meilleurs amis), sur une même infrastructure, comment éviter que Bob puisse aller chez Alice et vice-versa ?
Le Network Namespace
Vous avez peut-être déjà entendu ce terme par des Kubernetes hipsters disant que Docker n’avait rien inventé avec les containers, qu’ils ont juste utilisé des Network Namespaces.
C’est pas totalement faux. En effet, sous Linux, un network namespace permet d’isoler d’un point de vue réseau les ressources utilisées par des processus. Pour Docker, on verra ça une prochaine fois.
Dans notre simulation, nous allons utiliser chaque network namespace pour représenter un nœud placé dans le réseau de son tenant.
Par nœud, on entend ici une ressource qui peut être un ordinateur ou une VM.
Le bridge
Un autre composant qui va nous être utile pour simuler notre cloud va être le bridge, qui jouera l’équivalent virtuel de notre switch.
On va donc pouvoir connecter les nœuds de nos clients à leur switch.
Veth pair
Comment on connecte un nœud à un réseau ? Avec un câble évidemment.
Cela va être le rôle de notre Veth pair qui sera branchée d’un côté à notre nœud, de l’autre à notre switch.
Voilà, on a nos briques fondamentales pour faire du réseau. On va donc pouvoir commencer à construire notre infrastructure.
D’abord, la création de nos nœuds qui seront affectés à différents tenants. Inutile d’en créer beaucoup pour le moment.
sudo ip netns add node10
sudo ip netns add node20
sudo ip netns add node30
sudo ip netns add node40
Puis la création de nos switchs.
sudo ip link add pc-alice type bridge
sudo ip link set pc-alice up
sudo ip link add pc-bob type bridge
sudo ip link set pc-bob up
Construire le réseau d’Alice
Pour construire le réseau d’Alice, il faut donc connecter les nœuds d’Alice au même switch afin qu’ils puissent communiquer entre eux et seulement entre eux.
On va donc créer notre premier câble virtuel.
sudo ip link add v-node10-h type veth peer name v-node10-n
sudo ip link set v-node10-n netns node10
sudo ip link set v-node10-h master pc-alice
sudo ip link set v-node10-h up
Puis configurer le sous-réseau.
sudo ip netns exec node10 ip link set lo up
sudo ip netns exec node10 ip link set v-node10-n up
sudo ip netns exec node10 ip addr add 10.10.0.10/24 dev v-node10-n
On fait exactement pareil sur le nœud suivant pour avoir deux machines sur le même tenant.
sudo ip link add v-node20-h type veth peer name v-node20-n
sudo ip link set v-node20-n netns node20
sudo ip link set v-node20-h master pc-alice
sudo ip link set v-node20-h up
sudo ip netns exec node20 ip link set lo up
sudo ip netns exec node20 ip link set v-node20-n up
sudo ip netns exec node20 ip addr add 10.10.0.11/24 dev v-node20-n
Construire le réseau de Bob
Un client c’est bien, mais on n’a jamais vu un Cloud Provider avec un seul client.
Donc ne perdons pas de temps et faisons la même chose avec notre client Bob, qui aura lui les nœuds 30 et 40.
sudo ip link add v-node30-h type veth peer name v-node30-n
sudo ip link set v-node30-n netns node30
sudo ip link set v-node30-h master pc-bob
sudo ip link set v-node30-h up
sudo ip netns exec node30 ip link set lo up
sudo ip netns exec node30 ip link set v-node30-n up
sudo ip netns exec node30 ip addr add 10.20.0.10/24 dev v-node30-n
sudo ip link add v-node40-h type veth peer name v-node40-n
sudo ip link set v-node40-n netns node40
sudo ip link set v-node40-h master pc-bob
sudo ip link set v-node40-h up
sudo ip netns exec node40 ip link set lo up
sudo ip netns exec node40 ip link set v-node40-n up
sudo ip netns exec node40 ip addr add 10.20.0.11/24 dev v-node40-n
La procédure est bien sûr identique et c’est très important, car une grande partie du défi du cloud consiste justement à être capable de reproduire automatiquement ce genre d’opérations à grande échelle.
Testons la communication
Bien, maintenant il est temps de voir si nos réseaux sont fonctionnels, donc si les nœuds d’Alice peuvent communiquer entre eux, et même chose du côté de Bob.
Mais aussi de tester l’isolation. Nos deux clients ne doivent pas pouvoir se parler.
On va donc exécuter un ping du node10 vers le node20, qui appartiennent tous les deux à Alice.
sudo ip netns exec node10 ping -c 3 10.10.0.11
PING 10.10.0.11 (10.10.0.11) 56(84) bytes of data.
64 bytes from 10.10.0.11: icmp_seq=1 ttl=64 time=16.0 ms
64 bytes from 10.10.0.11: icmp_seq=2 ttl=64 time=0.160 ms
64 bytes from 10.10.0.11: icmp_seq=3 ttl=64 time=0.103 ms
--- 10.10.0.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 0.103/5.437/16.048/7.503 ms
Et la même chose du node30 au node40, qui appartiennent à Bob.
sudo ip netns exec node30 ping -c 3 10.20.0.11
PING 10.20.0.11 (10.20.0.11) 56(84) bytes of data.
64 bytes from 10.20.0.11: icmp_seq=1 ttl=64 time=0.791 ms
64 bytes from 10.20.0.11: icmp_seq=2 ttl=64 time=0.241 ms
64 bytes from 10.20.0.11: icmp_seq=3 ttl=64 time=0.260 ms
--- 10.20.0.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2029ms
rtt min/avg/max/mdev = 0.241/0.430/0.791/0.254 ms
Par contre, il est impossible pour Alice ou Bob de communiquer avec l’autre réseau.
sudo ip netns exec node10 ping -c 3 10.20.0.10
ping: connect: Network is unreachable
Nous avons donc bien une première forme d’isolation.
« Hey mais attends, là on a juste créé deux réseaux qui ne communiquent pas, c’est niveau première année de BTS et tu appelles ça du cloud ? Est-ce que tu ne te foutrais pas un peu de notre gueule ? Là ça ne communique pas juste parce que ça n’a pas de route ! Je me rappelle quand même de mes cours ! »
Le test de la route
Très bonne remarque.
Deux sous-réseaux IP distincts ont besoin d’un mécanisme de routage pour communiquer.
Alors que se passe-t-il quand on tente d’ajouter une route ?
sudo ip netns exec node10 ip route add 10.20.0.0/24 dev v-node10-n
Puis regardons la table de routage :
sudo ip netns exec node10 ip route
10.10.0.0/24 dev v-node10-n proto kernel scope link src 10.10.0.10
10.20.0.0/24 dev v-node10-n scope link
Voilà, on a une route. Testons !
sudo ip netns exec node10 ping -c 3 10.20.0.10
PING 10.20.0.10 (10.20.0.10) 56(84) bytes of data.
From 10.10.0.10 icmp_seq=1 Destination Host Unreachable
From 10.10.0.10 icmp_seq=2 Destination Host Unreachable
From 10.10.0.10 icmp_seq=3 Destination Host Unreachable
--- 10.20.0.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2049ms
pipe 3
Ah bah non, toujours pas.
Cette route ne crée pas réellement de chemin vers Bob. Elle dit simplement à Alice de considérer le réseau 10.20.0.0/24 comme directement accessible via son interface v-node10-n.
Cette fois Alice sait donc bien par quelle interface essayer d’envoyer son trafic.
Le problème est maintenant plus bas, au niveau de la couche 2.
Node10 cherche 10.20.0.10 sur son réseau Ethernet en envoyant une requête ARP, mais cette requête reste confinée au bridge pc-alice.
Il n’existe aucun chemin de couche 2 vers pc-bob.
Nos deux réseaux sont donc bien isolés dans notre architecture actuelle.
Alors le cloud, c’est juste du réseau de première année ?
Oui et non.
En effet, la partie réseau ici est assez basique, mais le cloud n’a pas besoin d’être compliqué dans son architecture.
Bien au contraire, il va se complexifier ensuite de façon intrinsèque et au fur et a mesure, donc quand des choses peuvent être gardées simples, gardons-les.
C’est quand on va commencer à automatiser la création et la gestion de cette infrastructure à grande échelle que va commencer à ressembler à un cloud : création de nouveaux tenants, suppression des anciens, modification de leurs limites, allocation et désallocation de nœuds, déplacement des ressources, etc.
Gérer en permanence l’état de milliers, voire de millions d’éléments, c’est là que les choses commencent vraiment à devenir intéressantes.
Et cette partie logicielle sera justement le sujet de la partie 2, car il y a beaucoup à dire.
Et à coder.
Top comments (0)