IO pobre devido ao ordenamento de LUKS / Software RAID / LVM? ______ qstntxt ___ Estou tentando determinar se devo reorganizar minha matriz RAID devido ao desempenho ruim do IO. Primeiro, o sistema: i7 920 4 unidades verdes WD 5400 de 4 TB CentOS 6.3 host Em segundo lugar, a configuração do disco: / dev / sda2, b2, c2, d2 são criptografados individualmente pelo LUKS / dev / mapper / a2, b2, c2, d2 fazem parte de um software RAID5 / dev / md1 / dev / md1 tem LVM além disso O LVM é usado para separar /, / storage e swap Eu escolhi essa estrutura para permitir várias instâncias do kcryptd, pensando que, ao fazer isso, eu obteria suporte multithread na criptografia, já que uma instância está sendo executada por unidade. No entanto, estou começando a me perguntar se foi uma boa ideia. Por exemplo, se eu executar uma rotina de descompressão pesada em um arquivo RAR de dados aleatórios, meu IO Wait aumenta para cerca de 25% e diminui o sistema geral. Eu estou querendo saber se todos os conjuntos de instruções estão recebendo backup de alguma forma devido a todos os processos do kcryptd. Por isso, estou pensando em mudar para: / dev / sda2, b2, c2, d2 são colocados em / dev / md1 / dev / md1 é criptografado e mapeado para / dev / mapper / 1 LVM em cima de / dev / mapper / 1 Isso cairia em um único processo kcrpytd, que poderia ser um gargalo por si só também. Alguém acha que isso ajudará no meu problema de IO? ______ azszpr114452 ___ Suas camadas são abaixo do ideal porque colocar o RAID 5 em cima da criptografia significa aumentar em 25% o número de operações de criptografia / descriptografia, pois 4 * 4 TB são criptografados. Ao colocar a criptografia na parte superior da invasão 5, apenas 3 * 4 TB são criptografados. O raciocínio por trás disso é: você não precisa criptografar dados de paridade (que ocupam 4 TB em seu exemplo) de dados criptografados porque isso não aumenta sua segurança. Sua presunção sobre vários processos kcrypt é apenas isso. Ao basear as decisões nele, é uma otimização prematura que pode ter o efeito oposto. Seu i7 é bastante robusto, provavelmente incluindo algumas instruções especiais que ajudam a acelerar o AES - e o kernel do Linux inclui várias variantes otimizadas de primitivas criptográficas que são automaticamente selecionadas durante a inicialização. Você pode verificar se as rotinas otimizadas para sua CPU são usadas via %code% (por exemplo, sinalizador %code% ), %code% , %code% (a menos que os módulos aes sejam compilados no kernel) e log do kernel. Você deve comparar o throughput do kryptd sem envolver nenhum disco lento para ver qual é o limite superior (isto é, em um disco RAM usando o iozone). Para diagnosticar possíveis problemas de desempenho mais tarde, também é útil fazer um benchmark de sua configuração de escolha de RAID sem qualquer criptografia para obter um limite superior nesse ponto. Além do tópico de criptografia, o RAID 5 envolve mais IO-Operations do que o RAID 1 ou 10. Como o armazenamento é meio barato, talvez seja uma opção para comprar mais discos rígidos e usar outro nível de RAID. ______ azszpr114404 ___ Eu Raid 1 + 0 [a2, b2] + [c2, d2], depois LVM sobre LUKS. Exemplo %pre% OBSERVAÇÃO: Estruturar desta forma criará uma faixa de espelhos permitindo que um máximo de 2 discos falhe (um em cada espelho max) e lhe dará um espaço total / 2 em oposição a raid5 que é total * ~ 0,75. Também acredito que este esquema é significativamente mais rápido porque o RAID5 é conhecido por prejudicar o desempenho, mas você terá menos espaço disponível. Você também pode verificar a cifra, embora eu ache que aes-cbc-essiv é o padrão e razoavelmente rápido, mas você poderia usar aes-xts-plain, que deveria ser mais rápido. ______ azszpr114424 ___ Sua configuração significa que mais dados precisam ser criptografados no total ao gravar (os dados de paridade). Se sua criptografia já estiver lenta, a propriedade de vários núcleos pode não ser suficiente para compensar isso. Ao ler, não deve fazer diferença (os dados de paridade normalmente não são lidos). Isso ainda não está considerando quaisquer efeitos colaterais com o tempo mdadm ou o que quer que seja. Eu tomei uma abordagem diferente; em vez de fazer um grande RAID, particionei meus discos e criei vários discos menores (por exemplo, 8x 250G partições em um disco de 2TB). Isso significa 8 RAIDs em vez de 1, 8 contêineres LUKS e o LVM conecta tudo novamente em um grande VG. Em seguida, contanto que você tenha processos trabalhando em diferentes áreas do disco, os vários contêineres e RAIDs do LUKS funcionariam independentemente um do outro. Não é verdadeira criptografia paralela (o kernel ainda não suporta isso sozinho?), Mas funcionou muito bem para mim. Eu mantive essa configuração até mesmo em minha nova caixa Haswell, onde a criptografia não é um problema, graças ao AES-NI. Eu fiz isso porque há outros efeitos colaterais positivos. Por exemplo, um único setor defeituoso faria com que apenas uma parte de 250G de um disco caísse do RAID, enquanto o outro 1750G permanecesse redundante; ou se há um bug como o pânico do kernel RAID5 no 3.13.0, apenas um dos RAIDs precisa ser ressincronizado ao invés de todos eles. Ao mesmo tempo, não notei nenhum problema de desempenho, diferente de outras soluções, como o bitmap com intenção de gravação, etc. ___

Question

Estou tentando determinar se devo reorganizar minha matriz RAID devido ao desempenho ruim do IO. Primeiro, o sistema:

• i7 920
• 4 unidades verdes WD 5400 de 4 TB
• CentOS 6.3 host

Em segundo lugar, a configuração do disco:

• / dev / sda2, b2, c2, d2 são criptografados individualmente pelo LUKS
• / dev / mapper / a2, b2, c2, d2 fazem parte de um software RAID5 / dev / md1
• / dev / md1 tem LVM além disso
• O LVM é usado para separar /, / storage e swap

Eu escolhi essa estrutura para permitir várias instâncias do kcryptd, pensando que, ao fazer isso, eu obteria suporte multithread na criptografia, já que uma instância está sendo executada por unidade. No entanto, estou começando a me perguntar se foi uma boa ideia.

Por exemplo, se eu executar uma rotina de descompressão pesada em um arquivo RAR de dados aleatórios, meu IO Wait aumenta para cerca de 25% e diminui o sistema geral. Eu estou querendo saber se todos os conjuntos de instruções estão recebendo backup de alguma forma devido a todos os processos do kcryptd.

Por isso, estou pensando em mudar para:

• / dev / sda2, b2, c2, d2 são colocados em / dev / md1
• / dev / md1 é criptografado e mapeado para / dev / mapper / 1
• LVM em cima de / dev / mapper / 1

Isso cairia em um único processo kcrpytd, que poderia ser um gargalo por si só também. Alguém acha que isso ajudará no meu problema de IO?

    

Answer 1

Suas camadas são abaixo do ideal porque colocar o RAID 5 em cima da criptografia significa aumentar em 25% o número de operações de criptografia / descriptografia, pois 4 * 4 TB são criptografados.

Ao colocar a criptografia na parte superior da invasão 5, apenas 3 * 4 TB são criptografados.

O raciocínio por trás disso é: você não precisa criptografar dados de paridade (que ocupam 4 TB em seu exemplo) de dados criptografados porque isso não aumenta sua segurança.

Sua presunção sobre vários processos kcrypt é apenas isso. Ao basear as decisões nele, é uma otimização prematura que pode ter o efeito oposto. Seu i7 é bastante robusto, provavelmente incluindo algumas instruções especiais que ajudam a acelerar o AES - e o kernel do Linux inclui várias variantes otimizadas de primitivas criptográficas que são automaticamente selecionadas durante a inicialização.

Você pode verificar se as rotinas otimizadas para sua CPU são usadas via /proc/cpuinfo (por exemplo, sinalizador aes ), /proc/crypto , lsmod (a menos que os módulos aes sejam compilados no kernel) e log do kernel.

Você deve comparar o throughput do kryptd sem envolver nenhum disco lento para ver qual é o limite superior (isto é, em um disco RAM usando o iozone).

Para diagnosticar possíveis problemas de desempenho mais tarde, também é útil fazer um benchmark de sua configuração de escolha de RAID sem qualquer criptografia para obter um limite superior nesse ponto.

Além do tópico de criptografia, o RAID 5 envolve mais IO-Operations do que o RAID 1 ou 10. Como o armazenamento é meio barato, talvez seja uma opção para comprar mais discos rígidos e usar outro nível de RAID.

    

Answer 2

Eu Raid 1 + 0 [a2, b2] + [c2, d2], depois LVM sobre LUKS.

Exemplo

$ sudo mdadm --create /dev/md0 -v --raid-devices=4 \
      --level=raid10 /dev/sdb1 /dev/sdc1 /dev/sde1 /dev/sde1

OBSERVAÇÃO: Estruturar desta forma criará uma faixa de espelhos permitindo que um máximo de 2 discos falhe (um em cada espelho max) e lhe dará um espaço total / 2 em oposição a raid5 que é total * ~ 0,75.

Também acredito que este esquema é significativamente mais rápido porque o RAID5 é conhecido por prejudicar o desempenho, mas você terá menos espaço disponível.

Você também pode verificar a cifra, embora eu ache que aes-cbc-essiv é o padrão e razoavelmente rápido, mas você poderia usar aes-xts-plain, que deveria ser mais rápido.

    

Answer 3

Sua configuração significa que mais dados precisam ser criptografados no total ao gravar (os dados de paridade). Se sua criptografia já estiver lenta, a propriedade de vários núcleos pode não ser suficiente para compensar isso. Ao ler, não deve fazer diferença (os dados de paridade normalmente não são lidos). Isso ainda não está considerando quaisquer efeitos colaterais com o tempo mdadm ou o que quer que seja.

Eu tomei uma abordagem diferente; em vez de fazer um grande RAID, particionei meus discos e criei vários discos menores (por exemplo, 8x 250G partições em um disco de 2TB). Isso significa 8 RAIDs em vez de 1, 8 contêineres LUKS e o LVM conecta tudo novamente em um grande VG.

Em seguida, contanto que você tenha processos trabalhando em diferentes áreas do disco, os vários contêineres e RAIDs do LUKS funcionariam independentemente um do outro. Não é verdadeira criptografia paralela (o kernel ainda não suporta isso sozinho?), Mas funcionou muito bem para mim.

Eu mantive essa configuração até mesmo em minha nova caixa Haswell, onde a criptografia não é um problema, graças ao AES-NI. Eu fiz isso porque há outros efeitos colaterais positivos. Por exemplo, um único setor defeituoso faria com que apenas uma parte de 250G de um disco caísse do RAID, enquanto o outro 1750G permanecesse redundante; ou se há um bug como o pânico do kernel RAID5 no 3.13.0, apenas um dos RAIDs precisa ser ressincronizado ao invés de todos eles.

Ao mesmo tempo, não notei nenhum problema de desempenho, diferente de outras soluções, como o bitmap com intenção de gravação, etc.