Про HPE Synergy – часть V. Управление.
Начало:
Начал писать эту часть еще в октябре, но потом пошла «жара конца года» по проектам, а потом одолела новогодняя прокрастинация, но уже январь, и надо сделать финальное усилие =).
Эту часть логично будет разделить на три раздела, в каждом из разделов описать модули SY Composer, SY Image Streamer и SY Frame Link Module (FLM).
Начнем с главного устройства – Synergy Composer’а (одна штука для инсталляции обязательна).
Как я уже писал ранее, разработчики в название постарались вложить основной смысл данного устройства, «сomposer», в переводе с английского — композитор (еще есть значения – автор-сочинитель и синтезатор). Так вот, Synergy Composer представляет собой небольшой блейд-сервер, который также монтируется в шасси, и на борту кроме какой-то ОС имеет развернутый функциональный модуль HPE OneView, который управляет всеми ресурсами шасси — вычислительными, передачи данных и их хранением. Кроме этого, цитирую «it is a fully programmable interface which will integrate into popular management tools such as Microsoft SystemsCenter and VMWare vCenter and into open source automation and DevOps tools such as Chef, Docker, and OpenStack».
С точки зрения серверов и шасси Composer:
С точки зрения сетей:
С точки зрения хранения информации:
Отдельно указано поддерживаемое внешнее оборудование:
С точки зрения интеграции со сторонними программными продуктами:
Основной вопрос – для чего весь этот огород нужно было городить? HPE обещает, что это будет работать в виде «Инфраструктуры-как-код», то есть на уровне написания ПО можно задать все интересующие параметры и их вариации для разворачивания этого ПО. Например, прямо кодом написать в ПО: разворачиваем ферму из 10 веб-серверов, процессоров столько-то, памяти столько-то, диска столько-то, прошивка – такая-то, ОС – такая-то такой-то версии с такими-то патчами (возьми ее с Image Streamer’а), драйвера такие-то. После этого, через API Synergy Composer должен все это корректно и быстро отработать. Идея интересная, все зависит от реализации, ведь «Software-defined-что-то» проектов было уже немало, а к успеху пришли весьма не все. Если реализация удастся, это может быть прорыв, если будет как, например, с Helion CloudSystem, то мягко говоря, решение будет «не для всех».
Что еще можно добавить про Composer’ы? Для отказоустойчивости рекомендуется брать второй Composer (даже для одного шасси, но тогда нельзя будет установить Image Streamer); поддерживается Single-sign-on (SSO) для iLO; Composer’ы можно бэкапить (?); поддержку я вижу только уровня 24х7 и выше.
SDK для REST-based Unified API доступны для Java, PowerShell и Python.
Плавно переходим к дополнению первого модуля – второму модулю, он же Synergy Image Streamer’у. Он также представляет собой небольшой блейд-сервер, который тоже монтируется в шасси. Что у него на борту – пока не известно. Внешний вид такой же, как у Composer’а, только информационная наклейка другая.
На Image Streamer’е, как в репозитории, хранится следующее:
В целом, функциональная роль модуля вырисовывается как роль репозитория ОС и ПО плюс функционал iSCSI-boot-from (тут процитрую отдельно – «Unlike traditional boot-from-SAN environments, HPE Image Streamer requires no additional manual setup or configuration (like multipath support, adapter configuration, access control, and SAN array configuration in typical SAN environments)»). Картина получается следующая: в ПО кодим план развертывания какой либо фермы ПО, толкаем на Composer, который определяет наличие самого ПО, ОС и настроек на Image Streamer’е, с него толкаем эти данные на сервера.
В инсталляции может быть несколько модулей, максимальную инсталляцию обещают в 21 шасси. На данный момент соединение между управляющими модулями 10/20 Гбит/с (отдельных от остальных модулей шасси) обещают разогнать до сотни.
Далее рассмотрим Synergy Frame Link Module (FLM). По хорошему имело смысл рассмотреть его во второй части, в рамках шасси, но в этом случае раздел получался логически несбалансированным, поэтому рассмотрим тут.
Задача FLM – на основе набора этих модулей (FLM) создать между различными шасси сеть управления с топологией «кольцо» (10GbE private management network ring) для модулей управления шасси — SY Composer’а и SY Image Streamer’а. Шасси в одной стойке могут быть соединены кабелями CAT6, между стойками требуют CAT7. На рисунке видно, что на передней панели модуля есть два RJ-45 порта: верхний – MGMT (управление), нижний – LINK (связь между модулями). Каждое шасси содержит в себе один модуль, для соединения двух и более требуется, соответственно, второй модуль FLM.
Ну и напоследок расскажу о трех интересных документах, о которых я не знал, когда начинал этот цикл писать/читать, но которые могут помочь при изучении инфраструктуры с HPE Synergy:
Первый документ состоит из 12 страниц и содержит в себе краткое описание всех железок и сравнительные таблицы с ними – полезен как краткая шпаргалка.
Второй документ намного серьезнее – 71 страница, и описывает принципы и примеры инсталляций. Тут можно отметить, что теперь у меня два документа, первый от апреля 2016 года и там 51 страница с теоретическими примерами, и второй – тот, на который дана ссылка, это уже свежак от декабря 2016 года, 71 страница, более детально проработанный, видимо, с использованием набранного опыта.
Третий документ – это уже из серии «добей меня танцем, мой кумир!», читал с интересом, немедленно взял оттуда несколько поясняющих картинок в хорошем качестве для этой статьи.
Вообще общая ссылка на всю доступную документацию по продукту — http://www.hpe.com/info/synergy-docs (кажется, я нашел то, что буду читать ближайшие пару месяцев — HPE OneView 3.0 User Guide на 500 страниц). Не вся документация готова, вместо некоторых документов есть ссылки-заглушки, но уже имеет смысл отметить высокую проработанность раздела, на декабрь 2016 года вышла уже большая часть документации, которой не было в октябре (когда я только начинал писать черновик этой статьи).
P.S. Уважаемая компания НРЕ буквально вчера анонсировала на конец января «HPE Synergy — технические подробности. Демонстрация предпромышленного образца» — неужели?! Возможно, после этого мероприятия хватит информации для написания еще одной статьи, в которой можно будет кратко рассмотреть существующие конфигурации решения и методики планирования.
P.P.S. Перед публикацией коллега прислал ссылку на описание двухдневного курса 01064178 «HPE Synergy Solutions, Rev. 16.21», получилось, что мягко говоря, первый день курса я точно написал.
P.P.P.S. — тут хабровчанин начал писать про опыт реальной эксплуатации
— надеюсь, будет интересно — habrahabr.ru/post/319590
Начало:
Часть I (Вступление) — habrahabr.ru/post/308224
Часть II (Шасси и сервера) — habrahabr.ru/post/310092
Часть III – Дисковое хранилище D3940 и SAS-коммутаторы — habrahabr.ru/post/310564
Часть IV – Наши сети — habrahabr.ru/post/313240
Начал писать эту часть еще в октябре, но потом пошла «жара конца года» по проектам, а потом одолела новогодняя прокрастинация, но уже январь, и надо сделать финальное усилие =).
Эту часть логично будет разделить на три раздела, в каждом из разделов описать модули SY Composer, SY Image Streamer и SY Frame Link Module (FLM).
Начнем с главного устройства – Synergy Composer’а (одна штука для инсталляции обязательна).
Фото промышленного прототипа Synergy Composer’а
Рисунок Synergy с Composer’ом и Streamer'ом
Внешний вид по 3D-модели Composer’а
Ч/б чертеж проекции Composer’а
Как я уже писал ранее, разработчики в название постарались вложить основной смысл данного устройства, «сomposer», в переводе с английского — композитор (еще есть значения – автор-сочинитель и синтезатор). Так вот, Synergy Composer представляет собой небольшой блейд-сервер, который также монтируется в шасси, и на борту кроме какой-то ОС имеет развернутый функциональный модуль HPE OneView, который управляет всеми ресурсами шасси — вычислительными, передачи данных и их хранением. Кроме этого, цитирую «it is a fully programmable interface which will integrate into popular management tools such as Microsoft SystemsCenter and VMWare vCenter and into open source automation and DevOps tools such as Chef, Docker, and OpenStack».
С точки зрения серверов и шасси Composer:
- управляет подключенными шасси (во множественном числе) и серверами в этих шасси, включая автообнаружение устанавливаемого оборудования;
- хранит в себе, для последующей загрузки на сервера, варианты прошивок (firmware) серверов;
- использует некий функционал «logical enclosures», который детально не описан. Рискну предположить, что позволяет создавать на базе железа нескольких фреймов логические вычислительные сущности;
- хранит в себе, для последующей загрузки, варианты драйверов операционных систем;
- также позволяет вести мониторинг и логирование системы в целом и ее компонентов;
- содержит в себе модуль отчетности с неким набором стандартных отчетов, с возможностью их экспорта в CSV или MS Excel;
- содержит в себе элемент HPE Unified REST API для обработки внешних команд управления;
- содержит в себе модуль взаимодействия с SY Image Streamer’ом, т.е. модулем, где хранятся готовы image-файлы дисков операционных систем с предустановленным ПО – для быстрого развертывания ОС на серверах (напомню, что модули управления соединены отдельной от остального шасси 10гбитной сетью).
С точки зрения сетей:
- поддерживает настройку HPE VirtualConnect, свичей и pass-thru модулей;
- управляет соединениями между мастер-модулями и сателлитами;
- управляет агрегацией линков между шасси (Multi-module link aggregation, MLAG);
- управляет обнаружением сетевого оборудования и масштабированием его в существующую инфраструктуру;
- поддерживает обновление логических соединений без остановки передачи траффика.
С точки зрения хранения информации:
- управляет использованием DAS или SAN–хранилищ. Отдельно указано, что некоторые хранилки управляются через Composer, но изначально должны настраиваться независимо от него.
- управляет емкостью и уровнями хранения (tiering) на основе дисковых модулей DAS 3940, для шасси с «натянутым» на них VSA (ограничение по raw-объему – до 614 Тб, причем возможно распределение объема между разными шасси);
- управляет Boot-from-SAN for Fibre Channel (FC);
- управляет политиками зонинга сетей хранения данных;
- ведет мониторинг и логирование систем SAN и систем хранения в целом и на уровне компонентов;
Отдельно указано поддерживаемое внешнее оборудование:
- хранилки — StoreServe 3PAR (FC switched), StoreVirtual VSA and P4000 (iSCSI);
- SAN-сети — Brocade SAN switches, HPE 5900cp/af and 5930 SAN switches, Cisco Nexus 5500/6000 and MDS SAN switches (FC/FCoE).
С точки зрения интеграции со сторонними программными продуктами:
- HPE OneView for VMware vCenter 8.1 supports Synergy systems;
- HPE OneView for Microsoft System Center 8.1 supports Synergy systems;
- HPE Helion CloudSystem 10 supports Synergy systems.
Основной вопрос – для чего весь этот огород нужно было городить? HPE обещает, что это будет работать в виде «Инфраструктуры-как-код», то есть на уровне написания ПО можно задать все интересующие параметры и их вариации для разворачивания этого ПО. Например, прямо кодом написать в ПО: разворачиваем ферму из 10 веб-серверов, процессоров столько-то, памяти столько-то, диска столько-то, прошивка – такая-то, ОС – такая-то такой-то версии с такими-то патчами (возьми ее с Image Streamer’а), драйвера такие-то. После этого, через API Synergy Composer должен все это корректно и быстро отработать. Идея интересная, все зависит от реализации, ведь «Software-defined-что-то» проектов было уже немало, а к успеху пришли весьма не все. Если реализация удастся, это может быть прорыв, если будет как, например, с Helion CloudSystem, то мягко говоря, решение будет «не для всех».
Что еще можно добавить про Composer’ы? Для отказоустойчивости рекомендуется брать второй Composer (даже для одного шасси, но тогда нельзя будет установить Image Streamer); поддерживается Single-sign-on (SSO) для iLO; Composer’ы можно бэкапить (?); поддержку я вижу только уровня 24х7 и выше.
SDK для REST-based Unified API доступны для Java, PowerShell и Python.
Плавно переходим к дополнению первого модуля – второму модулю, он же Synergy Image Streamer’у. Он также представляет собой небольшой блейд-сервер, который тоже монтируется в шасси. Что у него на борту – пока не известно. Внешний вид такой же, как у Composer’а, только информационная наклейка другая.
Внешний вид по 3D-модели Image Streamer’а
На Image Streamer’е, как в репозитории, хранится следующее:
- Profile — профили серверов, которые включают в себя разные версии настроек BIOS и разные версии прошивок;
- Golden Image — «Золотые снимки» ОС – базовые загрузочные версии ОС с I/O драйверы. Есть отдельно приписка – «If your golden image captures your application stack, then your application stack can also be deployed and/or updated with HPE Image Streamer.»
- Personality – персонализированные снимки ОС с приложениями и конфигурациями (hostname, IP config, etc).
В целом, функциональная роль модуля вырисовывается как роль репозитория ОС и ПО плюс функционал iSCSI-boot-from (тут процитрую отдельно – «Unlike traditional boot-from-SAN environments, HPE Image Streamer requires no additional manual setup or configuration (like multipath support, adapter configuration, access control, and SAN array configuration in typical SAN environments)»). Картина получается следующая: в ПО кодим план развертывания какой либо фермы ПО, толкаем на Composer, который определяет наличие самого ПО, ОС и настроек на Image Streamer’е, с него толкаем эти данные на сервера.
Схема взаимодействия Composer'a, Image Streamer'a и серверов в шасси
В инсталляции может быть несколько модулей, максимальную инсталляцию обещают в 21 шасси. На данный момент соединение между управляющими модулями 10/20 Гбит/с (отдельных от остальных модулей шасси) обещают разогнать до сотни.
Далее рассмотрим Synergy Frame Link Module (FLM). По хорошему имело смысл рассмотреть его во второй части, в рамках шасси, но в этом случае раздел получался логически несбалансированным, поэтому рассмотрим тут.
Ч/б чертеж проекции FLM
Внешний вид по 3D-модели FLM
Задача FLM – на основе набора этих модулей (FLM) создать между различными шасси сеть управления с топологией «кольцо» (10GbE private management network ring) для модулей управления шасси — SY Composer’а и SY Image Streamer’а. Шасси в одной стойке могут быть соединены кабелями CAT6, между стойками требуют CAT7. На рисунке видно, что на передней панели модуля есть два RJ-45 порта: верхний – MGMT (управление), нижний – LINK (связь между модулями). Каждое шасси содержит в себе один модуль, для соединения двух и более требуется, соответственно, второй модуль FLM.
Ну и напоследок расскажу о трех интересных документах, о которых я не знал, когда начинал этот цикл писать/читать, но которые могут помочь при изучении инфраструктуры с HPE Synergy:
- Five steps to building a composable Infrastructure with HPE Synergy
- Configuration and Compatibility Guide
- HPE Synergy For Dummies
Первый документ состоит из 12 страниц и содержит в себе краткое описание всех железок и сравнительные таблицы с ними – полезен как краткая шпаргалка.
Второй документ намного серьезнее – 71 страница, и описывает принципы и примеры инсталляций. Тут можно отметить, что теперь у меня два документа, первый от апреля 2016 года и там 51 страница с теоретическими примерами, и второй – тот, на который дана ссылка, это уже свежак от декабря 2016 года, 71 страница, более детально проработанный, видимо, с использованием набранного опыта.
Третий документ – это уже из серии «добей меня танцем, мой кумир!», читал с интересом, немедленно взял оттуда несколько поясняющих картинок в хорошем качестве для этой статьи.
Вообще общая ссылка на всю доступную документацию по продукту — http://www.hpe.com/info/synergy-docs (кажется, я нашел то, что буду читать ближайшие пару месяцев — HPE OneView 3.0 User Guide на 500 страниц). Не вся документация готова, вместо некоторых документов есть ссылки-заглушки, но уже имеет смысл отметить высокую проработанность раздела, на декабрь 2016 года вышла уже большая часть документации, которой не было в октябре (когда я только начинал писать черновик этой статьи).
P.S. Уважаемая компания НРЕ буквально вчера анонсировала на конец января «HPE Synergy — технические подробности. Демонстрация предпромышленного образца» — неужели?! Возможно, после этого мероприятия хватит информации для написания еще одной статьи, в которой можно будет кратко рассмотреть существующие конфигурации решения и методики планирования.
P.P.S. Перед публикацией коллега прислал ссылку на описание двухдневного курса 01064178 «HPE Synergy Solutions, Rev. 16.21», получилось, что мягко говоря, первый день курса я точно написал.
P.P.P.S. — тут хабровчанин начал писать про опыт реальной эксплуатации
— надеюсь, будет интересно — habrahabr.ru/post/319590
Поделиться с друзьями
Комментарии (17)
Tortortor
13.01.2017 11:47эволюция С7000?
Tigger
13.01.2017 15:29Не совсем, также как блейды не были эволюцией стоечных серверов. Это новое решение с нуля. А C7000 будет выпускаться и обновляться еще несколько лет.
SemperFi
13.01.2017 18:27я бы не сказал, что решение с нуля, наработки блейд-серверов видно невооруженным глазом, тем не менее — видно наработки и по СХД, и по SAN. кмк это попытка переосмыслить вычисления. а блейды заявлено что еще не менее 5 лет будут продаваться (наверное на случай, если синерджи «не взлетит » +)))
KorP
Я вот только так и не уловил до конца — HPE позиционирует данное решение как что? Замену блейдовым корзинам?
Tigger
Нет, как совершенно новый класс ИТ-систем для новой реальности, в которой:
— нужно подружить физическую, виртуальную и контейнерную среды и всем этим бесшовно управлять
— экономика программно-определяемых решений становится выгодной
— DevOps становится мейнстримом
— в будущем: появятся новые типы интерконнектов (фотоника), памяти (типа Intel 3D XPoint) и вычислителей (предусмотрена работа с новыми процессорами на много лет вперед)
Скажете маркетинг — может быть, но завтра это все станет рутиной :)
KorP
Ну в общем надо хорошую презентацию и демонстрацию :)
SemperFi
24го уже таки обещают
KorP
Я видимо что то упустил. О чём речь? Ничего не слышал про 24-е…
SemperFi
блейд-клуб приглашают собраться
KorP
Видать это для ограниченного круга лиц, я про такое не слышал :(
И Tigger что то не приглашает :(
SemperFi
а вы, простите, заказчик или партнер?
KorP
У меня личные взаимоотношения с компанией HPE, но ни под одно из этих определений они не подпадают :)
SemperFi
видимо «truth is out there»
KorP
Если зайти ко мне в профиль — там есть интересный момент на эту тему :D
ustas33
Зачем в DevOps реальности костыли типа OneView, FlexFabric, Synergy?
В DevOps реальности можно всем управлять без лишних костылей через Chef, Puppet и Ansible.
В DevOps реальность предпочитает недорогие серверы без Vendor Lock-in, и ToR коммутаторы Arista или Juniper, которые дружат с DevOps tools )
SemperFi
вы как то странно рассуждаете…
вот у вас в примере no-name сервера, но во всех стоит процессор от Intel — это vendor-lock или нет? Arista или Juniper — это вендоры?
далее — в документации SY заявлена интеграция с DevOps tools от MS, например, кроме того — отдельно указано, что OneView разрабатывается по методологии DevOps и SY, видимо, это достаточно удобно.
лично мне (возможно, я ошибаюсь) решение SY видится дальнейшим развитием практик DevOps, когда инфраструктуру можно будет закладывать в код ПО, а для этого, очевидно, должна быть единая среда (на уровне подсистем — вычислительной (Intel), хранения, и передачи (FlexFabric) ) плюс оркестратор и интепретатор внешних команд — OneView.
Независимо от реализации (которая может и подкачать) — идея очень крутая.
SemperFi
насколько я понимаю, это реализация концепции The Machine ( https://www.labs.hpe.com/the-machine#! ), т.е. попытка создания «вычислителя» без жесткого деления на подсистемы прямо на фронте.