J'aimerais utiliser le cache SSD de linux (dm-cache ou bcache) avec les serveurs de production de Debian Jessie. (noyau 3.16)
Ma question : Les modules dm-cache et bcache sont-ils fiables sous linux 3.16 ? Dois-je mettre à jour mon noyau vers une version plus récente ?
J'ai également trouvé ce message inquiétant à propos de bcache : https://lkml.org/lkml/2015/12/22/154
Notez que je comprends parfaitement ce qu'implique le choix du mode de mise en cache (write-back/write-through) en termes de fiabilité et de perte de données, ma question porte plutôt sur les bogues logiciels dans ces modules.
Février 2018 suivi après plus d'un an d'utilisation de bcache sur un serveur d'intégration continue (instance jenkins exécutant beaucoup de jobs intensifs !).
Configuration du serveur (pile de stockage essentiellement)
Matériel :
- 2 x 480GB SSD (Samsung SM863 enterprise grade MLC)
- 2 x 4TB HDD (Seagate Constellation ES.3 SATA)
- Dell R730 - Dual Xeon E52670 - 128 Go de RAM
- NON RAID matériel, pas de cache d'écriture matériel sauvegardé par batterie/flash, c'est là que la fonction writeback du bcache devient intéressante.
Logiciel :
- configuré en septembre 2016, jamais redémarré
- Debian Jessie avec le noyau 4.6 (provenant du portage officiel jessie au moment de la dernière mise à jour)
- logiciel MD raid 10
- 1 périphérique raid10 pour les 2 SSD
- 1 dispositif raid10 pour les 2 disques durs
- 2 LVM VG sur les 2 périphériques raid
- un périphérique de "mise en cache" bcache créé sur un volume logique du VG SSD_RAID10
- un périphérique de "sauvegarde" bcache créé sur un volume logique du VG HDD_RAID10
- le cache bcache configuré comme réécriture
Charge de travail
- de nombreux jobs jenkins (intégration continue)
- des tâches à forte intensité de calcul mélangées à des périodes à forte intensité d'E/S
- avant d'utiliser bcache de telles périodes où s'élève régulièrement la latence moyenne des E/S au-dessus de 5 secondes ( !!!)
- la charge de travail réelle sur ce serveur a commencé il y a seulement 1 an (~Feb 2017)
Quantité d'E/S émise sur le périphérique bcache selon /proc/diskstats)
- 350 To écrits
- 6 To de lecture (j'ai vérifié deux fois, je pense que la grande quantité de RAM aide beaucoup à mettre en cache les lectures dans la couche VFS).
Résultat
- stable ! la machine n'a jamais dû être redémarrée (temps de fonctionnement de 525 jours), aucune corruption n'a été détectée.
- le taux de réussite est élevé ! 78% en moyenne sur l'ensemble de l'année, et en progression : plus de 80% ces derniers mois.
- Le writeback aide beaucoup : la latence du disque est maintenant inférieure d'un ordre de grandeur, malheureusement je n'ai pas de mesures précises à ce sujet, mais les calculs ne sont plus bloqués par les rafales d'écriture. La quantité de données sales dépasse les 5 Go, alors qu'un cache d'écriture RAID matériel a généralement une taille comprise entre 512 Mo et 1 Go.)
Conclusion
- bcache est rock stable sur cette configuration ( mais 1 machine, 1 configuration, 1 machine année, ce n'est pas suffisant pour généraliser mais c'est un bon début !)
- bcache est très performant sur cette charge de travail et le mode writeback semble remplacer efficacement un write-cache RAID matériel (mais gardez à l'esprit que la fiabilité en cas de coupure de courant n'a pas été testée).
- à mon avis, bcache est sous-estimé, et des solutions intéressantes pourraient être mises en place en l'utilisant, mais notez aussi que l'auteur original développe maintenant bcachefs (un système de fichiers basé sur le travail de bcache) et n'améliore plus bcache.
