Zfs sous linux
Si la capture de paquet est une aide indispensable dans de nombreuses situations de troubleshooting réseau et applicatif, elle présente des challenges techniques considérables en termes de stockage.
Le système de fichier ZFS, nouvellement disponible sous linux, système d’exploitation choisit par de nombreux constructeurs pour leurs sondes, pourrait améliorer les performances tout en baissant les coûts.
Alors que le 10Gbit Ethernet est devenu la norme sur les serveurs et que les liens inter-switch dans les Datacenter atteignent 40 Gbit/s et bientôt 100 Gbit/s, les technologies de stockage ont progressé beaucoup moins rapidement.
La révolution des disques SSD n’étant malheureusement pas utilisable dans les sondes de capture réseau, à cause de leur prix au Go encore beaucoup trop élevé ; les fabricants sont contraints d’utiliser les disques durs « classiques » dont les performances en lecture/écriture n’ont pas fondamentalement évoluées en 35 ans. Si sur cette période, les capacités ont été multipliées par un million pour atteindre 6/8 To sur les plus gros modèles, la vitesse moyenne d’écriture n’a progressé que d’un facteur 300 à 400 pour atteindre 150 Mo/s aujourd’hui.
Cette vitesse d’écriture et en particulier la vitesse minimale garantie pour un modèle de disque est un paramètre dimensionnant pour une sonde réseau. Elle conditionne le débit réseau maximum que la sonde peut accepter sans perdre de paquets, condition indispensable pour une analyse pertinente des données enregistrées.
Le graphique de débit en écriture séquentielle ci-dessous est celui d’un disque récent de 6 To. On remarque que si la vitesse moyenne atteint 175 Mo/s, la vitesse minimale garantie n’est que de 95 Mo/s. Cela est représentatif des modèles actuels dont les meilleurs stagnent autour de 100 Mo/s en écriture continue garantie.
Comparons ce débit garanti de 100 Mo/s à celui d’une banale interface réseau à 10 Gbit, qui, dans un scénario réaliste, peut générer 1000 Mo/s (80% d’utilisation dans un sens et 20% dans l’autre). Dans ce cas, il nous faudrait déjà 10 disques pour en enregistrer le trafic et cela sans compter les pointes de trafic et les besoins annexes de lecture/écriture tel que l’extraction de paquets ou l’administration de la sonde.
Bref, suivant l’usage de cette unique interface 10Gbit, son enregistrement peut facilement exiger 16 disques pour garantir une perte de paquet quasi-nulle. Sachant qu’un seul point de visibilité sur le réseau est rarement suffisant, on imagine la difficulté à concevoir des sondes multi-10Gbits et multi 40 Gbits à des couts raisonnables.
Dans ce cadre, que peut apporter le système de fichier ZFS ?
Il présente de très nombreux avantages par rapports aux systèmes de fichiers traditionnels plus anciens (Voir l’annexe 1 pour plus de détails) mais nous allons nous focaliser sur deux d’entre eux : la compression de donnée et la gestion du RAID.
Compresser les données est une manière simple d’accélérer l’écriture tout en améliorant la capacité de stockage.
ZFS propose une compression native, multi-threadé avec plusieurs algorithmes (les deux plus intéressant étant GZIP et LZ4) et des tailles de bloc sur les disques allant jusqu’à 1 Mo. Le choix de l’algorithme de compression permet de s’adapter à la performance de chaque cœur du processeur, Gzip est plus efficace mais plus lent, LZ4 est un peu moins efficace mais beaucoup plus rapide et dispose d’une fonction innovante « early abort » qui cesse la compression si un taux minimum de 12,5% n’est pas atteint rapidement sur le bloc, ce qui évite de gaspiller du temps processeur.
Le multi-threading permet un usage complet de tous les cœurs disponibles sur le processeur et les larges tailles de bloc en écriture favorisent à la fois la vitesse et le taux de compression. Les paquets réseau se compriment généralement bien mais le taux effectif est très variable. Les gains mesurés (voir annexe 2) pour l’algorithme GZIP sont typiquement entre 25 et 40% avec des pointes à 95% et des minimums à 5%. Des exemples de flux ne se compressant pas ou peu sont les flux audio/vidéo (visioconference, youtube, VOIP…) car ils le sont déjà ou les flux cryptés (VPN, HTTPS, SSH, TOR…) car aléatoires par définition. A l’inverse, les flux répétitifs (high frequency trading) , en mode texte (HTTP, telnet), voire, si la sonde et l’usage le permettent, les paquets tronqués (les en-têtes sont très répétitifs), se compressent très fortement.
L’autre aspect positif de la compression est d’améliorer la capacité de rétention des sondes.
Celle-ci doit être suffisante, pour que l’information concernant un incident passé ne soit pas déjà écrasée par des paquets plus récents, quand la demande d’extraction et de sauvegarde parvient à l’équipe compétente. Nous rencontrons régulièrement des sondes sous-dimensionnées de ce point de vue. Pour nous, une durée de rétention ne devrait jamais être inférieure à 72 heures et nous recommandons vivement un minimum de 84 heures. Cela permet qu’un incident passé inaperçu un vendredi matin, puisse encore être étudié en détail le lundi après-midi suivant. A l’inverse, une rétention de paquet supérieure à 8 jours n’a pas d’intérêt (au-delà, seules les statistiques sont importantes mais c’est un autre sujet)
Dernier avantage de ZFS, l’économie qu’il permet de réaliser en se passant d’une carte RAID dans les sondes. Une différence fondamentale de ZFS par rapport aux autres systèmes de fichiers plus anciens est sa nature intégrée : c’est à la fois un gestionnaire de volume, un système de fichier et un gestionnaire de RAID.
Cela permet de garantir l’intégrité des données de bout en bout, tout en améliorant les performances et en simplifiant l’administration. Cela permet aussi de fabriquer des sondes à moindre coût en utilisant uniquement les ports SAS/SATA présent sur la carte mère de la sonde. Cette économie est surtout valable pour des modèles ayant moins de 8 disques, au-delà il sera souvent nécessaire d’ajouter un contrôleur mais, même dans ce cas, un simple contrôleur sera toujours moins cher qu’une carte RAID complète.
L’innovation en matière de système de fichier marquait le pas sous Linux depuis quelques années comparée à d’autres systèmes d’exploitation open source. Désormais avec la disponibilité de ZFS sur des distributions majeures telle qu’Ubuntu server 16.04 LTS, linux dispose enfin d’un système de fichier moderne et mature. Son usage dans des enregistreurs réseaux permettrait des gains moyens de 25 à 40% et plus dans des cas spécifiques, tant en terme de vitesse d’enregistrement que de durée de rétention avec une hausse raisonnable de l’utilisation CPU et mémoire.
Annexes :
Présentation ZFS (en anglais)
https://blogs.oracle.com/orasysat/entry/so_what_makes_zfs_so
Compression de données réseau avec GZIP
