Так совпало, что я сел поразбираться с этим виртуальным коммутатором и понял, что русскоязычных статей по нему почти нет. Все что есть – маркетинг или обзор технологий. Между тем, его настройка – дело совсем непростое.
Если интересно – читаем дальше…
Наиболее полное сравнение функционала различных типов виртуальных свитчей углядел тут (спасибо Мише Михееву).
Что такое 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 дней.
Перед его развертыванием определяемся со следующими условиями:
- У нас должен быть установлен vCenter, в который добавлены хосты;
- Должен быть развернут Update Manager, ему предоставлен доступ к интернет;
- Предприняты необходимые орг.шаги и подготовлен служебный VLAN (или несколько, по которым будут общаются VSM и VEM) и IP-адреса;
- Хосты не находятся в кластере и не добавлены в распределенный свитч. На хостах свободен один физический адаптер.
Если все пункты выполнены, можно приступать к развертыванию Nexus’а.
Настраиваем VSM
- Подключаемся vClient’ом к vCenter;
- Настраиваем виртуальную сеть (порт-группу), в которой будут находиться сетевые адаптеры VSM. Допустим, это VLAN180
- Разворачиваем из OVA/OVF-файла апплайнс сVSM. Соглашаемся с установкой через gui, указываем параметры первого VSM-модуля.
- Заходим на него через http и запускаем инсталлятор (Launch Application);
- В инсталляторе указываем параметры VSM (адрес, маска, шлюз, domain id, vlan’ы. vSwitch native Vlan – такой же, как VLAN у Nexus’а (180).
- Хост (на котором VSM) в NEXUS не добавляем и сети не мигрируем.
- Подключаемся к Nexus по ssh/telnet и создаем профили портов. На этом этапе нам понадобятся два профиля: для физических адаптеров (аплинков) и для виртуальных интерфейсов VSM/интерфейсов SC&VMK. Также можно создать профили для остальных ВМ.
- Добавляем хосты в распределенный свитч и выполняем в консоли 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.
- После его загрузки проверяем уровень отказоустойчивости с помощью show system redundancy status (с основного VSM)
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
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
The end!
> Если не ошибаюсь, аналогов VMware Distributed Switch у других вендоров виртуализации пока нет
На самом деле у opensource Xen похожая штука уже есть http://openvswitch.org/, т.ч. Citrix в скором времени тоже должен подтянуться.
Супер. Спасибо за ссылку!
Функционал Open vSwitch’а с VMware vDS не сравнивали?