A Figura 1 exibe a estrutura básica do Ceph.

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 dados através dos nós do cluster.
• LIBRADOS:
  Biblioteca que provê uma interface nativa para trabalhar com uma implementaçã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 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 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. É 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.
• 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 objetos, os MDSs não serão necessários.
• OSD:
  São a representação dos discos físicos nos quais os dados são armazenados na forma de objetos. Esse é o único componente do Ceph que escreve e lê os dados dos usuários. De forma geral, o número de OSDs de um cluster representa o número total de discos físicos do mesmo. A recomendação é que cada OSD tenha, no mínimo, 1 CPU e 2GB de RAM 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 a clientes do kernel Linux, 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 espalhados 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 disco em várias partes de tamanho definido, que são armazenadas em vários OSDs do cluster como objetos. Quando esses dados são necessários, as partes são recuperadas, concatenadas 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

  

  Figura 4: Armazenamento em blocos com librbd

• RGW:
  Provê serviços de armazenamento de objetos do tipo S3. Utiliza a biblioteca librgw para se comunicar com o librados, e disponibiliza uma API Restful com interfaces compatíveis com o Amazon S3 e o OpenStack Swift.
  

  Figura 5: Armazenamento em blocos com KRDB

• 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 metadados dos arquivos, como: hierarquia dos diretórios e arquivos, per missõ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.