Глава 5. Практический опыт сетевой среды

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

Ранее необходимая изоляция множества арендаторов при выполнении требований безопасности могла быть достигнута через громадные инвестиции в сетевую инфраструктуру. однако, Windows Server 2016 при помощи Hyper-V изменил это. Его динамичный и гибкий сетевой подход позволяет вам достичь эту цель при меньшем оборудовании физической сетевой среды, однако с увеличенной гибкостью. Посредством применения виртуального коммутатора Hyper-V возрастает абстрагирование, что объясняется в последующих параграфах. Виртуальные машины используют виртуальные сетевые интерфейсы (VIF, virtual network interfaces), которые взаимодействуют через VMBUS с имеющимся виртуальным коммутатором. Такой полный стек управляется корневым разделом (root partition) Hyper-V, также имеющим название управляющей ОС (management OS) и имеющимися в виртуальных машинах vNIC.

Все связанные с сетевой средой установки в данной главе будут напрямую настраиваться через PowerShell на уровне самой операционной системы. Такие настройки также можно осуществить через SCVMM (System Center Virtual Machine Manager, Системный центр Диспетчера Виртуальных машин), который вы изучите юолее подробно в Главе 7, Настройка производительности Hyper-V. В качестве практического метода, если вы планируете применять более трёх хостов Hyper-V, рекомендуется применять SCVMM и сетевые настройки должны осуществляться из SCVMM. Невозможно управлять созданными через SCVMM сетевыми установками, которые были созданы PowerShell Hyper-V.

Аналогично Windows Server 2012 (R2), Windows Server 2016 поддерживает конвергентные сетевые среды с совместным использованием различных типов сетевого обмена в одной и той же сетевой инфраструктуре Ethernet. При помощи таких средств как QoS (Quality of Service, Качество обслуживания), у нас имеется возможность консолидировать сетевой обмен в меньшем числе физических адаптеров. При объединении с методами изоляции обмена, такими как VLAN, вы можете изолировать весь сетевой обмен и управлять им независимо от физической архитектуры.

Давайте перейдём к подробностям наилучших практических методов Hyper-V.

Виртуальный коммутатор Hyper-V является сетевым коммутатором 2 уровня на основе программного обеспечения, который доступен в Диспетчере Hyper-V когда вы добавляете роль Сервера Hyper-V. Такой коммутатор позволяет нам присоединять виртуальные машины как к виртуальным сетевым средам, так и к физическим сетевым средам. Кроме того, Виртуальный коммутатор Hyper-V предоставляет усиления политики для безопасности, изолированности и уровней обслуживания, а также может быть расширен для целей усовершенствованного управления такого, как анти- вирусные или диагностические добавления.

Вы даже можете расширить имеющийся по умолчанию Коммутатор Hyper-V хорошо известным Cisco Switch Nexus 1000V. Если вы уже используете Сетевую инфраструктуру Cisco, вам следует пользоваться данным расширением и управлять таким Cisco Nexus 1000V при помощи имеющейся у вас инфраструктуры Управления Cisco.

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

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

В Главе 1, Ускорение развёртывания Hyper-V мы уже применяли PowerShell для создания некоторого внешнего коммутатора:

New-VMSwitch -Name external -NetAdapterName "Local Area Connection 2"
 	   

Для Внутреннего и Частного vSwitches, которые я собираюсь представить далее, параметр NetAdapterName не доступен, так как никакой внешний адаптер не применяется. Вы также ранее применяли параметр AllowManagementOS $true, который делает возможным применение для некоторого виртуального коммутатора того же самого физического сетевого адаптера помимо соединения с вашими хостами Hyper-V. Такая разделяемая установка должна применяться только когда у вас не имеется достаточного числа доступных физических адаптеров и не применяется конвергентное построение сетей (converged networking), некая концепция, которую я представлю позже в данной главе. Во всех остальных случаях он не будет предпочтительной настройкой с точки зрения производительности.

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

Для создания некоторого внутреннего vSwitch из поднимаемой оболочки воспользуйтесь следующим cmdlet:

New-VMSwitch -Name internal `
             -SwitchType internal `
             -Notes 'Internal VMs only'
 	   

Частный vSwitch делает возможным взаимодействие между виртуальными машинами Hyper-V в одном и том же хосте. Он не допускает никакого внешнего взаимодействия или взаимодействия с самим родительским хостом. В основном он применяется для сетевых сред гостевых кластеров, как это объясняется в Главе 2, Развёртывание кластеров Hyper-V высокой доступности, а также для лабораторных целей.

Для создания частного vSwitch воспользуйтесь следующим cmdlet в поднимающейся оболочке:

New-VMSwitch -Name private -SwitchType Private
 	   

Сетевые среды Hyper-V способны применять VLAN; однако, они настраиваются не на уровне vSwitch, а исключительно на уровне виртуального интерфейса. Имеющаяся в наличии в Диспетчере Виртуального коммутатора флаговая кнопка VLAN ID служит только для настроек VLAN ОС хоста в случае, когда применяется параметр AllowManagementOS.

Hyper-V предлагает два типа сетевых адаптеров: наследуемый сетевой адаптер (legacy network adapter) и определяемый по умолчанию синтетический сетевой адаптер (synthetic network adapter. Наследуемый адаптер первоначально использовался для возможностей начальной загрузки PXE. Однако при наличии сетевой полосы пропускания со всего 100 Мегабитами, его следует избегать. В ВМ 2 поколения (generation 2), такой наследуемый сетевой адаптер более не доступен, а начальная загрузка PXE доступна теперь в предоставляемом по умолчанию сетевом адаптере.

Некий сетевой адаптер всегда подключается к какому- то vSwitch, который описывался выше в данной главе. После подключения vmNIC к vSwitch мы можем теперь добавить этот конкретный NIC к какой- то определённой VLAN. Весь сетевой обмен к и от такой ВМ будет осуществляться через эту VLAN (помеченную - tagged). Вместо добавления 15 различных кабелей к вашему хосту Hyper-V при использовании 15 различных сетевых сред для ваших систем, имеется данная великолепная возможность включения транков (группирования - trunking) VLAN и осуществлять взаимодействие всего с при посредстве 1 - 2 физических NIC.

Для добавления отдельного VLAN в наш vNIC внешним образом при помощи PowerShell воспользуйтесь приводимым ниже cmdlet:

Set-VMNetworkAdapterVlan -VMName VM01 `
                         -VMNetworkAdapterName "External" `
                         -Access `
                         -VlanId 10
 	   

Также имеются дополнительные возможности для Hyper-V и VLAN, такие как использование режимов изоляции VLAN и разнородных режимов для более расширенных сценариев с выделенной изоляцией и требованиями совместимости между VLAN (http://bit.ly/1mDy6GH).

Хорошей практикой является ограничиваться всего одной VLAN на NIC до тех пор, пока вы не перестанете удовлетворять своим требованиям для неё. Если вам необходимо применять транки или прочие специализированные сценарии, настоятельно рекомендуется чтобы вы применяли для управления VLAN SCVMM. За дальнейшими подробностями отсылаем вас к Главе 8, Управление при помощи системного центра и Azure.

После включения на наших vNIC VLAN, мы разделяем использование одного или нескольких физических соединений между такими VLAN. Чтобы гарантировать, что наша сетевая среда резервного копирования не использует всю доступную полосу пропускания и тем самым оказывает воздействие на производственные ВМ, мы применяем управление полосой пропускания для своих виртуальных интерфейсов, которое также имеет наименование QoS. QoS позволяет нам отвечать требованиям конкретной службы какого- либо сервиса или приложения путём измерения значения сетевой полосы пропускания, обнаружения пределов полосы пропускания, а также приоритезации - или дросселирования - сетевого обмена посредством политик. Hyper-V предоставляет нам возможность управлять двумя установками для сетевых сред:

Эти настройки предоставляются на абсолютных значениях полосы пропускания и являются жёсткими для аппаратных изменений. Наилучшей практикой является установка минимальной полосы пропускания, однако при этом не ограничивать значение максимальной полосы пропускания. Для установки пределов, улучшающих данный подход, применяйте следующий cmdlet PowerShell:

Set-VMNetworkAdapter -VMName VM1 -MinimumBandwidth 1000000
 	   

Абсолютное значение полосы пропускания предоставляется в битах в секунду и будет округляться до байта. Эти установки будут отображены в GUI:

В данном примере я также установил значение максимальной полосы пропускания в 200Mbps.

Однако имеется намного лучший подход с применением весов вместо абсолютных значений. Эти значения не отображаются в GUI, поэтому вновь нашим другом является PowerShell. Чтобы включить применение весов, для начала разрешите относительные веса для vSwitch, а затем установите некоторое значение по умолчанию для созданного нами vSwitch.

При помощи параметра DefaultFlowMinimumBandwidthWeight создайте следующим образом некий vSwitch:

New-VMSwitch -Name external `
             -NetAdapterName "Local Area Connection 2" `
             -DefaultFlowMinimumBandwidthWeight
 	   

Для имеющегося внешнего VMSwitch установите DefaultFlowMinimumBandwidthWeight равным 50. этот вес будет назначен всем имеющимся в данном vSwitch адаптерам без некоторого определённого особым образом веса. Установите наивысший вес (вплоть до 100) для наиболее важных служб, а меньшее весовое значение для менее важных служб.

В некотором типовом кластере hyper-V в каждом из узлов Hyper-V доступны следующие сетевые среды и я подключил свои значения настроек QoS полосы пропускания своего практического опыта:

Сетевая среда	Минимальное значение веса QoS
Управление	10
Кластер	15
Миграция в реальном времени	25
Виртуальные машины	50

Для возможности резервирования эти сетевые среды и их веса лучше помещать в некотором группированном NIC.

Вплоть до Windows Server 2012 группирование (teaming) NIC было частью самого драйвера NIC, а не данной операционной системы. Данная политика приводила к постоянным случаям возникновения проблем с реализациями; таким образом, присутствие Группирования NIC выполнено на уровне самой операционной системы.

Группирование NIC в Windows Server 2016 позволяет нам расширять некую группу по NIC от различных производителей и с различными полосами пропускания с применением классических возможностей LBFO (Load Balancing and Failover, Балансировки нагрузки и отказоустойчивости). Однако, лучшей практикой будет иметь в одной группе только активные интерфейсы с эквивалентными полосами пропускания. Создание Группы NIC создаст некий логический сетевой объект, tNIC (team NIC), который затем подключается к созданному нами vSwitch Hyper-V.

имеется возможность создания дополнительных tNIC в некоторой существующей группе без применения vSwitch. Однако, такая возможность утрачивает способность к QoS и её следует избегать.

В Windows Server 2012 R2 доступны различные режимы группирования. Они следующие:

Существует три доступных метода балансировки нагрузки, которые определяют как разделяется обмен по участникам данной группы. они таковы:

Давайте посмотри какие комбинации готовы для сценариев из практики:

Также имеются варианты для определения некоторого адаптера в ждущем режиме (standby), который является пассивным, пока не откажет один из адаптеров. Наилучшей практикой является применение всех доступных NIC.

Зависимые от коммутатора политики на моей практике являются более сложными и не предоставляют лучшей производительности.

Для дополнительных подробностей обращайтесь к руководству пользователя по Группированию NIC Windows Server 2012 R2 по адресу http://bit.ly/2b8648h.

основными проблемами для группирования NIC в хосте Hyper-V является отсутствие поддержки для свойств, подобных vRSS для NIC в ОС управления или RDMA. Для разрешения этих проблем вы можете применять SET (Switch Embedded Teaming, Встроенное группирование коммутатора, которое мы обсудим в следующем разделе), что является новой функциональностью в Windows Server 2016.

В данной версии Windows я рекомендую вам применять SET вместо группирования NIC в своём корневом разделе. Для группирования в гостевых ОС Windows вам придётся использовать Группирование NIC, так как SET не поддерживается в виртуальных машинах.

Когда для подключения к vSwitch вы применяете Группирование NIC, вы вначале создаёте некоторую группу, а затем вы создаёте тот vSwitch, который соединён с данным tNIC. Затем вы можете подключить данный vmNIC к обсуждаемому vSwitch для взаимодействия с ним. Как мы уже сказали ранее, Группированный NIC утрачивает такие свойства как vRSS для управляющей ОС или RDMA, что может стать проблематичным для полной конвергенции сетевой среды (конвергентные сетевые среды мы обсудим позже), а также для производительности.

Когда вы применяете SET, балансировка нагрузки между NIC управляется внутри Коммутатора Hyper-V. В один SET вы максимально можете добавить до 8 физических сетевых адаптеров. SET может применяться только в Виртуальном коммутаторе Hyper-V в Windows Server 2016. Это означает, что вы можете развёртывать SET только в физических узлах с установленной ролью Hyper-V.

SET поддерживает следующие функции:

Однако, SET не поддерживает следующие функции:

Когда вы применяете SET, методом группирования является Независимый коммутатор, а алгоритмом балансировки нагрузки может быть либо Динамический, либо Порт Hyper-V. За исключением расширенных сценариев я рекомендую вам оставлять алгоритмом балансировки нагрузки Динамический.

Чтобы создать SET вы можете исполнить следующий cmdlet PowerShell:

New-VMSwitch -Name SwitchSET -NetAdapterName "NIC 1","NIC 2" -EnableEmbeddedTeaming $true -ManagementOS $True
 	   

Когда вы создаёте VMSwitch, enableEmbeddedTeaming $True включает данное свойство SET. NetAdapterName позволяет определять конкретный физический NIC, который будет частью данного SET.

Если впоследствии вы пожелаете добавить в этот SET физические NIC, вы можете исполнить следующий cmdlet PwerShell:

Set-VMSwitchTeam -Name SwitchSET -NetAdapterName "NIC 1","NIC 3"
 	   

Предыдущий cmdlet добавляет NIC 1 и NIC 3 в SwitchSET Если NIC 2 ранее уже присутствовал в данном SET SwitchSET, тогда предыдущая команда удалит его из данного SET.

Теперь с Сетевой виртуализацией Hyper-V - VLAN, QoS и NIC - у нас имеются в руках величайшие инструменты для создания истинных программно управляемых сетевых сред, вне зависимости от лежащего в их основании физического оборудования. Это даёт нам возможность реализовывать все сетевые проекты по нашему выбору без конкретной потребности в дополнительных физических NIC. Воспользуйтесь несколькими высокоскоростными NIC вместо большого числа отдельных гигабитных NIC. Я настоятельно рекомендую чтобы вы применяли сетевые адаптеры одного и того же производителя. Даже если Группирование NIC поддерживает NIC от различных производителей, я наблюдал множество проблем с такого вида конфигурациями. Группируйте такие NIC и добавляйте решения конвергентных сетевых сред в них. Применяйте виртуальные NIC в некотором vSwitch (вместо tNIC без vSwitch) чтобы добавить настройки QoS.

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

Группирование с независимым коммутатором/ динамической балансировкой создаётся на всех доступных NIC с самой высоко полосой пропускания, только при том что они не применяются для кластеров гостевых ОС. Динамический коммутатор создаётся поверх такой Группировки. При помощи PowerShell будут созданы четыре vNIC в управляющей ОС и подключены к также создаваемому vSwitch:

Add-VMNetworkAdapter -ManagementOS -Name &qout;Management&qout; -SwitchName &qout;External&qout;
MinimumBandwidthWeight 10
Add-VMNetworkAdapter -ManagementOS -Name &qout;Live Migration&qout; -SwitchName &qout;External&qout; MinimumBandwidthWeight 25
Add-VMNetworkAdapter -ManagementOS -Name &qout;VMs&qout; -SwitchName &qout;External&qout;
MinimumBandwidthWeight 50
Add-VMNetworkAdapter -ManagementOS -Name &qout;Cluster&qout; -SwitchName &qout;External&qout;
MinimumBandwidthWeight 15   
 	   

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

Вам настоятельно рекомендуется применять конвергентную архитектуру вместо классического соответствия сетевых сред.

Если вы используете для взаимодействия с хранилищем Инфраструктуру Fibre Channel, у вас нет необходимости дополнительного рассмотрения вопроса интеграции этого взаимодействия в вашу конвергентную сетевую среду. Однако, если вы применяете взаимодействие iSCSI, я настоятельно рекомендую чтобы для взаимодействия с хранилищем вы применяли другую сетевую среду. Для надёжности осуществления взаимодействия iSCSI применяет MPIO вместо сетевого группирования. имеется всего один подходящий сценарий при котором возможен iSCSI поверх группированных интерфейсов, во всех основных сценариях группированное взаимодействие iSCSI не поддерживается. За дополнительными подробностями обращайтесь к http://bit.ly/1mVYDyq.

Хорошей практикой является отделение всего взаимодействия iSCSI от остального обмена на некотором уровне хоста с тем, чтобы применять две выделенные сетевые карты в этом хосте. Не добавляйте их в Группирование, а применяйте вместо этого для обеспечения надёжности функциональность MPIO.

Если вы используете для своего хранилища взаимодействие SMB3, применяйте SET (Группирование встроенным коммутатором) для конвергирования данного вида обмена в случае если ваши сетевые адаптеры поддерживают RDMA. Для получения приоритетности потока SMB3 над остальным сетевым обменом вы можете усилить его DCB (Datacenter Bridging, Снабжение мостами Центров данных) и PFC (Priority Flow Control, Управление потоком на основе приоритетов) {Прим. пер.: который, строго говоря, входит в состав стандартов, формирующих DCB сам по себе.} Для установки и настройки DCB для SMB3 выполните следующий сценарий:

# Turn on DCB
Install-WindowsFeature Data-Center-Bridging
# Set a policy for SMB-Direct
New-NetQosPolicy &qout;SMB&qout; -NetDirectPortMatchCondition 445 -PriorityValue8021Action 3
# Turn on Flow Control for SMB
Enable-NetQosFlowControl -Priority 3
# Make sure flow control is off for other traffic
Disable-NetQosFlowControl -Priority 0,1,2,4,5,6,7
# Apply policy to the target adapters
Enable-NetAdapterQos -InterfaceAlias &qout;SLOT 2*&qout;
# Give SMB Direct 30% of the bandwidth minimum
New-NetQosTrafficClass &qout;SMB&qout; -Priority 3 -BandwidthPercentage 30 -Algorithm ETS
 	   

Для создания vNIC в SET с возможностями RDMA выполните следующие cmdlet:

Add-VMNetworkAdapter -SwitchName SETswitch -Name SMB_1 -managementOS
Add-VMNetworkAdapter -SwitchName SETswitch -Name SMB_2 -managementOS
Enable-NetAdapterRDMA &qout;vEthernet (SMB_1)&qout;,&qout;vEthernet (SMB_2)&qout;
 	   

Вы также можете создать некое подобие между vNIC и физическим адаптером. Это не препятствует переходу такого vNIC к другому NIC в случае отказа первого. Однако, если у вас имеются два vNIC, подключённых к SET с двумя NIC, вы можете связать один vNIC с физическим NIC, а второй vNIC со вторым физическим NIC. Вы можете осуществить такое подобие при помощи PowerShell следующим образом:

Set-VMNetworkAdapterTeamMapping -VMNetworkAdapterName SMB_1 -ManagementOS -PhysicalNetAdapterName NIC 1
Set-VMNetworkAdapterTeamMapping -VMNetworkAdapterName SMB_2 -ManagementOS -PhysicalNetAdapterName NIC 2
 	   

При применении взаимодействия с хранилищем SMB3 или миграции в реальном времени вам рекомендуется для получения наилучшей производительности устанавливать сетевые адаптеры с RDMA. Как мы уже видели ранее, начиная с Windows Server 2016 вы можете объединять (конвергировать) обмен SMB с остальным обменом при помощи SET. Вы можете добавить каждый сетевой адаптер в ту же самую подсеть, причём Windows Server 2016 автоматически настроит эти сетевые среды в отказоустойчивый кластер.

Windows Server будет автоматически распространять имеющуюся рабочую нагрузку между всеми NIC применяя многоканальный SMB. RDMA делает возможным высокопроизводительный сетевой обмен и при этом применяет очень маленькую нагрузку на CPU. Прямой SMB (SMB Direct) будет автоматически включён в случае, если в данном хосте будут обнаружены NIC с поддержкой RDMA.

Имеются три типа доступных сетевых архитектур, осведомлённых об RDMA. Это:

Все три типа архитектур имеют полную возможность предоставления великолепной производительности для взаимодействия с хранилищами SMB и Миграции в реальном времени. По моему опыту нет потребности в применении возможностей RDMA если вы не используете 10GbE или более высокие полосы пропускания для сетевых сред ВМ.

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

Для этого главным образом применяются NVGRE для инкапсуляции и шлюз NVGRE для внешнего взаимодействия. Это великолепные опции, но они не являются необходимыми в общем случае. Держитесь от этих настроек в стороне, пока они на самом деле не понадобятся вам для использования. Поскольку не самые распространённые опции не являются целью данной книги, за подробностями отсылаем вас к http://bit.ly/Ud5WXq.

Намного более часто применяемой опцией является DHCP Guard (Защитник DHCP). Наличие Rogue сервера DHCP {Прим. пер.: не находящегося в вашем административном подчинении, как правило, находящегося в вашем маршрутизаторе или даже модеме} может быстро превратиться в уродливую проблему практически для любой промышленной среды. Сервер DHCP Windows в некотором домене Active Directory должен пройти авторизацию прежде чем он начнёт широковещательное предложение DHCP. В прочих топологиях ничто более не остановит Rogue серверы DHCP. Hyper-V может защитить вас от непрошенных предложений маршрутизации и сервера DHCP на сетевом уровне.

Наилучшей практикой является включать Защитника DHCP для всех ВМ и запрещать его для определённых ВМ, в которых эти службы нужны. Естественно, для данной задачи мы применяем PowerShell:

Get-VM | Set-VMNetworkAdapter -DhcpGuard On
 	   

Он не включён по умолчанию, поскольку имеется некое минимальное воздействие на производительность для фильтрации непрошенных пакетов DHCP на сетевом уровне. По моему личному опыту такое воздействие на производительность практически не заметно.

Имеется аналогичная служба с названием Router Guard (Защитник маршрутизатора) для фильтрации заявлений о себе Маршрутизаторов ICMP и перенапраления сообщений, однако Защитник маршрутизатора применяется крайне редко.

Microsoft выпустил в Windows Server 2016 новую функцию с названием Сетевого контроллера (Network Controller). Это служба с высокой доступностью и масштабируемостью для управления Программно- определяемыми Сетевыми средами (SDN, Software-defined Networking) из единой панели. Сетвой контроллер предоставляет два API. Они таковы:

Сетевым контроллером можно управлять при помощи PowerShell или применяя GUI, например, SCVMM (Системный центр Диспетчера Виртуальных машин).

Сетевой контроллер выходит за рамки данной книги. Просто упомянем, что вы можете настраивать виртуальные коммутаторы Hyper-V через Сетевой контроллер.

Одним из наиболее привлекательных свойств в Windows Server 2016 является модуль IPAM (IP address management, Управления адресами IP). Он очень прост и скор в применении , но также и очень эффективен.

Когда вам требуется некий статический IP адрес для вновь создаваемой виртуальной машины где вам его получить? Выполнять ping по случайным адресам и смотреть когда он завершается по тайм- ауту? Проверять свой сервер DNS на имеющиеся записи? Проверять выделения и резервирования DHCP или просроченные файлы Excel? Всё это достаточно распространённые действия, однако имеется вероятность промаха и применения именно того адреса, который уже находится в использовании.

IPAM предлагает динамическую версию перечня Excel. Он периодически сканирует ваши серверы DNS и DHCP для фиксации всех полученных от них адресов и предлагает последующие в действительности свободные IP адреса, которые вы можете применять для своей новой ВМ, причём выполняет такую фиксацию автоматически.

Я не знаком со способом полной настройки IPAM через PowerShell, поэтому я рекомендую вам руководство, доступное по адресу http://bit.ly/1qgEw1R.

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

Теперь продолжим Главой 6, Высокоэффективная архитектура Hyper-V чтобы научиться делать архитектуру Hyper-V с NAS, SAN или Непосредственно подключаемыми Хранилищами (Storage Spaces Direct).