Em um artigo anterior, examinei a possibilidade de criar um servidor NFS tolerante a falhas usando DRBD e Proxmox. Acabou muito bem, mas não vamos descansar sobre os louros e agora vamos tentar "espremer todos os sucos" do nosso armazenamento.
Neste artigo, mostrarei como criar um destino iSCSI tolerante a falhas dessa maneira, que usaremos o LVM para cortar em pedaços pequenos e usá-lo em máquinas virtuais.
É essa abordagem que reduz a carga e aumenta a velocidade do acesso aos dados várias vezes; isso é especialmente benéfico quando o acesso competitivo aos dados não é necessário, por exemplo, no caso em que você precisa organizar o armazenamento para máquinas virtuais.
Algumas palavras sobre DRBD
DRBD é uma solução bastante simples e madura, o código da oitava versão é adotado como parte do kernel do Linux. De fato, representa um espelho de rede RAID1. A nona versão introduziu suporte para quorum e replicação com mais de dois nós.
De fato, ele permite combinar dispositivos de bloco em vários nós físicos em uma rede compartilhada comum.
Usando o DRBD, você pode obter configurações muito interessantes. Hoje falaremos sobre iSCSI e LVM.
Você pode aprender mais sobre isso lendo meu artigo anterior , onde descrevi essa solução em detalhes.
Algumas palavras sobre o iSCSI
O iSCSI é um protocolo de entrega de dispositivo de bloco em uma rede.
Ao contrário do NBD, ele suporta autorização, elimina falhas de rede sem problemas e suporta muitas outras funções úteis e, o mais importante, mostra um desempenho muito bom.
Há um grande número de implementações, algumas delas também incluídas no kernel e não exigem dificuldades especiais para sua configuração e conexão.
Algumas palavras sobre o LVM
Vale ressaltar que o LINBIT tem sua própria solução para o Proxmox, ele deve funcionar imediatamente e permitir obter um resultado semelhante, mas neste artigo eu não gostaria de focar apenas no Proxmox e descrever uma solução mais universal que seja adequada para Proxmox e qualquer outra coisa, neste exemplo, o proxmox é usado apenas como um meio de orquestração de contêiner; na verdade, você pode substituí-lo por outra solução, por exemplo, iniciar contêineres com um destino no Kubernetes.
Quanto ao Proxmox especificamente, ele funciona bem com LUN e LVM compartilhados, usando apenas seus próprios drivers padrão.
As vantagens do LVM incluem o fato de que seu uso não é algo revolucionário, novo e insuficiente, mas, pelo contrário, mostra estabilidade a seco, o que geralmente é exigido no armazenamento. Vale ressaltar que o LVM é usado ativamente em outros ambientes, por exemplo, no OpenNebula ou no Kubernetes, e é bem suportado por lá.
Assim, você receberá armazenamento universal que pode ser usado em sistemas diferentes (não apenas no proxmox), usando apenas drivers prontos, sem necessidade especial de modificá-lo com um arquivo.
Infelizmente, ao escolher uma solução para armazenamento, você sempre precisa fazer alguns compromissos. Portanto, aqui, esta solução não oferece a mesma flexibilidade que, por exemplo, o Ceph.
O tamanho do disco virtual é limitado pelo tamanho do grupo LVM, e a área marcada para um disco virtual específico será necessariamente realocada - isso melhora muito a velocidade do acesso aos dados, mas não permite o Thin-Provisioning (quando o disco virtual ocupa menos espaço do que realmente é). Vale ressaltar que o desempenho do LVM diminui bastante ao usar instantâneos e, portanto, a possibilidade de seu uso gratuito é frequentemente eliminada.
Sim, o LVM suporta pools Thin-Provision que não têm essa desvantagem, mas infelizmente seu uso é possível apenas no contexto de um único nó e não há como compartilhar um pool Thin-Provision em vários nós em um cluster.
Mas, apesar dessas deficiências, devido à sua simplicidade, o LVM ainda não permite que os concorrentes o contornem e o empurram completamente para fora do campo de batalha.
Com uma sobrecarga bastante pequena, o LVM ainda fornece uma solução muito rápida, estável e bastante flexível.
Esquema geral
- Nós temos três nós
- Cada nó possui um dispositivo drbd distribuído.
- Na parte superior do dispositivo drbd, um contêiner LXC com um destino iSCSI é iniciado.
- O destino está conectado aos três nós.
- Um grupo LVM foi criado no destino conectado.
- Se necessário, o contêiner LXC pode ser movido para outro nó, junto com o destino iSCSI
Personalização
Descobrimos a idéia agora, vamos seguir para a implementação.
Por padrão , a oitava versão do drbd é fornecida com o kernel Linux , infelizmente não nos convém e precisamos instalar a nona versão do módulo.
Conecte o repositório LINBIT e instale tudo o que você precisa:
wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add - echo "deb http://packages.linbit.com/proxmox/ proxmox-5 drbd-9.0" \ > /etc/apt/sources.list.d/linbit.list apt-get update && apt-get -y install pve-headers drbd-dkms drbd-utils drbdtop
pve-headers - pve-headers kernel necessários para construir o módulodrbd-dkms - módulo do kernel no formato DKMSdrbd-utils - utilitários básicos de gerenciamento DRBDdrbdtop é uma ferramenta interativa como top apenas para DRBD
Depois de instalar o módulo, verifique se está tudo bem com ele:
Se você vir a oitava versão na saída do comando, algo deu errado e o módulo do kernel na árvore é carregado. Verifique o dkms status descobrir qual é o motivo.
Cada nó que temos terá o mesmo dispositivo drbd rodando sobre partições regulares. Primeiro, precisamos preparar esta seção para o drbd em cada nó.
Essa partição pode ser qualquer dispositivo de bloco , pode ser lvm, zvol, uma partição de disco ou o disco inteiro. Neste artigo, usarei um disco nvme separado com uma partição sob drbd: /dev/nvme1n1p1
Vale a pena notar que os nomes dos dispositivos tendem a mudar algumas vezes; portanto, é melhor adotar imediatamente o hábito de usar o link simbólico constante para o dispositivo.
Você pode encontrar um link simbólico para /dev/nvme1n1p1 desta maneira:
Descrevemos nosso recurso nos três nós:
É aconselhável usar uma rede separada para sincronização drbd.
Agora crie os metadados para drbd e execute-o:
Repita estas etapas nos três nós e verifique o status:
Agora, nosso disco inconsistente está nos três nós, isso ocorre porque o drbd não sabe qual disco deve ser tomado como original. Devemos marcar um deles como Primário para que seu estado seja sincronizado com os outros nós:
drbdadm primary --force tgt1 drbdadm secondary tgt1
Imediatamente após isso, a sincronização começará:
Não precisamos esperar que termine e podemos executar outras etapas em paralelo. Eles podem ser executados em qualquer nó , independentemente do estado atual do disco local no DRBD. Todas as solicitações serão redirecionadas automaticamente para o dispositivo com o estado UpToDate .
Não se esqueça de ativar a execução automática do serviço drbd nos nós:
systemctl enable drbd.service
Configurando um Contêiner LXC
Vamos omitir a parte de configuração do cluster Proxmox de três nós, essa parte está bem descrita no wiki oficial
Como eu disse antes, nosso destino iSCSI funcionará em um contêiner LXC . Manteremos o contêiner no dispositivo /dev/drbd100 que acabamos de criar.
Primeiro, precisamos criar um sistema de arquivos nele:
mkfs -t ext4 -O mmp -E mmp_update_interval=5 /dev/drbd100
O Proxmox, por padrão, inclui proteção multimount no nível do sistema de arquivos; em princípio, podemos fazer sem ele, porque Por padrão, o DRBD possui sua própria proteção; ele simplesmente proíbe a segunda Primária do dispositivo, mas o cuidado não nos prejudica.
Agora baixe o modelo do Ubuntu:
# wget http://download.proxmox.com/images/system/ubuntu-16.04-standard_16.04-1_amd64.tar.gz -P /var/lib/vz/template/cache/
E crie nosso contêiner a partir dele:
pct create 101 local:vztmpl/ubuntu-16.04-standard_16.04-1_amd64.tar.gz \ --hostname=tgt1 \ --net0=name=eth0,bridge=vmbr0,gw=192.168.1.1,ip=192.168.1.11/24 \ --rootfs=volume=/dev/drbd100,shared=1
Neste comando, indicamos que o sistema raiz do nosso contêiner estará no dispositivo /dev/drbd100 e adicionamos o parâmetro shared=1 para permitir a migração do contêiner entre os nós.
Se algo der errado, você sempre poderá corrigi-lo através da interface Proxmox ou na /etc/pve/lxc/101.conf contêiner /etc/pve/lxc/101.conf
O Proxmox irá descompactar o modelo e preparar o sistema raiz do contêiner para nós. Depois disso, podemos lançar nosso contêiner:
pct start 101
Configurando um destino iSCSI.
De todo o conjunto de destinos , eu escolhi o istgt , pois ele tem o melhor desempenho e trabalha no espaço do usuário.
Agora vamos fazer login no nosso contêiner:
pct exec 101 bash
Instale atualizações e istgt :
apt-get update apt-get -y upgrade apt-get -y install istgt
Crie um arquivo que forneceremos pela rede:
mkdir -p /data fallocate -l 740G /data/target1.img
Agora precisamos escrever uma configuração para istgt /etc/istgt/istgt.conf :
[Global] Comment "Global section" NodeBase "iqn.2018-07.org.example.tgt1" PidFile /var/run/istgt.pid AuthFile /etc/istgt/auth.conf MediaDirectory /var/istgt LogFacility "local7" Timeout 30 NopInInterval 20 DiscoveryAuthMethod Auto MaxSessions 16 MaxConnections 4 MaxR2T 32 MaxOutstandingR2T 16 DefaultTime2Wait 2 DefaultTime2Retain 60 FirstBurstLength 262144 MaxBurstLength 1048576 MaxRecvDataSegmentLength 262144 InitialR2T Yes ImmediateData Yes DataPDUInOrder Yes DataSequenceInOrder Yes ErrorRecoveryLevel 0 [UnitControl] Comment "Internal Logical Unit Controller" AuthMethod CHAP Mutual AuthGroup AuthGroup10000 Portal UC1 127.0.0.1:3261 Netmask 127.0.0.1 [PortalGroup1] Comment "SINGLE PORT TEST" Portal DA1 192.168.1.11:3260 [InitiatorGroup1] Comment "Initiator Group1" InitiatorName "ALL" Netmask 192.168.1.0/24 [LogicalUnit1] Comment "Hard Disk Sample" TargetName disk1 TargetAlias "Data Disk1" Mapping PortalGroup1 InitiatorGroup1 AuthMethod Auto AuthGroup AuthGroup1 UseDigest Auto UnitType Disk LUN0 Storage /data/target1.img Auto
Reinicie o istgt:
systemctl restart istgt
Isso completa a configuração de destino
Configuração de HA
Agora podemos passar para a configuração do gerenciador de alta disponibilidade . Vamos criar um grupo HA separado para o nosso dispositivo:
ha-manager groupadd tgt1 --nodes pve1,pve2,pve3 --nofailback=1 --restricted=1
Nosso recurso funcionará apenas nos nós especificados para este grupo. Adicione nosso contêiner a este grupo:
ha-manager add ct:101 --group=tgt1 --max_relocate=3 --max_restart=3
Recomendações e ajuste
DRBD
Como observei acima, é sempre aconselhável usar uma rede separada para replicação. É altamente recomendável usar adaptadores de rede de 10 gigabit , caso contrário, você terá velocidade de porta.
Se a replicação parecer lenta o suficiente, tente algumas das opções para DRBD . Aqui está a configuração, que na minha opinião é ideal para minha rede 10G :
# cat /etc/drbd.d/global_common.conf global { usage-count yes; udev-always-use-vnr; } common { handlers { } startup { } options { } disk { c-fill-target 10M; c-max-rate 720M; c-plan-ahead 10; c-min-rate 20M; } net { max-buffers 36k; sndbuf-size 1024k; rcvbuf-size 2048k; } }
Você pode obter mais informações sobre cada parâmetro na documentação oficial do DRBD.
Abra o iSCSI
Como não usamos caminhos múltiplos, no nosso caso , é recomendável desativar as verificações periódicas de conexão nos clientes, além de aumentar o tempo limite de espera para recuperação da sessão no /etc/iscsi/iscsid.conf .
node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 node.session.timeo.replacement_timeout = 86400
Use
Proxmox
O destino iSCSI resultante pode ser conectado imediatamente ao Proxmox, sem esquecer de desmarcar Usar LUN diretamente .
Imediatamente depois disso, será possível criar LVM sobre ele, não se esqueça de marcar a caixa compartilhada :
Outros ambientes
Se você planeja usar esta solução em um ambiente diferente, pode ser necessário instalar uma extensão de cluster para o LVM no momento em que houver duas implementações. CLVM e lvmlockd .
A configuração do CLVM não é trivial e requer um gerenciador de cluster em funcionamento.
Onde, como segundo método, o lvmlockd ainda não foi totalmente testado e está apenas começando a aparecer em repositórios estáveis.
Eu recomendo a leitura de um excelente artigo sobre bloqueio no LVM
Ao usar o LVM com Proxmox, a adição de cluster não é necessária , pois o gerenciamento de volume é fornecido pelo próprio proxmox, que atualiza e monitora os metadados do LVM independentemente. O mesmo se aplica ao OpenNebula , como a documentação oficial indica claramente.