Implantando com o DeepSea/Salt | Guia de Implantação

documentation.suse.com › Documentação do SUSE Enterprise Storage 6 › Guia de Implantação › Implantação e upgrade do cluster › Implantando com o DeepSea/Salt

ConteúdoConteúdo

Guia de Implantação

Navegação←→

Aplica-se a SUSE Enterprise Storage 6

5 Implantando com o DeepSea/Salt #

5.1 Ler os detalhes da versão
5.2 Introdução ao DeepSea
5.3 Implantação do cluster
5.4 CLI do DeepSea
5.5 Configuração e personalização

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: 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 problema de desempenho e de procedimento de upgrade, não implante a função Ceph OSD, Servidor de Metadados ou Ceph Monitor no Nó de Admin.
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 5.3, “Implantação do cluster”.

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

5.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: Executar a Fase 0 Novamente após a Reinicialização do Nó de Admin
Se o Nó de Admin for reinicializado durante a fase 0 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: a descoberta: nessa fase, o hardware inteiro no cluster é detectado e as informações necessárias para a configuração do Ceph são coletadas. Para obter detalhes sobre a configuração, consulte a Seção 5.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 2.3, “Removendo e reinstalando nós do cluster”.

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

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

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

5.2.2.2 Direcionando com um grain do DeepSea #

Em um ambiente heterogêneo gerenciado pelo Salt, em que o SUSE Enterprise Storage 6 é implantado em um subconjunto de nós juntamente com outras soluções de cluster, você precisa marcar os minions relevantes aplicando um grain "deepsea" a eles antes de executar a fase 0 do DeepSea. Dessa forma, você pode direcionar facilmente os minions do DeepSea nos ambientes em que a correspondência por nome do 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

5.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: 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 do DeepSea.

Corresponder todos os minions Salt no cluster:

deepsea_minions: '*'

Corresponder todos os minions com o grain “deepsea”:

deepsea_minions: 'G@deepsea:*'

5.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. A página de manual do “deepsea-minions” apresenta mais detalhes sobre direcionamento do DeepSea (man 7 deepsea_minions).

5.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: Implantando nós do monitor sem definir perfis de OSD

Se você precisa ignorar a definição de funções de armazenamento para o OSD, conforme descrito na Seção 5.5.1.2, “Atribuição de função”, e implantar primeiro os nós do Ceph Monitor, defina a variável DEV_ENV.

Isso permite implantar monitores sem a presença do diretório role-storage/ e implantar um cluster do Ceph com pelo menos uma função 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

Como exemplo, é possível criar o /srv/pillar/ceph/stack/global.yml com o seguinte conteúdo:

DEV_ENV: True

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

Instale e registre o SUSE Linux Enterprise Server 15 SP1 juntamente com a extensão do SUSE Enterprise Storage 6 em cada nó do cluster.

Verifique se os produtos apropriados estão instalados e foram registrados listando os repositórios de software existentes. Execute zypper lr -E e compare a saída com a seguinte lista:

 SLE-Product-SLES15-SP1-Pool
 SLE-Product-SLES15-SP1-Updates
 SLE-Module-Server-Applications15-SP1-Pool
 SLE-Module-Server-Applications15-SP1-Updates
 SLE-Module-Basesystem15-SP1-Pool
 SLE-Module-Basesystem15-SP1-Updates
 SUSE-Enterprise-Storage-6-Pool
 SUSE-Enterprise-Storage-6-Updates

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-15/book_sle_admin/data/sec_network_yast.html. Para obter mais informações sobre como configurar um servidor DNS, consulte https://www.suse.com/documentation/sles-15/book_sle_admin/data/cha_dns.html.
Selecione um ou mais servidores de horário/pools e sincronize o horário local com eles. Verifique se o serviço de sincronização de horário está habilitado em cada inicialização do sistema. É possível usar o comando yast ntp-client incluído em um pacote yast2-ntp-client para configurar a sincronização de horário.
Dica
As máquinas virtuais não são fontes confiáveis de NTP.
Encontre mais informações sobre como configurar o NTP em https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html.
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
```
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: 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 # systemctl stop firewalld.service
```
ou definir a opção FAIL_ON_WARNING como “False” em /srv/pillar/ceph/stack/global.yml:
```
FAIL_ON_WARNING: False
```
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.
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
```
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 # systemctl enable salt-minion.service
root # systemctl start salt-minion.service
```
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.
Nota
Se a impressão digital do minion Salt retornar vazia, verifique se o minion Salt tem uma configuração do master Salt e pode se comunicar com o master Salt.
Ver a impressão digital de cada minion:
```
root@master # 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
```
Verifique se as chaves foram aceitas:
```
root@master # salt-key --list-all
```
Antes de implantar o SUSE Enterprise Storage 6, limpe (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-15/book_storage/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-15/book_storage/data/part_software_raid.html para obter mais detalhes.
5. Dica: Reinicializando o servidor
  Se você receber mensagens de erro, como “partition in use” ou “kernel cannot be updated with the new partition table” durante as etapas seguintes, reinicialize o servidor.
  Limpe o começo de cada partição (como root):
```
for partition in /dev/sdX[0-9]*
do
  dd if=/dev/zero of=$partition bs=4096 count=1 oflag=direct
done
```
6. Limpe o começo da unidade:
```
root # dd if=/dev/zero of=/dev/sdX bs=512 count=34 oflag=direct
```
7. Limpe o fim da unidade:
```
root # dd if=/dev/zero of=/dev/sdX bs=512 count=33 \
  seek=$((`blockdev --getsz /dev/sdX` - 33)) oflag=direct
```
8. Verifique se a unidade está vazia (sem estruturas de GPT) usando:
```
root # parted -s /dev/sdX print free
```
  ou
```
root # dd if=/dev/sdX bs=512 count=34 | hexdump -C
root # dd if=/dev/sdX bs=512 count=33 \
  skip=$((`blockdev --getsz /dev/sdX` - 33)) | hexdump -C
```
Opcionalmente, se você precisar predefinir as configurações de rede do cluster antes da instalação do pacote deepsea , crie /srv/pillar/ceph/stack/ceph/cluster.yml manualmente e defina as opções cluster_network: e public_network:. Observe que o arquivo não será sobregravado após a instalação do deepsea.
Dica: Habilitação do IPv6
Se você precisar habilitar endereçamento de rede IPv6, consulte a Seção 7.2.1, “Habilitando o IPv6 para implantação de cluster do Ceph”
Instale o DeepSea no nó master Salt:
```
root@master # zypper in deepsea
```
O valor do parâmetro master_minion é derivado dinamicamente do arquivo /etc/salt/minion_id no master Salt. Se você precisar anular o valor descoberto, edite o arquivo /srv/pillar/ceph/stack/global.yml e defina um valor relevante:
```
master_minion: MASTER_MINION_NAME
```
Se o master Salt for acessível por mais nomes de host, use o nome do minion Salt para o cluster de armazenamento, conforme retornado pelo comando salt-key -L. 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: Convenções do comando salt

Há duas maneiras possíveis de executar salt-run state.orch: uma é com “stage.STAGE_NUMBER”, 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 5.1: Executando as fases de implantação #

Verifique se os minions Salt que pertencem ao cluster do Ceph estão corretamente direcionados com a opção deepsea_minions em /srv/pillar/ceph/deepsea_minions.sls. Consulte a Seção 5.2.2.3, “Definir a opção deepsea_minions” para obter mais informações.
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 implantar sem os perfis ajustados. Para fazer isso, insira as seguintes linhas no /srv/pillar/ceph/stack/global.yml antes de executar as fases do DeepSea:
```
alternative_defaults:
 tuned_mgr_init: default-off
 tuned_mon_init: default-off
 tuned_osd_init: default-off
```
Opcional: crie subvolumes Btrfs para /var/lib/ceph/. Esta etapa precisa ser executada antes da fase 0 do DeepSea. Para migrar os diretórios existentes ou obter mais detalhes, consulte o Seção 25.6, “Subvolume Btrfs para /var/lib/ceph em nós do Ceph Monitor”.
Aplique os seguintes comandos a cada um dos minions Salt:
```
root@master # salt 'MONITOR_NODES' saltutil.sync_all
root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume
```
Nota
O comando Ceph.subvolume cria /var/lib/ceph como um subvolume Btrfs @/var/lib/ceph.
Agora, o novo subvolume está montado e /etc/fstab está atualizado.
Prepare o cluster. Consulte 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: 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 5.4, “CLI do DeepSea”.
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.
Execute o seguinte comando para acionar a fase de descoberta:
```
root@master # salt-run state.orch ceph.stage.1
```
ou
```
root@master # salt-run state.orch ceph.stage.discovery
```
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 5.5.1, “Arquivo policy.cfg”.
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:.
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
```
Dica: Modificação do Layout do OSD
Para modificar o layout do OSD padrão e mudar a configuração dos grupos de unidades, siga o procedimento descrito na Seção 5.5.2, “DriveGroups”.
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.
Agora você pode executar a fase de implantação. Nesta fase, o pillar é validado, e os daemons Ceph Monitor e Ceph OSD são iniciados:
```
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:
```
cephadm@adm > ceph -s
```
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, 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.
Antes de continuar, recomendamos enfaticamente habilitar o módulo de telemetria do Ceph. Para obter mais informações e instruções, consulte o Seção 10.2, “Módulo de telemetria”.

5.4 CLI do DeepSea #

O DeepSea também fornece uma ferramenta de interface de linha de comando (CLI, command line interface) que permite ao usuário monitorar ou executar as fases enquanto visualiza o andamento da execução em tempo real. Verifique se o pacote deepsea-cli está instalado antes de clicar no executável deepsea.

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: Comandos da CLI do DeepSea

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

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

Dica: Iniciar o Monitor em uma Nova Sessão do Terminal

É necessário iniciar o monitor em uma nova janela do terminal antes de executar qualquer salt-run state.orch para que o monitor 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

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

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

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

5.5 Configuração e personalização #

5.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, quais nós atuam como Ceph OSDs ou Ceph Monitors. 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: Exemplos de `policy.cfg`

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

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

5.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, ou iSCSI Gateway. 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”, “storage”, “mds”, “igw”, “rgw”, “ganesha”, “grafana” ou “prometheus”.
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 de 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 monitor ao cluster do Ceph. Essa função requer os endereços dos minions atribuídos. A partir do SUSE Enterprise Storage 5, os endereços públicos são calculados dinamicamente e não são mais necessários no pillar do Salt.
```
role-mon/cluster/mon*.sls
```
O exemplo atribui a função de monitor 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
```
storage: use essa função para especificar nós de armazenamento.
```
role-storage/cluster/data*.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/cluster/*.sls
```
rgw:: o minion atuará como Object Gateway:
```
role-rgw/cluster/rgw*.sls
```
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.
```
role-ganesha/cluster/ganesha*.sls
```
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 21.3, “Funções personalizadas do NFS Ganesha”.
grafana, prometheus: esse nó adiciona gráficos do Grafana com base nos alertas do Prometheus ao Ceph Dashboard. Consulte o Capítulo 22, Ceph Dashboard para ver a descrição detalhada.
```
role-grafana/cluster/grafana*.sls
```
```
role-prometheus/cluster/prometheus*.sls
```

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

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

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

5.5.1.5 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

# STORAGE
role-storage/cluster/ses-example-[5,6,7,8].sls 6

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

# IGW
role-igw/cluster/ses-example-4.sls 8

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

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

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	Todos os minions correspondentes a “ses-example-[5,6,7,8]” serão configurados como nós de armazenamento.
7	O minion “ses-example-4” terá a função MDS.
8	O minion “ses-example-4” terá a função IGW.
9	O minion “ses-example-4” terá a função RGW.
10	Significa que aceitamos os valores padrão para os parâmetros de configuração comum, como `fsid` e `public_network`.
11	Significa que aceitamos os valores padrão para os parâmetros de configuração comum, como `fsid` e `public_network`.

5.5.2 DriveGroups #

Os DriveGroups especificam os layouts dos OSDs no cluster do Ceph. Eles são definidos em um único arquivo /srv/salt/ceph/configuration/files/drive_groups.yml.

Um administrador deve especificar manualmente um grupo de OSDs que estão interligados (OSDs híbridos implantados em estado sólido e spinners) ou compartilhar as mesmas opções de implantação (idênticas, por exemplo, mesmo armazenamento de objetos, mesma opção de criptografia, OSDs independentes). Para evitar a listagem explícita de dispositivos, os DriveGroups usam uma lista de itens de filtro que correspondem a poucos campos selecionados dos relatórios de inventário do ceph-volume. No caso mais simples, isso pode ser o flag “rotacional” (todas as unidades de estado sólido devem ser dispositivos db_devices, todas as unidades rotacionais devem ser dispositivos de dados) ou algo mais presente, como strings “modelo”ou tamanhos. O DeepSea fornecerá o código que converte esses DriveGroups em listas reais de dispositivos para inspeção pelo usuário.

Veja a seguir um procedimento simples que demonstra o workflow básico ao configurar DriveGroups:

Inspecione as propriedades dos discos conforme apresentado pelo comando ceph-volume. Apenas essas propriedades são aceitas pelos DriveGroups:
```
root@master # salt-run disks.details
```
Abra o arquivo YAML /srv/salt/ceph/configuration/files/drive_groups.yml e ajuste-o conforme suas necessidades. Consulte a Seção 5.5.2.1, “Especificação”. Lembre-se de usar espaços em vez de tabulações. Há exemplos mais avançados na Seção 5.5.2.4, “Exemplos”. O exemplo a seguir inclui todas as unidades disponíveis para o Ceph como OSDs:
```
default_drive_group_name:
  target: '*'
  data_devices:
    all: true
```
Verifique os novos layouts:
```
root@master # salt-run disks.list
```
Este executor retorna uma estrutura de discos correspondentes com base em seus grupos de unidades. Se você não ficar satisfeito com o resultado, repita a etapa anterior.
Dica: Relatório Detalhado
Além do executor disks.list, há um executor disks.report que imprime um relatório detalhado do que acontecerá ao invocar a fase 3 seguinte do DeepSea.
```
root@master # salt-run disks.report
```
Implante os OSDs. Na invocação da fase 3 seguinte do DeepSea, os discos OSD serão implantados de acordo com a especificação do grupo de unidades.

5.5.2.1 Especificação #

/srv/salt/ceph/configuration/files/drive_groups.yml aceita as seguintes opções:

drive_group_default_name:
  target: *
  data_devices:
    drive_spec: DEVICE_SPECIFICATION
  db_devices:
    drive_spec: DEVICE_SPECIFICATION
  wal_devices:
    drive_spec: DEVICE_SPECIFICATION
  block_wal_size: '5G'  # (optional, unit suffixes permitted)
  block_db_size: '5G'   # (optional, unit suffixes permitted)
  osds_per_device: 1   # number of osd daemons per device
  format:              # 'bluestore' or 'filestore' (defaults to 'bluestore')
  encryption:           # 'True' or 'False' (defaults to 'False')

Para configurações do FileStore, o drive_groups.yml pode ser da seguinte maneira:

drive_group_default_name:
  target: *
  data_devices:
    drive_spec: DEVICE_SPECIFICATION
  journal_devices:
    drive_spec: DEVICE_SPECIFICATION
  format: filestore
  encryption: True

5.5.2.2 Correspondendo dispositivos de disco #

Você pode descrever a especificação usando os seguintes filtros:

Por um modelo de disco:
```
model: DISK_MODEL_STRING
```
Por um fornecedor de disco:
```
vendor: DISK_VENDOR_STRING
```
Dica: String de Fornecedor em Letras Minúsculas
Sempre insira DISK_VENDOR_STRING em letras minúsculas.
Se um disco é ou não rotacional. SSDs e unidades NVME não são rotacionais.
```
rotational: 0
```
Implante um nó usando todas as unidades disponíveis para OSDs:
```
data_devices:
  all: true
```
Limite também o número de discos correspondentes:
```
limit: 10
```

5.5.2.3 Filtrando dispositivos por tamanho #

Você pode filtrar dispositivos de disco por tamanho, seja por um tamanho exato ou por uma faixa de tamanhos. O parâmetro size: aceita argumentos no seguinte formato:

“10G”: Inclui discos de um tamanho exato.
“10G:40G”: Inclui discos cujo tamanho está dentro da faixa.
“:10G”: Inclui discos menores do que ou iguais a 10 GB.
“40G:”: Inclui discos iguais ou maiores do que 40 GB.

Exemplo 5.1: Correspondência por Tamanho do Disco #

drive_group_default:
  target: '*'
  data_devices:
    size: '40TB:'
  db_devices:
    size: ':2TB'

Nota: Aspas Obrigatórias

Ao usar o delimitador “:”, você precisa colocar o tamanho entre aspas; do contrário, o sinal “:” será interpretado como um novo hash de configuração.

Dica: Atalhos de Unidade

Em vez de (G)igabytes, você também pode especificar os tamanhos em (M)egabytes ou (T)erabytes.

5.5.2.4 Exemplos #

Esta seção inclui exemplos de configurações de OSD diferentes.

Exemplo 5.2: Configuração Simples #

Este exemplo descreve dois nós com a mesma configuração:

20 HDDs
- Fornecedor: Intel
- Modelo: SSD-123-foo
- Tamanho: 4 TB
2 SSDs
- Fornecedor: Micron
- Modelo: MC-55-44-ZX
- Tamanho: 512 GB

O arquivo drive_groups.yml correspondente será da seguinte maneira:

drive_group_default:
  target: '*'
  data_devices:
    model: SSD-123-foo
  db_devices:
    model: MC-55-44-XZ

Essa configuração é simples e válida. O problema é que um administrador pode adicionar discos de diferentes fornecedores no futuro, e eles não serão incluídos. Você pode melhorá-la reduzindo os filtros nas propriedades de núcleo das unidades:

drive_group_default:
  target: '*'
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0

No exemplo anterior, impomos todos os dispositivos rotacionais que serão declarados como "dispositivos de dados", e todos os dispositivos não rotacionais serão usados como "dispositivos compartilhados" (wal, db).

Se você sabe que as unidades com mais de 2 TB sempre serão os dispositivos de dados mais lentos, pode filtrar por tamanho:

drive_group_default:
  target: '*'
  data_devices:
    size: '2TB:'
  db_devices:
    size: ':2TB'

Exemplo 5.3: Configuração avançada #

Este exemplo descreve duas configurações distintas: 20 HDDs devem compartilhar 2 SSDs, enquanto 10 SSDs devem compartilhar 2 NVMes.

20 HDDs
- Fornecedor: Intel
- Modelo: SSD-123-foo
- Tamanho: 4 TB
12 SSDs
- Fornecedor: Micron
- Modelo: MC-55-44-ZX
- Tamanho: 512 GB
2 NVMes
- Fornecedor: Samsung
- Modelo: NVME-QQQQ-987
- Tamanho: 256 GB

Essa configuração pode ser definida com dois layouts da seguinte maneira:

drive_group:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: MC-55-44-XZ

drive_group_default:
  target: '*'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    vendor: samsung
    size: 256GB

Exemplo 5.4: Configuração Avançada com Nós Não Uniformes #

Os exemplos anteriores consideraram que todos os nós tinham as mesmas unidades. No entanto, esse nem sempre é o caso:

Nós 1-5:

20 HDDs
- Fornecedor: Intel
- Modelo: SSD-123-foo
- Tamanho: 4 TB
2 SSDs
- Fornecedor: Micron
- Modelo: MC-55-44-ZX
- Tamanho: 512 GB

Nós 6-10:

5 NVMes
- Fornecedor: Intel
- Modelo: SSD-123-foo
- Tamanho: 4 TB
20 SSDs
- Fornecedor: Micron
- Modelo: MC-55-44-ZX
- Tamanho: 512 GB

Você pode usar a chave de “destino” no layout para direcionar nós específicos. A notação de destino do Salt ajuda a simplificar as coisas:

drive_group_node_one_to_five:
  target: 'node[1-5]'
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0

seguido de

drive_group_the_rest:
  target: 'node[6-10]'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    model: SSD-123-foo

Exemplo 5.5: Configuração Técnica #

Todos os casos anteriores consideraram que os WALs e BDs usavam o mesmo dispositivo. No entanto, também é possível implantar o WAL em um dispositivo dedicado:

20 HDDs
- Fornecedor: Intel
- Modelo: SSD-123-foo
- Tamanho: 4 TB
2 SSDs
- Fornecedor: Micron
- Modelo: MC-55-44-ZX
- Tamanho: 512 GB
2 NVMes
- Fornecedor: Samsung
- Modelo: NVME-QQQQ-987
- Tamanho: 256 GB

drive_group_default:
  target: '*'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    model: SSD-123-foo
  wal_devices:
    model: NVME-QQQQ-987

Exemplo 5.6: Configuração Complexa (e Improvável) #

Na configuração a seguir, tentamos definir:

20 HDDs com 1 NVMe
2 HDDs com 1 SSD(db) e 1 NVMe(wal)
8 SSDs com 1 NVMe
2 SSDs independentes (criptografados)
1 HDD é sobressalente e não deve ser implantado

Veja a seguir o resumo das unidades usadas:

23 HDDs
- Fornecedor: Intel
- Modelo: SSD-123-foo
- Tamanho: 4 TB
10 SSDs
- Fornecedor: Micron
- Modelo: MC-55-44-ZX
- Tamanho: 512 GB
1 NVMe
- Fornecedor: Samsung
- Modelo: NVME-QQQQ-987
- Tamanho: 256 GB

A definição dos DriveGroups será a seguinte:

drive_group_hdd_nvme:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: NVME-QQQQ-987

drive_group_hdd_ssd_nvme:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: MC-55-44-XZ
  wal_devices:
    model: NVME-QQQQ-987

drive_group_ssd_nvme:
  target: '*'
  data_devices:
    model: SSD-123-foo
  db_devices:
    model: NVME-QQQQ-987

drive_group_ssd_standalone_encrypted:
  target: '*'
  data_devices:
    model: SSD-123-foo
  encryption: True

Um HDD permanecerá enquanto o arquivo está sendo analisado de cima para baixo.

5.5.3 Ajustando o `ceph.conf` com configurações personalizadas #

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

Imprimir esta página