NASDEC: LVM e GlusterFS perfazem um NASDEC funcional

Este artigo é talvez o mais importante da série do NASDEC (nosso projeto para criar um NAS que dê aos nossos dados uma longevidade superior a 10 anos e satisfazendo vários critérios de segurança): vou detalhar de forma simplificada como se pode montar as camadas superiores da pilha de armazenamento – o LVM e o GlusterFS. Ao final do artigo já teremos um NASDEC minimamente funcional e pronto pra usar.

Uma Breve Recapituação

No artigo sobre a configuração de hardware, descrevi que o NASDEC consiste em dois computadores quase iguais (chamados monkey e dinky) ligados via uma rede Gigabit Ethernet. Cada um tem um disco rígido de 3TB endereçado pelo dispositivo /dev/sda e dedicado exclusivamente ao armazém de dados – nem mesmo uma tabela de partição eu me dei o trabalho de criar. O sistema operacional, aplicativos e utilitários fica em um cartão MicroSD de 4GB dentro de um leitor USB que aparece como /dev/sdb.

No artigo sobre o subsistema de cifragem, mostrei como transformei esse /dev/sda em uma versão com cifragem/decifragem em tempo real, que aparece como /dev/mapper/esda (o "e" representa "encrypted"). Esse lance da cifragem foi para atender um dos itens da lista de requisitos, que considera a hipótese do equipamento ser roubado e exige que a confidenciadidade dos dados seja preservada mesmo se isso acontecer.

Nem todo mundo precisa desse requisito; por isso, ao criar o seu próprio NASDEC, você pode perfeitamente dispensar a cifragem se quiser; para isso, no passo-a-passo que vou descrever adiante, pule os passos relativos ao cryptsetup e, nos demais, troque todas as ocorrências de /dev/mapper/esda por /dev/sda (ou seja lá qual o nome que seu disco tenha recebido.)

Para a conveniência do leitor, repito aqui a figura com o mapa conceitual geral da pilha de armazenamento, que servirá como roteiro geral do que faremos hoje (note que ele deve ser lido de baixo pra cima):

Para uma explicação conceitual sobre cada um desses componentes, leia o artigo específico sobre isso. Hoje não é mais o dia dos conceitos e discussões de design; hoje é dia de "mão na massa"!

Instalação dos Utilitários

Tanto o LVM quanto os sistemas de arquivos que vamos usar (BTRFS e JFS) são divididos em dois componentes: alguns módulos de kernel que normalmente já vêm incluídos quando o próprio kernel é instalado; e outro com os utilitários de controle, que você pode instalar usando:

# apt-get install lvm2 btrfs-tools jfsutils

Nesse e nos demais exemplos, o texto em vermelho-negrito é o que você deve digitar; o texto em preto é o que aparece ou que o sistema responde. O "# " imita o prompt do Linux e significa algo que deve ser feito como root nas duas máquinas. Quando o prompt contiver o nome de uma máquina (por exemplo, [email protected]:~#, significa que esses comandos devem ser executados apenas naquela máquina específica.)

A Configuração dos Volumes Lógicos

Se você estiver usando cifragem, siga os passos descritos na seção "Resumo da Ópera" do post anterior para criar o dispositivo cifrado /dev/mapper/esda. Assumindo que você já tenha feito a etapa de inicialização, deve ser algo da seguinte forma:

# cryptsetup --verify-passphrase esda /dev/sda

O comando acima é para o caso de você estar usando o kernel padrão e o esquema de cifragem padrão AES-CBC. Como eu expliquei no post anterior, esse esquema não é tão bom em termos de velocidade e tolerância a falhas do disco rígido. Se, ao invés, você tiver instalado o kernel que eu montei, com suporte ao algoritmo de cifragem Salsa20/12, faça assim:

# cryptsetup --verify-passphrase -c salsa20_12-plain-plain64 esda /dev/sda

O sistema vai lhe perguntar a frase-senha do dispositivo cifrado. CUIDADO AO DIGITÁ-LA: certifique-se que você a digitou de forma absolutamente correta. Quando usamos o cryptsetup tal como acima, no chamado "modo cru", ele não dá erro se você digitar a frase-senha errada; se você fizer isso, o dispositivo de bloco /dev/mapper/esda vai ser criado com sucesso, mas seu conteúdo parecerá "lixo", de forma que o LVM ou seu sistema de arquivos não vão reconhecer nada. Para minimizar a chance de você errar, eu acrescentei a opção --verify-passphrase, que faz com que o cryptsetup pergunte a senha duas vezes e aborte a operação se você não digitar a mesma senha na segunda vez.

Finalmente é hora de criarmos os volumes lógicos. Como de praxe, vamos inicialmente marcar o /dev/mapper/esda como sendo um "volume físico" (também chamado de "PV", sigla de "physical volume") sob controle do LVM:

# pvcreate /dev/mapper/esda

Em seguida, vamos criar um grupo de volumes ("VG", sigla de "volume group") chamado vg0 consistindo apenas desse único volume físico:

# vgcreate vg0 /dev/mapper/esda

No futuro, quando eu tiver mais de um disco, uma das maneiras de expandir o espaço em disco seria acrescentando esse novo disco ao grupo vg0.

Mas isso é no futuro. Voltando ao agora, vamos criar o volume lógico, que chamaremos de "nasdec". Apesar de termos 2.73TiB de espaço, eu comecei "pequeno", inicialmente alocando "apenas" 300GB:

# lvcreate -n nasdec -L 300G /dev/vg0

Pronto: agora temos um dispositivo chamado /dev/vg0/nasdec com 300GB de espaço e que poderemos expandir no futuro, até o limite de espaço disponível no /dev/vg0. Isso é o mais legal do LVM: os "volumes lógicos" ou ("LVs") atuam como as antigas "partições", mas com a diferença que podem ser redimensionadas (aumentando ou diminuindo sua capacidade), movidas, rearranjadas, etc., em muitos casos sem a necessidade de reiniciar a máquina e sem mesmo sem parar as aplicações que estiverem usando o disco – algo como trocar a toalha da mesa sem precisar mexer nos pratos e talheres!

Chegou então a hora de criar o sistema de arquivos e montá-lo. Observando o conceito de "redundância dissimilar" que discuti anteriormente, na máqina monkey eu usei o BTRFS:

[email protected]:~# mkfs.btrfs /dev/vg0/nasdec

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on /dev/vg0/nasdec
	nodesize 4096 leafsize 4096 sectorsize 4096 size 300.00GB
Btrfs Btrfs v0.19
[email protected]:~# mkdir /nasdec
[email protected]:~# mount -t btrfs /dev/vg0/nasdec /nasdec

Ao passo que na máquina dinky eu usei o JFS:

[email protected]:~# mkfs.jfs /dev/vg0/nasdec
mkfs.jfs version 1.1.12, 24-Aug-2007
Warning!  All data on device /dev/vg0/nasdec will be lost!

Continue? (Y/N) y
   |

Format completed successfully.

314572800 kilobytes total disk space.
[email protected]:~# mkdir /nasdec
[email protected]:~# mount -t jfs /dev/vg0/nasdec

Teste Rasteiro Preliminar do Desempenho

A título de curiosidade, vamos medir que tipo de velocidade estamos obtendo após todas essas camadas, usando o utilitário dd para cronometrar o temp que leva para escrever 4GB de zeros em um arquivo chamado test. Na máquina monkey, obtive:

[email protected]:~# cd /nasdec
[email protected]:~# dd if=/dev/zero of=test bs=1M count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB) copied, 39.0438 s, 107 MB/s
[email protected]:~# rm test

E na máquina dinky, obtive:

[email protected]:~# cd /nasdec
[email protected]:~# dd if=/dev/zero of=test bs=1M count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB) copied, 39.0481 s, 107 MB/s
[email protected]:~# rm test

Esse resultado é fruto de uma coincidência curiosa: o BTRFS é, na realidade, ligeiramente mais rápido que o JFS; todavia, o disco rígido da máquina monkey (um Western Digital Caviar Green modelo WD30EZRS-00J de velocidade de rotação variável) é ligeiramente mais lento do que o da máquina dinky (um Seagate Barracuda XT ST33000651AS de 7200RPM). Isso fez com que os dois efeitos se cancelassem em proporção quase idêntica. É interessante observar que o resultado também é muito próximo ao obtido no benchmark da velocidade da criptografia usando o Salsa20/12 que fiz no artigo anterior.

Avaliemos o resultado global: no meu NASDEC, o LVM e os filesystems, combinados com a cifragem em tempo real, está tornando a velocidade de escrita de arquivos grandes cerca de 11% menor que o máximo de 120MB/s que eu havia medido anteriormente pro Caviar Green e 33% menor do que os 160MB/s máximos que eu medi pro Barracuda. Não deixa de ser uma perda significativa, mas perfeitamente tolerável, pois os arquivos serão acessados quase exclusivamente via rede e a velocidade máxima da Gigabit Ethernet é 111MB/s. Sob esse ponto de vista, os 107MB/s incorrem em uma perda de pouco menos do que 4% da velocidade máxima possível.

Acho esse resultado bastante razoável, especialmente considerando que as máquinas monkey e dinky são relativamente fraquinhas (usam um processador Intel Atom D510 de 1,6GHz e memória DDR2-800), sendo mais otimizadas para baixo consumo de energia do que para alto desempenho.

Ressalva: se medirmos a velocidade com uma outra carga de trabalho – por exemplo, arquivos pequenos ou atividades fortemente baseadas em acesso aleatório, que movam muito os cabeçotes dos HDs e, assim, fiquem dominados pela latência, o resultados serão bem diferentes, mas, ainda assim, competitivos.

Instalando o GlusterFS

Os desenvolvedores do Gluster disponibilizam um pacote prontinho para instalar no Debian; basta baixar e instalar manualmente, como mostrado abaixo (faça isso nas duas máquinas):

# wget http://download.gluster.com/pub/gluster/glusterfs/LATEST/Debian/
glusterfs_3.2.2-1%_amd64.deb
--2011-07-30 16:55:54-- http://download.gluster.com/pub/gluster/glusterfs/
LATEST/Debian/glusterfs_3.2.2-1_amd64.deb Resolving download.gluster.com... 70.38.57.57 Connecting to download.gluster.com|70.38.57.57|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 8912082 (8.5M) [application/x-debian-package] Saving to: “glusterfs_3.2.2-1_amd64.deb” 100%[=================================>] 8,912,082 1.07M/s in 9.0s 2011-07-30 16:56:03 (965 KB/s) - “glusterfs_3.2.2-1_amd64.deb” saved
[8912082/8912082] # dpkg -i glusterfs_3.2.2-1_amd64.deb Selecting previously deselected package glusterfs. (Reading database ... 25661 files and directories currently installed.) Unpacking glusterfs (from glusterfs_3.2.2-1_amd64.deb) ... Setting up glusterfs (3.2.2-1) ... Processing triggers for man-db ...

Configurando o GlusterFS

Vamos usar o script de partida que o pacote provê para colocar o daemon glusterd para rodar:

# /etc/init.d/glusterd start
Starting glusterd service: glusterd.

Na terminologia do Gluster, os computadores que oferecem via rede seu espaço de armazenamento são chamadas de "bricks" ("tijolos", em inglês). Para que o GlusterFS funcione, o deamon glusterd precisa estar todando em todos os tijolos.

Vale mencionar que o glusterd é um programa userspace comum e não tem nenhuma necessidade especial. Por isso, ele pode ser facilmente virtualizado. É exatamente isso que vou fazer em um post futuro e isso nos dará algumas vantagens de organização, segurança e até mesmo de desempenho. Todavia, como nem todo mundo pode querer usar o meu sistema de compartimentalização em geral e os vservers em particular, hoje vou explicar tudo sem apelar para a virtualização.

Quando a gente dá partida no glusterd pela primeira vez, ele se considera "sozinho no Universo" – se lhe perguntarmos quem são seus pares ("vizinhos"), ele responderá que não há nenhum:

# gluster peer status
No peers present

O GlusterFS espera ser capaz de identificar os endereços IP dos seus vizinhos através do DNS. No caso do nosso NASDEC, onde só temos duas máquinas, criar um servidor DNS só pra isso seria exagero. Por isso, vou usar a abordagem simplista (alguns diriam "gambiarresca") de acrescentar os nomes das duas máquinas manualmente no /etc/hosts das duas máquinas:

# echo 192.168.10.200 monkey >> /etc/hosts
# echo 192.168.10.201 dinky  >> /etc/hosts

Naturalmente, substitua os endereços IP acima pelos endereços que você (ou o seu servidor DHCP) tiver atribuído às suas máquinas. O correto funcionamento de tudo que estou explicando aqui depende, naturalmente, da conectividade e configurações de rede estarem corretas e funcionando.

Com isso feito, podemos apresentar as máquinas umas às outras. Primeiro vamos avisar a monkey que ela tem uma vizinha chamada dinky:

[email protected]:~# gluster peer probe dinky
Probe successful

Se perguntarmos novamente agora sobre os vizinhos que ela conhece, ela terá algo mais interessante a nos dizer:

[email protected]:~# gluster peer status
Number of Peers: 1

Hostname: dinky
Uuid: e1b566bf-0414-468e-a826-9febd9804e6d
State: Peer in Cluster (Connected)

Se estivéssemos usando um servidor DNS, nem seria necessário fazer o procedimento equivalente em dinky. Todavia, como estamos forçando a barra via o /etc/hosts, é bom fazer:

[email protected]:~# gluster peer probe dinky
Probe successful

Com as máquinas devidamente apresentadas, podemos agora configurar o volume acessível via rede:

[email protected]:~# gluster volume create nasdec \
replica 2 transport tcp monkey:/nasdec dinky:/nasdec
Creation of volume nasdec has been successful. Please start the volume
to access data.

Esse comando indica que queremos criar um volume chamado nasdec usando o transporte via TCP e com os dados replicados em dois servidores: uma cópia fica no diretório /nasdec do servidor monkey e a outra fica no diretório de mesmo nome no servidor dinky.

Por fim, vamos dar partida no volume:

[email protected]:~# gluster volume start nasdec
Starting volume nasdec has been successful

E só. Nosso cluster já está pronto pra usar.

Note que toda essa etapa de preparação só é necessária na primeira vez. Todas as configurações que tijolos e volumes ficam salvas em disco. Quando iniciarmos o glusterd novamente, ele automaticamente procurará seus vizinhos e dará partida nos volumes, sem precisarmos fazer nem configurar mais nada.

Note ainda que, por padrão, o Gluster aceita conexões oriundas de quaisquer máquinas. Você pode querer configurar o firewall local das máquinas para restringir o acesso apenas a máquinas que você explicitamente autorizar. O próprio Gluster também oferece um recurso semelhante na camada de aplicação. Para maiores detalhes, leia a documentação do comando gluster (especificamente o subcomando set e as variáveis de configuração auth.allow e auth.reject.

Dando uma "primeira voltinha"

Em uma outra máquina, vamos instalar o clientes necessários para usar o Gluster e rodarmos uns testes de funcionalidade e desempenho.

O mesmo pacote glusterfs_3.2.2-1_amd64.deb oferece também um cliente GlusterFS. Por isso, vamos repetir aquele procedimento de instalação:

[email protected]:~# wget http://download.gluster.com/pub/gluster/glusterfs/LATEST/
Debian/glusterfs_3.2.2-1_amd64.deb
--2011-07-18 15:15:36-- http://download.gluster.com/pub/gluster/glusterfs/
LATEST/Debian/glusterfs_3.2.2-1_amd64.deb Resolving download.gluster.com... 70.38.57.57 Connecting to download.gluster.com|70.38.57.57|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 8912082 (8.5M) [application/x-debian-package] Saving to: “glusterfs_3.2.2-1_amd64.deb” 100%[======================================>] 8,912,082 972K/s in 11s 2011-07-18 15:15:48 (792 KB/s) - “glusterfs_3.2.2-1_amd64.deb” saved
8912082/8912082] [email protected]:~# dpkg -i glusterfs_3.2.2-1_amd64.deb Selecting previously deselected package glusterfs. (Reading database ... 22583 files and directories currently installed.) Unpacking glusterfs (from glusterfs_3.2.2-1_amd64.deb) ... Setting up glusterfs (3.2.2-1) ... Processing triggers for man-db ...

A primeira diferença é que o cliente do Gluster é baseado no FUSE, então precisamos também instalar o pacote fuse-utils:

[email protected]:~# gluster volume start nasdec

Como estamos usando a gambiarra de colocar os nomes e IPs dos tijolos no /etc/hosts, precisaremos repeti-las também:

[email protected]:~# echo 192.168.10.200 monkey >> /etc/hosts
[email protected]:~# echo 192.168.10.201 dinky  >> /etc/hosts

Agora, finalmente, podemos montar o sistema de arquivos:

[email protected]:~# mount -t glusterfs monkey:/nasdec /mnt

Prontinho. Agora vamos salvar algum arquivo lá para testar a funcionalidade de replicação automática:

[email protected]:~# cp /bin/bash /mnt/teste
[email protected]:~# ls -l /mnt/teste
-rwxr-xr-x 1 root root 926536 Jul 18 15:39 /mnt/test
[email protected]:~# md5sum /mnt/teste
9a99d4a76f3f773f7ab5e9e3e482c213  /mnt/teste

Vamos ver como esse arquivo aparece em monkey:

[email protected]:~# ls -l /nasdec/teste
-rwxr-xr-x 1 root root 926536 Jul 18 15:39 /nasdec/teste
[email protected]:~# md5sum /nasdec/teste
9a99d4a76f3f773f7ab5e9e3e482c213  /nasdec/teste

E em dinky:

[email protected]:~# ls -l /nasdec/teste
-rwxr-xr-x 1 root root 926536 Jul 18 15:39 /nasdec/teste
[email protected]:~# md5sum /nasdec/teste
9a99d4a76f3f773f7ab5e9e3e482c213  /nasdec/teste

Ou seja, o fato de nós salvarmos o arquivo no /mnt da máquina cliente faz com que duas réplicas idênticas sejam salvas sob o diretório /nasdec das máquinas monkey e dinky.

O mais legal é que se qualquer uma das máquinas sair do ar, mesmo que seja no meio de uma operação de escrita, o cliente detecta automaticamente e prossegue com a máquina restante. Quando a máquina que caiu voltar ao ar, acontecerá o processo de cura automática: toda vez que um diretório é acessado, o Gluster confere os metadados dos arquivos para verem se são idênticos. Se não forem, a versão mais atual é automaticamente recopiada para os demais tijolos.

Isso viabiliza coisas como tirarmos uma das máquinas do ar para manutenção, reparos, atualizações, aumento de capacidade, etc., sem que os usuários sequer percebam. É também o que dificulta perdermos nossos dados caso algum componente pife: desde que a outra cópia sobreviva, continuaremos bem.

Uma ressalva importante: o protocolo de comunicação entre o cliente Gluster e o servidor não é cifrado. Portanto, cuide bem da segurança física da sua rede cabeada, implemente boa cifragem na sua rede Wifi ou, melhor ainda, tunele tudo por sobre uma VPN.

Outro Teste Rasteiro de Desempenho

Já que estamos aqui, vamos fazer um teste de desempenho:

[email protected]:~# dd if=/dev/zero of=/mnt/bigfile bs=1M count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB) copied, 85,9293 s, 48.8 MB/s

Apesar de não ser de todo ruim, esses 48.8MB/s parecem meio decepcionantes. A culpada aqui é a replicação: por ser implementada no lado do cliente e como nosso volume tem duas réplicas, os dados são enviados pela rede duas vezes, uma para cada máquina. Por isso, a taxa de dados efetivamente passando na rede é, na realidade, por volta de 98MB/s, que já se compara mais favoravelmente com os 107MB/s que obtivemos anteriormente.

É interessante observar que a velocidade de leitura fica ligeiramente maior:

[email protected]:~# dd if=/mnt/bigfile of=/dev/null
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB) copied, 77.0353 s, 54.4 MB/s

Mesmo assim, nosso desempenho ainda está acima da "concorrência": compare com esse artigo do site Tom's Hardware, que mostra quatro soluções comerciais de NAS (todas baseadas no mesmo processador Atom D510 que nós usamos no NASDEC) que suportam criptografia: a melhor delas, na mais favorável das situações com criptografia ativada, dá um pouco menos de 30MB/s; a média está mais para uns 20MB/s.

Finalizando

Se você não usa cifragem, você pode colocar o glusterd das máquinas-tijolo para ser executado automaticamente na partida do sistema utilizando:

# update-rc.d glusterd defaults
update-rc.d: using dependency based boot sequencing

Com o disco cifrado, porém, esse método não vai funcionar porque o LVM não vai reconhecer o volume físico. Para simplificar o processo, eu criei um pequeno script que coloquei em /root/start-nasdec.sh:

#!/bin/bash
#
# Encrypted NASDEC start script v1.0
# By Marco "Kiko" Carnut 
# Licensed under the GPLv2 -- http://www.gnu.org/licenses/gpl-2.0.html

# Remove caso tenha ficado pendurado de alguma execucao anterior

cryptsetup remove esda >& /dev/null

# Recria o sda cifrado, vai aparecer em /dev/mapper/esda
# Isso vai emitir um prompt pedindo a frase-senha

cryptsetup -c salsa20_12-plain-plain64 create esda /dev/sda

# Testa pra ver se o LVM reconhece o LV. Se sim, prossegue; se nao,
# aborta dizendo que foi porque a frase senha foi digitada errada.

lvs | grep nasdec >& /dev/null
if [ "$?" != "0" ] ; then
    echo logical volume 'nasdec' not found, wrong decryption password?
    exit 1
fi

# Ativa o VG, para que os LVs possam ser usados (isso cria os
# devices /dev/vg0, /dev/vg0/nasdec e quaisquer outros que tenham
# sido configurados)

vgchange -ay > /dev/null

# Testa se o volume /dev/vg0/nasdec eh um JFS2. Se nao, seguimos adiante;
# Se sim, temos um procedimentinho especifico pra ele

if [ `file -sL /dev/vg0/nasdec | grep -c JFS2` == "1" ] ; then
   # O JFS nao faz automaticamente a recuperacao a partir do "journal";
   # nele, eh preciso passar o fsck para fazer isso. (mas eh muitissimo
   # mais rapido do que se fosse o ext2/3/4)
   fsck.jfs /dev/vg0/nasdec >& /dev/null
   if [ "$?" -gt "1" ] ; then
       echo fsck.jfs reported problems, check manually
       exit 1
   fi
   mount -t jfs -o noatime,nodiratime /dev/vg0/nasdec /nasdec
fi

# Testa se o volume /dev/vg0/nasdec eh um BTRFS. Se nao, seguimos adiante;
# Se sim, basta monta-lo.

if [ `file -sL /dev/vg0/nasdec | grep -c BTRFS` == "1" ] ; then
   mount -t btrfs -o noatime,nodiratime /dev/vg0/nasdec /nasdec
fi

# Com o backing store do gluster jah montado, podemos dar partida no
# glusterd. Isso automaticamente localiza os vizinhos e inicia o volume
# exportavel 'nasdec'

/etc/init.d/glusterd start

# Dah um tempinho e monta o volume 'nasdec' localmente no '/nas' para
# que o script de auto-cura possa rodar

sleep 2
mkdir -p /nas >& /dev/null
mount -t glusterfs localhost:/nasdec /nas

O script acima assume que você está usando o meu kernel personalizado com suporte ao algoritmo de cifragem Salsa20/12 (consulte o artigo sobre a camada de cifragem para detalhes sobre isso). Se você estiver usando o kernel padrão do Debian, remova o -c salsa20_12-plain-plain64 da linha do cryptsetup logo no começo.

Recomendo que esse script seja executado manualmente; não recomendo que ele seja colocado para rodar automaticamente durante a partida do sistema.

Note que o script termina montando o próprio filesystem via loopback. Isso vai ser útil para várias coisas que vou explicar oportunamente, mas uma delas eu vou explicar agora: para podermos disparar a "cura automática" de discrepâncias.

Relembre o que eu disse acima: o Gluster só percebe diferenças entre as réplicas quando o diretório que contém os arquivos diferentes é acessado. Em diretórios pouco acessados, isso pode fazer que um erro passe despercebido por muito tempo. Para minimizar a quantidade de tempo que esse erro passa despercebido, vamos colocar o seguinte comando no cron.hourly para ser executado uma vez a cada hora:

# cat > /etc/cron.hourly/self-heal
#!/bin/bash

find /nas -noleaf -print0 | xargs -0 stat >/dev/null
( tecle CONTROL+D neste ponto )

Esse script vai dar um stat em todos os diretórios do nosso volume nasdec montado no diretório /nas, fazendo com que o Gluster compare e resolva eventuais diferenças.

Conclusões

Nos próximos posts desta série vamos fazer vários aprimoramentos de segurança, organização e desempenho, bem como planejar o tratamento de upgrades, situações de falhas dos componentes. Discutiremos também estratégias, implementações e custos de backups.

Hoje passamos da parte "morro acima" do caminho – aquela em que a gente rala pra burro antes que o resultado apareça. Ainda há um bom caminho pela frente, mas vai ser "morro abaixo", no sentido que sentiremos os resultados aparecendo mais facilmente.

Assim, se você seguiu as instruções deste post com sucesso, já pode comemorar vitória, pois já tem seu próprio NASDEC minimamente funcionando. Adoraria ouvir as experiências de vocês (tanto de sucesso quanto de fracasso) nos comentários.

Partes anteriores

Próxima parte

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Marco Carnut | 2014-08-29 08:00:43 | permalink | topo

Olá Robson,

Primeiramente, obrigado! É ótimo ter feedback, motiva a gente a continuar escrevendo.

Na época em que eu escrevi este artigo, a implementação do ZFS para Linux aina me parecia meio embrionária, incompleta e menos avançada do que o BTRFS. Talvez essa situação tenha mudado; não sei lhe dizer porque ainda não tive a chance de fazer algum projeto ou laboratório com ele. Na primeira oportunidade que eu tiver de fazer isso, eu reporto.

Quanto à atualização, eu tenho atualizado normalmente via apt-get update e apt-get upgrade. O único detalhe é que, como eu uso a cifragem com o salsa20_12, eu mantenho o kernel com o patch para dar suporte a esse algoritmo. Se você usa o algortimo aes padrão do cryptsetup, não precisa se preocupar com isso e pode deixar o apt atualizar o kernel também.

-K.

Robson | 2014-07-10 11:47:15 | permalink | topo

Primeiro Parabens!!!

Execelente artigo e me sera muito util, estou montando um NASDEC em minha casa e espero que funcione muito bem gracas as suas dicas.

Pelo tempo desde a ultima postagem, imagino que nao haja outras ou voce ainda esta muito ocupado para continuar...pena !

Estou abandonando de vez o windows e estou instalando o kubuntu 14.04 LTS e pretendo implementar o BRTFS (ou quem sabe o ZFS se voce achar melhor) como sistema de arquivo e aproveitarei as dicas de criptografia para garantir seguranca nele.

Se possivel gostaria de algumas dicas: - ZFS ou BRTFS ? Estarei usando a mesma estrutura de disco mostrada no seu artigo, so que com uma maquina so

- Alguma recomendacao sobre atualizacao das tecnologias mostradas aqui ?

- Como ocorreria a atualizacao de tudo isso ?

Obrigado.

JrBenito | 2011-08-25 22:45:47 | permalink | topo

Parabéns pela série. Abriu diversas novas ideias e fechou algumas lacunas sobre LVM e cluster.

Confesso: Estou muito curioso sobre os vservers e compartimentalização.

Também estou ansioso pela discussão sobre o backup de tudo isso. Afinal, como você disse, as duas máquinas podem ser roubadas, pode haver catástrofes naturais.

Abraço e obrigado.