Saber como dimensionar storage SAN evita dois erros caros em infraestrutura enterprise: adquirir capacidade que não entrega desempenho ou pagar por uma configuração superdimensionada antes de haver demanda real. Em ambientes com virtualização, bancos de dados, ERP, VDI e arquivos críticos, o volume em TB é apenas uma parte da decisão. O storage precisa responder ao perfil de I/O das aplicações, manter a latência sob controle e preservar margem para crescimento, snapshots e contingência.
Comece pela carga de trabalho, não pela capacidade
O ponto de partida é identificar quais servidores e aplicações utilizarão a SAN. Uma área de armazenamento centralizado pode concentrar máquinas virtuais, volumes de banco de dados, repositórios de backup, arquivos compartilhados e aplicações transacionais. Esses workloads têm comportamentos radicalmente diferentes, mesmo quando consomem capacidades parecidas.
Uma máquina virtual de aplicação pode exigir poucas operações por segundo, enquanto uma base SQL Server, Oracle ou PostgreSQL demanda IOPS constantes e baixa latência. Um ambiente de VDI costuma apresentar picos severos durante o boot simultâneo dos usuários, conhecido como boot storm. Já um repositório de backup tende a priorizar throughput sequencial, não IOPS aleatórios.
Antes da cotação, levante ao menos quatro dados de cada workload relevante:
- capacidade atualmente consumida e crescimento mensal ou anual;
- IOPS médios e de pico, com leitura e gravação separadas;
- tamanho de bloco predominante, como 4 KB, 8 KB, 32 KB ou 64 KB;
- latência observada e limite aceitável para a aplicação.
Como dimensionar storage SAN pela capacidade útil
Capacidade bruta não é capacidade disponível para aplicações. Um storage com 100 TB brutos pode entregar muito menos espaço útil depois da configuração de RAID, hot spare, pools, snapshots, metadados e reserva operacional. Por isso, o cálculo deve partir da capacidade efetivamente utilizável.
Em configurações com HDD SAS, RAID 6 costuma ser adotado para proteger grandes grupos de discos contra a falha simultânea de duas unidades. O custo é equivalente à capacidade de dois discos por grupo, além do impacto de escrita associado à paridade. RAID 10 consome aproximadamente 50% da capacidade bruta, mas oferece desempenho superior para gravações aleatórias e tempos de reconstrução mais previsíveis. A escolha depende do nível de desempenho e disponibilidade exigido, não apenas do melhor aproveitamento de TB.
Em arrays all-flash, RAID 5 ou RAID 6 pode ser viável conforme a arquitetura do fabricante, o tamanho dos SSDs e as políticas de proteção do controlador. Ainda assim, não se deve assumir que deduplicação e compressão entregarão uma taxa fixa. Esses recursos podem reduzir bastante o consumo em VDI e sistemas operacionais repetitivos, mas têm resultado limitado em dados já comprimidos, criptografados, imagens, backups e arquivos multimídia.
Como referência de projeto, é prudente reservar entre 20% e 30% de espaço livre no pool. Essa margem favorece o desempenho interno do array, reduz riscos durante expansões e mantém espaço para snapshots. Se a empresa usa replicação entre sites ou mantém retenções longas de cópias locais, o planejamento precisa reservar essa capacidade adicional desde o início.
Uma fórmula simplificada é:
Capacidade bruta necessária = capacidade útil projetada ÷ eficiência estimada do RAID e do pool
A capacidade útil projetada deve incluir o consumo atual, o crescimento previsto para três a cinco anos e a reserva para proteção de dados. Se o ambiente requer 40 TB úteis em três anos e a eficiência total estimada é de 70%, o projeto precisa considerar pelo menos 57 TB brutos, antes de validar hot spare, discos de expansão e requisitos específicos do fabricante.
IOPS, latência e throughput definem a experiência da aplicação
A capacidade responde à pergunta "quanto cabe". IOPS, latência e throughput respondem se o ambiente funcionará com desempenho adequado. IOPS mede quantas operações de entrada e saída o storage processa por segundo. Throughput mede o volume transferido, geralmente em MB/s ou GB/s. Latência mede o tempo de resposta de cada operação, em milissegundos.
Para bancos de dados e virtualização, a latência costuma ser o indicador mais visível para o usuário final. Uma SAN pode ter capacidade livre e links de alta velocidade, mas apresentar lentidão se os discos, controladoras ou caches não atenderem às gravações aleatórias. Em workloads transacionais, normalmente busca-se latência de poucos milissegundos. O limite correto, porém, depende do aplicativo, da arquitetura do banco e do SLA do negócio.
O tipo de mídia altera completamente o resultado. HDDs SAS de 10K ou 15K RPM ainda atendem cenários de capacidade, backup e arquivos com custo por TB competitivo, mas oferecem IOPS limitados por unidade. SSDs SAS e NVMe entregam IOPS e latência muito superiores, sendo mais indicados para bancos de dados, clusters de virtualização, VDI e aplicações críticas. Uma arquitetura híbrida pode equilibrar custo e desempenho quando há camadas com necessidades distintas, desde que o tiering seja compatível com o padrão de acesso real.
Também é necessário considerar o efeito de escrita do RAID. Em RAID com paridade, uma gravação aleatória pode gerar operações adicionais de leitura e escrita, o chamado write penalty. Dimensionar apenas com os IOPS recebidos do host e ignorar esse fator pode levar a uma configuração subdimensionada. Cache protegido por bateria ou flash, controladoras ativas-ativas e SSDs de maior desempenho reduzem esse impacto, mas não eliminam a necessidade de cálculo.
Defina a conectividade entre hosts e storage
A rede SAN precisa transportar o desempenho previsto sem criar gargalos. Fibre Channel é uma escolha recorrente para aplicações de missão crítica por oferecer rede dedicada, baixa latência e operação madura em ambientes corporativos. Velocidades como 16 Gb, 32 Gb e 64 Gb FC devem ser avaliadas junto com HBAs, switches SAN, transceptores e compatibilidade de firmware.
iSCSI pode ser uma alternativa eficiente quando a empresa dispõe de switching Ethernet adequado e segmentação correta. Em projetos de maior demanda, 10 GbE é o ponto mínimo mais comum, enquanto 25 GbE oferece margem superior para clusters atuais e expansão futura. Independentemente do protocolo, a recomendação é utilizar redundância ponta a ponta: duas controladoras no storage, múltiplos caminhos por host, switches independentes e multipathing devidamente configurado.
Não basta instalar duas portas no servidor. É preciso validar a compatibilidade entre HBA ou NIC, sistema operacional, hypervisor, firmware do storage e versão do driver. Em infraestrutura enterprise, uma matriz de compatibilidade atualizada reduz falhas intermitentes e simplifica o suporte.
Planeje disponibilidade, proteção e expansão
Uma SAN deve continuar atendendo à operação durante a falha de um disco, uma controladora, uma fonte ou um caminho de rede. Isso exige controladoras redundantes, fontes e ventilação redundantes, multipath, RAID adequado e discos homologados para o equipamento. Discos enterprise SAS, SATA nearline e SSDs para data center têm características de endurance, firmware e tratamento de erro que diferem de unidades de uso desktop.
A proteção de dados também não pode depender exclusivamente de snapshots. Snapshots são úteis para recuperação rápida de arquivos, máquinas virtuais ou volumes, mas permanecem vinculados ao mesmo sistema de armazenamento. Uma estratégia consistente combina snapshot, backup em mídia ou repositório independente e, quando o RPO exige, replicação para outro storage ou site.
Quanto à expansão, avalie antecipadamente o limite de gavetas, discos, controladoras, portas front-end e capacidade por pool do modelo selecionado. Um storage aparentemente econômico pode se tornar restritivo se exigir migração completa ao atingir determinado limite. Em contrapartida, comprar uma plataforma muito acima da necessidade atual imobiliza orçamento. O equilíbrio está em escolher uma arquitetura escalável, com controladoras e conectividade compatíveis com o horizonte de crescimento definido.
Transforme o levantamento em uma especificação técnica
Uma especificação de compra bem estruturada deve indicar a capacidade útil requerida, o período de projeção, o perfil de IOPS, a latência esperada, a mídia desejada, o nível de RAID, a conectividade FC ou iSCSI, a quantidade de hosts e os requisitos de redundância. Inclua também o ambiente de software: VMware vSphere, Microsoft Hyper-V, Windows Server, Linux, banco de dados e ferramentas de backup.
Com essas informações, fica mais simples comparar uma SAN all-flash com uma solução híbrida, avaliar controladoras, selecionar SSDs ou HDDs SAS e confirmar HBAs, switches e transceptores compatíveis. A I.T. Computers apoia projetos desse tipo com infraestrutura enterprise completa, incluindo storages SAN, servidores, componentes e conectividade para expansão de data centers.
O melhor dimensionamento não é o que entrega o maior número de TB ou IOPS no catálogo. É o que sustenta a aplicação crítica dentro do SLA, mantém espaço para crescer e permite que a operação continue funcionando quando um componente inevitavelmente falhar.