Мы строим дата-центры (ЦОДы) и постоянно их обслуживаем. Недавно у нас появилась новая софтина, которая просто восхищает. Ниже несколько скринов из интерфейса визуализации дата-центра:
Тут видно коммутацию, детализацию по стойкам (например, свободные порты), управление питанием, мониторинг температуры в разных участках машинного зала, визуализацию связанного оборудования и визуальный анализ оборудования при применении плана аварийного восстановления.
Вот так выглядит упрощенный вид (примерно похожие виды были в старом софте визуализации):
Это — схема энергопотребления:
Детальный анализ:
Контроль температуры в зале:
Сетевая инфраструктура:
Зависимость оборудования для планирования рисков и разработки планов аварийного восстановления:
Информация по железу, например, количество свободных портов, как осуществлена коммутация, место:
Наглядные представления рабочих процессов:
И привычная аналитика:
Возможность наглядно увидеть свою инфраструктуру ЦОДа в 3D — это более актуальная и доступная для людей информация обо всех компонентах и процессах. В наших ЦОДах стоят банки, крупные госкомпании и другие клиенты подобного уровня, поэтому любой шаг в сторону «сделать понятнее» очень полезено. Наглядность и простота представления дает возможность удобнее мониторить ЦОД, плюс можно более обдуманно принимать решения при обслуживании, планировании мощностей, расширении, переезде, перестановке и так далее.
Допустим, мы запускаем новый зал на 200 стоек в собственном дата-центре. Планируется закупка определенного парка техники, новых вычислительных мощностей под конкретного заказчика из, скажем так, очень ответственной сферы. Надо рассчитать мощности:
Все это традиционно считается и в обычных программах, но в системе визуализации мы можем «расставить» оборудование, скоммутировать все компоненты и прогнать сотни тестовых сценариев использования (включая аварийное восстановление). Система быстро и просто показывает, что, например, у нас есть такое-то количество свободного места в таких-то местах, есть такая-то возможность для выделения электроэнергии для этого набора оборудования, есть такие-то сетевые мощности, система охлаждения и так далее.
Если вы когда-нибудь работали с печатными платами, то знаете, как сложно рассчитать оптимальную схему расположения компонентов с первого раза. Обычно это пара дней автоматических прогонов и ручной перестановки компонент. При постановке оборудования в дата-центр мы имеем примерно похожую головоломку. Новая система получает входную информацию, думает, а затем предлагает план расстановки оборудования с учетом оптимизации всех параметров. Инженер, который будет заниматься расстановкой этого оборудования, может увидеть в системе, как это будет выглядеть «вживую», переставить компоненты местами, посмотреть эксплуатацию в системе симуляции и утвердить схему.
Когда придет время приступить к работам, сработает календарное событие, и система автоматически оповестит персонал. Она сгенерирует задачи нужным инженерам, где будет расписано, что им нужно сделать, какое оборудование куда поставить (с картинками визуализации и схемами подключения).
Можно заняться оптимизацией имеющегося железа. Допустим, система может посчитать, что неэффективно используется место в шкафах: оборудование раскидано по шкафам, и можно заполнить шкафы так, чтобы осталось еще свободное место для других задач. Также система может осуществлять контроль энергопотребления, и поможет нам сократить затраты на питание.
До внедрения звучали скептические голоса: мол, зачем нужна 3D-визуализация, если на обычных 2D-схемах все и так прекрасно видно. После первых тестов вопросы полностью отпали. 3D нужно для наглядности: это не просто веселые картинки, а реально полезная инфографика. Например, оператор может быстрее локализовать какую-то проблему, что важно. Самое сладкое — к этой визуализации можно привязать внешние системы мониторинга, и делать индикацию: система будет показывать, что, допустим, на данном узле проблема.
Плюс мы можем достаточно быстро посмотреть зависимости. Допустим, у нас вышел из строя ИБП. Нам интересно узнать, на что это повлияло, и на этих 3D-картинках мы можем выбрать интересующее нас устройство, применить к нему фильтр. Фильтр покажет, какое оборудование зависит напрямую, а какое подключено к источнику питания, например, по резервной линии. Можно посмотреть все цепочки взаимодействий: это очень эффективно при разработке так называемых планов аварийного восстановления системы (DRP). Всегда можно посмотреть, от чего зависят те или иные компоненты, причем не обязательно по питанию, а, еще и, например, от сетевой составляющей. Допустим, есть узловой маршрутизатор, можно нажать на него и посмотреть, какие компоненты вообще взаимодействуют посредством этого маршрутизатора. В результате, мы будем понимать, что будет происходить в случае его отказа, какие системы будут недоступны.
Есть аналитические отчеты, можно разрабатывать визуальные представления (дашборды) для конечных пользователей, в которых будет уже собрана агрегированная информация. Кстати, переключиться на 2D очень просто: все схемы имеют плоский вид — для web-интерфейсов, например.
Каждый объект – это не просто модель сервера или роутера, компоненты могут быть модульными: сервер, в принципе, можно «разобрать» до блока питания. Каждый объект имеет свои атрибуты, которые можно мониторить, какие-то паспортные характеристики и так далее. Оператор может в любой момент на картинке открыть шкаф, посмотреть на сервер, выбрать компоненты этого сервера, получить информацию по ним – так что это достаточно удобно.
В систему заведены все компоненты, которые используются в работе ЦОДа, и каждый из них учитывается с точки зрения энергопотребления. Зная реальную ситуацию (система же интегрируется с системами мониторинга, которые снимают данные в режиме реального времени) мы можем добавлять данные с температурных датчиков и строить термокарты, которые показывают распределение температуры в ЦОДе.
С софтом поставляется библиотека типовых видов железа, которое можно встретить в ЦОДе, например, сервера крупных вендоров, ИБП, модули распределения электропитания, серверные шкафы, сетевые карты, блоки питания и так далее. На все подобное железо есть готовые шаблоны с характеристиками (вес, энергопотребление, размеры и т.п.) и ссылки на сайт производителя. Можно создавать свои шаблоны.
Кабели детализируются по типу и по сервису, например, можно выделить только VLAN.
Здание ЦОД также моделируется системой.
Система показывает и их, что очень удобно для отчетности по ресурсам. Программные компоненты на разных серверах могут объединяться в общие логические блоки. Например, можно объединить в один блок оборудование, отвечающее за предоставление услуг финансовому департаменту клиента, отделу логистики, отделу продаж и так далее, плюс назначить каждой группе свой цвет на основной картинке.
На сервере располагается база данных моделей и серверная часть. На мощных клиентских рабочих станциях устанавливается «толстый клиент». К серверу подключены web-клиенты, визуализирующие все в 2D. В случае распределенной инфраструктуры существует возможность установки дополнительных серверов и настройки синхронизации инвентарной базы данных между ними (это полезно, когда железо физически в разных ЦОДах).
Работает как любой полезный инструмент: вроде, до внедрения было не нужно, но после первых тестов стало понятно, что отказаться от системы уже не получится, уж больно она хороша. Приходит почти физическое ощущение порядка и контроля, это очень круто.
P.S. Пост писался вместе с Алексеем Акопяном (его нет на Хабре).
Тут видно коммутацию, детализацию по стойкам (например, свободные порты), управление питанием, мониторинг температуры в разных участках машинного зала, визуализацию связанного оборудования и визуальный анализ оборудования при применении плана аварийного восстановления.
Что можно увидеть?
Вот так выглядит упрощенный вид (примерно похожие виды были в старом софте визуализации):
Это — схема энергопотребления:
Детальный анализ:
Контроль температуры в зале:
Сетевая инфраструктура:
Зависимость оборудования для планирования рисков и разработки планов аварийного восстановления:
Информация по железу, например, количество свободных портов, как осуществлена коммутация, место:
Наглядные представления рабочих процессов:
И привычная аналитика:
Зачем нужна визуализация ЦОД?
Возможность наглядно увидеть свою инфраструктуру ЦОДа в 3D — это более актуальная и доступная для людей информация обо всех компонентах и процессах. В наших ЦОДах стоят банки, крупные госкомпании и другие клиенты подобного уровня, поэтому любой шаг в сторону «сделать понятнее» очень полезено. Наглядность и простота представления дает возможность удобнее мониторить ЦОД, плюс можно более обдуманно принимать решения при обслуживании, планировании мощностей, расширении, переезде, перестановке и так далее.
Как это помогает в обслуживании?
Допустим, мы запускаем новый зал на 200 стоек в собственном дата-центре. Планируется закупка определенного парка техники, новых вычислительных мощностей под конкретного заказчика из, скажем так, очень ответственной сферы. Надо рассчитать мощности:
- По питанию.
- По тому, как расположить эту технику.
- По оптимальным параметрам охлаждения и так далее.
Все это традиционно считается и в обычных программах, но в системе визуализации мы можем «расставить» оборудование, скоммутировать все компоненты и прогнать сотни тестовых сценариев использования (включая аварийное восстановление). Система быстро и просто показывает, что, например, у нас есть такое-то количество свободного места в таких-то местах, есть такая-то возможность для выделения электроэнергии для этого набора оборудования, есть такие-то сетевые мощности, система охлаждения и так далее.
Если вы когда-нибудь работали с печатными платами, то знаете, как сложно рассчитать оптимальную схему расположения компонентов с первого раза. Обычно это пара дней автоматических прогонов и ручной перестановки компонент. При постановке оборудования в дата-центр мы имеем примерно похожую головоломку. Новая система получает входную информацию, думает, а затем предлагает план расстановки оборудования с учетом оптимизации всех параметров. Инженер, который будет заниматься расстановкой этого оборудования, может увидеть в системе, как это будет выглядеть «вживую», переставить компоненты местами, посмотреть эксплуатацию в системе симуляции и утвердить схему.
Когда придет время приступить к работам, сработает календарное событие, и система автоматически оповестит персонал. Она сгенерирует задачи нужным инженерам, где будет расписано, что им нужно сделать, какое оборудование куда поставить (с картинками визуализации и схемами подключения).
Можно заняться оптимизацией имеющегося железа. Допустим, система может посчитать, что неэффективно используется место в шкафах: оборудование раскидано по шкафам, и можно заполнить шкафы так, чтобы осталось еще свободное место для других задач. Также система может осуществлять контроль энергопотребления, и поможет нам сократить затраты на питание.
3D – это забава или это реально полезно?
До внедрения звучали скептические голоса: мол, зачем нужна 3D-визуализация, если на обычных 2D-схемах все и так прекрасно видно. После первых тестов вопросы полностью отпали. 3D нужно для наглядности: это не просто веселые картинки, а реально полезная инфографика. Например, оператор может быстрее локализовать какую-то проблему, что важно. Самое сладкое — к этой визуализации можно привязать внешние системы мониторинга, и делать индикацию: система будет показывать, что, допустим, на данном узле проблема.
Плюс мы можем достаточно быстро посмотреть зависимости. Допустим, у нас вышел из строя ИБП. Нам интересно узнать, на что это повлияло, и на этих 3D-картинках мы можем выбрать интересующее нас устройство, применить к нему фильтр. Фильтр покажет, какое оборудование зависит напрямую, а какое подключено к источнику питания, например, по резервной линии. Можно посмотреть все цепочки взаимодействий: это очень эффективно при разработке так называемых планов аварийного восстановления системы (DRP). Всегда можно посмотреть, от чего зависят те или иные компоненты, причем не обязательно по питанию, а, еще и, например, от сетевой составляющей. Допустим, есть узловой маршрутизатор, можно нажать на него и посмотреть, какие компоненты вообще взаимодействуют посредством этого маршрутизатора. В результате, мы будем понимать, что будет происходить в случае его отказа, какие системы будут недоступны.
Есть аналитические отчеты, можно разрабатывать визуальные представления (дашборды) для конечных пользователей, в которых будет уже собрана агрегированная информация. Кстати, переключиться на 2D очень просто: все схемы имеют плоский вид — для web-интерфейсов, например.
Насколько глубока детализация на картинке?
Каждый объект – это не просто модель сервера или роутера, компоненты могут быть модульными: сервер, в принципе, можно «разобрать» до блока питания. Каждый объект имеет свои атрибуты, которые можно мониторить, какие-то паспортные характеристики и так далее. Оператор может в любой момент на картинке открыть шкаф, посмотреть на сервер, выбрать компоненты этого сервера, получить информацию по ним – так что это достаточно удобно.
В систему заведены все компоненты, которые используются в работе ЦОДа, и каждый из них учитывается с точки зрения энергопотребления. Зная реальную ситуацию (система же интегрируется с системами мониторинга, которые снимают данные в режиме реального времени) мы можем добавлять данные с температурных датчиков и строить термокарты, которые показывают распределение температуры в ЦОДе.
С софтом поставляется библиотека типовых видов железа, которое можно встретить в ЦОДе, например, сервера крупных вендоров, ИБП, модули распределения электропитания, серверные шкафы, сетевые карты, блоки питания и так далее. На все подобное железо есть готовые шаблоны с характеристиками (вес, энергопотребление, размеры и т.п.) и ссылки на сайт производителя. Можно создавать свои шаблоны.
Кабели детализируются по типу и по сервису, например, можно выделить только VLAN.
Здание ЦОД также моделируется системой.
Как насчет виртуальных машин?
Система показывает и их, что очень удобно для отчетности по ресурсам. Программные компоненты на разных серверах могут объединяться в общие логические блоки. Например, можно объединить в один блок оборудование, отвечающее за предоставление услуг финансовому департаменту клиента, отделу логистики, отделу продаж и так далее, плюс назначить каждой группе свой цвет на основной картинке.
Для чего еще нужна такая система?
- Для упрощения инвентаризации оборудования.
- Создания «симуляторов ЦОД», когда можно «рассматривать» оборудование, не заходя физически в машинный зал и строить целые «планируемые» залы по такому принципу.
- Интеллектуального ввода в эксплуатацию.
- Визуализации схем питания и сетевой коммутации.
- Для планирования мощностей.
- Для оптимизации расстановки оборудования.
- Для автоматической генерации нарядов на работу инженерам.
- Удобного контроля основных SNMP-метрик на оборудовании инфраструктуры ЦОД.
- Управлении энергопотреблением.
- В аварийных ситуациях (пока только на учебных, реальных ЧП не было).
- Управления переездами департаментов.
- Простого управления множественными ресурсами и активностями.
Какая архитектура?
На сервере располагается база данных моделей и серверная часть. На мощных клиентских рабочих станциях устанавливается «толстый клиент». К серверу подключены web-клиенты, визуализирующие все в 2D. В случае распределенной инфраструктуры существует возможность установки дополнительных серверов и настройки синхронизации инвентарной базы данных между ними (это полезно, когда железо физически в разных ЦОДах).
Итого: взлетит?
Работает как любой полезный инструмент: вроде, до внедрения было не нужно, но после первых тестов стало понятно, что отказаться от системы уже не получится, уж больно она хороша. Приходит почти физическое ощущение порядка и контроля, это очень круто.
P.S. Пост писался вместе с Алексеем Акопяном (его нет на Хабре).