O ZFS para Linux sobrecarrega o VirtualBox?

4

Estou usando o MD raid + LVM há muitos anos, mas recentemente decidi dar uma olhada no ZFS. Para experimentá-lo, criei uma VM VirtualBox com um layout semelhante ao meu servidor principal - 7 unidades 'SATA' ou vários tamanhos.

Configurei-o com uma aproximação da minha configuração atual do MD + LVM e continuei a trabalhar nas etapas que precisava seguir para reorganizar arquivos, LVs, VGs etc, para liberar espaço para testar o ZFS. Tudo parecia ok - eu mudei e rearranjei PVs até que eu tivesse o espaço configurado em um período de 3 dias de atividade.

Finalmente, criei o primeiro ZPool:

  pool: tank
 state: ONLINE
  scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    tank        ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        sdb1    ONLINE       0     0     0
        sdc1    ONLINE       0     0     0
        sdd1    ONLINE       0     0     0
        sde1    ONLINE       0     0     0
        sdg1    ONLINE       0     0     0

errors: No known data errors

Eu criei alguns conjuntos de dados do ZFS e comecei a copiar arquivos usando cp e tar . Por exemplo. cd /data/video;tar cf - .|(cd /tank/video;tar xvf -) .

Em seguida, percebi que estava recebendo erros de SATA na máquina virtual, embora o sistema host não mostre erros.

Apr  6 10:24:56 model-zfs kernel: [291246.888769] ata4.00: exception Emask 0x0 SAct 0x400 SErr 0x0 action 0x6 frozen
Apr  6 10:24:56 model-zfs kernel: [291246.888801] ata4.00: failed command: WRITE FPDMA QUEUED
Apr  6 10:24:56 model-zfs kernel: [291246.888830] ata4.00: cmd 61/19:50:2b:a7:01/00:00:00:00:00/40 tag 10 ncq 12800 out
Apr  6 10:24:56 model-zfs kernel: [291246.888830]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Apr  6 10:24:56 model-zfs kernel: [291246.888852] ata4.00: status: { DRDY }
Apr  6 10:24:56 model-zfs kernel: [291246.888883] ata4: hard resetting link
Apr  6 10:24:57 model-zfs kernel: [291247.248428] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Apr  6 10:24:57 model-zfs kernel: [291247.249216] ata4.00: configured for UDMA/133
Apr  6 10:24:57 model-zfs kernel: [291247.249229] ata4.00: device reported invalid CHS sector 0
Apr  6 10:24:57 model-zfs kernel: [291247.249254] ata4: EH complete

Este erro ocorre várias vezes em várias unidades diferentes, ocasionalmente com um comando com falha de 'READ FPDMA QUEUED' ou (duas vezes) 'WRITE DMA', na medida em que o kernel eventualmente reporta:

Apr  6 11:51:32 model-zfs kernel: [296442.857945] ata4.00: NCQ disabled due to excessive errors

Isso não impede que os erros sejam relatados.

Uma pesquisa na internet mostrou que esse erro havia sido registrado nos sites da VirtualBox.org há cerca de 4 anos ( link ) para a versão 4.0.2 do VirtualBox e aparentemente foi considerado fixo, mas reaberto.

Estou executando o VirtualBox 4.3.18_Debian r96516 no kernel Debian (Sid) versão 3.16.0-4-amd64 (que também é o sistema operacional convidado, bem como o sistema operacional host). O ZFS é a versão 0.6.3 para ZFSonLinux.org/debian.html.

Eu teria pensado que mais trabalho foi feito sobre isso nos anos intermediários, pois eu não posso acreditar que sou a única pessoa a testar o ZFS no VirtualBox, então teria pensado que esse erro teria sido identificado e resolvido especialmente como versões do ZFS e do VirtualBox são mantidas pelo Oracle.

Ou é simplesmente o caso em que o ZFS enfatiza a máquina virtual aos seus limites e o drive / controlador simulado simplesmente não consegue responder rápido o suficiente?

Atualização:

Nas 14 horas desde que criei um pool, a VM relatou 204 atributos do kernel. A maioria dos comandos falhados é 'WRITE FPDMA QUEUED', seguida por 'READ FPDMA QUEUED', 'WRITE DMA' e um único 'FLUSH CACHE'. Presumivelmente, o ZFS repetiu os comandos, mas até agora estou cauteloso em usar o ZFS em um servidor real se ele estiver produzindo muitos erros em uma máquina virtual!

    
por StarNamer 06.04.2015 / 15:08

1 resposta

0

Eles se parecem com erros genéricos de tempo limite do disco rígido no sistema convidado. Eles podem ser causados pelo ZFS, mas também podem ser causados por outras operações de E / S altas. Como sistema convidado, o Linux é bastante sensível a esse respeito, pois tem um tempo limite baixo (geralmente 30 segundos). Isso pode não ser suficiente em uma VM, especialmente se a imagem do disco for um arquivo regular e o sistema host estiver sob carga; algumas gravações podem demorar mais do que o esperado se o cache do host estiver cheio.

Ou, para citar o manual do VirtualBox :

However, some guests (e.g. some Linux versions) have severe problems if a write to an image file takes longer than about 15 seconds. Some file systems however require more than a minute to complete a single write, if the host cache contains a large amount of data that needs to be written.

Observe que isso não está limitado ao VirtualBox. Outras soluções de virtualização podem mostrar o mesmo comportamento ao executar um convidado Linux.

Quanto ao tempo limite em si: O tempo limite do hdd do Linux (levando a exceções de ata e possivelmente corrupção sob alta carga) pode ser aumentado no sistema convidado.

Por exemplo, no Debian 7, tudo o que você precisa fazer é adicionar algumas linhas ao seu /etc/rc.local :

$ cat /etc/rc.local 
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

TIMEOUT=86400
for f in /sys/block/sd?/device/timeout; do
    echo $TIMEOUT >"$f"
done

exit 0

Em seguida, grep para exceções de ata para ver se eles sumiram:

# grep -Rn --col 'ata.*exception' /var/log/

No entanto, seria preferível aumentar o desempenho do disco da vm em vez de ter que alterar o tempo limite do sistema convidado. No caso do VirtualBox, o " Cache de E / S do Host " do controlador de armazenamento virtual da vm pode ser desativado. Se ativado, o cache do host pode ser o gargalo e diminuir as operações de disco se houver muita E / S de disco no host. Por outro lado, desabilitá-lo pode aumentar a carga na própria VM, para que os tempos limites ainda possam ocorrer se o convidado estiver sobrecarregado, portanto, ativar o cache do host pode até ser melhor em alguns casos, dependendo de sua carga de trabalho.

Se isso não ajudar, o manual do VirtualBox também recomenda a experimentação do intervalo de flush:

For IDE disks use the following command:

VBoxManage setextradata "VM name"
  "VBoxInternal/Devices/piix3ide/0/LUN#[x]/Config/FlushInterval" [b]

For SATA disks use the following command:

VBoxManage setextradata "VM name"
  "VBoxInternal/Devices/ahci/0/LUN#[x]/Config/FlushInterval" [b]

Values between 1000000 and 10000000 (1 to 10 megabytes) are a good starting point. Decreasing the interval both decreases the probability of the problem and the write performance of the guest.

Em alguns testes, os sistemas convidados do VirtualBox experimentaram esses tempos limite de disco rígido (travar a VM e / ou causar corrupção), não importando se o cache de E / S do host estava habilitado ou não. O sistema de arquivos do host não era lento, exceto por meio minuto, sempre que uma tarefa cron planejada fosse executada, causando esses tempos limites na VM. Foi só depois de definir o tempo limite do disco rígido como descrito acima que o problema desapareceu e não ocorreram mais tempos limite.

    
por 22.08.2016 / 14:27