-
Guia de Administração
SUSE Enterprise Storage 6
-
Guia de AdministraçãoSUSE Enterprise Storage 6por Tomáš Bažant,
Jana Haláčková, Alexandra Settle, e Sven Seeberg
Data de Publicação: 22/05/2020
SUSE LLC1800 South Novell PlaceProvo, UT 84606USA
https://documentation.suse.com
Copyright © 2020 SUSE LLC
Copyright © 2016, RedHat, Inc. e colaboradores.
O texto e as ilustrações neste documento foram licenciados pela
Creative Commons Attribution-
Share Alike 4.0 International ("CC-BY-SA"). Há uma
explicação da CC-BY-SA disponível em http://
creativecommons.org/licenses/by-sa/4.0/legalcode . De acordo com
a CC-BY-SA, se você distribuir este
documento ou uma adaptação dele, deverá fornecer o URL da versão
original.
Red Hat, Red Hat Enterprise Linux, o logotipo do Shadowman,
JBoss, MetaMatrix, Fedora, o logotipo da
Innity e RHCE são marcas registradas da Red Hat, Inc., com
registro nos Estados Unidos e em outros
países. Linux® é a marca comercial registrada da Linus Torvalds
nos Estados Unidos e em outros países.
Java® é uma marca comercial registrada da Oracle e/ou de suas
aliadas. XFS® é uma marca registrada
da Silicon Graphics International Corp. ou de suas subsidiárias
nos Estados Unidos e/ou em outros países.
Todas as outras marcas registradas são de seus respectivos
proprietários.
Para ver as marcas registradas da SUSE, visite
http://www.suse.com/company/legal/ . Todas as marcas
comerciais de terceiros pertencem a seus respectivos
proprietários. Os símbolos de marca registrada (®,™
https://documentation.suse.comhttp://creativecommons.org/licenses/by-sa/4.0/legalcodehttp://creativecommons.org/licenses/by-sa/4.0/legalcodehttp://www.suse.com/company/legal/
-
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 xviii
I GERENCIAMENTO DE CLUSTER 1
1 Privilégios de usuário e prompts de comando 21.1 Comandos
relacionados ao Salt/DeepSea 2
1.2 Comandos relacionados ao Ceph 2
1.3 Comandos gerais do Linux 3
1.4 Informações adicionais 3
2 Administração do cluster do Salt 42.1 Adicionando novos nós do
cluster 4
2.2 Adicionando novas funções aos nós 6
2.3 Removendo e reinstalando nós do cluster 7
2.4 Reimplantando nós do monitor 10
2.5 Adicionando um disco OSD a um nó 11
2.6 Removendo um OSD 12Removendo vários OSDs 12 • Removendo
todos os OSDs de um
host 13 • Removendo à força os OSDs danificados 13 • Validando
os
metadados OSD da LVM 14
2.7 Substituindo um disco OSD 15
2.8 Recuperando um nó OSD reinstalado 16
2.9 Movendo o nó de admin para um novo servidor 17
2.10 Instalação automatizada pelo Salt 19
iv Guia de Administração
-
2.11 Atualizando os nós do cluster 19Repositórios do software 20
• Propagação em fases do
repositório 20 • zypper patch ou zypper dup 20 •
Reinicializaçõesde nó do cluster 20 • Tempo de espera dos serviços
do
Ceph 21 • Executando a atualização 21
2.12 Parando ou reinicializando o cluster 21
2.13 Ajustando o ceph.conf com configurações personalizadas
23Anulando os padrões 24 • Incluindo arquivos de configuração
25
2.14 Habilitando perfis do AppArmor 26
2.15 Desativando perfis ajustados 27
2.16 Removendo um cluster inteiro do Ceph 27
3 Fazendo backup da configuração e dos dados docluster 29
3.1 Fazendo backup da configuração do Ceph 29
3.2 Fazendo backup da configuração do Salt 29
3.3 Fazendo backup da configuração do DeepSea 29
3.4 Configurações personalizadas de backup 30
II OPERANDO UM CLUSTER 31
4 Introdução 32
5 Operando serviços do Ceph 335.1 Operando serviços relacionados
ao cluster do Ceph por meio do
systemd 33Iniciando, parando e reiniciando serviços usando
destinos 33 • Iniciando,
parando e reiniciando serviços individuais 34 • Identificando
serviços
individuais 34 • Status do serviço 35
5.2 Reiniciando serviços do Ceph usando DeepSea 35Reiniciando
todos os serviços 35 • Reiniciando serviços específicos 36
v Guia de Administração
-
5.3 Encerramento normal de todo o cluster do Ceph 37
6 Determinando o estado do cluster 386.1 Verificando o status do
cluster 38
6.2 Verificando a saúde do cluster 39
6.3 Observando um cluster 48
6.4 Verificando as estatísticas de uso do cluster 50
6.5 Verificando o status do OSD 51
6.6 Verificando se há OSDs cheios 52
6.7 Verificando o status do monitor 53
6.8 Verificando estados de grupo de posicionamento 54
6.9 Usando o soquete de admin 54
6.10 Capacidade de armazenamento 55
6.11 Monitorando OSDs e grupos de posicionamento 57Monitorando
OSDs 58 • Conjuntos de grupos de
posicionamento 59 • Emparelhamento 61 • Monitorando estados
de
grupo de posicionamento 61 • Identificando grupos de
posicionamento com
problemas 67 • Encontrando o local de um objeto 67
6.12 OSD não está em execução 68Um OSD não será iniciado 69 •
Falha em um OSD 69 • Sem espaço livre
no disco 70
7 Monitoramento e alerta 727.1 Variáveis do pillar 72
7.2 Grafana 73
7.3 Prometheus 74
7.4 Alertmanager 74Arquivo de configuração 74 • Alertas
personalizados 87 • Receptor de
detecção de SNMP 89
vi Guia de Administração
-
8 Autenticação com cephx 918.1 Arquitetura de autenticação
91
8.2 Gerenciamento de chaves 94Informações de segundo plano 95 •
Gerenciando
usuários 98 • Gerenciamento de chaveiro 102 • Uso da linha
de
comando 105
9 Gerenciamento de dados armazenados 1069.1 Dispositivos 107
Classes de dispositivo 107
9.2 Compartimentos de memória 115
9.3 Conjuntos de regras 118Iteração pela árvore de nós 120 •
firstn e indep 122
9.4 Grupos de posicionamento 123Como os grupos de posicionamento
são usados? 123 • Determinando
o valor de PG_NUM 125 • Definindo o número de grupos de
posicionamento 126 • Obtendo o número de grupos de
posicionamento 127 • Obtendo as estatísticas de PG de um
cluster 127 • Obtendo as estatísticas de PGs travados 127 •
Obtendo
um mapa de grupo de posicionamento 128 • Obtendo as
estatísticas
dos grupos de posicionamento 128 • Depurando um grupo de
posicionamento 128 • Priorizando o provisionamento e a
recuperação de
grupos de posicionamento 128 • Revertendo objetos perdidos
129
9.5 Manipulação de mapa CRUSH 130Editando um mapa CRUSH 130 •
Adicionar/Mover um
OSD 131 • Diferença entre ceph osd reweight e ceph osdcrush
reweight 132 • Remover um OSD 133 • Adicionandoum compartimento de
memória 133 • Mover um compartimento de
memória 133 • Removendo um compartimento de memória 133
9.6 Depuração 134
vii Guia de Administração
-
10 Módulos do Ceph Manager 13710.1 Balanceador 137
O modo “crush-compat” 138 • Planejando e executando o
balanceamento de
dados 138
10.2 Módulo de telemetria 140
11 Gerenciando pools de armazenamento 14211.1 Associar pools a
um aplicativo 142
11.2 Pools operacionais 143Listando pools 143 • Criando um pool
143 • Definindo cotas do
pool 145 • Apagar um pool 145 • Renomear um pool 146 • Mostrar
as
estatísticas do pool 147 • Obtendo os valores do pool 148 •
Definindo os
valores do pool 149 • Definir o número de réplicas do objeto
152
11.3 Migração de pool 154Migrando usando a camada de cache 154 •
Migrando uma imagem do
dispositivo de bloco RADOS 157
11.4 Instantâneos de pool 158Criando um instantâneo de um pool
158 • Listando instantâneos de um
pool 158 • Removendo um instantâneo de um pool 159
11.5 Compactação de dados 159Habilitar compactação 159 • Opções
de compactação de
pool 160 • Opções globais de compactação 161
12 Dispositivo de blocos RADOS 16312.1 Comandos do dispositivo
de blocos 163
Criando a imagem de um dispositivo de blocos em um pool
replicado 164 • Criando a imagem de um dispositivo de blocos
em
um pool com codificação de eliminação 164 • Listando imagens
de dispositivo de blocos 165 • Recuperando informações da
imagem 165 • Redimensionando a imagem de um dispositivo de
blocos 165 • Removendo a imagem de um dispositivo de blocos
165
viii Guia de Administração
-
12.2 Montando e desmontando 165rbdmap: Mapear dispositivos RBD
no momento da
inicialização 168 • Aumentando o tamanho do dispositivo RBD
169
12.3 Instantâneos 170Notas sobre o Cephx 170 • Aspectos básicos
do
instantâneo 171 • Camadas 173
12.4 Espelhamento 177Daemon rbd-mirror 177 • Configuração do
pool 178 • Configuração da
imagem 179 • Status do espelho 182
12.5 Configurações de cache 183
12.6 Configurações de QdS 184
12.7 Configurações de leitura com ajuda 186
12.8 Recursos avançados 186
12.9 Mapeando o RBD por meio de clientes antigos do kernel
188
13 Pools com codificação de eliminação 19013.1 Pré-requisito
para pools com codificação de eliminação 190
13.2 Criando um pool com codificação de eliminação de exemplo
191
13.3 Perfis de codificação de eliminação 191Criando um novo
perfil de codificação de eliminação 194 • Removendo
um perfil de codificação de eliminação 195 • Exibindo detalhes
do perfil
de codificação de eliminação 196 • Listando perfis de
codificação de
eliminação 196
13.4 Pools com codificação de eliminação com dispositivo de
blocosRADOS 196
14 Camadas de cache 19714.1 Terminologia de armazenamento em
camadas 197
14.2 Pontos a serem considerados 198
14.3 Quando usar as camadas de cache 198
ix Guia de Administração
-
14.4 Modos de cache 199
14.5 Pool com codificação de eliminação e camada de cache
199
14.6 Configurando um armazenamento em camadas de exemplo 200
14.7 Configurando uma camada de cache 202Conjunto de acertos 202
• Tamanho do cache 205 • Data do
cache 206 • Exemplos 207
15 Melhorando o desempenho com o cache LVM 20815.1
Pré-requisitos 208
15.2 Pontos a serem considerados 208
15.3 Preparação 210
15.4 Configurando o cache LVM 210Adicionando o cache LVM 210 •
Removendo o cache LVM 210 • Definindo
o modo de cache LVM 211
15.5 Lidando com falhas 211
15.6 Perguntas frequentes (FAQ) 211
16 Configuração do cluster do Ceph 21316.1 Configuração de tempo
de execução 213
16.2 Ceph OSD e BlueStore 214Dimensionamento automático do cache
214
16.3 Ceph Object Gateway 215Configurações gerais 215 • Front
ends HTTP 225
III ACESSANDO OS DADOS DO CLUSTER 228
17 Ceph Object Gateway 22917.1 Restrições e limitações de
nomeação do Object Gateway 229
Limitações de compartimento de memória 229 • Limitações de
objetos
armazenados 229 • Limitações de cabeçalho HTTP 230
x Guia de Administração
-
17.2 Implantando o Object Gateway 230
17.3 Operando o serviço Object Gateway 230
17.4 Opções de configuração 231
17.5 Gerenciando o acesso ao Object Gateway 231Acessando o
Object Gateway 231 • Gerenciando contas do S3 e do
Swift 234
17.6 Front ends HTTP 238
17.7 Habilitando HTTPS/SSL para Object Gateways 238Criar um
certificado autoassinado 238 • Configuração de HTTPS
simples 239 • Configuração de HTTPS avançada 240
17.8 Módulos de sincronização 240Configuração geral 241 •
Sincronizando zonas 242 • Módulo
de sincronização ElasticSearch 243 • Módulo de sincronização
de
nuvem 247 • Módulo de sincronização de arquivo 251
17.9 Autenticação LDAP 252Mecanismo de autenticação 252 •
Requisitos 253 • Configurar o Object
Gateway para usar a autenticação LDAP 253 • Usando um filtro de
pesquisa
personalizado para limitar o acesso do usuário 254 • Gerando um
token de
acesso para autenticação LDAP 255
17.10 Fragmentação de índice do compartimento de memória
256Refragmentação de índice do compartimento de
memória 256 • Fragmentação de índice para novos compartimentos
de
memória 259
17.11 Integrando o OpenStack Keystone 261Configurando o
OpenStack 261 • Configurando o Ceph Object Gateway 262
17.12 Posicionamento do pool e classes de armazenamento
264Destinos de posicionamento 264 • Classes de
armazenamento 265 • Configuração do grupo de zonas/
zona 265 • Personalizando o posicionamento 267 • Usando classes
de
armazenamento 269
xi Guia de Administração
-
17.13 Object Gateways multissite 269Terminologia 270 •
Configuração de cluster de exemplo 270 • Chaves
do sistema 271 • Convenções de nomeação 271 • Pools
padrão 272 • Criando um domínio 272 • Apagando o grupo de
zonas
padrão 273 • Criando um grupo de zonas master 273 • Criando
uma
zona master 274 • Criando uma zona secundária 277 •
Adicionando
o Object Gateway ao segundo cluster 281 • Failover e recuperação
de
desastre 285
17.14 Equilibrando a carga dos servidores Object Gateway com
HAProxy 287
18 Ceph iSCSI Gateway 28818.1 Conectando-se a destinados
gerenciados por ceph-iscsi 288
Linux (open-iscsi) 288 • Microsoft Windows (Iniciador
Microsoft
iSCSI) 292 • VMware 299
18.2 Conclusão 305
19 Sistema de arquivos em cluster 30619.1 Montando o CephFS
306
Preparação do cliente 306 • Criar um arquivo de segredo 306 •
Montar o
CephFS 307
19.2 Desmontando o CephFS 308
19.3 CephFS no /etc/fstab 309
19.4 Vários daemons MDS ativos (MDS ativo-ativo) 309Quando usar
MDS ativo-ativo 309 • Aumentando o tamanho do cluster
MDS ativo 309 • Diminuindo o número de classificações 310 •
Fixando
manualmente árvores do diretório em uma classificação 312
19.5 Failover de Gerenciamento 312Configurando daemons de
standby 313 • Exemplos 314
19.6 Definindo cotas do CephFS 315Limitações 315 • Configuração
316
19.7 Gerenciando instantâneos do CephFS 317Criando instantâneos
317 • Apagando instantâneos 318
xii Guia de Administração
-
20 Exportando dados do Ceph por meio do Samba 31920.1 Exportando
o CephFS por meio do compartilhamento do Samba 319
Instalação de pacotes relacionados ao Samba 319 • Exemplo de
gateway
único 320 • Configuração de alta disponibilidade 322
20.2 Gateway do Samba ingressando no Active Directory
326Preparação 326 • Verificando o DNS 327 • Resolvendo
registros
SRV 327 • Configurando o kerberos 328 • Resolução de nome
de host local 328 • Configurando o Samba 329 • Ingressando
no domínio do Active Directory 332 • Configurando o Name
Service
Switch 332 • Iniciando os serviços 333 • Testando a
conectividade de
winbindd 333
21 NFS Ganesha: Exportar dados do Ceph pelo NFS 33521.1
Instalação 335
21.2 Configuração 335Configuração de serviço 336 • Configuração
de exportações 338
21.3 Funções personalizadas do NFS Ganesha 340Usuários
diferentes do Object Gateway para NFS Ganesha 341 • Separando a
FSAL do CephFS e do Object Gateway 342 • Operações suportadas
344
21.4 Iniciando ou reiniciando o NFS Ganesha 344
21.5 Definindo o nível de registro 345
21.6 Verificando o compartilhamento NFS exportado 345
21.7 Montando o compartilhamento NFS exportado 345
IV GERENCIANDO O CLUSTER COM FERRAMENTAS DE GUI 346
22 Ceph Dashboard 34722.1 Interface do usuário da Web do painel
de controle 347
Login 347 • Menu de utilitários 349 • Menu principal 350 • O
painel
de conteúdo 350 • Recursos comuns de IU da Web 350 • Widgets
do
painel de controle 351
xiii Guia de Administração
-
22.2 Gerenciando usuários e funções do painel de controle
353Listando usuários 354 • Adicionando novos usuários 354 •
Editando
usuários 355 • Apagando usuários 355 • Listando funções de
usuário 355 • Adicionando funções personalizadas 355 •
Editando
funções personalizadas 357 • Apagando funções personalizadas
357
22.3 Vendo o conteúdo do cluster 357Nós do cluster 357 • Ceph
Monitors 358 • Ceph
OSDs 358 • Configuração do cluster 361 • Mapa
CRUSH 362 • Módulos do gerenciador 363 • Registros 364
22.4 Gerenciando pools 364Adicionando um novo pool 365 •
Apagando pools 366 • Editando opções
de um pool 366
22.5 Gerenciando dispositivos de blocos RADOS 367Vendo detalhes
sobre RBDs 367 • Vendo a configuração do
RBD 368 • Criando RBDs 369 • Apagando RBDs 370 •
Instantâneos
de dispositivo de blocos RADOS 370 • Gerenciando iSCSI
Gateways 371 • Qualidade do Serviço (QdS) do RBD 374 •
Espelhamento
do RBD 377
22.6 Gerenciando o NFS Ganesha 386Adicionando exportações NFS
386 • Apagando exportações
NFS 388 • Editando exportações NFS 388
22.7 Gerenciando sistemas de arquivos Ceph 389Acessando a visão
geral do CephFS 390
22.8 Gerenciando Object Gateways 391Vendo Object Gateways 391 •
Gerenciando usuários do Object
Gateway 392 • Gerenciando compartimentos de memória do
Object
Gateway 394
22.9 Configuração manual 396Suporte a TLS/SSL 396 • Nome de host
e número da porta 398 • Nome de
usuário e senha 399 • Habilitando o front end de gerenciamento
do Object
Gateway 399 • Habilitando login único 400
xiv Guia de Administração
-
22.10 Gerenciando usuários e funções na linha de comando
402Contas de usuário 402 • Funções e permissões de usuário 403 •
Proxies
reversos 407 • Auditoria 407
V INTEGRAÇÃO COM FERRAMENTAS DE VIRTUALIZAÇÃO 409
23 Usando a libvirt com o Ceph 41023.1 Configurando o Ceph
410
23.2 Preparando o gerenciador de VM 411
23.3 Criando uma VM 412
23.4 Configurando a VM 412
23.5 Resumo 415
24 Ceph como back end para instância de KVMQEMU 416
24.1 Instalação 416
24.2 Uso 416
24.3 Criando imagens com o QEMU 417
24.4 Redimensionando imagens com o QEMU 417
24.5 Recuperando informações da imagem com o QEMU 417
24.6 Executando o QEMU com o RBD 418
24.7 Habilitando descarte/TRIM 418
24.8 Opções de cache do QEMU 419
VI PERGUNTAS FREQUENTES, DICAS E SOLUÇÃO DE PROBLEMAS 421
25 Dicas e truques 42225.1 Identificando partições órfãs 422
25.2 Ajustando a depuração 422
xv Guia de Administração
-
25.3 Parando os OSDs sem redistribuição 423
25.4 Sincronização de horário dos nós 424
25.5 Verificando a gravação de dados sem equilíbrio 425
25.6 Subvolume Btrfs para /var/lib/ceph em nós do Ceph Monitor
426Requisitos 427 • Etapas necessárias durante uma nova
implantação
de cluster 427 • Etapas necessárias durante o upgrade do
cluster 428 • Configuração manual 429 • Para obter mais
informações 429
25.7 Aumentando os descritores de arquivos 429
25.8 Integração com software de virtualização 430Armazenando
discos da KVM no cluster do Ceph 430 • Armazenando discos
da libvirt no cluster do Ceph 430 • Armazenando discos do Xen no
cluster
do Ceph 430
25.9 Configurações de firewall para o Ceph 431
25.10 Testando o desempenho da rede 433
25.11 Como localizar discos físicos que usam luzes de LED
434
26 Perguntas frequentes (FAQ) 43926.1 Como o número de grupos de
posicionamento afeta o desempenho do
cluster? 439
26.2 Posso usar SSDs e discos rígidos no mesmo cluster? 439
26.3 Quais são as compensações de usar um diário na SSD? 440
26.4 O que acontece quando há falha em um disco? 441
26.5 O que acontece quando há falha em um disco de diário?
441
27 Solução de problemas 44227.1 Relatando problemas de software
442
27.2 Falha ao enviar objetos grandes pelo rados com OSD completo
442
27.3 Sistema de arquivos XFS corrompido 443
xvi Guia de Administração
-
27.4 Mensagem de status “Too Many PGs per OSD” 443
27.5 Mensagem de status “nn pg stuck inactive” 444
27.6 Peso do OSD é 0 445
27.7 OSD está inativo 445
27.8 Descobrindo OSDs lentos 446
27.9 Corrigindo avisos de diferença do relógio 446
27.10 Cluster de baixo desempenho causado por problemas de rede
447
27.11 Pouco espaço em /var 449
A Exemplo personalizado da fase 1 do DeepSea 451
B Alertas padrão para o SUSE Enterprise Storage 6 452
C Atualizações de manutenção do Ceph baseadas nospoint releases
de upstream do “Nautilus” 456
Glossário 459
D Atualizações da documentação 462D.1 Atualização de manutenção
da documentação do SUSE Enterprise
Storage 6 462
D.2 Junho de 2019 (Lançamento do SUSE Enterprise Storage 6)
464
xvii Guia de Administração
-
Sobre este guia
O SUSE Enterprise Storage 6 é uma extensão do Linux Enterprise
Server 15 SP1. Ele combina osrecursos do projeto de armazenamento
Ceph (http://ceph.com/ ) com a engenharia corporativae o suporte da
SUSE. O SUSE Enterprise Storage 6 oferece às organizações de TI o
recurso paraimplantar uma arquitetura de armazenamento distribuído
capaz de suportar inúmeros casos deuso por meio de plataformas de
hardware convencional.
Este guia ajuda você a entender o conceito do SUSE Enterprise
Storage 6 com foco nogerenciamento e na administração da
infraestrutura do Ceph. Ele também demonstra como usaro Ceph com
outras soluções relacionadas, por exemplo KVM ou OpenStack.
Muitos capítulos neste manual contêm links para recursos
adicionais de documentação. Estãoincluídas a documentação adicional
disponível no sistema e a documentação disponível naInternet.
Para obter uma visão geral da documentação disponível para o seu
produto e das atualizaçõesde documentação mais recentes, consulte
http://www.suse.com/documentation .
1 Documentação disponívelOs seguintes manuais estão disponíveis
para este produto:
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.
xviii Documentação disponível SES 6
http://ceph.com/http://www.suse.com/documentationhttp://www.suse.com/documentationhttp://www.suse.com/documentation
-
2 ComentáriosVários canais de comentário estão disponíveis:
Solicitações de bugs e aperfeiçoamentos
Para ver as opções de serviços e suporte disponíveis ao seu
produto, consulte http://www.suse.com/support/ .Para relatar bugs
no componente de um produto, efetue login no Novell Customer
Centerem http://www.suse.com/support/ e selecione My Support (Meu
Suporte) Service Request(Solicitação de Serviço).
Comentários do usuário
Desejamos saber a sua opinião e receber sugestões sobre este
manual e outrasdocumentações incluídas neste produto. Utilize o
recurso Comentários na parte inferiorde cada página da documentação
online ou vá para http://www.suse.com/documentation/feedback.html e
digite lá os seus comentários.
Correio
Para fazer comentários sobre a documentação deste produto, você
também pode enviarum e-mail para [email protected] . 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
xix Comentários SES 6
http://www.suse.com/support/http://www.suse.com/support/http://www.suse.com/support/http://www.suse.com/documentation/feedback.htmlhttp://www.suse.com/documentation/feedback.html
-
Arquivo, Arquivo Gravar Como: itens de menu, botões
Pinguins Dançarinos (Capítulo Pinguins, ↑Outro Manual): É uma
referência a um capítulode outro manual.
4 Sobre este manualEste manual foi desenvolvido no GeekoDoc, um
subconjunto do DocBook (consulte http://www.docbook.org ). Os
arquivos de origem XML foram validados por xmllint , processadospor
xsltproc e convertidos em XSL-FO usando uma versão personalizada
das folhas deestilo de Norman Walsh. O PDF nal pode ser formatado
por meio do FOP da Apache ou doXEP da RenderX. As ferramentas de
criação e publicação usadas para produzir este manualestão
disponíveis no pacote daps . O DocBook Authoring and Publishing
Suite (DAPS) foidesenvolvido como software de código-fonte aberto.
Para obter mais informações, consultehttp://daps.sf.net/ .
5 Colaboradores do CephO projeto do Ceph e a respectiva
documentação são resultados do trabalho de centenas decolaboradores
e organizações. Visite https://ceph.com/contributors/ para obter
mais detalhes.
xx Sobre este manual SES 6
http://www.docbook.orghttp://www.docbook.orghttp://daps.sf.net/https://ceph.com/contributors/
-
I Gerenciamento de Cluster
1 Privilégios de usuário e prompts de comando 2
2 Administração do cluster do Salt 4
3 Fazendo backup da configuração e dos dados do cluster 29
-
1 Privilégios de usuário e prompts de comando
Como administrador de cluster do Ceph, você congura e ajusta o
comportamento do clusterexecutando comandos especícos. Há vários
tipos de comandos que serão necessários:
1.1 Comandos relacionados ao Salt/DeepSeaEsses comandos ajudam
você a implantar ou fazer upgrade do cluster do Ceph,
executarcomandos em vários (ou todos) nós do cluster ao mesmo tempo
ou ajudá-lo a adicionar ouremover nós do cluster. Os comandos mais
usados são salt , salt-run e deepsea . Você precisaexecutar os
comandos do Salt no nó master Salt (consulte o Livro “Guia de
Implantação”, Capítulo5 “Implantando com o DeepSea/Salt”, Seção 5.2
“Introdução ao DeepSea” para obter detalhes) comoroot . Esses
comandos são introduzidos com o seguinte prompt:
root@master #
Por exemplo:
root@master # salt '*.example.net' test.ping
1.2 Comandos relacionados ao CephTrata-se de comandos de nível
inferior que conguram e ajustam todos os aspectos do clustere seus
gateways na linha de comando. ceph , rbd , radosgw-admin ou
crushtool são algunsdeles.
Para executar os comandos relacionados ao Ceph, você precisa ter
acesso de leitura a uma chavedo Ceph. Os recursos da chave denem
seus privilégios no ambiente do Ceph. Uma opção éexecutar os
comandos do Ceph como root (ou por meio do sudo ) e usar o chaveiro
padrãoirrestrito “ceph.client.admin.key”.
A opção mais segura e recomendada é criar uma chave individual
mais restritiva para cadausuário administrador e colocá-la em um
diretório onde os usuários possam lê-la. Por exemplo:
~/.ceph/ceph.client.USERNAME.keyring
2 Comandos relacionados ao Salt/DeepSea SES 6
-
Dica: Caminho para Chaves do CephPara utilizar um usuário admin
e um chaveiro personalizados, você precisa especicar onome de
usuário e o caminho para a chave toda vez que executar o comando
ceph comas opções -n client.USER_NAME e --keyring PATH/TO/KEYRING
.
Para evitar isso, inclua essas opções na variável CEPH_ARGS nos
arquivos ~/.bashrc dosusuários individuais.
É possível executar os comandos relacionados ao Ceph em qualquer
nó do cluster, mas arecomendação é executá-los no Nó de Admin. Esta
documentação utiliza o usuário cephadmpara executar os comandos,
portanto, eles são introduzidos com o seguinte prompt:
cephadm@adm >
Por exemplo:
cephadm@adm > ceph auth list
Dica: Comandos para Nós EspecíficosSe a documentação orientar
você a executar um comando em um nó do cluster com umafunção
especíca, isso será processado pelo prompt. Por exemplo:
cephadm@mon >
1.3 Comandos gerais do LinuxOs comandos do Linux não
relacionados ao Ceph ou ao DeepSea, como mount , cat ouopenssl ,
são introduzidos com os prompts cephadm@adm > ou root # ,
dependendo dosprivilégios exigidos pelo comando relacionado.
1.4 Informações adicionaisPara obter mais informações sobre o
gerenciamento de chaves do Ceph, consulte a
Seção 8.2,“Gerenciamento de chaves”.
3 Comandos gerais do Linux SES 6
-
2 Administração do cluster do Salt
Após implantar um cluster do Ceph, provavelmente você precisará
fazer várias modicaçõesnele de vez em quando. Dentre elas,
adicionar ou remover novos nós, discos ou serviços. Estecapítulo
descreve como você pode realizar essas tarefas de
administração.
2.1 Adicionando novos nós do clusterO 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 5
“Implantando com o DeepSea/Salt”:
Dica: Evitar RedistribuiçãoAo 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, adicione ao
mesmotempo todos os OSDs desejados.
A outra maneira é denir a opção osd crush initial weight = 0 no
arquivoceph.conf antes de adicionar os OSDs:
1. Adicione osd crush initial weight = 0 a
/srv/salt/ceph/configuration/files/ceph.conf.d/global.conf .
2. Crie a nova conguração no nó master Salt:
root@master # salt 'SALT_MASTER_NODE' state.apply
ceph.configuration.create
3. Aplique a nova conguração aos minions OSD de destino:
root@master # salt 'OSD_MINIONS' state.apply
ceph.configuration
4. Após a adição dos novos OSDs, ajuste os pesos deles conforme
necessário com ocomando ceph osd crush reweight .
4 Adicionando novos nós do cluster SES 6
-
1. Instale o SUSE Linux Enterprise Server 15 SP1 no novo nó e
dena a conguração de redepara que ela resolva o nome de host do
master Salt corretamente. Verique se ele temuma conexão apropriada
com redes públicas e de cluster e se a sincronização de horárioestá
congurada corretamente. Em seguida, 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. No master Salt, aceite a chave salt do novo nó:
root@master # salt-key --accept NEW_NODE_KEY
3. Verique se o /srv/pillar/ceph/deepsea_minions.sls está
direcionado para o novominion Salt e/ou dena o grain do DeepSea
apropriado. Consulte o Livro “Guia deImplantação”, Capítulo 5
“Implantando com o DeepSea/Salt”, Seção 5.2.2.1 “Correspondendo
o
nome do minion” ou o Livro “Guia de Implantação”, Capítulo 5
“Implantando com o DeepSea/Salt”, Seção 5.3 “Implantação do
cluster”, Executando as fases de implantação para obter
maisdetalhes.
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
Importante: Possível Reinicialização da fase 0 do DeepSeaSe o
master Salt for reiniciado após a atualização do kernel, você
precisará reiniciara fase 0 do DeepSea.
5 Adicionando novos nós do cluster SES 6
-
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 5 “Implantando com o DeepSea/Salt”, Seção
5.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
Dica: Modificação do Layout do OSDPara modicar o layout do OSD
padrão e mudar a conguração dos grupos deunidades, siga o
procedimento descrito no Livro “Guia de Implantação”, Capítulo
5“Implantando com o DeepSea/Salt”, Seção 5.5.2 “DriveGroups”.
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
2.2 Adicionando novas funções aos nósVocê pode implantar com o
DeepSea todos os tipos de funções suportadas. Consulte o Livro
“Guiade Implantação”, Capítulo 5 “Implantando com o DeepSea/Salt”,
Seção 5.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.
6 Adicionando novas funções aos nós SES 6
-
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 deImplantação”, Capítulo 5
“Implantando com o DeepSea/Salt”, Seção 5.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 pillar:
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.
2.3 Removendo e reinstalando nós do cluster
Dica: Remoção Temporária de um Nó do ClusterO master Salt espera
que todos os minions estejam presentes e responsivos no cluster.Se
houver falha em um minion e ele parar de responder, isso causará
problemas nainfraestrutura do Salt, principalmente no DeepSea e no
Ceph Dashboard.
Antes de corrigir o minion, apague a chave dele do master Salt
temporariamente:
root@master # salt-key -d MINION_HOST_NAME
Após a correção do minion, adicione a chave dele ao master Salt
novamente:
root@master # salt-key -a MINION_HOST_NAME
Para 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 5 “Implantando com
o DeepSea/Salt”, Seção 5.3 “Implantaçãodo cluster”.
7 Removendo e reinstalando nós do cluster SES 6
-
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.
Antes de executar a fase 5 para fazer a remoção real, sempre
verique quais OSDs serãoremovidos pelo DeepSea:
root@master # salt-run rescinded.ids
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 manualmente.
EXEMPLO 2.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 Profilerole-storage/cluster/data*.sls[...]
Portanto, para remover o minion Salt “data2.ceph”, mude as
linhas para o seguinte:
[...]# Hardware
Profilerole-storage/cluster/data[1,3-6]*.sls[...]
8 Removendo e reinstalando nós do cluster SES 6
-
Lembre-se também de adpatar seu arquivo drive_groups.yml para
corresponder aos novosdestinos.
[...] drive_group_name: target: 'data[1,3-6]*' [...]
Em seguida, execute a fase 2, verique quais OSDs serão removidos
e conclua a execuçãoda fase 5:
root@master # salt-run state.orch ceph.stage.2root@master #
salt-run rescinded.idsroot@master # salt-run state.orch
ceph.stage.5
EXEMPLO 2.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 5“Implantando com o DeepSea/Salt”, Seção 5.3
“Implantação do cluster”, Executando as fases de
implantação) para o novo hardware, você denominou o novo gateway
como rgw1 . Seo nó data8 precisar que a função Object Gateway seja
removida e que a função dearmazenamento seja adicionada, o
policy.cfg atual terá esta aparência:
# Hardware Profilerole-storage/cluster/data[1-7]*.sls
# Rolesrole-rgw/cluster/data8*.sls
Portanto, faça uma mudança para:
# Hardware Profilerole-storage/cluster/data[1-8]*.sls
# Rolesrole-rgw/cluster/rgw1*.sls
9 Removendo e reinstalando nós do cluster SES 6
-
Execute as fases de 2 a 4, verique quais OSDs talvez sejam
removidos e conclua aexecução da fase 5. A Fase 3 adicionará o
data8 como nó de armazenamento. Por algumtempo, o data8 terá as
duas funções. A fase 4 adicionará a função Object Gateway aorgw1 ,
e a fase 5 removerá a função Object Gateway do data8 :
root@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 rescinded.idsroot@master #
salt-run state.orch ceph.stage.5
2.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 um nódo
monitor e, por esse motivo, o cluster car apenas com dois nós, você
precisará atribuirtemporariamente a função do monitor a outros nós
do cluster antes de reimplantar osnó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 2.1,
“Adicionando novos nós do cluster” e a Seção 2.2, “Adicionando
novasfunções aos nós”.
Para obter mais informações sobre como remover nós do cluster,
consulte a Seção 2.3,“Removendo e reinstalando nós do
cluster”.
10 Reimplantando nós do monitor SES 6
-
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 5
“Implantando com o DeepSea/Salt”, Seção 5.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.
Por exemplo:
[...]#
MON#role-mon/cluster/ses-example-failed1.sls#role-mon/cluster/ses-example-failed2.slsrole-mon/cluster/ses-example-new1.slsrole-mon/cluster/ses-example-new2.sls[...]
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
2.5 Adicionando um disco 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 12 no Livro “Guia de Implantação”,
Capítulo 5 “Implantandocom o DeepSea/Salt”, Seção 5.3 “Implantação
do cluster” para obter mais detalhes. Adapte o
/srv/salt/ceph/configuration/files/drive_groups.yml de acordo
(consulte o Livro “Guiade Implantação”, Capítulo 5 “Implantando com
o DeepSea/Salt”, Seção 5.5.2 “DriveGroups” para obterdetalhes).
Após gravar o arquivo, execute a fase 3 do DeepSea:
root@master # deepsea stage run ceph.stage.3
11 Adicionando um disco OSD a um nó SES 6
-
2.6 Removendo um OSDVocê pode remover um Ceph OSD do cluster
executando o seguinte comando:
root@master # salt-run osd.remove OSD_ID
OSD_ID precisa ser um número do OSD sem o prexo osd. . Por
exemplo, use apenas o dígito3 de osd.3 .
2.6.1 Removendo vários OSDs
Siga o mesmo procedimento conforme mencionado na Seção
2.6, “Removendo um OSD”, massimplesmente insira vários IDs de
OSD:
root@master # salt-run osd.remove 2 6 11 15Removing osd 2 on
host data1Draining the OSDWaiting for ceph to catch up.osd.2 is
safe to destroyPurging from the crushmapZapping the device
Removing osd 6 on host data1Draining the OSDWaiting for ceph to
catch up.osd.6 is safe to destroyPurging from the crushmapZapping
the device
Removing osd 11 on host data1Draining the OSDWaiting for ceph to
catch up.osd.11 is safe to destroyPurging from the crushmapZapping
the device
Removing osd 15 on host data1Draining the OSDWaiting for ceph to
catch up.osd.15 is safe to destroyPurging from the crushmap
12 Removendo um OSD SES 6
-
Zapping the device
2:True6:True11:True15:True
2.6.2 Removendo todos os OSDs de um host
Para remover todos os OSDs de um host especíco, execute o
seguinte comando:
root@master # salt-run osd.remove OSD_HOST_NAME
2.6.3 Removendo à força os OSDs danificados
Há casos em que há falha na remoção normal de um OSD (consulte a
Seção 2.6, “Removendoum OSD”). Por exemplo, isso poderá
acontecer se o OSD ou o diário, WAL ou BD dele estiverdanicado,
quando ele é afetado por operações de E/S travadas ou quando há
falha nadesmontagem do disco OSD.
root@master # salt-run osd.remove OSD_ID force=True
Dica: Montagens TravadasSe uma partição ainda estiver montada no
disco que está sendo removido, o comando seráencerrado com a
mensagem: “Unmount failed - check for processes on DEVICE ” (Falha
nadesmontagem. Consulte os processos no DISPOSITIVO). Em seguida, é
possível listar todosos processos que acessam o sistema de arquivos
com o comando fuser -m DISPOSITIVO .Se fuser não retornar nada,
tente unmount DISPOSITIVO manual e conra a saída doscomandos dmesg
ou journalctl .
13 Removendo todos os OSDs de um host SES 6
-
2.6.4 Validando os metadados OSD da LVM
Após remover um OSD usando o comando salt-run osd.remove ID ou
outros comandosceph, os metadados da LVM talvez não sejam
completamente removidos. Isso signica que, parareimplantar um novo
OSD, serão usados os metadados antigos da LVM.
1. Primeiramente, verique se o OSD foi removido:
cephadm@osd > ceph-volume lvm list
Mesmo que um dos OSDs tenha sido removido com êxito, ele ainda
poderá ser listado. Porexemplo, se você removeu o osd.2 , a saída é
a seguinte:
====== osd.2 =======
[block]
/dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380
block device
/dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380
block uuid kH9aNy-vnCT-ExmQ-cAsI-H7Gw-LupE-cvSJO9 cephx lockbox
secret cluster fsid 6b6bbac4-eb11-45cc-b325-637e3ff9fa0c cluster
name ceph crush device class None encrypted 0 osd fsid
aac51485-131c-442b-a243-47c9186067db osd id 2 type block vdo 0
devices /dev/sda
Neste exemplo, você pode ver que o osd.2 ainda está localizado
em /dev/sda .
2. Valide os metadados da LVM no nó OSD:
cephadm@osd > ceph-volume inventory
A saída da execução de ceph-volume inventory marca a
disponibilidade de /dev/sdacomo False (Falso). Por exemplo:
Device Path Size rotates available Model name /dev/sda 40.00 GB
True False QEMU HARDDISK /dev/sdb 40.00 GB True False QEMU HARDDISK
/dev/sdc 40.00 GB True False QEMU HARDDISK
14 Validando os metadados OSD da LVM SES 6
-
/dev/sdd 40.00 GB True False QEMU HARDDISK /dev/sde 40.00 GB
True False QEMU HARDDISK /dev/sdf 40.00 GB True False QEMU HARDDISK
/dev/vda 25.00 GB True False
3. Execute o seguinte comando no nó OSD para remover
completamente os metadados daLVM:
cephadm@osd > ceph-volume lvm zap --osd-id ID --destroy
4. Execute o comando inventory novamente para vericar se a
disponibilidade de /dev/sda é retornada como True (Verdadeiro). Por
exemplo:
cephadm@osd > ceph-volume inventoryDevice Path Size rotates
available Model name/dev/sda 40.00 GB True True QEMU
HARDDISK/dev/sdb 40.00 GB True False QEMU HARDDISK/dev/sdc 40.00 GB
True False QEMU HARDDISK/dev/sdd 40.00 GB True False QEMU
HARDDISK/dev/sde 40.00 GB True False QEMU HARDDISK/dev/sdf 40.00 GB
True False QEMU HARDDISK/dev/vda 25.00 GB True False
Os metadados da LVM foram removidos. Agora é seguro executar o
comando dd nodispositivo.
5. O OSD pode ser reimplantado sem que seja necessário
reinicializar o nó OSD:
root@master # salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3
2.7 Substituindo um disco OSDHá várias razões pelas quais você
pode precisar substituir um disco OSD. Por exemplo:
Houve falha no disco OSD ou ele está prestes a falhar com base
nas informações do SMARTe não poderá mais ser usado para armazenar
dados com segurança.
Por exemplo, você precisa fazer upgrade do disco OSD para
aumentar o tamanho dele.
O procedimento de substituição é o mesmo para os dois casos.
Isso também vale para os MapasCRUSH padrão e personalizados.
15 Substituindo um disco OSD SES 6
-
1. Por exemplo, suponha que “5” é o ID do OSD cujo disco precisa
ser substituído. O comandoa seguir o marca como eliminado no Mapa
CRUSH, mas mantém seu ID original:
root@master # salt-run osd.replace 5
Dica: osd.replace e osd.removeOs comandos osd.replace e
osd.remove do Salt (consulte a Seção 2.6, “Removendoum OSD”)
são idênticos, com exceção de que osd.replace mantém o OSDcomo
“eliminado” no Mapa CRUSH, enquanto osd.remove remove todos
osrastreamentos do Mapa CRUSH.
2. Substitua manualmente a unidade OSD com falha/upgrade.
3. Para modicar o layout do OSD padrão e mudar a conguração dos
DriveGroups, siga oprocedimento descrito no Livro “Guia de
Implantação”, Capítulo 5 “Implantando com o DeepSea/Salt”, Seção
5.5.2 “DriveGroups”.
4. Execute a fase 3 da implantação para implantar o disco OSD
substituído:
root@master # salt-run state.orch ceph.stage.3
2.8 Recuperando um nó OSD reinstaladoSe 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 SUSE Linux Enterprise de base
no nó em que o OS falhou.Instale os pacotes salt-minion no nó OSD,
apague a chave antiga do minion Salt domaster Salt e registre a
nova chave do minion Salt no master Salt. Para obter
maisinformações sobre a implantação inicial, consulte o Livro “Guia
de Implantação”, Capítulo 5“Implantando com o DeepSea/Salt”, Seção
5.3 “Implantação do cluster”.
2. 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
16 Recuperando um nó OSD reinstalado SES 6
-
3. 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
4. Execute a fase 0 do DeepSea:
root@master # salt-run state.orch ceph.stage.0
5. Reinicialize o nó OSD relevante. Todos os discos OSD serão
redescobertos e reutilizados.
6. Instale e execute o exportador de nó do Prometheus:
root@master # salt 'RECOVERED_MINION' \ state.apply
ceph.monitoring.prometheus.exporters.node_exporter
7. Atualize os grains do Salt:
root@master # salt 'RECOVERED_MINION' osd.retain
2.9 Movendo o nó de admin para um novo servidorSe você precisa
substituir o host do Nó de Admin por um novo, é necessário mover os
arquivosdo master Salt e do DeepSea. Use sua ferramenta de
sincronização favorita para transferir osarquivos. Neste
procedimento, usamos o rsync porque é uma ferramenta padrão
disponívelnos repositórios do software SUSE Linux Enterprise Server
15 SP1.
1. Pare os serviços salt-master e salt-minion no Nó de Admin
antigo:
root@master # systemctl stop salt-master.serviceroot@master #
systemctl stop salt-minion.service
2. Congure o Salt no novo Nó de Admin para que o master Salt e
os minions Salt secomuniquem. Encontre mais detalhes no Livro “Guia
de Implantação”, Capítulo 5 “Implantandocom o DeepSea/Salt”, Seção
5.3 “Implantação do cluster”.
17 Movendo o nó de admin para um novo servidor SES 6
-
Dica: Transição de Minions SaltPara facilitar a transição dos
minions Salt para o novo Nó de Admin, remova achave pública do
master Salt original de cada um deles:
root@minion > rm
/etc/salt/pki/minion/minion_master.pubroot@minion > systemctl
restart salt-minion.service
3. Verique se o pacote deepsea está instalado e instale-o, se
necessário.
root@master # zypper install deepsea
4. Personalize o arquivo policy.cfg mudando a linha role-master
. Encontre maisdetalhes no Livro “Guia de Implantação”, Capítulo 5
“Implantando com o DeepSea/Salt”, Seção5.5.1 “Arquivo
policy.cfg”.
5. Sincronize os diretórios /srv/pillar e /srv/salt do Nó de
Admin antigo com o novo.
Dica: Dry Run para rsync e Links SimbólicosSe possível, tente
sincronizar os arquivos em um dry run primeiro para ver quaisserão
transferidos (opção -n do rsync ). Inclua também os links
simbólicos (opção-a do rsync ). Para o rsync , o comando de
sincronização terá a seguinteaparência:
root@master # rsync -avn /srv/pillar/
NEW-ADMIN-HOSTNAME:/srv/pillar
6. Se você fez mudanças personalizadas nos arquivos fora de
/srv/pillar e /srv/salt ,por exemplo, no /etc/salt/master ou no
/etc/salt/master.d , sincronize-as também.
7. Agora você pode executar as fases do DeepSea do novo Nó de
Admin. Consulte o Livro“Guia de Implantação”, Capítulo 5
“Implantando com o DeepSea/Salt”, Seção 5.2 “Introdução ao
DeepSea” para obter a descrição detalhada.
18 Movendo o nó de admin para um novo servidor SES 6
-
2.10 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.
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 começará.
Se a operação for executada apropriadamente, edite o arquivo
/etc/salt/master.d/reactor.conf
e substitua a linha a seguir
- /srv/salt/ceph/reactor/discovery.sls
por
- /srv/salt/ceph/reactor/all_stages.sls
Verique se a linha não está comentada.
2.11 Atualizando os nós do clusterMantenha os nós do cluster do
Ceph atualizados aplicando as atualizações
sequenciaisregularmente.
19 Instalação automatizada pelo Salt SES 6
-
2.11.1 Repositórios do software
Antes de corrigir o cluster com os pacotes de software mais
recentes, verique se todos os nós docluster têm acesso aos
repositórios relevantes. Consulte o Livro “Guia de Implantação”,
Capítulo 6“Fazendo upgrade de versões anteriores”, Seção 6.8.1
“Fazendo upgrade manual do nó por meio do DVD
do instalador” para obter uma lista completa dos repositórios
necessários.
2.11.2 Propagação em fases do repositório
Se você usa uma ferramenta de propagação em fases, por exemplo,
SUSE Manager, SMT(Subscription Management Tool) ou Repository
Mirroring Tool, que processa os repositórios dosoftware nos nós do
cluster, verique se as fases dos dois repositórios “Updates” para o
SUSELinux Enterprise Server e o SUSE Enterprise Storage foram
criadas no mesmo momento.
É altamente recomendável usar uma ferramenta de propagação em
fases para patches comníveis de patch congelados/em fases. Isso
garante que os novos nós que ingressarem no clustertenham o mesmo
nível de patch que os nós que já estão em execução no cluster.
Dessa forma,você não precisa aplicar os patches mais recentes a
todos os nós do cluster antes que os novosnós possam ingressar no
cluster.
2.11.3 zypper patch ou zypper dup
Por padrão, o upgrade dos nós do cluster é feito por meio do
comando zypper dup . Se, em vezdisso, você preferir atualizar o
sistema usando o zypper patch , edite o
/srv/pillar/ceph/stack/global.yml e adicione a seguinte linha:
update_method_init: zypper-patch
2.11.4 Reinicializações de nó do cluster
Durante a atualização, os nós do cluster podem ser
reinicializados se a atualização fez upgradedo kernel deles. Para
eliminar a possibilidade de uma reinicialização forçada de todos os
nós,verique se o kernel mais recente está instalado e em execução
nos nós do Ceph ou desabiliteas renicializações de nó automáticas,
conforme descrito no Livro “Guia de Implantação”, Capítulo
7“Personalizando a configuração padrão”, Seção 7.1.5 “Atualizações
e reinicializações durante a fase 0”.
20 Repositórios do software SES 6
-
2.11.5 Tempo de espera dos serviços do Ceph
Dependendo da conguração, os nós do cluster podem ser
reinicializados durante a atualização,conforme descrito na
Seção 2.11.4, “Reinicializações de nó do cluster”. Se houver
um ponto únicode falha para os serviços, como Object Gateway, Samba
Gateway, NFS Ganesha ou iSCSI, asmáquinas cliente poderão ser
temporariamente desconectadas dos serviços cujos nós estão
sendoreinicializados.
2.11.6 Executando a atualização
Para atualizar os pacotes de software em todos os nós do cluster
para a versão mais recente,siga estas etapas:
1. Atualize os pacotes deepsea , salt-master e salt-minion e
reinicie os serviçosrelevantes no master Salt:
root@master # salt -I 'roles:master' state.apply
ceph.updates.master
2. Atualize e reinicie o pacote salt-minion em todos os nós do
cluster:
root@master # salt -I 'cluster:ceph' state.apply
ceph.updates.salt
3. Atualize todos os outros pacotes de software no cluster:
root@master # salt-run state.orch ceph.maintenance.upgrade
2.12 Parando ou reinicializando o clusterEm 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”:
cephadm@adm > ceph osd set noout
21 Tempo de espera dos serviços do Ceph SES 6
-
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
5. Gateways. Por exemplo, NFS Ganesha ou Object Gateway
6. Clientes de armazenamento
5. Remova o ag “noout”:
cephadm@adm > ceph osd unset noout
22 Parando ou reinicializando o cluster SES 6
-
2.13 Ajustando o ceph.conf com configuraçõespersonalizadasSe
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. Para ver
exemplos, consulte
/srv/salt/ceph/configuration/files/rgw.conf
ou
/srv/salt/ceph/configuration/files/rgw-ssl.conf
Importante: Executar a fase 3Após fazer mudanças personalizadas
nos arquivos de conguração mencionados acima,execute as fases 3 e 4
para aplicá-las aos nós do cluster:
root@master # salt-run state.orch ceph.stage.3
23 Ajustando o ceph.conf com configurações personalizadas SES
6
-
root@master # salt-run state.orch ceph.stage.4
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.
2.13.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
Ao redenir os valores padrão, as ferramentas relacionadas do
Ceph, como rados , podem emitiravisos de que os valores especícos
do ceph.conf.j2 foram redenidos no global.conf .Esses avisos são
causados por um parâmetro atribuído duas vezes no ceph.conf
resultante.
Como uma solução alternativa para este caso especíco, siga estas
etapas:
1. Mude o diretório atual para
/srv/salt/ceph/configuration/create :
root@master # cd /srv/salt/ceph/configuration/create
2. Copie default.sls para custom.sls :
root@master # cp default.sls custom.sls
24 Anulando os padrões SES 6
-
3. Edite custom.sls e mude ceph.conf.j2 para custom-ceph.conf.j2
.
4. Mude o diretório atual para
/srv/salt/ceph/configuration/files :
root@master # cd /srv/salt/ceph/configuration/files
5. Copie ceph.conf.j2 para custom-ceph.conf.j2 :
root@master # cp ceph.conf.j2 custom-ceph.conf.j2
6. Edite custom-ceph.conf.j2 e apague a seguinte linha:
{% include "ceph/configuration/files/rbd.conf" %}
Edite global.yml e adicione a seguinte linha:
configuration_create: custom
7. Atualize o pillar:
root@master # salt target saltutil.pillar_refresh
8. Execute a fase 3:
root@master # salt-run state.orch ceph.stage.3
Agora você deve ter apenas uma entrada para cada denição de
valor. Para recriar aconguração, execute:
root@master # salt-run state.orch ceph.configuration.create
e, em seguida, verique o conteúdo de
/srv/salt/ceph/configuration/cache/ceph.conf .
2.13.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]{% include
"ceph/configuration/files/ceph.conf.d/osd1.conf" ignore missing
%}
25 Incluindo arquivos de configuração SES 6
-
[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 16.1, “Configuração detempo de execução” para obter mais
informações sobre como mudar a conguração detempo de execução do
Ceph.
2.14 Habilitando perfis do AppArmorAppArmor é uma solução de
segurança que limita programas por um perl especíco.Para obter mais
detalhes, visite
https://www.suse.com/documentation/sles-15/book_security/data/part_apparmor.html
.
O DeepSea oferece três estados para os pers do AppArmor:
“enforce”, “complain” e “disable”.Para ativar um determinado estado
do AppArmor, execute:
salt -I "deepsea_minions:*" state.apply
ceph.apparmor.default-STATE
Para colocar os pers do AppArmor no estado “enforce”:
root@master # salt -I "deepsea_minions:*" state.apply
ceph.apparmor.default-enforce
Para colocar os pers do AppArmor no estado “complain”:
root@master # salt -I "deepsea_minions:*" state.apply
ceph.apparmor.default-complain
Para desabilitar os pers do AppArmor:
root@master # salt -I "deepsea_minions:*" state.apply
ceph.apparmor.default-disable
26 Habilitando perfis do AppArmor SES 6
https://www.suse.com/documentation/sles-15/book_security/data/part_apparmor.htmlhttps://www.suse.com/documentation/sles-15/book_security/data/part_apparmor.html
-
Dica: Habilitação do Serviço AppArmorCada uma destas três
chamadas verica se o AppArmor está instalado e o instala, se foro
caso. Em seguida, o serviço systemd relacionado é iniciado e
habilitado. O DeepSeaavisará você se o AppArmor foi instalado e
iniciado/habilitado de outra maneira e,portanto, está em execução
sem os pers do DeepSea.
2.15 Desativando perfis ajustadosPor padrão, o DeepSea implanta
os clusters do Ceph com pers ajustados ativos nos nós doCeph
Monitor, Ceph Manager e Ceph OSD. Em alguns casos, você pode
precisar desativarpermanentemente os pers ajustados. Para fazer
isso, insira as seguintes linhas no
/srv/pillar/ceph/stack/global.yml e execute novamente a fase 3:
alternative_defaults: tuned_mgr_init: default-off
tuned_mon_init: default-off tuned_osd_init: default-off
root@master # salt-run state.orch ceph.stage.3
2.16 Removendo um cluster inteiro do CephO executor ceph.purge
remove o cluster inteiro do Ceph. Desta forma, você pode limpar
oambiente do cluster ao testar congurações diferentes. Após a
conclusão do ceph.purge , ocluster Salt será revertido ao estado no
m da fase 1 do DeepSea. Em seguida, você poderá mudaro policy.cfg
(consulte o Livro “Guia de Implantação”, Capítulo 5 “Implantando
com o DeepSea/Salt”, Seção 5.5.1 “Arquivo policy.cfg”) ou
prosseguir para a fase 2 do DeepSea com a mesmaconguração.
Para evitar a exclusão acidental, a orquestração verica se a
segurança está desligada. Vocêpode desligar as medidas de segurança
e remover o cluster do Ceph executando:
root@master # salt-run disengage.safetyroot@master # salt-run
state.orch ceph.purge
27 Desativando perfis ajustados SES 6
-
Dica: Desabilitação da Remoção do Cluster do CephPara evitar que
qualquer pessoa execute o ceph.purge , crie um arquivo
denominadodisabled.sls no diretório /srv/salt/ceph/purge e insira a
linha a seguir no arquivo/srv/pillar/ceph/stack/global.yml :
purge_init: disabled
Importante: Rescindir Funções PersonalizadasSe você já criou
funções personalizadas para o Ceph Dashboard (consulte a
Seção 22.2.6,“Adicionando funções personalizadas” e a
Seção 22.10.2, “Funções e permissões de usuário” paraobter
informações detalhadas), precisa realizar etapas manuais para
purgá-las antes deexecutar o ceph.purge . Por exemplo, se o nome da
função personalizada para o ObjectGateway for “us-east-1”, siga
estas etapas:
root@master # cd /srv/salt/ceph/rescindroot@master # rsync -a
rgw/ us-east-1root@master # sed -i 's!rgw!us-east-1!'
us-east-1/*.sls
28 Removendo um cluster inteiro do Ceph SES 6
-
3 Fazendo backup da configuração e dos dados docluster
Este capítulo explica quais partes do cluster do Ceph devem ser
incluídas no backup para queseja possível restaurar a
funcionalidade dele.
3.1 Fazendo backup da configuração do CephFaça backup do
diretório /etc/ceph . Ele inclui a conguração essencial do cluster.
Vocêprecisará fazer backup do /etc/ceph , por exemplo, quando for
necessário substituir o Nó deAdmin.
3.2 Fazendo backup da configuração do SaltVocê precisa fazer
backup do diretório /etc/salt/ . Ele contém os arquivos de
conguraçãodo Salt. Por exemplo, a chave master do Salt e as chaves
aceitas do cliente.
Os arquivos do Salt não são estritamente necessários para fazer
backup do Nó de Admin, masfacilitam a reimplantação do cluster do
Salt. Se não houver nenhum backup desses arquivos, osminions Salt
precisarão ser registrados novamente no novo Nó de Admin.
Nota: Segurança da chave privada master do SaltGaranta que o
backup da chave privada master do Salt esteja armazenado em um
localseguro. A chave master do Salt pode ser usada para manipular
todos os nós do cluster.
Após a restauração do diretório /etc/salt de um backup, reinicie
os serviços Salt:
root@master # systemctl restart salt-masterroot@master #
systemctl restart salt-minion
3.3 Fazendo backup da configuração do DeepSeaTodos os arquivos
necessários ao DeepSea são armazenados em /srv/pillar/ ,
/srv/salt/e /etc/salt/master.d .
29 Fazendo backup da configuração do Ceph SES 6
-
Se você precisar reimplantar o Nó de Admin, instale o pacote do
DeepSea no novo nó e movaos dados dos quais foi feito o backup de
volta aos diretórios. Em seguida, o DeepSea poderá serusado
novamente sem a necessidade de outras modicações. Antes de usar o
DeepSea de novo,verique se todos os minions Salt estão registrados
corretamente no Nó de Admin.
3.4 Configurações personalizadas de backup
Dados e personalização do Prometheus.
Personalização do Grafana.
Verique se você tem um registro de usuários existentes do
openATTIC para que possacriar novas contas para esses usuários no
Ceph Dashboard.
Mudanças manuais no ceph.conf fora do DeepSea.
Mudanças manuais na conguração do iSCSI fora do DeepSea.
Chaves do Ceph.
Mapa CRUSH e regras CRUSH. Execute o comando a seguir para
gravar o Mapa CRUSHdescompilado incluindo as regras CRUSH no
crushmap-backup.txt :
cephadm@adm > ceph osd getcrushmap | crushtool -d - -o
crushmap-backup.txt
Conguração do Gateway do Samba. Se você usa um único gateway,
faça backup do /etc/samba/smb.conf . Se você usa a conguração de
HA, faça backup também dos arquivos deconguração CTDB e Pacemaker.
Consulte o Capítulo 20, Exportando dados do Ceph por meiodo
Samba para obter detalhes sobre a conguração que é usada pelos
Gateways do Samba.
Conguração do NFS Ganesha. Necessário apenas ao usar a
conguração de HA. Consulteo Capítulo 21, NFS Ganesha:
Exportar dados do Ceph pelo NFS para obter detalhes sobre
aconguração que é usada pelo NFS Ganesha.
30 Configurações personalizadas de backup SES 6
-
II Operando um cluster
4 Introdução 32
5 Operando serviços do Ceph 33
6 Determinando o estado do cluster 38
7 Monitoramento e alerta 72
8 Autenticação com cephx 91
9 Gerenciamento de dados armazenados 106
10 Módulos do Ceph Manager 137
11 Gerenciando pools de armazenamento 142
12 Dispositivo de blocos RADOS 163
13 Pools com codificação de eliminação 190
14 Camadas de cache 197
15 Melhorando o desempenho com o cache LVM 208
16 Configuração do cluster do Ceph 213
-
4 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.
32 SES 6
-
5 Operando serviços do Ceph
Você pode operar serviços do Ceph usando o systemd ou o
DeepSea.
5.1 Operando serviços relacionados ao cluster doCeph por meio do
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.
5.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 :
cephadm@adm > 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 start ceph.targetroot # systemctl stop
ceph.targetroot # systemctl restart ceph.target
Para iniciar/parar/reiniciar todos os OSDs no nó, execute:
root # systemctl start ceph-osd.targetroot # systemctl stop
ceph-osd.targetroot # systemctl restart ceph-osd.target
Os comandos para os outros destinos são semelhantes.
33 Operando serviços relacionados ao cluster do Ceph por meio do
systemd SES 6
-
5.1.2 Iniciando, parando e reiniciando serviços individuaisVocê
pode operar serviços individuais usando os seguintes arquivos
parametrizados da unidadesystemd :
[email protected]@[email protected]@[email protected]@.service
Para usar esses comandos, primeiro você precisa identicar o nome
do serviço que deseja operar.Consulte a Seção 5.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 start [email protected] # systemctl stop
[email protected] # systemctl restart [email protected]
Os comandos para os outros tipos de serviço são semelhantes.
5.1.3 Identificando serviços individuaisVocê pode descobrir
nomes/números de um determinado tipo de serviço de várias maneiras.
Osseguintes comandos apresentam resultados para os serviços do
ceph* . Você pode executá-losem qualquer nó do cluster do Ceph.
Para listar todos os serviços (até os inativos) do tipo ceph* ,
execute:
root # systemctl list-units --all --type=service ceph*
Para listar apenas os serviços inativos, execute:
root # systemctl list-units --all --state=inactive
--type=service ceph*
Você também pode usar o salt para consultar serviços em vários
nós:
root@master # salt TARGET cmd.shell \ "systemctl list-units
--all --type=service ceph* | sed -e '/^$/,$ d'"
Consultar apenas nós de armazenamento:
root@master # salt -I 'roles:storage' cmd.shell \ 'systemctl
list-units --all --type=service ceph*'
34 Iniciando, parando e reiniciando serviços individuais SES
6
-
5.1.4 Status do serviço
É possível consultar o systemd para saber o status dos serviços.
Por exemplo:
root # systemctl status [email protected] # systemctl
status [email protected]
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 5.1.3, “Identificando serviçosindividuais”.
5.2 Reiniciando serviços do Ceph usando DeepSeaApós aplicar
atualizações aos nós do cluster, os serviços relacionados ao Ceph
afetadosprecisarão ser reiniciados. Normalmente, as
reinicializações são executadas automaticamentepelo DeepSea. Esta
seção descreve como reiniciar os serviços manualmente.
Dica: 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
Outro comando para monitorar tarefas ativas é
root@master # salt-run jobs.active
5.2.1 Reiniciando todos os serviços
Atenção: Interrupção de ServiçosSe os serviços relacionados ao
Ceph, especicamente o iSCSI ou o NFS Ganesha, foremcongurados como
pontos únicos de acesso sem conguração de Alta Disponibilidade,
areinicialização deles resultará na interrupção temporária quando
vistos do lado do cliente.
35 Status do serviço SES 6
-
Dica: Samba Não Gerenciado pelo DeepSeaComo o DeepSea e o Ceph
Dashboard não suportam implantações do Samba no momento,você
precisa gerenciar os serviços relacionados ao Samba manualmente.
Para ver maisdetalhes, consulte o Capítulo 20, Exportando
dados do Ceph por meio do Samba.
Para reiniciar todos os serviços no cluster, execute o seguinte
comando:
root@master # salt-run state.orch ceph.restart
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.
5.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
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
36 Reiniciando serviços específicos SES 6
-
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
5.3 Encerramento normal de todo o cluster do CephHá ocasiões em
que você precisa parar todos os serviços relacionados ao Ceph no
cluster naordem recomendada e depois apenas iniciá-los novamente.
Por exemplo, em caso de queda deenergia planejada.
Para encerrar todo o cluster do Ceph, desabilite as medidas de
segurança e execute oceph.shutdown :
root@master # salt-run disengage.safetyroot@master # salt-run
state.orch ceph.shutdown
Para iniciar todo o cluster do Ceph, execute o ceph.startup
:
root@master # salt-run state.orch ceph.startup
37 Encerramento normal de todo o cluster do Ceph SES 6
-
6 Determinando o estado do cluster
Quando você tem um cluster em execução, pode usar a ferramenta
ceph para monitorá-lo.Normalmente, determinar o estado do cluster
envolve vericar o status dos Ceph OSDs, CephMonitors, grupos de
posicionamento e Servidores 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@adm > cephceph> healthceph> statusceph>
quorum_statusceph> mon_status
6.1 Verificando o status do clusterPara vericar o status de um
cluster, execute o seguinte:
cephadm@adm > ceph status
ou
cephadm@adm > 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 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
38 Verificando o status do cluster SES 6
-
115 GB used, 167 GB / 297 GB avail 1 active+clean+scrubbing+deep
951 active+clean
6.2 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:
cephadm@adm > ceph healthHEALTH_WARN 10 pgs degraded; 100 pgs
stuck unclean; 1 mons down, quorum 0,2 \node-1,node-2,node-3
DicaSe você especicou locais diferentes do padrão em sua
conguração ou no chaveiro, deveespecicar estes locais:
cephadm@adm > ceph -c /path/to/conf -k /path/to/keyring
health
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.
OSD_ORPHAN
Um OSD é referenciado na hierarquia do mapa CRUSH, mas não
existe. O OSD pode serremovido da hierarquia do CRUSH com:
cephadm@adm > ceph osd crush rm osd.ID
39 Verificando a saúde do cluster SES 6
-
OSD_OUT_OF_ORDER_FULL
Os limites de uso para backllfull (padrão denido como 0,90),
nearfull (padrão denidocomo 0,85), full (padrão denido como 0,95)
e/ou failsafe_full não são ascendentes.Especicamente, esperamos
backllfull < nearfull, nearfull < full e full <
failsafe_full.Para ler os valores atuais, execute:
cephadm@adm > ceph health detailHEALTH_ERR 1 full osd(s); 1
backfillfull osd(s); 1 nearfull osd(s)osd.3 is full at 97%osd.4 is
backfill full at 91%osd.2 is near full at 87%
É possível ajustar os limites com os seguintes comandos:
cephadm@adm > ceph osd set-backfillfull-ratio
ratiocephadm@adm > ceph osd set-nearfull-ratio ratiocephadm@adm
> 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:
cephadm@adm > ceph df
É possível ver a cota full denida no momento com:
cephadm@adm > 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:
cephadm@adm > 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:
cephadm@adm > ceph df
40 Verificando a saúde do cluster SES 6
-
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:
cephadm@adm > 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:
cephadm@adm > ceph osd set flagcephadm@adm > 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 9.6, “Depuração”) está
desabilitada.
notieragent
41 Verificando a saúde do cluster SES 6
-
A atividade de camadas de cache foi suspensa.
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:
cephadm@adm > ceph osd add-flag osd-IDcephadm@adm > 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 co
