Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wptelegram domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/u632055791/domains/itg.az/public_html/wp-includes/functions.php on line 6114

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wp-pagenavi domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/u632055791/domains/itg.az/public_html/wp-includes/functions.php on line 6114

Notice: Функция _load_textdomain_just_in_time вызвана неправильно. Загрузка перевода для домена kirki была запущена слишком рано. Обычно это индикатор того, что какой-то код в плагине или теме запускается слишком рано. Переводы должны загружаться при выполнении действия init или позже. Дополнительную информацию можно найти на странице «Отладка в WordPress». (Это сообщение было добавлено в версии 6.7.0.) in /home/u632055791/domains/itg.az/public_html/wp-includes/functions.php on line 6114
Блейд-система Cisco UCS

Блейд-система 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.

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

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

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

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