bcache vs dm-cache : mise en cache SSD sous Linux

Les SSD sont rapides mais coûteux au gigaoctet. Les disques durs (HDD) sont bon marché mais lents. Linux vous offre deux outils au niveau du noyau pour les combiner : bcache et dm-cache. Tous deux utilisent un SSD comme cache transparent devant un disque dur (HDD) plus grand, mais ils diffèrent par leur architecture, leurs exigences de configuration et les situations dans lesquelles ils sont les plus performants.

Fonctionnement de bcache

Bcache est intégré au noyau Linux depuis la version 3.10 (juin 2013). Il opère au niveau de la couche bloc, ce qui lui permet de fonctionner avec n'importe quel système de fichiers prenant en charge les UUID.

En interne, bcache utilise une structure hybride B+ tree/log. Il divise le stockage SSD en compartiments de taille fixe (128 Ko à 2 Mo), alignés sur les limites des blocs d’effacement. Cela convertit les écritures aléatoires en écritures séquentielles, ce qui réduit l’amplification d’écriture et prolonge la durée de vie du SSD. Les opérations d’E/S séquentielles supérieures à 4 Mo contournent automatiquement le cache, permettant au SSD de se concentrer sur les modèles d’accès aléatoire où il apporte le plus de valeur.

Bcache surveille également la latence du SSD en temps réel. Si la latence en lecture dépasse 2 ms ou si la latence en écriture dépasse 20 ms, il limite le trafic pour empêcher le périphérique de cache de devenir un goulot d'étranglement.

Configuration

Installez bcache-tools, puis formatez votre périphérique de stockage et votre périphérique de cache :

make-bcache -B /dev/sdb          # format HDD as backing device
make-bcache -C /dev/sdc          # format SSD as cache device
echo <UUID> > /sys/block/bcache0/bcache/attach   # attach cache

Le réglage à la volée s'effectue via l' /sys/block/bcache<N>/bcache/ interface sysfs, où vous pouvez ajuster les modes de mise en cache, les seuils d'E/S séquentielles et les objectifs de latence. Pour les matrices RAID, utilisez --data-offset pour l'aligner sur la largeur de bande.

Le hic : la configuration est destructive. Les deux périphériques doivent être formatés en tant que cibles bcache ; vous ne pouvez donc pas ajouter bcache à un système de fichiers existant sans l'effacer au préalable. Les périphériques bcache ne peuvent pas non plus être redimensionnés après leur création.

Performances

La consolidation des écritures de Bcache lui confère d'excellentes performances en écriture aléatoire. Lors de tests de performance, il a atteint environ 18 500 IOPS en écriture aléatoire 4K, contre 12 200 IOPS sur le SSD brut seul. Le débit en lecture aléatoire peut atteindre environ 1 000 000 IOPS avec un matériel adapté.

Pour les charges de travail chiffrées, superposez dm-crypt au /dev/bcache<N> périphérique plutôt que de chiffrer individuellement les disques sous-jacents. Cela offre généralement de meilleures performances car Bcache peut toujours consolider les écritures avant le chiffrement.

Fonctionnement de dm-cache

dm-cache est une cible Device Mapper qui se superpose à un volume logique existant. Il utilise trois sous-périphériques : un périphérique d'origine (disque dur), un périphérique de cache (SSD ou NVMe) et un périphérique de métadonnées qui suit l'emplacement des blocs et les états de modification. La politique de cache par défaut est smq (Stochastic Multi-Queue), qui identifie les données fréquemment utilisées dans des charges de travail mixtes.

Principal avantage : dm-cache peut être superposé à un volume LVM en production sans détruire les données existantes. Vous pouvez également le redimensionner à l'aide des commandes LVM standard.

Configuration avec LVM

La manière la plus pratique de configurer dm-cache est d'utiliser lvmcache. Une dmsetup est possible, mais elle est source d'erreurs et ne survit pas aux redémarrages. L'approche LVM :

1. Créez des volumes physiques (PV) à la fois sur le disque dur et sur le SSD.
2. Ajoutez les deux PV à un seul groupe de volumes (VG).
3. Créez trois volumes logiques : un pour les données de sauvegarde (disque dur), un pour le cache (SSD) et un pour les métadonnées (SSD).
4. Regroupez les volumes logiques de cache et de métadonnées dans un pool de cache :
   lvconvert --type cache-pool --poolmetadata <meta_lv> <cache_lv>
5. Attachez le pool à l'origine :
   lvconvert --type cache --cachepool <pool_lv> <data_lv>

Une chose à surveiller : montez le système de fichiers via son /dev/mapper/ chemin d'accès, et non par son UUID. Le montage par UUID peut contourner la couche de cache et accéder directement au périphérique d'origine.

Performances et mémoire

En mode writeback avec une charge de travail Zipf de 90/10 en lecture/écriture, dm-cache a atteint des vitesses de lecture d'environ 193 Mo/s et des vitesses d'écriture d'environ 21 Mo/s. Dans un autre test de performance, la mise en cache d'un disque dur de 100 Go avec une partition NVMe de 10 Go a fait passer les IOPS en écriture aléatoire de 118 à 798.

Le compromis réside dans la mémoire. La surcharge liée aux métadonnées de dm-cache dépend de la taille des blocs. Une taille de bloc de 512 octets peut consommer plus de 16 Go de RAM pour 100 Go de cache. En passant à 4 096 octets, l'utilisation de la mémoire tombe à environ 2 Go pour 100 Go. Choisissez une taille de bloc proche de votre taille moyenne d'E/S (64 Ko est un point de départ raisonnable) et assurez-vous qu'elle soit un multiple de 64 secteurs (32 Ko), dans la plage comprise entre 32 Ko et 1 Go.

Les métadonnées sont vidées à chaque écriture FLUSH ou FUA, ou au moins une fois par seconde. Pour une haute disponibilité, mettez en miroir le périphérique de métadonnées afin d'éviter un point de défaillance unique.

Modes de mise en cache

bcache et dm-cache prennent tous deux en charge les mêmes modes de mise en cache de base. Ce choix a une incidence à la fois sur les performances et sur la sécurité des données.

Le mode « Writethrough » est le réglage par défaut sûr pour les deux outils. Le mode « Writeback » est plus rapide mais présente un risque réel : si le SSD tombe en panne alors qu'il contient des données non vidées, ces données sont perdues et le système de fichiers peut être corrompu. N'utilisez le mode « Writeback » que si vous disposez de SSD redondants ou si vous pouvez tolérer une perte occasionnelle de données.

bcache vs dm-cache : lequel utiliser

Utilisez bcache lorsque vous construisez un nouveau système à partir de zéro et que vous souhaitez obtenir les meilleures performances possibles en matière d'E/S aléatoires. C'est le meilleur choix pour les charges de travail à forte intensité d'écriture, telles que les bases de données et le stockage de machines virtuelles, ainsi que pour les matrices RAID 6 où les pénalités d'écriture aléatoire sont importantes.

Utilisez dm-cache lorsque vous devez ajouter une mise en cache à un serveur déjà en production. Son intégration LVM vous permet de connecter un cache sans temps d'arrêt ni migration de données. Il est mieux adapté aux charges de travail à forte intensité de lecture et aux environnements où vous avez besoin de flexibilité pour redimensionner ou reconfigurer le stockage à la volée.

Conclusion

Ces deux outils résolvent le même problème, mais conviennent à des situations différentes. Bcache est le choix optimal en termes de performances pour les nouvelles installations. dm-cache est le choix pratique pour les systèmes LVM existants. Quel que soit votre choix, commencez par le mode « writethrough » jusqu’à ce que vous soyez sûr de la fiabilité de votre SSD, puis passez au mode « writeback » si vous avez besoin de performances d’écriture.

Si vous avez besoin de serveurs dédiés avec des configurations de mise en cache SSD, découvrez les options de serveurs dédiés de FDC.