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 4, Implantando com o DeepSea/Salt:

Você pode implantar com o DeepSea todos os tipos de funções suportadas. Consulte o Seção 4.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.

Dica: Fases e funções obrigatórias e opcionais

Em geral, é recomendável executar a implantação completa de todas as Fases de 0 a 5 para adicionar uma nova função ao nó do cluster. Para economizar algum tempo, você pode ignorar as Fases 3 ou 4, dependendo do tipo de função que você pretende implantar. Enquanto as funções OSD e MON incluem os serviços básicos e são exigidas pelo Ceph, outras funções, como Object Gateway, são opcionais. As fases de implantação do DeepSea são hierárquicas: a Fase 3 implanta os serviços básicos e a Fase 4 implanta os opcionais.

Portanto, você precisa executar a Fase 3 ao implantar as funções básicas, como MON, em um nó OSD existente e pode ignorar a Fase 4.

Da mesma forma, você pode ignorar a Fase 3 ao implantar os serviços opcionais, como Object Gateway, mas precisa executar a Fase 4 neste caso.

Para adicionar um novo serviço a um nó existente, siga estas etapas:

Dica

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, recomendamos adicionar ao mesmo tempo todos os OSDs desejados.

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 4.3, “Implantação do cluster”.

Nota: Removendo OSDs 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.

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.

Nota: Preservando as partições criadas por outros métodos

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.

[...]
# Hardware Profile
profile-default/cluster/data*.sls
profile-default/stack/default/ceph/minions/data*.yml
[...]

[...]
# Hardware Profile
profile-default/cluster/data[1,3-6]*.sls
profile-default/stack/default/ceph/minions/data[1,3-6]*.yml
[...]

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

# Hardware Profile
profile-default/cluster/data[1-7]*.sls
profile-default/stack/default/ceph/minions/data[1-7]*.sls

# Roles
role-rgw/cluster/data8*.sls

# Hardware Profile
profile-default/cluster/data[1-8]*.sls
profile-default/stack/default/ceph/minions/data[1-8]*.sls

# Roles
role-rgw/cluster/rgw1*.sls

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.

Importante: O mínimo são três nós do monitor

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 um ou 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 1.1, “Adicionando novos nós do cluster” e a Seção 1.2, “Adicionando novas funções aos nós”.

Para obter mais informações sobre como remover nós do cluster, consulte a Seção 1.3, “Removendo e reinstalando nós do cluster”.

Há dois graus básicos de falha no nó do Ceph:

Para adicionar um disco a um nó OSD existente, verifique se qualquer partição no disco foi removida e limpa. Consulte a Etapa 13 no Seção 4.3, “Implantação do cluster” para obter mais detalhes. Depois que o disco estiver vazio, adicione-o ao arquivo YAML do nó. O caminho para o arquivo é /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/nome_do_nó.yml. Após gravar o arquivo, execute as fases 2 e 3 do DeepSea:

root@master # deepsea stage run ceph.stage.2
root@master # deepsea stage run ceph.stage.3

Dica: Perfis atualizados automaticamente

Em vez de editar manualmente o arquivo YAML, o DeepSea pode criar novos perfis. Para permitir que o DeepSea crie novos perfis, os perfis existentes precisam ser movidos:

root@master # old /srv/pillar/ceph/proposals/profile-default/
root@master # deepsea stage run ceph.stage.1
root@master # deepsea stage run ceph.stage.2
root@master # deepsea stage run ceph.stage.3

Você pode remover um Ceph OSD do cluster executando o seguinte comando:

root@master # salt-run disengage.safety
root@master # salt-run remove.osd OSD_ID

OSD_ID precisa ser o número do OSD sem o termo osd. Por exemplo, use apenas o dígito 3 de osd.3.

Dica: Removendo vários OSDs

Não é possível remover vários OSDs em paralelo com o comando salt-run remove.osd. Para automatizar a remoção de vários OSDs, você pode usar o seguinte loop (5, 21, 33, 19 são os números de ID dos OSDs que serão removidos):

for i in 5 21 33 19
do
 echo $i
 salt-run disengage.safety
 salt-run remove.osd $i
done

root@master # target osd.remove OSD_ID force=True

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:

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

Atenção

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:

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 será iniciada.

Se a operação for executada apropriadamente, mude a última linha no /etc/salt/master.d/reactor.conf:

- /srv/salt/ceph/reactor/discovery.sls

para

- /srv/salt/ceph/reactor/all_stages.sls

Convém aplicar atualizações sequenciais aos nós do cluster regularmente. Para aplicar as atualizações, execute a Fase 0:

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

Se o DeepSea detectar um cluster do Ceph em execução, ele aplicará as atualizações e reiniciará os nós sequencialmente. O DeepSea segue a recomendação oficial do Ceph de atualizar primeiro os monitores, depois os OSDs e, por último, os serviços adicionais, como MDS, Object Gateway, iSCSI Gateway ou NFS Ganesha. O DeepSea interromperá o processo de atualização se ele detectar algum problema no cluster. Veja a seguir o que pode provocar isso:

Faça esses ajustes para garantir que o cluster do Ceph continue funcionando mesmo com as atualizações corrompidas ou com falha.

A Fase 0 do DeepSea atualizará o sistema por meio do zypper update e o reinicializará se o kernel for atualizado. Para eliminar a possibilidade de uma reinicialização forçada de todos os nós em potencial, verifique se o kernel mais recente está instalado e em execução antes de iniciar a Fase 0 do DeepSea.

Dica: zypper patch

Se você preferir atualizar o sistema usando o comando zypper patch, edite o /srv/pillar/ceph/stack/global.yml e adicione a seguinte linha:

update_method_init: zypper-patch

Você pode mudar o comportamento de reinicialização padrão da Fase 0 do DeepSea adicionando as seguintes linhas ao /srv/pillar/ceph/stack/global.yml:

stage_prep_master: default-update-no-reboot
stage_prep_minion: default-update-no-reboot

stage_prep_master define o comportamento da Fase 0 do master Salt, e stage_prep_minion define o comportamento de todos os minions. Todos os parâmetros disponíveis são:

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:

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:

Nota: 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. Consulte /srv/salt/ceph/configuration/files/rgw.conf para ver um exemplo.

Importante: Executar a fase 3

Após fazer mudanças personalizadas nos arquivos de configuração mencionados acima, execute a Fase 3 para aplicá-las aos nós do cluster:

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

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.

Dica

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.

auth cluster required = none
auth service required = none
auth client required = none

1.11.2 Incluindo arquivos de configuração #

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.

Dica: Configuração de tempo de execução

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 1.12, “Configuração de tempo de execução do Ceph” para obter mais informações sobre como mudar a configuração de tempo de execução do Ceph.

A Seção 1.11, “Arquivo ceph.conf personalizado” descreve como fazer mudanças no arquivo de configuração do Ceph ceph.conf. Entretanto, o comportamento real do cluster não é determinado pelo estado atual do arquivo ceph.conf, mas sim pela configuração dos daemons Ceph em execução, que são armazenados na memória.

É possível consultar determinada configuração em um daemon Ceph usando o soquete de admin no nó em que o daemon está em execução. Por exemplo, o seguinte comando obtém o valor do parâmetro de configuração osd_max_write_size do daemon denominado osd.0:

root # ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok \
config get osd_max_write_size
{
  "osd_max_write_size": "90"
}

Você também pode mudar as configurações dos daemons em tempo de execução. Lembre-se de que essa mudança é temporária e será perdida após a reinicialização do próximo daemon. Por exemplo, o seguinte comando muda o parâmetro osd_max_write_size para “50” em todos os OSDs no cluster:

root # ceph tell osd.* injectargs --osd_max_write_size 50

Atenção: injectargs não é confiável

Mudar as configurações do cluster com o comando injectargs não é 100% confiável. Se você precisa ter certeza de que o parâmetro mudado está ativo, mude-o no arquivo de configuração e reinicie todos os daemons no cluster.