Распределенные коммутаторы – vNetwork Distributed Switch, dvSwitch. Настройки

Виртуальные коммутаторы VMware – штука хорошая. Однако нет предела совершенству,  и в больших инфраструктурах вам могут быть интересны распределенные виртуальные коммутаторы  – vNetwork Distributed Switch, или dvSwitch.

Обратите  внимание  на то, что настройки распределенных виртуальных ком-

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

Q  в разделах 2.3.4 и 2.3.5 описаны уникальные настройки dvSwitch;

Q  в разделе 2.4 описаны настройки,  доступные и для стандартных,  и для распределенных  виртуальных коммутаторов, это группы настроек «Security»,

«VLAN», «Traffic shaping» и «NIC Teaming».

2.3.1. Основа понятия «распределенный виртуальный коммутатор VMware»

Идея  их  заключается в  следующем:  в  случае  использования  стандартных  вКоммутаторов у вас разные (пусть очень часто и идентично настроенные) виртуальные коммутаторы на каждом сервере. Акцент я хочу сделать вот на чем: создать и поддерживать эту, пусть даже идентичную,  конфигурацию придется  вам. При необходимости,  например, создать еще одну группу портов для еще одного VLAN вам потребуется повторить это простое действие на всех серверах ESX(i).

А в случае создания  распределенного коммутатора  вы получаете один-един ственный (логически) коммутатор, существующий сразу на всех серверах ESX(i).

Вы настраиваете  только  этот, логически  единый  коммутатор.  Новую группу портов из примера выше вы создадите один раз, и она появится для всех серверов ESX(i), входящих в распределенный коммутатор.

ВМ, даже при миграции  с сервера  на сервер, остаются  не только  на том же коммутаторе,  но и даже на том же порту распределенного виртуального коммутатора (это называют Network vMotion). Это позволяет  проще настраивать политики  безопасности,  осуществлять мониторинг трафика  ВМ, привязываясь даже к отдельному порту вКоммутатора.

В отличие  от стандартных  виртуальных коммутаторов VMware,  distributed vSwitch  поддерживают Private VLAN и двухсторонний traffic shaping (о том, что это такое, см. в разделах 2.4.2 и 2.4.4). В версии 4.1 в список уникальных возможностей распределенных коммутаторов добавились  такие функции,  как:

Q  Network IO Control – возможность гибко настраивать минимально и мак-

симально  доступные  ресурсы  пропускной способности  для  трафика разных типов. Подробности о NIOC  см. в главе 6, посвященной распределе нию ресурсов;

Q  Load Based Teaming – балансировка нагрузки  между  физическими кон-

троллерами одного вКоммутатора в зависимости от нагрузки  на каждый контроллер.

Еще один плюс – распределенный вКоммутатор  доступен  в реализациях от VMware и от Cisco.

Вариант   от  Cisco,  распределенный  виртуальный  коммутатор   Cisco  Nexus 1000V,  приобретается независимо  от vSphere  (но  подойдет  не  любая  лицензия vSphere,  на момент написания – только Enterprise Plus). Он обладает всеми возможностями, присущими  сетевому  оборудованию от Cisco. Позволяет добиться того, что все используемые коммутаторы  в сети компании  созданы одним производителем (здесь имеется в виду Cisco), и сетевые администраторы могут управлять ими точно так же, как коммутаторами физическими, снимая, таким образом, эти задачи с администратора vSphere.  Однако  рассмотрение  настроек  и возможностей этого решения в данной книге описано не будет.

Здесь  будет  описан  распределенный виртуальный коммутатор  от  VMware.

Возможность  им пользоваться появляется после активации лицензии, дающей на

него право, – сегодня это vSphere Enterprise Plus (и ее ознакомительный 60-дневный период после установки vSphere, Evaluation-лицензия).

Как я уже сказал, dvSwitch – объект скорее логический, как таковой существующий только для vCenter.  Мы создали один распределенный вКоммутатор, но на каждом сервере, для которых он существует, автоматически создаются  стандартные вКоммутаторы,  скрытые от нас (рис. 2.11). Таким образом, де-факто  распределенный коммутатор является шаблоном настроек. Мы создаем его и указываем  настройки в vCenter – это control plane по документации VMware, то есть уровень управления. А после включения в созданный  распределенный коммутатор  серверов ESX(i) vCenter создает на них стандартные  коммутаторы,  скрытые от нас. По документации VMware это IO Plane, прикладной уровень. За всю работу отвечают скрытые коммутаторы на серверах ESX(i), все управление осуществляется только через vCenter.

Рис. 2.11. Иллюстрация сути распределенного виртуального коммутатора Источник: VMware

Минусом  такой  схемы распределенного виртуального коммутатора VMware является возросшая  сложность,  в частности  зависимость от vCenter. vCenter является управляющим элементом для dvSwitch,  и при недоступности vCenter у администратора нет возможности менять настройки распределенного коммутатора  и даже переключать виртуальные машины на другие группы портов. Однако даже при недоступности vCenter сеть будет продолжать работать – ведь за техническую сторону вопроса отвечают скрытые от нас коммутаторы на каждом ESX(i), теряется только возможность изменения настроек.

Кстати, подключение  самого vCenter к распределенному коммутатору не поддерживается VMware.

Подключитесь клиентом  vSphere  к vCenter.  Предполагается, что в иерархии  vCenter уже создан объект Datacenter, уже добавлены  серверы. Распределенный виртуальный коммутатор  создается  для объекта Datacenter, и существовать  для серверов из разных Datacenter один dvSwitch не может.

Пройдите  Home ? Networking. В контекстном меню объекта Datacenter вы-

берите пункт New vNetwork Distributed Switch.

В запустившемся мастере нас спросят:

Q  Name – имя создаваемого вКоммутатора. Влияет только на удобство;

Q  Number of dvUplink ports – максимальное количество  подключений ко внешней сети – привязанных vmnic – на каждом сервере. Обратите  внимание: один такой вКоммутатор  может существовать  для серверов  с разной конфигурацией, с разным количеством доступных сетевых контроллеров – а здесь мы ограничиваем  максимальное число используемых для данного dvSwitch контроллеров на одном сервере;

Q  дальше вам предложат  выбрать серверы, для которых будет существовать  создаваемый  вКоммутатор.  Выбор можно осуществить или изменить  позже. Если будете выбирать серверы сейчас, то вам покажут свободные физи ческие сетевые контроллеры на каждом выбранном сервере – и вы сможете выбрать те из них, что будут использоваться для создаваемого  вКоммутатора. По ссылке View Details вам покажут  исчерпывающую информацию о физическом сетевом контроллере – драйвер, производитель, статус подключения  (link  status), PCI-адрес, доступные  через него подсети  IP  – не покажут здесь только MAC-адрес;

Q  на последнем  шаге можно будет снять флажок  Automatically create a default port group. Если  он стоит,  то автоматически  будет  создана  группа портов со 128 портами и именем по умолчанию. Имя по умолчанию  малоинформативно, поэтому  я рекомендую  этот флажок  снимать  и создавать группу портов самостоятельно, после создания  вКоммутатора.

Обратите внимание. У стандартных вКоммутаторов  число портов настраивается для них самих, группы портов «безразмерные».  У распределенных  вКоммутаторов наоборот. Вы можете создать до 248 распределенных  виртуальных  коммутаторов для сервера. На одном сервере может быть до 4096 портов стандартных и распре деленных вКоммутаторов.  Это означает, что если не задавать заведомо  огромных значений числа портов, то с ограничениями с этой стороны вы не столкнетесь.

Когда вы создали dvSwitch,  то на странице Home ? Inventory ? Networking

вы видите картинку  примерно как на рис. 2.12.

Здесь  «Demo_dvSwitch» – это сам объект  – распределенный  вКоммутатор. Объект «Demo_dvSwitch-DVUplinks-28» – это группа портов, в которую объединены его подключения ко внешним  сетям. То есть те порты вКоммутатора,  к ко-

Рис. 2.12. Свежесозданный dvSwitch

торым подключены  физические сетевые контроллеры серверов, на которых этот dvSwitch существует. Нужен  этот объект для получения информации о внешних подключениях – обратите внимание на столбцы в закладке Ports для данной группы портов. Число 28 в названии – это случайным образом сгенерированное число, для уникальности имени этого объекта.

Ну  и «Demo_dvPortGroup» – созданная  вручную  группа  портов, туда можно подключать  ВМ, а также виртуальные сетевые контроллеры Service Console и VMkernel.

Обратите внимание. При  использовании стандартных  виртуальных  коммутаторов невозможно  поместить в одну группу портов виртуальные  машины и интерфейс VMkernel или Service Console. На распределенных виртуальных коммутаторах VMware это возможно,  на dvSwitch в одной группе портов могут сосуществовать и ВМ, и интерфейсы SC и VMkernel в любых сочетаниях.

Кстати говоря, объект «VM Network»  на этом рисунке – это группа портов на стандартных  виртуальных коммутаторах серверов этого vCenter.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий