Шасси Synergy 12000
Шасси Synergy 12000 с первого взгляда похоже на шасси HPE c7000, но это только с первого взгляда. Фактически это совсем другая корзина разработанная с нуля, общим с HPE c7000 является только высота 10U и то что серверы вставляются спереди а интерконнекты сзади (впрочем как и у остальных blade решений). Шасси имеет 12 слотов для установки серверов + 2 слота для установки Composer-a (отвечает за управление шасси) и Image стримера (содержит образы ОС). Решение снизить плотность серверов обусловлено прогнозом на увеличение теплового пакета будущих поколений CPU. Новое шасси получило backplane с разведенными световодами и будет поддерживать передачу данных посредствам фотонов. Пока трудно представить где именно это может понадобиться, в фотонном коммутаторе с минимальными задержками или в вычислительных модулях использующих свет вместо электричества, сам факт наличия световодов говорит о долгосрочных планах компании HPE использовать новое шасси. К слову сказать, шасси c7000 уже 11 лет не претерпевало существенных изменений и сохраняет совместимость со всей линейкой выпускавшихся серверов.
Салазки для установки шасси в стойку внушают доверие и не играют под весом корзины.
Вес корзины в полной набивке составляет почти 250 кг.
Съемная перегородка для установки двойных по высоте серверов оснащена двумя пружинными фиксаторами и стала удобнее по сравнению с аналогичной в с7000.
Модули шасси
Шасси Synergy 12000 имеет слоты для установки следующих модулей:
- 12 серверов
- 1 Composer
- 1 Image Streamer
- 1 Модуль консольного подключения
- 2 FLM модуля
- 10 вентиляторов
- 6 блоков питания
- 6 интерконнектов
Рассмотрим каждый из модулей:
Composer
Управление шасси осуществляется через интерфейс OneView в WEB браузере. Composer представляет из себя мини сервер х86 архитектуры с модифицированным ядром Linux. На нем и крутится OneView, если Composer вытащить, то на работоспособность компонентов это не повлияет, однако управление будет недоступно. Корзины можно объединять между собой в группы, при этом все корзины в группе будут управляться через единый интерфейс OneView.
В такой конфигурации используется два (Active/Standby) композера установленных в разных корзинах для отказоустойчивости. В одну группу можно объединить до 20 шасси.
Image Streamer
Image Streamer так же представляет из себя мини сервер, на нем хранятся образы операционных систем и он отвечает за заливку ОС на серверы.
Модуль консольного подключения
Расположен справа на передней панели, необходим для первоначальной настройки шасси, а так же для сброса к заводским настройкам. Обеспечивает подключение к активному FLM модулю.
FLM модуль
Frame Link Module (FLM) — в его задачи входят следующие функции:
- управление вентиляторами
- управление блоками питания
- передача команд поступающих от композера до конечного элемента
- объединение нескольких корзин в одну группу
В каждом шасси по два FLM модуля для обеспечения отказоустойчивости. При объединении нескольких корзин FLM модули соединяются образуя изолированную сеть управления с топологией кольцо.
Блоки питания
По сравнению с БП с7000, ПБ Synergy стали меньше по размеру а их мощность возросла. 6 блоков питания обеспечивают резервирование N+N для всех компонентов корзины.
Коммутационные модули
Нововведением среди модулей коммутации является использование satellite коммутаторов, которые подключаются к master свичу расположенному в другой корзине, т.о. достигается экономия кол-ва необходимых аплинков и бюджета, поскольку satellite свичи будут стоить дешевле. Satellite switch можно подключить только к master свичу, к одному Master Switch могут быть подключено до 4 сателлитов. На фото ниже master switch (над верхним рядом блоков питания).
Конструкция защелки впечатлила своей монументальностью и плавным ходом.
Сервер Synergy 480 Gen9
Данный сервер содержит процессоры Xeon E5 четвертого поколения как и bl460 Gen9, но отличается от него по конструкции: RAID контроллер теперь находится под дисками, резервный источник питания имеет бОльшую емкость, а число слотов памяти возросло до 24.
Конструктив корзины с дисками обеспечивает возможность прямого подключения дисков без участия RAID контроллера, данная опция будет необходима при использовании серверов в качестве компонентов программно определяемых систем хранения (SDS).
Разъемы подключения mezzanine адаптеров, как и разъемы на backplane шасси стали менее прихотливы а риск погнуть контакты теперь сведен к минимуму.
Конструкция новой ручки-защелки просто подарок для персонала сопровождения, поскольку ее можно использовать для переноски серверов.
Система управления OneView
Управление всеми компонентами корзины осуществляется через OneView, в Synergy нет отдельных интерфейсов управления VirtualConnect и SAS коммутаторами, здесь нельзя зайти даже в WEB интерфейс iLo хотя сам iLo конечно есть. Интерфейс OneView прост и понятен, нужно только привыкнуть к тому, что физические и логические составляющие оборудования теперь отделены друг от друга. Все идентификаторы серверов (серийный номер, MAC адрес, WWN и т.д.) могут быть привязаны к конкретному слоту корзины, так же как и набор версий микрокода компонентов сервера, драйверов ОС и самого образа ОС. К примеру, если стоит задача перенести сервер БД на новое железо, то для этого необходимо:
- Выключить старый сервер.
- Вставить новый сервер.
- Дождаться завершения процесса автоматической настройки сервера и заливки ОС.
- Настроить приложение на сервере, если данные настройки не были изначально включены в образ ОС.
- Все!
Профили оборудования можно переносить между физическими серверами тем самым оптимизируя использование ресурсов. Фактически теперь настраивается не само оборудование, будь это сервер корзина или коммутатор, все настройки хранятся в профиле оборудования который может быть применен к какому-либо компоненту системы нажатием одной кнопки. Профилей может быть много, но активный профиль для единицы оборудования может быть только один, если на оборудовании профиль не назначен, то оно будет простаивать. В профиле сервера храниться исчерпывающая информация по настройкам включая конфигурацию RAID и настройки UEFI/BIOS. Большие возможности открываются для DevOps, система управления имеет поддержку RestAPI и все что можно сделать через WEB интерфейс, можно сделать и через RestAPI. Еще одним преимуществом будет возможность через OneView управлять презентацией дисковых ресурсов на массивах HPE 3Par.
Меню OneView имеет вид.
Управление VirtualConnect.
Меню управления сервером.
OneView так же включает функционал моделирования ЦОД с возможностью получать данные о температуре и энергопотреблении в стойке через термодатчики в серверах и iPDU.
Что понравилось
- Единая точка управления OneView.
- Поддержка Rest API.
- Использование профилей оборудования.
- Наличие оптических линков на backplane шасси.
Что не понравилось
- Неудачно реализована фиксация кабелей питания, стяжки со временем могут потрескаться.
- Сверху шасси присутствуют отверстия в которые могут попасть посторонние предметы.
- Не быстро применяются изменения профилей на Virtual Connect.
Выводы
HPE Synergy оказался очень интересным продуктом, тот редкий случай когда маркетинг был на втором месте после технической части. Новая корзина Synergy не позиционируется как прямая замена с7000, у них несколько разные задачи. Полагаю что с7000 будет существовать параллельно с Synergy до того момента пока backplane не станет узким местом. На данный момент аналогичных решений у конкурентов еще нет, но с большой долей вероятности спрос на подобное оборудование будет расти тем самым рождая новые предложения.
Комментарии (32)
acmnu
16.01.2017 12:33Наличие оптики внутри интересно, но внушает опасение. Что будет с механической прочностью и пылью на этих коннектах? Или там есть какая-то хитрая механика прикрывающая порт в отстутсвии сервера.
ESergey
16.01.2017 22:25Как выглядят оптические коннекторы у меня информации нет, но есть два предположения. На фото внутренности корзины куда вставляется сервер, стрелками обозначены возможные места расположения световодов, зеленой стрелкой обозначен штырь входящий в основной разъем сервера, красными стрелками обозначены шторки за которыми могут скрываться разъемы световодов.
Pave1
16.01.2017 13:34С большим опозданием начинают идеи у циски брать. Которые раньше были «плохими».
А теперь вот и коммутаторы-сателлиты появились… И многое другое ))ESergey
16.01.2017 13:41В использовании коммутаторов сателлитов нет ничего плохого вне зависимости от вендора, blade решение от Cisco имеет свои нюансы, основная часть которых заключается в отсутствии поддержки транспорта FC без инкапсуляции.
ustas33
16.01.2017 23:05Проще 48-96 портовый Top of rack Arista 71xx/72xx или Huawei CE68xx поставить, и напрямую серверы вокнуть. Дешевле блейд-коммутаторов получится.
ESergey
17.01.2017 09:58Медь в стойке это вчерашний день, хотя конечно дешевле спора нет.
ustas33
17.01.2017 11:51Оптические естественно c SFP+/QSFP+. 48х портовый 10Gb дата центровый ToR с поддержкой FCF/FCoE, VxLAN, SDN ready стоит от $12K c НДС.
48x 10Gb портовый коммутатор потупее без VXLAN, FCOE от $8K.
100м SFP+ трансивер $120-150 в лист прайсе. DAC'и естественно в 2-3 раза дешевле.ESergey
17.01.2017 20:07При использовании коммутаторов Top of Rack (ToR) внутри стойки все равно будет медь и при большой плотности оборудования её будет много. Если считать blade серверы с коэффициентом плотности 1.6 сервера на юнит (HPE, DELL) и если требуется по два линка на сервер, то в 42U стойке нужно будет проложить 128 патчкордов. Надежность такого решения будет небольшая, все же электроника это наука о плохих контактах, не говоря о том, что нужно еще поискать человека который сможет правильно уложить всю эту медь в стойке и сохранять порядок при переключениях линков на протяжении всего срока эксплуатации ДЦ. В случае использования классических blade коммутаторов потребуется всего 16 оптических патчкордов, а при подключении четырех корзин Synergy будет достаточно всего двух QSFP кабелей.
ustas33
17.01.2017 20:56В скольки датацентрах Вы видели питание более 15 кВт на стойку?
15кВт это 2х блейд-шасси на стойку (20-24U) или если очень оптимистично 3х блейд-шасси (36U).
Обычно в датацентрах с воздушным охлаждением 6-12 кВт. С такой нагрузкой ещё можно использовать free cooling. Т.е. это в прыжке 2х блейд-шасси и пол шкафа не проданного воздуха. Т.е. преимущество в плотности — это маркетинг.
Жизнь показала, проще поставить стандартные 2U серверы с дисками, с KVM, oVirt/OpenStack, Ceph (SDS) и не любить голову.
На 6кВт стойку это до 12х серверов, 4х 10Gb порта на сервер, и 48x портовый 10Gb ToR. 48 линков на стойку, не так и много.
При нагрузке 6-12кВт на стойку, отказ половины кондеев в контейнере/гермозоне не приводит к meltdown)ESergey
19.01.2017 01:10В скольки датацентрах Вы видели питание более 15 кВт на стойку?
Лично был в 7 или 8 ДЦ с питанием более 15 кВт на стойку. Если считать стоимость юнита в ДЦ Tier 3, то она получается близка к стоимости 1U сервера средних характеристик А бренда, поэтому плотность вычислительных ресурсов на юнит может играть большую роль. Если брать наиболее плотные решения (HP и DELL) с 32 CPU (тепловой пакет каждого CPU 135W) на 10U, реальная потребляемая мощность будет около 4кВт при использовании серверов для VM. Итого на стойку получится 16кВт, в реальности эта цифра будет близка к 12кВт на 4 корзины, если конечно биткоины не считать))
SemperFi
16.01.2017 18:09ого =) я только в теории изучал и серию написал, а тут уже и практика есть.
вам в россии удалось протестировать, или зарубежом? в заказчике, партнере, вендоре?ESergey
16.01.2017 21:33Тестирование проходило в России, была информация что на момент начала тесов это был единственный экземпляр на всю Европу) Пользуясь случаем хочу поблагодарить вас за интересные статьи на данную тему, ссылки были очень кстати.
SemperFi
16.01.2017 21:52пользуясь случаем хочу сказать пожалуйста =)))
значит вы из того самого «ключевого заказчика», про которого говорили. оч.-оч. круто, пишите больше про процесс, особенно про devops интересно =)
Karpion
16.01.2017 18:12«Composer представляет из себя мини сервер х86 архитектуры с модифицированным ядром Linux.»
Хм-м-м, а почему не ARM? Что там за задачи такие, что ARM не справляется?
«Данный сервер содержит процессоры Xeon E5 четвертого поколения»
Мне не нравится то, что нет свободы выбора процессоров. Очень хотелось бы иметь возможность использовать процессоры ARM, другие RISC-процессоры, более слабые (и соответственно, слабые дешёвые) процессоры Intel и процессоры AMD — на выбор.
Например, ряд атак (прежде всего — с забросом на сервер своего программного кода с попыткой заставить сервер выполнить этот код) предполагают, что на сервере работает конкретный тип процессора. А если там процессор с другим набором команд — то атака заведомо зафейлится.ESergey
16.01.2017 21:52Хм-м-м, а почему не ARM? Что там за задачи такие, что ARM не справляется?
Если управлять одним шасси, то думаю что хватит и ARM, но если 20 шт. то видимо уже нет.
Мне не нравится то, что нет свободы выбора процессоров. Очень хотелось бы иметь возможность использовать процессоры ARM, другие RISC-процессоры, более слабые (и соответственно, слабые дешёвые) процессоры Intel и процессоры AMD — на выбор.
Никто не мешает использовать RISC-процессоры, для этого есть HPE Moonshot (Кстати тоже занимался его тестированием), там совсем другая плотность, архитектура и круг решаемых задач.
Например, ряд атак (прежде всего — с забросом на сервер своего программного кода с попыткой заставить сервер выполнить этот код) предполагают, что на сервере работает конкретный тип процессора. А если там процессор с другим набором команд — то атака заведомо зафейлится.
Вредоносный код использующий уязвимости ядра ОС, пишется под определенные версии ядра, а версия ядра напрямую зависит от архитектуры CPU. Чем меньше распространена версия ядра, тем меньше у нее обнаруженных уязвимостей.Karpion
18.01.2017 19:20-1А сколько процессорной мощности требует управление одним шасси?
Вредоносный код может никак не использовать ядро, а обращаться к библиотекам, как это делают все нормальные программы. Кроме того, одна конкретная версия программы может работать на широком диапазоне ядер — например, на W'95/98 и на W'NT/2000/XP (ядра там сильно разные). Во FreeBSD бинарная совместимость обычно сохраняется вплоть до смены старшей цифры в номере версии — т.е. от 5.0 до 5.4 совместимость полная.
Если брать за пример FreeBSD, то он работает на разных архитектурах (см.ихний сайт). При этом версия ядра и всей операционки — одна и та же.
ustas33
16.01.2017 21:55Какой теперь у HP лозунг? Конвергентная адаптивность или адаптация конвергентности?
Мир разворачивается в сторону микросервисов. Зачем теперь вот это всё?
Под oVirt, Openstack, Docker, Ceph дешевле поставить DL160, и выкинуть (вернуть лизингодателю) через 3 года.
Или ещё проще использовать что то типа HPE Apollo 2000.ESergey
16.01.2017 22:03Для каждой задачи нужно использовать подходящее оборудование, Synergy это Enterprise решение. Контейнеры можно разворачивать и на десктопах, используя при этом SDS, но какой будет уровень надежости и масштабируемости системы? Да и не каждую задачу можно решить контейнерным способом, тяжелую БД в контейнер или на слабое железо не запихнешь.
ustas33
16.01.2017 22:09Для тяжелой БД есть, например, Huawei RH8100 V3 с hot-swap PCI, hot-swap memory а-ля древних Sun Fire.
Я понимаю, что сейчас БД кластеризуются и зеркалируются,
но в блейдах нет hot-swap memory или hot-swap mezzanine, и PCIe NVMe в них не напихаешь.ESergey
19.01.2017 01:28Не знаю почему, но не люблю Huawei, наверное потому что продавцы у них очень сильно хотят тебе что-то продать, у меня этот метод работы ассоциируется с продажами пылесосов по квартирам))) При этом среди железа у них есть достойные модели, RH8100 в том числе.
DRoi
17.01.2017 10:16+1Основная идея, которая продвигается данным решением — это инфраструктура как софт, так называемая «Composable Infrastructure», т.е. фактические нет привязки к аппаратному обеспечению — есть вычислительные блоки и блоки хранения + софт управления всем этим.
Выделение и ввредение в работу ресурсов (без разницы аппаратных или виртуальных) происходит фактически без вмешательства администрируещего персонала — достаточно применить профиль на бей/сервер и система сама присвоит MAC/WWN, зальет и развернет образ ОС.
Также, не стоит забывать о разных подходах в Enterprise и Cloud сегментах. Контейнеризация, как и виртуализация решает многое, но далеко не все.ustas33
17.01.2017 12:21Это сказка для того чтобы продать vendor lock-in.
HP Oneview конечно прекрасен, но работает только с оборудованием HP. Его ждет та же судьба, что и HP Matrix.
Зачем виртуальные MAC/WWN? Сейчас нет уникальных серверов, все на виртуалках.
Вся HA/DR логика находится на гипервизорах, логика управления сетью на Open vSwitch, OVS, vSwitch, NSX. LUN СХД презентуется сразу порт группе.
OS deployment умеют все, любой сервер поддерживает ipmi, PXE. Windows WDS, Linux умеет деплоиться на bare metal.
Puppet, Ansible прекрасно умеет работать с коммутаторами Arista, Juniper и нарезать VLAN'ы, QoS во время деплоя серверов.
Проще использовать OpenSource набор утилит для monitoring, deploy, provisioning чем вендорские костыли.
Пора учиться продавать DevOps, как Arista, а не Ынтерпайз и Прэмиум )DRoi
17.01.2017 12:39+1HPE OneView поддерживает не тольколь HPE, как минимум еще Cisco и Brocade, но сервера и СХД только HPE.
По моим данным потребности в физической инфрастуктуре все еще высоки, т.к. некоторые производители корпроративного ПО до сих пор не сертифицировали ни один из известных гипервизоров.
Виртуализация ввода/вывода на уровне WWN и MAC опять таки необходимы при замене физических серверов.
И да, данное решение не позиционируется как альтернатива Cloud решений от opensource сообщества — это параллельно существующее направление.
Если рынок хочет получить решение уровня Synergy, 3PAR и т.д. значит оно ему надо. :)
ESergey
17.01.2017 20:45HP OneView конечно прекрасен, но работает только с оборудованием HP. Его ждет та же судьба, что и HP Matrix.
OneView это софт управления а HP Matrix это проприетарное облачное решение на itanium.Зачем виртуальные MAC/WWN?
Железо для виртуальных серверов тоже нудно менять, и если их десяток, то это не проблема, но когда инфраструктура большая, Synergy может заметно упростить работу администраторам.LUN СХД презентуется сразу порт группе.
Это вообще как? Зонинг по портам, и all acсess на массиве, и кто подключился к порту тот и получил доступ к LUN? Такой подход возможен только с малым кол-вом SAN портов и имеет значительные ограничения.Проще использовать OpenSource набор утилит для monitoring, deploy, provisioning чем вендорские костыли.
Основная разница между Enterprise и OpenSource решениями в том кто будет виноват когда что-либо сломается, чинить OpenSource придется самому и никто тут не поможет. Вопрос в критичности бизнеса, в одном случае оптимальным будет применение OpenSource в другом Enterprise, как говориться не надо грести лопатой и копать веслом )
Pave1
18.01.2017 10:56Возникает вопрос: какой смысл в 10 юнитовой корзине на 10 серверов? )))) Когда в те же 10 юнитов можно засунуть 10 классических серверов сопоставимой производительности?
Какой смысл в блэйдах, если они не обеспечивают высокую плотность размещения оборудования?
Ну и очень печальна завязка на функционально убогий и логически кривой virtual connect. Который часто вызывает большие проблемы. Т.к. в нем толком не разбираются и не хотят связываться ни администраторы этих самых блейдов, ни сетевые администраторы.ESergey
19.01.2017 00:50какой смысл в 10 юнитовой корзине на 10 серверов?
Ну все же корзина не на 10 серверов а на 12, но конечно коэффициент плотности на текущих CPU разочаровывает.Какой смысл в блэйдах, если они не обеспечивают высокую плотность размещения оборудования?
Смысл есть в консолидации управления, когда серверов много (несколько тысяч) методы прекрасно работающие на нескольких сотнях перестают работать.Ну и очень печальна завязка на функционально убогий и логически кривой virtual connect.
Тут согласен, к классическому Virtual Connect большинство относиться с предубеждением и я в их числе, но знаю людей которые от них в восторге и используют те фишки, которых нет в других blade коммутаторах. С другой стороны интерфейс управления для Virtual Connect в Synergy переработан полностью, и показался мне более интуитивно понятным по сравнению с предыдущим.Pave1
19.01.2017 11:47А какие такие плюсы в управлении дают эти блейды по сравнению с обычными серверами?)
И почему яндексы, гуглы и т.д. используют обычные сервера вместо блейдов?
ИМХО если например говорить про ту же циску — там хотя бы реально продают готовую инфраструктуру на 30 корзин с одной точкой управления и готовым интерконектом.
А тут собери, спроектируй, настрой по отдельности…
Жалкое число возиможных коммутаторо-саттелитов. Почему бы их не сделать больше, а головной интергонект вывести из корзины? )))
Больше напоминает коробку с обычныи компонентами.
Понятно, что ХП конечно более гибкий для специфических задач, умеет родной FC, наверняка IB интерконекты будут и т.д…SemperFi
19.01.2017 12:16Cisco вообще то собирается в своих системах HyperFlex уйти от корзин и использовать юнитовые сервера в hyperconverged решениях
ESergey
19.01.2017 23:05И почему яндексы, гуглы и т.д. используют обычные сервера вместо блейдов?
Google и Яндекс используют архитектуру отказоустойчивости на уровне приложения, если сломается железо или целый ДЦ, пользователи этого могут и не заметить, просто нет смысла использовать дорогое железо.
EminH
А как с обратной совместимостью с оборудованием от старых шасси (c7000)? Сервера я так понял нужны свои, а интерконнекты?
ESergey
Платформа Synergy создавалась с нуля, совместимость компонентов с HPE c7000 не предусмотрена.