Provavelmente, todos os que ficaram pelo menos uma vez intrigados com a busca por armazenamento definido por software de alto desempenho, mais cedo ou mais tarde, ouviram falar do DRBD , ou talvez até tenham lidado com isso.
É verdade que, no auge da popularidade do Ceph e GlusterFS , que funcionam muito bem em princípio e, o mais importante, imediatamente, todos se esqueceram um pouco disso. Além disso, a versão anterior não suportava a replicação para mais de dois nós e, por causa disso, eram frequentemente encontrados problemas com o cérebro dividido , o que claramente não aumentava sua popularidade.
A solução não é realmente nova, mas bastante competitiva. Com custos relativamente baixos para CPU e RAM, o DRBD fornece sincronização realmente rápida e segura no nível do dispositivo de bloco . Durante todo esse tempo, os desenvolvedores do LINBIT - DRBD não param e o refinam constantemente. Começando com a versão DRBD9 , deixa de ser apenas um espelho de rede e se torna algo mais.
Em primeiro lugar, a idéia de criar um único dispositivo de bloco distribuído para vários servidores recuou para o segundo plano e agora o LINBIT está tentando fornecer ferramentas para orquestrar e gerenciar muitos dispositivos drbd em um cluster criado sobre partições LVM e ZFS .
Por exemplo, o DRBD9 suporta até 32 réplicas, RDMA, nós sem disco e novas ferramentas de orquestração permitem o uso de instantâneos, migração online e muito mais.
Apesar do DRBD9 possuir ferramentas de integração com Proxmox , Kubernetes , OpenStack e OpenNebula , no momento elas estão em algum modo de transição, quando novas ferramentas ainda não são suportadas em todos os lugares, e as antigas serão anunciadas como obsoletas muito em breve. Estes são DRBDmanage e Linstor .
Aproveitarei esse momento para não entrar muito nos detalhes de cada um deles, mas examinar com mais detalhes a configuração e os princípios do trabalho com o próprio DRBD9 . Você ainda precisa descobrir isso, apenas porque a configuração tolerante a falhas do controlador Linstor implica em instalá-lo em um desses dispositivos.
Neste artigo, gostaria de falar sobre o DRBD9 e a possibilidade de seu uso no Proxmox sem plug-ins de terceiros.
DRBDmanage e Linstor
Em primeiro lugar, vale a pena mencionar mais uma vez sobre o DRBDmanage , que se integra muito bem ao Proxmox . O LINBIT fornece um plug-in DRBDmanage pronto para o Proxmox que permite usar todas as suas funções diretamente da interface do Proxmox .
Parece realmente incrível, mas infelizmente tem algumas desvantagens.
- Primeiro, os nomes de volumes marcados, o grupo LVM ou o pool ZFS devem ter o nome
drbdpool . - Incapacidade de usar mais de um pool por nó
- Devido às especificidades da solução, o volume do controlador pode estar apenas em um LVM regular e não de outra forma
- Falhas periódicas no dbus , usadas de perto pelo DRBDmanage para interagir com os nós.
Como resultado, o LINBIT decidiu substituir toda a lógica complexa do DRBDmanage por um aplicativo simples que se comunica com os nós usando uma conexão tcp regular e funciona sem nenhuma mágica. Então havia Linstor .
Linstor realmente funciona muito bem. Infelizmente, os desenvolvedores escolheram o java como o idioma principal para escrever o servidor Linstor, mas não deixe que isso o assuste, pois o próprio Linstor se preocupa apenas em distribuir configurações DRBD e fatiar partições LVM / ZFS nos nós.
Ambas as soluções são gratuitas e distribuídas sob a licença GPL3 gratuita .
Você pode ler sobre cada um deles e sobre como configurar o plug-in mencionado para o Proxmox no wiki oficial do Proxmox
Servidor NFS de failover
Infelizmente, no momento da redação deste artigo, o Linstor só tinha integração com o Kubernetes . Mas no final do ano, os drivers são esperados para o resto dos sistemas Proxmox , OpenNebula , OpenStack .
Até agora, porém, não existe uma solução pronta, mas não gostamos da antiga, de uma forma ou de outra. Vamos tentar usar o DRBD9 da maneira antiga para organizar o acesso do NFS a uma partição compartilhada.
No entanto, essa solução também não terá vantagens, porque o servidor NFS permitirá organizar o acesso competitivo ao sistema de arquivos do repositório a partir de vários servidores, sem a necessidade de sistemas de arquivos de cluster complexos com DLM, como OCFS e GFS2.
Nesse caso, você poderá alternar as funções do nó Primário / Secundário simplesmente migrando o contêiner com o servidor NFS na interface Proxmox.
Você também pode armazenar qualquer arquivo dentro deste sistema de arquivos, bem como discos e backups virtuais.
Caso você use o Kubernetes , poderá organizar o acesso ReadWriteMany para os seus PersistentVolumes .
Contêineres Proxmox e LXC
Agora a pergunta é: por que o Proxmox?
Em princípio, para construir esse esquema, poderíamos usar o Kubernetes, bem como o esquema usual, com um gerenciador de cluster. Mas o Proxmox fornece uma interface pronta, muito multifuncional e ao mesmo tempo simples e intuitiva para quase tudo que você precisa. Está pronto para o uso em cluster e suporta o mecanismo de esgrima baseado no softdog. E, ao usar contêineres LXC, permite atingir tempos mínimos mínimos ao alternar.
A solução resultante não terá um único ponto de falha .
De fato, usaremos o Proxmox principalmente como um gerenciador de cluster , onde podemos considerar um contêiner LXC separado como um serviço em execução em um cluster HA clássico, apenas com a diferença de que o contêiner também vem com seu sistema raiz . Ou seja, você não precisa instalar várias instâncias de serviço em cada servidor separadamente; é possível fazer isso apenas uma vez dentro do contêiner.
Se você já trabalhou com o software gerenciador de cluster e fornece HA para aplicativos, entenderá o que quero dizer.
Esquema geral
Nossa solução será semelhante ao esquema de replicação padrão de um banco de dados.
- Nós temos três nós
- Cada nó possui um dispositivo drbd distribuído.
- O dispositivo possui um sistema de arquivos regular ( ext4 )
- Apenas um servidor pode ser um mestre
- O servidor NFS no contêiner LXC é iniciado no assistente.
- Todos os nós acessam o dispositivo estritamente através do NFS.
- Se necessário, o assistente pode passar para outro nó, junto com o servidor NFS
O DRBD9 possui um recurso muito interessante que simplifica bastante tudo:
O dispositivo drbd automaticamente se torna Primário no momento em que é montado em algum nó. Se o dispositivo estiver marcado como Primário , qualquer tentativa de montá-lo em outro nó resultará em um erro de acesso. Isso garante bloqueio e proteção garantida contra acesso simultâneo ao dispositivo.
Por que tudo isso simplifica bastante? Como quando o contêiner é iniciado, o Proxmox monta automaticamente este dispositivo e ele se torna Primário nesse nó. Quando o contêiner para, desmonta-o pelo contrário e o dispositivo se torna Secundário novamente.
Portanto, não precisamos mais nos preocupar com a troca de dispositivos Primário / Secundário , o Proxmox fará isso automaticamente , Hurra!
Configuração DRBD
Bem, descobrimos a idéia. Agora, vamos à 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
Após a instalação do módulo, verificaremos se está tudo em ordem 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 nfs1 drbdadm secondary nfs1
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 servidor NFS 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=nfs1 \ --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
Configure um servidor NFS.
Por padrão, o Proxmox não permite que o servidor NFS seja executado no contêiner, mas existem várias maneiras de habilitá-lo.
Uma delas é apenas adicionar lxc.apparmor.profile: unconfined à /etc/pve/lxc/100.conf do nosso contêiner /etc/pve/lxc/100.conf .
Ou podemos habilitar o NFS para todos os contêineres continuamente, para isso, precisamos atualizar o modelo padrão do LXC em todos os nós, adicionar as seguintes linhas em /etc/apparmor.d/lxc/lxc-default-cgns :
mount fstype=nfs, mount fstype=nfs4, mount fstype=nfsd, mount fstype=rpc_pipefs,
Após as alterações, reinicie o contêiner:
pct shutdown 101 pct start 101
Agora vamos entrar nele:
pct exec 101 bash
Instale atualizações e servidor NFS :
apt-get update apt-get -y upgrade apt-get -y install nfs-kernel-server
Crie uma exportação :
echo '/data *(rw,no_root_squash,no_subtree_check)' >> /etc/exports mkdir /data exportfs -a
Configuração de HA
No momento da escrita, o proxmox HA-manager possui um bug que não permite que o contêiner de HA conclua com êxito seu trabalho, como resultado dos processos de espaço no kernel do servidor nfs que não foram completamente mortos impedem que o dispositivo drbd saia do Secundário . Se você já encontrou essa situação, não entre em pânico e apenas execute killall -9 nfsd no nó em que o contêiner foi iniciado e, em seguida, o dispositivo drbd deverá "liberar" e passará para o secundário .
Para corrigir esse erro, execute os seguintes comandos em todos os nós:
sed -i 's/forceStop => 1,/forceStop => 0,/' /usr/share/perl5/PVE/HA/Resources/PVECT.pm systemctl restart pve-ha-lrm.service
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 nfs1 --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=nfs1 --max_relocate=3 --max_restart=3
Só isso. Simples, certo?
A bola nfs resultante pode ser conectada imediatamente ao Proxmox para armazenar e executar outras máquinas e contêineres virtuais.
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.
Servidor NFS
Para acelerar a operação do servidor NFS, pode ajudar a aumentar o número total de instâncias em execução do servidor NFS. Por padrão - 8 , pessoalmente, me ajudou a aumentar esse número para 64 .
Para conseguir isso, atualize o parâmetro RPCNFSDCOUNT=64 em /etc/default/nfs-kernel-server .
E reinicie os daemons:
systemctl restart nfs-utils systemctl restart nfs-server
NFSv3 vs NFSv4
Sabe a diferença entre NFSv3 e NFSv4 ?
- O NFSv3 é um protocolo sem estado, como regra, tolera melhor falhas e se recupera mais rapidamente.
- O NFSv4 é um protocolo com estado , funciona mais rápido e pode ser vinculado a determinadas portas tcp, mas devido à presença de estado, é mais sensível a falhas. Ele também tem a capacidade de usar a autenticação usando o Kerberos e vários outros recursos interessantes.
No entanto, quando você executa showmount -e nfs_server , o protocolo NFSv3 é usado. O Proxmox também usa o NFSv3. O NFSv3 também é comumente usado para organizar máquinas de inicialização de rede.
Em geral, se você não tiver um motivo específico para usar o NFSv4, tente usá-lo, pois é menos doloroso para falhas devido à falta de um estado como tal.
Você pode montar a bola usando o NFSv3 especificando o parâmetro -o vers=3 para o comando mount :
mount -o vers=3 nfs_server:/share /mnt
Se desejar, você pode desativar o NFSv4 para o servidor, para fazer isso, adicione a opção --no-nfs-version 4 à variável --no-nfs-version 4 e reinicie o servidor, por exemplo:
RPCNFSDCOUNT="64 --no-nfs-version 4"
iSCSI e LVM
Da mesma forma, um daemon tgt regular pode ser configurado dentro do contêiner, o iSCSI produzirá um desempenho significativamente mais alto para operações de E / S, e o contêiner funcionará mais tranqüilamente porque o servidor tgt funciona completamente no espaço do usuário.
Normalmente, um LUN exportado é dividido em várias partes usando o LVM . No entanto, há várias nuances a serem consideradas, por exemplo: como os bloqueios LVM são fornecidos para o compartilhamento de um grupo exportado em vários hosts.
Talvez essas e outras nuances sejam descritas no próximo artigo .