Get best of the week

Monitoramento no data center: como alteramos o antigo BMS para um novo. Parte 1



O que é um BMS


O sistema de monitoramento de sistemas de engenharia no data center é um elemento-chave da infraestrutura que afeta diretamente um indicador tão importante para o data center, como a velocidade da resposta do pessoal a emergências e, portanto, a duração da operação ininterrupta. 

Os sistemas de monitoramento BMS (Building Monitoring System) são oferecidos por muitos fornecedores globais de equipamentos de data center. Durante o trabalho do Linxdatacenter na Rússia, tivemos a oportunidade de nos familiarizar com diferentes sistemas e encontrar abordagens diametralmente opostas de fornecedores para operar esses sistemas. 

Contamos como atualizamos completamente nosso sistema BMS no ano passado e por quê.  

A raiz do problema


Tudo começou há 10 anos com o lançamento do data center Linxdatacenter em São Petersburgo. O sistema BMS, de acordo com os padrões da indústria daqueles anos, era um servidor físico com software instalado acessado por meio de um programa cliente (o chamado cliente “grosso”). 

Havia poucas empresas oferecendo essas soluções na época. Seus produtos eram o padrão, a única resposta para uma solicitação existente. E devemos dar a eles o que lhes é devido: hoje e hoje, os líderes de mercado como um todo lidam com sua tarefa básica - a entrega de soluções funcionais para a operação de data centers. 

A escolha lógica para nós foi a solução BMS de um dos maiores fabricantes do mundo. O sistema selecionado naquele momento atendeu a todos os requisitos para monitorar uma instalação de engenharia integrada, que é um data center. 

No entanto, com o tempo, os requisitos e expectativas dos usuários (ou seja, nós, operadores de data center) das soluções de TI mudaram. E grandes fornecedores, como mostra a análise do mercado de soluções propostas, não estavam prontos para isso.

O mercado corporativo de TI foi fortemente influenciado pelo setor de B2C. Hoje, as soluções digitais devem garantir a conveniência do usuário final - esse é o objetivo que os desenvolvedores estabeleceram. Isso é evidente na melhoria das interfaces do usuário (UI) e na qualidade da experiência do usuário (UX) de muitos aplicativos corporativos. 

Uma pessoa se acostuma a confortar tudo o que se relaciona às ferramentas digitais na vida cotidiana e faz as mesmas exigências nas ferramentas que usa para tarefas de trabalho. As pessoas esperam dos aplicativos corporativos a mesma visibilidade, intuitividade, simplicidade e transparência disponíveis em serviços financeiros, chamadas de táxi ou compras on-line. Os profissionais de TI que implementam soluções no ambiente corporativo também se esforçam para obter todos os "presentes" modernos: implantação e dimensionamento simples, tolerância a falhas e opções de personalização ilimitadas. 

Os principais fornecedores internacionais geralmente ignoram essas tendências. Com base em seus muitos anos de autoridade no setor, as empresas que trabalham com clientes geralmente são categóricas e inflexíveis. A ilusão de sua própria indispensabilidade não permite que eles vejam como as empresas de tecnologia jovens aparecem literalmente debaixo do nariz, oferecendo soluções alternativas personalizadas para um cliente específico e sem pagar demais pela marca.

Desvantagens do antigo sistema BMS 


A principal desvantagem da solução obsoleta de BMS existente para nós foi seu trabalho lento. A investigação de vários eventos relacionados à reação insuficientemente rápida do pessoal de plantão nos ajudou a entender que algumas vezes os eventos eram exibidos no sistema BMS com um longo atraso. Ao mesmo tempo, o sistema não estava sobrecarregado ou com defeito, apenas as versões de seus componentes (por exemplo, JAVA) estavam desatualizadas e não podiam funcionar corretamente com novas versões de sistemas operacionais sem atualizações. Só foi possível atualizá-los junto com o sistema BMS, enquanto o fornecedor não forneceu a continuidade automática da versão, ou seja, para nós o processo seria quase tão trabalhoso quanto a transição para o novo sistema, e a nova solução reteria algumas das deficiências do antigo.  

Adicionamos aqui algumas "coisinhas" mais desagradáveis:

  1. « IP- – »; 
  2. ( BMS);
  3. ; 
  4. «» , ;
  5. «» , . – ;
  6. «» , , ;
  7. - , , - ;
  8. – -«» . – ;

    :



  9. – , , ; 
  10. - (, );
  11. - BMS . 


BMS


Diante do exposto, nossos principais requisitos são os seguintes:

  1. Duas máquinas independentes mutuamente redundantes com sincronização automática, executando em duas plataformas de nuvem diferentes em diferentes datacenters (no nosso caso, os datacenters Linxdatacenter em São Petersburgo e Moscou);
  2. Adicione novos dispositivos gratuitamente;
  3. Atualização gratuita do software e seus componentes (com exceção das melhorias funcionais);
  4. Código-fonte aberto que nos permite oferecer suporte independente ao sistema em caso de problemas do lado do desenvolvedor;
  5. A capacidade de receber e usar dados do BMS, por exemplo, no site ou em sua conta pessoal;
  6. Acesso via navegador WEB sem um cliente "grosso";
  7. Usando contas de usuário de domínio para acessar o BMS;
  8. A presença de animação e muitos mais pequenos e pouco desejos que se materializaram em uma declaração detalhada do trabalho.


Última palha




Naquele momento, quando percebemos que o data center havia superado seu BMS, a solução mais óbvia era atualizar o sistema existente. "Eles não trocam de cavalo no cruzamento", certo? 

No entanto, grandes empresas, como regra, não oferecem uma modificação personalizada de suas décadas de soluções "polidas" vendidas em dezenas de países. Enquanto empresas jovens estão testando a idéia ou protótipo de um produto futuro para potenciais consumidores e confiando nas análises de usuários no desenvolvimento de produtos, as empresas continuam a vender licenças para um produto que antes era muito legal, mas, infelizmente, desatualizado e não flexível.

E sentimos a diferença de abordagem sobre nós mesmos. No decorrer da correspondência com o fabricante do antigo BMS, rapidamente ficou claro que a atualização do sistema existente pelo fornecedor resultaria na compra de um novo sistema com uma transferência semiautomática da base, alto custo e armadilhas durante a transferência, que nem o próprio fabricante poderia prever. Obviamente, nesse caso, o custo do suporte técnico da solução atualizada aumentou e permaneceu a necessidade de comprar licenças para expansão.

E a pior parte é que o novo sistema não pôde satisfazer totalmente nossos requisitos de redundância. O sistema BMS atualizado poderia ser implementado, como queríamos, em uma plataforma em nuvem, o que nos permitiria abandonar o hardware, mas a opção de reserva não estava incluída no preço. Para fazer backup dos dados, teríamos que comprar um segundo servidor BMS virtual e um conjunto adicional de licenças. A um custo de uma licença de cerca de US $ 76 e o ​​número de endereços IP de 1000 unidades, US $ 76.000 de despesas adicionais acumulam apenas a licença da máquina de backup. 

A "cereja" na nova versão do BMS foi a necessidade de comprar licenças adicionais "para todos os dispositivos" - mesmo para o servidor principal. Aqui é necessário esclarecer que existem dispositivos conectados ao BMS através de gateways. O gateway tem um endereço IP, mas controla vários dispositivos (em média 10). No antigo BMS, isso exigia uma licença por endereço IP do gateway, as estatísticas eram mais ou menos assim: "Endereços / licenças IP 1000, dispositivos 1200". O BMS atualizado funcionou com um princípio diferente e as estatísticas se pareceriam com "endereços IP 1000, dispositivos / licenças 1200". Ou seja, o fornecedor da nova versão mudou o princípio de atribuição de licenças e tivemos que comprar aproximadamente 200 licenças adicionais. 

O orçamento da "atualização", como resultado, consistiu em quatro pontos: 

  • o custo da versão em nuvem e seus serviços de migração; 
  • licenças adicionais para o pacote existente para dispositivos conectados através de gateways;
  • custo da versão em nuvem de backup;  
  • conjunto de licenças para a máquina de backup. 

O custo total do projeto foi superior a US $ 100.000! E isso sem mencionar a necessidade de comprar licenças para novos dispositivos no futuro.

No final, percebemos que seria mais fácil para nós - e talvez mais barato - solicitar um sistema criado do zero, levando em consideração todos os nossos requisitos e prevendo a possibilidade de modernização no futuro. Mas aqueles que desejavam desenvolver um sistema tão complexo ainda precisavam encontrar, comparar propostas, escolher e seguir com o finalista o caminho do TK à implementação ... Leia sobre isso na segunda parte do material muito em breve. 

More articles:


All Articles