NASDEC: Terabytes pra além de Dez Anos: Conceituação e Requisitos

Como garantir que daqui a dez anos eu ainda tenha meus dados? É difícil negar que o mundo digital esteja tornando as lembranças efêmeras. Geramos uma quantidade absurda de dados, mas também perdemos outro tanto. Entre HDs pifados, cartões de memória perdidos, migrações de disquete pra pendrive, de HD PATA para SATA, surpreendentemente pouco sobra. Em contraste, meus pais ainda têm as fotos de quando eu nasci. Será que eu terei o mesmo pra mostrar aos meus filhos daqui a algumas décadas?

No plano profissional, será que ainda terei o código fonte que escrevi, artigos que não terminei, os contratos (digitais e digitalizados) que assinei e outras coisas de que poderei precisar? Enfim, como preservar nossas memórias a longo prazo usando tecnologias de uma indústria cujo modelo de negócio é lastreado na obsolescência programada, que se reeinventa e se reencarna numa escala de tempo de meses?

Este é o primeiro de uma série de posts sobre um projeto de longo prazo em que estou embarcando para tratar exatamente esse aspecto ainda pouco discutido de segurança de sistemas de informação: preservação de dados digitais por longos períodos de tempo. Na realidade, bibliotecas, cartórios, historiadores, museus e até o Vaticano (difícil pensar em uma instituição com mais tradição em preservação de documentos ao longo dos séculos) já vêm pensando nisso há um bom tempo. Mas ainda há muita gente que não atentou para esse detalhe.

Especificamente, pretendo documentar o projeto e implementação de uma solução de NAS (Network Attached Storage) e infra de backup associada que resultará em um custo de aquisição menor que R$ 1 por gigabyte armazenado, capacidade inicial de 3 terabytes (vislumbro exceder os 15TB daqui a dez anos) e com todas as características de disponibilidade e resistência a manutenção necessárias para exceder um tempo de vida útil de 10 anos, usando apenas componentes comuns "de prateleira" e 100% em software livre.

Esse valor pode parecer caríssimo quando hoje em dia temos ofertas de disco rígido resultando em dez centavos por gigabyte. Mas aí cabem algumas perguntas: e se ele pifar? E se você o perder (no caso de um disco portátil) ou ele for roubado? E que certeza você tem que ele ainda vai estar funcionando daqui a dez anos? Ou que ainda se usará eSATA ou USB daqui a dez anos? Além disso, seu HD não funciona sozinho – ele precisa de um computador, cujo custo precisa entrar na conta. E por aí vai. A diferença entre os R$ 0,10/GB e os R$ 1/GB se manifestará nas diversas garantias que a solução dará.

De fato, eu estou fazendo dois desses: um pra mim, no meu "home office" e outro para a Tempest – que, por sinal, já tem vários. Alguns deles rodam bem há mais de 4 anos, mas os requesitos de projeto deles eram diferentes, focando em disponibilidade, desempenho e outros. Esse é o primeiro que tem a longevidade como requisito primário. Por isso, nós o batizamos de "nasdec" (o NAS para uma década).

Para tornar essa série de artigos acessível a uma audência ampla, eu o escrevi com um mote de "aplicação doméstica pessoal/residencial" ou SOHO ("small office/home office"), mas, como vou mostrar, os mesmos princípios básicos podem ser aplicados para "soluções empresariais" ou "institucionais" de grande porte, sendo possível escalar trivialmente a solução (ainda que com outros parâmetros de custo) para capacidades de ordem de petabytes. Tenciono documentar tudo em detalhes suficientes para que o leitor tecnicamente inclinado consiga reproduzir meus passos e montar seu próprio NASDEC.

Reflexões Iniciais e Requisitos Preliminares

Nos meus arquivos pessoais, eu até tenho um bom punhado de dados digitais de mais de dez anos atrás – código fonte, textos do Word, fotos, etc. Eu ainda tenho a coleção de MP3 exata que eu estava ouvindo no meu primeiro dia de trabalho no grupo acadêmico da UFPE que viria a dar origem à Tempest, em 1998. Mas também sei que, entre discos rígidos pifados, diversas trocas de notebook e outras intempéries, perdi muita coisa que eu ainda gostaria de ter.

Algumas vezes isso me forçou a dezenas de horas de retrabalho pra recriar uma solução que eu já tinha feito e testado, mas tinha perdido. Outras vezes a obsolescência tecnológica também me causou muita trabalheira: uns meses atrás precisei recuperar um trabalho tão antigo que estava em disquetes de 5 e 1/4 polegadas – muita gente das gerações mais novas nunca sequer viu um. Imagine o inferno que foi achar quem ainda tivesse um drive de 5 e 1/4 funcionando.

O fato é que foi por sorte, e não por intenção, esses dados terem sobrevivido até hoje. Isso então dita a minha prioridade no projeto da minha solução: por projeto, deverá ser possível recuperar a totalidade (ou próximo disso) dos dados mesmo mais de uma década no futuro. Na minha notação de "seguro contra o que", podemos qualificar como um tipo de "segurança contra indisponibilidade futura".

A técnica básica para se obter esse requisito é a redundância: termos múltiplas cópias dos dados armazenados em diferentes meios físicos. Como no velho ditado "não ponha todos os seus ovos em uma cesta só", devemos estar preparados para o fato que alguma das nossas "cestas" (discos rígidos, DVDs e outros meios de armazenamento) serão perdidas. De fato, devemos esperar de antemão que alguma perda fatalmente acontecerá em algum ponto no futuro e devemos ter uma série de "planos B" para essas eventualidades.

Meus leitores assíduos sabem que eu vivo dizendo que não é bem verdade que "segurança é prioridade". Segurança é uma prioridade e em geral nem é a primeira. O custo é que costuma estar no topo da lista de prioridades. Conveniência de operação também. De nada adianta a solução ser super segura se ela for excessivamente cara e inconveniente.

Exemplo: imagine que eu, querendo começar com uma capacidade de 3TB, compre 20 HDs USB de 1,5TB, que uma loja aqui de Recife me fornece por R$ 332,00 a unidade. Isso custaria R$ 6.640,00, mas eu poderia ter dez cópias de tudo e poderia guardá-los em diferentes lugares – na casa de parentes, em cofre de banco, quem sabe enterrar um no quintal ou colocar debaixo do colchão. É difícil negar que esse sistema seria bem seguro: eu teria de perder (pifar, quebrar, ser calcinado em um incêndio, ou alguns dos que os guardam se recusarem a me devolvê-los) dez HDs simultaneamente para que eu perdesse algum dado. Só que dá pra fazer o mesmo de forma muito mais barata e é muito inconveniente – eu teria de recolher cada um dos dez pra atualizar ou me contentar com o fato que eu teria várias versões desatualizadas, o que seria um pesadelo pra gerenciar.

O difícil, e que é a arte da coisa, é exatamente obter um bom balanceamento dos requisitos de segurança versus custo e conveniência. Na minha lista de requisitos, quero tentar chegar a um "custo de aquisição" de menos de R$ 1 por gigabyte e um TCO ("total cost of ownership", ou "custo total de posse"), que inclui o custo de operação ao longo de todo o tempo de vida útil não muito maior que R$ 2/GB (o que basicamente quer dizer que eu não quero gastar na operação e manutenção ao longo de dez anos muito mais do que gastei na aquisição.)

Além dos requisitos de custo, há os de conveniência: a operação no dia-a-dia deve ser fácil, a manutenção e os upgrades não devem ser nem caros nem difíceis (em um sistema projetado para viver uma década, manutenção parece inevitável, sobretudo se usando componentes "de prateleira", de qualidade fora do nosso controle), deve-se tentar evitar armadilhas de obsolescência tecnológica (sistemas exóticos que tenderão a se tornar obsoletos e incompatíveis), e ele deve dar excelente disponibilidade, maior do que 99,99%.

Do quesito de conveniência decorre que eu quero que a solução seja primariamente on-line, na forma de um serviço de rede que eu possa acessar pelas redes locais (cabeada ou sem fio) e, quiçá, até pela Internet. Esse requisito implica que, na realidade, o que nós vamos fazer é algo parecido com o que se convencionou chamar de NAS (Network Attached Storage).

Há que se perguntar se 99,99% de disponibilidade é realmente necessário em um serviço desse tipo, sobretudo na versão "pessoal" que estou construindo em casa. O leitor talvez ache que não, mas, eu lembro de várias vezes no passado em que eu tive de desligar a máquina "servidora de arquivos" lá de casa para algum reparo e meus usuários domésticos inventaram de usar justamente naquele momento, o que me fez ter de aturar aquelas clássicas gracinhas de que a informática nunca está disponível quando a gente precisa dela. E aqui na Tempest, com mais de 50 pessoas e turnos de 24x7, não há dúvida que alta disponibilidade é imprescindível.

Uma consequência desse requisito é a necessidade de considerar as diversas possibilidades de falha: ventiladores pararem, fonte morrer, CPU sobreaquecer, armazenamento primário (discos rígidos e de estado sólido) pifarem, placa-mãe travar, faltas de energia elétrica e muitos outros detalhes insidiosos que vão nos levar em uma viagem fascinante sobre um tema cercado de mitos: como e com que frequência os sistemas eletrônicos falham. Além disso, não se pode deixar de considerar a possibilidade que haja um incêndio ou semelhante calamidade. É preciso ter "planos B", "C", "D", etc., previamente concebidos e de prontidão para cada uma dessas contingências.

Uma questão interessante vai ser equilibrar a conveniência com a segurança contra calamidades. Uma maneira de evitar calamidades é ter um backup offline em outro lugar, mas, justamente por serem offline e realizados manualmente, eles dão uma trabalheira.

Outro detalhe que não pode ser esquecido é a obsolescência tecnológica. Exemplo: hoje as principais interfaces para armazenamento de alta capacidade são SATA e SAS. Será que daqui a alguns anos, quando formos acrescentar mais capacidade, ainda serão? E se não forem? Joga-se tudo fora e faz tudo do zero? Ou há algum meio de fazer uma migração suave?

Como tudo que a gente faz aqui na Tempest, temos de levar em consideração também a segurança contra omissões técnicas: naturalmente, o sistema não deve ser fácil de invadir, o que significa basicamente usar uma pilha de software minimalista e de "bom pedigree", com histórico baixo (de preferência zero) de vulnerabilidades conhecidas. Isso também significa usar todos os truques tradicionais de blindagem e compartimentalização, que vou tratar em detalhes em um futuro post. É claro que o nasdec vai estar protegido pelo meu firewall de borda, mas lembre-se que eu me reservei a opção de torná-lo acessível via Internet.

Além disso, como é bem provável que mesmo no meu NAS pessoal eu venha a ter cópias de material confidencial da Tempest e/ou de clientes meus, é imperativo que o sistema resista mesmo se roubado – o que basicamente significa que todos os dados deverão ser armazenados cifrados. Ou seja, esse é um dos tipos de segurança contra acesso indevido para o qual precisamos atentar.

Nesse caldeirão de quesitos conflitantes, quem vai acabar por último na escala de prioridades (e, por isso, vai sofrer um pouco) é o desempenho. Lógico que precisamos que ele seja, no mínimo, decente e, idealmente, o melhor possível – nada adianta fazermos isso tudo se a solução for tão lerda que não dá pra usar. Vou mostrar que dá pra atingir um resultado muito decente, mas sabemos logo de saída que dificilmente vamos ganhar algum benchmark.

Uma Boa Idéia do Que Queremos

Não sei se vocês notaram, mas na discussão sobre requisitos acima, acabamos fazendo uma versão informal do "modelo de ameaça". Conseguimos delinear, ainda que grosseiramente, o "seguro contra o que", a lista de coisas que queremos que não aconteçam. Vou reformulá-la aqui para deixar mais claro e explícito:

  • não queremos perder quantidades significativas de dados antes de pelo menos dez anos (e de preferência por mais tempo que isso);
  • não queremos perder dados nem em caso de catástrofes naturais;
  • não queremos que ninguém possa acessar os dados mesmo se todo o sistema for roubado;
  • não queremos perder dados por causa de falhas dos diversos componentes eletrônicos, sobretudo os de armazenagem de dados;
  • não queremos deixar de usar o sistema por causa de faltas de luz;
  • não queremos que o sistema pare durante manutenções;
  • não queremos perder dados por causa de erros bobos de operação, nem tampouco por causa de bugs na pilha de software;
  • não queremos que a solução arruine nossas finanças;
  • não queremos que o sistema seja tão lento a ponto de se tornar pouco prático.

Enfim, já temos pelo menos uma boa idéia do que queremos – e é uma lista de requisitos razoavelmente ambiciosa. No próximo post, vou detalhar a configuração do hardware, detalhando como aquela seleção particular de componentes atende aos requisitos que definimos aqui. Farei também uma análise comparativa de custos em relação a outras possíveis soluções.

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.
Marco Carnut | 2011-06-14 18:49:26 | permalink | topo

Enildo,

O que fazer com tanta informação? Puxa, dá pra fazer muita coisa. Mas o que eu posso te garantir é: tudo começa com guardá-la bem.

-K.

Enildo | 2011-06-14 15:48:55 | permalink | topo

Grande Kiko, recentemente tive um conversa com minha esposa, o que vamos fazer com tanta informação, a conversa incluiu também como guardar, ela riu quando eu disse "quem tem um, não tem nenhum", quando eu falei em comprar mais um hd externo, hehehehehe. Bom artigo, não demore muito para postar, gostei do assunto.