Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com › Documentação do SUSE Enterprise Storage 5 › Guia de Implantação › Implantação e upgrade do cluster › Personalizando a configuração padrão
ConteúdoConteúdo
Guia de Implantação
  1. Sobre este guia
  2. I SUSE Enterprise Storage
    1. 1 SUSE Enterprise Storage e Ceph
    2. 2 Requisitos e recomendações de hardware
    3. 3 Configuração de alta disponibilidade do nó de admin do Ceph
  3. II Implantação e upgrade do cluster
    1. 4 Implantando com o DeepSea/Salt
    2. 5 Fazendo upgrade de versões anteriores
    3. 6 Fazendo backup da configuração do cluster
    4. 7 Personalizando a configuração padrão
  4. III Instalação de serviços adicionais
    1. 8 Instalação de serviços para acessar seus dados
    2. 9 Ceph Object Gateway
    3. 10 Instalação do iSCSI Gateway
    4. 11 Instalação do CephFS
    5. 12 Instalação do NFS Ganesha
    6. 13 Exportar o CephFS via Samba
  5. A Atualizações da documentação
Navegação←→
documentation.suse.com › Documentação do SUSE Enterprise Storage 5 › Guia de Implantação › Implantação e upgrade do cluster › Personalizando a configuração padrão
Topo
←→
Aplica-se a SUSE Enterprise Storage 5

7 Personalizando a configuração padrão

7.1 Usando arquivos de configuração personalizados
7.2 Modificando a configuração descoberta

Você pode mudar a configuração padrão do cluster gerada na Fase 2 (consulte Descrição das fases do DeepSea). Por exemplo, talvez você precise mudar as configurações de rede ou o software que está instalado por padrão no master Salt. Para o primeiro caso, você pode modificar o pillar atualizado após a Fase 2. No segundo caso, costuma-se criar um arquivo sls personalizado e adicioná-lo ao pillar. Os detalhes estão descritos nas seções a seguir.

7.1 Usando arquivos de configuração personalizados

Esta seção lista as diversas tarefas que requerem adição/modificação de seus próprios arquivos sls. Normalmente, esse tipo de procedimento é usado quando você precisa mudar o processo de implantação padrão.

Dica
Dica: Adicionar prefixo aos arquivos .sls personalizados

Seus arquivos .sls personalizados pertencem ao mesmo subdiretório que os arquivos .sls do DeepSea. Para evitar sobregravar seus arquivos .sls por aqueles que podem ser recém-adicionados do pacote do DeepSea, adicione um prefixo ao nome deles com a string custom-.

7.1.1 Desabilitando uma etapa de implantação

Se você resolver determinada tarefa fora do processo de implantação do DeepSea e, desse modo, precisar ignorá-la, crie um arquivo “no-operation” seguindo este exemplo:

Procedimento 7.1: Desabilitando a sincronização de horário

  1. Crie /srv/salt/ceph/time/disabled.sls com o seguinte conteúdo e grave-o: 

    disable time setting:
test.nop

  2. Edite /srv/pillar/ceph/stack/global.yml, adicione a seguinte linha e grave-o: 

    time_init: disabled

  3. Faça a verificação atualizando o pillar e executando a etapa: 

    root@master # salt target saltutil.pillar_refresh
root@master # salt 'admin.ceph' state.apply ceph.time
admin.ceph:
  Name: disable time setting - Function: test.nop - Result: Clean

Summary for admin.ceph
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
    Nota
    Nota: ID exclusivo

    O ID da tarefa “disable time setting” pode ser qualquer mensagem exclusiva em um arquivo sls. Para impedir colisões de ID, especifique descrições exclusivas.

7.1.2 Substituindo uma etapa de implantação

Se você precisa substituir o comportamento padrão de uma etapa específica por um personalizado, crie um arquivo sls personalizado com o conteúdo de substituição.

Por padrão, /srv/salt/ceph/pool/default.sls cria uma imagem rbd chamada “demo”. Em nosso exemplo, não desejamos que essa imagem seja criada, mas precisamos de duas imagens: “archive1” e “archive2”.

Procedimento 7.2: Substituindo a imagem rbd demo por duas imagens rbd personalizadas

  1. Crie /srv/salt/ceph/pool/custom.sls com o seguinte conteúdo e grave-o: 

    wait:
  module.run:
    - name: wait.out
    - kwargs:
        'status': "HEALTH_ERR"1
    - fire_event: True

archive1:
  cmd.run:
    - name: "rbd -p rbd create archive1 --size=1024"2
    - unless: "rbd -p rbd ls | grep -q archive1$"
    - fire_event: True

archive2:
  cmd.run:
    - name: "rbd -p rbd create archive2 --size=768"
    - unless: "rbd -p rbd ls | grep -q archive2$"
    - fire_event: True

    1

    O módulo wait ficará pausado enquanto o status do cluster do Ceph for HEALTH_ERR. Nas instalações novas, um cluster do Ceph pode ter esse status até que um número suficiente de OSDs se torne disponível e a criação de pools seja concluída.

    2

    O comando rbd não é idempotente. Se o mesmo comando de criação for executado novamente após a existência da imagem, haverá falha no estado do Salt. A declaração unless impede que isso aconteça.

  2. Para chamar o arquivo personalizado recém-criado, em vez do padrão, você precisa editar /srv/pillar/ceph/stack/ceph/cluster.yml, adicionar a seguinte linha e gravá-lo: 

    pool_init: custom

  3. Faça a verificação atualizando o pillar e executando a etapa: 

    root@master # salt target saltutil.pillar_refresh
root@master # salt 'admin.ceph' state.apply ceph.pool
Nota
Nota: Autorização

A criação de pools ou imagens requer autorização suficiente. O minion admin.ceph tem um chaveiro de admin.

Dica
Dica: Modo alternativo

Outra opção é mudar a variável em /srv/pillar/ceph/stack/ceph/roles/master.yml. O uso desse arquivo reduzirá o acúmulo de dados do pillar para outros minions.

7.1.3 Modificando uma etapa de implantação

Às vezes, você pode precisar de uma etapa específica para realizar algumas tarefas adicionais. Não é recomendável modificar o arquivo de estado relacionado, pois ele pode complicar um upgrade futuro. Em vez disso, crie um arquivo separado para executar as tarefas adicionais exatamente como foi descrito na Seção 7.1.2, “Substituindo uma etapa de implantação”.

Nomeie o novo arquivo sls de modo descritivo. Por exemplo, se você precisa criar duas imagens rbd além da imagem demo, nomeie o arquivo archive.sls.

Procedimento 7.3: Criando duas imagens rbd adicionais

  1. Crie /srv/salt/ceph/pool/custom.sls com o seguinte conteúdo e grave-o: 

    include:
 - .archive
 - .default
    Dica
    Dica: Incluir precedência

    Neste exemplo, o Salt criará as imagens archive e, em seguida, a imagem demo. A ordem não importa neste exemplo. Para mudar a ordem, inverta as linhas após a diretiva include:.

    Você pode adicionar a linha include diretamente ao archive.sls, e todas as imagens também serão criadas. No entanto, independentemente de onde a linha include for colocada, o Salt processará primeiro as etapas no arquivo incluído. Embora esse comportamento possa ser anulado pelas declarações requires e order, um arquivo separado incluindo as outras etapas garante a ordem e reduz as chances de confusão.

  2. Edite /srv/pillar/ceph/stack/ceph/cluster.yml, adicione a seguinte linha e grave-o: 

    pool_init: custom

  3. Faça a verificação atualizando o pillar e executando a etapa: 

    root@master # salt target saltutil.pillar_refresh
root@master # salt 'admin.ceph' state.apply ceph.pool

7.1.4 Modificando uma fase de implantação

Se você precisa adicionar uma etapa de implantação completamente separada, crie três novos arquivos: um sls que executa o comando, um arquivo de orquestração e um arquivo personalizado que alinha a nova etapa às etapas originais da implantação.

Por exemplo, se você precisa executar logrotate em todos os minions como parte da fase de preparação:

Crie primeiro um arquivo sls e inclua o comando logrotate.

Procedimento 7.4: Executando o logrotate em todos os minions Salt

  1. Crie um diretório, como /srv/salt/ceph/logrotate.

  2. Crie /srv/salt/ceph/logrotate/init.sls com o seguinte conteúdo e grave-o: 

    rotate logs:
  cmd.run:
    - name: "/usr/sbin/logrotate /etc/logrotate.conf"

  3. Verifique se o comando funciona em um minion: 

    root@master # salt 'admin.ceph' state.apply ceph.logrotate

Como o arquivo de orquestração precisa ser executado antes de todas as outras etapas de preparação, adicione-o à Fase 0 Preparação:

  1. Crie /srv/salt/ceph/stage/prep/logrotate.sls com o seguinte conteúdo e grave-o: 

    logrotate:
  salt.state:
    - tgt: '*'
    - sls: ceph.logrotate

  2. Verifique se o arquivo de orquestração funciona: 

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

O último arquivo é aquele personalizado que inclui a etapa adicional com as etapas originais:

  1. Crie /srv/salt/ceph/stage/prep/custom.sls com o seguinte conteúdo e grave-o: 

    include:
  - .logrotate
  - .master
  - .minion

  2. Anule o comportamento padrão. Edite /srv/pillar/ceph/stack/global.yml, adicione a seguinte linha e grave o arquivo: 

    stage_prep: custom

  3. Verifique se a Fase 0 funciona: 

    root@master # salt-run state.orch ceph.stage.0
Nota
Nota: Por que global.yml?

O arquivo global.yml foi escolhido no lugar do cluster.yml porque, durante a fase de preparação, nenhum minion pertence ao cluster do Ceph e não tem acesso a quaisquer configurações no cluster.yml.

7.1.5 Desabilitando atualizações e reinicializações durante a fase 0

Durante a Fase 0 (consulte Descrição das fases do DeepSea para obter mais informações sobre as fases do DeepSea), o master e os minions Salt podem ser reinicializados porque os pacotes recém-atualizados, como o kernel, exigem reinicialização do sistema.

Para evitar a atualização ou reinicialização de nós do cluster durante a Fase 0, edite o /srv/pillar/ceph/stack/ceph/cluster.yml e adicione as opções stage_prep_master ou stage_prep_minion, dependendo se você precisa modificar o comportamento do master Salt, todos os minions Salt ou todos os nós.

As duas opções aceitam os seguintes valores:

default-no-update-no-reboot

Impede que os nós atualizem seus pacotes e sejam reinicializados.

default-no-update-reboot

Impede que os nós atualizem seus pacotes, mas as reinicializações são permitidas.

default-update-no-reboot

Impede que os nós sejam reinicializados, mas permite a atualização dos pacotes.

default

Permite a atualização de pacotes dos nós e também sua reinicialização.

7.2 Modificando a configuração descoberta

Após concluir a Fase 2, convém mudar a configuração descoberta. Para ver as configurações atuais, execute: 

root@master # salt target pillar.items

Normalmente, a saída da configuração padrão de um único minion é semelhante a esta: 

----------
    available_roles:
        - admin
        - mon
        - storage
        - mds
        - igw
        - rgw
        - client-cephfs
        - client-radosgw
        - client-iscsi
        - mds-nfs
        - rgw-nfs
        - master
    cluster:
        ceph
    cluster_network:
        172.16.22.0/24
    fsid:
        e08ec63c-8268-3f04-bcdb-614921e94342
    master_minion:
        admin.ceph
    mon_host:
        - 172.16.21.13
        - 172.16.21.11
        - 172.16.21.12
    mon_initial_members:
        - mon3
        - mon1
        - mon2
    public_address:
        172.16.21.11
    public_network:
        172.16.21.0/24
    roles:
        - admin
        - mon
        - mds
    time_server:
        admin.ceph
    time_service:
        ntp

As configurações mencionadas acima são distribuídas entre vários arquivos de configuração. A estrutura de diretórios com esses arquivos é definida no diretório /srv/pillar/ceph/stack/stack.cfg. Em geral, os arquivos a seguir descrevem seu cluster:

  • /srv/pillar/ceph/stack/global.yml: o arquivo afeta todos os minions no cluster do Salt.

  • /srv/pillar/ceph/stack/ceph/cluster.yml: o arquivo afeta todos os minions no cluster do Ceph denominado ceph.

  • /srv/pillar/ceph/stack/ceph/roles/role.yml: afeta todos os minions que receberam a função específica no cluster ceph.

  • /srv/pillar/ceph/stack/cephminions/ID do minion/yml: afeta o minion individual.

Nota
Nota: Sobregravando diretórios com valores padrão

Há uma árvore de diretório paralela que armazena a configuração padrão em /srv/pillar/ceph/stack/default. Não mude valores aqui, pois eles serão sobregravados.

Veja a seguir o procedimento comum para mudar a configuração coletada:

  1. Encontre o local do item de configuração que você precisa mudar. Por exemplo, se você precisa mudar a configuração relacionada ao cluster, como a rede do cluster, edite o arquivo /srv/pillar/ceph/stack/ceph/cluster.yml.

  2. Grave o arquivo.

  3. Para verificar as mudanças, execute: 

    root@master # salt target saltutil.pillar_refresh

    e, em seguida: 

    root@master # salt target pillar.items
→Parte III Instalação de serviços adicionais←Capítulo 6 Fazendo backup da configuração do cluster
Imprimir esta página

© 2022 SUSE