6 votes

Philipp Wendler avatar

Mauvaises performances avec le logiciel Linux RAID5 et le cryptage LUKS

Demandé el 3 de Juillet, 2011
Quand la question a-t-elle été
7774 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'ai configuré un RAID5 logiciel Linux sur trois disques durs et je veux le crypter avec cryptsetup/LUKS. Mes tests ont montré que le cryptage entraîne une baisse massive des performances que je ne peux pas expliquer.

Le RAID5 est capable d'écrire 187 MB/s [1] sans cryptage. Avec le cryptage en plus, la vitesse d'écriture descend à environ 40 Mo/s.

Le RAID a une taille de 512K et un bitmap d'intention d'écriture. J'ai utilisé -c aes-xts-plain -s 512 --align-payload=2048 comme paramètres pour cryptsetup luksFormat La charge utile doit donc être alignée sur 2048 blocs de 512 octets (soit 1 Mo). cryptsetup luksDump montre un décalage de la charge utile de 4096. Je pense donc que l'alignement est correct et correspond à la taille des morceaux du RAID.

Le CPU n'est pas le goulot d'étranglement, car il a un support matériel pour AES (aesni_intel). Si j'écris sur un autre disque (un SSD avec LVM) qui est également crypté, j'ai une vitesse d'écriture de 150 Mo/s. top montre que l'utilisation du CPU est effectivement très faible, seul le xor du RAID5 prend 14%.

J'ai également essayé de mettre un système de fichiers (ext4) directement sur le RAID non crypté pour voir si la superposition est un problème. Le système de fichiers diminue un peu les performances comme prévu, mais de loin pas tant que ça (vitesse d'écriture variable, mais > 100 MB/s).

Résumé :
Disques + RAID5 : bon
Disques + RAID5 + ext4 : bon
Disques + RAID5 + cryptage : mauvais
SSD + cryptage + LVM + ext4 : bon

La performance de lecture n'est pas affectée par le cryptage, elle est de 207 MB/s sans et 205 MB/s avec cryptage (ce qui montre également que la puissance du CPU n'est pas le problème).

Que puis-je faire pour améliorer les performances d'écriture du RAID crypté ?

[1] Toutes les mesures de vitesse ont été effectuées avec plusieurs séries d'essais. dd if=/dev/zero of=DEV bs=100M count=100 (c'est-à-dire l'écriture de 10G par blocs de 100M).

Editar: Si cela peut vous aider : J'utilise Ubuntu 11.04 64bit avec Linux 2.6.38.

Edit2 : Les performances restent à peu près les mêmes si je passe une taille de bloc de 4KB, 1MB ou 10MB à dd .

Demandé el 3 de Juillet, 2011 par Philipp Wendler

Réponses

Trop de publicités?

6voto

Philipp Wendler avatar
Philipp Wendler Points 544

La solution consiste à définir le stripe_cache_size fonctionnalité pour les raids Md.

Par défaut, il est fixé à 256, mais il peut être augmenté jusqu'à 32768.

Pour ce faire, il faut écrire la taille souhaitée dans le fichier /sys/block/md0/md/stripe_cache_size (si le raid est md0 ). Sur Ask Ubuntu, il existe un solution pour fixer la valeur de façon permanente .

J'ai testé sur le même RAID que dans la question, et j'ai obtenu les chiffres suivants :

size   256: 50 MB/s
size  4096: 123 MB/s
size  8192: 142 MB/s
size 16384: 140 MB/s
size 32768: 142 MB/s

Ces tests ont été réalisés avec Ubuntu 12.04 (Linux 3.2) en écrivant 10 Go dans un fichier avec des blocs de 1 Mo.

Historique : Le cache à bandes stocke les blocs récemment écrits. Si les données sont écrites en continu, il se peut que lors de la première écriture, seule une partie d'une bande soit écrite. Cela signifie que le code RAID doit lire la bande complète sur le disque, la mettre à jour et l'écrire à nouveau complètement. Si une deuxième écriture survient pour une autre partie de la même bande, tout cela devra être refait. Maintenant, si le cache est utilisé et contient encore les données écrites par la première écriture, la lecture qui était nécessaire avant la deuxième écriture peut être omise.

En général, une taille de bloc importante lors de l'écriture permet d'éviter le problème (car les bandes complètes sont écrites en une seule fois, et aucune lecture n'est donc nécessaire). Cependant, il semble que le cryptage n'utilise que de petits blocs lors de l'écriture sur le périphérique sous-jacent, et donc l'augmentation du cache a un effet positif.

Répondu el 5 de Février, 2013 par Philipp Wendler (544 Points )

1voto

cablop avatar
cablop Points 178

LUKS a un goulot d'étranglement, c'est-à-dire qu'il ne génère qu'un seul fil par périphérique de bloc.

Placez-vous le cryptage au-dessus du RAID 5 ? Du point de vue de votre système d'exploitation, vous n'avez qu'un seul périphérique et il n'utilise qu'un seul thread pour tous ces disques, ce qui signifie que les disques fonctionnent en série plutôt qu'en parallèle.

Est-ce que vous placez LVM au-dessus des périphériques cryptés ? Dans ce cas, vous créez un thread par dispositif, ce qui leur permet de travailler en parallèle.

Une solution pour cela ? Si vous utilisez Linux, quelle que soit la vitesse, la puissance ou le nombre de cœurs de votre processeur, utilisez le logiciel Raid, puis créez les volumes sur des disques cryptés. De cette façon, votre système d'exploitation verra plusieurs périphériques et créera un thread pour chacun d'eux.

L'inconvénient est de devoir entrer la clé de passe plusieurs fois, mais pour éviter cela, vous pouvez opter pour cette configuration. Un disque ou une partie d'un disque contient les partitions de démarrage et de racine, le démarrage est non chiffré, la racine est chiffrée et contient un fichier clé, ce fichier clé est utilisé pour déchiffrer les autres périphériques (peut-être le reste du même disque).

J'ai trouvé ce problème sans utiliser RAID, mais en traitant avec une machine virtuelle qui ralentissait le système d'exploitation hôte, jusqu'à ce que je réalise que le système d'exploitation virtuel monopolisait le fil de lecture. J'ai décidé de créer différentes partitions sur le même périphérique et d'utiliser une partition pour les disques virtuels, alors ils ne peuvent pas monopoliser le fil et les performances des deux systèmes d'exploitation se sont beaucoup améliorées.

Je pense que vous pouvez également bénéficier de l'utilisation du RAID logiciel, vous ne seriez plus dépendant de votre matériel.

Répondu el 15 de Août, 2011 par cablop (178 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X