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

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

Мы не собираемся демонстрировать конфигурацию NVGRE, но объясним различные компоненты, участвующие в виртуализации сети Hyper-V, с помощью схемы HNV, показанной ниже, а также узнаем о командлетах PowerShell, которые нам необходимо использовать для настройки виртуализации сети Hyper-V. Чтобы ограничить обсуждение, мы сосредоточимся на том, как эти компоненты сочетаются друг с другом для реализации виртуализации сети Hyper-V. Прежде чем я начну объяснять компоненты WNV, позвольте мне дать вам обзор дизайна HNV, объясняя, как эти компоненты выглядят в проекте виртуализации сети при настройке для нескольких клиентов в общем облаке IaaS.

Виртуализация сети Hyper-V, иногда называемая сетью HNV, включает в себя различные компоненты. Технология построена из компонентов CA, PA, VSID, RDID/VM Network и Lookup Table. Это основные компоненты модуля WNV, как показано в приведенном ниже проекте HNV:

Рисунок 1.1: Виртуализация сети Hyper-V и ее компоненты

Как показано на рисунке 1.1 выше, работают два хоста Hyper-V; Хост1 и Хост2. На обоих хостах Hyper-V работает несколько виртуальных машин от разных клиентов. Несколько виртуальных машин работают с одинаковой схемой IP на обоих узлах Hyper-V. Синие виртуальные машины принадлежат Клиенту-A, а красные виртуальные машины принадлежат Клиенту-B.

Как показано выше, виртуальные машины клиентов работают в трех виртуальных подсетях; две виртуальные подсети (10.1.1.0 и 10.1.2.0) для синих виртуальных машин и 1 виртуальная подсеть (10.1.1.0) для красных виртуальных машин.

Виртуальные машины Blue1 и Red1 работают на Hyper-V Host1 с одним и тем же IP-адресом (10.1.1.11). Виртуальные машины Blue2 и Red2 также работают с одним и тем же IP-адресом (10.1.1.12), но на Hyper-V Host2. Эти виртуальные машины настроены в одной виртуальной подсети, но используют разные VSID (6001 и 6002). VSID позволяет запускать виртуальные машины с одним и тем же IP-адресом. Вы не столкнетесь с конфликтом IP-адресов для виртуальных машин Blue1 и Red1, поскольку они настроены с разными VSID. Если вы удалите VSID или назначите те же VSID, вы столкнетесь с проблемой конфликта IP-адресов.

Совет:
VSID аналогичен идентификатору VLAN. Единственное отличие состоит в том, что идентификатор VLAN нельзя использовать с виртуализацией сети Hyper-V, вместо этого вы должны использовать VSID.

Виртуальные машины Blue3 и Blue4 принадлежат Клиенту-A. Эти виртуальные машины работают в отдельной виртуальной подсети (10.1.2.0), и для этих виртуальных машин настроен VSID 6005.

Вы также видите что-то под названием « Адрес PA », который назначается каждому хосту Hyper-V (PA 192.168.1.10 для Hyper-V Host1 и 192.168.2.20 для Hyper-V Host2). PA отвечает за управление виртуальными машинами, работающими на локальном сервере Hyper-V, и предпринимает необходимые действия для доступа к виртуальным машинам, работающим на удаленных серверах Hyper-V. PA взаимодействуют друг с другом для управления связью между виртуальными машинами клиентов. Я расскажу больше о PA в следующей части этой серии статей.

Виртуальная машина, участвующая в сетевой виртуализации Hyper-V, называется CA (Customer Address). Все виртуальные машины Blue и Red являются CA, как показано на рисунке выше.

Поскольку на обоих узлах Hyper-V работают две виртуальные машины клиента, необходима изоляция. Чтобы обеспечить изоляцию между виртуальными машинами разных клиентов, мы создали два RDID; один для виртуальных машин Blue и еще один для виртуальных машин Red. RDID известен как идентификатор домена маршрутизации, который является требованием для виртуализации сети Hyper-V.

Таким образом, в проекте реализованы следующие компоненты модуля WNV:

• Два клиента — клиент A (синие виртуальные машины) и клиент B (красные виртуальные машины).
• Два RDID — по одному для каждого клиента.
• Три виртуальные подсети с разными VSID — 10.1.1.0: 6001, 10.1.1.0: 6002 и 10.2.1.0: 6005.
• Два PA-адреса — 192.168.1.10 и 192.168.2.20
• Шесть виртуальных машин ЦС — Blue1, Blue2, Blue3, Blue4, Red1 и Red2

И общая цель конструкции HNV, показанной выше, состоит в том, чтобы убедиться, что:

• Клиенты могут использовать свои собственные IP-адреса и сетевые топологии.
• Нет необходимости вносить какие-либо изменения в топологию физической сети.
• Виртуальные машины с той же схемой IP могут работать на узлах Hyper-V.
• Виртуальные машины Customer-A могут общаться друг с другом.
• Виртуальные машины Customer-B могут взаимодействовать друг с другом.
• Ни одна из виртуальных машин Blue и Red не должна взаимодействовать друг с другом, поскольку они принадлежат разным клиентам.
• Виртуальные машины можно мигрировать в режиме реального времени между разными подсетями.

Виртуализация сети Hyper-V позволяет достичь вышеуказанной цели. Теперь давайте подробнее рассмотрим все компоненты WNV. В этой части этой серии статей мы сосредоточимся только на компоненте «RDID».

RDID: RDID, иногда называемый идентификатором домена маршрутизации, представляет собой границу домена маршрутизации, в которой виртуальные машины могут взаимодействовать друг с другом, но не могут взаимодействовать с виртуальными машинами, работающими в другом RDID. В приведенном выше дизайне есть два RDID; один RDID предназначен для виртуальных машин Blue, а другой RDID создается для виртуальных машин Red. Виртуальные машины Blue1, Blue2, Blue3 и Blue4 относятся к RDID 1, а виртуальные машины Red1 и Red2 относятся к RDID 2. RDID обеспечивает изоляцию между виртуальными машинами клиентов и является требованием для реализации виртуализации сети Hyper-V. RDID — это 128-битный GUID Windows. У каждого клиента должен быть свой RDID.

Как видите, виртуальные машины Blue1 и Red1 работают с одной и той же схемой IP. Это связано с тем, что они реализованы в разных RDID с разными VSID. RDID должен быть создан с уникальным VSID, чтобы гарантировать отсутствие конфликта IP-адресов. Вы увидите проблему конфликта IP-адресов, если не назначите VSID виртуальным машинам Red1 и Blue1 или если обе виртуальные машины используют один и тот же VSID. Поэтому просто создать RDID будет недостаточно. Вы также должны назначить уникальный VSID виртуальным машинам.

Вам нужно использовать командлет PowerShell , чтобы создать RDID для клиента. Прежде чем создавать RDID для клиента, убедитесь, что выполняются следующие утверждения:

• Ни один другой клиент, размещенный в том же общем облаке IaaS, не использует тот же RDID GUID.
• GUID RDID должен быть сгенерирован с помощью командлета SCVMM или PowerShell. Вы также можете создать GUID вручную, но это должен быть действительный 128-битный GUID Windows.
• Вы также должны получить идентификатор виртуальной подсети (VSID), который не используется ни одним другим клиентом в сети.

Ниже приведен пример RDID, созданного с помощью командлета PowerShell:

1. New-NetVirtualizationCustomerRoute -DestinationPrefix "10.1.1.0/24" -NextHop "0.0.0.0" -RoutingDomainID "{11111111-2222-3333-4444-000000006002}" -VirtualSubnetID 6002
2. New-NetVirtualizationCustomerRoute -DestinationPrefix "10.1.2.0/24" -NextHop "0.0.0.0" -RoutingDomainID "{11111111-2222-3333-4444-000000006001}" -VirtualSubnetID 6001
3. New-NetVirtualizationCustomerRoute -DestinationPrefix "10.1.2.0/24" -NextHop "0.0.0.0" -RoutingDomainID "{11111111-2222-3333-4444-000000006005}" -VirtualSubnetID 6005

Поскольку у вас есть две клиентские виртуальные машины, работающие на обоих хостах Hyper-V, вы должны создать два RDID для целей изоляции. Командлет PowerShell должен выполняться для каждой виртуальной подсети в RDID.

Первая команда создает RDID для виртуальных машин Red (Customer-A). 2-я и 3-я команды выполняются для создания еще одного RDID для виртуальных машин Blue (Customer-B). Как вы заметили, для Blue Virtual Machines выполняются две команды. Это связано с тем, что есть две виртуальные подсети с двумя VSID для виртуальных машин Blue. Поскольку команда может одновременно принимать только один VSID, вы должны выполнить команду PowerShell для каждой виртуальной подсети и VSID, используя один и тот же RDID GUID.

Совет:
Чтобы сгенерировать новый RDID GUID, вы можете использовать приведенную ниже команду командлета PowerShell:

• $NewGUID = [руководство]::NewGuid()

Примечание:
Команду необходимо выполнить на обоих узлах Hyper-V. Другими словами, все хосты Hyper-V должны знать обо всех клиентских RDID.

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

• Get-NetVirtualizationCustomerRoute | ft RoutingDomainID, VirtualSubnetID, DestinationPrefix, NextHop -auto

Рисунок 1.2: Получение конфигурации RDID на хосте Hyper-V

Как вы заметили на рисунке 1.2, команда отображает список RDID, настроенных на локальном хосте Hyper-V. Вы должны убедиться, что та же самая конфигурация возвращается при выполнении команды на других хостах Hyper-V, где работают виртуальные машины клиента.

Резюме

Во второй части этой серии статей мы увидели, как выглядит дизайн HNV. Мы также объяснили компонент RDID HNV и команды PowerShell, которые должен выполнить виртуальный администратор, чтобы создать RDID для каждого клиента на каждом узле Hyper-V.

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

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