Os clusters ativos / passivos ainda são muito usados em muitos lugares e em execução na produção.
Veja abaixo nossa configuração de produção , ela está funcionando bem e você pode deixá-la em execução no modo manual ( orchestrate=start ) ou ativar o failover automático ( orchestrate=ha ). Usamos o zfs para se beneficiar do zfs send / receive e zfs snapshots, mas também é possível usar o drbd se você preferir a replicação síncrona.
Pré-requisitos:
- 2 nós (em meus nós físicos de configuração 2, 400 quilômetros de distância)
- discos internos
- 1 pool zfs em cada nó
- vlan esticado (na minha configuração usamos "vrack" no provedor de hospedagem OVH)
Etapas:
- instale o agente opensvc nos dois nós ( link )
- forma o cluster opensvc (3 comandos necessários, descritos no screencast no link )
- crie uma confiança ssh de raiz entre os dois nós
- crie um serviço do opensvc por convidado do kvm [arquivo de configuração do serviço abaixo]
root@node1:~$ svcmgr -s win1 print config
[DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-e5d5-4817-a8fe-e7a2004c5520
orchestrate = start
[fs#1]
mnt_opt = rw,xattr,acl
mnt = /srv/{svcname}
dev = data/{svcname}
type = zfs
[container#0]
type = kvm
name = {svcname}
guestos = windows
shared = true
[sync#1]
src = data/{svcname}
dst = data/{svcname}
type = zfs
target = nodes
recursive = true
schedule = @12h
Algumas explicações:
- o serviço é denominado "win1" e cada
{svcname} no arquivo de configuração do serviço é uma referência que aponta para o nome real do serviço (win1)
- início do serviço, faça o seguinte:
- monte o conjunto de dados do zfs
data/win1 no ponto de montagem /srv/win1
- inicie o contêiner kvm
win1
- ressource
sync#1 é usado para declarar uma replicação de conjunto de dados zfs assíncrona para o nó escravo (dados / win1 no nó1 são enviados para dados / win1 no nó2), uma vez por 12 horas no exemplo (zfs send / receive é gerenciado pelo agente opensvc)
O agente - opensvc também está lidando com a replicação de configuração do kvm qemu e definindo-o quando o serviço é relocado para o nó escravo
Alguns comandos de gerenciamento:
-
svcmgr -s win1 start inicia o serviço
-
svcmgr -s win1 stop pare o serviço
-
svcmgr -s win1 stop --rid container#0 pare o container referenciado container # 0 no arquivo de configuração
-
svcmgr -s win1 switch realocar o serviço para o outro nó
-
svcmgr -s win1 sync update aciona uma cópia de conjunto de dados zfs incremental
-
svcmgr -s win1 sync full aciona uma cópia completa do conjunto de dados do zfs
Alguns serviços que eu gerencio também precisam de snapshots zfs regularmente (diário / semanal / mensal), com retenção, neste caso eu adiciono o seguinte trecho de configuração ao arquivo de configuração de serviço, e o agente opensvc faz o trabalho. / p>
[sync#1sd]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61
keep = 7
name = daily
recursive = true
sync_max_delay = 1d
[sync#1sw]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 sun
keep = 4
name = weekly
recursive = true
sync_max_delay = 7d
[sync#1sm]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 * *:first
keep = 6
name = monthly
recursive = true
sync_max_delay = 31d
Conforme solicitado, também adiciono uma configuração lvm / drbd / kvm:
configuração do recurso drbd /etc/drbd.d/kvmdrbd.res :
resource kvmdrbd {
device /dev/drbd10;
disk /dev/drbdvg/drbdlv;
on node1 {
address 1.2.3.4:12345;
meta-disk internal;
}
on node2 {
address 4.3.2.1:12345;
meta-disk internal;
}
}
arquivo de configuração do serviço opensvc /etc/opensvc/kvmdrbd.conf :
root@node1# svcmgr -s kvmdrbd print config
[DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-f4d3-1234-a2cd-e7a2018c4321
orchestrate = start
[disk#1]
type = lvm
vgname = {env.drbdvgname}
standby = true
[disk#2]
type = drbd
standby = true
shared = true
res = {svcname}
[fs#0]
mnt = {env.basedir}/{svcname}
type = ext4
dev = /dev/{env.drbddev}
shared = true
[container#0]
type = kvm
name = {svcname}
shared = true
[sync#i0]
schedule = @1440
[env]
basedir = /srv
drbddev = drbd10
drbdvgname = drbdvg
Algumas explicações:
- na minha configuração, eu replico lvm lv com drbd. Eu crio um sistema de arquivos no dispositivo de blocos drbd. Neste sistema de arquivos, eu crio 1 arquivo simples por disco que quero apresentar para o convidado kvm.
-
disk#1 : é o lvm vg que hospeda o grande volume lógico. deve ter pelo menos 5 GB.
-
disk#2 : é o disco drbd apontado pelo nome do recurso drbd. Se o serviço opensvc tiver o nome "foo", você deverá ter o /etc/drbd.d/foo.res. Ou altere o parâmetro do disco # 2.res no arquivo de configuração do serviço.
-
fs#0 : o sistema de arquivos principal que hospeda todos os arquivos do disco para o kvm guest
-
container#0 : o convidado kvm, mesmo nome do serviço opensvc no exemplo. O agente deve ser capaz de resolver o convidado kvm, fazer uma verificação de ping antes de aceitar iniciar o serviço (se o ping responder, o convidado kvm já está sendo executado em algum lugar, e não é uma boa idéia iniciá-lo. pelo agente opensvc)
-
standby = true : significa que esse recurso deve permanecer ativo quando o serviço estiver sendo executado no outro nó. Em nosso exemplo, é necessário manter o drbd rodando bem
-
shared = true : link