22.04.2020

Мониторинг в ЦОДе: как мы меняли старую BMS на новую. Часть 2

В первой части мы рассказали о том, почему решили поменять старую BMS-систему в наших ЦОДах на новую. И не просто поменять, а разработать с нуля под свои требования. Во второй части рассказываем, как мы это делали

В первой части мы рассказали о том, почему решили поменять старую BMS-систему в наших ЦОДах на новую. И не просто поменять, а разработать с нуля под свои требования. Во второй части рассказываем, как мы это делали.

Анализ рынка

С учетом описанных в первой части пожеланий и решения отказаться от обновления существующей системы мы написали ТЗ для поиска решения на рынке и сделали запросы в несколько крупных компаний, занимающихся только созданием промышленных систем SCADA.

Первые же ответы от них показали, что лидеры рынка систем мониторинга преимущественно продолжают работать на железных серверах, хотя процесс миграции в облака в этом сегменте уже начался. Что касается резервирования виртуальных машин – эту опцию не поддерживал никто. Более того, складывалось ощущение, что никто из заметных на рынке разработчиков не продемонстрировал даже понимания необходимости резервирования: «облако же не падает» был наиболее частый ответ. Фактически нам предлагали разместить мониторинг ЦОДа в облаке, физически находящемся в этом же ЦОДе.

Тут надо сделать небольшое отступление о процессе выбора подрядчика. Цена, конечно, имеет значение, но во время любого тендера на реализацию сложного проекта, на стадии диалога с поставщиками ты начинаешь чувствовать, кто из кандидатов более заинтересован и способен реализовать его.

Это особенно заметно на сложных проектах.

По характеру уточняющих вопросов к ТЗ можно разделить подрядчиков на заинтересованных просто продать (ощущается стандартный напор менеджера по продажам) и на заинтересованных в том, чтобы разработать продукт, услышав и поняв заказчика, внести конструктивные правки в ТЗ еще до финального выбора (даже несмотря на реальный риск улучшить чужое ТЗ и проиграть тендер), в конце концов просто готовых принять профессиональный вызов и сделать хороший продукт.

Все это заставило нас обратить внимание на относительно небольшого локального разработчика – группу компаний «Санлайн», который откликнулся на большинство наших требований сразу и был готов реализовать все потребности касательно новой BMS.

Риски

Пока большие игроки пытались понять, что же мы хотим, и вели с нами неспешную переписку с привлечением специалистов уровня пресейл, локальный девелопер назначил встречу в нашем офисе с участием своей технической команды. На этой встрече подрядчик еще раз продемонстрировал желание участвовать в проекте и – главное – объяснил, как требуемая система будет реализована.

Перед встречей мы видели два риска работы с командой, не имеющей за спиной ресурса большой национальной или международной компании:

  • Специалисты могли переоценить свои возможности и в результате просто не справиться, например, будут использовать сложный софт или спроектируют невыполнимые алгоритмы резервирования.
  • После реализации проекта команда проекта может распасться и, следовательно, поддержка продукта окажется под угрозой.

Чтобы минимизировать эти риски, мы пригласили на встречу собственных специалистов по разработке. Сотрудники потенциального подрядчика были тщательно опрошены на предмет того, на чем строится система, как планируется реализовывать резервирование и по другим вопросам, в которых мы, как служба эксплуатации, недостаточно компетентны.

Вердикт был положительным: архитектура имеющейся уже платформы BMS современна, проста и надежна, может быть доработана, предлагаемая схема резервирования и синхронизации логична и работоспособна.

С первым риском справились. Второй исключили, получив от подрядчика подтверждение о готовности передать нам исходники кода системы и документации, а также выбрав язык программирования Python, хорошо знакомый нашим специалистам. Это гарантировало нам возможность поддерживать систему своими силами без каких-либо затруднений и длительного периода обучения сотрудников в случае ухода компании-разработчика с рынка.

Дополнительным плюсом платформы являлось то, что она была реализована в Docker контейнерах: в этой среде функционируют ядро, веб-интерфейс и БД продукта. Такой подход дает множество преимуществ, включая предустановку настроек для высочайшей скорости развертывания решения по сравнению с «классикой» и простое добавление в систему новых устройств. Принцип «все вместе» максимально упрощает внедрение системы: достаточно распаковать систему и можно сразу ее эксплуатировать.

С таким решением проще делать копии системы, а усовершенствовать ее и реализовывать апгрейды можно в отдельной среде, без остановки работы решения в целом.

После того как оба риска были минимизированы, подрядчик предоставил КП. В нем были проработаны все самые важные для нас параметры системы BMS.

Резервирование

Новая BMS-система должна была находиться в облаке, на виртуальной машине.

Никакого железа, никаких серверов и всех связанных с этой моделью развертывания неудобств и рисков – облачное решение позволяло нам избавиться от них навсегда. Было решено, что система будет работать в нашем облаке на двух площадках ЦОДа в Санкт-Петербурге и Москве. Это две полностью функциональные системы, работающие в режиме active standby с доступом для всех авторизованных специалистов.

Две системы страхуют друг друга, обеспечивая полный резерв и по вычислительным мощностям, и по каналам передачи данных. Также настроены дополнительные меры безопасности, включая резервное копирование данных и каналов, систем, виртуальных машин в целом, и отдельное резервное копирование БД раз в месяц (самый ценный ресурс в перспективе управления и анализа).

Отметим, что резервирование как опция BMS-решения было разработано специально под наш запрос. Сама схема резервирования выглядела вот так:

 

Support

Важнейший момент для эффективной эксплуатации BMS-решения – техподдержка.

Здесь все просто: новая система стоила бы нам по этому показателю 35 000 руб. в месяц за SLA «реакция в течение 8 часов», то есть 35 000 х 12 / 80 = $5 250 в год. Первый год – бесплатно.

Для сравнения: поддержка старой BMS от вендора обходилась в $18 000 долларов в год с увеличением суммы за каждое новое добавленное устройство! При этом выделенного менеджера компания не предоставляла, все взаимодействие происходило через менеджера по продажам, который заинтересован в нас как в потенциальном покупателе с соответствующим акцентом в обработке запросов.

За меньшие деньги мы получили полноценную поддержку продукта, с аккаунт-менеджером, который принимал бы участие в разработке продукта, с единой точкой входа и т.д. Поддержка становилась на порядок более гибкой – благодаря прямому доступу к разработчикам для оперативных корректировок по любым аспектам работы системы, интеграции через API и т.д.

Обновления

По предложенному КП в новой BMS все обновления включены в стоимость поддержки, т.е. не требуют дополнительной оплаты. Исключение составляет разработка дополнительной функциональности, сверх той, что указана в ТЗ.

Старая система предполагала оплату как за обновление встроенного бесплатного ПО (типа Java), так и за исправление ошибок. Отказаться от этого было нельзя, при отсутствии обновлений система в целом «тормозила» из-за старых версий внутренних компонентов.

И, само собой, нельзя было обновить ПО без покупки пакета поддержки.

Гибкий подход

Еще одно принципиальное требование касалось интерфейса. Мы хотели обеспечить доступ к нему через веб-браузер из любой точки, без обязательного присутствия инженера на территории ЦОДа. Кроме того, мы стремились к созданию анимированного интерфейса, чтобы динамика функционирования инфраструктуры была более наглядной для дежурных инженеров.

Также в новой системе нужно было обеспечить поддержку формул для обсчета работы виртуальных датчиков в инженерных системах – например, для оптимального распределения электрических мощностей по стойкам с оборудованием. Для этого нужно иметь в своем распоряжении все привычные математические операции, применимые к показателям датчиков.

Далее, требовался доступ к базе данных SQL с возможностью брать из нее нужные данные о работе оборудования – а именно, все записи о мониторинге двух тысяч устройств и двух тысяч виртуальных датчиков, генерирующих примерно 20 тысяч переменных.

Нужен был также модуль учета оборудования в стойке, дающий графическое представление расположения устройств в каждом юните с подсчетом общего веса «железа», ведением библиотеки устройств и подробной информацией о каждом элементе.

Согласование ТЗ и подписание договора

На тот момент, когда было необходимо начинать работу над новой системой, переписка с «большими» компаниями все еще была очень далека от обсуждения стоимости их предложений, поэтому мы сравнили полученное КП с затратами на обновление старой БМС (см. первую часть), и в результате оно оказалось более привлекательным по цене и соответствующим нашим требованиям.

Выбор был сделан.

После выбора подрядчика юристы стали составлять договор, а технические команды с обеих сторон шлифовать ТЗ. Как известно, подробное и грамотное ТЗ – это основа успеха любых работ. Чем больше конкретики в ТЗ, тем меньше разочарований вроде «а мы хотели не так».

Приведу два примера уровня детализации требований в ТЗ:

  • Дежурные ЦОД наделены полномочиями добавлять в BMS новые устройства, чаще всего это PDU. В старой BMS это был уровень «администратора», позволяющий в том числе менять уставки переменных всех устройств, и разделить функции было невозможно. Нас это не устраивало. В имеющейся базовой версии новой платформы схема была аналогичной. Мы сразу указали в ТЗ, что хотим разделить эти роли: уставки должен менять только уполномоченный сотрудник, но дежурные должны и дальше иметь возможность добавлять устройства. Эта схема и была принята к реализации.
  • В любой стандартной BMS есть три типовые категории уведомлений: КРАСНАЯ – надо немедленно реагировать, ЖЕЛТАЯ – можно наблюдать, СИНЯЯ – «Информационная». Мы традиционно использовали «синие» уведомления для мониторинга превышения коммерческих параметров, например, превышение лимита мощности стойки клиента. Этот тип уведомлений в нашем случае был предназначен для менеджеров и не был интересен службе эксплуатации, но в старой BMS регулярно засорял список активных инцидентов и мешал оперативной работе. Саму логику и цветовую дифференциацию штанов уведомлений мы посчитали удачной и сохранили, однако в ТЗ специально указали, что «синие» уведомления должны, не отвлекая дежурных, беззвучно «сыпаться» в отдельный раздел, где ими будут заниматься коммерческие специалисты.

С аналогичной степенью детализации были прописаны форматы построения графиков и выведения отчетов, очертания интерфейсов, перечень устройств, которые надо было мониторить и еще множество других вещей.

Это была по-настоящему творческая работа трех рабочих групп – службы заказчика, которая диктовала свои требования и условия; технических специалистов с обеих сторон, в задачу которых входило преобразование этих условий в техническую документацию; команды программистов подрядчика, которые реализовывали требования заказчика по разработанной технической документации… В итоге что-то из наших непринципиальных требований мы адаптировали под функционал уже имеющейся платформы, что-то подрядчик обязался дописать под нас.

Параллельная работа двух систем

Настало время реализации. На практике это означало, что мы даем подрядчику возможность развернуть прототип BMS в нашем виртуальном облаке и предоставляем сетевой доступ ко всем устройствам, требующим мониторинга.

При этом новая система еще не была готова к работе. На данном этапе для нас было важно сохранить мониторинг в старой системе и одновременно дать доступ к устройствам новой системе. Невозможно нормально построить систему, не видя в ней устройств, которые в свою очередь нельзя отключить от мониторинга старой системой.

Выдержат ли устройства одновременный опрос двумя системами, было неочевидно без реальных испытаний. Существовала вероятность, что двойной одновременный опрос приведет к частым отказам в ответах от устройств и мы получим множество ошибок по недоступности устройств, что в свою очередь заблокирует работу старой системы мониторинга.

Сетевой отдел прокинул виртуальные маршруты от прототипа новой BMS, развернутого в облаке, к устройствам, и мы получили результаты:

  • устройства, подключенные по протоколу SNMP, практически не выпадали в дисконнект из-за одновременных обращений,
  • устройства, подключенные через шлюзы по протоколам modbas-TCP, имели проблемы, которые были решены разумным снижением частоты их опроса.

А дальше мы стали наблюдать, как на наших глазах строится новая система, в ней появляются уже знакомые нам устройства, но в другом интерфейсе – удобном, быстром, доступном даже с телефона.

О том, что получилось в итоге, мы расскажем в третьей части нашей статьи.

News and publications

You may also be interested in

Write to us

How we optimized customer data center management

Data center is a complex IT and engineering object, which requires professionalism at all levels of management: from managers to technical specialists and executors of maintenance works. Here's how we helped our client put operational management in corporate data centers in order.
 

Taras Chirkov, Head of Data Center in St. Petersburg  in St. Petersburg 

Konstantin Nagorny, chief engineer of data center in St. Petersburg.  in St. Petersburg 

Data center is a complex IT and engineering object, which requires professionalism at all levels of management: from managers to technical specialists and executors of maintenance works. Here's how we helped our client put operational management in corporate data centers in order.  

Management is in the lead 

The most advanced and expensive IT equipment will not bring the expected economic benefits if proper processes of engineering systems operation in the data center, where it is located, are not established.  

The role of reliable and productive data centers in today's economy is constantly growing along with the requirements for their uninterrupted operation. However, there is a big systemic problem on this front.  

A high level of "uptime" - failure-free operation of a data center without downtime - depends very much on the engineering team that manages the site. And there is no single formalized school of data center management.  

And there is no single formalized school of data center management.    

Nationwide  

In practice, the situation with the operation of data centers in Russia is as follows.  

Data centers in the commercial segment usually have certificates confirming their management competence. Not all of them do, but the very specifics of the business model, when a provider is responsible to the client for the quality of service, money and reputation in the market, obligates them to own the subject. 

The segment of corporate data centers that serve companies' own needs lags far behind commercial data centers in terms of operational quality. The internal customer is not treated as carefully as the external customer, not every company understands the potential of well-configured management processes. 

Finally, government departmental data centers - in this regard, they are often unknown territory due to their closed nature. An international audit of such facilities is understandably impossible. Russian state standards are just being developed.  

This all translates into a "who knows what" situation. "Diverse" composition of operation teams composed of specialists with different backgrounds, different approaches to the organization of corporate architecture, different views and requirements to IT departments.  

There are many factors that lead to this state of affairs, one of the most important is the lack of systematic documentation of operational processes. There are a couple of introductory articles by Uptime Institute which give an idea of the problem and how to overcome it. But then it's necessary to build the system by your own efforts. And not every business has enough resources and competence for that.  ⠀⠀  

Meanwhile, even a small systematization of management processes according to industry best practices always yields excellent results in terms of improving the resilience of engineering and IT systems.  

Case: through thorns to the relative order 

Let's illustrate by the example of an implemented project. A large international company with its own data center network approached us. The request was for help to optimize the management processes at three sites where IT systems and business-critical applications are deployed.  

The company had recently undergone an audit of its headquarters and received a list of inconsistencies with corporate standards with orders to eliminate them. We were brought in as a consultant for this as a bearer of industry competence: we have been developing our own data center management system and have been educating on the role of quality in operational processes for several years.  

Communication with the client's team began. The specialists wanted to get a well-established system of data center engineering systems operation, documented on the processes of monitoring, maintenance and troubleshooting. All this had to ensure optimization of the infrastructure component in terms of IT equipment continuity.  

And here began the most interesting part.  

Know thyself 

To assess the level of data centers in terms of compliance with standards, you need to know the exact requirements of the business to IT systems: what is the level of internal SLA, the allowable period of equipment downtime, etc.  

It became clear right away that the IT department did not know exactly what the business wanted. There were no internal criteria of service quality, no understanding of the logic of their own infrastructure.  

Colleagues simply had no idea what the permissible downtime for IT-related operations was, what the optimal system recovery time in case of a disaster was, or how the architecture of their own applications was structured. For example, we had to figure out whether a "crash" of one of the data centers would be critical to the application, or if there were no components affecting the application.  

Without knowing such things, it is impossible to calculate any specific operational requirements. The client recognized the problem and increased coordination between IT and the business to develop internal requirements and establish relationships to align operations.  

Once an understanding of the IT systems architecture was achieved, the team was able to summarize the requirements for operations, contractors, and equipment reliability levels.  

Improvements in the process 

Our specialists traveled to sites to assess infrastructure, read existing documentation, and checked the level of compliance of data center projects with actual implementation.  

Interviews with the responsible employees and their managers became a separate area of focus. They told what and how they do in different work situations, how the key processes of engineering systems' operation are arranged.  

After starting the work and getting acquainted with the specifics of the task the client "gave up" a little: we heard the request "just to write all the necessary documentation", quickly and without deep diving into the processes.  

However, proper optimization of data center "engineering" management implies the task to teach people to properly assess the processes and write unique documentation for them based on the specifics of the object.  

It is impossible to come up with a working document for a specific maintenance area manager - unless you work with him at the site continuously for several months. Therefore this approach was rejected: We found local leaders who were willing to learn themselves and lead their subordinates.  

Having explained the algorithm of documents creation, requirements to their contents and principles of instructions ecosystem organization, for the next six months we controlled the process of detailed writing of documentation and step-by-step transition of the personnel to work in a new way. 

This was followed by a phase of initial support for work on the updated regulations, which lasted one year in a remote format. Then we moved on to training and drills - the only way to put the new material into practice.  

What's been done 

In the process, we were able to resolve several serious issues.  

First of all, we avoided double documentation, which the client's employees feared. To this end, we combined in the new regulations the regulatory requirements applied to various engineering systems as standard (electrics, cooling, access control), with industry best practices, creating a transparent documentation structure with simple and logical navigation.   

The principle of "easy to find, easy to understand, easy to remember" was complemented by the fact that the new information was linked to the old experience and knowledge of the employees. 

Next, we reshuffled the staff of service engineers: several people turned out to be completely unprepared for the change. The resistance of some was successfully overcome in the course of the project through the demonstration of benefits, but a certain percentage of employees turned out to be untrained and unresponsive to new things.  

But we were surprised by the company's frivolous attitude to its IT infrastructure: from the lack of redundancy of critical systems to the chaos in the structure and management.  

In 1.5 years the engineering systems management processes have been pumped up to the level that allowed the company's specialists to successfully report "for quality" to the auditors from the headquarters.  

With the support of the operating component development pace the company will be able to pass any existing certification of data centers from leading international agencies.  

Summary 

In general, the prospects of consulting in the field of operational management of data centers, in our opinion, are the brightest.  

The process of digitalization of the economy and the public sector is in full swing. Yes, there will be a lot of adjustments in the launch of new projects and plans for the development of old ones, but this will not change the essence - the operation should be improved at least to improve the efficiency of already built sites.  

The main problem here: many managers do not understand what thin ice they are walking on, not paying proper attention to this point. The human factor is still the main source of the most unpleasant accidents and failures. And it needs to be explained.  

Government data center projects are also becoming more relevant now and require increased attention in terms of operations: the scope of government IT systems is growing. Here, too, the development and introduction of a system of standardization and certification of sites will be required.  

When the requirements to public data centers in Russia at the level of legislation will be reduced to a standard, it can be applied to commercial data centers, including for the placement of public IT resources.  

The work in this area is ongoing, we are participating in this process in consultation with the Ministry of Digital and by building competencies for teaching courses on data center operation at the ANO Data Center. There is not much experience on such tasks in Russia, and we believe that we should share it with colleagues and clients. 

Мониторинг в ЦОДе: как мы меняли старую BMS на новую. Часть 2

BEST, money transfer and payments operator

business challenge

The customer faced a technical issue with a persistent BGP session flag with Linxdatacenter hardware. We examined the problem and found out that one of customer’s hosts was under a DDoS attack.

Because of the distributed nature of the attack, traffic couldn’t be filtered effectively, and disconnecting the host from the external network wasn’t an option. The attack stopped after changes in the server configuration, but resumed the day after. A 5.5 Gbps attack overloaded the junctions with internet providers, affecting other Linx Cloud users. To mitigate the effects of the attack, we employed a dedicated DDoS protection service.

Solution

To ensure the continuous availability of resources hosted in Linx Cloud, we rerouted all the customer’s traffic through StormWall Anti-DDoS system. The attack was stopped within half an hour. To prevent future cyberattacks, we organized all connections to the customer’s resources through the StormWall network.

client:

BEST, money transfer and payments operator

business challenge

The customer faced a technical issue with a persistent BGP session flag with Linxdatacenter hardware. We examined the problem and found out that one of customer’s hosts was under a DDoS attack.

Because of the distributed nature of the attack, traffic couldn’t be filtered effectively, and disconnecting the host from the external network wasn’t an option. The attack stopped after changes in the server configuration, but resumed the day after. A 5.5 Gbps attack overloaded the junctions with internet providers, affecting other Linx Cloud users. To mitigate the effects of the attack, we employed a dedicated DDoS protection service.

Solution

To ensure the continuous availability of resources hosted in Linx Cloud, we rerouted all the customer’s traffic through StormWall Anti-DDoS system. The attack was stopped within half an hour. To prevent future cyberattacks, we organized all connections to the customer’s resources through the StormWall network.

Thank you for your inquiry, we will get back to you shortly!