Nota: Os comentaristas apontaram 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 de K discos de tamanho arbitrário e armazena dados neles, duplicando cada peça (4 MB por padrão) um número especificado N vezes.
Considere o caso mais simples com dois discos idênticos. Neles, você pode montar um RAID 1 ou um cluster com N = 2 - o resultado será o mesmo. Se houver três discos e eles tiverem tamanhos diferentes, será fácil montar um cluster com N = 2: alguns dos dados estarão nos discos 1 e 2, outros nos discos 1 e 3 e outros nos 2 e 3, enquanto o RAID não (você pode coletar RAID, mas seria uma perversão). Se houver ainda mais discos, é possível criar o RAID 5, o CEPH possui um código-analógico-apagável, que contradiz os conceitos iniciais dos desenvolvedores e, portanto, não é considerado. O RAID 5 pressupõe que você tenha um pequeno número de discos e que todos estejam em boas condições. Se um falhar, o restante deverá aguentar até que o disco seja substituído e os dados sejam restaurados para ele. O CEPH, para N> = 3, incentiva o uso de drives antigos, em particular,se você mantiver vários discos bons para armazenar uma cópia dos dados e as duas ou três cópias restantes forem armazenadas em um grande número de discos antigos, as informações estarão seguras, desde que os novos discos estejam ativos - não há problemas e, se um deles quebrar, ocorrerá uma falha simultânea. três discos com uma vida útil de mais de cinco anos, de preferência de diferentes servidores - um evento extremamente improvável.
Há uma sutileza na distribuição de cópias. Por padrão, supõe-se que os dados sejam divididos em mais (~ 100 por disco) grupos de distribuição PG, cada um dos quais duplicado em alguns discos. Suponha que K = 6, N = 2, se dois discos falharem, os dados serão perdidos, pois, de acordo com a teoria das probabilidades, existe pelo menos um PG que estará localizado nesses dois discos. E a perda de um grupo torna todos os dados no pool inacessíveis. Se os discos forem divididos em três pares e permitirem que apenas os dados sejam armazenados em discos dentro de um par, essa distribuição também será resistente à falha de qualquer disco, mas se dois falharem, a probabilidade de perda de dados não será 100%, mas apenas 3/15, e mesmo em caso de falha três discos - apenas 12/20. Portanto, a entropia na distribuição de dados não contribui para a tolerância a falhas. Observe tambémque para um servidor de arquivos, a RAM livre aumenta significativamente a velocidade de resposta. Quanto mais memória em cada nó e mais memória em todos os nós, mais rápido será. Essa é, sem dúvida, a vantagem de um cluster sobre um único servidor e, além disso, um NAS de hardware, onde uma quantidade muito pequena de memória é incorporada.
Daqui resulta que o CEPH é uma boa maneira, com um investimento mínimo de equipamentos desatualizados, para criar um sistema de armazenamento confiável para dezenas de TB com capacidade de escalar (aqui, é claro, isso exigirá custos, mas pequenos em comparação com os sistemas de armazenamento comercial).
Implementação de cluster
Para o experimento, vamos usar um computador Intel DQ57TM + Intel Core i3 540 desativado + 16 GB de RAM. Organizamos quatro discos de 2 TB à semelhança do RAID10. Após um teste bem-sucedido, adicionamos o segundo nó e o mesmo número de discos.
Instale o Linux. A distribuição requer personalização e estabilidade. O Debian e o Suse atendem aos requisitos. O Suse possui um instalador mais flexível para desativar qualquer pacote; infelizmente, não consegui descobrir quais podem ser descartadas sem danificar o sistema. Instalamos o Debian via debootstrap buster. A opção min-base instala um sistema não operacional no qual não há drivers suficientes. A diferença de tamanho em comparação com a versão completa não é tão grande a ponto de incomodar. Como o trabalho é realizado em uma máquina física, quero fazer instantâneos, como em máquinas virtuais. Esta opção é fornecida pelo LVM ou pelo btrfs (xfs ou zfs - a diferença não é grande). Os instantâneos do LVM não são um ponto forte. Nós colocamos btrfs. E o carregador de inicialização está no MBR. Não faz sentido obstruir um disco de 50 MB com uma partição FAT,quando você pode colocá-lo em uma área de 1 MB da tabela de partição e alocar todo o espaço para o sistema. Usado no disco 700 MB. Quantas instalações básicas do SUSE não se lembram, aparentemente, de 1,1 ou 1,4 GB.
Instalando o CEPH. Ignore a versão 12 no repositório debian e faça o link diretamente do site 15.2.3. Siga as instruções na seção "Instalar o CEPH manualmente" com as seguintes reservas:
- Antes de conectar o repositório, você deve instalar os certificados gnupg wget ca
- Após conectar o repositório, mas antes de instalar o cluster, a instalação do pacote é omitida: apt -y --no-install-recomenda instalar ceph-common ceph-mon ceph-mon ceph-osd ceph-mds ceph-mgr
- No momento da instalação, o ceph-osd por razões (já compreensíveis) tentará instalar o lvm2. Não há necessidade urgente disso. Se você tiver problemas para instalar um pacote, poderá abandoná-lo removendo a dependência em / var / lib / dpkg / status para ceph-osd.
Um patch menos humano foi usado ao escrever o artigo:cat << EOF >> /var/lib/dpkg/status Package: lvm2 Status: install ok installed Priority: important Section: admin Installed-Size: 0 Maintainer: Debian Adduser Developers <adduser@packages.debian.org> Architecture: all Multi-Arch: foreign Version: 113.118 Description: No-install EOF
Visão geral do cluster
ceph-osd - responsável por armazenar dados no disco. Um serviço de rede é iniciado para cada disco, que aceita e executa solicitações de leitura ou gravação em objetos. Este artigo discute o armazenamento em bluestore como o nível mais baixo. Os arquivos de serviço são criados no diretório de serviço que descreve o ID do cluster, armazenamento, seu tipo etc., bem como o arquivo de bloco necessário - esses arquivos não são alterados. Se o arquivo for físico, o osd criará nele um sistema de arquivos e armazenará dados. Se o arquivo for um link, os dados estarão no dispositivo para o qual o link aponta. Além do dispositivo principal, block.db - metadata (RocksDB) e block.wal - um log (registro write-ahead do RocksDB) também podem ser indicados. Se nenhum dispositivo adicional for especificado, os metadados e o log serão armazenados no dispositivo principal.É muito importante monitorar a disponibilidade de espaço livre para o RocksDB, caso contrário, o OSD não será iniciado!
Com a criação padrão do osd em versões mais antigas, o disco é dividido em duas partições: a primeira é de 100 MB xfs, montada em / var / lib / ... e contém informações de serviço, a segunda é fornecida para o armazenamento principal. A nova versão usa lvm.
Teoricamente, você não pode montar uma partição em miniatura, mas colocar os arquivos em / var / lib / ..., duplicá-los em todos os nós e alocar o disco inteiro para dados, sem criar um cabeçalho GPT ou LVM. Ao adicionar OSDs manualmente, você precisa garantir que o usuário ceph tenha acesso de gravação aos dispositivos de bloco de dados, e o diretório de dados do serviço seja montado automaticamente em / var / lib ... se você decidir colocá-los lá. 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 baixo, o CEPH é o armazenamento de objetos. O armazenamento em bloco é reduzido para armazenar cada bloco de 4 MB como um objeto. O armazenamento de arquivos funciona da mesma maneira. Dois conjuntos são criados: um para metadados e outro para dados. Eles são combinados em um sistema de arquivos. Nesse momento, algum tipo de registro é criado; portanto, se você excluir o sistema de arquivos, mas manter os dois conjuntos, não poderá restaurá-lo. Existe um procedimento para extrair arquivos em blocos, eu não testei. O serviço ceph-mds é responsável por acessar o sistema de arquivos. Cada sistema de arquivos requer uma instância separada do serviço. Existe uma opção "classificação", que permite criar uma aparência de vários sistemas de arquivos em um - também não testado.
ceph-mon - Este serviço armazena o mapa de cluster. Inclui informações sobre todos os OSDs, o algoritmo de distribuição PG no OSD e, 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/store.db existe um arquivo grande - 26MB e, em um cluster de 105K objetos, resulta um pouco mais de 256 bytes por objeto - acho que o monitor mantém uma lista de todos os objetos e o PG em que estão localizados). Danos neste diretório resultam na perda de todos os dados no cluster. A partir disso, concluiu-se que o CRUSH mostra como os PGs estão localizados no OSD e como os objetos estão localizados no PG - no banco de dados (a conclusão acabou incorreta, o que exatamente está contido nela requer esclarecimentos). Como conseqüência, em primeiro lugar, não podemos instalar o sistema em uma unidade flash USB no modo RO, pois o banco de dados está sendo gravado constantemente,É necessário um disco adicional para esses dados (pouco mais de 1 GB) e, em segundo lugar, é necessário ter uma cópia desse banco de dados em tempo real. Se houver vários monitores, a tolerância a falhas será fornecida às custas deles, mas se houver apenas um monitor, no máximo dois, será necessário garantir a proteção dos dados. Existe um procedimento teórico para recuperar um monitor com base em dados OSD; no momento em que ele foi restaurado no nível do objeto, o sistema de arquivos não foi restaurado no momento. Até agora, não se pode confiar neste mecanismo.no momento em que foi restaurado no nível do objeto, o sistema de arquivos não foi restaurado no momento atual. Até agora, não se pode confiar neste mecanismo.no momento, ele acabou sendo restaurado no nível do objeto, o sistema de arquivos no momento não pôde ser restaurado. Até agora, não se pode confiar neste mecanismo.
rados-gw - Exporta armazenamento de objetos pelo S3 e similares. Cria muitas piscinas, não está claro o porquê. Não experimentou muito.
ceph-mgr - Ao instalar este serviço, vários módulos são iniciados. Uma delas é a escala automática que não está desativada. Ele se esforça para manter a quantidade certa de PG / OSD. Se você deseja controlar a proporção manualmente, pode proibir o dimensionamento para cada pool, mas nesse caso, o módulo cai dividindo por 0 e o status do cluster se torna ERROR. O módulo é escrito em python e, se você comentar a linha necessária, isso levará à sua desconexão. Detalhes com preguiça de lembrar.
Referências:
Instalando o CEPH
Recuperando de falhas completas do monitor
Artigo sobre BlueStore no Ceph
Descrição da arquitetura ceph. Sábio A. Weil
Listagens de scripts:
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 <adduser@packages.debian.org>
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 <adduser@packages.debian.org>
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 6apt -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@rbd1
OSD ()
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@$osdnumA principal vantagem de marketing do CEPH é o CRUSH, um algoritmo de cálculo de localização de dados. Os monitores distribuem esse algoritmo aos clientes, após o qual os clientes solicitam diretamente o nó necessário e o OSD necessário. CRUSH garante que não há centralização. É um arquivo pequeno que você pode pelo menos imprimir e pendurar na parede. A prática mostrou que CRUSH não é um mapa exaustivo. Destruir e recriar monitores, mantendo todos os OSDs e CRUSHs, não é suficiente para restaurar o cluster. A partir disso, concluiu-se que cada monitor armazena alguns metadados sobre todo o cluster. A quantidade insignificante desses metadados não impõe restrições ao tamanho do cluster, mas exige garantia de segurança, o que elimina a economia de disco ao instalar o sistema em uma unidade flash USB e exclui clusters com menos de três nós.Política agressiva de desenvolvedor em relação aos recursos opcionais. Longe do minimalismo. A documentação no nível: "pelo que é - já obrigada, mas muito, muito escassa". A possibilidade de interagir com os serviços em um nível baixo é fornecida, mas a documentação está superficialmente relacionada a esse tópico, portanto, em vez de sim. Praticamente não há chance de recuperar dados em uma situação de emergência (graças às explicações da comunidade, a chance ainda permanece).Quase não há chance de recuperação de dados em uma situação de emergência (graças às explicações da comunidade, ainda há uma chance).Quase não há chance de recuperação de dados em uma situação de emergência (graças às explicações da comunidade, ainda há uma chance).
Opções para ações adicionais: abandone o CEPH e use o banal multi-disk btrfs (ou xfs, zfs), descubra novas informações sobre o CEPH, que permitirão que ele seja usado nessas condições, tente escrever seu próprio repositório como um treinamento adicional.