Глава 12. Работа с Hyper-V
Содержание
- Глава 12. Работа с Hyper-V
Сегодня администраторы сервера едят, спят и дышат виртуальными машинами. Они наводняют нашу инфраструктуру вычислений, быстро заменяя физические серверы во всех аспектах нашей технологии. К счастью, вход в мир виртуализации становится достаточно простым когда вы знаете какие части головоломки должны работать вместе чтобы приступить к построению виртуальных машин. Я работал со многими администраторами серверов, которые сами управляют имеющимися виртуальными машинами, когда они находятся в Интернете, однако в крупных организациях обычно именно находящийся во внутренней среде в первую очередь создаёт такие ВМ. Это означает, что даже когда кто- то, кто ежедневно работает с серверами Windows каждый день, может не иметь достаточного опыта в работе с применением Консоли управления Hyper-V, и это является причиной, по которой важно включить в данную книгу про Windows Server 2016 главу об Hyper-V саму по себе. Данная глава рассмотрит следующие темы:
-
Создание Windows Server который исполняет Hyper-V
-
Создание Hyper-V
-
Настройка сетевой среды ВМ
-
Построение вашей первой виртуальной машины
-
Применение страницы настроек ВМ
-
Изменение виртуальных жёстких дисков
-
Использование Контрольных точек в качестве пунктов отката
Когда мы говорим о виртуализации сервера, важно отметить разницу виртуализацией хоста и виртуальной машины. Хост сервер является важной птицей, причём (обычно) физической платформой, которая предоставляет все необходимые ресурсы виртуальным машинам меньшего размера. Существует два основных игрока в категории таких виртуальных хостов. Компания с названием 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 {Прим. пер.: см., например, наши переводы вторых изданий Hyper-V 2016, Практический опыт, октябрь 2016, и изданной в январе 2017Книги рецептов Windows Server 2016 Hyper-V.} Данная глава сосредоточится на шагах, которые вам необходимы для начала использования, а также в качестве краеугольного камня исполнения среды виртуализации. Чтобы выйти за пределы рецептов данной книги, не забудьте ознакомиться с такими разделами, как Кластеризация и репликация Hyper-V, поскольку вы теперь можете строить среду, в которой все ваши сервера имеют находящиеся в горячем резерве дубликаты, расположенные на заднем плане в ожидании вызова для вступления в действие. Hyper-V может быть центральным местом в вашем плане восстановления после сбоев. Кроме того, в Server 2016 имеется новая идея вложенной виртуализации, при которой вы можете получать виртуальные машины, исполняются внутри Hyper-V и при этом устанавливают роль Hyper-V на саму виртуальную машину! Зачем в современном мире вам это может понадобиться? "Чтобы применять контейнеры" является ответом номер один на данный вопрос, так как вы начинаете расширять свои возможности DevOps при использовании Windows Server и контейнеров Hyper-V для предоставления крохотных, безопасных, стандартизованных платформ для разработки и расширения приложений.
Перед тем, как вы начинаете строить виртуальные машины для применения в своей среде, вначале вам необходим сервер хоста виртуализации на котором будет работать Hyper-V. Первый предмет рассмотрения, который необходимо принимать во внимание, это аппаратные средства. Требования к аппаратным средствам для исполнения Hyper-V сервера зависят от того, сколько виртуальных серверов вы планируете запускать поверх такой хост платформы. Например, сервер, который я использую для лабораторной среды показываемый на протяжении данной книги имеет процессор Intel i3 всего с 8ГБ оперативной памяти. Это не является благоприятным для успешной среды Hyper-V. Я могу включить только четыре или пять ВМ за раз, причём каждая из них с минимальным объёмом памяти на виртуальную машину. Все они работают крайне медленно. Множество процессоров Xeon со 100ГБ оперативной памяти, или даже больше, становятся критерием, если вы собираетесь исполнять десятки серверов в рамках своей виртуальной среды. Или вы можете встретить числа в промежутке между приведёнными значениями если вы исполняете от одного до 10 серверов. Здесь не существует правильного ответа. просто убедитесь, что у вас имеется достаточно выделенной оперативной памяти для каждой ВМ, которая ей необходима, плюс объём достаточный для самой операционной системы хоста с тем, чтобы он продолжал работать надлежащим образом. Пространство жёстких дисков также является предметом рассмотрения, так как вам необходимо быть уверенным, что у вас имеется достаточное физическое пространство для всех тех серверов, которые вы планируете раскручивать.
Когда вы определились с аппаратными средствами, ваше следующее решение в том, какую версию Windows Server 2016 необходимо устанавливать. Если вам приходилось проходить процесс установки, вы будете знать что у вас имеются варианты для Server 2016 Standard и Server 2016 Datacenter. Одно из основных соображений, которое я могу вам предложить относительно данной темы состоит в том, что стандартная единица учёта (Standard SKU, stock-keeping unit) Windows Server позволяет вам исполнять всего две виртуальные машины! Если это не полностью отвечает вашим потребностям, вам лучше заглянуть вперёд и установить Windows Server 2016 Datacenter. Забегая вперёд: не забудьте проверить следующий рецепт в этой главе на предмет третьего варианта. Предупреждение- спойлер: оно намного менее затратно нежели Datacenter SKU!
У меня имеется фрагмент серверного оборудования на которое я установил редакцию Windows Server 2016 Datacenter. Это позволит мне раскручивать неограниченное число виртуальных машин с точки зрения перспектив лицензирования. Имейте в виду, что каждая создаваемая вами виртуальная машина, которая исполняет Windows Server также потребует ключ сервера; здесь нет халявы с лицензиями операционной системы {Прим. пер.: если не считать таковой Партнёрскую программу Microsoft.}
Я уже установил Windows Server 2016 Datacenter на своё оборудование. В данном сервере у меня имеется два NIC, так как Hyper-V предпочитает иметь выделенный NIC для взаимодействий операционной системы хоста. Второй NIC может применяться в качестве моста между виртуальными машинами и моей физической сетевой средой. Для установки роли Hyper-V выполните следующие шаги:
-
Откройте Диспетчер сервера и кликните по ссылке Add roles and features.Кликайте по Next пока не достигните окна Select server roles. Здесь вы просто выбираете флаговую кнопку для Hyper-V.
-
В качестве альтернативы, причём это может быть очень полезно для сервера Hyper-V, исполняющегося в режиме Сервера ядра, следующий cmdlet PowerShell установит роль Hyper-V и его функциональность управления:
Add-WindowsFeature Hyper-V, RSAT-Hyper-V-Tools, Hyper-V-Tools, Hyper-V-PowerShell
-
Следуя за установкой данной роли вы должны будете перезагрузить свой сервер. Когда он вернётся назад в рабочее состояние, проследуйте в Диспетчер сервера и запустите Hyper-V Manager для первого раза из меню Tools (Средства).
-
Следующий снимок экрана предоставляет вам взгляд на Hyper-V Manager. Именно при помощи этиго инструментов вы будете наиболее часто взаимодействовать со своими виртуальными машинами, которые вы исполняете на данном сервере хоста виртуализации. Как мы будем обсуждать в последующих рецептах, существует множество вариантов которыми вы можете взаимодействовать с исполняющим Hyper-V сервером, а также множество различных способов, которыми вы можете исполнять Консоль диспетчера Hyper-V.
Реализация роли Hyper-V в вашем новом Windows Server 2016 является самым первым шагом на пути к виртуализации вашей инфраструктуры. Вам необходимо аккуратно спланировать потребности в аппаратных средствах, убедится что у вас имеется пространство для манёвра в случае, если вы в результате получите большее число серверов или сервера большего размера, нежели изначально планировали. теперь, когда ваш хост виртуализации Hyper-V запущен и имеет установленной данную роль, а также прошёл свою начальную настройку, настало время на самом деле воспользоваться Консолью диспетчера Hyper-V.
Важный относящийся к установке роли Hyper-V элемент, на который стоит обратить внимание, состоит в возможности установки роли Hyper-V на некую виртуальную машину! В отрасли это называется Вложенной виртуализацией (Nested Virtualization). Ваши виртуальные серверы могут содержать другие виртуальные серверы. В чём смысл этого? В первую очередь это обусловлено некоторой новой функциональностью в Server 2016, относящейся к контейнерам, а также Нано серверам, однако это также интересный момент для того, чтобы вы потратили некоторое время на осознание того, что будет наилучшим вариантом построения вашего собственного окружения виртуального сервера.
Подождите минутку, а разве не это мы только что сделали? Нет. То что мы сделали в предыдущем рецепте, это мы установили роль Hyper-V на некий обычный сервер Windows Server 2016. Вы можете реализовать Hyper-V на сервере выполняющемся в Снабжённом рабочим столом режиме, Сервере ядра или даже Нано сервере для размещения виртуальных машин. Однако именно реальный Сервер Hyper-V с другой стороны, является чем-то ещё, что представляет собой всё это вместе.
Когда вы построили Windows Server 2016 и установили в нём роль Hyper-V, это приятно и просто настраивается и является тем способом, которым большинство администраторов строят свои хосты виртуализации. Однако существует пара изъянов, главным образом относящихся к стоимости. Как мы уже упоминали, если вы применяете в качестве хоста Windows Server 2016 Standard, вам будет доступно исполнение только двух виртуальных машин. Это существенный ограничивающий фактор. С другой стороны вы можете установить на своём хосте Windows Server 2016 Datacenter и после этого запускать неограниченное число ВМ, однако стоимость Datacenter существенно выше таковой у сервера Standard.
В этом значение сервера Hyper-V. Он является совершенно другим файлом установки, который вы можете свободно загружать с сайта Microsoft. Будучи введённым в строй, такой сервер Hyper-V не имеет связанных с ним стоимостей лицензирования. Конечно, для каждого обычного Windows Server, который вы размещаете поверх своего сервера Hyper-V присутствуют затраты на лицензию, связанные с ним. Однако сама машина хоста сервера Hyper-V абсолютно бесплатна. А кроме того, вы можете запускать на ней неограниченное число ВМ! Учитывая слово "бесплатно", вы можете предположить, что сервер Hyper-V станет преобладающим внутри наших центров обработки данных, но в действительности это не так. Я полагаю, что это результат двух факторов. Первый состоит в том, что многие администраторы могут даже не знать, что существует сервер Hyper-V. Второй заключается в том, что интерфейс для Сервера Hyper-V во многом аналогичен Серверу ядра, и не очень комфортно ощущение, когда ты знаешь, что консоль вашего супер- важного, массивного сервера хоста Hyper-V сопровождается только предоставлением вам приглашения командной строки в качестве единственного интерфейса с ним.
Давайте вместе установим Сервер Hyper-V с тем чтобы вы поняли что, да как, а затем мы также взглянем на управление ВМ из этого сервера Hyper-V. Поверьте мне, это совсем не так сложно, как вы могли бы предположить.
У нас имеется новый сервер, поверх которого мы собираемся установить Hyper-V Server 2016. Мы также будем применять Windows Server 2016, который исполняется в режиме, Снабжённом рабочим столом (Desktop Experience) чтобы продемонстрировать удалённое управление сервером Hyper-V.
{Прим. пер.: Поскольку в Windows 8 и Windows Server 2012 (а также, скорее всего, в 2016) был удалён RPC интерфейс Удалённого доступа к PNP, При работе с Сервером Hyper-V вам могут понадобиться Device Management PowerShell Cmdlet. Данный модуль поддерживает следующие cmdlet:
-
Get-Device
-
Get-Driver
-
Get-Numa
-
Enable-Device
-
Disable-Device
}
Для реализации и проверки своего первого сервера Hyper-V выполните следующие шаги:
-
Вам необходимо загрузить установочный ISO с сайта Microsoft. Откройте Bing и наберите в строке поиска "
Download Windows Hyper-V Server 2016
" чтобы отыскать этот файл. {Прим. пер.: На момент перевода работает ссылка https://www.microsoft.com/ru-ru/evalcenter/evaluate-windows-server-2016/.} -
После загрузки перепишите загрузочный файл на диск DVD или сделайте ещё шаг и примените инструмент для переноса ISO на USB чтобы создать загрузочный носитель такого вида. После этого загрузите новое серверное оборудование с такого носителя.
-
Как вы можете обнаружить, мастер установки выглядит совершенно аналогично тому, как он представлен в обычном установщике Windows Server 2016. Самая большая разница состоит в том, что этот установщик не делает паузу для вопроса о том, какую версию операционной системы вы желаете устанавливать. После определения местоположения установки он немедленно запускает установку Hyper-V Server 2016.
-
Следуя за процессом установки вам будет представлено окно командной строки, которое выглядит невероятно похожим на то, которым мы пользовались при знакомстве с Сервером ядра.
-
Если вы нажмёте Ctrl + Alt + Delete, вам будет предоставлена возможность ввести пароль локального администратора. Вслед за этим изменением вы немедленно окажетесь в инструменте sconfig. данный инструмент является стандартным интерфейсом настройки для любого работающего с Сервером ядра, поэтому у вас имеется некоторый опыт работы с ним. Каак вы можете заметить, здесь у нас имеются доступные для выбора варианты, такие как изменение имени хоста, настройка сетевых установок, а также присоединение нашего нового Сервера Hyper-V к имеющемуся домену.
-
на самом деле, я просто прошёл этими шагами и установил имя хоста, IP адрес и членство в домене для своего сервера hyper-V.
-
Теперь, когда Hyper-V Server 2016 установлен и мы осуществили обычные установки настройки сервера, что дальше? Хорошо, роли и службы, необходимые для этой коробки чтобы исполнять сервер хоста Hyper-V уже включены в данную операционную систему, следовательно, всё что нам нужно сделать в данный момент, это определить как войти в Консоль управления Hyper-V чтобы приступить к построению ВМ. Для этого мы собираемся вернуться назад к нашей парадигме удалённого управления Microsoft.
-
Если вы желаете убедиться, что роль Hyper-V на самом деле установлена на вашем новом сервере Hyper-V , введите параметр с номером
14
в своей консоли sconfig. Это приведёт нас в обычную командную строку. В ней наберитеpowershell
и нажмите Enter чтобы перейти к интерфейсу PowerShell. -
Внутри PowerShell введите
Get-WindowsFeature -name *hyper*
- вы можете обнаружить, что роль Hyper-V уже установлена.
-
Зарегистрируйтесь на другом сервере или компьютере в своей сетевой среде и воспользуйтесь Консолью управления Hyper-V чтобы удалённо управлять этим новым Сервером Hyper-V. Вы можете либо зарегистрироваться в Windows Server, который имеет уже установленными инструменты управления Hyper-V, либо вы можете установить эти инструменты прямо поверх своего клиента Windows 10. Если вы работаете с Windows 10 Pro или Enterprise, у вас имеется возможность установить инструменты Hyper-V прямо на вашем настольном компьютере и после этого мы можем применять данные инструменты для манипуляций с этим сервером. Я собираюсь зарегистрироваться на своём клиенте
Win10
, установить инструменты Hyper-V из средств Turn Windows features on or off внутри панели управления (Control Panel), а затем запустить Диспетчер Hyper-V в этом настольном компьютере. -
Войдя вовнутрь, кликните правой кнопкой по Hyper-V Manager и выберите Connect to Server….
-
Введите имя вашего нового Сервера Hyper-V и нажмите OK.
-
теперь вы видите запущенную Консоль управления Hyper-V в компьютере клиента
Win10
, однако удалённо управляете службой Hyper-V, которая исполняется на этом новом сервере. Отсюда вы можете строить новые ВМ, манипулировать ВМ, а также делать всё что пожелаете обычно выполнять внутри Диспетчера Hyper-V, если бы он работал прямо на вашем сервере Hyper-V.
Сервер Hyper-V на самом деле является экземпляром Сервера ядра, который предварительно настроен с ролью Hyper-V. Самая большая разница между сервером Hyper-V и обычным Windows Server исполняющим роль Hyper-V состоит в стоимости и способе взаимодействия с самим этим сервером. Задействовав инструменты удалённого управления с другого сервера или напрямую с вашей рабочей станции, вы можете облегчить бремя изучения нового интерфейса, так как вы можете начать исследовать насколько подходит или нет Сервер Hyper-V под ваши цели. В оставшихся наших рецептах мы будем применять Hyper-V установленный поверх обычной версии Windows Server 2016, Снабжённой рабочим столом (Desktop Experience), однако того, что существует Сервер Hyper-V очень важно для того, чтобы планировать надлежащим образом свою инфраструктуру виртуализации.
После того, как ваш Сервер Hyper-V запущен и работает, какую бы ни было платформу вы бы не выбрали для применения, следующим логичным шагом было бы построение некоей виртуальной машины, не так ли? Итак, почему мы говорим о построении сетевой среды? Да потому что настройка сетевой среды к которой ваши ВМ собираются подключаться является важной основой и неплохо было пы потрать немного время на её обдумывание, прежде чем вы приступите к раскрутке новых ВМ. Каждая виртуальная машина будет иметь некий сетевой интерфейс, а иногда и более одного и, следовательно, эти NIC должны подключаться к коммутатору; в точности как и в случае с физическим сервером. Кроме того, в нашем виртуальном мире мы не применяем физические коммутаторы, мы должны должны сообщать ВМ в какой виртуальный коммутатор им необходимо проникать.
Также важно планирование правильного числа физических NIC, которые должны находиться внутри вашего сервера хоста Hyper-V. Очевидно, каждый физический NIC может быть присоединён только к одному физическому коммутатору и, следовательно, если вы планируете размещать виртуальные машины на данном сервере хоста, которому необходимо проникать в различные физические сетевые среды, вам необходимо в таком сценарии обеспечивать множество NIC. Каждый NIC в физическом сервере хоста может подключаться к различным коммутаторами, пропускающих обмен в различные области вашей сетевой среды. Затем, внутри Диспетчера Виртуального коммутатора (Virtual Switch Manager) мы можем построить виртуальные коммутаторы, которые будут соответствовать таким физическим NIC с тем, чтобы наши ВМ могли подключаться к любому выбранному нами месту нашей физической сетевой среды. В качестве простого примера, рассмотрим некий сервер DirectAccess, который необходимо присоединить к обеим сетевым среда, и к внутренней корпоративной, и к DMZ. Вам необходимо по крайней мере три NIC на таком физическом сервере хоста Hyper-V, так как один подключается к внутренней сетевой среде, один к сетевой среде DMZ, а также для самой операционной системы хоста на сервере Hyper-V предпочтительно иметь некий выделенный NIC для собственного взаимодействия.
Мы собираемся воспользоваться Windows Server 2016 исполняющим Hyper-V, который на протяжении данной книги размещает все виртуальные машины. Этот север имеет всего два NIC; к сожалению, данное ограничение имеющегося в моём тестовом блоке ограничения шасси. Для полнофункционального сервера Hyper-V более привычно иметь более двух сетевых физических интерфейсов.
Вот шаги, которые вам необходимо осуществить, чтобы создавать виртуальные сети в вашем сервере Hyper-V и управлять ими:
-
Запустите Hyper-V Manager изнутри меню Tools (Средства) Диспетчера сервера.
-
Вам представляется перечень установленных в вашей системе виртуальных машин, а в правой части вашего экрана существует панель Actions. Пройдите далее и кликните по ссылке Virtual Switch Manager….
-
Это экран, в котором вы будете определять все коммутаторы, котрые вам понадобятся для доступа со стороны NIC ваших ВМ для подключения к ним. Как вы можете понять из приводимого ниже снимка экрана, некий коммутатор присоединяется к моему физическому NIC в моём хосте Hyper-V подключённому к корпоративной сетевой среде и такой виртуальный коммутатор назван Physical NIC при начальной установке роли Hyper-V. Я легко могу изменить это имя внутри данного экрана с тем, чтобы оно отображало то описание, которое нужно мне.
-
Также имеются ещё два Private virtual switches, которые в настоящее время настроены в данном сервере. Это именно те коммутаторы, которые я создал чтобы выполнить построение данного сервера и те тестирования, которые мы осуществляли на протяжении всех глав. Как вы можете видеть, один помечен как Corp LAN, а второй я назвал Internet. Ни один из этих коммутаторов не подключён к физическому NIC, поэтому у них нет никакой возможности осуществлять взаимодействие вне данного сервера хоста. Такие виды коммутаторов полезны для построения отделённой среды тестовой лаборатории когда вам необходимо проверить новые технологии.
-
Если вы кликните по New virtual network switch, вы обнаружите, что у вас имеется вариант создания трёх различных видов виртуальных коммутаторов.
-
Давайте потратим минутку на описание разницы между этими тремя вариантами:
-
External: Этот вид виртуального коммутатора связывает себя с физическим адаптером сети в сервере хоста Hyper-V. Когда вы подключаете ВМ к некоторому внешнему виртуальному коммутатору, они получают возможность пропускать обмен вперёд и назад в такую физическую сетевую среду.
-
Internal: Этот вариант виртуального коммутатора не подключается к какому- либо физическому NIC и, следовательно, создаваемый в этом коммутаторе обмен не может осуществлять взаимодействие за пределами такой системы хоста. Однако, все ВМ, которые вы подключите к таким коммутаторам, имеют возможность взаимодействовать друг с другом и с самой системой хоста Hyper-V.
-
Private: Данный вид виртуального коммутатора именно то, что я применял в своей тестовой лаборатории. Это отделённый коммутатор, не имеющий возможности общаться ни с каким физическим NIC, а также не способный взаимодействовать с самим хостом Hyper-V. Все подключаемые к некоторому частному коммутатору ВМ будут иметь возможность осуществлять взаимодействие друг с другом, как это имело в случае с моим коммутатором Corp LAN, однако они будут изолированы друг от друга и ничего более.
-
-
Хотя я использую для данного рецепта совершенно новый Windows Server 2016 и мне видны только три стандартных вида коммутаторов в данном графическом интерфейсе, я бы хотел отметить что существует ещё два дополнительных вида коммутаторов Hyper-V, причём совершенно новые в Server 2016 и доступные к использованию. Почему они не видны в предыдущем снимке экрана? Потому что если вы желаете применять эти новые виды коммутаторов, вам необходимо развёртывать их через PowerShell. Вот общая суммарная информация об этих двух новых видах доступных нам в серверах Windows Server 2016 Hyper-V коммутаторов которые исполняются в стеке SDN (Software Defined Networking, Программно управляемый сетевой):
-
SET (Внешний коммутатор с коммутацией встроенных групп, External switch with Switch Embedded Teaming) - является совершенно новым в 2016 и позволяет нам группировать NIC прямо в коммутаторе Hyper-V, функциональность которая никогда не присутствовала в предыдущих версиях Hyper-V. Вы имеете возможность группировать от одного до восьми физических NIC в виртуальных сетевых адаптерах, что предоставляет отказоустойчивость в случае отказа одного NIC. При применении SET важно знать, что все такие адаптеры NIC должны быть установлены в одном и том же физическом сервере хоста Hyper-V, причём все такие NIC должны быть идентичными. Чтобы создать новый виртуальный коммутатор SET вы применяете cmdlet
New-VMSwitch
совместно с параметромEnableEmbeddedTeaming
. -
NAT: Windows Server 2016 также содержит новый тип коммутатора Hyper-V, называемый NAT. Вам следует устанавливать данный вид виртуального коммутатора когда вам необходимо, чтобы у виртуальных машин была возможность совместного использования внутренней сетевой среды и подключения к внешним интерфейсам с применением адресов NAT вместо их прямого связывания с внешним NIC и его собственным IP адресацией. NAT также не доступен из графической консоли при настройке нового коммутатора Hyper-V; вы используете cmdlet
New-VMSwitch
вместе с параметром-SwitchType NAT
для его построения. Такой новый тип коммутатора имеет практическую ценность в сценарии контейнеров.
-
У вас имеется возможность очень быстрого создания многих различных виртуальных коммутаторов в Диспетчере Виртуальных коммутаторов Hyper-V, поскольку вам необходимо поддерживать разные виды виртуальных машин, которые вы планируете создавать. В большей части проверочных сред имеет смысл применять внутренние или частные коммутаторы, чтобы быть уверенным, что обмен остаётся отделённым в рамках данного хоста. Это позволяет вам назначать адреса IP своим ВМ и предоставлять им возможность взаимодействия с вашей физической сетевой средой и такими местами как реальный Интернет. Важно иметь по крайней мере один из ваших виртуальных коммутаторов настроенным, прежде чем вы начнёте создавать море ВМ, поскольку, как вы увидите в следующем рецепте, одной из опций, которую вы можете настраивать в процессе создания ВМ является к какому из виртуальных коммутаторов она должна быть подключена.
Если ранее вы не работали с Диспетчером Hyper-V, вам скорее всего слегка будет не по зубам получить свою первую виртуальную машину поднятой и работающей! Существует ряд параметров, которые вы должны определить в процессе создания такой виртуальной машины. Давайте потратим несколько минут и пройдёмся вместе с тем, чтобы вы ознакомились со значением этих параметров и того, какие преимущества они могут привнести в общую таблицу.
Мы воспользуемся Windows Server 2016 с ролью Hyper-V и установленными средствами управления. Это единственное требование для данного рецепта.
Давайте пройдём следующие шаги чтобы создать совершенно новую виртуальную машину и установить некую операционную систему на эту ВМ.
-
В меню Диспетчера сервера Tools (Средства) откройте Hyper-V Manager или запустите его напрямую из папки Administrative Tools.
-
Кликните правой кнопкой по имени своего сервера Hyper-V рядом с правой верхней частью вашего экрана и выберите New | Virtual Machine….
-
Это запустит New Virtual Machine Wizard, пройдите далее и кликните Next чтобы перейти к реальной настройке.
-
Определите Name для вашей новой ВМ. это имя не должно иметь ничего общего с реальным именем хоста того сервера, на котором вы собираетесь её строить; это всего лишь имя описания которое будет отображаться внутри Диспетчера Hyper-V. Какое бы имя вы не присвоили здесь данной ВМ, оно будет отображаться в той папке, которая создаётся для размещения всех файлов виртуальных машин на жёстком диске нашего сервера хоста Hyper-V.
-
Всё ещё находясь на странице именования, не забудьте также выбрать местоположение, внутри которого Hyper-V следует хранить такую новую виртуальную машину. Каждая ВМ состоит из некоторого числа файлов типа метаданных, а также основного файла виртуального жёсткого диска (virtual hard disk), причём все они должны где-то храниться. Я считаю хорошей практикой определять здесь нечто отличное от установки по умолчанию. Если вы позволите Hyper-V зарывать эти файлы внутри
C:\ProgramData
, это прелестно., однако может создать проблемы с их отслеживанием в дальнейшем. Обычно у меня имеется выделенный диск для расположения на нём моих ВМ и я просто создаю в нём папку с именемVNs
. Например, на следующем снимке экрана я присваиваю своей новой виртуальной машине имяDC3
и собираюсь сохранять её файлы внутриC:\VMs
. Мастер затем создаст папку внутри этого месторасположения, что даст мне в конечном итоге местом назначения для данной виртуальной машиныC:\VMs\DC3
.
Совет Технически моя новая виртуальная машина может обслуживать любые цели внутри моей сетевой среды, однако как вы можете сказать мне по её имени, эти ребята собираются превратить её в контроллер домена когда она будет поднята и заработает. Важно отметить, что когда вы применяете виртуальные машины в качестве контроллера домена, существует одна особая конфигурация, которую вы скорее всего пожелаете поместить на место. После построения такой ВМ проследуйте в её страницу Settings и отключите Integration Services | Time synchronization. Если вы оставите включённой синхронизацию времени, такой котроллер домена продолжит получать своё время от хоста Hyper-V, вместо того чтобы выступать самому в роли поставщика времени, а это может вызывать проблемы в случае рассинхронизации времени. При применении виртуального контроллера домена он зачастую лучше работает с запрещённой синхронизацией времени и передаёт ответственность за хранение времени кому- либо ещё.
-
Кликните Next и теперь нам будут предоставлены вариант создания нашей виртуальной машины в качестве Generation 1 ил Generation 2 (1 или 2 поколения). Обычно, когда вы строите ВМ на сервере Hyper-V, такие ВМ также будут исполнять некую копию Microsoft Windows Server. Так как пара самых последних итераций операционной системы Windows Server поддерживала только 64- битные установки, скорее всего вы пожелаете выбрать для данных серверов ВМ Generation 2. Это предоставит вам самую последнюю функциональность вашим ВМ, в том числе репликацию этих ВМ на вторичный сервер Hyper-V. Однако в случае, если вам необходимо реализовать виртуальную машину, которая исполняет 32- битную операционную систему, вам всё ещё предоставляется возможность выбрать Generation 1 и сделать это возможным.
-
Далее нам необходимо выделить объём оперативной памяти для данной ВМ. Совершенно обычной практикой для администраторов является задание определённого объёма, которое соответствует реальному объёму физической оперативной памяти, например, 1024 МБ, 2048 МБ, 4096 МБ и т.п.. Однако нет реальной причины делать это. Вы можете ввести здесь лубое значение, которое пожелаете. Обратите внимание также на флаговую кнопку приведённую на данном экране. Если вы пометите Use Dynamic Memory for this virtual machine (Применять для данной виртуальной машины динамическую память), такая ВМ будет потреблять только столько, сколько ей в действительности требуется для исполнения. В качестве примера, мой сервер
DC1
, который выполняется здесь прямо сейчас потребляет 1583 МБ ОЗУ. Хотя это неплохо выглядит в теории, всегда иметь меньшие объёмы используемыми чем выделено, когда ВМ требуется расширить динамическую память, это потребляет определённое количество циклов ЦПУ для осуществления таких действий. Это означает, что если вы настроите все свои ВМ имеющими динамическую память, вы можете слегка уменьшить свои требования к ОЗУ, однако вы будете с более напряжённо работающим сервером хоста, который будет поддерживать все подвижки в требованиях к памяти. -
Вперёд и далее. Теперь нам представляется экран, который позволяет нам Configure Networking. Этот экран представляет собой просто ниспадающее меню, в котором вы можете выбрать выбрать подключение виртуального NIC своей новой ВМ в один из имеющихся виртуальных коммутаторов из тех, что мы создали ранее. Если вы откроете этот перечень, вы должны обнаружить все их доступными для выбора отсюда. Я намереваюсь подключить
DC3
к своей Corp LAN.
-
Теперь мы обнаружим себя на одном из самых важных экранов: определении своего виртуального жёсткого диска. Как вы можете видеть, место расположения такого жёсткого диска по умолчанию во вложенной папке
C:\VMs\DC3
, и в большинстве случаев это является надлежащим местом, так как оно делает возможным хранить все файлыVMs
вместе. Наиболее важным моментом данного экрана предполагается то, что вы запрашиваете мастер создать новый виртуальный жёсткий диск для себя, причём определяя ему некий размер. Установкой по умолчаню является 127 ГБ, что не является очень большим в сопоставлении со стандартами размеров современных физических дисков. Достаточно распространённым заблуждением новых администраторов Hyper-V является предполагать, что чем больше вы определите это значение, тем большего размера должен быть соответствующий файл VHDX; следовательно, если вы используете только 50 ГБ на некотором диске с размером 300 ГБ, то вы теряете впустую 250 ГБ своего физического дискового пространства. Но это не так!
Совет По окончанию создания данной ВМ, если вы взглянете на реальный созданный вами файл VHDX вы заметите, что хотя вы и определили 250 ГБ, реальный размер этого файла составляет только 4 МБ! Конечно, он будет расти по мере того, как мы установим некую операционную систему на свой новый сервер, однако важно знать, что этот диск не потребляет автоматически 250 ГБ сразу после своего создания. Отметим, что существует возможность создать виртуальный диск фиксированного размера, который употребил бы весь объём пространства прямо сразу, однако применяемые мастером опции по умолчанию не заставляют делать этого.
-
После определения размера вашего жёсткого диска вам необходимо сделать выбор как вы планируете заливать на него некую операционную систему. Для своих целей я буду устанавливать на данную новую ВМ Windows Server 2016 и, таким образом, я могу указать своей новой ВМ на файл установки ISO, который я разместил на жёстком диске своего сервера Hyper-V. На уровне данной ВМ это означает, что в ней строится некий виртуальный DVD, а затем к нему подключается данный ISO так, как если бы мы вставили реальный загрузочный DVD. Это гарантирует, что когда мы загрузим такую ВМ в первый раз, загрузка продолжится процессом установки Windows Server 2016.
-
После нажатия Next с последующим Finish, ваша совершенно новая виртуальная машина
DC3
создана и готова к запуску. Изнутри Диспетчера Hyper-V кликните правой кнопкой поDC3
и выберите Connect…. Это откроет окно, которое отобразит вам консольDC3
в точности так, будто вы располагаетесь прямо перед физическим монитором, подключённым к физическому серверу. -
В расположенной вверху панели инструментов кликните по кнопке Start и наблюдайте за тем как ваша новая виртуальная машина начинает оживать!
-
Также существует возможность раскрутить некую новую виртуальную машину воспользовавшись PowerShell! Взгляните на следующую команду в качестве примера. Как вы можете обнаружить, все описанные в нашей команде параметры отражают те опции, которые мы только что прошли в своём мастере.
-
Прежде чем вы выполните эту команду, переместитесь на свой диск, где хранятся ваши ВМ. В моём случае это
C:\VMs
.New-VM -Name "DC4" -NewVHDPath .\DC4.vhdx -NewVHDSizeBytes 250gb -MemoryStartupBytes 1024mb
-
После того, как данная команда завершится, ваша новая ВМ готовы к исполнению! Как вы можете заметить, мы не определили к какому виртуальному коммутатору подключаться, или какой ISO подключать к её виртуальному DVD чтобы осуществить загрузку с носителя. Эти элементы легко выполнить изнутри окна Settings внутри данной ВМ, что будет обсуждаться далее в нашем следующем рецепте.
Построение виртуальной машины является одной из основных задач которую вам необходимо регулярно выполнять на своих серверах Hyper-V. Существует ряд опций для выбора по которым вы перемещаетесь в процессе настройки своих новых ВМ, поэтому мы хотим взглянуть на них и объяснить некоторые из имеющихся различных параметров. Наличие возможности создавать ВМ изнутри PowerShell может быть невероятно мощным инструментом, в особенности если вам необходимо создать множество ВМ за раз. Поразмыслите о возможностях автоматизации этого с тем, чтобы вы просто запускали некий сценарий и получали за секунды десятки новых серверов исполняющимися!
Раз у вас имеются поднятыми и работающими некоторые виртуальные машины, становится важной настройки, которую вы выполняете для этих серверов изнутри операционной системы, исполняющейся внутри такой ВМ. В случае работающего Windows Server вы обычно взаимодействуете с такой операционной системой либо через функции соединения Hyper-V, например такие которые мы уже рассматривали или, возможно, включаете RDP на таком новом сервере с тем,чтобы применять клиента соединения с удалённым рабочим местом с рабочего стола своего компьютера для регистрации на таком новом сервере. Однако, всякий раз когда вы исполняете ВМ или физические серверы, присутствуют некоторые экземпляры, в которые вам приходится вносить изменения, или выполнять настройку этих серверов, которые не могут быть осуществлены изнутри такой операционной системы: например, если вам необходимо заменить жёсткий диск, или добавить больше оперативной памяти, или же добавить некий NIC и подключить его в новую сетевую среду. Это всё реальные случаи из жизни как для физических серверов, так и для виртуальных серверов. Единственная разница заключается в том, что вам не нужны физические элементы оборудования для выполнения работ при использовании ВМ. Итак, как нам приводить в исполнение все такие изменения? Существуют экраны настроек Hyper-V, которые вступают в игру.
Мы выполняем работу внутри Консоли управления Hyper-V моего сервера хоста Hyper-V, в котором у меня имеются полнофункциональные поднятые и работающие виртуальные машины.
Чтобы открыть основные настройки для одной из наших виртуальных машин выполните следующие шаги (мы также обсудим некоторые дополнительные важные опции перечисленные внутри этого интерфейса):
-
Находясь внутри Диспетчера Hyper-V кликните правой кнопкой на некую ВМ и взгляните на доступные нам в этом меню опции. Мы проследуем в меню Settings… через мгновение, однако вначале отметим, что клик правой кнопкой очень быстрый и простой способ для выполнения таких вещей как останов или запуск ВМ. Вы даже можете применять клавиши Ctrl или Shift для выбора множества ВМ в одно и то же время, а затем кликнуть правой кнопкой и запустить или погасить целую пачку одним махом!
-
Кликните по Settings… и давайте вернёмся к этому экрану чуть позже чтобы рассмотреть некоторые из этих параметров.
-
Для начала мы запустим экран Add Hardware. Именно здесь мы можем добавлять компоненты, подключаемые к вашей ВМ. Наиболее распространённый элемент, который я наблюдаю выбираемым здесь администраторами это Network Adapter. Существует множество причин зачем виртуальным машинам может понадобится более одного NIC, и именно этот экран в точности то место, где это необходимо осуществлять. Вы отметите, что некоторые из этих опций затенены; это происходит по той причине, что ряд изменений, которые вы могли бы пожелать выполнить с некоторой ВМ требуют чтобы данная машина была погашена и остановлена прежде чем осуществить такое изменение. На самом деле, для ВМ 1 поколения (Generation 1) вы должны гасить их прежде чем добавлять новые сетевые карты. К счастью, я создал
DC3
как виртуальную машину 2 поколения, поэтому мы можем добавлять новые NIC к этой ВМ даже при её исполнении! Я кликну по кнопке Addпрямо сейчас чтобы проверить это и вы видите некий второй Network Adapter отображённый в данном списке.
-
Это переносит нас к другой полезной и часто применяемой части нашего интерфейса настроек, экранам Network Adapter. Здесь отдельно перечисляется каждый виртуальный NIC, присоединённый к вашей ВМ, и кликнув по одному из них вы получаете возможность выбрать к какому из Virtual switch этот NIC подключается при помощи ниспадающего меню рядом с верхней частью данного экрана. Я подключаю один из своих NIC к Corp LAN, а свой другой NIC к Internet.
-
Чуть ниже в списке вы можете обнаружить опции своего дискового контроллера. Эти установки будут отличаться в зависимости от того будете ил вы исполнять ВМ 1 или 2 поколения. ВМ Gen 1 имеют перечисленными в настройках контроллеры IDE, в то время как ВМ Gen 2 имеют контроллеры SCSI. В любом случае это то место, в котором вы можете подключить дополнительные жёсткие диски к некоей ВМ, а также это то место, которое посещаете чтобы подключать какой- либо ISO файл к своему виртуальному устройству DVD, что является очень распространённой задачей при построении новых серверов. Со временем вы также обнаружите, что ВМ Gen 2 намного проще в работе. Мы можем добавлять новые жёсткие диски в систему на-лету, в то время как она продолжает оставаться в рабочем состоянии. В случае ВМ Gen 1, у вас нет иного способа кроме как погасить систему для подключения нового устройства.
-
Как вы можете ожидать, вы также имеете возможность шлёпнуть дополнительный Processors в некую ВМ. Выполнение таких настроек требует останова данной ВМ, вне зависимости от того выполняется она как Gen 1, или Gen 2.
-
Здесь также имеются и прочие опции, которые достаточно однозначно описывают себя сами, однако самое последнее место которое я хочу указать это категория Memory. Хотя это и не является само по себе чем- то особенным или причудливым (это всего лишь пункт, в котором вы определяете объём имеющейся в данной системе оперативной памяти), мы обсуждаем его здесь, так как Windows Server 2016 привнёс некую дополнительную функциональность в эти настройки. Исторически мы всегда должны были гасить ВМ чтобы изменять объём оперативной памяти, который она использует. Теперь это не так! Мы теперь можем изменять эти настройки и применять их прямо на работающей ВМ. Как вы можете видеть на следующем снимке экрана, я всего лишь перемещаю свой сервер
DC3
с 1 ГБ на 2 ГБ оперативной памяти, кликаю по кнопке Apply и изменения немедленно отображаются внутри свойств SystemDC3
.
-
Самый последний элемент, который я хочу упомянуть внутри экрана Settings это ниспадающее меню в самом верху. Когда вы кликаете правой кнопкой по некоторой ВМ и следуете в Settings…, вы очевидно просматриваете настройки той саомой виртуальной машины, по которой вы кликнули. Очень часто я наблюдаю людей, которые выполняют изменения на множестве ВМ за один раз, однако после каждого изменения они кликают OK, что закрывает окно Settings, а затем кликают правой кнопкой по следующей ВМ и возвращаются назад в то де самое окно. Вместо этого, если вы просто кликните по ниспадающему меню рядом с верхним краем, вы можете перемещаться между страницами Settings для всех ВМ исполняющихся на вашем сервере Hyper-V. Если вам нужно выполнить регулировку множества серверов, это определённо может сохранить ваше время и клики мышью.
раз вы начали выполнять работу по администрированию своих серверов Hyper-V, экран настроек для ваших виртуальных машин скорее всего самое посещаемое место для вашей повседневной работы. Регулировка оборудования и подключение к NIC являются задачами, которые вы должны выполнять быстро и легко, поэтому важно чтобы вы были знакомы с навигацией по этой части Диспетчера Hyper-V. Если вы новичок в мире Hyper-V, я надеюсь, что данный рецепт помог вам сделать эту часть всего интерфейса более удобным для вас чтобы перемещаться вперёд.
Когда мы выходим за рамки дискового пространства физического жёсткого диска, имеющиеся у нас варианты ограничены. Мы можем заменить это устройство чем- то большим, однако затем нам необходимо беспокоиться об успешном перемещении всех своих данных. Если мы работаем с некоторой разновидностью RAID или Пространств хранения (Storage Spaces), тогда возможно мы можем добавить новое устройство в такой массив дисков, однако это возможно только если мы правильно настроили инфраструктуру для поддержки этого ранее. К счастью, когда мы работаем с виртуальными машинами, который, в свою очередь, работают с виртуальными жёсткими дисками мы добавляем немного больше текучести к возможностям управления своими дисками. В конце концов, такие виртуальные жёсткие диски всего навсего файлы, не так ли? Поэтому имеет смысл, что ими слегка проще манипулировать нежели механическими дисками с физическими ограничениями. В данном рецепте мы собираемся изучить доступные нам опции внутри Мастера изменений Виртуальных жёстких дисков (Edit Virtual Hard Disk Wizard). Этот мастер позволит нам выбрать некий виртуальный жёсткий диск, а затем выполнить одну из трёх доступных вещей с ним. Мы можем уплотнить диск, расширить диск, или мы можем преобразовать диск к другому типу.
Наша работа будет осуществляться изнутри Диспетчера Hyper-V на Сервере Hyper-V работающем в нашей сетевой среде. Вам даже не требуются никакие виртуальные машины внутри Диспетчера Hyper-V, так как функции управления таким диском могут применяться к любому файлу VHD или VHDX - вне зависимости от того назначены или нет они какой- либо ВМ.
Вот шаги, необходимые для изменения ваших виртуальных жёстких дисков:
-
Внутри Hyper-V Manager (Диспетчера Hyper-V) взгляните на правую сторону своего экрана. Внутри панели Actions кликните по Edit Disk….
-
Кликните Next и затем переместитесь в местоположение своего файла VHD или VHDX, с которым вы желаете разобраться.
Совет Как вы можете заметить в предупреждении на данном экране, определённые типы виртуальных дисков могут отрицательно воздействовать на изменение. Проверьте что вы не пытаетесь изменять в одном из этих трёх случаев.
-
Далее нам нужно выбрать Action которое (Действие) мы собираемся осуществить с данным виртуальным диском.
-
Compact (Уплотнение) достаточно понятно из своего названия; оно пересмотрит свободное пространство внутри такого диска и уплотнит его настолько, насколько это возможно. Для выполнения этого нет никаких дополнительных экранов; вы просто кликаете Finish.
-
Expand (Расширение) также достаточно очевидно. Введите новый максимальный размер для своего виртуального жёсткого диска и данный файл будет увеличиваться для соответствия большему пороговому значению. Это наиболее частая причина для посещения Edit Virtual Hard Disk Wizard.
-
Convert (Преобразование) является тем параметром, который мы выбираем в данном рецепте, так как он даёт нам возможность обсудить различные типы виртуальных дисков. После выбора Convert и нажатия Next, вы получите вопрос желаете ли вы сделать это с файлом VHD или VHDX. Единственная причина, по которой вы бы выбрали VHD состоит в том, что вы намереваетесь реализовать некую операционную систему на своей виртуальной машине, которая не поддерживает работу на диске VHDX, например, Windows Server 2008 R2 или более ранних версий. В противном случае вы всегда здесь выбираете VHDX.
-
Теперь мы выбираем к какому типу виртуального диска выполнять преобразование. Когда вы позволяете мастеру создания ваших виртуальных машин настраивать для себя новый диск, он всегда выбирает Dynamically expanding (Динамическое расширение). Именно это обычно то, что нужно администраторам, та как файл VHDX стартует с очень небольшого размера, а затем растёт по мере потребностей. Это экономит используемое дисковое пространство до минимума. Однако, как и в случае с динамически расширяющейся оперативной памятью, для регулирования размера некоторого жёсткого диска на-лету требуются некоторый ресурсы. Поэтому, если вашей целью для некоторой ВМ является максимальная эффективность, в ваших интересах будет установить такой файл VHDX в значение Fixed size (Фиксированный размер). Выполнение этого вызовет потребление таким файлом VHDX всего необходимого объёма дискового пространства при создании или преобразовании такого диска, что скажется на общем объёме доступного вам физического пространства, однако это будет самым быстрым и полезным для рабочих нагрузок, которым требуется высокая производительность дисков.
-
Файл VHDX, который я в настоящий момент изменяю был настроен моим мастером, поэтому он в настоящий момент Dynamically expanding. Я собираюсь изменить его на Fixed size и следующий экран сообщает ему где сохранять мой новый файл VHDX. Это необходимо, так как всякий раз когда вы осуществляете преобразование виртуального диска из одного типа в другой, Hyper-V на самом деле собирается создавать совершенно новый файл VHDX, а затем копировать весь диск целиком в новое место.
Изменение ваших виртуальных дисков требуется не очень часто, если вы аккуратно планируете размеры дисков и их типы в процессе создания своих ВМ. Однако вам может понадобиться прийти в среду Hyper-V, которая была установлена до того как вы начали сотрудничать с некоторой компанией, а теперь имеете задачу очистки и более эффективной работы такого сервера Hyper-V. Регулировка размеров диска и их типов может быть частью общей цели по улучшению жизнедеятельности ваших серверов Hyper-V.
Резервное копирование физических серверов и их восстановление на предыдущие положения во времени всегда было слегка мудрёным в мире Windows Server. Когда с сервером что- то не так, в большинстве случаев более предпочтительным является исправление такой проблемы, вместо того чтобы просто откатить к предыдущей версии. Если вы на самом деле собираетесь выбрать это решение по откату операционной системы физического сервера, вы говорите о создании времени простоя. Это происходит по той причине, что вы восстанавливаете файл Резервной копии Windows или, если вы применяете некий вид утилиты образа, которая имеет полную картину вашего жёсткого диска в процессе такого резервного копирования и существует возможность подкладки такого целого образа назад в случае восстановления, вы должны остановить исполнение Windows чтобы заменить его файлы на таком диске. Поэтому вне зависимости от того какую технологию вы применяли для резервного копирования, вы должны выключить сервер по крайней мере временно пока осуществляется такое восстановление.
Hyper-V изменил всё. При работе с вашими вм, у нас имеется возможность брать и восстанавливать Контрольные точки (Checkpoint) как только у нас появляется такая потребность. Такая возможность также называлась Моментальными снимками (Snapshot) в предыдущих версиях Hyper-V; термин Контрольной точки (Checkpoint) является новым для Windows Server 2016. Также новым является выбор её создания в двух различных вариантах Контрольных точек - Стандартном (Standard) или Промышленном (Production). В данном рецепте мы пройдём через создание и восстановление обоих типов Контрольных точек чтобы рассмотреть преимущества, содержащиеся в каждом из типов.
Вся ваша работа по резервному копированию и восстановлению будет осуществляться внутри Диспетчера Hyper-V в вашем Windows Server 2016.
У нас имеется открытый Диспетчер Hyper-V, а также есть ряд различных работающих здесь ВМ. Давайте вместе исследуем возможности Контрольных точек:
-
Определите ВМ в которой вам нужны Контрольные точки. Я собираюсь воспользоваться своим сервером
DC3
. найдите эту машину в списке, кликните по ней правой кнопкой и выберите Checkpoint.
-
Как вы заметите, мы получим сообщение о том факте, что для нас была создана контрольная точка Production (Промышленная). Это важно, чтобы вы понимали, что Промышленный тип контрольной точки установлен в качестве режима по умолчанию. Вы также отметите, что раздел Контрольной точки (Checkpoint) Диспетчера Hyper-V должен теперь зажечься в качестве входа для сервера
DC3
. Работающая в настоящий момент виртуальная машина перечисляется как Now, и вы можете применённые к ней дату и временной штамп над ней, которые являются только что созданной Контрольной точкой.
-
Представляющее себя сообщение говорит, что технология резервного копирования внутри данной гостевой операционной системы было применено для создания такой контрольной точки. Что это означает? И ещё более важно, если мы желаем изменить назад на Стандартные Контрольные точки, где мы должны это осуществлять? На оба этих вопроса можно ответить открыв Settings вашей виртуальной машины. Кликните правой кнопкой по
DC3
, и выберите Settings…. Когда окажетесь внутри, выберите заголовок, который сообщает Checkpoints. -
именно в этом экране вы можете выбрать будете ли вы создавать Production checkpoints, либо Standard checkpoints. Для каждого из видов также имеется хорошее описание. В предыдущих версиях Hyper-V мы могли делать только Стандартные контрольные точки- которые назывались Моментальными снимками (snapshot); у нас не было других вариантов. Стандартные контрольные точки по существу всего лишь создают диски приращений для нашего файла VHDX. Когда вы восстанавливаете стандартную контрольную точку, она замещает всё в обратном порядке своей работы, включая содержимое уровня приложения. Промышленные контрольные точки, с другой стороны, применяют программное обеспечение резервного копирования внутри своей гостевой (ВМ) операционной системы. Это больше похоже на регистрацию в данной ВМ, открытии Резервной копии Windows и создании некоторого файла резервной копии. Помимо того, что вы обязаны сделать это за один клик, это занимает для осуществления всего несколько секунд. Мы обсудим все за и против каждого типа контрольной точки в разделе Как это работает... в конце данного рецепта.
-
Пройдите далее и измените Checkpoint Type на Standard checkpoints. Затем кликните правой кнопкой по своей ВМ и снова выберите Checkpoint. Это откроет нам вторую контрольную точку, причём она будет иметь тип Стандартной.
-
Как вы можете видеть, на самом деле не существует ничего существенно отличного между двумя различными взятыми нами контрольными точками помимо временного штампа. Помимо имеющихся собственных знаний, мы теперь осведомлены о том, что в 3:27a.m. контрольная точка была Промышленной контрольной точкой, в то время как контрольная точка 4:00a.m. имела разновидность Стандартной. Если вы полагаете, что вы будете брать контрольные точки обоих видов, может оказаться полезным переименовывать эти контрольные точки, просто кликая правой кнопкой по ним, чтобы отображать их тип контрольной точки где- то в наименовании самой контрольной точки.
-
Теперь мы хотим попытаться восстановить эти контрольные точки, перенося свой сервер
DC3
обратно к этим определённым моментам во времени. Если вы хотите проверить сам факт того, что такой откат на самом деле работает, вы можете внести некоторые изменения в свою операционную систему в данный момент. Может быть, создать некие файлы на своём жёстком диске чтобы вы могли убедиться после выполнения отката, что эти файлы были удалены. -
Чтобы осуществить откат некоторой ВМ к предыдущей контрольной точке просто кликните правой кнопкой по той контрольной точке к которой вы хотите осуществить восстановление и выберите Apply….
-
DC3
немедленно вернётся обратно к стандартной контрольно точке, которая была создана несколько минут назад. Она имеет все мои приложения и всё ещё выполняется на данном экране, в точности так же, как на тот момент, когда я создал образ данной контрольной точки.Совет не забудьте внимательно прочитать раздел Как это работает... данной части. В то время как Стандартная Контрольная точка может казаться наилучшим подходом благодаря своим моментальным восстановлениям, она поступает с некоторыми предостережениями, о которых вам следует знать!
-
Теперь, когда мы успешно восстановили стандартную контрольную точку, давайте попробуем восстановить первую созданную нами контрольную точку, которая имела новы тип Промышленной. Наша процедура в точности та же самая: кликаем правой кнопкой по файлу контрольной точки и выбираем Apply….
-
На данный момент, однако, мы можем отметить, что наша виртуальная машина
DC3
вернулась к своему собственному состоянию OFF когда мы выбрали эту контрольную точку для восстановления.
-
Кликните по кнопке Start чтобы вернуть
DC3
назад в рабочее состояние и загрузить её. Однако это новая загрузка, а не наше немедленное восстановление, осведомлённое о приложениях, которое получилось при первом откате контрольной точки. Данная ВМ теперь была восстановлена обратно к той Промышленной контрольной точке, которую мы создали. Как вы уже видели, основная разница в нашей процедуре в здесь состояла в том, что мы вернулись обратно к своему серверу следуя процессом восстановления.
Имеющаяся возможность Windows Server 2016 Hyper-V создавать Контрольные точки является очень полезной. Предыдущие версии Windows Server называли эту функцию Моментальными снимками (Snapshots), и в основном работали в точности так же как большая часть Контрольных точек. Основная разница состоит в том, что теперь у нас имеются два различных типа образов, которые мы можем создавать когда мы выбираем создание Контрольной точки для наших виртуальных машин.
Standard checkpoints в точности повторяют предыдущее поколение моментальных снимков - они делают возможным немедленный откат к некоторому файлу образа, сохраняя ВМ в рабочем состоянии и даже запоминая информацию, специфичную для приложений по завершению такого отката. Существует одна главная проблема которая присутствует в моментальных снимках и при этом продолжает оставаться некоторой проблемой для стандартных контрольных точек. Именно эта проблема присутствует при определённых видах отказов синхронизации с прочими серверами когда вы применяете стандартные контрольные точки. Как вы видите, когда вы создаёте контрольные точки таких серверов, как контроллеры домена или сервера баз данных, создаваемый файл является простым снимком для уровня Диспетчера Hyper-V - он в высшей степени не интересуется тем, что происходит внутри такой виртуальной машины, либо своей собственной операционной системы на данный момент времени. Это означает, что когда вы восстанавливаете некоторую стандартную контрольную точку, она всего лишь подкладывает такие данные обратно в точности таким образом, как они там располагались до того, причём при этом не принимая в рассмотрение сам сервер или какие функции он выполняет. Это часто при водит в результате к тому, что контроллеры домена отказывают в синхронизации с прочими DC в вашей сетевой среде, а данные перекашиваются после своего восстановления. Это вызывает большие проблемы для компаний.
Production checkpoints являются новым ребёнком в этом объединении, и по этой причине является вариантом по умолчанию. Даже хотя они медленнее для восстановления ваши ВМ будут запирать себя вслед за восстановлением из Промышленной контрольной точки, что имеет результатом время простоя для данного сервера, Промышленные контрольные точки применяют инструменты резервного копирования и восстановления аналогичные VSS внутри самой гостевой операционной системы. Это означает, что такие файлы контрольных точек будут более понятными для самой вашей ВМ и выполнит восстановление более равномерно в промышленной среде.