SAN entrega blocos brutos ao servidor via rede dedicada — o servidor vê um disco e decide como formatar. NAS entrega um sistema de arquivos compartilhado — o servidor monta uma pasta. Essa diferença fundamental define qual workload cada um serve. Escolher errado não derruba o sistema no dia um, mas cria problemas de performance que aparecem meses depois.
A diferença fundamental — o que cada um entrega ao servidor
Imagine que você vai construir uma casa. A SAN entrega tijolos e cimento — matéria-prima bruta que você usa do jeito que quiser. Você decide como empilhar, qual estrutura construir, qual sistema de arquivos usar. O NAS entrega um apartamento pronto — você entra, usa e divide com outros moradores, mas a estrutura já está lá.
Traduzindo para tecnologia: quando um servidor conecta a um volume SAN, ele recebe um LUN (Logical Unit Number) — uma sequência de blocos sem estrutura. O próprio servidor formata esse LUN com o sistema de arquivos que quiser (NTFS, ext4, XFS, VMFS) e o usa como se fosse um disco local. Nenhum outro servidor enxerga esse volume diretamente — o acesso é exclusivo do servidor que montou.
Quando um servidor conecta a um compartilhamento NAS, ele monta um sistema de arquivos que já existe — criado e gerenciado pelo próprio NAS. Outros servidores e clientes podem montar o mesmo compartilhamento simultaneamente. É colaboração, não exclusividade.
Protocolos — como cada um fala com o servidor
A SAN tem dois protocolos principais. O iSCSI encapsula comandos SCSI (o padrão de comunicação com discos) sobre TCP/IP — você usa a rede Ethernet existente para conectar o servidor ao storage. É mais barato e simples de implementar, basta uma rede dedicada de 10 GbE ou 25 GbE e configurar os initiators nos servidores.
O Fibre Channel é mais antigo, mais determinístico e de menor latência — mas requer hardware específico: HBAs (Host Bus Adapters) nos servidores e switches FC dedicados. Latências de 0,5 ms de ponta a ponta são alcançáveis. É o protocolo de ambientes onde cada microssegundo conta — Oracle RAC em missão crítica, sistemas financeiros de alta frequência.
O NAS fala NFS (Network File System) para clientes Linux/Unix e SMB/CIFS (Server Message Block) para clientes Windows. Alguns NAS servem ambos simultaneamente. O NFS é mais eficiente para workloads Linux de alta throughput; o SMB é melhor integrado ao ecossistema Windows com funcionalidades como DFS (Distributed File System) e ACLs detalhadas.
Performance real — onde cada um brilha e onde garga
Na prática, a SAN tem latência menor e IOPS mais alto para workloads de acesso randômico porque o caminho entre a aplicação e os blocos é mais curto. Um banco de dados Oracle em SAN iSCSI com rede 10 GbE dedicada vai enxergar latências de 0,5 a 2 ms. O mesmo banco em NFS vai adicionar a latência do protocolo de sistema de arquivos por cima.
Mas para leitura sequencial de arquivos grandes — que é exatamente o padrão de workloads de NAS — a diferença de latência de protocolo é irrelevante. Um render farm lendo arquivos de 50 GB de projeto 3D, ou um sistema de BI lendo datasets para análise, ou um servidor de mídia lendo vídeo para transcodificação — esses workloads são adequados para NAS porque acessam os dados sequencialmente.
O que realmente dói em NAS para workloads de banco de dados é o acesso randômico intenso: cada pequena leitura de página de dado envolve uma chamada ao protocolo de sistema de arquivos, que tem overhead maior que a leitura direta de bloco na SAN. Com milhares de operações por segundo, esse overhead acumula.
Casos de uso reais — onde cada um pertence
SAN é o ambiente natural de virtualização (VMware ESXi com VMFS em LUNs iSCSI ou FC), bancos de dados de missão crítica (Oracle, SQL Server, PostgreSQL de produção), sistemas ERP (SAP HANA em particular tem requisitos específicos de latência de storage) e qualquer aplicação que precise de block storage exclusivo com alta performance.
Imagine uma empresa com 200 VMs rodando num cluster VMware de 10 hosts. O armazenamento de todas essas VMs precisa ser acessível de qualquer host do cluster para vMotion e HA funcionar. A SAN com datastores VMFS compartilhados entre os hosts é a arquitetura correta — cada host monta o mesmo LUN e o VMware gerencia o acesso.
NAS é o ambiente natural de home directories e compartilhamentos corporativos (o servidor de arquivos do RH, da contabilidade, do time de produto), produção de mídia (estações de edição de vídeo acessando footage bruta compartilhada), desenvolvimento de software (repositórios de código e artefatos de build compartilhados), e backup primário via protocolo NFS ou SMB.
Imagine uma empresa de produção audiovisual com 30 editores acessando simultaneamente footage em 4K de um projeto. O NAS com alto throughput sequencial e compartilhamento simultâneo por NFS é exatamente o que esse workload precisa.
Custo e coexistência
SAN custa mais. Não porque o hardware de disco seja mais caro — o hardware pode ser o mesmo. O custo extra vem dos switches iSCSI dedicados ou equipamento FC, das HBAs nos servidores (no caso de FC), e da complexidade operacional maior. Uma SAN Fibre Channel bem feita requer expertise específica para configurar zoning, multipath e gerenciamento de LUNs.
NAS é mais simples de operar, mais barato de implementar e mais fácil de expandir. A desvantagem é que você não tem o controle total sobre o sistema de arquivos que a SAN dá — o NAS gerencia o filesystem por você.
O importante é entender que SAN e NAS não se excluem. A maioria dos datacenters corporativos tem os dois, cada um fazendo o que faz melhor. O mesmo array de storage muitas vezes serve como SAN (via iSCSI para o VMware) e NAS (via NFS para compartilhamentos Linux ou SMB para o Windows) simultaneamente — é o que se chama de storage unificado.
Para arquiteturas de storage corporativo que combinam SAN e NAS de forma adequada ao workload — sem over-engineering e sem subdimensionamento — fale com os arquitetos da Adentro. Nossos datacenters Tier III operam storage unificado com SLA de 99,99%.