O componente básico de Ceph é denominado RADOS (Reliable Autonomic Distributed Object Store). Ele é responsável por gerenciar os dados armazenados no cluster. Normalmente, os dados no Ceph são armazenados como objetos. Cada objeto consiste em um identificador e nos dados.

O RADOS oferece os seguintes métodos de acesso aos objetos armazenados que envolvem diversos casos de uso:

O Gateway de Objetos e o RBD usam essa biblioteca, enquanto o CephFS estabelece interface direta com o RADOS. Figura 1.1, “Interfaces com o armazenamento de objetos do Ceph”

Figura 1.1: Interfaces com o armazenamento de objetos do Ceph #

 

No centro de um cluster do Ceph está o algoritmo CRUSH. CRUSH é o acrônimo de Controlled Replication Under Scalable Hashing. Trata-se de uma função que processa a alocação de armazenamento e precisa de poucos parâmetros equivalentes. Isso significa que apenas uma pequena quantidade de informações é necessária para calcular a posição de armazenamento de um objeto. Os parâmetros são um mapa atual do cluster, incluindo o estado de saúde, algumas regras de posicionamento definidas pelo administrador e o nome do objeto que precisa ser armazenado ou recuperado. Com essas informações, todos os nós no cluster do Ceph são capazes de calcular onde um objeto e suas réplicas serão armazenados. Isso dificulta a gravação e a leitura de dados muito eficientes. O CRUSH tenta distribuir igualmente os dados a todos os nós do cluster.

O Mapa CRUSH contém todos os nós de armazenamento e as regras de posicionamento definidas pelo administrador para armazenar objetos no cluster. Ele define uma estrutura hierárquica que costuma corresponder à estrutura física do cluster. Por exemplo, os discos com dados estão em hosts, os hosts estão em racks, os racks estão em linhas e as linhas estão em data centers. É possível usar essa estrutura para definir domínios de falha. Em seguida, o Ceph garante que as replicações sejam armazenadas em ramificações diferentes de um domínio de falha específico.

Se o domínio de falha for definido como rack, as replicações dos objetos serão distribuídas para racks diferentes. Isso pode reduzir as interrupções causadas por um switch com falha em um rack. Se uma unidade de distribuição de energia fornece uma linha de racks, o domínio de falha pode ser definido como linha. Quando a unidade de distribuição de energia falha, os dados replicados ainda ficam disponíveis em outras linhas.

No Ceph, os nós são servidores que trabalham para o cluster. Eles podem executar vários tipos de daemons. Recomendamos executar apenas um tipo de daemon em cada nó, exceto os daemons do Ceph Manager, que podem ser combinados com Ceph Monitors. Cada cluster requer pelo menos os daemons do Ceph Monitor, Ceph Manager e Ceph OSD:

Para usar o CephFS, o Gateway de Objetos, o NFS Ganesha ou o iSCSI Gateway, são necessários outros nós:

Os objetos armazenados em um cluster do Ceph são agrupados em pools. Os pools representam as partições lógicas do cluster para o mundo externo. É possível definir um conjunto de regras para cada pool. Por exemplo, o número necessário de replicações de cada objeto. A configuração padrão dos pools chama-se pool replicado.

Normalmente, os pools contêm objetos, mas também podem ser configurados para agir como um RAID 5. Nessa configuração, os objetos são armazenados em pacotes com outros pacotes de codificação. Os pacotes de codificação contêm as informações redundantes. O número de dados e de pacotes de codificação pode ser definido pelo administrador. Nessa configuração, os pools são denominados pools codificados para eliminação ou pools EC.

Os PGs (Placement Groups – Grupos de Posicionamento) são usados para distribuição de dados em um pool. Ao criar um pool, determinado número de grupos de posicionamento é definido. Os grupos de posicionamento são usados internamente para agrupar objetos e são um fator importante para o desempenho de um cluster do Ceph. O PG de um objeto é determinado pelo nome do objeto.

Esta seção mostra um exemplo simplificado de como o Ceph gerencia os dados (consulte a Figura 1.2, “Exemplo de Ceph de pouco dimensionamento”). Esse exemplo não representa uma configuração recomendada para um cluster do Ceph. A configuração de hardware consiste em três nós de armazenamento ou Ceph OSDs (Host 1, Host 2, Host 3). Cada nó tem três discos rígidos que são usados como OSDs (osd.1 a osd.9). Os nós do Ceph Monitor são ignorados neste exemplo.

Nota: Diferença entre Ceph OSD e OSD

Enquanto Ceph OSD ou daemon Ceph OSD refere-se a um daemon executado em um nó, a palavra OSD refere-se ao disco lógico com o qual o daemon interage.

O cluster tem dois pools: Pool A e Pool B. Enquanto o Pool A replica os objetos apenas duas vezes, a resiliência do Pool B é mais importante e efetua três replicações de cada objeto.

Quando um aplicativo coloca um objeto em um pool (por exemplo, pela API REST), um Grupo de Posicionamento (PG1 a PG4) é selecionado com base no nome do pool e do objeto. Em seguida, o algoritmo CRUSH calcula em quais OSDs o objeto é armazenado, com base no Grupo de Posicionamento que contém o objeto.

Neste exemplo, o domínio de falha foi definido como host. Isso garante que as replicações dos objetos sejam armazenadas em hosts diferentes. Dependendo do nível de replicação definido para um pool, o objeto é armazenado em dois ou três OSDs, que são usados pelo Grupo de Posicionamento.

Um aplicativo que grava um objeto interage apenas com um Ceph OSD: o principal. O Ceph OSD principal efetua a replicação e confirma a conclusão do processo de gravação depois que todos os outros OSDs armazenaram o objeto.

Em caso de falha no osd.5, todos os objetos no PG1 ainda estarão disponíveis no osd.1. Logo que o cluster reconhece a falha em um OSD, outro OSD entra em ação. Neste exemplo, o osd.4 é usado como substituto do osd.5. Os objetos armazenados no osd.1 são replicados para o osd.4 para restaurar o nível de replicação.

Figura 1.2: Exemplo de Ceph de pouco dimensionamento #

 

Se um novo nó com novos OSDs for adicionado ao cluster, o mapa do cluster será modificado. Na sequência, a função CRUSH retorna locais diferentes para os objetos. Os objetos que recebem os novos locais serão realocados. Esse processo resulta no uso equilibrado de todos os OSDs.

Recomendamos uma única rede tolerante a falhas com largura de banda suficiente para atender aos seus requisitos. Para o ambiente de rede pública do Ceph, recomendamos duas interfaces de rede de 25 GbE (ou mais rápidas) vinculadas por meio de 802.3ad (LACP). Essa é considerada a configuração mínima do Ceph. Se você também usa uma rede de cluster, recomendamos quatro interfaces de rede de 25 GbE vinculadas. A vinculação de duas ou mais interfaces de rede proporciona melhor throughput por meio da agregação de links e, considerando os links e switches redundantes, melhora a tolerância a falhas e a capacidade de manutenção.

Você também pode criar VLANs para isolar diferentes tipos de tráfego em uma vinculação. Por exemplo, você pode criar uma vinculação para fornecer duas interfaces VLAN: uma para a rede pública e a segunda para a rede de cluster. No entanto, isso não é necessário ao configurar o projeto de rede do Ceph. Os detalhes sobre a vinculação das interfaces estão disponíveis em https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-iface-bonding.

É possível aprimorar a tolerância a falhas por meio do isolamento dos componentes em domínios de falha. Para melhorar a tolerância a falhas da rede, a vinculação de uma interface de duas Placas de Interface de Rede (NIC, Network Interface Cards) separadas oferece proteção contra falhas de uma única NIC. Da mesma forma, criar uma vinculação entre dois switches protege contra falhas de um switch. Recomendamos consultar o fornecedor do equipamento de rede para projetar o nível de tolerância a falhas necessário.

Importante: rede de administração não suportada

A configuração de rede de administração adicional, que permite, por exemplo, separar projetos de rede SSH, Salt ou DNS, não foi testada nem é suportada.

Dica: Nós configurados por DHCP

Se os nós de armazenamento foram configurados por DHCP, os tempos de espera padrão talvez não sejam suficientes para que a rede seja configurada corretamente antes que os vários daemons do Ceph sejam iniciados. Se isso acontecer, os Ceph MONs e OSDs não serão iniciados corretamente (a execução do systemctl status ceph\* resultará em erros do tipo "impossível vincular"). Para evitar esse problema, recomendamos aumentar o tempo de espera do cliente DHCP para pelo menos 30 segundos em cada nó no cluster de armazenamento. Para fazer isso, mude as seguintes configurações em cada nó:

Em /etc/sysconfig/network/dhcp, defina

DHCLIENT_WAIT_AT_BOOT="30"

Em /etc/sysconfig/network/config, defina

WAIT_FOR_INTERFACES="60"

2.1.1.2 Nós de monitoramento em sub-redes diferentes #

 

Se os nós do monitor estiverem em várias sub-redes, por exemplo, localizados em salas distintas e processados por switches diferentes, você precisará especificar o endereço da rede pública na notação CIDR:

cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_N

Por exemplo:

cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"

Atenção

Se você especificar mais de um segmento de rede para a rede pública (ou cluster), conforme descrito nesta seção, cada uma dessas sub-redes deverá ser capaz de rotear para todas as outras. Do contrário, os MONs e outros daemons do Ceph em diferentes segmentos de rede não poderão se comunicar, e o resultado será um cluster dividido. Além disso, se você usa um firewall, certifique-se de incluir cada endereço IP ou sub-rede em seu iptables e abrir as portas para eles em todos os nós, conforme necessário.

Uma configuração de cluster mínima do produto consiste em:

Veja abaixo uma configuração detalhada:

Figura 2.2: Configuração de cluster mínima #

 

Depois que você aumentar o cluster, recomendamos realocar os Ceph Monitors, os Servidores de Metadados e os Gateways para nós separados para melhorar a tolerância a falhas.

Para usar um hardware de múltiplos caminhos, verifique se o LVM vê multipath_component_detection = 1 no arquivo de configuração na seção devices. É possível executar o comando lvm config para verificar isso.

Se preferir, verifique se o LVM filtra os componentes mpath de um dispositivo por meio da configuração do filtro do LVM. Esse procedimento será específico do host.

Nota

Ele não é recomendado e deverá ser considerado apenas se multipath_component_detection = 1 não puder ser definido.

Para obter informações sobre configuração de múltiplos caminhos, consulte https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-multipath.html#sec-multipath-lvm.

Há dois tipos de espaço em disco necessários para execução no OSD: o espaço para o dispositivo WAL/BD e o espaço principal para os dados armazenados. O valor mínimo (e padrão) para o WAL/BD é de 6 GB. O espaço mínimo para os dados é de 5 GB, pois as partições menores do que 5 GB recebem automaticamente o peso de 0.

Portanto, embora o espaço mínimo em disco para um OSD seja de 11 GB, não é recomendável um disco menor do que 20 GB, mesmo para fins de teste.

As SSDs (Solid-State Drives – Unidades de Estado Sólido) não têm partes móveis. Isso reduz o tempo de acesso aleatório e a latência de leitura enquanto acelera o throughput de dados. Como o preço delas por 1 MB é significativamente maior do que o preço dos discos rígidos giratórios, as SSDs são adequadas apenas para armazenamento menor.

Os OSDs podem observar um aprimoramento significativo no desempenho ao armazenar as partições WAL/BD em um SSD e os dados de objetos em um disco rígido separado.

Dica: Compartilhando um SSD com várias partições WAL/BD

Como as partições WAL/BD ocupam relativamente pouco espaço, você pode compartilhar um disco SSD com várias partições WAL/BD. Com cada partição WAL/BD, lembre-se de que o desempenho do disco SSD é reduzido. Não recomendamos compartilhar mais do que seis partições WAL/BD no mesmo disco SSD, e 12 nos discos NVMe.

Você poderá ter quantos discos forem permitidos em um servidor. Há algumas coisas que devem ser consideradas na hora de planejar o número de discos por servidor:

O SUSE Manager e o SUSE Enterprise Storage não estão integrados, portanto, o SUSE Manager não pode gerenciar um cluster do SES neste momento.

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

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 Book “Guia de Operações e Administração”, Chapter 28 “Configuração do cluster do Ceph”, Section 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

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

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]

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.

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]

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.

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]

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]

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 Book “Guia de Operações e Administração”, Chapter 16 “Monitoramento e alerta”, Section 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:

1. Configure o URL do registro local:

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

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

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

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

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

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 Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph” para obter mais informações.

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.

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

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

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

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

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

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 Book “Guia de Operações e Administração”, Chapter 13 “Tarefas operacionais”, Section 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 Book “Guia de Operações e Administração”, Chapter 21 “Gateway de Objetos do Ceph”, Section 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 Book “Guia de Operações e Administração”, Chapter 21 “Gateway de Objetos do Ceph”, Section 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 Book “Guia de Operações e Administração”, Chapter 10 “Configuração manual”, Section 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 Book “Guia de Operações e Administração”, Chapter 18 “Gerenciar pools de armazenamento”, Section 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).

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 Book “Guia de Operações e Administração”, Chapter 16 “Monitoramento e alerta”, Section 16.1 “Configurando imagens personalizadas ou locais”.

Para implantar a pilha de monitoramento, siga estas etapas:

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

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

3. 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 Book “Guia de Operações e Administração”, Chapter 16 “Monitoramento e alerta”, Section 16.5.4 “Habilitando o monitoramento de imagens RBD” para obter mais informações.

Originalmente, o destino iSCSI do kernel do Linux era chamado de LIO, referente a linux-iscsi.org, o domínio original e o site do projeto na Web. Por algum tempo, nada menos do que quatro implementações de destino iSCSI concorrentes estavam disponíveis para a plataforma Linux, mas o LIO acabou prevalecendo como único destino iSCSI de referência. O código de kernel de linha principal do LIO usa o nome simples, porém um pouco ambíguo, "destino", para diferenciar entre "núcleo de destino" e uma variedade de módulos de destino de front end e back end.

Seguramente, o módulo de front end mais usado é o iSCSI. No entanto, o LIO também suporta FC (Fibre Channel), FCoE (Fibre Channel over Ethernet) e vários outros protocolos de front end. Neste momento, apenas o protocolo iSCSI é suportado pelo SUSE Enterprise Storage.

O módulo de back end de destino usado com mais frequência é aquele capaz de simplesmente reexportar qualquer dispositivo de blocos disponível no host de destino. Esse módulo é denominado iblock. No entanto, o LIO também tem um módulo de back end específico do RBD que suporta acesso paralelizado de E/S de múltiplos caminhos às imagens RBD.

Esta seção apresenta informações resumidas sobre os iniciadores iSCSI usados nas plataformas Linux, Microsoft Windows e VMware.

A implantação do Gateway iSCSI do Ceph segue o mesmo procedimento da implantação de outros serviços do Ceph: por meio do cephadm. Para ver mais detalhes, consulte a Seção 5.4.3.5, “Implantando Gateways iSCSI”.

As imagens RBD são criadas no armazenamento do Ceph e, em seguida, exportadas para o iSCSI. É recomendável usar um pool RADOS dedicado para essa finalidade. Você pode criar um volume de qualquer host capaz de se conectar com seu cluster de armazenamento usando o utilitário de linha de comando rbd do Ceph. Para isso, o cliente deve ter pelo menos um arquivo de configuração mínima ceph.conf e as credenciais apropriadas de autenticação no CephX.

Para criar um novo volume para exportação subsequente por meio do iSCSI, use o comando rbd create, especificando o tamanho do volume em megabytes. Por exemplo, para criar um volume de 100 GB chamado testvol no pool denominado iscsi-images, execute:

cephuser@adm > rbd --pool iscsi-images create --size=102400 testvol

Para exportar imagens RBD por meio do iSCSI, você pode usar a interface da Web Ceph Dashboard ou o utilitário gwcli do ceph-iscsi. Nesta seção, vamos nos concentrar apenas no gwcli, demonstrando como criar um destino iSCSI que exporta uma imagem RBD usando a linha de comando.

Nota

As imagens RBD com as seguintes propriedades não podem ser exportadas por meio do iSCSI:

• imagens com o recurso de registro em diário habilitado

• imagens com uma unidade de distribuição menor do que 4096 bytes

Como root, insira o container do Gateway iSCSI:

root # cephadm enter --name CONTAINER_NAME

Como root, inicie a interface de linha de comando do Gateway iSCSI:

root # gwcli

Vá para iscsi-targets e crie um destino com o nome iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol:

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol

Crie os gateways iSCSI especificando o nome e o endereço ip deles:

gwcli >  /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/gateways
gwcli >  /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104
gwcli >  /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105

Dica

Use o comando help para mostrar a lista de comandos disponíveis no nó da configuração atual.

Adicione a imagem RBD com o nome testvol no pool iscsi-images:

gwcli >  /iscsi-target...tvol/gateways> cd /disks
gwcli >  /disks> attach iscsi-images/testvol

Mapeie a imagem RBD para o destino:

gwcli >  /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/disks
gwcli >  /iscsi-target...testvol/disks> add iscsi-images/testvol

Nota

Você pode usar ferramentas de nível mais baixo, como targetcli, para consultar a configuração local, mas sem a modificar.

Dica

Você pode usar o comando ls para revisar a configuração. Alguns nós da configuração também suportam o comando info, que podem ser usados para exibir informações mais detalhadas.

Por padrão, a autenticação ACL está habilitada, portanto, esse destino ainda não está acessível. Consulte a Seção 6.4.4, “Autenticação e controle de acesso” para obter mais informações sobre autenticação e controle de acesso.

A autenticação iSCSI é flexível e inclui muitas possibilidades de autenticação.

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> auth disable_acl

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20

gwcli >  /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol

6.4.4.3 Habilitando a autenticação CHAP #

 

Além da ACL, você pode habilitar a autenticação CHAP especificando um nome de usuário e uma senha para cada iniciador:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20
gwcli >  /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678

Nota

Os nomes de usuário devem ter entre 8 e 64 caracteres e podem incluir caracteres alfanuméricos, ., @, -, _ ou :.

As senhas devem ter entre 12 e 16 caracteres e podem incluir caracteres alfanuméricos, @, -, _ ou /.

Se preferir, você também poderá habilitar a autenticação CHAP mútua especificando os parâmetros mutual_username e mutual_password no comando auth.

6.4.4.4 Configurando descoberta e autenticação mútua #

 

A autenticação Discovery é independente dos métodos de autenticação anteriores. Ela requer credenciais para navegação, é opcional e pode ser configurada por:

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> discovery_auth username=du123456 password=dp1234567890

Nota

Os nomes de usuário devem ter entre 8 e 64 caracteres e podem incluir apenas letras, ., @, -, _ ou :.

As senhas devem ter entre 12 e 16 caracteres e podem incluir apenas letras, @, -, _ ou /.

Você também pode especificar os parâmetros mutual_username e mutual_password no comando discovery_auth.

Use o seguinte comando para desabilitar a autenticação Discovery:

gwcli >  /iscsi-targets> discovery_auth nochap

É possível configurar o ceph-iscsi com parâmetros avançados, que depois são passados para o destino de E/S do LIO. Os parâmetros são divididos nos parâmetros target e disk.

Atenção

Exceto se indicado de outra forma, não é recomendável mudar a configuração padrão desses parâmetros.

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol
gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> info

gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> reconfigure login_timeout 20

gwcli >  /> cd /disks/rbd/testvol
gwcli >  /disks/rbd/testvol> info

gwcli >  /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0

Antes de fazer upgrade, leia as seções a seguir para garantir que você entenda todas as tarefas que precisam ser executadas.

É altamente recomendável fazer backup de todas as configurações e dados do cluster antes de iniciar o upgrade para o SUSE Enterprise Storage 7. Para obter instruções sobre como fazer backup de todos os seus dados, consulte https://documentation.suse.com/ses/6/html/ses-all/cha-deployment-backup.html.

Se você fez upgrade da versão 5, verifique se o upgrade para a versão 6 foi concluído com êxito:

Verifique se existe o arquivo /srv/salt/ceph/configuration/files/ceph.conf.import.

Esse arquivo é criado pelo processo de integração durante o upgrade do SUSE Enterprise Storage 5 para 6. A opção configuration_init: default-import é definida em /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml.

Se configuration_init ainda está definido como default-import, o cluster usa ceph.conf.import como arquivo de configuração, e não o ceph.conf padrão do DeepSea, que é compilado dos arquivos em /srv/salt/ceph/configuration/files/ceph.conf.d/.

Portanto, você precisa inspecionar se há qualquer configuração personalizada em ceph.conf.import e, possivelmente, mover a configuração para um dos arquivos em /srv/salt/ceph/configuration/files/ceph.conf.d/.

Em seguida, remova a linha configuration_init: default-import de /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml.

Verifique se todas as atualizações mais recentes do SUSE Linux Enterprise Server 15 SP1 e do SUSE Enterprise Storage 6 foram aplicadas a todos os nós do cluster:

root # zypper refresh && zypper patch

Após a aplicação das atualizações, verifique a saúde do cluster:

cephuser@adm > ceph -s

Verifique se cada nó do cluster tem acesso aos repositórios do software SUSE Linux Enterprise Server 15 SP2 e SUSE Enterprise Storage 7 e também ao registro de imagens de container.

No SUSE Enterprise Storage 7, os Gateways de Objetos são sempre configurados com um domínio, o que permite multissite no futuro (consulte o Book “Guia de Operações e Administração”, Chapter 21 “Gateway de Objetos do Ceph”, Section 21.13 “Gateways de Objetos multissite” para obter mais detalhes). Se você usou uma configuração de site único do Gateway de Objetos no SUSE Enterprise Storage 6, siga estas etapas para adicionar um domínio. Se você não planeja de fato usar a funcionalidade multissite, pode usar o padrão para os nomes de domínio, grupo de zonas e zona.

Para colocar o serviço Gateway de Objetos em container, crie o respectivo arquivo de especificação conforme descrito na Seção 5.4.3.4, “Implantando Gateways de Objetos” e aplique-o.

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

Veja a seguir como migrar um serviço NFS Ganesha existente que executa o Ceph Nautilus para um container do NFS Ganesha que executa o Ceph Octopus.

Atenção

A documentação a seguir requer que você já tenha feito upgrade dos serviços básicos do Ceph.

O NFS Ganesha armazena a configuração adicional por daemon e a exporta para um pool RADOS. O pool RADOS configurado pode ser encontrado na linha watch_url do bloco RADOS_URLS no arquivo ganesha.conf. Por padrão, esse pool será denominado ganesha_config.

Antes de tentar qualquer migração, é altamente recomendável fazer uma cópia dos objetos de configuração de exportação e daemon localizados no pool RADOS. Para localizar o pool RADOS configurado, execute o seguinte comando:

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

Para listar o conteúdo do pool RADOS:

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

Para copiar os objetos RADOS:

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

Para cada nó, um serviço NFS Ganesha existente precisa ser interrompido e, em seguida, substituído por um container gerenciado pelo cephadm.

É possível migrar as exportações existentes de duas maneiras diferentes:

Após a migração bem-sucedida do serviço, o serviço NFS Ganesha baseado no Nautilus poderá ser removido.

Ao contrário dos MONs, MGRs e OSDs, o Servidor de Metadados não pode ser adotado no local. Em vez disso, você precisa reimplantá-lo em containers usando o orquestrador do Ceph.

Para fazer upgrade do iSCSI Gateway, é necessário reimplantá-lo em containers usando o orquestrador do Ceph. Se você tiver vários iSCSI Gateways, precisará reimplantá-los um por um para reduzir o tempo de espera do serviço.