É seguro adicionar o dispositivo de cache LVM ao grupo de volumes LVM existente enquanto o sistema de arquivos está montado?

Isso não foi claramente documentado em nenhum lugar pelos autores do LVM, mas de acordo com https://blog.delouw.ch/2020/01/29/using-lvm-cache-for-storage-tiering/

Outro benefício do dm-cache sobre o dm-writecache é que o cache pode ser criado, ativado e destruído online .

Isso significa que, desde que você esteja usando dm-cachemódulo em vez de dm-writecachemódulo, deve ser seguro adicionar e remover o cache LVM enquanto o volume lógico já estiver montado.

Observe que cachemodea configuração do LVM writebacké diferente de dm-writecache.

Além disso, a documentação do RedHat em https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/administration_guide/sect-lvm_cache#idm140401735629408 diz o seguinte:

19.8.3. Configurando o cache LVM
...
A adição ou remoção de pools de cache pode ser feita em volumes ativos, mesmo com sistemas de arquivos montados em uso . No entanto, há sobrecarga na operação e serão observados impactos no desempenho , especialmente ao remover um volume de cache no modo writeback, pois será necessária uma sincronização completa dos dados.

Eu também verifiquei isso seguindo o teste:

1. Crie 4 dispositivos de armazenamento adicionais em uma máquina virtual: sda(2 GB), sdb(4 GB), sdc(4 GB), sdd(1 GB). Os tamanhos desses dispositivos não são importantes. Usei dispositivos de tamanhos diferentes para ilustrar a flexibilidade do LVM aqui. Você pode fingir que o menor sddé o dispositivo mais rápido e será usado como cache.

2. Construa um armazenamento LVM de sda, sdb, sdc usando todas as extensões de todos os dispositivos (o grupo de volumes é chamado storagee o volume lógico é chamado datapara este exemplo):

   pvcreate /dev/sda /dev/sdb /dev/sdc
   vgcreate storage /dev/sda /dev/sdb /dev/sdc
   lvcreate -l100%FREE -n data storage
   mkfs.ext4 /dev/mapper/storage-data
   mkdir -p /root/test
   mount /dev/mapper/storage-data /root/test
   

   No mundo real, eu recomendaria criar partições um pouco mais curtas que todo o dispositivo e usar essas partições para o volume físico do LVM. Isso permite uma substituição mais fácil de um dispositivo porque dispositivos de “1 TB” de fabricantes diferentes podem diferir em alguns megabytes. Prefiro manter os últimos ~ 100 MB não particionados para que os SSDs possam criar partições de tamanho idêntico em diferentes dispositivos SSD. Como bônus, o dispositivo SSD pode usar essa área nunca usada do disco como área extra de nivelamento de desgaste. Se você usar unidades baratas, recomendo deixar 10–20% nunca usadas porque unidades baratas normalmente têm muito menos área de nivelamento de desgaste fora da área acessível ao usuário. Deixar alguma área acessível ao usuário intocada (ou liberada comTRIM) permite que o firmware tenha mais área de nivelamento de desgaste, o que prolonga a vida útil da unidade e normalmente melhora seu desempenho.

3. Inicie dois loops de teste fio em paralelo em dois terminais separados no diretório /root/test:

   Primeiro ciclo:

   while fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randwrite --size=500m --blocksize=4k --ioengine=libaio --fsync=1m --iodepth=1 --direct=1 --numjobs=1 --group_reporting --verify=sha1 --do_verify=0 --verify_state_save=1 --verify_backlog=1024 && fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --blocksize=4k --ioengine=libaio --fsync=1m --iodepth=1 --direct=1 --numjobs=1 --group_reporting --verify=sha1 --do_verify=1 --verify_state_save=1 --verify_backlog=1024 --verify_dump=1 --verify_only ; do printf "\nOK -- %s\n\n\n" "$(date --iso=sec)"; done
   

   Segundo loop (em outro terminal):

   while fio --name TEST --eta-newline=5s --filename=fio-tempfile2.dat --rw=randwrite --size=500m --blocksize=4k --ioengine=libaio --fsync=1m --iodepth=4 --direct=1 --numjobs=4 --group_reporting --verify=sha1 --do_verify=0 --verify_state_save=1 --verify_backlog=1024 && fio --name TEST --eta-newline=5s --filename=fio-tempfile2.dat --rw=randread --size=500m --blocksize=4k --ioengine=libaio --fsync=1m --iodepth=2 --direct=1 --numjobs=8 --group_reporting --verify=sha1 --do_verify=1 --verify_state_save=1 --verify_backlog=1024 --verify_dump=1 --verify_only ; do printf "\nOK -- %s\n\n\n" "$(date --iso=sec)"; done
   

   Estes criam dois arquivos chamados fio-tempfile.date fio-tempfile2.datque são gravados e verificados continuamente com um total de 5 processos e o conteúdo dos arquivos é verificado. Testei com ddisso que se você modificar um único byte, o loop detectará o erro:

   dd if=/dev/zero of=fio-tempfile.dat seek=1000000 count=1 bs=1
   

   Assim que um erro for detectado, você pode reiniciar o loop e ele continuará testando e verificando o armazenamento até ser interrompido ou até que um erro seja encontrado.

4. Adicione um novo dispositivo de cache ( sdd) a esse armazenamento existente enquanto os loops de teste acima estão em execução constante para demonstrar que o acesso ao sistema de arquivos é seguro:

   pvcreate /dev/sdd
   vgextend storage /dev/sdd
   lvcreate -n lvmcache-data -l 98%FREE storage /dev/sdd
   lvcreate -n lvmcache-metadata -l 50%FREE storage /dev/sdd
   lvconvert --type cache-pool --cachemode writeback --poolmetadata storage/lvmcache-metadata storage/lvmcache-data
   lvconvert --type cache --cachepool storage/lvmcache-data storage/data
   

   O último comando adiciona o dispositivo de cache LVM dinamicamente sem causar corrupção de dados. O cache também durará reinicializações do sistema sem problemas. A razão para alocar apenas 98% para o cache de dados e 50% do espaço restante (1%) para o cache de metadados é que construir um cachepool a partir deles requer um pouco de espaço livre no grupo de volumes ou falhará. Você também pode usar cachevolem vez disso cachepool, mas software de terceiros normalmente só oferece suporte cachepoolporque é o método mais antigo. Ambos têm desempenho idêntico e cachepoolsão apenas mais complexos de construir, mas têm melhor interoperabilidade com software de reparo e diagnóstico de terceiros, por isso prefiro usá-los. OcachepoolO modo também suporta o uso de dispositivos separados para metadados e dados, o que pode melhorar o desempenho se você tiver vários dispositivos realmente rápidos.

5. Se você quiser remover o dispositivo de cache, poderá fazer o seguinte imediatamente, sem corrupção de dados:

   lvconvert --uncache storage/data
   

   Isso levará muito tempo se o cache LVM estiver em uso ativo (como no exemplo acima com os loops de teste em execução) e continuará exibindo status como

   Flushing 15610 blocks for cache storage/data.
   Flushing 11514 blocks for cache storage/data.
   Flushing 7418 blocks for cache storage/data.
   Flushing 5481 blocks for cache storage/data.
   ...
   Flushing 1 blocks for cache storage/data.
   Logical volume "lvmcache-data_cpool" successfully removed
   Logical volume storage/data is not cached.
   

   Parece que a descarga pode parar por um longo tempo e continuar exibindo a mesma quantidade de blocos não liberados, mas você só precisa continuar esperando. O sistema de arquivos montado no LVM continua funcionando o tempo todo.

   Não verifiquei o que acontece se houver perda de energia durante a uncacheoperação. Eu presumo que o LVM inicializa com o cache ainda em uso e você pode simplesmente executar uncachenovamente a operação.

Observe que após o uncachecomando, os volumes lógicos do cache de dados e do cache de metadados serão perdidos (liberados sem qualquer histórico), portanto, se você quiser reconectar o dispositivo de cache, deverá construí-lo desde o início (todos os comandos lvcreatee lvconvertpara o passo 4). O dispositivo de cache ainda fará parte do grupo de volumes após a uncacheoperação, portanto não será necessário refazer isso.

E como sempre, tenha sempre um backup atualizado, completo e verificado antes de mexer em qualquer dado importante!

A configuração do cache LVM acima será semelhante a lsblk -sp:

NAME                                             MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
/dev/mapper/storage-data                         253:3    0    10G  0 lvm  /root/test
├─/dev/mapper/storage-lvmcache--data_cpool_cdata 253:0    0   996M  0 lvm  
│ └─/dev/sdd                                       8:48   0     1G  0 disk 
├─/dev/mapper/storage-lvmcache--data_cpool_cmeta 253:1    0    12M  0 lvm  
│ └─/dev/sdd                                       8:48   0     1G  0 disk 
└─/dev/mapper/storage-data_corig                 253:2    0    10G  0 lvm  
  ├─/dev/sda                                       8:0    0     2G  0 disk 
  ├─/dev/sdb                                       8:16   0     4G  0 disk 
  └─/dev/sdc                                       8:32   0     4G  0 disk 

Algumas dicas adicionais sobre o uso do cache LVM:

Você pode ajustar um pouco o cache do LVM, mesmo que a lógica para selecionar o que manter no cache seja totalmente automática. Veja man lvmcachepara detalhes completos. Alguns exemplos:

• Liste as configurações atuais de cache (os valores padrão não serão listados):

  lvs -o cachesettings storage/data
  

• Limpe todas as configurações de cache (use padrões para tudo):

  lvchange --cachesettings '' storage/data
  

• Ajuste o cache para sempre começar a liberar o cache de gravação para o armazenamento de apoio quando mais de 10% do cache for usado para buffer de gravação:

  lvchange --cachesettings 'high_watermark=10' storage/data
  

• Ajuste o cache para continuar liberando o cache de gravação quando houver algo para liberar depois que a liberação for iniciada por qualquer motivo:

  lvchange --cachesettings 'low_watermark=0' storage/data
  

• Ajuste o cache para pausar automaticamente a liberação por 50 ms se o armazenamento de apoio for acessado (evite introduzir latência para liberação)

  lvchange --cachesettings 'pause_writeback=50' storage/data
  

• Descarregue automaticamente até mesmo uma pequena quantidade de dados para o armazenamento de apoio quando eles estiverem no cache por mais de 60 segundos:

  lvchange --cachesettings 'autocommit_time=60000' storage/data