N1KV install: prepare

Речь пойдёт о установке Cisco Nexus 1000v, краткий обзор которой можно найти здесь. При этом речь пойдёт про самую крайнюю версию данного продукта – 2.1.1, которая стала бесплатна.

Формат статьи подразумевает, что читатель должен иметь опыт работы с VMware vShpere, VMware virtual standard switch (vSS) и желательно VMware virtual distributed switch (vDS).

Итак, 22 октября сего года был релиз новой версии. Пакет свободно доступен любому зарегистрированному пользователю cisco.com. Имя файла – Nexus1000v.4.2.1.SV2.1.1.zip. Весит 683MB. Шатен, голубые глаза. Особых примет нет. Татуировки отсутствуют.

1. Вступление

Значительная часть информации взята прямо из Release Notes. Если вы планируете не просто играться, а ставить это дело в продакшен, рекомендую к прочтению на ночь.

Если раньше надо было читать README.txt для того чтобы узнать как запустить нужные для установки оснастки, то теперь нам доступно всё через единую красивую панельку. Или как написано в release notes – “simplifies the entire installation process via a single pane of glass”:

The Cisco Nexus 1000V Installation Management Center is now a standalone Java application that can install the Cisco Nexus1000V VSM or VEM.
The Cisco Nexus 1000V Installation Management Center supports a single pane for invoking the Cisco Nexus1000V VSM installer and VEM installer.

При запуске выглядит вот так:

Ещё перед началом подготовки необходимо убедиться, что ваша версия VMware совместима с данным продуктом и релизом – vSphere 4.1.0, 5.0.0, and 5.1.0 release trains.

2. Составление плана

2.1. План общего вида

Итак, мы имеем два VMware ESXi узла, на одном из которых имеется VM с vCenter.
На каждом из узлов будет имется по одной VM для проверки корректной настройки сети.
Базовая настройка будет использовать vSS – virtual standard switch, машины в одном VLAN – перед миграцией на N1KV обязательно проверяется базовый connectivity между имеющимися VM. Используемый VLAN – 1.

Известно, что vCenter рекомендуется размещать на отдельном от управляемых узлов физическом хосте и, если он всё же в виртуальной машине, использовать vSS, дабы не потерять доступ к нему и связность с управляемыми узлами в случае ошибки конфигурации.

Далее, на каждый из узлов будет установлен N1KV в режиме HA – primary и secondary на разных узлах. На узлы будет установлен VEM, добавлены все нужные плагины. Проверяется связность всех частей и выполняется миграция с vSS на N1KV. Настройка будет произведена с использованием всё того же VLAN1, с целью проверить корректность настройки.

После успешной проверки будет выполнена настройка внешнего коммутатора для InterVLAN routing и сам N1KV настроен для использования разных VLAN для разных типов трафика. Этот момент подробнее рассматривается в разделе “Дизайн VLAN”.

На самом деле вы сможете оставить всё как есть, так как использование flat L2-domain design допускается и во многих случаях необходим в виртуальной серверной ферме.

Можно пропускать этап с проверкой L2-connectivity и сразу мигрировать на готовый многовлановый вариант, но с целью исследования, мы всё же используем возможность поиграться в CLI. К тому же вариаций дизайна много, например вы можете пусть management трафик мимо N1KV, через vSS и возможность увидеть как изменить настройки использованные при установке могут быть очень полезными для изменения дизайна.

2.2. Дизайн VLAN

Эта часть регулярно упускается во всех статьях про N1KV и даже в вебинарах (в том числе том, который был на Cisco Expo 2011). Мы не станет повторят ошибок коллег и рассмотрим схематично: какие вланы обязательны, какие желательны и какой из них куда должен попадать.

2.2.1. Служебные VLANs
Это те VLAN’ы с которыми надо определиться до того, как вы запустите оснастку установки N1KV. Они используются НЕ для передачи трафика виртуальных машин, а для служебного трафика между нашими служебными частями виртуальной сетевой инфраструктуры: vCenter, VSMs, VEMs и только. Рассмотрим на примере нашей схемы.

Читаем строку и смотрим на картинку, чтобы понять систему (для чего они используются вспоминаем здесь):

  • существует три типа служебных VLAN’ов и все они в обязательном порядке добираются до каждого из VSM;
  • каждый служебный VLAN на VSM представлен как обычная виртуальная сетевая карта (vmnic): Network Adapter#1, #2, #3. При этом порядок карт очень важен, сначала идёт Control, потом Management и последней Packet;
  •  Management VLAN используется только между vCenter и VSM, таким образом downlink со свитча до vCenter, если он на отдельном физическом хосте, либо до виртуальной машины в составе какого ESXi-хоста, должен спускаться всего 1 этот VLAN (не считая прочих нужных для естественной работы vCenter, не связанной с этой статьёй);
  •  Control и Packet VLAN используется только между VSM и VEM, соответственно до этих машин должен спускаться trunk, включающий оба этих VLAN;
  • допускается использование одного VLAN для всех этих служебных каналов и, более того, в этом нет ничего плохого, если вы не готовы на вскидку сказать, чего потеряете в этом случае;
  • если вы всё же предпочитаете разные VLAN для разных служебных данных. следует понимать, что так как служебным узлам достаточно L2 связности в рамках VLAN и обмена данными между VLAN не требуется, то на внешнем коммутаторе не требуется SVI-интерфейсов для InterVLAN routing (однако, нам всё же требуется внешнее коммутируещее устройство, для связи между разными ESXi-узлами).

Давайте условимся, что мы будем использовать разные VLAN для каждого служебного канала:

  • N1KV Control VLAN – 1001;
  • N1KV Mgmt VLAN – 1002;
  • N1KV Packet VLAN – 1003.

2.2.2. VLAN’ы для передачи трафика виртуальных машин

Указанные тоже желательно планировать до установки, но вы всё ещё можете поменять их до момента пока система не начала гонять реальных трафик. Вполне резонно, что вы, как и мы, в этой статье, разбиваете задача на несколько частей и в конце каждой убеждаетесь, что всё настроено правильно.

Эти VLAN будут назначаться виртуальным портам соединения VEM с непосредственно VM и так же нам скорее всего понадобится гонять трафик между VM находящихся в разных VLAN/подсетях (и для переезда VM это тоже важно), т.е. внешний коммутатор должен обеспечивать возможность InterVLAN routing. Прежде чем определиться с цифрами, учтём несколько моментов:

  • VEM ничего не знает о других VEM и если место назначения не в его юрисдикции, то он просто отправляет его по аплинкам, считая, что вышестоящее устройство позаботится о заблудившихся фреймиках. Однако, за локальный трафик, между directly-attached VM, отвечает именно он;
  • VSM не маршрутизирует трафик, а только лишь управляет известными и потому подвластными VEM. Т.е. в схеме этих VLAN он никак не задействован. Так же как и vCenter, да.;
  • каждый VSM может управлять не более чем 64VEM и как говорят в документации – Cisco 1000v можно представить как 66-слотовый модульный коммутатор. При этом слоты 1 и 2 отводятся под supervisors – наши VM c N1KV и подключение прочих VM начинается с третьего слота, т.е. имена портов будут Ethernet 3/1, 3/2, … , 3/N. Возможно это поможет вам легче представлять в уме пути трафика;
  • благодаря тому что каждый порт доступа VEM как бы привязывается к VM, все сетевые настройки полностью сохранятся, при переезде VM на другой физический узел (в процессе отработки vMotion, HA, FT);

Вроде всё просто, значит давайте определимся с цифрами:

  • Native VLAN – 1100 [нативный VLAN используемый для того чтобы все фреймы маркировались VLAN-tag’ом]
  • Management VLAN – 1110 / subnet 172.16.10/24 [используется для подсети с management ip-адресами vCenter, каждого ESXi-узла, соответственно для передачи трафика типа vMotion, между этими узлами. Не требует маршрутизации вниз, узлам достаточно видеть себя в рамках L2-домена, но требует маршрутизацию наверх, чтобы иметь возможность связаться с узлами для управления];
  • VMGroup1 VLAN – 1120 / subnet 172.16.20/24 [первая подсеть для виртуальных машин]
  • VMGroup2 VLAN – 1130 / subnet 172.16.30/24 [вторая подсеть для виртуальных машин]

2.2.3. Точка зрения внешнего коммутатора

Коммутатор понятия не имеет, как выглядит мир за пределами своих портов доступа (мог бы, благодаря STP и IGP, но ни первое ни тем более второе в виртуальной среде не существует). С его холма всё выглядит гораздо проще, чем есть на самом деле:

Напомню, что трафик между VLAN 1001,1002,1003 не будет передаваться, поэтому маршрутизация между этими VLAN не нужна и достаточно просто иметь указанные VLAN на коммутаторе и включить их в разрешённые на транке. Тогда как трафик между VLAN 1110,1120 и 1130 должен передаваться, так как это реальный трафик наших виртуальных машин, поэтому на внешнем коммутаторе должны иметься SVI-интерфейсы и включен ip routing.

Зачем затягивать? Давайте посмотрим как будет выглядеть финальная конфигурация внешнего коммутатора, т.е. когда не будет уже никакого VLAN1.

Материала много, есть над чем подумать, поэтому статью разобьём на две части.
Мы готовы к установке и займёмся этим во второй части, где возможно откажемся от реализации с VLAN1, если это будет делать объёмы настолько большими, что придётся делать и третью часть.

3. Источники

SHARE: Tweet about this on TwitterShare on FacebookShare on VKShare on LinkedInShare on Google+Email this to someone
  • mika

    Интрефейсы interface range g1/0/1-4 не агрегированы?

    • Sk1f3r

      Узлов несколько и агрегировать все линки не разумно. Да и вообще
      агрегировать с VMware не всегда нужно, ведь зачастую используется NIC
      Teaming, однако возможно, тем более в 5.1 добавили поддержку LACP ;)