Amélioration des E / S avec FlashCache

J'ai un serveur avec 2 disques durs (2x 1 To), fonctionnant en RAID 1 (SW-RAID). Je souhaite améliorer les performances d'E / S en utilisant flashcache. Il exécute des machines virtuelles KVM dessus, en utilisant LVM.

À ce sujet, j'ai les questions suivantes:

• Est-ce que cela fonctionnera même? flashcachefonctionne pour les périphériques bloc, mais ce sont toutes des machines virtuelles avec leur propre configuration.
• Dans quelle mesure puis-je m'attendre à augmenter les performances? La plupart des machines virtuelles exécutent des sites Web et certains jeux hôtes.
• Quelle doit être la taille du SSD? Un SSD plus grand augmenterait-il les performances puisqu'il est capable de mettre en cache plus de fichiers?
• Que se passe-t-il si le SSD meurt? Est-ce que flashcacherécupérer des fichiers du disque dur traditionnel et je pourrais simplement remplacer le SSD?
• Combien serait plus rapide writebacken comparaison avec writethroughet writearound?

Je n'ai malheureusement pas accès à un système de test, donc pourrais-je installer flashcachesur un serveur live sans démonter les disques? J'ai trouvé un excellent tutoriel ici que j'utiliserais.

Flashcache, pour ceux qui ne l'ont pas vu auparavant, est une méthode pour étendre le cache de blocs Linux avec un lecteur SSD. C'est moins cher que d'exécuter un serveur avec une demi-To de RAM juste pour la mise en cache.

Est-ce que cela fonctionnera même?

Cela devrait. Le cache de blocs Linux fonctionne en mettant en cache les blocs accédés , pas les fichiers . Tant que vous ne donnez pas aux machines KVM un accès direct aux périphériques de bloc (vous ne l'êtes pas), le cache de blocs Linux sera en jeu. Toutefois, si vous êtes donnez des machines KVM accès bloc périphérique directement la réponse , il est moins clair.

Si vous utilisez des disques virtuels sauvegardés sur fichiers, cela fonctionnera certainement.

Si vous utilisez des disques virtuels soutenus par LV, je ne sais pas.

Dans quelle mesure puis-je m'attendre à augmenter les performances?

C'est une chose à laquelle nous ne pouvons pas répondre. Cela dépend d'une variété de choses. Dans l'abstrait, vous obtiendrez les meilleures performances pour dimensionner votre SSD afin qu'il soit plus grand que l'ensemble de blocs actif. Si vous obtenez une mise en cache parfaite, vos performances seront similaires à l'exécution de l'ensemble de votre système sur des SSD. Ce que vous ferez effectivement.

Quelle doit être la taille du SSD?

Nous ne pouvons pas vous aider à trouver la taille exacte dont vous avez besoin. Plus c'est mieux, bien sûr, mais trouver le rapport exact entre cache-SSD et stockage principal n'est pas une mince affaire.

Pour compliquer cela, les écritures doivent être vidées immédiatement, telles que certaines opérations du système de fichiers et certaines configurations de base de données. Ces écritures ne seront que brièvement mises en cache et leurs performances ne seront en aucun cas affectées par la présence ou l'absence de flashcache.

Que se passe-t-il si le SSD meurt?

La même chose se produit lorsque vous dites à Linux de supprimer les caches mais avec une torsion. Avec les drop-caches, toutes les écritures non vidées qui se trouvent dans le cache de bloc seront vidées sur le disque. Ce qui se passe lorsque le SSD disparaît dépend du mode de mise en cache :

Writethrough : Toutes les écritures sont écrites dans le cache et le stockage principal en parallèle, de sorte que les risques d'une perte soudaine de SSD provoquant des erreurs sur les machines virtuelles sont très faibles.

Contournement : toutes les écritures sont écrites sur le stockage principal et mises en cache uniquement lors de la lecture. Aucune chance d'erreurs dans les VM.

Écriture différée : toutes les écritures vont d'abord dans le cache et sont écrites sur le stockage principal en arrière-plan. Les plus susceptibles de provoquer des erreurs dans vos machines virtuelles en cas de défaillance du SSD, et je n'utiliserais pas ce mode en production.

Combien plus rapide serait l'écriture différée par rapport à l'écriture et à l'écriture?

Cela dépend de la quantité d'écriture que vous faites. Si vos écritures saturent périodiquement votre stockage principal, l'augmentation des performances pourrait être assez importante. Si vous êtes principalement lu avec un peu d'écriture, vous ne remarquerez probablement pas d'améliorations.

De plus, l'écriture différée est une mauvaise politique pour ce que vous faites, alors ne l'utilisez pas.

Oui, cela fonctionnera bien tant que vous utiliserez les bons blocs. Et il y a un truc.

Lorsque LVM recherche des PV, il doit voir la partition via le disque dur lui-même et via le périphérique "virtuel" flashcache.

Un symptôme évident devrait être que les outils LVM se plaignent de PV en double.

Le correctif, pour éviter ces avertissements et surtout, assurez-vous que le périphérique flashcache est utilisé par LVM2, consiste à adapter le filtre /etc/lvm/lvm.conf.

La LVM.CONF(5)page de manuel l'expliquera mieux que moi, mais je vous laisse avec un exemple, si tous les volumes physiques sont sauvegardés par flashcache:

filter = [ "a/.*dm.*/" ]

Il y a aussi le niveau du créateur lessfs. Cela vous permettra de créer des appareils hybrides entre SSD et HDD. Les performances de tier semblent surpasser Flashcache.

http://www.lessfs.com/wordpress/

http://www.lessfs.com/wordpress/?p=776

//Christian

Certaines applications ouvrent des fichiers de manière non tamponnée.

http://man7.org/linux/man-pages/man2/open.2.html

O_DIRECT (depuis Linux 2.4.10) Essayez de minimiser les effets de cache des E / S vers et depuis ce fichier. En général, cela dégrade les performances, mais il est utile dans des situations spéciales, comme lorsque les applications effectuent leur propre mise en cache. Les E / S de fichiers sont effectuées directement vers / depuis les tampons de l'espace utilisateur. Le drapeau O_DIRECT fait à lui seul un effort pour transférer les données de manière synchrone, mais ne donne pas les garanties du drapeau O_SYNC que les données et les métadonnées nécessaires sont transférées. Pour garantir des E / S synchrones, O_SYNC doit être utilisé en plus de O_DIRECT. Voir les NOTES ci-dessous pour plus de discussion.

Par exemple, cela est très courant pour les bases de données. Vérifiez donc si flashcache fonctionne avec cet ensemble d'applications.