O Culto do ZFS

É bastante comum que os círculos de TI desenvolvam uma certa mentalidade de culto ou de “fã fanático”. O que provoca essa reação a tecnologias e produtos eu não sei ao certo, mas que isso acontece é inegável. Uma área em que eu jamais imaginei que veria isso ocorrer é a dos sistemas de arquivos – um dos componentes de sistema mais “por baixo dos panos” e um que, até recentemente, não recebia literalmente atenção alguma, mesmo em círculos razoavelmente técnicos. Sejamos francos: confundir quando algo vem do Active Directory em vez de vir do NTFS é praticamente onipresente. Os sistemas de arquivos são, muito simplesmente, ignorados. Desde o lançamento do Windows NT 4 e do NTFS como a única opção viável, a ideia de que um sistema de arquivos não é um componente intrínseco de um sistema operacional e de que poderia haver outras opções para o armazenamento de arquivos praticamente desapareceu. Isto é, até recentemente.

A única comunidade em que, até certo ponto, isso não aconteceu foi a comunidade Linux, mas mesmo ali o Ext2 e seus descendentes conquistaram a preferência de forma tão completa que, embora estivessem amplamente disponíveis, os sistemas de arquivos alternativos ficaram à margem e apenas o XFS recebeu alguma atenção, historicamente, e, ainda assim, recebeu muito pouca.

Onde ocorreu um comportamento verdadeiramente estranho, mais recentemente, foi em torno do sistema de arquivos ZFS da Oracle, originalmente desenvolvido para o sistema operacional Solaris e para a plataforma de armazenamento aberto X4500 “Thumper” (originalmente sob os auspícios da Sun, antes da aquisição pela Oracle). Na época (há nove anos), quando o ZFS foi lançado, os sistemas de arquivos concorrentes estavam, em sua maioria, mal preparados para lidar com os grandes arrays de discos que se previa serem construídos ao longo dos anos seguintes. O ZFS foi projetado para lidar com eles e inaugurou a era dos sistemas de arquivos de grande escala. Como a maioria dos sistemas de arquivos daquela época, o ZFS estava limitado a um único sistema operacional e, assim, embora amplamente considerado um grande avanço no design de sistemas de arquivos, produziu poucas ondas no mundo do armazenamento e ainda menos no mundo dos “sistemas”, onde mesmo os administradores de Solaris geralmente o consideraram apenas um ponto de interesse durante bastante tempo, optando, em sua maioria, por permanecer com o consagrado e confiável UFS que vinham usando havia muitos anos.

O ZFS foi, de fato, um sistema de arquivos revolucionário e eu fui, e continuo sendo, um grande defensor dele. Mas é muito importante entender por que o ZFS fez o que fez, quais são seus objetivos, por que esses objetivos eram importantes e como ele se aplica a nós hoje. A complexidade do ZFS levou a muita confusão e a muitos mal-entendidos sobre como o sistema de arquivos funciona e quando é apropriado usá-lo.

Os principais objetivos do ZFS eram criar um sistema de arquivos capaz de escalar bem para arrays de discos muito grandes. Na época de sua introdução, a escala que o ZFS era capaz de alcançar era inédita em outros sistemas de arquivos, mas não havia uma necessidade real de que um sistema de arquivos pudesse crescer tanto. Quando a necessidade surgiu, muitos outros sistemas de arquivos, como NTFS, XFS, Ext3 e outros, já haviam escalado para atendê-la. O ZFS certamente liderou a investida rumo ao manejo de sistemas de arquivos maiores, mas foi acompanhado por muitos outros pouco tempo depois.

Como o ZFS teve origem no mundo do Solaris, onde, como em todos os grandes sistemas UNIX de porte robusto, não existe RAID por hardware, o RAID por software teve de ser usado. O Solaris sempre teve RAID por software disponível como seu próprio subsistema. Tomou-se a decisão de construir uma nova implementação de RAID por software diretamente dentro do ZFS. Isso permitiria um gerenciamento simplificado por meio de um único conjunto de ferramentas, tanto para a camada de RAID quanto para o sistema de arquivos. Isso não introduziu nenhuma mudança ou vantagem significativa ao ZFS, como muitas vezes se acredita; apenas deslocou a interface da camada de RAID por software, que deixou de ser seu próprio conjunto de comandos para passar a fazer parte do conjunto de comandos do ZFS.

A implementação de RAID do ZFS introduziu stripes de largura variável nos níveis de RAID com paridade. Essa inovação eliminou um risco menor do RAID com paridade conhecido como “buraco de gravação” (write hole). Essa inovação foi muito boa, mas chegou bem tarde, pois a era do RAID com paridade confiável começava a chegar ao fim e o problema do buraco de gravação já era considerado um risco de “ruído de fundo” não mencionado dos arrays com paridade, uma vez que geralmente não era visto como uma ameaça por ser eliminado por meio do uso de caches de array protegidos por bateria e, mais ou menos na mesma época, de caches de array não voláteis – evite a perda de energia e você evitará o buraco de gravação. O ZFS precisava abordar essa questão porque, sendo RAID por software, estava sob maior risco em relação ao buraco de gravação do que o RAID por hardware, já que não há a possibilidade de um cache protegido contra a perda de energia – o RAID por hardware oferece o potencial de uma camada adicional de proteção de energia para os arrays.

A verdadeira “inovação” que o ZFS inadvertidamente fez foi que, em vez de simplesmente implementar os habituais níveis de RAID 1, 5, 6 e 10, ele “rotulou” esses níveis com suas próprias convenções de nomenclatura. O RAID 5 passou a ser conhecido como RAIDZ. O RAID 6 passou a ser conhecido como RAIDZ2. O RAID 1 é conhecido apenas como espelhamento. E assim por diante. Isso foi amplamente considerado tolo na época e inutilmente confuso, mas, como veio a se revelar, essa confusão se tornou a pedra angular da ressurreição do ZFS muitos anos depois.

Cabe observar que o ZFS posteriormente acrescentou a primeira implementação de produção do setor de um sistema de RAID 7 (também conhecido como RAID 7.3) com tripla paridade e o rotulou de RAIDZ3. Esse acréscimo posterior é uma inovação importante para arrays de grande escala que precisam do máximo de capacidade ao mesmo tempo em que permanecem extremamente seguros, mas que estão dispostos a sacrificar o desempenho para conseguir isso. Esse continua sendo um recurso exclusivo do ZFS, mas um recurso que raramente é usado.

No espírito de comprimir a pilha de armazenamento e de usar um único conjunto de comandos para gerenciar todos os aspectos do armazenamento, as funções de gerenciamento de volumes lógicos também foram incorporadas ao ZFS. Acredita-se erroneamente, em certos círculos, que o ZFS tenha introduzido o gerenciamento de volumes lógicos, mas praticamente todas as plataformas empresariais, incluindo AIX, Linux, Windows e até o próprio Solaris, já tinham gerenciamento de volumes lógicos havia muitos anos. O ZFS não estava fazendo isso para introduzir um novo paradigma, mas simplesmente para consolidar o gerenciamento e envolver as três principais camadas de armazenamento (RAID, gerenciamento de volumes lógicos e sistema de arquivos) em uma única entidade que seria mais fácil de gerenciar e poderia proporcionar comunicações inerentes para cima e para baixo na pilha. Há prós e contras nesse método e a opinião do setor permanece indefinida quase uma década depois.

Um dos aspectos mais importantes dessa consolidação de três sistemas em um é que agora temos um produto muito confuso de discutir. O ZFS é um sistema de arquivos, sim, mas não é apenas um sistema de arquivos. É um gerenciador de volumes lógicos, mas não apenas um gerenciador de volumes lógicos. As pessoas se referem ao ZFS como um sistema de arquivos, que é sua função principal, mas o fato de ele ser muito mais do que um sistema de arquivos pode ser bastante confuso e dificulta as comparações com outros sistemas de armazenamento. Na época, acredito que essa confusão não foi prevista.

O que resultou dessa fusão confusa é que o ZFS é frequentemente comparado a outros sistemas de arquivos, como o XFS ou o Ext4. Mas isso é confuso, pois o ZFS é uma pilha completa e o XFS é apenas um aspecto de uma pilha. O ZFS seria mais bem comparado a MD (RAID por software do Linux) / LVM / XFS ou a SmartArray (RAID por hardware da HP) / LVM / XFS do que ao XFS sozinho. Caso contrário, parece que o ZFS está repleto de recursos que faltam ao XFS, mas, na realidade, trata-se apenas de uma vitória semântica. A maioria dos recursos frequentemente alardeados pelos defensores do ZFS não teve origem no ZFS e estava comumente disponível nos sistemas de arquivos alternativos muito antes de o ZFS existir. Mas é difícil comparar “o seu sistema de arquivos faz isso”, pois a resposta é “não... meu RAID ou meu gerenciador de volumes lógicos é que faz isso”. E, na verdade, não é o ZFS, o sistema de arquivos, que fornece o RAIDZ; é o ZFS, o subsistema de RAID por software, que o faz.

A fim de lidar de forma elegante com sistemas de arquivos muito grandes, recursos de integridade de dados foram incorporados ao ZFS, o que incluiu uma verificação de checksum ou hash por todo o sistema de arquivos, capaz de aproveitar o RAID por software incluído para reparar arquivos corrompidos. Isso foi visto como necessário em razão do tamanho previsto dos sistemas de arquivos ZFS no futuro. A corrupção de sistemas de arquivos é um fenômeno raramente observado, mas, à medida que os sistemas de arquivos crescem em tamanho, o risco aumenta. Esse recurso menos conhecido do ZFS é, possivelmente, o seu maior.

O ZFS também mudou a forma como as verificações de sistema de arquivos são realizadas. Devido à premissa de que o ZFS seria usado em sistemas de arquivos muito grandes, havia um temor genuíno de que uma verificação de sistema de arquivos no momento da inicialização pudesse levar um tempo impossivelmente longo para ser concluída e, assim, encontrou-se uma estratégia alternativa. Em vez de esperar para fazer uma verificação na reinicialização, o sistema exigiria a execução de um processo de scrubbing para realizar uma verificação semelhante enquanto o sistema estivesse em funcionamento. Isso exige mais sobrecarga do sistema enquanto ele está ativo, mas o sistema é capaz de se recuperar de uma reinicialização inesperada com mais rapidez. Uma troca, mas uma troca que é amplamente vista como muito positiva.

O ZFS tem poderosas capacidades de snapshot em sua camada de volumes lógicos e, em sua camada de RAID, implementou mecanismos de cache muito robustos, tornando o ZFS uma excelente escolha para muitos casos de uso. Esses recursos não são exclusivos do ZFS, mas estão amplamente disponíveis em sistemas mais antigos do que o ZFS. São, porém, implementações muito boas de cada um e muito bem integradas em razão da natureza do ZFS.

Em certa época, o ZFS era de código aberto e, durante esse período, seu código passou a fazer parte dos sistemas operacionais Mac OSX da Apple e FreeBSD, por serem compatíveis com a licença do ZFS. O Linux não obteve o ZFS naquele momento devido a desafios relacionados ao licenciamento. Se o licenciamento do ZFS tivesse permitido que o Linux o usasse sem restrições, o panorama do Linux provavelmente seria muito diferente hoje. O Mac OSX acabou por abandonar o ZFS, por não se considerar que ele tivesse vantagens suficientes para justificá-lo naquele ambiente. O FreeBSD agarrou-se ao ZFS e, com o tempo, ele se tornou o sistema de arquivos mais popular da plataforma, embora o UFS também ainda seja muito utilizado. A Oracle fechou o código-fonte do ZFS após a aquisição da Sun, deixando o FreeBSD sem atualizações contínuas para sua versão do ZFS, enquanto a Oracle continuou a desenvolver o ZFS internamente para o Solaris.

Hoje, o Solaris continua usando a implementação original do ZFS, agora com várias atualizações desde sua separação da comunidade de código aberto. O FreeBSD e outros continuaram usando o ZFS no estado em que ele se encontrava quando o código foi fechado, já não tendo acesso às atualizações mais recentes da Oracle. Por fim, o trabalho de atualizar a base de código do ZFS de código aberto abandonada foi retomado e hoje é conhecido como OpenZFS. O OpenZFS ainda é incipiente e ainda não deixou realmente sua marca, mas tem algum potencial para revitalizar a plataforma ZFS no espaço de código aberto; neste momento, porém, o OpenZFS ainda fica atrás do ZFS.

O desenvolvimento de código aberto nos últimos anos nesse espaço tem se concentrado mais no novo rival do ZFS, o BtrFS, que está sendo desenvolvido nativamente no Linux e conta com bom suporte de muitos dos principais fornecedores de sistemas operacionais. O BtrFS é muito recente, mas está fazendo grandes progressos para alcançar a paridade de recursos com o ZFS naquilo que já está implementado, embora tenha grandes aspirações e, devido à natureza de código fechado do ZFS, tenha o benefício do momento de mercado. O BtrFS foi iniciado, assim como o ZFS, pela Oracle e tem sido amplamente visto como a visão de futuro da Oracle, sendo um substituto para o ZFS até mesmo dentro da Oracle. Neste momento, o BtrFS já, assim como o ZFS, fundiu as camadas de sistema de arquivos, gerenciamento de volumes lógicos e RAID por software, implementou checksumming para a integridade do sistema de arquivos, escala ainda mais do que o ZFS (mesmo limite absoluto, mas lida com mais arquivos), snapshots por cópia na escrita (copy on write), etc.

O ZFS, sem dúvida, foi um sistema de arquivos incrível em seu apogeu e continua sendo um líder hoje. Eu fui um defensor dele em 2005 e ainda acredito fortemente nele. Mas tem me entristecido ver a comunidade em torno do ZFS adotar um fervor e um zelo fanático que não lhe prestam serviço algum e fazem com que a menção ao ZFS quase pareça algo negativo – com o ZFS sendo escolhido de forma tão universal pelos motivos errados: principalmente a crença de que seus recursos não existem em nenhum outro lugar, de que seu RAID não está sujeito aos riscos e limitações a que esses níveis de RAID estão sempre sujeitos, ou de que ele foi projetado para um propósito diferente (principalmente o desempenho) daquele para o qual realmente foi projetado. E quando o ZFS é uma boa escolha, ele é frequentemente implementado de forma deficiente, com base em premissas falsas.

O ZFS, é claro, não tem culpa. Tampouco, pelo que posso constatar, têm culpa seus apoiadores corporativos ou seus desenvolvedores de código aberto. Onde o ZFS parece ter se desviado é em uma comunidade frouxa e não oficial que só recentemente passou a conhecer o ZFS, muitas vezes acreditando que ele seja novo ou de “próxima geração” porque só recentemente o descobriu. Pelo que tenho visto, isso quase nunca ocorre por meio dos canais do Solaris ou do FreeBSD, mas quase exclusivamente por empresas menores que buscam usar um “sistema operacional de NAS” empacotado, como FreeNAS ou NAS4Free, e que não estão familiarizadas com sistemas operacionais UNIX. O uso de sistemas operacionais de NAS empacotados, principalmente por departamentos de TI que não possuem nem competências profundas em UNIX nem em armazenamento e, por consequência, pouca exposição ao mundo mais amplo dos sistemas de arquivos fora do Windows e, frequentemente, pouca ou nenhuma exposição ao gerenciamento de volumes lógicos e a RAID, especialmente RAID por software, parece levar a uma cultura de “mito” em torno do ZFS, com ele assumindo um status quase inquestionável e infalível.

Esse séquito de tipo cultuado e o mal-entendido geral sobre o ZFS frequentemente levam a aplicações inadequadas do ZFS ou a uma cadeia de tomada de decisões baseada em premissas equivocadas que pode desencaminhar profundamente uma pessoa.

Uma das mudanças mais surpreendentes nesse espaço é a mudança de preferência do RAID por hardware para o RAID por software. Tradicionalmente, o RAID por software era um pária nos círculos de administração de Windows, sem boa razão – administradores de Windows e pequenas empresas, muitas vezes não familiarizados com servidores UNIX de maior porte, acreditavam que o RAID por hardware fosse onipresente quando, na verdade, sistemas de maior escala sempre usaram RAID por software. O RAID por hardware era, em praticamente todo o setor, considerado uma necessidade, e o RAID por software, completamente rejeitado. Esse mesmo público, agora diante do movimento do “Culto do ZFS”, reage agora exatamente da maneira oposta, acreditando que o RAID por hardware é ruim e que o RAID por software do ZFS é a única opção viável. A mudança é dramática e nenhuma das duas abordagens é válida – tanto o RAID por hardware quanto o RAID por software, e ambos em muitas implementações, são opções muito válidas e, mesmo usando o ZFS, o uso de RAID por hardware poderia facilmente ser apropriado.

O ZFS é frequentemente escolhido por se acreditar que ele é a opção de mais alto desempenho em sistemas de arquivos, mas isso nunca foi um objetivo central de design do ZFS. Os recursos que lhe permitem escalar tanto e lidar com tantos aspectos diferentes do armazenamento, na verdade, tornam muito difícil ser de altíssimo desempenho. O ZFS, na época de sua criação, nem sequer se esperava que fosse tão rápido quanto o venerável UFS, que rodava nos mesmos sistemas que ele. No entanto, isso é frequentemente secundário diante do fato de que o desempenho de sistemas de arquivos é amplamente irrelevante, pois todos os sistemas de arquivos modernos são extremamente rápidos e a velocidade do sistema de arquivos raramente é um fator importante – especialmente fora de sistemas de armazenamento maciços e de ponta, em uma escala muito grande.

Um interessante estudo de dez sistemas de arquivos no Linux, produzido pela Phoronix em 2013, mostrou diferenças enormes entre os sistemas de arquivos conforme a carga de trabalho, mas nenhum vencedor claro no que diz respeito ao desempenho geral. O que o estudo mostrou de forma conclusiva é que adequar a carga de trabalho ao sistema de arquivos é a escolha mais importante, que o ZFS pende para o lado mais lento de todos os sistemas de arquivos populares, mesmo em suas implementações mais modernas, e que escolher um sistema de arquivos por motivos de desempenho sem um entendimento muito profundo da carga de trabalho resultará em um desempenho imprevisível – nenhum sistema de arquivos deve ser escolhido às cegas se o desempenho for um fator importante. Lamentavelmente, por o teste ter sido feito no Linux, faltou-lhe o UFS, que é frequentemente o principal concorrente do ZFS, especialmente no Solaris e no FreeBSD, e faltou-lhe o HFS+ do Mac OSX.

A migração do RAID por hardware para o RAID por software acarreta riscos adicionais, muitas vezes imprevistos, para os departamentos sem experiência em UNIX também. Embora o ZFS permita a troca a quente (hot swap), é frequentemente esquecido que o hot swap é primordialmente um recurso de hardware, e não de software, e também é amplamente desconhecido que a troca cega (blind swapping – a remoção de discos rígidos sem primeiro colocá-los offline no sistema operacional) não é sinônimo de troca a quente, e isso pode levar a desastres para os departamentos que migram de uma tradição de RAID por hardware, que lidava com compatibilidade, troca a quente e troca cega de forma transparente para eles, para um sistema de RAID por software que exige muito mais planejamento, coordenação e entendimento do sistema para ser usado com segurança.

Um equívoco menor, mas ainda comum, a respeito do ZFS, é o de que ele seja um sistema de arquivos em cluster adequado ao uso em cenários de DAS compartilhado ou de SAN, à la OCFS, VxFS e GFS2. O ZFS não é um sistema de arquivos em cluster e compartilha as mesmas limitações, nesse espaço, de todos os seus concorrentes comuns.

O ZFS pode ser uma excelente escolha, mas está longe de ser a única. O ZFS vem com grandes ressalvas, não sendo a menor delas as limitações de sistema operacional a ele associadas e, embora tenha muitos benefícios, poucos, se é que algum, são exclusivos do ZFS, e é muito raro que algum departamento se beneficie de cada um deles. Como em qualquer tecnologia, há trocas a serem feitas. Um tamanho não serve para todos. A chave para saber quando o ZFS é o ideal para você está em compreender o que o ZFS é, o que é e o que não é exclusivo dele, quais são seus objetivos de design, como a comparação de uma pilha de armazenamento com um sistema de arquivos puro produz resultados enganosos e quais limitações inerentes estão atreladas a ele.

O ZFS é uma consideração importante e a escolha comum quando Solaris ou FreeBSD é o sistema operacional escolhido. Com raras exceções, o sistema operacional nunca deve ser escolhido em função do ZFS, mas, em vez disso, o ZFS deve ser frequentemente escolhido, mas nem sempre, quando o sistema operacional já foi escolhido. O sistema operacional deve nortear as escolhas de sistema de arquivos em todos os casos, exceto nos mais raros. A escolha do sistema operacional é tão dramaticamente mais importante do que a escolha do sistema de arquivos.

O ZFS pode ser usado no Linux, mas ali não é considerado uma opção empresarial, e sim mais um sistema de hobby para experimentação, já que nenhum fornecedor empresarial (como Red Hat, Suse ou Canonical) oferece suporte ao ZFS no Linux e já que o Linux já conta com ótimas alternativas. Algum dia, o ZFS poderá ser promovido a sistema de arquivos de primeira classe no Linux, mas isso não é esperado, pois o BtrFS já ingressou na linha principal do kernel e foi incluído em versões de produção por diversos grandes fornecedores.

Embora o ZFS seja visto na grande maioria das implantações de Solaris e FreeBSD, isso se deve principalmente ao fato de ele ter assumido a posição de sistema de arquivos padrão, e não por ser claramente a escolha superior nessas situações ou por sequer ter sido avaliado de forma crítica. O ZFS é perfeitamente adequado para ser um sistema de arquivos de uso geral onde é nativo e tem suporte.

Qual é o principal caso de uso do ZFS?

O objetivo de design e o principal caso de uso do ZFS são sistemas de armazenamento aberto em Solaris e FreeBSD que fornecem armazenamento compartilhado a outros servidores ou que servem como repositórios maciços de dados para aplicações instaladas localmente. Nesses casos, o foco do ZFS em escalabilidade e integridade de dados realmente se destaca. O ZFS pende fortemente para departamentos de grande porte e de escala empresarial e, de modo geral, afasta-se da aplicabilidade no espaço das pequenas e médias empresas, onde competências em Solaris e FreeBSD, bem como necessidades de armazenamento de grande escala, são raras.

Referência: http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1