Estou testando a configuração de um Xen DomU com um armazenamento DRBD para facilitar o failover. Na maioria das vezes, imediatamente após a inicialização do DomU, recebo um erro de E / S:
[ 3.153370] EXT3-fs (xvda2): using internal journal
[ 3.277115] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 3.336014] nf_conntrack version 0.5.0 (3899 buckets, 15596 max)
[ 3.515604] init: failsafe main process (397) killed by TERM signal
[ 3.801589] blkfront: barrier: write xvda2 op failed
[ 3.801597] blkfront: xvda2: barrier or flush: disabled
[ 3.801611] end_request: I/O error, dev xvda2, sector 52171168
[ 3.801630] end_request: I/O error, dev xvda2, sector 52171168
[ 3.801642] Buffer I/O error on device xvda2, logical block 6521396
[ 3.801652] lost page write due to I/O error on xvda2
[ 3.801755] Aborting journal on device xvda2.
[ 3.804415] EXT3-fs (xvda2): error: ext3_journal_start_sb: Detected aborted journal
[ 3.804434] EXT3-fs (xvda2): error: remounting filesystem read-only
[ 3.814754] journal commit I/O error
[ 6.973831] init: udev-fallback-graphics main process (538) terminated with status 1
[ 6.992267] init: plymouth-splash main process (546) terminated with status 1
A manpage do drbdsetup diz que o LVM (que eu uso) não suporta barreiras (mais conhecido como tagged command queuing ou native command queing ), então eu configurei o dispositivo drbd para não usar barreiras. Isso pode ser visto em /proc/drbd (por " wo:f , significando flush, o próximo método que o drbd escolhe após a barreira):
3: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
ns:2160152 nr:520204 dw:2680344 dr:2678107 al:3549 bm:9183 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
E no outro host:
3: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
ns:0 nr:2160152 dw:2160152 dr:0 al:0 bm:8052 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
Também ativei a opção disable_sendpage, conforme os documentos do drbd:
cat /sys/module/drbd/parameters/disable_sendpage
Y
Eu também tentei adicionar barreiras = 0 a fstab como opção de montagem. Ainda assim, às vezes diz:
[ 58.603896] blkfront: barrier: write xvda2 op failed
[ 58.603903] blkfront: xvda2: barrier or flush: disabled
Eu nem sei se o ext3 tem uma opção nobarrier. E, como apenas um dos meus sistemas de armazenamento é suportado por bateria, não seria inteligente de qualquer maneira.
Por que ainda compensa as barreiras quando eu desabilitei isso?
Ambos os hosts são:
Debian: 6.0.4
uname -a: Linux 2.6.32-5-xen-amd64
drbd: 8.3.7
Xen: 4.0.1
Convidado:
Ubuntu 12.04 LTS
uname -a: Linux 3.2.0-24-generic pvops
recurso drbd:
resource drbdvm
{
meta-disk internal;
device /dev/drbd3;
startup
{
# The timeout value when the last known state of the other side was available. 0 means infinite.
wfc-timeout 0;
# Timeout value when the last known state was disconnected. 0 means infinite.
degr-wfc-timeout 180;
}
syncer
{
# This is recommended only for low-bandwidth lines, to only send those
# blocks which really have changed.
#csums-alg md5;
# Set to about half your net speed
rate 60M;
# It seems that this option moved to the 'net' section in drbd 8.4. (later release than Debian has currently)
verify-alg md5;
}
net
{
# The manpage says this is recommended only in pre-production (because of its performance), to determine
# if your LAN card has a TCP checksum offloading bug.
#data-integrity-alg md5;
}
disk
{
# Detach causes the device to work over-the-network-only after the
# underlying disk fails. Detach is not default for historical reasons, but is
# recommended by the docs.
# However, the Debian defaults in drbd.conf suggest the machine will reboot in that event...
on-io-error detach;
# LVM doesn't support barriers, so disabling it. It will revert to flush. Check wo: in /proc/drbd. If you don't disable it, you get IO errors.
no-disk-barrier;
}
on host1
{
# universe is a VG
disk /dev/universe/drbdvm-disk;
address 10.0.0.1:7792;
}
on host2
{
# universe is a VG
disk /dev/universe/drbdvm-disk;
address 10.0.0.2:7792;
}
}
DomU cfg:
bootloader = '/usr/lib/xen-default/bin/pygrub'
vcpus = '2'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'phy:/dev/drbd3,xvda2,w',
'phy:/dev/universe/drbdvm-swap,xvda1,w',
]
#
# Hostname
#
name = 'drbdvm'
#
# Networking
#
# fake IP for posting
vif = [ 'ip=1.2.3.4,mac=00:16:3E:22:A8:A7' ]
#
# Behaviour
#
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
Na minha configuração de teste: o armazenamento do host primário é o RAID PCIe SATA-II 9650SE com bateria. O secundário é o software RAID1.
O DRBD + Xen não é amplamente utilizado? Com esses problemas, não vai funcionar.
Editar: as barreiras são, na verdade, um problema conhecido ( aqui e aqui ). Eu ainda não vejo a solução ainda.
Não sei se isso muda alguma coisa, mas você também pode especificar os volumes DRBD em sua configuração de DomU da seguinte forma:
disk = [ 'drbd:drbdvm,xvda2,w' ... ]
Dessa forma, ao criar o DomU, o Xen tornará automaticamente o nó atual primário para o recurso especificado (a menos que o recurso já esteja sendo usado pela segunda máquina). Além disso, quando o DomU é destruído, o recurso será liberado.
Eu tenho muitos pares de DRBD rodando assim e nunca vi o erro que você postou.
Adicione extra = " barrier=off" à sua configuração do DomU. Observe o espaço antes da barreira .
Adicione também a opção de barreira / desativação correspondente (de acordo com as opções de montagem do sistema de arquivos) no / etc / fstab de suas DomUs.
Atualização:
A opção barreira / desligado é uma segunda medida para garantir que as barreiras estejam desativadas.
Quanto a operações de barreira: como você pode ver durante a inicialização, essas operações falham. Então desligá-lo não piora as coisas. Além disso, essas barreiras só fazem sentido em discos rígidos com o cache de gravação ativado que não é gravado no disco em falhas de energia.
Um servidor deve ter um no-break com bateria, bem como um controlador RAID com backup de bateria. Então, transformar as barreiras só vai custar desempenho (mesmo que funcione).