cephx
ceph.conf
com configurações personalizadasApós implantar um cluster do Ceph, provavelmente você precisará fazer várias modificações nele de vez em quando. Dentre elas, adicionar ou remover novos nós, discos ou serviços. Este capítulo descreve como você pode realizar essas tarefas de administração.
O procedimento de adição de novos nós ao cluster é quase idêntico à implantação de nó do cluster inicial descrita no Capítulo 5, Implantando com o DeepSea/Salt:
Ao adicionar um OSD ao cluster existente, lembre-se de que o cluster será redistribuído após algum tempo. Para minimizar os períodos de redistribuição, adicione ao mesmo tempo todos os OSDs desejados.
A outra maneira é definir a opção osd crush initial weight = 0
no arquivo ceph.conf
antes de adicionar os OSDs:
Adicione osd crush initial weight = 0
a /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf
.
Crie a nova configuração no nó master Salt:
root@master #
salt 'SALT_MASTER_NODE' state.apply ceph.configuration.create
Aplique a nova configuração aos minions OSD de destino:
root@master #
salt 'OSD_MINIONS' state.apply ceph.configuration
Após a adição dos novos OSDs, ajuste os pesos deles conforme necessário com o comando ceph osd crush reweight
.
Instale o SUSE Linux Enterprise Server 15 SP1 no novo nó e defina a configuração de rede para que ela resolva o nome de host do master Salt corretamente. Verifique se ele tem uma conexão apropriada com redes públicas e de cluster e se a sincronização de horário está configurada corretamente. Em seguida, instale o pacote salt-minion
:
root@minion >
zypper in salt-minion
Se o nome de host do master Salt não for salt
, edite /etc/salt/minion
e adicione o seguinte:
master: DNS_name_of_your_salt_master
Se você efetuou quaisquer mudanças nos arquivos de configuração mencionados acima, reinicie o serviço salt.minion
:
root@minion >
systemctl restart salt-minion.service
No master Salt, aceite a chave salt do novo nó:
root@master #
salt-key --accept NEW_NODE_KEY
Verifique se o /srv/pillar/ceph/deepsea_minions.sls
está direcionado para o novo minion Salt e/ou defina o grain do DeepSea apropriado. Consulte o Seção 5.2.2.1, “Correspondendo o nome do minion” ou o Procedimento 5.1, “Executando as fases de implantação” para obter mais detalhes.
Execute a fase de preparação. Ela sincroniza os módulos e grains para que o novo minion possa fornecer todas as informações esperadas pelo DeepSea.
root@master #
salt-run state.orch ceph.stage.0
Se o master Salt for reiniciado após a atualização do kernel, você precisará reiniciar a fase 0 do DeepSea.
Execute a fase de descoberta. Ela gravará novas entradas de arquivo no diretório /srv/pillar/ceph/proposals
, em que você pode editar os arquivos .yml relevantes:
root@master #
salt-run state.orch ceph.stage.1
Se preferir, mude o /srv/pillar/ceph/proposals/policy.cfg
se o host recém-adicionado não corresponder ao esquema de nomeação existente. Para obter informações detalhadas, consulte o Seção 5.5.1, “Arquivo policy.cfg
”.
Execute a fase de configuração. Ela lê tudo o que está em /srv/pillar/ceph
e atualiza o pillar de acordo:
root@master #
salt-run state.orch ceph.stage.2
O pillar armazena dados que você pode acessar com o seguinte comando:
root@master #
salt target pillar.items
Para modificar o layout do OSD padrão e mudar a configuração dos grupos de unidades, siga o procedimento descrito no Seção 5.5.2, “DriveGroups”.
As fases de configuração e implantação incluem os nós recém-adicionados:
root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4
Você pode implantar com o DeepSea todos os tipos de funções suportadas. Consulte o Seção 5.5.1.2, “Atribuição de função” para obter mais informações sobre os tipos de função suportados e ver exemplos de como correspondê-los.
Para adicionar um novo serviço a um nó existente, siga estas etapas:
Adapte o /srv/pillar/ceph/proposals/policy.cfg
para corresponder o host existente a uma nova função. Para obter mais detalhes, consulte o Seção 5.5.1, “Arquivo policy.cfg
”. Por exemplo, se você precisa executar um Object Gateway em um nó MON, a linha é semelhante a:
role-rgw/xx/x/example.mon-1.sls
Execute a fase 2 para atualizar o pillar:
root@master #
salt-run state.orch ceph.stage.2
Execute a fase 3 para implantar os serviços básicos, ou a fase 4 para implantar os serviços opcionais. Não há nenhum problema em executar as duas fases.
O master Salt espera que todos os minions estejam presentes e responsivos no cluster. Se houver falha em um minion e ele parar de responder, isso causará problemas na infraestrutura do Salt, principalmente no DeepSea e no Ceph Dashboard.
Antes de corrigir o minion, apague a chave dele do master Salt temporariamente:
root@master #
salt-key -d MINION_HOST_NAME
Após a correção do minion, adicione a chave dele ao master Salt novamente:
root@master #
salt-key -a MINION_HOST_NAME
Para remover uma função de um cluster, edite o /srv/pillar/ceph/proposals/policy.cfg
e remova a(s) linha(s) correspondente(s). Em seguida, execute as fases 2 e 5, conforme descrito no Seção 5.3, “Implantação do cluster”.
Se for necessário remover determinado nó OSD do cluster, verifique se o cluster tem mais espaço livre em disco do que o disco que você pretende remover. A remoção de um OSD provoca a redistribuição do cluster inteiro.
Antes de executar a fase 5 para fazer a remoção real, sempre verifique quais OSDs serão removidos pelo DeepSea:
root@master #
salt-run rescinded.ids
Quando uma função é removida de um minion, o objetivo é desfazer todas as modificações relacionadas a essa função. Para a maioria das funções, a tarefa é simples, mas pode haver problemas com as dependências de pacotes. Se um pacote for desinstalado, suas dependências não serão.
Os OSDs removidos aparecem como unidades em branco. As tarefas relacionadas sobregravam o início dos sistemas de arquivos, removem as partições de backup e limpam as tabelas de partição.
As unidades de disco já configuradas por outros métodos, como ceph-deploy
, ainda podem conter partições. O DeepSea não as eliminará automaticamente. O administrador deve reaproveitar essas unidades manualmente.
Se os nomes dos minions de armazenamento forem, por exemplo, “data1.ceph”, “data2.ceph”, etc., o “data6.ceph” e as linhas relacionadas no policy.cfg
serão semelhantes ao seguinte:
[...] # Hardware Profile role-storage/cluster/data*.sls [...]
Portanto, para remover o minion Salt “data2.ceph”, mude as linhas para o seguinte:
[...] # Hardware Profile role-storage/cluster/data[1,3-6]*.sls [...]
Lembre-se também de adpatar seu arquivo drive_groups.yml para corresponder aos novos destinos.
[...] drive_group_name: target: 'data[1,3-6]*' [...]
Em seguida, execute a fase 2, verifique quais OSDs serão removidos e conclua a execução da fase 5:
root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run rescinded.idsroot@master #
salt-run state.orch ceph.stage.5
Considere a seguinte situação: durante a nova instalação do cluster, você (o administrador) alocou um dos nós de armazenamento como Object Gateway independente enquanto aguardava a chegada do hardware do gateway. Agora, o hardware permanente do gateway chegou e você pode finalmente atribuir a função desejada ao nó de armazenamento de backup e remover a função do gateway.
Depois de executar as fases 0 e 1 (consulte o Procedimento 5.1, “Executando as fases de implantação”) para o novo hardware, você denominou o novo gateway como rgw1
. Se o nó data8
precisar que a função Object Gateway seja removida e que a função de armazenamento seja adicionada, o policy.cfg
atual terá esta aparência:
# Hardware Profile role-storage/cluster/data[1-7]*.sls # Roles role-rgw/cluster/data8*.sls
Portanto, faça uma mudança para:
# Hardware Profile role-storage/cluster/data[1-8]*.sls # Roles role-rgw/cluster/rgw1*.sls
Execute as fases de 2 a 4, verifique quais OSDs talvez sejam removidos e conclua a execução da fase 5. A Fase 3 adicionará o data8
como nó de armazenamento. Por algum tempo, o data8
terá as duas funções. A fase 4 adicionará a função Object Gateway ao rgw1
, e a fase 5 removerá a função Object Gateway do data8
:
root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4root@master #
salt-run rescinded.idsroot@master #
salt-run state.orch ceph.stage.5
Quando há falha em um ou mais nós do monitor e eles não respondem, você precisa remover os monitores com falha do cluster e, possivelmente, readicioná-los ao cluster.
O número de nós do monitor não deve ser menor do que três. Se houver falha em um nó do monitor e, por esse motivo, o cluster ficar apenas com dois nós, você precisará atribuir temporariamente a função do monitor a outros nós do cluster antes de reimplantar os nós com falha do monitor. Após reimplantar os nós com falha do monitor, você poderá desinstalar as funções temporárias do monitor.
Para obter mais informações sobre como adicionar novos nós/funções ao cluster do Ceph, consulte a Seção 2.1, “Adicionando novos nós do cluster” e a Seção 2.2, “Adicionando novas funções aos nós”.
Para obter mais informações sobre como remover nós do cluster, consulte a Seção 2.3, “Removendo e reinstalando nós do cluster”.
Há dois graus básicos de falha no nó do Ceph:
O host do minion Salt está danificado fisicamente ou no nível do OS e não responde à chamada salt “nome_do_minion” test.ping
. Nesse caso, você precisa reimplantar o servidor por completo seguindo as instruções relevantes no Seção 5.3, “Implantação do cluster”.
Houve falha nos serviços relacionados ao monitor e eles se recusam a se recuperar, mas o host responde à chamada salt “nome_do_minion” test.ping
. Nesse caso, siga estas etapas:
Edite o /srv/pillar/ceph/proposals/policy.cfg
no master Salt e remova ou atualize as linhas correspondentes aos nós com falha do monitor para que agora eles apontem para os nós ativos do monitor. Por exemplo:
[...] # MON #role-mon/cluster/ses-example-failed1.sls #role-mon/cluster/ses-example-failed2.sls role-mon/cluster/ses-example-new1.sls role-mon/cluster/ses-example-new2.sls [...]
Execute as fases de 2 a 5 do DeepSea para aplicar as mudanças:
root@master #
deepsea
stage run ceph.stage.2root@master #
deepsea
stage run ceph.stage.3root@master #
deepsea
stage run ceph.stage.4root@master #
deepsea
stage run ceph.stage.5
Para adicionar um disco a um nó OSD existente, verifique se qualquer partição no disco foi removida e limpa. Consulte a Etapa 12 no Seção 5.3, “Implantação do cluster” para obter mais detalhes. Adapte o /srv/salt/ceph/configuration/files/drive_groups.yml
de acordo (consulte o Seção 5.5.2, “DriveGroups” para obter detalhes). Após gravar o arquivo, execute a fase 3 do DeepSea:
root@master #
deepsea
stage run ceph.stage.3
Você pode remover um Ceph OSD do cluster executando o seguinte comando:
root@master #
salt-run osd.remove OSD_ID
OSD_ID precisa ser um número do OSD sem o prefixo osd.
. Por exemplo, use apenas o dígito 3
de osd.3
.
Siga o mesmo procedimento conforme mencionado na Seção 2.6, “Removendo um OSD”, mas simplesmente insira vários IDs de OSD:
root@master #
salt-run osd.remove 2 6 11 15
Removing osd 2 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.2 is safe to destroy
Purging from the crushmap
Zapping the device
Removing osd 6 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.6 is safe to destroy
Purging from the crushmap
Zapping the device
Removing osd 11 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.11 is safe to destroy
Purging from the crushmap
Zapping the device
Removing osd 15 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.15 is safe to destroy
Purging from the crushmap
Zapping the device
2:
True
6:
True
11:
True
15:
True
Para remover todos os OSDs de um host específico, execute o seguinte comando:
root@master #
salt-run osd.remove OSD_HOST_NAME
Há casos em que há falha na remoção normal de um OSD (consulte a Seção 2.6, “Removendo um OSD”). Por exemplo, isso poderá acontecer se o OSD ou o diário, WAL ou BD dele estiver danificado, quando ele é afetado por operações de E/S travadas ou quando há falha na desmontagem do disco OSD.
root@master #
salt-run osd.remove OSD_ID force=True
Se uma partição ainda estiver montada no disco que está sendo removido, o comando será encerrado com a mensagem: “Unmount failed - check for processes on DEVICE” (Falha na desmontagem. Consulte os processos no DISPOSITIVO). Em seguida, é possível listar todos os processos que acessam o sistema de arquivos com o comando fuser -m DISPOSITIVO
. Se fuser
não retornar nada, tente unmount DISPOSITIVO
manual e confira a saída dos comandos dmesg
ou journalctl
.
Após remover um OSD usando o comando salt-run osd.remove ID
ou outros comandos ceph, os metadados da LVM talvez não sejam completamente removidos. Isso significa que, para reimplantar um novo OSD, serão usados os metadados antigos da LVM.
Primeiramente, verifique se o OSD foi removido:
cephadm@osd >
ceph-volume lvm list
Mesmo que um dos OSDs tenha sido removido com êxito, ele ainda poderá ser listado. Por exemplo, se você removeu o osd.2
, a saída é a seguinte:
====== osd.2 ======= [block] /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380 block device /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380 block uuid kH9aNy-vnCT-ExmQ-cAsI-H7Gw-LupE-cvSJO9 cephx lockbox secret cluster fsid 6b6bbac4-eb11-45cc-b325-637e3ff9fa0c cluster name ceph crush device class None encrypted 0 osd fsid aac51485-131c-442b-a243-47c9186067db osd id 2 type block vdo 0 devices /dev/sda
Neste exemplo, você pode ver que o osd.2
ainda está localizado em /dev/sda
.
Valide os metadados da LVM no nó OSD:
cephadm@osd >
ceph-volume inventory
A saída da execução de ceph-volume inventory
marca a disponibilidade de /dev/sda
como False
(Falso). Por exemplo:
Device Path Size rotates available Model name /dev/sda 40.00 GB True False QEMU HARDDISK /dev/sdb 40.00 GB True False QEMU HARDDISK /dev/sdc 40.00 GB True False QEMU HARDDISK /dev/sdd 40.00 GB True False QEMU HARDDISK /dev/sde 40.00 GB True False QEMU HARDDISK /dev/sdf 40.00 GB True False QEMU HARDDISK /dev/vda 25.00 GB True False
Execute o seguinte comando no nó OSD para remover completamente os metadados da LVM:
cephadm@osd >
ceph-volume lvm zap --osd-id ID --destroy
Execute o comando inventory
novamente para verificar se a disponibilidade de /dev/sda
é retornada como True
(Verdadeiro). Por exemplo:
cephadm@osd >
ceph-volume inventory
Device Path Size rotates available Model name
/dev/sda 40.00 GB True True QEMU HARDDISK
/dev/sdb 40.00 GB True False QEMU HARDDISK
/dev/sdc 40.00 GB True False QEMU HARDDISK
/dev/sdd 40.00 GB True False QEMU HARDDISK
/dev/sde 40.00 GB True False QEMU HARDDISK
/dev/sdf 40.00 GB True False QEMU HARDDISK
/dev/vda 25.00 GB True False
Os metadados da LVM foram removidos. Agora é seguro executar o comando dd
no dispositivo.
O OSD pode ser reimplantado sem que seja necessário reinicializar o nó OSD:
root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3
Há várias razões pelas quais você pode precisar substituir um disco OSD. Por exemplo:
Houve falha no disco OSD ou ele está prestes a falhar com base nas informações do SMART e não poderá mais ser usado para armazenar dados com segurança.
Por exemplo, você precisa fazer upgrade do disco OSD para aumentar o tamanho dele.
O procedimento de substituição é o mesmo para os dois casos. Isso também vale para os Mapas CRUSH padrão e personalizados.
Por exemplo, suponha que “5” é o ID do OSD cujo disco precisa ser substituído. O comando a seguir o marca como eliminado no Mapa CRUSH, mas mantém seu ID original:
root@master #
salt-run osd.replace 5
osd.replace
e osd.remove
Os comandos osd.replace
e osd.remove
do Salt (consulte a Seção 2.6, “Removendo um OSD”) são idênticos, com exceção de que osd.replace
mantém o OSD como “eliminado” no Mapa CRUSH, enquanto osd.remove
remove todos os rastreamentos do Mapa CRUSH.
Substitua manualmente a unidade OSD com falha/upgrade.
Para modificar o layout do OSD padrão e mudar a configuração dos DriveGroups, siga o procedimento descrito no Seção 5.5.2, “DriveGroups”.
Execute a fase 3 da implantação para implantar o disco OSD substituído:
root@master #
salt-run state.orch ceph.stage.3
Se houver falha no sistema operacional que não puder ser recuperada em um dos nós OSD, siga estas etapas para recuperá-lo e reimplantar a função OSD com os dados do cluster inalterados:
Reinstale o sistema operacional SUSE Linux Enterprise de base no nó em que o OS falhou. Instale os pacotes salt-minion no nó OSD, apague a chave antiga do minion Salt do master Salt e registre a nova chave do minion Salt no master Salt. Para obter mais informações sobre a implantação inicial, consulte o Seção 5.3, “Implantação do cluster”.
Em vez de executar toda a fase 0, execute as seguintes partes:
root@master #
salt 'osd_node' state.apply ceph.syncroot@master #
salt 'osd_node' state.apply ceph.packages.commonroot@master #
salt 'osd_node' state.apply ceph.minesroot@master #
salt 'osd_node' state.apply ceph.updates
Execute as fases de 1 a 5 do DeepSea:
root@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.4root@master #
salt-run state.orch ceph.stage.5
Execute a fase 0 do DeepSea:
root@master #
salt-run state.orch ceph.stage.0
Reinicialize o nó OSD relevante. Todos os discos OSD serão redescobertos e reutilizados.
Instale e execute o exportador de nó do Prometheus:
root@master #
salt 'RECOVERED_MINION' \
state.apply ceph.monitoring.prometheus.exporters.node_exporter
Atualize os grains do Salt:
root@master #
salt 'RECOVERED_MINION' osd.retain
Se você precisa substituir o host do Nó de Admin por um novo, é necessário mover os arquivos do master Salt e do DeepSea. Use sua ferramenta de sincronização favorita para transferir os arquivos. Neste procedimento, usamos o rsync
porque é uma ferramenta padrão disponível nos repositórios do software SUSE Linux Enterprise Server 15 SP1.
Pare os serviços salt-master
e salt-minion
no Nó de Admin antigo:
root@master #
systemctl stop salt-master.serviceroot@master #
systemctl stop salt-minion.service
Configure o Salt no novo Nó de Admin para que o master Salt e os minions Salt se comuniquem. Encontre mais detalhes no Seção 5.3, “Implantação do cluster”.
Para facilitar a transição dos minions Salt para o novo Nó de Admin, remova a chave pública do master Salt original de cada um deles:
root@minion >
rm /etc/salt/pki/minion/minion_master.pubroot@minion >
systemctl restart salt-minion.service
Verifique se o pacote deepsea está instalado e instale-o, se necessário.
root@master #
zypper install deepsea
Personalize o arquivo policy.cfg
mudando a linha role-master
. Encontre mais detalhes no Seção 5.5.1, “Arquivo policy.cfg
”.
Sincronize os diretórios /srv/pillar
e /srv/salt
do Nó de Admin antigo com o novo.
rsync
e Links Simbólicos
Se possível, tente sincronizar os arquivos em um dry run primeiro para ver quais serão transferidos (opção -n
do rsync
). Inclua também os links simbólicos (opção -a
do rsync
). Para o rsync
, o comando de sincronização terá a seguinte aparência:
root@master #
rsync -avn /srv/pillar/ NEW-ADMIN-HOSTNAME:/srv/pillar
Se você fez mudanças personalizadas nos arquivos fora de /srv/pillar
e /srv/salt
, por exemplo, no /etc/salt/master
ou no /etc/salt/master.d
, sincronize-as também.
Agora você pode executar as fases do DeepSea do novo Nó de Admin. Consulte o Seção 5.2, “Introdução ao DeepSea” para obter a descrição detalhada.
É possível automatizar a instalação por meio do reator Salt. Para ambientes virtuais ou de hardware consistentes, esta configuração permitirá a criação de um cluster do Ceph com o comportamento especificado.
O Salt não pode executar verificações de dependência com base nos eventos do reator. Existe um risco real de tornar seu master Salt sobrecarregado e sem resposta.
A instalação automatizada requer o seguinte:
Um /srv/pillar/ceph/proposals/policy.cfg
criado apropriadamente.
Configuração personalizada preparada incluída no diretório /srv/pillar/ceph/stack
.
A configuração do reator padrão executará apenas as fases 0 e 1. Isso permite testar o reator sem esperar a conclusão das fases seguintes.
Quando o primeiro comando salt-minion for iniciado, a fase 0 começará. Um bloqueio impede várias instâncias. Quando todos os minions concluírem a fase 0, a fase 1 começará.
Se a operação for executada apropriadamente, edite o arquivo
/etc/salt/master.d/reactor.conf
e substitua a linha a seguir
- /srv/salt/ceph/reactor/discovery.sls
por
- /srv/salt/ceph/reactor/all_stages.sls
Verifique se a linha não está comentada.
Mantenha os nós do cluster do Ceph atualizados aplicando as atualizações sequenciais regularmente.
Antes de corrigir o cluster com os pacotes de software mais recentes, verifique se todos os nós do cluster têm acesso aos repositórios relevantes. Consulte o Seção 6.8.1, “Fazendo upgrade manual do nó por meio do DVD do instalador” para obter uma lista completa dos repositórios necessários.
Se você usa uma ferramenta de propagação em fases, por exemplo, SUSE Manager, SMT (Subscription Management Tool) ou Repository Mirroring Tool, que processa os repositórios do software nos nós do cluster, verifique se as fases dos dois repositórios “Updates” para o SUSE Linux Enterprise Server e o SUSE Enterprise Storage foram criadas no mesmo momento.
É altamente recomendável usar uma ferramenta de propagação em fases para patches com níveis de patch congelados/em fases. Isso garante que os novos nós que ingressarem no cluster tenham o mesmo nível de patch que os nós que já estão em execução no cluster. Dessa forma, você não precisa aplicar os patches mais recentes a todos os nós do cluster antes que os novos nós possam ingressar no cluster.
zypper patch
ou zypper dup
#
Por padrão, o upgrade dos nós do cluster é feito por meio do comando zypper dup
. Se, em vez disso, você preferir atualizar o sistema usando o zypper patch
, edite o /srv/pillar/ceph/stack/global.yml
e adicione a seguinte linha:
update_method_init: zypper-patch
Durante a atualização, os nós do cluster podem ser reinicializados se a atualização fez upgrade do kernel deles. Para eliminar a possibilidade de uma reinicialização forçada de todos os nós, verifique se o kernel mais recente está instalado e em execução nos nós do Ceph ou desabilite as renicializações de nó automáticas, conforme descrito no Seção 7.1.5, “Atualizações e reinicializações durante a fase 0”.
Dependendo da configuração, os nós do cluster podem ser reinicializados durante a atualização, conforme descrito na Seção 2.11.4, “Reinicializações de nó do cluster”. Se houver um ponto único de falha para os serviços, como Object Gateway, Samba Gateway, NFS Ganesha ou iSCSI, as máquinas cliente poderão ser temporariamente desconectadas dos serviços cujos nós estão sendo reinicializados.
Para atualizar os pacotes de software em todos os nós do cluster para a versão mais recente, siga estas etapas:
Atualize os pacotes deepsea, salt-master e salt-minion e reinicie os serviços relevantes no master Salt:
root@master #
salt -I 'roles:master' state.apply ceph.updates.master
Atualize e reinicie o pacote salt-minion em todos os nós do cluster:
root@master #
salt -I 'cluster:ceph' state.apply ceph.updates.salt
Atualize todos os outros pacotes de software no cluster:
root@master #
salt-run state.orch ceph.maintenance.upgrade
Em alguns casos, talvez seja necessário parar ou reinicializar o cluster inteiro. Recomendamos verificar com cuidado as dependências dos serviços em execução. As seguintes etapas apresentam uma descrição de como parar e iniciar o cluster:
Especifique para o cluster do Ceph não marcar os OSDs com o flag “out”:
cephadm@adm >
ceph
osd set noout
Pare os daemons e os nós na seguinte ordem:
Clientes de armazenamento
Gateways. Por exemplo, NFS Ganesha ou Object Gateway
Servidor de Metadados
Ceph OSD
Ceph Manager
Ceph Monitor
Se necessário, execute as tarefas de manutenção.
Inicie os nós e os servidores na ordem inversa do processo de encerramento:
Ceph Monitor
Ceph Manager
Ceph OSD
Servidor de Metadados
Gateways. Por exemplo, NFS Ganesha ou Object Gateway
Clientes de armazenamento
Remova o flag “noout”:
cephadm@adm >
ceph
osd unset noout
ceph.conf
com configurações personalizadas #
Se você precisar inserir configurações personalizadas no arquivo ceph.conf
, poderá modificar os arquivos de configuração no diretório /srv/salt/ceph/configuration/files/ceph.conf.d
:
global.conf
mon.conf
mgr.conf
mds.conf
osd.conf
client.conf
rgw.conf
Rgw.conf
exclusivo
O Object Gateway oferece muita flexibilidade e é exclusivo em comparação com outras seções do ceph.conf
. Todos os outros componentes do Ceph têm cabeçalhos estáticos, como [mon]
ou [osd]
. O Object Gateway tem cabeçalhos exclusivos, como [client.rgw.rgw1]
. Isso significa que o arquivo rgw.conf
precisa de uma entrada de cabeçalho. Para ver exemplos, consulte
/srv/salt/ceph/configuration/files/rgw.conf
ou
/srv/salt/ceph/configuration/files/rgw-ssl.conf
Após fazer mudanças personalizadas nos arquivos de configuração mencionados acima, execute as fases 3 e 4 para aplicá-las aos nós do cluster:
root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4
Esses arquivos são incluídos do arquivo de gabarito /srv/salt/ceph/configuration/files/ceph.conf.j2
e correspondem às diferentes seções aceitas pelo arquivo de configuração do Ceph. Ao inserir um trecho da configuração no arquivo correto, o DeepSea pode incluí-lo na seção correta. Você não precisa adicionar nenhum dos cabeçalhos de seção.
Para aplicar quaisquer opções de configuração apenas às instâncias específicas de um daemon, adicione um cabeçalho como [osd.1]
. As seguintes opções de configuração serão aplicadas apenas ao daemon OSD com o ID 1.
As últimas declarações em uma seção anulam as anteriores. Portanto, é possível anular a configuração padrão conforme especificado no gabarito /srv/salt/ceph/configuration/files/ceph.conf.j2
. Por exemplo, para desativar a autenticação do cephx, adicione as três linhas a seguir ao arquivo /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf
:
auth cluster required = none auth service required = none auth client required = none
Ao redefinir os valores padrão, as ferramentas relacionadas do Ceph, como rados
, podem emitir avisos de que os valores específicos do ceph.conf.j2
foram redefinidos no global.conf
. Esses avisos são causados por um parâmetro atribuído duas vezes no ceph.conf
resultante.
Como uma solução alternativa para este caso específico, siga estas etapas:
Mude o diretório atual para /srv/salt/ceph/configuration/create
:
root@master #
cd /srv/salt/ceph/configuration/create
Copie default.sls
para custom.sls
:
root@master #
cp default.sls custom.sls
Edite custom.sls
e mude ceph.conf.j2
para custom-ceph.conf.j2
.
Mude o diretório atual para /srv/salt/ceph/configuration/files
:
root@master #
cd /srv/salt/ceph/configuration/files
Copie ceph.conf.j2
para custom-ceph.conf.j2
:
root@master #
cp ceph.conf.j2 custom-ceph.conf.j2
Edite custom-ceph.conf.j2
e apague a seguinte linha:
{% include "ceph/configuration/files/rbd.conf" %}
Edite global.yml
e adicione a seguinte linha:
configuration_create: custom
Atualize o pillar:
root@master #
salt target saltutil.pillar_refresh
Execute a fase 3:
root@master #
salt-run state.orch ceph.stage.3
Agora você deve ter apenas uma entrada para cada definição de valor. Para recriar a configuração, execute:
root@master #
salt-run state.orch ceph.configuration.create
e, em seguida, verifique o conteúdo de /srv/salt/ceph/configuration/cache/ceph.conf
.
Se você precisar aplicar muitas configurações personalizadas, use as seguintes declarações de inclusão nos arquivos de configuração personalizados para facilitar o gerenciamento de arquivos. Veja a seguir um exemplo de arquivo osd.conf
:
[osd.1] {% include "ceph/configuration/files/ceph.conf.d/osd1.conf" ignore missing %} [osd.2] {% include "ceph/configuration/files/ceph.conf.d/osd2.conf" ignore missing %} [osd.3] {% include "ceph/configuration/files/ceph.conf.d/osd3.conf" ignore missing %} [osd.4] {% include "ceph/configuration/files/ceph.conf.d/osd4.conf" ignore missing %}
No exemplo anterior, os arquivos osd1.conf
, osd2.conf
, osd3.conf
e osd4.conf
contêm opções de configuração específicas ao OSD relacionado.
As mudanças feitas nos arquivos de configuração do Ceph entrarão em vigor após a reinicialização dos daemons Ceph relacionados. Consulte a Seção 16.1, “Configuração de tempo de execução” para obter mais informações sobre como mudar a configuração de tempo de execução do Ceph.
AppArmor é uma solução de segurança que limita programas por um perfil específico. Para obter mais detalhes, visite https://www.suse.com/documentation/sles-15/book_security/data/part_apparmor.html.
O DeepSea oferece três estados para os perfis do AppArmor: “enforce”, “complain” e “disable”. Para ativar um determinado estado do AppArmor, execute:
salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-STATE
Para colocar os perfis do AppArmor no estado “enforce”:
root@master #
salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-enforce
Para colocar os perfis do AppArmor no estado “complain”:
root@master #
salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-complain
Para desabilitar os perfis do AppArmor:
root@master #
salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-disable
Cada uma destas três chamadas verifica se o AppArmor está instalado e o instala, se for o caso. Em seguida, o serviço systemd
relacionado é iniciado e habilitado. O DeepSea avisará você se o AppArmor foi instalado e iniciado/habilitado de outra maneira e, portanto, está em execução sem os perfis do DeepSea.
Por padrão, o DeepSea implanta os clusters do Ceph com perfis ajustados ativos nos nós do Ceph Monitor, Ceph Manager e Ceph OSD. Em alguns casos, você pode precisar desativar permanentemente os perfis ajustados. Para fazer isso, insira as seguintes linhas no /srv/pillar/ceph/stack/global.yml
e execute novamente a fase 3:
alternative_defaults: tuned_mgr_init: default-off tuned_mon_init: default-off tuned_osd_init: default-off
root@master #
salt-run state.orch ceph.stage.3
O executor ceph.purge
remove o cluster inteiro do Ceph. Desta forma, você pode limpar o ambiente do cluster ao testar configurações diferentes. Após a conclusão do ceph.purge
, o cluster Salt será revertido ao estado no fim da fase 1 do DeepSea. Em seguida, você poderá mudar o policy.cfg
(consulte o Seção 5.5.1, “Arquivo policy.cfg
”) ou prosseguir para a fase 2 do DeepSea com a mesma configuração.
Para evitar a exclusão acidental, a orquestração verifica se a segurança está desligada. Você pode desligar as medidas de segurança e remover o cluster do Ceph executando:
root@master #
salt-run disengage.safetyroot@master #
salt-run state.orch ceph.purge
Para evitar que qualquer pessoa execute o ceph.purge
, crie um arquivo denominado disabled.sls
no diretório /srv/salt/ceph/purge
e insira a linha a seguir no arquivo /srv/pillar/ceph/stack/global.yml
:
purge_init: disabled
Se você já criou funções personalizadas para o Ceph Dashboard (consulte a Seção 22.2.6, “Adicionando funções personalizadas” e a Seção 22.10.2, “Funções e permissões de usuário” para obter informações detalhadas), precisa realizar etapas manuais para purgá-las antes de executar o ceph.purge
. Por exemplo, se o nome da função personalizada para o Object Gateway for “us-east-1”, siga estas etapas:
root@master #
cd /srv/salt/ceph/rescindroot@master #
rsync -a rgw/ us-east-1root@master #
sed -i 's!rgw!us-east-1!' us-east-1/*.sls