Les solutions RAID classiques gaspillent de l’espace lorsque les disques sont de tailles différentes. Le RAID logiciel Linux avec LVM exploite la capacité totale de chaque disque et permet d’étendre le stockage en remplaçant un ou deux disques à la fois¹.

Nous partons de quatre disques de taille identique :

$ lsblk -Mo NAME,TYPE,SIZE
NAME TYPE  SIZE
vda  disk  101M
vdb  disk  101M
vdc  disk  101M
vdd  disk  101M

Nous créons une partition sur chacun d’eux :

$ sgdisk --zap-all --new=0:0:0 -t 0:fd00 /dev/vda
$ sgdisk --zap-all --new=0:0:0 -t 0:fd00 /dev/vdb
$ sgdisk --zap-all --new=0:0:0 -t 0:fd00 /dev/vdc
$ sgdisk --zap-all --new=0:0:0 -t 0:fd00 /dev/vdd
$ lsblk -Mo NAME,TYPE,SIZE
NAME   TYPE  SIZE
vda    disk  101M
└─vda1 part  100M
vdb    disk  101M
└─vdb1 part  100M
vdc    disk  101M
└─vdc1 part  100M
vdd    disk  101M
└─vdd1 part  100M

Nous assemblons les quatre partitions pour former un volume RAID 5² :

$ mdadm --create /dev/md0 --level=raid5 --bitmap=internal --raid-devices=4 \
>   /dev/vda1 /dev/vdb1 /dev/vdc1 /dev/vdd1
$ lsblk -Mo NAME,TYPE,SIZE
    NAME          TYPE    SIZE
    vda           disk    101M
┌┈▶ └─vda1        part    100M
┆   vdb           disk    101M
├┈▶ └─vdb1        part    100M
┆   vdc           disk    101M
├┈▶ └─vdc1        part    100M
┆   vdd           disk    101M
└┬▶ └─vdd1        part    100M
 └┈┈md0           raid5 292.5M
$ cat /proc/mdstat
md0 : active raid5 vdd1[4] vdc1[2] vdb1[1] vda1[0]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Nous utilisons LVM pour créer des volumes logiques au-dessus du volume RAID.

$ pvcreate /dev/md0
  Physical volume "/dev/md0" successfully created.
$ vgcreate data /dev/md0
  Volume group "data" successfully created
$ lvcreate -L 100m -n bits data
  Logical volume "bits" created.
$ lvcreate -L 100m -n pieces data
  Logical volume "pieces" created.
$ mkfs.ext4 -q /dev/data/bits
$ mkfs.ext4 -q /dev/data/pieces
$ lsblk -Mo NAME,TYPE,SIZE
    NAME          TYPE    SIZE
    vda           disk    101M
┌┈▶ └─vda1        part    100M
┆   vdb           disk    101M
├┈▶ └─vdb1        part    100M
┆   vdc           disk    101M
├┈▶ └─vdc1        part    100M
┆   vdd           disk    101M
└┬▶ └─vdd1        part    100M
 └┈┈md0           raid5 292.5M
    ├─data-bits   lvm     100M
    └─data-pieces lvm     100M
$ vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  data   1   2   0 wz--n- 288.00m 88.00m

Nous obtenons la configuration suivante :

Nous remplaçons /dev/vda par un disque plus grand. Nous le réintégrons dans la grappe RAID 5 après avoir copié les partitions de /dev/vdb :

$ cat /proc/mdstat
md0 : active (auto-read-only) raid5 vdb1[1] vdd1[4] vdc1[2]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [_UUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ sgdisk --replicate=/dev/vda /dev/vdb
$ sgdisk --randomize-guids /dev/vda
$ mdadm --manage /dev/md0 --add /dev/vda1
$ cat /proc/mdstat
md0 : active raid5 vda1[5] vdb1[1] vdd1[4] vdc1[2]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Nous n’utilisons pas la capacité supplémentaire : cette configuration ne survivrerait pas à la perte de /dev/vda car nous ne disposons d’aucune capacité de réserve. Nous devons remplacer un second disque, tel que /dev/vdb :

$ cat /proc/mdstat
md0 : active (auto-read-only) raid5 vda1[5] vdd1[4] vdc1[2]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [U_UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ sgdisk --replicate=/dev/vdb /dev/vdc
$ sgdisk --randomize-guids /dev/vdb
$ mdadm --manage /dev/md0 --add /dev/vdb1
$ cat /proc/mdstat
md0 : active raid5 vdb1[6] vda1[5] vdd1[4] vdc1[2]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Nous créons un nouveau volume RAID 1 en utilisant l’espace libre sur /dev/vda et /dev/vdb :

$ sgdisk --new=0:0:0 -t 0:fd00 /dev/vda
$ sgdisk --new=0:0:0 -t 0:fd00 /dev/vdb
$ mdadm --create /dev/md1 --level=raid1 --bitmap=internal --raid-devices=2 \
>   /dev/vda2 /dev/vdb2
$ cat /proc/mdstat
md1 : active raid1 vdb2[1] vda2[0]
      101312 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md0 : active raid5 vdb1[6] vda1[5] vdd1[4] vdc1[2]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Nous ajoutons /dev/md1 au groupe de volumes :

$ pvcreate /dev/md1
  Physical volume "/dev/md1" successfully created.
$ vgextend data /dev/md1
  Volume group "data" successfully extended
$ vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  data   2   2   0 wz--n- 384.00m 184.00m
$  lsblk -Mo NAME,TYPE,SIZE
       NAME          TYPE    SIZE
       vda           disk    201M
   ┌┈▶ ├─vda1        part    100M
┌┈▶┆   └─vda2        part    100M
┆  ┆   vdb           disk    201M
┆  ├┈▶ ├─vdb1        part    100M
└┬▶┆   └─vdb2        part    100M
 └┈┆┈┈┈md1           raid1  98.9M
   ┆   vdc           disk    101M
   ├┈▶ └─vdc1        part    100M
   ┆   vdd           disk    101M
   └┬▶ └─vdd1        part    100M
    └┈┈md0           raid5 292.5M
       ├─data-bits   lvm     100M
       └─data-pieces lvm     100M

Nous obtenons la configuration suivante³ :

Étendons encore notre capacité en remplaçant /dev/vdc :

$ cat /proc/mdstat
md1 : active (auto-read-only) raid1 vda2[0] vdb2[1]
      101312 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md0 : active (auto-read-only) raid5 vda1[5] vdd1[4] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UU_U]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ sgdisk --replicate=/dev/vdc /dev/vdb
$ sgdisk --randomize-guids /dev/vdc
$ mdadm --manage /dev/md0 --add /dev/vdc1
$ cat /proc/mdstat
md1 : active (auto-read-only) raid1 vda2[0] vdb2[1]
      101312 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md0 : active raid5 vdc1[7] vda1[5] vdd1[4] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Convertissons /dev/md1 d’un RAID 1 vers un RAID 5 :

$ mdadm --grow /dev/md1 --level=5 --raid-devices=3 --add /dev/vdc2
mdadm: level of /dev/md1 changed to raid5
mdadm: added /dev/vdc2
$ cat /proc/mdstat
md1 : active raid5 vdc2[2] vda2[0] vdb2[1]
      202624 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md0 : active raid5 vdc1[7] vda1[5] vdd1[4] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ pvresize /dev/md1
$ vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  data   2   2   0 wz--n- 482.00m 282.00m

Nous obtenons la disposition suivante :

Nous étendons encore davantage notre capacité en remplaçant /dev/vdd :

$ cat /proc/mdstat
md0 : active (auto-read-only) raid5 vda1[5] vdc1[7] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active (auto-read-only) raid5 vda2[0] vdc2[2] vdb2[1]
      202624 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ sgdisk --replicate=/dev/vdd /dev/vdc
$ sgdisk --randomize-guids /dev/vdd
$ mdadm --manage /dev/md0 --add /dev/vdd1
$ cat /proc/mdstat
md0 : active raid5 vdd1[4] vda1[5] vdc1[7] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active (auto-read-only) raid5 vda2[0] vdc2[2] vdb2[1]
      202624 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Agrandissons le second volume RAID 5 :

$ mdadm --grow /dev/md1 --raid-devices=4 --add /dev/vdd2
mdadm: added /dev/vdd2
$ cat /proc/mdstat
md0 : active raid5 vdd1[4] vda1[5] vdc1[7] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid5 vdd2[3] vda2[0] vdc2[2] vdb2[1]
      303936 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ pvresize /dev/md1
$ vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  data   2   2   0 wz--n- 580.00m 380.00m
$ lsblk -Mo NAME,TYPE,SIZE
       NAME          TYPE    SIZE
       vda           disk    201M
   ┌┈▶ ├─vda1        part    100M
┌┈▶┆   └─vda2        part    100M
┆  ┆   vdb           disk    201M
┆  ├┈▶ ├─vdb1        part    100M
├┈▶┆   └─vdb2        part    100M
┆  ┆   vdc           disk    201M
┆  ├┈▶ ├─vdc1        part    100M
├┈▶┆   └─vdc2        part    100M
┆  ┆   vdd           disk    301M
┆  └┬▶ ├─vdd1        part    100M
└┬▶ ┆  └─vdd2        part    100M
 ┆  └┈┈md0           raid5 292.5M
 ┆     ├─data-bits   lvm     100M
 ┆     └─data-pieces lvm     100M
 └┈┈┈┈┈md1           raid5 296.8M

Ce processus peut se poursuivre indéfiniment en remplaçant chaque disque un par un en s’appuyant sur les mêmes étapes. ♾️

Akvorado collecte des flux sFlow et IPFIX via UDP. Comme UDP ne retransmet pas les paquets perdus, il faut les traiter rapidement. Akvorado exécute plusieurs routines écoutant sur le même port. Le noyau devrait répartir équitablement les paquets reçus entre ces routines. Cependant, cela ne fonctionne pas comme prévu. Quelques routines présentent une perte de paquets importante :

$ curl -s 127.0.0.1:8080/api/v0/inlet/metrics \
> | sed -n s/akvorado_inlet_flow_input_udp_in_dropped//p
packets_total{listener="0.0.0.0:2055",worker="0"} 0
packets_total{listener="0.0.0.0:2055",worker="1"} 0
packets_total{listener="0.0.0.0:2055",worker="2"} 0
packets_total{listener="0.0.0.0:2055",worker="3"} 1.614933572278264e+15
packets_total{listener="0.0.0.0:2055",worker="4"} 0
packets_total{listener="0.0.0.0:2055",worker="5"} 0
packets_total{listener="0.0.0.0:2055",worker="6"} 9.59964121598348e+14
packets_total{listener="0.0.0.0:2055",worker="7"} 0

eBPF peut aider en implémentant un algorithme de répartition alternatif. 🐝

Options pour la répartition de charge

Il existe trois méthodes pour répartir les paquets UDP entre des routines :

1. Une routine reçoit les paquets et les distribue aux autres routines.
2. Toutes les routines partagent la même chaussette.
3. Chaque routine a sa propre chaussette, liée au même port, avec l’option SO_REUSEPORT.

Option SO_REUSEPORT

Tom Hebert a ajouté l’option SO_REUSEPORT dans Linux 3.9. La présentation de sa série de patchs explique pourquoi cette nouvelle option est meilleure que les deux existantes du point de vue des performances :

SO_REUSEPORT permet à plusieurs chaussettes d’être liées au même port. […] Les paquets reçus sont distribués aux multiples chaussettes liées au même port en utilisant un hachage du quadruplet de connexion.

Le cas d’usage pour SO_RESUSEPORT en TCP serait quelque chose comme un serveur web écoutant sur le port 80 fonctionnant avec plusieurs routines, où chaque routine pourrait avoir sa propre chaussette d’écoute. Cela pourrait être une alternative à d’autres modèles :

1. avoir une routine d’écoute qui distribue les connexions aux autres routines ;
2. accepter sur une seule chaussette depuis plusieurs routines.

Dans le premier cas, la routine d’écoute peut facilement devenir un goulot d’étranglement. Dans le second cas, la proportion de connexions acceptées par routine a tendance à être inégale sous une charge élevée. […] Nous avons vu la disproportion atteindre un ratio de 3:1 entre la routine acceptant le plus de connexions et celle qui en accepte le moins. Avec SO_REUSEPORT, la distribution est uniforme.

Le cas d’usage pour SO_REUSEPORT en UDP serait quelque chose comme un serveur DNS. Une alternative serait de recevoir sur la même chaussette depuis plusieurs routines. Comme dans le cas de TCP, la charge entre ces routines a tendance à être disproportionnée et nous observons également beaucoup de contention sur le verrou de la chaussette.

Akvorado utilise l’option SO_REUSEPORT pour distribuer les paquets entre les routines. Comme la distribution utilise un hachage du quadruplet de connexion, une seule routine gère tous les flux provenant d’un exporteur.

Option SO_ATTACH_REUSEPORT_EBPF

Dans Linux 4.5, Craig Gallek a ajouté l’option SO_ATTACH_REUSEPORT_EBPF pour permettre à un programme eBPF de sélectionner la chaussette UDP cible. Dans Linux 4.6, il l’a étendue pour prendre en charge TCP. La page de manuel socket(7) documente ce mécanisme¹ :

Le programme BPF doit renvoyer un index entre 0 et N-1 représentant la chaussette qui devrait recevoir le paquet (où N est le nombre de chaussettes dans le groupe). Si le programme BPF renvoie un index invalide, la sélection de chaussette se rabattra sur le mécanisme SO_REUSEPORT standard.

Dans Linux 4.19, Martin KaFai Lau a ajouté le type de programme BPF_PROG_TYPE_SK_REUSEPORT. Un tel programme eBPF sélectionne la chaussette à partir d’un tableau associatif. Cette nouvelle approche est plus flexible et permet par exemple un redémarrage sans impact en insérant les chaussettes d’une nouvelle instance.

Répartition de charge avec eBPF et Go

Modifier l’algorithme de répartition de charge pour un groupe de chaussettes nécessite deux étapes :

1. écrire et compiler un programme eBPF en C² ;
2. le charger et l’attacher en Go.

Programme eBPF en C

Un algorithme de répartition de charge simple consiste à choisir aléatoirement la chaussette de destination. Le noyau expose la fonction bpf_get_prandom_u32() pour obtenir un nombre pseudo-aléatoire.

volatile const __u32 num_sockets; // ❶

struct {
    __uint(type, BPF_MAP_TYPE_REUSEPORT_SOCKARRAY);
    __type(key, __u32);
    __type(value, __u64);
    __uint(max_entries, 256);
} socket_map SEC(".maps"); // ❷

SEC("sk_reuseport")
int reuseport_balance_prog(struct sk_reuseport_md *reuse_md)
{
    __u32 index = bpf_get_prandom_u32() % num_sockets; // ❸
    bpf_sk_select_reuseport(reuse_md, &socket_map, &index, 0); // ❹
    return SK_PASS; // ❺
}

char _license[] SEC("license") = "GPL";

En ❶, nous déclarons une constante volatile pour le nombre de chaussettes dans le groupe. Nous initialiserons cette constante avant de charger le programme eBPF dans le noyau. En ❷, nous définissons le tableau associatif de chaussettes. Nous le remplirons par la suite avec les descripteurs de fichiers. En ❸, nous sélectionnons aléatoirement l’index de la chaussette cible³. En ❹, nous invoquons la fonction bpf_sk_select_reuseport() pour enregistrer notre décision. Enfin, en ❺, nous acceptons le paquet.

Fichiers d’en-tête

Si vous compilez le source C avec clang, vous obtenez des erreurs dues à des entêtes manquantes. La méthode conseillée pour résoudre ce problème consiste à générer un fichier vmlinux.h avec bpftool :

$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

Ensuite, incluez les entêtes suivantes⁴ :

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

Pour mon noyau 6.17, le fichier vmlinux.h généré est assez volumineux : 2,7 Mio. De plus, bpf/bpf_helpers.h est fourni avec libbpf. Cela ajoute une autre dépendance. Comme le programme eBPF est assez petit, je préfère mettre le strict minimum dans vmlinux.h en sélectionnant les définitions dont j’ai besoin.

Compilation

La bibliothèque eBPF pour Go fournit bpf2go, un outil pour compiler les programmes eBPF et générer un squelette de code. Nous créons un fichier gen.go avec le contenu suivant :

package main

//go:generate go tool bpf2go -tags linux reuseport reuseport_kern.c

Après avoir exécuté go generate ./..., nous pouvons inspecter les objets résultants avec readelf et llvm-objdump :

$ readelf -S reuseport_bpfeb.o
There are 14 section headers, starting at offset 0x840:
  [Nr] Name              Type             Address           Offset
[…]
  [ 3] sk_reuseport      PROGBITS         0000000000000000  00000040
  [ 6] .maps             PROGBITS         0000000000000000  000000c8
  [ 7] license           PROGBITS         0000000000000000  000000e8
[…]
$ llvm-objdump -S reuseport_bpfeb.o
reuseport_bpfeb.o:  file format elf64-bpf
Disassembly of section sk_reuseport:
0000000000000000 <reuseport_balance_prog>:
; {
       0:   bf 61 00 00 00 00 00 00     r6 = r1
;     __u32 index = bpf_get_prandom_u32() % num_sockets;
       1:   85 00 00 00 00 00 00 07     call 0x7
[…]

Utilisation depuis Go

Configurons 10 routines écoutant sur le même port⁵. Chaque chaussette active l’option SO_REUSEPORT avant de se mettre en écoute⁶ :

var (
    err error
    fds []uintptr
    conns []*net.UDPConn
)
workers := 10
listenAddr := "127.0.0.1:0"
listenConfig := net.ListenConfig{
    Control: func(_, _ string, c syscall.RawConn) error {
        c.Control(func(fd uintptr) {
            err = unix.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.SO_REUSEPORT, 1)
            fds = append(fds, fd)
        })
        return err
    },
}
for range workers {
    pconn, err := listenConfig.ListenPacket(t.Context(), "udp", listenAddr)
    if err != nil {
        t.Fatalf("ListenPacket() error:\n%+v", err)
    }
    udpConn := pconn.(*net.UDPConn)
    listenAddr = udpConn.LocalAddr().String()
    conns = append(conns, udpConn)
}

La deuxième étape consiste à charger le programme eBPF, initialiser la variable num_sockets, remplir le tableau de chaussettes et attacher le programme à la première chaussette⁷.

// Charge la collection eBPF.
spec, err := loadReuseport()
if err != nil {
    t.Fatalf("loadVariables() error:\n%+v", err)
}

// Initialise la variable globale "num_sockets" avec le nombre de descripteurs de fichiers.
if err := spec.Variables["num_sockets"].Set(uint32(len(fds))); err != nil {
    t.Fatalf("NumSockets.Set() error:\n%+v", err)
}

// Charge le programme et le tableau dans le noyau.
var objs reuseportObjects
if err := spec.LoadAndAssign(&objs, nil); err != nil {
    t.Fatalf("loadReuseportObjects() error:\n%+v", err)
}
t.Cleanup(func() { objs.Close() })

// Renseigne les descripteurs de fichiers dans le tableau de chaussettes.
for worker, fd := range fds {
    if err := objs.reuseportMaps.SocketMap.Put(uint32(worker), uint64(fd)); err != nil {
        t.Fatalf("SocketMap.Put() error:\n%+v", err)
    }
}

// Attache le programme eBPF à la première chaussette.
socketFD := int(fds[0])
progFD := objs.reuseportPrograms.ReuseportBalanceProg.FD()
if err := unix.SetsockoptInt(socketFD, unix.SOL_SOCKET, unix.SO_ATTACH_REUSEPORT_EBPF, progFD); err != nil {
    t.Fatalf("SetsockoptInt() error:\n%+v", err)
}

Nous sommes maintenant prêts à traiter les paquets. Chaque routine Go incrémente un compteur pour chaque paquet reçu⁸ :

var wg sync.WaitGroup
receivedPackets := make([]int, workers)
for worker := range workers {
    conn := conns[worker]
    packets := &receivedPackets[worker]
    wg.Go(func() {
        payload := make([]byte, 9000)
        for {
            if _, err := conn.Read(payload); err != nil {
                if errors.Is(err, net.ErrClosed) {
                    return
                }
                t.Logf("Read() error:\n%+v", err)
            }
            *packets++
        }
    })
}

Envoyons 1000 paquets :

sentPackets := 1000
conn, err := net.Dial("udp", conns[0].LocalAddr().String())
if err != nil {
    t.Fatalf("Dial() error:\n%+v", err)
}
defer conn.Close()
for range sentPackets {
    if _, err := conn.Write([]byte("hello world!")); err != nil {
        t.Fatalf("Write() error:\n%+v", err)
    }
}

Si nous affichons le contenu du tableau receivedPackets, nous pouvons vérifier que la répartition fonctionne comme prévu, chaque routine recevant environ 100 paquets :

=== RUN   TestUDPWorkerBalancing
    balancing_test.go:84: receivedPackets[0] = 107
    balancing_test.go:84: receivedPackets[1] = 92
    balancing_test.go:84: receivedPackets[2] = 99
    balancing_test.go:84: receivedPackets[3] = 105
    balancing_test.go:84: receivedPackets[4] = 107
    balancing_test.go:84: receivedPackets[5] = 96
    balancing_test.go:84: receivedPackets[6] = 102
    balancing_test.go:84: receivedPackets[7] = 105
    balancing_test.go:84: receivedPackets[8] = 99
    balancing_test.go:84: receivedPackets[9] = 88

    balancing_test.go:91: receivedPackets = 1000
    balancing_test.go:92: sentPackets     = 1000

Déploiement sans impact

Nous pouvons également utiliser SO_ATTACH_REUSEPORT_EBPF pour redémarrer une application sans impact. Une nouvelle instance de l’application prépare sa propre version du tableau de chaussettes et attache le programme eBPF à la première d’entre elles. Le noyau dirige alors les paquets entrants vers cette nouvelle instance. L’ancienne instance doit traiter les paquets déjà reçus avant de s’arrêter.

Pour vérifier que nous ne perdons aucun paquet, nous créons une routine Go pour envoyer autant de paquets que possible :

sentPackets := 0
notSentPackets := 0
done := make(chan bool)
conn, err := net.Dial("udp", conns1[0].LocalAddr().String())
if err != nil {
    t.Fatalf("Dial() error:\n%+v", err)
}
defer conn.Close()
go func() {
    for {
        if _, err := conn.Write([]byte("hello world!")); err != nil {
            notSentPackets++
        } else {
            sentPackets++
        }
        select {
        case <-done:
            return
        default:
        }
    }
}()

Ensuite, pendant que cette routine Go s’exécute, nous démarrons le deuxième ensemble de routines. Une fois configurées, elles commencent à recevoir des paquets. Si nous arrêtons proprement l’ensemble initial de routines, nous ne perdons aucun paquet⁹ !

=== RUN   TestGracefulRestart
    graceful_test.go:135: receivedPackets1[0] = 165
    graceful_test.go:135: receivedPackets1[1] = 195
    graceful_test.go:135: receivedPackets1[2] = 194
    graceful_test.go:135: receivedPackets1[3] = 190
    graceful_test.go:135: receivedPackets1[4] = 213
    graceful_test.go:135: receivedPackets1[5] = 187
    graceful_test.go:135: receivedPackets1[6] = 170
    graceful_test.go:135: receivedPackets1[7] = 190
    graceful_test.go:135: receivedPackets1[8] = 194
    graceful_test.go:135: receivedPackets1[9] = 155

    graceful_test.go:139: receivedPackets2[0] = 1631
    graceful_test.go:139: receivedPackets2[1] = 1582
    graceful_test.go:139: receivedPackets2[2] = 1594
    graceful_test.go:139: receivedPackets2[3] = 1611
    graceful_test.go:139: receivedPackets2[4] = 1571
    graceful_test.go:139: receivedPackets2[5] = 1660
    graceful_test.go:139: receivedPackets2[6] = 1587
    graceful_test.go:139: receivedPackets2[7] = 1605
    graceful_test.go:139: receivedPackets2[8] = 1631
    graceful_test.go:139: receivedPackets2[9] = 1689

    graceful_test.go:147: receivedPackets = 18014
    graceful_test.go:148: sentPackets     = 18014

Malheureusement, arrêter correctement une chaussette UDP n’est pas trivial en Go¹⁰. Auparavant, nous terminions les routines en fermant leurs chaussettes. Cependant, si nous les fermons trop tôt, l’application perd les paquets qui leur ont été attribués mais qui n’ont pas encore été traités. Avant de s’arrêter, une routine doit appeler conn.Read() jusqu’à ce qu’il n’y ait plus de paquets. Une solution consiste à définir une échéance pour conn.Read() et vérifier si nous devons arrêter la routine Go lorsque l’échéance est écoulée :

payload := make([]byte, 9000)
for {
    conn.SetReadDeadline(time.Now().Add(50 * time.Millisecond))
    if _, err := conn.Read(payload); err != nil {
        if errors.Is(err, os.ErrDeadlineExceeded) {
            select {
            case <-done:
                return
            default:
                continue
            }
        }
        t.Logf("Read() error:\n%+v", err)
    }
    *packets++
}

Avec TCP, cet aspect est plus simple : après avoir activé le paramètre noyau net.ipv4.tcp_migrate_req, le noyau migre automatiquement les connexions en attentes vers une chaussette aléatoire du même groupe. Alternativement, eBPF peut également contrôler cette migration. Les deux fonctionnalités sont disponibles depuis Linux 5.14.

Addendum

Après avoir implémenté cette stratégie dans Akvorado, toutes les routines perdent désormais des paquets ! 😱

$ curl -s 127.0.0.1:8080/api/v0/inlet/metrics \
> | sed -n s/akvorado_inlet_flow_input_udp_in_dropped//p
packets_total{listener="0.0.0.0:2055",worker="0"} 838673
packets_total{listener="0.0.0.0:2055",worker="1"} 843675
packets_total{listener="0.0.0.0:2055",worker="2"} 837922
packets_total{listener="0.0.0.0:2055",worker="3"} 841443
packets_total{listener="0.0.0.0:2055",worker="4"} 840668
packets_total{listener="0.0.0.0:2055",worker="5"} 850274
packets_total{listener="0.0.0.0:2055",worker="6"} 835488
packets_total{listener="0.0.0.0:2055",worker="7"} 834479

La raison majeure est que le module Kafka limite par défaut les lots à 32 messages. Cette limite est trop basse car les brokers ont une charge importante lors du traitement de chaque lot : ils doivent s’assurer de leur bonne persistance avant d’accuser réception. Augmenter la limite à 4096 messages corrige ce problème.

Bien que la répartition des flux entrants avec eBPF reste utile, elle n’a pas résolu le problème principal. Au moins, la distribution uniforme des paquets perdus a aidé à identifier le véritable goulot d’étranglement. 😅

Une solution courante pour fournir un service hautement disponible et évolutif consiste à insérer une couche d’équilibrage de charge pour répartir les requêtes des utilisateurs vers les serveurs frontaux¹. Nous avons habituellement plusieurs attentes à l’égard d’une telle couche :

Évolutivité

Elle permet à un service de monter en charge en poussant le trafic vers des serveurs nouvellement provisionnés. Elle est également capable de s’étendre si elle devient le goulot d’étranglement.

Disponibilité

Elle fournit la haute disponibilité au service. Si un serveur devient indisponible, le trafic est rapidement redirigé vers un autre serveur. Elle doit également être elle-même hautement disponible.

Flexibilité

Elle gère aussi bien les connexions de courtes et de longues durées. Elle est suffisamment flexible pour offrir toutes les fonctionnalités généralement attendues d’un répartiteur de charge comme TLS ou le routage HTTP.

Opérabilité

Avec un peu de coopération, tout changement prévu est transparent : mise à niveau des frontaux, ajout ou suppression de frontaux ou changement de topologie de la couche de répartition elle-même.

Le problème et ses solutions sont bien connus. Parmi les articles récemment parus sur le sujet, « Introduction to modern network load-balancing and proxying » donne un aperçu de l’état de l’art. Google a publié « Maglev: A Fast and Reliable Software Network Load Balancer » décrivant en détail leur solution interne². Cependant, le logiciel associé n’est pas disponible. Fondamentalement, la construction d’une solution d’équilibrage de charge consiste à assembler trois composants :

• routage ECMP ;
• répartition L4 (sans état) ;
• répartition L7 (avec état).

Dans cet article, je décris une solution à multiples niveaux utilisant Linux et des composants open-source. Cela offre une base pour construire une couche d’équilibrage de charge prête à la production.

Dernier niveau : répartition L7

Commençons par le dernier niveau. Son rôle est de fournir la haute disponibilité, en transférant les requêtes vers les frontaux sains, ainsi que l’évolutivité, en répartissant équitablement les requêtes. Travaillant dans les couches supérieures du modèle OSI, il peut également offrir des services supplémentaires, comme la terminaison TLS, le routage HTTP, la réécriture des entêtes, la limitation du débit des utilisateurs non authentifiés, etc. Il peut tirer parti d’algorithmes complexes d’équilibrage de charge. En tant que premier point de contact avec les serveurs frontaux, il doit faciliter les maintenances et minimiser l’impact lors des changements quotidiens.

Il termine également les connexions TCP des clients. Cela découple l’étage de répartition des serveurs frontaux avec les avantages suivants :

• les connexions vers les frontaux peuvent être maintenues ouvertes pour réduire l’utilisation des ressources et la latence ;
• les requêtes peuvent être réessayées de manière transparente en cas de défaillance ;
• les clients peuvent utiliser un protocole IP différent des serveurs ;
• les frontaux n’ont pas à se soucier de la découverte de la MTU du chemin, des algorithmes de congestion TCP, de la gestion de l’état TIME-WAIT ou d’autres détails de bas niveau.

De nombreux logiciels conviennent pour cette couche et il existe une littérature abondante sur la façon de les configurer. Vous pouvez regarder HAProxy, Envoy ou Traefik. Voici un exemple de configuration pour HAProxy :

# Point d'entrée de la répartition de charge L7
frontend l7lb
  # Écoute à la fois en IPv4 et IPv6
  bind :80 v4v6
  # Redirige tout sur un ensemble de serveurs frontaux
  default_backend servers
  # Vérification de la bonne santé
  acl dead nbsrv(servers) lt 1
  acl disabled nbsrv(enabler) lt 1
  monitor-uri /healthcheck
  monitor fail if dead || disabled

# Serveurs frontaux en IPv6 avec tests HTTP et via un agent
backend servers
  balance roundrobin
  option httpchk
  server web1 [2001:db8:1:0:2::1]:80 send-proxy check agent-check agent-port 5555
  server web2 [2001:db8:1:0:2::2]:80 send-proxy check agent-check agent-port 5555
  server web3 [2001:db8:1:0:2::3]:80 send-proxy check agent-check agent-port 5555
  server web4 [2001:db8:1:0:2::4]:80 send-proxy check agent-check agent-port 5555

# Faux serveur gérant la disponibilitant du répartiteur de charge lui-même
backend enabler
  server enabler [::1]:0 agent-check agent-port 5555

Cette configuration est très sommaire mais permet d’illustrer deux notions clés pour l’opérabilité :

1. Les frontaux sont testés à la fois au niveau HTTP (avec check et option httpchk) et via un agent auxiliaire (avec agent-check). Ce dernier permet de placer un serveur en maintenance pour effectuer une mise en production progressive. Sur chaque frontal, un processus écoute sur le port 5555 et répond avec le statut du service (UP, DOWN, MAINT). Un simple socat fait l’affaire³ :

   socat -ly \
     TCP6-LISTEN:5555,ipv6only=0,reuseaddr,fork \
     OPEN:/etc/lb/agent-check,rdonly
   

   Dans /etc/lb/agent-check, UP indique que le service est en mode nominal. Si le test HTTP est aussi positif, HAProxy enverra des requêtes vers ce nœud. Si vous devez le mettre en maintenance, écrivez MAINT et attendez que les connexions en cours se terminent. Utilisez READY pour annuler ce mode.

2. Le répartiteur de charge lui-même fournit un point de diagnostic (/healthcheck) pour les niveaux supérieurs. Il retourne une erreur 503 si aucun frontal n’est disponible ou si le serveur enabler est indiqué comme indisponible via l’agent. Le même mécanisme que pour les serveurs frontaux classiques peut alors être utilisé pour signaler l’indisponibilité de cet équilibreur de charge.

De plus, la directive send-proxy permet d’utiliser le protocole proxy afin de transmettre les adresses IP réelles des clients. Ce protocole fonctionne également pour les connexions non-HTTP et est supporté par de nombreux serveurs, y compris nginx :

http {
  server {
    listen [::]:80 default ipv6only=off proxy_protocol;
    root /var/www;
    set_real_ip_from ::/0;
    real_ip_header proxy_protocol;
  }
}

En l’état, cette solution n’est pas complète. Nous avons déplacé le problème de disponibilité et d’évolutivité ailleurs. Comment répartir les demandes entre les équilibreurs de charge ?

Premier niveau : routage ECMP

Sur la plupart des réseaux IP modernes, il existe des chemins redondants entre les clients et les serveurs. Pour chaque paquet, les routeurs doivent choisir une branche. Lorsque le coût associé à chaque trajet est égal, les flux entrants⁴ sont répartis entre les destinations disponibles. Cette caractéristique peut être utilisée pour répartir les connexions entre les équilibreurs de charge disponibles :

Il y a peu de contrôle sur la répartition des flux, mais le routage ECMP apporte la possibilité de faire évoluer horizontalement les deux niveaux. Une mise en œuvre courante d’une telle solution est d’utiliser BGP, un protocole de routage pour échanger des routes entre les équipements du réseau. Chaque répartiteur de charge annonce aux routeurs auxquels il est connecté les adresses IP qu’il dessert.

En supposant que vous avez déjà des routeurs avec BGP, ExaBGP est une solution flexible pour permettre aux répartiteurs de charge d’annoncer leur disponibilité. Voici un exemple de configuration :

# Test de disponibilité en IPv6
process service-v6 {
  run python -m exabgp healthcheck -s --interval 10 --increase 0 --cmd "test -f /etc/lb/v6-ready -a ! -f /etc/lb/disable";
  encoder text;
}

template {
  # Patron pour un routeur IPv6
  neighbor v6 {
    router-id 192.0.2.132;
    local-address 2001:db8::192.0.2.132;
    local-as 65000;
    peer-as 65000;
    hold-time 6;
    family {
      ipv6 unicast;
    }
    api services-v6 {
      processes [ service-v6 ];
    }
  }
}

# Premier routeur
neighbor 2001:db8::192.0.2.254 {
  inherit v6;
}

# Second routeur
neighbor 2001:db8::192.0.2.253 {
  inherit v6;
}

Si /etc/lb/v6-ready est présent mais que /etc/lb/disable est absent, toutes les IP configurées sur l’interface lo sont annoncées aux deux routeurs. Si les autres répartiteurs de charge ont une configuration similaire, les routeurs leur distribuent équitablement les flux reçus. Un processus externe doit gérer l’existence du fichier /etc/lb/v6-ready en vérifiant la bonne santé du répartiteur de charge (à l’aide du point /healthcheck par exemple). Un opérateur peut retirer un répartiteur de charge de la rotation en créant le fichier /etc/lb/disable.

Pour plus de détails concernant cette partie, jetez un œil sur « Redondance avec ExaBGP ». Si vous êtes hébergés dans les nuages, ce tiers est généralement mis en place par votre fournisseur sous forme d’une IP « élastique » ou d’un service de répartition L4.

Malheureusement, cette solution n’est pas robuste lorsqu’un changement, prévu ou non, se produit. Notamment, lors de l’ajout ou de la suppression d’un équilibreur de charge, le nombre de routes disponibles pour une destination change. L’algorithme de hachage utilisé par les routeurs n’est pas cohérent et les flux sont redistribués entre les répartiteurs de charge disponibles, rompant les connexions existantes :

De plus, chaque routeur peut choisir ses propres chemins. Quand un routeur devient indisponible, le second peut router les mêmes flux différemment :

Si vous pensez que ce n’est pas un résultat acceptable, notamment si vous devez gérer de longues connexions comme le téléchargement de fichiers, le streaming vidéo ou les connexions websocket, vous avez besoin d’un niveau supplémentaire. Continuez la lecture !

Second niveau : répartition L4

Le deuxième niveau est la glue entre le monde sans état des routeurs IP et le pays avec état de l’équilibrage de charge L7. Il est mis en œuvre grâce à l’équilibrage de charge L4. La terminologie peut être un peu confuse ici : ce niveau route les datagrammes IP (pas de terminaison TCP) mais l’algorithme de répartition utilise à la fois l’IP de destination et le port pour choisir un serveur disponible dans le niveau suivant. Le but de cet étage est de s’assurer que tous les membres prennent la même décision d’ordonnancement pour un paquet entrant.

Il y a deux possibilités :

• répartition de charge L4 avec synchronisation des états ;
• répartition de charge L4 avec hachage cohérent.

La première option augmente la complexité et limite l’évolutivité. Nous ne l’explorons pas⁵. La seconde option est moins robuste aux changements mais cela peut être amélioré via une approche hybride avec un état local.

Nous utilisons IPVS, un répartiteur de charge L4 performant fonctionnant dans le noyau Linux. Il est piloté par Keepalived qui dispose d’un ensemble de tests de disponibilité pour détecter les problèmes. IPVS est configuré pour utiliser Maglev, un algorithme de hachage cohérent créé par Google. Dans sa famille, c’est un bon algorithme car il répartit les connexions de manière équitable, minimise les impacts consécutifs à un changement et est particulièrement rapide pour construire sa table de correspondance. Enfin, pour améliorer les performances, le dernier niveau (les répartiteurs de charge L7) répond aux clients directement sans impliquer le second niveau (les répartiteurs de charge L4). Ce mécanisme est connu sous le nom de direct server return (DSR) ou direct routing (DR).

Avec une telle configuration, on s’attend à ce que les paquets appartenant à un flux puissent se déplacer librement entre les composants des deux premiers niveaux tout en finissant sur le même équilibreur de charge L7.

Configuration

Une fois ExaBGP configuré comme décrit dans la section précédente, nous pouvons passer à la configuration de Keepalived :

virtual_server_group VS_GROUP_MH_IPv6 {
  2001:db8::198.51.100.1 80
}
virtual_server group VS_GROUP_MH_IPv6 {
  lvs_method TUN  # Mode tunnel pour DSR
  lvs_sched mh    # Algorithme : Maglev
  mh-port         # Prend en compte les ports TCP
  protocol TCP
  delay_loop 5
  alpha           # Les serveurs sont considérés inaccessibles au démarrage
  omega           # Exécute quorum_down à l'arrêt
  quorum_up   "/bin/touch /etc/lb/v6-ready"
  quorum_down "/bin/rm -f /etc/lb/v6-ready"

  # Premier répartiteur de charge L7
  real_server 2001:db8::192.0.2.132 80 {
    weight 1
    HTTP_GET {
      url {
        path /healthcheck
        status_code 200
      }
      connect_timeout 2
    }
  }

  # Tous les autres...
}

Les directives quorum_up et quorum_down définissent les commandes à exécuter quand le service devient respectivement accessible et inaccessible. Le fichier /etc/lb/v6-ready est utilisé pour signaler à ExaBGP s’il doit ou non publier l’adresse IP du service aux routeurs.

De plus, IPVS doit être configuré pour router les paquets appartenant à un flux traité initialement par un autre nœud. Il doit également continuer de router les paquets quand une destination devient indisponible afin de s’assurer qu’on puisse mettre hors service proprement un répartiteur de charge L7.

# Prend aussi en charge les paquets non SYN
sysctl -qw net.ipv4.vs.sloppy_tcp=1
# Ne PAS rerouter une connexion quand une destination
# devient invalide.
sysctl -qw net.ipv4.vs.expire_nodest_conn=0
sysctl -qw net.ipv4.vs.expire_quiescent_template=0

L’algorithme Maglev sera disponible dans Linux 4.18, grâce au travail de Inju Song. Pour les noyaux plus anciens, j’ai préparé un rétroportage⁶. Le substituer par un autre algorithme, tel que sh, rend l’ensemble moins robuste.

Le DSR est mis en place avec le mode tunnel. Cette méthode est compatible avec les réseaux routés. Les requêtes sont encapsulées vers le nœud choisi à l’aide du protocole IPIP. Cela ajoute un léger surcoût et entraîne des problèmes de MTU. Si possible, utilisez une MTU plus grande entre le second et troisième niveau⁷. Dans le cas contraire, autorisez explicitement la fragmentation des paquets IP :

sysctl -qw net.ipv4.vs.pmtu_disc=0

Il faut aussi configurer les répartiteurs de charge L7 pour accepter ce trafic encapsulé⁸ :

# Configure le tunnel IPIP pour accepter des paquets de n'importe quelle source
ip tunnel add tunlv6 mode ip6ip6 local 2001:db8::192.0.2.132
ip link set up dev tunlv6
ip addr add 2001:db8::198.51.100.1/128 dev tunlv6

Évaluation de la robustesse

Ainsi configuré, le second niveau améliore la robustesse de l’ensemble pour deux raisons :

1. L’utilisation d’un algorithme de hachage cohérent pour choisir la destination réduit l’impact négatif d’un changement, prévu ou non, en minimisant le nombre de flux déplacés vers une nouvelle destination. « Consistent Hashing: Algorithmic Tradeoffs » offre plus de détails sur ce sujet.

2. IPVS garde localement une table des connexions pour les flux connus. Quand un changement n’impacte que le dernier niveau, les flux existants continuent d’être routés correctement en utilisant cette table.

Si nous ajoutons ou retirons un répartiteur L4, les flux existants ne sont pas impactés car chaque répartiteur prend la même décision grâce au hachage cohérent :

Lors de l’ajout d’un répartiteur L7, les flux existants ne sont pas impactés non plus car seules les nouvelles connexions sont routées vers le nouveau répartiteur. Pour les connexions existantes, IPVS utilise sa table de connexion locale et continue de router les paquets vers la destination originale. De manière similaire, le retrait d’un répartiteur L7 n’impacte que les connexions liées à celui-ci. Les autres connexions sont routées correctement :

Seuls des changements simultanés sur les deux niveaux mènent à un impact notable. Par exemple, lors de l’ajout d’un équilibreur de charge L4 et d’un équilibreur de charge L7, seules les connexions déplacées vers un répartiteur L4 sans état et programmées vers le nouveau répartiteur seront rompues. Grâce à l’algorithme de hachage cohérent, les autres connexions resteront liées au répartiteur L7 adéquat. Lors d’un changement planifié, cette perturbation peut être minimisée en ajoutant d’abord les nouveaux équilibreurs L4, en attendant quelques minutes puis en ajoutant les nouveaux équilibreurs L7.

De plus, IPVS route correctement les messages ICMP vers les mêmes répartiteurs L7 que les flux associés⁹. Cela permet à la découverte de la MTU du chemin de fonctionner correctement sans utiliser de techniques palliatives.

Niveau 0 : répartition de charge via le DNS

Il est également possible d’ajouter un équilibrage de charge DNS à l’ensemble. Ceci est utile si votre installation est répartie sur plusieurs centres de données, plusieurs régions ou si vous voulez diviser une large ferme de répartition de charge en morceaux plus petits. Il n’est pas destiné à remplacer le premier niveau car il ne partage pas les mêmes caractéristiques : la répartition de charge est déséquilibrée (elle n’est pas basée sur les flux) et la guérison après une panne est lente.

gdnsd est un serveur DNS faisant autorité avec des tests de disponibilité intégrés. Il peut servir des zones au format RFC 1035 :

@ SOA ns1 ns1.example.org. 1 7200 1800 259200 900
@ NS ns1.example.com.
@ NS ns1.example.net.
@ MX 10 smtp

@     60 DYNA multifo!web
www   60 DYNA multifo!web
smtp     A    198.51.100.99

L’enregistrement spécial DYNA retourne des entrées A et AAAA après avoir consulté le greffon spécifié. Ici, le greffon multfifo implémente une surveillance en mode actif/actif des adresses IP de la ferme :

service_types => {
  web => {
    plugin => http_status
    url_path => /healthcheck
    down_thresh => 5
    interval => 5
  }
  ext => {
    plugin => extfile
    file => /etc/lb/ext
    def_down => false
  }
}

plugins => {
  multifo => {
    web => {
      service_types => [ ext, web ]
      addrs_v4 => [ 198.51.100.1, 198.51.100.2 ]
      addrs_v6 => [ 2001:db8::198.51.100.1, 2001:db8::198.51.100.2 ]
    }
  }
}

En mode nominal, une requête A recevra en réponse à la fois 198.51.100.1 et 198.51.100.2. Si un test de disponibilité échoue, l’ensemble retourné est mis à jour. Il est également possible de retirer une IP volontairement en modifiant le fichier /etc/lb/ext. Par exemple, en mettant le contenu suivant, 198.51.100.2 ne fera plus partie des réponses :

198.51.100.1 => UP
198.51.100.2 => DOWN
2001:db8::c633:6401 => UP
2001:db8::c633:6402 => UP

Tous les fichiers de configuration pour la mise en place de chaque niveau sont disponibles dans un dépôt Git. Si vous voulez reproduire cette configuration à une échelle plus petite, il est possible de fusionner le second et le troisième niveau, soit avec des espaces de nom, soit avec une configuration spécifique de type localnode. Même si vous n’avez pas besoin de ces services directs, vous devriez garder le dernier niveau : alors que les serveurs frontaux vont et viennent, les équilibreurs de charge L7 apportent de la stabilité, rendant l’ensemble plus robuste.

DKMS est un système conçu pour permettre la mise à jour individuelle de modules noyau sans changer le noyau en entier. Il est également très facile de reconstruire des modules lorsque vous mettez à jour le noyau.

Sur les systèmes de type Debian¹, DKMS permet l’installation de différents pilotes, de ZFS aux modules VirtualBox ou NVIDIA. Ces modules externes ne sont pas distribués sous forme binaire : une fois installés, ils doivent être compilés pour votre noyau actuel. Tout se fait automatiquement :

# apt install zfs-dkms
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  binutils cpp cpp-6 dkms fakeroot gcc gcc-6 gcc-6-base libasan3 libatomic1 libc-dev-bin libc6-dev
  libcc1-0 libcilkrts5 libfakeroot libgcc-6-dev libgcc1 libgomp1 libisl15 libitm1 liblsan0 libmpc3
  libmpfr4 libmpx2 libnvpair1linux libquadmath0 libstdc++6 libtsan0 libubsan0 libuutil1linux libzfs2linux
  libzpool2linux linux-compiler-gcc-6-x86 linux-headers-4.9.0-6-amd64 linux-headers-4.9.0-6-common
  linux-headers-amd64 linux-kbuild-4.9 linux-libc-dev make manpages manpages-dev patch spl spl-dkms
  zfs-zed zfsutils-linux
[…]
3 upgraded, 44 newly installed, 0 to remove and 3 not upgraded.
Need to get 42.1 MB of archives.
After this operation, 187 MB of additional disk space will be used.
Do you want to continue? [Y/n]
[…]
# dkms status
spl, 0.6.5.9, 4.9.0-6-amd64, x86_64: installed
zfs, 0.6.5.9, 4.9.0-6-amd64, x86_64: installed
# modinfo zfs | head
filename:       /lib/modules/4.9.0-6-amd64/updates/dkms/zfs.ko
version:        0.6.5.9-5
license:        CDDL
author:         OpenZFS on Linux
description:    ZFS
srcversion:     42C4AB70887EA26A9970936
depends:        spl,znvpair,zcommon,zunicode,zavl
retpoline:      Y
vermagic:       4.9.0-6-amd64 SMP mod_unload modversions
parm:           zvol_inhibit_dev:Do not create zvol device nodes (uint)

Lors de l’installation d’un nouveau noyau, la compilation du module est automatiquement déclenchée.

Construction d’un paquet compatible DKMS

Supposons que vous avez mis la main sur un serveur avec une carte réseau Intel XXV710-DA2. Cette carte est gérée par le pilote i40e. Malheureusement, elle n’est prise en charge que depuis Linux 4.10 et vous utilisez un noyau 4.9 issu de Debian Stretch. DKMS fournit ici une solution simple !

Téléchargez les sources du pilote chez Intel, décompressez-les dans un répertoire et ajoutez un sous-répertoire debian/ avec les fichiers suivants :

• debian/changelog:

  i40e-dkms (2.4.6-0) stretch; urgency=medium
  
    * Initial package.
  
   -- Vincent Bernat <bernat@debian.org>  Tue, 27 Feb 2018 17:20:58 +0100
  

• debian/control:

  Source: i40e-dkms
  Maintainer: Vincent Bernat <bernat@debian.org>
  Build-Depends: debhelper (>= 9), dkms
  
  Package: i40e-dkms
  Architecture: all
  Depends: ${misc:Depends}
  Description: DKMS source for the Intel i40e network driver
  

• debian/rules:

  #!/usr/bin/make -f
  
  include /usr/share/dpkg/pkg-info.mk
  
  %:
          dh $@ --with dkms
  
  override_dh_install:
          dh_install src/* usr/src/i40e-$(DEB_VERSION_UPSTREAM)/
  
  override_dh_dkms:
          dh_dkms -V $(DEB_VERSION_UPSTREAM)
  
  override_dh_auto_configure:
  override_dh_auto_build:
  override_dh_auto_test:
  override_dh_auto_install:
  override_dh_auto_clean:
  

• debian/i40e-dkms.dkms:

  PACKAGE_NAME="i40e"
  PACKAGE_VERSION="#MODULE_VERSION#"
  BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
  DEST_MODULE_LOCATION[0]="/updates/dkms"
  AUTOINSTALL="YES"
  REMAKE_INITRD="YES"
  

• debian/compat:

  9
  

Le fichier debian/changelog permet essentiellement de spécifier la version du paquet. Celle du pilote est 2.4.6. Par conséquent, nous utilisons 2.4.6-0 comme version de paquet. Dans debian/rules, nous copions les sources du pilote dans /usr/src/i40e-2.4.6 (la version est extraite de debian/changelog).

Le contenu de debian/i40e-dkms.dkms est décrit en détail dans la page de manuel dkms(8). Le pilote i40e est assez standard et dkms sait comment le compiler. Cependant, si un module noyau ne suit pas les conventions habituelles, c’est le bon endroit pour remplacer la commande de construction.

Une fois tous les fichiers en place, vous pouvez transformer le répertoire en un paquet Debian à l’aide, par exemple, de la commande dpkg-buildpackage command². Vous obtenez un paquet compatible DKMS : i40e-dkms_2.4.6-0_all.deb. Placez le dans votre dépôt interne et installez-le sur le serveur cible.

Éviter la phase de compilation

Si la présence d’outils de développement sur un serveur en production vous rend nerveux, il y a une solution ! Depuis la version 2.2.0.3-5³, grâce à Thijs Kinkhorst, dkms peut construire des paquets contenant uniquement les modules précompilés. Pour chaque version du noyau, un tel paquet peut être construit via votre système d’intégration :

KERNEL_VERSION=4.9.0-6-amd64 # could be a Jenkins parameter
apt -qyy install \
      i40e-dkms \
      linux-image-${KERNEL_VERSION} \
      linux-headers-${KERNEL_VERSION}

DRIVER_VERSION=$(dkms status i40e | awk -F', ' '{print $2}')
dkms mkbmdeb i40e/${DRIVER_VERSION} -k ${KERNEL_VERSION}

cd /var/lib/dkms/i40e/${DRIVER_VERSION}/bmdeb/
dpkg -c i40e-modules-${KERNEL_VERSION}_*
dpkg -I i40e-modules-${KERNEL_VERSION}_*

Voici la sortie abrégée des deux dernières commandes :

# dpkg -c i40e-modules-${KERNEL_VERSION}_*
[…]
-rw-r--r-- root/root    551664 2018-03-01 19:16 ./lib/modules/4.9.0-6-amd64/updates/dkms/i40e.ko
[…]
# dpkg -I i40e-modules-${KERNEL_VERSION}_*
 new debian package, version 2.0.
[…]
 Package: i40e-modules-4.9.0-6-amd64
 Source: i40e-dkms-bin
 Version: 2.4.6
 Architecture: amd64
 Installed-Size: 555
 Depends: linux-image-4.9.0-6-amd64
 Provides: i40e-modules
 Section: misc
 Priority: optional
 Description: i40e binary drivers for linux-image-4.9.0-6-amd64
  This package contains i40e drivers for the 4.9.0-6-amd64 Linux kernel,
  built from i40e-dkms for the amd64 architecture.

Le paquet Debian ainsi créé contient le pilote précompilé et ne dépend que du noyau associé. Vous pouvez l’installer sans tirer des dizaines de dépendances supplémentaires.

La mise en haute disponibilité des réseaux L2 peut se faire de plusieurs façons :

• d’antiques protocoles tels que le Spanning Tree Protocol ;
• des protocoles propriétaires tels que le chassis virtuel chez Juniper, le vPC chez Cisco ainsi que de nombreuses implémentations de MC-LAG¹ ;
• des protocoles standards tels que Shortest Path Bridging Protocol ou TRILL ;
• la délégation de cette problématique au réseau sous-jacent (dans le cas des protocoles reposant sur d’autres réseaux, tels que VXLAN).

Les réseaux L2 nécessitent très peu de configuration mais sont difficiles à opérer de manière fiable dans des configurations hautement disponibles : un incident risque souvent d’impacter l’ensemble du réseau². Il est donc préférable de limiter la portée de chaque réseau L2. Par exemple, il est courant d’avoir un réseau L2 dans chaque baie et de les connecter entre eux via du routage L3. Un incident impacte rarement l’ensemble d’un réseau IP.

Dans le schéma ci-dessous, les commutateurs de baie fournissent une passerelle par défaut pour les clients. Afin d’assurer une certaine redondance, ils utilisent une implémentation de MC-LAG. La portée de chaque réseau L2 est alors limitée à une seule baie. Chaque sous-réseau IP est lié à une baie et les informations de routage sont partagées entre les commutateurs de baie et les routeurs en utilisant un protocole tel qu’OSPF.

Il y a deux défauts dans cette conception :

1. La portée de chaque réseau L2 reste très importante. Une baie peut contenir plusieurs dizaines d’hyperviseurs et plusieurs milliers de machines virtuelles. Un incident réseau a donc un impact majeur.

2. Les sous-réseaux IP sont liés à une baie. Une machine virtuelle ne peut pas migrer dans une autre baie et les IP non utilisées dans une baie ne peuvent pas être utilisées dans une autre.

Pour résoudre ces deux problèmes, il est possible de pousser le réseau L3 encore plus au sud, transformant chaque hyperviseur en routeur. Il convient toutefois de cacher ce changement aux machines virtuelles qui continuent d’obtenir leur configuration via DHCP (IP, sous-réseau et passerelle).

Hyperviseur comme routeur

En bref, pour une machine virtuelle disposant d’une adresse IPv4 :

• l’hyperviseur hôte configure une route /32 sur l’interface virtuelle ;
• cette route est distribuée aux autres hyperviseurs et routeurs via BGP.

Nous voulons aussi gérer deux domaines de routage : un domaine public pour les machines virtuelles de clients connectées à Internet et un domaine privé pour notre propre usage, notamment la gestion des hyperviseurs. À cet effet, chaque hyperviseur utilise deux tables de routage.

L’illustration suivante montre la configuration d’un hyperviseur avec cinq machines virtuelles. Notez l’absence de tout pont réseau.

La configuration complète décrite dans cet article est également disponible sur GitHub. Un agent reste nécessaire pour mettre en place la configuration lors d’un changement. Pour ce faire, ce dernier recevrait des notifications de la part du système de gestion des machines virtuelles.

Calico est un projet à l’objectif similaire (routage L3 jusqu’à l’hyperviseur) et des idées très proches (à l’exception de l’utilisation de Netfilter pour assurer l’isolation des domaines de routage). Il fournit un agent, Felix, qui s’interface avec des orchestrateurs (tels qu’OpenStack ou Kubernetes). C’est une alternative possible si on désire une solution clé en main.

Configuration du routage

À l’aide de règles de routage, chaque interface est « attachée » à une table de routage :

$ ip rule show
0:  from all lookup local
20: from all iif lo lookup main
21: from all iif lo lookup local-out
30: from all iif eth0.private lookup private
30: from all iif eth1.private lookup private
30: from all iif vnet8 lookup private
30: from all iif vnet9 lookup private
40: from all lookup public

Les règles les plus importantes sont surlignées (priorités 30 et 40) : tout trafic provenant d’une interface privée utilise la table private. Tout le trafic restant utilise la table public.

Les deux règles en iif lo gèrent le routage des paquets émis par l’hyperviseur lui-même. La table local-out est une combinaison des tables private et public. À première vue, l’hyperviseur n’a besoin que de la table private mais il doit être capable de contacter les machines virtuelles locales (par exemple, pour répondre à un ping) via la table public. Ces tables contiennent en temps normal une route par défaut toutes les deux (pas de chaînage possible). La table local-out est construite en copiant toutes les routes de la table private et les routes directement connectées de la table public.

Pour éviter toute fuite de trafic accidentelle, les tables public, private et local-out contiennent une route par défaut avec une métrique élevée³. En temps normal, ces routes sont éclipsées par une véritable route par défaut :

ip route add blackhole default metric 4294967294 table public
ip route add blackhole default metric 4294967294 table private
ip route add blackhole default metric 4294967294 table local-out

Les choses sont plus simples avec IPv6 car il n’y a qu’un seul domaine de routage. Nous gardons cependant une table public mais il n’y a nul besoin de la table local-out :

$ ip -6 rule show
0:  from all lookup local
20: from all lookup main
40: from all lookup public

Une fois cette configuration en place, le routage est activé et la taille maximale du cache des routes IPv6 est augmentée (la valeur par défaut est seulement 4096)⁴ :

sysctl -qw net.ipv4.conf.all.forwarding=1
sysctl -qw net.ipv6.conf.all.forwarding=1
sysctl -qw net.ipv6.route.max_size=524288

Routes pour les machines virtuelles

La seconde étape est de configurer les routes pour atteindre chaque machine virtuelle. Pour IPv6, l’adresse du lien local (dérivée de l’adresse MAC) est utilisée comme prochain saut⁵ :

ip -6 route add 2001:db8:cb00:7100:5254:33ff:fe00:f/128 \
    via fe80::5254:33ff:fe00:f dev vnet6 \
    table public

Ajouter d’autres adresses IP ou sous-réseaux peut se faire en spécifiant d’autres routes sur le même modèle :

ip -6 route add 2001:db8:cb00:7107::/64 \
    via fe80::5254:33ff:fe00:f dev vnet6 \
    table public

En IPv4, la route utilise comme prochain saut l’interface à laquelle la machine virtuelle est connectée. Linux émettra une requête ARP avant de pouvoir router les paquets⁶ :

ip route add 192.0.2.15/32 dev vnet6 \
  table public

Les IP et sous-réseaux supplémentaires peuvent être ajoutées de la même façon. Cela impose toutefois que chaque adresse IP réponde aux requêtes ARP. Pour éviter cela, le routage peut se faire via la première IP configurée⁷ :

ip route add 203.0.113.128/28 \
  via 192.0.2.15 dev vnet6 onlink \
  table public

Configuration BGP

La troisième étape consiste à partager les routes entre les hyperviseurs à l’aide de BGP. Cette partie de la configuration dépend du type de réseau connectant les hyperviseurs.

Fabrique

Les hyperviseurs peuvent être connectés de plusieurs façons. Une première possibilité naturelle est d’utiliser un réseau L3 de type leaf-spine :

Chaque hyperviseur établit une session eBGP vers chaque routeur de type leaf. Ceux-ci établissent une session eBGP avec chaque routeur de type spine. Cette solution peut s’avérer coûteuse car les routeurs de type spine doivent être capables de gérer l’intégralité des routes. Avec la génération actuelle de routeurs, cela implique une limite sur le nombre total de routes en fonction de la densité voulue⁸. Elle nécessite de plus beaucoup de configuration pour définir les sessions BGP, à moins d’utiliser certaines fonctionnalités d’autoconfiguration actuellement encore peu répandues. D’un autre côté, les routeurs de type leaf (et les hyperviseurs) peuvent apprendre moins de routes et pousser le reste du trafic vers le nord.

Une autre solution est d’utiliser une fabrique de type L2. Cela peut sembler surprenant après avoir critiqué les réseaux L2 pour leur manque de fiabilité mais nous n’avons pas besoin de haute disponibilité. Ils permettent alors d’obtenir une solution peu coûteuse et facile à mettre en place⁹ :

Chaque hyperviseur est connecté à 4 réseaux L2 distincts. Si un incident survient sur l’un d’eux, nous ne perdons qu’un quart de la bande passante disponible. Cette solution repose entièrement sur iBGP. Pour éviter de multiplier les connexions BGP entre les hyperviseurs, des réflecteurs de routes sont utilisés. Chaque hyperviseur établit une session iBGP avec un ou plusieurs réflecteurs sur chaque réseau L2. Les réflecteurs d’un même réseau L2 se partagent également leurs routes via iBGP. Calico documente ce concept de manière plus détaillée.

C’est la solution utilisée par la suite. La partie publique et la partie privée partagent la même infrastructure sur des VLAN différents.

Réflecteurs de routes

Les réflecteurs de routes centralisent et redistribuent les routes via BGP mais ne routent aucun trafic. Il en faut au moins un dans chaque réseau L2. Pour une meilleure disponibilité, on peut en utiliser plusieurs.

Voici un exemple de configuration avec Junos¹⁰ :

protocols {
    bgp {
        group public-v4 {
            family inet {
                unicast {
                    no-install; # ❶
                }
            }
            type internal;
            cluster 198.51.100.126; # ❷
            allow 198.51.100.0/25; # ❸
            neighbor 198.51.100.127;
        }
        group public-v6 {
            family inet6 {
                unicast {
                    no-install;
                }
            }
            type internal;
            cluster 198.51.100.126;
            allow 2001:db8:c633:6401::/64;
            neighbor 2001:db8:c633:6401::198.51.100.127;
        }
        ttl 255;
        bfd-liveness-detection { # ❹
            minimum-interval 100;
            multiplier 5;
        }
    }
}
routing-options {
    router-id 198.51.100.126;
    autonomous-system 65000;
}

Ce réflecteur accepte et redistribue toutes les routes IPv4 et IPv6. En ❶, on s’assure que les routes ne sont pas installées dans la FIB car un réflecteur n’est pas un routeur.

Chaque réflecteur doit disposer d’un cluster identifier qui est utilisé pour détecter les boucles. Dans notre cas, nous utilisons l’adresse IPv4 à cet effet (en ❷). En utilisant un identifiant différent pour chaque réflecteur attaché à un même réseau L2, on s’assure qu’ils s’échangeront les routes reçues, apportant ainsi une meilleure résilience.

Au lieu de déclarer explicitement chacun des hyperviseurs devant se connecter au réflecteur, un sous-réseau entier est autorisé en ❸¹¹. Nous déclarons aussi le second réflecteur présent sur le même réseau L2 afin qu’ils s’échangent leurs routes.

Un autre point important est de réagir rapidement en cas d’indisponibilité d’un chemin. Avec des sessions BGP directement connectées, un lien défaillant peut être détecté immédiatement et la session BGP est aussitôt invalidée. Cela n’est pas toujours fiable et dans notre cas, cela ne fonctionne pas en raison de la présence de commutateurs sur les chemins. En ❹, nous activons BFD, un protocole qui permet de détecter en moins d’une seconde¹² un problème entre deux pairs BGP (RFC 5880).

Un dernier point à prendre en compte est la possibilité de faire du routage anycast : si une IP est publiée sur plusieurs hyperviseurs, deux solutions sont acceptables :

• envoyer tous les flux vers un seul hyperviseur ;
• répartir les flux entre les hyperviseurs.

Le second choix permet d’obtenir un répartiteur de charge L3. Avec la configuration ci-dessus, pour chaque préfixe, le réflecteur va choisir un seul chemin et redistribuer celui-ci. Ainsi, un seul hyperviseur recevra les paquets. Pour obtenir une répartition de charge, il faut redistribuer l’ensemble des chemins possibles (RFC 7911)¹³ :

set protocols bgp group public-v4 family inet  unicast add-path send path-count 4
set protocols bgp group public-v6 family inet6 unicast add-path send path-count 4

Voici un extrait de show route montrant quelques routes « simples » ainsi qu’une route anycast :

> show route protocol bgp
inet.0: 6 destinations, 7 routes (7 active, 1 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0        *[BGP/170] 00:09:01, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.1 via em1.90
192.0.2.15/32    *[BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.101 via em1.90
203.0.113.1/32   *[BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.101 via em1.90
203.0.113.6/32   *[BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.102 via em1.90
203.0.113.18/32  *[BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.103 via em1.90
203.0.113.10/32  *[BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.101 via em1.90
                  [BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.102 via em1.90

La configuration complète est disponible sur GitHub. Des configurations similaires pour GoBGP, BIRD ou FRR (sur Cumulus Linux) sont également disponibles¹⁴. La configuration pour le domaine de routage privé est identique. Pour éviter d’investir dans du matériel dédié pour les réflecteurs, il est possible de convertir certains commutateurs de baie à cet usage.

Configuration de l’hyperviseur

Passons maintenant à la dernière étape : la configuration de l’hyperviseur. BIRD (1.6.x) est utilisé en tant que démon BGP. Il maintient trois tables de routage internes (public, private and local-out). Nous définissons un patron avec les propriétés communes pour se connecter à un réflecteur :

template bgp rr_client {
  local as 65000;   # ASN local correspond à l'ASN des réflecteurs
  import all;       # Accepte toutes les routes reçues
  export all;       # Envoie toutes les routes de la table
  next hop self;    # Modifie le saut suivant avec l'IP de la session BGP
  bfd yes;          # Active BFD
  direct;           # Pair directement connecté
  ttl security yes; # GTSM activé
  add paths rx;     # Accepte ADD-PATH en réception

  # Réétablissement rapide des sessions BGP
  connect delay time 1;
  connect retry time 5;
  error wait time 1,5;
  error forget time 10;
}

table public;
protocol bgp RR1_public from rr_client {
  neighbor 198.51.100.126 as 65000;
  table public;
}
# […]

Avec la configuration ci-dessus, toutes les routes de la table public de BIRD sont envoyées au réflecteur 198.51.100.126. Toutes les routes reçues sont acceptées. Il nous reste à connecter la table public de BIRD à celle du noyau¹⁵ :

protocol kernel kernel_public {
  persist;
  scan time 10;
  import filter {
    # Accepte n'importe quelle route du noyau
    # sauf celle de dernier secours
    if krt_metric < 4294967294 then accept;
    reject;
  };
  export all;      # Envoie toutes les routes au noyau
  learn;           # Apprend les routes autres que celles de BIRD
  merge paths yes; # Utilise des routes ECMP si besoin
  table public;    # Nom de la table de routage dans BIRD
  kernel table 90; # Numéro de la table de routage dans le noyau
}

Il faut également activer BFD sur toutes les interfaces :

protocol bfd {
  interface "*" {
    interval 100ms;
    multiplier 5;
  };
}

Afin d’éviter qu’un encombrement temporaire de la table de suivi de Netfilter n’impacte BFD, il est prudent de désactiver le suivi de connexions pour ces paquets :

ip46tables -t raw -A PREROUTING -p udp --dport 3784 \
  -m addrtype --dst-type LOCAL -j CT --notrack
ip46tables -t raw -A OUTPUT -p udp --dport 3784 \
  -m addrtype --src-type LOCAL -j CT --notrack

Il faut également ajouter :

• la configuration de la table local-out ;
• la configuration de la table private ;
• la configuration pour IPv6¹⁶.

Une fois les sessions BGP établies, on peut vérifier les routes apprises :

$ ip route show table public proto bird
default
        nexthop via 198.51.100.1 dev eth0.public weight 1
        nexthop via 198.51.100.254 dev eth1.public weight 1
203.0.113.6
        nexthop via 198.51.100.102 dev eth0.public weight 1
        nexthop via 198.51.100.202 dev eth1.public weight 1
203.0.113.18
        nexthop via 198.51.100.103 dev eth0.public weight 1
        nexthop via 198.51.100.203 dev eth1.public weight 1

Performance

Avec de nombreuses routes, on peut se soucier de la quantité de mémoire utilisée par Linux. Elle est très raisonnable :

• 128 Mio permettent de gérer 1 million de routes IPv4 ;
• 512 Mio permettent de gérer 1 million de routes IPv6.

Les chiffres doivent être doublés pour prendre en compte la mémoire utilisée par BIRD. En ce qui concerne les temps de recherche d’une route, les performances sont aussi excellentes avec IPv4 et très bonnes avec IPv6 :

• 30 ns par recherche avec 1 million de routes IPv4 ;
• 1.25 µs par recherche avec 1 million de routes IPv6.

Ainsi, l’impact de laisser la gestion d’un très grand nombre de routes à Linux est très faible. Pour plus de détails sur le sujet, voyez « Fonctionnement de la table de routage IPv4 sous Linux » et « Fonctionnement de la table de routage IPv6 sous Linux ».

Filtrage par la source

Pour éviter l’usurpation d’adresse IP, le filtrage par la source (reverse-path filtering) est activé sur chaque interface virtuelle : Linux va vérifier la légitimité de chaque IP source en vérifiant qu’une réponse serait renvoyée sur la même interface. Cela interdit toute tentative d’usurpation de la part d’une machine virtuelle.

Pour IPv4, il est possible d’activer cette fonctionnalité à travers un sysctl¹⁷ ou à travers Netfilter. Pour IPv6, seule la dernière option est disponible.

# Pour IPv6, utilise Netfilter
ip6tables -t raw -N RPFILTER
ip6tables -t raw -A RPFILTER -m rpfilter -j RETURN
ip6tables -t raw -A RPFILTER -m rpfilter --accept-local \
  -m addrtype --dst-type MULTICAST -j DROP
ip6tables -t raw -A RPFILTER -m limit --limit 5/s --limit-burst 5 \
  -j LOG --log-prefix "NF: rpfilter: " --log-level warning
ip6tables -t raw -A RPFILTER -j DROP
ip6tables -t raw -A PREROUTING -i vnet+ -j RPFILTER

# Pour IPv4, utilise les sysctls
sysctl -qw net.ipv4.conf.all.rp_filter=0
sysctl -qw net.ipv4.conf.all.rp_filter=0
for iface in /sys/class/net/vnet*; do
    sysctl -qw net.ipv4.conf.${iface##*/}.rp_filter=1
done

Il n’est pas utile de s’inquiéter d’une usurpation sur le L2, l’attaquant n’y gagnerait aucun avantage.

Leurrer les machines virtuelles

Un point important est de s’assurer que les machines virtuelles continuent de penser qu’elles sont rattachées à un réseau L2 classique (une IP, un sous-réseau, une passerelle).

La première étape consiste à leur fournir la passerelle par défaut. Sur l’hyperviseur, il suffit d’assigner l’IP associée à l’interface virtuelle correspondante :

ip addr add 203.0.113.254/32 dev vnet5 scope link

Le but de cette manœuvre est de s’assurer que Linux répondra aux requêtes ARP concernant cette IP. La configuration d’un /32 est suffisante et il ne faut pas configurer un sous-réseau plus grand : Linux installerait la route correspondante sur cette interface, ce qui serait incorrect¹⁸.

Pour IPv6, ce n’est pas utile car les adresses de lien local sont utilisées comme passerelle.

Une machine virtuelle peut également vouloir échanger des paquets avec des machines partageant le même sous-réseau IP. L’hyperviseur va répondre aux requêtes ARP à leur place. Une fois que le trafic IP est reçu, il lui suffira alors de le router normalement. Cela peut se faire en activant le proxy ARP sur l’interface virtuelle :

sysctl -qw net.ipv4.conf.vnet5.proxy_arp=1
sysctl -qw net.ipv4.neigh.vnet5.proxy_delay=0

Pour IPv6, le proxy NDP de Linux est beaucoup moins pratique. À la place, le démon ndppd va gérer efficacement cette tâche. Pour chaque interface, nous utilisons la configuration suivante :

proxy vnet5 {
  rule 2001:db8:cb00:7100::/64 {
    static
  }
}

ndppd n’usurpe pas l’adresse source et certains systèmes sont plus pointilleux à ce sujet. Par conséquent, une adresse adéquate doit être configurée sur chaque interface :

ip addr add 2001:db8:cb00:7100::1/64 dev vnet5 noprefixroute nodad

En ce qui concerne le DHCP, certains démons peuvent être contrariés par l’adresse en /32 associée à l’interface. Toutefois, dnsmasq accepte de s’y faire. Si besoin, l’écriture d’un démon DHCP est relativement triviale. Pour IPv6, si l’adresse assignée est de type EUI-64, radvd fonctionne parfaitement avec cette configuration :

interface vnet5 {
  AdvSendAdvert on;
  prefix 2001:db8:cb00:7100::/64 {
    AdvOnLink on;
    AdvAutonomous on;
    AdvRouterAddr on;
  };
};

Conclusion et avenir

La configuration présentée ici fonctionne avec BIRD 1.6.3 et Linux 3.15 ou plus récent. Elle permet de s’affranchir des limitations inhérentes des réseaux L2 en termes de flexibilité ou de disponibilité tout en restant transparent du point de vue des machines virtuelles hébergées. En faisant reposer l’effort de routage sur Linux, la solution est également économique car le matériel existant peut être réutilisé. Enfin, l’exploitation d’un tel réseau reste simple après avoir compris les bases (règles de routage, tables de routage et sessions BGP).

Il existe plusieurs améliorations potentielles :

Utilisation des VRF

À partir de Linux 4.3, les domaines virtuels de routage L3 (VRF) permettent d’associer des interfaces à des tables de routage. Nous pourrions donc définir trois VRF : public, private et local-out. Cela permettrait d’améliorer les performances en retirant la nécessité de parcourir plusieurs règles de routage (cependant, avant Linux 4.8, les performances sont dégradées en raison de la non-utilisation des fonctionnalités d’accélération, voir le commit 7889681f4a6c). Pour plus d’informations, reportez vous à la documentation du noyau.

Routage L3 de bout en bout

Plutôt que de reposer sur une fabrique L2, la configuration BGP peut être améliorée et simplifiée en utilisant un certain nombre de mécanismes d’autoconfiguration. Cumulus a publié un livret sur le sujet : « BGP in the datacenter ». Toutefois, cela nécessite que toutes les implémentations BGP utilisées supportent ces fonctionnalités. Sur les hyperviseurs, cela impose l’utilisation de FRR et sur les équipements réseau, seul Cumulus Linux remplit les critères adéquats.

Utilisation de BGP LLGR

Utiliser BFD avec des temps de réaction courts permet d’invalider très rapidement un chemin non fonctionnel. En contre-partie, en cas de congestion ou de charge élevée, des paquets BFD peuvent être perdus rendant l’hyperviseur et les machines qu’il héberge indisponibles jusqu’au rétablissement des sessions BGP. Certaines implémentations de BGP supportent le Long-Lived BGP Graceful Restart, une extension conservant les routes perdues mais avec une priorité plus faible (voir draft-uttaro-idr-bgp-persistence-03). C’est une solution idéale pour notre problème : les routes perdues ne sont utilisées qu’en dernier secours quand tous les liens sont devenus indisponibles. Actuellement, aucune implémentation libre n’existe. Jetez un œil sur « BGP LLGR : sessions BGP fiables et réactives » pour plus de détails.

Habituellement, les performances d’un sous-système du noyau Linux sont mesurées à travers un processus externe (local ou distant). Selon le point d’entrée utilisé, de nombreuses fonctions peuvent être impliquées. Pour tester les performances d’une seule fonction, une solution est d’écrire un module noyau.

Module noyau minimal

Supposons que l’on désire mesurer les performances de la fonction fib_lookup() qui permet de rechercher une route IPv4. La fonction noyau suivante exécute 1000 recherches pour 8.8.8.8 et retourne une moyenne¹. Elle utilise la fonction get_cycles() pour calculer le temps d’exécution.

/* Exécute le test pour fib_lookup() and place
   le résultat dans `buf`. */
static int do_bench(char *buf)
{
    unsigned long long t1, t2;
    unsigned long long total = 0;
    unsigned long i;
    unsigned count = 1000;
    int err = 0;
    struct fib_result res;
    struct flowi4 fl4;

    memset(&fl4, 0, sizeof(fl4));
    fl4.daddr = in_aton("8.8.8.8");

    for (i = 0; i < count; i++) {
        t1 = get_cycles();
        err |= fib_lookup(&init_net, &fl4, &res, 0);
        t2 = get_cycles();
        total += t2 - t1;
    }
    if (err != 0)
        return scnprintf(buf, PAGE_SIZE, "err=%d msg=\"lookup error\"\n", err);
    return scnprintf(buf, PAGE_SIZE, "avg=%llu\n", total / count);
}

Nous devons placer cette fonction dans un module noyau. Le code suivant déclare un dossier sysfs contenant un pseudo-fichier run. Quand l’utilisateur consulte ce fichier, le module exécute le test et retourne le résultat en tant que contenu.

#define pr_fmt(fmt) "kbench: " fmt

#include <linux/kernel.h>
#include <linux/version.h>
#include <linux/module.h>
#include <linux/inet.h>
#include <linux/timex.h>
#include <net/ip_fib.h>

/* Quand un utilisateur consulte le fichier "run", exécute
   la fonction de test. */
static ssize_t run_show(struct kobject *kobj,
                        struct kobj_attribute *attr,
                        char *buf)
{
    return do_bench(buf);
}

static struct kobj_attribute run_attr = __ATTR_RO(run);
static struct attribute *bench_attributes[] = {
    &run_attr.attr,
    NULL
};
static struct attribute_group bench_attr_group = {
    .attrs = bench_attributes,
};
static struct kobject *bench_kobj;

int init_module(void)
{
    int rc;
    /* ❶ Création d'un kobject "kbench" dans /sys/kernel. */
    bench_kobj = kobject_create_and_add("kbench", kernel_kobj);
    if (!bench_kobj)
        return -ENOMEM;

    /* ❷ Création des fichiers associés au kobject. */
    rc = sysfs_create_group(bench_kobj, &bench_attr_group);
    if (rc) {
        kobject_put(bench_kobj);
        return rc;
    }

    return 0;
}

void cleanup_module(void)
{
    kobject_put(bench_kobj);
}

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Microbenchmark for fib_lookup()");

En ❶, kobject_create_and_add() crée un nouveau kobject appelé kbench. Un kobject est l’abstraction derrière le système de fichiers sysfs. Ce kobject sera visible en tant que /sys/kernel/kbench/.

En ❷, sysfs_create_group() attache un ensemble d’attributs au kobject. Ceux-ci se matérialisent comme des fichiers dans /sys/kernel/kbench/. Nous n’en déclarons qu’un, run, avec la macro __ATTR_RO. Cet attribut est en lecture seule (0444) et quand un utilisateur tente d’en récupérer le contenu, la fonction run_show() est invoquée avec un tampon de PAGE_SIZE octets comme dernier argument. Elle doit retourner le nombre d’octets effectivement écrits.

Pour plus de détails, consultez la documentation du noyau et l’exemple associé. De nombreux exemples sur le web (incluant celui-ci) peuvent être partiellement obsolètes².

Le Makefile suivant permet de compiler l’exemple :

# Kernel module compilation
KDIR = /lib/modules/$(shell uname -r)/build
obj-m += kbench_mod.o
kbench_mod.ko: kbench_mod.c
    make -C $(KDIR) M=$(PWD) modules

Après exécution de make, vous devez obtenir un fichier kbench_mod.ko :

$ modinfo kbench_mod.ko
filename:       /home/bernat/code/…/kbench_mod.ko
description:    Microbenchmark for fib_lookup()
license:        GPL
depends:
name:           kbench_mod
vermagic:       4.14.0-1-amd64 SMP mod_unload modversions

Il convient de le charger et d’exécuter le test :

$ insmod ./kbench_mod.ko
$ ls -l /sys/kernel/kbench/run
-r--r--r-- 1 root root 4096 déc.  10 16:05 /sys/kernel/kbench/run
$ cat /sys/kernel/kbench/run
avg=75

Le résultat est un nombre de cycles. Pour obtenir un temps approximatif, on le divise par la fréquence du processeur en gigahertz (25 ns pour un processeur cadencé à 3 GHz)³.

Paramétrisation

Le module utilise deux constantes : le nombre de boucles et la destination à tester. En les exposant comme des attributs supplémentaires de notre kobject et en définissant une paire de fonctions pour les consulter et les modifier, on permet à l’utilisateur de les manipuler :

static unsigned long loop_count      = 5000;
static u32           flow_dst_ipaddr = 0x08080808;

static DEFINE_MUTEX(kb_lock);

/* Retourne le nombre de boucles. */
static ssize_t loop_count_show(struct kobject *kobj,
                               struct kobj_attribute *attr,
                               char *buf)
{
    ssize_t res;
    mutex_lock(&kb_lock);
    res = scnprintf(buf, PAGE_SIZE, "%lu\n", loop_count);
    mutex_unlock(&kb_lock);
    return res;
}

/* Modifie le nombre de boucles. */
static ssize_t loop_count_store(struct kobject *kobj,
                                struct kobj_attribute *attr,
                                const char *buf,
                                size_t count)
{
    unsigned long val;
    int err = kstrtoul(buf, 0, &val);
    if (err < 0)
        return err;
    if (val < 1)
        return -EINVAL;
    mutex_lock(&kb_lock);
    loop_count = val;
    mutex_unlock(&kb_lock);
    return count;
}

/* Retourne l'adresse de destination. */
static ssize_t flow_dst_ipaddr_show(struct kobject *kobj,
                                    struct kobj_attribute *attr,
                                    char *buf)
{
    ssize_t res;
    mutex_lock(&kb_lock);
    res = scnprintf(buf, PAGE_SIZE, "%pI4\n", &flow_dst_ipaddr);
    mutex_unlock(&kb_lock);
    return res;
}

/* Modifie l'adresse de destination. */
static ssize_t flow_dst_ipaddr_store(struct kobject *kobj,
                                     struct kobj_attribute *attr,
                                     const char *buf,
                                     size_t count)
{
    mutex_lock(&kb_lock);
    flow_dst_ipaddr = in_aton(buf);
    mutex_unlock(&kb_lock);
    return count;
}

/* Définition des deux nouveaux attributs. */
static struct kobj_attribute loop_count_attr      = __ATTR_RW(loop_count);
static struct kobj_attribute flow_dst_ipaddr_attr = __ATTR_RW(flow_dst_ipaddr);
static struct kobj_attribute run_attr             = __ATTR_RO(run);
static struct attribute *bench_attributes[] = {
    &loop_count_attr.attr,
    &flow_dst_ipaddr_attr.attr,
    &run_attr.attr,
    NULL
};

L’adresse IPv4 est stockée dans un entier 32 bits mais affichée et modifiée en utilisant la notation en quadruplet. Le noyau fournit de sympathiques fonctions à cet usage.

Après ce changement, deux nouveaux fichiers apparaissent dans le dossier /sys/kernel/kbench. Nous pouvons lire et modifier leurs contenus.

# cd /sys/kernel/kbench
# ls -l
-rw-r--r-- 1 root root 4096 déc.  10 19:10 flow_dst_ipaddr
-rw-r--r-- 1 root root 4096 déc.  10 19:10 loop_count
-r--r--r-- 1 root root 4096 déc.  10 19:10 run
# cat loop_count
5000
# cat flow_dst_ipaddr
8.8.8.8
# echo 9.9.9.9 > flow_dst_ipaddr
# cat flow_dst_ipaddr
9.9.9.9

Il ne nous reste qu’à modifier la fonction do_bench() pour utiliser ces variables :

static int do_bench(char *buf)
{
    /* … */
    mutex_lock(&kb_lock);
    count = loop_count;
    fl4.daddr = flow_dst_ipaddr;
    mutex_unlock(&kb_lock);

    for (i = 0; i < count; i++) {
        /* … */

Meilleures statistiques

Actuellement, seule une moyenne est calculée. Cette valeur est habituellement peu significative :

• Un petit nombre de données aberrantes peut augmenter sensiblement la moyenne. Une aberration peut apparaître lorsque la fonction testée est préemptée du CPU. Cela ne se produit pas souvent si celle-ci est de courte durée (moins d’une milliseconde) mais lorsque cela a lieu, la différence est de l’ordre de plusieurs millisecondes, ce qui peut représenter plusieurs ordres de grandeur et fausser totalement la moyenne. Il est donc préférable d’utiliser la médiane⁴.

• La distribution des valeurs peut être asymétrique et avoir plusieurs maxima locaux. Calculer plusieurs percentiles ou afficher un graphe de distribution est alors utile.

Pour calculer des statistiques supplémentaires, les résultats sont placés dans un tableau.

static int do_bench(char *buf)
{
    unsigned long long *results;
    /* … */

    results = kmalloc(sizeof(*results) * count, GFP_KERNEL);
    if (!results)
        return scnprintf(buf, PAGE_SIZE, "msg=\"no memory\"\n");

    for (i = 0; i < count; i++) {
        t1 = get_cycles();
        err |= fib_lookup(&init_net, &fl4, &res, 0);
        t2 = get_cycles();
        results[i] = t2 - t1;
    }

    if (err != 0) {
        kfree(results);
        return scnprintf(buf, PAGE_SIZE, "err=%d msg=\"lookup error\"\n", err);
    }
    /* Calcule et affiche les statistiques */
    display_statistics(buf, results, count);

    kfree(results);
    return strnlen(buf, PAGE_SIZE);
}

Il nous faut ensuite une fonction pour calculer des percentiles :

static unsigned long long percentile(int p,
                                     unsigned long long *sorted,
                                     unsigned count)
{
    int index = p * count / 100;
    int index2 = index + 1;
    if (p * count % 100 == 0)
        return sorted[index];
    if (index2 >= count)
        index2 = index - 1;
    if (index2 < 0)
        index2 = index;
    return (sorted[index] + sorted[index+1]) / 2;
}

Cette fonction nécessite un tableau trié en entrée. Le noyau fournit à cet effet une fonction de tri par tas, sort(). Une autre valeur utile est la déviation par rapport à la médiane. La fonction ci-dessous calcule la déviation absolue médiane⁵ :

static unsigned long long mad(unsigned long long *sorted,
                              unsigned long long median,
                              unsigned count)
{
    unsigned long long *dmedian = kmalloc(sizeof(unsigned long long) * count,
                                          GFP_KERNEL);
    unsigned long long res;
    unsigned i;

    if (!dmedian) return 0;
    for (i = 0; i < count; i++) {
        if (sorted[i] > median)
            dmedian[i] = sorted[i] - median;
        else
            dmedian[i] = median - sorted[i];
    }
    sort(dmedian, count, sizeof(unsigned long long), compare_ull, NULL);
    res = percentile(50, dmedian, count);
    kfree(dmedian);
    return res;
}

Ces deux fonctions nous permettent de fournir des statistiques supplémentaires :

static void display_statistics(char *buf,
                               unsigned long long *results,
                               unsigned long count)
{
    unsigned long long p95, p90, p50;

    sort(results, count, sizeof(*results), compare_ull, NULL);
    if (count == 0) {
        scnprintf(buf, PAGE_SIZE, "msg=\"no match\"\n");
        return;
    }

    p95 = percentile(95, results, count);
    p90 = percentile(90, results, count);
    p50 = percentile(50, results, count);
    scnprintf(buf, PAGE_SIZE,
          "min=%llu max=%llu count=%lu 95th=%llu 90th=%llu 50th=%llu mad=%llu\n",
          results[0],
          results[count - 1],
          count,
          p95,
          p90,
          p50,
          mad(results, p50, count));
}

Enfin, ajoutons un graphique de la distribution (incluant la fonction de répartition) :

min=72 max=33364 count=100000 95th=154 90th=142 50th=112 mad=6
    value │                      ┊                         count
       72 │                                                   51
       77 │▒                                                3548
       82 │▒▒░░                                             4773
       87 │▒▒░░░░░                                          5918
       92 │░░░░░░░                                          1207
       97 │░░░░░░░                                           437
      102 │▒▒▒▒▒▒░░░░░░░░                                  12164
      107 │▒▒▒▒▒▒▒░░░░░░░░░░░░░░                           15508
      112 │▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░               23014
      117 │▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░             6297
      122 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░              905
      127 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░           3845
      132 │▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░       6687
      137 │▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░     4884
      142 │▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   4133
      147 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  1015
      152 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  1123

Validité

Bien que les tests fournissent quelques chiffres attrayants, leur validité peut laisser dubitatif. Il y a plusieurs écueils à considérer :

Code mort

Un compilateur peut retirer le code non utilisé. Dans notre exemple, nous combinons le résultat de la fonction testée avec une variable pour éviter ceci.

Échauffement

La mise en place des données initiales peut affecter négativement le test. En C, c’est un phénomène peu probable. Toutefois, l’ajout d’une phase d’échauffement reste possible.

Jeu de données trop petit

Si le test utilise toujours les mêmes arguments en entrée, le résultat peut être calculé entièrement à partir de données en cache. Cela avantage le test indûment. Il convient donc d’itérer sur un grand ensemble de données.

Jeu de données trop régulier

Quand les arguments donnés en entrée sont trop réguliers, le résultat peut également être impacté positivement : chaque test peut être dérivé en utilisant les données du test précédent (qui se trouvent en cache). Dans notre exemple, les routes sont organisées dans un arbre et il convient donc de ne pas parcourir linéairement l’espace d’adresses. Ce dernier peut être exploré aléatoirement en utilisant un simple générateur congruentiel linéaire.

Coûts additionnels

Lorsque la fonction testée s’exécute en quelques nanosecondes, le coût induit par l’infrastructure de test peut s’avérer trop élevé. La méthode présentée ici implique un coût d’environ 5 nanosecondes. La fonction get_cycles() est une mince couche autour de l’instruction RDTSC qui permet d’obtenir le nombre de cycles depuis la dernière mise à zéro du processeur. Elle est aussi disponible en version virtualisée pour un coût similaire lorsque le test est effectué sur une machine virtuelle. Pour mesurer une fonction avec une précision accrue, une solution est d’évaluer le temps d’exécution d’une boucle. Toutefois, les boucles apportent leur propre coût, notamment quand il faut calculer des arguments différents pour chaque itération. Elles cachent de plus la distribution des résultats et les compilateurs aiment les optimiser.

Préemption

Pendant l’exécution du test, le CPU peut être préempté pour une autre tâche. Lorsque la fonction testée prend moins d’une milliseconde, c’est un cas particulièrement rare qui est filtré par l’utilisation des percentiles.

Bruit

D’autres processus (ou d’autres machines virtuelles) peuvent accaparer le CPU de manière peu prévisible d’un test à l’autre. Il n’est donc pas souhaitable de faire tourner de tels tests dans un nuage public. D’un autre côté, un test peut être rendu plus réaliste par ajout d’un bruit contrôlé. Dans notre exemple, la recherche d’une route ne représente qu’une petite partie du travail nécessaire pour router un paquet. Mesurer cette fonction dans une boucle serrée affecte positivement le test.

Synchronisation de tests parallèles

Bien qu’il soit possible de lancer plusieurs tests en parallèle, il est difficile de s’assurer qu’ils s’exécutent bien tous en même temps. Cela fausse les résultats car certains tests tournent sans contention. Idéalement, chaque test devrait tourner à vide jusqu’à ce que tous les tests soient prêts. Cela ne semble pas une modification triviale.

En conclusion, le module de test présenté ici est plutôt primitif (notamment par rapport à des outils tels que JMH pour Java) mais il peut produire des résultats concluants tels que ceux présentés dans « Fonctionnement de la table de routage IPv4 sous Linux » et « Fonctionnement de la table de routage IPv6 sous Linux ».

Alternative

L’utilisation d’un outil de tracing constitue une approche alternative. Pour mesurer le temps de recherche des routes IPv4, nous pouvons faire tourner le processus suivant :

while true; do
  ip route get $((RANDOM%100)).$((RANDOM%100)).$((RANDOM%100)).5
  sleep 0.1
done

Ensuite, nous instrumentons la fonction __fib_lookup() via eBPF (à l’aide de BCC):

$ sudo funclatency-bpfcc __fib_lookup
Tracing 1 functions for "__fib_lookup"... Hit Ctrl-C to end.
^C
     nsecs               : count     distribution
         0 -> 1          : 0        |                    |
         2 -> 3          : 0        |                    |
         4 -> 7          : 0        |                    |
         8 -> 15         : 0        |                    |
        16 -> 31         : 0        |                    |
        32 -> 63         : 0        |                    |
        64 -> 127        : 0        |                    |
       128 -> 255        : 0        |                    |
       256 -> 511        : 3        |*                   |
       512 -> 1023       : 1        |                    |
      1024 -> 2047       : 2        |*                   |
      2048 -> 4095       : 13       |******              |
      4096 -> 8191       : 42       |********************|

Actuellement, le coût de l’instrumentation est très élevé et ne permet pas d’obtenir de résultats pertinents. Cela peut changer à l’avenir lorsque Linux ajoutera la possibilité de mesurer la latence entre deux évènements.