Изначально я планировал написать одну небольшую статью, но, по мере погружения в тему понял, что скорее всего понадобится серия из 5-6 статей, чтобы раскрыть суть достаточно полно.

О чем пойдет речь? О продукте компании Hewlett-Packard Enterprise (дальше – просто HPE) – Synergy.

В силу своей работы я плотно связан с вычислительными комплексами, то есть с теми железками, которые работают с базовыми свойствами информации – информацию можно передавать, хранить и обрабатывать.

Передача информации – это, собственно, различные сети передачи данных; хранение данных – различные системы хранения: аппаратные СХД, программные СХД, и SAN; ну и обработка – различные серверные системы. HPE Synergy, на первый взгляд, попадает в категорию систем обработки информации, т.е. в категорию «различные типы серверов».

На Хабре я нашел две статьи с упоминанием (хотя бы!) этого продукта:

• 1. habrahabr.ru/company/cbs/blog/273737 — тут анонсировали анонс Synergy;
• 2. habrahabr.ru/company/hpe/blog/273681

Вторая статья более интересная, в ней написано из чего Synergy будет состоять, но решительно не понятно зачем весь комплекс нужен. То есть, лично я видел весь комплекс как замену блейд-шасси HPE с7000, но зачем? Шасси ультра-успешное, продаваться будет еще долго (обещали года до 2020), зачем нужен новый комплекс? С другой стороны, очевидно, что у HPE есть свое видение (vision), которое обосновывает вложение в разработку нового продукта десятки миллионов USD, и которое я пока понять не могу.

В феврале я попал на HPE Summit 2016 во Франции, где железку дали потрогать руками, пару фото положу здесь для затравки:

Вид спереди-справа. Нормально фотографировать было невозможно, потому что фотографировали все.



Вид сзади.



В итоге, для того, чтобы понять зачем может быть нужен новый продукт, я решил сделать эту заметку.

Во-первых, для того, чтобы увидеть назначение Synergy, имеет смысл обратиться к истории появления блейд-систем вообще, для понимания какие процессы вызвали развитие этих систем (да и в принципе, как учит наука история, некий факт можно рассматривать только в его историческом контексте).

Итак, в 1999 году жила-была в штате Техас компания Compaq — лучший друг и конкурент многих ИТ-компаний на рынке США. К 1999 году эта компания уже существовала 17 лет на рынке и продавала ПК, ноутбуки, сервера, сетевое оборудование и ПО (тесно сотрудничала с Microsoft). Интересна она в контексте статьи тем, что в ней долго работал архитектором серверов Кристофер Хипп (надеюсь, что пишу фамилию правильно, на всякий случай оригинал — Christopher Hipp), но как раз в 1999 году, на пике краха дот-комов (крах нанес очень сильный удар по продажам Hi-End решений), он покинул компанию Compaq и основал свою компанию – RLX Technologies. А Compaq, в итоге, купила компания Hewlett-Packard.

Далее, RLX Technologies во главе с Кристофером Хиппом занялась разработкой блейд-серверов. Побуждением к разработке было понимание того, что основная ценность сервера – его вычислительная мощность, тогда как блоки питания, например, или конструктив корпуса, или система управления, вторичны относительно главной функции – обработки математических операций. Логическим развитием этой мысли стала идея, что весь не основной функционал сервера можно вынести в отдельный конструктив – шасси, в которое впоследствии можно устанавливать сервера без блоков питания и прочего. Первые блейд-сервера и шасси были выпущены уже в 2000 году, а в 2002 году был зарегистрирован патент US6411506 «High density web server chassis system and method» – рекомендую пройти по ссылке и ознакомиться, очень интересно. Далее дела пошли по разному, блейд-сервера продавались, но было и несколько неудачных инициатив, и в 2005 году компанию RLX Technologies приобрела (сюрприз!) компания Hewlett-Packard. Кристофер Хипп занялся разработкой квантового компьютера, но умер 14 июля 2009 года от сердечной недостаточности, катаясь на велосипеде в Кремниевой долине.

После нескольких лет экспериментов с различными шасси – e-сlass (очень похоже на патент, указанный выше), p-class(уже не так похоже), в 2007 компания Hewlett-Packard выпустила первую ревизию шасси c-class — c7000, таким образом, в следующем году будет уже 10 лет, как это решение продается на ИТ-рынке – своего рода рекорд. Cтало ясно, что новый тип серверов пришелся весьма по душе крупным заказчикам, так как позволял установить в стандартную стойку больше серверов (больше серверов для бога серверов!), например, в обычную стойку высотой 42U влезает 40 одноюнитовых плюс два коммутатора ToR (Top of the rack), тогда как если набить стойку четырьмя шасси c7000 по 16 серверов, то в стойке можно аккумулировать 64 сервера (в 1,6 раза больше). Кстати, именно поэтому высоту шасси стараются сделать 10 юнитов, чтобы в стойку можно было вставить 4 шасси. Таким образом, за 5 лет, т.е. к 2010 году, блейд-решения заняли 40% всего рынка серверов.

Вот такая эволюция вычислительных систем произошла с 2000 года и, очевидно, привела к дальнейшему появлению Synergy.

Перейдем к «во-вторых». Чтобы понять для чего что-то нужно, надо посмотреть на внутреннюю структуру. Посмотрим из чего состоит Synergy:

1. Базовая единица стоечное шасси Frame 12000 высотой 10 юнитов. Вмещает, правда, уже не 16 серверов, а всего 12 (большинство картинок в сети — рендеры 3D-моделей, на первом фото хорошо видно шасси — оно совсем не такое красочное).

2. Сервера, как сказано выше:

• a. либо до 12 штук двухпроцессорных (Xeon E5-2ххх v4) HPE Synergy 480 Gen9,
• b. либо до 6 штук четырехпроцессорных (Xeon E7-48xx и Xeon E7-88xx) HPE Synergy 620 Gen9;
• c. либо до 6 штук четырепроцессорных (Xeon E5-46xx) HPE Synergy 660 Gen9;
• d. либо до 3 штук монструозных четырехпроцессорных (Xeon Xeon E7-48xx и Xeon E7-88xx) HPE Synergy 680 Gen9 – это фактически «склейка» двух 620-х серверов. Этот сервер также поддерживает фантастические 6 Тб памяти DDR4.

3. Модуль хранения HPE Synergy D3940 – до 40 дисков SFF HDD или SSD. Этот модуль хранения — фактически JBOD (от англ. Just a bunch of disks, просто пачка дисков), своих контроллеров хранения модуль не имеет. Поначалу наличие такого странного модуля вызвало один большой вопрос – ЗАЧЕМ? Но, мне кажется, я начал догадываться для чего он нужен. Кстати, в блейд-сервер для работы с модулем хранения надо устанавливать RAID-контроллер Smart Array P542D/2GB FBWC 12Gb. На первом фото этот модуль установлен в зону №1, занимая отсеки № 1 и №2.

4. HPE Synergy Composer – сервер мониторинга и управления с предустановленным OneView. Про него придется писать отдельную статью. На первом фото вверху — лежит на столе вытащенный из шасси.

5. HPE Synergy Frame Link Module(FLM) – модуль, подключаемый к HPE Synergy Composer. Я так понимаю, передает информацию с других шасси, когда в инсталляции более одного шасси. Постараюсь разобрать его в той же статье, что и композер.

6. HPE Synergy Image Streamer – модуль для хранения и развертывания операционных систем с нужными в данный момент настройками. Такого модуля я еще не встречал, видимо, ему тоже придется посвятить отдельную статью в рамках обзора.

7. Сетевая часть представлена пока не очень богато, однако, прежде чем перейти к перечислению доступных сейчас модулей, хочется отдельно отметить, что в шасси сразу заложена разводка пассивной коммутации в виде оптики, а заявленная доступная скорость внутренней коммутации – до 100 Гбит/с. Видимо, это одна из причин замены предыдущего шасси с7000 – там медь и максимум 20 Гбит/с.
Итак, что можно установить:

Ethernet/CNA:

• a. HPE Virtual Connect SE 40GB F8 Module for HPE Synergy — на втором фото видно, он установлен в отсек 3, над верхним рядом блоков питания;
• b. HPE Synergy 10Gb Interconnect Link Module;
• c. HPE Synergy 20Gb Interconnect Link Module;
• d. HPE Synergy 10/40Gb Pass Thru Module.

SAS-подключения:

• a. HPE Synergy 12Gb SAS Connection Module with 12 Internal Ports — на втором фото видно, он установлен в самый верхний отсек;
• b. HPE Synergy D3940 Redundant I/O Adapter.
• Выглядит так, что диски из модуля с дисками, расположенного в одном шасси (пусть будет шасси 2), можно подключать к серверам в другом шасси (например, шасси 1).

SAN-сеть:

• a. Brocade 16Gb/12 Fibre Channel SAN Switch Module;
• b. Brocade 16Gb/24 Fibre Channel SAN Switch Module;
• с. HPE Virtual Connect SE 16Gb Fibre Channel Module — мне кажется, что на втором фото он установлен в отсек 6, над нижним рядом блоков питания.

Со стороны серверов можно установить 4 типа адаптеров:

• a. HPE Synergy 3820C 10/20Gb Converged Network Adapter(CNA);
• b. HPE Synergy 3830C 16Gb Fibre Channel Host Bus Adapter;
• c. HPE Synergy 3530C 16Gb Fibre Channel Host Bus Adapter;
• d. HPE Synergy 2820C 10Gb Converged Network Adapter(CNA).

Как видно (сюрприз!), чисто Ethernet сетевых карт нет вообще.

8. Вентиляторы и блоки питания – в теории 10 вентиляторов всегда в комплекте, БП — два по 2650 Вт в комплекте, максимум 6 шт, добавляются парами. В теории, потому что в конфигураторе функция по изменению количества БП есть, но на данный момент заблокирована, по умолчанию стоит 6 штук.

По энергопотреблению и тепловыделению можно пройтись отдельно. Я сделал две примерно одинаковые конфигурации серверов (два процессора Intel Xeon E5-2660 v4 (14C), 4x16 Gb DDR4 PC4-2400, два диска 300 Gb 10k, сеть 20 Gbit) в программе, моделирующей инженерные данные «HPE Power Advisor 7.9», получилось следующее:
Для шасси Synergy 12000 Frame с двенадцатью серверами 480 G9, одним композером, одним стриммером, парой коммутаторов:



Для шасси BladeSystem с7000 с 16 серверами BL460c G9, двумя модулями управления Onboard Administrator, парой коммутаторов (почему то не указан в этом окне вес – 219 кг):



Видно, что при одном объеме(10U) шасси с7000 тяжелее (выше плотность серверов), но Synergy Frame кушает больше электричества и больше выделяет тепла, примерно, в 1,2 раза. С чем связано – пока не очень понятно.

В целом, выше перечислены основные компоненты. Что можно сказать? Изначально конструкция кажется несуразной: серверов меньше, чем в с7000, жрет электричества больше, какие-то полки дисковые, которые содержат просто набор дисков без какой то структуры, SAS коммутаторы. Зачем городить такой огород, когда есть нормальное работающее шасси с7000? Так я думал примерно полгода, до тех пор, пока не посыпались задачи на проектирование инфраструктур по BigData и Hadoop. Оказалось, что для этих задач обычная инфраструктура, типа шасси с серверами+SAN сеть+ СХД, практически не применима. Если с серверами особо нет проблем, то внутренний интерконнект и СХД – узкое место таких систем. Основное достоинство Hadoop – возможность линейного наращения вычислительных мощностей до огромных масштабов (я видел описание решений для 2000 узлов), что явно невозможно для архитектур типа «блейды+СХД», во-первых, в с7000 — максимум 20 Гбит/с (скорее, это симметричная десятка), во-вторых, СХД имеет ограничение по количеству дисков на контроллерную пару и, когда требуется это количество увеличить, приходится менять СХД, а это и весьма затратно, плюс миграция данных – это технологически сложный процесс. Хорошее описание узких мест нашел тут – глава «Blades, SANs, and Virtualization».

Так вот, если посмотреть на Synergy под этим углом, то платформа выглядит весьма выгодно: поставил в сервер нужный контроллер, вставил сервер в шасси, через Composer отдал в модуле хранения нужное число дисков новому серверу, через Image Streamer быстро накатил из готового образа какой-нибудь «unmodified Debian 7.3» или RHEL с нужными настройками, и новая вычислительная нода готова. Учитывая, что одной парой композеров можно управлять 20-ю шасси (5 полных стоек, до 240 серверов) – это просто ОЧЕНЬ круто. В этой парадигме Synergy – практически идеальное решение, реальная альтернатива стоечным серверам, из которых сейчас собираются фермы для BigData. Принимая во внимание, что прогноз для рынка анализа «Больших Данных» — 50 миллиардов USD к 2020 году, разработка Synergy – это очень сильная заявка на лидерство в этом сегменте.

В дальнейших статьях хотелось бы рассмотреть компоненты Synergy отдельно:

• 1. Само шасси и сервера.
• 2. Модуль хранения с дисками и SAS коммутаторы.
• 3. Сеть.
• 4. HPE Synergy Composer.
• 5. HPE Synergy Image Streamer.

Дальше интересно? )

P.S. — Вообще оригинальный заголовок я планировал такой — Хочу увидеть суслика! («Видишь суслика? А он – есть!» к/ф ДМБ)