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 a librados, 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-SP3/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-SP3/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.

Se você executar o config sem nenhum caminho ou subcomando, digitará um shell interativo do ceph-saltceph-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 ceph-saltls do , 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:

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

Inclua todos ou um subconjunto de Minions Salt que implantamos e aceitamos na Capítulo 6, 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]

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

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.

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

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.

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]

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:

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-SP3/html/SLES-all/cha-ntp.html#sec-ntp-yast.

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

O cluster do Ceph precisa ter acesso a um registro de container para que possa fazer download e implantar os serviços do Ceph em container. Há duas maneiras de acessar o registro:

7.2.10.1 Criando e configurando o registro local (opcional) #

 

Importante

Há vários métodos de criação de um registro local. As instruções nesta seção são exemplos de criação de registros seguros e não seguros. Para obter informações gerais sobre a execução de um registro de imagem de container, consulte https://documentation.suse.com/sles/15-SP3/single-html/SLES-container/#sec-docker-registry-installation.

Dica: Posicionamento e uso de porta

Implante o registro em uma máquina acessível a todos os nós no cluster. Recomendamos o Nó de Admin. Por padrão, o registro escuta na porta 5000.

No nó de registro, use o seguinte comando para garantir que a porta esteja livre:

ss -tulpn | grep :5000

Se outros processos (como iscsi-tcmu) já estiverem escutando na porta 5000, determine outra porta livre que possa ser usada para mapear para a porta 5000 no container de registro.

Procedimento 7.1: Criando o registro local #

 

1. Verifique se a extensão Containers Module está habilitada:

   > SUSEConnect --list-extensions | grep -A2 "Containers Module"
   Containers Module 15 SP3 x86_64 (Activated)

2. Verifique se os seguintes pacotes estão instalados: apache2-utils (no caso de habilitar um registro seguro), cni, cni-plugins, podman, podman-cni-config e skopeo.

3. Colete as seguintes informações:

   • Nome de domínio completo e qualificado do host de registro (REG_HOST_FQDN).

   • Um número de porta disponível usado para mapear para a porta 5000 do container de registro (REG_HOST_PORT).

   • Se o registro será seguro ou não seguro (insecure=[true|false]).

4. Para iniciar um registro não seguro (sem criptografia SSL), siga estas etapas:

   1. Configure o ceph-salt para o registro não seguro:

      cephuser@adm > ceph-salt config containers/registries_conf enable
      cephuser@adm > ceph-salt config containers/registries_conf/registries \
       add prefix=REG_HOST_FQDN insecure=true \
       location=REG_HOST_PORT:5000

   2. Inicie o registro não seguro criando o diretório necessário (por exemplo, /var/lib/registry) e iniciando o registro com o comando podman:

      # mkdir -p /var/lib/registry
      # podman run --privileged -d --name registry \
       -p REG_HOST_PORT:5000 -v /var/lib/registry:/var/lib/registry \
       --restart=always registry:2

   3. Para que o registro seja iniciado após uma reinicialização, crie um arquivo da unidade systemd para ele e habilite-o:

      > sudo podman generate systemd --files --name registry
      > sudo mv container-registry.service /etc/systemd/system/
      > sudo systemctl enable container-registry.service

5. Para iniciar um registro seguro, siga estas etapas:

   1. Crie os diretórios necessários:

      # mkdir -p /var/lib/registry/{auth,certs}

   2. Gere um certificado SSL:

      # openssl req -newkey rsa:4096 -nodes -sha256 \
       -keyout /var/lib/registry/certs/domain.key -x509 -days 365 \
       -out /var/lib/registry/certs/domain.crt

      

      Nota

      Defina o valor CN=[value] como o nome de domínio completo e qualificado do host ([REG_HOST_FQDN]).

   3. Copie o certificado para todos os nós do cluster e atualize o cache do certificado:

      # salt-cp '*' /var/lib/registry/certs/domain.crt \
       /etc/pki/trust/anchors/
      # salt '*' cmd.shell "update-ca-certificates"

   4. Gere uma combinação de nome de usuário e senha para autenticação no registro:

      # htpasswd2 -bBc /var/lib/registry/auth/htpasswd \
       REG_USERNAME REG_PASSWORD

   5. Inicie o registro seguro. Use o flag REGISTRY_STORAGE_DELETE_ENABLED=true para que você possa apagar imagens posteriormente com o comando skopeo delete.

      podman run --name myregistry -p REG_HOST_PORT:5000 \
       -v /var/lib/registry:/var/lib/registry \
       -v /var/lib/registry/auth:/auth:z \
       -e "REGISTRY_AUTH=htpasswd" \
       -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
       -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
       -v /var/lib/registry/certs:/certs:z \
       -e "REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt" \
       -e "REGISTRY_HTTP_TLS_KEY=/certs/domain.key" \
       -e REGISTRY_STORAGE_DELETE_ENABLED=true \
       -e REGISTRY_COMPATIBILITY_SCHEMA1_ENABLED=true -d registry:2

   6. Teste o acesso seguro ao registro:

      > curl https://REG_HOST_FQDN:REG_HOST_PORT/v2/_catalog \
       -u REG_USERNAME:REG_PASSWORD

6. Quando o registro local é criado, você precisa sincronizar as imagens de container do registro oficial do SUSE em registry.suse.com com o registro local. Você pode usar o comando skopeo sync incluído no pacote skopeo para essa finalidade. Para obter mais detalhes, consulte a página de manual (man 1 skopeo-sync). Considere estes exemplos:

   Exemplo 7.1: Vendo arquivos de manifesto #

    

   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/ceph | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/grafana | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 | jq .RepoTags

   Exemplo 7.2: Sincronizar com um diretório #

    

   Sincronizar todas as imagens do Ceph:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph /root/images/

   Sincronizar apenas as imagens mais recentes:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph:latest /root/images/

   Exemplo 7.3: Sincronizar as imagens do Grafana: #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana /root/images/

   Sincronizar apenas as imagens mais recentes do Grafana:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana:latest /root/images/

   Exemplo 7.4: Sincronizar as imagens mais recentes do Prometheus #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 /root/images/

Procedimento 7.2: Configurar o registro local e as credenciais de acesso #

 

1. Configure o URL do registro local:

   cephuser@adm > ceph-salt config /containers/registry_auth/registry set REG_HOST_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 REG_USERNAME

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

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.

7.2.10.2 Configurando o caminho para imagens de container #

 

Importante

Esta seção ajuda você a configurar o caminho para as imagens de container do cluster de boot (implantação do primeiro par de Ceph Monitor e Ceph Manager). O caminho não se aplica a imagens de container de serviços adicionais, por exemplo, a pilha de monitoramento.

Dica: Configurando o proxy HTTPS

Se você precisa usar um proxy para se comunicar com o servidor de registro do container, execute as seguintes etapas de configuração em todos os nós do cluster:

1. Copie o arquivo de configuração dos containers:

   > sudo cp /usr/share/containers/containers.conf /etc/containers/containers.conf

2. Edite o arquivo recém-copiado e adicione a configuração http_proxy a esta seção [engine], por exemplo:

   > cat /etc/containers/containers.conf
    [engine]
    http_proxy=proxy.example.com
    [...]

O cephadm precisa saber um caminho de URI válido para as imagens de container. Verifique a configuração padrão executando:

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

Se você não precisa de um registro alternativo ou local, especifique o registro de container do SUSE padrão:

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

Se a implantação exigir um caminho específico, por exemplo, um caminho para um registro local, configure-o da seguinte maneira:

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set LOCAL_REGISTRY_PATH

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:

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

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.

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

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

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

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

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 Book “Guia de Administração e Operações”, 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

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 Book “Guia de Administração e Operações”, 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

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 Book “Guia de Administração e Operações”, 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

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

iSCSI é uma implementação do comando SCSI (Small Computer System Interface) definido pelo Protocolo IP, especificado na RFC 3720. O iSCSI é implementado como um serviço em que o cliente (iniciador) comunica-se com o servidor (destino) por meio de uma sessão na porta TCP 3260. O endereço IP e a porta do destino iSCSI são chamados de portal iSCSI, em que um destino pode ser exposto por meio de um ou mais portais. A combinação de um destino e de um ou mais portais é denominada grupo de portais de destino (TPG, Target Portal Group).

O protocolo da camada de link de dados subjacente ao iSCSI costuma ser a Ethernet. Mais especificamente, as infraestruturas modernas do iSCSI usam 10 GigE Ethernet, ou redes mais rápidas, para alcançar o throughput ideal. A conectividade 10 Gigabit Ethernet entre o iSCSI Gateway e o cluster de back end do Ceph é altamente recomendada.

O ceph-iscsi combina os benefícios dos Dispositivos de Blocos RADOS com a versatilidade universal do iSCSI. Ao executar o ceph-iscsi em um host de destino iSCSI (conhecido como iSCSI Gateway), qualquer aplicativo que tenha que usar armazenamento de blocos poderá se beneficiar do Ceph, mesmo que ele não reconheça nenhum protocolo de cliente do Ceph. Em vez disso, os usuários podem utilizar o iSCSI ou qualquer outro protocolo de front end de destino para se conectar a um destino LIO, o que converte todas as operações de E/S de destino em armazenamento RBD.

Figura 9.1: Cluster do Ceph com único iSCSI Gateway #

 

O ceph-iscsi apresenta alta disponibilidade inerente e suporta operações de múltiplos caminhos. Portanto, os hosts downstream do iniciador podem usar vários iSCSI Gateways para alta disponibilidade e escalabilidade. Durante a comunicação com uma configuração do iSCSI com mais de um gateway, os iniciadores podem equilibrar a carga das solicitações iSCSI entre vários gateways. Em caso de falha no gateway, estado temporariamente inacessível ou desabilitado para manutenção, a E/S continuará por meio de outro gateway de forma visível.

Figura 9.2: Cluster do Ceph com vários gateways iSCSI #

 

Uma configuração mínima do SUSE Enterprise Storage 7.1 com ceph-iscsi consiste nos seguintes componentes:

Uma configuração de produção recomendada do SUSE Enterprise Storage 7.1 com ceph-iscsi consiste em:

Esta seção descreve as etapas para instalar e configurar um iSCSI Gateway no SUSE Enterprise Storage.

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

9.1.4.3 Exportando imagens RBD por meio do iSCSI #

 

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:

# cephadm enter --name CONTAINER_NAME

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

# 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 9.1.4.4, “Autenticação e controle de acesso” para obter mais informações sobre autenticação e controle de acesso.

9.1.4.4 Autenticação e controle de acesso #

 

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

9.1.4.4.1 Desabilitando a autenticação ACL #

 

Nenhuma Autenticação significa que qualquer iniciador poderá acessar qualquer LUN no destino correspondente. Você pode habilitar Nenhuma Autenticação desabilitando a autenticação ACL:

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

9.1.4.4.2 Usando a autenticação ACL #

 

Ao usar a autenticação ACL com base no nome do iniciador, apenas os iniciadores definidos têm permissão para se conectar. Faça o seguinte para definir um iniciador:

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

Os iniciadores definidos poderão se conectar, mas apenas terão acesso às imagens RBD que foram explicitamente adicionadas aos iniciadores:

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

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

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

9.1.4.5 Definindo configurações avançadas #

 

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

9.1.4.5.1 Visualizando configurações de destino #

 

Você pode ver o valor dessas configurações usando o comando info:

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

E mudar uma configuração usando o comando reconfigure:

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

As configurações de target disponíveis são:

default_cmdsn_depth

Profundidade padrão do CmdSN (Command Sequence Number – Número de Sequência do Comando). Limita a quantidade de solicitações pendentes que um iniciador iSCSI pode ter em qualquer momento.

default_erl

Nível de recuperação de erro padrão.

login_timeout

Valor de tempo de espera de login em segundos.

netif_timeout

Tempo de espera de falha da NIC em segundos.

prod_mode_write_protect

Se definida como 1, impede gravações em LUNs.

9.1.4.5.2 Visualizando configurações de disco #

 

Você pode ver o valor dessas configurações usando o comando info:

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

E mudar uma configuração usando o comando reconfigure:

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

As configurações de disk disponíveis são:

block_size

Tamanho do bloco do dispositivo subjacente.

emulate_3pc

Se definida como 1, habilita Cópia de Terceiros.

emulate_caw

Se definida como 1, habilita Comparar e Gravar.

emulate_dpo

Se definida como 1, ativa o recurso Disable Page Out (Desabilitar Saída de Página).

emulate_fua_read

Se definida como 1 habilita a leitura de Force Unit Access (Forçar Acesso de Unidade).

emulate_fua_write

Se definida como 1, habilita a gravação de Force Unit Access (Forçar Acesso de Unidade).

emulate_model_alias

Se definida como 1, usa o nome do dispositivo de back end para o álias do modelo.

emulate_pr

Se definida como 0, o suporte para Reservas SCSI, incluindo Reservas de Grupo Persistentes, será desabilitado. Enquanto estiver desabilitado, o iSCSI Gateway do SES pode ignorar o estado de reserva, resultando em melhor latência de solicitação.

Dica

A recomendação é definir backstore_emulate_pr como 0 se os iniciadores iSCSI não exigirem suporte para Reserva SCSI.

emulate_rest_reord

Se definida como 0, o Modificador de Algoritmo de Fila terá Reordenação Restrita.

emulate_tas

Se definida como 1, habilita o Status Interrompido da Tarefa.

emulate_tpu

Se definida como 1, habilita a Anulação do Mapeamento de Aprovisionamento Dinâmico.

emulate_tpws

Se definida como 1, habilita a Mesma Gravação de Aprovisionamento Dinâmico.

emulate_ua_intlck_ctrl

Se definida como 1, habilita o Interbloqueio de Atenção de Unidade.

emulate_write_cache

Se definida como 1, ativa a Habilitação de Gravação de Cache.

enforce_pr_isids

Se definida como 1, assegura o uso obrigatório de ISIDs de reserva persistentes.

is_nonrot

Se definida como 1, o backstore será um dispositivo não rotacional.

max_unmap_block_desc_count

Número máximo de descritores de blocos para UNMAP.

max_unmap_lba_count:

Número máximo de LBAs para UNMAP.

max_write_same_len

Tamanho máximo para WRITE_SAME.

optimal_sectors

Tamanho da solicitação ideal em setores.

pi_prot_type

Tipo de proteção DIF.

queue_depth

Profundidade da fila.

unmap_granularity

Granularidade de UNMAP.

unmap_granularity_alignment

Alinhamento da granularidade de UNMAP.

force_pr_aptpl

Quando habilitada, o LIO sempre gravará o estado de reserva persistente no armazenamento persistente, mesmo que o cliente não o tenha solicitado usando aptpl=1. Isso não tem efeito com o back end do RBD do kernel para LIO, ele sempre mantém o estado de reserva persistente. O ideal é que a opção target_core_rbd force-o como “1” e emita um erro se alguém tentar desabilitá-lo pela configuração.

unmap_zeroes_data

Afeta se o LIO divulgará ou não o LBPRZ para os iniciadores SCSI, indicando que os zeros serão lidos novamente de uma região seguindo UNMAP ou WRITE SAME com um bit de anulação de mapeamento.

O ceph-iscsi suporta os dois backstores rbd (com base no kernel) e user:rbd (tcmu-runner), tornando todo o gerenciamento transparente e independente do backstore.

Atenção: Prévia de tecnologia

Atualmente, as implantações do iSCSI Gateway com base no tcmu-runner estão na versão Technology Preview.

Diferentemente das implantações do iSCSI Gateway baseadas em kernel, os iSCSI Gateways com base em tcmu-runner não oferecem suporte a E/S de múltiplos caminhos ou Reservas Persistentes SCSI.

Para exportar a imagem do Dispositivo de Blocos RADOS usando o tcmu-runner, tudo o que você precisar fazer é especificar o backstore user:rbd ao anexar o disco:

gwcli >  /disks> attach rbd/testvol backstore=user:rbd

Nota

Ao usar o tcmu-runner, o recurso exclusive-lock deve estar habilitado na imagem RBD exportada.

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 os dados do cluster antes de iniciar o upgrade para o SUSE Enterprise Storage 7.1. Para obter instruções sobre como fazer backup de todos os seus dados, consulte o https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backup.

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:

# zypper refresh && zypper patch

Dica

Consulte https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updates para obter informações detalhadas sobre como atualizar os nós do cluster.

Depois que as atualizações forem aplicadas, reinicie o Master Salt, sincronize os novos módulos do Salt e verifique a saúde do cluster:

root@master # systemctl restart salt-master.service
root@master # salt '*' saltutil.sync_all
cephuser@adm > ceph -s

 cephuser@adm > ceph status
 cluster:
   id:     3fe8b35a-689f-4970-819d-0e6b11f6707c
   health: HEALTH_WARN
   mons are allowing insecure global_id reclaim
 [...]

cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false

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

No SUSE Enterprise Storage 7.1, os Gateways de Objetos são sempre configurados com um domínio, o que permite multissite no futuro (consulte o Book “Guia de Administração e Operações”, 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 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 8.3.4, “Implantando Gateways de Objetos” e aplique-o.

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

Importante

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

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ó, qualquer serviço existente do NFS Ganesha 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, será possível remover o serviço NFS Ganesha baseado no Nautilus.

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.

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 os dados do cluster antes de iniciar o upgrade. Para obter instruções sobre como fazer backup de todos os seus dados, consulte Book “Guia de Administração e Operações”, Chapter 15 “Backup e restauração”.

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