13 Tarefas operacionais #

Para identificar os dispositivos de disco usados e não usados em todos os nós do cluster, liste-os executando o seguinte comando:

cephuser@adm > ceph orch device ls
HOST       PATH      TYPE SIZE  DEVICE  AVAIL REJECT REASONS
ses-master /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vdb  hdd  8192M  387836 False locked, LVM detected, Insufficient space (<5GB) on vgs
ses-min2   /dev/vdc  hdd  8192M  450575 True

Para reutilizar um dispositivo de disco, você precisa apagá-lo (ou zap) primeiro:

ceph orch device zap HOST_NAME DISK_DEVICE

Por exemplo:

cephuser@adm > ceph orch device zap ses-min2 /dev/vdc

Nota

Se você já implantou os OSDs por meio de DriveGroups ou da opção --all-available-devices sem o flag unmanaged definido, o cephadm implantará esses OSDs automaticamente depois que você os apagar.

Os DriveGroups especificam os layouts dos OSDs no cluster do Ceph. Eles são definidos em um único arquivo YAML. Nesta seção, usaremos drive_groups.yml como exemplo.

Um administrador deve especificar manualmente um grupo de OSDs que estão interligados (OSDs híbridos implantados em uma combinação de HDDs e SDDs) ou compartilhar opções idênticas de implantação (por exemplo, mesmo armazenamento de objetos, mesma opção de criptografia, OSDs independentes). Para evitar a listagem explícita de dispositivos, os DriveGroups usam uma lista de itens de filtro que correspondem a poucos campos selecionados dos relatórios de inventário do ceph-volume. O cephadm fornecerá o código que converte esses DriveGroups em listas reais de dispositivos para inspeção pelo usuário.

O comando para aplicar a especificação de OSD ao cluster é:

cephuser@adm > ceph orch apply osd -i drive_groups.yml

Para obter uma visualização das ações e testar seu aplicativo, você pode usar a opção --dry-run junto com o comando ceph orch apply osd. Por exemplo:

cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run
...
+---------+------+------+----------+----+-----+
|SERVICE  |NAME  |HOST  |DATA      |DB  |WAL  |
+---------+------+------+----------+----+-----+
|osd      |test  |mgr0  |/dev/sda  |-   |-    |
|osd      |test  |mgr0  |/dev/sdb  |-   |-    |
+---------+------+------+----------+----+-----+

Se a saída --dry-run atender às suas expectativas, basta executar novamente o comando sem a opção --dry-run.

13.4.3.1 OSDs não gerenciados #

 

Todos os dispositivos de disco limpos disponíveis que correspondem à especificação DriveGroups serão usados como OSDs automaticamente depois que você os adicionar ao cluster. Esse comportamento é chamado de modo gerenciado.

Para desabilitar o modo gerenciado, adicione a linha unmanaged: true às especificações relevantes, por exemplo:

service_type: osd
service_id: example_drvgrp_name
placement:
 hosts:
 - ses-min2
 - ses-min3
encrypted: true
unmanaged: true

Dica

Para mudar os OSDs já implantados do modo gerenciado para não gerenciado, adicione as linhas unmanaged: true aos locais aplicáveis durante o procedimento descrito na Seção 13.1, “Modificando a configuração do cluster”.

13.4.3.2 Especificação DriveGroups #

 

Veja a seguir um exemplo do arquivo de especificação DriveGroups:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  drive_spec: DEVICE_SPECIFICATION
db_devices:
  drive_spec: DEVICE_SPECIFICATION
wal_devices:
  drive_spec: DEVICE_SPECIFICATION
block_wal_size: '5G'  # (optional, unit suffixes permitted)
block_db_size: '5G'   # (optional, unit suffixes permitted)
encrypted: true       # 'True' or 'False' (defaults to 'False')

Nota

A opção antes chamada de "criptografia" no DeepSea foi renomeada para "criptografada". Ao usar o DriveGroups no SUSE Enterprise Storage 7, adote essa nova terminologia na especificação do serviço; do contrário, haverá falha na operação ceph orch apply.

13.4.3.4 Filtrando dispositivos por tamanho #

 

Você pode filtrar dispositivos de disco por tamanho, seja por um tamanho exato ou por uma faixa de tamanhos. O parâmetro size: aceita argumentos no seguinte formato:

• “10G”: Inclui discos de um tamanho exato.

• “10G:40G”: Inclui discos cujo tamanho está dentro da faixa.

• “:10G”: Inclui discos menores do que ou iguais a 10 GB.

• “40G:”: Inclui discos iguais ou maiores do que 40 GB.

Exemplo 13.1: Correspondendo por tamanho do disco #

 

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '40TB:'
db_devices:
  size: ':2TB'

Nota: Aspas obrigatórias

Ao usar o delimitador “:”, você precisa colocar o tamanho entre aspas; do contrário, o sinal “:” será interpretado como um novo hash de configuração.

Dica: Atalhos de unidade

Em vez de Gigabytes (G), você pode especificar os tamanhos em Megabytes (M) ou Terabytes (T).

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: MC-55-44-XZ

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ

service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB

service_type: osd
service_id: example_drvgrp_one2five
placement:
  host_pattern: 'node[1-5]'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

service_type: osd
service_id: example_drvgrp_rest
placement:
  host_pattern: 'node[6-10]'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
wal_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

Antes de remover um nó OSD do cluster, verifique se o cluster tem mais espaço livre em disco do que o disco OSD que será removido. Saiba que a remoção de um OSD provoca a redistribuição do cluster inteiro.

cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID

Há várias razões pelas quais você pode precisar substituir um disco OSD. Por exemplo:

Para substituir um OSD mantendo seu ID, execute:

cephuser@adm > ceph orch osd rm OSD_SERVICE_ID --replace

Por exemplo:

cephuser@adm > ceph orch osd rm 4 --replace

A substituição de um OSD é idêntica à remoção de um OSD (consulte a Seção 13.4.4, “Removendo OSDs” para obter mais detalhes), exceto que o OSD não é permanentemente removido da hierarquia CRUSH e recebe um flag destroyed.

O flag destroyed é usado para determinados IDs de OSD que serão reutilizados durante a próxima implantação de OSD. Os discos recém-adicionados que corresponderem à especificação DriveGroups (consulte a Seção 13.4.3, “Adicionando OSDs por meio da especificação DriveGroups” para obter mais detalhes) receberão os IDs de OSD da contraparte substituída.

Dica

Anexar a opção --dry-run não executará a substituição real, mas apresentará uma visualização das etapas que normalmente ocorrem.

Nota

No caso de substituir um OSD após uma falha, é altamente recomendável acionar uma remoção profunda dos grupos de posicionamento. Visite a Seção 17.6, “Depurando grupos de posicionamento” para obter mais detalhes.

Execute o seguinte comando para iniciar uma remoção profunda:

cephuser@adm > ceph osd deep-scrub osd.OSD_NUMBER

Importante: Falha no dispositivo compartilhado

Em caso de falha em um dispositivo compartilhado para BD/WAL, você precisará executar o procedimento de substituição para todos os OSDs que compartilham o dispositivo com falha.

Antes de corrigir o cluster com os pacotes de software mais recentes, verifique se todos os nós do cluster têm acesso aos repositórios relevantes. Consulte o Seção 10.1.5.1, “Repositórios do software” para obter uma lista completa dos repositórios necessários.

Se você usa uma ferramenta de propagação em fases; por exemplo, SUSE Manager ou SMT (Subscription Management Tool), que processa os repositórios do software nos nós do cluster, verifique se as fases dos dois repositórios "Updates" para o SUSE Linux Enterprise Server e o SUSE Enterprise Storage foram criadas no mesmo momento.

É altamente recomendável usar uma ferramenta de propagação em fases para aplicar os patches que têm níveis congelados ou em fases. Isso garante que os novos nós que ingressarem no cluster tenham o mesmo nível de patch que os nós que já estão em execução no cluster. Dessa forma, você não precisa aplicar os patches mais recentes a todos os nós do cluster antes que os novos nós possam ingressar no cluster.

Dependendo da configuração, os nós do cluster podem ser reinicializados durante a atualização. Se houver um ponto único de falha para os serviços, como Gateway de Objetos, Samba Gateway, NFS Ganesha ou iSCSI, as máquinas cliente poderão ser temporariamente desconectadas dos serviços cujos nós estão sendo reinicializados.

Para atualizar os pacotes de software em todos os nós do cluster para a versão mais recente, execute o seguinte comando:

root@master # ceph-salt update

Antes de iniciar a atualização, verifique se todos os nós estão online e se o cluster está saudável:

cephuser@adm > cephadm shell -- ceph -s

Para atualizar para uma versão específica do Ceph:

cephuser@adm > ceph orch upgrade start --image REGISTRY_URL

Por exemplo:

cephuser@adm > ceph orch upgrade start --image registry.suse.com/ses/7.1/ceph/ceph:latest

Fazer upgrade de pacotes nos hosts:

cephuser@adm > ceph-salt update

Execute o seguinte comando para determinar se uma atualização está em andamento:

cephuser@adm > ceph orch upgrade status

Enquanto a atualização estiver em andamento, você verá uma barra de andamento na saída de status do Ceph:

cephuser@adm > ceph -s
[...]
  progress:
    Upgrade to registry.suse.com/ses/7.1/ceph/ceph:latest (00h 20m 12s)
      [=======.....................] (time remaining: 01h 43m 31s)

Você também pode observar o registro do cephadm:

cephuser@adm > ceph -W cephadm

Você pode interromper o processo de atualização a qualquer momento:

cephuser@adm > ceph orch upgrade stop