Блейд-система Cisco UCS

cisco-ucs-01

Относительно недавно (3-4 года назад, если не ошибаюсь) производитель отличного сетевого оборудования компания Cisco, начала выводить на корпоративный рынок продукты из других направлений, в том числе и серверного.

Серверное направление у Циски называется — Cisco UCS (Unified Computing System), и представляет собой модельный ряд из «рековых» (rack-mount) и «блейдовых» (blade)серверов.

Рековые сервера объединены в серию «C» а блейды в серию «B». То есть, если сервер называется Cisco UCS C-220-M2 — это стоечный сервер, а если B-220-M2 — это блейд.

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

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

Да, с рековыми серверами тоже есть инновации в плане сети и управления, но с блейдами это выглядит более эффектно :))

 

Идея всего этого счастья заключается в «унификации», как можно догадаться из названия 🙂 Под этим наумняченным англицизмом понимается попытка стандартизации однотипных компонентов и консолидации компонентов общего назначения (если вы ничего не поняли — не расстраивайтесь, чуть ниже по тексту вы поймете о чем речь).

Для начала — блейд-система Cisco UCS предполагает использование конвергентной сети на основе 10G Ethernet. Для тех кто не в теме, конвергентная сеть, в данном случае, значит объединение SAN и LAN в одну физическую сеть. Данный подход считается более универсальным и гибким (как говорит «циска» — унифицированным :)) в построении сети, т.к. позволяет использовать единое сетевое оборудование (конвергентрые коммутаторы) для агрегации всех сетевых линков и управления всем сетевым трафиком из единой точки.

То есть, это уже как минимум сокращает количество оборудования, необходимого для построения ЦОД. Вместо  двух коммутаторов для LAN и двух коммутаторов для SAN — мы берем два конвергентных коммутатора (например Cisco Nexus 5K серии) и заводим туда SAN и LAN.

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

Лучше всего особенности Cisco UCS объяснять в сравнении с обычным подходом blade-систем, поэтому, я так и сделаю.

Возьмем классическую blade-систему

Как мы знаем, в классическом подходе у нас есть шасси («корзина»), в которой есть сервера. Кроме серверов, в корзине собраны общие компоненты для всех серверов:

— блоки питания

— вентиляторы

— сетевые устройства (коммутаторы или Path through модули)

— система управления

в первую очередь, нас интересуют сетевые устройства и система управления.

В классическом подходе, у нас для каждого протокола свой коммутатор или Path throughмодуль.

То есть, если нам нужно каждому серверу дать 1G Ethernet и 8G FC — мы ставим 2 коммутатора 1G Ethernet и 2 коммутатора 8G FC и получаем у каждого сервера 2 шт.Ethernet карты 1G и 2 карты 8G FC. И условно все… Как-то варьировать сетевые устройства отдельного сервера особо не получится. Конечно, есть вариант поставить еще 2 коммутатора в корзину, но далеко на этом тоже не уедешь, и особого разнообразия не получишь.

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

Что нам предлагает Cisco UCS:

cisco-ucs-02

С питанием и охлаждением здесь все то же.

Сетевые функции в Cisco UCS выполняет отдельное устройство — Fabric Interconnect (FIС)

cisco-ucs-05

которое выполнено в форм-факторе 1U (32 порта) или 2U (64 порта). Данное устройство выполняет роль конвергентного коммутатора (по сути — это тот же Nexus 5K серии), а также системы управления, о которой мы поговорим позже. Для отказоустойчивости, данных устройств должно быть 2.

Блейд-шасси Cisco UCS:

cisco-ucs-03

не содержит сетевых блоков в виде коммутаторов и Path through модулей, заточенных под конкретные задачи. Вместо них, в корзине установлены 2 стандартных (унифицированных :))) модуля ввода-вывода (Fabric Extender),

cisco-ucs-06

каждый из которых имеет 4 или 8 портов 10GFabric Extender называются унифицированными неспроста, т.к. способны передавать трафик по любым протоколам (Ethernet, Fibre Channel, FCoE).

Каждая корзина, посредством данных модулей ввода-вывода, подключается к Fabric Interconnect с помощью до 16 медных 10G шнурков (по 8 шт. на каждую FIC), что обеспечивает пропускную способность до 160 Гбит/сек между шасси и фабрикой.

За счет того, что сетевые коммутаторы вынесены за пределы шасси и являются общими для нескольких шасси (до 40 шт.), а само шасси высотой 6 юнитов, достигается достаточно высокая (хотя и не самая высокая) плотность системы по ресурсам, в пересчете на занимаемые в шкафу юниты. Кроме того, упрощается коммутация, настройка и обслуживание, масштабирование, высокая гибкость конфигурации, появляется единая точка управления всем этим хозяйством и т.п..

Пример коммутации Cisco UCS:

cisco-ucs-08

В другом ракурсе:

cisco-ucs-07

Конечно, в случае когда у нас всего одно шасси, чисто архитектурно — классическая схема будет проще, потому что у нас все в одной корзине и не нужно какие-то 2 дополнительные устройства ставить сверху.

В случае, когда у нас есть 2 и больше шасси — концепция Cisco UCS имеет явные преимущества, особенно, если учесть мощную систему управления.

К стати о системе управления.

Как я уже и говорил, все управление Cisco UCS сосредоточено на Fabric Interconnect. Система управления называется Cisco UCS Manager и имеет графический интерфейс иCLI. Графическая оболочка традиционно выполнена на яве (гори она в аду) а CLIдоступен через консольный порт на самой железке, или по SSH.

UCS Manager

cisco-ucs-10

cisco-ucs-09

позволяет централизованно управлять всей системой UCS, которая может содержать до 40 шасси и до 320 blade-серверов (возможно уже больше, могу ошибаться), при чем управлять достаточно гибко и эффективно.

Что я подразумеваю под гибкостью? Это в первую очередь виртуализация (если можно это так назвать) ввода-вывода. То есть у каждого сервера есть физическая карта ввода-вывода (на подобии классической «мезанины»), которая агрегирует на себе все типы трафика и позволяет нарезать много виртуальных адаптеров Fibre ChannelFCoE,Ethernet или даже iSCSI в любых комбинациях.

Например — у нас есть блейд, на который мы будем устанавливать ESXi. По дизайну нам нужно 4 интерфейса 10G Ethernet и 2 HBA карточки FC 8G. Мы заходим в UCS Manager и для конкретного сервера, или группы серверов нарезаем необходимую нам конфигурацию.

Максимальная пропускная способность на лезвие по всем протоколам — 40G (если не ошибаюсь).

Вторая удобная вещь это сервисные профили (Service Profile), которые представляют собой некий образ сервера, и содержат все его настройки, MAC и WWN адреса, настройки БИОС, настройки адаптеров и т.п.. Это дает простую переносимость настроек с одного сервера на другой.

Немного объясню на примере:

Есть у нас блейд с работающей на нем СУБД Oracle (к примеру). Реализована схемаBoot-from SAN и все данные лежат на LUN-ах СХД. В случае, если сервер выходит из строя, мы извлекаем его из шасси, ставим на его место другой сервер (при чем необязательно такой же конфигурации железа) и накатываем на него профиль старого сервера. После данной операции, новый сервер получит абсолютно все настройки старого сервера (включая WWN и MAC адреса) и сможет загрузиться без выполнения дополнительных действий (настройки зоннинга, маппинга LUN-ов на стороне СХД и пр.).

Таким образом, замена вышедшего из строя сервера займет минут 15…

Кроме быстрой замены профиля у нас появляются возможности клонирования и создания шаблонов сервисных профилей.

Представим другой сценарий:

У нас есть виртуальная инфраструктура из 15 однотипных серверов. Все сервисные профили созданы на основе шаблона. Щедрое руководство купило еще 8 серверов для расширения существующей инфраструктуры. Вместо долгой и нужной прошивки каждого сервера, настройки адаптеров, политик загрузки и т.п. мы выставляем каждому серверу актуальную версию прошивки, а потом в несколько кликов разворачиваем из шаблона 8 новых сервисных профилей и привязываем их на новые сервера. В результате новые сервера получают типичные для данного шаблона настройки и WWNMAC-адреса из пулов — вуаля!

И много других примеров можно привести, где данные фичи будут очень к стати, все зависит от вашей фантазии 😉

Итак, хватит хвалить Cisco UCS — пора немного и поругать :))

Из негативных моментов, blade-системы Cisco UCS, можно выделить ее неотесанность. Т.к. система не очень давно на рынке, по сравнению с конкурентами. При работе с ней складывается впечатление, что она пока что немного сыровата и имеют место быть мелкие и не очень глюки.

Хотя, коллеги, работающие с блейдами других вендоров, говорят что это вполне нормально и глюки есть у всех.

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

Ну и напоследок хотелось бы упомянуть о том, что на основе блейдов Cisco UCSпостроены такие программно-аппаратные комплексы как Vblock от компании VCE,VSPEX от компании EMC и Flexpod от Cisco и NetApp.

Данные комплексы представляют собой готовые решения для построения облачной инфраструктуры и они заслуживают отдельной статьи. Постараюсь в будущем рассказать немного об их архитектуре и поделиться опытом внедрения, если будет интерес у читателей.

Все это очень поверхностно, и наверняка многие это знают, но в дебри залезать не хочу т.к. получится летопись на несколько мегабайт :))

Вообще, буду рад выслушать вопросы и замечания. Если что-то было не совсем понятно (или совсем непонятно) — постараюсь рассказать об этом более подробно.

з.ы. все фотки и рисунки из интернета.