Настройка Cisco Nexus 1000v

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

Если интересно — читаем дальше…

Наиболее полное сравнение функционала различных типов виртуальных свитчей углядел тут (спасибо Мише Михееву).

Что такое Cisco Nexus 1000v? Это удобный взгляд на виртуальные сети как с точки зрения сетевого администратора, так и с точки зрения администратора виртуальных систем. Cisco даже считает, что Nexus 1000v помогает разворачивать  и поддерживать больше приложений за меньшее время (по сравнению с альтернативами). Как я думаю, основной причиной для покупки все же является более широкий функционал. На Nexus’е нет STP, Port Channel есть только для физических портов хостов.

Если не ошибаюсь, аналогов VMware Distributed Switch у других вендоров виртуализации пока нет (разве что Citrix про что-то такое говорил). Аналогов Nexus 1000v нет вообще (с точки зрения виртуальных свитчей).

Лицензируется Nexus 1000v на сокет (процессор), причем может использоваться только вместе с vSphere Enterprise Plus (есть даже специальная лицензия на процессор, совмещающая эти две лицензии).

Конструктивно Nexus 1000v представляет собой модульный свитч. Первый и второй слот зарезервированы под VSM — супервизоры, или модули управления свитчем. VSM доступны в качестве Virtual Appliance и скачиваются с сайта Cisco.com. В VSM три сетевых интерфейса: Control, Management и Packet. По первому и третьему идет обмен с VEM. Control используется для мониторинга статуса VEM, а также управления ими. Management — для удаленного управления супервизором. Packet — интерфейс по которому работают протоколы CDP, IGMP и LACP. Cisco рекомендует разделять по VLAN’ам Control и Packet — интерфейсы. Использование общего VLAN’а для всех интерфейсов Nexus’а, в принципе, допустимо. В этом же VLAN’е и общем адресном пространстве должны находиться интерфейсы Service Console (ESX) или VMKernel (ESXi) (доступ к vCenter можно осуществлять через роутер). Также Cisco рекомендует размещать два VSM в режиме HA, размещая их на разных хостах. При недоступности VSM, VEM будут как прежде передавать трафик. VSM можно запускать даже на хостах с версией ESX 3,5 U2.

С третьего по шестьдесят шестой слоты отведены под VEM, сетевые модули c хостов ESX4/ESXi4. В ESX VEM уже встроен, на ESXi его необходимо доставить (хотя при настроенном Update Manager он установился автоматически при добавлении хоста в распределенный свитч Nexus).

Если раньше любой логин на Cisco.com мог скачать для оценки виртуальный апплайнс Nexus, то сейчас все стало сложнее.

Перед развертыванием свитча крайне рекомендую ознакомиться с гайдами (как минимум, Getting Started).

Итак, у нас есть VSM. В него включена оценочная лицензия на 16 процессоров сроком на 60 дней.

Перед его развертыванием определяемся со следующими условиями:

  1. У нас должен быть установлен vCenter, в который добавлены хосты;
  2. Должен быть развернут Update Manager, ему предоставлен доступ к интернет;
  3. Предприняты необходимые орг.шаги и подготовлен служебный VLAN (или несколько, по которым будут общаются VSM и VEM) и IP-адреса;
  4. Хосты не находятся в кластере и не добавлены в распределенный свитч. На хостах свободен один физический  адаптер.

Если все пункты выполнены, можно приступать к развертыванию Nexus’а.

Настраиваем VSM

  • Подключаемся vClient’ом к vCenter;
  • Настраиваем виртуальную сеть (порт-группу), в которой будут находиться сетевые адаптеры VSM. Допустим, это VLAN180
  • Разворачиваем из OVA/OVF-файла апплайнс сVSM. Соглашаемся с установкой через gui, указываем параметры первого VSM-модуля.

nexus1

  • Заходим на него через http и запускаем инсталлятор (Launch Application);
  • В инсталляторе указываем параметры VSM (адрес, маска, шлюз, domain id, vlan’ы. vSwitch native Vlan — такой же, как VLAN у Nexus’а (180).
  • Хост (на котором VSM) в NEXUS не добавляем и сети не мигрируем.
  • Подключаемся к Nexus по ssh/telnet и создаем профили портов. На этом этапе нам понадобятся два профиля: для физических адаптеров (аплинков) и для виртуальных интерфейсов VSM/интерфейсов SC&VMK. Также можно создать профили для остальных ВМ.
port-profile type ethernet system-uplink # type ethernet означает, что профайл применяется к физическим сетевым адаптерам
vmware port-group # профиль будет доступен в vCenter
switchport mode trunk
switchport trunk allowed vlan all
system vlan 180 # список VLAN, по которым происходит «общение» VSM и VEM
no shutdown
state enabled #включение профиля. После этой команды он появится в vCenter

port-profile VLAN180 #у профилей два типа — Ethernet (физика) и vEthernet (виртуальные адаптеры). type vethernet писать не обязательно
vmware port-group
switchport mode access
switchport access vlan 180
system vlan 180 # этот параметр не должен противоречить настройке switchport mode. Если используется режим access, то здесь может быть только такой же номер VLAN
no shutdown
state enabled
Если есть необходимость прокинуть в виртуальную машину несколько VLAN, то создаем vEthernet-профиль с режимом порта «trunk», выдаем ВМ сетевой адаптер E1000 и устанавливаем Intel ProSet (для Windows-систем).
  • Добавляем хосты в распределенный свитч и выполняем в консоли VSM команду show module

vsm1# sh modu
Mod  Ports  Module-Type                      Model              Status
—  ——  ——————————— —————— ————
1    0      Virtual Supervisor Module        Nexus1000V         active *
3    248    Virtual Ethernet Module          NA                 ok
4    248    Virtual Ethernet Module          NA                 ok

Mod  Sw               Hw
—  —————  ——
1    4.0(4)SV1(3b)    0.0
3    4.0(4)SV1(3b)    0.4
4    4.0(4)SV1(3b)    0.4

Mod  MAC-Address(es)                         Serial-Num
—  —————————————  ———-
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
3    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA
4    02-00-0c-00-05-00 to 02-00-0c-00-05-80  NA

Mod  Server-IP        Server-UUID                           Server-Name
—  —————  ————————————  ———————
1    10.10.1.26       NA                                    NA
3    10.10.1.23       422f14d5-9d19-efdf-6ad7-fc9402999d5f  testesx1.domain.local
4    10.10.1.25       422f905f-4c70-7a77-f9de-d27f73863805  testesx3.domain.local

  • Переносим management-интерфейс Nexus в порт-группу VLAN180 и проверяем пингом доступность адреса.
  • Если все ок, мигрируем (если они в 180 VLAN’е) VMK/SC-интерфейсы хостов со стандартного свитча в Nexus. Если нет, сначала тестируем на обычной ВМ доступность сети из VLAN’а управления (то есть, создаем профиль и подключаем сетевой адаптер ВМ в этот профиль).
  • Переносим остальные интерфейсы Nexus в порт-группу VLAN180.
  • Мигрируем остальные ВМ на Nexus, удаляем стандартные свитчи и подключаем оставшиеся физические адаптеры в Nexus.
  • sh module должна показать тот же вывод, что и ранее.
  • В настройках первого VSM меняем его роль с standalone до primary

vsm1# conf t
vsm1(config)# system redundancy role primary

vsm1(config)# do copy running-config startup-config

  • Разворачиваем из шаблона второй vsm, указав ручное конфигурирование (а не через GUI), никаких настроек (адрес, маска подсети и пр.) не вводим.
  • Подключаемся к консоли второго VSM. Указываем пароль администратора, роль — secondary и domain id. Перезагружаем второй VSM.

nexus2

  • После его загрузки проверяем уровень отказоустойчивости с помощью show system redundancy status (с основного VSM)
vsm1# sh syst redu sta
Redundancy role
—————
administrative:   primary
operational:   primaryRedundancy mode
—————
administrative:   HA
operational:   HAThis supervisor (sup-1)
————————
Redundancy state:   Active
Supervisor state:   Active
Internal state:   Active with HA standby

Other supervisor (sup-2)
————————
Redundancy state:   Standby

Supervisor state:   HA standby
Internal state:   HA standby

и show module
vsm1# sh mod
Mod  Ports  Module-Type                      Model              Status
—  ——  ——————————— —————— ————
1    0      Virtual Supervisor Module        Nexus1000V         active *
2    0      Virtual Supervisor Module        Nexus1000V         ha-standby
4    248    Virtual Ethernet Module          NA                 ok
5    248    Virtual Ethernet Module          NA                 okMod  Sw               Hw
—  —————  ——
1    4.0(4)SV1(3b)    0.0
2    4.0(4)SV1(3b)    0.0
4    4.0(4)SV1(3b)    0.4
5    4.0(4)SV1(3b)    0.4Mod  MAC-Address(es)                         Serial-Num
—  —————————————  ———-
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
2    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA
5    02-00-0c-00-05-00 to 02-00-0c-00-05-80  NA

Mod  Server-IP        Server-UUID                           Server-Name
—  —————  ————————————  ———————
1    10.10.1.26       NA                                    NA
2    10.10.1.26       NA                                    NA
3    10.10.1.23       422f14d5-9d19-efdf-6ad7-fc9402999d5f  testesx1.domain.local
4    10.10.1.25       422f905f-4c70-7a77-f9de-d27f73863805  testesx3.domain.local

* this terminal session

The end!

Запись опубликована в рубрике 4.1, Cisco, Hardware, VMware, vSphere. Добавьте в закладки постоянную ссылку.

2 комментария: Настройка Cisco Nexus 1000v

  1. EGarbuziv говорит:

    > Если не ошибаюсь, аналогов VMware Distributed Switch у других вендоров виртуализации пока нет
    На самом деле у opensource Xen похожая штука уже есть http://openvswitch.org/, т.ч. Citrix в скором времени тоже должен подтянуться.

  2. Андрей Вахитов говорит:

    Супер. Спасибо за ссылку!
    Функционал Open vSwitch’а с VMware vDS не сравнивали?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *