HPE Synergy, опыт реальной эксплуатации

    Synergy 12000 Frame — это новое blade шасси компании HPE. Beta версия данного оборудования попала мне на тестирование, в данной статье я хочу поделиться опытом эксплуатации новой корзины от HPE и рассказать как все это работает.

    Шасси 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 и т.д.) могут быть привязаны к конкретному слоту корзины, так же как и набор версий микрокода компонентов сервера, драйверов ОС и самого образа ОС. К примеру, если стоит задача перенести сервер БД на новое железо, то для этого необходимо:

    1. Выключить старый сервер.
    2. Вставить новый сервер.
    3. Дождаться завершения процесса автоматической настройки сервера и заливки ОС.
    4. Настроить приложение на сервере, если данные настройки не были изначально включены в образ ОС.
    5. Все!

    Профили оборудования можно переносить между физическими серверами тем самым оптимизируя использование ресурсов. Фактически теперь настраивается не само оборудование, будь это сервер корзина или коммутатор, все настройки хранятся в профиле оборудования который может быть применен к какому-либо компоненту системы нажатием одной кнопки. Профилей может быть много, но активный профиль для единицы оборудования может быть только один, если на оборудовании профиль не назначен, то оно будет простаивать. В профиле сервера храниться исчерпывающая информация по настройкам включая конфигурацию 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 не станет узким местом. На данный момент аналогичных решений у конкурентов еще нет, но с большой долей вероятности спрос на подобное оборудование будет расти тем самым рождая новые предложения.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 32

      0
      А как с обратной совместимостью с оборудованием от старых шасси (c7000)? Сервера я так понял нужны свои, а интерконнекты?
        0
        Платформа Synergy создавалась с нуля, совместимость компонентов с HPE c7000 не предусмотрена.
        0

        Наличие оптики внутри интересно, но внушает опасение. Что будет с механической прочностью и пылью на этих коннектах? Или там есть какая-то хитрая механика прикрывающая порт в отстутсвии сервера.

          0
          Как выглядят оптические коннекторы у меня информации нет, но есть два предположения. На фото внутренности корзины куда вставляется сервер, стрелками обозначены возможные места расположения световодов, зеленой стрелкой обозначен штырь входящий в основной разъем сервера, красными стрелками обозначены шторки за которыми могут скрываться разъемы световодов.
          0
          С большим опозданием начинают идеи у циски брать. Которые раньше были «плохими».
          А теперь вот и коммутаторы-сателлиты появились… И многое другое ))
            0
            В использовании коммутаторов сателлитов нет ничего плохого вне зависимости от вендора, blade решение от Cisco имеет свои нюансы, основная часть которых заключается в отсутствии поддержки транспорта FC без инкапсуляции.
              0
              Проще 48-96 портовый Top of rack Arista 71xx/72xx или Huawei CE68xx поставить, и напрямую серверы вокнуть. Дешевле блейд-коммутаторов получится.
                0

                Медь в стойке это вчерашний день, хотя конечно дешевле спора нет.

                  0
                  Оптические естественно 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 раза дешевле.
                    0
                    При использовании коммутаторов Top of Rack (ToR) внутри стойки все равно будет медь и при большой плотности оборудования её будет много. Если считать blade серверы с коэффициентом плотности 1.6 сервера на юнит (HPE, DELL) и если требуется по два линка на сервер, то в 42U стойке нужно будет проложить 128 патчкордов. Надежность такого решения будет небольшая, все же электроника это наука о плохих контактах, не говоря о том, что нужно еще поискать человека который сможет правильно уложить всю эту медь в стойке и сохранять порядок при переключениях линков на протяжении всего срока эксплуатации ДЦ. В случае использования классических blade коммутаторов потребуется всего 16 оптических патчкордов, а при подключении четырех корзин Synergy будет достаточно всего двух QSFP кабелей.
                      0
                      В скольки датацентрах Вы видели питание более 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)
                        0
                        В скольки датацентрах Вы видели питание более 15 кВт на стойку?
                        Лично был в 7 или 8 ДЦ с питанием более 15 кВт на стойку. Если считать стоимость юнита в ДЦ Tier 3, то она получается близка к стоимости 1U сервера средних характеристик А бренда, поэтому плотность вычислительных ресурсов на юнит может играть большую роль. Если брать наиболее плотные решения (HP и DELL) с 32 CPU (тепловой пакет каждого CPU 135W) на 10U, реальная потребляемая мощность будет около 4кВт при использовании серверов для VM. Итого на стойку получится 16кВт, в реальности эта цифра будет близка к 12кВт на 4 корзины, если конечно биткоины не считать))
              0
              Осталось озвучить как оно по цене в соотношении с с7000 :)
                0
                ого =) я только в теории изучал и серию написал, а тут уже и практика есть.
                вам в россии удалось протестировать, или зарубежом? в заказчике, партнере, вендоре?
                  0
                  Тестирование проходило в России, была информация что на момент начала тесов это был единственный экземпляр на всю Европу) Пользуясь случаем хочу поблагодарить вас за интересные статьи на данную тему, ссылки были очень кстати.
                    0
                    пользуясь случаем хочу сказать пожалуйста =)))

                    значит вы из того самого «ключевого заказчика», про которого говорили. оч.-оч. круто, пишите больше про процесс, особенно про devops интересно =)
                  0
                  «Composer представляет из себя мини сервер х86 архитектуры с модифицированным ядром Linux.»

                  Хм-м-м, а почему не ARM? Что там за задачи такие, что ARM не справляется?

                  «Данный сервер содержит процессоры Xeon E5 четвертого поколения»

                  Мне не нравится то, что нет свободы выбора процессоров. Очень хотелось бы иметь возможность использовать процессоры ARM, другие RISC-процессоры, более слабые (и соответственно, слабые дешёвые) процессоры Intel и процессоры AMD — на выбор.

                  Например, ряд атак (прежде всего — с забросом на сервер своего программного кода с попыткой заставить сервер выполнить этот код) предполагают, что на сервере работает конкретный тип процессора. А если там процессор с другим набором команд — то атака заведомо зафейлится.
                    0
                    Хм-м-м, а почему не ARM? Что там за задачи такие, что ARM не справляется?
                    Если управлять одним шасси, то думаю что хватит и ARM, но если 20 шт. то видимо уже нет.
                    Мне не нравится то, что нет свободы выбора процессоров. Очень хотелось бы иметь возможность использовать процессоры ARM, другие RISC-процессоры, более слабые (и соответственно, слабые дешёвые) процессоры Intel и процессоры AMD — на выбор.
                    Никто не мешает использовать RISC-процессоры, для этого есть HPE Moonshot (Кстати тоже занимался его тестированием), там совсем другая плотность, архитектура и круг решаемых задач.
                    Например, ряд атак (прежде всего — с забросом на сервер своего программного кода с попыткой заставить сервер выполнить этот код) предполагают, что на сервере работает конкретный тип процессора. А если там процессор с другим набором команд — то атака заведомо зафейлится.
                    Вредоносный код использующий уязвимости ядра ОС, пишется под определенные версии ядра, а версия ядра напрямую зависит от архитектуры CPU. Чем меньше распространена версия ядра, тем меньше у нее обнаруженных уязвимостей.
                      –1
                      А сколько процессорной мощности требует управление одним шасси?

                      Вредоносный код может никак не использовать ядро, а обращаться к библиотекам, как это делают все нормальные программы. Кроме того, одна конкретная версия программы может работать на широком диапазоне ядер — например, на W'95/98 и на W'NT/2000/XP (ядра там сильно разные). Во FreeBSD бинарная совместимость обычно сохраняется вплоть до смены старшей цифры в номере версии — т.е. от 5.0 до 5.4 совместимость полная.

                      Если брать за пример FreeBSD, то он работает на разных архитектурах (см.ихний сайт). При этом версия ядра и всей операционки — одна и та же.
                    0
                    Какой теперь у HP лозунг? Конвергентная адаптивность или адаптация конвергентности?

                    Мир разворачивается в сторону микросервисов. Зачем теперь вот это всё?
                    Под oVirt, Openstack, Docker, Ceph дешевле поставить DL160, и выкинуть (вернуть лизингодателю) через 3 года.
                    Или ещё проще использовать что то типа HPE Apollo 2000.
                      0
                      Для каждой задачи нужно использовать подходящее оборудование, Synergy это Enterprise решение. Контейнеры можно разворачивать и на десктопах, используя при этом SDS, но какой будет уровень надежости и масштабируемости системы? Да и не каждую задачу можно решить контейнерным способом, тяжелую БД в контейнер или на слабое железо не запихнешь.
                        0
                        Для тяжелой БД есть, например, Huawei RH8100 V3 с hot-swap PCI, hot-swap memory а-ля древних Sun Fire.
                        Я понимаю, что сейчас БД кластеризуются и зеркалируются,
                        но в блейдах нет hot-swap memory или hot-swap mezzanine, и PCIe NVMe в них не напихаешь.
                          0
                          Не знаю почему, но не люблю Huawei, наверное потому что продавцы у них очень сильно хотят тебе что-то продать, у меня этот метод работы ассоциируется с продажами пылесосов по квартирам))) При этом среди железа у них есть достойные модели, RH8100 в том числе.
                        +1
                        Основная идея, которая продвигается данным решением — это инфраструктура как софт, так называемая «Composable Infrastructure», т.е. фактические нет привязки к аппаратному обеспечению — есть вычислительные блоки и блоки хранения + софт управления всем этим.
                        Выделение и ввредение в работу ресурсов (без разницы аппаратных или виртуальных) происходит фактически без вмешательства администрируещего персонала — достаточно применить профиль на бей/сервер и система сама присвоит MAC/WWN, зальет и развернет образ ОС.
                        Также, не стоит забывать о разных подходах в Enterprise и Cloud сегментах. Контейнеризация, как и виртуализация решает многое, но далеко не все.
                          0
                          Это сказка для того чтобы продать 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, а не Ынтерпайз и Прэмиум )
                            +1
                            HPE OneView поддерживает не тольколь HPE, как минимум еще Cisco и Brocade, но сервера и СХД только HPE.
                            По моим данным потребности в физической инфрастуктуре все еще высоки, т.к. некоторые производители корпроративного ПО до сих пор не сертифицировали ни один из известных гипервизоров.
                            Виртуализация ввода/вывода на уровне WWN и MAC опять таки необходимы при замене физических серверов.

                            И да, данное решение не позиционируется как альтернатива Cloud решений от opensource сообщества — это параллельно существующее направление.

                            Если рынок хочет получить решение уровня Synergy, 3PAR и т.д. значит оно ему надо. :)

                              0
                              HP 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, как говориться не надо грести лопатой и копать веслом )
                          0
                          Возникает вопрос: какой смысл в 10 юнитовой корзине на 10 серверов? )))) Когда в те же 10 юнитов можно засунуть 10 классических серверов сопоставимой производительности?
                          Какой смысл в блэйдах, если они не обеспечивают высокую плотность размещения оборудования?

                          Ну и очень печальна завязка на функционально убогий и логически кривой virtual connect. Который часто вызывает большие проблемы. Т.к. в нем толком не разбираются и не хотят связываться ни администраторы этих самых блейдов, ни сетевые администраторы.
                            0
                            какой смысл в 10 юнитовой корзине на 10 серверов?
                            Ну все же корзина не на 10 серверов а на 12, но конечно коэффициент плотности на текущих CPU разочаровывает.
                            Какой смысл в блэйдах, если они не обеспечивают высокую плотность размещения оборудования?
                            Смысл есть в консолидации управления, когда серверов много (несколько тысяч) методы прекрасно работающие на нескольких сотнях перестают работать.
                            Ну и очень печальна завязка на функционально убогий и логически кривой virtual connect.
                            Тут согласен, к классическому Virtual Connect большинство относиться с предубеждением и я в их числе, но знаю людей которые от них в восторге и используют те фишки, которых нет в других blade коммутаторах. С другой стороны интерфейс управления для Virtual Connect в Synergy переработан полностью, и показался мне более интуитивно понятным по сравнению с предыдущим.
                              0
                              А какие такие плюсы в управлении дают эти блейды по сравнению с обычными серверами?)
                              И почему яндексы, гуглы и т.д. используют обычные сервера вместо блейдов?

                              ИМХО если например говорить про ту же циску — там хотя бы реально продают готовую инфраструктуру на 30 корзин с одной точкой управления и готовым интерконектом.
                              А тут собери, спроектируй, настрой по отдельности…
                              Жалкое число возиможных коммутаторо-саттелитов. Почему бы их не сделать больше, а головной интергонект вывести из корзины? )))
                              Больше напоминает коробку с обычныи компонентами.

                              Понятно, что ХП конечно более гибкий для специфических задач, умеет родной FC, наверняка IB интерконекты будут и т.д…
                                0
                                Cisco вообще то собирается в своих системах HyperFlex уйти от корзин и использовать юнитовые сервера в hyperconverged решениях
                                  0
                                  И почему яндексы, гуглы и т.д. используют обычные сервера вместо блейдов?
                                  Google и Яндекс используют архитектуру отказоустойчивости на уровне приложения, если сломается железо или целый ДЦ, пользователи этого могут и не заметить, просто нет смысла использовать дорогое железо.

                            Only users with full accounts can post comments. Log in, please.