Software Defined Storage é a separação entre o software que gerencia o armazenamento e o hardware físico onde os dados ficam. Em vez de depender de um appliance proprietário com hardware e software inseparáveis, o SDS roda em servidores comuns e pode gerenciar qualquer disco — transformando commodity hardware em infraestrutura de storage enterprise.
A analogia com o que já aconteceu em compute
Imagine que, em 2005, para rodar dez servidores você precisaria de dez máquinas físicas dedicadas, cada uma com sistema operacional e aplicação amarrados ao hardware do fabricante. Então veio a virtualização — o VMware separou o software (a VM) do hardware (o servidor físico) e transformou como o mundo opera compute. Hoje você roda cem VMs em dez servidores físicos comuns, move workloads entre hosts sem desligar nada, e o hardware virou commodity.
O Software Defined Storage faz exatamente isso, mas para armazenamento. Antes, o storage era um appliance fechado — um array do NetApp, da EMC, da HPE — com controladores proprietários, firmware específico e garantia vinculada ao fabricante. Se você precisava de mais capacidade, comprava expansão do mesmo fabricante pelo preço que ele cobrasse. Se o controlador falhava, chamava o fabricante.
O SDS quebra essa dependência. O software de storage — que gerencia replicação, snapshots, RAID distribuído, tiering, deduplicação, compressão — roda em servidores x86 comuns. Os discos são commodity. Você adiciona capacidade adicionando servidores com discos, comprados do fornecedor mais competitivo do momento.
Como o SDS funciona na prática
Na prática, um sistema SDS abstrai os discos físicos em pools de storage lógicos. O software gerencia esses pools e apresenta volumes, compartilhamentos ou buckets para os consumidores — da mesma forma que um hypervisor gerencia CPUs e memória físicas e apresenta CPUs e memória virtuais para as VMs.
O software SDS fica responsável por tudo que um array tradicional faria no hardware: distribuição dos dados entre os discos para performance e disponibilidade, detecção e recuperação de falha de disco, replicação para outros nós ou sites, snapshots e clones, compressão e deduplicação, e apresentação via protocolos padrão (iSCSI, NFS, S3, etc.).
O resultado é que o hardware fica intercambiável. Se a Intel lançar um SSD 30% mais rápido a um preço competitivo, você pode comprar esses SSDs e adicioná-los ao cluster SDS. O software gerencia a mistura de hardware transparentemente. Com um appliance tradicional, você ficaria preso ao roadmap e aos preços do fabricante.
Os principais produtos de SDS no mercado
O Ceph é o exemplo mais puro de SDS open source. Ele roda em qualquer hardware x86, gerencia pools de disco e apresenta block, file e object storage via protocolos padrão. É o que move a maioria das clouds privadas baseadas em OpenStack.
O VMware vSAN integra SDS ao hypervisor. Os discos locais de cada host ESXi entram num pool de storage compartilhado que o VMware gerencia diretamente. É elegante para ambientes VMware porque elimina o storage externo — os discos dos próprios servidores de compute viram o storage das VMs.
O Microsoft Storage Spaces Direct (S2D) é o equivalente da Microsoft no Windows Server e Azure Stack HCI. Mesma ideia: discos locais dos servidores Hyper-V formam um pool de storage gerenciado pelo Windows, apresentado como CSV (Cluster Shared Volume) para as VMs.
O NetApp ONTAP Select é interessante porque pega o mesmo software ONTAP que roda nos arrays físicos da NetApp e o transforma em VM. Você consegue as funcionalidades enterprise do ONTAP em hardware commodity — mas mantém a familiaridade operacional e o suporte da NetApp.
Vantagens reais e limitações honestas
As vantagens do SDS são concretas. Eliminação de lock-in de fabricante é a principal — você não está mais refém de um único vendor para expansão de capacidade, suporte e upgrades. Hardware commodity tem preços muito mais competitivos que appliances proprietários. Escala horizontal por adição de nós, sem windows de migração complexos. E o software evolui independente do hardware — você atualiza o software sem precisar trocar o hardware.
Mas as limitações são igualmente reais. O overhead de software — o processamento de replicação, compressão, erasure coding — consome CPU e memória dos servidores. Em appliances dedicados, isso é feito em hardware especializado (ASICs) sem overhead no servidor. Com SDS, você precisa dimensionar o hardware levando esse consumo em conta.
O problema real aqui é a expertise necessária. Um appliance tradicional tem uma interface de gerenciamento simplificada e suporte do fabricante para qualquer problema. O SDS requer que você ou o seu time entenda profundamente como o software funciona — o CRUSH map do Ceph, os políticas do vSAN, o dimensionamento de storage spaces. Problemas complexos de performance ou corrupção de dados exigem conhecimento que não está na documentação de nível básico.
A tendência de migração de appliances para SDS
Pense assim: o mercado de storage está repetindo o que aconteceu com servidores depois da virtualização. Os appliances de storage ainda existem — assim como ainda existem mainframes — mas o crescimento marginal está todo no SDS, tanto em nuvem pública quanto privada.
AWS, Azure e Google Cloud são essencialmente SDS em escala massiva. OpenStack com Ceph, VMware vSAN e Azure Stack HCI crescem em mercado corporativo. Os fabricantes de appliances como NetApp e Dell respondem com versões de software do seu stack (ONTAP Select, PowerStore) para não ficar para trás.
Para a maioria das empresas que estão renovando ou expandindo infraestrutura hoje, a decisão não é “SDS ou appliance” em termos absolutos — é “qual SDS” e se você opera ele mesmo ou consome como serviço gerenciado.
A cloud privada da Adentro é construída sobre SDS gerenciado pela nossa equipe de infraestrutura. Você consome storage com SLA enterprise sem precisar operar Ceph, vSAN ou qualquer camada de software por baixo.