🥇 Armazenamento LINSTOR e sua integração com OpenNebula

Recentemente, a equipe da LINBIT apresentou sua nova solução SDS — Linstor. Trata-se de um armazenamento completamente livre, baseado em tecnologias testadas: DRBD, LVM, ZFS. O Linstor combina simplicidade com uma arquitetura bem elaborada, permitindo alcançar resultados estáveis e expressivos.

Hoje, gostaria de falar sobre ele com mais detalhes e mostrar como é simples integrá-lo ao OpenNebula usando o linstor_un — um novo driver que desenvolvi especialmente para este fim.

O Linstor em conjunto com o OpenNebula permite construir uma nuvem rápida e confiável, que pode ser implantada sem problemas em sua própria infraestrutura.

Arquitetura Linstor

O Linstor não é um sistema de arquivos nem um armazenamento em bloco por si só, é um orquestrador que fornece uma camada de abstração, permitindo automatizar a criação de volumes no LVM ou ZFS e replicá-los usando o DRBD9.

Quebrando estereótipos

Mas espere, DRBD? — Por que automatizá-lo e como isso pode funcionar?

Vamos recordar o passado, quando o DRBD8 era amplamente popular. Seu uso padrão envolvia a criação de um grande dispositivo de bloco e sua divisão em muitos pequenos pedaços, com o mesmo LVM. Uma espécie de RAID-1 do mdadm, porém com replicação pela rede.

Esse approach não é isento de desvantagens, e por isso, com a chegada do DRBD9, os princípios de construção do armazenamento mudaram, agora um dispositivo DRBD separado é criado para cada máquina virtual.

A abordagem com dispositivos de bloco independentes permite uma melhor utilização do espaço no cluster, além de adicionar uma série de possibilidades adicionais. Por exemplo, para cada um desses dispositivos, podemos definir o número de réplicas, sua localização e configurações individuais. Elas são fáceis de criar/remover, tirar snapshots, alterar o tamanho, habilitar criptografia e muito mais. Vale a pena notar que o DRBD9 também suporta quórum, o que ajuda a evitar situações de split-brain.

Recursos e backends

Ao criar um novo dispositivo de bloco, o Linstor aloca o número necessário de réplicas em diferentes nós no cluster. Cada uma dessas réplicas será chamada de recurso DRBD.

Os recursos vêm em dois tipos:

Recurso de Dados — são um dispositivo DRBD localizado em um nó em um pool LVM ou ZFS.
Atualmente, há suporte para vários backends e seu número está em crescimento constante. Há suporte para LVM, ThinLVM e ZFS. Os dois últimos permitem a criação e uso de snapshots.
Recurso sem disco — é um dispositivo DRBD localizado em um nó sem backend, mas que permite ser tratado como um dispositivo de bloco comum; todas as operações de leitura/escrita serão redirecionadas para os recursos de dados. O análogo mais próximo aos recursos sem disco é um LUN iSCSI.

Cada recurso DRBD pode ter até 8 réplicas, e apenas uma delas pode estar ativa por padrão — Primária, todas as outras serão Secundárias e seu uso será impossível enquanto houver pelo menos uma Primária, ou seja, elas apenas irão replicar dados entre si.

Ao montar um dispositivo DRBD no sistema, ele automaticamente se torna Primária, assim até mesmo o recurso sem disco, na terminologia DRBD, pode ser Primário.

Então, para que serve o Linstor?

Ao confiar todas as tarefas intensivas em recursos ao núcleo, o Linstor é essencialmente um aplicativo Java comum que facilita a automação da criação de recursos DRBD.
Cada recurso criado por ele será um cluster DRBD independente, que opera de forma autônoma, independentemente do estado do control-plane e dos outros recursos DRBD.

O Linstor consiste em apenas dois componentes:

Linstor-controller — O controlador principal, que fornece uma API para criação e gerenciamento de recursos. Ele também se comunica com os satélites, verificando o espaço livre neles e enviando tarefas para criar e excluir novos recursos. É executado em uma única instância e utiliza um banco de dados que pode ser interno (H2) ou externo (PostgreSQL, MySQL, MariaDB)
Linstor-satellite — Instalado em todos os nós de armazenamento e fornece ao controlador informações sobre o espaço livre, além de executar tarefas recebidas do controlador para criar e excluir novos volumes e dispositivos DRBD sobre eles.

O Linstor opera com os seguintes conceitos-chave:

Nó — servidor físico onde os recursos DRBD serão criados e utilizados.
Storage Pool — pool LVM ou ZFS criado em um nó onde os recursos DRBD serão hospedados. Também é possível ter um pool sem disco — este é um pool onde serão alocados apenas recursos sem disco.
Definição de Recurso — Definição do recurso, que é essencialmente um protótipo que descreve o nome e todas as suas propriedades.
Definição de Volume — Definição de volume. Cada recurso pode consistir em vários volumes, e cada volume deve ter um tamanho.
Recurso — Instância criada de um dispositivo de bloco, cada recurso deve ser alocado em um determinado nó e em algum pool de armazenamento.

Instalação do Linstor

Recomendo usar o Ubuntu como sistema, pois existe um PPA pronto:

add-apt-repository ppa:linbit/linbit-drbd9-stack
apt-get update

Ou Debian, onde o Linstor pode ser instalado do repositório oficial para Proxmox:

wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add -
PVERS=5 && echo "deb http://packages.linbit.com/proxmox/ proxmox-$PVERS drbd-9.0" > 
/etc/apt/sources.list.d/linbit.list
apt-get update

Controlador

Aqui é bem simples:

apt-get install linstor-controller linstor-client
systemctl enable linstor-controller
systemctl start linstor-controller

Nódulos de armazenamento

Atualmente, o kernel Linux vem com o módulo de kernel in-tree DRBD8, infelizmente, não é adequado para nós e precisamos instalar DRBD9:

apt-get install drbd-dkms

Como mostra a prática, a maioria das dificuldades ocorre exatamente porque o módulo DRBD8 está carregado no sistema, e não o DRBD9. Felizmente, isso pode ser verificado facilmente executando:

modprobe drbd
cat /proc/drbd

Se você vir version: 9 — significa que está tudo certo, se version: 8 — significa que algo deu errado e você precisará tomar ações adicionais para descobrir as causas.

Agora vamos instalar linstor-satellite e drbd-utils:

apt-get install linstor-satellite drbd-utils
systemctl enable linstor-satellite
systemctl start linstor-satellite

Criação de cluster

Pools de armazenamento e nós

Como backend, iremos usar ThinLVM, pois é o mais simples e suporta snapshots.
Instale lvm2, caso ainda não tenha feito isso, vamos criar um pool ThinLVM em todos os nossos nódulos de armazenamento:

sudo vgcreate drbdpool /dev/sdb
sudo lvcreate -L 800G -T drbdpool/thinpool

Todas as ações seguintes podem ser realizadas diretamente no controlador:

Vamos adicionar nossos nós:

linstor node create node1 127.0.0.11
linstor node create node2 127.0.0.12
linstor node create node3 127.0.0.13

Vamos criar pools de armazenamento:

linstor storage-pool create lvmthin node1 data drbdpool/thinpool
linstor storage-pool create lvmthin node2 data drbdpool/thinpool
linstor storage-pool create lvmthin node3 data drbdpool/thinpool

Agora vamos verificar os pools criados:

linstor storage-pool list

Se tudo foi feito corretamente, devemos ver algo como:

+-------------------------------------------------------------------------------------------------------+
| StoragePool | Node  | Driver   | PoolName          | FreeCapacity | TotalCapacity | SupportsSnapshots |
|-------------------------------------------------------------------------------------------------------|
| data        | node1 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | true              |
| data        | node2 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | true              |
| data        | node3 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | true              |
+-------------------------------------------------------------------------------------------------------+

Recursos DRBD

Agora vamos tentar criar nosso novo recurso DRBD:

linstor resource-definition create myres
linstor volume-definition create myres 1G
linstor resource create myres --auto-place 2

Vamos verificar os recursos criados:

linstor resource list

+------------------------------------------------------------------------------------------------------+
| Node  | Resource | StoragePool | VolumeNr | MinorNr | DeviceName    | Allocated  | InUse  |    State |
|------------------------------------------------------------------------------------------------------|
| node1 | myres    | data        | 0        | 1084    | /dev/drbd1084 | 52 KiB     | Unused | UpToDate |
| node2 | myres    | data        | 0        | 1084    | /dev/drbd1084 | 52 KiB     | Unused | UpToDate |
+------------------------------------------------------------------------------------------------------+

Ótimo! — vemos que o recurso foi criado nos dois primeiros nós, também podemos tentar criar um recurso sem disco no terceiro:

linstor resource create --diskless node3 myres

Nos nós você sempre encontrará este dispositivo como /dev/drbd1084 ou /dev/drbd/by-res/myres/0

É assim que o Linstor funciona, você pode obter mais informações de documentação oficial.

Agora eu vou falar sobre como integrá-lo com o OpenNebula

Configuração do OpenNebula

Não vou me aprofundar muito no processo de configuração do OpenNebula, pois todos os passos estão detalhadamente descritos em documentação oficial, que recomendo que você consulte, vou falar apenas sobre a integração do OpenNebula com o Linstor.

linstor_un

Para resolver essa tarefa, escrevi meu próprio driver — linstor_un, atualmente ele está disponível como um plugin e deve ser instalado separadamente.

Toda a instalação é realizada nos nós frontend do OpenNebula e não requer ações adicionais nos nós de computação.

Primeiro precisamos garantir que temos jq e linstor-client:

apt-get install jq linstor-client

Time linstor node list deve listar os nós. Todos os nós de computação do OpenNebula devem ser adicionados ao cluster Linstor.

Vamos baixar e instalar o plugin:

curl -L https://github.com/OpenNebula/addon-linstor_un/archive/master.tar.gz | tar -xzvf - -C /tmp

mv /tmp/addon-linstor_un-master/vmm/kvm/* /var/lib/one/remotes/vmm/kvm/

mkdir -p /var/lib/one/remotes/etc/datastore/linstor_un
mv /tmp/addon-linstor_un-master/datastore/linstor_un/linstor_un.conf /var/lib/one/remotes/etc/datastore/linstor_un/linstor_un.conf

mv /tmp/addon-linstor_un-master/datastore/linstor_un /var/lib/one/remotes/datastore/linstor_un
mv /tmp/addon-linstor_un-master/tm/linstor_un /var/lib/one/remotes/tm/linstor_un

rm -rf /tmp/addon-linstor_un-master

Agora precisamos adicioná-lo ao config do OpenNebula, para isso, execute os passos simples descritos aqui.

Depois disso, reiniciaremos o OpenNebula:

systemctl restart opennebula

E adicionaremos nossos datastores, o sistema:

cat > system-ds.conf <<EOT
NAME="linstor-system"
TYPE="SYSTEM_DS"
STORAGE_POOL="data"
AUTO_PLACE="2"
CLONE_MODE="snapshot"
CHECKPOINT_AUTO_PLACE="1"
BRIDGE_LIST="node1 node2 node3"
TM_MAD="linstor_un"
EOT

onedatastore create system-ds.conf

E o armazenamento de imagens:

cat > images-ds.conf <<EOT
NAME="linstor-images"
TYPE="IMAGE_DS"
STORAGE_POOL="data"
AUTO_PLACE="2"
BRIDGE_LIST="node1 node2 node3"
DISK_TYPE="BLOCK"
DS_MAD="linstor_un"
TM_MAD="linstor_un"
EOT

onedatastore create images-ds.conf

Parâmetro AUTO_PLACE indica o número de réplicas de dados que será criado para cada nova imagem no OpenNebula.
Parâmetro CLONE_MODE indica como as imagens serão clonadas ao criar novas máquinas virtuais, snapshot — criará um snapshot da imagem e a partir do snapshot implantará a máquina virtual, copy — fará uma cópia completa da imagem para cada máquina virtual.
Em BRIDGE_LIST é recomendável listar todas as nodos que serão usadas para executar operações de clonagem de imagens.

A lista completa dos parâmetros suportados é apresentada em README do projeto.

Com isso, a configuração está concluída, agora podemos carregar algum appliance do oficial OpenNebula Marketplace e criar máquinas virtuais a partir dele.

Link para o projeto:
https://github.com/OpenNebula/addon-linstor_un

Fonte: habr.com