Ceph : Como funciona?

Posted on by fabio.reis

Neste post do Ceph Brasil será apresentado de forma conceitual como funciona o processo de IO dentro do cluster CEPH.

Vamos abranger também detalhes de cada componente para tentar esclarecer de forma simples o seu funcionamento.

A abordagem do Ceph para lidar como uma nova implementação de  sistema de armazenamento distribuído de scale-out baseado em hardware comum que se comunica através de uma rede TCP / IP .

Essa abordagem permite um processo operacional rápido e acessível sem interrupções , ao mesmo tempo em que suporta a nova escala de petabytes com um desempenho muito alto. Esse tipo de armazenamento hiperescalável se ajusta muito bem aos modelos de Cloud.





1. Componentes

1.1 Componentes do Cluster

Um cluster CEPH funciona com os seguintes componentes:

  • OSD (Object Storage Daemon) – Cada node de storage Ceph executa um ou mais daemons do Ceph OSD (um por disco). O OSD é um dameon que faz todas as operações armazenamento de dados, replicação e recuperação de dados.  Os sistemas de arquivos normalmente usados são XFS, btrfs e ext4.
  • Monitor – O Monitor do Ceph é o daemon responsável por manter uma cópia principal do mapa do cluster. O cluster do Ceph precisa de um quorum mínimo de 3 mais ou mais para garantir alta disponibilidade (abaixo será apresentado em imagem como o processo funciona).
  •  Rados Gateway – O rados gateway entrega um serviço de api, onde podemos nos conectar via S3 ou Swift diretamente com o Ceph.
  • Metadata Server – O MDS manipula todas as operações de arquivo e utiliza objetos RADOS para armazenar dados e atributos do sistema de arquivos. Pode ser escalado horizontalmente adicionando com mais Ceph Metadata Servers para suportar mais clientes. 
  • Ceph Manager – O daemon do Ceph Manager (ceph-mgr) é executado ao lado dos daemons do monitor, para fornecer monitoramento adicional e interfaces para sistemas externos de monitoramento e gerenciamento ( Somente disponível da versão Luminous para cima).



1.2 Clientes

Para que haja conexão com o Cluster o Ceph fornece uma interface de bloco (RBD), uma interface de objeto (RGW) e uma interface de sistema de arquivos (CephFS).

Em nosso diagrama na imagem abaixo podemos observar os seguintes tipos de clientes :



  • S3 / SWIFT (RGW) – Consome os serviços do Rados gateway via internet para armazenar objetos.
  • RBD. Um dispositivo de bloco confiável e totalmente distribuído com integração de plataforma em nuvem
  • CephFS – O Ceph Filesystem (CephFS) é um sistema de arquivos compatível com POSIX que usa um cluster Ceph para armazenar seus dados. Para utilizar este recurso é necessário ter uma estrutura de Ceph Metadata Server (MDS) no cluster Ceph
  • LIBRADOS –  Uma biblioteca que permite que os aplicativos acessem diretamente RADOS (C, C ++, Java, Python, Ruby, PHP)


2. Funcionamento

2.1 Autenticação

O Ceph utiliza o sistema de autenticação cephx similar ao Kerberos para autenticar os usuários e os daemons, onde não é utilizado SSL ou TLS. O cephx compartilha chaves secretas para autenticação mútua, o que significa que tanto os clientes e os monitores do cluster tem uma cópia da chave secreta do cliente.


2.2 Cluster Map

O Ceph  têm conhecimento da topologia de cluster, que inclui cinco mapas chamados de “Cluster Map”:

  • Monitor Map : Contém o fsid do cluster, a posição, o nome do endereço e a porta de cada monitor. Também indica a época atual, quando o mapa foi criado e a última vez que foi alterado. Para visualizar um mapa do monitor, execute ceph mon dump.
  • OSD Map : contém o fsid do cluster, quando o mapa foi criado e modificado pela última vez, uma lista de pools, tamanhos de réplicas, números PG, uma lista de OSDs e seus status (por exemplo, up, in edown). Para visualizar um mapa OSD, execute ceph osd dump.
  •  PG Map : Contém a versão PG, seu registro de data e hora, a última época do mapa OSD, as proporções completas e detalhes de cada grupo de posicionamento, como PG ID, Up Set, Ativo, estado do PG (por exemplo , ativo + limpo) e estatísticas de uso de dados para cada pool.
  • CRUSH Map : Contém uma lista de dispositivos de armazenamento, a hierarquia do domínio de falha (por exemplo, dispositivo, host, rack, linha, sala etc.) e regras para percorrer a hierarquia ao armazenar dados. Para visualizar um mapa CRUSH, execute:
    ceph osd getcrushmap -o {filename};
    decompile-o executando: 
    crushtool -d {compiled-crushmap-filename} -o {decompiled-crushmap-filename}.
    Você pode ver o mapa descompilado em um editor de texto.
  •  MDS Map(CEPHFS) : Contém a época atual do mapa MDS, quando o mapa foi criado e a última 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. Para visualizar um mapa do MDS, execute ceph mds dump.



Segue abaixo o exemplo do processo do Crush Map :

  1. Server Client entra em contato com os Monitors para atualizar uma cópia do cluster.
  2. O Server Client recebe o Mapemento de PGs e OSD’s.
  3. O Server Client envia o dado para gravar  no cluster e todo o processo do Crush mapeando as PGs para as OSD’s.
  4.  É realizado todo o processo de gravação e replicação (Será detalhado abaixo).

Para maior confibilidade e tolerância a falhas , o Ceph suporta um cluster de monitores, onde em um cenário de  falha de 1 Monitor server faça com que o perca o estado atual do cluster .

Por esse motivo, o Ceph utiliza o algoritmo Paxos para estabelecer um consenso entre os Monitors e sempre atualizar o estado Cluster.

OBS: A comunicação do cliente com o monitor é realizada apenas para atualizar o Crush Map, a gravação do dado é realizada direto em comunicação com o Storage node de forma independente. 



2.3 Separação Lógica

O Ceph utiliza 3 componentes importantes para fazer a separação lógica dos dados :

  • Pools – Os objetos no Ceph são armazenados em Pools. Cada pool é divido em grupos de posicionamento pg_num(PGs) onde cada PG contém fragmentos do objeto do conjunto geral.
  • Placement Groups – O Ceph mapeia objetos para placement groups (PGs)que são fragmentos de um conjunto de objetos que são  mapeados para diversas OSDs.
  • CRUSH Map –  O CRUSH é o que permite com que o Ceph seja dimensionado sem gargalos de desempenho, sem limitações de escalabilidade e sem um único ponto de falha. Os mapas CRUSH fornecem a topologia física do cluster ao algoritmo CRUSH para determinar onde os dados de um objeto e suas réplicas devem ser armazenados e como fazer isso nos domínios de falha para maior segurança de dados.





2.4 Processo de Escrita e Leitura

O processo de  leitura e escrita é realizado da seguite forma no cluster :

  1. O cliente grava o objeto na PG identificado no OSD principal.
  2. Na OSD principal com sua própria cópia do mapa CRUSH identifica outras OSDs.
  3. É realizado replica para a Segunda OSD.
  4. É realizado replica para a Terceira OSD.
  5. O Cliente recebe confirmação de escrita com sucesso.

No exemplo abaixo temos o exemplo de leitura .



2.3 Replicação dos Dados

Nos outros tópicos falamos como o dado é consumido no cluster, neste tópico apresentamos como o dado é replicado fisicamente :


Quando uma PG é replicada  você receberá cópias idênticas desses objetos em cada OSD que o CRUSH decide que os PGs devem ser mapeados.

Se você tiver um pool replicado em 3 com 128 PGs, você terá 384 PGs espalhadas por quantas OSDs você tiver.

Graças ao algoritmo CRUSH todos os blocos são distribuídos por todo o cluster aproveitando a velocidade total da rede, os IOPs de disco e a largura de banda.



2.5 Separação Física

Os mapas CRUSH contêm uma lista de OSDs, uma lista de “buckets” para agregar os dispositivos em locais físicos e uma lista de regras que informam como CRUSH deve replicar os dados nos pools de cluster do Ceph.


Segundo a imagem acima para a esclarecer a questão desta separação podemos considerar que :

  • Rack com storages  SATA – Pool A e Pool B
  • Rack com storages SSD – Pool C e Pool D



O cenário proposto após alterar o Crush Map  :

Para visualizar um mapa CRUSH, execute:


ceph osd getcrushmap -o {filename};

Decompile o arquivo  executando: 
crushtool -d {compiled-crushmap-filename} -o {decompiled-crushmap-filename}.txt

Arquivo Crush Map editado para atender o cenário de exemplo: 

# 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 straw_calc_version 1

# devices
device 0 osd.0
device 1 osd.1
device 2 osd.2
device 3 osd.3
device 4 osd.4
device 5 osd.5
device 6 osd.6
device 7 osd.7

# 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 region
type 10 root

# buckets
host storage1 {
        id -4           # do not change unnecessarily
        # weight 32.737
        alg straw
        hash 0  # rjenkins1
        item osd.0 weight 5.456
        item osd.1 weight 5.456

}
host storage2  {
        id -5           # do not change unnecessarily
        # weight 32.737
        alg straw
        hash 0  # rjenkins1
        item osd.2 weight 5.456
        item osd.3 weight 5.456

}
rack sata {
        id -2           # do not change unnecessarily
        # weight 65.473
        alg straw
        hash 0  # rjenkins1
        item storage1 weight 32.737
        item storage2 weight 32.737
}

host storage3 {
        id -6           # do not change unnecessarily
        # weight 8.582
        alg straw
        hash 0  # rjenkins1
        item osd.4 weight 1.430
        item osd.5 weight 1.430

}
host storage4 {
        id -7           # do not change unnecessarily
        # weight 8.582
        alg straw
        hash 0  # rjenkins1
        item osd.6 weight 1.430
        item osd.7 weight 1.430
}
rack ssd {
        id -3           # do not change unnecessarily
        # weight 17.164
        alg straw
        hash 0  # rjenkins1
        item storage3 weight 8.582
        item storage4 weight 8.582
}

root default {
        id -1           # do not change unnecessarily
        # weight 82.637
        alg straw
        hash 0  # rjenkins1
        item sata weight 65.473
        item ssd weight 17.164
}

# rules
rule replicated_ruleset {
        ruleset 0
        type replicated
        min_size 1
        max_size 10
        step take default
        step chooseleaf firstn 0 type host
        step emit
}
rule sata {
        ruleset 1
        type replicated
        min_size 1
        max_size 10
        step take sata
        step chooseleaf firstn 0 type host
        step emit
}
rule ssd {
        ruleset 2
        type replicated
        min_size 1
        max_size 10
        step take ssd
        step chooseleaf firstn 0 type host
        step emit
}


Setando as configurações no Crush Map editadas no arquivo :

crushtool -c crushmap.txt -o crushmap
ceph osd setcrushmap -i crushmap

Comando para criar as pools : 

ceph osd pool create <POOL NAME> <NUMBER OF PGS>

Criando as pools para separar fisicamente : 

ceph osd pool create poola 256 
ceph osd pool create poolb 256
ceph osd pool create poolc 256 
ceph osd pool create poold 256


Separando fisicamente as pools : 

ceph osd pool set poola crush_ruleset 1
ceph osd pool set poolb crush_ruleset 1
ceph osd pool set poolc crush_ruleset 2
ceph osd pool set poold crush_ruleset 2

Podemos observar que no arquivo do CrushMap as regras de SATA estão com o ruleset 1 e a de SSD estão com o ruleset 2.


Conclusão

Neste documento tentamos apresentar de forma simples o funcionamento do Ceph.
As documentações abaixo foram essenciais para escrever este documento .

https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/
http://docs.ceph.com/docs/master/

Translate »