Настройка для игр windows server 2012

В данной статье пошагово со скриншотами рассмотрим самые базовые настройки Windows Server 2012 R2 (любых версий: Standard, Datacenter, Essentials). В них входит настройка AD, DNS, DHCP, а так же лицензирование терминального сервера (настройка сервера RDP). Эти настройки как правило подходят для большинства задач и являются стандартными для использования их в Windows Server.

С процессом установки и самой начальной настройки как активация сервера, и получение обновлений Windows Server 2012 R2 можете ознакомиться в нашей прошлой статье.

1) Итак, начнем. Для начала нам нужно задать имя сервера, чтобы оно было в последующем корректно указано в различных настройках для подключений. Зайдем в меню «Свойство системы» => Изменить параметры => Далее в окне «Имя компьютера» нажимаем кнопку «Изменить» => После в строке ввода «Имя сервера» задаем имя в произвольном порядке. У нас оно будет просто Server.

Чтобы настройки применились перезагрузите Ваш компьютер.

2) Следующая, тоже очень важная процедура — это задать локальный статический IP адрес серверу. Для быстроты переходим в меню «Пуск», далее в поиске вводим ncpa.cpl.

На Вашем основном сетевом адаптере щелкаем правой кнопкой мыши => Свойства

Выделяем протокол IPv4 и нажимаем «Свойства».

И задаете серверу статический IP адрес в зависимости от Вашей сети. (далее в статье рассмотрим настройку DHCP, чтобы Ваш сервер сам мог раздавать свой диапазон IP адресов). Чтобы посмотреть текущий локальный IP адрес и шлюз — Вам нужно открыть командную строку, в поиске введите «Cmd» => Далее введите команду «ipconfig». Как DNS сервера в предпочтительных можем оставить IP адрес Вашего шлюза (роутера, маршутизатора), а как альтернативный адрес Google — 8.8.8.8

После применяете настройки и проверяете Ваше соединение с интернетом, если все работает, значит Ваши настройки корректные.

3) С настройками IP адресов пока закончено, перейдем к добавлению ролей и компонентов. Заходим в диспетчер серверов. Меню «Панель мониторинга» => Добавить роли и компоненты

Переходим в пункт «Тип установки» и выбираем «Установка ролей или компонентов».

Выбираете Ваш сервер в меню выбора серверов.

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

В компонентах оставляем все по стандарту. За исключением того, если у Вас сервер будет работать по Wi-FI, т.е в нем будет какой-либо Wi-Fi адаптер, то без компонента «Службы беспроводной локальной сети» — беспроводное соединение работать не будет. Отмечаете галкой его, если Вам требуется такой функционал.

Далее доходим до меню «Службы ролей» для удаленных рабочих столов. Отмечаем галкой то, что нужно для работы с RDP.

В службах «Удаленный доступ» по желанию можете выбрать работу с VPN и прокси-сервером, это как правило многим не нужно. На Ваш выбор.

Доходим до пункта «Подтверждение», отмечаем галкой автоматический перезапуск после установки и жмем «Установить». Ожидаем пока все установится.

4) Теперь переходим к настройкам тому, что мы только что устанавливали. В конкретном случае к настройкам DNS. Заходим снова в меню «Диспетчер серверов» => Нажимаем на флажок => И выбираем пункт «Повысить роль этого сервера до контроллера домена».

В конфигурации развертывания отмечаем пункт «Добавить новый лес» и придумываем имя корневого домена. В вашем случае это может быть абсолютно любое название, которое Вам понравится, мы назовем как пример «soft.com».

В параметрах контроллера придумываем Ваш пароль для Вашего домена и жмем «Далее».

Теперь можем дойти сразу до предварительной проверки всех настроек. Все будет корректно если у Вас будет в окне указано, что «Все проверки готовности к установке выполнены успешно …«. Нажимаем установить. После установки перезагружаем сервер.

После перезагрузки как будете вводить пароль администратора, Вы можете заметить, что Ваш сервер уже добавлен в домен.

Но это еще не все, нам нужно его до конца настроить. Снова переходим в «Диспетчер серверов» => меню «Свойства» => DNS

Мы перешли в «Диспетчер DNS». Разворачиваем дерево DNS => SERVER (Имя Вашего сервера) => Зоны обратного просмотра => Щелкаем правой кнопкой мыши и нажимаем на пункт «Создать новую зону».

Выбираем «Основная зона» и отмечаем галкой «Сохранять зону в Active Directory …«.

Следующим окном выбираем пункт «Для всех DNS-серверов, работающих на контроллерах домена в этом домене: «ваш домен»«.

Далее выбираем пункт с IPv4 соответственно.

В индефикаторе сети для данного DNS выбираем Ваш IP диапазон или имя зоны. Мы на примере выберем DNS по IP диапазону.

Разрешим динамические обновления, т.к это рекомендуемый параметр для настроек AD.

На этом все, нажимаем готово.

5) Теперь рассмотрим настройки DHCP (чтобы Ваш сервер мог раздавать свой диапазон IP адресов). Переходим в меню «Диспетчер серверов» и выбираем пункт «Завершение настройки DHCP».

В меню «Авторизация» для удобства выбираем пункт «Использовать учетные данные текущего пользователя«. И нажимаем «Фиксировать».

Теперь заходим в меню «Средства» => DHCP.

Разворачиваем дерево DHCP => «Имя вашего домена» => нажимаем на IPv4 правой кнопкой мыши => Создать область.

Задаем имя области, как пример «Basic», Вы можете задать любое название.

Теперь прописываем диапазон IP адресов, который будет раздавать Ваш сервер путем DHCP. Например 192.168.1.1/245. Диапазон задается по Вашему желанию.

В следующем окне можете исключить какой-либо диапазон, например определенные IP адреса. На примере мы его пропустим.

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

Можете добавить Ваш маршутизатор в эту область, либо пропустить этот шаг.

Укажите имя Вашего домена как родительский.

6) Теперь Вам можно уже настроить удаленные рабочие столы для пользователей. Для этого на Вашем сервере нужно лицензировать сервер удаленных рабочих столов. С инструкцией как происходит настройка RDP на сервере можете ознакомиться в нашей прошлой статье на следующей странице. Приобрести ключ активации для лицензирования Windows Server User/Device CAL можете в нашем каталоге. Быстрая доставка ключа в течении нескольких часов на Вашу электронную почту.

7) Теперь, после того как Вы успешно лицензировали сервер удаленных рабочих столов, можно добавить первого пользователя для подключения по RDP. Заходим в «Диспетчер серверов» => Средства => Пользователи и компьютеры Active Directory.

Разворачиваем дерево «Пользователи и компьютеры» => Правой кнопкой мыши на название Вашего домена или просто имя сервера => Создать => Подразделение.

Чтобы было понятно, что за подразделение можете задать ему имя «Пользователи», или «Клиенты».

Далее в новом разделе «Пользователя» (в зависимости от того, как Вы назвали Ваше подразделение). Нажимаете на него правой кнопкой мыши => Создать => Пользователь.

Теперь в карточке пользователя задаем параметры для пользователя, его имя, фамилию, имя для входа на латинице.

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

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

На этом все, мы закончили самую базовую настройку.

Обновлено 25.10.2016

Настройка windows server 2012 r2 осуществляется сразу после того как была произведена установка windows server 2012 r2. Под настройкой понимается, настройка сети, смена имени и отключение не нужных для сервера вещей, благодаря этим действиям, системный администратор сможет повысить удобство и стабильность работы данной операционной системы и улучшить ее производительность, если вы производите установку массово, то это все конечно же можно автоматизировать.

Настройка сети windows server 2012 r2

Первым делом любому серверу необходима, настройка сети. В настройку сети входит выбор и установка статического ip адреса. Для этого щелкаем правым кликом по значку сети и выбираем Центр управления сетями и общим доступом

Далее выбираем ваше сетевое подключение

Нажимаем кнопку свойства

настройка сети windows server всегда требует одного правила отключаем все то, что не используется. Так как у меня не используется протокол ipv6, то я снимаю с него галку, так как компьютеры в первую очередь пытаются по умолчанию общаться через него.

Теперь выбираем ipv4 и нажимаем свойства.

Так как наш ip адрес получен от DHCP сервера, то мы динамический ip адрес заменим на статический. Заранее вы для своей локальной сети должны были выбрать пул ip адресов, которые будут у вас. И для серверов, забронировать определенное количество ipшников. У меня это диапазон 10.10.2.0/24. И так как у меня данный сервер вскоре будет контроллером домена, то я ему назначу ip адрес 10.10.2.1 с маской 255.255.255.0 в качестве DNS сервера пропишу пока его же 10.10.2.1. Вот так производится настройка статического ip адреса.

Жмем везде дальше ок и закрываем все окна. С сетью мы закончили работы.

Задаем имя сервера

Имя сервера, один из важных параметров в вашей инфраструктуре, существует много вариантов наименования серверов и с точки удобства и с точки зрения безопасности сети, так как явно понятное имя позволяет хакеру ускорить процесс совершения задуманного и понимания, что и где в сети. Лично я придерживаюсь, что контроллеры домена можно назвать и dc, а вот сервера просто обезличенно назвать server01 и так далее.

Щелкаем правым кликом по пуску и выбираем Система

Переходим в дополнительные параметры системы

Переходим на вкладку имя сервера, на ней можно изменить имя сервера на любое какое вам нужно, до 16 символов.

Я задаю имя компьютера, такое: у меня домен будет inmoskow.org и от имени домена возьму первые две буквы im и добавлю dc01, в итоге получаю imdc01, у вас может быть свой принцип.

После чего вас уведомят, все настройки будут применены только после перезагрузки.

Вас попросят перезагрузиться, сделаем это позже

Быстродействие Windows Server 2012 r2

Для того, чтобы ускорить ваш сервер, нужно чтобы на нем работало только то что реально нужно, заходим на вкладку Дополнительно-Параметры

вкладка визуальные эффекты, и ставим переключатель на Обеспечить наилучшее быстродействие, это позволит ускорить сервер.

Включаем удаленный рабочий стол

Для того чтобы вы со своего рабочего места могли заходить по RDP, необходимо включить на вкладке Удаленный доступ птичку Разрешить удаленные подключения к этому компьютеру. В итоге будет создано правило в брандмауэре открывающее порт 3389.

Вот теперь перезагружаемся и заходим на ваш сервер по RDP. Проверим как применились настройки на нашем сервере. Для этого вводим две команды

Команда hostname покажет текущее имя сервера, а ipconfig отобразит настройки сети, в нашем случае это ip адрес и маску. Видим, что все отлично применилось.

Вот так вот просто делается настройка windows server 2012 r2, можно двигаться дальше и устанавливать контроллер домена на платформе 2012R2.

Материал сайта pyatilistnik.org

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

В Hyper-V в Windows Server 2012 заложены весьма широкие возможности масштабирования, виртуальные машины могут иметь до 64 виртуальных процессоров (vCPU) и до 1 Тбайт оперативной памяти. Благодаря новому формату VHDX теперь возможно создавать виртуальные жесткие диски (VHD) объемом до 64 Тбайт, что избавляет от необходимости задействовать транзитное хранилище. Таким образом, можно согласиться с тем, что практически любое приложение может быть виртуализовано с помощью Hyper-V.

Конечно, масштабируемость сама по себе не имеет большого значения без функций, способных в полной мере использовать ее возможности. И Windows Server 2012 обладает ими. Динамическая миграция хранилища позволяет перемещать хранилище виртуальной машины, не выключая ее. Динамическая миграция без разделения ресурсов позволяет перемещать виртуальные машины между хостами Windows Server 2012 без простоя, даже без кластеризации и общего хранилища. Эти возможности делают виртуальные машины мобильными в рамках центра обработки данных.

Такие новые возможности, как виртуализация операций ввода-вывода SR-IOV (single root I/O virtualization), протокол Server Message Block (SMB) версии 3.0, виртуальный адаптер Fibre Channel и виртуализация сети, делают Hyper-V очень эффективным гипервизором. Однако многие организации не рассматривали его ранее и не знают, с чего начать. В этой статье мы рассмотрим основы установки и настройки Windows Server 2012 Hyper-V.

Какое аппаратное обеспечение мне потребуется?

В простом случае, то есть при развертывании одного сервера, вам потребуется сервер с 64-разрядным процессором, поддерживающим аппаратную виртуализацию. У процессоров Intel эта технология называется Intel Virtualization Technology (VT), у процессоров AMD — AMD virtualization (AMD-V). Практически любой процессор из выпущенных за последние пять лет поддерживает эту технологию. Но если вы не уверены в своем аппаратном обеспечении, загрузите и запустите из командной строки с повышенными привилегиями утилиту Coreinfo (technet.microsoft.com/en-us/sysinternals/cc835722.aspx) с параметром –v. Утилита покажет, поддерживает ли процессор аппаратную виртуализацию и преобразование адресов второго уровня (Second Level Address Translation (SLAT); для процессоров Intel и AMD эта возможность также может называться Extended Page Tables. Результат запуска утилиты, показанный на экране 1, говорит о том, что аппаратная виртуализация Intel включена, а это все, что нужно, чтобы начать. Поддержка SLAT не является обязательной для работы Hyper-V, но улучшает производительность. Поэтому предпочтительно задействовать SLAT всегда, когда это возможно, а в тех средах, где используются технологии виртуальных рабочих столов, такие, как виртуализованные серверы служб удаленных рабочих столов Remote Desktop Services или инфраструктура виртуальных рабочих столов (VDI), применение SLAT является абсолютно необходимым.

Экран 1. Пример вывода утилиты Coreinfo

Windows Server 2012 не имеет ограничения на соотношение между физическими и логическими процессорами (в Windows Server 2008 R2 поддерживалось соотношение 8:1 для виртуальных машин с серверными операционными системами). Если вас удовлетворяет, как сервер справляется с нагрузкой, то Microsoft этого достаточно.

Объем необходимой памяти полностью зависит от того, сколько памяти вы планируете выделить виртуальным машинам. Обычно я выделяю 2 Гбайт на хост, а затем добавляю память, которая потребуется для виртуальных машин. Для крупномасштабных виртуальных сред серверы с объемом памяти в 96 или 192 Гбайт — дело обычное. Но для тестовой среды вам хватит ровно столько памяти, сколько необходимо для работы.

У каждой виртуальной машины есть один или более виртуальных дисков. В Windows Server 2012 используется новый формат VHDX, который не только поддерживает диски объемом 64 Тбайт (старый формат поддерживал диски объемом до 2 Tбайт), но и был оптимизирован так, что его производительность практически не уступает физическим жестким дискам. Это верно даже для динамических виртуальных жестких дисков, которые изначально занимают немного места и увеличиваются в объеме по мере записи данных. Также есть возможность создания VHD фиксированного размера. Этот вариант, как правило, используется в производственных средах, как из соображений производительности, так и для того, чтобы не израсходовать все свободное место на диске. А это вполне может произойти, если фактический объем занимаемого дискового пространства не отслеживается должным образом, поскольку динамические файлы VHDX увеличиваются в размере. Используйте старый формат VHD только в том случае, если вам нужна совместимость с предыдущими версиями серверов Hyper-V, такими как Windows Server 2008 R2.

Файлы VHDX могут храниться на локально подключенном хранилище (в тестовой среде, например, это могут быть встроенные диски), но в идеале стоит использовать внешнее хранилище, такое как SAN. Новая возможность в Windows Server 2012 — это хранение и запуск виртуальных машин из общей сетевой папки, с использованием протокола SMB 3.0. Применение внешнего хранилища упрощает создание резервных копий виртуальной среды. Внешнее хранилище позволяет задействовать больший объем дискового пространства по мере увеличения количества серверов. Использование центрального пула упрощает управление. Внешнее хранилище также пригодится, если вы собираетесь использовать отказоустойчивую кластеризацию для включения нескольких узлов кластера, позволив, тем самым, виртуальным машинам легко перемещаться между хостами и автоматически перезапускаться, если один хост выйдет из строя. Миграция типа Shared Nothing Live Migration позволяет виртуальным машинам также перемещаться без перерыва в работе за пределы кластера, как уже упоминалось выше. Кроме того, кластеры чрезвычайно полезны для проведения планового обслуживания, поскольку они позволяют переместить все виртуальные машины на другой узел (используя динамическую миграцию, что предотвращает момент недоступности виртуальной машины), пока на первоначальный узел устанавливаются обновления и он перезагружается, после чего машины перемещаются обратно и следующий узел обновляется и перезагружается. Любой узел в кластере может быть обновлен без простоя виртуальных машин. Используя этот процесс, в Windows Server 2012 можно обновить весь кластер одним щелчком мыши.

Что с сетевыми подключениями?

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

1. Вам необходимо управлять хостом Hyper-V. Соответственно, вам требуется подключение для выполнения административных задач.
2. Скорее всего, виртуальным машинам потребуется связь с внешним миром. Частный виртуальный коммутатор позволяет виртуальным машинам взаимодействовать между собой, а внутренний виртуальный коммутатор позволяет им взаимодействовать между собой и хостом Hyper-V. Но ни один из них не дает возможности взаимодействовать с внешним миром. Следовательно, вам понадобится сетевой адаптер для трафика виртуальных машин. В производственной среде вам, вероятнее всего, потребуется как минимум два адаптера для трафика виртуальных машин; вы сможете объединить их для создания отказоустойчивого подключения. Существует возможность использовать один и тот же адаптер как для управления, так и для виртуальных машин; в тестовой среде вы можете задействовать этот вариант. Но в идеале лучше разделять административный трафик и виртуальный сетевой коммутатор, который управляет трафиком виртуальных машин. Вы ведь не хотите потерять доступ к серверу, если что-то случится с виртуальным коммутатором.
3. Необходимо, чтобы узлы в кластере обменивались служебной информацией, такой, как различные сообщения IsAlive. Обычно для этого применяется отдельная сеть. Дополнительно к трафику подтверждения соединения кластера (heartbeat) кластерная сеть используется для трафика общего тома кластера cluster shared volume (CSV). Это позволяет всем узлам кластера одновременно задействовать одни LUN в NTFS. Обычно трафик CSV состоит только из изменений метаданных. Однако в некоторых ситуациях отдельные узлы используют эту сеть для передачи трафика, относящегося к хранилищу. Поэтому при использовании CSV кластеру потребуется отдельная сеть.
4. Вам потребуется выделенная сеть, чтобы гарантировать, что миграция виртуальных машин между узлами происходит за приемлемое время. Таким образом, вам нужно выделить сеть для динамической миграции.
5. Если вы используете iSCSI для подключения к хранилищу, то вам опять же потребуется выделенная сеть.

Это требование наличия пяти сетевых подключений не учитывает использование нескольких сетевых адаптеров для трафика виртуальных машин или объединения сетевых карт (для балансировки нагрузки и обеспечения высокой доступности). Кроме того, оно не учитывает использование нескольких сетевых подключений iSCSI или Microsoft Multipath I/O (MPIO) для обеспечения дополнительной отказоустойчивости.

В данном расчете предполагается, что вы используете подключения 1 Гбит/с. При использовании подключений 10 Гбит/с ситуация меняется. Не имеет смысла выделять отдельный интерфейс 10 Гбит/с для административного трафика или трафика CSV. В средах с 10 Гбит/с, вероятнее всего, будет два подключения; используйте объединение сетевых карт для каждого из них для обеспечения отказоустойчивости и должного качества обслуживания Quality of Service (QoS), чтобы гарантировать пропускную способность для каждого типа трафика. Подробные рекомендации Microsoft можно найти в статье «Hyper-V: Live Migration Network Configuration Guide» (technet.microsoft.com/en-us/library/ff428137(v=WS.10).aspx).

Можно применять тот же подход и в сетях 1 Гбит/с. Используйте объединение сетевых карт и QoS, чтобы гарантировать пропускную способность для трафика разных типов.

Какую операционную систему использовать?

После того, как вы определили подходящие процессор, память, диски и сеть, все, что вам нужно — это выбрать операционную систему. Но какую именно редакцию выбрать — Windows Server 2012 Standard, Windows Server 2012 Datacenter или бесплатную Microsoft Hyper-V Server 2012? С точки зрения Hyper-V разницы нет. Все три операционные системы имеют одинаковые ограничения, возможности кластеризации и функции. Решение зависит от того, какая операционная система будет использоваться на хосте Hyper-V.

Если это Windows Server, то планируете ли вы свободно перемещать виртуальные машины между хостами? В Hyper-V 2012 Server невозможно установить на виртуальную машину операционную систему Windows Server. И это имеет смысл – операционная система бесплатна и вполне подойдет, если вы не будете устанавливать на виртуальные машины операционную систему Windows Server. Если вы используете виртуальные рабочие столы (VDI) с виртуальными машинами Windows 8 или у вас виртуальные машины только на UNIX или Linux, то ориентируйтесь на Hyper-V 2012.

Если вам нужно применять Windows Servers на виртуальных машинах, то вам подойдет редакция Windows Server 2012 Standard, которая дает возможность запускать одновременно две виртуальные машины с операционной системой Windows Server. Если бы мне потребовалось запустить четыре виртуальные машины с операционной системой Windows Server, то я мог бы купить два экземпляра Windows Server 2012 Standard. Обратите внимание, что вы можете запускать на одном и том же сервере и другие виртуальные машины, не с серверными операционными системами. По количеству виртуальных машин ограничений нет, есть только ограничение на число виртуальных машин с операционной системой Windows Server, работающих на Hyper-V, VMware или любой другой платформе виртуализации.

Если предстоит запускать несколько экземпляров операционной системы Windows Server, то вам потребуется редакция Windows Server 2012 Datacenter, которая дает возможность запускать неограниченное количество виртуальных машин с серверными операционными системами. При расчете учтите стоимость версий Standard и Datacenter применительно к своей среде. Например, если вам нужно запускать менее шести виртуальных машин с Windows Server, то дешевле купить несколько копий Standard, чем Datacenter. А если вы используете кластеризацию и хотите перемещать виртуальные машины, то вам придется учесть следующий фактор: лицензии Windows Server привязаны к аппаратному обеспечению, и их можно перемещать между серверами только раз в 90 дней.

Давайте рассмотрим пример с региональным офисом, в котором развернуты два кластера виртуализации. Повторюсь, речь идет о лицензировании Windows, а не Hyper-V, поэтому все, о чем я говорю, не зависит от используемого гипервизора. На каждом узле Hyper-V обычно работает 4 виртуальные машины, поэтому мне нужны две копии Windows Server 2012 Standard для каждого узла. Поскольку узлы включены в кластер, я могу перемещать виртуальные машины между узлами. Например, для установки обновлений мне нужно переместить все виртуальные машины на узел B (в результате на нем одновременно будет работать восемь виртуальных машин), пока я буду устанавливать обновления и перезагружать сервер А. Затем мне понадобится переместить все восемь машин на узел А, пока я буду обновлять и перезагружать узел B. Но я могу это сделать, только подождав 90 дней с момента перемещения всех виртуальных машин на узел В. К тому же, если узел выйдет из строя, то я не смогу в течение 90 дней передвинуть обратно перемещенные виртуальные машины, когда узел будет восстановлен. Для того чтобы свободно перемещать виртуальные машины, мне необходимо достаточное количество свободных лицензий, чтобы обеспечить ими все виртуальные машины, которые только могут оказаться на данном узле, то есть восемь машин. Для этого мне понадобится четыре копии Standard для каждого сервера, что делает Datacenter в данном случае более разумным вариантом.

Многие компании часто неверно понимают это сравнение, которое имеет большое значение, когда речь идет о планировании количества необходимых лицензий. Как правило, когда виртуализация используется мало, вам будет достаточно Windows Server 2012 Standard. В то время как в полностью виртуализованных средах, вероятнее всего, понадобится Windows Server 2012 Datacenter.

Еще один важный вопрос — использовать ли режим Server Core или режим с графическим пользовательским интерфейсом. В общем случае использование Server Core предпочтительно, так как требует установки меньшего количества обновлений и, как следствие, перезагрузок. Но при этом в Windows Server 2012 пользовательский интерфейс в любой момент можно добавить или удалить, что требует только одной перезагрузки. Поэтому, особенно если вы еще не очень хорошо знакомы с Windows Server 2012, изначально установите сервер с пользовательским графическим интерфейсом. Сделайте все настройки, освойтесь, а затем удалите графическую оболочку и инструменты управления и используйте сервер в режиме Server Core, управляя им удаленно с компьютера с операционной системой Windows 8.

Установка Hyper-V

Итак, вы установили Windows Server 2012, применили последние обновления, подключили сервер к системе хранения, переименовали сетевые подключения, чтобы их было проще различать (и объединили их, если необходимо) и настроили IP-адреса. Следующий шаг — установка роли Hyper-V. Эту задачу можно решить из графического интерфейса с помощью диспетчера сервера или же используя Powershell:

Install-WindowsFeature Hyper-V -IncludeManagementTools –Restart

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

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

Ниже приведены основные шаги, которые необходимо выполнить для установки с помощью диспетчера сервера.

1. Зарегистрируйтесь на сервере, который будет хостом Hyper-V, под учетной записью с правами администратора и запустите диспетчер сервера. Или запустите диспетчер сервера на удаленной машине, используя учетную запись с правами администратора на сервере, который будет хостом Hyper-V.
2. Выберите «Добавить роли и функции» из меню «Управление».
3. Нажмите «Далее».
4. На странице «Выбор типа установки» выберите «Установка на основе ролей» и нажмите «Далее».
5. На странице «Выбор сервера» из списка серверов выберете сервер, на который необходимо установить Hyper-V, и нажмите «Далее».
6. В списке «Роли сервера» отметьте Hyper-V и подтвердите автоматическую установку инструментов управления.
7. На странице «Создать виртуальный коммутатор», показанной на экране 2, выберите сетевой адаптер, который будет использоваться для трафика виртуальных машин, и нажмите «Далее».
8. Оставьте режим «Включить динамическую миграцию» выключенным и нажмите «Далее». Динамическую миграцию легко включить позже.
9. Укажите место для хранения виртуальных машин или оставьте значения по умолчанию и нажмите «Далее».
10. Установите флажок для автоматической перезагрузки сервера, если это необходимо, и щелкните «Да» в окне подтверждения. Нажмите кнопку «Установить».

Экран 2. Создание виртуального коммутатора

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

bcdedit /enum

из командной строки показывает, что гипервизор теперь загружается автоматически при старте системы. Результат выполнения команды показан на экране 3.

Экран 3. Результат выполнения команды, показывающий автозагрузку гипервизора при старте системы

Запустите диспетчер сервера, в разделе «Инструменты» выберите «Диспетчер Hyper-V» и подключитесь к своему серверу. На нем пока нет виртуальных машин. Но если вы нажмете «Диспетчер виртуальных коммутаторов», вы увидите единственный виртуальный коммутатор, который будет называться так же, как и контроллер сетевого адаптера, например Realtek PCIe GBE Family Controller, как показано на экране 4.

Экран 4. Настройка виртуального коммутатора

Я рекомендую заменить название на более понятное, например «Внешний коммутатор», чтобы было ясно, к какой сети он подключен. Использовать типовые имена для коммутаторов на всех хостах Hyper-V очень важно. Если вы перемещаете виртуальные машины между хостами, коммутатор с одним и тем же названием должен существовать как на исходном, так и на конечном хосте, чтобы виртуальная машина сохранила сетевое подключение. Кроме того, как показано на экране 4, не выбирайте пункт Allow management operating system to share this network adapter. Данная настройка нужна, только если у вас нет отдельного сетевого адаптера для управления сервером или если у вас только один сетевой адаптер, который используется совместно виртуальными машинами и хостом. Здесь же вы можете создать дополнительные коммутаторы, если это необходимо.

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

Есть еще несколько моментов, на которые необходимо обратить внимание.

• Если вы включили Windows Update, то, вероятно, не хотите, чтобы ваш сервер автоматически перезагружался после установки обновлений. Поэтому если вы используете корпоративное решение для управления обновлениями, настройте сервисный интервал, во время которого сервер Hyper-V может перезагрузиться, так, чтобы он не пересекался с рабочими часами. Во время перезагрузки Hyper-V виртуальные машины недоступны.
• Если вы используете антивирусное программное обеспечение на сервере Hyper-V, то в целях повышения производительности необходимо исключить из сканирования определенные файлы и папки. Исключения описаны в статье Microsoft «Virtual machines are missing, or error 0x800704C8, 0x80070037, or 0x800703E3 occurs when you try to start or create a virtual machine» (support.microsoft.com/kb/961804).
• Делайте резервные копии своих виртуальных машин. В Windows Server 2012 дополнительное преимущество заключается в том, что если у вас есть резервная копия виртуальной машины, то импортировать ее на новый сервер Hyper-V очень просто. Вам не нужно предварительно экспортировать ее.
• Если на вашем сервере Hyper-V установлен большой объем оперативной памяти, то по умолчанию Windows создаст большой файл подкачки. Размер этого файла может быть изменен вручную, так как большую часть памяти используют виртуальные машины. Вы спокойно можете создать для сервера Hyper-V файл подкачки размером 4 Гбайт, используя модуль «Система» в панели управления. Перейдите на вкладку «Дополнительно», нажмите кнопку «Настройки» в разделе «Производительность», снова откройте вкладку «Дополнительно», нажмите кнопку «Изменить» в разделе «Виртуальная память» и задайте необходимый размер. Нажмите «Задать» и «ОК» во всех открытых диалоговых окнах.

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

В статье подробно описан процесс установки и настройки роли Hyper-V, создание виртуальной машины, а также настройка сетевого взаимодействия и запуск виртуальной машины на Windows Server 2012 R2.

Для установки роли Hyper-V на Windows Server 2012 R2 потребуется компьютер, под управлением Windows Server 2012 R2 (О том как установить Windows Server 2012 R2 можно прочитать в данной статье: «Установка и активация Windows Server 2012 R2 c USB флешки» ).

I. Установка роли Hyper-V на Windows Server 2012 R2

1. Откройте окно диспетчера сервера и выберите пункт Добавить роли и компоненты (Рис.1).

Рис.1

.

2. В появившемся окне нажмите Далее (Рис.2).

Рис.2

.

3. Выберите пункт Установка ролей и компонентов, затем нажмите Далее (Рис.3).

Рис.3

.

4. Выберите сервер на который будет производиться установка роли, затем нажмите Далее (Рис.4).

Рис.4

.

5. Поставьте галочку напротив Hyper-V (Рис.5).

Рис.5

.

6. Мастер установки ролей предупредит, что для установки роли Hyper-V нужно установить несколько компонентов. Нажмите Добавить компоненты (Рис.6).

Рис.6

.

7. Убедитесь, что после установки необходимых компонентов напротив Hyper-V стоит галочка, затем нажмите Далее (Рис.7).

Рис.7

.

8. На этапе добавления компонентов оставьте все значения по умолчанию и нажмите Далее (Рис.8).

Рис.8

.

9. Ознакомьтесь с дополнительной информацией касательно Hyper-V, затем нажмите Далее (Рис.9).

Рис.9

.

10. Мастер добавления ролей и компонентов предложит настроить сеть и выбрать сетевые адаптеры, ничего не выбирайте (настройку можно будет произвести позднее) и нажмите Далее (Рис.10).

Рис.10

.

11. Настройку миграции тоже можно произвести позднее, нажмите Далее (Рис.11).

Рис.11

.

12. Оставьте настройки по умолчанию и нажмите Далее (Рис.12).

Рис.12

.

13. Нажмите Установить (Рис.13).

Рис.13

.

14. Начнётся процесс установки (Рис.14).

Рис.14

.

15. После окончания установки нажмите Закрыть, затем перезагрузите сервер (Рис.15).

Рис.15

.

16. После перезагрузки откройте Диспетчер серверов, в левой колонке Вы увидите пункт Hyper-V (Рис.16). На этом установка роли Hyper-V в Windows Server 2012 R2 закончена.

Рис.16

.

II. Создание виртуальной машины в Hyper-V

1. Откройте Диспетчер серверов, затем Средства и выберите Диспетчер Hyper-V (Рис.17).

Рис.17

.

2. В открывшемся окне нажмите Создать (Рис.18).

Рис.18

.

3. В открывшемся меню выберите Виртуальная машина… (Рис.19).

Рис.19

.

4. В открывшемся окне Мастера создания виртуальной машины нажмите Далее (Рис.20).

Рис.20

.

5. В поле Имя введите имя для новой виртуальной машины (прим. в данном руководстве это DemoVM), затем нажмите Далее (Рис.21).

Рис.21

.

6. Выберите поколение виртуальной машины, затем нажмите Далее (Рис.22).

Рис.22

.

7. Поставьте галочку напротив Использовать для этой виртуальной машины динамическую память, затем нажмите Далее (Рис.23).

Рис.23

.

8. В окне настроек сети — нажмите Далее (Рис.24).

Рис.24

.

9. Выберите пункт Создать виртуальный жесткий диск, затем установите размер диска, после чего нажмите Далее (Рис.25).

Рис.25

.

10. Выберите пункт Установить операционную систему позднее, затем нажмите Далее (Рис.26).

Рис.26

.

11. Для создания виртуальной машины и закрытия мастера нажмите Готово (Рис.27). На этом создание виртуальной машины завершено.

Рис.27

.

III. Настройка сетевого взаимодействия

1. Откройте Диспетчер Hyper-V и выберите Диспетчер виртуальных коммутаторов (Рис.28).

Рис.28

.

2. Выберите необходимый тип виртуального коммутатора (прим. описание для каждого типа указаны в диспетчере виртуальных коммутаторов ниже. В данном руководстве будет использоваться Внешний тип виртуального коммутатора), затем нажмите ОК (Рис.29).

Рис.29

.

3. В поле Имя введите имя для виртуального коммутатора (прим. в данном руководстве это Demo Virtual switch). Выберите пункт Внешняя сеть и укажите Сетевое подключение, затем поставьте галочку напротив Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру, нажмите Применить и ОК (Рис.30).

Рис.30

.

4. В появившемся окне предупреждения нажмите Да (Рис.31).

Рис.31

.

5. Откройте Диспетчер Hyper-V, выберите виртуальную машину (прим. в данном руководстве это DemoVM), откройте меню (пр. кнопкой мыши) и выберите Параметры… (Рис.32).

Рис.32

.

6. В окне Параметров выберите Сетевой адаптер, затем укажите виртуальный коммутатор (прим. в данном руководстве это Demo Virtual switch) (Рис.33).

Рис.33

.

7. После того как Вы выбрали виртуальный коммутатор, нажмите Применить, затем ОК (Рис.34). На этом настройка сети завершена.

Рис.34

.

IV. Запуск виртуальной машины в Hyper-V

1. Откройте Диспетчер Hyper-V и выберите Параметры… (Рис.35).

Рис.35

.

2. Выберите DVD-дисковод, затем пункт Файл образа и нажмите Обзор… (Рис.36).

Рис.36

.

3. Выберите ISO-образ операционной системы (прим. в данном руководстве, в качестве примера, используется Windows Server 2012 R2) и нажмите Открыть (Рис.37).

Рис.37

.

4. Нажмите Применить, затем ОК (Рис.38).

Рис.38

.

5. В Диспетчере Hyper-V выберите виртуальную машину, вызовите меню (пр. кнопкой мыши) и нажмите Пуск (Рис.39).

Рис.39

.

6. Сделайте двойной клик на названии виртуальной машины, после чего откроется окно запущенной виртуальной машины (Рис.40).

Рис.40

.

Установка и настройки роли Hyper-V, создание виртуальной машины, а также настройка сетевого взаимодействия и запуск виртуальной машины на Windows Server 2012 R2 произведены! Надеемся, что данное руководство было для Вас полезно!

.

Новая функциональность, новые редакции, новая модель лицензирования

Введение

По прошествии четырех лет разработки, 4 сентября 2012 года, Microsoft объявила о доступности новой версии Windows Server — Microsoft Windows Server 2012.

Исторически операционные системы линейки Windows Server — это ОС, предназначенные для управления аппаратным обеспечением серверов, обладающие требуемыми для этого функциональными особенностями. Также эти серверные ОС содержат специализированные службы (программные компоненты), предназначенные для организации, мониторинга и управления ИТ-инфраструктурой предприятия, начиная от управления адресным пространством протокола IP и учетными записями пользователей и заканчивая организацией отказоустойчивых сетевых сервисов.

Если мы посмотрим на ИТ-инфраструктуру предприятий образца 10-летней давности, то в большом количестве случаев увидим т. н. модель «on-premise», когда серверное аппаратное обеспечение приобреталось предприятиями в собственность, на каждом сервере разворачивался экземпляр операционной системы, настраивались ее комплектные службы, устанавливалось прочее программное обеспечение, реализующее дополнительную функциональность. В этой классической модели ИТ-инфраструктуры предприятия взаимодействие, как правило, строилось по схеме клиент—сервер, причем под клиентом в подавляющем большинстве случаев понимался ПК. То есть клиентский ПК, как устройство, на сетевом уровне взаимодействовал через локальную сеть с сервером, а на уровне приложений некое клиентское приложение взаимодействовало с соответствующим серверным.

В то же время, сейчас в индустрии мы видим трансформацию этой модели в модель «подключенных устройств и непрерывных сервисов». Всё большее количество пользователей работает со всё более и более возрастающим количеством разнообразнейших подключенных к интернету устройств: смартфонами, планшетами, ноутбуками, настольными ПК и даже «умными» телевизорами. На стороне «серверов» предприятия пользователи ожидают уже не просто серверных приложений, взаимодействующих с единственным их устройством, но непрерывно, 24×7×365, функционирующих сервисов: «облачных», умных, надежных, быстрых, соответствующим образом обрабатывающих и умеющих синхронизировать данные между всеми устройствами. То есть нужна серверная операционная система, которая позволила бы строить такие сервисы. Растет и количество данных: в реляционных БД, текстовых документах и электронных таблицах накапливается все большее количество информации.

В условиях такой трансформации Microsoft поставила перед собой цель выпустить настоящую «облачную» операционную систему — платформу масштаба уже не единичного сервера, но центра обработки данных (ЦОД) с единообразными подходами и инструментами для управления и разработки приложений в частном, партнерском, глобальном облаке и гибридных вариантах. По аналогии с тем, как Microsoft перепридумала клиентскую ОС Windows, серьезному переосмыслению подверглась и парадигма серверной ОС Windows Server.

Ключевыми строительными блоками здесь являются Windows Server 2012, Windows Azure и System Center 2012 SP1.

Говоря «облачная операционная система», Microsoft понимает под этим четыре группы требований к серверной ОС:

1. Преобразование ЦОД. Необходимо иметь возможность взять все ресурсы ЦОД (хранение, сеть, вычислительные мощности), разделить их между облачными службами, обеспечить возможность высокой загрузки (эффективного использования) этих ресурсов. Нужно иметь возможность гибкого масштабирования, то есть для любой конкретной службы необходимо иметь возможность выделения ей дополнительных ресурсов, но только на то время, когда они ей нужны. Необходимо иметь возможность строить инфраструктуру, работающую в режимах always-up и always-on (всегда включено и всегда доступно). Необходимо иметь возможность автоматизирования задач по управлению ЦОД посредством API и порталов самообслуживания.
2. Необходимо иметь возможность размещения современных приложений поверх такой инфраструктуры. Нужно иметь большой набор работающих служб, позволяющих строить социальные, мобильные приложения и приложения для обработки сверхбольших массивов данных, т. е. поддержать все современные тренды. Предприятиям необходимо иметь гибкость в инструментарии, в среде разработки, чтобы быстро строить эти приложения. Необходимо иметь быстрый цикл разработки, который объединял бы разработчиков и управленцев.
3. Microsoft ставил перед собой задачу поддержать тенденцию BYOD (bring your own device = приноси свое собственное устройство) на предприятиях, в то же время обеспечивая необходимые контроль и управление со стороны ИТ-службы.
4. Необходимо было поддержать возможности по обработке и хранению любых массивов данных с любой парадигмой хранения: как SQL, так и NoSQL, совместно обрабатывать данные предприятия и данные из внешних структурированных источников, создавая новые возможности.

Результатом явилось построение облачной операционной системы и платформы. Новая ОС может быть развернута в своем ЦОД, можно использовать ее как услугу из партнерского ЦОД или из глобальной Windows Azure; при этом обеспечивается единый подход к виртуализации, инфраструктуре управления, инфраструктуре разработки приложений, управлению данными и сервисами идентификации.

Однако новая ОС несет множество новаций и усовершенствований и для тех, кто не планирует переселяться в облака

Редакции и лицензирование в линейке Windows Server 2012

Обычно вопросы лицензирования, редакций и их ограничений у всех производителей — одни из самых непростых. В линейке Windows Server 2012 структура упрощена и унифицирована по сравнению с предыдущим поколением.

В линейке Windows Server 2012 доступны 4 редакции.

Ранее входившие в линейку редакции Windows Small Business Server (SBS), Windows Home Server более развиваться не будут, так как, по наблюдениям Microsoft, целевые аудитории этих продуктов (домашние пользователи, малый бизнес) все чаще выбирают облачные службы для решения своих задач, например таких, как организация электронной почты и совместной работы и резервного копирования, вместо развертывания собственной инфраструктуры.

Также ранее входившие в линейку редакции Enterprise, High-Performance Computing (HPC) и Web Server в новом поколении недоступны.

Важным изменением является то, что функционально редакции Datacenter и Standard не отличаются — теперь можно строить кластеры высокой доступности и отказоустойчивые кластеры, имея лицензию на Standard.

Платформа виртуализации (Hyper-V)

Поскольку виртуализация — краеугольный камень облачных сред, много нового появилось именно в этой области.

Принята во внимание необходимость больших компаний и облачных провайдеров лучше управлять их ЦОДами, учитывая потребление ресурсов: вычислительных, хранения, сети.

Масштабируемость

Если предприятию было недостаточно мощности решений виртуализации предыдущего поколения, то Windows Server 2012 может быть выходом, так как Hyper-V 3-й версии поддерживает:

• до 320 логических процессоров на физический сервер и до 64 процессоров в виртуальной машине;
• до 4 ТБ оперативной памяти на физический сервер и до 1 ТБ памяти в виртуальной машине;
• в виртуальной машине поддерживается жесткий диск объемом до 64 ТБ;
• кластеры Hyper-V с количеством узлов до 64 и до 8000 виртуальных машин на кластер до 1024 машин на узел.

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

Live Migration

Live Migration (живая миграция) — возможность переноса виртуальных машин между физическими серверами без перерыва в предоставлении сервисов клиентам — с появлением Windows Server 2012 стала возможна более чем для одной виртуальной машины одновременно. Фактически количество виртуальных машин, одновременно вживую мигрирующих между хостами, зависит от мощности оборудования. При использовании новой версии протокола SMB, SMB3 (см. ниже), и агрегировании высокопроизводительных сетевых интерфейсов (NIC teaming) можно одновременно переносить 120 виртуальных машин.

Также, благодаря поддержке размещения виртуальных жестких дисков на общих папках по протоколу SMB3, стало возможным выполнять Live Migration без использования разделяемого кластерного хранилища (CSV = clustered shared volume).

Microsoft говорит о появлении возможности миграции типа «shared-nothing», т. е. при наличии только Ethernet-кабеля.

Сетевые возможности

Выполнены существенные усовершенствования и в сетевой инфраструктуре Hyper-V. Если в физическом хосте виртуализации будут установлены серьезные сетевые адаптеры, с большим количеством возможностей на аппаратном уровне, например IPSec Offload, то с большой вероятностью, применив Hyper-V 3, все эти «вкусности» удастся получить и внутри виртуальных машин.

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

В настоящее время уже выпущено одно решение, использующее упомянутую архитектуру — виртуальный свитч Cisco Nexus 1000V.

Вместе с тем, даже без применения сторонних решений виртуальный свитч стал мощнее — например, появилась возможность управлять полосой пропускания отдельных виртуальных машин.

Другие механизмы Hyper-V

Также усовершенствованы многие другие механизмы: Hyper-V стал лучше поддерживать NUMA; появился новый формат виртуальных жестких дисков VHDX, поддерживающий жесткие диски формата native 4K и диски большого размера; улучшен механизм Dynamic Memory — добавлена опция Minimum Memory, позволяющая гипервизору забирать память у виртуальных машин, если для запуска нужной ее недостаточно. Стало возможным делать инкрементальные резервные копии работающих виртуальных машин.

Сетевая подсистема

IPv6

В ОС Windows Server 2012 переписана реализация стека протоколов TCP/IP. Основным протоколом сейчас считается IPv6, в то время как IPv4 на внутреннем программном уровне обрабатывается как подмножество IPv6.

На приоритетное использование IPv6 нацелена и реализация многих протоколов более высокого уровня и сервисов — не стоит удивляться, когда при наличии возможности работы и IPv6, и IPv4 будет выбран именно IPv6. Например, служба разрешения доменных имен DNS в первую очередь пытается получить именно IPv6-адрес узла.

Остановимся на некоторых особенностях IPv6:

• первое, что упоминается всеми — большее адресное пространство, что позволит наделить собственным уникальным во вселенной IPv6-адресом ≈3,4·10³⁸ узлов. Вместе с тем, существующие правила выделения IPv6-адресов, учитывающие их структуру, предписывают выделять каждому обратившемуся за собственным блоком IPv6-адресов предприятию подсеть /64, т. е. предприятие получает возможность выдать своим серверам, клиентским ПК и устройствам 2⁶⁴ уникальных глобально маршрутизируемых IPv6-адресов — в 2³² раза больше, чем было во всем вместе взятом IPv4-адресном пространстве Интернета;
• возможность выдать каждому узлу сети (каждому устройству) собственный глобально маршрутизируемый IPv6-адрес сделает гораздо более простой работу сервисов, которые должны из Интернета инициативно доставлять сообщения адресатам внутри корпоративных (да и домашних) сетей — в основном это различные приложения сегмента унифицированных коммуникаций: мессенджеры, коммуникаторы и т. п. Культурный шок: PAT (NAT) — больше нет! Для клиентских же приложений отпадет необходимость постоянно поддерживать открытую через PAT (NAT) TCP-сессию, а для сервера, соответственно, держать их тысячи/десятки тысяч;
• IPv6 позволяет снизить нагрузку и, соответственно, требования к сетевому оборудованию, особенно это будет заметно на высоконагруженном провайдерском оборудовании: из стандарта убрана фрагментация, не нужно считать контрольные суммы, длина заголовков — фиксирована;
• в IPv6 включена обязательная поддержка узлами технологии IPSec. В настоящее время существует большое количество протоколов, разработанных на заре Интернета, к каждому из которых пришлось позже разрабатывать и стандартизовать безопасные аналоги — некие уникальные для каждого протокола «обертки» (HTTP/HTTPS, FTP/SFTP и т. п.). IPv6 позволит уйти от этого «зоопарка» и унифицированно защищать соединение двух узлов на 3-м уровне сетевой модели для любого протокола;
• IPv6 потенциально создает возможность роуминга мобильных устройств между беспроводными сетями различных операторов (Wi-Fi, 3G, 4G и т. д.) без разрыва сессий клиентского ПО, например голосового трафика SIP-клиентов.

В частности, такая входящая в Windows Server технология, как DirectAccess, позволяет организовать защищенный удаленный доступ клиентского компьютера в корпоративную локальную сеть прозрачно для пользователя. Со стороны пользователя нет необходимости использовать какие-либо VPN-клиенты или подключения. DirectAccess, будучи единственный раз настроен, в дальнейшем работает прозрачно для пользователя.

С технологической стороны, DirectAccess — это реализация IPSec VPN на базе IPv6 компании Microsoft. (Это не значит, что он не будет работать поверх транспортных сетей IPv4.)

Кстати, в Windows Server 2012 стало возможным не развертывать PKI, если клиенты DirectAccess — Windows 8.

SMB3

В сетях Microsoft для доступа к ресурсам файл-сервера применяются протоколы SMB (Server Message Block). Уже довольно давно мы работаем с протоколом версии 2, а в Windows Server 2012 вошла новая редакция — SMB 3.0.

На самом деле, протокол SMB 3.0 необходимо рассматривать не в контексте сетевой подсистемы, а в контексте подсистемы хранения данных — и позже мы увидим почему.

В контексте же сетевой подсистемы можно сказать, что SMB 3.0 заточен под современные быстрые локальные гигабитные сети — при его использовании оптимизировано управление протоколом транспортного уровня TCP в таких сетях, учитывается возможность применения т. н. jumbo-фреймов Ethernet. Заточен он также и для применения IPv6.

Подсистема хранения

На крупных предприятиях при построении ИТ-инфраструктур часто применяются специализированные решения для хранения данных, за счет чего достигается определенный уровень гибкости: полка с дисками может использоваться одновременно несколькими серверами, емкость гибко по необходимости распределяется между ними.

В то же время, такие специализированные решения достаточно дороги и в приобретении, и в последующем обслуживании. Администрирование и поддержка этих устройств и интерфейсов (например, Fiber Channel) требуют от администраторов соответствующих знаний и навыков.

При проектировании Windows Server 2012 в Microsoft ставили перед собой задачу реализовать в серверной ОС функциональность, которая позволит предоставить приложениям, таким как SQL Server и Hyper-V, тот же уровень надежности подсистемы хранения, что и специализированные решения, используя относительно недорогие («неумные») дисковые массивы. Причем, для унификации задач администрирования, реализация даже не применяет блочные протоколы (такие как iSCSI), а работает в варианте с обычными файл-серверными протоколами, такими как SMB.

Достигнуто это было в основном двумя механизмами — применением Storage Spaces и протокола SMB3.

SMB3

Таким образом, SMB 3.0 научили:

• максимально использовать возможности «умных» полок, если таковые уже приобретены: использовать технологии Offloaded Data Transfer (ODX), когда сервер только отдает команду полке на перемещение файлов, а полка это сверхбыстро внутри себя делает и возвращает серверу результат выполнения;
• открывать более одной TCP-сессии для копирования файла на сетевых картах, поддерживающих RSS (receive side scaling);
• использовать более одной сетевой карты одновременно для увеличения производительности: если два сервера Windows Server 2012 (или Windows имеют по две сетевые карты, то скорость копирования вырастет;
• использовать более одной сетевой карты одновременно для обеспечения отказоустойчивости: если два сервера Windows Server 2012 (или Windows имеют по две сетевые карты и одна из них откажет, то процесс копирования не остановится, а завершится успешно;
• обеспечивать работу Continuously Available File Server — настоящего отказоустойчивого кластера файл-серверов*.

* Здесь необходимо сделать лирическое отступление. Термин Windows Server Failover Clustering достаточно давно неправильно перевели как «отказоустойчивый кластер». На самом деле это высокодоступный кластер. То есть сервис, оказываемый клиенту конкретным узлом кластера, в случае нештатного выхода этого узла из строя, прервется. Далее, без вмешательства администратора, сервис поднимется на другом узле кластера и продолжит обслуживать клиентов. Ущерб конкретному клиенту, получившему отказ в обслуживании на короткое время, зависит от используемого сервиса и стадии сессии, на которой произошел отказ.

Так вот, новый Continuously Available File Server — это тот самый настоящий «отказоустойчивый файл-сервер», то есть такое устройство кластера, выполняющего роль файл-сервера, при котором отказ узла, обслуживающего конкретного клиента в данный момент времени (например, клиент может копировать большой файл с сервера на локальный диск), не повлечет перерыва в обслуживании для этого клиента — файл на клиента продолжит отдавать другой узел кластера.

Storage Spaces

Storage Spaces — новый механизм, появившийся в Windows Server 2012.

Его ключевая «фишка» — дать возможность организовать высокодоступную и масштабируемую инфраструктуру хранения по значительно более низкой совокупной стоимости владения (TCO), чем специализированные сторадж-решения.

Идея, реализованная этим механизмом — следующая. Есть сервер под управлением Windows Server 2012. У него есть DAS (directly attached storage) — может быть, в форме дисков SATA или SAS, находящихся в корпусе, а может быть, в виде внешних дисковых полок, подключенных по интерфейсу SAS. Полкам не нужно обеспечивать никакой расширенной обработки, то есть не нужно реализовывать алгоритмы RAID, достаточно отдать JBOD — просто набор дисков, то есть полка в данном случае — это просто железка с блоком питания, салазками и интерфейсом SAS.

В механизме Storage Spaces определяются т. н. Storage Pools — базовые логические строительные блоки системы хранения. Они включают один или несколько физических дисков. На уровне Storage Pool один из дисков может быть назначен как диск, находящийся в горячем резерве — он будет автоматически задействован тогда, когда один из рабочих дисков, входящих в Storage Pool, выйдет из строя.

Далее, внутри Storage Pool, определяются виртуальные диски. Виртуальный диск может быть собран в одном из трех режимов:

1. Простой (Simple) — данные будут распределены между физическими дисками, увеличивая производительность, но уменьшая надежность (некий аналог RAID0);
2. Зеркало (Mirror) — данные будут продублированы на двух или трех дисках, увеличивая надежность, но неэффективно используя емкость (некий аналог RAID1);
3. Четность (Parity) — данные и блоки четности будут распределены по дискам, представляя компромиссное решение между первыми двумя режимами (некий аналог RAID5).

Виртуальные диски могут быть собраны с фиксированным размером на физическом диске либо потреблять место из Storage Pool по мере сохранения данных, до определенного для диска размера.

После создания виртуального диска ОС предлагает создать на нем раздел ОС, под который можно отвести все или часть пространства виртуального диска, отформатировать раздел и присвоить ему букву диска. То есть можно сказать, что механизм Storage Spaces формирует виртуальные жесткие диски, логически расположенные между «железом» и «Управлением дисками» (Disk Manager).

В чем же преимущество по сравнению со старым добрым софтовым RAID, работающим в Windows NT с незапамятных времен?

Неверное, самым большим отличием будет являться возможность создать виртуальные диски объемом больше, чем нижележащие диски с учетом режима. Например, определив Storage Pool, включающий три жестких диска по 16 ГБ, можно создать в нем виртуальный диск размером 120 ГБ. По мере того, как диск будет заполняться данными и доступная емкость физических жестких дисков будет заканчиваться, можно добавить в Storage Pool новые физические диски, не меняя ничего на уровне раздела и данных.

Отдельно хотелось бы сказать о производительности решения. Мы понимаем, что на определенном уровне архитектуры Storage Spaces представляют собой софтовую организацию RAID-массива. Софтовая — совсем не значит медленная или плохая. Например, реализация Intel Matrix RAID, несмотря на то что «снаружи» она выглядит как аппаратная, на самом деле для обсчета старших уровней RAID использует ресурсы ЦП. Необходимо полноценно тестировать производительность различных решений, и желательно не абстрактными синтетическими тестами, а тестами, имитирующими или представляющими собой реальную нагрузку.

Что же касается переносимости Storage Spaces между серверами — то она есть, без проблем. Если боевой сервер «упал», то можно подключить жесткие диски к новому и импортировать существующую конфигурацию Storage Spaces.

За счет новых технологий Storage Spaces и SMB3, в числе прочего, может быть собрана следующая архитектура:

Два Hyper-V-хоста обеспечивают режим высокой доступности для исполняющихся на них виртуальных машин. Виртуальные жесткие диски и конфигурация виртуальных машин хранятся на выделенной в совместное использование по протоколу SMB3 папке. Папка, в свою очередь, выделена непрерывно доступным файл-сервером (отказоустойчивым кластером), состоящим из двух серверов, в каждом из которых расположены два SAS HBA (хост-адаптера), каждый из которых соединен с двумя идентичными коробками дисков). На файл-серверах настроены «зеркальные» Storage Spaces, а на соответствующих дисках организовано разделяемое кластерное хранилище (CSV). То есть подсистема хранения вообще не имеет единой точки отказа, и собрана она при этом исключительно средствами Microsoft Windows Server 2012.

Дедупликация данных

Практически стандартной является ситуация, когда каждому сотруднику предприятия на файл-сервере выделена личная папка. Диск файл-сервера, как правило, организован на отказоустойчивом RAID-массиве, осуществляется регулярное резервное копирование, правами на доступ к личной папке обладает только сотрудник. Таким образом, и информация, и интересы предприятия эффективно защищены.

Иногда встречаются вариации схемы: средствами ОС Windows на файл-сервер перенаправлены папки «Мои документы» и «Рабочий стол». То есть сотрудник пользуется этими папками как обычно, а физически они расположены на файл-сервере.

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

В такой ситуации может проявить себя новый механизм Windows Server 2012 — механизм дедупликации данных.

Будучи задействованным для конкретного тома, Windows Server 2012 начинает по определенному расписанию анализировать том на наличие блоков (не файлов, а блоков), содержащих идентичные данные, и обеспечивать их хранение в единственном экземпляре. Конечно, для пользователя это совершенно незаметно.

Расположив два идентичных по содержимому файла на диске, получаем следующую картину до и после дедупликации:

Механизм дедупликации не поддерживает ReFS и данные, защищенные EFS; не обрабатываются файлы менее 32 КБ и файлы с расширенными атрибутами (extended attributes), тома Cluster Shared Volumes и системные тома.

Новая файловая система — ReFS

Новая файловая система доступна только в Windows Server 2012. Хотя она остается совместимой с NTFS на уровне API, для нее действует целый ряд ограничений:

• не поддерживается шифрование NTFS;
• не поддерживается сжатие NTFS;
• не поддерживается на системных томах.

В ReFS для хранения информации о файлах используется структура т. н. «бинарного дерева», что позволяет быстро находить требуемую информацию. В ней не используется механизм «журналирования» NTFS, а реализован другой принцип транзакционности. ReFS хранит расширенную информацию о файлах, например контрольные суммы с возможностью коррекции считанных исходных данных файла, что помогает предотвратить ошибки типа «bit rotting».

CHKDSK

Утилита CHKDSK, отвечающая за проверку логической целостности файловой системы и ранее требовавшая эксклюзивного доступа к диску (отмонтирования тома), в Windows Server 2012 научилась работать в фоне. То есть, например, если большой диск с данными SQL Server требуется проверить CHKDSK, то после перезагрузки сервер запускается, SQL стартует и начинает обслуживать клиентов, а в фоне работает CHKDSK.

Динамический контроль доступа

В предыдущих поколениях Windows Server разграничение на доступ к ресурсам файл-сервера строилось на механизме списков контроля доступа (ACL) на ресурсах и включении учетной записи пользователя в группы.

При наличии большого количества файл-серверов, ресурсов на них и обширного штата пользователей работа по администрированию доступа становилась трудоемкой. Представим ситуацию, когда есть:

1. несколько регионов продаж;
2. несколько уровней допуска к информации внутри подразделений продаж;
3. несколько типов документов по степени конфиденциальности;
4. предусматривается возможность доступа с нескольких категорий устройств: доверенных и недоверенных.

Дизайн становится непростым. Для пользовательских учеток возникают группы вида «G-Sales-RUS-High_Clearance-…». Учесть же требования п.4 вообще не представляется возможным. При этом отметим, что мы в какой-то части дублируем свою же работу: если для учетной записи пользователя в Active Directory мы уже исправно заполняем «Регион», то мы же сами потом и должны включить его учетку в группу «G-Sales-RUS-…».

В таких сценариях и появляется поле для деятельности динамического контроля доступа. Идея заключается в том, что файл-сервер при принятии решения о предоставлении доступа к ресурсу (файлу, папке) сможет учитывать определенные атрибуты пользователя и устройства, источником которых является Active Directory. Например, предоставлять доступ только в том случае, если Страна учетки пользователя = Россия или Германия, Департамент = Финансы, и Тип_Устройства, с которого пользователь пытается получить доступ = Управляемое. То есть для администраторов задача по сведению пользовательских учеток в группы в некоторых сценариях может быть значительно упрощена. Сам пользователь придет за доступом к ресурсу файл-сервера, уже имея набор определенных реквизитов, взятых из Active Directory. А на ресурсе значения этих реквизитов могут быть собраны в логические выражения.

Для развертывания, в числе прочего, требуется функциональный уровень леса не ниже Windows Server 2003 и хотя бы один домен-контроллер на Windows Server 2012, а также файл-сервер на Windows Server 2012. Клиентами могут быть Windows 7.

Особенно интересными могут быть сценарии, когда динамический контроль доступа работает в связке с инфраструктурой классификации файлов (FCI). В этом случае на файлы автоматически в зависимости от их содержимого могут быть установлены расширенные атрибуты типа «УровеньДоступа = КонфиденциальнаяИнформация», а доступ можно настроить, например, только группе «G_Managers» департамента «Управляющая компания».

RDP 8 / RemoteFX второго поколения

Интересные изменения произошли в протоколе удаленных рабочих столов — RDP — с выходом RDP 8.

Если посмотреть на историю вопроса, мы увидим, что на заре существования по протоколу RDP передавались команды GDI — графического интерфейса Windows, которые исполнялись (отрисовывались) на удаленном терминале.

Постепенно протокол эволюционировал, обрастал различными типами, способами и методами кодирования и передачи заданий на отрисовку.

В Windows Server 2008 R2 была представлена концепция RemoteFX, в которой идеология полностью поменялась. С RemoteFX RDP-сервер фактически отрисовывал все сам, брал готовый фрейм-буфер, кодировал одним кодеком и отдавал на клиента.

Теперь в RDP8 вошел RemoteFX, если так можно выразиться, второго поколения. Теперь фрейм-буфер анализируется, для различных участков экрана (графика, статичные изображения, анимация и видео) выбираются разные кодеки, участки кодируются и по отдельности отдаются на клиента. Для изображений применяется прогрессивный рендеринг, то есть изображение в низком разрешении клиент увидит мгновенно, а детали догрузятся так быстро, как это позволит пропускная способность канала.

RemoteFX первого поколения работал только в том случае, если RDP-хост был развернут в виде виртуальной машины Hyper-V и в системе работал совместимый видеоадаптер, реализующий DirectX 10-й версии. Сейчас эти требования ушли: и визуальная часть, и проброс USB-устройств будут работать на RDP-хосте, развернутом прямо на железе, без виртуализации, и не имеющем видеоадаптера с DirectX 10. (Проброс USB-устройств позволяет работать в терминальной сессии любым USB-устройствам, подключенным к клиентскому терминалу, например лицензионным USB-ключикам — проброс осуществляется на уровне передачи данных по протоколу USB.)

RDP8/RemoteFX2 научился подстраиваться под особенности канала связи, используя адаптивные кодеки. То есть при подключении по локальной сети видео будет воспроизводиться в отличном качестве, но и на тонком WAN-канале что-то да будет видно

RDP8 поддерживает multi-touch и жесты, благодаря чему, например, на Microsoft Surface можно устанавливать RDP-соединение до сервера и использовать x86-приложения. В RDP-клиенте есть удаленный курсор, помогающий попадать пальцами по контролам Desktop-интерфейса.

Появился и новый API, который позволяет приложениям использовать адаптирующиеся под пропускную способность канала кодеки. Например, в сценарии развертывания пользовательских ПК как виртуальных машин (т. н. VDI) клиент унифицированных коммуникаций, работающий в терминальной сессии и получающий аудио- и видеопотоки от RDP-клиента, может использовать преимущества RDP8. В настоящее время используется клиентом Lync 2013.

Клиент RDP8 с поддержкой всей новой функциональности уже сейчас доступен для Windows 7.

Режимы Server Core / Minimal Server Interface

Свершилось: режим Server Core в Windows Server 2012 является основным рекомендуемым режимом установки и использования Windows Server. Преимущества такого подхода известны давно: меньше размер на диске, меньше требования к ресурсам (что особенно важно при высокой плотности виртуальных машин на физическом хосте), меньшая поверхность атак и обслуживания (сервер начинает таскать на себя меньше патчей). Кстати, из Server Core можно удалить компонент WoW64, позволяющий исполняться 32-битному коду, превратив Windows Server в настоящую чистую на 100% 64-битную ОС

Интересно, что между Server Core и Server with a GUI теперь находится некий промежуточный вариант, который нельзя выбрать при установке, но в который можно попасть при переходе от одного из двух основных вариантов к другому — т. н. «Minimal Server Interface», включающий Microsoft Management Console (MMC), Server Manager, и подмножество Control Panel.

Вместе с тем, в Windows Server 2012 можно переключаться между режимами Server Core, Minimal Server Interface и Server with a GUI в любое время после установки (в процессе эксплуатации), так что интересным представляется сценарий установки Server with a GUI, настройки сервера и последующего перехода к Server Core.

Для дополнительной экономии места на диске в Windows Server 2012 стало возможным после установки и настройки сервера полностью удалить бинарные файлы тех ролей и функциональности, которые остались незадействованными.

Администрирование

Новый Server Manager

В Windows Server 2012 появился новый Server Manager. Из интересного: можно управлять сразу несколькими серверами, выполняя на них однотипную операцию.

В интерфейсе появился список задач администрирования. Например, после установки DHCP-сервера для администратора устанавливается задача его настройки — выделения диапазонов и пр.

Личные впечатления: приятная неожиданность — пожалуй, это первый Server Manager, который не был сразу же закрыт и у которого не выключалась опция автозагрузки.

PowerShell

PowerShell в Windows Server 2012 существенно расширен: добавились более 2400 (!) командлетов. PowerShell де-факто стал стандартом на управление из командной строки. Всей функциональностью — возможно, за крайне небольшим исключением — можно управлять через PowerShell.

Такой подход не может не радовать. Мы можем вспомнить зоопарк из комплектных утилит командной строки, Support Tools, Resource Kit, специальных утилит, которые техподдержка Microsoft писала сама для себя, и прочего, каждая со своим собственным синтаксисом и возможностью совместного использования только через разбор текстового вывода одной и подачей на вход другой.

Почувствуйте разницу: единообразный синтаксис, передача объектов между командлетами, удаленное управление через стандартизованный интерфейс WS-Management.

Интересно: некоторые утилиты, например netsh, предупреждают, что их функциональность в следующих версиях Windows Server может быть изъята, и советуют переходить на PowerShell для решения задач автоматизации управления.

Заключение

В Windows Server 2012 действительно много новой интересной функциональности. Основные изменения сосредоточены в областях виртуализации, подсистемы хранения, сетях. Моменты, показавшиеся автору наиболее интересными, затронуты в статье.

Вместе с тем, о чем-то мы даже не упомянули: например, о нововведениях в подсистеме печати, VDI, IIS, BranchCache, DHCP…

Скачать пробную версию Windows Server 2012 можно здесь.

Если Вам интересно примерить возможности Windows Server 2012 к инфраструктуре своего предприятия — пишите, будет интересно пообщаться.

Источники:
www.microsoft.com
www.technet.com
www.smb3.info
www.atraining.ru