ntpd
para o chronyd
policy.cfg
e implantando o Ceph Dashboard por meio do DeepSeaEste capítulo apresenta as etapas para fazer upgrade do SUSE Enterprise Storage 5.5 para a versão 6. Observe que a versão 5.5 é basicamente a versão 5 com todos os patches mais recentes aplicados.
O upgrade de versões do SUSE Enterprise Storage mais antigas do que a 5.5 não é suportado. Você precisa primeiro fazer upgrade para a versão mais recente do SUSE Enterprise Storage 5.5 e, em seguida, seguir as etapas neste capítulo.
Leia os detalhes da versão: onde você encontra mais informações sobre o que mudou desde a versão anterior do SUSE Enterprise Storage. Consulte os detalhes da versão para verificar se:
seu hardware precisa de considerações especiais.
qualquer pacote de software usado foi significativamente modificado.
são necessárias precauções especiais para a instalação.
Os detalhes da versão também apresentam informações que não puderam ser incluídas a tempo no manual. Eles também incluem notas sobre problemas conhecidos.
Após instalar o pacote release-notes-ses, encontre os detalhes da versão no diretório local /usr/share/doc/release-notes
ou no site https://www.suse.com/releasenotes/.
Se você fez upgrade da versão 4, verifique se o upgrade para a versão 5 foi concluído com êxito:
Verifique a existência do arquivo
/srv/salt/ceph/configuration/files/ceph.conf.import
Ele é criado pelo processo de importação durante o upgrade do SES 4 para 5. A opção configuration_init: default-import
também está definida no arquivo
/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
Se configuration_init
ainda está definido como default-import
, o cluster usa ceph.conf.import
como arquivo de configuração, e não o ceph.conf
padrão do DeepSea, que é compilado dos arquivos em
/srv/salt/ceph/configuration/files/ceph.conf.d/
Portanto, você precisa inspecionar se há qualquer configuração personalizada em ceph.conf.import
e, possivelmente, mover a configuração para um dos arquivos em
/srv/salt/ceph/configuration/files/ceph.conf.d/
Em seguida, remova a linha configuration_init: default-import
de
/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
Se você não fundir a configuração do ceph.conf.import
e remover a opção configuration_init: default-import
, nenhuma configuração padrão que fizer parte do DeepSea (armazenada em /srv/salt/ceph/configuration/files/ceph.conf.j2
) será aplicada ao cluster.
Verifique se o cluster usa o novo tipo de compartimento de memória “straw2”:
cephadm@adm >
ceph osd crush dump | grep straw
Verifique se o perfil “jewel” do Ceph foi usado:
cephadm@adm >
ceph osd crush dump | grep profile
Caso os clientes RBD antigos do kernel (mais antigos do que o SUSE Linux Enterprise Server 12 SP3) sejam usados, consulte o Seção 12.9, “Mapeando o RBD por meio de clientes antigos do kernel”. Recomendamos fazer upgrade dos clientes RBD antigos do kernel, se possível.
Se o openATTIC estiver localizado no Nó de Admin, ele estará disponível após o upgrade do nó. O novo Ceph Dashboard não estará disponível até você implantá-lo usando o DeepSea.
O upgrade do cluster pode levar algum tempo, aproximadamente o tempo necessário para fazer upgrade de uma máquina multiplicado pelo número de nós do cluster.
Não é possível fazer upgrade de um único nó durante a execução da versão anterior do SUSE Linux Enterprise Server, mas ele precisa ser reinicializado no instalador da nova versão. Portanto, os serviços que o nó fornece estarão indisponíveis por algum tempo. Os principais serviços do cluster ainda estarão disponíveis. Por exemplo, se um MON estiver inativo durante o upgrade, ainda haverá pelo menos dois MONs ativos. Os serviços de instância única estarão indisponíveis. Por exemplo, um único iSCSI Gateway.
Alguns tipos de daemons dependem de outros. Por exemplo, os Ceph Object Gateways dependem dos daemons Ceph MON e OSD. Recomendamos o upgrade nesta ordem:
Nó de Admin
Ceph Monitors/Ceph Managers
Servidores de Metadados
Ceph OSDs
Object Gateways
iSCSI Gateways
NFS Ganesha
Gateways do Samba
Se você usou o AppArmor no modo "complain" ou "enforce", precisa definir uma variável do pillar Salt antes do upgrade. Como o SUSE Linux Enterprise Server 15 SP1 está incluído com o AppArmor por padrão, o gerenciamento do AppArmor foi integrado à fase 0 do DeepSea. O comportamento padrão no SUSE Enterprise Storage 6 é remover o AppArmor e os perfis relacionados. Para manter o comportamento configurado no SUSE Enterprise Storage 5.5, verifique se uma das seguintes linhas está presente no arquivo /srv/pillar/ceph/stack/global.yml
antes de iniciar o upgrade:
apparmor_init: default-enforce
ou
apparmor_init: default-complain
A partir do SUSE Enterprise Storage 6, os nomes de MDS que começam com um dígito não são mais permitidos, e os daemons MDS se recusarão a ser iniciados. Você pode verificar se seus daemons têm esses nomes executando o comando ceph fs status
ou reiniciando um MDS e verificando a seguinte mensagem nos registros dele:
deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden in a future version. MDS names may not start with a numeric digit.
Se aparecer a mensagem acima, os nomes de MDS precisarão ser migrados antes de tentar fazer upgrade para o SUSE Enterprise Storage 6. O DeepSea inclui uma orquestração para automatizar esse tipo de migração. Os nomes de MDS que começam com um dígito receberão o prefixo “mds”.:
root@master #
salt-run state.orch ceph.mds.migrate-numerical-names
Se você tem configurações vinculadas a nomes MDS e seus daemons MDS têm nomes que começam com um dígito, verifique se as configurações também se aplicam aos novos nomes (com o prefixo “mds”). Considere a seguinte seção de exemplo no arquivo /etc/ceph/ceph.conf
:
[mds.123-my-mds] # config setting specific to MDS name with a name starting with a digit mds cache memory limit = 1073741824 mds standby for name = 456-another-mds
O orquestrator ceph.mds.migrate-numerical-names
mudará o nome do daemon MDS “123-my-mds” para “mds.123-my-mds”. Você precisa ajustar a configuração para refletir o novo nome:
[mds.mds,123-my-mds] # config setting specific to MDS name with the new name mds cache memory limit = 1073741824 mds standby for name = mds.456-another-mds
Esse procedimento adicionará os daemons MDS com os novos nomes antes de remover os daemons MDS antigos. O número de daemons MDS será o dobro por um curto período. Os clientes poderão acessar o CephFS com uma breve pausa para failover. Portanto, planeje a migração para momentos em que você espera pouca ou nenhuma carga do CephFS.
Embora a criação de backups da configuração e dos dados de um cluster não seja obrigatória, recomendamos enfaticamente o backup de arquivos de configuração e dados do cluster importantes. Consulte a Capítulo 3, Fazendo backup da configuração e dos dados do cluster para obter mais detalhes.
ntpd
para o chronyd
#
O SUSE Linux Enterprise Server 15 SP1 não usa mais o ntpd
para sincronizar o horário local do host. Em vez disso, ele usa o chronyd
. Você precisa migrar o daemon de sincronização de horário em cada nó do cluster. Você pode migrar para o chronyd
antes do cluster ou fazer upgrade do cluster e, depois disso, migrar para o chronyd
.
chronyd
antes do Upgrade do Cluster #Instale o pacote chrony :
root@minion >
zypper install chrony
Edite o arquivo de configuração do chronyd
/etc/chrony.conf
e adicione fontes de NTP da configuração atual do ntpd
ao /etc/ntp.conf
.
chronyd
Visite https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html para encontrar mais detalhes sobre como incluir fontes de horário na configuração do chronyd
.
Desabilite e pare o serviço ntpd
:
root@minion >
systemctl disable ntpd.service && systemctl stop ntpd.service
Inicie e habilite o serviço chronyd
:
root@minion >
systemctl start chronyd.service && systemctl enable chronyd.service
Verifique o status do chrony:
root@minion >
chronyc tracking
chronyd
após o Upgrade do Cluster #Durante o upgrade do cluster, adicione os seguintes repositórios de software:
SLE-Module-Legacy15-SP1-Pool
SLE-Module-Legacy15-SP1-Updates
Faça upgrade do cluster para a versão 6.
Edite o arquivo de configuração do chronyd
/etc/chrony.conf
e adicione fontes de NTP da configuração atual do ntpd
ao /etc/ntp.conf
.
chronyd
Visite https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html para encontrar mais detalhes sobre como incluir fontes de horário na configuração do chronyd
.
Desabilite e pare o serviço ntpd
:
root@minion >
systemctl disable ntpd.service && systemctl stop ntpd.service
Inicie e habilite o serviço chronyd
:
root@minion >
systemctl start chronyd.service && systemctl enable chronyd.service
Migre do ntpd
para o chronyd
.
Verifique o status do chrony:
root@minion >
chronyc tracking
Remova os repositórios de software legados que você adicionou para manter o ntpd
no sistema durante o processo de upgrade.
Aplique os patches mais recentes a todos os nós do cluster antes do upgrade.
Verifique se os repositórios necessários estão configurados em cada nó do cluster. Para listar todos os repositórios disponíveis, execute
root@minion >
zypper lr
O SUSE Enterprise Storage 5.5 requer:
SLES12-SP3-Installer-Updates
SLES12-SP3-Pool
SLES12-SP3-Updates
SUSE-Enterprise-Storage-5-Pool
SUSE-Enterprise-Storage-5-Updates
O Gateway NFS/SMB no SLE-HA no SUSE Linux Enterprise Server 12 SP3 requer:
SLE-HA12-SP3-Pool
SLE-HA12-SP3-Updates
Se você estiver usando um dos sistemas de propagação em fases do repositório (SMT, RMT ou SUSE Manager), crie um novo nível de patch congelado para a versão atual e nova do SUSE Enterprise Storage.
Mais informações podem ser encontradas na:
Aplique os patches mais recentes do SUSE Enterprise Storage 5.5 e do SUSE Linux Enterprise Server 12 SP3 a cada nó do cluster do Ceph. Verifique se os repositórios de software corretos estão conectados a cada nó do cluster (consulte a Seção 6.4.1, “Repositórios de software necessários”) e execute a fase 0 do DeepSea:
root@master #
salt-run state.orch ceph.stage.0
Após a conclusão da fase 0, verifique se o status de cada nó do cluster inclui “HEALTH_OK”. Se não incluir, resolva o problema antes das possíveis reinicializações nas próximas etapas.
Execute o zypper ps
para verificar se há processos que possam ser executados com bibliotecas ou binários desatualizados e, se houver, faça a reinicialização.
Verifique se o kernel em execução é o mais recente disponível e, se não for, faça a reinicialização. Verifique as saídas dos seguintes comandos:
cephadm@adm >
uname -acephadm@adm >
rpm -qa kernel-default
Verifique se o pacote ceph é da versão 12.2.12 ou mais recente. Verifique se o pacote deepsea é da versão 0.8.9 ou mais recente.
Se você já usou qualquer uma das configurações de bluestore_cache
, elas não estão mais em vigor a partir do ceph
versão 12.2.10. A nova configuração bluestore_cache_autotune
que, por padrão, está definida como “true”, desabilita o dimensionamento manual do cache. Para ativar o comportamento antigo, você precisa definir bluestore_cache_autotune=false
. Consulte o Seção 16.2.1, “Dimensionamento automático do cache” para obter os detalhes.
Se o sistema tiver problemas óbvios, corrija-os antes de iniciar o upgrade. O upgrade nunca corrige problemas existentes do sistema.
Verifique o desempenho do cluster. Você pode usar comandos, como rados bench
, ceph tell osd.* bench
ou iperf3
.
Verifique o acesso aos gateways (como iSCSI Gateway ou Object Gateway) e ao Dispositivo de Blocos RADOS.
Registre partes específicas da configuração do sistema, como configuração de rede, particionamento ou detalhes da instalação.
Use o supportconfig
para coletar informações importantes do sistema e grave-as fora dos nós do cluster. Mais informações podem ser encontradas em https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html.
Verifique se há espaço livre suficiente no disco em cada nó do cluster. Use o comando df -h
para verificar o espaço livre no disco. Quando necessário, libere espaço no disco removendo arquivos/diretórios desnecessários ou removendo instantâneos obsoletos do OS. Se não houver espaço livre suficiente no disco, não continue com o upgrade até liberar espaço suficiente.
Use o comando cluster health
para verificar a saúde do cluster antes de iniciar o procedimento de upgrade. Não inicie o upgrade, exceto quando cada nó do cluster relatar “HEALTH_OK”.
Verifique se todos os serviços estão em execução:
Master Salt e daemons do master Salt.
Daemons do Ceph Monitor e do Ceph Manager.
Daemons do Servidor de Metadados.
Daemons do Ceph OSD.
Daemons do Object Gateway.
Daemons do iSCSI Gateway.
Os seguintes comandos apresentam os detalhes do estado do cluster e a configuração específica:
ceph -s
Imprime um breve resumo da saúde do cluster do Ceph, dos serviços em execução, do uso de dados e das estatísticas de E/S. Verifique se ele relata “HEALTH_OK” antes de iniciar o upgrade.
ceph health detail
Imprime os detalhes se a saúde do cluster do Ceph não estiver OK.
ceph versions
Imprime as versões dos daemons do Ceph em execução.
ceph df
Imprime o espaço total e livre do disco no cluster. Não inicie o upgrade se o espaço livre no disco do cluster for inferior a 25% do espaço total no disco.
salt '*' cephprocesses.check results=true
Imprime os processos em execução do Ceph e os respectivos PIDs classificados por minions Salt.
ceph osd dump | grep ^flags
Verifique se os flags "recovery_deletes" e "purged_snapdirs” estão presentes. Se não estiverem, você poderá forçar uma depuração de todos os grupos de posicionamento executando o comando a seguir. Saiba que essa depuração forçada pode prejudicar o desempenho dos clientes Ceph.
cephadm@adm >
ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub
O CTDB oferece um banco de dados em cluster usado pelos Gateways do Samba. O protocolo CTDB é muito simples e não suporta clusters de nós que se comunicam com diferentes versões de protocolo. Portanto, os nós do CTDB precisam ser colocados offline antes de realizar um upgrade.
Para garantir que os principais serviços do cluster fiquem disponíveis durante o upgrade, você precisa fazer upgrade dos nós do cluster um por um, em sequência. Há duas maneiras de executar o upgrade de um nó: usando o DVD do instalador ou o sistema de migração de distribuição.
Após o upgrade de cada nó, recomendamos executar o rpmconfigcheck
para verificar se há arquivos de configuração atualizados que foram editados localmente. Se o comando retornar uma lista de nomes de arquivo com um sufixo .rpmnew
, .rpmorig
ou .rpmsave
, compare esses arquivos com os arquivos de configuração atuais para garantir que nenhuma mudança local tenha sido perdida. Se necessário, atualize os arquivos afetados. Para obter mais informações sobre como trabalhar com arquivos .rpmnew
, .rpmorig
e .rpmsave
, consulte https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-sw-cl.html#sec-rpm-packages-manage.
Após o upgrade de um nó, vários pacotes terão o estado “órfão” sem um repositório pai. Isso acontece porque os pacotes python3 relacionados não tornam os pacotes python2 obsoletos.
Há mais informações sobre como listar pacotes órfãos disponíveis no site https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_zypper.html#sec_zypper_softup_orphaned.
Reinicialize o nó usando o DVD/imagem do instalador do SUSE Linux Enterprise Server 15 SP1.
Selecione
no menu de inicialização.Na tela
, verifique se “SUSE Linux Enterprise Server 15 SP1” está selecionado e ative a caixa de seleção .Selecione os seguintes módulos para instalação:
SUSE Enterprise Storage 6 x86_64
Módulo Basesystem 15 SP1 x86_64
Módulo Desktop Applications 15 SP1 x86_64
Módulo Legacy 15 SP1 x86_64
Módulo Server Applications 15 SP1 x86_64
Na tela
, verifique se os repositórios corretos estão selecionados. Se o sistema não foi registrado com SCC/SMT, você precisa adicionar os repositórios manualmente.O SUSE Enterprise Storage 6 requer:
SLE-Module-Basesystem15-SP1-Pool
SLE-Module-Basesystem15-SP1-Updates
SLE-Module-Server-Applications15-SP1-Pool
SLE-Module-Server-Applications15-SP1-Updates
SLE-Module-Desktop-Applications15-SP1-Pool
SLE-Module-Desktop-Applications15-SP1-Updates
SLE-Product-SLES15-SP1-Pool
SLE-Product-SLES15-SP1-Updates
SLE15-SP1-Installer-Updates
SUSE-Enterprise-Storage-6-Pool
SUSE-Enterprise-Storage-6-Updates
Se você pretende migrar o ntpd
para o chronyd
após a migração do SES (consulte a Seção 6.3, “Migrando do ntpd
para o chronyd
”), inclua os seguintes repositórios:
SLE-Module-Legacy15-SP1-Pool
SLE-Module-Legacy15-SP1-Updates
O Gateway NFS/SMB no SLE-HA no SUSE Linux Enterprise Server 15 SP1 requer:
SLE-Product-HA15-SP1-Pool
SLE-Product-HA15-SP1-Updates
Revise as
e inicie o procedimento de instalação clicando em .O Distribution Migration System (DMS) inclui um caminho de upgrade para um sistema SUSE Linux Enterprise instalado de uma versão principal para outra. O procedimento a seguir utiliza o DMS para fazer upgrade do SUSE Enterprise Storage 5.5 para a versão 6, incluindo a migração do SUSE Linux Enterprise Server 12 SP3 subjacente para o SUSE Linux Enterprise Server 15 SP1.
Consulte https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/ para encontrar informações gerais e detalhadas sobre o DMS.
Instale os pacotes RPM de migração. Eles ajustam o carregador de boot GRUB para acionar automaticamente o upgrade na próxima reinicialização. Instale os pacotes SLES15-SES-Migration e suse-migration-sle15-activation :
root@minion >
zypper install SLES15-SES-Migration suse-migration-sle15-activation
Se o nó do qual está sendo feito o upgrade foi registrado com um sistema de propagação em fases do repositório, como SCC, SMT, RMT ou SUSE Manager, crie o /etc/sle-migration-service.yml
com o seguinte conteúdo:
use_zypper_migration: true preserve: rules: - /etc/udev/rules.d/70-persistent-net.rules
Se o nó do qual está sendo feito o upgrade não foi registrado com um sistema de propagação em fases do repositório, como SCC, SMT, RMT ou SUSE Manager, faça as seguintes mudanças:
Crie o /etc/sle-migration-service.yml
com o seguinte conteúdo:
use_zypper_migration: false preserve: rules: - /etc/udev/rules.d/70-persistent-net.rules
Desabilite ou remova os repositórios SLE 12 SP3 e SES 5 e adicione os repositórios SLE 15 SP1 e SES 6. Encontre a lista de repositórios relacionados na Seção 6.4.1, “Repositórios de software necessários”.
Reinicialize para iniciar o upgrade. Durante a execução do upgrade, você pode efetuar login no nó do qual foi feito o upgrade com ssh
como usuário da migração utilizando a chave SSH existente do sistema host, conforme descrito em https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/. Para o SUSE Enterprise Storage, se você tiver acesso físico ou acesso direto do console à máquina, poderá efetuar login como root
no console do sistema usando a senha sesupgrade
. O nó será reinicializado automaticamente após o upgrade.
Se houver falha no upgrade, inspecione o /var/log/distro_migration.log
. Corrija o problema, reinstale os pacotes RPM de migração e reinicialize o nó.
Os seguintes comandos ainda funcionarão, embora os minions Salt estejam executando versões antigas do Ceph e do Salt: salt '*' test.ping
e ceph status
Após o upgrade do Nó de Admin, o openATTIC não será mais instalado.
Se o Nó de Admin hospedava o SMT, conclua a migração dele para o RMT (consulte https://www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html).
Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.
Após o upgrade do Nó de Admin, você poderá executar o comando salt-run upgrade.status
para ver informações úteis sobre os nós do cluster. O comando lista as versões do Ceph e do OS de todos os nós e recomenda em que ordem fazer o upgrade de quaisquer nós que ainda executam versões antigas.
root@master #
salt-run upgrade.status
The newest installed software versions are:
ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable)
os: SUSE Linux Enterprise Server 15 SP1
Nodes running these software versions:
admin.ceph (assigned roles: master)
mon2.ceph (assigned roles: admin, mon, mgr)
Nodes running older software versions must be upgraded in the following order:
1: mon1.ceph (assigned roles: admin, mon, mgr)
2: mon3.ceph (assigned roles: admin, mon, mgr)
3: data1.ceph (assigned roles: storage)
[...]
Se o cluster não usa funções MDS, faça upgrade dos nós MON/MGR um por um.
Se o cluster usa funções MDS, e as funções MON/MGR e MDS são colocalizadas, você precisa reduzir o cluster MDS e, em seguida, fazer upgrade dos nós colocalizados. Consulte a Seção 6.11, “Fazendo upgrade dos servidores de metadados” para obter mais detalhes.
Se o cluster usa funções MDS e elas são executadas em servidores dedicados, faça upgrade de todos os nós MON/MGR um por um, depois reduza e faça upgrade do cluster MDS. Consulte a Seção 6.11, “Fazendo upgrade dos servidores de metadados” para obter mais detalhes.
Em virtude de uma limitação no projeto do Ceph Monitor, depois que é feito upgrade de dois MONs para o SUSE Enterprise Storage 6 e um quorum é formado, o terceiro MON (enquanto ainda está no SUSE Enterprise Storage 5.5) não reingressará no cluster MON se ele for reiniciado por qualquer motivo, incluindo uma reinicialização de nó. Portanto, quando é feito upgrade de dois MONs, a melhor opção é fazer upgrade dos demais o quanto antes.
Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.
Você precisa reduzir o cluster do Servidor de Metadados (MDS, Metadata Server). Como há recursos incompatíveis entre as versões 5.5 e 6 do SUSE Enterprise Storage, os daemons MDS mais antigos serão encerrados logo que virem um único MDS no nível do SES 6 ingressar no cluster. Portanto, é necessário reduzir o cluster MDS a um único MDS ativo (sem standbys) durante os upgrades dos nós MDS. Logo após o upgrade do segundo nó, você poderá estender o cluster MDS novamente.
Em um cluster MDS com carga muito pesada, talvez seja necessário reduzir a carga (por exemplo, parando os clientes) para que um único MDS ativo seja capaz de processar a carga de trabalho.
Observe o valor atual da opção max_mds
:
cephadm@adm >
ceph fs get cephfs | grep max_mds
Reduza o cluster MDS se você tiver mais do que 1 daemon MDS ativo. Por exemplo, max_mds
é > 1. Para reduzir o cluster MDS, execute
cephadm@adm >
ceph fs set FS_NAME max_mds 1
em que FS_NAME é o nome da sua instância do CephFS (por padrão, “cephfs”).
Encontre o nó que hospeda um dos daemons MDS de standby. Consulte a saída do comando ceph fs status
e inicie o upgrade do cluster MDS nesse nó.
cephadm@adm >
ceph fs status
cephfs - 2 clients
======
+------+--------+--------+---------------+-------+-------+
| Rank | State | MDS | Activity | dns | inos |
+------+--------+--------+---------------+-------+-------+
| 0 | active | mon1-6 | Reqs: 0 /s | 13 | 16 |
+------+--------+--------+---------------+-------+-------+
+-----------------+----------+-------+-------+
| Pool | type | used | avail |
+-----------------+----------+-------+-------+
| cephfs_metadata | metadata | 2688k | 96.8G |
| cephfs_data | data | 0 | 96.8G |
+-----------------+----------+-------+-------+
+-------------+
| Standby MDS |
+-------------+
| mon3-6 |
| mon2-6 |
+-------------+
Neste exemplo, é necessário iniciar o procedimento de upgrade no nó “mon3-6” ou “mon2-6”.
Faça upgrade do nó com o daemon MDS de standby. Depois que o nó MDS do qual foi feito o upgrade for iniciado, os daemons MDS desatualizados serão encerrados automaticamente. Neste ponto, os clientes podem passar por um breve tempo de espera do serviço CephFS.
Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.
Faça upgrade dos nós MDS restantes.
Redefina max_mds
para a configuração desejada:
cephadm@adm >
ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT
Para cada nó de armazenamento, siga etas etapas:
Identifique quais daemons OSD estão sendo executados em um nó específico:
cephadm@osd >
ceph osd tree
Defina o flag “noout” para cada daemon OSD no nó do qual está sendo feito o upgrade:
cephadm@osd >
ceph osd add-noout osd.OSD_ID
Por exemplo:
cephadm@osd >
for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done
Faça a verificação com:
cephadm@osd >
ceph health detail | grep noout
ou
cephadm@osd >
ceph –s
cluster:
id: 44442296-033b-3275-a803-345337dc53da
health: HEALTH_WARN
6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set
Crie arquivos /etc/ceph/osd/*.json
para todos os OSDs existentes executando o seguinte comando no nó do qual será feito o upgrade:
cephadm@osd >
ceph-volume simple scan --force
Faça upgrade do nó OSD. Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.
Ativar todos os OSDs encontrados no sistema:
cephadm@osd >
;ceph-volume simple activate --all
Para ativar partições de dados individualmente, você precisa encontrar o comando ceph-volume
correto de cada partição para ativá-la. Substitua X1 pela letra/número correto da partição:
cephadm@osd >
ceph-volume simple scan /dev/sdX1
Por exemplo:
cephadm@osd >
ceph-volume simple scan /dev/vdb1
[...]
--> OSD 8 got scanned and metadata persisted to file:
/etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json
--> To take over management of this scanned OSD, and disable ceph-disk
and udev, run:
--> ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290
A última linha da saída contém o comando para ativar a partição:
cephadm@osd >
ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290
[...]
--> All ceph-disk systemd units have been disabled to prevent OSDs
getting triggered by UDEV events
[...]
Running command: /bin/systemctl start ceph-osd@8
--> Successfully activated OSD 8 with FSID
d7bd2685-5b92-4074-8161-30d146cd0290
Verifique se o nó OSD será iniciado apropriadamente após a reinicialização.
Resolva a mensagem “Legacy BlueStore stats reporting detected on XX OSD(s)” (Relatório de estatísticas do BlueStore legado detectado em XX OSD(s)):
cephadm@osd >
ceph –s
cluster:
id: 44442296-033b-3275-a803-345337dc53da
health: HEALTH_WARN
Legacy BlueStore stats reporting detected on 6 OSD(s)
O aviso é normal ao fazer upgrade do Ceph para 14.2.2. Para desabilitá-lo, defina:
bluestore_warn_on_legacy_statfs = false
A correção apopriada é executar o seguinte comando em todos os OSDs enquanto estão sendo interrompidos:
cephadm@osd >
ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX
Veja a seguir um script ajudante que executa o comando ceph-bluestore-tool repair
para todos os OSDs no nó NODE_NAME:
OSDNODE=OSD_NODE_NAME;\ for OSD in $(ceph osd ls-tree $OSDNODE);\ do echo "osd=" $OSD;\ salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\ salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\ salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\ done
Cancele a definição do flag “noout” para cada daemon OSD no nó do qual foi feito o upgrade:
cephadm@osd >
ceph osd rm-noout osd.OSD_ID
Por exemplo:
cephadm@osd >
for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done
Faça a verificação com:
cephadm@osd >
ceph health detail | grep noout
Nota:
cephadm@osd >
ceph –s
cluster:
id: 44442296-033b-3275-a803-345337dc53da
health: HEALTH_WARN
Legacy BlueStore stats reporting detected on 6 OSD(s)
Verifique o status do cluster. Ele será semelhante à seguinte saída:
cephadm@osd >
ceph status
cluster:
id: e0d53d64-6812-3dfe-8b72-fd454a6dcf12
health: HEALTH_WARN
3 monitors have not enabled msgr2
services:
mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
mgr: mon2(active, since 22m), standbys: mon1, mon3
osd: 30 osds: 30 up, 30 in
data:
pools: 1 pools, 1024 pgs
objects: 0 objects, 0 B
usage: 31 GiB used, 566 GiB / 597 GiB avail
pgs: 1024 active+clean
Verifique se todos os nós OSD foram reinicializados e se os OSDs foram iniciados automaticamente após a reinicialização.
O OSD do BlueStore é um novo back end para os daemons OSD. Ele é a opção padrão desde o SUSE Enterprise Storage 5. Comparado com o FileStore, que armazena objetos como arquivos em um sistema de arquivos XFS, o BlueStore pode proporcionar melhor desempenho, porque armazena os objetos diretamente no dispositivo de blocos subjacente. O BlueStore também disponibiliza outros recursos, como compactação incorporada e sobregravações EC, que não estão disponíveis no FileStore.
Especificamente no BlueStore, um OSD tem um dispositivo “wal” (Registro Write-Ahead) e um dispositivo “db” (banco de dados RocksDB). O banco de dados RocksDB armazena os metadados para um OSD do BlueStore. Por padrão, esses dois dispositivos residirão no mesmo dispositivo como um OSD, mas qualquer um deles pode ser inserido em uma mídia diferente, por exemplo, mais rápida.
No SUSE Enterprise Storage 5, tanto o FileStore quanto o BlueStore são suportados, e os OSDs do FileStore e do BlueStore podem coexistir em um único cluster. Durante o procedimento de upgrade do SUSE Enterprise Storage, os OSDs do FileStore não são convertidos automaticamente em BlueStore. Os recursos específicos do BlueStore não estarão disponíveis nos OSDs que não foram migrados para o BlueStore.
Antes da conversão em BlueStore, os OSDs precisam executar o SUSE Enterprise Storage 5. A conversão é um processo lento, pois todos os dados são regravados duas vezes. O processo de migração pode levar muito tempo para ser concluído, mas não há nenhuma interrupção do cluster, e todos os clientes podem continuar acessando o cluster durante esse período. No entanto, é comum uma redução no desempenho durante a migração. Isso é causado pela redistribuição e preenchimento de dados dos cluster.
Siga o procedimento abaixo para migrar os OSDs do FileStore para o BlueStore:
Os comandos do Salt necessários para executar a migração são bloqueados por medidas de segurança. Para desativar essa medida preventiva, execute o seguinte comando:
root@master #
salt-run disengage.safety
Reconstrua os nós antes de continuar:
root@master #
salt-run rebuild.node TARGET
Você também pode reconstruir cada nó individualmente. Por exemplo:
root@master #
salt-run rebuild.node data1.ceph
O rebuild.node
sempre remove e recria todos os OSDs no nó.
Se um OSD não puder ser convertido, uma nova reconstrução destruirá os OSDs do BlueStore já convertidos. Em vez de uma nova reconstrução, você poderá executar:
root@master #
salt-run disks.deploy TARGET
Após a migração para o BlueStore, o total de objetos permanecerá o mesmo, e a utilização do disco será quase igual.
Faça upgrade dos nós do aplicativo na seguinte ordem:
Object Gateways
Se o front end dos Object Gateways for um balanceador de carga, um upgrade sequencial dos Object Gateways deverá ser possível sem interrupção.
Confirme se os daemons do Object Gateway estão em execução após cada upgrade e faça o teste com o cliente S3/Swift.
Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.
iSCSI Gateways
Se os iniciadores iSCSI estiverem configurados com múltiplos caminhos, um upgrade sequencial dos iSCSI Gateways deverá ser possível sem interrupção.
Confirme se o daemon lrbd
está em execução após cada upgrade e faça o teste com o iniciador.
Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.
NFS Ganesha. Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.
Gateways do Samba. Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.
policy.cfg
e implantando o Ceph Dashboard por meio do DeepSea #
No Nó de Admin, edite o /srv/pillar/ceph/proposals/policy.cfg
e aplique as seguintes mudanças:
Durante o upgrade do cluster, não adicione novos serviços ao arquivo policy.cfg
. Apenas mude a arquitetura do cluster após a conclusão do upgrade.
Remova role-openattic
.
Adicione role-prometheus
e role-grafana
ao nó com o Prometheus e o Grafana instalados (normalmente, o Nó de Admin).
Agora, a função profile-NOME_PERFIL
será ignorada. Adicione a nova função correspondente: linha role-storage
. Por exemplo, para o comando existente
profile-default/cluster/*.sls
adicione
role-storage/cluster/*.sls
Sincronize todos os módulos do Salt:
root@master #
salt '*' saltutil.sync_all
Execute as fases 1 e 2 do DeepSea para atualizar o pillar Salt:
root@master #
salt-run state.orch ceph.stage.1root@master #
salt-run state.orch ceph.stage.2
Limpe o openATTIC:
root@master #
salt OA_MINION state.apply ceph.rescind.openatticroot@master #
salt OA_MINION state.apply ceph.remove.openattic
Cancele a definição do grain “restart_igw” para impedir que a fase 0 reinicie o iSCSI Gateway, que ainda não está instalado:
Salt mastersalt '*' grains.delkey restart_igw
Por fim, execute as fases de 0 a 4 do DeepSea:
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.3root@master #
salt-run state.orch ceph.stage.4
A fase 3 do DeepSea pode falhar com um erro semelhante ao exibido a seguir:
subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \ '/var/lib/ceph subvolume missing on 4510-1', \ [...] 'See /srv/salt/ceph/subvolume/README.md']
Neste caso, você precisa editar o /srv/pillar/ceph/stack/global.yml
e adicionar a seguinte linha:
subvolume_init: disabled
Em seguida, atualize o pillar Salt e execute a fase 3 do DeepSea novamente:
root@master #
salt '*' saltutil.refresh_pillarroot@master #
salt-run state.orch ceph.stage.3
Após a conclusão bem-sucedida da fase 3 do DeepSea, o Ceph Dashboard será executado. Consulte o Capítulo 22, Ceph Dashboard para obter uma visão geral detalhada dos recursos do Ceph Dashboard.
Para listar os nós que executam o painel de controle, aplique o comando:
cephadm@adm >
ceph mgr services | grep dashboard
Para listar as credenciais de admin, execute:
root@master #
salt-call grains.get dashboard_creds
Reinicie sequencialmente os serviços do Object Gateway para usar o servidor Web “beast” em vez do “civetweb” desatualizado:
root@master #
salt-run state.orch ceph.restart.rgw.force
Antes de continuar, recomendamos enfaticamente habilitar o módulo de telemetria do Ceph. Para obter mais informações e instruções, consulte o Seção 10.2, “Módulo de telemetria”.
No SUSE Enterprise Storage 5.5, o DeepSea ofereceu os chamados “perfis” para descrever o layout dos OSDs. A partir do SUSE Enterprise Storage 6, adotamos uma abordagem diferente denominada DriveGroups (encontre mais detalhes na Seção 5.5.2, “DriveGroups”).
A migração para a nova abordagem não é obrigatória de imediato. Operações destrutivas, como salt-run osd.remove
, salt-run osd.replace
ou salt-run osd.purge
, ainda estão disponíveis. No entanto, a adição de novos OSDs exigirá que você execute uma ação.
Devido à abordagem diferente dessas implementações, não oferecemos um caminho de migração automatizado. No entanto, oferecemos uma variedade de ferramentas, executores Salt, para tornar a migração o mais simples possível.
Para ver informações sobre os OSDs implantados atualmente, use o seguinte comando:
root@master #
salt-run disks.discover
Se preferir, você poderá inspecionar o conteúdo dos arquivos nos diretórios /srv/pillar/ceph/proposals/profile-*/
. Eles têm uma estrutura semelhante à seguinte:
ceph: storage: osds: /dev/disk/by-id/scsi-drive_name: format: bluestore /dev/disk/by-id/scsi-drive_name2: format: bluestore
Consulte a Seção 5.5.2.1, “Especificação” para obter mais detalhes sobre a especificação de DriveGroups.
A diferença entre uma implantação nova e um cenário de upgrade é que as unidades que serão migradas já são “usadas”. Como
root@master #
salt-run disks.list
procura apenas discos não usados, aplique o comando
root@master #
salt-run disks.list include_unavailable=True
Ajuste os DriveGroups até corresponder à sua configuração atual. Para uma representação mais visual do que acontecerá, execute o comando a seguir. Observe que ele não terá saída se não houver discos livres:
root@master #
salt-run disks.report bypass_pillar=True
Se você verificou que os DriveGroups estão configurados apropriadamente e deseja aplicar a nova abordagem, remova os arquivos do diretório /srv/pillar/ceph/proposals/profile-NOME_PERFIL/
, remova as linhas profile-NOME_PERFIL/cluster/*.sls
correspondentes do arquivo /srv/pillar/ceph/proposals/policy.cfg
e execute a fase 2 do DeepSea para atualizar o pillar Salt.
root@master #
salt-run state.orch ceph.stage.2
Execute os seguintes comandos para verificar o resultado:
root@master #
salt target_node pillar.get ceph:storageroot@master #
salt-run disks.report
Se os DriveGroups não estiverem configurados apropriadamente e houver discos sobressalentes na configuração, eles serão implantados da maneira que você os especificou. Recomendamos executar o comando:
root@master #
salt-run disks.report
Para casos simples, como OSDs independentes, a migração acontecerá com o tempo. Sempre que você remover ou substituir um OSD do cluster, ele será substituído por um novo OSD baseado em LVM.
Sempre que um único OSD "legado" precisar ser substituído em um nó, todos os OSDs que compartilham dispositivos com ele deverão ser migrados para o formato baseado em LVM.
Para totalidade, considere a migração dos OSDs em todo o nó.
Se você tem uma configuração mais sofisticada do que apenas OSDs independentes (por exemplo, WAL/BDs dedicados ou OSDs criptografados), a migração apenas pode acontecer quando todos os OSDs atribuídos a esse dispositivo WAL/BD são removidos. Isso ocorre porque o comando ceph-volume
cria os Volumes Lógicos nos discos antes da implantação. Esse comportamento impede que o usuário misture implantações baseadas na partição com implantações baseadas em LV. Nesses casos, o melhor é remover manualmente todos os OSDs atribuídos a um dispositivo WAL/BD e reimplantá-los adotando a abordagem DriveGroups.