Quando há mais dados do que cabem em um disco, é hora de pensar em RAID. Quando criança, muitas vezes ouvia dos mais velhos: “um dia o RAID será uma coisa do passado, o armazenamento de objetos preencherá o mundo e você nem sabe o que é CEPH”, então a primeira coisa na minha vida independente era criar meu próprio cluster. O objetivo do experimento foi conhecer a estrutura interna do ceph e compreender o escopo de sua aplicação. Quão justificada é a implementação do ceph nas médias e pequenas empresas? Após vários anos de operação e algumas perdas irreversíveis de dados, surgiu a compreensão dos meandros de que nem tudo é tão simples. As peculiaridades do CEPH representam barreiras à sua adoção generalizada e, por causa delas, os experimentos chegaram a um beco sem saída. Abaixo está uma descrição de todas as etapas realizadas, o resultado obtido e as conclusões tiradas. Se pessoas conhecedoras compartilharem sua experiência e explicarem alguns pontos, ficarei grato.
Nota: Os comentadores identificaram erros graves em algumas das suposições que exigem revisão de todo o artigo.
Estratégia CEPH
O cluster CEPH combina um número arbitrário K de discos de tamanho arbitrário e armazena dados neles, duplicando cada parte (4 MB por padrão) um determinado número N vezes.
Consideremos o caso mais simples com dois discos idênticos. A partir deles você pode montar o RAID 1 ou um cluster com N=2 - o resultado será o mesmo. Se houver três discos e eles forem de tamanhos diferentes, então é fácil montar um cluster com N=2: alguns dos dados estarão nos discos 1 e 2, alguns estarão nos discos 1 e 3, e alguns estarão em 2 e 3, enquanto o RAID não (você pode montar tal RAID, mas seria uma perversão). Se houver ainda mais discos, então é possível criar RAID 5; o CEPH possui um análogo - erasure_code, que contradiz os conceitos iniciais dos desenvolvedores e, portanto, não é considerado. O RAID 5 pressupõe que há um pequeno número de unidades, todas em boas condições. Se um falhar, os outros deverão resistir até que o disco seja substituído e os dados sejam restaurados nele. O CEPH, com N>=3, incentiva o uso de discos antigos, em particular, se você mantiver vários discos bons para armazenar uma cópia dos dados e armazenar as duas ou três cópias restantes em um grande número de discos antigos, então as informações estará seguro, pois por enquanto os novos discos estão vivos - não há problemas, e se um deles quebrar, então a falha simultânea de três discos com vida útil superior a cinco anos, de preferência de servidores diferentes, é extremamente improvável evento.
Há uma sutileza na distribuição de cópias. Por padrão, presume-se que os dados sejam divididos em mais grupos de distribuição PG (cerca de 100 por disco), cada um deles duplicado em alguns discos. Digamos K = 6, N = 2, então se quaisquer dois discos falharem, é garantido que os dados serão perdidos, pois de acordo com a teoria da probabilidade, haverá pelo menos um PG localizado nesses dois discos. E a perda de um grupo torna todos os dados do pool indisponíveis. Se os discos forem divididos em três pares e os dados puderem ser armazenados apenas em discos dentro de um par, então tal distribuição também será resistente à falha de qualquer disco, mas se dois discos falharem, a probabilidade de perda de dados não é 100%, mas apenas 3/15, e mesmo em caso de falha de três discos - apenas 12/20. Conseqüentemente, a entropia na distribuição de dados não contribui para a tolerância a falhas. Observe também que, para um servidor de arquivos, a 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 de um cluster sobre um único servidor e, mais ainda, de um NAS de hardware, onde está incorporada uma quantidade muito pequena de memória.
Conclui-se que o CEPH é uma boa maneira de criar um sistema confiável de armazenamento de dados para dezenas de TB, com capacidade de escalar com investimento mínimo de equipamentos desatualizados (aqui, é claro, serão necessários custos, mas pequenos em comparação com sistemas de armazenamento comerciais).
Implementação de cluster
Para o experimento, vamos pegar um computador desativado Intel DQ57TM + Intel core i3 540 + 16 GB de RAM. Organizaremos quatro discos de 2 TB em algo como RAID10, após um teste bem-sucedido adicionaremos um segundo nó e o mesmo número de discos.
Instalando Linux. A distribuição requer capacidade de personalização e estabilidade. Debian e Suse atendem aos requisitos. O Suse possui um instalador mais flexível que permite desabilitar qualquer pacote; Infelizmente, não consegui descobrir quais poderiam ser jogados fora sem danificar o sistema. Instale o Debian usando o debootstrap buster. A opção min-base instala um sistema quebrado sem drivers. A diferença de tamanho em relação à versão completa não é tão grande a ponto de incomodar. Como o trabalho é realizado em uma máquina física, quero tirar snapshots, como nas máquinas virtuais. Esta opção é fornecida pelo LVM ou btrfs (ou xfs ou zfs - a diferença não é grande). Os instantâneos do LVM não são um ponto forte. Instale o btrfs. E o bootloader está no MBR. Não faz sentido sobrecarregar um disco de 50 MB com uma partição FAT quando você pode colocá-lo em uma área da tabela de partições de 1 MB e alocar todo o espaço para o sistema. Ocupou 700 MB no disco. Não me lembro quanto tem a instalação básica do SUSE, acho que é cerca de 1.1 ou 1.4 GB.
Instale o CEPH. Ignoramos a versão 12 no repositório debian e nos conectamos diretamente do site 15.2.3. Seguimos as instruções da seção “Instalar o CEPH manualmente” com as seguintes advertências:
- Antes de conectar o repositório, você deve instalar gnupg wget ca-certificates
- Depois de conectar o repositório, mas antes de instalar o cluster, a instalação de pacotes é omitida: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- Ao instalar o CEPH, por motivos desconhecidos, ele tentará instalar o lvm2. Em princípio não é uma pena, mas a instalação falha, então o CEPH também não instala.
Este patch ajudou:
cat << EOF >> /var/lib/dpkg/status Package: lvm2 Status: install ok installed Priority: important Section: admin Installed-Size: 0 Maintainer: Debian Adduser Developers <[email protected]> Architecture: all Multi-Arch: foreign Version: 113.118 Description: No-install EOF
Visão geral do cluster
ceph-osd - é responsável por armazenar dados em disco. Para cada disco, é lançado um serviço de rede que aceita e executa solicitações de leitura ou gravação em objetos. Duas partições são criadas no disco. Um deles contém informações sobre o cluster, número do disco e chaves do cluster. Essas informações de 1 KB são criadas uma vez ao adicionar um disco e nunca foram alteradas. A segunda partição não possui sistema de arquivos e armazena dados binários CEPH. A instalação automática nas versões anteriores criava uma partição xfs de 100 MB para informações de serviço. Converti o disco para MBR e aloquei apenas 16 MB - o serviço não reclama. Acho que o xfs poderia ser substituído pelo ext sem problemas. Esta partição é montada em /var/lib/…, onde o serviço lê informações sobre o OSD e também encontra uma referência ao dispositivo de bloco onde os dados binários estão armazenados. Teoricamente, você pode colocar imediatamente arquivos auxiliares em /var/lib/… e alocar todo o disco para dados. Ao criar um OSD via ceph-deploy, uma regra é criada automaticamente para montar a partição em /var/lib/…, e o usuário ceph também recebe direitos para ler o dispositivo de bloco desejado. Se você instalar manualmente, deverá fazer isso sozinho; a documentação não diz isso. Também é aconselhável especificar o parâmetro de destino da memória osd para que haja memória física suficiente.
ceph-mds. Em um nível inferior, CEPH é armazenamento de objetos. A capacidade de bloquear o armazenamento se resume a armazenar cada bloco de 4 MB como um objeto. O armazenamento de arquivos funciona com o mesmo princípio. Dois pools são criados: um para metadados e outro para dados. Eles são combinados em um sistema de arquivos. Neste momento é criado algum tipo de registro, portanto se você deletar o sistema de arquivos, mas manter os dois pools, não será possível restaurá-lo. Existe um procedimento para extrair arquivos por blocos, não testei. O serviço ceph-mds é responsável pelo acesso ao sistema de arquivos. Cada sistema de arquivos requer uma instância separada do serviço. Existe uma opção “index”, que permite criar a aparência de vários sistemas de arquivos em um - também não testada.
Ceph-mon – Este serviço armazena um mapa do cluster. Inclui informações sobre todos os OSDs, um algoritmo para distribuição de PGs em OSDs e, o mais importante, informações sobre todos os objetos (os detalhes deste mecanismo não são claros para mim: existe um diretório /var/lib/ceph/mon/…/ store.db, ele contém um arquivo grande de 26 MB e, em um cluster de 105 mil objetos, tem pouco mais de 256 bytes por objeto - acho que o monitor armazena uma lista de todos os objetos e os PGs nos quais eles estão localizados). Danos a este diretório resultam na perda de todos os dados do cluster. Conseqüentemente, concluiu-se que o CRUSH mostra como os PGs estão localizados no OSD e como os objetos estão localizados nos PGs - eles são armazenados centralmente no banco de dados, por mais que os desenvolvedores evitem essa palavra. Como resultado, em primeiro lugar, não podemos instalar o sistema em um pen drive em modo RO, pois o banco de dados está em constante gravação, é necessário um disco adicional para estes (pouco mais de 1 GB), em segundo lugar, é necessário ter um copie em tempo real esta base. Se houver vários monitores, a tolerância a falhas é garantida automaticamente, mas no nosso caso há apenas um monitor, no máximo dois. Existe um procedimento teórico para restaurar um monitor baseado em dados OSD, recorri a ele três vezes por motivos diversos, e três vezes não houve mensagens de erro, assim como nenhum dado. Infelizmente, esse mecanismo não funciona. Ou operamos uma partição miniatura no OSD e montamos um RAID para armazenar o banco de dados, o que certamente afetará muito mal o desempenho, ou alocamos pelo menos duas mídias físicas confiáveis, de preferência USB, para não ocupar portas.
rados-gw - exporta armazenamento de objetos via protocolo S3 e similares. Cria muitos pools, não está claro o porquê. Não experimentei muito.
ceph-mgr – Ao instalar este serviço, vários módulos são lançados. Um deles é a escala automática que não pode ser desativada. Ele se esforça para manter a quantidade correta de PG/OSD. Se quiser controlar a proporção manualmente, você pode desabilitar o escalonamento para cada pool, mas neste caso o módulo trava com uma divisão por 0 e o status do cluster se torna ERRO. O módulo é escrito em Python e se você comentar a linha necessária nele, isso o levará à desativação. Com preguiça de lembrar os detalhes.
Lista de fontes usadas:
Listagens de scripts:
Instalando o sistema via 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 << EOF > /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 << EOF >> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers <[email protected]>
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 <[email protected]>
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 6Crie um 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 << EOF > /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 = 2147483648
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@rbd1Adicionando 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 /dev/sd?2
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-osd@$osdnum
systemctl start ceph-osd@$osdnumResumo
A principal vantagem de marketing do CEPH é o CRUSH - um algoritmo para calcular a localização dos dados. Os monitores distribuem esse algoritmo aos clientes, após os quais os clientes solicitam diretamente o nó desejado e o OSD desejado. CRUSH garante nenhuma centralização. É um arquivo pequeno que você pode até imprimir e pendurar na parede. A prática tem mostrado que CRUSH não é um mapa exaustivo. Se você destruir e recriar os monitores, mantendo todos os OSD e CRUSH, isso não será suficiente para restaurar o cluster. A partir disso conclui-se que cada monitor armazena alguns metadados sobre todo o cluster. A pequena quantidade desses metadados não impõe restrições ao tamanho do cluster, mas exige a garantia de sua segurança, o que elimina a economia de disco com a instalação do sistema em um pen drive e exclui clusters com menos de três nós. A política agressiva do desenvolvedor em relação aos recursos opcionais. Longe do minimalismo. A documentação está no nível de “obrigado pelo que temos, mas é muito, muito escasso”. A capacidade de interagir com serviços de baixo nível é fornecida, mas a documentação aborda esse tópico muito superficialmente, então é mais provável que seja um não do que um sim. Praticamente não há chance de recuperar dados de uma situação de emergência.
Opções para ações futuras: abandonar o CEPH e usar o banal btrfs multi-disco (ou xfs, zfs), descobrir novas informações sobre o CEPH, que lhe permitirão operá-lo nas condições especificadas, tentar escrever seu próprio armazenamento como um avançado treinamento.
Fonte: habr.com