Aplica-se a SUSE Enterprise Storage 7.1

10 Upgrade do SUSE Enterprise Storage 6 para 7.1 #

Este capítulo apresenta as etapas para fazer upgrade do SUSE Enterprise Storage 6 para a versão 7.1.

O upgrade inclui as seguintes tarefas:

Fazer upgrade do Ceph Nautilus para o Pacific.
Alternar da instalação e execução do Ceph por meio de pacotes RPM para a execução em containers.
Remoção completa do DeepSea e substituição pelo ceph-salt e cephadm.

Atenção

As informações de upgrade neste capítulo são válidas apenas para upgrades do DeepSea para o cephadm. Não tente seguir estas instruções para implantar o SUSE Enterprise Storage na Plataforma SUSE CaaS.

Importante

O upgrade de versões do SUSE Enterprise Storage mais antigas do que a 6 não é suportado. Você deve primeiro fazer upgrade para a versão mais recente do SUSE Enterprise Storage 6 e, na sequência, seguir as etapas neste capítulo.

10.1 Antes de fazer upgrade #

As tarefas a seguir devem ser concluídas antes de você iniciar o upgrade. Isso pode ser feito a qualquer momento durante a vida útil do SUSE Enterprise Storage 6.

A migração do OSD do FileStore para o BlueStore deve ser feita antes do upgrade porque o FileStore é incompatível com o SUSE Enterprise Storage 7.1. Há mais detalhes sobre o BlueStore e como migrar do FileStore em https://documentation.suse.com/ses/6/single-html/ses-deployment/#filestore2bluestore.
Se você executa um cluster mais antigo que ainda usa OSDs do ceph-disk, precisa alternar para o ceph-volume antes do upgrade. Encontre mais detalhes na https://documentation.suse.com/ses/6/single-html/ses-deployment/#upgrade-osd-deployment.

10.1.1 Pontos a serem considerados #

Antes de fazer upgrade, leia as seções a seguir para garantir que você entenda todas as tarefas que precisam ser executadas.

Ler os detalhes da versão. Neles, 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.
Você encontra os detalhes da versão do SES 7.1 online em https://www.suse.com/releasenotes/.
Além disso, após a instalação do pacote release-notes-ses do repositório SES 7.1, encontre os detalhes da versão localmente no diretório /usr/share/doc/release-notes ou online em https://www.suse.com/releasenotes/.
Leia a Parte II, “Implantando o cluster do Ceph” para se familiarizar com o ceph-salt e o orquestrador do Ceph, especialmente as informações sobre as especificações do serviço.
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.
Você precisa primeiro fazer upgrade do Master Salt e depois substituir o DeepSea pelo ceph-salt e cephadm. Você não poderá começar a usar o módulo de orquestrador cephadm até que seja feito o upgrade de todos os nós do Ceph Manager.
O upgrade do uso de RPMs do Nautilus para containers do Pacific precisa ser feito em uma única etapa. Isso significa fazer upgrade de um nó inteiro de uma vez, e não um daemon de cada vez.
O upgrade dos serviços básicos (MON, MGR, OSD) é feito de forma ordenada. Cada serviço fica disponível durante o upgrade. Os serviços de gateway (Servidor de Metadados, Gateway de Objetos, NFS Ganesha, iSCSI Gateway) precisarão ser reimplantados após o upgrade dos serviços básicos. Há um determinado tempo de espera para cada um dos seguintes serviços:
- Importante
  Os Servidores de Metadados e os Gateways de Objetos ficam inativos a partir do momento em que o upgrade dos nós é feito do SUSE Linux Enterprise Server 15 SP1 para o SUSE Linux Enterprise Server 15 SP3 até a reimplantação dos serviços no final do procedimento de upgrade. É importante ter isso em mente principalmente quando esses serviços estão combinados com MONs, MGRs ou OSDs, porque eles podem ficar inativos durante o upgrade do cluster. Se isso for um problema, considere a implantação desses serviços separadamente em nós adicionais antes do upgrade, de modo que eles fiquem inativos pelo menor tempo possível. Essa é a duração do upgrade dos nós de gateway, não a duração do upgrade de todo o cluster.
- O NFS Ganesha e os iSCSI Gateways ficam inativos apenas no período de reinicialização dos nós durante o upgrade do SUSE Linux Enterprise Server 15 SP1 para o SUSE Linux Enterprise Server 15 SP3, e rapidamente depois quando cada serviço é reimplantado no modo de container.

10.1.2 Fazendo backup da configuração e dos dados do cluster #

É altamente recomendável fazer backup de todas as configurações e os dados do cluster antes de iniciar o upgrade para o SUSE Enterprise Storage 7.1. Para obter instruções sobre como fazer backup de todos os seus dados, consulte o https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backup.

10.1.3 Verificando etapas do upgrade anterior #

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

Verifique se existe o arquivo /srv/salt/ceph/configuration/files/ceph.conf.import.

Esse arquivo é criado pelo processo de integração durante o upgrade do SUSE Enterprise Storage 5 para 6. A opção configuration_init: default-import é definida em /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.

10.1.4 Atualizando os nós e verificando a saúde do cluster #

Verifique se todas as atualizações mais recentes do SUSE Linux Enterprise Server 15 SP1 e do SUSE Enterprise Storage 6 foram aplicadas a todos os nós do cluster:

# zypper refresh && zypper patch

Dica

Consulte https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updates para obter informações detalhadas sobre como atualizar os nós do cluster.

Depois que as atualizações forem aplicadas, reinicie o Master Salt, sincronize os novos módulos do Salt e verifique a saúde do cluster:

root@master # systemctl restart salt-master.service
root@master # salt '*' saltutil.sync_all
cephuser@adm > ceph -s

10.1.4.1 Desabilitar clientes não seguros #

Desde o Nautilus v14.2.20, um novo aviso de saúde foi implementado para informar a você que clientes não seguros têm permissão para ingressar no cluster. Por padrão, esse aviso está ativado. O Ceph Dashboard mostrará o cluster no status HEALTH_WARN. A linha de comando verifica o status do cluster da seguinte maneira:

 cephuser@adm > ceph status
 cluster:
   id:     3fe8b35a-689f-4970-819d-0e6b11f6707c
   health: HEALTH_WARN
   mons are allowing insecure global_id reclaim
 [...]

Esse aviso significa que os Ceph Monitors ainda permitem que clientes antigos e sem patch se conectem ao cluster. Isso garante que os clientes existentes ainda consigam se conectar durante o upgrade do cluster, mas avisa você de que há um problema que precisa ser resolvido. Quando o upgrade do cluster e de todos os clientes for feito para a versão mais recente do Ceph, execute o seguinte comando para não permitir os clientes sem patch:

cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false

10.1.5 Verificando o acesso a repositórios do software e imagens de container #

Verifique se cada nó do cluster tem acesso aos repositórios do software SUSE Linux Enterprise Server 15 SP3 e SUSE Enterprise Storage 7.1 e também ao registro de imagens de container.

10.1.5.1 Repositórios do software #

Se todos os nós foram registrados no SCC, você poderá usar o comando zypper migration para fazer upgrade. Consulte https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-upgrade-online.html#sec-upgrade-online-zypper para obter mais detalhes.

Se os nós não foram registrados no SCC, desabilite todos os repositórios existentes do software e adicione os dois repositórios Pool e Updates para cada uma das seguintes extensões:

SLE-Product-SLES/15-SP3
SLE-Module-Basesystem/15-SP3
SLE-Module-Server-Applications/15-SP3
SUSE-Enterprise-Storage-7.1

10.1.5.2 Imagens de container #

Todos os nós do cluster precisam acessar o registro de imagens de container. Na maioria dos casos, você usará o registro público do SUSE em registry.suse.com. Você precisa das seguintes imagens:

registry.suse.com/ses/7.1/ceph/ceph
registry.suse.com/ses/7.1/ceph/grafana
registry.suse.com/ses/7.1/ceph/prometheus-server
registry.suse.com/ses/7.1/ceph/prometheus-node-exporter
registry.suse.com/ses/7.1/ceph/prometheus-alertmanager

Por exemplo, para implantações isoladas (air-gapped), uma alternativa é configurar um registro local e verificar se você tem o conjunto correto de imagens de container disponível. Consulte a Seção 7.2.10, “Usando o registro do container” para obter mais detalhes sobre como configurar um registro de imagens de container local.

10.2 Fazendo upgrade do Master Salt #

O procedimento a seguir descreve o processo de upgrade do Master Salt:

Faça upgrade do OS subjacente para o SUSE Linux Enterprise Server 15 SP3:
- Para um cluster em que todos os nós foram registrados no SCC, execute zypper migration.
- Para um cluster em que os nós têm repositórios de software atribuídos manualmente, execute zypper dup seguido de reboot.

Desabilite as fases do DeepSea para evitar o uso acidental. Adicione o seguinte conteúdo a /srv/pillar/ceph/stack/global.yml:

stage_prep: disabled
stage_discovery: disabled
stage_configure: disabled
stage_deploy: disabled
stage_services: disabled
stage_remove: disabled

Grave o arquivo e aplique as mudanças:

root@master # salt '*' saltutil.pillar_refresh

Se você não usa imagens de container do registry.suse.com, mas sim o registro configurado localmente, edite o /srv/pillar/ceph/stack/global.yml para especificar a imagem de container e o registro do Ceph que o DeepSea usará. Por exemplo, para usar 192.168.121.1:5000/my/ceph/image, adicione as seguintes linhas:
```
ses7_container_image: 192.168.121.1:5000/my/ceph/image
ses7_container_registries:
  - location: 192.168.121.1:5000
```
Se você precisar especificar informações de autenticação para o registro, adicione o bloco ses7_container_registry_auth:, por exemplo:
```
ses7_container_image: 192.168.121.1:5000/my/ceph/image
ses7_container_registries:
  - location: 192.168.121.1:5000
ses7_container_registry_auth:
  registry: 192.168.121.1:5000
  username: USER_NAME
  password: PASSWORD
```
Grave o arquivo e aplique as mudanças:
```
root@master # salt '*' saltutil.refresh_pillar
```

Observe a configuração existente:

cephuser@adm > ceph config assimilate-conf -i /etc/ceph/ceph.conf

Verifique o status do upgrade. A saída pode ser diferente dependendo da configuração do seu cluster:

root@master # salt-run upgrade.status
The newest installed software versions are:
 ceph: ceph version 16.2.7-640-gceb23c7491b (ceb23c7491bd96ab7956111374219a4cdcf6f8f4) pacific (stable)
 os: SUSE Linux Enterprise Server 15 SP3

Nodes running these software versions:
 admin.ceph (assigned roles: master, prometheus, grafana)

Nodes running older software versions must be upgraded in the following order:
 1: mon1.ceph (assigned roles: admin, mon, mgr)
 2: mon2.ceph (assigned roles: admin, mon, mgr)
 3: mon3.ceph (assigned roles: admin, mon, mgr)
 4: data4.ceph (assigned roles: storage, mds)
 5: data1.ceph (assigned roles: storage)
 6: data2.ceph (assigned roles: storage)
 7: data3.ceph (assigned roles: storage)
 8: data5.ceph (assigned roles: storage, rgw)

10.3 Fazendo upgrade dos nós MON, MGR e OSD #

Faça upgrade do Ceph Monitor, do Ceph Manager e dos nós OSD, um de cada vez. Para cada serviço, siga estas etapas:

Antes de adotar qualquer nó OSD, você precisa executar uma conversão de formato dos nós OSD para melhorar a contabilização dos dados OMAP. Você pode fazer isso executando o seguinte comando no Nó de Admin:
```
cephuser@adm > ceph config set osd bluestore_fsck_quick_fix_on_mount true
```
Os nós OSD serão convertidos automaticamente após o término da adoção.
Nota
A conversão pode levar de minutos a horas, dependendo da quantidade de dados OMAP contida no disco rígido relacionado. Para obter mais detalhes, consulte o https://docs.ceph.com/en/latest/releases/pacific/#upgrading-non-cephadm-clusters.

Se o nó do qual você está fazendo upgrade é um OSD, execute o comando a seguir para evitar marcá-lo como out:

cephuser@adm > ceph osd add-noout SHORT_NODE_NAME

Substitua SHORT_NODE_NAME pelo nome abreviado do nó da forma como ele aparece na saída do comando ceph osd tree. Na entrada a seguir, os nomes abreviados de host são ses-min1 e ses-min2

root@master # ceph osd tree
ID   CLASS  WEIGHT   TYPE NAME       STATUS  REWEIGHT  PRI-AFF
 -1         0.60405  root default
-11         0.11691      host ses-min1
  4    hdd  0.01949          osd.4       up   1.00000  1.00000
  9    hdd  0.01949          osd.9       up   1.00000  1.00000
 13    hdd  0.01949          osd.13      up   1.00000  1.00000
[...]
 -5         0.11691      host ses-min2
  2    hdd  0.01949          osd.2       up   1.00000  1.00000
  5    hdd  0.01949          osd.5       up   1.00000  1.00000
[...]

Faça upgrade do OS subjacente para o SUSE Linux Enterprise Server 15 SP3:
- Se todos os nós do cluster foram registrados no SCC, execute zypper migration.
- Se os nós do cluster tiveram repositórios de software atribuídos manualmente, execute zypper dup seguido de reboot.
Após a reinicialização do nó, coloque em contêiner todos os daemons MON, MGR e OSD existentes nesse nó executando o seguinte comando no Master Salt:
```
root@master # salt MINION_ID state.apply ceph.upgrade.ses7.adopt
```
Substitua MINION_ID pelo ID do minion do qual você está fazendo upgrade. Você pode gerar uma lista de IDs de minions ao executar o comando salt-key -L no Master Salt.
Dica
Para ver o status e o andamento da adoção, verifique o Ceph Dashboard ou execute um dos seguintes comandos no Master Salt:
```
root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status
```
Após a conclusão bem-sucedida da adoção, cancele a definição do flag noout se o nó do qual você estiver fazendo upgrade for OSD:
```
cephuser@adm > ceph osd rm-noout SHORT_NODE_NAME
```

10.4 Fazendo upgrade de nós de gateway #

A seguir, faça upgrade dos nós de gateway separados (Gateway do Samba, Servidor de Metadados, Gateway de Objetos, NFS Ganesha ou iSCSI Gateway). Faça upgrade do OS subjacente para o SUSE Linux Enterprise Server 15 SP3 para cada nó:

Se todos os nós do cluster foram registrados no SUSE Customer Center, execute o comando zypper migration.
Se os nós do cluster tiveram repositórios de software atribuídos manualmente, execute o comando zypper dup seguido do comando reboot.

Esta etapa também vale para qualquer nó que faça parte do cluster, mas que ainda não recebeu nenhuma função (em caso de dúvida, verifique a lista de hosts no Master Salt gerada pelo comando salt-key -L e compare-a com a saída do comando salt-run upgrade.status).

Quando o upgrade do OS é feito em todos os nós do cluster, a próxima etapa é instalar o pacote ceph-salt e aplicar a configuração do cluster. Os serviços de gateway reais são reimplantados no modo em container no final do procedimento de upgrade.

Nota

Os serviços Servidor de Metadados e Gateway de Objetos ficam indisponíveis a partir do momento do upgrade para o SUSE Linux Enterprise Server 15 SP3 até serem reimplantados no final do procedimento de upgrade.

10.5 Instalando o `ceph-salt` e aplicando a configuração do cluster #

Antes de iniciar o procedimento de instalação do ceph-salt e aplicar a configuração do cluster, verifique o status do cluster e do upgrade executando os seguintes comandos:

root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status

Remova os Crons rbd_exporter e rgw_exporter criados pelo DeepSea. No Master Salt, execute o comando rootcrontab -e como para editar o crontab. Apague os seguintes itens, se houver:

# SALT_CRON_IDENTIFIER:deepsea rbd_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/rbd.sh > \
 /var/lib/prometheus/node-exporter/rbd.prom 2> /dev/null
# SALT_CRON_IDENTIFIER:Prometheus rgw_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/ceph_rgw.py > \
 /var/lib/prometheus/node-exporter/ceph_rgw.prom 2> /dev/null

Exporte a configuração do cluster do DeepSea executando os seguintes comandos:

root@master # salt-run upgrade.ceph_salt_config > ceph-salt-config.json
root@master # salt-run upgrade.generate_service_specs > specs.yaml

Desinstale o DeepSea e instale o ceph-salt no Master Salt:

root@master # zypper remove 'deepsea*'
root@master # zypper install ceph-salt

Reinicie o Master Salt e sincronize os módulos do Salt:

root@master # systemctl restart salt-master.service
root@master # salt \* saltutil.sync_all

Importe a configuração do cluster do DeepSea para ceph-salt:
```
root@master # ceph-salt import ceph-salt-config.json
```
Gere as chaves SSH para comunicação do nó do cluster:
```
root@master # ceph-salt config /ssh generate
```
Dica
Verifique se a configuração do cluster foi importada do DeepSea e especifique as opções que possam ter sido perdidas:
```
root@master # ceph-salt config ls
```
Para ver uma descrição completa da configuração do cluster, consulte a Seção 7.2, “Configurando as propriedades do cluster”.
Aplique a configuração e habilite o cephadm:
```
root@master # ceph-salt apply
```
Se for necessário inserir o URL de registro do container local e as credenciais de acesso, siga as etapas descritas na Seção 7.2.10, “Usando o registro do container”.
Se você não usa imagens de container do registry.suse.com, mas usa o registro configurado localmente, informe a imagem de container que o Ceph usará executando o comando:
```
root@master # ceph config set global container_image IMAGE_NAME
```
Por exemplo:
```
root@master # ceph config set global container_image 192.168.121.1:5000/my/ceph/image
```
Pare e desabilite os daemons ceph-crash do SUSE Enterprise Storage 6. Novos formulários em container desses daemons são iniciados automaticamente mais tarde.
```
root@master # salt '*' service.stop ceph-crash
root@master # salt '*' service.disable ceph-crash
```

10.6 Fazendo upgrade e adotando a pilha de monitoramento #

O procedimento a seguir adota todos os componentes da pilha de monitoramento (consulte o Capítulo 16, Monitoramento e alerta para obter mais detalhes).

Pause o orquestrador:
```
cephuser@adm > ceph orch pause
```

Em qualquer nó que esteja executando o Prometheus, o Grafana e o Alertmanager (por padrão, o Master Salt), execute os seguintes comandos:

cephuser@adm > cephadm adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name grafana.$(hostname)

Dica

Se você não executa o registro de imagem de container padrão registry.suse.com, precisa especificar a imagem que será usada em cada comando, por exemplo:

cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/prometheus-server:2.32.1 \
  adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/prometheus-alertmanager:0.21.0 \
  adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/grafana:7.5.12 \
 adopt --style=legacy --name grafana.$(hostname)

As imagens de container necessárias e suas respectivas versões estão listadas em Seção 16.1, “Configurando imagens personalizadas ou locais”.

Remova Node-Exporter de todos os nós. O Node-Exporter não precisa ser migrado e será reinstalado como um container quando o arquivo specs.yaml for aplicado.
```
> sudo zypper rm golang-github-prometheus-node_exporter
```
Se preferir, remova o Node-Exporter de todos os nós simultaneamente usando o Salt no nó de admin:
```
root@master # salt '*' pkg.remove golang-github-prometheus-node_exporter
```
Aplique as especificações de serviço que você já exportou do DeepSea:
```
cephuser@adm > ceph orch apply -i specs.yaml
```
Dica
Se você não executa o registro de imagem de container padrão registry.suse.com, mas um registro de container local, configure o cephadm para usar a imagem de container do registro local para a implantação do Node-Exporter antes de implantá-lo. Do contrário, você poderá ignorar com segurança esta etapa e o aviso a seguir.
```
cephuser@adm > ceph config set mgr mgr/cephadm/container_image_node_exporter QUALIFIED_IMAGE_PATH
```
Verifique se todas as imagens de container dos serviços de monitoramento apontam para o registro local, não apenas para o Node-Exporter. Esta etapa requer que você faça isso apenas para o Node-Exporter, mas é recomendável definir todas as imagens de container de monitoramento no cephadm para apontar para o registro local neste ponto.
Se você não fizer isso, as novas implantações de serviços de monitoramento e as reimplantações usarão a configuração cephadm padrão, e você talvez não consiga implantar serviços (no caso de implantações isoladas (air-gapped)) ou tenha serviços implantados com versões misturadas.
Encontre uma descrição de como o cephadm precisa ser configurado para usar imagens de container do registro local no Seção 16.1, “Configurando imagens personalizadas ou locais”.
Continue o orquestrador:
```
cephuser@adm > ceph orch resume
```

10.7 Reimplantação do serviço de gateway #

10.7.1 Fazendo upgrade do Gateway de Objetos #

No SUSE Enterprise Storage 7.1, os Gateways de Objetos são sempre configurados com um domínio, o que permite multissite no futuro (consulte o Seção 21.13, “Gateways de Objetos multissite” para obter mais detalhes). Se você usou uma configuração de site único do Gateway de Objetos no SUSE Enterprise Storage 6, siga estas etapas para adicionar um domínio. Se você não planeja usar a funcionalidade multissite, pode usar o padrão para os nomes de domínio, grupo de zonas e zona.

Crie um novo domínio:

cephuser@adm > radosgw-admin realm create --rgw-realm=REALM_NAME --default

Opcionalmente, renomeie a zona padrão e o grupo de zonas.

cephuser@adm > radosgw-admin zonegroup rename \
 --rgw-zonegroup default \
 --zonegroup-new-name=ZONEGROUP_NAME
cephuser@adm > radosgw-admin zone rename \
 --rgw-zone default \
 --zone-new-name ZONE_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME

Configure o grupo de zonas master:

cephuser@adm > radosgw-admin zonegroup modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --master --default

Configure a zona master. Para isso, você precisará da ACCESS_KEY e da SECRET_KEY de um usuário do Gateway de Objetos com o flag system habilitado. O usuário costuma ser o admin. Para obter a ACCESS_KEY e a SECRET_KEY, execute radosgw-admin user info --uid admin --rgw-zone=NOME_DA_ZONA.
```
cephuser@adm > radosgw-admin zone modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --rgw-zone=ZONE_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --access-key=ACCESS_KEY \
 --secret=SECRET_KEY \
 --master --default
```

Confirme a configuração atualizada:

cephuser@adm > radosgw-admin period update --commit

Para colocar o serviço Gateway de Objetos em container, crie o respectivo arquivo de especificação conforme descrito na Seção 8.3.4, “Implantando Gateways de Objetos” e aplique-o.

cephuser@adm > ceph orch apply -i RGW.yml

10.7.2 Fazendo upgrade do NFS Ganesha #

Importante

O NFS Ganesha suporta o NFS versão 4.1 e mais recente. Ele não suporta o NFS versão 3.

Veja a seguir como migrar um serviço NFS Ganesha existente que executa o Ceph Nautilus para um container do NFS Ganesha que executa o Ceph Octopus.

Atenção

A documentação a seguir requer que você já tenha feito upgrade dos serviços básicos do Ceph.

O NFS Ganesha armazena a configuração adicional por daemon e a exporta para um pool RADOS. O pool RADOS configurado pode ser encontrado na linha watch_url do bloco RADOS_URLS no arquivo ganesha.conf. Por padrão, esse pool será denominado ganesha_config.

Antes de tentar qualquer migração, é altamente recomendável fazer uma cópia dos objetos de configuração de exportação e daemon localizados no pool RADOS. Para localizar o pool RADOS configurado, execute o seguinte comando:

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

Para listar o conteúdo do pool RADOS:

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

Para copiar os objetos RADOS:

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

Para cada nó, qualquer serviço existente do NFS Ganesha precisa ser interrompido e, em seguida, substituído por um container gerenciado pelo cephadm.

Pare e desabilite o serviço NFS Ganesha existente:

cephuser@adm > systemctl stop nfs-ganesha
cephuser@adm > systemctl disable nfs-ganesha

Depois que o serviço NFS Ganesha existente for interrompido, um novo serviço poderá ser implantado em um container usando o cephadm. Para fazer isso, você precisa criar uma especificação de serviço que contenha um service_id, que será usado para identificar esse novo cluster do NFS, o nome de host do nó que estamos migrando listado como host na especificação de posicionamento e o pool RADOS e o namespace que contêm os objetos de exportação do NFS configurados. Por exemplo:
```
service_type: nfs
service_id: SERVICE_ID
placement:
  hosts:
  - node2
  pool: ganesha_config
  namespace: ganesha
```
Para obter mais informações sobre como criar uma especificação de posicionamento, consulte a Seção 8.2, “Especificação de serviço e posicionamento”.

Aplique a especificação de posicionamento:

cephuser@adm > ceph orch apply -i FILENAME.yaml

Confirme se o daemon do NFS Ganesha está em execução no host:

cephuser@adm > ceph orch ps --daemon_type nfs
NAME           HOST   STATUS         REFRESHED  AGE  VERSION  IMAGE NAME                                IMAGE ID      CONTAINER ID
nfs.foo.node2  node2  running (26m)  8m ago     27m  3.3      registry.suse.com/ses/7.1/ceph/ceph:latest  8b4be7c42abd  c8b75d7c8f0d

Repita essas etapas para cada nó do NFS Ganesha. Você não precisa criar uma especificação de serviço separada para cada nó. É suficiente adicionar o nome de host de cada nó à especificação do serviço NFS existente e reaplicá-la.

É possível migrar as exportações existentes de duas maneiras diferentes:

Recriação ou reatribuição manual usando o Ceph Dashboard.
Cópia manual do conteúdo de cada objeto RADOS por daemon para a configuração comum recém-criada do NFS Ganesha.

Procedimento 10.1: Copiando manualmente as exportações para o arquivo de configuração comum do NFS Ganesha #

Determine a lista de objetos RADOS por daemon:

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > DAEMON_OBJS=$(rados $RADOS_ARGS ls | grep 'conf-')

Faça uma cópia dos objetos RADOS por daemon:

cephuser@adm > for obj in $DAEMON_OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 20K
drwxr-xr-x 2 root root 4.0K Sep 8 16:51 .
drwxr-xr-x 3 root root 4.0K Sep 8 16:47 ..
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-nfs.SERVICE_ID
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node3

Classifique e faça a fusão em uma única lista de exportações:

cephuser@adm > cat conf-* | sort -u > conf-nfs.SERVICE_ID
cephuser@adm > cat conf-nfs.foo
%url "rados://ganesha_config/ganesha/export-1"
%url "rados://ganesha_config/ganesha/export-2"
%url "rados://ganesha_config/ganesha/export-3"
%url "rados://ganesha_config/ganesha/export-4"

Grave o novo arquivo de configuração comum do NFS Ganesha:

cephuser@adm > rados $RADOS_ARGS put conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID

Notifique o daemon do NFS Ganesha:
```
cephuser@adm > rados $RADOS_ARGS notify conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID
```
Nota
Essa ação fará com que o daemon recarregue a configuração.

Após a migração bem-sucedida do serviço, será possível remover o serviço NFS Ganesha baseado no Nautilus.

Remova o NFS Ganesha:

cephuser@adm > zypper rm nfs-ganesha
Reading installed packages...
Resolving package dependencies...
The following 5 packages are going to be REMOVED:
  nfs-ganesha nfs-ganesha-ceph nfs-ganesha-rados-grace nfs-ganesha-rados-urls nfs-ganesha-rgw
5 packages to remove.
After the operation, 308.9 KiB will be freed.
Continue? [y/n/v/...? shows all options] (y): y
(1/5) Removing nfs-ganesha-ceph-2.8.3+git0.d504d374e-3.3.1.x86_64 .................................................................................................................................................................................................................................................................................................[done]
(2/5) Removing nfs-ganesha-rgw-2.8.3+git0.d504d374e-3.3.1.x86_64 ..................................................................................................................................................................................................................................................................................................[done]
(3/5) Removing nfs-ganesha-rados-urls-2.8.3+git0.d504d374e-3.3.1.x86_64 ...........................................................................................................................................................................................................................................................................................[done]
(4/5) Removing nfs-ganesha-rados-grace-2.8.3+git0.d504d374e-3.3.1.x86_64 ..........................................................................................................................................................................................................................................................................................[done]
(5/5) Removing nfs-ganesha-2.8.3+git0.d504d374e-3.3.1.x86_64 ......................................................................................................................................................................................................................................................................................................[done]
Additional rpm output:
warning: /etc/ganesha/ganesha.conf saved as /etc/ganesha/ganesha.conf.rpmsave

Remova as configurações do cluster legado do Ceph Dashboard:

cephuser@adm > ceph dashboard reset-ganesha-clusters-rados-pool-namespace

10.7.3 Fazendo upgrade do servidor de metadados #

Ao contrário dos MONs, MGRs e OSDs, o Servidor de Metadados não pode ser adotado no local. Em vez disso, você precisa reimplantá-lo em containers usando o orquestrador do Ceph.

Execute o comando ceph fs ls para obter o nome do seu sistema de arquivos, por exemplo:

cephuser@adm > ceph fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

Crie um novo arquivo de especificação de serviço mds.yml, conforme descrito na Seção 8.3.3, “Implantando servidores de metadados”, usando o nome do sistema de arquivos como o service_id e especificando os hosts que executarão os daemons MDS. Por exemplo:
```
service_type: mds
service_id: cephfs
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
```
Execute o comando ceph orch apply -i mds.yml para aplicar a especificação de serviço e iniciar os daemons MDS.

10.7.4 Fazendo upgrade do iSCSI Gateway #

Para fazer upgrade do iSCSI Gateway, é necessário reimplantá-lo em containers usando o orquestrador do Ceph. Se você tiver vários iSCSI Gateways, precisará reimplantá-los um por um para reduzir o tempo de espera do serviço.

Pare e desabilite os daemons iSCSI existentes em cada nó do iSCSI Gateway:

> sudo systemctl stop rbd-target-gw
> sudo systemctl disable rbd-target-gw
> sudo systemctl stop rbd-target-api
> sudo systemctl disable rbd-target-api

Crie uma especificação de serviço para o iSCSI Gateway conforme descrito na Seção 8.3.5, “Implantando Gateways iSCSI”. Para isso, você precisa das configurações pool, trusted_ip_list e api_* do arquivo /etc/ceph/iscsi-gateway.cfg existente. Se você tem o suporte a SSL habilitado (api_secure = true), precisa também do certificado SSL (/etc/ceph/iscsi-gateway.crt) e da chave (/etc/ceph/iscsi-gateway.key).
Por exemplo, se /etc/ceph/iscsi-gateway.cfg contém o seguinte:
```
[config]
cluster_client_name = client.igw.ses-min5
pool = iscsi-images
trusted_ip_list = 10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202
api_port = 5000
api_user = admin
api_password = admin
api_secure = true
```
Você precisa criar o seguinte arquivo de especificação de serviço iscsi.yml:
```
service_type: iscsi
service_id: igw
placement:
  hosts:
  - ses-min5
spec:
  pool: iscsi-images
  trusted_ip_list: "10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202"
  api_port: 5000
  api_user: admin
  api_password: admin
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----
```
Nota
As configurações pool, trusted_ip_list, api_port, api_user, api_password e api_secure são idênticas às do arquivo /etc/ceph/iscsi-gateway.cfg. É possível copiar os valores ssl_cert e ssl_key dos arquivos de chave e de certificado SSL existentes. Verifique se eles estão indentados corretamente e se o caractere barra vertical | aparece no final das linhas ssl_cert: e ssl_key: (veja o conteúdo do arquivo iscsi.yml acima).
Execute o comando ceph orch apply -i iscsi.yml para aplicar a especificação de serviço e iniciar os daemons do iSCSI Gateway.
Remova o pacote ceph-iscsi antigo de cada um dos nós de gateway iSCSI existentes:
```
cephuser@adm > zypper rm -u ceph-iscsi
```

10.8 Limpeza após o upgrade #

Após o upgrade, execute as seguintes etapas de limpeza:

Verifique a versão atual do Ceph para conferir se o upgrade do cluster foi bem-sucedido:
```
cephuser@adm > ceph versions
```

Garanta que nenhum OSD antigo ingresse no cluster:

cephuser@adm > ceph osd require-osd-release pacific

Defina o pg_autoscale_mode dos pools existentes, se necessário:
Importante
Por padrão, os pools no SUSE Enterprise Storage 6 tinham o pg_autoscale_mode definido como warn. Isso resultava em uma mensagem de aviso em caso de número de PGs abaixo do ideal, mas o dimensionamento automático não era feito. O padrão no SUSE Enterprise Storage 7.1 é a opção pg_autoscale_mode definida como on para que os novos pools e os PGs sejam dimensionados automaticamente. O processo de upgrade não muda automaticamente o pg_autoscale_mode dos pools existentes. Para mudá-lo para on e aproveitar todos os benefícios do dimensionador automático, consulte as instruções no Seção 17.4.12, “Habilitando o dimensionador automático de PG”.
Encontre mais detalhes no Seção 17.4.12, “Habilitando o dimensionador automático de PG”.

Impedir clientes pré-Luminous:

cephuser@adm > ceph osd set-require-min-compat-client luminous

Habilite o módulo de balanceador:
```
cephuser@adm > ceph balancer mode upmap
cephuser@adm > ceph balancer on
```
Encontre mais detalhes no Seção 29.1, “Balanceador”.
Se preferir, habilite o módulo de telemetria:
```
cephuser@adm > ceph mgr module enable telemetry
cephuser@adm > ceph telemetry on
```
Encontre mais detalhes no Seção 29.2, “Habilitando o módulo de telemetria”.

10 Upgrade do SUSE Enterprise Storage 6 para 7.1 #

10.1 Antes de fazer upgrade #

10.1.1 Pontos a serem considerados #

10.1.2 Fazendo backup da configuração e dos dados do cluster #

10.1.3 Verificando etapas do upgrade anterior #

10.1.4 Atualizando os nós e verificando a saúde do cluster #

10.1.4.1 Desabilitar clientes não seguros #

10.1.5 Verificando o acesso a repositórios do software e imagens de container #

10.1.5.1 Repositórios do software #

10.1.5.2 Imagens de container #

10.2 Fazendo upgrade do Master Salt #

10.3 Fazendo upgrade dos nós MON, MGR e OSD #

10.4 Fazendo upgrade de nós de gateway #

10.5 Instalando o ceph-salt e aplicando a configuração do cluster #

10.6 Fazendo upgrade e adotando a pilha de monitoramento #

10.7 Reimplantação do serviço de gateway #

10.7.1 Fazendo upgrade do Gateway de Objetos #

10.7.2 Fazendo upgrade do NFS Ganesha #

10.7.3 Fazendo upgrade do servidor de metadados #

10.7.4 Fazendo upgrade do iSCSI Gateway #

10.8 Limpeza após o upgrade #

10.5 Instalando o `ceph-salt` e aplicando a configuração do cluster #