bcache sur md ou md sur bcache

bcache permet à un ou plusieurs disques durs rapides tels que des disques SSD (Flash State-based SSD) d'agir comme cache pour un ou plusieurs disques durs plus lents .

Si je comprends bien,

un SSD ^* peut être attribué pour mettre en cache plusieurs disques durs de sauvegarde, puis les périphériques mis en cache résultants peuvent être RAIDés avec mdadm
ou
plusieurs disques durs peuvent être RAIDés dans un seul périphérique md de support et le SSD affecté au cache qui

Je me demande quelle est l'approche la plus saine. Il me semble que la croissance d'un RAID5 / 6 peut être plus simple avec l'une ou l'autre technique, mais je ne sais pas laquelle!

Existe-t-il de bonnes raisons (par exemple, augmenter le stockage de sauvegarde ou autre) pour choisir une approche plutôt que l'autre (pour un grand système de fichiers non root contenant des fichiers de sauvegarde de VM)?

_{^* par "un SSD", je veux dire une sorte de périphérique SSD redondant, par exemple un RAID1 de deux SSD physiques}

Dans les deux cas, tous les disques qui bcachedoivent être formatés devront être formatés bcache- vous devrez donc soit créer un mdtableau, formater le disque résultant entièrement en tant que bcachepartition sauvegardée, le lier à son lecteur de cache et y aller, ou formater plusieurs disques bcache, liez-les à leur lecteur de cache, puis formatez les nombreux disques en une seule baie. Dans les deux cas, il y a plusieurs points de défaillance possibles qui dépendent tous de l'interopérabilité entre deux systèmes de fichiers - sans parler des fs finaux. voir ici : faites défiler vers le bas .

— mikeserv

Grâce à github.com/g2p/blocks , vous pouvez le convertir sur place, bien qu'il y ait quelques limitations à cela.

— Adam Ryczkowski

@mikeserv Je comprends tout cela, c'est pour un serveur spécialement conçu donc tout va bien. Que voulez-vous dire par "deux systèmes de fichiers"? bcache n'est pas un système de fichiers - le seul système de fichiers que j'aurai sera XFS sur le dernier périphérique bcache ou mdadm (selon l'option que je choisis).

Merci @Adam, la conversion sur place n'est pas un problème pour moi.

@mikeserv non, ce n'est pas le cas. Les systèmes de fichiers (par exemple btrfs, xfs, extN, etc.) vivent au-dessus des périphériques de blocs. mdadm et bcache fonctionnent au niveau du périphérique de bloc et non au niveau du système de fichiers (btrfs confond le problème avec sa violation de superposition, mais c'est une conversation complètement distincte).

Réponses:

Je pense que la mise en cache de l'ensemble du périphérique md est plus logique.

Mettre bcache pour mettre en cache l'ensemble du périphérique md sacrifie l'idée d'avoir un raid, car cela introduit un autre point de défaillance unique.

Les pannes OTH des disques SSD sont relativement rares et bcache peut être placé en mode writethrough/ writearound(contrairement au writebackmode), où aucune donnée n'est stockée uniquement sur le périphérique de cache, et l'échec du cache ne tue pas les informations contenues dans le raid en fait une option relativement sûre.
Un autre fait est qu'il existe une surcharge de calcul importante pour le RAID-5 logiciel; lors de la mise en cache de chaque membre du raid en rotation séparément, l'ordinateur doit toujours recalculer toutes les parités, même en cas de succès de cache
~~Évidemment, vous sacrifieriez un espace ssd coûteux, si vous mettez en cache chaque disque en rotation séparément.~~ - Sauf si vous prévoyez d'utiliser le cache ssd raidé.
Les deux options n'affectent pas relativement le temps de croissance du processus - bien que l'option avec les disques tournants mis en cache séparément a le potentiel d'être plus lente en raison d'un trafic de bus plus important.

Il est rapide et relativement simple de configurer bcache pour supprimer le lecteur ssd, lorsque vous devez le remplacer. Grâce aux blocs, il devrait être possible de migrer la configuration du raid dans les deux sens sur place.

Rappelez - vous aussi, que pour le moment la plupart (tous?) Les distributions live-CD ne prennent pas en chargebcache , de sorte que vous ne pouvez pas simplement accéder à vos données avec ces outils quelle que soit la bcache- mdraidoption mise en page que vous avez choisi.

— Adam Ryczkowski
source

J'ai mis à jour la question pour préciser que je ne prévois pas d'avoir un cache SSD non redondant. Votre deuxième puce est un excellent point, merci pour cela. Troisième puce à propos de l'espace: voulez-vous dire que vous stockeriez la parité sur SSD? En ce qui concerne votre dernier paragraphe, j'utilise F20 mais j'utiliserai éventuellement RHEL / CentOS7 ou Debian Jessie (si bcache-tools fait la coupe).

@JackDouglas Ad 3rd bullet: Oui, exactement cela. Mais puisque vous prévoyez d'utiliser des disques SSD raidés, cela ne s'applique pas à vous.

— Adam Ryczkowski

Il le fait toujours car ils seront non seulement mis en miroir mais devront également stocker la parité RAID pour les disques de sauvegarde. Ce n'est pas le cas si le RAID est fait sous bcache, ce que je pensais être votre point

Je pense que vous voulez dire le contraire: la matrice SSD n'a pas besoin de stocker la parité des disques en rotation, si elle est alimentée par le lecteur mdraid entier.

— Adam Ryczkowski

oui, c'est exactement ce que je veux dire!

Je pense que l'approche sensée consiste à mettre en cache le périphérique MD résultant.

bcache est conçu pour passer par des lectures et des écritures séquentielles.

Si vous bcachez chaque périphérique séparément, logiquement, plusieurs périphériques entrelacés dans un MD raidé ou dépouillé, du point de vue bcache, écriront constamment des blocs aléatoires.

Alors qu'un volume MD bcached aura l'air normal, écrire des fichiers sur le volume, plutôt que des blocs aléatoires sur plusieurs appareils.

L'intérêt du raid matériel et logiciel est de procéder à l'entrelacement des données dans le backend afin que le système de fichiers résultant ressemble à un volume normal.

Cela peut ne pas être correct (car les développeurs bcache peuvent être intelligents et tenir compte de ce genre de situation), mais la chose logique optimale à faire est de mettre en cache les volumes, plutôt que de bloquer les périphériques.

— éclairer
source

également un très bon point

Une grande écriture séquentielle sur un RAID5 / 6 produit des écritures séquentielles sur tous les périphériques composants. Chaque périphérique composant obtient chaque bloc de données N-1 (ou parité), mais les données qu'il obtient sont séquentielles. Mais vous avez raison, cela faussera les choses. S'il y a des morceaux qui voient des écritures de bande partielle fréquentes, entraînant une lecture-modification-écriture de (une partie de) la bande de parité, cela pourrait être mis en cache par bcache. Le mettre en cache plus haut, avant que l'écriture en bande partielle n'atteigne le périphérique MD, serait encore mieux.

— Peter Cordes