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 будет вариантом по-умолчанию:
После установки, запустим sconfig и зададим базовые настройки:
После этого, посмотрим какие роли и фичи установлены по-умолчанию:
Get-WindowsFeature | Where-Object {$_.Installed -eq $True}
Если на сервере не планируется установка 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
.. а объем потребляемой оперативной памяти около 0.5Гб:
Get-Counter 'MemoryCommitted Bytes'
Установка современного сервера подразумевает удаленное администрирование и отсутствие физического доступа (или необходимости такого доступа) с дисплеем, клавиатурой и мышкой.
Администрирование может выполняться как со специального сервера на котором включены необходимые компоненты 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
.. или “полновесный” 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 выглядит следующим образом:
После установки “минималистичного” GUI размер диска вырастет на ~3Гб, а портребление оперативной памяти практически не изменится:
В случае установки “полновесного” GUI размер диска вырастет на те же ~3Гб, а портребление оперативной памяти также практически не изменится.
Обратите внимание, после удаления GUI:
Remove-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell
.. размер диска не уменьшится:
Зато теперь можно устанавливать и удалять GUI без указания исходников:
Разумеется, исходники для GUI можно удалить:
Uninstall-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Remove
.. это уменьшит размер диска:
Если есть желание еще больше уменьшить дисковое пространство, можно удалить исходники для всех ролей и фич которые не установлены:
Get-WindowsFeature | Where-Object installstate -eq "available" | Uninstall-WindowsFeature -Remove
Это освободит еще немного дискового пространства:
Разумеется, делать это нужно после установки ролей и фич под которые сервер вводится в эксплуатацию.
Если вы обращали внимание, папка WinSxS занимает не просто много места, но еще и некорректно показывает реально занятое место (за счет хардлинков).
Посмотрим, что покажет анализ содержимого этот папки:
Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore
Попробуем запустить очистку (она занимает определенное время):
Dism.exe /Online /Cleanup-Image /StartComponentCleanup
.. и проверим результат:
Задача очистки по-умолчанию уже присутствует в Task Scheduller, все что нужно это настроить адекватный график запуска для нее:
Если Вы используете виртуальные машины, не забудьте выполнить Compact .vhdx-файла.
В итоге, Windows Server 10 в Server Core занимает в два раза меньше места чем полная установка популярного Windows Server 2008R2 (напомню, 2008R2 в Core возможен, но очень ограничен).
Что касается количества обновлений, для Core-варианта их нужно предсказуемо меньше:
В случае когда после удаления исходников все-таки потребуется установить роль или фичу, нужно будет указывать путь к шаре с исходниками или монтировать диск с дистрибутивом:
Для упрощения, можно использовать групповую политику:
Для того, чтобы при применении таких политик не пришлось перестраивать структуру OU в соответствии с версиями ОС, можно применить WMI-фильтр:
Подведем итоги:
Очевидно, что “полновесный” GUI ухудшает метрики SLA сервисов которые развернуты на этом сервере, хоть и частично упрощает управление.
Кроме того, уменьшение утилизируемого дискового пространства важно при размещении серверов в публичных облаках, например Microsoft Azure или Amazon.
“Минималистичный” GUI является хорошим вариантом для bare-metal хостов, а “Core” является рекомендованным вариантом для большинства установок.
Сценарий: “Установить сервер с GUI – Развернуть на сервере сервис – Выключить GUI” является распространенным, но я рекомендую изначально планировать установку так, чтобы в ее процессе не приходилось ничего включать-выключать (например, с использованием App Controller).
Что касается управления парком серверов, разумно установить RSAT на ПК администраторов для выполнения ежедневных задач, для редких и ответственных задач, а также на случай аварии использовать высокодоступную виртуальную машину в Azure, и кроме того иметь запасной вариант в виде Power Shell Web Access.
Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.