1 SES e Ceph #
O SUSE Enterprise Storage é um sistema de armazenamento distribuído projetado para escalabilidade, confiabilidade e desempenho que usa a tecnologia Ceph. É possível executar um cluster do Ceph em servidores convencionais em uma rede comum, como Ethernet. O cluster tem capacidade de dimensionamento para milhares de servidores (posteriormente mencionados como nós) e dentro da faixa de petabytes. Ao contrário dos sistemas convencionais que têm tabelas de alocação para armazenar e buscar dados, o Ceph usa um algoritmo determinístico para alocar armazenamento de dados e não tem nenhuma estrutura centralizada de informações. Nos clusters de armazenamento, o Ceph considera a adição ou remoção de hardware a regra, e não a exceção. O cluster do Ceph automatiza as tarefas de gerenciamento, como distribuição e redistribuição de dados, replicação de dados, detecção de falhas e recuperação. O Ceph é autorreparável e autogerenciável, o que resulta na redução de overhead administrativo e orçamentário.
Este capítulo apresenta uma visão geral resumida do SUSE Enterprise Storage 7.1 e descreve brevemente os componentes mais importantes.
1.1 Recursos do Ceph #
O ambiente do Ceph tem os seguintes recursos:
- Escalabilidade
O Ceph pode ser dimensionado para milhares de nós e pode gerenciar o armazenamento na faixa de petabytes.
- Hardware convencional
Não há necessidade de hardware especial para executar um cluster do Ceph. Para obter os detalhes, consulte a Capítulo 2, Requisitos e recomendações de hardware
- Autogerenciável
O cluster do Ceph é autogerenciável. Quando os nós são adicionados, removidos ou falham, o cluster redistribui os dados automaticamente. Ele também reconhece discos sobrecarregados.
- Sem Ponto Único de Falha
Nenhum nó em um cluster armazena informações importantes separadamente. É possível configurar o número de redundâncias.
- Software de código-fonte aberto
O Ceph é uma solução de software de código-fonte aberto e independente de hardware ou de fornecedores específicos.
1.2 Componentes básicos do Ceph #
Para aproveitar todas as vantagens do Ceph, é necessário conhecer alguns dos componentes e conceitos básicos. Esta seção apresenta algumas partes do Ceph que são mencionadas com mais frequência em outros capítulos.
1.2.1 RADOS #
O componente básico de Ceph é denominado RADOS (Reliable Autonomic Distributed Object Store). Ele é responsável por gerenciar os dados armazenados no cluster. Normalmente, os dados no Ceph são armazenados como objetos. Cada objeto consiste em um identificador e nos dados.
O RADOS oferece os seguintes métodos de acesso aos objetos armazenados que envolvem diversos casos de uso:
- Gateway de Objetos
O Gateway de Objetos é um gateway HTTP REST para armazenamento de objetos RADOS. Ele permite acesso direto aos objetos armazenados no cluster do Ceph.
- Dispositivo de blocos RADOS
É possível acessar o Dispositivo de Blocos RADOS (RBD, RADOS Block Device) como qualquer outro dispositivo de blocos. Eles podem ser usados em combinação com o
libvirt
para fins de virtualização, por exemplo.- CephFS
O Sistema de Arquivos Ceph é compatível com POSIX.
librados
librados
é uma biblioteca que pode ser usada com várias linguagens de programação para criar um aplicativo capaz de interagir diretamente com o cluster de armazenamento.
O Gateway de Objetos e o RBD usam a librados
, enquanto o CephFS estabelece interface direta com o RADOS (Figura 1.1, “Interfaces com o armazenamento de objetos do Ceph”).
1.2.2 CRUSH #
No centro de um cluster do Ceph está o algoritmo CRUSH. CRUSH é o acrônimo de Controlled Replication Under Scalable Hashing. Trata-se de uma função que processa a alocação de armazenamento e precisa de poucos parâmetros equivalentes. Isso significa que apenas uma pequena quantidade de informações é necessária para calcular a posição de armazenamento de um objeto. Os parâmetros são um mapa atual do cluster, incluindo o estado de saúde, algumas regras de posicionamento definidas pelo administrador e o nome do objeto que precisa ser armazenado ou recuperado. Com essas informações, todos os nós no cluster do Ceph são capazes de calcular onde um objeto e suas réplicas serão armazenados. Isso dificulta a gravação e a leitura de dados muito eficientes. O CRUSH tenta distribuir igualmente os dados a todos os nós do cluster.
O Mapa CRUSH contém todos os nós de armazenamento e as regras de posicionamento definidas pelo administrador para armazenar objetos no cluster. Ele define uma estrutura hierárquica que costuma corresponder à estrutura física do cluster. Por exemplo, os discos com dados estão em hosts, os hosts estão em racks, os racks estão em linhas e as linhas estão em data centers. É possível usar essa estrutura para definir domínios de falha. Em seguida, o Ceph garante que as replicações sejam armazenadas em ramificações diferentes de um domínio de falha específico.
Se o domínio de falha for definido como rack, as replicações dos objetos serão distribuídas para racks diferentes. Isso pode reduzir as interrupções causadas por um switch com falha em um rack. Se uma unidade de distribuição de energia fornece uma linha de racks, o domínio de falha pode ser definido como linha. Quando a unidade de distribuição de energia falha, os dados replicados ainda ficam disponíveis em outras linhas.
1.2.3 Nós e daemons do Ceph #
No Ceph, os nós são servidores que trabalham para o cluster. Eles podem executar vários tipos de daemons. Recomendamos executar apenas um tipo de daemon em cada nó, exceto os daemons do Ceph Manager, que podem ser combinados com Ceph Monitors. Cada cluster requer pelo menos os daemons do Ceph Monitor, Ceph Manager e Ceph OSD:
- Nó de Admin
O Nó de Admin é um nó de cluster do Ceph do qual você executa comandos para gerenciar o cluster. O Nó de Admin é um ponto central do cluster do Ceph porque ele gerencia o restante dos nós do cluster, consultando e instruindo os serviços do Minion Salt.
- Ceph Monitor
Os nós do Ceph Monitor (geralmente abreviado como MON) mantêm informações sobre o estado de saúde do cluster, um mapa de todos os nós e as regras de distribuição de dados (consulte a Seção 1.2.2, “CRUSH”).
Em caso de falhas ou conflitos, os nós do Ceph Monitor no cluster decidem, por maioria, quais informações estão corretas. Para formar uma maioria qualificada, é recomendável ter um número ímpar de nós do Ceph Monitor e, pelo menos, três deles.
Se for usado mais de um site, os nós do Ceph Monitor deverão ser distribuídos para um número ímpar de sites. O número de nós do Ceph Monitor por site deve ser suficiente para que mais do que 50% dos nós do Ceph Monitor continuem funcionando em caso de falha de um site.
- Ceph Manager
O Ceph Manager coleta as informações de estado do cluster inteiro. O daemon do Ceph Manager é executado com os daemons do Ceph Monitor. Ele fornece monitoramento adicional e estabelece interface com os sistemas externos de monitoramento e gerenciamento. Ele também inclui outros serviços. Por exemplo, a IU da Web do Ceph Dashboard é executada no mesmo nó que o Ceph Manager.
O Ceph Manager não requer configuração adicional, além de garantir que esteja em execução.
- Ceph OSD
O Ceph OSD é um daemon que processa Dispositivos de Armazenamento de Objetos, que são unidades físicas ou lógicas de armazenamento (discos rígidos ou partições). Os Dispositivos de Armazenamento de Objetos podem ser discos/partições físicos ou volumes lógicos. O daemon também se encarrega da replicação e redistribuição de dados em caso de nós adicionados ou removidos.
Os daemons Ceph OSD comunicam-se com os daemons do monitor e informam a eles o estado dos outros daemons OSD.
Para usar o CephFS, o Gateway de Objetos, o NFS Ganesha ou o iSCSI Gateway, são necessários outros nós:
- MDS (Metadata Server – Servidor de Metadados)
Os metadados do CephFS são armazenados em seu próprio pool RADOS (consulte a Seção 1.3.1, “Pools”). Os Servidores de Metadados atuam como uma camada de cache inteligente para os metadados e serializam o acesso quando necessário. Isso permite acesso simultâneo de vários clientes sem sincronização explícita.
- Gateway de Objetos
O Gateway de Objetos é um gateway HTTP REST para armazenamento de objetos RADOS. Ele é compatível com o OpenStack Swift e o Amazon S3 e tem seu próprio gerenciamento de usuários.
- NFS Ganesha
O NFS Ganesha concede acesso de NFS ao Gateway de Objetos ou CephFS. Ele é executado no espaço do usuário, em vez do kernel, e interage diretamente com o Gateway de Objetos ou o CephFS.
- iSCSI Gateway
iSCSI é um protocolo de rede de armazenamento que permite aos clientes enviar comandos SCSI para dispositivos de armazenamento SCSI (destinos) em servidores remotos.
- Gateway do Samba
O Gateway do Samba concede ao Samba acesso aos dados armazenados no CephFS.
1.3 Estrutura de armazenamento do Ceph #
1.3.1 Pools #
Os objetos armazenados em um cluster do Ceph são agrupados em pools. Os pools representam as partições lógicas do cluster para o mundo externo. É possível definir um conjunto de regras para cada pool. Por exemplo, o número necessário de replicações de cada objeto. A configuração padrão dos pools chama-se pool replicado.
Normalmente, os pools contêm objetos, mas também podem ser configurados para agir como um RAID 5. Nessa configuração, os objetos são armazenados em pacotes com outros pacotes de codificação. Os pacotes de codificação contêm as informações redundantes. O número de dados e de pacotes de codificação pode ser definido pelo administrador. Nessa configuração, os pools são denominados pools codificados para eliminação ou pools EC.
1.3.2 Grupos de posicionamento #
Os PGs (Placement Groups – Grupos de Posicionamento) são usados para distribuição de dados em um pool. Ao criar um pool, determinado número de grupos de posicionamento é definido. Os grupos de posicionamento são usados internamente para agrupar objetos e são um fator importante para o desempenho de um cluster do Ceph. O PG de um objeto é determinado pelo nome do objeto.
1.3.3 Exemplo #
Esta seção mostra um exemplo simplificado de como o Ceph gerencia os dados (consulte a Figura 1.2, “Exemplo de Ceph de pouco dimensionamento”). Esse exemplo não representa uma configuração recomendada para um cluster do Ceph. A configuração de hardware consiste em três nós de armazenamento ou Ceph OSDs (Host 1
, Host 2
, Host 3
). Cada nó tem três discos rígidos que são usados como OSDs (osd.1
a osd.9
). Os nós do Ceph Monitor são ignorados neste exemplo.
Enquanto Ceph OSD ou daemon Ceph OSD refere-se a um daemon executado em um nó, a palavra OSD refere-se ao disco lógico com o qual o daemon interage.
O cluster tem dois pools: Pool A
e Pool B
. Enquanto o Pool A replica os objetos apenas duas vezes, a resiliência do Pool B é mais importante e efetua três replicações de cada objeto.
Quando um aplicativo coloca um objeto em um pool (por exemplo, pela API REST), um Grupo de Posicionamento (PG1
a PG4
) é selecionado com base no nome do pool e do objeto. Em seguida, o algoritmo CRUSH calcula em quais OSDs o objeto é armazenado, com base no Grupo de Posicionamento que contém o objeto.
Neste exemplo, o domínio de falha foi definido como host. Isso garante que as replicações dos objetos sejam armazenadas em hosts diferentes. Dependendo do nível de replicação definido para um pool, o objeto é armazenado em dois ou três OSDs, que são usados pelo Grupo de Posicionamento.
Um aplicativo que grava um objeto interage apenas com um Ceph OSD: o principal. O Ceph OSD principal efetua a replicação e confirma a conclusão do processo de gravação depois que todos os outros OSDs armazenaram o objeto.
Em caso de falha no osd.5
, todos os objetos no PG1
ainda estarão disponíveis no osd.1
. Logo que o cluster reconhece a falha em um OSD, outro OSD entra em ação. Neste exemplo, o osd.4
é usado como substituto do osd.5
. Os objetos armazenados no osd.1
são replicados para o osd.4
para restaurar o nível de replicação.
Se um novo nó com novos OSDs for adicionado ao cluster, o mapa do cluster será modificado. Na sequência, a função CRUSH retorna locais diferentes para os objetos. Os objetos que recebem os novos locais serão realocados. Esse processo resulta no uso equilibrado de todos os OSDs.
1.4 BlueStore #
BlueStore é um novo back end de armazenamento padrão para Ceph a partir do SES 5. Ele apresenta melhor desempenho do que o FileStore, checksum completo de dados e compactação incorporada.
O BlueStore gerencia um, dois ou três dispositivos de armazenamento. No caso mais simples, o BlueStore consome um único dispositivo de armazenamento principal. Normalmente, o dispositivo de armazenamento é particionado em duas partes:
Uma pequena partição denominada BlueFS que implementa funcionalidades do tipo do sistema de arquivos que o RocksDB exige.
Normalmente, o restante do dispositivo é ocupado por uma partição grande. Ele é gerenciado diretamente pelo BlueStore e contém todos os dados reais. Normalmente, esse dispositivo principal é identificado por um link simbólico de bloco no diretório de dados.
É possível também implantar o BlueStore em dois dispositivos adicionais:
É possível usar o dispositivo WAL para o diário interno ou o registro write-ahead do BlueStore. Ele é identificado pelo link simbólico block.wal
no diretório de dados. O uso de um dispositivo WAL separado será útil apenas se ele for mais rápido do que o dispositivo principal ou o dispositivo de BD. Por exemplo, quando:
O dispositivo WAL é um NVMe, o dispositivo de BD é uma SSD e o dispositivo de dados é uma SSD ou HDD.
Ambos os dispositivos WAL e de BD são SSDs separadas, e o dispositivo de dados é uma SSD ou HDD.
É possível usar um dispositivo de BD para armazenar metadados internos do BlueStore. O BlueStore (ou, em vez dele, o RocksDB incorporado) colocará o máximo de metadados que puder no dispositivo de BD para melhorar o desempenho. Mais uma vez, apenas será útil provisionar um dispositivo de BD compartilhado se ele for mais rápido do que o dispositivo principal.
Planeje com cuidado para garantir o tamanho suficiente do dispositivo de BD. Se o dispositivo de BD ficar cheio, os metadados serão despejados no dispositivo principal, o que prejudica bastante o desempenho do OSD.
Você pode verificar se uma partição WAL/BD está ficando lotada e sendo despejada ao executar o comando ceph daemon osd.ID perf dump
. O valor slow_used_bytes
mostra a quantidade de dados que está sendo despejada:
cephuser@adm >
ceph daemon osd.ID perf dump | jq '.bluefs'
"db_total_bytes": 1073741824,
"db_used_bytes": 33554432,
"wal_total_bytes": 0,
"wal_used_bytes": 0,
"slow_total_bytes": 554432,
"slow_used_bytes": 554432,
1.5 Informações adicionais #
Como um projeto comunitário, o Ceph tem sua própria documentação online completa. Para os tópicos não encontrados neste manual, visite https://docs.ceph.com/en/pacific/.
A publicação original CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data por S.A. Weil, S.A. Brandt, E.L. Miller, C. Maltzahn apresenta informações úteis sobre o funcionamento interno do Ceph. Principalmente na implantação de clusters em grande escala, trata-se de uma leitura recomendada. Você encontra essa publicação em http://www.ssrc.ucsc.edu/papers/weil-sc06.pdf.
É possível usar o SUSE Enterprise Storage com distribuições que não são do SUSE OpenStack. Os clientes Ceph precisam estar em um nível que seja compatível com o SUSE Enterprise Storage.
NotaA SUSE suporta o componente de servidor da implantação do Ceph, e o cliente é suportado pelo fornecedor de distribuição do OpenStack.