виртуальная сеть san hyper v что это
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Настраиваем сеть в Hyper-V.
Продолжая цикл статей посвященный виртуализации, сегодня мы поговорим о настройке сети в Hyper-V. Основное внимание мы уделим теории, а именно разберем как устроены виртуальные сети и как они взаимодействуют с реальными. Потому что, как показывает практика, многие администраторы, в отсутствие простых и понятных материалов по данному вопросу, вынуждены осваивать настройку сети в Hyper-V методом «научного тыка».
С одной стороны, ничего сложного в настройке сетей для виртуальных машин нет, с другой многие начинают путаться во всех этих адаптерах, с трудом понимая, где реальный, где виртуальный, и чем они друг от друга отличаются. Постараемся внести ясность.
За настройку сетей в Hyper-V отвечает Диспетчер виртуальных коммутаторов, если мы откроем его, то увидим следующую картину:
Как видим, нам доступно создание трех типов сетей: внешней, внутренней и частной. Разберемся подробнее, для чего нужны эти сети и в чем разница между ними.
Внешняя сеть
Самый распространенный тип сети, который позволяет виртуальным машинам взаимодействовать с внешними сетями и хостом. При ее создании необходимо выбрать один из физических сетевых адаптеров, через который данная виртуальная сеть будет соединяться с внешними сетями.
Как мы уже писали, основу виртуальной сети составляет виртуальный коммутатор. При создании внешней сети, Hyper-V создает виртуальный коммутатор, к которому через виртуальные сетевые адаптеры (vNIC) подключаются как виртуальные машины, так и хост. Физический адаптер отключается от хоста и по сути становится физическим портом виртуального коммутатора, через который он подключается к внешней сети.
В этом нетрудно убедиться, после создания внешней сети на хосте появляется Адаптер Ethernet для виртуальной сети Hyper-V, на который переносятся все настройки с физического адаптера.
А в свойствах физического адаптера остался только Расширяемый виртуальный сетевой коммутатор в Hyper-V.
В случае с внешней сетью следует четко понимать, что хост, точно также как и виртуальные машины, подключается к виртуальному коммутатору через виртуальный сетевой адаптер. Физический сетевой адаптер, после создания внешней сети становится портом виртуального коммутатора, через который он подключается к внешней сети. Поэтому все сетевые настройки хоста следует производить только на виртуальном сетевом адаптере.
Также имеется возможность создания внешних сетей, изолированных от хоста, в этом случае виртуальный сетевой адаптер не создается, а физический интерфейс отключается от хоста, обслуживая только виртуальный коммутатор. Для этого при создании внешней сети необходимо снять галочку Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру.
Данная конфигурация позволяет успешно виртуализировать пограничные сетевые устройства, надежно отвязав их от внутренней сети и хоста. Например, мы можем создать две внешних сети, одна из которых будет подключена к локальной сети, вторая к интернет и осуществлять выход во внешнюю сеть через роутер на виртуальной машине, при этом и хост, и локальная сеть будут надежно изолированы от интернет, несмотря на то, что кабель внешней сети физически будет подключен к сетевому адаптеру хоста.
Внутренняя сеть
Как следует из ее названия, внутренняя сеть предназначена для подключения виртуальных машин и хоста и не предусматривает соединения с внешними сетями. При ее создании также создается виртуальный сетевой адаптер для хоста, который оказывается подключен к виртуальному коммутатору внутренней сети и должен быть сконфигурирован в соответствии с настройками виртуальной сети.
К внешней сети хост остается подключен через физический адаптер, настройки которого не затрагиваются. Данная конфигурация чаще всего используется для учебных и исследовательских целей, позволяя создавать и моделировать различной сложности сетевые конфигурации не затрагивая рабочие сети предприятия.
Внутренняя сеть c NAT
Данная возможность появилась начиная с Windows Server 2016, Hyper-V Server 2016 и Windows 10. Подробнее читайте в нашей статье: Настраиваем сеть NAT в Hyper-V
Частная сеть
Частная сеть отличается от внутренней тем, что виртуальный коммутатор может быть подключен только к виртуальным машинам и изолирован от хоста.
Данный вид сетей может быть использован также в учебных и исследовательских целей, а также для создания изолированных участков сети, например DMZ.
В этом случае связь между внешней и частной сетью будет осуществляться через одну из виртуальных машин, которая должна быть подключена к обеим сетям.
Как видим, Hyper-V дает в руки администратора весьма гибкий и мощный инструмент, позволяющий создавать весьма сложные сетевые конфигурации и управлять ими.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Подключение СХД Qsan к серверам в среде Windows Server и Hyper-V
Мы продолжаем цикл публикаций из серии How To для пользователей СХД Qsan. В данной статье пойдет речь о подключении СХД к серверам на базе Windows Server, в том числе при использовании функционала виртуализации Hyper-V.
В статье мы будем рассматривать подключения СХД Qsan с использованием блочных протоколов доступа iSCSI и Fibre Channel. Сам процесс подключения можно разделить на несколько основных этапов:
В статье приведены скриншоты настройки операционной системы Windows Server 2016/2019 с нелокализованным интерфейсом. Часть описания, не относящаяся напрямую к ОС, взята из нашего предыдущего обзора по настройке ESXi.
Физическая и логическая коммутация
Совокупность оборудования и линий связи между СХД и серверами образуют так называемую SAN сеть. Отказоустойчивое подключение участников SAN сети подразумевает постоянное наличие хотя бы одного пути между инициатором (хост) и таргетом (СХД). Т.к. СХД сейчас практически поголовно имеют минимум два контроллера, каждый сервер должен иметь связь с каждым из них. В простейшем варианте серверы подключаются к СХД напрямую. Такой режим работы называют Direct Attach. СХД Qsan поддерживают такой режим работы. В этом случае каждый сервер должен иметь двухпортовую HBA для соединения с каждым контроллером СХД. Т.е. между сервером и СХД будет 2 пути. При наличии максимального количества опциональных портов в таком режиме к СХД можно подключить до 10 серверов через iSCSI или до 8 серверов через Fibre Channel.
В большинстве случаев серверы соединяются с СХД через коммутаторы. Для большей надежности их должно быть два (в общем случае их, конечно же, может быть больше, но это они все равно делятся на две группы – фабрики). Этим выполняется защита от выхода из строя самого коммутатора, линка и порта контроллера СХД/HBA. В этом случае каждый сервер и каждый контроллер СХД подключается к каждому коммутатору. Т.е. между каждым сервером и СХД будет 4 пути (в случае двух коммутаторов).
Для Qsan параметр MTU меняется на каждом порту каждого контроллера в меню iSCSI Ports
В Windows Server параметр MTU меняется в настройках драйвера адаптера:
Control Panel\Network and Internet\Network Connections → Свойства конкретного адаптера → Configure → Advanced → Jumbo Packet (у некоторых адаптеров этот пункт может называться что-то типа Large Packets)
Для получения инструкций по изменению MTU у физических коммутаторов рекомендуем обратиться к документации конкретного производителя.
Действия на стороне СХД
Необходимые настройки на СХД можно разделить на два этапа:
Настраивать интерфейсы требуется в основном в случае использования протокола iSCSI: необходимо задать IP адреса портов на вкладке iSCSI Ports. IP адреса портов должны быть из разных подсетей, чтобы однозначно маршрутизировался трафик на стороне хоста.
В случае использования интерфейса Fibre Channel ничего настраивать, как правило, не нужно.
Далее необходимо создать пространство хранения. Сначала создается пул – группа физических накопителей, работающих совместно. Пулов в пределах СХД может быть несколько. Накопители внутри пула объединяются в соответствии с выбранным при его создании уровнем RAID, обеспечивая заданную надежность. Пулы создаются на вкладке Pools → Create Pool, где запускается пошаговый мастер.
Помимо обычных пулов Qsan поддерживает создание AutoTiering пулов при условии активации соответствующей лицензии. С принципом работы таких пулов можно ознакомиться в отдельной статье.
После создания пула(ов) необходимо создать тома (volume): Volumes → Create volumes. Также запустится пошаговый мастер создания тома.
Необходимо задать требуемый размер тома, тип тома выбирается как RAID volume. Рассмотрим их более подробно.
Заключительным этапом в настройке СХД является публикация томов для доступа к ним со стороны хостов через функционал LUN mapping → Map LUN.
Действия на стороне хоста
Первоначально необходимо один раз установить на сервере компонент Multipath IO, который обеспечивает работу многопутевого ввода/вывода. Данное действие производится через стандартный диалог Add Roles and Features
При использовании протокола iSCSI необходимо выполнить:
При использовании протокола Fibre Channel все гораздо проще: достаточно выполнить Rescan для обнаружения нового тома. В нашем примере это том с LUN доступный по 4 путям. Как и в случае с iSCSI следует убедиться, что для диска установлена политика Round Robin, при которой все доступные пути до СХД будут использоваться равномерно.
Важное замечание касательно конфигурирования MPIO. По умолчанию Windows видит дисковые устройства по отдельности, т.е. каждый путь к устройству – это отдельный диск.
Чтобы ОС «склеила» все одинаковые диски в единое устройство, необходимо в стандартной оснастке MPIO добавить новое устройство как многопутевое. Для iSCSI устройств устанавливается отдельное разрешение. По окончании настройки потребуется перезагрузить сервер. Данную настройку необходимо произвести однократно для каждой СХД. После чего все вновь презентованные диски будут опознаваться ОС как многопутевые.
В случае использования кластера из нескольких хостов Windows Server, действия, описанные выше, необходимо повторить на каждом из хостов. После чего диски, появившиеся в системе, можно добавлять в дисковые ресурсы кластера.
В рамках этой статьи были рассмотрены преимущественно базовые операции, необходимые для подключения серверов Windows Server к СХД Qsan. Для получения более полной информации настоятельно рекомендуется ознакомиться с руководствами пользователей, предоставляемыми обоими вендорами.
Виртуализация сети в Hyper-V. Концепция
В Windows Server 2012 появилась технология виртуализации сети (Network Virtualization, NV), обеспечивающая возможность виртуализации на принципиально новом уровне – уровне сетевого сегмента. В отличие от привычной серверной виртуализации NV позволит вам виртуализовать IP-подсети и полностью скрыть от виртуальных машин (ВМ) и приложений внутри ВМ реальную IP-адресацию, используемую в вашей инфраструктуре. При этом ВМ по-прежнему могут взаимодействовать между собой, с другими физическими хостами, с хостами в других подсетях.
С технологической точки зрения виртуализация сети представляет собой довольно сложный механизм, поэтому сделать более-менее полный обзор этой технологии в рамках одного поста, пожалуй, не удастся. Сегодня обсудим концепцию и архитектуру, в следующем посте я сосредоточусь на настройке NV, затем отдельно поговорим об организации внешнего доступа к ВМ, запущенным в виртуализованной сети.
Начнем с основополагающего вопроса: «Для чего нужна виртуализация сети?»
Для чего нужна виртуализация сети?
В случае серверной виртуализации с небольшими оговорками ОС внутри ВМ работает так, как если бы была установлена на физический сервер и являлась единственной ОС на этом оборудовании. Подобная абстракция позволяет запускать несколько изолированных экземпляров виртуальных серверов на одном физическом. По аналогии виртуализация сети приводит к тому, что виртуальная, а точнее в данном контексте виртуализованная сеть, функционирует так, как если бы она являлась физической сетью. Соответственно, данный уровень виртуализации позволяет создавать и использовать несколько виртуальных сетей, возможно с перекрывающимися или даже полностью совпадающими пространствами IP-адресов, на одной физической сетевой инфраструктуре. И эта сетевая инфраструктура, вообще говоря, может включать в себя произвольное количество физических серверов и сетевого оборудования (см. рис. ниже).
На приведенном рисунке виртуальные машины из синей сети и красной сети, принадлежащих разным департаментам или организациям, могут использовать одни и те же IP-адреса, могут быть запущены на одном и том же или разных физических хостах, но при этом с одной стороны, они будут полностью изолированы друг от друга, и, с другой стороны, при этом будут безо всяких проблем взаимодействовать с другими сетевыми объектами (реальными или виртуальными) своего департамента или своей организации. Отсюда вытекают назначение технологии NV, преимущества и основные сценарии ее применения.
Большая гибкость в размещении ВМ в пределах ЦОД
NV предоставляет определенную свободу при размещении ВМ в рамках ЦОД. В частности, размещение ВМ предполагает настройку IP-адреса, соответствующего физическому сегменту сети, и настройку VLAN для обеспечения изоляции. Коль скоро NV допускает сосуществование на одном хосте ВМ с совпадающими IP-адресами, мы более не связаны применяемой в ЦОД схемой IP-адресации и не упираемся в ограничения, накладываемые VLAN.
Упрощенный перенос ВМ в облако
Поскольку при использовании виртуализации сети IP-адрес и конфигурация ВМ остаются неизменными, это значительно упрощает процесс переноса ВМ в соседний ЦОД организации, в облако хостера или публичное облако. И клиенты приложения, и ИТ-администраторы продолжают использовать свои инструменты для взаимодействия с ВМ/приложением без переконфигурации.
Динамическая миграция (Live Migration) за пределы подсети
Динамическая миграция ВМ ограничена пределами IP-подсети (или VLAN-ами). Если мигрировать ВМ в другую подсеть, потребуется перенастройка IP внутри гостевой ОС со всем вытекающими последствиями. Однако если динамическая миграция выполняется между двумя хостами с Windows Server 2012 с включенной NV, то хосты могут располагаться в различных сегментах физической сети, при этом виртуализация сети обеспечит непрерывность сетевых коммуникаций перемещаемой ВМ.
Повышенная утилизация ресурсов физических хостов и сетей
Отсутствие зависимости от IP-адресации и VLAN-ов позволяет более равномерно загружать физические хосты и более эффективно утилизировать имеющиеся ресурсы. При этом следует отметить, что NV поддерживает VLAN, и вы можете сочетать оба способа изоляции, например, изолировав трафик NV в выделенном для этих целей VLAN-не.
Концепция Hyper-V Network Virtualization
В процессе сетевого взаимодействия ВМ формирует пакет с адресами отправителя и получателя из пространства CA. Такой пакет покидает ВМ и хостом Hyper-V упаковывается в пакет с адресами отправителя и получателя из пространства PA. Адреса PA определяются на основе таблицы политики виртуализации. После этого пакет передается по физической сети. Хост Hyper-V, получивший пакет, на основе все той же таблицы политики виртуализации выполняет обратную процедуру: извлекает исходный пакет, определяет ВМ-получателя и перенаправляет исходный пакет с адресами CA нужной ВМ.
Таким образом, виртуализация сети, в конечном счете, сводится к виртуализации адресов, используемых виртуальными машинами. В свою очередь, виртуализация адресов в Hyper-V Windows Server 2012 возможна с помощью двух механизмов: Generic Routing Encapsulation и IP Rewrite. Рассмотрим кратко каждый их них.
Generic Routing Encapsulation
В первом механизме исходный пакет c CA-адресами инкапсулируется в структуру GRE (Generic Routing Encapsulation, см. RFC 2890), которая упаковывается в IP-пакет с необходимыми PA-адресами. В заголовок GRE добавляется также уникальный идентификатор виртуальной подсети (Virtual Subnet ID, поле «Ключ GRE» на рис.), которой принадлежит исходный пакет, и МАС-адреса виртуальных сетевых адаптеров ВМ отправителя и получателя.
Идентификатор подсети позволяет хосту-получателю правильно определить ВМ, для которой предназначен пакет, даже в случае возможного совпадения CA-адресов в ВМ разных заказчиков. Вторая важная особенность данного механизма заключается в том, что вне зависимости от количества запущенных на хосте ВМ достаточно одного PA-адреса для передачи пакетов от любых ВМ. Это существенным образом влияет на масштабируемость решения при использовании GRE-механизма виртуализации адресов. Наконец надо отметить, что описанная схема полностью совместима с имеющимся сетевым оборудованием и не требует какого-либо обновления сетевых адаптеров, коммутаторов или маршрутизаторов.
Однако в перспективе было бы совсем не лишним, чтобы свитч или роутер могли анализировать поле Virtual Subnet ID пакета, и администратор мог бы настраивать соответствующие правила для коммутации или маршрутизации пакетов на основе этого поля. Или например, чтобы все задачи, связанные с упаковкой-распаковкой GRE, брал на себя сетевой адаптер. С этой целью Microsoft совместно с партнерами разработали стандарт NVGRE – Network Virtualization using Generic Routing Encapsulation, находящийся сейчас в стадии IETF Draft. В частности, в рамках этого стандарта регламентируется 24-битное поле Tenant Network Identifier (TNI) для хранения идентификатора подсети, тип протокола 0x6558, указывающий на NVGRE-пакет, и другие нюансы.
IP Rewrite
Второй механизм по своей идеологии несколько проще. Каждому CA-адресу ставится в соответствие уникальный PA-адрес. Когда пакет покидает ВМ, хост Hyper-V заменяет в заголовке IP-пакета CA-адреса на PA-адреса и посылает пакет в сеть. Принимающий хост выполняет обратную замену адресов и доставляет пакет ВМ. Как следует из описанного алгоритма, на каждом физическом хосте с ролью Hyper-V необходимо сконфигурировать столько PA-адресов, сколько CA-адресов используется во всех запущенных на данном хосте виртуальных машинах, использующих виртуализацию сети.
Инкапсуляция пакетов с помощью GRE требует дополнительных накладных расходов. Поэтому для сценариев с высокими требованиями к пропускной способности канала, например, для ВМ активно использующей 10Gbps-адаптер, как и раз и рекомендуется IP Rewrite. Для большинства же остальных случаев оптимальным является механизм GRE. Ну а с появлением оборудования, поддерживающего NVGRE, этот механизм не будет уступать IP Rewrite и в производительности.
Сеть заказчика и виртуальная подсеть
В терминологии Hyper-V Network Virtualization заказчик – это «владелец» группы ВМ, развернутых в ЦОД. На практике, если речь идет о ЦОД-е провайдера хостинговых услуг, таким заказчиком может быть какая-либо компания или организация. Если говорим о частном облаке, то заказчиком, как правило, выступает департамент или отдел организации. В любом случае заказчик может владеть одной или несколькими сетями (Customer Network), и каждая такая сеть состоит из одной или нескольких виртуальных подсетей (Virtual Subnet).
Применение этих двух понятий позволяет заказчику переносить свою сетевую топологию в облако. На рис. ниже изображены две сети компании «Синие» — сеть R&D и сеть отдела продаж. Изначально эти сети изолированы и не должны взаимодействовать между собой. Поскольку при переносе в среду Hyper-V Network Virtualization этим сетям присвоены различные RDID, ВМ этих сетей не могут «видеть» друг друга. При этом, например, ВМ из виртуальных подсетей 1, 2 и 3 сети R&D могут обмениваться пакетами.
Архитектура Hyper-V Network Virtualization
NV доступна только в Windows Server 2012.
На хостах с Hyper-V Network Virtualization должна поддерживаться политика виртуализации, в которой собственно задается и хранится информация о пространствах CA и PA, идентификаторах RDID и VSID, применяемых механизмах виртуализации адресов. Windows Server 2012 содержит набор программных интерфейсов (API), с помощью которых ПО может управлять всеми аспектами NV. Таким управляющим ПО в самом простом случае могут быть скрипты PowerShell, в промышленном сценарии эту роль выполняет System Center 2012 Virtual Machine Manager SP1 (VMM). Обращаю внимание, что именно с выходом SP1 в System Center 2012 появилась поддержка Windows Server 2012, а стало быть и NV.
Настройки, заданные в политике виртуализации, непосредственно применяются драйвером-фильтром уровня NDIS (Network Driver Interface Specification), называемым Windows Network Virtualization (WNV). Фильтр WNV располагается ниже Hyper-V Extensible Switch. Это означает, что коммутатор Hyper-V и все его расширения (если таковые имеются) работают с CA-адресами и ничего не знают о PA-адресах. Однако VSID-ы доступны коммутатору и расширениям, поэтому Hyper-V Extensible Switch способен различать, например, CA-адреса 10.0.0.5, принадлежащие разным заказчикам.
Если для ВМ включается виртуализация сети, то для портов Hyper-V Extensible Switch, к которым подключены виртуальные сетевые адаптеры этой ВМ, гипервизор включает списки управления доступом (Access Control List, ACL). Подробнее об ACL я рассказывал здесь. В ACL указывается VSID виртуальной подсети, которой принадлежит ВМ. Любые пакеты, приходящие на данный порт свитча, с VSID, отличным от заданного в ACL, игнорируются.
Приняв эту логику во внимание, перемещение пакетов выглядит следующим образом. Исходящий от ВМ пакет через порт Hyper-V Extensible Switch попадает в фильтр WNV, который анализирует политику виртуализации NV и применяет к пакету необходимые операции (замена IP-адреса или упаковка в GRE), после чего пакет отправляется в сеть.
На принимающей стороне входящий пакет попадает в фильтр WNV, который анализирует политику виртуализации NV. Если входящий пакет – пакет GRE, фильтр считывает из GRE-заголовка поле VSID, извлекает исходный IP-пакет и передает его вместе с VSID на тот порт Hyper-V Extensible Switch, к которому подключен vNIC виртуальной машины с CA-адресом, соответствующим адресу получателя в заголовке исходного IP-пакета. Если переданный VSID совпадает с VSID в ACL данного порта, свитч передает пакет виртуальной машине. Если используемый механизм виртуализации – IP Rewrite, фильтр на основе информации из политики виртуализации меняет PA-адреса в пакете на CA-адреса, все по тем же парам PA- и CA-адресов определяет VSID и пакет с уже CA-адресами вместе с VSID направляет на соответствующий порт Hyper-V Extensible Switch. Если переданный VSID совпадает с VSID в ACL данного порта, свитч передает пакет виртуальной машине.
Описанная логика применяется, когда пакет передается между ВМ, расположенными на одном или разных хостах с Windows Server 2012 и поднятой ролью Hyper-V. Ситуация несколько усложнится, если пакет из ВМ, в которой, например, запущено некое бизнес-приложение, должен добраться до рабочей станции с клиентской частью этого бизнес-приложения. В этом случае нам потребуется настроить Hyper-V Network Virtualization Gateway, о чем мы поговорим отдельно.