8 Implantando os serviços principais restantes com o cephadm #

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

cephuser@adm > ceph orch status

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

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:

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 8.3, “Implantar serviços do Ceph”.

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

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 8.1.1, “Exibindo o status do orquestrador”.

Embora você tenha implantado serviços no cluster do Ceph usando os arquivos de especificação, conforme descrito na Seção 8.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

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

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:

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

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

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

8.3.4.1.1 Configurar o Gateway de Objetos para escutar nas portas 443 e 80 #

 

Para configurar o Gateway de Objetos para escutar nas portas 443 (HTTPS) e 80 (HTTP), siga estas etapas:

Nota

Os comandos no procedimento usam domínio e zona default.

1. Forneça um arquivo de especificação para implantar o Gateway de Objetos. Consulte a Seção 8.3.4, “Implantando Gateways de Objetos” para obter mais detalhes sobre a especificação do Gateway de Objetos. Utilize o seguinte comando:

   cephuser@adm > ceph orch apply -i SPEC_FILE

2. Se os certificados SSL não forem fornecidos no arquivo de especificação, adicione-os usando o seguinte comando:

   cephuser@adm > ceph config-key set rgw/cert/default/default.crt -i certificate.pem
   cephuser@adm > ceph config-key set rgw/cert/default/default.key -i key.pem

3. Mude o valor padrão da opção rgw_frontends:

   cephuser@adm > ceph config set client.rgw.default.default rgw_frontends \
    "beast port=80 ssl_port=443"

4. Remova a configuração específica criada pelo cephadm. Identifique para qual destino a opção rgw_frontends foi configurada executando o comando:

   cephuser@adm > ceph config dump | grep rgw

   Por exemplo, o destino é client.rgw.default.default.node4.yiewdu. Remova o valor específico atual de rgw_frontends:

   cephuser@adm > ceph config rm client.rgw.default.default.node4.yiewdu rgw_frontends

   

   Dica

   Em vez de remover um valor de rgw_frontends, você pode especificá-lo. Por exemplo:

   cephuser@adm > ceph config set client.rgw.default.default.node4.yiewdu \
    rgw_frontends "beast port=80 ssl_port=443"

5. Reinicie os Gateways de Objetos:

   cephuser@adm > ceph orch restart rgw.default.default

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

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.

spec:
  api_secure: true

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

Importante

O NFS Ganesha suporta o NFS versão 4.1 e mais recente. Ele não suporta o NFS versão 3.

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

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

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:

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.