Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Aplica-se a SUSE Enterprise Storage 6

2 Administração do cluster do Salt

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

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

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

    root@master # salt 'SALT_MASTER_NODE' state.apply ceph.configuration.create
  3. Aplique a nova configuração aos minions OSD de destino:

    root@master # salt 'OSD_MINIONS' state.apply ceph.configuration
  4. Após a adição dos novos OSDs, ajuste os pesos deles conforme necessário com o comando ceph osd crush reweight.

  1. 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
  2. No master Salt, aceite a chave salt do novo nó:

    root@master # salt-key --accept NEW_NODE_KEY
  3. 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.

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

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

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

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

  1. 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
  2. Execute a fase 2 para atualizar o pillar:

    root@master # salt-run state.orch ceph.stage.2
  3. 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
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
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
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
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:

  1. 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
    [...]
  2. 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
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.

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

  2. 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
  3. Execute o seguinte comando no nó OSD para remover completamente os metadados da LVM:

    cephadm@osd > ceph-volume lvm zap --osd-id ID --destroy
  4. 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.

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

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

  2. Substitua manualmente a unidade OSD com falha/upgrade.

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

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

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

  2. 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
  3. 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
  4. Execute a fase 0 do DeepSea:

    root@master # salt-run state.orch ceph.stage.0
  5. Reinicialize o nó OSD relevante. Todos os discos OSD serão redescobertos e reutilizados.

  6. Instale e execute o exportador de nó do Prometheus:

    root@master # salt 'RECOVERED_MINION' \
     state.apply ceph.monitoring.prometheus.exporters.node_exporter
  7. 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.

  1. 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
  2. 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
    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
  3. Verifique se o pacote deepsea está instalado e instale-o, se necessário.

    root@master # zypper install deepsea
  4. Personalize o arquivo policy.cfg mudando a linha role-master. Encontre mais detalhes no Seção 5.5.1, “Arquivo policy.cfg.

  5. Sincronize os diretórios /srv/pillar e /srv/salt do Nó de Admin antigo com o novo.

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

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

  1. 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
  2. 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
  3. 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:

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

    cephadm@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 Object Gateway

    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 Object Gateway

    6. Clientes de armazenamento

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

ou

/srv/salt/ceph/configuration/files/rgw-ssl.conf
Importante
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
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:

  1. Mude o diretório atual para /srv/salt/ceph/configuration/create:

    root@master # cd /srv/salt/ceph/configuration/create
  2. Copie default.sls para custom.sls:

    root@master # cp default.sls custom.sls
  3. Edite custom.sls e mude ceph.conf.j2 para custom-ceph.conf.j2.

  4. Mude o diretório atual para /srv/salt/ceph/configuration/files:

    root@master # cd /srv/salt/ceph/configuration/files
  5. Copie ceph.conf.j2 para custom-ceph.conf.j2:

    root@master # cp ceph.conf.j2 custom-ceph.conf.j2
  6. 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
  7. Atualize o pillar:

    root@master # salt target saltutil.pillar_refresh
  8. 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
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
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
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
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