Как вести учет и контроль оборудования, если у тебя более десятка серверных в трех географически разделенных дата-центрах? Как и многие крупные провайдеры, в России и за рубежом, Selectel начал реализовывать DCIM-систему. Однако история с готовым энтерпрайз-решением нам не подошла: попытка адаптировать внешнюю систему под свои потребности с помощью пары скриптов на Python выросла в полноценную самописную DCIM-платформу.
Собственно, о том, как «вылупилась» и развивается DCIM-система, которую мы назвали Racks, мы сегодня и расскажем. Что сейчас может приложение и почему мы в итоге отказались от стороннего решения? Ченджлог подняли руководитель направления DCIM Вячеслав Литвинов и разработчик систем управления инфраструктурой дата-центров Николай Огоров.
Что такое DCIM
Вячеслав Литвинов: Для начала кратко расскажу о том, что такое DCIM, или Data Center Infrastructure Management. Грубо говоря, это многофункциональный инструмент для планирования установки, учета и мониторинга физической инфраструктуры дата-центра — начиная со стоек и заканчивая ПО и сервисами. О DCIM на Хабре писали еще в 2012 году. И хотя технологии шагнули далеко вперед, общая концепция и цель внедрения 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 и мы не всегда знали, как именно будет развиваться система.
Режимы просмотра, графики и отчеты
Режимы просмотра
Вячеслав Литвинов: Мы начали внедрять различные режимы просмотра (или слои/фильтры), когда поняли, что схема машинного зала начинает напоминать радугу. Режимы добавляли во многом исходя из запросов отделов. Например, коллегам было важно смотреть, серверы каких клиентов размещены в стойке, — это режим просмотра «Клиенты». Если важно увидеть, где расположены дедики или услуги компании, выручит слой «Услуги». Слой «Состояние» покажет, какие стойки заняты, свободны или зарезервированы, а «Заполненность» — заполненность стойки оборудованием. По запросу от сетевого департамента компании добавили слой «Сетевое оборудование». Режимы не появились одномоментно: одни добавили раньше, другие — позже.
Сейчас у нас 7 режимов просмотра с собственной цветовой дифференциацией. Одно из свежих нововведений — это слои «Проектная мощность» и «Договорная мощность». Появился запрос на мониторинг электропитания, чтобы можно было посмотреть, на сколько мы еще можем загрузить стойку.
Договорная мощность — это та, что указана в договоре с клиентом-арендатором или в техническом задании для внутреннего проекта компании. Проектная мощность работает с физическими ограничениями стойки — какую нагрузку она может выдержать.
У каждой серверной стойки в Selectel есть измерительное устройство, с которого мы собираем информацию о потребляемой электроэнергии. Эти данные отправляются в Zabbix/Grafana, где можно построить графики потребляемой мощности. Эти же графики можно посмотреть непосредственно в Racks, как на картинке ниже.
Благодаря этому мы можем сравнивать реально потребляемую мощность и запланированную. Если есть перерасход, можем скорректировать потребление на основе полученных данных. Это одно из свежих дополнений, но им уже очень заинтересовались аналитики Selectel.
/charts – графики
Вячеслав Литвинов: То, что в Racks нужно добавить возможность строить графики, мы поняли достаточно быстро. Графики были необходимы для отчетов по стойкам. Система, которой мы пользовались, показывала только данные на текущий момент. Сделать ретроспективный анализ, построив график на основе данных прошлого месяца, было невозможно.
Тогда кто-то из коллег вскользь упомянул, что было бы здорово смотреть, в каком состоянии была стойка несколько месяцев назад, какие клиенты ее занимали. Ранее эту информацию можно было только из памяти сотрудников доставать. Мы решили добавить в Racks возможность сохранять информацию хотя бы на несколько месяцев — так у приложения появилась собственная база данных.
Николай Огоров: Возможность вернуться в прошлое мы обеспечиваем за счет регулярных снапшотов состояния системы и сохранения этих «слепков». Мы собираем информацию примерно раз в 8 часов — это довольно большой пласт данных по всем стойкам, оборудованию, коммутаторам и так далее. Не все они подходят под стандарты Racks, поэтому я немного очищаю данные, трансформируя их в «перевариваемый» для Racks формат. На это обычно уходит несколько минут, что немного, учитывая количество активов.
Раньше мы писали функционал по построению графиков в самом приложении, но каждое улучшение требовало переписывания логики. Мы поняли, что изобретаем велосипед и перешли на Grafana, которая через iframe «инкрустирована» в Racks.
Сейчас можно вернуться практически в любое состояние серверной с момента запуска функции создания графиков. Узнать, кто занимал ту или иную стойку в августе 2020 года? Легко! Можно посмотреть хоть всю «историю» серверных в ретроспективе.
В основном графиками пользуются аналитики, как финансовые, так и продуктовые. Они смотрят, как растут активы компании, и планируют закупки новых стоек и оборудования на основе этой информации.
/reports – отчеты
Вячеслав Литвинов: Самым первым стал отчет по стойкам. Его сотрудники дата-центров делают на постоянной основе.
Как это выглядело раньше? Старшие инженеры дата-центров собирали информацию и отправляли ее человеку, который агрегировал ее в определенном месте: кто, когда, какой проект или клиент занял или освободил стойку. Потом руками собирался месячный отчет, который уже в более-менее презентационном виде отправлялся топ-менеджерам компании.
Мы решили автоматизировать процесс: сгенерировать отчет в Excel-формате можно сразу в DCIM-системе — в нем отобразятся все действия, которые производились со стойками в течение определенного времени.
Сейчас у нас семь отчетов. Все они заточены под ретроспективный анализ:
- Отчет по изменениям стоек за период времени.
- Отчет по количеству занятых стоек на конец месяца.
- Отчет по весам всех стоек.
- Отчет по количеству занятых юнитов в коммунальных стойках.
- Отчет по заполненности помещений.
- Отчет по распределению стоек по услугам.
- Отчет по количеству свободных юнитов в стойках.
Если сотруднику нужна информация здесь и сейчас, он может заглянуть в NetBox (об этом мы еще расскажем). Если нужно посмотреть данные за какой-то период в прошлом, Racks будет незаменим. Теоретически можно посмотреть полную историю «жизни» стойки: кто въезжал в нее, кто выезжал, сколько в ней стояло оборудования и какого.
Самый новый, седьмой, отчет позволяет смотреть последовательность свободных юнитов в стойках (один телекоммуникационный юнит 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?
- Инструмент широко используется в дата-центрах и хорошо знаком многим сотрудникам.
- Это Open source, причем с довольно активным комьюнити. Если у нас возникали проблемы, решение мы находили довольно быстро.
- Постоянно развивается. Когда мы только перешли на NetBox, он не поддерживал необходимую нам мультитенантность (возможность разграничивать права пользователей), но мы знали, что запрос на нее есть не только у нас, и ждали фичу. Вскоре она появилась. И это касается многих важных для нас функций.
- Имеет понятный интерфейс.
- Не стоит нам ни копейки.
- В любой момент можно «форкнуться» и продолжить разработку внутри компании.
Была, конечно, и ложка дегтя. У NetBox – слишком медленный API для больших объемов данных, которые у нас были. Загрузка информации по серверным со всем оборудованием занимала непростительно большое количество времени. К счастью, нам удалось обойти это ограничение.
Вячеслав Литвинов: С появлением 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. Тот же «Длинномер», например.
Кажется, то, что получилось у нас, — очень хороший уровень для самописного решения с такой функциональностью. В России подобных кейсов, если честно, мы не встречали, поэтому рады рассказать о своем опыте.
