Глава 4. Концепции сетевых сред vSphere и управление

Большинство физических машин будут иметь одну или более сетевые платы, которые не только позволяют им взаимодействовать с прочими сетевыми компонентами, но также предоставляют уникальную сетевую идентичность в виде некоторого MAC адреса и IP адреса. Теперь, когда вы применяете некоторую отдельную машину для размещения различных виртуальных машин, исполняющих некоторые обычные операционные системы, которые когда- то работали на какой- то физической машине, всплывает на поверхность их потребность иметь некую адресацию. Общий вызов такой: как мы назначим уникальные идентификационные данные для каждой из этих виртуальных машин и как мы заставим их стать частью сетевой среды нашей организации? Часть нашего ответа вводит существенное понятие Виртуальной сетевой интерфейсной платы (vNIC, Virtual NIC): именно она создаётся в некоторой виртуальной машине чтобы позволить ей соединяться с имеющейся сетевой средой. Второй частью данного вызова является тот факт, что хотя вы и имеете множество vNIC, соединённых с некоторой виртуальной машиной, должен иметься некий способ направлять весь обмен vNIC прочь из хоста ESXi через его физические NIC. Этот вызов разрешается при помощи некоторого определяемого программно коммутатора (software seitch). Программно определяемый коммутатор не является понятием, которое дебютировало в ESXi; некая его форма уже входила в состав продукта виртуализации VMware под названием VMware Workstation. Однако, он тогда не имел названия коммутатора. Поскольку VMware Workstation выходит за пределы тем, рассматриваемых в данной книге, мы охватим только те конструкции виртуальной коммутации, которые доступны в некоторой среде vSphere. Итак, что в действительности делает программно определяемый коммутатор? Он делает возможной агрегацию сетевых соединений от множества vNIC, применяет к ним политики сетевых настроек, а также прикрепляет их к имеющимся в хостах ESXi физическим адаптерам для протекания обмена. В этом имеется нечто большее чем то, что я пытался высказать в предыдущем предложении. В данной главе мы погрузимся глубже во все концепции построения виртуальных сетевых сред.

Теперь, когда мы осознали необходимость в некотором виртуальном коммутаторе, существенно понимать в чём отличия некоторого виртуального коммутатора при его сравнении с неким физическим коммутатором. Основной момент состоит в том, что VMware называет его неким виртуальным коммутатором для отображения того факта, что он способен переключать кадры между своими виртуальными портами или физическими восходящими связями. Итак, существуют ли какие- то отличия от некоторого физического коммутатора? Общий ответ - да, причём в паре направлений. Одно из отличий состоит в том способе, которым имеющийся виртуальный коммутатор обрабатывает передаваемые кадры:

Когда некий кадр поступает в любой физический коммутатор, его получатель определяется определённым номером порта коммутатора, соответствующим MAC адресу его получателя в имеющейся у данного физического коммутатора таблице MAC адресов. Если у вас нет возможности найти некую запись в данной таблице MAC адресов, он направляет данный кадр во все порты, отличающиеся данного порта источника. Во многом аналогично такому физическому коммутатору, любой виртуальный коммутатор также поддерживает некую таблицу MAC адресов, однако для виртуального коммутатора отсутствует какой бы то ни было процесс обучения. Виртуальный коммутатор уже будет иметь некий перечень MAC алресов и их номеров виртуальных портов. Если в виртуальный комутатор поступает некий кадр с каким- то MAC адресом, который не представлен в имеющейся в виртуальном коммутаторе таблице MAC адресов, тогда она отсылается через физический NIC (активные восходящие соединения), подключённый к данному виртуальному коммутатору. Это остаётся верным только если источником данного потока является некая виртуальная машина или некий интерфейс vmkernel, иными словами, только в случае когда этот кадр поступает через некий виртуальный порт. Если в какой бы то ни было виртуальный коммутатор поступает некий кадр с неизвестным MAC адресом через его физическое восходящее соединение, тогда этот кадр отбрасывается данным виртуальным коммутатором. Второе отличие состоит в общем числе портов в данном коммутаторе. Физический коммутатор будет иметь фиксированное число портов; некий виртуальный коммутатор будет всё- таки иметь некий максимальный предел, однако при этом намного большее число настраиваемых портов. В настоящее время VMware поддерживает до 4 096 виртуальных портов коммутации на хост ESXi. Третье отличие состоит в том, что он в сравнении с некоторыми, или даже с большинством, физических коммутаторов не является управляемым коммутатором, что, по существу, означает отсутствие у него собственного IP адреса управления или некоторой операционной системы, наподибии Cisco IOS. Вместо этого имеющиеся виртуальные коммутаторы управляются в гипервизоре или vCenter в зависимости от самого типа применяемого виртуального коммутатора (стандартный vSitch или VDS - распределённый виртуальный коммутатор).

Вы можете включить в некотором хосте ESXi в общей сложности максимально до 32 1Gbps и 16 10Gbps портов Ethernet. Эти максимальные значения регулируются созданием/ моделями/ драйверами/ свойствами имеющихся плат NIC и их комбинаций. Например, вы получаете до 32 1Gbps портов Ethernet Broadcom при использовании драйвера tg3 и отключённом NetQueue, однако тот же самый NIC с включённым NetQueue может представлять только 16 портов. Если бы вы применяли некую комбинацию портов Ethernet 10Gbps и 1Gbps, тогда можно было бы включить только 16 портов 10Gbps и четыре порта 1Gbps.

Отсылаем вас к разделу Сетевых максимумов на странице 14 Руководства по настройке максимальных значений для vSphere за дополнительными подробностями: https://www.vmware.com/pdf/vsphere6/r6/vsphere-6-configuration-maximums.pdf.

Теперь, когда ESXi имеет возможность управления большим числом физических NIC, должен иметься некий метод логического представления таких NIC для применения к ним политик настройки. Это достигается путём нумерации имеющихся физических NIC по шаблону vmnicX (vmnic0... vmnic32). Помимо этого имеется некая логика поведения такой нумерации. Все NIC последовательно нумеруются на протяжении процесса начальной загрузки ESXi при сканировании шины PCI, слота и номера порта. В настройках некоторого ESXi хоста /etc/vmware/esx.conf можно обнаружить соответствие PCI-id для vmnic:

Всем виртуальным машинам необходимы некие платы сетевых интерфейсов, которые могут подключаться к какой- то сетевой среде и принимать в ней участие. VMware называет его vNIC. Это элемент может быть создан в любой виртуальной машине. Имеются различные типы vNIC, которые могут создаваться в некоторой виртуальной машине. Тот тип vNIC, который вы выбираете, будет зависеть не только от имеющегося типа исполняющейся на виртуальной машине гостевой операционной системы, но также и от общего назначения данной платы NIC. VMware делает возможным добавлять до 10 vNIC для каждой виртуальной машины. Все те vNIC, которые вы добавляете к некоторой виртуальной машине могут быть любого поддерживаемого типа, или даже некоторой комбинацией множества типов NIC.

Допустимыми типами адаптеров vNIC являются:

Во многом аналогично тому как и всем виртуальным машинам, которые исполняются в имеющихся хостах ESXi, самому vmkernel также необходимо взаимодействовать с имеющейся сетевой средой для различных целей. Такие интерфейсы действуют как точки сетевого узла для данного vmkernel. Самый первый интерфейс vmkernel - vmk0 создаётся в процессе первой установки ESXi. Такой интерфейс является управляющим интерфейсом для самого хоста ESXi. VMware позволяет создавать максимально до 256 интерфейсов vmkernel (vmk0 - vmk255) в некотором хосте ESXi. Вариантами применения являются интерфейсы для обмена управляющей информацией, обмена VMotion, обмена FT, обмена Виртуального SAN, интерфейсов iSCSI и NAS. Поскольку все интерфейсы представляют некоторую точку сетевого узла, им необходима настройка адресов IP и MAC. Самый первый интерфейс vmkernel (vmk0) обеспечивается тем адресом MAC физического NIC к которому он подключён. Остальные интерфейсы прихватывают MAC адреса VMware OUI, которые создаются его хостом ESXi. В своём следующем разделе мы изучим как VMware обрабатывает все MAC адреса.

Всем виртуальным машинам и интерфейсам vmkernel, которые вы создаёте в некотором хосте ESXi требуется некоторая идентичность layer-2 для взаимодействия внутри такой сетевой среды. Во многом также как и в реальном физическом мире MAC адреса предоставляют такую уникальную идентичность для всех виртуальных машин или интерфейсов, которые подключаются к некоторому виртуальному коммутатору. Всякий физический сетевой интерфейс будет иметь некий выжженный 48- битный MAC адрес, нумерация которого имеет организационную уникальность. Это обусловлено тем, что все выпускающие такие платы производители будут иметь некий набор OUI (Organizationally Unique Identifiers, Уникальный идентификатор организации), выделенный ему IEEE (Institute of Electrical and Electronics Engineers). Фактичекски каждый производитель приобретает OUI в центре регистрации (Registration Authority) IEEE. VMware также имеет некий набор выделенных ей OUI, и ими являются 00:50:56 и 00:0C:29. Хотя оба OUI применяются по- разному, они могут назначаться NIC виртуальных машин и интерфейсам vmkernel. VMware также поддерживает применение LAA (Locally Administered Addresses, Локально управляемые адреса) с применением схем выделения на основе префикса (prefix-based) и диапазона (range-based). Обе эти схемы выделения требуют доступности vCenter для генерации и управления MAC адресами. При выделении на основании префикса всем имеющимся в вашей среде vCenter выдаётся некий уникальный префикс LAA из трёх байт. При схемы выделения из диапазона каждому vCenter выделяется некий диапазон MAC адресов и следует побеспокоиться о том, чтобы убедиться в том, что ограничения диапазонов являются уникальными для всех vCenter. Адреса MAC на основании OUI по умолчанию именуется как UAA (Universally Administered Addresses, Глобально назначенные адреса).

B ESXi, и vCenter могут генерировать MAC адреса для всех интерфейсов виртуальных машин. Некий MAC адрес создаётся для какого- то vNIC когда включается его виртуальная машина. Все созданные адреса остаются статичными пока отсутствуют какие бы то ни было конфликты MAC адресов в вашей среде.

Если ваша виртуальная машина не является неким хостом ESXi, который управляется каким- либо vCenter, её будет назначаться некий MAC адрес с OUI - 00:0C:29. Если же данный хост управляется vCenter, тогда этой виртуальной машине тогда этой виртуальной машине будет назначаться MAC адрес с его OUI - 00:56:54.

Все интерфейсы vmkernel за исключением vmk0 получат некий MAC адрес с OUI - 00:56:54.

Все создаваемые vCenteer/ ESXi MAC адреса называются начальным MAC адресом (initial MAC address). Тот MAC адрес, который применяется используемой GOS (Guest Operating System, Гостевой операционной системой) имеет название действующего MAC адреса (effective MAC address). Почти во всех случаях ваша GOS будет применять начальный MAC адрес в качестве действующего MAC адреса, только если GOS не меняет действующий MAC адрес для поддельного обмена, который не будет работать пока этот коммутатор не разрешит ему. В следующем разделе данной главы мы изучим дополнительно поддельные обмены (forged transmits) и изменения MAC адреса.

Распределённый коммутатор vSphere будет записывать так называемый MAC адрес времени исполнения (runtime MAC address), который является тем MAC адресом, который наблюдается тем dvPort, к которому подключён данный vNIC.

В предыдущих разделах мы рассматривали те понятия, которые помогли бы вам понять как работает виртуальный коммутатор. Имеется намного больше того, что предлагает виртуальный коммутатор в терминах свойств и настроек, нежели просто выполнять коммутацию кадров 2 уровня (layer-2). В данном разделе мы обсудим все понятия и настройки некоторого стандартного vSwitch.

В этой секции мы рассмотрим следующее:

Стандартный vSwitch является некоторой центральной сетевой конструкцией определённого гипервизора ESXi. В процессе установки создаётся некий vSwitch - vSwitch0 для настройки в нём своего управляющего интерфейса vmkernel (vmk0). Следующий моментальный снимок отображает созданный в процессе установки ESXi такой vSwitch по умолчанию:

В разделе Создание стандартного vSwitch мы дополнительно рассмотрим настройку стандартного vSwitch.

Группы портов являются логической конструкцией для группировки портов в некотором vSwitch. Стандартный vSwitch не выставляет индивидуальные порты для имеющегося пользовательского интерфейса чтобы применять политики. Вместо этого нам разрешается применять группу портов для достижения того жа самого. Интересно отметить, что не имеется никаких наборов значений или ограничений на общее число виртуальных портов, которое способна охватывать некая группа портов. Однако имеются пределы для vSwitch и для хоста. Для понимания пределов настройки истиной в последней инстанции является Руководство по Максимумам настроек.

Вот URL для данного Руководства по Максимумам настроек: https://www.vmware.com/pdf/vsphere6/r6/vsphere-6-configuration-maximums.pdf.

Все порты добавляются под их зонтик некоторой группы портов по мере того как вы подключаете к нему всё больше и больше vNIC. Вплоть до vShere 5.5 некий стандартный vSwitch по умолчанию мог бы иметь 128 связанных с ним портов. Начиная с vShere 5.5 в каком бы то ни было vSwitch нет установленного количества портов. Если вы просматривали те же самые свойства vSwitch с использованием веб клиента vSphere, тогда общее число значения портов будет отображаться как эластичное, что означает, что все виртуальные порты добавляются/ используются в некотором vSwitch когда вы подключаетесь к некоторой группе портов.

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

Группа портов виртуальной машины может применяться только для подключения к ней vNIC виртуальных машин. В некотором стандартном vSwitch может иметься более одной группы портов виртуальных машин. Группа портов VMkernel может использоваться только для подключения какого- то интерфейса VMkernel. К отдельной группе портов виртуальных машин можно подключать некоторое число виртуальных машин, однако всякий VMkernel требует некоторой отдельной группы портов в каком бы то ни было стандартном vSwitch. Это поведение слегка отличается в случае некоего распределённого vSwitch. В разделе, обсуждающем такие распределённые vSwitch мы изучим подробности.

Теперь давайте предположим что у вас имеются значительные рабочие нагрузки среды хостинга для различных подразделений бизнеса внутри вашей организации. Нет ничего необычного в том, чтобы заключать большую часть их рабочих потоков в их собственные подсети. Если это является необходимым, должен существовать метод, допускающий в вашей виртуальной среде коммутации применение VLAN. И стандартный, и распределённый виртуальные коммутаторы поддерживают применение VLAN. VLAN не могут настраиваться напрямую в некотором стандартном vSwitch; им необходимо быть установленными в некоторой группе портов.

Имеется три различных способа, посредством которых в некотором виртуальном коммутаторе обрабатываются VLAN:

Пометка внешнего коммутатора

Пометку (тегирование)/ снятие тегов все кадров 2 уровня будет выполнять сам физический коммутатор, к которому подключён кабелем физический NIC данного хоста ESXi. Для данной работы данный порт физического коммутатора необходимо будет настроить в качестве некоторого порта доступа. Одним из основных недостатков такого типа реализации является то, что весь vSwitch (все имеющиеся в нём группы портов) будут обрабатывать обмен только от одной отдельной подсети 2 уровня:

В режиме EST, когда некий кадр виртуальной машины приходит в такой vSwitch, он попадает в некий активный аплинк (восходящее соединение), которое затем переносит данный кадр в подключённый физический коммутатор. Порт доступа данного физического коммутатора затем назначит ему некий идентификатор (ID) VLAN и обработает данную коммутацию обмена. Когда некий кадр пытается вернуться обратно в данный vSwitch, этот порт доступа уберёт пометку (untag) рассматриваемого кадра и отправит весь обмен в vSwitch, а затем обратно к vNIC виртуальной машины получателя.

Пометка виртуального коммутатора

Все кадры 2 уровня помечаются на уровне имеющегося виртуального коммутатора. Чтобы работала данная реализация, переносящий весь обмен физический NIC должен быть подключён к некоторому порту физического коммутатора, который настроен для группировки (транка) всех необходимых VLAN. Все созданные в данном vSwitch группы портов виртуальных машин или vmkernel затем необходимо настроить с данным идентификаторм VLAN их соответствующих подсетей. Это наиболее часто применяемая и предпочитаемая реализация в большинстве больших/ средних/ малых окружений не только просто благодаря той гибкости, которую она предлагает, но также и из- за того факта, что наиболее современные среды блейд- систем имеют уменьшенное общее число портов физических NIC в присутствующем оборудовании сервера, пользуясь всеми преимуществами 10Gbps Ethernet:

В режиме VST при поступлении какого- то кадра от некоторой виртуальной машины в некий виртуальный коммутатор ему назначается некий номер VLAN. Данный номер VLAN должен быть уже настроен на имеющейся группе портов, к которой подключена данная виртуальная машина. Данный тег VLAN затем буде перенесён от данного активного физического NIC в имеющийся в подключённом физическом коммутаторе порт транка. Когда некий кадр поступает в какой- то виртуальный коммутатор из данного физического коммутатора, с него снимается пометка данного кадра (untag) и затем выполняется коммутация данного кадра к её виртуальной машине.

Пометка виртуального гостя

В этом случае за назначение тегов VLAN становится ответственной имеющаяся гостевая операционная система. Та группа портов, к которой подключается такая виртуальная машина должна быть настроена с VLANID 4095 (что означает создание транка):

В режиме VGT весь помеченный VLAN обмен будет протекать без изменений через имеющийся виртуальный коммутатор и к присутствующему физическому коммутатору. Данная гостевая операционная система сама по себе отвечает за тегирование всех кадров и снятие с них пометки.

Чтобы иметь возможность создать некий стандартный vSwitch вам будет необходимо либо осуществить доступ к какому- то управляющими вашими хостами ESXi серверу vCenter, либо напрямую подключить клиента vSphere к настраиваемому хосту ESXi. Как я уже упоминал ранее, данная установка ESXi создаст по умолчанию vSwitch0 для того, чтобы он мог создать в нём некий интерфейс управления vmkernel. Вот подробности настройки IP, которые вы предоставили после установки и которые относятся к самому первому созданному интерфейсу vmkernel (vmk0).

Для создания vSwitch вам будет необходимо запустить мастер Add Networking. Имеется ряд вариантов запуска этого мастера. В данном случае мы связываемся с vCenter посредством клиента vSphere:

В панели Recent Tasks ввы увидите некую успешно завершённую Update network configuration task (Задачу обновления сетевых настроек). Закладка Manage | Networking в этом хосте теперь отображает созданный новый vSwitch с некоторой новой группой портов виртуальной машины. Взгляните на картинку ниже:

Сцепление и выделение портов

Сцепление портов

Выделение портов

Реализация частных VLAN в VDS

Настройки стандартного vSwitch и группы портов

Настройки dvPortGroup и dvPort

Беспорядочный режим

Изменение MAC адресов и поддельный обмен

Настройка формирования обмена

Маршрутизация на основе ID виртуального порта

Маршрутизация на основе хеша MAC источника

Маршрутизация на основе хеша IP

LBT

Применение явного порядка отказоустойчивости

Редактирование свойств

Выбор источников и получателей