O que é Metro SAN?

Um data center bem montado tem discos redundantes, controladoras em par e caminhos duplicados. Ainda assim, ele é um único ponto de falha: um incêndio, uma enchente ou uma queda prolongada de energia derrubam tudo de uma vez, por mais redundância interna que exista. É contra esse risco, perder o site inteiro e não só um componente, que existe o Metro SAN.

Metro SAN é uma SAN estendida entre dois data centers de uma mesma região metropolitana, que espelha os dados em nível de bloco, em geral de forma síncrona, para que a queda de um site não pare a operação nem faça perder dados.

Este artigo assume que você já sabe o que é uma SAN. Aqui o foco é o que muda quando essa rede de armazenamento deixa de viver dentro de quatro paredes e passa a atravessar a cidade. O fluxo básico é este:

O que é Metro SAN

Metro SAN, também chamada de SAN metropolitana ou stretched SAN, é uma SAN cujos servidores e arrays estão distribuídos entre data centers separados fisicamente, dentro do raio de uma região metropolitana. Ela preserva tudo o que define uma SAN comum: o acesso em nível de bloco, os volumes (LUNs) que o sistema operacional enxerga como discos locais, os protocolos de storage. O que muda é o alcance geográfico e, com ele, o propósito.

Numa SAN local, o objetivo é consolidar armazenamento e entregar desempenho. No Metro SAN esse objetivo continua valendo, mas o que puxa o projeto é outro: continuidade. Você mantém uma cópia viva e idêntica dos dados em um segundo prédio para que, se o primeiro desaparecer do mapa, a operação siga sem parar e sem perder transações. É disponibilidade de infraestrutura crítica, não conectividade de escritório.

Vale marcar essa fronteira porque o nome confunde. Metro SAN não é rede metropolitana para interligar filiais, nem tem parentesco com CDN ou com o "metro Ethernet" de operadora. É armazenamento em bloco, espelhado entre sites, para sobreviver a desastres.

O limite que manda no projeto: a velocidade da luz

Antes de falar de tecnologia, é preciso encarar a física, porque é ela que decide até onde um Metro SAN vai. A luz percorre a fibra óptica a cerca de 200.000 km/s, mais devagar que no vácuo por causa do índice de refração do vidro. Isso dá aproximadamente 5 microssegundos por quilômetro em cada sentido, ou perto de 10 µs no ida e volta.

Parece desprezível, e para leitura seria. O problema é a escrita síncrona: o array do site primário não confirma a gravação enquanto o site remoto não gravar o mesmo bloco e devolver o reconhecimento. Ou seja, toda escrita paga a latência de ida e volta do enlace. A 50 km são cerca de 0,5 ms somados a cada escrita. Numa aplicação transacional que faz milhares de escritas por segundo, isso deixa de ser detalhe e vira gargalo.

Daí a palavra "metro" no nome. O síncrono só é viável enquanto a distância mantém a latência baixa, algumas dezenas de quilômetros. Passou disso, o desempenho da aplicação degrada a ponto de inviabilizar o espelhamento em tempo real, e a solução passa a ser assíncrona. Essa é a linha divisória entre um Metro SAN (curto, síncrono) e uma solução de DR geográfico (longa distância, assíncrona).

Replicação síncrona × assíncrona

A escolha entre síncrono e assíncrono é a decisão central de qualquer projeto de replicação, e ela troca distância por perda de dados aceitável. Vale entender o conceito de RPO e RTO antes, porque é nesses termos que a decisão se resolve.

No síncrono, os dois sites estão sempre idênticos: se o primário cai, o secundário tem o mesmo estado, bloco a bloco, com RPO próximo de zero, ao preço da distância curta. No assíncrono, o array confirma a escrita localmente e replica em segundo plano; a aplicação não sente a latência do enlace e a distância deixa de ser limite, mas você aceita perder o que ainda não foi transmitido no momento da falha. Metro SAN é o território do síncrono. Muitas empresas combinam os dois: um par metropolitano síncrono para alta disponibilidade e um terceiro site remoto, assíncrono, caso a região metropolitana inteira seja afetada.

Como os dois sites se conectam

Espelhar blocos entre prédios exige uma fibra dedicada e de baixa latência entre eles, e não serve qualquer link de internet. As opções reais são:

• Dark fiber: um par de fibras ópticas dedicado, próprio ou alugado, sem equipamento ativo de terceiros no meio. É o caminho mais limpo e previsível em latência.
• DWDM/CWDM: multiplexação por divisão de comprimento de onda. Ela transporta vários canais independentes, inclusive Fibre Channel nativo, por um mesmo par de fibras, cada um numa cor de luz diferente. É o que permite carregar o tráfego de storage, a rede IP e a replicação no mesmo enlace metropolitano. Se o assunto óptico interessa, vale a leitura sobre tipos de fibra óptica.

Sobre esse transporte, o storage viaja de duas formas principais:

• Fibre Channel estendido: o Fibre Channel sai do data center e atravessa o enlace metropolitano. Aqui mora um detalhe que separa quem já apanhou de quem só leu: os buffer credits (BB_credits). O FC controla fluxo por créditos: o transmissor só envia um quadro se tiver crédito para ele. Em link longo há muitos quadros "em voo" ao mesmo tempo e, sem BB_credits suficientes, o enlace trava esperando reconhecimento e desperdiça banda. Dimensionar crédito à distância é o que mantém o throughput num FC estendido.
• FCIP (Fibre Channel over IP): encapsula os quadros FC dentro de pacotes IP, o que permite atravessar uma rede IP/WAN entre os sites. É a rota comum quando não há fibra dedicada ponta a ponta, e é mais usada em cenários de distância maior e replicação assíncrona.

Cluster estendido e o fantasma do split-brain

Ter os dados espelhados nos dois sites é metade do trabalho. A outra metade é coordenar quem manda. As soluções modernas de Metro SAN costumam operar em cluster estendido (stretched cluster), com virtualização de storage entre os sites: os dois arrays apresentam o mesmo volume, de forma ativa-ativa, e um host em qualquer dos sites enxerga o storage como uma coisa só. Fabricantes de storage têm produtos dedicados a isso: soluções como NetApp MetroCluster ou Dell EMC VPLEX existem justamente para entregar esse comportamento.

O risco clássico desse arranjo é o split-brain. Se o enlace entre os sites cai mas os dois data centers continuam de pé, cada um deixa de ver o outro e, sem coordenação, ambos podem se julgar o sobrevivente e continuar aceitando escritas. Quando o link volta, você tem duas versões divergentes dos mesmos dados e nenhuma forma limpa de reconciliar, o pior desfecho possível para storage.

A defesa é um quorum ou testemunha (witness) em um terceiro site, independente dos dois principais. Ele age como árbitro: quando a comunicação direta se rompe, o site que ainda alcançar a testemunha continua ativo e o outro se recusa a escrever. Por isso um projeto sério de Metro SAN raramente é só dois prédios: são dois prédios mais um ponto de decisão neutro.

Quando o Metro SAN faz sentido (e quando não)

Metro SAN é caro e complexo. Exige dois data centers reais, fibra metropolitana de baixa latência, arrays compatíveis com replicação entre sites, um terceiro ponto para quorum e gente que saiba operar tudo isso. Não é infraestrutura para quem só precisa de espaço em disco.

Ele se paga onde a indisponibilidade custa mais que a solução: instituições financeiras que não podem perder uma transação, hospitais e serviços de emergência, telecomunicações, sistemas que sustentam a operação de uma empresa inteira. Para esses casos, RPO próximo de zero e RTO de minutos são requisito regulatório ou de sobrevivência do negócio.

Fora desse recorte, quase sempre há caminho mais barato. Replicação assíncrona para um site remoto resolve DR com RPO de minutos a uma fração do custo. E vale insistir num ponto que muita gente confunde: Metro SAN não é backup. A replicação síncrona copia tudo em tempo real, inclusive um rm errado, um ransomware ou uma corrupção lógica, que chegam idênticos ao segundo site em milissegundos. Disponibilidade e recuperação de desastres são um problema; recuperação de dados, com cópias em pontos no tempo e isoladas, é outro. Um Metro SAN precisa de uma estratégia de backup ao lado, não no lugar.

Para a terminologia e os padrões de replicação e storage networking, a SNIA (Storage Networking Industry Association) é a entidade de referência do setor.

Perguntas frequentes sobre Metro SAN

O que é Metro SAN?

Metro SAN (SAN metropolitana ou stretched SAN) é uma Storage Area Network estendida entre dois ou mais data centers de uma mesma região metropolitana, tipicamente até algumas dezenas de quilômetros. Ela mantém a semântica de acesso em nível de bloco e espelha os dados entre os sites, geralmente por replicação síncrona, para garantir alta disponibilidade e recuperação de desastres.

Para que serve o Metro SAN?

Serve para continuidade de negócios e recuperação de desastres. Com dois sites espelhados em tempo real, a queda de um data center inteiro (incêndio, falta de energia, alagamento) não para a operação nem perde dados: o outro site assume com uma cópia idêntica, entregando RPO próximo de zero.

Qual a diferença entre Metro SAN e uma SAN local?

A SAN local vive dentro de um único data center e protege contra falha de disco, controladora ou servidor. O Metro SAN estende essa mesma rede de bloco até um segundo site, a quilômetros de distância, protegendo contra a perda do data center inteiro. É a diferença entre sobreviver a um componente que queima e sobreviver ao prédio que sai do ar.

Por que a distância é limitada no Metro SAN?

Porque a luz leva cerca de 5 microssegundos para percorrer 1 km de fibra, ou perto de 10 µs na ida e volta. Na replicação síncrona, cada escrita só é confirmada depois que o site remoto grava e responde, então toda a latência do enlace entra no tempo de resposta da aplicação. Quanto maior a distância, mais lenta fica a escrita, e por isso o síncrono só é viável na casa das dezenas de quilômetros.

Metro SAN substitui o backup?

Não. A replicação síncrona copia tudo instantaneamente entre os sites, inclusive um apagamento errado, um ransomware ou uma corrupção de dados: o erro chega idêntico ao outro lado. O Metro SAN resolve disponibilidade e recuperação de desastres; o backup, com cópias em pontos no tempo e isoladas, resolve recuperação de dados. São camadas complementares, não substitutas.