Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com › Documentação do SUSE Enterprise Storage 6 › Guia de Implantação › Implantação e upgrade do cluster › Fazendo upgrade de versões anteriores
ConteúdoConteúdo
Guia de Implantação
  1. Sobre este guia
  2. I SUSE Enterprise Storage
    1. 1 SUSE Enterprise Storage 6 e Ceph
    2. 2 Requisitos e recomendações de hardware
    3. 3 Configuração de alta disponibilidade do nó de admin do
    4. 4 Privilégios de usuário e prompts de comando
  3. II Implantação e upgrade do cluster
    1. 5 Implantando com o DeepSea/Salt
    2. 6 Fazendo upgrade de versões anteriores
    3. 7 Personalizando a configuração padrão
  4. III Instalação de serviços adicionais
    1. 8 Instalação de serviços para acessar seus dados
    2. 9 Ceph Object Gateway
    3. 10 Instalação do iSCSI Gateway
    4. 11 Instalação do CephFS
    5. 12 Instalação do NFS Ganesha
  5. IV Implantação do cluster no SUSE CaaS Platform 4 (Technology Preview)
    1. 13 SUSE Enterprise Storage 6 no cluster Kubernetes do SUSE CaaS Platform 4
  6. A Atualizações de manutenção do Ceph baseadas nos point releases de upstream do “Nautilus”
  7. Glossário
  8. B Atualizações da documentação
Navegação←→
documentation.suse.com › Documentação do SUSE Enterprise Storage 6 › Guia de Implantação › Implantação e upgrade do cluster › Fazendo upgrade de versões anteriores
Topo
←→
Aplica-se a SUSE Enterprise Storage 6

6 Fazendo upgrade de versões anteriores

6.1 Pontos de consideração antes do upgrade
6.2 Fazendo backup de dados do cluster
6.3 Migrando do ntpd para o chronyd
6.4 Corrigindo o cluster antes do upgrade
6.5 Verificando o ambiente atual
6.6 Verificando o estado do cluster
6.7 Fazendo upgrade offline dos clusters CTDB
6.8 Fazendo upgrade por nó: procedimento básico
6.9 Fazendo upgrade do nó de admin
6.10 Fazendo upgrade dos nós do Ceph Monitor/Ceph Manager
6.11 Fazendo upgrade dos servidores de metadados
6.12 Fazendo upgrade dos Ceph OSDs
6.13 Migração do OSD para BlueStore
6.14 Fazendo upgrade dos nós do aplicativo
6.15 Atualizando o policy.cfg e implantando o Ceph Dashboard por meio do DeepSea
6.16 Migrando de implantações com base no perfil para DriveGroups

Este capítulo apresenta as etapas para fazer upgrade do SUSE Enterprise Storage 5.5 para a versão 6. Observe que a versão 5.5 é basicamente a versão 5 com todos os patches mais recentes aplicados.

Nota
Nota: Upgrade de Versões Mais Antigas Não Suportado

O upgrade de versões do SUSE Enterprise Storage mais antigas do que a 5.5 não é suportado. Você precisa primeiro fazer upgrade para a versão mais recente do SUSE Enterprise Storage 5.5 e, em seguida, seguir as etapas neste capítulo.

6.1 Pontos de consideração antes do upgrade

  • Leia os detalhes da versão: onde 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/.

  • Se você fez upgrade da versão 4, verifique se o upgrade para a versão 5 foi concluído com êxito:

    • Verifique a existência do arquivo 

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

      Ele é criado pelo processo de importação durante o upgrade do SES 4 para 5. A opção configuration_init: default-import também está definida no arquivo 

      /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml

      Se configuration_init ainda está definido como default-import, o cluster usa ceph.conf.import como arquivo de configuração, e não o ceph.conf padrão do DeepSea, que é compilado dos arquivos em 

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

      Portanto, você precisa inspecionar se há qualquer configuração personalizada em ceph.conf.import e, possivelmente, mover a configuração para um dos arquivos em 

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

      Em seguida, remova a linha configuration_init: default-import de 

      /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
      Atenção
      Atenção: Configuração Padrão do DeepSea

      Se você não fundir a configuração do ceph.conf.import e remover a opção configuration_init: default-import, nenhuma configuração padrão que fizer parte do DeepSea (armazenada em /srv/salt/ceph/configuration/files/ceph.conf.j2) será aplicada ao cluster.

    • Verifique se o cluster usa o novo tipo de compartimento de memória “straw2”: 

      cephadm@adm > ceph osd crush dump | grep straw

    • Verifique se o perfil “jewel” do Ceph foi usado: 

      cephadm@adm > ceph osd crush dump | grep profile

  • Caso os clientes RBD antigos do kernel (mais antigos do que o SUSE Linux Enterprise Server 12 SP3) sejam usados, consulte o Seção 12.9, “Mapeando o RBD por meio de clientes antigos do kernel”. Recomendamos fazer upgrade dos clientes RBD antigos do kernel, se possível.

  • Se o openATTIC estiver localizado no Nó de Admin, ele estará disponível após o upgrade do nó. O novo Ceph Dashboard não estará disponível até você implantá-lo usando o DeepSea.

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

  • Não é possível fazer upgrade de um único nó durante a execução da versão anterior do SUSE Linux Enterprise Server, mas ele precisa ser reinicializado no instalador da nova versão. Portanto, os serviços que o nó fornece estarão indisponíveis por algum tempo. Os principais serviços do cluster ainda estarão disponíveis. Por exemplo, se um MON estiver inativo durante o upgrade, ainda haverá pelo menos dois MONs ativos. Os serviços de instância única estarão indisponíveis. Por exemplo, um único iSCSI Gateway.

  • Alguns tipos de daemons dependem de outros. Por exemplo, os Ceph Object Gateways dependem dos daemons Ceph MON e OSD. Recomendamos o upgrade nesta ordem:

    1. Nó de Admin

    2. Ceph Monitors/Ceph Managers

    3. Servidores de Metadados

    4. Ceph OSDs

    5. Object Gateways

    6. iSCSI Gateways

    7. NFS Ganesha

    8. Gateways do Samba

  • Se você usou o AppArmor no modo "complain" ou "enforce", precisa definir uma variável do pillar Salt antes do upgrade. Como o SUSE Linux Enterprise Server 15 SP1 está incluído com o AppArmor por padrão, o gerenciamento do AppArmor foi integrado à fase 0 do DeepSea. O comportamento padrão no SUSE Enterprise Storage 6 é remover o AppArmor e os perfis relacionados. Para manter o comportamento configurado no SUSE Enterprise Storage 5.5, verifique se uma das seguintes linhas está presente no arquivo /srv/pillar/ceph/stack/global.yml antes de iniciar o upgrade: 

    apparmor_init: default-enforce

    ou 

    apparmor_init: default-complain

  • A partir do SUSE Enterprise Storage 6, os nomes de MDS que começam com um dígito não são mais permitidos, e os daemons MDS se recusarão a ser iniciados. Você pode verificar se seus daemons têm esses nomes executando o comando ceph fs status ou reiniciando um MDS e verificando a seguinte mensagem nos registros dele: 

    deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden in
a future version.  MDS names may not start with a numeric digit.

    Se aparecer a mensagem acima, os nomes de MDS precisarão ser migrados antes de tentar fazer upgrade para o SUSE Enterprise Storage 6. O DeepSea inclui uma orquestração para automatizar esse tipo de migração. Os nomes de MDS que começam com um dígito receberão o prefixo “mds”.: 

    root@master # salt-run state.orch ceph.mds.migrate-numerical-names
    Dica
    Dica: Configuração Personalizada Vinculada a Nomes MDS

    Se você tem configurações vinculadas a nomes MDS e seus daemons MDS têm nomes que começam com um dígito, verifique se as configurações também se aplicam aos novos nomes (com o prefixo “mds”). Considere a seguinte seção de exemplo no arquivo /etc/ceph/ceph.conf: 

    [mds.123-my-mds] # config setting specific to MDS name with a name starting with a digit
mds cache memory limit = 1073741824
mds standby for name = 456-another-mds

    O orquestrator ceph.mds.migrate-numerical-names mudará o nome do daemon MDS “123-my-mds” para “mds.123-my-mds”. Você precisa ajustar a configuração para refletir o novo nome: 

    [mds.mds,123-my-mds] # config setting specific to MDS name with the new name
mds cache memory limit = 1073741824
mds standby for name = mds.456-another-mds

    Esse procedimento adicionará os daemons MDS com os novos nomes antes de remover os daemons MDS antigos. O número de daemons MDS será o dobro por um curto período. Os clientes poderão acessar o CephFS com uma breve pausa para failover. Portanto, planeje a migração para momentos em que você espera pouca ou nenhuma carga do CephFS.

6.2 Fazendo backup de dados do cluster

Embora a criação de backups da configuração e dos dados de um cluster não seja obrigatória, recomendamos enfaticamente o backup de arquivos de configuração e dados do cluster importantes. Consulte a Capítulo 3, Fazendo backup da configuração e dos dados do cluster para obter mais detalhes.

6.3 Migrando do ntpd para o chronyd

O SUSE Linux Enterprise Server 15 SP1 não usa mais o ntpd para sincronizar o horário local do host. Em vez disso, ele usa o chronyd. Você precisa migrar o daemon de sincronização de horário em cada nó do cluster. Você pode migrar para o chronyd antes do cluster ou fazer upgrade do cluster e, depois disso, migrar para o chronyd.

Procedimento 6.1: Migrar para o chronyd antes do Upgrade do Cluster

  1. Instale o pacote chrony : 

    root@minion > zypper install chrony

  2. Edite o arquivo de configuração do chronyd /etc/chrony.conf e adicione fontes de NTP da configuração atual do ntpd ao /etc/ntp.conf.

    Dica
    Dica: Mais Detalhes sobre a Configuração do chronyd

    Visite https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html para encontrar mais detalhes sobre como incluir fontes de horário na configuração do chronyd.

  3. Desabilite e pare o serviço ntpd: 

    root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

  4. Inicie e habilite o serviço chronyd: 

    root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

  5. Verifique o status do chrony: 

    root@minion > chronyc tracking
Procedimento 6.2: Migrar para o chronyd após o Upgrade do Cluster

  1. Durante o upgrade do cluster, adicione os seguintes repositórios de software:

    • SLE-Module-Legacy15-SP1-Pool

    • SLE-Module-Legacy15-SP1-Updates

  2. Faça upgrade do cluster para a versão 6.

  3. Edite o arquivo de configuração do chronyd /etc/chrony.conf e adicione fontes de NTP da configuração atual do ntpd ao /etc/ntp.conf.

    Dica
    Dica: Mais Detalhes sobre a Configuração do chronyd

    Visite https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html para encontrar mais detalhes sobre como incluir fontes de horário na configuração do chronyd.

  4. Desabilite e pare o serviço ntpd: 

    root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

  5. Inicie e habilite o serviço chronyd: 

    root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

  6. Migre do ntpd para o chronyd.

  7. Verifique o status do chrony: 

    root@minion > chronyc tracking

  8. Remova os repositórios de software legados que você adicionou para manter o ntpd no sistema durante o processo de upgrade.

6.4 Corrigindo o cluster antes do upgrade

Aplique os patches mais recentes a todos os nós do cluster antes do upgrade.

6.4.1 Repositórios de software necessários

Verifique se os repositórios necessários estão configurados em cada nó do cluster. Para listar todos os repositórios disponíveis, execute 

root@minion > zypper lr

O SUSE Enterprise Storage 5.5 requer:

  • SLES12-SP3-Installer-Updates

  • SLES12-SP3-Pool

  • SLES12-SP3-Updates

  • SUSE-Enterprise-Storage-5-Pool

  • SUSE-Enterprise-Storage-5-Updates

O Gateway NFS/SMB no SLE-HA no SUSE Linux Enterprise Server 12 SP3 requer:

  • SLE-HA12-SP3-Pool

  • SLE-HA12-SP3-Updates

6.4.2 Sistemas de propagação em fases do repositório

Se você estiver usando um dos sistemas de propagação em fases do repositório (SMT, RMT ou SUSE Manager), crie um novo nível de patch congelado para a versão atual e nova do SUSE Enterprise Storage.

Mais informações podem ser encontradas na:

6.4.3 Corrigindo o cluster inteiro com os patches mais recentes

  1. Aplique os patches mais recentes do SUSE Enterprise Storage 5.5 e do SUSE Linux Enterprise Server 12 SP3 a cada nó do cluster do Ceph. Verifique se os repositórios de software corretos estão conectados a cada nó do cluster (consulte a Seção 6.4.1, “Repositórios de software necessários”) e execute a fase 0 do DeepSea: 

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

  2. Após a conclusão da fase 0, verifique se o status de cada nó do cluster inclui “HEALTH_OK”. Se não incluir, resolva o problema antes das possíveis reinicializações nas próximas etapas.

  3. Execute o zypper ps para verificar se há processos que possam ser executados com bibliotecas ou binários desatualizados e, se houver, faça a reinicialização.

  4. Verifique se o kernel em execução é o mais recente disponível e, se não for, faça a reinicialização. Verifique as saídas dos seguintes comandos: 

    cephadm@adm > uname -a
cephadm@adm > rpm -qa kernel-default

  5. Verifique se o pacote ceph é da versão 12.2.12 ou mais recente. Verifique se o pacote deepsea é da versão 0.8.9 ou mais recente.

  6. Se você já usou qualquer uma das configurações de bluestore_cache, elas não estão mais em vigor a partir do ceph versão 12.2.10. A nova configuração bluestore_cache_autotune que, por padrão, está definida como “true”, desabilita o dimensionamento manual do cache. Para ativar o comportamento antigo, você precisa definir bluestore_cache_autotune=false. Consulte o Seção 16.2.1, “Dimensionamento automático do cache” para obter os detalhes.

6.5 Verificando o ambiente atual

  • Se o sistema tiver problemas óbvios, corrija-os antes de iniciar o upgrade. O upgrade nunca corrige problemas existentes do sistema.

  • Verifique o desempenho do cluster. Você pode usar comandos, como rados bench, ceph tell osd.* bench ou iperf3.

  • Verifique o acesso aos gateways (como iSCSI Gateway ou Object Gateway) e ao Dispositivo de Blocos RADOS.

  • Registre partes específicas da configuração do sistema, como configuração de rede, particionamento ou detalhes da instalação.

  • Use o supportconfig para coletar informações importantes do sistema e grave-as fora dos nós do cluster. Mais informações podem ser encontradas em https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html.

  • Verifique se há espaço livre suficiente no disco em cada nó do cluster. Use o comando df -h para verificar o espaço livre no disco. Quando necessário, libere espaço no disco removendo arquivos/diretórios desnecessários ou removendo instantâneos obsoletos do OS. Se não houver espaço livre suficiente no disco, não continue com o upgrade até liberar espaço suficiente.

6.6 Verificando o estado do cluster

  • Use o comando cluster health para verificar a saúde do cluster antes de iniciar o procedimento de upgrade. Não inicie o upgrade, exceto quando cada nó do cluster relatar “HEALTH_OK”.

  • Verifique se todos os serviços estão em execução:

    • Master Salt e daemons do master Salt.

    • Daemons do Ceph Monitor e do Ceph Manager.

    • Daemons do Servidor de Metadados.

    • Daemons do Ceph OSD.

    • Daemons do Object Gateway.

    • Daemons do iSCSI Gateway.

Os seguintes comandos apresentam os detalhes do estado do cluster e a configuração específica:

ceph -s

Imprime um breve resumo da saúde do cluster do Ceph, dos serviços em execução, do uso de dados e das estatísticas de E/S. Verifique se ele relata “HEALTH_OK” antes de iniciar o upgrade.

ceph health detail

Imprime os detalhes se a saúde do cluster do Ceph não estiver OK.

ceph versions

Imprime as versões dos daemons do Ceph em execução.

ceph df

Imprime o espaço total e livre do disco no cluster. Não inicie o upgrade se o espaço livre no disco do cluster for inferior a 25% do espaço total no disco.

salt '*' cephprocesses.check results=true

Imprime os processos em execução do Ceph e os respectivos PIDs classificados por minions Salt.

ceph osd dump | grep ^flags

Verifique se os flags "recovery_deletes" e "purged_snapdirs” estão presentes. Se não estiverem, você poderá forçar uma depuração de todos os grupos de posicionamento executando o comando a seguir. Saiba que essa depuração forçada pode prejudicar o desempenho dos clientes Ceph. 

cephadm@adm > ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub

6.7 Fazendo upgrade offline dos clusters CTDB

O CTDB oferece um banco de dados em cluster usado pelos Gateways do Samba. O protocolo CTDB é muito simples e não suporta clusters de nós que se comunicam com diferentes versões de protocolo. Portanto, os nós do CTDB precisam ser colocados offline antes de realizar um upgrade.

6.8 Fazendo upgrade por nó: procedimento básico

Para garantir que os principais serviços do cluster fiquem disponíveis durante o upgrade, você precisa fazer upgrade dos nós do cluster um por um, em sequência. Há duas maneiras de executar o upgrade de um nó: usando o DVD do instalador ou o sistema de migração de distribuição.

Após o upgrade de cada nó, recomendamos executar o rpmconfigcheck para verificar se há arquivos de configuração atualizados que foram editados localmente. Se o comando retornar uma lista de nomes de arquivo com um sufixo .rpmnew, .rpmorig ou .rpmsave, compare esses arquivos com os arquivos de configuração atuais para garantir que nenhuma mudança local tenha sido perdida. Se necessário, atualize os arquivos afetados. Para obter mais informações sobre como trabalhar com arquivos .rpmnew, .rpmorig e .rpmsave, consulte https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-sw-cl.html#sec-rpm-packages-manage.

Dica
Dica: Pacotes Órfãos

Após o upgrade de um nó, vários pacotes terão o estado “órfão” sem um repositório pai. Isso acontece porque os pacotes python3 relacionados não tornam os pacotes python2 obsoletos.

Há mais informações sobre como listar pacotes órfãos disponíveis no site https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_zypper.html#sec_zypper_softup_orphaned.

6.8.1 Fazendo upgrade manual do nó por meio do DVD do instalador

  1. Reinicialize o nó usando o DVD/imagem do instalador do SUSE Linux Enterprise Server 15 SP1.

  2. Selecione Upgrade no menu de inicialização.

  3. Na tela Selecionar o Destino da Migração, verifique se “SUSE Linux Enterprise Server 15 SP1” está selecionado e ative a caixa de seleção Ajustar Manualmente os Repositórios para Migração.

    Selecionar o Destino da Migração
    Figura 6.1: Selecionar o Destino da Migração

  4. Selecione os seguintes módulos para instalação:

    • SUSE Enterprise Storage 6 x86_64

    • Módulo Basesystem 15 SP1 x86_64

    • Módulo Desktop Applications 15 SP1 x86_64

    • Módulo Legacy 15 SP1 x86_64

    • Módulo Server Applications 15 SP1 x86_64

  5. Na tela Repositórios Usados Anteriormente, verifique se os repositórios corretos estão selecionados. Se o sistema não foi registrado com SCC/SMT, você precisa adicionar os repositórios manualmente.

    O SUSE Enterprise Storage 6 requer:

    • SLE-Module-Basesystem15-SP1-Pool

    •  SLE-Module-Basesystem15-SP1-Updates

    •  SLE-Module-Server-Applications15-SP1-Pool

    •  SLE-Module-Server-Applications15-SP1-Updates

    • SLE-Module-Desktop-Applications15-SP1-Pool

    • SLE-Module-Desktop-Applications15-SP1-Updates

    •  SLE-Product-SLES15-SP1-Pool

    •  SLE-Product-SLES15-SP1-Updates

    •  SLE15-SP1-Installer-Updates

    •  SUSE-Enterprise-Storage-6-Pool

    •  SUSE-Enterprise-Storage-6-Updates

    Se você pretende migrar o ntpd para o chronyd após a migração do SES (consulte a Seção 6.3, “Migrando do ntpd para o chronyd”), inclua os seguintes repositórios:

    • SLE-Module-Legacy15-SP1-Pool

    • SLE-Module-Legacy15-SP1-Updates

    O Gateway NFS/SMB no SLE-HA no SUSE Linux Enterprise Server 15 SP1 requer:

    • SLE-Product-HA15-SP1-Pool

    • SLE-Product-HA15-SP1-Updates

  6. Revise as Configurações de Instalação e inicie o procedimento de instalação clicando em Atualizar.

6.8.2 Fazendo upgrade do nó por meio do SUSE Distribution Migration System

O Distribution Migration System (DMS) inclui um caminho de upgrade para um sistema SUSE Linux Enterprise instalado de uma versão principal para outra. O procedimento a seguir utiliza o DMS para fazer upgrade do SUSE Enterprise Storage 5.5 para a versão 6, incluindo a migração do SUSE Linux Enterprise Server 12 SP3 subjacente para o SUSE Linux Enterprise Server 15 SP1.

Consulte https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/ para encontrar informações gerais e detalhadas sobre o DMS.

  1. Instale os pacotes RPM de migração. Eles ajustam o carregador de boot GRUB para acionar automaticamente o upgrade na próxima reinicialização. Instale os pacotes SLES15-SES-Migration e suse-migration-sle15-activation : 

    root@minion > zypper install SLES15-SES-Migration suse-migration-sle15-activation

    1. Se o nó do qual está sendo feito o upgrade foi registrado com um sistema de propagação em fases do repositório, como SCC, SMT, RMT ou SUSE Manager, crie o /etc/sle-migration-service.yml com o seguinte conteúdo: 

      use_zypper_migration: true
preserve:
  rules:
    - /etc/udev/rules.d/70-persistent-net.rules

    2. Se o nó do qual está sendo feito o upgrade não foi registrado com um sistema de propagação em fases do repositório, como SCC, SMT, RMT ou SUSE Manager, faça as seguintes mudanças:

      1. Crie o /etc/sle-migration-service.yml com o seguinte conteúdo: 

        use_zypper_migration: false
preserve:
  rules:
    - /etc/udev/rules.d/70-persistent-net.rules

      2. Desabilite ou remova os repositórios SLE 12 SP3 e SES 5 e adicione os repositórios SLE 15 SP1 e SES 6. Encontre a lista de repositórios relacionados na Seção 6.4.1, “Repositórios de software necessários”.

  3. Reinicialize para iniciar o upgrade. Durante a execução do upgrade, você pode efetuar login no nó do qual foi feito o upgrade com ssh como usuário da migração utilizando a chave SSH existente do sistema host, conforme descrito em https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/. Para o SUSE Enterprise Storage, se você tiver acesso físico ou acesso direto do console à máquina, poderá efetuar login como root no console do sistema usando a senha sesupgrade. O nó será reinicializado automaticamente após o upgrade.

    Dica
    Dica: Falha no upgrade

    Se houver falha no upgrade, inspecione o /var/log/distro_migration.log. Corrija o problema, reinstale os pacotes RPM de migração e reinicialize o nó.

6.9 Fazendo upgrade do nó de admin

Dica
Dica: Status dos Nós do Cluster

Após o upgrade do Nó de Admin, você poderá executar o comando salt-run upgrade.status para ver informações úteis sobre os nós do cluster. O comando lista as versões do Ceph e do OS de todos os nós e recomenda em que ordem fazer o upgrade de quaisquer nós que ainda executam versões antigas. 

root@master # salt-run upgrade.status
The newest installed software versions are:
  ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable)
  os: SUSE Linux Enterprise Server 15 SP1

Nodes running these software versions:
  admin.ceph (assigned roles: master)
  mon2.ceph (assigned roles: admin, mon, mgr)

Nodes running older software versions must be upgraded in the following order:
   1: mon1.ceph (assigned roles: admin, mon, mgr)
   2: mon3.ceph (assigned roles: admin, mon, mgr)
   3: data1.ceph (assigned roles: storage)
[...]

6.10 Fazendo upgrade dos nós do Ceph Monitor/Ceph Manager

Nota
Nota: Upgrade do Ceph Monitor

Em virtude de uma limitação no projeto do Ceph Monitor, depois que é feito upgrade de dois MONs para o SUSE Enterprise Storage 6 e um quorum é formado, o terceiro MON (enquanto ainda está no SUSE Enterprise Storage 5.5) não reingressará no cluster MON se ele for reiniciado por qualquer motivo, incluindo uma reinicialização de nó. Portanto, quando é feito upgrade de dois MONs, a melhor opção é fazer upgrade dos demais o quanto antes.

Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.

6.11 Fazendo upgrade dos servidores de metadados

Você precisa reduzir o cluster do Servidor de Metadados (MDS, Metadata Server). Como há recursos incompatíveis entre as versões 5.5 e 6 do SUSE Enterprise Storage, os daemons MDS mais antigos serão encerrados logo que virem um único MDS no nível do SES 6 ingressar no cluster. Portanto, é necessário reduzir o cluster MDS a um único MDS ativo (sem standbys) durante os upgrades dos nós MDS. Logo após o upgrade do segundo nó, você poderá estender o cluster MDS novamente.

Dica
Dica

Em um cluster MDS com carga muito pesada, talvez seja necessário reduzir a carga (por exemplo, parando os clientes) para que um único MDS ativo seja capaz de processar a carga de trabalho.

  1. Observe o valor atual da opção max_mds: 

    cephadm@adm > ceph fs get cephfs | grep max_mds

  2. Reduza o cluster MDS se você tiver mais do que 1 daemon MDS ativo. Por exemplo, max_mds é > 1. Para reduzir o cluster MDS, execute 

    cephadm@adm > ceph fs set FS_NAME max_mds 1

    em que FS_NAME é o nome da sua instância do CephFS (por padrão, “cephfs”).

  3. Encontre o nó que hospeda um dos daemons MDS de standby. Consulte a saída do comando ceph fs status e inicie o upgrade do cluster MDS nesse nó. 

    cephadm@adm > ceph fs status
cephfs - 2 clients
======
+------+--------+--------+---------------+-------+-------+
| Rank | State  |  MDS   |    Activity   |  dns  |  inos |
+------+--------+--------+---------------+-------+-------+
|  0   | active | mon1-6 | Reqs:    0 /s |   13  |   16  |
+------+--------+--------+---------------+-------+-------+
+-----------------+----------+-------+-------+
|       Pool      |   type   |  used | avail |
+-----------------+----------+-------+-------+
| cephfs_metadata | metadata | 2688k | 96.8G |
|   cephfs_data   |   data   |    0  | 96.8G |
+-----------------+----------+-------+-------+
+-------------+
| Standby MDS |
+-------------+
|    mon3-6   |
|    mon2-6   |
+-------------+

    Neste exemplo, é necessário iniciar o procedimento de upgrade no nó “mon3-6” ou “mon2-6”.

  4. Faça upgrade do nó com o daemon MDS de standby. Depois que o nó MDS do qual foi feito o upgrade for iniciado, os daemons MDS desatualizados serão encerrados automaticamente. Neste ponto, os clientes podem passar por um breve tempo de espera do serviço CephFS.

    Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.

  5. Faça upgrade dos nós MDS restantes.

  6. Redefina max_mds para a configuração desejada: 

    cephadm@adm > ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT

6.12 Fazendo upgrade dos Ceph OSDs

Para cada nó de armazenamento, siga etas etapas:

  1. Identifique quais daemons OSD estão sendo executados em um nó específico: 

    cephadm@osd > ceph osd tree

  2. Defina o flag “noout” para cada daemon OSD no nó do qual está sendo feito o upgrade: 

    cephadm@osd > ceph osd add-noout osd.OSD_ID

    Por exemplo: 

    cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done

    Faça a verificação com: 

    cephadm@osd > ceph health detail | grep noout

    ou 

    cephadm@osd > ceph –s
cluster:
 id:     44442296-033b-3275-a803-345337dc53da
 health: HEALTH_WARN
      6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set

  3. Crie arquivos /etc/ceph/osd/*.json para todos os OSDs existentes executando o seguinte comando no nó do qual será feito o upgrade: 

    cephadm@osd > ceph-volume simple scan --force

  4. Faça upgrade do nó OSD. Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.

  5. Ativar todos os OSDs encontrados no sistema: 

    cephadm@osd > ;ceph-volume simple activate --all
    Dica
    Dica: Ativação das Partições de Dados Individualmente

    Para ativar partições de dados individualmente, você precisa encontrar o comando ceph-volume correto de cada partição para ativá-la. Substitua X1 pela letra/número correto da partição: 

     cephadm@osd > ceph-volume simple scan /dev/sdX1

    Por exemplo: 

    cephadm@osd > ceph-volume simple scan /dev/vdb1
[...]
--> OSD 8 got scanned and metadata persisted to file:
/etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json
--> To take over management of this scanned OSD, and disable ceph-disk
and udev, run:
-->     ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290

    A última linha da saída contém o comando para ativar a partição: 

    cephadm@osd > ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290
[...]
--> All ceph-disk systemd units have been disabled to prevent OSDs
getting triggered by UDEV events
[...]
Running command: /bin/systemctl start ceph-osd@8
--> Successfully activated OSD 8 with FSID
d7bd2685-5b92-4074-8161-30d146cd0290

  6. Verifique se o nó OSD será iniciado apropriadamente após a reinicialização.

  7. Resolva a mensagem “Legacy BlueStore stats reporting detected on XX OSD(s)” (Relatório de estatísticas do BlueStore legado detectado em XX OSD(s)): 

    cephadm@osd > ceph –s
cluster:
 id:     44442296-033b-3275-a803-345337dc53da
 health: HEALTH_WARN
 Legacy BlueStore stats reporting detected on 6 OSD(s)

    O aviso é normal ao fazer upgrade do Ceph para 14.2.2. Para desabilitá-lo, defina: 

    bluestore_warn_on_legacy_statfs = false

    A correção apopriada é executar o seguinte comando em todos os OSDs enquanto estão sendo interrompidos: 

    cephadm@osd > ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX

    Veja a seguir um script ajudante que executa o comando ceph-bluestore-tool repair para todos os OSDs no nó NODE_NAME: 

    OSDNODE=OSD_NODE_NAME;\
 for OSD in $(ceph osd ls-tree $OSDNODE);\
 do echo "osd=" $OSD;\
 salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\
 salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\
 salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\
 done

  8. Cancele a definição do flag “noout” para cada daemon OSD no nó do qual foi feito o upgrade: 

    cephadm@osd > ceph osd rm-noout osd.OSD_ID

    Por exemplo: 

    cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done

    Faça a verificação com: 

    cephadm@osd > ceph health detail | grep noout

    Nota: 

    cephadm@osd > ceph –s
cluster:
 id:     44442296-033b-3275-a803-345337dc53da
 health: HEALTH_WARN
 Legacy BlueStore stats reporting detected on 6 OSD(s)

  9. Verifique o status do cluster. Ele será semelhante à seguinte saída: 

    cephadm@osd > ceph status
cluster:
  id:     e0d53d64-6812-3dfe-8b72-fd454a6dcf12
  health: HEALTH_WARN
          3 monitors have not enabled msgr2

services:
  mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
  mgr: mon2(active, since 22m), standbys: mon1, mon3
  osd: 30 osds: 30 up, 30 in

data:
  pools:   1 pools, 1024 pgs
  objects: 0 objects, 0 B
  usage:   31 GiB used, 566 GiB / 597 GiB avail
  pgs:     1024 active+clean

  10. Verifique se todos os nós OSD foram reinicializados e se os OSDs foram iniciados automaticamente após a reinicialização.

6.13 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 diferente, por exemplo, mais rápida.

No SUSE Enterprise Storage 5, 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

Reconstrua os nós antes de continuar: 

 root@master #  salt-run rebuild.node TARGET

Você também pode reconstruir cada nó individualmente. Por exemplo: 

root@master #  salt-run rebuild.node data1.ceph

O rebuild.node sempre remove e recria todos os OSDs no nó.

Importante
Importante

Se um OSD não puder ser convertido, uma nova reconstrução destruirá os OSDs do BlueStore já convertidos. Em vez de uma nova reconstrução, você poderá executar: 

root@master # salt-run disks.deploy TARGET

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

6.14 Fazendo upgrade dos nós do aplicativo

Faça upgrade dos nós do aplicativo na seguinte ordem:

  1. Object Gateways

    • Se o front end dos Object Gateways for um balanceador de carga, um upgrade sequencial dos Object Gateways deverá ser possível sem interrupção.

    • Confirme se os daemons do Object Gateway estão em execução após cada upgrade e faça o teste com o cliente S3/Swift.

    • Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.

  2. iSCSI Gateways

    • Se os iniciadores iSCSI estiverem configurados com múltiplos caminhos, um upgrade sequencial dos iSCSI Gateways deverá ser possível sem interrupção.

    • Confirme se o daemon lrbd está em execução após cada upgrade e faça o teste com o iniciador.

    • Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.

  3. NFS Ganesha. Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.

  4. Gateways do Samba. Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.

6.15 Atualizando o policy.cfg e implantando o Ceph Dashboard por meio do DeepSea

No Nó de Admin, edite o /srv/pillar/ceph/proposals/policy.cfg e aplique as seguintes mudanças:

Importante
Importante: Sem Novos Serviços

Durante o upgrade do cluster, não adicione novos serviços ao arquivo policy.cfg. Apenas mude a arquitetura do cluster após a conclusão do upgrade.

  1. Remova role-openattic.

  2. Adicione role-prometheus e role-grafana ao nó com o Prometheus e o Grafana instalados (normalmente, o Nó de Admin).

  3. Agora, a função profile-NOME_PERFIL será ignorada. Adicione a nova função correspondente: linha role-storage. Por exemplo, para o comando existente 

    profile-default/cluster/*.sls

    adicione 

    role-storage/cluster/*.sls

  4. Sincronize todos os módulos do Salt: 

    root@master # salt '*' saltutil.sync_all

  5. Execute as fases 1 e 2 do DeepSea para atualizar o pillar Salt: 

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

  6. Limpe o openATTIC: 

    root@master # salt OA_MINION state.apply ceph.rescind.openattic
root@master # salt OA_MINION state.apply ceph.remove.openattic

  7. Cancele a definição do grain “restart_igw” para impedir que a fase 0 reinicie o iSCSI Gateway, que ainda não está instalado: 

    Salt mastersalt '*' grains.delkey restart_igw

  8. Por fim, execute as fases de 0 a 4 do DeepSea: 

    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
root@master # salt-run state.orch ceph.stage.4
    Dica
    Dica: Erros de "subvolume ausente" durante a Fase 3

    A fase 3 do DeepSea pode falhar com um erro semelhante ao exibido a seguir: 

    subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \
'/var/lib/ceph subvolume missing on 4510-1', \
[...]
'See /srv/salt/ceph/subvolume/README.md']

    Neste caso, você precisa editar o /srv/pillar/ceph/stack/global.yml e adicionar a seguinte linha: 

    subvolume_init: disabled

    Em seguida, atualize o pillar Salt e execute a fase 3 do DeepSea novamente: 

    root@master # salt '*' saltutil.refresh_pillar
 root@master # salt-run state.orch ceph.stage.3

    Após a conclusão bem-sucedida da fase 3 do DeepSea, o Ceph Dashboard será executado. Consulte o Capítulo 22, Ceph Dashboard para obter uma visão geral detalhada dos recursos do Ceph Dashboard.

    Para listar os nós que executam o painel de controle, aplique o comando: 

    cephadm@adm > ceph mgr services | grep dashboard

    Para listar as credenciais de admin, execute: 

    root@master # salt-call grains.get dashboard_creds

  9. Reinicie sequencialmente os serviços do Object Gateway para usar o servidor Web “beast” em vez do “civetweb” desatualizado: 

    root@master # salt-run state.orch ceph.restart.rgw.force

  10. Antes de continuar, recomendamos enfaticamente habilitar o módulo de telemetria do Ceph. Para obter mais informações e instruções, consulte o Seção 10.2, “Módulo de telemetria”.

6.16 Migrando de implantações com base no perfil para DriveGroups

No SUSE Enterprise Storage 5.5, o DeepSea ofereceu os chamados “perfis” para descrever o layout dos OSDs. A partir do SUSE Enterprise Storage 6, adotamos uma abordagem diferente denominada DriveGroups (encontre mais detalhes na Seção 5.5.2, “DriveGroups”).

Nota
Nota

A migração para a nova abordagem não é obrigatória de imediato. Operações destrutivas, como salt-run osd.remove, salt-run osd.replace ou salt-run osd.purge, ainda estão disponíveis. No entanto, a adição de novos OSDs exigirá que você execute uma ação.

Devido à abordagem diferente dessas implementações, não oferecemos um caminho de migração automatizado. No entanto, oferecemos uma variedade de ferramentas, executores Salt, para tornar a migração o mais simples possível.

6.16.1 Analisando o layout atual

Para ver informações sobre os OSDs implantados atualmente, use o seguinte comando: 

root@master # salt-run disks.discover

Se preferir, você poderá inspecionar o conteúdo dos arquivos nos diretórios /srv/pillar/ceph/proposals/profile-*/. Eles têm uma estrutura semelhante à seguinte: 

ceph:
  storage:
    osds:
      /dev/disk/by-id/scsi-drive_name: format: bluestore
      /dev/disk/by-id/scsi-drive_name2: format: bluestore

6.16.2 Criando DriveGroups que correspondem ao layout atual

Consulte a Seção 5.5.2.1, “Especificação” para obter mais detalhes sobre a especificação de DriveGroups.

A diferença entre uma implantação nova e um cenário de upgrade é que as unidades que serão migradas já são “usadas”. Como 

root@master # salt-run disks.list

procura apenas discos não usados, aplique o comando 

root@master # salt-run disks.list include_unavailable=True

Ajuste os DriveGroups até corresponder à sua configuração atual. Para uma representação mais visual do que acontecerá, execute o comando a seguir. Observe que ele não terá saída se não houver discos livres: 

root@master # salt-run disks.report bypass_pillar=True

Se você verificou que os DriveGroups estão configurados apropriadamente e deseja aplicar a nova abordagem, remova os arquivos do diretório /srv/pillar/ceph/proposals/profile-NOME_PERFIL/, remova as linhas profile-NOME_PERFIL/cluster/*.sls correspondentes do arquivo /srv/pillar/ceph/proposals/policy.cfg e execute a fase 2 do DeepSea para atualizar o pillar Salt. 

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

Execute os seguintes comandos para verificar o resultado: 

root@master # salt target_node pillar.get ceph:storage
root@master # salt-run disks.report
Atenção
Atenção: Configuração Incorreta dos DriveGroups

Se os DriveGroups não estiverem configurados apropriadamente e houver discos sobressalentes na configuração, eles serão implantados da maneira que você os especificou. Recomendamos executar o comando: 

root@master # salt-run disks.report

6.16.3 Implantando um OSD

Para casos simples, como OSDs independentes, a migração acontecerá com o tempo. Sempre que você remover ou substituir um OSD do cluster, ele será substituído por um novo OSD baseado em LVM.

Dica
Dica: Migrar para o Formato LVM

Sempre que um único OSD "legado" precisar ser substituído em um nó, todos os OSDs que compartilham dispositivos com ele deverão ser migrados para o formato baseado em LVM.

Para totalidade, considere a migração dos OSDs em todo o nó.

6.16.4 Configurações mais complexas

Se você tem uma configuração mais sofisticada do que apenas OSDs independentes (por exemplo, WAL/BDs dedicados ou OSDs criptografados), a migração apenas pode acontecer quando todos os OSDs atribuídos a esse dispositivo WAL/BD são removidos. Isso ocorre porque o comando ceph-volume cria os Volumes Lógicos nos discos antes da implantação. Esse comportamento impede que o usuário misture implantações baseadas na partição com implantações baseadas em LV. Nesses casos, o melhor é remover manualmente todos os OSDs atribuídos a um dispositivo WAL/BD e reimplantá-los adotando a abordagem DriveGroups.

→Capítulo 7 Personalizando a configuração padrão←Capítulo 5 Implantando com o DeepSea/Salt
Imprimir esta página

© 2022 SUSE