Guia de Implantação

SUSE Enterprise Storage 6

Guia de ImplantaçãoSUSE Enterprise Storage 6por Tomáš Bažant, Jana Haláčková, Alexandra Settle, e Sven Seeberg

Data de Publicação: 22/05/2020

SUSE LLC1800 South Novell PlaceProvo, UT 84606USA

https://documentation.suse.com

Copyright © 2020 SUSE LLC

Copyright © 2016, RedHat, Inc. e colaboradores.

O texto e as ilustrações neste documento foram licenciados pela Creative Commons Attribution-

Share Alike  4.0 International ("CC-BY-SA"). Há uma explicação da CC-BY-SA disponível em http://

creativecommons.org/licenses/by-sa/4.0/legalcode . De acordo com a CC-BY-SA, se você distribuir este

documento ou uma adaptação dele, deverá fornecer o URL da versão original.

Red Hat, Red Hat Enterprise Linux, o logotipo do Shadowman, JBoss, MetaMatrix, Fedora, o logotipo da

Innity e RHCE são marcas registradas da Red Hat, Inc., com registro nos Estados Unidos e em outros

países. Linux® é a marca comercial registrada da Linus Torvalds nos Estados Unidos e em outros países.

Java® é uma marca comercial registrada da Oracle e/ou de suas aliadas. XFS® é uma marca registrada

da Silicon Graphics International Corp. ou de suas subsidiárias nos Estados Unidos e/ou em outros países.

Todas as outras marcas registradas são de seus respectivos proprietários.

Para ver as marcas registradas da SUSE, visite http://www.suse.com/company/legal/ . Todas as marcas

comerciais de terceiros pertencem a seus respectivos proprietários. Os símbolos de marca registrada (®,™

etc.) representam marcas registradas da SUSE e suas aliadas. Os asteriscos (*) indicam marcas registradas

de terceiros.

Todas as informações deste manual foram compiladas com a maior atenção possível aos detalhes.

Entretanto, isso não garante uma precisão absoluta. A SUSE LLC, suas aliadas, os autores ou tradutores

não serão responsáveis por possíveis erros nem pelas consequências resultantes de tais erros.

Sumário

Sobre este guia x

I SUSE ENTERPRISE STORAGE 1

1 SUSE Enterprise Storage 6 e Ceph 21.1 Recursos do Ceph 2

1.2 Componentes básicos 3

RADOS 3 • CRUSH 4 • Nós e daemons do Ceph 5

1.3 Estrutura de armazenamento 7

Pool 7 • Grupo de posicionamento 7 • Exemplo 7

1.4 BlueStore 9

1.5 Informações adicionais 10

2 Requisitos e recomendações de hardware 11

2.1 Configurações de várias arquiteturas 11

2.2 Configuração mínima do cluster 11

2.3 Nós de armazenamento de objetos 12

Requisitos mínimos 12 • Tamanho mínimo do disco 13 • Tamanho

recomendado para o dispositivo WAL e BD do BlueStore 13 • Usando SSD

para diários OSD 14 • Número máximo recomendado de discos 14

2.4 Nós do monitor 15

2.5 Nós do Object Gateway 15

2.6 Nós do servidor de metadados 16

2.7 Master Salt 16

2.8 Nós do iSCSI 16

iv Guia de Implantação

2.9 Recomendações de rede 16

Adicionando uma rede privada a um cluster em execução 17 • Nós do

monitor em sub-redes diferentes 18

2.10 Limitações de nomeação 18

2.11 OSD e monitor que compartilham um servidor 19

2.12 Configuração recomendada do cluster de produção 19

2.13 SUSE Enterprise Storage 6 e outros produtos da SUSE 20

SUSE Manager 20

3 Configuração de alta disponibilidade do nó de admindo 21

3.1 Estrutura do cluster de HA para o nó de admin do 21

3.2 Criando o cluster de HA com nó de admin 22

4 Privilégios de usuário e prompts de comando 24

4.1 Comandos relacionados ao Salt/DeepSea 24

4.2 Comandos relacionados ao Ceph 24

4.3 Comandos gerais do Linux 25

4.4 Informações adicionais 25

II IMPLANTAÇÃO E UPGRADE DO CLUSTER 26

5 Implantando com o DeepSea/Salt 275.1 Ler os detalhes da versão 27

5.2 Introdução ao DeepSea 28

Organização e locais importantes 29 • Direcionando os minions 30

5.3 Implantação do cluster 32

5.4 CLI do DeepSea 42

CLI do DeepSea: Modo monitor 43 • CLI do DeepSea: Modo

independente 43

v Guia de Implantação

5.5 Configuração e personalização 45

Arquivo policy.cfg 45 • DriveGroups 50 • Ajustando o ceph.conf

com configurações personalizadas 60

6 Fazendo upgrade de versões anteriores 61

6.1 Pontos de consideração antes do upgrade 61

6.2 Fazendo backup de dados do cluster 65

6.3 Migrando do ntpd para o chronyd 65

6.4 Corrigindo o cluster antes do upgrade 67

Repositórios de software necessários 67 • Sistemas de propagação em

fases do repositório 67 • Corrigindo o cluster inteiro com os patches mais

recentes 68

6.5 Verificando o ambiente atual 68

6.6 Verificando o estado do cluster 69

6.7 Fazendo upgrade oine dos clusters CTDB 70

6.8 Fazendo upgrade por nó: procedimento básico 70

Fazendo upgrade manual do nó por meio do DVD do

instalador 71 • Fazendo upgrade do nó por meio do SUSE Distribution

Migration System 73

6.9 Fazendo upgrade do nó de admin 75

6.10 Fazendo upgrade dos nós do Ceph Monitor/Ceph Manager 76

6.11 Fazendo upgrade dos servidores de metadados 76

6.12 Fazendo upgrade dos Ceph OSDs 78

6.13 Migração do OSD para BlueStore 81

6.14 Fazendo upgrade dos nós do aplicativo 83

6.15 Atualizando o policy.cfg e implantando o Ceph Dashboard por meiodo DeepSea 84

vi Guia de Implantação

6.16 Migrando de implantações com base no perfil para DriveGroups 86

Analisando o layout atual 87 • Criando DriveGroups que correspondem

ao layout atual 87 • Implantando um OSD 88 • Configurações mais

complexas 88

7 Personalizando a configuração padrão 89

7.1 Usando arquivos de configuração personalizados 89

Desabilitando uma etapa de implantação 89 • Substituindo

uma etapa de implantação 90 • Modificando uma

etapa de implantação 92 • Modificando uma fase de

implantação 93 • Atualizações e reinicializações durante a fase 0 94

7.2 Modificando a configuração descoberta 95

Habilitando o IPv6 para implantação de cluster do Ceph 97

III INSTALAÇÃO DE SERVIÇOS ADICIONAIS 99

8 Instalação de serviços para acessar seus dados 100

9 Ceph Object Gateway 101

9.1 Instalação manual do Object Gateway 102

Configuração do Object Gateway 102

10 Instalação do iSCSI Gateway 109

10.1 Armazenamento em blocos iSCSI 109

Destino iSCSI do kernel do Linux 110 • Iniciadores iSCSI 110

10.2 Informações gerais sobre ceph-iscsi 111

10.3 Considerações de implantação 113

10.4 Instalação e configuração 113

Implantar o iSCSI Gateway em um cluster do Ceph 114 • Criar imagens

RBD 114 • Exportar imagens RBD por meio do iSCSI 114 • Autenticação e

controle de acesso 116 • Configurações avançadas 117

10.5 Exportando imagens de dispositivo de blocos RADOS usando tcmu-runner 121

vii Guia de Implantação

11 Instalação do CephFS 123

11.1 Cenários e diretrizes suportados do CephFS 123

11.2 Servidor de metadados Ceph 124

Adicionando um servidor de metadados 124 • Configurando um servidor de

metadados 124

11.3 CephFS 130

Criando o CephFS 130 • Tamanho do cluster MDS 132 • Cluster e

atualizações do MDS 132 • Layouts de arquivos 133

12 Instalação do NFS Ganesha 139

12.1 Preparação 139

Informações Gerais 139 • Resumo dos requisitos 140

12.2 Exemplo de instalação 140

12.3 Configuração ativa-passiva de alta disponibilidade 141

Instalação básica 141 • Limpar recursos 144 • Configurando o recurso de

ping 144 • HA do NFS Ganesha e DeepSea 145

12.4 Configuração ativa-ativa 145

Pré-requisitos 146 • Configurando o NFS Ganesha 146 • Preenchendo

o banco de dados extra do cluster 148 • Reiniciando os serviços NFS

Ganesha 148 • Conclusão 149

12.5 Mais informações 149

IV IMPLANTAÇÃO DO CLUSTER NO SUSE CAAS PLATFORM 4 (TECHNOLOGYPREVIEW) 150

13 SUSE Enterprise Storage 6 no cluster Kubernetes doSUSE CaaS Platform 4 151

13.1 Considerações 151

13.2 Pré-requisitos 151

13.3 Obtendo declarações sobre o Rook 152

viii Guia de Implantação

13.4 Instalação 152

Configuração 152 • Criando o operador do Rook 154 • Criando o cluster

do Ceph 154

13.5 Usando o Rook como armazenamento para carga de trabalho doKubernetes 155

13.6 Desinstalando o Rook 156

A Atualizações de manutenção do Ceph baseadas nospoint releases de upstream do “Nautilus” 157

Glossário 160

B Atualizações da documentação 163

B.1 Atualização de manutenção da documentação do SUSE EnterpriseStorage 6 163

B.2 Junho de 2019 (Lançamento do SUSE Enterprise Storage 6) 164

ix Guia de Implantação

Sobre este guia

O SUSE Enterprise Storage 6 é uma extensão do Linux Enterprise Server 15 SP1. Ele combina osrecursos do projeto de armazenamento Ceph (http://ceph.com/ ) com a engenharia corporativae o suporte da SUSE. O SUSE Enterprise Storage 6 oferece às organizações de TI o recurso paraimplantar uma arquitetura de armazenamento distribuído capaz de suportar inúmeros casos deuso por meio de plataformas de hardware convencional.

Este guia ajuda você a entender o conceito do SUSE Enterprise Storage 6 com foco nogerenciamento e na administração da infraestrutura do Ceph. Ele também demonstra como usaro Ceph com outras soluções relacionadas, por exemplo KVM ou OpenStack.

Muitos capítulos neste manual contêm links para recursos adicionais de documentação. Estãoincluídas a documentação adicional disponível no sistema e a documentação disponível naInternet.

Para obter uma visão geral da documentação disponível para o seu produto e das atualizaçõesde documentação mais recentes, consulte http://www.suse.com/documentation .

1 Documentação disponívelOs seguintes manuais estão disponíveis para este produto:

Livro “Guia de Administração”

O guia descreve várias tarefas de administração que normalmente são executadas apósa instalação. Este guia também apresenta as etapas para integrar o Ceph a soluções devirtualização, como libvirt , Xen ou KVM, e os meios de acesso aos objetos armazenadosno cluster pelos gateways iSCSI e RADOS.

Guia de Implantação

Orienta você pelas etapas de instalação do cluster do Ceph e de todos os serviçosrelacionados ao Ceph. O guia também ilustra uma estrutura básica de cluster do Ceph eapresenta a você a terminologia relacionada.

As versões HTML dos manuais do produto podem ser encontradas no sistema instalado em /usr/share/doc/manual . Encontre as atualizações mais recentes da documentação em http://

www.suse.com/documentation , onde você pode fazer download dos manuais referentes ao seuproduto em vários formatos.

x Documentação disponível SES 6

2 ComentáriosVários canais de comentário estão disponíveis:

Solicitações de bugs e aperfeiçoamentos

Para ver as opções de serviços e suporte disponíveis ao seu produto, consulte http://

www.suse.com/support/ .Para relatar bugs no componente de um produto, efetue login no Novell Customer Centerem http://www.suse.com/support/ e selecione My Support (Meu Suporte) Service Request(Solicitação de Serviço).

Comentários do usuário

Desejamos saber a sua opinião e receber sugestões sobre este manual e outrasdocumentações incluídas neste produto. Utilize o recurso Comentários na parte inferiorde cada página da documentação online ou vá para http://www.suse.com/documentation/

feedback.html e digite lá os seus comentários.

Correio

Para fazer comentários sobre a documentação deste produto, você também pode enviarum e-mail para doc-team@suse.de . Inclua o título do documento, a versão do produto ea data de publicação da documentação. Para relatar erros ou fazer sugestões de melhorias,descreva resumidamente o problema e informe o respectivo número de seção e página (ouURL).

3 Convenções da documentaçãoAs seguintes convenções tipográcas são usadas neste manual:

/etc/passwd : nomes de diretório e arquivo

marcador : substitua marcador pelo valor real

PATH : a variável de ambiente PATH

ls , --help : comandos, opções e parâmetros

user : usuários ou grupos

Alt , Alt – F1 : uma tecla ou uma combinação de teclas a serem pressionadas; as teclassão mostradas em letras maiúsculas como aparecem no teclado

xi Comentários SES 6

Arquivo, Arquivo Gravar Como: itens de menu, botões

Pinguins Dançarinos (Capítulo Pinguins, ↑Outro Manual): É uma referência a um capítulode outro manual.

4 Sobre este manualEste manual foi desenvolvido no GeekoDoc, um subconjunto do DocBook (consulte http://

www.docbook.org ). Os arquivos de origem XML foram validados por xmllint , processadospor xsltproc e convertidos em XSL-FO usando uma versão personalizada das folhas deestilo de Norman Walsh. O PDF nal pode ser formatado por meio do FOP da Apache ou doXEP da RenderX. As ferramentas de criação e publicação usadas para produzir este manualestão disponíveis no pacote daps . O DocBook Authoring and Publishing Suite (DAPS) foidesenvolvido como software de código-fonte aberto. Para obter mais informações, consultehttp://daps.sf.net/ .

5 Colaboradores do CephO projeto do Ceph e a respectiva documentação são resultados do trabalho de centenas decolaboradores e organizações. Visite https://ceph.com/contributors/ para obter mais detalhes.

xii Sobre este manual SES 6

I SUSE Enterprise Storage

1 SUSE Enterprise Storage 6 e Ceph 2

2 Requisitos e recomendações de hardware 11

3 Configuração de alta disponibilidade do nó de admin do 21

4 Privilégios de usuário e prompts de comando 24

1 SUSE Enterprise Storage 6 e Ceph

O SUSE Enterprise Storage 6 é um sistema de armazenamento distribuído projetado paraescalabilidade, conabilidade e desempenho que usa a tecnologia Ceph. É possível executar umcluster do Ceph em servidores convencionais em uma rede comum, como Ethernet. O clustertem capacidade de dimensionamento para milhares de servidores (posteriormente mencionadoscomo nós) e dentro da faixa de petabytes. Ao contrário dos sistemas convencionais que têmtabelas de alocação para armazenar e buscar dados, o Ceph usa um algoritmo determinísticopara alocar armazenamento de dados e não tem nenhuma estrutura centralizada de informações.Nos clusters de armazenamento, o Ceph considera a adição ou remoção de hardware a regra,e não a exceção. O cluster do Ceph automatiza as tarefas de gerenciamento, como distribuiçãoe redistribuição de dados, replicação de dados, detecção de falhas e recuperação. O Cephé autorreparável e autogerenciável, o que resulta na redução de overhead administrativo eorçamentário.

Este capítulo apresenta uma visão geral resumida do SUSE Enterprise Storage 6 e descrevebrevemente os componentes mais importantes.

DicaDesde o SUSE Enterprise Storage 5, o único método de implantação de cluster é o DeepSea.Consulte o Capítulo 5, Implantando com o DeepSea/Salt para obter detalhes sobre o processode implantação.

1.1 Recursos do CephO ambiente do Ceph tem os seguintes recursos:

Escalabilidade

O Ceph pode ser dimensionado para milhares de nós e pode gerenciar o armazenamentona faixa de petabytes.

Hardware convencional

Não há necessidade de hardware especial para executar um cluster do Ceph. Para obter osdetalhes, consulte o Capítulo 2, Requisitos e recomendações de hardware.

Autogerenciável

2 Recursos do Ceph SES 6

O cluster do Ceph é autogerenciável. Quando os nós são adicionados, removidos oufalham, o cluster redistribui os dados automaticamente. Ele também reconhece discossobrecarregados.

Sem Ponto Único de Falha

Nenhum nó em um cluster armazena informações importantes separadamente. É possívelcongurar o número de redundâncias.

Software de código-fonte aberto

O Ceph é uma solução de software de código-fonte aberto e independente de hardware oude fornecedores especícos.

1.2 Componentes básicosPara aproveitar todas as vantagens do Ceph, é necessário conhecer alguns dos componentes econceitos básicos. Esta seção apresenta algumas partes do Ceph que são mencionadas com maisfrequência em outros capítulos.

1.2.1 RADOS

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

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

Object Gateway

O Object Gateway é um gateway HTTP REST para armazenamento de objetos RADOS. Elepermite acesso direto aos objetos armazenados no cluster do Ceph.

Dispositivo de blocos RADOS

É possível acessar os Dispositivos de Blocos RADOS (RBD) como qualquer outro dispositivode blocos. Eles podem ser usados em combinação com o libvirt para ns devirtualização, por exemplo.

CephFS

O Sistema de Arquivos Ceph é compatível com POSIX.

3 Componentes básicos SES 6

librados

librados é uma biblioteca que pode ser usada com várias linguagens de programaçãopara criar um aplicativo capaz de interagir diretamente com o cluster de armazenamento.

O Object Gateway e o RBD usam essa biblioteca , enquanto o CephFS estabelece interfacedireta com o RADOS. Figura 1.1, “Interfaces com o Armazenamento de Objetos do Ceph”

RADOS

FIGURA 1.1: INTERFACES COM O ARMAZENAMENTO DE OBJETOS DO CEPH

1.2.2 CRUSH

No centro de um cluster do Ceph está o algoritmo CRUSH. CRUSH é o acrônimo de ControlledReplication Under Scalable Hashing. Trata-se de uma função que processa a alocação dearmazenamento e precisa de poucos parâmetros equivalentes. Isso signica que apenas umapequena quantidade de informações é necessária para calcular a posição de armazenamento deum objeto. Os parâmetros são um mapa atual do cluster, incluindo o estado de saúde, algumasregras de posicionamento denidas pelo administrador e o nome do objeto que precisa serarmazenado ou recuperado. Com essas informações, todos os nós no cluster do Ceph são capazesde calcular onde um objeto e suas réplicas serão armazenados. Isso diculta a gravação e aleitura de dados muito ecientes. O CRUSH tenta distribuir igualmente os dados a todos os nósdo cluster.

O mapa CRUSH contém todos os nós de armazenamento e as regras de posicionamento denidaspelo administrador para armazenar objetos no cluster. Ele dene uma estrutura hierárquica quecostuma corresponder à estrutura física do cluster. Por exemplo, os discos com dados estão emhosts, 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 denir domínios de falha. Em seguida, o Ceph garante que asreplicações sejam armazenadas em ramicações diferentes de um domínio de falha especíco.

4 CRUSH SES 6

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

1.2.3 Nós e daemons do Ceph

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

Nó de Admin

O Nó de Admin é um nó de cluster do Ceph em que o serviço master Salt está sendoexecutado. O Nó de Admin é um ponto central do cluster do Ceph porque ele gerenciao restante dos nós do cluster consultando e instruindo os serviços de minion Salt.Normalmente, ele também inclui outros serviços. Por exemplo, a IU da Web do CephDashboard com o painel de controle do Grafana e o suporte do kit de ferramentas demonitoramento do Prometheus.

Ceph Monitor

Os nós do Ceph Monitor (geralmente abreviado como MON) mantêm informações sobre oestado de saúde do cluster, um mapa de todos os nós e as regras de distribuição de dados(consulte a Seção 1.2.2, “CRUSH”).Em caso de falhas ou conitos, os nós do Ceph Monitor no cluster decidem, por maioria,quais informações estão corretas. Para formar uma maioria qualicada, é recomendávelter um número ímpar de nós do Ceph Monitor e, pelo menos, três deles.Se for usado mais de um site, os nós do Ceph Monitor deverão ser distribuídos para umnúmero ímpar de sites. O número de nós do Ceph Monitor por site deve ser suciente paraque mais do que 50% dos nós do Ceph Monitor continuem funcionando em caso de falhade um site.

Ceph Manager

O Ceph Manager (MGR) coleta as informações de estado do cluster inteiro. O daemon CephManager é executado com os daemons do monitor. Ele fornece monitoramento adicionale estabelece interface com os sistemas externos de monitoramento e gerenciamento.

5 Nós e daemons do Ceph SES 6

O Ceph Manager não requer conguração adicional, além de garantir que esteja emexecução. Você pode implantá-lo como uma função separada usando o DeepSea.

Ceph OSD

O Ceph OSD é um daemon que processa Dispositivos de Armazenamento de Objetos, que sãounidades físicas ou lógicas de armazenamento (discos rígidos ou partições). Os Dispositivosde Armazenamento de Objetos podem ser discos/partições físicos ou volumes lógicos. Odaemon também se encarrega da replicação e redistribuição de dados em caso de nósadicionados ou removidos.Os daemons Ceph OSD comunicam-se com os daemons do monitor e informam a eles oestado dos outros daemons OSD.

Para usar o CephFS, o Object Gateway, o NFS Ganesha ou o iSCSI Gateway, são necessáriosoutros nós:

MDS (Metadata Server – Servidor de Metadados)

Os Servidores de Metadados armazenam metadados para o CephFS. Ao usar um MDS, vocêpode executar comandos básicos do sistema de arquivos, como ls , sem sobrecarregar ocluster.

Object Gateway

O Object Gateway é um gateway HTTP REST para armazenamento de objetos RADOS. Eleé compatível com o OpenStack Swift e o Amazon S3 e tem seu próprio gerenciamento deusuários.

NFS Ganesha

O NFS Ganesha concede acesso de NFS ao Object Gateway ou CephFS. Ele é executadono espaço do usuário, em vez do kernel, e interage diretamente com o Object Gatewayou o CephFS.

iSCSI Gateway

iSCSI é um protocolo de rede de armazenamento que permite aos clientes enviar comandosSCSI para dispositivos de armazenamento SCSI (destinos) em servidores remotos.

Gateway do Samba

O Gateway do Samba oferece para o SAMBA acesso aos dados armazenados no CephFS.

6 Nós e daemons do Ceph SES 6

1.3 Estrutura de armazenamento

1.3.1 PoolOs objetos armazenados em um cluster do Ceph são agrupados em pools. Os pools representamas partições lógicas do cluster para o mundo externo. É possível denir um conjunto de regraspara cada pool. Por exemplo, o número necessário de replicações de cada objeto. A conguraçãopadrão dos pools chama-se pool replicado.

Normalmente, os pools contêm objetos, mas também podem ser congurados para agir comoum RAID 5. Nessa conguração, os objetos são armazenados em pacotes com outros pacotes decodicação. Os pacotes de codicação contêm as informações redundantes. O número de dadose de pacotes de codicação pode ser denido pelo administrador. Nessa conguração, os poolssão denominados pools com codicação de eliminação.

1.3.2 Grupo de posicionamentoOs PGs (Placement Groups – Grupos de Posicionamento) são usados para distribuição de dadosem um pool. Ao criar um pool, determinado número de grupos de posicionamento é denido.Os grupos de posicionamento são usados internamente para agrupar objetos e são um fatorimportante para o desempenho de um cluster do Ceph. O PG de um objeto é determinado pelonome do objeto.

1.3.3 ExemploEsta seção mostra um exemplo simplicado de como o Ceph gerencia os dados (consultea Figura 1.2, “Exemplo de Ceph de Pouco Dimensionamento”). Esse exemplo não representa umaconguração recomendada para um cluster do Ceph. A conguração de hardware consiste emtrês nós de armazenamento ou Ceph OSDs ( Host 1 , Host 2 , Host 3 ). Cada nó tem três discosrígidos que são usados como OSDs ( osd.1 a osd.9 ). Os nós do Ceph Monitor são ignoradosneste exemplo.

Nota: Diferença entre Ceph OSD e OSDEnquanto Ceph OSD ou daemon Ceph OSD refere-se a um daemon executado em um nó, apalavra OSD refere-se ao disco lógico com o qual o daemon interage.

7 Estrutura de armazenamento SES 6

O cluster tem dois pools: Pool A e Pool B . Enquanto o Pool A replica os objetos apenas duasvezes, 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 Grupode Posicionamento ( PG1 a PG4 ) é selecionado com base no nome do pool e do objeto. Emseguida, o algoritmo CRUSH calcula em quais OSDs o objeto é armazenado, com base no Grupode Posicionamento que contém o objeto.

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

Um aplicativo que grava um objeto interage apenas com um Ceph OSD: o principal. O CephOSD principal efetua a replicação e conrma a conclusão do processo de gravação depois quetodos 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 . Logoque 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 oosd.4 para restaurar o nível de replicação.

FIGURA 1.2: EXEMPLO DE CEPH DE POUCO DIMENSIONAMENTO

8 Exemplo SES 6

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

1.4 BlueStoreBlueStore é um novo back end de armazenamento padrão para Ceph, a partir do SUSE EnterpriseStorage 5. Ele apresenta melhor desempenho do que o FileStore, checksum completo de dadose compactação incorporada.

O BlueStore gerencia um, dois ou três dispositivos de armazenamento. No caso mais simples,o BlueStore consome um único dispositivo de armazenamento principal. Normalmente, odispositivo de armazenamento é particionado em duas partes:

1. Uma pequena partição denominada BlueFS que implementa funcionalidades do tipo dosistema de arquivos que o RocksDB exige.

2. Normalmente, o restante do dispositivo é ocupado por uma partição grande. Ele égerenciado diretamente pelo BlueStore e contém todos os dados reais. Normalmente, essedispositivo principal é identicado por um link simbólico de bloco no diretório de dados.

É possível também implantar o BlueStore em dois dispositivos adicionais:

É possível usar o dispositivo WAL para o diário interno ou o registro write-ahead do BlueStore.Ele é identicado pelo link simbólico block.wal no diretório de dados. O uso de um dispositivoWAL separado será útil apenas se ele for mais rápido do que o dispositivo principal ou odispositivo de BD. Por exemplo, quando:

O dispositivo WAL é um NVMe, o dispositivo de BD é uma SSD e o dispositivo de dadosé uma SSD ou HDD.

Ambos os dispositivos WAL e de BD são SSDs separadas, e o dispositivo de dados é umaSSD ou HDD.

É possível usar um dispositivo de BD para armazenar metadados internos do BlueStore. OBlueStore (ou, em vez dele, o RocksDB incorporado) colocará o máximo de metadados que puderno dispositivo de BD para melhorar o desempenho. Mais uma vez, apenas será útil provisionarum dispositivo de BD compartilhado se ele for mais rápido do que o dispositivo principal.

9 BlueStore SES 6

Dica: Planejar o tamanho do BDPlaneje com cuidado para garantir o tamanho suciente do dispositivo de BD. Se odispositivo de BD car cheio, os metadados serão despejados no dispositivo principal, oque prejudica bastante o desempenho do OSD.

Você pode vericar se uma partição WAL/BD está cando lotada e sendo despejada aoexecutar o comando ceph daemon osd.ID perf dump . O valor slow_used_bytesmostra a quantidade de dados que está sendo despejada:

cephadm@adm > ceph daemon osd.ID perf dump | jq '.bluefs'"db_total_bytes": 1073741824,"db_used_bytes": 33554432,"wal_total_bytes": 0,"wal_used_bytes": 0,"slow_total_bytes": 554432,"slow_used_bytes": 554432,

1.5 Informações adicionais

Como um projeto comunitário, o Ceph tem sua própria documentação online completa.Para os tópicos não encontrados neste manual, visite http://docs.ceph.com/docs/master/ .

A publicação original CRUSH: Controlled, Scalable, Decentralized Placement of ReplicatedData por S.A. Weil, S.A. Brandt, E.L. Miller, C. Maltzahn apresenta informações úteis sobreo funcionamento interno do Ceph. Principalmente na implantação de clusters em grandeescala, trata-se de uma leitura recomendada. Você encontra essa publicação em http://

www.ssrc.ucsc.edu/papers/weil-sc06.pdf .

É possível usar o SUSE Enterprise Storage com distribuições que não são do SUSEOpenStack. Os clientes Ceph precisam estar em um nível que seja compatível com o SUSEEnterprise Storage.

NotaA SUSE suporta o componente de servidor da implantação do Ceph, e o cliente ésuportado pelo fornecedor de distribuição do OpenStack.

10 Informações adicionais SES 6

2 Requisitos e recomendações de hardware

Os requisitos de hardware do Ceph dependem bastante da carga de trabalho de E/S. Os requisitose as recomendações de hardware a seguir devem ser considerados um ponto de partida para oplanejamento detalhado.

Em geral, as recomendações apresentadas nesta seção são baseadas em cada processo. Se houvervários processos localizados na mesma máquina, os requisitos de CPU, RAM, disco e rede deverãoser incrementados.

2.1 Configurações de várias arquiteturasO SUSE Enterprise Storage suporta as arquiteturas x86 e Arm. Ao considerar cada arquitetura,é importante notar que, de uma perspectiva de núcleo por OSD, frequência e RAM, não hádiferença real entre as arquiteturas de CPU quanto ao dimensionamento.

Assim como nos processadores x86 menores (sem servidor), os núcleos de desempenho maisbaixo com base em Arm podem não oferecer uma experiência ideal, principalmente quandousados para pools com codicação de eliminação.

2.2 Configuração mínima do cluster

No mínimo, quatro nós OSD, com oito discos OSD cada, são necessários.

Três nós do Ceph Monitor (requer SSD como unidade dedicada do OS).

iSCSI Gateways, Object Gateways e Servidores de Metadados requerem mais 4 GB de RAMe quatro núcleos.

Nós de Ceph Monitors, Object Gateways e Servidores de Metadados requerem implantaçãoredundante.

Nó de Admin Separado com 4 GB de RAM, quatro núcleos, capacidade de 1 TB. Trata-se normalmente do nó master Salt. Os serviços e gateways do Ceph, como Ceph Monitor,Ceph Manager, Servidor de Metadados, Ceph OSD, Object Gateway ou NFS Ganesha, nãosão suportados no Nó de Admin.

11 Configurações de várias arquiteturas SES 6

2.3 Nós de armazenamento de objetos

2.3.1 Requisitos mínimos

Recomendações da CPU:

1x Thread de CPU de 2 GHz por spinner

2x Threads de CPU de 2 GHz por SSD

4x Threads de CPU de 2 GHz por NVMe

Redes separadas de 10 GbE (pública/cliente e back end), 4x 10 GbE necessário, 2x 25 GbErecomendado.

RAM total necessária = número de OSDs x (1 GB + osd_memory_target ) + 16 GB.Consulte o Livro “Guia de Administração”, Capítulo 16 “Configuração do cluster do Ceph”,

Seção 16.2.1 “Dimensionamento automático do cache” para obter mais detalhes sobreosd_memory_target .

Discos OSD nas congurações JBOD ou nas congurações individuais de RAID-0.

Diário OSD pode residir no disco OSD.

Os discos OSD devem ser usados exclusivamente pelo SUSE Enterprise Storage.

Disco/SSD dedicado para o sistema operacional, preferencialmente em uma conguraçãode RAID 1.

Se este host OSD hospedar parte de um pool de cache usado para criação de camada decache, aloque pelo menos mais 4 GB de RAM.

Ceph Monitors, Ceph Gateway e Servidores de Metadados podem residir em Nós deArmazenamento de Objetos.

Por motivos de desempenho do disco, recomendamos o uso de nós OSD completamentevazios e máquinas físicas.

12 Nós de armazenamento de objetos SES 6

2.3.2 Tamanho mínimo do disco

Há dois tipos de espaço em disco necessários para execução no OSD: o espaço para o diáriodo disco (para FileStore) ou o dispositivo WAL/BD (para BlueStore) e o espaço principalpara os dados armazenados. O valor mínimo (e padrão) para o diário/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 recebemautomaticamente o peso de 0.

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

2.3.3 Tamanho recomendado para o dispositivo WAL e BD doBlueStore

Dica: Mais informaçõesConsulte a Seção 1.4, “BlueStore” para obter mais informações sobre o BlueStore.

Recomendamos reservar 4 GB para o dispositivo WAL. O tamanho recomendado para oBD é de 64 GB para a maioria das cargas de trabalho.

Se você pretende colocar o dispositivo WAL e BD no mesmo disco, recomendamos usaruma única partição para ambos os dispositivos, em vez de ter uma partição separada paracada um. Dessa forma, o Ceph pode usar o dispositivo BD também para operação de WAL.Portanto, o gerenciamento do espaço em disco é mais ecaz, pois o Ceph usa a partiçãoBD para o WAL apenas quando há necessidade dela. Outra vantagem é que há poucaprobabilidade de a partição WAL car cheia, e quando ela não é totalmente usada, o espaçodela não é desperdiçado, mas usado para operação do BD.Para compartilhar o dispositivo BD com o WAL, não especique o dispositivo WAL, masapenas o dispositivo BD.Encontre mais informações sobre como especicar um layout de OSD na Seção  5.5.2,

“DriveGroups”.

13 Tamanho mínimo do disco SES 6

2.3.4 Usando SSD para diários OSD

As SSDs (Solid-State Drives – Unidades de Estado Sólido) não têm partes móveis. Isso reduz otempo de acesso aleatório e a latência de leitura enquanto acelera o throughput de dados. Comoo preço delas por 1 MB é signicativamente 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 signicativo no desempenho armazenando o diárioem uma SSD e os dados de objeto em um disco rígido separado.

Dica: Compartilhando uma SSD para vários diáriosComo os dados do diário ocupam relativamente pouco espaço, você pode montar váriosdiretórios de diário em um único disco SSD. Com cada diário compartilhado, lembre-sede que o desempenho do disco SSD é reduzido. Não recomendamos compartilhar mais doque seis diários no mesmo disco SSD, e 12 nos discos NVMe.

2.3.5 Número máximo recomendado de discos

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

Largura de banda de rede. Quanto mais discos você tiver em um servidor, mais dadosdeverão ser transferidos por placa(s) de rede para as operações de gravação em disco.

Memória. RAM acima de 2  GB é usada para o cache do BlueStore. Com oosd_memory_target padrão de 4 GB, o sistema tem um tamanho de cache inicial razoávelpara mídia giratória. Se você usa SSD ou NVME, considere aumentar o tamanho do cachee a alocação de RAM por OSD para maximizar o desempenho.

Tolerância a falhas. Em caso de falha no servidor inteiro, quanto mais discos ele tiver, maisOSDs o cluster perderá temporariamente. Além disso, para manter as regras de replicaçãoem execução, você precisa copiar todos os dados do servidor com falha para os outros nósno cluster.

14 Usando SSD para diários OSD SES 6

2.4 Nós do monitor

Pelo menos três nós do Ceph Monitor são necessários. O número de monitores deve sersempre ímpar (1+2n).

4 GB de RAM.

Processador com quatro núcleos lógicos.

Uma SSD ou outro tipo de armazenamento rápido o bastante é altamente recomendadopara monitores, principalmente para o caminho /var/lib/ceph em cada nó do monitor,pois o quorum pode car instável com altas latências de disco. É recomendada aconguração de dois discos no RAID 1 para redundância. É recomendável o uso de discosseparados ou, pelo menos, de partições de disco separadas para que os processos do monitorprotejam o espaço em disco disponível do monitor contra eventos como arquivo de registromuito grande.

Deve haver apenas um processo do monitor por nó.

A combinação de nós OSD, de monitor ou do Object Gateway apenas será suportada sehouver recursos de hardware sucientes disponíveis. Isso signica que os requisitos paratodos os serviços precisam ser incrementados.

Duas interfaces de rede vinculadas a vários switches.

2.5 Nós do Object GatewayOs nós do Objeto Gateway devem ter de seis a oito núcleos de CPU e 32 GB de RAM (recomenda-se 64 GB). Quando outros processos são colocalizados na mesma máquina, os requisitos precisamser incrementados.

15 Nós do monitor SES 6

2.6 Nós do servidor de metadadosO dimensionamento apropriado dos nós do Servidor de Metadados depende do caso de usoespecíco. Em geral, quanto mais arquivos abertos o Servidor de Metadados tiver que processar,mais CPU e RAM serão necessárias. Veja a seguir os requisitos mínimos:

3 GB de RAM para cada daemon do Servidor de Metadados.

Interface de rede vinculada.

CPU de 2.5 GHz com, no mínimo, 2 núcleos.

2.7 Master SaltPelo menos 4 GB de RAM e uma CPU quad-core são necessárias. Isso inclui a execução do CephDashboard no Nó de Admin. Para clusters grandes com centenas de nós, 6 GB de RAM é asugestão.

2.8 Nós do iSCSIOs nós do iSCSI devem ter de seis a oito núcleos de CPU e 16 GB de RAM.

2.9 Recomendações de redeO ideal é que o ambiente de rede em que você pretende executar o Ceph seja um conjuntovinculado de no mínimo duas interfaces de rede, que é dividido logicamente em uma partepública e uma parte interna conável por meio de VLANs. Se possível, o modo de vinculaçãorecomendado é 802.3ad para fornecer largura de banda e resiliência máximas.

A VLAN pública serve para fornecer o serviço aos clientes, enquanto a parte interna permitea comunicação de rede autenticada no Ceph. O principal motivo disso é que, embora o Cephofereça autenticação e proteção contra ataques depois que as chaves secretas estão em vigor,as mensagens usadas para congurar essas chaves poderão ser transferidas abertamente e serãovulneráveis.

16 Nós do servidor de metadados SES 6

Dica: Nós configurados por DHCPSe os nós de armazenamento foram congurados por DHCP, os tempos de espera padrãotalvez não sejam sucientes para que a rede seja congurada corretamente antes que osvários daemons do Ceph sejam iniciados. Se isso acontecer, os MONs e OSDs do Cephnão serão iniciados corretamente (a execução de systemctl status ceph\* resultaráem erros "não é possível vincular"). Para evitar esse problema, é recomendável aumentaro tempo de espera do cliente DHCP para, pelo menos, 30 segundos em cada nó no seucluster de armazenamento. Para fazer isso, mude as seguintes congurações em cada nó:

Em /etc/sysconfig/network/dhcp , dena

DHCLIENT_WAIT_AT_BOOT="30"

Em /etc/sysconfig/network/config , dena

WAIT_FOR_INTERFACES="60"

2.9.1 Adicionando uma rede privada a um cluster em execução

Se você não especicar uma rede de cluster durante a implantação do Ceph, ele assumirá umambiente de rede pública única. Enquanto o Ceph funciona bem com uma rede pública, seudesempenho e segurança melhoram quando você dene uma segunda rede privada de cluster.Para suportar duas redes, cada nó do Ceph precisa ter pelo menos duas placas de rede.

Você precisará aplicar as mudanças a seguir a cada nó do Ceph. É relativamente rápido fazerisso em um cluster pequeno, mas pode ser muito demorado se você tem um cluster com centenasou milhares de nós.

1. Pare os serviços relacionados ao Ceph em cada nó do cluster.Adicione uma linha a /etc/ceph/ceph.conf para denir a rede de cluster. Por exemplo:

cluster network = 10.0.0.0/24

Se for necessário atribuir endereços IP estáticos ou anular as congurações de rede decluster especicamente, você poderá fazer isso com o comando opcional cluster addr .

2. Verique se a rede privada de cluster funciona conforme esperado no nível do OS.

3. Inicie os serviços relacionados ao Ceph em cada nó do cluster.

17 Adicionando uma rede privada a um cluster em execução SES 6

root # systemctl start ceph.target

2.9.2 Nós do monitor em sub-redes diferentes

Se os nós do monitor estiverem em várias sub-redes (por exemplo, localizados em salas distintase atendidos por switches diferentes), você precisará ajustar o arquivo ceph.conf de acordo.Por exemplo, se os nós tiverem endereços IP 192.168.123.12, 1.2.3.4 e 242.12.33.12, adicioneas seguintes linhas à seção global deles:

[global][...]mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12mon initial members = MON1, MON2, MON3[...]

Além disso, se você precisar especicar um endereço ou uma rede pública por monitor, adicioneuma seção [mon.X] para cada monitor:

[mon.MON1]public network = 192.168.123.0/24

[mon.MON2]public network = 1.2.3.0/24

[mon.MON3]public network = 242.12.33.12/0

2.10 Limitações de nomeaçãoEm geral, o Ceph não suporta caracteres não ASCII em arquivos de conguração, nomes depool, nomes de usuário, etc. Ao congurar um cluster do Ceph, é recomendável usar apenascaracteres alfanuméricos simples (A-Z, a-z, 0-9) e pontuação mínima ('.', '-', '_’) em todos osnomes de objeto/conguração do Ceph.

18 Nós do monitor em sub-redes diferentes SES 6

2.11 OSD e monitor que compartilham um servidorEmbora seja tecnicamente possível executar Ceph OSDs e Ceph Monitors no mesmo servidorem ambientes de teste, é altamente recomendável ter um servidor separado para cada nó domonitor em produção. O principal motivo é o desempenho: quanto mais OSDs o cluster tiver,mais operações de E/S os nós do monitor precisarão executar. E, quando um servidor forcompartilhado entre um nó de monitor e OSD(s), as operações de E/S do OSD serão um fatorlimitador para o nó do monitor.

Uma outra consideração é quando se deve compartilhar discos entre um OSD, um nó de monitore o sistema operacional no servidor. A resposta é simples: se possível, dedique um disco separadoao OSD e um servidor separado a um nó de monitor.

Embora o Ceph suporte OSDs com base em diretório, um OSD deve sempre ter um disco dedicadodiferente do sistema operacional.

DicaSe for realmente necessário executar um nó OSD e de monitor no mesmo servidor, executeo monitor em um disco separado por meio da montagem do disco no diretório /var/lib/ceph/mon para obter um desempenho um pouco melhor.

2.12 Configuração recomendada do cluster deprodução

Sete Nós de Armazenamento de Objetos

Nenhum nó único excede ~ 15% do total de armazenamento

10 Gb Ethernet (quatro redes físicas vinculadas a vários switches)

Mais de 56 OSDs por cluster de armazenamento

Discos de OS RAID 1 para cada nó de armazenamento OSD

SSDs para Diário com o diário de SSD de proporção 6:1 para OSD

19 OSD e monitor que compartilham um servidor SES 6

1,5 GB de RAM por TB de capacidade bruta do OSD para cada Nó de Armazenamentode Objetos

2 GHz por OSD para cada Nó de Armazenamento de Objetos

Nós dedicados de infraestrutura física

Três nós do Ceph Monitor: 4 GB de RAM, processador de 4 núcleos, SSDs RAID 1para disco

Um nó de gerenciamento SES: 4 GB de RAM, processador de 4 núcleos, SSDs RAID1 para disco

Implantação física redundante de nós de gateway ou Servidor de Metadados:

Nós do Object Gateway: 32 GB de RAM, processador de 8 núcleos, SSDs RAID1 para disco

Nós do iSCSI Gateway: 16 GB de RAM, processador de 4 núcleos, SSDs RAID1 para disco

Nós do Servidor de Metadados (um ativo/um standby ativo): 32 GB de RAM,processador de 8 núcleos, SSDs RAID 1 para disco

2.13 SUSE Enterprise Storage 6 e outros produtos daSUSEEsta seção contém informações importantes sobre a integração do SUSE Enterprise Storage 6com outros produtos da SUSE.

2.13.1 SUSE Manager

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

20 SUSE Enterprise Storage 6 e outros produtos da SUSE SES 6

3 Configuração de alta disponibilidade do nó deadmin do

O Nó de Admin é um nó do cluster do Ceph em que o serviço master Salt está sendo executado.O Nó de Admin é um ponto central do cluster do Ceph porque ele gerencia o restante dos nósdo cluster consultando e instruindo os serviços de minion Salt. Normalmente, ele também incluioutros serviços. Por exemplo, a IU da Web do Ceph Dashboard com o painel de controle doGrafana e o suporte do kit de ferramentas de monitoramento do Prometheus.

Em caso de falha no Nó de Admin, geralmente você precisa fornecer um novo hardware ativopara o nó e restaurar a pilha completa de conguração do cluster de um backup recente. Esseé um método demorado e provoca interrupção no cluster.

Para evitar o tempo de espera no desempenho do cluster do Ceph causado pela falha no Nó deAdmin, é recomendável usar o cluster de Alta Disponibilidade (HA, High Availability) para oNó de Admin do Ceph.

3.1 Estrutura do cluster de HA para o nó de admin doA ideia de um cluster de HA é que, em caso de falha em um nó do cluster, o outro nó assumeautomaticamente a função dele, incluindo o Nó de Admin virtualizado. Dessa forma, os outrosnós do cluster do Ceph não percebem a falha no Nó de Admin.

A solução de HA mínima para o Nó de Admin requer o seguinte hardware:

Dois servidores completamente vazios capazes de executar o SUSE Linux Enterprise coma extensão de Alta Disponibilidade e de virtualizar o Nó de Admin.

Dois ou mais caminhos de comunicação de rede redundantes. Por exemplo, via Ligaçãode Dispositivo de Rede.

Armazenamento compartilhado para hospedar a(s) imagem(ns) de disco da máquinavirtual do Nó de Admin. O armazenamento compartilhado precisa ser acessível aos doisservidores. Por exemplo, ele pode ser uma exportação NFS, um compartilhamento doSamba ou um destino iSCSI.

Encontre mais detalhes sobre os requisitos de cluster no site https://www.suse.com/

documentation/sle-ha-15/book_sleha_quickstarts/data/sec_ha_inst_quick_req.html .

21 Estrutura do cluster de HA para o nó de admin do SES 6

FIGURA 3.1: CLUSTER DE HA DE 2 NÓS PARA O NÓ DE ADMIN DO

3.2 Criando o cluster de HA com nó de adminO procedimento a seguir resume as etapas mais importantes de criação do cluster de HA paravirtualização do Nó de Admin. Para obter detalhes, consulte os links indicados.

1. Congure um cluster de HA básico de 2 nós com armazenamento compartilhado, conformedescrito em https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/

art_sleha_install_quick.html .

2. Em ambos os nós do cluster, instale todos os pacotes necessários para executar o hipervisorKVM e o kit de ferramentas libvirt , conforme descrito em https://www.suse.com/

documentation/sles-15/book_virt/data/sec_vt_installation_kvm.html .

3. No primeiro nó do cluster, crie uma nova VM (Virtual Machine – Máquina Virtual)KVM usando o libvirt , conforme descrito em https://www.suse.com/documentation/

sles-15/book_virt/data/sec_libvirt_inst_vmm.html . Use o armazenamento compartilhadopré-congurado para armazenar as imagens de disco da VM.

4. Após o término da conguração da VM, exporte sua conguração para um arquivo XMLno armazenamento compartilhado. Use a seguinte sintaxe:

root # virsh dumpxml VM_NAME > /path/to/shared/vm_name.xml

22 Criando o cluster de HA com nó de admin SES 6

5. Crie um recurso para a VM do Nó de Admin. Consulte https://www.suse.com/

documentation/sle-ha-15/book_sleha_guide/data/cha_conf_hawk2.html para obterinformações gerais sobre a criação de recursos de HA. Há informações detalhadas sobre acriação de recursos para uma máquina virtual KVM descritas em http://www.linux-ha.org/

wiki/VirtualDomain_%28resource_agent%29 .

6. No convidado da VM recém-criado, implante o Nó de Admin, incluindo os serviçosadicionais necessários nele. Siga as etapas relevantes na Seção 5.3, “Implantação do cluster”.Ao mesmo tempo, implante os nós de cluster do Ceph restantes nos servidores de clusternão HA.

23 Criando o cluster de HA com nó de admin SES 6

4 Privilégios de usuário e prompts de comando

Como administrador de cluster do Ceph, você congura e ajusta o comportamento do clusterexecutando comandos especícos. Há vários tipos de comandos que serão necessários:

4.1 Comandos relacionados ao Salt/DeepSeaEsses comandos ajudam você a implantar ou fazer upgrade do cluster do Ceph, executarcomandos em vários (ou todos) nós do cluster ao mesmo tempo ou ajudá-lo a adicionar ouremover nós do cluster. Os comandos mais usados são salt , salt-run e deepsea . Você precisaexecutar os comandos do Salt no nó master Salt (consulte o Seção 5.2, “Introdução ao DeepSea”

para obter detalhes) como root . Esses comandos são introduzidos com o seguinte prompt:

root@master #

Por exemplo:

root@master # salt '*.example.net' test.ping

4.2 Comandos relacionados ao CephTrata-se de comandos de nível inferior que conguram e ajustam todos os aspectos do clustere seus gateways na linha de comando. ceph , rbd , radosgw-admin ou crushtool são algunsdeles.

Para executar os comandos relacionados ao Ceph, você precisa ter acesso de leitura a uma chavedo Ceph. Os recursos da chave denem seus privilégios no ambiente do Ceph. Uma opção éexecutar os comandos do Ceph como root (ou por meio do sudo ) e usar o chaveiro padrãoirrestrito “ceph.client.admin.key”.

A opção mais segura e recomendada é criar uma chave individual mais restritiva para cadausuário administrador e colocá-la em um diretório onde os usuários possam lê-la. Por exemplo:

~/.ceph/ceph.client.USERNAME.keyring

24 Comandos relacionados ao Salt/DeepSea SES 6

Dica: Caminho para Chaves do CephPara utilizar um usuário admin e um chaveiro personalizados, você precisa especicar onome de usuário e o caminho para a chave toda vez que executar o comando ceph comas opções -n client.USER_NAME e --keyring PATH/TO/KEYRING .

Para evitar isso, inclua essas opções na variável CEPH_ARGS nos arquivos ~/.bashrc dosusuários individuais.

É possível executar os comandos relacionados ao Ceph em qualquer nó do cluster, mas arecomendação é executá-los no Nó de Admin. Esta documentação utiliza o usuário cephadmpara executar os comandos, portanto, eles são introduzidos com o seguinte prompt:

cephadm@adm >

Por exemplo:

cephadm@adm > ceph auth list

Dica: Comandos para Nós EspecíficosSe a documentação orientar você a executar um comando em um nó do cluster com umafunção especíca, isso será processado pelo prompt. Por exemplo:

cephadm@mon >

4.3 Comandos gerais do LinuxOs comandos do Linux não relacionados ao Ceph ou ao DeepSea, como mount , cat ouopenssl , são introduzidos com os prompts cephadm@adm > ou root # , dependendo dosprivilégios exigidos pelo comando relacionado.

4.4 Informações adicionaisPara obter mais informações sobre o gerenciamento de chaves do Ceph, consulte a Livro “Guia de

Administração”, Capítulo 8 “Autenticação com cephx”, Seção 8.2 “Gerenciamento de chaves”.

25 Comandos gerais do Linux SES 6

II Implantação e upgrade do cluster

5 Implantando com o DeepSea/Salt 27

6 Fazendo upgrade de versões anteriores 61

7 Personalizando a configuração padrão 89

5 Implantando com o DeepSea/Salt

O Salt, juntamente com o DeepSea, é uma pilha de componentes que ajuda você a implantar egerenciar a infraestrutura do servidor. Ele é muito escalável, rápido e relativamente fácil de serexecutado. Leia as seguintes considerações antes de começar a implantação do cluster com o Salt:

Os minions Salt são nós controlados por um nó dedicado denominado master Salt. Osminions Salt têm funções. Por exemplo, Ceph OSD, Ceph Monitor, Ceph Manager, ObjectGateway, iSCSI Gateway ou NFS Ganesha.

Um master Salt executa seu próprio minion Salt. Ele é necessário para executar tarefas comprivilégio (por exemplo, criar, autorizar e copiar chaves para os minions), dessa forma, osminions remotos nunca precisam executar tarefas com privilégio.

Dica: Compartilhando várias funções por servidorO desempenho do cluster do Ceph é melhor quando cada função é implantadaem um nó separado. Porém, as implantações reais às vezes exigem que um nóseja compartilhado com várias funções. Para evitar problema de desempenho e deprocedimento de upgrade, não implante a função Ceph OSD, Servidor de Metadadosou Ceph Monitor no Nó de Admin.

Os minions Salt precisam resolver corretamente o nome de host do master Salt na rede. Porpadrão, eles procuram o nome de host salt , mas você pode especicar qualquer outronome de host acessível por rede no arquivo /etc/salt/minion . Consulte a Seção 5.3,

“Implantação do cluster”.

5.1 Ler os detalhes da versãoNos detalhes da versão, você encontra mais informações sobre o que mudou desde a versãoanterior do SUSE Enterprise Storage. Consulte os detalhes da versão para vericar se:

seu hardware precisa de considerações especiais.

qualquer pacote de software usado foi signicativamente modicado.

são necessárias precauções especiais para a instalação.

27 Ler os detalhes da versão SES 6

Os detalhes da versão também apresentam informações que não puderam ser incluídas a tempono manual. Eles também incluem notas sobre problemas conhecidos.

Após instalar o pacote release-notes-ses , encontre os detalhes da versão no diretório local/usr/share/doc/release-notes ou no site https://www.suse.com/releasenotes/ .

5.2 Introdução ao DeepSeaO objetivo do DeepSea é economizar o tempo do administrador e executar com segurançaoperações complexas em um cluster do Ceph.

O Ceph é uma solução de software muito congurável. Ele promove a liberdade e aresponsabilidade dos administradores do sistema.

A conguração mínima do Ceph é ideal para ns de demonstração, mas não apresenta os recursosinteressantes do Ceph que você pode ver com um grande número de nós.

O DeepSea coleta e armazena dados sobre os servidores individuais, como endereços e nomes dedispositivos. Para um sistema de armazenamento distribuído, como Ceph, pode haver centenasdesses itens para coletar e armazenar. A coleta de informações e a entrada manual de dados emuma ferramenta de gerenciamento de conguração são exaustivas e propensas a erros.

A maioria das etapas necessárias para preparar os servidores, coletar a conguração, congurar eimplantar o Ceph é a mesma. No entanto, isso não resolve o gerenciamento de funções separadas.Para operações do dia a dia, a simples capacidade de adicionar hardware a determinada funçãoe removê-lo sem problemas é um requisito.

O DeepSea resolve essas observações com a seguinte estratégia: ele consolida as decisões doadministrador em um único arquivo. As decisões incluem atribuição de cluster, atribuição defunção e atribuição de perl. E o DeepSea coleta cada conjunto de tarefas em uma meta simples.Cada meta é uma fase:

DESCRIÇÃO DAS FASES DO DEEPSEA

Fase 0: preparação. Durante essa fase, todas as atualizações necessárias são aplicadas, eo sistema pode ser reinicializado.

28 Introdução ao DeepSea SES 6

Importante: Executar a Fase 0 Novamente após aReinicialização do Nó de AdminSe o Nó de Admin for reinicializado durante a fase 0 para carregar a nova versão dokernel, você precisará executar a fase 0 novamente; do contrário, os minions nãoserão direcionados.

Fase 1: a descoberta: nessa fase, o hardware inteiro no cluster é detectado e as informaçõesnecessárias para a conguração do Ceph são coletadas. Para obter detalhes sobre aconguração, consulte a Seção 5.5, “Configuração e personalização”.

Fase 2: conguração. Você precisa preparar os dados de conguração em um formatoespecíco.

Fase 3: implantação. Cria um cluster básico do Ceph com os serviços obrigatórios dele.Consulte a Seção 1.2.3, “Nós e daemons do Ceph” para ver a lista.

Fase 4: serviços. É possível instalar recursos adicionais do Ceph, como iSCSI, ObjectGateway e CephFS, nessa fase. Cada um deles é opcional.

Fase 5: fase de remoção. Essa fase não é obrigatória e, durante a conguração inicial, nãocostuma ser necessária. Nessa fase, as funções dos minions e também a conguração docluster são removidas. Você precisa executar essa fase quando tem que remover um nóde armazenamento do cluster. Para obter detalhes, consulte o Livro “Guia de Administração”,

Capítulo 2 “Administração do cluster do Salt”, Seção 2.3 “Removendo e reinstalando nós do cluster”.

5.2.1 Organização e locais importantes

O Salt tem vários locais padrão e diversas convenções de nomeação usados no nó master:

/srv/pillar

O diretório armazena os dados de conguração para os minions do cluster. Pillar é umainterface que fornece valores globais de conguração a todos os minions do seu cluster.

/srv/salt/

O diretório armazena os arquivos de estado do Salt (também denominados sls). Os arquivosde estado são descrições formatadas dos estados em que o cluster deve estar.

/srv/module/runners

29 Organização e locais importantes SES 6

O diretório armazena os scripts do Python conhecidos como executores. Eles sãoexecutados no nó master.

/srv/salt/_modules

O diretório armazena os scripts do Python que são chamados de módulos. Os módulos sãoaplicados a todos os minions no seu cluster.

/srv/pillar/ceph

O diretório é usado pelo DeepSea. Os dados de conguração coletados são armazenadosnele.

/SRV/salt/ceph

Um diretório usado pelo DeepSea. Ele armazena arquivos sls que podem estar em formatosdiferentes, mas cada subdiretório contém arquivos sls. Cada subdiretório contém apenasum tipo de arquivo sls. Por exemplo, /srv/salt/ceph/stage contém os arquivos deorquestração que são executados por salt-run state.orchestrate .

5.2.2 Direcionando os minions

Os comandos do DeepSea são executados pela infraestrutura do Salt. Ao usar o comando salt ,você precisa especicar um conjunto de minions Salt afetados pelo comando. Descrevemos oconjunto de minions como destino para o comando salt . As seções a seguir descrevem osmétodos possíveis para direcionar os minions.

5.2.2.1 Correspondendo o nome do minion

Você pode direcionar um minion ou um grupo de minions correspondendo os nomes deles.Normalmente, o nome de um minion é o nome de host curto do nó onde o minion é executado.Trata-se de um método de direcionamento geral do Salt que não está relacionado ao DeepSea.Você pode usar glob, expressões regulares ou listas para limitar a faixa de nomes de minion.Veja a seguir a sintaxe geral:

root@master # salt target example.module

Dica: Cluster apenas do CephSe todos os minions Salt em seu ambiente pertencerem ao cluster do Ceph, você poderásubstituir com segurança o destino por '*' para incluir todos os minions registrados.

30 Direcionando os minions SES 6

Corresponder todos os minions no domínio example.net (considerando que os nomes dosminions sejam idênticos aos nomes de host "completos" deles):

root@master # salt '*.example.net' test.ping

Corresponder o minion “web1” ao “web5”:

root@master # salt 'web[1-5]' test.ping

Corresponder tanto o minion “web1-prod” quanto “web1-devel” usando uma expressão regular:

root@master # salt -E 'web1-(prod|devel)' test.ping

Corresponder uma lista simples de minions:

root@master # salt -L 'web1,web2,web3' test.ping

Corresponder todos os minions no cluster:

root@master # salt '*' test.ping

5.2.2.2 Direcionando com um grain do DeepSea

Em um ambiente heterogêneo gerenciado pelo Salt, em que o SUSE Enterprise Storage 6 éimplantado em um subconjunto de nós juntamente com outras soluções de cluster, você precisamarcar os minions relevantes aplicando um grain "deepsea" a eles antes de executar a fase 0 doDeepSea. Dessa forma, você pode direcionar facilmente os minions do DeepSea nos ambientesem que a correspondência por nome do minion é problemática.

Para aplicar o grain “deepsea” a um grupo de minions, execute:

root@master # salt target grains.append deepsea default

Para remover o grain “deepsea” de um grupo de minions, execute:

root@master # salt target grains.delval deepsea destructive=True

Após aplicar o grain “deepsea” aos minions relevantes, você poderá direcioná-los da seguintemaneira:

root@master # salt -G 'deepsea:*' test.ping

O comando a seguir é um equivalente:

root@master # salt -C 'G@deepsea:*' test.ping

31 Direcionando os minions SES 6

5.2.2.3 Definir a opção deepsea_minions

A denição do destino da opção deepsea_minions é um requisito para as implantações doDeepSea. O DeepSea a utiliza para instruir os minions durante a execução das fases (consulteDescrição das fases do DeepSea para obter detalhes).

Para denir ou mudar a opção deepsea_minions , edite o arquivo /srv/pillar/ceph/

deepsea_minions.sls no master Salt e adicione ou substitua a seguinte linha:

deepsea_minions: target

Dica: Destino de deepsea_minionsComo destino para a opção deepsea_minions , você pode usar qualquer método dedirecionamento: tanto Correspondendo o nome do minion quanto Direcionando com um grain

do DeepSea.

Corresponder todos os minions Salt no cluster:

deepsea_minions: '*'

Corresponder todos os minions com o grain “deepsea”:

deepsea_minions: 'G@deepsea:*'

5.2.2.4 Para obter mais informações

Você pode usar métodos mais avançados para direcionar minions por meio da infraestrutura doSalt. A página de manual do “deepsea-minions” apresenta mais detalhes sobre direcionamentodo DeepSea ( man 7 deepsea_minions ).

5.3 Implantação do clusterO processo de implantação do cluster tem várias fases. Primeiramente, você precisa preparartodos os nós do cluster congurando o Salt e, em seguida, implantar e congurar o Ceph.

32 Implantação do cluster SES 6

Dica: Implantando nós do monitor sem definir perfis de OSDSe você precisa ignorar a denição de funções de armazenamento para o OSD, conformedescrito na Seção  5.5.1.2, “Atribuição de função”, e implantar primeiro os nós do CephMonitor, dena a variável DEV_ENV .

Isso permite implantar monitores sem a presença do diretório role-storage/ eimplantar um cluster do Ceph com pelo menos uma função de armazenamento, monitore gerenciador.

Para denir a variável de ambiente, habilite-a globalmente congurando-a no arquivo /srv/pillar/ceph/stack/global.yml ou dena-a apenas para a sessão do shell atual:

root@master # export DEV_ENV=true

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

DEV_ENV: True

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

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

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

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

3. Dena as congurações de rede incluindo a resolução de nome DNS em cadanó. O master Salt e todos os minions Salt necessários para resolução entre elespor meio dos nomes de host. Para obter mais informações sobre como conguraruma rede, consulte https://www.suse.com/documentation/sles-15/book_sle_admin/data/

33 Implantação do cluster SES 6

sec_network_yast.html . Para obter mais informações sobre como congurar umservidor DNS, consulte https://www.suse.com/documentation/sles-15/book_sle_admin/

data/cha_dns.html .

4. Selecione um ou mais servidores de horário/pools e sincronize o horário local com eles.Verique se o serviço de sincronização de horário está habilitado em cada inicializaçãodo sistema. É possível usar o comando yast ntp-client incluído em um pacote yast2-ntp-client para congurar a sincronização de horário.

DicaAs máquinas virtuais não são fontes conáveis de NTP.

Encontre mais informações sobre como congurar o NTP em https://www.suse.com/

documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html .

5. Instale os pacotes salt-master e salt-minion no nó master Salt:

root@master # zypper in salt-master salt-minion

Verique se o serviço salt-master está habilitado e foi iniciado. Se necessário, habilite-o e inicie-o:

root@master # systemctl enable salt-master.serviceroot@master # systemctl start salt-master.service

6. Se você pretende usar um rewall, verique se o nó master Salt tem as portas 4505 e 4506abertas para todos os nós do minion Salt. Se as portas estiverem fechadas, você poderáabri-las usando o comando yast2 firewall e permitindo o serviço SaltStack.

Atenção: Falha nas fases do DeepSea com firewallHá falha nas fases de implantação do DeepSea quando o rewall está ativo (e atécongurado). Para percorrer as fases corretamente, você precisa desativar o rewallexecutando

root # systemctl stop firewalld.service

34 Implantação do cluster SES 6

ou denir a opção FAIL_ON_WARNING como “False” em /srv/pillar/ceph/

stack/global.yml :

FAIL_ON_WARNING: False

7. Instale o pacote salt-minion em todos os nós do minion.

root@minion > zypper in salt-minion

Verique se o nome de domínio completo e qualicado de cada nó pode ser resolvido parao endereço IP da rede pública por todos os outros nós.

8. Congure todos os minions (incluindo o minion master) para conectar-se ao master. Se omaster Salt não puder ser acessado pelo nome de host salt , edite o arquivo /etc/salt/minion ou crie um novo arquivo /etc/salt/minion.d/master.conf com o seguinteconteúdo:

master: host_name_of_salt_master

Se você efetuou quaisquer mudanças nos arquivos de conguração mencionados acima,reinicie o serviço Salt em todos os minions Salt:

root@minion > systemctl restart salt-minion.service

9. Verique se o serviço salt-minion está habilitado e foi iniciado em todos os nós. Senecessário, habilite-o e inicie-o:

root # systemctl enable salt-minion.serviceroot # systemctl start salt-minion.service

10. Verique a impressão digital de cada minion Salt e aceite todas as chaves do Salt no masterSalt se as impressões digitais forem correspondentes.

NotaSe a impressão digital do minion Salt retornar vazia, verique se o minion Salt temuma conguração do master Salt e pode se comunicar com o master Salt.

35 Implantação do cluster SES 6

Ver a impressão digital de cada minion:

root@master # salt-call --local key.fingerlocal:3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

Após coletar as impressões digitais de todos os minions Salt, liste as impressões digitaisde todas as chaves de minion não aceitas no master Salt:

root@master # salt-key -F[...]Unaccepted Keys:minion1:3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

Se houver correspondência de impressões digitais dos minions, aceite-as:

root@master # salt-key --accept-all

11. Verique se as chaves foram aceitas:

root@master # salt-key --list-all

12. Antes de implantar o SUSE Enterprise Storage 6, limpe (zap) manualmente todos os discos.Lembre-se de substituir “X” pela letra correta do disco:

a. Pare todos os processos que estão usando o disco especíco.

b. Verique se alguma partição no disco está montada e, se necessário, desmonte-a.

c. Se o disco for gerenciado por LVM, desative e apague toda a infraestruturado LVM. Consulte https://www.suse.com/documentation/sles-15/book_storage/data/

cha_lvm.html para obter mais detalhes.

d. Se o disco zer parte do RAID MD, desative o RAID. Consulte https://www.suse.com/

documentation/sles-15/book_storage/data/part_software_raid.html para obter maisdetalhes.

36 Implantação do cluster SES 6

e. Dica: Reinicializando o servidorSe você receber mensagens de erro, como “partition in use” ou “kernelcannot be updated with the new partition table” durante as etapas seguintes,reinicialize o servidor.

Limpe o começo de cada partição (como root ):

for partition in /dev/sdX[0-9]*do dd if=/dev/zero of=$partition bs=4096 count=1 oflag=directdone

f. Limpe o começo da unidade:

root # dd if=/dev/zero of=/dev/sdX bs=512 count=34 oflag=direct

g. Limpe o m da unidade:

root # dd if=/dev/zero of=/dev/sdX bs=512 count=33 \ seek=$((`blockdev --getsz /dev/sdX` - 33)) oflag=direct

h. Verique se a unidade está vazia (sem estruturas de GPT) usando:

root # parted -s /dev/sdX print free

ou

root # dd if=/dev/sdX bs=512 count=34 | hexdump -Croot # dd if=/dev/sdX bs=512 count=33 \ skip=$((`blockdev --getsz /dev/sdX` - 33)) | hexdump -C

13. Opcionalmente, se você precisar predenir as congurações de rede do cluster antesda instalação do pacote deepsea , crie /srv/pillar/ceph/stack/ceph/cluster.ymlmanualmente e dena as opções cluster_network: e public_network: . Observe queo arquivo não será sobregravado após a instalação do deepsea .

37 Implantação do cluster SES 6

Dica: Habilitação do IPv6Se você precisar habilitar endereçamento de rede IPv6, consulte a Seção  7.2.1,

“Habilitando o IPv6 para implantação de cluster do Ceph”

14. Instale o DeepSea no nó master Salt:

root@master # zypper in deepsea

15. O valor do parâmetro master_minion é derivado dinamicamente do arquivo /etc/salt/minion_id no master Salt. Se você precisar anular o valor descoberto, edite o arquivo /srv/pillar/ceph/stack/global.yml e dena um valor relevante:

master_minion: MASTER_MINION_NAME

Se o master Salt for acessível por mais nomes de host, use o nome do minion Salt parao cluster de armazenamento, conforme retornado pelo comando salt-key -L . Se vocêusou o nome de host padrão para o seu master Salt (salt) no domínio ses, o arquivo temesta aparência:

master_minion: salt.ses

Agora você pode implantar e congurar o Ceph. A menos que especicado de outra forma, todasas etapas são obrigatórias.

Nota: Convenções do comando saltHá duas maneiras possíveis de executar salt-run state.orch : uma é com“stage. STAGE_NUMBER ”, a outra é com o nome da fase. As duas notações têm o mesmoimpacto, e você decide qual comando usar de acordo com a sua preferência.

PROCEDIMENTO 5.1: EXECUTANDO AS FASES DE IMPLANTAÇÃO

1. Verique se os minions Salt que pertencem ao cluster do Ceph estãocorretamente direcionados com a opção deepsea_minions em /srv/pillar/ceph/deepsea_minions.sls . Consulte a Seção 5.2.2.3, “Definir a opção deepsea_minions” paraobter mais informações.

38 Implantação do cluster SES 6

2. Por padrão, o DeepSea implanta os clusters do Ceph com pers ajustados ativos nos nós doCeph Monitor, Ceph Manager e Ceph OSD. Em alguns casos, você pode precisar implantarsem os pers ajustados. Para fazer isso, insira as seguintes linhas no /srv/pillar/ceph/stack/global.yml antes de executar as fases do DeepSea:

alternative_defaults: tuned_mgr_init: default-off tuned_mon_init: default-off tuned_osd_init: default-off

3. Opcional: crie subvolumes Btrfs para /var/lib/ceph/ . Esta etapa precisa ser executadaantes da fase 0 do DeepSea. Para migrar os diretórios existentes ou obter mais detalhes,consulte o Livro “Guia de Administração”, Capítulo 25 “Dicas e truques”, Seção 25.6 “Subvolume

Btrfs para /var/lib/ceph em nós do Ceph Monitor”.Aplique os seguintes comandos a cada um dos minions Salt:

root@master # salt 'MONITOR_NODES' saltutil.sync_allroot@master # salt 'MONITOR_NODES' state.apply ceph.subvolume

NotaO comando Ceph.subvolume cria /var/lib/ceph como um subvolume Btrfs @/var/lib/ceph .

Agora, o novo subvolume está montado e /etc/fstab está atualizado.

4. Prepare o cluster. Consulte Descrição das fases do DeepSea para obter mais detalhes.

root@master # salt-run state.orch ceph.stage.0

ou

root@master # salt-run state.orch ceph.stage.prep

39 Implantação do cluster SES 6

Nota: Executar ou monitorar fases usando a CLI doDeepSeaAo usar a CLI do DeepSea, você pode acompanhar o andamento da execução dafase em tempo real, seja executando a CLI do DeepSea no modo de monitoramentoou executando a fase diretamente na CLI do DeepSea. Para obter detalhes, consultea Seção 5.4, “CLI do DeepSea”.

5. A fase de descoberta coleta dados de todos os minions e cria fragmentos de conguraçãoque são armazenados no diretório /srv/pillar/ceph/proposals . Os dados sãoarmazenados no formato YAML em arquivos *.sls ou *.yml.Execute o seguinte comando para acionar a fase de descoberta:

root@master # salt-run state.orch ceph.stage.1

ou

root@master # salt-run state.orch ceph.stage.discovery

6. Após a conclusão bem-sucedida do comando anterior, crie um arquivo policy.cfgem /srv/pillar/ceph/proposals . Para obter detalhes, consulte a Seção 5.5.1, “Arquivo

policy.cfg”.

DicaSe você tiver que mudar a conguração de rede do cluster, edite /srv/

pillar/ceph/stack/ceph/cluster.yml e ajuste as linhas que começam comcluster_network: e public_network: .

7. A fase de conguração analisa o arquivo policy.cfg e funde os arquivos incluídos emseu formato nal. O cluster e o conteúdo relacionado à função são armazenados em /srv/pillar/ceph/cluster , enquanto o conteúdo especíco do Ceph é armazenado em/srv/pillar/ceph/stack/default .Execute o seguinte comando para acionar a fase de conguração:

root@master # salt-run state.orch ceph.stage.2

ou

40 Implantação do cluster SES 6

root@master # salt-run state.orch ceph.stage.configure

A etapa de conguração pode levar mais tempo. Após a conclusão do comando, vocêpoderá ver os dados do pillar referentes aos minions especicados (por exemplo,denominados ceph_minion1 , ceph_minion2 , etc.) executando:

root@master # salt 'ceph_minion*' pillar.items

Dica: Modificação do Layout do OSDPara modicar o layout do OSD padrão e mudar a conguração dos grupos deunidades, siga o procedimento descrito na Seção 5.5.2, “DriveGroups”.

Nota: Substituindo padrõesLogo após a conclusão do comando, você poderá ver a conguração padrão e mudá-la de acordo com as suas necessidades. Para obter detalhes, consulte o Capítulo 7,

Personalizando a configuração padrão.

8. Agora você pode executar a fase de implantação. Nesta fase, o pillar é validado, e osdaemons Ceph Monitor e Ceph OSD são iniciados:

root@master # salt-run state.orch ceph.stage.3

ou

root@master # salt-run state.orch ceph.stage.deploy

O comando pode levar algum tempo. Se ele falhar, você precisará corrigir o problema eexecutar novamente as fases anteriores. Depois que o comando for bem-sucedido, executeo seguinte para vericar o status:

cephadm@adm > ceph -s

41 Implantação do cluster SES 6

9. A última etapa da implantação do cluster do Ceph é a fase de serviços. Nessa etapa, vocêinstancia qualquer um dos serviços suportados atualmente: iSCSI Gateway, CephFS, ObjectGateway, e NFS Ganesha. Nessa fase, os pools necessários, os chaveiros de autorização eos serviços de inicialização são criados. Para iniciar a fase, execute o seguinte:

root@master # salt-run state.orch ceph.stage.4

ou

root@master # salt-run state.orch ceph.stage.services

Dependendo da conguração, o comando pode ser executado por muito tempo.

10. Antes de continuar, recomendamos enfaticamente habilitar o módulo de telemetria doCeph. Para obter mais informações e instruções, consulte o Livro “Guia de Administração”,

Capítulo 10 “Módulos do Ceph Manager”, Seção 10.2 “Módulo de telemetria”.

5.4 CLI do DeepSeaO DeepSea também fornece uma ferramenta de interface de linha de comando (CLI, commandline interface) que permite ao usuário monitorar ou executar as fases enquanto visualiza oandamento da execução em tempo real. Verique se o pacote deepsea-cli está instalado antesde clicar no executável deepsea .

Dois modos são suportados para visualização do andamento da execução de uma fase:

MODOS DA CLI DO DEEPSEA

Modo de monitoramento: visualiza o andamento da execução de uma fase do DeepSeaacionada pelo comando salt-run emitido em outra sessão de terminal.

Modo independente: executa uma fase do DeepSea enquanto permite a visualização emtempo real das etapas de seus componentes conforme são executadas.

Importante: Comandos da CLI do DeepSeaApenas é possível executar os comandos da CLI do DeepSea no nó master Salt, com osprivilégios de root .

42 CLI do DeepSea SES 6

5.4.1 CLI do DeepSea: Modo monitor

O monitor de andamento apresenta uma visualização detalhada em tempo real do que acontecedurante a execução das fases usando os comandos salt-run state.orch em outras sessõesde terminal.

Dica: Iniciar o Monitor em uma Nova Sessão do TerminalÉ necessário iniciar o monitor em uma nova janela do terminal antes de executar qualquersalt-run state.orch para que o monitor possa detectar o início da execução da fase.

Se você iniciar o monitor após a emissão do comando salt-run state.orch , não será exibidonenhum andamento da execução.

É possível iniciar o modo monitor executando o seguinte comando:

root@master # deepsea monitor

Para obter mais informações sobre as opções de linha de comando disponíveis do deepseamonitor , consulte a página de manual dele:

root@master # man deepsea-monitor

5.4.2 CLI do DeepSea: Modo independente

No modo independente, é possível usar a CLI do DeepSea para executar uma fase dele, mostrandoa execução em tempo real.

O comando para executar uma fase do DeepSea pela CLI tem o seguinte formato:

root@master # deepsea stage run stage-name

em que stage-name corresponde ao modo como os arquivos de estado da orquestração doSalt são referenciados. Por exemplo, a fase deploy (implantação), que corresponde ao diretóriolocalizado em /srv/salt/ceph/stage/deploy , é referenciada como ceph.stage.deploy.

Esse comando é uma alternativa aos comandos com base no Salt para execução das fases doDeepSea (ou de qualquer arquivo de estado da orquestração do DeepSea).

O comando deepsea stage run ceph.stage.0 equivale ao salt-run state.orchceph.stage.0 .

43 CLI do DeepSea: Modo monitor SES 6

Para obter mais informações sobre as opções de linha de comando disponíveis que são aceitaspelo comando deepsea stage run , consulte a página de manual dele:

root@master # man deepsea-stage run

Na gura a seguir, há um exemplo da saída da CLI do DeepSea durante a execução da Fase 2:

FIGURA 5.1: SAÍDA DO ANDAMENTO DA EXECUÇÃO DA FASE DA CLI DO DEEPSEA

5.4.2.1 Álias stage run da CLI do DeepSea

Para usuários avançados do Salt, também oferecemos suporte a um álias para execução de umafase do DeepSea que aplica o comando Salt usado para executar uma fase, por exemplo, salt-run state.orch stage-name , como um comando da CLI do DeepSea.

Exemplo:

root@master # deepsea salt-run state.orch stage-name

44 CLI do DeepSea: Modo independente SES 6

5.5 Configuração e personalização

5.5.1 Arquivo policy.cfg

O arquivo de conguração /srv/pillar/ceph/proposals/policy.cfg é usado paradeterminar as funções dos nós individuais do cluster. Por exemplo, quais nós atuam como CephOSDs ou Ceph Monitors. Edite o policy.cfg para reetir a conguração desejada do cluster.A ordem das seções é arbitrária, mas o conteúdo das linhas incluídas sobregrava as chavescorrespondentes do conteúdo das linhas anteriores.

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

5.5.1.1 Atribuição de cluster

Na seção do cluster, selecione os respectivos minions. Você pode selecionar todos os minionsou incluí-los na lista negra ou na lista de permissões. Veja a seguir exemplos para um clusterdenominado ceph.

Para incluir todos os minions, adicione as seguintes linhas:

cluster-ceph/cluster/*.sls

Para incluir um minion especíco na lista de permissões:

cluster-ceph/cluster/abc.domain.sls

ou um grupo de minions, você pode usar a correspondência de globbing do shell:

cluster-ceph/cluster/mon*.sls

Para incluir minions na lista negra, dena-os como unassigned :

cluster-unassigned/cluster/client*.sls

45 Configuração e personalização SES 6

5.5.1.2 Atribuição de função

Esta seção apresenta detalhes sobre como atribuir “funções” a nós do cluster. Neste contexto,uma “função” signica o serviço que você precisa executar no nó, como Ceph Monitor, ObjectGateway, ou iSCSI Gateway. Nenhuma função é atribuída automaticamente, apenas as funçõesadicionadas ao policy.cfg serão implantadas.

A atribuição segue este padrão:

role-ROLE_NAME/PATH/FILES_TO_INCLUDE

Em que os itens têm o signicado e os valores a seguir:

ROLE_NAME é qualquer um destes valores: “master”, “admin”, “mon”, “mgr”, “storage”,“mds”, “igw”, “rgw”, “ganesha”, “grafana” ou “prometheus”.

PATH é um caminho de diretório relativo para os arquivos .sls ou .yml. No caso dearquivos .sls, ele costuma ser cluster , já os arquivos .yml estão localizados em stack/default/ceph/minions .

FILES_TO_INCLUDE são os arquivos de estado do Salt ou os arquivos de conguraçãoYAML. Normalmente, eles são compostos de nomes de host de minions Salt. Por exemplo,ses5min2.yml . É possível usar o globbing do shell para correspondência mais especíca.

Veja a seguir um exemplo para cada função:

master: o nó tem chaveiros de admin para todos os clusters do Ceph. Atualmente, apenas umúnico cluster do Ceph é suportado. Como a função master é obrigatória, adicione sempreuma linha semelhante ao seguinte:

role-master/cluster/master*.sls

admin: o minion terá um chaveiro de admin. Dena as funções da seguinte forma:

role-admin/cluster/abc*.sls

mon: o minion fornecerá o serviço de monitor ao cluster do Ceph. Essa função requer osendereços dos minions atribuídos. A partir do SUSE Enterprise Storage 5, os endereçospúblicos são calculados dinamicamente e não são mais necessários no pillar do Salt.

role-mon/cluster/mon*.sls

O exemplo atribui a função de monitor a um grupo de minions.

46 Arquivo policy.cfg SES 6

mgr: o daemon Ceph Manager que coleta todas as informações de estado do cluster inteiro.Implante-o em todos os minions nos quais você pretende implantar a função Ceph Monitor.

role-mgr/cluster/mgr*.sls

storage: use essa função para especicar nós de armazenamento.

role-storage/cluster/data*.sls

mds: o minion fornecerá o serviço de metadados para oferecer suporte ao CephFS.

role-mds/cluster/mds*.sls

igw: o minion atuará como iSCSI Gateway. Essa função requer os endereços dos minionsatribuídos, portanto, você também precisa incluir os arquivos do diretório stack :

role-igw/cluster/*.sls

rgw:: o minion atuará como Object Gateway:

role-rgw/cluster/rgw*.sls

ganesha: o minion atuará como servidor NFS Ganesha. A função “ganesha” requer umafunção “rgw” ou “mds” no cluster; do contrário, haverá falha na validação na Fase 3.

role-ganesha/cluster/ganesha*.sls

Para instalar o NFS Ganesha com êxito, é necessária uma conguração adicional. Para usaro NFS Ganesha, leia o Capítulo 12, Instalação do NFS Ganesha antes de executar as fases 2 e4. No entanto, é possível instalar o NFS Ganesha posteriormente.Em alguns casos, ele pode ser útil para denir funções personalizadas para os nós do NFSGanesha. Para obter os detalhes, consulte o Livro “Guia de Administração”, Capítulo 21 “NFS

Ganesha: Exportar dados do Ceph pelo NFS”, Seção 21.3 “Funções personalizadas do NFS Ganesha”.

grafana, prometheus: esse nó adiciona grácos do Grafana com base nos alertas doPrometheus ao Ceph Dashboard. Consulte o Livro “Guia de Administração”, Capítulo 22 “Ceph

Dashboard” para ver a descrição detalhada.

role-grafana/cluster/grafana*.sls

role-prometheus/cluster/prometheus*.sls

47 Arquivo policy.cfg SES 6

Nota: Várias funções dos nós do clusterÉ possível atribuir várias funções a um único nó. Por exemplo, você pode atribuir asfunções “mds” aos nós do monitor:

role-mds/cluster/mon[1,2]*.sls

5.5.1.3 Configuração comum

A seção de conguração comum inclui arquivos de conguração gerados durante adescoberta (Fase 1). Esses arquivos de conguração armazenam parâmetros como fsid oupublic_network . Para incluir a conguração comum necessária do Ceph, adicione as seguinteslinhas:

config/stack/default/global.ymlconfig/stack/default/ceph/cluster.yml

5.5.1.4 Filtragem de itens

Nem sempre é prático incluir todos os arquivos de determinado diretório com globbing *.sls. Oanalisador de arquivos policy.cfg reconhece os seguintes ltros:

Atenção: Técnicas avançadasEsta seção descreve as técnicas de ltragem para os usuários avançados. Quando nãousada corretamente, a ltragem pode causar problemas. Por exemplo, em caso demudança na numeração do nó.

slice=[start:end]

Use o ltro slice para incluir apenas os itens start até end-1. Observe que os itens emdeterminado diretório são classicados em ordem alfanumérica. A linha a seguir inclui doterceiro ao quinto arquivo do subdiretório role-mon/cluster/ :

role-mon/cluster/*.sls slice[3:6]

re=regexp

48 Arquivo policy.cfg SES 6

Use o ltro de expressão regular para incluir apenas os itens correspondentes às expressõesinseridas. Por exemplo:

role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$

5.5.1.5 Arquivo policy.cfg de exemplo

Veja a seguir um exemplo de um arquivo policy.cfg básico:

## Cluster Assignmentcluster-ceph/cluster/*.sls 1

## Roles# ADMINrole-master/cluster/examplesesadmin.sls 2

role-admin/cluster/sesclient*.sls 3

# MONrole-mon/cluster/ses-example-[123].sls 4

# MGRrole-mgr/cluster/ses-example-[123].sls 5

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

# MDSrole-mds/cluster/ses-example-4.sls 7

# IGWrole-igw/cluster/ses-example-4.sls 8

# RGWrole-rgw/cluster/ses-example-4.sls 9

# COMMONconfig/stack/default/global.yml 10

config/stack/default/ceph/cluster.yml 11

1 Indica que todos os minions estão incluídos no cluster do Ceph. Se você tem minions quenão deseja incluir no cluster do Ceph, use:

cluster-unassigned/cluster/*.slscluster-ceph/cluster/ses-example-*.sls

49 Arquivo policy.cfg SES 6

A primeira linha marca todos os minions como não atribuídos. A segunda linha anula osminions correspondentes a “ses-example-*.sls” e os atribui ao cluster do Ceph.

2 O minion chamado “examplesesadmin” tem a função “master”. A propósito, isso signicaque ele enviará chaves de admin ao cluster.

3 Todos os minions correspondentes a “sesclient*” também receberão chaves de admin.

4 Todos os minions correspondentes a “ses-example-[123]” (teoricamente três minions: ses-example-1, ses-example-2 e ses-example-3) serão congurados como nós MON.

5 Todos os minions correspondentes a “ses-example-[123]” (todos os nós MON no exemplo)serão congurados como nós MGR.

6 Todos os minions correspondentes a “ses-example-[5,6,7,8]” serão congurados como nósde armazenamento.

7 O minion “ses-example-4” terá a função MDS.

8 O minion “ses-example-4” terá a função IGW.

9 O minion “ses-example-4” terá a função RGW.

10 Signica que aceitamos os valores padrão para os parâmetros de conguração comum,como fsid e public_network .

11 Signica que aceitamos os valores padrão para os parâmetros de conguração comum,como fsid e public_network .

5.5.2 DriveGroups

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

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

50 DriveGroups SES 6

Veja a seguir um procedimento simples que demonstra o workow básico ao congurarDriveGroups:

1. Inspecione as propriedades dos discos conforme apresentado pelo comando ceph-volume .Apenas essas propriedades são aceitas pelos DriveGroups:

root@master # salt-run disks.details

2. Abra o arquivo YAML /srv/salt/ceph/configuration/files/drive_groups.yml eajuste-o conforme suas necessidades. Consulte a Seção 5.5.2.1, “Especificação”. Lembre-sede usar espaços em vez de tabulações. Há exemplos mais avançados na Seção  5.5.2.4,

“Exemplos”. O exemplo a seguir inclui todas as unidades disponíveis para o Ceph comoOSDs:

default_drive_group_name: target: '*' data_devices: all: true

3. Verique os novos layouts:

root@master # salt-run disks.list

Este executor retorna uma estrutura de discos correspondentes com base em seus gruposde unidades. Se você não car satisfeito com o resultado, repita a etapa anterior.

Dica: Relatório DetalhadoAlém do executor disks.list , há um executor disks.report que imprime umrelatório detalhado do que acontecerá ao invocar a fase 3 seguinte do DeepSea.

root@master # salt-run disks.report

4. Implante os OSDs. Na invocação da fase 3 seguinte do DeepSea, os discos OSD serãoimplantados de acordo com a especicação do grupo de unidades.

51 DriveGroups SES 6

5.5.2.1 Especificação

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

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

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

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

5.5.2.2 Correspondendo dispositivos de disco

Você pode descrever a especicação usando os seguintes ltros:

Por um modelo de disco:

model: DISK_MODEL_STRING

Por um fornecedor de disco:

vendor: DISK_VENDOR_STRING

Dica: String de Fornecedor em Letras MinúsculasSempre insira DISK_VENDOR_STRING em letras minúsculas.

52 DriveGroups SES 6

Se um disco é ou não rotacional. SSDs e unidades NVME não são rotacionais.

rotational: 0

Implante um nó usando todas as unidades disponíveis para OSDs:

data_devices: all: true

Limite também o número de discos correspondentes:

limit: 10

5.5.2.3 Filtrando dispositivos por tamanho

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

“10G”: Inclui discos de um tamanho exato.

“10G:40G”: Inclui discos cujo tamanho está dentro da faixa.

“:10G”: Inclui discos menores do que ou iguais a 10 GB.

“40G:”: Inclui discos iguais ou maiores do que 40 GB.

EXEMPLO 5.1: CORRESPONDÊNCIA POR TAMANHO DO DISCO

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

Nota: Aspas ObrigatóriasAo usar o delimitador “:”, você precisa colocar o tamanho entre aspas; do contrário, osinal “:” será interpretado como um novo hash de conguração.

53 DriveGroups SES 6

Dica: Atalhos de UnidadeEm vez de (G)igabytes, você também pode especicar os tamanhos em (M)egabytes ou(T)erabytes.

5.5.2.4 Exemplos

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

EXEMPLO 5.2: CONFIGURAÇÃO SIMPLES

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

20 HDDs

Fornecedor: Intel

Modelo: SSD-123-foo

Tamanho: 4 TB

2 SSDs

Fornecedor: Micron

Modelo: MC-55-44-ZX

Tamanho: 512 GB

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

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

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

drive_group_default: target: '*'

54 DriveGroups SES 6

data_devices: rotational: 1 db_devices: rotational: 0

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

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

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

EXEMPLO 5.3: CONFIGURAÇÃO AVANÇADA

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

20 HDDs

Fornecedor: Intel

Modelo: SSD-123-foo

Tamanho: 4 TB

12 SSDs

Fornecedor: Micron

Modelo: MC-55-44-ZX

Tamanho: 512 GB

2 NVMes

Fornecedor: Samsung

Modelo: NVME-QQQQ-987

Tamanho: 256 GB

55 DriveGroups SES 6

Essa conguração pode ser denida com dois layouts da seguinte maneira:

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

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

EXEMPLO 5.4: CONFIGURAÇÃO AVANÇADA COM NÓS NÃO UNIFORMES

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

Nós 1-5:

20 HDDs

Fornecedor: Intel

Modelo: SSD-123-foo

Tamanho: 4 TB

2 SSDs

Fornecedor: Micron

Modelo: MC-55-44-ZX

Tamanho: 512 GB

Nós 6-10:

5 NVMes

56 DriveGroups SES 6

Fornecedor: Intel

Modelo: SSD-123-foo

Tamanho: 4 TB

20 SSDs

Fornecedor: Micron

Modelo: MC-55-44-ZX

Tamanho: 512 GB

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

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

seguido de

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

EXEMPLO 5.5: CONFIGURAÇÃO TÉCNICA

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

20 HDDs

Fornecedor: Intel

Modelo: SSD-123-foo

Tamanho: 4 TB

2 SSDs

57 DriveGroups SES 6

Fornecedor: Micron

Modelo: MC-55-44-ZX

Tamanho: 512 GB

2 NVMes

Fornecedor: Samsung

Modelo: NVME-QQQQ-987

Tamanho: 256 GB

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

EXEMPLO 5.6: CONFIGURAÇÃO COMPLEXA (E IMPROVÁVEL)

Na conguração a seguir, tentamos denir:

20 HDDs com 1 NVMe

2 HDDs com 1 SSD(db) e 1 NVMe(wal)

8 SSDs com 1 NVMe

2 SSDs independentes (criptografados)

1 HDD é sobressalente e não deve ser implantado

Veja a seguir o resumo das unidades usadas:

23 HDDs

Fornecedor: Intel

Modelo: SSD-123-foo

Tamanho: 4 TB

10 SSDs

58 DriveGroups SES 6

Fornecedor: Micron

Modelo: MC-55-44-ZX

Tamanho: 512 GB

1 NVMe

Fornecedor: Samsung

Modelo: NVME-QQQQ-987

Tamanho: 256 GB

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

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

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

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

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

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

59 DriveGroups SES 6

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

Se você precisar incluir as congurações personalizadas no arquivo de conguração ceph.conf ,consulte o Livro “Guia de Administração”, Capítulo 2 “Administração do cluster do Salt”, Seção 2.13

“Ajustando o ceph.conf com configurações personalizadas” para obter mais detalhes.

60 Ajustando o ceph.conf com configurações personalizadas SES 6

6 Fazendo upgrade de versões anteriores

Este capítulo apresenta as etapas para fazer upgrade do SUSE Enterprise Storage 5.5 para aversão 6. Observe que a versão 5.5 é basicamente a versão 5 com todos os patches mais recentesaplicados.

Nota: Upgrade de Versões Mais Antigas Não SuportadoO upgrade de versões do SUSE Enterprise Storage mais antigas do que a 5.5 não ésuportado. Você precisa primeiro fazer upgrade para a versão mais recente do SUSEEnterprise Storage 5.5 e, em seguida, seguir as etapas neste capítulo.

6.1 Pontos de consideração antes do upgrade

Leia os detalhes da versão: onde você encontra mais informações sobre o que mudou desdea versão anterior do SUSE Enterprise Storage. Consulte os detalhes da versão para vericarse:

seu hardware precisa de considerações especiais.

qualquer pacote de software usado foi signicativamente modicado.

são necessárias precauções especiais para a instalação.

Os detalhes da versão também apresentam informações que não puderam ser incluídas atempo no manual. Eles também incluem notas sobre problemas conhecidos.Após instalar o pacote release-notes-ses , encontre os detalhes da versão no diretóriolocal /usr/share/doc/release-notes ou no site https://www.suse.com/releasenotes/ .

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

Verique a existência do arquivo

/srv/salt/ceph/configuration/files/ceph.conf.import

Ele é criado pelo processo de importação durante o upgrade do SES 4 para 5. A opçãoconfiguration_init: default-import também está denida no arquivo

61 Pontos de consideração antes do upgrade SES 6

/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml

Se configuration_init ainda está denido como default-import , o cluster usaceph.conf.import como arquivo de conguração, e não o ceph.conf padrão doDeepSea, que é compilado dos arquivos em

/srv/salt/ceph/configuration/files/ceph.conf.d/

Portanto, você precisa inspecionar se há qualquer conguração personalizada emceph.conf.import e, possivelmente, mover a conguração para um dos arquivosem

/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

Atenção: Configuração Padrão do DeepSeaSe você não fundir a conguração do ceph.conf.import e remover a opçãoconfiguration_init: default-import , nenhuma conguração padrão quezer parte do DeepSea (armazenada em /srv/salt/ceph/configuration/files/ceph.conf.j2 ) será aplicada ao cluster.

Verique se o cluster usa o novo tipo de compartimento de memória “straw2”:

cephadm@adm > ceph osd crush dump | grep straw

Verique se o perl “jewel” do Ceph foi usado:

cephadm@adm > ceph osd crush dump | grep profile

Caso os clientes RBD antigos do kernel (mais antigos do que o SUSE Linux EnterpriseServer 12 SP3) sejam usados, consulte o Livro “Guia de Administração”, Capítulo 12 “Dispositivo

de blocos RADOS”, Seção 12.9 “Mapeando o RBD por meio de clientes antigos do kernel”.Recomendamos fazer upgrade dos clientes RBD antigos do kernel, se possível.

Se o openATTIC estiver localizado no Nó de Admin, ele estará disponível após o upgrade donó. O novo Ceph Dashboard não estará disponível até você implantá-lo usando o DeepSea.

62 Pontos de consideração antes do upgrade SES 6

O upgrade do cluster pode levar algum tempo, aproximadamente o tempo necessário parafazer upgrade de uma máquina multiplicado pelo número de nós do cluster.

Não é possível fazer upgrade de um único nó durante a execução da versão anterior doSUSE Linux Enterprise Server, mas ele precisa ser reinicializado no instalador da novaversão. Portanto, os serviços que o nó fornece estarão indisponíveis por algum tempo. Osprincipais serviços do cluster ainda estarão disponíveis. Por exemplo, se um MON estiverinativo durante o upgrade, ainda haverá pelo menos dois MONs ativos. Os serviços deinstância única estarão indisponíveis. Por exemplo, um único iSCSI Gateway.

Alguns tipos de daemons dependem de outros. Por exemplo, os Ceph Object Gatewaysdependem dos daemons Ceph MON e OSD. Recomendamos o upgrade nesta ordem:

1. Nó de Admin

2. Ceph Monitors/Ceph Managers

3. Servidores de Metadados

4. Ceph OSDs

5. Object Gateways

6. iSCSI Gateways

7. NFS Ganesha

8. Gateways do Samba

Se você usou o AppArmor no modo "complain" ou "enforce", precisa denir uma variáveldo pillar Salt antes do upgrade. Como o SUSE Linux Enterprise Server 15 SP1 está incluídocom o AppArmor por padrão, o gerenciamento do AppArmor foi integrado à fase 0 doDeepSea. O comportamento padrão no SUSE Enterprise Storage 6 é remover o AppArmore os pers relacionados. Para manter o comportamento congurado no SUSE EnterpriseStorage 5.5, verique se uma das seguintes linhas está presente no arquivo /srv/pillar/ceph/stack/global.yml antes de iniciar o upgrade:

apparmor_init: default-enforce

ou

63 Pontos de consideração antes do upgrade SES 6

apparmor_init: default-complain

A partir do SUSE Enterprise Storage 6, os nomes de MDS que começam com um dígito nãosão mais permitidos, e os daemons MDS se recusarão a ser iniciados. Você pode vericarse seus daemons têm esses nomes executando o comando ceph fs status ou reiniciandoum MDS e vericando a seguinte mensagem nos registros dele:

deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden ina future version. MDS names may not start with a numeric digit.

Se aparecer a mensagem acima, os nomes de MDS precisarão ser migrados antes de tentarfazer upgrade para o SUSE Enterprise Storage 6. O DeepSea inclui uma orquestraçãopara automatizar esse tipo de migração. Os nomes de MDS que começam com um dígitoreceberão o prexo “mds”.:

root@master # salt-run state.orch ceph.mds.migrate-numerical-names

Dica: Configuração Personalizada Vinculada a Nomes MDSSe você tem congurações vinculadas a nomes MDS e seus daemons MDS têm nomesque começam com um dígito, verique se as congurações também se aplicam aosnovos nomes (com o prexo “mds”). Considere a seguinte seção de exemplo noarquivo /etc/ceph/ceph.conf :

[mds.123-my-mds] # config setting specific to MDS name with a name starting with a digitmds cache memory limit = 1073741824mds standby for name = 456-another-mds

O orquestrator ceph.mds.migrate-numerical-names mudará o nome do daemonMDS “123-my-mds” para “mds.123-my-mds”. Você precisa ajustar a conguraçãopara reetir o novo nome:

[mds.mds,123-my-mds] # config setting specific to MDS name with the new namemds cache memory limit = 1073741824mds standby for name = mds.456-another-mds

64 Pontos de consideração antes do upgrade SES 6

Esse procedimento adicionará os daemons MDS com os novos nomes antes de remover osdaemons MDS antigos. O número de daemons MDS será o dobro por um curto período. Osclientes poderão acessar o CephFS com uma breve pausa para failover. Portanto, planejea migração para momentos em que você espera pouca ou nenhuma carga do CephFS.

6.2 Fazendo backup de dados do clusterEmbora a criação de backups da conguração e dos dados de um cluster não seja obrigatória,recomendamos enfaticamente o backup de arquivos de conguração e dados do clusterimportantes. Consulte a Livro “Guia de Administração”, Capítulo 3 “Fazendo backup da configuração e

dos dados do cluster” para obter mais detalhes.

6.3 Migrando do ntpd para o chronydO SUSE Linux Enterprise Server 15 SP1 não usa mais o ntpd para sincronizar o horário localdo host. Em vez disso, ele usa o chronyd . Você precisa migrar o daemon de sincronização dehorário em cada nó do cluster. Você pode migrar para o chronyd antes do cluster ou fazerupgrade do cluster e, depois disso, migrar para o chronyd .

PROCEDIMENTO 6.1: MIGRAR PARA O chronyd ANTES DO UPGRADE DO CLUSTER

1. Instale o pacote chrony :

root@minion > zypper install chrony

2. Edite o arquivo de conguração do chronyd /etc/chrony.conf e adicione fontes deNTP da conguração atual do ntpd ao /etc/ntp.conf .

Dica: Mais Detalhes sobre a Configuração do chronydVisite https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html

para encontrar mais detalhes sobre como incluir fontes de horário na conguraçãodo chronyd .

3. Desabilite e pare o serviço ntpd :

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

65 Fazendo backup de dados do cluster SES 6

4. Inicie e habilite o serviço chronyd :

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

5. Verique o status do chrony:

root@minion > chronyc tracking

PROCEDIMENTO 6.2: MIGRAR PARA O chronyd APÓS O UPGRADE DO CLUSTER

1. Durante o upgrade do cluster, adicione os seguintes repositórios de software:

SLE-Module-Legacy15-SP1-Pool

SLE-Module-Legacy15-SP1-Updates

2. Faça upgrade do cluster para a versão 6.

3. Edite o arquivo de conguração do chronyd /etc/chrony.conf e adicione fontes deNTP da conguração atual do ntpd ao /etc/ntp.conf .

Dica: Mais Detalhes sobre a Configuração do chronydVisite https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html

para encontrar mais detalhes sobre como incluir fontes de horário na conguraçãodo chronyd .

4. Desabilite e pare o serviço ntpd :

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

5. Inicie e habilite o serviço chronyd :

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

6. Migre do ntpd para o chronyd .

7. Verique o status do chrony:

root@minion > chronyc tracking

8. Remova os repositórios de software legados que você adicionou para manter o ntpd nosistema durante o processo de upgrade.

66 Migrando do ntpd para o chronyd SES 6

6.4 Corrigindo o cluster antes do upgradeAplique os patches mais recentes a todos os nós do cluster antes do upgrade.

6.4.1 Repositórios de software necessários

Verique se os repositórios necessários estão congurados em cada nó do cluster. Para listartodos os repositórios disponíveis, execute

root@minion > zypper lr

O SUSE Enterprise Storage 5.5 requer:

SLES12-SP3-Installer-Updates

SLES12-SP3-Pool

SLES12-SP3-Updates

SUSE-Enterprise-Storage-5-Pool

SUSE-Enterprise-Storage-5-Updates

O Gateway NFS/SMB no SLE-HA no SUSE Linux Enterprise Server 12 SP3 requer:

SLE-HA12-SP3-Pool

SLE-HA12-SP3-Updates

6.4.2 Sistemas de propagação em fases do repositório

Se você estiver usando um dos sistemas de propagação em fases do repositório (SMT, RMT ouSUSE Manager), crie um novo nível de patch congelado para a versão atual e nova do SUSEEnterprise Storage.

Mais informações podem ser encontradas na:

https://www.suse.com/documentation/sles-12/book_smt/data/book_smt.html ,

https://www.suse.com/documentation/sles-15/book_rmt/data/book_rmt.html .

https://www.suse.com/documentation/suse-manager-3/index.html ,

67 Corrigindo o cluster antes do upgrade SES 6

6.4.3 Corrigindo o cluster inteiro com os patches mais recentes

1. Aplique os patches mais recentes do SUSE Enterprise Storage 5.5 e do SUSE LinuxEnterprise Server 12 SP3 a cada nó do cluster do Ceph. Verique se os repositórios desoftware corretos estão conectados a cada nó do cluster (consulte a Seção 6.4.1, “Repositórios

de software necessários”) e execute a fase 0 do DeepSea:

root@master # salt-run state.orch ceph.stage.0

2. Após a conclusão da fase 0, verique se o status de cada nó do cluster inclui “HEALTH_OK”.Se não incluir, resolva o problema antes das possíveis reinicializações nas próximas etapas.

3. Execute o zypper ps para vericar se há processos que possam ser executados combibliotecas ou binários desatualizados e, se houver, faça a reinicialização.

4. Verique se o kernel em execução é o mais recente disponível e, se não for, faça areinicialização. Verique as saídas dos seguintes comandos:

cephadm@adm > uname -acephadm@adm > rpm -qa kernel-default

5. Verique se o pacote ceph é da versão 12.2.12 ou mais recente. Verique se o pacotedeepsea é da versão 0.8.9 ou mais recente.

6. Se você já usou qualquer uma das congurações de bluestore_cache , elas nãoestão mais em vigor a partir do ceph versão 12.2.10. A nova conguraçãobluestore_cache_autotune que, por padrão, está denida como “true”, desabilita odimensionamento manual do cache. Para ativar o comportamento antigo, você precisadenir bluestore_cache_autotune=false . Consulte o Livro “Guia de Administração”,

Capítulo 16 “Configuração do cluster do Ceph”, Seção 16.2.1 “Dimensionamento automático do

cache” para obter os detalhes.

6.5 Verificando o ambiente atual

Se o sistema tiver problemas óbvios, corrija-os antes de iniciar o upgrade. O upgrade nuncacorrige problemas existentes do sistema.

Verique o desempenho do cluster. Você pode usar comandos, como rados bench , cephtell osd.* bench ou iperf3 .

68 Corrigindo o cluster inteiro com os patches mais recentes SES 6

Verique o acesso aos gateways (como iSCSI Gateway ou Object Gateway) e ao Dispositivode Blocos RADOS.

Registre partes especícas da conguração do sistema, como conguração de rede,particionamento ou detalhes da instalação.

Use o supportconfig para coletar informações importantes do sistema e grave-as forados nós do cluster. Mais informações podem ser encontradas em https://www.suse.com/

documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html .

Verique se há espaço livre suciente no disco em cada nó do cluster. Use o comandodf -h para vericar o espaço livre no disco. Quando necessário, libere espaço no discoremovendo arquivos/diretórios desnecessários ou removendo instantâneos obsoletos doOS. Se não houver espaço livre suciente no disco, não continue com o upgrade até liberarespaço suciente.

6.6 Verificando o estado do cluster

Use o comando cluster health para vericar a saúde do cluster antes de iniciar oprocedimento de upgrade. Não inicie o upgrade, exceto quando cada nó do cluster relatar“HEALTH_OK”.

Verique se todos os serviços estão em execução:

Master Salt e daemons do master Salt.

Daemons do Ceph Monitor e do Ceph Manager.

Daemons do Servidor de Metadados.

Daemons do Ceph OSD.

Daemons do Object Gateway.

Daemons do iSCSI Gateway.

Os seguintes comandos apresentam os detalhes do estado do cluster e a conguração especíca:

ceph -s

69 Verificando o estado do cluster SES 6

Imprime um breve resumo da saúde do cluster do Ceph, dos serviços em execução, do usode dados e das estatísticas de E/S. Verique se ele relata “HEALTH_OK” antes de iniciaro upgrade.

ceph health detail

Imprime os detalhes se a saúde do cluster do Ceph não estiver OK.

ceph versions

Imprime as versões dos daemons do Ceph em execução.

ceph df

Imprime o espaço total e livre do disco no cluster. Não inicie o upgrade se o espaço livreno disco do cluster for inferior a 25% do espaço total no disco.

salt '*' cephprocesses.check results=true

Imprime os processos em execução do Ceph e os respectivos PIDs classicados por minionsSalt.

ceph osd dump | grep ^flags

Verique se os ags "recovery_deletes" e "purged_snapdirs” estão presentes. Se nãoestiverem, você poderá forçar uma depuração de todos os grupos de posicionamentoexecutando o comando a seguir. Saiba que essa depuração forçada pode prejudicar odesempenho dos clientes Ceph.

cephadm@adm > ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub

6.7 Fazendo upgrade oine dos clusters CTDBO CTDB oferece um banco de dados em cluster usado pelos Gateways do Samba. O protocoloCTDB é muito simples e não suporta clusters de nós que se comunicam com diferentes versões deprotocolo. Portanto, os nós do CTDB precisam ser colocados oine antes de realizar um upgrade.

6.8 Fazendo upgrade por nó: procedimento básicoPara garantir que os principais serviços do cluster quem disponíveis durante o upgrade, vocêprecisa fazer upgrade dos nós do cluster um por um, em sequência. Há duas maneiras de executaro upgrade de um nó: usando o DVD do instalador ou o sistema de migração de distribuição.

70 Fazendo upgrade oine dos clusters CTDB SES 6

Após o upgrade de cada nó, recomendamos executar o rpmconfigcheck para vericar se háarquivos de conguração atualizados que foram editados localmente. Se o comando retornaruma lista de nomes de arquivo com um suxo .rpmnew , .rpmorig ou .rpmsave , compareesses arquivos com os arquivos de conguração atuais para garantir que nenhuma mudança localtenha sido perdida. Se necessário, atualize os arquivos afetados. Para obter mais informaçõessobre como trabalhar com arquivos .rpmnew , .rpmorig e .rpmsave , consulte https://

documentation.suse.com/sles/15-SP1/single-html/SLES-admin/#sec-rpm-packages-manage .

Dica: Pacotes ÓrfãosApós o upgrade de um nó, vários pacotes terão o estado “órfão” sem um repositório pai.Isso acontece porque os pacotes python3 relacionados não tornam os pacotes python2obsoletos.

Há mais informações sobre como listar pacotes órfãosdisponíveis no site https://www.suse.com/documentation/sles-15/book_sle_admin/data/

sec_zypper.html#sec_zypper_softup_orphaned .

6.8.1 Fazendo upgrade manual do nó por meio do DVD doinstalador

1. Reinicialize o nó usando o DVD/imagem do instalador do SUSE Linux Enterprise Server15 SP1.

2. Selecione Upgrade no menu de inicialização.

3. Na tela Selecionar o Destino da Migração, verique se “SUSE Linux Enterprise Server 15SP1” está selecionado e ative a caixa de seleção Ajustar Manualmente os Repositórios paraMigração.

71 Fazendo upgrade manual do nó por meio do DVD do instalador SES 6

FIGURA 6.1: SELECIONAR O DESTINO DA MIGRAÇÃO

4. Selecione os seguintes módulos para instalação:

SUSE Enterprise Storage 6 x86_64

Módulo Basesystem 15 SP1 x86_64

Módulo Desktop Applications 15 SP1 x86_64

Módulo Legacy 15 SP1 x86_64

Módulo Server Applications 15 SP1 x86_64

5. Na tela Repositórios Usados Anteriormente, verique se os repositórios corretos estãoselecionados. Se o sistema não foi registrado com SCC/SMT, você precisa adicionar osrepositórios manualmente.O SUSE Enterprise Storage 6 requer:

SLE-Module-Basesystem15-SP1-Pool

 SLE-Module-Basesystem15-SP1-Updates

 SLE-Module-Server-Applications15-SP1-Pool

 SLE-Module-Server-Applications15-SP1-Updates

72 Fazendo upgrade manual do nó por meio do DVD do instalador SES 6

SLE-Module-Desktop-Applications15-SP1-Pool

SLE-Module-Desktop-Applications15-SP1-Updates

 SLE-Product-SLES15-SP1-Pool

 SLE-Product-SLES15-SP1-Updates

 SLE15-SP1-Installer-Updates

 SUSE-Enterprise-Storage-6-Pool

 SUSE-Enterprise-Storage-6-Updates

Se você pretende migrar o ntpd para o chronyd após a migração do SES (consulte aSeção 6.3, “Migrando do ntpd para o chronyd”), inclua os seguintes repositórios:

SLE-Module-Legacy15-SP1-Pool

SLE-Module-Legacy15-SP1-Updates

O Gateway NFS/SMB no SLE-HA no SUSE Linux Enterprise Server 15 SP1 requer:

SLE-Product-HA15-SP1-Pool

SLE-Product-HA15-SP1-Updates

6. Revise as Congurações de Instalação e inicie o procedimento de instalação clicando emAtualizar.

6.8.2 Fazendo upgrade do nó por meio do SUSE DistributionMigration System

O Distribution Migration System (DMS) inclui um caminho de upgrade para um sistema SUSELinux Enterprise instalado de uma versão principal para outra. O procedimento a seguir utilizao DMS para fazer upgrade do SUSE Enterprise Storage 5.5 para a versão 6, incluindo a migraçãodo SUSE Linux Enterprise Server 12 SP3 subjacente para o SUSE Linux Enterprise Server 15 SP1.

Consulte https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/

distribution-migration-system/ para encontrar informações gerais e detalhadas sobre o DMS.

73 Fazendo upgrade do nó por meio do SUSE Distribution Migration System SES 6

1. Instale os pacotes RPM de migração. Eles ajustam o carregador de boot GRUB para acionarautomaticamente o upgrade na próxima reinicialização. Instale os pacotes SLES15-SES-Migration e suse-migration-sle15-activation :

root@minion > zypper install SLES15-SES-Migration suse-migration-sle15-activation

2. a. Se o nó do qual está sendo feito o upgrade foi registrado com um sistema depropagação em fases do repositório, como SCC, SMT, RMT ou SUSE Manager, crie o/etc/sle-migration-service.yml com o seguinte conteúdo:

use_zypper_migration: truepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules

b. Se o nó do qual está sendo feito o upgrade não foi registrado com um sistema depropagação em fases do repositório, como SCC, SMT, RMT ou SUSE Manager, façaas seguintes mudanças:

i. Crie o /etc/sle-migration-service.yml com o seguinte conteúdo:

use_zypper_migration: falsepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules

ii. Desabilite ou remova os repositórios SLE 12 SP3 e SES 5 e adicione osrepositórios SLE 15 SP1 e SES 6. Encontre a lista de repositórios relacionadosna Seção 6.4.1, “Repositórios de software necessários”.

3. Reinicialize para iniciar o upgrade. Durante a execução do upgrade, você podeefetuar login no nó do qual foi feito o upgrade com ssh como usuárioda migração utilizando a chave SSH existente do sistema host, conformedescrito em https://documentation.suse.com/suse-distribution-migration-system/1.0/single-

html/distribution-migration-system/ . Para o SUSE Enterprise Storage, se você tiver acessofísico ou acesso direto do console à máquina, poderá efetuar login como root no consoledo sistema usando a senha sesupgrade . O nó será reinicializado automaticamente apóso upgrade.

74 Fazendo upgrade do nó por meio do SUSE Distribution Migration System SES 6

Dica: Falha no upgradeSe houver falha no upgrade, inspecione o /var/log/distro_migration.log .Corrija o problema, reinstale os pacotes RPM de migração e reinicialize o nó.

6.9 Fazendo upgrade do nó de admin

Os seguintes comandos ainda funcionarão, embora os minions Salt estejam executandoversões antigas do Ceph e do Salt: salt '*' test.ping e ceph status

Após o upgrade do Nó de Admin, o openATTIC não será mais instalado.

Se o Nó de Admin hospedava o SMT, conclua a migração dele para o RMT (consulte https://

www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html ).

Siga o procedimento descrito na Seção  6.8, “Fazendo upgrade por nó: procedimento

básico”.

Dica: Status dos Nós do ClusterApós o upgrade do Nó de Admin, você poderá executar o comando salt-runupgrade.status para ver informações úteis sobre os nós do cluster. O comando lista asversões do Ceph e do OS de todos os nós e recomenda em que ordem fazer o upgrade dequaisquer nós que ainda executam versões antigas.

root@master # salt-run upgrade.statusThe newest installed software versions are: ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable) os: SUSE Linux Enterprise Server 15 SP1

Nodes running these software versions: admin.ceph (assigned roles: master) mon2.ceph (assigned roles: admin, mon, mgr)

Nodes running older software versions must be upgraded in the following order: 1: mon1.ceph (assigned roles: admin, mon, mgr) 2: mon3.ceph (assigned roles: admin, mon, mgr) 3: data1.ceph (assigned roles: storage)

75 Fazendo upgrade do nó de admin SES 6

[...]

6.10 Fazendo upgrade dos nós do Ceph Monitor/Ceph Manager

Se o cluster não usa funções MDS, faça upgrade dos nós MON/MGR um por um.

Se o cluster usa funções MDS, e as funções MON/MGR e MDS são colocalizadas, vocêprecisa reduzir o cluster MDS e, em seguida, fazer upgrade dos nós colocalizados. Consultea Seção 6.11, “Fazendo upgrade dos servidores de metadados” para obter mais detalhes.

Se o cluster usa funções MDS e elas são executadas em servidores dedicados, façaupgrade de todos os nós MON/MGR um por um, depois reduza e faça upgrade do clusterMDS. Consulte a Seção 6.11, “Fazendo upgrade dos servidores de metadados” para obter maisdetalhes.

Nota: Upgrade do Ceph MonitorEm virtude de uma limitação no projeto do Ceph Monitor, depois que é feito upgrade dedois MONs para o SUSE Enterprise Storage 6 e um quorum é formado, o terceiro MON(enquanto ainda está no SUSE Enterprise Storage 5.5) não reingressará no cluster MONse ele for reiniciado por qualquer motivo, incluindo uma reinicialização de nó. Portanto,quando é feito upgrade de dois MONs, a melhor opção é fazer upgrade dos demais oquanto antes.

Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento básico”.

6.11 Fazendo upgrade dos servidores de metadadosVocê precisa reduzir o cluster do Servidor de Metadados (MDS, Metadata Server). Como hárecursos incompatíveis entre as versões 5.5 e 6 do SUSE Enterprise Storage, os daemons MDSmais antigos serão encerrados logo que virem um único MDS no nível do SES 6 ingressar nocluster. Portanto, é necessário reduzir o cluster MDS a um único MDS ativo (sem standbys)durante os upgrades dos nós MDS. Logo após o upgrade do segundo nó, você poderá estendero cluster MDS novamente.

76 Fazendo upgrade dos nós do Ceph Monitor/Ceph Manager SES 6

DicaEm um cluster MDS com carga muito pesada, talvez seja necessário reduzir a carga (porexemplo, parando os clientes) para que um único MDS ativo seja capaz de processar acarga de trabalho.

1. Observe o valor atual da opção max_mds :

cephadm@adm > ceph fs get cephfs | grep max_mds

2. Reduza o cluster MDS se você tiver mais do que 1 daemon MDS ativo. Por exemplo,max_mds é > 1. Para reduzir o cluster MDS, execute

cephadm@adm > ceph fs set FS_NAME max_mds 1

em que FS_NAME é o nome da sua instância do CephFS (por padrão, “cephfs”).

3. Encontre o nó que hospeda um dos daemons MDS de standby. Consulte a saída do comandoceph fs status e inicie o upgrade do cluster MDS nesse nó.

cephadm@adm > ceph fs statuscephfs - 2 clients======+------+--------+--------+---------------+-------+-------+| Rank | State | MDS | Activity | dns | inos |+------+--------+--------+---------------+-------+-------+| 0 | active | mon1-6 | Reqs: 0 /s | 13 | 16 |+------+--------+--------+---------------+-------+-------++-----------------+----------+-------+-------+| Pool | type | used | avail |+-----------------+----------+-------+-------+| cephfs_metadata | metadata | 2688k | 96.8G || cephfs_data | data | 0 | 96.8G |+-----------------+----------+-------+-------++-------------+| Standby MDS |+-------------+| mon3-6 || mon2-6 |+-------------+

Neste exemplo, é necessário iniciar o procedimento de upgrade no nó “mon3-6” ou“mon2-6”.

77 Fazendo upgrade dos servidores de metadados SES 6

4. Faça upgrade do nó com o daemon MDS de standby. Depois que o nó MDS do qualfoi feito o upgrade for iniciado, os daemons MDS desatualizados serão encerradosautomaticamente. Neste ponto, os clientes podem passar por um breve tempo de esperado serviço CephFS.Siga o procedimento descrito na Seção  6.8, “Fazendo upgrade por nó: procedimento

básico”.

5. Faça upgrade dos nós MDS restantes.

6. Redena max_mds para a conguração desejada:

cephadm@adm > ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT

6.12 Fazendo upgrade dos Ceph OSDsPara cada nó de armazenamento, siga etas etapas:

1. Identique quais daemons OSD estão sendo executados em um nó especíco:

cephadm@osd > ceph osd tree

2. Dena o ag “noout” para cada daemon OSD no nó do qual está sendo feito o upgrade:

cephadm@osd > ceph osd add-noout osd.OSD_ID

Por exemplo:

cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done

Faça a vericação com:

cephadm@osd > ceph health detail | grep noout

ou

cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN 6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set

78 Fazendo upgrade dos Ceph OSDs SES 6

3. Crie arquivos /etc/ceph/osd/*.json para todos os OSDs existentes executando oseguinte comando no nó do qual será feito o upgrade:

cephadm@osd > ceph-volume simple scan --force

4. Faça upgrade do nó OSD. Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade

por nó: procedimento básico”.

5. Ativar todos os OSDs encontrados no sistema:

cephadm@osd > ;ceph-volume simple activate --all

Dica: Ativação das Partições de Dados IndividualmentePara ativar partições de dados individualmente, você precisa encontrar o comandoceph-volume correto de cada partição para ativá-la. Substitua X1 pela letra/número correto da partição:

cephadm@osd > ceph-volume simple scan /dev/sdX1

Por exemplo:

cephadm@osd > ceph-volume simple scan /dev/vdb1[...]--> OSD 8 got scanned and metadata persisted to file:/etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json--> To take over management of this scanned OSD, and disable ceph-diskand udev, run:--> ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290

A última linha da saída contém o comando para ativar a partição:

cephadm@osd > ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290[...]--> All ceph-disk systemd units have been disabled to prevent OSDsgetting triggered by UDEV events[...]Running command: /bin/systemctl start ceph-osd@8--> Successfully activated OSD 8 with FSIDd7bd2685-5b92-4074-8161-30d146cd0290

6. Verique se o nó OSD será iniciado apropriadamente após a reinicialização.

79 Fazendo upgrade dos Ceph OSDs SES 6

7. Resolva a mensagem “Legacy BlueStore stats reporting detected on XX OSD(s)” (Relatóriode estatísticas do BlueStore legado detectado em XX OSD(s)):

cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)

O aviso é normal ao fazer upgrade do Ceph para 14.2.2. Para desabilitá-lo, dena:

bluestore_warn_on_legacy_statfs = false

A correção apopriada é executar o seguinte comando em todos os OSDs enquanto estãosendo interrompidos:

cephadm@osd > ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX

Veja a seguir um script ajudante que executa o comando ceph-bluestore-tool repairpara todos os OSDs no nó NODE_NAME :

OSDNODE=OSD_NODE_NAME;\ for OSD in $(ceph osd ls-tree $OSDNODE);\ do echo "osd=" $OSD;\ salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\ salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\ salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\ done

8. Cancele a denição do ag “noout” para cada daemon OSD no nó do qual foi feito oupgrade:

cephadm@osd > ceph osd rm-noout osd.OSD_ID

Por exemplo:

cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done

Faça a vericação com:

cephadm@osd > ceph health detail | grep noout

80 Fazendo upgrade dos Ceph OSDs SES 6

Nota:

cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)

9. Verique o status do cluster. Ele será semelhante à seguinte saída:

cephadm@osd > ceph statuscluster: id: e0d53d64-6812-3dfe-8b72-fd454a6dcf12 health: HEALTH_WARN 3 monitors have not enabled msgr2

services: mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h) mgr: mon2(active, since 22m), standbys: mon1, mon3 osd: 30 osds: 30 up, 30 in

data: pools: 1 pools, 1024 pgs objects: 0 objects, 0 B usage: 31 GiB used, 566 GiB / 597 GiB avail pgs: 1024 active+clean

10. Verique se todos os nós OSD foram reinicializados e se os OSDs foram iniciadosautomaticamente após a reinicialização.

6.13 Migração do OSD para BlueStoreO OSD do BlueStore é um novo back end para os daemons OSD. Ele é a opção padrão desde oSUSE Enterprise Storage 5. Comparado com o FileStore, que armazena objetos como arquivosem um sistema de arquivos XFS, o BlueStore pode proporcionar melhor desempenho, porquearmazena os objetos diretamente no dispositivo de blocos subjacente. O BlueStore tambémdisponibiliza outros recursos, como compactação incorporada e sobregravações EC, que nãoestão disponíveis no FileStore.

81 Migração do OSD para BlueStore SES 6

Especicamente no BlueStore, um OSD tem um dispositivo “wal” (Registro Write-Ahead) e umdispositivo “db” (banco de dados RocksDB). O banco de dados RocksDB armazena os metadadospara um OSD do BlueStore. Por padrão, esses dois dispositivos residirão no mesmo dispositivocomo um OSD, mas qualquer um deles pode ser inserido em uma mídia diferente, por exemplo,mais rápida.

No SUSE Enterprise Storage 5, tanto o FileStore quanto o BlueStore são suportados, e os OSDsdo FileStore e do BlueStore podem coexistir em um único cluster. Durante o procedimento deupgrade do SUSE Enterprise Storage, os OSDs do FileStore não são convertidos automaticamenteem BlueStore. Os recursos especícos do BlueStore não estarão disponíveis nos OSDs que nãoforam migrados para o BlueStore.

Antes da conversão em BlueStore, os OSDs precisam executar o SUSE Enterprise Storage 5.A conversão é um processo lento, pois todos os dados são regravados duas vezes. O processode migração pode levar muito tempo para ser concluído, mas não há nenhuma interrupçãodo cluster, e todos os clientes podem continuar acessando o cluster durante esse período.No entanto, é comum uma redução no desempenho durante a migração. Isso é causado pelaredistribuição e preenchimento de dados dos cluster.

Siga o procedimento abaixo para migrar os OSDs do FileStore para o BlueStore:

Dica: Desativar medidas de segurançaOs comandos do Salt necessários para executar a migração são bloqueados por medidasde segurança. Para desativar essa medida preventiva, execute o seguinte comando:

root@master # salt-run disengage.safety

Reconstrua os nós antes de continuar:

root@master # salt-run rebuild.node TARGET

Você também pode reconstruir cada nó individualmente. Por exemplo:

root@master # salt-run rebuild.node data1.ceph

O rebuild.node sempre remove e recria todos os OSDs no nó.

82 Migração do OSD para BlueStore SES 6

ImportanteSe um OSD não puder ser convertido, uma nova reconstrução destruirá os OSDs doBlueStore já convertidos. Em vez de uma nova reconstrução, você poderá executar:

root@master # salt-run disks.deploy TARGET

Após a migração para o BlueStore, o total de objetos permanecerá o mesmo, e a utilização dodisco será quase igual.

6.14 Fazendo upgrade dos nós do aplicativoFaça upgrade dos nós do aplicativo na seguinte ordem:

1. Object Gateways

Se o front end dos Object Gateways for um balanceador de carga, um upgradesequencial dos Object Gateways deverá ser possível sem interrupção.

Conrme se os daemons do Object Gateway estão em execução após cada upgradee faça o teste com o cliente S3/Swift.

Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento

básico”.

2. iSCSI Gateways

Se os iniciadores iSCSI estiverem congurados com múltiplos caminhos, um upgradesequencial dos iSCSI Gateways deverá ser possível sem interrupção.

Conrme se o daemon lrbd está em execução após cada upgrade e faça o teste como iniciador.

Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por nó: procedimento

básico”.

83 Fazendo upgrade dos nós do aplicativo SES 6

3. NFS Ganesha. Siga o procedimento descrito na Seção  6.8, “Fazendo upgrade por nó:

procedimento básico”.

4. Gateways do Samba. Siga o procedimento descrito na Seção 6.8, “Fazendo upgrade por

nó: procedimento básico”.

6.15 Atualizando o policy.cfg e implantando oCeph Dashboard por meio do DeepSeaNo Nó de Admin, edite o /srv/pillar/ceph/proposals/policy.cfg e aplique as seguintesmudanças:

Importante: Sem Novos ServiçosDurante o upgrade do cluster, não adicione novos serviços ao arquivo policy.cfg .Apenas mude a arquitetura do cluster após a conclusão do upgrade.

1. Remova role-openattic .

2. Adicione role-prometheus e role-grafana ao nó com o Prometheus e o Grafanainstalados (normalmente, o Nó de Admin).

3. Agora, a função profile-NOME_PERFIL será ignorada. Adicione a nova funçãocorrespondente: linha role-storage . Por exemplo, para o comando existente

profile-default/cluster/*.sls

adicione

role-storage/cluster/*.sls

4. Sincronize todos os módulos do Salt:

root@master # salt '*' saltutil.sync_all

5. Execute as fases 1 e 2 do DeepSea para atualizar o pillar Salt:

root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2

84 Atualizando o policy.cfg e implantando o Ceph Dashboard por meio do DeepSea SES 6

6. Limpe o openATTIC:

root@master # salt OA_MINION state.apply ceph.rescind.openatticroot@master # salt OA_MINION state.apply ceph.remove.openattic

7. Cancele a denição do grain “restart_igw” para impedir que a fase 0 reinicie o iSCSIGateway, que ainda não está instalado:

Salt mastersalt '*' grains.delkey restart_igw

8. Por m, execute as fases de 0 a 4 do DeepSea:

root@master # salt-run state.orch ceph.stage.0root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4

Dica: Erros de "subvolume ausente" durante a Fase 3A fase 3 do DeepSea pode falhar com um erro semelhante ao exibido a seguir:

subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \'/var/lib/ceph subvolume missing on 4510-1', \[...]'See /srv/salt/ceph/subvolume/README.md']

Neste caso, você precisa editar o /srv/pillar/ceph/stack/global.yml eadicionar a seguinte linha:

subvolume_init: disabled

Em seguida, atualize o pillar Salt e execute a fase 3 do DeepSea novamente:

root@master # salt '*' saltutil.refresh_pillar root@master # salt-run state.orch ceph.stage.3

Após a conclusão bem-sucedida da fase 3 do DeepSea, o Ceph Dashboard seráexecutado. Consulte o Livro “Guia de Administração”, Capítulo 22 “Ceph Dashboard” paraobter uma visão geral detalhada dos recursos do Ceph Dashboard.

85 Atualizando o policy.cfg e implantando o Ceph Dashboard por meio do DeepSea SES 6

Para listar os nós que executam o painel de controle, aplique o comando:

cephadm@adm > ceph mgr services | grep dashboard

Para listar as credenciais de admin, execute:

root@master # salt-call grains.get dashboard_creds

9. Reinicie sequencialmente os serviços do Object Gateway para usar o servidor Web “beast”em vez do “civetweb” desatualizado:

root@master # salt-run state.orch ceph.restart.rgw.force

10. Antes de continuar, recomendamos enfaticamente habilitar o módulo de telemetria doCeph. Para obter mais informações e instruções, consulte o Livro “Guia de Administração”,

Capítulo 10 “Módulos do Ceph Manager”, Seção 10.2 “Módulo de telemetria”.

6.16 Migrando de implantações com base no perfilpara DriveGroupsNo SUSE Enterprise Storage 5.5, o DeepSea ofereceu os chamados “pers” para descrever olayout dos OSDs. A partir do SUSE Enterprise Storage 6, adotamos uma abordagem diferentedenominada DriveGroups (encontre mais detalhes na Seção 5.5.2, “DriveGroups”).

NotaA migração para a nova abordagem não é obrigatória de imediato. Operações destrutivas,como salt-run osd.remove , salt-run osd.replace ou salt-run osd.purge , aindaestão disponíveis. No entanto, a adição de novos OSDs exigirá que você execute uma ação.

Devido à abordagem diferente dessas implementações, não oferecemos um caminho de migraçãoautomatizado. No entanto, oferecemos uma variedade de ferramentas, executores Salt, paratornar a migração o mais simples possível.

86 Migrando de implantações com base no perfil para DriveGroups SES 6

6.16.1 Analisando o layout atual

Para ver informações sobre os OSDs implantados atualmente, use o seguinte comando:

root@master # salt-run disks.discover

Se preferir, você poderá inspecionar o conteúdo dos arquivos nos diretórios /srv/pillar/ceph/proposals/profile-*/ . Eles têm uma estrutura semelhante à seguinte:

ceph: storage: osds: /dev/disk/by-id/scsi-drive_name: format: bluestore /dev/disk/by-id/scsi-drive_name2: format: bluestore

6.16.2 Criando DriveGroups que correspondem ao layout atual

Consulte a Seção  5.5.2.1, “Especificação” para obter mais detalhes sobre a especicação deDriveGroups.

A diferença entre uma implantação nova e um cenário de upgrade é que as unidades que serãomigradas já são “usadas”. Como

root@master # salt-run disks.list

procura apenas discos não usados, aplique o comando

root@master # salt-run disks.list include_unavailable=True

Ajuste os DriveGroups até corresponder à sua conguração atual. Para uma representação maisvisual do que acontecerá, execute o comando a seguir. Observe que ele não terá saída se nãohouver discos livres:

root@master # salt-run disks.report bypass_pillar=True

Se você vericou que os DriveGroups estão congurados apropriadamente e deseja aplicar anova abordagem, remova os arquivos do diretório /srv/pillar/ceph/proposals/profile-NOME_PERFIL/ , remova as linhas profile-NOME_PERFIL/cluster/*.sls correspondentes doarquivo /srv/pillar/ceph/proposals/policy.cfg e execute a fase 2 do DeepSea paraatualizar o pillar Salt.

root@master # salt-run state.orch ceph.stage.2

87 Analisando o layout atual SES 6

Execute os seguintes comandos para vericar o resultado:

root@master # salt target_node pillar.get ceph:storageroot@master # salt-run disks.report

Atenção: Configuração Incorreta dos DriveGroupsSe os DriveGroups não estiverem congurados apropriadamente e houver discossobressalentes na conguração, eles serão implantados da maneira que você osespecicou. Recomendamos executar o comando:

root@master # salt-run disks.report

6.16.3 Implantando um OSD

Para casos simples, como OSDs independentes, a migração acontecerá com o tempo. Sempre quevocê remover ou substituir um OSD do cluster, ele será substituído por um novo OSD baseadoem LVM.

Dica: Migrar para o Formato LVMSempre que um único OSD "legado" precisar ser substituído em um nó, todos os OSDsque compartilham dispositivos com ele deverão ser migrados para o formato baseado emLVM.

Para totalidade, considere a migração dos OSDs em todo o nó.

6.16.4 Configurações mais complexas

Se você tem uma conguração mais sosticada do que apenas OSDs independentes (por exemplo,WAL/BDs dedicados ou OSDs criptografados), a migração apenas pode acontecer quando todosos OSDs atribuídos a esse dispositivo WAL/BD são removidos. Isso ocorre porque o comandoceph-volume cria os Volumes Lógicos nos discos antes da implantação. Esse comportamentoimpede que o usuário misture implantações baseadas na partição com implantações baseadas emLV. Nesses casos, o melhor é remover manualmente todos os OSDs atribuídos a um dispositivoWAL/BD e reimplantá-los adotando a abordagem DriveGroups.

88 Implantando um OSD SES 6

7 Personalizando a configuração padrão

Você pode mudar a conguração padrão do cluster gerada na Fase 2 (consulte Descrição das fases

do DeepSea). Por exemplo, talvez você tenha que mudar as congurações de rede ou o softwareque está instalado por padrão no Nó de Admin. Para o primeiro caso, você pode modicar o pillaratualizado após a Fase 2. No segundo caso, costuma-se criar um arquivo sls personalizado eadicioná-lo ao pillar. Os detalhes estão descritos nas seções a seguir.

7.1 Usando arquivos de configuração personalizadosEsta seção lista as diversas tarefas que requerem adição/modicação de seus próprios arquivossls . Normalmente, esse tipo de procedimento é usado quando você precisa mudar o processode implantação padrão.

Dica: Adicionar prefixo aos arquivos .sls personalizadosSeus arquivos .sls personalizados pertencem ao mesmo subdiretório que os arquivos .slsdo DeepSea. Para evitar sobregravar seus arquivos .sls por aqueles que podem ser recém-adicionados do pacote do DeepSea, adicione um prexo ao nome deles com a stringcustom- .

7.1.1 Desabilitando uma etapa de implantação

Se você resolver determinada tarefa fora do processo de implantação do DeepSea e, desse modo,precisar ignorá-la, crie um arquivo “no-operation” seguindo este exemplo:

PROCEDIMENTO 7.1: DESABILITANDO A SINCRONIZAÇÃO DE HORÁRIO

1. Crie /srv/salt/ceph/time/disabled.sls com o seguinte conteúdo e grave-o:

disable time setting:test.nop

2. Edite /srv/pillar/ceph/stack/global.yml , adicione a seguinte linha e grave-o:

time_init: disabled

89 Usando arquivos de configuração personalizados SES 6

3. Faça a vericação atualizando o pillar e executando a etapa:

root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.timeadmin.ceph: Name: disable time setting - Function: test.nop - Result: Clean

Summary for admin.ceph------------Succeeded: 1Failed: 0------------Total states run: 1

Nota: ID exclusivoO ID da tarefa “disable time setting” pode ser qualquer mensagem exclusiva em umarquivo sls . Para impedir colisões de ID, especique descrições exclusivas.

7.1.2 Substituindo uma etapa de implantação

Se você precisa substituir o comportamento padrão de uma etapa especíca por umpersonalizado, crie um arquivo sls personalizado com o conteúdo de substituição.

Por padrão, /srv/salt/ceph/pool/default.sls cria uma imagem rbd chamada “demo”. Emnosso exemplo, não desejamos que essa imagem seja criada, mas precisamos de duas imagens:“archive1” e “archive2”.

PROCEDIMENTO 7.2: SUBSTITUINDO A IMAGEM RBD DEMO POR DUAS IMAGENS RBD PERSONALIZADAS

1. Crie /srv/salt/ceph/pool/custom.sls com o seguinte conteúdo e grave-o:

wait: module.run: - name: wait.out - kwargs: 'status': "HEALTH_ERR" 1

- fire_event: True

archive1: cmd.run: - name: "rbd -p rbd create archive1 --size=1024" 2

- unless: "rbd -p rbd ls | grep -q archive1$"

90 Substituindo uma etapa de implantação SES 6

- fire_event: True

archive2: cmd.run: - name: "rbd -p rbd create archive2 --size=768" - unless: "rbd -p rbd ls | grep -q archive2$" - fire_event: True

1 O módulo wait cará pausado enquanto o status do cluster do Ceph for HEALTH_ERR .Nas instalações novas, um cluster do Ceph pode ter esse status até que um númerosuciente de OSDs se torne disponível e a criação de pools seja concluída.

2 O comando rbd não é idempotente. Se o mesmo comando de criação for executadonovamente após a existência da imagem, haverá falha no estado do Salt. A declaraçãounless impede que isso aconteça.

2. Para chamar o arquivo personalizado recém-criado, em vez do padrão, você precisa editar/srv/pillar/ceph/stack/ceph/cluster.yml , adicionar a seguinte linha e gravá-lo:

pool_init: custom

3. Faça a vericação atualizando o pillar e executando a etapa:

root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool

Nota: AutorizaçãoA criação de pools ou imagens requer autorização suciente. O minion admin.ceph temum chaveiro de admin.

Dica: Modo alternativoOutra opção é mudar a variável em /srv/pillar/ceph/stack/ceph/roles/

master.yml . O uso desse arquivo reduzirá o acúmulo de dados do pillar para outrosminions.

91 Substituindo uma etapa de implantação SES 6

7.1.3 Modificando uma etapa de implantação

Às vezes, você pode precisar de uma etapa especíca para realizar algumas tarefas adicionais.Não é recomendável modicar o arquivo de estado relacionado, pois ele pode complicar umupgrade futuro. Em vez disso, crie um arquivo separado para executar as tarefas adicionaisexatamente como foi descrito na Seção 7.1.2, “Substituindo uma etapa de implantação”.

Nomeie o novo arquivo sls de modo descritivo. Por exemplo, se você precisa criar duas imagensrbd além da imagem demo, nomeie o arquivo archive.sls .

PROCEDIMENTO 7.3: CRIANDO DUAS IMAGENS RBD ADICIONAIS

1. Crie /srv/salt/ceph/pool/custom.sls com o seguinte conteúdo e grave-o:

include: - .archive - .default

Dica: Incluir precedênciaNeste exemplo, o Salt criará as imagens archive e, em seguida, a imagem demo. Aordem não importa neste exemplo. Para mudar a ordem, inverta as linhas após adiretiva include: .

Você pode adicionar a linha include diretamente ao archive.sls , e todas asimagens também serão criadas. No entanto, independentemente de onde a linhainclude for colocada, o Salt processará primeiro as etapas no arquivo incluído.Embora esse comportamento possa ser anulado pelas declarações requires e order,um arquivo separado incluindo as outras etapas garante a ordem e reduz as chancesde confusão.

2. Edite /srv/pillar/ceph/stack/ceph/cluster.yml , adicione a seguinte linha e grave-o:

pool_init: custom

3. Faça a vericação atualizando o pillar e executando a etapa:

root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool

92 Modificando uma etapa de implantação SES 6

7.1.4 Modificando uma fase de implantação

Se você precisa adicionar uma etapa de implantação completamente separada, crie trêsnovos arquivos: um sls que executa o comando, um arquivo de orquestração e um arquivopersonalizado que alinha a nova etapa às etapas originais da implantação.

Por exemplo, se você precisa executar logrotate em todos os minions como parte da fase depreparação:

Crie primeiro um arquivo sls e inclua o comando logrotate .

PROCEDIMENTO 7.4: EXECUTANDO O logrotate EM TODOS OS MINIONS SALT

1. Crie um diretório, como /srv/salt/ceph/logrotate .

2. Crie /srv/salt/ceph/logrotate/init.sls com o seguinte conteúdo e grave-o:

rotate logs: cmd.run: - name: "/usr/sbin/logrotate /etc/logrotate.conf"

3. Verique se o comando funciona em um minion:

root@master # salt 'admin.ceph' state.apply ceph.logrotate

Como o arquivo de orquestração precisa ser executado antes de todas as outras etapas depreparação, adicione-o à Fase 0 Preparação:

1. Crie /srv/salt/ceph/stage/prep/logrotate.sls com o seguinte conteúdo e grave-o:

logrotate: salt.state: - tgt: '*' - sls: ceph.logrotate

2. Verique se o arquivo de orquestração funciona:

root@master # salt-run state.orch ceph.stage.prep.logrotate

O último arquivo é aquele personalizado que inclui a etapa adicional com as etapas originais:

1. Crie /srv/salt/ceph/stage/prep/custom.sls com o seguinte conteúdo e grave-o:

include: - .logrotate - .master

93 Modificando uma fase de implantação SES 6

- .minion

2. Anule o comportamento padrão. Edite /srv/pillar/ceph/stack/global.yml , adicionea seguinte linha e grave o arquivo:

stage_prep: custom

3. Verique se a Fase 0 funciona:

root@master # salt-run state.orch ceph.stage.0

Nota: Por que global.yml?O arquivo global.yml foi escolhido no lugar do cluster.yml porque, durante a fasede preparação, nenhum minion pertence ao cluster do Ceph e não tem acesso a quaisquercongurações no cluster.yml .

7.1.5 Atualizações e reinicializações durante a fase 0

Durante a fase 0 (consulte Descrição das fases do DeepSea para obter mais informações sobre asfases do DeepSea), o master Salt e os minions Salt podem ser reinicializados porque os pacotesatualizados recentemente, por exemplo kernel , exigem reinicialização do sistema.

O comportamento padrão é instalar as novas atualizações disponíveis e não reinicializar os nós,mesmo no caso de atualizações do kernel.

Você pode alterar o comportamento padrão de atualização/reinicialização da fase 0 do DeepSeaadicionando/alterando as opções stage_prep_master e stage_prep_minion no arquivo /srv/pillar/ceph/stack/global.yml . _prep_master dene o comportamento da Fase domaster Salt, e stage_prep_minion dene o comportamento de todos os minions. Todos osparâmetros disponíveis são:

default

Instalar as atualizações sem reinicializar.

default-update-reboot

Instalar as atualizações e reinicializar após a atualização.

default-no-update-reboot

Reinicializar sem instalar as atualizações.

94 Atualizações e reinicializações durante a fase 0 SES 6

default-no-update-no-reboot

Não instalar as atualizações nem reinicializar.

Por exemplo, para impedir que os nós do cluster instalem as atualizações e sejam reinicializados,edite /srv/pillar/ceph/stack/global.yml e adicione as seguintes linhas:

stage_prep_master: default-no-update-no-rebootstage_prep_minion: default-no-update-no-reboot

Dica: Valores e arquivos correspondentesOs valores de stage_prep_master correspondem aos nomes de arquivo localizados no /srv/salt/ceph/stage/0/master . Já os valores de stage_prep_minion correspondemaos arquivos no /srv/salt/ceph/stage/0/minion :

root@master # ls -l /srv/salt/ceph/stage/0/masterdefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]

root@master # ls -l /srv/salt/ceph/stage/0/miniondefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]

7.2 Modificando a configuração descobertaApós concluir a Fase 2, convém mudar a conguração descoberta. Para ver as conguraçõesatuais, execute:

root@master # salt target pillar.items

Normalmente, a saída da conguração padrão de um único minion é semelhante a esta:

---------- available_roles: - admin - mon

95 Modificando a configuração descoberta SES 6

- storage - mds - igw - rgw - client-cephfs - client-radosgw - client-iscsi - mds-nfs - rgw-nfs - master cluster: ceph cluster_network: 172.16.22.0/24 fsid: e08ec63c-8268-3f04-bcdb-614921e94342 master_minion: admin.ceph mon_host: - 172.16.21.13 - 172.16.21.11 - 172.16.21.12 mon_initial_members: - mon3 - mon1 - mon2 public_address: 172.16.21.11 public_network: 172.16.21.0/24 roles: - admin - mon - mds time_server: admin.ceph time_service: ntp

96 Modificando a configuração descoberta SES 6

As congurações mencionadas acima são distribuídas entre vários arquivos de conguração. Aestrutura de diretórios com esses arquivos é denida no diretório /srv/pillar/ceph/stack/stack.cfg . Em geral, os arquivos a seguir descrevem seu cluster:

/srv/pillar/ceph/stack/global.yml : o arquivo afeta todos os minions no cluster doSalt.

/srv/pillar/ceph/stack/ceph/cluster.yml : o arquivo afeta todos os minions nocluster do Ceph denominado ceph .

/srv/pillar/ceph/stack/ceph/roles/role.yml : afeta todos os minions quereceberam a função especíca no cluster ceph .

/srv/pillar/ceph/stack/ceph/minions/MINION_ID/yml : afeta o minion individual.

Nota: Sobregravando diretórios com valores padrãoHá uma árvore de diretório paralela que armazena a conguração padrão em /srv/pillar/ceph/stack/default . Não mude valores aqui, pois eles serão sobregravados.

Veja a seguir o procedimento comum para mudar a conguração coletada:

1. Encontre o local do item de conguração que você precisa mudar. Por exemplo, se vocêprecisa mudar a conguração relacionada ao cluster, como a rede do cluster, edite oarquivo /srv/pillar/ceph/stack/ceph/cluster.yml .

2. Grave o arquivo.

3. Para vericar as mudanças, execute:

root@master # salt target saltutil.pillar_refresh

e, em seguida:

root@master # salt target pillar.items

7.2.1 Habilitando o IPv6 para implantação de cluster do Ceph

Como o endereçamento de rede IPv4 é predominante, você precisa habilitar o IPv6 como umapersonalização. O DeepSea não tem descoberta automática de endereçamento IPv6.

97 Habilitando o IPv6 para implantação de cluster do Ceph SES 6

Para congurar o IPv6, dena as variáveis public_network e cluster_network no arquivo/srv/pillar/ceph/stack/global.yml como sub-redes IPv6 válidas. Por exemplo:

public_network: fd00:10::/64cluster_network: fd00:11::/64

Em seguida, execute a fase 2 do DeepSea e verique se as informações de rede correspondem àconguração. A fase 3 gerará o ceph.conf com os ags necessários.

Importante: Não Há Suporte para Pilha DuplaO Ceph não suporta pilha dupla. A execução do Ceph simultaneamente no IPv4 e noIPv6 não é possível. A validação do DeepSea rejeitará uma incompatibilidade entrepublic_network e cluster_network ou em uma dessas variáveis. O exemplo a seguirapresentará falha na validação.

public_network: "192.168.10.0/24 fd00:10::/64"

Dica: Evite Usar Endereços fe80::/10 link-localEvite usar endereços fe80::/10 link-local . Todas as interfaces de rede têm umendereço fe80 atribuído e exigem um qualicador de interface para o roteamentoapropriado. Atribua endereços IPv6 alocados ao seu site ou considere o uso de fd00::/8 .Eles fazem parte do ULA e não são roteáveis globalmente.

98 Habilitando o IPv6 para implantação de cluster do Ceph SES 6

III Instalação de serviços adicionais

8 Instalação de serviços para acessar seus dados 100

9 Ceph Object Gateway 101

10 Instalação do iSCSI Gateway 109

11 Instalação do CephFS 123

12 Instalação do NFS Ganesha 139

8 Instalação de serviços para acessar seus dados

Após implantar o cluster do SUSE Enterprise Storage 6, talvez seja necessário instalar outrosoftware para acessar seus dados, como Object Gateway ou iSCSI Gateway, ou você poderáimplantar um sistema de arquivos em cluster no cluster do Ceph. Este capítulo abordaespecicamente a instalação manual. Se você tem um cluster que foi implantado com o Salt,consulte o Capítulo 5, Implantando com o DeepSea/Salt para ver o procedimento de como instalargateways especícos ou o CephFS.

100 SES 6

9 Ceph Object Gateway

Ceph Object Gateway é uma interface de armazenamento de objetos desenvolvida com base emlibrgw para fornecer aplicativos com um gateway RESTful aos clusters do Ceph. Ele suportaduas interfaces:

Compatível com S3: Oferece a funcionalidade de armazenamento de objetos com umainterface compatível com um amplo subconjunto da API RESTful do Amazon S3.

Compatível com Swift: Oferece a funcionalidade de armazenamento de objetos com umainterface compatível com um amplo subconjunto da API do OpenStack Swift.

Por padrão, o daemon do Object Gateway usa o front end HTTP “Beast”. Ele usa a bibliotecaBoost.Beast para análise de HTTP e a biblioteca Boost.Asio para operações de E/S de redeassíncronas.

Como o Object Gateway oferece interfaces compatíveis com o OpenStack Swift e o AmazonS3, ele tem o próprio gerenciamento de usuários. O Object Gateway pode armazenar dados nomesmo cluster usado para armazenar dados dos clientes CephFS ou dos clientes de Dispositivode Blocos RADOS. As APIs do S3 e do Swift compartilham um espaço de nome comum, portanto,você pode gravar dados com uma API e recuperá-los com outra.

Importante: Object Gateway implantado pelo DeepSeaO Object Gateway é instalado como uma função do DeepSea, portanto, você não precisainstalá-lo manualmente.

Para instalar o Object Gateway durante a implantação do cluster, consulte a Seção 5.3,

“Implantação do cluster”.

Para adicionar um novo nó com o Object Gateway ao cluster, consulte o Livro “Guia

de Administração”, Capítulo 2 “Administração do cluster do Salt”, Seção 2.2 “Adicionando novas

funções aos nós”.

101 SES 6

9.1 Instalação manual do Object Gateway

1. Instale o Object Gateway em um nó que não use a porta 80. O comando a seguir instalatodos os componentes necessários:

cephadm@ogw > sudo zypper ref && zypper in ceph-radosgw

2. Se o servidor Apache da instância anterior do Object Gateway estiver em execução, pare-o e desabilite o serviço relevante:

cephadm@ogw > sudo systemctl stop disable apache2.service

3. Edite /etc/ceph/ceph.conf e adicione as seguintes linhas:

[client.rgw.gateway_host] rgw frontends = "beast port=80"

DicaPara congurar o Object Gateway/Beast para uso com a criptograa SSL, modiquea linha de acordo:

rgw frontends = beast ssl_port=7480 ssl_certificate=PATH_TO_CERTIFICATE.PEM

4. Reinicie o serviço Object Gateway.

cephadm@ogw > sudo systemctl restart ceph-radosgw@rgw.gateway_host

9.1.1 Configuração do Object Gateway

Várias etapas são necessárias para congurar um Object Gateway.

102 Instalação manual do Object Gateway SES 6

9.1.1.1 Configuração Básica

A conguração de um Ceph Object Gateway requer um Cluster de Armazenamento do Ceph emexecução. O Ceph Object Gateway é um cliente do Cluster de Armazenamento do Ceph. Comocliente do Cluster de Armazenamento do Ceph, ele requer:

Um nome de host para a instância do gateway. Por exemplo, gateway .

Um nome de usuário do cluster de armazenamento com as permissões apropriadas e umchaveiro.

Pools para armazenar os dados.

Um diretório de dados para a instância do gateway.

Uma entrada de instância no arquivo de conguração do Ceph.

Cada instância deve ter um nome de usuário e uma chave para se comunicar com um clusterde armazenamento do Ceph. Nas etapas a seguir, usamos um nó do monitor para criar umchaveiro do protocolo de boot e, em seguida, criamos o chaveiro do usuário da instância doObject Gateway com base no do protocolo de boot. Em seguida, criamos um nome de usuárioe uma chave do cliente. Na sequência, adicionamos a chave ao Cluster de Armazenamento doCeph. Por m, distribuímos o chaveiro para o nó que contém a instância do gateway.

1. Crie um chaveiro para o gateway:

cephadm@adm > ceph-authtool --create-keyring /etc/ceph/ceph.client.rgw.keyringcephadm@adm > sudo chmod +r /etc/ceph/ceph.client.rgw.keyring

2. Gere um nome de usuário e uma chave do Ceph Object Gateway para cada instância. Comoexemplo, usaremos o nome gateway depois de client.radosgw :

cephadm@adm > ceph-authtool /etc/ceph/ceph.client.rgw.keyring \ -n client.rgw.gateway --gen-key

3. Adicione recursos à chave:

cephadm@adm > ceph-authtool -n client.rgw.gateway --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.client.rgw.keyring

103 Configuração do Object Gateway SES 6

4. Após criar um chaveiro e uma chave para habilitar o acesso do Ceph Object Gateway aoCluster de Armazenamento do Ceph, adicione a chave ao Cluster de Armazenamento doCeph. Por exemplo:

cephadm@adm > ceph -k /etc/ceph/ceph.client.admin.keyring auth add client.rgw.gateway \ -i /etc/ceph/ceph.client.rgw.keyring

5. Distribua o chaveiro para o nó com a instância do gateway:

cephadm@adm > scp /etc/ceph/ceph.client.rgw.keyring ceph@HOST_NAME:/home/cephcephadm@adm > ssh ceph@HOST_NAMEcephadm@ogw > mv ceph.client.rgw.keyring /etc/ceph/ceph.client.rgw.keyring

Dica: Usar o chaveiro do protocolo de bootUma maneira alternativa é criar o chaveiro do protocolo de boot do Object Gateway e,em seguida, criar o chaveiro do Object Gateway com base nele:

1. Crie um chaveiro do protocolo de boot do Object Gateway em um dos nós domonitor:

cephadm@mon > ceph \ auth get-or-create client.bootstrap-rgw mon 'allow profile bootstrap-rgw' \ --connect-timeout=25 \ --cluster=ceph \ --name mon. \ --keyring=/var/lib/ceph/mon/ceph-NODE_HOST/keyring \ -o /var/lib/ceph/bootstrap-rgw/keyring

2. Crie o diretório /var/lib/ceph/radosgw/ceph-RGW_NAME para armazenar ochaveiro do protocolo de boot:

cephadm@mon > mkdir \/var/lib/ceph/radosgw/ceph-RGW_NAME

3. Crie um chaveiro do Object Gateway com base no chaveiro do protocolo de bootrecém-criado:

cephadm@mon > ceph \ auth get-or-create client.rgw.RGW_NAME osd 'allow rwx' mon 'allow rw' \ --connect-timeout=25 \ --cluster=ceph \

104 Configuração do Object Gateway SES 6

--name client.bootstrap-rgw \ --keyring=/var/lib/ceph/bootstrap-rgw/keyring \ -o /var/lib/ceph/radosgw/ceph-RGW_NAME/keyring

4. Copie o chaveiro do Object Gateway para o host do Object Gateway:

cephadm@mon > scp \/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring \RGW_HOST:/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring

9.1.1.2 Criar pools (opcional)

Os Ceph Object Gateways requerem pools de Cluster de Armazenamento do Ceph paraarmazenar dados especícos do gateway. Se o usuário que você criou tem as permissõesapropriadas, o gateway criará os pools automaticamente. No entanto, verique se vocêdeniu um número padrão apropriado de grupos de posicionamento por pool no arquivo deconguração do Ceph.

Os nomes dos pools vêm depois da sintaxe ZONE_NAME.POOL_NAME . Ao congurar um gatewaycom a região e a zona padrão, o nome da zona padrão é “default”, como em nosso exemplo:

.rgw.rootdefault.rgw.controldefault.rgw.metadefault.rgw.logdefault.rgw.buckets.indexdefault.rgw.buckets.data

Para criar os pools manualmente, consulte o Livro “Guia de Administração”, Capítulo 11 “Gerenciando

pools de armazenamento”, Seção 11.2.2 “Criando um pool”.

Importante: Object Gateway e pools com codificação deeliminaçãoApenas o pool default.rgw.buckets.data pode ter codicação de eliminação. Todosos outros pools precisam ser replicados; do contrário, o gateway não cará acessível.

105 Configuração do Object Gateway SES 6

9.1.1.3 Adicionando a configuração do gateway ao Ceph

Adicione a conguração do Ceph Object Gateway ao arquivo de Conguração do Ceph. Aconguração do Ceph Object Gateway requer que você identique a instância do Ceph ObjectGateway. Em seguida, especique o nome de host em que você instalou o daemon do CephObject Gateway, um chaveiro (para uso com o cephx) e, opcionalmente, um arquivo de registro.Por exemplo:

[client.rgw.INSTANCE_NAME]host = HOST_NAMEkeyring = /etc/ceph/ceph.client.rgw.keyring

Dica: Arquivo de registro do Object GatewayPara anular o arquivo de registro do Object Gateway padrão, inclua o seguinte:

log file = /var/log/radosgw/client.rgw.INSTANCE_NAME.log

A parte [client.rgw.*] da instância do gateway identica essa parte do arquivo deconguração do Ceph como a que congura um cliente de Cluster de Armazenamento do Cephno qual o tipo de cliente é um Ceph Object Gateway (radosgw). O nome da instância vem nasequência. Por exemplo:

[client.rgw.gateway]host = ceph-gatewaykeyring = /etc/ceph/ceph.client.rgw.keyring

NotaO HOST_NAME deve ser o nome de host da sua máquina, excluindo o nome de domínio.

Em seguida, desative print continue . Se ele estiver denido como true, você poderá terproblemas com as operações PUT:

rgw print continue = false

106 Configuração do Object Gateway SES 6

Para usar um Ceph Object Gateway com chamadas de subdomínio S3 (por exemplo, http://bucketname.hostname ), você deve adicionar o nome DNS do Ceph Object Gateway à seção[client.rgw.gateway] do arquivo de conguração do Ceph:

[client.rgw.gateway]...rgw dns name = HOST_NAME

Você também deve considerar a instalação de um servidor DNS, como Dnsmasq, emsua(s) máquina(s) cliente ao usar a sintaxe http://BUCKET_NAME.HOST_NAME . O arquivodnsmasq.conf deve incluir as seguintes congurações:

address=/HOST_NAME/HOST_IP_ADDRESSlisten-address=CLIENT_LOOPBACK_IP

Em seguida, adicione o endereço IP CLIENT_LOOPBACK_IP como o primeiro servidor DNS à(s)máquina(s) cliente.

9.1.1.4 Criar diretório de dados

Os scripts de implantação não podem criar o diretório de dados do Ceph Object Gateway padrão.Crie diretórios de dados para cada instância de um daemon radosgw, caso isso ainda não tenhasido feito. As variáveis de host no arquivo de conguração do Ceph determinam qual hostexecuta cada instância de um daemon radosgw. O formato comum especica o daemon radosgw,o nome do cluster e o ID do daemon.

root # mkdir -p /var/lib/ceph/radosgw/CLUSTER_ID

Usando as congurações do ceph.conf do exemplo acima, você executa o seguinte:

root # mkdir -p /var/lib/ceph/radosgw/ceph-radosgw.gateway

9.1.1.5 Reiniciar serviços e iniciar o gateway

Para garantir que todos os componentes recarreguem as congurações deles, é recomendávelreiniciar o serviço de Cluster de Armazenamento do Ceph. Em seguida, inicialize o serviçoradosgw . Para obter mais informações, consulte o Livro “Guia de Administração”, Capítulo 4

“Introdução” e o Livro “Guia de Administração”, Capítulo 17 “Ceph Object Gateway”, Seção 17.3 “Operando

o serviço Object Gateway”.

107 Configuração do Object Gateway SES 6

Quando o serviço estiver em execução, você poderá fazer uma solicitação GET anônima paraver se o gateway retorna uma resposta. Uma solicitação HTTP simples para o nome de domíniodeve retornar o seguinte:

<ListAllMyBucketsResult> <Owner> <ID>anonymous</ID> <DisplayName/> </Owner> <Buckets/></ListAllMyBucketsResult>

108 Configuração do Object Gateway SES 6

10 Instalação do iSCSI Gateway

iSCSI é um protocolo SAN (Storage Area Network) que permite aos clientes (denominadosiniciadores) enviar comandos SCSI para dispositivos de armazenamento SCSI (destinos) emservidores remotos. O SUSE Enterprise Storage 6 inclui um recurso que abre o gerenciamentode armazenamento do Ceph para clientes heterogêneos, como Microsoft Windows* e VMware*vSphere, por meio do protocolo iSCSI. O acesso de múltiplos caminhos do iSCSI fornecedisponibilidade e escalabilidade para esses clientes, e o protocolo iSCSI padronizado tambémproporciona uma camada adicional de isolamento de segurança entre os clientes e o clusterdo SUSE Enterprise Storage 6. O recurso de conguração é denominado ceph-iscsi . Aousar o ceph-iscsi , os administradores de armazenamento do Ceph podem denir volumesreplicados, aprovisionados dinamicamente e altamente disponíveis com suporte a instantâneosapenas leitura, clones de leitura-gravação e redimensionamento automático com Dispositivo deBlocos RADOS (RBD, RADOS Block Device) do Ceph. Em seguida, os administradores podemexportar os volumes por um host de gateway ceph-iscsi único ou por vários hosts de gatewaycom suporte a failover de múltiplos caminhos. Os hosts do Linux, Microsoft Windows e VMwarepodem se conectar aos volumes pelo protocolo iSCSI, que os torna disponíveis como qualqueroutro dispositivo de blocos SCSI. Isso signica que os clientes do SUSE Enterprise Storage 6podem executar com ecácia um subsistema completo de infraestrutura de armazenamento deblocos no Ceph, que fornece todos os recursos e benefícios de uma SAN convencional, permitindoum crescimento futuro.

Este capítulo apresenta informações detalhadas sobre como congurar uma infraestrutura decluster do Ceph juntamente com um iSCSI Gateway para que os hosts de clientes possam usaros dados armazenados remotamente como dispositivos de armazenamento local por meio doprotocolo iSCSI.

10.1 Armazenamento em blocos iSCSIiSCSI é uma implementação do comando SCSI (Small Computer System Interface) denido peloProtocolo IP, especicado na RFC 3720. O iSCSI é implementado como um serviço em que ocliente (iniciador) comunica-se com o servidor (destino) por meio de uma sessão na porta TCP3260. O endereço IP e a porta de destino iSCSI são chamados de portal iSCSI, em que um destinopode ser exposto por meio de um ou mais portais. A combinação de um destino e de um ou maisportais é denominada TPG (Target Portal Group – Grupo de Portais de Destino).

109 Armazenamento em blocos iSCSI SES 6

O protocolo da camada de vinculação de dados subjacente ao iSCSI costuma ser a Ethernet.Mais especicamente, as infraestruturas modernas do iSCSI usam 10 Gigabit Ethernet, ou redesmais rápidas, para obter o throughput ideal. A conectividade 10 Gigabit Ethernet entre o iSCSIGateway e o cluster de back end do Ceph é altamente recomendada.

10.1.1 Destino iSCSI do kernel do Linux

Originalmente, o destino iSCSI do kernel do Linux era chamado de LIO para linux-iscsi.org,o domínio original e o site do projeto. Por algum tempo, nada menos do que quatroimplementaçõ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 delinha principal do LIO usa o nome simples, porém um pouco ambíguo, "destino", para diferenciarentre "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 suportaFC (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 simplesmentereexportar 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íco do RBDque suporta acesso paralelizado de E/S de múltiplos caminhos às imagens RBD.

10.1.2 Iniciadores iSCSI

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

10.1.2.1 Linux

O iniciador padrão para a plataforma Linux é open-iscsi . O open-iscsi inicia um daemon,iscsid , que o usuário pode utilizar para descobrir destinos iSCSI em qualquer portalespecicado, efetuar login em destinos e mapear volumes iSCSI. O iscsid comunica-se com acamada intermediária do SCSI para criar dispositivos de blocos no kernel, e que depois o kernelpoderá tratar como qualquer outro dispositivo de blocos SCSI no sistema. É possível implantar oiniciador open-iscsi em conjunto com o recurso Device Mapper Multipath ( dm-multipath )para oferecer um dispositivo de blocos iSCSI altamente disponível.

110 Destino iSCSI do kernel do Linux SES 6

10.1.2.2 Microsoft Windows e Hyper-V

O iniciador iSCSI padrão para o sistema operacional Microsoft Windows é o Microsoft iSCSI. Oserviço iSCSI pode ser congurado por meio de uma GUI (Graphical User Interface – InterfaceGráca do Usuário) e suporta E/S de múltiplos caminhos para alta disponibilidade.

10.1.2.3 VMware

O iniciador iSCSI padrão para o VMware vSphere e o ESX é o do software VMware ESX:vmkiscsi . Quando habilitado, ele pode ser congurado pelo cliente do vSphere ou pelocomando vmkiscsi-tool . Em seguida, você pode formatar volumes de armazenamentoconectados por meio do adaptador de armazenamento iSCSI do vSphere com VMFS e usá-loscomo qualquer outro dispositivo de armazenamento da VM. O iniciador do VMware tambémsuporta E/S de múltiplos caminhos para alta disponibilidade.

10.2 Informações gerais sobre ceph-iscsiO ceph-iscsi combina os benefícios dos Dispositivos de Blocos RADOS com a versatilidadeuniversal do iSCSI. Ao executar o ceph-iscsi em um host de destino iSCSI (conhecido comoiSCSI Gateway), qualquer aplicativo que tenha que usar armazenamento de blocos poderá sebeneciar do Ceph, mesmo que ele não reconheça nenhum protocolo de cliente do Ceph. Em vezdisso, os usuários podem utilizar o iSCSI ou qualquer outro protocolo de front end de destinopara se conectar a um destino LIO, o que converte todas as operações de E/S de destino emarmazenamento RBD.

111 Informações gerais sobre ceph-iscsi SES 6

FIGURA 10.1: CLUSTER DO CEPH COM ÚNICO ISCSI GATEWAY

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

FIGURA 10.2: CLUSTER DO CEPH COM VÁRIOS ISCSI GATEWAYS

112 Informações gerais sobre ceph-iscsi SES 6

10.3 Considerações de implantaçãoUma conguração mínima do SUSE Enterprise Storage 6 com ceph-iscsi consiste nosseguintes componentes:

Um cluster de armazenamento do Ceph. O cluster do Ceph consiste em um mínimo dequatro servidores físicos que hospedam, pelo menos, oito OSDs (Object Storage Daemons– Daemons de Armazenamento de Objetos) cada. Nesse tipo de conguração, três nós OSDtambém são dobrados como host do monitor (MON).

Um servidor de destino iSCSI que executa o destino iSCSI do LIO, congurado por meiodo ceph-iscsi .

Um host do iniciador iSCSI, executando o open-iscsi (Linux), o Iniciador Microsoft iSCSI(Microsoft Windows) ou qualquer outra implementação de iniciador iSCSI compatível.

Uma conguração de produção recomendada do SUSE Enterprise Storage 6 com ceph-iscsiconsiste em:

Um cluster de armazenamento do Ceph. Um cluster de produção do Ceph consiste emqualquer número de nós OSD (costuma ser mais do que 10), com cada um executandonormalmente de 10 a 12 OSDs (Object Storage Daemons – Daemons de Armazenamentode Objetos), com pelo menos três hosts MON dedicados.

Vários servidores de destino iSCSI que executam o destino iSCSI do LIO, congurados pormeio do ceph-iscsi . Para failover e equilíbrio de carga do iSCSI, esses servidores devemexecutar um kernel com suporte ao módulo target_core_rbd . Os pacotes de atualizaçãoestão disponíveis no canal de manutenção do SUSE Linux Enterprise Server.

Qualquer número de hosts do iniciador iSCSI, executando o open-iscsi (Linux), oIniciador Microsoft iSCSI (Microsoft Windows) ou qualquer outra implementação deiniciador iSCSI compatível.

10.4 Instalação e configuraçãoEsta seção descreve as etapas para instalar e congurar um iSCSI Gateway no SUSE EnterpriseStorage.

113 Considerações de implantação SES 6

10.4.1 Implantar o iSCSI Gateway em um cluster do Ceph

É possível implantar o iSCSI Gateway durante o processo de implantação do cluster do Ceph ouadicioná-lo a um cluster existente usando o DeepSea.

Para incluir o iSCSI Gateway durante o processo de implantação do cluster, consulte aSeção 5.5.1.2, “Atribuição de função”.

Para adicionar o iSCSI Gateway a um cluster existente, consulte o Livro “Guia de Administração”,

Capítulo 2 “Administração do cluster do Salt”, Seção 2.2 “Adicionando novas funções aos nós”.

10.4.2 Criar imagens RBD

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 nalidade. Você pode criar um volumede qualquer host capaz de se conectar com seu cluster de armazenamento usando o utilitáriode linha de comando rbd do Ceph. Para isso, o cliente deve ter pelo menos um arquivo deconguraçã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 comandorbd create , especicando o tamanho do volume em megabytes. Por exemplo, para criar umvolume de 100 GB chamado “testvol” no pool denominado “iscsi-images”, execute:

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

10.4.3 Exportar imagens RBD por meio do iSCSI

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

NotaApenas os seguintes recursos de imagem RBD são suportados: layering , striping(v2) , exclusive-lock , fast-diff e data-pool . Não é possível exportar imagensRBD com qualquer outro recurso habilitado.

114 Implantar o iSCSI Gateway em um cluster do Ceph SES 6

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.x86:testvol :

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

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

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

DicaUse o comando help para mostrar a lista de comandos disponíveis no nó da conguraçãoatual.

Adicione a imagem RBD com o nome “testvol” ao pool “iscsi-images”:

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

Mapeie a imagem RBD para o destino:

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

NotaVocê pode usar ferramentas de nível mais baixo, como targetcli , para consultar aconguração local, mas sem a modicar.

DicaVocê pode usar o comando ls para revisar a conguração. Alguns nós da conguraçãotambém suportam o comando info , que podem ser usados para exibir informações maisdetalhadas.

115 Exportar imagens RBD por meio do iSCSI SES 6

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

10.4.4 Autenticação e controle de acesso

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

10.4.4.1 Nenhuma autenticação

"Nenhuma autenticação" signica que qualquer iniciador poderá acessar qualquer LUNno destino correspondente. Você pode habilitar "Nenhuma autenticação" desabilitando aautenticação ACL:

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

10.4.4.2 Autenticação ACL

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

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

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

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

10.4.4.3 Autenticação CHAP

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

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

116 Autenticação e controle de acesso SES 6

NotaOs 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 habilitar a autenticação CHAP mútua especicando os parâmetrosmutual_username e mutual_password no comando auth .

10.4.4.4 Discovery e autenticação mútua

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

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

NotaOs 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 especicar os parâmetros mutual_username e mutual_password nocomando discovery_auth .

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

gwcli > /iscsi-targets> discovery_auth nochap

10.4.5 Configurações avançadas

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

117 Configurações avançadas SES 6

AtençãoExceto se indicado de outra forma, não é recomendável mudar a conguração padrãodesses parâmetros.

10.4.5.1 Configurações de destino

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

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

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

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

As congurações de “target” disponíveis são:

default_cmdsn_depth

Profundidade padrão do CmdSN (Command Sequence Number – Número de Sequência doComando). Limita a quantidade de solicitações pendentes que um iniciador iSCSI pode terem 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 denida como 1, impede gravações em LUNs.

10.4.5.2 Configurações de disco

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

gwcli > /> cd /disks/rbd/testvol

118 Configurações avançadas SES 6

gwcli > /disks/rbd/testvol> info

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

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

As congurações de "disk” disponíveis são:

block_size

Tamanho do bloco do dispositivo subjacente.

emulate_3pc

Se denida como 1, habilita Third Party Copy (Cópia de Terceiros).

emulate_caw

Se denida como 1, habilita Compare (Comparar) e Write (Gravar).

emulate_dpo

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

emulate_fua_read

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

emulate_fua_write

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

emulate_model_alias

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

emulate_pr

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

DicaNão será recomendável denir backstore_emulate_pr como 0 se os iniciadores iSCSInão exigirem suporte para Reserva SCSI.

emulate_rest_reord

Se denida como 0, o Modicador de Algoritmo de Fila terá Reordenação Restrita.

119 Configurações avançadas SES 6

emulate_tas

Se denida como 1, habilita o Task Aborted Status (Status Interrompido da Tarefa).

emulate_tpu

Se denida como 1, habilita Thin Provisioning Unmap (Anulação do Mapeamento deAprovisionamento Dinâmico).

emulate_tpws

Se denida como 1, habilita Thin Provisioning Write Same (Mesma Gravação deAprovisionamento Dinâmico).

emulate_ua_intlck_ctrl

Se denida como 1, habilita Unit Attention Interlock (Interbloqueio de Atenção deUnidade).

emulate_write_cache

Se denida como 1, ativa o recurso Write Cache Enable (Habilitação de Gravação deCache).

enforce_pr_isids

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

is_nonrot

Se denida 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 la.

120 Configurações avançadas SES 6

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 armazenamentopersistente, mesmo que o cliente não o tenha solicitado usando aptpl=1 . Isso não temefeito com o back end do RBD do kernel para LIO, ele sempre mantém o estado de reservapersistente. Idealmente, a opção target_core_rbd deverá forçá-lo como “1” e emitir umerro se alguém tentar desabilitá-lo usando congfs.

unmap_zeroes_data

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

10.5 Exportando imagens de dispositivo de blocosRADOS usando tcmu-runnerO 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: Technology PreviewAtualmente, as implantações do iSCSI Gateway com base no tcmu-runner estão naversão Technology Preview.

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

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

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

121 Exportando imagens de dispositivo de blocos RADOS usando tcmu-runner SES 6

NotaAo usar o tcmu-runner , o recurso exclusive-lock deve estar habilitado na imagemRBD exportada.

122 Exportando imagens de dispositivo de blocos RADOS usando tcmu-runner SES 6

11 Instalação do CephFS

O sistema de arquivos Ceph (CephFS) é um sistema de arquivos compatível com POSIX que usaum cluster de armazenamento do Ceph para armazenar seus dados. O CephFS usa o mesmosistema de cluster que os dispositivos de blocos do Ceph, o armazenamento de objetos do Cephcom APIs S3 e Swift ou as vinculações nativas ( librados ).

Para usar o CephFS, você precisa ter um cluster de armazenamento do Ceph em execução e, nomínimo, um servidor de metadados Ceph.

11.1 Cenários e diretrizes suportados do CephFSCom o SUSE Enterprise Storage 6, a SUSE inclui suporte ocial para diversos cenários em queo componente distribuído e de expansão horizontal CephFS é usado. Essa entrada descreve oslimites físicos e apresenta orientações para os casos de uso sugeridos.

Uma implantação suportada do CephFS deve atender a estes requisitos:

No mínimo, um Servidor de Metadados. A SUSE recomenda implantar vários nós com afunção MDS. Apenas um será ativo , os demais serão passivos . Lembre-se de mencionartodos os nós MON no comando mount ao montar o CephFS de um cliente.

Os clientes são SUSE Linux Enterprise Server 12 SP3 ou mais recente, ou SUSE LinuxEnterprise Server 15 ou mais recente, usando o driver de módulo do kernel cephfs . Omódulo FUSE não é suportado.

As cotas do CephFS são suportadas no SUSE Enterprise Storage 6 e podem ser denidas emqualquer subdiretório do sistema de arquivos Ceph. A cota restringe o número de bytesou de arquivos armazenados abaixo do ponto especicado na hierarquia de diretórios.Para obter mais informações, consulte o Livro “Guia de Administração”, Capítulo 19 “Sistema de

arquivos em cluster”, Seção 19.6 “Definindo cotas do CephFS”.

123 Cenários e diretrizes suportados do CephFS SES 6

O CephFS suporta mudanças de layout de arquivo, conforme documentado em Seção 11.3.4,

“Layouts de arquivos”. No entanto, embora o sistema de arquivos seja montado por qualquercliente, novos pools de dados não podem ser adicionados a um sistema de arquivos CephFSexistente ( ceph mds add_data_pool ). Eles apenas podem ser adicionados enquanto osistema de arquivos está desmontado.

No mínimo, um Servidor de Metadados. A SUSE recomenda implantar vários nós coma função MDS. Por padrão, os daemons adicionais do MDS começam como daemons destandby , agindo como backups para o MDS ativo. Vários daemons ativos do MDS tambémsão suportados (consulte a seção Seção 11.3.2, “Tamanho do cluster MDS”).

11.2 Servidor de metadados CephO servidor de metadados Ceph (MDS) armazena metadados para o CephFS. Os dispositivos deblocos e o armazenamento de objetos do Ceph não usam o MDS. Os MDSs permitem que osusuários do sistema de arquivos POSIX executem comandos básicos, como ls ou find , sem anecessidade de uma carga enorme no cluster de armazenamento do Ceph.

11.2.1 Adicionando um servidor de metadados

Você pode implantar o MDS durante o processo inicial de implantação do cluster, conformedescrito na Seção 5.3, “Implantação do cluster”, ou adicioná-lo a um cluster já implantado, conformedescrito no Livro “Guia de Administração”, Capítulo 2 “Administração do cluster do Salt”, Seção 2.1

“Adicionando novos nós do cluster”.

Após implantar o MDS, permita o serviço Ceph OSD/MDS na conguração do rewall do servidorno qual o MDS está implantado: Inicie o yast , navegue até Security and Users (Segurança eUsuários) Firewall Allowed Services (Serviços Permitidos) e, no menu suspenso Service to Allow(Serviço para Permitir), selecione Ceph OSD/MDS. Se o nó MDS do Ceph não permitir tráfegocompleto, haverá falha na montagem do sistema de arquivos, mesmo que outras operaçõescontinuem funcionando apropriadamente.

11.2.2 Configurando um servidor de metadados

Você pode ajustar o comportamento do MDS inserindo as opções relevantes no arquivo deconguração ceph.conf .

124 Servidor de metadados Ceph SES 6

CONFIGURAÇÕES DO SERVIDOR DE METADADOS

mon force standby active

Se denida como “true” (padrão), monitora a reprodução de standby forçada para carativa. Denida nas seções [mon] ou [global] .

mds cache memory limit

O limite exível de memória (em bytes) que o MDS impõe ao cache. Os administradoresdevem usá-lo no lugar da conguração antiga mds cache size . O padrão é 1 GB.

mds cache reservation

A reserva de cache (memória ou inodes) para manutenção do cache do MDS. Quando oMDS começar a usar a reserva, ele revogará o estado do cliente até o tamanho do cachereduzir para restaurar a reserva. O padrão é 0,05.

mds cache size

O número de inodes para armazenar em cache. Um valor de 0 (padrão) indica um númeroilimitado. É recomendado usar mds cache memory limit para limitar a quantidade dememória que o cache do MDS usa.

mds cache mid

O ponto de inserção para novos itens no LRU do cache (a partir da parte superior). Opadrão é 0.7.

mds dir commit ratio

A fração do diretório que foi modicada antes que o Ceph se comprometa usando umaatualização completa, em vez da atualização parcial. O padrão é 0.5.

mds dir max commit size

O tamanho máximo de uma atualização de diretório antes que o Ceph o divida emtransações menores. O padrão é 90 MB.

mds decay halflife

A meia-vida da temperatura do cache do MDS. O padrão é 5.

mds beacon interval

A frequência em segundos das mensagens de beacon enviadas ao monitor. O padrão é 4.

mds beacon grace

O intervalo sem beacons antes que o Ceph declare um MDS como lento e possivelmenteo substitua. O padrão é 15.

125 Configurando um servidor de metadados SES 6

mds blacklist interval

A duração da lista negra para MDSs com falha no mapa OSD. Essa conguração controlaquanto tempo os daemons MDS com falha permanecerão na lista negra do mapa OSD.Ela não tem efeito sobre o tempo que um elemento permanece na lista negra quando oadministrador o inclui na lista negra manualmente. Por exemplo, o comando ceph osdblacklist add ainda usará o tempo padrão de lista negra. O padrão é 24*60.

mds reconnect timeout

O intervalo em segundos para esperar os clientes se reconectarem durante a reinicializaçãodo MDS. O padrão é 45.

mds tick interval

Com que frequência o MDS realiza as tarefas periódicas internas. O padrão é 5.

mds dirstat min interval

O intervalo mínimo em segundos para tentar evitar a propagação de estatísticas recursivasaté a árvore. O padrão é 1.

mds scatter nudge interval

A rapidez com que as mudanças do dirstat se propagam. O padrão é 5.

mds client prealloc inos

O número de inodes para pré-alocar por sessão do cliente. O padrão é 1000.

mds early reply

Determina se o MDS deve permitir que os clientes vejam os resultados da solicitação antesque eles se comprometam com o diário. O padrão é “true”.

mds use tmap

Usar o mapa trivial para atualizações de diretório. O padrão é “true”.

mds default dir hash

A função a ser usada para hashing de arquivos entre fragmentos de diretório. O padrãoé 2 (isto é, “rjenkins”).

mds log skip corrupt events

Determina se o MDS deve tentar ignorar os eventos de diário corrompidos durante areprodução do diário. O padrão é “false” (falso).

mds log max events

O máximo de eventos no diário antes de iniciar o corte. Dena como -1 (padrão) paradesabilitar limites.

126 Configurando um servidor de metadados SES 6

mds log max segments

O número máximo de segmentos (objetos) no diário antes de iniciar o corte. Dena como-1 para desabilitar limites. O padrão é 30.

mds log max expiring

O número máximo de segmentos a serem expirados em paralelos. O padrão é 20.

mds log eopen size

O número máximo de inodes em um evento do EOpen. O padrão é 100.

mds bal sample interval

Determina com que frequência é feita uma amostra da temperatura do diretório paradecisões de fragmentação. O padrão é 3.

mds bal replicate threshold

A temperatura máxima antes que o Ceph tente replicar os metadados para outros nós. Opadrão é 8000.

mds bal unreplicate threshold

A temperatura mínima antes que o Ceph pare de replicar os metadados para outros nós.O padrão é 0.

mds bal split size

O tamanho máximo do diretório antes que o MDS divida um fragmento do diretório embits menores. O padrão é 10000.

mds bal split rd

A temperatura máxima de leitura do diretório antes que o Ceph divida um fragmento dodiretório. O padrão é 25000.

mds bal split wr

A temperatura máxima de gravação do diretório antes que o Ceph divida um fragmentodo diretório. O padrão é 10000.

mds bal split bits

O número de bits que será usado para dividir um fragmento do diretório. O padrão é 3.

mds bal merge size

O tamanho mínimo do diretório antes que o Ceph tente fundir fragmentos adjacentes dodiretório. O padrão é 50.

mds bal interval

A frequência em segundos de trocas de carga de trabalho entre os MDSs. O padrão é 10.

127 Configurando um servidor de metadados SES 6

mds bal fragment interval

O atraso em segundos entre um fragmento ser capaz de se dividir ou fundir e a execuçãoda mudança de fragmentação. O padrão é 5.

mds bal fragment fast factor

A proporção pela qual os fragmentos podem exceder o tamanho dividido antes de umadivisão ser executada imediatamente, ignorando o intervalo do fragmento. O padrão é 1.5.

mds bal fragment size max

O tamanho máximo de um fragmento antes de quaisquer novas entradas serem rejeitadascom ENOSPC. O padrão é 100000.

mds bal idle threshold

A temperatura mínima antes que o Ceph migre uma subárvore de volta para seu pai. Opadrão é 0.

mds bal mode

O método para calcular a carga do MDS:

0 = Híbrido.

1 = Taxa de solicitação e latência.

2 = Carga da CPU.

O padrão é 0.

mds bal min rebalance

A temperatura mínima da subárvore antes da migração do Ceph. O padrão é 0.1.

mds bal min start

A temperatura mínima da subárvore antes que o Ceph pesquise uma subárvore. O padrãoé 0.2.

mds bal need min

A fração mínima do tamanho da subárvore de destino a ser aceita. O padrão é 0.8.

mds bal need max

A fração máxima do tamanho da subárvore de destino a ser aceita. O padrão é 1.2.

mds bal midchunk

O Ceph migrará qualquer subárvore que seja maior do que essa fração do tamanho dasubárvore de destino. O padrão é 0.3.

128 Configurando um servidor de metadados SES 6

mds bal minchunk

O Ceph ignorará qualquer subárvore que seja menor do que essa fração do tamanho dasubárvore de destino. O padrão é 0.001.

mds bal target removal min

O número mínimo de iterações do balanceador antes que o Ceph remova um destino doMDS antigo do mapa MDS. O padrão é 5.

mds bal target removal max

O número máximo de iterações do balanceador antes que o Ceph remova um destino doMDS antigo do mapa MDS. O padrão é 10.

mds replay interval

O intervalo de poll do diário durante o modo de reprodução de standby ("standby ativo").O padrão é 1.

mds shutdown check

O intervalo para polling do cache durante o encerramento do MDS. O padrão é 0.

mds thrash fragments

O Ceph fragmentará ou fundirá os diretórios aleatoriamente. O padrão é 0.

mds dump cache on map

O Ceph descartará o conteúdo do cache do MDS em um arquivo em cada mapa MDS. Opadrão é “false” (falso).

mds dump cache after rejoin

O Ceph descartará o conteúdo do cache do MDS para um arquivo após reingressar no cachedurante a recuperação. O padrão é “false” (falso).

mds standby for name

Um daemon MDS servirá de standby para outro daemon MDS do nome especicado nestaconguração.

mds standby for rank

Um daemon MDS servirá de standby para um daemon MDS desta posição. O padrão é -1.

mds standby replay

Determina se um daemon MDS do Ceph deve fazer poll e reproduzir o registro de um MDSativo ("standby ativo"). O padrão é “false” (falso).

mds min caps per client

Denir o número mínimo de recursos que um cliente pode armazenar. O padrão é 100.

129 Configurando um servidor de metadados SES 6

mds max ratio caps per client

Denir a proporção máxima de recursos atuais que podem ser chamados novamentedurante uma pressão do cache do MDS. O padrão é 0.8.

CONFIGURAÇÕES DE DIÁRIO (JOURNALER) DO SERVIDOR DE METADADOS

journaler write head interval

Com que frequência atualizar o objeto de início do diário. O padrão é 15.

journaler prefetch periods

Quantos períodos de distribuição serão lidos primeiro na reprodução do diário. O padrãoé 10.

journal prezero periods

Quantos períodos de distribuição serão zerados à frente da posição de gravação. O padrãoé 10.

journaler batch interval

Latência máxima adicional em segundos que incorremos articialmente. O padrão é 0.001.

journaler batch max

Número máximo de bytes para atrasar o descarregamento. O padrão é 0.

11.3 CephFSQuando você tem um cluster de armazenamento do Ceph saudável com pelo menos um servidorde metadados Ceph, pode criar e montar o sistema de arquivos Ceph. Verique se o seu clientetem conectividade de rede e um chaveiro de autenticação apropriado.

11.3.1 Criando o CephFS

Um CephFS requer pelo menos dois pools RADOS: um para dados e outro para metadados. Aocongurar esses pools, considere o seguinte:

Uso de um nível mais alto de replicação para o pool de metadados, pois qualquer perdade dados nesse pool pode tornar todo o sistema de arquivos inacessível.

Uso de armazenamento de latência menor, como SSDs, para o pool de metadados, pois issomelhora a latência observada das operações do sistema de arquivos nos clientes.

130 CephFS SES 6

Ao atribuir um role-mds em policy.cfg , os pools necessários são criados automaticamente.Você pode criar manualmente os pools cephfs_data e cephfs_metadata para ajuste dodesempenho manual antes de congurar o Servidor de Metadados. O DeepSea não criará essespools se eles já existirem.

Para obter mais informações sobre gerenciamento de pools, consulte o Livro “Guia de

Administração”, Capítulo 11 “Gerenciando pools de armazenamento”.

Para criar os dois pools necessários (por exemplo, “cephfs_data” e “cephfs_metadata”) com ascongurações padrão para uso com o CephFS, execute os seguintes comandos:

cephadm@adm > ceph osd pool create cephfs_data pg_numcephadm@adm > ceph osd pool create cephfs_metadata pg_num

É possível usar os pools EC em vez dos pools replicados. É recomendável usar apenas os poolsEC para requisitos de baixo desempenho e acesso aleatório com pouca frequência. Por exemplo,armazenamento frio, backups, arquivamento. O CephFS em pools EC requer a habilitação doBlueStore, e o pool deve ter a opção allow_ec_overwrite denida. É possível denir essaopção executando ceph osd pool set ec_pool allow_ec_overwrites true .

Apagar a codicação aumenta signicativamente o overhead das operações do sistema dearquivos, principalmente de pequenas atualizações. Esse overhead é inerente ao uso do recursode apagar codicação como mecanismo de tolerância a falhas. Essa desvantagem é compensadapela redução substancial do overhead de espaço de armazenamento.

Quando os pools são criados, você pode habilitar o sistema de arquivos com o comando cephfs new :

cephadm@adm > ceph fs new fs_name metadata_pool_name data_pool_name

Por exemplo:

cephadm@adm > ceph fs new cephfs cephfs_metadata cephfs_data

Você pode vericar se o sistema de arquivos foi criado listando todos os CephFSs disponíveis:

cephadm@adm > ceph fs ls name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

Quando o sistema de arquivos for criado, o MDS poderá inserir um estado ativo. Por exemplo,em um único sistema MDS:

cephadm@adm > ceph mds state5: 1/1/1 up

131 Criando o CephFS SES 6

Dica: Mais tópicosVocê pode encontrar mais informações sobre tarefas especícas, por exemplo, montar,desmontar e conguração avançada do CephFS, no Livro “Guia de Administração”, Capítulo

19 “Sistema de arquivos em cluster”.

11.3.2 Tamanho do cluster MDS

Vários daemons MDS ativos podem atender a uma instância do CephFS. Todos os daemons MDSativos atribuídos a uma instância do CephFS distribuirão a árvore de diretório do sistema dearquivos entre eles e, portanto, dividirão a carga de clientes simultâneos. Para adicionar umdaemon MDS ativo a uma instância do CephFS, é necessário um standby separado. Inicie umdaemon adicional ou use uma instância de standby existente.

O comando a seguir exibirá o número atual de daemons MDS ativos e passivos.

cephadm@adm > ceph mds stat

O comando a seguir dene o número de MDSs ativos como dois em uma instância do sistemade arquivos.

cephadm@adm > ceph fs set fs_name max_mds 2

Para reduzir o cluster MDS antes de uma atualização, duas etapas são necessárias.Primeiramente, dena max_mds de forma que permaneça apenas uma instância:

cephadm@adm > ceph fs set fs_name max_mds 1

e, em seguida, desative explicitamente os outros daemons MDS ativos:

cephadm@adm > ceph mds deactivate fs_name:rank

em que rank é o número de um daemon MDS ativo de uma instância do sistema de arquivos,variando de 0 a max_mds -1.

Recomendamos que pelo menos um MDS seja deixado como daemon de standby.

11.3.3 Cluster e atualizações do MDS

Durante as atualizações do Ceph, os ags de recursos em uma instância do sistema de arquivospodem mudar (normalmente, adicionando novos recursos). Os daemons incompatíveis (comoos de versões mais antigas) não funcionam com um conjunto de recursos incompatíveis e se

132 Tamanho do cluster MDS SES 6

recusarão a iniciar. Isso signica que a atualização e a reinicialização de um daemon podemfazer com que todos os outros daemons ainda não atualizados parem e se recusem a iniciar.Por esse motivo, recomendamos reduzir o cluster MDS ativo para o tamanho 1 e parar todosos daemons de standby antes de atualizar o Ceph. Veja a seguir as etapas manuais para esteprocedimento de atualização:

1. Atualize os pacotes relacionados ao Ceph usando o zypper .

2. Reduza o cluster MDS ativo, conforme descrito acima, para uma instância e pare todos osdaemons MDS de standby usando as unidades systemd deles em todos os outros nós:

cephadm@mds > systemctl stop ceph-mds\*.service ceph-mds.target

3. Somente depois disso, reinicie o único daemon MDS restante, o que faz com que ele sejareiniciado usando o binário atualizado.

cephadm@mds > systemctl restart ceph-mds\*.service ceph-mds.target

4. Reinicie todos os outros daemons MDS e redena a conguração max_mds desejada.

cephadm@mds > systemctl start ceph-mds.target

Se você usa o DeepSea, ele seguirá esse procedimento se o pacote ceph for atualizado duranteas fases 0 e 4. É possível executar esse procedimento enquanto os clientes estão com a instânciado CephFS montada e a E/S está em andamento. No entanto, observe que haverá uma pausade E/S muito breve durante a reinicialização do MDS ativo. Os clientes serão recuperadosautomaticamente.

Convém reduzir a carga de E/S o máximo possível antes de atualizar um cluster MDS. Um clusterMDS ocioso passará por esse procedimento de atualização mais rapidamente. Por outro lado,em um cluster excessivamente carregado com vários daemons MDS, é essencial reduzir a cargade maneira antecipada para evitar que um único daemon MDS que sobrecarregado com E/S contínua.

11.3.4 Layouts de arquivos

O layout de um arquivo controla como o conteúdo dele é mapeado para objetos RADOS do Ceph.É possível ler e gravar o layout de um arquivo usando atributos estendidos virtuais ou xattrs, naforma abreviada.

133 Layouts de arquivos SES 6

O nome dos xattrs de layout depende se um arquivo é regular ou um diretório. Os xattrsde layout de arquivos regulares são denominados ceph.file.layout . Os xattrs de layoutde diretórios são denominados ceph.dir.layout . Onde os exemplos fazem referência aoceph.file.layout , substitua a parte .dir. conforme apropriado ao trabalhar com diretórios.

11.3.4.1 Campos de layout

Os seguintes campos de atributo são reconhecidos:

pool

ID ou nome de um pool RADOS em que os objetos de dados de um arquivo serãoarmazenados.

pool_namespace

Namespace RADOS em um pool de dados no qual os objetos serão gravados. Por padrão,ele está vazio, o que signica o namespace padrão.

stripe_unit

O tamanho em bytes de um bloco de dados utilizado na distribuição RAID 0 de um arquivo.Todas as unidades de distribuição para um arquivo têm tamanho igual. A última unidadede distribuição normalmente está incompleta. Ela representa os dados no m do arquivoe o "espaço" não utilizado além dele até o m do tamanho da unidade de faixa xa.

stripe_count

O número de unidades de distribuição consecutivas que constituem uma “faixa” RAID 0de dados do arquivo.

object_size

O tamanho em bytes de objetos RADOS nos quais os dados do arquivo são empacotados.

Dica: Tamanhos de ObjetosO RADOS impõe um limite congurável aos tamanhos dos objetos. Se você aumentaros tamanhos dos objetos CephFS além desse limite, as gravações poderão falhar.A conguração do OSD é osd_max_object_size , que por padrão é de 128 MB.Objetos RADOS muito grandes impedem a operação contínua do cluster. Portanto,aumentar o limite de tamanho do objeto além do padrão não é recomendado.

134 Layouts de arquivos SES 6

11.3.4.2 Layout de leitura com getfattr

Use o comando getfattr para ler as informações de layout de um arquivo de exemplo filecomo uma única string:

root # touch fileroot # getfattr -n ceph.file.layout file# file: fileceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=419430

Leia os campos de layout individuais:

root # getfattr -n ceph.file.layout.pool file# file: fileceph.file.layout.pool="cephfs_data"root # getfattr -n ceph.file.layout.stripe_unit file# file: fileceph.file.layout.stripe_unit="4194304"

Dica: ID ou Nome do PoolAo ler os layouts, o pool costuma ser indicado por nome. No entanto, em casos raros emque os pools apenas foram criados, o ID pode ser a saída.

Os diretórios não têm um layout explícito até que ele seja personalizado. Há falha nas tentativasde ler o layout se ele nunca foi modicado: isso indica que o layout do próximo diretório deorigem com um layout explícito será usado.

root # mkdir dirroot # getfattr -n ceph.dir.layout dirdir: ceph.dir.layout: No such attributeroot # setfattr -n ceph.dir.layout.stripe_count -v 2 dirroot # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"

11.3.4.3 Gravando layouts com setfattr

Use o comando setfattr para modicar os campos de layout de um arquivo de exemplo file :

cephadm@adm > ceph osd lspools0 rbd1 cephfs_data

135 Layouts de arquivos SES 6

2 cephfs_metadataroot # setfattr -n ceph.file.layout.stripe_unit -v 1048576 fileroot # setfattr -n ceph.file.layout.stripe_count -v 8 file# Setting pool by ID:root # setfattr -n ceph.file.layout.pool -v 1 file# Setting pool by name:root # setfattr -n ceph.file.layout.pool -v cephfs_data file

Nota: Arquivo VazioQuando os campos de layout de um arquivo são modicados usando setfattr , essearquivo precisa estar vazio; do contrário, ocorrerá um erro.

11.3.4.4 Limpando layouts

Para remover um layout explícito de um diretório de exemplo mydir e reverter para herdar olayout de sua origem, execute o seguinte:

root # setfattr -x ceph.dir.layout mydir

Da mesma forma, se você deniu o atributo "pool_namespace" e deseja modicar o layout parausar o namespace padrão, execute:

# Create a directory and set a namespace on itroot # mkdir mydirroot # setfattr -n ceph.dir.layout.pool_namespace -v foons mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a pool_namespace=foons"

# Clear the namespace from the directory's layoutroot # setfattr -x ceph.dir.layout.pool_namespace mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a"

11.3.4.5 Herança de layouts

Os arquivos herdam o layout do diretório pai deles no momento da criação. No entanto, asmudanças subsequentes no layout do diretório pai não afetam os lhos:

root # getfattr -n ceph.dir.layout dir

136 Layouts de arquivos SES 6

# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# file1 inherits its parent's layoutroot # touch dir/file1root # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# update the layout of the directory before creating a second fileroot # setfattr -n ceph.dir.layout.stripe_count -v 4 dirroot # touch dir/file2

# file1's layout is unchangedroot # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# ...while file2 has the parent directory's new layoutroot # getfattr -n ceph.file.layout dir/file2# file: dir/file2ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"

Os arquivos criados como descendentes do diretório também herdarão o layout se os diretóriosintermediários não tiverem layouts denidos:

root # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"root # mkdir dir/childdirroot # getfattr -n ceph.dir.layout dir/childdirdir/childdir: ceph.dir.layout: No such attributeroot # touch dir/childdir/grandchildroot # getfattr -n ceph.file.layout dir/childdir/grandchild# file: dir/childdir/grandchildceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"

137 Layouts de arquivos SES 6

11.3.4.6 Adicionando um pool de dados ao servidor de metadados

Antes que você possa usar um pool com o CephFS, precisa adicioná-lo ao Servidor de Metadados:

cephadm@adm > ceph fs add_data_pool cephfs cephfs_data_ssdcephadm@adm > ceph fs ls # Pool should now show up.... data pools: [cephfs_data cephfs_data_ssd ]

Dica: Chaves cephxVerique se as chaves cephx permitem que o cliente acesse esse novo pool.

Em seguida, você poderá atualizar o layout em um diretório no CephFS para usar o pooladicionado:

root # mkdir /mnt/cephfs/myssddirroot # setfattr -n ceph.dir.layout.pool -v cephfs_data_ssd /mnt/cephfs/myssddir

Todos os novos arquivos criados dentro desse diretório agora herdarão o layout dele earmazenarão os dados em seu pool recém-adicionado. Talvez você observe que o número deobjetos em seu pool de dados principal continua aumentando, mesmo que os arquivos estejamsendo criados no pool recém-adicionado. Isso é normal: os dados do arquivo são armazenadosno pool especicado pelo layout, mas uma pequena quantidade de metadados é mantida no poolde dados principal para todos os arquivos.

138 Layouts de arquivos SES 6

12 Instalação do NFS Ganesha

O NFS Ganesha concede acesso de NFS ao Object Gateway ou CephFS. No SUSE EnterpriseStorage 6, as versões 3 e 4 do NFS são suportadas. O NFS Ganesha é executado no espaço dousuário, em vez do kernel, e interage diretamente com o Object Gateway ou o CephFS.

Atenção: Acesso a Vários ProtocolosOs clientes nativos CephFS e NFS não são restritos por bloqueios de arquivos obtidospor meio do Samba, e vice-versa. Os aplicativos que dependem do bloqueio de arquivoscompatível com vários protocolos poderão ter os dados corrompidos se os caminhos decompartilhamento do Samba com suporte do CephFS forem acessados por outros meios.

12.1 Preparação

12.1.1 Informações Gerais

Para implantar o NFS Ganesha com êxito, você precisa adicionar uma função role-ganeshaao /srv/pillar/ceph/proposals/policy.cfg . Para obter os detalhes, consulte a Seção 5.5.1,

“Arquivo policy.cfg”. O NFS Ganesha também precisa da role-rgw ou da role-mds nopolicy.cfg .

Embora seja possível instalar e executar o servidor NFS Ganesha em um nó do Ceph existente,é recomendável executá-lo em um host dedicado com acesso ao cluster do Ceph. Normalmente,os hosts de clientes não fazem parte do cluster, mas eles precisam ter acesso via rede ao servidorNFS Ganesha.

Para habilitar o servidor NFS Ganesha a qualquer momento após a instalação inicial, adicionea role-ganesha ao policy.cfg e reexecute pelo menos as fases 2 e 4 do DeepSea. Para obteros detalhes, consulte a Seção 5.3, “Implantação do cluster”.

O NFS Ganesha é congurado por meio do arquivo /etc/ganesha/ganesha.conf que existe nonó do NFS Ganesha. No entanto, esse arquivo é sobregravado toda vez que a fase 4 do DeepSeaé executada. Portanto, recomendamos editar o gabarito usado pelo Salt, que é o arquivo /srv/salt/ceph/ganesha/files/ganesha.conf.j2 no master Salt. Para obter detalhes sobre oarquivo de conguração, consulte o Livro “Guia de Administração”, Capítulo 21 “NFS Ganesha: Exportar

dados do Ceph pelo NFS”, Seção 21.2 “Configuração”.

139 Preparação SES 6

12.1.2 Resumo dos requisitos

Os seguintes requisitos devem ser atendidos antes da execução das fases 2 e 4 do DeepSea parainstalar o NFS Ganesha:

No mínimo, um nó precisa receber a função role-ganesha .

Você pode denir apenas uma role-ganesha por minion.

O NFS Ganesha precisa de um Object Gateway ou CephFS para funcionar.

O NFS com base no kernel precisa ser desabilitado nos minions com a função role-ganesha .

12.2 Exemplo de instalaçãoEste procedimento fornece um exemplo de instalação que usa as FSAL (File System AbstractionLayers – Camadas de Abstração do Sistema de Arquivos) do Object Gateway e do CephFS doNFS Ganesha.

1. Se você não fez isto, execute as fases 0 e 1 do DeepSea antes de continuar esseprocedimento.

root@master # salt-run state.orch ceph.stage.0root@master # salt-run state.orch ceph.stage.1

2. Após executar a fase 1 do DeepSea, edite o /srv/pillar/ceph/proposals/policy.cfge adicione a linha

role-ganesha/cluster/NODENAME

Substitua NODENAME pelo nome de um nó no cluster.Verique também se uma role-mds e uma role-rgw foram atribuídas.

3. Execute pelo menos as fases 2 e 4 do DeepSea. É recomendável executar a fase 3 entre elas.

root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3 # optional but recommendedroot@master # salt-run state.orch ceph.stage.4

140 Resumo dos requisitos SES 6

4. Verique se o NFS Ganesha está ativo conrmando se o serviço NFS Ganesha está emexecução no nó do minion:

root@master # salt -I roles:ganesha service.status nfs-ganeshaMINION_ID: True

12.3 Configuração ativa-passiva de altadisponibilidadeEsta seção apresenta um exemplo de como denir uma conguração ativa-passiva de dois nósdos servidores NFS Ganesha. A conguração requer a SUSE Linux Enterprise High AvailabilityExtension. Os dois nós são denominados earth e mars .

Importante: Colocation dos ServiçosOs serviços que têm a própria tolerância a falhas e o próprio balanceamento de carga nãodevem ser executados em nós do cluster com limitação de serviços de failover. Portanto,não execute os serviços Ceph Monitor, Servidor de Metadados, iSCSI ou Ceph OSD emcongurações de Alta Disponibilidade.

Para obter detalhes sobre a SUSE Linux Enterprise High Availability Extension, consulte https://

www.suse.com/documentation/sle-ha-15/ .

12.3.1 Instalação básica

Nessa conguração, earth tem o endereço IP 192.168.1.1 , e mars tem o endereço192.168.1.2 .

Além disso, dois endereços IP virtuais utuantes são usados, permitindo aos clientes seconectarem ao serviço independentemente do nó físico no qual está sendo executado.192.168.1.10 é usado para administração do cluster com Hawk2, e 192.168.2.1 é usadoexclusivamente para exportações NFS. Isso facilita aplicar as restrições de segurança mais tarde.

O procedimento a seguir descreve a instalação de exemplo. Mais detalhes podem serencontrados em https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/

art_sleha_install_quick.html .

141 Configuração ativa-passiva de alta disponibilidade SES 6

1. Prepare os nós do NFS Ganesha no master Salt:

a. Execute as fases 0 e 1 do DeepSea.

root@master # salt-run state.orch ceph.stage.0root@master # salt-run state.orch ceph.stage.1

b. Atribua aos nós earth e mars a função role-ganesha em /srv/pillar/ceph/proposals/policy.cfg :

role-ganesha/cluster/earth*.slsrole-ganesha/cluster/mars*.sls

c. Execute as fases de 2 a 4 do DeepSea.

root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4

2. Registre a SUSE Linux Enterprise High Availability Extension no earth e no mars .

root # SUSEConnect -r ACTIVATION_CODE -e E_MAIL

3. Instale o ha-cluster-bootstrap em ambos os nós:

root # zypper in ha-cluster-bootstrap

4. a. Inicialize o cluster no earth :

root@earth # ha-cluster-init

b. Permita que o mars ingresse no cluster:

root@mars # ha-cluster-join -c earth

5. Verique o status do cluster. Você deve ver dois nós adicionados ao cluster:

root@earth # crm status

6. Em ambos os nós, desabilite o início automático do serviço NFS Ganesha no momento dainicialização:

root # systemctl disable nfs-ganesha

142 Instalação básica SES 6

7. Inicie o shell do crm no earth :

root@earth # crm configure

Os próximos comandos são executados no shell do crm.

8. No earth , execute o shell do crm para executar os comandos a seguir a m de conguraro recurso nos daemons do NFS Ganesha como clone do tipo de recurso systemd:

crm(live)configure# primitive nfs-ganesha-server systemd:nfs-ganesha \op monitor interval=30scrm(live)configure# clone nfs-ganesha-clone nfs-ganesha-server meta interleave=truecrm(live)configure# commitcrm(live)configure# status 2 nodes configured 2 resources configured

Online: [ earth mars ]

Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ]

9. Crie um IPAddr2 primitivo com o shell do crm:

crm(live)configure# primitive ganesha-ip IPaddr2 \params ip=192.168.2.1 cidr_netmask=24 nic=eth0 \op monitor interval=10 timeout=20

crm(live)# statusOnline: [ earth mars ]Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ] ganesha-ip (ocf::heartbeat:IPaddr2): Started earth

10. Para congurar um relacionamento entre o servidor NFS Ganesha e o IP Virtual utuante,usamos colocalização e ordenação.

crm(live)configure# colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clonecrm(live)configure# order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs-ganesha-clone ganesha-ip

143 Instalação básica SES 6

11. Use o comando mount do cliente para garantir que a conguração do cluster foi concluída:

root # mount -t nfs -v -o sync,nfsvers=4 192.168.2.1:/ /mnt

12.3.2 Limpar recursos

Em caso de falha em um dos nós do NFS Ganesha (por exemplo, earth ), corrija o problemae limpe o recurso. Apenas depois que o recurso estiver limpo, será possível fazer failback delepara o earth , caso haja falha no mars do NFS Ganesha.

Para limpar o recurso:

root@earth # crm resource cleanup nfs-ganesha-clone earthroot@earth # crm resource cleanup ganesha-ip earth

12.3.3 Configurando o recurso de ping

Pode acontecer de um servidor não conseguir acessar o cliente por causa de um problema derede. Um recurso de ping pode detectar e minimizar esse problema. A conguração desse recursoé opcional.

1. Dena o recurso de ping:

crm(live)configure# primitive ganesha-ping ocf:pacemaker:ping \ params name=ping dampen=3s multiplier=100 host_list="CLIENT1 CLIENT2" \ op monitor interval=60 timeout=60 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60

host_list é uma lista de endereços IP separados por caracteres de espaço. Será feito pingregular dos endereços IP para vericar se há interrupções de rede. Se um cliente sempreprecisar de acesso ao servidor NFS, adicione-o à host_list .

2. Crie um clone:

crm(live)configure# clone ganesha-ping-clone ganesha-ping \ meta interleave=true

3. O comando a seguir cria uma restrição para o serviço NFS Ganesha. Ele força o serviço ase mover para outro nó quando a host_list está inacessível.

144 Limpar recursos SES 6

crm(live)configure# location nfs-ganesha-server-with-ganesha-ping nfs-ganesha-clone \ rule -inf: not_defined ping or ping lte 0

12.3.4 HA do NFS Ganesha e DeepSea

O DeepSea não oferece suporte à conguração de HA do NFS Ganesha. Para evitar falha noDeepSea após a conguração de HA do NFS Ganesha, exclua a inicialização e interrupção doserviço NFS Ganesha da fase 4 do DeepSea:

1. Copie /srv/salt/ceph/ganesha/default.sls para /srv/salt/ceph/ganesha/

ha.sls .

2. Remova a entrada .service do /srv/salt/ceph/ganesha/ha.sls de modo que quecom esta aparência:

include:- .keyring- .install- .configure

3. Adicione a seguinte linha a /srv/pillar/ceph/stack/global.yml :

ganesha_init: ha

12.4 Configuração ativa-ativaEsta seção apresenta um exemplo da conguração ativa-ativa simples do NFS Ganesha. Oobjetivo é implantar dois servidores NFS Ganesha em camadas sobrepondo o mesmo CephFSexistente. Os servidores serão dois nós do cluster do Ceph com endereços separados. Os clientesprecisam ser distribuídos entre eles manualmente. O “failover” nessa conguração signicadesmontar e remontar manualmente o outro servidor no cliente.

145 HA do NFS Ganesha e DeepSea SES 6

12.4.1 Pré-requisitos

Para nossa conguração de exemplo, você precisa do seguinte:

Cluster do Ceph em execução. Consulte a Seção  5.3, “Implantação do cluster” para obterdetalhes sobre como implantar e congurar o cluster do Ceph usando o DeepSea.

Pelo menos um CephFS congurado. Consulte o Capítulo 11, Instalação do CephFS para obtermais detalhes sobre como implantar e congurar o CephFS.

Dois nós do cluster do Ceph com o NFS Ganesha implantado. Consulte o Capítulo  12,

Instalação do NFS Ganesha para obter mais detalhes sobre como implantar o NFS Ganesha.

Dica: Usar Servidores DedicadosEmbora os nós do NFS Ganesha possam compartilhar recursos com outros serviçosrelacionados do Ceph, recomendamos o uso de servidores dedicados para melhoraro desempenho.

Após implantar os nós do NFS Ganesha, verique se o cluster está operante e se os pools padrãodo CephFS estão lá:

cephadm@adm > rados lspoolscephfs_datacephfs_metadata

12.4.2 Configurando o NFS Ganesha

Verique se ambos os nós do NFS Ganesha têm o arquivo /etc/ganesha/ganesha.confinstalado. Adicione os seguintes blocos, se eles ainda não existirem, ao arquivo de conguraçãopara habilitar o RADOS como o back end de recuperação do NFS Ganesha.

NFS_CORE_PARAM{ Enable_NLM = false; Enable_RQUOTA = false; Protocols = 4;}NFSv4{

146 Pré-requisitos SES 6

RecoveryBackend = rados_cluster; Minor_Versions = 1,2;}CACHEINODE { Dir_Chunk = 0; NParts = 1; Cache_Size = 1;}RADOS_KV{ pool = "rados_pool"; namespace = "pool_namespace"; nodeid = "fqdn" UserId = "cephx_user_id"; Ceph_Conf = "path_to_ceph.conf"}

Você pode descobrir os valores para rados_pool e pool_namespace vericando a linhaexistente na conguração do formato:

%url rados://rados_pool/pool_namespace/...

O valor para a opção nodeid corresponde ao FQDN da máquina, e o valor das opções UserIde Ceph_Conf podem ser encontrados no bloco RADOS_URLS existente.

Como as versões legadas do NFS nos impedem de aumentar o período extra com antecedênciae, portanto, prolongar uma reinicialização do servidor, desabilitamos as opções para o NFSanterior à versão 4.2. Desabilitamos também a maior parte do cache do NFS Ganesha, já que asbibliotecas do Ceph já realizam um cache agressivo.

O back end de recuperação “rados_cluster” armazena suas informações nos objetos RADOS.Embora não sejam muitos dados, desejamos que estejam altamente disponíveis. Usamos o poolde metadados do CephFS para essa nalidade e declaramos um novo namespace “ganesha” nelepara diferenciá-lo dos objetos CephFS.

Nota: IDs de Nó do ClusterA maior parte da conguração é idêntica entre os dois hosts, no entanto, a opção nodeidno bloco “RADOS_KV” precisa ser uma string exclusiva para cada nó. Por padrão, o NFSGanesha dene nodeid como o nome de host do nó.

Se você precisa usar valores xos diferentes dos nomes de host, pode denir nodeid ='a' , por exemplo, em um nó e nodeid = 'b' no outro nó.

147 Configurando o NFS Ganesha SES 6

12.4.3 Preenchendo o banco de dados extra do cluster

Precisamos vericar se todos os nós no cluster se reconhecem. Isso é feito por meio de um objetoRADOS que é compartilhado entre os hosts. O NFS Ganesha usa esse objeto para comunicar oestado atual com relação a um período extra.

O pacote nfs-ganesha-rados-grace contém uma ferramenta de linha de comando paraconsultar e manipular esse banco de dados. Se o pacote não estiver instalado em pelo menosum dos nós, instale-o com

root # zypper install nfs-ganesha-rados-grace

Usaremos o comando para criar o BD e adicionar os dois nodeid s. Em nosso exemplo, os doisnós do NFS Ganesha são denominados ses6min1.example.com e ses6min2.example.com . Emum dos hosts do NFS Ganesha, execute

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min1.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=1 rec=0======================================================ses6min1.example.com Eses6min2.example.com E

Isso cria o banco de dados extra e adiciona ambos “ses6min1.example.com” e“ses6min2.example.com” a ele. O último comando descarta o estado atual. Os hosts recém-adicionados sempre são considerados para impor o período extra, portanto, os dois têm o ag“E” denido. Os valores “cur” e “rec” mostram as épocas atual e de recuperação, que é comomantemos o controle dos hosts que podem realizar a recuperação e quando.

12.4.4 Reiniciando os serviços NFS Ganesha

Em ambos os nós do NFS Ganesha, reinicie os serviços relacionados:

root # systemctl restart nfs-ganesha.service

Após a reinicialização dos serviços, verique o banco de dados extra:

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=3 rec=0======================================================ses6min1.example.com

148 Preenchendo o banco de dados extra do cluster SES 6

ses6min2.example.com

Nota: O Flag “E” foi LimpoObserve que os ags “E” dos dois nós foram limpos, indicando que não estão maisimpondo o período extra e agora estão no modo de operação normal.

12.4.5 Conclusão

Após concluir todas as etapas anteriores, você poderá montar o NFS exportado de um dos doisservidores NFS Ganesha e executar as operações normais do NFS neles.

Nossa conguração de exemplo considera que, se um dos dois servidores NFS Ganesha carinativo, você o reiniciará manualmente em 5 minutos. Após 5 minutos, o Servidor de Metadadospoderá cancelar a sessão mantida pelo cliente NFS Ganesha e todo o estado associado a ela. Seos recursos da sessão forem cancelados antes que o restante do cluster entre no período extra,os clientes do servidor talvez não possam recuperar todo o estado deles.

12.5 Mais informaçõesMais informações podem ser encontradas no Livro “Guia de Administração”, Capítulo 21 “NFS

Ganesha: Exportar dados do Ceph pelo NFS”.

149 Conclusão SES 6

IV Implantação do cluster no SUSE CaaSPlatform 4 (Technology Preview)

13 SUSE Enterprise Storage 6 no cluster Kubernetes do SUSE CaaS Platform4 151

13 SUSE Enterprise Storage 6 no cluster Kubernetesdo SUSE CaaS Platform 4

Atenção: Technology PreviewA execução do cluster do Ceph em containers no SUSE CaaS Platform é uma versãoTechnology Preview. Não faça a implantação em um cluster Kubernetes de produção.

Este capítulo descreve como implantar o SUSE Enterprise Storage 6 em containers no clusterKubernetes do SUSE CaaS Platform 4.

13.1 ConsideraçõesAntes de começar a implantação, considere os seguintes pontos:

Para executar o Ceph no Kubernetes, o SUSE Enterprise Storage 6 usa um projeto deupstream denominado Rook (https://rook.io/ ).

Dependendo da conguração, o Rook pode consumir todos os discos não usados em todosos nós em um cluster Kubernetes.

A conguração requer containers com privilégios.

13.2 Pré-requisitosAntes de começar a implantação, você precisa ter:

Um cluster do SUSE CaaS Platform 4 em execução.

Nós do worker do SUSE CaaS Platform 4 com um número de discos extras anexados comoarmazenamento para o cluster do Ceph.

151 Considerações SES 6

13.3 Obtendo declarações sobre o RookO orquestrador Rook usa arquivos de conguração no formato YAML chamados de declarações.As declarações que você precisa estão incluídas no pacote RPM rook-k8s-yaml . Para instalá-lo, execute

root # zypper install rook-k8s-yaml

13.4 InstalaçãoO Rook-Ceph inclui dois componentes importantes: o “operador”, que é executado peloKubernetes e permite a criação de clusters do Ceph, e o próprio “cluster” do Ceph, que é criadoe parcialmente gerenciado pelo operador.

13.4.1 Configuração

13.4.1.1 Configuração global

As declarações usadas nesta conguração instalam todos os componentes do Rook e do Ceph nonamespace “rook-ceph”. Se você precisar modicá-lo, adapte todas as referências ao namespacenas declarações do Kubernetes de acordo.

Dependendo dos recursos do Rook que você pretende usar, altere a conguração “Política deSegurança do Pod” no common.yaml para limitar os requisitos de segurança do Rook. Siga oscomentários no arquivo de declarações.

13.4.1.2 Configuração do operador

O operator.yaml de declarações congura o operador do Rook. Normalmente, não énecessário mudá-lo. Encontre mais informações seguindos os comentários no arquivo dedeclarações.

152 Obtendo declarações sobre o Rook SES 6

13.4.1.3 Configuração do cluster do Ceph

O cluster.yaml de declarações é responsável por congurar o cluster real do Ceph que seráexecutado no Kubernetes. Encontre a descrição detalhada de todas as opções disponíveis nadocumentação do Rook de upstream em https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html .

Por padrão, o Rook está congurado para usar todos os nós que nãoforam afetados por node-role.kubernetes.io/master:NoSchedule e seguirá ascongurações de posicionamento denidas (consulte https://rook.io/docs/rook/v1.0/ceph-cluster-

crd.html#placement-configuration-settings ). O exemplo a seguir desabilita esse comportamentoe usa apenas os nós explicitamente listados na seção de nós:

storage: useAllNodes: false nodes: - name: caasp4-worker-0 - name: caasp4-worker-1 - name: caasp4-worker-2

NotaPor padrão, o Rook está congurado para usar todos os discos livres e vazios em cada nópara uso como armazenamento do Ceph.

13.4.1.4 Documentação

A documentação de upstream do Rook-Ceph em https://rook.github.io/docs/rook/

master/ceph-storage.html contém informações mais detalhadas sobre como congurarimplantações mais avançadas. Use-a como referência para entender os conceitos básicosdo Rook-Ceph antes de fazer congurações mais avançadas.

Encontre mais detalhes sobre o produto SUSE CaaS Platform em https://www.suse.com/

documentation/suse-caasp .

153 Configuração SES 6

13.4.2 Criando o operador do Rook

Instale os componentes comuns do Rook-Ceph, as funções CSI e o operador do Rook-Cephexecutando o seguinte comando no nó master do SUSE CaaS Platform:

root # kubectl apply -f common.yaml -f operator.yaml

O common.yaml criará o namespace “rook-ceph”, as Denições de Recursos Personalizados(CRDs, Custom Resource Denitions) do Ceph (consulte https://kubernetes.io/docs/concepts/

extend-kubernetes/api-extension/custom-resources/ ) para que o Kubernetes reconheça osObjetos do Ceph (por exemplo, “CephCluster”), as funções RBAC e as Políticas de Segurançado Pod (consulte https://kubernetes.io/docs/concepts/policy/pod-security-policy/ ), que sãonecessárias para permitir que o Rook gerencie os recursos especícos do cluster.

Dica: Uso do hostNetwork e do hostPortsA permissão de uso do hostNetwork é necessária ao usar hostNetwork: true

na Denição de Recursos Personalizados. A permissão de uso do hostPorts emPodSecurityPolicy também é necessária.

Execute kubectl get pods -n rook-ceph no nó master do SUSE CaaS Platform para vericara instalação. Por exemplo:

root # kubectl get pods -n rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22hrook-discover-tztz4 1/1 Running 0 22h

13.4.3 Criando o cluster do Ceph

Após módicar o cluster.yaml de acordo com as suas necessidades, você poderá criar o clusterdo Ceph. Execute o seguinte comando no nó master do SUSE CaaS Platform:

root # kubectl apply -f cluster.yaml

154 Criando o operador do Rook SES 6

Observe o namespace “rook-ceph” para ver o cluster do Ceph que está sendo criado. Você veráo mesmo número de Ceph Monitors que foram congurados na declaração cluster.yaml (opadrão é 3), um Ceph Manager e a mesma quantidade de Ceph OSDs que você tem de discoslivres.

Dica: Pods OSD TemporáriosAo inicializar o cluster do Ceph, você verá alguns pods com o nome rook-ceph-osd-prepare-NODE-NAME executados durante um tempo e, em seguida, terminados com ostatus “Concluído”. Como o próprio nome indica, esses pods provisionam os OSDs doCeph. Eles não são apagados para que você possa inspecionar os registros deles após otérmino. Por exemplo:

root # kubectl get pods --namespace rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-mgr-a-6d48564b84-k7dft 1/1 Running 0 22hrook-ceph-mon-a-cc44b479-5qvdb 1/1 Running 0 22hrook-ceph-mon-b-6c6565ff48-gm9wz 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-ceph-osd-0-57bf997cbd-4wspg 1/1 Running 0 22hrook-ceph-osd-1-54cf468bf8-z8jhp 1/1 Running 0 22hrook-ceph-osd-prepare-caasp4-worker-0-f2tmw 0/2 Completed 0 9m35srook-ceph-osd-prepare-caasp4-worker-1-qsfhz 0/2 Completed 0 9m33srook-ceph-tools-76c7d559b6-64rkw 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22hrook-discover-tztz4 1/1 Running 0 22h

13.5 Usando o Rook como armazenamento paracarga de trabalho do KubernetesO Rook permite usar três tipos diferentes de armazenamento:

Armazenamento de Objetos

O armazenamento de objetos expõe uma API S3 ao cluster de armazenamento para queos aplicativos insiram e acessem os dados. Consulte https://rook.io/docs/rook/v1.0/ceph-

object.html para ver uma descrição detalhada.

155 Usando o Rook como armazenamento para carga de trabalho do Kubernetes SES 6

Sistema Compartilhado de Arquivos

É possível montar um sistema compartilhado de arquivos com permissão de leitura/gravação de vários pods. Isso é útil para aplicativos agrupados em cluster usandoum sistema compartilhado de arquivos. Consulte https://rook.io/docs/rook/v1.0/ceph-

filesystem.html para ver uma descrição detalhada.

Armazenamento de Blocos

O armazenamento de blocos permite montar o armazenamento em um único pod. Consultehttps://rook.io/docs/rook/v1.0/ceph-block.html para ver uma descrição detalhada.

13.6 Desinstalando o RookPara desinstalar o Rook, siga estas etapas:

1. Apague todos os aplicativos do Kubernetes que estão consumindo armazenamento doRook.

2. Apague todos os artefatos de objeto, arquivo e/ou armazenamento de blocos criadosseguindo a Seção  13.5, “Usando o Rook como armazenamento para carga de trabalho do

Kubernetes”.

3. Apague o cluster, o operador e os recursos relacionados do Ceph:

root # kubectl delete -f cluster.yamlroot # kubectl delete -f operator.yamlroot # kubectl delete -f common.yaml

4. Apague os dados dos hosts:

root # rm -rf /var/lib/rook

5. Se necessário, limpe os discos que foram usados pelo Rook. Consulte https://rook.io/docs/

rook/master/ceph-teardown.html para obter mais detalhes.

156 Desinstalando o Rook SES 6

A Atualizações de manutenção do Ceph baseadasnos point releases de upstream do “Nautilus”

Vários pacotes importantes no SUSE Enterprise Storage 6 são baseados na série de lançamentosNautilus do Ceph. Quando o projeto do Ceph (https://github.com/ceph/ceph ) publica novospoint releases na série Nautilus, o SUSE Enterprise Storage 6 é atualizado para garantir que oproduto aproveite as correções de bug de upstream e os backports de recursos mais recentes.

Este capítulo contém resumos das mudanças importantes contidas em cada point release deupstream que foi, ou está planejado para ser incluído no produto.

Point release do Nautilus 14.2.4Esse point release corrige uma regressão grave que acabou passando no point release 14.2.3.Essa regressão não afetou os clientes do SUSE Enterprise Storage porque não distribuímos umaversão com base na 14.2.3.

Point release do Nautilus 14.2.3

Uma vulnerabilidade de negação de serviço foi corrigida, na qual um cliente nãoautenticado do Ceph Object Gateway era capaz de provocar uma falha de uma exceçãonão detectada.

Os clientes librbd com base no Nautilus agora podem abrir imagens em clusters Jewel.

O num_rados_handles do Object Gateway foi removido. Se você estavausando um valor de num_rados_handles maior do que 1, multiplique osparâmetros objecter_inflight_ops e objecter_inflight_op_bytes atuais pelonum_rados_handles antigo para conseguir o mesmo comportamento de obstrução.

O modo seguro do protocolo Messenger v2 não é mais experimental com esta versão. Essemodo é agora preferencial para conexão de monitores.

osd_deep_scrub_large_omap_object_key_threshold foi reduzido para detectar maisfacilmente um objeto com um número grande de chaves omap.

Agora, o Ceph Dashboard permite silenciar as noticações do Prometheus.

157 Point release do Nautilus 14.2.4 SES 6

Point release do Nautilus 14.2.2

Os comandos relacionados no{up,down,in,out} foram reformulados. Agora há duasmaneiras de denir os ags no{up,down,in,out} : o comando antigo

ceph osd [un]set FLAG

que dene os ags de todo o cluster; e o novo comando

ceph osd [un]set-group FLAGS WHO

que dene os ags em lote na granularidade de qualquer nó de crush ou classe dedispositivo.

radosgw-admin introduz dois subcomandos que permitem o gerenciamento de objetosde expiração-esvaziamento que podem ser esquecidos após a refragmentação de umcompartimento de memória nas versões anteriores do Object Gateway. Um subcomandolista esses objetos, e o outro os apaga.

As versões anteriores do Nautilus (14.2.1 e 14.2.0) têm um problema em que a implantaçãode um novo e único OSD BlueStore do Nautilus em um cluster do qual foi feito o upgrade(ex. um que foi originalmente implantado antes do Nautilus) interrompe as estatísticas deutilização do pool relatadas pelo ceph df . Até que todos os OSDs sejam reprovisionadosou atualizados (por meio de ceph-bluestore-tool repair ), as estatísticas do poolmostrarão valores inferiores aos valores reais. Isso foi resolvido na versão 14.2.2, de modoque o cluster apenas mudará para o uso de estatísticas mais precisas por pool depoisque todos os OSDs forem da versão 14.2.2 ou posterior, de Armazenamento de Blocos eatualizados por meio da função de conserto, caso tenham sido criados antes do Nautilus.

O valor padrão para mon_crush_min_required_version foi mudado de firefly parahammer , o que signica que o cluster emitirá um aviso de saúde se os tunables do CRUSHforem mais antigos do que os do Hammer. Em geral, há uma pequena (mas não zero)quantidade de dados que serão movidos ao alternar para os tunables do Hammer.Se possível, recomendamos denir o cliente mais antigo com permissão como hammer ouposterior. Para exibir o cliente mais antigo com permissão atual, execute:

cephadm@adm > ceph osd dump | grep min_compat_client

158 Point release do Nautilus 14.2.2 SES 6

Se o valor atual for mais antigo do que hammer , execute o seguinte comando paradeterminar se é seguro fazer essa mudança vericando se não há clientes mais antigos doque o Hammer atualmente conectados ao cluster:

cephadm@adm > ceph features

O tipo de compartimento de memória do CRUSH straw2 foi incluído no Hammer. Se vocêvericar que todos os clientes são do Hammer ou mais recente, ele permitirá o uso de novosrecursos suportados apenas para compartimentos de memória straw2 , incluindo o modocrush-compat para o Balanceador (Livro “Guia de Administração”, Capítulo 10 “Módulos do

Ceph Manager”, Seção 10.1 “Balanceador”).

Encontre informações detalhadas sobre o patch em https://download.suse.com/Download?

buildid=D38A7mekBz4~

Point release do Nautilus 14.2.1Esse foi o primeiro point release após a versão original do Nautilus (14.2.0). A versão original(“Disponibilidade Geral” ou “GA”) do SUSE Enterprise Storage 6 foi baseada nesse point release.

159 Point release do Nautilus 14.2.1 SES 6

Glossário

Geral

Árvore de roteamentoUm termo que representa qualquer diagrama que mostra as várias rotas que um receptorpode executar.

Compartimento de memóriaUm ponto que agrega outros nós em uma hierarquia de locais físicos.

Importante: Não Misture com Compartimentos de MemóriaS3Os compartimentos de memória ou containers S3 representam termos diferentes quesignicam pastas para armazenar objetos.

Conjunto de RegrasRegras para determinar o posicionamento de dados em um pool.

CRUSH, Mapa CRUSHControlled Replication Under Scalable Hashing: Um algoritmo que determina como armazenare recuperar dados calculando os locais de armazenamento de dados. O CRUSH requer ummapa de cluster para armazenar e recuperar dados de forma pseudo-aleatória nos OSDs comuma distribuição uniforme dos dados pelo cluster.

NóQualquer máquina ou servidor único em um cluster do Ceph.

Nó de adminO nó no qual você executa o utilitário ceph-deploy para implantar nós do Ceph e OSD.

Nó do monitor, MONUm nó do cluster que mantém os mapas de estado do cluster, incluindo o mapa do monitorou o mapa OSD.

160 SES 6

Nó OSDUm nó do cluster que armazena dados, processa a replicação, a recuperação, opreenchimento e a redistribuição de dados e fornece algumas informações de monitoramentoaos Ceph Monitors examinando outros daemons Ceph OSD.

OSDDependendo do contexto, Dispositivo de Armazenamento de Objetos ou Daemon deArmazenamento de Objetos. O daemon ceph-osd é o componente do Ceph responsável porarmazenar objetos em um sistema de arquivos local e por conceder acesso a eles pela rede.

PGGrupo de Posicionamento: uma subdivisão de um pool, usado para ajuste de desempenho.

PoolPartições lógicas para armazenamento de objetos, como imagens de disco.

Termos específicos do Ceph

AlertmanagerUm binário único que processa os alertas enviados pelo servidor Prometheus e notica ousuário nal.

Cluster de Armazenamento do CephO conjunto principal de software de armazenamento que armazena os dados do usuário.Esse conjunto consiste em Ceph Monitors e OSDs.

Também conhecido como “Armazenamento de Objetos do Ceph”.

GrafanaAnálise de banco de dados e solução de monitoramento.

PrometheusKit de ferramentas de monitoramento e alertas de sistemas.

161 SES 6

Termos específicos do Object Gateway

Módulo de sincronização de arquivosMódulo que permite a criação de uma zona do Object Gateway para manter o histórico dasversões de objeto do S3.

Objeto GatewayO componente de gateway do S3/Swift do Armazenamento de Objetos do Ceph.

162 SES 6

B Atualizações da documentação

Este capítulo lista alterações de conteúdo para este documento desde o lançamento daúltima atualização de manutenção do SUSE Enterprise Storage 5. Você pode encontrarmodicações relacionadas à implantação do cluster que se apliquem a versões anterioresem https://www.suse.com/documentation/suse-enterprise-storage-5/book_storage_deployment/

data/ap_deploy_docupdate.html .

O documento foi atualizado nas seguintes datas:

Seção B.1, “Atualização de manutenção da documentação do SUSE Enterprise Storage 6”

Seção B.2, “Junho de 2019 (Lançamento do SUSE Enterprise Storage 6)”

B.1 Atualização de manutenção da documentação doSUSE Enterprise Storage 6ATUALIZAÇÕES GERAIS

Execução de rpmconfigcheck sugerida para evitar perda de mudanças locais na Seção 6.8,

“Fazendo upgrade por nó: procedimento básico” (https://jira.suse.com/browse/SES-348 ).

Adicionado o Livro “Guia de Administração”, Capítulo 15 “Melhorando o desempenho com o cache

LVM” (https://jira.suse.com/browse/SES-269 ).

Adicionado o Capítulo 13, SUSE Enterprise Storage 6 no cluster Kubernetes do SUSE CaaS Platform

4 (https://jira.suse.com/browse/SES-720 ).

CORREÇÕES DE BUG

Dica adicionada sobre monitoramento de status de nós do cluster durante o upgradena Seção  6.9, “Fazendo upgrade do nó de admin” (https://bugzilla.suse.com/show_bug.cgi?

id=1154568 ).

Seção 6.8.2, “Fazendo upgrade do nó por meio do SUSE Distribution Migration System” adicionada(https://bugzilla.suse.com/show_bug.cgi?id=1154438 ).

O capítulo sobre upgrade foi colocado em sequência, Capítulo 6, Fazendo upgrade de versões

anteriores (https://bugzilla.suse.com/show_bug.cgi?id=1144709 ).

Entrada do registro de mudanças adicionada referente ao Ceph 14.2.4 (https://

bugzilla.suse.com/show_bug.cgi?id=1151881 ).

163 Atualização de manutenção da documentação do SUSE Enterprise Storage 6 SES 6

O nome do pool “cephfs_metadata” foi unicado nos exemplos no Capítulo 12, Instalação do

NFS Ganesha (https://bugzilla.suse.com/show_bug.cgi?id=1148548 ).

Seção  5.5.2.1, “Especificação” atualizada para incluir valores mais realísticos (https://

bugzilla.suse.com/show_bug.cgi?id=1148216 ).

Dois novos repositórios para “Module-Desktop” foram adicionados, já que nossos clientesusam a GUI com mais frequência, na Seção 6.8.1, “Fazendo upgrade manual do nó por meio do

DVD do instalador” (https://bugzilla.suse.com/show_bug.cgi?id=1144897 ).

deepsea-cli não é uma dependência de deepsea na Seção 5.4, “CLI do DeepSea” (https://

bugzilla.suse.com/show_bug.cgi?id=1143602 ).

Dica adicionada para migrar ntpd para chronyd na Seção 6.1, “Pontos de consideração antes

do upgrade” (https://bugzilla.suse.com/show_bug.cgi?id=1135185 ).

Livro “Guia de Administração”, Capítulo 2 “Administração do cluster do Salt”, Seção

2.15 “Desativando perfis ajustados” adicionado (https://bugzilla.suse.com/show_bug.cgi?

id=1130430 ).

Considerar a migração do nó OSD inteiro na Seção 6.16.3, “Implantando um OSD” (https://

bugzilla.suse.com/show_bug.cgi?id=1138691 ).

Ponto adicionado sobre como migrar nomes MDS na Seção 6.1, “Pontos de consideração antes

do upgrade” (https://bugzilla.suse.com/show_bug.cgi?id=1138804 ).

B.2 Junho de 2019 (Lançamento do SUSE EnterpriseStorage 6)ATUALIZAÇÕES GERAIS

Seção 5.5.2, “DriveGroups” adicionada (jsc#SES-548).

Capítulo 6, Fazendo upgrade de versões anteriores reformulado (jsc#SES-88).

Seção 7.2.1, “Habilitando o IPv6 para implantação de cluster do Ceph” adicionada (jsc#SES-409).

Armazenamento de Blocos tornou-se o back end de armazenamento padrão(Fate#325658).

Todas as referências à documentação online externa foram removidas e substituídas peloconteúdo relevante (Fate#320121).

164 Junho de 2019 (Lançamento do SUSE Enterprise Storage 6) SES 6

CORREÇÕES DE BUG

Informações adicionadas sobre o AppArmor durante o upgrade na Seção 6.1, “Pontos de

consideração antes do upgrade” (https://bugzilla.suse.com/show_bug.cgi?id=1137945 ).

Informações adicionadas sobre os clusters CDTB que não suportam upgrade online naSeção 6.1, “Pontos de consideração antes do upgrade” (https://bugzilla.suse.com/show_bug.cgi?

id=1129108 ).

Informações adicionadas sobre colocation de serviços do Ceph em congurações de AltaDisponibilidade na Seção  12.3, “Configuração ativa-passiva de alta disponibilidade” (https://

bugzilla.suse.com/show_bug.cgi?id=1136871 ).

Dica adicionada sobre pacotes órfãos na Seção 6.8, “Fazendo upgrade por nó: procedimento

básico” (https://bugzilla.suse.com/show_bug.cgi?id=1136624 ).

profile-* atualizado com role-storage na Dica: Implantando nós do monitor sem definir

perfis de OSD (https://bugzilla.suse.com/show_bug.cgi?id=1138181 ).

Adicionada a Seção  6.16, “Migrando de implantações com base no perfil para DriveGroups”

(https://bugzilla.suse.com/show_bug.cgi?id=1135340 ).

Adicionada a Seção  6.11, “Fazendo upgrade dos servidores de metadados” (https://

bugzilla.suse.com/show_bug.cgi?id=1135064 ).

Cluster MDS precisa ser reduzido na Seção 6.1, “Pontos de consideração antes do upgrade”

(https://bugzilla.suse.com/show_bug.cgi?id=1134826 ).

Arquivo de conguração modicado para /srv/pillar/ceph/stack/global.yml

(https://bugzilla.suse.com/show_bug.cgi?id=1129191 ).

Várias partes do Livro “Guia de Administração”, Capítulo 20 “Exportando dados do Ceph por meio

do Samba” foram atualizadas (https://bugzilla.suse.com/show_bug.cgi?id=1101478 ).

master_minion.sls foi removido da Seção  5.3, “Implantação do cluster” (https://

bugzilla.suse.com/show_bug.cgi?id=1090921 ).

O pacote deepsea-cli foi mencionado na Seção  5.4, “CLI do DeepSea” (https://

bugzilla.suse.com/show_bug.cgi?id=1087454 ).

165 Junho de 2019 (Lançamento do SUSE Enterprise Storage 6) SES 6