zpool import em um volume de 50 TB está demorando para sempre: o que está fazendo?

Question

Temos um canal de fibra san gerenciado por dois servidores NFS do OpenSolaris 2009.06.

• O servidor 1 está gerenciando 3 volumes pequenos (unidades de 300 GB e 15K RPM). Está funcionando como um encanto.
• O servidor 2 está gerenciando um grande volume de 32 unidades (unidades de 2200 RPM) RAID6. O tamanho total é de 50 TB.
• Os dois servidores têm a versão 14 do Zpool e a versão 3 do ZFS.

O servidor lento de 50 TB foi instalado há alguns meses e estava funcionando bem. Usuários preenchidos com 2 TB. Eu fiz uma pequena experiência (criei 1000 sistemas de arquivos e tive 24 instantâneos em cada um). Tudo bem, tanto quanto criar, acessar os sistemas de arquivos com snapshots e montar NFS alguns deles.

Quando eu tentei destruir os sistemas de arquivos 1000, o primeiro fs levou vários minutos e depois falhou ao reportar que o fs estava em uso. Eu emiti um desligamento do sistema, mas demorou mais de 10 minutos. Eu não esperei mais e desliguei a energia.

Agora, ao inicializar, o OpenSolaris trava. As luzes nas 32 unidades estão piscando rapidamente. Eu deixei por 24 horas - ainda piscando, mas sem progresso.

Eu inicializei em um instantâneo do sistema antes do zpool ser criado e tentei importar o zpool.

pfexec zpool import bigdata

Mesma situação: LEDs piscando e a importação trava para sempre.

Dtracing o processo "zpool import" mostra apenas a chamada do sistema ioctl:

dtrace -n syscall:::entry'/pid == 31337/{ @syscalls[probefunc] = count(); }'

ioctl                          2499

Existe uma maneira de corrigir isso? Editar: sim. A atualização do OpenSolaris para o svn_134b fez o seguinte:

pkg publisher # shows opensolaris.org
beadm create opensolaris-updated-on-2010-12-17
beadm mount opensolaris-updated-on-2010-12-17 /mnt
pkg -R /mnt image-update
beadm unmount opensolaris-updated-on-2010-12-17
beadm activate opensolaris-updated-on-2010-12-17
init 6

Agora eu tenho o zfs versão 3. O BigData zpool permanece na versão 14. E está de volta à produção!

Mas o que estava acontecendo com o acesso pesado de E / S por mais de 24 horas (antes do upgrade do software)?

    

Answer 1

Com o ZFS, você realmente deseja permitir que ele manipule os discos diretamente, pois isso melhora a simultaneidade. O único disco de 50 TB que você deu é um ponto de estrangulamento.

Esse script do DTrace está apenas rastreando syscalls. A ação real acontece dentro do kernel e, se você quiser ver o que está consumindo a maior parte da CPU, use o script 'hotkernel' do DTrace Toolkit.

Quando você importa um pool, o ZFS lê a configuração do disco e a valida. Depois que o pool for importado, ele começará a montar todos os sistemas de arquivos e snapshots que você criou. Isso pode demorar um pouco. Se você teve a dedupção ativada (o que você não fez desde que você estava usando snv_111), levaria ainda mais tempo, já que tem que carregar a tabela de desduplicação (DDT).

Desligar o sistema nunca é uma boa opção, especialmente no OpenSolaris snv_111. Você não postou sua configuração de pool (zpool status), mas se você tiver dispositivos slog e eles falharem, você não poderá importar o pool (isso foi resolvido recentemente no Solaris 11 Express snv_151a).

Meu conselho é que você exporte cada um dos 32 discos individualmente e crie vários vdev's raidz2 para ter mais cabeças de leitura / gravação. Não crie vdev's enormes com discos > 8 porque o desempenho será péssimo.

Se você não puder perder tempo com o sistema (a maioria das pessoas não o faz), estude cuidadosamente os instantâneos do ZFS e como replicá-los em um servidor remoto com o zfs send / receive. Isso permitirá que você traga rapidamente um servidor de failover.

    

Answer 2

'zfs import' é mais ou menos apenas a leitura da configuração de seus vdevs (a partir do 'zpool.cache') diretamente. Eu estou supondo que o que estava levando para sempre aqui para terminar, foi sua transação de exclusão.

Dado que o ZFS é transacional e que você removeu 1000 sistemas de arquivos, cada um com 24 snapshots precisou ser removido intensivamente para verificar os ponteiros de referência para 24.000 instantâneos. Dado o tempo de busca desses chefes da SATA, e todas as atualizações de árvore que precisavam ser feitas.