Administração do cluster do Salt | Guia de Administração

documentation.suse.com › Documentação do SUSE Enterprise Storage 6 › Guia de Administração › Gerenciamento de Cluster › Administração do cluster do Salt

ConteúdoConteúdo

Guia de Administração

Navegação←→

Aplica-se a SUSE Enterprise Storage 6

2 Administração do cluster do Salt #

2.1 Adicionando novos nós do cluster
2.2 Adicionando novas funções aos nós
2.3 Removendo e reinstalando nós do cluster
2.4 Reimplantando nós do monitor
2.5 Adicionando um disco OSD a um nó
2.6 Removendo um OSD
2.7 Substituindo um disco OSD
2.8 Recuperando um nó OSD reinstalado
2.9 Movendo o nó de admin para um novo servidor
2.10 Instalação automatizada pelo Salt
2.11 Atualizando os nós do cluster
2.12 Parando ou reinicializando o cluster
2.13 Ajustando o ceph.conf com configurações personalizadas
2.14 Habilitando perfis do AppArmor
2.15 Desativando perfis ajustados
2.16 Removendo um cluster inteiro do Ceph

Após implantar um cluster do Ceph, provavelmente você precisará fazer várias modificações nele de vez em quando. Dentre elas, adicionar ou remover novos nós, discos ou serviços. Este capítulo descreve como você pode realizar essas tarefas de administração.

2.1 Adicionando novos nós do cluster #

O procedimento de adição de novos nós ao cluster é quase idêntico à implantação de nó do cluster inicial descrita no Capítulo 5, Implantando com o DeepSea/Salt:

Dica: Evitar Redistribuição

Ao adicionar um OSD ao cluster existente, lembre-se de que o cluster será redistribuído após algum tempo. Para minimizar os períodos de redistribuição, adicione ao mesmo tempo todos os OSDs desejados.

A outra maneira é definir a opção osd crush initial weight = 0 no arquivo ceph.conf antes de adicionar os OSDs:

Adicione osd crush initial weight = 0 a /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf.

Crie a nova configuração no nó master Salt:

root@master # salt 'SALT_MASTER_NODE' state.apply ceph.configuration.create

Aplique a nova configuração aos minions OSD de destino:

root@master # salt 'OSD_MINIONS' state.apply ceph.configuration

Após a adição dos novos OSDs, ajuste os pesos deles conforme necessário com o comando ceph osd crush reweight.

Instale o SUSE Linux Enterprise Server 15 SP1 no novo nó e defina a configuração de rede para que ela resolva o nome de host do master Salt corretamente. Verifique se ele tem uma conexão apropriada com redes públicas e de cluster e se a sincronização de horário está configurada corretamente. Em seguida, instale o pacote salt-minion:
```
root@minion > zypper in salt-minion
```
Se o nome de host do master Salt não for salt, edite /etc/salt/minion e adicione o seguinte:
```
master: DNS_name_of_your_salt_master
```
Se você efetuou quaisquer mudanças nos arquivos de configuração mencionados acima, reinicie o serviço salt.minion:
```
root@minion > systemctl restart salt-minion.service
```
No master Salt, aceite a chave salt do novo nó:
```
root@master # salt-key --accept NEW_NODE_KEY
```
Verifique se o /srv/pillar/ceph/deepsea_minions.sls está direcionado para o novo minion Salt e/ou defina o grain do DeepSea apropriado. Consulte o Seção 5.2.2.1, “Correspondendo o nome do minion” ou o Procedimento 5.1, “Executando as fases de implantação” para obter mais detalhes.
Execute a fase de preparação. Ela sincroniza os módulos e grains para que o novo minion possa fornecer todas as informações esperadas pelo DeepSea.
```
root@master # salt-run state.orch ceph.stage.0
```
Importante: Possível Reinicialização da fase 0 do DeepSea
Se o master Salt for reiniciado após a atualização do kernel, você precisará reiniciar a fase 0 do DeepSea.
Execute a fase de descoberta. Ela gravará novas entradas de arquivo no diretório /srv/pillar/ceph/proposals, em que você pode editar os arquivos .yml relevantes:
```
root@master # salt-run state.orch ceph.stage.1
```
Se preferir, mude o /srv/pillar/ceph/proposals/policy.cfg se o host recém-adicionado não corresponder ao esquema de nomeação existente. Para obter informações detalhadas, consulte o Seção 5.5.1, “Arquivo policy.cfg”.
Execute a fase de configuração. Ela lê tudo o que está em /srv/pillar/ceph e atualiza o pillar de acordo:
```
root@master # salt-run state.orch ceph.stage.2
```
O pillar armazena dados que você pode acessar com o seguinte comando:
```
root@master # salt target pillar.items
```
Dica: Modificação do Layout do OSD
Para modificar o layout do OSD padrão e mudar a configuração dos grupos de unidades, siga o procedimento descrito no Seção 5.5.2, “DriveGroups”.

As fases de configuração e implantação incluem os nós recém-adicionados:

root@master # salt-run state.orch ceph.stage.3
root@master # salt-run state.orch ceph.stage.4

2.2 Adicionando novas funções aos nós #

Você pode implantar com o DeepSea todos os tipos de funções suportadas. Consulte o Seção 5.5.1.2, “Atribuição de função” para obter mais informações sobre os tipos de função suportados e ver exemplos de como correspondê-los.

Para adicionar um novo serviço a um nó existente, siga estas etapas:

Adapte o /srv/pillar/ceph/proposals/policy.cfg para corresponder o host existente a uma nova função. Para obter mais detalhes, consulte o Seção 5.5.1, “Arquivo policy.cfg”. Por exemplo, se você precisa executar um Object Gateway em um nó MON, a linha é semelhante a:
```
role-rgw/xx/x/example.mon-1.sls
```

Execute a fase 2 para atualizar o pillar:

root@master # salt-run state.orch ceph.stage.2

Execute a fase 3 para implantar os serviços básicos, ou a fase 4 para implantar os serviços opcionais. Não há nenhum problema em executar as duas fases.

2.3 Removendo e reinstalando nós do cluster #

Dica: Remoção Temporária de um Nó do Cluster

O master Salt espera que todos os minions estejam presentes e responsivos no cluster. Se houver falha em um minion e ele parar de responder, isso causará problemas na infraestrutura do Salt, principalmente no DeepSea e no Ceph Dashboard.

Antes de corrigir o minion, apague a chave dele do master Salt temporariamente:

root@master # salt-key -d MINION_HOST_NAME

Após a correção do minion, adicione a chave dele ao master Salt novamente:

root@master # salt-key -a MINION_HOST_NAME

Para remover uma função de um cluster, edite o /srv/pillar/ceph/proposals/policy.cfg e remova a(s) linha(s) correspondente(s). Em seguida, execute as fases 2 e 5, conforme descrito no Seção 5.3, “Implantação do cluster”.

Nota: Removendo OSDs do Cluster

Se for necessário remover determinado nó OSD do cluster, verifique se o cluster tem mais espaço livre em disco do que o disco que você pretende remover. A remoção de um OSD provoca a redistribuição do cluster inteiro.

Antes de executar a fase 5 para fazer a remoção real, sempre verifique quais OSDs serão removidos pelo DeepSea:

root@master # salt-run rescinded.ids

Quando uma função é removida de um minion, o objetivo é desfazer todas as modificações relacionadas a essa função. Para a maioria das funções, a tarefa é simples, mas pode haver problemas com as dependências de pacotes. Se um pacote for desinstalado, suas dependências não serão.

Os OSDs removidos aparecem como unidades em branco. As tarefas relacionadas sobregravam o início dos sistemas de arquivos, removem as partições de backup e limpam as tabelas de partição.

Nota: Preservando as partições criadas por outros métodos

As unidades de disco já configuradas por outros métodos, como ceph-deploy, ainda podem conter partições. O DeepSea não as eliminará automaticamente. O administrador deve reaproveitar essas unidades manualmente.

Exemplo 2.1: Removendo um minion Salt do cluster #

Se os nomes dos minions de armazenamento forem, por exemplo, “data1.ceph”, “data2.ceph”, etc., o “data6.ceph” e as linhas relacionadas no policy.cfg serão semelhantes ao seguinte:

[...]
# Hardware Profile
role-storage/cluster/data*.sls
[...]

Portanto, para remover o minion Salt “data2.ceph”, mude as linhas para o seguinte:

[...]
# Hardware Profile
role-storage/cluster/data[1,3-6]*.sls
[...]

Lembre-se também de adpatar seu arquivo drive_groups.yml para corresponder aos novos destinos.

    [...]
    drive_group_name:
      target: 'data[1,3-6]*'
    [...]

Em seguida, execute a fase 2, verifique quais OSDs serão removidos e conclua a execução da fase 5:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run rescinded.ids
root@master # salt-run state.orch ceph.stage.5

Exemplo 2.2: Migrando nós #

Considere a seguinte situação: durante a nova instalação do cluster, você (o administrador) alocou um dos nós de armazenamento como Object Gateway independente enquanto aguardava a chegada do hardware do gateway. Agora, o hardware permanente do gateway chegou e você pode finalmente atribuir a função desejada ao nó de armazenamento de backup e remover a função do gateway.

Depois de executar as fases 0 e 1 (consulte o Procedimento 5.1, “Executando as fases de implantação”) para o novo hardware, você denominou o novo gateway como rgw1. Se o nó data8 precisar que a função Object Gateway seja removida e que a função de armazenamento seja adicionada, o policy.cfg atual terá esta aparência:

# Hardware Profile
role-storage/cluster/data[1-7]*.sls

# Roles
role-rgw/cluster/data8*.sls

Portanto, faça uma mudança para:

# Hardware Profile
role-storage/cluster/data[1-8]*.sls

# Roles
role-rgw/cluster/rgw1*.sls

Execute as fases de 2 a 4, verifique quais OSDs talvez sejam removidos e conclua a execução da fase 5. A Fase 3 adicionará o data8 como nó de armazenamento. Por algum tempo, o data8 terá as duas funções. A fase 4 adicionará a função Object Gateway ao rgw1, e a fase 5 removerá a função Object Gateway do data8:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.3
root@master # salt-run state.orch ceph.stage.4
root@master # salt-run rescinded.ids
root@master # salt-run state.orch ceph.stage.5

2.4 Reimplantando nós do monitor #

Quando há falha em um ou mais nós do monitor e eles não respondem, você precisa remover os monitores com falha do cluster e, possivelmente, readicioná-los ao cluster.

Importante: O Mínimo são Três Nós do Monitor

O número de nós do monitor não deve ser menor do que três. Se houver falha em um nó do monitor e, por esse motivo, o cluster ficar apenas com dois nós, você precisará atribuir temporariamente a função do monitor a outros nós do cluster antes de reimplantar os nós com falha do monitor. Após reimplantar os nós com falha do monitor, você poderá desinstalar as funções temporárias do monitor.

Para obter mais informações sobre como adicionar novos nós/funções ao cluster do Ceph, consulte a Seção 2.1, “Adicionando novos nós do cluster” e a Seção 2.2, “Adicionando novas funções aos nós”.

Para obter mais informações sobre como remover nós do cluster, consulte a Seção 2.3, “Removendo e reinstalando nós do cluster”.

Há dois graus básicos de falha no nó do Ceph:

O host do minion Salt está danificado fisicamente ou no nível do OS e não responde à chamada salt “nome_do_minion” test.ping. Nesse caso, você precisa reimplantar o servidor por completo seguindo as instruções relevantes no Seção 5.3, “Implantação do cluster”.
Houve falha nos serviços relacionados ao monitor e eles se recusam a se recuperar, mas o host responde à chamada salt “nome_do_minion” test.ping. Nesse caso, siga estas etapas:

Edite o /srv/pillar/ceph/proposals/policy.cfg no master Salt e remova ou atualize as linhas correspondentes aos nós com falha do monitor para que agora eles apontem para os nós ativos do monitor. Por exemplo:
```
[...]
# MON
#role-mon/cluster/ses-example-failed1.sls
#role-mon/cluster/ses-example-failed2.sls
role-mon/cluster/ses-example-new1.sls
role-mon/cluster/ses-example-new2.sls
[...]
```

Execute as fases de 2 a 5 do DeepSea para aplicar as mudanças:

root@master # deepsea stage run ceph.stage.2
root@master # deepsea stage run ceph.stage.3
root@master # deepsea stage run ceph.stage.4
root@master # deepsea stage run ceph.stage.5

2.5 Adicionando um disco OSD a um nó #

Para adicionar um disco a um nó OSD existente, verifique se qualquer partição no disco foi removida e limpa. Consulte a Etapa 12 no Seção 5.3, “Implantação do cluster” para obter mais detalhes. Adapte o /srv/salt/ceph/configuration/files/drive_groups.yml de acordo (consulte o Seção 5.5.2, “DriveGroups” para obter detalhes). Após gravar o arquivo, execute a fase 3 do DeepSea:

root@master # deepsea stage run ceph.stage.3

2.6 Removendo um OSD #

Você pode remover um Ceph OSD do cluster executando o seguinte comando:

root@master # salt-run osd.remove OSD_ID

OSD_ID precisa ser um número do OSD sem o prefixo osd.. Por exemplo, use apenas o dígito 3 de osd.3.

2.6.1 Removendo vários OSDs #

Siga o mesmo procedimento conforme mencionado na Seção 2.6, “Removendo um OSD”, mas simplesmente insira vários IDs de OSD:

root@master # salt-run osd.remove 2 6 11 15
Removing osd 2 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.2 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 6 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.6 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 11 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.11 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 15 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.15 is safe to destroy
Purging from the crushmap
Zapping the device


2:
True
6:
True
11:
True
15:
True

2.6.2 Removendo todos os OSDs de um host #

Para remover todos os OSDs de um host específico, execute o seguinte comando:

root@master # salt-run osd.remove OSD_HOST_NAME

2.6.3 Removendo à força os OSDs danificados #

Há casos em que há falha na remoção normal de um OSD (consulte a Seção 2.6, “Removendo um OSD”). Por exemplo, isso poderá acontecer se o OSD ou o diário, WAL ou BD dele estiver danificado, quando ele é afetado por operações de E/S travadas ou quando há falha na desmontagem do disco OSD.

root@master # salt-run osd.remove OSD_ID force=True

Dica: Montagens Travadas

Se uma partição ainda estiver montada no disco que está sendo removido, o comando será encerrado com a mensagem: “Unmount failed - check for processes on DEVICE” (Falha na desmontagem. Consulte os processos no DISPOSITIVO). Em seguida, é possível listar todos os processos que acessam o sistema de arquivos com o comando fuser -m DISPOSITIVO. Se fuser não retornar nada, tente unmount DISPOSITIVO manual e confira a saída dos comandos dmesg ou journalctl.

2.6.4 Validando os metadados OSD da LVM #

Após remover um OSD usando o comando salt-run osd.remove ID ou outros comandos ceph, os metadados da LVM talvez não sejam completamente removidos. Isso significa que, para reimplantar um novo OSD, serão usados os metadados antigos da LVM.

Primeiramente, verifique se o OSD foi removido:

cephadm@osd > ceph-volume lvm list

Mesmo que um dos OSDs tenha sido removido com êxito, ele ainda poderá ser listado. Por exemplo, se você removeu o osd.2, a saída é a seguinte:

  ====== osd.2 =======

  [block] /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380

  block device /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380
  block uuid kH9aNy-vnCT-ExmQ-cAsI-H7Gw-LupE-cvSJO9
  cephx lockbox secret
  cluster fsid 6b6bbac4-eb11-45cc-b325-637e3ff9fa0c
  cluster name ceph
  crush device class None
  encrypted 0
  osd fsid aac51485-131c-442b-a243-47c9186067db
  osd id 2
  type block
  vdo 0
  devices /dev/sda

Neste exemplo, você pode ver que o osd.2 ainda está localizado em /dev/sda.

Valide os metadados da LVM no nó OSD:

cephadm@osd > ceph-volume inventory

A saída da execução de ceph-volume inventory marca a disponibilidade de /dev/sda como False (Falso). Por exemplo:

  Device Path Size rotates available Model name
  /dev/sda 40.00 GB True False QEMU HARDDISK
  /dev/sdb 40.00 GB True False QEMU HARDDISK
  /dev/sdc 40.00 GB True False QEMU HARDDISK
  /dev/sdd 40.00 GB True False QEMU HARDDISK
  /dev/sde 40.00 GB True False QEMU HARDDISK
  /dev/sdf 40.00 GB True False QEMU HARDDISK
  /dev/vda 25.00 GB True False

Execute o seguinte comando no nó OSD para remover completamente os metadados da LVM:
```
cephadm@osd > ceph-volume lvm zap --osd-id ID --destroy
```

Execute o comando inventory novamente para verificar se a disponibilidade de /dev/sda é retornada como True (Verdadeiro). Por exemplo:

cephadm@osd > ceph-volume inventory
Device Path Size rotates available Model name
/dev/sda 40.00 GB True True QEMU HARDDISK
/dev/sdb 40.00 GB True False QEMU HARDDISK
/dev/sdc 40.00 GB True False QEMU HARDDISK
/dev/sdd 40.00 GB True False QEMU HARDDISK
/dev/sde 40.00 GB True False QEMU HARDDISK
/dev/sdf 40.00 GB True False QEMU HARDDISK
/dev/vda 25.00 GB True False

Os metadados da LVM foram removidos. Agora é seguro executar o comando dd no dispositivo.

O OSD pode ser reimplantado sem que seja necessário reinicializar o nó OSD:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.3

2.7 Substituindo um disco OSD #

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

Houve falha no disco OSD ou ele está prestes a falhar com base nas informações do SMART e não poderá mais ser usado para armazenar dados com segurança.
Por exemplo, você precisa fazer upgrade do disco OSD para aumentar o tamanho dele.

O procedimento de substituição é o mesmo para os dois casos. Isso também vale para os Mapas CRUSH padrão e personalizados.

Por exemplo, suponha que “5” é o ID do OSD cujo disco precisa ser substituído. O comando a seguir o marca como eliminado no Mapa CRUSH, mas mantém seu ID original:
```
root@master # salt-run osd.replace 5
```
Dica: osd.replace e osd.remove
Os comandos osd.replace e osd.remove do Salt (consulte a Seção 2.6, “Removendo um OSD”) são idênticos, com exceção de que osd.replace mantém o OSD como “eliminado” no Mapa CRUSH, enquanto osd.remove remove todos os rastreamentos do Mapa CRUSH.
Substitua manualmente a unidade OSD com falha/upgrade.
Para modificar o layout do OSD padrão e mudar a configuração dos DriveGroups, siga o procedimento descrito no Seção 5.5.2, “DriveGroups”.
Execute a fase 3 da implantação para implantar o disco OSD substituído:
```
root@master # salt-run state.orch ceph.stage.3
```

2.8 Recuperando um nó OSD reinstalado #

Se houver falha no sistema operacional que não puder ser recuperada em um dos nós OSD, siga estas etapas para recuperá-lo e reimplantar a função OSD com os dados do cluster inalterados:

Reinstale o sistema operacional SUSE Linux Enterprise de base no nó em que o OS falhou. Instale os pacotes salt-minion no nó OSD, apague a chave antiga do minion Salt do master Salt e registre a nova chave do minion Salt no master Salt. Para obter mais informações sobre a implantação inicial, consulte o Seção 5.3, “Implantação do cluster”.

Em vez de executar toda a fase 0, execute as seguintes partes:

root@master # salt 'osd_node' state.apply ceph.sync
root@master # salt 'osd_node' state.apply ceph.packages.common
root@master # salt 'osd_node' state.apply ceph.mines
root@master # salt 'osd_node' state.apply ceph.updates

Execute as fases de 1 a 5 do DeepSea:

root@master # salt-run state.orch ceph.stage.1
root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.3
root@master # salt-run state.orch ceph.stage.4
root@master # salt-run state.orch ceph.stage.5

Execute a fase 0 do DeepSea:

root@master # salt-run state.orch ceph.stage.0

Reinicialize o nó OSD relevante. Todos os discos OSD serão redescobertos e reutilizados.

Instale e execute o exportador de nó do Prometheus:

root@master # salt 'RECOVERED_MINION' \
 state.apply ceph.monitoring.prometheus.exporters.node_exporter

Atualize os grains do Salt:

root@master # salt 'RECOVERED_MINION' osd.retain

2.9 Movendo o nó de admin para um novo servidor #

Se você precisa substituir o host do Nó de Admin por um novo, é necessário mover os arquivos do master Salt e do DeepSea. Use sua ferramenta de sincronização favorita para transferir os arquivos. Neste procedimento, usamos o rsync porque é uma ferramenta padrão disponível nos repositórios do software SUSE Linux Enterprise Server 15 SP1.

Pare os serviços salt-master e salt-minion no Nó de Admin antigo:

root@master # systemctl stop salt-master.service
root@master # systemctl stop salt-minion.service

Configure o Salt no novo Nó de Admin para que o master Salt e os minions Salt se comuniquem. Encontre mais detalhes no Seção 5.3, “Implantação do cluster”.
Dica: Transição de Minions Salt
Para facilitar a transição dos minions Salt para o novo Nó de Admin, 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
```
Verifique se o pacote deepsea está instalado e instale-o, se necessário.
```
root@master # zypper install deepsea
```
Personalize o arquivo policy.cfg mudando a linha role-master. Encontre mais detalhes no Seção 5.5.1, “Arquivo policy.cfg”.
Sincronize os diretórios /srv/pillar e /srv/salt do Nó de Admin antigo com o novo.
Dica: Dry Run para rsync e Links Simbólicos
Se possível, tente sincronizar os arquivos em um dry run primeiro para ver quais serão transferidos (opção -n do rsync). Inclua também os links simbólicos (opção -a do rsync). Para o rsync, o comando de sincronização terá a seguinte aparência:
```
root@master # rsync -avn /srv/pillar/ NEW-ADMIN-HOSTNAME:/srv/pillar
```
Se você fez mudanças personalizadas nos arquivos fora de /srv/pillar e /srv/salt, por exemplo, no /etc/salt/master ou no /etc/salt/master.d, sincronize-as também.
Agora você pode executar as fases do DeepSea do novo Nó de Admin. Consulte o Seção 5.2, “Introdução ao DeepSea” para obter a descrição detalhada.

2.10 Instalação automatizada pelo Salt #

É possível automatizar a instalação por meio do reator Salt. Para ambientes virtuais ou de hardware consistentes, esta configuração permitirá a criação de um cluster do Ceph com o comportamento especificado.

Atenção

O Salt não pode executar verificações de dependência com base nos eventos do reator. Existe um risco real de tornar seu master Salt sobrecarregado e sem resposta.

A instalação automatizada requer o seguinte:

Um /srv/pillar/ceph/proposals/policy.cfg criado apropriadamente.
Configuração personalizada preparada incluída no diretório /srv/pillar/ceph/stack.

A configuração do reator padrão executará apenas as fases 0 e 1. Isso permite testar o reator sem esperar a conclusão das fases seguintes.

Quando o primeiro comando salt-minion for iniciado, a fase 0 começará. Um bloqueio impede várias instâncias. Quando todos os minions concluírem a fase 0, a fase 1 começará.

Se a operação for executada apropriadamente, edite o arquivo

/etc/salt/master.d/reactor.conf

e substitua a linha a seguir

- /srv/salt/ceph/reactor/discovery.sls

por

- /srv/salt/ceph/reactor/all_stages.sls

Verifique se a linha não está comentada.

2.11 Atualizando os nós do cluster #

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

2.11.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 6.8.1, “Fazendo upgrade manual do nó por meio do DVD do instalador” para obter uma lista completa dos repositórios necessários.

2.11.2 Propagação em fases do repositório #

Se você usa uma ferramenta de propagação em fases, por exemplo, SUSE Manager, SMT (Subscription Management Tool) ou Repository Mirroring 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 patches com níveis de patch congelados/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.

2.11.3 `zypper patch` ou `zypper dup` #

Por padrão, o upgrade dos nós do cluster é feito por meio do comando zypper dup. Se, em vez disso, você preferir atualizar o sistema usando o zypper patch, edite o /srv/pillar/ceph/stack/global.yml e adicione a seguinte linha:

update_method_init: zypper-patch

2.11.4 Reinicializações de nó do cluster #

Durante a atualização, os nós do cluster podem ser reinicializados se a atualização fez upgrade do kernel deles. Para eliminar a possibilidade de uma reinicialização forçada de todos os nós, verifique se o kernel mais recente está instalado e em execução nos nós do Ceph ou desabilite as renicializações de nó automáticas, conforme descrito no Seção 7.1.5, “Atualizações e reinicializações durante a fase 0”.

2.11.5 Tempo de espera dos serviços do Ceph #

Dependendo da configuração, os nós do cluster podem ser reinicializados durante a atualização, conforme descrito na Seção 2.11.4, “Reinicializações de nó do cluster”. Se houver um ponto único de falha para os serviços, como Object Gateway, 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.

2.11.6 Executando a atualização #

Para atualizar os pacotes de software em todos os nós do cluster para a versão mais recente, siga estas etapas:

Atualize os pacotes deepsea, salt-master e salt-minion e reinicie os serviços relevantes no master Salt:
```
root@master # salt -I 'roles:master' state.apply ceph.updates.master
```

Atualize e reinicie o pacote salt-minion em todos os nós do cluster:

root@master # salt -I 'cluster:ceph' state.apply ceph.updates.salt

Atualize todos os outros pacotes de software no cluster:

root@master # salt-run state.orch ceph.maintenance.upgrade

2.12 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”:
```
cephadm@adm > ceph osd set noout
```
Pare os daemons e os nós na seguinte ordem:
1. Clientes de armazenamento
2. Gateways. Por exemplo, NFS Ganesha ou Object Gateway
3. Servidor de Metadados
4. Ceph OSD
5. Ceph Manager
6. 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:
1. Ceph Monitor
2. Ceph Manager
3. Ceph OSD
4. Servidor de Metadados
5. Gateways. Por exemplo, NFS Ganesha ou Object Gateway
6. Clientes de armazenamento
Remova o flag “noout”:
```
cephadm@adm > ceph osd unset noout
```

2.13 Ajustando o `ceph.conf` com configurações personalizadas #

Se você precisar inserir configurações personalizadas no arquivo ceph.conf, poderá modificar os arquivos de configuração no diretório /srv/salt/ceph/configuration/files/ceph.conf.d:

global.conf
mon.conf
mgr.conf
mds.conf
osd.conf
client.conf
rgw.conf

Nota: `Rgw.conf` exclusivo

O Object Gateway oferece muita flexibilidade e é exclusivo em comparação com outras seções do ceph.conf. Todos os outros componentes do Ceph têm cabeçalhos estáticos, como [mon] ou [osd]. O Object Gateway tem cabeçalhos exclusivos, como [client.rgw.rgw1]. Isso significa que o arquivo rgw.conf precisa de uma entrada de cabeçalho. Para ver exemplos, consulte

/srv/salt/ceph/configuration/files/rgw.conf

/srv/salt/ceph/configuration/files/rgw-ssl.conf

Importante: Executar a fase 3

Após fazer mudanças personalizadas nos arquivos de configuração mencionados acima, execute as fases 3 e 4 para aplicá-las aos nós do cluster:

root@master # salt-run state.orch ceph.stage.3
root@master # salt-run state.orch ceph.stage.4

Esses arquivos são incluídos do arquivo de gabarito /srv/salt/ceph/configuration/files/ceph.conf.j2 e correspondem às diferentes seções aceitas pelo arquivo de configuração do Ceph. Ao inserir um trecho da configuração no arquivo correto, o DeepSea pode incluí-lo na seção correta. Você não precisa adicionar nenhum dos cabeçalhos de seção.

Dica

Para aplicar quaisquer opções de configuração apenas às instâncias específicas de um daemon, adicione um cabeçalho como [osd.1]. As seguintes opções de configuração serão aplicadas apenas ao daemon OSD com o ID 1.

2.13.1 Anulando os padrões #

As últimas declarações em uma seção anulam as anteriores. Portanto, é possível anular a configuração padrão conforme especificado no gabarito /srv/salt/ceph/configuration/files/ceph.conf.j2. Por exemplo, para desativar a autenticação do cephx, adicione as três linhas a seguir ao arquivo /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf:

auth cluster required = none
auth service required = none
auth client required = none

Ao redefinir os valores padrão, as ferramentas relacionadas do Ceph, como rados, podem emitir avisos de que os valores específicos do ceph.conf.j2 foram redefinidos no global.conf. Esses avisos são causados por um parâmetro atribuído duas vezes no ceph.conf resultante.

Como uma solução alternativa para este caso específico, siga estas etapas:

Mude o diretório atual para /srv/salt/ceph/configuration/create:
```
root@master # cd /srv/salt/ceph/configuration/create
```
Copie default.sls para custom.sls:
```
root@master # cp default.sls custom.sls
```
Edite custom.sls e mude ceph.conf.j2 para custom-ceph.conf.j2.
Mude o diretório atual para /srv/salt/ceph/configuration/files:
```
root@master # cd /srv/salt/ceph/configuration/files
```

Copie ceph.conf.j2 para custom-ceph.conf.j2:

root@master # cp ceph.conf.j2 custom-ceph.conf.j2

Edite custom-ceph.conf.j2 e apague a seguinte linha:
```
{% include "ceph/configuration/files/rbd.conf" %}
```
Edite global.yml e adicione a seguinte linha:
```
configuration_create: custom
```

Atualize o pillar:

root@master # salt target saltutil.pillar_refresh

Execute a fase 3:

root@master # salt-run state.orch ceph.stage.3

Agora você deve ter apenas uma entrada para cada definição de valor. Para recriar a configuração, execute:

root@master # salt-run state.orch ceph.configuration.create

e, em seguida, verifique o conteúdo de /srv/salt/ceph/configuration/cache/ceph.conf.

2.13.2 Incluindo arquivos de configuração #

Se você precisar aplicar muitas configurações personalizadas, use as seguintes declarações de inclusão nos arquivos de configuração personalizados para facilitar o gerenciamento de arquivos. Veja a seguir um exemplo de arquivo osd.conf:

[osd.1]
{% include "ceph/configuration/files/ceph.conf.d/osd1.conf" ignore missing %}
[osd.2]
{% include "ceph/configuration/files/ceph.conf.d/osd2.conf" ignore missing %}
[osd.3]
{% include "ceph/configuration/files/ceph.conf.d/osd3.conf" ignore missing %}
[osd.4]
{% include "ceph/configuration/files/ceph.conf.d/osd4.conf" ignore missing %}

No exemplo anterior, os arquivos osd1.conf, osd2.conf, osd3.conf e osd4.conf contêm opções de configuração específicas ao OSD relacionado.

Dica: Configuração de tempo de execução

As mudanças feitas nos arquivos de configuração do Ceph entrarão em vigor após a reinicialização dos daemons Ceph relacionados. Consulte a Seção 16.1, “Configuração de tempo de execução” para obter mais informações sobre como mudar a configuração de tempo de execução do Ceph.

2.14 Habilitando perfis do AppArmor #

AppArmor é uma solução de segurança que limita programas por um perfil específico. Para obter mais detalhes, visite https://www.suse.com/documentation/sles-15/book_security/data/part_apparmor.html.

O DeepSea oferece três estados para os perfis do AppArmor: “enforce”, “complain” e “disable”. Para ativar um determinado estado do AppArmor, execute:

salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-STATE

Para colocar os perfis do AppArmor no estado “enforce”:

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-enforce

Para colocar os perfis do AppArmor no estado “complain”:

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-complain

Para desabilitar os perfis do AppArmor:

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-disable

Dica: Habilitação do Serviço AppArmor

Cada uma destas três chamadas verifica se o AppArmor está instalado e o instala, se for o caso. Em seguida, o serviço systemd relacionado é iniciado e habilitado. O DeepSea avisará você se o AppArmor foi instalado e iniciado/habilitado de outra maneira e, portanto, está em execução sem os perfis do DeepSea.

2.15 Desativando perfis ajustados #

Por padrão, o DeepSea implanta os clusters do Ceph com perfis ajustados ativos nos nós do Ceph Monitor, Ceph Manager e Ceph OSD. Em alguns casos, você pode precisar desativar permanentemente os perfis ajustados. Para fazer isso, insira as seguintes linhas no /srv/pillar/ceph/stack/global.yml e execute novamente a fase 3:

alternative_defaults:
 tuned_mgr_init: default-off
 tuned_mon_init: default-off
 tuned_osd_init: default-off

root@master # salt-run state.orch ceph.stage.3

2.16 Removendo um cluster inteiro do Ceph #

O executor ceph.purge remove o cluster inteiro do Ceph. Desta forma, você pode limpar o ambiente do cluster ao testar configurações diferentes. Após a conclusão do ceph.purge, o cluster Salt será revertido ao estado no fim da fase 1 do DeepSea. Em seguida, você poderá mudar o policy.cfg (consulte o Seção 5.5.1, “Arquivo policy.cfg”) ou prosseguir para a fase 2 do DeepSea com a mesma configuração.

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 # salt-run disengage.safety
root@master # salt-run state.orch ceph.purge

Dica: Desabilitação da Remoção do Cluster do Ceph

Para evitar que qualquer pessoa execute o ceph.purge, crie um arquivo denominado disabled.sls no diretório /srv/salt/ceph/purge e insira a linha a seguir no arquivo /srv/pillar/ceph/stack/global.yml:

purge_init: disabled

Importante: Rescindir Funções Personalizadas

Se você já criou funções personalizadas para o Ceph Dashboard (consulte a Seção 22.2.6, “Adicionando funções personalizadas” e a Seção 22.10.2, “Funções e permissões de usuário” para obter informações detalhadas), precisa realizar etapas manuais para purgá-las antes de executar o ceph.purge. Por exemplo, se o nome da função personalizada para o Object Gateway for “us-east-1”, siga estas etapas:

root@master # cd /srv/salt/ceph/rescind
root@master # rsync -a rgw/ us-east-1
root@master # sed -i 's!rgw!us-east-1!' us-east-1/*.sls

Imprimir esta página

Guia de Administração

2 Administração do cluster do Salt #

2.1 Adicionando novos nós do cluster #

Dica: Evitar Redistribuição

Importante: Possível Reinicialização da fase 0 do DeepSea

Dica: Modificação do Layout do OSD

2.2 Adicionando novas funções aos nós #

2.3 Removendo e reinstalando nós do cluster #

Dica: Remoção Temporária de um Nó do Cluster

Nota: Removendo OSDs do Cluster

Nota: Preservando as partições criadas por outros métodos

Exemplo 2.1: Removendo um minion Salt do cluster #

Exemplo 2.2: Migrando nós #

2.4 Reimplantando nós do monitor #

Importante: O Mínimo são Três Nós do Monitor

2.5 Adicionando um disco OSD a um nó #

2.6 Removendo um OSD #

2.6.1 Removendo vários OSDs #

2.6.2 Removendo todos os OSDs de um host #

2.6.3 Removendo à força os OSDs danificados #

Dica: Montagens Travadas

2.6.4 Validando os metadados OSD da LVM #

2.7 Substituindo um disco OSD #

Dica: osd.replace e osd.remove

2.8 Recuperando um nó OSD reinstalado #

2.9 Movendo o nó de admin para um novo servidor #

Dica: Transição de Minions Salt

Dica: Dry Run para rsync e Links Simbólicos

2.10 Instalação automatizada pelo Salt #

Atenção

2.11 Atualizando os nós do cluster #

2.11.1 Repositórios do software #

2.11.2 Propagação em fases do repositório #

2.11.3 zypper patch ou zypper dup #

2.11.4 Reinicializações de nó do cluster #

2.11.5 Tempo de espera dos serviços do Ceph #

2.11.6 Executando a atualização #

2.12 Parando ou reinicializando o cluster #

2.13 Ajustando o ceph.conf com configurações personalizadas #

Nota: Rgw.conf exclusivo

Importante: Executar a fase 3

Dica

2.13.1 Anulando os padrões #

2.13.2 Incluindo arquivos de configuração #

Dica: Configuração de tempo de execução

2.14 Habilitando perfis do AppArmor #

Dica: Habilitação do Serviço AppArmor

2.15 Desativando perfis ajustados #

2.16 Removendo um cluster inteiro do Ceph #

Dica: Desabilitação da Remoção do Cluster do Ceph

Importante: Rescindir Funções Personalizadas

Dica: `osd.replace` e `osd.remove`

Dica: Dry Run para `rsync` e Links Simbólicos

2.11.3 `zypper patch` ou `zypper dup` #

2.13 Ajustando o `ceph.conf` com configurações personalizadas #

Nota: `Rgw.conf` exclusivo