Департамент образования Вологодской области Бюджетное профессиональное образовательное учреждение Вологодской области «Великоустюгский многопрофильный колледж» Курсовая работа (проект) Учебный предмет, курс, дисциплина (модуль): «эксплуатация объектов сетевой инфраструктуры» на тему: «служба Hyper-v windows server » Выполнил студент: Кочкин Дмитрий Вячеславович Специальность 09.02.02 «Компьютерные сети» 4 курса, 941 группы Проверил преподаватель: Барский Игорь Александрович Работа проверена: ____________ Допущена (не допущена) к защите Оценка после защиты: ___________ Подпись руководителя: ___________ г. Великий Устюг Оглавление «служба Hyper-v windows server » ......................................................................................................... 1 Введение .................................................................................................................................................. 3 Архитектура .................................................................................................................................................. 4 Архитектура построения Hyper-V ........................................................................................................... 4 Архитектура виртуализации сетей Hyper-V ........................................................................................... 5 Hyper-V в Windows Server 2016 .................................................................................................................. 6 Сравнение Hyper-V с другими гипервизорами .......................................................................................11 Технические сведения о виртуализации сети Hyper-V в Windows Server 2016 ...................................12 Переключение и маршрутизация в виртуализации сети Hyper-V.........................................................14 Высокая доступность сетевого контроллера ..........................................................................................19 Конфигурация Hyper-V ..............................................................................................................................20 Введение Когда мы говорим о виртуализации сервера, важно отметить разницу виртуализацией хоста и виртуальной машины. Хост сервер является важной птицей, причём (обычно) физической платформой, которая предоставляет все необходимые ресурсы виртуальным машинам меньшего размера. Существует два основных игрока в категории таких виртуальных хостов. Компания с названием VMware популярна на обоих рынках, и персонального и корпоративного уровней и, конечно, Microsoft с собственным Hyper-V. Поскольку я живу в мире Microsoft, и в данной книге всё вращается вокруг Microsoft, мы собираемся сосредоточиться на возможностях виртуализации, предоставляемых Microsoft Hyper-V внутри их новой операционной системы Windows Server 2016. Наилучшей частью в Hyper-V является то, что он доступен любому, кто работает с операционной системой Windows Server, поэтому даже если вы не применяете технологию виртуализации в своём сегодняшнем бизнесе, при помощи всего пары кликов мышью вы вероятно могли бы начать. Более того, если у вас сегодня имеется предприятие VMware, не забудьте проверить самые последние предложения от Microsoft относящиеся к вашей миграции на Hyper-V. Редакция Windows Server 2016 выдаётся с некоторыми значительными скидками и стимулами для компаний, которые желают переключиться на Hyper-V Цель: Изучить службу Hyper-v windows server Задачи: 1) Обзор архитектуры Hyper-v 2)узнать про службу Hyper-v в windows server 3)Сравнить Hyper-v с другими гипервизорами 4) изучить переключение и маршрутизацию в виртуализации сетей Hyper-V 1. Архитектура Архитектура построения Hyper-V Hyper-V включает архитектуру на основе гипервизора типа 1. Гипервизор выполняет виртуализацию процессоров и памяти и предоставляет механизмы для стека виртуализации в корневом разделе для управления дочерними секциями (виртуальными машинами) и предоставления таких служб, как устройства ввода-вывода, на виртуальные машины. Корневой раздел владеет и имеет прямой доступ к физическим устройствам ввода-вывода. Стек виртуализации в корневом разделе предоставляет диспетчер памяти для виртуальных машин, API-интерфейсов управления и виртуализированных устройств ввода-вывода. Он также реализует эмулированные устройства, такие как встроенный контроллер диска IDE и порт ввода PS/2, и поддерживает синтетические устройства Hyper-V для повышения производительности и снижения издержек. Архитектура ввода-вывода, специфичная для Hyper-V, состоит из поставщиков служб виртуализации (VSPs) в корневом разделе и клиентах службы виртуализации (VSC) в дочернем разделе. Каждая служба предоставляется как устройство через VMBus, которое выступает в качестве шины ввода-вывода и обеспечивает высокую производительность обмена данными между виртуальными машинами, использующими такие механизмы, как общая память. Диспетчер Plug and Play операционной системы на виртуальной машине перечисляет эти устройства, включая VMBus, и загружает соответствующие драйверы устройств (клиенты виртуальных служб). В этой архитектуре также доступны службы, отличные от операций ввода-вывода. Начиная с Windows Server 2008, операционная система включает просветлений, чтобы оптимизировать свое поведение при работе на виртуальных машинах. Эти преимущества включают снижение затрат на виртуализацию памяти, повышение многоядерную масштабируемость и уменьшение фонового использования ЦП операционной системой на виртуальной машине. Архитектура виртуализации сетей Hyper-V В Windows Server 2016 HNVv2 реализуется с помощью виртуальной платформы фильтрации Azure (VFP), которая является расширением фильтрации NDIS в коммутаторе Hyper-V. Ключевым понятием VFP является то, что подсистема обработки совпадений с внутренним интерфейсом API, предоставляемым агенту узла SDN для программирования сетевой политики. Сам агент узла SDN получает сетевую политику от сетевого контроллера по каналам связи ОВСДБ и WCF Подсистемамми. Не только политика виртуальной сети (например, сопоставление CA-PA) запрограммирована с помощью VFP, но и дополнительной политики, такой как ACL, QoS и т. д. Иерархия объектов для расширения "переадресация vSwitch и VFP" является следующей: vSwitch Управление внешним сетевым адаптером Разгрузка аппаратных карт Глобальные правила пересылки Порт Уровень перенаправления для перекрестного закрепления Списки пробелов для сопоставлений и пулов NAT Унифицированная таблица потока Уровень VFP Таблица Flow Группа Правило Правила могут ссылаться на пробелы В VFP создается слой для каждого типа политики (например, виртуальная сеть), который является универсальным набором таблиц правил или потоков. Она не имеет никаких встроенных функций, пока для реализации таких функций не назначены определенные правила. Каждому слою назначается приоритет, и уровни назначаются порту по возрастанию приоритета. Правила организованы в группы в основном в зависимости от направления и семейства IP-адресов. Группам также назначается приоритет и не более, одно правило из группы может соответствовать заданному потоку. Логика пересылки для vSwitch с расширением VFP выглядит следующим образом: Обработка входящих данных (входящий трафик с точки зрения пакета, поступающего в порт) Ссылая Обработка исходящих данных (исходящий с точки зрения пакета, который выходит из порта) VFP поддерживает внутреннюю пересылку MAC для типов инкапсуляции NVGRE и ВКСЛАН, а также для внешних пересылок на основе MAC VLAN. Расширение VFP имеет медленный и быстрый путь для обхода пакетов. Первый пакет в последовательности должен проходить все группы правил на каждом уровне и выполнять поиск правил, который является дорогостоящей операцией. Однако после регистрации последовательности в таблице унифицированного потока со списком действий (на основе соответствующих правил) все последующие пакеты будут обрабатываться на основе записей таблицы унифицированного потока. Политика HNV запрограммирована агентом узла. Для каждого сетевого адаптера виртуальной машины настраивается IPv4-адрес. Существуют АК, используемые для связи виртуальных машин друг с другом, они поступают в IP-пакетах из этих виртуальных машин. HNV инкапсулирует кадр ЦС в кадре PA на основе политик виртуализации сети, хранящихся в базе данных агента узла. 2.Hyper-V в Windows Server 2016 Технология виртуализации Microsoft Hyper-V была усовершенствована в Windows Server 2016 несколькими способами, рассмотрим некоторые из этих усовершенствований. Во-первых, появилась новая функция, под названием «Группы виртуальных машин», и новая межплатформенная виртуальная машина (VM), с возможностью мобильности платформы. Вовторых, новая конфигурационная версия VM, новый формат конфигурационного файла и новая поддержка использования контрольных точек в производственных средах. И наконец, новые возможности добавления и удаления горячих сетевых адаптеров и памяти, которые теперь поддерживаются ролью Hyper-V. Масштабируемость Windows Server 2016 предоставляет новую масштабируемость для виртуализации любой, без исключения, рабочей нагрузки. В следующей таблице показано сравнение пути, пройденного от Windows Server 2012 / 2012R2 до настоящего времени: Windows Server Описание 2012/2012 R2, 2016 Standard, и Standard и Центр Центр обработки обработки данных данных Поддержка физической (основной) памяти Windows Server До 4 Тб на физический сервер До 24 ТБ на физический сервер (6x) Поддержка физических (хост) До 320 LP логических До 512 LP процессоров Поддержка До 1 ТБ на VM памяти VM Поддержка До 64 VP До 16 Тбайт на VM (16x) До 240 VP виртуальных (виртуальных точек) на (виртуальных точек) процессоров VM VM Вложенная виртуализация на VM (3.75x) Вложенная виртуализация позволяет запускать Hyper-Vв Windows Server 2016, в качестве гостевой виртуальной машины, работающей на HyperV! Она предоставляет расширения аппаратной виртуализации для ВМ. Для запуска этой технологии есть некоторые требования: Windows Server 2016 или Windows 10 Минимум 4 ГБ ОЗУ для хоста Процессоры Intel VT-x (на момент написания статьи) Поддержка EPT Вложенная VM, на которой выполняется Hyper-V, должна отключать динамическую память Чтобы включить вложенную виртуализацию, сначала на хосте, для созданной, но ещё не включённой вами виртуальной машины, вы должны запустить следующую команду Windows PowerShell. Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true Если вы хотите предоставить параметры подключения гостевых виртуальных машин, которые будут находиться внутри вашей вложенной машины Hyper-V, у вас есть два варианта. Первый вариант - включить спуфинг MAC для гостевой виртуальной машины. Это позволит гостевым виртуальным машинам отправлять трафик по сети. Чтобы включить спуфинг MAC-адресов на главном коммутаторе Hyper-V, используйте следующую команду: Get-VMNetworkAdapter -VMName <VMName> | Set-VMNetworkAdapter MacAddressSpoofing On Второй вариант - NAT. На вложенных виртуальных машинах Hyper-V, с помощью следующих команд, вам нужно включить NAT: new-vmswitch -name VmNAT -SwitchType Internal New-NetNat –Name LocalNAT –InternalIPInterfaceAddressPrefix “192.168.100.0/24” Когда это сделано, необходимо назначить IP-адрес для нового внутреннего адаптера. По существу, это будет адрес шлюза для виртуальных машин, работающих под вложенным Hyper-V. Для этого используйте такие команды Windows PowerShell: get-netadapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress 192.168.100.1 -AddressFamily IPv4 -PrefixLength 24 Каждая вложенная гостевая VM должен иметь настроенный IP-адрес и заданный следующим образом шлюз: get-netadapter "Ethernet" | New-NetIPAddress -IPAddress 192.168.100.2 DefaultGateway 192.168.100.1 - AddressFamily IPv4 -PrefixLength 24 Службы интеграции Обновления служб интеграции для гостевых ОС Windows распространяются через центр обновления Windows. Для поставщиков услуг и частных «облачных» хостов это позволяет контролировать применение владельцами виртуальных машин обновлений. Теперь арендаторы могут обновлять свои виртуальные машины Windows (все обновления, включая службы интеграции), используя один метод. Усовершенствования в диспетчере Hyper-V В диспетчере Hyper-V есть некоторые новые усовершенствования. Давайте взглянем на них: Поддержка альтернативных учётных данных. Теперь, в диспетчере Hyper-V, при подключении к другому Windows Server 2016 или удалённому хосту Windows 10, можно использовать другой набор учётных данных. А также, чтобы облегчить последующий вход, вы можете сохранить эти учётные данные. Управление более ранними версиями. С помощью диспетчера Hyper-V Windows Server 2016 и Windows 10, вы можете управлять компьютерами под управлением Hyper-V Windows Server 2012, Windows 8, Windows Server 2012 R2 и Windows 8.1. Обновление протокола управления. Диспетчер Hyper-V был обновлён для коммуникации с удалёнными хостами Hyper-V. Для этого используется, разрешающий проверку подлинности CredSSP, Kerberos или NTLM, протокол веб-служб управления (WS-MAN). Когда вы, для подключения к удалённому хосту Hyper-V, используете CredSSP, вы можете сделать живую миграцию, без включения ограниченного делегирования в Active Directory. А также, инфраструктура на основе WS-MAN упрощает настройку хоста для удалённого управления. WS-MAN подключается через открытый по умолчанию порт 80. Защита ресурсов хоста Одной из проблем с виртуализацией, всегда была борьба за то, чтобы ВМ не использовала больше своей доли ресурсов. Это чрезмерное использование ресурсов, может повлиять на производительность основной системы и гостевой ВМ. По умолчанию этот мониторинг и защита выключены. Чтобы включить их, выполните следующее: Set-VMProcessor -EnableHostResourceProtection $true Включится процесс мониторинга, который сканирует чрезмерное использование и будет ограничивать ресурсы любой виртуальной машины. Подключение в режиме ожидания При инсталляции на компьютер роли Hyper-V, которая использует модель питания Always On/Always Connected (AOAC), теперь доступно состояние питания Connected Standby. Назначение устройства Используя эту функцию, вы можете дать VM прямой и эксклюзивный доступ к некоторым PCIe аппаратным устройствам. Использование этого устройства обходит стек виртуализации Hyper-V, что приводит к более быстрому доступу. Windows PowerShell Direct Windows PowerShell Direct даёт вам возможность запускать на виртуальной машине команды Windows PowerShell с хоста. Windows PowerShell работает между хостом и VM. Это означает, она не нуждается в сети или требованиях к брандмауэру, и работает независимо от конфигурации удалённого управления. Windows PowerShell Direct работает подобно удалённому Windows PowerShell, но не требует подключения к сети. Для подключения к виртуальной машине с хоста, используйте следующий командлет Enter-PSSession: Enter-PSSession -VMName <VMName> У вас запросят учётные данные, а затем, вы в этом сеансе PSSession, сможете управлять виртуальной машиной. Командлет Invoke-Command был обновлён для выполнения подобных задач. Например, вы можете выполнить скрипт из хоста в виртуальную машину, как показано здесь: Invoke-Command -VMName <vmname> -FilePath C:\Scripts\MyTestScript.ps1 3.Сравнение Hyper-V с другими гипервизорами Сравнение Hyper-V и KVM KVM (или Kernel-based Virtual Machine) является технологией Red Hat и в отличие от гипервизора Hyper-V, KVM является продуктом с открытым исходным кодом. Hyper-V является более дорогим решением и пользуется спросом в первую очередь у более крупных проектов. Hyper-V считается более стабильным и надежным решением, чем KVM. Сравнение Hyper-V и VMWare Результаты тестов показывают, что основной конкурент Hyper-V — гипервизор VMWare vSphere. Он превосходит Hyper-V в показателях производительности, но уступает в плане масштабируемости. Большим преимуществом VMWare vSphere является его независимость, поскольку наличие операционной системы не является обязательным для управления всеми компонентами виртуализации. Что касается стоимости реализации, то здесь Microsoft утверждает, что их платформа дешевле, в то время как пользователи и специалисты полагают, что в некоторых случаях именно VMWare может оказаться более выгодным продуктом с экономической точки зрения. Сравнение Hyper-V и XEN XENServer, так же, как и KVM, является программным продуктом с открытым исходным кодом. XEN значительно уступает в популярности продукту от Microsoft. XENServer обладает повышенной безопасностью, но, как можно судить по мнениям специалистов, он не так удобен для пользователя, как гипервизор от Microsoft. Сравнение Hyper-V и OVZ К возможным недостаткам OpenVZ, пожалуй, можно отнести тот факт, что гипервизор OVZ, в отличие от Hyper-V, в качестве гостевых операционных систем поддерживает только системы Linux. В пассив OpenVZ также можно записать общий дисковый кэш и виртуальную память с другими виртуальными серверами, развернутыми на данном физическом сервере. В плане легкости администрирования OpenVZ опережает конкурента от Microsoft. Что касается стоимости готовых решений, то здесь Hyper-V также уступает (т.е. дороже) OpenVZ. Технические сведения о виртуализации сети Hyper-V в Windows Server 2016 Виртуализация серверов позволяет нескольким серверам работать одновременно на едином физическом узле; при этом указанные серверы остаются взаимно изолированными. По существу, каждая виртуальная машина работает как единственный сервер на данном физическом компьютере. Виртуализация сети обеспечивает аналогичную возможность, при которой несколько виртуальных сетей (потенциально с перекрывающимися IP-адресами) выполняются в одной и той же физической сетевой инфраструктуре, и каждая виртуальная сеть работает так, как если бы это единственная виртуальная сеть, работающая в общей сетевой инфраструктуре. Концепции виртуализации сетей Hyper-V В виртуализации сети Hyper-V (HNV) пользователь или клиент определяется как "владелец" набора IP-подсетей, развернутых на предприятии или в центре обработки данных. Клиент может быть организацией или предприятием с несколькими подразделениями или подразделениями в частном центре обработки данных, которым требуется изоляция сети, или клиент в общедоступном центре управления данными, размещенном в поставщике услуг. Каждый клиент может иметь одну или несколько виртуальных сетей в центре обработки данных, а каждая виртуальная сеть состоит из одной или нескольких виртуальных подсетей. Существует две реализации HNV, которые будут доступны в Windows Server 2016: HNVv1 и HNVv2. HNVv1 HNVv1 совместим с Windows Server 2012 R2 и System Center 2012 R2 Virtual Machine Manager (VMM). Конфигурация для HNVv1 зависит от управления WMI и командлетов Windows PowerShell (с помощью System Center VMM) для определения параметров изоляции и адреса клиента (CA) — сопоставления виртуальной сети с физическим адресом (PA) и маршрутизации. В HNVv1 в Windows Server 2016 не были добавлены дополнительные функции, и новые функции не планируется. Установка Teaming и HNV v1 несовместима платформой. o чтобы использовать шлюзы HA NVGRE, пользователи должны либо использовать команду LBFO, либо не какую-либо команду. Или o использовать развернутые шлюзы сетевого контроллера с параметром "настроить объединенный коммутатор". HNVv2 В HNVv2 включено значительное количество новых функций, которое реализуется с помощью расширения переадресации платформы виртуальных фильтров Azure (VFP) в коммутаторе Hyper-V. HNVv2 полностью интегрирован с Microsoft Azure Stack, который включает новый сетевой контроллер в стеке программно-определяемой сети (SDN). Политика виртуальной сети определяется через сетевой контроллер Майкрософт с помощью API-интерфейса RESTful обмена (NetBIOS) и подключен к агенту узла через несколько подсистемамми ИНТЕФАЦЕС (ликвидный SBI), включая овсдб. Политика программы агента узла в расширении VFP коммутатора Hyper-V, где он применяется. 4. Переключение и маршрутизация в виртуализации сети Hyper-V HNVv2 реализует правильное переключение уровня 2 (L2) и семантику маршрутизации уровня 3 (L3), чтобы работать точно так же, как физический коммутатор или маршрутизатор. Когда виртуальная машина, подключенная к виртуальной сети HNV, пытается установить подключение к другой виртуальной машине в той же виртуальной подсети (VSID), сначала необходимо узнать MAC-адрес ЦС удаленной виртуальной машины. Если имеется запись ARP для IP-адреса целевой виртуальной машины в таблице ARP исходной виртуальной машины, используется MAC-адрес из этой записи. Если запись не существует, исходная виртуальная машина отправит широковещательную ARP-запрос, соответствующий IP-адресу целевой виртуальной машины, который будет возвращен. Коммутатор Hyper-V перехватит этот запрос и отправит его агенту узла. Агент узла будет искать в своей локальной базе данных соответствующий MAC-адрес для запрошенной конечной виртуальной машины. Если MAC-адрес доступен, агент узла вставляет ответ ARP и отправляет его обратно на виртуальную машину. После того как сетевой стек виртуальной машины будет иметь все необходимые сведения о заголовке L2, этот кадр будет отправлен соответствующему порту Hyper-V на коммутаторе V. На внутреннем уровне коммутатор Hyper-V проверяет этот кадр на соответствие правилам сопоставления N-кортежам, назначенным V-порту, и применяет определенные преобразования к кадру на основе этих правил. Что важнее всего, набор преобразований инкапсуляции применяется для создания заголовка инкапсуляции с помощью NVGRE или ВКСЛАН в зависимости от политики, определенной на сетевом контроллере. В зависимости от политики, запрограммированной агентом узла, для определения IP-адреса узла Hyper-V, на котором находится целевая виртуальная машина, используется сопоставление CA-PA. Коммутатор Hyper-V гарантирует, что к внешнему пакету применяются правильные правила маршрутизации и теги VLAN, чтобы они достигли удаленного адреса PA. Если виртуальная машина, подключенная к виртуальной сети HNV, хочет создать подключение с виртуальной машиной в другой виртуальной подсети (VSID), пакет необходимо маршрутизировать соответствующим образом. HNV предполагает топологию типа "звезда", где в пространстве ЦС имеется только один IP-адрес, используемый в качестве следующего прыжка для получения всех префиксов IP-адресов (то есть один маршрут или шлюз по умолчанию). В настоящее время ограничение на использование одного маршрута по умолчанию и маршрутов не по умолчанию не поддерживается. Маршрутизация между виртуальными подсетями В физической сети IP-подсеть — это домен уровня 2 (L2), где компьютеры (виртуальные и физические) могут напрямую взаимодействовать друг с другом. Домен уровня L2 — это Широковещательный домен, в котором записи ARP (схема IP-адресов MAC) обрабатываются через запросы ARP, которые проходят вещание на всех интерфейсах и ответы ARP отправляются обратно на запрашивающий узел. Компьютер использует информацию MAC, полученную из ответа ARP, для полного создания кадра L2, включая заголовки Ethernet. Однако если IPадрес находится в другой подсети L3, запрос ARP не пересекает эту границу L3. Вместо этого интерфейс маршрутизатора L3 (следующий прыжок или шлюз по умолчанию) с IP-адресом в исходной подсети должен отвечать на эти запросы ARP с собственным MAC-адресом. В стандартной сети Windows администратор может создавать статические маршруты и назначать их сетевому интерфейсу. Кроме того, "шлюз по умолчанию" обычно настраивается как IP-адрес следующего прыжка в интерфейсе, куда отправляются пакеты, предназначенные для маршрута по умолчанию (0.0.0.0/0). Пакеты отправляются в этот шлюз по умолчанию, если не существует конкретных маршрутов. По сути это маршрутизатор для физической сети. HNV использует встроенный маршрутизатор, который является частью каждого узла и имеет интерфейс в каждой VSID, чтобы создать распределенный маршрутизатор для виртуальных сетей. Так как HNV предполагает топологию типа "звезда", распределенный маршрутизатор HNV выступает в качестве единого шлюза по умолчанию для всего трафика, который проходит между виртуальными подсетями, которые являются частью одной сети VSID. Адрес, используемый в качестве шлюза по умолчанию, по умолчанию имеет самый низкий IP-адрес в VSID и назначается распределенному маршрутизатору HNV. Этот распределенный маршрутизатор обеспечивает очень эффективный способ маршрутизации всего трафика в VSID сети, так как каждый узел может напрямую направить трафик на соответствующий узел, не требуя посредника. Это тем более верно, если две виртуальные машины из одной сети, но из разных виртуальных подсетей виртуальных машин находятся на одном физическом узле. Как вы узнаете позже в этом разделе, пакету нет необходимости покидать физический узел. Маршрутизация между подсетями PA В отличие от HNVv1, которые выделили один IP-адрес PA для каждой виртуальной подсети (VSID), HNVv2 теперь использует по одному IP-адресу PA для каждого члена группы поддержки сетевых карт (SET). Развертывание по умолчанию предполагает команду с двумя сетевыми картами и назначает два IP-адреса PA на узел. С одним узлом IP-адреса PA назначены из одной логической подсети поставщика (PA) в одной виртуальной ЛС. Две виртуальные машины клиента в одной виртуальной подсети на самом деле могут находиться на двух разных узлах, подключенных к двум разным логическим подсетям поставщика. HNV будет формировать внешние заголовки IP-адресов для инкапсулированного пакета на основе сопоставления CA-PA. Однако он полагается на стек TCP/IP узла на ARP для шлюза PA по умолчанию, а затем создает внешние заголовки Ethernet на основе ответа ARP. Как правило, этот ответ ARP поступает от интерфейса сви на физическом коммутаторе или на маршрутизаторе L3, подключенном к узлу. Таким образом, HNV полагается на маршрутизатор L3 для маршрутизации инкапсулированных пакетов между логическими подсетями поставщика или виртуальными ЛС. Маршрутизация за пределами виртуальной сети Развертывание большинства клиентских сетей требует, чтобы среда виртуализации сети Hyper-V была связана с ресурсами, не включенными в среду виртуализации сети Hyper-V. Шлюзы виртуализации сетей необходимы для обеспечения возможности связи между этими двумя средами. Инфраструктурам, требующим HNV Gateway, относятся частное облако и гибридное облако. По сути, шлюзы HNV необходимы для маршрутизации уровня 3 между внутренней и внешней (физической) сетями (включая NAT) или между разными сайтами и (или) облаками (частными или общедоступными), которые используют туннель IPSec или GRE. Шлюзы могут иметь различные физические конструктивные параметры. Они могут быть созданы на базе Windows Server 2016, включены в начало ключа стойки (TOR), действующего в качестве шлюза ВКСЛАН, доступ к которому осуществляется через виртуальный IP-адрес (VIP), объявленный подсистемой балансировки нагрузки, в другие существующие сетевые устройства или как новое автономное сетевое устройство. Инкапсуляция пакета В виртуализации сети Hyper-V каждый виртуальный сетевой адаптер связан с двумя IP-адресами: Адрес клиента (CA) IP-адрес, назначенный клиентом в зависимости от инфраструктуры интрасети. Этот адрес позволяет клиенту обмениваться сетевым трафиком с виртуальной машиной, как будто он не был перемещен в общедоступное или частное облако. АК является видимым для виртуальной машины и доступным для клиента. Адрес поставщика (PA) — IP-адрес, назначенный поставщиком услуг размещения или администратором центра обработки данных на основе физической сетевой инфраструктуры. АП появляется в сети в виде пакетов. Обмен ими производится с сервером Hyper-V, на котором размещается виртуальная машина. АП является видимым в физической сети, но не для виртуальной машины. АК обслуживают топологию клиентской сети, которая виртуализируется и лишается привязки к фактическим адресам и топологии базовой физической сети, как это реализовано для АП. На следующей схеме представлены концептуальные взаимоотношения АК виртуальных машин и АП сетевых инфраструктур как результат виртуализации сетей. Высокая доступность сетевого контроллера С помощью этого раздела можно узнать о высокой доступности и масштабируемости сетевого контроллера для программно определяемой сетевой конфигурации (Sdn). При развертывании SDN в вашем центре обработки данных можно использовать сетевой контроллер для централизованного развертывания, мониторинга и управления множеством сетевых элементов, включая шлюзы RAS, подсистемы балансировки нагрузки, политики виртуальных сетей для связи с клиентами, политики брандмауэра центра обработки данных, качество обслуживания () для политик Sdn, политики гибридных сетей и многое другое. Поскольку сетевой контроллер является важнейшим руководством по управлению SDN, для развертывания сетевых контроллеров очень важно обеспечить высокий уровень доступности и возможность легко масштабировать узлы сетевого контроллера с вашими потребностями в центре обработки данных. Несмотря на то, что сетевой контроллер можно развернуть как кластер с одним компьютером, для обеспечения высокой доступности и отработки отказа необходимо развернуть сетевой контроллер в кластере с несколькими компьютерами, используя не менее трех компьютеров. Высокий уровень доступности и масштабируемости Поскольку сетевой контроллер является ядром сети центра обработки данных, он должен быть устойчивым к сбоям и быть достаточно масштабируемым, чтобы обеспечить гибкие изменения в сетях центра обработки данных с течением времени. Следующие функции предоставляют эти возможности: Быстрая отработка отказа. Service Fabric обеспечивает чрезвычайно быструю отработку отказа. Несколько реплик с горячей вторичной службой доступны всегда. Если экземпляр операционной системы становится недоступным из-за сбоя оборудования, одна из вторичных реплик немедленно повышается до первичной реплики. Гибкость масштабирования. Вы можете легко и быстро масштабировать эти надежные службы из нескольких экземпляров до тысяч экземпляров, а затем выполнять резервное копирование на несколько экземпляров в зависимости от потребностей ресурса. Постоянное хранилище Приложение сетевого контроллера имеет большие требования к хранению в конфигурации и состоянии. Приложение также должно быть доступно в запланированных и незапланированных простоях. Для этой цели Service Fabric предоставляет хранилище "ключ-значение" (КВС), которое является реплицируемым, транзакционным и материализованным хранилищем. Модульность Сетевой контроллер разработан с помощью модульной архитектуры, каждая из которых имеет такие сетевые службы, как служба виртуальных сетей и брандмауэр, встроенные - в виде отдельных служб. Эта архитектура приложения предоставляет следующие преимущества. 1. Модульность сетевого контроллера обеспечивает независимую разработку каждой из поддерживаемых служб по мере развития потребностей. Например, службу балансировки нагрузки программного обеспечения можно обновить, не затрагивая другие службы или нормальную работу сетевого контроллера. 2. Модульность сетевого контроллера позволяет добавлять новые службы по мере развития сети. Новые службы могут быть добавлены к сетевому контроллеру без влияния на существующие службы. Конфигурация Hyper-V Выбор оборудования Рекомендации по оборудованию для серверов под управлением Hyper-V, как правило, похожи на те, которые являются нейтрализованными серверами, но серверы с Hyper-V могут демонстрировать увеличение загрузки ЦП, потребляют больше памяти и требуют большей пропускной способности ввода-вывода в связи с консолидацией серверов. Процессоры Hyper-V в Windows Server 2016 представляет логические процессоры как один или несколько виртуальных процессоров для каждой активной виртуальной машины. Hyper-V теперь требует процессоров, поддерживающих технологии преобразования адресов второго уровня (SLAT), такие как расширенные таблицы страниц (EPT) или таблицы вложенных страниц (НПТ). Cache Hyper-V может выиграть от больших кэшей процессора, особенно для нагрузок с большим рабочим набором в памяти и в конфигурациях виртуальных машин, в которых отношение виртуальных процессоров к логическим процессорам велико. Память Физическому серверу требуется достаточно памяти для корневого и дочернего разделов. Корневой разделу требуется память для эффективного выполнения операций ввода-вывода от имени виртуальных машин и операций, таких как моментальный снимок виртуальной машины. Hyper-V обеспечивает достаточный объем доступной памяти для корневого раздела и позволяет назначить оставшийся объем памяти дочерним секциям. Размеры дочерних секций должны быть в зависимости от потребностей ожидаемой нагрузки для каждой виртуальной машины. Хранилище Оборудование хранилища должно иметь достаточную пропускную способность ввода-вывода и емкость для удовлетворения текущих и будущих потребностей виртуальных машин, размещенных на физическом сервере. Эти требования следует учитывать при выборе контроллеров и дисков хранилища и выборе конфигурации RAID. Размещение виртуальных машин с ресурсоемкими рабочими нагрузками на разных физических дисках может повысить общую производительность. Например, если четыре виртуальные машины используют один диск и активно используют его, каждая виртуальная машина может выдавать только 25% пропускной способности этого диска. Рекомендации по схеме управления питанием Виртуализация — это мощное средство, которое полезно при увеличении плотности рабочих нагрузок серверов, уменьшая количество необходимых физических серверов в центре обработки данных, повышая эксплуатационную эффективность и уменьшая затраты на энергопотребление. Управление питанием является критически важным для управления затратами. В идеальной среде центра обработки данных потребление энергии управляется путем консолидации работы на компьютерах до тех пор, пока они не будут заняты, а затем отключены на бездействующие компьютеры. Если этот подход непрактичен, администраторы могут использовать схемы управления питанием на физических узлах, чтобы гарантировать, что они не потребляют больше энергии, чем необходимо. Методы управления питанием сервера поставляются с учетом затрат, особенно в том случае, если рабочие нагрузки клиента не являются доверенными для диктовки политики физической инфраструктуры поставщика услуг размещения. Программное обеспечение уровня узла оставляет возможность максимально увеличить пропускную способность и свести к минимуму энергопотребление. В основном на бездействующих машинах это может привести к тому, что физическая инфраструктура завершится с помощью средней мощности, что приведет к тому, что отдельные рабочие нагрузки клиента будут работать медленнее, чем в противном случае. Windows Server использует виртуализацию в самых разных сценариях. С легко загруженного сервера IIS на умеренную SQL Server в облачный узел с Hyper-V, на котором запущены сотни виртуальных машин на каждом сервере. Каждый из этих сценариев может иметь уникальные требования к оборудованию, программному обеспечению и производительности. По умолчанию Windows Server использует и рекомендует сбалансированную схему управления питанием, которая позволяет экономить электроэнергию путем масштабирования производительности процессора на основе загрузки ЦП. При использовании сбалансированной схемы управления питанием самые высокие состояния питания (и наименьшие задержки ответа в рабочих нагрузках клиента) применяются только в том случае, когда физический узел относительно занят. При значении детерминированного ответа с низкой задержкой для всех рабочих нагрузок клиента следует рассмотреть возможность переключения с сбалансированной схемы управления питанием на высокопроизводительную схему управления питанием. Высокопроизводительная схема управления питанием будет выполнять все процессоры с максимальной скоростью, эффективно отключая переключение на основе спроса вместе с другими методами управления питанием и оптимизировать производительность по сравнению с энергосбережением. Для клиентов, которым удовлетворена экономия затрат от сокращения числа физических серверов и требуется обеспечить максимальную производительность для виртуализованных рабочих нагрузок, следует рассмотреть возможность использования высокопроизводительной схемы управления питанием. Установка основных серверных компонентов Windows Server 2016 — вариант установки основных серверных компонентов. Server Core предлагает минимальную среду для размещения выбранного набора ролей сервера, включая Hyper-V. Он занимает меньше места на диске для операционной системы узла, а также меньшей атаки и обслуживания. Поэтому мы настоятельно рекомендуем использовать для серверов виртуализации Hyper-V вариант установки Server Core. Установка Server Core предлагает окно консоли только в том случае, если пользователь вошел в систему, но Hyper-V предоставляет функции удаленного управления, включая Windows PowerShell, поэтому администраторы могут управлять ею удаленно. Выделенная роль сервера Корневой раздел должен быть выделен для Hyper-V. Выполнение дополнительных ролей сервера на сервере под управлением Hyper-V может негативно сказаться на производительности сервера виртуализации, особенно если они потребляют значительный объем ресурсов ЦП, памяти или ввода-вывода. Минимизация ролей сервера в корневом разделе имеет дополнительные преимущества, такие как уменьшение уязвимой зоны. Системным администраторам следует тщательно продумать, какое программное обеспечение установлено в корневом разделе, поскольку некоторое программное обеспечение может негативно сказаться на общей производительности сервера с Hyper-V.