NAS e SAN com Linux

NAS (Network Attached Storage) e SANs (Storage Area Networks) vêm se tornando cada vez mais comuns como os principais repositórios de dados em grandes empresas. As vantagens são várias: performance, confiabilidade e maneabilidade. Os principais nomes deste mercado (Veritas, Legato, Quantum, EMC, Aspex e IBM, entre outros) suportam o Linux como plataforma "Tier 1"

Há rumores de que alguns produtos destas empresas seriam eles mesmos baseados no sistema operacional de código aberto, o que seria nada mais do que uma escolha natural, por trazer ao mesmo tempo redução de custos e uma base sólida para a construção de network appliances (sistemas dedicados que vêm prontos para uso: é só conectar na rede). A entrada do software livre neste ambiente não se limita ao Linux: há suporte de vários produtos ao Net/Open/FreeBSD.

Neste artigo, veremos as características dos sistemas de NAS e SAN, algumas vantagens e também algumas limitações do Linux como base para sua implementação.

NAS x SAN

Um NAS pode ser visto como um "superservidor de arquivos". Ele é um nó da rede dedicado a compartilhar arquivos com outras estações e servidores da rede. Um bom NAS deve ser compatível com vários protocolos: SMB/CIFS para o mundo Windows, NFS para Unix e Linux e AppleShare para os Macintosh. Há algum tempo, também seria considerado obrigatório o suporte ao NCP das redes Novell Netware.

Dada a característica centralizadora do NAS, recursos de tolerância a falhas, replicação e clustering são fundamentais, assim como balanceamento de carga. É verdade que o suporte a clusters para NAS é bem mais simples do que em bancos de dados ou servidores de aplicação, pois não há necessidade de preservar o estado de memória nem contexto de transações.

Como um NAS é basicamente um mecanismo de E/S de rede, devemos selecionar com cuidado o hardware utilizado: precisamos de discos rápidos, controladoras SCSI de última geração e múltiplas placas de rede para agregação de banda ou até mesmo Gigabit Ethernet.

Já o SAN surgiu dos arrays de discos compartilhados em clusters de bancos de dados. Utilizando a tecnologia Fibre Channel, montamos uma pequena rede (pequena em área física) de alto desempenho e confiabilidade. A esta rede conectamos robôs de fitas, arrays de discos e outros dispositivos especializados. Os clientes da SAN não a enxergam como uma rede local de propósito geral, mas sim como dispositivos virtuais, como se os discos e unidades de fitas estivessem conectados aos seus próprios barramentos SCSI.

Além da velocidade oferecida pelo Fire Channel, a SAN oferece vantagens na reconfiguração (drives podem ser relocados sem necessidade de mudar conexões físicas) e backups mais rápidos (pois os nós de uma SAN podem se comunicar diretamente - assim, o backup de um array de discos para um robô de fitas é feito sem passar pelos servidores que "hospedam" os dispositivos).

A visão da SAN como dispositivos virtuais é importante porque permite oferecer raw devices para os clientes, permitindo o seu uso como meio de armazenamento para bancos de dados. Quando um PostgreSQL ou um Oracle salvam os dados do log de transação em disco, eles esperam que realmente seja feita a gravação física dos dados no disco, caso contrário o mecanismo de recuperação de transações pode falhar. Entretanto, se os logs estiverem em um NAS, ainda temos o transporte dos blocos de dados pela rede e o cache de disco do servidor de arquivos remoto antes da efetiva gravação no disco.

É possível obter apenas o software para NAS ou SAN dos fornecedores tradicionais, mas, em geral, se adquire soluções fechadas, incorporando tanto hardware quanto software, nos chamados network appliances. A Quantum, por exemplo, publica comparações da sua linha Snap Server com servidores NT, citando custos inferiores de aquisição, upgrade, manutenção e de licenças bastante semelhantes a comparações do Windows com servidores de arquivos baseados em Linux e Samba (!).

NAS e SAN em Linux

Em princípio, o sistema Linux parece ser um ótimo candidato a base para implementação de NAS e SANs:

~U O kernel é eficiente no escalonamento e realização de operações de E/S de disco e de rede.

~U Há drivers para diversas controladoras SCSI (com e sem RAID integrado) e Fibre Channel

~U O sistema sabe lidar com múltiplos barramentos PCI na mesma placa mãe, além do uso simultâneo de várias CPUs, controladoras de disco e placas de rede;

~U RAID 0, 1 e 5 em software, o que pode baratear a construção de appliances, dado que um servidor de arquivos costuma ter muito tempo de CPU ocioso para esta tarefa;

~U Sistemas de arquivos com journaling (para recuperação rápida em caso de falha de energia): Ext3, ReiserFS, JFS e XFS;

~U Recursos para clustering, como heart-beat e ARP watch

~U Múltiplos protocolos cliente: SMB, NCP, NFS, AppleShare;

~U Múltiplos mecanismos de autenticação: NIS, LDAP, Radius, Kerberos, Winbind (Domínios Windows), pam_ncp (Bindery e NDS);

~U Mecanismos de replicação como rdist e NBD (Network Block Device);

~U Facilidades para administração remota segura (como o SSH), além de front-ends Web maduros (como o Webmin) para administração do sistema e operação headless (sem monitor e teclado)

Os fornecedores tradicionais de produtos para NAS e SAN oferecem alternativas aos recursos já oferecidos por software livre em uma distribuição padrão do Linux. A Veritas, por exemplo, fornece seu próprio gerenciador de volumes em substituição ao LVM (dispositivos MD) do kernel do Linux, além de sistemas de arquivos com journalling e software para clustering. Ela vem sendo bastante agressiva na comercialização da sua solução sobre o Red Hat Advanced Server, em parceria com a Dell e a Oracle.

Algumas empresas estão buscando espaço neste mercado, com soluções inteiramente baseadas em software aberto, como o iSCSI Linux NAS Server. O que elas fazem é fornecer o conjunto de hardware e software pré-configurado, tal qual os network appliances dos fornecedores tradicionais, mas sem incluir software proprietário.

Apesar de todos os recursos do Linux, ainda falta algo indispensável para construir grandes repositórios de arquivos: controle de acesso granular.

Bits de Permissão x ACLs x Trustees

Estamos acostumados aos três níveis de permissão do Unix: Dono, Grupo e Outros. Em cada nível, podemos estabelecer permissões de leitura, escrita e execução. Com este sistema, simplesmente não é possível definir grupos diferentes de usuários com acesso de leitura ou escrita a um dado arquivo ou diretório.

Servidores Netware utilizam o conceito de Trustees, pelo qual associamos a cada usuário ou grupo permissões de acesso sobre diretórios ou arquivos individuais. Os direitos efetivos de um usuário são a soma dos trustees do usuário e de todos os grupos aos quais ele pertence. Se um usuário possui direitos sobre um dado diretório, ele também possui os mesmos direitos para todos os arquivos e subdiretórios abaixo dele, a não ser que exista um trustee mais específico. Ou seja, os trustees são herdados na árvore de diretórios.

Os trustees são poderosos e fáceis de gerenciar, pois, dado um nome de usuário, podemos facilmente determinar todas as suas permissões de acesso a arquivos e podemos implementar qualquer combinação desejada para satisfazer às políticas da empresa.

Servidores Windows herdaram do LAN Manager o conceito de ACL, pelo qual associamos a cada arquivo ou diretório uma lista relacionando usuários ou grupos a permissões específicas, tal qual os bits de permissão do Unix. Quando um usuário acessa um arquivo, são consideradas apenas as entradas do ACL que referenciem o próprio usuário ou algum dos grupos ao qual ele pertence, e a permissão menos restrita encontrada é a permissão efetiva.

ACLs também permitem a implementação de qualquer política de controle de acesso que a empresa julgue conveniente, mas tem custo administrativo elevado porque só podemos obter o conjunto total de permissões atribuídas a um dado usuário se percorrermos todos os arquivos do disco. É muito fácil ter uma permissão mais aberta em um subdiretório que passe desapercebida para o administrador (bom para os crackers) e também é muito fácil sobrescrever permissões customizadas de um arquivo quando modificamos o ACL de um diretório vários níveis acima de modo recursivo. Mesmo o artifício de herança de ACL do Windows 2000 não resolve inteiramente o problema.

Outro problema dos ACLs é que ficamos com várias entradas "perdidas" quando um usuário ou grupo é removido do sistema. Este "lixo" se acumula, gera overhead (pois toda a ACL tem que ser processada a cada acesso a arquivo) e cria brechas de segurança. Ocasionalmente, este "lixo" é efeito colateral da quebra de um relacionamento de confiança ou da indisponibilidade de um servidor membro em grupo de trabalho ou controlador de domínio e, portanto, não deve ser removido.

A vantagem dos ACLs é sua verificação mais rápida, pois envolve apenas o arquivo sendo acessado e talvez os seus antepassados. O algoritmo de validação de acesso por ACLs é consideravelmente mais simples do que com Trustees.

Por outro lado, é mais fácil adicionar suporte a Trustees em um sistema de arquivos, pois os Trustees podem ser armazenados em um arquivo de configuração isolado (tal qual informações de quotas de disco no Linux) enquanto que o ACL deve ser armazenado em atributos estendidos de comprimento variável, associados ao i-node de um arquivo, diretório ou dispositivo.

Atributos Estendidos, ACLs e Trustees no Linux

O padrão POSIX para os sistemas Unix-like optou pelo conceito de ACL, e a falta de atributos estendidos nos sistemas de arquivos do minix e no ext2 fez com que o Linux não suportasse este recurso até recentemente.

Sistemas de arquivos mais recentes como o ext3 e o XFS da SGI oferecem atributos estendidos, e podemos conseguir patches também pra o JFS da IBM. Até o momento, não há nada para o ReiserFS. O suporte a ACLs via atributos estendidos já pode ser adicionado como patches ao kernel 2.4 e provavelmente será padrão no kernel 2.6.

O suporte a ACLs envolve uma grande atualização das distribuições pois, além das mudanças nos sistemas de arquivos e no kernel, necessitamos de utilitários para permitir ao administrador visualizar e modificar os ACLs (comandos getfacl e setfacl), suporte em utilitários de backup, compactação e arquivamento (cpio, tar, gzip e zip/unzip), além de atualizações de front-ends administrativos e gerenciadores de arquivos gráficos.

Apesar disso, já é possível utilizar ACLs, pois componentes-chave como o Samba, o NFS e o Webmin já as suportam de forma interoperável com outros sistemas POSIX como o AIX e o Solaris.

Existe ainda um projeto de adição de trustees ao kernel do Linux que eu gostaria muito de ver incluso no kernel 2.6 e suportado pelas distribuições. Mesmo sem o status de padrão POSIX, a implementação dos trustees em uma rede Linux não é complicada porque não há necessidade de modificação de protocolos como o NFS para suportar a consulta e modificação de permissões.

Sistemas de NAS e SAN deverão fazer parte da sua rede muito em breve, se já não o fazem. O Linux vem sendo reconhecido pelos fornecedores novos e tradicionais como uma plataforma poderosa para este tipo de aplicação, e com o advento do suporte a ACLs nos sistemas de arquivos mais recentes, o Linux se tornará capaz de oferecer o mesmo nível de funcionalidade e maneabilidade de grandes servidores de arquivos Netware ou Windows. Resta esperar para ver em quanto tempo as soluções baseadas em software livre terão impacto significativo sobre a fatia de mercado dos produtos proprietários tradicionais.

Buscando Alternativas

O custo elevado e a falta de padronização do Fibre Channel fizeram com que o mercado buscasse tecnologias alternativas para o SAN. A mais promissora é o iSCSI ou SCSI sobre IP. Nesta tecnologia, encapsulamos pacotes SCSI em pacotes IP, que são enviados por conexões Fast Ethernet ou Gigabit Ethernet, e montamos uma rede local isolada para funcionar como uma SAN.

A grande dificuldade desta tecnologia é o overhead do protocolo IP. Enquanto é fácil para a maioria dos servidores utilizar toda a largura de banda de uma conexão Fibre Chanel de 100Mbps, o mesmo não costuma ser feito com uma Fast Ethernet na mesma velocidade, devido ao consumo de CPU da pilha TCP/IP. A solução é criar placas de rede inteligentes que incorporem o processamento do protocolo IP e até mesmo do UDP ou TCP. Estas placas são classificadas pelos fornecedores como sendo "wire speed", pois são capazes de sustentar transmissões IP na totalidade da capacidade da Ethernet.

Algumas empresas estão buscando espaço neste mercado, com soluções baseadas em software aberto

Para saber mais:
"Using SANs and NAS", W. Curtis Preston, O'Reilly - www.oreilly.com/catalog/sansnas
"The Top 10 SANs x NAS Decision Factors", W. Curtis Preston - www.oreillynet.com/pub/a/aonlamp/2002/03/14/sansnas.html
Extended Attributes and Access Control Lists for Linux - acl.bestbits.at
Linux Trustees Project - trustees.sourceforge.net
iSCSI Linux NAS Server - www.storage-virtualization.com/iSCSILinuxNASServer.htm
Veritas - www.veritas.com
Legato - www.legato.com
Quantum - www.quantum.com
SNAP Appliance - www.snapappliance.com
Página pessoal do Autor - www.lozano.eti.br