Início / unix / Perguntas / 781250
Accepted
dotokija
Asked: 2024-08-02 16:51:35 +0800 CST

Explicação das regras do Ceph Crush para configuração de multiroom/racks

  • 772

Comecei recentemente com ceph, herdei 1 cluster grande para manutenção e agora estou construindo cluster de recuperação. Por meio de um jogo de tentativa e fracasso, consegui criar regras de esmagamento que atendessem ao meu propósito, mas não consegui entender a sintaxe da definição de regras de esmagamento. Alguém poderia explicar (não faça referência aos documentos ceph, pois eles não explicam isso)?
Aqui está minha configuração de cluster de produção:
20 hosts distribuídos em 2 salas, 2 racks em cada sala, 5 servidores por rack, 10 OSDs por host, 200 OSDs no total.
Alguém queria uma configuração super segura, então a replicação é 2/4 e as regras são (supostamente) definidas para replicar para outra sala, 2 cópias em cada rack, 4 no total para cada objeto. Aqui está a regra:

rule replicated_nvme {
    id 4
    type replicated
    min_size 1
    max_size 100
    step take default class nvme
    step choose firstn 0 type room
    step choose firstn 2 type rack
    step chooseleaf firstn 1 type host
    step emit
}

No meu novo cluster eu tenho uma configuração menor, então apenas 2 racks com 2 servidores cada para teste. Eu tentei isso, semelhante ao anterior, mas sem espaço:

rule replicated-nvme {
    id 6
    type replicated
    step take default class nvme
    step choose firstn 0 type rack
    step chooseleaf firstn 1 type host
    step emit
}

Porém, isso não produz o resultado desejado (com replicação 2/4 deve-se copiar para outro rack cada cópia para um servidor diferente). O que obtive foram 2 réplicas em servidores em racks diferentes e 2 cópias adicionais não criadas. Eu recebo isso do ceph:

pgs:     4/8 objects degraded (50.000%)
             1 active+undersized+degraded

e vejo que apenas 2 OSDs são usados, não 4!

Então, joguei e mudei para isto:

rule replicated-nvme {
    id 6
    type replicated
    step take default class nvme
    step choose firstn 0 type rack
    step chooseleaf firstn 0 type host
    step emit
}

e funciona. Os PGs do pool são replicados para 4 OSDs em 2 racks (2 OSDs em cada rack). A única diferença é chooseleaf firstn 0 type hostem vez de chooseleaf firstn 1 type host.

As perguntas são:

  • qual é a diferença entre chooseechooseleaf
  • qual é o significado do número depoisfirstn
  • como é definida a hierarquia das etapas , o que é verificado antes e depois?

Resumindo, gostaria de saber a sintaxe das regras de crush.
Apenas para esclarecimento, embora o cluster de produção tenha um número par de hosts por sala/rack e até mesmo regras de replicação, a distribuição dos objetos não é muito uniforme. Ou seja, a distribuição dos PGs pode diferir em até 10% por OSD.
Suspeito que a primeira regra definida acima esteja errada e que apenas pelo grande número de OSDs a distribuição seja mais ou menos igual.

ceph

1 respostas

  1. Best Answer

    Os documentos são bastante claros sobre as opções, não tenho certeza de qual é a sua reclamação. Vou tentar decompô-lo de qualquer maneira com base no seu exemplo:

    step take default class nvme
step choose firstn 0 type rack
step chooseleaf firstn 0 type host
    • Vá para a raiz de esmagamento "padrão", geralmente na parte superior da sua, ceph osd treese você tiver apenas uma raiz, selecione apenas dispositivos do tipo "nvme".
    • Em seguida, escolha 0 baldes do tipo “rack”. Se {num} == 0, escolha buckets pool-num-replicas (quantos buckets estiverem disponíveis), portanto, no seu caso, 2 racks.
    • Em cada rack escolha folha selecione 0 OSDs dentro do host do tipo bucket, "folhas" porque desce no galho da árvore de esmagamento. Novamente, se {num} == 0 ele escolhe tantos OSDs quanto pool-num-replicas.

    Se quiser ser mais específico, você pode substituir o 0 pelo número exato de buckets que deseja que o crush escolha, por exemplo, isso também deve funcionar, ter 4 réplicas no total, distribuídas em dois racks:

    step take default class nvme
step choose firstn 2 type rack
step chooseleaf firstn 2 type host

    A hierarquia é de cima para baixo. Você também pode brincar com o crushtool . Pode ser muito valioso se você quiser testar a distribuição sem modificar o mapa de esmagamento atual ao vivo, o que pode causar movimentação inesperada de dados. A distribuição de dados do seu cluster depende de alguns fatores, a regra aplicada não é importante nesse sentido, o balanceador está habilitado? ceph balancer statusmostra o estado atual. O número de PGs por OSD também é muito importante. Se seus PGs forem grandes e você tiver apenas alguns deles, os dados não poderão ser distribuídos uniformemente.

    • 1

relate perguntas