Привет, Хабр!
Быть облачным провайдером — значит постоянно аккумулировать новые знания и экспертизу. За годы работы мы сформировали достаточно большое количество практик, которых стараемся придерживаться для обеспечения наилучшего уровня сервиса. Одна из них — использование решений комплекса Cisco Unified Computing System. Под катом я хочу рассказать, почему, на наш взгляд, UCS является одним из лучших решений для провайдеров, и обсудить некоторые особенности работы и кейсы использования системы.
С момента появления Cisco UCS на рынке прошло почти 8 лет. Это вполне достаточный срок, чтобы у аудитории сформировалось полное представление о технологии, а из мануалов, обзоров и обучающих статей можно было составить объемистый книжный том. Впрочем, из маркетинговых статей по этой теме получится двухтомник. Мы постараемся поговорить о Cisco UCS максимально предметно: выделим ключевые особенности решения, на их основе обсудим преимущества для для облачных сервис-провайдеров и поделимся кейсами.
Термин и тема «конвергентность» вошли в обиход благодаря инженерам HP, это произошло приблизительно 10 лет назад. Собственно, HP же первыми выпустили так называемые конвергентные модули для установки в шасси HP BladeSystem c7000. Они давали возможность, к примеру, выделять на конкретный blade-сервер определенную полосу пропускания. Это был первый шаг к конвергентности, однако это решение не обладало всеми необходимыми признаками конвергентных систем.
На всякий случай поясним: конвергентной инфраструктурой является единый комплекс оборудования и программного обеспечения с единой точкой входа для управления всем оборудованием, входящим в состав комплекса, плюс оркестратор.
Что же касается Cisco UCS, это решение уже полностью соответствует определению конвергентности в части оборудования и входящего в состав комплекса программного обеспечения.
Внимательно изучим приведенную выше схему и дадим краткое описание элементов комплекса «сверху-вниз».
Программное обеспечение Cisco UCS Manager
Единая точка входа для управления всеми аппаратными компонентами, изображенными на схеме, и оркестратор, позволяющий управлять компонентами в ручном режиме или через REST API. Это своего рода «мозг» комплекса. Он установлен внутри Fabric Interconnect. Все без исключения настройки оборудования выполняются через интерфейс управления (GUI или CLI) или API UCS Manager.
Fabric Interconnect
Аппаратный unified-коммутатор, построенный на базе Cisco Nexus. Он обеспечивает сетевую связность всех компонент комплекса, а также связность blade-серверов с внешними сетями. В состав комплекса входят два Fabric Interconnect. В последних версиях — FI6332 и FI6454 — поддерживается подключение до 20 шасси 5108, а суммарное количество blade-серверов при этом достигает:
Сегодня это едва ли не единственное решение, предоставляющее возможности для интеграции в рамках одной точки входа и поддерживающее бесшовную сетевую связность без использования дополнительных коммутаторов уровня ToR либо иных модулей, устанавливаемых в шасси вместе с blade-серверами.
Шасси c5108
В сравнении с FI это достаточно простые устройства. Их компоновка стандартна для blade-систем: PSU, вентиляторы, а также ключевой компонент шасси — FEX-модули, осуществляющие связность между blade-серверами и FI. На момент написания статьи поддерживаются как 4-портовые 40GbE-модули 2304, так и 8- или 4-портовые 10GbE-модули 2204. Их отличительная особенность — возможность группировки портов, что позволяет увеличить общую полосу пропускания.
VIC (Virtual Interface Card)
Интеллектуальный адаптер, устанавливаемый в blade-сервер. Позволяет выделять виртуальные сетевые ресурсы как для аппаратных серверов, так и для виртуальных машин. Поддерживает Eth и FC/FCoE-протоколы передачи данных.
Теперь, когда устройство решения более-менее понятно, поговорим о том, почему на наш субъективный взгляд Cisco UCS является одним из самых удобных решений на рынке.
Теперь, когда у нас есть четкое представление о том, из чего состоит решение, поговорим о его преимуществах. Чем решение от Cisco лучше, чем его “родственники” — например, те же HP Synergy? Этот вопрос нам нередко задают наши коллеги, хотя ответ (как нам кажется) лежит на поверхности. Дело в следующем:
Де-факто в этих трех пунктах сосредоточены все основные требования к решению как со стороны бизнеса, так и со стороны ИТ. Тем не менее, без кейсов эти преимущества выглядят несколько голословно, поэтому далее мы “расшифруем” их, приводя реальные примеры.
Как и обещали в начале статьи, в этом разделе мы рассмотрим кейсы эксплуатации Cisco UCS. Начнем с обзора нашего опыта и плавно перейдем к конкретным ситуациям.
За то время, что мы используем решения Cisco UCS, нам приходилось вводить в эксплуатацию и расширять онлайн 8 комплексов (под комплексом понимается пара Fabric Interconnect и минимум одно blade-шасси), суммарно — 16 FI и более. Самый первый комплекс мы вводили в эксплуатацию в 2014 году, обладая на тот момент минимальным практическим опытом. Этот процесс занял у нас три дня, два из которых были потрачены на изучение документации и понимание логики работы оборудования. Отметим, что документация у Cisco оформлена на уровне лучших образцов RedBook от IBM — те, кто знаком, поймут сравнение.
Разобравшись с логикой и основными принципами настройки, мы без труда собрали и запустили оборудование. Затем выполнили обновление прошивок всех компонентов, настроили шаблоны профилей серверов и создали профили. Всего за один рабочий день.
Дальнейшее внедрение выполнялось в рамках стандартных ITIL-процедур управления изменениями и занимало не более четырех часов на развертывание каждой пары FI и одного-двух шасси с момента включения по питанию до полной готовности шасси к использованию, включая создание и настройку всех необходимых шаблонов и политик.
Использование REST API и PowerTools-модулей может ускорить процедуру инсталляции. К примеру, копирование 500+ VLAN на новую инсталляцию выполняется всего двумя простыми действиями с помощью PowerTools:
Масштабирование инфраструктуры выполняется с помощью подключения новых шасси с blade-серверами к установленной паре FI (при наличии нужного количества свободных портов). Процедура на 100% «онлайновая» и может быть выполнена из интерфейса Cisco UCS Manager. При правильных глобальных настройках сразу после перевода портов FI, к которым подключено шасси, в нужный режим работы эти порты автоматически собираются в Port-channel. Далее запускается автоматизированная процедура acknowledge, в рамках которой выполняется:
Еще раз напомним, что все это делается без вмешательства инженеров, на основании глобальных политик, заданных при вводе комплекса в эксплуатацию.
По времени такая процедура занимает примерно час-полтора. Физическое подключение нового шасси к FI заключается в коммутации FEX к портам на FI, при этом оптимально использовать DAC-кабели. И вовсе не обязательно брать оригинальные кабели от Cisco.
Как много в этом звуке… О ней можно говорить много, причем не только хорошее. Как говорится, без бочки дегтя ложка меда не будет такой вкусной. А если серьезно, то все рутинные процедуры, которые в обычной инфраструктуре занимают много минут или часов, здесь выполняются автоматизировано из GUI. Например, для проливки нового VLAN на все blade-серверы комплекса (а их, напомню, поддерживается от 80 до 160 штук) достаточно добавить его в vNIC template в разделе LAN Policy — новый VLAN автоматически прольется на все blade-сервера, в составе профилей которых присутствует этот vNIC template.
Раз уж речь зашла о Policy, стоит сказать, что буквально все настройки устанавливаются через политики. Можно, конечно же, их не использовать, но это будет… кхм, слишком жестко. Все сетевые настройки для blade-серверов, включая MAC- и IP-адреса для KVM, Flow Control, LACP, CDP, VMQ, задаются через политики. Тем же способом определяются настройки BIOS, версия FW, которая будет залита на blade-сервер, Power Control, настройки доступа по IPMI и многое другое.
Приведем еще один пример, представляющий возможности UCS по автоматизации рутинных операций, таких как настройки FC-зонинга.
В настройках Storage Connection Policy достаточно выбрать нужный zoning type и задать его, например, как «single initiator single target». В этом случае при привязке blade-сервера к profile template будет создаваться отдельная зона. В эту зону будет автоматически включаться заданный WWN таргета и WWPN виртуального HBA с нужного порта, принадлежащего нужной фабрике.
Политики привязываются к шаблонам профилей (template profile) для серверов. Дальше все просто: привязка шаблона к нужному blade-серверу и инициализация. На выходе получаем готовый к установке операционной системы сервер. Инициализация сервера выполняется не более 10-20 минут, причем она может выполняться одновременно для нужного количества серверов. Итого, всего за 25-35 минут мы получаем от 80 до 160 серверов, полностью готовых к установке ОС. Безусловно, процесс установки также можно автоматизировать, и Cisco UCS API может помочь вам в этой задаче, но это уже тема для отдельной статьи.
Итого: на развертывание комплекса из пары FI, 20 blade-шасси и 160 blade-серверов b200 M5 с нуля до готовности к установке ОС один инженер потратит не более 8 часов, причем основное время, порядка 3-х часов, уйдет на создание политик и шаблонов профилей. Оставшееся время можно будет посвятить куда более важным делам, ожидая инициализацию шасси и blade-серверов после привязки шаблонов к последним. Указанное время развертывания неплохо ложится в парадигму сокращения операционных расходов (OPEX), о которой уже говорилось выше.
Универсальность, универсальность и еще раз универсальность — наверное, так можно озвучить девиз комплекса. Проиллюстрируем этот тезис списком возможностей Cisco UCS, которые делают его уникальным на рынке даже спустя 8 лет. По нынешним меркам это весьма немалый срок.
Разумеется, возможности управления сторонним оборудованием не включены в UCS Manager — для этого у Cisco есть другие инструменты — но и те, что приведены в списке выше, уже впечатляют. Вот несколько примеров, когда unified features сослужили нам хорошую службу:
Временная замена коммутаторам Cisco Nexus
Поставка новых коммутаторов Cisco Nexus существенно задержалась. Новая СХД от NetApp приехала раньше них и могла бы простаивать несколько месяцев: не хватало 10GbE-портов для полноценного отказоустойчивого подключения. Решение: подключаем СХД через порты FI, сконфигурированные в режим Appliance, конфигурируем port-channel с поддержкой LACP, вводим СХД в эксплуатацию на несколько месяцев раньше, чем приезжают коммутаторы. Оборудование работает, приносит доход, уровень CAPEX снижается.
Миграция на новую СХД
Нашему заказчику необходимо было с минимальными потерями мигрировать данные со старой СХД EMC на СХД NetApp. Свободных портов в его старой FC фабрике нет, подключить FI в общую фабрику нет возможности. Но на СХД заказчика нашлись свободные порты. Подключаем их к FI, поднимаем на FC vSAN. Запускаем миграцию виртуальных машин через Storage vMotion на NetApp, подключенный по NFS. Всё в порядке, все довольны. Миграция произведена успешно.
Нельзя не упомянуть о ряде преимуществ, которые предоставляет архитектура UCS, например, для виртуальной инфраструктуры под управлением VMware. Адаптеры VIC, о которых мы уже говорили при описании компонентов, на физическом уровне коммутируются через Midplane шасси с IO модулями через Backplane порты. На один VIC может приходить от 2 до 4 портов, которые автоматически конфигурируются в EtherChannel-порты на уровне UCS Manager. Это позволяет получить следующие преимущества сетевых соединений:
Как видите, комплекс Cisco UCS действительно хорошо зарекомендовал себя в целом ряде задач и кейсов. С одной стороны, это хорошо документированное и проверенное временем решение. С другой — оно не теряет своей актуальности и идеально закрывает в своей части все задачи облачного провайдера. Если у вас есть дополнения к статье или вы захотите поделиться собственным опытом, ждем вас в комментариях.
Быть облачным провайдером — значит постоянно аккумулировать новые знания и экспертизу. За годы работы мы сформировали достаточно большое количество практик, которых стараемся придерживаться для обеспечения наилучшего уровня сервиса. Одна из них — использование решений комплекса Cisco Unified Computing System. Под катом я хочу рассказать, почему, на наш взгляд, UCS является одним из лучших решений для провайдеров, и обсудить некоторые особенности работы и кейсы использования системы.
С момента появления Cisco UCS на рынке прошло почти 8 лет. Это вполне достаточный срок, чтобы у аудитории сформировалось полное представление о технологии, а из мануалов, обзоров и обучающих статей можно было составить объемистый книжный том. Впрочем, из маркетинговых статей по этой теме получится двухтомник. Мы постараемся поговорить о Cisco UCS максимально предметно: выделим ключевые особенности решения, на их основе обсудим преимущества для для облачных сервис-провайдеров и поделимся кейсами.
Вначале было слово
Термин и тема «конвергентность» вошли в обиход благодаря инженерам HP, это произошло приблизительно 10 лет назад. Собственно, HP же первыми выпустили так называемые конвергентные модули для установки в шасси HP BladeSystem c7000. Они давали возможность, к примеру, выделять на конкретный blade-сервер определенную полосу пропускания. Это был первый шаг к конвергентности, однако это решение не обладало всеми необходимыми признаками конвергентных систем.
На всякий случай поясним: конвергентной инфраструктурой является единый комплекс оборудования и программного обеспечения с единой точкой входа для управления всем оборудованием, входящим в состав комплекса, плюс оркестратор.
Что же касается Cisco UCS, это решение уже полностью соответствует определению конвергентности в части оборудования и входящего в состав комплекса программного обеспечения.
Архитектура решения
Внимательно изучим приведенную выше схему и дадим краткое описание элементов комплекса «сверху-вниз».
Программное обеспечение Cisco UCS Manager
Единая точка входа для управления всеми аппаратными компонентами, изображенными на схеме, и оркестратор, позволяющий управлять компонентами в ручном режиме или через REST API. Это своего рода «мозг» комплекса. Он установлен внутри Fabric Interconnect. Все без исключения настройки оборудования выполняются через интерфейс управления (GUI или CLI) или API UCS Manager.
Fabric Interconnect
Аппаратный unified-коммутатор, построенный на базе Cisco Nexus. Он обеспечивает сетевую связность всех компонент комплекса, а также связность blade-серверов с внешними сетями. В состав комплекса входят два Fabric Interconnect. В последних версиях — FI6332 и FI6454 — поддерживается подключение до 20 шасси 5108, а суммарное количество blade-серверов при этом достигает:
- b480 M5 — до 80 серверов;
- b200 M5 — до 160 серверов.
Сегодня это едва ли не единственное решение, предоставляющее возможности для интеграции в рамках одной точки входа и поддерживающее бесшовную сетевую связность без использования дополнительных коммутаторов уровня ToR либо иных модулей, устанавливаемых в шасси вместе с blade-серверами.
Шасси c5108
В сравнении с FI это достаточно простые устройства. Их компоновка стандартна для blade-систем: PSU, вентиляторы, а также ключевой компонент шасси — FEX-модули, осуществляющие связность между blade-серверами и FI. На момент написания статьи поддерживаются как 4-портовые 40GbE-модули 2304, так и 8- или 4-портовые 10GbE-модули 2204. Их отличительная особенность — возможность группировки портов, что позволяет увеличить общую полосу пропускания.
VIC (Virtual Interface Card)
Интеллектуальный адаптер, устанавливаемый в blade-сервер. Позволяет выделять виртуальные сетевые ресурсы как для аппаратных серверов, так и для виртуальных машин. Поддерживает Eth и FC/FCoE-протоколы передачи данных.
Теперь, когда устройство решения более-менее понятно, поговорим о том, почему на наш субъективный взгляд Cisco UCS является одним из самых удобных решений на рынке.
Почему Cisco UCS
Теперь, когда у нас есть четкое представление о том, из чего состоит решение, поговорим о его преимуществах. Чем решение от Cisco лучше, чем его “родственники” — например, те же HP Synergy? Этот вопрос нам нередко задают наши коллеги, хотя ответ (как нам кажется) лежит на поверхности. Дело в следующем:
- универсализм решения, соответствие термину «unified» ⇒ снижение OPEX;
- минимальное количество оборудования позволяет закрыть максимальное количество кейсов (о них чуть ниже), а также простота масштабирования ⇒ снижение CAPEX;
- отличная производительность и балансировка нагрузки, доступность Enterprise-уровня.
Де-факто в этих трех пунктах сосредоточены все основные требования к решению как со стороны бизнеса, так и со стороны ИТ. Тем не менее, без кейсов эти преимущества выглядят несколько голословно, поэтому далее мы “расшифруем” их, приводя реальные примеры.
Применение на практике
Как и обещали в начале статьи, в этом разделе мы рассмотрим кейсы эксплуатации Cisco UCS. Начнем с обзора нашего опыта и плавно перейдем к конкретным ситуациям.
Ввод оборудования в эксплуатацию
За то время, что мы используем решения Cisco UCS, нам приходилось вводить в эксплуатацию и расширять онлайн 8 комплексов (под комплексом понимается пара Fabric Interconnect и минимум одно blade-шасси), суммарно — 16 FI и более. Самый первый комплекс мы вводили в эксплуатацию в 2014 году, обладая на тот момент минимальным практическим опытом. Этот процесс занял у нас три дня, два из которых были потрачены на изучение документации и понимание логики работы оборудования. Отметим, что документация у Cisco оформлена на уровне лучших образцов RedBook от IBM — те, кто знаком, поймут сравнение.
Разобравшись с логикой и основными принципами настройки, мы без труда собрали и запустили оборудование. Затем выполнили обновление прошивок всех компонентов, настроили шаблоны профилей серверов и создали профили. Всего за один рабочий день.
Дальнейшее внедрение выполнялось в рамках стандартных ITIL-процедур управления изменениями и занимало не более четырех часов на развертывание каждой пары FI и одного-двух шасси с момента включения по питанию до полной готовности шасси к использованию, включая создание и настройку всех необходимых шаблонов и политик.
Использование REST API и PowerTools-модулей может ускорить процедуру инсталляции. К примеру, копирование 500+ VLAN на новую инсталляцию выполняется всего двумя простыми действиями с помощью PowerTools:
- выборка списка VLAN из рабочей инфраструктуры;
- заливка списка VLAN на новый комплекс.
Масштабирование инфраструктуры выполняется с помощью подключения новых шасси с blade-серверами к установленной паре FI (при наличии нужного количества свободных портов). Процедура на 100% «онлайновая» и может быть выполнена из интерфейса Cisco UCS Manager. При правильных глобальных настройках сразу после перевода портов FI, к которым подключено шасси, в нужный режим работы эти порты автоматически собираются в Port-channel. Далее запускается автоматизированная процедура acknowledge, в рамках которой выполняется:
- обновление всех компонентов шасси на актуальную версию FW;
- настройка Power Cap;
- маппинг Backplane портов на FEX в нужные фабрики и сборки port-channel для этих самых портов.
Еще раз напомним, что все это делается без вмешательства инженеров, на основании глобальных политик, заданных при вводе комплекса в эксплуатацию.
По времени такая процедура занимает примерно час-полтора. Физическое подключение нового шасси к FI заключается в коммутации FEX к портам на FI, при этом оптимально использовать DAC-кабели. И вовсе не обязательно брать оригинальные кабели от Cisco.
Эксплуатация
Как много в этом звуке… О ней можно говорить много, причем не только хорошее. Как говорится, без бочки дегтя ложка меда не будет такой вкусной. А если серьезно, то все рутинные процедуры, которые в обычной инфраструктуре занимают много минут или часов, здесь выполняются автоматизировано из GUI. Например, для проливки нового VLAN на все blade-серверы комплекса (а их, напомню, поддерживается от 80 до 160 штук) достаточно добавить его в vNIC template в разделе LAN Policy — новый VLAN автоматически прольется на все blade-сервера, в составе профилей которых присутствует этот vNIC template.
Раз уж речь зашла о Policy, стоит сказать, что буквально все настройки устанавливаются через политики. Можно, конечно же, их не использовать, но это будет… кхм, слишком жестко. Все сетевые настройки для blade-серверов, включая MAC- и IP-адреса для KVM, Flow Control, LACP, CDP, VMQ, задаются через политики. Тем же способом определяются настройки BIOS, версия FW, которая будет залита на blade-сервер, Power Control, настройки доступа по IPMI и многое другое.
Приведем еще один пример, представляющий возможности UCS по автоматизации рутинных операций, таких как настройки FC-зонинга.
В настройках Storage Connection Policy достаточно выбрать нужный zoning type и задать его, например, как «single initiator single target». В этом случае при привязке blade-сервера к profile template будет создаваться отдельная зона. В эту зону будет автоматически включаться заданный WWN таргета и WWPN виртуального HBA с нужного порта, принадлежащего нужной фабрике.
Политики привязываются к шаблонам профилей (template profile) для серверов. Дальше все просто: привязка шаблона к нужному blade-серверу и инициализация. На выходе получаем готовый к установке операционной системы сервер. Инициализация сервера выполняется не более 10-20 минут, причем она может выполняться одновременно для нужного количества серверов. Итого, всего за 25-35 минут мы получаем от 80 до 160 серверов, полностью готовых к установке ОС. Безусловно, процесс установки также можно автоматизировать, и Cisco UCS API может помочь вам в этой задаче, но это уже тема для отдельной статьи.
Итого: на развертывание комплекса из пары FI, 20 blade-шасси и 160 blade-серверов b200 M5 с нуля до готовности к установке ОС один инженер потратит не более 8 часов, причем основное время, порядка 3-х часов, уйдет на создание политик и шаблонов профилей. Оставшееся время можно будет посвятить куда более важным делам, ожидая инициализацию шасси и blade-серверов после привязки шаблонов к последним. Указанное время развертывания неплохо ложится в парадигму сокращения операционных расходов (OPEX), о которой уже говорилось выше.
Unified System
Универсальность, универсальность и еще раз универсальность — наверное, так можно озвучить девиз комплекса. Проиллюстрируем этот тезис списком возможностей Cisco UCS, которые делают его уникальным на рынке даже спустя 8 лет. По нынешним меркам это весьма немалый срок.
- поддержка unified интерфейсов 10GbE/16Gbit FC, 40 GbE (или 4x10 GbE breakout);
- поддержка протоколов Fibre Channel, Ethernet FCoE в рамках одного FI;
- поддержка полноценной FC Fabric на уровне FI, возможность интеграции с FC коммутаторами от Brocade в режиме NPV;
- поддержка подключения к FI rack-серверов Cisco через дополнительные extender'ы, управление серверами через интерфейс UCS Manager;
- поддержка подключения к FI rack-серверов других вендоров, предоставление связности на уровне L2 с возможностью агрегации портов;
- поддержка подключения к FI схд по протоколам Eth и FC.
Разумеется, возможности управления сторонним оборудованием не включены в UCS Manager — для этого у Cisco есть другие инструменты — но и те, что приведены в списке выше, уже впечатляют. Вот несколько примеров, когда unified features сослужили нам хорошую службу:
Временная замена коммутаторам Cisco Nexus
Поставка новых коммутаторов Cisco Nexus существенно задержалась. Новая СХД от NetApp приехала раньше них и могла бы простаивать несколько месяцев: не хватало 10GbE-портов для полноценного отказоустойчивого подключения. Решение: подключаем СХД через порты FI, сконфигурированные в режим Appliance, конфигурируем port-channel с поддержкой LACP, вводим СХД в эксплуатацию на несколько месяцев раньше, чем приезжают коммутаторы. Оборудование работает, приносит доход, уровень CAPEX снижается.
Миграция на новую СХД
Нашему заказчику необходимо было с минимальными потерями мигрировать данные со старой СХД EMC на СХД NetApp. Свободных портов в его старой FC фабрике нет, подключить FI в общую фабрику нет возможности. Но на СХД заказчика нашлись свободные порты. Подключаем их к FI, поднимаем на FC vSAN. Запускаем миграцию виртуальных машин через Storage vMotion на NetApp, подключенный по NFS. Всё в порядке, все довольны. Миграция произведена успешно.
Cisco UCS и виртуализация
Нельзя не упомянуть о ряде преимуществ, которые предоставляет архитектура UCS, например, для виртуальной инфраструктуры под управлением VMware. Адаптеры VIC, о которых мы уже говорили при описании компонентов, на физическом уровне коммутируются через Midplane шасси с IO модулями через Backplane порты. На один VIC может приходить от 2 до 4 портов, которые автоматически конфигурируются в EtherChannel-порты на уровне UCS Manager. Это позволяет получить следующие преимущества сетевых соединений:
- на уровне физики мы получаем отказоустойчивое соединение между блейд-сервером и IO модулем на уровне FI. Как минимум, один Backplane порт подается из Fabric A, и один — из Fabric B.
- возможность балансировать трафик между FI на физическом уровне с помощью агрегации портов. Наличие EtherChannel на уровне Backplane портов позволяет избежать использования NIC Teaming на уровне гипервизора, что не всегда возможно, и в то же время балансировать трафик на физическом уровне между FI. За счет этого мы также можем использовать active-active конфигурацию сетевых адаптеров на уровне гипервизора.
- возможность создавать до 256 PCIe virtual devices (vNIC или vHBA) на базе одного физического VIC. Конфигурация каждого VIC определяется «на лету» через настройки Service Profile Template, поэтому мы можем добавлять виртуальные адаптеры и изменять ряд настроек без перезагрузки. Благодаря возможности добавления новых vNIC или vHBA можно увеличить сетевую пропускную способность без изменения состава оборудования.
- поддержка VM-FEX, с помощью которой можно организовать Pass Through Switching между VM и FI с использованием технологии VMWare Direct Path IO.
Как видите, комплекс Cisco UCS действительно хорошо зарекомендовал себя в целом ряде задач и кейсов. С одной стороны, это хорошо документированное и проверенное временем решение. С другой — оно не теряет своей актуальности и идеально закрывает в своей части все задачи облачного провайдера. Если у вас есть дополнения к статье или вы захотите поделиться собственным опытом, ждем вас в комментариях.