Experiência de operação do CEPH

Quando os dados excedem a capacidade de um único disco, é hora de considerar o RAID. Na infância, ouvia frequentemente dos mais velhos: "um dia o RAID ficará no passado, os armazenamentos de objetos dominarão o mundo, e você nem saberá o que é o CEPH". Por isso, assim que comecei minha vida independente, o primeiro passo foi criar meu próprio cluster. O objetivo do experimento era entender a estrutura interna do ceph e suas aplicações. Quão justificável é a implementação do ceph em empresas de médio porte e em pequenas também? Após alguns anos de uso e algumas perdas irrecuperáveis de dados, entendi as sutilezas — nem tudo é tão simples assim. As características do CEPH criam obstáculos à sua ampla adoção, e por causa disso, os experimentos chegaram a um impasse. Abaixo está uma descrição de todos os passos realizados, os resultados obtidos e as conclusões tiradas. Ficarei grato se pessoas experientes puderem compartilhar suas vivências e esclarecer certos pontos.

Nota: os comentadores apontaram erros significativos em algumas suposições que requerem uma revisão completa do artigo.

Estratégia CEPH

O cluster CEPH combina um número arbitrário de K discos de tamanhos variados e armazena dados neles, duplicando cada pedaço (4 MB por padrão) um número definido de N vezes.

Vamos considerar o caso mais simples com dois discos iguais. A partir deles, é possível montar um RAID 1 ou um cluster com N=2 — o resultado será o mesmo. Se houver três discos, e eles forem de tamanhos diferentes, montar um cluster com N=2 é fácil: parte dos dados estará nos discos 1 e 2, parte nos discos 1 e 3, e parte nos discos 2 e 3, enquanto no RAID isso não acontece (é possível montar tal RAID, mas seria uma aberração). Se houver ainda mais discos, é possível criar um RAID 5; o CEPH tem um análogo — erasure_code, que contradiz os conceitos anteriores dos desenvolvedores, e por isso não é considerado. O RAID 5 pressupõe que há um número pequeno de discos, e todos eles estão em bom estado. Se um falhar, os demais devem aguentar até que o disco seja substituído e os dados sejam restaurados nele. Por outro lado, o CEPH, com N>=3, incentiva o uso de discos antigos, especialmente se mantiver vários discos bons para armazenar uma cópia dos dados, enquanto as outras duas ou três cópias são armazenadas em uma grande quantidade de discos antigos. Dessa forma, a informação ficará segura, pois enquanto os discos novos estiverem funcionando — não há problemas, e se um deles quebrar, a falha simultânea de três discos com mais de cinco anos de vida, preferencialmente, de diferentes servidores — é um evento extremamente improvável.

Na distribuição de cópias, há uma nuance. Por padrão, assume-se que os dados são divididos em um maior número (~100 por disco) de grupos de distribuição PG, cada um dos quais é duplicado em alguns discos. Suponha que K=6 e N=2, então, ao falhar qualquer dois discos, os dados são garantidamente perdidos, pois, pela teoria das probabilidades, haverá pelo menos uma PG que estará localizada exatamente nesses dois discos. E a perda de um grupo torna todos os dados no pool inacessíveis. Se, no entanto, os discos forem divididos em três pares e for permitido armazenar os dados apenas em discos dentro de um par, essa distribuição também será resistente à falha de qualquer disco; ainda assim, na falha de dois, a probabilidade de perda de dados não é 100%, mas apenas 3/15, e mesmo na falha de três discos — apenas 12/20. Daí, a entropia na distribuição de dados não contribui para a resistência a falhas. Também notamos que, para um servidor de arquivos, a memória RAM livre aumenta significativamente a velocidade de resposta. Quanto mais memória em cada nó, e quanto mais memória em todos os nós — mais rápido será. Esta é, sem dúvida, uma vantagem do cluster em relação a um servidor único e, mais ainda, a um NAS de hardware, que integra um volume de memória muito pequeno.

Daqui, conclui-se que o CEPH é uma boa maneira de criar um sistema de armazenamento de dados confiável de dezenas de TB com investimentos mínimos a partir de equipamentos obsoletos, com possibilidade de escalabilidade (aqui, claro, serão necessárias despesas, mas menores em comparação com as soluções de armazenamento comerciais).

Implementação do cluster

Para o experimento, pegaremos um computador descontinuado Intel DQ57TM + Intel Core i3 540 + 16 GB de RAM. Quatro discos de 2 TB serão organizados em uma espécie de RAID10; após o teste bem-sucedido, adicionaremos um segundo nó e mais discos iguais.

Instalamos o Linux. O distribuidor deve ter a capacidade de personalização e estabilidade. Debian e Suse atendem a esses requisitos. O Suse possui um instalador mais flexível, permitindo desativar qualquer pacote; infelizmente, não consegui entender quais podem ser removidos sem comprometer o sistema. Instalamos o Debian através do debootstrap buster. A opção min-base instala um sistema não funcional, que não tem os drivers necessários. A diferença de tamanho em comparação com a versão completa não é tão grande a ponto de justificar preocupações. Como o trabalho é feito em uma máquina física, é desejável fazer snapshots, como em máquinas virtuais. Essa possibilidade é oferecida pelo LVM ou btrfs (ou xfs, ou zfs - a diferença não é grande). Snapshots não são o ponto forte do LVM. Optamos pelo btrfs. E o carregador - no MBR. Não faz sentido poluir o disco com uma partição FAT de 50 MB, quando podemos colocá-la na área de 1 MB da tabela de partições e destinar todo o espaço ao sistema. Ocupou 700 MB no disco. Não me lembro quanto ocupa a instalação básica do SUSE - parece que cerca de 1,1 ou 1,4 GB.

Instalamos o CEPH. Ignoramos a versão 12 no repositório do debian e conectamos diretamente do site 15.2.3. Seguimos as instruções da seção "instalando o CEPH manualmente" com as seguintes observações:

• Antes de conectar o repositório, é necessário instalar gnupg wget ca-certificates
• Após conectar o repositório, mas antes da instalação do cluster, a instalação de pacotes foi omitida: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
• No momento da instalação do CEPH, por razões inexplicáveis, o lvm2 tentará ser instalado. Na verdade, não é um problema, mas a instalação falha, portanto, o CEPH também não será instalado.

  Esse patch ajudou:

  cat <> /var/lib/dpkg/status
  Package: lvm2
  Status: install ok installed
  Priority: important
  Section: admin
  Installed-Size: 0
  Maintainer: Debian Adduser Developers 
  Architecture: all
  Multi-Arch: foreign
  Version: 113.118
  Description: No-install
  EOF
  

Visão geral do cluster

ceph-osd — é responsável pelo armazenamento de dados no disco. Para cada disco, um serviço de rede é iniciado, que aceita e executa solicitações de leitura ou gravação em objetos. No disco, são criadas duas partições. Uma delas contém informações sobre o cluster, número do disco, além de chaves do cluster. Essas informações, que totalizam 1KB, são criadas uma vez ao adicionar o disco e nunca notei que mudassem. Na segunda partição, não há sistema de arquivos e são armazenados dados binários do CEPH. A instalação automática nas versões anteriores criava uma partição xfs de 100MB para informações de serviço. Eu converti o disco para MBR e aloquei apenas 16MB — o serviço não reclama. Acredito que sem problemas o xfs poderia ser substituído pelo ext. Esta partição é montada em /var/lib/…, onde o serviço lê informações sobre OSD, além de encontrar uma referência ao dispositivo de bloco, onde os dados binários são armazenados. Teoricamente, pode-se imediatamente alocar auxiliares em /var/lib/…, e o disco inteiro dedicar-se aos dados. Ao criar OSD através do ceph-deploy, uma regra de montagem da partição em /var/lib/… é criada automaticamente, e os direitos de leitura sobre o respectivo dispositivo de bloco são atribuídos ao usuário ceph. Na instalação manual, isso deve ser feito manualmente, não está mencionado na documentação. Também é desejável especificar o parâmetro osd memory target, para garantir que haja memória física suficiente.

ceph-mds. Em um nível baixo, o CEPH é um armazenamento de objetos. A capacidade de armazenamento em bloco é reduzida a armazenar cada bloco de 4MB como um objeto. O armazenamento de arquivos funciona segundo o mesmo princípio. Dois pools são criados: um para os metadados e outro para os dados. Estes são unidos em um sistema de arquivos. Nesse momento, uma espécie de registro é criado, portanto, se o sistema de arquivos for excluído, mas ambos os pools forem mantidos, não será possível recuperá-lo. Existe um procedimento para extração de arquivos por blocos, não testei. O acesso ao sistema de arquivos é gerenciado pelo serviço ceph-mds. Para cada sistema de arquivos, é necessário uma instância separada do serviço. Há uma opção de "índice", que permite criar uma semelhança de vários sistemas de arquivos em um — isso também não foi testado.

ceph-mon — este serviço armazena o mapa do cluster. Ele contém informações sobre todos os OSD, o algoritmo de distribuição de PG nos OSD e, o mais importante, informações sobre todos os objetos (os detalhes desse mecanismo não são claros para mim: há um catálogo /var/lib/ceph/mon/.../store.db, onde existe um grande arquivo — 26MB, e no cluster há 105K objetos, resultando em pouco mais de 256 bytes por objeto - eu acho que o monitor mantém uma lista de todos os objetos e os PGs em que eles residem). A corrupção desse catálogo leva à perda de todos os dados no cluster. Daí vem a conclusão de que o CRUSH mostra como os PGs estão distribuídos entre os OSDs, enquanto os objetos estão organizados em PGs — são centralmente armazenados dentro do banco de dados, por mais que os desenvolvedores tentem evitar essa palavra. Como consequência, em primeiro lugar, não podemos instalar o sistema em um pendrive em modo RO, pois o banco de dados requer gravação constante, é necessário um disco adicional para isso (difícilmente mais de 1 GB), e em segundo lugar, é necessário ter uma cópia desse banco em tempo real. Se houver vários monitores, a tolerância a falhas é garantida automaticamente, mas no nosso caso, há um monitor apenas, no máximo — dois. Há um procedimento teórico para a recuperação do monitor com base nos dados dos OSD, recorri a ele três vezes por diferentes razões, e em três ocasiões não houve mensagens de erro, assim como também não houve dados. Infelizmente, esse mecanismo não funciona. Ou exploramos uma partição minúscula no OSD e montamos um RAID para armazenar o banco de dados, o que certamente afetará mal o desempenho, ou designamos pelo menos dois suportes físicos confiáveis, preferencialmente USB, para não ocupar as portas.

rados-gw — exporta o armazenamento de objetos pelo protocolo S3 e similares. Cria múltiplos pools, sem entendimento claro do porquê. Não experimentei muito.

ceph-mgr — ao instalar este serviço, vários módulos são ativados. Um deles — o autoscale que não pode ser desligado. Ele busca manter a quantidade correta de PG/OSD. Se desejar gerenciar a proporção manualmente, você pode desativar a escalabilidade para cada pool, mas nesse caso, o módulo falha com a divisão por 0, e o estado do cluster torna-se ERROR. O módulo é escrito em Python, e comentar a linha necessária faz com que ele seja desligado. Detalhes, estou com preguiça de lembrar.

Lista de fontes utilizadas:

Instalação do CEPH
Recuperação em caso de falha total do monitor

Listagens dos scripts:

Instalação do sistema através do debootstrap

blkdev=sdb1
mkfs.btrfs -f /dev/$blkdev
mount /dev/$blkdev /mnt
cd /mnt
for i in {@,@var,@home}; do btrfs subvolume create $i; done
mkdir snapshot @/{var,home}
for i in {var,home}; do mount -o bind @${i} @/$i; done
debootstrap buster @ http://deb.debian.org/debian; echo $?
for i in {dev,proc,sys}; do mount -o bind /$i @/$i; done
cp /etc/bash.bashrc @/etc/

chroot /mnt/@ /bin/bash
echo rbd1 > /etc/hostname
passwd
uuid=`blkid | grep $blkdev | cut -d '"' -f 2`
cat < /etc/fstab
UUID=$uuid / btrfs noatime,nodiratime,subvol=@ 0 1
UUID=$uuid /var btrfs noatime,nodiratime,subvol=@var 0 2
UUID=$uuid /home btrfs noatime,nodiratime,subvol=@home 0 2
EOF
cat <> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers 
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install

Package: sudo
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers 
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install
EOF

exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6

apt -yq install --no-install-recommends linux-image-amd64 bash-completion ed btrfs-progs grub-pc iproute2 ssh smartmontools ntfs-3g net-tools man
exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6

Criação de cluster

apt -yq install --no-install-recommends gnupg wget ca-certificates
echo 'deb https://download.ceph.com/debian-octopus/ buster main' >> /etc/apt/sources.list
wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -
apt update
apt -yq install --no-install-recommends ceph-common ceph-mon

echo 192.168.11.11 rbd1 >> /etc/hosts
uuid=`cat /proc/sys/kernel/random/uuid`
cat < /etc/ceph/ceph.conf
[global]
fsid = $uuid
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
mon allow pool delete = true
mon host = 192.168.11.11
mon initial members = rbd1
mon max pg per osd = 385
osd crush update on start = false
osd memory target = 1610612736
osd scrub chunk min = 1
osd scrub chunk max = 2
osd scrub sleep = .2
osd pool default pg autoscale mode = off
osd pool default size = 1
osd pool default min size = 1
osd pool default pg num = 1
osd pool default pgp num = 1
[mon]
mgr initial modules = dashboard
EOF

ceph-authtool --create-keyring ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'
ceph-authtool --create-keyring ceph.client.admin.keyring --gen-key -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *' --cap mgr 'allow *'
cp ceph.client.admin.keyring /etc/ceph/
ceph-authtool --create-keyring bootstrap-osd.ceph.keyring --gen-key -n client.bootstrap-osd --cap mon 'profile bootstrap-osd' --cap mgr 'allow r'
cp bootstrap-osd.ceph.keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
ceph-authtool ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
ceph-authtool ceph.mon.keyring --import-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
monmaptool --create --add rbd1 192.168.11.11 --fsid $uuid monmap
rm -R /var/lib/ceph/mon/ceph-rbd1/*
ceph-mon --mkfs -i rbd1 --monmap monmap --keyring ceph.mon.keyring
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-mon@rbd1
systemctl start ceph-mon@rbd1
ceph mon enable-msgr2
ceph status

# dashboard

apt -yq install --no-install-recommends ceph-mgr ceph-mgr-dashboard python3-distutils python3-yaml
mkdir /var/lib/ceph/mgr/ceph-rbd1
ceph auth get-or-create mgr.rbd1 mon 'allow profile mgr' osd 'allow *' mds 'allow *' > /var/lib/ceph/mgr/ceph-rbd1/keyring
systemctl enable ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1
ceph config set mgr mgr/dashboard/ssl false
ceph config set mgr mgr/dashboard/server_port 7000
ceph dashboard ac-user-create root 1111115 administrator
systemctl stop ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1

Adicionando OSD (parte)

apt install ceph-osd

osdnum=`ceph osd create`
mkdir -p /var/lib/ceph/osd/ceph-$osdnum
mkfs -t xfs /dev/sda1
mount -t xfs /dev/sda1 /var/lib/ceph/osd/ceph-$osdnum
cd /var/lib/ceph/osd/ceph-$osdnum
ceph auth get-or-create osd.0 mon 'profile osd' mgr 'profile osd' osd 'allow *' > /var/lib/ceph/osd/ceph-$osdnum/keyring
ln -s /dev/disk/by-partuuid/d8cc3da6-02 block
ceph-osd -i $osdnum --mkfs
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-osd@$osdnum
systemctl start ceph-osd@$osdnum

Resumo

A principal vantagem de marketing do CEPH é o CRUSH, um algoritmo para calcular a localização dos dados. Os monitores distribuem esse algoritmo para os clientes, que então solicitam diretamente o nó e o OSD necessários. O CRUSH garante a ausência de centralização. Ele consiste em um pequeno arquivo que pode ser impresso e pendurado na parede. A prática demonstrou que o CRUSH não é um mapa abrangente. Se os monitores forem destruídos e recriados, mantendo todos os OSD e o CRUSH, isso não é suficiente para recuperar o cluster. Portanto, conclui-se que cada monitor armazena alguns metadados sobre todo o cluster. Um pequeno volume desses metadados não impõe limitações ao tamanho do cluster, mas requer a garantia de sua preservação, o que exclui a economia de disco ao instalar o sistema em um pen drive e proíbe clusters com menos de três nós. A política agressiva do desenvolvedor em relação a recursos opcionais. Longe do minimalismo. A documentação está no nível: "agradecemos pelo que existe, mas é muito, muito escassa". A possibilidade de interagir com serviços de baixo nível é prevista, mas a documentação aborda essa questão de forma muito superficial, portanto, é mais provável que não. Praticamente não há chances de recuperação de dados em situações de emergência.

Opções para ações futuras: abandonar o CEPH e utilizar um btrfs multicombinação comum (ou xfs, zfs), buscar novas informações sobre o CEPH que possibilitem sua operação nas condições mencionadas, tentar, como aperfeiçoamento de habilidades, escrever seu próprio armazenamento.

Fonte: habr.com