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

5 Fazendo upgrade de versões anteriores

Este capítulo apresenta as etapas de upgrade do SUSE Enterprise Storage de versões anteriores para a atual.

5.1 Ler os detalhes da versão

Nos detalhes da versão, você encontra mais informações sobre o que mudou desde a versão anterior do SUSE Enterprise Storage. Consulte os detalhes da versão para verificar se:

  • seu hardware precisa de considerações especiais.

  • qualquer pacote de software usado foi significativamente modificado.

  • são necessárias precauções especiais para a instalação.

Os detalhes da versão também apresentam informações que não puderam ser incluídas a tempo no manual. Eles também incluem notas sobre problemas conhecidos.

Após instalar o pacote release-notes-ses, encontre os detalhes da versão no diretório local /usr/share/doc/release-notes ou no site https://www.suse.com/releasenotes/.

5.2 Procedimento geral de upgrade

Considere os seguintes itens antes de iniciar o procedimento de upgrade:

Ordem do upgrade

Antes de fazer upgrade do cluster do Ceph, você precisa registrar corretamente o SUSE Linux Enterprise Server e o SUSE Enterprise Storage subjacentes no SCC ou na SMT. Você poderá fazer upgrade dos daemons no cluster enquanto ele estiver online e em execução. Alguns tipos de daemons dependem de outros. Por exemplo, os Ceph Object Gateways dependem dos daemons Ceph Monitors e Ceph OSD. Recomendamos o upgrade nesta ordem:

  1. Ceph Monitors

  2. Ceph Managers

  3. Ceph OSDs

  4. Servidores de Metadados

  5. Object Gateways

  6. iSCSI Gateways

  7. NFS Ganesha

Apagar instantâneos desnecessários do sistema operacional

Remova os instantâneos de sistema de arquivos que não são necessários das partições de nós do sistema operacional. Esse procedimento garante espaço livre suficiente no disco durante o upgrade.

Verificar a saúde do cluster

É recomendável verificar a saúde do cluster antes de iniciar o procedimento de upgrade.

Fazer upgrade individualmente

Recomendamos fazer upgrade de todos os daemons de determinado tipo (por exemplo, todos os daemons monitor ou OSD) um de cada vez para garantir que todos sejam da mesma versão. Recomendamos também fazer upgrade de todos os daemons no cluster antes de você tentar usar uma nova funcionalidade em uma versão.

Após o upgrade de todos os daemons de um tipo específico, verifique o status deles.

Verifique se cada monitor reingressou no quorum após o upgrade de todos os monitores:

root # ceph mon stat

Verifique se cada daemon Ceph OSD reingressou no cluster após o upgrade de todos os OSDs:

root # ceph osd stat
Definir o flag require-osd-release luminous

Quando é feito o upgrade do último OSD para o SUSE Enterprise Storage 5, os nós do monitor detectam que todos os OSDs estão executando a versão “luminous” do Ceph e podem reclamar que o flag require-osd-release luminous do osdmap não está definido. Nesse caso, você precisa definir esse flag manualmente para confirmar que, agora que o upgrade do cluster foi feito para “luminous”, não é possível revertê-lo para a versão menos eficiente “jewel” do Ceph. Defina o flag executando o seguinte comando:

root@minion > sudo ceph osd require-osd-release luminous

Após a conclusão do comando, o aviso desaparecerá.

Nas novas instalações do SUSE Enterprise Storage 5, esse flag é definido automaticamente quando os Ceph Monitors criam o osdmap inicial. Dessa forma, nenhuma ação do usuário final é necessária.

5.3 Criptografando OSDs durante o upgrade

Desde o SUSE Enterprise Storage 5, por padrão, os OSDs são implantados usando o BlueStore em vez do FileStore. Embora o BlueStore suporte criptografia, os Ceph OSDs são implantados sem criptografia, por padrão. O procedimento a seguir descreve as etapas para criptografar os OSDs durante o processo de upgrade. Vamos supor que ambos os discos de dados e WAL/BD que serão usados para implantação do OSD estejam limpos, sem partições. Se os discos já foram usados, limpe-os seguindo o procedimento descrito na Etapa 13.

Importante
Importante: Um OSD de cada vez

Você precisa implantar os OSDs criptografados um por um, não ao mesmo tempo. O motivo disso é que os dados do OSD são esvaziados, e o cluster passa por várias iterações de redistribuição.

  1. Determine os valores bluestore block db size e bluestore block wal size da sua implantação e adicione-os ao arquivo /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf no master Salt. Os valores precisam ser especificados em bytes.

    [global]
    bluestore block db size = 48318382080
    bluestore block wal size = 2147483648

    Para obter mais informações sobre como personalizar o arquivo ceph.conf, consulte o Seção 1.11, “Arquivo ceph.conf personalizado”.

  2. Execute a Fase 3 do DeepSea para distribuir as mudanças:

    root@master # salt-run state.orch ceph.stage.3
  3. Verifique se o arquivo ceph.conf está atualizado nos nós relevantes do OSD:

    root@minion > cat /etc/ceph/ceph.conf
  4. Edite os arquivos *.yml no diretório /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions relevantes aos OSDs que você está criptografando. Compare o caminho deles com o que foi definido no arquivo /srv/pillar/ceph/proposals/policy.cfg para garantir que você modifique os arquivos *.yml corretos.

    Importante
    Importante: Identificadores de disco longo

    Ao identificar discos OSD nos arquivos /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/*.yml, use os identificadores de disco longo.

    Veja a seguir um exemplo de configuração de OSD. Como a criptografia é necessária, as opções db_size e wal_size foram removidas:

    ceph:
     storage:
       osds:
         /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_007027b1065faa972100d34d7aa06d86:
           format: bluestore
           encryption: dmcrypt
           db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
           wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
         /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_00d146b1065faa972100d34d7aa06d86:
           format: bluestore
           encryption: dmcrypt
           db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
           wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
  5. Implante os novos OSDs de Armazenamento em Blocos com criptografia executando as Fases 2 e 3 do DeepSea:

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

    Você poderá observar o andamento com ceph -s ou ceph osd tree. É essencial permitir que o cluster seja redistribuído antes de repetir o processo no próximo nó do OSD.

5.4 Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5

Importante
Importante: Requisitos de software

Você precisa ter o seguinte software instalado e atualizado para as versões mais recentes dos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciar o procedimento de upgrade:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

Além disso, antes de iniciar o upgrade, você precisa fazer upgrade do nó master Salt para o SUSE Linux Enterprise Server 12 SP3 e o SUSE Enterprise Storage 5 executando o comando zypper migration (ou seu método de upgrade preferencial).

Atenção
Atenção: Pontos de consideração antes do upgrade
  • Verifique se o serviço AppArmor está em execução e desabilite-o em cada nó do cluster. Inicie o módulo AppArmor do YaST, selecione Settings (Configurações) e, em seguida, desative a caixa de seleção Enable Apparmor (Habilitar Apparmor). Para confirmar, clique em Done (Concluído).

    O SUSE Enterprise Storage não funcionará com o AppArmor habilitado.

  • Embora o cluster permaneça totalmente funcional durante o upgrade, o DeepSea define o flag "noout", que impede o Ceph de redistribuir os dados durante o tempo de espera e, portanto, evita transferências de dados desnecessárias.

  • Para otimizar o processo de upgrade, o DeepSea faz upgrade dos nós na ordem, com base nas funções atribuídas, conforme recomendado pelo upstream do Ceph: MONs, MGRs, OSDs, MDS, RGW, IGW e NFS Ganesha.

    O DeepSea não poderá evitar que a ordem recomendada seja violada se um nó executar vários serviços.

  • Embora o cluster do Ceph permaneça operacional durante o upgrade, os nós podem ser reinicializados para aplicar novas versões de kernel, por exemplo. Para reduzir as operações de E/S em espera, é recomendável recusar solicitações recebidas durante o processo de upgrade.

  • O upgrade do cluster pode levar muito tempo: aproximadamente o tempo necessário para fazer upgrade de uma máquina multiplicado pelo número de nós do cluster.

  • A partir do Ceph Luminous, a opção de configuração osd crush location não é mais suportada. Atualize os arquivos de configuração do DeepSea para usar crush location antes do upgrade.

Para fazer upgrade do cluster do SUSE Enterprise Storage 4 para a versão 5, siga estas etapas:

  1. Defina a nova ordem de classificação de objetos internos. Execute:

    root # ceph osd set sortbitwise
    Dica
    Dica

    Para verificar se o comando foi bem-sucedido, recomendamos executar

    root # ceph osd dump --format json-pretty | grep sortbitwise
     "flags": "sortbitwise,recovery_deletes,purged_snapdirs",
  2. Usando o rpm -q deepsea, verifique se a versão do pacote do DeepSea no nó master Salt começa com 0.7 no mínimo. Por exemplo:

    root # rpm -q deepsea
    deepsea-0.7.27+git.0.274c55d-5.1

    Se o número da versão do pacote do DeepSea começa com 0.6, verifique se você migrou com êxito o nó master Salt para o SUSE Linux Enterprise Server 12 SP3 e o SUSE Enterprise Storage 5 (consulte Importante: Requisitos de software no início desta seção). Isso se trata de um pré-requisito que deve ser concluído antes de iniciar o procedimento de upgrade.

    1. Se você registrou seus sistemas com o SUSEConnect e usa SCC/SMT, nenhuma outra ação é necessária. Continue na Etapa 4.

    2. Se você não usa SCC/SMT, mas uma ISO de Mídia ou outra fonte de pacote, adicione os seguintes repositórios manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base e SES5 Update. Para fazer isso, você pode usar o comando zypper. Primeiramente, remova todos os repositórios de software existentes, adicione os novos necessários e, por fim, atualize as fontes dos repositórios:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref

      Na sequência, mude os dados do Pillar para usar uma estratégia diferente. Edite

      /srv/pillar/ceph/stack/name_of_cluster/cluster.yml

      e adicione a linha a seguir:

      upgrade_init: zypper-dup
      Dica
      Dica

      A estratégia zypper-dup requer que você adicione manualmente os repositórios de software mais recentes, enquanto a zypper-migration padrão utiliza os repositórios fornecidos pelo SCC/SMT.

  3. Atualize o Pillar:

    root@master # salt target saltutil.sync_all

    Consulte a Seção 4.2.2, “Direcionando os minions” para obter detalhes sobre o destino dos minions Salt.

  4. Verifique se você fez a gravação no Pillar com êxito:

    root@master # salt target pillar.get upgrade_init

    A saída do comando deve espelhar a entrada que você adicionou.

  5. Faça upgrade dos minions Salt:

    root@master # salt target state.apply ceph.updates.salt
  6. Verifique se foi feito o upgrade de todos os minions Salt:

    root@master # salt target test.version
  7. Inclua os minions Salt do cluster. Consulte a Seção 4.2.2, “Direcionando os minions” do Procedimento 4.1, “Executando as fases de implantação” para obter mais detalhes.

  8. Inicie o upgrade do SUSE Linux Enterprise Server e do Ceph:

    root@master # salt-run state.orch ceph.maintenance.upgrade
    Dica
    Dica: Nova execução na reinicialização

    Se o processo resultar em uma reinicialização do master Salt, execute novamente o comando para iniciar outra vez o processo de upgrade dos minions Salt.

  9. Verifique se o AppArmor está desabilitado e parado em todos os nós após o upgrade:

    root # systemctl disable apparmor.service
    systemctl stop apparmor.service
  10. Após o upgrade, os Ceph Managers ainda não estarão instalados. Para atingir um estado saudável do cluster, faça o seguinte:

    1. Execute a Fase 0 para habilitar a API REST do Salt:

      root@master # salt-run state.orch ceph.stage.0
    2. Execute a Fase 1 para criar o subdiretório role-mgr/:

      root@master # salt-run state.orch ceph.stage.1
    3. Edite o policy.cfg conforme descrito na Seção 4.5.1, “Arquivo policy.cfg e adicione uma função do Ceph Manager aos nós em que os Ceph Monitors estão implantados. Adicione também a função do openATTIC a um dos nós do cluster. Consulte o Capítulo 15, openATTIC para obter mais detalhes.

    4. Execute a Fase 2 para atualizar o Pillar:

      root@master # salt-run state.orch ceph.stage.2
    5. Agora, o DeepSea usa uma abordagem diferente para gerar o arquivo de configuração ceph.conf. Consulte o Seção 1.11, “Arquivo ceph.conf personalizado” para obter mais detalhes.

    6. Execute a Fase 3 para implantar Ceph Managers:

      root@master # salt-run state.orch ceph.stage.3
    7. Execute a Fase 4 para configurar o openATTIC apropriadamente:

      root@master # salt-run state.orch ceph.stage.4
    Nota
    Nota: Incompatibilidade de recursos de chave do Ceph

    Em caso de falha no ceph.stage.3 com o erro: "Error EINVAL: entity client.bootstrap-osd exists but caps do not match", significa que os recursos da chave client.bootstrap.osd existente do cluster não são compatíveis com aqueles que o DeepSea está tentando definir. Acima da mensagem de erro, em vermelho, você pode ver um dump do comando ceph auth que falhou. Analise esse comando para verificar o ID da chave e o arquivo que estão sendo usados. No caso do client.bootstrap-osd, o comando será

    root # ceph auth add client.bootstrap-osd \
     -i /srv/salt/ceph/osd/cache/bootstrap.keyring

    Para corrigir recursos de chave incompatíveis, verifique o conteúdo do arquivo de chaveiro que o DeepSea está tentando implantar. Por exemplo:

    cephadm > cat /srv/salt/ceph/osd/cache/bootstrap.keyring
    [client.bootstrap-osd]
         key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
         caps mgr = "allow r"
         caps mon = "allow profile bootstrap-osd"

    Compare-o com a saída de ceph auth get client.bootstrap-osd:

    root # ceph auth get client.bootstrap-osd
    exported keyring for client.bootstrap-osd
    [client.bootstrap-osd]
         key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
         caps mon = "allow profile bootstrap-osd"

    Observe que caps mgr = "allow r” está ausente na última chave. Para corrigir isso, execute:

    root # ceph auth caps client.bootstrap-osd mgr \
     "allow r" mon "allow profile bootstrap-osd"

    Agora, a execução de ceph.stage.3 deve ser bem-sucedida.

    O mesmo problema pode ocorrer com os chaveiros do Servidor de Metadados e do Object Gateway durante a execução do ceph.stage.4. O mesmo procedimento acima deve ser aplicado: verificar o comando que falhou, o arquivo de chaveiro que está sendo implantado e os recursos da chave existente. Em seguida, execute ceph auth caps para atualizar os recursos da chave existente para corresponder aos que o DeepSea está implantando.

Importante
Importante: Falha no upgrade

Se o estado do cluster permanecer como “HEALTH_ERR” por mais do que 300 segundos, ou se um dos serviços para cada função atribuída ficar inativo por mais do que 900 segundos, haverá falha no upgrade. Nesse caso, tente localizar o problema, resolva-o e execute o procedimento de upgrade novamente. Em ambientes virtualizados, observe que os tempos de espera são mais curtos.

Importante
Importante: Reinicializando os OSDs

Após o upgrade do SUSE Enterprise Storage 5, os OSDs do FileStore precisarão de aproximadamente cinco minutos a mais para serem iniciados, já que o OSD fará uma conversão única de seus arquivos no disco.

Dica
Dica: Verificar a versão dos componentes/nós do cluster

Quando você precisa saber as versões dos componentes e nós individuais do cluster (por exemplo, para saber se todos os seus nós estão realmente no mesmo nível de patch após o upgrade), você pode executar

root@master # salt-run status.report

O comando analisa os minions Salt conectados, verifica os números de versão do Ceph, Salt e SUSE Linux Enterprise Server e apresenta um relatório a você com a versão da maioria dos nós e os nós que têm uma versão diferente da maioria.

5.4.1 Migração do OSD para BlueStore

O OSD do BlueStore é um novo back end para os daemons OSD. Ele é a opção padrão desde o SUSE Enterprise Storage 5. Comparado com o FileStore, que armazena objetos como arquivos em um sistema de arquivos XFS, o BlueStore pode proporcionar melhor desempenho, porque armazena os objetos diretamente no dispositivo de blocos subjacente. O BlueStore também disponibiliza outros recursos, como compactação incorporada e sobregravações EC, que não estão disponíveis no FileStore.

Especificamente no BlueStore, um OSD tem um dispositivo “wal” (Registro Write-Ahead) e um dispositivo “db” (banco de dados RocksDB). O banco de dados RocksDB armazena os metadados para um OSD do BlueStore. Por padrão, esses dois dispositivos residirão no mesmo dispositivo como um OSD, mas qualquer um deles pode ser inserido em uma mídia mais rápida ou diferente.

No SES5, tanto o FileStore quanto o BlueStore são suportados, e os OSDs do FileStore e do BlueStore podem coexistir em um único cluster. Durante o procedimento de upgrade do SUSE Enterprise Storage, os OSDs do FileStore não são convertidos automaticamente em BlueStore. Os recursos específicos do BlueStore não estarão disponíveis nos OSDs que não foram migrados para o BlueStore.

Antes da conversão em BlueStore, os OSDs precisam executar o SUSE Enterprise Storage 5. A conversão é um processo lento, pois todos os dados são regravados duas vezes. O processo de migração pode levar muito tempo para ser concluído, mas não há nenhuma interrupção do cluster, e todos os clientes podem continuar acessando o cluster durante esse período. No entanto, é comum uma redução no desempenho durante a migração. Isso é causado pela redistribuição e preenchimento de dados dos cluster.

Siga o procedimento abaixo para migrar os OSDs do FileStore para o BlueStore:

Dica
Dica: Desativar medidas de segurança

Os comandos do Salt necessários para executar a migração são bloqueados por medidas de segurança. Para desativar essa medida preventiva, execute o seguinte comando:

root@master # salt-run disengage.safety
  1. Migre os perfis de hardware:

    root@master # salt-run state.orch ceph.migrate.policy

    Esse executor migra quaisquer perfis de hardware que o arquivo policy.cfg usa atualmente. Ele processa o policy.cfg, encontra qualquer perfil de hardware que usa a estrutura de dados original e converte-a na nova estrutura de dados. O resultado é um novo perfil de hardware chamado “migrated-nome_original”. O policy.cfg também é atualizado.

    Se a configuração original tinha diários separados, a configuração do BlueStore usará o mesmo dispositivo do “wal” e do “db” para esse OSD.

  2. O DeepSea migra os OSDs definindo o peso deles como 0, o que “aspira” os dados até esvaziar o OSD. Você pode migrar os OSDs um por um ou todos ao mesmo tempo. Em qualquer um dos casos, quando o OSD estiver vazio, a orquestração o removerá e o recriará com a nova configuração.

    Dica
    Dica: Método recomendado

    Use ceph.migrate.nodes se você tiver um grande número de nós de armazenamento físico ou poucos dados. Se um nó representa menos do que 10% da sua capacidade, o ceph.migrate.nodes pode ser um pouco mais rápido para mover todos os dados desses OSDs em paralelo.

    Se você não tem certeza sobre qual método usar, ou se o site tem poucos nós de armazenamento (por exemplo, cada nó tem mais do que 10% dos dados do cluster), selecione ceph.migrate.osds.

    1. Para migrar os OSDs um de cada vez, execute:

      root@master # salt-run state.orch ceph.migrate.osds
    2. Para migrar todos os OSDs em cada nó em paralelo, execute:

      root@master # salt-run state.orch ceph.migrate.nodes
    Dica
    Dica

    Como a orquestração não apresenta comentários sobre o andamento da migração, use

    root # ceph osd tree

    para ver quais OSDs têm um peso de zero periodicamente.

Após a migração para o BlueStore, o total de objetos permanecerá o mesmo, e a utilização do disco será quase igual.

5.5 Upgrade do SUSE Enterprise Storage 4 (implantação do ceph-deploy) para 5

Importante
Importante: Requisitos de software

Você precisa ter o seguinte software instalado e atualizado para as versões mais recentes dos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciar o procedimento de upgrade:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

Escolha o master Salt para seu cluster. Se o Calamari está implantado no cluster, o nó Calamari já é o master Salt. Como alternativa, o nó de admin do qual você executou o comando ceph-deploy se tornará o master Salt.

Antes de iniciar o procedimento a seguir, você precisa fazer upgrade do nó master Salt para o SUSE Linux Enterprise Server 12 SP3 e o SUSE Enterprise Storage 5 executando o comando zypper migration (ou seu método de upgrade preferencial).

Para fazer upgrade do cluster do SUSE Enterprise Storage 4 que foi implantado com ceph-deploy para a versão 5, siga estas etapas:

Procedimento 5.1: Etapas para aplicar a todos os nós do cluster (incluindo o nó Calamari)
  1. Instale o pacote salt do SLE-12-SP2/SES4:

    root # zypper install salt
  2. Instale o pacote salt-minion do SLE-12-SP2/SES4, habilite e inicie o serviço relacionado:

    root # zypper install salt-minion
    root # systemctl enable salt-minion
    root # systemctl start salt-minion
  3. Verifique se o nome de host “salt” é resolvido para o endereço IP do nó master Salt. Se o master Salt não puder ser acessado pelo nome de host salt, edite o arquivo /etc/salt/minion ou crie um novo arquivo /etc/salt/minion.d/master.conf com o seguinte conteúdo:

    master: host_name_of_salt_master
    Dica
    Dica

    Os minions Salt existentes já têm a opção master: definida em /etc/salt/minion.d/calamari.conf. O nome do arquivo de configuração não importa, o diretório /etc/salt/minion.d/ é importante.

    Se você efetuou quaisquer mudanças nos arquivos de configuração mencionados acima, reinicie o serviço Salt em todos os minions Salt:

    root@minion > systemctl restart salt-minion.service
    1. Se você registrou seus sistemas com o SUSEConnect e usa SCC/SMT, nenhuma outra ação é necessária.

    2. Se você não usa SCC/SMT, mas uma ISO de Mídia ou outra fonte de pacote, adicione os seguintes repositórios manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base e SES5 Update. Para fazer isso, você pode usar o comando zypper. Primeiramente, remova todos os repositórios de software existentes, adicione os novos necessários e, por fim, atualize as fontes dos repositórios:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref
Procedimento 5.2: Etapas para aplicar ao nó master Salt
  1. Defina a nova de ordem de classificação de objetos internos. Execute:

    root@master # ceph osd set sortbitwise
    Dica
    Dica

    Para verificar se o comando foi bem-sucedido, recomendamos executar

    root@master # ceph osd dump --format json-pretty | grep sortbitwise
     "flags": "sortbitwise,recovery_deletes,purged_snapdirs",
  2. Faça upgrade do nó master Salt para o SUSE Linux Enterprise Server 12 SP3 e o SUSE Enterprise Storage 5. Para os sistemas registrados pelo SCC, use zypper migration. Se você inserir manualmente os repositórios de software necessários, use zypper dup. Após o upgrade, verifique se apenas os repositórios do SUSE Linux Enterprise Server 12 SP3 e do SUSE Enterprise Storage 5 estão ativos (e atualizados) no nó master Salt antes de prosseguir.

  3. Se ele ainda não estiver presente, instale o pacote salt-master, habilite e inicie o serviço relacionado:

    root@master # zypper install salt-master
    root@master # systemctl enable salt-master
    root@master # systemctl start salt-master
  4. Verifique a presença de todos os minions Salt listando suas chaves:

    root@master # salt-key -L
  5. Adicione todas as chaves dos minions Salt ao master Salt incluindo o master minion:

    root@master # salt-key -A -y
  6. Verifique se as chaves de todos os minions Salt foram aceitas:

    root@master # salt-key -L
  7. Confirme se o software em seu nó master Salt está atualizado:

    root@master # zypper migration
  8. Instale o pacote deepsea:

    root@master # zypper install deepsea
  9. Inclua os minions Salt do cluster. Consulte a Seção 4.2.2, “Direcionando os minions” do Procedimento 4.1, “Executando as fases de implantação” para obter mais detalhes.

  10. Importe o cluster instalado pelo ceph-deploy existente:

    root@master # salt-run populate.engulf_existing_cluster

    O comando fará o seguinte:

    • Distribuirá todos os módulos do Salt e DeepSea necessários para todos os minions Salt.

    • Inspecionará o cluster do Ceph em execução e preencherá /srv/pillar/ceph/proposals com um layout do cluster.

      O /srv/pillar/ceph/proposals/policy.cfg será criado com as funções correspondentes a todos os serviços do Ceph em execução detectados. Veja esse arquivo para verificar se cada um dos nós MON, OSD, RGW e MDS existentes tem as funções apropriadas. Os nós OSD serão importados para o subdiretório profile-import/, portanto, você pode examinar os arquivos em /srv/pillar/ceph/proposals/profile-import/cluster/ e /srv/pillar/ceph/proposals/profile-import/stack/default/ceph/minions/ para confirmar se os OSDs foram capturados corretamente.

      Nota
      Nota

      O policy.cfg gerado apenas aplicará as funções dos serviços do Ceph detectados “role-mon”, “role-mgr”, “role-mds”, “role-rgw”, “role-admin” e “role-master” referentes ao nó master Salt. Quaisquer outras funções desejadas deverão ser adicionadas manualmente ao arquivo (consulte a Seção 4.5.1.2, “Atribuição de função”).

    • O ceph.conf do cluster existente será gravado em /srv/salt/ceph/configuration/files/ceph.conf.import.

    • O /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml incluirá o fsid do cluster, o cluster e as redes públicas, além de especificar a opção configuration_init: default-import, que faz o DeepSea usar o arquivo de configuração ceph.conf.import mencionado anteriormente, em vez de usar o gabarito /srv/salt/ceph/configuration/files/ceph.conf.j2 padrão do DeepSea.

      Nota
      Nota: Ceph.conf personalizado

      Se você precisa integrar o arquivo ceph.conf com mudanças personalizadas, aguarde a conclusão bem-sucedida do processo de importação/upgrade. Em seguida, edite o arquivo /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml e comente na seguinte linha:

      configuration_init: default-import

      Grave o arquivo e siga as informações no Seção 1.11, “Arquivo ceph.conf personalizado”.

    • Os vários chaveiros do cluster serão gravados nos seguintes diretórios:

      /srv/salt/ceph/admin/cache/
      /srv/salt/ceph/mon/cache/
      /srv/salt/ceph/osd/cache/
      /srv/salt/ceph/mds/cache/
      /srv/salt/ceph/rgw/cache/

      Verifique se os arquivos de chaveiro existem e se não há um arquivo de chaveiro no seguinte diretório (o Ceph Manager não existia antes do SUSE Enterprise Storage 5):

      /srv/salt/ceph/mgr/cache/
  11. O comando salt-run populate.engulf_existing_cluster não consegue importar a configuração do openATTIC. Você precisa editar manualmente o arquivo policy.cfg e adicionar uma linha role-openattic. Consulte a Seção 4.5.1, “Arquivo policy.cfg para obter mais detalhes.

  12. O comando salt-run populate.engulf_existing_cluster não consegue importar as configurações de iSCSI Gateways. Se o cluster inclui iSCSI Gateways, importe as configurações manualmente:

    1. Em um dos nós do iSCSI Gateway, exporte o lrbd.conf atual e copie-o para o nó master Salt:

      root@minion > lrbd -o >/tmp/lrbd.conf
      root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
    2. No nó master Salt, adicione a configuração padrão do iSCSI Gateway à configuração do DeepSea:

      root@master # mkdir -p /srv/pillar/ceph/stack/ceph/
      root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.yml
      root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
    3. Adicione as funções do iSCSI Gateway ao policy.cfg e grave o arquivo:

      role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml
      role-igw/cluster/ses-1.ses.suse.sls
      [...]
  13. Execute a Fase 1 para criar todas as funções possíveis:

    root@master # salt-run state.orch ceph.stage.1
  14. Gere os subdiretórios necessários em /srv/pillar/ceph/stack:

    root@master # salt-run push.proposal
  15. Verifique se existe um cluster gerenciado pelo DeepSea em execução com as funções corretamente atribuídas:

    root@master # salt target pillar.get roles

    Compare a saída com o layout real do cluster.

  16. O Calamari deixa uma tarefa programada do Salt em execução para verificar o status do cluster. Remova a tarefa:

    root@minion > salt target schedule.delete ceph.heartbeat
  17. A partir deste ponto, siga o procedimento descrito na Seção 5.4, “Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5”.

5.6 Upgrade do SUSE Enterprise Storage 4 (implantação do Crowbar) para 5

Importante
Importante: Requisitos de software

Você precisa ter o seguinte software instalado e atualizado para as versões mais recentes dos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciar o procedimento de upgrade:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

Para fazer upgrade do SUSE Enterprise Storage 4 implantado por meio do Crowbar para a versão 5, siga estas etapas:

  1. Para cada nó do Ceph (incluindo o nó Calamari), interrompa e desabilite todos os serviços relacionados ao Crowbar:

    root@minion > sudo systemctl stop chef-client
    root@minion > sudo systemctl disable chef-client
    root@minion > sudo systemctl disable crowbar_join
    root@minion > sudo systemctl disable crowbar_notify_shutdown
  2. Para cada nó do Ceph (incluindo o nó Calamari), verifique se os repositórios de software apontam para os produtos SUSE Enterprise Storage 5 e SUSE Linux Enterprise Server 12 SP3. Se ainda houver repositórios apontando para versões mais antigas do produto, desabilite-os.

  3. Para cada nó do Ceph (incluindo o nó Calamari), verifique se o salt-minion está instalado. Se não estiver, instale-o:

    root@minion > sudo zypper in salt salt-minion
  4. Para os nós do Ceph sem o pacote salt-minion instalado, crie o arquivo /etc/salt/minion.d/master.conf com a opção master apontando para o nome completo do host do nó Calamari:

    master: full_calamari_hostname
    Dica
    Dica

    Os minions Salt existentes já têm a opção master: definida em /etc/salt/minion.d/calamari.conf. O nome do arquivo de configuração não importa, o diretório /etc/salt/minion.d/ é importante.

    Habilite e inicie o serviço salt-minion:

    root@minion > sudo systemctl enable salt-minion
    root@minion > sudo systemctl start salt-minion
  5. No nó Calamari, aceite quaisquer chaves de minion Salt restantes:

    root@master # salt-key -L
    [...]
    Unaccepted Keys:
    d52-54-00-16-45-0a.example.com
    d52-54-00-70-ac-30.example.com
    [...]
    
    root@master # salt-key -A
    The following keys are going to be accepted:
    Unaccepted Keys:
    d52-54-00-16-45-0a.example.com
    d52-54-00-70-ac-30.example.com
    Proceed? [n/Y] y
    Key for minion d52-54-00-16-45-0a.example.com accepted.
    Key for minion d52-54-00-70-ac-30.example.com accepted.
  6. Se o Ceph foi implantado na rede pública, e não há uma interface VLAN presente, adicione uma interface VLAN na rede pública do Crowbar ao nó Calamari.

  7. Faça upgrade do nó Calamari para o SUSE Linux Enterprise Server 12 SP3 e o SUSE Enterprise Storage 5, usando o comando zypper migration ou o método de sua preferência. A partir deste ponto, o nó Calamari torna-se o master Salt. Após o upgrade, reinicialize o master Salt.

  8. Instale o DeepSea no master Salt:

    root@master # zypper in deepsea
  9. Especifique a opção deepsea_minions para incluir o grupo correto de minions Salt nas fases de implantação. Consulte a Seção 4.2.2.3, “Definir a opção deepsea_minions para obter mais detalhes.

  10. O DeepSea espera que todos os nós do Ceph tenham um /etc/ceph/ceph.conf idêntico. O Crowbar implanta um ceph.conf levemente diferente em cada nó, portanto, você precisa consolidá-lo:

    • Remova a opção osd crush location hook que foi incluída pelo Calamari.

    • Remova a opção public addr da seção [mon].

    • Remova os números de porta da opção mon host.

  11. Se você estava executando o Object Gateway, o Crowbar implantou um arquivo /etc/ceph/ceph.conf.radosgw à parte para manter os segredos do Keystone separados do arquivo ceph.conf regular. O Crowbar também adicionou um arquivo /etc/systemd/system/ceph-radosgw@.service personalizado. Como o DeepSea não oferece suporte a ele, é necessário removê-lo:

    • Anexe todas as seções [client.rgw....] do arquivo ceph.conf.radosgw ao /etc/ceph/ceph.conf em todos os nós.

    • No nó do Object Gateway, execute o seguinte:

      root@minion > rm /etc/systemd/system/ceph-radosgw@.service
      systemctl reenable ceph-radosgw@rgw.public.$hostname
  12. Verifique se o ceph status funciona quando executado do master Salt:

    root@master # ceph status
    cluster a705580c-a7ae-4fae-815c-5cb9c1ded6c2
    health HEALTH_OK
    [...]
  13. Importe o cluster existente:

    root@master # salt-run populate.engulf_existing_cluster
    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run push.proposal
  14. O comando salt-run populate.engulf_existing_cluster não consegue importar as configurações de iSCSI Gateways. Se o cluster inclui iSCSI Gateways, importe as configurações manualmente:

    1. Em um dos nós do iSCSI Gateway, exporte o lrbd.conf atual e copie-o para o nó master Salt:

      root@minion > lrbd -o > /tmp/lrbd.conf
      root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
    2. No nó master Salt, adicione a configuração padrão do iSCSI Gateway à configuração do DeepSea:

      root@master # mkdir -p /srv/pillar/ceph/stack/ceph/
      root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.yml
      root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
    3. Adicione as funções do iSCSI Gateway ao policy.cfg e grave o arquivo:

      role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml
      role-igw/cluster/ses-1.ses.suse.sls
      [...]
    1. Se você registrou seus sistemas com o SUSEConnect e usa SCC/SMT, nenhuma outra ação é necessária.

    2. Se você não usa SCC/SMT, mas uma ISO de Mídia ou outra fonte de pacote, adicione os seguintes repositórios manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base e SES5 Update. Para fazer isso, você pode usar o comando zypper. Primeiramente, remova todos os repositórios de software existentes, adicione os novos necessários e, por fim, atualize as fontes dos repositórios:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref

      Na sequência, mude os dados do Pillar para usar uma estratégia diferente. Editar

      /srv/pillar/ceph/stack/name_of_cluster/cluster.yml

      e adicione a linha a seguir:

      upgrade_init: zypper-dup
      Dica
      Dica

      A estratégia zypper-dup requer que você adicione manualmente os repositórios de software mais recentes, enquanto a zypper-migration padrão utiliza os repositórios fornecidos pelo SCC/SMT.

  15. Corrija os grains do host para fazer com que o DeepSea use nomes de host curtos na rede pública para os IDs de instância do daemon Ceph. Para cada nó, você precisa executar grains.set com o novo nome de host (curto). Antes de executar grains.set, verifique as instância atuais do monitor usando o comando ceph status. Veja a seguir um exemplo de antes e depois:

    root@master # salt target grains.get host
    d52-54-00-16-45-0a.example.com:
        d52-54-00-16-45-0a
    d52-54-00-49-17-2a.example.com:
        d52-54-00-49-17-2a
    d52-54-00-76-21-bc.example.com:
        d52-54-00-76-21-bc
    d52-54-00-70-ac-30.example.com:
        d52-54-00-70-ac-30
    root@master # salt d52-54-00-16-45-0a.example.com grains.set \
     host public.d52-54-00-16-45-0a
    root@master # salt d52-54-00-49-17-2a.example.com grains.set \
     host public.d52-54-00-49-17-2a
    root@master # salt d52-54-00-76-21-bc.example.com grains.set \
     host public.d52-54-00-76-21-bc
    root@master # salt d52-54-00-70-ac-30.example.com grains.set \
     host public.d52-54-00-70-ac-30
    root@master # salt target grains.get host
    d52-54-00-76-21-bc.example.com:
        public.d52-54-00-76-21-bc
    d52-54-00-16-45-0a.example.com:
        public.d52-54-00-16-45-0a
    d52-54-00-49-17-2a.example.com:
        public.d52-54-00-49-17-2a
    d52-54-00-70-ac-30.example.com:
        public.d52-54-00-70-ac-30
  16. Execute o upgrade:

    root@master # salt target state.apply ceph.updates
    root@master # salt target test.version
    root@master # salt-run state.orch ceph.maintenance.upgrade

    Todos os nós serão reinicializados. O cluster retornará com a reclamação de que não há uma instância ativa do Ceph Manager. Isso costuma acontecer. Neste ponto, o Calamari não deve mais ser instalado/estar em execução.

  17. Execute todas as fases de implantação necessárias para atingir um estado saudável do cluster:

    root@master # salt-run state.orch ceph.stage.0
    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
  18. Para implantar o openATTIC (consulte o Capítulo 15, openATTIC), adicione a linha role-openattic apropriada (consulte a Seção 4.5.1.2, “Atribuição de função”) ao /srv/pillar/ceph/proposals/policy.cfg. Em seguida, execute:

    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.4
  19. Durante o upgrade, você pode receber erros do tipo: "Error EINVAL: entity [...] exists but caps do not match". Para resolvê-los, consulte a Seção 5.4, “Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5”.

  20. Efetue a limpeza restante:

    • O Crowbar cria entradas em /etc/fstab para cada OSD. Elas não são necessárias, portanto, apague-as.

    • O Calamari deixa uma tarefa programada do Salt em execução para verificar o status do cluster. Remova a tarefa:

      root@master # salt target schedule.delete ceph.heartbeat
    • Ainda restam alguns pacotes desnecessários instalados, a maioria deles relacionada a ruby gems e chef. Não é necessário removê-los, mas convém apagá-los executando zypper rm nome_pct.

5.7 Upgrade do SUSE Enterprise Storage 3 para 5

Importante
Importante: Requisitos de software

Você precisa ter o seguinte software instalado e atualizado para as versões mais recentes dos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciar o procedimento de upgrade:

  • SUSE Linux Enterprise Server 12 SP1

  • SUSE Enterprise Storage 3

Para fazer upgrade do cluster do SUSE Enterprise Storage 3 para a versão 5, siga as etapas descritas no Procedimento 5.1, “Etapas para aplicar a todos os nós do cluster (incluindo o nó Calamari)” e no Procedimento 5.2, “Etapas para aplicar ao nó master Salt”.

Imprimir esta página