Ceph
Este documento visa apresentar o sistema de armazenamento definido por
software Ceph, seu processo de configuração, uso e operação.
Atualizado em: 28 de dezembro de 2023
Revision: 2eff6816c1336be443c62ed7695669bf8b94687f
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 . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.3 Manutenção de OSDs . . . . . . . . . . . . . . . . . . . . . . . . . . 121
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.
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