Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Aplica-se a SUSE Enterprise Storage 5

1 Administração do cluster do Salt

Após implantar o 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.

1.1 Adicionando novos nós do cluster

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:

  1. Instale o SUSE Linux Enterprise Server 12 SP3 no novo nó, defina a configuração de rede para que ela resolva o nome de host do master Salt corretamente e 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
  2. Aceite todas as chaves do Salt no master Salt:

    root@master # salt-key --accept-all
  3. Verifique se o /srv/pillar/ceph/deepsea_minions.sls também está direcionado para o novo minion Salt. Consulte o Seção 4.2.2.1, “Correspondendo o nome do minion” do Procedimento 4.1, “Executando as fases de implantação” para obter mais detalhes.

  4. 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
  5. 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
  6. 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 4.5.1, “Arquivo policy.cfg.

  7. 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
  8. As fases de configuração e implantação incluem os nós recém-adicionados:

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

1.2 Adicionando novas funções aos nós

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

  1. 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 4.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
  2. Execute a Fase 2 para atualizar o pilar:

    root@master # salt-run state.orch ceph.stage.2
  3. 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.

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

1.3 Removendo e reinstalando nós do cluster

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

Exemplo 1.1: Removendo um minion Salt do cluster

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
profile-default/cluster/data*.sls
profile-default/stack/default/ceph/minions/data*.yml
[...]

Portanto, para remover o minion Salt “data2.ceph”, mude as linhas para o seguinte:

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

Em seguida, execute as Fases 2 e 5:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.5
Exemplo 1.2: Migrando nós

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 4.1, “Executando as fases de implantação”) para o novo hardware, você denominou o novo gateway 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
profile-default/cluster/data[1-7]*.sls
profile-default/stack/default/ceph/minions/data[1-7]*.sls

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

Portanto, faça uma mudança para:

# 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

Execute as Fases de 2 a 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.

1.4 Reimplantando nós do monitor

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

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

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

  2. Execute as Fases de 2 a 5 do DeepSea para aplicar as mudanças:

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

1.5 Adicionar um OSD a um nó

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

1.6 Removendo um OSD

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

1.6.1 Removendo à força os OSDs danificados

Há casos em que há falha na remoção normal de um OSD (consulte a Seção 1.6, “Removendo um OSD”). Por exemplo, isso poderá acontecer se o OSD ou o cache dele estiver danificado, quando ele é afetado por operações de E/S travadas ou quando há falha na desmontagem do disco OSD. Nesse caso, você precisa forçar a remoção do OSD:

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

Esse comando remove tanto a partição de dados quanto as partições de diário ou WAL/BD.

Para identificar dispositivos de diário/WAL/BD órfãos, siga estas etapas:

  1. Selecione o dispositivo que pode ter partições órfãs e grave a lista de suas partições em um arquivo:

    root@minion > ls /dev/sdd?* > /tmp/partitions
  2. Execute readlink em todos os dispositivos block.wal, block.db e de diário e compare a saída com a lista de partições que foi gravada:

    root@minion > readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \
     | sort | comm -23 /tmp/partitions -

    A saída é a lista de partições que não são usadas pelo Ceph.

  3. Remova as partições órfãs que não pertencem ao Ceph usando o comando de sua preferência (por exemplo, fdisk, parted ou sgdisk).

1.7 Recuperando um nó OSD reinstalado

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:

  1. Reinstale o sistema operacional no nó.

  2. Instale o pacote salt-minion no nó OSD, apague a chave antiga do minion Salt no master Salt e registre a nova chave no master Salt. Para obter mais informações sobre a implantação do minion Salt, consulte o Seção 4.3, “Implantação do cluster”.

  3. Em vez de executar toda a Fase 0, execute as seguintes partes:

    root@master # salt 'osd_node' state.apply ceph.sync
    root@master # salt 'osd_node' state.apply ceph.packages.common
    root@master # salt 'osd_node' state.apply ceph.mines
    root@master # salt 'osd_node' state.apply ceph.updates
  4. Execute as Fases de 1 a 5 do DeepSea:

    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4
    root@master # salt-run state.orch ceph.stage.5
  5. Execute a Fase 0 do DeepSea:

    root@master # salt-run state.orch ceph.stage.0
  6. Reinicialize o nó OSD relevante. Todos os discos OSD serão redescobertos e reutilizados.

1.8 Instalação automatizada pelo Salt

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

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

1.9 Atualizando os nós do cluster

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:

  • O Ceph relata “HEALTH_ERR” por mais do que 300 segundos.

  • Os minions Salt são consultados para verificar se os serviços atribuídos deles ainda estão ativos depois de uma atualização. Haverá falha na atualização se os serviços ficarem inativos por mais do que 900 segundos.

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

default

Instalar as atualizações e reinicializar após a atualização.

default-update-no-reboot

Instalar as atualizações sem reinicializar.

default-no-update-reboot

Reinicializar sem instalar as atualizações.

default-no-update-no-reboot

Não instalar as atualizações nem reinicializar.

1.10 Parando ou reinicializando o cluster

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:

  1. Especifique para o cluster do Ceph não marcar os OSDs com o flag “out”:

    root # ceph osd set noout
  2. Pare os daemons e os nós na seguinte ordem:

    1. Clientes de armazenamento

    2. Gateways. Por exemplo, NFS Ganesha ou Object Gateway

    3. Servidor de Metadados

    4. Ceph OSD

    5. Ceph Manager

    6. Ceph Monitor

  3. Se necessário, execute as tarefas de manutenção.

  4. Inicie os nós e os servidores na ordem inversa do processo de encerramento:

    1. Ceph Monitor

    2. Ceph Manager

    3. Ceph OSD

    4. Servidor de Metadados

    5. Gateways. Por exemplo, NFS Ganesha ou Object Gateway

    6. Clientes de armazenamento

  5. Remova o flag “noout”:

    root # ceph osd unset noout

1.11 Arquivo ceph.conf personalizado

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

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

1.11.1 Anulando os padrões

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

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

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

Imprimir esta página