Принято считать, что серверные решения Cisco UCS — это очень сложно. Мы решили наглядно показать всю простоту настройки таких решений. Под катом видеообзор, а также стенограмма со скриншотами (Осторожно, трафик! Многие скриншоты в полный размер, если их ужимать — ничего не разобрать).

Дисклеймер: конечно, весь процесс настройки блейда Cisco занимает около 2 часов, мы отметили ключевые и главные моменты. А представляете все это в прямом эфире записать? – это никому не будет интересно.

Сам видеообзор



Стенограмма (с небольшой редактурой)

Сегодня мы рассмотрим базовую настройку блейд-системы Cisco. Уже неcколько лет эти системы будоражат рынок. Для начала посмотрим как выглядят коробки и базовый комплект.



Небольшой ликбез по блейд-системе от Cisco.

Во-первых, это 2 универсальных коммутатора, которые умеют передавать трафик и Ethernet и FibreChannel, они построены на основе Cisco Nexus.

Второй компонент – это само блейд-шасси и сервера, которые устанавливаются в это шасси. Особенность системы в том, что нам понадобятся максимум два универсальных коммутатора Fabric Interconnect (далее FI), почти для любого количества серверов, которые у нас будут в дата-центре.



Например, нам нужно 1, 2, 10, 20 шасси, все равно нам будет достаточно всего два вышеуказанных коммутаторов. Это – огромная экономия для больших предприятий.

В чем особенность? Если вдруг нам потребуется два порта Ethernet на каждый сервер, 4, 10, 100 портов Ethernet, которые отвечают за каждый сервер, или же FibreChannel не важно какое количество, нам все равно нужно будет всего два таких коммутатора FI. Сделано это благодаря технологии Cisco, которая позволяет видеть из консоли управления любое количество интерфейсов, которые мы создадим на каждом сервере.

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

Теперь программная настойка

Подключаем уже знакомый многим консольный кабель.


Мы подключим его в каждый коммутатор для настройки.

Дальнейшая настройка — через веб-интерфейс.

Стоит обратить внимание на заднюю сторону блейд-шасси. Вы можете наблюдать здесь специальный модуль расширения FI– называется Fabric Extender.



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



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

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



Пробуем ввести простой пароль «пароль», и меня просят ввести более сложный вариант.

Далее идет опрос от системы: будет ли второй коммутатор FI? Далее назначаем кто из них первый, а кто второй. Затем – имя системы. Даем IP-адреса, то, ради чего мы подключились к ним консолью. Адрес первого коммутатора: 192.168.0.11, gateway: 192.168.0.1

Вот теперь интересная вещь, виртуальный адрес 192.168.0.1, который будет переезжать между коммутаторами, в случае если кто-то из них выйдет из строя. ДНС пока настраивать не будем.

Далее наc спрашивают: «все ли нам нравится в конфигурации?», мы говорим – да, и конфигурация применена. Настройка из консоли завершена.

Теперь настраиваем второй фабрик FI.

Настраивать будем из консоли. Найден еще один FI, вопрос – скачать с него конфигурацию? Скачиваем. Затем задаем IP-адрес второго FI.

Выбираем применение конфигурации. Настройка из консоли завершена. Вся дальнейшая настройка будет производиться графическим интерфейсом. Единственное, для чего нужна консоль – для настройки IP-адресов.



Вводим IP-адрес, который мы настроили из консоли, в браузер. Запускается консоль Java.





Вводим логин и пароль, который мы задавали из консоли. И вот мы видим графический интерфейс управления всей нашей системой. Сейчас мы видим два FI. Они объединены в кластер. Серверов мы пока не видим.



Давайте разберемся с интерфейсом управления.

Мы можем посмотреть, какие порты есть на каких интерфейсах FI – какие из них сейчас FC, какие Ethernet.



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



А теперь меню управления прошивками. Отсюда мы можем централизовано обновить или понизить прошивки на те или иные компоненты.
Здесь прошивка скачивается и тут же применяется.



Загрузить новую прошивку можно с локальной системы или по FTP, SFTP.



Теперь меню политик. Первая политика – 10-гигабитные линки. Соединять ли их в Port Channel или нет. Устанавливаем соединять. Отсюда можно указать избыточность блоков питания и некоторые другие параметры.



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



Вот первые четыре порта, они подключены к блейд-шасси.



Открываем порт и назначаем его серверным.



Таким образом активируем все порты.

Так как в политиках мы назначили, что все порты, которые идут к блейд-шасси, будут собираться по Port Channel, у нас получается два 40-гигабитных линка. Один будет идти с одного свитча, другой со второго.

Теперь настроим второй FI. Порты, идущие к шасси, могут находиться где угодно – в начале, в середине или в конце, как мы их назначим, так и будет.

Посмотрим, что обнаружилось через активированные порты.

Есть два сервера. Можем посмотреть, какие у них есть серийные номера, на адаптеры, которые в них вставлены, на версию CIMC (аналог iLo от Cisco). Также можно посмотреть информацию по процессорам в серверах.



Можно посмотреть память, RAID-контроллеры, локально установленные диски.





Теперь давайте приступим к настройке. Первое, что мы сделаем – создадим MAC-адреса для наших серверов. Для чего это нужно? Мы можем перепрошивать абсолютно все аппаратные настройки серверов. Создаем первый пул MAC-адресов, и даем MAC-систему, которая у нас уже существовала и на которой была настроена безопасность. Ровно один MAC-адрес.





Если у вас уже была какая-то настроенная система, мы можем создать новый сервер с такими MAC-адресами, и не нужно будет перенастраивать сеть.

Создадим еще один пул, где можно будет создать много MAC-адресов – скажем, 256.

Пул MAC-адресов, которые мы будем назначать серверам, готов.



Далее создадим IP-адреса, которые будут использоваться для управления серверами. У нас уже есть предготовый список внешнего управления.

Давайте добавим сюда блок IP-адресов, которые будут управляющими для серверов. В блоке их будет десять. Назначим Default Gateway.



Чтобы показать, что у нас могут быть еще адреса помимо первого пула, создадим еще один пул.



Теперь у нас есть список MAC-адресов и IP-адресов, которые мы будем давать серверам. Следующее, что может потребоваться, это настройка стореджевых адаптеров, то есть Host Bus адаптеров. Давайте создадим WWNN-ны. У нас уже есть готовый список, давайте создадим другой. Придумаем случайное значение, например 256.



Теперь список портнеймов.





У нас есть все базовые настройки. Чего нам еще не хватает? Не хватает серийника сервера или его UID. Назначаются они в разделе серверов.



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



Теперь создаем сам сервер. Выбираем режим эксперта. Даем серверу, или профайлу, который будем применять к серверу, название. Профайл – это то, как будет выглядеть сам сервер. Выбираем из списка UID, который уже был создан. Нажимаем Next.



Далее есть возможность выбрать динамические сетевые адаптеры. Это адаптеры, которые используются в VMware и которые можно динамически добавлять или убирать. И создаем теперь не динамические, а статические IP-адреса. Также здесь есть настройка MTU для этого адаптера и некоторый тюнинг под определенную операционную систему. Предположим, что у нас будет VMware.





Создадим в систем еще парочку адаптеров – пусть будет четыре.



Теперь настройка системы хранения. По умолчанию у нас нет здесь никаких дисков, поэтому создадим специальную политику, которая будет отображать, чтобы сервер не использовал вообще никаких дисков. Мы можем выбрать, в какой RAID собирать диски на сервере, или указать что их вообще нет. SD-карточек тоже нет, поэтому все ставим Disable. И выбираем применение только что созданной политики к этому профайлу.







Теперь давайте создадим Host Bus адаптеры в режиме экспертов. WWNN берем из созданного нами списка. Даем адаптеру название и портнейм из списка портнеймов. Будет подключен к FI А. Мы можем подключить его в определенный vSAN, и назначить оптимизацию под определенную политику.



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

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



Теперь – настройка загрузки сервера, откуда будет грузиться ОС. ПО умолчанию есть несколько загрузочных политик, но давайте создадим свою собственную. Для этого нужно выбрать Create a Specific Boot Policy. Сперва установим по умолчанию загрузку с подключенного через CIMC CD/DVD, добавим имя, загрузку с нулевого адаптера (fc0). Если мы нажмем Add SAN Boot Target, то мы можем указать дополнительные настройки загрузки. У нас теперь есть два адаптера, в дальнейшем можно будет добавить, с какого конкретно таргета загружаться.





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



Сразу перейдем к последнему шагу – настройке BIOS вновь созданного сервера. Давайте создадим какой-нибудь новый профайл, чтобы увидеть, что мы можем назначать и видеть в настройках BIOS созданного профайла и сервера. Сперва стандартные параметры, такие как Quiet Boot, что делать при Post Error, что делать при потере питания, свойства процессора, включать/не включать Hyper Threading, технологии виртуализации и т. д. Затем настройки памяти, последовательного порта, USB, PCI, QPI, встроенные адаптеры (что с ними делать и как их воспринимать), настройки загрузки.















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

Причем профайлы можно применять как к одному серверу, так и сразу же к нескольким, и соответственно сразу же размножить на все сервера.

Здесь мы выбираем, какой использовать IP-адрес или пул IP-адресов для внешнего администрирования



Собственно, профайл создан.



Теперь можем применить его. Через несколько минут наш сервер полностью соответствует тому профайлу, который мы создали.





С помощью KVM-консоли можно посмотреть, что твориться на самом сервере.





Все вопросы о решениях Cisco@muk.ua

Стоит отметить, что решения Cisco через группу компаний доступны теперь не только в Украине, но и в Молдове – недавно на территории этой страны был подписан дистрибуторский контракт.

МУК-сервис — клиентский и корпоративный ИТ-ремонт, сервисные контракты

Комментарии (4)


  1. DLag
    19.11.2015 19:23
    +1

    Принято считать, что серверные решения Cisco UCS — это очень сложно.

    И не зря. Очень сильно перемудрили.


  1. nikerossxp
    20.11.2015 01:45

    Вообще, хорошая тенденция — «или делай удобный интерфейс, или тебя выпрут с рынка».


  1. vaskes
    24.11.2015 06:52
    -1

    Я досмотрел ролик до конца. Забаньте автора, пожалуйста. Технология черезвычайно «виртуализирована». Я бы даже сказал излишне. Автор потратил 26 минут моего и вашего времени чтобы пробится в биос блейда. По сути материала (коммутаторы) не сказано ничего.


    1. merlin-vrn
      24.11.2015 08:50

      Любую проблему можно устранить введением дополнительного уровня абстракции, кроме одной — слишком много уровней абстракции.

      Cisco похоже забыли про вторую часть этого афоризма :)