Ceph
Este documento visa apresentar o sistema de armazenamento definido por
software Ceph, seu processo de configuração, uso e operação.
Atualizado em: 7 de outubro de 2024
Revision: add05a341f4bbc51fecf1d5c8a9992591400771a
Conteúdo
Lista de Abreviaturas 11
I Teoria e Conceitos Básicos 12
1 Introdução 13
1.1 Componentes básicos . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 CRUSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Mapas de Metadados . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.5 Placement Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.6 Redes do Ceph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.7 Fluxo básico do Ceph . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2 Uso e comandos básicos 37
2.1 ceph-volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
II Formas de implantação 44
3 Formas de implantação 45
4 Deploy manual 46
5 ceph-ansible 63
5.1 Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Remoção do cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 Atualização do cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6 Cephadm 69
6.1 Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
III Dashboard e orchestrator 80
2
7 Dashboard 81
7.1 Chamadas para a API do MGR . . . . . . . . . . . . . . . . . . . . . 83
8 Orchestrator 101
IV Formas de consumo e operações 103
9 Operações com pools 104
10 Operações com blocos 114
11 Operações com OSDs 117
11.1 Detecção e correção de falhas . . . . . . . . . . . . . . . . . . . . . 117
11.2 Detectando OSDs lentos . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.3 Manutenção de OSDs . . . . . . . . . . . . . . . . . . . . . . . . . . 122
12 Operações com crush map e rules 123
12.1 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
12.2 Tipos e Buckets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
12.3 Regras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
12.4 Afinidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13 CephFS 135
14 Gerenciando usuários 139
14.1 Gerenciando usuários com acesso ao cluster . . . . . . . . . . . . . 139
14.1.1 Utilizando namespaces . . . . . . . . . . . . . . . . . . . . . . 141
14.2 Gerenciando usuários do dashboard . . . . . . . . . . . . . . . . . . 142
14.3 Gerenciando usuários do RGW . . . . . . . . . . . . . . . . . . . . . 149
15 iSCSI 157
15.1 Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
15.1.1 Clientes Windows . . . . . . . . . . . . . . . . . . . . . . . . . 162
15.1.2 Clientes Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
3
V Conceitos avançados e processos do Ceph 175
16 BlueStore 176
17 Bucket policies 179
17.1 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
18 Ceph scrub 181
19 Compressão de dados 186
20 Deduplicação de dados 188
21 Snapshots 190
22 Configurações 196
22.1 Configurações importantes . . . . . . . . . . . . . . . . . . . . . . . 197
VI Dicas e truques 199
23 Alterando configurações dinamicamente 200
24 Resolvendo o warning de mon is allowing insecure global_id reclaim 201
25 Alterar redes do Ceph 201
26 Operações básicas com OSDs 202
26.1 Detecção e correção de falhas em OSDs . . . . . . . . . . . . . . . 202
26.2 Detectando OSDs lentos . . . . . . . . . . . . . . . . . . . . . . . . . 204
26.3 Verificando o mapeamento dos OSDs com discos físicos . . . . . . 206
27 Coletando informações sobre falhas 209
28 Boas práticas no uso do RadosGW 210
28.1 Boas práticas na criação de usuários . . . . . . . . . . . . . . . . . 210
28.2 Boas práticas na criação de buckets . . . . . . . . . . . . . . . . . . 210
29 Criar VM usando RBD como backend 211
4
Lista de Figuras
1 Layers básicos do Ceph . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Acesso ao RADOS através do librados . . . . . . . . . . . . . . . . . 15
3 Armazenamento em blocos com KRDB . . . . . . . . . . . . . . . . 18
4 Armazenamento em blocos com librbd . . . . . . . . . . . . . . . . 19
5 Armazenamento em objetos com librgw . . . . . . . . . . . . . . . 20
6 Uso de PGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7 Redes usadas no Ceph . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8 Fluxo Básico de Escrita . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9 Fluxo Básico de Leitura/Escrita . . . . . . . . . . . . . . . . . . . . . 35
10 Fluxo Básico de Recuperação de Falhas . . . . . . . . . . . . . . . . 36
11 Fluxo Básico de Recuperação de Falhas . . . . . . . . . . . . . . . . 36
12 Acessando o host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
13 Pacotes a serem instalados no host . . . . . . . . . . . . . . . . . . 48
14 Diretório criado no host . . . . . . . . . . . . . . . . . . . . . . . . . 48
15 fsid gerado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
16 Criar chaves do MON . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
17 Criar chaves do admin . . . . . . . . . . . . . . . . . . . . . . . . . . 49
18 Criar chaves dos OSDs . . . . . . . . . . . . . . . . . . . . . . . . . . 50
19 Importar as chaves criadas . . . . . . . . . . . . . . . . . . . . . . . 50
20 Alterar o dono do arquivo . . . . . . . . . . . . . . . . . . . . . . . . 50
21 Criando o mapa do MON . . . . . . . . . . . . . . . . . . . . . . . . 51
22 Criar o diretório padrão do MON . . . . . . . . . . . . . . . . . . . . 51
23 Populando o serviço do MON . . . . . . . . . . . . . . . . . . . . . . 51
24 Arquivo de configuração . . . . . . . . . . . . . . . . . . . . . . . . . 52
25 Habilitando e iniciando o serviço do MON . . . . . . . . . . . . . . 52
26 Configurando o firewall . . . . . . . . . . . . . . . . . . . . . . . . . 52
27 MON rodando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5
28 Criando o diretório padrão do MGR . . . . . . . . . . . . . . . . . . 53
29 Criando a chave de autenticação do MGR . . . . . . . . . . . . . . . 54
30 Ativar o MGR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
31 Habilitar os serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
32 Instalando os pacotes do OSD . . . . . . . . . . . . . . . . . . . . . 55
33 Copiando os arquivos necessários para o OSD . . . . . . . . . . . . 56
34 Criando o volume do OSD . . . . . . . . . . . . . . . . . . . . . . . . 57
35 Listar todos os volumes do cluster . . . . . . . . . . . . . . . . . . . 58
36 Ativar o OSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
37 Verificar o estado do cluster . . . . . . . . . . . . . . . . . . . . . . . 59
38 Instalar os pacotes do MDS . . . . . . . . . . . . . . . . . . . . . . . 60
39 Copiar os arquivos necessários para o MDS . . . . . . . . . . . . . 60
40 Criar o diretório padrão do MDS . . . . . . . . . . . . . . . . . . . . 61
41 Criar as chaves de autenticação do MDS . . . . . . . . . . . . . . . 61
42 Importando as chaves do MDS para o cluster . . . . . . . . . . . . . 61
43 Iniciando o MDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
44 Checando o estado do cluster . . . . . . . . . . . . . . . . . . . . . . 62
45 Finalização do deploy do Ceph . . . . . . . . . . . . . . . . . . . . . 67
46 Baixando o script do cephadm . . . . . . . . . . . . . . . . . . . . . 69
47 Tornando o script executável . . . . . . . . . . . . . . . . . . . . . . 69
48 Adicionando os pacotes da versão desejada do Ceph . . . . . . . . 70
49 Verificando a instalação do cephadm . . . . . . . . . . . . . . . . . 70
50 Adicionando o pacote ceph-common . . . . . . . . . . . . . . . . . 70
51 Instalando o cephadm via repositórios da distribuição . . . . . . . 71
52 Realizando o deploy inicial do cluster . . . . . . . . . . . . . . . . . . 73
53 Containeres criados por padrão no bootstrap . . . . . . . . . . . . . 74
54 Informações do cluster criado inicialmente no bootstrap . . . . . . 74
55 Copiando a chave para os demais hosts . . . . . . . . . . . . . . . . 75
56 Adicionando novos hosts . . . . . . . . . . . . . . . . . . . . . . . . . 75
6
57 Listando os novos hosts . . . . . . . . . . . . . . . . . . . . . . . . . 76
58 Adicionando os MONs . . . . . . . . . . . . . . . . . . . . . . . . . . 77
59 Adicionando os OSDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
60 Listando os discos disponíveis para usar como OSDs . . . . . . . . 78
61 Criando os OSDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
62 Dashboard do Ceph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
63 Acessando a API do dashboard . . . . . . . . . . . . . . . . . . . . . 84
64 Documentação da API do manager . . . . . . . . . . . . . . . . . . . 84
65 Habilitar a escrita parcial em um pool erasure code . . . . . . . . . 105
66 Listando pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
67 Criando novo pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
68 Criando novo pool replicado . . . . . . . . . . . . . . . . . . . . . . 110
69 Criando novo pool com erasure code . . . . . . . . . . . . . . . . . . 111
70 Editando pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
71 Editando pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
72 Criando imagem em pool erasure code . . . . . . . . . . . . . . . . . 114
73 Hierarquia de buckets do Ceph . . . . . . . . . . . . . . . . . . . . . 126
74 Acessando a tela de gerencia de usuários . . . . . . . . . . . . . . . 145
75 Listando todos os usuários . . . . . . . . . . . . . . . . . . . . . . . 145
76 Selecionando usuário específico . . . . . . . . . . . . . . . . . . . . 146
77 Verificando detalhes de um usuário específico . . . . . . . . . . . . 146
78 Criando novo usuário . . . . . . . . . . . . . . . . . . . . . . . . . . 146
79 Especificando detalhes do novo usuário . . . . . . . . . . . . . . . 147
80 Editando usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
81 Editando usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
82 Removendo usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
83 Confirmando remoção do usuário . . . . . . . . . . . . . . . . . . . 149
84 Listando usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
85 Listando detalhes do usuário . . . . . . . . . . . . . . . . . . . . . . 151
7
86 Criando novo usuário . . . . . . . . . . . . . . . . . . . . . . . . . . 151
87 Especificando detalhes do novo usuário . . . . . . . . . . . . . . . 152
88 Selecionando usuário “pai” . . . . . . . . . . . . . . . . . . . . . . . 153
89 Criando subusuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
90 Especificando detalhes do subusuário . . . . . . . . . . . . . . . . . 154
91 Selecionando usuário para editar . . . . . . . . . . . . . . . . . . . 154
92 Editando usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
93 Removendo usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
94 Confirmando remoção do usuário . . . . . . . . . . . . . . . . . . . 156
95 Acessando os targets iSCSI . . . . . . . . . . . . . . . . . . . . . . . . 157
96 Criando novo target iSCSI . . . . . . . . . . . . . . . . . . . . . . . . 158
97 Detalhes na criação de um novo target iSCSI . . . . . . . . . . . . . 158
98 Exemplo de configuração parcial de um novo target iSCSI . . . . . 159
99 Adicionando Initiator . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
100 Target criado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
101 Instalando o Multipath-IO . . . . . . . . . . . . . . . . . . . . . . . . 163
102 Configurações atuais do Multipath-IO . . . . . . . . . . . . . . . . . 163
103 Alterando as configurações do Multipath-IO . . . . . . . . . . . . . 164
104 Habilitando o multipath no programa MPIO . . . . . . . . . . . . . 164
105 Utilizando o programa iSCSI Initiator no Windows . . . . . . . . . . 165
106 Acessando configurações do iSCSI Initiator . . . . . . . . . . . . . . 165
107 Copiando o Initiator Name . . . . . . . . . . . . . . . . . . . . . . . 166
108 Quick Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
109 Confirme a conexão . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
110 Habilitando o multipath no initiator . . . . . . . . . . . . . . . . . . 168
111 Adicionando um dos gateways na conexão . . . . . . . . . . . . . . 169
112 Acessando devices disponíveis . . . . . . . . . . . . . . . . . . . . . 170
113 Detalhes do device disponível . . . . . . . . . . . . . . . . . . . . . . 171
114 Formatando o novo device . . . . . . . . . . . . . . . . . . . . . . . . 172
8
115 Device formatado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
116 Agora o device pode ser utilizado como um disco qualquer . . . . 173
117 Criando o snapshot do pool . . . . . . . . . . . . . . . . . . . . . . . 190
118 Listando as snapshots do pool . . . . . . . . . . . . . . . . . . . . . . 190
119 Removendo uma snapshot do pool . . . . . . . . . . . . . . . . . . . 191
120 Revertendo o estado do objeto para a snapshot . . . . . . . . . . . 191
121 Criando snapshots da imagem . . . . . . . . . . . . . . . . . . . . . 192
122 Listando as snapshots da imagem . . . . . . . . . . . . . . . . . . . 192
123 Revertendo a snapshot da imagem . . . . . . . . . . . . . . . . . . . 192
124 Removendo a snapshot da imagem . . . . . . . . . . . . . . . . . . 193
125 Detalhes do pool com snapshots sendo removidas . . . . . . . . . 193
126 Detalhes do pool após a snapshot ter sido removida . . . . . . . . 193
127 Removendo todas as snapshots da imagem . . . . . . . . . . . . . 194
128 Protegendo a snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . 194
129 Removendo a proteção da snapshot . . . . . . . . . . . . . . . . . . 195
130 Obtendo o tamanho real da snapshot . . . . . . . . . . . . . . . . . 195
131 Alterando dinamicamente a configuração mon_osd_down_out_i
nterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
132 Alterando dinamicamente a configuração mon_max_pg_per_osd . 198
133 Obtendo informações sobre a configuração . . . . . . . . . . . . . 200
134 Listando os OSDs e seus hosts . . . . . . . . . . . . . . . . . . . . . 207
135 Link simbólico do OSD . . . . . . . . . . . . . . . . . . . . . . . . . . 207
136 Encontrando o dispositivo físico pelo link simbólico do OSD . . . . 208
137 Listando os OSDs do host e seus discos físicos associados . . . . . 208
138 Criando o pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
139 Criando a imagem RBD . . . . . . . . . . . . . . . . . . . . . . . . . 212
140 Criando o usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
141 Arquivo secret.xml no host KVM . . . . . . . . . . . . . . . . . . . . 213
142 Definindo a chave no libvirt . . . . . . . . . . . . . . . . . . . . . . . 213
9
143 Definindo a autenticação no secret do libvirt . . . . . . . . . . . . . 213
144 Criando uma VM sem storage . . . . . . . . . . . . . . . . . . . . . . 214
145 Criando uma VM normalmente . . . . . . . . . . . . . . . . . . . . . 214
146 Editando o XML da VM . . . . . . . . . . . . . . . . . . . . . . . . . . 215
147 Iniciando a instalação da VM . . . . . . . . . . . . . . . . . . . . . . 216
148 Continuando a instalação da VM . . . . . . . . . . . . . . . . . . . . 217
149 Mapeando a imagem localmente . . . . . . . . . . . . . . . . . . . . 217
150 Criando a VM usando a imagem mapeada localmente . . . . . . . 218
151 Finalizar a criação da VM usando a imagem mapeada localmente 218
10
Lista de Abreviaturas
CephFS Ceph Filesystem
CLI Command Line Interface
CRUSH Controlled Replication Under Scalable
Hashing ou Replicação Controlada Sobre
Hash Escalável
MDS Ceph Metadata Server
MGR Ceph Manager
MON Ceph Monitor
OSD Object Storage Devices
PG Placement Group
RADOS Reliable Autonomic Distributed Object Store
RBD Rados Block Device
RGW RADOS Gateway
S3 Simple Storage System
11
Parte I
Teoria e Conceitos Básicos
O presente capítulo se destina a descrever a teoria e conceitos básicos sobre o
sistema de armazenamento definido por software SDS Ceph.
12
1. Introdução
Ceph é um sistema de armazenamento definido por software open-source,
criado por Sage Weil em 2007 em sua tese de doutorado. O sistema Ceph visa
disponibilizar armazenamento distribuído com alta escalabilidade, confiabili-
dade e desempenho, sem a necessidade de hardware ou sistemas de rede es-
pecializados.
Sistemas Ceph possuem funções de autogerenciamento e recuperação para
automatizar o gerenciamento dos dados, como distribuição, redistribuição e
replicação dos dados, assim como detecção e recuperação de falhas. O sistema
não possui um ponto único de falha, uma vez que os dados são distribuídos e
gerenciados por agentes autônomos que estão em constante interação.
O Ceph possui interfaces que suportam três tipos de modos de dados, cha-
mados de gateways, podendo ser arquivos, blocos ou objetos. De forma breve,
o armazenamento usando arquivos organiza os dados em uma hierarquia de
arquivos e diretórios (como um sistema de arquivos comum). O armazena-
mento de blocos é utilizado para entregar blocos de armazenamento via rede
através do protocolo RBD. O armazenamento de objetos trabalha os dados
como objetos com o padrão S3.
Aqui é importante ressaltar que os gateways do Ceph emulam essas três
formas de armazenamento, porém, internamente, o Ceph sempre armazena
os dados no formato de objetos
1
.).
1.1. Componentes básicos
A Figura 1 exibe a estrutura básica do Ceph.
1
Não confundir com objetos do protocolo S3, aqui estamos falando da implementação pró-
pria do Ceph de objetos, chamados de Rados Objects
13
Figura 1: Layers básicos do Ceph
• RADOS:
É o conceito base do Ceph. Ao final do processo, todos os dados do Ceph
são armazenados em formato de objetos, sendo a implementação desse
conceito responsável por armazená-los, independente do tipo inicial dos
mesmos.
Além disso, é a implementação do RADOS a responsável por manter a
consistência dos dados através de replicação dos mesmos, assim como
detecção e recuperação de falhas, migração e rebalanceamento dos da-
dos através dos nós do cluster.
• LIBRADOS:
Biblioteca que provê uma interface nativa para trabalhar com uma imple-
mentação de RADOS. Pode ser utilizada por diversas linguagens, como
PHP, Ruby, Java, Python, C e C++. Serve como base de acesso de outras
aplicações, como o RBD, RGW e CephFS. Apenas essa biblioteca acessa
diretamente o Ceph, de forma que, as demais aplicações que desejam
14
acessar precisam usar essa biblioteca, seguindo o diagrama da Figura 2:
Figura 2: Acesso ao RADOS através do librados
A comunicação entre o librados e o RADOS ocorre através de um protocolo
nativo, que torna a comunicação entre os dois componentes mais rápida
em comparação com o uso de protocolos padrões e genéricos.
• MON:
Monitores do Ceph responsáveis por checar a saúde do cluster e manter
mapas com informações de cada componente do cluster, incluindo mapas
de OSDs, mapas de MONs, mapas de PGs
2
e mapas das regras CRUSH.
Todos os componentes do cluster reportam aos MONs e compartilham
informações sempre que ocorre alguma alteração em seus estados.
2
Esse componente será melhor explicado na Seção 1.3.
15
É recomendado que o número de MONs de um cluster seja um número
ímpar, e com o mínimo de 3 monitores, uma vez que esse componente
usa o algoritmo de Paxos para definição de um líder através do quorum.
Além disso, também é recomendado que cada MON tenha um mínimo de
2 CPUs, entre 2 à 4 GB de RAM, e cerca de 60 GB de armazenamento
3
• MDS:
Servidores de Metadados do Ceph, armazenam metadados do sistema
de arquivos Ceph, como permissões e propriedades de arquivos, ou seja,
se o Ceph for utilizado somente para armazenamento em blocos ou ob-
jetos
4
, os MDSs não serão necessários.
É recomendado que o número mínimo de MDSs seja 2. Dessa forma, o
Ceph irá utilizar um deles como primário, enquanto o outro ficará como
backup, de forma que, caso o MDS primário caia, as cargas do ambiente
serão automaticamente redirecionadas para o MDS de backup, que pas-
sará a atuar como primário. Além disso, também é recomendado que
cada MDS tenha um mínimo de 2 CPUs, e 2 GB ou mais.
• MGR:
Componente adicionado a partir da versão 12.x
5
do Ceph
6
, responsável
por manter métricas em tempo real do cluster, como utilização do arma-
zenamento, métricas de performace do cluster, carga do sistema, entre
outros. Além disso, esse componente também disponibiliza um dashbo-
ard web, e provê uma interface rest para uso de sistemas de monitora-
mento externos. É recomendado que o número mínimo de MGRs seja 2.
3
É possível ter um MON perfeitamente funcional com apenas 20 GB de armazenamento,
mas essa indicação de valor considera que os logs dos mesmos podem crescer exponencial-
mente dependendo da infraestrutura do cluster e da política de rotacionamento e/ou exclusão
dos logs.
4
No formato S3.
5
Release de codinome Luminous, atualmente na versão 12.2.13
6
Informações sobre as versões do Ceph podem ser encontradas nesse link
16
Dessa forma, o Ceph irá utilizar um deles como primário, enquanto o ou-
tro ficará como backup, de forma que, caso o MGR primário caia, o backup
assumirá seu lugar, mantendo a alta disponibilidade do ambiente intacta.
Não existe nenhuma recomendação oficial sobre o hardware para esse
componente, mas pode-se utilizar as mesmas recomendações de hard-
ware dos MONs.
• OSD:
São a representação dos discos físicos nos quais os dados são armaze-
nados na forma de objetos. Esse é o único componente do Ceph que
escreve e lê os dados dos clientes. De forma geral, o número de OSDs
de um cluster representa o número total de discos físicos do mesmo
7
. A
recomendação é que cada OSD tenha, no mínimo, 1 CPU e 2GB de RAM
8
para que o mesmo tenha um desempenho satisfatório.
• RBD:
É uma interface construída sobre o librados, usada para armazenamento
de dados em blocos. Possui suporte à clientes do kernel Linux
9
, assim
como suporte aos drivers de virtualização do QEMU/KVM. Os blocos de
dados no Ceph são do tipo thin, podendo ser redimensionados e espa-
lhados em múltiplos OSDs do cluster.
O armazenamento em blocos é o modo mais comum de armazenar dados
de mídia rotativa, como discos, CDs, entre outros. Nesse tipo de cenário,
o RBD divide o dado a ser armazenado em várias partes de tamanho de-
finido
10
, que são armazenadas em vários OSDs do cluster como objetos.
7
Com o uso de SSDs NVMEs, para aproveitar o máximo do desempenho desses dispositivos,
é recomendado particionar o mesmo e, para cada partição, configurar um OSD.
8
Idealmente deveria possuir 4GB de RAM ou mais.
9
Release 2.6.37 do Linux e presente desde a release Dumpling, que foi a primeira release
oficial do Ceph
10
O padrão de tamanho dos blocos é de 4MiB, mas esse valor pode ser alterado.
17
Quando esses dados são necessários, as partes são recuperadas, conca-
tenadas e retornadas no formato de disco virtual.
A interação entre o RBD e os OSDs pode ser feita através do módulo KRBD
presente no kernel Linux, vide Figura 3, ou usando a biblioteca librbd, vide
Figura 4. O KRBD provê dispositivos de blocos para hosts Linux enquanto
que o librbd provê blocos de armazenamento para VMs.
Figura 3: Armazenamento em blocos com KRDB
18
Figura 4: Armazenamento em blocos com librbd
• RGW:
Componente que provê serviços de armazenamento de objetos do tipo
S3. Utiliza a biblioteca librgw para se comunicar com o librados, e dispo-
nibiliza uma API Restful com interfaces compatíveis com o Amazon S3 e
o OpenStack Swift. Possyí como recomendações mínimas de hardware 1
CPU, 1 GB de RAM e 5 GB de armazenamento.
19
Figura 5: Armazenamento em objetos com librgw
• CephFS:
Disponibiliza uma interface semelhante à POSIX, permitindo que os dados
sejam armazenados na forma de arquivos e diretórios como se fosse em
um sistema de arquivos normal. Utiliza o MDS para armazenar metada-
dos dos arquivos, como: hierarquia dos diretórios e arquivos, permissões
e outros. Os OSDs são utilizados para armazenar os dados. Caso o nú-
mero de MDS cresça, os metadados são divididos entre eles, de forma a
não existir um ponto único de falha.
1.2. CRUSH
É o algoritmo utilizado no RADOS para determinar a alocação dos dados no
cluster. Para tal, é necessário apenas ter o nome do objeto, o mapa do cluster e
o mapa CRUSH. Com esses dados, os clientes, assim como todos os nodos do
20
cluster, conseguem calcular em que local do cluster os dados serão escritos ou
lidos, e também em que local estão as cópias desses dados. Assim, inverte-se
o paradigma de gestão de alocação dos dados nos discos físicos do sistema de
arquivos para o cliente.
1.3. Mapas de Metadados
O Ceph mantém mapas para representar a topologia do cluster, sendo 6
tipos diferentes de mapas existentes:
1. Monitor Map:
Armazena o fsid do cluster, a posição, o nome do endereço e a porta de
cada monitor. Também indica a época
11
atual, quando o mapa foi criado
e a última vez que foi alterado. Para visualizar um mapa do monitor, basta
executar o comando:
~# ceph mon dump
dumped monmap epoch 1
epoch 1
fsid d5fde8a5-ad7e-4a96-8c23-f232c65a2828
last_changed 2022-07-27T12:46:03.496974+0000
created 2022-07-27T12:46:03.496974+0000
min_mon_release 15 (octopus)
0: [v2:192.168.122.240:3300/0,v1:192.168.122.240:6789/0] mon.vm1
1: [v2:192.168.122.241:3300/0,v1:192.168.122.241:6789/0] mon.vm2
2: [v2:192.168.122.242:3300/0,v1:192.168.122.242:6789/0] mon.vm3
2. Manager Map:
Contém as informações sobre os MGRs no cluster, a época dos mesmos,
quais são os MGRs ativos e de backup, os módulos disponíveis, entre ou-
tras informações, podendo ser visualizado através do comando:
~# ceph mgr dump
{
"epoch": 572,
"active_gid": 494143,
"active_name": "vm1",
"active_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.240:6802",
"nonce": 756
11
Épocas, nesse caso, indicam o estado dos mapas do cluster. Quando ocorre alguma altera-
ção nesses mapas, o contador de épocas é incrementado.
21
},
{
"type": "v1",
"addr": "192.168.122.240:6803",
"nonce": 756
}
]
},
"active_addr": "192.168.122.240:6803/756",
"active_change": "2022-12-19T18:08:18.113999+0000",
"active_mgr_features": 4540138292840890367,
"available": true,
"standbys": [
{
"gid": 494129,
"name": "vm2",
"mgr_features": 4540138292840890367,
"available_modules": [
{
...
}
}
],
"services": {
"dashboard": "https://vm1:8443/",
"prometheus": "http://vm1:9283/"
},
"always_on_modules": {
"nautilus": [
"balancer",
"crash",
"devicehealth",
"orchestrator_cli",
"progress",
"rbd_support",
"status",
"volumes"
],
"octopus": [
"balancer",
"crash",
"devicehealth",
"orchestrator",
"pg_autoscaler",
"progress",
"rbd_support",
"status",
"telemetry",
"volumes"
],
"last_failure_osd_epoch": 1388,
"active_clients": [
{
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.240:0",
"nonce": 3093442031
}
]
},
{
"addrvec": [
{
"type": "v2",
22
"addr": "192.168.122.240:0",
"nonce": 3209415801
}
]
},
{
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.240:0",
"nonce": 2307999958
}
]
},
{
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.240:0",
"nonce": 1149315182
}
]
}
]
}
}
3. OSD Map:
Contém o fsid do cluster, quando o mapa foi criado e modificado pela úl-
tima vez, uma lista de pools, tamanhos de réplicas, números de PGs, uma
lista de OSDs e seus status. Para visualizar um mapa OSD, basta executar
o comando:
~# ceph osd dump
epoch 521
fsid d5fde8a5-ad7e-4a96-8c23-f232c65a2828
created 2022-07-27T12:46:08.513211+0000
modified 2022-09-13T19:50:43.606946+0000
flags sortbitwise,recovery_deletes,purged_snapdirs,pglog_hardlimit
crush_version 19
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.85
require_min_compat_client jewel
min_compat_client jewel
require_osd_release octopus
pool 1 'device_health_metrics' replicated size 3 min_size 1 ... application mgr_devicehealth
pool 2 '.rgw.root' replicated size 3 min_size 1 ... application rgw
pool 3 'default.rgw.log' replicated size 3 min_size 1 ... application rgw
pool 4 'default.rgw.control' replicated size 3 min_size 1 ... application rgw
pool 5 'default.rgw.meta' replicated size 3 min_size 1 ... application rgw
pool 6 'metadata-ec' replicated size 3 min_size 1 ... stripe_width 0
pool 7 'acs-primary-storage' replicated size 3 min_size 1 ... stripe_width 0
max_osd 5
osd.0 up in weight 1 up_from 466 up_thru ... exists,up 8b6fadd9-0ca5-4b83-9f5e-b42397d8f555
osd.1 up in weight 1 up_from 466 up_thru ... exists,up 99818b4e-696c-4325-9d52-617a1960b76e
osd.2 up in weight 1 up_from 463 up_thru ... exists,up 9886b73e-6833-4654-a288-0d45eb2b9e1a
osd.3 up in weight 1 up_from 469 up_thru ... exists,up 20ed5c5f-0db6-4e05-8793-ecc39793e5fd
osd.4 up in weight 1 up_from 474 up_thru ... exists,up 01bad136-6797-4a2f-819c-5f620318444f
23
4. PG Map:
Contém a versão do PG, seu registro de data e hora, a última época do
mapa OSD, as proporções completas e detalhes de cada grupo de posi-
cionamento, como PG ID, Up Set
12
, Ativo, estado do PG e estatísticas de
uso de dados para cada pool. Para visualizar esse mapa, basta executar o
comando:
~# ceph pg dump
dumped all
version 260764
stamp 2022-09-15T12:05:12.462623+0000
last_osdmap_epoch 0
last_pg_scan 0
PG_STAT OBJECTS MISSING_ON_PRIMARY DEGRADED MISPLACED UNFOUND BYTES OMAP_BYTES* OMAP_KEYS*
LOG DISK_LOG STATE STATE_STAMP VERSION REPORTED UP UP_PRIMARY ACTING ACTING_PRIMARY
LAST_SCRUB SCRUB_STAMP LAST_DEEP_SCRUB DEEP_SCRUB_STAMP SNAPTRIMQ_LEN
...
7 25131 0 0 0 0 105205893449 74 8 76095 76095
6 0 0 0 0 0 0 0 0 0 0
5 2 0 0 0 0 393 0 0 4 4
4 8 0 0 0 0 0 0 0 159 159
3 207 0 0 0 0 3520 0 0 97968 97968
2 4 0 0 0 0 1289 0 0 8 8
1 0 0 0 0 0 0 0 0 0 0
sum 25352 0 0 0 0 105205898651 74 8 174234 174234
OSD_STAT USED AVAIL USED_RAW TOTAL HB_PEERS PG_SU M PRIMARY_PG_SUM
4 68 GiB 131 GiB 69 GiB 200 GiB [0,1,2,3] 113 44
3 51 GiB 148 GiB 52 GiB 200 GiB [0,1,2,4] 92 29
2 55 GiB 144 GiB 56 GiB 200 GiB [0,1,3,4] 96 33
1 52 GiB 147 GiB 53 GiB 200 GiB [0,2,3,4] 90 22
0 68 GiB 131 GiB 69 GiB 200 GiB [1,2,3,4] 116 41
sum 294 GiB 701 GiB 299 GiB 1000 GiB
5. CRUSH Map:
Contém uma lista de dispositivos de armazenamento, a hierarquia dos
domínios de falha (por exemplo: dispositivo, host, rack, linha, sala etc.) e
regras para percorrer a hierarquia ao armazenar dados.
Para visualizar um mapa CRUSH, os seguintes passos devem ser executa-
dos:
• Salvar o mapa em um arquivo binário:
ceph osd getcrushmap -o <filename>
12
Quais OSDs fazem parte desse PG
24
• Decompilar o binário:
crushtool -d <filename> -o <decompiled-crushmap-filename>
• Em seguida, basta ler o arquivo decompilado.
Por exemplo:
~# ceph osd getcrushmap -o crush
19
~# crushtool -d crush -o crush.txt
~# cat crush.txt
# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable chooseleaf_vary_r 1
tunable chooseleaf_stable 1
tunable straw_calc_version 1
tunable allowed_bucket_algs 54
# devices
device 0 osd.0 class hdd
device 1 osd.1 class hdd
device 2 osd.2 class hdd
device 3 osd.3 class hdd
device 4 osd.4 class hdd
# types
type 0 osd
type 1 host
type 2 chassis
type 3 rack
type 4 row
type 5 pdu
type 6 pod
type 7 room
type 8 datacenter
type 9 zone
type 10 region
type 11 root
# buckets
host dp1 {
id -3 # do not change unnecessarily
id -4 class hdd # do not change unnecessarily
# weight 0.195
alg straw2
hash 0 # rjenkins1
item osd.2 weight 0.195
}
host dp4 {
id -5 # do not change unnecessarily
id -6 class hdd # do not change unnecessarily
# weight 0.195
alg straw2
hash 0 # rjenkins1
item osd.3 weight 0.195
}
host dp3 {
id -7 # do not change unnecessarily
id -8 class hdd # do not change unnecessarily
25
# weight 0.195
alg straw2
hash 0 # rjenkins1
item osd.1 weight 0.195
}
host dp2 {
id -9 # do not change unnecessarily
id -10 class hdd # do not change unnecessarily
# weight 0.195
alg straw2
hash 0 # rjenkins1
item osd.0 weight 0.195
}
host dp5 {
id -11 # do not change unnecessarily
id -12 class hdd # do not change unnecessarily
# weight 0.195
alg straw2
hash 0 # rjenkins1
item osd.4 weight 0.195
}
root default {
id -1 # do not change unnecessarily
id -2 class hdd # do not change unnecessarily
# weight 0.976
alg straw2
hash 0 # rjenkins1
item dp1 weight 0.195
item dp4 weight 0.195
item dp3 weight 0.195
item dp2 weight 0.195
item dp5 weight 0.195
}
# rules
rule replicated_rule {
id 0
type replicated
min_size 1
max_size 10
step take default
step chooseleaf firstn 0 type host
step emit
}
# end crush map
6. MDS Map:
13
Contém a época atual do mapa MDS, quando o mapa foi criado e a úl-
tima vez que foi alterado. Ele também contém o pool para armazenar
metadados, uma lista de servidores de metadados e quais servidores de
metadados estão ativos e disponíveis, podendo ser visualizado com o co-
mando:
13
Esse mapa só é utilizado pelo CephFS.
26
~# ceph fs dump -f json-pretty
dumped fsmap epoch 2158
{
"epoch": 2158,
"default_fscid": 1,
"compat": {
"compat": {},
"ro_compat": {},
"incompat": {
"feature_1": "base v0.20",
"feature_2": "client writeable ranges",
"feature_3": "default file layouts on dirs",
"feature_4": "dir inode in separate object",
"feature_5": "mds uses versioned encoding",
"feature_6": "dirfrag is stored in omap",
"feature_8": "no anchor table",
"feature_9": "file layout v2",
"feature_10": "snaprealm v2"
}
},
"feature_flags": {
"enable_multiple": false,
"ever_enabled_multiple": false
},
"standbys": [
{
"gid": 494123,
"name": "vm3",
"rank": -1,
"incarnation": 0,
"state": "up:standby",
"state_seq": 2,
"addr": "192.168.122.242:6801/707167124",
"addrs": {
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.242:6800",
"nonce": 707167124
},
{
"type": "v1",
"addr": "192.168.122.242:6801",
"nonce": 707167124
}
]
},
"join_fscid": -1,
"export_targets": [],
"features": 4540138292840890367,
"flags": 0,
"epoch": 2153
}
],
"filesystems": [
{
"mdsmap": {
"epoch": 2158,
"flags": 18,
"ever_allowed_features": 0,
"explicitly_allowed_features": 0,
"created": "2022-11-21T13:48:01.119362+0000",
"modified": "2022-12-19T18:09:15.187797+0000",
"tableserver": 0,
27
"root": 0,
"session_timeout": 60,
"session_autoclose": 300,
"min_compat_client": "0 (unknown)",
"max_file_size": 1099511627776,
"last_failure": 0,
"last_failure_osd_epoch": 1389,
"compat": {
"compat": {},
"ro_compat": {},
"incompat": {
"feature_1": "base v0.20",
"feature_2": "client writeable ranges",
"feature_3": "default file layouts on dirs",
"feature_4": "dir inode in separate object",
"feature_5": "mds uses versioned encoding",
"feature_6": "dirfrag is stored in omap",
"feature_8": "no anchor table",
"feature_9": "file layout v2",
"feature_10": "snaprealm v2"
}
},
"max_mds": 1,
"in": [
0
],
"up": {
"mds_0": 494150
},
"failed": [],
"damaged": [],
"stopped": [],
"info": {
"gid_494150": {
"gid": 494150,
"name": "vm1",
"rank": 0,
"incarnation": 2154,
"state": "up:active",
"state_seq": 19,
"addr": "192.168.122.240:6801/401281360",
"addrs": {
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.240:6800",
"nonce": 401281360
},
{
"type": "v1",
"addr": "192.168.122.240:6801",
"nonce": 401281360
}
]
},
"join_fscid": -1,
"export_targets": [],
"features": 4540138292840890367,
"flags": 0
}
},
"data_pools": [
8
],
"metadata_pool": 9,
28
"enabled": true,
"fs_name": "cephfs",
"balancer": "",
"standby_count_wanted": 1
},
"id": 1
}
]
}
1.4. Pools
O Ceph armazena os dados em partições lógicas chamadas Pools, que po-
dem ser criadas e destruídas pelos administradores do cluster. Cada pool é
dividido em grupos de posicionamento, chamados de PGs, onde cada PG con-
tém fragmentos do objeto que representa o dado total.
1.5. Placement Groups
Os Placement Group (PGs) no Ceph são uma abstração lógica de um contai-
ner, que contém múltiplos objetos, sendo esse container mapeado para múlti-
plos OSDs. O número de PGs em um cluster Ceph pode ter impacto significativo
no desempenho e na capacidade de recuperação de falhas do cluster, conforme
ilustrado na Figura 6.
29
Figura 6: Uso de PGs
É possível que os OSDs façam parte de múltiplos placement groups. Além
disso, desde a release Mimic, é possível incrementar o número de PGs, mas
só a partir da release Nautilus passou a ser possível também realizar o decre-
mento dos mesmos. Ainda na Nautilus, foi introduzida a funcionalidade de pg-
autoscaling, que permite que o próprio Ceph faça recomendações do número
de PGs e até mesmo incremente ou diminua esse número, conforme o uso do
cluster.
É possível especificar o autoscaling para cada pool com o comando:
~$ ceph osd pool set <pool-name> pg_autoscale_mode <mode>
Ou habilitar globalmente essa funcionalidade:
~$ ceph config set global osd_pool_default_pg_autoscale_mode <mode>
Onde os modos possíveis para ambos os comandos são:
• off: desabilita o autoscaling para o pool;
30
• on: habilita o autoscaling para o pool, ou seja, permite ao Ceph definir o
tamanho das PGs do pool, assim como incrementá-las ou reduzi-las;
• warn: emite um alerta quando as PGs do pool precisam ser ajustadas.
Porém, é importante ressaltar que, ao alterar globalmente, apenas novos
pools irão aplicar o modo de autoscaling definido. Pools antigos, que estavam
utilizando outro modo, não serão afetados. Além disso, ao alterar o modo de
um pool, assim como ao incrementar ou diminuir seu número de PGs, caso
o pool já contenha dados, os mesmos serão movidos no cluster, o que é uma
operação cara.
A escolha do número adequado de PGs para o ambiente depende de vários
fatores, como tamanho do cluster, o número de OSDs, a quantidade de arma-
zenamento em uso e o desempenho desejado. Dicas gerais para determinar o
número apropriado de PGs incluem:
• Uma aproximação do número de PGs ideal para um pool pode ser cal-
culada como as possíveis combinações do conjunto de OSDs desse pool,
onde todos os OSDs são eleitos como OSD primário em pelo menos um
PG, isto é, um pool contendo 25 OSD s tem 600 possíveis combinações
(25*24), é uma boa pratica utilizar PGs multiplos de 2, logo recomenda-
se nesse caso, utilizar o número 512 como PG visto que é a potência de
2 mais próxima de 600. Dessa forma, é possível garantir que cada OSD
tenha uma carga equilibrada e possa se recuperar de falhas mais rapida-
mente
14
.
• Considere o tamanho total de armazenamento do cluster. Em clusters me-
nores, pode ser adequado usar um número menor de PGs, enquanto que
14
Algumas referências utilizam a fórmula abaixo para aproximar o valor ideal de PGs.
P Gs =
OSDs ∗ 100
num_replicas
31
para clusters maiores pode ser necessário aumentar o número de PGs
para garantir um desempenho adequado.
• A natureza dos dados também deve ser considerada. Dados como vídeos
de alta resolução ou grandes arquivos, podem se beneficiar de um nú-
mero maior de PGs, entretanto, pequenos arquivos (como arquivos de
logs) não precisam de um número grande de PGs.
• Monitore o desempenho do cluster e realizar ajustes conforme o necessá-
rio. Caso o desempenho do cluster estiver abaixo do esperado, aumentar
o número de PGs pode ajudar a melhorar o desempenho, entretanto, é
necessário atenção, pois um número grande de PGs requer mais recur-
sos computacionais no momento de calcular/determinar em qual PG um
bloco será persistido ou lido. Isso afeta o processo de interação com os
clientes e momentos de recovery.
Em resumo, a escolha do número adequado de PGs para um ambiente Ceph
pode exigir um pouco de experimentação e ajustes. Um número de PGs por
OSD baixo, pode levar a uma sobrecarga em alguns OSDs e uma menor eficiên-
cia na recuperação de falhas; um número de PGs por OSD alto, pode acarretar
na diminuição no desempenho geral do cluster. Portanto, a escolha do número
adequado de PGs por OSD deve considerar o tamanho do cluster, o número de
OSDs e a carga de trabalho, além de ser monitorado e ajustado conforme ne-
cessário. É importante considerar também outros fatores, como a utilização
do hardware, o tráfego de rede e as políticas de armazenamento para garantir
um desempenho ideal do cluster.
1.6. Redes do Ceph
A arquitetura de redes sugerida para o uso do Ceph consiste em duas redes:
• Rede pública:
Uma rede acessível para os clientes, que a irão utilizar para se comunicar
com os monitores e os OSDs, assim como a rede usada para gestão.
32
• Rede cluster
Uma rede isolada, que somente será utilizada pelos componentes do Ceph
para replicação dos dados recebidos, seja essa replicação realizada no
processo de escrita de um dado, ou no processo de recuperação de um
dado.
A Figura 7 apresenta a topologia das redes no Ceph.
Figura 7: Redes usadas no Ceph
1.7. Fluxo básico do Ceph
Com esses componentes explicados, os fluxos básicos utilizados pelo Ceph
são:
• Na escrita/leitura de um dado, vide Figuras 8 e 9:
1. O cliente solicita à um dos monitores os mapas de PGs, de OSDs e do
CRUSH do cluster;
2. Com esses dados, o cliente calcula qual será o PG e OSD primários
nos quais os dados serão escritos e envia os dados ao cluster;
33
3. Ao receber os dados, o OSD primário os escreve e consulta uma cópia
do mapa CRUSH para identificar em quais outros OSDs o dado será
escrito;
4. Com as réplicas calculadas, o OSD primário replica, via rede cluster,
o dado para os demais OSDs;
5. Após o dado ter sido corretamente replicado, o cliente recebe uma
confirmação de que a escrita finalizou com sucesso.
Figura 8: Fluxo Básico de Escrita
34
Figura 9: Fluxo Básico de Leitura/Escrita
• Na recuperação de um dado, vide Figuras 10 e 11:
1. Caso um dos OSDs apresente falha, o Ceph identifica tal falha e, com
base nos mapas do cluster, calcula quais dados estavam naquele OSD
que falhou, assim como em quais outros OSDs estão as réplicas de
tais dados;
2. Com essas informações é iniciado um processo de recuperação dos
dados, no qual os dados das réplicas são adicionados em outro OSD
e o mapa do cluster é atualizado com essa informação.
35
Figura 10: Fluxo Básico de Recuperação de Falhas
Figura 11: Fluxo Básico de Recuperação de Falhas
36
2. Uso e comandos básicos
Ao realizar o deploy de um cluster Ceph, é possível utilizar o CLI ceph para re-
alizar diversas operações no cluster. Esse CLI provê diversos subcomandos, que
permitem operar e gerenciar componentes como MONs, MGRs, OSDs, PGs,
MDSs, entre diversas outras operações de administração e gerência mais ge-
rais. A seguir estão alguns comandos básicos de uso do Ceph:
• Verificar estado do cluster:
~# ceph -s
cluster:
id: d5fde8a5-ad7e-4a96-8c23-f232c65a2828
health: HEALTH_WARN
mons are allowing insecure global_id reclaim
1 pool(s) do not have an application enabled
services:
mon: 3 daemons, quorum vm1,vm2,vm3 (age 31h)
mgr: vm1(active, since 5d), standbys: vm2
osd: 5 osds: 5 up (since 5d), 5 in (since 6d)
rgw: 1 daemon active (vm3.rgw0)
task status:
data:
pools: 7 pools, 169 pgs
objects: 25.35k objects, 98 GiB
usage: 299 GiB used, 701 GiB / 1000 GiB avail
pgs: 169 active+clean
• Verificar uso do cluster:
~# ceph df
--- RAW STORAGE ---
CLASS SIZE AVAIL USED RAW USED %RAW USED
hdd 1000 GiB 701 GiB 294 GiB 299 GiB 29.90
TOTAL 1000 GiB 701 GiB 294 GiB 299 GiB 29.90
--- POOLS ---
POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL
device_health_metrics 1 1 0 B 0 0 B 0 202 GiB
.rgw.root 2 32 1.3 KiB 4 768 KiB 0 202 GiB
default.rgw.log 3 32 3.4 KiB 207 6 MiB 0 202 GiB
default.rgw.control 4 32 0 B 8 0 B 0 202 GiB
default.rgw.meta 5 8 393 B 2 384 KiB 0 202 GiB
metadata-ec 6 32 0 B 0 0 B 0 202 GiB
acs-primary-storage 7 32 98 GiB 25.13k 294 GiB 32.63 202 GiB
• Listar os OSDs do cluster:
~# ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.97649 root default
37
-3 0.19530 host dp1
2 hdd 0.19530 osd.2 up 1.00000 1.00000
-9 0.19530 host dp2
0 hdd 0.19530 osd.0 up 1.00000 1.00000
-7 0.19530 host dp3
1 hdd 0.19530 osd.1 up 1.00000 1.00000
-5 0.19530 host dp4
3 hdd 0.19530 osd.3 up 1.00000 1.00000
-11 0.19530 host dp5
4 hdd 0.19530 osd.4 up 1.00000 1.00000
• Verificar detalhes de um OSD:
~# ceph osd find 2
{
"osd": 2,
"addrs": {
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.230:6800",
"nonce": 63981
},
{
"type": "v1",
"addr": "192.168.122.230:6801",
"nonce": 63981
}
]
},
"osd_fsid": "9886b73e-6833-4654-a288-0d45eb2b9e1a",
"host": "dp1",
"crush_location": {
"host": "dp1",
"root": "default"
}
}
• Listar pools:
~# ceph osd pool ls
device_health_metrics
.rgw.root
default.rgw.log
default.rgw.control
default.rgw.meta
metadata-ec
acs-primary-storage
• Verificar o estado dos pools:
~# ceph osd pool stats
pool device_health_metrics id 1
nothing is going on
pool .rgw.root id 2
nothing is going on
pool default.rgw.log id 3
nothing is going on
38
pool default.rgw.control id 4
nothing is going on
pool default.rgw.meta id 5
nothing is going on
pool metadata-ec id 6
nothing is going on
pool acs-primary-storage id 7
nothing is going on
• Realizar benchmark nos OSDs:
~# ceph tell osd.* bench
osd.0: {
"bytes_written": 1073741824,
"blocksize": 4194304,
"elapsed_sec": 1.5983376140000001,
"bytes_per_sec": 671786620.42048395,
"iops": 160.16641150009249
}
osd.1: {
"bytes_written": 1073741824,
"blocksize": 4194304,
"elapsed_sec": 1.4726374440000001,
"bytes_per_sec": 729128427.62132013,
"iops": 173.8377636960316
}
osd.2: {
"bytes_written": 1073741824,
"blocksize": 4194304,
"elapsed_sec": 1.6086810540000001,
"bytes_per_sec": 667467190.79592013,
"iops": 159.13657922647479
}
osd.3: {
"bytes_written": 1073741824,
"blocksize": 4194304,
"elapsed_sec": 3.2434518730000002,
"bytes_per_sec": 331049100.16958344,
"iops": 78.928256075282917
}
osd.4: {
"bytes_written": 1073741824,
"blocksize": 4194304,
"elapsed_sec": 3.9115396859999998,
"bytes_per_sec": 274506181.75832057,
"iops": 65.447373809414046
}
• Listar configurações do cluster:
~# ceph config dump
WHO MASK LEVEL OPTION VALUE RO
mgr advanced mgr/dashboard/ALERTMANAGER_API_HOST http://192.168.122.240:9093 *
mgr advanced mgr/dashboard/GRAFANA_API_PASSWORD <password> *
mgr advanced mgr/dashboard/GRAFANA_API_SSL_VERIFY false *
mgr advanced mgr/dashboard/GRAFANA_API_URL https://192.168.122.240:3000 *
mgr advanced mgr/dashboard/GRAFANA_API_USERNAME <password> *
mgr advanced mgr/dashboard/PROMETHEUS_API_HOST http://192.168.122.240:9092 *
39
mgr advanced mgr/dashboard/RGW_API_ACCESS_KEY <password> *
mgr advanced mgr/dashboard/RGW_API_HOST 192.168.122.242 *
mgr advanced mgr/dashboard/RGW_API_PORT 8080 *
mgr advanced mgr/dashboard/RGW_API_SCHEME http *
mgr advanced mgr/dashboard/RGW_API_SECRET_KEY <password> *
mgr advanced mgr/dashboard/RGW_API_USER_ID ceph-dashboard *
mgr advanced mgr/dashboard/server_port 8443 *
mgr advanced mgr/dashboard/ssl false *
mgr advanced mgr/dashboard/ssl_server_port 8443 *
mgr advanced mgr/dashboard/vm1/server_addr 192.168.122.240 *
mgr advanced mgr/selftest/rwoption1 1234 *
mgr advanced mgr/selftest/rwoption2 10 *
mgr advanced mgr/selftest/rwoption3 1.500000 *
mgr advanced mgr/selftest/rwoption4 foo *
mgr advanced mgr/selftest/rwoption5 false *
mgr advanced mgr/selftest/testkey <password> *
mgr advanced mgr/selftest/vm1/testkey <password> *
mgr advanced mgr/telemetry/contact <password> *
mgr advanced mgr/telemetry/interval 60 *
mgr advanced mgr/telemetry/leaderboard true *
• Listar o status completo do cluster:
~# ceph report
{
"cluster_fingerprint": "0ae735cb-de04-4d33-8c68-c62c9dcc8376",
"version": "15.2.17",
"commit": "8a82819d84cf884bd39c17e3236e0632ac146dc4",
"timestamp": "2022-12-21T16:10:15.769584+0000",
"tag": "",
"health": {
"status": "HEALTH_OK",
"checks": {},
"mutes": []
},
"monmap_first_committed": 1,
"monmap_last_committed": 1,
"monmap": {
"epoch": 1,
...
},
"paxos": {
"first_committed": 4992140,
"last_committed": 4992711,
"last_pn": 33701,
"accepted_pn": 34500
}
}
• Buscar os arquivos de logs dos componentes do Ceph:
– Logs dos Monitores:
São armazenados nos arquivos
/var/log/ceph/ceph-mon.<identificador>.log
40
– Logs dos Managers:
São armazenados nos arquivos
/var/log/ceph/ceph-mgr.<identificador>.log
– Logs dos OSDs:
São armazenados nos arquivos
/var/log/ceph/ceph-osd.<identificador>.log
2.1. ceph-volume
O subcomando ceph-volume é usado para gerenciar o armazenamento do
cluster, remover completamente
15
qualquer vestígio de um dispositivo de ar-
mazenamento específico, incluindo todos os metadados e partições. Útil quando
se deseja reutilizar um dispositivo para uma nova configuração de armazena-
mento, especialmente quando um dispositivo anteriormente usado foi adicio-
nado ao cluster Ceph. A lista abaixo contém os principais parâmetros utilizados
pelo subcomando ceph-volume.
• lvm: permite criar e gerenciar OSDs e dispositivos de armazenamento
baseados em LVM
16
;
• raw: permite criar e gerenciar OSDs e dispositivos de armazenamento
RAW
17
;
• zfs: permite criar e gerenciar OSDs e dispositivos de armazenamento ba-
seados em ZFS
18
;
• list: lista os dispositivos de armazenamento disponíveis no sistema;
15
O comando faz uso da função wipefs do sistema operacional para limpar as informações
de partição e sistema de arquivos, o que efetivamente apaga o disco.
16
Logical Volume Manager - método de alocação de espaço, no disco rígido de um sistema
Linux.
17
Armazenamento de dados que não possui nenhum tipo de sistema de arquivos ou orga-
nização de dados aplicada a ele.
18
Zettabyte File System sistema de arquivos projetado para ser altamente resistente a falhas.
41
• prepare: prepara um dispositivo de armazenamento para uso como um
OSD ou outro tipo de dispositivo de armazenamento;
• activate: ativa um dispositivo de armazenamento preparado;
• create: cria um novo OSD ou outro tipo de dispositivo de armazena-
mento.
• batch: permite a execução de comandos ceph-volume em lotes;
• lvm zap: opção que remove completamente os metadados e partições
de um dispositivo LVM. Caso o VG possua apenas um LVM durante a exe-
cução do comando, o VG também será removido.
Quando executado, ceph-volume lvm zap apaga todos os dados do disposi-
tivo especificado e prepara para uso em um novo pool ou cluster Ceph. Remove
os metadados de armazenamento e configurações de partição existentes, ga-
rantindo que não haja resquícios do dispositivo anterior, é necessário que o
dispositivo não esteja em uso ao executar o comando. Entretanto, é impor-
tante lembrar que trata-se de um comando destrutivo e irreversível, todos os
dados no dispositivo serão apagados permanentemente. Portanto, é essencial
ter certeza de selecionar o dispositivo correto antes de executar o comando.
Para apagar dispositivos de armazenamento baseados em LVM use o co-
mando abaixo.
~$ ceph-volume lvm zap {vg name/lv name}
O subcomando ceph-volume lvm zap também pode ser utilizado para apa-
gar partições inteiras.
~$ ceph-volume lvm zap /dev/sdcX
Ao utilizar o atributo --osd-id ou --osd-fsid
19
os operadores podem informar
respectivamente o ID de um dispositivo e/ou um osd-fsid de um OSD.
19
atributo exclusivo, usado para identificar o OSD em todo o cluster, gerado automatica-
mente pelo Ceph durante o processo de criação do OSD no cluster.
42
## Informando o ID de um dispositivo
~$ ceph-volume lvm zap --destroy --osd-id 1
## Informando o fsid de um cluster
~$ ceph-volume lvm zap --destroy --osd-fsid 5f9a1e79-6411-4e0b-814e-20f2de27bd12
## Informando ambos
~$ ceph-volume lvm zap --destroy --osd-fsid 5f9a1e79-6411-4e0b-814e-20f2de27bd12 --osd-id 1
43
Parte II
Formas de implantação
Esse capítulo abordará algumas das formas de realizar o deploy de um cluster
Ceph. Para tal, a versão do Ceph utilizada foi a Octopus e hosts com o sistema
operacional Ubuntu 20.04.
44
3. Formas de implantação
Existem diversas formas e ferramentas que permitem o deploy de um cluster
Ceph, sendo algumas delas:
• Deploy manual: envolve realizar, manualmente, o deploy de um cluster
Ceph. Através dessa abordagem, o operador pode definir cada detalhe
do cluster conforme sua necessidade, o que exige que o mesmo conheça
a fundo o funcionamento do Ceph. Porém, tal abordagem, além de ser
difícil de ser escalável em comparação com as outras alternativas, acaba
centralizando todo o conhecimento e capacidade de deploy do cluster em
uma pessoa ou grupo de pessoas
20
.
• ceph-ansible: solução “legada” que utiliza o Ansible para realizar o deploy.
Permite a automação do deploy do cluster, com a flexibilidade de parame-
trizações de acordo com a necessidade.
• cephadm: solução “sugerida” pela comunidade. Facilita o deploy do clus-
ter, com o uso de muitos “padrões”. Ofusca o que está sendo feito e não
permite, de forma fácil, ao operador muitas parametrizações específicas
durante o deploy.
• Rook: envolve o uso de Kubernetes, adicionando uma camada à mais de
software no deploy do cluster, o que aumenta consideravelmente a com-
plexidade de gerência do mesmo.
• Soluções pagas: facilitam ao extremo o deploy do cluster, aplicando confi-
gurações consideradas “ideais”, geralmente utilizando uma interface grá-
fica e aplicação restrita. Acabam prendendo o cliente à solução.
Neste documento, serão abordadas as alternativas de deploy manual, ceph
-ansible e cephadm.
20
Caso o processo inteiro de deploy não seja bem documentado.
45
4. Deploy manual
É possível realizar o deploy manual de um cluster Ceph. Os componentes
básicos de um cluster Ceph são:
• fsid: identificador (UUID) único para o cluster;
• Nome do cluster: nome simples, sem espaços, que deve ter o valor ceph
21
;
• Nome do MON: cada MON no cluster deve ter um nome único. Geral-
mente esse nome é o hostname do host;
• Mapa do MON: ao criar o(s) MON(s) inicial(is) requer gerar um mapa do
MON. Esse mapa requer o fsid, o nome do cluster e ao menos um host-
name e IP.
• Chaves do MON: os MONs se comunicam com os outros via chave secreta.
Ao criar o MON inicial, o mesmo precisa ter suas chaves informadas;
• Chave do administrador: para usar as ferramentas de CLI do Ceph, é ne-
cessário criar um usuário client.admin, junto com sua chave
Os passos necessários para o deploy manual são:
1. Realizar o deploy dos MONs:
(a) Realizar o login no host que será o MON inicial:
ssh <user>@<ip>
É importante ressaltar que tal usuário precisará ter permissões de
instalação de pacotes.
21
De acordo com a documentação, esse nome pode ser alterado, porém, em testes internos,
ao utilizar nomes diferentes, devido à diversas partes do código-fonte do Ceph ter o valor desse
nome hardcoded, diversas funcionalidades passaram a apresentar bugs. Dito isso, a equipe da
SC Clouds recomenda fortemente que seja mantido o nome ceph.
46
Figura 12: Acessando o host
(b) Baixar os pacotes necessários em tal host:
No sistema operacional Ubuntu 20.04, tais pacotes são ceph, ceph-co
mmon, ce p h-base, ceph -m o n , ceph-os d , ceph-mg r . Instalando o pa-
cote ceph irá instalar as demais dependências. Para outros sistemas
operacionais, consulte o repositório da distribuição.
47
Figura 13: Pacotes a serem instalados no host
Com essa instalação, será criado automaticamente o diretório /etc/c
eph:
Figura 14: Diretório criado no host
(c) Crie o arquivo de configuração do cluster:
Tal arquivo fica em /etc/ceph/ceph.con f e deve possuir a seguinte
estrutura básica:
[global]
fsid = {fsid}
48
cluster = {cluster-name}
mon host = {ip-address}[,{ip-address}]
mon initial members = {hostname}[,{hostname}]
Sendo que o fsid deve ser gerado com o comando uuidgen:
Figura 15: fsid gerado
Segue exemplo de configuração:
[global]
fsid = c898c04b-5243-441a-9be1-dbae8e89ad55
mon host = 192.168.10.11
mon initial members = ceph-mon01
(d) Criar um par de chaves para o cluster e a chave secreta para o MON:
ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *
'
Figura 16: Criar chaves do MON
(e) Criar o usuário admin e gerar suas chaves:
ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring --gen-key -n client.
admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *' --cap mgr 'allow *
'
Figura 17: Criar chaves do admin
49
(f) Criar usuário e chave para bootstrap dos OSDs
22
:
ceph-authtool --create-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring --gen-key -n
client.bootstrap-osd --cap mon 'profile bootstrap-osd' --cap mgr 'allow r'
Figura 18: Criar chaves dos OSDs
(g) Adicione as chaves geradas para o ceph.mon.keyring:
ceph-authtool /tmp/ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
ceph-authtool /tmp/ceph.mon.keyring --import-keyring /var/lib/ceph/bootstrap-osd/ceph.
keyring
Figura 19: Importar as chaves criadas
(h) Alterar o dono do arquivo ceph.mon.keyring:
chown ceph:ceph /tmp/ceph.mon.keyring
Figura 20: Alterar o dono do arquivo
(i) Gerar o mapa do MON usando o hostname, IP e fsid, salvando tal
mapa em /tmp/monmap:
22
Serão utilizados posteriormente na adição dos OSDs.
50
monmaptool --create --add {hostname} {ip-address} --fsid {uuid} /tmp/monmap
Figura 21: Criando o mapa do MON
(j) Criar o diretório padrão para os MONs:
sudo -u ceph mkdir -p /var/lib/ceph/mon/{cluster-name}-{hostname}
Figura 22: Criar o diretório padrão do MON
(k) Popule o serviço do MON com o mapa criada e as chaves:
ceph-mon [--cluster {cluster-name}] --mkfs -i {hostname} --monmap /tmp/monmap --keyring /
tmp/ceph.mon.keyring
Figura 23: Populando o serviço do MON
(l) Altere o arquivo de configuração do cluster contido em /etc/ceph/ce
ph.conf. Algumas sugestões são:
[global]
fsid = {cluster-id}
cluster = {cluster-name}
mon initial members = {hostname}[, {hostname}]
mon host = {ip-address}[, {ip-address}]
public network = {network}[, {network}]
cluster network = {network}[, {network}]
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
osd journal size = {n}
osd pool default size = {n}
osd pool default min size = {n}
Por exemplo:
51
Figura 24: Arquivo de configuração
(m) Inicie o MON:
i. Habilite o serviço e o inicie usando o systemd:
systemctl enable ceph-mon@<hostname>
systemctl start ceph-mon@<hostname>
Figura 25: Habilitando e iniciando o serviço do MON
ii. Habilitar as portas necessárias para o serviço:
firewall-cmd --zone=public --add-service=ceph-mon
firewall-cmd --zone=public --add-service=ceph-mon --permanent
Figura 26: Configurando o firewall
(n) Verificar se o MON está rodando:
ceph -s
52
Figura 27: MON rodando
(o) Repetir os passos para os demais MONs:
Aqui deve-se copiar os arquivos /etc/ceph/ceph.conf e /etc/ceph/cep
h.client.admin.keyring para os demais MONs.
2. Realizar o deploy dos MGRs:
Considerando que o MGR esteja no mesmo host no qual foi realizado o
deploy do MON e, portanto, já tenha os arquivos /etc/ceph / ceph.conf e /
etc/ceph/ceph.client.admin.keyring, assim como os pacotes instalados:
(a) Criar o diretório padrão para armazenar as chaves do MGR:
sudo -u ceph mkdir -p /var/lib/ceph/mgr/{cluster-name}-{hostname}
Figura 28: Criando o diretório padrão do MGR
53
(b) Criar a chave de autenticação do MGR e a coloque no diretório criado,
em um arquivo chamado keyring:
ceph auth get-or-create mgr.$name mon 'allow profile mgr' osd 'allow *' mds 'allow *' -o
/var/lib/ceph/mgr/{cluster-name}-{hostname}/keyring
Figura 29: Criando a chave de autenticação do MGR
(c) Ative o MGR:
ceph-mgr -i {hostname}
Figura 30: Ativar o MGR
(d) Habilite os serviços:
systemctl enable ceph-mgr.target
systemctl enable ceph-mgr@{hostname}
systemctl start ceph-mgr@{hostname}
54
Figura 31: Habilitar os serviços
3. Realizar o deploy dos OSDs:
(a) Realizar o login no host alvo, e instalar os pacotes necessários:
ssh root@<ip|name>
apt install ceph ceph-osd
Figura 32: Instalando os pacotes do OSD
(b) Copiar os arquivos /var/lib/ceph/bootstrap-osd/ceph.keyring, /etc/ce
ph/ceph.conf e /etc/ceph/ceph.client.admin.keyring de um dos MONs
55
já realizado o deploy para o host alvo
23
:
scp /var/lib/ceph/bootstrap-osd/ceph.keyring root@<osd-ip|osd-name>:/var/lib/ceph/
bootstrap-osd/ceph.keyring
scp /etc/ceph/ceph.conf root@<osd-ip|osd-name>:/etc/ceph
scp /etc/ceph/ceph.client.admin.keyring root@<osd-ip|osd-name>:/etc/ceph
Figura 33: Copiando os arquivos necessários para o OSD
(c) Retornar para o OSD alvo e criar o OSD:
ceph-volume lvm create --data /dev/<device>
23
Que atuará como OSD.
56
Figura 34: Criando o volume do OSD
(d) Listar os volumes do cluster, para ativar o OSD recém-criado:
ceph-volume lvm list
57
Figura 35: Listar todos os volumes do cluster
(e) Com as informações do osd id e osd fsid, ative o OSD:
ceph-volume lvm activate {osd-id} {osd-uuid}
Figura 36: Ativar o OSD
(f) Cheque o estado do cluster e verifique que o OSD foi corretamente
adicionado:
ceph -s
58
Figura 37: Verificar o estado do cluster
(g) Repita para os demais OSDs do cluster
4. Realizar o deploy dos MDSs:
(a) Realizar o login no host alvo, e instalar os pacotes necessários:
ssh root@<ip|name>
apt install ceph ceph-mds
59
Figura 38: Instalar os pacotes do MDS
(b) Copiar os arquivos /et c / c eph/ceph.conf e /etc/ceph/ceph.clie n t . a dm
in.keyring de um dos MONs já realizado o deploy para o host alvo
24
:
scp /etc/ceph/ceph.conf root@<mds-ip|mds-name>:/etc/ceph
scp /etc/ceph/ceph.client.admin.keyring root@<mds-ip|mds-name>:/etc/ceph
Figura 39: Copiar os arquivos necessários para o MDS
(c) No MDS alvo, criar o diretório padrão de dados:
sudo -u ceph mkdir -p /var/lib/ceph/mds/{cluster-name}-{hostname}
24
Que atuará como MDS.
60
Figura 40: Criar o diretório padrão do MDS
(d) Criar as chaves de autenticação do MDS:
ceph-authtool --create-keyring /var/lib/ceph/mds/{cluster-name}-{hostname}/keyring --gen-
key -n mds.{hostname}
Figura 41: Criar as chaves de autenticação do MDS
(e) Importar as chaves e criar as permissões no Ceph:
ceph auth add mds.{hostname} osd "allow rwx" mds "allow *" mon "allow profile mds" -i /
var/lib/ceph/mds/{cluster}-{hostname}/keyring
Figura 42: Importando as chaves do MDS para o cluster
(f) Inicie o MDS manualmente:
ceph-mds --cluster {cluster-name} -i {hostname} -m {mon-ip|mon-hostname}
Figura 43: Iniciando o MDS
(g) Cheque o estado do cluster:
ceph -s
61
Figura 44: Checando o estado do cluster
62
5. ceph-ansible
O Ansible é uma ferramenta open-source para automação de processos,
como gerenciamento de configurações, instalação de aplicativos, orquestração
intra-serviços e outros. Todo esse processamento é centralizado em um único
nodo, no qual todas as instruções são executadas a partir de uma máquina
de controle que se comunica com clientes remotos via SSH (outros protocolos
também são suportados). As definições de quais instruções serão executadas
são escritas em um arquivo YAML e podem ser extremamente granulares, a
fim de descrever e configurar um sistema como um todo.
Existe um repositório no GitHub, acessível através desse link, que utiliza o
Ansible para realizar o deploy de um cluster Ceph, podendo ser feito o deploy
usando containers docker ou hosts físicos.
5.1. Deploy
Para utilizá-lo para realizar o deploy do Ceph, o procedimento a ser realizado
é:
1. Clonar o repositório para o host/VM que irá ser utilizado para realizar o
deploy:
git clone https://github.com/ceph/ceph-ansible.git
2. Navegar até o repositório clonado e realizar o checkout para uma das
tags compatíveis com o SO dos hosts que irão atuar como monitores do
Ceph. Informações de compatibilidade podem ser encontradas nesse
link. Nessa documentação foi utilizada a versão v5.0.12:
cd ceph-ansible
git checkout v5.0.12
3. Criar um virtualenv e instalar as dependências necessárias com o pip:
python -m venv env
source env/bin/activate
pip install -r requirements.txt
63
4. Na pasta group_vars, que armazena exemplos de módulos a serem ins-
talados e configurados, remover o sufixo .sample de todos os arquivos e,
na raíz do projeto, realizar o mesmo procedimento nos arquivos site.yml
.sample site-docker.yml.sample;
5. Editar o arquivo group_vars/all.yml, responsável pelas configurações glo-
bais do cluster, adicionando as configurações desejadas. Abaixo segue um
exemplo de configuração aplicável de deploy em hosts físicos:
ceph_origin: repository
ceph_repository: community
ceph_stable: true
cephx: true
monitor_interface: <interface usada pelos monitores>
journal_size: 5120
public_network: rede/máscara
cluster_network: rede/máscara
osd_mkfs_type: ext4
radosgw_interface: <interface usada pelo radosgw>
ceph_conf_overrides:
global:
osd pool default size: 3
osd pool default size: 2
osd pool default min size: 1
grafana_admin_user: <grafana user>
grafana_admin_password: <grafana password>
dashboard_admin_password: <dashboard password>
Caso opte-se por realizar o deploy em containers, deve-se adicionar e/ou
alterar as seguintes entradas para os seguintes valores:
# A opção containerized_deployment determina se será utiliza ou não
# containers no deploy do Ceph
containerized_deployment: true
ceph_docker_image: "ceph/daemon"
# A tag utilizada deve ser alterada para a desejada
ceph_docker_image_tag: latest-${versão-desejada}
ceph_docker_registry: docker.io
6. Editar o arquivo group_vars/osds.yml, que é o responsável por configurar
os OSDs do cluster, de acordo com as configurações desejadas. Abaixo
segue um exemplo de configuração aplicável:
devices:
- /dev/sdb
- /dev/sdc
- /dev/sdd
- /dev/sde
- /dev/sdf
- /dev/sdg
64
osd_auto_discovery: false
osds_per_device: 1
É recomendável alterar a configuração osd_auto_discovery para false, de
forma a evitar que o Ceph considere discos que o operador possa ter ou-
tra finalidade como blocos disponíveis.
7. Na raíz do projeto, editar o arquivo inventory. Caso esse arquivo não
exista, o mesmo deve ser criado. Tal arquivo é responsável por mapear
os monitores, OSDs, clientes e MGRs existentes no cluster, além da fer-
ramenta utilizada para comunicação entre os nodos
25
e o usuário que
executará os comandos nos hosts
26
. Abaixo segue um exemplo de confi-
guração aplicável:
[mons]
vm1 ansible_connection=ssh ansible_ssh_user=root
vm2 ansible_connection=ssh ansible_ssh_user=root
vm3 ansible_connection=ssh ansible_ssh_user=root
[osds]
dp1 ansible_connection=ssh ansible_ssh_user=root
dp2 ansible_connection=ssh ansible_ssh_user=root
dp3 ansible_connection=ssh ansible_ssh_user=root
dp4 ansible_connection=ssh ansible_ssh_user=root
dp5 ansible_connection=ssh ansible_ssh_user=root
[grafana-server]
vm1 ansible_connection=ssh ansible_ssh_user=root
[clients]
client-1 ansible_connection=ssh ansible_ssh_user=root
[mgrs]
vm1 ansible_connection=ssh ansible_ssh_user=root
[mdss]
vm3 ansible_connection=ssh ansible_ssh_user=root
vm1 ansible_connection=ssh ansible_ssh_user=root
[rgws]
vm3 ansible_connection=ssh ansible_ssh_user=root
vm2 ansible_connection=ssh ansible_ssh_user=root
[iscsigws]
iscsi1 ansible_connection=ssh ansible_ssh_user=root
iscsi2 ansible_connection=ssh ansible_ssh_user=root
[nfss]
25
Tipicamente o SSH, embora seja possível utilizar outros protocolos.
26
Tipicamente é utilizado o usuário root.
65
vm2 ansible_connection=ssh ansible_ssh_user=root
vm1 ansible_connection=ssh ansible_ssh_user=root
Onde o nome anterior a cada ansible_connection representa os IPs dos
respectivos hosts na interface do clus t er _ n et w o rk . Dessa forma, é neces-
sário alterar o arquivo /etc/hosts, mapeando cada um desses nomes, ou
utilizar um sistema de DNS interno para resolver os mesmos. Um exem-
plo de configuração via arquivo /etc/hosts é:
192.168.122.230 dp1
192.168.122.231 dp2
192.168.122.232 dp3
192.168.122.233 dp4
192.168.122.234 dp5
192.168.122.240 vm1
192.168.122.241 vm2
192.168.122.242 vm3
192.168.122.243 iscsi1
192.168.122.244 iscsi2
8. Por fim, com todas as configurações realizadas, basta executar o playbook
com um dos seguintes comandos:
• Caso tenha sido utilizado o deploy em hosts físicos:
ansible-playbook -i inventory site.yml
• Caso tenha sido utilizado o deploy em containers:
ansible-playbook -i inventory site-docker.yml
Em ambos os cenários, caso o procedimento finalize com sucesso, será
exibida uma saída semelhante a da Figura 45.
66
Figura 45: Finalização do deploy do Ceph
Em situações específicas pode ser necessário executar o deploy para um
grupo limitado de daemons ou hosts (mons, osds, mrgs, Gateways). Para tanto,
basta informar a flag -l (–limit) seguido do(s) grupo(s) de daemons/gateways/hosts
que se deseja realizar o deploy: ansible-playbook -i inventory site.yml -l osds.
5.2. Remoção do cluster
Caso deseje-se remover totalmente o cluster, caso tenha sido realizado o
deploy com containers, pode-se utilizar o comando
27
:
ansible-playbook -i inventory infrastructure-playbooks/purge-container-cluster.yml
Para deploys em hosts físicos, o comando utilizado é:
ansible-playbook -i inventory infrastructure-playbooks/purge-cluster.yml
5.3. Atualização do cluster
Pode-se utilizar o Ansible também para realizar o upgrade de um cluster
Ceph com o comando:
ansible-playbook -i inventory infrastructure-playbooks/rolling_update.yml
27
Essa opção apenas remove o cluster Ceph e o docker, mas a rede bridge criada pelo Docker,
geralmente docker0, é apenas inativada, devendo ser removida manualmente pelo operador.
67
6. Cephadm
O cephadm é um utilitário, introduzido na versão v15.2.0 (Octopus)
28
, que
permite a gerência de um cluster Ceph. Ele pode ser utilizado para gerenciar
todo o ciclo de vida de um cluster Ceph. O ciclo inicia com o deploy de um clus-
ter Ceph com apenas um nó
29
, o qual pode ser expandido, adicionando novos
hosts, daemons e serviços, além de também ser possível atualizar ou destruir o
cluster.
Todas essas operações podem ser realizadas via CLI ou via dashboard. Há
de se mencionar que todos os componentes do cluster são containers Docker.
6.1. Deploy
Para realizar o deploy utilizando o cephadm, os passos necessários são:
1. Instalar o cephadm: Existem duas formas de instalar o cephadm:
• Via curl:
– Inicialmente, deve-se realizar o download do script do cephadm
de acordo com a versão do Ceph desejada:
curl --silent --remote-name --location https://github.com/ceph/ceph/raw/<version>/
src/cephadm/cephadm
Figura 46: Baixando o script do cephadm
– Em seguida, o script deve ser convertido em executável:
chmod +x cephadm
Figura 47: Tornando o script executável
28
Versões mais antigas não suportam o uso do cephadm.
29
Um MON e um MGR.
69
– Utilizar o script para realizar o download dos demais pacotes do
cephadm, de acordo com a versão desejada do Ceph:
./cephadm add-repo --release <name>
./cephadm install
Figura 48: Adicionando os pacotes da versão desejada do Ceph
– Confirme que o cephadm está corretamente instalado com o co-
mando which, que deve retornar o resultado /usr/s bin/cephadm
:
Figura 49: Verificando a instalação do cephadm
⋆ Opcionalmente, pode-se realizar o download do pacote ce ph-co
mmon, de forma a facilitar o uso do cluster Ceph, como o uso de
rbd, mount.ceph, entre outros:
cephadm install ceph-common
Figura 50: Adicionando o pacote ceph-common
• Via pacotes da distribuição: De acordo com a distribuição utilizada,
o pacote cephadm pode ser instalado diretamente dos repositórios
da distribuição adotada.
70
Figura 51: Instalando o cephadm via repositórios da distribuição
71
Em ambos os cenários, o download do cephadm deve ser realizado dire-
tamente em um dos nós que atuará como MON/MGR do cluster.
2. Realizar o deploy inicial do cluster:
Em um dos hosts que fará parte do cluster Ceph, preferencialmente um
que atuará como MON e/ou MGR, deve-se executar o comando:
cephadm bootstrap --mon-ip <mon-ip>
Onde <mon-ip> deve ser alterado para o IP do nó na rede que será a cep
h-public. Tal comando irá executar as seguintes alterações:
(a) Criar dois daemons, um MON e um MGR, no nó local
30
;
(b) Criar um novo par de chaves SSH que serão utilizadas no cluster Ceph,
e adicionar tal chave no arquivo /root/.ssh/authorized_keys do nó
local;
(c) Criar uma cópia da chave pública criada anteriormente para o ar-
quivo /etc/ceph/ceph.pub
(d) Criar uma configuração mínima de um cluster Ceph no arquivo /etc/
ceph/ceph.conf. Por exemplo:
# minimal ceph.conf for 1f238848-62c2-11ee-b057-4d76b22c4aac
[global]
fsid = 1f238848-62c2-11ee-b057-4d76b22c4aac
mon_host = [v2:10.100.2.11:3300/0,v1:10.100.2.11:6789/0]
(e) Criar uma cópia do client.admin para /etc/ceph/ceph.client. admin.k
eyring do nó local
30
localhost, já que o cephadm não permite, no bootstrap de um cluster, informar o IP de outro
host.
72
Figura 52: Realizando o deploy inicial do cluster
73
Figura 53: Containeres criados por padrão no bootstrap
Figura 54: Informações do cluster criado inicialmente no bootstrap
3. Adicionar os demais hosts que fazem parte do cluster:
Para tal, os passos necessários são:
(a) Copiar a chave pública gerada no bootstrap inicial para os demais
hosts:
ssh-copy-id -f -i /etc/ceph/ceph.pub root@<new-host>
74
Figura 55: Copiando a chave para os demais hosts
(b) Adicionar os hosts ao cluster:
ceph orch host add <hostname> <ip-ceph-public>
Figura 56: Adicionando novos hosts
75
(c) Listar os hosts adicionados ao cluster
31
:
ceph orch host ls
Figura 57: Listando os novos hosts
4. Configurar as redes:
Uma vez que todos os hosts tenham sido adicionados, pode-se configurar
as redes ceph-public e ceph-cluster com os comandos:
ceph config set global cluster_network <network>/<mask>
ceph config set mon public_network <network>/<mask>
5. Configurar os hosts que serão MONs do cluster:
ceph orch host label add <hostname> mon
ceph orch apply mon label:mon
31
Aqui apenas os hosts foram adicionados, sem informar qual papel esses hosts terão no
cluster (OSDs, MONs, MGRs, entre outros).
76
Figura 58: Adicionando os MONs
6. Configurar os hosts que serão OSDs do cluster:
ceph orch host label add <hostname> osd
77
Figura 59: Adicionando os OSDs
7. Listando os devices disponíveis e os formatando como OSDs:
ceph orch device ls
ceph orch apply osd --all-available-devices
Figura 60: Listando os discos disponíveis para usar como OSDs
78
Figura 61: Criando os OSDs
79
Parte III
Dashboard e orchestrator
O presente capítulo detalha o uso do dashboard web do Ceph, assim como o
uso do módulo orchestrator.
80
7. Dashboard
Utilizando Ceph, a partir da versão Luminous(12.2.0), é possível habilitar um
dashboard web, que vem embutido junto ao MGR, podendo ser utilizado para
gerenciar e visualizar o cluster Ceph de modo mais amigável.
Para verificar se o mesmo está habilitado, pode-se utilizar o comando:
root@client:~# ceph mgr services
{
"dashboard": "https://<ip>:8443/"
}
Caso seja verificado que o módulo do dashboard está desabilitado, pode-se
habilitá-lo com o comando:
root@client:~# ceph mgr module enable dashboard
Por padrão, o dashboard irá utilizar o IP do MGR ativo no momento, assim
como irá utilizar o protocolo HTTPS e a porta 8443. Para verificar qual é o ativo
no momento, pode-se utilizar o comando:
root@client:~# ceph -s
cluster:
id: <id>
health: HEALTH_OK
services:
mon: 3 daemons, quorum vm1,vm2,vm3 (age 7h)
mgr: vm1(active, since 43h), standbys: vm2
# Aqui pode-se verificar qual o MGR ativo
A Figura 62 exibe a página inicial desse dashboard.
81
Figura 62: Dashboard do Ceph
Caso o operador não deseje utilizar HTTPS, o mesmo pode ser desabilitado
com o comando ceph config set mgr mgr/dashboard/ssl false. Nesse cenário,
a porta padrão utilizada para acesso ao dashboard passará a ser a 8080. Além
disso, o operador também pode realizar configurações do dashboard, como:
• Gerar certificado SSL auto-assinado:
root@client:~# ceph dashboard create-self-signed-cert
Esse comando irá criar e utilizar automaticamente um certificado auto-
assinado para acesso ao dashboard via protocolo HTTPS. Porém, deve-se
ressaltar que, por ser um certificado autoassinado, a maioria dos nave-
gadores irá exigir a aprovação explícita do usuário antes de estabelecer a
conexão.
• Utilizar um certificado SSL válido:
82
Caso o operador possua um certificado SSL válido, o mesmo pode ser
adicionado ao dashboard com os comandos:
root@client:~# ceph dashboard set-ssl-certificate -i valid-certificate.crt
root@client:~# ceph dashboard set-ssl-certificate-key -i certificate-key.key
Além disso, também é possível atribuir um certificado diferente para cada
MGR do cluster bastando informar o nome
32
de cada MGR nos comandos:
root@client:~# ceph dashboard set-ssl-certificate mgr1 -i valid-certificate.crt
root@client:~# ceph dashboard set-ssl-certificate-key mgr1 -i certificate-key.key
root@client:~# ceph dashboard set-ssl-certificate mgr2 -i valid-certificate2.crt
root@client:~# ceph dashboard set-ssl-certificate-key mgr2 -i certificate-key2.key
• Configurar o IP e portas do dashboard:
root@client:~# ceph config set mgr mgr/dashboard/server_addr <ip>
root@client:~# ceph config set mgr mgr/dashboard/server_port <porta>
root@client:~# ceph config set mgr mgr/dashboard/ssl_server_port <porta>
Caso exista mais de um MGR, pode-se configurar cada um dos MGRs se-
paradamente:
root@client:~# ceph config set mgr mgr/dashboard/<mgr-identificador>/server_addr <ip>
root@client:~# ceph config set mgr mgr/dashboard/<mgr-identificador>/server_port <porta>
root@client:~# ceph config set mgr mgr/dashboard/<mgr-identificador>/ssl_server_port <porta>
7.1. Chamadas para a API do MGR
O manager possuí embutido, além da interface web, uma API Restful, cujos
endpoints podem ser obtidos e testados via dashboard, vide Figuras 63 e 64, ou
através da URL http[s ]:// <ip-do-mgr-ativo>:[8443|80 80]/docs. Através dessa
API Restful, é possível realizar diversas chamadas para o cluster Ceph, de forma
a poder monitorar o ambiente. Como as possibilidades de chamadas para as
APIs do manager são extensas, não iremos nos aprofundar muito nas mesmas.
32
Geralmente o hostname
83
Figura 63: Acessando a API do dashboard
Figura 64: Documentação da API do manager
Alguns exemplos de chamadas possíveis são:
1. Gerar o token de autenticação de um usuário:
curl -X POST "http[s]://<ip-do-mgr-ativo>:[8443|8080]/api/auth" -H "accept: */*" \
-H "Content-Type: application/json" -d "{\"username\":\"admin\",\"password\":\"hidden\"}"
{
"token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
eyJpc3MiOiJjZXBoLWRhc2hib2FyZCIsImp0aSI6IjlkZDl
mZDMwLTkyNzktNDA4Mi1iNjJiLTY5MGZmY2U5ZmYzYSIsImV4cCI6MTY4MTc2NzY2NCwiaWF0IjoxNjgxNzM4ODY0LCJ1
c2VybmFtZSI6ImFkbWluIn0.GMwQNp-o7TskVTaoxSu491WHEM-PdJKHB7Uc4rS0lR8",
"username": "admin",
"permissions": {
"cephfs": [
84
"create",
"delete",
"read",
"update"
],
"config-opt": [
"create",
"delete",
"read",
"update"
],
"dashboard-settings": [
"create",
"delete",
"read",
"update"
],
"grafana": [
"create",
"delete",
"read",
"update"
],
"hosts": [
"create",
"delete",
"read",
"update"
],
"iscsi": [
"create",
"delete",
"read",
"update"
],
"log": [
"create",
"delete",
"read",
"update"
],
"manager": [
"create",
"delete",
"read",
"update"
],
"monitor": [
"create",
"delete",
"read",
"update"
],
"nfs-ganesha": [
"create",
"delete",
"read",
"update"
],
"osd": [
"create",
"delete",
"read",
"update"
],
85
"pool": [
"create",
"delete",
"read",
"update"
],
"prometheus": [
"create",
"delete",
"read",
"update"
],
"rbd-image": [
"create",
"delete",
"read",
"update"
],
"rbd-mirroring": [
"create",
"delete",
"read",
"update"
],
"rgw": [
"create",
"delete",
"read",
"update"
],
"user": [
"create",
"delete",
"read",
"update"
]
},
"pwdExpirationDate": null,
"sso": false,
"pwdUpdateRequired": false
}
2. Listar todas as configurações possíveis do cluster:
curl -H "Authorization: Bearer <token>" -X GET
"http[s]://<ip-do-mgr-ativo>:[8443|8080]/api/cluster_conf" -H "accept: */*"
{
"name": "admin_socket",
"type": "str",
"level": "advanced",
"desc": "path for the runtime control socket file, used by the 'ceph daemon' command",
"long_desc": "",
"default": "",
"daemon_default": "$run_dir/$cluster-$name.asok",
"tags": [],
"services": [
"common"
],
"see_also": [],
"enum_values": [],
"min": "",
"max": "",
"can_update_at_runtime": false,
86
"flags": [
"startup"
]
},
{
"name": "admin_socket_mode",
"type": "str",
"level": "advanced",
"desc": "file mode to set for the admin socket file, e.g, '0755'",
"long_desc": "",
"default": "",
"daemon_default": "",
"tags": [],
"services": [
"common"
],
"see_also": [
"admin_socket"
],
"enum_values": [],
"min": "",
"max": "",
"can_update_at_runtime": false,
"flags": [
"startup"
]
},
{
"name": "allow_ansi",
"type": "str",
"level": "basic",
"desc": "Allow ANSI escape sequences in output. Values: Terminal, Always, Never",
"long_desc": "",
"default": "Terminal",
"daemon_default": "",
"tags": [],
"services": [
"cephfs-shell"
],
"see_also": [],
"enum_values": [],
"min": "",
"max": "",
"can_update_at_runtime": false,
"flags": []
},
{
"name": "auth_allow_insecure_global_id_reclaim",
"type": "bool",
"level": "advanced",
"desc": "Allow reclaiming global_id without presenting a valid ticket proving previous
possession of that global_id",
"long_desc": "Allowing unauthorized global_id (re)use poses a security risk. Unfortunately,
older clients may omit their ticket on reconnects and therefore rely on this being allowed
for preserving their global_id for the lifetime of the client instance. Setting this value
to false would immediately prevent new connections from those clients (assuming
auth_expose_insecure_global_id_reclaim set to true) and eventually break existing sessions
as well (regardless of auth_expose_insecure_global_id_reclaim setting).",
"default": true,
"daemon_default": "",
"tags": [],
"services": [],
"see_also": [
"mon_warn_on_insecure_global_id_reclaim",
"mon_warn_on_insecure_global_id_reclaim_allowed",
87
"auth_expose_insecure_global_id_reclaim"
],
"min": "",
"max": "",
"can_update_at_runtime": true,
"flags": [],
"value": [
{
"section": "mon",
"value": "true"
}
],
"source": "mon"
},
...
{
"name": "throttler_perf_counter",
"type": "bool",
"level": "advanced",
"desc": "",
"long_desc": "",
"default": true,
"daemon_default": "",
"tags": [],
"services": [],
"see_also": [],
"min": "",
"max": "",
"can_update_at_runtime": true,
"flags": []
},
{
"name": "timing",
"type": "bool",
"level": "basic",
"desc": "Whether execution time should be reported",
"long_desc": "",
"default": false,
"daemon_default": "",
"tags": [],
"services": [
"cephfs-shell"
],
"see_also": [],
"min": "",
"max": "",
"can_update_at_runtime": true,
"flags": []
}
]
3. Listar o estado do cluster:
curl -H "Authorization: Bearer <token>" -X GET
"http[s]://<ip-do-mgr-ativo>:[8443|8080]/api/health/full" -H "accept: */*"
{
"health": {
"status": "HEALTH_WARN",
"checks": [
{
"severity": "HEALTH_WARN",
"summary": {
"message": "1 pools have too many placement groups",
"count": 1
},
88
"detail": [
{
"message": "Pool erasure-rbd has 128 placement groups, should have 32"
}
],
"muted": false,
"type": "POOL_TOO_MANY_PGS"
}
],
"mutes": []
},
"mon_status": {
"name": "vm1",
"rank": 0,
"state": "leader",
"election_epoch": 8,
"quorum": [
0,
1,
2
],
"quorum_age": 13359,
"features": {
"required_con": "2449958747315978244",
"required_mon": [
"kraken",
"luminous",
"mimic",
"osdmap-prune",
"nautilus",
"octopus"
],
"quorum_con": "4540138292840890367",
"quorum_mon": [
"kraken",
"luminous",
"mimic",
"osdmap-prune",
"nautilus",
"octopus"
]
},
"outside_quorum": [],
"extra_probe_peers": [
{
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.241:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "192.168.122.241:6789",
"nonce": 0
}
]
},
{
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.242:3300",
"nonce": 0
},
89
{
"type": "v1",
"addr": "192.168.122.242:6789",
"nonce": 0
}
]
}
],
"sync_provider": [],
"monmap": {
"epoch": 1,
"fsid": "438e2a49-9e1d-459f-82cd-a2d9086f3b98",
"modified": "2023-04-17T15:25:24.789368Z",
"created": "2023-04-17T15:25:24.789368Z",
"min_mon_release": 15,
"min_mon_release_name": "octopus",
"features": {
"persistent": [
"kraken",
"luminous",
"mimic",
"osdmap-prune",
"nautilus",
"octopus"
],
"optional": []
},
"mons": [
{
"rank": 0,
"name": "vm1",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.240:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "192.168.122.240:6789",
"nonce": 0
}
]
},
"addr": "192.168.122.240:6789/0",
"public_addr": "192.168.122.240:6789/0",
"priority": 0,
"weight": 0
},
{
"rank": 1,
"name": "vm2",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.241:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "192.168.122.241:6789",
"nonce": 0
}
90
]
},
"addr": "192.168.122.241:6789/0",
"public_addr": "192.168.122.241:6789/0",
"priority": 0,
"weight": 0
},
{
"rank": 2,
"name": "vm3",
"public_addrs": {
"addrvec": [
{
"type": "v2",
"addr": "192.168.122.242:3300",
"nonce": 0
},
{
"type": "v1",
"addr": "192.168.122.242:6789",
"nonce": 0
}
]
},
"addr": "192.168.122.242:6789/0",
"public_addr": "192.168.122.242:6789/0",
"priority": 0,
"weight": 0
}
]
},
"feature_map": {
"mon": [
{
"features": "0x3f01cfb8ffedffff",
"release": "luminous",
"num": 1
}
],
"osd": [
{
"features": "0x3f01cfb8ffedffff",
"release": "luminous",
"num": 3
}
],
"client": [
{
"features": "0x3f01cfb8ffedffff",
"release": "luminous",
"num": 3
}
],
"mgr": [
{
"features": "0x3f01cfb8ffedffff",
"release": "luminous",
"num": 2
}
]
}
},
...
{
"name": "cephfs_metadata",
91
"id": 10,
"stats": {
"stored": 4364,
"stored_data": 4364,
"stored_omap": 0,
"objects": 22,
"kb_used": 1536,
"bytes_used": 1572864,
"data_bytes_used": 1572864,
"omap_bytes_used": 0,
"percent_used": 0.0000015503094346058788,
"max_avail": 338182275072,
"quota_objects": 0,
"quota_bytes": 0,
"dirty": 0,
"rd": 0,
"rd_bytes": 0,
"wr": 56,
"wr_bytes": 24576,
"compress_bytes_used": 0,
"compress_under_bytes": 0,
"stored_raw": 13092,
"avail_raw": 1014546797298
}
}
]
},
"client_perf": {
"read_bytes_sec": 1705,
"read_op_per_sec": 1,
"write_bytes_sec": 0,
"write_op_per_sec": 0,
"recovering_bytes_per_sec": 0
},
"hosts": 8,
"rgw": 1,
"iscsi_daemons": {
"up": 2,
"down": 0
}
}
4. Listar os OSDs do cluster:
curl -H "Authorization: Bearer <token>" -X GET "http[s]://<ip-do-mgr-ativo>:[8443|8080]/api/osd
"
-H "accept: */*"
[
{
"osd": 0,
"up": 1,
"in": 1,
"weight": 1,
"primary_affinity": 1,
"last_clean_begin": 0,
"last_clean_end": 0,
"up_from": 16,
"up_thru": 154,
"down_at": 0,
"lost_at": 0,
"public_addrs": {
"addrvec": [
{
"type": "v2",
92
"nonce": 78658,
"addr": "192.168.122.230:6800"
},
{
"type": "v1",
"nonce": 78658,
"addr": "192.168.122.230:6801"
}
]
},
"cluster_addrs": {
"addrvec": [
{
"type": "v2",
"nonce": 78658,
"addr": "10.0.1.230:6800"
},
{
"type": "v1",
"nonce": 78658,
"addr": "10.0.1.230:6801"
}
]
},
"heartbeat_back_addrs": {
"addrvec": [
{
"type": "v2",
"nonce": 78658,
"addr": "10.0.1.230:6802"
},
{
"type": "v1",
"nonce": 78658,
"addr": "10.0.1.230:6803"
}
]
},
...
"op_out_bytes": [
[
1681758628.2036219,
0
],
[
1681758633.2043064,
0
],
[
1681758638.2051032,
0
],
[
1681758643.2062242,
0
],
[
1681758648.2071307,
0
],
[
1681758653.2084196,
0
],
[
93
1681758658.2086031,
0
],
[
1681758663.2100496,
0
],
[
1681758668.2106152,
0
],
[
1681758673.2118962,
0
],
[
1681758678.2128623,
0
],
[
1681758683.2138152,
0
],
[
1681758688.2150798,
0
],
[
1681758693.215984,
0
],
[
1681758698.2172012,
0
],
[
1681758703.2184103,
0
],
[
1681758708.21974,
0
],
[
1681758713.2209485,
0
],
[
1681758718.2213042,
0
]
]
}
}
]
5. Listar performance dos componentes do cluster
curl -H "Authorization: Bearer <token>" -X GET
"http[s]://<ip-do-mgr-ativo>:[8443|8080]/api/perf_counters" -H "accept: */*"
{
"osd.0": {
"bluefs.bytes_written_slow": {
"description": "Bytes written to WAL/SSTs at slow device",
"type": 10,
94
"priority": 5,
"units": 0,
"value": 0
},
"bluefs.bytes_written_sst": {
"description": "Bytes written to SSTs",
"nick": "sst",
"type": 10,
"priority": 10,
"units": 0,
"value": 4096
},
"bluefs.bytes_written_wal": {
"description": "Bytes written to WAL",
"nick": "wal",
"type": 10,
"priority": 10,
"units": 1,
"value": 26394624
},
"bluefs.db_total_bytes": {
"description": "Total bytes (main db device)",
"nick": "b",
"type": 2,
"priority": 5,
"units": 0,
"value": 8589803520
},
...
"rgw.put_initial_lat": {
"description": "Put latency",
"type": 5,
"priority": 5,
"units": 1,
"value": 0,
"count": 0
},
"rgw.qactive": {
"description": "Active requests queue",
"type": 2,
"priority": 5,
"units": 1,
"value": 0
},
"rgw.qlen": {
"description": "Queue length",
"type": 2,
"priority": 5,
"units": 1,
"value": 0
},
"rgw.req": {
"description": "Requests",
"type": 10,
"priority": 5,
"units": 1,
"value": 1
}
}
}
6. Listar dados dos pools:
curl -H "Authorization: Bearer <token>" -X GET
"http[s]://<ip-do-mgr-ativo>:[8443|8080]/api/pool?stats=true" -H "accept: */*"
95
[
{
"pool": 1,
"pool_name": "device_health_metrics",
"flags": 1,
"flags_names": "hashpspool",
"type": "replicated",
"size": 3,
"min_size": 1,
"crush_rule": "replicated_rule",
"object_hash": 2,
"pg_autoscale_mode": "on",
"pg_num": 1,
"pg_placement_num": 1,
"pg_placement_num_target": 1,
"pg_num_target": 1,
"pg_num_pending": 1,
"last_pg_merge_meta": {
"ready_epoch": 0,
"last_epoch_started": 0,
"last_epoch_clean": 0,
"source_pgid": "0.0",
"source_version": "0'0",
"target_version": "0'0"
},
"auid": 0,
"snap_mode": "selfmanaged",
"snap_seq": 0,
"snap_epoch": 0,
"pool_snaps": [],
"quota_max_bytes": 0,
"quota_max_objects": 0,
"tiers": [],
"tier_of": -1,
"read_tier": -1,
"write_tier": -1,
"cache_mode": "none",
"target_max_bytes": 0,
"target_max_objects": 0,
"cache_target_dirty_ratio_micro": 400000,
"cache_target_dirty_high_ratio_micro": 600000,
"cache_target_full_ratio_micro": 800000,
"cache_min_flush_age": 0,
"cache_min_evict_age": 0,
"erasure_code_profile": "",
"hit_set_params": {
"type": "none"
},
"hit_set_period": 0,
"hit_set_count": 0,
"use_gmt_hitset": true,
"min_read_recency_for_promote": 0,
"min_write_recency_for_promote": 0,
"hit_set_grade_decay_rate": 0,
"hit_set_search_last_n": 0,
"grade_table": [],
"stripe_width": 0,
"expected_num_objects": 0,
"fast_read": false,
"options": {
"pg_num_min": 1
},
"application_metadata": [
"mgr_devicehealth"
],
96
"create_time": "2023-04-17T15:27:13.231914+0000",
"last_change": "140",
"last_force_op_resend": "0",
"last_force_op_resend_prenautilus": "0",
"last_force_op_resend_preluminous": "0",
"removed_snaps": "[]",
"pg_status": {
"active+clean": 1
},
...
"compress_bytes_used": {
"latest": 0,
"rate": 0,
"rates": [
[
1681759072.782105,
0
],
[
1681759078.025552,
0
],
[
1681759083.1435049,
0
],
[
1681759088.2403982,
0
],
[
1681759094.0028422,
0
],
[
1681759099.0903163,
0
],
[
1681759105.068778,
0
],
[
1681759110.1636276,
0
],
[
1681759115.4267433,
0
]
]
},
"compress_under_bytes": {
"latest": 0,
"rate": 0,
"rates": [
[
1681759072.782105,
0
],
[
1681759078.025552,
0
],
[
97
1681759083.1435049,
0
],
[
1681759088.2403982,
0
],
[
1681759094.0028422,
0
],
[
1681759099.0903163,
0
],
[
1681759105.068778,
0
],
[
1681759110.1636276,
0
],
[
1681759115.4267433,
0
]
]
},
"stored_raw": {
"latest": 13092,
"rate": 0,
"rates": [
[
1681759072.782105,
0
],
[
1681759078.025552,
0
],
[
1681759083.1435049,
0
],
[
1681759088.2403982,
0
],
[
1681759094.0028422,
0
],
[
1681759099.0903163,
0
],
[
1681759105.068778,
0
],
[
1681759110.1636276,
0
],
98
[
1681759115.4267433,
0
]
]
},
"avail_raw": {
"latest": 1014546797298,
"rate": 0,
"rates": [
[
1681759072.782105,
0
],
[
1681759078.025552,
0
],
[
1681759083.1435049,
0
],
[
1681759088.2403982,
0
],
[
1681759094.0028422,
0
],
[
1681759099.0903163,
0
],
[
1681759105.068778,
0
],
[
1681759110.1636276,
0
],
[
1681759115.4267433,
0
]
]
}
}
}
]
7. Listar um sumário do estado atual do cluster
curl -H "Authorization: Bearer <token>" -X GET
"http[s]://<ip-do-mgr-ativo>:[8443|8080]/api/summary" -H "accept: */*"
{
"health_status": "HEALTH_WARN",
"mgr_id": "vm3",
"mgr_host": "http://vm3:8443/",
"have_mon_connection": true,
"executing_tasks": [],
"finished_tasks": [
{
"name": "iscsi/target/create",
99
"metadata": {
"target_iqn": "iqn.2001-07.com.ceph:1681759313612"
},
"begin_time": "2023-04-17T19:22:05.677171Z",
"end_time": "2023-04-17T19:22:07.809254Z",
"duration": 2.132082939147949,
"progress": 100,
"success": true,
"ret_value": null,
"exception": null
},
{
"name": "rbd/create",
"metadata": {
"pool_name": "rbd",
"namespace": null,
"image_name": "test"
},
"begin_time": "2023-04-17T19:21:49.323425Z",
"end_time": "2023-04-17T19:21:50.548450Z",
"duration": 1.2250256538391113,
"progress": 100,
"success": true,
"ret_value": null,
"exception": null
},
{
"name": "progress/PG autoscaler decreasing pool 5 PGs from 32 to 8",
"metadata": {
"pool": 5
},
"begin_time": "2023-04-17T15:28:33.019073Z",
"end_time": "2023-04-17T15:32:33.059109Z",
"duration": 240.04003643989563,
"progress": 100,
"success": true,
"ret_value": null,
"exception": null
}
],
"version": "ceph version 15.2.17 (8a82819d84cf884bd39c17e3236e0632ac146dc4) octopus (stable)"
,
"rbd_mirroring": {
"warnings": 0,
"errors": 0
}
}
100
8. Orchestrator
A partir da versão Octopus, junto ao uso de managers, foi introduzido o con-
ceito de módulos para orquestração do cluster Ceph, que permitem, por exem-
plo, a adição e remoção de OSDs do cluster via dashboard, assim como uma
gerência facilitada via linha de comando. Há de se mencionar, entretanto, que
o uso de tais módulos em muitos casos ofusca as configurações aplicadas, o
que pode não ser desejável.
Dito isso, uma vez que o cluster esteja funcional, os passos para habilitar o
módulo de orquestração são:
1. Habilitar o módulo cephadm no manager e utilizá-lo como backend do or-
chestrator
33
:
Nas versões testadas do Ceph
34
, não é possível nativamente habilitar esse
módulo em sistemas operacionais baseados no Ubuntu. Ao invés disso,
deve-se “migrar” o cluster para a gerência do cephadm . Há de se men-
cionar que, ao realizar isso, o próprio cepha dm irá utilizar nativamente
containeres, não sendo possível alterar esse comportamento. Dito isso, a
migração do cluster para a gerência do cephadm pode ser realizada atra-
vés dos seguintes comandos
35
:
(a) Em cada host e VM do cluster, rodar o comando:
root@componentX:~# cephadm prepare-host
root@componentX:~# cephadm --image <IMAGE>
Nesse tutorial, a imagem utilizada foi a quay.io/ceph/ceph:v15
(b) Assimilar o cluster:
root@componentX:~# ceph config assimilate-conf -i /etc/ceph/ceph.conf
(c) Em cada monitor, executar o comando:
33
Outros módulos podem ser utilizados, como o rook, dependendo do que o operador de-
seja.
34
Octopus e Quincy.
35
Mais informações sobre esse processo podem ser obtidas na documentação oficial.
101
root@monX:~# cephadm adopt --style legacy --name mon.<mon-name>
(d) Em cada manager, executar o comando:
root@mgrX:~# cephadm adopt --style legacy --name mgr.<mgr-name>
(e) Habilitar o módulo:
~# ceph mgr module enable cephadm
~# ceph orch set backend cephadm
(f) Adicionar os hosts à gerência do cephadm:
~# ceph orch host add <hostname> [ip-address]
(g) Adotar os OSDs:
~# cephadm adopt --style legacy --name <name-osd>
Após isso, será possível utilizar o cephadm para realizar a adição de novos
componentes, tanto via linha de comando quanto via dashboard.
102
Parte IV
Formas de consumo e operações
O presente capítulo se destina a detalhar formas de consumo do cluster Ceph,
assim como operações básicas do mesmo.
103
9. Operações com pools
No Ceph, os pools criados podem ser de dois tipos:
1. Replication mode:
Os dados são replicados entre os OSDs. Utiliza mais espaço de armaze-
namento, porém, em caso de falha de um dos OSDs ou de um dos hosts,
a recuperação dos dados é mais rápida, pois requer a simples cópia dos
dados para novos OSDs;
2. Erasure mode:
São utilizados blocos de paridade para garantir a consistência dos dados.
Utiliza menos espaço de armazenamento, porém apresenta maior lenti-
dão na leitura e recuperação dos mesmos, uma vez que o Ceph precisará
recalcular os blocos de paridade para reconstruir os dados.
Além disso, outras considerações importantes sobre os pools são:
• O Ceph disponibiliza a opção de utilizar algoritmos de compressão nos
pools criados, sejam eles replicados ou não, de forma a reduzir o uso de
espaço em disco;
• Pools cujos nomes iniciam com . são utilizados para operações internas
do Ceph, não devendo ser criados ou editados pelos administradores do
cluster.
• É possível habilitar o escalonamento automático de PGs de um pool, de
forma a permitir que o próprio Ceph gerencie e ajuste o número de PGs
automaticamente, baseado na utilização do pool.
Para isso, é possível informar na criação do pool que o mesmo terá suas
PGs escalonadas automaticamente
36
, ou alterar dinamicamente o pool
para que o mesmo seja auto escalonável através do comando:
36
Através da opção --autoscale-mode=[on,off,warn].
104
ceph osd pool set <pool-name> pg_autoscale_mode <mode>
Onde os modos disponibilizados pelo Ceph são:
– on: habilita o auto escalonamento das PGs do pool;
– off: desabilita o auto escalonamento das PGs do pool;
– warn: lança um alerta quando as PGs do pool precisam ser rebalan-
ceadas, mas não o faz automaticamente.
Para verificar as configurações de auto escalonamento de todos os pools,
pode-se utilizar o comando:
ceph osd pool autoscale-status
• Pools erasure code por padrão apenas funcionam com operações que re-
alizam a escrita completa de um objeto, como é o caso do RGW. Desde a
versão Luminus, é possível realizar escritas parciais, através da configu-
ração allow_ec_over writes, o que permite o uso deste tipo de pool para
operações com RBD e CephFS:
ceph osd pool set <pool-name> allow_ec_overwrites true
Figura 65: Habilitar a escrita parcial em um pool erasure code
Algumas das operações básicas com pools são:
105
1. Via CLI:
• Listar pools:
ceph osd lspools
• Criar pool replicado:
ceph osd pool create <pool-name> [<pg-num> <pgp-num>] replicated <crush-rule> <expected-
num-objects>
Onde:
– pg-num: número total de PGs do pool;
– pgp-num: número total de PGs do pool, usado pelo Ceph para
gerência interna, devendo ser igual ao do pg-num;
– crush-rule: nome das regras de CRUSH que será usada nesse
pool;
– expected-num-objects: número esperado de objetos para o pool.
• Criar pool com erasure:
ceph osd pool create <nome-do-pool> [<pg-num> <pgp-num>] erasure <erasure-code-profile> <
crush-rule> <expected-num-objects>
Onde:
– erasure-code-profile: Profile que será utilizado no pool, contendo
dados como quantidade de blocos de paridade para cada bloco
de dados, algoritmo de paridade utilizado, entre outros.
– crush-rule: Nome das regras de CRUSH que será usada nesse
pool;
– expected-num-objects: Número esperado de objetos para o pool.
• Renomear pool:
ceph osd pool rename <old-name> <new-name>
• Associar pool com uma aplicação:
Desde a versão 12.x do Ceph, Luminous, os pools precisam ter uma
aplicação associada à eles. Para isso, pode-se utilizar o comando:
106
ceph osd pool application enable <pool-name> [cephfs,rbd,rgw]
• Habilitar quotas de um pool
37
:
ceph osd pool set-quota <pool-name> max_objects <int>
ceph osd pool set-quota <pool-name> max_bytes <int>
Ao habilitar quotas nos pools é necessário estar ciente da necessidade
de um monitoramento ativo, uma vez que, ao atingir o limite definido
pelos operadores o Ceph pode apresentar comportamentos inespe-
rados, como travamentos e perda de dados caso os usuários tentem
realizar escritas acima da capacidade máxima definida para o pool.
• Desabilitar quota de um pool:
ceph osd pool <pool-name> max_objects 0
• Remover pool:
Para remover o pool criado, primeiro é necessário injetar uma opção
temporária no serviço dos MONs, que por padrão vem como f alse,
para garantir que não haja erros. Isso é feito com o comando:
ceph tell mon.* injectargs '--mon-allow-pool-delete=true'
Em seguida, o pool pode ser removido com o comando:
ceph osd pool delete <pool-name> <pool-name> --yes-i-really-really-mean-it
• Alterar configurações do pool dinamicamente:
Pode-se alterar as configurações do pool de forma dinâmica, através
do comando:
ceph osd pool set <pool-name> <key> <value>
Onde as principais chaves e valores a se ter em mente são:
37
o Ceph não aceita como parâmetro os atributos max_objects e max_bytes durante a criação
de um pool. Sendo assim, é necessário definir os valores desses atributos após a criação do
pool. Ademais, é necessário executar o comando set-quota uma vez para cada atributo.
107
– compression_algorithm: Define o algoritmo de compressão do pool,
podendo ter os valores lz4, sn appy, zlib ou zstd. Caso nenhum
valor seja especificado, o pool não usará nenhum algoritmo de
compressão;
– compression_mode: Define o modo de compressão, podendo ter
os valores none, passive, aggressive ou force.
O comando c eph osd pool get <pool_nam e> a ll apresenta um re-
sumo das configurações aplicadas ao pool e lista algumas das possí-
veis configurações que podem ser alteradas dinamicamente. Como,
por exemplo, o atributo min_size
38
, que pode ser alterado dinamica-
mente com o comando ceph osd pool set <pool_name> min_size <v
alue>.
~$ ceph osd pool set rbd-example min_size 3
set pool 16 min_size to 3
~$ ceph osd pool get rbd-example all
size: 3
min_size: 3
pg_num: 32
pgp_num: 32
crush_rule: replicated_rule
hashpspool: true
nodelete: false
nopgchange: false
nosizechange: false
write_fadvise_dontneed: false
noscrub: false
nodeep-scrub: false
use_gmt_hitset: 1
fast_read: 0
pg_autoscale_mode: on
Outras configurações podem ser encontradas na documentação ofi-
cial.
• Criar snapshot do pool:
ceph osd pool mksnap <pool-name> <snap-name>
• Remover snapshot do pool:
38
Número mínimo de réplicas de objetos que devem estar disponíveis para garantir a tole-
rância a falhas no cluster.
108
ceph osd pool rmsnap <pool-name> <snap-name>
2. Via dashboard:
• Listar pools: opção no painel de gestão para listar todos os pools do
cluster Ceph, conforme apresentado na Figura 66.
Figura 66: Listando pools
• Criar pool: opção no painel de gestão para criar um pool no cluster
Ceph, conforme demonstrado na Figura 67.
Figura 67: Criando novo pool
Após selecionar a opção para criar um pool no ambiente Ceph, con-
109
forme apresentado na Figura 68, o operador poderá escolher entre o
modo de tolerância a falha do mesmo. Caso deseja-se trabalhar com
replicação, deve-se selecionar a opção replicated e posteriormente,
informar o número de réplicas desejado. Além disso, nessa opção,
é possível também selecionar modos de compressão, de modo a re-
duzir o tamanho bruto de armazenamento utilizado.
Figura 68: Criando novo pool replicado
Alternativamente, conforme apresentado na Figura 69, após seleci-
onar a opção para criar um pool no ambiente Ceph, o operador po-
derá escolher trabalhar com erasure code, de modo a reduzir o es-
110
paço bruto necessário para o armazenamento de seus dados. Assim,
deve-se selecionar a opção erasure code e posteriormente, informar
o erasure code profile, onde as configurações de número de blocos
de paridade são definidas . Além disso, nessa opção, é possível tam-
bém selecionar modos de compressão, de modo a reduzir o tamanho
bruto de armazenamento utilizado.
Figura 69: Criando novo pool com erasure code
• Editar pool: Opção utilizada para editar confgurações básicas dos po-
ols, conforme apresentado na Figura 70. Deve-se atentar que não é
111
Figura 71: Editando pool
113
10. Operações com blocos
Ao utilizar o Ceph para disponibilizar armazenamento via blocos, que é usado
pelo driver rbd do kernel Linux e pelo QEMU/KVM, é disponibilizado o utilitário
chamado rbd, que permite diversas operações, à saber:
• Inicializando um pool para ser utilizado pelo rbd:
rbd pool init <pool-name>
• Criar uma imagem usando um pool replicado:
rbd create --size <size>[GB,MB,KB] <pool-name>/<image-name>
• Criar uma imagem usando um pool erasure code:
Nesse cenário, os dados da imagem RBD são armazenados no pool era-
sure code e os metadados são armazenados no pool replicado, de forma a
garantir tolerância à falha. Além disso, o pool erasure code precisa permitir
escritas parciais. Para maiores informações, consulte a seção 9:
rbd create --size <size>[GB,MB,KB] --data-pool <ec-pool> <pool-replicated>/<image-name>
Figura 72: Criando imagem em pool erasure code
• Listar images em um pool:
rbd ls <pool-name>
~$ rbd ls rbd-example
image
image2
114
• Verificar informações da imagem:
rbd info <pool-name>/<image-name>
~$ rbd info rbd-example/image
rbd image 'image':
size 100 GiB in 25600 objects
order 22 (4 MiB objects)
snapshot_count: 0
id: 1bb2e8142f55
block_name_prefix: rbd_data.1bb2e8142f55
format: 2
features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
op_features:
flags:
create_timestamp: Fri May 19 00:23:05 2023
access_timestamp: Fri May 19 00:23:05 2023
modify_timestamp: Fri May 19 00:23:05 2023
• Incrementar o tamanho de uma images:
rbd resize --size <new-size> <pool-name>/<image-name>
~$ rbd resize --size 105GB rbd-example/image
Resizing image: 100% complete...done.
• Decrementar o tamanho de uma images:
rbd resize --size <new-size> <pool-name>/<image-name> --allow-shrink
~$ rbd resize --size 15GB rbd-example/image --allow-shrink
Resizing image: 100% complete...done.
• Remover uma imagem:
rbd rm <pool-name>/<image-name>
~$ rbd rm rbd-example/image
Removing image: 100% complete...done.
• Montar uma imagem:
rbd map <pool-name>/<image-name>
~$ rbd map rbd-example/image
/dev/rbd0
Caso o usuário tenha acesso à imagem, a mesma será montada em
/dev/rbd<id-incremental>, podendo, a partir desse momento, ser forma-
tada, e usada como um disco normal.
• Desmontar uma imagem:
115
rbd unmap /dev/rbd<id-incremental>
• Configurar IOPS de um pool:
rbd config pool set <pool-name> rbd_qos_iops_limit <int>
• Configurar IOPS de uma imagem:
rbd config image set <pool-name>/<image> rbd_qos_iops_limit <int>
• Listar todas as configurações possíveis de serem alteradas de um pool
RBD:
rbd config pool list <pool-name>
~$ rbd config pool list rbd-example | grep qos_read
rbd_qos_read_bps_burst 0 config
rbd_qos_read_bps_limit 0 config
rbd_qos_read_iops_burst 0 config
rbd_qos_read_iops_limit 0 config
116
11. Operações com OSDs
Essa seção se destina a detalhar comandos úteis do Ceph para monitora-
mento e gerência dos OSDs do cluster.
11.1. Detecção e correção de falhas
Por vezes, os OSDs da infraestrutura podem apresentar falhas, sendo ne-
cessário restituí-los, seja através da reinicialização do OSD ou da troca de um
disco físico. Para tal, o procedimento a ser executado nesse cenário é:
1. Inicialmente, deve-se verificar a saúde do cluster com o comando:
~$ ceph health
HEALTH_OK
Caso haja algum erro em algum OSD, uma saída semelhante a essa será
exibida:
HEALTH_WARN mons are allowing insecure global_id reclaim; 1 osds down; 1 host (1 osds) down;
Degraded data redundancy: 1761/7833 objects degraded (22.482%), 50 pgs degraded; 1 pool(s) do
not have an application enabled
2. Para encontrar qual OSD está com falha, basta executar o comando:
root@client-1:~# ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.97649 root default
-3 0.19530 host dp1
2 hdd 0.19530 osd.2 up 1.00000 1.00000
-9 0.19530 host dp2
0 hdd 0.19530 osd.0 up 1.00000 1.00000
-7 0.19530 host dp3
1 hdd 0.19530 osd.1 up 1.00000 1.00000
-5 0.19530 host dp4
3 hdd 0.19530 osd.3 up 1.00000 1.00000
-11 0.19530 host dp5
4 hdd 0.19530 osd.4 down 1.00000 1.00000
E identificar qual host está com falha.
3. Em seguida, é necessário acessar tal host para verificar o estado do ser-
viço ceph-OSD, assim como os logs do mesmo. Caso a análise prévia indi-
que que não se trata de uma falha no disco físico, basta iniciar/reiniciar o
serviço do OSD com o comando:
systemctl start|restart ceph-osd@<id>.service
117
E, após o mesmo ser automaticamente reintroduzido no cluster, repetir o
passo 1.
4. Caso a falha do OSD tenha sido causada por uma falha no disco físico, o
procedimento a ser realizado é:
(a) Verifique se é seguro destruir esse OSD:
while ! ceph osd safe-to-destroy osd.<osd-id> ; do sleep 10 ; done
(b) Destrua esse OSD:
ceph osd destroy <osd-id> --yes-i-really-mean-it
(c) Adicione um novo disco no host físico e, em seguida, o formate para
ser identificado como um OSD no Ceph:
ceph-volume lvm zap /dev/sdX
(d) Adicione esse novo OSD no Ceph com o id do antigo
39
:
ceph-volume lvm prepare --osd-id <osd-id> --data /dev/sdX
Ao realizar o prepare de um OSD, o mesmo ficará em estado down
até que seja realizado o activate. Ao realizar o ceph osd tree, o OSD
down aparecerá no final na árvore, dando a ilusão de que o mesmo
pertence ao último host apresentado.
(e) Ative esse OSD:
ceph-volume lvm activate <osd-id> <osd-fsid>
(f) Inicie o serviço do OSD e aguarde até que o mesmo esteja up e in no
cluster:
systemctl start ceph-osd@<id>.service
(g) Aguarde o rebalancemento finalizar com o comando ceph -w.
∗ Os comandos d e e podem ser executados em um único comando:
39
Caso o OSD a ser substituído tenha um dedicated_device, será necessário informar as op-
ções --block.db ou --bloc k-wal durante a preparação do disco. Informações sobre se tal OSD
possui um dedicated_device podem ser obtidas com o comando ls -lha /var/lib/ceph/osd/cep
h-<id>/, vgs e lvs. Maiores informações podem ser encontradas na documentação oficial.
118
ceph-volume lvm create --osd-id {id} --data /dev/sdX
Os passos (d) e (e) podem ser simplificados substituindo o comando prepar
e por create no passo (d), o qual realizará a ativação do OSD automaticamente.
11.2. Detectando OSDs lentos
O Ceph possui formas de identificar OSDs lentos, por exemplo, o comando
ceph tell osd.<osd-id> bench pode ser utilizado para verificar a velocidade de
escrita e de leitura dos OSDs, é possível também identificar OSDs com baixa
performance através do comando ceph o sd perf <osd-id> para avaliar o de-
sempenho dos OSDs em um cluster Ceph.
O comando ceph tell osd.<osd-id> bench é usado para realizar testes de
desempenho de leitura e escrita em um OSD específico. Permite avaliar a ca-
pacidade de armazenamento e recuperação de dados do OSD em questão. O
formato básico do comando está apresentado abaixo.
~$ ceph tell osd.{osd-id} bench {time} {block}
Por exemplo, caso deseje executar um teste de leitura e escrita em um OSD
(osd.0) específico por 10 segundos, usando blocos de dados de 4096 bytes:
~$ ceph tell osd.0 bench 10 4096
{
"bytes_written": 10,
"blocksize": 4096,
"elapsed_sec": 0.0030375559999999998,
"bytes_per_sec": 3292.1203757231142,
"iops": 0.80374032610427593
}
Ao executar este comando, o OSD selecionado irá realizar operações de lei-
tura e escrita em um bloco de dados aleatório no pool. Durante o teste, o OSD
exibirá estatísticas de desempenho em tempo real, incluindo a taxa de transfe-
rência de dados, a latência média e a quantidade total de dados lidos e escritos.
Útil em:
• situações onde se deseja avaliar o desempenho de um único OSD em am-
bientes Ceph;
119
• comparar o desempenho de diferentes OSDs em um mesmo cluster;
• testar a integridade e capacidade de armazenamento de um OSD especí-
fico após uma manutenção ou atualizações.
Entretanto, é necessário lembrar que os testes de benchmark podem afetar
o desempenho geral do cluster e, portanto, devem ser executados com cau-
tela e apenas em momentos de baixa carga. Além disso, os resultados do ben-
chmark podem variar dependendo de vários fatores, como a configuração do
hardware, o tamanho e tipo dos dados armazenados e a quantidade de tráfego
de rede no cluster.
O comando ceph osd perf é uma ferramenta útil para avaliar o desempe-
nho dos OSDs em ambientes Ceph. Quando executado, exibe as métricas de
desempenho listadas abaixo.
~$ ceph osd perf
osd commit_latency(ms) apply_latency(ms)
4 0 0
3 0 0
2 0 0
1 0 0
0 0 0
• osd: ID do OSD;
• apply_latency: tempo de latência até a transação terminar, isto é, o tempo
de gravação + journal_latency;
• commit_latency: tempo que leva para realizar o syncfs();
• journal_latency: tempo que leva para gravar no journal, ou seja, tempo
de reconhecimento da escrita para o cliente.
Caso necessário, os operadores podem executar o comando
ceph daemon o sd.<id> perf dump a partir do host onde está situado o OSD
alvo, dessa forma o Ceph irá retornar um conjunto de estatísticas que incluem
120
informações sobre as operações de leitura e escrita, latência, taxa de transfe-
rência, entre outras. Abaixo estão alguns exemplos de informações que são
retornadas pelo comando, a resposta para esse comando foi omitida para não
poluir o documento.
• osd.op_r: número total de operações de leitura executadas pelo OSD;
• osd.op_w: número total de operações de gravação executadas pelo OSD;
• osd.op_rw_in_bytes: número total de bytes lidos e escritos pelo OSD;
• osd.op_r_latency: latência média das operações de leitura (em microsse-
gundos);
• osd.op_w_latency: latência média das operações de escrita (em micros-
segundos)/
• osd.op_rw_latency: latência média das operações de leitura e escrita (em
microssegundos);
• osd.op_in_bytes: número total de bytes lidos e escritos pelo OSD.
• osd.op_out_bytes: número total de bytes escritos pelo OSD;
• osd.op_in_bytes_slow: número total de bytes lidos pelo OSD com latência
maior que um limite de tempo especificado;
• osd.op_out_bytes_slow: número total de bytes escritos pelo OSD com
latência maior que um limite de tempo especificado.
Essas informações podem ser usadas para monitorar o desempenho do
OSD em tempo real e identificar possíveis problemas de desempenho. Por
exemplo, se a latência média das operações de leitura ou gravação é muito
alta, isso pode indicar que o OSD está sobrecarregado e precisando de mais
recursos ou ajustes na configuração.
121
11.3. Manutenção de OSDs
No cenário no qual seja necessário remover um disco de um dos hosts físicos
para manutenção, porém sem envolver a destruição/modificação dos dados
contidos em tal disco, o procedimento a ser realizado consiste em:
1. Verificar o valor da configuração mon_osd_down_out_interval e ajustar o
mesmo de acordo com o intervalo planejado para a manutenção. Além
disso, é possível utilizar a flag noout no cluster Ceph, de forma que o
mesmo não inicie nenhum processo de rebalanceamento de dados quando
detectar que um ou mais OSDs do cluster estão irresponsivos
40
:
ceph osd set noout
2. Parar o serviço do OSD:
systemctl stop ceph-osd@<id>.service
3. Marcar o OSD alvo como down e out:
ceph osd down <id>
ceph osd out <id>
Apesar do comando down, o OSD será marcado como down somente
após a parada do serviço.
4. Remover o disco para a manutenção desejada, atentando-se para não
destruir ou modificar os dados do mesmo.
5. Após finalizada a manutenção do disco, e o mesmo ser reinserido no host,
deve-se iniciar o serviço do OSD e aguardar até que o mesmo esteja up e
in no cluster:
systemctl start ceph-osd@<id>.service
6. Por fim, deve-se remover a flag noout do cluster. Esse passo é essencial
e NUNCA deve ser esquecido!!!:
ceph osd unset noout
40
A equipe da SC Clouds recomenda extremo cuidado com essa opção, devendo ser
removida imediatamente após a manutenção, de forma a evitar cenários onde OSDs
fiquem irresponsivos, mas os dados não sejam rebalanceados.
122
12. Operações com crush map e rules
A presente seção contém informações sobre os passos para executar alte-
rações em crush maps, bem como aborda cada um dos seus componentes. É
necessário atenção e cuidados por parte dos operadores ao realizar alterações
manuais aos crush maps do ambiente, uma vez que esses passos persistem me-
tadados de maneira forçada/cega, podendo assim, gerar inconsistências de di-
fícil mapeamento e troubleshooting. A SC Clouds não recomenda a edição de
crush map, sem a análise prévia das alterações desejadas, dessa forma é pos-
sível prevenir situações de inconsistências e crash do ambiente.
O Ceph permite alterações em crush maps através do Ceph CLI, que pos-
sibilita aos operadores adicionar/remover classes de OSDs, rule s e buckets
41
,
entre outros. O exemplo abaixo apresenta os passos executados para alterar
a classe de um OSD cujo id é 0 para, em seguida, criar uma regra simples de
erasure code.
~$ ceph osd crush get-device-class 0 # Verificar a qual classe o osd.0 pertence.
hdd
~$ ceph osd crush rm-device-class 0 # Remover classe definida para o osd.0.
done removing class of osd(s): 0
~$ ceph osd crush set-device-class ssd 0 # Definir ao osd.0 a classe ssd.
set osd(s) 0 to class 'ssd'
~$ ceph osd crush get-device-class 0 # Verificar a qual classe o osd.0 pertence.
ssd
~$ ceph osd crush rule create-erasure erasure_rule # Criar uma rule do tipo erasure code
created rule erasure_rule at 1
~$ ceph osd crush rule list # Listar as regra do ambiente
replicated_rule
erasure_rule
~$ ceph osd crush rule rm erasure_rule # Remover uma regra
Entretanto, é possível executar alterações manuais em situações onde o
Ceph CLI não disponibiliza tais customizações, por exemplo, alterar o algoritmo
utilizado para construir o crush map.
41
Não confundir com os objetos distribuídos do AWS S3.
123
• Obter um crush map: O Ceph produzirá um crush map compilado para o
arquivo especificado. Como o crush map está em um formato compilado,
é necessário descompilar antes de editar.
~$ ceph osd getcrushmap -o {compiled-crushmap-filename}
• Descompilar o crush map:
~$ crushtool -d {compiled-crushmap-filename} -o {decompiled-crushmap-filename}
• Recompilar o crush map:
~$ crushtool -c {decompiled-crushmap-filename} -o {compiled-crushmap-filename}
• Definir o crush map: Após editar o crush map e recompilá-lo, o comando
abaixo irá definir o crush map conforme o arquivo especificado.
~$ ceph osd setcrushmap -i {compiled-crushmap-filename}
Existem 6 seções principais em um crush map:
• Tunables: descreve quaisquer tunables que diferem do comportamento
de crush map legados. Corrigem bugs, fornecem otimizações e alterações
realizadas ao longo dos anos para melhorar o comportamento do crush
map no ambiente Ceph;
• Devices: representam os OSDs que são os elementos que de fato intera-
gem com os dispositivos físicos e realizam a escrita e leitura de dados;
• Types: os tipos de buckets consistem em uma agregação hierárquica para
o crush map de locais de armazenamento (e.g., rows, racks, chassis, hosts);
• Buckets: ao definir o tipo de bucket, é necessário definir cada nó na hie-
rarquia, seu tipo e os dispositivos que ele contém;
• Rules: definem políticas sobre como os dados são distribuídos entre os
dispositivos na hierarquia;
124
• Choose_args: pesos associados à hierarquia que foram ajustados para
otimizar o posicionamento dos dados.
12.1. Dispositivos
Dispositivos são OSDs individuais que armazenam dados. Os dispositivos
são identificados por um id (inteiro, não negativo) e um name, normalmente
osd.N onde N é o id do dispositivo. Os dispositivos também podem ter uma
classe de dispositivo associada a eles (por exemplo, hdd ou ssd), permitindo
que sejam convenientemente direcionados por uma regra de crush map.
12.2. Tipos e Buckets
Bucket é o termo utilizado para definir nós internos na hierarquia lógica do
cluster Ceph: hosts, racks, rows, entre outros. O crush map define tipos que são
usados para descrever esses nós. Os tipos padrão incluem:
• device (OSDs) – representam os discos físicos onde os dados são de fato
escritos;
• host – representa os servidores físicos onde os discos são alocados;
• chassis – lâminas/chassis onde os servidores estão contidos (caso exista
essa segregação no ambiente);
• rack – rack onde os servidores foram montados;
• row – linha do datacenter onde os racks dos servidores são montados;
• pdu – fonte de alimentação de energia que liga as linhas do datacenter;
• pod – estrutura do datacenter onde os servidores são alocados com seus
respectivos equipamentos de rede, que interconectam os servidores com
os demais elementos do datacenter;
• room – sala do datacenter onde os PODs são alocados;
125
• datacenter – datacenter onde a estrutura está sendo executada;
• zone – zona geográfica (normalmente representa um estado ou região de
um país) onde os sistemas foram instalados;
• region – região (normalmente utilizada para representar um país) geográ-
fica onde os sistemas foram instalados;
• root – elemento base de toda a estrutura Ceph, e obrigatório.
A maioria dos clusters usa apenas alguns desses tipos, outros tipos podem
ser definidos conforme necessário. A hierarquia é construída com dispositivos
(normalmente tipo osd) nas folhas, nós internos com tipos não dispositivos e
um nó raiz do tipo root. A Figura 73 apresenta um exemplo dessa hierarquia.
Figura 73: Hierarquia de buckets do Ceph
Os elementos da estrutura ilustrada com a Figura 73 são todos opcionais
e fica a cargo do operador do ambiente definir a arquitetura adequada para
sua realidade e contexto. Por padrão, a hierarquia adotada pelo Ceph é de
126
root− > hosts− > osds. Deve-se atentar que ao utilizar definições mais comple-
xas, como por exemplo, com OSDs em diferentes datacenter, zonas e regiões,
o ambiente começa a sofrer com latência, devido à necessidade de replicar
dados em ambientes geograficamente distribuídos, e do Ceph somente res-
ponder para o cliente confirmando a escrita do dado, somente após o último
bloco ser escrito com sucesso no último OSD do PG.
Cada bucket na hierarquia tem um peso (weight) que indica a proporção re-
lativa do total de dados que o dispositivo ou sub árvore hierárquica deve arma-
zenar. Os pesos são definidos nas folhas, indicando o tamanho do dispositivo,
e somam automaticamente a árvore, de modo que o peso do nó root seja o
total de todos os buckets contidos abaixo dele. Entretanto, como o crush map é
um processo pseudo aleatório probabilístico, há sempre uma variação na dis-
tribuição ideal. Sendo assim os atributos weight definidos nas folhas permitem
que o cluster execute otimizações numéricas com base nas especificidades da
hierarquia para obter uma distribuição equilibrada.
Existem dois tipos suportados de distribuição de weight:
1. compat:
É um único conjunto de pesos para cada dispositivo e nó do ambiente
Ceph, não é adequado para corrigir todas as anomalias, por exemplo,
diferentes pools com diferentes cargas e performances serão tratados
como iguais pelo balanceador. Entretanto, esse modo de configuração
é compatível com as versões antigas do Ceph, uma vez que o conceito de
conjuntos de pesos foi introduzida na versão Luminous v12.2;
2. per-pool:
Conjunto de pesos mais flexível, permite que o posicionamento de blocos
seja otimizado para cada conjunto de dados, permitindo que o otimiza-
dor corrija uma sutil distorção de dados em direção a OSDs com pesos
pequenos em relação aos outros OSDs do ambiente Ceph.
O comando a seguir apresenta uma visualização simples da hierarquia do
127
ambiente Ceph, incluindo os pesos.
~$ ceph osd crush tree
ID CLASS WEIGHT TYPE NAME
-1 0.97649 root default
-11 0.19530 host dp1
0 hdd 0.19530 osd.0
-9 0.19530 host dp2
3 hdd 0.19530 osd.3
-5 0.19530 host dp3
2 hdd 0.19530 osd.2
-7 0.19530 host dp4
4 hdd 0.19530 osd.4
-3 0.19530 host dp5
1 hdd 0.19530 osd.1
12.3. Regras
Regras definem a política sobre como os dados são distribuídos pelos dis-
positivos na hierarquia, definem também estratégias de posicionamento, repli-
cação e políticas de distribuição que permitem especificar exatamente como o
crush map persiste as réplicas de dados. Utilizando regras é possível, por exem-
plo, definir um par de destinos para espelhamento bidirecional ou ainda criar
uma regra para erasure code entre diferentes dispositivos de armazenamento
em um ambiente Ceph. Os atributos que definem as regras em ambientes
Ceph estão apresentados abaixo.
rule <rulename> {
id <unique number>
type [replicated | erasure]
min_size <min-size>
max_size <max-size>
step take <bucket-type> [class <class-name>]
step [choose|chooseleaf] [firstn|indep] <N> <bucket-type>
step emit
}
• id: número inteiro não negativo, único, para identificar a regra;
• type [replicated | erasure]: Define se a regra tem propósito de replicated
ou erasure code;
• min_size <minsize>: não seleciona a regra caso um pool faça menos ré-
plicas do que o valor definido
42
;
42
A partir da versão Nautilus, esses parâmetros foram removidos e substituídos pelo parâ-
metro size na definição de pool.
128
• max_size <maxsize>: não seleciona a regra caso um pool faça mais répli-
cas do que o valor definido
42
;
• step take <buckettype> [class <classname>]: seleciona um bucket e co-
meça a iterar na árvore;
• step [choose|chooseleaf] [firstn|indep] <N> <buckettype>: define o
número de réplicas no pool. Onde:
– choose: seleciona N buckets do tipo fornecido, esse número geral-
mente representa o número de réplicas do pool;
– chooseleaf: seleciona um conjunto de buckets do tipo fornecido e
escolhe um nó folha em cada sub árvore de cada bucket no conjunto
fornecido. Esse número geralmente representa o número de réplicas
do pool;
– firstn|indep: controla a estratégia de substituição que o crush map
utiliza quando os OSDs são marcados como Down. Caso a regra seja
utilizada para replicação de dados deve ser usado firstn, caso a regra
seja utilizada para erasure code deve ser usado indep;
– Se N == 0: escolhe o valor definido para pool-num-replicas;
– Se N > 0 && < pool-num-replicas: escolhe o valor definido por N;
– Se N < 0: escolhe o resultado da operação pool-num-replicas - N.
• step emit: Retorna com o valor obtido e esvazia a pilha. Normalmente
utilizado no final de uma regra, mas pode ser utilizado para obter árvores
diferentes na mesma regra.
As regras podem ser criadas por meio do Ceph CLI, especificando o tipo
de pool para o qual serão usadas (replicadas ou erasure code), o domínio de
falha e, opcionalmente, uma classe de dispositivo. Em casos raros, as regras
devem ser escritas à mão, editando manualmente o crush map. Os operadores
129
podem visualizar as regras criadas no ambiente e os detalhes das regras com
os comandos abaixo.
~$ ceph osd crush rule ls
replicated_rule
erasure_rule
~$ ceph osd crush rule dump erasure_rule
{
"rule_id": 1,
"rule_name": "erasure_rule",
"ruleset": 1,
"type": 3,
"min_size": 3,
"max_size": 4,
"steps": [
{
"op": "set_chooseleaf_tries",
"num": 5
},
{
"op": "set_choose_tries",
"num": 100
},
{
"op": "take",
"item": -1,
"item_name": "default"
},
{
"op": "chooseleaf_indep",
"num": 0,
"type": "host"
},
{
"op": "emit"
}
]
}
A decisão principal ao criar uma rule para crush map é qual será o domínio
de falha. Por exemplo, se um domínio de falha do host for selecionado, o crush
map garantirá que cada réplica dos dados seja armazenada em um host ex-
clusivo, caso seja selecionado rack cada réplica será armazenada em um rack
diferente. A escolha do domínio de falha depende principalmente do tamanho
e da topologia do ambiente Ceph. Na maioria dos casos, toda a hierarquia do
ambiente está aninhada abaixo de um nó root chamado default. Também é
possível criar regra que restrinja a colocação de dados a uma classe especí-
fica de dispositivo. Por padrão, os Ceph OSDs se classificam automaticamente
como HDD ou SSD, dependendo do tipo de dispositivo que está sendo usado.
O comando abaixo é utilizado para criar uma regra de replicação.
130
~$ ceph osd crush rule create-replicated {name} {root} {failure-domain-type} [{class}]
Para um pool com erasure code, as mesmas decisões básicas precisam ser
tomadas: qual é o domínio de falha, em qual nó na hierarquia os dados se-
rão colocados (geralmente default) e se a colocação será restrita a uma classe
de dispositivo específica. No entanto, os pools de erasure code são criados de
maneira um pouco diferente, pois precisam ser construídos com cuidado, com
base no erasure code que está sendo usado. Por esse motivo, é necessário in-
cluir essas informações no perfil do erasure code. O comando abaixo é utilizado
para listar os perfis de erasure code de um ambiente Ceph.
~$ ceph osd erasure-code-profile ls
default
Os detalhes de um perfil existente pode ser visualizado com:
~$ ceph osd erasure-code-profile get default
k=2
m=2
plugin=jerasure
technique=reed_sol_van
Normalmente, os perfis não devem ser modificados; em vez disso, um novo
perfil deve ser criado e usado ao criar um novo pool ou criar uma nova regra
para um pool existente. Um perfil erasure code consiste em um conjunto de
pares chave=valor. A maioria deles controla o comportamento do erasure code
que está codificando dados no pool. Aqueles que começam com crush -, no
entanto, afetam a regra crush map que é criada.
Os atributos de interesse de perfil de erasure code são:
• crush-root: o nome do nó onde será alocado os dados [default: default];
• crush-failure-domain: o tipo de bucket onde os fragmentos de erasure
code serão alocados [default: host];
• crush-device-class: a classe dos dispositivos no qual serão alocados os
dados [default: none (isto é, todos os dispositivos serão utilizados)];
131
• k e m: onde K é o número de blocos originais e M é o número total de blo-
cos de paridade. Por exemplo, na configuração 4:2, cada bloco de dados
é dividido em quatro blocos e gerados dois blocos de paridade. Isso signi-
fica que, mesmo que dois blocos (de dados ou paridade) sejam perdidos,
os dados originais ainda podem ser recuperados.
Após ser definido um perfil de erasure code, os operadores podem criar uma
regra de erasure code com o comando a seguir.
~$ ceph osd crush rule create-erasure {name} {profile-name}
Conforme mencionado no início desta seção, em casos raros, as regras de-
vem ser escritas à mão, editando manualmente o crush map, dessa forma os
operadores podem customizar as rules do crush map. Existem ambientes que
ocasionalmente equilibram custo e desempenho misturando SSDs e HDDs no
mesmo pool. Ao definir a afinidade primária dos OSDs da classe HDD como 0
, pode-se direcionar as operações para a classe SSD. Uma alternativa é definir
uma regra que sempre seleciona um OSD SSD como o primeiro OSD e, em se-
guida, seleciona HDDs para os demais OSDs. Assim, o conjunto de atuação de
cada PG terá exatamente um OSD da classe SS D como primário, e os demais
OSDs da classe HDD. Por exemplo, a regra abaixo apresenta um exemplo do
cenário descrito acima; escolhe um OSD da classe SSD como primário. Observe
que, para um pool replicado N vezes, essa regra seleciona N+1 OSDs (bloco
original + N réplicas) para garantir que N cópias estejam em hosts diferentes,
porque o primeiro OSD da classe SSD pode ser colocalizado em qualquer um
dos N OSDs da classe HDD.
rule mixed_replicated_rule {
id 11
type replicated
min_size 1
max_size 10
# Seleciona os buckets da classe ssd
step take default class ssd
# Escreve 1 réplica em uma folha de um bucket do tipo host
step chooseleaf firstn 1 type host
step emit
# Seleciona os buckets da classe hdd
step take default class hdd
132
# Escreve o numero de replicas definido no pool nos buckets do tipo host
step chooseleaf firstn 0 type host
step emit
}
Esse requisito de armazenamento extra pode ser evitado colocando SSDs
e HDDs em hosts diferentes com a compensação de que os hosts com SSDs
receberão todas as solicitações do cliente. Portanto, é necessário considerar
CPUs mais rápidos para hosts SSD e mais modestos para nós HDD, já que o
último normalmente atenderá apenas operações de recuperação. No exemplo
abaixo, os buckets ssd_hosts e hdd_hosts devem conter servidores distintos
com recursos computacionais distintos.
rule mixed_replicated_rule_two {
id 1
type replicated
min_size 1
max_size 10
# Seleciona os buckets da classe ssd definidos no bucket ssd_hosts
step take ssd_hosts class ssd
# Escreve 1 réplica em uma folha de um bucket do tipo host
step chooseleaf firstn 1 type host
step emit
# Seleciona os buckets da classe hdd definidos no bucket hdd_hosts
step take hdd_hosts class hdd
# Escreve (pool-num-replicas - 1) réplicas em uma folha de um bucket do tipo host
step chooseleaf firstn -1 type host
step emit
}
12.4. Afinidade
Quando um Ceph Client lê ou grava dados, primeiro é contatado o OSD
principal em cada PG afetado. Por padrão, o primeiro OSD no conjunto é o
principal. Por exemplo, no conjunto [2, 3, 4], osd.2 é listado como primário e,
portanto, é o OSD principal. Às vezes, um OSD é menos adequado para atuar
como líder do que outros OSDs (por exemplo, tem uma unidade lenta ou um
controlador lento). Para evitar gargalos de desempenho (especialmente em
operações de leitura) enquanto maximiza a utilização de seu hardware, pode-
se influenciar a seleção de OSDs primários ajustando os valores de afinidade
primários ou criando uma regra que seleciona primeiro os OSDs preferidos.
Um cenário comum para afinidade primária é quando um ambiente con-
tém uma mistura de tamanhos de OSDs, por exemplo, racks mais antigos com
133
SSDs SATA de 1,9 TB e racks mais modernos com SSDs SATA de 3,84 TB. Em
média, o último receberá o dobro do número de PGs e, portanto, servirá o
dobro do número de operações de gravação e leitura, portanto, eles estarão
mais ocupados do que o primeiro. Uma atribuição grosseira de afinidade pri-
mária inversamente proporcional ao tamanho do OSD não será 100% ideal,
mas pode facilmente alcançar uma melhoria de 15% na taxa de transferência
geral de leitura, utilizando a largura de banda da interface SATA e os ciclos da
CPU de maneira mais uniforme.
Por padrão, todos os ceph OSDs têm afinidade primária de 1, o que indica
que qualquer OSD pode atuar como primário com igual probabilidade. É possí-
vel reduzir a afinidade primária de um OSD para que o crush map tenha menos
probabilidade de escolher o OSD como primário no conjunto de atuação de um
PG, definindo a afinidade de um OSD para um número real no intervalo [0-1],
onde 0 indica que o OSD NÃO pode ser usado como primário e 1 indica que
um OSD pode ser usado como primário. Quando o peso está entre esses extre-
mos, é menos provável que o crush map selecione esse OSD como primário. O
processo para selecionar o OSD principal é mais complexo do que uma simples
probabilidade baseada em valores de afinidade relativa, mas resultados men-
suráveis podem ser alcançados mesmo com aproximações de primeira ordem
de valores desejáveis.
134
13. CephFS
O CephFS implementa um sistema de arquivos POSIX em um backend Ceph,
possibilitando um método fácil de implementar sistemas de arquivos comparti-
lhados com alta disponibilidade. Para tal, o Ceph utiliza os componentes MDSs
para realizar a gestão do sistema de arquivos
43
.
Para criar um filesystem utilizando o CephFS, é necessário criar dois pools
44
,
sendo que um irá armazenar os dados em sí, enquanto que o outro irá arma-
zenar os metadados.
É importante ressaltar que o pool de metadados apenas pode ser do tipo re-
plicado
45
, enquanto que o pool de dados pode ser tanto replicado quanto com
erasure code. O uso de erasure code não é recomendado pela documentação
oficial do Ceph, devido a peculiaridades dos sistemas de arquivos e funciona-
mento do Ceph em si.
O processo de erasure code divide o dado em partes iguais (chamadas de
parâmetro k), e faz a persistência do mesmo no Ceph, e gera blocos de paridade
(partes m) para serem utilizadas em caso de perda de alguma das partes “k”.
Assim, para se montar a informação original num erasure code, precisa-se de “k”
partes de dados; deste modo, o cliente precisa esperar o número “k” de OSDs
responderam para remontar a informação original, o que pode ocasionar uma
certa latência a depender da estrutura montada.
Além disso, os objetos básicos do Ceph (RADOS object) possuem tamanho
fixo padrão de 4M; assim, caso trabalhe-se com muitos arquivos pequenos,
além da situação mencionada de latência, pode-se ter uma perda de espaço
útil de armazenamento frente ao overhead do processo de erasure code, com a
43
Por isso o ideal é que sempre existam ao menos 2 MDSs, de forma a garantir a tolerância
à falta de um ou então, realizar o balanceamento entre os dois, de forma que ambos sejam
ativos no ambiente.
44
Pode-se utilizar o mesmo pool para armazenar os dados e os metadados, mas essa opção
não é recomendada, uma vez que ao mesclar os dados com os metadados no mesmo pool, a
performance do filesystem pode ser afetada.
45
Se o operador tentar usar um pool com erasure code, será retornado um erro na operação.
135
informação sendo divida em k partes mais m blocos de paridade. Deste modo,
antes de adotar um ou outra técnica de tolerância a falta, deve-se avaliar o
que é mais adequado para o contexto e carga de dados a serem aplicadas no
ambiente Ceph.
ceph osd pool create fs-replicated <pgs>
ceph osd pool create fs-erasure erasure <pgs> <profile>
ceph osd pool set fs-erasure allow_ec_overwrites true
ceph osd pool application enable fs-replicated cephfs
ceph osd pool application enable fs-erasure cephfs
ceph fs new <filesystem-name> <metadata-pool> <data-pool> [--force] # caso o <data-pool> seja do tipo
# erasure code
Além disso, caso já exista um filesystem associado a um MDS, a criação de
outro filesystem será bloqueada. Esse comportamento pode ser alterado com
o comando:
ceph fs flag set enable_multiple true --yes-i-really-mean-it
Dito isso, apesar de ser possível que um único MDS gerencie vários filesys-
tems, o mesmo não faz a gerência de todos ao mesmo tempo, sendo necessário
parar um dos filesystems, subir o outro e esperar o sistema convergir:
ceph fs set <filesystem-up> down true
ceph fs set <another-filesystem> down false
Assim, caso deseje-se utilizar mais de um filesystem ao mesmo tempo, deve-
se utilizar mais de um MDS. Com isso, a criação de um filesystem está completa,
sendo as operações possíveis com tal filesystem:
• Removê-lo:
ceph fs set <filesystem> down true
ceph fs fail <filesystem>
ceph fs rm <filesystem> --yes-i-really-mean-it
• Criar usuário com acesso a um diretório específico:
ceph fs authorize <filesystem> client.<name> <directory> rw
Por exemplo:
136
ceph fs authorize cephfs client.test /test rw
[client.test]
key = AQAbyj5kIBAaBBAAwS8tfs0m4HjEHr/uMp9xVA==
caps mds = "allow rw path=/test"
caps mon = "allow r"
caps osd = "allow rw tag cephfs data=cephfs"
Aqui é importante ressaltar que, para que a limitação de um usuário a
determinado diretório funcione, o mesmo deve ser previamente criado
pelo administrador do sistema. Para isso, o processo seria:
– Montar o filesystem:
echo <admin-key> > secret.key # redirecione a chave do admin para um arquivo
mount -t ceph <mon1>[,<mon2>,<monX]:/ /mnt -o name=admin,secretfile=secret.key
mkdir /mnt/test
umount /mnt
• Limitar quotas de um usuário:
Por padrão, um usuário com acesso a um diretório específico não possuí
limites de quotas. Porém, isso pode ser alterado, limitando a quantidade
de arquivos que o usuário pode ter e seu tamanho. Para tal, o adminis-
trador precisará executar alguns passos antes:
1. Ter o pacote attr instalado;
2. Montar o filesystem usando o diretório /;
3. Especificar as quotas para determinado diretório:
setfattr -n ceph.quota.max_bytes -v 104857600 /mnt/test # 100 MB
setfattr -n ceph.quota.max_files -v 10000 /mnt/test # 10,000 files
Caso deseje-se ver as quotas de um diretório
46
getfattr -n ceph.quota.max_bytes /mnt/test
getfattr -n ceph.quota.max_files /mnt/test
Por fim, para alterar/remover as limitações de quotas de um diretó-
rio:
46
Caso o diretório não possua quotas, a seguinte mensagem de erro ocorrerá: /mnt/: ceph.
quota.max[_bytes|_files]: No such attribute
137
setfattr -n ceph.quota.max_bytes -v 0 /mnt/test # Remove a quota
setfattr -n ceph.quota.max_files -v 0 /mnt/test # Remove a quota
setfattr -n ceph.quota.max_bytes -v 10 /mnt/test # Altera a quota
setfattr -n ceph.quota.max_files -v 10 /mnt/test # Altera a quota
• Montar o filesystem como cliente:
echo <client-key> > client.key
mount -t ceph <mon1>[,<mon2>,<monX]:/test /mnt -o name=test,secretfile=test.key
A partir desse ponto, pode-se utilizar o filesystem do CephFS no sistema
operacional como um sistema de arquivos normal.
Caso o cliente tente montar um diretório ao qual o mesmo não tem acesso,
o seguinte erro ocorrerá:
mount -t ceph <mon1>[,<mon2>,<monX]:/ /mnt -o name=test,secretfile=test.key
mount error 13 = Permission denied
138
14. Gerenciando usuários
14.1. Gerenciando usuários com acesso ao cluster
A estrutura básica de controle de acesso ao cluster Ceph utiliza a forma de
um keyring, onde fica armazenada a key
47
e os caps
48
. Um exemplo de chave
de autenticação é:
[client.username]
key = hAATGxhSLDe3deyifXw7iFhXQ==
caps mds = "allow rwp"
caps mgr = "allow r"
caps mon = "allow r"
caps osd = "allow rw pool=my_pool, allow r pool=read_only_pool"
Onde essa chave permite ao usuário chamado de username:
• mds: ler, escrever e definir o pool onde um diretório do CephFS vai ser
armazenado;
• mgr: ler metadados e estatísticas do ambiente;
• mon: ler os metadados do cluster;
• osd: ler e escrever no pool my_pool e apenas ler do pool read_only_pool.
Através do CLI é possível gerenciar o acesso de clientes ao cluster Ceph,
sendo as operações possíveis:
• Criar usuário:
ceph auth get-or-create client.<name> <daemon> 'allow [r|w|x|*] [pool=<pool-name>]
[namespace=<namespace>]' <daemon> 'allow [r|w|x|*] [pool=<pool-name>]
[namespace=<namespace>]' <daemon> 'profile [profile] [pool=<pool-name>]
[namespace=<namespace>]'
Onde os daemons possíveis são:
1. mon: controla o acesso aos monitors;
2. osd: controla o acesso aos OSDs;
47
Chave de acesso utilizado pelo cliente.
48
Capacidades da chave de acesso.
139
3. mgr: controla o acesso aos managers;
4. mds: controla o acesso aos metadata servers.
E as capacidades:
1. r: acesso de leitura
49
;
2. w: acesso de escrita
50
;
3. x: acesso de execução de funções
51
;
4. p: específico para MDS, permite definir o pool onde um diretório do
CephFS vai ser armazenado;
5. *: acesso total ao componente
52
;
6. profile: servem como alias que agregam capacidades para determi-
nados componentes e fins. Para maiores informações sobre os pro-
files default do Ceph, consulte a documentação oficial.
Além disso, as capacidades também podem restringir o usuário à deter-
minado pool e namespace, entre outros. Por exemplo, para criar um usuá-
rio com acesso à determinado pool:
ceph auth get-or-create client.test mon 'allow r' osd 'allow rw pool=pool-test'
Aqui é importante ressaltar que a capacidade de leitura do compo-
nente mon é necessário para todos os clientes, uma vez que os cli-
entes acessam os monitores para obterem o mapa do cluster. Além
disso, caso nenhum pool seja especificado, o cliente terá acesso à to-
dos os pools!
• Listar usuários:
ceph auth ls
49
read.
50
write.
51
exec.
52
all.
140
• Listar usuário específico:
ceph auth get client.<name>
ceph auth get client.<name> -o <client-authentication-file>
• Alterar capacidades de um usuário:
ceph auth caps client.<name> mon 'allow rw' osd 'allow rwx pool=another-pool'
ceph auth caps client.<name> mon 'allow *' osd 'allow *'
• Remover capacidades de um usuário:
ceph auth caps client.<name> mon ' ' osd ' ' <daemon> ' '
• Remover usuário:
ceph auth del client.<name>
14.1.1. Utilizando namespaces
Namespaces são a representação lógica de um grupo de objetos dentro de
um pool. O acesso de um usuário à determinado pool pode ser associado à
determinado namespace, de forma que o usuário só terá acesso ao pool se tiver
acesso ao namespace. Atualmente apenas aplicações RBD e CephFS suportam
o uso de namespaces.
Utilizando RBD:
• Criar namespace
53
:
rbd namespace create --namespace <namespace> --pool <replicated>
• Criar usuário com acesso ao pool e namespace:
ceph auth get-or-create client.<name> mon 'profile rbd' osd 'profile rbd pool=<replicated>
namespace=<namespace>[, profile rbd pool=<erasure>]'
• Criar imagem utilizando o namespace:
rbd create --namespace <namespace> --size <int>G <replicated>/<image-name>
rbd create --namespace <namespace> --size <int>G --data-pool <erasure> <replicated>/<image-name
>
53
Ao criar um namespace, sempre será informado o pool ao qual tal namespace pertence.
Além disso, apenas pools do tipo replicado suportam o uso de namespaces. Por fim, apenas o
usuário admin tem permissões de criar namespaces.
141
• Listar e mapear a imagem criada:
rbd --namespace <namespace> ls <replicated> -n client.<name> --keyring=<path-to-key-file>
rbd --namespace <namespace> map <replicated>/<image-name> -n client.<name>
--keyring=<path-to-key-file>
• Listar namespaces:
rbd namespace ls [-p <pool-name>]
54
• Remover imagem do namespace:
rbd rm --namespace <namespace> <pool>/<image-name> -n client.<name> --keyring=<path-to-key-file
>
• Remover namespace
55
:
rbd namespace remove <pool>/<namespace>
14.2. Gerenciando usuários do dashboard
É possível gerenciar os usuários que têm acesso ao dashboard de duas for-
mas:
1. Via CLI:
• Listar todos os usuários:
ceph dashboard ac-user-show
• Listar usuário específico:
ceph dashboard ac-user-show <username>
• Criar usuário:
ceph dashboard ac-user-create <username> -i <file-with-user-password>
Aqui é importante ressaltar que o Ceph não permite nomes de usuá-
rios duplicados.
54
Por padrão, apenas os namespaces associados ao pool default de nome rb d são listados.
Para verificar os namespaces de outros pools via linha de comando, é necessário passar o nome
do pool.
55
Caso o namespace já possua uma imagem associada à ele, o procedimento correto consiste
em primeiro remover a imagem para, só então, remover o namespace. Além disso, apenas o
usuário admin consegue remover namespaces.
142
• Desabilitar usuários após múltiplas tentativas incorretas de login:
Por padrão, o Ceph irá desabilitar a conta de um usuário caso o mesmo
efetue mais de 10 tentativas incorretas de login. Esse comportamento
visa evitar ataques de força bruta sobre o cluster, podendo ser alte-
rado com o comando:
ceph dashboard set-account-lockout-attempts <int> # valor inteiro
Caso deseje-se desabilitar esse comportamento, basta utilizar o co-
mando passando o valor de 0:
ceph dashboard set-account-lockout-attempts 0
• Habilitar/reabilitar usuário:
Caso um usuário tenha sido desabilitado, seja devido à múltiplas ten-
tativas de login incorretas ou por algum outro motivo, o mesmo pode
ser habilitado/reabilitado com o comando:
ceph dashboard ac-user-enable <username>
• Desabilitar usuário:
ceph dashboard ac-user-disable <username>
• Remover usuário:
ceph dashboard ac-user-delete <username>
• Alterar senha do usuário:
ceph dashboard ac-user-set-password <username> -i <file-with-user-password>
• Alterar nome e e-mail do usuário:
ceph dashboard ac-user-set-info <username> <new-username> <new-email>
• Habilitar/desabilitar política de senhas:
Por padrão, o Ceph possui uma política de senhas de usuários, que
consiste em uma senha com no mínimo 8 caracteres, além de não
ser permitida a atualização da senha para o mesmo valor do antigo.
143
Essa política pode ser habilitada/desabilitada com o comando:
ceph dashboard set-pwd-policy-enabled true|false
Sendo algumas verificações adicionais que podem ser habilitadas/-
desabilitadas:
ceph dashboard set-pwd-policy-min-length <int> # Tamanho mínimo da senha dos usuários
ceph dashboard set-pwd-policy-check-length-enabled [true|false] # Se o tamanho mínimo
definido na política anterior será checado, tanto na hora de criar a senha, quanto
na hora de a alterar
ceph dashboard set-pwd-policy-check-oldpwd-enabled [true|false]} # Verificar se o usuário
, ao alterar a senha, poderá atualizar para a mesma
ceph dashboard set-pwd-policy-check-username-enabled [true|false]} # Se a senha pode
conter o nome do usuário
ceph dashboard set-pwd-policy-exclusion-list palavra1[,palavra2,...]} # Uma lista de
palavras que não podem ser usadas na senha
ceph dashboard set-pwd-policy-check-exclusion-list-enabled [true|false]} # Se a lista de
palavras proibidas na senha vai ser verificada
ceph dashboard set-pwd-policy-check-complexity-enabled [true|false]} # Se a complexidade
da senha vai ser verificada
ceph dashboard set-pwd-policy-check-sequential-chars-enabled [true|false]} # Se a senha
pode ter caracteres sequências, como "abcde"
ceph dashboard set-pwd-policy-check-repetitive-chars-enabled [true|false]} # Se a senha
pode ter caracteres repetidos, como ``aaaaa''
• Alterar complexidade mínima da senha:
ceph dashboard set-pwd-policy-min-complexity <int>
Onde o valor da complexidade da senha é calculado, a partir do valor
de 0, lendo cada caractere da senha, e sendo incrementado por um
valor inteiro, caso o caractere lido se enquadre em uma das seguintes
regras:
– Se o caractere é um dígito, incremente a complexidade em +1;
– Se o caractere é uma letra em lowercase, incremente a complexi-
dade em +1;
– Se o caractere é uma letra em uppercase, incremente a comple-
xidade em +2;
– Se o caractere é um caracter especial, como !"\#\$\%~, incre-
mente a complexidade em +3;
– Se o caractere não se enquadra em nenhuma das regras anteri-
144
Figura 76: Selecionando usuário específico
Figura 77: Verificando detalhes de um usuário específico
• Criar usuário:
Figura 78: Criando novo usuário
146
Figura 79: Especificando detalhes do novo usuário
• Editar usuário:
Figura 80: Editando usuário
147
Figura 81: Editando usuário
• Remover usuário:
Figura 82: Removendo usuário
148
Figura 83: Confirmando remoção do usuário
14.3. Gerenciando usuários do RGW
É possível gerenciar os usuários que têm acesso ao RGW de duas formas:
1. Via CLI:
• Listar usuários:
radosgw-admin user list
• Listar detalhes do usuário:
radosgw-admin user info --uid <username>
• Criar usuário:
radosgw-admin user create --uid=<username> --display-name="username" --email=<email>
• Criar subusuário:
radosgw-admin subuser create --uid=<father-username> --subuser=<username> --access=[read,
write,readwrite,full]
• Editar usuário:
radosgw-admin user modify --uid=<username> --display-name='New Name like Jake'
Demais parâmetros que podem ser alterados podem ser checados
com o comando:
radosgw-admin user modify --uid=<username>
• Remover usuário:
radosgw-admin user rm --uid=<username>
149
• Habilitar/desabilitar um usuário:
radosgw-admin user enable --uid=<username>
radosgw-admin user suspend --uid=<username>
• Criar quota de usuário:
radosgw-admin quota set --quota-scope=user --uid=<username> --max-objects=<max-obj> --max
-size=<max-size>
• Habilitar/desabilitar quota de um usuário:
radosgw-admin quota enable --quota-scope=user --uid=<username>
radosgw-admin quota disable --quota-scope=user --uid=<username>
2. Via dashboard:
• Listar usuários:
Figura 84: Listando usuários
• Listar detalhes do usuário:
150
Figura 85: Listando detalhes do usuário
• Criar usuário:
Figura 86: Criando novo usuário
151
Figura 87: Especificando detalhes do novo usuário
• Criar subusuário:
152
Figura 88: Selecionando usuário “pai”
Figura 89: Criando subusuário
153
Figura 90: Especificando detalhes do subusuário
• Editar usuário:
Figura 91: Selecionando usuário para editar
154
Figura 92: Editando usuário
155
• Remover usuário:
Figura 93: Removendo usuário
Figura 94: Confirmando remoção do usuário
156
15. iSCSI
Na versão da comunidade do ce ph-ansible, apenas sistemas operacionais
derivados da RedHat possibilitam o deploy de gateways iSCSI. Isso se dá devido à
uma checagem no próprio playbook. Porém, a mesma foi contornada na versão
disponibilizada pela SC Clouds.
15.1. Uso
É possível acessar e utilizar os gateways iSCSI no Windows, Linux e VMware.
Para tal os passos básicos são:
1. Crie uma nova imagem RBD:
Para tal, primeiro é necessário criar um novo pool e associá-lo à aplicações
do tipo RBD
57
. Com o pool e imagens criados, para a criação dos targets
iSCSI, pode-se utilizar o dashboard ou a linha de comando em um dos
gateways através do utilitário gwcli.
2. Via dashboard:
(a) Acesse a aba de Targets dos gateways iSCSI e crie um novo target:
Figura 95: Acessando os targets iSCSI
57
Caso já não exista nenhum pool RBD criado para esse propósito, veja a Seção 9 para mai-
ores informações.
157
Figura 96: Criando novo target iSCSI
(b) Na tela de criação de Targets, crie um novo target:
Figura 97: Detalhes na criação de um novo target iSCSI
158
Figura 98: Exemplo de configuração parcial de um novo target iSCSI
Neste ponto, não será abordado como obter o Initiator name dos
159
hosts que irão consumir o target iSCSI. Tal explicação será abordada
mais a frente, ao descrever o método de conexão com o iSCSI através
do Windows e do Linux.
(c) Com o Initiator Name copiado do host alvo, retorne ao Ceph, e adici-
one esse nome na seção Initiators do target iSCSI:
Figura 99: Adicionando Initiator
Lembrando que o mesmo target iSCSI pode utilizar várias imagens e
ter vários initiators.
(d) Isso irá adicionar um novo initiator nos gateways iSCSI, mas não irá
fazer o login do cliente automaticamente:
160
Figura 100: Target criado
Com isso, os passos básicos para a criação de um target iSCSI foram
finalizados. As configurações do lado dos clientes serão abordadas
nas subseções abaixo.
3. Via linha de comando:
(a) Em um dos gateways iSCSI, gerar um IQN válido e executar o utilitário
gwcli:
root@iscsi1:~# iscsi-iname
iqn.2005-03.org.open-iscsi:25ba86cd5e89
root@iscsi1:~# gwcli
/>
(b) Criar um novo target e adicionar os gateways:
/> cd /iscsi-targets
/iscsi-targets> create iqn.2005-03.org.open-iscsi:25ba86cd5e89 # Comando 'create <iqn-
name>'
ok
/iscsi-targets> cd iqn.2005-03.org.open-iscsi:25ba86cd5e89/gateways # Comando 'cd <iqn-
name>/gateways'
/iscsi-target...5e89/gateways> create iscsi1 192.168.122.243 # Comando 'create <gateway-
name> <gateway-ip> [skipchecks=true]'. O parâmetro skipchecks=true pode ser
utilizado para ignorar validações, como certificados válidos entre os gateways.
Adding gateway, sync'ing 0 disk(s) and 0 client(s)
ok
/iscsi-target...5e89/gateways> create iscsi2 192.168.122.244
Adding gateway, sync'ing 0 disk(s) and 0 client(s)
ok
(c) Criar um novo disco:
161
/iscsi-target...5e89/gateways> cd /disks
/disks> create pool=rbd image=name size=10G # Aqui deve-se alterar o pool, imagem e
tamanho de acordo com o desejado
ok
(d) Criar um novo initiator e adicionar um disco para o mesmo:
cd /iscsi-targets/<iqn>/hosts
create <iqn-client>
cd <iqn-client>
disk add pool/image
(e) Desabilitar autenticação ACL:
Ao desabilitar a autenticação ACL, qualquer initiator poderá acessar
qualquer LUN no destino correspondente:
cd /iscsi-targets/<iqn>/hosts
/iscsi-target...testvol/hosts> auth disable_acl
(f) Utilizar CHAP para autenticação:
cd /iscsi-targets/<iqn>/hosts/<iqn-client>
/iscsi-target...:iqn-client> auth username=common12 password=pass12345678
15.1.1. Clientes Windows
Para o acesso aos gateways iSCSI através de hosts Windows, incluindo a pos-
sibilidade de utilizar multipath, os passos necessários são:
1. Verificar se o Multipath-IO está instalado:
Get-WindowsFeature -Name 'Multipath-IO'
2. Caso o mesmo não esteja instalado, o instale com o comando:
Add-WindowsFeature -Name 'Multipath-IO'
162
Figura 101: Instalando o Multipath-IO
3. Verifique as configurações do Multipath-IO:
A configuração de timeout para que o Windows se conecte com o outro
gateway iSCSI é feita do lado do cliente, tendo o valor padrão de 10 mi-
nutos. Para verificar as configurações atuais do Multipath-IO, o comando
utilizado é:
Get-MPIOSetting
Figura 102: Configurações atuais do Multipath-IO
4. Configure o Multipath-IO:
Para configurar o Multipath-IO para atender as demandas do cliente, o
comando a ser utilizado é:
Set-MPIOSetting -NewPathRecoveryInterval <int> -CustomPathRecovery <Enabled|Disabled> -
NewPDORemovePeriod <int> -NewDiskTimeout <int> -NewPathVerificationState <Enabled|Disabled
> -NewRetryInterval <int> -NewRetryCount <int>
163
Figura 103: Alterando as configurações do Multipath-IO
Após isso, reinicie o sistema para completar a instalação/configuração do
Multipath-IO.
5. Configure o MPIO:
Após reiniciar o sistema, execute o programa MPIO, vá na aba Discover
Multi-Paths e adicione a opção Add support for iSCSI devices. Em seguida,
reinicie novamente o sistema:
Figura 104: Habilitando o multipath no programa MPIO
6. Obtenha o Initiator name da máquina:
164
Execute o programa iSCSI Initiator:
Figura 105: Utilizando o programa iSCSI Initiator no Windows
Vá até as configurações do initiator:
Figura 106: Acessando configurações do iSCSI Initiator
165
Figura 108: Quick Connect
167
Figura 109: Confirme a conexão
8. Ainda no programa iSCSI Initiator, edite a conexão criada para habilitar o
multipath:
Figura 110: Habilitando o multipath no initiator
E, na aba Advanced, configure o multipath, informando um dos gateways
iSCSI:
168
Figura 111: Adicionando um dos gateways na conexão
9. Repita o passo anterior para todos os gateways existentes.
10. Após isso, a imagem pode ser verificada acessando os Devices dos targets:
169
Figura 112: Acessando devices disponíveis
170
Figura 113: Detalhes do device disponível
11. Após isso, basta formatar esse device com o utilitário do Windows e passar
a usá-lo como um disco físico qualquer:
171
Figura 114: Formatando o novo device
172
Figura 115: Device formatado
Figura 116: Agora o device pode ser utilizado como um disco qualquer
15.1.2. Clientes Linux
Para o acesso aos gateways iSCSI via hosts Linux, é necessário ter os pacotes
open-iscsi e multipath-tools instalados
58
. Com tais pacotes instalados, é pos-
sível obter o initiator name da máquina no arquivo /etc/i scsi/initi atorname.isc
58
O nome dos pacotes pode variar de acordo com a distro utilizada.
173
si e utilizá-lo na criação de um target iSCSI, conforme descrito na Seção 15.1.
Após isso, é possível realizar a descoberta dos gateways e posterior login com
os comandos:
iscsiadm -m discovery -t st -p <gateway-ip>
root@client-1:~# iscsiadm -m discovery -t st -p 192.168.122.243
192.168.122.243:3260,1 iqn.2001-07.com.ceph:1684157452672
192.168.122.244:3260,2 iqn.2001-07.com.ceph:1684157452672
192.168.122.243:3260,1 iqn.2005-03.org.open-iscsi:25ba86cd5e89
192.168.122.244:3260,2 iqn.2005-03.org.open-iscsi:25ba86cd5e89
iscsiadm -m node -T iqn.2006-04.com.example:3260 --login # Login em um target específico
iscsiadm -m node --login # Caso o initiator pertença a apenas um target
iscsiadm -m node -T iqn.2006-04.com.example:3260 --logout # Logout em um target específico
iscsiadm -m node --logout
multipath -r # Forçar o reload do multipath
multipath -ll # Exibir a topologia do multipath
root@client-1:~# multipath -ll
mpathc (360014055c5f6be08e114c56b1835c636) dm-1 LIO-ORG,TCMU device
size=10G features='0' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 7:0:0:0 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
`- 6:0:0:0 sda 8:0 active ready running
Após o login e, se necessário, reload do multipath, o disco disponibilizado via
iSCSI será apresentado como novos dispositivos, um para cada gateway confi-
gurado e um para o multipath:
Disk /dev/sda: 10 GiB, 10737418240 bytes, 20971520 sectors
Disk model: TCMU device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 524288 bytes
Disk /dev/sdb: 10 GiB, 10737418240 bytes, 20971520 sectors
Disk model: TCMU device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 524288 bytes
Disk /dev/mapper/mpathc: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 524288 bytes
A partir desse ponto, o bloco pode ser formatado e utilizado como um disco
normal pelo sistema operacional.
174
Parte V
Conceitos avançados e processos
do Ceph
O presente capítulo se destina a detalhar conceitos e processos avançados do
cluster Ceph.
175
16. BlueStore
BlueStore é um sistema de arquivos nativo do Ceph projetado para melho-
rar o desempenho e a escalabilidade do armazenamento distribuído. Bluestore
é a alternativa recomendada ao uso de Filestore, que foi o primeiro modo de
backend suportado pelo Ceph. Usa uma estrutura de dados otimizada para ar-
mazenar objetos em blocos de tamanho variável, permitindo o acesso rápido
e a recuperação rápida em caso de falhas. Uma das principais vantagens do
BlueStore é sua capacidade de usar cache de memória para acelerar o acesso
aos dados. Utiliza uma estratégia de cache em camadas, onde os dados são
mantidos em três camadas: cache de leitura, cache de gravação e cache de me-
tadados.
O cache de leitura é usado para armazenar os dados que foram lidos re-
centemente e são frequentemente acessados, enquanto o cache de gravação
é usado para armazenar os dados que estão sendo gravados atualmente. O
cache de metadados é usado para armazenar as informações sobre os objetos
armazenados no BlueStore.
O tamanho do bloco usado pelo BlueStore é configurável, permitindo que
os usuários ajustem o desempenho do cluster com base em seus requisitos es-
pecíficos. O tamanho do bloco afeta diretamente o desempenho do ambiente,
pois determina a quantidade de dados que podem ser lidos ou gravados de
uma vez. Blocos maiores podem melhorar o desempenho de leitura, pois re-
duzem o número de operações de leitura necessárias para acessar um objeto.
No entanto, eles podem ter um impacto negativo no desempenho de gravação,
pois uma gravação de um objeto grande pode exigir a reescrita de um bloco
inteiro. Por outro lado, blocos menores podem melhorar o desempenho de
gravação, pois permitem que as gravações sejam agrupadas em blocos me-
nores. No entanto, eles podem ter um impacto negativo no desempenho de
leitura, pois exigem mais operações de leitura para recuperar um objeto.
O conjunto de parâmetros de configuração do BlueStore, incluem:
176
• bluestore_block_size: define o tamanho do bloco usado pelo BlueStore.
O tamanho padrão é de 4 KB
59
, mas pode ser aumentado ou diminuído
dependendo das necessidades de desempenho e capacidade do cluster.
Um bloco maior pode melhorar o desempenho de leitura, enquanto um
bloco menor pode melhorar o desempenho de gravação;
• bluestore_cache_size: define o tamanho máximo do cache de leitura usada
pelo BlueStore. Afeta o desempenho de leitura, pois o cache de leitura é
usada para armazenar os dados frequentemente acessados. O valor pa-
drão é de 1 GB, mas pode ser ajustado com base na memória disponível
no cluster;
• bluestore_cache_meta_ratio: define a proporção de memória que será
usada para o cache de metadados em relação ao tamanho do cache de
leitura. O valor padrão é de 0,25, o que significa que 25% do tamanho do
cache de leitura será usado para o cache de metadados;
• bluestore_compression_algorithm: define o algoritmo de compressão
usado pelo BlueStore para compactar os dados. O valor padrão é snapp
y, mas outros algoritmos, como zlib e lz4, também estão disponíveis;
• bluestore_max_blob_size: define o tamanho máximo de um objeto ar-
mazenado no Bluestore. O valor padrão é de 64 MB, mas pode ser aumen-
tado ou diminuído dependendo das necessidades de armazenamento do
cluster.
Esses são alguns dos parâmetros de configuração disponíveis no BlueStore.
É importante ajustar esses parâmetros de acordo com as necessidades espe-
59
O valor padrão para HDD nas versões anteriores a Pacific era de 64 KB, entretanto, as novas
versões do Ceph utilizam o valor 4 KB como tamanho padrão para o tamanho de bloco tanto
para HDD quanto para SSD.
177
cíficas do ambiente para obter o melhor desempenho e capacidade de arma-
zenamento possível.
178
17. Bucket policies
A partir da versão Luminous o Ceph oferece suporte a um subconjunto da
linguagem de política do protocolo Amazon S3, chamado de bucket policies, que
se refere às políticas de acesso e permissões aplicadas aos buckets do RadosGW.
O RadosGW fornece uma interface S3 e Swift para o Ceph, permitindo que os
usuários acessem e gerenciem objetos usando clients para consumir o proto-
colo S3 (i.e. S3tools e/ou Boto3 S3 Client).
As bucket policies permitem que clientes controlem as permissões de acesso
aos buckets e aos objetos contidos neles. Essas políticas são escritas em for-
mato ACL (Access Control Language) e podem ser aplicadas em nível de bucket
para definir quem pode fazer o quê com os objetos dentro do bucket. Por exem-
plo, os clientes podem criar políticas que permitem que um grupo específico de
usuários faça upload de objetos, enquanto outro grupo tem permissão apenas
de leitura. As políticas são baseadas no modelo de controle de acesso da Ama-
zon Web Services (AWS) para o serviço S3. Portanto, é necessário usar a sintaxe
e as estruturas de políticas semelhantes às usadas no S3 da AWS.
{
"Version": "2023-05-30",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": ["arn:aws:iam::usfolks:user/fred:subuser"]},
"Action": "s3:PutObjectAcl",
"Resource": [
"arn:aws:s3:::happybucket/*"
]
}]
}
As políticas são flexíveis e permitem que se defina permissões granulares,
especificando ações permitidas ou negadas para usuários, grupos de usuários
ou até mesmo para endereços IP específicos. Com essas políticas, é possível
controlar o acesso, a autenticação e a autorização para objetos no Ceph.
17.1. Limitações
As bucket policies no Ceph (versão Quincy) e as políticas da AWS S3 possuem
algumas diferenças e limitações. A lista completa de ações suportadas no Ceph
179
pode ser observado através da documentação oficial do Ceph.
Algumas das limitações das bucket policies no Ceph incluem:
• Granularidade: as bucket policies no Ceph permitem definir permissões
de leitura/escrita de objetos e metadados, mas não oferecem granulari-
dade para ações específicas em objetos, como leitura, escrita, exclusão,
entre outros. Isso significa que as políticas aplicam-se a todas as ações
em objetos dentro de um bucket;
• Complexidade da sintaxe: a sintaxe para escrever bucket policies no Ceph
pode ser mais complexa em comparação com as políticas da AWS S3. A
sintaxe do Ceph utiliza a linguagem de controle de acesso da Amazon ACL
(Access Control Language) para definir as permissões, o que pode ser um
pouco mais difícil de aprender e utilizar corretamente;
• Falta de integração com outros serviços AWS: o Ceph é uma solução de ar-
mazenamento distribuído de código aberto que pode ser usado em con-
junto com a AWS, mas não possui uma integração nativa com os servi-
ços da AWS. Isso significa que as bucket policies do Ceph não possuem
os recursos avançados de integração com outros serviços da AWS, como
políticas de serviço;
• Escopo: as bucket policies do Ceph são definidas no nível do bucket, o que
significa que se aplicam a todos os objetos dentro do bucket. Por outro
lado, as políticas da AWS S3 podem ser aplicadas em níveis mais granula-
res, como buckets e objetos específicos;
• Sintaxe e formato: a sintaxe e o formato das bucket policies do Ceph e da
AWS S3 são diferentes. O Ceph usa a linguagem ACL para definir permis-
sões, enquanto a AWS S3 utiliza a AWS Policy Language, que é baseada em
JSON.
180
18. Ceph scrub
No Ceph, scrub é o processo de verificação e correção de erros nos dados
armazenados em ambientes Ceph. Scrub é um processo executado periodica-
mente em segundo plano, que verifica os dados armazenados em OSDs para
detectar possíveis erros de hardware, corrupção de dados ou outras inconsis-
tências. Durante o processo de scrub, cada objeto é verificado e comparado
com seus checksums para garantir que os dados estejam íntegros. Se houver al-
guma inconsistência detectada, o Ceph tenta corrigir o problema recuperando
o objeto a partir de outras réplicas ou partes do objeto armazenadas em outros
OSDs. Além disso, é um processo contínuo e automático que não requer inter-
venção do usuário, tornando-o uma parte essencial da operação de ambientes
Ceph.
O processo de scrub no Ceph pode ser realizado tanto no nível do cluster
quanto no nível do Ceph File System (CephFS), pode também ser agendado de
forma apropriada, evitando interrupções na performance do cluster. O tempo
de execução do scrub pode variar dependendo do tamanho do cluster e do
volume de dados armazenados. O processo ajuda a garantir a integridade dos
dados armazenados, prevenir a perda de dados em caso de falhas de hardware
ou corrupção de dados e pode ser realizado de forma incremental, verificando
somente os dados que foram alterados desde a última verificação, ou pode ser
realizado em todo o ambiente.
Para configurar o processo de scrub, é necessário editar o arquivo de confi-
guração ceph.con f; as configurações podem variar dependendo da versão do
Ceph utilizado. Abaixo estão listados os parâmetros que regem o comporta-
mento do Ceph scrub e um exemplo de configuração.
• osd_scrub_interval: determina o intervalo de tempo entre cada execu-
ção do processo de scrub. O valor padrão é de 60 minutos (1 hora), mas
pode ser configurado de acordo com suas necessidades;
181
• osd_scrub_load_threshold: determina a carga máxima do OSD no qual
o processo de scrub não será executado. Útil para evitar sobrecarga do
sistema. O valor padrão é de 0,5 (50% da carga máxima), mas pode ser
ajustado de acordo com suas necessidades;
• osd_scrub_chunk_max: determina o número máximo de objetos a se-
rem verificados por vez durante o processo de scrub. O valor padrão é de
5, mas pode ser aumentado para acelerar o processo de scrub;
• mds_scrub_interval: determina o intervalo de tempo entre cada execu-
ção do processo de scrub no CephFS. O valor padrão é de 60 minutos (1
hora), mas pode ser configurado de acordo com suas necessidades;
• mds_scrub_max_inodes: determina o número máximo de arquivos e di-
retórios a serem verificados por vez durante o processo de scrub no CephFS.
O valor padrão é de 10000, mas pode ser aumentado para acelerar o pro-
cesso de scrub.
[global]
osd_scrub_interval = 24
osd_scrub_load_threshold = 0.5
osd_scrub_chunk_max = 25
[mds]
mds_scrub_max_inodes = 100000
mds_scrub_interval = 24
Existem dois tipos de Scrubbing no Ceph: o light Scrubbing e o deep scrub-
bing. light Scrubbing é um processo de verificação menos intenso no Ceph, que
tem como objetivo verificar os atributos e o tamanho dos objetos armazena-
dos nos OSDs. Esse processo é executado diariamente por padrão e é menos
exigente em termos de recursos do cluster, em comparação com o deep scrub-
bing. Durante o light Scrubbing, o Ceph verifica os atributos dos objetos arma-
zenados nos OSDs, como o tamanho, a data de modificação e os metadados.
Esse processo ajuda a identificar problemas de armazenamento, como objetos
182
ausentes ou corrompidos, bem como dados com atributos incorretos. Ao de-
tectar esses problemas, o Ceph pode corrigi-los automaticamente ou alertar os
administradores sobre eles. O light Scrubbing é uma prática recomendada para
manter a integridade dos dados e garantir que o ambiente Ceph esteja funci-
onando corretamente. É possível configurar a frequência do light Scrubbing no
arquivo ceph.conf do cluster, ajustando os parâmetros osd_scr ub_begin_hour
e osd_scrub_end_hour. Por padrão, o processo é executado diariamente de 1h
às 3h da manhã.
Para executar um light Scrubbing manualmente use o comando abaixo, subs-
titua <osd_i d> pelo ID do OSD que se deseja verificar. Este comando inicia o
processo de light Scrubbing no OSD especificado.
~$ ceph osd scrub <osd_id>
~$ ceph osd scrub all|any # faz em todos
Deep scrubbing é um processo de verificação mais intenso, que tem como
objetivo verificar a integridade dos dados armazenados nos OSDs. Diferente-
mente do light Scrubbing, o deep scrubbing realiza uma leitura completa dos
dados armazenados em cada OSD, usando checksums para garantir que os da-
dos estejam corretos. Durante o processo de deep scrubbing, o Ceph lê todos
os objetos armazenados em um OSD e verifica a integridade dos dados usando
checksums. Esse processo pode ser bastante exigente em termos de recursos
do cluster, pois envolve a leitura completa de todos os dados armazenados em
cada OSD. Por padrão o deep scrubbing é executado uma vez por semana du-
rante a madrugada (horário local), entretanto, essas configurações podem ser
alteradas conforme necessário editando o arquivo ceph.c onf. Os parâmetros
que regem o comportamento do deep scrubbing, incluem:
• osd_deep_scrub_interval: determina o intervalo de tempo entre as ope-
rações de deep scrub. O valor padrão é de 1 dia;
• osd_deep_scrub_randomize_ratio: determina a proporção de objetos
que serão verificados durante cada operação de deep scrub. O valor pa-
183
drão é de 0,1, o que significa que 10% dos objetos serão verificados du-
rante cada operação;
• osd_deep_scrub_stride: determina o tamanho dos blocos de objetos que
são verificados durante o deep scrub. O valor padrão é de 65536 bytes;
• osd_deep_scrub_concurrency: define o número de operações de deep
scrub que podem ser executadas simultaneamente em um nó do Ceph.
Por padrão, o valor é definido como o número de núcleos de CPU dispo-
níveis no nó;
• osd_deep_scrub_large_omap_object_size: define o tamanho máximo do
objeto que será verificado durante o deep scrub. Por padrão, o valor é
definido como 4096 bytes;
• osd_deep_scrub_tier_delay: define o atraso entre as operações de deep
scrub em camadas de armazenamento de cache e camadas de armaze-
namento de base. O valor padrão é de 0 segundos, o que significa que o
deep scrub é executado simultaneamente em todas as camadas.
Para executar um deep scrubbing manualmente use o comando abaixo, subs-
titua <osd_i d> pelo ID do OSD que se deseja verificar. Este comando inicia o
processo de deep scrubbing no OSD especificado.
~$ ceph osd deep-scrub <osd_id>
~$ ceph osd deep-scrub all|any # idem sobre fazer em todos
O processo de scrubbing no Ceph é uma etapa importante da administração
e manutenção de um ambiente Ceph, garantindo a integridade e a disponibi-
lidade dos dados armazenados. O administrador do sistema deve monitorar
regularmente o status do processo de scrubbing para garantir que está sendo
executado conforme o planejado. Existem várias maneiras de monitorar o pro-
cesso de scrubbing no Ceph. Uma das mais simples é usar o comando ceph stat
us, que exibe informações sobre o estado geral do cluster, incluindo o status do
184
processo de scrubbing. Outra maneira de monitorar o processo de scrubbing
é por meio da interface gráfica do Ceph, como o Ceph Dashboard. Através da
interface, os operadores podem verificar o status de cada nó do cluster e ver de-
talhes sobre o progresso do processo de scrubbing. Além disso, os operadores
podem usar ferramentas de monitoramento de terceiros, como o Nagios ou o
Zabbix, para monitorar o status do processo de scrubbing e receber alertas em
caso de falhas ou problemas.
185
19. Compressão de dados
O Ceph utiliza técnicas de compressão de dados para reduzir o espaço ne-
cessário de armazenamento e possui suporte a diversos algoritmos de com-
pressão, incluindo:
• LZ4: algoritmo de compressão rápido que é útil para reduzir a latência de
leitura e gravação. Ele pode ser usado em ambientes de armazenamento
em que a latência é crítica, como no armazenamento de banco de dados;
• Snappy: algoritmo de compressão rápido e eficiente em termos de es-
paço, que pode ser usado em ambientes em que o espaço é limitado,
como no armazenamento em nuvem;
• Zlib: algoritmo de compressão mais lento, mas mais eficiente em termos
de espaço, útil para reduzir a utilização de espaço em disco. Pode ser
usado em ambientes em que o espaço é uma preocupação, como no ar-
mazenamento de arquivos;
• Bzip2: algoritmo de compressão muito eficiente em termos de espaço,
mas mais lento que o zlib. Útil em cenários em que a utilização de espaço
em disco é um fator crítico e a taxa de compressão é mais importante do
que a velocidade de acesso aos dados.
Além dos algoritmos de compressão, o Ceph suporta dois modos de com-
pressão:
• aggressive: este modo é o mais eficiente em termos de compressão e,
portanto, oferece a melhor taxa de redução de tamanho de dados. Entre-
tanto, requer mais recursos de CPU para a compressão e descompressão
dos dados. Útil para ambientes de armazenamento em que a economia
de espaço em disco é uma prioridade e há recursos de CPU disponíveis
para lidar com a carga adicional;
186
• passive: este modo oferece uma compressão mais leve, com menor im-
pacto na CPU, mas com uma taxa de redução de tamanho de dados me-
nor. Útil em ambientes em que a economia de espaço em disco é uma
preocupação, mas a carga de CPU adicional é indesejável;
• force: o Ceph irá comprimir todos os dados, mesmo aqueles que não são
considerados candidatos para compressão. Pode resultar em uma maior
taxa de compressão, mas também pode aumentar a sobrecarga de CPU
durante a gravação e leitura de dados.
Para habilitar a compressão de dados é necessário editar o arquivo de con-
figuração do Ceph (/etc/ceph/ceph.conf) e adicionar as linhas:
osd compression algorithm = << algorithm >>
osd compression mode = << aggressive | passive >>
Após editar o arquivo, é necessário reiniciar o serviço OSD para que as al-
terações tenham efeito. O comando abaixo é um exemplo de como reiniciar o
serviço OSD. Substitua <ID_OSD> pelo ID do OSD que deseja reiniciar.
~$ systemctl restart ceph-osd@<ID_OSD>
Quando é alterado o algoritmo de compressão no Ceph, os dados existen-
tes não são automaticamente descomprimidos e recomprimidos com o novo
algoritmo. Isso ocorre para evitar a sobrecarga do sistema e a perda de de-
sempenho durante o processo de descompressão e recompressão dos dados.
Entretanto, o Ceph preserva nos metadados o algoritmo que foi utilizado para
comprir os dados, dessa forma os dados que já estavam comprimidos podem
ser lidos de forma transparente e, a partir do momento em que o algoritmo
de compressão é alterado, os novos dados gravados no Ceph serão comprimi-
dos usando o novo algoritmo definido. Caso seja necessário aplicar um novo
algoritmo aos dados existentes, é necessário que seja feito de forma manual
executando uma ferramenta de migração de dados, como o Rados Gateway ou
o Rados Block Device, que permitem a migração de dados entre pools de arma-
zenamento sem afetar a disponibilidade do cluster.
187
20. Deduplicação de dados
A deduplicação de dados ainda não foi implementada oficialmente no Ceph.
Embora existam projetos em andamento para adicioná-la, atualmente não há
uma implementação pronta para uso na versão estável atual do Ceph (Quincy
- 2022-04-19). Trata-se de uma funcionalidade complexa e requer muito tra-
balho para ser implementada de forma segura e eficiente em um sistema de
armazenamento distribuído como o Ceph. No entanto, é possível usar ferra-
mentas externas para adicionar suporte à funcionalidade no Ceph. Algumas
das iniciativas promissoras incluem
60
:
• Ceph-dedup - Projeto de código aberto para adicionar suporte a dedupli-
cação no Ceph. Funciona adicionando uma camada de armazenamento
entre o cliente e o cluster Ceph, e usa um algoritmo de deduplicação ba-
seado em blocos para identificar e remover dados duplicados. Projetado
para trabalhar com o backend de armazenamento BlueStore do Ceph.
• BlueStore Inline Deduplication: Projeto sendo desenvolvido como um
novo módulo que pode fornecer suporte a deduplicação em nível de ob-
jeto no Ceph. Esse módulo está em fase experimental, e ainda não está
disponível em uma versão de produção do Ceph.
Em relação à segurança e à estabilidade, é importante lembrar que qualquer
recurso experimental pode apresentar riscos. A deduplicação é uma técnica
complexa que pode afetar a integridade dos dados se não for implementada
corretamente. É importante ressaltar que a deduplicação pode ser um pro-
cesso intensivo em termos de recursos, o que pode afetar o desempenho do
sistema. Além disso, pode não ser a solução ideal para todos os casos de uso
60
Além das iniciativas apresentadas, a documentação oficial do Ceph disponibiliza um passo
a passo para configurar e habilitar deduplicação utilizando máquinas RADOS Ceph - Dedu-
plication. Entretanto, o time da SC Clouds não recomenda a utilização dessas soluções em
ambientes de produção sem a devida análise e validação por se tratarem de funcionalidades
experimentais.
188
de armazenamento, dependendo do tipo de dados e dos padrões de uso. Por
isso, o time da SC Clouds recomenda avaliar cuidadosamente as necessidades
de armazenamento e considerar as opções disponíveis antes de implementar
uma solução. Além disso, a deduplicação de dados pode trazer benefícios em
termos de economia de espaço de armazenamento, mas também pode au-
mentar a carga de trabalho do sistema, especialmente durante a gravação de
dados. Portanto, é importante considerar cuidadosamente as vantagens e des-
vantagens antes de implementá-la.
189
21. Snapshots
Snapshot é uma cópia que suporta apenas leitura de um dado em um deter-
minado ponto do tempo, podendo ser utilizado para restaurar o dado, servindo
como forma de proteção do mesmo. O Ceph possui dois tipos de snapshots:
1. Snapshot de pool:
É possível realizar o snapshot de um pool por completo
61
. As operações
possíveis são:
• Criar a snapshot do pool:
Aqui é importante frisar que o nome da snapshot deve ser único no
pool.
ceph osd pool mksnap <pool-name> <snap-name>
Figura 117: Criando o snapshot do pool
• Listar snapshots do pool:
rados -p <pool-name> lssnap
Figura 118: Listando as snapshots do pool
61
Ao utilizar essa opção, o snapshot de imagens RBD se torna inviável
190
• Remover snapshots do pool:
ceph osd pool rmsnap <pool-name> <snap-name>
Figura 119: Removendo uma snapshot do pool
• Reverter snapshot do pool:
Infelizmente não existe uma forma de reverter todos os objetos de
um pool para o estado do snapshot. Ao invés disso, deve-se reverter
o estado dos objetos para o snapshot desejado.
rados -p <pool-name> rollback <object-name> <snap-name>
Figura 120: Revertendo o estado do objeto para a snapshot
2. Snapshots de imagens RBD:
Também é possível criar snapshots de imagens RBD. Essa opção permite
operações mais avançadas, sendo as mesmas:
• Criar a snapshot:
Assim como a snapshot de pool, o nome da snapshot de imagem pre-
cisa ser único para cada imagem.
rbd snap create <pool-name>/<image-name>@<snap-name>
191
Figura 121: Criando snapshots da imagem
• Listar snapshots da imagem:
rbd snap ls <pool-name>/<image-name>
Figura 122: Listando as snapshots da imagem
• Reverter a snapshot:
Essa opção deve ser utilizada com cuidado, pois, se a imagem estiver
sendo utilizada por uma VM, o sistema operacional da mesma pode
tornar os dados read-only ou não sincronizá-los.
rbd snap rollback <pool-name>/<image-name>@<snap-name>
Figura 123: Revertendo a snapshot da imagem
• Remover a snapshot:
Os OSDs removem os dados de forma assíncrona, então, ao remover
uma snapshot, a mesma não é imediatamente removida dos OSDs.
O processo de remoção de uma snapshot dos OSDs é chamado de s
naptrim e é visto no output do comando ceph osd pool ls detail.
192
rbd snap rm <pool-name>/<image-name>@<snap-name>
Figura 124: Removendo a snapshot da imagem
Figura 125: Detalhes do pool com snapshots sendo removidas
Figura 126: Detalhes do pool após a snapshot ter sido removida
• Removendo todas as snapshots de uma imagem:
Caso a imagem possua múltiplas snapshots, pode-se remover todas
com um único comando.
rbd snap purge <pool-name>/<image-name>
193
Figura 127: Removendo todas as snapshots da imagem
• Proteger a snapshot:
É possível proteger uma ou mais snapshots, impedindo que as mes-
mas sejam removidas enquanto a proteção for mantida.
rbd snap protect <pool-name>/<image-name>@<snap-name>
Figura 128: Protegendo a snapshot
• Remover a proteção da snapshot:
rbd snap unprotect <pool-name>/<image-name>@<snap-name>
194
Figura 129: Removendo a proteção da snapshot
• Calcular o tamanho real da snapshot:
Uma vez que as snapshots das imagens RBD são realizadas de forma
incremental e, na listagem das mesmas o tamanho apresentado é
sempre o tamanho total da imagem e não o tamanho real da snapshot,
a forma possível de se obter o tamanho real da snapshot consiste em
comparar duas snapshots da imagem para obter a diferença entre
elas e, com isso, o tamanho real da snapshot:
rbd diff --from-snap <old-snap> <pool-name>/<image-name>@<new-snap> | awk '{ SUM += $2 }
END { print SUM/1024/1024 " MB" }'
Figura 130: Obtendo o tamanho real da snapshot
Infelizmente, essa abordagem apenas permite obter o tamanho real
da segunda snapshot em diante, não havendo uma forma de obter o
tamanho real da primeira snapshot.
195
22. Configurações
O cluster Ceph possui diversas configurações que regem seus componen-
tes. Algumas podem ser alteradas dinamicamente, enquanto outras necessi-
tam que o componente afetado seja reiniciado.
Configurações alteradas de forma dinâmica
62
apenas tem seus valores utili-
zados enquanto o componente afetado não for reiniciado. Caso o componente
seja reinciado, a configuração voltará a ter seu valor padrão. Para garantir que
as configurações sejam permanentes, as mesmas devem ser alteradas no ar-
quivo /etc/ceph/ceph.conf de cada host que faz parte do cluster Ceph e, em
seguida, os componentes de tal host devem ser reiniciados, de forma a carre-
garem as novas configurações.
Abaixo segue exemplo de algumas configurações desse arquivo, onde cada
sessão
63
possui configurações próprias:
[global]
cluster network = 10.100.1.0/24
fsid = 006c802d-fc76-4211-bf90-a5c6c92098b7
mon host = [v2:10.100.2.11:3300,v1:10.100.2.11:6789],[v2:10.100.2.12:3300,v1:10.100.2.12:6789],[v2
:10.100.2.13:3300,v1:10.100.2.13:6789],[v2:10.100.2.14:3300,v1:10.100.2.14:6789],[v2
:10.100.2.15:3300,v1:10.100.2.15:6789]
mon initial members = dp1,dp2,dp3,dp4,dp5
osd pool default crush rule = -1
osd pool default min size = 2
osd pool default pg autoscale mode = warn
osd pool default size = 3
public network = 10.100.2.0/24
rbd readahead disable after bytes = 0
rbd readahead max bytes = 4194304
[mon]
auth_allow_insecure_global_id_reclaim = False
mon osd down out interval = 120
mon_warn_on_insecure_global_id_reclaim = True
mon_warn_on_insecure_global_id_reclaim_allowed = True
[osd]
bluestore cache size = 1073741824
bluestore default buffered write = True
osd memory target = 4294967296
Informações adicionais sobre as configurações possíveis podem ser encon-
tradas na documentação oficial.
62
Melhor detalhadas na seção 23.
63
Representada por [component-name].
196
22.1. Configurações importantes
Algumas configurações a se atentar, quando utilizando o Ceph, são:
• mon_osd_down_out_interval:
Essa configuração determina o período de espera, em segundos, antes de
um OSD irresponsivo ser marcado como down e out do cluster. Quando
esse intervalo é ultrapassado, o Ceph começará a migração dos dados
que existiam no OSD para os demais OSDs, de forma a manter a consis-
tência dos mesmos. Possui o valor padrão de 10 minutos.
Tal configuração é de extrema importância, tanto para manter a consis-
tência dos dados no cluster, quanto para operações de manutenção pla-
nejadas dos hosts. Os comandos para obter o valor corrente de tal confi-
guração, assim como alterá-lo dinâmicamente são:
ceph config get mon mon_osd_down_out_interval
ceph config set mon mon_osd_down_out_interval <int>
Figura 131: Alterando dinamicamente a configuração mon_osd_down_out_interval
• mon_max_pg_per_osd:
Essa configuração é usada para definir quantas PGs devem ser alocadas
por OSD, tendo o valor padrão de 250. Tal configuração pode ser adicio-
nada tanto para MONs quanto para OSDs, tendo comportamentos diver-
gentes em cada um desses componentes.
Nos MONs, essa configuração é usada para habilitar a criação de novos
pools. Nos OSDs a mesma é usada para realizar a implementação das
197
PGs. Caso tal configuração seja adicionada na seção global do arquivo /e
tc/ceph/ceph.conf, os MONs e OSDs irão a herdar.
Por se tratar de uma configuração que pode ser aplicada a mais de um
componente do cluster, pode-se causar inconsistências, caso o operador
altere o valor de tal configuração em um componente mas não o aplica
em outro. Por exemplo, caso o operador incremente o valor dessa con-
figuração para os MONs, mas se esqueça dos OSDs, será possível criar
múltiplos pools, porém, caso o número de PGs ultrapasse o definido nos
OSDs, os mesmos não irão implementar as PGs, deixando o cluster em
um estado de inconsistência.
Para obter e alterar dinamicamente essa configuração em ambos os com-
ponentes
64
, os comandos necessários são:
ceph config get mon mon_max_pg_per_osd
ceph config get osd mon_max_pg_per_osd
ceph config set mon mon_max_pg_per_osd <int>
ceph config set osd mon_max_pg_per_osd <int>
Figura 132: Alterando dinamicamente a configuração mon_max_pg_per_osd
64
MONs e OSDs.
198
Parte VI
Dicas e truques
O presente capítulo se destina a detalhar comandos úteis do Ceph para moni-
toramento e gerência do cluster.
199
23. Alterando configurações dinamicamente
É possível utilizar o comando ceph confi g para alterar dinamicamente as
configurações dos componentes no cluster. As configurações que podem ser
alteradas são nos níveis:
global Afeta todos os daemons e clientes
mon Afeta os monitores
mgr Afeta os managers
osd Afeta os OSDs
mds Afeta os Metadata Servers
client Afeta todos os clientes do Ceph
Sendo os principais subcomandos:
• Listar todas as configurações disponíveis:
ceph config ls
• Listar detalhes de uma configuração específica:
ceph config help <config-name>
Figura 133: Obtendo informações sobre a configuração
• Listar todas as configurações aplicadas:
ceph config dump
• Alterar configuração específica:
A sintaxe para esse tipo de operação é:
ceph config set <daemon> <opção> <valor>
200
Por exemplo:
ceph config set osd/class:hdd osd_max_backfills 8
24. Resolvendo o warning de mon is allowing insecure global_id reclaim
Para resolver essa mensagem de warning, basta executar o comando:
ceph config set mon auth_allow_insecure_global_id_reclaim false
25. Alterar redes do Ceph
• Caso o cluster Ceph tenha sido criado usando o ceph-ansible, para alterar
alguma das redes do cluster, o procedimento a ser realizado é:
1. No arquivo group_vars/all.yml, alterar os valores das chaves
monitor_interfa ce, public_network e/ou cluster_network, conforme
a necessidade;
2. Após isso, basta reexecutar o playbook, de forma a refazer o deploy
do cluster.
Esse procedimento é necessário, uma vez que, caso o usuário tente optar
por alterar diretamente o arquivo /etc/ceph/ceph.conf de todos os moni-
tores, tal arquivo será sobreescrito pelo Ansible.
• Caso o deploy do Ceph tenha sido realizado com o c ephadm, o procedi-
mento a ser realizado é:
1. Faça o login no shell do cephadm:
cephadm shell
2. Configure a rede pública com a subrede:
ceph config set mon public_network network/netmask
3. Liste e reinicie os daemons com os comandos:
ceph orch ls
ceph orch restart mon
201
4. Configure a rede privada com a subrede:
ceph config set global cluster_network network/netmask
5. Repita o passo 3;
6. (Opcional) Caso queira reiniciar todo o cluster, no nodo admin, exe-
cute o comando:
systemctl restart ceph-<fsid>.target
• Caso o deploy do Ceph tenha sido realizado de forma manual, o procedi-
mento a ser realizado é:
1. Em cada nodo monitor e OSD do cluster, alterar no arquivo
/etc/ceph/ceph.conf os valores das chaves cluster network,
mon host e/ou public network, de acordo com a necessidade;
2. Reiniciar cada monitor e OSD do ambiente.
26. Operações básicas com OSDs
26.1. Detecção e correção de falhas em OSDs
Por vezes, os OSDs da infraestrutura podem apresentar falhas, sendo ne-
cessário restituí-los, seja através da reinicialização do OSD ou da troca de um
disco físico. Para tal, o procedimento a ser executado nesse cenário é:
1. Inicialmente, deve-se verificar a saúde do cluster com o comando:
~$ ceph health
HEALTH_OK
Caso haja algum erro em algum OSD, uma saída semelhante a essa será
exibida:
HEALTH_WARN mons are allowing insecure global_id reclaim; 1 osds down; 1 host (1 osds) down;
Degraded data redundancy: 1761/7833 objects degraded (22.482%), 50 pgs degraded; 1 pool(s) do
not have an application enabled
2. Para encontrar qual OSD está com falha, basta executar o comando:
202
root@client-1:~# ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.97649 root default
-3 0.19530 host dp1
2 hdd 0.19530 osd.2 up 1.00000 1.00000
-9 0.19530 host dp2
0 hdd 0.19530 osd.0 up 1.00000 1.00000
-7 0.19530 host dp3
1 hdd 0.19530 osd.1 up 1.00000 1.00000
-5 0.19530 host dp4
3 hdd 0.19530 osd.3 up 1.00000 1.00000
-11 0.19530 host dp5
4 hdd 0.19530 osd.4 down 1.00000 1.00000
E identificar qual host está com falha.
3. Em seguida, é necessário acessar tal host para verificar o estado do serviço
ceph-OSD. Caso o serviço esteja parado, basta iniciá-lo com o comando:
root@dp5:~# systemctl start ceph-osd@<id>.service
E, após o mesmo ser automaticamente reintroduzido no cluster, repetir o
passo 1.
4. Caso a falha do OSD tenha sido causada por uma falha no disco físico, o
procedimento a ser realizado é:
• Verifique se é seguro destruir esse OSD:
while ! ceph osd safe-to-destroy osd.<osd-id> ; do sleep 10 ; done
• Destrua esse OSD:
ceph osd destroy <osd-id> --yes-i-really-mean-it
• Adicione um novo disco no host físico e, em seguida, o formate para
ser identificado como um OSD no Ceph:
ceph-volume lvm zap /dev/sdX
• Adicione esse novo OSD no Ceph com o id do antigo:
203
ceph-volume lvm prepare --osd-id <osd-id> --data /dev/sdX
• Por fim, ative esse OSD:
ceph-volume lvm activate <osd-id> <fsid>
26.2. Detectando OSDs lentos
O Ceph possui formas de identificar OSDs lentos, por exemplo, o comando
ceph tell osd.<osd-id bench pode ser utilizado para verificar a velocidade de
escrita e de leitura dos OSDs, é possível também identificar OSDs com baixa
performance através do comando ceph o sd perf <osd-id> para avaliar o de-
sempenho dos OSDs em um cluster Ceph.
O comando ceph tell osd.<osd-id> bench é usado para realizar testes de
desempenho de leitura e escrita em um OSD específico. Permite avaliar a ca-
pacidade de armazenamento e recuperação de dados do OSD em questão. O
formato básico do comando está apresentado abaixo.
~$ ceph tell osd.{osd-id} bench {time} {block}
Por exemplo, caso deseje executar um teste de leitura e escrita em um OSD
(osd.0) específico por 10 segundos, usando blocos de dados de 4096 bytes:
~$ ceph tell osd.0 bench 10 4096
{
"bytes_written": 10,
"blocksize": 4096,
"elapsed_sec": 0.0030375559999999998,
"bytes_per_sec": 3292.1203757231142,
"iops": 0.80374032610427593
}
Ao executar este comando, o OSD selecionado irá realizar operações de lei-
tura e escrita em um bloco de dados aleatório no pool. Durante o teste, o OSD
exibirá estatísticas de desempenho em tempo real, incluindo a taxa de transfe-
rência de dados, a latência média e a quantidade total de dados lidos e escritos.
Útil em situações onde se deseja avaliar o desempenho de um único OSD em
ambientes Ceph; comparar o desempenho de diferentes OSDs em um mesmo
204
cluster; testar a integridade e capacidade de armazenamento de um OSD espe-
cífico após uma manutenção ou atualizações. Entretanto, é necessário lembrar
que os testes de benchmark podem afetar o desempenho geral do cluster e,
portanto, devem ser executados com cautela e apenas em momentos de baixa
carga. Além disso, os resultados do benchmark podem variar dependendo de
vários fatores, como a configuração do hardware, o tamanho e tipo dos dados
armazenados e a quantidade de tráfego de rede no cluster.
O comando ceph osd perf é uma ferramenta útil para avaliar o desempe-
nho dos OSDs em ambientes Ceph. Quando executado, exibe as métricas de
desempenho listadas abaixo.
~$ ceph osd perf
osd commit_latency(ms) apply_latency(ms)
4 0 0
3 0 0
2 0 0
1 0 0
0 0 0
• osd: ID do OSD;
• apply_latency: tempo de latência até a transação terminar, isto é, o tempo
de gravação + journal_latency;
• commit_latency: tempo que leva para realizar o syncfs();
• journal_latency: tempo que leva para gravar no journal, ou seja, tempo
de reconhecimento da escrita para o cliente.
Caso necessário, os operadores podem executar o comando
ceph daemon o sd.<id> perf dump a partir do host onde está situado o OSD
alvo, dessa forma o Ceph irá retornar um conjunto de estatísticas que incluem
informações sobre as operações de leitura e escrita, latência, taxa de transfe-
rência, entre outras. Abaixo estão alguns exemplos de informações que são
retornadas pelo comando, a resposta para esse comando foi omitida para não
poluir o documento.
205
• osd.op_r: número total de operações de leitura executadas pelo OSD;
• osd.op_w: número total de operações de gravação executadas pelo OSD;
• osd.op_rw_in_bytes: número total de bytes lidos e escritos pelo OSD;
• osd.op_r_latency: latência média das operações de leitura (em microsse-
gundos);
• osd.op_w_latency: latência média das operações de escrita (em micros-
segundos);
• osd.op_rw_latency: latência média das operações de leitura e escrita (em
microssegundos);
• osd.op_in_bytes: número total de bytes lidos e escritos pelo OSD;
• osd.op_out_bytes: número total de bytes escritos pelo OSD;
• osd.op_in_bytes_slow: número total de bytes lidos pelo OSD com latência
maior que um limite de tempo especificado;
• osd.op_out_bytes_slow: número total de bytes escritos pelo OSD com
latência maior que um limite de tempo especificado.
Essas informações podem ser usadas para monitorar o desempenho do
OSD em tempo real e identificar possíveis problemas de desempenho. Por
exemplo, se a latência média das operações de leitura ou gravação é muito
alta, isso pode indicar que o OSD está sobrecarregado e precisando de mais
recursos ou ajustes na configuração.
26.3. Verificando o mapeamento dos OSDs com discos físicos
Caso o operador deseje saber qual OSD está mapeado para device físico, o
passo a passo para isso é:
1. Listar em qual host está o OSD que se deseja verificar:
206
ceph osd tree
Figura 134: Listando os OSDs e seus hosts
2. Acessar este host via ssh:
A partir desse ponto, existem dois caminhos que podem ser seguidos:
(a) Listar os devices e filtrar o disco físico via link simbólico:
Esse é o caminho mais longo, tendo os passos:
i. Listar o link simbólico do OSD:
No host alvo, pode-se listar o link simbólico do OSD que aponta
para o dispositivo físico com o comando:
ls -lah /var/lib/ceph/osd/ceph-<osd-id>
Figura 135: Link simbólico do OSD
ii. Filtrar os discos físicos filtrando pelo início do nome do link sim-
bólico
65
:
65
Nesse caso, queremos o valor ceph-<lvm-id> contido na string /dev/ceph-<lvm-id>/osd-<o
sd-id>.
207
pvs | grep ceph-<lvm-id>
Figura 136: Encontrando o dispositivo físico pelo link simbólico do OSD
(b) Listar todos os OSDs e seus discos físicos no host em questão:
Existe um comando que faz o mapeamento dos discos diretamente,
sem as necessidades do passo anterior. Para tal, o comando utilizado
é:
ceph-volume lvm list
Figura 137: Listando os OSDs do host e seus discos físicos associados
208
27. Coletando informações sobre falhas
O Ceph possui um módulo chamado crash utilizado para coletar e relatar in-
formações de falhas (crashes) em componentes individuais, como Mons, OSDs
e clients; é executado automaticamente quando uma falha é detectada e foi
projetado para coletar informações detalhadas sobre antes, durante e depois
de uma falha ocorrer no ambiente. É uma ferramenta útil para manter a esta-
bilidade e a confiabilidade do cluster do Ceph.
Por padrão os dumps dos diagnósticos serão salvos na pasta /var/log/cep
h/crash , entretanto, isso pode ser alterado editando o arquivo ceph.con f. Os
parâmetros de configuração do módulo, incluem:
• crash_dir: define o diretório onde serão armazenados os arquivos de
crash;
• crash_log: define o arquivo de log onde serão registradas as informações
de crash.
Para habilitar o módulo se faz necessário executar o comando:
~$ ceph mgr module enable crash
Para remover um diagnóstico específico. Substitua crashid pelo ID do diag-
nóstico que a ser removido:
~$ ceph crash rm <crashid>
Para listar os diagnósticos previamente coletados e armazenados:
~$ ceph crash ls # Para listar todos os diagnósticos.
~$ ceph crash ls-new # Para listar apenas os diagnósticos mais recentes.
Para sumarizar diagnósticos previamente coletados:
~$ ceph crash stat # Mostra resumo das informaçoes salvas de acidentes agrupadas por data.
~$ ceph crash info <crashid> # Mostra detalhes de um diagnóstico.
Para remover diagnósticos:
~$ ceph crash rm <crashid> # Remove o diagnóstico definido pelo crashid.
~$ ceph crash prune <keep> # Remove os diagnósticos salvos com mais de keep dias. O valor de keep
deve ser um numero inteiro positivo.
209
28. Boas práticas no uso do RadosGW
A presente seção tem como objetivo apresentar algumas das boas práticas
na criação de usuários e buckets no Rados Gateway que podem ajudar a otimizar
o desempenho, melhorar a segurança e facilitar a administração.
28.1. Boas práticas na criação de usuários
Algumas das boas práticas na criação de usuários incluem:
• Crie usuários separados para cada serviço (ou aplicação) que irá consumir
os recursos do Rados Gateway. Assim é possível um melhor controle e
gerenciamento de permissões.
• Utilize senhas fortes e seguras, seguindo as boas práticas de segurança
(comprimento, complexidade, entre outros).
• Aplique o conceito de privilégio mínimo, concedendo apenas as permis-
sões necessárias.
• Evite nomes genéricos e vagos, utilize um padrão que possibilite identifi-
car o propósito do usuário.
28.2. Boas práticas na criação de buckets
Algumas das boas práticas na criação de buckets incluem:
• Capacidade: é importante planejar a capacidade necessária para armaze-
namento. Considere fatores como tamanho de dados, crescimento espe-
rado e requisitos de desempenho;
• Configurações de armazenamento: revise as configurações de armaze-
namento, como tamanho do objeto, número de réplicas e estratégias de
distribuição, para atender às necessidades do usuário (serviço/aplicação);
• Backup: implemente um plano de backup para proteger os dados. Con-
sidere estratégias como snapshots, replicação ou outros mecanismos de
proteção de dados;
210
• Tamanho do bucket: considere dividir grandes quantidades de dados em
várias pastas (prefixo dos objetos) menores, para evitar que as pastas se
tornem muito grandes. Pastas grandes podem resultar em tempos de
resposta mais lentos e dificuldades na gestão. Ademais, o S3 limita a lis-
tagem de objetos a 1000 por requisição, portanto, é interessante que não
ultrapasse 1000 objetos dentro de uma pasta;
• Nomes: é recomendável seguir um padrão de nomenclatura para garan-
tir consistência e facilitar a organização. Evite caracteres especiais e use
nomes descritivos que represente o conteúdo do bucket;
• Objetos: é importante criar objetos pensando em diretórios seguindo um
padrão, por exemplo <prefixo>< de lim ita dor ><o bje to>, que facilite a ges-
tão e busca de objetos, uma vez que os operadores podem utilizar desse
padrão para filtrar as buscas por objetos, diminuindo o tempo necessário
para o Ceph identificar os objetos presentes no bucket.
29. Criar VM usando RBD como backend
Para criar uma VM utilizando uma imagem RBD como backend, os passos
necessários são:
1. Criar o pool e a imagem RBD:
Aqui será utilizado um pool replicado. Para maiores informações sobre
operações com pools, consulte a seção 9. Para maiores informações sobre
RBD, consulte a seção 10.
ceph osd pool create vms replicated
rbd create --size <int>G <pool>/<name>
211
Figura 138: Criando o pool
Figura 139: Criando a imagem RBD
2. Criar usuário com autenticação apenas ao pool criado:
ceph auth get-or-create client.<name> mon 'profile rbd' osd 'profile rbd pool=<pool-name>'
Figura 140: Criando o usuário
3. No host KVM, criar o arquivo secret.xml, que conterá o arquivo de secret
do libvirt:
<secret ephemeral='no' private='no'>
<usage type='ceph'>
<name>client.{name}</name>
</usage>
</secret>
212
Figura 141: Arquivo secret.xml no host KVM
Há de se mencionar que não podem existir dois secrets no libvirt com o
mesmo nome ou uuid.
4. Criar chave secreta de autenticação no libvirt:
virsh secret-define --file <file.xml>
Figura 142: Definindo a chave no libvirt
5. Adicionar a chave de autenticação do Ceph, criada no Passo 2, ao secret,
criado no Passo 4:
virsh secret-set-value <uuid> <key>
Figura 143: Definindo a autenticação no secret do libvirt
6. Criar uma VM, preferencialmente utilizando um utilitário como o virt-ma
nager, editando o XML da mesma antes do deploy, de forma a utilizar a
imagem RBD como backend:
(a) Via virt-manager, iniciar a criação de uma VM normalmente, porém,
sem storage:
213
Figura 144: Criando uma VM sem storage
Figura 145: Criando uma VM normalmente
Deve-se utilizar a opção Customize configura t i o n bef ore ins t a l l para
editar o XML da VM.
(b) Editar o XML de backend do storage da VM, adicionando a imagem R
BD:
<disk type="network" device="disk">
<driver name="qemu" type="raw" cache="none" discard="unmap"/>
<auth username="<name>">
<secret type="ceph" uuid="<secret-uuid>"/>
214
</auth>
<source protocol="rbd" name="<pool>/<name>">
<host name="<mon-ip1>" port="6789"/>
<host name="<mon-ip2>" port="6789"/>
<host name="<mon-ipX>" port="6789"/>
</source>
<target dev="vda" bus="virtio"/>
</disk>
Figura 146: Editando o XML da VM
(c) Inicie a instalação:
215
Figura 147: Iniciando a instalação da VM
216
Figura 148: Continuando a instalação da VM
7. Mapear a imagem localmente e a usar para instalar a VM:
Outro procedimento para instalar uma VM usando RBD como backend
consiste em mapear a imagem localmente e, via CLI do virt-install, utilizar
a imagem mapeada para criar a VM.
Há de se mencionar que tal procedimento requer que a imagem RBD seja
mapeada, e permaneça mapeada no host, para que a VM funcione.
(a) Mapear a imagem criada:
rbd map <pool>/<image>
Figura 149: Mapeando a imagem localmente
(b) Criar a VM usando a imagem mapeada como storage:
217
virt-install --name=<name> --vcpus=<int> --memory=<int> --disk /dev/rbd<X> --boot cdrom
--cdrom </path/to/iso/file.iso>
Figura 150: Criando a VM usando a imagem mapeada localmente
Figura 151: Finalizar a criação da VM usando a imagem mapeada localmente
⋆ Detalhes:
218
Para realizar esses procedimentos, é necessário ter os pacotes do libvirt,
virt-manager e ceph-rbd instalados na máquina, assim como acesso aos
IPs dos MONs e credenciais válidas de acesso ao cluster Ceph.
219
