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

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

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

Verifique se o arquivo ceph.conf está atualizado nos nós relevantes do OSD:

root@minion > cat /etc/ceph/ceph.conf

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

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.

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

root # ceph osd set sortbitwise

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",

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

   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.

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.

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.

Faça upgrade dos minions Salt:

root@master # salt target state.apply ceph.updates.salt

Verifique se foi feito o upgrade de todos os minions Salt:

root@master # salt target test.version

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.

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

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

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.

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

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

Instale o pacote salt do SLE-12-SP2/SES4:

root # zypper install salt

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

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

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

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

root@master # ceph osd set sortbitwise

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",

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.

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

Verifique a presença de todos os minions Salt listando suas chaves:

root@master # salt-key -L

Adicione todas as chaves dos minions Salt ao master Salt incluindo o master minion:

root@master # salt-key -A -y

Verifique se as chaves de todos os minions Salt foram aceitas:

root@master # salt-key -L

Confirme se o software em seu nó master Salt está atualizado:

root@master # zypper migration

Instale o pacote deepsea:

root@master # zypper install deepsea

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.

Importe o cluster instalado pelo ceph-deploy existente:

root@master # salt-run populate.engulf_existing_cluster

O comando fará o seguinte:

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.

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

Execute a Fase 1 para criar todas as funções possíveis:

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

Gere os subdiretórios necessários em /srv/pillar/ceph/stack:

root@master # salt-run push.proposal

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.

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

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

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

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.

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

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

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

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.

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.

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.

Instale o DeepSea no master Salt:

root@master # zypper in deepsea

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.

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:

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:

Verifique se o ceph status funciona quando executado do master Salt:

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

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

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

   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.

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

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.

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

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

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

Efetue a limpeza restante: