2. План
Сетевые подключения Сisco UCS
• Подключения внутри системы UCS
• Подключение к внешним сетям
• Подключение внешних устройств к UCS
Эффективное управление системой
• Основные «строительные блоки» системы управления UCS
• Пулы ресурсов
• Политики
• Шаблоны
• Масштабирование инфраструктуры
3. Вычислительная платформа Cisco UCS
•
•
•
•
В Cisco UCS архитектурно
интегрированы и неотделимы друг от
друга:
– Вычислительные мощности,
– Единая сетевая инфраструктура
– Управление системой как единым
целым
Нет понятия «настройка сервера» есть настройка фермы
Нет понятия «настройка портов
коммутаторов» – фабрика одна
(резервированная) и настраивается
автоматически
Отсутствуют в принципе вопросы и
сложности интеграции и
согласованной настройки серверной и
сетевой части
4. Унифицированная система Cisco UCS
Интегрированное управление на базе фабрики
• Масштабируемость без роста сложности
• Сервер – всего лишь ресурс, их количество не
имеет значения
• Конфигурации серверов «программируются» в
зависимости от требований
• Управление «один-ко-многим» (шаблоны,
политики, профили, пулы)
Mgmt
SAN A
LAN
SAN B
Унифицированная фабрика
Cisco SingleConnect –
подключение «напрямую» к
единой фабрике:
• Физических и виртуальных
машин
• Блейд и стоечных серверов
• По любым протоколам (LAN,
SAN, управление)
• Сервер получает нужное
число портов нужного типа в
нужной конфигурации
7. Детали организации фабрики UCS 2.0
UCS 6248
UCS 6248
Fabric
Interconnects
Fabric
Extenders
Expansion
Module
32x SFP+
32x SFP+
Настраиваемый
EtherChannel (только
между 62хх и 22хх)
До 160G на шасси
2208XP
2208XP
До 80G на серверный слот
Бэкплейн
Адаптер
Expansion
Module
1280 VIC
x16 Gen 2
x16 Gen 2
Блейд-сервер
IOH
CPU
Два 4x10 Gbps EtherChannel от VIC 1280 к модулю
ввода-вывода 2208
Не требуется конфигурация
Потоки балансируются между каналами
Конкретный поток – до 10Gb
Поддерживается Fabric Failover
CPU
UCS Blade Chassis
10. Режимы работы интерконнектов
Ethernet
Fibre Channel
Режим хоста/End Host Mode
— По умолчанию
— Выглядит для сети как сервер
— Выучивание MAC только на
серверных портах
— Нет STP, заблокированных портов
— Доступен FabricFailover
— Рекомендованный режим
Режим коммутатора/Switch Mode
— Rapid PVST+
— Отсутствуют настройки приоритетов и
таймеров STP
— Выучивание MAC на серверных и
сетевых портах
Режим хоста/NPV mode/End Host
Mode
—
—
—
—
—
По умолчанию
Выглядит для сети как сервер
NPV-режим
Требуется FC-коммутатор с NPIV
Рекомендованный режим
Режим коммутатора/Switch Mode
— Поддержка зонирования
средствами UCS Manager
— Непосредственное подключение
массивов
— Отсутствует InterOp Mode
Переключение режимов требует перезагрузки интерконнектов
Режимы Ethernet и FC настраиваются независимо друг от друга
11. Ethernet End-Host Mode
Распределение адаптеров по внешним портам
Динамическая привязка
vNIC/vHBA серверов равномерно
распределяются между всеми портами
vNIC могут быть перемещены между
портами для баланса соотношения
vNIC/Uplink или при добавлении/удалении
внешних портов
vHBA привязываются во время логина
Статическая привязка
PinGroup
Oracle
6100 A
Pinning
vEth 2
vEth 3
vEth 1
Switching
vNIC/vHBA серверов привязываются к
заданным портам
Используются Pin Group
— Дискретный или агрегированный
интерфейс помещается в Pin Group
— Pin Group присваивается vNIC/vHBA
VNIC 0
VNIC 0
VNIC 0
Server X
Server Y
Oracle
PinGroup
Oracle
12. Ethernet End-Host Mode
Коммутация unicast
LAN
• Локальная коммутация трафика между
серверами в одном и том же VLAN
• Трафик между внешними портами не
коммутируется
• Каждый vNIC привязан к одному интерфейсу FI
(дискретному или агрегированному)
• Трафик «сеть–>сервер» передается серверу
только в том случае, если он получен на
интерфейсе, к которому привязан vNIC
сервера (Reverse Path Forwarding check—
RPF check)
• Пакеты с SRC MAC, принадлежащим
серверу, полученные на внешнем порту,
игнорируются (Deja-Vu Check)
Server 2
Deja-Vu
RPF
vEth 1
VLAN 10
vEth 3
VNIC 0
VNIC 0
Server 2
Server 1
13. Ethernet End-Host Mode
Коммутация multicast и broadcast
LAN
В каждом интерконнекте выбирается
один порт (или port-channel), который
коммутирует широковещательный трафик
во всех VLAN
Широковещательный трафик на других
портах игнорируется
Все группы multicast привязаны к одному
порту
Multicast-трафик между серверами
коммутируется локально
Используются механизмы RPF и deja-vu
B
B
Broadcast
Listener
FI
vEth 1
vEth 3
B
VNIC 0
VNIC 0
Server 2
Server 1
14. Ethernet End-Host Mode
Агрегированные внешние интерфейсы
Режим транка, на котором
доступны все VLAN
Больше полосы
пропускания
vNIC остается
привязанным к прежнему
интерфейсу
FI-A
Pinning
vEth 3
Fabric A
vEth 1
Switching
VLAN 10
Прозрачно для vNIC
Рекомендуемый режим
VNIC 0
MAC A
vSwitch / N1K
ESX HOST 1
VM 1
VNIC 0
Server 2
VM 2
MAC B
MAC C
16. Варианты подключения устройств к UCS
Поддержку подключения устройств по FC/FCoE нужно проверять по матрице
совместимости производителей устройств
Ethernet
FC
FCoE
multi-hop
Сценарий 1
Сценарий 2
Сценарий 3
direct attach
Сценарий 4
Сценарий 5
Сценарий 6
Switch Mode
End Host Mode
17. Сценарий 1
EHM
Подключение коммутаторов по Ethernet
Рекомендуемая топология – vPC/VSS
В противном случае интерконнект подключается
агрегированными соединениями к каждому
коммутатору
Интерфейсы коммутатора в режиме транка
NX-OS
vPC/VSS
interface ethernet 1/20
switchport mode trunk
switchport trunk native vlan 1
switchport trunk allowed vlan 10-17,122
spanning-tree port type edge trunk
IOS
interface gigabitethernet 1/20
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
spanning-tree port type edge trunk
switchport trunk native vlan 1
switchport trunk allowed vlan 10-17,122
FI-A
FI-B
18. Сценарий 2
EHM
Подключение коммутаторов по FC
Раздельные фабрики коммутации
Интерконнекты рекомендуется подключать
агрегированными соединениями
Возможно только с коммутаторами Cisco
Коммутаторы FC в режиме NPIV
Обеспечение совместимости
Внешний порт интерконнекта должен быть
помещен в нужный VSAN
Должен совпадать с настройками VSAN на стороне
коммутатора Cisco
Не мешает подключиться к коммутатору другого
производителя
Порты интерконнекта могут быть в режиме
доступа или транка
FI-A
FI-B
20. Непосредственное подключение
устройств по Ethernet
В зависимости от массива возможна
балансировка vNIC по контроллерам
Рекомендация – настройка доступа vNIC к
LUN должна локализовать трафик внутри
одного интерконнекта
Если vNIC и активный контроллер LUN
разнесены на разные фабрики, трафик
пойдет по внешним коммутаторам
В некоторых сценариях аварий трафик
пойдет во внешним коммутаторам
Сценарий 4
EHM
LAN
NAS
Volume
A
C1
Volume
B
C2
Appliance
Port
FI-A
vEth 1
U
U
Uplink
Port
FI-B
vEth 2
vEth 1
vEth 2
Например, сбой IOM, активного контроллера,
интерфейсов массива
Правильно спланируйте емкость внешних
интерфейсов, чтобы не получить
бутылочное горло во время аварий
vNIC 0
Server 1
Accessing
Volume A
vNIC 1
Server 2
Accessing
Volume B
21. Непосредственное подключение
массивов по FC
Поддерживаются дисковые массивы NetApp и
EMC
Особое внимание на матрицу совместимости
производителя дискового массива
Информация о зонах может быть унаследована с
внешнего коммутатора или настроена внутри UCS
Manager
Включается/выключается на уровне VSAN
В VSAN можно использовать один из двух методов
Зонирование в UCSM требуют отключения от внешних
коммутаторов FC
Сценарий 5
Switch Mode
FC Storage
FI-A
FI-B
22. Непосредственное подключение
массивов по FCoE
Поддерживаются дисковые массивы NetApp и
EMC
Особое внимание на матрицу совместимости
производителя дискового массива
Информация о зонах может быть унаследована с
внешнего коммутатора или настроена внутри UCS
Manager
Включается/выключается на уровне VSAN
В VSAN можно использовать один из двух методов
FI-A
Зонирование в UCSM требуют отключения от внешних
коммутаторов FC
Сценарий 6
Switch Mode
FCoE Storage
FI-B
25. Базовые понятия концепции управления
Cisco UCS
Политика
Набор правил и параметров, описывающих поведение и характеристики системы.
Задается один раз, применяется к любому количеству серверов
Например: политика загрузки, версии прошивок, уровень RAID, QoS и т.д.
Пул ресурсов
Пулы идентификаторов (UUID, MAC, WWNN, WWPN)
Серверные пулы (заполняются вручную или автоматически)
Шаблон
Тиражируемый набор параметров и конфигураций, использует конкретные
политики и пулы ресурсов
Шаблон интерфейса ввода-вывода (vNIC, vHBA)
Шаблон сервисного профиля
Сервисный профиль
Конфигурация конкретного логического сервера с конкретными
идентификаторами; как правило, порождается из шаблона
Ассоциируется с физическим сервером, определяет его характеристики
При этом: мобильный, переносимый
27. Сервисный профиль - «мобильная»
«тиражируемая» конфигурация сервера
Это то, что в «традиционный» сервер «намертво» прошивают на заводе
UUID
MAC, WWN
Плюс то, что Вы задаете на этапе закупки (как правило навсегда)
Тип и количество адаптеров ввода-вывода
Плюс все то, что Вы обычно настраиваете на физическом сервере
Настройки BIOS, RAID, порядок загрузки;
Прошивки на всех компонентах;
Настройки адаптеров ввода-вывода – NIC и HBA;
Политики управления энергопотреблением;
Адрес контроллера удаленного управления;
и т.д. и т.п.
Плюс то, что Вы настраиваете в сетевой инфраструктуре уровня доступа
VLAN-ы, параметры QoS и т.д. для портов LAN
VSAN-ы для коммутаторов FC
28. Сервисный профиль – как его
конфигурировать
В сервисном профиле много параметров, при этом:
Вы практически никогда не задаете настройки сервиcного профиля напрямую и
вручную
Вы ссылаетесь на единожды заранее созданные:
Пулы идентификаторов;
Политики;
Шаблоны адаптеров ввода-вывода;
Если Ваши серверы – часть одной фермы
Вы конфигурируете их ОДИН раз, неважно, сколько у Вас серверов;
Для этого есть шаблоны и процедура тиражирования (один клик);
Вы вообще никак не настраиваете физические серверы – просто заносите их
(чаще всего автоматически в соответствии с критериями) в нужный пул, они
автоматически получат все необходимые настройки в процессе ассоциации;
Если необходимо изменить конфигурацию всех серверов в ферме – Вы делаете
это в одном месте и один раз.
30. Пулы идентификаторов
Позволяет «собрать» сервер с нужными характеристиками вводавывода
Упрощает создание сервисных профилей и особенно создание
тиражируемых ферм на основе шаблонов
Обеспечивает уникальность серверов в рамках системы или систем
WWN
Pool
UUID Pool
MAC Pool
31. Создание блока UUID Suffix
Кнопка Add, задаем начало и количество идентификаторов в пуле.
Можно добавить другие блоки в тот же пул при необходимости
32. Задаем пул MAC адресов
Имя, описание, начальный адрес и количество
Рекомендация: не изменять первые три октета, четвертый октет
использовать для идентификации UCS системы (например 12 – 2-ая
UCS система в первом ЦОД-е)
33. Пулы WWNN и WWPN адресов
WWNN – идентификатор узла FC
WWPN – идентификатор конкрентного адаптера
Процесс создания полностью аналогичен созданию пула MAC
адресов
WWN – это 64 бита в формате 2X:XX:YY:YY:YY:ZZ:ZZ:ZZ
например: 20:00:00:25:B5:12:A0:00
Рекомендации по использованию (пример)
— Не изменять первые пять октетов
— Шестой октет – номер ЦОДа и номер UCS системы в данном
ЦОДе (например 12 – 2-ая UCS система в первом ЦОД-е)
— Первая цифра седьмого октета – либо A (WWPN в фабрике A),
либо B (WWPN в фабрике B), либо F (WWNN)
— Остальные три цифры пусть выбирает система уникально для
конкретного сервера или адаптера
34. Management IP Pool
Внешние IP-адреса
— Только для управляющего доступа к серверам
— Один или несколько блоков на пул
Используется для прямого доступа к серверу извне
— Keyboard, video, mouse (KVM)
— Serial over LAN
— IPMI
Management IP Pool
Range: 172.16.1.1 – 172.16.1.253
Gateway: 172.16.1.254
Subnet: 255.255.255.0
Range: 172.16.2.1 – 172.16.1.13
Gateway: 172.16.2.14
Subnet: 255.255.255.240
36. Серверные пулы
Могут наполняться вручную или автоматически
Один и тот же сервер может быть в нескольких пулах одновременно
Если сервисный профиль ассоциирован с пулом, то:
— Физический сервер будет выделен автоматически
— Выделен будет только сервер, не ассоциированный с другим
профилем и не находящийся в процессе «деассоциации»
Pool Dev
Pool QA
40. Что такое политики
Cisco UCS управляется на основе
политик
— Обеспечивает консистентность
вычислительной среды (не надо
настраивать отдельные узлы)
Политика
— Задает как работают
компоненты UCS в
определенных обстоятельствах
— Разделяет функции внутри
системы
— Разные политики для сети,
серверов, СХД
Используются в сервисных
профилях
Service Profile
Boot Order
SAN
Local drive
CD-ROM
PXE
Ethernet Adapter
Queue depth
Failover timeout
Performance
...
Blade Collection
Интервалы для сбора
статистики
Applied
Policies
41. Типы политик
Что?
Configuration Policies
Operational Policies
Конфигурация серверов и компонентов
Функции управления, мониторинга,
управления доступом
Где?
Global Policies
Local Policies
Определена на всю системы
Определена на организацию
42. Конфигурационные политики
Политика
Описание
Autoconfiguration
Автоматическая конфигурация новых серверов
Boot
Правила загрузки сервера (SAN, LAN, локальный диск,
virtual media)
Chassis discovery
Что происходит при обнаружении шасси
Dynamic connection
Конфигурация динамических адаптеров для поддержки
VM-FEX
Ethernet adapter
Настройки NIC адаптера (queue depth, failover timeout,
performance, etc.)
Fibre Channel adapter
Настройки HBA адаптера (FLOGI and PLOGI timeouts,
error handling, и т.д.)
Firmware package
Требования к версиям прошивок на всех компонентах
IPMI access profile
Настройки доступа через IPMI
43. Конфигурационные политики (продолжение)
Политика
Описание
LAN Connectivity
Policy
Настройка всех подключений к LAN (число, тип и
характеристики адаптеров)
Local disk configuration
Настройка внутренних дисков и RAID-контроллера
QoS definitions
Настройки QoS для vNIC и vHBA (CoS, burst, rate)
SAN Connectivity
Policy
Настройка всех подключений к SAN (число, тип и
характеристики адаптеров)
Server discovery
Действия системы при обнаружении нового сервера
Server inheritance
Настройки использования «вшитых» аппаратных
характеристик
Server pool
Управление распределением серверов по пулам
Server pool qualification
Правила квалификации серверов (память, ввод-вывод,
число CPU и т.д.)
44. Операционные политики
Политика
Описание
Adapter collection
Интервалы сбора статистики с адаптера
Blade collection
Интервалы сбора статистики с сервера
Call Home
Настройки Call Home для автоматического оповещения по email
Chassis collection
Интервалы сбора статистики с шасси
IPMI profile
Управление возможностью доступа к серверу по IPMI
Fault collection
Реакции на ошибки и проблемы
Maintenance Policy
Определяет правила и расписание применения
изменений, требующих перезагрузки
Port collection
Интервалы сбора статистики с портов устройств
Scrub
Управляет удалением «состояния» с сервера (HDD, BIOS)
Threshold
Пороговые значения датчиков для Ethernet, Fibre Channel,
adapters, blades, chassis, PSU, FEX, FAN, и т.д.
46. Создание сервисного шаблона
Используется для управления «один-ко-многим»
Требует наличия серверных пулов
Требует наличия пулов идентификаторов (UUID, MAC, WWNN, WWPN)
48. Типы шаблонов
Initial template
— Изменения в шаблон НЕ распространяются на порожденные из
него сервисные профили
Updating template
— Изменения в шаблон распространяются на порожденные из него
сервисные профили
49. Выбор пула UUID
Все сервисные профили, порожденные из этого шаблона, будут
использовать UUID из этого пула
50. Выбор пула WWNN
Все сервисные профили, порожденные из этого шаблона, будут
использовать WWNN из этого пула
51. Создание vHBA для Fabric A
Все сервисные профили, порожденные из этого шаблона, будут
использовать WWPN из заданного пула и все остальные настройки
адаптера
52. Создание vHBA для Fabric В
Все сервисные профили, порожденные из этого шаблона, будут
использовать WWPN из заданного пула и все остальные настройки
адаптера
53. Шаблоны vHBA
Все настройки vHBA могут быть сохранены в шаблоне vHBA.
Шаблоны создаются либо из закладки «SAN», либо прямо из Wizardа создания сервисного шаблона
54. Создание vNIC для Fabric A
Все сервисные профили, порожденные из этого шаблона, будут
использовать MAC из заданного пула и все остальные настройки
адаптера
55. Создание vNIC для Fabric B
Все сервисные профили, порожденные из этого шаблона, будут
использовать MAC из заданного пула и все остальные настройки
адаптера
56. Шаблоны vNIC
Все настройки vNIC могут
быть сохранены в
шаблоне vNIC.
Шаблоны создаются либо
из закладки «LAN», либо
прямо из Wizard-а
создания сервисного
шаблона
57. Политика загрузки: Boot Order и Boot Target
Ссылаемся на политику загрузки, созданную заранее, единожды для
всех серверов и всех типов серверов.
58. Ассоциация шаблона с серверным пулом
Сервисные шаблоны могут привязываться только к пулам серверов
59. Дополнительные политики
Выбор дополнительных политик:
— настройки BIOS, версий прошивок, threshold, энергопотребления и пр.
— Можно сослаться на заранее созданные, можно создать прямо из
Wizard-а
62. Создание сервисных профилей из шаблона
Создание профилей из шаблона - одновременное развертывание
большого количества серверов (неважно какого)
63. Выбор префикса имени и количества
Задаем префикс имени и требуемое количество серверов в ферме
В примере ниже будут созданы профили с именами от Oracle_RAC1
до Oracle_RAC20.
64. Управление фермой как одним объектом
Если был создан updating шаблон, все изменения в него
распространяются на все порожденные серверы
Это отлично помогает в обслуживании системы
Но ряд изменений требуют перезагрузки
Для управления тем, как это происходит, используется Maintenance
Policy, привязанная к шаблону
Три варианта:
— Применять немедленно на все (вряд ли Вы будете использовать
это в продуктиве)
— Требовать ручного подтверждения от администратора на
перезагрузку серверов (замигает кнопка «Pending Activities»)
— Применять изменения по расписанию в заданные временные
промежутки, перезагружая например не более 1 или 2 (или
сколько угодно) серверов одновременно
65. Масштабирование фермы
Ферму серверов можно масштабировать с минимальными
трудозатратами и НУЛЕВЫМИ рисками неверной конфигурации
Способы:
— «Консервативный»: вставить новые серверы, занести их в пул,
создать N новых экземпляров сервисных профилей из шаблона
фермы (UCSM отследит нумерацию cуществующих профилей и
после Oracle_RAC20 создаст Oracle_RAC21 и далее)
— «Опережающий»: создать из шаблона нужное количество
профилей БЕЗ наличия дополнительных физических серверов в
системе – когда они появятся и будут добавлены в
соответствующий пул, профили привяжутся к ним автоматически
— «Автомагический»: создать политику “Autoconfig”, которая после
обнаружения и квалификации новых серверов автоматически
создаст новые профили и привяжет их к новым серверам
66. «Отвязывание» сервисного профиля от шаблона
Сервисные профили порожденные из updating шаблона нельзя
изменять – их состояние определяется «родителем»
Если есть необходимость независимо изменять профиль, его можно
отвязать от шаблона
67. Привязывание сервисного профиля к шаблону
Независимые сервисные профили могут быть в любое время
привязаны к заданному шаблону, т.е. могут стать частью фермы с
характеристиками, задаваемыми шаблоном
68. Клонирование и тиражирование независимых
сервисных профилей
Из отдельного профиля всегда можно создать сколько угодно новых
профилей.
Отдельный профиль всегда можно превратить в шаблон
