Guia de Implantação

SUSE Enterprise Storage 5

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

Data de Publicação: 02/09/2019

SUSE LLC10 Canal Park DriveSuite 200Cambridge MA 02141USA

https://www.suse.com/documentation

Copyright © 2019 SUSE LLC

Copyright © 2016, RedHat, Inc, and contributors.

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. MySQL® é uma marca

comercial registrada da MySQL AB nos Estados Unidos, na União Europeia e 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 ix

I SUSE ENTERPRISE STORAGE 1

1 SUSE Enterprise Storage 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 Nós de armazenamento de objetos 11

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

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

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

2.2 Nós do monitor 14

2.3 Nós do Object Gateway 15

2.4 Nós do servidor de metadados 15

2.5 Master Salt 15

2.6 Nós do iSCSI 16

2.7 Recomendações de rede 16

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

monitor em sub-redes diferentes 17

iv Guia de Implantação

2.8 Limitações de nomeação 18

2.9 OSD e monitor que compartilham um servidor 18

2.10 Configuração mínima do cluster 19

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

2.12 SUSE Enterprise Storage e outros produtos da SUSE 20

SUSE Manager 20

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

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

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

II IMPLANTAÇÃO E UPGRADE DO CLUSTER 24

4 Implantando com o DeepSea/Salt 254.1 Ler os detalhes da versão 26

4.2 Introdução ao DeepSea 26

Organização e locais importantes 28 • Direcionando os minions 28

4.3 Implantação do cluster 31

4.4 CLI do DeepSea 38

CLI do DeepSea: Modo monitor 39 • CLI do DeepSea: Modo

independente 39

4.5 Configuração e personalização 42

Arquivo policy.cfg 42 • Arquivo ceph.conf personalizado 48

5 Fazendo upgrade de versões anteriores 49

5.1 Ler os detalhes da versão 49

5.2 Procedimento geral de upgrade 49

5.3 Criptografando OSDs durante o upgrade 51

v Guia de Implantação

5.4 Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para5 53

Migração do OSD para BlueStore 59

5.5 Upgrade do SUSE Enterprise Storage 4 (implantação do ceph-deploy)para 5 62

5.6 Upgrade do SUSE Enterprise Storage 4 (implantação do Crowbar) para5 68

5.7 Upgrade do SUSE Enterprise Storage 3 para 5 74

6 Fazendo backup da configuração do cluster 75

6.1 Fazer backup da configuração do Salt 75

6.2 Fazer backup da configuração do DeepSea 75

7 Personalizando a configuração padrão 76

7.1 Usando arquivos de configuração personalizados 76

Desabilitando uma etapa de implantação 76 • Substituindo

uma etapa de implantação 77 • Modificando uma

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

implantação 80 • Desabilitando atualizações e reinicializações durante a

fase 0 81

7.2 Modificando a configuração descoberta 82

III INSTALAÇÃO DE SERVIÇOS ADICIONAIS 85

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

9 Ceph Object Gateway 87

9.1 Instalação manual do Object Gateway 87

Configuração do Object Gateway 88

10 Instalação do iSCSI Gateway 94

10.1 Armazenamento em blocos iSCSI 94

Destino iSCSI do kernel do Linux 95 • Iniciadores iSCSI 95

vi Guia de Implantação

10.2 Informações gerais sobre lrbd 96

10.3 Considerações de implantação 98

10.4 Instalação e configuração 98

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

RBD 99 • Exportar imagens RBD por meio do iSCSI 99 • Configurações

opcionais 102 • Configurações avançadas 103

10.5 Exportando imagens de dispositivo de blocos RADOS por meio do tcmu-runner 107

Instalação 108 • Configuração e implantação 108 • Uso 110

11 Instalação do CephFS 111

11.1 Cenários e diretrizes suportados do CephFS 111

11.2 Servidor de metadados Ceph 112

Adicionando um servidor de metadados 112 • Configurando um servidor de

metadados 112

11.3 CephFS 113

Criando o CephFS 113 • Tamanho do cluster MDS 114 • Cluster e

atualizações do MDS 115

12 Instalação do NFS Ganesha 117

12.1 Preparação 117

Informações Gerais 117 • Resumo dos requisitos 118

12.2 Exemplo de instalação 118

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

Instalação básica 120 • Limpar recursos 122 • Configurando o recurso de

ping 122 • HA do NFS Ganesha e DeepSea 123

12.4 Mais informações 124

13 Exportar o CephFS via Samba 125

13.1 Exemplo de instalação 125

13.2 Configuração de alta disponibilidade 126

vii Guia de Implantação

A Atualizações da documentação 131A.1 Outubro de 2018 (Lançamento do SUSE Enterprise Storage 5.5) 131

A.2 Novembro de 2017 (atualização de manutenção) 134

A.3 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) 135

viii Guia de Implantação

Sobre este guia

O SUSE Enterprise Storage é uma extensão do SUSE Linux Enterprise. Ele combina os recursos doprojeto de armazenamento Ceph (http://ceph.com/ ) com a engenharia corporativa e o suporteda SUSE. O SUSE Enterprise Storage oferece às organizações de TI o recurso para implantar umaarquitetura de armazenamento distribuído capaz de suportar inúmeros casos de uso por meiode plataformas de hardware convencional.

Este guia ajuda você a compreender o conceito do SUSE Enterprise Storage 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ível

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

ix Documentação disponível SES 5

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

Nós queremos 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

x Comentários SES 5

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 Ceph ContributorsThe Ceph project and its documentation is a result of hundreds of contributors and organizations.See https://ceph.com/contributors/ for more details.

xi Sobre este manual SES 5

I SUSE Enterprise Storage

1 SUSE Enterprise Storage e Ceph 2

2 Requisitos e recomendações de hardware 11

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

1 SUSE Enterprise Storage e Ceph

O SUSE Enterprise Storage é 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 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 4, Implantando com o DeepSea/Salt para obter detalhes sobre o processode implantação.

1.1 Recursos do Ceph

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

2 Recursos do Ceph SES 5

Autogerenciável

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 5

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 interface diretacom 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 5

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 daemonsMGR que podem ser combinados com MONs. Cada cluster requer no mínimo os daemons MON,MGR e OSD:

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

5 Nós e daemons do Ceph SES 5

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 Ceph Object Gateway incluído no Object Gateway é um gateway HTTP REST paraarmazenamento de objetos RADOS. Ele é compatível com o OpenStack Swift e o AmazonS3 e tem seu próprio gerenciamento de usuá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.

6 Nós e daemons do Ceph SES 5

1.3 Estrutura de armazenamento

1.3.1 Pool

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

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

Esta 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.0 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 5

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 5

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 BlueStore

BlueStore é um novo back-end de armazenamento padrão para Ceph, desde o 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 5

Dica: Planejar o tamanho do BDPlaneje sucientemente o tamanho do dispositivo de BD. Se o dispositivo de BD carlotado, os metadados serão despejados no dispositivo principal, o que prejudica odesempenho 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:

root@minion > 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 .

10 Informações adicionais SES 5

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 Nós de armazenamento de objetos

2.1.1 Requisitos mínimos

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

Para OSDs que não usam BlueStore, 1 GB de RAM por terabyte de capacidade bruta doOSD é o mínimo exigido para cada nó de armazenamento OSD. É recomendável 1,5 GB deRAM por terabyte de capacidade bruta do OSD. Durante a recuperação, 2 GB de RAM porterabyte de capacidade bruta do OSD pode ser o ideal.Para OSDs que usam BlueStore, primeiro calcule o tamanho de RAM recomendado para osOSDs que não usam BlueStore, depois calcule 2 GB mais o tamanho do cache de RAM doBlueStore que é recomendado para cada processo de OSD e escolha o maior valor de RAMentre os dois resultados. Observe que o cache padrão do BlueStore é de 1 GB para HDD ede 3 GB para unidades SSD, por padrão. Em resumo, escolha o maior de:

[1GB * OSD count * OSD size]

ou

[(2 + BS cache) * OSD count]

1,5 GHz de um núcleo de CPU lógico por OSD é o mínimo necessário para cada processo dodaemon OSD. É recomendável 2 GHz por processo do daemon OSD. Observe que o Cephexecuta um processo do daemon OSD por disco de armazenamento. Não são consideradosdiscos reservados exclusivamente para uso como diários OSD, diários WAL, metadadosomap ou qualquer combinação desses três casos.

11 Nós de armazenamento de objetos SES 5

10 Gb Ethernet (duas interfaces de rede vinculadas a vários switches).

Discos OSD nas congurações JBOD.

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.

Por motivos de desempenho do disco, os nós OSD devem estar completamente vazios enão devem ser virtualizados.

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

Veja a seguir várias regras para dimensionamento de dispositivo WAL/BD. Ao usar o DeepSeapara implantar OSDs com o BlueStore, ele aplica as regras recomendadas automaticamente enotica o administrador sobre o fato.

12 Tamanho mínimo do disco SES 5

10 GB do dispositivo de BD para cada Terabyte da capacidade do OSD (1/100º do OSD).

Entre 500 MB e 2 GB para o dispositivo WAL. O tamanho do WAL depende do tráfegode dados e da carga de trabalho, não do tamanho do OSD. Se você souber que um OSDé sicamente capaz de processar pequenas gravações e sobregravações a um throughputmuito elevado, será preferível ter mais WAL do que menos WAL. Um dispositivo WAL de1 GB é uma boa solução que atende à maioria das implementações.

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 for totalmente usada, seuespaço não será desperdiçado, mas usado para operação de BD.Para compartilhar o dispositivo BD com o WAL, não especique o dispositivo WAL, masapenas o dispositivo BD:

bluestore_block_db_path = "/path/to/db/device"bluestore_block_db_size = 10737418240bluestore_block_wal_path = ""bluestore_block_wal_size = 0

Se preferir, você poderá colocar o WAL em seu próprio dispositivo separado. Nesse caso,é recomendável o dispositivo mais rápido para a operação de WAL.

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

13 Usando SSD para diários OSD SES 5

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.1.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. Para atingir o melhor desempenho, reserve pelo menos 2 GB de RAM por terabytede espaço em disco instalado.

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.

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

14 Número máximo recomendado de discos SES 5

separados 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.3 Nós do Object Gateway

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

2.4 Nós do servidor de metadados

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

3G de RAM por cada daemon do Servidor de Metadados.

Interface de rede vinculada.

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

2.5 Master Salt

Pelo menos 4 GB de RAM e uma CPU quad-core são necessárias. Isso inclui o openATTIC emexecução no master Salt. Para clusters grandes com centenas de nós, 6 GB de RAM é a sugestão.

15 Nós do Object Gateway SES 5

2.6 Nós do iSCSI

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

2.7 Recomendações de rede

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

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"

16 Nós do iSCSI SES 5

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

sudo systemctl start ceph.target

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

[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] por monitor:

[mon.MON1]

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

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.8 Limitações de nomeação

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

2.9 OSD e monitor que compartilham um servidor

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

18 Limitações de nomeação SES 5

2.10 Configuração mínima do cluster

Quatro Nós de Armazenamento de Objetos

10 Gb Ethernet (duas redes vinculadas a vários switches)

32 OSDs por cluster de armazenamento

Diário OSD pode residir no disco OSD

Disco de OS dedicado para cada Nó de Armazenamento de Objetos

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

1,5 GHz por OSD para cada Nó de Armazenamento de Objetos

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

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

Nós de Ceph Monitors, Object Gateways e Servidores de Metadados requeremimplantação redundante

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

Nó de gerenciamento separado com 4 GB de RAM, quatro núcleos, capacidade de 1 TB

2.11 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

19 Configuração mínima do cluster SES 5

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

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.12 SUSE Enterprise Storage e outros produtos daSUSEEsta seção contém informações importantes sobre a integração do SUSE Enterprise Storage comoutros produtos da SUSE.

2.12.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 e outros produtos da SUSE SES 5

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

O nó de admin do Ceph é 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 gerencia o restantedos nós de cluster consultando e instruindo os serviços de minion Salt. Normalmente, ele tambéminclui outros serviços. Por exemplo, a IU da Web do openATTIC com o painel do Grafana e osuporte do kit de ferramentas de monitoramento do Prometheus.

Em caso de falha no nó de admin do Ceph, geralmente você precisa fornecer um novo hardwareativo para o nó e restaurar a pilha completa de conguração do cluster de um backup recente.Esse 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 HA (High Availability – Alta Disponibilidade) para onó de admin do Ceph.

3.1 Estrutura do cluster de HA para o nó de admin doCephA ideia de um cluster de HA é que, em caso de falha em um nó de cluster, o outro nó assumeautomaticamente sua função, incluindo o nó de admin do Ceph virtualizado. Dessa forma, osoutros nós de cluster do Ceph não percebem a falha no nó de admin do Ceph.

A solução de HA mínima para o nó de admin do Ceph 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 do Ceph.

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 do Ceph. O armazenamento compartilhado precisa ser acessívelaos dois servidores. Por exemplo, ele pode ser uma exportação NFS, um compartilhamentoSamba ou um destino iSCSI.

Encontre mais detalhes sobre os requisitos de cluster em https://www.suse.com/documentation/

sle-ha-12/install-quick/data/install-quick.html#sec_ha_inst_quick_req .

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

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

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

1. Congure um cluster de HA básico de 2 nós com armazenamento compartilhado,conforme descrito em https://www.suse.com/documentation/sle-ha-12/install-quick/data/

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-12/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-12/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 do Ceph SES 5

5. Crie um recurso para a VM do nó de admin do Ceph. Consulte https://www.suse.com/

documentation/sle-ha-12/book_sleha/data/cha_conf_hawk2.html para obter informaçõesgerais sobre a criação de recursos de HA. Há informações detalhadas sobre a criação derecursos para uma máquina virtual KVM em http://www.linux-ha.org/wiki/VirtualDomain_

%28resource_agent%29 .

6. No convidado da VM recém-criado, implante o nó de admin do Ceph, incluindo os serviçosadicionais necessários nele. Siga as etapas relevantes na Seção 4.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 do Ceph SES 5

II Implantação e upgrade do cluster

4 Implantando com o DeepSea/Salt 25

5 Fazendo upgrade de versões anteriores 49

6 Fazendo backup da configuração do cluster 75

7 Personalizando a configuração padrão 76

4 Implantando com o DeepSea/Salt

Nota: ceph-deploy removido do SUSE Enterprise Storage 5A ferramenta de implantação de cluster ceph-deploy foi descontinuada no SUSEEnterprise Storage 4 e totalmente removida para entrada do DeepSea a partir do SUSEEnterprise Storage 5.

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 problemas de desempenho e deprocedimento de upgrade, não implante a função Ceph OSD, Servidor de Metadadosou Ceph Monitor no master Salt.

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

“Implantação do cluster”.

25 SES 5

4.1 Ler os detalhes da versão

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

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

4.2 Introdução ao DeepSea

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

26 Ler os detalhes da versão SES 5

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.

Importante: Executar novamente a Fase 0 após areinicialização do master SaltDurante a Fase 0, se o master Salt for reinicializado 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: descoberta. Nessa fase, você detecta o hardware inteiro no cluster e coletaas informações necessárias para conguração do Ceph. Para obter detalhes sobre aconguração, consulte a Seção 4.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 1 “Administração do cluster do Salt”, Seção 1.3 “Removendo e reinstalando nós do cluster”.

Você encontra uma apresentação mais detalhada sobre o DeepSea em https://github.com/suse/

deepsea/wiki .

27 Introdução ao DeepSea SES 5

4.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. Para obtermais informações, consulte a documentação do Salt (https://docs.saltstack.com/en/latest/

topics/tutorials/starting_states.html) .

/srv/module/runners

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 .

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

28 Organização e locais importantes SES 5

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

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

4.2.2.2 Direcionando com um grain “deepsea”

Em um ambiente heterogêneo gerenciado pelo Salt em que o SUSE Enterprise Storage estáimplantado em um subconjunto de nós com outra(s) solução(ões) de cluster, convém “marcar”os minions relevantes aplicando um grain “deepsea”a eles. Dessa forma, você pode direcionarfacilmente os minions do DeepSea nos ambientes em que a correspondência por nome de minioné problemática.

29 Direcionando os minions SES 5

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

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

“deepsea”.

Corresponder todos os minions Salt no cluster:

deepsea_minions: '*'

Corresponder todos os minions com o grain “deepsea”:

deepsea_minions: 'G@deepsea:*'

30 Direcionando os minions SES 5

4.2.2.4 Para obter mais informações

Você pode usar métodos mais avançados para direcionar minions por meio da infraestrutura doSalt. Consulte https://docs.saltstack.com/en/latest/topics/targeting/ para obter uma descriçãode todas as técnicas de direcionamento.

A página de manual do “deepsea-minions” também apresenta mais detalhes sobre odirecionamento do DeepSea ( man 7 deepsea_minions ).

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

Dica: Implantando nós do monitor sem definir perfis de OSDSe você precisa ignorar a denição de pers de OSD e implantar os nós do monitorprimeiro, poderá fazer isso denindo a variável DEV_ENV . Ela permite implantarmonitores sem a presença do diretório profile/ e implantar um cluster com pelo menosum nó de armazenamento, monitor e 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

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

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

2. Verique se os produtos apropriados estão instalados e foram registrados listando osrepositórios de software existentes. A lista será semelhante a esta saída:

root@minion > zypper lr -E# | Alias | Name | Enabled | GPG Check | Refresh---+---------+-----------------------------------+---------+-----------+-------- 4 | [...] | SUSE-Enterprise-Storage-5-Pool | Yes | (r ) Yes | No 6 | [...] | SUSE-Enterprise-Storage-5-Updates | Yes | (r ) Yes | Yes

31 Implantação do cluster SES 5

9 | [...] | SLES12-SP3-Pool | Yes | (r ) Yes | No11 | [...] | SLES12-SP3-Updates | Yes | (r ) Yes | Yes

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-12/book_sle_admin/data/

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

data/cha_dns.html .

4. Congure, habilite e inicie o servidor de sincronização de horário NTP:

root@master # systemctl enable ntpd.serviceroot@master # systemctl start ntpd.service

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

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

5. Verique se o serviço AppArmor está em execução e desabilite-o em cada nó do cluster.Inicie o módulo AppArmor do YaST, selecione Settings (Congurações) e, em seguida,desative a caixa de seleção Enable Apparmor (Habilitar Apparmor). Para conrmar, cliqueem Done (Concluído).O SUSE Enterprise Storage não funcionará com o AppArmor habilitado.

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

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

32 Implantação do cluster SES 5

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@master # systemctl stop SuSEfirewall2.service

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

stack/global.yml :

FAIL_ON_WARNING: False

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

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

10. 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@minion > systemctl enable salt-minion.serviceroot@minion > systemctl start salt-minion.service

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

33 Implantação do cluster SES 5

Ver a impressão digital de cada minion:

root@minion > 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

12. Verique se as chaves foram aceitas:

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

13. Antes de implantar o SUSE Enterprise Storage, verique se todos os discos que foramusados como OSD por clusters anteriores estão vazios, sem partições. Para garantir isso,você precisa limpar (zap) manualmente todos os discos. Lembre-se de substituir “X” pelaletra 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-12/stor_admin/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-12/stor_admin/data/part_software_raid.html para obter maisdetalhes.

34 Implantação do cluster SES 5

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

Limpe o começo de cada partição:

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

f. Limpe a tabela de partição:

sgdisk -Z --clear -g /dev/sdX

g. Limpe as tabelas de partição de backup:

size=`blockdev --getsz /dev/sdX`position=$((size/4096 - 33))dd if=/dev/zero of=/dev/sdX bs=4M count=33 seek=$position oflag=direct

14. Instale o DeepSea no nó master Salt:

root@master # zypper in deepsea

15. Verique se o arquivo /srv/pillar/ceph/master_minion.sls no master Salt apontapara o seu master Salt. Se o master Salt puder ser acessado por outros nomes de host, use oque for mais adequado ao cluster de armazenamento. Se você usou o nome de host padrãopara o seu master Salt (salt) no domínio ses, o arquivo tem esta 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.

35 Implantação do cluster SES 5

Nota: Convenções do comando saltHá duas maneiras possíveis de executar salt-run state.orch : uma é comstage.<número da fase> , 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 4.1: EXECUTANDO AS FASES DE IMPLANTAÇÃO

1. Inclua os minions Salt pertencentes ao cluster do Ceph que você está implantandoatualmente. Consulte a Seção 4.2.2.1, “Correspondendo o nome do minion” para obter maisinformações sobre como direcionar os minions.

2. Prepare o cluster. Consulte a 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

Nota: Executar ou monitorar fases usando a CLI do DeepSeaAo 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 4.4, “CLI do DeepSea”.

3. Opcional: crie subvolumes Btrfs para /var/lib/ceph/ . Essa etapa apenas deve serexecutada antes da execução das próximas fases do DeepSea. Para migrar os diretóriosexistentes ou para obter mais detalhes, consulte o Livro “Guia de Administração”, Capítulo 18

“Dicas e truques”, Seção 18.5 “Subvolume Btrfs para /var/lib/ceph”.

root@master # salt-run state.orch ceph.migrate.subvolume

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

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

36 Implantação do cluster SES 5

ou

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

5. 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 4.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: .

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

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

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.

37 Implantação do cluster SES 5

7. Agora você pode executar a fase de implantação. Nessa fase, o pilar é validado, e osdaemons dos monitores e ODS são iniciados nos nós de armazenamento. Execute o seguintepara iniciar a fase:

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:

root@master # ceph -s

8. 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,Object Gateway, openATTIC e NFS Ganesha. Nessa fase, os pools necessários, os chaveirosde autorização e os serviços de inicialização são criados. Para iniciar a fase, execute oseguinte:

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.

4.4 CLI do DeepSea

O DeepSea também fornece uma ferramenta CLI que permite ao usuário monitorar ou executaras fases enquanto visualiza o andamento da execução em tempo real.

38 CLI do DeepSea SES 5

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, comprivilégios de root .

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

É necessário iniciar o monitor antes de executar qualquer comando salt-run state.orch paraque ele 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

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

39 CLI do DeepSea: Modo monitor SES 5

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 .

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

40 CLI do DeepSea: Modo independente SES 5

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

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

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

41 CLI do DeepSea: Modo independente SES 5

4.5 Configuração e personalização

4.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, o nó que atua como OSDou como nó do monitor. 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/ .

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

42 Configuração e personalização SES 5

4.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, iSCSI Gateway ou openATTIC. Nenhuma função é atribuída automaticamente, apenasas funções adicionadas 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”, “mds”, “igw”,“rgw”, “ganesha” ou “openattic”.

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 por 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 monitoramento ao cluster do Ceph. Essa funçãorequer os endereços dos minions atribuídos. Desde o SUSE Enterprise Storage 5, o endereçopúblico é calculado dinamicamente e não é mais necessário no pillar do Salt.

role-mon/cluster/mon*.sls

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

43 Arquivo policy.cfg SES 5

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

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/stack/default/ceph/minions/xyz.domain.ymlrole-igw/cluster/*.sls

rgw:: o minion atuará como Object Gateway:

role-rgw/cluster/rgw*.sls

openattic: o minion atuará como servidor openATTIC:

role-openattic/cluster/openattic*.sls

Para obter mais informações, consulte Livro “Guia de Administração”, Capítulo 15 “openATTIC”.

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.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 14 “NFS

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

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

44 Arquivo policy.cfg SES 5

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

4.5.1.4 Atribuição de perfil

No Ceph, uma única função de armazenamento não é suciente para descrever as váriascongurações de disco disponíveis com o mesmo hardware. A fase 1 do DeepSea geraráuma proposta de perl de armazenamento padrão. Por padrão, essa proposta será um perlbluestore e tentará propor a conguração com o desempenho mais alto para a conguraçãode hardware especicada. Por exemplo, a preferência será por diários externos do que por umúnico disco com objetos e metadados. O armazenamento de estado sólido terá prioridade sobreos discos giratórios. Os pers são atribuídos no policy.cfg similares às funções.

A proposta padrão pode ser encontrada na árvore do diretório padrão do perl. Para incluir isso,adicione as duas linhas a seguir ao policy.cfg .

profile-default/cluster/*.slsprofile-default/stack/default/ceph/minions/*.yml

Você também pode criar um perl de armazenamento personalizado de sua preferência usandoo executor de proposta. Esse executor oferece três métodos: help, peek e populate.

salt-run proposal.help imprime o texto de ajuda do executor sobre os vários argumentosque ele aceita.

salt-run proposal.peek mostra a proposta gerada de acordo com os argumentos passados.

salt-run proposal.populate grava a proposta no subdiretório /srv/pillar/ceph/

proposals . Passe name=myprofile para nomear o perl de armazenamento. Isso resultará emum subdiretório prole-myprole.

Para todos os outros argumentos, consulte a saída do salt-run proposal.help .

45 Arquivo policy.cfg SES 5

4.5.1.5 Implantando OSDs criptografados

Desde o SUSE Enterprise Storage 5, por padrão, os OSDs são implantados usando o BlueStoreem vez do FileStore. Embora o BlueStore suporte criptograa, os Ceph OSDs são implantadossem criptograa, por padrão. Vamos supor que ambos os discos de dados e WAL/BD que serãousados para implantação do OSD estejam limpos, sem partições. Se os discos já foram usados,limpe-os seguindo o procedimento descrito na Etapa 13.

Para usar OSDs criptografados em sua nova implantação, use o executor proposal.populatecom o argumento encryption=dmcrypt :

root@master # salt-run proposal.populate encryption=dmcrypt

4.5.1.6 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

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$

46 Arquivo policy.cfg SES 5

4.5.1.7 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

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

# IGWrole-igw/stack/default/ceph/minions/ses-example-4.yml 7

role-igw/cluster/ses-example-4.sls 8

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

# openATTICrole-openattic/cluster/openattic*.sls 10

# COMMONconfig/stack/default/global.yml 11

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

## Profilesprofile-default/cluster/*.sls 13

profile-default/stack/default/ceph/minions/*.yml 14

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

47 Arquivo policy.cfg SES 5

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 O minion “ses-example-4” terá a função MDS.

7 Verique se o DeepSea sabe o endereço IP do nó IGW.

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

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

10 Especica para implantar a interface do usuário do openATTIC para administrar o clusterdo Ceph. Consulte a Livro “Guia de Administração”, Capítulo 15 “openATTIC” para obter maisdetalhes.

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

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

13 Informamos ao DeepSea para usar o perl de hardware padrão para cada minion. A escolhado perl de hardware padrão signica que todos os discos adicionais (exceto o disco raiz)devem ser OSDs.

14 Informamos ao DeepSea para usar o perl de hardware padrão para cada minion. A escolhado perl de hardware padrão signica que todos os discos adicionais (exceto o disco raiz)devem ser OSDs.

4.5.2 Arquivo ceph.conf personalizado

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

“Arquivo ceph.conf personalizado” para obter mais detalhes.

48 Arquivo ceph.conf personalizado SES 5

5 Fazendo upgrade de versões anteriores

Este capítulo apresenta as etapas de upgrade do SUSE Enterprise Storage de versões anteriorespara a atual.

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.

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 Procedimento geral de upgradeConsidere os seguintes itens antes de iniciar o procedimento de upgrade:

Ordem do upgrade

Antes de fazer upgrade do cluster do Ceph, você precisa registrar corretamente o SUSELinux Enterprise Server e o SUSE Enterprise Storage subjacentes no SCC ou na SMT. Vocêpoderá fazer upgrade dos daemons no cluster enquanto ele estiver online e em execução.Alguns tipos de daemons dependem de outros. Por exemplo, os Ceph Object Gatewaysdependem dos daemons Ceph Monitors e Ceph OSD. Recomendamos o upgrade nestaordem:

1. Ceph Monitors

2. Ceph Managers

3. Ceph OSDs

4. Servidores de Metadados

49 Ler os detalhes da versão SES 5

5. Object Gateways

6. iSCSI Gateways

7. NFS Ganesha

Apagar instantâneos desnecessários do sistema operacional

Remova os instantâneos de sistema de arquivos que não são necessários das partições denós do sistema operacional. Esse procedimento garante espaço livre suciente no discodurante o upgrade.

Verificar a saúde do cluster

É recomendável vericar a saúde do cluster antes de iniciar o procedimento de upgrade.

Fazer upgrade individualmente

Recomendamos fazer upgrade de todos os daemons de determinado tipo (por exemplo,todos os daemons monitor ou OSD) um de cada vez para garantir que todos sejam da mesmaversão. Recomendamos também fazer upgrade de todos os daemons no cluster antes devocê tentar usar uma nova funcionalidade em uma versão.Após o upgrade de todos os daemons de um tipo especíco, verique o status deles.Verique se cada monitor reingressou no quorum após o upgrade de todos os monitores:

root # ceph mon stat

Verique se cada daemon Ceph OSD reingressou no cluster após o upgrade de todos osOSDs:

root # ceph osd stat

Definir o flag require-osd-release luminous

Quando é feito o upgrade do último OSD para o SUSE Enterprise Storage 5, os nós domonitor detectam que todos os OSDs estão executando a versão “luminous” do Cephe podem reclamar que o ag require-osd-release luminous do osdmap não estádenido. Nesse caso, você precisa denir esse ag manualmente para conrmar que, agoraque o upgrade do cluster foi feito para “luminous”, não é possível revertê-lo para a versãomenos eciente “jewel” do Ceph. Dena o ag executando o seguinte comando:

root@minion > sudo ceph osd require-osd-release luminous

Após a conclusão do comando, o aviso desaparecerá.Nas novas instalações do SUSE Enterprise Storage 5, esse ag é denido automaticamentequando os Ceph Monitors criam o osdmap inicial. Dessa forma, nenhuma ação do usuárional é necessária.

50 Procedimento geral de upgrade SES 5

5.3 Criptografando OSDs durante o upgradeDesde o SUSE Enterprise Storage 5, por padrão, os OSDs são implantados usando o BlueStoreem vez do FileStore. Embora o BlueStore suporte criptograa, os Ceph OSDs são implantadossem criptograa, por padrão. O procedimento a seguir descreve as etapas para criptografar osOSDs durante o processo de upgrade. Vamos supor que ambos os discos de dados e WAL/BDque serão usados para implantação do OSD estejam limpos, sem partições. Se os discos já foramusados, limpe-os seguindo o procedimento descrito na Etapa 13.

Importante: Um OSD de cada vezVocê precisa implantar os OSDs criptografados um por um, não ao mesmo tempo. Omotivo disso é que os dados do OSD são esvaziados, e o cluster passa por várias iteraçõesde redistribuição.

1. Determine os valores bluestore block db size e bluestore block wal size

da sua implantação e adicione-os ao arquivo /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf no master Salt. Os valores precisam ser especicados embytes.

[global]bluestore block db size = 48318382080bluestore block wal size = 2147483648

Para obter mais informações sobre como personalizar o arquivo ceph.conf , consulte oLivro “Guia de Administração”, Capítulo 1 “Administração do cluster do Salt”, Seção 1.11 “Arquivo

ceph.conf personalizado”.

2. Execute a Fase 3 do DeepSea para distribuir as mudanças:

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

3. Verique se o arquivo ceph.conf está atualizado nos nós relevantes do OSD:

root@minion > cat /etc/ceph/ceph.conf

4. Edite os arquivos *.yml no diretório /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions relevantes aos OSDs que você está criptografando.Compare o caminho deles com o que foi denido no arquivo /srv/pillar/ceph/proposals/policy.cfg para garantir que você modique os arquivos *.yml corretos.

51 Criptografando OSDs durante o upgrade SES 5

Importante: Identificadores de disco longoAo identicar discos OSD nos arquivos /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/*.yml , use os identicadores de discolongo.

Veja a seguir um exemplo de conguração de OSD. Como a criptograa é necessária, asopções db_size e wal_size foram removidas:

ceph: storage: osds: /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_007027b1065faa972100d34d7aa06d86: format: bluestore encryption: dmcrypt db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_00d146b1065faa972100d34d7aa06d86: format: bluestore encryption: dmcrypt db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN

5. Implante os novos OSDs de Armazenamento em Blocos com criptograa executando asFases 2 e 3 do DeepSea:

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

Você poderá observar o andamento com ceph -s ou ceph osd tree . É essencial permitirque o cluster seja redistribuído antes de repetir o processo no próximo nó do OSD.

52 Criptografando OSDs durante o upgrade SES 5

5.4 Upgrade do SUSE Enterprise Storage 4(implantação do DeepSea) para 5

Importante: Requisitos de softwareVocê precisa ter o seguinte software instalado e atualizado para as versões mais recentesdos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciaro procedimento de upgrade:

SUSE Linux Enterprise Server 12 SP2

SUSE Enterprise Storage 4

Além disso, antes de iniciar o upgrade, você precisa fazer upgrade do nó master Saltpara o SUSE Linux Enterprise Server 12 SP3 e o SUSE Enterprise Storage 5 executando ocomando zypper migration (ou seu método de upgrade preferencial).

Atenção: Pontos de consideração antes do upgrade

Verique se o serviço AppArmor está em execução e desabilite-o em cada nó docluster. Inicie o módulo AppArmor do YaST, selecione Settings (Congurações) e,em seguida, desative a caixa de seleção Enable Apparmor (Habilitar Apparmor). Paraconrmar, clique em Done (Concluído).O SUSE Enterprise Storage não funcionará com o AppArmor habilitado.

Embora o cluster permaneça totalmente funcional durante o upgrade, o DeepSeadene o ag "noout", que impede o Ceph de redistribuir os dados durante o tempode espera e, portanto, evita transferências de dados desnecessárias.

Para otimizar o processo de upgrade, o DeepSea faz upgrade dos nós na ordem, combase nas funções atribuídas, conforme recomendado pelo upstream do Ceph: MONs,MGRs, OSDs, MDS, RGW, IGW e NFS Ganesha.O DeepSea não poderá evitar que a ordem recomendada seja violada se um nóexecutar vários serviços.

53 Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5 SES 5

Embora o cluster do Ceph permaneça operacional durante o upgrade, os nós podemser reinicializados para aplicar novas versões de kernel, por exemplo. Para reduzir asoperações de E/S em espera, é recomendável recusar solicitações recebidas duranteo processo de upgrade.

O upgrade do cluster pode levar muito tempo: aproximadamente o tempo necessáriopara fazer upgrade de uma máquina multiplicado pelo número de nós do cluster.

A partir do Ceph Luminous, a opção de conguração osd crush location não émais suportada. Atualize os arquivos de conguração do DeepSea para usar crushlocation antes do upgrade.

Para fazer upgrade do cluster do SUSE Enterprise Storage 4 para a versão 5, siga estas etapas:

1. Dena a nova ordem de classicação de objetos internos. Execute:

root # ceph osd set sortbitwise

DicaPara vericar se o comando foi bem-sucedido, recomendamos executar

root # ceph osd dump --format json-pretty | grep sortbitwise "flags": "sortbitwise,recovery_deletes,purged_snapdirs",

2. Usando o rpm -q deepsea , verique se a versão do pacote do DeepSea no nó master Saltcomeça com 0.7 no mínimo. Por exemplo:

root # rpm -q deepseadeepsea-0.7.27+git.0.274c55d-5.1

Se o número da versão do pacote do DeepSea começa com 0.6, verique se você migroucom êxito o nó master Salt para o SUSE Linux Enterprise Server 12 SP3 e o SUSE EnterpriseStorage 5 (consulte Importante: Requisitos de software no início desta seção). Isso se trata deum pré-requisito que deve ser concluído antes de iniciar o procedimento de upgrade.

3. a. Se você registrou seus sistemas com o SUSEConnect e usa SCC/SMT, nenhuma outraação é necessária. Continue na Etapa 4.

54 Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5 SES 5

b. Se você não usa SCC/SMT, mas uma ISO de Mídia ou outra fonte de pacote, adicioneos seguintes repositórios manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5Base e SES5 Update. Para fazer isso, você pode usar o comando zypper .Primeiramente, remova todos os repositórios de software existentes, adicione osnovos necessários e, por m, atualize as fontes dos repositórios:

root # zypper sd {0..99}root # zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot # zypper ref

Na sequência, mude os dados do Pillar para usar uma estratégia diferente. Edite

/srv/pillar/ceph/stack/name_of_cluster/cluster.yml

e adicione a linha a seguir:

upgrade_init: zypper-dup

DicaA estratégia zypper-dup requer que você adicione manualmente osrepositórios de software mais recentes, enquanto a zypper-migration

padrão utiliza os repositórios fornecidos pelo SCC/SMT.

4. Atualize o Pillar:

root@master # salt target saltutil.sync_all

Consulte a Seção 4.2.2, “Direcionando os minions” para obter detalhes sobre o destino dosminions Salt.

55 Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5 SES 5

5. Verique se você fez a gravação no Pillar com êxito:

root@master # salt target pillar.get upgrade_init

A saída do comando deve espelhar a entrada que você adicionou.

6. Faça upgrade dos minions Salt:

root@master # salt target state.apply ceph.updates.salt

7. Verique se foi feito o upgrade de todos os minions Salt:

root@master # salt target test.version

8. Inclua os minions Salt do cluster. Consulte a Seção  4.2.2, “Direcionando os minions” doProcedimento 4.1, “Executando as fases de implantação” para obter mais detalhes.

9. Inicie o upgrade do SUSE Linux Enterprise Server e do Ceph:

root@master # salt-run state.orch ceph.maintenance.upgrade

Dica: Nova execução na reinicializaçãoSe o processo resultar em uma reinicialização do master Salt, execute novamente ocomando para iniciar outra vez o processo de upgrade dos minions Salt.

10. Verique se o AppArmor está desabilitado e parado em todos os nós após o upgrade:

root # systemctl disable apparmor.servicesystemctl stop apparmor.service

11. Após o upgrade, os Ceph Managers ainda não estarão instalados. Para atingir um estadosaudável do cluster, faça o seguinte:

a. Execute a Fase 0 para habilitar a API REST do Salt:

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

b. Execute a Fase 1 para criar o subdiretório role-mgr/ :

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

56 Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5 SES 5

c. Edite o policy.cfg conforme descrito na Seção 4.5.1, “Arquivo policy.cfg” e adicioneuma função do Ceph Manager aos nós em que os Ceph Monitors estão implantados.Adicione também a função do openATTIC a um dos nós do cluster. Consulte o Livro

“Guia de Administração”, Capítulo 15 “openATTIC” para obter mais detalhes.

d. Execute a Fase 2 para atualizar o Pillar:

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

e. Agora, o DeepSea usa uma abordagem diferente para gerar o arquivo de conguraçãoceph.conf . Consulte o Livro “Guia de Administração”, Capítulo 1 “Administração do cluster

do Salt”, Seção 1.11 “Arquivo ceph.conf personalizado” para obter mais detalhes.

f. Execute a Fase 3 para implantar Ceph Managers:

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

g. Execute a Fase 4 para congurar o openATTIC apropriadamente:

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

57 Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5 SES 5

Nota: Incompatibilidade de recursos de chave do CephEm caso de falha no ceph.stage.3 com o erro: "Error EINVAL: entityclient.bootstrap-osd exists but caps do not match", signica que os recursos da chaveclient.bootstrap.osd existente do cluster não são compatíveis com aqueles queo DeepSea está tentando denir. Acima da mensagem de erro, em vermelho, vocêpode ver um dump do comando ceph auth que falhou. Analise esse comandopara vericar o ID da chave e o arquivo que estão sendo usados. No caso doclient.bootstrap-osd , o comando será

root # ceph auth add client.bootstrap-osd \ -i /srv/salt/ceph/osd/cache/bootstrap.keyring

Para corrigir recursos de chave incompatíveis, verique o conteúdo do arquivo dechaveiro que o DeepSea está tentando implantar. Por exemplo:

cephadm > cat /srv/salt/ceph/osd/cache/bootstrap.keyring[client.bootstrap-osd] key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw== caps mgr = "allow r" caps mon = "allow profile bootstrap-osd"

Compare-o com a saída de ceph auth get client.bootstrap-osd :

root # ceph auth get client.bootstrap-osdexported keyring for client.bootstrap-osd[client.bootstrap-osd] key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw== caps mon = "allow profile bootstrap-osd"

Observe que caps mgr = "allow r” está ausente na última chave. Para corrigirisso, execute:

root # ceph auth caps client.bootstrap-osd mgr \ "allow r" mon "allow profile bootstrap-osd"

Agora, a execução de ceph.stage.3 deve ser bem-sucedida.

O mesmo problema pode ocorrer com os chaveiros do Servidor de Metadados e doObject Gateway durante a execução do ceph.stage.4 . O mesmo procedimentoacima deve ser aplicado: vericar o comando que falhou, o arquivo de chaveiro

58 Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5 SES 5

que está sendo implantado e os recursos da chave existente. Em seguida, executeceph auth caps para atualizar os recursos da chave existente para corresponderaos que o DeepSea está implantando.

Importante: Falha no upgradeSe o estado do cluster permanecer como “HEALTH_ERR” por mais do que 300 segundos,ou se um dos serviços para cada função atribuída car inativo por mais do que 900segundos, haverá falha no upgrade. Nesse caso, tente localizar o problema, resolva-o eexecute o procedimento de upgrade novamente. Em ambientes virtualizados, observe queos tempos de espera são mais curtos.

Importante: Reinicializando os OSDsApós o upgrade do SUSE Enterprise Storage 5, os OSDs do FileStore precisarão deaproximadamente cinco minutos a mais para serem iniciados, já que o OSD fará umaconversão única de seus arquivos no disco.

Dica: Verificar a versão dos componentes/nós do clusterQuando você precisa saber as versões dos componentes e nós individuais do cluster (porexemplo, para saber se todos os seus nós estão realmente no mesmo nível de patch apóso upgrade), você pode executar

root@master # salt-run status.report

O comando analisa os minions Salt conectados, verica os números de versão do Ceph,Salt e SUSE Linux Enterprise Server e apresenta um relatório a você com a versão damaioria dos nós e os nós que têm uma versão diferente da maioria.

5.4.1 Migração do OSD para BlueStore

O 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, porque

59 Migração do OSD para BlueStore SES 5

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

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 mais rápida ou diferente.

No SES5, tanto o FileStore quanto o BlueStore são suportados, e os OSDs do FileStore e doBlueStore podem coexistir em um único cluster. Durante o procedimento de upgrade do SUSEEnterprise Storage, os OSDs do FileStore não são convertidos automaticamente em BlueStore.Os recursos especícos do BlueStore não estarão disponíveis nos OSDs que não foram migradospara 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

1. Migre os pers de hardware:

root@master # salt-run state.orch ceph.migrate.policy

Esse executor migra quaisquer pers de hardware que o arquivo policy.cfg usaatualmente. Ele processa o policy.cfg , encontra qualquer perl de hardware que usaa estrutura de dados original e converte-a na nova estrutura de dados. O resultado é umnovo perl de hardware chamado “migrated- nome_original ”. O policy.cfg tambémé atualizado.

60 Migração do OSD para BlueStore SES 5

Se a conguração original tinha diários separados, a conguração do BlueStore usará omesmo dispositivo do “wal” e do “db” para esse OSD.

2. O DeepSea migra os OSDs denindo o peso deles como 0, o que “aspira” os dados atéesvaziar o OSD. Você pode migrar os OSDs um por um ou todos ao mesmo tempo. Emqualquer um dos casos, quando o OSD estiver vazio, a orquestração o removerá e o recriarácom a nova conguração.

Dica: Método recomendadoUse ceph.migrate.nodes se você tiver um grande número de nós dearmazenamento físico ou poucos dados. Se um nó representa menos do que 10%da sua capacidade, o ceph.migrate.nodes pode ser um pouco mais rápido paramover todos os dados desses OSDs em paralelo.

Se você não tem certeza sobre qual método usar, ou se o site tem poucos nós dearmazenamento (por exemplo, cada nó tem mais do que 10% dos dados do cluster),selecione ceph.migrate.osds .

a. Para migrar os OSDs um de cada vez, execute:

root@master # salt-run state.orch ceph.migrate.osds

b. Para migrar todos os OSDs em cada nó em paralelo, execute:

root@master # salt-run state.orch ceph.migrate.nodes

DicaComo a orquestração não apresenta comentários sobre o andamento da migração,use

root # ceph osd tree

para ver quais OSDs têm um peso de zero periodicamente.

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

61 Migração do OSD para BlueStore SES 5

5.5 Upgrade do SUSE Enterprise Storage 4(implantação do ceph-deploy) para 5

Importante: Requisitos de softwareVocê precisa ter o seguinte software instalado e atualizado para as versões mais recentesdos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciaro procedimento de upgrade:

SUSE Linux Enterprise Server 12 SP2

SUSE Enterprise Storage 4

Escolha o master Salt para seu cluster. Se o Calamari está implantado no cluster, o nóCalamari já é o master Salt. Como alternativa, o nó de admin do qual você executou ocomando ceph-deploy se tornará o master Salt.

Antes de iniciar o procedimento a seguir, você precisa fazer upgrade do nó master Saltpara o SUSE Linux Enterprise Server 12 SP3 e o SUSE Enterprise Storage 5 executando ocomando zypper migration (ou seu método de upgrade preferencial).

Para fazer upgrade do cluster do SUSE Enterprise Storage 4 que foi implantado com ceph-deploy para a versão 5, siga estas etapas:

PROCEDIMENTO 5.1: ETAPAS PARA APLICAR A TODOS OS NÓS DO CLUSTER (INCLUINDO O NÓ CALAMARI)

1. Instale o pacote salt do SLE-12-SP2/SES4:

root # zypper install salt

2. Instale o pacote salt-minion do SLE-12-SP2/SES4, habilite e inicie o serviço relacionado:

root # zypper install salt-minionroot # systemctl enable salt-minionroot # systemctl start salt-minion

62 Upgrade do SUSE Enterprise Storage 4 (implantação do ceph-deploy) para 5 SES 5

3. Verique se o nome de host “salt” é resolvido para o endereço IP do nó master Salt. 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

DicaOs minions Salt existentes já têm a opção master: denida em /etc/salt/minion.d/calamari.conf . O nome do arquivo de conguração não importa, odiretório /etc/salt/minion.d/ é importante.

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

4. a. Se você registrou seus sistemas com o SUSEConnect e usa SCC/SMT, nenhuma outraação é necessária.

b. Se você não usa SCC/SMT, mas uma ISO de Mídia ou outra fonte de pacote, adicioneos seguintes repositórios manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5Base e SES5 Update. Para fazer isso, você pode usar o comando zypper .Primeiramente, remova todos os repositórios de software existentes, adicione osnovos necessários e, por m, atualize as fontes dos repositórios:

root # zypper sd {0..99}root # zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot # zypper ref

63 Upgrade do SUSE Enterprise Storage 4 (implantação do ceph-deploy) para 5 SES 5

PROCEDIMENTO 5.2: ETAPAS PARA APLICAR AO NÓ MASTER SALT

1. Dena a nova de ordem de classicação de objetos internos. Execute:

root@master # ceph osd set sortbitwise

DicaPara vericar se o comando foi bem-sucedido, recomendamos executar

root@master # ceph osd dump --format json-pretty | grep sortbitwise "flags": "sortbitwise,recovery_deletes,purged_snapdirs",

2. Faça upgrade do nó master Salt para o SUSE Linux Enterprise Server 12 SP3 e o SUSEEnterprise Storage 5. Para os sistemas registrados pelo SCC, use zypper migration . Sevocê inserir manualmente os repositórios de software necessários, use zypper dup . Apóso upgrade, verique se apenas os repositórios do SUSE Linux Enterprise Server 12 SP3e do SUSE Enterprise Storage 5 estão ativos (e atualizados) no nó master Salt antes deprosseguir.

3. Se ele ainda não estiver presente, instale o pacote salt-master , habilite e inicie o serviçorelacionado:

root@master # zypper install salt-masterroot@master # systemctl enable salt-masterroot@master # systemctl start salt-master

4. Verique a presença de todos os minions Salt listando suas chaves:

root@master # salt-key -L

5. Adicione todas as chaves dos minions Salt ao master Salt incluindo o master minion:

root@master # salt-key -A -y

6. Verique se as chaves de todos os minions Salt foram aceitas:

root@master # salt-key -L

7. Conrme se o software em seu nó master Salt está atualizado:

root@master # zypper migration

64 Upgrade do SUSE Enterprise Storage 4 (implantação do ceph-deploy) para 5 SES 5

8. Instale o pacote deepsea :

root@master # zypper install deepsea

9. Inclua os minions Salt do cluster. Consulte a Seção  4.2.2, “Direcionando os minions” doProcedimento 4.1, “Executando as fases de implantação” para obter mais detalhes.

10. Importe o cluster instalado pelo ceph-deploy existente:

root@master # salt-run populate.engulf_existing_cluster

O comando fará o seguinte:

Distribuirá todos os módulos do Salt e DeepSea necessários para todos os minionsSalt.

Inspecionará o cluster do Ceph em execução e preencherá /srv/pillar/ceph/proposals com um layout do cluster.O /srv/pillar/ceph/proposals/policy.cfg será criado com as funçõescorrespondentes a todos os serviços do Ceph em execução detectados. Veja essearquivo para vericar se cada um dos nós MON, OSD, RGW e MDS existentestem as funções apropriadas. Os nós OSD serão importados para o subdiretórioprofile-import/ , portanto, você pode examinar os arquivos em /srv/pillar/ceph/proposals/profile-import/cluster/ e /srv/pillar/ceph/proposals/profile-import/stack/default/ceph/minions/ para conrmar se os OSDsforam capturados corretamente.

NotaO policy.cfg gerado apenas aplicará as funções dos serviços do Cephdetectados “role-mon”, “role-mgr”, “role-mds”, “role-rgw”, “role-admin” e“role-master” referentes ao nó master Salt. Quaisquer outras funções desejadasdeverão ser adicionadas manualmente ao arquivo (consulte a Seção 4.5.1.2,

“Atribuição de função”).

O ceph.conf do cluster existente será gravado em /srv/salt/ceph/

configuration/files/ceph.conf.import .

65 Upgrade do SUSE Enterprise Storage 4 (implantação do ceph-deploy) para 5 SES 5

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

incluirá o fsid do cluster, o cluster e as redes públicas, além de especicara opção configuration_init: default-import , que faz o DeepSea usar oarquivo de conguração ceph.conf.import mencionado anteriormente, em vez deusar o gabarito /srv/salt/ceph/configuration/files/ceph.conf.j2 padrão doDeepSea.

Nota: Ceph.conf personalizadoSe você precisa integrar o arquivo ceph.conf com mudanças personalizadas,aguarde a conclusão bem-sucedida do processo de importação/upgrade.Em seguida, edite o arquivo /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml e comente na seguinte linha:

configuration_init: default-import

Grave o arquivo e siga as informações no Livro “Guia de Administração”, Capítulo

1 “Administração do cluster do Salt”, Seção 1.11 “Arquivo ceph.conf personalizado”.

Os vários chaveiros do cluster serão gravados nos seguintes diretórios:

/srv/salt/ceph/admin/cache//srv/salt/ceph/mon/cache//srv/salt/ceph/osd/cache//srv/salt/ceph/mds/cache//srv/salt/ceph/rgw/cache/

Verique se os arquivos de chaveiro existem e se não há um arquivo de chaveiro noseguinte diretório (o Ceph Manager não existia antes do SUSE Enterprise Storage 5):

/srv/salt/ceph/mgr/cache/

11. O comando salt-run populate.engulf_existing_cluster não consegue importar aconguração do openATTIC. Você precisa editar manualmente o arquivo policy.cfg eadicionar uma linha role-openattic . Consulte a Seção 4.5.1, “Arquivo policy.cfg” paraobter mais detalhes.

66 Upgrade do SUSE Enterprise Storage 4 (implantação do ceph-deploy) para 5 SES 5

12. O comando salt-run populate.engulf_existing_cluster não consegue importaras congurações de iSCSI Gateways. Se o cluster inclui iSCSI Gateways, importe ascongurações manualmente:

a. Em um dos nós do iSCSI Gateway, exporte o lrbd.conf atual e copie-o para o nómaster Salt:

root@minion > lrbd -o >/tmp/lrbd.confroot@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf

b. No nó master Salt, adicione a conguração padrão do iSCSI Gateway à conguraçãodo DeepSea:

root@master # mkdir -p /srv/pillar/ceph/stack/ceph/root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.ymlroot@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml

c. Adicione as funções do iSCSI Gateway ao policy.cfg e grave o arquivo:

role-igw/stack/default/ceph/minions/ses-1.ses.suse.ymlrole-igw/cluster/ses-1.ses.suse.sls[...]

13. Execute a Fase 1 para criar todas as funções possíveis:

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

14. Gere os subdiretórios necessários em /srv/pillar/ceph/stack :

root@master # salt-run push.proposal

15. Verique se existe um cluster gerenciado pelo DeepSea em execução com as funçõescorretamente atribuídas:

root@master # salt target pillar.get roles

Compare a saída com o layout real do cluster.

16. O Calamari deixa uma tarefa programada do Salt em execução para vericar o status docluster. Remova a tarefa:

root@minion > salt target schedule.delete ceph.heartbeat

67 Upgrade do SUSE Enterprise Storage 4 (implantação do ceph-deploy) para 5 SES 5

17. A partir deste ponto, siga o procedimento descrito na Seção 5.4, “Upgrade do SUSE Enterprise

Storage 4 (implantação do DeepSea) para 5”.

5.6 Upgrade do SUSE Enterprise Storage 4(implantação do Crowbar) para 5

Importante: Requisitos de softwareVocê precisa ter o seguinte software instalado e atualizado para as versões mais recentesdos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciaro procedimento de upgrade:

SUSE Linux Enterprise Server 12 SP2

SUSE Enterprise Storage 4

Para fazer upgrade do SUSE Enterprise Storage 4 implantado por meio do Crowbar para a versão5, siga estas etapas:

1. Para cada nó do Ceph (incluindo o nó Calamari), interrompa e desabilite todos os serviçosrelacionados ao Crowbar:

root@minion > sudo systemctl stop chef-clientroot@minion > sudo systemctl disable chef-clientroot@minion > sudo systemctl disable crowbar_joinroot@minion > sudo systemctl disable crowbar_notify_shutdown

2. Para cada nó do Ceph (incluindo o nó Calamari), verique se os repositórios de softwareapontam para os produtos SUSE Enterprise Storage 5 e SUSE Linux Enterprise Server12 SP3. Se ainda houver repositórios apontando para versões mais antigas do produto,desabilite-os.

3. Para cada nó do Ceph (incluindo o nó Calamari), verique se o salt-minion estáinstalado. Se não estiver, instale-o:

root@minion > sudo zypper in salt salt-minion

68 Upgrade do SUSE Enterprise Storage 4 (implantação do Crowbar) para 5 SES 5

4. Para os nós do Ceph sem o pacote salt-minion instalado, crie o arquivo /etc/salt/minion.d/master.conf com a opção master apontando para o nome completo do hostdo nó Calamari:

master: full_calamari_hostname

DicaOs minions Salt existentes já têm a opção master: denida em /etc/salt/minion.d/calamari.conf . O nome do arquivo de conguração não importa, odiretório /etc/salt/minion.d/ é importante.

Habilite e inicie o serviço salt-minion :

root@minion > sudo systemctl enable salt-minionroot@minion > sudo systemctl start salt-minion

5. No nó Calamari, aceite quaisquer chaves de minion Salt restantes:

root@master # salt-key -L[...]Unaccepted Keys:d52-54-00-16-45-0a.example.comd52-54-00-70-ac-30.example.com[...]

root@master # salt-key -AThe following keys are going to be accepted:Unaccepted Keys:d52-54-00-16-45-0a.example.comd52-54-00-70-ac-30.example.comProceed? [n/Y] yKey for minion d52-54-00-16-45-0a.example.com accepted.Key for minion d52-54-00-70-ac-30.example.com accepted.

6. Se o Ceph foi implantado na rede pública, e não há uma interface VLAN presente, adicioneuma interface VLAN na rede pública do Crowbar ao nó Calamari.

7. Faça upgrade do nó Calamari para o SUSE Linux Enterprise Server 12 SP3 e o SUSEEnterprise Storage 5, usando o comando zypper migration ou o método de suapreferência. A partir deste ponto, o nó Calamari torna-se o master Salt. Após o upgrade,reinicialize o master Salt.

69 Upgrade do SUSE Enterprise Storage 4 (implantação do Crowbar) para 5 SES 5

8. Instale o DeepSea no master Salt:

root@master # zypper in deepsea

9. Especique a opção deepsea_minions para incluir o grupo correto de minions Salt nasfases de implantação. Consulte a Seção  4.2.2.3, “Definir a opção deepsea_minions” paraobter mais detalhes.

10. O DeepSea espera que todos os nós do Ceph tenham um /etc/ceph/ceph.conf idêntico.O Crowbar implanta um ceph.conf levemente diferente em cada nó, portanto, vocêprecisa consolidá-lo:

Remova a opção osd crush location hook que foi incluída pelo Calamari.

Remova a opção public addr da seção [mon] .

Remova os números de porta da opção mon host .

11. Se você estava executando o Object Gateway, o Crowbar implantou um arquivo /etc/ceph/ceph.conf.radosgw à parte para manter os segredos do Keystone separados doarquivo ceph.conf regular. O Crowbar também adicionou um arquivo /etc/systemd/system/ceph-radosgw@.service personalizado. Como o DeepSea não oferece suporte aele, é necessário removê-lo:

Anexe todas as seções [client.rgw....] do arquivo ceph.conf.radosgw ao /etc/ceph/ceph.conf em todos os nós.

No nó do Object Gateway, execute o seguinte:

root@minion > rm /etc/systemd/system/ceph-radosgw@.servicesystemctl reenable ceph-radosgw@rgw.public.$hostname

12. Verique se o ceph status funciona quando executado do master Salt:

root@master # ceph statuscluster a705580c-a7ae-4fae-815c-5cb9c1ded6c2health HEALTH_OK[...]

13. Importe o cluster existente:

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

70 Upgrade do SUSE Enterprise Storage 4 (implantação do Crowbar) para 5 SES 5

root@master # salt-run push.proposal

14. O comando salt-run populate.engulf_existing_cluster não consegue importaras congurações de iSCSI Gateways. Se o cluster inclui iSCSI Gateways, importe ascongurações manualmente:

a. Em um dos nós do iSCSI Gateway, exporte o lrbd.conf atual e copie-o para o nómaster Salt:

root@minion > lrbd -o > /tmp/lrbd.confroot@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf

b. No nó master Salt, adicione a conguração padrão do iSCSI Gateway à conguraçãodo DeepSea:

root@master # mkdir -p /srv/pillar/ceph/stack/ceph/root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.ymlroot@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml

c. Adicione as funções do iSCSI Gateway ao policy.cfg e grave o arquivo:

role-igw/stack/default/ceph/minions/ses-1.ses.suse.ymlrole-igw/cluster/ses-1.ses.suse.sls[...]

15. a. Se você registrou seus sistemas com o SUSEConnect e usa SCC/SMT, nenhuma outraação é necessária.

b. Se você não usa SCC/SMT, mas uma ISO de Mídia ou outra fonte de pacote, adicioneos seguintes repositórios manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5Base e SES5 Update. Para fazer isso, você pode usar o comando zypper .Primeiramente, remova todos os repositórios de software existentes, adicione osnovos necessários e, por m, atualize as fontes dos repositórios:

root # zypper sd {0..99}root # zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot # zypper ar \

71 Upgrade do SUSE Enterprise Storage 4 (implantação do Crowbar) para 5 SES 5

http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot # zypper ref

Na sequência, mude os dados do Pillar para usar uma estratégia diferente. Editar

/srv/pillar/ceph/stack/name_of_cluster/cluster.yml

e adicione a linha a seguir:

upgrade_init: zypper-dup

DicaA estratégia zypper-dup requer que você adicione manualmente osrepositórios de software mais recentes, enquanto a zypper-migration

padrão utiliza os repositórios fornecidos pelo SCC/SMT.

16. Corrija os grains do host para fazer com que o DeepSea use nomes de host curtos na redepública para os IDs de instância do daemon Ceph. Para cada nó, você precisa executargrains.set com o novo nome de host (curto). Antes de executar grains.set , veriqueas instância atuais do monitor usando o comando ceph status . Veja a seguir um exemplode antes e depois:

root@master # salt target grains.get hostd52-54-00-16-45-0a.example.com: d52-54-00-16-45-0ad52-54-00-49-17-2a.example.com: d52-54-00-49-17-2ad52-54-00-76-21-bc.example.com: d52-54-00-76-21-bcd52-54-00-70-ac-30.example.com: d52-54-00-70-ac-30

root@master # salt d52-54-00-16-45-0a.example.com grains.set \ host public.d52-54-00-16-45-0aroot@master # salt d52-54-00-49-17-2a.example.com grains.set \ host public.d52-54-00-49-17-2aroot@master # salt d52-54-00-76-21-bc.example.com grains.set \ host public.d52-54-00-76-21-bc

72 Upgrade do SUSE Enterprise Storage 4 (implantação do Crowbar) para 5 SES 5

root@master # salt d52-54-00-70-ac-30.example.com grains.set \ host public.d52-54-00-70-ac-30

root@master # salt target grains.get hostd52-54-00-76-21-bc.example.com: public.d52-54-00-76-21-bcd52-54-00-16-45-0a.example.com: public.d52-54-00-16-45-0ad52-54-00-49-17-2a.example.com: public.d52-54-00-49-17-2ad52-54-00-70-ac-30.example.com: public.d52-54-00-70-ac-30

17. Execute o upgrade:

root@master # salt target state.apply ceph.updatesroot@master # salt target test.versionroot@master # salt-run state.orch ceph.maintenance.upgrade

Todos os nós serão reinicializados. O cluster retornará com a reclamação de que não háuma instância ativa do Ceph Manager. Isso costuma acontecer. Neste ponto, o Calamarinão deve mais ser instalado/estar em execução.

18. Execute todas as fases de implantação necessárias para atingir um estado saudável docluster:

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

19. Para implantar o openATTIC (consulte o Livro “Guia de Administração”, Capítulo 15

“openATTIC”), adicione a linha role-openattic apropriada (consulte a Seção  4.5.1.2,

“Atribuição de função”) ao /srv/pillar/ceph/proposals/policy.cfg . Em seguida,execute:

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

20. Durante o upgrade, você pode receber erros do tipo: "Error EINVAL: entity [...] existsbut caps do not match". Para resolvê-los, consulte a Seção 5.4, “Upgrade do SUSE Enterprise

Storage 4 (implantação do DeepSea) para 5”.

73 Upgrade do SUSE Enterprise Storage 4 (implantação do Crowbar) para 5 SES 5

21. Efetue a limpeza restante:

O Crowbar cria entradas em /etc/fstab para cada OSD. Elas não são necessárias,portanto, apague-as.

O Calamari deixa uma tarefa programada do Salt em execução para vericar o statusdo cluster. Remova a tarefa:

root@master # salt target schedule.delete ceph.heartbeat

Ainda restam alguns pacotes desnecessários instalados, a maioria deles relacionadaa ruby gems e chef. Não é necessário removê-los, mas convém apagá-los executandozypper rm nome_pct .

5.7 Upgrade do SUSE Enterprise Storage 3 para 5

Importante: Requisitos de softwareVocê precisa ter o seguinte software instalado e atualizado para as versões mais recentesdos pacotes em todos os nós do Ceph dos quais você deseja fazer upgrade antes de iniciaro procedimento de upgrade:

SUSE Linux Enterprise Server 12 SP1

SUSE Enterprise Storage 3

Para fazer upgrade do cluster do SUSE Enterprise Storage 3 para a versão 5, siga as etapasdescritas no Procedimento 5.1, “Etapas para aplicar a todos os nós do cluster (incluindo o nó Calamari)”

e no Procedimento 5.2, “Etapas para aplicar ao nó master Salt”.

74 Upgrade do SUSE Enterprise Storage 3 para 5 SES 5

6 Fazendo backup da configuração do cluster

Este capítulo explica os arquivos no nó de admin dos quais se deve fazer o backup. Logo apósconcluir a implantação ou a migração do seu cluster, crie um backup destes diretórios.

6.1 Fazer backup da configuração do SaltÉ possível fazer backup do diretório /etc/salt/ . Ele contém os arquivos de conguração doSalt. Por exemplo, a chave master do Salt e as chaves aceitas do cliente.

Os arquivos do Salt não são estritamente necessários para fazer backup do nó de admin, masfacilitam a reimplantação do cluster do Salt. Se não houver nenhum backup desses arquivos, osminions Salt precisarão ser registrados novamente no novo nó de admin.

Nota: Segurança da chave privada master do SaltGaranta que o backup da chave privada master do Salt esteja armazenado em um localseguro. A chave master do Salt pode ser usada para manipular todos os nós do cluster.

Após a restauração do diretório /etc/salt de um backup, reinicie os serviços Salt:

root@master # systemctl restart salt-masterroot@master # systemctl restart salt-minion

6.2 Fazer backup da configuração do DeepSeaTodos os arquivos necessários ao DeepSea são armazenados em /srv/pillar/ , /srv/salt/e /etc/salt/master.d .

Se você precisar reimplantar o nó de admin, instale o pacote do DeepSea no novo nó e movaos dados dos quais foi feito o backup de volta aos diretórios. Em seguida, o DeepSea poderá serusado novamente sem a necessidade de outras modicações. Antes de usar o DeepSea de novo,verique se todos os minions Salt estão registrados corretamente no nó de admin.

75 Fazer backup da configuração do Salt SES 5

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ê precise mudar as congurações de rede ou o softwareque está instalado por padrão no master Salt. 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

76 Usando arquivos de configuração personalizados SES 5

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

77 Substituindo uma etapa de implantação SES 5

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

78 Substituindo uma etapa de implantação SES 5

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

79 Modificando uma etapa de implantação SES 5

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:

80 Modificando uma fase de implantação SES 5

- .logrotate - .master - .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 Desabilitando 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 sobreas fases do DeepSea), o master e os minions Salt podem ser reinicializados porque os pacotesrecém-atualizados, como o kernel , exigem reinicialização do sistema.

Para evitar a atualização ou reinicialização de nós do cluster durante a Fase 0, edite o /srv/pillar/ceph/stack/ceph/cluster.yml e adicione as opções stage_prep_master oustage_prep_minion , dependendo se você precisa modicar o comportamento do master Salt,todos os minions Salt ou todos os nós.

As duas opções aceitam os seguintes valores:

default-no-update-no-reboot

Impede que os nós atualizem seus pacotes e sejam reinicializados.

default-no-update-reboot

Impede que os nós atualizem seus pacotes, mas as reinicializações são permitidas.

default-update-no-reboot

Impede que os nós sejam reinicializados, mas permite a atualização dos pacotes.

81 Desabilitando atualizações e reinicializações durante a fase 0 SES 5

default

Permite a atualização de pacotes dos nós e também sua reinicialização.

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

82 Modificando a configuração descoberta SES 5

172.16.21.11 public_network: 172.16.21.0/24 roles: - admin - mon - mds time_server: admin.ceph time_service: ntp

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/cephminions/ID do minion/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

83 Modificando a configuração descoberta SES 5

e, em seguida:

root@master # salt target pillar.items

84 Modificando a configuração descoberta SES 5

III Instalação de serviços adicionais

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

9 Ceph Object Gateway 87

10 Instalação do iSCSI Gateway 94

11 Instalação do CephFS 111

12 Instalação do NFS Ganesha 117

13 Exportar o CephFS via Samba 125

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

Após implantar o cluster do SUSE Enterprise Storage, 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 4, Implantando com o DeepSea/Salt para ver o procedimento de como instalargateways especícos ou o CephFS.

86 SES 5

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.

O daemon do Object Gateway usa um servidor HTTP incorporado (CivetWeb) para interagircom o cluster do Ceph. Como ele oferece interfaces compatíveis com o OpenStack Swift e oAmazon S3, o Object Gateway tem seu próprio gerenciamento de usuários. O Object Gatewaypode armazenar dados no mesmo cluster usado para armazenar dados dos clientes CephFS oudos clientes de Dispositivo de Blocos RADOS. As APIs do S3 e do Swift compartilham um espaçode nome comum, portanto, você pode gravar dados com uma API e recuperá-los com outra.

Importante: Object Gateway implantado pelo DeepSeaA partir do SUSE Enterprise Storage 5, o Object Gateway é instalado como uma funçãodo DeepSea, portanto, você não precisa instalá-lo manualmente.

Para instalar o Object Gateway durante a implantação do cluster, consulte a Seção 4.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 1 “Administração do cluster do Salt”, Seção 1.2 “Adicionando novas

funções aos nós”.

9.1 Instalação manual do Object Gateway

1. Instale o Object Gateway em um nó que não use a porta 80. Por exemplo, um nó queexecuta o openATTIC já está usando a porta 80. O comando a seguir instala todos oscomponentes necessários:

cephadm > sudo zypper ref && sudo zypper in ceph-radosgw

87 Instalação manual do Object Gateway SES 5

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 > sudo systemctl stop disable apache2.service

3. Edite /etc/ceph/ceph.conf e adicione as seguintes linhas:

[client.rgw.gateway_host] rgw frontends = "civetweb port=80"

DicaPara congurar o Object Gateway/CivetWeb para uso com a criptograa SSL,modique a linha de acordo:

rgw frontends = civetweb port=7480s ssl_certificate=path_to_certificate.pem

4. Reinicie o serviço Object Gateway.

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

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.

88 Configuração do Object Gateway SES 5

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 > sudo ceph-authtool --create-keyring /etc/ceph/ceph.client.rgw.keyringcephadm > 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 > sudo ceph-authtool /etc/ceph/ceph.client.rgw.keyring \ -n client.rgw.gateway --gen-key

3. Adicione recursos à chave:

cephadm > sudo ceph-authtool -n client.rgw.gateway --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.client.rgw.keyring

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 > sudo 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 > sudo scp /etc/ceph/ceph.client.rgw.keyring ceph@hostname:/home/cephcephadm > ssh hostnamecephadm > sudo mv ceph.client.rgw.keyring /etc/ceph/ceph.client.rgw.keyring

89 Configuração do Object Gateway SES 5

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 > sudo 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 > sudo 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 > sudo ceph \ auth get-or-create client.rgw.rgw_name osd 'allow rwx' mon 'allow rw' \ --connect-timeout=25 \ --cluster=ceph \ --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 > sudo scp \/var/lib/ceph/radosgw/ceph-rgw_name/keyring \rgw_host:/var/lib/ceph/radosgw/ceph-rgw_name/keyring

90 Configuração do Object Gateway SES 5

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

pools de armazenamento”, Seção 7.2.2 “Criar 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.

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 = hostnamekeyring = /etc/ceph/ceph.client.rgw.keyring

91 Configuração do Object Gateway SES 5

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

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

Você também deve considerar a instalação de um servidor DNS, como Dnsmasq, em sua(s)máquina(s) cliente ao usar a sintaxe http://bucketname.hostname . O arquivo dnsmasq.confdeve incluir as seguintes congurações:

address=/hostname/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.

92 Configuração do Object Gateway SES 5

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.

cephadm > sudo mkdir -p /var/lib/ceph/radosgw/cluster-id

Usando as congurações do ceph.conf do exemplo acima, você executa o seguinte:

cephadm > sudo 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 2

“Introdução” e o Livro “Guia de Administração”, Capítulo 11 “Ceph Object Gateway”, Seção 11.3 “Operando

o serviço Object Gateway”.

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>

93 Configuração do Object Gateway SES 5

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 inclui uma interface 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 de isolamento de segurança entre os clientes e o cluster do SUSEEnterprise Storage. O recurso de conguração é denominado lrbd . Ao usar o lrbd , osadministradores de armazenamento do Ceph podem denir volumes replicados, aprovisionadosdinamicamente e altamente disponíveis com suporte a instantâneos apenas leitura, clones deleitura-gravação e redimensionamento automático com RBD (RADOS Block Device – Dispositivode Blocos RADOS) do Ceph. Em seguida, os administradores podem exportar os volumes porum gateway lrbd único ou por vários hosts de gateway com suporte a failover de múltiploscaminhos. Os hosts do Linux, Microsoft Windows e VMware podem se conectar aos volumes peloprotocolo iSCSI, que os torna disponíveis como qualquer outro dispositivo de blocos SCSI. Issosignica que os clientes do SUSE Enterprise Storage podem executar com ecácia um subsistemacompleto de infraestrutura de armazenamento de blocos no Ceph, que fornece todos os recursose benefícios de uma SAN convencional, permitindo um 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 iSCSI

iSCSI é 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).

94 Armazenamento em blocos iSCSI SES 5

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.

95 Destino iSCSI do kernel do Linux SES 5

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 lrbdO lrbd combina os benefícios dos Dispositivos de Blocos RADOS com a versatilidade universaldo iSCSI. Ao executar o lrbd em um host de destino iSCSI (conhecido como gateway lrbd ),qualquer aplicativo que tenha que usar armazenamento em blocos poderá se beneciar do Ceph,mesmo que ele não reconheça nenhum protocolo de cliente do Ceph. Em vez disso, os usuáriospodem utilizar o iSCSI ou qualquer outro protocolo de front end de destino para se conectar aum destino LIO, o que converte todas as operações de E/S de destino em armazenamento RBD.

FIGURA 10.1: CLUSTER DO CEPH COM ÚNICO ISCSI GATEWAY

96 Informações gerais sobre lrbd SES 5

O lrbd apresenta alta disponibilidade inerente e suporta operações de múltiplos caminhos.Portanto, os hosts downstream do iniciador podem usar vários iSCSI Gateways para altadisponibilidade e escalabilidade. Durante a comunicação com uma conguração do iSCSI commais de um gateway, os iniciadores podem equilibrar a carga das solicitações iSCSI entre váriosgateways. Em caso de falha no gateway, estado temporariamente inacessível ou desabilitadopara 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

97 Informações gerais sobre lrbd SES 5

10.3 Considerações de implantação

Uma conguração mínima do SUSE Enterprise Storage com lrbd consiste nos seguintescomponentes:

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

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 com lrbd consisteem:

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, conguradospor meio do lrbd . 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ção

Esta seção descreve as etapas para instalar e congurar um iSCSI Gateway no SUSE EnterpriseStorage.

98 Considerações de implantação SES 5

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 4.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 1 “Administração do cluster do Salt”, Seção 1.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 , execute:

root # rbd --pool iscsi create --size=102400 testvol

O comando acima cria um volume RBD no formato padrão 2.

NotaA partir do SUSE Enterprise Storage 3, o formato padrão do volume é 2, e o formato 1 foidescontinuado. No entanto, você ainda pode criar volumes no formato 1 descontinuadocom a opção --image-format 1 .

10.4.3 Exportar imagens RBD por meio do iSCSI

Para exportar imagens RBD por meio do iSCSI, use o utilitário lrbd . O lrbd permite criar,revisar e modicar a conguração de destino iSCSI, que usa o formato JSON.

99 Implantar o iSCSI Gateway em um cluster do Ceph SES 5

Dica: Importar mudanças para o openATTICQuaisquer mudanças feitas na conguração do iSCSI Gateway com o comando lrbd nãocam visíveis no DeepSea e no openATTIC. Para importar as mudanças manuais, vocêprecisa exportar a conguração do iSCSI Gateway para um arquivo:

root@minion > lrbd -o /tmp/lrbd.conf

Em seguida, copie-a no master Salt para que o DeepSea e o openATTIC possam vê-la:

root@minion > scp /tmp/lrbd.conf ses5master:/srv/salt/ceph/igw/cache/lrbd.conf

Por m, edite o /srv/pillar/ceph/stack/global.yml e dena:

igw_config: default-ui

Para editar a conguração, use lrbd -e ou lrbd --edit . Esse comando invocará oeditor padrão, conforme denido pela variável de ambiente EDITOR . Você pode anular essecomportamento denindo a opção -E , além da -e .

Veja a seguir um exemplo de conguração para

dois hosts do iSCSI Gateway chamados iscsi1.example.com e iscsi2.example.com ,

denindo um único destino iSCSI com o IQN (iSCSI Qualied Name – Nome QualicadoiSCSI) iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol ,

com uma única LU (Logical Unit – Unidade Lógica) iSCSI,

com base em uma imagem RBD denominada testvol no pool RADOS rbd

e exportando o destino por meio de dois portais chamados "east" e "west":

{ "auth": [ { "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol", "authentication": "none" } ], "targets": [ {

100 Exportar imagens RBD por meio do iSCSI SES 5

"target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol", "hosts": [ { "host": "iscsi1.example.com", "portal": "east" }, { "host": "iscsi2.example.com", "portal": "west" } ] } ], "portals": [ { "name": "east", "addresses": [ "192.168.124.104" ] }, { "name": "west", "addresses": [ "192.168.124.105" ] } ], "pools": [ { "pool": "rbd", "gateways": [ { "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol", "tpg": [ { "image": "testvol" } ] } ] } ] }

Sempre que você zer referência a um nome de host na conguração, observe que ele deverácorresponder à saída do comando uname -n do iSCSI Gateway.

101 Exportar imagens RBD por meio do iSCSI SES 5

O JSON editado é armazenado nos atributos estendidos (xattrs) de um único objeto RADOS porpool. Esse objeto está disponível aos hosts do gateway em que o JSON foi editado e tambéma todos os hosts do gateway conectados ao mesmo cluster do Ceph. Nenhuma informação deconguração é armazenada localmente no gateway lrbd .

Para ativar a conguração, armazene-a no cluster do Ceph e execute uma das seguintes opções(como root ):

Execute o comando lrbd (sem opções adicionais) na linha de comando,

ou

Reinicie o serviço lrbd com service lrbd restart .

O "serviço” lrbd não opera nenhum daemon em segundo plano. Em vez disso, ele simplesmenteinvoca o comando lrbd . Esse tipo de serviço é conhecido como "monoestável".

Você também deve habilitar o lrbd para conguração automática na inicialização do sistema.Para fazer isso, execute o comando systemctl enable lrbd .

A conguração acima reete uma denição simples de único gateway. A conguração do lrbdpode ser muito mais complexa e eciente. O pacote RPM lrbd vem com um conjunto completode exemplos de conguração, que você pode consultar acessando o conteúdo do diretório /usr/share/doc/packages/lrbd/samples após a instalação. Os exemplos também estão disponíveisem https://github.com/SUSE/lrbd/tree/master/samples .

10.4.4 Configurações opcionais

As congurações a seguir podem ser úteis em alguns ambientes. Para imagens, existem osatributos uuid , lun , retries , sleep e retry_errors . Os dois primeiros, uuid e lun ,permitem codicar “uuid” ou “lun” para determinada imagem. Você pode especicar um delespara uma imagem. retries , sleep e retry_errors afetam as tentativas de mapear umaimagem RBD.

"pools": [ { "pool": "rbd", "gateways": [ { "host": "igw1", "tpg": [ {

102 Configurações opcionais SES 5

"image": "archive", "uuid": "12345678-abcd-9012-efab-345678901234", "lun": "2", "retries": "3", "sleep": "4", "retry_errors": [ 95 ], [...] } ] } ] }]

10.4.5 Configurações avançadas

É possível congurar o lrbd com parâmetros avançados, que depois são passados para o destinode E/S do LIO. Os parâmetros são divididos em componentes de armazenamento iSCSI e debackup que, em seguida, podem ser especicados nas seções "targets” e "tpg", respectivamente,da conguração lrbd .

AtençãoNão é recomendável mudar a conguração padrão desses parâmetros.

"targets": [ { [...] "tpg_default_cmdsn_depth": "64", "tpg_default_erl": "0", "tpg_login_timeout": "10", "tpg_netif_timeout": "2", "tpg_prod_mode_write_protect": "0", }]

Veja a seguir uma descrição das opções:

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

103 Configurações avançadas SES 5

tpg_default_erl

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

tpg_login_timeout

Valor de tempo de espera de login em segundos.

tpg_netif_timeout

Tempo de espera de falha da NIC em segundos.

tpg_prod_mode_write_protect

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

"pools": [ { "pool": "rbd", "gateways": [ { "host": "igw1", "tpg": [ { "image": "archive", "backstore_block_size": "512", "backstore_emulate_3pc": "1", "backstore_emulate_caw": "1", "backstore_emulate_dpo": "0", "backstore_emulate_fua_read": "0", "backstore_emulate_fua_write": "1", "backstore_emulate_model_alias": "0", "backstore_emulate_rest_reord": "0", "backstore_emulate_tas": "1", "backstore_emulate_tpu": "0", "backstore_emulate_tpws": "0", "backstore_emulate_ua_intlck_ctrl": "0", "backstore_emulate_write_cache": "0", "backstore_enforce_pr_isids": "1", "backstore_fabric_max_sectors": "8192", "backstore_hw_block_size": "512", "backstore_hw_max_sectors": "8192", "backstore_hw_pi_prot_type": "0", "backstore_hw_queue_depth": "128", "backstore_is_nonrot": "1", "backstore_max_unmap_block_desc_count": "1", "backstore_max_unmap_lba_count": "8192", "backstore_max_write_same_len": "65535", "backstore_optimal_sectors": "8192", "backstore_pi_prot_format": "0",

104 Configurações avançadas SES 5

"backstore_pi_prot_type": "0", "backstore_queue_depth": "128", "backstore_unmap_granularity": "8192", "backstore_unmap_granularity_alignment": "4194304" } ] } ] }]

Veja a seguir uma descrição das opções:

backstore_block_size

Tamanho do bloco do dispositivo subjacente.

backstore_emulate_3pc

Se denida como 1, habilita Third Party Copy (Cópia de Terceiros).

backstore_emulate_caw

Se denida como 1, habilita Compare (Comparar) e Write (Gravar).

backstore_emulate_dpo

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

backstore_emulate_fua_read

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

backstore_emulate_fua_write

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

backstore_emulate_model_alias

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

backstore_emulate_rest_reord

Se denida como 0, o Modicador de Algoritmo de Fila terá Reordenação Restrita.

backstore_emulate_tas

Se denida como 1, habilita o Task Aborted Status (Status Interrompido da Tarefa).

backstore_emulate_tpu

Se denida como 1, habilita Thin Provisioning Unmap (Anulação do Mapeamento deAprovisionamento Dinâmico).

105 Configurações avançadas SES 5

backstore_emulate_tpws

Se denida como 1, habilita Thin Provisioning Write Same (Mesma Gravação deAprovisionamento Dinâmico).

backstore_emulate_ua_intlck_ctrl

Se denida como 1, habilita Unit Attention Interlock (Interbloqueio de Atenção deUnidade).

backstore_emulate_write_cache

Se denida como 1, ativa o recurso Write Cache Enable (Habilitação de Gravação deCache).

backstore_enforce_pr_isids

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

backstore_fabric_max_sectors

Número máximo de setores que a malha pode transferir de uma vez.

backstore_hw_block_size

Tamanho do bloco de hardware em bytes.

backstore_hw_max_sectors

Número máximo de setores que o hardware pode transferir de uma vez.

backstore_hw_pi_prot_type

Se for diferente de zero, a proteção DIF será habilitada no hardware subjacente.

backstore_hw_queue_depth

Profundidade da la de hardware.

backstore_is_nonrot

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

backstore_max_unmap_block_desc_count

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

backstore_max_unmap_lba_count:

Número máximo de LBAs para UNMAP.

backstore_max_write_same_len

Tamanho máximo para WRITE_SAME.

backstore_optimal_sectors

Tamanho da solicitação ideal em setores.

106 Configurações avançadas SES 5

backstore_pi_prot_format

Formato da proteção DIF.

backstore_pi_prot_type

Tipo de proteção DIF.

backstore_queue_depth

Profundidade da la.

backstore_unmap_granularity

Granularidade de UNMAP.

backstore_unmap_granularity_alignment

Alinhamento da granularidade de UNMAP.

Para destinos, os atributos tpg permitem o ajuste dos parâmetros de kernel. Use com cuidado.

"targets": [{ "host": "igw1", "target": "iqn.2003-01.org.linux-iscsi.generic.x86:sn.abcdefghijk", "tpg_default_cmdsn_depth": "64", "tpg_default_erl": "0", "tpg_login_timeout": "10", "tpg_netif_timeout": "2", "tpg_prod_mode_write_protect": "0", "tpg_t10_pi": "0"}

DicaSe um site precisa de LUNs atribuídos estaticamente, atribua números a cada LUN.

10.5 Exportando imagens de dispositivo de blocosRADOS por meio do tcmu-runnerDesde a versão 5, o SUSE Enterprise Storage fornece um back end RBD de espaço de usuáriopara tcmu-runner (consulte man 8 tcmu-runner para obter detalhes).

107 Exportando imagens de dispositivo de blocos RADOS por meio do tcmu-runner SES 5

Atenção: Technology PreviewAtualmente, as implantações do iSCSI Gateway com base no tcmu-runner estão naversão Technology Preview. Consulte o Capítulo 10, Instalação do iSCSI Gateway para obterinstruções sobre a implantação do iSCSI Gateway baseada em kernel com o lrbd .

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

Atualmente, como o DeepSea e o openATTIC não suportam implantações por tcmu-runner ,você precisa gerenciar a instalação, a implantação e o monitoramento manualmente.

10.5.1 Instalação

No nó do iSCSI Gateway, instale o pacote tcmu-runner-handler-rbd da mídia do SUSEEnterprise Storage 5 juntamente com as dependências de pacote libtcmu1 e tcmu-runner .Instale o pacote targetcli-fb para ns de conguração. Observe que o pacote targetcli-fb não é compatível a versão “não fb” do pacote targetcli .

Conrme se o serviço tcmu-runner systemd está em execução:

root # systemctl enable tcmu-runnertcmu-gw:~ # systemctl status tcmu-runner● tcmu-runner.service - LIO Userspace-passthrough daemon Loaded: loaded (/usr/lib/systemd/system/tcmu-runner.service; static; vendor preset: disabled) Active: active (running) since ...

10.5.2 Configuração e implantação

Crie uma imagem de Dispositivo de Blocos RADOS no cluster do Ceph existente. No exemplo aseguir, usaremos uma imagem de 10 G chamada “tcmu-lu” localizada no pool “rbd”.

Após a criação da imagem de Dispositivo de Blocos RADOS, execute targetcli e verique seo gerenciador RBD tcmu-runner (plug-in) está disponível:

root # targetclitargetcli shell version 2.1.fb46Copyright 2011-2013 by Datera, Inc and others.

108 Instalação SES 5

For help on commands, type 'help'.

/> lso- / ................................... [...] o- backstores ........................ [...]... | o- user:rbd ......... [Storage Objects: 0]

Crie uma entrada de conguração de backstore para a imagem RBD:

/> cd backstores/user:rbd/backstores/user:rbd> create tcmu-lu 10G /rbd/tcmu-luCreated user-backed storage object tcmu-lu size 10737418240.

Crie uma entrada de conguração de transporte iSCSI. No exemplo a seguir, o IQN dedestino "iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a” é automaticamente geradopelo targetcli para ser usado como identicador exclusivo de destino iSCSI:

/backstores/user:rbd> cd /iscsi/iscsi> createCreated target iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a.Created TPG 1.Global pref auto_add_default_portal=trueCreated default portal listening on all IPs (0.0.0.0), port 3260.

Crie uma entrada ACL para o(s) iniciador(es) iSCSI que você deseja conectar ao destino. Noexemplo a seguir, o IQN do iniciador "iqn.1998-01.com.vmware:esxi-872c4888” é usado:

/iscsi> cdiqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a/tpg1/acls//iscsi/iqn.20...a3a/tpg1/acls> create iqn.1998-01.com.vmware:esxi-872c4888

Por m, vincule a conguração de backstore do RBD criada anteriormente ao destino iSCSI:

/iscsi/iqn.20...a3a/tpg1/acls> cd ../luns/iscsi/iqn.20...a3a/tpg1/luns> create /backstores/user:rbd/tcmu-luCreated LUN 0.Created LUN 0->0 mapping in node ACL iqn.1998-01.com.vmware:esxi-872c4888

Saia do shell para gravar a conguração existente:

/iscsi/iqn.20...a3a/tpg1/luns> exitGlobal pref auto_save_on_exit=trueLast 10 configs saved in /etc/target/backup.Configuration saved to /etc/target/saveconfig.json

109 Configuração e implantação SES 5

10.5.3 Uso

Em seu nó do iniciador iSCSI (cliente), conecte-se ao destino iSCSI recém-provisionado usandoo IQN e o nome de host congurados anteriormente.

110 Uso SES 5

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 CephFS

Com o SUSE Enterprise Storage, 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”, e o restante será “passivo”. Lembre-se de mencionartodos os nós MDS no comando mount ao montar o CephFS de um cliente.

Os instantâneos do CephFS estão desabilitados (padrão) e não são suportados nesta versão.

Os clientes são baseados no SUSE Linux Enterprise Server 12 SP2 ou SP3 e usam o driverdo módulo do kernel cephfs . O módulo FUSE não é suportado.

As cotas do CephFS não são suportadas no SUSE Enterprise Storage, já que o suporte acotas foi implementado apenas no cliente do FUSE.

O CephFS suporta mudanças de layout de arquivo, conforme documentado em http://

docs.ceph.com/docs/jewel/cephfs/file-layouts/ . No entanto, embora o sistema de arquivosseja montado por qualquer cliente, novos pools de dados não podem ser adicionados a umsistema de arquivos CephFS existente ( ceph mds add_data_pool ). Eles apenas podemser adicionados enquanto o sistema de arquivos está desmontado.

111 Cenários e diretrizes suportados do CephFS SES 5

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 4.3, “Implantação do cluster”, ou adicioná-lo a um cluster já implantado, conformedescrito no Livro “Guia de Administração”, Capítulo 1 “Administração do cluster do Salt”, Seção 1.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 .

TAMANHO DO CACHE DO MDS

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.

Para obter uma lista detalhada das opções de conguração relacionadas ao MDS, consulte http://

docs.ceph.com/docs/master/cephfs/mds-config-ref/ .

112 Servidor de metadados Ceph SES 5

Para obter uma lista detalhada das opções de conguração do gravador de diário do MDS,consulte http://docs.ceph.com/docs/master/cephfs/journaler/ .

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.

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

root # ceph osd pool create cephfs_data pg_numroot # 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 .

113 CephFS SES 5

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 :

root # ceph fs new fs_name metadata_pool_name data_pool_name

Por exemplo:

root # ceph fs new cephfs cephfs_metadata cephfs_data

Você pode vericar se o sistema de arquivos foi criado listando todos os CephFSs disponíveis:

root # 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:

root # ceph mds state5: 1/1/1 up

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

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

114 Tamanho do cluster MDS SES 5

root # ceph mds stat

O comando a seguir dene o número de MDS ativos como dois em uma instância do sistemade arquivos.

root # 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:

root # ceph fs set fs_name max_mds 1

e, em seguida, desative explicitamente os outros daemons MDS ativos:

root # 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. Consulte http://docs.ceph.com/docs/luminous/cephfs/multimds/

para obter informações adicionais.

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 serecusarã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 1 instância e pare todos osdaemons MDS de standby usando as unidades systemd deles em todos os outros nós:

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

115 Cluster e atualizações do MDS SES 5

root # systemctl restart ceph-mds\*.service ceph-mds.target

4. Reinicie todos os outros daemons MDS e redena a conguração max_mds desejada.

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

116 Cluster e atualizações do MDS SES 5

12 Instalação do NFS Ganesha

O NFS Ganesha concede acesso de NFS ao Object Gateway ou CephFS. No SUSE EnterpriseStorage 5, 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.

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 4.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 4.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 14 “NFS Ganesha: Exportar

dados do Ceph pelo NFS”, Seção 14.2 “Configuração”.

117 Preparação SES 5

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.

Se o NFS Ganesha tiver que usar o Object Gateway para estabelecer interface com o cluster,o /srv/pillar/ceph/rgw.sls no master Salt deverá ser preenchido.

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 # salt-run state.orch ceph.stage.0root # 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. Crie o arquivo /srv/pillar/ceph/rgw.sls e insira o seguinte conteúdo:

rgw_configurations: rgw: users: - { uid: "demo", name: "Demo", email: "demo@demo.nil" } - { uid: "demo1", name: "Demo1", email: "demo1@demo.nil" }

118 Resumo dos requisitos SES 5

Posteriormente, esses usuários serão criados como usuários do Object Gateway, e as chavesde API serão geradas. No nó do Object Gateway, você pode depois executar radosgw-admin user list para listar todos os usuários criados, e radosgw-admin user info --uid=demo para obter detalhes sobre usuários únicos.O DeepSea garante que tanto o Object Gateway quanto o NFS Ganesha recebam ascredenciais de todos os usuários listados na seção rgw do rgw.sls .O NFS exportado usa esses nomes de usuário no primeiro nível do sistema de arquivos.Neste exemplo, os caminhos /demo e /demo1 serão exportados.

4. Execute pelo menos as fases 2 e 4 do DeepSea. É recomendável executar a fase 3 entre elas.

root # salt-run state.orch ceph.stage.2root # salt-run state.orch ceph.stage.3 # optional but recommendedroot # salt-run state.orch ceph.stage.4

5. Monte o compartilhamento NFS de um nó de cliente para vericar se o NFS Ganesha estáfuncionando:

root # mount -o sync -t nfs GANESHA_NODE:/ /mntroot # ls /mntcephfs demo demo1

O /mnt deve conter todos os caminhos exportados. Os diretórios para o CephFS e ambosos usuários do Object Gateway devem existir. Para cada compartimento de memória queum usuário possui, um caminho /mnt/USERNAME/BUCKETNAME é exportado.

12.3 Configuração ativa-passiva de altadisponibilidade

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

Para obter detalhes sobre a SUSE Linux Enterprise High Availability Extension, consulte https://

www.suse.com/documentation/sle-ha-12/ .

119 Configuração ativa-passiva de alta disponibilidade SES 5

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 ser encontradosem https://www.suse.com/documentation/sle-ha-12/install-quick/data/install-quick.html .

1. Prepare os nós do NFS Ganesha no master Salt:

a. Execute as fases 0 e 1 do DeepSea no master Salt.

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 3 e 4 do DeepSea no master Salt.

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

120 Instalação básica SES 5

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

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 ]

121 Instalação básica SES 5

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

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 \

122 Limpar recursos SES 5

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.

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

123 HA do NFS Ganesha e DeepSea SES 5

12.4 Mais informaçõesMais informações podem ser encontradas no Livro “Guia de Administração”, Capítulo 14 “NFS

Ganesha: Exportar dados do Ceph pelo NFS”.

124 Mais informações SES 5

13 Exportar o CephFS via Samba

Esta seção descreve como exportar o CephFS por meio de um compartilhamento Samba/CIFS.É possível usar compartilhamentos Samba com clientes Windows*.

Atenção: Technology PreviewA partir do SUSE Enterprise Storage 5, a exportação de compartilhamentos Samba éconsiderada uma versão Technology Preview e não é suportada.

13.1 Exemplo de instalaçãoA exportação do CephFS é uma versão Technology Preview e não é suportada. Para exportarum compartilhamento Samba, você precisa instalar manualmente o Samba em um nó de clustere congurá-lo. É possível fornecer a funcionalidade de failover com o CTDB e a SUSE LinuxEnterprise High Availability Extension.

1. Verique se já existe um CephFS em execução no cluster. Para obter os detalhes, consulteo Capítulo 11, Instalação do CephFS.

2. Crie um chaveiro especíco do Gateway do Samba no master Salt e copie-o para o nó dogateway do Samba:

root@master # ceph auth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyringroot@master # scp ceph.client.samba.gw.keyring SAMBA_NODE:/etc/ceph/

Substitua SAMBA_NODE pelo nome do nó do gateway do Samba.

3. As etapas a seguir são executadas no nó do gateway do Samba. Instale o daemon do Sambano nó do gateway do Samba:

root # zypper in samba samba-ceph

4. Edite o /etc/samba/smb.conf e adicione a seguinte seção:

[SHARE_NAME] path = / vfs objects = ceph ceph:config_file = /etc/ceph/ceph.conf ceph: user_id = samba.gw

125 Exemplo de instalação SES 5

read only = no

5. Inicie e habilite o daemon do Samba:

root # systemctl start smb.serviceroot # systemctl enable smb.serviceroot # systemctl start nmb.serviceroot # systemctl enable nmb.service

13.2 Configuração de alta disponibilidade

Esta seção apresenta um exemplo de como denir uma conguração de dois nós dealta disponibilidade dos servidores Samba. A conguração requer a SUSE Linux EnterpriseHigh Availability Extension. Os dois nós são denominados earth ( 192.168.1.1 ) e mars( 192.168.1.2 ).

Para obter detalhes sobre a SUSE Linux Enterprise High Availability Extension, consulte https://

www.suse.com/documentation/sle-ha-12/ .

Além disso, dois endereços IP virtuais utuantes permitem aos clientes se conectarem ao serviçoindependentemente do nó físico no qual está sendo executado. 192.168.1.10 é usado paraadministração do cluster com Hawk2, e 192.168.2.1 é usado exclusivamente para exportaçõesCIFS. Isso facilita aplicar as restrições de segurança mais tarde.

O procedimento a seguir descreve a instalação de exemplo. Mais detalhes podem ser encontradosem https://www.suse.com/documentation/sle-ha-12/install-quick/data/install-quick.html .

1. Crie um chaveiro especíco do Gateway do Samba no master Salt e copie-o para os doisnós:

root@master # ceph auth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyringroot@master # scp ceph.client.samba.gw.keyring earth:/etc/ceph/root@master # scp ceph.client.samba.gw.keyring mars:/etc/ceph/

2. Prepare o earth e o mars para hospedar o serviço do Samba:

a. Verique se os seguintes pacotes estão instalados antes de continuar: ctdb , tdb-tools e samba (necessário para os recursos smb e nmb).

root # zypper in ctdb tdb-tools samba samba-ceph

126 Configuração de alta disponibilidade SES 5

b. Verique se os serviços ctdb , smb e nmb estão parados e desabilitados:

root # systemctl disable ctdbroot # systemctl disable smbroot # systemctl disable nmbroot # systemctl stop smbroot # systemctl stop nmb

c. Abra a porta 4379 do seu rewall em todos os nós. Isso é necessário para o CTDBse comunicar com outros nós do cluster.

d. Crie um diretório para o bloqueio do CTDB no sistema de arquivos compartilhado:

root # mkdir -p /srv/samba/

3. No earth , crie os arquivos de conguração para o Samba. Mais tarde, eles serãosincronizados automaticamente com o mars .

a. Em /etc/ctdb/nodes , insira todos os nós que contêm todos os endereços IPprivados de cada nó no cluster:

192.168.1.1192.168.1.2

b. Congure o Samba. Adicione as seguintes linhas à seção [global] do /etc/samba/smb.conf . Use o nome de host de sua escolha em vez de "CTDB-SERVER" (todos osnós no cluster aparecerão como um nó grande com esse nome, efetivamente):

[global] netbios name = CTDB-SERVER clustering = yes idmap config * : backend = tdb2 passdb backend = tdbsam ctdbd socket = /var/lib/ctdb/ctdb.socket

Para obter detalhes sobre o csync2 , consulte https://www.suse.com/documentation/

sle-ha-12/singlehtml/book_sleha/

book_sleha.html#pro.ha.installation.setup.csync2.start .

4. Instale e inicialize o cluster da SUSE Linux Enterprise High Availability.

a. Registre a SUSE Linux Enterprise High Availability Extension no earth e no mars .

127 Configuração de alta disponibilidade SES 5

root@earth # SUSEConnect -r ACTIVATION_CODE -e E_MAIL

root@mars # SUSEConnect -r ACTIVATION_CODE -e E_MAIL

b. Instale o ha-cluster-bootstrap nos dois nós:

root@earth # zypper in ha-cluster-bootstrap

root@mars # zypper in ha-cluster-bootstrap

c. Inicialize o cluster no earth :

root@earth # ha-cluster-init

d. 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 status2 nodes configured1 resource configured

Online: [ earth mars ]

Full list of resources:

admin-ip (ocf::heartbeat:IPaddr2): Started earth

6. Execute os seguintes comandos no earth para congurar o recurso CTDB:

root@earth # crm configurecrm(live)configure# primitive ctdb ocf:heartbeat:CTDB params \ ctdb_manages_winbind="false" \ ctdb_manages_samba="false" \ ctdb_recovery_lock="!/usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper ceph client.samba.gw cephfs_metadata ctdb-mutex" ctdb_socket="/var/lib/ctdb/ctdb.socket" \ op monitor interval="10" timeout="20" \ op start interval="0" timeout="90" \ op stop interval="0" timeout="100"crm(live)configure# primitive nmb systemd:nmb \ op start timeout="60" interval="0" \

128 Configuração de alta disponibilidade SES 5

op stop timeout="60" interval="0" \ op monitor interval="60" timeout="60"crm(live)configure# primitive smb systemd:smb \ op start timeout="60" interval="0" \ op stop timeout="60" interval="0" \ op monitor interval="60" timeout="60"crm(live)configure# group g-ctdb ctdb nmb smbcrm(live)configure# clone cl-ctdb g-ctdb meta interleave="true"crm(live)configure# commit

O binário /usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper na opção deconguração ctdb_recovery_lock tem os parâmetros CLUSTER_NAME CEPHX_USER

CEPH_POOL CEPHX_USER , nessa ordem.

7. Adicione um endereço IP em cluster:

crm(live)configure# primitive ip ocf:heartbeat:IPaddr2 params ip=192.168.2.1 \ unique_clone_address="true" \ op monitor interval="60" \ meta resource-stickiness="0"crm(live)configure# clone cl-ip ip \ meta interleave="true" clone-node-max="2" globally-unique="true"crm(live)configure# colocation col-with-ctdb 0: cl-ip cl-ctdbcrm(live)configure# order o-with-ctdb 0: cl-ip cl-ctdbcrm(live)configure# commit

Se unique_clone_address for denido como true , o agente de recurso IPaddr2adicionará um ID de clone ao endereço especicado, resultando em três endereços IPdiferentes. Geralmente, eles não são necessários, mas ajudam no equilíbrio de carga. Paraobter mais informações sobre este tópico, consulte https://www.suse.com/documentation/

sle-ha-12/book_sleha/data/cha_ha_lb.html .

8. Verique o resultado:

root@earth # crm statusClone Set: base-clone [dlm] Started: [ factory-1 ] Stopped: [ factory-0 ] Clone Set: cl-ctdb [g-ctdb] Started: [ factory-1 ] Started: [ factory-0 ] Clone Set: cl-ip [ip] (unique) ip:0 (ocf:heartbeat:IPaddr2): Started factory-0 ip:1 (ocf:heartbeat:IPaddr2): Started factory-1

129 Configuração de alta disponibilidade SES 5

9. Faça o teste de uma máquina cliente. Em um cliente Linux, execute o seguinte comandopara ver se você pode copiar arquivos do sistema e para o sistema:

root # smbclient //192.168.2.1/myshare

130 Configuração de alta disponibilidade SES 5

A Atualizações da documentação

Este capítulo lista as mudanças no conteúdo deste documento desde o lançamento inicial doSUSE Enterprise Storage 4. Você pode encontrar modicações relacionadas à implantação docluster que se apliquem a versões anteriores em https://www.suse.com/documentation/ses-4/

book_storage_admin/data/ap_adm_docupdate.html .

O documento foi atualizado nas seguintes datas:

Seção A.1, “Outubro de 2018 (Lançamento do SUSE Enterprise Storage 5.5)”

Seção A.2, “Novembro de 2017 (atualização de manutenção)”

Seção A.3, “Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5)”

A.1 Outubro de 2018 (Lançamento do SUSEEnterprise Storage 5.5)Atualizações gerais

Capítulo  3, Configuração de alta disponibilidade do nó de admin do Ceph adicionado(Fate#325622).

OSDs criptografados durante a implantação e o upgrade na Seção 4.5.1.5, “Implantando

OSDs criptografados” e na Seção  5.3, “Criptografando OSDs durante o upgrade” (Fate#321665).

Correções de bug

Pools do Object Gateway sem dados precisam ser replicados na Seção 9.1.1.2, “Criar

pools (opcional)” (https://bugzilla.suse.com/show_bug.cgi?id=1095743 ).

FQDN de todos os nós deve ser resolvido para o IP de rede pública.Consulte a Seção 4.3, “Implantação do cluster” (https://bugzilla.suse.com/show_bug.cgi?

id=1067113 ).

Dica adicionada sobre como compartilhar várias funções no Capítulo 4, Implantando

com o DeepSea/Salt (https://bugzilla.suse.com/show_bug.cgi?id=1093824 ).

Adicionada a Seção  2.4, “Nós do servidor de metadados” (https://bugzilla.suse.com/

show_bug.cgi?id=1047230 ).

131 Outubro de 2018 (Lançamento do SUSE Enterprise Storage 5.5) SES 5

Edição manual de policy.cfg para openATTIC (https://bugzilla.suse.com/

show_bug.cgi?id=1073331 ).

/var/lib/ceph recomendado na SSD na Seção  2.2, “Nós do monitor” (https://

bugzilla.suse.com/show_bug.cgi?id=1056322 ).

Seção 1.4, “BlueStore” e Seção 2.1.3, “Tamanho recomendado para o dispositivo WAL e BD do

BlueStore” adicionadas (https://bugzilla.suse.com/show_bug.cgi?id=1072502 ).

Estendida a implantação de OSDs criptografados na Seção 4.5.1.5, “Implantando OSDs

criptografados” (https://bugzilla.suse.com/show_bug.cgi?id=1093003 ).

Aumento do número de bytes para apagar para 4 milhões na Etapa 13 (https://

bugzilla.suse.com/show_bug.cgi?id=1093331 ).

Firewall separa as fases do DeepSea, na Seção 4.3, “Implantação do cluster” (https://

bugzilla.suse.com/show_bug.cgi?id=1090683 ).

Adicionada a lista de repositórios na Seção  4.3, “Implantação do cluster” (https://

bugzilla.suse.com/show_bug.cgi?id=1088170 ).

Instruções incluídas para adicionar manualmente os repositórios usando o zypperSeção  5.4, “Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5”,Seção 5.5, “Upgrade do SUSE Enterprise Storage 4 (implantação do ceph-deploy) para 5” eSeção 5.6, “Upgrade do SUSE Enterprise Storage 4 (implantação do Crowbar) para 5” (https://

bugzilla.suse.com/show_bug.cgi?id=1073308 ).

Adicionada uma lista de repositórios de upgrade + breve explicação daopção upgrade_init do DeepSea na Seção  5.4, “Upgrade do SUSE Enterprise

Storage 4 (implantação do DeepSea) para 5” (https://bugzilla.suse.com/show_bug.cgi?

id=1073372 ).

Adicionada a Seção 7.1.5, “Desabilitando atualizações e reinicializações durante a fase 0”

(https://bugzilla.suse.com/show_bug.cgi?id=1081524 ).

Prompts corrigidos no Procedimento 5.2, “Etapas para aplicar ao nó master Salt” (https://

bugzilla.suse.com/show_bug.cgi?id=1084307 ).

Adicionada a Seção 2.12, “SUSE Enterprise Storage e outros produtos da SUSE” (https://

bugzilla.suse.com/show_bug.cgi?id=1089717 ).

132 Outubro de 2018 (Lançamento do SUSE Enterprise Storage 5.5) SES 5

Uma nota foi adicionada sobre as seções de conguração do Object Gateway no Livro

“Guia de Administração”, Capítulo 1 “Administração do cluster do Salt”, Seção 1.11 “Arquivo

ceph.conf personalizado” (https://bugzilla.suse.com/show_bug.cgi?id=1089300 ).

Trechos do WAL/BD adicionados à Seção 2.1.2, “Tamanho mínimo do disco” (https://

bugzilla.suse.com/show_bug.cgi?id=1057797 ).

Os endereços públicos dos MONs são calculados dinamicamente (https://

bugzilla.suse.com/show_bug.cgi?id=1089151 ).

Local corrigido dos chaveiros na Seção  5.5, “Upgrade do SUSE Enterprise Storage

4 (implantação do ceph-deploy) para 5” (https://bugzilla.suse.com/show_bug.cgi?

id=1073368 ).

Vários trechos de ajudantes fornecidos na Seção 4.5.1.2, “Atribuição de função” (https://

bugzilla.suse.com/show_bug.cgi?id=1061629 ).

Importação do ceph.conf personalizado no Procedimento 5.2, “Etapas para aplicar ao

nó master Salt” (https://bugzilla.suse.com/show_bug.cgi?id=1085443 ).

Valor de RAM atualizado recomendado para implantação do BlueStore na Seção 2.1.1,

“Requisitos mínimos” (https://bugzilla.suse.com/show_bug.cgi?id=1076385) ).

Etapas manuais adicionadas para fazer upgrade dos iSCSI Gateways após o comandode importação na Seção 5.5, “Upgrade do SUSE Enterprise Storage 4 (implantação do ceph-deploy) para 5” e na Seção 5.6, “Upgrade do SUSE Enterprise Storage 4 (implantação do

Crowbar) para 5” (https://bugzilla.suse.com/show_bug.cgi?id=1073327) ).

Implantação do iSCSI Gateway atualizada no modo do DeepSea na Seção  10.4,

“Instalação e configuração” (https://bugzilla.suse.com/show_bug.cgi?id=1073327 ).

As cotas do CephFS não são suportadas. Consulte a Seção 11.1, “Cenários e diretrizes

suportados do CephFS” (https://bugzilla.suse.com/show_bug.cgi?id=1077269 ).

Incluir partições com números mais altos do que 9 na etapa de anulação. Consulte aEtapa 13. (https://bugzilla.suse.com/show_bug.cgi?id=1050230 ).

133 Outubro de 2018 (Lançamento do SUSE Enterprise Storage 5.5) SES 5

A.2 Novembro de 2017 (atualização de manutenção)

Atualizações gerais

Seção  11.3.2, “Tamanho do cluster MDS” e·Seção  11.3.3, “Cluster e atualizações do MDS”

adicionadas.

Correções de bug

Estratégia de limpeza de disco aprimorada na Etapa 13 da Seção 4.3, “Implantação do

cluster” (https://bugzilla.suse.com/show_bug.cgi?id=1073897 ).

Dica adicionada sobre como desativar medidas de segurança na Seção 5.4.1, “Migração

do OSD para BlueStore” (https://bugzilla.suse.com/show_bug.cgi?id=1073720 ).

Referência feita à Seção 4.2.2.1, “Correspondendo o nome do minion” no Procedimento 4.1,

“Executando as fases de implantação” e no Livro “Guia de Administração”, Capítulo

1 “Administração do cluster do Salt”, Seção 1.1 “Adicionando novos nós do cluster”

para unicar a fonte de informações (https://bugzilla.suse.com/show_bug.cgi?

id=1073374 ).

Na Seção 5.2, “Procedimento geral de upgrade”, apenas atualize o master e minion Salt enão todos os pacotes. Portanto, substitua salt target state.apply ceph.updatespor salt target state.apply ceph.updates.salt (https://bugzilla.suse.com/

show_bug.cgi?id=1073373 ).

Seção  5.6, “Upgrade do SUSE Enterprise Storage 4 (implantação do Crowbar)

para 5” adicionada (https://bugzilla.suse.com/show_bug.cgi?id=1073317 e https://

bugzilla.suse.com/show_bug.cgi?id=1073701 ).

“*” substituído por destino e introdução ao direcionamento complementadana Seção  4.2.2, “Direcionando os minions” (https://bugzilla.suse.com/show_bug.cgi?

id=1068956 ).

Vericação adicionada das impressões digitais dos minions Salt na Seção  4.3,

“Implantação do cluster” (https://bugzilla.suse.com/show_bug.cgi?id=1064045 ).

Aviso removido para copiar o arquivo refactor.conf de exemplo do Livro “Guia

de Administração”, Capítulo 1 “Administração do cluster do Salt”, Seção 1.8 “Instalação

automatizada pelo Salt” (https://bugzilla.suse.com/show_bug.cgi?id=1065926 ).

134 Novembro de 2017 (atualização de manutenção) SES 5

Caminho corrigido para o arquivo YAML de conguração de rede noProcedimento  4.1, “Executando as fases de implantação” (https://bugzilla.suse.com/

show_bug.cgi?id=1067730 ).

Vericar o layout do cluster no Procedimento 5.2, “Etapas para aplicar ao nó master Salt”

(https://bugzilla.suse.com/show_bug.cgi?id=1067189 ).

ceph osd set sortbitwise adicionado à Seção 5.4, “Upgrade do SUSE Enterprise

Storage 4 (implantação do DeepSea) para 5” e ao Procedimento 5.2, “Etapas para aplicar ao

nó master Salt” (https://bugzilla.suse.com/show_bug.cgi?id=1067146 ).

osd crush location está obsoleto. ceph.conf foi personalizado de mododiferente em Importante: Requisitos de software (https://bugzilla.suse.com/show_bug.cgi?

id=1067381 ).

“role-admin” corrigido de “role-master” na Seção 4.5.1.2, “Atribuição de função” (https://

bugzilla.suse.com/show_bug.cgi?id=1064056 ).

Caminho corrigido para cluster.yml no Procedimento 4.1, “Executando as fases de

implantação” (https://bugzilla.suse.com/show_bug.cgi?id=1066711 ).

Adicionada a Seção 12.3.4, “HA do NFS Ganesha e DeepSea” (https://bugzilla.suse.com/

show_bug.cgi?id=1058313 ).

Seção  2.7.2, “Nós do monitor em sub-redes diferentes” readicionada (https://

bugzilla.suse.com/show_bug.cgi?id=1050115 ).

O arquivo deepsea_minions.sls deve conter apenas uma entradadeepsea_minions . Consulte o Procedimento 4.1, “Executando as fases de implantação”.(https://bugzilla.suse.com/show_bug.cgi?id=1065403 )

Ordem das etapas mudada no primeiro procedimento da Seção 4.3, “Implantação do

cluster”. (https://bugzilla.suse.com/show_bug.cgi?id=1064770 )

A Seção  5.4.1, “Migração do OSD para BlueStore” foi esclarecida. (https://

bugzilla.suse.com/show_bug.cgi?id=1063250 )

A.3 Outubro de 2017 (Lançamento do SUSEEnterprise Storage 5)Atualizações gerais

135 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) SES 5

Seção 5.7, “Upgrade do SUSE Enterprise Storage 3 para 5” adicionada (Fate#323072).

A ferramenta de instalação Crowbar obsoleta foi substituída pelo DeepSea.

A ferramenta ceph-deploy obsoleta foi substituída pelo DeepSea.

Capítulo  2, Requisitos e recomendações de hardware atualizado(https://bugzilla.suse.com/show_bug.cgi?id=1029544 e https://bugzilla.suse.com/

show_bug.cgi?id=1042283 ).

Capítulo  12, Instalação do NFS Ganesha atualizado (https://bugzilla.suse.com/

show_bug.cgi?id=1036495 , https://bugzilla.suse.com/show_bug.cgi?id=1031444 ,FATE#322464).

Esquema de nomeação de pers do DeepSea mudado. Consulte a Seção  4.5.1.4,

“Atribuição de perfil” (https://bugzilla.suse.com/show_bug.cgi?id=1046108 ).

É possível usar o CephFS em pools EC. Consulte a Seção 11.3.1, “Criando o CephFS”

(FATE #321617).

Correções de bug

Adicionada a Seção 10.5, “Exportando imagens de dispositivo de blocos RADOS por meio do

tcmu-runner” (https://bugzilla.suse.com/show_bug.cgi?id=1064467 ).

O procedimento de upgrade foi aprimorado para incluir a função do openATTIC naSeção 5.4, “Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5” (https://

bugzilla.suse.com/show_bug.cgi?id=1064621 ).

Uma referência foi adicionada ao Procedimento 4.1, “Executando as fases de implantação”

na Etapa 4 (https://bugzilla.suse.com/show_bug.cgi?id=1064276 ).

O procedimento de upgrade foi modicado no Procedimento 5.2, “Etapas para aplicar

ao nó master Salt” (https://bugzilla.suse.com/show_bug.cgi?id=1061608 e https://

bugzilla.suse.com/show_bug.cgi?id=1048959 ).

rgw.conf adicionado no Livro “Guia de Administração”, Capítulo 1 “Administração do

cluster do Salt”, Seção 1.11 “Arquivo ceph.conf personalizado” (https://bugzilla.suse.com/

show_bug.cgi?id=1062109 ).

Instalação do DeepSea transferida quase para o nal da Seção 4.3, “Implantação do

cluster” (https://bugzilla.suse.com/show_bug.cgi?id=1056292 ).

136 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) SES 5

Adicionada a Seção  4.5.1.5, “Implantando OSDs criptografados” (https://

bugzilla.suse.com/show_bug.cgi?id=1061751 ).

O procedimento de upgrade foi atualizado e simplicado na Seção 5.4, “Upgrade do

SUSE Enterprise Storage 4 (implantação do DeepSea) para 5” (https://bugzilla.suse.com/

show_bug.cgi?id=1059362 ).

Vericar versão do DeepSea antes do upgrade em Importante: Requisitos de software

(https://bugzilla.suse.com/show_bug.cgi?id=1059331 ).

Prexo dos arquivos .sls personalizados com custom- na Seção  7.1, “Usando

arquivos de configuração personalizados” (https://bugzilla.suse.com/show_bug.cgi?

id=1048568 ).

Nota adicionada sobre incompatibilidade de recursos de chave na Seção 5.4, “Upgrade

do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5” (https://bugzilla.suse.com/

show_bug.cgi?id=1054186 ).

Fusão de itens de lista redundantes na Seção  4.3, “Implantação do cluster” (https://

bugzilla.suse.com/show_bug.cgi?id=1055140 ).

Nota adicionada sobre o longo tempo que pode levar para fazer upgrade do cluster naSeção 5.4, “Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5” (https://

bugzilla.suse.com/show_bug.cgi?id=1054079 ).

Direcionamento de minions Salt com deepsea_minions: é obrigatório (https://

bugzilla.suse.com/show_bug.cgi?id=1054229 ).

Fase 1 inserida após importação no Procedimento 5.2, “Etapas para aplicar ao nó master

Salt” (https://bugzilla.suse.com/show_bug.cgi?id=1054155 ).

Adicionado o Livro “Guia de Administração”, Capítulo 1 “Administração do cluster do Salt”,

Seção 1.11 “Arquivo ceph.conf personalizado” (https://bugzilla.suse.com/show_bug.cgi?

id=1052806 ).

Etapas ausentes adicionadas à Seção  5.4, “Upgrade do SUSE Enterprise

Storage 4 (implantação do DeepSea) para 5” (https://bugzilla.suse.com/show_bug.cgi?

id=1052597 ).

Sintaxe do comando radosgw-admin corrigida na Seção 12.2, “Exemplo de instalação”

(https://bugzilla.suse.com/show_bug.cgi?id=1052698 ).

137 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) SES 5

“Salt” não é o nome de host obrigatório do master Salt durante o upgrade noProcedimento 5.1, “Etapas para aplicar a todos os nós do cluster (incluindo o nó Calamari)”

(https://bugzilla.suse.com/show_bug.cgi?id=1052907 ).

Melhoria no uxo do texto e nas palavras da seção “importante” da Seção 5.4, “Upgrade

do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5” (https://bugzilla.suse.com/

show_bug.cgi?id=1052147 ).

Nota adicionada sobre atribuição de função manual durante a importação noProcedimento  5.2, “Etapas para aplicar ao nó master Salt” (https://bugzilla.suse.com/

show_bug.cgi?id=1050554 ).

Adicionada a Seção 5.4.1, “Migração do OSD para BlueStore” (https://bugzilla.suse.com/

show_bug.cgi?id=1052210 ).

salt-run populate.engulf_existing_cluster explicado em detalhes noProcedimento  5.2, “Etapas para aplicar ao nó master Salt” (https://bugzilla.suse.com/

show_bug.cgi?id=1051258 ).

Função do openATTIC adicionada na Seção 4.5.1.7, “Arquivo policy.cfg de exemplo”

(https://bugzilla.suse.com/show_bug.cgi?id=1052076 ).

Caminhos de profile-default corrigidos na Seção 4.5.1.7, “Arquivo policy.cfg de

exemplo” (https://bugzilla.suse.com/show_bug.cgi?id=1051760 ).

Seção anterior separada no novo Capítulo  7, Personalizando a configuração padrão

(https://bugzilla.suse.com/show_bug.cgi?id=1050238 ).

Referência à Seção 1.2.3, “Nós e daemons do Ceph” de Descrição das fases do DeepSea paramanter a lista de serviços do Ceph atualizada (https://bugzilla.suse.com/show_bug.cgi?

id=1050221 ).

Descrição e texto do master Salt aprimorados no Capítulo 4, Implantando com o DeepSea/

Salt (https://bugzilla.suse.com/show_bug.cgi?id=1050214 ).

Descrição das funções opcionais do nó adicionada à Seção 1.2.3, “Nós e daemons do

Ceph” (https://bugzilla.suse.com/show_bug.cgi?id=1050085 ).

O procedimento de upgrade foi atualizado no geral (https://bugzilla.suse.com/

show_bug.cgi?id=1048436 , https://bugzilla.suse.com/show_bug.cgi?id=1048959 ehttps://bugzilla.suse.com/show_bug.cgi?id=104i7085 ).

138 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) SES 5

Uma nova função do DeepSea foi adicionada: Ceph Manager (https://

bugzilla.suse.com/show_bug.cgi?id=1047472 ).

Adicionada a Seção 5.5, “Upgrade do SUSE Enterprise Storage 4 (implantação do ceph-deploy) para 5” (https://bugzilla.suse.com/show_bug.cgi?id=1048436 ).

A Fase 0 tornou-se totalmente opcional em Descrição das fases do DeepSea (https://

bugzilla.suse.com/show_bug.cgi?id=1045845 ).

Atualização da lista de pools padrão na Seção 9.1.1, “Configuração do Object Gateway”

(https://bugzilla.suse.com/show_bug.cgi?id=1034039 ).

Adicionado um trecho “importante” sobre a implantação do Object Gatewayagora pelo DeepSea ao Capítulo  9, Ceph Object Gateway (https://bugzilla.suse.com/

show_bug.cgi?id=1044928 ).

Script de shell corrigido na Seção  4.3, “Implantação do cluster” (https://

bugzilla.suse.com/show_bug.cgi?id=1044684 ).

"Denir ag require-osd-release luminous ” adicionado àSeção  5.2, “Procedimento geral de upgrade” (https://bugzilla.suse.com/show_bug.cgi?

id=1040750 ).

Anotação adicionada ao policy.cfg de exemplo na Seção  4.5.1.7, “Arquivo

policy.cfg de exemplo” (https://bugzilla.suse.com/show_bug.cgi?id=1042691 ).

Comandos aprimorados para limpeza (zap) de disco OSD na Seção 4.3, “Implantação

do cluster” (https://bugzilla.suse.com/show_bug.cgi?id=1042074 ).

Aviso removido para instalar o salt-minion no master Salt na Seção 4.3, “Implantação

do cluster” (https://bugzilla.suse.com/show_bug.cgi?id=1041590 ).

Desabilitar o AppArmor na Seção 4.3, “Implantação do cluster” e na Seção 5.4, “Upgrade

do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5” (https://bugzilla.suse.com/

show_bug.cgi?id=1039852 ).

Recomendação de rewall adicionada à Seção 4.3, “Implantação do cluster” (https://

bugzilla.suse.com/show_bug.cgi?id=1039344 ).

Referências de XML-RPC removidas das linhas de comando systemd doopenATTIC na Seção  7.1, “Usando arquivos de configuração personalizados” (https://

bugzilla.suse.com/show_bug.cgi?id=1037371 ).

139 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) SES 5

Sintaxe de YAML corrigida na Seção  4.3, “Implantação do cluster” (https://

bugzilla.suse.com/show_bug.cgi?id=1035498 ).

Adicionada a explicação da função “ganesha” à Seção 4.5.1.2, “Atribuição de função”

(https://bugzilla.suse.com/show_bug.cgi?id=1037365 ).

Fluxo do texto esclarecido e aprimorado na Seção 4.5.1, “Arquivo policy.cfg” (https://

bugzilla.suse.com/show_bug.cgi?id=1037360 ).

Adicionado o procedimento de upgrade do SUSE Enterprise Storage 4 para 5 naSeção 5.4, “Upgrade do SUSE Enterprise Storage 4 (implantação do DeepSea) para 5” (https://

bugzilla.suse.com/show_bug.cgi?id=1036266 ).

O termo “aprovisionamento” foi substituído por “preparação” na Seção  4.3,

“Implantação do cluster” (https://bugzilla.suse.com/show_bug.cgi?id=1036400 ehttps://bugzilla.suse.com/show_bug.cgi?id=1036492 ).

Aviso adicionado sobre técnicas avançadas à Seção 4.5.1.6, “Filtragem de itens” (https://

bugzilla.suse.com/show_bug.cgi?id=1036278 ).

Atribuição de role-admin redundante substituída na Seção  4.5.1.7, “Arquivo

policy.cfg de exemplo” (https://bugzilla.suse.com/show_bug.cgi?id=1036506 ).

Descrição das fases do DeepSea e Seção 4.3, “Implantação do cluster” aprimoradas (https://

bugzilla.suse.com/show_bug.cgi?id=1036278 ).

Foram adicionadas modicações nas etapas de implantação à Seção  7.1, “Usando

arquivos de configuração personalizados” (https://bugzilla.suse.com/show_bug.cgi?

id=1026782 ).

O Capítulo 4, Implantando com o DeepSea/Salt foi esclarecido e aprimorado conformesugerido (https://bugzilla.suse.com/show_bug.cgi?id=1020920 ).

Habilitação recomendada de serviços personalizados do openATTIC naSeção 7.1, “Usando arquivos de configuração personalizados” (https://bugzilla.suse.com/

show_bug.cgi?id=989349 ).

Recomendações de rede transferidas para o Capítulo 2, Requisitos e recomendações de

hardware, e a Seção 2.7.1, “Adicionando uma rede privada a um cluster em execução” foiincluída (https://bugzilla.suse.com/show_bug.cgi?id=1026569 ).

140 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) SES 5