Глава 12. Виртуализация вашего центра обработки данных при помощи Hyper-V

Создание вашего сервера Hyper-V обычно достаточно простое. Постройте сервер, установите роль Hyper-V, и вы готовы начинать. Фактически, вы даже можете установить роль Hyper-V в компьютере с Windows 10 Pro или Enterprise, если у вас есть потребность запускать какие-то виртуальные рабочие машины на вашем собственном рабочем месте. В то время как большая часть оборудования, которое создаётся в наши дни, полностью поддерживает главную идею выступать поставщиком гипервизора, некоторые из вас могут попробовать установить роль Hyper-V только покончив со следующим сообщением об ошибке:

О, это не хорошо. Это означает одну из двух вещей - либо мой ЦПУ в действительности не поддерживает виртуализацию, либо я просто имею некоторые настройки выключенные в моём BIOS {Прим. пер.: Firmware} на моём сервере, что не даёт возможности работы. Существует три момента, которые вы должны проверить в своём сервере, чтобы убедиться что он готов к работе с Hyper-V. Во- первых вам необходимо работать с процессором на основе x64. Этот элемент выступает как данность, ибо Windows Server 2019 в любом случае поставляется только для 64 бит. Если у вас нет процессора с поддержкой инструкций x64, то вы не сможете установить саму операционную систему. Во- вторых, ваш ЦПУ должен иметь возможность аппаратной поддержки виртуализации. Она обычно называется либо Intel Virtualization Technology (Intel VT), либо AMD Virtualization (AMD-V). И последнее, но не по значимости, вы должны иметь доступной в вашей системе DEP (Data Execution Prevention). Если вы приобрели соответствующее оборудование, которое выглядит способным осуществлять виртуализацию, однако оно всё ещё не работает, тогда скорее всего настройка DEP выключена внутри BIOS {Прим. пер.: Firmware}. Загрузитесь в настройки BIOS {Прим. пер.: Firmware} и включите DEP, наряду со всеми прочими более дружественными для пользователя настройками, которые могут указывать на то, что они в настоящее время блокируют вашу возможность запуска виртуальных машин.

Как только вам удастся запустить виртуальные машины, вы сможете превратить оборудование практически любого размера в гипервизор установив роль Hyper-V. Нет нужды думать о минимальных системных требованиях, так как вы желаете чтобы ваше оборудование системы было настолько большим, насколько это возможно в сервере Hyper-V. Чем больше ядер ЦПУ, оперативной памяти и пространства жёстких дисков вы можете предоставить, тем больше виртуальных машин вы сможете сделать доступными для работы. Даже самые маленькие серверы Hyper-V, которые я видел в промышленных средах работали с оборудованием вроде дуальных процессоров Xeon, 96ГБ оперативной памяти и многих терабайт пространства хранения. Хотя 96ГБ может показаться громадным - если ваш стандартный сервер строится с применением 8ГБ памяти, что является достаточно небольшим числом, а вы хотите выполнять дюжину серверов на своём сервере Hyper-V - эти времена уже в прошлом, когда в доступности у сервера Hyper-V было только 96ГБ оперативной памяти. Восемь помноженные на двенадцать это 96, и вы не потеряете нисколько памяти для применения её операционной системой! Итак, в чём мораль этой истории? Работайте по- взрослому, или убирайтесь прочь!

Hyper-V является просто другой ролью в Windows Server 2019, однако в процессе установки этой роли вам будет задано несколько вопросов и важно понимать о чём они спрашивают чтобы вы могли быть уверенными что ваш новый сервер Hyper-V построен самым современным и работает эффективно. Прежде всего, вам конечно необходимо иметь уже установленным Windows Server 2019 и воспользоваться функцией Add roles and features чтобы установить роль с названием Hyper-V:

Если вы продолжите следовать за мастером для установки необходимой роли, вы пройдёте через экран с заглавием Create Virtual Switches. Мы обсудим сетевую среду в рамках Hyper-V чуть подробнее в следующем разделе этой главы, однако здесь важно отметить, что вы должны определить какой физический NIC сервера будет привязан к Hyper-V и доступен для использования вашими виртуальными машинами. Хорошей мыслью будет применять для каждого сервера Hyper-V несколько NIC. Вы хотите один NIC выделить для самого хоста, что не бы выбрали в этом экране. Оставьте его свободным для собственного взаимодействия гипервизора. Кроме этого NIC вы пожелаете по крайней мере один сетевой адаптер, который может выступать в роли моста ваших ВМ в корпоративную сетевую среду. Этот вам следует выбрать как вы можете это наблюдать в снимке экрана на подходе. Если вы будете размещать много различных ВМ на данном сервере и они должны будут соединяться с различными физическими сетевыми средами, вам может понадобиться установить множество различных NIC в ваш сервер Hyper-V:

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

Последний экран, на который я хочу указать, это определение местоположений хранилища для ваших данных виртуальных машин. После создания ВМ мы погрузимся в то как они выглядят на уровне вашего жёсткого диска, другими словами, когда вы ищите какие файлы создаются для ВМ, вы увидите что присутствуют две ключевых стороны для виртуальной машины. Первая это сам файл виртуального жёсткого диска - VHD (Virtual Hard Disk) или VHDX - а вторая состоит в папке, содержащей файлы настроек для этой ВМ.

В следующем снимке экрана вы можете увидеть местоположение для хранения этих элементов по- умолчанию является чем-то что вы ожидали бы увидеть за пределами приложений клиента которые вы устанавливаете на ноутбуки, однако вы не ожидали бы что- то столь тяжёлое как то, что Hyper-V хранит эти файлы ядра в Documents. Я предполагаю, что поскольку Microsoft не знает всей настройки вашего сервера, он не может сделать реальных предположений где вы в действительности желаете хранить эти данные, и поэтому он устанавливает по умолчанию нечто выглядящее настолько странным, чтобы вы изменили это. Множество серверов Hyper-V будут иметь выделенное хранилище, даже если это только отдельный жёсткий диск на котором планируется сохранять эти файлы. Убедитесь что вы потратили минутку на этот экран и изменили местоположения сохранения по- умолчанию ваших файлов ВМ.

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

Чтобы ответить на эти вопросы нам нужно открыть свой интерфейс управления для Hyper-V. Как и для любого инструмента администрирования роли Windows проверьте внутри меню Диспетчера сервера (Server Manager) наличие меню Tools, а теперь, когда роль установлена, вы увидите новый перечень для Hyper-V Manager. Запустите его и мы теперь наблюдаем свою самую первую платформу, с которой мы будем управлять и манипулировать всеми сторонами нашего окружения Hyper-V:

В настоящее время у нас имеется множество свободного пространства в этой консоли, так как у нас нет пока никаких работающих ВМ. С правой стороны от Hyper-V Manager вы можете увидеть ссылку которая сообщает Virtual Switch Manager…. Пройдите далее и кликните по этой ссылке чтобы войти в настройки для наших виртуальных коммутаторов и сетевых сред:

Далее слева мы увидим текущий перечень Virtual Switches. В моём сервере присутствует только один коммутатор в списке на текущий момент, который имеет название, соответствующее физическому NIC, к которому он подключён. Именно этот виртуальный коммутатор, чья роль состоит в процессе установки, создан для нас, когда мы выбрали NIC, который следует включить в Hyper-V. Если вы выбрали множество NIC в процессе установки роли, вы будете иметь множество виртуальных коммутаторов доступных в этом месте, причём каждый будет соответствовать отдельному физическому NIC. Каждая ВМ которую вы создаёте будет иметь один или более виртуальных NIC, и вы увидите вскорости, что у вас имеется возможность выбирать где каждый из этих виртуальных коммутаторов будет подключён. Если имеется пять различных физических сетевых сред с которыми ваши ВМ могут контактировать, вы можете применить пять физических NIC в своём сервере Hyper-V, подключив каждый в свою сетевую среду и получить здесь в консоли пять виртуальных коммутаторов, к которым могут подключаться ваши NIC ВМ .

Как вы можете увидеть на предыдущем снимке экрана, у нас имеется кнопка Create Virtual Switch, которая сама себя объясняет. Очевидно, это то куда мы идём чтобы создать новые коммутаторы, однако существует три различных типа коммутаторов, которые вы можете создать. Давайте выделим всего одну минутку и обсудим существующие разницы между этими тремя вариантами.

Внешний виртуальный коммутатор является наиболее распространённым типом, применяемым для любых ВМ, которым нужно взаимодействовать с производственной сетевой средой. Каждый внешний коммутатор прицепляется к физическому NIC, который установлен в ваш сервер Hyper-V. Если в кликните на внешний виртуальный коммутатор, вы можете увидеть, что у вас имеются некоторые варианты для настройки этого коммутатора и что вы можете даже изменить тип коммутатора. На следующем снимке экрана я переименовал свой внешний виртуальный коммутатор с тем чтобы его было проще определять когда я решу добавлять дополнительные NIC в этот сервер в будущем:

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

Частный виртуальный коммутатор - это просто то, что подразумевает его название - частный. Подключённые к одному и тому же частному виртуальному коммутатору ВМ могут взаимодействовать друг с другом, но не за его пределами. Даже сам сервер хоста Hyper-V не имеет сетевой связи с частным виртуальным коммутатором. Тестовые лаборатории являются великолепным примером для частных виртуальных коммутаторов, что будет обсуждаться непосредственно сразу после данного текста, когда мы создадим новый виртуальный коммутатор для своего владения.

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

Внутри Диспетчера виртуального коммутатора (Virtual Switch Manager) всё что мне необходимо сделать, это выбрать вид виртуального коммутатора, который я хочу создать, в данном случае, private, после чего кликните по кнопке Create Virtual Switch. Затем я могу предоставить своему новому коммутатору имя и я немедленно способен присоединять ВМ к этому коммутатору. Я могу видеть следующий снимок экрана, в котором я создал два новых частных виртуальных коммутатора, один для подключения для подключения своего внутреннего NIC ВМ тестовой лаборатории, а другой будет работать как моя тестовая лаборатория сетевой среды DMZ:

Теперь мы готовы раскрутить свой первый виртуальный сервер! Аналогично созданию нового виртуального коммутатора, сам процесс создания новой ВМ достаточно прямолинеен, однако существуют некоторые шаги вдоль этого пути, которые могут потребовать некоторого объяснения если вы не преодолевали этого пути ранее. Мы стартуем в том же самом интерфейсе управления, из которого мы делаем всё в своём мире Hyper-V. Откроем Hyper-V Manager и кликнем правой кнопкой по имени своего сервера Hyper-V. Переместимся к New | Virtual Machine… для запуска мастера:

Первый экран, в котором мы должны принять некие решения это Specify Name and Location. Создайте имя своей новой ВМ, что достаточно просто. Однако затем вам также придётся сохранить свою ВМ в новом местоположении. Если вы установили хорошее местоположение по умолчанию для своих виртуальных машин в процессе установки роли Hyper-V, существует шанс что вам не нужно менять это поле. Однако в моём случае я выбрал параметры по умолчанию когда я устанавливал эту роль, и поэтому мне предлагается место для моей ВМ где- то в C:\Users, а мне не нравится как это выглядит. Поэтому я захожу в этот блок и выбираю местоположение, которое я предпочитаю для своей ВМ.

Вы можете увидеть, что я выбираю выделенный диск для хранения своих виртуальных машин, что обычно является хорошим практическим приёмом:

Далее я должен решить буду ли я создавать виртуальную машину Generation 1 или Generation 2. Нам не стоит обсуждать это подробно, так как их объяснение приводится со всей ясностью в самой установке данной страницы. Если ваша ВМ собирается работать с более старой операционной системой, вам следует выбрать Generation 1 для гарантии совместимости. В качестве альтернативы, если вы планируете установку в эту ВМ последних версий операционной системы, вероятно в ваших интересах будет лучше воспользоваться новейшими свойствами и лучшими перспективами безопасности, выбрав Generation 2:

Теперь определим сколько оперативной памяти вы желаете выделить этой определённой ВМ. Имейте в виду, что это установка, которую вы можете изменить в дальнейшем для этого сервера и поэтому сосредотачиваться на планировании данного пункта. Объём оперативной памяти, который вы выделяете данной виртуальной машине будет зависеть от того, сколько оперативной памяти у вас доступно в системе хоста Hyper-V, а также от того, сколько оперативной памяти требуется для работы каких- либо ролей и служб, которые вы планируете установить на данной ВМ. Вы можете определить в данном поле любой объём оперативной памяти. Например, если я желаю в точности 2ГБ, я могу набрать примерно 2000МБ. Однако, что я нахожу в этом поле это то, что большинство людей всё ещё застревают с этим действительным количеством МБ, так как это то, то мы должны всегда делать для аппаратных средств. Поэтому вместо округления до 2000 я собираюсь установить мои 2ГБ ВМ в значение действительных 2ГБ - или 2048МБ.

Оставляя этот блок не помеченным для динамической памяти означает, что Hyper-V будет выделять реальные 2048МБ оперативной памяти для этой конкретной ВМ. Вне зависимости от того будет ли данная ВМ применять 2048МБ или 256МБ в определённый момент времени, все 2048МБ будут выделены под эту ВМ и будут недоступны остальному серверу Hyper-V. Если вы выберите этот блок для Use Dynamic Memory for this virtual machine, тогда такая ВМ будет получать от хоста Hyper-V только что она в действительности использует. Если вы установите это значение в 2048МБ, однако данная ВМ будет сидеть без дела и потреблять только 256МБ, она обременит Hyper-V только загрузкой 256МБ:

Следующим представленным экраном будет Configure Networking, и это то место, в котором мы выбираем какие виртуальные коммутаторы наших NIC ВМ получат подключения. В действительности у нас есть возможность добавить дополнительные NIC к этой ВМ позже, однако на текущий момент мы получаем стандартный отдельный NIC в процессе создания своей новой ВМ и всё что нам нужно, это выбрать куда она должна быть подключена. На текущий момент этот новый выстраиваемый мной веб- сервер для своей Тестовой лаборатории внутренней корпоративной сети, поэтому я смогу таким образом построить свои веб приложения и протестировать их, прежде чем введу их в реальную промышленную сетевую среду. Если я разверну здесь весь перечень доступных соединений, вы увидите в нём мой первоначальный внешний виртуальный коммутатор, а также два новых частных виртуальных коммутатора, которые я создал, доступными для выбора:

Несколько уточнений также необходимо предпринять с тем, чтобы эта новая виртуальная машина могла иметь жёсткий диск. Скорее всего, вы примените верхний параметр здесь с тем, чтобы новая ВМ получила новый маркированный (brand) жёсткий диск. Также существуют варианты для использования существующего виртуального жёсткого диска если вы загружаетесь из существующего файла или подключиться к диску позже, если вы ещё пока не готовы к осуществлению данного решения. Мы собираемся позволить своему мастеру создать маркированный новый виртуальный жёсткий диск и размер по умолчанию установлен в 127ГБ. Я могу установить здесь то что пожелаю, однако важно знать, что он не будет потреблять все 127ГБ пространства. Реальный размер диска будет настолько велик, сколько в действительности будет использоваться данным диском, поэтому задействована только часть из этих 127ГБ. Я упоминаю этот момент, что общее значение определяемое здесь является просто максимальным размером, поэтому убедитесь, что планируете свои диски надлежащим образом, определите достаточный размер, который нужен вам и вашим приложениям, достаточный для роста:

Наш последний экран выбора параметров в мастере позволяет нам определять специфические особенности той операционной системы , с которой наша новая ВМ собирается запускаться. Мы целенаправленно оставляем это установленным в Install an operating system later, так как это параметр по умолчанию и он даёт нам возможность увидеть что произойдёт когда вы не определите никаких действительных значений в этом экране:

Теперь мы создали некую виртуальную машину, что вы могли увидеть внутри консоли Hyper-V Manager . Запуск виртуальной машины это просто правый клик по ней, после чего мы выбираем Start. После выбора параметра для запуска этой ВМ снова кликните правой кнопкой по ней и нажмите Connect…. Это откроет окно консоли в котором вы сможете наблюдать процесс загрузки вашего нового сервера:

Теперь, когда наша новая ВМ была запущена, что мы можем ожидать увидеть внутри этого окна консоли? Конечно же, ошибку начальной загрузки:

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

Внутри настроек вы увидите, что эта ВМ имеет DVD Drive автоматически перечисляемый в IDE Controller 1. Если вы кликните по DVD Drive, вы сможете легко сообщить ему смонтировать какой- либо ISO для этого диска. Скопируйте необходимый файл ISO устанавливаемой по вашему желанию операционной системы для запуска на жёсткий диск для вашего сервера Hyper-V.

Я обычно помещаю свои ISO внутри выделенной папки с названием ISO где-то неподалёку от своей папки ВМ - а затем Browse… его в этом экране. Подключение некоего ISO к своей ВМ это в точности то же, как если бы вы подключали физический установочный DVD к физическому серверу:

После монтирования необходимого носителя, перезапустите данную ВМ и вы увидите что ваш установщик запустился автоматически:

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

Как вы уже знаете, Менеджер Hyper-V является первейшим инструментом для управления сервером Hyper-V. Это приятная консоль, которая быстро предоставляет вам состояние ваших виртуальных машин и позволяет вам управлять этими ВМ различными способами. Кое- что мы ещё не охватили, поскольку у меня имеется один рабочий сервер Hyper-V, а именно то, что вы можете управлять множеством серверов Hyper-V из одной консоли Hyper-V Manager. В точности как и любая другая консоль в стиле MMC из мира Microsoft, если вы кликните правой кнопкой по словам Hyper-V Manager вблизи от верхнего левого угла своего экрана, вы получите опции, которые сообщать Connect to Server…. Воспользовавшись этой функцией, вы можете получить информацию с других серверов Hyper-V в том же самом стекле окна.

Более того, это позволит вам запускать ваше программное обеспечение Hyper-V Manager на клиентском компьютере - вы можете установить роль Hyper-V на многих машинах Windows 10, которые также установят эту консоль - а затем использовать локальную копию Менеджера Hyper-V выполняющуюся на вашем рабочем месте чтобы управлять вашими серверами Hyper-V без необходимости регистрироваться на этих серверах напрямую.

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

Некоторые из них объясняют себя сами, а некоторые играют полезную роль вокруг них. Мы уже применяли Connect… для соединения с консолью своей ВМ. Settings… открывает тьму возможностей и мы взглянем на них далее внутри меню настроек следующего сразу за этим текстом. Одна из наиболее частых причин, по которой я открываю это меню правой кнопки это функции включения моих ВМ. Вы можете видеть, что у вас имеется возможность Turn Off… или Shut Down… вашу ВМ. Выключение (Turn Off) в точности как нажатие на кнопку электропитания сервера, оно незамедлительно отключает электропитание этого сервера и вызывает некоторую печаль Windows, когда вы делаете это. Функция останва (Shut Down), с другой стороны, инициирует чистый останов, по крайней мере когда вы используете в операционные системы Microsoft на своих ВМ. Останов сервера не великое дело, однако в этом случае, однако реальная мощность здесь проистекает из того факта, что вы можете останавливать множество ВМ одновременно. Например, если у меня работают десятки различных ВМ, причём все в моей тестовой лаборатории, и я решу, что моя лаборатория потребляет слишком много ресурсов и вызывает проблемы в моём сервере Hyper-V, я могу выбрать все свои ВМ и после этого кликнуть Shut Down… всего один раз, и это немедленно запустит процесс останова на всех моих ВМ, которые я выделил. Когда ВМ остановится и выключится, тогда клик правой кнопкой на эту ВМ предоставит вам функцию Start и вы можете также отобрать много различных серверов и запустить их за раз воспользовавшись таким меню правого клика.

Выполнение внутренних изменений в любой вашей машине обычно означает правый клик по ней с последующим переходом к Settings… для данной определённой ВМ. Внутри настроек вы можете настраивать любые аспекты оборудования вашей виртуальной машины, что является наиболее распространённой причиной для посещения этого экрана. Немедленно открыв эти настройки вы получаете возможности Add Hardware к своей ВМ. Это именно то место куда вам следует переходить для добавления дополнительных жёстких дисков или NIC в свой виртуальный сервер.

Я не знаю что вы можете сказать по поводу предыдущего снимка экрана, однако кнопка Add в настоящее время окрашена серым цветом. Это следует обсудить. Многие функции внутри установок могут выполняться на лету, в процессе работы этой виртуальной машины. Некоторые функции не могут быть выполнены пока эта ВМ не выключится. Добавление оборудования является одной из таких функций. Если вы желаете добавить новый жёсткий диск или NIC к своей ВМ, вам придётся остановить этот сервер, прежде чем вы будете в состоянии сделать это.

Далее следует обсудить ваш экран Memory. Он достаточно прост, не так ли? Просто введите объём памяти, который вы хотите сделать доступным для этой ВМ. Причина, по которой я останавливаюсь здесь состоит в основном улучшении выполненном в этой функциональности. Начиная с Windows Server 2016 вы можете установить нужный объём памяти, который имеет ВМ даже пока она работает! В предыдущих версиях Hyper-V вам было необходимо остановить эту ВМ чтобы внести изменения в выделения памяти, однако несмотря на то,что мой сервер WEB3 в настоящее время работает и обслуживает пользователей, я могу внезапно появиться здесь и увеличить оперативную память по своему желанию.

Допустим, мои 2ГБ не соответствуют загрузке моей задачи и я хочу увеличить их до 4ГБ. Я оставляю этот сервер работающим, открываю настройки Hyper-V Manager для данной ВМ и настраиваю 4096МБ.

Объём памяти настраивается моментально и, если я открою свойства системы внутри своего сервера WEB3, я смогу увидеть, что моя операционная система обновилась для отображения установленных в настоящее время 4ГБ:

Другими полезными экранами настроек являются разделы Processor и Network Adapter. У вас есть возможность определить общее число виртуальных процессоров в настоящее время назначенное для данной ВМ, а также веса производительности для этих процессоров. В экране Network Adapter вы можете изменять к какому из виртуальных коммутаторов подключаются ваши виртуальные NIC. Я часто застаю себя в этом разделе, так как я часто меняю одно местоположение сервера на другое.

Контрольные точки

Последняя часть настроек меню, которую я хочу обсудить, называется Checkpoints (контрольные точки). Это ранее называлось моментальными снимками, что, как я полагаю, сделает их слегка более понятным для большинства из нас. Контрольные точки являются функцией, которую вы можете выполнять из Hyper-V Manager нажатие правой кнопки по одной или большему числу ВМ. Она в действительности создаёт моментальные снимки в определённый момент для данной ВМ. Другим способом взглянуть на контрольные точки является то, что они создают точки отката для ваших серверов. Если вы создаёте контрольную точку во вторник, а в среду кто- то вносит изменения в настройку на этом сервере, которая вызывает проблемы, вы можете восстановить свою контрольную точку от вторника и вернуть эту ВМ назад в состояние того дня недели.

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

Эти установки являются индивидуальными для каждой исполняемой вами ВМ; например, вы можете рассматривать контрольные точки для WEB1 иначе чем для WEB2. Способом по умолчанию для обработки этих моментальных снимков по времени именуется Production checkpoints (Промышленными контрольными точками). Обычно это предпочтительный способ создания таких быстрых образов ваших серверов, поскольку он является самым ясным методом. При выборе генерации неких Промышленных контрольных точек Hyper-V вызывает функции резервного копирования Windows внутри собственной операционной системы этой ВМ для создания некой резервной копии этого сервера. Это было бы аналогично тому чтобы вы зарегистрировались в этой ВМ и вручную запустили бы задачу резервного копирования операционной системы. Имейте в виду, что когда вы это делаете, а следовательно для вас это выполняет Hyper-V, это не означает поблочное идентичное резервное копирование данной ВМ на тот момент когда она исполняется, а вместо этого некий файл резервной копии, который впоследствии будет восстановлен чтобы вернуть файлы данной операционной системы обратно к этому моменту времени. Иными словами, Промышленные контрольные точки возвращают Windows обратно к её предыдущему состоянию, однако все приложения и данные, которые непрерывно изменялись в данном сервере не будут фиксированы.

В качестве альтернативы, именно это делает вариант со Standard checkpoints (Стандартными контрольными точками). В этом случае выполняется более быстрый и без предосторожностей захват вашей ВМ, некая разновидность того что вы кликнули правой кнопке файла жёсткого диска VHDX и выбрали скопировать его в какое- то место. Восстановление стандартных контрольных точек может быть запутанным процессом, так как если ваша контрольная точка была создана в тот момент когда ваш сервер пребывал посреди некой важной функции, её восстановление приводит вас обратно к тому состоянию когда это приложение будет пребывать посреди той же самой важной функции. Для чего- то подобного записи в базу данных это может вызвать сложности.

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

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

Хотя настройки оборудования для ВМ необходимо выполнять через Менеджер Hyper-V, ваше ежедневное взаимодействие с этими ВМ, выполняющимися в качестве серверов в вашей среде не обязательно означает что вы должны регистрироваться на своём сервере Hyper-V во что бы то ни было. Как вы уже видели, если вам случилось оказаться внутри Менеджера Hyper-V каким- либо образом, тогда вы можете быстро и просто применить функцию Connect чтобы взаимодействовать с консолями ваших серверов через использование инструментов Консоли Hyper-V. Доступ к вашим серверам таким образом является предпочтительным если вам нужно посмотреть что- либо в BIOS или где- либо ещё за пределами вашей операционной системы Windows которая работает на этой ВМ, однако такой уровень консольного доступа не так уж часто и требуется.

Когда у вас имеются Windows Server работающие в качестве ВМ, более распространённым для взаимодействия с такими серверами является в точности те же самые способы, которыми вы взаимодействуете со своими физическими серверами в вашей сетевой среде. Хотя я и осуществил доступ к своему серверу WEB3 через Консоль Hyper-V, как это было на протяжении этой главы, теперь у меня имеется установленный на WEB3 Windows Server 2019 и я включил возможности RDP в нём, нет причин почему бы я не мог просто открыть MSTSC и зарегистрироваться в WEB3 таким образом, прямо со своего рабочего стола:

То же самое справедливо и для PowerShell. Так как эта ВМ совершенно рабочая и имеет установленную серверную операционную систему, я могу применять PowerShell удалённо для манипуляций со своим сервером WEB3, так же как и с прочими серверами со своего компьютера рабочего места. Раз вы завершили построение своих аппаратных средств и установки операционной системы на ВМ, становится более редким событием то, что вам в действительности нужно использовать Консоль Hyper-V чтобы взаимодействовать с этим сервером. Основные причины, по которым открывается Диспетчер Hyper-V состоит в том чтобы достичь некой ВМ и внести изменения на аппаратном уровне в данном сервере, такие как добавление некого жёсткого диска, регулировка ОЗУ, либо перемещение сетевого подключения с одного коммутатора на другой.

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

Если ваши повседневные задания не содержат работы с Hyper-V, скорее всего вы никогда и не слышали о защищённых (shielded) ВМ. Само название даёт достаточно хорошее задание для пояснения данной технологии на базовом уровне. Если некая ВМ является виртуальной машиной, то защищённая ВМ должна быть некой ВМ, которая защищена или экранирована неким образом, не так ли?

Некая защищённая ВМ это ВМ, которая зашифрована. А скорее, зашифрован при помощи BitLocker сам файл жёсткого диска (VHDX). Это звучит просто, но для этого существует ряд основательных требований. Для надлежащей работы BitLocker в вашу ВМ встраивается некий виртуальный чип TPM (Trusted Platform Module, Модуль Доверенной платформы). TPM быстро превращается в обычную принадлежность на аппаратном уровне, но на самом деле его использование остаётся загадочным чёрным ящиком для большинства администраторов. Защищённые ВМ можно просто заблокировать на работу только на жизнеспособных и удостоверенных серверах хостинга, что для нас предоставляет удивительное преимущество когда мы озабочены безопасностью. Такая возможность обеспечивается несколькими различными вариантами аттестации, которые мы вскоре обсудим.

Чтобы пояснить те преимущества, которые приносят нам на стол защищённые ВМ, мы собираемся рассмотреть пример, того что происходит когда виртуальные машины не защищены. Имейте в виду, что идея защищённых ВМ является несколько более важной когда вы рассуждаете о размещаемых в облачном решении серверах, когда у вас нет доступа к самому серверу или когда вы размещаетесь в неком ином подразделении внутри вашей компании, таком как частное облачное решение. Пока вы не нашли времени развернуть защиту на все ВМ в своём окружении, то что я вам собираюсь продемонстрировать так это то, что это можно выполнить на любой из ваших уже имеющихся виртуальных машин.

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

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

Теперь давайте слегка развлечёмся и превратимся в злоумышленника. Я мерзкий сотрудник поставщика облачных услуг и я решил что произведу некие разрушения, прежде чем выйду за дверь. Достаточно просто будет мне убить такой сервер WEB3 полностью, так как у меня имеется доступ к главной консоли администратора хоста. Тем не менее, скорее всего будет вывешен некий флаг где- то и такой арендатор просто смог бы раскрутить новый веб- сервер, либо восстановить его из резервной копии. Поэтому будет даже лучше вместо разрушения такой ВМ, чтобы я оставил его запущенным, а затем изменил всё содержимое самого веб- сайта. Давайте дадим клиентам этой компании повод поговорить об этом!

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

Для начала я регистрируюсь на этом сервере Hyper-V и отыскиваю местоположение нужного файла VHD, который использует WEB3. Это всё находится на моём сервере, поэтому мне не нужно иметь полномочия какого- либо арендатора для входа туда. Я просто кликаю правой кнопкой по этому VHD и выбираю Mount:

Теперь, когда этот VHD смонтирован напрямую в операционной системе сервера данного хоста, я могу просмотреть жёсткий диск этой ВМ, как если бы он был одним из моих собственных дисков. Переместимся в папку wwwroot чтобы отыскать все файлы данного вебсайта и изменим имеющуюся страницу по умолчанию чтобы она отображала то что нужно нам:

Когда я завершу свою игру с этим вебсайтом, я смогу открыть Disk Management щёлкнув правой кнопкой по этому смонтированному диску и выбрать Detach VHD чтобы покрыть свои дорожки:

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

Что вы должны думать о поставщике виртуальных машин в данном облаке теперь? Этот пример врезается в самую сердцевину того почему так много компаний боятся сделать этот начальный шаг в размещение в облаках - существует просто неизвестный уровень безопасности для таких сред. К счастью Microsoft облегчил такую безопасность лазейки своей новой технологией под названием защищённые ВМ (shielded VM).

Лежащая в основе защищённых ВМ идея очень проста. Microsoft уже имеет великолепную технологию шифрования диска под названием BitLocker. Защищённые ВМ являются виртуальными машинами которые имеют включённым шифрование диска BitLocker, никто не имеет возможности получить обходной доступ к такому диску. Попытка смонтировать этот VHD навроде того, что мы только что успешно выполнили приведёт в результате к сообщению об ошибке, ничего больше:

Ещё лучше то, что при настройке вашей инфраструктуры для поддержки защищённых ВМ вы также блокируете доступ Консоли Hyper-V к тем ВМ, которые являются закрытыми (экранированными). Хотя это само по себе не является таким крупным достижением как шифрование диска, это всё- таки достаточно важно отметить. Если кто- то имеет доступ к подобному серверу хоста Hyper-V и откроет Hyper-V Manager, они не будут вообще иметь возможности использовать функцию Connect на ВМ этого арендатора чтобы просмотреть что- либо в настоящий момент в этой консоли. Более чем вероятно, что это сохранит им возможность запуска экрана регистрации, который, как мы надеемся, они не смогут взломать, однако если бы консоль такой ВМ кем- то была оставлена в зарегистрированном состоянии, они бы смогли моментально получить доступ для манипуляций с такой ВМ, даже если бы её диск и был зашифрован. Поэтому, когда вы создаёте защищённую ВМ, это не только шифрует ваш VHD с помощью технологии BitLocker, но это также блокирует весь доступ к такой ВМ из основной Консоли Hyper-V.

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

Имеется пара важных моментов в данной головоломке, о которых вам следует знать, раз уж вы интересуетесь исполнением защищённых ВМ.

Хосты под охраной

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

Хосты под охраной обязаны исполнять Server 2016 Datacenter или Server 2019 Datacenter, а также обычно вы желаете от них загрузки с помощью UEFI, а также наличия чипа TPM 2.0. Хотя TPM 2.0 не является строгим требованием, его наличие настоятельно рекомендуется.

Эти охраняемые серверы хостинга затем занимают место ваших обычных Серверов Hyper-V. Хостинг ваших ВМ именно то что является заданием для ваших ВМ.

HGS (Host Guardian Service)

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

HGS является критически важным для создания некой работающей охранной фабрики. В случае отказа HGS никакая из ваших защищённых ВМ не будет запущена!

Для HGS существует ряд различных требований, которые зависят от того какой именно режим аттестации намерены применять ваши хосты под охраной. В последующих разделах данной главы мы изучим дополнительно эти режимы. HGS обязан исполняться на Server 2016 или Server 2019, а в более общем случае вы пожелаете применять для данной службы три физических сервера работающими в неком кластере из трёх узлов.

Мне бы также хотелось указать на некую возможность HGS, которая является совершенно новой в Windows Server 2019: HGS cache. Предыдущее ограничение защищённых ВМ Server 2016 состояло в том, что для HGS требовался контакт всякий раз когда любой охраняемый хост желал бы раскрутить какую- то защищённую ВМ. Это могло становиться проблематичным если HGS становился недоступным по какой- то временной причине. В Server 2019 новым является кэш HGS для ключей ВМ с тем чтобы некий охраняемый хост был способен запускать доверенные ВМ на основе ключей из данного кэша вместо того чтобы проверять вживую всякий раз HGS. Это может быть полезным при отключении HGS (хотя полное отключение HGS и может означать что у вас имеется большая проблема), однако хэш HGS может иметь более верный вариант применения в случае филиалов при плохом сетевом соединении с HGS.

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

Существует два различных режима, которые могут применять такие охраняемые хосты для прохода аттестации в HGS. Ну ладно, в действительности имеется три, но один уже признан устаревшим. Давайте потратим минутку на разбор подробностей тех трёх различных режимов, которые могут применяться между вашими охраняемыми хостами и вашим HGS.

Аттестация доверенным TPM

Именно это самый лучший способ! Чипы TPM являются физическими чипами, устанавливаемыми в материнские платы ваших серверов, которые содержат уникальную информацию. Что наиболее важно, так это то что эта информация не может быть изменена или взломана изнутри самой операционной системы Windows. Когда ваши охраняемые серверы снабжены чипами TPM 2.0, это открывает двери выполнения некой невероятной мощности аттестации хостов. Такой хост применяет Безопасную загрузку и некие проверки целостности кода, который хранится внутри данного TPM для проверки того что он жизнеспособен и не подвергался изменениям. Затем HGS осуществляет дополнительную проверку по другим источникам той информации, которая была предоставлена TPM и той информации, о которой ему известно на момент первоначальной настройки охраняемого хоста чтобы убедиться что данный запрашиваемый хост на самом деле один из тех, которому доверена роль охраняемого хоста и что он не подвергался вмешательству в свою работу. Если вы настраиваете новые серверы Hyper-V, убедитесь что они содержать чипы TPM 2.0 с тем чтобы воспользоваться данной функциональностью.

Аттестация ключом хоста

Если ваше оборудование не предоставляет возможностей TPM, мы можем выполнять более простую аттестацию ключа хоста. Данная возможность для выработки вашими охраняемыми хостами некого ключа хоста, который может быть известен HGS и проверяться им является новой для Windows Server 2019. Она применяет технологию несимметричной пары ключей для удостоверения охраняемых хостов. В основном вы будете либо создавать новую пару ключей хоста или применять уже имеющиеся сертификаты, а затем отправлять общедоступную часть этого ключа или сертификата в HGS. Когда охраняемые хосты раскручивают некую защищённую ВМ, они обращаются за аттестацией к HGS и такая аттестация подтверждается или в отклоняется на основании этой пары ключей.

Безусловно, это более быстрый и более простой способ превратить в реальность ваши защищённые ВМ в вашей же сетевой среде, но он не настолько же безопасен как доверенная TPM аттестация.

Аттестация администратором - устаревшая в 2019

Если вваша среда новая и основана на Server 2019, не тратьте своё время на это. Тем не менее, имеются парни, которые исполняют защищённые ВМ в инфраструктуре Windows Server 2016 и в таком случае существует некая дополнительная возможность для аттестации. Обычно именуемая как подтверждаемая администратором аттестация, это был самый простой (и не самый безопасный) способ аттестации ваших хостов для HGS, который можно было выполнять. В его основе вы создаёте некую группу безопасности Active Directory (AD), добавляете в эту группу свои охраняемые хосты, а затем HGS рассматривает всякий являющийся частью этой группы хост как подтверждённый в качестве охраняемого для запуска защищённых ВМ.

Многие компании применяют Linux в той или иной степени. Применение Linux на самом деле может быть сбалансировано для осуществления теперь великого входа в мир Windows Server, когда у нас имеется такой наивысший уровень интеграции, который возможен в Windows Server 2019. Имеется целый ряд вариантов которыми Server 2019 теперь может применяться для взаимодействия с ВМ Linux:

Хотя файловые системы и функции дедупликации и являются технологиями, которые вы скорее всего не ожидаете обсуждать когда речь идёт о Hyper-V, улучшения связанные с ReFS и дедупликацией данных в Сервере 2019 несут некие гигантские преимущества для серверов Hyper-V. Если эти понятия вам не знакомы, давайте уделим минутку и дадим определения ReFS и дедупликации.

Всякий кто поработал на компьютерах будет знать о FAT, FAT32 и NTFS. Это файловые системы, которые могут применяться при форматировании жёстких дисков. Различные версии файловых систем переходят в различные возможности применения такого жёсткого диска. В течении целого ряда лет NTFS была de facto стандартом для всех подключаемых в машинам Windows жёстких дисков.

Это продолжалось вплоть до Windows Server 2016. Теперь у нас имеется иной вариант с названием ReFS. Даже если вы постоянно работаете в ИТ подразделении, вы могли никогда не слышать об ReFS, так как до сих пор она не имела слишком широкого распространения. Она в первую очередь применялась в серверах, которые вовлечены в S2D (Storage Spaces Direct, Непосредственные пространства хранения). Если это самая последняя и величайшая файловая система от Microsoft, почему она не применяется в качестве варианта по умолчанию для любой новой системы? В первую очередь по той причине, что ReFS не является загружаемой файловой системой. Это незамедлительно исключает возможность для систем с единственным жёстким диском для работы с ReFS на этом диске целиком. Что означает, что ReFS предназначена для вторичных томов в серверах, которые имеют целью хранение больших объёмов данных.

При тех обстоятельствах, когда вы форматируете некий вторичный том под ReFS и сохраняете в нём данные, имеются некие великолепные преимущества в плане надёжности и производительности при применении ReFS вместо NTFS. Эти преимущества были разработаны с целью лучшей работы реализации S2D.

Дедупликация данных это просто наличие возможности для вычислительной системы обнаруживать множество являющихся идентичными бит данных на диске и вычищать их. Если в некой системе имелось шесть копий в точности одного и того же файла, дедупликация способна удалить пять из них, оставляя для имеющихся целей в шести местоположениях один. Эта идея позволяет сбережение некого значительного пространства. Сама по себе дедупликация не нова; у нас имелись некие такие возможности ещё в Серверах 2012.

Именно Windows Server 2019 стал самой первой платформой, в которой стало возможным включение дедупликации в отформатированных под ReFS томах.

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

ReFS имеет некие большие преимущества в надёжности и производительности над NTFS и следовательно также очевидно что файлы VHDX будут лучше обслуживаться при их хранении в томе ReFS.

Windows Server 2019 является самой первой платформой в которой вы можете это приготовить и употребить. Теперь у нас имеется возможность создавать некий том ReFS для хранения жёстких дисков виртуальных машин, а также для включения дедупликации в этом самом томе.

Очень легко возбудиться виртуализацией. Построить некое аппаратное решение, установить Windows Server 2019, реализовать роль Hyper-V и бам! Вы готовы начать перекатывать сотни и тысячи ВМ в своей среде ... так?

Несомненно. Мы ещё не обсудили лицензирование, а очень часто наша технологическая удаль ограничена требованиями лицензирования. То же самое верно и для Hyper-V. Каждая ВМ, которую вы раскручиваете, конечно, должна иметь свою собственную лицензию операционной системы. Это верно и для Hyper-V. Конечно, каждая раскручиваемая вами ВМ обязана иметь свою собственную лицензию операционной системы. Это требование имеет смысл. Что менее очевидно, так это тот факт, что вы можете исполнять на своём сервере Hyper-V только определённое число ВМ, в зависимости от того какой SKU вы применяете для самой операционной системы вашего хоста.

Самая большая засада, которая застаёт людей врасплох это то, что применение Windows Server 2019 Standard Edition в качестве вашего сервера Hyper-V имеет результатом исполнение только двух ВМ. Двух! Именно так, и не больше. Вы будете способны запускать пару виртуальных машин и потом будете ограничены в исполнении дополнительного числа. Очевидно, Standard Edition SKU не разработан для использования в качестве сервера Hyper-V.

Это оставляет вас с Windows Server 2019 Datacenter Edition. К счастью, Datacenter позволяет вам исполнять неограниченное число ВМ! Это великолепная новость! За исключением одной вещи - Datacenter Edition стоит много тысяч долларов. Это очень ограничивающий фактор для развёртывания серверов Hyper-V.

Все эти разговоры о лицензировании и как неуклюже и дорогостояще это может быть приводит к одной точке - Hyper-V Server 2019. Постойте, но разве это не Windows Server 2019 с установленной ролью Hyper-V? Нет, вовсе нет.

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

Гигантское преимущество Hyper-V Server 2019 - он СВОБОДНО РАСПРОСТРАНЯЕТСЯ. Вы всё ещё несёте ответственность за лицензии для каждой своей ВМ самой по себе, конечно, однако иметь свободную операционную систему которая может исполнять неограниченное число ВМ - теперь это нечто с чем мой бумажник может в действительности согласиться.

Я создал установщик ISO для Hyper-V Server 2019 на DVD и только что завершил установку его на своё оборудование. Установка самой по себе операционной системы было достаточно привычным, все экраны установки и опции были теми же самыми, как если бы устанавливалась полная версия Windows Server 2019. Однако, теперь, когда установщик завершил свою работу и я загрузился в реальную операционную систему своего Hyper-V Server 2019, всё выглядит совершенно по- другому:

Нам предоставлена только приглашение командной строки, а внутри этого приглашения имеется автоматически запускающаяся утилита настройки с названием SConfig. Применяя здесь свою клавиатуру я могу выполнять вещи подобные установке имени хоста этого сервера, присоединения к домену, а также изменения настроек сети. Когда вы завершите применение интерфейса CLI для настройки основных требований на этом сервере, нам на самом деле нет необходимости осуществлять доступ к основной консоли этого сервера Hyper-V вновь, пока нам не понадобится вернуться и посетить повторно этот экран настроек чтобы изменить что- то. Вместо этого, после настройки своего сервера Hyper-V, вы просто применяете Hyper-V Manager или PowerShell, или другой сервер или рабочее место внутри своей сетевой среды для удалённой врезки в управление своими виртуальными машинам, которые работают на этом сервере Hyper-V.

На следующем снимке экрана вы можете видеть, что я запустил Диспетчер Hyper-V на своей машине Windows 10, которой довелось иметь установленной роль Hyper-V. Здесь я могу кликнуть правой кнопкой по Диспетчеру Hyper-V и выбрать Connect to Server.... А затем я ввожу название своего нового сервера Hyper-V и эта консоль создаст некое удалённое подключение. В этом удалённом подключении я могу применять функциональность своего Диспетчера Hyper-V Windows 10 в точности как если бы они непосредственно работали на этом новом сервере Hyper-V:

Аналогично тому способу, каким удалённо выполняется большая часть задач для Сервера ядра (Server Core) или Нано сервера (Nano Server) - при помощи использования удалённых консолей или PowerShell - мы выполняем всё непрерывное сопровождение и администрирование такого сервера Hyper-V, происходящее на вашей консоли Менеджера Hyper-V.

Hyper-V Server даёт вам преимущества безопасности интерфейса без GUI, объединённые с преимуществами гибкости размещения неограниченного числа виртуальных машин, а также вопрос стоимости с которым никто не может поспорить!

Я не располагаю официальными цифрами, однако я рискую заявить, что сегодня уже больше работающих виртуальных серверов, чем физических серверов, поддерживающих наш мир на плаву. Хотя и продолжается баталия в ранжировании между тем какая из платформ является наилучшей - обычно аргументы разделяются между либо Hyper-V, либо VMWare - вы не можете игнорировать тот факт, что виртуализация является дорогой в будущее. Microsoft затратил большой объём времени и ресурсов чтобы обеспечить уверенность, что Hyper-V всегда останется на вершине этой игры и с каждым выпуском вводит всё больше и больше свойств с тем, чтобы вы могли сохранять свою виртуальную инфраструктуру в работе, причём работающей великолепно, на протяжении всего времени. Являются ли возможности облачной виртуализации даже более мощными чем предоставляемые в рамках Сервера Hyper-V? Я бы сказал да, потому что вся инфраструктура, которая находится на месте облачной службы поставщика собирается быть самым всемогущим волшебником Оз в сравнении с тем, что отдельная компания может предоставить в своём собственном центре обработки данных. Означает ли это что вы можете совершенно забыть об Hyper-V и просто использовать сервера предоставляемые из облака? Может быть когда- то, однако эти дни наступят не скоро. Потребность в собственных серверах и службах всё ещё огромна, а некоторые отрасли просто никогда не смогут себе позволить размещать свои данные и приложения у стороннего производителя. Понимание возможностей Hyper-V и способность выстраивать эту инфраструктуру с самых основ даст вам главное преимущество при поиске или получении работы в ориентированной на Mcrosoft организации.

Это подводит к концу нашего повествования о новом Windows Server 2019. Многие из обсуждавшихся тем достаточно всеобъемлющи чтобы заполнить собой целые книги, и я надеюсь что идеи предоставленные в этом томе достаточны чтобы пригласить вас погрузиться глубже в эти технологии с которыми вы планируете работать. Технологии Microsoft царствуют как король в большинстве центров обработки данных повсеместно. Новые о усовершенствованные свойства внутри Windows Server 2019 гарантируют что эта тенденция продолжится далеко в будущее.