система dcim что это
Управление инфраструктурой ЦОД: выбираем оптимальное DCIM-решение
Мы, компания King Servers стараемся автоматизировать все то, что можно автоматизировать для высвобождения ресурсов и времени. Конечно, автоматизация автоматизации рознь, здесь нужно подходить к делу обстоятельно и осторожно. О том, как можно использовать автоматизацию как инструмент для повышения работы дата-центра, мы уже писали.
Сегодня предлагаем обсудить такой важный вопрос, как выбор DCIM-решения для дата-центра. В целом, этот термин обозначает интеграцию информационной технологии и функций управления для централизации контроля, управления и планирования работы основных систем инфраструктуры дата-центра. Такое решение обычно нужно для инженерной команды ДЦ.
Зачем нужен DCIM?
В первую очередь, речь идет о том, что удачно выбранное и настроенное DCIM-решение позволяет повысить эффективность эксплуатации как всего дата-центра, так и отдельных его элементов. Вследствие этого падает стоимость IT-сервиса при пересчете на одного пользователя в единицу времени. В перспективе, это позволяет улучшить надежность работы ЦОД с одновременным улучшением сервисов, предоставляемых пользователям. Еще одна приятна сторона — снижение операционных расходов на эксплуатацию ЦОД.
Что касается ключевых возможностей DCIM, которые нужны в первую очередь, то здесь мнения специалистов расходятся.
В этом году свое мнение по поводу необходимой функциональности DCIM опубликовали три известных аналитических агентства: Gartner, 451 Research, IDC.
Что касается первого агентства, то его специалисты посчитали необходимыми функциями DCIM решения следующие:
При работе с любым сценарием выбранное решение должно работать со всей структурой дата-центра, включая электрические, механические, электронные элементы, системы хранения данных и все прочее. Это нужно для того, чтобы операторы ЦОД беспрепятственно круглосуточно получали всю доступную информацию, которая может оказаться полезной. При этом DCIM-система должна уметь работать как со старыми, так и с новыми устройствами, протоколами и стандартами.
Чтобы получить больше информации, такая система должна быть оснащена как основными, так и вспомогательными датчиками. Чаще всего используются системы, способные:
Выбираем DCIM
Если учитывать все, что уже сказано выше, при выборе DCIM-решения для своего ДЦ стоит сделать вот что:
Автоматизация DCIM или инвентаризация ЦОД
DCIM (Data center infrastructure management) — это программное обеспечение для визуализации и управления физической инфраструктурой ЦОД (центра обработки данных). В Интернете на эту тему написано много, разные поставщики предлагают решения весьма широких диапазонов по цене и функциональности. Но основа у таких решений одна: все они должны, как минимум, хранить точное расположение оборудования в стойках ЦОД и на основе данных о расположении (и других данных) предоставлять свои сервисы.
Вопрос о том, как вносить в DCIM информацию о размещении оборудования в стойках, и хочется осветить в этой статье. Я умышленно не буду называть имена поставщиков решений, а сконцентрируюсь только на технической стороне дела.
Начнем с самого простого способа: сотрудник ЦОД с тетрадкой обходит все стойки и зарисовывает реальное положение всяких серверов, свитчей и маршрутизаторов, а затем переносит данные из тетрадки в DCIM. Самый продвинутый вариант такого способа — ходить с iPhone между стоек и с помощью специального клиента DCIM (а такие в самом деле имеются) пальцем перетаскивать оборудование по стойкам.
Следующий шаг автоматизации — оснастить оборудование оптически распознаваемыми метками со штрихкодом, DataMatrix или QR-кодом. Понятно, что считывать метки с помощью сканера или смартфона удобнее и быстрее, чем художестовать в тетрадке.
Похожий, но более быстрый (и более дорогой) способ использует RFID метки.
Принцип работы очевиден.
Все выше описанные методы не позволяют понять, на какой высоте в стойке (в каком юните) установлено устройство. А для правильного заполнения базы данных DCIM это все-таки необходимо. Поэтому придумали парочку улучшений в применении RFID меток и ручного RFID считывателя. Одна американская компания предложила установить RFID метки на каждый юнит стойки. И когда считываешь RFID метку оборудования, заодно определяешь высоту, на которой это оборудование установлено. Российское изобретение предлагает сходный функционал.
В этом варианте наверху и внизу стойки устанавливаются дополнительные RFID метки, при этом юниты стойки должны быть полностью заполнены (для ЦОД применение заглушек пустых юнитов всё-равно необходимо для правильного охлаждения). Верхняя RFID метка означает начало сканирования стойки, нижняя завершение, а информация о порядке считывания меток в совокупности с высотой каждой единицы оборудования (очевидно, что идентификатор позволяет получить все данные об оборудовании) дает возможность четко определить карту размещение оборудования в стойке.
Большей степени автоматизации, но без точной локализации оборудования внутри стойки, можно достичь, используя тележку с RFID считывателем и антеннами.
Повозил тележку между стоек, и определил, что находится в каждой из стойке.
Другие способы инвентаризация ЦОД (заполнения базы данных DCIM) практически не требуют участия персонала. Отслеживание перемещения оборудования между стойками происходит автоматически. Один из самых простых вариантов — в каждой стойке разместить своё приемно-передающее устройство, а каждое оборудование оснастить собственным приемо-передатчиком электромагнитных волн с уникальным идентификатором. Причем приемо-передатчик может быть инфракрасным модулем, пассивной или активной RFID меткой и т.д… Понятно, что изменяя мощность излучения, можно добиться того, чтобы считывались только те идентификаторы меток, которые находятся вблизи антенны конкретной стойки.
Естественным развитием выше описанного способа является многоэлементная составная антенна, которая излучает только в пределах одного юнита стойки, что позволяет знать местоположение каждой «железки» с точностью до юнита.
То есть антенна считывает только идентификатор приемно-передающего устройства того оборудования, которое установлено в данный юнит стойки.
Сходный принцип можно применить, если использовать электрический контакт через разъем. На каждое оборудование установить ключ-таблетку (touch memory, как на домофонах в подъезде), а на каждый юнит стойки установить разъем считывателя «таблетки». Когда оборудование установили в стойку, то «таблетка» с уникальным идентификатором контачит с разъемом, и опять же можно получить размещение оборудования с точностью до юнита.
Тот же результат можно получить другим путем с помощью российского продукта. На рейке каждого юнита стойки можно разместить датчики, которые реагируют на наличие в данном юните установленного оборудования (занято/незанято). Таким образом можно понять, где в стойке установлено какое-то оборудование. А если на оборудовании стоит обычная пассивная RFID метка, то с помощью RFID антенны можно понять, какое конкретно оборудование установили в юниты, где сработали д
В заключении описание системы, которую наблюдал мой приятель русский американец: «была стойка с двумя десятками компьютеров, в сети. Чтобы определить, какой конкретно комп на каком адресе — админ посылал на этот адрес команду открыть CD-диск, и на нужном компе выдвигался дисковод. Бинго!»
DCIM – ключ к управлению ЦОД
Согласно прогнозам аналитиков компании iKS-Consulting, к 2021 году рост числа серверных стоек у крупнейших провайдеров услуг ЦОД в России достигнет 49 тысяч. А их количество в мире, по данным Gartner, уже давно превысило 2,5 миллиона.
Для современных предприятий ЦОД – ценнейший актив. Спрос на ресурсы для хранения и обработки данных постоянно растет, и вместе с ним растут тарифы на электроэнергию. Традиционные системы мониторинга и управления не могут ответить на вопросы, сколько электроэнергии потребляется, кем потребляется и как ее сэкономить. Не помогают они найти ответы и на другие вопросы специалистов по обслуживанию ЦОД:
Именно поэтому на смену устаревшим неинтегрированным системам приходит DCIM – новейшая система мониторинга и управления ЦОД, позволяющая сократить затраты, ответить на поставленные вопросы и решить целый ряд других, не менее важных задач:
DCIM объединяет все компоненты оборудования и ИТ-инфраструктуры на одной платформе и предоставляет полную информацию для принятия решений по управлению и качественному обслуживанию ЦОД.
Система в режиме реального времени мониторит потребляемую мощность, отображает показатели эффективности энергопотребления (PUE), контролирует параметры окружающей среды (температуру, влажность, давление…) и работу информационных ресурсов — серверов, коммутаторов и систем хранения.
Три примера внедрения DCIM-решений
Вкратце опишем, как внедрялась DCIM-система Delta InfraSuite Manager на разных предприятиях и какого результата удалось добиться.
1. Тайваньская компания по разработке полупроводниковых компонентов.
Специализация: разработка интегральных микросхем для беспроводной связи, устройств DVD/Bluray, телевидения высокой четкости.
Задача. Внедрить полноценное DCIM-решение в новом ЦОД среднего размера. Важнейший параметр – непрерывное отслеживание показателя эффективности энергопотребления (PUE). Также предполагалось следить за состоянием всей рабочей среды, систем питания, охлаждения, доступом в помещение, логическими контроллерами и другим оборудованием.
Решение. Установлены три модуля системы Delta InfraSuite Manager (Operation Platform, PUE Energy, Asset). Это позволило интегрировать разрозненные компоненты в единую систему, куда начала поступать вся информация с элементов инфраструктуры ЦОД. Для контроля затрат был разработан виртуальный прибор учета электроэнергии.
Результат:
Несмотря на то что с помощью системы мониторинга и управления ЦОД можно решать широкий спектр задач, первоначально нужно сосредоточиться на главной проблеме – болевой точке бизнеса, где внедрение DCIM принесет максимальную пользу.
2. Индийская компания Tata Communications.
Специализация: крупнейший в мире поставщик телекоммуникационных услуг.
Задача. Для восьми ЦОД, каждый из которых занимает четырехэтажное здание с двумя залами, где установлено по 200 стоек, требовалось создать централизованное хранилище данных об ИТ-оборудовании. Рабочие параметры должны постоянно отслеживаться и выводиться для анализа в режиме реального времени. В частности, важно видеть расход электроэнергии и потребляемую мощность по каждой стойке.
Решение. Развернута система Delta InfraSuite Manager в составе модулей Operation Platform, Asset и PUE Energy.
Результат. Заказчик видит данные о потреблении электроэнергии по всем стойкам и их арендаторам. Получает индивидуальные отчеты по энергопотреблению. Отслеживает рабочие параметры ЦОД в режиме реального времени.
3. Нидерландская компания Bytesnet.
Специализация: поставщик вычислительных сервисов, предоставляющий услуги по размещению и аренде серверов.
Задача. В ЦОД, расположенных в городах Гронинген и Роттердам, требовалось внедрить инфраструктуру энергоснабжения. Показатели PUE в масштабах ЦОД планировалось использовать для разработки мероприятий по повышению энергоэффективности и сокращению затрат.
Решение. Установка модулей Operation Platform и PUE Energy системы Delta InfraSuite Manager и интеграция ряда устройств разных марок для оптимизации мониторинга.
Результат: Персонал получил возможность наблюдать за работой оборудования ЦОД. Показатели PUE обеспечили менеджеров необходимой информацией для повышения эффективности работы и снижения затрат на электроэнергию. Данные об изменяющейся нагрузке на систему охлаждения и другие важные параметры позволили специалистам компании обеспечить доступность критически важных приложений и оборудования.
Модульные DCIM-решения дают возможность внедрять систему поэтапно. Сначала вводится в эксплуатацию первый модуль системы, например для контроля энергопотребления, а затем по порядку все остальные модули.
Будущее за DCIM
DCIM-решения позволяют сделать ИТ-инфраструктуру прозрачной. Вместе с мониторингом мощности это дает возможность минимизировать простои в работе ЦОД, которые дорого обходятся бизнесу. Центрам, приближающимся к пределу своих возможностей, установка DCIM помогает повысить отдачу от существующей инфраструктуры и отсрочить новые финансовые вливания.
Анализируя состояние рабочей среды, имеющуюся мощность и возможности ее наращивания, компании начинают планировать свои возможности, оперируя точными данными. Это помогает избежать финансовых рисков в виде неоправданных капиталовложений.
DCIM-платформа Racks: почему мы отказались от энтерпрайз-решения в пользу самописного приложения
Как вести учет и контроль оборудования, если у тебя более десятка серверных в трех географически разделенных дата-центрах? Как и многие крупные провайдеры, в России и за рубежом, Selectel начал реализовывать DCIM-систему. Однако история с готовым энтерпрайз-решением нам не подошла: попытка адаптировать внешнюю систему под свои потребности с помощью пары скриптов на Python выросла в полноценную самописную DCIM-платформу.
Собственно, о том, как «вылупилась» и развивается DCIM-система, которую мы назвали Racks, мы сегодня и расскажем. Что сейчас может приложение и почему мы в итоге отказались от стороннего решения? Ченджлог подняли руководитель направления DCIM Вячеслав Литвинов и разработчик систем управления инфраструктурой дата-центров Николай Огоров.
Что такое DCIM
Вячеслав Литвинов: Для начала кратко расскажу о том, что такое DCIM, или Data Center Infrastructure Management. Грубо говоря, это многофункциональный инструмент для планирования установки, учета и мониторинга физической инфраструктуры дата-центра — начиная со стоек и заканчивая ПО и сервисами. О DCIM на Хабре писали еще в 2012 году. И хотя технологии шагнули далеко вперед, общая концепция и цель внедрения DCIM остались неизменными.
Основной плюс DCIM-систем состоит в том, что информация о всех активах дата-центров существует в одном месте. При этом каждый человек, имеющий соответствующий уровень доступа, может зайти и посмотреть актуальную картину по физической инфраструктуре. С помощью DCIM мы берем все разрозненные гугл-таблички, которые ведут разные отделы и сотрудники дата-центров, и забываем о них, потому что у нас появляется единый хаб информации.
Так выглядел учет оборудования до введения DCIM.
С возможностью комплексно взглянуть на активы дата-центров появляются новые опции. Теперь, основываясь на «железных» данных, вы можете планировать закупки нового оборудования (о capacity planning мы еще поговорим), оптимизировать ресурсы серверной для более эффективной и экономичной работы, поднять мониторинг систем на новый уровень.
Если говорить про мониторинг, то он — обязательная часть работы любого дата-центра. Но мониторинг базируется на показаниях счетчиков (температуры, электроэнергии и так далее) на текущий момент, без визуализации, без возможности делать ретроспективный анализ и скачивать необходимые отчеты. Поэтому только на системах мониторинга в современном дата-центре далеко не уедешь.
DCIM-системы производят настоящий wow-эффект. Впервые, пожалуй, я познакомился с ними на конференции Data Centre World, которая традиционно проходит в Лондоне. Тогда же решил, что было бы здорово внедрить подобную систему в Selectel.
В чем, собственно, состоит wow-эффект? В DCIM-платформе ты можешь смотреть на машинный зал с «высоты птичьего полета» (floor plan), приближать необходимые объекты, крутить их в 3D, смотреть, где какая единица оборудования, куда она подключена и какой у нее тепловой выхлоп. Добавим сюда еще множество слоев, которые ты можешь добавлять или убирать по своему усмотрению. С DCIM ты понимаешь, что весь дата-центр и контроль над ним сосредоточены в твоем рабочем ноутбуке. Даже в машинный зал ходить не обязательно.
DCIM в Selectel: предпосылки
Вячеслав Литвинов: Примерно три года назад мы решили внедрять DCIM в Selectel. У нас уже было шесть крупных дата-центров — в Санкт-Петербурге, Ленинградской области и Москве — и «Облачная платформа» на собственной инфраструктуре. Клиентов становилось все больше, вместе со спросом увеличивалось количество оборудования. За всем этим нужно было четко следить, и десятки Excel-таблиц, заполняемых разными людьми, с разной периодичностью и усердием, — были не лучшим решением.
Николай Огоров: До того, как я перешел в отдел DCIM, я работал в ИТО (инженерно-технический отдел) и не понаслышке знаю, как сложно работать, когда нет единой точки сбора информации.
Допустим, ты работал в одном дата-центре компании, а потом тебя перевели в другой. Ты приезжаешь и просто не знаешь, где что находится. Приходится тратить время на изучение новой площадки, чтобы выполнять хотя бы базовые задачи. При этом в твоем распоряжении — некоторое количество гугл-доков, информация в которых может быть не всегда актуальна (человеческий фактор: что-то просто могли забыть внести или поправить).
Вот еще немного приветов из прошлого.
Для тех, кто уже не первый год работает, такой уклад становился привычным и даже комфортным — опытный сотрудник ИТО знает серверные как свои пять пальцев. Но «новеньких» это часто сбивало с толку. А Selectel постоянно растет, принимает на работу новых инженеров, и вот для них порог входа из-за отсутствия единой системы повышается.
Вячеслав Литвинов: Сначала мы составили proof of concept нашей будущей DCIM, на бумаге — примерное видение, что необходимо Selectel. Параллельно я занимался тем, что изучал огромное количество существующих систем: смотрел демки, ставил тестовые версии, которые мне предлагали разработчики, анализировал их с точки зрения плюсов и минусов для компании. В итоге нашли подходящую нам систему (упоминать название не буду, это обычная DCIM-система, коих множество). Она была платная, но подходила по всем параметрам: по цене, политике лицензирования (зависела от количества устройств, занесенных в систему), функциональности и другим характеристикам.
Переход к новой парадигме учета инфраструктуры
Вячеслав Литвинов: Итак, у нас появилась система, но в нее нужно было внести все необходимые данные. С самого начала это казалось невозможным: у нас же тысячи серверов и другого оборудования. Мы решили, что восполнять пробелы в информации логично через сотрудников ИТО, так как они ежедневно взаимодействуют с оборудованием в дата-центрах.
Структура объектов DCIM иерархична: сначала нужно воссоздать в ней схему машинного зала, затем «отрисовать» стойки и только после наполнить их серверами и сопутствующим оборудованием. Схемы наших машинных залов (параметры и площадь) были в нашей корпоративной базе знаний в Confluence, а вот расположение стоек нужно было отрисовывать. С этих самых крупных активов мы и начали.
Для отрисовки схемы серверных нам нужно было собрать информацию по комнатам и стойкам — их высоту, габариты, расположение, название. Чтобы не вносить данные руками, мы писали скрипты на Python, которые парсили нужную информацию и заливали в базу автоматически. Затем выбранная система сама рисовала карту машинного зала со всеми стойками.
Как все начиналось.
Добавить в систему серверные стойки, пожалуй, было самой сложной частью работы. По нескольким причинам.
Во-первых, на них очень много хитрых процессов завязано: стойки могут сдаваться клиентам полностью; в них могут быть серверы нескольких клиентов; в стойке могут быть серверы под собственные продукты Selectel. И у разных отделов, имеющих дело с серверами, у разных услуг могут быть свои требования к тому, какой именно должна быть стойка. Для учета всех этих тонкостей приходилось собирать информацию со всех интересантов и стараться уместить это в общей концепции приложения, чтобы оно было полезно всем сотрудникам компании.
Во-вторых, это была первая крупная задача нового отдела DCIM. Не все в компании понимали, что мы делаем и зачем нужны, а мы еще и работы людям подкидывали, тем же инженерам дата-центров. Конечно, мы пытались максимально быстро показывать, какой профит им принесет DCIM. Поэтому активно добавляли новые фичи, генерируя их сами или получая фидбэк от коллег.
Так что этап добавления стоек в DCIM-систему был самым сложным, долгим, но основополагающим. В итоге он задал вектор последующему развитию направления DCIM в Selectel.
Рождение приложения Racks
Николай Огоров: На этом первом этапе мы столкнулись с типичным последствием Change management — люди начали высказывать недовольство изменениями. С гугл-доками ушла привычная многим система обозначений: инженеры привыкли к цветовым маркерам, обозначающим заполненность стойки или услугу Selectel, которая «занимает» сервер. Всю эту информацию можно было получить из DCIM-системы, которую мы выбрали, но она не была связана с цветовой разметкой схемы машинного зала.
После очередной дискуссии с инженерами я решил им показать, что вся информация есть в системе. Написал быстрый скрипт, который как раз позволял «разукрашивать» схему в привычные для сотрудников ИТО цвета, и скинул получившуюся картинку в общий чат. На удивление, решение понравилось даже противникам новой системы, которые в итоге просили реализовать возможность цветовой дифференциации на постоянной основе.
Тот самый результат написанного скрипта: все стойки «разукрашены».
Сначала думали добавить ссылку на скрипт в базу знаний компании в Confluence, но в итоге задумались, а почему бы не создать небольшой сайт, который все это рисует. Выбирая название «сайтика», остановились на Racks – с английского переводится как «стойки», ведь наше одностраничное приложение «разукрашивало» именно их. Тогда мы даже не думали, что это станет первым шагом к нашей собственной DCIM-системе.
Так, 24 октября 2018 года родился Racks, в самом зачаточном состоянии. После стадий торга и принятия коллеги стали уже сами просить какие-то дополнения, необходимые для их работы.
Две системы параллельно
Вячеслав Литвинов: Так получилось, что мы начали вести две системы параллельно. Одна (платформа стороннего вендора) была своеобразной системой учета, вторая (Racks) — приятным функциональным дополнением, утоляющим боль от ухода культуры гугл-доков. В итоге мы пришли к концепции двухкомпонентной DCIM-системы: у нас была «бэкендовая» часть — система учета, база данных – и «фронтендовая» часть, которая не подразумевает добавления информации, — только визуализацию данных.
Что важно знать о Racks
Залипательное видео о том, как развивалось наше приложение
Николай Огоров: Racks мы писали практически с нуля, на стандартном веб-фреймворке, выступающем в роли каркаса. Все остальное делали на собственных идеях, много экспериментировали. Сейчас, возвращаясь к старому коду, я вижу, что какую-то его функциональность может выполнять готовая библиотека. Тогда я оптимизирую его, заменяя ранее написанное новым кодом из библиотеки. Референсом для нас были существующие DCIM-системы – некоторые идеи для Racks мы «подсматривали» у них: использовали терминологию и какие-то характерные обозначения.
Сам сервис сейчас размещен в частном облаке Selectel (на самом старте жил на «железном» сервере). Для хранения и работы с данными мы используем собственные «Облачные базы данных». Сейчас приложение контейнеризировано, а в оркестрации помогает наш Managed Kubernetes. С развитием «Облачных функций», возможно, рассмотрим и их интеграцию. Racks развивается вместе с услугами Selectel. Как только у нас начали появляться управляемые БД и кластеры Kubernetes, мы внедрили их в инфраструктуру приложения.
Программный стек у нас такой: большую часть пишем на Python, а в качестве веб-фреймворка выступает Flask. База данных — PostgreSQL. С точки зрения фронтенда не используется ничего особенного: тут смесь JavaScript и HTML (схемы) с использованием Bootstrap и jQuery. В целом, в планах переписать фронт (рассматриваем переезд на Angular), потому что схемы становятся все более сложным для обычного HTML. Сейчас мы понимаем, что некоторые решения в плане выбора инструментов разработки были ситуативными: на первых порах у нас не было roadmap для Racks и мы не всегда знали, как именно будет развиваться система.
A little bit of code.
Режимы просмотра, графики и отчеты
Режимы просмотра
Вячеслав Литвинов: Мы начали внедрять различные режимы просмотра (или слои/фильтры), когда поняли, что схема машинного зала начинает напоминать радугу. Режимы добавляли во многом исходя из запросов отделов. Например, коллегам было важно смотреть, серверы каких клиентов размещены в стойке, — это режим просмотра «Клиенты». Если важно увидеть, где расположены дедики или услуги компании, выручит слой «Услуги». Слой «Состояние» покажет, какие стойки заняты, свободны или зарезервированы, а «Заполненность» — заполненность стойки оборудованием. По запросу от сетевого департамента компании добавили слой «Сетевое оборудование». Режимы не появились одномоментно: одни добавили раньше, другие — позже.
Применение слоя «Сетевое оборудование».
Сейчас у нас 7 режимов просмотра с собственной цветовой дифференциацией. Одно из свежих нововведений — это слои «Проектная мощность» и «Договорная мощность». Появился запрос на мониторинг электропитания, чтобы можно было посмотреть, на сколько мы еще можем загрузить стойку.
Договорная мощность — это та, что указана в договоре с клиентом-арендатором или в техническом задании для внутреннего проекта компании. Проектная мощность работает с физическими ограничениями стойки — какую нагрузку она может выдержать.
Слой «Проектная мощность».
У каждой серверной стойки в Selectel есть измерительное устройство, с которого мы собираем информацию о потребляемой электроэнергии. Эти данные отправляются в Zabbix/Grafana, где можно построить графики потребляемой мощности. Эти же графики можно посмотреть непосредственно в Racks, как на картинке ниже.
Благодаря этому мы можем сравнивать реально потребляемую мощность и запланированную. Если есть перерасход, можем скорректировать потребление на основе полученных данных. Это одно из свежих дополнений, но им уже очень заинтересовались аналитики Selectel.
/charts – графики
Вячеслав Литвинов: То, что в Racks нужно добавить возможность строить графики, мы поняли достаточно быстро. Графики были необходимы для отчетов по стойкам. Система, которой мы пользовались, показывала только данные на текущий момент. Сделать ретроспективный анализ, построив график на основе данных прошлого месяца, было невозможно.
Тогда кто-то из коллег вскользь упомянул, что было бы здорово смотреть, в каком состоянии была стойка несколько месяцев назад, какие клиенты ее занимали. Ранее эту информацию можно было только из памяти сотрудников доставать. Мы решили добавить в Racks возможность сохранять информацию хотя бы на несколько месяцев — так у приложения появилась собственная база данных.
Элемент нашей базы данных.
Николай Огоров: Возможность вернуться в прошлое мы обеспечиваем за счет регулярных снапшотов состояния системы и сохранения этих «слепков». Мы собираем информацию примерно раз в 8 часов — это довольно большой пласт данных по всем стойкам, оборудованию, коммутаторам и так далее. Не все они подходят под стандарты Racks, поэтому я немного очищаю данные, трансформируя их в «перевариваемый» для Racks формат. На это обычно уходит несколько минут, что немного, учитывая количество активов.
Раньше мы писали функционал по построению графиков в самом приложении, но каждое улучшение требовало переписывания логики. Мы поняли, что изобретаем велосипед и перешли на Grafana, которая через iframe «инкрустирована» в Racks.
Сейчас можно вернуться практически в любое состояние серверной с момента запуска функции создания графиков. Узнать, кто занимал ту или иную стойку в августе 2020 года? Легко! Можно посмотреть хоть всю «историю» серверных в ретроспективе.
В основном графиками пользуются аналитики, как финансовые, так и продуктовые. Они смотрят, как растут активы компании, и планируют закупки новых стоек и оборудования на основе этой информации.
График основан на неактуальных данных 2018-2019 гг.
/reports – отчеты
Вячеслав Литвинов: Самым первым стал отчет по стойкам. Его сотрудники дата-центров делают на постоянной основе.
Как это выглядело раньше? Старшие инженеры дата-центров собирали информацию и отправляли ее человеку, который агрегировал ее в определенном месте: кто, когда, какой проект или клиент занял или освободил стойку. Потом руками собирался месячный отчет, который уже в более-менее презентационном виде отправлялся топ-менеджерам компании.
Мы решили автоматизировать процесс: сгенерировать отчет в Excel-формате можно сразу в DCIM-системе — в нем отобразятся все действия, которые производились со стойками в течение определенного времени.
Сейчас у нас семь отчетов. Все они заточены под ретроспективный анализ:
Мы можем посмотреть «летопись» любой стойки.
Самый новый, седьмой, отчет позволяет смотреть последовательность свободных юнитов в стойках (один телекоммуникационный юнит 1U – это единица измерения высоты устанавливаемого оборудования, равная 4,445 см — прим. ред.). Можно выбрать услугу и локацию (например, выделенные серверы) и посмотреть, сколько в ней места под новые серверы определенной высоты. Отчет сам подскажет, куда мы сможем поставить, допустим, 5 серверов высотой в 3U.
Всегда можно посмотреть, сколько юнитов свободно.
Стройная система учета активов открывает новые возможности, казалось бы, в самых неожиданных местах. Благодаря тому, что у нас есть полная информация по стойкам, юнитам и серверам, ребята, которые занимаются развитием выделенных серверов, смогли предоставить клиентам информацию о расположении их серверов в стойках (для дополнительного повышения отказоустойчивости критических серверов). Так сервис, разработанный для внутреннего использования, нашел применение в качестве фичи для клиентов.
Сapacity management
Вячеслав Литвинов: После того, как мы пришли к capacity management, — Racks и ценность DCIM стали воспринимать в компании по-иному.
В чем важность capacity management, или управления мощностями? Если говорить про дата-центры, он помогает найти баланс между необходимыми инфраструктурными ресурсами и затратами на их покупку и поддержку. Подробнее о capacity management можно прочитать в этом тексте на Хабре.
Примерно в начале 2020 года мы получили запрос от топ-менеджмента Selectel: было бы здорово иметь возможность планировать установку новых стоек с помощью Racks. Например, узнать, сколько еще можно добавить стоек в частично заполненную серверную. Здесь мы добавили такое понятие, как вес стойки. Вес одной стойки равняется единице, половинчатой стойки — 0,5, четвертинки, соответственно, — 0,25. На основе этих значений мы начали вычислять суммарный вес всей серверной (естественно, автоматически, по формуле). Допустим, общий вес комнаты составлял 650, а стоек в ней 250. А значит, как говорит нам простая арифметика, туда можно добавить еще 400 «эталонных» стоек (без поправок на потребляемую мощность и нестандартные габариты).
Для реализации capacity management мы как раз добавили несколько новых отчетов в наше приложение.
Сейчас подобный расчет доступен для любой серверной. В боковом меню Racks можно на шкале посмотреть capacity management по стойко-местам в процентном соотношении: сколько занято, сколько можем занять.
Николай Огоров: Кроме уже озвученных сущностей типа стойкоместа и веса стойки, мы добавили понятие кейджа (от слова cage). Кейдж – это физическая решетка, которой ограничена какая-то часть серверной, полностью арендованная клиентом. На этой территории другие стойки мы поставить не можем, потому что это полностью клиентская зона, даже если там есть потенциальное место под стойки. И вот эти кейджи система тоже учитывает.
Как выглядят кейджи в системе.
Нюансов, требующих внимания, в целом, было довольно много, но в конечном счете это вылилось в полную статистику по серверным, где было написано, сколько установлено стоек, сколько из установленных занято и сколько еще можно установить. И все это в виде отчета, на основе которого можно было принимать решение, нужны ли нам новые площадки под стойки или мы можем более эффективно использовать существующие ресурсы (capacity planning).
Параллельно с этим мы наполняли систему все большей информацией по машинным залам: добавляли конструктивные объекты типа колонн, инфраструктурное оборудование (кондиционеры, силовые щитки, огнетушители), сетевое оборудование и фурнитуру (оптические кроссы, патч-панели), двери и т.д. Всю эту информацию мы вносили постепенно, по мере получения.
Переезд на другой бэкенд
Николай Огоров: С системой, выбранной в качестве бэкенда первоначально, у нас появлялось все больше расхождений. С ней было не очень удобно работать, особенно учитывая, что мы многое хотели переделать под себя. Так как наша изначальная система была энтерпрайз-решением, она обладала свойственной им неповоротливостью — исправления багов можно было ждать месяцами.
В итоге после полутора лет работы с ней мы начали искать другие решения. Выбор пал на NetBox, и вот, в 2020 году мы начали переезд.
Почему выбрали NetBox?
Вячеслав Литвинов: С появлением NetBox мы как раз начали вносить информацию по оборудованию. При «переписи» решили отталкиваться от проектов: например, у нас есть оборудование под облачные сервисы, есть выделенные серверы, colocation и так далее. У кого-то из коллег уже был учет серверов в NetBox, где-то мы настроили интеграцию систем с автоматическим обменом данными или написали отдельный скрипт. В ряде случаев, например, при занесении информации о сетевом оборудовании, не обошлось без физического осмотра стоек и ручного «вбивания» данных.
С появлением данных об оборудовании многие отчеты стали более полными, а Racks все больше становился полноценным инструментом для DCIM. Слой «Заполненность» начал играть ту роль, которая ему предназначалась.
А в capacity management появился уже упомянутый расчет количества свободных юнитов по серверному помещению.
Мы иногда удивляемся этой иронии судьбы: Racks появился как небольшой скрипт, но в итоге «перерос» уже два бэкенда и собрал вокруг себя не один сервис. Мы «связали» его с системой управления сетевым оборудованием и системой учета и управления выделенными серверами в Selectel, Zabbix и планируем интеграцию с 1С. Racks стал своеобразным хабом для целого стека ПО, которое используют инженеры дата-центров Selectel. Теперь им не приходится «ходить» в несколько приложений, так как есть единая точка входа в виде Racks.
Синхронизация с другими системами помогает нам выявлять какие-то неточности, расхождения в информации. Если информация в одной системе противоречит данным в другой, значит, где-то произошла ошибка, что-то было не учтено, забыто. Например, прилетает алерт о рассинхронизации с нашей внутренней системой: значит, кто-то из инженеров поставил оборудование, но забыл заполнить данные по размещению либо указал их неверно.
Фичи под запросы
Racks стал во многом полем для реализации идей. Любой сотрудник компании, который видит, как с пользой расширить его функциональность, может написать нам о своей идее. Ценные предложения обязательно идут в roadmap сервиса. Ниже мы расскажем о некоторых таких фичах.
Инструмент «Длинномер»
Николай Огоров: Эта идея у меня появилась, когда я еще был стажером в ИТО. При выборе длины кроссировок инженерам приходится вручную измерять расстояние между стойками, ходить по машинному залу с колесным курвиметром.
А что если сделать своеобразную диджитал-«линейку», которая будет просчитывать кратчайший путь от стойки до стойки и оптимальную длину кабеля сразу в приложении? В целом, расположение стоек и кабельных лотков у нас не меняется, эта информация статична. Сейчас мы реализовали эту фичу в тестовом режиме, для небольшой серверной. Будем собирать фидбэк от инженеров, вносить необходимые исправления и масштабировать инструмент на все существующие машинные залы.
Вот так можно измерить расстояние от одной стойки до другой.
Выгрузка ID клиентов
Также есть функция, которая позволяет выгрузить ID клиентов, чьи серверы могут затронуть плановые работы в машинном зале. Это помогает нашим инженерам быстро уведомлять клиентов о проведении работ. Им достаточно выбрать нужные стойки — в ответ они получат список «айдишников», которые могут вставить в свой инструмент для рассылок уведомлений в тикетах.
Посты мониторинга
Вячеслав Литвинов: Если вы немного представляете, как все устроено в дата-центре, то вы знаете, что существует комната дежурного с большим количеством экранов. На них обычно аккумулируется вся информация из SCADA-системы о состоянии серверных на текущий момент: нет ли перегрева оборудования, каких-то инфраструктурных сбоев и так далее. То есть тут вся информация с датчиков, счетчиков электроэнергии и так далее.
Мы сделали так, чтобы доступ к ним можно было получить дистанционно. То есть не обязательно для полного контроля ситуации сидеть в комнате дежурного. Более того, мы делаем снапшоты показателей мониторов, опять же, для ретроспективного анализа — возможности вернуться в определенный момент времени и оценить состояние систем. Сейчас «слепки» делаются раз в пять минут и хранятся несколько месяцев.
Такие данные помогают также в анализе проблем. Например, поступила информация, что в серверной в определенный промежуток времени ночью мигнул свет. Дежурный, зашедший на пост, может посмотреть, что происходило с системами в это время. Нет ли отклонений, которые в дальнейшем могут вызвать неприятности? Вся ли мнемоника на схеме отработала как положено? Применений такому инструменту, на самом деле, много. Ведь у нас есть доступ к точным данным по состоянию дата-центра в моменте. А это очень ценная информация.
Информация ценная, поэтому показать мы ее не можем. Но вы можете больше узнать о мониторинге в Selectel из этого видео.
Обнаружение логических ошибок
Николай Огоров: Еще мы добавили набор скриптов, которые помогают находить несоответствие данных в NetBox нужному виду. У нас целый набор скриптов, которые, например, могут проверять стойки на заполненность полей или корректность заполнения json-поля у комнат, стоек и девайсов в Netbox. Такое автоматическое нахождение ошибок позволяет держать информацию в DCIM в порядке.
Планы по развитию Racks
Вячеслав Литвинов: Во-первых, как мы уже рассказывали выше, мы хотим немного переделать фронтенд-часть приложения.
Также мы реализовываем выгрузку comprehensive capacity management report. Это отчет, в котором будут группироваться все данные по нашим стойкам, помимо информации о количестве свободных юнитов, на основе которой уже можно будет принимать решения об установке нового оборудования. Добавим возможность смотреть объем электропитания, которым мы можем «догрузить» стойки. Также планируем сделать синхронизацию по сетевым портам на оборудовании, чтобы можно было смотреть свободные порты, — с привычной нам цветовой дифференциацией. Это примерный план до конца года.
Кроме того, к нам постоянно обращаются коллеги с какими-то идеями, которые мы можем быстро реализовать в какой-то дополнительной функциональности или небольшом скрипте. Такие входящие запросы мы тоже рассматриваем.
***
О Racks можно, пожалуй, говорить бесконечно — в него вложено много работы. Сейчас он полностью заменяет нам готовые энтерпрайз-решения в области DCIM, которые используют крупные компании. Тот же EcoStruxure Platform от Schneider Electric, это известная платформа для задач DCIM, но довольно дорогая. В целом, Racks включает большую часть ее полезных функций, только еще у нас есть милые сердцу фичи, которые сделаны специально для сотрудников Selectel. Тот же «Длинномер», например.
Кажется, то, что получилось у нас, — очень хороший уровень для самописного решения с такой функциональностью. В России подобных кейсов, если честно, мы не встречали, поэтому рады рассказать о своем опыте.
На этом завершим наш обзор. Если вам интересно узнать больше о Racks (может, какая-то функция «зацепила» вас больше всего), с радостью расскажем об этом подробнее в одном из следующих текстов в блоге Selectel. Главное — напишите о своем желании в комментариях!