Aplica-se a SUSE Enterprise Storage 7

20 Dispositivo de Blocos RADOS #

Um bloco é uma sequência de bytes. Por exemplo, um bloco de dados de 4 MB. As interfaces de armazenamento com base em blocos são a maneira mais comum para armazenar dados com mídia rotativa, como discos rígidos, CDs e disquetes. A onipresença de interfaces de dispositivo de blocos faz do dispositivo de blocos virtual o candidato ideal para interagir com um sistema de armazenamento de dados em massa, como o Ceph.

Os dispositivos de blocos do Ceph permitem o compartilhamento de recursos físicos e são redimensionáveis. Eles armazenam dados distribuídos por vários OSDs em um cluster do Ceph. Os dispositivos de blocos do Ceph aproveitam os recursos do RADOS, como criação de instantâneos, replicação e consistência. Os Dispositivo de Blocos RADOS (RBD) do Ceph interagem com os OSDs usando os módulos do kernel ou a biblioteca librbd.

Figura 20.1: Protocolo RADOS #

Os dispositivos de blocos do Ceph oferecem alto desempenho com escalabilidade infinita aos módulos do kernel. Eles suportam soluções de virtualização, como QEMU, ou sistemas de computação com base em nuvem, como OpenStack, que utilizam a libvirt. Você pode usar o mesmo cluster para operar o Gateway de Objetos, o CephFS e os Dispositivos de Blocos RADOS simultaneamente.

20.1 Comandos do dispositivo de blocos #

O comando rbd permite criar, listar, avaliar e remover imagens de dispositivo de blocos. Você também pode usá-lo, por exemplo, para clonar imagens, criar instantâneos, voltar uma imagem para um instantâneo ou ver um instantâneo.

20.1.1 Criando uma imagem de dispositivo de blocos em um pool replicado #

Antes que você possa adicionar um dispositivo de blocos a um cliente, precisa criar uma imagem relacionada em um pool existente (consulte o Capítulo 18, Gerenciar pools de armazenamento):

cephuser@adm > rbd create --size MEGABYTES POOL-NAME/IMAGE-NAME

Por exemplo, para criar uma imagem de 1 GB denominada “myimage” que armazena informações em um pool chamado “mypool”, execute o seguinte:

cephuser@adm > rbd create --size 1024 mypool/myimage

Dica: Unidades de tamanho de imagem

Se você omitir um atalho de unidade de tamanho (“G” ou “T”), o tamanho da imagem será em megabytes. Use “G” ou “T” após o número do tamanho para especificar gigabytes ou terabytes.

20.1.2 Criando uma imagem de dispositivo de blocos em um pool codificado para eliminação #

É possível armazenar dados de uma imagem de dispositivo de blocos diretamente em pools codificados para eliminação (EC, Erasure Coded). A imagem de um Dispositivo de Blocos RADOS consiste nas partes de dados e metadados. Você pode armazenar apenas a parte de dados de uma imagem de Dispositivo de Blocos RADOS em um pool EC. O pool precisa ter o flag overwrite definido como true, e isso apenas será possível se todos os OSDs em que o pool está armazenado usarem o BlueStore.

Você não pode armazenar a parte de metadados da imagem em um pool EC. Você pode especificar o pool replicado para armazenar os metadados da imagem com a opção --pool= do comando rbd create ou especificar pool/ como prefixo para o nome da imagem.

Crie um pool EC:

cephuser@adm > ceph osd pool create EC_POOL 12 12 erasure
cephuser@adm > ceph osd pool set EC_POOL allow_ec_overwrites true

Especifique o pool replicado para armazenar os metadados:

cephuser@adm > rbd create IMAGE_NAME --size=1G --data-pool EC_POOL --pool=POOL

Ou:

cephuser@adm > rbd create POOL/IMAGE_NAME --size=1G --data-pool EC_POOL

20.1.3 Listando imagens de dispositivo de blocos #

Para listar os dispositivos de blocos em um pool chamado “mypool”, execute o seguinte:

cephuser@adm > rbd ls mypool

20.1.4 Recuperando informações da imagem #

Para recuperar as informações de uma imagem “myimage” em um pool chamado “mypool”, execute o seguinte:

cephuser@adm > rbd info mypool/myimage

20.1.5 Redimensionando uma imagem de dispositivo de blocos #

As imagens de Dispositivo de Blocos RADOS são aprovisionadas dinamicamente, elas não usam nenhum armazenamento físico até você começar a gravar dados nelas. No entanto, elas têm uma capacidade máxima que você define com a opção --size. Para aumentar (ou diminuir) o tamanho máximo da imagem, execute o seguinte:

cephuser@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME # to increase
cephuser@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME --allow-shrink # to decrease

20.1.6 Removendo uma imagem de dispositivo de blocos #

Para remover um dispositivo de blocos correspondente a uma imagem “myimage” no pool chamado “mypool”, execute o seguinte:

cephuser@adm > rbd rm mypool/myimage

20.2 Montando e desmontando #

Após criar um Dispositivo de Blocos RADOS, você poderá usá-lo como qualquer outro dispositivo de disco: formatá-lo, montá-lo para poder trocar arquivos e desmontá-lo depois de concluído.

O comando rbd usa como padrão o acesso ao cluster por meio da conta do usuário admin do Ceph. Essa conta tem acesso administrativo completo ao cluster. Esse comportamento cria o risco de danos acidentais, similar ao login em uma estação de trabalho Linux como root. Portanto, é preferível criar contas dos usuários com menos privilégios e usá-las para acesso normal de leitura/gravação ao Dispositivo de Blocos RADOS.

20.2.1 Criando uma conta do usuário do Ceph #

Para criar uma nova conta do usuário com os recursos Ceph Manager, Ceph Monitor e Ceph OSD, use o comando ceph com o subcomando auth get-or-create:

cephuser@adm > ceph auth get-or-create client.ID mon 'profile rbd' osd 'profile profile name \
  [pool=pool-name] [, profile ...]' mgr 'profile rbd [pool=pool-name]'

Por exemplo, para criar um usuário chamado qemu com acesso de leitura/gravação ao pool vms e acesso apenas leitura ao pool images, execute o seguinte:

ceph auth get-or-create client.qemu mon 'profile rbd' osd 'profile rbd pool=vms, profile rbd-read-only pool=images' \
  mgr 'profile rbd pool=images'

A saída do comando ceph auth get-or-create será o chaveiro do usuário especificado, que poderá gravar em /etc/ceph/ceph.client.ID.keyring.

Nota

Ao usar o comando rbd, você pode especificar o ID de usuário inserindo o argumento --id ID opcional.

Para obter mais detalhes sobre o gerenciamento de contas dos usuários do Ceph, consulte o Capítulo 30, Autenticação com cephx.

20.2.2 Autenticação de usuário #

Para especificar um nome de usuário, utilize --id user-name. Se você usa a autenticação do cephx, também precisa especificar um segredo. Ele pode vir de um chaveiro ou de um arquivo que contém o segredo:

cephuser@adm > rbd device map --pool rbd myimage --id admin --keyring /path/to/keyring

cephuser@adm > rbd device map --pool rbd myimage --id admin --keyfile /path/to/file

20.2.3 Preparando um Dispositivo de Blocos RADOS para uso #

Verifique se o cluster do Ceph inclui um pool com a imagem do disco que você deseja mapear. Considere o pool chamado mypool e a imagem myimage.
```
cephuser@adm > rbd list mypool
```

Mapeie a imagem para um novo dispositivo de blocos:

cephuser@adm > rbd device map --pool mypool myimage

Liste todos os dispositivos mapeados:
```
cephuser@adm > rbd device list
id pool   image   snap device
0  mypool myimage -    /dev/rbd0
```
O dispositivo no qual desejamos trabalhar é /dev/rbd0.
Dica: Caminho do dispositivo RBD
Em vez do /dev/rbdDEVICE_NUMBER, você pode usar /dev/rbd/POOL_NAME/IMAGE_NAME como o caminho de um dispositivo persistente. Por exemplo:
```
       /dev/rbd/mypool/myimage
```

Crie um sistema de arquivos XFS no dispositivo /dev/rbd0:

root # mkfs.xfs /dev/rbd0
      log stripe unit (4194304 bytes) is too large (maximum is 256KiB)
      log stripe unit adjusted to 32KiB
      meta-data=/dev/rbd0              isize=256    agcount=9, agsize=261120 blks
      =                       sectsz=512   attr=2, projid32bit=1
      =                       crc=0        finobt=0
      data     =                       bsize=4096   blocks=2097152, imaxpct=25
      =                       sunit=1024   swidth=1024 blks
      naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
      log      =internal log           bsize=4096   blocks=2560, version=2
      =                       sectsz=512   sunit=8 blks, lazy-count=1
      realtime =none                   extsz=4096   blocks=0, rtextents=0

Substitua /mnt por seu ponto de montagem, monte o dispositivo e verifique se ele foi montado corretamente:
```
root # mount /dev/rbd0 /mnt
      root # mount | grep rbd0
      /dev/rbd0 on /mnt type xfs (rw,relatime,attr2,inode64,sunit=8192,...
```
Agora, você pode mover os dados de e para o dispositivo como se ele fosse um diretório local.
Dica: Aumentando o tamanho do dispositivo RBD
Se você acha que o tamanho do dispositivo RBD não é mais suficiente, pode aumentá-lo com facilidade.
1. Aumente o tamanho da imagem RBD. Por exemplo, até 10 GB.
  cephuser@adm > rbd resize --size 10000 mypool/myimage Resizing image: 100% complete...done.
2. Expanda o sistema de arquivos para preencher o novo tamanho do dispositivo:
  root # xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000
Após terminar de acessar o dispositivo, você poderá anular o mapeamento e desmontá-lo.
```
cephuser@adm > rbd device unmap /dev/rbd0
root # unmount /mnt
```

Dica: Montagem e desmontagem manuais

Um script rbdmap e a unidade systemd são fornecidos para facilitar o processo de mapeamento e montagem de RBDs após a inicialização e de desmontagem deles antes do encerramento. Consulte a Seção 20.2.4, “rbdmap Mapear dispositivos RBD no momento da inicialização”.

20.2.4 `rbdmap` Mapear dispositivos RBD no momento da inicialização #

rbdmap é um script de shell que automatiza as operações rbd map e rbd device unmap em uma ou mais imagens RBD. Embora você possa executar o script manualmente a qualquer momento, a principal vantagem é mapear e montar automaticamente as imagens RBD no momento da inicialização (e desmontar e anular o mapeamento no encerramento), conforme acionado pelo sistema Init. Um arquivo da unidade systemd, rbdmap.service, está incluído no pacote ceph-common para essa finalidade.

O script aplica um único argumento, que pode ser map ou unmap. Em qualquer um dos casos, o script analisa um arquivo de configuração. Ele assume como padrão /etc/ceph/rbdmap, mas pode ser anulado por meio de uma variável de ambiente RBDMAPFILE. Cada linha do arquivo de configuração corresponde a uma imagem RBD que será mapeada ou que terá o mapeamento anulado.

O arquivo de configuração tem o seguinte formato:

image_specification rbd_options

image_specification

Caminho para uma imagem em um pool. Especifique como nome_do_pool/nome_da_imagem.

rbd_options

Uma lista opcional de parâmetros a serem passados para o comando rbd device map de base. Esses parâmetros e seus valores devem ser especificados como uma string separada por vírgula. Por exemplo:

PARAM1=VAL1,PARAM2=VAL2,...

O exemplo faz com que o script rbdmap execute o seguinte comando:

cephuser@adm > rbd device map POOL_NAME/IMAGE_NAME --PARAM1 VAL1 --PARAM2 VAL2

No exemplo a seguir, você pode ver como especificar um nome de usuário e um chaveiro com um segredo correspondente:

cephuser@adm > rbdmap device map mypool/myimage id=rbd_user,keyring=/etc/ceph/ceph.client.rbd.keyring

Quando executado como rbdmap map, o script analisa o arquivo de configuração e, para cada imagem RBD especificada, ele tenta primeiro mapear a imagem (usando o comando rbd device map) e, na sequência, montar a imagem.

Quando executado como rbdmap unmap, as imagens listadas no arquivo de configuração serão desmontadas e o mapeamento delas será anulado.

rbdmap unmap-all tenta desmontar e, na sequência, anular o mapeamento de todas as imagens RBD mapeadas, independentemente de estarem listadas no arquivo de configuração.

Se bem-sucedida, a operação rbd device map mapeia a imagem para um dispositivo /dev/rbdX e, nesse ponto, uma regra udev é acionada para criar um link simbólico do nome do dispositivo amigável /dev/rbd/nome_do_pool/nome_da_imagem apontando para o dispositivo real mapeado.

Para que a montagem e a desmontagem sejam bem-sucedidas, o nome “amigável” do dispositivo precisa ter uma entrada correspondente em /etc/fstab. Ao gravar entradas /etc/fstab em imagens RBD, especifique a opção de montagem “noauto” (ou “nofail”). Isso impede que o sistema Init tente montar o dispositivo com muita antecedência, antes mesmo de ele existir, pois rbdmap.service é normalmente acionado mais adiante na sequência de boot.

Para obter uma lista de opções rbd, consulte a página de manual do rbd (man 8 rbd).

Para ver exemplos de uso do rbdmap, consulte a página de manual do rbdmap (man 8 rbdmap).

20.2.5 Aumentando o tamanho dos dispositivos RBD #

Se você acha que o tamanho do dispositivo RBD não é mais suficiente, pode aumentá-lo com facilidade.

Aumente o tamanho da imagem RBD. Por exemplo, até 10 GB.

cephuser@adm > rbd resize --size 10000 mypool/myimage
 Resizing image: 100% complete...done.

Expanda o sistema de arquivos para preencher o novo tamanho do dispositivo.
```
root # xfs_growfs /mnt
 [...]
 data blocks changed from 2097152 to 2560000
```

20.3 Instantâneos #

Um instantâneo RBD é aquele de uma imagem do Dispositivo de Blocos RADOS. Com os instantâneos, você pode manter o histórico de estado da imagem. O Ceph também suporta camadas de instantâneo, o que permite clonar imagens de VM de forma rápida e fácil. O Ceph suporta instantâneos de dispositivo de blocos usando o comando rbd e muitas interfaces de nível mais alto, incluindo QEMU, libvirt, OpenStack e CloudStack.

Nota

Pare as operações de entrada e saída e descarregue todas as gravações pendentes antes de criar o instantâneo de uma imagem. Se a imagem tiver um sistema de arquivos, o estado dele deverá ser consistente no momento da criação do instantâneo.

20.3.1 Habilitando e configurando o `cephx` #

Quando o cephx está habilitado, você deve especificar um nome de usuário ou ID e um caminho para o chaveiro que contém a chave correspondente para o usuário. Consulte o Capítulo 30, Autenticação com cephx para obter mais detalhes. É possível também adicionar a variável de ambiente CEPH_ARGS para evitar uma nova entrada dos parâmetros a seguir.

cephuser@adm > rbd --id user-ID --keyring=/path/to/secret commands
cephuser@adm > rbd --name username --keyring=/path/to/secret commands

Por exemplo:

cephuser@adm > rbd --id admin --keyring=/etc/ceph/ceph.keyring commands
cephuser@adm > rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands

Dica

Adicione o usuário e o segredo à variável de ambiente CEPH_ARGS para que você não precise digitá-los toda vez.

20.3.2 Aspectos básicos do instantâneo #

Os procedimentos a seguir demonstram como criar, listar e remover instantâneos usando o comando rbd na linha de comando.

20.3.2.1 Criando instantâneos #

Para criar um instantâneo com rbd, especifique a opção snap create, o nome do pool e o nome da imagem.

cephuser@adm > rbd --pool pool-name snap create --snap snap-name image-name
cephuser@adm > rbd snap create pool-name/image-name@snap-name

Por exemplo:

cephuser@adm > rbd --pool rbd snap create --snap snapshot1 image1
cephuser@adm > rbd snap create rbd/image1@snapshot1

20.3.2.2 Listando instantâneos #

Para listar os instantâneos de uma imagem, especifique o nome do pool e o nome da imagem.

cephuser@adm > rbd --pool pool-name snap ls image-name
cephuser@adm > rbd snap ls pool-name/image-name

Por exemplo:

cephuser@adm > rbd --pool rbd snap ls image1
cephuser@adm > rbd snap ls rbd/image1

20.3.2.3 Revertendo instantâneos #

Para voltar a um instantâneo com rbd, especifique a opção snap rollback, o nome do pool, o nome da imagem e o nome do instantâneo.

cephuser@adm > rbd --pool pool-name snap rollback --snap snap-name image-name
cephuser@adm > rbd snap rollback pool-name/image-name@snap-name

Por exemplo:

cephuser@adm > rbd --pool pool1 snap rollback --snap snapshot1 image1
cephuser@adm > rbd snap rollback pool1/image1@snapshot1

Nota

Voltar uma imagem para um instantâneo significa sobregravar a versão atual da imagem com os dados de um instantâneo. O tempo necessário para executar um rollback aumenta de acordo com o tamanho da imagem. É mais rápido clonar de um instantâneo do que voltar uma imagem para um instantâneo, e é o método preferencial para reverter a um estado preexistente.

20.3.2.4 Apagando um instantâneo #

Para apagar um instantâneo com rbd, especifique a opção snap rm, o nome do pool, o nome da imagem e o nome de usuário.

cephuser@adm > rbd --pool pool-name snap rm --snap snap-name image-name
cephuser@adm > rbd snap rm pool-name/image-name@snap-name

Por exemplo:

cephuser@adm > rbd --pool pool1 snap rm --snap snapshot1 image1
cephuser@adm > rbd snap rm pool1/image1@snapshot1

Nota

Os Ceph OSDs apagam dados de forma assíncrona, portanto, apagar um instantâneo não libera o espaço em disco imediatamente.

20.3.2.5 Purgando instantâneos #

Para apagar todos os instantâneos de uma imagem com rbd, especifique a opção snap purge e o nome da imagem.

cephuser@adm > rbd --pool pool-name snap purge image-name
cephuser@adm > rbd snap purge pool-name/image-name

Por exemplo:

cephuser@adm > rbd --pool pool1 snap purge image1
cephuser@adm > rbd snap purge pool1/image1

20.3.3 Camadas de instantâneo #

O Ceph permite criar vários clones de cópia em gravação (COW, Copy-On-Write) de um instantâneo de dispositivo de blocos. As camadas de instantâneo permitem que os clientes de dispositivo de blocos do Ceph criem imagens muito rapidamente. Por exemplo, você pode criar uma imagem de dispositivo de blocos com uma VM Linux gravada nela e, em seguida, capturar um instantâneo da imagem, proteger o instantâneo e criar quantos clones de cópia em gravação desejar. Um instantâneo é apenas leitura, portanto, sua clonagem simplifica a semântica, possibilitando criar clones rapidamente.

Nota

Os termos “pai” e “filho” mencionados nos exemplos de linha de comando a seguir indicam um instantâneo de dispositivo de blocos do Ceph (pai) e a imagem correspondente clonada do instantâneo (filho).

Cada imagem clonada (filho) armazena uma referência à imagem pai, o que permite que a imagem clonada abra o instantâneo pai e o leia.

Um clone COW de um instantâneo funciona exatamente como qualquer outra imagem de dispositivo de blocos do Ceph. Você pode ler, gravar, clonar e redimensionar imagens clonadas. Não há nenhuma restrição especial em relação às imagens clonadas. No entanto, o clone de cópia em gravação de um instantâneo refere-se ao instantâneo. Sendo assim, você deve proteger o instantâneo antes de cloná-lo.

Nota: --image-format 1 não suportado

Você não pode criar instantâneos de imagens criadas com a opção rbd create --image-format 1 descontinuada. O Ceph suporta apenas a clonagem de imagens no formato 2 padrão.

20.3.3.1 Introdução às camadas #

As camadas de dispositivo de blocos do Ceph são um processo simples. Você deve ter uma imagem. Você deve criar um instantâneo da imagem. Você deve proteger o instantâneo. Após executar essas etapas, você poderá iniciar a clonagem do instantâneo.

A imagem clonada tem uma referência ao instantâneo pai e inclui os IDs do pool, da imagem e do instantâneo. A inclusão do ID do pool significa que você pode clonar instantâneos de um pool para imagens em outro pool.

Gabarito de Imagem: Um caso de uso comum para camadas de dispositivo de blocos é criar uma imagem master e um instantâneo que serve como gabarito para os clones. Por exemplo, um usuário pode criar uma imagem para uma distribuição Linux (por exemplo, SUSE Linux Enterprise Server) e criar um instantâneo para ela. Periodicamente, o usuário pode atualizar a imagem e criar um novo instantâneo (por exemplo, zypper ref && zypper patch seguido por rbd snap create). Durante a maturação da imagem, o usuário pode clonar qualquer um dos instantâneos.
Gabarito Estendido: Um caso de uso mais avançado inclui estender a imagem de um gabarito que fornece mais informações do que uma imagem de base. Por exemplo, um usuário pode clonar uma imagem (um gabarito de VM) e instalar outro software (por exemplo, um banco de dados, um sistema de gerenciamento de conteúdo ou um sistema de análise) e, em seguida, capturar um instantâneo da imagem estendida que, por si só, pode ser atualizada da mesma forma que a imagem de base.
Pool de Gabarito: Uma maneira de usar as camadas de dispositivo de blocos é criar um pool que contém imagens master que atuam como gabaritos e instantâneos desses gabaritos. Em seguida, você pode estender os privilégios apenas leitura aos usuários para que eles possam clonar os instantâneos sem a capacidade de gravação ou execução no pool.
Migração/Recuperação de Imagens: Uma maneira de usar as camadas de dispositivo de blocos é migrar ou recuperar os dados de um pool para outro.

20.3.3.2 Protegendo um instantâneo #

Os clones acessam os instantâneos pai. Todos os clones serão destruídos se um usuário apagar o instantâneo pai por engano. Para evitar a perda de dados, você precisa proteger o instantâneo antes de cloná-lo.

cephuser@adm > rbd --pool pool-name snap protect \
 --image image-name --snap snapshot-name
cephuser@adm > rbd snap protect pool-name/image-name@snapshot-name

Por exemplo:

cephuser@adm > rbd --pool pool1 snap protect --image image1 --snap snapshot1
cephuser@adm > rbd snap protect pool1/image1@snapshot1

Nota

Você não pode apagar um instantâneo protegido.

20.3.3.3 Clonando um instantâneo #

Para clonar um instantâneo, você precisa especificar o pool pai, a imagem, o instantâneo, o pool filho e o nome da imagem. Você precisa proteger o instantâneo antes de cloná-lo.

cephuser@adm > rbd clone --pool pool-name --image parent-image \
 --snap snap-name --dest-pool pool-name \
 --dest child-image
cephuser@adm > rbd clone pool-name/parent-image@snap-name \
pool-name/child-image-name

Por exemplo:

cephuser@adm > rbd clone pool1/image1@snapshot1 pool1/image2

Nota

Você pode clonar um instantâneo de um pool para uma imagem em outro pool. Por exemplo, você pode manter as imagens e os instantâneos apenas leitura como gabaritos em um pool e os clones graváveis em outro pool.

20.3.3.4 Anulando a proteção de um instantâneo #

Antes de apagar um instantâneo, você deve anular a proteção dele. Além disso, você não pode apagar instantâneos com referências de clones. Você precisa nivelar cada clone de um instantâneo antes de apagar o instantâneo.

cephuser@adm > rbd --pool pool-name snap unprotect --image image-name \
 --snap snapshot-name
cephuser@adm > rbd snap unprotect pool-name/image-name@snapshot-name

Por exemplo:

cephuser@adm > rbd --pool pool1 snap unprotect --image image1 --snap snapshot1
cephuser@adm > rbd snap unprotect pool1/image1@snapshot1

20.3.3.5 Listando os filhos de um instantâneo #

Para listar os filhos de um instantâneo, execute o seguinte:

cephuser@adm > rbd --pool pool-name children --image image-name --snap snap-name
cephuser@adm > rbd children pool-name/image-name@snapshot-name

Por exemplo:

cephuser@adm > rbd --pool pool1 children --image image1 --snap snapshot1
cephuser@adm > rbd children pool1/image1@snapshot1

20.3.3.6 Nivelando uma imagem clonada #

As imagens clonadas mantêm uma referência ao instantâneo pai. Ao remover a referência do clone filho para o instantâneo pai, você “nivela” com eficiência a imagem copiando as informações do instantâneo para o clone. O tempo necessário para nivelar um clone aumenta de acordo com o tamanho do instantâneo. Para apagar um instantâneo, você deve primeiro nivelar as imagens filho.

cephuser@adm > rbd --pool pool-name flatten --image image-name
cephuser@adm > rbd flatten pool-name/image-name

Por exemplo:

cephuser@adm > rbd --pool pool1 flatten --image image1
cephuser@adm > rbd flatten pool1/image1

Nota

Como uma imagem nivelada contém todas as informações do instantâneo, ela ocupa mais espaço de armazenamento do que um clone em camadas.

20.4 Espelhos de imagens RBD #

É possível espelhar as imagens RBD de forma assíncrona entre dois clusters do Ceph. Esse recurso está disponível em dois modos:

Com base em diário: Esse modo usa o recurso de registro de imagens RBD em diário para garantir a replicação consistente com o ponto no tempo e a falha entre os clusters. Cada gravação na imagem RBD é registrada primeiro no diário associado antes de modificar a imagem real. O cluster remoto fará a leitura do diário e reproduzirá as atualizações em sua cópia local da imagem. Como cada gravação na imagem RBD resultará em duas gravações no cluster do Ceph, é esperado que as latências de gravação quase dobrem ao usar o recurso de registro de imagens RBD em diário.
Com base em instantâneo: Esse modo usa instantâneos de espelho de imagens RBD programados periodicamente ou criados manualmente para replicar imagens RBD consistentes com a falha entre os clusters. O cluster remoto determinará quaisquer atualizações de dados ou metadados entre dois instantâneos de espelho e copiará os deltas para sua cópia local da imagem. Com a ajuda do recurso de imagem RBD fast-diff, os blocos de dados atualizados podem ser rapidamente calculados sem a necessidade de explorar a imagem RBD completa. Como esse modo não é consistente com o ponto no tempo, o delta de instantâneo completo precisará ser sincronizado antes do uso durante um cenário de failover. Quaisquer deltas de instantâneo parcialmente aplicados voltarão ao último instantâneo totalmente sincronizado antes do uso.

O espelhamento é configurado por pool nos clusters de peer. Ele pode ser configurado em um subconjunto específico de imagens no pool ou configurado para espelhar automaticamente todas as imagens em um pool ao usar apenas o espelhamento com base em diário. O espelhamento é configurado usando o comando rbd. O daemon rbd-mirror é responsável por capturar as atualizações da imagem do cluster de peer remoto e aplicá-las à imagem no cluster local.

Dependendo das necessidades de replicação desejadas, o espelhamento de RBD pode ser configurado para replicação unidirecional ou bidirecional:

Replicação unidirecional: Quando os dados são espelhados apenas de um cluster principal para um cluster secundário, o daemon rbd-mirror é executado somente no cluster secundário.
Replicação bidirecional: Quando os dados são espelhados de imagens principais em um cluster para imagens não principais em outro cluster (e vice-versa), o daemon rbd-mirror é executado nos dois clusters.

Importante

Cada instância do daemon rbd-mirror precisa ser capaz de se conectar aos clusters do Ceph local e remoto simultaneamente. Por exemplo, todos os hosts de monitor e OSD. Além disso, a rede precisa ter largura de banda suficiente entre os dois data centers para processar a carga de trabalho de espelhamento.

20.4.1 Configuração do pool #

Os procedimentos a seguir demonstram como executar as tarefas administrativas básicas para configurar o espelhamento usando o comando rbd. O espelhamento é configurado por pool nos clusters do Ceph.

Você precisa executar as etapas de configuração do pool em ambos os clusters peer. Estes procedimentos consideram a existência de dois clusters, chamados de local e remoto, acessíveis de um único host, por motivos de clareza.

Consulte a página de manual do rbd (man 8 rbd) para obter mais detalhes sobre como se conectar a diferentes clusters do Ceph.

Dica: Vários clusters

O nome do cluster nos exemplos a seguir corresponde a um arquivo de configuração do Ceph com o mesmo nome /etc/ceph/remote.conf e ao arquivo de chaveiro do Ceph com o mesmo nome /etc/ceph/remote.client.admin.keyring.

20.4.1.1 Permitir o espelhamento em um pool #

Para habilitar o espelhamento em um pool, especifique o subcomando mirror pool enable, o nome do pool e o modo de espelhamento. O modo de espelhamento pode ser pool ou image:

pool: Todas as imagens no pool com o recurso de registro em diário habilitado são espelhadas.
image: O espelhamento precisa ser habilitado explicitamente em cada imagem. Consulte a Seção 20.4.2.1, “Habilitando o espelhamento de imagens” para obter mais informações.

Por exemplo:

cephuser@adm > rbd --cluster local mirror pool enable POOL_NAME pool
cephuser@adm > rbd --cluster remote mirror pool enable POOL_NAME pool

20.4.1.2 Desabilitar o espelhamento #

Para desabilitar o espelhamento em um pool, especifique o subcomando mirror pool disable e o nome do pool. Quando o espelhamento é desabilitado dessa maneira em um pool, ele também é desabilitado em todas as imagens (no pool) para as quais ele foi explicitamente habilitado.

cephuser@adm > rbd --cluster local mirror pool disable POOL_NAME
cephuser@adm > rbd --cluster remote mirror pool disable POOL_NAME

20.4.1.3 Inicializando peers #

Para que o daemon rbd-mirror descubra seu cluster de peer, o peer precisa ser registrado no pool, e uma conta do usuário precisa ser criada. Esse processo pode ser automatizado com o rbd e os comandos mirror pool peer bootstrap create e mirror pool peer bootstrap import.

Para criar manualmente um novo token de boot com o rbd, especifique o comando mirror pool peer bootstrap create, o nome de um pool, junto com o nome amigável de um site, para descrever o cluster local:

cephuser@local > rbd mirror pool peer bootstrap create \
 [--site-name LOCAL_SITE_NAME] POOL_NAME

A saída do mirror pool peer bootstrap create será um token que deve ser inserido no comando mirror pool peer bootstrap import. Por exemplo, no cluster local:

cephuser@local > rbd --cluster local mirror pool peer bootstrap create --site-name local image-pool
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW \
1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1v \
bl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==

Para importar manualmente o token de boot criado por outro cluster com o comando rbd, use a seguinte sintaxe:

rbd mirror pool peer bootstrap import \
 [--site-name LOCAL_SITE_NAME] \
 [--direction DIRECTION \
 POOL_NAME TOKEN_PATH

Onde:

LOCAL_SITE_NAME: O nome amigável opcional de um site para descrever o cluster local.
DIRECTION: Uma direção de espelhamento. Assume rx-tx como padrão para espelhamento bidirecional, mas também pode ser definido como rx-only para espelhamento unidirecional.
POOL_NAME: O nome do pool.
TOKEN_PATH: O caminho de arquivo para o token criado (ou - para lê-lo da entrada padrão).

Por exemplo, no cluster remoto:

cephuser@remote > cat <<EOF > token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW \
1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1v \
bl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOF

cephuser@adm > rbd --cluster remote mirror pool peer bootstrap import \
 --site-name remote image-pool token

20.4.1.4 Adicionando um peer do cluster manualmente #

Como alternativa à inicialização de peers, conforme descrito na Seção 20.4.1.3, “Inicializando peers”, você pode especificar os peers manualmente. O daemon remoto rbd-mirrorprecisará de acesso ao cluster local para executar o espelhamento. Crie um novo usuário do Ceph local que o daemon rbd-mirror remoto usará, por exemplo rbd-mirror-peer:

cephuser@adm > ceph auth get-or-create client.rbd-mirror-peer \
 mon 'profile rbd' osd 'profile rbd'

Use a seguinte sintaxe para adicionar um cluster de peer de espelhamento do Ceph com o comando rbd:

rbd mirror pool peer add POOL_NAME CLIENT_NAME@CLUSTER_NAME

Por exemplo:

cephuser@adm > rbd --cluster site-a mirror pool peer add image-pool client.rbd-mirror-peer@site-b
cephuser@adm > rbd --cluster site-b mirror pool peer add image-pool client.rbd-mirror-peer@site-a

Por padrão, o daemon rbd-mirror precisa ter acesso ao arquivo de configuração do Ceph localizado em /etc/ceph/.CLUSTER_NAME.conf. Ele inclui os endereços IP dos MONs do cluster de peer e um chaveiro para um cliente denominado CLIENT_NAME, localizado nos caminhos padrão ou personalizado de pesquisa de chaveiro, por exemplo /etc/ceph/CLUSTER_NAME.CLIENT_NAME.keyring.

Como alternativa, é possível gravar o MON do cluster de peer e/ou a chave do cliente com segurança no armazenamento de chave de configuração local do Ceph. Para especificar os atributos de conexão do cluster de peer ao adicionar um peer de espelhamento, use as opções --remote-mon-host e --remote-key-file. Por exemplo:

cephuser@adm > rbd --cluster site-a mirror pool peer add image-pool \
 client.rbd-mirror-peer@site-b --remote-mon-host 192.168.1.1,192.168.1.2 \
 --remote-key-file /PATH/TO/KEY_FILE
cephuser@adm > rbd --cluster site-a mirror pool info image-pool --all
Mode: pool
Peers:
  UUID        NAME   CLIENT                 MON_HOST                KEY
  587b08db... site-b client.rbd-mirror-peer 192.168.1.1,192.168.1.2 AQAeuZdb...

20.4.1.5 Remover o peer de cluster #

Para remover um cluster peer de espelhamento, especifique o subcomando mirror pool peer remove, o nome do pool e o UUID do peer (disponível no comando rbd mirror pool info):

cephuser@adm > rbd --cluster local mirror pool peer remove POOL_NAME \
 55672766-c02b-4729-8567-f13a66893445
cephuser@adm > rbd --cluster remote mirror pool peer remove POOL_NAME \
 60c0e299-b38f-4234-91f6-eed0a367be08

20.4.1.6 Pools de dados #

Ao criar imagens no cluster de destino, o rbd-mirror seleciona um pool de dados da seguinte maneira:

Se o cluster de destino tiver um pool de dados padrão configurado (com a opção de configuração rbd_default_data_pool), ele será usado.
Do contrário, se a imagem de origem usar um pool de dados separado, e existir um pool com o mesmo nome no cluster de destino, esse pool será usado.
Se nenhuma das opções acima for verdadeira, nenhum pool de dados será definido.

20.4.2 Configuração de imagens RBD #

Diferentemente da configuração do pool, a configuração da imagem precisa apenas ser executada em um único cluster peer de espelhamento do Ceph.

As imagens RBD espelhadas são designadas como principais ou não principais. Essa é uma propriedade da imagem, e não do pool. Não é possível modificar as imagens designadas como não principais.

As imagens são automaticamente promovidas a principais quando o espelhamento é habilitado primeiro em uma imagem (seja implicitamente, se o modo de espelhamento do pool for “pool” e a imagem tiver o recurso de registro de imagens em diário habilitado, ou explicitamente (consulte a Seção 20.4.2.1, “Habilitando o espelhamento de imagens”) pelo comando rbd).

20.4.2.1 Habilitando o espelhamento de imagens #

Se o espelhamento for configurado no modo image, será necessário habilitar explicitamente o espelhamento para cada imagem no pool. Para habilitar o espelhamento de uma imagem específica com o rbd, especifique o subcomando mirror image enable junto com o nome do pool e da imagem:

cephuser@adm > rbd --cluster local mirror image enable \
 POOL_NAME/IMAGE_NAME

O modo de espelhamento da imagem pode ser journal ou snapshot:

journal (padrão): Quando configurado no modo journal, o espelhamento usará o recurso de registro de imagens RBD em diário para replicar o conteúdo da imagem. Se o recurso de registro de imagens RBD em diário ainda não estiver habilitado na imagem, ele será habilitado automaticamente.
snapshot: Quando configurado no modo snapshot, o espelhamento usará o instantâneo de espelho de imagens RBD para replicar o conteúdo da imagem. Uma vez habilitado, um instantâneo de espelho inicial será criado automaticamente. É possível criar mais instantâneos de espelho de imagens RBD com o comando rbd.

Por exemplo:

cephuser@adm > rbd --cluster local mirror image enable image-pool/image-1 snapshot
cephuser@adm > rbd --cluster local mirror image enable image-pool/image-2 journal

20.4.2.2 Habilitando o recurso de registro de imagens em diário #

O espelhamento de RBD usa o recurso de registro de RBD em diário para garantir que a imagem replicada permaneça sempre consistente com a falha. Ao usar o modo de espelhamento de imagem, o recurso de registro em diário será habilitado automaticamente se o espelhamento estiver habilitado na imagem. Ao usar o modo de espelhamento de pool, antes que uma imagem possa ser espelhada para um cluster de peer, o recurso de registro de imagens RBD em diário deve ser habilitado. O recurso pode ser habilitado no momento da criação da imagem inserindo a opção --image-feature exclusive-lock,journaling no comando rbd.

Se preferir, o recurso de registro em diário pode ser habilitado dinamicamente nas imagens RBD preexistentes. Para habilitar o registro em diário, especifique o subcomando feature enable, o nome do pool e da imagem e o nome do recurso:

cephuser@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME exclusive-lock
cephuser@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME journaling

Nota: Dependência da opção

O recurso de registro em diário depende do recurso de bloqueio exclusivo. Se o recurso de bloqueio exclusivo ainda não estiver habilitado, você precisará habilitá-lo antes de habilitar o recurso de registro em diário.

Dica

É possível habilitar o registro em diário em todas as imagens novas por padrão, adicionando rbd default features = layering,exclusive-lock,object-map,deep-flatten,journaling ao arquivo de configuração do Ceph.

20.4.2.3 Criando instantâneos de espelho de imagem #

Ao usar o espelhamento com base em instantâneo, os instantâneos de espelho precisarão ser criados sempre que você desejar espelhar o conteúdo modificado da imagem RBD. Para criar um instantâneo de espelho manualmente com o rbd, especifique o comando mirror image snapshot, junto com o nome do pool e da imagem:

cephuser@adm > rbd mirror image snapshot POOL_NAME/IMAGE_NAME

Por exemplo:

cephuser@adm > rbd --cluster local mirror image snapshot image-pool/image-1

Por padrão, apenas três instantâneos de espelho serão criados por imagem. O instantâneo de espelho mais recente será removido automaticamente se o limite for atingido. O limite poderá ser anulado por meio da opção de configuração rbd_mirroring_max_mirroring_snapshots, se necessário. Além disso, os instantâneos de espelho são automaticamente apagados quando a imagem é removida ou quando o espelhamento é desabilitado.

Os instantâneos de espelho também poderão ser criados automaticamente de maneira periódica, se as programações de instantâneos de espelho forem definidas. O instantâneo de espelho pode ser programado nos níveis global, por pool ou por imagem. Várias programações de instantâneos de espelho podem ser definidas em qualquer nível, mas apenas as programações de instantâneo mais específicas correspondentes a uma imagem espelhada individual serão executadas.

Para criar uma programação de instantâneo de espelho com o rbd, especifique o comando mirror snapshot schedule add, junto com o nome de um pool ou imagem opcional, o intervalo e o horário de início opcional.

O intervalo pode ser especificado em dias, horas ou minutos usando os sufixos d, h ou m, respectivamente. O horário de início opcional pode ser especificado usando o formato de horário ISO 8601. Por exemplo:

cephuser@adm > rbd --cluster local mirror snapshot schedule add --pool image-pool 24h 14:00:00-05:00
cephuser@adm > rbd --cluster local mirror snapshot schedule add --pool image-pool --image image1 6h

Para remover uma programação de instantâneo de espelho com o rbd, especifique o comando mirror snapshot schedule remove com as opções correspondentes ao comando de adição da programação.

Para listar todas as programações de instantâneo para um nível específico (global, pool ou imagem) com o rbd, especifique o comando mirror snapshot schedule ls, junto com o nome de um pool ou imagem opcional. Além disso, a opção --recursive pode ser usada para listar todas as programações no nível especificado e abaixo dele. Por exemplo:

cephuser@adm > rbd --cluster local mirror schedule ls --pool image-pool --recursive
POOL        NAMESPACE IMAGE  SCHEDULE
image-pool  -         -      every 1d starting at 14:00:00-05:00
image-pool            image1 every 6h

Para saber quando os próximos instantâneos serão criados para imagens RBD de espelhamento com base em instantâneo com o rbd, especifique o comando mirror snapshot schedule status, junto com o nome de um pool ou imagem opcional. Por exemplo:

cephuser@adm > rbd --cluster local mirror schedule status
SCHEDULE TIME       IMAGE
2020-02-26 18:00:00 image-pool/image1

20.4.2.4 Desabilitando o espelhamento de imagens #

Para desabilitar o espelhamento em determinada imagem, especifique o subcomando mirror image disable juntamente com o nome do pool e da imagem:

cephuser@adm > rbd --cluster local mirror image disable POOL_NAME/IMAGE_NAME

20.4.2.5 Promovendo e retrocedendo imagens #

Em um cenário de failover em que a designação principal precisa ser movida para a imagem no cluster peer, você precisa interromper o acesso à imagem principal, rebaixar a imagem principal atual, promover a nova imagem principal e continuar o acesso à imagem no cluster alternativo.

Nota: Promoção forçada

A promoção pode ser forçada usando a opção --force. A promoção forçada é necessária quando o rebaixamento não pode ser propagado para o cluster peer (por exemplo, em caso de falha do cluster ou interrupção da comunicação). Isso resultará em um cenário de split-brain (dupla personalidade) entre os dois peers, e a imagem não será mais sincronizada até que um subcomando resync seja emitido.

Para rebaixar determinada imagem para não principal, especifique o subcomando mirror image demote juntamente com o nome do pool e da imagem:

cephuser@adm > rbd --cluster local mirror image demote POOL_NAME/IMAGE_NAME

Para rebaixar todas as imagens principais em um pool para não principais, especifique o subcomando mirror pool demote juntamente com o nome do pool:

cephuser@adm > rbd --cluster local mirror pool demote POOL_NAME

Para promover determinada imagem para principal, especifique o subcomando mirror image promote juntamente com o nome do pool e da imagem:

cephuser@adm > rbd --cluster remote mirror image promote POOL_NAME/IMAGE_NAME

Para promover todas as imagens não principais em um pool para principais, especifique o subcomando mirror pool promote juntamente com o nome do pool:

cephuser@adm > rbd --cluster local mirror pool promote POOL_NAME

Dica: Dividir a carga de E/S

Como o status principal ou não principal refere-se a cada imagem, é possível ter dois clusters que dividem a carga de E/S e o failover ou failback por fase.

20.4.2.6 Forçando a ressincronização da imagem #

Se um evento de split-brain for detectado pelo daemon rbd-mirror, ele não tentará espelhar a imagem afetada até o problema ser corrigido. Para continuar o espelhamento de uma imagem, primeiro rebaixe a imagem que foi identificada como desatualizada e, em seguida, solicite uma ressincronização com a imagem principal. Para solicitar a ressincronização de uma imagem, especifique o subcomando mirror image resync juntamente com o nome do pool e da imagem:

cephuser@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME

20.4.3 Verificando o status do espelho #

O status de replicação do cluster peer é armazenado para cada imagem principal espelhada. Esse status pode ser recuperado usando os subcomandos mirror image status e mirror pool status:

Para solicitar o status da imagem de espelho, especifique o subcomando mirror image status juntamente com o nome do pool e da imagem:

cephuser@adm > rbd mirror image status POOL_NAME/IMAGE_NAME

Para solicitar o status do resumo do pool de espelhos, especifique o subcomando mirror pool status juntamente com o nome do pool:

cephuser@adm > rbd mirror pool status POOL_NAME

Dica:

A adição da opção --verbose ao subcomando mirror pool status resultará também nos detalhes de status para cada imagem de espelhamento no pool.

20.5 Configurações de cache #

A implementação do espaço de usuário do dispositivo de blocos do Ceph (librbd) não pode se beneficiar do cache de página do Linux. Portanto, ela inclui seu próprio cache na memória. O cache RBD tem comportamento semelhante ao cache de disco rígido. Quando o OS envia uma solicitação de barreira ou descarga, todos os dados "modificados" são gravados nos OSDs. Isso significa que o uso do cache de write-back é tão seguro quanto o uso de um disco rígido físico de bom funcionamento com uma VM que envia descarregamentos apropriadamente. O cache usa um algoritmo menos utilizado recentemente (LRU, Least Recently Used) e, no modo write-back, ele pode fundir solicitações adjacentes para um melhor throughput.

O Ceph suporta cache de write-back para RBD. Para habilitá-lo, execute

cephuser@adm > ceph config set client rbd_cache true

Por padrão, o librbd não executa armazenamento em cache. As gravações e leituras seguem diretamente para o cluster de armazenamento, e as gravações são retornadas apenas quando os dados estão no disco em todas as réplicas. Com o cache habilitado, as gravações são retornadas imediatamente, a menos que haja mais bytes descarregados do que o que foi definido na opção rbd cache max dirty. Nesse caso, a gravação aciona write-back e blocos até que sejam descarregados bytes suficientes.

O Ceph suporta cache de write-through para RBD. Você pode definir o tamanho do cache, destinos e limites para alternar do cache de write-back para o cache de write-through. Para habilitar o modo write-through, execute

cephuser@adm > ceph config set client rbd_cache_max_dirty 0

Isso significa que as gravações são retornadas apenas quando os dados estão no disco em todas as réplicas, mas as leituras podem vir do cache. O cache está na memória do cliente, e cada imagem RBD tem seu próprio cache. Como o cache é local ao cliente, não fará sentido se houver outras pessoas acessando a imagem. A execução do GFS ou OCFS no RBD não funcionará com o cache habilitado.

Os parâmetros a seguir afetam o comportamento dos Dispositivos de Blocos RADOS. Para defini-los, use a categoria client:

cephuser@adm > ceph config set client PARAMETER VALUE

rbd cache: Habilitar o cache para Dispositivo de blocos RADOS (RBD, RADOS Block Device). O padrão é “true”.
rbd cache size: O tamanho do cache RBD em bytes. O padrão é 32 MB.
rbd cache max dirty: O limite de "modificação" em bytes em que o cache aciona o write-back. rbd cache max dirty precisa ser inferior a rbd cache size. Se definido como 0, usa o cache de write-through. O padrão é 24 MB.
rbd cache target dirty: O “destino de modificação” antes de o cache começar a gravar dados no armazenamento de dados. Não bloqueia as gravações para o cache. O padrão é 16 MB.
rbd cache max dirty age: Por quantos segundos os dados modificados permanecem no cache antes que o write-back seja iniciado. O padrão é 1.
rbd cache writethrough until flush: Comece no modo write-through e alterne para write-back depois de receber a primeira solicitação de descarregamento. A habilitação dessa configuração é conservadora, porém segura, caso as máquinas virtuais executadas no rbd sejam muito antigas para enviar descarregamentos (por exemplo, o driver virtio no Linux antes do kernel 2.6.32). O padrão é “true”.

20.6 Configurações de QdS #

Em geral, a Qualidade do Serviço (QdS) refere-se aos métodos de priorização de tráfego e reserva de recursos. Ela é importante principalmente para o transporte de tráfego com requisitos especiais.

Importante: não suportadas pelo iSCSI

As seguintes configurações de QdS são usadas apenas pela implementação RBD librbd do espaço de usuário, e não são usadas pela implementação kRBD. Como o iSCSI usa o kRBD, ele não usa as configurações de QdS. No entanto, para o iSCSI, você pode configurar a QdS na camada do dispositivo de blocos do kernel usando os recursos padrão do kernel.

rbd qos iops limit: O limite desejado das operações de E/S por segundo. O padrão é 0 (sem limite).
rbd qos bps limit: O limite desejado de bytes de E/S por segundo. O padrão é 0 (sem limite).
rbd qos read iops limit: O limite desejado das operações de leitura por segundo. O padrão é 0 (sem limite).
rbd qos write iops limit: O limite desejado das operações de gravação por segundo. O padrão é 0 (sem limite).
rbd qos read bps limit: O limite desejado de bytes de leitura por segundo. O padrão é 0 (sem limite).
rbd qos write bps limit: O limite desejado de bytes de gravação por segundo. O padrão é 0 (sem limite).
rbd qos iops burst: O limite de burst desejado das operações de E/S. O padrão é 0 (sem limite).
rbd qos bps burst: O limite de burst desejado de bytes de E/S. O padrão é 0 (sem limite).
rbd qos read iops burst: O limite de burst desejado das operações de leitura. O padrão é 0 (sem limite).
rbd qos write iops burst: O limite de burst desejado das operações de gravação. O padrão é 0 (sem limite).
rbd qos read bps burst: O limite de burst desejado de bytes de leitura. O padrão é 0 (sem limite).
rbd qos write bps burst: O limite de burst desejado de bytes de gravação. O padrão é 0 (sem limite).
rbd qos schedule tick min: O tique de horário mínimo (em milissegundos) para QdS. O padrão é 50.

20.7 Configurações de leitura com ajuda #

O Dispositivo de Blocos RADOS suporta leitura com ajuda/pré-busca para otimizar pequenas leituras sequenciais. Isso costuma ser processado pelo OS convidado no caso de uma máquina virtual, mas os carregadores de boot talvez não emitam leituras suficientes. A leitura com ajuda será automaticamente desabilitada se o cache for desabilitado.

Importante: não suportadas pelo iSCSI

As seguintes configurações de leitura com ajuda são usadas apenas pela implementação RBD librbd do espaço de usuário, e não são usadas pela implementação kRBD. Como o iSCSI usa o kRBD, ele não usa as configurações de leitura com ajuda. No entanto, para o iSCSI, você pode configurar a leitura com ajuda na camada do dispositivo de blocos do kernel usando os recursos padrão do kernel.

rbd readahead trigger requests: Número de solicitações de leitura sequenciais necessárias para acionar a leitura com ajuda. O padrão é 10.
rbd readahead max bytes: Tamanho máximo de uma solicitação de leitura com ajuda. Se definido como 0, a leitura com ajuda será desabilitada. O padrão é 512 KB.
rbd readahead disable after bytes: Após a leitura dessa quantidade de bytes de uma imagem RBD, a leitura com ajuda será desabilitada para essa imagem até ser fechada. Isso permite que o OS convidado controle a leitura com ajuda quando é inicializado. Se definido como 0, a leitura com ajuda permanecerá habilitada. O padrão é 50 MB.

20.8 Recursos avançados #

O Dispositivo de Blocos RADOS suporta recursos avançados que melhoram a funcionalidade das imagens RBD. Você pode especificar os recursos na linha de comando ao criar uma imagem RBD ou no arquivo de configuração do Ceph usando a opção rbd_default_features.

Você pode especificar os valores da opção rbd_default_features de duas maneiras:

Como a soma dos valores internos dos recursos. Cada recurso tem seu próprio valor interno. Por exemplo, “layering” tem 1 e “fast-diff” tem 16. Portanto, para ativar esses dois recursos por padrão, inclua o seguinte:
```
rbd_default_features = 17
```
Como uma lista de recursos separada por vírgula. O exemplo anterior terá a seguinte aparência:
```
rbd_default_features = layering,fast-diff
```

Nota: Recursos não suportados pelo iSCSI

As imagens RBD com os seguintes recursos não serão suportadas pelo iSCSI: deep-flatten, object-map, journaling, fast-diff, striping

Veja a seguir uma lista de recursos RBD avançados:

layering

As camadas (layering) permitem usar a clonagem.

O valor interno é 1, o padrão é “yes”.

striping

A distribuição difunde os dados por vários objetos e ajuda com paralelismo para cargas de trabalho de leitura/gravação sequenciais. Ele evita gargalos de nó único para Dispositivo de Blocos RADOS grandes ou ocupados.

O valor interno é 2, o padrão é “yes”.

exclusive-lock

Quando habilitado, ele requer que um cliente crie um bloqueio em um objeto antes de fazer uma gravação. Habilite o bloqueio exclusivo apenas quando um único cliente está acessando uma imagem ao mesmo tempo. O valor interno é 4. O padrão é “yes”.

object-map

O suporte ao mapa de objetos depende do suporte ao bloqueio exclusivo. Os dispositivos de blocos são aprovisionados dinamicamente, o que significa que eles apenas armazenam dados que realmente existem. O suporte ao mapa de objetos ajuda a monitorar os objetos que realmente existem (com dados armazenados em uma unidade). A habilitação do suporte ao mapa de objetos acelera as operações de E/S para clonagem, importação e exportação de uma imagem pouco preenchida, além da exclusão.

O valor interno é 8, o padrão é “yes”.

fast-diff

O suporte à comparação rápida (fast-diff) depende do suporte ao mapa de objetos e do suporte ao bloqueio exclusivo. Ele adiciona outra propriedade ao mapa de objetos, o que o torna muito mais rápido para gerar comparações entre instantâneos de uma imagem e o uso real dos dados de um instantâneo.

O valor interno é 16, o padrão é “yes”.

deep-flatten

O nivelamento profundo (deep-flatten) faz com que o rbd flatten (consulte a Seção 20.3.3.6, “Nivelando uma imagem clonada”) funcione em todos os instantâneos de uma imagem, além da própria imagem. Sem ele, os instantâneos de uma imagem ainda dependerão do pai, portanto, você não poderá apagar a imagem pai até os instantâneos serem apagados. O deep-flatten torna um pai independente de seus clones, mesmo que eles tenham instantâneos.

O valor interno é 32, o padrão é “yes”.

journaling

O suporte ao registro em diário depende do suporte ao bloqueio exclusivo. O diário registra todas as modificações em uma imagem na ordem em que elas ocorrem. O espelhamento RBD (consulte a Seção 20.4, “Espelhos de imagens RBD”) usa o diário para replicar uma imagem consistente de falha para um cluster remoto.

O valor interno é 64, o padrão é “no”.

20.9 Mapeando o RBD por meio de clientes antigos do kernel #

Clientes antigos (por exemplo, SLE11 SP4) podem não conseguir mapear imagens RBD porque um cluster implantado com o SUSE Enterprise Storage 7 força alguns recursos (no nível tanto da imagem RBD quanto do RADOS) que esses clientes antigos não suportam. Quando isso acontece, os registros do OSD mostram mensagens semelhantes às seguintes:

2019-05-17 16:11:33.739133 7fcb83a2e700  0 -- 192.168.122.221:0/1006830 >> \
192.168.122.152:6789/0 pipe(0x65d4e0 sd=3 :57323 s=1 pgs=0 cs=0 l=1 c=0x65d770).connect \
protocol feature mismatch, my 2fffffffffff < peer 4010ff8ffacffff missing 401000000000000

Atenção: Mudança de tipos de compartimento de memória do Mapa CRUSH provoca rebalanceamento massivo

Se você pretende alternar os tipos de compartimento de memória do Mapa CRUSH entre “straw” e “straw2”, faça um planejamento para isso. Espere um impacto significativo na carga do cluster, porque a mudança do tipo de compartimento de memória provoca uma redistribuição massiva do cluster.

Desabilite quaisquer recursos da imagem RBD que não sejam suportados. Por exemplo:

cephuser@adm > rbd feature disable pool1/image1 object-map
cephuser@adm > rbd feature disable pool1/image1 exclusive-lock

Mude os tipos de compartimento de memória do Mapa CRUSH de “straw2” para “straw”:
1. Grave o Mapa CRUSH:
```
cephuser@adm > ceph osd getcrushmap -o crushmap.original
```
2. Descompile o Mapa CRUSH:
```
cephuser@adm > crushtool -d crushmap.original -o crushmap.txt
```
3. Edite o Mapa CRUSH e substitua “straw2” por “straw”.
4. Recompile o Mapa CRUSH:
```
cephuser@adm > crushtool -c crushmap.txt -o crushmap.new
```
5. Defina o novo Mapa CRUSH:
```
cephuser@adm > ceph osd setcrushmap -i crushmap.new
```

20.10 Habilitando dispositivos de blocos e Kubernetes #

Você pode usar o Ceph RBD com o Kubernetes 1.13 e versões mais recentes por meio do driver ceph-csi. Esse driver provisiona dinamicamente as imagens RBD para suportar os volumes do Kubernetes e mapeia essas imagens RBD como dispositivos de blocos (opcionalmente, montando um sistema de arquivos contido na imagem) em nós de trabalho que executam pods que fazem referência a um volume com suporte do RBD.

Para usar dispositivos de blocos do Ceph com o Kubernetes, você deve instalar e configurar o ceph-csi no seu ambiente do Kubernetes.

Importante

O ceph-csi usa os módulos do kernel RBD por padrão, que podem não suportar todos os tunables do Ceph CRUSH ou os recursos de imagem RBD.

Por padrão, os dispositivos de blocos do Ceph usam o pool RBD. Crie um pool para armazenamento de volume do Kubernetes. Verifique se o cluster do Ceph está em execução e crie o pool:
```
cephuser@adm > ceph osd pool create kubernetes
```
Use a ferramenta RBD para inicializar o pool:
```
cephuser@adm > rbd pool init kubernetes
```

Crie um novo usuário para o Kubernetes e o ceph-csi. Execute o seguinte e registre a chave gerada:

cephuser@adm > ceph auth get-or-create client.kubernetes mon 'profile rbd' osd 'profile rbd pool=kubernetes' mgr 'profile rbd pool=kubernetes'
[client.kubernetes]
    key = AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==

O ceph-csi requer um objeto ConfigMap armazenado no Kubernetes para definir os endereços do monitor do Ceph para o cluster do Ceph. Colete o FSID exclusivo do cluster do Ceph e os endereços do monitor:

cephuser@adm > ceph mon dump
<...>
fsid b9127830-b0cc-4e34-aa47-9d1a2e9949a8
<...>
0: [v2:192.168.1.1:3300/0,v1:192.168.1.1:6789/0] mon.a
1: [v2:192.168.1.2:3300/0,v1:192.168.1.2:6789/0] mon.b
2: [v2:192.168.1.3:3300/0,v1:192.168.1.3:6789/0] mon.c

Gere um arquivo csi-config-map.yaml semelhante ao exemplo abaixo, substituindo o FSID por clusterID e os endereços do monitor por monitors:

kubectl@adm > cat <<EOF > csi-config-map.yaml
---
apiVersion: v1
kind: ConfigMap
data:
  config.json: |-
    [
      {
        "clusterID": "b9127830-b0cc-4e34-aa47-9d1a2e9949a8",
        "monitors": [
          "192.168.1.1:6789",
          "192.168.1.2:6789",
          "192.168.1.3:6789"
        ]
      }
    ]
metadata:
  name: ceph-csi-config
EOF

Quando gerado, armazene o novo objeto ConfigMap no Kubernetes:
```
kubectl@adm > kubectl apply -f csi-config-map.yaml
```
O ceph-csi requer as credenciais do cephx para se comunicar com o cluster do Ceph. Gere um arquivo csi-rbd-secret.yaml semelhante ao exemplo abaixo, usando o ID de usuário do Kubernetes recém-criado e a chave do cephx:
```
kubectl@adm > cat <<EOF > csi-rbd-secret.yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: default
stringData:
  userID: kubernetes
  userKey: AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==
EOF
```
Quando gerado, armazene o novo objeto secreto no Kubernetes:
```
kubectl@adm > kubectl apply -f csi-rbd-secret.yaml
```
Crie os objetos do Kubernetes ServiceAccount e RBAC ClusterRole/ClusterRoleBinding necessários. Esses objetos não precisam ser necessariamente personalizados para seu ambiente do Kubernetes e, portanto, podem ser usados diretamente dos arquivos YAML de implantação do ceph-csi:
```
kubectl@adm > kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-provisioner-rbac.yaml
kubectl@adm > kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-nodeplugin-rbac.yaml
```

Crie o aprovisionador ceph-csi e os plug-ins de nó:

kubectl@adm > wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin-provisioner.yaml
kubectl@adm > kubectl apply -f csi-rbdplugin-provisioner.yaml
kubectl@adm > wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin.yaml
kubectl@adm > kubectl apply -f csi-rbdplugin.yaml

Importante

Por padrão, os arquivos YAML do aprovisionador e do plug-in de nó extrairão a versão de desenvolvimento do container ceph-csi. Os arquivos YAML devem ser atualizados para usar uma versão de lançamento.

20.10.1 Usando dispositivos de blocos do Ceph no Kubernetes #

A StorageClass do Kubernetes define uma classe de armazenamento. Vários objetos StorageClass podem ser criados para mapear para diferentes níveis e recursos de qualidade de serviço. Por exemplo, pools com base em NVMe em relação aos pools com base em HDD.

Para criar uma StorageClass do ceph-csi que mapeie para o pool do Kubernetes criado acima, o seguinte arquivo YAML pode ser usado, depois de garantir que a propriedade clusterID corresponda ao FSID do cluster do Ceph:

kubectl@adm > cat <<EOF > csi-rbd-sc.yaml
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: csi-rbd-sc
provisioner: rbd.csi.ceph.com
parameters:
   clusterID: b9127830-b0cc-4e34-aa47-9d1a2e9949a8
   pool: kubernetes
   csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
   csi.storage.k8s.io/provisioner-secret-namespace: default
   csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret
   csi.storage.k8s.io/node-stage-secret-namespace: default
reclaimPolicy: Delete
mountOptions:
   - discard
EOF
kubectl@adm > kubectl apply -f csi-rbd-sc.yaml

Um PersistentVolumeClaim é uma solicitação de recursos de armazenamento abstratos feita por um usuário. O PersistentVolumeClaim é associado a um recurso de pod para provisionar um PersistentVolume, que recebe suporte de uma imagem de bloco do Ceph. É possível incluir um volumeMode opcional para selecionar entre um sistema de arquivos montado (padrão) ou um volume bruto com base em dispositivo de blocos.

Usando o ceph-csi, a especificação de Filesystem para volumeMode pode suportar ambos os requerimentos ReadWriteOnce e ReadOnlyMany accessMode, e a especificação de Block para volumeMode pode suportar os requerimentos ReadWriteOnce, ReadWriteMany e ReadOnlyMany accessMode.

Por exemplo, para criar um PersistentVolumeClaim baseado em blocos que usa o ceph-csi-based StorageClass criado acima, o seguinte arquivo YAML pode ser usado para solicitar o armazenamento de blocos bruto de csi-rbd-sc StorageClass:

kubectl@adm > cat <<EOF > raw-block-pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: raw-block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc
EOF
kubectl@adm > kubectl apply -f raw-block-pvc.yaml

Veja a seguir uma demonstração de como vincular o PersistentVolumeClaim acima a um recurso de pod como um dispositivo de blocos bruto:

kubectl@adm > cat <<EOF > raw-block-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-with-raw-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: ["tail -f /dev/null"]
      volumeDevices:
        - name: data
          devicePath: /dev/xvda
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: raw-block-pvc
EOF
kubectl@adm > kubectl apply -f raw-block-pod.yaml

Para criar um PersistentVolumeClaim baseado em sistema de arquivos que usa o ceph-csi-based StorageClass criado acima, o seguinte arquivo YAML pode ser usado para solicitar um sistema de arquivos montado (com suporte de uma imagem RBD) de csi-rbd-sc StorageClass:

kubectl@adm > cat <<EOF > pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rbd-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc
EOF
kubectl@adm > kubectl apply -f pvc.yaml

Veja a seguir uma demonstração de como vincular o PersistentVolumeClaim acima a um recurso de pod como um sistema de arquivos montado:

kubectl@adm > cat <<EOF > pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: csi-rbd-demo-pod
spec:
  containers:
    - name: web-server
      image: nginx
      volumeMounts:
        - name: mypvc
          mountPath: /var/lib/www/html
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: rbd-pvc
        readOnly: false
EOF
kubectl@adm > kubectl apply -f pod.yaml

20 Dispositivo de Blocos RADOS #

20.1 Comandos do dispositivo de blocos #

20.1.1 Criando uma imagem de dispositivo de blocos em um pool replicado #

20.1.2 Criando uma imagem de dispositivo de blocos em um pool codificado para eliminação #

20.1.3 Listando imagens de dispositivo de blocos #

20.1.4 Recuperando informações da imagem #

20.1.5 Redimensionando uma imagem de dispositivo de blocos #

20.1.6 Removendo uma imagem de dispositivo de blocos #

20.2 Montando e desmontando #

20.2.1 Criando uma conta do usuário do Ceph #

20.2.2 Autenticação de usuário #

20.2.3 Preparando um Dispositivo de Blocos RADOS para uso #

20.2.4 rbdmap Mapear dispositivos RBD no momento da inicialização #

20.2.5 Aumentando o tamanho dos dispositivos RBD #

20.3 Instantâneos #

20.3.1 Habilitando e configurando o cephx #

20.3.2 Aspectos básicos do instantâneo #

20.3.2.1 Criando instantâneos #

20.3.2.2 Listando instantâneos #

20.3.2.3 Revertendo instantâneos #

20.3.2.4 Apagando um instantâneo #

20.3.2.5 Purgando instantâneos #

20.3.3 Camadas de instantâneo #

20.3.3.1 Introdução às camadas #

20.3.3.2 Protegendo um instantâneo #

20.3.3.3 Clonando um instantâneo #

20.3.3.4 Anulando a proteção de um instantâneo #

20.3.3.5 Listando os filhos de um instantâneo #

20.3.3.6 Nivelando uma imagem clonada #

20.4 Espelhos de imagens RBD #

20.4.1 Configuração do pool #

20.4.1.1 Permitir o espelhamento em um pool #

20.4.1.2 Desabilitar o espelhamento #

20.4.1.3 Inicializando peers #

20.4.1.4 Adicionando um peer do cluster manualmente #

20.4.1.5 Remover o peer de cluster #

20.4.1.6 Pools de dados #

20.4.2 Configuração de imagens RBD #

20.4.2.1 Habilitando o espelhamento de imagens #

20.4.2.2 Habilitando o recurso de registro de imagens em diário #

20.4.2.3 Criando instantâneos de espelho de imagem #

20.4.2.4 Desabilitando o espelhamento de imagens #

20.4.2.5 Promovendo e retrocedendo imagens #

20.4.2.6 Forçando a ressincronização da imagem #

20.4.3 Verificando o status do espelho #

20.5 Configurações de cache #

20.6 Configurações de QdS #

20.7 Configurações de leitura com ajuda #

20.8 Recursos avançados #

20.9 Mapeando o RBD por meio de clientes antigos do kernel #

20.10 Habilitando dispositivos de blocos e Kubernetes #

20.10.1 Usando dispositivos de blocos do Ceph no Kubernetes #

20.2.4 `rbdmap` Mapear dispositivos RBD no momento da inicialização #

20.3.1 Habilitando e configurando o `cephx` #