Виртуальные контроллеры Service Console и VMkernel

Первое,  чем отличаются  виртуальные сетевые  контроллеры, – это  принадлежность. Принадлежать они могут Service Console (для  ESX, у ESXi нет Service Console),  VMkernel  (самому гипервизору) и виртуальным машинам.

Если  виртуальный контроллер принадлежит ВМ, то он может  быть разных типов – Flexible, vmxnet2, vmxnet3, E1000. Но про них поговорим в разделе, посвященном свойствам и оборудованию виртуальных машин, а здесь сконцентрируем внимание на виртуальных сетевых контроллерах для Service Console и VMkernel.

Управляющий интерфейс ESX, виртуальный контроллер для Service Console (vswif)

Виртуальный сетевой контроллер для Service Console используется для управления  сервером  ESX. Один  такой  контроллер создается  установщиком  сервера ESX, именно ему принадлежит тот IP-адрес,  который вы указывали при установке. Именно на IP-адрес Service Console вы подключаетесь клиентом vSphere, через него с сервером работает vCenter,  на этот IP подключаются утилиты  для работы с ESX. Также  через интерфейс Service  Console  идут сигналы  пульса  (heartbeat) при работе кластера VMware HA. Наконец, некоторые варианты резервного копирования  виртуальных машин осуществляются через интерфейсы Service Console.

Вам следует резервировать управляющий интерфейс,  сделать это можно двумя путями, см. рис. 2.6.

В левой части рисунка  вы видите дублированную конфигурацию единственного интерфейса Service Console. Она задублирована за счет того, что к вКоммута-

Рис. 2.6. Два варианта дублирования управляющего интерфейса ESX

тору подключены два сетевых контроллера. Таким образом, выход из строя одной физической сетевой карточки (а если они подключены к разным физическим коммутаторам – то и одного из них) не приведет к недоступности управления сервером ESX по сети.

В правой  части рисунка  вы тоже видите  дублированную конфигурацию, но дублированную по-другому – созданы два интерфейса Service Console, на разных вКоммутаторах,  следовательно, на разных vmnic. Если  выйдет  из строя один из каналов  во внешнюю сеть (сам vmnic или порт в физическом коммутаторе,  к которому он подключен, или сам физический коммутатор), то один из интерфейсов SC станет недоступен, но останется другой.

Первый  вариант  удобнее в использовании, но если мы не можем себе позволить  выделить  два vmnic на вКоммутатор  с Service  Console,  то он будет невозможен. Выделить  может не получиться, если количество сетевых контроллеров в сервере недостаточно под все наши задачи. Тогда имеет смысл пойти по второму пути. Само собой, на вКоммутаторах интерфейсы Service Console могут соседствовать с любыми другими виртуальными интерфейсами в любых количествах – на рис. 2.6 их нет для простоты.

Однако первый вариант резервирования не защитит от двух дополнительных типов проблем:

Q  ошибки настроек интерфейса SC;

Q  проблемы во внешней сети. Во втором примере двум разным интерфейсам SC даны адреса из разных сетей, и это защитит  в том случае, если одна из этих сетей начнет испытывать проблемы (например, перегрузка  паразит ным трафиком  или сбой маршрутизатора).

Создать  еще один интерфейс очень просто: Configuration ?  Networking ?

Аdd Networking (для  создания  нового вКоммутатора – то есть резервирование

по правому варианту  с рис. 2.6). Нас спросят, группу портов для чего мы хотим создать на этом вКоммутаторе.  Несложно догадаться,  что сейчас нас интересует Service  Console.  Выбираем,  жмем Next. Выберем,  какие vmnic привязать к создаваемому сейчас вКоммутатору.  Next. Указываем имя (Network Label) – это название группы портов.

Это название – для человека, так что рекомендую давать говорящие названия.

«Service_Console_2» вполне подойдет.

Однако  при чем здесь группа портов, мы ведь создаем виртуальный сетевой интерфейс Service Console? Дело в том, что любой виртуальный сетевой контрол лер числится  подключенным именно к группе портов, поэтому при создании интерфейса  SC из GUI  мы создаем и интерфейс Service Console,  и группу портов для него.

На стандартном  виртуальном коммутаторе  интерфейс Service Console всегда занимает  свою группу портов целиком  (или,  что то же самое, группа портов для Service Console  всегда состоит из одного порта).  Этот факт  не является ограничением – на одном вКоммутаторе могут сосуществовать любые виртуальные интерфейсы  в любых комбинациях, просто  под каждый  интерфейс Serice Console (и, забегая вперед, VMkernel) создается отдельная группа портов.

Обратите внимание. Я не рекомендую использовать пробелы и спецсимволы в каких бы то ни было названиях. Это не смертельно, но может создать дополнительные проблемы при работе в командной строке и сценариях.

все.

Затем  для виртуального контроллера указываем  настройки IP.  В принципе,

Единственный, наверное, нюанс – если хотим создать интерфейс SC не на но-

вом, а на уже существующем  вКоммутаторе.  Тогда делаем так: Configuration ?

Networking ? для нужного вКоммутатора нажимаем  Properties ? и на вкладке

Ports нажимаем Add. Дальше все так же.

Наконец,   в  случае   распределенных  виртуальных  коммутаторов   пройдите Configuration ? Networking ? кнопка  Distributed Virtual Switch ? ссылка Manage Virtual Adapters ? Add.

Будьте  аккуратны в случае  изменения настроек  интерфейса SC,  когда  он один, – в случае ошибки (например, опечатки в IP-адресе) доступ к управлению ESX по сети станет невозможен.  Решается такая проблема из командной  строки для ESX или из BIOS-подобного локального  интерфейса ESXi. В любом случае понадобится доступ к локальной консоли сервера – физически или по iLO и аналогам.

Обратите внимание. Виртуальный сетевой контроллер для Service Console называется vswif – при создании их из GUI им даются имена вида vswif#, в командной строке мы управляем этими объектами с помощью esxcfg-vswif.

Управляющий интерфейс ESXi

Для ESX управление  идет через интерфейс Service Console. Но в составе ESXi нет Service  Console.  Поэтому  для ESXi  в качестве  интерфейсов управления используются  виртуальные сетевые контроллеры VMkernel,  те из них, в свойствах которых установлен  флажок «Management traffic» (рис. 2.7).

Таким  образом, организационные соображения здесь те же самые, что и для интерфейсов Service Console в ESX, но в качестве самих интерфейсов выступают интерфейсы VMkernel  с соответствующим флажком в свойствах.

Виртуальный сетевой контроллер для VMkernel (vmk)

И  в ESX,  и в ESXi  мы можем  создать  виртуальные сетевые  адаптеры  для VMkernel, для гипервизора.  Нужны  они для:

Q  vMotion – по этим интерфейсам будет передаваться содержимое оператив-

ной памяти переносимой  ВМ;

Q  подключения дисковых  ресурсов  по iSCSI  в случае  использования  программного инициатора iSCSI;

Q  подключения дисковых ресурсов по NFS;

Q  Fault  Tolerance  – по этим интерфейсам будут передаваться процессорные инструкции на резервную ВМ в Fault Tolerance-паре;

Q  (только  на ESXi)  управления сервером  (на  ESX  для  этого  используется

сеть Service Console).

Рис. 2.7. Управляющий интерфейс ESXi

См. подробности  и требования  к сети для соответствующих функций в разделах, им посвященных.

Таким образом, работа гипервизора с сетью немного двойственна, потому что происходит на двух уровнях. С одной стороны, гипервизор имеет доступ и управляет  физическими контроллерами; с другой – сам для себя, для своего доступа в сеть создает контроллеры виртуальные. Тем не менее такая схема весьма удобна для понимания:  физические контроллеры – это всегда «ресурс», всегда только канал во внешнюю сеть. А как источник трафика, как активные объекты сети всегда выступают контроллеры виртуальные, в том числе для трафика  гипервизора.

Виртуальные сетевые контроллеры для гипервизора создаются точно так же, как для Service Console (на ESX): Configuration ? Networking ? и затем:

Q  либо  Аdd Networking для  создания  нового  вКоммутатора и  интерфейса VMkernel  на нем;

Q  либо  для  существующего  вКоммутатора Properties ? Add на  закладке

Ports;

Q  в  случае  распределенных виртуальных  коммутаторов пройдите  Configuration ? Networking ? кнопка  Distributed Virtual Switch ? ссылка Manage Virtual Adapters ? Add.

В любом случае как тип добавляемого  интерфейса выбираем VMkernel. Укажем имя группы портов и настройки IP для создаваемого интерфейса.

Обратите  внимание  на то, что для интерфейса VMkernel  у нас есть возможность установить  три флажка (рис. 2.8).

Каждый  из  флажков  разрешает  передачу  соответствующего трафика  через данный  интерфейс.  Технически  допускается любая комбинация флажков  на од-

Рис. 2.8. Настройки интерфейса VMkernel на ESXi

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

К тому же в случае использования ESXi через интерфейс с флажком «Management traffic» по умолчанию не пересылается трафик iSCSI и NFS. Если вы планируете использовать один интерфейс для управления и обращения  к IP-СХД, то лучше всего создать  несколько  интерфейсов, пусть даже из одной подсети  и на одном и том же виртуальном коммутаторе.

Обратите внимание. Виртуальные  сетевые контроллеры этого типа  называются vmk – при создании их из GUI им даются имена вида vmk#, в командной строке мы управляем этими объектами с помощью команды esxcfg-vmknic.

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

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

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

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