Ir para o conteúdoIr para navegação de página: página anterior [tecla de acesso p]/próxima página [tecla de acesso n]
documentation.suse.com / Documentação do SUSE Enterprise Storage 7 / Guia de Operações e Administração / Operação do cluster / Tarefas operacionais
Aplica-se a SUSE Enterprise Storage 7

13 Tarefas operacionais

13.1 Modificando a configuração do cluster

Para modificar a configuração de um cluster do Ceph existente, siga estas etapas:

  1. Exporte a configuração atual do cluster para um arquivo:

    cephuser@adm > ceph orch ls --export --format yaml > cluster.yaml
  2. Edite o arquivo com a configuração e atualize as linhas relevantes. Encontre exemplos de especificações no Seção 5.4, “Implantando serviços e gateways” e Seção 13.4.3, “Adicionando OSDs por meio da especificação DriveGroups”.

  3. Aplique a nova configuração:

    cephuser@adm > ceph orch apply -i cluster.yaml

13.2 Adicionando nós

Para adicionar um novo nó a um cluster do Ceph, siga estas etapas:

  1. Instale o SUSE Linux Enterprise Server e o SUSE Enterprise Storage no novo host. Consulte o Seção 5.1, “Instalando e configurando o SUSE Linux Enterprise Server” para obter mais informações.

  2. Configure o host como um Minion Salt de um Master Salt existente. Consulte o Seção 5.2, “Implantando o Salt” para obter mais informações.

  3. Adicione o novo host ao ceph-salt e informe ao cephadm, por exemplo:

    root@master # ceph-salt config /ceph_cluster/minions add ses-min5.example.com
    root@master # ceph-salt config /ceph_cluster/roles/cephadm add ses-min5.example.com

    Consulte o Seção 5.3.2.2, “Adicionando minions Salt” para obter mais informações.

  4. Verifique se o nó foi adicionado ao ceph-salt:

    root@master # ceph-salt config /ceph_cluster/minions ls
    o- minions ................................................. [Minions: 5]
    [...]
      o- ses-min5.example.com .................................... [no roles]
  5. Aplique a configuração ao novo host de cluster:

    root@master # ceph-salt apply ses-min5.example.com
  6. Verifique se o host recém-adicionado agora pertence ao ambiente do cephadm:

    cephuser@adm > ceph orch host ls
    HOST                   ADDR                    LABELS   STATUS
    [...]
    ses-min5.example.com   ses-min5.example.com

13.3 Removendo nós

Dica
Dica: Remover OSDs

Se o nó que você vai remover executa OSDs, remova-os primeiro e verifique se nenhum OSD está sendo executado nesse nó. Consulte Seção 13.4.4, “Removendo OSDs” para obter mais detalhes sobre como remover OSDs.

Para remover um nó de um cluster, faça o seguinte:

  1. Para todos os tipos de serviço do Ceph, exceto node-exporter e crash, remova o nome de host do nó do arquivo de especificação de posicionamento do cluster (por exemplo, cluster.yml). Consulte o Seção 5.4.2, “Especificação de serviço e posicionamento” para obter mais detalhes. Por exemplo, se você remover o host chamado ses-min2, remova todas as ocorrências de - ses-min2 de todas as seções placement:

    Atualização

    service_type: rgw
    service_id: EXAMPLE_NFS
    placement:
      hosts:
      - ses-min2
      - ses-min3

    para

    service_type: rgw
    service_id: EXAMPLE_NFS
    placement:
      hosts:
      - ses-min3

    Aplique suas mudanças ao arquivo de configuração:

    cephuser@adm > ceph orch apply -i rgw-example.yaml
  2. Remova o nó do ambiente do cephadm:

    cephuser@adm > ceph orch host rm ses-min2
  3. Se o nó estiver executando os serviços crash.osd.1 e crash.osd.2, remova-os executando o seguinte comando no host:

    root@minion > cephadm rm-daemon --fsid CLUSTER_ID --name SERVICE_NAME

    Por exemplo:

    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.1
    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2
  4. Remova todas as funções do minion que deseja apagar:

    cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/throughput remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/latency remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/cephadm remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/admin remove ses-min2

    Se o minion que você deseja remover for de boot, você também precisará remover a função de boot:

    cephuser@adm > ceph-salt config /ceph_cluster/roles/bootstrap reset
  5. Após remover todos os OSDs de um único host, remova o host do mapa CRUSH:

    cephuser@adm > ceph osd crush remove bucket-name
    Nota
    Nota

    O nome do compartimento de memória deve ser igual ao nome de host.

  6. Agora você pode remover o minion do cluster:

    cephuser@adm > ceph-salt config /ceph_cluster/minions remove ses-min2
Importante
Importante

Em caso de falha e se o minion que você está tentando remover estiver em um estado permanentemente desligado, você precisará remover o nó do Master Salt:

root@master # salt-key -d minion_id

Em seguida, remova o nó de pillar_root/ceph-salt.sls. Normalmente, ele está localizado em /srv/pillar/ceph-salt.sls.

13.4 Gerenciamento de OSD

Esta seção descreve como adicionar, apagar ou remover OSDs de um cluster do Ceph.

13.4.1 Listando dispositivos de disco

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

13.4.2 Apagando dispositivos de disco

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
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.

13.4.3 Adicionando OSDs por meio da especificação DriveGroups

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
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
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.3 Correspondendo dispositivos de disco

Você pode descrever a especificação usando os seguintes filtros:

  • Por um modelo de disco:

    model: DISK_MODEL_STRING
  • Por um fornecedor de disco:

    vendor: DISK_VENDOR_STRING
    Dica
    Dica

    Insira DISK_VENDOR_STRING sempre em letras minúsculas.

    Para obter detalhes sobre o modelo e o fornecedor do disco, observe a saída do seguinte comando:

    cephuser@adm > ceph orch device ls
    HOST     PATH     TYPE  SIZE DEVICE_ID                  MODEL            VENDOR
    ses-min1 /dev/sdb ssd  29.8G SATA_SSD_AF34075704240015  SATA SSD         ATA
    ses-min2 /dev/sda ssd   223G Micron_5200_MTFDDAK240TDN  Micron_5200_MTFD ATA
    [...]
  • Se um disco é ou não rotacional. Os SSDs e as unidades NVMe não são rotacionais.

    rotational: 0
  • Implante um nó usando todas as unidades disponíveis para OSDs:

    data_devices:
      all: true
  • Limite também o número de discos correspondentes:

    limit: 10

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
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
Dica: Atalhos de unidade

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

13.4.3.5 Exemplos de DriveGroups

Esta seção inclui exemplos de configurações de OSD diferentes.

Exemplo 13.2: Configuração simples

Este exemplo descreve dois nós com a mesma configuração:

  • 20 HDDs

    • Fornecedor: Intel

    • Modelo: SSD-123-foo

    • Tamanho: 4 TB

  • 2 SSDs

    • Fornecedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamanho: 512 GB

O arquivo drive_groups.yml correspondente será da seguinte maneira:

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

Essa configuração é simples e válida. O problema é que um administrador pode adicionar discos de diferentes fornecedores no futuro, e eles não serão incluídos. Você pode melhorá-la reduzindo os filtros nas propriedades de núcleo das unidades:

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

No exemplo anterior, impomos todos os dispositivos rotacionais que serão declarados como "dispositivos de dados", e todos os dispositivos não rotacionais serão usados como "dispositivos compartilhados" (wal, db).

Se você sabe que as unidades com mais de 2 TB sempre serão os dispositivos de dados mais lentos, pode filtrar por tamanho:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'
Exemplo 13.3: Configuração avançada

Este exemplo descreve duas configurações distintas: 20 HDDs devem compartilhar 2 SSDs, enquanto 10 SSDs devem compartilhar 2 NVMes.

  • 20 HDDs

    • Fornecedor: Intel

    • Modelo: SSD-123-foo

    • Tamanho: 4 TB

  • 12 SSDs

    • Fornecedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamanho: 512 GB

  • 2 NVMes

    • Fornecedor: Samsung

    • Modelo: NVME-QQQQ-987

    • Tamanho: 256 GB

Essa configuração pode ser definida com dois layouts da seguinte maneira:

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
Exemplo 13.4: Configuração avançada com nós não uniformes

Os exemplos anteriores consideraram que todos os nós tinham as mesmas unidades. No entanto, esse nem sempre é o caso:

Nós 1-5:

  • 20 HDDs

    • Fornecedor: Intel

    • Modelo: SSD-123-foo

    • Tamanho: 4 TB

  • 2 SSDs

    • Fornecedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamanho: 512 GB

Nós 6-10:

  • 5 NVMes

    • Fornecedor: Intel

    • Modelo: SSD-123-foo

    • Tamanho: 4 TB

  • 20 SSDs

    • Fornecedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamanho: 512 GB

Você pode usar a chave de “destino” no layout para direcionar nós específicos. A notação de destino do Salt ajuda a simplificar as coisas:

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

seguido de

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
Exemplo 13.5: Configuração técnica

Todos os casos anteriores consideraram que os WALs e BDs usavam o mesmo dispositivo. No entanto, também é possível implantar o WAL em um dispositivo dedicado:

  • 20 HDDs

    • Fornecedor: Intel

    • Modelo: SSD-123-foo

    • Tamanho: 4 TB

  • 2 SSDs

    • Fornecedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamanho: 512 GB

  • 2 NVMes

    • Fornecedor: Samsung

    • Modelo: NVME-QQQQ-987

    • Tamanho: 256 GB

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
Exemplo 13.6: Configuração complexa (e improvável)

Na configuração a seguir, tentamos definir:

  • 20 HDDs com 1 NVMe

  • 2 HDDs com 1 SSD(db) e 1 NVMe(wal)

  • 8 SSDs com 1 NVMe

  • 2 SSDs independentes (criptografados)

  • 1 HDD é sobressalente e não deve ser implantado

Veja a seguir o resumo das unidades usadas:

  • 23 HDDs

    • Fornecedor: Intel

    • Modelo: SSD-123-foo

    • Tamanho: 4 TB

  • 10 SSDs

    • Fornecedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamanho: 512 GB

  • 1 NVMe

    • Fornecedor: Samsung

    • Modelo: NVME-QQQQ-987

    • Tamanho: 256 GB

A definição dos DriveGroups será a seguinte:

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

Um HDD permanecerá enquanto o arquivo está sendo analisado de cima para baixo.

13.4.4 Removendo OSDs

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.

  1. Identifique o OSD que será removido obtendo seu ID:

    cephuser@adm > ceph orch ps --daemon_type osd
    NAME   HOST            STATUS        REFRESHED  AGE  VERSION
    osd.0  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.1  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.2  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.3  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
  2. Remova um ou mais OSDs do cluster:

    cephuser@adm > ceph orch osd rm OSD1_ID OSD2_ID ...

    Por exemplo:

    cephuser@adm > ceph orch osd rm 1 2
  3. Você pode consultar o estado da operação de remoção:

    cephuser@adm > ceph orch osd rm status
    OSD_ID  HOST         STATE                    PG_COUNT  REPLACE  FORCE  STARTED_AT
    2       cephadm-dev  done, waiting for purge  0         True     False  2020-07-17 13:01:43.147684
    3       cephadm-dev  draining                 17        False    True   2020-07-17 13:01:45.162158
    4       cephadm-dev  started                  42        False    True   2020-07-17 13:01:45.162158

13.4.4.1 Interrompendo a remoção do OSD

Após programar uma remoção do OSD, você poderá interrompê-la, se necessário. O comando a seguir redefinirá o estado inicial do OSD e o removerá da fila:

cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID

13.4.5 Substituindo OSDs

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
Dica

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

13.5 Movendo o Master Salt para um novo nó

Se você precisar substituir o host Master Salt por um novo, siga estas etapas:

  1. Exporte a configuração do cluster e faça backup do arquivo JSON exportado. Encontre mais detalhes no Seção 5.3.2.15, “Exportando as configurações do cluster”.

  2. Se o Master Salt antigo também for o único nó de administração no cluster, mova manualmente /etc/ceph/ceph.client.admin.keyring e /etc/ceph/ceph.conf para o novo Master Salt.

  3. Pare e desabilite o serviço systemd do Master Salt no nó do Master Salt antigo:

    root@master # systemctl stop salt-master.service
    root@master # systemctl disable salt-master.service
  4. Se o nó do Master Salt antigo não estiver mais no cluster, também pare e desabilite o serviço systemd do Minion Salt:

    root@master # systemctl stop salt-minion.service
    root@master # systemctl disable salt-minion.service
    Atenção
    Atenção

    Não pare nem desabilite o salt-minion.service se o nó do Master Salt antigo tiver daemons do Ceph (MON, MGR, OSD, MDS, gateway, monitoramento) em execução.

  5. Instale o SUSE Linux Enterprise Server 15 SP2 no novo Master Salt seguindo o procedimento descrito no Seção 5.1, “Instalando e configurando o SUSE Linux Enterprise Server”.

    Dica
    Dica: Transição de Minion Salt

    Para simplificar a transição dos Minions Salt para o novo Master Salt, remova a chave pública do Master Salt original de cada um deles:

    root@minion > rm /etc/salt/pki/minion/minion_master.pub
    root@minion > systemctl restart salt-minion.service
  6. Instale o pacote salt-master e, se aplicável, o pacote salt-minion no novo Master Salt.

  7. Instale o ceph-salt no novo nó do Master Salt:

    root@master # zypper install ceph-salt
    root@master # systemctl restart salt-master.service
    root@master # salt '*' saltutil.sync_all
    Importante
    Importante

    Execute todos os três comandos antes de continuar. Os comandos são idempotentes; não faz diferença se eles são repetidos.

  8. Inclua o novo Master Salt no cluster, conforme descrito no Seção 5.3.1, “Instalando o ceph-salt, Seção 5.3.2.2, “Adicionando minions Salt” e Seção 5.3.2.4, “Especificando o nó de admin”.

  9. Importe a configuração do cluster de backup e aplique-a:

    root@master # ceph-salt import CLUSTER_CONFIG.json
    root@master # ceph-salt apply
    Importante
    Importante

    Renomeie o minion id do Master Salt no arquivo CLUSTER_CONFIG.json exportado antes de importá-lo.

13.6 Atualizando os nós do cluster

Mantenha os nós do cluster do Ceph atualizados aplicando as atualizações sequenciais regularmente.

13.6.1 Repositórios do software

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 7.1.5.1, “Repositórios do software” para obter uma lista completa dos repositórios necessários.

13.6.2 Propagação em fases do repositório

Se você usa uma ferramenta de propagação em fases; por exemplo, SUSE Manager ou Repository Management Tool (RMT), 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.

13.6.3 Tempo de espera dos serviços do Ceph

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.

13.6.4 Executando a atualização

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

13.7 Atualizando o Ceph

Você pode instruir o cephadm a atualizar o Ceph de uma versão de correção de bug para outra. A atualização automatizada dos serviços do Ceph respeita a ordem recomendada: ela começa com os Ceph Managers, os Ceph Monitors e continua com os outros serviços, como Ceph OSDs, Servidores de Metadados e Gateways de Objetos. Cada daemon será reiniciado apenas depois que o Ceph indicar que o cluster permanecerá disponível.

Nota
Nota

O procedimento de atualização a seguir usa o comando ceph orch upgrade. Lembre-se de que as instruções a seguir detalham como atualizar o cluster do Ceph com uma versão do produto (por exemplo, uma atualização de manutenção) e não fornecem instruções sobre como fazer upgrade do cluster de uma versão do produto para outra.

13.7.1 Iniciando a atualização

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/ceph/ceph:latest

Fazer upgrade de pacotes nos hosts:

cephuser@adm > ceph-salt update

13.7.2 Monitorando a atualização

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/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

13.7.3 Cancelando uma atualização

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

cephuser@adm > ceph orch upgrade stop

13.8 Parando ou reinicializando o cluster

Em alguns casos, talvez seja necessário parar ou reinicializar o cluster inteiro. Recomendamos verificar com cuidado as dependências dos serviços em execução. As seguintes etapas apresentam uma descrição de como parar e iniciar o cluster:

  1. Especifique para o cluster do Ceph não marcar os OSDs com o flag “out”:

    cephuser@adm > ceph osd set noout
  2. Pare os daemons e os nós na seguinte ordem:

    1. Clientes de armazenamento

    2. Gateways. Por exemplo, NFS Ganesha ou Gateway de Objetos

    3. Servidor de Metadados

    4. Ceph OSD

    5. Ceph Manager

    6. Ceph Monitor

  3. Se necessário, execute as tarefas de manutenção.

  4. Inicie os nós e os servidores na ordem inversa do processo de encerramento:

    1. Ceph Monitor

    2. Ceph Manager

    3. Ceph OSD

    4. Servidor de Metadados

    5. Gateways. Por exemplo, NFS Ganesha ou Gateway de Objetos

    6. Clientes de armazenamento

  5. Remova o flag “noout”:

    cephuser@adm > ceph osd unset noout

13.9 Removendo um cluster inteiro do Ceph

O comando ceph-salt purge remove todo o cluster do Ceph. Se houver mais clusters do Ceph implantados, será purgado aquele que for relatado pelo ceph -s. Desta forma, você pode limpar o ambiente do cluster ao testar configurações diferentes.

Para evitar a exclusão acidental, a orquestração verifica se a segurança está desligada. Você pode desligar as medidas de segurança e remover o cluster do Ceph executando:

root@master # ceph-salt disengage-safety
root@master # ceph-salt purge