par Petit article rapide sur deux modifications que j’ai apporté au niveau de la gestion de mes VLANS et de mon réseau au sein de mon infrastructure Xen, Openvswitch.
Rien de bien compliqué, mais comme je vais m’en servir dans les articles à venir, autant vous le présenter.
I – Rappel
Pour rappel, jusqu’à présent, au niveau Vlans et réseaux, j’ai ceci :
- Vlan 10, Réseau 10.10.1.0/24 -> Communication entre le routeur et les VMS (dans les deux sens).
- Vlan 20, Réseau 10.20.1.0/24 > Communication entre les VMS.
- Vlan 99, Réseau 10.99.1.0/24 -> Dédié au communications entre le Xen et les Domus.
Ces trois Vlans sont associés à des fakes-bridges dans Openvswitch.
Pour les exemples à suivre, je pars sur un cluster MariaDB :
- Maria1: 10.10.1.151, 10.20.1.151 et 10.99.1.151
- Maria2 : … 152
- Maria3 : … 153
- Un HAPROXY en amont et redondant : .155 et .156
- Une VIP 10.20.1.150, déclarée sur les des deux proxys (un seul bien sur en a la charge à un moment t). Cette VIP sert de point d’entrée pour le SQL
Alors oui, j’intègre le point d’entrée Haproxy qui, techniquement ne fait pas partie du cluster à proprement parlé, vous me pardonnerez ce « raccourci ».
II – De nouveaux VLANS
En ce moment, c’est redondance à tous les étages… La haute dispo et autres joyeusetés, je ne vous cache pas que vous allez en prendre pour quelques articles…
J’en profite donc pour revoir mon architecture réseau et me dit qu’il ne serait pas idiot de rajouter des Vlans. Bah oui, ce n’est pas assez le bazar, pourquoi ne pas en rajouter ?
A dire vrai, je ne vais pas les rajouter juste pour le « fun » comme disaient les jeunes de mon époque (qui du coup, sont vieux…), mais j’ai bien une idée derrière la tête.
Avoir un Vlan dédié par grappe de serveur. Pourquoi ? Parce que je souhaite que les communications au sein d’un cluster (par ex MARIADB) soient sur un Vlan à part et sur une plage 10.30.1.0/24.
Le but, mieux isoler mes services. Je veux que les requêtes SQL venant des VMs externes au cluster ne puissent être traitées que par HAPROXY, qui lui a le droit de contacter les serveurs SQL. En gros, une Vm autre doit demander le service SQL exclusivement via le point d’entrée.
Pardon ? Oui ! C’est tout à fait faisable à coup d’Iptables un peu partout, puis faut bien refléchir aux -s, -d, etc.. et on peut faire bien plus simple.
La, en ajoutant à chaque membre du « cluster réseau », une patte sur le Vlan qui va bien, on assure déjà cette isolation sans rien faire, ou presque…
Une machine 10.20.1.199 qui demanderait le SQL à 10.20.1.151 n’aura rien. Il faut demander le SQL à 10.20.1.150. Bon, elle peut toujours demander à 10.20.1.155 et 10.20.1.156 si on ne change rien, mais cela n’est guere problematique, ceux ci restent bien nos points d’entrées.
Bien évidement , il faut penser aux binds corrects des serveurs en question car si c’est pour écouter comme un sagouin sur 0.0.0.0, ça ne sert à pas grand chose…
Du coup, ce VLAN sera tagué 30 ?
Et bien non… Pourquoi ?
Pour chaque cluster et histoire de rester « simple », la logique sera toujours la même : la communication inter cluster sera toujours sur le réseau 10.30.1.0/24.
Mais en même temps, je ne veux pas qu’un SQL contacte un LDAP à travers cette plage commune. D’où l’idée des VLans. On aura toujours le même range IP mais dans différents Vlans, donc isolés.
Et histoire de me retrouver dans les numéros, comme mon cluster SQL est sur la série des IPs en 10.X.1.15X, j’ai choisi le VLAN 150, tout simplement.
Pour un cluster en 10.X.1.24X, je prendrais donc le VLAN240, mais toujours avec le réseau 10.30 pour la communication entre les membres.
Pour la création du fake-bridge :
xen# ovs-vsctl add-br vlansql brint 150
Donc voila, loin d’être indispensable et au final, ce n’est que du VLAN, mais vous comprendrez pourquoi dans mes tutos, ça risque de devenir le bazar niveau réseau.
III – Vlans et domus
Autre modification que j’ai apporté, très simple.
Au niveau des DomUs, jusque la, j’utilisais un « lien virtuel » par vlan et associais donc une interface, etc…
A – Avant
Coté Xen, la configuration du réseau de la VM Maria1 ressemblait à cela :
vir=['vifname=maria1.0,ip=10.10.1.151 ,mac=00:16:3E:A1:51:10,bridge=brint.10',
'vifname=maria1.1,ip=10.20.1.151 ,mac=00:16:3E:A1:51:20,bridge=brint.20',
'vifname=maria1.2,ip=10.99.1.151 ,mac=00:16:3E:A1:51:99,bridge=brint.99',
'vifname=maria1.3,ip=10.30.1.151 ,mac=00:16:3E:A1:51:30,bridge=brint.130']
Et le fichier d’interfaces, coté Domu :
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.10.1.151 netmask 255.255.255.0 gateway 10.10.1.2 auto eth1 iface eth1 inet static address 10.20.1.151 netmask 255.255.255.0 auto eth2 iface eth2 inet static address 10.99.1.151 netmask 255.255.255.0 auto eth3 iface eth3 inet static address 10.30.1.151 netmask 255.255.255.0
B – Après
Maintenant, je simplifie en utilisant les ports en mode « trunk » (non, rien à voir…) à savoir la possibilité de véhiculer plusieurs Vlans au sein d’un port du Switch.
Rien de sorcier, côté Xen, on va avoir quelque chose de la sorte :
vir=['vifname=maria1.0,mac=00:16:3E:A1:51:10,bridge=brint:10:20:150',
'vifname=maria1.1,mac=00:16:3E:A1:51:20,bridge=brint.99']
Au passage, je garde juste une interface indépendante pour mon reseau Xen-Domu.
Coté fichier interface :
auto lo iface lo inet loopback auto eth0.10 iface eth0.10 inet static address 10.10.1.151 netmask 255.255.255.0 gateway 10.10.1.2 auto eth0.20 iface eth0.20 inet static address 10.20.1.151 netmask 255.255.255.0 auto eth0.150 iface eth0.150 inet static address 10.30.1.151 netmask 255.255.255.0 auto eth1 iface eth1 inet static address 10.99.1.151 netmask 255.255.255.0
Voila voila…
Ce qui fait que le principe de « fake-bridge » dont je parle plus haut n’est plus vraiment obligatoire.
Toujours l’exemple avec le cluster MariaDB:
Avant, chaque port était bien sur le switch correspondant, par exemple le vlansql avait les ports de chaque MariaDB et des Haproxys :
xen# ovs-vsctl list-ports vlansql [...] maria1.3 maria2.3 maria3.3 hamaria1.3 hamaria2.3 [...]
Et ainsi de suite pour chaque Vlan.
Maintenant, les ports trunk sont branchés sur le brint directement.
xen# ovs-vsctl list-ports brint [...] maria1.0 maria2.0 maria3.0 hamaria1.0 hamaria2.0 [...]
Les ports xxx.1 (pour le vlan99), eux, restent bien sur le switch vlan99.
Mais ces fakes-bridges, au final, je les conserve car la mise en place d’un port interne directement connecté permet au Dom0 de se connecter au Vlan et j’aime garder la possibilité que le Dom0 est tout les possibilités (certains checks, etc…)
III – Conclusion
Bon, on est d’accord, ce n’est pas un article qui sera à l’origine d’une grande révolution, mais ainsi, mes clusters sont un peu mieux cloisonnés et j’aime à imaginer que les câbles virtuels sont moins nombreux 😉
On va attaquer les choses sérieuses bientôt…
