NASDEC: Software Básico e Pilha de Armazenamento

No post de hoje, vamos começar a discutir os aspectos de software relacionados ao NASDEC, o nosso armazém redundante de dados projetado para fazer com que nossos terabytes de dados sobrevivam pelo menos dez anos. Vou dar uma visão geral da pilha de software, explicando os prós e contras daquelas escolhas. Também vou falar de várias outras hipóteses que considerei, mas rejeitei.

Recomendo que o leitor dê uma lida nas partes anteriores desta série, especialmente na descrição do hardware e na lista de requisitos (que também faz as vezes de modelo de ameaças).

O Sistema Operacional

O sistema operacional que usei no NASDEC é um Linux baseado no Debian GNU/Linux 6.0 "Squeeze". Essa escolha foi feita por várias razões:

  • ele é gratuito, de forma que nem entra na planilha de custos;
  • É leve e oferece ótimo desempenho;
  • Tenho ampla familiaridade com ele;
  • Alguns dos programas que pretendia usar, apesar de terem versões para outros sistemas, nasceram e são mais bem ajustados para funcionar no Linux.

Além disso, eu sabia que provavelmente eu iria querer mudar algumas coisas para que funcionassem ao meu jeito. Por isso, uma solução de código aberto é essencial.

Uma das primeiras mudanças que eu pretendia fazer no Debian padrão era trocar o kernel pela versão 2.6.38, pois ela oferece um recurso que as versões anteriores não têm: o dm_crypt (responsável pela cifragem de disco em tempo real) agora pode rodar em múltiplos processadores, o que dará melhorias significativas no desempenho. Em uma máquina possante moderna, ele funciona bem mesmo da forma padrão. No caso do NASDEC, devido ao processador Atom "fraquinho", precisei lançar mão de umas "magias negras" que explicarei timtim por timtim no próximo artigo.

Além disso, queria usar uma versão com suporte a VServers. Os VServers são minha solução de virtualização preferida para Linux: fáceis de usar, oferecem excelente isolamento entre as máquinas virtuais, e dão o menor consumo de disco e memória, aliado ao melhor desempenho, dentre quase todas as outras soluções de virtualização que eu conheço.

Aqui na Tempest a gente usa VServers pra quase tudo. Especificamente no caso do NASDEC, a virtualização será útil para pelo menos duas principais finalidades:

  • Há algumas vantagens em virtualizar os próprios serviços de "armazém de dados" do NASDEC: vai ficar mais organizado, facilitar atualizações e testes, além de ficar mais seguro (contra o que, exatamente, eu explicarei mais adiante).

  • Há alguns serviços extras que, em rigor, não fazem parte do armazém de dados, mas que que eu gostaria de "pendurar" nas mesmas máquinas do NASDEC. Por exemplo, eu opero um "bridge node" do Tor e uso muito o Transmission para baixar ou oferecer grandes massas de dados. Hoje esses caras ficam em uma máquina separada, que torra energia, diminui a autonomia das baterias do UPS e me dá trabalho de manter. Colocando nas mesmas máquinas do NASDEC, eu economizo trabalho, energia e fica tudo mais simples.

A Pilha Armazenamento

O subsistema de armazenamento é composto de várias "camadas", cada uma empilhada por sobre as demais, com cada item mais acima usando o item abaixo como insumo. O diagrama abaixo dá uma visão geral de como eu montei a pilha de dispositivos de hardware e pseudo-dispositivos de software:

De baixo para cima:

  • O /dev/sda representa o primeiro disco rígido SATA – no caso, o disco de 3TB. Note que eu nem sequer criei uma tabela de partições nele; eu usei o disco todo como insumo do subsistema de criptografia.

  • Usando o utilitário cryptsetup (que controla o módulo de kernel dm_crypt), criei um pseudo-dispositivo que chamei de esda (o "e" é de "encrypted"). Esses pseudo-dispositivos aparecem debaixo do diretório /dev/mapper. Assim, tudo que for gravado no /dev/mapper/esda é, na realidade, cifrado e salvo no setor correspondente do /dev/sda; e tudo que algum programa tentar ler no /dev/mapper/esda, na realidade estará vindo do /dev/sda e decifrado.

A maneira exata como configurei o dm-crypt será alvo do próximo artigo desta série. Inclusive, aposto que será um dos mais divertidos, devido a uns detalhes técnicos pouco discutidos e algumas escolhas polêmicas que adotei.

  • Em seguida, eu criei um "grupo de volumes" ("volume group" ou "VG", no jargão do LVM) chamado vg0 (na falta de um nome mais criativo) para conter o único PV que tínhamos. Esse VG ficou com a totalidade do tamanho disponível do disco físico, 3TB = 2,73TiB.

  • Criei um volume lógico ("logical volume" ou "LV") chamado "nasdec" alocando 300GB do vg0.

  • Por sobre o LV nasdec eu criei, na máquina monkey, um sistema de arquivos usando o BTRFS; e na máquina dinky eu criei um JFS. Montei esses caras debaixo do diretório /nasdec.

  • O espelhamento dos dados entre os diretórios /nasdec de cada máquina e sua disponibilização na minha rede local são feitos através do GlusterFS. Usar o Gluster nessa aplicação com só duas máquinas é quase "matar uma mosca com bala de canhão", pois ele foi projetado para criar sistemas de armazenamento com petabytes (milhares de terabytes) de capacidade. Mas ele escala muito bem tanto pra cima quanto pra baixo e oferece uma tremenda versatilidade nas relações entre redundância, desempenho e capacidade, provendo uma expansibilidade garantida para o futuro. Além disso, é, de longe, o software de "clustering" mais fácil de instalar e configurar que eu conheço.

Na figura acima eu omiti uma outra camada: um servidor "samba" para exportar a área de armazenamento do NASDEC via o protocolo CIFS, para que sistemas operacionais como o Windows possam usá-los também.

Na realidade, eu não fiz tudo isso de uma vez só; o esquema acima é o resultado de um monte de experiências fiz ao longo de vários dias, comparando características, benefícios, desvantagens, desempenho, etc., em diversos cenários. Vou brevemente discutir alguns cenários que considerei:

  • Posicionamento da Cifragem/Decifragem: eu poderia ter colocado a criptografia no topo da pilha, logo abaixo do glusterfs e imediatamente acima do sistema de arquivos (BRTFS ou JFS), usando, digamos, o eCryptfs. Isso traria algumas vantagens: por exemplo, eu poderia fazer com que os backups fossem feitos já a partir dos arquivos cifrados, dispensando outra solução de criptografia separada para os backups. Por outro lado, eu teria de ter uma chave para cada filesystem separado, o que complicaria um pouco o uso.

Além disso, o eCryptfs só cifra o conteúdo dos arquivos e não seus metadados; assim, se alguém roubasse ou apreendesse meus discos rígidos, poderia descobrir um bocado sobre minhas atividades só analisando os nomes dos arquivos e diretórios.
Pra mim, a necessidade de esconder os metadados é decisiva. Por isso, optei por usar cifragem total do "block device" do disco, na camada mais inferior da pilha. Com essa solução, há apenas uma senha por máquina e todos os volumes e sistemas de arquivos que eu criar já estarão automaticamente cifrados. Ou seja, depois que eu digitar a senha para dar partida no sistema, eu posso até "esquecer" que a criptografia existe e fazer tudo normalmente – exceto no caso dos backups, que terão de ser tratados separadamente.
A desvantagem é que o sistema não dá partida sozinho; após o boot, eu tenho de logar na máquina, dar o comando de partida e digitar a frase-senha. Armazenar a frase-senha no próprio disco ou em algum hardware (em um pen-drive ou algo mais exótico, como um smart-card) está fora de questão, pois se a máquina for roubada, quase certamente esse hardware seria levado junto. A segurança contra roubo é inteiramente calcada no fato de que a frase-senha da cifragem do disco não está armazenada em nenhum lugar senão minha cabeça. O que, por sinal, também significa que se eu a esquecer, todos os meus dados já eram. Portanto, ao implementar cifragem de disco, escolha muito bem a sua frase-senha e não a esqueça!

  • Particionamento: Não vi razão para usar tabelas de partição estáticas tradicionais; elas são inflexíveis, pois não podem ser mudadas dinamicamente a posteriori. Já o [[http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)Gerenciador de Volumes Lógicos (LVM) do Linux permite que a gente mude os tamanhos e até posição física dos volumes, muitas vezes sem sequer ser necessário desmontar os sistemas de arquivos, com as aplicações rodando e tudo.

Eu considerei e rejeitei a possibilidade de omitir o LVM em absoluto. Isso me deixaria com um único sistema de arquivos de tamanho fixo; ou seja, se eu mudasse de idéia posteriormente quanto ao sistema de arquivos que queria usar, eu teria de desmontar e remontar tudo. Factível, mas trabalhoso. Além disso, uma das coisas que eu pretendo fazer com o NASDEC é usá-lo como plataforma para avaliar as características de diferentes sistemas de arquivos. Pra mim, esse foi o ponto decisivo para justificar a inclusão do LVM.
Outra possibilidade teria sido criar uma partição para ser cifrada e outra normal, para os casos em que eu precisasse do desempenho máximo do disco, desobstruído pela sobrecarga imposta pela cifragem/decifragem. Sob um certo ponto de vista, impor a cifragem em tudo pode ser encarado como uma falta de flexibilidade no projeto. Mas optei por essa solução exatamente porque, se não há áreas não cifradas, não há como eu, por alguma desatenção, acabar salvando dados confidenciais em algum lugar não-cifrado1. Também não há como ter uma área de swap sem ser cifrada.

  • Sistemas de Arquivos e Redundância Dissimilar do Software: Eu queria usar o novíssimo BTRFS, principalmente por causa do recurso de snapshots ultra-leves que ele oferece. Todavia, o BTRFS ainda não está "pronto". Apesar de eu conhecer gente que já o usa sem incidentes há anos, também já ouvi histórias de horror de gente que perdeu seus dados com ele. Por isso, optei por usar o BTRFS na máquina monkey e o tradicionalíssimo JFS na máquina dinky. O JFS é considerado talvez o mais estável e "à prova de bala" dentre os sistemas de arquivos para Linux.

O conteúdo dos dois sistemas de arquivos serão espelhados em tempo real pelo sistema de replicação automática de arquivos do GlusterFS. Assim, bugs ou corrupções causadas por quedas de energia afetarão os dois de forma diferente (e lembre-se que a máquina monkey está ligada em um UPS), minimizando as chances de "dupla falha idêntica" e maximizando as chances de recuperação, ou de que uma das réplicas sobreviva intacta.
Usar o BTRFS cria algumas outras potenciais encrencas que, se por um lado não deverão ser catastróficas, por outro precisamos estar cientes delas: o conceito de 'espaço livre' o BTRFS é diferente do dos sistemas de arquivos convencionais, tal como o JFS. Pode ser que o BTRFS encha (digamos, porque eu criei vários snapshots) enquanto ainda há espaço vazio no JFS. Ainda não sei o que o GlusterFS vai achar disso, mas vou fazer uns testes e reporto sobre isso em um artigo futuro.
Por causa disso, se você estiver querendo criar seu próprio NASDEC, eu recomendo usar sistemas de arquivos convencionais: digamos, o JFS em uma máquina e o XFS em outra. Mas mesmo assim um deles pode encher antes do outro, devido a diferenças nos tamanhos das tabelas internas. O melhor é evitar que os sistemas de arquivos encham – o que não deve ser difícil, pois todos eles suportam crescimento online.
Note que há pelo menos duas camadas aqui que são idênticas e, por isso, não gozam dos benefícios da "redundância dissimilar": o LVM e o device-mapper, cujo componente dm_crypt é o responsável pela cifragem de disco em tempo real. Todavia, eu uso o LVM há mais de dez anos em dezenas de máquinas e nunca tive problemas com ele.

  • Solução de Cifragem de Disco: No mundo do Linux, há pelo menos duas: o TrueCrypt e o dm-crypt. O TrueCrypt talvez seja mais famoso, até por ser multiplataforma, roda também no Windows e que ganhou fama extra por ter sido instrumental para evitar que os dados do Daniel Dantas fossem decodificados pela Polícia Federal. Porém, preferi o dm-crypt porque ele já vem embutido no kernel, quando corretamente usado é bastante seguro, é mais simples de usar e, acima de tudo, mais simples de modificar – para extrair o máximo de desempenho do anêmico processador Atom do NASDEC, precisaremos fazer umas modificações no seu código-fonte.

  • GlusterFS vs DRBD vs outros: Há diversas soluções para fazer filesystems de rede com redundância e escalabilidade. Nós aqui na Tempest temos anos de experiência com o DRBD, que faz uma espécie de RAID1 via rede: cria-se dois dispositivos de bloco do mesmo tamanho em duas máquinas conectadas via rede e o DRBD se encarrega de mantê-los sincronizados em tempo real. Você pode colocar qualquer filesystem por sobre o dispositivo criado pelo DRBD (muito embora ele normalmente só fique montado em uma das máquinas). O DRBD cuida automaticamente de todos os cenários de "failover": se uma máquina cair, a outra compensa automática e transparentemente, sem necessidade de intervenção. Ao longo dos anos, a estabilidade do DRBD não cansa de me impressionar: nunca tivemos um único problema sequer com ele, e ele rotineiramente nos salva de enrascadas.

Todavia, o DRBD é feito para funcionar apenas entre duas máquinas, e só escala até o ponto que cada máquina individual pode suportar. Além disso, como se trata de replicação do dispositivo de bloco, só há um filesystem: se ele for corrompido, a corrupção tende a ser espelhada também. Isso fere o princípio da reundância dissimilar que eu tenho tentado seguir.
Por isso, para essa solução resolvi sair da minha zona de conforto e experimentar o GlusterFS para fazer o componente principal do subsistema de armazenamento. Ele é um "stacked filesystem", um sistema de arquivos por sobre um outro sistema de arquivos previamente existente. Para os da "velha guarda", ele lembra vagamente o NFS, mas com um protocolo de rede nativamente baseado em TCP (ao invés do problemático RPC usado pelo NFS). Ele consegue a façanha de ser ainda mais simples de montar e de usar que o DRBD, e escala tanto verticalmente quanto horizontalmente (é possível adicionar máquinas ao cluster indefinidamente).
Em tese, dá para usar apenas o GlusterFS e eu vou demonstrar como fazer isso. Mas há outra variante mais sofisticada que usa tanto o GlusterFS e o DRBD simultaneamente, que, como veremos, oferece algumas vantagens.

Esboço dos Próximos Passos

O leitor atento talvez tenha notado que hoje eu falei muito pouco sobre "backup" – essencial para prover segurança contra catástrofes tipo incêndio, raios, inundações, quedas de meteoros, etc. Há uma razão pra isso: eu ainda estou testando várias alternativas e não me decidi ainda entre elas. Resolvi não atrasar mais esse artigo por causa disso e abordar o assunto depois.

No próximo artigo desta série, vamos finalmente "colocar a mão na massa": vou mostrar exatamente como montei o kernel e como configurei a cifragem em tempo real, com especial detalhe à magia negra necessária para dar boa velocidade mesmo no Atom. O artigo seguinte tratará da configuração do LVM e do GlusterFS.



1 Na realidade, os dados no cartão MicroSD que contém o sistema operacional não estão cifrados. Isso significa que quando eu estiver dando manutenção na máquina, digamos, na linha de comando via SSH, esse é um erro que eu ainda posso cometer. Mas não há como cometer esse erro se usando o filesystem remoto via rede. [ voltar ]

Partes anteriores

Próximas partes

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.
Robson | 2014-07-13 18:19:15 | permalink | topo

Kiko...parabens pelo artigo....espero que tenha continuacao..rsrs

Eu nao consegui achar a area de onde poderia fazer o download da distro usada aqui no nasdec...poderia me passar o link ? obrigado

Marco Carnut | 2011-07-08 12:42:20 | permalink | topo

Pedro!,

O artigo sobre o LVM na Wikipedia (cujo link eu inclusive coloquei no artigo) dá uma boa visão geral. Procure no Google por "LVM howto" e "lvm oreilly", você vai achar vários artigos e tutoriais sobre ele. Esse artiguinho é bem simples, direto e didático, muito embora não fale sobre snapshots, que é um dos recursos mais legais do LVM.

Os artigos da Wikipedia sobre XFS, JFS, BTRFS, etc. também são úteis para obter uma primeira visão geral sobre os recursos que cada um oferece. O Phoronix tem trocentos benchmarks e comparativos de um em relação ao outro.

O artigo da Wikipedia sobre o dm-crypt dá uma boa primeira visão geral, mas é parco nos detalhes. Muito do que eu aprendi sobre ele foi lendo artigos na Linux Weekly News e lendo o código-fonte. :)

Mas lembre-se: nada melhor do que testar! Ponha tudo isso em prática e aprenderá muito.

Divirta-se!

-K.

Pedro! | 2011-07-08 01:12:14 | permalink | topo

Kiko, Esse seu post me levanta uma série de questionamentos sobre questões básicas de armazenamento. Você pode citar bons artigos que tratem de temas como LVM, (XFS vs JFS vs extN vs reiserfs vs...), funcionamento de cifragem direta de disco como a usada por você, enfim as referencias para os dados por você citado.

Rafael Silva (rfdslabs) | 2011-07-07 23:02:28 | permalink | topo

Muito massa Kiko! Acompanhando....