ZFS sobre problemas de gravação simultâneos do NFS

3

Eu executo um cluster Proxmox e, nesse cluster, tenho algumas VMs em uma rede privada, com um back-end de armazenamento CEPH (gerenciado por Proxmox) para os discos da VM.

Uma VM (KVM) executando o "Ubuntu 16.04 server minimum vm" é configurada com um segundo "disco rígido", configurado como um "armazenamento" de pool do ZFS de um disco, usando

zpool create storage /dev/sdb1

que é montado automaticamente em / storage. Essa VM também executa o nfs-kernel-server.

Este diretório é exportado através do nfs com a seguinte linha em / etc / exports:

/storage        10.10.0.0/16(rw,sync)

Eu montei esta exportação de duas outras máquinas (uma VM rodando o Ubuntu 14.04, uma máquina física rodando o servidor Ubuntu 16.04) através de

mount -t nfs4 10.10.3.1:/storage /mnt

Como este é meu playground para testar uma configuração de armazenamento para dois servidores web planejados que hospedam um aplicativo antigo perl escrito em arquivos Berkeley DB, decidi testar gravações simultâneas de maneira simples para testar meu back-end de armazenamento compartilhado, com um simples script php:

<?php
    $line = str_repeat($argv[1], 30) . "\n";

    for ($i = 1; $i <= 10000; $i++)
    {
        $of = fopen("test.txt", "a") or DIE("can't open output file\n");
            fwrite($of, sprintf("%04d-", $i)  . $line);
        fclose($of);
    }

?>

Eu vou para o diretório de armazenamento compartilhado (é onde o script php também está localizado), e o executo usando

php test.php 1

da primeira máquina remota e com

php test.php 2

da segunda máquina.

Meu problema é que algumas gravações não parecem chegar ao arquivo de destino, ou seja, eu recebo uma saída assim:

9286-222222222222222222222222222222
9287-222222222222222222222222222222
9288-222222222222222222222222222222
9289-222222222222222222222222222222
7473-111111111111111111111111111111
7474-111111111111111111111111111111
7475-111111111111111111111111111111
7476-111111111111111111111111111111
7477-111111111111111111111111111111
7478-111111111111111111111111111111
7479-111111111111111111111111111111
9297-222222222222222222222222222222
9298-222222222222222222222222222222
7481-111111111111111111111111111111
9300-222222222222222222222222222222
7482-111111111111111111111111111111
9302-222222222222222222222222222222
7484-111111111111111111111111111111

e verificar se a linha não é armazenada em cache e gravada em uma posição diferente no arquivo:

nas:/storage# grep "9290-" test.txt
9290-111111111111111111111111111111
nas:/storage# 

i.e. está faltando (entre outros) o

9290-222222222222222222222222222222
linha

. Neste momento, estou esperando que eu esteja simplesmente perdendo alguns parâmetros de configuração ou uma ou duas etapas durante a configuração que possam corrigir esse problema.

Edit: Eu só notei que as gravações parecem bloquear uma a outra, ou seja, as lacunas entre os números de linha sempre correspondem ao número de gravações de intercalação do outro "escritor" remoto. Ainda não estou mais perto de explicar por que isso acontece, nem como resolvê-lo.

Além disso, eu tinha "Discard" e "IO thread" ativos no proxmox para o disco rígido vm e desativava essas duas opções, sem efeito (não achei que seria, mas verificado, no entanto). O comportamento é o mesmo.

    
por Eddy Buhler 06.03.2017 / 13:24

1 resposta

3

Ok, aparentemente o Berkeley DB oferece mecanismos de bloqueio para acesso simultâneo, portanto, meu "cenário de teste simples" é inadequado para que o bloqueio ocorra no nível do aplicativo; meu script de teste não faz nada do tipo, então o teste não corresponde ao caso de uso.

Consequentemente, estou considerando essa questão respondida. Obrigado pelas respostas!

    
por 06.03.2017 / 15:02

Tags