Routage h7 » Historique » Version 4
Version 3 (Élie Bouttier, 11/03/2018 16:01) → Version 4/5 (Élie Bouttier, 11/03/2018 16:27)
h1. Routage h7
L’allocation d’une IP dans djadhere provoque le routage de cette dernière sur h7.
Pour cela, un cron sur h7 s’occupe toute les minutes de répercuter les modifications effectuées sur djadhere.
Les scripts s’occupant du routage se trouvent dans le dossier @h7:/root/routing@.
h2. CRON
Le cron est installé via @/etc/cron.d/routing@.
Il lance le script @/root/routing/update-ip-ttnn@.
Ce script télécharge depuis djadhere la dernière version de @ip_ttnn.txt@ avec curl (et s’arrête là en cas d’erreur de curl).
Un git diff est effectué sur le fichier ip_ttnn.txt afin de tester s’il a été modifié.
Si c’est le cas, il est commité localement et le script @check-routing ip_ttnn.txt@ est lancé.
h2. Le script de routage
<pre>
root@h7:~/routing# ./check-routing --help
usage: check-routing [-h] [--quiet] [--fix] [--force] db
positional arguments:
db the ip_ttnn.txt file
optional arguments:
-h, --help show this help message and exit
--quiet do not print executed commands
--fix run ip commands needed to fix the routing ; if absent, they are
printed but not executed
--force by-pass mad guard (more than 10 commands, change cluster's IPs
route)
</pre>
Le script de routage lis le fichier @ip_ttnn.txt@ passé en argument et vérifie pour toutes les IPs que les routes associées, IPv4 et IPv6, sont correctes.
Les routes @custom@ (géré à la main) et @openstack@ (géré par bird) ne sont pas vérifié.
Les IPs connues comme appartenant à h7, définie dans @IP_LOCALS@, sont ignorées ; un message d’erreur est affiché si leur route n’est ni @custom@, ni @reserved@.
La vérification parse le résultat d’@ip route get@ et, si nécessaire, ajoute les actions nécessaires à la liste @CMDS@ :
* @ip route add@ si la route est manquante
* @ip route delete@ si elle ne devrait pas être présente
* @ip route delete@ puis @ip route add@ si elle est incorrecte.
Si l’IP est actuellement routé sur le vlan openstack (@eth3.3132@), l’action se voit ajouter un attribut « need --force ».
S’il y a plus de 10 actions nécessaires, le script refuse de continuer sans l’option @--force@.
Finalement, pour chaque action, celle-ci est affiché.
Si le script est lancé avec @--fix@, la commande est lancé (sauf si @--force@ est également nécessaire mais absent des aguments du script).
h2. Et au démarrage ?
Le script @/root/ip_ttnn.sh@, lancé par @/etc/rc.local@ s’en occupe.
L’allocation d’une IP dans djadhere provoque le routage de cette dernière sur h7.
Pour cela, un cron sur h7 s’occupe toute les minutes de répercuter les modifications effectuées sur djadhere.
Les scripts s’occupant du routage se trouvent dans le dossier @h7:/root/routing@.
h2. CRON
Le cron est installé via @/etc/cron.d/routing@.
Il lance le script @/root/routing/update-ip-ttnn@.
Ce script télécharge depuis djadhere la dernière version de @ip_ttnn.txt@ avec curl (et s’arrête là en cas d’erreur de curl).
Un git diff est effectué sur le fichier ip_ttnn.txt afin de tester s’il a été modifié.
Si c’est le cas, il est commité localement et le script @check-routing ip_ttnn.txt@ est lancé.
h2. Le script de routage
<pre>
root@h7:~/routing# ./check-routing --help
usage: check-routing [-h] [--quiet] [--fix] [--force] db
positional arguments:
db the ip_ttnn.txt file
optional arguments:
-h, --help show this help message and exit
--quiet do not print executed commands
--fix run ip commands needed to fix the routing ; if absent, they are
printed but not executed
--force by-pass mad guard (more than 10 commands, change cluster's IPs
route)
</pre>
Le script de routage lis le fichier @ip_ttnn.txt@ passé en argument et vérifie pour toutes les IPs que les routes associées, IPv4 et IPv6, sont correctes.
Les routes @custom@ (géré à la main) et @openstack@ (géré par bird) ne sont pas vérifié.
Les IPs connues comme appartenant à h7, définie dans @IP_LOCALS@, sont ignorées ; un message d’erreur est affiché si leur route n’est ni @custom@, ni @reserved@.
La vérification parse le résultat d’@ip route get@ et, si nécessaire, ajoute les actions nécessaires à la liste @CMDS@ :
* @ip route add@ si la route est manquante
* @ip route delete@ si elle ne devrait pas être présente
* @ip route delete@ puis @ip route add@ si elle est incorrecte.
Si l’IP est actuellement routé sur le vlan openstack (@eth3.3132@), l’action se voit ajouter un attribut « need --force ».
S’il y a plus de 10 actions nécessaires, le script refuse de continuer sans l’option @--force@.
Finalement, pour chaque action, celle-ci est affiché.
Si le script est lancé avec @--fix@, la commande est lancé (sauf si @--force@ est également nécessaire mais absent des aguments du script).
h2. Et au démarrage ?
Le script @/root/ip_ttnn.sh@, lancé par @/etc/rc.local@ s’en occupe.