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

4 Implantando com o DeepSea/Salt

Nota
Nota: ceph-deploy removido do SUSE Enterprise Storage 5

A ferramenta de implantação de cluster ceph-deploy foi descontinuada no SUSE Enterprise Storage 4 e totalmente removida para entrada do DeepSea a partir do SUSE Enterprise Storage 5.

O Salt, juntamente com o DeepSea, é uma pilha de componentes que ajuda você a implantar e gerenciar a infraestrutura do servidor. Ele é muito escalável, rápido e relativamente fácil de ser executado. Leia as seguintes considerações antes de começar a implantação do cluster com o Salt:

  • Os minions Salt são nós controlados por um nó dedicado denominado master Salt. Os minions Salt têm funções. Por exemplo, Ceph OSD, Ceph Monitor, Ceph Manager, Object Gateway, iSCSI Gateway ou NFS Ganesha.

  • Um master Salt executa seu próprio minion Salt. Ele é necessário para executar tarefas com privilégio (por exemplo, criar, autorizar e copiar chaves para os minions), dessa forma, os minions remotos nunca precisam executar tarefas com privilégio.

    Dica
    Dica: Compartilhando várias funções por servidor

    O desempenho do cluster do Ceph é melhor quando cada função é implantada em um nó separado. Porém, as implantações reais às vezes exigem que um nó seja compartilhado com várias funções. Para evitar problemas de desempenho e de procedimento de upgrade, não implante a função Ceph OSD, Servidor de Metadados ou Ceph Monitor no master Salt.

  • Os minions Salt precisam resolver corretamente o nome de host do master Salt na rede. Por padrão, eles procuram o nome de host salt, mas você pode especificar qualquer outro nome de host acessível por rede no arquivo /etc/salt/minion. Consulte a Seção 4.3, “Implantação do cluster”.

4.1 Ler os detalhes da versão

Nos detalhes da versão, 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/.

4.2 Introdução ao DeepSea

O objetivo do DeepSea é economizar o tempo do administrador e executar com segurança operações complexas em um cluster do Ceph.

O Ceph é uma solução de software muito configurável. Ele promove a liberdade e a responsabilidade dos administradores do sistema.

A configuração mínima do Ceph é ideal para fins de demonstração, mas não apresenta os recursos interessantes do Ceph que você pode ver com um grande número de nós.

O DeepSea coleta e armazena dados sobre os servidores individuais, como endereços e nomes de dispositivos. Para um sistema de armazenamento distribuído, como Ceph, pode haver centenas desses itens para coletar e armazenar. A coleta de informações e a entrada manual de dados em uma ferramenta de gerenciamento de configuração são exaustivas e propensas a erros.

A maioria das etapas necessárias para preparar os servidores, coletar a configuração, configurar e implantar o Ceph é a mesma. No entanto, isso não resolve o gerenciamento de funções separadas. Para operações do dia a dia, a simples capacidade de adicionar hardware a determinada função e removê-lo sem problemas é um requisito.

O DeepSea resolve essas observações com a seguinte estratégia: ele consolida as decisões do administrador em um único arquivo. As decisões incluem atribuição de cluster, atribuição de função e atribuição de perfil. E o DeepSea coleta cada conjunto de tarefas em uma meta simples. Cada meta é uma fase:

Descrição das fases do DeepSea
  • Fase 0: preparação. Durante essa fase, todas as atualizações necessárias são aplicadas, e o sistema pode ser reinicializado.

    Importante
    Importante: Executar novamente a Fase 0 após a reinicialização do master Salt

    Durante a Fase 0, se o master Salt for reinicializado para carregar a nova versão do kernel, você precisará executar a Fase 0 novamente; do contrário, os minions não serão direcionados.

  • Fase 1: descoberta. Nessa fase, você detecta o hardware inteiro no cluster e coleta as informações necessárias para configuração do Ceph. Para obter detalhes sobre a configuração, consulte a Seção 4.5, “Configuração e personalização”.

  • Fase 2: configuração. Você precisa preparar os dados de configuração em um formato específico.

  • Fase 3: implantação. Cria um cluster básico do Ceph com os serviços obrigatórios dele. Consulte a Seção 1.2.3, “Nós e daemons do Ceph” para ver a lista.

  • Fase 4: serviços. É possível instalar recursos adicionais do Ceph, como iSCSI, Object Gateway e CephFS, nessa fase. Cada um deles é opcional.

  • Fase 5: fase de remoção. Essa fase não é obrigatória e, durante a configuração inicial, não costuma ser necessária. Nessa fase, as funções dos minions e também a configuração do cluster são removidas. Você precisa executar essa fase quando tem que remover um nó de armazenamento do cluster. Para obter detalhes, consulte o Seção 1.3, “Removendo e reinstalando nós do cluster”.

Você encontra uma apresentação mais detalhada sobre o DeepSea em https://github.com/suse/deepsea/wiki.

4.2.1 Organização e locais importantes

O Salt tem vários locais padrão e diversas convenções de nomeação usados no nó master:

/srv/pillar

O diretório armazena os dados de configuração para os minions do cluster. Pillar é uma interface que fornece valores globais de configuração a todos os minions do seu cluster.

/srv/salt/

O diretório armazena os arquivos de estado do Salt (também denominados sls). Os arquivos de estado são descrições formatadas dos estados em que o cluster deve estar. Para obter mais informações, consulte a documentação do Salt.

/srv/module/runners

O diretório armazena os scripts do Python conhecidos como executores. Eles são executados no nó master.

/srv/salt/_modules

O diretório armazena os scripts do Python que são chamados de módulos. Os módulos são aplicados a todos os minions no seu cluster.

/srv/pillar/ceph

O diretório é usado pelo DeepSea. Os dados de configuração coletados são armazenados nele.

/SRV/salt/ceph

Um diretório usado pelo DeepSea. Ele armazena arquivos sls que podem estar em formatos diferentes, mas cada subdiretório contém arquivos sls. Cada subdiretório contém apenas um tipo de arquivo sls. Por exemplo, /srv/salt/ceph/stage contém os arquivos de orquestração que são executados por salt-run state.orchestrate.

4.2.2 Direcionando os minions

Os comandos do DeepSea são executados pela infraestrutura do Salt. Ao usar o comando salt, você precisa especificar um conjunto de minions Salt afetados pelo comando. Descrevemos o conjunto de minions como destino para o comando salt. As seções a seguir descrevem os métodos possíveis para direcionar os minions.

4.2.2.1 Correspondendo o nome do minion

Você pode direcionar um minion ou um grupo de minions correspondendo os nomes deles. Normalmente, o nome de um minion é o nome de host curto do nó onde o minion é executado. Trata-se de um método de direcionamento geral do Salt que não está relacionado ao DeepSea. Você pode usar glob, expressões regulares ou listas para limitar a faixa de nomes de minion. Veja a seguir a sintaxe geral:

root@master # salt target example.module
Dica
Dica: Cluster apenas do Ceph

Se todos os minions Salt em seu ambiente pertencerem ao cluster do Ceph, você poderá substituir com segurança o destino por '*' para incluir todos os minions registrados.

Corresponder todos os minions no domínio example.net (considerando que os nomes dos minions sejam idênticos aos nomes de host "completos" deles):

root@master # salt '*.example.net' test.ping

Corresponder o minion “web1” ao “web5”:

root@master # salt 'web[1-5]' test.ping

Corresponder tanto o minion “web1-prod” quanto “web1-devel” usando uma expressão regular:

root@master # salt -E 'web1-(prod|devel)' test.ping

Corresponder uma lista simples de minions:

root@master # salt -L 'web1,web2,web3' test.ping

Corresponder todos os minions no cluster:

root@master # salt '*' test.ping

4.2.2.2 Direcionando com um grain “deepsea”

Em um ambiente heterogêneo gerenciado pelo Salt em que o SUSE Enterprise Storage está implantado em um subconjunto de nós com outra(s) solução(ões) de cluster, convém “marcar” os minions relevantes aplicando um grain “deepsea”a eles. Dessa forma, você pode direcionar facilmente os minions do DeepSea nos ambientes em que a correspondência por nome de minion é problemática.

Para aplicar o grain “deepsea” a um grupo de minions, execute:

root@master # salt target grains.append deepsea default

Para remover o grain “deepsea” de um grupo de minions, execute:

root@master # salt target grains.delval deepsea destructive=True

Após aplicar o grain “deepsea” aos minions relevantes, você poderá direcioná-los da seguinte maneira:

root@master # salt -G 'deepsea:*' test.ping

O comando a seguir é um equivalente:

root@master # salt -C 'G@deepsea:*' test.ping

4.2.2.3 Definir a opção deepsea_minions

A definição do destino da opção deepsea_minions é um requisito para as implantações do DeepSea. O DeepSea a utiliza para instruir os minions durante a execução das fases (consulte Descrição das fases do DeepSea para obter detalhes).

Para definir ou mudar a opção deepsea_minions, edite o arquivo /srv/pillar/ceph/deepsea_minions.sls no master Salt e adicione ou substitua a seguinte linha:

deepsea_minions: target
Dica
Dica: Destino de deepsea_minions

Como destino para a opção deepsea_minions, você pode usar qualquer método de direcionamento: tanto Correspondendo o nome do minion quanto Direcionando com um grain “deepsea”.

Corresponder todos os minions Salt no cluster:

deepsea_minions: '*'

Corresponder todos os minions com o grain “deepsea”:

deepsea_minions: 'G@deepsea:*'

4.2.2.4 Para obter mais informações

Você pode usar métodos mais avançados para direcionar minions por meio da infraestrutura do Salt. Consulte https://docs.saltstack.com/en/latest/topics/targeting/ para obter uma descrição de todas as técnicas de direcionamento.

A página de manual do “deepsea-minions” também apresenta mais detalhes sobre o direcionamento do DeepSea (man 7 deepsea_minions).

4.3 Implantação do cluster

O processo de implantação do cluster tem várias fases. Primeiramente, você precisa preparar todos os nós do cluster configurando o Salt e, em seguida, implantar e configurar o Ceph.

Dica
Dica: Implantando nós do monitor sem definir perfis de OSD

Se você precisa ignorar a definição de perfis de OSD e implantar os nós do monitor primeiro, poderá fazer isso definindo a variável DEV_ENV. Ela permite implantar monitores sem a presença do diretório profile/ e implantar um cluster com pelo menos um nó de armazenamento, monitor e gerenciador.

Para definir a variável de ambiente, habilite-a globalmente configurando-a no arquivo /srv/pillar/ceph/stack/global.yml ou defina-a apenas para a sessão do shell atual:

root@master # export DEV_ENV=true

O procedimento a seguir descreve a preparação do cluster em detalhes.

  1. Instale e registre o SUSE Linux Enterprise Server 12 SP3 juntamente com a extensão do SUSE Enterprise Storage em cada nó do cluster.

  2. Verifique se os produtos apropriados estão instalados e foram registrados listando os repositórios de software existentes. A lista será semelhante a esta saída:

     root@minion > zypper lr -E
    #  | Alias   | Name                              | Enabled | GPG Check | Refresh
    ---+---------+-----------------------------------+---------+-----------+--------
     4 | [...]   | SUSE-Enterprise-Storage-5-Pool    | Yes     | (r ) Yes  | No
     6 | [...]   | SUSE-Enterprise-Storage-5-Updates | Yes     | (r ) Yes  | Yes
     9 | [...]   | SLES12-SP3-Pool                   | Yes     | (r ) Yes  | No
    11 | [...]   | SLES12-SP3-Updates                | Yes     | (r ) Yes  | Yes
  3. Defina as configurações de rede incluindo a resolução de nome DNS em cada nó. O master Salt e todos os minions Salt necessários para resolução entre eles por meio dos nomes de host. Para obter mais informações sobre como configurar uma rede, consulte https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_basicnet_yast.html. Para obter mais informações sobre como configurar um servidor DNS, consulte https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_dns.html.

  4. Configure, habilite e inicie o servidor de sincronização de horário NTP:

    root@master # systemctl enable ntpd.service
    root@master # systemctl start ntpd.service

    Encontre mais informações sobre como configurar o NTP em https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_netz_xntp_yast.html.

  5. Verifique se o serviço AppArmor está em execução e desabilite-o em cada nó do cluster. Inicie o módulo AppArmor do YaST, selecione Settings (Configurações) e, em seguida, desative a caixa de seleção Enable Apparmor (Habilitar Apparmor). Para confirmar, clique em Done (Concluído).

    O SUSE Enterprise Storage não funcionará com o AppArmor habilitado.

  6. Instale os pacotes salt-master e salt-minion no nó master Salt:

    root@master # zypper in salt-master salt-minion

    Verifique se o serviço salt-master está habilitado e foi iniciado. Se necessário, habilite-o e inicie-o:

    root@master # systemctl enable salt-master.service
    root@master # systemctl start salt-master.service
  7. Se você pretende usar um firewall, verifique se o nó master Salt tem as portas 4505 e 4506 abertas para todos os nós do minion Salt. Se as portas estiverem fechadas, você poderá abri-las usando o comando yast2 firewall e permitindo o serviço SaltStack.

    Atenção
    Atenção: Falha nas fases do DeepSea com firewall

    Há falha nas fases de implantação do DeepSea quando o firewall está ativo (e até configurado). Para percorrer as fases corretamente, você precisa desativar o firewall executando

    root@master # systemctl stop SuSEfirewall2.service

    ou definir a opção FAIL_ON_WARNING como “False” em /srv/pillar/ceph/stack/global.yml:

    FAIL_ON_WARNING: False
  8. Instale o pacote salt-minion em todos os nós do minion.

    root@minion > zypper in salt-minion

    Verifique se o nome de domínio completo e qualificado de cada nó pode ser resolvido para o endereço IP da rede pública por todos os outros nós.

  9. Configure todos os minions (incluindo o minion master) para conectar-se ao master. Se o master Salt não puder ser acessado pelo nome de host salt, edite o arquivo /etc/salt/minion ou crie um novo arquivo /etc/salt/minion.d/master.conf com o seguinte conteúdo:

    master: host_name_of_salt_master

    Se você efetuou quaisquer mudanças nos arquivos de configuração mencionados acima, reinicie o serviço Salt em todos os minions Salt:

    root@minion > systemctl restart salt-minion.service
  10. Verifique se o serviço salt-minion está habilitado e foi iniciado em todos os nós. Se necessário, habilite-o e inicie-o:

    root@minion > systemctl enable salt-minion.service
    root@minion > systemctl start salt-minion.service
  11. Verifique a impressão digital de cada minion Salt e aceite todas as chaves do Salt no master Salt se as impressões digitais forem correspondentes.

    Ver a impressão digital de cada minion:

    root@minion > salt-call --local key.finger
    local:
    3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    Após coletar as impressões digitais de todos os minions Salt, liste as impressões digitais de todas as chaves de minion não aceitas no master Salt:

    root@master # salt-key -F
    [...]
    Unaccepted Keys:
    minion1:
    3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    Se houver correspondência de impressões digitais dos minions, aceite-as:

    root@master # salt-key --accept-all
  12. Verifique se as chaves foram aceitas:

    root@master # salt-key --list-all
  13. Antes de implantar o SUSE Enterprise Storage, verifique se todos os discos que foram usados como OSD por clusters anteriores estão vazios, sem partições. Para garantir isso, você precisa limpar (zap) manualmente todos os discos. Lembre-se de substituir “X” pela letra correta do disco:

    1. Pare todos os processos que estão usando o disco específico.

    2. Verifique se alguma partição no disco está montada e, se necessário, desmonte-a.

    3. Se o disco for gerenciado por LVM, desative e apague toda a infraestrutura do LVM. Consulte https://www.suse.com/documentation/sles-12/stor_admin/data/cha_lvm.html para obter mais detalhes.

    4. Se o disco fizer parte do RAID MD, desative o RAID. Consulte https://www.suse.com/documentation/sles-12/stor_admin/data/part_software_raid.html para obter mais detalhes.

    5. Dica
      Dica: Reinicializando o servidor

      Se você receber mensagens de erro, como “partition in use” ou “kernel can not be updated with the new partition table” durante as etapas seguintes, reinicialize o servidor.

      Limpe o começo de cada partição:

      for partition in /dev/sdX[0-9]*
      do
        dd if=/dev/zero of=$partition bs=4096 count=1 oflag=direct
      done
    6. Limpe a tabela de partição:

      sgdisk -Z --clear -g /dev/sdX
    7. Limpe as tabelas de partição de backup:

      size=`blockdev --getsz /dev/sdX`
      position=$((size/4096 - 33))
      dd if=/dev/zero of=/dev/sdX bs=4M count=33 seek=$position oflag=direct
  14. Instale o DeepSea no nó master Salt:

    root@master # zypper in deepsea
  15. Verifique se o arquivo /srv/pillar/ceph/master_minion.sls no master Salt aponta para o seu master Salt. Se o master Salt puder ser acessado por outros nomes de host, use o que for mais adequado ao cluster de armazenamento. Se você usou o nome de host padrão para o seu master Salt (salt) no domínio ses, o arquivo tem esta aparência:

    master_minion: salt.ses

Agora você pode implantar e configurar o Ceph. A menos que especificado de outra forma, todas as etapas são obrigatórias.

Nota
Nota: Convenções do comando salt

Há duas maneiras possíveis de executar salt-run state.orch: uma é com stage.<número da fase>, a outra é com o nome da fase. As duas notações têm o mesmo impacto, e você decide qual comando usar de acordo com a sua preferência.

Procedimento 4.1: Executando as fases de implantação
  1. Inclua os minions Salt pertencentes ao cluster do Ceph que você está implantando atualmente. Consulte a Seção 4.2.2.1, “Correspondendo o nome do minion” para obter mais informações sobre como direcionar os minions.

  2. Prepare o cluster. Consulte a Descrição das fases do DeepSea para obter mais detalhes.

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

    ou

    root@master # salt-run state.orch ceph.stage.prep
    Nota
    Nota: Executar ou monitorar fases usando a CLI do DeepSea

    Ao usar a CLI do DeepSea, você pode acompanhar o andamento da execução da fase em tempo real, seja executando a CLI do DeepSea no modo de monitoramento ou executando a fase diretamente na CLI do DeepSea. Para obter detalhes, consulte a Seção 4.4, “CLI do DeepSea”.

  3. Opcional: crie subvolumes Btrfs para /var/lib/ceph/. Essa etapa apenas deve ser executada antes da execução das próximas fases do DeepSea. Para migrar os diretórios existentes ou para obter mais detalhes, consulte o Seção 18.5, “Subvolume Btrfs para /var/lib/ceph”.

    root@master # salt-run state.orch ceph.migrate.subvolume
  4. A fase de descoberta coleta dados de todos os minions e cria fragmentos de configuração que são armazenados no diretório /srv/pillar/ceph/proposals. Os dados são armazenados no formato YAML em arquivos *.sls ou *.yml.

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

    ou

    root@master # salt-run state.orch ceph.stage.discovery
  5. Após a conclusão bem-sucedida do comando anterior, crie um arquivo policy.cfg em /srv/pillar/ceph/proposals. Para obter detalhes, consulte a Seção 4.5.1, “Arquivo policy.cfg.

    Dica
    Dica

    Se você tiver que mudar a configuração de rede do cluster, edite /srv/pillar/ceph/stack/ceph/cluster.yml e ajuste as linhas que começam com cluster_network: e public_network:.

  6. A fase de configuração analisa o arquivo policy.cfg e funde os arquivos incluídos em seu formato final. O cluster e o conteúdo relacionado à função são armazenados em /srv/pillar/ceph/cluster, enquanto o conteúdo específico do Ceph é armazenado em /srv/pillar/ceph/stack/default.

    Execute o seguinte comando para acionar a fase de configuração:

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

    ou

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

    A etapa de configuração pode levar mais tempo. Após a conclusão do comando, você poderá ver os dados do pillar referentes aos minions especificados (por exemplo, denominados ceph_minion1, ceph_minion2, etc.) executando:

    root@master # salt 'ceph_minion*' pillar.items
    Nota
    Nota: Substituindo padrões

    Logo após a conclusão do comando, você poderá ver a configuração padrão e mudá-la de acordo com as suas necessidades. Para obter detalhes, consulte o Capítulo 7, Personalizando a configuração padrão.

  7. Agora você pode executar a fase de implantação. Nessa fase, o pilar é validado, e os daemons dos monitores e ODS são iniciados nos nós de armazenamento. Execute o seguinte para iniciar a fase:

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

    ou

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

    O comando pode levar algum tempo. Se ele falhar, você precisará corrigir o problema e executar novamente as fases anteriores. Depois que o comando for bem-sucedido, execute o seguinte para verificar o status:

    root@master # ceph -s
  8. A última etapa da implantação do cluster do Ceph é a fase de serviços. Nessa etapa, você instancia qualquer um dos serviços suportados atualmente: iSCSI Gateway, CephFS, Object Gateway, openATTIC e NFS Ganesha. Nessa fase, os pools necessários, os chaveiros de autorização e os serviços de inicialização são criados. Para iniciar a fase, execute o seguinte:

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

    ou

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

    Dependendo da configuração, o comando pode ser executado por muito tempo.

4.4 CLI do DeepSea

O DeepSea também fornece uma ferramenta CLI que permite ao usuário monitorar ou executar as fases enquanto visualiza o andamento da execução em tempo real.

Dois modos são suportados para visualização do andamento da execução de uma fase:

Modos da CLI do DeepSea
  • Modo de monitoramento: visualiza o andamento da execução de uma fase do DeepSea acionada pelo comando salt-run emitido em outra sessão de terminal.

  • Modo independente: executa uma fase do DeepSea enquanto permite a visualização em tempo real das etapas de seus componentes conforme são executadas.

Importante
Importante: Comandos da CLI do DeepSea

Apenas é possível executar os comandos da CLI do DeepSea no nó master Salt, com privilégios de root.

4.4.1 CLI do DeepSea: Modo monitor

O monitor de andamento apresenta uma visualização detalhada em tempo real do que acontece durante a execução das fases usando os comandos salt-run state.orch em outras sessões de terminal.

É necessário iniciar o monitor antes de executar qualquer comando salt-run state.orch para que ele possa detectar o início da execução da fase.

Se você iniciar o monitor após a emissão do comando salt-run state.orch, não será exibido nenhum andamento da execução.

É possível iniciar o modo monitor executando o seguinte comando:

root@master # deepsea monitor

Para obter mais informações sobre as opções de linha de comando disponíveis do deepsea monitor, consulte a página de manual dele:

root@master # man deepsea-monitor

4.4.2 CLI do DeepSea: Modo independente

No modo independente, é possível usar a CLI do DeepSea para executar uma fase dele, mostrando a execução em tempo real.

O comando para executar uma fase do DeepSea pela CLI tem o seguinte formato:

root@master # deepsea stage run stage-name

em que stage-name corresponde ao modo como os arquivos de estado da orquestração do Salt são referenciados. Por exemplo, a fase deploy (implantação), que corresponde ao diretório localizado em /srv/salt/ceph/stage/deploy, é referenciada como ceph.stage.deploy.

Esse comando é uma alternativa aos comandos com base no Salt para execução das fases do DeepSea (ou de qualquer arquivo de estado da orquestração do DeepSea).

O comando deepsea stage run ceph.stage.0 equivale ao salt-run state.orch ceph.stage.0.

Para obter mais informações sobre as opções de linha de comando disponíveis que são aceitas pelo comando deepsea stage run, consulte a página de manual dele:

root@master # man deepsea-stage run

Na figura a seguir, há um exemplo da saída da CLI do DeepSea durante a execução da Fase 2:

Saída do andamento da execução da fase da CLI do DeepSea
Figura 4.1: Saída do andamento da execução da fase da CLI do DeepSea

4.4.2.1 Álias stage run da CLI do DeepSea

Para usuários avançados do Salt, também oferecemos suporte a um álias para execução de uma fase do DeepSea que aplica o comando Salt usado para executar uma fase, por exemplo, salt-run state.orch stage-name, como um comando da CLI do DeepSea.

Exemplo:

root@master # deepsea salt-run state.orch stage-name

4.5 Configuração e personalização

4.5.1 Arquivo policy.cfg

O arquivo de configuração /srv/pillar/ceph/proposals/policy.cfg é usado para determinar as funções dos nós individuais do cluster. Por exemplo, o nó que atua como OSD ou como nó do monitor. Edite o policy.cfg para refletir a configuração desejada do cluster. A ordem das seções é arbitrária, mas o conteúdo das linhas incluídas sobregrava as chaves correspondentes do conteúdo das linhas anteriores.

Dica
Dica: Exemplos de policy.cfg

Você encontra vários exemplos de arquivos de política completos no diretório /usr/share/doc/packages/deepsea/examples/.

4.5.1.1 Atribuição de cluster

Na seção do cluster, selecione os respectivos minions. Você pode selecionar todos os minions ou incluí-los na lista negra ou na lista de permissões. Veja a seguir exemplos para um cluster denominado ceph.

Para incluir todos os minions, adicione as seguintes linhas:

cluster-ceph/cluster/*.sls

Para incluir um minion específico na lista de permissões:

cluster-ceph/cluster/abc.domain.sls

ou um grupo de minions, você pode usar a correspondência de globbing do shell:

cluster-ceph/cluster/mon*.sls

Para incluir minions na lista negra, defina-os como unassigned:

cluster-unassigned/cluster/client*.sls

4.5.1.2 Atribuição de função

Esta seção apresenta detalhes sobre como atribuir “funções” a nós do cluster. Neste contexto, uma “função” significa o serviço que você precisa executar no nó, como Ceph Monitor, Object Gateway, iSCSI Gateway ou openATTIC. Nenhuma função é atribuída automaticamente, apenas as funções adicionadas ao policy.cfg serão implantadas.

A atribuição segue este padrão:

role-ROLE_NAME/PATH/FILES_TO_INCLUDE

Em que os itens têm o significado e os valores a seguir:

  • ROLE_NAME é qualquer um destes valores: “master”, “admin”, “mon”, “mgr”, “mds”, “igw”, “rgw”, “ganesha” ou “openattic”.

  • PATH é um caminho de diretório relativo para os arquivos .sls ou .yml. No caso de arquivos .sls, ele costuma ser cluster, já os arquivos .yml estão localizados em stack/default/ceph/minions.

  • FILES_TO_INCLUDE são os arquivos de estado do Salt ou os arquivos de configuração YAML. Normalmente, eles são compostos por nomes de host de minions Salt. Por exemplo, ses5min2.yml. É possível usar o globbing do shell para correspondência mais específica.

Veja a seguir um exemplo para cada função:

  • master: o nó tem chaveiros de admin para todos os clusters do Ceph. Atualmente, apenas um único cluster do Ceph é suportado. Como a função master é obrigatória, adicione sempre uma linha semelhante ao seguinte:

    role-master/cluster/master*.sls
  • admin: o minion terá um chaveiro de admin. Defina as funções da seguinte forma:

    role-admin/cluster/abc*.sls
  • mon: o minion fornecerá o serviço de monitoramento ao cluster do Ceph. Essa função requer os endereços dos minions atribuídos. Desde o SUSE Enterprise Storage 5, o endereço público é calculado dinamicamente e não é mais necessário no pillar do Salt.

    role-mon/cluster/mon*.sls

    O exemplo atribui a função de monitoramento a um grupo de minions.

  • mgr: o daemon Ceph Manager que coleta todas as informações de estado do cluster inteiro. Implante-o em todos os minions nos quais você pretende implantar a função Ceph Monitor.

    role-mgr/cluster/mgr*.sls
  • mds: o minion fornecerá o serviço de metadados para oferecer suporte ao CephFS.

    role-mds/cluster/mds*.sls
  • igw: o minion atuará como iSCSI Gateway. Essa função requer os endereços dos minions atribuídos, portanto, você também precisa incluir os arquivos do diretório stack:

    role-igw/stack/default/ceph/minions/xyz.domain.yml
    role-igw/cluster/*.sls
  • rgw:: o minion atuará como Object Gateway:

    role-rgw/cluster/rgw*.sls
  • openattic: o minion atuará como servidor openATTIC:

    role-openattic/cluster/openattic*.sls

    Para obter mais informações, consulte Capítulo 15, openATTIC.

  • ganesha: o minion atuará como servidor NFS Ganesha. A função “ganesha” requer uma função “rgw” ou “mds” no cluster; do contrário, haverá falha na validação na Fase 3.

    Para instalar o NFS Ganesha com êxito, é necessária uma configuração adicional. Para usar o NFS Ganesha, leia o Capítulo 12, Instalação do NFS Ganesha antes de executar as fases 2 e 4. No entanto, é possível instalar o NFS Ganesha posteriormente.

    Em alguns casos, ele pode ser útil para definir funções personalizadas para os nós do NFS Ganesha. Para obter os detalhes, consulte o Seção 14.3, “Funções personalizadas do NFS Ganesha”.

Nota
Nota: Várias funções dos nós do cluster

É possível atribuir várias funções a um único nó. Por exemplo, você pode atribuir as funções mds aos nós do monitor:

role-mds/cluster/mon[1,2]*.sls

4.5.1.3 Configuração comum

A seção de configuração comum inclui arquivos de configuração gerados durante a descoberta (fase 1). Esses arquivos de configuração armazenam parâmetros como fsid ou public_network. Para incluir a configuração comum necessária do Ceph, adicione as seguintes linhas:

config/stack/default/global.yml
config/stack/default/ceph/cluster.yml

4.5.1.4 Atribuição de perfil

No Ceph, uma única função de armazenamento não é suficiente para descrever as várias configurações de disco disponíveis com o mesmo hardware. A fase 1 do DeepSea gerará uma proposta de perfil de armazenamento padrão. Por padrão, essa proposta será um perfil bluestore e tentará propor a configuração com o desempenho mais alto para a configuração de hardware especificada. Por exemplo, a preferência será por diários externos do que por um único disco com objetos e metadados. O armazenamento de estado sólido terá prioridade sobre os discos giratórios. Os perfis são atribuídos no policy.cfg similares às funções.

A proposta padrão pode ser encontrada na árvore do diretório padrão do perfil. Para incluir isso, adicione as duas linhas a seguir ao policy.cfg.

profile-default/cluster/*.sls
profile-default/stack/default/ceph/minions/*.yml

Você também pode criar um perfil de armazenamento personalizado de sua preferência usando o executor de proposta. Esse executor oferece três métodos: help, peek e populate.

salt-run proposal.help imprime o texto de ajuda do executor sobre os vários argumentos que ele aceita.

salt-run proposal.peek mostra a proposta gerada de acordo com os argumentos passados.

salt-run proposal.populate grava a proposta no subdiretório /srv/pillar/ceph/proposals. Passe name=myprofile para nomear o perfil de armazenamento. Isso resultará em um subdiretório profile-myprofile.

Para todos os outros argumentos, consulte a saída do salt-run proposal.help.

4.5.1.5 Implantando OSDs criptografados

Desde o SUSE Enterprise Storage 5, por padrão, os OSDs são implantados usando o BlueStore em vez do FileStore. Embora o BlueStore suporte criptografia, os Ceph OSDs são implantados sem criptografia, por padrão. Vamos supor que ambos os discos de dados e WAL/BD que serão usados para implantação do OSD estejam limpos, sem partições. Se os discos já foram usados, limpe-os seguindo o procedimento descrito na Etapa 13.

Para usar OSDs criptografados em sua nova implantação, use o executor proposal.populate com o argumento encryption=dmcrypt:

root@master # salt-run proposal.populate encryption=dmcrypt

4.5.1.6 Filtragem de itens

Nem sempre é prático incluir todos os arquivos de determinado diretório com globbing *.sls. O analisador de arquivos policy.cfg reconhece os seguintes filtros:

Atenção
Atenção: Técnicas avançadas

Esta seção descreve as técnicas de filtragem para os usuários avançados. Quando não usada corretamente, a filtragem pode causar problemas. Por exemplo, em caso de mudança na numeração do nó.

slice=[start:end]

Use o filtro slice para incluir apenas os itens start até end-1. Observe que os itens em determinado diretório são classificados em ordem alfanumérica. A linha a seguir inclui do terceiro ao quinto arquivo do subdiretório role-mon/cluster/:

role-mon/cluster/*.sls slice[3:6]
re=regexp

Use o filtro de expressão regular para incluir apenas os itens correspondentes às expressões inseridas. Por exemplo:

role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$

4.5.1.7 Arquivo policy.cfg de exemplo

Veja a seguir um exemplo de um arquivo policy.cfg básico:

## Cluster Assignment
cluster-ceph/cluster/*.sls 1

## Roles
# ADMIN
role-master/cluster/examplesesadmin.sls 2
role-admin/cluster/sesclient*.sls 3

# MON
role-mon/cluster/ses-example-[123].sls 4

# MGR
role-mgr/cluster/ses-example-[123].sls 5

# MDS
role-mds/cluster/ses-example-4.sls 6

# IGW
role-igw/stack/default/ceph/minions/ses-example-4.yml 7
role-igw/cluster/ses-example-4.sls 8

# RGW
role-rgw/cluster/ses-example-4.sls 9

# openATTIC
role-openattic/cluster/openattic*.sls 10

# COMMON
config/stack/default/global.yml 11
config/stack/default/ceph/cluster.yml 12

## Profiles
profile-default/cluster/*.sls 13
profile-default/stack/default/ceph/minions/*.yml 14

1

Indica que todos os minions estão incluídos no cluster do Ceph. Se você tem minions que não deseja incluir no cluster do Ceph, use:

cluster-unassigned/cluster/*.sls
cluster-ceph/cluster/ses-example-*.sls

A primeira linha marca todos os minions como não atribuídos. A segunda linha anula os minions correspondentes a “ses-example-*.sls” e os atribui ao cluster do Ceph.

2

O minion chamado “examplesesadmin” tem a função “master”. A propósito, isso significa que ele enviará chaves de admin ao cluster.

3

Todos os minions correspondentes a “sesclient*” também receberão chaves de admin.

4

Todos os minions correspondentes a “ses-example-[123]” (teoricamente três minions: ses-example-1, ses-example-2 e ses-example-3) serão configurados como nós MON.

5

Todos os minions correspondentes a “ses-example-[123]” (todos os nós MON no exemplo) serão configurados como nós MGR.

6

O minion “ses-example-4” terá a função MDS.

7

Verifique se o DeepSea sabe o endereço IP do nó IGW.

8

O minion “ses-example-4” terá a função IGW.

9

O minion “ses-example-4” terá a função RGW.

10

Especifica para implantar a interface do usuário do openATTIC para administrar o cluster do Ceph. Consulte a Capítulo 15, openATTIC para obter mais detalhes.

11

Significa que aceitamos os valores padrão para os parâmetros de configuração comum, como fsid e public_network.

12

Significa que aceitamos os valores padrão para os parâmetros de configuração comum, como fsid e public_network.

13

Informamos ao DeepSea para usar o perfil de hardware padrão para cada minion. A escolha do perfil de hardware padrão significa que todos os discos adicionais (exceto o disco raiz) devem ser OSDs.

14

Informamos ao DeepSea para usar o perfil de hardware padrão para cada minion. A escolha do perfil de hardware padrão significa que todos os discos adicionais (exceto o disco raiz) devem ser OSDs.

4.5.2 Arquivo ceph.conf personalizado

Se você precisar incluir as configurações personalizadas no arquivo de configuração ceph.conf, consulte o Seção 1.11, “Arquivo ceph.conf personalizado” para obter mais detalhes.

Imprimir esta página