Что нужно знать о программно определяемой сети в Hyper-V (часть 3)

• Что нужно знать о программно определяемой сети в Hyper-V (часть 2)

Введение

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

Типы сетей

Первая концепция, которую вам необходимо понять, чтобы понять программно-определяемую сеть для виртуальных машин Hyper-V, заключается в том, что программно-определяемая сеть использует три разных типа сети. Первый тип сети — это физическая сеть. Физическая сеть состоит из физического сетевого оборудования, которое обеспечивает подключение к физическим устройствам в вашей сети.

Второй тип используемой сети — это виртуальная сеть Hyper-V. Виртуальная сеть Hyper-V должна быть знакома всем, кто имеет опыт настройки виртуальных машин Hyper-V.

Виртуальная сеть Hyper-V основана на использовании виртуального коммутатора. Существует три различных типа виртуальных коммутаторов: внешние, внутренние и частные. Ради этого обсуждения я собираюсь сосредоточиться исключительно на внешних виртуальных коммутаторах, поскольку они являются наиболее часто используемым типом виртуального коммутатора.

Внешний виртуальный коммутатор привязан к физическому сетевому адаптеру на хост-сервере. Виртуальные машины не подключаются напрямую к физическому сетевому адаптеру. Вместо этого они подключаются к виртуальному коммутатору, а виртуальный коммутатор передает пакеты между виртуальными машинами и физической сетью.

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

Третий тип сети, который используется в программно-определяемой сети, — это логическая сеть. Логические сети находятся где-то посередине между виртуальными сетями и физическими сетями. Логические сети создаются с помощью System Center Virtual Machine Manager и обычно имитируют базовую физическую сеть. Логические сети позволяют иметь уровень абстракции от физической сети.

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

Конечно, это поднимает вопрос о том, как сети, использующие общее физическое оборудование, могут быть надежно изолированы друг от друга. Как я объяснял в первой статье этой серии, в логической изоляции нет ничего нового. Виртуальные локальные сети десятилетиями обеспечивали изоляцию, определяя виртуальные сети с помощью идентификатора виртуальной локальной сети.

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

Около 20 лет назад я решил построить домашнюю сеть. В то время я знал, что хочу использовать TCP/IP в своей сети, но я был новичком в TCP/IP и не совсем понимал, как работает назначение IP-адресов. Поскольку я не мог понять, где я должен был получить адреса для использования в своей сети, я выбрал случайное адресное пространство.

Как бы странно это ни звучало, я до сих пор использую выбранное адресное пространство. Я думаю, что просто никогда не было подходящего времени для переназначения всех адресов в моей сети, поэтому я продолжал использовать адресное пространство, которое выбрал так давно.

Теперь здесь все становится интереснее. Мое случайно выбранное адресное пространство фактически оказалось принадлежащим интернет-провайдеру во Франции. Несмотря на это, я все еще могу использовать его, не создавая проблем ни себе, ни законному владельцу адресного пространства. Так почему же?

Это потому, что моя домашняя сеть находится в изолированной подсети. Конечно, у меня есть подключение к Интернету, но мой маршрутизатор скрывает адреса, которые я использую внутри, от внешнего мира. Мой провайдер назначил мне статический IP-адрес, а я, в свою очередь, назначил этот адрес своему маршрутизатору. Мой маршрутизатор действует как устройство NAT, которое облегчает связь между моей частной сетью и Интернетом. Точно такой же принцип применялся бы, если бы я использовал частное адресное пространство, такое как 192.168.0.x.

Итак, какое отношение все это имеет к Hyper-V и программно-определяемым сетям? Что ж, как я объяснил, я могу использовать набор адресов в своей частной сети, которые мне действительно не следует использовать, потому что эти адреса ограничены изолированной подсетью. Та же концепция применяется к программно-определяемым сетям Hyper-V. Адресные пространства изолированы внутри виртуальных подсетей. Вот почему сети арендаторов могут использовать перекрывающиеся адресные пространства, не создавая проблем друг для друга.

Так как же можно создать изолированные и, тем не менее, потенциально перекрывающиеся подсети, использующие общий набор оборудования? Ответ заключается в том, что виртуализация сети Hyper-V использует инкапсуляцию.

Процесс инкапсуляции на самом деле мало чем отличается от того, что используется в виртуальных частных сетях (VPN). VPN используют инкапсуляцию пакетов как способ безопасной передачи частного сетевого трафика через Интернет. Когда пакет необходимо отправить через VPN, конечная точка, обращенная к Интернету, добавляет уровень инкапсуляции, который позволяет отправить пакет через Интернет на удаленный VPN-шлюз. Получив такой пакет, VPN-шлюз снимает инкапсуляцию и пересылает пакет на хост в удаленной сети.

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

Microsoft предоставляет командлет PowerShell под названием Get-NetVirtualizationLookupRecord. Этот командлет возвращает несколько различных фрагментов информации, но в результатах есть несколько атрибутов, которые особенно интересны.

Первое, на что вы можете обратить внимание при просмотре результатов, — это имя виртуальной машины (VMName) и атрибуты Customer Address. Эти атрибуты содержат имя виртуальной машины и IP-адрес, назначенный виртуальной машине.

Однако более интересным является атрибут VirtualSubnetID. Этот атрибут отображает восьмизначное число, однозначно идентифицирующее подсеть. Виртуальные машины с общим идентификатором виртуальной подсети используют общую виртуальную сеть. Если две виртуальные машины имеют разные идентификаторы виртуальной подсети, они находятся в разных виртуальных сетях. Виртуальные машины с разными идентификаторами виртуальных подсетей могут использовать один и тот же адрес клиента (IP-адрес, который арендатор назначает виртуальной машине), поскольку виртуальные сети изолированы друг от друга.

Между прочим, в средах с несколькими арендаторами каждому арендатору назначается уникальный идентификатор клиента. Это позволяет отслеживать, кому принадлежит каждая виртуальная сеть. Атрибут CustomerID предоставляется через Get-NetVirtualizationLookupRecord. Я планирую более подробно рассмотреть этот командлет позже в этой серии.

Вывод

В этой статье я объяснил, что виртуализация сети основана на использовании инкапсуляции. В следующей статье этой серии я планирую объяснить роль шлюза HNV и System Center Virtual Machine Manager.

• Что нужно знать о программно определяемой сети в Hyper-V (часть 2)