O Caçador de Zumbis: DCIM

Por mais que eu queira, não vou escrever sobre Negan, Rick, Daryl, Michonne e The Walking Dead. Não, nós não vamos sugerir que você vire um caçador e perambule polo seu data center com uma Colt Python (Colt Python é um revolver Magnum calibre .357), ou uma espada de Samurai.  Entretanto, você pode querer trazer o mesmo entusiasmo e seus melhores instintos de sobrevivência para a tarefa de identificar e eliminar servidores zumbis em seu data center.  Sabemos, a partir do relatório do Dr. Koomey que podem haver vários destes zumbis se escondendo em suas instalações.

Vamos começar definindo o que queremos dizer com servidor zumbi, comatoso, órfão, inativo ou subutilizado.  Cada uma destas categorias de dispositivos tem um impacto negativo na produtividade do data center e no consumo total de energia. Eles também ocupam um espaço valioso do rack enquanto consomem energia crítica e recursos de refrigeração. Mas com um hardware de distribuição de energia inteligente trabalhando em conjunto com um sistema DCIM de gerenciamento de ativos de TI monitorando e controlando os PDUs de forma individual, podemos encontrar e eliminar estes zumbis.  Nossa arma? Um aplicativo DCIM baseado em regras – e políticas – que ajuda a reduzir o consumo total de energia do data center, liberando recursos valiosos como espaço, energia condicionada e refrigeração.

Servidores zumbis vêm em vários formatos. De qualquer forma que forem definidos, todos eles consomem energia e devoram espaço, alguns podem ser reabilitados, mas a pergunta que você deve fazer é: Se eles ficaram inativos por um certo período de tempo e sem nenhum impacto as suas aplicações, não é hora de desligar a tomada?

A Grande Lista dos Servidores Zumbis Sugadores de Energia

Como você pode observar, estamos vendo uma lista grande de zumbis e outros monstros similares de data centers. Inacreditavelmente, estudos mostram que na media data centers de médio porte, salas de computação e gabinetes de rede têm 30% dos servidores instalados praticamente inativos.

Desenvolver um matador de zumbis automático com base em regras – e políticas – é uma tarefa relativamente simples, que vale o investimento em tempo e em recursos.  Tudo começa com a compreensão de alguns pontos chaves do perfil de consumo de energia do seu servidor: suspenso (sleep), inativo (idle), modo de economia de energia (aplicação de OEM), carga parcial, modo normal, e pico. O segundo passo é validar esta informação, uma vez que ela tenha sido coletada no data center através do medidor de energia, ao nível individual através de PDUs inteligentes. Estabeleça um grau de confiança aceitável (precisão do medidor acrescentado de uma pequena margem de segurança) e inicie a coleta de dados em tempo real através das interfaces das PDUs e do software DCIM.

Antes de tomar conclusões precipitadas, permita aos servidores se normalizarem e se estabelecerem em modo “produção”. Uma vez que estejam funcionando normalmente, coletamos um pouco mais de dados e então começamos a desenvolver nossas regras e políticas. Uma regra importante será a definição do que é um servidor “inativo” para classes específicas de servidores e aplicações.  Seus dados podem mostrar o consumo de energia como sendo 2,5 amperes em 208V AC (considerando a UPS como uma regulagem rígida de tensão).  Seu teste e os dados do mundo real indicam uma “carga-baixa” como 2,9 amperes e o modo “normal” como maior que 3,3 amperes. Você deve então ajustar a função do monitor do DCIM para automaticamente iniciar um relógio de tempo quando ele identificar que este dispositivo caiu para 2,5 amperes e reinicializar sempre que o servidor exceder 2,8 amperes, levando em consideração a precisão, desvios, incertezas, etc.  (Para saber mais sobre os impactos dos servidores inativos na eficiência de seu data center, leia nosso post recente pedindo por um novo padrão de desempenho inativo.)

Agora temos um registro da hora e um relógio trabalhando para um servidor inativo. O relatório do Dr. Koomey sugere que um servidor zumbi ou comatoso não tem demanda de rede ou ações executáveis por mais de seis meses, mas não há razão para esperar tudo tanto para tomar uma atitude. Recomendamos definir regras adicionais em nosso DCIM para destacar e reportar o status do servidor inativo com 30 dias de antecedência e enviar um aviso com 60 dias de antecedência para a administração local de TI e para o proprietário identificado.  Se nenhum proprietário for identificado, a busca começa para valer.

Após atingir 90 dias de desempenho inativo contínuo, o servidor é reportado para os administradores de TI apropriados, com a compreensão que ao atingir 120 dias de status inativo, o gerente de instalações e/ou o gerente de TI pode inverter o comutador para desligar o servidor. Após alcançar 150 dias de inatividade, o sistema DCIM irá enviar uma notificação avisando do desligamento iminente. Em 180 dias, a ferramenta DCIM irá desligar quaisquer dispositivos que permaneçam no modo inativo.

Suas regras de uso e políticas de desligamento irão variar. Eu sugiro que 90 dias é muito tempo exceto talvez para uma instalação inicial, e neste caso pode ser tempo de estabelecer políticas de aprovação mais restritas para a compra e implementação de novos hardwares e softwares de TI.  Considere um programa de 30/60/90 dias com o DCIM tendo total autonomia para desligar quaisquer servidores que permaneçam inativos continuamente por 90 dias.

Temos os recursos básicos para automatizar a identificação, reporte e desligamento de servidores zumbis.  Tudo o que resta é remover o servidor, fazer uma limpeza de dados minuciosa, e devolver ao fornecedor (ou a um terceiro autorizado) para o descarte responsável.  Neste ínterim, limpamos o tão necessário espaço no data center junto com a energia e refrigeração de missão crítica para fazer espaço para servidores novos, mais robustos, capazes de rodar o volume de trabalho vital da empresa.  Agora você pode efetivamente automatizar um componente chave do Energy Logic 2.0.

Um pensamento final: a segurança-cibernética tem que ser uma prioridade.  Por favor considere as implicações associadas com a infraestrutura conectada em rede conforme malfeitores espreitam na internet. Você pode considerar uma rede fora de banda para sua infraestrutura de missão crítica. Fale com seu especialista em segurança DCIM sobre mudar para além dos firewalls.