Windows Server Core: Setup

icon_wserver

Server Core можно рассматривать как ответ на современную ситуацию, когда администратор управляет большим количеством серверов (с внедрением виртуализации количество ОС значительно увеличилось), а сервера эти могут находится как в частном, так и в публичном облаке, и, как следствие, должны быть как можно меньше.

Режим Server Core стал доступен  начиная с Windows Server 2008 стал доступен режим Server Core, преимуществами которого являются снижение времени простоя сервиса (например, по причине установки Windows Updates и последующей перезагрузки) а также снижение площади потенциальных атак (львиная доля которых приходится на Explorer и т.п).

Идея здравая – зачем на сервере Internet Explorer, Windows Media Player и т.п. понять было сложно.

Кроме того, все это счастье потребляет дисковое пространство – размер ОС, обслуживающей сервис мог на порядок превосходить размер сервиса (например AD DS, AD CS, RRAS, etc). Это приводило не только к перерасходам на закупке накопителей, но и увеличивало время простоя при миграциях виртуальных машин, восстановлении из резервных копий и т.п.

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

В Windows Server 2008 в режиме Server Core было доступно совсем немного ролей: AD DS, AD LDS, DNS, DHCP, File Server, Print Server, IIS, Hyper-V.

Основной проблемой являлось отсутствие .NET, а значит установка Exchange, SharePoint, Dynamics и пр. на Core-сервера была невозможной.

И вот, в Windows Server 2012 Core mode был значительно улучшен и теперь является рекомендованным режимом эксплуатации. Тем не менее, еще остались еще роли,  управлять которыми через GUI невозможно через RSAT – например, AD FS.

В этой статье я расскажу о Server Core на примере Windows Server 10, но материал применим и к предыдущим версиям.

При новой установке Server Core Installation будет вариантом по-умолчанию:

Screen-Shot-2014-12-28-at-18.30.48

После установки, запустим sconfig и зададим базовые настройки:

Screen-Shot-2014-12-28-at-18.38.23

После этого, посмотрим какие роли и фичи установлены по-умолчанию:

Get-WindowsFeature | Where-Object {$_.Installed -eq $True}

Screen-Shot-2014-12-28-at-18.40.30

Если на сервере не планируется установка 32-х битного ПО, разумно удалить фичу WoW64 Support:

Uninstall-WindowsFeature WoW64-Support

Удаление этой фичи положительно сказывается на безопасности (зловредное ПО как правило 32х битное) и производительности сервера.

Но если на сервере будет установлен GUI (даже минимальный, который Graphical Management Tools and Infrastructure), WoW64-Support будет нужна.

Теперь, давайте убедимся что сервер занимает около 7Гб дискового пространства:

Get-WmiObject Win32_logicaldisk | ft DeviceId, Size, FreeSpace

Screen-Shot-2014-12-28-at-18.48.25

.. а объем потребляемой оперативной памяти около 0.5Гб:

Get-Counter 'MemoryCommitted Bytes'

Screen-Shot-2014-12-28-at-19.40.22

Установка современного сервера подразумевает удаленное администрирование и отсутствие физического доступа (или необходимости такого доступа) с дисплеем, клавиатурой и мышкой.

Администрирование может выполняться как со специального сервера на котором включены необходимые компоненты RSAT, так и с ПК под управлением Windows, на которую RSAT установлены (об этом ниже).

Но в ряде случаев необходимо обеспечить возможность непосредственного администрирования не только с помощью PowerShell, но и с помощью Server Manager (Graphical Management Tools and Infrastructure) или даже “полновесного” GUI (Graphical Management Tools and Infrastructure + Server Graphical Shell).

Пример зачем может быть нужен GUI – на bare-metal сервере Device Manager может быть использован для специфичных настроек оборудования, а доступен он только после установки Graphical Management Tools and Infrastructure.

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

Установим “минималистичный” GUI:

Install-WindowsFeature Server-Gui-Mgmt-Infra -Source wim:%path%install.wim:4

Screen-Shot-2014-12-28-at-19.05.10

.. или “полновесный” GUI с Internet Explorer и прочим:

Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Source wim:%path%install.wim:4

Обратите внимание, суффикс :4 обозначает что в исходниках находятся файлы для всех 4х редакций:

  • :1 – Standard Edition Server Core
  • :2 – Standard Edition
  • :3 – Datacenter Edition Server Core
  • :4 – Datacenter Edition

“Минималистичный” GUI выглядит следующим образом:

Screen-Shot-2014-12-28-at-19.14.08

После установки “минималистичного” GUI размер диска вырастет на ~3Гб, а портребление оперативной памяти практически не изменится:

Screen-Shot-2014-12-28-at-19.19.58

В случае установки “полновесного” GUI размер диска вырастет на те же ~3Гб, а портребление оперативной памяти также практически не изменится.

Обратите внимание, после удаления GUI:

Remove-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell

.. размер диска не уменьшится:

Screen-Shot-2014-12-28-at-19.26.32

Зато теперь можно устанавливать и удалять GUI без указания исходников:

Screen-Shot-2014-12-28-at-19.27.53

Разумеется, исходники для GUI можно удалить:

Uninstall-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Remove

.. это уменьшит размер диска:

Screen-Shot-2014-12-28-at-19.30.52

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

Get-WindowsFeature | Where-Object installstate -eq "available" | Uninstall-WindowsFeature -Remove

Screen-Shot-2014-12-28-at-17.11.22

Это освободит еще немного дискового пространства:

Screen-Shot-2014-12-28-at-19.38.58

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

Если вы обращали внимание, папка WinSxS занимает не просто много места, но еще и некорректно показывает реально занятое место (за счет хардлинков).

Посмотрим, что покажет анализ содержимого этот папки:

Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

Screen Shot 2015-06-20 at 15.18.01

Попробуем запустить очистку (она занимает определенное время):

Dism.exe /Online /Cleanup-Image /StartComponentCleanup

.. и проверим результат:

Screen Shot 2015-06-20 at 15.27.17

Задача очистки по-умолчанию уже присутствует в Task Scheduller, все что нужно это настроить адекватный график запуска для нее:

Screen Shot 2015-06-20 at 15.26.43

Если Вы используете виртуальные машины, не забудьте выполнить Compact .vhdx-файла.

В итоге, Windows Server 10 в Server Core занимает в два раза меньше места чем полная установка популярного Windows Server 2008R2  (напомню, 2008R2 в Core возможен, но очень ограничен).

Что касается количества обновлений, для Core-варианта их нужно предсказуемо меньше:

Screen Shot 2015-01-02 at 20.10.26

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

Screen-Shot-2014-12-28-at-20.00.34

Для упрощения, можно использовать групповую политику:

Screen-Shot-2014-12-28-at-19.58.10

Для того, чтобы при применении таких политик не пришлось перестраивать структуру OU в соответствии с версиями ОС, можно применить WMI-фильтр:

Screen-Shot-2014-12-28-at-19.59.34

Подведем итоги:

Очевидно, что “полновесный” GUI ухудшает метрики SLA сервисов которые развернуты на этом сервере, хоть и частично упрощает управление.

Кроме того, уменьшение утилизируемого дискового пространства важно при размещении серверов в публичных облаках, например Microsoft Azure или Amazon.

“Минималистичный” GUI является хорошим вариантом для bare-metal хостов, а “Core” является рекомендованным вариантом для большинства установок.

Сценарий: “Установить сервер с GUI – Развернуть на сервере сервис – Выключить GUI” является распространенным, но  я рекомендую изначально планировать установку так, чтобы в ее процессе не приходилось ничего включать-выключать (например, с использованием App Controller).

Что касается управления парком серверов, разумно установить RSAT на ПК администраторов для выполнения ежедневных задач, для редких и ответственных задач, а также на случай аварии использовать высокодоступную виртуальную машину в Azure, и кроме того иметь запасной вариант в виде Power Shell Web Access.

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.