ceph-deploy
) para 5Este capítulo apresenta as etapas de upgrade do SUSE Enterprise Storage de versões anteriores para a atual.
Nos detalhes da versão, você encontra mais informações sobre o que mudou desde a versão anterior do SUSE Enterprise Storage. Consulte os detalhes da versão para verificar se:
seu hardware precisa de considerações especiais.
qualquer pacote de software usado foi significativamente modificado.
são necessárias precauções especiais para a instalação.
Os detalhes da versão também apresentam informações que não puderam ser incluídas a tempo no manual. Eles também incluem notas sobre problemas conhecidos.
Após instalar o pacote release-notes-ses, encontre os detalhes da versão no diretório local /usr/share/doc/release-notes
ou no site https://www.suse.com/releasenotes/.
Considere os seguintes itens antes de iniciar o procedimento de upgrade:
Antes de fazer upgrade do cluster do Ceph, você precisa registrar corretamente o SUSE Linux Enterprise Server e o SUSE Enterprise Storage subjacentes no SCC ou na SMT. Você poderá fazer upgrade dos daemons no cluster enquanto ele estiver online e em execução. Alguns tipos de daemons dependem de outros. Por exemplo, os Ceph Object Gateways dependem dos daemons Ceph Monitors e Ceph OSD. Recomendamos o upgrade nesta ordem:
Ceph Monitors
Ceph Managers
Ceph OSDs
Servidores de Metadados
Object Gateways
iSCSI Gateways
NFS Ganesha
Remova os instantâneos de sistema de arquivos que não são necessários das partições de nós do sistema operacional. Esse procedimento garante espaço livre suficiente no disco durante o upgrade.
É recomendável verificar a saúde do cluster antes de iniciar o procedimento de upgrade.
Recomendamos fazer upgrade de todos os daemons de determinado tipo (por exemplo, todos os daemons monitor ou OSD) um de cada vez para garantir que todos sejam da mesma versão. Recomendamos também fazer upgrade de todos os daemons no cluster antes de você tentar usar uma nova funcionalidade em uma versão.
Após o upgrade de todos os daemons de um tipo específico, verifique o status deles.
Verifique se cada monitor reingressou no quorum após o upgrade de todos os monitores:
root #
ceph mon stat
Verifique se cada daemon Ceph OSD reingressou no cluster após o upgrade de todos os OSDs:
root #
ceph osd stat
require-osd-release luminous
Quando é feito o upgrade do último OSD para o SUSE Enterprise Storage 5, os nós do monitor detectam que todos os OSDs estão executando a versão “luminous” do Ceph e podem reclamar que o flag require-osd-release luminous
do osdmap não está definido. Nesse caso, você precisa definir esse flag manualmente para confirmar que, agora que o upgrade do cluster foi feito para “luminous”, não é possível revertê-lo para a versão menos eficiente “jewel” do Ceph. Defina o flag executando o seguinte comando:
root@minion >
sudo ceph osd require-osd-release luminous
Após a conclusão do comando, o aviso desaparecerá.
Nas novas instalações do SUSE Enterprise Storage 5, esse flag é definido automaticamente quando os Ceph Monitors criam o osdmap inicial. Dessa forma, nenhuma ação do usuário final é necessária.
Desde o SUSE Enterprise Storage 5, por padrão, os OSDs são implantados usando o BlueStore em vez do FileStore. Embora o BlueStore suporte criptografia, os Ceph OSDs são implantados sem criptografia, por padrão. O procedimento a seguir descreve as etapas para criptografar os OSDs durante o processo de upgrade. Vamos supor que ambos os discos de dados e WAL/BD que serão usados para implantação do OSD estejam limpos, sem partições. Se os discos já foram usados, limpe-os seguindo o procedimento descrito na Etapa 13.
Você precisa implantar os OSDs criptografados um por um, não ao mesmo tempo. O motivo disso é que os dados do OSD são esvaziados, e o cluster passa por várias iterações de redistribuição.
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.
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.2root@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.
Você precisa ter o seguinte software instalado e atualizado para as versões mais recentes dos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciar o procedimento de upgrade:
SUSE Linux Enterprise Server 12 SP2
SUSE Enterprise Storage 4
Além disso, antes de iniciar o upgrade, você precisa fazer upgrade do nó master Salt para o SUSE Linux Enterprise Server 12 SP3 e o SUSE Enterprise Storage 5 executando o comando zypper migration
(ou seu método de upgrade preferencial).
Verifique se o serviço AppArmor está em execução e desabilite-o em cada nó do cluster. Inicie o módulo AppArmor do YaST, selecione
(Configurações) e, em seguida, desative a caixa de seleção (Habilitar Apparmor). Para confirmar, clique em (Concluído).O SUSE Enterprise Storage não funcionará com o AppArmor habilitado.
Embora o cluster permaneça totalmente funcional durante o upgrade, o DeepSea define o flag "noout", que impede o Ceph de redistribuir os dados durante o tempo de espera e, portanto, evita transferências de dados desnecessárias.
Para otimizar o processo de upgrade, o DeepSea faz upgrade dos nós na ordem, com base nas funções atribuídas, conforme recomendado pelo upstream do Ceph: MONs, MGRs, OSDs, MDS, RGW, IGW e NFS Ganesha.
O DeepSea não poderá evitar que a ordem recomendada seja violada se um nó executar vários serviços.
Embora o cluster do Ceph permaneça operacional durante o upgrade, os nós podem ser reinicializados para aplicar novas versões de kernel, por exemplo. Para reduzir as operações de E/S em espera, é recomendável recusar solicitações recebidas durante o processo de upgrade.
O upgrade do cluster pode levar muito tempo: aproximadamente o tempo necessário para fazer upgrade de uma máquina multiplicado pelo número de nós do cluster.
A partir do Ceph Luminous, a opção de configuração osd crush location
não é mais suportada. Atualize os arquivos de configuração do DeepSea para usar crush location
antes do upgrade.
Para fazer upgrade do cluster do SUSE Enterprise Storage 4 para a versão 5, siga estas etapas:
Defina a nova ordem de classificação de objetos internos. Execute:
root #
ceph osd set sortbitwise
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.
Se você registrou seus sistemas com o SUSEConnect e usa SCC/SMT, nenhuma outra ação é necessária. Continue na Etapa 4.
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-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot #
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
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
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:
Execute a Fase 0 para habilitar a API REST do Salt:
root@master #
salt-run state.orch ceph.stage.0
Execute a Fase 1 para criar o subdiretório role-mgr/
:
root@master #
salt-run state.orch ceph.stage.1
Edite o 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.
Execute a Fase 2 para atualizar o Pillar:
root@master #
salt-run state.orch ceph.stage.2
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.
Execute a Fase 3 para implantar Ceph Managers:
root@master #
salt-run state.orch ceph.stage.3
Execute a Fase 4 para configurar o openATTIC apropriadamente:
root@master #
salt-run state.orch ceph.stage.4
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.
Se o estado do cluster permanecer como “HEALTH_ERR” por mais do que 300 segundos, ou se um dos serviços para cada função atribuída ficar inativo por mais do que 900 segundos, haverá falha no upgrade. Nesse caso, tente localizar o problema, resolva-o e execute o procedimento de upgrade novamente. Em ambientes virtualizados, observe que os tempos de espera são mais curtos.
Após o upgrade do SUSE Enterprise Storage 5, os OSDs do FileStore precisarão de aproximadamente cinco minutos a mais para serem iniciados, já que o OSD fará uma conversão única de seus arquivos no disco.
Quando você precisa saber as versões dos componentes e nós individuais do cluster (por exemplo, para saber se todos os seus nós estão realmente no mesmo nível de patch após o upgrade), você pode executar
root@master #
salt-run status.report
O comando analisa os minions Salt conectados, verifica os números de versão do Ceph, Salt e SUSE Linux Enterprise Server e apresenta um relatório a você com a versão da maioria dos nós e os nós que têm uma versão diferente da maioria.
O OSD do BlueStore é um novo back end para os daemons OSD. Ele é a opção padrão desde o SUSE Enterprise Storage 5. Comparado com o FileStore, que armazena objetos como arquivos em um sistema de arquivos XFS, o BlueStore pode proporcionar melhor desempenho, porque armazena os objetos diretamente no dispositivo de blocos subjacente. O BlueStore também disponibiliza outros recursos, como compactação incorporada e sobregravações EC, que não estão disponíveis no FileStore.
Especificamente no BlueStore, um OSD tem um dispositivo “wal” (Registro Write-Ahead) e um dispositivo “db” (banco de dados RocksDB). O banco de dados RocksDB armazena os metadados para um OSD do BlueStore. Por padrão, esses dois dispositivos residirão no mesmo dispositivo como um OSD, mas qualquer um deles pode ser inserido em uma mídia mais rápida ou diferente.
No SES5, tanto o FileStore quanto o BlueStore são suportados, e os OSDs do FileStore e do BlueStore podem coexistir em um único cluster. Durante o procedimento de upgrade do SUSE Enterprise Storage, os OSDs do FileStore não são convertidos automaticamente em BlueStore. Os recursos específicos do BlueStore não estarão disponíveis nos OSDs que não foram migrados para o BlueStore.
Antes da conversão em BlueStore, os OSDs precisam executar o SUSE Enterprise Storage 5. A conversão é um processo lento, pois todos os dados são regravados duas vezes. O processo de migração pode levar muito tempo para ser concluído, mas não há nenhuma interrupção do cluster, e todos os clientes podem continuar acessando o cluster durante esse período. No entanto, é comum uma redução no desempenho durante a migração. Isso é causado pela redistribuição e preenchimento de dados dos cluster.
Siga o procedimento abaixo para migrar os OSDs do FileStore para o BlueStore:
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
Migre os perfis de hardware:
root@master #
salt-run state.orch ceph.migrate.policy
Esse executor migra quaisquer perfis de hardware que o arquivo policy.cfg
usa atualmente. Ele processa o policy.cfg
, encontra qualquer perfil de hardware que usa a estrutura de dados original e converte-a na nova estrutura de dados. O resultado é um novo perfil de hardware chamado “migrated-nome_original”. O policy.cfg
também é atualizado.
Se a configuração original tinha diários separados, a configuração do BlueStore usará o mesmo dispositivo do “wal” e do “db” para esse OSD.
O DeepSea migra os OSDs definindo o peso deles como 0, o que “aspira” os dados até esvaziar o OSD. Você pode migrar os OSDs um por um ou todos ao mesmo tempo. Em qualquer um dos casos, quando o OSD estiver vazio, a orquestração o removerá e o recriará com a nova configuração.
Use ceph.migrate.nodes
se você tiver um grande número de nós de armazenamento físico ou poucos dados. Se um nó representa menos do que 10% da sua capacidade, o ceph.migrate.nodes
pode ser um pouco mais rápido para mover todos os dados desses OSDs em paralelo.
Se você não tem certeza sobre qual método usar, ou se o site tem poucos nós de armazenamento (por exemplo, cada nó tem mais do que 10% dos dados do cluster), selecione ceph.migrate.osds
.
Para migrar os OSDs um de cada vez, execute:
root@master #
salt-run state.orch ceph.migrate.osds
Para migrar todos os OSDs em cada nó em paralelo, execute:
root@master #
salt-run state.orch ceph.migrate.nodes
Como a orquestração não apresenta comentários sobre o andamento da migração, use
root #
ceph osd tree
para ver quais OSDs têm um peso de zero periodicamente.
Após a migração para o BlueStore, o total de objetos permanecerá o mesmo, e a utilização do disco será quase igual.
ceph-deploy
) para 5 #Você precisa ter o seguinte software instalado e atualizado para as versões mais recentes dos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciar o procedimento de upgrade:
SUSE Linux Enterprise Server 12 SP2
SUSE Enterprise Storage 4
Escolha o master Salt para seu cluster. Se o Calamari está implantado no cluster, o nó Calamari já é o master Salt. Como alternativa, o nó de admin do qual você executou o comando ceph-deploy
se tornará o master Salt.
Antes de iniciar o procedimento a seguir, você precisa fazer upgrade do nó master Salt para o SUSE Linux Enterprise Server 12 SP3 e o SUSE Enterprise Storage 5 executando o comando zypper migration
(ou seu método de upgrade preferencial).
Para fazer upgrade do cluster do SUSE Enterprise Storage 4 que foi implantado com ceph-deploy
para a versão 5, siga estas etapas:
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-minionroot #
systemctl enable salt-minionroot #
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
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
Se você registrou seus sistemas com o SUSEConnect e usa SCC/SMT, nenhuma outra ação é necessária.
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-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot #
zypper ref
Defina a nova de ordem de classificação de objetos internos. Execute:
root@master #
ceph osd set sortbitwise
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-masterroot@master #
systemctl enable salt-masterroot@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:
Distribuirá todos os módulos do Salt e DeepSea necessários para todos os minions Salt.
Inspecionará o cluster do Ceph em execução e preencherá /srv/pillar/ceph/proposals
com um layout do cluster.
O /srv/pillar/ceph/proposals/policy.cfg
será criado com as funções correspondentes a todos os serviços do Ceph em execução detectados. Veja esse arquivo para verificar se cada um dos nós MON, OSD, RGW e MDS existentes tem as funções apropriadas. Os nós OSD serão importados para o subdiretório profile-import/
, portanto, você pode examinar os arquivos em /srv/pillar/ceph/proposals/profile-import/cluster/
e /srv/pillar/ceph/proposals/profile-import/stack/default/ceph/minions/
para confirmar se os OSDs foram capturados corretamente.
O policy.cfg
gerado apenas aplicará as funções dos serviços do Ceph detectados “role-mon”, “role-mgr”, “role-mds”, “role-rgw”, “role-admin” e “role-master” referentes ao nó master Salt. Quaisquer outras funções desejadas deverão ser adicionadas manualmente ao arquivo (consulte a Seção 4.5.1.2, “Atribuição de função”).
O ceph.conf
do cluster existente será gravado em /srv/salt/ceph/configuration/files/ceph.conf.import
.
O /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
incluirá o fsid do cluster, o cluster e as redes públicas, além de especificar a opção configuration_init: default-import
, que faz o DeepSea usar o arquivo de configuração ceph.conf.import
mencionado anteriormente, em vez de usar o gabarito /srv/salt/ceph/configuration/files/ceph.conf.j2
padrão do DeepSea.
Ceph.conf
personalizado
Se você precisa integrar o arquivo ceph.conf
com mudanças personalizadas, aguarde a conclusão bem-sucedida do processo de importação/upgrade. Em seguida, edite o arquivo /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
e comente na seguinte linha:
configuration_init: default-import
Grave o arquivo e siga as informações no Seção 1.11, “Arquivo ceph.conf
personalizado”.
Os vários chaveiros do cluster serão gravados nos seguintes diretórios:
/srv/salt/ceph/admin/cache/ /srv/salt/ceph/mon/cache/ /srv/salt/ceph/osd/cache/ /srv/salt/ceph/mds/cache/ /srv/salt/ceph/rgw/cache/
Verifique se os arquivos de chaveiro existem e se não há um arquivo de chaveiro no seguinte diretório (o Ceph Manager não existia antes do SUSE Enterprise Storage 5):
/srv/salt/ceph/mgr/cache/
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:
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.confroot@minion >
scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
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.ymlroot@master #
chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
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”.
Você precisa ter o seguinte software instalado e atualizado para as versões mais recentes dos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciar o procedimento de upgrade:
SUSE Linux Enterprise Server 12 SP2
SUSE Enterprise Storage 4
Para fazer upgrade do SUSE Enterprise Storage 4 implantado por meio do Crowbar para a versão 5, siga estas etapas:
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-clientroot@minion >
sudo systemctl disable chef-clientroot@minion >
sudo systemctl disable crowbar_joinroot@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
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-minionroot@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:
Remova a opção osd crush location hook
que foi incluída pelo Calamari.
Remova a opção public addr
da seção [mon]
.
Remova os números de porta da opção mon host
.
Se você estava executando o Object Gateway, o Crowbar implantou um arquivo /etc/ceph/ceph.conf.radosgw
à parte para manter os segredos do Keystone separados do arquivo ceph.conf
regular. O Crowbar também adicionou um arquivo /etc/systemd/system/ceph-radosgw@.service
personalizado. Como o DeepSea não oferece suporte a ele, é necessário removê-lo:
Anexe todas as seções [client.rgw....]
do arquivo ceph.conf.radosgw
ao /etc/ceph/ceph.conf
em todos os nós.
No nó do Object Gateway, execute o seguinte:
root@minion >
rm /etc/systemd/system/ceph-radosgw@.service
systemctl reenable ceph-radosgw@rgw.public.$hostname
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_clusterroot@master #
salt-run state.orch ceph.stage.1root@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:
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.confroot@minion >
scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
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.ymlroot@master #
chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
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 [...]
Se você registrou seus sistemas com o SUSEConnect e usa SCC/SMT, nenhuma outra ação é necessária.
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-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot #
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
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-0aroot@master #
salt d52-54-00-49-17-2a.example.com grains.set \ host public.d52-54-00-49-17-2aroot@master #
salt d52-54-00-76-21-bc.example.com grains.set \ host public.d52-54-00-76-21-bcroot@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.updatesroot@master #
salt target test.versionroot@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.0root@master #
salt-run state.orch ceph.stage.1root@master #
salt-run state.orch ceph.stage.2root@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.2root@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:
O Crowbar cria entradas em /etc/fstab
para cada OSD. Elas não são necessárias, portanto, apague-as.
O Calamari deixa uma tarefa programada do Salt em execução para verificar o status do cluster. Remova a tarefa:
root@master #
salt target schedule.delete ceph.heartbeat
Ainda restam alguns pacotes desnecessários instalados, a maioria deles relacionada a ruby gems e chef. Não é necessário removê-los, mas convém apagá-los executando zypper rm nome_pct
.
Você precisa ter o seguinte software instalado e atualizado para as versões mais recentes dos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciar o procedimento de upgrade:
SUSE Linux Enterprise Server 12 SP1
SUSE Enterprise Storage 3
Para fazer upgrade do cluster do SUSE Enterprise Storage 3 para a versão 5, siga as etapas descritas no Procedimento 5.1, “Etapas para aplicar a todos os nós do cluster (incluindo o nó Calamari)” e no Procedimento 5.2, “Etapas para aplicar ao nó master Salt”.