par Dans la continuité de mon tutoriel complet : Tuto Virtualisation V 2022 : Debian 11, KVM et Openvswitch, on va monter notre premier pool de serveurs.
Dans l’exemple, ce sont des futurs serveurs Backweb, mais cela peut être ce que vous voulez.
Nous allons simplement les installer et les brancher sur le réseau. L’idée est de vous montrer un exemple pour que vous soyez autonome pour les suivants.
Cet article sera souvent mentionné dans les articles à venir quand on causera pool de serveurs (sql, ceph, etc…)
I – Présentation
Dans l’exemple, on va expliquer la mise en place du VLAN, la configuration des routeurs, etc…
Par la suite, quand on ajoutera un nouveau pool, il suffira de suivre les étapes II, IV et V.
II – Mise en place VM
On va lancer la création des VMs avec le script disponible ici.
En option dans le script, je passe ça :
size_var=3 size=4 ram=1024 cpu=2
Et on lance :
hyperv# ./create.sh -n backweb1 -i 31 -s 1 hyperv# ./create.sh -n backweb2 -i 32 -s 0
On va leur ajouter une interface dans le vlan 100.
Un fichier net-vlan100-backweb1.xml :
<interface type='network'>
<source network='intern-vlans' portgroup='100'/>
<target dev='backweb1.1'/>
<model type='virtio'/>
<driver name='vhost'/>
</interface>
Et un fichier net-vlan100-backweb2.xml :
<interface type='network'>
<source network='intern-vlans' portgroup='100'/>
<target dev='backweb2.1'/>
<model type='virtio'/>
<driver name='vhost'/>
</interface>
On injecte :
hyperV# virsh attach-device backweb1 net-vlan100-backweb1.xml --config hyperV# virsh attach-device backweb2 net-vlan100-backweb2.xml --config
Passons maintenant à la configuration réseau, côté VM :
Pour Backweb1, on monte :
hyperv# mount /dev/mapper/vg1-backweb1p1 /root/mountlvm/
On édite le fichier /root/mountlvm/etc/network/interfaces pour y ajouter cela à la fin :
auto eth1 iface eth1 inet static address 10.100.0.31 netmask 255.255.255.0 gateway 10.100.0.254
On démonte :
hyperv# unmount /root/mountlvm/
Pour Backweb2 :
hyperv# mount /dev/mapper/vg0-backweb2p1 /root/mountlvm/
On édite le fichier /root/mountlvm/etc/network/interfaces pour y ajouter cela à la fin :
auto eth1 iface eth1 inet static address 10.100.0.32 netmask 255.255.255.0 gateway 10.100.0.254
On démonte :
hyperv# unmount /root/mountlvm/
Et on peut lancer nos VMs :
hyperv# virsh start backweb1 hyperv# virsh start backweb2
III – Réseau
Maintenant, il s’agit de faire en sorte que ces VMs aient un accès au net. On va regarder pour Backweb1…
Si l’on regarde les routes qu’elle a :
backweb1# ip route default via 10.100.0.254 dev eth1 onlink 10.99.1.0/24 dev eth0.99 proto kernel scope link src 10.99.1.31 10.100.0.0/24 dev eth1 proto kernel scope link src 10.100.0.31 10.250.1.0/24 dev eth0.250 proto kernel scope link src 10.250.1.31
A – Ping vers Introut
On va tester tout d’abord un ping vers notre passerelle, le routeur interne (sur son ip virtuelle) :
backweb1# ping 10.100.0.254
Ça, c’est OK.
B – Ping vers Proxy
Par contre, un ping vers le proxy :
backweb1# ping 10.20.1.90
ne donne rien. Et rien non plus sur les ips réelles des proxies, 10.20.1.91 et 10.20.1.92.
On va se rendre sur notre proxy1, en root.
Si, pendant le ping depuis backweb1, on lance un tcpdump sur le proxy, on voit les paquets arriver. Et on a l’habitude maintenant, s’ils ne repartent pas, ça sent la route manquante.
En effet, nos proxies ne savent pas adresser le réseau 10.100.0.0/24.
Et on va prendre les devants en faisant en sorte d’adresser non seulement 10.100.0.0/24, mais également 10.100.1.0/24, 10.100.2.0/24, etc… vu qu’ils seront également utilisés par la suite.
Ce sera donc le réseau 10.100.0.0/16 qu’on va router.
Sur proxy1 :
proxy1# ip route add 10.100.0.0/16 via 10.20.1.254
Et on peut restester :
backweb1# ping 10.20.1.90
Histoire de rendre cette route persistante, sur les deux proxies, on va l’ajouter de manière « statique », dans le fichier /etc/network/interfaces :
Sur proxy1 :
auto eth1.20 iface eth1.20 inet static address 10.20.1.91 netmask 255.255.255.0 up ip route add 10.100.0.0/16 via 10.20.1.254
et sur proxy2 :
auto eth1.20 iface eth1.20 inet static address 10.20.1.92 netmask 255.255.255.0 up ip route add 10.100.0.0/16 via 10.20.1.254
Depuis Backweb1, on peut pinger le proxy :
# ping 10.20.1.90
Une étape de plus !
C – Ping vers le routeur externe
Maintenant, un ping vers le routeur externe :
backweb1# ping 10.10.1.254
La encore, rien ne revient.
Sur extrout1, en root :
extrout1# ip route add 10.100.0.0/16 via 10.10.1.90
On reteste :
backweb1# ping 10.10.1.254
Done !
Maintenant, on va ajouter de quoi monter/démonter ces routes de façon automatique.
Sur les deux routeurs externes, extrout1 et extrout2, dans le fichier /srv/keepup.sh, on ajoute la ligne en gras :
#!/bin/bash ip addr add aaa.bbb.ccc.ddd dev eth2 ip link set eth2 up ip route add 62.210.0.1 dev eth2 ip route del default ip route add 0.0.0.0/0 via GW.ONLINE dev eth2 ip route add 10.20.1.0/24 via 10.10.1.90 ip route add 10.100.0.0/16 via 10.10.1.90 echo 1 > /proc/sys/net/ipv4/ip_forward /srv/firewallup.sh sleep 1 ping -c 1 62.210.0.1
Sur extrout1, on ajoute, dans le fichier /srv/keepdown.sh :
#!/bin/bash ip link set eth2 down ip addr del aaa.bbb.ccc.ddd/32 dev eth2 ip route add 0.0.0.0/0 via 10.10.1.2 dev eth1 src 10.10.1.1 ip route del 10.20.1.0/24 via 10.10.1.90 ip route del 10.100.0.0/16 via 10.10.1.90 /srv/firewalldown.sh
et sur extrout2, dans le fichier /srv/keepdown.sh :
#!/bin/bash ip link set eth2 down ip addr del aaa.bbb.ccc.ddd/32 dev eth2 ip route add 0.0.0.0/0 via 10.10.1.1 dev eth1 src 10.10.1.2 ip route del 10.20.1.0/24 via 10.10.1.90 ip route del 10.100.0.0/16 via 10.10.1.90 /srv/firewalldown.sh
And voila !
IV – Ajout du VLAN
Pour notre premier pool, le VLAN 100 a déjà été mis en place dans l’article consacré à la mise en place des routeurs internes. Ce paragraphe est a utiliser lorsqu’on rajoutera un nouveau pool de serveurs par la suite.
Imaginons maintenant, pour l’exemple, que vous venons d’ajouter des serveurs dans un VLAN 109 (dont l’adressage sera chez moi 10.100.9.X)…
Il faut donc ajouter la gestion de ce VLAN à nos deux routeurs internes.
Pour se faire :
A – Configuration réseau
Sur introut1, dans le fichier /etc/network/interfaces, on ajoute ceci à la fin :
auto eth2.109 iface eth2.109 inet static address 10.100.9.5 netmask 255.255.255.0
et sur introut2, dans le fichier /etc/network/interfaces, on ajoute ceci à la fin :
auto eth2.109 iface eth2.109 inet static address 10.100.9.6 netmask 255.255.255.0
On active le réseau, sur les deux routeurs internes :
introutx# ifup eth2.109
B – Configuration Keepalived
Sur introut1, dans le fichier /etc/keepalived/keepalived.conf, on ajoute cela à la fin :
vrrp_instance INTROUT_109 {
state MASTER
preempt 1
interface eth2.109
virtual_router_id 109
priority 200
advert_int 1
authentication {
auth_type PASS
auth_pass password
}
unicast_src_ip 10.100.9.5
unicast_peer {
10.100.9.6
}
virtual_ipaddress {
10.100.9.254
}
}
et sur introut2, dans le fichier /etc/keepalived/keepalived.conf, on ajoute cela à la fin :
vrrp_instance INTROUT_109 {
state BACKUP
interface eth2.109
virtual_router_id 109
priority 50
advert_int 1
authentication {
auth_type PASS
auth_pass password
}
unicast_src_ip 10.100.9.6
unicast_peer {
10.100.9.5
}
virtual_ipaddress {
10.100.9.254
}
}
Sur les deux routeurs internes, on reload :
introutx# servive keepalived reload
Tada ! Notre nouveau Vlan est prêt.
V – Ajout de VLANs pour la communication au sein des pools
Pour certains pools de serveurs, j’aurais besoin d’avoir également des interfaces réseaux indépendantes et dédiées à la communication de VMs au sein d’un même cluster. C’est assez souvent optionnel, mais j’aime bien scinder les flux quand on peut.
On va donc ajouter de nouveaux VLANs dans la gestion KVM-Openvswitch. On les utilisera par exemple pour le pool Sql, le pool Ceph, etc…
De la même manière qu’on avait ajouté la gestion des VLANs dans KVM, on va créer un fichier private.xml avec ce qui suit dedans :
<network> <name>private-vlans</name> <forward mode='bridge'/> <bridge name='brint'/> <virtualport type='openvswitch'/> <portgroup name='vlan50'> <vlan> <tag id='50'/> </vlan> </portgroup> <portgroup name='vlan51'> <vlan> <tag id='51'/> </vlan> </portgroup> <portgroup name='vlan52'> <vlan> <tag id='52'/> </vlan> </portgroup> <portgroup name='vlan53'> <vlan> <tag id='53'/> </vlan> </portgroup> <portgroup name='vlan54'> <vlan> <tag id='54'/> </vlan> </portgroup> <portgroup name='vlan55'> <vlan> <tag id='55'/> </vlan> </portgroup> <portgroup name='vlan56'> <vlan> <tag id='56'/> </vlan> </portgroup> <portgroup name='vlan57'> <vlan> <tag id='57'/> </vlan> </portgroup> <portgroup name='vlan58'> <vlan> <tag id='58'/> </vlan> </portgroup> <portgroup name='vlan59'> <vlan> <tag id='59'/> </vlan> </portgroup> </network>
Création d’une dizaine de nouveaux VLANS, de 50 à 59.
La, on utilisera toujours des adresses en 10.50.0.0/24. En effet, comme chaque VLAN sera indépendant, on peut prendre le même plan d’adressage sans risque.
Et ensuite, on l’injecte dans KVM :
# virsh net-define private.xml # virsh net-start private-vlans # virsh net-autostart private-vlans
Ça, c’est bon, ne reste plus qu’à l’utiliser quand on en aura besoin.
VI – Routage vers les pools depuis les Front
Si on se souvient bien, ce premier pool nous servira pour des serveurs Web, derrière les deux frontaux qu’on à déjà mis en place : Mise en œuvre de frontaux Web Nginx en haute disponibilité avec Keepalived.
Ces deux serveurs doivent pouvoir acceder aux pools via les routeurs internes (Tuto KVM/Openvswitch : Mise en place de routeurs internes)
Il faut donc ajouter un peu de routage, en l’occurrence le réseau 10.100.0.0/16 (voir III-B)
Sur les deux frontweb, 1 et 2:
frontwebX# ip route add 10.100.0.0/16 via 10.20.1.254
Histoire de rendre cette route persistante, sur les deux frontaux, on va l’ajouter de manière « statique », dans le fichier /etc/network/interfaces :
Sur frontweb1 :
auto eth1.20 iface eth1.20 inet static address 10.20.1.11 netmask 255.255.255.0 up ip route add 10.100.0.0/16 via 10.20.1.254
et sur frontweb2 :
auto eth1.20 iface eth1.20 inet static address 10.20.1.12 netmask 255.255.255.0 up ip route add 10.100.0.0/16 via 10.20.1.254
Tout est ok ? On peut donc revenir à notre feuille de route.
