O Efeito Jurassic Park

“Se me permitem… Hum, vou lhes dizer qual é o problema com o poder científico que vocês estão usando aqui: não foi preciso disciplina alguma para alcançá-lo. Vocês leram o que outros haviam feito e deram o passo seguinte. Vocês não conquistaram o conhecimento por si mesmos, então não assumem responsabilidade alguma por ele. Vocês se apoiaram nos ombros de gênios para realizar algo o mais rápido que puderam e, antes mesmo de saberem o que tinham em mãos, já patentearam, embalaram, estamparam numa lancheira de plástico e agora …” – Dr. Ian Malcolm, Jurassic Park

Ao analisar a construção de um servidor de armazenamento ou NAS, há uma sensação comum de que o que se precisa é de um “sistema operacional NAS”. Essa é uma reação estranha, a meu ver, já que o termo NAS não significa nada além de um “servidor de arquivos com uma interface de armazenamento dedicada”. Ou, em outras palavras, apenas um servidor de arquivos com funcionalidade exposta de forma limitada. A razão pela qual escolhemos appliances NAS físicos é o suporte integrado e, às vezes, alguma funcionalidade especial e proprietária (a NetApp é um exemplo importante disso, oferecendo ampla integração SMB e NFS e algumas opções de RAID e sistema de arquivos realmente exclusivas, ou a Exablox, que oferece armazenamento de arquivos com escalabilidade horizontal totalmente gerenciado e proteção no estilo RAIN). Usar um NAS para substituir um servidor de arquivos tradicional é, em grande parte, um fenômeno relativamente recente e que, segundo tenho observado, muitas vezes é movido por equívocos ou pela impressão de que gerenciar um servidor de arquivos, uma das cargas de trabalho mais básicas de TI, é algo especial ou difícil. Servidores de arquivos costumam ser considerados a forma mais básica de servidor e, tradicionalmente, era o que as pessoas queriam dizer ao usar o termo servidor, a menos que uma descrição adicional fosse acrescentada, sendo também a única forma comumente integrada ao desktop (todo desktop Mac, Windows e Linux pode funcionar como servidor de arquivos, e é muito comum fazer isso).

É claro que não há nada de errado em recorrer a um NAS em vez de um servidor de arquivos tradicional para atender às suas necessidades de armazenamento, especialmente porque algumas opções modernas de NAS, como a Exablox, oferecem escalabilidade horizontal e opções de armazenamento que não estão disponíveis na maioria dos sistemas operacionais. Mas parece que a tendência de usar um NAS em vez de um servidor de arquivos levou a um comportamento estranho quando profissionais de TI voltam a considerar servidores de arquivos novamente. Um efeito em cascata, suspeito, em que as razões pelas quais o NAS às vezes é preferido e o raciocínio em nível de objetivo se perdem, restando a ideia de que “eu deveria ter um NAS”, de modo que, ao voltar a avaliar opções de servidor de arquivos, existe um impulso de “ter um NAS” independentemente de haver ou não uma razão lógica para sentir que isso é necessário.

Primeiro, devemos considerar que o conceito geral de um NAS é simples: pegar um servidor de arquivos tradicional, simplificá-lo removendo opções e empacotá-lo com todo o hardware necessário para criar um appliance simplificado, com todo o suporte incluído, da interface até os discos giratórios e tudo o que há entre eles. O armazenamento pode ser complicado quando os usuários precisam determinar níveis de RAID, tipos de disco, monitorar de forma eficaz etc. Um NAS resolve isso integrando o hardware à plataforma. Isso torna as coisas simples, mas pode acrescentar risco, já que você tem menos opções de suporte e menos capacidade de consertar ou substituir coisas por conta própria. A migração de um servidor de arquivos para um appliance NAS diz respeito, quase exclusivamente, ao suporte e, em geral, representa um comprometimento muito forte com um único fornecedor. Você escolheu a abordagem NAS porque quer depender de um fornecedor para tudo.

Quando passamos para um servidor de arquivos, seguimos na direção oposta. Um servidor de arquivos é um servidor corporativo tradicional como qualquer outro. Você compra o hardware do servidor de um fornecedor (HP, Dell, IBM etc.) e o sistema operacional de outro (Microsoft, Red Hat, Suse etc.). Você especifica as peças e a configuração de que precisa e tem o modelo de computação mais comum de toda a TI. Com esse modelo, em geral você usa peças padronizadas, de prateleira, o que permite migrar facilmente entre fornecedores de hardware e entre fornecedores de software. Você tem opções de “redundância de fornecedor” e, em geral, tudo é feito por meio de protocolos abertos e padronizados. Você obtém grande flexibilidade e pode gerenciar e monitorar seu servidor de arquivos exatamente como qualquer outro integrante da sua frota de servidores, inclusive mantendo-o completamente virtualizado. Você abre mão da integração vertical do NAS em troca de flexibilidade e padronização horizontais.

O estranho, portanto, é quando se retorna ao modelo de prateleira, mas se busca o que é coloquialmente conhecido como um SO NAS. Exemplos comuns disso incluem NAS4Free, FreeNAS e OpenFiler. Essa categoria de produtos geralmente nada mais é do que um sistema operacional padrão (frequentemente o FreeBSD, por ter um licenciamento ideal, ou o Linux, por ser bem conhecido) com uma “interface de armazenamento” aplicada sobre ele e nenhuma funcionalidade especial ou adicional que não existiria com o sistema operacional normal. Em tese, são um sistema operacional de “função única” que faz apenas uma coisa. Mas isso não é a realidade. São sistemas operacionais de propósito geral com uma camada extra de gerenciamento via GUI adicionada por cima. Poder-se-ia dizer o mesmo da maioria dos próprios produtos NAS físicos, mas esses normalmente incluem engenharia personalizada até mesmo no nível de armazenamento, recursos especiais e, mais importante, uma pilha de suporte integrada e um verdadeiro isolamento da “generalidade” do SO subjacente. Um “SO NAS” não é uma versão mais simples de um SO de propósito geral; é uma versão mais complexa, porém menos funcional, dele.

O que é ainda mais estranho é que os SOs gerais, com raras exceções, já vêm com interfaces de armazenamento muito simples, extremamente bem conhecidas e totalmente suportadas. Quase todas as variantes de servidores Windows ou Linux, por exemplo, incluem há muito tempo interfaces gráficas simples para essas funções. Essas GUIs incluídas costumam ser rejeitadas pelos administradores de sistemas por serem “pesadas e desnecessárias” demais para um simples servidor de arquivos. Por isso, é ainda mais incomum que adicionar uma GUI de terceiros, que não é corrigida e testada pela equipe do SO e não é conhecida e suportada de forma padrão, passe a ser desejada, já que isso vai contra os ideais e práticas comuns de uso de um servidor.

E é aqui que entra o efeito Jurassic Park – os fornecedores de SO (Red Hat, Microsoft, Oracle, FreeBSD, Suse, Canonical et al.) são gigantes com equipes de engenharia incríveis, revisão de código, testes, supervisão e ecossistemas de suporte corporativo. Já os fornecedores de “SO NAS” costumam ser empresas muito pequenas, algumas com apenas uma pessoa em tempo parcial, que se apoiam nos ombros desses gigantes e constroem algo que sabiam que podiam, mas nunca pararam para se perguntar se deviam. Os produtos resultantes são totalmente negativos em comparação com suas contrapartes de SO puro: não tornam o gerenciamento de sistemas mais fácil, nem preenchem uma lacuna na oferta de serviços do mercado. Armazenamento sólido, confiável e fácil de usar já está disponível; não são necessários mais fornecedores para preencher esse espaço no mercado.

A lógica frequentemente aplicada ao analisar um SO NAS é a de que eles são “fáceis de configurar”. Isso pode ou não ser verdade, pois “fácil”, aqui, precisa ser um termo relacional. Para que haja qualquer valor, um SO NAS tem que ser fácil em comparação com a versão padrão do mesmo sistema operacional. Assim, no caso do FreeNAS, isso significaria o FreeBSD. O FreeNAS precisaria ser sensivelmente mais fácil de configurar do que o FreeBSD para as mesmas funções dedicadas. E isso é facilmente verdadeiro: configurar um SO NAS costuma ser bastante fácil. Mas essa facilidade é apenas um paliativo, do qual os profissionais de TI precisam estar bem cientes. Tornar algo fácil de configurar não é uma prioridade em TI; tornar algo fácil de operar e reparar quando há problemas é o que importa. Fácil de configurar é bom, mas, se isso vem ao custo de não compreender como o sistema está configurado e torna os reparos operacionais mais difíceis, é uma coisa muito, muito ruim. Os produtos de SO NAS rotineiramente tornam perigosamente fácil colocar um produto em produção para uma função de armazenamento – que quase sempre é a função mais crítica, ou quase a mais crítica, de qualquer servidor em um ambiente – sem que a TI tenha experiência ou, provavelmente, competência para manter, operar e, mais importante, consertar quando algo dá errado. Precisamos exatamente do oposto: um sistema fácil de operar e consertar. É isso que importa. Então temos um segundo caso de “apoiar-se nos ombros de gigantes” e construir um sistema que sabíamos que podíamos, mas não sabíamos se deveríamos.

O que agrava esse problema é que as próprias pessoas que sentem necessidade de recorrer a um SO NAS para “tornar o armazenamento fácil” são, pela própria natureza do SO NAS, exatamente aquelas para quem o suporte operacional e o reparo do sistema são mais difíceis. Administradores de sistemas que se sentem à vontade com o SO subjacente naturalmente não veriam um SO NAS como um benefício e o evitariam, na maior parte dos casos. São, de modo singular, as pessoas para quem é mais perigoso operar uma plataforma de armazenamento que não compreendem plenamente que têm maior probabilidade de tentar usá-la. E, é claro, a maioria dos fornecedores de SO NAS ganha dinheiro, como poderíamos prever, com chamados de suporte pós-instalação de clientes que implantaram e ficaram presos uma vez em produção, de modo que ficam à mercê dos fornecedores por preços exorbitantes de suporte. É do interesse dos fornecedores torná-lo fácil de instalar e difícil de consertar. Tudo está jogando contra o profissional de TI aqui.

Se tomarmos um exemplo comum e analisarmos o FreeNAS, podemos ver como esse é um péssimo alinhamento de “dificuldades”. O FreeNAS é o FreeBSD com uma interface adicional por cima. Tudo o que o FreeNAS pode fazer, o FreeBSD pode fazer. Não há perda de funcionalidade ao migrar para o FreeBSD. Quando algo falha, em qualquer um dos casos, o administrador de sistemas precisa ter um bom conhecimento prático de FreeBSD para efetuar os reparos. Não há como escapar disso. O conhecimento de FreeBSD é comum no setor, e obter ajuda externa é relativamente fácil. Usar o FreeNAS acrescenta várias complicações, sendo a maior delas o fato de que todas e quaisquer personalizações feitas pela GUI do FreeNAS são conhecimentos específicos necessários para a solução de problemas além do conhecimento já necessário para operar o FreeBSD. Portanto, é um conjunto de conhecimentos amplo, além de mais coisas que podem falhar. É também um conjunto de conhecimentos relativamente incomum, já que o FreeNAS é um produto de armazenamento de nicho de um pequeno fornecedor e o FreeBSD é uma grande plataforma corporativa de TI (além de todo uso de FreeNAS ser uso de FreeBSD, mas apenas uma pequena porcentagem do uso de FreeBSD ser FreeNAS). Assim, podemos ver que usar um SO NAS apenas acrescenta risco repetidamente.

Esse mesmo problema se estende às comunidades que se formam em torno desses produtos. Se você recorrer às comunidades em torno do FreeBSD, Linux ou Windows em busca de orientação e ajuda, você lida com grandes números de profissionais de TI, administradores de sistemas habilidosos e pessoas com experiência empresarial e corporativa. É claro que hobistas, leigos e outros também participam, mas essas são as plataformas corporativas de TI, e todo o conhecimento do setor está disponível para você ao implementar esses produtos. Compare isso com a comunidade de um SO NAS. Por sua própria natureza, apenas pessoas com dificuldades na administração de um sistema operacional padrão e/ou nos fundamentos de armazenamento olhariam para um pacote de SO NAS, e isso naturalmente filtra a participação em suas comunidades para incluir apenas as pessoas das quais seria melhor evitar receber conselhos. Isso cria uma cultura isolada de desinformação e mal-entendidos em torno do armazenamento e dos produtos de armazenamento. Mitos abundam, a orientação muitas vezes se torna imprudente e perigosa, e as melhores práticas do setor são ignoradas como se décadas de experiência acumulada nunca tivessem acontecido.

Um SO NAS também, comumente, introduz atrasos em correções e atualizações. Um SO NAS quase sempre, e quase necessariamente, ficará atrás de seu SO de origem em atualizações de segurança e estabilidade e, muito frequentemente, ficará meses ou anos atrás em recursos importantes. Em um cenário muito conhecido, o OpenFiler, o produto foi construído sobre uma base upstream não corporativa (RPath Linux) que carecia de suporte da comunidade e do fornecedor, fracassou e foi abandonada, deixando os usuários downstream, incluindo todos no OpenFiler, abandonados sem o ecossistema necessário para apoiá-los. Usar um SO NAS significa confiar não apenas no grande, corporativo e bem conhecido fornecedor de SO primário que faz o SO base, mas também confiar no fornecedor do SO NAS. E o fornecedor do SO NAS é ordens de magnitude mais propenso a fracassar do que os fornecedores que baseiam seus produtos em SOs base de classe corporativa.

O armazenamento é uma função crítica e não deve ser tratado de forma descuidada nem ignorado como se sua criticidade não existisse. Os SOs NAS nos tentam a instalar rapidamente e esquecer, na esperança de que nada dê errado ou de que possamos seguir para outras funções ou empresas por completo antes que coisas ruins aconteçam. Isso nos prepara para o fracasso onde o fracasso é mais impactante. Quando um servidor de aplicação típico falha, sempre podemos copiar os arquivos de seu armazenamento e começar do zero. Quando o armazenamento falha, dados são perdidos e sistemas saem do ar.

“John Hammond: Todos os grandes parques temáticos têm atrasos. Quando inauguraram a Disneylândia em 1956, nada funcionava!

Dr. Ian Malcolm: Sim, mas, John, se Piratas do Caribe quebrar, os piratas não comem os turistas.”

Quando o armazenamento falha, as empresas falham. Tomar o caminho fácil para configurar o armazenamento e ignorar as necessidades de suporte de longo prazo, buscando conselhos em comunidades que filtraram os engenheiros experientes de armazenamento e sistemas, aumenta drasticamente o risco. Infelizmente, a natureza de um SO NAS é tal que a própria razão pela qual as pessoas recorrem a ele (falta de conhecimento técnico profundo para construir os sistemas) é a própria razão pela qual devem evitá-lo (necessidade ainda maior de suporte). As pessoas para quem os SOs NAS são efetivamente seguros de usar, aquelas com conhecimento de armazenamento e sistemas muito profundo e amplo, raramente considerariam esses produtos, porque para elas não oferecem benefício algum.

No fim das contas, embora o conceito de um SO NAS pareça maravilhoso, ele não é uma panaceia, e o valor de um NAS não se transfere do mundo dos appliances físicos para o mundo do SO instalado, e o valor dos SOs padrão é grande demais para que os SOs NAS consigam, efetivamente, agregar valor real.

“Dr. Alan Grant: Hammond, após alguma reflexão, decidi não endossar o seu parque.

John Hammond: Eu também.”