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

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

О, это не хорошо. Это означает одну из двух вещей - либо мой ЦПУ в действительности не поддерживает виртуализацию, либо я просто имею некоторые настройки выключенные в моём BIOS {Прим. пер.: Firmware} на моём сервере, что не даёт возможности работы. Существует три момента, которые вы должны проверить в своём сервере, чтобы убедиться что он готов к работе с Hyper-V. Во- первых вам необходимо работать с процессором на основе x64. Этот элемент выступает как данность, ибо Windows Server 2016 в любом случае поставляется только для 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 2016, однако в процессе установки этой роли вам будет задано несколько вопросов и важно понимать о чём они спрашивают, чтобы вы могли быть уверенными что ваш новый сервер Hyper-V построен самым современным и работает эффективно. Прежде всего, вам конечно необходимо иметь уже установленным Windows Server 2016 и воспользоваться функцией 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 или VHDX - а вторая состоит в папке, содержащей файлы настроек для этой ВМ. В следующем снимке экрана вы можете увидеть местоположение для хранения этих элементов по умолчанию является чем-то что вы ожидали бы увидеть за пределами приложений клиента которые вы устанавливаете на ноутбуки, однако вы не ожидали бы что- то столь тяжёлое как то, что Hyper-V хранит эти файлы ядра в My 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:

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

Теперь определим сколько оперативной памяти вы желаете выделить этой определённой ВМ. Имейте в виду, что это установка, которую вы можете изменить в дальнейшем для этого сервера и поэтому сосредотачиваться на планировании данного пункта. Объём оперативной памяти, который вы выделяете данной виртуальной машине будет зависеть от того, сколько оперативной памяти у вас доступно в системе хоста 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. Он достаточно прост. Не так ли? Просто введите объём памяти, который вы хотите сделать доступным для этой ВМ. Причина, по которой я останавливаюсь здесь состоит в основном улучшении выполненном в этой функциональности. Вы теперь можете установить нужный объём памяти, который имеет ВМ пока она работает! В предыдущих версиях Hyper-V вам было необходимо остановить эту ВМ чтобы внести изменения в выделения памяти, однако несмотря на то, что мой сервер WEB3 в настоящее время работает и обслуживает пользователей, я могу внезапно появиться здесь и увеличить оперативную память по своему желанию. Допустим, мои 2ГБ не соответствуют загрузке моей задачи и я хочу увеличить их до 4ГБ. Я оставляю этот сервер работающим, открываю настройки Hyper-V Manager для данной ВМ и настраиваю 4096МБ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аналогично тому способу, каким удалённо выполняется большая часть задач для Ядра сервера (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 2016. Многие из обсуждавшихся тем достаточно всеобъемлющи чтобы заполнить собой целые книги, и я надеюсь что идеи предоставленные в этом томе достаточны чтобы пригласить вас погрузиться глубже в эти технологии с которыми вы планируете работать. Технологии Microsoft царствуют как король в большинстве центров обработки данных повсеместно. Новые о усовершенствованные свойства внутри Windows Server 2016 гарантируют что эта тенденция продолжится далеко в будущее.