Estou tentando configurar duas máquinas sincronizando com o DRBD. O armazenamento é configurado da seguinte forma: PV - > LVM - > DRBD - > CLVM - > GFS2.
O DRBD está configurado no modo principal duplo. O primeiro servidor está configurado e funcionando bem no modo primário. As unidades no primeiro servidor possuem dados sobre elas. Eu configurei o segundo servidor e estou tentando trazer os recursos do DRBD. Eu criei todos os LVMs base para combinar com o primeiro servidor. Depois de inicializar os recursos com ''
drbdadm create-md storage
Estou trazendo os recursos emitindo
drbdadm up storage
Depois de emitir esse comando, recebo um kernel panic e o servidor é reinicializado em 30 segundos. Aqui está uma captura de tela.
Minhaconfiguraçãoéaseguinte:SO:CentOS6
uname-aLinuxhost.structuralcomponents.net2.6.32-279.5.2.el6.x86_64#1SMPFriAug2401:07:11UTC2012x86_64x86_64x86_64GNU/Linuxrpm-qa|grepdrbd
kmod-drbd84-8.4.1-2.el6.elrepo.x86_64drbd84-utils-8.4.1-2.el6.elrepo.x86_64cat/etc/drbd.d/global_common.conf
global{usage-countyes;#minor-countdialog-refreshdisable-ip-verification}common{handlers{pri-on-incon-degr"/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
# fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
# split-brain "/usr/lib/drbd/notify-split-brain.sh root";
# out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
# before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 15 -- -c 16k";
# after-resync-target /usr/lib/drbd/unsnapshot-resync-target-lvm.sh;
}
startup {
# wfc-timeout degr-wfc-timeout outdated-wfc-timeout wait-after-sb
become-primary-on both;
wfc-timeout 30;
degr-wfc-timeout 10;
outdated-wfc-timeout 10;
}
options {
# cpu-mask on-no-data-accessible
}
disk {
# size max-bio-bvecs on-io-error fencing disk-barrier disk-flushes
# disk-drain md-flushes resync-rate resync-after al-extents
# c-plan-ahead c-delay-target c-fill-target c-max-rate
# c-min-rate disk-timeout
}
net {
# protocol timeout max-epoch-size max-buffers unplug-watermark
# connect-int ping-int sndbuf-size rcvbuf-size ko-count
# allow-two-primaries cram-hmac-alg shared-secret after-sb-0pri
# after-sb-1pri after-sb-2pri always-asbp rr-conflict
# ping-timeout data-integrity-alg tcp-cork on-congestion
# congestion-fill congestion-extents csums-alg verify-alg
# use-rle
protocol C;
allow-two-primaries yes;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
}
cat /etc/drbd.d/storage.res
resource storage {
device /dev/drbd0;
meta-disk internal;
on host.structuralcomponents.net {
address 10.10.1.120:7788;
disk /dev/vg_storage/lv_storage;
}
on host2.structuralcomponents.net {
address 10.10.1.121:7788;
disk /dev/vg_storage/lv_storage;
}
/ var / log / messages não está registrando nada sobre o travamento.
Eu tenho tentado encontrar uma causa disso, mas não consegui nada. Alguém pode me ajudar? Obrigado.
A exceção de verificação de máquina é um problema de hardware. Você pode usar mcelog para interpretá-lo, se você puder inicializar o sistema.
A resolução é substituir o hardware com falha. Como parece que você provavelmente está leasing de um servidor, entre em contato com o provedor.
Parece que o pânico do kernel foi causado pelo adaptador de rede. O servidor foi configurado com um NIC dedicado para o tráfego do DRBD. Quando mudei o tráfego do DRBD para o NIC onboard, as falhas pararam. Vou relatar se encontrar uma explicação melhor para o motivo de isso (outro tráfego nessa interface parece estar funcionando bem).