Опубликовано Minorioo 7 Май , 2014

В сегодняшнем нашем с Вами разговоре речь пойдет о виртуальном коммутаторе Cisco, который служит заменой для VMware dSwitch – Nexus1Kv.

N1K представляет собой виртуальную машину, которая может работать под всеми основными сегодняшними супервизорами: ESX/ESXi, Hyper-V, Xen.

Компоненты коммутатора

Коммутатор состоит из двух основных компонентов:

— Virtual Supervisor Module (VSM)

— Virtual Ethernet Module (VEM)

VSM предоставляет функции control и management plane, а VEM – data plane.

Чтобы полностью понять, как работает свитч, первоначально необходимо ознакомиться с архитектурой VmWare.

Базовая сетевая инфраструктура VMware

Виртуальная сеть VmWare состоит из виртуальных сетевых интерфейсов (vNIC), физических сетевых плат (pNIC или просто NIC) и виртуальных коммутаторов для соединения их друг с другом.

У каждой виртуалки есть одна или более vNIC (именно их Вы видите в сетевых подключениях). Эти vNIC подключаются к виртуальному коммутатору (vSwitch – например, Cisco Nexus 1000v). Подключение реализовано через механизм, который известен как Port Group. Каждая портовая группа определяет vlan или набор vlan’ов, который будет доступен для vNIC. Также в портовой группе можно определить дополнительные параметры, такие как rate limiting, port-security, QoS. Портовая группа привязывается к виртуальной машине на этапе ее создания (чаще всего).

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

Архитектура Nexus 1000v

Virtual Supervisor Module

Ка уже упоминалось, VSM предоставляет функции management plane. Относитесь к VSM также, как и к обычному супервизору в физическом коммутаторе (например, 2T у Catalyst6500). Единственным отличием является тот факт, что к N7K/Cat6K функции супервизора зашиты в железе, здесь же VSM является или отдельной виртуальной машиной или виртуальным блейдом на аппаратном платформе Cisco Nexus 1010. Под ESX VSM устанавливается как и обычная виртуалка, чаще всего с использованием OVF (Open Virtualization Format) или ISO-файла. После установки N1K, Вы увидите знакомый интерфейс NX-OS J

Для нормального функционирования, VSM требует три vNIC, каждая из которых будет выполнять определенную функцию.

Прим. Для функционирования vNIC требуется Intel E1000 драйвер

Management интерфейс

Management интерфейс виден на коммутаторе как порт mgmt0. Используется для установления связи между VSM и VMware vCenter. Интерфейс нумеруется как «Network Adapter 2» в свойствах виртуальной машины.

Control интерфейс

Control интерфейс используется для коммуникации с VEM-модулями в L2-режиме работы коммутатора (что это такое и в чем отличие от L3 рассмотрим чуть позже). Также интерфейс используется для VSM High-Availability. Интерфейс нумеруется как «Network Adapter 1».

Packet Interface

Packet интерфейс используется для переноса пакетов, которые должны быть обработаны VSM-модулем. В основном это два типа пакетов: CDP и IGMP.

Domain ID

Классический физический коммутатор пропускает control plane информацию с ASIC-порта на CPU через внутреннюю шину. Эта шина изолирована от всего внешнего мира по-умолчанию. В случае же виртуальной инфраструктуры, пакеты control plane от VEM к VSM передаются по физической среде передачи данных. Теоретически может случиться так, что из-за ошибки администратора VEM получает control фрейм от VSM, который относится к совершенно другому 1000v коммутатору. Если VEM ответит на такой пакет, то он не сможет корректно его обработать. Чтобы не допустить такого сценария развития событий, используется параметр Domain ID. Каждая команда, которая посылается VSM’ом тегируется этим ID. Если VSM и VEM разделяют один Domain ID, то VEM примет данную команду. В противном случае отбросит.

Virtual Ethernet Module

VEM представляет собой аналог линейной платы в физическом коммутаторе. Однако одновременно с этим каждый VEM является отдельным коммутатором с точки зрения коммутации трафика.

VEM обладает очень глубокой интеграцией с ESXi: он устанавливается как kernel компонент. Ресурсы, которые выделяются под VEM не являются управляемыми – в зависимости от конфигурации RAM выделяется динамически. При типичном внедрении диапазон использования RAM находится в пределах от 10 до 50 МБ (абсолютный верхний предел 150 МБ). Максимальное количество VEM’ов для отказоустойчивой пары VSM’ов составляет 64 штуки.

 

Интерфейсы коммутатора

Nexus 1000v поддерживает несколько типов интерфейсов: virtual Ethernet (vEth), Ethernet (Eth) и Port-Channel (Po). Если с классическими Eth и Po все должно быть понятно, то на vEth остановимся подробнее.

vEth представляет собой порт, который подключается к vNIC виртуальной машины. Хотелось бы немного остановиться на схеме именования виртуальных интерфейсов. Мы с Вами привыкли, что интерфейсы имеют вид FaX/Y, где X-номер слота коммутатора, а Y – номер порта. vEth интерфейсы помечаются как vEthZ, где Z – порядковый номер, который не зависит от того, где физически находится VEM. Сделано это для прозрачной интеграции с VMware VMotion.

Каждый vEth статически ассоциируется с определенным vNIC и существует ровно столько, сколько существует соответствующая виртуальная машина.

Передача фреймов и защита от петель

Передача фреймов осуществляется также, как и на физических коммутаторах – анализируется поле Destination MAC. Отличием является тот факт, что таблица MAC-адресов на каждом VEM модуле строится независимо и не синхронизируется с другими модулями.

Также Nexus 1000v не поддерживает Spanning-Tree. Для предотвращения петель используется несколько иной алгоритм. А именно: проверяется каждый входящий фрейм на физическом Eth интерфейсе. Если Source MAC является внутренним для VEM, то фрейм дропается. Если Destination MAC является внешним, то фрейм дропается.

Взаимодействие VEM и VSM

Передача данных между VEM и VSM может происходить либо по L2, либо по L3. Рекомендуемый режим – L3.

В случае L3 режима работы, взаимодействие между VEM и VSM может проходить либо через control интерфейс, либо через management. Для настройки необходимо ввести команду (config-svs-domain)#svs mode L3 interface [mgmt0|control0]

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

Почему рекомендуется внедрять именно L3 режим? L3 гораздо проще траблшутить в случае каких-либо проблем (точно также, как нам проще траблшутить IGP, чем какие-либо L2-проблемы) благодаря стандартным приложениями типа ping, traceroute и пр. Также, в случае L2 все VEMы и VSM должны находиться в пределах одной vlan’ы, что не всегда удобно.

Прим. Но в любом случае, независимо от метода коммуникации между модулями коммутатора, настраивается Nexus 1000v как и обычное NX-OS устройство.

Для мониторинга VEMов используются hearbeat’ы с частотой в 1сек и holdtime 6сек. Все коммуникации между ними шифруются с помощью AES-128.

Конфигурация

Здесь я не буду приводить какие-то конкретные настройки технологии. Хотелось бы остановиться немного на другом. В стандартной ситуации (когда у нас есть физический коммутатор) все настройки мы применяем port-based. Здесь же применяется технология, которая называется профили портов (port profile). Профили создаются на VSM и далее распространяются на vCenter в качестве портовых груп (port group). После того, как профиль прилетает на vCenter, администратор может назначить его на vNIC виртуальной машины. Будьте аккуратны, т.к. профили бывают двух типов: Ethernet и vEthernet. Для применения на физические или виртуальные линки соответственно.

Ниже я приведу пример конфига профиля и описание того, что он делает:

port-profile type vethernet VPROF_TEST

 vmware port-group ! делаем профиль доступным для vCenter

 switchport mode access

 switchport access vlan 158

 no shutdown

 max-ports 1024

 state enabled ! включаем профиль

Осталось разобраться с различными Desing Considerations, но это совсем другая история.

Метки: 1000v, nexus
Опубликовано: Data Center , Virtualization