Data centers e salas de TI: automação para operações que não podem parar

Um data center vende uma promessa difícil de sustentar sozinha: disponibilidade. SLA de 99,9%, 99,95%, 99,99% — cada casa decimal a mais depois da vírgula representa minutos de tolerância a menos por ano, e cada minuto fora do ar custa mais do que a métrica sugere: contrato penalizado, cliente perdido, reputação manchada num mercado pequeno o bastante para que todo mundo saiba quando algum site caiu. E esse desafio não é mais exclusivo dos grandes data centers corporativos. Cresce do mesmo jeito em sites de borda, salas de TI dentro de empresas, headends de operadoras e pontos de presença espalhados por várias cidades — lugares onde raramente existe alguém tecnicamente qualificado de plantão, e onde a distância entre "alguém percebeu o problema" e "alguém resolveu o problema" é medida em horas, não em minutos.

Quando um equipamento trava de madrugada, quem vai até o rack?

Switches, servidores, roteadores e appliances de rede que operam ininterruptamente acumulam pequenas falhas de firmware que travam o equipamento sem derrubar a energia — ele simplesmente para de responder. Resolver isso, na maioria das vezes, é tão simples quanto desligar e ligar de novo. O problema é chegar até a tomada: sem controle remoto de energia, alguém precisa se deslocar fisicamente até o data center ou até o rack, às vezes de madrugada, às vezes numa cidade diferente de onde a equipe de operação está baseada. Em um único site isso já dói. Em uma rede de sites de borda ou de colocation com dezenas de racks espalhados, o custo de deslocamento por incidente vira uma linha de despesa que ninguém planejou — e o tempo de resposta, mesmo assim, nunca é imediato, porque ainda depende de alguém chegar fisicamente ao local.

É esse o problema que a smartPDU da Strataon resolve na tomada: religar remotamente um equipamento travado, de qualquer lugar, sem depender de deslocamento.

Temperatura, umidade e o intervalo entre "está tudo bem" e "virou incidente"

Boa parte das falhas de hardware em data center não acontece do nada — é precedida por horas de temperatura acima do ideal, umidade fora da faixa recomendada ou um sistema de refrigeração que perdeu eficiência sem que ninguém percebesse. Sem sensores dedicados reportando esses dados em tempo real, o primeiro sinal de problema costuma ser o pior possível: o próprio equipamento desligando por proteção térmica, no meio da operação, ou um disco que falha prematuramente depois de meses operando alguns graus acima do recomendado. O mesmo raciocínio vale para riscos que não avisam antes de virar desastre, como princípio de incêndio e alagamento: um sensor de fumaça ou de presença de água num ambiente sem operador de plantão é o que separa um alerta a tempo de uma sala de TI inteira perdida. Monitorar temperatura, umidade, fumaça e alagamento ponto a ponto — não só na entrada da sala, mas rack a rack — transforma um evento que seria descoberto tarde demais em um alerta que dá tempo de agir antes da falha.

A porta do rack é um problema diferente do controle de acesso da sala

É comum pensar em segurança física de data center como um problema resolvido na entrada da sala: crachá ou biometria na porta, e pronto. Mas quem abriu a porta frontal — ou a traseira — de um rack específico é uma pergunta diferente, e bem mais difícil de responder sem um sistema dedicado a isso. Em ambientes de colocation, onde vários clientes dividem o mesmo espaço físico mas precisam de garantia de que ninguém além da própria equipe (ou de quem eles autorizarem) chega perto do próprio equipamento, esse controle granular por rack — e não só por sala — deixa de ser um recurso desejável e vira um requisito contratual.

No Sentia, é possível definir quem tem autorização para acessar cada rack individualmente, com janelas de horário específicas e histórico de auditoria completo de cada abertura de porta, frontal ou traseira. Isso não substitui o controle de acesso ao ambiente — complementa: a sala tem sua própria entrada controlada, e cada rack dentro dela tem a sua, com registro e permissões próprios. A leitura de identificação é compatível com qualquer leitor de mercado no padrão Wiegand — crachá de proximidade, biometria, reconhecimento facial, entre outros — sem prender a operação a uma marca específica de leitor.

Resposta local mesmo com o link caído

Um detalhe que passa despercebido até o dia em que falha: monitoramento e automação que dependem inteiramente da nuvem param de funcionar exatamente no momento em que a conectividade do site cai — que costuma ser também o momento em que mais se precisa de resposta automática. Em sites de borda e pontos de presença remotos, onde a conexão com a internet nem sempre é redundante, a automação crítica — reboot de equipamento, alerta ambiental, liberação de porta de rack — precisa continuar rodando localmente, sem depender de um servidor remoto disponível naquele instante. É esse o papel do miniPLC: a nuvem agrega e visualiza dado depois; a decisão em tempo real fica resolvida no próprio site.

Histórico de eventos como base para manutenção preventiva — e para auditoria

Cada travamento de equipamento, cada pico de temperatura e cada abertura de porta de rack registrados ao longo do tempo viram um ativo, não só um log. É esse histórico que permite identificar um rack com tendência a superaquecer antes que o problema derrube um equipamento, ou confirmar exatamente quem abriu qual rack, quando, e se estava dentro da janela de horário autorizada. Sem esse registro, a operação vive reagindo a incidentes; com ele, dá para migrar parte da manutenção de reativa para preventiva, e responder com dados a qualquer questionamento sobre quem teve acesso a quê.

Quem sente esse impacto na prática

Essa necessidade aparece, em intensidades diferentes, em:

• Equipes de NOC e operações de TI, cobradas por uptime e tempo de resposta a incidentes.
• Provedores de colocation, que precisam de controle granular de acesso por rack e histórico confiável para rastrear qualquer problema entre clientes que dividem o mesmo espaço.
• Operadoras de telecom e provedores de internet, com sites de borda e pontos de presença espalhados geograficamente.
• Empresas com sala de TI própria, sem equipe técnica de plantão fora do horário comercial.
• Integradores de infraestrutura crítica, que projetam e mantêm esse tipo de ambiente para terceiros.

Se a sua operação ainda depende de alguém se deslocar até o rack para resolver um travamento, só descobre um problema ambiental quando o equipamento já desligou sozinho, ou não sabe dizer com certeza quem abriu qual rack e quando, vale entender onde a automação resolve isso primeiro.