Capítulo 14. Armazenamento

O Device Mapper (DM) foi atualizado para a versão upstream 4.2, a qual fornece várias correções de erros e aprimoramentos em relação à versão anterior, incluindo uma importante atualização do desempenho DM crypt e uma atualização do núcleo DM para oferecer suporte ao Mecanismo de Enfileiramento (em inglês, Multi-Queue Block I/O Queueing Mechanism) (blk-mq).

O Red Hat Enterprise Linux 7.2 inclui um novo mecanismo de agendamento de múltiplas filas E/S para dispositivos de blocos conhecidos como blk-mq. Ele melhora o desempenho permitindo que certos drivers de dispositivo mapeiem as solicitações E/S às múltiplas filas de software ou hardware. Esta melhora do desempenho vem através da redução da contenção de bloqueio presente quando múltiplas threads de execução desempenham E/S em um único dispositivo. Os dispositivos mais novos, como o Non-Volatile Memory Express (NVMe), ficam melhor posicionados para tirar proveito deste recurso, devido ao suporte nativo deles à múltipla submissão de hardware e às filas de conclusão, assim como às suas características de desempenho de baixa latência. Os ganhos com o desempenho, como sempre, dependerão do tipo exato de hardware e da carga de trabalho.

O recurso blk-mq está atualmente implementado e habilitado por padrão nos seguintes drivers: virtio-blk, mtip32xx, nvme e rbd.

O recurso relacionado, scsi-mq, permite que os drivers de dispositivo da Interface de Sistemas para Pequenos Computadores (do inglês, Small Computer System Interface - SCSI) utilizem a infraestrutura do blk-mq. O recurso scsi-mq é fornecido como uma apresentação prévia da tecnologia no Red Hat Enterprise Linux 7.2. Para habilitar o scsi-mq, especifique scsi_mod.use_blk_mq=y na linha de comando do kernel. O valor padrão é n (desabilitado).

O destino do device mapper (DM) multipath, o qual usa DM baseado em solicitação, também pode ser configurado para utilizar a infraestrutura do blk-mq, se a opção do kernel dm_mod.use_blk_mq=y estiver especificada. O valor padrão é n (desabilitado).

Pode ser proveitoso definir dm_mod.use_blk_mq=y, caso os dispositivos SCSI subjacentes também estejam usando blk-mq, já que reduz a sobrecarga de bloqueio na camada do DM.

Para determinar se o DM multipath está usando blk-mq em algum sistema, concatene o arquivo /sys/block/dm-X/dm/use_blk_mq, onde dm-X é substituído pelo dispositivo DM multipath de interesse. Este arquivo está em modo somente leitura e reflete o valor global no /sys/module/dm_mod/parameters/use_blk_mq no momento que o dispositivo DM multipath baseado em solicitação foi criado.

Mesmo quando um caminho não é confiável, como quando a conexão cai com frequência, o multipathd continua tentando usar este caminho. O tempo limite que o multipathd percebe que o caminho não é mais acessível é de 3000 segundos, o que pode dar a impressão de que o multipathd está paralisado.

Para corrigir isto, duas novas opções de configuração foram adicionadas: delay_watch_checks e delay_wait_checks. Configure delay_watch_checks para o número de ciclos de caminho que o multipathd deve assistir depois que ficar online. Caso o caminho falhe sob o valor atribuído, multipathd contará com a opção delay_wait_checks para informá-lo sobre o número de ciclos consecutivos que ele deve passar até que o caminho torne-se válido novamente. Isto previne que os caminhos inválidos sejam usados imediatamente depois que ficam online de novo.

Os usuários não podiam dividir sua configuração entre /etc/multipath.conf e outros arquivos de configuração. Isso impedia que os usuários instalassem um arquivo de configuração principal para todas as suas máquinas e mantivessem informações de configuração específicas da máquina em arquivos de configuração separados para cada máquina.

Para resolver isso, uma nova opção config_dir foi adicionada ao arquivo multipath.config. Os usuários devem alterar a opção config_dir para uma cadeia de caracteres vazia ou um nome de caminho de diretório totalmente qualificado. Quando definido para qualquer outra coisa que não seja uma cadeia de caracteres vazia, o multipath irá ler todos os arquivos .conf em ordem alfabética. Ele irá, então, aplicar as configurações exatamente como se tivessem sido adicionadas ao /etc/multipath.conf. Se esta alteração não é feita, config_dir é padronizado em /etc/multipath/conf.d.

O comando dmstats fornece suporte ao espaço de usuário para as estatísticas de E/S do device-mapper. Isto permite ao usuário criar, gerenciar e informar dados de histograma em latência, métricas e contadores de E/S para as regiões arbitrárias definidas pelos usuários de dispositivos device-mapper. Os campos de estatísticas estão, agora, disponíveis nos relatórios dmsetup e o comando dmstats adiciona novos modos de relatório especializados desenvolvidos para uso com informações estatísticas. Para mais informações sobre o comando dmstats, consulte a página manual dmstats(8).

O LVM cache tem sido oferecido com suporte integral desde Red Hat Enterprise Linux 7.1. Este recurso permite aos usuários criar volumes lógicos (LVs) com um dispositivo pequeno e rápido desempenhando como um cache para dispositivos maiores e mais lentos. Consulte a página manual lvmcache(7) para informações sobre a criação de volumes lógicos cache.

Observe as seguintes restrições na utilização dos LVs cache:

* O LV cache deve ser um dispositivo de alto nível. Não pode ser usado como um LV thin-pool, uma imagem de um RAID LV ou qualquer outro tipo de sub-LV.

* Os sub-LVs do LV cache (LV de origem, LV de metadados e LV de dados) só podem ser do tipo linear, striped ou RAID.

* As propriedades do LV cache não podem ser modificadas após a criação. Para mudar as propriedades do cache, remova o cache conforme descrito em lvmcache(7) e recrie-o com as propriedades desejadas.

Uma nova política de dm-cache smq que reduz o consumo de memória e melhora o desempenho na maioria dos casos de utilização foi escrita. Esta é, agora, a política de cache padrão para os novos volumes lógicos de LVM cache. Os usuários que preferirem usar a política de cache mq legada ainda podem utilizá-la fornecendo o argumento —cachepolicy quando estiverem criando o volume lógico cache.

Os grupos de volume LVM agora podem ser atribuídos a um proprietário. O proprietário dos grupos de volume é a ID do sistema de um host. Somente o host com a ID de sistema dada pode usar o VG. Isto pode beneficiar os grupos de volume que existem em dispositivos compartilhados, visíveis a múltiplos hosts, os quais não são protegidos de outro modo do uso simultâneo de múltiplos hosts. Os grupos de volume LVM em dispositivos compartilhados com uma ID do sistema atribuída são pertencentes a um host e protegidos de outros hosts.

O daemon lvmpolld fornece um método polling para comandos LVM de execução longa. Quando habilitado, o controle dos comandos LVM de execução longa é transferido do comando LVM original para o daemon lvmpolld. Isto permite que a operação continue independente do comando LVM original. O daemon lvmpolld é habilitado por padrão.

Antes da introdução do daemon lvmpolld, qualquer processo de polling em segundo plano originário de um comando lvm2 iniciado dentro de um cgroup de um serviço systemd poderia ser interrompido, se o processo principal (o serviço principal) fosse encerrado no cgroup. Isto podia gerar o término prematuro do processo de polling do lvm2. Além disto, lvmpolld ajuda a evitar a geração de consultas de processos de polling do lvm2 para progresso na mesma tarefa múltiplas vezes, já que ele monitora o progresso para todas as tarefas de polling em andamento.

Para mais informações sobre o daemon lvmpolld, consulte o arquivo de configuração lvm.conf.

O lançamento do Red Hat Enterprise Linux 7.2 fornece suporte a várias melhorias nos critérios de seleção do LVM. Anteriormente, era possível usar critérios de seleção somente para os comandos de notificação; agora, o LVM fornece suporte a critérios de seleção para diversos comandos de processamento de LVM também. Além disto, há chances de fornecer um suporte melhor neste lançamento para a seleção e campos de notificação de tempo.

Para mais informações sobre a implementação desses novos recursos, consulte o apêndice LVM Selection Criteria no manual Logical Volume Administration.

O valor padrão para o parâmetro max_report_luns aumentou de 511 para 16393. Este parâmetro especifica o número máximo de unidades lógicas que podem ser configuradas quando os sistemas escaneiam a interconexão SCSI usando o mecanismo Report LUNs.