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:
Exporte a configuração atual do cluster para um arquivo:
cephuser@adm >
ceph orch ls --export --format yaml > cluster.yamlEdite 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”.
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:
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.
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.
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.comroot@master #
ceph-salt config /ceph_cluster/roles/cephadm add ses-min5.example.comConsulte o Seção 5.3.2.2, “Adicionando minions Salt” para obter mais informações.
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]Aplique a configuração ao novo host de cluster:
root@master #
ceph-salt apply ses-min5.example.comVerifique 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 #
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:
Para todos os tipos de serviço do Ceph, exceto
node-exporter
ecrash
, 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 chamadoses-min2
, remova todas as ocorrências de- ses-min2
de todas as seçõesplacement:
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.yamlRemova o nó do ambiente do cephadm:
cephuser@adm >
ceph orch host rm ses-min2Se o nó estiver executando os serviços
crash.osd.1
ecrash.osd.2
, remova-os executando o seguinte comando no host:root@minion >
cephadm rm-daemon --fsid CLUSTER_ID --name SERVICE_NAMEPor exemplo:
root@minion >
cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.1root@minion >
cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2Remova todas as funções do minion que deseja apagar:
cephuser@adm >
ceph-salt config /ceph_cluster/roles/tuned/throughput remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/tuned/latency remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/cephadm remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/admin remove ses-min2Se 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 resetApós remover todos os OSDs de um único host, remova o host do mapa CRUSH:
cephuser@adm >
ceph osd crush remove bucket-nameNotaO nome do compartimento de memória deve ser igual ao nome de host.
Agora você pode remover o minion do cluster:
cephuser@adm >
ceph-salt config /ceph_cluster/minions remove ses-min2
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
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 -idrive_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 -idrive_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
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')
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
DicaInsira 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.
service_type: osd service_id: example_drvgrp_name placement: host_pattern: '*' data_devices: size: '40TB:' db_devices: size: ':2TB'
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.
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.
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'
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
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
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
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.
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 ...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 2Você 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.
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:
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”.
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.Pare e desabilite o serviço
systemd
do Master Salt no nó do Master Salt antigo:root@master #
systemctl stop salt-master.serviceroot@master #
systemctl disable salt-master.serviceSe 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.serviceroot@master #
systemctl disable salt-minion.serviceAtençãoNã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.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: Transição de Minion SaltPara 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.pubroot@minion >
systemctl restart salt-minion.serviceInstale o pacote salt-master e, se aplicável, o pacote salt-minion no novo Master Salt.
Instale o
ceph-salt
no novo nó do Master Salt:root@master #
zypper install ceph-saltroot@master #
systemctl restart salt-master.serviceroot@master #
salt '*' saltutil.sync_allImportanteExecute todos os três comandos antes de continuar. Os comandos são idempotentes; não faz diferença se eles são repetidos.
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”.Importe a configuração do cluster de backup e aplique-a:
root@master #
ceph-salt import CLUSTER_CONFIG.jsonroot@master #
ceph-salt applyImportanteRenomeie o
minion id
do Master Salt no arquivoCLUSTER_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.
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:
Especifique para o cluster do Ceph não marcar os OSDs com o flag “out”:
cephuser@adm >
ceph
osd set nooutPare os daemons e os nós na seguinte ordem:
Clientes de armazenamento
Gateways. Por exemplo, NFS Ganesha ou Gateway de Objetos
Servidor de Metadados
Ceph OSD
Ceph Manager
Ceph Monitor
Se necessário, execute as tarefas de manutenção.
Inicie os nós e os servidores na ordem inversa do processo de encerramento:
Ceph Monitor
Ceph Manager
Ceph OSD
Servidor de Metadados
Gateways. Por exemplo, NFS Ganesha ou Gateway de Objetos
Clientes de armazenamento
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-safetyroot@master #
ceph-salt purge