Storage não é commodity. Escolher o tipo errado para um workload é uma das causas mais comuns de problemas de performance que aparecem meses depois da implantação — quando o projeto já foi entregue. Este artigo explica como cada arquitetura funciona e, mais importante, quando usar cada uma.
Como o computador “vê” o armazenamento — e por que isso importa
Antes de comparar tecnologias, vale entender um ponto que muita gente pula: a forma como um servidor enxerga o storage é o que define a arquitetura adequada. O servidor pode ver um disco bruto (blocos), um sistema de arquivos compartilhado na rede ou um repositório de objetos acessado por API. Cada modelo tem suas implicações em latência, custo e escalabilidade.
Imagine que você está montando uma cozinha industrial. O DAS seria ter os ingredientes dentro da própria cozinha — acesso instantâneo, mas só quem trabalha ali chega a eles. O NAS seria um almoxarifado compartilhado no corredor — qualquer cozinha do andar acessa, com um pouco mais de caminho. O SAN seria um sistema de tubos diretos do estoque até cada estação — alta vazão, mas requer infraestrutura específica. E o Object Storage seria um serviço de delivery por pedido — você solicita por API e recebe o que precisa, sem se preocupar onde o item está fisicamente.
DAS — Direct Attached Storage
O DAS é o modelo mais simples: discos conectados diretamente ao servidor, via barramento SATA, SAS ou NVMe. Sem rede no meio. Sem camada adicional de software. O sistema operacional vê aqueles discos como se fossem parte do próprio servidor — porque são.
Na prática, o DAS ainda faz muito sentido em cenários específicos. Um servidor de banco de dados crítico que não pode tolerar nenhuma latência de rede adicional. Um nó de processamento de vídeo que precisa de taxa de transferência máxima. Workloads onde o dado tem dono único e não precisa ser compartilhado.
O protocolo varia com o barramento: SATA para SSDs de performance moderada, SAS para discos corporativos de alta durabilidade, e NVMe via PCIe para latências abaixo de 100 microssegundos. A limitação é óbvia — se o servidor morrer, o storage fica inacessível, a menos que você replique os dados em outro lugar.
NAS — Network Attached Storage
O NAS coloca um sistema de arquivos compartilhado na rede. Em vez de blocos brutos, o servidor oferece diretórios e arquivos que qualquer cliente autorizado pode montar e usar — seja Linux via NFS, seja Windows via SMB/CIFS.
Imagine que você tem 50 desenvolvedores que precisam acessar os mesmos arquivos de projeto. Ou uma equipe de produção de vídeo que compartilha footage bruta. Ou um sistema de backup que precisa ser acessado por múltiplos agentes. Esses são casos naturais para NAS.
A latência do NAS é maior do que DAS porque há uma camada de rede e um protocolo de sistema de arquivos no meio. Para aplicações que acessam arquivos sequencialmente e não são latência-sensíveis, isso não é problema. Para um banco de dados OLTP com milhares de operações por segundo de leitura aleatória, o NAS vira gargalo rapidamente.
SAN — Storage Area Network
A SAN é uma rede dedicada para storage — separada da rede de dados corporativa — que entrega blocos brutos aos servidores. O servidor recebe um LUN (Logical Unit Number) que ele vê como um disco local, mas que fisicamente está em um array de storage centralizado e compartilhado.
O protocolo mais comum hoje é iSCSI, que encapsula comandos SCSI sobre TCP/IP e permite usar a rede Ethernet existente. Em ambientes de altíssima performance e baixa tolerância à latência, o Fibre Channel ainda domina — é um protocolo dedicado, com switches específicos e latências abaixo de 1 milissegundo de ponta a ponta.
Na prática, a SAN é o padrão para virtualização corporativa (VMware, Hyper-V), bancos de dados de missão crítica (Oracle, SQL Server) e qualquer workload que precise de alta performance em I/O randômico com acesso compartilhado. A complexidade e o custo são maiores, mas a performance e a disponibilidade compensam em cenários onde esses fatores são críticos.
Object Storage — e por que S3 virou protocolo padrão
O Object Storage funciona de forma completamente diferente dos outros três. Em vez de blocos ou arquivos, você armazena objetos — cada um com seu conteúdo, um identificador único e metadados livres. O acesso é feito via API HTTP, tipicamente compatível com o protocolo S3 da Amazon.
O ponto de inflexão foi a Amazon popularizar o S3 em 2006 como serviço público. O protocolo S3 se tornou um padrão de fato: hoje, qualquer storage object compatível com S3 usa a mesma API, independente de ser AWS, um storage local ou um serviço regional como o da Adentro. Você escreve o código uma vez e ele funciona em qualquer ambiente S3-compatible.
Object Storage não tem a hierarquia de diretórios do sistema de arquivos — é um namespace plano com buckets e chaves. Isso soa limitante, mas é o que permite escalar para petabytes sem os problemas de metadata que afligem sistemas de arquivos tradicionais. O caso de uso clássico: backup de longo prazo, armazenamento de mídia (imagens, vídeos), logs de aplicação, datasets de treinamento de IA, artefatos de build e distribuição de conteúdo estático.
A latência do Object Storage é maior do que SAN ou DAS — estamos falando de milissegundos por operação HTTP, não microssegundos. Mas para os workloads certos, isso é absolutamente irrelevante diante das vantagens: custo por GB muito menor, escala horizontal sem limite prático e durabilidade por design (múltiplas réplicas ou erasure coding).
Como escolher — regras práticas
O problema real aqui é que muitas decisões de storage são tomadas com base em familiaridade, não em adequação ao workload. Time que sempre usou SAN coloca tudo em SAN. Time que descobriu object storage quer guardar banco de dados lá.
Pense assim: se o dado é acessado por um único servidor com necessidade de latência mínima — DAS. Se múltiplos servidores precisam compartilhar arquivos e a performance não é crítica — NAS. Se você tem bancos de dados, VMs ou qualquer workload que precise de block storage compartilhado com alta performance — SAN. Se você precisa armazenar volumes grandes de dados não estruturados, com acesso via aplicação — Object Storage.
| Critério | DAS | NAS | SAN | Object |
|---|---|---|---|---|
| Latência típica | <1 ms | 1–10 ms | <2 ms | 10–100 ms |
| Custo relativo | Baixo | Médio | Alto | Muito baixo |
| Escalabilidade | Limitada | Moderada | Alta | Quase ilimitada |
| Compartilhamento | Não | Sim (arquivos) | Sim (blocos) | Sim (API) |
| Uso ideal | DB local, compute | Arquivos, colaboração | VMs, DB crítico | Backup, mídia, logs |
Em ambientes modernos, esses tipos coexistem. Um datacenter bem projetado usa SAN para os datastores do VMware, NAS para os home directories e compartilhamentos corporativos, e Object Storage para backup e arquivos históricos — cada um no lugar certo.
Precisa dimensionar storage para sua infraestrutura? Fale com um arquiteto da Adentro — nossos datacenters Tier III em Osasco, Vinhedo e Porto Alegre oferecem SAN, NAS e Object Storage S3-compatible com SLA de 99,99%.