17 Gerenciamento de dados armazenados #

A flexibilidade do Mapa CRUSH para controlar o posicionamento de dados é um dos pontos fortes do Ceph. É também uma das partes mais difíceis de gerenciamento do cluster. As classes de dispositivo automatizam as mudanças mais comuns nos Mapas CRUSH que o administrador antes precisava fazer manualmente.

17.1.1.1 Problema de gerenciamento do CRUSH #

 

Os clusters do Ceph costumam ser criados com vários tipos de dispositivos de armazenamento: HDD, SSD, NVMe ou até classes combinadas dos elementos acima. Denominamos esses diferentes tipos de dispositivos de armazenamento como classes de dispositivo para evitar confusão entre a propriedade tipo dos compartimentos de memória do CRUSH (por exemplo, host, rack, linha. Consulte a Seção 17.2, “Compartimentos de memória” para obter mais detalhes). Os Ceph OSDs com SSDs são muito mais rápidos do que os com discos giratórios, o que os torna mais adequados a determinadas cargas de trabalho. O Ceph facilita a criação de pools RADOS para diferentes conjuntos de dados ou cargas de trabalho e a atribuição de regras CRUSH diferentes para controlar o posicionamento de dados para esses pools.

Figura 17.1: OSDs com classes de dispositivo combinadas #

 

No entanto, a configuração de regras CRUSH para posicionar dados apenas em uma determinada classe de dispositivo é desgastante. As regras funcionam nos termos da hierarquia CRUSH, mas se os dispositivos forem combinados com os mesmos hosts ou racks (como na hierarquia da amostra acima), eles (por padrão) serão combinados e aparecerão nas mesmas subárvores da hierarquia. A separação manual deles em árvores separadas envolvia a criação de várias versões de cada nó intermediário para cada classe de dispositivo nas versões anteriores do SUSE Enterprise Storage.

cephuser@adm > ceph osd tree
 ID CLASS WEIGHT   TYPE NAME      STATUS REWEIGHT PRI-AFF
 -1       83.17899 root default
 -4       23.86200     host cpach
 2   hdd  1.81898         osd.2      up  1.00000 1.00000
 3   hdd  1.81898         osd.3      up  1.00000 1.00000
 4   hdd  1.81898         osd.4      up  1.00000 1.00000
 5   hdd  1.81898         osd.5      up  1.00000 1.00000
 6   hdd  1.81898         osd.6      up  1.00000 1.00000
 7   hdd  1.81898         osd.7      up  1.00000 1.00000
 8   hdd  1.81898         osd.8      up  1.00000 1.00000
 15  hdd  1.81898         osd.15     up  1.00000 1.00000
 10  nvme 0.93100         osd.10     up  1.00000 1.00000
 0   ssd  0.93100         osd.0      up  1.00000 1.00000
 9   ssd  0.93100         osd.9      up  1.00000 1.00000

cephuser@adm > ceph osd crush rm-device-class osd.2 osd.3
done removing class of osd(s): 2,3
cephuser@adm > ceph osd crush set-device-class ssd osd.2 osd.3
set osd(s) 2,3 to class 'ssd'

cephuser@adm > ceph osd crush rule create-replicated RULE_NAME ROOT FAILURE_DOMAIN_TYPE DEVICE_CLASS

cephuser@adm > ceph osd crush rule create-replicated fast default host ssd

cephuser@adm > ceph osd pool create fast_pool 128 128 replicated fast

cephuser@adm > ceph osd erasure-code-profile set myprofile \
 k=4 m=2 crush-device-class=ssd crush-failure-domain=host
cephuser@adm > ceph osd pool create mypool 64 erasure myprofile

rule ecpool {
  id 2
  type erasure
  min_size 3
  max_size 6
  step set_chooseleaf_tries 5
  step set_choose_tries 100
  step take default class ssd
  step chooseleaf indep 0 type host
  step emit
}

cephuser@adm > ceph osd crush class ls
[
  "hdd",
  "ssd"
]

cephuser@adm > ceph osd crush rule ls
replicated_rule
fast

cephuser@adm > ceph osd crush rule dump fast
{
		"rule_id": 1,
		"rule_name": "fast",
		"ruleset": 1,
		"type": 1,
		"min_size": 1,
		"max_size": 10,
		"steps": [
						{
										"op": "take",
										"item": -21,
										"item_name": "default~ssd"
						},
						{
										"op": "chooseleaf_firstn",
										"num": 0,
										"type": "host"
						},
						{
										"op": "emit"
						}
		]
}

cephuser@adm > ceph osd crush class ls-osd ssd
0
1

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

As regras no Mapa CRUSH definem como os OSDs são selecionados dessa árvore. Uma regra começa com um nó e, em seguida, faz a iteração descendente pela árvore para retornar um conjunto de OSDs. Não é possível definir qual ramificação precisa ser selecionada. Em vez disso, o algoritmo CRUSH garante que o conjunto de OSDs atende aos requisitos de replicação e distribui os dados igualmente.

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

Após step take, uma ou mais entradas step choose vêm a seguir na definição da regra. Cada step choose escolhe um número definido de nós (ou ramificações) do nó superior selecionado anteriormente.

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

step chooseleaf é uma prática função que seleciona os OSDs diretamente das ramificações do compartimento de memória especificado.

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

Figura 17.2: Exemplo de árvore #

 

# orange arrows
rule example1a {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # orange (1)
        step take rack1
        # orange (2)
        step choose firstn 0 host
        # orange (3)
        step choose firstn 1 osd
        step emit
}

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

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

Uma regra CRUSH define substituições para nós ou OSDs com falha (consulte a Seção 17.3, “Conjuntos de regras”). A palavra-chave step requer firstn ou indep como parâmetro. A Figura 17.3, “Métodos de substituição de nó” apresenta um exemplo.

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

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

Figura 17.3: Métodos de substituição de nó #

 

Um grupo de posicionamento (PG) agrega objetos em um pool. O principal motivo é que o monitoramento do posicionamento de objetos e dos metadados por objeto é caro em termos de capacidade de computação. Por exemplo, um sistema com milhões de objetos não pode monitorar o posicionamento de cada um dos seus objetos diretamente.

Figura 17.4: Grupos de posicionamento em um pool #

 

O cliente Ceph calculará a que grupo de posicionamento um objeto pertencerá. Ele faz isso por meio de hashing do ID do objeto e da aplicação de uma operação com base no número de PGs no pool definido e no ID do pool.

O conteúdo do objeto em um grupo de posicionamento é armazenado em um conjunto de OSDs. Por exemplo, em um pool replicado de tamanho dois, cada grupo de posicionamento armazenará objetos em dois OSDs:

Figura 17.5: Grupos de posicionamento e OSDs #

 

Se o OSD nº 2 falhar, outro OSD será atribuído ao grupo de posicionamento nº 1 e será preenchido com cópias de todos os objetos no OSD nº 1. Se o tamanho do pool for mudado de dois para três, um OSD adicional será atribuído ao grupo de posicionamento e receberá cópias de todos os objetos no grupo de posicionamento.

Os grupos de posicionamento não têm a propriedade do OSD, eles o compartilham com outros grupos de posicionamento do mesmo pool ou até de outros pools. Se o OSD nº 2 falhar, o grupo de posicionamento nº 2 também precisará restaurar cópias dos objetos usando o OSD nº 3.

Quando o número de grupos de posicionamento aumentar, os novos grupos de posicionamento receberão os OSDs. O resultado da função CRUSH também mudará, e alguns objetos dos antigos grupos de posicionamento serão copiados para os novos grupos de posicionamento e removidos dos antigos.

Nota

A partir do Ceph Nautilus (v14.x), você pode usar o módulo pg_autoscaler do Ceph Manager para dimensionar automaticamente os PGs, conforme necessário. Para habilitar esse recurso, consulte o Section 8.1.1.1, “Default PG and PGP counts”.

Ao criar um novo pool, você ainda pode escolher o valor de PG_NUM manualmente:

# ceph osd pool create POOL_NAME PG_NUM

Não é possível calcular o PG_NUM automaticamente. Veja a seguir alguns valores mais usados, dependendo do número de OSDs no cluster:

Conforme o número de OSDs aumenta, a escolha do valor certo para PG_NUM torna-se mais importante. O PG_NUM afeta altamente o comportamento do cluster e também a durabilidade dos dados em caso de falha no OSD.

total PGs = (OSDs * 100) / POOL_SIZE

          (200 * 100) / 3 = 6667

Nota

A partir do Ceph Nautilus (v14.x), você pode usar o módulo pg_autoscaler do Ceph Manager para dimensionar automaticamente os PGs, conforme necessário. Para habilitar esse recurso, consulte Section 8.1.1.1, “Default PG and PGP counts”.

Se você ainda precisa especificar o número de grupos de posicionamento em um pool manualmente, é necessário especificá-los no momento da criação do pool (consulte a Seção 18.1, “Criando um pool”). Após definir os grupos de posicionamento para um pool, você poderá aumentar o número de grupos de posicionamento executando o seguinte comando:

# ceph osd pool set POOL_NAME pg_num PG_NUM

Após aumentar o número de grupos de posicionamento, você também precisará aumentar esse número para o posicionamento (PGP_NUM) antes que o cluster seja redistribuído. O PGP_NUM será o número de grupos de posicionamento que serão considerados para o posicionamento pelo algoritmo CRUSH. O aumento do PG_NUM divide os grupos de posicionamento, mas os dados não serão migrados para os grupos de posicionamento mais recentes até que PGP_NUM seja aumentado. O PGP_NUM deve ser igual ao PG_NUM. Para aumentar o número de grupos para o posicionamento, execute o seguinte:

# ceph osd pool set POOL_NAME pgp_num PGP_NUM

Para encontrar o número de grupos de posicionamento em um pool, execute o seguinte comando get:

# ceph osd pool get POOL_NAME pg_num

Para encontrar as estatísticas dos grupos de posicionamento em seu cluster, execute o seguinte comando:

# ceph pg dump [--format FORMAT]

Os formatos válidos são “plain” (padrão) e “json”.

Para encontrar as estatísticas de todos os grupos de posicionamento travados em um determinado estado, execute o seguinte:

# ceph pg dump_stuck STATE \
 [--format FORMAT] [--threshold THRESHOLD]

O STATE é um dos seguintes: “inactive” (PGs não podem processar leituras ou gravações porque estão aguardando por um OSD com os dados mais atualizados), “unclean” (PGs contêm objetos que não foram replicados o número desejado de vezes), “stale” (PGs em estado desconhecido: os OSDs que os hospedam não foram relatados ao cluster do monitor no intervalo especificado pela opção mon_osd_report_timeout), “undersized” ou “degraded”.

Os formatos válidos são “plain” (padrão) e “json”.

O limite define o número mínimo de segundos que o grupo de posicionamento permanece travado antes de incluí-lo nas estatísticas retornadas (por padrão, 300 segundos).

Para pesquisar o mapa de um determinado grupo de posicionamento, execute o seguinte:

# ceph pg map PG_ID

O Ceph retornará o mapa do grupo de posicionamento, o grupo de posicionamento e o status do OSD:

# ceph pg map 1.6c
osdmap e13 pg 1.6c (1.6c) -> up [1,0] acting [1,0]

Para recuperar as estatísticas de um determinado grupo de posicionamento, execute o seguinte:

# ceph pg PG_ID query

Para depurar (Seção 17.6, “Depurando grupos de posicionamento”) um grupo de posicionamento, execute o seguinte:

# ceph pg scrub PG_ID

O Ceph verifica os nós primários e de réplica, gera um catálogo de todos os objetos no grupo de posicionamento e os compara para garantir que nenhum objeto esteja ausente ou seja incompatível e que seu conteúdo seja consistente. Supondo que todas as réplicas sejam correspondentes, uma varredura semântica final garante que todos os metadados de objetos relacionados a instantâneo sejam consistentes. Os erros são relatados por meio de registros.

Você pode enfrentar uma situação em que vários grupos de posicionamento exigem recuperação e/ou provisionamento, enquanto alguns grupos armazenam dados mais importantes do que outros. Por exemplo, alguns PGs podem armazenar dados para imagens usadas por máquinas em execução, e outros PGs podem ser usados por máquinas inativas ou dados menos relevantes. Nesse caso, você pode priorizar a recuperação desses grupos para que o desempenho e a disponibilidade dos dados armazenados neles sejam restaurados com mais antecedência. Para marcar grupos de posicionamento específicos como priorizados durante o provisionamento ou a recuperação, execute o seguinte:

# ceph pg force-recovery PG_ID1 [PG_ID2 ... ]
# ceph pg force-backfill PG_ID1 [PG_ID2 ... ]

Isso fará com que o Ceph realize a recuperação ou o provisionamento dos grupos de posicionamento especificados primeiro, antes dos outros grupos de posicionamento. Esse procedimento não interrompe os provisionamentos ou a recuperação que está em andamento, mas faz com que os PGs especificados sejam processados o mais rápido possível. Se você mudar de ideia ou priorizar grupos errados, cancele a priorização:

# ceph pg cancel-force-recovery PG_ID1 [PG_ID2 ... ]
# ceph pg cancel-force-backfill PG_ID1 [PG_ID2 ... ]

Os comandos cancel-* removem o flag “force” dos PGs para que sejam processados na ordem padrão. Mais uma vez, isso não afeta os grupos de posicionamento que estão sendo processados, apenas aqueles que ainda estão na fila. O flag “force” será limpo automaticamente após a recuperação ou o provisionamento do grupo.

Se o cluster perdeu um ou mais objetos, e você decidiu parar de procurar os dados perdidos, precisará marcar os objetos não encontrados como "perdidos".

Se os objetos ainda continuarem perdidos depois de ter consultado todos os locais possíveis, você talvez tenha de desistir deles. Isso é possível considerando as combinações incomuns de falhas que permitem que o cluster reconheça as gravações que foram realizadas antes de serem recuperadas.

Atualmente, a única opção suportada é "revert", que voltará para uma versão anterior do objeto ou o esquecerá completamente, no caso de um novo objeto. Para marcar os objetos “não encontrados” como “perdidos”, execute o seguinte:

  cephuser@adm > ceph pg PG_ID mark_unfound_lost revert|delete

Os grupos de posicionamento (PGs, Placement Groups) são um detalhe interno de implementação de como o Ceph distribui os dados. Ao habilitar o pg-autoscaling, você pode permitir que o cluster crie ou ajuste os PGs automaticamente com base no modo como o cluster é usado.

Cada pool no sistema tem uma propriedade pg_autoscale_mode que pode ser definida como off, on ou warn:

O dimensionador automático é configurado por pool e pode ser executado em três modos:

Para definir o modo de dimensionamento automático para os pools existentes:

cephuser@adm > ceph osd pool set POOL_NAME pg_autoscale_mode mode

Você também pode configurar o pg_autoscale_mode padrão que será aplicado a qualquer pool criado no futuro com:

cephuser@adm > ceph config set global osd_pool_default_pg_autoscale_mode MODE

Você pode ver cada pool, sua utilização relativa e quaisquer mudanças sugeridas na contagem de PGs com este comando:

cephuser@adm > ceph osd pool autoscale-status

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

Dica: Usar o sistema de controle de versão

Use um sistema de controle de versão, como git ou svn, para os arquivos de Mapa CRUSH exportados e modificados. Isso simplifica um possível rollback.

Dica: Testar o novo mapa CRUSH

Teste o novo Mapa CRUSH ajustado usando o comando crushtool --test e compare com o estado antes da aplicação do novo Mapa CRUSH. Você pode achar útil os seguintes switches de comando: --show-statistics, --show-mappings, --show-bad-mappings, --show-utilization, --show-utilization-all, --show-choose-tries

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

cephuser@adm > ceph osd crush set id_or_name weight root=pool-name
bucket-type=bucket-name ...

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

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

Há dois comandos similares que mudam o “peso” de um Ceph OSD. O contexto do uso deles é diferente e pode causar confusão.

17.5.3.1 ceph osd reweight #

 

Uso:

cephuser@adm > ceph osd reweight OSD_NAME NEW_WEIGHT

O ceph osd reweight define um peso de substituição no Ceph OSD. Esse valor está na faixa de 0 a 1 e força o CRUSH a reposicionar os dados que, de outra forma, residiriam nesta unidade. Ele não muda os pesos atribuídos aos compartimentos de memória acima do OSD e é uma medida corretiva em caso de não funcionamento ou mau funcionamento da distribuição normal do CRUSH. Por exemplo, se um dos OSDs estiver em 90% e os outros estiverem em 40%, você poderá reduzir esse peso para tentar compensá-lo.

Nota: O peso do OSD é temporário

Observe que a configuração ceph osd reweight não é persistente. Quando um OSD é marcado para ser removido, seu peso é definido como 0. Quando ele é marcado para ser incluído novamente, o peso é modificado para 1.

cephuser@adm > ceph osd crush reweight OSD_NAME NEW_WEIGHT

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

cephuser@adm > ceph osd crush remove OSD_NAME

Para adicionar um compartimento de memória ao Mapa CRUSH de um cluster em execução, use o comando ceph osd crush add-bucket:

cephuser@adm > ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE

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

cephuser@adm > ceph osd crush move BUCKET_NAME BUCKET_TYPE=BUCKET_NAME [...]

Por exemplo:

cephuser@adm > ceph osd crush move bucket1 datacenter=dc1 room=room1 row=foo rack=bar host=foo-bar-1

Para remover um compartimento de memória da hierarquia do Mapa CRUSH, execute o seguinte:

cephuser@adm > ceph osd crush remove BUCKET_NAME

Nota: Apenas compartimento de memória vazio

Um compartimento de memória deve estar vazio antes de removê-lo da hierarquia do CRUSH.