Aplica-se a SUSE Enterprise Storage 7

5 Implantação com cephadm #

O SUSE Enterprise Storage 7 usa a ferramenta ceph-salt baseada em Salt para preparar o sistema operacional em cada nó do cluster participante para implantação com o cephadm. O cephadm implanta e gerencia um cluster do Ceph conectando-se aos hosts do daemon do Ceph Manager por SSH. O cephadm gerencia o ciclo de vida completo de um cluster do Ceph. Ele começa inicializando um cluster bem pequeno em um único nó (um serviço MON e MGR) e, em seguida, usa a interface de orquestração para expandir o cluster para incluir todos os hosts e provisionar todos os serviços do Ceph. Você pode fazer isso pela interface de linha de comando (CLI, Command Line Interface) do Ceph ou parcialmente pelo Ceph Dashboard (GUI).

Importante

Observe que a documentação da comunidade do Ceph usa o comando cephadm bootstrap durante a implantação inicial. O ceph-salt chama o comando cephadm bootstrap e não deve ser executado diretamente. Qualquer implantação manual de cluster do Ceph que use o cephadm bootstrap não será suportada.

Para implantar um cluster do Ceph usando o cephadm, você precisa concluir as seguintes tarefas:

Instale e faça a configuração básica do sistema operacional subjacente, SUSE Linux Enterprise Server 15 SP2, em todos os nós do cluster.
Implante a infraestrutura do Salt em todos os nós do cluster para executar as preparações iniciais de implantação por meio do ceph-salt.
Configure as propriedades básicas do cluster por meio do ceph-salt e implante-o.
Adicione novos nós e funções ao cluster e implante serviços neles usando o cephadm.

5.1 Instalando e configurando o SUSE Linux Enterprise Server #

Instale e registre o SUSE Linux Enterprise Server 15 SP2 em cada nó do cluster. Durante a instalação do SUSE Enterprise Storage, é necessário ter acesso aos repositórios de atualização, portanto, o registro é obrigatório. Inclua pelo menos os seguintes módulos:
- Basesystem Module
- Server Applications Module
Encontre mais detalhes sobre como instalar o SUSE Linux Enterprise Server em https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-install.html.
Instale a extensão do SUSE Enterprise Storage 7 em cada nó do cluster.
Dica: Instalar o SUSE Enterprise Storage junto com o SUSE Linux Enterprise Server
Você poderá instalar a extensão do SUSE Enterprise Storage 7 separadamente após instalar o SUSE Linux Enterprise Server 15 SP2 ou adicioná-la durante o procedimento de instalação do SUSE Linux Enterprise Server 15 SP2.
Encontre mais detalhes sobre como instalar extensões em https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-register-sle.html.
Defina as configurações de rede incluindo a resolução de nome DNS em cada nó. Para obter mais informações sobre como configurar uma rede, consulte https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-yast. Para obter mais informações sobre como configurar um servidor DNS, consulte https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-dns.html.

5.2 Implantando o Salt #

O SUSE Enterprise Storage usa o Salt e o ceph-salt para a preparação inicial do cluster. O Salt ajuda você a configurar e executar comandos em vários nós do cluster simultaneamente, de um host dedicado chamado Master Salt. Antes de implantar o Salt, considere os seguintes pontos importantes:

Os Minions Salt são os nós controlados por um nó dedicado denominado Master Salt.
Se o host Master Salt fizer parte do cluster do Ceph, ele precisará executar seu próprio Minion Salt, mas isso não é um requisito.
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.

Instale o salt-master no nó do Master Salt:
```
root@master # zypper in salt-master
```
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 o firewall, verifique se o nó do 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 salt-master para a zona apropriada. Por exemplo, public.
Instale o pacote salt-minion em todos os nós do minion.
```
root@minion > zypper in salt-minion
```
Edite o /etc/salt/minion e remova o comentário da seguinte linha:
```
#log_level_logfile: warning
```
Mude o nível de registro de warning para info.
Nota: log_level_logfile e log_level
log_level controla quais mensagens de registro serão exibidas na tela, e log_level_logfile controla quais mensagens de registro serão gravadas no /var/log/salt/minion.
Nota
Verifique se você mudou o nível de registro em todos os nós do cluster (minion).
Verifique se o nome de domínio completo e qualificado de cada nó pode ser resolvido para um endereço IP na rede pública do cluster por todos os outros nós.
Configure todos os minions para se conectarem 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 relacionados:
```
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@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
```
Verifique se as chaves foram aceitas:
```
root@master # salt-key --list-all
```
Faça o teste para verificar se todos os Minions Salt respondem:
```
root@master # salt-run manage.status
```

5.3 Implantando o cluster do Ceph #

Esta seção orienta você pelo processo de implantação de um cluster básico do Ceph. Leia as subseções a seguir com atenção e execute os comandos incluídos na ordem indicada.

5.3.1 Instalando o `ceph-salt` #

O ceph-salt inclui ferramentas para implantar clusters do Ceph gerenciados pelo cephadm. O ceph-salt usa a infraestrutura do Salt para executar o gerenciamento de OS; por exemplo, atualizações de software ou sincronização de horário, e definir funções para os Minions Salt.

No Master Salt, instale o pacote ceph-salt :

root@master # zypper install ceph-salt

O comando acima instalou o ceph-salt-formula como uma dependência que modificou a configuração do Master Salt inserindo arquivos adicionais no diretório /etc/salt/master.d. Para aplicar as mudanças, reinicie o salt-master.service e sincronize os módulos do Salt:

root@master # systemctl restart salt-master.service
root@master # salt \* saltutil.sync_all

5.3.2 Configurando as propriedades do cluster #

Use o comando ceph-salt config para configurar as propriedades básicas do cluster.

Importante

O arquivo /etc/ceph/ceph.conf é gerenciado pelo cephadm e os usuários não devem editá-lo. Os parâmetros de configuração do Ceph devem ser definidos usando o novo comando ceph config. Consulte o Seção 28.2, “Banco de dados de configuração” para obter mais informações.

5.3.2.1 Usando o shell do `ceph-salt` #

Se você executar o ceph-salt config sem nenhum caminho ou subcomando, digitará um shell interativo do ceph-salt. O shell é prático se você precisa configurar várias propriedades em um lote e não deseja digitar a sintaxe completa do comando.

root@master # ceph-salt config
/> ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [no minions]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [no minions]
  |   o- bootstrap ........................................... [no minion]
  |   o- cephadm ............................................ [no minions]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path .................................. [ no image path]
  | o- dashboard ................................................... [...]
  | | o- force_password_update ................................. [enabled]
  | | o- password ................................................ [admin]
  | | o- ssl_certificate ....................................... [not set]
  | | o- ssl_certificate_key ................................... [not set]
  | | o- username ................................................ [admin]
  | o- mon_ip .................................................. [not set]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh ............................................... [no key pair set]
  | o- private_key .................................. [no private key set]
  | o- public_key .................................... [no public key set]
  o- time_server ........................... [enabled, no server host set]
    o- external_servers .......................................... [empty]
    o- servers ................................................... [empty]
    o- subnet .................................................. [not set]

Como você pode ver na saída do comando ls do ceph-salt, a configuração do cluster está organizada em uma estrutura de árvore. Para configurar uma propriedade específica do cluster no shell do ceph-salt, você tem duas opções:

Execute o comando a partir da posição atual e digite o caminho absoluto para a propriedade como o primeiro argumento:

/> /cephadm_bootstrap/dashboard ls
o- dashboard ....................................................... [...]
  o- force_password_update ..................................... [enabled]
  o- password .................................................... [admin]
  o- ssl_certificate ........................................... [not set]
  o- ssl_certificate_key ....................................... [not set]
  o- username .................................................... [admin]
/> /cephadm_bootstrap/dashboard/username set ceph-admin
Value set.

Mude para o caminho com a propriedade que você precisa configurar e execute o comando:

/> cd /cephadm_bootstrap/dashboard/
/ceph_cluster/minions> ls
o- dashboard ....................................................... [...]
  o- force_password_update ..................................... [enabled]
  o- password .................................................... [admin]
  o- ssl_certificate ........................................... [not set]
  o- ssl_certificate_key ....................................... [not set]
  o- username ................................................[ceph-admin]

Dica: Preenchimento automático de trechos da configuração

Enquanto estiver em um shell do ceph-salt, você poderá usar o recurso de preenchimento automático semelhante ao do shell normal do Linux (Bash). Ele preenche os caminhos de configuração, subcomandos ou nomes de Minion Salt. Ao preencher automaticamente um caminho de configuração, você tem duas opções:

Para permitir que o shell termine um caminho relativo à sua posição atual, pressione a tecla TAB →| duas vezes.
Para permitir que o shell termine um caminho absoluto, digite / e pressione a tecla TAB →| duas vezes.

Dica: Navegando com as teclas do cursor

Se você digitar cd no shell do ceph-salt sem nenhum caminho, o comando imprimirá uma estrutura de árvore da configuração do cluster com a linha do caminho atual ativo. Você pode usar as teclas do cursor para cima e para baixo para navegar pelas linhas individuais. Depois de confirmar com Enter, o caminho de configuração mudará para o último caminho ativo.

Importante: convenção

Para manter a documentação consistente, usaremos uma única sintaxe de comando sem inserir o shell do ceph-salt. Por exemplo, você pode listar a árvore de configuração do cluster usando o seguinte comando:

root@master # ceph-salt config ls

5.3.2.2 Adicionando minions Salt #

Inclua todos ou um subconjunto de Minions Salt que implantamos e aceitamos na Seção 5.2, “Implantando o Salt” na configuração do cluster do Ceph. Você pode especificar os Minions Salt usando os nomes completos ou as expressões glob "*" e "?" para incluir vários Minions Salt de uma vez. Use o subcomando add no caminho /ceph_cluster/minions. O seguinte comando inclui todos os Minions Salt aceitos:

root@master # ceph-salt config /ceph_cluster/minions add '*'

Verifique se os Minions Salt especificados foram adicionados:

root@master # ceph-salt config /ceph_cluster/minions ls
o- minions ................................................. [Minions: 5]
  o- ses-master.example.com .................................. [no roles]
  o- ses-min1.example.com .................................... [no roles]
  o- ses-min2.example.com .................................... [no roles]
  o- ses-min3.example.com .................................... [no roles]
  o- ses-min4.example.com .................................... [no roles]

5.3.2.3 Especificando minions Salt gerenciados pelo cephadm #

Especifique os nós que pertencerão ao cluster do Ceph e serão gerenciados pelo cephadm. Inclua todos os nós que executarão os serviços do Ceph e também o Nó de Admin:

root@master # ceph-salt config /ceph_cluster/roles/cephadm add '*'

5.3.2.4 Especificando o nó de admin #

O Nó de Admin é o nó em que o arquivo de configuração ceph.conf e o chaveiro admin do Ceph estão instalados. Geralmente, você executa os comandos relacionados ao Ceph no Nó de Admin.

Dica: Master Salt e nó de admin no mesmo nó

Em um ambiente homogêneo onde todos ou a maioria dos hosts pertencem ao SUSE Enterprise Storage, recomendamos manter o Nó de Admin no mesmo host que o Master Salt.

Em um ambiente heterogêneo onde uma infraestrutura do Salt hospeda mais de um cluster, por exemplo, o SUSE Enterprise Storage junto com o SUSE Manager, não coloque o Nó de Admin no mesmo host que o Master Salt.

Para especificar o Nó de Admin, execute o seguinte comando:

root@master # ceph-salt config /ceph_cluster/roles/admin add ses-master.example.com
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/admin ls
o- admin ................................................... [Minions: 1]
  o- ses-master.example.com ...................... [Other roles: cephadm]

Dica: Instalar o ceph.conf e o chaveiro admin em vários nós

Você pode instalar o arquivo de configuração do Ceph e o chaveiro admin em vários nós, se sua implantação exigir isso. Por motivos de segurança, evite instalá-los em todos os nós do cluster.

5.3.2.5 Especificando o primeiro nó MON/MGR #

Você precisa especificar qual dos Minions Salt do cluster inicializará o cluster. Esse minion será o primeiro a executar os serviços Ceph Monitor e Ceph Manager.

root@master # ceph-salt config /ceph_cluster/roles/bootstrap set ses-min1.example.com
Value set.
root@master # ceph-salt config /ceph_cluster/roles/bootstrap ls
o- bootstrap ..................................... [ses-min1.example.com]

Além disso, você precisa especificar o endereço IP do MON de boot na rede pública para garantir que o parâmetro public_network seja definido corretamente, por exemplo:

root@master # ceph-salt config /cephadm_bootstrap/mon_ip set 192.168.10.20

5.3.2.6 Especificando perfis ajustados #

Você precisa especificar quais dos minions do cluster têm os perfis ajustados ativamente. Para fazer isso, adicione estas funções explicitamente com os seguintes comandos:

Nota

Um minion não pode ter as duas funções latency e throughput.

root@master # ceph-salt config /ceph_cluster/roles/tuned/latency add ses-min1.example.com
Adding ses-min1.example.com...
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/tuned/throughput add ses-min2.example.com
Adding ses-min2.example.com...
1 minion added.

5.3.2.7 Gerando um par de chaves SSH #

O cephadm usa o protocolo SSH para se comunicar com os nós do cluster. Uma conta do usuário chamada cephadm é criada automaticamente e usada para comunicação por SSH.

Você precisa gerar a parte particular e a pública do par de chaves SSH:

root@master # ceph-salt config /ssh generate
Key pair generated.
root@master # ceph-salt config /ssh ls
o- ssh .................................................. [Key Pair set]
  o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]

5.3.2.8 Configurando o servidor de horário #

Todos os nós do cluster precisam ter o horário sincronizado com uma fonte de horário confiável. Há vários cenários para realizar a sincronização de horário:

Se todos os nós do cluster já estiverem configurados para sincronizar o horário usando um serviço NTP de sua escolha, desabilite completamente o processamento do servidor de horário:
```
root@master # ceph-salt config /time_server disable
```
Se o seu site já tiver uma fonte de horário única, especifique o nome de host dessa fonte:
```
 root@master # ceph-salt config /time_server/servers add time-server.example.com
```
Se preferir, o ceph-salt pode configurar um dos Minions Salt para agir como o servidor de horário para o restante do cluster. Esse recurso às vezes é chamado de "servidor de horário interno". Nesse cenário, o ceph-salt configura o servidor de horário interno (que deve ser um dos Minions Salt) para sincronizar seu horário com um servidor de horário externo, como pool.ntp.org, e configura todos os outros minions para obter o horário do servidor de horário interno. Isso pode ser feito da seguinte maneira:
```
root@master # ceph-salt config /time_server/servers add ses-master.example.com
root@master # ceph-salt config /time_server/external_servers add pool.ntp.org
```
A opção /time_server/subnet especifica a sub-rede da qual os clientes NTP têm permissão para acessar o servidor NTP. Ela é definida automaticamente quando você especifica /time_server/servers. Se você precisar mudá-la ou especificá-la manualmente, execute:
```
root@master # ceph-salt config /time_server/subnet set 10.20.6.0/24
```

Verifique as configurações do servidor de horário:

root@master # ceph-salt config /time_server ls
o- time_server ................................................ [enabled]
  o- external_servers ............................................... [1]
  | o- pool.ntp.org ............................................... [...]
  o- servers ........................................................ [1]
  | o- ses-master.example.com ..................................... [...]
  o- subnet .............................................. [10.20.6.0/24]

Encontre mais informações sobre como configurar a sincronização de horário em https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-ntp.html#sec-ntp-yast.

5.3.2.9 Configurando as credenciais de login do Ceph Dashboard #

O Ceph Dashboard estará disponível após a implantação do cluster básico. Para acessá-lo, você precisa definir um nome de usuário e uma senha válidos, por exemplo:

root@master # ceph-salt config /cephadm_bootstrap/dashboard/username set admin
root@master # ceph-salt config /cephadm_bootstrap/dashboard/password set PWD

Dica: Forçando atualização da senha

Por padrão, o primeiro usuário do painel de controle será forçado a mudar sua senha ao efetuar o primeiro login. Para desabilitar esse recurso, execute o seguinte comando:

root@master # ceph-salt config /cephadm_bootstrap/dashboard/force_password_update disable

5.3.2.10 Configurando o caminho para imagens de container #

O cephadm precisa saber um caminho de URI válido para as imagens de container que serão usadas durante a etapa de implantação. Verifique se o caminho padrão está definido:

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path ls

Se não houver um caminho padrão definido ou se a implantação exigir um caminho específico, adicione-o da seguinte maneira:

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set registry.suse.com/ses/7/ceph/ceph

Nota

Para a pilha de monitoramento, são necessárias mais imagens de container. Para uma implantação isolada (air-gapped) e também de um registro local, você pode obter essas imagens neste momento para preparar o registro local de acordo.

Observe que essas imagens de container não serão usadas pelo ceph-salt para a implantação. É uma preparação para uma etapa posterior em que o cephadm será usado para a implantação ou migração dos componentes de monitoramento.

Para obter mais informações sobre as imagens usadas pela pilha de monitoramento e como personalizá-las, visite a página Seção 16.1, “Configurando imagens personalizadas ou locais”.

5.3.2.11 Configurando o registro do container #

Opcionalmente, você pode definir um registro de container local. Ele servirá como um espelho do registro registration.suse.com. Lembre-se de que você precisa sincronizar novamente o registro local sempre que houver novos containers atualizados disponíveis em registry.suse.com.

A criação de um registro local é útil nos seguintes cenários:

Você tem muitos nós de cluster e deseja economizar tempo de download e largura de banda criando um espelho local de imagens de container.
Seu cluster não tem acesso ao registro online, uma implantação isolada (air-gapped), e você precisa de um espelho local do qual extrair as imagens de container.
Se problemas de configuração ou rede impedirem que o cluster acesse os registros remotos por meio de um link seguro, você precisará de um registro local não criptografado.

Importante

Para implantar Correções Temporárias de Programas (PTFs, Program Temporary Fixes) em um sistema suportado, você precisa implantar um registro de container local.

Para configurar um URL de registro local junto com as credenciais de acesso, faça o seguinte:

Configure o URL do registro local:

cephuser@adm > ceph-salt config /containers/registry_auth/registry set REGISTRY_URL

Configure o nome de usuário e a senha para acessar o registro local:

cephuser@adm > ceph-salt config /containers/registry_auth/username set REGISTRY_USERNAME

cephuser@adm > ceph-salt config /containers/registry_auth/password set REGISTRY_PASSWORD

Execute o ceph-salt apply para atualizar o pilar Salt em todos os minions.

Dica: Cache de registro

Para evitar a ressincronização do registro local quando novos containers atualizados forem exibidos, você pode configurar um cache de registro.

Os métodos de Desenvolvimento e Entrega de Aplicativos Nativos de Nuvem exigem um registro e uma instância de Integração/Entrega Contínua (CI/CD, Continuous Integration/Delivery) para o desenvolvimento e a produção de imagens de container. Você pode usar um registro particular nessa instância.

5.3.2.12 Habilitando a criptografia de dados em trânsito (msgr2) #

O Messenger v2 (MSGR2) é o protocolo on-wire do Ceph. Ele oferece um modo de segurança que criptografa todos os dados que passam pela rede, encapsulamento de payloads de autenticação e habilitação da integração futura de novos modos de autenticação (como Kerberos).

Importante

Atualmente, o msgr2 não é suportado pelos clientes Ceph do kernel do Linux, como CephFS e Dispositivo de Blocos RADOS.

Os daemons do Ceph podem se vincular a várias portas, permitindo que os clientes Ceph legados e os novos clientes compatíveis com a versão 2 se conectem ao mesmo cluster. Por padrão, os MONs agora se vinculam à nova porta 3300 atribuída pela IANA (CE4h ou 0xCE4) para o novo protocolo v2 e também à porta antiga padrão 6789 para o protocolo v1 legado.

O protocolo v2 (MSGR2) suporta dois modos de conexão:

modo crc: Uma autenticação inicial forte quando a conexão é estabelecida e uma verificação de integridade CRC32C.
modo seguro: Uma autenticação inicial forte quando a conexão é estabelecida e a criptografia completa de todo o tráfego pós-autenticação, incluindo uma verificação de integridade criptográfica.

Para a maioria das conexões, há opções que controlam os modos que são usados:

ms_cluster_mode: O modo de conexão (ou modos permitidos) usado para comunicação intracluster entre os daemons do Ceph. Se houver vários modos na lista, a preferência será dos que forem listados primeiro.
ms_service_mode: Uma lista de modos permitidos para os clientes usarem na conexão com o cluster.
ms_client_mode: Uma lista de modos de conexão, em ordem de preferência, para os clientes usarem (ou permitirem) na comunicação com um cluster do Ceph.

Há um conjunto paralelo de opções que se aplicam especificamente aos monitores, permitindo que os administradores definam requisitos diferentes (geralmente mais seguros) para comunicação com os monitores.

ms_mon_cluster_mode: O modo de conexão (ou modos permitidos) que será usado entre os monitores.
ms_mon_service_mode: Uma lista de modos permitidos para clientes ou outros daemons do Ceph usarem na conexão com monitores.
ms_mon_client_mode: Uma lista de modos de conexão, em ordem de preferência, para clientes ou daemons que não são de monitor usarem na conexão com monitores.

Para habilitar o modo de criptografia MSGR2 durante a implantação, você precisa adicionar algumas opções à configuração do ceph-salt antes de executar o ceph-salt apply.

Para usar o modo secure, execute os comandos a seguir.

Adicione a seção global ao ceph_conf na ferramenta de configuração do ceph-salt:

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global

Defina as seguintes opções:

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode "secure crc"

Nota

Certifique-se de que secure venha antes de crc.

Para forçar o modo secure, execute os seguintes comandos:

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode secure

Dica: Atualizando as configurações

Para mudar qualquer uma das configurações acima, defina as mudanças de configuração no armazenamento de configuração do monitor. Isso é feito usando o comando ceph config set.

root@master # ceph config set global CONNECTION_OPTION CONNECTION_MODE [--force]

Por exemplo:

root@master # ceph config set global ms_cluster_mode "secure crc"

Para verificar o valor atual, incluindo o valor padrão, execute o seguinte comando:

root@master # ceph config get CEPH_COMPONENT CONNECTION_OPTION

Por exemplo, para obter o ms_cluster_mode dos OSD's, execute:

root@master # ceph config get osd ms_cluster_mode

5.3.2.13 Configurando a rede do cluster #

Opcionalmente, se você executar uma rede de cluster separada, talvez seja necessário definir o endereço IP da rede do cluster seguido pela parte da máscara de sub-rede após a barra, por exemplo, 192.168.10.22/24.

Execute os seguintes comandos para habilitar cluster_network:

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set cluster_network NETWORK_ADDR

5.3.2.14 Verificando a configuração do cluster #

A configuração mínima do cluster foi concluída. Verifique se há erros óbvios:

root@master # ceph-salt config ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [Minions: 5]
  | | o- ses-master.example.com .................................. [admin]
  | | o- ses-min1.example.com ......................... [bootstrap, admin]
  | | o- ses-min2.example.com ................................. [no roles]
  | | o- ses-min3.example.com ................................. [no roles]
  | | o- ses-min4.example.com ................................. [no roles]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [Minions: 2]
  |   | o- ses-master.example.com ....................... [no other roles]
  |   | o- ses-min1.example.com ................. [other roles: bootstrap]
  |   o- bootstrap ................................ [ses-min1.example.com]
  |   o- cephadm ............................................ [Minions: 5]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path ............... [registry.suse.com/ses/7/ceph/ceph]
  | o- dashboard ................................................... [...]
  |   o- force_password_update ................................. [enabled]
  |   o- password ................................... [randomly generated]
  |   o- username ................................................ [admin]
  | o- mon_ip ............................................ [192.168.10.20]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh .................................................. [Key Pair set]
  | o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  | o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- time_server ............................................... [enabled]
    o- external_servers .............................................. [1]
    | o- 0.pt.pool.ntp.org ......................................... [...]
    o- servers ....................................................... [1]
    | o- ses-master.example.com .................................... [...]
    o- subnet ............................................. [10.20.6.0/24]

Dica: Status da configuração do cluster

Você pode verificar se a configuração do cluster é válida executando o seguinte comando:

root@master # ceph-salt status
cluster: 5 minions, 0 hosts managed by cephadm
config: OK

5.3.2.15 Exportando as configurações do cluster #

Depois de configurar o cluster básico e sua configuração estiver válida, convém exportá-la para um arquivo:

root@master # ceph-salt export > cluster.json

Atenção

A saída do comando ceph-salt export inclui a chave privada SSH. Se você estiver preocupado com as implicações de segurança, não execute esse comando sem tomar as devidas precauções.

Caso você danifique a configuração do cluster e tenha de reverter para um estado de backup, execute:

root@master # ceph-salt import cluster.json

5.3.3 Atualizando os nós e o cluster mínimo de boot #

Antes de implantar o cluster, atualize todos os pacotes de software em todos os nós:

root@master # ceph-salt update

Se um nó relatar que a Reinicialização é necessária durante a atualização, os pacotes importantes do OS, como o kernel, foram atualizados para uma versão mais recente, e você precisa reinicializar o nó para aplicar as mudanças.

Para reinicializar todos os nós que exigem reinicialização, anexe a opção --reboot

root@master # ceph-salt update --reboot

Se preferir, reinicialize-os em uma etapa separada:

root@master # ceph-salt reboot

Importante

O Master Salt nunca é reinicializado pelos comandos ceph-salt update --reboot ou ceph-salt reboot. Se o Master Salt precisar ser reinicializado, você deverá reinicializá-lo manualmente.

Após a atualização dos nós, inicialize o cluster mínimo:

root@master # ceph-salt apply

Nota

Quando a inicialização for concluída, o cluster terá um Ceph Monitor e um Ceph Manager.

O comando acima abrirá uma interface do usuário interativa que mostra o andamento atual de cada minion.

Figura 5.1: Implantação de um cluster mínimo #

Dica: Modo não interativo

Se você precisa aplicar a configuração de um script, também há um modo de implantação não interativo. Ele também é útil para implantar o cluster de uma máquina remota, porque a atualização constante das informações de andamento na tela pela rede pode provocar distração:

root@master # ceph-salt apply --non-interactive

5.3.4 Revisando as etapas finais #

Após a conclusão do comando ceph-salt apply, você deverá ter um Ceph Monitor e um Ceph Manager. Você deve conseguir executar o comando ceph status com êxito em qualquer um dos minions que receberam a função admin como root ou o usuário cephadm por meio do sudo.

As próximas etapas envolvem o uso do cephadm para implantar mais Ceph Monitor, Ceph Manager, OSDs, Pilha de Monitoramento e Gateways.

Antes de continuar, revise as novas configurações de rede do cluster. Neste ponto, a configuração public_network foi preenchida com base no que foi inserido para /cephadm_bootstrap/mon_ip na configuração do ceph-salt. No entanto, essa configuração foi aplicada apenas ao Ceph Monitor. Você pode revisá-la com o seguinte comando:

root@master # ceph config get mon public_network

Esse é o mínimo necessário para o Ceph funcionar, mas recomendamos tornar essa configuração public_network global, o que significa que ela será aplicada a todos os tipos de daemons do Ceph, e não apenas aos MONs:

root@master # ceph config set global public_network "$(ceph config get mon public_network)"

Nota

Essa etapa não é obrigatória. No entanto, se você não usar essa configuração, os Ceph OSDs e outros daemons (exceto o Ceph Monitor) escutarão em todos os endereços.

Para que seus OSDs se comuniquem entre si usando uma rede completamente separada, execute o seguinte comando:

root@master # ceph config set global cluster_network "cluster_network_in_cidr_notation"

A execução desse comando garante que os OSDs criados em sua implantação usem a rede de cluster pretendida desde o início.

Se o cluster estiver definido para ter nós densos (mais de 62 OSDs por host), atribua portas suficientes aos Ceph OSDs. Atualmente, a faixa padrão (6800-7300) não permite mais do que 62 OSDs por host. Para um cluster com nós densos, ajuste a configuração ms_bind_port_max para um valor adequado. Cada OSD consumirá oito portas adicionais. Por exemplo, um host definido para executar 96 OSDs requer 768 portas. ms_bind_port_max deve ser definido, no mínimo, como 7568 executando o seguinte comando:

root@master # ceph config set osd.* ms_bind_port_max 7568

Você precisará ajustar as configurações de firewall de acordo para que isso funcione. Consulte o Seção 13.7, “Firewall settings for Ceph” para obter mais informações.

5.4 Implantando serviços e gateways #

Após implantar o cluster básico do Ceph, implante os serviços principais em mais nós do cluster. Para tornar os dados do cluster acessíveis aos clientes, implante também mais serviços.

Atualmente, oferecemos suporte à implantação de serviços do Ceph na linha de comando usando o orquestrador do Ceph (subcomandos ceph orch).

5.4.1 O comando `ceph orch` #

O comando do orquestrador do Ceph ceph orch, uma interface com o módulo cephadm, processará a listagem de componentes do cluster e a implantação dos serviços do Ceph em novos nós do cluster.

5.4.1.1 Exibindo o status do orquestrador #

O comando a seguir mostra o modo e o status atuais do orquestrador do Ceph.

cephuser@adm > ceph orch status

5.4.1.2 Listando dispositivos, serviços e daemons #

Para listar todos os dispositivos de disco, execute o seguinte:

cephuser@adm > ceph orch device ls
Hostname   Path      Type  Serial  Size   Health   Ident  Fault  Available
ses-master /dev/vdb  hdd   0d8a... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdc  hdd   8304... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdd  hdd   7b81... 10.7G  Unknown  N/A    N/A    No
[...]

Dica: Serviços e daemons

Serviço é um termo geral para um serviço do Ceph de um tipo específico, por exemplo, Ceph Manager.

Daemon é uma instância específica de um serviço, por exemplo, um processo mgr.ses-min1.gdlcik executado em um nó denominado ses-min1.

Para listar todos os serviços conhecidos pelo cephadm, execute:

cephuser@adm > ceph orch ls
NAME  RUNNING  REFRESHED  AGE  PLACEMENT  IMAGE NAME                  IMAGE ID
mgr       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd
mon       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd

Dica

Você pode limitar a lista a serviços em um nó específico com o parâmetro opcional ‑‑host e a serviços de um determinado tipo com o parâmetro opcional --service-type (os tipos aceitáveis são mon, osd, mgr, mds e rgw).

Para listar todos os daemons em execução implantados pelo cephadm, execute:

cephuser@adm > ceph orch ps
NAME            HOST     STATUS   REFRESHED AGE VERSION    IMAGE ID     CONTAINER ID
mgr.ses-min1.gd ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd b8104e09814c
mon.ses-min1    ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd a719e0087369

Dica

Para consultar o status de um daemon específico, use --daemon_type e --daemon_id. Para os OSDs, o ID é o ID numérico do OSD. Para o MDS, o ID é o nome do sistema de arquivos:

cephuser@adm > ceph orch ps --daemon_type osd --daemon_id 0
cephuser@adm > ceph orch ps --daemon_type mds --daemon_id my_cephfs

5.4.2 Especificação de serviço e posicionamento #

A maneira recomendada de especificar a implantação dos serviços do Ceph é criar um arquivo no formato YAML com a especificação dos serviços que você pretende implantar.

5.4.2.1 Criando especificações de serviço #

Você pode criar um arquivo de especificação separado para cada tipo de serviço, por exemplo:

root@master # cat nfs.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

Se preferir, você poderá especificar vários (ou todos) tipos de serviço em um arquivo (por exemplo, cluster.yml), que descreve quais nós executarão serviços específicos. Lembre-se de separar os tipos de serviço individuais com três traços (---):

cephuser@adm > cat cluster.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE
---
service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
---
[...]

As propriedades mencionadas acima têm o seguinte significado:

service_type: O tipo de serviço. Ele pode ser um serviço do Ceph (mon, mgr, mds, crash, osd ou rbd-mirror), um gateway (nfs ou rgw) ou parte da pilha de monitoramento (alertmanager, grafana, node-exporter ou prometheus).
service_id: O nome do serviço. As especificações do tipo mon, mgr, alertmanager, grafana, node-exporter e prometheus não exigem a propriedade service_id.
placement: Especifica os nós que executarão o serviço. Consulte Seção 5.4.2.2, “Criando a especificação de posicionamento” para obter mais detalhes.
spec: Especificação adicional relevante para o tipo de serviço.

Dica: Aplicando serviços específicos

Geralmente, os serviços de cluster do Ceph têm várias propriedades específicas. Para obter exemplos e detalhes da especificação de cada serviço, consulte a Seção 5.4.3, “Implantar serviços do Ceph”.

5.4.2.2 Criando a especificação de posicionamento #

Para implantar os serviços do Ceph, o cephadm precisa saber em quais nós implantá-los. Use a propriedade placement e liste os nomes abreviados de host dos nós aos quais o serviço se aplica:

cephuser@adm > cat cluster.yml
[...]
placement:
  hosts:
  - host1
  - host2
  - host3
[...]

5.4.2.3 Aplicando a especificação de cluster #

Após criar um arquivo cluster.yml completo com as especificações de todos os serviços e seu posicionamento, você poderá aplicar o cluster executando o seguinte comando:

cephuser@adm > ceph orch apply -i cluster.yml

Para ver o status do cluster, execute o comando ceph orch status. Para ver mais detalhes, consulte a Seção 5.4.1.1, “Exibindo o status do orquestrador”.

5.4.2.4 Exportando a especificação de um cluster em execução #

Embora você tenha implantado serviços no cluster do Ceph usando os arquivos de especificação, conforme descrito na Seção 5.4.2, “Especificação de serviço e posicionamento”, a configuração do cluster pode divergir da especificação original durante sua operação. Além disso, você pode ter removido os arquivos de especificação por engano.

Para recuperar uma especificação completa de um cluster em operação, execute:

cephuser@adm > ceph orch ls --export
placement:
  hosts:
  - hostname: ses-min1
    name: ''
    network: ''
service_id: my_cephfs
service_name: mds.my_cephfs
service_type: mds
---
placement:
  count: 2
service_name: mgr
service_type: mgr
---
[...]

Dica

Você pode anexar a opção --format para mudar o formato de saída padrão yaml. Você pode selecionar entre json, json-pretty ou yaml. Por exemplo:

ceph orch ls --export --format json

5.4.3 Implantar serviços do Ceph #

Depois que o cluster básico estiver em execução, você poderá implantar os serviços do Ceph nos outros nós.

5.4.3.1 Implantando Ceph Monitors e Ceph Managers #

O cluster do Ceph tem três ou cinco MONs implantados em nós diferentes. Se houver cinco ou mais nós no cluster, recomendamos a implantação de cinco MONs. Uma boa prática é implantar os MGRs nos mesmos nós que os MONs.

Importante: incluir MON de boot

Ao implantar MONs e MGRs, lembre-se de incluir o primeiro MON que você adicionou durante a configuração do cluster básico na Seção 5.3.2.5, “Especificando o primeiro nó MON/MGR”.

Para implantar MONs, use a seguinte especificação:

service_type: mon
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Nota

Se você precisar adicionar outro nó, anexe o nome de host à mesma lista YAML. Por exemplo:

service_type: mon
placement:
 hosts:
 - ses-min1
 - ses-min2
 - ses-min3
 - ses-min4

Da mesma forma, para implantar MGRs, use a seguinte especificação:

Importante

Verifique se a implantação tem pelo menos três Ceph Managers em cada implantação.

service_type: mgr
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Dica

Se os MONs ou MGRs não estiverem na mesma sub-rede, você precisará anexar os endereços das sub-redes. Por exemplo:

service_type: mon
placement:
  hosts:
  - ses-min1:10.1.2.0/24
  - ses-min2:10.1.5.0/24
  - ses-min3:10.1.10.0/24

5.4.3.2 Implantando Ceph OSDs #

Importante: quando o dispositivo de armazenamento está disponível

Um dispositivo de armazenamento será considerado disponível se todas as condições abaixo forem verdadeiras:

O dispositivo não tem partições.
O dispositivo não tem nenhum estado de LVM.
O dispositivo não está montado.
O dispositivo não contém um sistema de arquivos.
O dispositivo não contém um OSD com BlueStore.
O dispositivo é maior do que 5 GB.

Se as condições acima não forem verdadeiras, o Ceph se recusará a provisionar esses OSDs.

A implantação de OSDs pode ser feita de duas maneiras:

Instrua o Ceph a consumir todos os dispositivos de armazenamento disponíveis e não utilizados:
```
cephuser@adm > ceph orch apply osd --all-available-devices
```
Use o DriveGroups (consulte o Seção 13.4.3, “Adicionando OSDs por meio da especificação DriveGroups”) para criar uma especificação de OSD que descreva os dispositivos que serão implantados com base em suas propriedades, como tipo de dispositivo (SSD ou HDD), nomes de modelo de dispositivo e tamanho, ou os nós onde os dispositivos residem. Em seguida, aplique a especificação executando o seguinte comando:
```
cephuser@adm > ceph orch apply osd -i drive_groups.yml
```

5.4.3.3 Implantando servidores de metadados #

O CephFS requer um ou mais serviços do Servidor de Metadados (MDS, Metadata Server). Para criar um CephFS, primeiro crie os servidores MDS usando a seguinte especificação:

Nota

Verifique se você já criou pelo menos dois pools (um para os dados do CephFS e outro para os metadados do CephFS) antes de usar a especificação a seguir.

service_type: mds
service_id: CEPHFS_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Depois que os MDSs estiverem em operação, crie o CephFS:

ceph fs new CEPHFS_NAME metadata_pool data_pool

5.4.3.4 Implantando Gateways de Objetos #

O cephadm implanta um Gateway de Objetos como uma coleção de daemons que gerenciam um domínio e uma zona específicos.

Você pode relacionar um serviço de Gateway de Objetos a um domínio e uma zona existentes (consulte o Seção 21.13, “Gateways de Objetos multissite” para obter mais detalhes) ou especificar um REALM_NAME e ZONE_NAME não existentes, e eles serão criados automaticamente depois que você aplicar a seguinte configuração:

service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE

5.4.3.4.1 Usando o acesso SSL seguro #

Para usar uma conexão SSL segura com o Gateway de Objetos, você precisa de um par de arquivos de chave e certificado SSL válidos (consulte o Seção 21.7, “Habilitar HTTPS/SSL para Gateways de Objetos” para obter mais detalhes). Você precisa habilitar o SSL e especificar um número de porta para conexões SSL e os arquivos de chave e certificado SSL.

Para habilitar o SSL e especificar o número da porta, inclua o seguinte em sua especificação:

spec:
  ssl: true
  rgw_frontend_port: 443

Para especificar a chave e o certificado SSL, você pode colar o conteúdo deles diretamente no arquivo de especificação YAML. O sinal de barra vertical (|) no final da linha informa ao analisador para esperar um valor de string de várias linhas. Por exemplo:

spec:
  ssl: true
  rgw_frontend_port: 443
  rgw_frontend_ssl_certificate: |
   -----BEGIN CERTIFICATE-----
   MIIFmjCCA4KgAwIBAgIJAIZ2n35bmwXTMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV
   BAYTAkFVMQwwCgYDVQQIDANOU1cxHTAbBgNVBAoMFEV4YW1wbGUgUkdXIFNTTCBp
   [...]
   -----END CERTIFICATE-----
   rgw_frontend_ssl_key: |
   -----BEGIN PRIVATE KEY-----
   MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDLtFwg6LLl2j4Z
   BDV+iL4AO7VZ9KbmWIt37Ml2W6y2YeKX3Qwf+3eBz7TVHR1dm6iPpCpqpQjXUsT9
   [...]
   -----END PRIVATE KEY-----

Dica

Em vez de colar o conteúdo dos arquivos de chave e certificado SSL, você pode omitir as palavras-chave rgw_frontend_ssl_certificate: e rgw_frontend_ssl_key: e fazer upload deles no banco de dados de configuração:

cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.crt \
 -i SSL_CERT_FILE
cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.key \
 -i SSL_KEY_FILE

5.4.3.4.2 Implantação com um subcluster #

Os subclusters ajudam a organizar os nós nos clusters para isolar as cargas de trabalho e facilitar a expansão elástica. Se a implantação for com um subcluster, use a seguinte configuração:

service_type: rgw
service_id: REALM_NAME.ZONE_NAME.SUBCLUSTER
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE
  subcluster: SUBCLUSTER

5.4.3.5 Implantando Gateways iSCSI #

O cephadm implanta um Gateway iSCSI, que é um protocolo SAN (Storage Area Network) que permite aos clientes (denominados iniciadores) enviar comandos SCSI para dispositivos de armazenamento SCSI (destinos) em servidores remotos.

Use a seguinte configuração para a implantação. Verifique se trusted_ip_list contém os endereços IP de todos os nós do Gateway iSCSI e do Ceph Manager (consulte o exemplo de saída abaixo).

Nota

Verifique se o pool foi criado antes de aplicar a especificação a seguir.

service_type: iscsi
service_id: EXAMPLE_ISCSI
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"

Nota

Verifique se os IPs listados em trusted_ip_list não têm espaço após a separação por vírgula.

5.4.3.5.1 Configuração SSL segura #

Para usar uma conexão SSL segura entre o Ceph Dashboard e a API de destino iSCSI, você precisa de um par de arquivos de chave e certificado SSL válidos. Eles podem ser emitidos por CA ou autoassinados (consulte o Seção 10.1.1, “Criando certificados autoassinados”). Para habilitar o SSL, inclua a configuração api_secure: true no arquivo de especificação:

spec:
  api_secure: true

Para especificar a chave e o certificado SSL, você pode colar o conteúdo diretamente no arquivo de especificação YAML. O sinal de barra vertical (|) no final da linha informa ao analisador para esperar um valor de string de várias linhas. Por exemplo:

spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----

5.4.3.6 Implantando o NFS Ganesha #

O cephadm implanta o NFS Ganesha usando um pool RADOS predefinido e um namespace opcional. Para implantar o NFS Ganesha, use a seguinte especificação:

Nota

Você precisa ter um pool RADOS predefinido; do contrário, haverá falha na operação ceph orch apply. Para obter mais informações sobre como criar um pool, consulte o Seção 18.1, “Criando um pool”.

service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

EXAMPLE_NFS com uma string arbitrária que identifica a exportação do NFS.
EXAMPLE_POOL com o nome do pool em que o objeto de configuração RADOS do NFS Ganesha será armazenado.
EXAMPLE_NAMESPACE (opcional) com o namespace desejado do NFS do Gateway de Objetos (por exemplo, ganesha).

5.4.3.7 Implantando o `rbd-mirror` #

O serviço rbd-mirror se encarrega de sincronizar as imagens do Dispositivo de Blocos RADOS entre dois clusters do Ceph (para obter mais detalhes, consulte o Seção 20.4, “Espelhos de imagens RBD”). Para implantar o rbd-mirror, use a seguinte especificação:

service_type: rbd-mirror
service_id: EXAMPLE_RBD_MIRROR
placement:
  hosts:
  - ses-min3

5.4.3.8 Implantando a pilha de monitoramento #

A pilha de monitoramento consiste no Prometheus, nos exportadores do Prometheus, no Alertmanager do Prometheus e no Grafana. O Ceph Dashboard usa esses componentes para armazenar e visualizar as métricas detalhadas sobre o uso e o desempenho do cluster.

Dica

Se a implantação exigir imagens de container personalizadas ou exibidas localmente dos serviços de pilha de monitoramento, consulte o Seção 16.1, “Configurando imagens personalizadas ou locais”.

Para implantar a pilha de monitoramento, siga estas etapas:

Habilite o módulo prometheus no daemon do Ceph Manager. Esse procedimento expõe as métricas internas do Ceph para que o Prometheus possa lê-las:
```
cephuser@adm > ceph mgr module enable prometheus
```
Nota
Verifique se esse comando foi executado antes da implantação do Prometheus. Se o comando não foi executado antes da implantação, você deve reimplantar o Prometheus para atualizar a configuração do Prometheus:
```
cephuser@adm > ceph orch redeploy prometheus
```

Crie um arquivo de especificação (por exemplo, monitoramento.yaml) com um conteúdo semelhante ao seguinte:

service_type: prometheus
placement:
  hosts:
  - ses-min2
---
service_type: node-exporter
---
service_type: alertmanager
placement:
  hosts:
  - ses-min4
---
service_type: grafana
placement:
  hosts:
  - ses-min3

Aplique os serviços de monitoramento executando este comando:
```
cephuser@adm > ceph orch apply -i monitoring.yaml
```
Pode levar um ou dois minutos para que os serviços de monitoramento sejam implantados.

Importante

O Prometheus, o Grafana e o Ceph Dashboard são todos configurados automaticamente para se comunicarem entre si, resultando em uma integração totalmente funcional do Grafana no Ceph Dashboard, quando implantados conforme descrito acima.

A única exceção a essa regra é o monitoramento com imagens RBD. Consulte o Seção 16.5.4, “Habilitando o monitoramento de imagens RBD” para obter mais informações.

5 Implantação com cephadm #

5.1 Instalando e configurando o SUSE Linux Enterprise Server #

5.2 Implantando o Salt #

5.3 Implantando o cluster do Ceph #

5.3.1 Instalando o ceph-salt #

5.3.2 Configurando as propriedades do cluster #

5.3.2.1 Usando o shell do ceph-salt #

5.3.2.2 Adicionando minions Salt #

5.3.2.3 Especificando minions Salt gerenciados pelo cephadm #

5.3.2.4 Especificando o nó de admin #

5.3.2.5 Especificando o primeiro nó MON/MGR #

5.3.2.6 Especificando perfis ajustados #

5.3.2.7 Gerando um par de chaves SSH #

5.3.2.8 Configurando o servidor de horário #

5.3.2.9 Configurando as credenciais de login do Ceph Dashboard #

5.3.2.10 Configurando o caminho para imagens de container #

5.3.2.11 Configurando o registro do container #

5.3.2.12 Habilitando a criptografia de dados em trânsito (msgr2) #

5.3.2.13 Configurando a rede do cluster #

5.3.2.14 Verificando a configuração do cluster #

5.3.2.15 Exportando as configurações do cluster #

5.3.3 Atualizando os nós e o cluster mínimo de boot #

5.3.4 Revisando as etapas finais #

5.4 Implantando serviços e gateways #

5.4.1 O comando ceph orch #

5.4.1.1 Exibindo o status do orquestrador #

5.4.1.2 Listando dispositivos, serviços e daemons #

5.4.2 Especificação de serviço e posicionamento #

5.4.2.1 Criando especificações de serviço #

5.4.2.2 Criando a especificação de posicionamento #

5.4.2.3 Aplicando a especificação de cluster #

5.4.2.4 Exportando a especificação de um cluster em execução #

5.4.3 Implantar serviços do Ceph #

5.4.3.1 Implantando Ceph Monitors e Ceph Managers #

5.4.3.2 Implantando Ceph OSDs #

5.4.3.3 Implantando servidores de metadados #

5.4.3.4 Implantando Gateways de Objetos #

5.4.3.4.1 Usando o acesso SSL seguro #

5.4.3.4.2 Implantação com um subcluster #

5.4.3.5 Implantando Gateways iSCSI #

5.4.3.5.1 Configuração SSL segura #

5.4.3.6 Implantando o NFS Ganesha #

5.4.3.7 Implantando o rbd-mirror #

5.4.3.8 Implantando a pilha de monitoramento #

5.3.1 Instalando o `ceph-salt` #

5.3.2.1 Usando o shell do `ceph-salt` #

5.4.1 O comando `ceph orch` #

5.4.3.7 Implantando o `rbd-mirror` #