Red Hat Training

A Red Hat training course is available for RHEL 8

Deduplicar e comprimir o armazenamento

Red Hat Enterprise Linux 8

Usando VDO para otimizar a capacidade de armazenamento no RHEL 8

Resumo

Esta coleção de documentação fornece instruções sobre como usar o Virtual Data Optimizer (VDO) para gerenciar pools de armazenamento dedicados e comprimidos no Red Hat Enterprise Linux 8.

Tornando o código aberto mais inclusivo

A Red Hat tem o compromisso de substituir a linguagem problemática em nosso código, documentação e propriedades da web. Estamos começando com estes quatro termos: master, slave, blacklist e whitelist. Por causa da enormidade deste esforço, estas mudanças serão implementadas gradualmente ao longo de vários lançamentos futuros. Para mais detalhes, veja a mensagem de nosso CTO Chris Wright.

Fornecendo feedback sobre a documentação da Red Hat

Agradecemos sua contribuição em nossa documentação. Por favor, diga-nos como podemos melhorá-la. Para fazer isso:

  • Para comentários simples sobre passagens específicas:

    1. Certifique-se de que você está visualizando a documentação no formato Multi-page HTML. Além disso, certifique-se de ver o botão Feedback no canto superior direito do documento.
    2. Use o cursor do mouse para destacar a parte do texto que você deseja comentar.
    3. Clique no pop-up Add Feedback que aparece abaixo do texto destacado.
    4. Siga as instruções apresentadas.
  • Para enviar comentários mais complexos, crie um bilhete Bugzilla:

    1. Ir para o site da Bugzilla.
    2. Como Componente, use Documentation.
    3. Preencha o campo Description com sua sugestão de melhoria. Inclua um link para a(s) parte(s) relevante(s) da documentação.
    4. Clique em Submit Bug.

Capítulo 1. Implantação de VDO

Como administrador de sistema, você pode usar VDO para criar pools de armazenamento dedicados e comprimidos.

1.1. Introdução à VDO

O Virtual Data Optimizer (VDO) oferece redução de dados em linha para Linux na forma de deduplicação, compressão e thin provisioning. Quando você configura um volume VDO, você especifica um dispositivo de bloco sobre o qual construir seu volume VDO e a quantidade de armazenamento lógico que você planeja apresentar.

  • Ao hospedar VMs ou contêineres ativos, a Red Hat recomenda o armazenamento de provisões a uma razão lógica para 10:1 física: ou seja, se você estiver utilizando 1 TB de armazenamento físico, você o apresentaria como 10 TB de armazenamento lógico.
  • Para o armazenamento de objetos, como o tipo fornecido pela Ceph, a Red Hat recomenda o uso de uma relação lógica para física de 3:1: ou seja, 1 TB de armazenamento físico se apresentaria como armazenamento lógico de 3 TB.

Em ambos os casos, você pode simplesmente colocar um sistema de arquivo em cima do dispositivo lógico apresentado pela VDO e depois usá-lo diretamente ou como parte de uma arquitetura de armazenamento distribuído em nuvem.

Como a VDO é pouco provisionada, o sistema de arquivo e as aplicações só vêem o espaço lógico em uso e não estão cientes do espaço físico real disponível. Use scripts para monitorar o espaço real disponível e gerar um alerta se o uso exceder um limite: por exemplo, quando o volume do VDO for 80 tosco.

Recursos adicionais

1.2. Cenários de implantação da VDO

Você pode implantar o VDO de várias maneiras para proporcionar um armazenamento dedicado:

  • tanto o acesso em bloco como o acesso a arquivos
  • armazenamento local e remoto

Como a VDO expõe seu armazenamento dedicado como um dispositivo de bloco padrão Linux, você pode usá-lo com sistemas de arquivo padrão, drivers iSCSI e FC alvo, ou como armazenamento unificado.

Nota

A implantação da VDO com a Ceph Storage não é atualmente suportada.

KVM

Você pode implantar o VDO em um servidor KVM configurado com Armazenamento Direto Acoplado.

VDO Deployment with KVM

Sistemas de arquivo

Você pode criar sistemas de arquivo em cima do VDO e expô-los aos usuários NFS ou CIFS com o servidor NFS ou Samba.

Deduplicated NAS

meta iSCSI

Você pode exportar a totalidade do alvo de armazenamento VDO como um alvo iSCSI para iniciadores iSCSI remotos.

Deduplicated block storage target

LVM

Em sistemas mais ricos em recursos, você pode usar LVM para fornecer múltiplos números de unidades lógicas (LUNs) que são todos apoiados pelo mesmo pool de armazenamento dedicado.

No diagrama a seguir, a meta VDO é registrada como um volume físico para que possa ser gerenciada pela LVM. Vários volumes lógicos (LV1 a LV4) são criados a partir do pool de armazenamento deduplicado. Desta forma, o VDO pode suportar o bloco unificado multiprotocolo ou o acesso a arquivos ao pool de armazenamento dedicado subjacente.

Deduplicated unified storage

O projeto de armazenamento unificado dedicado permite que vários sistemas de arquivos utilizem coletivamente o mesmo domínio de deduplicação através das ferramentas LVM. Além disso, os sistemas de arquivo podem aproveitar as vantagens do LVM snapshot, copy-on-write e recursos de encolher ou crescer, tudo em cima do VDO.

Criptografia

Mecanismos de mapeamento de dispositivos (DM) tais como DM Crypt são compatíveis com VDO. Criptografar volumes VDO ajuda a garantir a segurança dos dados, e quaisquer sistemas de arquivo acima do VDO ainda são deduplicados.

Using VDO with encryption
Importante

A aplicação da camada de criptografia acima da VDO resulta em pouca ou nenhuma desduplicação de dados. A encriptação torna os blocos duplicados diferentes antes que a VDO possa deduplicá-los.

Sempre coloque a camada de criptografia abaixo da VDO.

1.3. Componentes de um volume VDO

A VDO usa um dispositivo de bloco como armazém de apoio, que pode incluir uma agregação de armazenamento físico consistindo de um ou mais discos, divisórias ou até mesmo arquivos planos. Quando uma ferramenta de gerenciamento de armazenamento cria um volume VDO, a VDO reserva espaço de volume para o índice UDS e volume VDO. O índice UDS e o volume VDO interagem entre si para proporcionar um armazenamento em bloco dedicado.

Figura 1.1. Organização do disco VDO

VDO disk organization

A solução VDO consiste nos seguintes componentes:

kvdo

Um módulo de kernel que carrega na camada de mapeamento de dispositivos Linux fornece um volume de armazenamento de blocos deduplicado, comprimido e com pouca provisão.

O módulo kvdo expõe um dispositivo de bloco. Você pode acessar este dispositivo de bloco diretamente para armazenamento em bloco ou apresentá-lo através de um sistema de arquivo Linux, como XFS ou ext4.

Quando kvdo recebe uma solicitação para ler um bloco lógico de dados de um volume VDO, ele mapeia o bloco lógico solicitado para o bloco físico subjacente e então lê e retorna os dados solicitados.

Quando kvdo recebe um pedido para escrever um bloco de dados para um volume VDO, ele primeiro verifica se o pedido é um pedido DISCARD ou TRIM ou se os dados são uniformemente zero. Se alguma destas condições for verdadeira, kvdo atualiza seu mapa de blocos e reconhece o pedido. Caso contrário, a VDO processa e otimiza os dados.

uds

Um módulo de kernel que se comunica com o índice do Serviço de Deduplicação Universal (UDS) sobre o volume e analisa os dados para duplicatas. Para cada novo dado, o UDS determina rapidamente se esse dado é idêntico a qualquer dado previamente armazenado. Se o índice encontrar uma correspondência, o sistema de armazenamento pode então referenciar internamente o item existente para evitar o armazenamento da mesma informação mais de uma vez.

O índice UDS é executado dentro do kernel como o módulo do kernel uds.

Ferramentas de linha de comando
Para configurar e gerenciar o armazenamento otimizado.

1.4. O tamanho físico e lógico de um volume VDO

Esta seção descreve o tamanho físico, o tamanho físico disponível e o tamanho lógico que a VDO pode utilizar:

Tamanho físico

Este é o mesmo tamanho que o dispositivo de bloco subjacente. A VDO usa este armazenamento para:

  • Dados do usuário, que podem ser deduzidos e comprimidos
  • Metadados VDO, tais como o índice UDS
Tamanho físico disponível

Esta é a porção do tamanho físico que a VDO é capaz de usar para os dados do usuário

É equivalente ao tamanho físico menos o tamanho dos metadados, menos o restante após a divisão do volume em placas pelo tamanho da laje dada.

Tamanho lógico

Este é o tamanho provisionado que o volume VDO apresenta para as aplicações. Geralmente é maior do que o tamanho físico disponível. Se a opção --vdoLogicalSize não for especificada, então o provisionamento do volume lógico é agora provisionado para uma proporção de 1:1. Por exemplo, se um volume VDO for colocado em cima de um dispositivo de bloco de 20 GB, então 2,5 GB é reservado para o índice UDS (se o tamanho padrão do índice for usado). Os 17,5 GB restantes são fornecidos para os metadados e dados do usuário do VDO. Como resultado, o armazenamento disponível para consumo não é superior a 17,5 GB, e pode ser menor devido aos metadados que compõem o volume real do VDO.

A VDO suporta atualmente qualquer tamanho lógico até 254 vezes o tamanho do volume físico com um tamanho lógico máximo absoluto de 4PB.

Figura 1.2. Organização do disco VDO

VDO disk organization

Nesta figura, o alvo de armazenamento dedicado do VDO fica completamente em cima do dispositivo de bloco, o que significa que o tamanho físico do volume do VDO é o mesmo tamanho do dispositivo de bloco subjacente.

Recursos adicionais

1.5. Tamanho da laje em VDO

O armazenamento físico do volume do VDO é dividido em várias placas. Cada laje é uma região contígua do espaço físico. Todas as placas para um determinado volume têm o mesmo tamanho, que pode ser qualquer potência de 2 múltiplos de 128 MB até 32 GB.

O tamanho padrão da placa é de 2 GB a fim de facilitar a avaliação do VDO em sistemas de teste menores. Um único volume de VDO pode ter até 8192 lajes. Portanto, na configuração padrão com placas de 2 GB, o armazenamento físico máximo permitido é de 16 TB. Ao utilizar placas de 32 GB, o máximo de armazenamento físico permitido é de 256 TB. A VDO sempre reserva pelo menos uma placa inteira para metadados e, portanto, a placa reservada não pode ser usada para armazenamento de dados do usuário.

O tamanho da placa não tem efeito sobre o desempenho do volume VDO.

Tabela 1.1. Tamanhos de placas VDO recomendados por tamanho de volume físico

Tamanho do volume físicoTamanho recomendado da laje

10-99 GB

1 GB

100 GB - 1 TB

2 GB

2-256 TB

32 GB

Você pode controlar o tamanho da laje, fornecendo o --vdoSlabSize=megabytes para o comando vdo create.

1.6. Requisitos VDO

A VDO tem certas exigências quanto à sua colocação e aos recursos de seu sistema.

1.6.1. Requisitos de memória VDO

Cada volume VDO tem dois requisitos distintos de memória:

O módulo VDO

A VDO requer um fixo de 38 MB de RAM e vários valores variáveis:

  • 1.15 MB de RAM para cada 1 MB de cache de mapa de bloco configurado. O cache de mapa de blocos requer um mínimo de 150MB de RAM.
  • 1.6 MB de RAM para cada 1 TB de espaço lógico.
  • 268 MB de RAM para cada 1 TB de armazenamento físico gerenciado pelo volume.

O índice UDS

O Serviço de Deduplicação Universal (UDS) requer um mínimo de 250 MB de RAM, que também é a quantidade padrão que a deduplicação utiliza. Você pode configurar o valor ao formatar um volume VDO, pois o valor também afeta a quantidade de armazenamento que o índice necessita.

A memória necessária para o índice UDS é determinada pelo tipo de índice e pelo tamanho requerido da janela de deduplicação:

Tipo de índiceJanela de deduplicaçãoNota

Densa

1 TB por 1 GB de RAM

Um índice denso de 1 GB é geralmente suficiente para até 4 TB de armazenamento físico.

Pouco tempo

10 TB por 1 GB de RAM

Um índice esparso de 1 GB é geralmente suficiente para até 40 TB de armazenamento físico.

O recurso UDS Sparse Indexing é o modo recomendado para VDO. Ela se baseia na localização temporal dos dados e tenta reter apenas as entradas de índice mais relevantes na memória. Com o índice esparso, o UDS pode manter uma janela de deduplicação dez vezes maior do que com o denso, enquanto usa a mesma quantidade de memória.

Embora o índice esparso forneça a maior cobertura, o índice denso fornece mais conselhos de deduplicação. Para a maioria das cargas de trabalho, dada a mesma quantidade de memória, a diferença nas taxas de deduplicação entre os índices denso e esparso é insignificante.

Recursos adicionais

1.6.2. Requisitos de espaço de armazenamento da VDO

Você pode configurar um volume VDO para usar até 256 TB de armazenamento físico. Apenas uma determinada parte do armazenamento físico é utilizável para armazenar dados. Esta seção fornece os cálculos para determinar o tamanho utilizável de um volume gerenciado por VDO.

A VDO requer armazenamento para dois tipos de metadados VDO e para o índice UDS:

  • O primeiro tipo de metadados VDO usa aproximadamente 1 MB para cada 4 GB de physical storage mais 1 MB adicional por placa.
  • O segundo tipo de metadados VDO consome aproximadamente 1,25 MB para cada 1 GB de logical storage, arredondado para a laje mais próxima.
  • A quantidade de armazenamento necessária para o índice UDS depende do tipo de índice e da quantidade de RAM alocada para o índice. Para cada 1 GB de RAM, um índice UDS denso usa 17 GB de armazenamento, e um índice UDS esparso usará 170 GB de armazenamento.

Recursos adicionais

1.6.3. Colocação da VDO na pilha de armazenamento

Você deve colocar certas camadas de armazenamento sob a VDO e outras acima da VDO.

Um volume VDO é um dispositivo de bloco com pouca provisão. Para evitar o esgotamento do espaço físico, coloque o volume em cima do armazenamento que você pode expandir posteriormente. Exemplos de tal armazenamento expansível são volumes LVM ou matrizes MD RAID.

Você pode colocar camadas espessas em cima da VDO, mas não pode contar com as garantias de provisionamento espesso nesse caso. Como a camada VDO é de provisão fina, os efeitos da provisão fina se aplicam a todas as camadas acima dela. Se você não monitorar o dispositivo VDO, você pode ficar sem espaço físico em volumes de fornecimento grosso sobre o VDO.

Configurações suportadas

  • Camadas que você só pode colocar sob VDO:

    • DM Multipath
    • Cripta DM
    • RAID por software (LVM ou MD RAID)
  • Camadas que você só pode colocar acima da VDO:

    • LVM cache
    • Snapshots de LVM
    • Provisão fina de LVM

Configurações não suportadas

  • VDO em cima de outros volumes VDO
  • VDO em cima de snapshots de LVM
  • VDO no topo do cache LVM
  • VDO em cima de um dispositivo de loopback
  • VDO em cima do provisionamento fino da LVM
  • Volumes criptografados em cima do VDO
  • Partições em um volume VDO
  • RAID, como LVM RAID, MD RAID, ou qualquer outro tipo, em cima de um volume VDO

Recursos adicionais

1.6.4. Exemplos de requisitos VDO por tamanho físico

As tabelas a seguir fornecem os requisitos aproximados do sistema VDO com base no tamanho físico do volume subjacente. Cada tabela lista os requisitos apropriados à implantação pretendida, tais como armazenamento primário ou de reserva.

Os números exatos dependem de sua configuração do volume do VDO.

Implantação do armazenamento primário

No caso do armazenamento primário, o índice UDS está entre 0,01% a 25% do tamanho do tamanho físico.

Tabela 1.2. Requisitos de armazenamento e memória para armazenamento primário

Tamanho físicoUso de RAM: UDSUso de RAM: VDOUso do discoTipo de índice

10GB-1TB

250MB

472MB

2.5GB

Densa

2-10TB

1 GB

3GB

10 GB

Densa

250MB

22GB

Pouco tempo

11-50TB

2GB

14GB

170GB

Pouco tempo

51-100TB

3GB

27 GB

255GB

Pouco tempo

101-256TB

12GB

69GB

1020GB

Pouco tempo

Implantação de backup de armazenamento

No caso de armazenamento de backup, o índice UDS cobre o tamanho do conjunto de backup, mas não é maior do que o tamanho físico. Se você espera que o conjunto de backup ou o tamanho físico cresça no futuro, fator este no tamanho do índice.

Tabela 1.3. Requisitos de armazenamento e memória para armazenamento de backup

Tamanho físicoUso de RAM: UDSUso de RAM: VDOUso do discoTipo de índice

10GB-1TB

250MB

472MB

2.5 GB

Densa

2-10TB

2GB

3GB

170GB

Pouco tempo

11-50TB

10 GB

14GB

850 GB

Pouco tempo

51-100TB

20 GB

27 GB

1700GB

Pouco tempo

101-256TB

26 GB

69GB

3400GB

Pouco tempo

1.7. Instalando o VDO

Este procedimento instala o software necessário para criar, montar e gerenciar volumes VDO.

Procedimento

  • Instale os pacotes vdo e kmod-kvdo:

    # yum instalar vdo kmod-kvdo

1.8. Criando um volume VDO

Este procedimento cria um volume VDO em um dispositivo de bloco.

Pré-requisitos

Procedimento

Em todas as etapas a seguir, substitua vdo-name com o identificador que você deseja utilizar para seu volume VDO; por exemplo, vdo1. Você deve usar um nome e um dispositivo diferente para cada instância de VDO no sistema.

  1. Encontre um nome persistente para o dispositivo de bloco onde você deseja criar o volume VDO. Para mais informações sobre nomes persistentes, veja Capítulo 6, Visão geral dos atributos de nomeação persistentes.

    Se você usar um nome de dispositivo não-persistente, então a VDO poderá não conseguir iniciar corretamente no futuro se o nome do dispositivo mudar.

  2. Criar o volume VDO:

    # vdo create \
          --name=vdo-name \
          --device=block-device \
          --vdoLogicalSize=logical-size
    • Substitua block-device com o nome persistente do dispositivo do bloco onde se deseja criar o volume VDO. Por exemplo, /dev/disk/by-id/scsi-3600508b1001c264ad2af21e903ad031f.
    • Substitua logical-size com a quantidade de armazenamento lógico que o volume VDO deve apresentar:

      • Para VMs ativas ou armazenamento de containers, use o tamanho lógico que é ten vezes o tamanho físico de seu dispositivo de bloco. Por exemplo, se o seu dispositivo de bloco tiver 1TB de tamanho, use 10T aqui.
      • Para armazenamento de objetos, use o tamanho lógico que é three vezes o tamanho físico de seu dispositivo de bloco. Por exemplo, se seu dispositivo de bloco tiver 1TB de tamanho, use 3T aqui.
    • Se o dispositivo de bloco físico for maior que 16TiB, adicione a opção --vdoSlabSize=32G para aumentar o tamanho da laje no volume para 32GiB.

      Usando o tamanho padrão da placa de 2GiB em dispositivos de blocos maiores que 16TiB resulta na falha do comando vdo create com o seguinte erro:

      vdo: ERROR - vdoformat: formatVDO falhou em '/dev/device': Status VDO: Supera o número máximo de lajes suportadas

    Exemplo 1.1. Criação de VDO para armazenagem de contêineres

    Por exemplo, para criar um volume VDO para armazenamento de contêineres em um dispositivo de bloco de 1TB, você pode usar:

    # vdo create \
          --name=vdo1 \
          --device=/dev/disk/by-id/scsi-3600508b1001c264ad2af21e903ad031f \
          --vdoLogicalSize=10T
    Importante

    Se ocorrer uma falha ao criar o volume VDO, remova o volume para limpar. Veja Seção 2.10.2, “Removendo um volume VDO criado sem sucesso” para detalhes.

  3. Criar um sistema de arquivo em cima do volume do VDO:

    • Para o sistema de arquivos XFS:

      # mkfs.xfs -K /dev/mapper/vdo-name
    • Para o sistema de arquivo ext4:

      # mkfs.ext4 -E nodiscard /dev/mapper/vdo-name
  4. Use o seguinte comando para esperar que o sistema registre o novo nó de dispositivo:

    # udevadm assentar

Próximos passos

  1. Montar o sistema de arquivo. Veja Seção 1.9, “Montagem de um volume VDO” para detalhes.
  2. Habilite o recurso discard para o sistema de arquivo em seu dispositivo VDO. Veja Seção 1.10, “Possibilitando o descarte periódico em bloco” para detalhes.

Recursos adicionais

  • A página do homem vdo(8)

1.9. Montagem de um volume VDO

Este procedimento monta um sistema de arquivo em um volume VDO, seja manualmente ou persistentemente.

Pré-requisitos

Procedimento

  • Para montar o sistema de arquivo no volume do VDO manualmente, use:

    # montagem /dev/mapper/vdo-name mount-point
  • Para configurar o sistema de arquivo para montar automaticamente na inicialização, adicione uma linha ao arquivo /etc/fstab:

    • Para o sistema de arquivos XFS:

      /dev/mapper/vdo-name mount-point xfs defaults,_netdev,x-systemd.device-timeout=0,x-systemd.requires=vdo.service 0 0
    • Para o sistema de arquivo ext4:

      /dev/mapper/vdo-name mount-point ext4 defaults,_netdev,x-systemd.device-timeout=0,x-systemd.requires=vdo.service 0 0

Recursos adicionais

  • A página do homem vdo(8)

1.10. Possibilitando o descarte periódico em bloco

Este procedimento permite um temporizador systemd que descarta regularmente blocos não utilizados em todos os sistemas de arquivo suportados.

Procedimento

  • Habilitar e iniciar o temporizador systemd:

    # systemctl habilita --now fstrim.timer

1.11. Monitoramento VDO

Este procedimento descreve como obter informações de uso e eficiência de um volume VDO.

Pré-requisitos

Procedimento

  • Use o utilitário vdostats para obter informações sobre um volume VDO:

    # vdostats --human-readable
    
    Device                   1K-blocks    Used     Available    Use%    Space saving%
    /dev/mapper/node1osd1    926.5G       21.0G    905.5G       2%      73%
    /dev/mapper/node1osd2    926.5G       28.2G    898.3G       3%      64%

Recursos adicionais

  • A página do homem vdostats(8).

Capítulo 2. Mantendo a VDO

Após implantar um volume VDO, você pode realizar certas tarefas para mantê-lo ou otimizá-lo. Algumas das seguintes tarefas são necessárias para o correto funcionamento dos volumes VDO.

Pré-requisitos

2.1. Gerenciando o espaço livre em volumes VDO

O VDO é um alvo de armazenamento em bloco com pouca provisão. Devido a isso, é necessário monitorar e gerenciar ativamente o uso do espaço nos volumes VDO.

2.1.1. O tamanho físico e lógico de um volume VDO

Esta seção descreve o tamanho físico, o tamanho físico disponível e o tamanho lógico que a VDO pode utilizar:

Tamanho físico

Este é o mesmo tamanho que o dispositivo de bloco subjacente. A VDO usa este armazenamento para:

  • Dados do usuário, que podem ser deduzidos e comprimidos
  • Metadados VDO, tais como o índice UDS
Tamanho físico disponível

Esta é a porção do tamanho físico que a VDO é capaz de usar para os dados do usuário

É equivalente ao tamanho físico menos o tamanho dos metadados, menos o restante após a divisão do volume em placas pelo tamanho da laje dada.

Tamanho lógico

Este é o tamanho provisionado que o volume VDO apresenta para as aplicações. Geralmente é maior do que o tamanho físico disponível. Se a opção --vdoLogicalSize não for especificada, então o provisionamento do volume lógico é agora provisionado para uma proporção de 1:1. Por exemplo, se um volume VDO for colocado em cima de um dispositivo de bloco de 20 GB, então 2,5 GB é reservado para o índice UDS (se o tamanho padrão do índice for usado). Os 17,5 GB restantes são fornecidos para os metadados e dados do usuário do VDO. Como resultado, o armazenamento disponível para consumo não é superior a 17,5 GB, e pode ser menor devido aos metadados que compõem o volume real do VDO.

A VDO suporta atualmente qualquer tamanho lógico até 254 vezes o tamanho do volume físico com um tamanho lógico máximo absoluto de 4PB.

Figura 2.1. Organização do disco VDO

VDO disk organization

Nesta figura, o alvo de armazenamento dedicado do VDO fica completamente em cima do dispositivo de bloco, o que significa que o tamanho físico do volume do VDO é o mesmo tamanho do dispositivo de bloco subjacente.

Recursos adicionais

2.1.2. Provisão fina em VDO

O VDO é um alvo de armazenamento em bloco com pouca provisão. A quantidade de espaço físico que um volume VDO utiliza pode ser diferente do tamanho do volume que é apresentado aos usuários do armazenamento. Você pode fazer uso desta disparidade para economizar nos custos de armazenamento.

Condições fora do espaço

Tome cuidado para evitar que o espaço de armazenamento fique inesperadamente esgotado, se os dados escritos não atingirem a taxa de otimização esperada.

Sempre que o número de blocos lógicos (armazenamento virtual) excede o número de blocos físicos (armazenamento real), torna-se possível que os sistemas de arquivos e aplicações fiquem sem espaço inesperado. Por esse motivo, os sistemas de armazenamento que utilizam VDO devem fornecer uma forma de monitorar o tamanho do pool livre no volume do VDO.

Você pode determinar o tamanho deste pool gratuito usando o utilitário vdostats. A saída padrão deste utilitário lista informações para todos os volumes VDO em execução em um formato similar ao utilitário Linux df. Por exemplo, o utilitário VDO:

Device                1K-blocks   Used        Available   Use%
/dev/mapper/vdo-name  211812352   105906176   105906176   50%

Quando a capacidade de armazenamento físico de um volume VDO está quase cheia, a VDO relata um aviso no registro do sistema, semelhante ao seguinte:

Oct  2 17:13:39 system lvm[13863]: Monitoring VDO pool vdo-name.
Oct  2 17:27:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 80.69% full.
Oct  2 17:28:19 system lvm[13863]: WARNING: VDO pool vdo-name is now 85.25% full.
Oct  2 17:29:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 90.64% full.
Oct  2 17:30:29 system lvm[13863]: WARNING: VDO pool vdo-name is now 96.07% full.
Nota

Estas mensagens de aviso aparecem somente quando o serviço lvm2-monitor está em funcionamento. Ele é ativado por padrão.

Como evitar condições fora do espaço

Se o tamanho da piscina livre cair abaixo de um certo nível, você pode tomar providências:

  • Eliminação de dados. Isto recupera espaço sempre que os dados excluídos não forem duplicados. A eliminação de dados libera o espaço somente depois que os descartes são emitidos.
  • Acréscimo de armazenamento físico
Importante

Monitore o espaço físico em seus volumes VDO para evitar situações fora do espaço. Ficar sem blocos físicos pode resultar na perda de dados escritos recentemente, não reconhecidos, sobre o volume do VDO.

Provisão fina e os comandos TRIM e DISCARD

Para se beneficiar da economia de armazenamento do provisionamento fino, a camada de armazenamento físico precisa saber quando os dados são apagados. Sistemas de arquivos que trabalham com armazenamento thinly provisioned enviam os comandos TRIM ou DISCARD para informar o sistema de armazenamento quando um bloco lógico não for mais necessário.

Vários métodos de envio dos comandos TRIM ou DISCARD estão disponíveis:

  • Com a opção de montagem discard, os sistemas de arquivo podem enviar estes comandos sempre que um bloco for excluído.
  • Você pode enviar os comandos de forma controlada, utilizando utilitários como fstrim. Estes utilitários dizem ao sistema de arquivos para detectar quais blocos lógicos não são utilizados e enviar as informações ao sistema de armazenamento na forma de um comando TRIM ou DISCARD.

A necessidade de utilizar TRIM ou DISCARD em blocos não utilizados não é exclusiva da VDO. Qualquer sistema de armazenamento com pouca provisão tem o mesmo desafio.

2.1.3. Monitoramento VDO

Este procedimento descreve como obter informações de uso e eficiência de um volume VDO.

Pré-requisitos

Procedimento

  • Use o utilitário vdostats para obter informações sobre um volume VDO:

    # vdostats --human-readable
    
    Device                   1K-blocks    Used     Available    Use%    Space saving%
    /dev/mapper/node1osd1    926.5G       21.0G    905.5G       2%      73%
    /dev/mapper/node1osd2    926.5G       28.2G    898.3G       3%      64%

Recursos adicionais

  • A página do homem vdostats(8).

2.1.4. Recuperação de espaço para VDO em sistemas de arquivo

Este procedimento recupera espaço de armazenamento em um volume VDO que hospeda um sistema de arquivo.

A VDO não pode recuperar espaço a menos que os sistemas de arquivo comuniquem que os blocos estão livres usando os comandos DISCARD, TRIM, ou UNMAP.

Procedimento

  • Se o sistema de arquivo em seu volume VDO suportar operações de descarte, ative-os. Ver Capítulo 5, Descartando blocos não utilizados.
  • Para sistemas de arquivo que não utilizam DISCARD, TRIM, ou UNMAP, você pode recuperar manualmente o espaço livre. Armazene um arquivo composto de zeros binários para preencher o espaço livre e depois exclua esse arquivo.

2.1.5. Recuperação de espaço para VDO sem sistema de arquivo

Este procedimento recupera espaço de armazenamento em um volume VDO que é usado como um alvo de armazenamento em bloco sem um sistema de arquivo.

Procedimento

  • Use o utilitário blkdiscard.

    Por exemplo, um único volume VDO pode ser esculpido em vários subvolumes, implantando LVM em cima dele. Antes de desprovisionar um volume lógico, use o utilitário blkdiscard para liberar o espaço usado anteriormente por aquele volume lógico.

    A LVM suporta o comando REQ_DISCARD e encaminha as solicitações para a VDO nos endereços de bloco lógico apropriados, a fim de liberar o espaço. Se você usar outros gerentes de volume, eles também precisam suportar REQ_DISCARD, ou equivalente, UNMAP para dispositivos SCSI ou TRIM para dispositivos ATA.

Recursos adicionais

  • A página do homem blkdiscard(8)

2.1.6. Recuperação de espaço para VDO em Fibre Channel ou rede Ethernet

Este procedimento recupera espaço de armazenamento em volumes VDO (ou porções de volumes) que são provisionados para hosts em um tecido de armazenamento Fibre Channel ou em uma rede Ethernet usando estruturas-alvo SCSI, como LIO ou SCST.

Procedimento

  • Os iniciadores SCSI podem usar o comando UNMAP para liberar espaço em alvos de armazenamento pouco provisionados, mas a estrutura de alvos SCSI precisa ser configurada para anunciar o suporte a este comando. Isso normalmente é feito viabilizando o provisionamento fino sobre esses volumes.

    Verifique o suporte para UNMAP em iniciadores SCSI baseados em Linux executando o seguinte comando:

    # sg_vpd --page=0xb0 /dev/device

    Na saída, verifique se o valor Maximum unmap LBA count é maior que zero.

2.2. Iniciando ou parando volumes VDO

Você pode iniciar ou parar um determinado volume VDO, ou todos os volumes VDO, e seus índices UDS associados.

2.2.1. Volumes VDO iniciados e ativados

Durante a inicialização do sistema, a unidade vdo systemd automaticamente starts todos os dispositivos VDO que são configurados como activated.

A unidade vdo systemd é instalada e ativada por padrão quando o pacote vdo é instalado. Esta unidade executa automaticamente o comando vdo start --all na inicialização do sistema para trazer à tona todos os volumes VDO ativados.

Você também pode criar um volume VDO que não comece automaticamente, adicionando a opção --activate=disabled ao comando vdo create.

A ordem inicial

Alguns sistemas podem colocar volumes LVM tanto acima dos volumes VDO quanto abaixo deles. Nesses sistemas, é necessário iniciar os serviços na ordem correta:

  1. A camada inferior da LVM deve começar primeiro. Na maioria dos sistemas, o início desta camada é configurado automaticamente quando o pacote LVM é instalado.
  2. A unidade vdo systemd deve começar então.
  3. Finalmente, scripts adicionais devem ser executados a fim de iniciar volumes LVM ou outros serviços em cima dos volumes VDO em execução.

Quanto tempo leva para parar um volume

A parada de um volume VDO leva tempo com base na velocidade de seu dispositivo de armazenamento e na quantidade de dados que o volume precisa para escrever:

  • O volume sempre escreve em torno de 1GiB para cada 1GiB do índice UDS.
  • O volume adicionalmente escreve a quantidade de dados igual ao tamanho do cache do mapa de blocos mais até 8MiB por laje.
  • O volume deve terminar o processamento de todos os pedidos de IO pendentes.

2.2.2. Iniciando um volume VDO

Este procedimento inicia um determinado volume VDO ou todos os volumes VDO em seu sistema.

Procedimento

  • Para iniciar um determinado volume de VDO, use:

    # vdo start --name=my-vdo
  • Para iniciar todos os volumes VDO, use:

    # vdo start -- tudo

Recursos adicionais

  • A página do homem vdo(8)

2.2.3. Parando um volume VDO

Este procedimento interrompe um determinado volume VDO ou todos os volumes VDO em seu sistema.

Procedimento

  1. Pare o volume.

    • Para parar um determinado volume de VDO, use:

      # vdo stop --name=my-vdo
    • Para parar todos os volumes VDO, use:

      # vdo stop -- tudo
  2. Aguarde que o volume termine de escrever os dados no disco.

Recursos adicionais

  • A página do homem vdo(8)

2.3. Inicialização automática dos volumes VDO na inicialização do sistema

Você pode configurar os volumes VDO para que eles comecem automaticamente na inicialização do sistema. Você também pode desativar a partida automática.

2.3.1. Volumes VDO iniciados e ativados

Durante a inicialização do sistema, a unidade vdo systemd automaticamente starts todos os dispositivos VDO que são configurados como activated.

A unidade vdo systemd é instalada e ativada por padrão quando o pacote vdo é instalado. Esta unidade executa automaticamente o comando vdo start --all na inicialização do sistema para trazer à tona todos os volumes VDO ativados.

Você também pode criar um volume VDO que não comece automaticamente, adicionando a opção --activate=disabled ao comando vdo create.

A ordem inicial

Alguns sistemas podem colocar volumes LVM tanto acima dos volumes VDO quanto abaixo deles. Nesses sistemas, é necessário iniciar os serviços na ordem correta:

  1. A camada inferior da LVM deve começar primeiro. Na maioria dos sistemas, o início desta camada é configurado automaticamente quando o pacote LVM é instalado.
  2. A unidade vdo systemd deve começar então.
  3. Finalmente, scripts adicionais devem ser executados a fim de iniciar volumes LVM ou outros serviços em cima dos volumes VDO em execução.

Quanto tempo leva para parar um volume

A parada de um volume VDO leva tempo com base na velocidade de seu dispositivo de armazenamento e na quantidade de dados que o volume precisa para escrever:

  • O volume sempre escreve em torno de 1GiB para cada 1GiB do índice UDS.
  • O volume adicionalmente escreve a quantidade de dados igual ao tamanho do cache do mapa de blocos mais até 8MiB por laje.
  • O volume deve terminar o processamento de todos os pedidos de IO pendentes.

2.3.2. Ativação de um volume VDO

Este procedimento ativa um volume VDO para permitir que ele inicie automaticamente.

Procedimento

  • Para ativar um volume específico:

    # vdo activate --name=my-vdo
  • Para ativar todos os volumes:

    # vdo activate --tudo

Recursos adicionais

  • A página do homem vdo(8)

2.3.3. Desativação de um volume VDO

Este procedimento desativa um volume VDO para evitar que ele se inicie automaticamente.

Procedimento

  • Para desativar um volume específico:

    # vdo desativar --name=my-vdo
  • Para desativar todos os volumes:

    # vdo desativar -- tudo

Recursos adicionais

  • A página do homem vdo(8)

2.4. Selecionando um modo de escrita VDO

Você pode configurar o modo de gravação para um volume VDO, com base no que o dispositivo de bloco subjacente requer. Por padrão, o VDO seleciona o modo de gravação automaticamente.

2.4.1. Modos de escrita VDO

A VDO suporta os seguintes modos de escrita:

sync

Quando a VDO está no modo sync, as camadas acima assumem que um comando de gravação grava dados para armazenamento persistente. Como resultado, não é necessário que o sistema de arquivo ou aplicativo, por exemplo, emita FLUSH ou force o acesso por unidade (FUA) a fazer com que os dados se tornem persistentes em pontos críticos.

O VDO deve ser configurado para o modo sync somente quando o armazenamento subjacente garantir que os dados sejam escritos para armazenamento persistente quando o comando de gravação for concluído. Isto é, o armazenamento deve ou não ter cache de gravação volátil, ou ter um cache de gravação através do cache.

async

Quando a VDO está no modo async, a VDO não garante que os dados sejam escritos para armazenamento persistente quando um comando de gravação é reconhecido. O sistema de arquivo ou aplicativo deve emitir solicitações FLUSH ou FUA para garantir a persistência dos dados em pontos críticos em cada transação.

O VDO deve ser configurado para o modo async se o armazenamento subjacente não garantir que os dados sejam gravados em armazenamento persistente quando o comando de gravação for concluído; isto é, quando o armazenamento tiver um cache de gravação de volta volátil.

async-unsafe

Este modo tem as mesmas propriedades do async, mas não é compatível com Atomicidade, Consistência, Isolamento, Durabilidade (ACID). Comparado a async, async-unsafe tem um melhor desempenho.

Atenção

Quando uma aplicação ou um sistema de arquivo que assume a conformidade ACID opera em cima do volume do VDO, o modo async-unsafe pode causar perda de dados inesperada.

auto
O modo auto seleciona automaticamente sync ou async com base nas características de cada dispositivo. Esta é a opção padrão.

2.4.2. O processamento interno dos modos de escrita VDO

Esta seção fornece detalhes sobre como funcionam os modos de escrita sync e async VDO.

Se o módulo kvdo estiver operando em modo síncrono:

  1. Ele escreve temporariamente os dados no pedido para o bloco alocado e depois reconhece o pedido.
  2. Uma vez concluído o reconhecimento, é feita uma tentativa de deduplicar o bloco através do cálculo de uma assinatura MurmurHash-3 dos dados do bloco, que é enviada para o índice VDO.
  3. Se o índice VDO contém uma entrada para um bloco com a mesma assinatura, kvdo lê o bloco indicado e faz uma comparação byte por byte dos dois blocos para verificar se são idênticos.
  4. Se forem de fato idênticos, então kvdo atualiza seu mapa de blocos para que o bloco lógico aponte para o bloco físico correspondente e libere o bloco físico alocado.
  5. Se o índice VDO não contém uma entrada para a assinatura do bloco que está sendo escrito, ou se o bloco indicado não contém realmente os mesmos dados, kvdo atualiza seu mapa de blocos para tornar o bloco físico temporário permanente.

Se kvdo estiver operando em modo assíncrono:

  1. Em vez de escrever os dados, ele reconhecerá imediatamente o pedido.
  2. Tentará então deduplicar o bloco da mesma forma descrita acima.
  3. Se o bloco se tornar um duplicado, kvdo atualiza seu mapa de blocos e libera o bloco alocado. Caso contrário, ele escreve os dados no pedido para o bloco alocado e atualiza o mapa de blocos para tornar o bloco físico permanente.

2.4.3. Verificação do modo de gravação em um volume VDO

Este procedimento lista o modo de gravação ativa em um volume VDO selecionado.

Procedimento

  • Use o seguinte comando para ver o modo de escrita usado por um volume VDO:

    # vdo status --name=my-vdo

    As listas de saída:

    • O configured write policy, que é a opção selecionada de sync, async, ou auto
    • O write policy, que é o modo particular de escrita aplicado pela VDO, ou seja, sync ou async

2.4.4. Verificação da existência de um cache volátil

Este procedimento determina se um dispositivo de bloco tem ou não um cache volátil. Você pode usar as informações para escolher entre os modos de escrita sync e async VDO.

Procedimento

  1. Use um dos seguintes métodos para determinar se um dispositivo tem um cache de gravação:

    • Leia o /sys/block/block-device/device/scsi_disk/identifier/cache_type sysfs arquivo. Por exemplo:

      $ cat '/sys/block/sda/device/scsi_disk/7:0:0:0/cache_type'
      
      write back
      $ cat '/sys/block/sdb/device/scsi_disk/1:2:0:0/cache_type'
      
      None
    • Alternativamente, você pode descobrir se os dispositivos acima mencionados têm ou não um cache de gravação no log de inicialização do kernel:

      sd 7:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
      sd 1:2:0:0: [sdb] Write cache: disabled, read cache: disabled, supports DPO and FUA
  2. Nos exemplos anteriores:

    • O dispositivo sda indica que ele has é um cache de retorno. Use o modo async para isso.
    • O dispositivo sdb indica que ele does not have é um cache de retorno. Use o modo sync para isso.

    Você deve configurar o VDO para usar o modo de escrita sync se o valor cache_type for None ou write through.

2.4.5. Configurando um modo de escrita VDO

Este procedimento estabelece um modo de escrita para um volume VDO, seja para um volume existente ou ao criar um novo volume.

Importante

O uso de um modo de gravação incorreto pode resultar em perda de dados após uma falha de energia, uma falha do sistema ou qualquer perda inesperada de contato com o disco.

Pré-requisitos

Procedimento

  • Você pode definir um modo de gravação em um volume VDO existente ou ao criar um novo volume:

    • Para modificar um volume VDO existente, use:

      # vdo changeWritePolicy --writePolicy=sync|async|async-unsafe|auto \
                              --name=vdo-name
    • Para especificar um modo de escrita ao criar um volume VDO, acrescente o --writePolicy=sync|async|async-unsafe|auto para o comando vdo create.

2.5. Recuperando um volume VDO após um desligamento imundo

Você pode recuperar um volume VDO após um desligamento imundo para que ele possa continuar operando. A tarefa é, em sua maioria, automatizada. Além disso, você pode limpar depois que um volume VDO foi criado sem sucesso por causa de uma falha no processo.

2.5.1. Modos de escrita VDO

A VDO suporta os seguintes modos de escrita:

sync

Quando a VDO está no modo sync, as camadas acima assumem que um comando de gravação grava dados para armazenamento persistente. Como resultado, não é necessário que o sistema de arquivo ou aplicativo, por exemplo, emita FLUSH ou force o acesso por unidade (FUA) a fazer com que os dados se tornem persistentes em pontos críticos.

O VDO deve ser configurado para o modo sync somente quando o armazenamento subjacente garantir que os dados sejam escritos para armazenamento persistente quando o comando de gravação for concluído. Isto é, o armazenamento deve ou não ter cache de gravação volátil, ou ter um cache de gravação através do cache.

async

Quando a VDO está no modo async, a VDO não garante que os dados sejam escritos para armazenamento persistente quando um comando de gravação é reconhecido. O sistema de arquivo ou aplicativo deve emitir solicitações FLUSH ou FUA para garantir a persistência dos dados em pontos críticos em cada transação.

O VDO deve ser configurado para o modo async se o armazenamento subjacente não garantir que os dados sejam gravados em armazenamento persistente quando o comando de gravação for concluído; isto é, quando o armazenamento tiver um cache de gravação de volta volátil.

async-unsafe

Este modo tem as mesmas propriedades do async, mas não é compatível com Atomicidade, Consistência, Isolamento, Durabilidade (ACID). Comparado a async, async-unsafe tem um melhor desempenho.

Atenção

Quando uma aplicação ou um sistema de arquivo que assume a conformidade ACID opera em cima do volume do VDO, o modo async-unsafe pode causar perda de dados inesperada.

auto
O modo auto seleciona automaticamente sync ou async com base nas características de cada dispositivo. Esta é a opção padrão.

2.5.2. Recuperação de volume VDO

Quando um volume VDO reinicia após um desligamento imundo, a VDO realiza as seguintes ações:

  • Verifica a consistência dos metadados sobre o volume.
  • Reconstrói uma parte dos metadados para repará-lo, se necessário.

Os reconstruídos são automáticos e não requerem a intervenção do usuário.

A VDO pode reconstruir diferentes escritas, dependendo do modo de escrita ativa:

sync
Se a VDO estava rodando em armazenamento síncrono e a política de gravação foi definida para sync, todos os dados gravados no volume são totalmente recuperados.
async
Se a política de redação fosse async, algumas redações poderiam não ser recuperadas se não fossem tornadas duráveis. Isto é feito através do envio à VDO de um comando FLUSH ou de uma tag de escrita I/O com a bandeira FUA (force unit access). Isto pode ser feito a partir do modo usuário invocando uma operação de integridade de dados como fsync, fdatasync, sync, ou umount.

Em qualquer um dos modos, alguns escritos que não foram reconhecidos ou que não foram seguidos por um autoclismo também podem ser reconstruídos.

Recuperação automática e manual

Quando um volume VDO entra no modo de operação recovering, o VDO reconstrói automaticamente o volume impuro do VDO depois que ele volta a funcionar. Isto é chamado online recovery.

Se a VDO não conseguir recuperar um volume VDO com sucesso, ela coloca o volume no modo de operação read-only que persiste ao longo do volume reinicia. Você precisa consertar o problema manualmente, forçando uma reconstrução.

Recursos adicionais

2.5.3. Modos de operação VDO

Esta seção descreve os modos que indicam se um volume VDO está operando normalmente ou se está se recuperando de um erro.

Você pode exibir o modo de operação atual de um volume VDO usando o vdostats --verbose device comando. Veja o atributo Operating mode na saída.

normal
Este é o modo de operação padrão. Os volumes VDO estão sempre no modo normal, a menos que um dos estados a seguir force um modo diferente. Um volume VDO recém-criado começa no modo normal.
recovering

Quando um volume VDO não salva todos os seus metadados antes de ser desligado, ele entra automaticamente no modo recovering na próxima vez em que for ligado. As razões típicas para entrar neste modo são perda repentina de energia ou um problema do dispositivo de armazenamento subjacente.

No modo recovering, a VDO está fixando as contagens de referência para cada bloco físico de dados no dispositivo. A recuperação geralmente não leva muito tempo. O tempo depende do tamanho do volume do VDO, da velocidade do dispositivo de armazenamento subjacente e de quantos outros pedidos o VDO está tratando simultaneamente. O volume do VDO funciona normalmente com as seguintes exceções:

  • Inicialmente, a quantidade de espaço disponível para escrever pedidos sobre o volume pode ser limitada. Medida que mais metadados são recuperados, mais espaço livre se torna disponível.
  • Dados escritos enquanto o volume do VDO está se recuperando podem não se dedicar aos dados escritos antes da queda se esses dados estiverem em uma parte do volume que ainda não foi recuperada. O VDO pode comprimir os dados enquanto recupera o volume. Você ainda pode ler ou sobregravar blocos comprimidos.
  • Durante uma recuperação on-line, certas estatísticas não estão disponíveis: por exemplo, blocks in use e blocks free. Estas estatísticas ficam disponíveis quando a reconstrução é concluída.
  • Os tempos de resposta para leitura e escrita podem ser mais lentos do que o normal devido ao trabalho de recuperação em andamento

Você pode desligar com segurança o volume do VDO no modo recovering. Se a recuperação não terminar antes do desligamento, o dispositivo entra novamente no modo recovering na próxima vez em que for ligado.

O volume do VDO sai automaticamente do modo recovering e passa para o modo normal quando tem todas as contagens de referência fixadas. Nenhuma ação do administrador é necessária. Para detalhes, veja Seção 2.5.4, “Recuperando um volume VDO online”.

read-only

Quando um volume VDO encontra um erro interno fatal, ele entra no modo read-only. Os eventos que podem causar o modo read-only incluem a corrupção de metadados ou o dispositivo de armazenamento de backup tornando-se somente leitura. Este modo é um estado de erro.

No modo read-only, os dados lêem normalmente, mas os dados escritos sempre falham. O volume do VDO permanece no modo read-only até que um administrador conserte o problema.

Você pode desligar com segurança um volume VDO no modo read-only. O modo geralmente persiste depois que o volume do VDO é reiniciado. Em casos raros, o volume VDO não é capaz de gravar o estado read-only no dispositivo de armazenamento de apoio. Nestes casos, o VDO tenta fazer uma recuperação em seu lugar.

Uma vez que um volume está em modo somente leitura, não há garantia de que os dados sobre o volume não tenham sido perdidos ou corrompidos. Nesses casos, a Red Hat recomenda copiar os dados do volume somente leitura e possivelmente restaurar o volume a partir do backup.

Se o risco de corrupção de dados for aceitável, é possível forçar uma reconstrução offline dos metadados de volume do VDO para que o volume possa ser trazido de volta on-line e disponibilizado. A integridade dos dados reconstruídos não pode ser garantida. Para mais detalhes, consulte Seção 2.5.5, “Forçando uma reconstrução offline de um metadados de volume VDO”.

2.5.4. Recuperando um volume VDO online

Este procedimento realiza uma recuperação on-line em um volume VDO para recuperar metadados após um desligamento imundo.

Procedimento

  1. Se o volume do VDO ainda não tiver sido iniciado, inicie-o:

    # vdo start --name=my-vdo

    Não são necessárias medidas adicionais. A recuperação é feita em segundo plano.

  2. Se você conta com estatísticas de volume como blocks in use e blocks free, espere até que elas estejam disponíveis.

2.5.5. Forçando uma reconstrução offline de um metadados de volume VDO

Este procedimento realiza uma reconstrução forçada offline de um metadados de volume VDO para recuperar após um desligamento imundo.

Atenção

Este procedimento pode causar perda de dados sobre o volume.

Pré-requisitos

  • O volume VDO é iniciado.

Procedimento

  1. Verifique se o volume está no modo somente leitura. Veja o atributo operating mode na saída do comando:

    # vdo status --name=my-vdo

    Se o volume não estiver no modo somente leitura, não é necessário forçar uma reconstrução offline. Realizar uma recuperação on-line, conforme descrito em Seção 2.5.4, “Recuperando um volume VDO online”.

  2. Pare o volume se ele estiver funcionando:

    # vdo stop --name=my-vdo
  3. Reinicie o volume com a opção --forceRebuild:

    # vdo start --name=my-vdo --forceRebuild

2.5.6. Removendo um volume VDO criado sem sucesso

Este procedimento limpa um volume VDO em um estado intermediário. Um volume é deixado em um estado intermediário se ocorrer uma falha ao criar o volume. Isto pode acontecer quando, por exemplo:

  • O sistema trava
  • Falha de energia
  • O administrador interrompe um comando vdo create em execução

Procedimento

  • Para limpar, remover o volume criado sem sucesso com a opção --force:

    # vdo remove --force --name=my-vdo

    A opção --force é necessária porque o administrador pode ter causado um conflito ao alterar a configuração do sistema desde que o volume foi criado sem sucesso.

    Sem a opção --force, o comando vdo remove falha com a seguinte mensagem:

    [...]
    A previous operation failed.
    Recovery from the failure either failed or was interrupted.
    Add '--force' to 'remove' to perform the following cleanup.
    Steps to clean up VDO my-vdo:
    umount -f /dev/mapper/my-vdo
    udevadm settle
    dmsetup remove my-vdo
    vdo: ERROR - VDO volume my-vdo previous operation (create) is incomplete

2.6. Otimizando o índice UDS

Você pode configurar certas configurações do índice UDS para otimizá-lo em seu sistema.

Importante

Você não pode alterar as propriedades do índice UDS after criando o volume VDO.

2.6.1. Componentes de um volume VDO

A VDO usa um dispositivo de bloco como armazém de apoio, que pode incluir uma agregação de armazenamento físico consistindo de um ou mais discos, divisórias ou até mesmo arquivos planos. Quando uma ferramenta de gerenciamento de armazenamento cria um volume VDO, a VDO reserva espaço de volume para o índice UDS e volume VDO. O índice UDS e o volume VDO interagem entre si para proporcionar um armazenamento em bloco dedicado.

Figura 2.2. Organização do disco VDO

VDO disk organization

A solução VDO consiste nos seguintes componentes:

kvdo

Um módulo de kernel que carrega na camada de mapeamento de dispositivos Linux fornece um volume de armazenamento de blocos deduplicado, comprimido e com pouca provisão.

O módulo kvdo expõe um dispositivo de bloco. Você pode acessar este dispositivo de bloco diretamente para armazenamento em bloco ou apresentá-lo através de um sistema de arquivo Linux, como XFS ou ext4.

Quando kvdo recebe uma solicitação para ler um bloco lógico de dados de um volume VDO, ele mapeia o bloco lógico solicitado para o bloco físico subjacente e então lê e retorna os dados solicitados.

Quando kvdo recebe um pedido para escrever um bloco de dados para um volume VDO, ele primeiro verifica se o pedido é um pedido DISCARD ou TRIM ou se os dados são uniformemente zero. Se alguma destas condições for verdadeira, kvdo atualiza seu mapa de blocos e reconhece o pedido. Caso contrário, a VDO processa e otimiza os dados.

uds

Um módulo de kernel que se comunica com o índice do Serviço de Deduplicação Universal (UDS) sobre o volume e analisa os dados para duplicatas. Para cada novo dado, o UDS determina rapidamente se esse dado é idêntico a qualquer dado previamente armazenado. Se o índice encontrar uma correspondência, o sistema de armazenamento pode então referenciar internamente o item existente para evitar o armazenamento da mesma informação mais de uma vez.

O índice UDS é executado dentro do kernel como o módulo do kernel uds.

Ferramentas de linha de comando
Para configurar e gerenciar o armazenamento otimizado.

2.6.2. O índice UDS

A VDO usa um índice de deduplicação de alto desempenho chamado UDS para detectar blocos duplicados de dados à medida que estão sendo armazenados.

O índice UDS fornece a base do produto VDO. Para cada novo dado, ele determina rapidamente se esse dado é idêntico a qualquer dado previamente armazenado. Se o índice encontrar correspondência, o sistema de armazenamento pode então referenciar internamente o item existente para evitar o armazenamento da mesma informação mais de uma vez.

O índice UDS é executado dentro do kernel como o módulo do kernel uds.

O deduplication window é o número de blocos previamente escritos de que o índice se lembra. O tamanho da janela de deduplicação é configurável. Para um determinado tamanho de janela, o índice requer uma quantidade específica de RAM e uma quantidade específica de espaço em disco. O tamanho da janela é normalmente determinado especificando o tamanho da memória do índice usando a opção --indexMem=size. O VDO então determina a quantidade de espaço em disco a ser usada automaticamente.

O índice UDS é composto de duas partes:

  • Uma representação compacta é usada na memória que contém no máximo uma entrada por bloco único.
  • Um componente em disco que registra os nomes dos blocos associados apresentados ao índice à medida que eles ocorrem, em ordem.

A UDS usa uma média de 4 bytes por entrada na memória, incluindo o cache.

O componente em disco mantém um histórico limitado de dados passados à UDS. O UDS fornece conselhos de deduplicação de dados que se enquadram nesta janela de deduplicação, contendo os nomes dos blocos mais recentemente vistos. A janela de desduplicação permite ao UDS indexar dados da forma mais eficiente possível, enquanto limita a quantidade de memória necessária para indexar grandes repositórios de dados. Apesar da natureza limitada da janela de desduplicação, a maioria dos conjuntos de dados que têm altos níveis de desduplicação também exibe um alto grau de localidade temporal - em outras palavras, a maior parte da desduplicação ocorre entre conjuntos de blocos que foram escritos aproximadamente ao mesmo tempo. Além disso, em geral, os dados escritos são mais propensos a duplicar dados que foram escritos recentemente do que dados que foram escritos há muito tempo. Portanto, para uma determinada carga de trabalho em um determinado intervalo de tempo, as taxas de deduplicação muitas vezes serão as mesmas, quer os índices UDS indexem apenas os dados mais recentes ou todos os dados.

Como os dados duplicados tendem a exibir a localidade temporal, raramente é necessário indexar cada bloco no sistema de armazenamento. Se não fosse assim, o custo da memória de índice superaria a economia de custos de armazenamento reduzidos pela deduplicação. Os requisitos de tamanho do índice estão mais estreitamente relacionados com a taxa de ingestão de dados. Por exemplo, considere um sistema de armazenamento com 100 TB de capacidade total, mas com uma taxa de ingestão de 1 TB por semana. Com uma janela de deduplicação de 4 TB, o UDS pode detectar a maioria das redundâncias entre os dados escritos no último mês.

2.7. Habilitando ou desabilitando a deduplicação em VDO

Em alguns casos, você pode querer desativar temporariamente a deduplicação dos dados que estão sendo escritos em um volume VDO enquanto ainda mantém a capacidade de ler e escrever a partir do volume. A desabilitação da deduplicação impede que as escritas subseqüentes sejam deduplicadas, mas os dados que já foram deduplicados permanecem assim.

2.7.1. Deduplicação em VDO

A deduplicação é uma técnica para reduzir o consumo de recursos de armazenamento através da eliminação de múltiplas cópias de blocos duplicados.

Em vez de escrever os mesmos dados mais de uma vez, a VDO detecta cada bloco duplicado e o registra como uma referência ao bloco original. A VDO mantém um mapeamento desde endereços de blocos lógicos, que são usados pela camada de armazenamento acima da VDO, até endereços de blocos físicos, que são usados pela camada de armazenamento abaixo da VDO.

Após a deduplicação, vários endereços de blocos lógicos podem ser mapeados para o mesmo endereço de bloco físico. Estes são chamados de blocos compartilhados. O compartilhamento de blocos é invisível para os usuários do armazenamento, que lêem e escrevem blocos como fariam se a VDO não estivesse presente.

Quando um bloco compartilhado é sobrescrito, a VDO aloca um novo bloco físico para armazenar os dados do novo bloco para garantir que outros endereços lógicos do bloco que são mapeados para o bloco físico compartilhado não sejam modificados.

2.7.2. Possibilitando a deduplicação em um volume VDO

Este procedimento reinicia o índice UDS associado e informa ao volume VDO que a deduplicação está ativa novamente.

Nota

A desduplicação é ativada por padrão.

Procedimento

  • Para reiniciar a desduplicação em um volume VDO, use o seguinte comando:

    # vdo enableDeduplicação --name=my-vdo

2.7.3. Desabilitando a deduplicação em um volume VDO

Este procedimento interrompe o índice UDS associado e informa ao volume VDO que a deduplicação não está mais ativa.

Procedimento

  • Para parar a desduplicação em um volume VDO, use o seguinte comando:

    # vdo desativarDeduplicação --name=my-vdo
  • Você também pode desativar a deduplicação ao criar um novo volume VDO, adicionando a opção --deduplication=disabled ao comando vdo create.

2.8. Habilitando ou desabilitando a compressão em VDO

A VDO fornece compressão de dados. Você pode desativá-la para maximizar o desempenho ou acelerar o processamento de dados que dificilmente serão compactados, ou reativá-la para aumentar a economia de espaço.

2.8.1. Compressão em VDO

Além da desduplicação em nível de bloco, a VDO também fornece compressão em nível de bloco em linha usando a tecnologia HIOPS Compression™.

A compressão de volume VDO está ligada por padrão.

Enquanto a deduplicação é a solução ideal para ambientes de máquinas virtuais e aplicações de backup, a compressão funciona muito bem com formatos de arquivos estruturados e não estruturados que normalmente não apresentam redundância em nível de bloco, tais como arquivos de log e bancos de dados.

A compressão opera em blocos que não foram identificados como duplicados. Quando a VDO vê dados únicos pela primeira vez, ela comprime os dados. Cópias subseqüentes dos dados que já foram armazenados são deduplicadas sem exigir uma etapa adicional de compressão.

O recurso de compressão é baseado em um algoritmo de embalagem paralela que lhe permite lidar com muitas operações de compressão ao mesmo tempo. Após armazenar primeiro o bloco e responder ao solicitante, um algoritmo de embalagem mais adequado encontra vários blocos que, quando comprimidos, podem caber em um único bloco físico. Depois de determinado que é improvável que um determinado bloco físico contenha blocos comprimidos adicionais, ele é escrito para o armazenamento e os blocos não comprimidos são liberados e reutilizados.

Ao realizar as operações de compressão e embalagem após já ter respondido ao solicitante, o uso da compressão impõe uma penalidade de latência mínima.

2.8.2. Possibilitando a compressão em um volume VDO

Este procedimento permite a compressão sobre um volume VDO para aumentar a economia de espaço.

Nota

A compressão é ativada por padrão.

Procedimento

  • Para reiniciá-lo, use o seguinte comando:

    # vdo enableCompression --name=my-vdo

2.8.3. Desabilitando a compressão em um volume VDO

Este procedimento interrompe a compressão em um volume VDO para maximizar o desempenho ou acelerar o processamento de dados que dificilmente serão comprimidos.

Procedimento

  • Para parar a compressão em um volume VDO existente, use o seguinte comando:

    # vdo disableCompression --name=my-vdo
  • Alternativamente, você pode desativar a compressão adicionando a opção --compression=disabled ao comando vdo create ao criar um novo volume.

2.9. Aumentando o tamanho de um volume VDO

Você pode aumentar o tamanho físico de um volume VDO para utilizar mais capacidade de armazenamento subjacente, ou o tamanho lógico para fornecer mais capacidade sobre o volume.

2.9.1. O tamanho físico e lógico de um volume VDO

Esta seção descreve o tamanho físico, o tamanho físico disponível e o tamanho lógico que a VDO pode utilizar:

Tamanho físico

Este é o mesmo tamanho que o dispositivo de bloco subjacente. A VDO usa este armazenamento para:

  • Dados do usuário, que podem ser deduzidos e comprimidos
  • Metadados VDO, tais como o índice UDS
Tamanho físico disponível

Esta é a porção do tamanho físico que a VDO é capaz de usar para os dados do usuário

É equivalente ao tamanho físico menos o tamanho dos metadados, menos o restante após a divisão do volume em placas pelo tamanho da laje dada.

Tamanho lógico

Este é o tamanho provisionado que o volume VDO apresenta para as aplicações. Geralmente é maior do que o tamanho físico disponível. Se a opção --vdoLogicalSize não for especificada, então o provisionamento do volume lógico é agora provisionado para uma proporção de 1:1. Por exemplo, se um volume VDO for colocado em cima de um dispositivo de bloco de 20 GB, então 2,5 GB é reservado para o índice UDS (se o tamanho padrão do índice for usado). Os 17,5 GB restantes são fornecidos para os metadados e dados do usuário do VDO. Como resultado, o armazenamento disponível para consumo não é superior a 17,5 GB, e pode ser menor devido aos metadados que compõem o volume real do VDO.

A VDO suporta atualmente qualquer tamanho lógico até 254 vezes o tamanho do volume físico com um tamanho lógico máximo absoluto de 4PB.

Figura 2.3. Organização do disco VDO

VDO disk organization

Nesta figura, o alvo de armazenamento dedicado do VDO fica completamente em cima do dispositivo de bloco, o que significa que o tamanho físico do volume do VDO é o mesmo tamanho do dispositivo de bloco subjacente.

Recursos adicionais

2.9.2. Provisão fina em VDO

O VDO é um alvo de armazenamento em bloco com pouca provisão. A quantidade de espaço físico que um volume VDO utiliza pode ser diferente do tamanho do volume que é apresentado aos usuários do armazenamento. Você pode fazer uso desta disparidade para economizar nos custos de armazenamento.

Condições fora do espaço

Tome cuidado para evitar que o espaço de armazenamento fique inesperadamente esgotado, se os dados escritos não atingirem a taxa de otimização esperada.

Sempre que o número de blocos lógicos (armazenamento virtual) excede o número de blocos físicos (armazenamento real), torna-se possível que os sistemas de arquivos e aplicações fiquem sem espaço inesperado. Por esse motivo, os sistemas de armazenamento que utilizam VDO devem fornecer uma forma de monitorar o tamanho do pool livre no volume do VDO.

Você pode determinar o tamanho deste pool gratuito usando o utilitário vdostats. A saída padrão deste utilitário lista informações para todos os volumes VDO em execução em um formato similar ao utilitário Linux df. Por exemplo, o utilitário VDO:

Device                1K-blocks   Used        Available   Use%
/dev/mapper/vdo-name  211812352   105906176   105906176   50%

Quando a capacidade de armazenamento físico de um volume VDO está quase cheia, a VDO relata um aviso no registro do sistema, semelhante ao seguinte:

Oct  2 17:13:39 system lvm[13863]: Monitoring VDO pool vdo-name.
Oct  2 17:27:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 80.69% full.
Oct  2 17:28:19 system lvm[13863]: WARNING: VDO pool vdo-name is now 85.25% full.
Oct  2 17:29:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 90.64% full.
Oct  2 17:30:29 system lvm[13863]: WARNING: VDO pool vdo-name is now 96.07% full.
Nota

Estas mensagens de aviso aparecem somente quando o serviço lvm2-monitor está em funcionamento. Ele é ativado por padrão.

Como evitar condições fora do espaço

Se o tamanho da piscina livre cair abaixo de um certo nível, você pode tomar providências:

  • Eliminação de dados. Isto recupera espaço sempre que os dados excluídos não forem duplicados. A eliminação de dados libera o espaço somente depois que os descartes são emitidos.
  • Acréscimo de armazenamento físico
Importante

Monitore o espaço físico em seus volumes VDO para evitar situações fora do espaço. Ficar sem blocos físicos pode resultar na perda de dados escritos recentemente, não reconhecidos, sobre o volume do VDO.

Provisão fina e os comandos TRIM e DISCARD

Para se beneficiar da economia de armazenamento do provisionamento fino, a camada de armazenamento físico precisa saber quando os dados são apagados. Sistemas de arquivos que trabalham com armazenamento thinly provisioned enviam os comandos TRIM ou DISCARD para informar o sistema de armazenamento quando um bloco lógico não for mais necessário.

Vários métodos de envio dos comandos TRIM ou DISCARD estão disponíveis:

  • Com a opção de montagem discard, os sistemas de arquivo podem enviar estes comandos sempre que um bloco for excluído.
  • Você pode enviar os comandos de forma controlada, utilizando utilitários como fstrim. Estes utilitários dizem ao sistema de arquivos para detectar quais blocos lógicos não são utilizados e enviar as informações ao sistema de armazenamento na forma de um comando TRIM ou DISCARD.

A necessidade de utilizar TRIM ou DISCARD em blocos não utilizados não é exclusiva da VDO. Qualquer sistema de armazenamento com pouca provisão tem o mesmo desafio.

2.9.3. Aumentando o tamanho lógico de um volume VDO

Este procedimento aumenta o tamanho lógico de um determinado volume de VDO. Ele permite criar inicialmente volumes VDO que têm um tamanho lógico suficientemente pequeno para não ficar sem espaço. Após algum tempo, você pode avaliar a taxa real de redução de dados, e se suficiente, você pode aumentar o tamanho lógico do volume VDO para aproveitar a economia de espaço.

Não é possível diminuir o tamanho lógico de um volume VDO.

Procedimento

  • Para aumentar o tamanho lógico, use:

    # vdo growLogical --name=my-vdo \
                      --vdoLogicalSize=new-logical-size

    Quando o tamanho lógico aumenta, a VDO informa quaisquer dispositivos ou sistemas de arquivo sobre o volume do novo tamanho.

2.9.4. Aumentar o tamanho físico de um volume VDO

Este procedimento aumenta a quantidade de armazenamento físico disponível para um volume VDO.

Não é possível encolher um volume VDO desta forma.

Pré-requisitos

  • O dispositivo de bloco subjacente tem uma capacidade maior do que o tamanho físico atual do volume do VDO.

    Se não o fizer, você pode tentar aumentar o tamanho do dispositivo. O procedimento exato depende do tipo do dispositivo. Por exemplo, para redimensionar uma partição MBR ou GPT, consulte a seção Redimensionamento de uma partição no guia Managing storage devices.

Procedimento

  • Adicione o novo espaço de armazenamento físico ao volume do VDO:

    # vdo growFísico --nome=my-vdo

2.10. Remoção de volumes VDO

Você pode remover um volume VDO existente em seu sistema.

2.10.1. Remoção de um volume VDO em funcionamento

Este procedimento remove um volume VDO e seu índice UDS associado.

Procedimento

  1. Desmontar os sistemas de arquivo e parar as aplicações que estão usando o armazenamento no volume do VDO.
  2. Para remover o volume do VDO de seu sistema, use:

    # vdo remove --name=my-vdo

2.10.2. Removendo um volume VDO criado sem sucesso

Este procedimento limpa um volume VDO em um estado intermediário. Um volume é deixado em um estado intermediário se ocorrer uma falha ao criar o volume. Isto pode acontecer quando, por exemplo:

  • O sistema trava
  • Falha de energia
  • O administrador interrompe um comando vdo create em execução

Procedimento

  • Para limpar, remover o volume criado sem sucesso com a opção --force:

    # vdo remove --force --name=my-vdo

    A opção --force é necessária porque o administrador pode ter causado um conflito ao alterar a configuração do sistema desde que o volume foi criado sem sucesso.

    Sem a opção --force, o comando vdo remove falha com a seguinte mensagem:

    [...]
    A previous operation failed.
    Recovery from the failure either failed or was interrupted.
    Add '--force' to 'remove' to perform the following cleanup.
    Steps to clean up VDO my-vdo:
    umount -f /dev/mapper/my-vdo
    udevadm settle
    dmsetup remove my-vdo
    vdo: ERROR - VDO volume my-vdo previous operation (create) is incomplete

Capítulo 3. Teste de economia de espaço VDO

Você pode realizar uma série de testes para determinar quanto espaço de armazenamento você pode economizar usando o VDO.

Pré-requisitos

  • Estão disponíveis um ou mais dispositivos de bloqueio físico.
  • O dispositivo de bloco alvo é maior que 512 GiB.
  • O VDO está instalado.

3.1. O propósito e os resultados dos testes VDO

Os testes VDO fornecidos pela Red Hat ajudam a produzir uma avaliação da integração do VDO nos dispositivos de armazenamento existentes. Eles se destinam a aumentar, e não substituir, seus esforços de avaliação interna.

Os resultados dos testes ajudam os engenheiros da Red Hat a ajudá-lo a entender o comportamento da VDO em ambientes específicos de armazenamento. Os fabricantes de equipamentos originais (OEMs) podem aprender como projetar seus dispositivos capazes de deduplicação e compressão, e como seus clientes podem ajustar suas aplicações para esses dispositivos.

Objetivos

  • Identificar os ajustes de configuração que obtenham respostas ótimas do dispositivo de teste.
  • Explicar os parâmetros básicos de ajuste para ajudar a evitar erros de configuração do produto.
  • Criar uma referência de resultados de desempenho para comparar com casos reais de uso.
  • Identificar como as diferentes cargas de trabalho afetam o desempenho e a eficiência dos dados.
  • Encurtar o tempo de comercialização com as implementações VDO.

O plano de teste e as condições de teste

Os testes VDO oferecem condições sob as quais o VDO pode ser avaliado de forma mais realista. A alteração dos procedimentos ou parâmetros dos testes pode invalidar os resultados. Os engenheiros de vendas da Red Hat podem orientá-lo ao modificar os planos de teste.

Para um plano de teste eficaz, você deve estudar a arquitetura VDO e explorar estes itens:

  • O desempenho em ambientes de alta carga
  • As propriedades configuráveis da VDO para aplicações de ajuste de desempenho do usuário final
  • O impacto do VDO ser um dispositivo de bloco nativo 4 KiB
  • A resposta aos padrões de acesso e distribuições de deduplicação e compressão
  • O valor do custo versus capacidade versus desempenho para uma determinada aplicação

3.2. Provisão fina em VDO

O VDO é um alvo de armazenamento em bloco com pouca provisão. A quantidade de espaço físico que um volume VDO utiliza pode ser diferente do tamanho do volume que é apresentado aos usuários do armazenamento. Você pode fazer uso desta disparidade para economizar nos custos de armazenamento.

Condições fora do espaço

Tome cuidado para evitar que o espaço de armazenamento fique inesperadamente esgotado, se os dados escritos não atingirem a taxa de otimização esperada.

Sempre que o número de blocos lógicos (armazenamento virtual) excede o número de blocos físicos (armazenamento real), torna-se possível que os sistemas de arquivos e aplicações fiquem sem espaço inesperado. Por esse motivo, os sistemas de armazenamento que utilizam VDO devem fornecer uma forma de monitorar o tamanho do pool livre no volume do VDO.

Você pode determinar o tamanho deste pool gratuito usando o utilitário vdostats. A saída padrão deste utilitário lista informações para todos os volumes VDO em execução em um formato similar ao utilitário Linux df. Por exemplo, o utilitário VDO:

Device                1K-blocks   Used        Available   Use%
/dev/mapper/vdo-name  211812352   105906176   105906176   50%

Quando a capacidade de armazenamento físico de um volume VDO está quase cheia, a VDO relata um aviso no registro do sistema, semelhante ao seguinte:

Oct  2 17:13:39 system lvm[13863]: Monitoring VDO pool vdo-name.
Oct  2 17:27:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 80.69% full.
Oct  2 17:28:19 system lvm[13863]: WARNING: VDO pool vdo-name is now 85.25% full.
Oct  2 17:29:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 90.64% full.
Oct  2 17:30:29 system lvm[13863]: WARNING: VDO pool vdo-name is now 96.07% full.
Nota

Estas mensagens de aviso aparecem somente quando o serviço lvm2-monitor está em funcionamento. Ele é ativado por padrão.

Como evitar condições fora do espaço

Se o tamanho da piscina livre cair abaixo de um certo nível, você pode tomar providências:

  • Eliminação de dados. Isto recupera espaço sempre que os dados excluídos não forem duplicados. A eliminação de dados libera o espaço somente depois que os descartes são emitidos.
  • Acréscimo de armazenamento físico
Importante

Monitore o espaço físico em seus volumes VDO para evitar situações fora do espaço. Ficar sem blocos físicos pode resultar na perda de dados escritos recentemente, não reconhecidos, sobre o volume do VDO.

Provisão fina e os comandos TRIM e DISCARD

Para se beneficiar da economia de armazenamento do provisionamento fino, a camada de armazenamento físico precisa saber quando os dados são apagados. Sistemas de arquivos que trabalham com armazenamento thinly provisioned enviam os comandos TRIM ou DISCARD para informar o sistema de armazenamento quando um bloco lógico não for mais necessário.

Vários métodos de envio dos comandos TRIM ou DISCARD estão disponíveis:

  • Com a opção de montagem discard, os sistemas de arquivo podem enviar estes comandos sempre que um bloco for excluído.
  • Você pode enviar os comandos de forma controlada, utilizando utilitários como fstrim. Estes utilitários dizem ao sistema de arquivos para detectar quais blocos lógicos não são utilizados e enviar as informações ao sistema de armazenamento na forma de um comando TRIM ou DISCARD.

A necessidade de utilizar TRIM ou DISCARD em blocos não utilizados não é exclusiva da VDO. Qualquer sistema de armazenamento com pouca provisão tem o mesmo desafio.

3.3. Informações a registrar antes de cada teste VDO

Você deve registrar as seguintes informações no início de cada teste para garantir que o ambiente de teste seja totalmente compreendido. Você pode capturar grande parte das informações necessárias usando o utilitário sosreport.

Informações requeridas

  • A construção usada do Linux, incluindo o número de construção do kernel
  • A lista completa dos pacotes instalados, como obtida do comando rpm -qa
  • Especificações completas do sistema

    • Tipo e quantidade de CPU; disponível no arquivo /proc/cpuinfo
    • Memória instalada e a quantidade disponível após o sistema operacional rase estar em funcionamento; disponível no arquivo /proc/meminfo
    • Tipos de controladores de acionamento usados
    • Tipos e quantidade de discos usados
  • Uma lista completa dos processos em execução; disponível a partir do comando ps aux ou de uma lista semelhante
  • Nome do volume físico e do grupo de volume criado para uso com VDO; disponível a partir dos comandos pvs e vgs
  • Sistema de arquivo usado ao formatar o volume VDO, se houver
  • Permissões no diretório montado
  • Conteúdo do arquivo /etc/vdoconf.yaml
  • Localização dos arquivos VDO

3.4. Criando um volume de teste VDO

Este procedimento cria um volume VDO com um tamanho lógico de 1 TiB em um volume físico de 512 GiB para fins de teste.

Procedimento

  1. Criar um volume VDO:

    # vdo create --name=vdo-test \
                 --device=/dev/sdb \
                 --vdoLogicalSize=1T \
                 --writePolicy=policy \
                 --verbose
    • Substitua /dev/sdb com o caminho para um dispositivo de bloqueio.
    • Para testar o modo VDO async no topo do armazenamento assíncrono, crie um volume assíncrono usando a opção --writePolicy=async.
    • Para testar o modo VDO sync no topo do armazenamento síncrono, criar um volume síncrono usando a opção --writePolicy=sync.
  2. Formate o novo volume com um sistema de arquivo XFS ou ext4.

    • Para XFS:

      # mkfs.xfs -K /dev/mapper/vdo-test
    • Para ext4:

      # mkfs.ext4 -E nodiscard /dev/mapper/vdo-test
  3. Monte o volume formatado:

    # mkdir /mnt/vdo-test
    
    # mount /dev/mapper/vdo-test /mnt/vdo-test && \
      chmod a+rwx /mnt/vdo-test

3.5. Teste do volume de teste do VDO

Este procedimento testa se a leitura e a escrita do volume de teste VDO funciona.

Pré-requisitos

Procedimento

  1. Escreva 32 GiB de dados aleatórios para o volume VDO:

    $ dd if=/dev/urandom of=/mnt/vdo-test/test file bs=4096 count=8388608
  2. Leia os dados do volume do VDO e escreva-os em outro volume:

    $ dd if=/mnt/vdo-test/ test file of=another-location/testfile bs=4096
    • Substitua another-location com qualquer diretório onde você tenha acesso de escrita que não esteja no volume de teste do VDO. Por exemplo, você pode usar seu diretório pessoal.
  3. Compare os dois arquivos:

    $ diff --report-ficheiros idênticos /mnt/vdo-teste/arquivo de teste another-location/ arquivo de teste

    O comando deve informar que os arquivos são os mesmos.

  4. Copie o arquivo de volta para um novo local no volume do VDO:

    $ dd if=another-location/testfile of=/mnt/vdo-test/testfile2 bs=4096
  5. Compare o terceiro arquivo com o segundo arquivo:

    $ diff --report-ficheiros idênticos /mnt/vdo-teste/arquivo de teste2 another-location/ arquivo de teste

    O comando deve informar que os arquivos são os mesmos.

Etapas de limpeza

3.6. Limpeza do volume de teste VDO

Este procedimento remove do sistema o volume do VDO usado para testar a eficiência do VDO.

Pré-requisitos

  • Um volume de teste VDO é montado.

Procedimento

  1. Desmontar o sistema de arquivo criado no volume do VDO:

    # umount /mnt/vdo-test
  2. Remover o volume de teste VDO do sistema:

    # vdo remover --nome=vdo-teste

Etapas de verificação

  • Verificar se o volume foi removido:

    # lista vdo --tudo | grep vdo-test

    O comando não deve listar a partição de teste VDO.

3.7. Medindo a deduplicação do VDO

Este procedimento testa a eficiência da deduplicação dos dados VDO em um volume de teste VDO.

Pré-requisitos

Procedimento

  1. Prepare uma tabela onde você possa registrar os resultados do teste:

    EstatísticasSistema de arquivo nuaDepois da sementeApós 10 cópias

    Tamanho do sistema de arquivo utilizado

       

    Dados VDO utilizados

       

    Lógica VDO utilizada

       
  2. Criar 10 diretórios no volume do VDO para conter 10 cópias do conjunto de dados de teste:

    $ mkdir /mnt/vdo-test/vdo{01..10}
  3. Examinar o uso do disco informado pelo sistema de arquivo:

    $ df - legível por humanos /mnt/vdo-teste

    Exemplo 3.1. Uso do disco

    Filesystem            Size  Used Avail Use% Mounted on
    /dev/mapper/vdo-test  1.5T  198M  1.4T   1% /mnt/vdo-test
  4. Registre os seguintes valores:

    # vdostats --verbose "blocos usados

    Exemplo 3.2. Blocos usados

    data blocks used                : 1090
    overhead blocks used            : 538846
    logical blocks used             : 6059434
    • O valor data blocks used é o número de blocos usados pelos dados do usuário após a otimização do dispositivo físico rodando sob VDO.
    • O valor logical blocks used é o número de blocos utilizados antes da otimização. Ele será utilizado como ponto de partida para as medições.
  5. Criar um arquivo de fonte de dados sobre o volume VDO:

    $ dd if=/dev/urandom of=/mnt/vdo-test/sourcefile bs=4096 count=1048576
    
    4294967296 bytes (4.3 GB) copied, 540.538 s, 7.9 MB/s
  6. Reexamine a quantidade de espaço físico em disco utilizado:

    $ df - legível por humanos /mnt/vdo-teste

    Exemplo 3.3. Uso do disco com o arquivo fonte de dados

    Filesystem            Size  Used Avail Use% Mounted on
    /dev/mapper/vdo-test  1.5T  4.2G  1.4T   1% /mnt/vdo-test
    # vdostats --verbose "blocos usados

    Exemplo 3.4. Blocos usados com o arquivo de fonte de dados

    data blocks used                : 1050093  # Increased by 4GiB
    overhead blocks used            : 538846   # Did not significantly change
    logical blocks used             : 7108036  # Increased by 4GiB

    Este comando deve mostrar um aumento no número de blocos utilizados, correspondente ao tamanho do arquivo escrito.

  7. Copie o arquivo para cada um dos 10 subdiretórios:

    $ for i in {01..10}; do
      cp /mnt/vdo-test/sourcefile /mnt/vdo-test/vdo$i
      done
  8. Reexamine a quantidade de espaço físico em disco utilizado:

    $ df -h /mnt/vdo-teste

    Exemplo 3.5. Uso do disco após a cópia do arquivo

    Filesystem            Size  Used Avail Use% Mounted on
    /dev/mapper/vdo-test  1.5T   45G  1.3T   4% /mnt/vdo-test
    # vdostats --verbose "blocos usados

    Exemplo 3.6. Blocos usados após a cópia do arquivo

    data blocks used                : 1050836   # Increased by 3 MiB
    overhead blocks used            : 538846
    logical blocks used             : 17594127  # Increased by 41 GiB

    O valor data blocks used deve ser semelhante ao resultado da listagem anterior, com apenas um ligeiro aumento devido ao sistema de arquivo de periódicos e metadados.

  9. Subtrair este novo valor do espaço utilizado pelo sistema de arquivo do valor encontrado antes de escrever os dados de teste. Esta é a quantidade de espaço consumida por este teste a partir da perspectiva do sistema de arquivo.
  10. Observe a economia de espaço em suas estatísticas registradas:

    Exemplo 3.7. Valores registrados

    EstatísticasSistema de arquivo nuaDepois da sementeApós 10 cópias

    Tamanho do sistema de arquivo utilizado

    198 MiB

    4.2 GiB

    45 GiB

    Dados VDO utilizados

    4 MiB

    4.1 GiB

    4.1 GiB

    Lógica VDO utilizada

    23.6 GiB (file system overhead for 1.6 TiB formatted drive)

    27.8 GiB

    68.7 GiB

    Nota

    Na tabela, os valores foram convertidos para MiB ou GiB. Os blocos na saída do vdostats são 4.096 B em tamanho.

Etapas de limpeza

3.8. Medindo a compressão VDO

Este procedimento testa a eficiência da compressão de dados VDO em um volume de teste VDO.

Pré-requisitos

Procedimento

  1. Desativar a desduplicação e permitir a compressão no volume de teste VDO:

    # vdo disableDeduplication --name=vdo-test
    # vdo enableCompression --name=vdo-test
  2. Sincronizar o volume do VDO para completar qualquer compressão inacabada:

    # sync && dmsetup mensagem vdo-test 0 sync-dedupe
  3. Inspecione as estatísticas da VDO antes da transferência:

    # vdostats --verbose "blocos usados

    Tome nota dos valores data blocks used e logical blocks used.

  4. A VDO otimiza a sobrecarga do sistema de arquivos, bem como os dados reais do usuário. Calcule o número de 4 blocos KiB salvos por compressão para o sistema de arquivo vazio como logical blocks used menos data blocks used.
  5. Copie o conteúdo do diretório /lib para o volume VDO:

    # cp --verbose --recursive /lib /mnt/vdo-test
    
    ...
    sent 152508960 bytes  received 60448 bytes  61027763.20 bytes/sec
    total size is 152293104  speedup is 1.00

    Registrar o tamanho total dos dados copiados.

  6. Sincronizar as caches Linux e o volume VDO:

    # sync && dmsetup mensagem vdo-test 0 sync-dedupe
  7. Inspecione novamente as estatísticas da VDO:

    # vdostats --verbose "blocos usados

    Observar os valores logical blocks used e data blocks used.

  8. Calcule a quantidade de bytes salvos por compressão usando a seguinte fórmula:

    saved_bytes = (logical_blocks_used - data_blocks_used) * 4096

Etapas de limpeza

3.9. Medindo a economia total de espaço VDO

Este procedimento testa a eficiência combinada da deduplicação e compressão de dados VDO em um volume de teste VDO.

Procedimento

  1. Criar e montar um volume VDO como descrito em Seção 3.4, “Criando um volume de teste VDO”.
  2. Realizar os testes descritos em Medindo a deduplicação do VDO e Medindo a compressão do VDO no mesmo volume sem removê-lo. Observar as mudanças na economia de espaço na saída do vdostats.
  3. Experimente com seus próprios conjuntos de dados.

3.10. Testando o efeito do TRIM e DISCARD no VDO

Este procedimento testa se os comandos TRIM e DISCARD liberam corretamente os blocos de arquivos excluídos em um volume de teste VDO. Ele demonstra que os descartes informam à VDO que o espaço não é mais utilizado.

Pré-requisitos

Procedimento

  1. Prepare uma tabela onde você possa registrar os resultados do teste:

    EtapaEspaço de arquivo utilizado (MB)Blocos de dados utilizadosBlocos lógicos utilizados

    Inicial

       

    Adicionar 1 arquivo GiB

       

    Rodar fstrim

       

    Excluir 1 arquivo GiB

       

    Rodar fstrim

       
  2. Aparar o sistema de arquivo para remover blocos desnecessários:

    # fstrim /mnt/vdo-test

    O comando pode levar muito tempo.

  3. Registrar o uso inicial de espaço no sistema de arquivo:

    $ df -m /mnt/vdo-teste
  4. Veja quantos dados físicos e lógicos bloqueia o volume VDO usa:

    # vdostats --verbose "blocos usados
  5. Criar um arquivo 1 GiB com dados não duplicados sobre o volume do VDO:

    $ dd if=/dev/urandom of=/mnt/vdo-test/file bs=1M count=1K
  6. Registrar novamente o uso do espaço:

    $ df -m /mnt/vdo-test
    
    # vdostats --verbose | grep "blocks used"

    O sistema de arquivo deve usar um sistema adicional de 1 GiB. Os valores de data blocks used e logical blocks used devem aumentar de forma semelhante.

  7. Aparar novamente o sistema de arquivo:

    # fstrim /mnt/vdo-test
  8. Inspecione novamente o uso do espaço para confirmar que o revestimento não teve impacto sobre o uso do volume físico:

    $ df -m /mnt/vdo-test
    
    # vdostats --verbose | grep "blocks used"
  9. Apagar o arquivo 1 GiB:

    $ rm /mnt/vdo-test/file
  10. Verificar e registrar novamente o uso do espaço:

    $ df -m /mnt/vdo-test
    
    # vdostats --verbose | grep "blocks used"

    O sistema de arquivo está ciente de que um arquivo foi excluído, mas não há alteração no número de blocos físicos ou lógicos porque a exclusão do arquivo não foi comunicada ao armazenamento subjacente.

  11. Aparar novamente o sistema de arquivo:

    # fstrim /mnt/vdo-test
  12. Verificar e registrar novamente o uso do espaço:

    $ df -m /mnt/vdo-test
    
    # vdostats --verbose | grep "blocks used"

    O utilitário fstrim procura blocos gratuitos no sistema de arquivos e envia um comando TRIM para o volume VDO para endereços não utilizados, o que libera os blocos lógicos associados. A VDO processa o comando TRIM para liberar os blocos físicos subjacentes.

Recursos adicionais

Capítulo 4. Testando o desempenho do VDO

Você pode realizar uma série de testes para medir o desempenho do VDO, obter um perfil de desempenho de seu sistema com o VDO e determinar quais aplicações têm bom desempenho com o VDO.

Pré-requisitos

  • Um ou mais dispositivos de bloco físico Linux estão disponíveis.
  • O dispositivo de bloco alvo (por exemplo, /dev/sdb) é maior do que 512 GiB.
  • O Testador de E/S flexível (fio) está instalado.
  • O VDO está instalado.

4.1. Preparando um ambiente para testes de desempenho VDO

Antes de testar o desempenho do VDO, você deve considerar a configuração do sistema host, a configuração do VDO e as cargas de trabalho que serão utilizadas durante os testes. Estas escolhas afetam o benchmarking de eficiência de espaço, largura de banda e latência.

Para evitar que um teste afete os resultados de outro, você deve criar um novo volume VDO para cada iteração de cada teste.

4.1.1. Considerações antes de testar o desempenho do VDO

As seguintes condições e configurações afetam os resultados dos testes VDO:

Configuração do sistema

  • Número e tipo de núcleos de CPU disponíveis. Você pode listar estas informações usando o utilitário taskset.
  • Memória disponível e memória total instalada
  • Configuração de dispositivos de armazenamento
  • Agendador ativo de disco
  • Versão do kernel do Linux
  • Pacotes instalados

Configuração VDO

  • Esquema de partição
  • Sistemas de arquivo utilizados nos volumes VDO
  • Tamanho do armazenamento físico atribuído a um volume VDO
  • Tamanho do volume VDO lógico criado
  • Indexação UDS esparsa ou densa
  • Índice UDS em tamanho de memória
  • Configuração de rosca VDO

Cargas de trabalho

  • Tipos de ferramentas usadas para gerar dados de teste
  • Número de clientes simultâneos
  • A quantidade de 4 blocos KiB duplicados nos dados escritos
  • Padrões de leitura e escrita
  • O tamanho do conjunto de trabalho

4.1.2. Considerações especiais para testar o desempenho de leitura VDO

Você deve considerar estes fatores adicionais antes de testar o desempenho de leitura VDO:

  • Se um bloco de 4 KiB nunca foi escrito, a VDO não lê do armazenamento e responde imediatamente com um bloco zero.
  • Se um bloco de 4 KiB foi escrito mas contém todos os zeros, a VDO não lê a partir do armazenamento e responde imediatamente com um bloco zero.

Este comportamento resulta em um desempenho de leitura muito rápido quando não há dados para ler. É por isso que os testes de leitura devem preencher previamente o volume com dados reais.

4.1.3. Preparando o sistema para testar o desempenho do VDO

Este procedimento configura as configurações do sistema para alcançar o desempenho ideal do VDO durante os testes.

Importante

Testes além dos limites listados em qualquer teste em particular podem resultar na perda do tempo de teste devido a resultados anormais.

Por exemplo, os testes VDO descrevem um teste que realiza leituras aleatórias em uma faixa de 100 endereços GiB. Para testar um conjunto funcional de 500 GiB, é necessário aumentar a quantidade de RAM alocada para o cache do mapa de blocos da VDO de acordo.

Procedimento

  1. Certifique-se de que sua CPU esteja funcionando com o melhor desempenho possível.
  2. Se possível, desabilitar a escala de freqüência da CPU usando a configuração da BIOS ou o utilitário Linux cpupower.
  3. Se possível, ativar o ajuste dinâmico da freqüência do processador (Turbo Boost ou Turbo Core) para a CPU. Esta característica introduz alguma variabilidade nos resultados dos testes, mas melhora o desempenho geral.
  4. Os sistemas de arquivo podem ter impactos únicos no desempenho. Muitas vezes distorcem as medidas de desempenho, tornando mais difícil isolar o impacto da VDO sobre os resultados.

    Se razoável, meça o desempenho no dispositivo de bloco em bruto. Se isto não for possível, formate o dispositivo usando o sistema de arquivo que a VDO usará na implementação do alvo.

4.2. Criação de um volume VDO para testes de desempenho

Este procedimento cria um volume VDO com um tamanho lógico de 1 TiB em um volume físico de 512 GiB para testar o desempenho do VDO.

Procedimento

  • Criar um volume VDO:

    # vdo create --name=vdo-test \
                 --device=/dev/sdb \
                 --vdoLogicalSize=1T \
                 --writePolicy=policy \
                 --verbose
    • Substitua /dev/sdb com o caminho para um dispositivo de bloqueio.
    • Para testar o modo VDO async no topo do armazenamento assíncrono, crie um volume assíncrono usando a opção --writePolicy=async.
    • Para testar o modo VDO sync no topo do armazenamento síncrono, criar um volume síncrono usando a opção --writePolicy=sync.

4.3. Limpeza do volume de testes de desempenho do VDO

Este procedimento remove do sistema o volume do VDO usado para testar o desempenho do VDO.

Pré-requisitos

  • Existe um volume de teste VDO no sistema.

Procedimento

  • Remover o volume de teste VDO do sistema:

    # vdo remover --nome=vdo-teste

Etapas de verificação

  • Verificar se o volume foi removido:

    # lista vdo --tudo | grep vdo-test

    O comando não deve listar a partição de teste VDO.

4.4. Teste dos efeitos da profundidade de E/S no desempenho do VDO

Estes testes determinam a profundidade de E/S que produz a melhor produtividade e a menor latência para sua configuração VDO. A profundidade de E/S representa o número de solicitações de E/S que a ferramenta fio apresenta de cada vez.

Como a VDO usa um setor de 4 KiB tamanho, os testes realizam testes em 4 KiB I/O operações, e profundidade I/O de 1, 8, 16, 32, 64, 128, 256, 512, e 1024.

4.4.1. Teste do efeito da profundidade de E/S em 100% das leituras seqüenciais em VDO

Este teste determina como as operações seqüenciais 100% lidas se realizam em um volume VDO em diferentes valores de profundidade de E/S.

Procedimento

  1. Criar um novo volume VDO.

    Para maiores detalhes, ver Seção 4.2, “Criação de um volume VDO para testes de desempenho”.

  2. Preencha quaisquer áreas que o teste possa acessar realizando um trabalho de escrita fio sobre o volume do teste:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre o rendimento e a latência relatados para leituras seqüenciais de 100%:

    # for depth in 1 2 4 8 16 32 64 128 256 512 1024 2048; do
      fio --rw=read \
          --bs=4096 \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=$depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retirar o volume de teste VDO.

    Para maiores detalhes, ver Seção 4.3, “Limpeza do volume de testes de desempenho do VDO”.

4.4.2. Teste do efeito da profundidade de E/S em seqüenciais 100% escritas em VDO

Este teste determina como as operações de escrita seqüencial 100% se realizam em um volume VDO em diferentes valores de profundidade de E/S.

Procedimento

  1. Criar um novo volume de teste VDO.

    Para maiores detalhes, ver Seção 4.2, “Criação de um volume VDO para testes de desempenho”.

  2. Preencha quaisquer áreas que o teste possa acessar realizando um trabalho de escrita fio:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registrar o rendimento e a latência relatados para escritas seqüenciais 100%:

    # for depth in 1 2 4 8 16 32 64 128 256 512 1024 2048; do
      fio --rw=write \
          --bs=4096 \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=$depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retirar o volume de teste VDO.

    Para maiores detalhes, ver Seção 4.3, “Limpeza do volume de testes de desempenho do VDO”.

4.4.3. Teste do efeito da profundidade de E/S em leituras aleatórias de 100% em VDO

Este teste determina o desempenho de operações 100% lidas aleatoriamente em um volume VDO com diferentes valores de profundidade de E/S.

Procedimento

  1. Criar um novo volume de teste VDO.

    Para maiores detalhes, ver Seção 4.2, “Criação de um volume VDO para testes de desempenho”.

  2. Preencha quaisquer áreas que o teste possa acessar realizando um trabalho de escrita fio:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre o rendimento e a latência relatados para leituras aleatórias de 100%:

    # for depth in 1 2 4 8 16 32 64 128 256 512 1024 2048; do
      fio --rw=randread \
          --bs=4096 \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=$depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retirar o volume de teste VDO.

    Para maiores detalhes, ver Seção 4.3, “Limpeza do volume de testes de desempenho do VDO”.

4.4.4. Teste do efeito da profundidade de E/S em escritas aleatórias 100% em VDO

Este teste determina o desempenho de operações de escrita aleatórias de 100% em um volume VDO em diferentes valores de profundidade de E/S.

Importante

Você deve recriar o volume VDO entre cada teste de profundidade de E/S.

Procedimento

Execute as seguintes séries de passos separadamente para os valores de profundidade de E/S de 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, e 2048:

  1. Criar um novo volume de teste VDO.

    Para maiores detalhes, ver Seção 4.2, “Criação de um volume VDO para testes de desempenho”.

  2. Preencha quaisquer áreas que o teste possa acessar realizando um trabalho de escrita fio:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre o rendimento e a latência relatados para escritas aleatórias de 100%:

    # fio --rw=randwrite \
          --bs=4096 \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=depth-value
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retirar o volume de teste VDO.

    Para maiores detalhes, ver Seção 4.3, “Limpeza do volume de testes de desempenho do VDO”.

4.4.5. Análise do desempenho do VDO em diferentes profundidades de E/S

O exemplo a seguir analisa o rendimento e a latência VDO registrados em diferentes valores de profundidade de E/S.

Observe o comportamento em toda a faixa e os pontos de inflexão onde o aumento da profundidade de E/S proporciona ganhos de rendimento decrescentes. O acesso sequencial e o acesso aleatório provavelmente atingem o pico em valores diferentes, mas os picos podem ser diferentes para todos os tipos de configurações de armazenamento.

Exemplo 4.1. Análise da profundidade de E/S

Figura 4.1. Análise de rendimento de VDO

VDO throughput analysis

Observe o "joelho" em cada curva de desempenho:

  • O marcador 1 identifica o pico sequencial de produção no ponto X. Esta configuração particular não se beneficia da profundidade seqüencial 4 KiB I/O maior que X.
  • O marcador 2 identifica o pico aleatório de produção de 4 KiB no ponto Z. Esta configuração particular não se beneficia de 4 KiB I/O de profundidade aleatória maior que Z.

Além da profundidade de E/S nos pontos X e Z, há ganhos decrescentes de largura de banda, e a latência média de solicitação aumenta 1:1 para cada solicitação adicional de E/S.

A imagem a seguir mostra um exemplo da latência de escrita aleatória após o "joelho" da curva no gráfico anterior. Você deve testar nestes pontos a máxima produção que incorra na penalidade de menor tempo de resposta.

Figura 4.2. Análise da latência da VDO

VDO latency analysis

Profundidade ótima de E/S

O ponto Z marca a profundidade de E/S ideal. O plano de teste coleta dados adicionais com profundidade de E/S igual a Z.

4.5. Teste dos efeitos do tamanho da solicitação de E/S no desempenho do VDO

Usando estes testes, você pode identificar o tamanho do bloco que produz o melhor desempenho do VDO com a profundidade de E/S ideal.

Os testes realizam testes de quatro cantos a uma profundidade de E/S fixa, com blocos de tamanhos variados na faixa de 8 KiB a 1 MiB.

Pré-requisitos

4.5.1. Teste do efeito do tamanho do pedido de E/S em escritas seqüenciais em VDO

Este teste determina como as operações de gravação seqüencial se realizam em um volume VDO em diferentes tamanhos de solicitação de E/S.

Procedimento

  1. Criar um novo volume VDO.

    Para maiores detalhes, ver Seção 4.2, “Criação de um volume VDO para testes de desempenho”.

  2. Preencha quaisquer áreas que o teste possa acessar realizando um trabalho de escrita fio sobre o volume do teste:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registrar o rendimento e a latência relatados para o teste de escrita sequencial:

    # for iosize in 4 8 16 32 64 128 256 512 1024; do
      fio --rw=write \
          --bs=${iosize}k \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=optimal-depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retirar o volume de teste VDO.

    Para maiores detalhes, ver Seção 4.3, “Limpeza do volume de testes de desempenho do VDO”.

4.5.2. Teste do efeito do tamanho do pedido de E/S em escritas aleatórias em VDO

Este teste determina como as operações de escrita aleatória funcionam em um volume VDO em diferentes tamanhos de solicitação de E/S.

Importante

Você deve recriar o volume VDO entre cada execução de teste de tamanho de pedido de E/S.

Procedimento

Execute as seguintes etapas da série separadamente para os tamanhos de solicitação de E/S de 4k, 8k, 16k, 32k, 64k, 128k, 256k, 512k, e 1024k:

  1. Criar um novo volume VDO.

    Para maiores detalhes, ver Seção 4.2, “Criação de um volume VDO para testes de desempenho”.

  2. Preencha quaisquer áreas que o teste possa acessar realizando um trabalho de escrita fio sobre o volume do teste:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre o rendimento e a latência relatados para o teste de escrita aleatória:

    # fio --rw=randwrite \
          --bs=request-size \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=optimal-depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retirar o volume de teste VDO.

    Para maiores detalhes, ver Seção 4.3, “Limpeza do volume de testes de desempenho do VDO”.

4.5.3. Teste do efeito do tamanho do pedido de E/S na leitura seqüencial em VDO

Este teste determina como as operações de leitura seqüencial se realizam em um volume VDO em diferentes tamanhos de solicitação de E/S.

Procedimento

  1. Criar um novo volume VDO.

    Para maiores detalhes, ver Seção 4.2, “Criação de um volume VDO para testes de desempenho”.

  2. Preencha quaisquer áreas que o teste possa acessar realizando um trabalho de escrita fio sobre o volume do teste:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registrar o rendimento e a latência relatados para o teste de leitura seqüencial:

    # for iosize in 4 8 16 32 64 128 256 512 1024; do
      fio --rw=read \
          --bs=${iosize}k \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=optimal-depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retirar o volume de teste VDO.

    Para maiores detalhes, ver Seção 4.3, “Limpeza do volume de testes de desempenho do VDO”.

4.5.4. Teste do efeito do tamanho da solicitação de E/S na leitura aleatória em VDO

Este teste determina o desempenho de operações de leitura aleatória em um volume VDO em diferentes tamanhos de solicitação de E/S.

Procedimento

  1. Criar um novo volume VDO.

    Para maiores detalhes, ver Seção 4.2, “Criação de um volume VDO para testes de desempenho”.

  2. Preencha quaisquer áreas que o teste possa acessar realizando um trabalho de escrita fio sobre o volume do teste:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre o rendimento e a latência relatados para o teste de leitura aleatória:

    # for iosize in 4 8 16 32 64 128 256 512 1024; do
      fio --rw=read \
          --bs=${iosize}k \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=optimal-depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retirar o volume de teste VDO.

    Para maiores detalhes, ver Seção 4.3, “Limpeza do volume de testes de desempenho do VDO”.

4.5.5. Análise do desempenho do VDO em diferentes tamanhos de solicitação de E/S

O exemplo a seguir analisa o rendimento e a latência do VDO registrados em diferentes tamanhos de pedidos de E/S.

Exemplo 4.2. Análise do tamanho da solicitação de E/S

Figura 4.3. Tamanho da solicitação versus análise de rendimento e pontos-chave de inflexão

Request size versus throughput analysis and key inflection points

Analisando os resultados do exemplo:

  • Escritos seqüenciais atingem um pico de produção no tamanho solicitado Y.

    Esta curva demonstra como as aplicações que são configuráveis ou naturalmente dominadas por certos tamanhos de solicitação podem perceber o desempenho. Os tamanhos maiores de solicitação geralmente fornecem mais rendimento porque 4 operações de E/S KiB podem se beneficiar da fusão.

  • As leituras seqüenciais atingem um pico de produção semelhante no ponto Z.

    Após estes picos, a latência geral antes da operação de E/S completa aumenta sem nenhuma produção adicional. Você deve afinar o dispositivo para não aceitar operações de E/S maiores que este tamanho.

  • Leituras aleatórias atingem o pico de produção no ponto X.

    Alguns dispositivos podem atingir taxas de transferência quase seqüenciais em acessos aleatórios de grande tamanho de pedido, mas outros sofrem mais penalidades quando variam de acessos puramente seqüenciais.

  • Os escritos aleatórios atingem o pico de produção no ponto Y.

    As escritas aleatórias envolvem a maior interação de um dispositivo de deduplicação, e a VDO alcança alto desempenho especialmente quando os tamanhos de solicitação ou as profundidades de E/S são grandes.

4.6. Teste dos efeitos das cargas mistas de E/S sobre o desempenho do VDO

Este teste determina como sua configuração VDO se comporta com cargas de E/S de leitura e escrita mistas, e analisa os efeitos de leituras e escritas mistas na profundidade ideal da fila aleatória e tamanhos de solicitação de 4 KB a 1 MB.

Este procedimento realiza testes em quatro cantos com profundidade de E/S fixa, tamanho de bloco variado na faixa de 8 KB a 256 KB, e fixa a porcentagem de leitura em incrementos de 10%, começando com 0%.

Pré-requisitos

Procedimento

  1. Criar um novo volume VDO.

    Para maiores detalhes, ver Seção 4.2, “Criação de um volume VDO para testes de desempenho”.

  2. Preencha quaisquer áreas que o teste possa acessar realizando um trabalho de escrita fio sobre o volume do teste:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre o rendimento e a latência relatados para o estímulo de entrada de leitura e escrita:

    # for readmix in 0 10 20 30 40 50 60 70 80 90 100; do
        for iosize in 4 8 16 32 64 128 256 512 1024; do
          fio --rw=rw \
              --rwmixread=$readmix \
              --bs=${iosize}k \
              --name=vdo \
              --filename=/dev/mapper/vdo-test \
              --ioengine=libaio \
              --numjobs=1 \
              --thread \
              --norandommap \
              --runtime=300 \
              --direct=0 \
              --iodepth=optimal-depth \
              --scramble_buffers=1 \
              --offset=0 \
              --size=100g
        done
      done
  4. Retirar o volume de teste VDO.

    Para maiores detalhes, ver Seção 4.3, “Limpeza do volume de testes de desempenho do VDO”.

  5. Gráfico dos resultados do teste.

    Exemplo 4.3. Análise de cargas de E/S mistas

    A imagem a seguir mostra um exemplo de como a VDO pode responder a cargas mistas de E/S:

    Figura 4.4. O desempenho é consistente em várias misturas de leitura e escrita

    Performance is consistent across varying read and write mixes

    O desempenho agregado e a latência agregada são relativamente consistentes em toda a gama de leituras e escritas misturadas, tendendo da menor produção máxima de gravação para a maior produção máxima de leitura.

    Este comportamento pode variar com diferentes armazenamentos, mas a observação importante é que o desempenho é consistente sob cargas variáveis ou que você pode compreender as expectativas de desempenho para aplicações que demonstram misturas específicas de leitura e escrita.

    Nota

    Se seu sistema não mostrar uma consistência de resposta similar, pode ser um sinal de uma configuração sub-ótima. Contate seu Engenheiro de Vendas Red Hat se isto ocorrer.

4.7. Testando os efeitos dos ambientes de aplicação no desempenho do VDO

Estes testes determinam como sua configuração VDO se comporta quando implantada em um ambiente de aplicação misto e real. Se você souber mais detalhes sobre o ambiente esperado, teste-os também.

Pré-requisitos

  • Considere limitar a profundidade admissível da fila em sua configuração.
  • Se possível, ajuste o pedido para emitir pedidos com os tamanhos de bloco que são os mais benéficos para o desempenho da VDO.

Procedimento

  1. Criar um novo volume VDO.

    Para maiores detalhes, ver Seção 4.2, “Criação de um volume VDO para testes de desempenho”.

  2. Preencha quaisquer áreas que o teste possa acessar realizando um trabalho de escrita fio sobre o volume do teste:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre o rendimento e a latência relatados para o estímulo de entrada de leitura e escrita:

    # for readmix in 20 50 80; do
        for iosize in 4 8 16 32 64 128 256 512 1024; do
          fio --rw=rw \
              --rwmixread=$readmix \
              --bsrange=4k-256k \
              --name=vdo \
              --filename=/dev/mapper/vdo-name \
              --ioengine=libaio \
              --numjobs=1 \
              --thread \
              --norandommap \
              --runtime=300 \
              --direct=0 \
              --iodepth=$iosize \
              --scramble_buffers=1 \
              --offset=0 \
              --size=100g
        done
      done
  4. Retirar o volume de teste VDO.

    Para maiores detalhes, ver Seção 4.3, “Limpeza do volume de testes de desempenho do VDO”.

  5. Gráfico dos resultados do teste.

    Exemplo 4.4. Análise do ambiente de aplicação

    A imagem a seguir mostra um exemplo de como a VDO pode responder a cargas mistas de E/S:

    Figura 4.5. Desempenho do ambiente misto

    Mixed environment performance

4.8. Opções utilizadas para testar o desempenho do VDO com fio

Os testes VDO utilizam o utilitário fio para gerar sinteticamente dados com características repetíveis. As seguintes opções fio são necessárias para simular as cargas de trabalho do mundo real nos testes:

Tabela 4.1. Utilizado fio opções

ArgumentoDescriçãoValor utilizado nos testes

--size

A quantidade de dados que fio envia para o alvo por trabalho.

Veja também a opção --numjobs.

100 GiB

--bs

O tamanho do bloco de cada pedido de leitura e escrita produzido por fio.

A Red Hat recomenda um tamanho de bloco de 4 KiB para corresponder a 4 KiB padrão da VDO.

4k

--numjobs

O número de empregos que o site fio cria para o benchmark.

Cada trabalho envia a quantidade de dados especificada pela opção --size. O primeiro trabalho envia os dados para o dispositivo no offset especificado pela opção --offset. Os trabalhos subseqüentes sobrescrevem a mesma região do disco, a menos que você forneça a opção --offset_increment, que compensa cada trabalho de onde o trabalho anterior começou por esse valor.

Para atingir o desempenho máximo em discos flash (SSD), a Red Hat recomenda pelo menos dois trabalhos. Um trabalho é normalmente suficiente para saturar a produção do disco rotativo (HDD).

1 para HDD, 2 para SSD

--thread

Encarrega o site fio de executar os trabalhos em linhas em vez de garfos, o que poderia proporcionar melhor desempenho limitando a mudança de contexto.

none

--ioengine

O motor de E/S que fio utiliza para o benchmark.

O teste da Red Hat usa o motor assíncrono sem tampão chamado libaio para testar cargas de trabalho onde um ou mais processos estão fazendo solicitações simultâneas aleatórias. O motor libaio permite que um único tópico faça várias solicitações assíncronas antes de recuperar quaisquer dados. Isto limita o número de comutadores de contexto que um mecanismo síncrono exigiria se ele fornecesse as solicitações por muitos threads.

libaio

--direct

A opção permite que os pedidos apresentados ao dispositivo contornem o cache de páginas do kernel.

Você deve usar o motor libaio com a opção --direct. Caso contrário, o kernel usa a API de sincronização para todas as solicitações de E/S.

1 (libaio)

--iodepth

O número de buffers de E/S em vôo a qualquer momento.

Um valor alto normalmente aumenta o desempenho, particularmente para leituras ou escritas aleatórias. Valores altos garantem que o controlador tenha sempre pedidos de lote. Entretanto, a definição do valor muito alto, (normalmente maior que 1K, pode causar latência indesejável.

A Red Hat recomenda um valor entre 128 e 512. O valor final é um trade-off e depende de como sua aplicação tolera a latência.

128 no mínimo

--iodepth_batch_submit

O número de pedidos de E/S a serem criados quando o pool de tampão de profundidade de E/S começa a esvaziar.

Esta opção limita a troca de tarefas das operações de E/S para a criação de buffer durante o teste.

16

--iodepth_batch_complete

O número de operações de E/S a serem concluídas antes da apresentação de um lote.

Esta opção limita a troca de tarefas das operações de E/S para a criação de buffer durante o teste.

16

--gtod_reduce

Desativa as chamadas de tempo do dia para calcular a latência.

Este ajuste reduz a produção se ativado. Habilite a opção a menos que você necessite de medição de latência.

1

Capítulo 5. Descartando blocos não utilizados

Você pode realizar ou programar operações de descarte em dispositivos de bloco que os suportem.

5.1. Operações de descarte em bloco

As operações de descarte de blocos descartam blocos que não estão mais em uso por um sistema de arquivo montado. Eles são úteis:

  • Acionamentos em estado sólido (SSDs)
  • Armazenagem de provisão fina

Requisitos

O dispositivo de bloco subjacente ao sistema de arquivo deve suportar operações de descarte físico.

As operações de descarte físico são suportadas se o valor no /sys/block/device/queue/discard_max_bytes arquivo não é zero.

5.2. Tipos de operações de descarte em bloco

Você pode executar operações de descarte usando métodos diferentes:

Lote de descarte
São administrados explicitamente pelo usuário. Eles descartam todos os blocos não utilizados nos sistemas de arquivo selecionados.
Descarte on-line
São especificados no momento da montagem. Funcionam em tempo real, sem a intervenção do usuário. As operações de descarte on-line descartam apenas os blocos que estão passando de usados para livres.
Descarte periódico
São operações em lote que são administradas regularmente por um serviço systemd.

Todos os tipos são suportados pelos sistemas de arquivo XFS e ext4 e pela VDO.

Recomendações

A Red Hat recomenda que você utilize descarte em lote ou periódico.

Usar o descarte on-line somente se:

  • a carga de trabalho do sistema é tal que o descarte de lotes não é viável, ou
  • as operações de descarte on-line são necessárias para manter o desempenho.

5.3. Execução de descarte de blocos em lote

Este procedimento realiza uma operação de descarte de blocos em lote para descartar blocos não utilizados em um sistema de arquivo montado.

Pré-requisitos

  • O sistema de arquivo é montado.
  • O dispositivo de bloco subjacente ao sistema de arquivo suporta operações de descarte físico.

Procedimento

  • Use o utilitário fstrim:

    • Para realizar descarte somente em um sistema de arquivo selecionado, use:

      # fstrim mount-point
    • Para realizar descarte em todos os sistemas de arquivos montados, use:

      # fstrim -- tudo

Se você executar o comando fstrim em:

  • um dispositivo que não suporta operações de descarte, ou
  • um dispositivo lógico (LVM ou MD) composto de múltiplos dispositivos, onde qualquer um dos dispositivos não suporta operações de descarte,

a seguinte mensagem é exibida:

# fstrim /mnt/non_discard

fstrim: /mnt/non_discard: the discard operation is not supported

Recursos adicionais

  • A página do homem fstrim(8)

5.4. Permitindo o descarte em bloco online

Este procedimento permite operações de descarte de blocos on-line que descartam automaticamente blocos não utilizados em todos os sistemas de arquivo suportados.

Procedimento

  • Habilitar o descarte on-line no momento da montagem:

    • Ao montar um sistema de arquivo manualmente, adicione a opção de montagem -o discard:

      # montar -o descartar device mount-point
    • Ao montar um sistema de arquivo de forma persistente, adicione a opção discard à entrada de montagem no arquivo /etc/fstab.

Recursos adicionais

  • A página do homem mount(8)
  • A página do homem fstab(5)

5.5. Permitindo o descarte em bloco online usando as funções do sistema RHEL

Esta seção descreve como habilitar o descarte em bloco online usando a função storage.

Pré-requisitos

  • Existe um livro de brincadeiras possível, incluindo o papel storage.

Para informações sobre como aplicar tal playbook, consulte Aplicando um papel.

5.5.1. Exemplo Livro de reprodução possível para permitir o descarte em bloco online

Esta seção fornece um exemplo de um livro de brincadeiras possível. Este playbook aplica o papel storage para montar um sistema de arquivo XFS com o descarte de blocos on-line habilitado.

Exemplo 5.1. Um playbook que permite o descarte de blocos online em /mnt/dados/

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
        mount_options: discard
  roles:
    - rhel-system-roles.storage

Recursos adicionais

  • Para detalhes sobre os parâmetros utilizados na função do sistema storage, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

5.5.2. Recursos adicionais

5.6. Possibilitando o descarte periódico em bloco

Este procedimento permite um temporizador systemd que descarta regularmente blocos não utilizados em todos os sistemas de arquivo suportados.

Procedimento

  • Habilitar e iniciar o temporizador systemd:

    # systemctl habilita --now fstrim.timer

Capítulo 6. Visão geral dos atributos de nomeação persistentes

Como administrador de sistema, você precisa se referir aos volumes de armazenamento usando atributos de nomes persistentes para construir configurações de armazenamento que sejam confiáveis em várias boots de sistema.

6.1. Desvantagens dos atributos de nomenclatura não-persistentes

O Red Hat Enterprise Linux oferece uma série de maneiras de identificar dispositivos de armazenamento. É importante usar a opção correta para identificar cada dispositivo quando usado a fim de evitar o acesso inadvertido ao dispositivo errado, particularmente ao instalar ou reformatar unidades.

Tradicionalmente, nomes não-persistentes na forma de /dev/sd(major number)(minor number) são usados no Linux para se referir a dispositivos de armazenamento. A faixa de números maiores e menores e os nomes associados a sd são alocados para cada dispositivo quando ele é detectado. Isto significa que a associação entre o intervalo de números maior e menor e os nomes associados sd podem mudar se a ordem de detecção do dispositivo mudar.

Tal mudança no ordenamento pode ocorrer nas seguintes situações:

  • A paralelização do processo de inicialização do sistema detecta os dispositivos de armazenamento em uma ordem diferente com cada inicialização do sistema.
  • Um disco não consegue ligar ou responder ao controlador SCSI. Isto faz com que ele não seja detectado pela sonda normal do dispositivo. O disco não é acessível ao sistema e os dispositivos subseqüentes terão sua faixa de maior e menor número, incluindo os nomes associados sd deslocados para baixo. Por exemplo, se um disco normalmente referido como sdb não for detectado, um disco que normalmente é referido como sdc apareceria como sdb.
  • Um controlador SCSI (host bus adapter, ou HBA) não se inicializa, fazendo com que todos os discos conectados a esse HBA não sejam detectados. A quaisquer discos conectados a HBAs subseqüentemente sondados são atribuídas diferentes faixas de números maiores e menores, e diferentes nomes associados a sd.
  • A ordem de inicialização do motorista muda se diferentes tipos de HBAs estiverem presentes no sistema. Isto faz com que os discos conectados a esses HBAs sejam detectados em uma ordem diferente. Isto também pode ocorrer se os HBAs forem movidos para diferentes slots PCI no sistema.
  • Os discos conectados ao sistema com adaptadores Fibre Channel, iSCSI ou FCoE podem estar inacessíveis no momento em que os dispositivos de armazenamento são sondados, devido a uma matriz de armazenamento ou interruptor de intervenção sendo desligado, por exemplo. Isto pode ocorrer quando um sistema é reinicializado após uma falha de energia, se a matriz de armazenamento levar mais tempo para ficar on-line do que o sistema leva para arrancar. Embora alguns drivers Fibre Channel suportem um mecanismo para especificar uma identificação de alvo SCSI persistente para o mapeamento WWPN, isto não faz com que as faixas de números maiores e menores, e os nomes associados sd sejam reservados; ele só fornece números de identificação de alvo SCSI consistentes.

Estas razões tornam indesejável o uso da faixa de números maiores e menores ou dos nomes associados sd ao se referir aos dispositivos, como no arquivo /etc/fstab. Existe a possibilidade de que o dispositivo errado seja montado e a corrupção de dados possa resultar.

Ocasionalmente, porém, ainda é necessário consultar os nomes sd mesmo quando outro mecanismo é utilizado, como quando são relatados erros por um dispositivo. Isto porque o kernel Linux usa os nomes sd (e também os nomes SCSI host/channel/target/LUN tuples) nas mensagens do kernel referentes ao dispositivo.

6.2. Sistema de arquivos e identificadores de dispositivos

Esta seção explica a diferença entre atributos persistentes que identificam sistemas de arquivos e dispositivos de blocos.

Identificadores do sistema de arquivo

Os identificadores do sistema de arquivo são vinculados a um sistema de arquivo particular criado em um dispositivo de bloco. O identificador também é armazenado como parte do sistema de arquivo. Se você copiar o sistema de arquivo para um dispositivo diferente, ele ainda carrega o mesmo identificador de sistema de arquivo. Por outro lado, se você reescrever o dispositivo, por exemplo, formatando-o com o utilitário mkfs, o dispositivo perde o atributo.

Os identificadores do sistema de arquivo incluem:

  • Identificador único (UUID)
  • Etiqueta

Identificadores de dispositivos

Os identificadores de dispositivos são vinculados a um dispositivo de bloco: por exemplo, um disco ou uma partição. Se você reescrever o dispositivo, por exemplo, formatando-o com o utilitário mkfs, o dispositivo mantém o atributo, pois ele não é armazenado no sistema de arquivos.

Os identificadores de dispositivos incluem:

  • World Wide Identifier (WWID)
  • Partição UUID
  • Número de série

Recomendações

  • Alguns sistemas de arquivo, tais como volumes lógicos, abrangem vários dispositivos. A Red Hat recomenda acessar esses sistemas de arquivo usando identificadores de sistemas de arquivo em vez de identificadores de dispositivos.

6.3. Nomes de dispositivos gerenciados pelo mecanismo udev em /dev/disco/

Esta seção lista diferentes tipos de atributos de nomes persistentes que o serviço udev fornece no diretório /dev/disk/.

O mecanismo udev é usado para todos os tipos de dispositivos no Linux, não apenas para dispositivos de armazenamento. No caso de dispositivos de armazenamento, o Red Hat Enterprise Linux contém udev regras que criam links simbólicos no diretório /dev/disk/. Isto permite que você se refira aos dispositivos de armazenamento por:

  • Seu conteúdo
  • Um identificador único
  • Seu número de série.

Embora os atributos de nomenclatura udev sejam persistentes, na medida em que não mudam por si mesmos através de reinicializações do sistema, alguns também são configuráveis.

6.3.1. Identificadores do sistema de arquivo

O atributo UUID em /dev/disco/by-uuid/

As entradas neste diretório fornecem um nome simbólico que se refere ao dispositivo de armazenamento por um unique identifier (UUID) no conteúdo (ou seja, os dados) armazenados no dispositivo. Por exemplo, o nome do dispositivo:

/dev/disco/by-uuid/3e6be9de-8139-11d1-9106-a43f08d823a6

Você pode usar a UUID para consultar o dispositivo no arquivo /etc/fstab usando a seguinte sintaxe:

UUID=3e6be9de-8139-11d1-9106-a43f08d823a6

Você pode configurar o atributo UUID ao criar um sistema de arquivo, e também pode alterá-lo mais tarde.

O atributo Label in /dev/disk/by-label/

As entradas neste diretório fornecem um nome simbólico que se refere ao dispositivo de armazenamento por um label no conteúdo (ou seja, os dados) armazenados no dispositivo.

Por exemplo:

/dev/disco/by-label/Boot

Você pode usar a etiqueta para se referir ao dispositivo no arquivo /etc/fstab usando a seguinte sintaxe:

LABEL=Boot

Você pode configurar o atributo Label ao criar um sistema de arquivo, e também pode alterá-lo posteriormente.

6.3.2. Identificadores de dispositivos

O atributo WWID em /dev/disco/by-id/

O World Wide Identifier (WWID) é um persistente, system-independent identifier que a norma SCSI exige de todos os dispositivos SCSI. O identificador WWID é garantido como único para cada dispositivo de armazenamento, e independente do caminho que é usado para acessar o dispositivo. O identificador é uma propriedade do dispositivo, mas não é armazenado no conteúdo (ou seja, os dados) dos dispositivos.

Este identificador pode ser obtido emitindo um SCSI Inquiry para recuperar os Dados Vitais de Identificação do Dispositivo (página 0x83) ou o Número de Série da Unidade (página 0x80).

O Red Hat Enterprise Linux mantém automaticamente o mapeamento adequado do nome do dispositivo baseado na WWID para um nome atual /dev/sd naquele sistema. As aplicações podem usar o nome /dev/disk/by-id/ para referenciar os dados no disco, mesmo que o caminho para o dispositivo mude, e mesmo ao acessar o dispositivo a partir de sistemas diferentes.

Exemplo 6.1. Mapas da WWID

WWID symlinkDispositivo não-persistenteNota

/dev/disk/by-id/scsi-3600508b400105e210000900000490000

/dev/sda

Um dispositivo com uma página 0x83 identificador

/dev/disk/by-id/scsi-SSEAGATE_ST373453LW_3HW1RHM6

/dev/sdb

Um dispositivo com uma página 0x80 identificador

/dev/disk/by-id/ata-SAMSUNG_MZNLN256HMHQ-000L7_S2WDNX0J336519-part3

/dev/sdc3

Uma partição de disco

Além desses nomes persistentes fornecidos pelo sistema, você também pode usar as regras do udev para implementar nomes persistentes próprios, mapeados para a WWID do armazenamento.

O atributo Partição UUID em /dev/disco/by-partuuid

O atributo Partição UUID (PARTUUID) identifica as partições como definidas pela tabela de partição GPT.

Exemplo 6.2. Mapeamentos de partição UUID

Link simbólico PARTUÍDODispositivo não-persistente

/dev/disk/by-partuuid/4cd1448a-01

/dev/sda1

/dev/disk/by-partuuid/4cd1448a-02

/dev/sda2

/dev/disk/by-partuuid/4cd1448a-03

/dev/sda3

O atributo Caminho em /dev/disco/by-path/

Este atributo fornece um nome simbólico que se refere ao dispositivo de armazenamento pelo hardware path usado para acessar o dispositivo.

O atributo Path falha se qualquer parte do caminho do hardware (por exemplo, o PCI ID, porta de destino, ou número LUN) mudar. O atributo Caminho não é, portanto, confiável. Entretanto, o atributo Caminho pode ser útil em um dos seguintes cenários:

  • Você precisa identificar um disco que está planejando substituir mais tarde.
  • Você planeja instalar um serviço de armazenamento em um disco em um local específico.

6.4. O identificador mundial com DM Multipath

Esta seção descreve o mapeamento entre o World Wide Identifier (WWID) e os nomes de dispositivos não persistentes em uma configuração Multipath Mapper Device Mapper.

Se houver múltiplos caminhos de um sistema para um dispositivo, a DM Multipath usa a WWID para detectar isso. A DM Multipath então apresenta um único "pseudo-dispositivo" no diretório /dev/mapper/wwid, tal como /dev/mapper/3600508b400105df70000e00000ac0000.

O comando multipath -l mostra o mapeamento aos identificadores não-persistentes:

  • Host:Channel:Target:LUN
  • /dev/sd nome
  • major:minor número

Exemplo 6.3. Mapas da WWID em uma configuração multipath

Um exemplo de saída do comando multipath -l:

3600508b400105df70000e00000ac0000 dm-2 vendor,product
[size=20G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=0][active]
 \_ 5:0:1:1 sdc 8:32  [active][undef]
 \_ 6:0:1:1 sdg 8:96  [active][undef]
\_ round-robin 0 [prio=0][enabled]
 \_ 5:0:0:1 sdb 8:16  [active][undef]
 \_ 6:0:0:1 sdf 8:80  [active][undef]

DM Multipath mantém automaticamente o mapeamento adequado de cada nome de dispositivo baseado na WWID para seu correspondente nome /dev/sd no sistema. Estes nomes são persistentes nas mudanças de caminho, e são consistentes ao acessar o dispositivo a partir de diferentes sistemas.

Quando o recurso user_friendly_names do DM Multipath é usado, o WWID é mapeado para um nome do formulário /dev/mapper/mpathN. Por padrão, este mapeamento é mantido no arquivo /etc/multipath/bindings. Estes mpathN são persistentes, desde que esse arquivo seja mantido.

Importante

Se você utiliza user_friendly_names, então são necessários passos adicionais para obter nomes consistentes em um cluster.

6.5. Limitações da convenção de nomenclatura de dispositivos udev

A seguir estão algumas limitações da convenção de nomenclatura udev:

  • É possível que o dispositivo não esteja acessível no momento em que a consulta é realizada porque o mecanismo udev pode confiar na capacidade de consultar o dispositivo de armazenamento quando as regras do udev são processadas para um evento udev. Isto é mais provável que ocorra com dispositivos de armazenamento Fibre Channel, iSCSI ou FCoE quando o dispositivo não está localizado no chassi do servidor.
  • O kernel pode enviar eventos udev a qualquer momento, fazendo com que as regras sejam processadas e possivelmente fazendo com que os links /dev/disk/by-*/ sejam removidos se o dispositivo não estiver acessível.
  • Pode haver um atraso entre quando o evento udev é gerado e quando ele é processado, como quando um grande número de dispositivos é detectado e o serviço udevd de espaço do usuário leva algum tempo para processar as regras para cada um deles. Isto pode causar um atraso entre quando o kernel detecta o dispositivo e quando os nomes /dev/disk/by-*/ estão disponíveis.
  • Programas externos como o blkid invocado pelas regras podem abrir o dispositivo por um breve período de tempo, tornando o dispositivo inacessível para outros usos.
  • Os nomes dos dispositivos gerenciados pelo mecanismo udev em /dev/disco/ podem mudar entre os principais lançamentos, exigindo a atualização dos links.

6.6. Listagem de atributos de nomeação persistentes

Este procedimento descreve como descobrir os atributos persistentes de nomes de dispositivos de armazenamento não persistentes.

Procedimento

  • Para listar os atributos UUID e Label, use o utilitário lsblk:

    $ lsblk --fs storage-device

    Por exemplo:

    Exemplo 6.4. Visualização da UUID e do rótulo de um sistema de arquivo

    $ lsblk --fs /dev/sda1
    
    NAME FSTYPE LABEL UUID                                 MOUNTPOINT
    sda1 xfs    Boot  afa5d5e3-9050-48c3-acc1-bb30095f3dc4 /boot
  • Para listar o atributo PARTUUID, use o utilitário lsblk com a opção --output PARTUUID:

    $ lsblk -- saída PARTUÍDO

    Por exemplo:

    Exemplo 6.5. Visualização do atributo PARTUUIDO de uma partição

    $ lsblk --output +PARTUUID /dev/sda1
    
    NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT PARTUUID
    sda1   8:1    0  512M  0 part /boot      4cd1448a-01
  • Para listar o atributo WWID, examine os alvos dos links simbólicos no diretório /dev/disk/by-id/. Por exemplo:

    Exemplo 6.6. Visualização da WWID de todos os dispositivos de armazenamento no sistema

    $ file /dev/disk/by-id/*
    
    /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001
    symbolic link to ../../sda
    /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1
    symbolic link to ../../sda1
    /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
    symbolic link to ../../sda2
    /dev/disk/by-id/dm-name-rhel_rhel8-root
    symbolic link to ../../dm-0
    /dev/disk/by-id/dm-name-rhel_rhel8-swap
    symbolic link to ../../dm-1
    /dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhP0RMFsNyySVihqEl2cWWbR7MjXJolD6g
    symbolic link to ../../dm-1
    /dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhXqH2M45hD2H9nAf2qfWSrlRLhzfMyOKd
    symbolic link to ../../dm-0
    /dev/disk/by-id/lvm-pv-uuid-atlr2Y-vuMo-ueoH-CpMG-4JuH-AhEF-wu4QQm
    symbolic link to ../../sda2

6.7. Modificação de atributos de nomeação persistentes

Este procedimento descreve como alterar o atributo de nomeação persistente UUID ou Label de um sistema de arquivo.

Nota

A mudança dos atributos udev acontece em segundo plano e pode demorar muito tempo. O comando udevadm settle espera até que a mudança seja totalmente registrada, o que garante que seu próximo comando será capaz de utilizar o novo atributo corretamente.

Nos seguintes comandos:

  • Substitua new-uuid com a UUID que você deseja definir; por exemplo, 1cdfbc07-1c90-4984-b5ec-f61943f5ea50. Você pode gerar uma UUID usando o comando uuidgen.
  • Substitua new-label com um rótulo; por exemplo, backup_data.

Pré-requisitos

  • Se você estiver modificando os atributos de um sistema de arquivo XFS, desmonte-o primeiro.

Procedimento

  • Para alterar os atributos UUID ou Label de um sistema de arquivos XFS, use o utilitário xfs_admin:

    # xfs_admin -U new-uuid -L new-label storage-device
    # udevadm settle
  • Para alterar os atributos UUID ou Label de um sistema de arquivos ext4, ext3, ou ext2, use o utilitário tune2fs:

    # tune2fs -U new-uuid -L new-label storage-device
    # udevadm settle
  • Para alterar os atributos UUID ou Label de um volume swap, use o utilitário swaplabel:

    # swaplabel --uuid new-uuid --label new-label swap-device
    # udevadm settle

Capítulo 7. Usando o console web para gerenciar volumes do Virtual Data Optimizer

Configure o Virtual Data Optimizer (VDO) usando o console web RHEL 8.

Você aprenderá como fazê-lo:

  • Criar volumes VDO
  • Formato volumes VDO
  • Ampliar os volumes VDO

Pré-requisitos

  • O console web RHEL 8 está instalado e acessível.

    Para detalhes, consulte Instalando o console web.

  • O pacote cockpit-storaged está instalado em seu sistema.

7.1. Volumes VDO no console web

O Red Hat Enterprise Linux 8 suporta o Virtual Data Optimizer (VDO).

A VDO é uma tecnologia de virtualização em bloco que combina:

Compressão
Para detalhes, consulte Habilitação ou desativação da compressão em VDO.
Deduplicação
Para detalhes, veja Habilitação ou desabilitação da deduplicação em VDO.
Provisão fina
Para obter detalhes, consulte os volumes lógicos fornecidos finamente (volumes finos).

Utilizando estas tecnologias, a VDO:

  • Economiza espaço de armazenamento em linha
  • Comprime arquivos
  • Elimina duplicações
  • Permite-lhe alocar mais espaço virtual do que o espaço físico ou lógico de armazenamento
  • Permite ampliar o armazenamento virtual através do crescimento

O VDO pode ser criado em cima de muitos tipos de armazenamento. No console web RHEL 8, você pode configurar o VDO em cima de:

  • LVM

    Nota

    Não é possível configurar o VDO em cima de volumes pouco fornecidos.

  • Volume físico
  • Software RAID

Para detalhes sobre a colocação do VDO na Pilha de Armazenamento, veja Requisitos do Sistema.

Recursos adicionais

7.2. Criação de volumes VDO no console web

Crie um volume VDO no console web RHEL.

Pré-requisitos

  • Unidades físicas, LVMs, ou RAID a partir dos quais você deseja criar VDO.

Procedimento

  1. Acesse o console web RHEL 8.

    Para obter detalhes, consulte Login no console web.

  2. Clique em Storage.
  3. Clique no ícone na caixa VDO Devices.

    cockpit adicionando vdo

  4. No campo Name, digite um nome de um volume VDO sem espaços.
  5. Selecione a unidade que você deseja usar.
  6. Na barra Logical Size, configure o tamanho do volume do VDO. Você pode estendê-lo mais de dez vezes, mas considere para que finalidade está criando o volume VDO:

    • Para VMs ativas ou armazenamento de contêineres, usar tamanho lógico que seja dez vezes o tamanho físico do volume.
    • Para o armazenamento de objetos, usar tamanho lógico que é três vezes o tamanho físico do volume.

    Para obter detalhes, consulte Implantação de VDO.

  7. Na barra Index Memory, alocar memória para o volume VDO.

    Para obter detalhes sobre os requisitos do sistema VDO, consulte Requisitos do sistema.

  8. Selecione a opção Compression. Esta opção pode reduzir eficientemente vários formatos de arquivo.

    Para detalhes, consulte Habilitação ou desativação da compressão em VDO.

  9. Selecione a opção Deduplication.

    Esta opção reduz o consumo de recursos de armazenamento ao eliminar múltiplas cópias de blocos duplicados. Para detalhes, veja Habilitação ou desabilitação da deduplicação em VDO.

  10. [Opcional] Se você quiser usar o volume VDO com aplicações que necessitam de um bloco de 512 bytes, selecione Use 512 Byte emulation. Isto reduz o desempenho do volume do VDO, mas deve ser muito raramente necessário. Em caso de dúvida, deixe-o desligado.
  11. Clique em Create.

    cockpit criar diálogo vdo

Se o processo de criação do volume VDO for bem sucedido, você pode ver o novo volume VDO na seção Storage e formatá-lo com um sistema de arquivo.

cockpit vdo criado

7.3. Formatação de volumes VDO no console web

Os volumes VDO atuam como acionamentos físicos. Para utilizá-los, é necessário formatá-los com um sistema de arquivo.

Atenção

A formatação do VDO apagará todos os dados sobre o volume.

Os passos seguintes descrevem o procedimento para formatar os volumes VDO.

Pré-requisitos

Procedimento

  1. Acesse o console web RHEL 8.

    Para obter detalhes, consulte Login no console web.

  2. Clique em Storage.
  3. Clique no volume VDO.
  4. Clique na guia Unrecognized Data.
  5. Clique em Format.

    formato cockpit vdo

  6. No menu suspenso Erase, selecione:

    Don’t overwrite existing data
    O console web RHEL reescreve apenas o cabeçalho do disco. A vantagem desta opção é a velocidade da formatação.
    Overwrite existing data with zeros
    O console web RHEL reescreve o disco inteiro com zeros. Esta opção é mais lenta porque o programa tem que passar por todo o disco. Use esta opção se o disco incluir quaisquer dados e você precisar reescrevê-los.
  7. No menu suspenso Type, selecione um sistema de arquivos:

    • O sistema de arquivos XFS suporta grandes volumes lógicos, alternando acionamentos físicos on-line sem interrupções e crescendo. Deixe este sistema de arquivo selecionado se você não tiver uma preferência forte diferente.

      O XFS não suporta volumes decrescentes. Portanto, você não será capaz de reduzir o volume formatado com XFS.

    • O sistema de arquivo ext4 suporta volumes lógicos, alternando acionamentos físicos on-line sem interrupção, crescendo e encolhendo.

    Você também pode selecionar uma versão com a criptografia LUKS (Linux Unified Key Setup), que lhe permite criptografar o volume com uma frase-chave.

  8. No campo Name, digite o nome do volume lógico.
  9. No menu suspenso Mounting, selecione Custom.

    A opção Default não garante que o sistema de arquivo será montado na próxima inicialização.

  10. No campo Mount Point, adicione o caminho de montagem.
  11. Selecione Mount at boot.

    formato do cockpit lv

  12. Clique em Format.

    A formatação pode levar vários minutos, dependendo das opções de formatação utilizadas e do tamanho do volume.

    Após um acabamento bem sucedido, você pode ver os detalhes do volume formatado do VDO na aba Filesystem.

    formato cockpit vdo

  13. Para utilizar o volume VDO, clique em Mount.

Neste ponto, o sistema utiliza o volume VDO montado e formatado.

7.4. Ampliação dos volumes VDO no console web

Ampliar os volumes VDO no console web RHEL 8.

Pré-requisitos

  • O pacote cockpit-storaged está instalado em seu sistema.
  • O volume VDO criado.

Procedimento

  1. Acesse o console web RHEL 8.

    Para obter detalhes, consulte Login no console web.

  2. Clique em Storage.
  3. Clique no volume de seu VDO na caixa VDO Devices.

    cockpit vdo criado

  4. Nos detalhes de volume do VDO, clique no botão Grow.
  5. Na caixa de diálogo Grow logical size of VDO, ampliar o tamanho lógico do volume VDO.

    o cockpit vdo cresce feito

    O tamanho original do volume lógico da imagem da tela era de 6 GB. Como você pode ver, o console web RHEL permite aumentar o volume para mais de dez vezes o tamanho e funciona corretamente por causa da compressão e da deduplicação.

  6. Clique em Grow.

Se o processo de crescimento do VDO for bem sucedido, você pode ver o novo tamanho nos detalhes de volume do VDO.

cockpit vdo crescer detalhes