DevStack, IPv6 et Scaleway sont sur un bateau...

Cette année, j’ai récupéré un nouveau cours de Technologies Cloud auprès d’ingénieurs de troisième année à l’INP Clermont-Auvergne. Désireux de leur fournir des TPs fun et où on peut réellement pousser le concept de Cloud Computing au maximum, je me suis lancé dans le projet un peu fou de déployer un OpenStack avec DevStack, le tout en IPv6 natif. Retour sur 4 semaines d’arrachage de cheveux, 4 semaines de nuits blanches, mais pour un résultat qui vaut le détour 😊.

Par où on commence ?

La première question qu’on se pose lorsqu’on attaque un tel projet, c’est bien entendu sa faisabilité : ma dernière tentative avec DevStack remonte à 2020 (et ça n’avait pas été la plus grande des réussites), et je n’ai jamais mis les pieds dans l’univers IPv6. Deux énormes inconnues donc, couplée à une troisième question existentielle : quelle infrastructure pour accueillir mon OpenStack ? Pour y répondre, la première question qu’il faut se poser, ce sont les besoins en terme d’infra. Comme nous parlons de travaux pratiques sur une durée limitée, nous n’avons bien entendu pas les mêmes contraintes qu’une entreprise qui voudrait opérer son infra 24/7, et supporter les mises à jour en zéro-downtime : dans notre cas, tant pis pour les mises à jour, ça attendra l’an prochain.

Prenant en compte que j’aurai environ 44 élèves sur cette infrastructure, répartis dans des groupes de 17 élèves maximum, qui vont lancer au maximum 2 instances en simultané chacun, il me faudrait :

N’ayant aucune envie de dépenser un bon millier d’euros pour acheter une lame 2U qui me servirait trois mois par an, avec en supplément les contraintes d’adduction électrique et réseau à gérer, je me suis vite reporté sur la location de serveurs dédiés. Et pour cela, la France fait partie des grands champions, avec notamment OVHCloud et Scaleway.

Malheureusement, mon choix va vite se limiter : OVHCloud ne propose qu’une seule IPv6 SLAAC sur ses offres Kimsufi. Compte-tenu de mon budget contraint, la solution s’éteint donc rapidement. Je jette également un œil du côté de Hetzner, qui propose des tarifs très intéressants. Cependant, je me laisse convaincre par Online/Scaleway, étant donné que je suis déjà familier avec leur service.

Tester c’est douter (mais on doute, donc on teste)

Afin de tester en conditions réelles sans me ruiner, je commande un serveur Elastic Metal, d’entrée de gamme, le EM-A115X-SSD. Le serveur propose un CPU 4 cœurs (Xeon E3 1220), 32 Go de RAM, et 2To de SSD, pour 33€ par mois. Ayant très peur que le CPU souffre très fort avec 34 instances allumées, je conviens d’entrée de jeu que ce serveur ne me servira que de lab, étant donné que les Elastic Metal se payent à l’heure : 0.091€ de l’heure dans notre cas.

Ce serveur va me permettre d’expérimenter mon déploiement de DevStack avec un bloc d’IPv6 routable. La documentation de DevStack étant très mal faite, et la documentation de Scaleway sur IPv6 n’étant pas franchement mieux, je galère pendant plus de deux semaines à réussir à faire fonctionner mon préfixe IPv6 (ou, tout du moins, à le faire utiliser par OpenStack). Je vous passerai les détails, mais j’ai tout eu : du réseau entrant mais pas sortant, du réseau sortant mais pas entrant, pas de réseau du tout (ça c’était la majorité du temps…), et j’ai failli baisser les bras et abandonner à plusieurs reprises.

Cependant, l’acharnement paie, et grâce à l’aide de Justine et Louis (merci ❤️), j’arrive finalement à démarrer un DevStack fonctionnel, avec une délégation IPv6 fonctionnelle. Deux jours après, j’arrive à reproduire le déploiement from scratch sans mauvaise surprise : ça fonctionne, je peux enfin passer sur une “vraie” infra !

Avant de passer à la suite, voici la configuration qui a fonctionné chez moi, sur la version 2025.1 (dev) d’OpenStack, déployé depuis la branche principale de Devstack :

net.ipv6.conf.all.forwarding=1
net.ipv6.conf.eno1.autoconf=0
net.ipv6.conf.eno1.accept_ra=2

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      critical: true
      dhcp-identifier: mac
      dhcp4: true
      dhcp6: true
      accept-ra: false
      addresses:
        - "IPV6_PUBLIC_BLOC"
      routes:
        - to: "::/0"
          via: "GATEWAY_V6"
          on-link: true
      nameservers:
        addresses:
          - 8.8.8.8
          - 51.159.47.28
          - 51.159.47.26

[[local|localrc]]
# Change these values
HOST_IP=VOTRE_IPV4_ICI
ADMIN_PASSWORD=VOTRE_MOT_DE_PASSE_ADMIN
IPV6_ADDRS_SAFE_TO_USE="IPV6_LOCAL_BLOC_STARTING_WITH_FE80"
IPV6_PRIVATE_NETWORK_GATEWAY="GATEWAY_V6"
IPV6_PUBLIC_RANGE="IPV6_PUBLIC_BLOC"
IPV6_PUBLIC_NETWORK_GATEWAY="IPV6_PUBLIC_GATEWAY (Will be the public bloc without the /56 part)"
HOST_IPV6="HOST_IPV6"

# Don't touch this
SERVICE_HOST=$HOST_IP
MYSQL_HOST=$HOST_IP
RABBIT_HOST=$HOST_IP
GLANCE_HOSTPORT=$HOST_IP:9292
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
Q_USE_SECGROUP=True
IP_VERSION=6
PUBLIC_INTERFACE=eno1
IPV6_RA_MODE=slaac
IPV6_ADDRESS_MODE=slaac
Q_USE_PROVIDERNET_FOR_PUBLIC=True
OVS_PHYSICAL_BRIDGE=br-ex
PUBLIC_BRIDGE=br-ex
OVS_BRIDGE_MAPPINGS=public:br-ex
TEMPEST_INSTALL=False
INSTALL_TEMPEST=False

On passe sur du dédié au mois

Maintenant que nous avons un laboratoire fonctionnel, il est temps de déployer à plus grande échelle. Comme le serveur Elastic Metal que nous avons est limité en termes de CPU, nous allons changer de modèle, et de gamme : en effet, la gamme Elastic de Scaleway est coûteuse, et, comme dit plus tôt, je n’ai pas beaucoup d’argent à disposition pour ce projet.

Scaleway propose sa gamme Dedibox, de serveurs dédiés payés au mois, et à des tarifs très inférieurs à ceux de son Elastic Metal. Étant un utilisateur régulier de ce service que je sais fiable, je me décide à passer dessus. Je jette mon dévolu sur deux dédiés START-2-M-SATA, qui offrent 8 CPU, 16Go de RAM et 1To de HDD chacun, soit une infra de 16 CPU, 32Go de RAM et 2To de HDD. Je paye le premier mois (et les frais d’installation, toujours un plaisir), et je commence l’installation des deux Openstack… Et là, c’est le drame.

IPv6 prefix delegation DUID

En effet, l’infrastructure des Dedibox est légèrement différente des Elastic Metal sur la partie IPv6 : sur les Elastic Metal, la configuration de l’affectation de vos blocs IPv6 se fait directement en interface graphique : vous définissez que tel bloc en /64 est attaché à votre serveur elastic, et Scaleway s’occupe de faire l’affectation du bloc de son côté. Du côté Dedibox par contre, Scaleway vous met à disposition des blocs, et c’est à votre serveur (via dhclient par exemple) de récupérer la gestion du bloc, en s’authentifiant au préalable. Bon bah, c’est reparti pour bidouiller du réseau.

Bien entendu, il ne faut pas trop compter sur la documentation : elle est, au mieux, très ancienne, au pire, inexistante. Heureusement, je vais tomber sur ce post de kgersen sur lafibre.info ( un ÉNORME merci à toi !) qui évoque le besoin d’aller bidouiller dhclient pour rajouter un bout de configuration : en effet, Netplan ne supporte pas d’ajouter un DUID sur une configuration IPv6.

interface "eno1" {
  send dhcp6.client-id FULL_DUID;
}

interface "br-ex" {
  send dhcp6.client-id FULL_DUID;
}

[Service]
Type=forking
Restart=always
RestartSec=2s
TimeoutSec=10s
ExecStart=/sbin/dhclient -1 -v -pf /run/dhclient6.pid -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.leases -6 -P eno1
ExecStartPost=/sbin/ip -6 addr add V6_PREFIX dev br-ex
ExecStop=/sbin/dhclient -r -v -pf /run/dhclient6.pid -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.leases -6 eno1
PIDFile=/run/dhclient6.pid

[Install]
WantedBy=multi-user.target network-online.target

Comme nous voulons qu’OpenStack s’occupe de gérer IPv6 comme un grand, nous demandons à dhclient6 d’enregistrer les leases IPv6 pour l’interface br-ex, qui nous sert de bridge entre OpenStack et le réseau physique. Il faut donc déployer OpenStack avant de démarrer notre nouveau service.

Maintenant que nous avons toute la configuration qui va bien, il est temps de se jeter à l’eau, avec un ./stack.sh. L’installation va durer environ 40 minutes, et nous aboutissons à un OpenStack qui est configuré proprement. Nous pouvons désormais démarrer dhclient6, avec un petit systemctl enable dhclient6 ; systemctl start dhclient6 .

Tentez de créer une instance raccordée au réseau public, ouvrez l’ICMP et 22/tcp depuis ::/0, et si tout s’est bien passé, vous devriez pouvoir accéder à votre instance ! 🎉 Si ce n’est pas le cas, ça peut valoir le coup de relancer un netplan apply suivi d’un systemctl restart dhclient6 : l’annonce est parfois capricieuse.

T’es sûr, pour les HDD ?

Le premier TP commence et… tout se vautre en l’espace de dix minutes. Les deux OpenStack commencent à ramer sévère dès la première instance, et l’ensemble de l’infra s’effondre. Le problème venait en réalité de deux origines différentes :

Avec ces petites modifications (et deux nuits à réinstaller l’infra sous SSD), nous avons nos deux OpenStack fonctionnels, et les étudiants ont pu mener à bien leurs TPs 🎉.

Au secours, tout fonctionnait et d’un coup ça pète !

L’annonce des IPv6 SLAAC est… souffrante, dirons-nous, chez Scaleway. Et sans votre IPv6 SLAAC, impossible d’obtenir des leases DHCPv6 (ne me demandez pas pourquoi, je n’en ai aucune idée).

Si vous perdez soudainement vos IPv6, ou que des outils comme KeyCDN renvoient des résultats mitigés (des pings qui passent dans certaines régions, mais pas ailleurs), vérifiez votre configuration : ip -6 a. Si vous ne voyez plus votre IPv6 SLAAC, recréez-la (l’adresse est disponible sur votre console Online):

ip -6 addr add VOTRE_V6_SLAAC/64 dev eno1 mngtmpaddr noprefixroute

Si cela ne résout pas le problème, vous pouvez également tenter de modifier la route par défaut :

ip -6 route del default
ip -6 route add default via fe80::a293:51ff:feb7:5b1d dev br-ex metric 1024 pref medium

Pour conclure

Bien entendu, tout est loin d’être parfait, à commencer par le déploiement, que je n’ai pas encore automatisé (je prévois d’en faire un playbook Ansible). Également à noter, les deux OpenStack ont une vie qui leur est propre, chacun de leur côté. J’ai vu que Devstack permettait de créer des clusters d’OpenSack “all-in-one”, c’est définitivement un sujet pour l’année prochaine, pour simplifier l’usage auprès des étudiants et mieux répartir la charge (actuellement, j’ai splitté les élèves avec des droits spécifiques par OpenStack).

IPv6 m’en a fait voir de toutes les couleurs, et j’ai dû commander une petite machine en plus (à 3€ par mois) pour permettre aux étudiants d’avoir un rebond SSH, puisque le réseau de l’université ne propose toujours pas de sortir proprement en IPv6 😮‍💨.

À noter également mon erreur, qui m’aura coûté un peu plus de 60€ pour des serveurs que je ne vais pas utiliser. Les tests sur Elastic Metal m’auront coûté un peu moins de 10€, et maintenir l’infrastructure chaque mois me coûte environ 35€, sans compter les 35€ de frais d’installation. Étant donné que les TPs se terminent début décembre et que je compte couper les accès au 01/01/2025, on peut estimer le coût total à :

Soit 219.99€ d’infrastructure, pour trois mois de travaux pratiques. La somme peut paraître importante, mais en réalité, vu le besoin et la puissance obtenue pour si peu, c’est, en vérité, une somme très faible ! Nous avons tout de même à la clef deux infrastructures as a service, disponibles 24/7 pour que les étudiants avancent les TPs chez eux, le tout sans se préoccuper du hardware le reste du temps. Sans ma boulette, le coût aurait été d’autant plus faible, ce qui signifie que, pour les prochaines années, je pourrai m’en sortir pour 149.99€ (et peut-être même moins si la fac met enfin de l’IPv6… 👀).

Le tout, sur des fournisseurs Français, ce qui me tient à cœur. Comme quoi, quand on veut faire, on peut faire 😉.