6 octobre 2022

Création d’un pool de serveurs

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 pret.

 

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.

 

Tout est ok ? On peut donc revenir à notre feuille de route.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *