Глубокое погружение в виртуализацию сети Hyper-V (часть 3)

• Глубокое погружение в виртуализацию сети Hyper-V (часть 2)
• Глубокое погружение в виртуализацию сети Hyper-V (часть 4)
• Глубокое погружение в виртуализацию сети Hyper-V (часть 5)

Во второй части этой серии статей объяснялся компонент RDID модуля WNV. В третьей части этой серии статей мы продолжим изучение других компонентов модуля WNV, включая сеть виртуальных машин, PA, CA и виртуальную подсеть. Для целей этой серии статей мы использовали схему HNV в Части II. Необходимо, чтобы я также включил в эту часть тот же проект HNV, чтобы вам было легко ссылаться на компоненты HNV, которые я вскоре объясню.

фигура 1

Сеть виртуальных машин: это логическая граница сети, созданная для виртуальных машин, участвующих в виртуализации сети Hyper-V. Как показано в приведенном выше проекте HNV, виртуальные машины Blue1, Blue2, Blue3 и Blue4 принадлежат к сети виртуальных машин. Точно так же виртуальные машины Red1 и Red2 принадлежат другой сети виртуальных машин. Сеть виртуальных машин состоит из нескольких виртуальных подсетей. Например, в приведенном выше проекте HNV для клиента A (10.1.1.0 и 10.1.2.0) в сети виртуальных машин созданы две виртуальные подсети, а в другой — одна виртуальная подсеть для клиента B (10.1.1.0). Сеть ВМ.

Каждая сеть виртуальных машин имеет идентификатор домена маршрутизации, который идентифицирует сеть виртуальных машин. Идентификатор домена маршрутизации (RDID) назначается с помощью командлетов SCVMM или PowerShell. Пожалуйста, обратитесь к части II этой серии статей, чтобы узнать больше о RDID.

Адрес поставщика (PA): PA отвечает за обработку трафика виртуальных машин между узлами Hyper-V. Он назначается физическому сетевому адаптеру внешнего виртуального коммутатора. PA — это IP-адрес, который отвечает за поиск входящего и исходящего трафика для виртуальных машин клиентов, а затем позволяет виртуальным машинам обмениваться данными на физическом уровне. Как показано в приведенном выше проекте HNV, PA 192.168.1.10, назначенный узлу Hyper-V Host1, может отвечать только за обработку трафика NVGRE для виртуальных машин Blue1, Red1 и Blue4. PA 192.168.2.20, назначенный Hyper-V Host2, может управлять только виртуальными машинами Blue3, Blue2 и Red2, работающими на Hyper-V Host2.

Важно понимать, что PA может управлять только виртуальными машинами, которые участвуют в виртуализации сети Hyper-V. Как показано в приведенном выше дизайне HNV, на Hyper-V Host2 работает виртуальная машина Non-HNV-VM, которая не участвует в виртуализации сети Hyper-V. Следовательно, эта виртуальная машина не будет управляться PA.

Может ли PA управлять всеми виртуальными машинами, работающими на узле Hyper-V? Это полностью зависит от выбранной вами модели развертывания виртуализации сети Hyper-V. У вас может быть либо один PA, управляющий всеми виртуальными машинами, либо один PA, управляющий только одной виртуальной машиной. Виртуализация сети Hyper-V предоставляет три модели развертывания HNV. Подробное объяснение каждой модели развертывания выходит за рамки этой статьи, но я предоставлю обзор каждой модели развертывания HNV. Три модели развертывания HNV:

• Один PA для всех виртуальных машин, использующих NVGRE
• Один PA на виртуальную подсеть с использованием NVGRE
• Один PA на виртуальную машину с использованием IP ReWrite

В случае модели развертывания «Один PA для всех виртуальных машин с использованием NVGRE» все виртуальные машины клиента управляются одним PA-адресом. Этот адрес PA отвечает за управление всеми виртуальными машинами ЦС, работающими на сервере Hyper-V. Это модель развертывания HNV, которую мы используем в этой серии статей. Эта модель развертывания HNV использует протокол NVGRE для инкапсуляции и декапсуляции входящих и исходящих виртуальных пакетов.

Если вы выберете модель «Один PA на виртуальную подсеть с использованием NVGRE», она предоставит вам гибкость в плане управления записями политик PA и виртуальных машин на узлах Hyper-V.

Третья модель развертывания HNV заключается в использовании «одного PA на виртуальную машину с использованием IP ReWrite». В этой модели развертывания используется механизм IP ReWrite, для которого требуется один PA на виртуальную машину. В этой модели развертывания PA может управлять только одной виртуальной машиной. Эта модель развертывания используется нечасто из-за необходимости наличия одного PA на виртуальную машину.

Примечание:
IP ReWrite больше не используется в Windows Server 2012 R2.

Помните, что прежде чем PA сможет управлять виртуальными машинами, участвующими в виртуализации сети Hyper-V, PA должен быть назначен каждому узлу Hyper-V. Существует два способа назначения PA хостам Hyper-V; с помощью командлета SCVMM или HNV PowerShell. Чтобы назначить PA с помощью командлетов PowerShell, используйте командлет , как указано в следующих командах:

1. New-NetVirtualizationProviderAddress -InterfaceIndex 17 -PrefixLength 24 -ProviderAddress «192.168.1.10»
2. New-NetVirtualizationProviderAddress -InterfaceIndex 17 -PrefixLength 24 -ProviderAddress «192.168.1.20»

Первая команда выполняется на Hyper-V Host1, а вторая команда выполняется на Hyper-V Host2. «InterfaceIndex 17» — это физический сетевой адаптер, на который сопоставляется внешний виртуальный коммутатор.

Вы можете получить « InterfaceIndex », выполнив командлет PowerShell , как показано на снимке экрана ниже:

фигура 2

Чтобы убедиться, что вы успешно назначили PA на обоих хостах Hyper-V, выполните на обоих хостах Hyper-V, как показано на снимке экрана ниже:

• Get-NetVirtualizationProviderAddress | FTProviderAddress,InterfaceIndex,PrefixLength–авто

Рисунок 3

Вышеупомянутая команда выполняется на Hyper-V Host1 для отображения PA, которому назначено InterfaceIndex 17. Выполните ту же команду на Hyper-V Host2, чтобы убедиться, что вы видите тот же результат для PA 192.168.2.20, но « InterfaceIndex» может быть другим.

Простое назначение PA-адресов не сработает. Вы также должны создать записи политики. Запись статического сопоставления должна быть создана для каждого PA и виртуальной машины, участвующих в виртуализации сети Hyper-V. Я расскажу больше о статическом отображении позже в этой серии статей. Прежде чем мы поговорим о записях политики PA + CA, давайте узнаем о компоненте CA модуля WNV.

Адрес клиента (ЦС): виртуальная машина, участвующая в виртуализации сети Hyper-V, называется ЦС. ЦС — это IP-адрес, присвоенный виртуальной машине. Как показано в приведенном выше проекте HNV, 10.1.1.11 и 10.1.1.12 — это IP-адреса ЦС, которые назначаются, например, виртуальным машинам Blue1 и Blue2. Blue1, Blue2, Blue3, Blue4, Red1 и Red2 известны как виртуальные машины ЦС. IP-адрес ЦС и его MAC-адрес используются для создания записи политики в таблице поиска на узле Hyper-V. Я объясню интерполяционную таблицу в заключительной части этой серии статей.

Виртуальная подсеть. Виртуальные машины в одной виртуальной подсети должны использовать один и тот же префикс IP-подсети. Точно так же все виртуальные машины в виртуальной подсети должны использовать один и тот же VSID, чтобы они принадлежали к одной и той же виртуальной подсети. Как показано в приведенном выше проекте HNV, существует три виртуальных подсети (10.1.1.0, 10.1.1.0 и 10.1.2.0). Виртуальные машины Blue1 и Blue2 принадлежат к виртуальной подсети 10.1.1.0, и этим виртуальным машинам назначен VSID 6001. Точно так же виртуальные машины Red принадлежат виртуальной подсети 10.1.1.0, и этим виртуальным машинам назначается VSID 6002. Виртуальные машины Blue3 и Blue4 принадлежат к виртуальной подсети 10.1.2.0, но этим виртуальным машинам назначен VSID 6005.

В приведенном выше дизайне HNV вы видите, что виртуальные машины, работающие в виртуальной подсети, используют «один и тот же» VSID. Вы можете создать несколько виртуальных подсетей, но виртуальные машины, работающие в этих виртуальных подсетях, не должны перекрываться. Например, вы не можете назначить VSID 6001 виртуальным машинам Red1 и Red2, поскольку этот VSID уже используется виртуальными машинами Blue. Если вы сделаете это, вы можете столкнуться с проблемами конфликта IP-адресов, и на самом деле это не поддерживается.

Резюме

В этой части вы узнали о компонентах VM Network, PA, CA и Virtual Subnet модуля WNV. Сеть виртуальных машин является логической границей и создается автоматически при создании RDID. Как вы узнали, PA отвечает за управление виртуальными машинами на узле Hyper-V, но PA управляет виртуальными машинами в зависимости от выбранной вами модели развертывания HNV.

В следующей части мы узнаем о VSID, а также о том, как использование VSID поможет изолировать виртуальные машины клиентов.

• Глубокое погружение в виртуализацию сети Hyper-V (часть 2)
• Глубокое погружение в виртуализацию сети Hyper-V (часть 4)
• Глубокое погружение в виртуализацию сети Hyper-V (часть 5)