Guia de Administração

SUSE Enterprise Storage 5

Guia de Administraçã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 xiv

I GERENCIAMENTO DE CLUSTER 1

1 Administração do cluster do Salt 21.1 Adicionando novos nós do cluster 2

1.2 Adicionando novas funções aos nós 3

1.3 Removendo e reinstalando nós do cluster 5

1.4 Reimplantando nós do monitor 7

1.5 Adicionar um OSD a um nó 8

1.6 Removendo um OSD 8

Removendo à força os OSDs danificados 9

1.7 Recuperando um nó OSD reinstalado 10

1.8 Instalação automatizada pelo Salt 10

1.9 Atualizando os nós do cluster 11

1.10 Parando ou reinicializando o cluster 13

1.11 Arquivo ceph.conf personalizado 14

Anulando os padrões 15 • Incluindo arquivos de configuração 15

1.12 Configuração de tempo de execução do Ceph 16

iv Guia de Administração

II OPERANDO UM CLUSTER 18

2 Introdução 19

3 Operando serviços do Ceph 20

3.1 Operando serviços do Ceph usando systemd 20

Iniciando, parando e reiniciando serviços usando destinos 20 • Iniciando,

parando e reiniciando serviços individuais 21 • Identificando serviços

individuais 21 • Status do serviço 21

3.2 Reiniciando serviços do Ceph usando DeepSea 22

Reiniciando todos os serviços 22 • Reiniciando serviços específicos 22

4 Determinando o estado do cluster 244.1 Verificando a saúde do cluster 24

4.2 Observando um cluster 33

4.3 Verificando as estatísticas de uso do cluster 35

4.4 Verificando o status do cluster 36

4.5 Verificando o status do OSD 37

4.6 Verificando se há OSDs cheios 37

4.7 Verificando o status do monitor 38

4.8 Verificando estados de grupo de posicionamento 39

4.9 Usando o soquete de admin 40

5 Autenticação com cephx 41

5.1 Arquitetura de autenticação 41

5.2 Gerenciamento de chaves 44

Informações de segundo plano 45 • Gerenciando

usuários 48 • Gerenciamento de chaveiro 52 • Uso da linha de

comando 55

v Guia de Administração

6 Gerenciamento de dados armazenados 56

6.1 Dispositivos 57

6.2 Compartimentos de memória 57

6.3 Conjuntos de regras 60

Iteração pela árvore de nós 62 • firstn e indep 64

6.4 Manipulação de mapa CRUSH 65

Editando um mapa CRUSH 66 • Adicionar/Mover um OSD 66 • Ajustar

o peso do CRUSH de um OSD 67 • Remover um OSD 67 • Mover um

compartimento de memória 68

6.5 Depuração 68

6.6 SSDs e HDDs combinadas no mesmo nó 70

7 Gerenciando pools de armazenamento 73

7.1 Associar pools a um aplicativo 74

7.2 Pools operacionais 74

Listar pools 74 • Criar um pool 75 • Definir cotas do

pool 76 • Apagar um pool 76 • Renomear um pool 77 • Mostrar

as estatísticas do pool 78 • Definir os valores do pool 78 • Obter os

valores do pool 82 • Definir o número de réplicas do objeto 82 • Obter

o número de réplicas do objeto 83 • Aumentando o número de grupos de

posicionamento 83 • Adicionando um pool 84

7.3 Migração de pool 85Migrar usando a camada de cache 85

7.4 Instantâneos de pool 87Criar um instantâneo de um pool 87 • Remover um instantâneo de um

pool 88

7.5 Compactação de dados 88

Habilitar compactação 88 • Opções de compactação de

pool 88 • Opções globais de compactação 89

vi Guia de Administração

8 Dispositivo de Blocos RADOS 92

8.1 Comandos do dispositivo de blocos 92

Criando uma imagem de dispositivo de blocos 93 • Criando

a imagem de um dispositivo de blocos em um pool com

codificação de eliminação 93 • Listando imagens de

dispositivo de blocos 94 • Recuperando informações da

imagem 94 • Redimensionando a imagem de um dispositivo de

blocos 94 • Removendo a imagem de um dispositivo de blocos 95

8.2 Montando e desmontando imagens RBD 95

8.3 Instantâneos de dispositivo de blocos 97

Notas sobre o Cephx 97 • Aspectos básicos do

instantâneo 98 • Camadas 100

8.4 rbdmap: Mapear dispositivos RBD no momento da inicialização 104

8.5 Espelhamento de dispositivo de blocos RADOS 105

Daemon rbd-mirror 106 • Configuração do pool 106 • Configuração da

imagem 108 • Status do espelho 111

9 Pools com codificação de eliminação 112

9.1 Criando um pool com codificação de eliminação de exemplo 112

9.2 Perfis de codificação de eliminação 113

9.3 Pool com codificação de eliminação e camada de cache 116

9.4 Pools com codificação de eliminação com dispositivo de blocosRADOS 116

10 Camadas de cache 118

10.1 Terminologia de armazenamento em camadas 118

10.2 Pontos a serem considerados 119

10.3 Quando usar as camadas de cache 119

10.4 Modos de cache 120

vii Guia de Administração

10.5 Conjunto de acertos 120

Visão geral 120 • Exemplos 122

10.6 Configurando um armazenamento em camadas de exemplo 123

Configurando uma camada de cache 126

III ACESSANDO OS DADOS DO CLUSTER 130

11 Ceph Object Gateway 13111.1 Restrições e limitações de nomeação do Object Gateway 131

Limitações de compartimento de memória 131 • Limitações de objetos

armazenados 131 • Limitações de cabeçalho HTTP 132

11.2 Implantando o Object Gateway 132

11.3 Operando o serviço Object Gateway 132

11.4 Parâmetros de configuração 133

Notas adicionais 134

11.5 Gerenciando o acesso ao Object Gateway 134

Acessando o Object Gateway 134 • Gerenciando contas do S3 e do

Swift 136

11.6 Habilitando HTTPS/SSL para Object Gateways 140

Criar um certificado autoassinado 140 • Configuração de HTTPS

simples 141 • Configuração de HTTPS avançada 141

11.7 Módulos de sincronização 142

Sincronizando zonas 142 • Armazenando metadados no Elasticsearch 144

11.8 Autenticação LDAP 147

Mecanismo de autenticação 147 • Requisitos 148 • Configurar o Object

Gateway para usar a autenticação LDAP 148 • Usando um filtro de pesquisa

personalizado para limitar o acesso do usuário 149 • Gerando um token de

acesso para autenticação LDAP 150

viii Guia de Administração

11.9 Fragmentação de índice do compartimento de memória 151

Refragmentação de índice do compartimento de

memória 151 • Fragmentação de índice para novos compartimentos de

memória 154

11.10 Integrando o OpenStack Keystone 156

Configurando o OpenStack 156 • Configurando o Ceph Object Gateway 157

11.11 Object Gateways multissite 159

Terminologia 160 • Configuração de cluster de exemplo 161 • Chaves

do sistema 161 • Convenções de nomeação 162 • Pools

padrão 162 • Criando um domínio 163 • Apagando o grupo de zonas

padrão 163 • Criando um grupo de zonas master 163 • Criando uma zona

master 164 • Criando uma zona secundária 168 • Adicionando o Object

Gateway ao segundo cluster 171 • Failover e recuperação de desastre 175

11.12 Equilibrando a carga dos servidores Object Gateway com HAProxy 176

12 Ceph iSCSI Gateway 178

12.1 Conectando-se aos destinos gerenciados por lrbd 178

Linux (open-iscsi) 178 • Microsoft Windows (Iniciador Microsoft

iSCSI) 182 • VMware 189

12.2 Conclusão 195

13 Sistema de arquivos em cluster 19613.1 Montando o CephFS 196

Preparação do cliente 196 • Criar um arquivo de segredo 196 • Montar o

CephFS 197

13.2 Desmontando o CephFS 198

13.3 CephFS no /etc/fstab 199

13.4 Vários daemons MDS ativos (MDS ativo-ativo) 199Quando usar MDS ativo-ativo 199 • Aumentando o tamanho do cluster

MDS ativo 199 • Diminuindo o número de classificações 200 • Fixando

manualmente árvores do diretório em uma classificação 202

ix Guia de Administração

13.5 Failover de Gerenciamento 202

Configurando daemons de standby 203 • Exemplos 204

14 NFS Ganesha: Exportar dados do Ceph pelo NFS 205

14.1 Instalação 205

14.2 Configuração 205

Seção de exportação 206 • Seção RGW 207 • Mudando as portas padrão

do NFS Ganesha 208

14.3 Funções personalizadas do NFS Ganesha 208

Usuários diferentes do Object Gateway para NFS Ganesha 208 • Separando a

FSAL do CephFS e do Object Gateway 210

14.4 Iniciando ou reiniciando o NFS Ganesha 211

14.5 Definindo o nível de registro 212

14.6 Verificando o compartilhamento NFS exportado 212

14.7 Montando o compartilhamento NFS exportado 212

14.8 Recursos adicionais 213

IV GERENCIANDO O CLUSTER COM FERRAMENTAS DE GUI 214

15 openATTIC 21515.1 Implantação e configuração do openATTIC 215

Habilitando acesso seguro ao openATTIC por SSL 215 • Implantando o

openATTIC 216 • Configuração inicial do openATTIC 217 • Integração

do DeepSea no openATTIC 217 • Gerenciamento do Object

Gateway 218 • Gerenciamento do iSCSI Gateway 218

15.2 Interface do usuário da Web do openATTIC 218

15.3 Painel 220

15.4 Tarefas relacionadas ao Ceph 222

Recursos comuns de IU da Web 222 • Listando os nós

OSD 223 • Gerenciando dispositivos de blocos RADOS

(RBDs) 223 • Gerenciando pools 227 • Listando os

x Guia de Administração

nós 229 • Gerenciando o NFS Ganesha 230 • Gerenciando iSCSI

Gateways 234 • Vendo o mapa CRUSH do cluster 236 • Gerenciando

usuários e compartimentos de memória do Object Gateway 237

V INTEGRAÇÃO COM FERRAMENTAS DE VIRTUALIZAÇÃO 245

16 Usando a libvirt com o Ceph 24616.1 Configurando o Ceph 246

16.2 Preparando o gerenciador de VM 247

16.3 Criando uma VM 248

16.4 Configurando a VM 248

16.5 Resumo 251

17 Ceph como back end para instância de KVMQEMU 252

17.1 Instalação 252

17.2 Uso 252

17.3 Criando imagens com o QEMU 253

17.4 Redimensionando imagens com o QEMU 253

17.5 Recuperando informações da imagem com o QEMU 253

17.6 Executando o QEMU com o RBD 254

17.7 Habilitando descarte/TRIM 254

17.8 Opções de cache do QEMU 255

VI PERGUNTAS FREQUENTES, DICAS E SOLUÇÃO DE PROBLEMAS 257

18 Dicas e truques 25818.1 Ajustando a depuração 258

18.2 Parando os OSDs sem redistribuição 259

xi Guia de Administração

18.3 Sincronização de horário dos nós 259

18.4 Verificando a gravação de dados sem equilíbrio 261

18.5 Subvolume Btrfs para /var/lib/ceph 262

Requisitos para nova instalação 262 • Requisitos para instalação

existente 263 • Configuração automática 263 • Configuração

manual 264

18.6 Aumentando os descritores de arquivos 264

18.7 Como usar partições existentes para OSDs incluindo diários OSD 265

18.8 Integração com software de virtualização 266

Armazenando discos da KVM no cluster do Ceph 266 • Armazenando discos

da libvirt no cluster do Ceph 266 • Armazenando discos do Xen no cluster

do Ceph 266

18.9 Configurações de firewall para o Ceph 268

18.10 Testando o desempenho da rede 269

18.11 Substituindo o disco de armazenamento 270

19 Perguntas frequentes (FAQ) 27119.1 Como o número de grupos de posicionamento afeta o desempenho do

cluster? 271

19.2 Posso usar SSDs e discos rígidos no mesmo cluster? 271

19.3 Quais são as compensações de usar um diário na SSD? 272

19.4 O que acontece quando há falha em um disco? 273

19.5 O que acontece quando há falha em um disco de diário? 273

20 Solução de problemas 274

20.1 Relatando problemas de software 274

20.2 Falha ao enviar objetos grandes pelo rados com OSD completo 274

20.3 Sistema de arquivos XFS corrompido 275

xii Guia de Administração

20.4 Mensagem de status “Too Many PGs per OSD” 275

20.5 Mensagem de status “nn pg stuck inactive” 276

20.6 Peso do OSD é 0 277

20.7 OSD está inativo 277

20.8 Descobrindo OSDs lentos 278

20.9 Corrigindo avisos de diferença do relógio 278

20.10 Cluster de baixo desempenho causado por problemas de rede 279

20.11 Pouco espaço em /var 281

Glossário 283

A Exemplo do procedimento de instalação manual doCeph 285

B Atualizações da documentação 289

B.1 Setembro de 2018 (Lançamento do SUSE Enterprise Storage 5.5) 289

B.2 Novembro de 2017 (atualização de manutenção dadocumentação) 292

B.3 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) 292

B.4 Fevereiro de 2017 (Lançamento do SUSE Enterprise Storage 4,atualização de manutenção 1) 298

B.5 Dezembro de 2016 (Lançamento do SUSE Enterprise Storage 4) 299

B.6 Junho de 2016 (Lançamento do SUSE Enterprise Storage 3) 300

B.7 Janeiro de 2016 (Lançamento do SUSE Enterprise Storage 2.1) 303

B.8 Outubro de 2015 (Lançamento do SUSE Enterprise Storage 2) 304

xiii Guia de Administraçã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:

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.

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

xiv 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

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

xvi Sobre este manual SES 5

I Gerenciamento de Cluster

1 Administração do cluster do Salt 2

1 Administração do cluster do Salt

Após implantar o cluster do Ceph, provavelmente você precisará fazer várias modicações nelede vez em quando. Dentre elas, adicionar ou remover novos nós, discos ou serviços. Este capítulodescreve como você pode realizar essas tarefas de administração.

1.1 Adicionando novos nós do cluster

O procedimento de adição de novos nós ao cluster é quase idêntico à implantação de nó docluster inicial descrita no Livro “Guia de Implantação”, Capítulo 4 “Implantando com o DeepSea/Salt”:

1. Instale o SUSE Linux Enterprise Server 12 SP3 no novo nó, dena a conguração de redepara que ela resolva o nome de host do master Salt corretamente e instale o pacote salt-minion :

root@minion > zypper in salt-minion

Se o nome de host do master Salt não for salt , edite /etc/salt/minion e adicione oseguinte:

master: DNS_name_of_your_salt_master

Se você efetuou quaisquer mudanças nos arquivos de conguração mencionados acima,reinicie o serviço salt.minion :

root@minion > systemctl restart salt-minion.service

2. Aceite todas as chaves do Salt no master Salt:

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

3. Verique se o /srv/pillar/ceph/deepsea_minions.sls também está direcionado parao novo minion Salt. Consulte o Livro “Guia de Implantação”, Capítulo 4 “Implantando com o

DeepSea/Salt”, Seção 4.2.2.1 “Correspondendo o nome do minion” do Livro “Guia de Implantação”,

Capítulo 4 “Implantando com o DeepSea/Salt”, Seção 4.3 “Implantação do cluster”, Executando as

fases de implantação para obter mais detalhes.

2 Adicionando novos nós do cluster SES 5

4. Execute a fase de preparação. Ela sincroniza os módulos e grains para que o novo minionpossa fornecer todas as informações esperadas pelo DeepSea:

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

5. Execute a fase de descoberta. Ela gravará novas entradas de arquivo no diretório /srv/pillar/ceph/proposals , em que você pode editar os arquivos .yml relevantes:

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

6. Se preferir, mude o /srv/pillar/ceph/proposals/policy.cfg se o host recém-adicionado não corresponder ao esquema de nomeação existente. Para obter informaçõesdetalhadas, consulte o Livro “Guia de Implantação”, Capítulo 4 “Implantando com o DeepSea/

Salt”, Seção 4.5.1 “Arquivo policy.cfg”.

7. Execute a fase de conguração. Ela lê tudo o que está em /srv/pillar/ceph e atualizao pillar de acordo:

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

O pillar armazena dados que você pode acessar com o seguinte comando:

root@master # salt target pillar.items

8. As fases de conguração e implantação incluem os nós recém-adicionados:

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

1.2 Adicionando novas funções aos nós

Você pode implantar com o DeepSea todos os tipos de funções suportadas. Consulte o Livro “Guia

de Implantação”, Capítulo 4 “Implantando com o DeepSea/Salt”, Seção 4.5.1.2 “Atribuição de função”

para obter mais informações sobre os tipos de função suportados e ver exemplos de comocorrespondê-los.

3 Adicionando novas funções aos nós SES 5

Dica: Fases e funções obrigatórias e opcionaisEm geral, é recomendável executar a implantação completa de todas as Fases de 0 a 5para adicionar uma nova função ao nó do cluster. Para economizar algum tempo, vocêpode ignorar as Fases 3 ou 4, dependendo do tipo de função que você pretende implantar.Enquanto as funções OSD e MON incluem os serviços básicos e são exigidas pelo Ceph,outras funções, como Object Gateway, são opcionais. As fases de implantação do DeepSeasão hierárquicas: a Fase 3 implanta os serviços básicos e a Fase 4 implanta os opcionais.

Portanto, você precisa executar a Fase 3 ao implantar as funções básicas, como MON, emum nó OSD existente e pode ignorar a Fase 4.

Da mesma forma, você pode ignorar a Fase 3 ao implantar os serviços opcionais, comoObject Gateway, mas precisa executar a Fase 4 neste caso.

Para adicionar um novo serviço a um nó existente, siga estas etapas:

1. Adapte o /srv/pillar/ceph/proposals/policy.cfg para corresponder o hostexistente a uma nova função. Para obter mais detalhes, consulte o Livro “Guia de

Implantação”, Capítulo 4 “Implantando com o DeepSea/Salt”, Seção 4.5.1 “Arquivo policy.cfg”.Por exemplo, se você precisa executar um Object Gateway em um nó MON, a linha ésemelhante a:

role-rgw/xx/x/example.mon-1.sls

2. Execute a Fase 2 para atualizar o pilar:

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

3. Execute a Fase 3 para implantar os serviços básicos, ou a Fase 4 para implantar os serviçosopcionais. Não há nenhum problema em executar as duas fases.

DicaAo adicionar um OSD ao cluster existente, lembre-se de que o cluster será redistribuídoapós algum tempo. Para minimizar os períodos de redistribuição, recomendamosadicionar ao mesmo tempo todos os OSDs desejados.

4 Adicionando novas funções aos nós SES 5

1.3 Removendo e reinstalando nós do clusterPara remover uma função de um cluster, edite o /srv/pillar/ceph/proposals/policy.cfge remova a(s) linha(s) correspondente(s). Em seguida, execute as Fases 2 e 5 conforme descritono Livro “Guia de Implantação”, Capítulo 4 “Implantando com o DeepSea/Salt”, Seção 4.3 “Implantação

do cluster”.

Nota: Removendo OSDs do clusterSe for necessário remover determinado nó OSD do cluster, verique se o cluster tem maisespaço livre em disco do que o disco que você pretende remover. A remoção de um OSDprovoca a redistribuição do cluster inteiro.

Quando uma função é removida de um minion, o objetivo é desfazer todas as modicaçõesrelacionadas a essa função. Para a maioria das funções, a tarefa é simples, mas pode haverproblemas com as dependências de pacotes. Se um pacote for desinstalado, suas dependênciasnão serão.

Os OSDs removidos aparecem como unidades em branco. As tarefas relacionadas sobregravam oinício dos sistemas de arquivos, removem as partições de backup e limpam as tabelas de partição.

Nota: Preservando as partições criadas por outros métodosAs unidades de disco já conguradas por outros métodos, como ceph-deploy , aindapodem conter partições. O DeepSea não as eliminará automaticamente. O administradordeve reaproveitar essas unidades.

EXEMPLO 1.1: REMOVENDO UM MINION SALT DO CLUSTER

Se os nomes dos minions de armazenamento forem, por exemplo, “data1.ceph”,“data2.ceph”, etc., o “data6.ceph” e as linhas relacionadas no policy.cfg serãosemelhantes ao seguinte:

[...]# Hardware Profileprofile-default/cluster/data*.slsprofile-default/stack/default/ceph/minions/data*.yml[...]

Portanto, para remover o minion Salt “data2.ceph”, mude as linhas para o seguinte:

[...]

5 Removendo e reinstalando nós do cluster SES 5

# Hardware Profileprofile-default/cluster/data[1,3-6]*.slsprofile-default/stack/default/ceph/minions/data[1,3-6]*.yml[...]

Em seguida, execute as Fases 2 e 5:

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

EXEMPLO 1.2: MIGRANDO NÓS

Considere a seguinte situação: durante a nova instalação do cluster, você (o administrador)alocou um dos nós de armazenamento como Object Gateway independente enquantoaguardava a chegada do hardware do gateway. Agora, o hardware permanente do gatewaychegou e você pode nalmente atribuir a função desejada ao nó de armazenamento debackup e remover a função do gateway.

Depois de executar as Fases 0 e 1 (consulte o Livro “Guia de Implantação”, Capítulo 4

“Implantando com o DeepSea/Salt”, Seção 4.3 “Implantação do cluster”, Executando as fases de

implantação) para o novo hardware, você denominou o novo gateway rgw1 . Se o nó data8precisar que a função Object Gateway seja removida e que a função de armazenamentoseja adicionada, o policy.cfg atual terá esta aparência:

# Hardware Profileprofile-default/cluster/data[1-7]*.slsprofile-default/stack/default/ceph/minions/data[1-7]*.sls

# Rolesrole-rgw/cluster/data8*.sls

Portanto, faça uma mudança para:

# Hardware Profileprofile-default/cluster/data[1-8]*.slsprofile-default/stack/default/ceph/minions/data[1-8]*.sls

# Rolesrole-rgw/cluster/rgw1*.sls

Execute as Fases de 2 a 5. A Fase 3 adicionará o data8 como nó de armazenamento. Poralgum tempo, o data8 terá as duas funções. A Fase 4 adicionará a função Object Gatewayao rgw1 , e a Fase 5 removerá a função Object Gateway do data8 .

6 Removendo e reinstalando nós do cluster SES 5

1.4 Reimplantando nós do monitorQuando há falha em um ou mais nós do monitor e eles não respondem, você precisa removeros monitores com falha do cluster e, possivelmente, readicioná-los ao cluster.

Importante: O mínimo são três nós do monitorO número de nós do monitor não deve ser menor do que três. Se houver falha em umnó do monitor e, por esse motivo, o cluster car apenas com um ou dois nós, vocêprecisará atribuir temporariamente a função do monitor a outros nós do cluster antes dereimplantar os nós com falha do monitor. Após reimplantar os nós com falha do monitor,você poderá desinstalar as funções temporárias do monitor.

Para obter mais informações sobre como adicionar novos nós/funções ao cluster do Ceph,consulte a Seção  1.1, “Adicionando novos nós do cluster” e a Seção  1.2, “Adicionando novas

funções aos nós”.

Para obter mais informações sobre como remover nós do cluster, consulte a Seção 1.3,

“Removendo e reinstalando nós do cluster”.

Há dois graus básicos de falha no nó do Ceph:

O host do minion Salt está danicado sicamente ou no nível do OS e não responde àchamada salt “nome_do_minion” test.ping . Nesse caso, você precisa reimplantaro servidor por completo seguindo as instruções relevantes no Livro “Guia de Implantação”,

Capítulo 4 “Implantando com o DeepSea/Salt”, Seção 4.3 “Implantação do cluster”.

Houve falha nos serviços relacionados ao monitor e eles se recusam a se recuperar, maso host responde à chamada salt “nome_do_minion” test.ping . Nesse caso, siga estasetapas:

1. Edite o /srv/pillar/ceph/proposals/policy.cfg no master Salt e remova ou atualizeas linhas correspondentes aos nós com falha do monitor para que agora eles apontem paraos nós ativos do monitor.

2. Execute as Fases de 2 a 5 do DeepSea para aplicar as mudanças:

root@master # deepsea stage run ceph.stage.2root@master # deepsea stage run ceph.stage.3root@master # deepsea stage run ceph.stage.4root@master # deepsea stage run ceph.stage.5

7 Reimplantando nós do monitor SES 5

1.5 Adicionar um OSD a um nóPara adicionar um disco a um nó OSD existente, verique se qualquer partição no disco foiremovida e limpa. Consulte a Etapa 13 no Livro “Guia de Implantação”, Capítulo 4 “Implantando com

o DeepSea/Salt”, Seção 4.3 “Implantação do cluster” para obter mais detalhes. Depois que o discoestiver vazio, adicione-o ao arquivo YAML do nó. O caminho para o arquivo é /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/nome_do_nó.yml . Apósgravar o arquivo, execute as fases 2 e 3 do DeepSea:

root@master # deepsea stage run ceph.stage.2root@master # deepsea stage run ceph.stage.3

Dica: Perfis atualizados automaticamenteEm vez de editar manualmente o arquivo YAML, o DeepSea pode criar novos pers. Parapermitir que o DeepSea crie novos pers, os pers existentes precisam ser movidos:

root@master # old /srv/pillar/ceph/proposals/profile-default/root@master # deepsea stage run ceph.stage.1root@master # deepsea stage run ceph.stage.2root@master # deepsea stage run ceph.stage.3

1.6 Removendo um OSDVocê pode remover um Ceph OSD do cluster executando o seguinte comando:

root@master # salt-run disengage.safetyroot@master # salt-run remove.osd OSD_ID

OSD_ID precisa ser o número do OSD sem o termo osd . Por exemplo, use apenas o dígito 3de osd.3 .

Dica: Removendo vários OSDsNão é possível remover vários OSDs em paralelo com o comando salt-run remove.osd .Para automatizar a remoção de vários OSDs, você pode usar o seguinte loop (5, 21, 33,19 são os números de ID dos OSDs que serão removidos):

for i in 5 21 33 19

8 Adicionar um OSD a um nó SES 5

do echo $i salt-run disengage.safety salt-run remove.osd $idone

1.6.1 Removendo à força os OSDs danificados

Há casos em que há falha na remoção normal de um OSD (consulte a Seção 1.6, “Removendo um

OSD”). Por exemplo, isso poderá acontecer se o OSD ou o cache dele estiver danicado, quandoele é afetado por operações de E/S travadas ou quando há falha na desmontagem do disco OSD.Nesse caso, você precisa forçar a remoção do OSD:

root@master # target osd.remove OSD_ID force=True

Esse comando remove tanto a partição de dados quanto as partições de diário ou WAL/BD.

Para identicar dispositivos de diário/WAL/BD órfãos, siga estas etapas:

1. Selecione o dispositivo que pode ter partições órfãs e grave a lista de suas partições emum arquivo:

root@minion > ls /dev/sdd?* > /tmp/partitions

2. Execute readlink em todos os dispositivos block.wal, block.db e de diário e compare asaída com a lista de partições que foi gravada:

root@minion > readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \ | sort | comm -23 /tmp/partitions -

A saída é a lista de partições que não são usadas pelo Ceph.

3. Remova as partições órfãs que não pertencem ao Ceph usando o comando de suapreferência (por exemplo, fdisk , parted ou sgdisk ).

9 Removendo à força os OSDs danificados SES 5

1.7 Recuperando um nó OSD reinstalado

Se houver falha no sistema operacional que não puder ser recuperada em um dos nós OSD, sigaestas etapas para recuperá-lo e reimplantar a função OSD com os dados do cluster inalterados:

1. Reinstale o sistema operacional no nó.

2. Instale o pacote salt-minion no nó OSD, apague a chave antiga do minion Salt nomaster Salt e registre a nova chave no master Salt. Para obter mais informações sobre aimplantação do minion Salt, consulte o Livro “Guia de Implantação”, Capítulo 4 “Implantando

com o DeepSea/Salt”, Seção 4.3 “Implantação do cluster”.

3. Em vez de executar toda a Fase 0, execute as seguintes partes:

root@master # salt 'osd_node' state.apply ceph.syncroot@master # salt 'osd_node' state.apply ceph.packages.commonroot@master # salt 'osd_node' state.apply ceph.minesroot@master # salt 'osd_node' state.apply ceph.updates

4. Execute as Fases de 1 a 5 do DeepSea:

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

5. Execute a Fase 0 do DeepSea:

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

6. Reinicialize o nó OSD relevante. Todos os discos OSD serão redescobertos e reutilizados.

1.8 Instalação automatizada pelo Salt

É possível automatizar a instalação por meio do reator Salt. Para ambientes virtuais ou dehardware consistentes, esta conguração permitirá a criação de um cluster do Ceph com ocomportamento especicado.

10 Recuperando um nó OSD reinstalado SES 5

AtençãoO Salt não pode executar vericações de dependência com base nos eventos do reator.Existe um risco real de tornar seu master Salt sobrecarregado e sem resposta.

A instalação automatizada requer o seguinte:

Um /srv/pillar/ceph/proposals/policy.cfg criado apropriadamente.

Conguração personalizada preparada incluída no diretório /srv/pillar/ceph/stack .

A conguração do reator padrão executará apenas as Fases 0 e 1. Isso permite testar o reatorsem esperar a conclusão das fases seguintes.

Quando o primeiro comando salt-minion for iniciado, a Fase 0 começará. Um bloqueio impedevárias instâncias. Quando todos os minions concluírem a Fase 0, a Fase 1 será iniciada.

Se a operação for executada apropriadamente, mude a última linha no /etc/salt/master.d/reactor.conf :

- /srv/salt/ceph/reactor/discovery.sls

para

- /srv/salt/ceph/reactor/all_stages.sls

1.9 Atualizando os nós do cluster

Convém aplicar atualizações sequenciais aos nós do cluster regularmente. Para aplicar asatualizações, execute a Fase 0:

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

11 Atualizando os nós do cluster SES 5

Se o DeepSea detectar um cluster do Ceph em execução, ele aplicará as atualizações e reiniciaráos nós sequencialmente. O DeepSea segue a recomendação ocial do Ceph de atualizar primeiroos monitores, depois os OSDs e, por último, os serviços adicionais, como MDS, Object Gateway,iSCSI Gateway ou NFS Ganesha. O DeepSea interromperá o processo de atualização se eledetectar algum problema no cluster. Veja a seguir o que pode provocar isso:

O Ceph relata “HEALTH_ERR” por mais do que 300 segundos.

Os minions Salt são consultados para vericar se os serviços atribuídos deles ainda estãoativos depois de uma atualização. Haverá falha na atualização se os serviços careminativos por mais do que 900 segundos.

Faça esses ajustes para garantir que o cluster do Ceph continue funcionando mesmo com asatualizações corrompidas ou com falha.

A Fase 0 do DeepSea atualizará o sistema por meio do zypper update e o reinicializará seo kernel for atualizado. Para eliminar a possibilidade de uma reinicialização forçada de todosos nós em potencial, verique se o kernel mais recente está instalado e em execução antes deiniciar a Fase 0 do DeepSea.

Dica: zypper patchSe você preferir atualizar o sistema usando o comando zypper patch , edite o /srv/pillar/ceph/stack/global.yml e adicione a seguinte linha:

update_method_init: zypper-patch

Você pode mudar o comportamento de reinicialização padrão da Fase 0 do DeepSea adicionandoas seguintes linhas ao /srv/pillar/ceph/stack/global.yml :

stage_prep_master: default-update-no-rebootstage_prep_minion: default-update-no-reboot

stage_prep_master dene o comportamento da Fase 0 do master Salt, e stage_prep_miniondene o comportamento de todos os minions. Todos os parâmetros disponíveis são:

default

Instalar as atualizações e reinicializar após a atualização.

default-update-no-reboot

Instalar as atualizações sem reinicializar.

12 Atualizando os nós do cluster SES 5

default-no-update-reboot

Reinicializar sem instalar as atualizações.

default-no-update-no-reboot

Não instalar as atualizações nem reinicializar.

1.10 Parando ou reinicializando o cluster

Em alguns casos, talvez seja necessário parar ou reinicializar o cluster inteiro. Recomendamosvericar com cuidado as dependências dos serviços em execução. As seguintes etapasapresentam uma descrição de como parar e iniciar o cluster:

1. Especique para o cluster do Ceph não marcar os OSDs com o ag “out”:

root # ceph osd set noout

2. Pare os daemons e os nós na seguinte ordem:

1. Clientes de armazenamento

2. Gateways. Por exemplo, NFS Ganesha ou Object Gateway

3. Servidor de Metadados

4. Ceph OSD

5. Ceph Manager

6. Ceph Monitor

3. Se necessário, execute as tarefas de manutenção.

4. Inicie os nós e os servidores na ordem inversa do processo de encerramento:

1. Ceph Monitor

2. Ceph Manager

3. Ceph OSD

4. Servidor de Metadados

13 Parando ou reinicializando o cluster SES 5

5. Gateways. Por exemplo, NFS Ganesha ou Object Gateway

6. Clientes de armazenamento

5. Remova o ag “noout”:

root # ceph osd unset noout

1.11 Arquivo ceph.conf personalizado

Se você precisar inserir congurações personalizadas no arquivo ceph.conf , poderámodicar os arquivos de conguração no diretório /srv/salt/ceph/configuration/files/ceph.conf.d :

global.conf

mon.conf

mgr.conf

mds.conf

osd.conf

client.conf

rgw.conf

Nota: Rgw.conf exclusivoO Object Gateway oferece muita exibilidade e é exclusivo em comparação comoutras seções do ceph.conf . Todos os outros componentes do Ceph têm cabeçalhosestáticos, como [mon] ou [osd] . O Object Gateway tem cabeçalhos exclusivos, como[client.rgw.rgw1] . Isso signica que o arquivo rgw.conf precisa de uma entrada decabeçalho. Consulte /srv/salt/ceph/configuration/files/rgw.conf para ver umexemplo.

14 Arquivo ceph.conf personalizado SES 5

Importante: Executar a fase 3Após fazer mudanças personalizadas nos arquivos de conguração mencionados acima,execute a Fase 3 para aplicá-las aos nós do cluster:

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

Esses arquivos são incluídos do arquivo de gabarito /srv/salt/ceph/configuration/files/ceph.conf.j2 e correspondem às diferentes seções aceitas pelo arquivo de conguração doCeph. Ao inserir um trecho da conguração no arquivo correto, o DeepSea pode incluí-lo naseção correta. Você não precisa adicionar nenhum dos cabeçalhos de seção.

DicaPara aplicar quaisquer opções de conguração apenas às instâncias especícas de umdaemon, adicione um cabeçalho como [osd.1] . As seguintes opções de conguraçãoserão aplicadas apenas ao daemon OSD com o ID 1.

1.11.1 Anulando os padrões

As últimas declarações em uma seção anulam as anteriores. Portanto, é possível anular aconguração padrão conforme especicado no gabarito /srv/salt/ceph/configuration/files/ceph.conf.j2 . Por exemplo, para desativar a autenticação do cephx, adicioneas três linhas a seguir ao arquivo /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf :

auth cluster required = noneauth service required = noneauth client required = none

1.11.2 Incluindo arquivos de configuração

Se você precisar aplicar muitas congurações personalizadas, use as seguintes declaraçõesde inclusão nos arquivos de conguração personalizados para facilitar o gerenciamento dearquivos. Veja a seguir um exemplo de arquivo osd.conf :

[osd.1]

15 Anulando os padrões SES 5

{% include "ceph/configuration/files/ceph.conf.d/osd1.conf" ignore missing %}[osd.2]{% include "ceph/configuration/files/ceph.conf.d/osd2.conf" ignore missing %}[osd.3]{% include "ceph/configuration/files/ceph.conf.d/osd3.conf" ignore missing %}[osd.4]{% include "ceph/configuration/files/ceph.conf.d/osd4.conf" ignore missing %}

No exemplo anterior, os arquivos osd1.conf , osd2.conf , osd3.conf e osd4.conf contêmopções de conguração especícas ao OSD relacionado.

Dica: Configuração de tempo de execuçãoAs mudanças feitas nos arquivos de conguração do Ceph entrarão em vigor após areinicialização dos daemons Ceph relacionados. Consulte a Seção 1.12, “Configuração de

tempo de execução do Ceph” para obter mais informações sobre como mudar a conguraçãode tempo de execução do Ceph.

1.12 Configuração de tempo de execução do CephA Seção  1.11, “Arquivo ceph.conf personalizado” descreve como fazer mudanças no arquivode conguração do Ceph ceph.conf . Entretanto, o comportamento real do cluster não édeterminado pelo estado atual do arquivo ceph.conf , mas sim pela conguração dos daemonsCeph em execução, que são armazenados na memória.

É possível consultar determinada conguração em um daemon Ceph usando o soquete de adminno nó em que o daemon está em execução. Por exemplo, o seguinte comando obtém o valor doparâmetro de conguração osd_max_write_size do daemon denominado osd.0 :

root # ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok \config get osd_max_write_size{ "osd_max_write_size": "90"}

Você também pode mudar as congurações dos daemons em tempo de execução. Lembre-se deque essa mudança é temporária e será perdida após a reinicialização do próximo daemon. Porexemplo, o seguinte comando muda o parâmetro osd_max_write_size para “50” em todos osOSDs no cluster:

root # ceph tell osd.* injectargs --osd_max_write_size 50

16 Configuração de tempo de execução do Ceph SES 5

Atenção: injectargs não é confiávelMudar as congurações do cluster com o comando injectargs não é 100% conável.Se você precisa ter certeza de que o parâmetro mudado está ativo, mude-o no arquivo deconguração e reinicie todos os daemons no cluster.

17 Configuração de tempo de execução do Ceph SES 5

II Operando um cluster

2 Introdução 19

3 Operando serviços do Ceph 20

4 Determinando o estado do cluster 24

5 Autenticação com cephx 41

6 Gerenciamento de dados armazenados 56

7 Gerenciando pools de armazenamento 73

8 Dispositivo de Blocos RADOS 92

9 Pools com codificação de eliminação 112

10 Camadas de cache 118

2 Introdução

Nesta parte do manual, você aprenderá como iniciar ou parar os serviços do Ceph, monitorar oestado de um cluster, usar e modicar Mapas CRUSH ou gerenciar pools de armazenamento.

Há também tópicos avançados, por exemplo, como gerenciar os usuários e a autenticação emgeral, como gerenciar o pool e os instantâneos de dispositivos RADOS, como congurar poolscom codicação de eliminação ou como melhorar o desempenho do cluster com camadas decache.

19 SES 5

3 Operando serviços do Ceph

Você pode operar serviços do Ceph usando o systemd ou o DeepSea.

3.1 Operando serviços do Ceph usando systemdUse o comando systemctl para operar todos os serviços relacionados ao Ceph. A operação érealizada no nó em que você efetuou login. Você precisa ter privilégios de root para operarserviços do Ceph.

3.1.1 Iniciando, parando e reiniciando serviços usando destinos

Para tornar mais simples iniciar, parar e reiniciar todos os serviços de determinado tipo (porexemplo, todos os serviços do Ceph, os MONs ou os OSDs) em um nó, o Ceph oferece os seguintesarquivos da unidade systemd :

root # ls /usr/lib/systemd/system/ceph*.targetceph.targetceph-osd.targetceph-mon.targetceph-mgr.targetceph-mds.targetceph-radosgw.targetceph-rbd-mirror.target

Para iniciar/parar/reiniciar todos os serviços do Ceph no nó, execute:

root # systemctl stop ceph.targetroot # systemctl start ceph.targetroot # systemctl restart ceph.target

Para iniciar/parar/reiniciar todos os OSDs no nó, execute:

root # systemctl stop ceph-osd.targetroot # systemctl start ceph-osd.targetroot # systemctl restart ceph-osd.target

Os comandos para os outros destinos são semelhantes.

20 Operando serviços do Ceph usando systemd SES 5

3.1.2 Iniciando, parando e reiniciando serviços individuais

Você pode operar serviços individuais usando os seguintes arquivos parametrizados da unidadesystemd :

ceph-osd@.serviceceph-mon@.serviceceph-mds@.serviceceph-radosgw@.serviceceph-rbd-mirror@.service

Para usar esses comandos, primeiro você precisa identicar o nome do serviço que deseja operar.Consulte a Seção 3.1.3, “Identificando serviços individuais” para saber mais sobre a identicação deserviços.

Para iniciar/parar/reiniciar o serviço osd.1 , execute:

root # systemctl stop ceph-osd@1.serviceroot # systemctl start ceph-osd@1.serviceroot # systemctl restart ceph-osd@1.service

Os comandos para os outros tipos de serviço são semelhantes.

3.1.3 Identificando serviços individuais

É possível descobrir os nomes ou números de um tipo especíco de serviço executandosystemctl e ltrando os resultados com o comando grep . Por exemplo:

root # systemctl | grep -i 'ceph-osd.*service'root # systemctl | grep -i 'ceph-mon.*service'[...]

3.1.4 Status do serviço

É possível consultar o systemd para saber o status dos serviços. Por exemplo:

root # systemctl status ceph-osd@1.serviceroot # systemctl status ceph-mon@HOSTNAME.service

Substitua HOSTNAME pelo nome de host no qual o daemon está em execução.

Se você não souber o nome/número exato do serviço, consulte a Seção 3.1.3, “Identificando serviços

individuais”.

21 Iniciando, parando e reiniciando serviços individuais SES 5

3.2 Reiniciando serviços do Ceph usando DeepSeaApós aplicar as atualizações aos nós do cluster, você precisará reiniciar os serviços atribuídospara usar a versão recém-instalada.

Nota: Observando a reinicializaçãoO processo de reinicialização do cluster pode levar algum tempo. Para observar oseventos, você pode usar o barramento de evento do Salt ao executar o comando:

root@master # salt-run state.event pretty=True

3.2.1 Reiniciando todos os serviços

Para reiniciar todos os serviços no cluster, execute o seguinte comando:

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

A ordem em que cada função é reiniciada varia de acordo com a versão do DeepSea ( rpm -q deepsea ):

Para o DeepSea anterior à versão 0.8.4, os serviços Servidor de Metadados, iSCSI Gateway,Object Gateway e NFS Ganesha são reiniciados em paralelo.

Para o DeepSea 0.8.4 e versões mais recentes, todas as funções conguradas são reiniciadasna seguinte ordem: Ceph Monitor, Ceph Manager, Ceph OSD, Servidor de Metadados,Object Gateway, iSCSI Gateway, NFS Ganesha. Para manter o tempo de espera baixo edetectar possíveis problemas o quanto antes, os nós são reiniciados sequencialmente. Porexemplo, apenas um nó de monitoramento é reiniciado de cada vez.

O comando aguardará a recuperação do cluster se ele estiver degradado, não saudável.

3.2.2 Reiniciando serviços específicos

Para reiniciar um serviço especíco no cluster, execute:

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

22 Reiniciando serviços do Ceph usando DeepSea SES 5

Por exemplo, para reiniciar todos os Object Gateways, execute:

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

Você pode usar os seguintes destinos:

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

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

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

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

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

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

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

23 Reiniciando serviços específicos SES 5

4 Determinando o estado do cluster

Quando você tem um cluster em execução, pode usar a ferramenta ceph para monitorá-lo.Normalmente, a determinação do estado do cluster envolve vericar o status do OSD, monitor,grupo de posicionamento e servidor de metadados.

Dica: Modo interativoPara executar a ferramenta ceph no modo interativo, digite ceph na linha de comandosem argumentos. O modo interativo é o mais prático quando você pretende digitar maiscomandos ceph em uma linha. Por exemplo:

cephadm > cephceph> healthceph> statusceph> quorum_statusceph> mon_status

4.1 Verificando a saúde do clusterApós iniciar o cluster e antes de começar a leitura e/ou gravação de dados, verique a saúde dele:

root # ceph healthHEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \node-1,node-2,node-3

O cluster do Ceph retorna um dos seguintes códigos de saúde:

OSD_DOWN

Um ou mais OSDs estão marcados como inativos. O daemon OSD pode ter sido parado ouos OSDs peers talvez não conseguem acessar o OSD pela rede. As causas comuns incluemum daemon parado ou com falha, um host inativo ou uma interrupção da rede.Verique se o host está saudável, se o daemon foi iniciado e se a rede está funcionando. Seo daemon falhou, o arquivo de registro do daemon ( /var/log/ceph/ceph-osd.* ) podeincluir informações de depuração.

OSD_ tipo de crush _DOWN. Por exemplo, OSD_HOST_DOWN

Todos os OSDs em uma subárvore especíca do CRUSH estão marcados como inativos. Porexemplo, todos os OSDs em um host.

24 Verificando a saúde do cluster SES 5

OSD_ORPHAN

Um OSD é referenciado na hierarquia do mapa CRUSH, mas não existe. O OSD pode serremovido da hierarquia do CRUSH com:

root # ceph osd crush rm osd.ID

OSD_OUT_OF_ORDER_FULL

Os limites de uso para backllfull, nearfull, full e/ou failsafe_full não estão em ordemcrescente. Especicamente, esperamos backllfull < nearfull, nearfull < full e full <failsafe_full. É possível ajustar os limites com:

root # ceph osd set-backfillfull-ratio ratioroot # ceph osd set-nearfull-ratio ratioroot # ceph osd set-full-ratio ratio

OSD_FULL

Um ou mais OSDs excederam o limite de full e impedem o cluster de executar gravações.É possível vericar o uso por pool com:

root # ceph df

É possível ver a cota full denida no momento com:

root # ceph osd dump | grep full_ratio

Uma solução alternativa de curto prazo para resolver a disponibilidade de gravação éaumentar um pouco o valor do limite de full:

root # ceph osd set-full-ratio ratio

Adicione o novo armazenamento ao cluster implantando mais OSDs ou apague os dadosexistentes para liberar espaço.

OSD_BACKFILLFULL

Um ou mais OSDs excederam o limite de backllfull, o que impede a redistribuição dosdados no dispositivo. Trata-se de um aviso antecipado de que a redistribuição talvez nãopossa ser concluída e de que o cluster está quase cheio. É possível vericar o uso por poolcom:

root # ceph df

25 Verificando a saúde do cluster SES 5

OSD_NEARFULL

Um ou mais OSDs excederam o limite de nearfull. Trata-se de um aviso antecipado de queo cluster está quase cheio. É possível vericar o uso por pool com:

root # ceph df

OSDMAP_FLAGS

Um ou mais ags de interesse do cluster foram denidos. Com exceção de full, é possíveldenir ou limpar esses ags com:

root # ceph osd set flagroot # ceph osd unset flag

Esses ags incluem:

full

O cluster foi sinalizado como cheio e não pode realizar gravações.

pauserd, pausewr

Leituras ou gravações pausadas.

noup

Os OSDs não têm permissão para serem iniciados.

nodown

Os relatórios de falha do OSD estão sendo ignorados, portanto, os monitores nãomarcarão os OSDs como inativos.

noin

Os OSDs já marcados como out não serão remarcados como in quando foreminiciados.

noout

Os OSDs inativos não serão automaticamente marcados como out após o intervalocongurado.

nobackfill, norecover, norebalance

A recuperação ou a redistribuição de dados está suspensa.

noscrub, nodeep_scrub

A depuração (consulte a Seção 6.5, “Depuração”) está desabilitada.

notieragent

A atividade de camadas de cache foi suspensa.

26 Verificando a saúde do cluster SES 5

OSD_FLAGS

Um ou mais OSDs têm um ag de interesse denido por OSD. Esses ags incluem:

noup

O OSD não tem permissão para ser iniciado.

nodown

Os relatórios de falha para este OSD serão ignorados.

noin

Se este OSD já foi marcado como out automaticamente após uma falha, ele não serámarcado como in quando for iniciado.

noout

Se este OSD estiver inativo, ele não será automaticamente marcado como out apóso intervalo congurado.

É possível denir e limpar os ags por OSD com:

root # ceph osd add-flag osd-IDroot # ceph osd rm-flag osd-ID

OLD_CRUSH_TUNABLES

O Mapa CRUSH usa congurações muito antigas e deve ser atualizado. Os tunables maisantigos que podem ser usados (ou seja, a versão de cliente mais antiga que pode se conectarao cluster) sem acionar este aviso de saúde são determinados pela opção de conguraçãomon_crush_min_required_version .

OLD_CRUSH_STRAW_CALC_VERSION

O Mapa CRUSH usa um método mais antigo que não é o ideal para calcular os valoresde peso intermediários para compartimentos de memória straw. O Mapa CRUSH deve seratualizado para usar o método mais recente ( straw_calc_version=1).

CACHE_POOL_NO_HIT_SET

Um ou mais pools de cache não estão congurados com um conjunto de acertos paramonitorar o uso, o que impede o agente de camadas de identicar objetos frios paradescarregar e eliminar do cache. É possível congurar conjuntos de acertos no pool decache com:

root # ceph osd pool set poolname hit_set_type typeroot # ceph osd pool set poolname hit_set_period period-in-secondsroot # ceph osd pool set poolname hit_set_count number-of-hitsets

27 Verificando a saúde do cluster SES 5

root # ceph osd pool set poolname hit_set_fpp target-false-positive-rate

OSD_NO_SORTBITWISE

Não há OSDs anterior ao Luminous v12 em execução, mas o ag sortbitwise não foidenido. Você precisa denir o ag sortbitwise antes que os OSDs Luminous v12 oumais recentes possam ser iniciados:

root # ceph osd set sortbitwise

POOL_FULL

Um ou mais pools atingiram a cota e não permitem mais gravações. Você pode denircotas e uso de pool com:

root # ceph df detail

Você pode aumentar a cota do pool com

root # ceph osd pool set-quota poolname max_objects num-objectsroot # ceph osd pool set-quota poolname max_bytes num-bytes

ou apagar alguns dados existentes para reduzir o uso.

PG_AVAILABILITY

A disponibilidade de dados está reduzida, o que signica que o cluster não pode atender apossíveis solicitações de leitura ou gravação para alguns dados no cluster. Especicamente,o estado de um ou mais PGs não permite que as solicitações de E/S sejam atendidas. Osestados dos PGs problemáticos incluem emparelhamento, obsoleto, incompleto e a ausênciade ativo (se essas condições não forem resolvidas rapidamente). As informações detalhadassobre quais PGs são afetados estão disponíveis em:

root # ceph health detail

Na maioria dos casos, a causa raiz é que um ou mais OSDs estão inativos no momento. Épossível consultar o estado dos PGs problemáticos especícos com:

root # ceph tell pgid query

PG_DEGRADED

A redundância de dados está reduzida para alguns dados, o que signica que o clusternão tem o número de réplicas desejado para todos os dados (em pools replicados) oupara fragmentos de código de eliminação (em pools com codicação de eliminação).Especicamente, um ou mais PGs têm o ag degraded ou undersized denido (não há

28 Verificando a saúde do cluster SES 5

instâncias sucientes desse grupo de posicionamento no cluster) ou não tinham o ag cleandenido durante determinado período. As informações detalhadas sobre quais PGs sãoafetados estão disponíveis em:

root # ceph health detail

Na maioria dos casos, a causa raiz é que um ou mais OSDs estão inativos no momento. Épossível consultar o estado dos PGs problemáticos especícos com:

root # ceph tell pgid query

PG_DEGRADED_FULL

A redundância de dados pode estar reduzida ou em risco para alguns dados devidoà ausência de espaço livre no cluster. Especicamente, um ou mais PGs têm o agbackll_toofull ou recovery_toofull denido, o que signica que o cluster não pode migrarou recuperar dados porque um ou mais OSDs estão acima do limite de backllfull.

PG_DAMAGED

A depuração de dados (consulte a Seção 6.5, “Depuração”) descobriu alguns problemas coma consistência de dados no cluster. Especicamente, um ou mais PGs têm o ag inconsistentou snaptrim_error denido, indicando que uma operação de depuração anterior detectouum problema, ou o ag repair denido, o que signica que um reparo para esse tipo deinconsistência está agora em andamento.

OSD_SCRUB_ERRORS

Depurações recentes de OSD revelaram inconsistências.

CACHE_POOL_NEAR_FULL

Um pool de camada de cache está quase cheio. Neste contexto, “full” é determinado pelaspropriedades target_max_bytes e target_max_objects no pool de cache. Quando o pool atinge olimite de destino, as solicitações de gravação para o pool podem ser bloqueadas enquantoos dados são descarregados e eliminados do cache, um estado que normalmente geralatências muito altas e baixo desempenho. É possível ajustar o tamanho do destino do poolde cache com:

root # ceph osd pool set cache-pool-name target_max_bytes bytesroot # ceph osd pool set cache-pool-name target_max_objects objects

As atividades normais de descarregamento e eliminação de cache também podem carrestritas por redução na disponibilidade ou no desempenho da camada de base ou docarregamento geral do cluster.

29 Verificando a saúde do cluster SES 5

TOO_FEW_PGS

O número de PGs em uso está abaixo do limite congurável demon_pg_warn_min_per_osd PGs por OSD. Isso pode levar à distribuição e ao equilíbriode dados abaixo do ideal em todos os OSDs no cluster, reduzindo o desempenho geral.

TOO_MANY_PGS

O número de PGs em uso está acima do limite congurável de mon_pg_warn_max_per_osdPGs por OSD. Isso pode levar a um aumento do uso de memória dos daemons OSD,a uma redução do emparelhamento após mudanças no estado do cluster (por exemplo,reinicializações, adições ou remoções de OSD) e a um aumento da carga nos Ceph Managerse Ceph Monitors.O valor pg_num de pools existentes não pode ser reduzido. Porém, o valor pgp_num pode.Isso efetivamente combina alguns PGs nos mesmos conjuntos de OSDs, atenuando algunsdos impactos negativos descritos acima. É possível ajustar o valor pgp_num com:

root # ceph osd pool set pool pgp_num value

SMALLER_PGP_NUM

Um ou mais pools têm um valor pgp_num menor do que pg_num . Normalmente, issoindica que a contagem de PGs foi aumentada sem aumentar também o comportamentode posicionamento. Isso costuma ser resolvido denindo pgp_num para corresponder apg_num , o que aciona a migração de dados, com:

ceph osd pool set pool pgp_num pg_num_value

MANY_OBJECTS_PER_PG

Um ou mais pools têm um número médio de objetos por PG que é signicativamentemaior do que a média geral do cluster. O limite especíco é controlado pelo valorda conguração mon_pg_warn_max_object_skew . Isso costuma ser uma indicação deque o(s) pool(s) com a maioria dos dados no cluster está(ão) com um número muitobaixo de PGs, e/ou que outros pools sem tantos dados têm PGs em excesso. É possívelaumentar o limite para silenciar o aviso de saúde ajustando a opção de conguraçãomon_pg_warn_max_object_skew nos monitores.

POOL_APP_NOT_ENABLED

Existe um pool que contém um ou mais objetos, mas que não foi marcados para uso pordeterminado aplicativo. Resolva esse aviso identicando o pool para uso por um aplicativo.Por exemplo, se o pool é usado pelo RBD:

root # rbd pool init pool_name

30 Verificando a saúde do cluster SES 5

Se o pool é usado por um aplicativo personalizado “foo”, você também pode identicá-lousando o comando de nível inferior:

root # ceph osd pool application enable foo

POOL_FULL

Um ou mais pools atingiram (ou estão muito próximos de atingir) a cota. Olimite para acionar essa condição de erro é controlado pela opção de conguraçãomon_pool_quota_crit_threshold . É possível aumentar ou reduzir (ou remover) as cotasde pool com:

root # ceph osd pool set-quota pool max_bytes bytesroot # ceph osd pool set-quota pool max_objects objects

A denição do valor como 0 desabilitará a cota.

POOL_NEAR_FULL

Um ou mais pools estão quase atingindo a cota. O limite para acionar essa condição de avisoé controlado pela opção de conguração mon_pool_quota_warn_threshold . É possívelaumentar ou reduzir (ou remover) as cotas de pool com:

root # ceph osd osd pool set-quota pool max_bytes bytesroot # ceph osd osd pool set-quota pool max_objects objects

A denição do valor como 0 desabilitará a cota.

OBJECT_MISPLACED

Um ou mais objetos no cluster não estão armazenados no nó em que o cluster deseja queeles sejam armazenados. Isso é uma indicação de que a migração de dados decorrentede alguma mudança recente no cluster ainda não foi concluída. Os dados incorretamentearmazenados não representam uma condição de risco por si só. A consistência de dadosnunca está em risco, e as cópias antigas de objetos serão removidas apenas quando houvero número desejado de novas cópias (nos locais esperados).

OBJECT_UNFOUND

Um ou mais objetos no cluster não foram encontrados. Especicamente, os OSDs sabemque uma cópia nova ou atualizada de um objeto deve existir, mas uma cópia dessa versãodo objeto não foi encontrada nos OSDs que estão online no momento. As solicitações deleitura ou gravação para os objetos “não encontrados” serão bloqueadas. O ideal é que

31 Verificando a saúde do cluster SES 5

um OSD inativo com a cópia mais recente do objeto não encontrado possa voltar a caronline. É possível identicar os OSDs candidatos com base no estado do emparelhamentoreferente ao(s) PG(s) responsável(is) pelo objeto não encontrado:

root # ceph tell pgid query

REQUEST_SLOW

O processamento de uma ou mais solicitações OSD está levando muito tempo. Isso podeser uma indicação de carga extrema, um dispositivo de armazenamento lento ou um bugde software. É possível consultar a la de solicitações no(s) OSD(s) em questão com oseguinte comando executado do host OSD:

root # ceph daemon osd.id ops

Você pode ver um resumo das solicitações recentes mais lentas:

root # ceph daemon osd.id dump_historic_ops

Você pode encontrar o local de um OSD com:

root # ceph osd find osd.id

REQUEST_STUCK

Uma ou mais solicitações OSD caram bloqueadas por um tempo extremamente longo.Isso é uma indicação de que o cluster não esteve saudável por um longo período (porexemplo, não há OSDs sucientes em execução) ou de que existe algum problema internocom o OSD.

PG_NOT_SCRUBBED

Um ou mais PGs não foram depurados (consulte a Seção 6.5, “Depuração”) recentemente.Normalmente, os PGs são depurados a cada mon_scrub_interval segundos, e esse avisoserá acionado após decorrer mon_warn_not_scrubbed segundos sem uma depuração. OsPGs não serão depurados se não forem sinalizados como limpos, o que poderá ocorrer seforem armazenados incorretamente ou estiverem degradados (consulte PG_AVAILABILITYe PG_DEGRADED acima). Você pode iniciar manualmente uma depuração de um PG limpocom:

root # ceph pg scrub pgid

PG_NOT_DEEP_SCRUBBED

Um ou mais PGs não foram depurados em detalhes (consulte a Seção  6.5,

“Depuração”) recentemente. Normalmente, os PGs são depurados a cadaosd_deep_mon_scrub_interval segundos, e esse aviso é acionado quando esses

32 Verificando a saúde do cluster SES 5

intervalos de mon_warn_not_deep_scrubbed decorreram sem uma depuração. Os PGsnão serão depurados (em detalhes) se não forem sinalizados como limpos, o quepoderá ocorrer se forem armazenados incorretamente ou estiverem degradados (consultePG_AVAILABILITY e PG_DEGRADED acima). Você pode iniciar manualmente umadepuração de um PG limpo com:

root # ceph pg deep-scrub pgid

DicaSe você especicou locais diferentes do padrão em sua conguração ou no chaveiro, deveespecicar estes locais:

root # ceph -c /path/to/conf -k /path/to/keyring health

4.2 Observando um cluster

Você pode detectar o estado imediato do cluster usando o comando ceph -s . Por exemplo, umcluster do Ceph bem pequeno composto por um monitor e dois OSDs pode imprimir o seguintequando há uma carga de trabalho em execução:

cluster: id: 6586341d-4565-3755-a4fd-b50f51bee248 health: HEALTH_OK

services: mon: 3 daemons, quorum blueshark1,blueshark2,blueshark3 mgr: blueshark3(active), standbys: blueshark2, blueshark1 osd: 15 osds: 15 up, 15 in

data: pools: 8 pools, 340 pgs objects: 537 objects, 1985 MB usage: 23881 MB used, 5571 GB / 5595 GB avail pgs: 340 active+clean

io: client: 100 MB/s rd, 26256 op/s rd, 0 op/s wr

33 Observando um cluster SES 5

A saída apresenta as seguintes informações:

ID do cluster

Status de saúde do cluster

A época do mapa do monitor e o status do quorum do monitor

A época do mapa OSD e o status dos OSDs

A versão do mapa do grupo de posicionamento

O número de grupos de posicionamento e pools

A quantidade estimada de dados armazenados e o número de objetos armazenados; e

A quantidade total de dados armazenados.

Dica: Como o Ceph calcula o uso de dadosO valor usado reete o valor real do armazenamento bruto utilizado. O valor xxx GB/xxx GB indica o valor disponível (o menor número) da capacidade de armazenamentogeral do cluster. O número estimado reete o tamanho dos dados armazenados antesde serem replicados, clonados ou capturados como instantâneos. Portanto, a quantidadede dados realmente armazenados costuma exceder o valor estimado armazenado, pois oCeph cria réplicas dos dados e também pode usar a capacidade de armazenamento parafazer clonagem e criar instantâneos.

Outros comandos que exibem informações de status imediatas são:

ceph pg stat

ceph osd pool stats

ceph df

ceph df detail

Para obter as informações atualizadas em tempo real, insira qualquer um destes comandos(incluindo ceph -s ) em um loop de espera. Por exemplo:

rootwhile true ; do ceph -s ; sleep 10 ; done

34 Observando um cluster SES 5

Pressione Ctrl – C quando estiver cansado de observar.

4.3 Verificando as estatísticas de uso do clusterPara vericar o uso de dados de um cluster e a distribuição de dados entre os pools, você podeusar a opção df . Esse procedimento é similar ao df do Linux. Execute o seguinte:

root # ceph dfGLOBAL: SIZE AVAIL RAW USED %RAW USED 55886G 55826G 61731M 0.11POOLS: NAME ID USED %USED MAX AVAIL OBJECTS testpool 1 0 0 17676G 0 ecpool 2 4077M 0.01 35352G 2102 test1 3 0 0 17676G 0 rbd 4 16 0 17676G 3 rbd1 5 16 0 17676G 3 ecpool1 6 5708M 0.02 35352G 2871

A seção GLOBAL da saída apresenta uma visão geral da quantidade de armazenamento que seucluster usa para os dados.

SIZE : A capacidade de armazenamento geral do cluster.

AVAIL : A quantidade de espaço livre disponível no cluster.

RAW USED : A quantidade usada de armazenamento bruto.

% RAW USED : A porcentagem usada de armazenamento bruto. Use esse número emconjunto com full ratio e near full ratio para garantir que você não atinja acapacidade do cluster. Consulte Capacidade de armazenamento (http://docs.ceph.com/docs/

master/rados/configuration/mon-config-ref#storage-capacit) para obter mais detalhes.

Nota: Nível de preenchimento do clusterUm nível de preenchimento de armazenamento bruto de 70% a 80% indica queum novo armazenamento precisa ser adicionado ao cluster. O uso mais alto poderesultar em OSDs únicos cheios e problemas de saúde do cluster.

Use o comando ceph osd df tree para listar o nível de preenchimento de todosos OSDs.

35 Verificando as estatísticas de uso do cluster SES 5

A seção POOLS da saída apresenta uma lista dos pools e o uso estimado de cada pool. A saídadessa seção não reete réplicas, clones ou instantâneos. Por exemplo, se você armazenar umobjeto com 1 MB de dados, o uso estimado será de 1 MB, mas o uso real poderá ser de 2 MB oumais, dependendo do número de réplicas, clones e instantâneos.

NAME : O nome do pool.

ID : O ID do pool.

USED : A quantidade estimada de dados armazenados em quilobytes, exceto quando onúmero tem M anexado para megabytes ou G para gigabytes.

%USED : A porcentagem estimada de armazenamento usado por pool.

MAX AVAIL : O espaço máximo disponível no pool especicado.

OBJECTS : O número de objetos armazenados por pool.

NotaOs números na seção POOLS são estimativas. Eles não incluem o número de réplicas,instantâneos ou clones. Sendo assim, a soma dos valores USED e %USED não incluirá osvalores RAW USED e %RAW USED na seção %GLOBAL da saída.

4.4 Verificando o status do clusterPara vericar o status de um cluster, execute o seguinte:

root # ceph status

ou

root # ceph -s

No modo interativo, digite status e pressione Enter .

ceph> status

O Ceph imprimirá o status do cluster. Por exemplo, um cluster do Ceph bem pequeno compostopor um monitor e dois OSDs pode imprimir o seguinte:

cluster b370a29d-9287-4ca3-ab57-3d824f65e339

36 Verificando o status do cluster SES 5

health HEALTH_OK monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1 osdmap e63: 2 osds: 2 up, 2 in pgmap v41332: 952 pgs, 20 pools, 17130 MB data, 2199 objects 115 GB used, 167 GB / 297 GB avail 1 active+clean+scrubbing+deep 951 active+clean

4.5 Verificando o status do OSDVocê pode vericar os OSDs para garantir que estejam ativos e em execução:

root # ceph osd stat

ou

root # ceph osd dump

Você também pode ver os OSDs de acordo com a posição deles no mapa CRUSH.

root # ceph osd tree

O Ceph imprimirá uma árvore CRUSH com um host, os OSDs, se eles estão ativos e o peso.

# id weight type name up/down reweight-1 3 pool default-3 3 rack mainrack-2 3 host osd-host0 1 osd.0 up 11 1 osd.1 up 12 1 osd.2 up 1

4.6 Verificando se há OSDs cheiosO Ceph impede você de gravar em um OSD cheio para evitar a perda de dados. Em um clusteroperacional, você deve receber um aviso quando o cluster está próximo cota máxima. O padrãodo valor mon osd full ratio é de 0,95, ou 95% da capacidade antes de impedir que os clientesgravem dados. O padrão do valor mon osd nearfull ratio é de 0,85, ou 85% da capacidade,quando ele gera um aviso de saúde.

37 Verificando o status do OSD SES 5

O ceph health relata os nós OSD cheios:

ceph health HEALTH_WARN 1 nearfull osds osd.2 is near full at 85%

ou

ceph health HEALTH_ERR 1 nearfull osds, 1 full osds osd.2 is near full at 85% osd.3 is full at 97%

A melhor maneira de resolver um cluster cheio é adicionar novos nós OSD, o que permite aocluster redistribuir os dados para o armazenamento recém-disponibilizado.

Se você não pode iniciar um OSD porque ele está cheio, é possível apagar alguns dados excluindodiretórios do grupo de posicionamento no OSD cheio.

Dica: Evitando OSDs cheiosDepois que um OSD ca cheio (usa 100% do espaço em disco), ele costuma falharrapidamente sem aviso. Veja a seguir algumas dicas para se lembrar na hora deadministrar nós OSD.

O espaço em disco de cada OSD (normalmente montado em /var/lib/ceph/osd/osd-{1,2..} ) precisa ser colocado em um disco ou partição subjacente dedicado.

Verique os arquivos de conguração do Ceph e certique-se de que o Ceph nãoarmazene o arquivo de registro em discos/partições dedicados para uso por OSDs.

Conrme se nenhum outro processo faz gravações nos discos/partições dedicadospara uso por OSDs.

4.7 Verificando o status do monitorSe o seu cluster tem vários monitores (mais provável), você deve vericar o status do quorumdo monitor depois de iniciar o cluster, antes de ler e/ou gravar dados. Um quorum deve estarpresente quando vários monitores estão em execução. Você também deve vericar o status domonitor periodicamente para garantir que ele esteja em execução.

38 Verificando o status do monitor SES 5

Para exibir o mapa do monitor, execute o seguinte:

root # ceph mon stat

ou

root # ceph mon dump

Para vericar o status do quorum para o cluster do monitor, execute o seguinte:

root # ceph quorum_status

O Ceph retornará o status do quorum. Por exemplo, um cluster do Ceph com três monitorespode retornar o seguinte:

{ "election_epoch": 10, "quorum": [ 0, 1, 2], "monmap": { "epoch": 1, "fsid": "444b489c-4f16-4b75-83f0-cb8097468898", "modified": "2011-12-12 13:28:27.505520", "created": "2011-12-12 13:28:27.505520", "mons": [ { "rank": 0, "name": "a", "addr": "127.0.0.1:6789\/0"}, { "rank": 1, "name": "b", "addr": "127.0.0.1:6790\/0"}, { "rank": 2, "name": "c", "addr": "127.0.0.1:6791\/0"} ] }}

4.8 Verificando estados de grupo de posicionamentoOs grupos de posicionamento mapeiam objetos para OSDs. Ao monitorar seus grupos deposicionamento, você deseja que eles estejam ativos e limpos . Para ver uma discussãodetalhada, consulte Monitorando OSDs e grupos de posicionamento (http://docs.ceph.com/docs/

master/rados/operations/monitoring-osd-pg) .

39 Verificando estados de grupo de posicionamento SES 5

4.9 Usando o soquete de adminO soquete de admin do Ceph permite consultar um daemon pela interface do soquete. Porpadrão, os soquetes do Ceph residem em /var/run/ceph . Para acessar um daemon pelo soquetede admin, efetue login no host que executa o daemon e use o seguinte comando:

root # ceph --admin-daemon /var/run/ceph/socket-name

Para ver os comandos de soquete de admin disponíveis, execute o seguinte comando:

root # ceph --admin-daemon /var/run/ceph/socket-name help

O comando de soquete de admin permite mostrar e denir sua conguração em tempo deexecução. Consulte Vendo uma configuração em tempo de execução (http://docs.ceph.com/docs/

master/rados/configuration/ceph-conf#ceph-runtime-config) para obter detalhes.

Você também pode denir diretamente os valores de conguração em tempo de execução (osoquete de admin ignora o monitor, ao contrário de ceph tell daemon-type . id injectargs,que usa o monitor, mas não exige login diretamente no host em questão).

40 Usando o soquete de admin SES 5

5 Autenticação com cephx

Para identicar clientes e proteger-se contra ataques man-in-the-middle, o Ceph oferece osistema de autenticação cephx . Neste contexto, os clientes são pessoas, como o usuário admin,ou serviços/daemons relacionados ao Ceph, por exemplo, OSDs, monitores ou Object Gateways.

NotaO protocolo cephx não atende à criptograa de dados em transporte, como TLS/SSL.

5.1 Arquitetura de autenticaçãoO cephx usa chaves secretas compartilhadas para autenticação, o que signica que tanto ocliente quanto o cluster do monitor têm uma cópia da chave secreta do cliente. O protocolo deautenticação permite que ambas as partes comprovem uma para a outra que têm uma cópiada chave sem precisar revelá-la. Isso permite uma autenticação mútua: o cluster tem certezade que o usuário possui a chave secreta, e o usuário também tem certeza de que o cluster temuma cópia da chave secreta.

Um recurso de escalabilidade importante do Ceph é para evitar uma interface centralizada como armazenamento de objetos do Ceph. Isso signica que os clientes do Ceph podem interagirdiretamente com os OSDs. Para proteger os dados, o Ceph oferece o sistema de autenticaçãocephx , que autentica clientes do Ceph.

Cada monitor pode autenticar clientes e distribuir chaves, portanto, não há nenhum ponto únicode falha ou gargalo ao usar o cephx . O monitor retorna uma estrutura de dados de autenticaçãoque contém uma chave de sessão para uso na obtenção dos serviços do Ceph. Essa chave de sessãoé autocriptografada com a chave secreta permanente do cliente para que apenas o cliente possasolicitar serviços dos Ceph Monitors. Em seguida, o cliente usa a chave de sessão para solicitar osserviços desejados do monitor, e o monitor emite um ticket para o cliente que lhe autenticará nosOSDs que realmente processam os dados. Os Ceph Monitors e OSDs compartilham um segredo,portanto, o cliente pode usar o ticket emitido pelo monitor com qualquer OSD ou servidor demetadados no cluster. Os tickets do cephx expiram para que um invasor não consiga usar umticket expirado ou uma chave de sessão obtida indevidamente. Este formato de autenticaçãoevitará que invasores com acesso ao meio de comunicação criem mensagens falsas se passandopor outro cliente ou alterem mensagens legítimas de outro cliente, desde que a chave secretado cliente não seja revelada antes de expirar.

41 Arquitetura de autenticação SES 5

Para usar o cephx , um administrador deve primeiro congurar clientes/usuários. No diagrama aseguir, o usuário client.admin invoca ceph auth get-or-create-key da linha de comandopara gerar um nome de usuário e a chave secreta. O subsistema auth do Ceph gera o nome deusuário e a chave, armazena uma cópia com o(s) monitor(es) e transmite o segredo do usuáriode volta ao usuário client.admin . Isso signica que o cliente e o monitor compartilham umachave secreta.

FIGURA 5.1: AUTENTICAÇÃO BÁSICA DO cephx

Para autenticar-se no monitor, o cliente envia o nome de usuário ao monitor. O monitor gera umachave de sessão e a criptografa com a chave secreta associada ao nome de usuário e transmiteo ticket criptografado de volta para o cliente. Em seguida, o cliente decodica os dados com achave secreta compartilhada para recuperar a chave de sessão. A chave de sessão identica ousuário da sessão atual. Em seguida, o cliente solicita um ticket relacionado ao usuário, que éassinado pela chave de sessão. O monitor gera um ticket, criptografa-o com a chave secreta dousuário e o transmite de volta para o cliente. O cliente decodica o ticket e o utiliza para assinarsolicitações para OSDs e servidores de metadados em todo o cluster.

42 Arquitetura de autenticação SES 5

FIGURA 5.2: AUTENTICAÇÃO DO cephx

O protocolo cephx autentica as constantes comunicações entre a máquina cliente e os servidoresCeph. Cada mensagem enviada entre um cliente e um servidor após a autenticação inicial éassinada usando um ticket que os monitores, OSDs e servidores de metadados podem vericarcom o segredo compartilhado.

43 Arquitetura de autenticação SES 5

FIGURA 5.3: AUTENTICAÇÃO DO cephx: MDS E OSD

ImportanteA proteção oferecida por essa autenticação ocorre entre o cliente do Ceph e os hosts decluster do Ceph. A autenticação não ultrapassa o cliente do Ceph. Se um usuário acessar ocliente do Ceph de um host remoto, a autenticação do Ceph não será aplicada à conexãoentre o host do usuário e do cliente.

5.2 Gerenciamento de chaves

Esta seção descreve os usuários de cliente do Ceph e a autenticação e autorização no cluster dearmazenamento do Ceph. Usuários são pessoas ou mecanismos de sistema, como aplicativos, queusam os clientes do Ceph para interagir com os daemons do cluster de armazenamento do Ceph.

Quando o Ceph é executado com a autenticação e a autorização habilitadas (padrão), vocêdeve especicar um nome de usuário e um chaveiro que contém a chave secreta do usuárioespecicado (geralmente por meio da linha de comando). Se você não especicar um nomede usuário, o Ceph usará o client.admin como padrão. Se você não especicar um chaveiro,

44 Gerenciamento de chaves SES 5

o Ceph procurará um na conguração de chaveiros no arquivo de conguração do Ceph. Porexemplo, se você executar o comando ceph health sem especicar um nome de usuário ouchaveiro, o Ceph interpretará o comando da seguinte forma:

ceph -n client.admin --keyring=/etc/ceph/ceph.client.admin.keyring health

Se preferir, você poderá usar a variável de ambiente CEPH_ARGS para não ter que redigitar onome de usuário e o segredo.

5.2.1 Informações de segundo plano

Seja qual for o tipo de cliente do Ceph (por exemplo, dispositivo de blocos, armazenamento deobjetos, sistema de arquivos ou API nativa), o Ceph armazena todos os dados como objetos empools. Os usuários do Ceph precisam ter acesso aos pools para ler e gravar dados. Os usuáriosdo Ceph também devem ter permissões de execução para utilizar os comandos administrativosdo Ceph. Os conceitos a seguir ajudarão você a entender o gerenciamento de usuários do Ceph.

5.2.1.1 Usuário

Um usuário é uma pessoa ou um mecanismo de sistema, como um aplicativo. A criação deusuários permite controlar quem (ou o quê) pode acessar o cluster de armazenamento do Ceph,os pools e os dados dos pools.

O Ceph usa tipos de usuários. Para ns de gerenciamento de usuários, o tipo sempre será client .O Ceph identica os usuários no formato delimitado por ponto (.), que consiste no tipo e IDde usuário. Por exemplo, TYPE.ID , client.admin ou client.user1 . O motivo da deniçãode tipo do usuário é que os Ceph Monitors, OSDs e servidores de metadados também usam oprotocolo cephx, mas eles não são clientes. A distinção do tipo de usuário ajuda a diferenciaros usuários que são clientes dos demais, otimizando o controle de acesso, o monitoramento deusuários e o rastreamento.

NotaUm usuário de cluster de armazenamento do Ceph não é o mesmo que um usuário dearmazenamento de objetos ou de sistema de arquivos do Ceph. O Ceph Object Gatewayutiliza um usuário de cluster de armazenamento do Ceph para comunicação entre odaemon do gateway e o cluster de armazenamento, mas o gateway tem sua própria

45 Informações de segundo plano SES 5

funcionalidade de gerenciamento para usuários nais. O sistema de arquivos do Ceph usasemânticas do POSIX. O espaço do usuário associado a ele não é o mesmo de um usuáriode cluster de armazenamento do Ceph.

5.2.1.2 Autorização e recursos

O Ceph usa o termo "recursos" (caps) para descrever a autorização de um usuário autenticadopara executar as funcionalidades dos monitores, OSDs e servidores de metadados. Os recursostambém podem restringir o acesso aos dados em um pool ou a um namespace em um pool. Umusuário administrador do Ceph dene os recursos do usuário ao criá-lo ou atualizá-lo.

A sintaxe de recurso segue o formato:

daemon-type 'allow capability' [...]

Veja a seguir uma lista de recursos para cada tipo de serviço:

Recursos do monitor

incluem r , w , x e allow profile cap .

mon 'allow rwx'mon 'allow profile osd'

Recursos do OSD

incluem r , w , x , class-read , class-write e profile osd . Os recursos do OSDtambém permitem congurações de pool e namespace.

osd 'allow capability' [pool=poolname] [namespace=namespace-name]

Recurso do MDS

requer apenas allow ou ca em branco.

mds 'allow'

As entradas a seguir descrevem cada recurso:

allow

Antecede as congurações de acesso para um daemon. Implica apenas no rw para MDS.

r

Concede o acesso de leitura ao usuário. Necessário com monitores para recuperar o mapaCRUSH.

46 Informações de segundo plano SES 5

w

Concede ao usuário acesso de gravação em objetos.

x

Permite que o usuário chame métodos de classe (tanto de leitura quanto de gravação) eexecute operações do auth em monitores.

class-read

Permite que o usuário chame métodos de leitura de classe. Subconjunto do x .

class-write

Permite que o usuário chame métodos de gravação de classe. Subconjunto do x .

*

Concede ao usuário permissões de leitura, gravação e execução para determinado daemon/pool e permite executar comandos de admin.

profile osd

Concede a um usuário permissões para conectar-se como OSD a outros OSDs ou monitores.Atribuído aos OSDs para permitir que eles processem o tráfego de heartbeat de replicaçãoe o relatório de status.

profile mds

Concede a um usuário permissões para conectar-se como MDS a outros MDSs ou monitores.

profile bootstrap-osd

Concede a um usuário permissões para inicializar um OSD. Delegado a ferramentas deimplantação para que elas tenham permissões para adicionar chaves ao inicializar um OSD.

profile bootstrap-mds

Concede a um usuário permissões para inicializar um servidor de metadados. Delegadoa ferramentas de implantação para que elas tenham permissões para adicionar chaves aoinicializar um servidor de metadados.

5.2.1.3 Pools

Um pool é uma partição lógica em que os usuários armazenam dados. No caso das implantaçõesdo Ceph, é comum criar um pool como partição lógica para tipos de dados semelhantes. Porexemplo, ao implantar o Ceph como back end para o OpenStack, uma implantação típica tempools para volumes, imagens, backups, máquinas virtuais e usuários como client.glance ouclient.cinder .

47 Informações de segundo plano SES 5

5.2.2 Gerenciando usuários

A funcionalidade de gerenciamento de usuários permite aos administradores de cluster do Cephcriar, atualizar e apagar usuários diretamente do cluster do Ceph.

Ao criar ou apagar usuários do cluster do Ceph, talvez você tenha que distribuir chavesaos clientes para que elas possam ser adicionadas aos chaveiros. Consulte a Seção  5.2.3,

“Gerenciamento de chaveiro” para obter os detalhes.

5.2.2.1 Listando usuários

Para listar os usuários em seu cluster, execute o seguinte:

ceph auth list

O Ceph listará todos os usuários em seu cluster. Por exemplo, em um cluster com dois nós, asaída de ceph auth list tem esta aparência:

installed auth entries:

osd.0 key: AQCvCbtToC6MDhAATtuT70Sl+DymPCfDSsyV4w== caps: [mon] allow profile osd caps: [osd] allow *osd.1 key: AQC4CbtTCFJBChAAVq5spj0ff4eHZICxIOVZeA== caps: [mon] allow profile osd caps: [osd] allow *client.admin key: AQBHCbtT6APDHhAA5W00cBchwkQjh3dkKsyPjw== caps: [mds] allow caps: [mon] allow * caps: [osd] allow *client.bootstrap-mds key: AQBICbtTOK9uGBAAdbe5zcIGHZL3T/u2g6EBww== caps: [mon] allow profile bootstrap-mdsclient.bootstrap-osd key: AQBHCbtT4GxqORAADE5u7RkpCN/oo4e5W0uBtw== caps: [mon] allow profile bootstrap-osd

48 Gerenciando usuários SES 5

Nota: Notificação TYPE.IDObserve que a noticação TYPE.ID para usuários é aplicada de modo que osd.0especique um usuário do tipo osd e o ID seja 0 . client.admin é um usuário do tipoclient e o ID é admin . Observe também que cada entrada tem uma entrada key:value , e uma ou mais entradas caps: .

Você pode usar a opção -o nomedearquivo com ceph auth list para gravar a saídaem um arquivo.

5.2.2.2 Obtendo informações sobre usuários

Para recuperar um usuário, chave e recursos especícos, execute o seguinte:

ceph auth get TYPE.ID

Por exemplo:

ceph auth get client.adminexported keyring for client.admin[client.admin] key = AQA19uZUqIwkHxAAFuUwvq0eJD4S173oFRxe0g== caps mds = "allow" caps mon = "allow *" caps osd = "allow *"

Os desenvolvedores também podem executar o seguinte:

ceph auth export TYPE.ID

O comando auth export é idêntico a auth get , mas também imprime o ID de autenticaçãointerno.

5.2.2.3 Adicionando usuários

A adição de um usuário cria um nome de usuário ( TYPE.ID ), uma chave secreta e quaisquerrecursos incluídos no comando que você usa para criar o usuário.

A chave do usuário permite que ele se autentique no cluster de armazenamento do Ceph. Osrecursos do usuário lhe autorizam a ler, gravar ou executar Ceph Monitors (mon), Ceph OSDs(osd) ou servidores de metadados do Ceph (mds).

49 Gerenciando usuários SES 5

Há alguns comandos disponíveis para adicionar um usuário:

ceph auth add

Esse comando é a forma canônica de adicionar um usuário. Ele criará o usuário, geraráuma chave e adicionará quaisquer recursos especicados.

ceph auth get-or-create

Geralmente, esse comando é o método mais prático de criar um usuário, pois ele retornaum formato de arquivo de chaves com o nome de usuário (entre parênteses) e a chave. Seo usuário já existir, esse comando simplesmente retornará o nome de usuário e a chave noformato de arquivo de chaves. Você pode usar a opção -o nomedearquivo para gravara saída em um arquivo.

ceph auth get-or-create-key

Esse comando é um método prático de criar um usuário e retornar a chave dele (apenas).Ele é útil para clientes que precisam apenas da chave (por exemplo, libvirt ). Se ousuário já existir, esse comando retornará apenas a chave. Você pode usar a opção -onomedearquivo para gravar a saída em um arquivo.

Ao criar usuários de cliente, você pode criá-los sem recursos. Um usuário sem recursos podeapenas se autenticar, nada mais. Esse tipo de cliente não pode recuperar o mapa de cluster domonitor. No entanto, você pode criar um usuário sem recursos para adiar a adição de recursosusando o comando ceph auth caps .

Um usuário comum tem pelo menos recursos de leitura no Ceph Monitor e recursos de leiturae gravação nos Ceph OSDs. Além disso, as permissões de OSD do usuário costumam limitar-seao acesso a determinado pool.

root # ceph auth add client.john mon 'allow r' osd \ 'allow rw pool=liverpool'root # ceph auth get-or-create client.paul mon 'allow r' osd \ 'allow rw pool=liverpool'root # ceph auth get-or-create client.george mon 'allow r' osd \ 'allow rw pool=liverpool' -o george.keyringroot # ceph auth get-or-create-key client.ringo mon 'allow r' osd \ 'allow rw pool=liverpool' -o ringo.key

ImportanteSe você conceder a um usuário recursos para OSDs, mas não restringir o acesso adeterminados pools, o usuário terá acesso a todos os pools no cluster.

50 Gerenciando usuários SES 5

5.2.2.4 Modificando os recursos do usuário

O comando ceph auth caps permite especicar um usuário e mudar os recursos dele. Adenição de novos recursos sobregravará os atuais. Para ver os recursos atuais, execute cephauth get USERTYPE.USERID . Para adicionar recursos, você também precisa especicar osrecursos existentes quando usar o formato a seguir:

root # ceph auth caps USERTYPE.USERID daemon 'allow [r|w|x|*|...] \ [pool=pool-name] [namespace=namespace-name]' [daemon 'allow [r|w|x|*|...] \ [pool=pool-name] [namespace=namespace-name]']

Por exemplo:

root # ceph auth get client.johnroot # ceph auth caps client.john mon 'allow r' osd 'allow rw pool=prague'root # ceph auth caps client.paul mon 'allow rw' osd 'allow rwx pool=prague'root # ceph auth caps client.brian-manager mon 'allow *' osd 'allow *'

Para remover um recurso, você pode redeni-lo. Para que o usuário não tenha acesso adeterminado daemon já denido, especique uma string vazia:

root # ceph auth caps client.ringo mon ' ' osd ' '

5.2.2.5 Apagando usuários

Para apagar um usuário, execute ceph auth del :

root # ceph auth del TYPE.ID

em que TYPE é client , osd , mon ou mds , e ID é o nome de usuário ou o ID do daemon.

5.2.2.6 Imprimindo uma chave do usuário

Para imprimir a chave de autenticação do usuário em uma saída padrão, execute o seguinte:

root # ceph auth print-key TYPE.ID

em que TYPE é client , osd , mon ou mds , e ID é o nome de usuário ou o ID do daemon.

A impressão da chave do usuário é útil quando você precisa preencher o software cliente coma chave do usuário (como libvirt ), conforme mostrado neste exemplo:

cephadm > sudo mount -t ceph host:/ mount_point \

51 Gerenciando usuários SES 5

-o name=client.user,secret=`ceph auth print-key client.user`

5.2.2.7 Importando usuários

Para importar um ou mais usuários, execute ceph auth import e especique um chaveiro:

cephadm > sudo ceph auth import -i /etc/ceph/ceph.keyring

NotaO cluster de armazenamento do Ceph adicionará novos usuários, as chaves e os recursosdeles e atualizará os usuários existentes, as chaves e os recursos deles.

5.2.3 Gerenciamento de chaveiro

Quando você acessa o Ceph por um cliente, esse cliente procura um chaveiro local. Por padrão, oCeph predene a conguração de chaveiro com os quatro nomes de chaveiro a seguir, portanto,você não precisa deni-la em seu arquivo de conguração do Ceph, a menos que queira anularos padrões:

/etc/ceph/cluster.name.keyring/etc/ceph/cluster.keyring/etc/ceph/keyring/etc/ceph/keyring.bin

A metavariável cluster é o nome do cluster do Ceph conforme denido pelo nome do arquivode conguração do Ceph. ceph.conf signica que o nome do cluster é ceph , portanto,ceph.keyring . A metavariável name é o tipo e o ID de usuário. Por exemplo, client.admin ,portanto, ceph.client.admin.keyring .

Após criar um usuário (por exemplo, client.ringo ), você deverá obter a chave e adicioná-laa um chaveiro no cliente do Ceph para que o usuário possa acessar o cluster de armazenamentodo Ceph.

A Seção 5.2, “Gerenciamento de chaves” apresenta os detalhes de como listar, obter, adicionar,modicar e apagar usuários diretamente do cluster de armazenamento do Ceph. No entanto,o Ceph também oferece o utilitário ceph-authtool para que você possa gerenciar chaveirosde um cliente do Ceph.

52 Gerenciamento de chaveiro SES 5

5.2.3.1 Criando um chaveiro

Ao usar os procedimentos na Seção 5.2, “Gerenciamento de chaves” para criar usuários, você precisafornecer as chaves de usuário ao(s) cliente(s) do Ceph para permitir a recuperação da chavedo usuário especicado e a autenticação no cluster de armazenamento do Ceph. Os clientes doCeph acessam os chaveiros para pesquisar um nome de usuário e recuperar a chave do usuário:

cephadm > sudo ceph-authtool --create-keyring /path/to/keyring

Durante a criação de um chaveiro com vários usuários, é recomendável usar o nome do cluster(por exemplo, cluster .keyring) para o nome de arquivo do chaveiro e gravá-lo no diretório /etc/ceph para que a conguração padrão do chaveiro obtenha o nome do arquivo sem que vocêtenha que especicá-lo na cópia local do seu arquivo de conguração do Ceph. Por exemplo,crie ceph.keyring executando o seguinte:

cephadm > sudo ceph-authtool -C /etc/ceph/ceph.keyring

Durante a criação de um chaveiro com um único usuário, é recomendável usar o nome docluster, o tipo de usuário e o nome de usuário e gravá-lo no diretório /etc/ceph . Por exemplo,ceph.client.admin.keyring para o usuário client.admin .

5.2.3.2 Adicionando um usuário a um chaveiro

Ao adicionar um usuário ao cluster de armazenamento do Ceph (consulte a Seção  5.2.2.3,

“Adicionando usuários”), você pode recuperar o usuário, a chave e os recursos e gravá-lo em umchaveiro.

Para usar apenas um usuário por chaveiro, o comando ceph auth get com a opção -o gravaráa saída no formato de arquivo do chaveiro. Por exemplo, para criar um chaveiro para o usuárioclient.admin , execute o seguinte:

root # ceph auth get client.admin -o /etc/ceph/ceph.client.admin.keyring

Para importar usuários para um chaveiro, você pode usar ceph-authtool para especicar ochaveiro de destino e de origem:

cephadm > sudo ceph-authtool /etc/ceph/ceph.keyring \ --import-keyring /etc/ceph/ceph.client.admin.keyring

53 Gerenciamento de chaveiro SES 5

5.2.3.3 Criando um usuário

O Ceph inclui o comando ceph auth add para criar um usuário diretamente no cluster dearmazenamento do Ceph. No entanto, você também pode criar um usuário, as chaves e osrecursos diretamente em um chaveiro de cliente do Ceph. Em seguida, você pode importar ousuário para o cluster de armazenamento do Ceph:

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

Você também pode criar um chaveiro e adicionar um novo usuário a ele simultaneamente:

cephadm > sudo ceph-authtool -C /etc/ceph/ceph.keyring -n client.ringo \ --cap osd 'allow rwx' --cap mon 'allow rwx' --gen-key

Nos cenários anteriores, o novo usuário client.ringo está apenas no chaveiro. Para adicionaro novo usuário ao cluster de armazenamento do Ceph, você ainda deve adicioná-lo ao cluster:

cephadm > sudo ceph auth add client.ringo -i /etc/ceph/ceph.keyring

5.2.3.4 Modificando usuários

Para modicar os recursos do registro de um usuário em um chaveiro, especique o chaveiroe o usuário seguidos dos recursos:

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

Para atualizar o usuário modicado no ambiente de cluster do Ceph, você deve importar asmudanças do chaveiro para a entrada do usuário no cluster do Ceph:

root # ceph auth import -i /etc/ceph/ceph.keyring

Consulte a Seção  5.2.2.7, “Importando usuários” para obter detalhes sobre como atualizar umusuário do cluster de armazenamento do Ceph de um chaveiro.

54 Gerenciamento de chaveiro SES 5

5.2.4 Uso da linha de comando

O comando ceph suporta as seguintes opções relacionadas à manipulação de nome de usuárioe segredo:

--id ou --user

O Ceph identica os usuários com um tipo e um ID ( TYPE . ID , como client.admin ouclient.user1 ). As opções id , name e -n permitem especicar a parte do ID do nomede usuário (por exemplo, admin ou user1 ). Você pode especicar o usuário com --id eomitir o tipo. Por exemplo, para especicar o usuário client.foo, digite o seguinte:

root # ceph --id foo --keyring /path/to/keyring healthroot # ceph --user foo --keyring /path/to/keyring health

--name ou -n

O Ceph identica os usuários com um tipo e um ID ( TYPE . ID , como client.adminou client.user1 ). As opções --name e -n permitem especicar o nome completo dousuário. Você deve especicar o tipo de usuário (normalmente client ) com o ID deusuário:

root # ceph --name client.foo --keyring /path/to/keyring healthroot # ceph -n client.foo --keyring /path/to/keyring health

--keyring

O caminho para o chaveiro que contém um ou mais nomes de usuário e segredos. A opção--secret tem a mesma funcionalidade, mas não funciona com o Object Gateway, que usa--secret para outra nalidade. Você pode recuperar um chaveiro com ceph auth get-or-create e armazená-lo localmente. Essa é a abordagem preferencial, pois você podealternar nomes de usuário sem mudar o caminho do chaveiro:

cephadm > sudo rbd map --id foo --keyring /path/to/keyring mypool/myimage

55 Uso da linha de comando SES 5

6 Gerenciamento de dados armazenados

O algoritmo CRUSH determina como armazenar e recuperar dados calculando os locaisde armazenamento de dados. O CRUSH permite que os clientes do Ceph se comuniquemdiretamente com os OSDs, sem a necessidade de um servidor centralizado ou um controlador.Com um método de armazenamento e recuperação de dados determinado por algoritmo, o Cephevita um ponto único de falha, gargalo no desempenho e limite físico à escalabilidade.

O CRUSH requer um mapa do cluster e usa o Mapa CRUSH para armazenar e recuperar dadosde forma pseudo-aleatória nos OSDs com uma distribuição uniforme dos dados pelo cluster.

Os mapas CRUSH contêm uma lista de OSDs, uma lista de “compartimentos de memória”para agregar os dispositivos em locais físicos e uma lista de regras que orientam como oCRUSH deve replicar os dados nos pools de um cluster do Ceph. Ao reetir a organizaçãofísica adjacente da instalação, o CRUSH pode moldar (e, portanto, resolver) fontes potenciais defalhas de dispositivos correlacionados. As fontes comuns incluem proximidade física, fonte deenergia compartilhada e rede compartilhada. Ao codicar essas informações no mapa do cluster,as políticas de posicionamento do CRUSH podem separar réplicas de objetos em diferentesdomínios de falha enquanto ainda mantêm a distribuição desejada. Por exemplo, para evitara possibilidade de falhas simultâneas, convém usar diferentes prateleiras, racks, fontes dealimentação, controladoras e/ou locais físicos para os dispositivos nos quais as réplicas de dadossão armazenadas.

Depois que você implantar um cluster do Ceph, um Mapa CRUSH padrão será gerado. Isso é bompara o seu ambiente de área de segurança do Ceph. No entanto, ao implantar um cluster de dadosem grande escala, você deve considerar signicativamente o desenvolvimento de um MapaCRUSH personalizado, pois ele o ajudará a gerenciar o cluster do Ceph, melhorar o desempenhoe garantir a segurança dos dados.

Por exemplo, se um OSD car inativo, um Mapa CRUSH poderá ajudá-lo a localizar o data centerfísico, a sala, a leira e o rack do host com o OSD que falhou, caso seja necessário usar o suporteno local ou substituir o hardware.

Da mesma forma, o CRUSH pode ajudá-lo a identicar falhas mais rapidamente. Por exemplo,se todos os OSDs em determinado rack carem inativos ao mesmo tempo, a falha poderá estarassociada ao comutador de rede ou à energia que abastece o rack, e não aos próprios OSDs.

O Mapa CRUSH personalizado também pode ajudá-lo a identicar os locais físicos onde o Cepharmazena as cópias redundantes de dados, quando o(s) grupo(s) de posicionamento associado(s)ao host com falha está(ão) prejudicado(s).

56 SES 5

Há três seções principais para um Mapa CRUSH.

Dispositivos representam qualquer dispositivo de armazenamento de objetos, ou seja, odisco rígido correspondente a um daemon ceph-osd .

Compartimentos de memória representam uma agregação hierárquica de locais dearmazenamento (por exemplo, leiras, racks, hosts, etc.) e seus pesos atribuídos.

Conjuntos de regras representam o modo de seleção dos compartimentos de memória.

6.1 DispositivosPara mapear os grupos de posicionamento para OSDs, o Mapa CRUSH requer uma lista dedispositivos OSD (o nome do daemon OSD). A lista de dispositivos aparece primeiro no MapaCRUSH.

#devicesdevice num osd.name

Por exemplo:

#devicesdevice 0 osd.0device 1 osd.1device 2 osd.2device 3 osd.3

Como regra geral, um daemon OSD é mapeado para um único disco.

6.2 Compartimentos de memóriaOs mapas CRUSH contêm uma lista de OSDs, que podem ser organizados em “compartimentosde memória” para agregar os dispositivos em locais físicos.

0 OSD Um daemon OSD (osd.1, osd.2, etc.).

1 Host Um nome de host que contém um ou mais OSDs.

57 Dispositivos SES 5

2 Chassis Chassis que compõe o rack.

3 Rack Um rack de computador. O padrão é unknownrack .

4 Fileira Uma leira em uma série de racks.

5 Pdu Unidade de distribuição de energia.

6 Pod

7 Sala Uma sala com racks e leiras de hosts.

8 Data center Um data center físico com salas.

9 Região

10 Root

DicaVocê pode remover esses tipos e criar seus próprios tipos de compartimento de memória.

As ferramentas de implantação do Ceph geram um Mapa CRUSH que contém um compartimentode memória para cada host e um pool denominado “default”, que é útil para o pool rbd padrão.Os tipos de compartimento de memória restantes oferecem um meio de armazenar informaçõessobre o local físico dos nós/compartimentos de memória, o que facilita bastante a administraçãodo cluster em caso de mal funcionamento dos OSDs, dos hosts ou do hardware de rede e quandoo administrador precisa acessar o hardware físico.

Um compartimento de memória tem um tipo, um nome exclusivo (string), um ID único indicadopor um número inteiro negativo, um peso relativo à capacidade total do(s) item(ns), o algoritmodo compartimento de memória (por padrão, straw ) e o hash (por padrão, 0 , reetindo o HashCRUSH rjenkins1 ). Um compartimento de memória pode ter um ou mais itens. Os itens podemser constituídos de outros compartimentos de memória ou OSDs. Os itens podem ter um pesoque reete o peso relativo do item.

[bucket-type] [bucket-name] { id [a unique negative numeric ID] weight [the relative capacity/capability of the item(s)] alg [the bucket type: uniform | list | tree | straw ] hash [the hash type: 0 by default]

58 Compartimentos de memória SES 5

item [item-name] weight [weight]}

O exemplo a seguir ilustra como você pode usar compartimentos de memória para agregar umpool e locais físicos, como data center, sala, rack e leira.

host ceph-osd-server-1 { id -17 alg straw hash 0 item osd.0 weight 1.00 item osd.1 weight 1.00}

row rack-1-row-1 { id -16 alg straw hash 0 item ceph-osd-server-1 weight 2.00}

rack rack-3 { id -15 alg straw hash 0 item rack-3-row-1 weight 2.00 item rack-3-row-2 weight 2.00 item rack-3-row-3 weight 2.00 item rack-3-row-4 weight 2.00 item rack-3-row-5 weight 2.00}

rack rack-2 { id -14 alg straw hash 0 item rack-2-row-1 weight 2.00 item rack-2-row-2 weight 2.00 item rack-2-row-3 weight 2.00 item rack-2-row-4 weight 2.00 item rack-2-row-5 weight 2.00}

rack rack-1 { id -13 alg straw hash 0

59 Compartimentos de memória SES 5

item rack-1-row-1 weight 2.00 item rack-1-row-2 weight 2.00 item rack-1-row-3 weight 2.00 item rack-1-row-4 weight 2.00 item rack-1-row-5 weight 2.00}

room server-room-1 { id -12 alg straw hash 0 item rack-1 weight 10.00 item rack-2 weight 10.00 item rack-3 weight 10.00}

datacenter dc-1 { id -11 alg straw hash 0 item server-room-1 weight 30.00 item server-room-2 weight 30.00}

pool data { id -10 alg straw hash 0 item dc-1 weight 60.00 item dc-2 weight 60.00}

6.3 Conjuntos de regras

Os mapas CRUSH suportam a noção de “regras CRUSH”, que determinam o posicionamento dosdados em um pool. Para clusters grandes, convém criar muitos pools, em que cada um pode terseu próprio conjunto de regras CRUSH e suas próprias regras. O Mapa CRUSH padrão tem umaregra para cada pool e um conjunto de regras atribuído a cada um dos pools padrão.

60 Conjuntos de regras SES 5

NotaNa maioria dos casos, você não precisará modicar as regras padrão. Quando você criaum novo pool, o conjunto de regras padrão dele é 0.

Uma regra apresenta o seguinte formato:

rule rulename {

ruleset ruleset type type min_size min-size max_size max-size step step

}

ruleset

Um número inteiro. Classica uma regra como pertencente a um conjunto de regras.Ativado quando o conjunto de regras é denido em um pool. Essa opção é obrigatória.O padrão é 0 .

ImportanteVocê precisa aumentar o número do conjunto de regras do padrão 0 continuamente;do contrário, o monitor relacionado poderá falhar.

type

Uma string. Descreve uma regra para um disco rígido (replicado) ou um RAID. Essa opçãoé obrigatória. O padrão é replicado .

min_size

Um número inteiro. Se um grupo de posicionamento gerar menos réplicas do que essenúmero, o CRUSH NÃO selecionará essa regra. Essa opção é obrigatória. O padrão é 2 .

max_size

Um número inteiro. Se um grupo de posicionamento gerar mais réplicas do que essenúmero, o CRUSH NÃO selecionará essa regra. Essa opção é obrigatória. O padrão é 10 .

61 Conjuntos de regras SES 5

step take bucket

Usa um nome de compartimento de memória e inicia a iteração descendente na árvore.Essa opção é obrigatória. Para obter uma explicação sobre iteração na árvore, consulte aSeção 6.3.1, “Iteração pela árvore de nós”.

step target mode num type bucket-type

target pode ser choose ou chooseleaf . Quando denido como choose , um númerode compartimentos de memória é selecionado. chooseleaf seleciona diretamente osOSDs (nós folha) da subárvore de cada compartimento de memória no conjunto decompartimentos de memória.mode pode ser firstn ou indep . Consulte a Seção 6.3.2, “firstn e indep”.Seleciona o número de compartimentos de memória de determinado tipo. Em que N é onúmero de opções disponíveis, se num > 0 && < N, escolha essa mesma quantidade decompartimentos de memória; se num < 0, isso signica N - num e, se num == 0, escolhaN compartimentos de memória (todos disponíveis). Segue step take ou step choose .

step emit

Gera o valor atual e esvazia a pilha. Normalmente usado no m de uma regra, mas tambémpode ser usado para estruturar árvores diferentes na mesma regra. Segue step choose .

ImportantePara ativar uma ou mais regras com um número comum do conjunto de regras para umpool, dena o número do conjunto de regras para o pool.

6.3.1 Iteração pela árvore de nós

É possível ver a estrutura denida com os compartimentos de memória como uma árvore denós. Os compartimentos de memória são os nós, e os OSDs são as folhas da árvore.

As regras no Mapa CRUSH denem como os OSDs são selecionados dessa árvore. Uma regracomeça com um nó e, em seguida, faz a iteração descendente pela árvore para retornar umconjunto de OSDs. Não é possível denir qual ramicação precisa ser selecionada. Em vezdisso, o algoritmo CRUSH garante que o conjunto de OSDs atende aos requisitos de replicaçãoe distribui os dados igualmente.

62 Iteração pela árvore de nós SES 5

Com step take bucket , a iteração pela árvore de nós começa no compartimento de memóriaespecicado (sem tipo de compartimento de memória). Se os OSDs de todas as ramicações naárvore tiverem que ser retornados, o compartimento de memória deverá ser a raiz. Do contrário,as etapas a seguir apenas fará a iteração na subárvore.

Após step take , uma ou mais entradas step choose vêm a seguir na denição da regra. Cadastep choose escolhe um número denido de nós (ou ramicações) do nó superior selecionadoanteriormente.

No m, os OSDs selecionados são retornados com step emit .

step chooseleaf é uma prática função que seleciona os OSDs diretamente das ramicaçõesdo compartimento de memória especicado.

A Figura 6.1, “Exemplo de árvore” mostra um exemplo de como o step é usado para iterar em umaárvore. As setas e os números laranjas correspondem a example1a e example1b , e os azuiscorrespondem a example2 nas denições de regra a seguir.

FIGURA 6.1: EXEMPLO DE ÁRVORE

# orange arrowsrule example1a { ruleset 0 type replicated min_size 2 max_size 10 # orange (1)

63 Iteração pela árvore de nós SES 5

step take rack1 # orange (2) step choose firstn 0 host # orange (3) step choose firstn 1 osd step emit}

rule example1b { ruleset 0 type replicated min_size 2 max_size 10 # orange (1) step take rack1 # orange (2) + (3) step chooseleaf firstn 0 host step emit}

# blue arrowsrule example2 { ruleset 0 type replicated min_size 2 max_size 10 # blue (1) step take room1 # blue (2) step chooseleaf firstn 0 rack step emit}

6.3.2 firstn e indep

Uma regra CRUSH dene substituições para nós ou OSDs com falha (consulte a Seção  6.3,

“Conjuntos de regras”). A palavra-chave step requer firstn ou indep como parâmetro. AFigura 6.2, “Métodos de substituição de nó” apresenta um exemplo.

O firstn adiciona nós de substituição ao m da lista de nós ativos. No caso de um nó comfalha, os seguintes nós saudáveis são deslocados para a esquerda para preencher a lacuna do nócom falha. Esse é o método padrão desejado para pools replicados, porque um nó secundário játem todos os dados e, portanto, pode assumir as tarefas do nó principal imediatamente.

64 firstn e indep SES 5

O indep seleciona nós de substituição xos para cada nó ativo. A substituição de um nó comfalha não muda a ordem dos nós restantes. Esse é o método desejado para pools com codicaçãode eliminação. Nos pools com codicação de eliminação, os dados armazenados em um nódependem da posição dele na seleção do nó. Quando a ordem dos nós muda, todos os dadosnos nós afetados precisam ser realocados.

Nota: Pools de eliminaçãoVerique se uma regra que usa indep foi denida para cada pool com codicação deeliminação.

osd.b

osd.b

FIGURA 6.2: MÉTODOS DE SUBSTITUIÇÃO DE NÓ

6.4 Manipulação de mapa CRUSH

Esta seção apresenta os modos de manipulação do Mapa CRUSH básico. Por exemplo, editar umMapa CRUSH, mudar parâmetros do Mapa CRUSH e adicionar/mover/remover um OSD.

65 Manipulação de mapa CRUSH SES 5

6.4.1 Editando um mapa CRUSH

Para editar um mapa CRUSH existente, faça o seguinte:

1. Obtenha um Mapa CRUSH. Para obter o Mapa CRUSH para seu cluster, execute o seguinte:

root # ceph osd getcrushmap -o compiled-crushmap-filename

O Ceph gerará ( -o ) um Mapa CRUSH compilado com o nome de arquivo que vocêespecicou. Como o Mapa CRUSH está em um formato compilado, você deve descompilá-lo antes que você possa editá-lo.

2. Descompile um Mapa CRUSH. Para descompilar um Mapa CRUSH, execute o seguinte:

cephadm > crushtool -d compiled-crushmap-filename \ -o decompiled-crushmap-filename

O Ceph descompilará ( -d ) o Mapa CRUSH compilado e o gerará ( -o ) com o nome dearquivo que você especicou.

3. Edite pelo menos um dos parâmetros de Dispositivos, Compartimentos de Memória eRegras.

4. Compile um Mapa CRUSH. Para compilar um Mapa CRUSH, execute o seguinte:

cephadm > crushtool -c decompiled-crush-map-filename \ -o compiled-crush-map-filename

O Ceph armazenará um Mapa CRUSH compilado com o nome de arquivo que vocêespecicou.

5. Dena um Mapa CRUSH. Para denir o Mapa CRUSH para o cluster, execute o seguinte:

root # ceph osd setcrushmap -i compiled-crushmap-filename

O Ceph inserirá o Mapa CRUSH compilado do nome de arquivo que você especicou comoo Mapa CRUSH para o cluster.

6.4.2 Adicionar/Mover um OSD

Para adicionar ou mover um OSD no Mapa CRUSH de um cluster em execução, faça o seguinte:

root # ceph osd crush set id_or_name weight root=pool-name

66 Editando um mapa CRUSH SES 5

bucket-type=bucket-name ...

id

Um número inteiro. O ID numérico do OSD. Essa opção é obrigatória.

name

Uma string. O nome completo do OSD. Essa opção é obrigatória.

weight

Um duplo. O peso do CRUSH para o OSD. Essa opção é obrigatória.

pool

Um par de chave/valor. Por padrão, a hierarquia do CRUSH contém o pool padrão comoraiz. Essa opção é obrigatória.

bucket-type

Pares de chave/valor. Você pode especicar o local do OSD na hierarquia do CRUSH.

O exemplo a seguir adiciona osd.0 à hierarquia ou move o OSD de um local anterior.

root # ceph osd crush set osd.0 1.0 root=data datacenter=dc1 room=room1 \row=foo rack=bar host=foo-bar-1

6.4.3 Ajustar o peso do CRUSH de um OSD

Para ajustar o peso do CRUSH de um OSD no Mapa CRUSH de um cluster em execução, façao seguinte:

root # ceph osd crush reweight name weight

name

Uma string. O nome completo do OSD. Essa opção é obrigatória.

weight

Um duplo. O peso do CRUSH para o OSD. Essa opção é obrigatória.

6.4.4 Remover um OSD

Para remover um OSD do Mapa CRUSH de um cluster em execução, faça o seguinte:

root # ceph osd crush remove name

67 Ajustar o peso do CRUSH de um OSD SES 5

name

Uma string. O nome completo do OSD. Essa opção é obrigatória.

6.4.5 Mover um compartimento de memória

Para mover um compartimento de memória para outro local ou posição na hierarquia do mapaCRUSH, execute o seguinte:

root # ceph osd crush move bucket-name bucket-type=bucket-name, ...

bucket-name

Uma string. O nome do compartimento de memória para mover/reposicionar. Essa opçãoé obrigatória.

bucket-type

Pares de chave/valor. Você pode especicar o local do compartimento de memória nahierarquia do CRUSH.

6.5 DepuraçãoAlém de gerar várias cópias dos objetos, o Ceph garante a integridade dos dados por meio dadepuração dos grupos de posicionamento. A depuração do Ceph equivale à execução do fsckna camada de armazenamento de objetos. Para cada grupo de posicionamento, o Ceph geraum catálogo de todos os objetos e compara cada objeto principal e suas réplicas para garantirque nenhum objeto esteja ausente ou seja incompatível. A depuração diária simples verica otamanho e os atributos dos objetos, enquanto a depuração semanal profunda lê os dados e usachecksums para garantir a integridade dos dados.

A depuração é importante para manter a integridade dos dados, mas ela pode reduzir odesempenho. Você pode ajustar as seguintes congurações para aumentar ou diminuir asoperações de depuração:

osd max scrubs

O número máximo de operações de depuração simultâneas para o Ceph OSD. O padrão é 1.

osd scrub begin hour , osd scrub end hour

As horas do dia (0 a 24) que denem o intervalo para a execução da depuração. Por padrão,ela começa em 0 e termina em 24.

68 Mover um compartimento de memória SES 5

ImportanteSe o intervalo de depuração do grupo de posicionamento exceder a conguraçãoosd scrub max interval , a depuração será executada independentemente dointervalo denido para ela.

osd scrub during recovery

Permite depurações durante a recuperação. Ao deni-la como “false”, a programação denovas depurações é desabilitada durante uma recuperação ativa. As depurações que jáestão em execução continuam. Essa opção é útil para reduzir a carga em clusters ocupados.O padrão é “true”.

osd scrub thread timeout

O tempo máximo em segundos antes que um thread de depuração esgote o tempo deespera. O padrão é 60.

osd scrub finalize thread timeout

O tempo máximo em segundos antes que um thread de nalização da depuração esgoteo tempo de espera. O padrão é 60*10.

osd scrub load threshold

A carga máxima normalizada. O Ceph não efetuará a depuração quando a carga do sistema(conforme denido pela proporção de getloadavg() /número de cpus online ) forsuperior a esse número. O padrão é 0.5.

osd scrub min interval

O intervalo mínimo em segundos para depuração do Ceph OSD quando a carga do clusterdo Ceph está baixa. O padrão é 60*60*24 (uma vez por dia).

osd scrub max interval

O intervalo máximo em segundos para depuração do Ceph OSD independentemente dacarga do cluster. 7*60*60*24 (uma vez por semana).

osd scrub chunk min

O número mínimo de pacotes de armazenamento de objetos para depurar durante umaúnica operação. O Ceph bloqueia as gravações em um único pacote durante a depuração.O padrão é 5.

69 Depuração SES 5

osd scrub chunk max

O número máximo de pacotes de armazenamento de objetos para depurar durante umaúnica operação. O padrão é 25.

osd scrub sleep

O tempo em modo adormecido antes da depuração do próximo grupo de pacotes. Oaumento desse valor desacelera toda a operação de depuração, enquanto as operações decliente são menos afetadas. O padrão é 0.

osd deep scrub interval

O intervalo da depuração “profunda” (com leitura completa de todos os dados). A opçãoosd scrub load threshold não afeta essa conguração. O padrão é 60*60*24*7 (umavez por semana).

osd scrub interval randomize ratio

Adicione um atraso aleatório ao valor osd scrub min interval ao programar apróxima tarefa de depuração para um grupo de posicionamento. O atraso é um valoraleatório menor do que o resultado de osd scrub min interval * osd scrub

interval randomized ratio . Portanto, a conguração padrão distribui as depuraçõesquase aleatoriamente dentro do período permitido de [1, 1,5] * osd scrub min interval .O padrão é 0.5

osd deep scrub stride

Tamanho da leitura ao efetuar uma depuração profunda. O padrão é 524288 (512 KB).

6.6 SSDs e HDDs combinadas no mesmo nóConvém congurar um cluster do Ceph de modo que cada nó tenha uma combinação de SSDse HDDs, com um pool de armazenamento em SSDs rápidas e outro em HDDs mais lentas. Paraisso, o Mapa CRUSH precisa ser editado.

O Mapa CRUSH padrão terá uma hierarquia simples, na qual a raiz padrão incluirá hosts e oshosts incluirão OSDs. Por exemplo:

root # ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 83.17899 root default -4 23.86200 host cpach 2 hdd 1.81898 osd.2 up 1.00000 1.00000 3 hdd 1.81898 osd.3 up 1.00000 1.00000

70 SSDs e HDDs combinadas no mesmo nó SES 5

4 hdd 1.81898 osd.4 up 1.00000 1.00000 5 hdd 1.81898 osd.5 up 1.00000 1.00000 6 hdd 1.81898 osd.6 up 1.00000 1.00000 7 hdd 1.81898 osd.7 up 1.00000 1.00000 8 hdd 1.81898 osd.8 up 1.00000 1.00000 15 hdd 1.81898 osd.15 up 1.00000 1.00000 10 nvme 0.93100 osd.10 up 1.00000 1.00000 0 ssd 0.93100 osd.0 up 1.00000 1.00000 9 ssd 0.93100 osd.9 up 1.00000 1.00000

Isso não faz distinção entre tipos de disco. Para dividir os OSDs em SSDs e HDDs, precisamoscriar uma segunda hierarquia no Mapa CRUSH:

root # ceph osd crush add-bucket ssd root

Após criar a nova raiz para SSDs, precisaremos adicionar hosts a ela. Isso signica a criaçãode novas entradas de host. No entanto, como o mesmo nome de host não pode aparecer maisdo que uma vez no Mapa CRUSH, nomes de host falsos são usados. Esses nomes de host falsosnão precisam ser resolvidos por DNS. O CRUSH não leva em consideração quais são os nomesde host, ele apenas precisa criar as hierarquias certas. A única coisa que realmente precisa sermudada para suportar nomes de host falsos é que você deve denir

osd crush update on start = false

no arquivo /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf e, emseguida, executar a Fase 3 do DeepSea para distribuir a mudança (consulte a Seção 1.11, “Arquivo

ceph.conf personalizado” para obter mais informações):

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

Do contrário, os OSDs que você mover serão depois redenidos ao seu local original na raizpadrão, e o cluster não terá o comportamento esperado.

Depois que essa conguração for mudada, adicione os novos hosts falsos à raiz da SSD:

root # ceph osd crush add-bucket node1-ssd hostroot # ceph osd crush move node1-ssd root=ssdroot # ceph osd crush add-bucket node2-ssd hostroot # ceph osd crush move node2-ssd root=ssdroot # ceph osd crush add-bucket node3-ssd hostroot # ceph osd crush move node3-ssd root=ssd

Por m, para cada OSD de SSD, mova o OSD para a raiz da SSD. Neste exemplo, consideramosque osd.0, osd.1 e osd.2 estão sicamente hospedados em SSDs:

root # ceph osd crush add osd.0 1 root=ssd

71 SSDs e HDDs combinadas no mesmo nó SES 5

root # ceph osd crush set osd.0 1 root=ssd host=node1-ssdroot # ceph osd crush add osd.1 1 root=ssdroot # ceph osd crush set osd.1 1 root=ssd host=node2-ssdroot # ceph osd crush add osd.2 1 root=ssdroot # ceph osd crush set osd.2 1 root=ssd host=node3-ssd

A hierarquia do CRUSH deve ter esta aparência:

root # ceph osd treeID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY-5 3.00000 root ssd-6 1.00000 host node1-ssd 0 1.00000 osd.0 up 1.00000 1.00000-7 1.00000 host node2-ssd 1 1.00000 osd.1 up 1.00000 1.00000-8 1.00000 host node3-ssd 2 1.00000 osd.2 up 1.00000 1.00000-1 0.11096 root default-2 0.03699 host node1 3 0.01849 osd.3 up 1.00000 1.00000 6 0.01849 osd.6 up 1.00000 1.00000-3 0.03699 host node2 4 0.01849 osd.4 up 1.00000 1.00000 7 0.01849 osd.7 up 1.00000 1.00000-4 0.03699 host node3 5 0.01849 osd.5 up 1.00000 1.00000 8 0.01849 osd.8 up 1.00000 1.00000

Agora, crie uma regra CRUSH direcionada à raiz da SSD:

root # ceph osd crush rule create-simple ssd_replicated_ruleset ssd host

O replicated_ruleset padrão original (com ID 0) será direcionado às HDDs. O novossd_replicated_ruleset (com ID 1) será direcionado às SSDs.

Quaisquer pools existentes ainda usarão as HDDs, pois elas estão na hierarquia padrão no MapaCRUSH. Um novo pool pode ser criado para usar apenas as SSDs:

root # ceph osd pool create ssd-pool 64 64root # ceph osd pool set ssd-pool crush_rule ssd_replicated_ruleset

72 SSDs e HDDs combinadas no mesmo nó SES 5

7 Gerenciando pools de armazenamento

O Ceph armazena dados em pools. Pools são grupos lógicos para armazenamento de objetos.Quando você implanta um cluster pela primeira vez sem criar um pool, o Ceph usa os poolspadrão para armazenar os dados. Um pool oferece a você:

Resiliência: Agora você pode denir quantos OSDs podem falhar sem perda de dados. Paraos pools replicados, esse é o número desejado de cópias/réplicas de um objeto. Novos poolssão criados com um total padrão de réplicas denido como 3. Como a conguração típicaarmazena um objeto e uma cópia adicional, você precisa denir o total de réplicas como2. Para os pools com codicação de eliminação, esse é o número de pacotes de codicação(que é m=2 no perl de codicação de eliminação).

Grupos de Posicionamento: São estruturas internas de dados para armazenar dados em umpool em vários OSDs. O modo como o Ceph armazena os dados nos PGs é denido emum Mapa CRUSH. Você pode denir o número de grupos de posicionamento para o pool.Uma conguração típica usa aproximadamente 100 grupos de posicionamento por OSDpara possibilitar o equilíbrio ideal sem usar muitos recursos de computação. Ao congurarvários pools, tenha cuidado para garantir que você dena um número adequado de gruposde posicionamento para o pool e o cluster como um todo.

Regras CRUSH: Quando você armazena dados em um pool, um conjunto de regras CRUSHmapeado para o pool permite que o CRUSH identique uma regra para o posicionamentodo objeto e suas réplicas (ou pacotes para os pools com codicação de eliminação) nocluster. Você pode criar uma regra CRUSH personalizada para o pool.

Instantâneos: Ao criar instantâneos com ceph osd pool mksnap , você efetivamentecaptura um instantâneo de determinado pool.

Denir Propriedade: Você pode denir um ID de usuário como proprietário de um pool.

Para organizar dados em pools, você pode listar, criar e remover pools. Você também pode veras estatísticas de uso para cada pool.

73 SES 5

7.1 Associar pools a um aplicativo

Antes de usar os pools, você precisa associá-los a um aplicativo. Os pools que serão usadoscom o CephFS ou os pools criados automaticamente pelo Object Gateway são associados deforma automática. Os pools planejados para uso com o RBD precisam ser inicializados usandoa ferramenta rbd (consulte a Seção  8.1, “Comandos do dispositivo de blocos” para obter maisinformações).

Nos outros casos, você pode associar manualmente um nome de aplicativo de formato livre aum pool:

root # ceph osd pool application enable pool_name application_name

Dica: Nomes de aplicativos padrãoO CephFS usa o nome do aplicativo cephfs , o Dispositivo de Blocos RADOS usa o rbde o Object Gateway usa o rgw .

É possível associar um pool a vários aplicativos, e cada aplicativo tem seus próprios metadados.Você pode exibir os metadados do aplicativo para determinado pool usando o seguinte comando:

root # ceph osd pool application get pool_name

7.2 Pools operacionais

Esta seção apresenta informações práticas para realizar tarefas básicas com pools. Vocêaprenderá como listar, criar e apagar pools, bem como mostrar as estatísticas ou gerenciarinstantâneos de um pool.

7.2.1 Listar pools

Para listar os pools do cluster, execute:

root # ceph osd lspools0 rbd, 1 photo_collection, 2 foo_pool,

74 Associar pools a um aplicativo SES 5

7.2.2 Criar um pool

Para criar um pool replicado, execute:

root # ceph osd pool create pool_name pg_num pgp_num replicated crush_ruleset_name \expected_num_objects

Para criar um pool com codicação de eliminação, execute:

root # ceph osd pool create pool_name pg_num pgp_num erasure erasure_code_profile \ crush_ruleset_name expected_num_objects

O ceph osd pool create poderá falhar se você exceder o limite de grupos de posicionamentopor OSD. O limite é denido com a opção mon_max_pg_per_osd .

pool_name

O nome do pool. Ele deve ser exclusivo. Essa opção é obrigatória.

pg_num

O número total de grupos de posicionamento para o pool. Essa opção é obrigatória. Ovalor padrão é 8.

pgp_num

O número total de grupos de posicionamento para ns de posicionamento. Ele deve serigual ao número total de grupos de posicionamento, exceto para cenários de divisão degrupo de posicionamento. Essa opção é obrigatória. O valor padrão é 8.

pgp_type

O tipo de pool, que pode ser replicated para recuperação de OSDs perdidos mantendo váriascópias dos objetos, ou erasure para aplicar um tipo de recurso RAID5 generalizado. Os poolsreplicados exigem mais armazenamento bruto, porém implementam todas as operações doCeph. Os pools com codicação de eliminação exigem menos armazenamento bruto, porémimplementam apenas um subconjunto de operações disponíveis. O padrão é “replicated”.

crush_ruleset_name

O nome do conjunto de regras CRUSH para este pool. Se o conjunto de regras especicadonão existir, haverá falha na criação do pool replicado com -ENOENT. No entanto, o poolreplicado criará um novo conjunto de regras de eliminação com o nome especicado.O valor padrão é “erasure-code” para um pool com codicação de eliminação. Coleta avariável de conguração do Ceph osd_pool_default_crush_replicated_ruleset parao pool replicado.

75 Criar um pool SES 5

erasure_code_profile=profile

Apenas para pools com codicação de eliminação. Use o perl de codicação deeliminação. Ele deve ser um perl existente, conforme denido por osd erasure-code-profile set .Ao criar um pool, dena o número de grupos de posicionamento como um valor adequado(por exemplo, 100). Considere também o número total de grupos de posicionamento porOSD. Os grupos de posicionamento são onerosos em termos de computação, portanto,o desempenho será prejudicado se você tiver muitos pools com vários grupos deposicionamento (por exemplo, 50 pools com 100 grupos de posicionamento cada). O pontodo rendimento regressivo depende da capacidade do host OSD.Consulte Grupos de Posicionamento (http://docs.ceph.com/docs/master/rados/operations/

placement-groups/) para obter detalhes sobre como calcular um número apropriado degrupos de posicionamento para seu pool.

expected_num_objects

O número esperado de objetos para este pool. Ao denir esse valor, a divisão da pastado PG ocorre no momento da criação do pool. Isso evita o impacto da latência com umadivisão de pasta em tempo de execução.

7.2.3 Definir cotas do pool

Você pode denir cotas do pool para o número máximo de bytes e/ou para o número máximode objetos por pool.

root # ceph osd pool set-quota pool-name max_objects obj-count max_bytes bytes

Por exemplo:

root # ceph osd pool set-quota data max_objects 10000

Para remover uma cota, dena o valor como 0.

7.2.4 Apagar um pool

Atenção: A exclusão do pool não é reversívelOs pools podem conter dados importantes. Apagar um pool faz com que todos os dadosnele desapareçam, e não é possível recuperá-los.

76 Definir cotas do pool SES 5

Como a exclusão acidental do pool é um perigo real, o Ceph implementa dois mecanismos queimpedem que os pools sejam apagados. Os dois mecanismos devem ser desabilitados antes queum pool possa ser apagado.

O primeiro mecanismo é o ag NODELETE . Cada pool tem esse ag, e seu valor padrão é “false”.Para saber o valor desse ag em um pool, execute o seguinte comando:

root # ceph osd pool get pool_name nodelete

Se a saída for nodelete: true , não será possível apagar o pool até você mudar o ag usandoo seguinte comando:

ceph osd pool set pool_name nodelete false

O segundo mecanismo é o parâmetro de conguração de todo o cluster mon allow pool

delete , que assume como padrão “false”. Por padrão, isso signica que não é possível apagarum pool. A mensagem de erro exibida é:

Error EPERM: pool deletion is disabled; you must first set themon_allow_pool_delete config option to true before you can destroy a pool

Para apagar o pool mesmo com essa conguração de segurança, você pode denir mon allowpool delete temporariamente como “true”, apagar o pool e, em seguida, reverter o parâmetropara “false”:

root # ceph tell mon.* injectargs --mon-allow-pool-delete=trueroot # ceph osd pool delete pool_name pool_name --yes-i-really-really-mean-itroot # ceph tell mon.* injectargs --mon-allow-pool-delete=false

O comando injectargs exibe a seguinte mensagem:

injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)

Trata-se apenas de uma conrmação de que o comando foi executado com êxito. Isso não éum erro.

Se você criou seus próprios conjuntos de regras e suas próprias regras para um pool, convémremovê-los quando ele não for mais necessário. Se você criou usuários com permissõesestritamente para um pool que não existe mais, convém apagá-los também.

7.2.5 Renomear um pool

Para renomear um pool, execute:

root # ceph osd pool rename current-pool-name new-pool-name

77 Renomear um pool SES 5

Se você renomear um pool e tiver recursos por pool para um usuário autenticado, deveráatualizar os recursos do usuário com o novo nome do pool.

7.2.6 Mostrar as estatísticas do pool

Para mostrar as estatísticas de uso de um pool, execute:

root # rados dfpool name category KB objects lones degraded unfound rd rd KB wr wr KBcold-storage - 228 1 0 0 0 0 0 1 228data - 1 4 0 0 0 0 0 4 4hot-storage - 1 2 0 0 0 15 10 5 231metadata - 0 0 0 0 0 0 0 0 0pool1 - 0 0 0 0 0 0 0 0 0rbd - 0 0 0 0 0 0 0 0 0total used 266268 7total avail 27966296total space 28232564

7.2.7 Definir os valores do pool

Para denir um valor para um pool, execute:

root # ceph osd pool set pool-name key value

Você pode denir valores para as seguintes chaves:

size

Dene o número de réplicas para os objetos no pool. Consulte a Seção 7.2.9, “Definir o número

de réplicas do objeto” para obter mais detalhes. Apenas pools replicados.

min_size

Dene o número mínimo de réplicas necessárias para E/S. Consulte a Seção 7.2.9, “Definir o

número de réplicas do objeto” para obter mais detalhes. Apenas pools replicados.

crash_replay_interval

O número de segundos para permitir que os clientes reproduzam solicitações conrmadas,mas não comprometidas.

78 Mostrar as estatísticas do pool SES 5

pg_num

O número de grupos de posicionamento para o pool. Se você adicionar OSDs ao cluster,deverá aumentar o valor de grupos de posicionamento. Para obter detalhes, consulte aSeção 7.2.11, “Aumentando o número de grupos de posicionamento”.

pgp_num

O número efetivo de grupos de posicionamento a ser usado ao calcular o posicionamentodos dados.

crush_ruleset

O conjunto de regras a ser usado para mapear o posicionamento de objetos no cluster.

hashpspool

Dena (1) ou não dena (0) o ag HASHPSPOOL em um pool especíco. A habilitaçãodesse ag muda o algoritmo para distribuir melhor os PGs pelos OSDs. Após a habilitaçãodesse ag em um pool com o ag HASHPSPOOL denido como 0, o cluster iniciará opreenchimento para reposicionar todos os PGs corretamente. Saiba que isso pode geraruma carga considerável de E/S em um cluster, portanto, é necessário realizar um bomplanejamento em clusters de produção altamente carregados.

nodelete

Impede que o pool seja removido.

nopgchange

Impede que pg_num e pgp_num do pool sejam modicados.

nosizechange

Impede que o tamanho do pool seja modicado.

write_fadvise_dontneed

Dena/Não dena o ag WRITE_FADVISE_DONTNEED em um pool especíco.

noscrub,nodeep-scrub

Desabilita a depuração (em detalhes) dos dados para o pool especíco a m de resolveruma alta carga de E/S temporária.

hit_set_type

Habilita o monitoramento de conjunto de acertos para pools de cache. Consulte Filtro

de Bloom (http://en.wikipedia.org/wiki/Bloom_filter) para obter informações adicionais.Essa opção pode ter os seguintes valores: bloom , explicit_hash , explicit_object . Opadrão é bloom , os outros valores são apenas para teste.

79 Definir os valores do pool SES 5

hit_set_count

O número de conjuntos de acertos para armazenar nos pools de cache. Quanto maior onúmero, mais RAM é consumida pelo daemon ceph-osd . O padrão é 0 .

hit_set_period

A duração em segundos de um período do conjunto de acertos para os pools de cache.Quanto maior o número, mais RAM é consumida pelo daemon ceph-osd .

hit_set_fpp

A probabilidade de falsos positivos para o tipo de conjunto de acertos bloom. Consulte Filtro

de Bloom (http://en.wikipedia.org/wiki/Bloom_filter) para obter informações adicionais. Afaixa válida é de 0,0 a 1,0. O padrão é 0,05

use_gmt_hitset

Force os OSDs a usar marcações de horário em GMT (Horário de Greenwich) ao criar umconjunto de acertos para camadas de cache. Isso garante que os nós em fusos horáriosdiferentes retornem o mesmo resultado. O padrão é 1 . Esse valor não deve ser mudado.

cache_target_dirty_ratio

A porcentagem do pool de cache que contém os objetos modicados antes que o agentede camadas de cache os descarregue para o pool de armazenamento de suporte. O padrãoé 0,4 .

cache_target_dirty_high_ratio

A porcentagem do pool de cache que contém os objetos modicados antes que o agentede camadas de cache os descarregue para o pool de armazenamento de suporte com umavelocidade maior. O padrão é 0,6 .

cache_target_full_ratio

A porcentagem do pool de cache que contém os objetos não modicados (limpos) antesque o agente de camadas de cache os elimine do pool de cache. O padrão é 0,8 .

target_max_bytes

O Ceph iniciará o descarregamento ou a eliminação de objetos quando o limite max_bytesfor acionado.

target_max_objects

O Ceph iniciará o descarregamento ou a eliminação de objetos quando o limitemax_objects for acionado.

80 Definir os valores do pool SES 5

hit_set_grade_decay_rate

Taxa de redução de temperatura entre dois hit_set s sucessivos. O padrão é 20 .

hit_set_search_last_n

Considera no máximo N aparições nos hit_set s para o cálculo da temperatura. O padrãoé 1 .

cache_min_flush_age

O tempo (em segundos) antes que o agente de camadas de cache descarregue um objetodo pool de cache para o pool de armazenamento.

cache_min_evict_age

O tempo (em segundos) antes que o agente de camadas de cache elimine um objeto dopool de cache.

fast_read

Se esse ag estiver habilitado nos pools com codicação de eliminação, a solicitação deleitura emitirá subleituras para todos os fragmentos e aguardará até receber fragmentossucientes para decodicar e atender ao cliente. No caso dos plug-ins de eliminaçãojerasure e isa, quando as primeiras K respostas são retornadas, a solicitação do clienteé atendida imediatamente, usando os dados decodicados dessas respostas. Isso ajuda areceber alguns recursos para melhorar o desempenho. No momento, esse ag é suportadoapenas para pools com codicação de eliminação. O padrão é 0 .

scrub_min_interval

O intervalo mínimo em segundos para depuração do pool quando a carga do clusterestá baixa. O padrão 0 signica que o valor osd_scrub_min_interval do arquivo deconguração do Ceph foi usado.

scrub_max_interval

O intervalo máximo em segundos para depuração do pool, independentemente da cargado cluster. O padrão 0 signica que o valor osd_scrub_max_interval do arquivo deconguração do Ceph foi usado.

deep_scrub_interval

O intervalo em segundos para depuração do pool em detalhes. O padrão 0 signica que ovalor osd_deep_scrub do arquivo de conguração do Ceph foi usado.

81 Definir os valores do pool SES 5

7.2.8 Obter os valores do pool

Para obter um valor de um pool, execute:

root # ceph osd pool get pool-name key

Você pode obter valores para as chaves listadas na Seção 7.2.7, “Definir os valores do pool” e aschaves a seguir:

pg_num

O número de grupos de posicionamento para o pool.

pgp_num

O número efetivo de grupos de posicionamento a ser usado ao calcular o posicionamentodos dados. A faixa válida é igual a ou menor do que pg_num .

7.2.9 Definir o número de réplicas do objeto

Para denir o número de réplicas do objeto em um pool replicado, execute o seguinte:

root # ceph osd pool set poolname size num-replicas

O num-replicas inclui o próprio objeto. Por exemplo, se você deseja o objeto e duas cópiasdele para um total de três instâncias do objeto, especique 3.

Se você denir num-replicas como 2, haverá apenas uma cópia dos dados. Se vocêperder uma instância do objeto, precisará conar que a outra cópia não foi corrompidadesde a última depuração (http://ceph.com/docs/master/rados/configuration/osd-config-ref/

#scrubbing) durante a recuperação, por exemplo.

A denição de um pool para uma réplica signica que existe exatamente uma instância do objetode dados no pool. Se houver falha no OSD, você perderá os dados. Um uso possível para umpool com uma réplica é armazenar dados temporários por um curto período.

A denição de mais de três réplicas para um pool signica apenas um pequeno aumento naconabilidade, mas pode ser adequada em casos raros. Lembre-se de que, quanto mais réplicas,mais espaço em disco é necessário para armazenar as cópias do objeto. Se você precisar desegurança máxima de dados, recomendamos usar pools com codicação de eliminação. Paraobter mais informações, consulte o Capítulo 9, Pools com codificação de eliminação.

82 Obter os valores do pool SES 5

Atenção: Recomendação de mais do que duas réplicasDesaconselhamos fortemente o uso de apenas 2 réplicas. Em caso de falha em um OSD,a falha do segundo OSD devido a uma alta carga de trabalho durante a recuperação éextremamente provável.

Por exemplo:

root # ceph osd pool set data size 3

Você pode executar esse comando para cada pool.

NotaUm objeto pode aceitar E/S no modo degradado com menos do que pool size réplicas.Para denir um número mínimo de réplicas necessárias para E/S, você deve usar aconguração min_size . Por exemplo:

root # ceph osd pool set data min_size 2

Isso garante que nenhum objeto no pool de dados receba E/S com menos do quemin_size réplicas.

7.2.10 Obter o número de réplicas do objeto

Para obter o número de réplicas do objeto, execute o seguinte:

root # ceph osd dump | grep 'replicated size'

O Ceph listará os pools, com o atributo replicated size realçado. Por padrão, o Ceph criaduas réplicas de um objeto (um total de três cópias, ou um tamanho de 3).

7.2.11 Aumentando o número de grupos de posicionamento

Ao criar um novo pool, você especica o número de grupos de posicionamento para ele (consultea Seção 7.2.2, “Criar um pool”). Após adicionar mais OSDs ao cluster, normalmente você precisaráaumentar o número de grupos de posicionamento também por motivos de desempenho e

83 Obter o número de réplicas do objeto SES 5

durabilidade dos dados. Para cada grupo de posicionamento, os nós OSD e do monitor precisamde memória, rede e CPU o tempo todo, e ainda mais durante a recuperação. Em virtude disso,a redução no número de grupos de posicionamento economiza uma quantidade signicativa derecursos.

Atenção: Um valor muito alto de pg_numAo mudar o valor de pg_num de um pool, talvez o novo número de grupos deposicionamento possa exceder o limite permitido. Por exemplo

root # ceph osd pool set rbd pg_num 4096 Error E2BIG: specified pg_num 3500 is too large (creating 4096 new PGs \ on ~64 OSDs exceeds per-OSD max of 32)

O limite impede a divisão extrema do grupo de posicionamento e é derivado do valormon_osd_max_split_count .

Determinar o novo número correto de grupos de posicionamento para um clusterredimensionado é uma tarefa complexa. Uma abordagem é aumentar continuamente o númerode grupos de posicionamento até o estado de desempenho ideal do cluster. Para determinaro novo número incrementado de grupos de posicionamento, você precisa obter o valordo parâmetro mon_osd_max_split_count e adicioná-lo ao número atual de grupos deposicionamento. Para ter uma ideia básica, observe o seguinte script:

cephadm > max_inc=`ceph daemon mon.a config get mon_osd_max_split_count 2>&1 \ | tr -d '\n ' | sed 's/.*"\([[:digit:]]\+\)".*/\1/'`cephadm > pg_num=`ceph osd pool get rbd pg_num | cut -f2 -d: | tr -d ' '`cephadm > echo "current pg_num value: $pg_num, max increment: $max_inc"cephadm > next_pg_num="$(($pg_num+$max_inc))"cephadm > echo "allowed increment of pg_num: $next_pg_num"

Depois de descobrir o próximo número de grupos de posicionamento, aumente-o com

root # ceph osd pool set pool_name pg_num next_pg_num

7.2.12 Adicionando um pool

Depois que você implantar um cluster pela primeira vez, o Ceph usará os pools padrão paraarmazenar os dados. Depois disso, você poderá criar um novo pool com

84 Adicionando um pool SES 5

root # ceph osd pool create

Para obter mais informações sobre a criação de pools de cluster, consulte a Seção 7.2.2, “Criar

um pool”.

7.3 Migração de poolAo criar um pool (consulte a Seção 7.2.2, “Criar um pool”), você precisa especicar os parâmetrosiniciais, como o tipo de pool ou o número de grupos de posicionamento. Mais tarde, se vocêdecidir mudar qualquer um desses parâmetros após inserir dados no pool, será necessário migraros dados do pool para outro cujos parâmetros sejam adequados à sua implantação.

Há vários métodos de migração de pool. É recomendável usar a camada de cache, pois essemétodo é transparente, reduz o tempo de espera do cluster e evita a duplicação de todos osdados do pool.

7.3.1 Migrar usando a camada de cache

O princípio é simples: incluir o pool que você precisa migrar para a camada de cache na ordeminversa. Obtenha mais detalhes sobre as camadas de cache no Capítulo 10, Camadas de cache. Porexemplo, para migrar um pool replicado denominado “testpool” para um pool com codicaçãode eliminação, siga estas etapas:

PROCEDIMENTO 7.1: MIGRANDO O POOL REPLICADO PARA O POOL COM CODIFICAÇÃO DE ELIMINAÇÃO

1. Crie um novo pool com codicação de eliminação chamado “newpool”:

root@minion > ceph osd pool create newpool 4096 4096 erasure default

Agora você tem dois pools: o “testpool” replicado original preenchido com dados e o novo“newpool” com codicação de eliminação vazio:

FIGURA 7.1: POOLS ANTES DA MIGRAÇÃO

85 Migração de pool SES 5

2. Congure a camada de cache e dena o pool replicado “testpool” como o pool de cache:

root@minion > ceph osd tier add newpool testpool --force-nonemptyroot@minion > ceph osd cache-mode testpool forward

A partir deste momento, todos os objetos novos serão criados no novo pool:

FIGURA 7.2: CONFIGURAÇÃO DA CAMADA DE CACHE

3. Force o pool de cache a mover todos os objetos para o novo pool:

root@minion > rados -p testpool cache-flush-evict-all

FIGURA 7.3: DESCARREGAMENTO DE DADOS

4. Alterne todos os clientes para o novo pool. Até todos os dados serem descarregados para onovo pool com codicação de eliminação, você precisa especicar uma sobreposição paraque esses objetos sejam pesquisados no pool antigo:

root@minion > ceph osd tier set-overlay newpool testpool

Com a sobreposição, todas as operações são encaminhadas para o “testpool” replicadoantigo:

FIGURA 7.4: DEFININDO A SOBREPOSIÇÃO

86 Migrar usando a camada de cache SES 5

Agora você pode alternar todos os clientes para acessar objetos no novo pool.

5. Após a migração de todos os dados para o “newpool” com codicação de eliminação,remova a sobreposição e o pool de cache antigo “testpool”:

root@minion > ceph osd tier remove-overlay newpoolroot@minion > ceph osd tier remove newpool testpool

FIGURA 7.5: MIGRAÇÃO CONCLUÍDA

7.4 Instantâneos de pool

Os instantâneos de pool são capturados com base no estado do pool inteiro do Ceph. Com osinstantâneos de pool, você pode manter o histórico de estado do pool. Dependendo do tamanhodo pool, a criação de instantâneos de pool pode exigir bastante espaço de armazenamento.Conra sempre se há espaço em disco suciente no armazenamento relacionado antes de criarum instantâneo de um pool.

7.4.1 Criar um instantâneo de um pool

Para criar um instantâneo de um pool, execute:

root # ceph osd pool mksnap pool-name snap-name

Por exemplo:

root # ceph osd pool mksnap pool1 snapshot1created pool pool1 snap snapshot1

87 Instantâneos de pool SES 5

7.4.2 Remover um instantâneo de um pool

Para remover um instantâneo de um pool, execute:

root # ceph osd pool rmsnap pool-name snap-name

7.5 Compactação de dadosA partir do SUSE Enterprise Storage 5, o BlueStore fornece compactação de dados sob demandapara economizar espaço em disco.

7.5.1 Habilitar compactação

É possível habilitar a compactação de dados para um pool com:

root # ceph osd pool set POOL_NAME ompression_algorithm snappyroot # ceph osd pool set POOL_NAME compression_mode aggressive

Substitua POOL_NAME pelo pool no qual a compactação será habilitada.

7.5.2 Opções de compactação de pool

Uma lista completa de congurações de compactação:

compression_algorithm

Valores: none , zstd , snappy . Padrão: snappy .O algoritmo de compactação a ser usado depende do caso de uso especíco. Veja a seguirvárias recomendações:

Não use zlib : os outros algoritmos são melhores.

Se você precisa de uma boa taxa de compactação, use zstd . Observe que zstd nãoé recomendado para o BlueStore por causa do alto overhead de CPU ao comprimirpequenas quantidades de dados.

Se você precisa de uso menor da CPU, use lz4 ou snappy .

Realize um benchmark desses algoritmos em uma amostra dos dados reais e observeo uso de CPU e memória do cluster.

88 Remover um instantâneo de um pool SES 5

compression_mode

Valor: { none , aggressive , passive , force }. Padrão: none .

none : nunca comprimir

passive : comprimir se houver a dica COMPRESSIBLE

aggressive : comprimir, exceto se houver a dica INCOMPRESSIBLE

force : sempre comprimir

Para obter informações sobre como denir o ag COMPRESSIBLE ouINCOMPRESSIBLE , consulte http://docs.ceph.com/docs/doc-12.2.0-major-changes/rados/

api/librados/#rados_set_alloc_hint .

compression_required_ratio

Valor: Duplo, Taxa = SIZE_COMPRESSED / SIZE_ORIGINAL. Padrão: .875Os objetos acima dessa taxa não serão comprimidos por causa do baixo ganho líquido.

compression_max_blob_size

Valor: Número Inteiro Não Assinado, tamanho em bytes. Padrão: 0Tamanho mínimo dos objetos que serão comprimidos.

compression_min_blob_size

Valor: Número Inteiro Não Assinado, tamanho em bytes. Padrão: 0Tamanho máximo dos objetos que serão comprimidos.

7.5.3 Opções globais de compactação

As seguintes opções de conguração podem ser denidas na conguração do Ceph e aplicam-se a todos os OSDs, não apenas a um único pool. A conguração especíca do pool listada naSeção 7.5.2, “Opções de compactação de pool” tem prioridade.

bluestore_compression_algorithm

Valores: none , zstd , snappy , zlib . Padrão: snappy .

89 Opções globais de compactação SES 5

O algoritmo de compactação a ser usado depende do caso de uso especíco. Veja a seguirvárias recomendações:

Não use zlib , os outros algoritmos são melhores.

Se você precisa de uma boa taxa de compactação, use zstd . Observe que zstd nãoé recomendado para o BlueStore por causa do alto overhead de CPU ao comprimirpequenas quantidades de dados.

Se você precisa de uso menor da CPU, use lz4 ou snappy .

Realize um benchmark desses algoritmos em uma amostra dos dados reais e observeo uso de CPU e memória do cluster.

bluestore_compression_mode

Valor: { none , aggressive , passive , force }. Padrão: none .

none : nunca comprimir

passive : comprimir se houver a dica COMPRESSIBLE .

aggressive : comprimir, exceto se houver a dica INCOMPRESSIBLE

force : sempre comprimir

Para obter informações sobre como denir o ag COMPRESSIBLE ouINCOMPRESSIBLE , consulte http://docs.ceph.com/docs/doc-12.2.0-major-changes/rados/

api/librados/#rados_set_alloc_hint .

bluestore_compression_required_ratio

Valor: Duplo, Taxa = SIZE_COMPRESSED / SIZE_ORIGINAL. Padrão: .875Os objetos acima dessa taxa não serão comprimidos por causa do baixo ganho líquido.

bluestore_compression_min_blob_size

Valor: Número Inteiro Não Assinado, tamanho em bytes. Padrão: 0Tamanho mínimo dos objetos que serão comprimidos.

bluestore_compression_max_blob_size

Valor: Número Inteiro Não Assinado, tamanho em bytes. Padrão: 0Tamanho máximo dos objetos que serão comprimidos.

bluestore_compression_min_blob_size_ssd

Valor: Número Inteiro Não Assinado, tamanho em bytes. Padrão: 8K

90 Opções globais de compactação SES 5

Tamanho mínimo dos objetos que serão comprimidos e armazenados na unidade de estadosólido.

bluestore_compression_max_blob_size_ssd

Valor: Número Inteiro Não Assinado, tamanho em bytes. Padrão: 64KTamanho máximo dos objetos que serão comprimidos e armazenados na unidade de estadosólido.

bluestore_compression_min_blob_size_hdd

Valor: Número Inteiro Não Assinado, tamanho em bytes. Padrão: 128KTamanho mínimo dos objetos que serão comprimidos e armazenados em discos rígidos.

bluestore_compression_max_blob_size_hdd

Valor: Número Inteiro Não Assinado, tamanho em bytes. Padrão: 512KTamanho máximo dos objetos que serão comprimidos e armazenados em discos rígidos.

91 Opções globais de compactação SES 5

8 Dispositivo de Blocos RADOS

Um bloco é uma sequência de bytes. Por exemplo, um bloco de dados de 512 bytes. As interfacesde armazenamento com base em blocos são a maneira mais comum para armazenar dados commídia rotativa, como discos rígidos, CDs e disquetes. A onipresença de interfaces de dispositivode blocos faz do dispositivo de blocos virtual o candidato ideal para interagir com um sistemade armazenamento de dados em massa, como o Ceph.

Os dispositivos de blocos do Ceph permitem o compartilhamento de recursos físicos e sãoredimensionáveis. Eles armazenam dados distribuídos por vários OSDs em um cluster doCeph. Os dispositivos de blocos do Ceph aproveitam os recursos do RADOS, como criaçãode instantâneos, replicação e consistência. Os Dispositivo de Blocos RADOS (RBD) do Cephinteragem com os OSDs usando os módulos do kernel ou a biblioteca librbd .

FIGURA 8.1: PROTOCOLO RADOS

Os dispositivos de blocos do Ceph oferecem alto desempenho com escalabilidade innita aosmódulos do kernel. Eles suportam soluções de virtualização, como QEMU, ou sistemas decomputação com base em nuvem, como OpenStack, que utilizam a libvirt . Você pode usaro mesmo cluster para operar o Object Gateway, o CephFS e os Dispositivos de Blocos RADOSsimultaneamente.

8.1 Comandos do dispositivo de blocosO comando rbd permite criar, listar, avaliar e remover imagens de dispositivo de blocos. Vocêtambém pode usá-lo, por exemplo, para clonar imagens, criar instantâneos, voltar uma imagempara um instantâneo ou ver um instantâneo.

Dica: Acesso a um clusterPara usar os comandos do Dispositivo de Blocos RADOS, você deve ter acesso a um clusterdo Ceph ativo.

92 Comandos do dispositivo de blocos SES 5

8.1.1 Criando uma imagem de dispositivo de blocos

Antes de adicionar um dispositivo de blocos a um nó, você deve criar uma imagem para ele nocluster. Para criar uma imagem de dispositivo de blocos, execute o seguinte:

root # rbd create --size megabytes pool-name/image-name

Por exemplo, para criar uma imagem de 1 GB denominada “bar” que armazena informações emum pool chamado “swimmingpool”, execute o seguinte:

root # rbd create --size 1024 swimmingpool/bar

Dica: Pool padrãoSe você não especicar um pool durante a criação de uma imagem, ela será armazenadano pool padrão “rbd”.

Nota: Criar primeiro o poolVocê precisa primeiro criar um pool antes de especicá-lo como origem. Consulte oCapítulo 7, Gerenciando pools de armazenamento para obter mais detalhes.

8.1.2 Criando a imagem de um dispositivo de blocos em um poolcom codificação de eliminação

A partir do SUSE Enterprise Storage 5, é possível armazenar dados de uma imagem de dispositivode blocos em pools com codicação de eliminação. Apenas a parte de “dados” da imagemRBD pode ser armazenada em um pool com codicação de eliminação. Além disso, o pool comcodicação de eliminação deve ter o ag “overwrite” denido como true. Apenas será possíveldenir esse ag como true se todos os OSDs usarem o BlueStore.

Os metadados de imagem não podem residir em um pool com codicação de eliminação.Os metadados podem residir no pool “rbd” padrão ou no pool que o usuário especicaexplicitamente com o parâmetro --pool= no comando rbd create .

Nota: Necessário para o BlueStoreTodos os nós exigem que o BlueStore use pools com codicação de eliminação paraimagens de dispositivo de blocos.

93 Criando uma imagem de dispositivo de blocos SES 5

Siga as etapas abaixo para criar uma imagem RBD em um pool com codicação de eliminação:

root # ceph osd pool create POOL_NAME 12 12 erasureroot # ceph osd pool set POOL_NAME allow_ec_overwrites true

# Metadata will reside in pool "rbd", and data in pool "POOL_NAME"root # rbd create IMAGE_NAME --size=1G --data-pool POOL_NAME

#Metadata will reside in pool "OTHER_POOL", and data in pool "POOL_NAME"root # rbd create IMAGE_NAME --size=1G --data-pool POOL_NAME --pool=OTHER_POOL

8.1.3 Listando imagens de dispositivo de blocos

Para listar os dispositivos de blocos no pool “rbd”, execute o seguinte (“rbd” é o nome do poolpadrão):

root # rbd ls

Para listar os dispositivos de blocos em um pool chamado “swimmingpool”, execute o seguinte:

root # rbd ls swimmingpool

8.1.4 Recuperando informações da imagem

Para recuperar informações da imagem “bar” em um pool chamado “swimmingpool”, executeo seguinte:

root # rbd info swimmingpool/bar

8.1.5 Redimensionando a imagem de um dispositivo de blocos

As imagens de Dispositivo de Blocos RADOS são aprovisionadas dinamicamente, elas não usamnenhum armazenamento físico até você começar a gravar dados nelas. No entanto, elas têmuma capacidade máxima que você dene com a opção --size . Para aumentar (ou diminuir)o tamanho máximo da imagem, execute o seguinte:

root # rbd resize --size 2048 foo # to increaserbd resize --size 2048 foo --allow-shrink # to decrease

94 Listando imagens de dispositivo de blocos SES 5

8.1.6 Removendo a imagem de um dispositivo de blocos

Para remover um dispositivo de blocos correspondente a uma imagem “bar” no pool chamado“swimmingpool”, execute o seguinte:

root # rbd rm swimmingpool/bar

8.2 Montando e desmontando imagens RBDApós criar um Dispositivo de Blocos RADOS, você poderá formatá-lo, montá-lo para poder trocararquivos e desmontá-lo depois de concluído.

1. Verique se o cluster do Ceph inclui um pool com a imagem do disco que você desejamontar. Considere o pool chamado mypool e a imagem myimage .

rbd list mypool

2. Mapeie a imagem para um novo dispositivo de blocos.

root # rbd map --pool mypool myimage

Dica: Nome e autenticação de usuárioPara especicar um nome de usuário, utilize --id user-name . Além disso, se vocêusar a autenticação cephx , deverá também especicar um segredo. Ele pode vir deum chaveiro ou de um arquivo que contém o segredo:

root # rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

ou

root # rbd map --pool rbd myimage --id admin --keyfile /path/to/file

3. Liste todos os dispositivos mapeados:

root # rbd showmapped id pool image snap device 0 mypool myimage - /dev/rbd0

O dispositivo no qual desejamos trabalhar é /dev/rbd0 .

95 Removendo a imagem de um dispositivo de blocos SES 5

4. Crie um sistema de arquivos XFS no dispositivo /dev/rbd0 .

root # mkfs.xfs /dev/rbd0 log stripe unit (4194304 bytes) is too large (maximum is 256KiB) log stripe unit adjusted to 32KiB meta-data=/dev/rbd0 isize=256 agcount=9, agsize=261120 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=2097152, imaxpct=25 = sunit=1024 swidth=1024 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=8 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0

5. Monte o dispositivo e verique se ele foi montado corretamente. Substitua /mnt peloponto de montagem.

root # mount /dev/rbd0 /mntroot # mount | grep rbd0/dev/rbd0 on /mnt type xfs (rw,relatime,attr2,inode64,sunit=8192,...

Agora, você pode mover os dados de e para o dispositivo como se ele fosse um diretóriolocal.

Dica: Aumentando o tamanho do dispositivo RBDSe você acha que o tamanho do dispositivo RBD não é mais suciente, podeaumentá-lo com facilidade.

1. Aumente o tamanho da imagem RBD. Por exemplo, até 10 GB.

root # rbd resize --size 10000 mypool/myimage Resizing image: 100% complete...done.

2. Expanda o sistema de arquivos para preencher o novo tamanho do dispositivo.

root # xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000

6. Após terminar de acessar o dispositivo, você poderá desmontá-lo.

96 Montando e desmontando imagens RBD SES 5

root # unmount /mnt

Dica: (Des)montagem manualComo o mapeamento e a montagem manuais de imagens RBD após a inicialização,e a desmontagem e a anulação do mapeamento antes do encerramento, podem serdesgastantes, um script rbdmap e uma unidade systemd são fornecidos. Consulte aSeção 8.4, “rbdmap: Mapear dispositivos RBD no momento da inicialização”.

8.3 Instantâneos de dispositivo de blocosUm instantâneo RBD é aquele de uma imagem do Dispositivo de Blocos RADOS. Com osinstantâneos, você pode manter o histórico de estado da imagem. O Ceph também suportacamadas de instantâneo, o que permite clonar imagens de VM de forma rápida e fácil. O Cephsuporta instantâneos de dispositivo de blocos usando o comando rbd e muitas interfaces denível mais alto, incluindo QEMU, libvirt , OpenStack e CloudStack.

NotaPare as operações de entrada e de saída antes de criar instantâneos de uma imagem. Sea imagem tiver um sistema de arquivos, o estado dele deverá ser consistente antes dacriação de instantâneos.

8.3.1 Notas sobre o Cephx

Quando o cephx está habilitado (consulte http://ceph.com/docs/master/rados/configuration/

auth-config-ref/ para obter mais informações), você deve especicar um nome de usuárioou ID e um caminho para o chaveiro que contém a chave correspondente para ousuário. Consulte Gerenciamento de usuários (http://ceph.com/docs/master/rados/operations/

user-management/) para obter mais detalhes. É possível também adicionar a variável deambiente CEPH_ARGS para evitar uma nova entrada dos parâmetros a seguir.

root # rbd --id user-ID --keyring=/path/to/secret commandsroot # rbd --name username --keyring=/path/to/secret commands

97 Instantâneos de dispositivo de blocos SES 5

Por exemplo:

root # rbd --id admin --keyring=/etc/ceph/ceph.keyring commandsroot # rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands

DicaAdicione o usuário e o segredo à variável de ambiente CEPH_ARGS para que você nãoprecise digitá-los toda vez.

8.3.2 Aspectos básicos do instantâneo

Os procedimentos a seguir demonstram como criar, listar e remover instantâneos usando ocomando rbd na linha de comando.

8.3.2.1 Criar instantâneos

Para criar um instantâneo com rbd , especique a opção snap create , o nome do pool e onome da imagem.

root # rbd --pool pool-name snap create --snap snap-name image-nameroot # rbd snap create pool-name/image-name@snap-name

Por exemplo:

root # rbd --pool rbd snap create --snap snapshot1 image1root # rbd snap create rbd/image1@snapshot1

8.3.2.2 Listar instantâneos

Para listar os instantâneos de uma imagem, especique o nome do pool e o nome da imagem.

root # rbd --pool pool-name snap ls image-nameroot # rbd snap ls pool-name/image-name

Por exemplo:

root # rbd --pool rbd snap ls image1

98 Aspectos básicos do instantâneo SES 5

root # rbd snap ls rbd/image1

8.3.2.3 Voltar um instantâneo

Para voltar a um instantâneo com rbd , especique a opção snap rollback , o nome do pool,o nome da imagem e o nome do instantâneo.

root # rbd --pool pool-name snap rollback --snap snap-name image-nameroot # rbd snap rollback pool-name/image-name@snap-name

Por exemplo:

root # rbd --pool pool1 snap rollback --snap snapshot1 image1root # rbd snap rollback pool1/image1@snapshot1

NotaVoltar uma imagem para um instantâneo signica sobregravar a versão atual da imagemcom os dados de um instantâneo. O tempo necessário para executar um rollback aumentade acordo com o tamanho da imagem. É mais rápido clonar de um instantâneo do quevoltar uma imagem para um instantâneo, e é o método preferencial para reverter a umestado preexistente.

8.3.2.4 Apagar um instantâneo

Para apagar um instantâneo com rbd , especique a opção snap rm , o nome do pool, o nomeda imagem e o nome de usuário.

root # rbd --pool pool-name snap rm --snap snap-name image-nameroot # rbd snap rm pool-name/image-name@snap-name

Por exemplo:

root # rbd --pool pool1 snap rm --snap snapshot1 image1root # rbd snap rm pool1/image1@snapshot1

NotaOs Ceph OSDs apagam dados de forma assíncrona, portanto, apagar um instantâneo nãolibera o espaço em disco imediatamente.

99 Aspectos básicos do instantâneo SES 5

8.3.2.5 Purgar instantâneos

Para apagar todos os instantâneos de uma imagem com rbd , especique a opção snap purgee o nome da imagem.

root # rbd --pool pool-name snap purge image-nameroot # rbd snap purge pool-name/image-name

Por exemplo:

root # rbd --pool pool1 snap purge image1root # rbd snap purge pool1/image1

8.3.3 Camadas

O Ceph permite criar muitos clones COW (Copy-On-Write – Cópia em Gravação) de uminstantâneo de dispositivo de blocos. As camadas de instantâneo permitem que os clientesde dispositivo de blocos do Ceph criem imagens muito rapidamente. Por exemplo, você podecriar uma imagem de dispositivo de blocos com uma VM Linux gravada nela e, em seguida,capturar um instantâneo da imagem, proteger o instantâneo e criar quantos clones de cópiaem gravação desejar. Um instantâneo é apenas leitura, portanto, sua clonagem simplica asemântica, possibilitando criar clones rapidamente.

NotaOs termos “pai” e “lho” mencionados nos exemplos de linha de comando aseguir indicam um instantâneo de dispositivo de blocos do Ceph (pai) e a imagemcorrespondente clonada do instantâneo (lho).

Cada imagem clonada (lho) armazena uma referência à imagem pai, o que permite que aimagem clonada abra o instantâneo pai e o leia.

Um clone COW de um instantâneo funciona exatamente como qualquer outra imagem dedispositivo de blocos do Ceph. Você pode ler, gravar, clonar e redimensionar imagens clonadas.Não há nenhuma restrição especial em relação às imagens clonadas. No entanto, o clone decópia em gravação de um instantâneo refere-se ao instantâneo. Sendo assim, você deve protegero instantâneo antes de cloná-lo.

100 Camadas SES 5

NotaO Ceph suporta apenas a clonagem para imagens format 2 (criadas com rbd create --image-format 2 ).

8.3.3.1 Introdução às camadas

As camadas de dispositivo de blocos do Ceph são um processo simples. Você deve ter umaimagem. Você deve criar um instantâneo da imagem. Você deve proteger o instantâneo. Apósexecutar essas etapas, você poderá iniciar a clonagem do instantâneo.

A imagem clonada tem uma referência ao instantâneo pai e inclui os IDs do pool, da imageme do instantâneo. A inclusão do ID do pool signica que você pode clonar instantâneos de umpool para imagens em outro pool.

Gabarito de Imagem: Um caso de uso comum para camadas de dispositivo de blocos écriar uma imagem master e um instantâneo que serve como gabarito para os clones. Porexemplo, um usuário pode criar uma imagem para uma distribuição Linux (por exemplo,SUSE Linux Enterprise Server) e criar um instantâneo para ela. Periodicamente, o usuáriopode atualizar a imagem e criar um novo instantâneo (por exemplo, zypper ref &&zypper patch seguido por rbd snap create ). Durante a maturação da imagem, o usuáriopode clonar qualquer um dos instantâneos.

Gabarito Estendido: Um caso de uso mais avançado inclui estender a imagem de um gabaritoque fornece mais informações do que uma imagem de base. Por exemplo, um usuário podeclonar uma imagem (um gabarito de VM) e instalar outro software (por exemplo, um bancode dados, um sistema de gerenciamento de conteúdo ou um sistema de análise) e, emseguida, capturar um instantâneo da imagem estendida que, por si só, pode ser atualizadada mesma forma que a imagem de base.

Pool de Gabarito: Uma maneira de usar as camadas de dispositivo de blocos é criar um poolque contém imagens master que atuam como gabaritos e instantâneos desses gabaritos.Em seguida, você pode estender os privilégios apenas leitura aos usuários para que elespossam clonar os instantâneos sem a capacidade de gravação ou execução no pool.

Migração/Recuperação de Imagens: Uma maneira de usar as camadas de dispositivo deblocos é migrar ou recuperar os dados de um pool para outro.

101 Camadas SES 5

8.3.3.2 Protegendo um instantâneo

Os clones acessam os instantâneos pai. Todos os clones serão destruídos se um usuário apagar oinstantâneo pai por engano. Para evitar a perda de dados, você precisa proteger o instantâneoantes de cloná-lo.

root # rbd --pool pool-name snap protect \ --image image-name --snap snapshot-nameroot # rbd snap protect pool-name/image-name@snapshot-name

Por exemplo:

root # rbd --pool pool1 snap protect --image image1 --snap snapshot1root # rbd snap protect pool1/image1@snapshot1

NotaVocê não pode apagar um instantâneo protegido.

8.3.3.3 Clonando um instantâneo

Para clonar um instantâneo, você precisa especicar o pool pai, a imagem, o instantâneo, o poollho e o nome da imagem. Você precisa proteger o instantâneo antes de cloná-lo.

root # rbd --pool pool-name --image parent-image \ --snap snap-name --dest-pool pool-name \ --dest child-imageroot # rbd clone pool-name/parent-image@snap-name \pool-name/child-image-name

Por exemplo:

root # rbd clone pool1/image1@snapshot1 pool1/image2

NotaVocê pode clonar um instantâneo de um pool para uma imagem em outro pool. Porexemplo, você pode manter as imagens e os instantâneos apenas leitura como gabaritosem um pool e os clones graváveis em outro pool.

102 Camadas SES 5

8.3.3.4 Anulando a proteção de um instantâneo

Antes de apagar um instantâneo, você deve anular a proteção dele. Além disso, você nãopode apagar instantâneos com referências de clones. Você precisa nivelar cada clone de uminstantâneo antes de apagar o instantâneo.

root # rbd --pool pool-name snap unprotect --image image-name \ --snap snapshot-nameroot # rbd snap unprotect pool-name/image-name@snapshot-name

Por exemplo:

root # rbd --pool pool1 snap unprotect --image image1 --snap snapshot1root # rbd snap unprotect pool1/image1@snapshot1

8.3.3.5 Listando os filhos de um instantâneo

Para listar os lhos de um instantâneo, execute o seguinte:

root # rbd --pool pool-name children --image image-name --snap snap-nameroot # rbd children pool-name/image-name@snapshot-name

Por exemplo:

root # rbd --pool pool1 children --image image1 --snap snapshot1root # rbd children pool1/image1@snapshot1

8.3.3.6 Nivelando uma imagem clonada

As imagens clonadas mantêm uma referência ao instantâneo pai. Ao remover a referênciado clone lho para o instantâneo pai, você “nivela” com eciência a imagem copiando asinformações do instantâneo para o clone. O tempo necessário para nivelar um clone aumenta deacordo com o tamanho do instantâneo. Para apagar um instantâneo, você deve primeiro nivelaras imagens lho.

root # rbd --pool pool-name flatten --image image-nameroot # rbd flatten pool-name/image-name

Por exemplo:

root # rbd --pool pool1 flatten --image image1root # rbd flatten pool1/image1

103 Camadas SES 5

NotaComo uma imagem nivelada contém todas as informações do instantâneo, ela ocupa maisespaço de armazenamento do que um clone em camadas.

8.4 rbdmap: Mapear dispositivos RBD no momentoda inicialização

rbdmap é um script de shell que automatiza as operações rbd map e rbd unmap em uma ou maisimagens de Dispositivo de Blocos RADOS. Embora você possa executar o script manualmente aqualquer momento, o caso de uso principal é mapear e montar automaticamente as imagens RBDno momento da inicialização (e desmontar e anular o mapeamento no encerramento), conformeacionado pelo sistema Init. Um arquivo da unidade systemd , rbdmap.service , está incluídono pacote ceph-common para essa nalidade.

O script aplica um único argumento, que pode ser map ou unmap . Em qualquer um dos casos, oscript analisa um arquivo de conguração. Ele assume como padrão /etc/ceph/rbdmap , maspode ser anulado por meio de uma variável de ambiente RBDMAPFILE . Cada linha do arquivode conguração corresponde a uma imagem RBD que será mapeada ou que terá o mapeamentoanulado.

O arquivo de conguração tem o seguinte formato:

image_specification rbd_options

image_specification

Caminho para uma imagem em um pool. Especique comonome_do_pool / nome_da_imagem . Se você omitir nome_do_pool , o padrão “rbd” seráassumido.

rbd_options

Uma lista opcional de parâmetros a serem passados para o comando rbd map subjacente.Esses parâmetros e seus valores devem ser especicados como uma string separada porvírgula. Por exemplo:

PARAM1=VAL1,PARAM2=VAL2,...

104 rbdmap: Mapear dispositivos RBD no momento da inicialização SES 5

O exemplo faz com que o script rbdmap execute o seguinte comando:

rbd map pool_name/image_name --PARAM1 VAL1 --PARAM2 VAL2

Quando executado como rbdmap map , o script analisa o arquivo de conguração e, para cadaimagem RBD especicada, ele tenta primeiro mapear a imagem (usando o comando rbd map )e, na sequência, montar a imagem.

Quando executado como rbdmap unmap , as imagens listadas no arquivo de conguração serãodesmontadas e o mapeamento delas será anulado.

rbdmap unmap-all tenta desmontar e, na sequência, anular o mapeamento de todas as imagensRBD mapeadas, independentemente de estarem listadas no arquivo de conguração.

Se bem-sucedida, a operação rbd map mapeia a imagem para um dispositivo /dev/rbdX e, nesseponto, uma regra udev é acionada para criar um link simbólico do nome do dispositivo amigável/dev/rbd/nome_do_pool/nome_da_imagem apontando para o dispositivo real mapeado.

Para que a montagem e a desmontagem sejam bem-sucedidas, o nome “amigável” do dispositivoprecisa ter uma entrada correspondente em /etc/fstab . Ao gravar entradas /etc/fstab emimagens RBD, especique a opção de montagem “noauto” (ou “nofail”). Isso impede que osistema Init tente montar o dispositivo com muita antecedência, antes mesmo de ele existir, poisrbdmap.service é normalmente acionado mais adiante na sequência de boot.

Para obter uma lista de opções rbd , consulte a página de manual do rbd ( man 8 rbd ).

Para ver exemplos de uso do rbdmap , consulte a página de manual do rbdmap ( man 8 rbdmap ).

8.5 Espelhamento de dispositivo de blocos RADOS

É possível espelhar as imagens RBD de forma assíncrona entre dois clusters do Ceph. Essafuncionalidade usa o recurso de registro de imagens RBD em diário para garantir a replicaçãoconsistente com a falha entre os clusters. O espelhamento é congurado por pool nos clusterspeer e pode ser congurado para espelhar automaticamente todas as imagens em um pool ouapenas um subconjunto especíco de imagens. O espelhamento é congurado usando o comandorbd . O daemon rbd-mirror é responsável por capturar as atualizações da imagem do clusterpeer remoto e aplicá-las à imagem no cluster local.

105 Espelhamento de dispositivo de blocos RADOS SES 5

Importante: Daemon rbd-mirrorPara usar o espelhamento de RBD, você precisa ter dois clusters do Ceph, cada umexecutando o daemon rbd-mirror .

8.5.1 Daemon rbd-mirror

Os dois daemons rbd-mirror são responsáveis por observar os diários da imagem no clusterpeer remoto e reproduzir os eventos do diário no cluster local. O recurso de registro de imagensRBD em diário registra todas as modicações feitas na imagem na ordem em que elas ocorrem.Isso garante que um espelho da imagem remota consistente com a falha esteja disponívellocalmente.

O daemon rbd-mirror está disponível no pacote rbd-mirror . Instale, habilite e inicie-o emum dos nós do cluster:

root@minion > zypper install rbd-mirrorroot@minion > systemctl enable ceph-rbd-mirror@server_name.serviceroot@minion > systemctl start ceph-rbd-mirror@server_name.service

ImportanteCada daemon rbd-mirror requer conexão com os dois clusters simultaneamente.

8.5.2 Configuração do pool

Os procedimentos a seguir demonstram como executar as tarefas administrativas básicas paracongurar o espelhamento usando o comando rbd . O espelhamento é congurado por pool nosclusters do Ceph.

Você precisa executar as etapas de conguração do pool em ambos os clusters peer. Estesprocedimentos consideram a existência de dois clusters, chamados "local" e "remote", acessíveisde um único host, por motivos de clareza.

Consulte a página de manual do rbd ( man 8 rbd ) para obter mais detalhes sobre como seconectar a diferentes clusters do Ceph.

106 Daemon rbd-mirror SES 5

Dica: Vários clustersO nome do cluster nos exemplos a seguir corresponde a um arquivo de conguraçãodo Ceph de mesmo nome /etc/ceph/remote.conf . Consulte a documentação do ceph-

conf (http://docs.ceph.com/docs/master/rados/configuration/ceph-conf/#running-multiple-

clusters) para saber como congurar vários clusters.

8.5.2.1 Habilitar o espelhamento

Para habilitar o espelhamento em um pool, especique o subcomando mirror pool enable ,o nome do pool e o modo de espelhamento. O modo de espelhamento pode ser pool ou image:

pool

Todas as imagens no pool com o recurso de registro em diário habilitado são espelhadas.

image

O espelhamento precisa ser habilitado explicitamente em cada imagem. Consulte aSeção 8.5.3.2, “Habilitar o espelhamento de imagem” para obter mais informações.

Por exemplo:

root # rbd --cluster local mirror pool enable image-pool poolroot # rbd --cluster remote mirror pool enable image-pool pool

8.5.2.2 Desabilitar o espelhamento

Para desabilitar o espelhamento em um pool, especique o subcomando mirror pool disablee o nome do pool. Quando o espelhamento é desabilitado dessa maneira em um pool, ele tambémé desabilitado em todas as imagens (no pool) para as quais ele foi explicitamente habilitado.

root # rbd --cluster local mirror pool disable image-poolroot # rbd --cluster remote mirror pool disable image-pool

107 Configuração do pool SES 5

8.5.2.3 Adicionar peer de clusters

Para que o daemon rbd-mirror descubra seu cluster peer, o peer precisa ser registrado no pool.Para adicionar um cluster peer de espelhamento, especique o subcomando mirror pool peeradd , o nome do pool e uma especicação do cluster:

root # rbd --cluster local mirror pool peer add image-pool client.remote@remoteroot # rbd --cluster remote mirror pool peer add image-pool client.local@local

8.5.2.4 Remover peer de clusters

Para remover um cluster peer de espelhamento, especique o subcomando mirror pool peerremove , o nome do pool e o UUID do peer (disponível no comando rbd mirror pool info ):

root # rbd --cluster local mirror pool peer remove image-pool \ 55672766-c02b-4729-8567-f13a66893445root # rbd --cluster remote mirror pool peer remove image-pool \ 60c0e299-b38f-4234-91f6-eed0a367be08

8.5.3 Configuração da imagem

Diferentemente da conguração do pool, a conguração da imagem precisa apenas ser executadaem um único cluster peer de espelhamento do Ceph.

As imagens RBD espelhadas são designadas como principais ou não principais. Essa é umapropriedade da imagem, e não do pool. Não é possível modicar as imagens designadas comonão principais.

As imagens são automaticamente promovidas a principais quando o espelhamento é habilitadoprimeiro em uma imagem (seja implicitamente, se o modo de espelhamento do pool for “pool”e a imagem tiver o recurso de registro de imagens em diário habilitado, ou explicitamente(consulte a Seção 8.5.3.2, “Habilitar o espelhamento de imagem”) pelo comando rbd ).

108 Configuração da imagem SES 5

8.5.3.1 Habilitar o suporte ao registro de imagens em diário

O espelhamento de RBD usa o recurso de registro de RBD em diário para garantir que aimagem replicada permaneça sempre consistente com a falha. Antes de espelhar uma imagempara um cluster peer, o recurso de registro em diário deve ser habilitado. O recurso pode serhabilitado no momento da criação da imagem inserindo a opção --image-feature exclusive-lock,journaling no comando rbd .

Se preferir, o recurso de registro em diário pode ser habilitado dinamicamente nas imagens RBDpreexistentes. Para habilitar o registro em diário, especique o subcomando feature enable ,o nome do pool e da imagem e o nome do recurso:

root # rbd --cluster local feature enable image-pool/image-1 journaling

Nota: Dependência de opçãoO recurso de registro em diário depende do recurso de bloqueio exclusivo . Se orecurso de bloqueio exclusivo ainda não estiver habilitado, você precisará habilitá-loantes de habilitar o recurso de registro em diário .

Dica: Registrando todas as novas imagens em diárioVocê pode habilitar o registro em diário em todas as novas imagens por padrãoadicionando a seguinte linha ao arquivo de conguração do Ceph:

rbd default features = 125

8.5.3.2 Habilitar o espelhamento de imagem

Se o espelhamento for congurado no modo “image” para o pool da imagem, será necessáriohabilitar explicitamente o espelhamento para cada imagem no pool. Para habilitar oespelhamento em determinada imagem, especique o subcomando mirror image enablejuntamente com o nome do pool e da imagem:

root # rbd --cluster local mirror image enable image-pool/image-1

109 Configuração da imagem SES 5

8.5.3.3 Desabilitar o espelhamento de imagem

Para desabilitar o espelhamento em determinada imagem, especique o subcomando mirrorimage disable juntamente com o nome do pool e da imagem:

root # rbd --cluster local mirror image disable image-pool/image-1

8.5.3.4 Promoção e rebaixamento de imagem

Em um cenário de failover em que a designação principal precisa ser movida para a imagem nocluster peer, você precisa interromper o acesso à imagem principal, rebaixar a imagem principalatual, promover a nova imagem principal e continuar o acesso à imagem no cluster alternativo.

Para rebaixar determinada imagem para não principal, especique o subcomando mirrorimage demote juntamente com o nome do pool e da imagem:

root # rbd --cluster local mirror image demote image-pool/image-1

Para rebaixar todas as imagens principais em um pool para não principais, especique osubcomando mirror pool demote juntamente com o nome do pool:

root # rbd --cluster local mirror pool demote image-pool

Para promover determinada imagem para principal, especique o subcomando mirror imagepromote juntamente com o nome do pool e da imagem:

root # rbd --cluster remote mirror image promote image-pool/image-1

Para promover todas as imagens não principais em um pool para principais, especique osubcomando mirror pool promote juntamente com o nome do pool:

root # rbd --cluster local mirror pool promote image-pool

Dica: Dividir a carga de E/SComo o status principal ou não principal refere-se a cada imagem, é possível ter doisclusters que dividem a carga de E/S e o failover ou failback por fase.

110 Configuração da imagem SES 5

Nota: Promoção forçadaA promoção pode ser forçada usando a opção --force . A promoção forçada é necessáriaquando o rebaixamento não pode ser propagado para o cluster peer (por exemplo, em casode falha do cluster ou interrupção da comunicação). Isso resultará em um cenário de split-brain (dupla personalidade) entre os dois peers, e a imagem não será mais sincronizadaaté que um subcomando resync seja emitido.

8.5.3.5 Forçar ressincronização de imagem

Se um evento de split-brain for detectado pelo daemon rbd-mirror , ele não tentará espelhar aimagem afetada até o problema ser corrigido. Para continuar o espelhamento de uma imagem,primeiro rebaixe a imagem que foi identicada como desatualizada e, em seguida, solicite umaressincronização com a imagem principal. Para solicitar a ressincronização de uma imagem,especique o subcomando mirror image resync juntamente com o nome do pool e da imagem:

root # rbd mirror image resync image-pool/image-1

8.5.4 Status do espelho

O status de replicação do cluster peer é armazenado para cada imagem principal espelhada. Essestatus pode ser recuperado usando os subcomandos mirror image status e mirror poolstatus :

Para solicitar o status da imagem de espelho, especique o subcomando mirror image statusjuntamente com o nome do pool e da imagem:

root # rbd mirror image status image-pool/image-1

Para solicitar o status do resumo do pool de espelhos, especique o subcomando mirror poolstatus juntamente com o nome do pool:

root # rbd mirror pool status image-pool

Dica:A adição da opção --verbose ao subcomando mirror pool status resultará tambémnos detalhes de status para cada imagem de espelhamento no pool.

111 Status do espelho SES 5

9 Pools com codificação de eliminação

O Ceph oferece uma alternativa à replicação normal de dados em pools conhecidos comode eliminação ou com codicação de eliminação. Os pools de eliminação não têm todas asfuncionalidades dos pools replicados, mas exigem menos armazenamento bruto. Um pool deeliminação padrão capaz de armazenar 1 TB de dados requer 1,5 TB de armazenamento bruto.Isso equivale a um pool replicado que precisa de 2 TB de armazenamento bruto para a mesmaquantidade de dados.

Para obter informações sobre a Codicação de Eliminação, visite https://en.wikipedia.org/wiki/

Erasure_code .

NotaAo usar o FileStore, você não pode acessar pools com codicação de eliminação pelainterface do RBD, a menos que você tenha uma camada de cache congurada. Consultea Seção 9.3, “Pool com codificação de eliminação e camada de cache” para obter mais detalhesou use o BlueStore.

NotaVerique se as regras CRUSH para os pools de eliminação usam indep para step . Parasaber os detalhes, consulte a Seção 6.3.2, “firstn e indep”.

9.1 Criando um pool com codificação de eliminaçãode exemploO pool com codicação de eliminação mais simples é equivalente ao RAID5 e requer pelo menostrês hosts. Este procedimento descreve como criar um pool para ns de teste.

1. O comando ceph osd pool create é usado para criar um pool do tipo de eliminação.12 representa o número de grupos de posicionamento. Com os parâmetros padrão, o poolé capaz de resolver a falha de um OSD.

root # ceph osd pool create ecpool 12 12 erasurepool 'ecpool' created

112 Criando um pool com codificação de eliminação de exemplo SES 5

2. A string ABCDEFGHI é gravada em um objeto denominado NYAN .

cephadm > echo ABCDEFGHI | rados --pool ecpool put NYAN -

3. Para ns de teste, os OSDs agora podem ser desabilitados. Por exemplo, desconecte-osda rede.

4. Para testar se o pool é capaz de resolver a falha de dispositivos, o conteúdo do arquivopode ser acessado com o comando rados .

root # rados --pool ecpool get NYAN -ABCDEFGHI

9.2 Perfis de codificação de eliminação

Quando o comando ceph osd pool create é invocado para criar um pool de eliminação, o perlpadrão é usado, a menos que outro perl seja especicado. Os pers denem a redundânciados dados. Para fazer isso, dena dois parâmetros denominados aleatoriamente k e m . k em denem em quantos pacotes os dados são divididos e quantos pacotes de codicação sãocriados. Em seguida, os pacotes redundantes são armazenados em OSDs diferentes.

Denições necessárias para pers de pool de eliminação:

pacote

quando a função de codicação é chamada, ela retorna pacotes do mesmo tamanho:pacotes de dados que podem ser concatenados para reconstruir o objeto original e pacotesde codicação que podem ser usados para reconstruir um pacote perdido.

k

o número de pacotes de dados, que é o número de pacotes em que objeto original é dividido.Por exemplo, se k = 2 , um objeto de 10 KB será dividido em k objetos de 5 KB cada um.

m

o número de pacotes de codicação, que é o número de pacotes adicionais calculado pelasfunções de codicação. Se houver 2 pacotes de codicação, isso signica que 2 OSDspoderão ser eliminados sem perda de dados.

113 Perfis de codificação de eliminação SES 5

crush-failure-domain

dene para quais dispositivos os pacotes são distribuídos. Um tipo de compartimentode memória precisa ser denido como valor. Para todos os tipos de compartimento dememória, consulte a Seção 6.2, “Compartimentos de memória”. Se o domínio de falha forrack , os pacotes serão armazenados em racks diferentes para aumentar a resiliência emcaso de falhas no rack.

Com o perl de codicação de eliminação padrão usado na Seção  9.1, “Criando um pool com

codificação de eliminação de exemplo”, você não perderá os dados do cluster se houver falha emum único OSD. Dessa forma, para armazenar 1 TB de dados, ele precisa de mais 0,5 TB dearmazenamento bruto. Isso signica que 1,5 TB de armazenamento bruto é necessário para 1 TBde dados. Isso equivale a uma conguração RAID 5 comum. Para comparação: um pool replicadoprecisa de 2 TB de armazenamento bruto para armazenar 1 TB de dados.

As congurações do perl padrão podem ser exibidas com:

root # ceph osd erasure-code-profile get defaultdirectory=.libsk=2m=1plugin=jerasurecrush-failure-domain=hosttechnique=reed_sol_van

A escolha do perl correto é importante, porque ele não poderá ser modicado após a criaçãodo pool. Um novo pool com um perl diferente precisa ser criado, e todos os objetos do poolanterior precisam ser movidos para o novo.

Os parâmetros mais importantes do perl são k , m e crush-failure-domain porque denem ooverhead de armazenamento e a durabilidade dos dados. Por exemplo, se a arquitetura desejadativer que sustentar a perda de dois racks com um overhead de armazenamento de 66%, oseguinte perl poderá ser denido:

root # ceph osd erasure-code-profile set myprofile \ k=3 \ m=2 \ crush-failure-domain=rack

O exemplo na Seção  9.1, “Criando um pool com codificação de eliminação de exemplo” pode serrepetido com este novo perl:

root # ceph osd pool create ecpool 12 12 erasure myprofile

114 Perfis de codificação de eliminação SES 5

cephadm > echo ABCDEFGHI | rados --pool ecpool put NYAN -root # rados --pool ecpool get NYAN -ABCDEFGHI

O objeto NYAN será dividido em três ( k=3 ), e dois pacotes adicionais serão criados ( m=2 ). Ovalor de m dene quantos OSDs podem ser perdidos simultaneamente sem nenhuma perda dedados. O crush-failure-domain=rack criará um conjunto de regras CRUSH para garantir quedois pacotes não sejam armazenados no mesmo rack.

Para obter mais informações sobre os pers de codicação de eliminação, consulte http://

docs.ceph.com/docs/master/rados/operations/erasure-code-profile .

115 Perfis de codificação de eliminação SES 5

9.3 Pool com codificação de eliminação e camada decacheOs pools com codicação de eliminação requerem mais recursos do que os pools replicados enão têm algumas funcionalidades, como gravações parciais. Para compensar essas limitações, érecomendado denir uma camada de cache antes do pool com codicação de eliminação.

Por exemplo, se o pool “hot-storage” for constituído de armazenamento rápido, o “ecpool” criadona Seção 9.2, “Perfis de codificação de eliminação” poderá ser acelerado com:

root # ceph osd tier add ecpool hot-storageroot # ceph osd tier cache-mode hot-storage writebackroot # ceph osd tier set-overlay ecpool hot-storage

Isso colocará o pool “hot-storage” como uma camada do ecpool no modo write-back para quecada gravação e leitura no ecpool realmente usem o hot-storage e aproveitem os benefícios daexibilidade e velocidade.

Ao usar o FileStore, não é possível criar uma imagem RBD em um pool com codicação deeliminação, pois ele requer gravações parciais. No entanto, é possível criar uma imagem RBDem um pool com codicação de eliminação quando uma camada do pool replicado deniu umacamada de cache:

root # rbd --pool ecpool create --size 10 myvolume

Para obter mais informações sobre camadas de cache, consulte o Capítulo 10, Camadas de cache.

9.4 Pools com codificação de eliminação comdispositivo de blocos RADOSPara marcar um pool EC como pool RBD, sinalize-o de acordo:

root # ceph osd pool application enable rbd ec_pool_name

O RBD pode armazenar dados da imagem em pools EC. No entanto, o cabeçalho e os metadadosda imagem ainda precisam ser armazenados em um pool replicado. Considerando que você temum pool chamado “rbd” para esta nalidade:

root # rbd create rbd/image_name --size 1T --data-pool ec_pool_name

116 Pool com codificação de eliminação e camada de cache SES 5

Você pode usar a imagem normalmente, como qualquer outra, com exceção de que todos osdados serão armazenados no pool ec_pool_name em vez do “rbd”.

117 Pools com codificação de eliminação com dispositivo de blocos RADOS SES 5

10 Camadas de cache

A camada de cache é uma camada de armazenamento adicional implementada entre oarmazenamento de cliente e padrão. Ela foi criada para acelerar o acesso aos pools armazenadosem discos rígidos lentos e pools com codicação de eliminação.

Em geral, as camadas de cache envolvem a criação de um pool de dispositivos de armazenamentorelativamente rápidos e caros (por exemplo, unidades SSD), congurado para agir como umacamada de cache, e um pool de suporte de dispositivos mais lentos e baratos, congurado paraagir como uma camada de armazenamento.

10.1 Terminologia de armazenamento em camadas

As camadas de cache reconhecem dois tipos de pools: pool de cache e pool de armazenamento.

DicaPara obter informações gerais sobre pools, consulte o Capítulo  7, Gerenciando pools de

armazenamento.

pool de armazenamento

Um pool replicado padrão que armazena várias cópias de um objeto no cluster dearmazenamento do Ceph ou um pool com codicação de eliminação (consulte o Capítulo 9,

Pools com codificação de eliminação).O pool de armazenamento algumas vezes é chamado de “suporte” ou de armazenamento“a frio”.

pool de cache

Um pool replicado padrão armazenado em um dispositivo relativamente pequeno, porémrápido, com seu próprio conjunto de regras em um Mapa CRUSH.O pool de cache também é chamado de armazenamento “a quente”.

118 Terminologia de armazenamento em camadas SES 5

10.2 Pontos a serem consideradosAs camadas de cache podem prejudicar o desempenho do cluster para cargas de trabalhoespecícas. Os pontos a seguir mostram alguns dos aspectos que você precisa levar emconsideração:

Dependente da carga de trabalho: A melhoria no desempenho dependerá da carga detrabalho. Como existe um custo associado à adição ou remoção de objetos do cache, talvezseja melhor que a maioria das solicitações acesse o menor número de objetos. O pool decache deve ser grande o suciente para capturar o conjunto ativo de sua carga de trabalhopara evitar sobrecarga.

Benchmark difícil: A maioria dos benchmarks apresenta baixo desempenho com camadasde cache. O motivo é que elas solicitam um conjunto grande de objetos e leva muito tempopara “aquecer” o cache.

Desempenho possivelmente baixo: Para cargas de trabalho não adequadas às camadas decache, o desempenho costuma ser menor do que um pool replicado comum sem as camadasde cache habilitadas.

Enumeração de objetos do librados : Se a replicação usa o librados diretamente e executaa enumeração de objetos, as camadas de cache talvez não funcionem conforme esperado.(Isso não é um problema para o Object Gateway, RBD ou CephFS.)

10.3 Quando usar as camadas de cacheConsidere usar as camadas de cache nos seguintes casos:

Você precisa acessar pools com codicação de eliminação por meio do Dispositivo deBlocos RADOS (RBD).

Você precisa acessar pools com codicação de eliminação pelo iSCSI, já que ele herda aslimitações do RBD. Para obter mais informações sobre o iSCSI, consulte o Capítulo 12, Ceph

iSCSI Gateway.

Você tem um número limitado de armazenamento de alto desempenho e uma grandecoleção de armazenamento de baixo desempenho e precisa acessar os dados armazenadosmais rapidamente.

119 Pontos a serem considerados SES 5

10.4 Modos de cache

O agente de camadas de cache processa a migração de dados entre a camada de cache e a camadade armazenamento de suporte. Os administradores podem congurar o modo de execução dessamigração. Há dois cenários principais:

modo write-back

No modo write-back, os clientes do Ceph gravam dados na camada de cache e recebemuma conrmação (ACK) da camada de cache. No momento certo, os dados gravados nacamada de cache são migrados para a camada de armazenamento e eliminados da camadade cache. Conceitualmente, a camada de cache é sobreposta “na frente” da camada dearmazenamento de suporte. Quando um cliente do Ceph precisa de dados que residemna camada de armazenamento, o agente de camadas de cache os migra para a camadade cache na leitura e, em seguida, eles são enviados ao cliente do Ceph. Na sequência, ocliente do Ceph poderá executar a E/S usando a camada de cache, até que os dados setornem inativos. Esse procedimento é ideal para dados mutáveis, como edição de fotos ouvídeo, ou dados transacionais.

modo apenas leitura

No modo apenas leitura, os clientes do Ceph gravam dados diretamente na camada desuporte. Na leitura, o Ceph copia os objetos solicitados da camada de suporte para a camadade cache. Os objetos obsoletos são removidos da camada de cache de acordo com a políticadenida. Essa abordagem é ideal para dados imutáveis, como apresentação de fotos ouvídeos em uma rede social, dados de DNA ou imagens de raio X, porque a leitura de dadosde um pool de cache que possa conter dados desatualizados oferece pouca consistência.Não use o modo apenas leitura para dados mutáveis.

10.5 Conjunto de acertos

10.5.1 Visão geral

Os parâmetros de conjunto de acertos permitem o ajuste de pools de cache. Normalmente, osconjuntos de acertos no Ceph são ltros de Bloom e um método eciente, em termos de uso dememória, para monitorar objetos que já estão no pool de cache.

120 Modos de cache SES 5

O conjunto de acertos é uma matriz de bits usada para armazenar o resultado de um grupo defunções de hash aplicadas a nomes de objetos. Inicialmente, todos os bits estão denidos como0 . Quando um objeto é adicionado ao conjunto de acertos, um hash é executado com o nomedele, e o resultado é mapeado em diferentes posições no conjunto de acertos, em que o valordo bit é denido como 1 .

Para saber se existe um objeto no cache, um novo hash é executado com o nome do objeto.Se houver algum bit como 0 , denitivamente o objeto não estará no cache, e será necessáriorecuperá-lo do armazenamento a frio.

Os resultados de objetos diferentes podem ser armazenados no mesmo local que o conjuntode acertos. Existe a possibilidade de todos os bits serem 1 sem que o objeto esteja no cache.Portanto, os conjuntos de acertos que trabalham com um ltro de Bloom apenas podem informarse um objeto denitivamente não está no cache e precisa ser recuperado do armazenamentoa frio.

Um pool de cache pode ter mais do que um conjunto de acertos monitorando o acesso a arquivosao longo do tempo. A conguração hit_set_count dene quantos conjuntos de acertos estãoem uso, e hit_set_period dene por quanto tempo cada conjunto de acertos foi usado.Após a expiração do período, o próximo conjunto de acertos será utilizado. Se o número deconjuntos de acertos se esgotar, a memória do conjunto de acertos mais antigo será liberada,e um novo conjunto de acertos será criado. Os valores de hit_set_count e hit_set_periodmultiplicados um pelo outro denem o período geral de monitoramento do acesso aos objetos.

FIGURA 10.1: FILTRO DE BLOOM COM 3 OBJETOS ARMAZENADOS

121 Visão geral SES 5

Se comparado com o número de objetos com hash, um conjunto de acertos baseado em um ltrode Bloom é muito eciente em termos de uso de memória. Menos do que 10 bits são necessáriospara reduzir a probabilidade de falsos positivos para menos do que 1%. A probabilidade de falsospositivos pode ser denida com hit_set_fpp . Com base no número de objetos em um grupode posicionamento e na probabilidade de falsos positivos, o Ceph calcula automaticamente otamanho do conjunto de acertos.

O armazenamento necessário no pool de cache pode ser limitado commin_write_recency_for_promote e min_read_recency_for_promote . Se o valor fordenido como 0 , todos os objetos serão promovidos para o pool de cache assim que forem lidosou gravados, e esse comportamento se manterá até que eles sejam eliminados. Qualquer valormaior do que 0 dene o número de conjuntos de acertos que são pesquisados para o objeto,ordenado por data. Se o objeto for encontrado em um conjunto de acertos, ele será promovidopara o pool de cache.

10.5.2 Exemplos

10.5.2.1 Pool de cache grande e pouca memória

Em caso de muito armazenamento e pouca quantidade de RAM disponível, é possível promovertodos os objetos para o pool de cache logo que são acessados. O conjunto de acertos sem mantémpequeno. Veja a seguir um conjunto de valores de conguração de exemplo:

hit_set_count = 1hit_set_period = 3600hit_set_fpp = 0.05min_write_recency_for_promote = 0min_read_recency_for_promote = 0

10.5.2.2 Pool de cache pequeno e muita memória

Em caso de uma pequena quantidade de armazenamento, mas uma quantidade de memóriadisponível igualmente grande, é possível congurar a camada de cache para promover umnúmero limitado de objetos para o pool de cache. Doze conjuntos de acertos, dos quais cada um

122 Exemplos SES 5

é usado durante um período de 14.400 segundos, efetuam o monitoramento em um total de 48horas. Se um objeto foi acessado nas últimas 8 horas, ele é promovido para o pool de cache.Portanto, o conjunto de valores de conguração de exemplo é:

hit_set_count = 12hit_set_period = 14400hit_set_fpp = 0.01min_write_recency_for_promote = 2min_read_recency_for_promote = 2

10.6 Configurando um armazenamento em camadasde exemploEsta seção mostra como congurar uma camada de cache de SSD rápida (armazenamento aquente) na frente de um disco rígido padrão (armazenamento a frio).

DicaO exemplo a seguir é apenas para ns de ilustração e inclui uma conguração com umaraiz e uma regra para a parte da SSD que reside em um único nó do Ceph.

No ambiente de produção, as congurações do cluster normalmente incluem maisentradas raiz e de regra para o armazenamento a quente e também nós mistos, com SSDse discos SATA.

1. Prepare uma máquina de host com unidades rápidas, como SSDs. Esse nó de cluster servirácomo uma camada de cache rápida.

2. Torne a máquina um nó do Ceph usando o DeepSea. Instale o software e congure amáquina de host conforme descrito na Seção 1.1, “Adicionando novos nós do cluster”. Vamossupor que o nome seja node-4 . Esse nó precisa ter 4 discos OSD.Isso pode resultar em uma entrada como esta no mapa CRUSH:

[...]host node-4 { id -5 # do not change unnecessarily # weight 0.012 alg straw hash 0 # rjenkins1

123 Configurando um armazenamento em camadas de exemplo SES 5

item osd.6 weight 0.003 item osd.7 weight 0.003 item osd.8 weight 0.003 item osd.9 weight 0.003}[...]

3. Edite o mapa CRUSH do pool de armazenamento a quente mapeado para os OSDs queresidem nas unidades SSD rápidas. Dena uma segunda hierarquia com um nó raiz paraas SSDs (como “root ssd”). Mude também o peso e uma regra CRUSH para as SSDs. Paraobter mais informações sobre o mapa CRUSH, consulte http://docs.ceph.com/docs/master/

rados/operations/crush-map/ .Edite o mapa CRUSH diretamente com as ferramentas de linha de comando, comogetcrushmap e crushtool :

a. Recupere o mapa atual e grave-o como c.map :

cephadm > sudo ceph osd getcrushmap -o c.map

b. Descompile c.map e grave-o como c.txt :

cephadm > crushtool -d c.map -o c.txt

c. Edite c.txt :

[...]host node-4 { id -5 # do not change unnecessarily # weight 4.000 alg straw hash 0 # rjenkins1 item osd.6 weight 1.000 item osd.7 weight 1.000 item osd.8 weight 1.000 item osd.9 weight 1.000}root ssd { # newly added root for the SSD hot-storage id -6 alg straw hash 0 item node-4 weight 4.00}rule ssd { ruleset 4

124 Configurando um armazenamento em camadas de exemplo SES 5

type replicated min_size 0 max_size 4 step take ssd step chooseleaf firstn 0 type host step emit}[...]

d. Compile o arquivo c.txt editado e grave-o como ssd.map :

cephadm > crushtool -c c.txt -o ssd.map

e. Por m, instale ssd.map como o novo mapa CRUSH:

cephadm > sudo ceph osd setcrushmap -i ssd.map

4. Crie o pool de armazenamento a quente que será usado nas camadas de cache. Use a novaregra “ssd” para ele:

cephadm > sudo ceph osd pool create hot-storage 100 100 replicated ssd

5. Crie o pool de armazenamento a frio usando a regra “replicated_ruleset” padrão:

cephadm > sudo ceph osd pool create cold-storage 100 100 replicated replicated_ruleset

6. Em seguida, a conguração de uma camada de cache envolverá associar um pool dearmazenamento de suporte a um pool de cache. Neste caso, armazenamento a frio (=pool de armazenamento) a armazenamento a quente (= pool de cache):

cephadm > sudo ceph osd tier add cold-storage hot-storage

7. Para denir o modo de cache como “writeback”, execute o seguinte:

cephadm > sudo ceph osd tier cache-mode hot-storage writeback

Para obter mais informações sobre modos de cache, consulte a Seção 10.4, “Modos de cache”.

125 Configurando um armazenamento em camadas de exemplo SES 5

As camadas de cache writeback sobrepõem a camada de armazenamento de suporte,portanto, elas requerem uma etapa adicional: você deve direcionar todo o tráfego docliente do pool de armazenamento para o pool de cache. Por exemplo, para direcionar otráfego do cliente diretamente para o pool de cache, execute o seguinte:

cephadm > sudo ceph osd tier set-overlay cold-storage hot-storage

10.6.1 Configurando uma camada de cache

Há várias opções que você pode usar para congurar camadas de cache. Use a seguinte sintaxe:

cephadm > sudo ceph osd pool set cachepool key value

10.6.1.1 Tamanho e tipo de destino

As seguintes etapas descrevem como congurar um pool de cache com os valores apresentadosna Seção 10.5.2.2, “Pool de cache pequeno e muita memória”.

As camadas de cache de produção do Ceph usam um Filtro de Bloom para hit_set_type :

cephadm > sudo ceph osd pool set cachepool hit_set_type bloom

O hit_set_count e o hit_set_period denem quanto tempo cada conjunto de acertos devecobrir e quantos desses conjuntos de acertos devem ser armazenados.

cephadm > sudo ceph osd pool set cachepool hit_set_count 12cephadm > sudo ceph osd pool set cachepool hit_set_period 14400cephadm > sudo ceph osd pool set cachepool target_max_bytes 1000000000000

NotaUm hit_set_count maior resulta em mais memória RAM consumida pelo processoceph-osd .

O min_read_recency_for_promote dene em quantos conjuntos de acertos se deve vericara existência de um objeto ao processar uma operação de leitura. O resultado da vericação éusado para decidir se é para promover o objeto de forma assíncrona. O valor dele deve ser entre0 e hit_set_count . Se denido como 0, o objeto sempre será promovido. Se denido como 1,o conjunto atual de acertos será vericado. E se esse objeto estiver no conjunto atual de acertos,

126 Configurando uma camada de cache SES 5

ele será promovido. Caso contrário, não. Para os outros valores, o número exato de conjuntosde acertos de armazenamento será vericado. O objeto será promovido se for encontrado emqualquer um dos min_read_recency_for_promote conjuntos de acertos mais recentes.

Você pode denir um parâmetro similar, min_write_recency_for_promote , para a operaçãode gravação:

cephadm > sudo ceph osd pool set cachepool min_read_recency_for_promote 2cephadm > sudo ceph osd pool set cachepool min_write_recency_for_promote 2

NotaQuanto maior o período e maior os valores min_read_recency_for_promote

e min_write_recency_for_promote , mais RAM o daemon ceph-osd consome.Especicamente, quando o agente está ativo para descarregar ou eliminar objetos docache, todos os hit_set_count conjuntos de acertos são carregados na memória RAM.

10.6.1.2 Tamanho do cache

O agente de camadas de cache executa duas funções principais:

Descarregar

O agente identica objetos modicados e os encaminha ao pool de armazenamento paraarmazenamento de longo prazo.

Eliminar

O agente identica objetos que não foram modicados (limpos) e elimina do cache os queestão sem uso há mais tempo.

10.6.1.2.1 Tamanho absoluto

O agente de camadas de cache pode descarregar ou eliminar objetos com base no número totalde bytes ou no número total de objetos. Para especicar um número máximo de bytes, executeo seguinte:

cephadm > sudo ceph osd pool set cachepool target_max_bytes num_of_bytes

Para especicar o número máximo de objetos, execute o seguinte:

cephadm > sudo ceph osd pool set cachepool target_max_objects num_of_objects

127 Configurando uma camada de cache SES 5

NotaO Ceph não pode determinar o tamanho de um pool de cache automaticamente, portanto,a conguração com base no tamanho absoluto é necessária neste caso. Do contrário, odescarregamento e a eliminação não funcionarão. Se você especicar os dois limites, oagente de camadas de cache iniciará o descarregamento ou a eliminação quando um doslimites for acionado.

NotaTodas as solicitações de cliente serão bloqueadas apenas quando target_max_bytes outarget_max_objects for atingido.

10.6.1.2.2 Tamanho relativo

O agente de camadas de cache pode descarregar ou eliminar objetos relativos ao tamanhodo pool de cache (especicado por target_max_bytes ou target_max_objects naSeção  10.6.1.2.1, “Tamanho absoluto”). Quando o pool de cache consistir em determinadaporcentagem de objetos modicados, o agente de camadas de cache os descarregará para o poolde armazenamento. Para denir o valor cache_target_dirty_ratio , execute o seguinte:

cephadm > sudo ceph osd pool set cachepool cache_target_dirty_ratio 0.0...1.0

Por exemplo, a denição do valor como 0,4 iniciará o descarregamento dos objetos modicadosquando eles atingirem 40% da capacidade do pool de cache:

cephadm > sudo ceph osd pool set hot-storage cache_target_dirty_ratio 0.4

Quando os objetos modicados atingirem determinada porcentagem da capacidade,descarregue-os a uma velocidade mais alta. Use cache_target_dirty_high_ratio :

cephadm > sudo ceph osd pool set cachepool cache_target_dirty_high_ratio 0.0..1.0

Quando o pool de cache atingir determinada porcentagem da sua capacidade, o agente decamadas de cache eliminará os objetos para manter a capacidade livre. Para denir o valorcache_target_full_ratio , execute o seguinte:

cephadm > sudo ceph osd pool set cachepool cache_target_full_ratio 0.0..1.0

128 Configurando uma camada de cache SES 5

10.6.1.3 Data do cache

Você pode especicar a data mínima de um objeto recém-modicado a partir da qual o agentede camadas de cache o descarregará para o pool de armazenamento de suporte:

cephadm > sudo ceph osd pool set cachepool cache_min_flush_age num_of_seconds

Você pode especicar a data mínima de um objeto para ele ser eliminado da camada de cache:

cephadm > sudo ceph osd pool set cachepool cache_min_evict_age num_of_seconds

10.6.1.4 Usar GMT para conjunto de acertos

As congurações de camada de cache têm um ltro de Bloom denominado conjunto de acertos.O ltro faz um teste para identicar se um objeto pertence a determinado conjunto de objetosa quente ou a frio. Os objetos são adicionados ao conjunto de acertos usando marcações dehorário anexadas aos nomes deles.

Se as máquinas de cluster forem colocadas em fusos horários diferentes, e as marcações dehorário forem extraídas do horário local, os objetos em um conjunto de acertos poderão ternomes equivocados indicando marcações de horário futuras ou passadas. Na pior das hipóteses,os objetos podem nem existir no conjunto de acertos.

Para que isso não aconteça, use_gmt_hitset é denido como o padrão “1” nas conguraçõesde camada de cache recém-criadas. Dessa forma, você força os OSDs a usar as marcações dehorário GMT (Horário de Greenwich) durante a criação dos nomes de objetos para o conjuntode acertos.

Atenção: Manter o valor padrãoNão modique o valor padrão “1” de use_gmt_hitset . Se os erros relacionados a essaopção não forem causados pela conguração do cluster, nunca a modique manualmente.Do contrário, o comportamento do cluster poderá ser imprevisível.

129 Configurando uma camada de cache SES 5

III Acessando os dados do cluster

11 Ceph Object Gateway 131

12 Ceph iSCSI Gateway 178

13 Sistema de arquivos em cluster 196

14 NFS Ganesha: Exportar dados do Ceph pelo NFS 205

11 Ceph Object Gateway

Este capítulo apresenta detalhes sobre as tarefas de administração relacionadas ao ObjectGateway, como vericação de status do serviço, gerenciamento de contas, gateways multissiteou autenticação LDAP.

11.1 Restrições e limitações de nomeação do ObjectGatewayVeja a seguir uma lista dos limites importantes do Object Gateway:

11.1.1 Limitações de compartimento de memória

Ao usar o Object Gateway por meio da API do S3, há um limite para os nomes de compartimentode memória que devem ser compatíveis com DNS e podem ter um traço “-”. Ao usar o ObjectGateway por meio da API do Swift, você pode aplicar qualquer combinação de caracteres UTF-8permitidos, exceto a barra “/”. O tamanho máximo do nome de um compartimento de memóriaé de 255 caracteres. Os nomes de compartimento de memória devem ser exclusivos.

Dica: Usar nomes de compartimento de memória compatíveiscom DNSEmbora seja possível usar qualquer nome de compartimento de memória baseado emUTF-8 por meio da API do Swift, é recomendável nomear os compartimentos de memóriade acordo com as limitações de nomeação do S3 para evitar problemas ao acessar o mesmocompartimento de memória pela API do S3.

11.1.2 Limitações de objetos armazenados

Número máximo de objetos por usuário

Por padrão, nenhuma restrição (limitado por ~ 2^63).

Número máximo de objetos por compartimento de memória

Por padrão, nenhuma restrição (limitado por ~ 2^63).

131 Restrições e limitações de nomeação do Object Gateway SES 5

Tamanho máximo de um objeto para upload/armazenamento

Cada upload está restrito a 5 GB. Use várias partes para tamanhos de objetos maiores. Onúmero máximo de pacotes de várias partes é 10.000.

11.1.3 Limitações de cabeçalho HTTP

A limitação de cabeçalho HTTP e de solicitação depende do front end da Web usado. O CivetWebpadrão restringe o número de cabeçalhos HTTP a 64 e o tamanho a 16 KB cada.

11.2 Implantando o Object GatewayO método recomendado de implantar o Ceph Object Gateway é pela infraestrutura do DeepSea,adicionando a(s) linha(s) role-rgw [...] relevante(s) ao arquivo policy.cfg no master Salte executando as fases necessárias do DeepSea.

Para incluir o Object Gateway durante o processo de implantação do cluster do Ceph,consulte o Livro “Guia de Implantação”, Capítulo 4 “Implantando com o DeepSea/Salt”, Seção 4.3

“Implantação do cluster” e o Livro “Guia de Implantação”, Capítulo 4 “Implantando com o DeepSea/

Salt”, Seção 4.5.1 “Arquivo policy.cfg”.

Para adicionar a função Object Gateway a um cluster já implantado, consulte a Seção 1.2,

“Adicionando novas funções aos nós”.

11.3 Operando o serviço Object GatewayO serviço Object Gateway é operado pelo comando systemctl . Você precisa ter privilégios deroot para operar o serviço Object Gateway. Observe que gateway_host é o nome de host doservidor cuja instância do Object Gateway você precisa operar.

Os subcomandos a seguir são suportados para o serviço Object Gateway:

systemctl status ceph-radosgw@rgw. gateway_host

Imprime as informações de status do serviço

systemctl start ceph-radosgw@rgw. gateway_host

Inicia o serviço caso ainda não esteja em execução.

132 Limitações de cabeçalho HTTP SES 5

systemctl restart ceph-radosgw@rgw. gateway_host

Reinicia o serviço.

systemctl stop ceph-radosgw@rgw. gateway_host

Para o serviço em execução.

systemctl enable ceph-radosgw@rgw. gateway_host

Habilita o serviço para que ele seja iniciado automaticamente na inicialização do sistema.

systemctl disable ceph-radosgw@rgw. gateway_host

Desabilita o serviço para que ele não seja iniciado automaticamente na inicialização dosistema.

11.4 Parâmetros de configuração

O comportamento do Object Gateway pode ser afetado por inúmeras opções no arquivoceph.conf . Veja a seguir uma lista das mais importantes. Para ver a lista completa, consultehttp://docs.ceph.com/docs/master/radosgw/config-ref/ .

rgw_thread_pool_size

Número de threads para o servidor CivetWeb. Aumente para um valor mais alto se vocêprecisa atender a mais solicitações. O padrão é 100 threads.

rgw_num_rados_handles

O número de manipuladores de cluster RADOS (consulte http://docs.ceph.com/

docs/master/rados/api/librados-intro/#step-2-configuring-a-cluster-handle ) para o ObjectGateway. Disponibilizar um número congurável de manipuladores RADOS tem resultadoem um aumento signicativo no desempenho para todos os tipos de cargas de trabalho.Agora, cada thread do worker do Object Gateway precisa selecionar um manipuladorRADOS para sua vida útil. O padrão é 1.

rgw_max_chunk_size

Tamanho máximo de um pacote de dados que será lido em uma única operação. Aumentaro valor para 4 MB (4194304) proporcionará um melhor desempenho ao processar objetosgrandes. O padrão é 128 KB (131072).

133 Parâmetros de configuração SES 5

11.4.1 Notas adicionais

rgw dns name

Se o parâmetro rgw dns name for adicionado a ceph.conf , verique se o cliente S3 foicongurado para direcionar as solicitações no endpoint especicado por rgw dns name .

11.5 Gerenciando o acesso ao Object GatewayVocê pode se comunicar com o Object Gateway usando qualquer interface compatível com S3ou Swift. A interface do S3 é compatível com um grande subconjunto da API RESTful do AmazonS3. A interface do Swift é compatível com um grande subconjunto da API do OpenStack Swift.

As duas interfaces exigem que você crie um usuário especíco e instale o software clienterelevante para comunicação com o gateway usando a chave secreta do usuário.

11.5.1 Acessando o Object Gateway

11.5.1.1 Acesso à interface do S3

Para acessar a interface do S3, você precisa de um cliente REST. S3cmd é um clienteS3 de linha de comando. Você pode encontrá-lo em OpenSUSE Build Service (https://

build.opensuse.org/package/show/Cloud:Tools/s3cmd) . O repositório contém as versões paraambas as distribuições baseadas no SUSE Linux Enterprise e no openSUSE.

Para testar o acesso à interface do S3, você também pode gravar um pequeno script doPython. O script se conectará ao Object Gateway, criará um novo compartimento de memóriae listará todos os compartimentos de memória. Os valores para aws_access_key_id eaws_secret_access_key são extraídos dos valores de access_key e secret_key retornadospelo comando radosgw_admin da Seção 11.5.2.1, “Adicionando usuários do S3 e do Swift”.

1. Instale o pacote python-boto :

sudo zypper in python-boto

2. Crie um novo script do Python denominado s3test.py com o seguinte conteúdo:

import botoimport boto.s3.connection

134 Notas adicionais SES 5

access_key = '11BS02LGFB6AL6H1ADMW'secret_key = 'vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY'conn = boto.connect_s3(aws_access_key_id = access_key,aws_secret_access_key = secret_key,host = '{hostname}',is_secure=False,calling_format = boto.s3.connection.OrdinaryCallingFormat(),)bucket = conn.create_bucket('my-new-bucket')for bucket in conn.get_all_buckets(): print "{name}\t{created}".format( name = bucket.name, created = bucket.creation_date, )

Substitua {hostname} pelo nome de host no qual você congurou o serviço ObjectGateway. Por exemplo, gateway_host .

3. Execute o script:

python s3test.py

A saída do script é parecida com o seguinte:

my-new-bucket 2015-07-22T15:37:42.000Z

11.5.1.2 Acesso à interface do Swift

Para acessar o Object Gateway pela interface do Swift, você precisa do cliente de linha decomando swift . A página de manual dele man 1 swift apresenta mais detalhes sobre asopções de linha de comando.

O pacote está incluído no módulo “Public Cloud” (Nuvem Pública) do SUSE Linux Enterprise12 SP3. Antes de instalar o pacote, você precisa ativar o módulo e atualizar o repositório desoftware:

sudo SUSEConnect -p sle-module-public-cloud/12/x86_64sudo zypper refresh

Para instalar o comando swift , execute o seguinte:

sudo zypper in python-swiftclient

135 Acessando o Object Gateway SES 5

O acesso ao swift usa a seguinte sintaxe:

swift -A http://IP_ADDRESS/auth/1.0 \-U example_user:swift -K 'swift_secret_key' list

Substitua IP_ADDRESS pelo endereço IP do servidor gateway, e swift_secret_key pelorespectivo valor da saída do comando radosgw-admin key create executado para o usuárioswift na Seção 11.5.2.1, “Adicionando usuários do S3 e do Swift”.

Por exemplo:

swift -A http://gateway.example.com/auth/1.0 -U example_user:swift \-K 'r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h' list

A saída é:

my-new-bucket

11.5.2 Gerenciando contas do S3 e do Swift

11.5.2.1 Adicionando usuários do S3 e do Swift

É necessário criar um usuário, uma chave de acesso e um segredo para permitir que os usuáriosnais interajam com o gateway. Há dois tipos de usuário: usuário e subusuário. Os usuários sãousados para interagir com a interface do S3, os subusuários são usuáros da interface do Swift.Cada subusuário está associado a um usuário.

Os usuários também podem ser adicionados por meio do arquivo rgw.sls do DeepSea. Paraobter um exemplo, consulte a Seção 14.3.1, “Usuários diferentes do Object Gateway para NFS Ganesha”.

Para criar um usuário do Swift, siga as etapas:

1. Para criar um usuário do Swift, que é um subusuário em nossa terminologia, você precisacriar primeiro o usuário associado.

sudo radosgw-admin user create --uid=username \ --display-name="display-name" --email=email

Por exemplo:

sudo radosgw-admin user create \ --uid=example_user \ --display-name="Example User" \

136 Gerenciando contas do S3 e do Swift SES 5

--email=penguin@example.com

2. Para criar um subusuário (interface do Swift) para o usuário, você deve especicar oID de usuário (--uid= nomedeusuário ), um ID de subusuário e o nível de acesso para osubusuário.

sudo radosgw-admin subuser create --uid=uid \ --subuser=uid \ --access=[ read | write | readwrite | full ]

Por exemplo:

sudo radosgw-admin subuser create --uid=example_user \ --subuser=example_user:swift --access=full

3. Gere uma chave secreta para o usuário.

sudo radosgw-admin key create \ --gen-secret \ --subuser=example_user:swift \ --key-type=swift

4. Os dois comandos resultarão em dados formatados em JSON que mostram o estado dousuário. Observe as linhas a seguir e lembre-se do valor secret_key :

"swift_keys": [ { "user": "example_user:swift", "secret_key": "r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h"}],

Ao acessar o Object Gateway por meio da interface do S3, você precisa criar um usuário doS3 executando:

sudo radosgw-admin user create --uid=username \ --display-name="display-name" --email=email

Por exemplo:

sudo radosgw-admin user create \ --uid=example_user \ --display-name="Example User" \ --email=penguin@example.com

O comando também cria o acesso do usuário e a chave secreta. Verique a saída para as palavras-chave access_key e secret_key e seus valores:

[...]

137 Gerenciando contas do S3 e do Swift SES 5

"keys": [ { "user": "example_user", "access_key": "11BS02LGFB6AL6H1ADMW", "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}], [...]

11.5.2.2 Removendo usuários do S3 e do Swift

O procedimento para apagar usuários é semelhante para os usuários do S3 e do Swift. No casodos usuários do Swift, porém, você pode precisar apagar o usuário com os subusuários incluídos.

Para remover um usuário do S3 ou do Swift (incluindo todos os subusuários), especique userrm e o ID de usuário no seguinte comando:

sudo radosgw-admin user rm --uid=example_user

Para remover um subusuário, especique subuser rm e o ID de subusuário.

sudo radosgw-admin subuser rm --uid=example_user:swift

Você pode usar as seguintes opções:

--purge-data

Purga todos os dados associados ao ID de usuário.

--purge-keys

Purga todas as chaves associadas ao ID de usuário.

Dica: Removendo um subusuárioAo remover um subusuário, você remove o acesso à interface do Swift. O usuáriopermanecerá no sistema.

11.5.2.3 Mudando o acesso e as chaves secretas do usuário do S3 e do Swift

Os parâmetros access_key e secret_key identicam o usuário do Object Gateway ao acessaro gateway. A mudança das chaves existentes de usuário é o mesmo que criar novas chaves, poisas chaves antigas são sobregravadas.

Para usuários do S3, execute o seguinte:

sudo radosgw-admin key create --uid=example_user --key-type=s3 --gen-access-key --gen-secret

138 Gerenciando contas do S3 e do Swift SES 5

Para usuários do Swift, execute o seguinte:

sudo radosgw-admin key create --subuser=example_user:swift --key-type=swift --gen-secret

--key-type=type

Especica o tipo de chave. Pode ser swift ou s3 .

--gen-access-key

Gera uma chave de acesso aleatória (por padrão, para o usuário do S3).

--gen-secret

Gera uma chave secreta aleatória.

--secret=key

Especica uma chave secreta. Por exemplo, gerada manualmente.

11.5.2.4 Gerenciamento de cotas de usuário

O Ceph Object Gateway permite denir cotas para usuários e compartimentos de memóriapertencentes aos usuários. As cotas incluem o número máximo de objetos em um compartimentode memória e o tamanho máximo de armazenamento em megabytes.

Antes de habilitar uma cota de usuário, você precisa denir os respectivos parâmetros:

sudo radosgw-admin quota set --quota-scope=user --uid=example_user \ --max-objects=1024 --max-size=1024

--max-objects

Especica o número máximo de objetos. Um valor negativo desabilita a vericação.

--max-size

Especica o número máximo de bytes. Um valor negativo desabilita a vericação.

--quota-scope

Dene o escopo para a cota. As opções são bucket e user . As cotas de compartimentode memória aplicam-se aos compartimentos de memória que um usuário possui. As cotasde usuário aplicam-se a um usuário.

Após denir uma cota de usuário, você poderá habilitá-la:

sudo radosgw-admin quota enable --quota-scope=user --uid=example_user

139 Gerenciando contas do S3 e do Swift SES 5

Para desabilitar uma cota:

sudo radosgw-admin quota disable --quota-scope=user --uid=example_user

Para listar as congurações de cota:

sudo radosgw-admin user info --uid=example_user

Para atualizar as estatísticas de cota:

sudo radosgw-admin user stats --uid=example_user --sync-stats

11.6 Habilitando HTTPS/SSL para Object GatewaysPara habilitar a função Object Gateway padrão para comunicação segura por meio de SSL,você precisa ter um certicado emitido por uma CA ou criar um autoassinado. Há duasmaneiras de congurar o Object Gateway com HTTPS habilitado: uma maneira simples queusa as congurações padrão e uma maneira avançada que permite ajustar as conguraçõesrelacionadas a HTTPS.

11.6.1 Criar um certificado autoassinado

DicaIgnore esta seção se você já tem um certicado válido assinado por uma CA.

Por padrão, o DeepSea espera o arquivo de certicado em /srv/salt/ceph/rgw/cert/

rgw.pem no master Salt. Em seguida, ele distribuirá o certicado para /etc/ceph/rgw.pem nominion Salt com a função Object Gateway, onde o Ceph faz a leitura.

O procedimento a seguir descreve como gerar um certicado SSL autoassinado no nó master Salt.

1. Adicione a opção subjectAltName à seção [v3_req] do arquivo /etc/ssl/

openssl.cnf para todos os nomes de host desejados para o seu Object Gateway:

[...][ v3_req ]subjectAltName = ${ENV::SAN}[...]

140 Habilitando HTTPS/SSL para Object Gateways SES 5

2. Crie a chave e o certicado usando openssl . Adicione o prexo env SAN=DNS:fqdnao openssl . Insira todos os dados que você precisa incluir em seu certicado. Érecomendável inserir o FQDN como nome comum. Antes de assinar o certicado, veriquese “X509v3 Subject Alternative Name:” está incluído nas extensões solicitadas e se ocerticado resultante tem "X509v3 Subject Alternative Name:" denido.

root@master # env SAN=DNS:fqdn openssl req -x509 -nodes -days 1095 \ -newkey rsa:4096 -keyout rgw.key -out /srv/salt/ceph/rgw/cert/rgw.pem

11.6.2 Configuração de HTTPS simples

Por padrão, o Ceph no nó do Object Gateway lê o cericado /etc/ceph/rgw.pem e usa a porta443 para comunicação SSL segura. Se você não precisa mudar esses valores, siga estas etapas:

1. Edite /srv/pillar/ceph/stack/global.yml e adicione a seguinte linha:

rgw_configurations: rgw-sslrgw_init: default-ssl

2. Execute as Fases 2, 3 e 4 do DeepSea para aplicar as mudanças:

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

11.6.3 Configuração de HTTPS avançada

Se você precisar mudar os valores padrão para as congurações de SSL do Object Gateway, sigaestas etapas:

1. Copie a conguração de SSL do Object Gateway padrão para o subdiretório ceph.conf.d :

root@master # cp /srv/salt/ceph/configuration/files/rgw-ssl.conf \ /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf

2. Edite /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf e mude asopções padrão, como número da porte ou caminho para o certicado SSL, para reetirsua conguração.

141 Configuração de HTTPS simples SES 5

3. Execute as Fases 3 e 4 do DeepSea para aplicar as mudanças:

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

Dica: Vinculando a várias portasO servidor CivetWeb pode ser vinculado a várias portas. Isso será útil se você precisaracessar uma única instância do Object Gateway com ambas as conexões SSL e não SSL.Ao especicar as portas, separe os números usando um sinal de adição “+”. Veja a seguirum exemplo de linha de conguração de duas portas:

[client.{{ client }}]rgw_frontends = civetweb port=80+443s ssl_certificate=/etc/ceph/rgw.pem

11.7 Módulos de sincronização

A funcionalidade multissite do Object Gateway incluída no Jewel permite criar várias zonas eespelhar os dados e metadados entre elas. Os Módulos de Sincronização foram desenvolvidoscom base na estrutura multissite, que permite encaminhar dados e metadados para umacamada externa diferente. Um módulo de sincronização permite a execução de um conjuntode ações sempre que há uma mudança nos dados (operações de metadados, como criação decompartimento de memória ou usuário, etc., também são consideradas mudanças nos dados).Como as mudanças multissite do rgw acabam sendo consistentes em sites remotos, elas sãopropagadas de forma assíncrona. Desse modo, é possível desbloquear casos de uso, como backupde armazenamento de objetos em um cluster de nuvem externo ou em uma solução de backuppersonalizada que usa unidades de ta, indexação de metadados no Elasticsearch, etc.

11.7.1 Sincronizando zonas

A conguração de um módulo de sincronização é local para uma zona. O módulo desincronização determina se a zona exporta os dados ou apenas pode consumir os dados que forammodicados em outra zona. A partir do Luminous, os plug-ins de sincronização suportados sãoelasticsearch , rgw , que é o padrão para sincronizar dados entre zonas, e log , que é o comum

142 Módulos de sincronização SES 5

para registrar a operação de metadados que ocorre nas zonas remotas. As seções a seguir foramelaboradas com o exemplo de uma zona que usa o módulo de sincronização elasticsearch .O mesmo processo pode ser aplicado para congurar qualquer outro plug-in de sincronização.

Nota: Plug-in de sincronização padrãorgw é o plug-in de sincronização padrão, e não há necessidade de congurá-loexplicitamente.

11.7.1.1 Requisitos e considerações

Vamos considerar uma conguração multissite simples, conforme descrito na Seção 11.11, “Object

Gateways multissite”, com 2 zonas us-east e us-west . Agora, adicionamos uma terceira zonaus-east-es , que processará apenas os metadados de outros sites. Essa zona pode estar nomesmo ou em um cluster do Ceph diferente do us-east . Essa zona consumirá apenas osmetadados de outras zonas, e os Object Gateways nela não atenderão diretamente nenhumasolicitação de usuário nal.

11.7.1.2 Configurando módulos de sincronização

1. Crie a terceira zona semelhante àquelas descritas na Seção 11.11, “Object Gateways multissite”.Por exemplo,

root # radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \--access-key={system-key} --secret={secret} --endpoints=http://rgw-es:80

2. É possível congurar um módulo de sincronização para essa zona por meio do seguinteprocedimento

root # radosgw-admin zone modify --rgw-zone={zone-name} --tier-type={tier-type} \--tier-config={set of key=value pairs}

3. Por exemplo, no módulo de sincronização elasticsearch

root # radosgw-admin zone modify --rgw-zone={zone-name} --tier-type=elasticsearch \--tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1

Para as várias opções de conguração de camada suportadas, consulte a Seção  11.7.2,

“Armazenando metadados no Elasticsearch”.

143 Sincronizando zonas SES 5

4. Por m, atualize o período

root # radosgw-admin period update --commit

5. Agora, inicie o radosgw na zona

root # systemctl start ceph-radosgw@rgw.`hostname -s`root # systemctl enable ceph-radosgw@rgw.`hostname -s`

11.7.2 Armazenando metadados no Elasticsearch

Este módulo de sincronização grava os metadados de outras zonas no Elasticsearch. A partir doLuminous, é o JSON dos campos de dados que armazenamos no Elasticsearch.

{ "_index" : "rgw-gold-ee5863d6", "_type" : "object", "_id" : "34137443-8592-48d9-8ca7-160255d52ade.34137.1:object1:null", "_score" : 1.0, "_source" : { "bucket" : "testbucket123", "name" : "object1", "instance" : "null", "versioned_epoch" : 0, "owner" : { "id" : "user1", "display_name" : "user1" }, "permissions" : [ "user1" ], "meta" : { "size" : 712354, "mtime" : "2017-05-04T12:54:16.462Z", "etag" : "7ac66c0f148de9519b8bd264312c4d64" } }}

144 Armazenando metadados no Elasticsearch SES 5

11.7.2.1 Parâmetros de configuração de tipo de camada do Elasticsearch

endpoint

Especica o endpoint do servidor Elasticsearch a ser acessado.

num_shards

(número inteiro) O número de fragmentos que será congurado no Elasticsearch nainicialização da sincronização de dados. Observe que ele não pode ser mudado após ainicialização. Qualquer mudança aqui requer a reconstrução do índice do Elasticsearch ea reinicialização do processo de sincronização de dados.

num_replicas

(número inteiro) O número de réplicas que será congurado no Elasticsearch nainicialização da sincronização de dados.

explicit_custom_meta

(true | false) Especica se todos os metadados personalizados do usuário serão indexadosou se o usuário precisará congurar (no nível do compartimento de memória) quaisentradas de metadados do cliente devem ser indexadas. Por padrão, isso é “false”

index_buckets_list

(lista de strings separadas por vírgulas) Se vazia, todos os compartimentos de memóriaserão indexados. Do contrário, apenas os compartimentos de memória especicados nelaserão indexados. É possível inserir prexos (por exemplo, “foo*”) ou suxos (por exemplo,“*bar”) de compartimento de memória.

approved_owners_list

(lista de strings separadas por vírgulas) Se vazia, os compartimentos de memória de todosos proprietários serão indexados (sujeito a outras restrições); do contrário, apenas oscompartimentos de memória pertencentes a determinados proprietários serão indexados.É possível também inserir prexos e suxos.

override_index_path

(string) Se não estiver vazia, essa string será usado como caminho do índice doelasticsearch. Do contrário, o caminho do índice será determinado e gerado na inicializaçãoda sincronização.

145 Armazenando metadados no Elasticsearch SES 5

11.7.2.2 Consultas de metadados

Como o cluster do Elasticsearch agora armazena metadados de objetos, é importante não expor oendpoint do Elasticsearch ao público e mantê-lo acessível apenas aos administradores de cluster.A própria exposição das consultas de metadados ao usuário nal representa um problema, jáque desejamos que o usuário consulte apenas os metadados dele, e não de quaisquer outrosusuários. Para isso, o cluster do Elasticsearch deve autenticar os usuários de modo similar aoRGW, o que representa um problema.

A partir do Luminous, o RGW na zona master de metadados agora pode atender às solicitações deusuários nais. Isso evita a exposição do endpoint do Elasticsearch ao público e resolve tambémo problema de autenticação e autorização, pois o próprio RGW pode autenticar as solicitações deusuário nal. Para essa nalidade, o RGW inclui uma nova consulta nas APIs de compartimentode memória, que pode atender às solicitações do Elasticsearch. Todas essas solicitações devemser enviadas para a zona master de metadados.

Obter uma consulta do Elasticsearch

GET /BUCKET?query={query-expr}

parâmetros de solicitação:

max-keys: número máx. de entradas a retornar

marker: marcador de paginação

expression := [(]<arg> <op> <value> [)][<and|or> ...]

op é um dos seguintes: <, <=, ==, >=, >Por exemplo:

GET /?query=name==foo

Retornará todas as chaves indexadas para as quais o usuário tem permissão de leitura eque são denominadas “foo”. A saída será uma lista de chaves em XML, que é semelhanteà resposta de compartimentos de memória da lista do S3.

Configurar campos personalizados de metadados

Dena quais entradas de metadados personalizados devem ser indexadas (nocompartimento de memória especicado) e quais são os tipos das chaves. Se forcongurada a indexação explícita de metadados personalizados, esse procedimento será

146 Armazenando metadados no Elasticsearch SES 5

necessário para o rgw indexar os valores de metadados personalizados especicados. Docontrário, ele será necessário nos casos em que as chaves dos metadados indexados sãode um tipo diferente de string.

POST /BUCKET?mdsearchx-amz-meta-search: <key [; type]> [, ...]

Vários campos de metadados devem ser separados por vírgula. É possível forçar um tipopara um campo com “;”. Atualmente, os tipos permitidos são string (padrão), númerointeiro e data. Por exemplo, para indexar os metadados de objetos personalizados x-amz-meta-year como número inteiro, x-amz-meta-date como tipo de data e x-amz-meta-titlecomo string, você executa o seguinte

POST /mybooks?mdsearchx-amz-meta-search: x-amz-meta-year;int, x-amz-meta-release-date;date, x-amz-meta-title;string

Apague a configuração de metadados personalizados

Apague a conguração de compartimento de memória dos metadados personalizados.

DELETE /BUCKET?mdsearch

Obter a configuração dos metadados personalizados

Recupere a conguração de compartimento de memória dos metadados personalizados.

GET /BUCKET?mdsearch

11.8 Autenticação LDAPAlém da autenticação de usuário local padrão, o Object Gateway pode usar os serviços doservidor LDAP para autenticar também os usuários.

11.8.1 Mecanismo de autenticação

O Object Gateway extrai as credenciais de LDAP do usuário de um token. Um ltro de pesquisa éconstruído com base no nome de usuário. O Object Gateway usa a conta de serviço conguradapara pesquisar uma entrada correspondente no diretório. Se uma entrada for encontrada, oObject Gateway tentará se vincular ao nome exclusivo encontrado com a senha do token. Se ascredenciais forem válidas, o vínculo será bem-sucedido, e o Object Gateway concederá o acesso.

147 Autenticação LDAP SES 5

Você pode limitar os usuários permitidos denindo a base para a pesquisa como uma unidadeorganizacional especíca ou especicando um ltro de pesquisa personalizado. Por exemplo,exigir a participação em um grupo especíco, classes de objetos ou atributos personalizados.

11.8.2 Requisitos

LDAP ou Active Directory: Uma instância LDAP em execução acessível pelo Object Gateway.

Conta de serviço: Credenciais LDAP para uso do Object Gateway com permissões depesquisa.

Conta de usuário: Pelo menos, uma conta do usuário no diretório LDAP.

Importante: Não sobreponha usuários LDAP e locaisVocê não deve usar os mesmos nomes para usuários locais e usuários autenticados porLDAP. O Object Gateway não pode diferenciá-los e os trata como se fossem os mesmosusuários.

Dica: Verificações de integridadeUse o utilitário ldapsearch para vericar a conta de serviço ou a conexão LDAP. Porexemplo:

ldapsearch -x -D "uid=ceph,ou=system,dc=example,dc=com" -W \-H ldaps://example.com -b "ou=users,dc=example,dc=com" 'uid=*' dn

Use os mesmos parâmetros LDAP que o arquivo de conguração do Ceph para evitarpossíveis problemas.

11.8.3 Configurar o Object Gateway para usar a autenticação LDAP

Os seguintes parâmetros no arquivo de conguração /etc/ceph/ceph.conf estão relacionadosà autenticação LDAP:

rgw_ldap_uri

Especica o servidor LDAP a ser usado. Use o parâmetro ldaps://fqdn:porta para evitara transmissão aberta de credenciais de texto simples.

148 Requisitos SES 5

rgw_ldap_binddn

O DN (Distinguished Name – Nome Exclusivo) da conta de serviço usada pelo ObjectGateway.

rgw_ldap_secret

A senha para a conta de serviço.

rgw_ldap_searchdn

Especica a base na árvore de informações do diretório para pesquisar usuários. Ela podeser a unidade organizacional de usuários ou alguma OU (Organizational Unit – UnidadeOrganizacional) mais especíca.

rgw_ldap_dnattr

O atributo que está sendo usado no ltro de pesquisa construído para corresponder umnome de usuário. Dependendo da DIT (Directory Information Tree – Árvore de Informaçõesdo Diretório), ele provavelmente será uid ou cn .

rgw_search_filter

Se não for especicado, o Object Gateway construirá automaticamente o ltro de pesquisacom a conguração rgw_ldap_dnattr . Use esse parâmetro para restringir a lista deusuários permitidos com muita exibilidade. Consulte a Seção 11.8.4, “Usando um filtro de

pesquisa personalizado para limitar o acesso do usuário” para obter detalhes.

11.8.4 Usando um filtro de pesquisa personalizado para limitar oacesso do usuário

Você pode usar o parâmetro rgw_search_filter de duas maneiras.

11.8.4.1 Filtro parcial para limitar ainda mais o filtro de pesquisa construído

Veja a seguir um exemplo de ltro parcial:

"objectclass=inetorgperson"

149 Usando um filtro de pesquisa personalizado para limitar o acesso do usuário SES 5

O Object Gateway gerará o ltro de pesquisa como de costume com o nome de usuário extraídodo token e o valor de rgw_ldap_dnattr . Em seguida, o ltro construído será combinado aoltro parcial com base no atributo rgw_search_filter . Dependendo do nome de usuário e dascongurações, o ltro de pesquisa nal poderá ser:

"(&(uid=hari)(objectclass=inetorgperson))"

Nesse caso, o usuário “hari” apenas receberá acesso se for encontrado no diretório LDAP, setiver uma classe de objeto “inetorgperson” e se especicar uma senha válida.

11.8.4.2 Filtro completo

Um ltro completo deve conter um token USERNAME que será substituído pelo nome de usuáriodurante a tentativa de autenticação. O parâmetro rgw_ldap_dnattr não é mais usado nestecaso. Por exemplo, para limitar os usuários válidos a um grupo especíco, use o ltro a seguir:

"(&(uid=USERNAME)(memberOf=cn=ceph-users,ou=groups,dc=mycompany,dc=com))"

Nota: Atributo memberOfO uso do atributo memberOf nas pesquisas LDAP requer suporte da sua implementaçãode servidor LDAP especíca.

11.8.5 Gerando um token de acesso para autenticação LDAP

O utilitário radosgw-token gera o token de acesso com base no nome de usuário e na senhaLDAP. Ele emite uma string codicada com base64, que é o token de acesso real. Use seu clienteS3 favorito (consulte a Seção 11.5.1, “Acessando o Object Gateway”), especique o token como achave de acesso e use uma chave secreta vazia.

root@minion > export RGW_ACCESS_KEY_ID="username"root@minion > export RGW_SECRET_ACCESS_KEY="password"root@minion > radosgw-token --encode --ttype=ldap

Importante: Credenciais de texto sem criptografiaO token de acesso é uma estrutura JSON codicada com base64 que contém as credenciaisLDAP como texto sem criptograa.

150 Gerando um token de acesso para autenticação LDAP SES 5

Nota: Active DirectoryPara o Active Directory, use o parâmetro --ttype=ad .

11.9 Fragmentação de índice do compartimento dememória

O Object Gateway armazena os dados de índice do compartimento de memória em um pool deíndice, que assume .rgw.buckets.index como padrão. Se você colocar um número excessivo(centenas de milhares) de objetos em um único compartimento de memória, e a cota para onúmero máximo de objetos por compartimento de memória ( rgw bucket default quotamax objects ) não for denida, o desempenho do pool de índice poderá ser prejudicado. Afragmentação de índice do compartimento de memória impede essa redução no desempenho epermite um alto número de objetos por compartimento de memória.

11.9.1 Refragmentação de índice do compartimento de memória

Se um compartimento de memória car muito grande e sua conguração inicial não for maissuciente, será necessário refragmentar o pool de índice dele. Você pode usar a refragmentaçãode índice do compartimento de memória automática online (consulte a Seção  11.9.1.1,

“Refragmentação dinâmica”) ou refragmentar o índice do compartimento de memória oinemanualmente (consulte a Seção 11.9.1.2, “Refragmentação manual”).

11.9.1.1 Refragmentação dinâmica

A partir do SUSE Enterprise Storage 5, oferecemos suporte à refragmentação do compartimentode memória online. Ela detecta se o número de objetos por compartimento de memória atingedeterminado limite e aumenta automaticamente o número de fragmentos usados pelo índice docompartimento de memória. Esse processo reduz o número de entradas em cada fragmento deíndice do compartimento de memória.

151 Fragmentação de índice do compartimento de memória SES 5

O processo de detecção é executado:

Quando novos objetos são adicionados ao compartimento de memória.

Em um processo em segundo plano que explora periodicamente todos os compartimentosde memória. Isso é necessário para resolver a questão de compartimentos de memóriaexistentes que não são atualizados.

Um compartimento de memória que requer refragmentação é adicionado à la reshard_loge será programado para ser refragmentado posteriormente. Os threads de refragmentação sãoexecutados em segundo plano e executam a refragmentação programada, uma de cada vez.

CONFIGURANDO A REFRAGMENTAÇÃO DINÂMICA

rgw_dynamic_resharding

Habilita ou desabilita a refragmentação dinâmica de índice do compartimento de memória.Os valores possíveis são “true” (verdadeiro) ou “false” (falso). O padrão é “true”.

rgw_reshard_num_logs

Número de fragmentos para o registro da refragmentação. O padrão é 16.

rgw_reshard_bucket_lock_duration

Duração do bloqueio do objeto do compartimento de memória durante a refragmentação.O padrão é 120 segundos.

rgw_max_objs_per_shard

Número máximo de objetos por fragmento de índice do compartimento de memória. Opadrão é 100.000 objetos.

rgw_reshard_thread_interval

Tempo máxithread de refragmentaçãomo entre os ciclos de processamento do . O padrãoé 600 segundos.

Importante: Configurações multissiteA refragmentação dinâmica não é suportada em ambiente multissite. Por padrão, ela estádesabilitada desde o Ceph 12.2.2, mas recomendamos conferir essa conguração.

COMANDOS PARA ADMINISTRAR O PROCESSO DE REFRAGMENTAÇÃO

Adicionar um compartimento de memória à fila de refragmentação:

root@minion > radosgw-admin reshard add \

152 Refragmentação de índice do compartimento de memória SES 5

--bucket BUCKET_NAME \ --num-shards NEW_NUMBER_OF_SHARDS

Listar a fila de refragmentação:

root@minion > radosgw-admin reshard list

Processar/Programar a refragmentação de um compartimento de memória:

root@minion > radosgw-admin reshard process

Exibir o status da refragmentação do compartimento de memória:

root@minion > radosgw-admin reshard status --bucket BUCKET_NAME

Cancelar uma refragmentação pendente do compartimento de memória:

root@minion > radosgw-admin reshard cancel --bucket BUCKET_NAME

11.9.1.2 Refragmentação manual

A refragmentação dinâmica mencionada na Seção 11.9.1.1, “Refragmentação dinâmica” é suportadaapenas nas congurações simples do Object Gateway. Para congurações multissite, use arefragmentação manual descrita nesta seção.

Para refragmentar o índice do compartimento de memória manualmente oine, use o seguintecomando:

root@minion > radosgw-admin bucket reshard

O comando bucket reshard executa o seguinte:

Cria um novo conjunto de objetos de índice do compartimento de memória para o objetoespecicado.

Distribui todas as entradas desses objetos de índice.

Cria uma nova instância do compartimento de memória.

Vincula a nova instância do compartimento de memória ao compartimento de memóriapara que todas as novas operações de índice passem pelos novos índices do compartimentode memória.

Imprime o ID do compartimento de memória antigo e novo para a saída padrão.

153 Refragmentação de índice do compartimento de memória SES 5

PROCEDIMENTO 11.1: REFRAGMENTANDO O POOL DE ÍNDICE DO COMPARTIMENTO DE MEMÓRIA

1. Verique se todas as operações no compartimento de memória foram interrompidas.

2. Faça backup do índice original do compartimento de memória:

root@minion > radosgw-admin bi list \ --bucket=BUCKET_NAME \ > BUCKET_NAME.list.backup

3. Refragmente o índice do compartimento de memória:

root@minion > radosgw-admin reshard \ --bucket=BUCKET_NAME \ --num-shards=NEW_SHARDS_NUMBER

Dica: ID do compartimento de memória antigoComo parte da saída, esse comando também imprime o ID do compartimento dememória novo e antigo. Anote o ID do compartimento de memória antigo. Ele seránecessário para purgar os objetos de índice do compartimento de memória antigo.

4. Verique se os objetos estão listados corretamente comparando a listagem de índice docompartimento de memória antigo com o novo. Em seguida, purgue os objetos de índicedo compartimento de memória antigo:

root@minion > radosgw-admin bi purge --bucket=BUCKET_NAME --bucket-id=OLD_BUCKET_ID

11.9.2 Fragmentação de índice para novos compartimentos dememória

Há duas opções que afetam a fragmentação de índice do compartimento de memória:

Use a opção rgw_override_bucket_index_max_shards para congurações simples.

Use a opção bucket_index_max_shards para congurações multissite.

A denição das opções como 0 desabilita a fragmentação de índice do compartimento dememória. Um valor maior do que 0 habilita a fragmentação de índice do compartimento dememória e dene o número máximo de fragmentos.

154 Fragmentação de índice para novos compartimentos de memória SES 5

A fórmula a seguir ajuda você a calcular o número recomendado de fragmentos:

number_of_objects_expected_in_a_bucket / 100000

Esteja ciente de que o número máximo de fragmentos é 7877.

11.9.2.1 Configurações simples

1. Abra o arquivo de conguração do Ceph e adicione ou modique a seguinte opção:

rgw_override_bucket_index_max_shards = 12

Dica: Uma ou todas as instâncias do Object GatewayPara congurar a fragmentação de índice do compartimento dememória para todas as instâncias do Object Gateway, incluargw_override_bucket_index_max_shards na seção [global] .

Para congurar a fragmentação de índice do compartimento de memóriaapenas para uma instância especíca do Object Gateway, incluargw_override_bucket_index_max_shards na seção relacionada da instância.

2. Reinicie o Object Gateway. Consulte a Seção 11.3, “Operando o serviço Object Gateway” paraobter mais detalhes.

11.9.2.2 Configurações multissite

As congurações multissite podem ter um pool de índice diferente para gerenciar o failover.Para congurar um número consistente de fragmentos para as zonas em um grupo de zonas,dena a opção bucket_index_max_shards na conguração do grupo de zonas:

1. Exporte a conguração do grupo de zonas para o arquivo zonegroup.json :

root@minion > radosgw-admin zonegroup get > zonegroup.json

2. Edite o arquivo zonegroup.json e dena a opção bucket_index_max_shards para cadazona nomeada.

155 Fragmentação de índice para novos compartimentos de memória SES 5

3. Redena o grupo de zonas:

root@minion > radosgw-admin zonegroup set < zonegroup.json

4. Atualize o período:

root@minion > radosgw-admin period update --commit

11.10 Integrando o OpenStack KeystoneO OpenStack Keystone é um serviço de identidade que faz parte do produto OpenStack. Vocêpode integrar o Object Gateway ao Keystone para congurar um gateway que aceita o tokende autenticação do Keystone. Um usuário autorizado pelo Keystone a acessar o gateway serávericado no Ceph Object Gateway e criado automaticamente, se necessário. O Object Gatewayconsulta o Keystone periodicamente para obter uma lista de tokens revogados.

11.10.1 Configurando o OpenStack

Antes de congurar o Ceph Object Gateway, você precisa congurar o OpenStack Keystone parahabilitar o serviço Swift e apontá-lo para o Ceph Object Gateway:

1. Dena o serviço Swift. Para usar o OpenStack para validar usuários do Swift, crie primeiroo serviço Swift:

root # openstack service create \ --name=swift \ --description="Swift Service" \ object-store

2. Dena os endpoints. Após criar o serviço Swift, aponte para o Ceph Object Gateway.Substitua REGION_NAME pelo nome do grupo de zonas ou da região do gateway.

root # openstack endpoint create --region REGION_NAME \ --publicurl "http://radosgw.example.com:8080/swift/v1" \ --adminurl "http://radosgw.example.com:8080/swift/v1" \ --internalurl "http://radosgw.example.com:8080/swift/v1" \ swift

3. Verique as congurações. Após criar o serviço Swift e denir os endpoints, mostre osendpoints para vericar se todas as congurações estão corretas.

156 Integrando o OpenStack Keystone SES 5

root # openstack endpoint show object-store

11.10.2 Configurando o Ceph Object Gateway

11.10.2.1 Configurar certificados SSL

O Ceph Object Gateway consulta o Keystone periodicamente para obter uma lista de tokensrevogados. Essas solicitações são codicadas e assinadas. É possível também congurar oKeystone para fornecer tokens autoassinados, que também são codicados e assinados. Vocêprecisa congurar o gateway para que possa decodicar e vericar essas mensagens assinadas.Portanto, os certicados OpenSSL que o Keystone usa para criar as solicitações precisam serconvertidos no formato “nss db”:

root # mkdir /var/ceph/nssroot # openssl x509 -in /etc/keystone/ssl/certs/ca.pem \ -pubkey | certutil -d /var/ceph/nss -A -n ca -t "TCu,Cu,Tuw"rootopenssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem \ -pubkey | certutil -A -d /var/ceph/nss -n signing_cert -t "P,P,P"

É possível também terminar o OpenStack Keystone com um certicado SSL autoassinado parao Ceph Object Gateway interagir com o Keystone. Instale o certicado SSL do Keystone no nóque executa o Ceph Object Gateway ou, se preferir, dena o valor da opção rgw keystoneverify ssl como “false”. A denição de rgw keystone verify ssl como “false” indica queo gateway não tentará vericar o certicado.

11.10.2.2 Configurar as opções do Object Gateway

Você pode congurar a integração com o Keystone usando as seguintes opções:

rgw keystone api version

Versão da API do Keystone. As opções válidas são 2 ou 3. O padrão é 2.

rgw keystone url

O URL e o número da porta da API RESTful administrativa no servidor Keystone. Segue opadrão URL_SERVIDOR:NÚMERO_DA_PORTA .

157 Configurando o Ceph Object Gateway SES 5

rgw keystone admin token

O token ou segredo compartilhado congurado internamente no Keystone para solicitaçõesadministrativas.

rgw keystone accepted roles

As funções necessárias para atender às solicitações. O padrão é “Member, admin”.

rgw keystone accepted admin roles

A lista de funções que permite a um usuário obter privilégios administrativos.

rgw keystone token cache size

O número máximo de entradas no cache de token do Keystone.

rgw keystone revocation interval

O número de segundos antes de vericar se há tokens revogados. O padrão é 15 * 60.

rgw keystone implicit tenants

Criar novos usuários em seus próprios locatários de mesmo nome. O padrão é “false”.

rgw s3 auth use keystone

Se denido como “true”, o Ceph Object Gateway autenticará os usuários com o Keystone.O padrão é “false”.

nss db path

O caminho para o banco de dados NSS.

Também é possível congurar o locatário de serviço do Keystone, usuário e senha doKeystone (para a versão 2.0 da API do OpenStack Identity), similar ao modo como osserviços do OpenStack costumam ser congurados. Dessa forma, você pode evitar a deniçãodo segredo compartilhado rgw keystone admin token no arquivo de conguração,que deve ser desabilitado em ambientes de produção. As credenciais do locatário deserviço devem ter privilégios de admin. Para obter mais detalhes, consulte a documentação

oficial do OpenStack Keystone (https://docs.openstack.org/keystone/latest/#setting-up-projects-

users-and-roles) . Veja a seguir as opções de conguração relacionadas:

rgw keystone admin user

Nome do usuário administrador do Keystone.

rgw keystone admin password

Senha do usuário administrador do Keystone.

158 Configurando o Ceph Object Gateway SES 5

rgw keystone admin tenant

Locatário do usuário administrador do Keystone versão 2.0.

Um usuário do Ceph Object Gateway é mapeado para um locatário do Keystone. Um usuário doKeystone tem funções diferentes atribuídas, possivelmente em mais do que um único locatário.Quando o Ceph Object Gateway recebe o ticket, ele examina o locatário e as funções do usuárioatribuídas a esse ticket e aceita ou rejeita a solicitação de acordo com a conguração da opçãorgw keystone accepted roles .

Dica: Mapeando locatários do OpenStackEmbora os locatários do Swift sejam mapeados para o usuário do Object Gateway porpadrão, eles também podem ser mapeados para os locatários do OpenStack por meioda opção rgw keystone implicit tenants . Isso fará com que os containers usem onamespace do locatário em vez do namespace global do tipo do S3 que o Object Gatewayusa como padrão. É recomendável decidir sobre o método de mapeamento na fase deplanejamento para evitar confusão. O motivo é que alternar a opção posteriormenteafeta apenas as solicitações mais recentes que são mapeadas em um locatário, enquantoos compartimentos de memória mais antigos criados antes ainda continuam em umnamespace global.

Para obter a versão 3 da API do OpenStack Identity, você deve substituir a opção rgw keystoneadmin tenant por:

rgw keystone admin domain

Domínio do usuário administrador do Keystone.

rgw keystone admin project

Projeto do usuário administrador do Keystone.

11.11 Object Gateways multissite

Zona

Um agrupamento lógico de uma ou mais instâncias do Object Gateway. Deve haver umazona designada como master em um grupo de zonas, que processa toda a criação decompartimento de memória e usuário.

159 Object Gateways multissite SES 5

Grupo de zonas

Um grupo de zonas consiste em várias zonas. Deve haver um grupo de zonas master queprocessará as mudanças na conguração do sistema.

Mapa de grupo de zonas

Uma estrutura de conguração que contém o mapa de todo o sistema. Por exemplo,que grupo de zonas é master, os relacionamentos entre diferentes grupos de zonas edeterminadas opções de conguração, como políticas de armazenamento.

Domínio

Um container para grupos de zonas. Ele permite a separação de grupos de zonasentre clusters. É possível criar vários domínios, facilitando a execução de conguraçõescompletamente diferentes no mesmo cluster.

Período

Um período contém a estrutura de conguração para o estado atual do domínio. Cadaperíodo contém um ID e uma época exclusivos. Cada domínio tem um período atualassociado, que contém o estado atual da conguração dos grupos de zonas e das políticasde armazenamento. Qualquer mudança na conguração para uma zona não masterincrementará a época do período. Modicar a zona master para uma zona diferenteacionará as seguintes mudanças:

Um novo período será gerado com um novo ID e época do período de 1.

O período atual do domínio será atualizado para apontar para o ID do período recém-gerado.

A época do domínio será incrementada.

Você pode congurar cada Object Gateway para participar de uma arquitetura unicada,trabalhando em uma conguração de zona ativa e permitindo gravações em zonas não master.

11.11.1 Terminologia

Veja a seguir uma descrição dos termos especícos de uma arquitetura unicada:

160 Terminologia SES 5

11.11.2 Configuração de cluster de exemplo

Neste exemplo, o foco será na criação de um único grupo de zonas com três zonas separadas,que sincronizam seus dados ativamente. Duas zonas pertencem ao mesmo cluster, enquanto aterceira pertence a outro. Não há um agente de sincronização envolvido no espelhamento dasmudanças de dados entre os Object Gateways. Isso possibilita um esquema de conguraçãomuito mais simples e congurações ativas-ativas. Observe que as operações de metadados, comoa criação de um novo usuário, ainda precisam passar pela zona master. No entanto, as operaçõesde dados, como criação de objetos e compartimentos de memória, podem ser gerenciadas porqualquer uma das zonas.

11.11.3 Chaves do sistema

Ao congurar as zonas, o Object Gateway espera a criação de um usuário do sistema compatívelcom S3 juntamente com as chaves secretas e de acesso. Isso permite que outra instância doObject Gateway extraia a conguração remotamente com as chaves secretas e de acesso. Paraobter mais informações sobre como criar usuários do S3, consulte a Seção 11.5.2.1, “Adicionando

usuários do S3 e do Swift”.

DicaIsso é útil para gerar as chaves secretas e de acesso antes da criação da própria zona, poisfacilita a criação de scripts e o uso das ferramentas de gerenciamento de conguraçãono futuro.

Para efeitos deste exemplo, vamos supor que as chaves secretas e de acesso foram denidas nasvariáveis de ambiente:

# SYSTEM_ACCESS_KEY=1555b35654ad1656d805# SYSTEM_SECRET_KEY=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==

Normalmente, as chaves de acesso são compostas por 20 caracteres alfanuméricos, enquantoas chaves secretas são constituídas de 40 caracteres alfanuméricos (também podem conter oscaracteres +/=). É possível gerar essas chaves na linha de comando:

# SYSTEM_ACCESS_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1)# SYSTEM_SECRET_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1)

161 Configuração de cluster de exemplo SES 5

11.11.4 Convenções de nomeação

Este exemplo descreve o processo de conguração de uma zona master. Vamos considerar umgrupo de zonas denominado us abrangendo os Estados Unidos, que será nosso grupo de zonasmaster. Ele incluirá duas zonas gravadas no formato grupodezonas - zona . Trata-se apenas danossa convenção, e você pode escolher o formato de sua preferência. Em resumo:

Grupo de zonas master: Estados Unidos us

Zona master: Estados Unidos, Região Leste 1: us-east-1

Zona secundária: Estados Unidos, Região Leste 2: us-east-2

Zona secundária: Estados Unidos, Região Oeste: us-west

Isso fará parte de um domínio maior denominado gold . As zonas us-east-1 e us-east-2fazem parte do mesmo cluster do Ceph, sendo us-east-1 a primária. us-west está em umcluster diferente do Ceph.

11.11.5 Pools padrão

Quando congurado com as permissões apropriadas, o próprio Object Gateway cria poolspadrão. Os valores pg_num e pgp_num são obtidos do arquivo de conguração ceph.conf . Porpadrão, os pools relacionados a uma zona seguem a convenção nome-zona . nome-pool . Porexemplo, para a zona us-east-1 , serão os seguintes pools:

.rgw.rootus-east-1.rgw.controlus-east-1.rgw.data.rootus-east-1.rgw.gcus-east-1.rgw.logus-east-1.rgw.intent-logus-east-1.rgw.usageus-east-1.rgw.users.keysus-east-1.rgw.users.emailus-east-1.rgw.users.swiftus-east-1.rgw.users.uidus-east-1.rgw.buckets.indexus-east-1.rgw.buckets.dataus-east-1.rgw.meta

Esses pools também podem ser criados em outras zonas substituindo us-east-1 pelo nome dazona apropriado.

162 Convenções de nomeação SES 5

11.11.6 Criando um domínio

Congure um domínio chamado gold e torne-o o domínio padrão:

cephadm > radosgw-admin realm create --rgw-realm=gold --default{ "id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "name": "gold", "current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1}

Observe que cada domínio tem um ID, que permite exibilidade, como renomear um domíniono futuro, se necessário. current_period muda sempre que alguma coisa é modicada na zonamaster. epoch é incrementado quando há alguma mudança na conguração da zona masterque resulta na mudança do período atual.

11.11.7 Apagando o grupo de zonas padrão

A instalação padrão do Object Gateway cria o grupo de zonas padrão chamado default . Comonão precisamos mais do grupo de zonas padrão, remova-o.

cephadm > radosgw-admin zonegroup delete --rgw-zonegroup=default

11.11.8 Criando um grupo de zonas master

Crie um grupo de zonas master chamado us . O grupo de zonas gerenciará o mapa de grupo dezonas e propagará as mudanças para o restante do sistema. Ao marcar o grupo de zonas comopadrão, você permite mencionar explicitamente o switch rgw-zonegroup para comandos futuros.

cephadm > radosgw-admin zonegroup create --rgw-zonegroup=us \--endpoints=http://rgw1:80 --master --default{ "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ],

163 Criando um domínio SES 5

"hostnames": [], "hostnames_s3website": [], "master_zone": "", "zones": [], "placement_targets": [], "default_placement": "", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"}

Se preferir, você poderá marcar um grupo de zonas como padrão com o seguinte comando:

cephadm > radosgw-admin zonegroup default --rgw-zonegroup=us

11.11.9 Criando uma zona master

Agora, crie uma zona padrão e adicione-a ao grupo de zonas padrão. Observe que você usaráessa zona para operações de metadados, como criação de usuário:

cephadm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 \--endpoints=http://rgw1:80 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY{ "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "domain_root": "us-east-1/gc.rgw.data.root", "control_pool": "us-east-1/gc.rgw.control", "gc_pool": "us-east-1/gc.rgw.gc", "log_pool": "us-east-1/gc.rgw.log", "intent_log_pool": "us-east-1/gc.rgw.intent-log", "usage_log_pool": "us-east-1/gc.rgw.usage", "user_keys_pool": "us-east-1/gc.rgw.users.keys", "user_email_pool": "us-east-1/gc.rgw.users.email", "user_swift_pool": "us-east-1/gc.rgw.users.swift", "user_uid_pool": "us-east-1/gc.rgw.users.uid", "system_key": { "access_key": "1555b35654ad1656d804", "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "us-east-1/gc.rgw.buckets.index", "data_pool": "us-east-1/gc.rgw.buckets.data", "data_extra_pool": "us-east-1/gc.rgw.buckets.non-ec", "index_type": 0

164 Criando uma zona master SES 5

} } ], "metadata_heap": "us-east-1/gc.rgw.meta", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"}

Observe que os switches --rgw-zonegroup e --default adicionam a zona a um grupo dezonas e a tornam padrão. Se preferir, o mesmo também pode ser feito com os seguintescomandos:

cephadm > radosgw-admin zone default --rgw-zone=us-east-1cephadm > radosgw-admin zonegroup add --rgw-zonegroup=us --rgw-zone=us-east-1

11.11.9.1 Criando usuários do sistema

Para acessar os pools da zona, você precisa criar um usuário do sistema. Observe que vocêtambém precisará dessas chaves durante a conguração da zona secundária.

cephadm > radosgw-admin user create --uid=zone.user \--display-name="Zone User" --access-key=$SYSTEM_ACCESS_KEY \--secret=$SYSTEM_SECRET_KEY --system

11.11.9.2 Atualizar o período

Como você mudou a conguração da zona master, precisa conrmar as modicações para queelas entrem em vigor na estrutura de conguração do domínio. Inicialmente, o período tem estaaparência:

cephadm > radosgw-admin period get{ "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1, "predecessor_uuid": "", "sync_status": [], "period_map": { "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "zonegroups": [], "short_zone_ids": [] }, "master_zonegroup": "", "master_zone": "", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1

165 Criando uma zona master SES 5

} }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 1}

Atualize o período e conrme as mudanças:

cephadm > radosgw-admin period update --commit{ "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 1, "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707", "sync_status": [ "[...]" ], "period_map": { "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "zonegroups": [ { "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "zones": [ { "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "endpoints": [ "http:\/\/rgw1:80" ], "log_meta": "true", "log_data": "false", "bucket_index_max_shards": 0, "read_only": "false" } ], "placement_targets": [ { "name": "default-placement", "tags": [] } ], "default_placement": "default-placement",

166 Criando uma zona master SES 5

"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7" } ], "short_zone_ids": [ { "key": "83859a9a-9901-4f00-aa6d-285c777e10f0", "val": 630926044 } ] }, "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e", "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 2}

11.11.9.3 Iniciar o Object Gateway

É necessário mencionar as opções de zona e porta do Object Gateway no arquivo de conguraçãoantes de iniciá-lo. Para obter mais informações sobre o Object Gateway e sua conguração,consulte o Capítulo 11, Ceph Object Gateway. A seção de conguração do Object Gateway deveser semelhante a esta:

[client.rgw.us-east-1]rgw_frontends="civetweb port=80"rgw_zone=us-east-1

Inicie o Object Gateway:

sudo systemctl start ceph-radosgw@rgw.us-east-1

167 Criando uma zona master SES 5

11.11.10 Criando uma zona secundária

No mesmo cluster, crie e congure a zona secundária chamada us-east-2 . Você pode executartodos os comandos a seguir no nó que hospeda a própria zona master.

Para criar a zona secundária, execute o mesmo comando de quando você criou a zona primária,mas descartando o ag de master:

cephadm > radosgw-admin zone create --rgw-zonegroup=us --endpoints=http://rgw2:80 \--rgw-zone=us-east-2 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY{ "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-east-2", "domain_root": "us-east-2.rgw.data.root", "control_pool": "us-east-2.rgw.control", "gc_pool": "us-east-2.rgw.gc", "log_pool": "us-east-2.rgw.log", "intent_log_pool": "us-east-2.rgw.intent-log", "usage_log_pool": "us-east-2.rgw.usage", "user_keys_pool": "us-east-2.rgw.users.keys", "user_email_pool": "us-east-2.rgw.users.email", "user_swift_pool": "us-east-2.rgw.users.swift", "user_uid_pool": "us-east-2.rgw.users.uid", "system_key": { "access_key": "1555b35654ad1656d804", "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "us-east-2.rgw.buckets.index", "data_pool": "us-east-2.rgw.buckets.data", "data_extra_pool": "us-east-2.rgw.buckets.non-ec", "index_type": 0 } } ], "metadata_heap": "us-east-2.rgw.meta", "realm_id": "815d74c2-80d6-4e63-8cfc-232037f7ff5c"}

168 Criando uma zona secundária SES 5

11.11.10.1 Atualizar o período

Informe todos os gateways sobre a nova mudança no mapa do sistema fazendo uma atualizaçãodo período e conrmando as modicações:

cephadm > radosgw-admin period update --commit{ "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 2, "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707", "sync_status": [ "[...]" ], "period_map": { "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "zonegroups": [ { "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "zones": [ { "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "endpoints": [ "http:\/\/rgw1:80" ], "log_meta": "true", "log_data": "false", "bucket_index_max_shards": 0, "read_only": "false" }, { "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-east-2", "endpoints": [ "http:\/\/rgw2:80" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 0,

169 Criando uma zona secundária SES 5

"read_only": "false" }

], "placement_targets": [ { "name": "default-placement", "tags": [] } ], "default_placement": "default-placement", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7" } ], "short_zone_ids": [ { "key": "83859a9a-9901-4f00-aa6d-285c777e10f0", "val": 630926044 }, { "key": "950c1a43-6836-41a2-a161-64777e07e8b8", "val": 4276257543 }

] }, "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e", "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 2}

170 Criando uma zona secundária SES 5

11.11.10.2 Iniciar o Object Gateway

Ajuste a conguração do Object Gateway para a zona secundária e inicie-o:

[client.rgw.us-east-2]rgw_frontends="civetweb port=80"rgw_zone=us-east-2

cephadm > sudo systemctl start ceph-radosgw@rgw.us-east-2

11.11.11 Adicionando o Object Gateway ao segundo cluster

O segundo cluster do Ceph pertence ao mesmo grupo de zonas que o inicial, mas pode estargeogracamente em qualquer outro lugar.

11.11.11.1 Domínio padrão e grupo de zonas

Como você já criou o domínio para o primeiro gateway, insira-o aqui e torne-o padrão:

cephadm > radosgw-admin realm pull --url=http://rgw1:80 \--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY{ "id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "name": "gold", "current_period": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 2}cephadm > radosgw-admin realm default --rgw-realm=gold

Obtenha a conguração da zona master extraindo o período:

cephadm > radosgw-admin period pull --url=http://rgw1:80 \--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY

Dena o grupo de zonas padrão como o grupo us já criado:

cephadm > radosgw-admin zonegroup default --rgw-zonegroup=us

11.11.11.2 Configuração da zona secundária

Crie uma nova zona chamada us-west com as mesmas chaves do sistema:

cephadm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-west \

171 Adicionando o Object Gateway ao segundo cluster SES 5

--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY \--endpoints=http://rgw3:80 --default{ "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-west", "domain_root": "us-west.rgw.data.root", "control_pool": "us-west.rgw.control", "gc_pool": "us-west.rgw.gc", "log_pool": "us-west.rgw.log", "intent_log_pool": "us-west.rgw.intent-log", "usage_log_pool": "us-west.rgw.usage", "user_keys_pool": "us-west.rgw.users.keys", "user_email_pool": "us-west.rgw.users.email", "user_swift_pool": "us-west.rgw.users.swift", "user_uid_pool": "us-west.rgw.users.uid", "system_key": { "access_key": "1555b35654ad1656d804", "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "us-west.rgw.buckets.index", "data_pool": "us-west.rgw.buckets.data", "data_extra_pool": "us-west.rgw.buckets.non-ec", "index_type": 0 } } ], "metadata_heap": "us-west.rgw.meta", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"}

11.11.11.3 Atualizar o período

Para propagar as mudanças do mapa de grupo de zonas, atualizamos e conrmamos o período:

cephadm > radosgw-admin period update --commit --rgw-zone=us-west{ "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 3, "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707", "sync_status": [ "", # truncated ],

172 Adicionando o Object Gateway ao segundo cluster SES 5

"period_map": { "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "zonegroups": [ { "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "zones": [ { "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "endpoints": [ "http:\/\/rgw1:80" ], "log_meta": "true", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false" }, { "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-east-2", "endpoints": [ "http:\/\/rgw2:80" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false" }, { "id": "d9522067-cb7b-4129-8751-591e45815b16", "name": "us-west", "endpoints": [ "http:\/\/rgw3:80" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false"

173 Adicionando o Object Gateway ao segundo cluster SES 5

} ], "placement_targets": [ { "name": "default-placement", "tags": [] } ], "default_placement": "default-placement", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7" } ], "short_zone_ids": [ { "key": "83859a9a-9901-4f00-aa6d-285c777e10f0", "val": 630926044 }, { "key": "950c1a43-6836-41a2-a161-64777e07e8b8", "val": 4276257543 }, { "key": "d9522067-cb7b-4129-8751-591e45815b16", "val": 329470157 } ] }, "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e", "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 2}

174 Adicionando o Object Gateway ao segundo cluster SES 5

Observe que o número da época do período foi incrementado, o que indica uma mudança naconguração.

11.11.11.4 Iniciar o Object Gateway

O procedimento é quase igual a iniciar o Object Gateway na primeira zona. A única diferença éque a conguração da zona do Object Gateway deve reetir o nome da zona us-west :

[client.rgw.us-west]rgw_frontends="civetweb port=80"rgw_zone=us-west

Inicie o segundo Object Gateway:

sudo systemctl start ceph-radosgw@rgw.us-west

11.11.12 Failover e recuperação de desastre

Se a zona master falhar, faça o failover para a zona secundária para recuperação de desastre.

1. Converta a zona secundária na zona master e padrão. Por exemplo:

root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default

Por padrão, o Ceph Object Gateway será executado em uma conguração ativa-ativa. Seo cluster foi congurado para ser executado em uma conguração ativa-passiva, a zonasecundária é uma zona apenas leitura. Remova o status --read-only para permitir que azona receba as operações de gravação. Por exemplo:

root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default \--read-only=False

2. Atualize o período para que as mudanças entrem em vigor.

root # radosgw-admin period update --commit

3. Por m, reinicie o Ceph Object Gateway.

root # systemctl restart ceph-radosgw@rgw.`hostname -s`

Se a zona master anterior for recuperada, reverta a operação.

175 Failover e recuperação de desastre SES 5

1. Da zona recuperada, extraia o período da zona master atual.

root # radosgw-admin period pull --url={url-to-master-zone-gateway} \--access-key={access-key} --secret={secret}

2. Converta a zona recuperada na zona master e padrão.

root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default

3. Atualize o período para que as mudanças entrem em vigor.

root # radosgw-admin period update --commit

4. Em seguida, reinicie o Ceph Object Gateway na zona recuperada.

root # systemctl restart ceph-radosgw@rgw.`hostname -s`

5. Se a zona secundária precisar de uma conguração apenas leitura, atualize-a.

root # radosgw-admin zone modify --rgw-zone={zone-name} --read-only

6. Atualize o período para que as mudanças entrem em vigor.

root # radosgw-admin period update --commit

7. Por m, reinicie o Ceph Object Gateway na zona secundária.

root # systemctl restart ceph-radosgw@rgw.`hostname -s`

11.12 Equilibrando a carga dos servidores ObjectGateway com HAProxyVocê pode usar o balanceador de carga HAProxy para distribuir todas as solicitaçõesentre os vários servidores Object Gateway de back end. Consulte https://www.suse.com/

documentation/sle-ha-12/book_sleha/data/sec_ha_lb_haproxy.html para obter mais detalhessobre como congurar o HAProxy.

Veja a seguir uma conguração simples do HAProxy para equilibrar os nós do Object Gatewayusando o rodízio como algoritmo de equilíbrio:

root # cat /etc/haproxy/haproxy.cfg

176 Equilibrando a carga dos servidores Object Gateway com HAProxy SES 5

[...]frontend https_frontendbind *:443 crt path-to-cert.pem [ciphers: ... ]default_backend rgw

backend rgwmode httpbalance roundrobinserver rgw_server1 rgw-endpoint1 weight 1 maxconn 100 checkserver rgw_server2 rgw-endpoint2 weight 1 maxconn 100 check[...]

177 Equilibrando a carga dos servidores Object Gateway com HAProxy SES 5

12 Ceph iSCSI Gateway

O capítulo aborda especicamente as tarefas de administração relacionadas ao iSCSI Gateway.Para ver o procedimento de implantação, consulte o Livro “Guia de Implantação”, Capítulo 10

“Instalação do iSCSI Gateway”.

12.1 Conectando-se aos destinos gerenciados porlrbd

Este capítulo descreve como se conectar aos destinos gerenciados por lrdb de clientes com Linux,Microsoft Windows ou VMware.

12.1.1 Linux (open-iscsi)

A conexão com destinos iSCSI baseados em lrbd por meio do open-iscsi é um processo deduas etapas. Primeiramente, o iniciador deve descobrir os destinos iSCSI disponíveis no hostdo gateway, depois ele deve efetuar login e mapear as LUs (Logical Units – Unidades Lógicas)disponíveis.

As duas etapas exigem que o daemon open-iscsi esteja em execução. A maneira como vocêinicia o daemon open-iscsi depende da sua distribuição Linux:

No SUSE Linux Enterprise Server (SLES) e nos hosts Red Hat Enterprise Linux (RHEL),execute systemctl start iscsid (ou service iscsid start se o systemctl nãoestiver disponível).

Nos hosts do Debian e do Ubuntu, execute systemctl start open-iscsi (ou serviceopen-iscsi start ).

Se o host do seu iniciador executa o SUSE LinuxEnterprise Server, consulte https://www.suse.com/documentation/sles-12/stor_admin/data/

sec_iscsi_initiator.html ou https://www.suse.com/documentation/sles11/stor_admin/data/

sec_inst_system_iscsi_initiator.html para obter detalhes sobre como se conectar a um destinoiSCSI.

178 Conectando-se aos destinos gerenciados por lrbd SES 5

Para qualquer outra distribuição Linux com suporte a open-iscsi , prossiga para a descobertade destinos no gateway lrbd . Este exemplo usa iscsi1.example.com como endereço do portal.Para acesso de múltiplos caminhos, repita estas etapas com iscsi2.example.com:

iscsiadm -m discovery -t sendtargets -p iscsi1.example.com192.168.124.104:3260,1 iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol

Em seguida, efetue login no portal. Se o login for concluído com êxito, quaisquer unidades lógicasbaseadas em RBD no portal carão imediatamente disponíveis no barramento SCSI do sistema:

iscsiadm -m node -p iscsi1.example.com --loginLogging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260] (multiple)Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260] successful.

Repita esse processo para outros endereços IP ou hosts do portal.

Se o utilitário lsscsi estiver instalado no seu sistema, use-o para enumerar os dispositivosSCSI disponíveis no sistema:

lsscsi[8:0:0:0] disk SUSE RBD 4.0 /dev/sde[9:0:0:0] disk SUSE RBD 4.0 /dev/sdf

Em uma conguração de múltiplos caminhos (em que dois dispositivos iSCSI conectadosrepresentam a mesma LU), você também pode examinar o estado do dispositivo de múltiploscaminhos com o utilitário multipath :

multipath -ll360014050cf9dcfcb2603933ac3298dca dm-9 SUSE,RBDsize=49G features='0' hwhandler='0' wp=rw|-+- policy='service-time 0' prio=1 status=active| `- 8:0:0:0 sde 8:64 active ready running`-+- policy='service-time 0' prio=1 status=enabled`- 9:0:0:0 sdf 8:80 active ready running

Agora, você pode usar esse dispositivo de múltiplos caminhos como qualquer dispositivo deblocos. Por exemplo, você pode usá-lo como um Volume Físico para LVM (Logical VolumeManagement – Gerenciamento de Volumes Lógicos) Linux ou pode simplesmente criar umsistema de arquivos nele. O exemplo a seguir demonstra como criar um sistema de arquivos XFSno volume iSCSI de múltiplos caminhos recém-conectado:

mkfs -t xfs /dev/mapper/360014050cf9dcfcb2603933ac3298dca

179 Linux (open-iscsi) SES 5

log stripe unit (4194304 bytes) is too large (maximum is 256KiB)log stripe unit adjusted to 32KiBmeta-data=/dev/mapper/360014050cf9dcfcb2603933ac3298dca isize=256 agcount=17, agsize=799744 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0data = bsize=4096 blocks=12800000, imaxpct=25 = sunit=1024 swidth=1024 blksnaming =version 2 bsize=4096 ascii-ci=0 ftype=0log =internal log bsize=4096 blocks=6256, version=2 = sectsz=512 sunit=8 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0

Como o XFS é um sistema de arquivos sem cluster, você apenas pode montá-lo em um único nódo iniciador iSCSI em determinado momento.

Para descontinuar a qualquer momento o uso das LUs iSCSI associadas a determinado destino,execute o seguinte comando:

iscsiadm -m node -p iscsi1.example.com --logoutLogging out of session [sid: 18, iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260]Logout of [sid: 18, target: iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260] successful.

Como ocorre com a descoberta e o login, você deve repetir as etapas de logout para todos osnomes de host ou endereços IP do portal.

12.1.1.1 Configuração de múltiplos caminhos

A conguração de múltiplos caminhos é mantida nos clientes ou iniciadores e não depende denenhuma conguração de lrbd . Selecione uma estratégia antes de usar o armazenamento emblocos. Após editar o /etc/multipath.conf , reinicie o multipathd com

sudo systemctl restart multipathd

Para uma conguração ativa-passiva com nomes amigáveis, adicione

defaults { user_friendly_names yes}

ao /etc/multipath.conf . Após a conexão bem-sucedida com os destinos, execute

180 Linux (open-iscsi) SES 5

multipath -llmpathd (36001405dbb561b2b5e439f0aed2f8e1e) dm-0 SUSE,RBDsize=2.0G features='0' hwhandler='0' wp=rw|-+- policy='service-time 0' prio=1 status=active| `- 2:0:0:3 sdl 8:176 active ready running|-+- policy='service-time 0' prio=1 status=enabled| `- 3:0:0:3 sdj 8:144 active ready running`-+- policy='service-time 0' prio=1 status=enabled `- 4:0:0:3 sdk 8:160 active ready running

Observe o status de cada link. Para uma conguração ativa-ativa, adicione

defaults { user_friendly_names yes}

devices { device { vendor "(LIO-ORG|SUSE)" product "RBD" path_grouping_policy "multibus" path_checker "tur" features "0" hardware_handler "1 alua" prio "alua" failback "immediate" rr_weight "uniform" no_path_retry 12 rr_min_io 100 }}

ao /etc/multipath.conf . Reinicie o multipathd e execute

multipath -llmpathd (36001405dbb561b2b5e439f0aed2f8e1e) dm-3 SUSE,RBDsize=2.0G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw`-+- policy='service-time 0' prio=50 status=active |- 4:0:0:3 sdj 8:144 active ready running |- 3:0:0:3 sdk 8:160 active ready running `- 2:0:0:3 sdl 8:176 active ready running

181 Linux (open-iscsi) SES 5

12.1.2 Microsoft Windows (Iniciador Microsoft iSCSI)

Para se conectar a um destino iSCSI do SUSE Enterprise Storage de um servidor Windows 2012,siga estas etapas:

1. Abra o Gerenciador do Servidor Windows. No Painel de Controle, selecione Tools(Ferramentas) iSCSI Initiator (Iniciador iSCSI). A caixa de diálogo iSCSI Initiator Properties(Propriedades do Iniciador iSCSI) é exibida. Selecione a guia Discovery (Descoberta):

FIGURA 12.1: PROPRIEDADES DO INICIADOR ISCSI

182 Microsoft Windows (Iniciador Microsoft iSCSI) SES 5

2. Na caixa de diálogo Discover Target Portal (Descobrir Portal de Destino), insira o nome dehost ou endereço IP do destino no campo Target (Destino) e clique em OK:

FIGURA 12.2: DESCOBRIR PORTAL DE DESTINO

183 Microsoft Windows (Iniciador Microsoft iSCSI) SES 5

3. Repita esse processo para todos os outros nomes de host ou endereços IP do gateway. Aoconcluir, revise a lista Target Portals (Portais de Destino):

FIGURA 12.3: PORTAIS DE DESTINO

4. Em seguida, alterne para a guia Targets (Destinos) e revise o(s) destino(s) descoberto(s).

184 Microsoft Windows (Iniciador Microsoft iSCSI) SES 5

FIGURA 12.4: DESTINOS

5. Clique em Connect (Conectar) na guia Targets (Destinos). A caixa de diálogo ConnectTo Target (Conectar ao Destino) é exibida. Marque a caixa de seleção Enable Multi-path(Habilitar múltiplos caminhos) para habilitar a E/S de múltiplos caminhos (MPIO) e cliqueem OK:

185 Microsoft Windows (Iniciador Microsoft iSCSI) SES 5

6. Quando a caixa de diálogo Connect to Target (Conectar ao Destino) for fechada, selecioneProperties (Propriedades) para revisar as propriedades do destino:

FIGURA 12.5: PROPRIEDADES DO DESTINO ISCSI

186 Microsoft Windows (Iniciador Microsoft iSCSI) SES 5

7. Selecione Devices (Dispositivos) e clique em MPIO para revisar a conguração de E/S demúltiplos caminhos:

FIGURA 12.6: DETALHES DO DISPOSITIVO

A Load Balance policy (Política de Equilíbrio de Carga) padrão é Round Robin With Subset(Rodízio com Subconjunto). Se você preferir uma conguração exclusivamente de failover,mude-a para Fail Over Only (Somente Failover).

Isso conclui a conguração do iniciador iSCSI. Agora, os volumes iSCSI estão disponíveis comoqualquer outro dispositivo SCSI e podem ser inicializados para uso como volumes e unidades.Clique em OK para fechar a caixa de diálogo iSCSI Initiator Properties (Propriedades do IniciadoriSCSI) e prossiga com a função File and Storage Services (Serviços de Arquivo e Armazenamento)do painel de controle do Server Manager (Gerenciador do Servidor).

Observe o volume recém-conectado. Ele é identicado como SUSE RBD SCSI Multi-PathDrive (Unidade de Múltiplos Caminhos SCSI Baseada em RBD SUSE) no barramento iSCSIe é inicialmente marcado com o status Oine e o tipo de tabela de partição Unknown

187 Microsoft Windows (Iniciador Microsoft iSCSI) SES 5

(Desconhecido). Se o novo volume não aparecer imediatamente, selecione Rescan Storage(Explorar Armazenamento Novamente) na caixa suspensa Tasks (Tarefas) para explorar obarramento iSCSI novamente.

1. Clique o botão direito do mouse no volume iSCSI e selecione New Volume (Novo Volume)no menu de contexto. O New Volume Wizard (Assistente de Novo Volume) é exibido. Cliqueem Next (Avançar), realce o volume iSCSI recém-conectado e clique em Next para começar.

FIGURA 12.7: ASSISTENTE DE NOVO VOLUME

2. Inicialmente, o dispositivo está vazio e não contém uma tabela de partição. Quandosolicitado, conrme a caixa de diálogo indicando que o volume será inicializado com umatabela de partição GPT:

FIGURA 12.8: PROMPT DE DISCO OFFLINE

188 Microsoft Windows (Iniciador Microsoft iSCSI) SES 5

3. Selecione o tamanho do volume. Normalmente, você usa a capacidade total do dispositivo.Em seguida, atribua uma letra de unidade ou nome de diretório no qual o volume recém-criado estará disponível. Na sequência, selecione um sistema de arquivos para criar nonovo volume e, por m, clique em Create (Criar) para conrmar suas seleções e concluira criação do volume:

FIGURA 12.9: CONFIRMAR SELEÇÕES DO VOLUME

Quando o processo for concluído, revise os resultados e clique em Close (Fechar) paraconcluir a inicialização da unidade. Quando a inicialização for concluída, o volume (e orespectivo sistema de arquivos NTFS) cará disponível como uma unidade local recém-inicializada.

12.1.3 VMware

1. Para se conectar aos volumes iSCSI gerenciados por lrbd , você precisa de um adaptadorde software iSCSI congurado. Se não houver um adaptador desse tipo disponível naconguração do vSphere, crie um selecionando Conguration (Conguração) StorageAdapters (Adaptadores de Armazenamento) Add (Adicionar) iSCSI Software initiator(Iniciador de Software iSCSI).

189 VMware SES 5

2. Quando disponível, selecione as propriedades do adaptador clicando o botão direito domouse nele e selecionando Properties (Propriedades) no menu de contexto:

FIGURA 12.10: PROPRIEDADES DO INICIADOR ISCSI

3. Na caixa de diálogo iSCSI Software Initiator (Iniciador de Software iSCSI), clique nobotão Congure (Congurar). Em seguida, vá para a guia Dynamic Discovery (DescobertaDinâmica) e selecione Add (Adicionar).

4. Digite o endereço IP ou nome de host do seu gateway iSCSI lrbd . Se você executa váriosgateways iSCSI em uma conguração de failover, repita essa etapa para todos os gatewaysque você opera.

190 VMware SES 5

FIGURA 12.11: ADICIONAR SERVIDOR DE DESTINO

Após inserir todos os gateways iSCSI, clique em OK na caixa de diálogo para iniciar umanova exploração do adaptador iSCSI.

191 VMware SES 5

5. Quando a nova exploração for concluída, o novo dispositivo iSCSI aparecerá abaixo dalista Storage Adapters (Adaptadores de Armazenamento) no painel Details (Detalhes). Paradispositivos de múltiplos caminhos, agora você pode clicar o botão direito do mouse noadaptador e selecionar Manage Paths (Gerenciar Caminhos) no menu de contexto:

FIGURA 12.12: GERENCIAR DISPOSITIVOS DE MÚLTIPLOS CAMINHOS

Você agora deve ver todos os caminhos com um ícone verde em Status. Um dos seuscaminhos deve estar marcado como Active (I/O) (Ativo (E/S)), e todos os outros apenascomo Active (Ativo):

FIGURA 12.13: LISTAGEM DE CAMINHOS PARA MÚLTIPLOS CAMINHOS

6. Agora, você pode alternar de Storage Adapters (Adaptadores de Armazenamento) parao item denominado Storage (Armazenamento). Selecione Add Storage... (AdicionarArmazenamento) no canto superior direito do painel para exibir a caixa de diálogo

192 VMware SES 5

Add Storage (Adicionar Armazenamento). Em seguida, selecione Disk/LUN (Disco/LUN)e clique em Next (Avançar). O dispositivo iSCSI recém-adicionado aparece na lista SelectDisk/LUN (Selecionar Disco/LUN). Selecione-o e, em seguida, clique em Next (Avançar)para continuar:

FIGURA 12.14: CAIXA DE DIÁLOGO ADD STORAGE

Clique em Next (Avançar) para aceitar o layout de disco padrão.

193 VMware SES 5

7. No painel Properties (Propriedades), atribua um nome ao novo armazenamento de dadose clique em Next (Avançar). Aceite a conguração padrão para usar todo o espaço dovolume para o armazenamento de dados ou selecione Custom Space Setting (ConguraçãoPersonalizada de Espaço) para um armazenamento de dados menor:

FIGURA 12.15: CONFIGURAÇÃO PERSONALIZADA DE ESPAÇO

Clique em Finish (Concluir) para concluir a criação do armazenamento de dados.Agora, o novo armazenamento de dados aparece na lista de armazenamentos de dados, evocê pode selecioná-lo para recuperar os detalhes. Agora, você pode usar o volume iSCSIbaseado em lrbd como qualquer outro armazenamento de dados vSphere.

194 VMware SES 5

FIGURA 12.16: VISÃO GERAL DO ARMAZENAMENTO DE DADOS ISCSI

12.2 Conclusãolrbd é um componente fundamental do SUSE Enterprise Storage que concede acessoa armazenamento em blocos distribuído e altamente disponível de qualquer servidor oucliente que reconheça o protocolo iSCSI. Ao usar o lrbd em um ou mais hosts do iSCSIGateway, as imagens RBD do Ceph tornam-se disponíveis como LUs (Logical Units – UnidadesLógicas) associadas a destinos iSCSI, que podem ser acessados com equilíbrio de carga e altadisponibilidade.

Como a conguração de todos os lrbd s é inserida no armazenamento de objetos RADOSdo Ceph, os hosts do gateway lrbd são inerentemente sem estado persistente e, portanto,podem ser substituídos, aumentados ou reduzidos conforme desejado. Como resultado, o SUSEEnterprise Storage permite que os clientes SUSE executem uma tecnologia de armazenamentoempresarial verdadeiramente distribuída, altamente disponível, resiliente e autorreparável emum hardware convencional e em uma plataforma totalmente de código-fonte aberto.

195 Conclusão SES 5

13 Sistema de arquivos em cluster

Este capítulo descreve as tarefas de administração que normalmente são executadas depois que ocluster é congurado e o CephFS é exportado. Se você precisar de mais informações sobre comocongurar o CephFS, consulte o Livro “Guia de Implantação”, Capítulo 11 “Instalação do CephFS”.

13.1 Montando o CephFS

Quando o sistema de arquivos é criado e o MDS está ativo, você está pronto para montar osistema de arquivos de um host de cliente.

13.1.1 Preparação do cliente

Se o host de cliente executa o SUSE Linux Enterprise 12 SP2 ou SP3, você pode ignorar estaseção, já que o sistema está pronto para montar o CephFS ''out-of-the-box”.

Se o host de cliente executa o SUSE Linux Enterprise 12 SP1, você precisa aplicar todos ospatches mais recentes antes de montar o CephFS.

Em qualquer caso, tudo o que é preciso para montar o CephFS está incluído no SUSE LinuxEnterprise. O produto SUSE Enterprise Storage não é necessário.

Para suportar a sintaxe completa de mount , o pacote ceph-common (que é fornecido com oSUSE Linux Enterprise) deve ser instalado antes de tentar montar o CephFS.

13.1.2 Criar um arquivo de segredo

Por padrão, o cluster do Ceph é executado com a autenticação ativada. Você deve criar umarquivo que armazena sua chave secreta (não o chaveiro propriamente dito). Para obter a chavesecreta para determinado usuário e, em seguida, criar o arquivo, faça o seguinte:

PROCEDIMENTO 13.1: CRIANDO UMA CHAVE SECRETA

1. Veja a chave do usuário especíco em um arquivo de chaveiro:

cat /etc/ceph/ceph.client.admin.keyring

196 Montando o CephFS SES 5

2. Copie a chave do usuário que utilizará o sistema de arquivos Ceph FS montado.Normalmente, a chave tem a seguinte aparência:

AQCj2YpRiAe6CxAA7/ETt7Hcl9IyxyYciVs47w==

3. Crie um arquivo com o nome de usuário como parte do nome de arquivo. Por exemplo,/etc/ceph/admin.secret para o usuário admin.

4. Cole o valor da chave no arquivo criado na etapa anterior.

5. Dena os direitos de acesso apropriados para o arquivo. O usuário deve ser a única pessoaque pode ler o arquivo. Outras pessoas não devem ter nenhum direito de acesso.

13.1.3 Montar o CephFS

Você pode montar o CephFS com o comando mount . Você precisa especicar o nome dehost ou endereço IP do monitor. Como a autenticação cephx está habilitada por padrão noSUSE Enterprise Storage, você precisa especicar um nome de usuário e também o segredorelacionado:

sudo mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secret=AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==

Como o comando anterior permanece no histórico do shell, uma abordagem mais segura é lero segredo de um arquivo:

sudo mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

Observe que o arquivo de segredo deve conter apenas o segredo do chaveiro real. Em nossoexemplo, o arquivo incluirá apenas a seguinte linha:

AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==

Dica: Especificar vários monitoresConvém especicar vários monitores separados por vírgulas na linha de comando mountpara o caso de um monitor car inativo no momento da montagem. Cada endereço demonitor adota o formato host[:porta] . Se a porta não for especicada, será usado opadrão 6789.

197 Montar o CephFS SES 5

Crie o ponto de montagem no host local:

sudo mkdir /mnt/cephfs

Monte o CephFS:

sudo mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

Um subdiretório subdir poderá ser especicado se um subconjunto do sistema de arquivostiver que ser montado:

sudo mount -t ceph ceph_mon1:6789:/subdir /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

Você pode especicar mais de um host de monitor no comando mount :

sudo mount -t ceph ceph_mon1,ceph_mon2,ceph_mon3:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

Importante: Acesso de leitura ao diretório raizSe forem usados clientes com restrição de caminho, os recursos do MDS precisarão incluiro acesso de leitura ao diretório raiz. Por exemplo, um chaveiro pode ter a seguinteaparência:

client.bar key: supersecretkey caps: [mds] allow rw path=/barjail, allow r path=/ caps: [mon] allow r caps: [osd] allow rwx

A parte allow r path=/ indica que os clientes com restrição de caminho podem ver ovolume raiz, mas não podem gravar nele. Isso pode ser um problema para casos de usoem que o isolamento completo é um requisito.

13.2 Desmontando o CephFSPara desmontar o CephFS, use o comando umount :

sudo umount /mnt/cephfs

198 Desmontando o CephFS SES 5

13.3 CephFS no /etc/fstabPara montar o CephFS automaticamente na inicialização do cliente, insira a linhacorrespondente na respectiva tabela de sistemas de arquivos /etc/fstab :

mon1:6790,mon2:/subdir /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev 0 2

13.4 Vários daemons MDS ativos (MDS ativo-ativo)

Por padrão, o CephFS é congurado para um único daemon MDS ativo. Para aumentar odesempenho dos metadados em sistemas de grande escala, é possível habilitar vários daemonsMDS ativos, que compartilharão a carga de trabalho dos metadados entre eles.

13.4.1 Quando usar MDS ativo-ativo

Considere o uso de vários daemons MDS ativos em caso de gargalo no desempenho dosmetadados no MDS único padrão.

A adição de mais daemons não aumenta o desempenho em todos os tipos de carga de trabalho.Por exemplo, um único aplicativo em execução em um só cliente não se beneciará de umnúmero maior de daemons MDS, a menos que o aplicativo esteja efetuando muitas operaçõesde metadados em paralelo.

As cargas de trabalho que costumam se beneciar de um número maior de daemons MDS ativossão aquelas com vários clientes, que podem atuar em muitos diretórios separados.

13.4.2 Aumentando o tamanho do cluster MDS ativo

Cada sistema de arquivos CephFS tem uma conguração max_mds que controla quantasclassicações serão criadas. O número real de classicações no sistema de arquivos apenas seráaumentado se um daemon sobressalente estiver disponível para assumir a nova classicação.Por exemplo, se houver apenas um daemon MDS em execução, e max_mds estiver denido comodois, não será criada uma segunda classicação.

199 CephFS no /etc/fstab SES 5

No exemplo a seguir, denimos a opção max_mds como 2 para criar uma nova classicaçãoseparadamente do padrão. Para ver as mudanças, execute ceph status antes e depois que vocêdenir max_mds e observe a linha que contém fsmap :

root@master # ceph status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby [...]root@master # ceph mds set max_mds 2root@master # ceph status [...] services: [...] mds: cephfs-2/2/2 up {0=node2=up:active,1=node1=up:active} [...]

A classicação recém-criada (1) passa pelo estado de “criação” e depois entra no estado “ativo”.

Importante: Daemons de standbyMesmo com vários daemons MDS ativos, um sistema altamente disponível ainda requerdaemons de standby para assumir o controle em caso de falha em qualquer um dosservidores que executam um daemon ativo.

Consequentemente, o limite máximo ideal de max_mds para sistemas de altadisponibilidade é menor do que o número total de servidores MDS no sistema. Para semanter disponível em caso de várias falhas do servidor, aumente o número de daemons destandby no sistema para corresponder ao número de falhas do servidor que você precisasuperar.

13.4.3 Diminuindo o número de classificações

Todas as classicações, incluindo as que devem ser removidas, devem primeiro estar ativas. Issosignica que é necessário ter pelo menos max_mds daemons MDS disponíveis.

Primeiramente, dena max_mds como um número mais baixo. Por exemplo, volte a ter umúnico MDS ativo:

root@master # ceph status [...]

200 Diminuindo o número de classificações SES 5

services: [...] mds: cephfs-2/2/2 up {0=node2=up:active,1=node1=up:active} [...]root@master # ceph mds set max_mds 1root@master # ceph status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby [...]

Observe que ainda temos dois MDS ativos. As classicações ainda existem, apesar de termosreduzido max_mds , pois max_mds apenas restringe a criação de novas classicações.

Em seguida, use o comando ceph mds deactivate rank para remover a classicaçãodesnecessária:

root@master # ceph status [...] services: [...] mds: cephfs-2/2/1 up {0=node2=up:active,1=node1=up:active}root@master # ceph mds deactivate 1telling mds.1:1 192.168.58.101:6805/2799214375 to deactivate

root@master # ceph status [...] services: [...] mds: cephfs-2/2/1 up {0=node2=up:active,1=node1=up:stopping}

root@master # ceph status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby

A classicação desativada entrará primeiro no estado de interrupção, por um período enquantoela transmite sua cota de metadados para os daemons ativos restantes. Essa fase pode levarde segundos a minutos. Se o MDS parecer travado no estado de interrupção, isso deverá serinvestigado como um possível bug.

Se um daemon MDS falhar ou for terminado durante o estado de “interrupção”, um standbyassumirá o controle, e a classicação voltará para o estado “ativo”. Você poderá tentar desativá-la novamente quando ela voltar a ser ativa.

201 Diminuindo o número de classificações SES 5

Quando um daemon sair do estado de interrupção, ele será iniciado novamente e voltará a serstandby.

13.4.4 Fixando manualmente árvores do diretório em umaclassificação

Em várias congurações de servidor de metadados ativas, um balanceador é executado, quefunciona para distribuir a carga de metadados igualmente no cluster. Em geral, isso funciona bemo suciente para a maioria dos usuários; mas, às vezes, convém anular o balanceador dinâmicocom mapeamentos explícitos de metadados para classicações especícas. Isso pode permitirque o administrador ou os usuários distribuam a carga do aplicativo igualmente ou limitem oimpacto das solicitações de metadados dos usuários sobre o cluster inteiro.

O mecanismo fornecido para essa nalidade é chamado “export pin”. Ele é um atributo estendidode diretórios. O nome desse atributo estendido é ceph.dir.pin . Os usuários podem deniresse atributo usando os comandos padrão:

setfattr -n ceph.dir.pin -v 2 /path/to/dir

O valor ( -v ) do atributo estendido é a classicação à qual atribuir a subárvore do diretório. Ovalor padrão -1 indica que o diretório não foi xado.

O export pin de um diretório é herdado do seu pai mais próximo com um export pin denido.Portanto, a denição do export pin em um diretório afeta todos os seus lhos. No entanto, axação do pai pode ser anulada pela denição do export pin do diretório lho. Por exemplo:

mkdir -p a/b # "a" and "a/b" start with no export pin set.setfattr -n ceph.dir.pin -v 1 a/ # "a" and "b" are now pinned to rank 1.setfattr -n ceph.dir.pin -v 0 a/b # "a/b" is now pinned to rank 0 # and "a/" and the rest of its children # are still pinned to rank 1.

13.5 Failover de GerenciamentoSe um daemon MDS parar de se comunicar com o monitor, o monitor aguardarámds_beacon_grace segundos (o padrão é 15 segundos) antes de marcar o daemon como lento.Você pode congurar um ou mais daemons de “standby” para assumir o controle durante ofailover do daemon MDS.

202 Fixando manualmente árvores do diretório em uma classificação SES 5

13.5.1 Configurando daemons de standby

Há várias congurações que controlam o comportamento de um daemon durante o standby.Você pode especicá-las no ceph.conf no host em que o daemon MDS é executado. O daemoncarrega essas congurações quando é iniciado e as envia para o monitor.

Por padrão, se nenhuma dessas congurações for usada, todos os daemons MDS que não tiveremuma classicação serão usados como “standby” para qualquer classicação.

As congurações que associam um daemon de standby a determinado nome ou classicação nãogarantem que o daemon apenas será usado para essa classicação. Quando há vários standbysdisponíveis, elas indicam que o daemon de standby associado será usado. Em caso de falha emuma classicação, e se um standby estiver disponível, ele será usado mesmo se estiver associadoa uma diferente classicação ou daemon nomeado.

mds_standby_replay

Se denido como verdadeiro, o daemon de standby lerá continuamente o diário demetadados de uma classicação ativa. Isso resulta em um cache de metadados a quentee acelera o processo de failover em caso de falha no daemon que está assumindo aclassicação.Uma classicação ativa pode ter apenas um daemon de reprodução de standby atribuídoa ela. Se dois daemons forem denidos como reprodução de standby, um deles venceráarbitrariamente, e o outro se tornará um standby normal que não é de reprodução.Quando um daemon entrar no estado de reprodução de standby, ele apenas seráusado como standby para a classicação que está seguindo. Se houver falha em outraclassicação, esse daemon de reprodução de standby não será usado como substituição,mesmo que não haja outros standbys disponíveis.

mds_standby_for_name

Dena essa opção para fazer com que o daemon de standby apenas assuma umaclassicação com falha se o último daemon a mantê-la corresponder a este nome.

mds_standby_for_rank

Dena essa opção para fazer com que o daemon de standby apenas assuma a classicaçãoespecicada. Se houver falha em outra classicação, esse daemon não será usado parasubstituí-la.Use em conjunto com mds_standby_for_fscid para ser especíco quanto à classicaçãodo sistema de arquivos que você pretende usar em caso de vários sistemas de arquivos.

203 Configurando daemons de standby SES 5

mds_standby_for_fscid

Se mds_standby_for_rank for denido, trata-se simplesmente de um qualicador queindica qual classicação do sistema de arquivos está sendo referenciada.Se mds_standby_for_rank não for denido, a denição de FSCID fará com que estedaemon seja direcionado para qualquer classicação no FSCID especicado. Use essa opçãose você tem um daemon que deseja usar para qualquer classicação, mas apenas em umsistema de arquivos especíco.

mon_force_standby_active

Essa conguração é usada nos hosts de monitor. O padrão é verdadeiro.Se for falso, os daemons congurados com standby_replay=true apenas se tornarãoativos se houver falha na classicação/nome que foram congurados para seguir.Por outro lado, se essa conguração for verdadeira, um daemon congurado comstandby_replay=true poderá ser atribuído a alguma outra classicação.

13.5.2 Exemplos

Veja a seguir várias congurações do ceph.conf de exemplo. Você pode copiar um ceph.confcom a conguração de todos os daemons para todos os servidores ou pode ter um arquivodiferente em cada servidor contendo a conguração do daemon desse servidor.

13.5.2.1 Par simples

Dois daemons MDS “a” e “b” atuando como par. Aquele que não estiver atribuído a umaclassicação no momento será o seguidor de reprodução de standby do outro.

[mds.a]mds standby replay = truemds standby for rank = 0

[mds.b]mds standby replay = truemds standby for rank = 0

204 Exemplos SES 5

14 NFS Ganesha: Exportar dados do Ceph pelo NFS

NFS Ganesha é um servidor NFS (consulte Sharing File Systems with NFS (https://www.suse.com/

documentation/sles-12/book_sle_admin/data/cha_nfs.html) (Compartilhando sistemas dearquivos com o NFS)) executado em um espaço de endereço de usuário, e não como parte dokernel do sistema operacional. Com o NFS Ganesha, você pode conectar seu próprio mecanismode armazenamento, como Ceph, e acessá-lo de qualquer cliente NFS.

Os compartimentos de memória do S3 são exportados para o NFS por usuário. Por exemplo,usando o caminho NÓ_DO_GANESHA:/NOMEDEUSUÁRIO/NOMEDOCOMPARTIMENTODEMEMÓRIA .

Por padrão, um CephFS é exportado por meio do caminho NÓ_DO_GANESHA:/cephfs .

14.1 Instalação

Para obter instruções, consulte o Livro “Guia de Implantação”, Capítulo 12 “Instalação do NFS

Ganesha”.

14.2 Configuração

Para obter uma lista de todos os parâmetros disponíveis no arquivo de conguração, consulte:

man ganesha-config

man ganesha-ceph-config para obter as opções da FSAL (File System Abstraction Layer– Camada de Abstração do Sistema de Arquivos) do CephFS.

man ganesha-rgw-config para obter as opções da FSAL do Object Gateway.

Esta seção inclui informações para ajudar você a congurar o servidor NFS Ganesha paraexportar os dados de cluster acessíveis por meio do Object Gateway e do CephFS.

A conguração do NFS Ganesha é controlada por /etc/ganesha/ganesha.conf . Observe queas mudanças nesse arquivo serão sobregravadas quando a Fase 4 do DeepSea for executada. Paramudar as congurações permanentemente, edite o arquivo /srv/salt/ceph/ganesha/files/ganesha.conf.j2 localizado no master Salt.

205 Instalação SES 5

14.2.1 Seção de exportação

Esta seção descreve como congurar as seções EXPORT no ganesha.conf .

EXPORT{ Export_Id = 1; Path = "/"; Pseudo = "/"; Access_Type = RW; Squash = No_Root_Squash; [...] FSAL { Name = CEPH; }}

14.2.1.1 Seção de exportação principal

Export_Id

Cada exportação precisa ter um “Export_Id” exclusivo (obrigatório).

Caminho

Caminho de exportação no pool do CephFS relacionado (obrigatório). Isso permite que ossubdiretórios sejam exportados do CephFS.

Pseudo

Caminho de exportação de destino do NFS (obrigatório para NFSv4). Ele dene em qualcaminho de exportação do NFS os dados exportados estarão disponíveis.Exemplo: com o valor /cephfs/ e após a execução de

root # mount GANESHA_IP:/cephfs/ /mnt/

Os dados do CephFS estão disponíveis no diretório /mnt/cephfs/ no cliente.

Access_Type

“RO” para acesso apenas leitura. O padrão é “None”.

Squash

Opção “squash” do NFS.

206 Seção de exportação SES 5

FSAL

“Camada de Abstração do Sistema de Arquivos” de exportação. Consulte a Seção 14.2.1.2,

“Subseção FSAL”.

14.2.1.2 Subseção FSAL

EXPORT{ [...] FSAL { Name = CEPH; }}

Nome

Dene o back end que o NFS Ganesha usa. Os valores permitidos são CEPH para CephFSou RGW para Object Gateway. Dependendo da opção, uma role-mds ou role-rgw deveser denida em policy.cfg .

14.2.2 Seção RGW

RGW { ceph_conf = "/etc/ceph/ceph.conf"; name = "name"; cluster = "ceph";}

ceph_conf

Aponta para o arquivo ceph.conf . Durante a implantação com o DeepSea, não énecessário mudar esse valor.

name

O nome do usuário do cliente Ceph que o NFS Ganesha utiliza.

cluster

Nome do cluster do Ceph. Atualmente, o SUSE Enterprise Storage 5 suporta apenas umnome de cluster, que é ceph por padrão.

207 Seção RGW SES 5

14.2.3 Mudando as portas padrão do NFS Ganesha

Por padrão, o NFS Ganesha usa a porta 2049 para NFS e 875 para suporte a rquota. Para mudar osnúmeros de porta padrão, use as opções NFS_Port e RQUOTA_Port na seção NFS_CORE_PARAM .Por exemplo:

NFS_CORE_PARAM{ NFS_Port = 2060; RQUOTA_Port = 876;}

14.3 Funções personalizadas do NFS GaneshaÉ possível denir funções personalizadas do NFS Ganesha para nós de cluster. Na sequência,essas funções são atribuídas aos nós em policy.cfg . As funções permitem o seguinte:

Nós separados do NFS Ganesha para acessar o Object Gateway e o CephFS.

Atribuição de usuários diferentes do Object Gateway a nós do NFS Ganesha.

A existência de usuários diferentes do Object Gateway permite que os nós do NFS Ganeshaacessem compartimentos de memória diferentes do S3. É possível usar os compartimentos dememória do S3 para controle de acesso. Nota: Os compartimentos de memória do S3 não devemser confundidos com os do Ceph usados no Mapa CRUSH.

14.3.1 Usuários diferentes do Object Gateway para NFS Ganesha

O seguinte procedimento de exemplo para o master Salt mostra como criar duas funções do NFSGanesha com usuários diferentes do Object Gateway. Neste exemplo, as funções gold e silversão usadas, e o DeepSea já fornece arquivos de conguração de exemplo para elas.

1. Abra o arquivo /srv/pillar/ceph/stack/global.yml com o editor de sua preferência.Crie o arquivo se ele não existir.

2. O arquivo precisa incluir as seguintes linhas:

rgw_configurations:

208 Mudando as portas padrão do NFS Ganesha SES 5

- rgw - silver - goldganesha_configurations: - silver - gold

Mais tarde, essas funções poderão ser atribuídas em policy.cfg .

3. Crie um arquivo /srv/salt/ceph/rgw/users/users.d/gold.yml e adicione o seguinteconteúdo:

- { uid: "gold1", name: "gold1", email: "gold1@demo.nil" }

Crie um arquivo /srv/salt/ceph/rgw/users/users.d/silver.yml e adicione oseguinte conteúdo:

- { uid: "silver1", name: "silver1", email: "silver1@demo.nil" }

4. Agora, os gabaritos para o ganesha.conf precisam ser criados para cada função. Ogabarito original do DeepSea é um bom ponto de partida. Crie duas cópias:

root # cd /srv/salt/ceph/ganesha/files/root # cp ganesha.conf.j2 silver.conf.j2root # cp ganesha.conf.j2 gold.conf.j2

5. As novas funções exigem chaveiros para acessar o cluster. Para conceder acesso, copie oganesha.j2 :

root # cp ganesha.j2 silver.j2root # cp ganesha.j2 gold.j2

6. Copie o chaveiro para o Object Gateway:

root # cd /srv/salt/ceph/rgw/files/root # cp rgw.j2 silver.j2root # cp rgw.j2 gold.j2

7. O Object Gateway também precisa da conguração para as diferentes funções:

root # cd /srv/salt/ceph/configuration/files/root # cp ceph.conf.rgw silver.confroot # cp ceph.conf.rgw gold.conf

209 Usuários diferentes do Object Gateway para NFS Ganesha SES 5

8. Atribua as funções recém-criadas aos nós de cluster em /srv/pillar/ceph/proposals/policy.cfg :

role-silver/cluster/NODE1.slsrole-gold/cluster/NODE2.sls

Substitua NODE1 e NODE2 pelos nomes dos nós aos quais você deseja atribuir as funções.

9. Execute as Fases de 0 a 4 do DeepSea.

14.3.2 Separando a FSAL do CephFS e do Object Gateway

O seguinte procedimento de exemplo para o master Salt mostra como criar duas novas funçõesdiferentes que usam o CephFS e o Object Gateway:

1. Abra o arquivo /srv/pillar/ceph/rgw.sls com o editor de sua preferência. Crie oarquivo se ele não existir.

2. O arquivo precisa incluir as seguintes linhas:

rgw_configurations: ganesha_cfs: users: - { uid: "demo", name: "Demo", email: "demo@demo.nil" } ganesha_rgw: users: - { uid: "demo", name: "Demo", email: "demo@demo.nil" }

ganesha_configurations: - ganesha_cfs - ganesha_rgw

Mais tarde, essas funções poderão ser atribuídas em policy.cfg .

3. Agora, os gabaritos para o ganesha.conf precisam ser criados para cada função. Ogabarito original do DeepSea é um bom ponto de partida. Crie duas cópias:

root # cd /srv/salt/ceph/ganesha/files/root # cp ganesha.conf.j2 ganesha_rgw.conf.j2root # cp ganesha.conf.j2 ganesha_cfs.conf.j2

4. Edite o ganesha_rgw.conf.j2 e remova a seção:

{% if salt.saltutil.runner('select.minions', cluster='ceph', roles='mds') != [] %}

210 Separando a FSAL do CephFS e do Object Gateway SES 5

[...]{% endif %}

5. Edite o ganesha_cfs.conf.j2 e remova a seção:

{% if salt.saltutil.runner('select.minions', cluster='ceph', roles=role) != [] %} [...]{% endif %}

6. As novas funções exigem chaveiros para acessar o cluster. Para conceder acesso, copie oganesha.j2 :

root # cp ganesha.j2 ganesha_rgw.j2root # cp ganesha.j2 ganesha_cfs.j2

A linha caps mds = "allow *" pode ser removida do ganesha_rgw.j2 .

7. Copie o chaveiro para o Object Gateway:

root # cp /srv/salt/ceph/rgw/files/rgw.j2 \/srv/salt/ceph/rgw/files/ganesha_rgw.j2

8. O Object Gateway precisa da conguração para a nova função:

root # cp /srv/salt/ceph/configuration/files/ceph.conf.rgw \/srv/salt/ceph/configuration/files/ceph.conf.ganesha_rgw

9. Atribua as funções recém-criadas aos nós de cluster em /srv/pillar/ceph/proposals/policy.cfg :

role-ganesha_rgw/cluster/NODE1.slsrole-ganesha_cfs/cluster/NODE1.sls

Substitua NODE1 e NODE2 pelos nomes dos nós aos quais você deseja atribuir as funções.

10. Execute as Fases de 0 a 4 do DeepSea.

14.4 Iniciando ou reiniciando o NFS GaneshaPara habilitar e iniciar o serviço NFS Ganesha, execute:

root # systemctl enable nfs-ganesha

211 Iniciando ou reiniciando o NFS Ganesha SES 5

root # systemctl start nfs-ganesha

Reinicie o NFS Ganesha com:

root # systemctl restart nfs-ganesha

Quando o NFS Ganesha é iniciado ou reiniciado, ele tem um tempo de espera extra de 90segundos para o NFS v4. Durante o período extra, as novas solicitações dos clientes sãoativamente rejeitadas. Portanto, os clientes podem enfrentar lentidão nas solicitações duranteo período extra do NFS.

14.5 Definindo o nível de registroMude o nível de depuração padrão NIV_EVENT editando o arquivo /etc/sysconfig/nfs-ganesha . Substitua NIV_EVENT por NIV_DEBUG ou NIV_FULL_DEBUG . O aumento do nível dedetalhes do registro pode gerar grandes quantidades de dados nos arquivos de registro.

OPTIONS="-L /var/log/ganesha/ganesha.log -f /etc/ganesha/ganesha.conf -N NIV_EVENT"

É necessário reiniciar o serviço ao mudar o nível de registro.

14.6 Verificando o compartilhamento NFS exportadoAo usar o NFS v3, você pode vericar se os compartilhamentos NFS foram exportados no nódo servidor NFS Ganesha:

root # showmount -e/ (everything)

14.7 Montando o compartilhamento NFS exportadoPara montar o compartilhamento NFS exportado (conforme congurado na Seção  14.2,

“Configuração”) em um host de cliente, execute:

root # mount -t nfs -o rw,noatime,sync \ nfs_ganesha_server_hostname:/ /path/to/local/mountpoint

212 Definindo o nível de registro SES 5

14.8 Recursos adicionaisA documentação original do NFS Ganesha pode ser encontrada em https://github.com/nfs-

ganesha/nfs-ganesha/wiki/Docs .

213 Recursos adicionais SES 5

IV Gerenciando o cluster comferramentas de GUI

15 openATTIC 215

15 openATTIC

Dica: Calamari removidoO Calamari antes era o aplicativo preferido de IU da Web para gerenciar e monitorar ocluster do Ceph. A partir do SUSE Enterprise Storage 5, o Calamari foi substituído peloopenATTIC mais avançado.

O openATTIC é um sistema de gerenciamento de armazenamento central que oferece suporteao cluster de armazenamento do Ceph. Com o openATTIC, você pode controlar tudo de umainterface de gerenciamento central. Não é mais necessário ter conhecimento do funcionamentointerno das ferramentas de armazenamento do Ceph. As tarefas de gerenciamento de clusterpodem ser executadas pela interface da Web intuitiva do openATTIC ou por sua API REST.

15.1 Implantação e configuração do openATTICEsta seção apresenta as etapas de implantação e conguração do openATTIC e os recursossuportados para que você possa administrar seu cluster do Ceph usando uma interface da Webamigável.

15.1.1 Habilitando acesso seguro ao openATTIC por SSL

Por padrão, o acesso ao aplicativo Web openATTIC usa o protocolo HTTP não seguro. Parahabilitar o acesso seguro ao openATTIC, você precisa congurar o servidor Web Apachemanualmente:

1. Se você não tem um certicado SSL assinado por uma CA (Certicate Authority –Autoridade de Certicação) reconhecida, crie um certicado SSL autoassinado e copie osarquivos dele para o diretório padrão do servidor Web. Por exemplo:

root # openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 \ -keyout key.pem -out cert.pemroot # cp cert.pem /etc/ssl/certs/servercert.pemroot # cp key.pem /etc/ssl/certs/serverkey.pem

Visite https://www.suse.com/documentation/sles-12/book_sle_admin/data/

sec_apache2_ssl.html para obter mais detalhes sobre como criar certicados SSL.

215 Implantação e configuração do openATTIC SES 5

2. Adicione “SSL” à opção APACHE_SERVER_FLAGS no arquivo de conguração /etc/sysconfig/apache2 . Você pode criá-lo manualmente ou executar os seguintes comandos:

root # a2enmod sslroot # a2enflag SSL

3. Crie /etc/apache2/vhosts.d/vhost-ssl.conf para um novo host virtual Apache como seguinte conteúdo:

<IfDefine SSL><IfDefine !NOSSL><VirtualHost *:80> ServerName OA_HOST_NAME Redirect "/" "https://OA_HOST_NAME/"</VirtualHost><VirtualHost _default_:443> ServerName OA_HOST_NAME DocumentRoot "/srv/www/htdocs" ErrorLog /var/log/apache2/error_log TransferLog /var/log/apache2/access_log SSLEngine on SSLCertificateFile /etc/ssl/certs/servercert.pem SSLCertificateKeyFile /etc/ssl/certs/serverkey.pem CustomLog /var/log/apache2/ssl_request_log ssl_combined</VirtualHost></IfDefine></IfDefine>

4. Reinicie o servidor Web para recarregar a denição do novo host virtual juntamente comos arquivos de certicado:

root # systemctl restart apache2.service

15.1.2 Implantando o openATTIC

A partir do SUSE Enterprise Storage 5, o openATTIC foi implantado como uma função doDeepSea. Consulte o Capítulo 1, Administração do cluster do Salt para ver o procedimento geral.

216 Implantando o openATTIC SES 5

15.1.3 Configuração inicial do openATTIC

Por padrão, o oaconfig cria uma conta do usuário administrador, openattic , com a senhaigual ao nome de usuário. Como medida de segurança, é altamente recomendável mudar essasenha o quanto antes:

root@minion > oaconfig changepassword openatticChanging password for user 'openattic'Password: <enter password>Password (again): <re-enter password>Password changed successfully for user 'openattic'

15.1.4 Integração do DeepSea no openATTIC

Alguns recursos do openATTIC, como gerenciamento do iSCSI Gateway e do Object Gateway,usam a API REST do DeepSea. Ela está habilitada e congurada por padrão. Se você precisaranular as congurações padrão para ns de depuração, edite /etc/sysconfig/openattic eadicione ou mude as seguintes linhas:

SALT_API_HOST="salt_api_host"SALT_API_PORT=8001SALT_API_USERNAME="example_user"SALT_API_PASSWORD="password"

Importante: oaconfig restartLembre-se de executar oaconfig restart depois que você zer mudanças no arquivo/etc/sysconfig/openattic .

Importante: Sintaxe do arquivoO /etc/sysconfig/openattic é usado no Python e no Bash. Portanto, os arquivosprecisam estar em um formato reconhecido pelo Bash, e não é possível inserir espaçosantes ou depois dos sinais de “igual”.

217 Configuração inicial do openATTIC SES 5

15.1.5 Gerenciamento do Object Gateway

Os recursos de gerenciamento do Object Gateway no openATTIC estão habilitados por padrão. Sevocê precisar anular os valores padrão para a API do Object Gateway conforme descobertos combase no DeepSea, inclua as seguintes opções com os valores relevantes em /etc/sysconfig/openattic . Por exemplo:

RGW_API_HOST="rgw_api_host"RGW_API_PORT=80RGW_API_SCHEME="http"RGW_API_ACCESS_KEY="VFEG733GBY0DJCIV6NK0"RGW_API_SECRET_KEY="lJzPbZYZTv8FzmJS5eiiZPHxlT2LMGOMW8ZAeOAq"

Nota: Recurso padrão do Object GatewaySe o recurso de admin do Object Gateway não foi congurado para usar o valor padrão“admin” conforme usado em “http://rgw_host:80/admin”, você precisa também denira opção RGW_API_ADMIN_RESOURCE apropriadamente.

Para obter as credenciais do Object Gateway, use o comando radosgw-admin :

root@minion > radosgw-admin user info --uid=admin

15.1.6 Gerenciamento do iSCSI Gateway

Os recursos de gerenciamento do iSCSI Gateway no openATTIC estão habilitados por padrão.Se você precisar anular o nome de host padrão da API do Salt, mude o valor SALT_API_HOSTconforme descrito na Seção 15.1.4, “Integração do DeepSea no openATTIC”.

15.2 Interface do usuário da Web do openATTIC

É possível gerenciar o openATTIC por meio de uma interface do usuário da Web. Abra umbrowser da Web e navegue para http:// SERVER_HOST /openattic. Para efetuar login, use o nomede usuário padrão openattic e a senha correspondente.

218 Gerenciamento do Object Gateway SES 5

FIGURA 15.1: TELA DE LOGIN DO OPENATTIC

A interface do usuário do openATTIC tem uma representação gráca dividida em um painel demenus superior e um painel de conteúdo.

A parte direita do painel superior inclui um link para as congurações de usuário atuais e umlink Logout, além de links para a lista de Tarefas em segundo plano existentes e de Noticações dosistema. O restante do painel superior é preenchido pelo menu principal do openATTIC.

O painel de conteúdo muda de acordo com o menu de itens ativado. Por padrão, um Painel deControle exibe widgets com números para informá-lo sobre o status do cluster.

219 Interface do usuário da Web do openATTIC SES 5

FIGURA 15.2: PAINEL DE CONTROLE DO OPENATTIC

15.3 Painel

Cada widget do Painel de Controle mostra informações de status especícas relacionadas aocluster do Ceph em execução. Depois que você clica no título de um widget, ele se expandepor todo o painel de conteúdo, o que pode mostrar mais detalhes. Veja a seguir uma lista devários widgets:

O widget Status informa se o cluster está funcionando corretamente. Se um problema fordetectado, você poderá ver a mensagem de erro detalhada clicando no subtítulo no widget.

Os widgets Monitors in Quorum (Monitores no Quorum), Pools, OSDs In (OSDs Internos), OSDsOut (OSDs Externos), OSDs Up (OSDs Ativos), OSDs Down (OSDs Inativos) e Average PGs per OSD(Média de Páginas por OSD) mostram apenas os números relacionados.

220 Painel SES 5

FIGURA 15.3: WIDGETS BÁSICOS

Os seguintes widgets apresentam a capacidade de armazenamento total e disponível: ClusterCapacity (Capacidade do Cluster), Available Capacity (Capacidade Disponível), Used Capacity(Capacidade Usada) e Capacity (Capacidade).

FIGURA 15.4: WIDGETS DE CAPACIDADE

Os seguintes widgets apresentam a latência de nós OSD e do monitor: Average OSD ApplyLatency (Latência Média de Aplicação do OSD), Average OSD Commit Latency (Latência Médiade Compromisso do OSD) e Average Monitor Latency (Latência Média do Monitor):

FIGURA 15.5: WIDGETS DE LATÊNCIA

O widget Throughput mostra as estatísticas de leitura e gravação por segundo em um horário.

221 Painel SES 5

FIGURA 15.6: THROUGHPUT

Dica: Mais detalhes e dicas de ferramentaSe você mover o ponteiro do mouse sobre qualquer um dos grácos exibidos, verá maisdetalhes relacionados à data e ao horário em que foram apontados em uma janela popup.

Se você clicar na área do gráco e, em seguida, arrastar o ponteiro do mouse para aesquerda ou para a direita ao longo do eixo de horário, o intervalo de horário no eixo seráampliado para o intervalo que você marcou ao mover o mouse. Para reduzir novamenteà escala original, clique duas vezes no gráco.

15.4 Tarefas relacionadas ao CephO menu principal do openATTIC lista as tarefas relacionadas ao Ceph. Atualmente, as seguintestarefas são relevantes: OSDs, RBDs, Pools, Nós, iSCSI, NFS, Mapa CRUSH e Object Gateway.

15.4.1 Recursos comuns de IU da Web

No openATTIC, você costuma trabalhar com listas. Por exemplo, listas de pools, de nós OSD oudispositivos RBD. Os seguintes widgets comuns ajudam você a gerenciar ou ajustar essas listas:

Clique em para atualizar a lista de itens.

Clique em para exibir ou ocultar colunas individuais da tabela.

Clique em e selecione quantas linhas serão exibidas em uma única página.

Clique em e ltre as linhas digitando a string de pesquisa.

222 Tarefas relacionadas ao Ceph SES 5

Use para mudar a página exibida no momento, se a lista ocupar várias páginas.

15.4.2 Listando os nós OSD

Para listar todos os nós OSD disponíveis, clique em OSDs no menu principal.

A lista mostra o nome de cada OSD, nome de host, status, peso e back end de armazenamento.

FIGURA 15.7: LISTA DE NÓS OSD

15.4.3 Gerenciando dispositivos de blocos RADOS (RBDs)

Para listar todos os Dispositivos de Blocos RADOS disponíveis, clique em RBDs no menuprincipal.

A lista mostra o nome de cada dispositivo, o nome do pool relacionado, o tamanho do dispositivoe, se “fast-di” foi habilitado durante a criação do Dispositivo de Blocos RADOS, a porcentagemjá ocupada.

223 Listando os nós OSD SES 5

FIGURA 15.8: LISTA DE RBDS

15.4.3.1 Informações de status

Para ver informações mais detalhadas sobre um dispositivo, ative a caixa de seleção dele nacoluna mais à esquerda:

FIGURA 15.9: DETALHES DO RBD

15.4.3.2 Estatísticas

Clique na guia Statistics (Estatísticas) de um Dispositivo de Blocos RADOS para ver as estatísticasdos dados transferidos. Você pode realçar a faixa de horário com o mouse para ampliá-la ereduzi-la ou selecioná-la após clicar na data no canto superior esquerdo da guia.

15.4.3.3 Instantâneos de dispositivo de blocos RADOS

Para criar um instantâneo do Dispositivo de Blocos RADOS, clique na guia Snapshots(Instantâneos) dele e selecione Create (Criar) na caixa suspensa superior esquerda.

224 Gerenciando dispositivos de blocos RADOS (RBDs) SES 5

Após selecionar um instantâneo, você poderá renomeá-lo, protegê-lo, cloná-lo ou apagá-lo. Aexclusão também funcionará se você selecionar vários instantâneos. Rollback restaura o estadodo dispositivo com base no instantâneo atual.

FIGURA 15.10: INSTANTÂNEOS RBD

15.4.3.4 Apagando RBDs

Para apagar um dispositivo ou um grupo de dispositivos, ative as respectivas caixas de seleçãona coluna mais à esquerda e clique em Delete (Apagar) na parte superior esquerda da tabelade RBDs:

FIGURA 15.11: APAGANDO RBDS

225 Gerenciando dispositivos de blocos RADOS (RBDs) SES 5

15.4.3.5 Adicionando RBDs

Para adicionar um novo dispositivo, clique em Add (Adicionar) na parte superior esquerda databela de RBDs e faça o seguinte na tela Create RBD (Criar RBD):

FIGURA 15.12: ADICIONANDO UM NOVO RBD

1. Insira o nome do novo dispositivo. Consulte o Livro “Guia de Implantação”, Capítulo 2

“Requisitos e recomendações de hardware”, Seção 2.8 “Limitações de nomeação” para saber aslimitações de nomeação.

2. Selecione o cluster que armazenará o novo pool.

3. Selecione o pool que será usado como base para a criação do novo dispositivo RBD.

4. Especique o tamanho do novo dispositivo. Se você clicar no link use max (usar máx.)acima, o tamanho máximo do pool será preenchido.

5. Para ajustar os parâmetros do dispositivo, clique em Expert settings (Congurações deespecialista) e ative ou desative as opções exibidas.

226 Gerenciando dispositivos de blocos RADOS (RBDs) SES 5

6. Clique em Create (Criar) para conrmar.

15.4.4 Gerenciando pools

Dica: Mais informações sobre poolsPara obter mais informações gerais sobre os pools do Ceph, consulte o Capítulo  7,

Gerenciando pools de armazenamento. Para obter informações especícas dos pools comcodicação de eliminação, consulte o Capítulo 9, Pools com codificação de eliminação.

Para listar todos os pools disponíveis, clique em Pools no menu principal.

A lista mostra o nome de cada pool, o ID, a porcentagem de espaço usado, o número de gruposde posicionamento, o tamanho da réplica, o tipo (“replicado” ou “eliminação”), o perl decodicação de eliminação e o conjunto de regras CRUSH.

FIGURA 15.13: LISTA DE POOLS

227 Gerenciando pools SES 5

Para ver informações mais detalhadas sobre um pool, ative a caixa de seleção dele na colunamais à esquerda:

FIGURA 15.14: DETALHES DO POOL

15.4.4.1 Apagando pools

Para apagar um pool ou um grupo de pools, ative as respectivas caixas de seleção na colunamais à esquerda e clique em Delete (Apagar) na parte superior esquerda da tabela de pools:

FIGURA 15.15: APAGANDO POOLS

228 Gerenciando pools SES 5

15.4.4.2 Adicionando pools

Para adicionar um novo pool, clique em Add (Adicionar) na parte superior esquerda da tabelade pools e faça o seguinte na tela Create Ceph pool (Criar pool do Ceph):

FIGURA 15.16: ADICIONANDO UM NOVO POOL

1. Insira o nome do novo pool. Consulte o Livro “Guia de Implantação”, Capítulo 2 “Requisitos

e recomendações de hardware”, Seção 2.8 “Limitações de nomeação” para saber as limitaçõesde nomeação.

2. Selecione o cluster que armazenará o novo pool.

3. Selecione o tipo de pool. Os pools podem ser replicados ou com codicação de eliminação.

4. a. Para um pool replicado, especique o tamanho da réplica e o número de grupos deposicionamento.

b. Para um pool com codicação de eliminação, especique o número de grupos deposicionamento e o perl de codicação de eliminação. Você pode adicionar seuperl personalizado clicando no sinal de adição “+” e especicando nome do perl,dados e pacotes de codicação, além de um domínio de falha de conjunto de regras.

5. Clique em Create (Criar) para conrmar.

15.4.5 Listando os nós

Clique em Nodes (Nós) no menu principal para ver a lista de nós disponíveis no cluster.

229 Listando os nós SES 5

FIGURA 15.17: LISTA DE NÓS

Cada nó é representado por seu nome de host, endereço IP público, ID do cluster ao qual elepertence, função do nó (por exemplo, “admin”, “armazenamento” ou “master”) e status deaceitação da chave.

15.4.6 Gerenciando o NFS Ganesha

Dica: Mais informações sobre o NFS GaneshaPara obter mais informações gerais sobre o NFS Ganesha, consulte o Capítulo  14, NFS

Ganesha: Exportar dados do Ceph pelo NFS.

Para listar todas as exportações NFS disponíveis, clique em NFS no menu principal.

A lista mostra o diretório de cada exportação, nome de host, status, tipo de back end dearmazenamento e tipo de acesso.

FIGURA 15.18: LISTA DE EXPORTAÇÕES NFS

230 Gerenciando o NFS Ganesha SES 5

Para ver informações mais detalhadas sobre uma exportação NFS, ative a caixa de seleção delana coluna mais à esquerda:

FIGURA 15.19: DETALHES DA EXPORTAÇÃO NFS

Dica: Comando de montagem NFSNa parte inferior da tela de detalhes da exportação, há um comando de montagem quepermite montar facilmente a exportação NFS relacionada em uma máquina cliente.

15.4.6.1 Adicionando exportações NFS

Para adicionar uma nova exportação NFS, clique em Add (Adicionar) na parte superior esquerdada tabela de exportações e insira as informações necessárias.

231 Gerenciando o NFS Ganesha SES 5

FIGURA 15.20: ADICIONANDO UMA NOVA EXPORTAÇÃO NFS

1. Selecione um host de servidor para a exportação NFS.

2. Selecione um back end de armazenamento: CephFS ou Object Gateway.

3. Digite o caminho do diretório para a exportação NFS. Se o diretório não existir no servidor,ele será criado.

4. Especique outras opções relacionadas ao NFS, como versão do protocolo NFS suportada,tipo de acesso, squash ou protocolo de transporte.

5. Se você precisa limitar o acesso apenas a determinados clientes, clique em Add clients(Adicionar clientes) e adicione os endereços IP deles juntamente com o tipo de acesso eas opções de squash.

6. Clique em Submit (Enviar) para conrmar.

232 Gerenciando o NFS Ganesha SES 5

15.4.6.2 Clonando e apagando exportações NFS

Para apagar uma exportação ou um grupo de exportações, ative as respectivas caixas de seleçãona coluna mais à esquerda e selecione Delete (Apagar) na parte superior esquerda da tabela degateways.

Da mesma forma, você pode selecionar Clone (Clonar) para clonar o gateway ativado.

15.4.6.3 Editando exportações NFS

Para editar uma exportação existente, clique no nome dela na tabela de exportações ou ativesua caixa de seleção e clique em Edit (Editar) na parte superior esquerda da tabela de gateways.

Em seguida, você pode ajustar todos os detalhes da exportação NFS.

FIGURA 15.21: EDITANDO UMA EXPORTAÇÃO NFS

233 Gerenciando o NFS Ganesha SES 5

15.4.7 Gerenciando iSCSI Gateways

Dica: Mais informações sobre iSCSI GatewaysPara obter mais informações gerais sobre iSCSI Gateways, consulte o Livro “Guia de

Implantação”, Capítulo 10 “Instalação do iSCSI Gateway” e o Capítulo 12, Ceph iSCSI Gateway.

Para listar todos os gateways disponíveis, clique em iSCSI no menu principal.

A lista mostra o destino de cada gateway, o estado, os portais relacionados e as imagens RBD.

FIGURA 15.22: LISTA DE ISCSI GATEWAYS

Para ver informações mais detalhadas sobre um gateway, ative a caixa de seleção dele na colunamais à esquerda:

FIGURA 15.23: DETALHES DO GATEWAY

234 Gerenciando iSCSI Gateways SES 5

15.4.7.1 Adicionando iSCSI Gateways

Para adicionar um novo iSCSI Gateway, clique em Add (Adicionar) na parte superior esquerdada tabela de gateways e insira as informações necessárias.

FIGURA 15.24: ADICIONANDO UM NOVO ISCSI GATEWAY

1. Digite o endereço de destino do novo gateway.

2. Clique em Add portal (Adicionar portal) e selecione um ou vários portais iSCSI na lista.

3. Clique em Add image (Adicionar imagem) e selecione uma ou várias imagens RBD parao gateway.

4. Se você precisa usar a autenticação para acessar o gateway, ative a caixa de seleçãoAuthentication (Autenticação) e digite as credenciais. Você poderá encontrar opções deautenticação mais avançadas após ativar Mutual authentication (Autenticação mútua) eDiscovery authentication (Autenticação de descoberta).

5. Clique em Submit (Enviar) para conrmar.

235 Gerenciando iSCSI Gateways SES 5

15.4.7.2 Editando iSCSI Gateways

Para editar um iSCSI Gateway existente, clique no nome dele na tabela de gateways ou ativesua caixa de seleção e clique em Edit (Editar) na parte superior esquerda da tabela de gateways.

Em seguida, você pode modicar o destino iSCSI, adicionar ou apagar portais e adicionar ouapagar imagens RBD relacionadas. Você também pode ajustar as informações de autenticaçãopara o gateway.

15.4.7.3 Clonando e apagando iSCSI Gateways

Para apagar um gateway ou um grupo de gateways, ative as respectivas caixas de seleção nacoluna mais à esquerda e selecione Delete (Apagar) na parte superior esquerda da tabela degateways.

Da mesma forma, você pode selecionar Clone (Clonar) para clonar o gateway ativado.

15.4.7.4 Iniciando e parando iSCSI Gateways

Para iniciar todos os gateways, selecione Start all (Iniciar todos) na parte superior esquerda databela de gateways. Para parar todos os gateways, selecione Stop all (Parar todos).

15.4.8 Vendo o mapa CRUSH do cluster

Clique em CRUSH Map (Mapa CRUSH) no menu principal para ver o mapa CRUSH do cluster.

FIGURA 15.25: MAPA CRUSH

236 Vendo o mapa CRUSH do cluster SES 5

No painel Physical setup (Conguração física), você pode ver a estrutura do cluster, conformedescrito no Mapa CRUSH.

No painel Replication rules (Regras de replicação), você poderá ver conjuntos de regrasindividuais após selecionar um deles na caixa suspensa Content (Conteúdo).

FIGURA 15.26: REGRAS DE REPLICAÇÃO

15.4.9 Gerenciando usuários e compartimentos de memória doObject Gateway

Dica: Mais informações sobre Object GatewaysPara obter mais informações gerais sobre Object Gateways, consulte o Capítulo 11, Ceph

Object Gateway.

Para listar os usuários do Object Gateway, selecione Object Gateway Users (Usuários) no menuprincipal.

A lista mostra o ID de cada usuário, o nome de exibição, o endereço de e-mail, se o usuário estásuspenso e o número máximo de compartimentos de memória para o usuário.

237 Gerenciando usuários e compartimentos de memória do Object Gateway SES 5

FIGURA 15.27: LISTA DE USUÁRIOS DO OBJECT GATEWAY

15.4.9.1 Adicionando um novo usuário do Object Gateway

Para adicionar um novo usuário do Object Gateway, clique em Add (Adicionar) na parte superioresquerda da tabela de usuários e insira as informações relevantes.

Dica: Mais informaçõesEncontre mais informações sobre as contas do usuário do Object Gateway na Seção 11.5.2,

“Gerenciando contas do S3 e do Swift”.

238 Gerenciando usuários e compartimentos de memória do Object Gateway SES 5

FIGURA 15.28: ADICIONANDO UM NOVO USUÁRIO DO OBJECT GATEWAY

1. Insira o nome de usuário, o nome completo e, opcionalmente, um endereço de e-mail e onúmero máximo de compartimentos de memória para o usuário.

2. Se o usuário precisar car suspenso inicialmente, ative a caixa de seleção Suspended(Suspendo).

3. Especique as chaves secretas e de acesso para a autenticação do S3. Para o openATTICgerar as chaves para você, ative Generate key (Gerar chave).

4. Na seção User quota (Cota do usuário), dena os limites de cota para o usuário atual.Marque Enabled (Habilitado) para ativar os limites de cota do usuário. Você podeespecicar o Maximum size (Tamanho máximo) do espaço em disco que o usuário podeutilizar no cluster ou marcar Unlimited size (Tamanho ilimitado) para não estipular limitede tamanho.Da mesma forma, especique o Maximum objects (Máximo de objetos) que um usuáriopode armazenar no cluster ou Unlimited objects (Objetos ilimitados), se o usuário puderarmazenar qualquer número de objetos.

239 Gerenciando usuários e compartimentos de memória do Object Gateway SES 5

FIGURA 15.29: COTA DO USUÁRIO

5. Na seção Bucket Quota (Cota de Compartimento de Memória), dena os limites de cota decompartimento de memória para o usuário atual.

FIGURA 15.30: COTA DE COMPARTIMENTO DE MEMÓRIA

6. Clique em Submit (Enviar) para conrmar.

15.4.9.2 Apagando usuários do Object Gateway

Para apagar um ou mais usuários do Object Gateway, ative as respectivas caixas de seleçãona coluna mais à esquerda e selecione Delete (Apagar) na parte superior esquerda da tabela deusuários.

15.4.9.3 Editando usuários do Object Gateway

Para editar as informações de um usuário do Object Gateway, ative a caixa de seleção delena coluna mais à esquerda e selecione Edit (Editar) na parte superior esquerda da tabela deusuários ou clique no ID dele. Você pode mudar as informações inseridas ao adicionar o usuáriona Seção 15.4.9.1, “Adicionando um novo usuário do Object Gateway”, além das seguintes informaçõesadicionais:

Subusuários

Adicione, remova ou edite subusuários do usuário que está sendo editado.

240 Gerenciando usuários e compartimentos de memória do Object Gateway SES 5

FIGURA 15.31: ADICIONANDO UM SUBUSUÁRIO

Chaves

Adicione, remova ou veja as chaves secretas e de acesso do usuário que está sendo editado.Você pode adicionar chaves do S3 ao usuário que está sendo editado ou ver as chaves doSwift para seus subusuários.

FIGURA 15.32: VER CHAVES DO S3

Recursos

Adicione ou remova recursos do usuário. Os recursos são aplicados a compartimentosde memória, zona, usuários, metadados e uso. Cada valor de recurso pode ser “leitura”,“gravação” ou “*” para privilégio de leitura e gravação.

241 Gerenciando usuários e compartimentos de memória do Object Gateway SES 5

FIGURA 15.33: RECURSOS

15.4.9.4 Listando compartimentos de memória para usuários do ObjectGateway

DicaCompartimento de memória é um mecanismo para armazenar objetos de dados. Umaconta do usuário pode ter vários compartimentos de memória, mas os nomes deles devemser exclusivos. Ainda que o termo “compartimento de memória” seja normalmente usadona API do Amazon S3, o termo “container” é usado no contexto da API do OpenStackSwift.

Clique em Object Gateway Buckets (Compartimentos de Memória) para listar todos oscompartimentos de memória disponíveis do Object Gateway.

FIGURA 15.34: COMPARTIMENTOS DE MEMÓRIA DO OBJECT GATEWAY

15.4.9.5 Adicionando compartimentos de memória a usuários do ObjectGateway

Para adicionar um novo compartimento de memória, clique em Add (Adicionar) na partesuperior esquerda da tabela de compartimentos de memória e insira o nome do novocompartimento de memória e o usuário relacionado do Object Gateway. Clique em Submit(Enviar) para conrmar.

242 Gerenciando usuários e compartimentos de memória do Object Gateway SES 5

FIGURA 15.35: ADICIONANDO UM NOVO COMPARTIMENTO DE MEMÓRIA

15.4.9.6 Vendo detalhes do compartimento de memória

Para ver informações detalhadas sobre um compartimento de memória do Object Gateway, ativea caixa de seleção dele na coluna mais à esquerda da tabela de compartimentos de memória.

FIGURA 15.36: DETALHES DO COMPARTIMENTO DE MEMÓRIA

15.4.9.7 Editando compartimentos de memória

Para editar um compartimento de memória, ative a caixa de seleção dele na coluna mais àesquerda e selecione Edit (Editar) na parte superior esquerda da tabela de compartimentos dememória ou clique no nome dele.

243 Gerenciando usuários e compartimentos de memória do Object Gateway SES 5

FIGURA 15.37: EDITANDO UM COMPARTIMENTO DE MEMÓRIA DO OBJECT GATEWAY

Na tela de edição, você pode mudar o usuário ao qual o compartimento de memória pertence.

15.4.9.8 Apagando compartimentos de memória

Para apagar um ou mais compartimentos de memória do Object Gateway, ative as respectivascaixas de seleção na coluna mais à esquerda da tabela de compartimentos de memória e selecioneDelete (Apagar) na parte superior esquerda da tabela.

FIGURA 15.38: APAGANDO COMPARTIMENTOS DE MEMÓRIA

Para conrmar a exclusão, digite “yes” na janela popup Delete buckets (Apagar compartimentosde memória) e clique em Delete (Apagar).

Atenção: Cuidado na exclusãoAo apagar um compartimento de memória do Object Gateway, não é feita nenhumavericação se ele está em uso, por exemplo, pelo NFS Ganesha por meio do back end dearmazenamento do S3.

244 Gerenciando usuários e compartimentos de memória do Object Gateway SES 5

V Integração com ferramentas devirtualização

16 Usando a libvirt com o Ceph 246

17 Ceph como back end para instância de KVM QEMU 252

16 Usando a libvirt com o Ceph

A biblioteca libvirt cria uma camada de abstração de máquina virtual entre as interfaces dehipervisor e os aplicativos de software que as utilizam. Com a libvirt , os desenvolvedorese administradores de sistema podem se dedicar a uma estrutura comum de gerenciamento,API comum e interface de shell comum ( virsh ) com vários hipervisores diferentes, incluindoQEMU/KVM, Xen, LXC ou VirtualBox.

Os dispositivos de blocos do Ceph suportam o QEMU/KVM. Você pode usá-los com um softwareque estabeleça interface com a libvirt . A solução de nuvem usa a libvirt para interagir como QEMU/KVM, e o QEMU/KVM interage com os dispositivos de blocos do Ceph pela librbd .

Para criar VMs que usam os dispositivos de blocos do Ceph, siga os procedimentos nas seçõesabaixo. Nos exemplos, usamos libvirt-pool para o nome do pool, client.libvirt para onome de usuário e new-libvirt-image para o nome da imagem. Você pode usar qualquer valordesejado, mas deve substituí-los durante a execução dos comandos nos procedimentos seguintes.

16.1 Configurando o Ceph

Para congurar o Ceph para uso com a libvirt , execute as seguintes etapas:

1. Crie um pool. O exemplo a seguir usa o nome do pool libvirt-pool com 128 gruposde posicionamento.

ceph osd pool create libvirt-pool 128 128

Verique se o pool existe.

ceph osd lspools

2. Crie um Usuário do Ceph. O exemplo a seguir utiliza o nome de usuário do Cephclient.libvirt e faz referência ao libvirt-pool .

ceph auth get-or-create client.libvirt mon 'allow r' osd \ 'allow class-read object_prefix rbd_children, allow rwx pool=libvirt-pool'

Verique se o nome existe.

ceph auth list

246 Configurando o Ceph SES 5

NotaA libvirt acessará o Ceph usando o ID libvirt , não o nome do Cephclient.libvirt . Consulte http://docs.ceph.com/docs/master/rados/operations/

user-management/#user para ver uma explicação detalhada da diferença entreID e nome.

3. Use o QEMU para criar uma imagem em seu pool RBD. O exemplo a seguir usa o nomeda imagem new-libvirt-image e faz referência ao libvirt-pool .

Dica: Local do arquivo de chaveiroVerique se o caminho do chaveiro do usuário “libvirt” foi especicado em /etc/ceph/ceph.conf. Por exemplo:

keyring = /etc/ceph/client.libvirt.keyring

Se o chaveiro não existir, crie-o com:

root # ceph auth get client.libvirt > /etc/ceph/client.libvirt.keyring

qemu-img create -f raw rbd:libvirt-pool/new-libvirt-image:id=libvirt 2G

Verique se a imagem existe.

rbd -p libvirt-pool ls

16.2 Preparando o gerenciador de VMÉ possível usar a libvirt sem um gerenciador de VM, mas talvez você ache mais simples criarprimeiro o domínio com virt-manager .

1. Instale um gerenciador de máquina virtual.

sudo zypper in virt-manager

2. Prepare/faça download de uma imagem de OS do sistema que deseja virtualizar.

247 Preparando o gerenciador de VM SES 5

3. Inicie o gerenciador de máquina virtual.

virt-manager

16.3 Criando uma VMPara criar uma VM com virt-manager , execute as seguintes etapas:

1. Escolha a conexão na lista, clique o botão direito do mouse nela e selecione New (Novo).

2. Importe a imagem de disco existente informando o caminho para o armazenamento existente.Especique o tipo de OS, as congurações de memória e nomeie a máquina virtual. Porexemplo, libvirt-virtual-machine .

3. Conclua a conguração e inicie a VM.

4. Verique se o domínio recém-criado existe com sudo virsh list . Se necessário,especique a string de conexão, como

virsh -c qemu+ssh://root@vm_host_hostname/system listId Name State-----------------------------------------------[...] 9 libvirt-virtual-machine running

5. Efetue login na VM e pare-a antes de congurá-la para uso com o Ceph.

16.4 Configurando a VMNeste capítulo, vamos nos concentrar na conguração de VMs para integração com o Cephusando virsh . Geralmente, os comandos virsh exigem privilégios de root ( sudo ) e nãoretornarão os resultados apropriados nem o noticarão sobre a necessidade dos privilégios deroot. Para obter uma referência dos comandos virsh , consulte Virsh Command Reference (http://

www.libvirt.org/virshcmdref.html) (Referência do comando virsh).

1. Abra o arquivo de conguração com virsh edit vm-domain-name .

sudo virsh edit libvirt-virtual-machine

248 Criando uma VM SES 5

2. Em <devices>, deve haver uma entrada <disk>.

<devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/path/to/image/recent-linux.img'/> <target dev='vda' bus='virtio'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk>

Substitua /path/to/image/recent-linux.img pelo caminho para a imagem do OS.

ImportanteNo lugar de um editor de texto, use sudo virsh edit . Se você editar o arquivo deconguração em /etc/libvirt/qemu com um editor de texto, a libvirt poderánão reconhecer a mudança. Em caso de qualquer diferença entre o conteúdo doarquivo XML em /etc/libvirt/qemu e o resultado de sudo virsh dumpxml vm-domain-name , a VM pode não funcionar apropriadamente.

3. Adicione a imagem RBD do Ceph que você já criou como uma entrada <disk>.

<disk type='network' device='disk'> <source protocol='rbd' name='libvirt-pool/new-libvirt-image'> <host name='monitor-host' port='6789'/> </source> <target dev='vda' bus='virtio'/></disk>

Substitua monitor-host pelo nome do seu host e substitua o nome do pool e/ou da imagem, conforme necessário. Você pode adicionar várias entradas <host>aos Ceph Monitors. O atributo dev é o nome do dispositivo lógico que apareceráno diretório /dev da VM. O atributo de barramento opcional indica o tipo dedispositivo de disco a ser emulado. As congurações válidas são especícas do driver(por exemplo, ide, scsi, virtio, xen, usb ou sata). Consulte Disks (http://www.libvirt.org/

formatdomain.html#elementsDisks) (Discos) para obter detalhes do elemento <disk>e dos respectivos elementos lho e atributos.

4. Grave o arquivo.

249 Configurando a VM SES 5

5. Se a autenticação estiver habilitada no cluster do Ceph (que é o padrão), você deverá gerarum segredo. Abra o editor de sua preferência e crie um arquivo chamado secret.xmlcom o seguinte conteúdo:

<secret ephemeral='no' private='no'> <usage type='ceph'> <name>client.libvirt secret</name> </usage></secret>

6. Dena o segredo.

sudo virsh secret-define --file secret.xml<uuid of secret is output here>

7. Obtenha a chave client.libvirt e grave a string de chave em um arquivo.

ceph auth get-key client.libvirt | sudo tee client.libvirt.key

8. Dena o UUID do segredo.

sudo virsh secret-set-value --secret uuid of secret \--base64 $(cat client.libvirt.key) && rm client.libvirt.key secret.xml

Você também deve denir o segredo manualmente adicionando a seguinte entrada<auth> ao elemento <disk> que você inseriu antes (substituindo o valor do uuid peloresultado do exemplo de linha de comando acima).

sudo virsh edit libvirt-virtual-machine

Em seguida, adicione o elemento <auth></auth> ao arquivo de conguração do domínio:

...</source><auth username='libvirt'> <secret type='ceph' uuid='9ec59067-fdbc-a6c0-03ff-df165c0587b8'/></auth><target ...

250 Configurando a VM SES 5

NotaO ID do exemplo é libvirt , e não o nome do Ceph client.libvirt , conformegerado na etapa 2 da Seção 16.1, “Configurando o Ceph”. Use o componente de IDdo nome do Ceph que você gerou. Se, por algum motivo, você precisar gerarnovamente o segredo, terá que executar sudo virsh secret-undefine uuidantes de executar sudo virsh secret-set-value outra vez.

16.5 ResumoApós congurar a VM para uso com o Ceph, você poderá iniciá-la. Para vericar se a VM e oCeph estão se comunicando, você pode executar os procedimentos a seguir.

1. Verique se o Ceph está em execução:

ceph health

2. Verique se a VM está em execução:

sudo virsh list

3. Verique se a VM está se comunicando com o Ceph. Substitua vm-domain-name pelonome do domínio da sua VM:

sudo virsh qemu-monitor-command --hmp vm-domain-name 'info block'

4. Verique se o dispositivo de &target dev='hdb' bus='ide'/> aparece em /dev ouem /proc/partitions :

ls /devcat /proc/partitions

251 Resumo SES 5

17 Ceph como back end para instância de KVMQEMU

O caso de uso mais frequente do Ceph envolve fornecer imagens de dispositivos de blocos paramáquinas virtuais. Por exemplo, um usuário pode criar uma imagem “perfeita” com um OS equalquer software relevante em uma conguração ideal. Em seguida, ele captura um instantâneoda imagem. Por m, ele clona o instantâneo (normalmente, várias vezes. Consulte a Seção 8.3,

“Instantâneos de dispositivo de blocos” para obter detalhes). A capacidade de criar clones de cópiaem gravação de um instantâneo signica que o Ceph pode provisionar imagens de dispositivosde blocos para máquinas virtuais rapidamente, pois o cliente não precisa fazer download deuma imagem inteira cada vez que capturar uma nova máquina virtual.

Os dispositivos de blocos do Ceph podem ser integrados às máquinas virtuais QEMU. Para obtermais informações sobre a KVM QEMU, consulte https://www.suse.com/documentation/sles-12/

book_virt/data/part_virt_qemu.html .

17.1 Instalação

Para usar os dispositivos de blocos do Ceph, o QEMU precisa ter o driver apropriado instalado.Verique se o pacote qemu-bloco-rbd está instalado (instale-o se necessário):

sudo zypper install qemu-block-rbd

17.2 Uso

A linha de comando do QEMU espera você especicar o nome do pool e da imagem. Vocêtambém pode especicar o nome de um instantâneo.

qemu-img command options \rbd:pool-name/image-name@snapshot-name:option1=value1:option2=value2...

Por exemplo, se você especicar as opções id e conf , a aparência deverá ser a seguinte:

qemu-img command options \rbd:pool_name/image_name:id=glance:conf=/etc/ceph/ceph.conf

252 Instalação SES 5

17.3 Criando imagens com o QEMUVocê pode criar uma imagem de dispositivo de blocos no QEMU. Você deve especicar rbd , onome do pool e o nome da imagem que deseja criar. Você também deve especicar o tamanhoda imagem.

qemu-img create -f raw rbd:pool-name/image-name size

Por exemplo:

qemu-img create -f raw rbd:pool1/image1 10GFormatting 'rbd:pool1/image1', fmt=raw size=10737418240 nocow=off cluster_size=0

ImportanteO formato de dados brutos é realmente a única opção de formato sensível para usarcom o RBD. Tecnicamente, você pode usar outros formatos compatíveis com o QEMU,como qcow2 , mas isso aumentará o overhead e também tornará o volume não seguropara migração dinâmica da máquina virtual quando o cache estiver habilitado.

17.4 Redimensionando imagens com o QEMUÉ possível redimensionar uma imagem de dispositivo de blocos usando o QEMU. Você deveespecicar rbd , o nome do pool e o nome da imagem que deseja redimensionar. Você tambémdeve especicar o tamanho da imagem.

qemu-img resize rbd:pool-name/image-name size

Por exemplo:

qemu-img resize rbd:pool1/image1 9GImage resized.

17.5 Recuperando informações da imagem com oQEMUVocê pode recuperar informações da imagem do dispositivo de blocos usando o QEMU. Vocêdeve especicar rbd , o nome do pool e o nome da imagem.

253 Criando imagens com o QEMU SES 5

qemu-img info rbd:pool-name/image-name

Por exemplo:

qemu-img info rbd:pool1/image1image: rbd:pool1/image1file format: rawvirtual size: 9.0G (9663676416 bytes)disk size: unavailablecluster_size: 4194304

17.6 Executando o QEMU com o RBDO QEMU pode acessar uma imagem como dispositivo de blocos virtual diretamente pelolibrbd . Isso evita um switch de contexto adicional e pode ser melhor do que o cache do RBD.

Você pode usar qemu-img para converter as imagens existentes de máquinas virtuais emimagens de dispositivos de blocos do Ceph. Por exemplo, se você tem uma imagem qcow2, podeexecutar:

qemu-img convert -f qcow2 -O raw sles12.qcow2 rbd:pool1/sles12

Para executar uma inicialização de máquina virtual dessa imagem, você pode executar:

qemu -m 1024 -drive format=raw,file=rbd:pool1/sles12

O cache do RBD (http://ceph.com/docs/master/rbd/rbd-config-ref/#cache-settings) podemelhorar o desempenho signicativamente. As opções de cache do QEMU controlam o cachedo librbd :

qemu -m 1024 -drive format=rbd,file=rbd:pool1/sles12,cache=writeback

17.7 Habilitando descarte/TRIMOs dispositivos de blocos do Ceph suportam a operação de descarte. Isso signica que umconvidado pode enviar solicitações TRIM para permitir que um dispositivo de blocos do Cephreaproveite o espaço não usado. Para habilitar esse recurso, monte o XFS com a opção dedescarte.

254 Executando o QEMU com o RBD SES 5

Para que ele que disponível ao convidado, é necessário habilitá-lo explicitamente no dispositivode blocos. Para fazer isso, você deve especicar discard_granularity associado à unidade:

qemu -m 1024 -drive format=raw,file=rbd:pool1/sles12,id=drive1,if=none \-device driver=ide-hd,drive=drive1,discard_granularity=512

NotaO exemplo acima usa o driver IDE. O driver virtio não suporta descarte.

Se for usar o libvirt , edite o arquivo de conguração do domínio libvirt usando virsh editpara incluir o valor xmlns:qemu . Em seguida, adicione qemu:commandline block como lhodesse domínio. O exemplo a seguir mostra como denir dois dispositivos com qemu id= comvalores discard_granularity diferentes.

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='block.scsi0-0-0.discard_granularity=4096'/> <qemu:arg value='-set'/> <qemu:arg value='block.scsi0-0-1.discard_granularity=65536'/> </qemu:commandline></domain>

17.8 Opções de cache do QEMUAs opções de cache do QEMU correspondem às seguintes congurações de Cache do Ceph RBD.

Writeback:

rbd_cache = true

Writethrough:

rbd_cache = truerbd_cache_max_dirty = 0

Nenhuma:

rbd_cache = false

255 Opções de cache do QEMU SES 5

As congurações de cache do QEMU anulam as congurações padrão do Ceph (conguraçõesque não são explicitamente denidas no arquivo de conguração do Ceph). Se você denirexplicitamente as congurações de Cache do RBD (http://ceph.com/docs/master/rbd/rbd-config-

ref/#cache-settings) no arquivo de conguração do Ceph, elas anularão as congurações decache do QEMU. Se você denir as congurações de cache na linha de comando do QEMU, elasanularão as congurações do arquivo de conguração do Ceph.

256 Opções de cache do QEMU SES 5

VI Perguntas frequentes, dicas e soluçãode problemas

18 Dicas e truques 258

19 Perguntas frequentes (FAQ) 271

20 Solução de problemas 274

18 Dicas e truques

O capítulo apresenta informações para ajudar você a melhorar o desempenho do cluster do Cephe inclui dicas de como congurá-lo.

18.1 Ajustando a depuração

Por padrão, o Ceph executa uma depuração diária simples (encontre mais detalhes na Seção 6.5,

“Depuração”) e uma depuração semanal em detalhes. A depuração simples verica os tamanhos eos checksums dos objetos para garantir que os grupos de posicionamento estejam armazenandoos mesmos dados dos objetos. A depuração em detalhes compara o conteúdo de um objetocom o de suas réplicas para garantir que o conteúdo real seja o mesmo. O ponto negativo davericação de integridade de dados é uma carga de E/S maior no cluster durante o procedimentode depuração.

As congurações padrão permitem que os Ceph OSDs iniciem a depuração em horáriosinadequados. Por exemplo, durante os períodos de cargas elevadas. Os clientes podem enfrentarlatência e baixo desempenho quando as operações de depuração entram em conito com asoperações deles. O Ceph dispõe de várias congurações de depuração que podem limitá-la aperíodos com cargas menores ou fora dos horários de pico.

Se o cluster tem carga alta durante o dia e carga baixa à noite, considere restringir a depuraçãoa horários noturnos, como das 23h às 6h:

[osd]osd_scrub_begin_hour = 23osd_scrub_end_hour = 6

Se a restrição de horário não for um método ecaz para determinar uma programação dedepuração, considere usar a opção osd_scrub_load_threshold . O valor padrão é 0,5, mas elepode ser modicado para condições de carga baixa:

[osd]osd_scrub_load_threshold = 0.25

258 Ajustando a depuração SES 5

18.2 Parando os OSDs sem redistribuiçãoVocê precisa parar os OSDs para manutenção periódica. Se você não deseja que o CRUSHredistribua automaticamente o cluster para evitar transferências grandes de dados, dena ocluster primeiro como noout :

root@minion > ceph osd set noout

Se o cluster estiver denido como noout , você poderá iniciar a interrupção dos OSDs no domíniode falha que requer o trabalho de manutenção:

root@minion > systemctl stop ceph-osd@OSD_NUMBER.service

Mais informações podem ser encontradas na Seção 3.1.2, “Iniciando, parando e reiniciando serviços

individuais”.

Após concluir a manutenção, reinicie os OSDs:

root@minion > systemctl start ceph-osd@OSD_NUMBER.service

Depois que os serviços do OSD forem iniciados, cancele a denição do cluster como noout :

root@minion > ceph osd unset noout

18.3 Sincronização de horário dos nósO Ceph requer uma sincronização de horário precisa entre os nós especícos. Você devecongurar um nó com seu próprio servidor NTP. Mesmo que você possa apontar todas asinstâncias ntpd para um servidor de horário público remoto, isso não é recomendável com oCeph. Com essa conguração, cada nó no cluster tem seu próprio daemon NTP que se comunicacontinuamente pela Internet com um conjunto de três ou quatro servidores de horário, todoseles a alguns saltos de distância. Essa solução apresenta um alto grau de variação de latênciaque torna difícil ou impossível manter a diferença do relógio abaixo de 0,05 segundo (valorexigido pelos Ceph Monitors).

Portanto, use uma única máquina, como o servidor NTP, para o cluster inteiro. Depois disso,a instância ntpd do servidor NTP poderá apontar para o servidor NTP (público) remoto,ou ela poderá ter sua própria fonte de horário. As instâncias ntpd em todos os nós serãodepois apontadas para esse servidor local. Essa solução apresenta diversas vantagens, como

259 Parando os OSDs sem redistribuição SES 5

eliminar tráfego de rede e desvios de relógio desnecessários e diminuir a carga nos servidoresNTP públicos. Para obter detalhes sobre como congurar o servidor NTP, consulte o Guia

de Administração do SUSE Linux Enterprise Server (https://www.suse.com/documentation/sled11/

book_sle_admin/data/cha_netz_xntp.html) .

Em seguida, para mudar o horário no cluster, faça o seguinte:

Importante: Definindo o horárioEm algum momento, é provável que você tenha que reverter o horário. Por exemplo, emcaso de mudança do horário de verão para o padrão. Não é recomendável retroceder ohorário por um período maior do que o de inatividade do cluster. Avançar o horário nãocausa nenhum problema.

PROCEDIMENTO 18.1: SINCRONIZAÇÃO DE HORÁRIO NO CLUSTER

1. Pare todos os clientes que acessam o cluster do Ceph, principalmente aqueles que usamo iSCSI.

2. Encerre o cluster do Ceph. Em cada nó, execute:

systemctl stop ceph.target

NotaSe você usa o Ceph e o SUSE OpenStack Cloud, pare também o SUSE OpenStackCloud.

3. Verique se o servidor NTP foi congurado corretamente: todos os daemons ntpd obtêmo horário de uma ou mais fontes na rede local.

4. Dena o horário correto no servidor NTP.

5. Verique se o NTP está em execução e funcionando apropriadamente. Execute em todosos nós:

status ntpd.service

ou

ntpq -p

260 Sincronização de horário dos nós SES 5

6. Inicie todos os nós de monitoramento e verique se não há nenhum desvio de relógio:

systemctl start target

7. Inicie todos os nós OSD.

8. Inicie os outros serviços do Ceph.

9. Se você tiver, inicie o SUSE OpenStack Cloud.

18.4 Verificando a gravação de dados sem equilíbrio

Quando os dados são gravados nos OSDs igualmente, o cluster é considerado equilibrado. CadaOSD em um cluster recebe um peso. O peso é um número relativo que informa ao Ceph aquantidade de dados que devem ser gravados no OSD relacionado. Quanto maior o peso, maisdados serão gravados. Se um OSD tiver peso zero, não serão gravados dados nele. Se o peso deum OSD for relativamente alto em comparação com outros OSDs, uma grande parte dos dadosserá gravada nele, o que torna o cluster desequilibrado.

Os clusters desequilibrados apresentam baixo desempenho e, em caso de falha repentina de umOSD com peso elevado, muitos dados precisam ser movidos para outros OSDs, o que tambémtorna o cluster mais lento.

Para evitar isso, você deve vericar regularmente a quantidade de dados gravados nos OSDs. Se ovalor estiver entre 30% a 50% da capacidade de um grupo de OSDs especicada por determinadoconjunto de regras, você precisará redenir o peso dos OSDs. Verique cada disco e descubraqual deles é preenchido mais rapidamente do que os outros (ou está mais lento no geral) e reduzao peso dele. O mesmo é válido para os OSDs em que não há dados sucientes gravados. Vocêpode aumentar o peso deles para o Ceph gravar mais dados neles. No exemplo a seguir, vocêdescobrirá o peso de um OSD com ID 13 e redenirá o peso de 3 para 3,05:

$ ceph osd tree | grep osd.13 13 3 osd.13 up 1

$ ceph osd crush reweight osd.13 3.05 reweighted item id 13 name 'osd.13' to 3.05 in crush map

$ ceph osd tree | grep osd.13 13 3.05 osd.13 up 1

261 Verificando a gravação de dados sem equilíbrio SES 5

Dica: Redefinição de peso do OSD por utilizaçãoO comando ceph osd reweight-by-utilization threshold automatiza o processode redução de peso dos OSDs que estão com excesso de uso. Por padrão, ele diminuiráos pesos dos OSDs que atingiram 120% de uso médio. Porém, se você incluir o comandothreshold, ele usará essa porcentagem no lugar.

18.5 Subvolume Btrfs para /var/lib/ceph

Por padrão, o SUSE Linux Enterprise é instalado em uma partição Btrfs. O diretório /var/lib/ceph deve ser excluído de instantâneos e rollbacks Btrfs, principalmente quando há um MONem execução no nó. O DeepSea oferece o executor fs , que pode congurar um subvolume paraesse caminho.

18.5.1 Requisitos para nova instalação

Se você está congurando o cluster pela primeira vez, os seguintes requisitos devem seratendidos antes que você possa usar o executor do DeepSea:

O SALT e o DeepSea estão instalados apropriadamente e funcionando de acordo com estadocumentação.

salt-run state.orch ceph.stage.0 foi invocado para sincronizar todos os módulosdo Salt e do DeepSea com os minions.

O Ceph ainda não foi instalado, portanto, o ceph.stage.3 ainda não foi executado e o /var/lib/ceph ainda não existe.

262 Subvolume Btrfs para /var/lib/ceph SES 5

18.5.2 Requisitos para instalação existente

Se o cluster já foi instalado, os seguintes requisitos devem ser atendidos antes que você possausar o executor do DeepSea:

O upgrade dos nós foi feito para o SUSE Enterprise Storage e o cluster está sob controledo DeepSea.

O cluster do Ceph está funcionando e saudável.

O processo de upgrade sincronizou os módulos do Salt e do DeepSea com todos os nósdo minion.

18.5.3 Configuração automática

No master Salt, execute:

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

Em nós sem um diretório /var/lib/ceph existente, esse comando fará o seguinte (umnó de cada vez):

criará o /var/lib/ceph como um subvolume Btrfs @/var/lib/ceph .

montará o novo subvolume e atualizará o /etc/fstab apropriadamente.

desabilitará a cópia em gravação para /var/lib/ceph .

Em nós com uma instalação do Ceph existente, esse comando fará o seguinte (um nó decada vez):

terminará os processos do Ceph em execução.

desmontará os OSDs no nó.

criará o subvolume Btrfs @/var/lib/ceph e migrará os dados existentes do /var/lib/ceph .

montará o novo subvolume e atualizará o /etc/fstab apropriadamente.

desabilitará a cópia em gravação para /var/lib/ceph/* , omitindo o /var/lib/ceph/osd/* .

263 Requisitos para instalação existente SES 5

remontará os OSDs.

reiniciará os daemons Ceph.

18.5.4 Configuração manual

Este procedimento usa o novo executor fs .

1. Inspeciona o estado de /var/lib/ceph em todos os nós e imprime sugestões sobre comoproceder:

root@master # salt-run fs.inspect_var

Isso retornará um dos seguintes comandos:

salt-run fs.create_varsalt-run fs.migrate_varsalt-run fs.correct_var_attrs

2. Execute o comando que foi retornado na etapa anterior.Se ocorrer um erro em um dos nós, a execução dos outros nós também será interrompida,e o executor tentará reverter as mudanças realizadas. Consulte os arquivos de registro nosminions com problema para determinar o que houve de errado. Será possível executarnovamente o executor depois que o problema for resolvido.

O comando salt-run fs.help gera uma lista de todos os comandos de executor e de móduloreferentes ao módulo fs .

18.6 Aumentando os descritores de arquivosPara os daemons OSD, as operações de leitura/gravação são essenciais para manter o equilíbriodo cluster do Ceph. Geralmente, eles precisam ter muitos arquivos abertos para leitura egravação ao mesmo tempo. No nível do OS, o número máximo de arquivos abertos ao mesmotempo é chamado de “número máximo de descritores de arquivos”.

Para evitar que os OSDs quem sem descritores de arquivos, você pode anular o valor padrãodo OS e especicar o número em /etc/ceph/ceph.conf . Por exemplo:

max_open_files = 131072

264 Configuração manual SES 5

Após mudar o max_open_files , você precisará reiniciar o serviço do OSD no nó do Cephrelevante.

18.7 Como usar partições existentes para OSDsincluindo diários OSD

ImportanteEsta seção descreve um tópico avançado que apenas especialistas em armazenamentoe desenvolvedores devem consultar. Geralmente, ele é necessário ao usar tamanhos dediário OSD não padrão. Se o tamanho da partição do OSD for menor do que 10 GB, o pesoinicial será arredondado para 0 e, como não são inseridos dados nela, você deve aumentaro peso. Não assumimos nenhuma responsabilidade em relação a diários excessivamentepreenchidos.

Se você precisar usar partições de disco existentes como nó OSD, as partições de diário e dedados do OSD deverão estar em uma tabela de partição GPT.

Você precisa denir os tipos de partição corretos como as partições do OSD para que o udev asreconheça adequadamente e dena a propriedade delas como ceph:ceph .

Por exemplo, para denir o tipo de partição de diário /dev/vdb1 e de dados /dev/vdb2 ,execute o seguinte:

sudo sgdisk --typecode=1:45b0969e-9b03-4f30-b4c6-b4b80ceff106 /dev/vdbsudo sgdisk --typecode=2:4fbd7e29-9d25-41b8-afd0-062c0ceff05d /dev/vdb

DicaOs tipos de tabela de partição do Ceph estão relacionados em /usr/lib/udev/

rules.d/95-ceph-osd.rules :

cat /usr/lib/udev/rules.d/95-ceph-osd.rules# OSD_UUIDACTION=="add", SUBSYSTEM=="block", \ ENV{DEVTYPE}=="partition", \ ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \ OWNER:="ceph", GROUP:="ceph", MODE:="660", \ RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name"

265 Como usar partições existentes para OSDs incluindo diários OSD SES 5

ACTION=="change", SUBSYSTEM=="block", \ ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \ OWNER="ceph", GROUP="ceph", MODE="660"

# JOURNAL_UUIDACTION=="add", SUBSYSTEM=="block", \ ENV{DEVTYPE}=="partition", \ ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \ OWNER:="ceph", GROUP:="ceph", MODE:="660", \ RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name"ACTION=="change", SUBSYSTEM=="block", \ ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \ OWNER="ceph", GROUP="ceph", MODE="660"[...]

18.8 Integração com software de virtualização

18.8.1 Armazenando discos da KVM no cluster do Ceph

Você pode criar uma imagem de disco da máquina virtual controlada pela KVM, armazená-laem um pool do Ceph, opcionalmente, converter o conteúdo de uma imagem existente nela e,em seguida, executar a máquina virtual com qemu-kvm usando a imagem de disco armazenadano cluster. Para obter informações mais detalhadas, consulte o Capítulo 17, Ceph como back end

para instância de KVM QEMU.

18.8.2 Armazenando discos da libvirt no cluster do Ceph

Similar à KVM (consulte a Seção 18.8.1, “Armazenando discos da KVM no cluster do Ceph”), você podeusar o Ceph para armazenar máquinas virtuais controladas pela libvirt . A vantagem é quevocê pode executar qualquer solução de virtualização compatível com libvirt , como KVM,Xen ou LXC. Para obter mais informações, consulte o Capítulo 16, Usando a libvirt com o Ceph.

18.8.3 Armazenando discos do Xen no cluster do Ceph

Uma forma de usar o Ceph para armazenar discos do Xen é usar a libvirt conforme descritono Capítulo 16, Usando a libvirt com o Ceph.

266 Integração com software de virtualização SES 5

Outra opção é fazer com que o Xen se comunique diretamente com o driver de dispositivo deblocos rbd :

1. Se você não tem uma imagem de disco preparada para Xen, crie uma nova:

rbd create myimage --size 8000 --pool mypool

2. Liste as imagens no pool mypool e verique se a nova imagem está lá:

rbd list mypool

3. Crie um novo dispositivo de blocos mapeando a imagem myimage para o módulo rbddo kernel:

sudo rbd map --pool mypool myimage

Dica: Nome e autenticação de usuárioPara especicar um nome de usuário, utilize --id user-name . Além disso, se vocêusar a autenticação cephx , deverá também especicar um segredo. Ele pode vir deum chaveiro ou de um arquivo que contém o segredo:

sudo rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

ou

sudo rbd map --pool rbd myimage --id admin --keyfile /path/to/file

4. Liste todos os dispositivos mapeados:

rbd showmapped id pool image snap device 0 mypool myimage - /dev/rbd0

5. Agora, você pode congurar o Xen para usar esse dispositivo como disco para executaruma máquina virtual. Por exemplo, você pode adicionar a seguinte linha ao arquivo deconguração de domínio no estilo xl :

disk = [ '/dev/rbd0,,sda', '/dev/cdrom,,sdc,cdrom' ]

267 Armazenando discos do Xen no cluster do Ceph SES 5

18.9 Configurações de firewall para o Ceph

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

É recomendável proteger a comunicação do cluster de rede com o SUSE Firewall.Você pode editar sua conguração selecionando YaST Security and Users (Segurança eUsuários) Firewall Allowed Services (Serviços Permitidos).

Veja a seguir uma lista de serviços relacionados do Ceph e os números de porta que elescostumam usar:

Ceph Monitor

Habilitar o serviço Ceph MON ou a porta 6789 (TCP).

Ceph OSD ou Servidor de Metadados

Habilitar o serviço Ceph OSD/MDS ou as portas 6800-7300 (TCP).

iSCSI Gateway

Porta 3260 aberta (TCP).

Object Gateway

Abrir a porta de comunicação do Object Gateway. Isso é denido no /etc/ceph.conf nalinha que começa com rgw frontends = . O padrão é 80 para HTTP e 443 para HTTPS(TCP).

NFS Ganesha

Por padrão, o NFS Ganesha usa as portas 2049 (serviço NFS, TCP) e 875 (suporte a rquota,TCP). Consulte a Seção 14.2.3, “Mudando as portas padrão do NFS Ganesha” para obter maisinformações sobre como mudar as portas padrão do NFS Ganesha.

268 Configurações de firewall para o Ceph SES 5

Serviços com base no Apache, como openATTIC, SMT ou SUSE Manager

Portas abertas 80 para HTTP e 443 para HTTPS (TCP).

SSH

Porta 22 aberta (TCP).

NTP

Porta 123 aberta (UDP).

Salt

Portas 4505 e 4506 abertas (TCP).

Grafana

Porta 3000 aberta (TCP).

Prometheus

Porta 9100 aberta (TCP).

18.10 Testando o desempenho da redePara testar o desempenho da rede, o executor net do DeepSea oferece os comandos a seguir.

Um ping simples para todos os nós:

root@master # salt-run net.pingSucceeded: 9 addresses from 9 minions average rtt 1.35 ms

Um ping jumbo para todos os nós:

root@master # salt-run net.jumbo_pingSucceeded: 9 addresses from 9 minions average rtt 2.13 ms

Um teste de largura de banda:

root@master # salt-run net.iperfFastest 2 hosts: |_ - 192.168.58.106 - 2981 Mbits/sec |_ - 192.168.58.107 - 2967 Mbits/secSlowest 2 hosts:

269 Testando o desempenho da rede SES 5

|_ - 192.168.58.102 - 2857 Mbits/sec |_ - 192.168.58.103 - 2842 Mbits/sec

18.11 Substituindo o disco de armazenamentoSe você precisa substituir um disco de armazenamento em um cluster do Ceph, pode fazerisso durante a plena operação do cluster. A substituição provocará um aumento temporário datransferência de dados.

Se houver falha no disco inteiro, o Ceph precisará regravar pelo menos a mesma quantidadede dados que a capacidade do disco com falha. Se o disco for removido apropriadamente e,em seguida, reinserido para evitar perda de redundância durante o processo, a quantidade dedados regravados será duas vezes maior. Se o novo disco tiver um tamanho diferente daqueleque foi substituído, isso causará a redistribuição de alguns dados adicionais para nivelar o usode todos os OSDs.

270 Substituindo o disco de armazenamento SES 5

19 Perguntas frequentes (FAQ)

19.1 Como o número de grupos de posicionamentoafeta o desempenho do cluster?

Quando o cluster está atingindo 70 a 80% de sua capacidade, é hora de adicionar OSDs a ele. Aoaumentar o número de OSDs, você pode considerar também o aumento do número de gruposde posicionamento.

AtençãoMudar o número de PGs provoca a transferência de muitos dados no cluster.

O cálculo do valor ideal para o cluster recém-dimensionado é uma tarefa complexa.

Um alto número de PGs cria pequenos pacotes de dados. Isso acelera a recuperação após a falhaem um OSD, mas sobrecarrega os nós do monitor, pois eles são responsáveis por calcular o localdos dados.

Por outro lado, um baixo número de PGs leva mais tempo e exige a transferência de dados pararecuperação de uma falha no OSD, mas não impõe tanta carga sobre os nós do monitor, já queeles precisam calcular os locais para menos pacotes de dados (porém, maiores).

Encontre mais informações sobre o número ideal de PGs para o seu cluster usando a calculadora

online (http://ceph.com/pgcalc/) .

19.2 Posso usar SSDs e discos rígidos no mesmocluster?

Geralmente, as SSDs (Solid-State Drives – Unidades de Estado Sólido) são mais rápidas do queos discos rígidos. Se você combinar os dois tipos de discos na mesma operação de gravação, osdados que estiverem sendo gravados no disco SSD carão mais lentos por causa do desempenhodo disco rígido. Portanto, você nunca deve combinar SSDs e discos rígidos para gravação de dados,seguindo a mesma regra (consulte a Seção 6.3, “Conjuntos de regras” para obter mais informaçõessobre as regras de armazenamento de dados).

271 Como o número de grupos de posicionamento afeta o desempenho do cluster? SES 5

Geralmente, há dois casos em que o uso de SSD e disco rígido no mesmo cluster é ideal:

1. Usar cada tipo de disco para gravar dados seguindo regras diferentes. Nesse caso, vocêprecisa ter uma regra separada para o disco SSD e outra regra para o disco rígido.

2. Usar cada tipo de disco para uma nalidade especíca. Por exemplo, o disco SSD paradiário, e o disco rígido para armazenamento de dados.

19.3 Quais são as compensações de usar um diáriona SSD?

O uso de SSDs para diário(s) OSD é melhor para o desempenho, pois o diário costuma ser ogargalo dos OSDs apenas de disco rígido. Em geral, as SSDs são usadas para compartilhar diáriosde vários OSDs.

Veja a seguir uma lista das possíveis desvantagens de uso de SSDs para diário OSD:

Os discos SSD são mais caros do que os discos rígidos. Porém, como um diário OSD requerapenas até 6 GB de espaço em disco, o preço talvez não seja tão decisivo.

O disco SSD consome slots de armazenamento que podem ser usados por um disco rígidogrande para estender a capacidade do cluster.

Os discos SSD reduziram os ciclos de gravação em comparação com os discos rígidos, masas tecnologias modernas estão começando a eliminar o problema.

Se você compartilha mais diários no mesmo disco SSD, corre o risco de perder todos osOSDs relacionados depois de uma falha no disco SSD. Isso exigirá a migração de muitosdados para redistribuir o cluster.

Os discos de HotPlug tornam-se mais complexos, pois o mapeamento de dados não é 1:1em relação ao OSD com falha e o disco de diário.

272 Quais são as compensações de usar um diário na SSD? SES 5

19.4 O que acontece quando há falha em um disco?Quando um disco com dados de cluster armazenados tem algum problema de hardware e parade funcionar, veja o que acontece:

O OSD relacionado falha e é automaticamente removido do cluster.

Os dados do disco com falha são replicados para outro OSD no cluster com base em outrascópias dos mesmos dados armazenados em outros OSDs.

Em seguida, você deve remover o disco do Mapa CRUSH do cluster e sicamente dohardware de host.

19.5 O que acontece quando há falha em um discode diário?É possível congurar o Ceph para armazenar diários ou gravar registros antecipados emdispositivos separados dos OSDs. Quando há falha em um disco dedicado a um diário, tambémhá falha no(s) OSD(s) relacionado(s) (consulte a Seção 19.4, “O que acontece quando há falha em

um disco?”).

Atenção: Hospedando vários diários em um discoPara melhorar o desempenho, você pode usar um disco rápido (como SSD) paraarmazenar partições de diário para vários OSDs. Não recomendamos hospedar diáriospara mais do que quatro OSDs em um disco, já que em caso de falha no disco dodiário, você corre o risco de perder os dados armazenados de todos os discos dos OSDsrelacionados.

273 O que acontece quando há falha em um disco? SES 5

20 Solução de problemas

Este capítulo descreve vários problemas que você pode ter ao operar um cluster do Ceph.

20.1 Relatando problemas de softwareSe você tiver algum problema durante a execução do SUSE Enterprise Storage relacionado aalguns dos seus componentes, como Ceph ou Object Gateway, relate-o ao Suporte Técnico daSUSE. A forma recomendada é pelo utilitário supportconfig .

DicaComo o supportconfig é um software modular, verique se o pacote supportutils-plugin-ses está instalado.

rpm -q supportutils-plugin-ses

Se ele estiver ausente no servidor Ceph, instale-o com

zypper ref && zypper in supportutils-plugin-ses

Embora você possa usar o supportconfig na linha de comando, é recomendávelusar o módulo do YaST relacionado. Há mais informações a respeito dosupportconfig em https://www.suse.com/documentation/sles-12/singlehtml/book_sle_admin/

book_sle_admin.html#sec.admsupport.supportconfig .

20.2 Falha ao enviar objetos grandes pelo rados comOSD completoO rados é um utilitário de linha de comando que gerencia o armazenamento de objeto RADOS.Para obter mais informações, consulte man 8 rados .

Se você enviar um objeto grande para um cluster do Ceph com o utilitário rados , como

rados -p mypool put myobject /file/to/send

274 Relatando problemas de software SES 5

ele poderá preencher todo o espaço do OSD relacionado e causar sérios problemas nodesempenho do cluster.

20.3 Sistema de arquivos XFS corrompidoEm raras circunstâncias, como bug de kernel ou hardware defeituoso/mal congurado, o sistemade arquivos adjacente (XFS) no qual um OSD armazena os dados pode ser danicado e incapazde ser montado.

Se você tem certeza de que não há nenhum problema com o hardware e o sistema estácongurado apropriadamente, emita um bug no subsistema XFS do kernel do SUSE LinuxEnterprise Server e marque o OSD especíco como inativo:

ceph osd down OSD identification

Atenção: Não formatar ou, de alguma forma, modificar odispositivo danificadoMesmo que pareça plausível usar o xfs_repair para corrigir o problema no sistema dearquivos, não o utilize, pois o comando modica o sistema de arquivos. O OSD pode seriniciado, mas seu funcionamento talvez seja afetado.

Agora, limpe (zap) o disco subjacente e recrie o OSD executando:

ceph-disk prepare --zap $OSD_DISK_DEVICE $OSD_JOURNAL_DEVICE"

Por exemplo:

ceph-disk prepare --zap /dev/sdb /dev/sdd2

20.4 Mensagem de status “Too Many PGs per OSD”Se você receber uma mensagem Too Many PGs per OSD após executar ceph status , issosignica que o valor mon_pg_warn_max_per_osd (por padrão, 300) foi excedido. Esse valor écomparado ao número proporcional de PGs por OSD. Isso signica que a conguração do clusternão é a ideal.

275 Sistema de arquivos XFS corrompido SES 5

O número de PGs não pode ser reduzido depois que o pool é criado. Os pools que ainda nãocontêm dados podem ser apagados com segurança e, em seguida, recriados com um númeromenor de PGs. Para os pools que já contêm dados, a única solução é adicionar OSDs ao clusterpara que a proporção de PGs por OSD seja reduzida.

20.5 Mensagem de status “nn pg stuck inactive”

Se você receber uma mensagem de status stuck inactive após executar ceph status , issosignica que o Ceph não sabe onde replicar os dados armazenados para atender às regras dereplicação. Isso pode ocorrer logo após a conguração inicial do Ceph e é autocorrigido. Emoutros casos, isso pode exigir uma interação manual, como recuperar um OSD com defeito ouadicionar um novo OSD ao cluster. Em casos muito raros, a redução do nível de replicação podeajudar.

Se os grupos de posicionamento estiverem travados permanentemente, será necessário vericara saída de ceph osd tree . A saída deve ter uma estrutura da árvore, parecida com o exemplona Seção 20.7, “OSD está inativo”.

Se a saída de ceph osd tree for bem simples como no exemplo a seguir

ceph osd treeID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY-1 0 root default 0 0 osd.0 up 1.00000 1.00000 1 0 osd.1 up 1.00000 1.00000 2 0 osd.2 up 1.00000 1.00000

Você deverá vericar se o mapa CRUSH relacionado tem uma estrutura da árvore. Se ele tambémfor simples, ou sem hosts como no exemplo acima, isso poderá signicar que a resolução denome de host não está funcionando corretamente no cluster.

Se a hierarquia estiver incorreta (por exemplo, a raiz contém hosts, mas os OSDs estão no nívelsuperior e não foram atribuídos a hosts), você precisará mover os OSDs para o local correto nahierarquia. Isso pode ser feito usando os comandos ceph osd crush move e/ou ceph osdcrush set . Para obter mais detalhes, consulte a Seção 6.4, “Manipulação de mapa CRUSH”.

276 Mensagem de status “nn pg stuck inactive” SES 5

20.6 Peso do OSD é 0Ao ser iniciado, um peso é atribuído ao OSD. Quanto maior o peso, maior a chance de o clustergravar dados no OSD. O peso é especicado em um Mapa CRUSH do cluster ou calculado peloscript de inicialização dos OSDs.

Em alguns casos, o valor calculado do peso dos OSDs pode ser arredondado para zero. Issosignica que o OSD não está programado para armazenar dados, e não há dados gravados nele. Omotivo mais comum é que o disco é muito pequeno (menor do que 15 GB) e deve ser substituídopor um maior.

20.7 OSD está inativoO daemon OSD está em execução ou parado/inativo. Há 3 motivos gerais para um OSD inativo:

Falha no disco rígido.

Falha no OSD.

Falha no servidor.

Você pode ver o status detalhado dos OSDs executando

ceph osd tree# id weight type name up/down reweight -1 0.02998 root default -2 0.009995 host doc-ceph1 0 0.009995 osd.0 up 1 -3 0.009995 host doc-ceph2 1 0.009995 osd.1 up 1 -4 0.009995 host doc-ceph3 2 0.009995 osd.2 down 1

A listagem de exemplo mostra que o osd.2 está inativo. Em seguida, você pode vericar se odisco onde está o OSD foi montado:

lsblk -f [...] vdb ├─vdb1 /var/lib/ceph/osd/ceph-2 └─vdb2

277 Peso do OSD é 0 SES 5

Você pode monitorar o motivo pelo qual o OSD está inativo inspecionando o arquivo de registro/var/log/ceph/ceph-osd.2.log . Após localizar e corrigir o problema que impossibilita aexecução do OSD, inicie-o com

sudo systemctl start ceph-osd@2.service

Lembre-se de substituir 2 pelo número real do seu OSD parado.

20.8 Descobrindo OSDs lentos

Ao ajustar o desempenho do cluster, é muito importante identicar armazenamento/OSDs lentosno cluster. O motivo é que, se os dados forem gravados no disco (mais) lento, toda a operaçãode gravação cará lenta, pois ela sempre espera sua conclusão em todos os discos relacionados.

Não é simples localizar o gargalo no armazenamento. Será preciso examinar cada OSD paradescobrir os que estão atrasando o processo de gravação. Para fazer um benchmark em um únicoOSD, execute:

ceph tell osd.OSD_ID_NUMBER bench

Por exemplo:

root # ceph tell osd.0 bench { "bytes_written": 1073741824, "blocksize": 4194304, "bytes_per_sec": "19377779.000000"}

Em seguida, você precisa executar esse comando em cada OSD e comparar o valor debytes_per_sec para descobrir os OSDs (mais) lentos.

20.9 Corrigindo avisos de diferença do relógio

As informações de horário em todos os nós do cluster devem estar sincronizadas. Se o horário deum nó não estiver totalmente sincronizado, você poderá receber avisos de diferença do relógioao vericar o estado do cluster.

278 Descobrindo OSDs lentos SES 5

A sincronização de horário é gerenciada com o NTP (consulte http://en.wikipedia.org/wiki/

Network_Time_Protocol ). Dena cada nó para sincronizar o horário com um ou mais servidoresNTP, de preferência com o mesmo grupo de servidores NTP. Se a diferença de horário aindaocorrer em um nó, siga estas etapas para corrigi-la:

systemctl stop ntpd.servicesystemctl stop ceph-mon.targetsystemctl start ntpd.servicesystemctl start ceph-mon.target

Você pode consultar os peers NTP e vericar a diferença de horário com sudo ntpq -p .

Os relógios dos Ceph Monitors precisam estar sincronizados com no máximo 0,05 segundo entreeles. Consulte a Seção 18.3, “Sincronização de horário dos nós” para obter mais informações.

20.10 Cluster de baixo desempenho causado porproblemas de rede

Há outros motivos que podem prejudicar o desempenho do cluster. Um deles pode ser problemasde rede. Nesse caso, você pode observar que o cluster está atingindo o quorum, o OSD e osnós do monitor estão oine, a transferência de dados está levando muito tempo ou há muitastentativas de reconexão.

Para vericar se o desempenho do cluster está prejudicado por problemas de rede, consulte osarquivos de registro do Ceph no diretório /var/log/ceph .

Para corrigir problemas de rede no cluster, observe atentamente os seguintes pontos:

Diagnóstico básico da rede. Tente o executor das ferramentas de diagnóstico do DeepSeanet.ping para efetuar ping entre os nós do cluster para ver se uma interface pode acessaroutra especíca e o tempo médio de resposta. Qualquer tempo de resposta especíco muitomais lento do que a média também será relatado. Por exemplo:

root@master # salt-run net.ping Succeeded: 8 addresses from 7 minions average rtt 0.15 ms

Tente validar toda a interface com a habilitação de JumboFrame:

root@master # salt-run net.jumbo_ping

279 Cluster de baixo desempenho causado por problemas de rede SES 5

Succeeded: 8 addresses from 7 minions average rtt 0.26 ms

Benchmark de desempenho de rede. Tente o executor de desempenho de rede do DeepSeanet.iperf para testar a largura de banda de rede do nó interno. Em determinado nódo cluster, um número de processos iperf (conforme o número de núcleos de CPU) sãoiniciados como servidores. Os nós restantes do cluster serão usados como clientes paragerar tráfego de rede. A largura de banda acumulada de todos os processos iperf por nóserá relatada. Isso deve reetir o throughput máximo de rede atingível em todos os nósdo cluster. Por exemplo:

root@master # salt-run net.iperf cluster=ceph output=full192.168.128.1: 8644.0 Mbits/sec192.168.128.2: 10360.0 Mbits/sec192.168.128.3: 9336.0 Mbits/sec192.168.128.4: 9588.56 Mbits/sec192.168.128.5: 10187.0 Mbits/sec192.168.128.6: 10465.0 Mbits/sec

Verique as congurações de rewall nos nós do cluster. Certique-se de que elas nãobloqueiem as portas/protocolos necessários à operação do Ceph. Consulte a Seção 18.9,

“Configurações de firewall para o Ceph” para obter mais informações sobre as conguraçõesde rewall.

Verique se o hardware de rede, como placas de rede, cabos ou switches, está funcionandoapropriadamente.

Dica: Rede separadaPara garantir uma comunicação de rede rápida e segura entre os nós do cluster, congureuma rede separada usada exclusivamente pelos nós OSD e de monitor do cluster.

280 Cluster de baixo desempenho causado por problemas de rede SES 5

20.11 Pouco espaço em /varPor padrão, o master Salt grava o retorno de cada minion para cada tarefa no cache de tarefas. Emseguida, o cache pode ser usado para pesquisa de resultados em tarefas anteriores. O diretóriode cache padrão é /var/cache/salt/master/jobs/ .

Cada retorno de tarefa de cada minion é gravado em um único arquivo. Ao longo do tempo, essediretório pode car muito grande, dependendo do número de tarefas publicadas e do valor daopção keep_jobs no arquivo /etc/salt/master . keep_jobs dene o número de horas (24,por padrão) para manter as informações sobre as tarefas anteriores dos minions.

keep_jobs: 24

Importante: Não definir keep_jobs: 0Denir keep_jobs como “0” faz com que a limpeza do cache de tarefas nunca sejaexecutada, o que pode resultar em uma partição cheia.

Para desabilitar o cache de tarefas, dena job_cache como “Falso”:

job_cache: False

Dica: Restaurando a partição cheia devido ao cache de tarefasQuando a partição com arquivos de cache de tarefas car cheia por causa da conguraçãoincorreta de keep_jobs , siga estas etapas para liberar espaço no disco e melhorar ascongurações do cache de tarefas:

1. Pare o serviço master Salt:

root@master # systemctl stop salt-master

2. Mude a conguração do master Salt relacionada ao cache de tarefas editando /etc/salt/master :

job_cache: Falsekeep_jobs: 1

3. Limpe o cache de tarefas do master Salt:

rm -rfv /var/cache/salt/master/jobs/*

281 Pouco espaço em /var SES 5

4. Inicie o serviço master Salt:

root@master # systemctl start salt-master

282 Pouco espaço em /var SES 5

Glossário

Geral

Compartimento de memóriaUm ponto que agrega outros nós em uma hierarquia de locais físicos.

Conjunto de RegrasRegras para determinar o posicionamento de dados em um pool.

CRUSH, Mapa CRUSHUm algoritmo que determina como armazenar e recuperar dados calculando os locais dearmazenamento de dados. O CRUSH requer um mapa de cluster para armazenar e recuperardados de forma pseudo-aleatória nos OSDs com uma distribuição uniforme dos dados pelocluster.

NóQualquer máquina ou servidor único em um cluster do Ceph.

Nó de adminO nó no qual você executa o utilitário ceph-deploy para implantar nós do Ceph e OSD.

Nó do monitor, MONUm nó do cluster que mantém os mapas de estado do cluster, incluindo o mapa do monitorou o mapa OSD.

Nó OSDUm nó do cluster que armazena dados, processa a replicação, a recuperação, opreenchimento e a redistribuição de dados e fornece algumas informações de monitoramentoaos Ceph Monitors examinando outros daemons Ceph OSD.

PoolPartições lógicas para armazenamento de objetos, como imagens de disco.

283 SES 5

Termos específicos do Ceph

Cluster de Armazenamento do CephO conjunto principal de software de armazenamento que armazena os dados do usuário.Esse conjunto consiste em Ceph Monitors e OSDs.

Também conhecido como “Armazenamento de Objetos do Ceph”.

Objeto GatewayO componente de gateway do S3/Swift do Armazenamento de Objetos do Ceph.

284 SES 5

A Exemplo do procedimento de instalação manual doCeph

O procedimento a seguir mostra os comandos necessários para instalar manualmente o clusterde armazenamento do Ceph.

1. Gere os segredos das chaves para os serviços do Ceph que você pretende executar. Épossível usar o seguinte comando para gerá-los:

python -c "import os ; import struct ; import time; import base64 ; \ key = os.urandom(16) ; header = struct.pack('<hiih',1,int(time.time()),0,len(key)) ; \ print base64.b64encode(header + key)"

2. Adicione as chaves aos chaveiros relacionados. Primeiramente para o client.admin ,depois para os monitores e, em seguida, para outros serviços relacionados, como OSD,Object Gateway ou MDS:

ceph-authtool -n client.admin \ --create-keyring /etc/ceph/ceph.client.admin.keyring \ --cap mds 'allow *' --cap mon 'allow *' --cap osd 'allow *'ceph-authtool -n mon. \ --create-keyring /var/lib/ceph/bootstrap-mon/ceph-osceph-03.keyring \ --set-uid=0 --cap mon 'allow *'ceph-authtool -n client.bootstrap-osd \ --create-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring \ --cap mon 'allow profile bootstrap-osd'ceph-authtool -n client.bootstrap-rgw \ --create-keyring /var/lib/ceph/bootstrap-rgw/ceph.keyring \ --cap mon 'allow profile bootstrap-rgw'ceph-authtool -n client.bootstrap-mds \ --create-keyring /var/lib/ceph/bootstrap-mds/ceph.keyring \ --cap mon 'allow profile bootstrap-mds'

3. Crie um monmap, um banco de dados de todos os monitores em um cluster:

monmaptool --create --fsid eaac9695-4265-4ca8-ac2a-f3a479c559b1 \ /tmp/tmpuuhxm3/monmapmonmaptool --add osceph-02 192.168.43.60 /tmp/tmpuuhxm3/monmapmonmaptool --add osceph-03 192.168.43.96 /tmp/tmpuuhxm3/monmapmonmaptool --add osceph-04 192.168.43.80 /tmp/tmpuuhxm3/monmap

285 SES 5

4. Crie um novo chaveiro e importe as chaves dos chaveiros de admin e dos monitores paralá. Em seguida, use-as para iniciar os monitores:

ceph-authtool --create-keyring /tmp/tmpuuhxm3/keyring \ --import-keyring /var/lib/ceph/bootstrap-mon/ceph-osceph-03.keyringceph-authtool /tmp/tmpuuhxm3/keyring \ --import-keyring /etc/ceph/ceph.client.admin.keyringsudo -u ceph ceph-mon --mkfs -i osceph-03 \ --monmap /tmp/tmpuuhxm3/monmap --keyring /tmp/tmpuuhxm3/keyringsystemctl restart ceph-mon@osceph-03

5. Verique o estado dos monitores em systemd :

systemctl show --property ActiveState ceph-mon@osceph-03

6. Verique se o Ceph está em execução e relata o status do monitor:

ceph --cluster=ceph \ --admin-daemon /var/run/ceph/ceph-mon.osceph-03.asok mon_status

7. Verique o status dos serviços especícos usando as chaves existentes:

ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin -f json-pretty status[...]ceph --connect-timeout 5 \ --keyring /var/lib/ceph/bootstrap-mon/ceph-osceph-03.keyring \ --name mon. -f json-pretty status

8. Importe o chaveiro dos serviços existentes do Ceph e verique o status:

ceph auth import -i /var/lib/ceph/bootstrap-osd/ceph.keyringceph auth import -i /var/lib/ceph/bootstrap-rgw/ceph.keyringceph auth import -i /var/lib/ceph/bootstrap-mds/ceph.keyringceph --cluster=ceph \ --admin-daemon /var/run/ceph/ceph-mon.osceph-03.asok mon_statusceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin -f json-pretty status

9. Prepare os discos/partições para os OSDs usando o sistema de arquivos XFS:

ceph-disk -v prepare --fs-type xfs --data-dev --cluster ceph \ --cluster-uuid eaac9695-4265-4ca8-ac2a-f3a479c559b1 /dev/vdbceph-disk -v prepare --fs-type xfs --data-dev --cluster ceph \ --cluster-uuid eaac9695-4265-4ca8-ac2a-f3a479c559b1 /dev/vdc

286 SES 5

[...]

10. Ative as partições:

ceph-disk -v activate --mark-init systemd --mount /dev/vdb1ceph-disk -v activate --mark-init systemd --mount /dev/vdc1

11. No SUSE Enterprise Storage versão 2.1 e versões anteriores, crie os pools padrão:

ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .users.swift 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .intent-log 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .rgw.gc 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .users.uid 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .rgw.control 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .users 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .usage 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .log 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .rgw 16 16

12. Crie a chave de instância do Object Gateway com base na chave do protocolo de boot:

ceph --connect-timeout 5 --cluster ceph --name client.bootstrap-rgw \ --keyring /var/lib/ceph/bootstrap-rgw/ceph.keyring auth get-or-create \ client.rgw.0dc1e13033d2467eace46270f0048b39 osd 'allow rwx' mon 'allow rw' \ -o /var/lib/ceph/radosgw/ceph-rgw.rgw_name/keyring

13. Habilite e inicie o Object Gateway:

systemctl enable ceph-radosgw@rgw.rgw_namesystemctl start ceph-radosgw@rgw.rgw_name

14. Opcionalmente, crie a chave de instância do MDS com base na chave do protocolo de boote, em seguida, habilite-o e inicie-o:

ceph --connect-timeout 5 --cluster ceph --name client.bootstrap-mds \ --keyring /var/lib/ceph/bootstrap-mds/ceph.keyring auth get-or-create \ mds.mds.rgw_name osd 'allow rwx' mds allow mon \

287 SES 5

'allow profile mds' \ -o /var/lib/ceph/mds/ceph-mds.rgw_name/keyringsystemctl enable ceph-mds@mds.rgw_namesystemctl start ceph-mds@mds.rgw_name

288 SES 5

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

O documento foi atualizado nas seguintes datas:

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

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

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

Seção  B.4, “Fevereiro de 2017 (Lançamento do SUSE Enterprise Storage 4, atualização de

manutenção 1)”

Seção B.5, “Dezembro de 2016 (Lançamento do SUSE Enterprise Storage 4)”

Seção B.6, “Junho de 2016 (Lançamento do SUSE Enterprise Storage 3)”

Seção B.7, “Janeiro de 2016 (Lançamento do SUSE Enterprise Storage 2.1)”

Seção B.8, “Outubro de 2015 (Lançamento do SUSE Enterprise Storage 2)”

B.1 Setembro de 2018 (Lançamento do SUSEEnterprise Storage 5.5)

Atualizações gerais

Seção 15.4.3, “Gerenciando dispositivos de blocos RADOS (RBDs)” estendida. Em especial,uma seção adicionada sobre instantâneos (Fate #325642).

Seção 7.3, “Migração de pool” adicionada (Fate#322006).

Seção 3.2, “Reiniciando serviços do Ceph usando DeepSea” inserida no Capítulo 3, Operando

serviços do Ceph.

289 Setembro de 2018 (Lançamento do SUSE Enterprise Storage 5.5) SES 5

Correções de bug

Incluída a parte state.apply no salt na Seção  1.7, “Recuperando um nó OSD

reinstalado” https://bugzilla.suse.com/show_bug.cgi?id=1095937 ).

Adicionada a Seção  15.1.1, “Habilitando acesso seguro ao openATTIC por SSL” https://

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

Adicionada a Seção  11.12, “Equilibrando a carga dos servidores Object Gateway com

HAProxy” https://bugzilla.suse.com/show_bug.cgi?id=1093513 ).

Informações atualizadas sobre como personalizar o ceph.conf na Seção  6.6,

“SSDs e HDDs combinadas no mesmo nó” (https://bugzilla.suse.com/show_bug.cgi?

id=1093583 ).

Adicionada a Seção  6.5, “Depuração” https://bugzilla.suse.com/show_bug.cgi?

id=1079256 ).

A lista de portas foi aprimorada para a conguração de Firewall na Seção  18.9,

“Configurações de firewall para o Ceph” https://bugzilla.suse.com/show_bug.cgi?

id=1070087 ).

Reinicialização de funções diferenciada, de acordo com a versão do DeepSea naSeção  3.2.2, “Reiniciando serviços específicos” (https://bugzilla.suse.com/show_bug.cgi?

id=1091075 ).

Adicionada a Seção  1.4, “Reimplantando nós do monitor” https://bugzilla.suse.com/

show_bug.cgi?id=1038731 ).

Adicionada a Seção  11.9.1.1, “Refragmentação dinâmica” https://bugzilla.suse.com/

show_bug.cgi?id=1076001 ).

Adicionada a Seção 11.9, “Fragmentação de índice do compartimento de memória” https://

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

SSL do Object Gateway atualizado de acordo com o DeepSea na Seção  11.6,

“Habilitando HTTPS/SSL para Object Gateways” (https://bugzilla.suse.com/show_bug.cgi?

id=1083756 e https://bugzilla.suse.com/show_bug.cgi?id=1077809 ).

As mudanças no DeepSea exigem uma implantação modicada do NFS Ganeshacom o Object Gateway. Consulte a Seção 14.3.1, “Usuários diferentes do Object Gateway

para NFS Ganesha” (https://bugzilla.suse.com/show_bug.cgi?id=1058821 ). Falha em

290 Setembro de 2018 (Lançamento do SUSE Enterprise Storage 5.5) SES 5

ceph osd pool create se o limite de grupos de posicionamento por OSDfor excedido. Consulte a Seção  7.2.2, “Criar um pool”. (https://bugzilla.suse.com/

show_bug.cgi?id=1076509 )

Adicionada a Seção 1.7, “Recuperando um nó OSD reinstalado” (https://bugzilla.suse.com/

show_bug.cgi?id=1057764 ).

Um aviso de conabilidade foi adicionado à Seção 1.12, “Configuração de tempo de

execução do Ceph” (https://bugzilla.suse.com/show_bug.cgi?id=989349 ).

Adicionada a Seção  11.2, “Implantando o Object Gateway” (https://bugzilla.suse.com/

show_bug.cgi?id=1088895 ).

lz4 removido da lista de algoritmos de compactação na Seção 7.5.3, “Opções globais

de compactação” (https://bugzilla.suse.com/show_bug.cgi?id=1088450 ).

Dica adicionada sobre como remover vários OSDs na Seção 1.6, “Removendo um OSD”

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

Adicionada a Seção 18.2, “Parando os OSDs sem redistribuição” (https://bugzilla.suse.com/

show_bug.cgi?id=1051039 ).

Conguráveis de tamanho do cache do MDS adicionados ao Livro “Guia de

Implantação”, Capítulo 11 “Instalação do CephFS”, Seção 11.2.2 “Configurando um servidor

de metadados” (https://bugzilla.suse.com/show_bug.cgi?id=1062692 ).

Adicionada a Seção 11.10, “Integrando o OpenStack Keystone” (https://bugzilla.suse.com/

show_bug.cgi?id=1077941 ).

Dica adicionada sobre a sincronização de conguração do iSCSI Gateway no Livro

“Guia de Implantação”, Capítulo 10 “Instalação do iSCSI Gateway”, Seção 10.4.3 “Exportar

imagens RBD por meio do iSCSI” (https://bugzilla.suse.com/show_bug.cgi?id=1073327 ).

As mudanças no DeepSea exigem uma implantação modicada do NFS Ganesha como Object Gateway. Consulte a Seção 14.3.1, “Usuários diferentes do Object Gateway para

NFS Ganesha” (https://bugzilla.suse.com/show_bug.cgi?id=1058821 ).

291 Setembro de 2018 (Lançamento do SUSE Enterprise Storage 5.5) SES 5

B.2 Novembro de 2017 (atualização de manutençãoda documentação)

Atualizações gerais

Seção 18.11, “Substituindo o disco de armazenamento” adicionada (Fate#321032).

Correções de bug

Adicionada a Seção 9.4, “Pools com codificação de eliminação com dispositivo de blocos

RADOS” (https://bugzilla.suse.com/show_bug.cgi?id=1075158 ).

Seção incluída sobre como adicionar um disco aos nós OSD. Consulte a Seção 1.5,

“Adicionar um OSD a um nó”. (https://bugzilla.suse.com/show_bug.cgi?id=1066005 )

salt-run remove.osd requer o dígito OSD_ID sem osd. à esquerda. ConsulteSeção 1.6, “Removendo um OSD”.

ceph tell requer o dígito OSD_ID e osd. à esquerda. Consulte Seção  20.8,

“Descobrindo OSDs lentos”.

Adicionada a Seção  20.11, “Pouco espaço em /var” (https://bugzilla.suse.com/

show_bug.cgi?id=1069255 ).

Adicionada a Seção 11.1, “Restrições e limitações de nomeação do Object Gateway” (https://

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

Comandos rbd-mirror de inicialização e interrupção corrigidos na Seção  8.5.1,

“Daemon rbd-mirror” (https://bugzilla.suse.com/show_bug.cgi?id=1068061 ).

B.3 Outubro de 2017 (Lançamento do SUSEEnterprise Storage 5)

Atualizações gerais

Calamari substituído pelo openATTIC.

Seção 15.4.6, “Gerenciando o NFS Ganesha” adicionada (Fate#321620).

Adicionada a Seção 8.4, “rbdmap: Mapear dispositivos RBD no momento da inicialização”

292 Novembro de 2017 (atualização de manutenção da documentação) SES 5

Capítulo 8, Dispositivo de Blocos RADOS adicionada (Fate#321061).

Seção  15.4.9, “Gerenciando usuários e compartimentos de memória do Object Gateway”

adicionada (Fate#320318).

Seção 11.8, “Autenticação LDAP” adicionada (Fate#321631).

Seção 13.4, “Vários daemons MDS ativos (MDS ativo-ativo)” adicionada (Fate#322976).

Seção 15.4.7, “Gerenciando iSCSI Gateways” adicionada (Fate#321370).

Conguração adicionada do iSCSI Gateway e do Object Gateway para openATTIC.Consulte a Seção  15.1.5, “Gerenciamento do Object Gateway” e a Seção  15.1.6,

“Gerenciamento do iSCSI Gateway” (Fate #320318 e #321370).

Atualizado o Capítulo  14, NFS Ganesha: Exportar dados do Ceph pelo

NFS (https://bugzilla.suse.com/show_bug.cgi?id=1036495 , https://bugzilla.suse.com/

show_bug.cgi?id=1031444 ).

Agora as imagens RBD podem ser armazenadas em EC. Consulte a Seção 8.1.2, “Criando

a imagem de um dispositivo de blocos em um pool com codificação de eliminação” (https://

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

Seção adicionada sobre como fazer backup da conguração do DeepSea. Consulteo Livro “Guia de Implantação”, Capítulo 6 “Fazendo backup da configuração do cluster”

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

Failover e recuperação de desastre do Object Gateway. Consulte aSeção  11.11.12, “Failover e recuperação de desastre” (https://bugzilla.suse.com/

show_bug.cgi?id=1036084 ).

BlueStore habilita a compactação de dados para pools. Consulte a Seção  7.5,

“Compactação de dados” (FATE #318582).

Exportação CIFS do CephFS é possível. Consulte o Livro “Guia de Implantação”, Capítulo

13 “Exportar o CephFS via Samba” (FATE #321622).

Procedimento adicionado de reinicialização do cluster. Consulte a Seção 1.10, “Parando

ou reinicializando o cluster” (https://bugzilla.suse.com/show_bug.cgi?id=1047638 ).

É possível atualizar a fase 0 do DeepSea sem reinicialização. Consulte a Seção 1.9,

“Atualizando os nós do cluster”.

293 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) SES 5

ceph fs substituído. Consulte a Seção 13.4.3, “Diminuindo o número de classificações” ea Seção 13.4.2, “Aumentando o tamanho do cluster MDS ativo” (https://bugzilla.suse.com/

show_bug.cgi?id=1047638 ).

Seção 18.10, “Testando o desempenho da rede” adicionada (FATE#321031).

Correções de bug

Saída de comando atualizada para reetir as classes de armazenamento na Seção 6.6,

“SSDs e HDDs combinadas no mesmo nó” (https://bugzilla.suse.com/show_bug.cgi?

id=1061299 ).

Agora, o pacote do cliente swift faz parte do módulo “Public Cloud” (Nuvem Pública)na Seção 11.5.1, “Acessando o Object Gateway” (https://bugzilla.suse.com/show_bug.cgi?

id=1057591 ).

Adicionada a Seção  1.12, “Configuração de tempo de execução do Ceph” (https://

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

Comando modicado para uma opção de conguração na Seção 6.6, “SSDs e HDDs

combinadas no mesmo nó” (https://bugzilla.suse.com/show_bug.cgi?id=1059561 ).

Comando ceph osd pool set atualizado para corresponder à sintaxe do Luminousna Seção  6.6, “SSDs e HDDs combinadas no mesmo nó” (https://bugzilla.suse.com/

show_bug.cgi?id=1059593 ).

CivetWeb é vinculado a várias portas na Dica: Vinculando a várias portas (https://

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

Três opções do Object Gateway que afetam o desempenho incluídas na Seção 11.4,

“Parâmetros de configuração” (https://bugzilla.suse.com/show_bug.cgi?id=1052983 ).

Seção 1.11, “Arquivo ceph.conf personalizado” importada e incluída a necessidade daFase 3 (https://bugzilla.suse.com/show_bug.cgi?id=1057273 ).

Criação do chaveiro libvirt adicionada à Seção 16.1, “Configurando o Ceph” (https://

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

Adicionado o Exemplo  1.1, “Removendo um minion Salt do cluster” (https://

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

Seção 4.2, “Observando um cluster” atualizada (https://bugzilla.suse.com/show_bug.cgi?

id=1053638 ).

294 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) SES 5

As variáveis da API REST do Salt agora são opcionais na Seção 15.1, “Implantação

e configuração do openATTIC” (https://bugzilla.suse.com/show_bug.cgi?id=1054748 ehttps://bugzilla.suse.com/show_bug.cgi?id=1054749 ).

oaconfig install removido da Seção  15.1.3, “Configuração inicial do openATTIC”

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

Seção adicionada sobre a exibição de metadados de um pool na Seção 7.1, “Associar

pools a um aplicativo” (https://bugzilla.suse.com/show_bug.cgi?id=1053327 ).

Uma lista de códigos de saúde foi importada na Seção 4.1, “Verificando a saúde do cluster”

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

Capturas de tela e texto relacionado atualizados na Seção  15.4.9.1, “Adicionando

um novo usuário do Object Gateway” e na Seção  15.4.9.3, “Editando usuários do

Object Gateway” (https://bugzilla.suse.com/show_bug.cgi?id=1051814 e (https://

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

Compartimentos de memória do Object Gateway adicionados à Seção  15.4.9,

“Gerenciando usuários e compartimentos de memória do Object Gateway” (https://

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

Cephx incluído nos exemplos de montagem na Seção 13.1.3, “Montar o CephFS” (https://

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

Descrição da exclusão de pool atualizada e aprimorada na Seção 7.2.4, “Apagar um pool”

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

Descrição dos algoritmos de compactação adicionada à Seção  7.5.2, “Opções de

compactação de pool” (https://bugzilla.suse.com/show_bug.cgi?id=1051457 ).

Diagnóstico e benchmark de rede substituídos na Seção  20.10, “Cluster de baixo

desempenho causado por problemas de rede” (https://bugzilla.suse.com/show_bug.cgi?

id=1050190 ).

Seção  20.5, “Mensagem de status “nn pg stuck inactive”” estendida (https://

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

Recriação de pool mencionada na Seção 20.4, “Mensagem de status “Too Many PGs per

OSD”” (https://bugzilla.suse.com/show_bug.cgi?id=1050178 ).

295 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) SES 5

Nome da seção RGW corrigido no ceph.conf no Livro “Guia de Implantação”, Capítulo

9 “Ceph Object Gateway”, Seção 9.1 “Instalação manual do Object Gateway” (https://

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

Saída de comandos atualizada na Seção  4.3, “Verificando as estatísticas de uso do

cluster” e na Seção 4.2, “Observando um cluster” (https://bugzilla.suse.com/show_bug.cgi?

id=1050175 ).

Seção HEALTCH_WARN preventiva removida da Seção  4.1, “Verificando a saúde do

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

Sudo corrigido na Seção  11.5.2.1, “Adicionando usuários do S3 e do Swift” (https://

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

Referência removida a um distribuidor RADOS na Seção  20.2, “Falha ao enviar

objetos grandes pelo rados com OSD completo” (https://bugzilla.suse.com/show_bug.cgi?

id=1050171 ).

Seção aprimorada sobre falha no OSD devido à falha no diário na Seção  19.5,

“O que acontece quando há falha em um disco de diário?” (https://bugzilla.suse.com/

show_bug.cgi?id=1050169 ).

Dica adicionada sobre zypper patch durante a Fase 0 na Seção 1.9, “Atualizando os

nós do cluster” (https://bugzilla.suse.com/show_bug.cgi?id=1050165 ).

Adicionada a Seção  7.1, “Associar pools a um aplicativo” (https://bugzilla.suse.com/

show_bug.cgi?id=1049940 ).

Informações de sincronização de horário aprimoradas na Seção 20.9, “Corrigindo avisos

de diferença do relógio” (https://bugzilla.suse.com/show_bug.cgi?id=1050186 ).

“Pool de eliminação” substituído pelo “pool com codicação de eliminação” correto(https://bugzilla.suse.com/show_bug.cgi?id=1050093 ).

rcceph substituído por systemctl (https://bugzilla.suse.com/show_bug.cgi?

id=1050111 ).

Preparação de montagem do CephFS atualizada na Seção 13.1.1, “Preparação do cliente”

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

Comando qemu-img corrigido na Seção  16.1, “Configurando o Ceph” (https://

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

296 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) SES 5

Especicação de quais fases do DeepSea devem ser executadas ao remover funçõesna Seção  1.3, “Removendo e reinstalando nós do cluster” (https://bugzilla.suse.com/

show_bug.cgi?id=1047430 ).

Uma nova função do DeepSea foi adicionada: Ceph Manager (https://

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

Introdução ajustada para 12 SP3 na Seção  13.1.1, “Preparação do cliente” (https://

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

Erro de ortograa corrigido na entidade XML na Seção  16.4, “Configurando a VM”

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

Informações adicionadas para executar novamente as Fases de 2 a 5 do DeepSea pararemoção de uma função à Seção 1.3, “Removendo e reinstalando nós do cluster” (https://

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

Foram adicionados os números das portas do Object Gateway, iSCSI Gateway e NFSGanesha que precisam estar abertas no SUSE Firewall à Seção 18.9, “Configurações de

firewall para o Ceph” (https://bugzilla.suse.com/show_bug.cgi?id=1034081 ).

Descrição adicionada da iteração de árvore do mapa CRUSH. Consulte a Seção 6.3.1,

“Iteração pela árvore de nós”.

Parâmetro indep adicionado à regra CRUSH. Consulte a Seção 6.3.2, “firstn e indep”.(https://bugzilla.suse.com/show_bug.cgi?id=1025189 )

A montagem do CephFS por meio de /etc/fstab requer o parâmetro_netdev . Consulte a Seção 13.3, “CephFS no /etc/fstab” (https://bugzilla.suse.com/

show_bug.cgi?id=989349 )

Dica adicionada sobre um arquivo de serviço rbdmap systemd existentena Seção  8.2, “Montando e desmontando imagens RBD” (https://bugzilla.suse.com/

show_bug.cgi?id=1015748 ).

Explicação adicionada à opção use_gmt_hitset na Seção 10.6.1.4, “Usar GMT para

conjunto de acertos” (https://bugzilla.suse.com/show_bug.cgi?id=1024522 ).

Montagem do CephFS reincluída no Guia de Administração e seção de preparaçãode cliente adicionada à Seção 13.1.1, “Preparação do cliente” (https://bugzilla.suse.com/

show_bug.cgi?id=1025447 ).

297 Outubro de 2017 (Lançamento do SUSE Enterprise Storage 5) SES 5

B.4 Fevereiro de 2017 (Lançamento do SUSEEnterprise Storage 4, atualização de manutenção 1)

Atualizações gerais

Adicionado o Capítulo 14, NFS Ganesha: Exportar dados do Ceph pelo NFS.

Correções de bug

Link adicionado aos Tunables CRUSH no Livro “Guia de Implantação”, Capítulo

5 “Fazendo upgrade de versões anteriores”, Seção 5.4 “Upgrade do SUSE Enterprise

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

id=1024718 ).

Vericar se os serviços systemd estão habilitados e foram iniciados no Livro “Guia

de Implantação”, Capítulo 4 “Implantando com o DeepSea/Salt”, Seção 4.3 “Implantação do

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

Usuários informados sobre a necessidade de acesso de leitura ao diretório raizdo MDS na Seção  13.1.3, “Montar o CephFS” (https://bugzilla.suse.com/show_bug.cgi?

id=1014051 ).

Referência de upgrade do iSCSI Gateway transferida para o Livro “Guia de Implantação”,

Capítulo 5 “Fazendo upgrade de versões anteriores”, Seção 5.2 “Procedimento geral de

upgrade” (https://bugzilla.suse.com/show_bug.cgi?id=1014194 ).

Nó de admin adicionado ao workow de upgrade no Livro “Guia de Implantação”,

Capítulo 5 “Fazendo upgrade de versões anteriores”, Seção 5.2 “Procedimento geral de

upgrade” (https://bugzilla.suse.com/show_bug.cgi?id=1012155 ).

Capítulo 3, Operando serviços do Ceph reescrito para evitar serviços de globbing (https://

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

O apêndice que descreve os arquivos sls do Salt foram apagados (https://

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

Seção 20.3, “Sistema de arquivos XFS corrompido” adicionada sobre sistema de arquivosXFS corrompido (https://bugzilla.suse.com/show_bug.cgi?id=1012551 ).

298

Fevereiro de 2017 (Lançamento do SUSE Enterprise Storage 4, atualização de manutenção

1) SES 5

Seção 18.3, “Sincronização de horário dos nós” adicionada sobre sincronização de horário(https://bugzilla.suse.com/show_bug.cgi?id=1009653 ).

Livro “Guia de Implantação”, Capítulo 4 “Implantando com o DeepSea/Salt”, Seção 4.3

“Implantação do cluster” atualizado com informações de que os discos devem ser limpos(zap) (https://bugzilla.suse.com/show_bug.cgi?id=1014039 ).

B.5 Dezembro de 2016 (Lançamento do SUSEEnterprise Storage 4)

Atualizações gerais

Reformulado todo o documento que apresenta os elementos do DocBook aos capítulosrelacionados ao grupo.

Capítulo 15, openATTIC incluído (Fate #321085).

Livro “Guia de Implantação”, Capítulo 5 “Fazendo upgrade de versões anteriores”

Substituído o procedimento de upgrade antigo pelo Livro “Guia de Implantação”,

Capítulo 5 “Fazendo upgrade de versões anteriores”, Seção 5.4 “Upgrade do SUSE Enterprise

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

Correções de bug

Requisito de memória maior para um OSD no Livro “Guia de Implantação”, Capítulo

2 “Requisitos e recomendações de hardware”, Seção 2.1.1 “Requisitos mínimos” (https://

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

Livro “Guia de Implantação”, Capítulo 4 “Implantando com o DeepSea/Salt” aprimorado(https://bugzilla.suse.com/show_bug.cgi?id=993499 ).

Seção  20.9, “Corrigindo avisos de diferença do relógio” aprimorada (https://

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

Livro “Guia de Implantação”, Capítulo 11 “Instalação do CephFS”, Seção 11.2.1 “Adicionando

um servidor de metadados” aprimorado (https://bugzilla.suse.com/show_bug.cgi?

id=992769 ).

299 Dezembro de 2016 (Lançamento do SUSE Enterprise Storage 4) SES 5

B.6 Junho de 2016 (Lançamento do SUSE EnterpriseStorage 3)

Atualizações gerais

Adicionado o Apêndice A, Exemplo do procedimento de instalação manual do Ceph.

Adicionado o Capítulo 5, Autenticação com cephx.

Seção 11.11, “Object Gateways multissite” adicionada (Fate#320602).

Adicionado o Livro “Guia de Implantação”, Capítulo 4 “Implantando com o DeepSea/Salt”.

Capítulo 13, Sistema de arquivos em cluster adicionado (Fate#318586).

Capítulo 12, Ceph iSCSI Gateway

Adicionado o Livro “Guia de Implantação”, Capítulo 10 “Instalação do iSCSI Gateway”, Seção

10.4.4 “Configurações opcionais”.

Adicionada a Seção 12.1.1.1, “Configuração de múltiplos caminhos”.

Correções de bug

O procedimento para congurar o armazenamento a quente e o armazenamento afrio foi aprimorado na Seção 10.6, “Configurando um armazenamento em camadas de

exemplo” e a Seção 10.6.1, “Configurando uma camada de cache” foi adicionada. (https://

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

Comando adicionado para instalar o Ceph no servidor MDS no Livro “Guia de

Implantação”, Capítulo 11 “Instalação do CephFS”, Seção 11.2.1 “Adicionando um servidor de

metadados” (https://bugzilla.suse.com/show_bug.cgi?id=993820 ).

O formato 1 não é mais o padrão (substituído pelo formato 2) para criação de volumesRBD no Livro “Guia de Implantação”, Capítulo 10 “Instalação do iSCSI Gateway”, Seção 10.4

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

Nota adicionada sobre como aumentar o número de conjuntos de regras à Seção 6.3,

“Conjuntos de regras” (https://bugzilla.suse.com/show_bug.cgi?id=997051 ).

Especicação de quais clientes podem migrar para os tunables ideais (https://

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

300 Junho de 2016 (Lançamento do SUSE Enterprise Storage 3) SES 5

Livro “Guia de Implantação”, Capítulo 10 “Instalação do iSCSI Gateway”, Seção 10.4.4

“Configurações opcionais” dividido no Livro “Guia de Implantação”, Capítulo 10 “Instalação

do iSCSI Gateway”, Seção 10.4.5 “Configurações avançadas” e descrição de opções deconguração adicionada (https://bugzilla.suse.com/show_bug.cgi?id=986037 ).

Adicionada a Seção  6.6, “SSDs e HDDs combinadas no mesmo nó” (https://

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

Recomendações mínimas atualizadas no Livro “Guia de Implantação”, Capítulo 2

“Requisitos e recomendações de hardware”, Seção 2.1.1 “Requisitos mínimos” (https://

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

Informações de suporte corrigidas sobre a clonagem de instantâneo na Seção 8.3.3,

“Camadas” (https://bugzilla.suse.com/show_bug.cgi?id=982713 ).

Explicação aprimorada de “compartimento de memória” na Seção  6.2,

“Compartimentos de memória” (https://bugzilla.suse.com/show_bug.cgi?id=985047 ).

Frase esclarecida sobre não misturar a carga de trabalho no Livro “Guia de Implantação”,

Capítulo 2 “Requisitos e recomendações de hardware”, Seção 2.2 “Nós do monitor” (https://

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

Requisito de RAM atualizado para OSDs no Livro “Guia de Implantação”, Capítulo

2 “Requisitos e recomendações de hardware”, Seção 2.1.1 “Requisitos mínimos” (https://

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

Valor padrão hit_set_count corrigido na Seção 7.2.7, “Definir os valores do pool” enota adicionada com link externo à Seção 10.6, “Configurando um armazenamento em

camadas de exemplo” (https://bugzilla.suse.com/show_bug.cgi?id=982284 ).

Vários locais atualizados de acordo com a versão atual do Ceph na Seção  6.4.2,

“Adicionar/Mover um OSD”, na Seção  6.3, “Conjuntos de regras” e na Seção  6.2,

“Compartimentos de memória” (https://bugzilla.suse.com/show_bug.cgi?id=982563 ).

Na Seção  7.2.7, “Definir os valores do pool”, explicação adicionadados seguintes parâmetros de poll: hashpspool , expected_num_objects ,cache_target_dirty_high_ratio , hit_set_grade_decay_rate ,hit_set_grade_search_last_n , fast_read , scrub_min_interval ,scrub_max_interval , deep_scrub_interval , nodelete , nopgchange ,nosizechange , noscrub , nodeep-scrub . (https://bugzilla.suse.com/show_bug.cgi?

id=982512 ).

301 Junho de 2016 (Lançamento do SUSE Enterprise Storage 3) SES 5

Adicionada a Seção 18.7, “Como usar partições existentes para OSDs incluindo diários OSD”

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

Recomendações de RAID removidas sobre posicionamento de discos OSD doLivro “Guia de Implantação”, Capítulo 2 “Requisitos e recomendações de hardware”, Seção

2.1.1 “Requisitos mínimos” e da Seção  6.1, “Dispositivos” (https://bugzilla.suse.com/

show_bug.cgi?id=981611 ).

Conjunto padrão atualizado de compartimentos de memória do mapa CRUSHna Seção  6.2, “Compartimentos de memória” (https://bugzilla.suse.com/show_bug.cgi?

id=981756 ).

Pools de “dados” e “metadados” removidos, não mais o padrão (https://

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

Nomes de produtos de terceiros com marca registrada corrigidos e substituídos pelasentidades no Capítulo 12, Ceph iSCSI Gateway (https://bugzilla.suse.com/show_bug.cgi?

id=983018 ).

Nome do serviço Object Gateway atualizado para ceph-

radosgw@radosgw.gateway_name nas seções afetadas (https://bugzilla.suse.com/

show_bug.cgi?id=980594 ).

Adicionada a Seção  10.2, “Pontos a serem considerados” (https://bugzilla.suse.com/

show_bug.cgi?id=968290 ).

O valor padrão min_size foi mudado na Seção  6.3, “Conjuntos de regras” (https://

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

A opção master:dns_name_of_salt_master foi corrigida no Livro “Guia de

Implantação”, Capítulo 4 “Implantando com o DeepSea/Salt” (https://bugzilla.suse.com/

show_bug.cgi?id=977187 ).

Prexo rgw. adicionado aos hosts do Object Gateway (https://bugzilla.suse.com/

show_bug.cgi?id=974472 ).

Informações adicionadas sobre PGs travados permanentemente na Seção  20.5,

“Mensagem de status “nn pg stuck inactive”” (https://bugzilla.suse.com/show_bug.cgi?

id=968067 ).

302 Junho de 2016 (Lançamento do SUSE Enterprise Storage 3) SES 5

B.7 Janeiro de 2016 (Lançamento do SUSE EnterpriseStorage 2.1)Atualizações gerais

Btrfs removido, pois não é suportado desde o SUSE Enterprise Storage 2.

Seção  9.3, “Pool com codificação de eliminação e camada de cache” transferida doCapítulo 10, Camadas de cache para o Capítulo 9, Pools com codificação de eliminação paraque as informações fornecidas sigam a ordem correta.

Adicionado o Capítulo 12, Ceph iSCSI Gateway.

Capítulo 2, Introdução

Seção Vericando status do MDS removida do Capítulo  4, Determinando o estado do

cluster porque o MDS ainda não foi abordado.

Capítulo 17, Ceph como back end para instância de KVM QEMU

Adicionada a Seção 17.1, “Instalação”.

Correções de bug

systemctl stop cthulhu.service adicionado ao limpar um cluster obsoleto(https://bugzilla.suse.com/show_bug.cgi?id=967849 ).

Erro de ortograa corrigido (https://bugzilla.suse.com/show_bug.cgi?id=967937 )

Erro de ortograa corrigido na sintaxe do comando ceph-deploy rgw (https://

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

Todo o Capítulo 11, Ceph Object Gateway foi reformulado, Seção 11.3, “Operando o serviço

Object Gateway”, Seção 11.5, “Gerenciando o acesso ao Object Gateway” e Seção 11.5.2.3,

“Mudando o acesso e as chaves secretas do usuário do S3 e do Swift” adicionadas (https://

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

“Monitorando um cluster” renomeado para “Determinando o estado do cluster” noCapítulo  4, Determinando o estado do cluster (https://bugzilla.suse.com/show_bug.cgi?

id=958302 ).

Adicionada a Seção  20.4, “Mensagem de status “Too Many PGs per OSD””. (https://

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

303 Janeiro de 2016 (Lançamento do SUSE Enterprise Storage 2.1) SES 5

Clientes aconselhados a impedir manualmente o Apache de escutar na portapadrão 80 se preferirem um número de porta diferente (https://bugzilla.suse.com/

show_bug.cgi?id=942703 ).

Ocorrências de FastCGI e referências a arquivos removidas do Capítulo 11, Ceph Object

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

Método ceph-deploy de instalação/migração de instâncias do Object Gatewayadicionado (https://bugzilla.suse.com/show_bug.cgi?id=946771 ).

Informações de suporte do Apache corrigidas (https://bugzilla.suse.com/

show_bug.cgi?id=946769 ).

B.8 Outubro de 2015 (Lançamento do SUSEEnterprise Storage 2)

Geral

Adicionado o Livro “Guia de Implantação”, Capítulo 5 “Fazendo upgrade de versões

anteriores”.

Adicionado o Capítulo 16, Usando a libvirt com o Ceph.

Adicionado o Capítulo 17, Ceph como back end para instância de KVM QEMU.

Capítulo 11, Ceph Object Gateway

Comando systemctl radosgw corrigido no Livro “Guia de Implantação”, Capítulo

9 “Ceph Object Gateway”, Seção 9.1.1 “Configuração do Object Gateway” (https://

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

Apache substituído pelo CivetWeb incorporado.

304 Outubro de 2015 (Lançamento do SUSE Enterprise Storage 2) SES 5