Установка WINS
Как и многие другие службы в Windows Server 2008 R2, сервер WINS устанавливается и конфигурируется с помощью мастера добавления компонентов (Add Features Wizard). Этот мастер автоматически устанавливает все необходимые службы и базы данных и выполняет настройку всех касающихся каждой из них параметров. Хотя существуют и другие способы для установки, данный метод является предпочитаемым подходом в Windows Server 2008 R2.
- Выберите в меню Start (Пуск) пункт All Programs-Administrative Tools-Server Manager. Внутри консоли в дереве узлов щелкните правой кнопкой мыши на узле Features (Компоненты) и выберите в контекстном меню пункт Add Features (Добавить компоненты), чтобы запустить мастер добавления компонентов (Add Features Wizard).
- На странице Select Features (Выбор компонентов) прокрутить список компонентов немного вниз и отметьте флажок рядом с компонентом WINS Server (WINS-сервер). Для продолжения щелкните на кнопке Next (Далее).
- Удостоверьтесь в том, что сервер WINS присутствует в окне выбранных параметров.
- Щелкните на кнопке Install (Установить) на странице Confirm Installation Selections (Подтверждение выбранных параметров для установки), чтобы запустить процесс установки WINS-сервера.
- Процесс установки и базовой настройки сервера WINS займет несколько минут.
- По завершении этого процесса щелкните на ссылке Print (Распечатать), E-mail (Отправить по электронной почте) или Save the Installation Report (Сохранить отчет о результатах установки), если результаты установки должны быть сохранены.
- Чтобы завершить процесс установки, на странице Installation Results (Результаты установки) щелкните на кнопке Close (Закрыть).
WINS — еще одна служба, преобразующая имена компьютеров в ІР-адреса. Имя компьютера, например, COMPUTER4, будет преобразовано в IР-адрес, позволяющий компьютерам сети Microsoft находить друг друга и обмениваться информацией.
Служба WINS необходима для поддержки систем с версиями Windows до Windows 2000 и старых приложений, в которых применяется NetBIOS через TCP/IP, например, для утилит командной строки NET. Если в вашей сети нет систем со старыми версиями ОС или старыми приложениями, WINS вам не нужна.
WINS лучше всего работает в клиент-серверных средах: WINS-клиенты посылают запросы на разрешение имен WINS-серверам, те выполняют разрешение и отправляют ответ. Для передачи WINS-запросов и другой информации компьютеры используют протокол NetBIOS. Для разрешения имен компьютеров в ІР-адреса приложения NetBIOS применяют WINS или локальный файл LMHOSTS. В сетях на базе систем, предшествующих Windows 2000, WINS является главной службой разрешения имен. В сетях Windows 2000 и более поздних разрешением имен занимается DNS, а у WINS другая функция: предоставлять системам до Windows 2000 возможность просматривать списки ресурсов сети, а системам с Windows 2000 и более поздним — обнаруживать NetBIOS-ресурсы.
Чтобы включить разрешение имен WINS, вы должны настроить клиенты и серверы WINS. Настройка клиентов состоит в указании IP-адресов серверов WINS. С помощью IP-адреса клиенты способны связаться с WINS-сервером, даже если он расположен в другой подсети. Также клиенты WINS могут связываться при помощи широковещательной рассылки, отправляя другим компьютерам сегмента локальной сети сообщения с запросом их IP-адресов. Поскольку сообщения являются широковещательными, сервер WINS не используется. Любые нe WINS-клиенты, поддерживающие этот тип рассылки сообщений, также могут использовать данный метод для разрешения имен компьютеров в ІР-адреса.
Связываясь с сервером WINS, клиенты создают сеансы, состоящие из трех ключевых этапов:
- Регистрация имени — Клиент передает серверу свое имя и IP-адрес и просит добавить их в базу данных WINS. Если указанные имя и ІР-адрес не используются в сети, сервер WINS принимает запрос и регистрирует клиента в базе данных.
- Обновление имени — Имя закрепляется за клиентом не навсегда. Он пользуется им в течение определенного времени, называемого временем аренды. Клиенту также указывается временной интервал, в течение которого аренда должны быть обновлена. В течение интервала обновления клиент должен повторно зарегистрироваться на сервере.
- Освобождение имени — Если клиент не обновляет аренду, имя освобождается, что позволяет другой системе в сети использовать то же самое имя компьютера, тот же IP-адрес или и то, и другое. Также имена освобождаются при отключении клиента WINS.
Организовав сеанс с сервером WINS, клиент может посылать запросы службе разрешениям имен. Метод разрешения имени зависит от настроек сети. Вообще, существует четыре метода:
- В-узел (широковещательный метод) Для разрешения имен компьютеров в ІР-адреса используются широковещательные сообщения. Компьютеры, которым требуется разрешение, посылают сообщение каждому хосту локальной сети, запрашивая IP-адрес, соответствующий имени компьютера. В больших сетях из сотен и тысяч компьютеров эти сообщения могут занимать значительную часть полосы пропускания.
- Р-узел (одноранговый метод) Для разрешения имен компьютеров в ІР-адреса используются WINS-серверы. Когда клиенту требуется разрешить имя компьютера в IP-адрес, клиент посылает запрос на сервер, а — сервер посылает ему ответ.
- М-узел (смешанный метод) Совмещает широковещательный и одноранговый методы. Клиент WINS сначала пытается использовать для разрешения имени В-узел. Если это не удается, он использует Р-узел. Поскольку В-узел применяется первым, этому методу присущи те же проблемы с загруженностью сети, что и широковещательному методу.
- Н-узел (гибридный метод) Также совмещает широковещательный и одноранговый методы. Клиент сначала пытается использовать одноранговый метод, потом (в случае сбоя) — широковещательный. Поскольку Р-узел применяется первым, в большинстве сетей гибридный метод позволяет достичь наилучшей производительности. По умолчанию в WINS используется именно он.
Если в сети имеются WINS-серверы, клиенты Windows используют для разрешения имей метод Р-узла. Если WINS-серверы отсутствуют, применяется широковещательный метод. Windows-компьютеры также могут использовать для разрешения имен DNS и локальные файлы LMHOSTS и HOSTS. О работе DNS я расскажу Вам не много позже, в следующих постах на сайте logi.cc.
Если вы применяете DHCP для назначения ІР-адресов, вы должны указать метод разрешения имен для DHCP-клиентов. Как это сделать, я напишу в будущих постах. Предпочтительным является гибридный метод.
Привет, Хабр! 14/01/2020 приближается и эта дата знаменует окончание расширенной поддержки для Windows Server 2008 R2, и если вы все еще используете Windows Server 2008 R2, вам следует задуматься про миграцию на более актуальную платформу.
Под катом находится небольшое сравнение потребляемых ресурсов старой и новых платформ Windows Server — роль RDSH. В первую очередь меня интересовала возможность продолжить использование уже имеющихся в наличии серверов HP G6/G7 под управлением VMware Vsphere 5.5.
Информация о Windows Server Lifecycle доступна по этой ссылке Search Product Lifecycle.
У меня будет два тестовых стенда:
- HP DL120 G7, 1*cpu Intel Xeon E3-1240
- HP ML350 G6, 2*cpu Intel Xeon E5620
Сервера будут работать под управлением VMware ESXi 5.5, образ VMware-ESXi-5.5.0-Update1-1746018-HP-5.75.4-Dec2014. Я также пробовал использовать образ VMware-ESXi-5.5.0-Update3-3116895-HP-550.9.4.26-Nov2015, но на полученные результаты это не влияет.
А вот образ VMware-ESXi-5.5.0-Update2-2403361-HP-550.9.2.40.2-Sep2015 дает искаженные результаты, по какой-то причине статистика которую показывает сервер отличается от реальной в два раза. С этим образом максимум что показывает сервер это 50 процентов нагрузки на процессор, видимо какой-то баг. Я вначале обрадовался когда получил первые результаты, но потом понял что что-то не так…
Также следует упомянуть, что поддержка VMware Vsphere 5.5 тоже не вечная, и платформа уже не актуальна, и стоит задуматься про обновление. Информация про VMware Lifecycle доступна в данном документе VMware Lifecycle Product Matrix.
И не стоит забывать про VMware Compatibility Guide. Если говорить про сервер HP DL120 G7, этот сервер никогда не присутствовал в матрицах совместимости, а вот на сервер HP ML350 G6 официально допускается установка ESXi 5.5 U3.
Гостевые ОС
Информация про совместимость ESXi с гостевыми ОС также доступна в VMware Compatibility Guide.
ESXi 5.5 U3 позволяет в качестве гостевой ОС установить Windows Server 2016, и даже версии 5.5 будет для этого достаточно. А вот для установки Windows Server 2019 понадобится ESXi версии 6+, но это никак не помешает мне протестировать задуманное.
У меня будут следующие тестовые VM: WS2008R2SP1, WS2012R2, WS2016 и WS2019.
На все VM установлены агенты VMware Tools 5.5.0-10.2.5.8068406. Установлены все обновления от Microsoft за май 2019 и даже какие-то за июнь 2019, после чего служба обновления была отключена.
Для моих тестов я выполнил минимальный тюнинг, хочу чтобы все работало с максимально стандартными параметрами. Для этого я буду использовать локальные групповые политики, немного подробней про это я напишу в конце.
- отключил «desktop composition»
- разрешил редирект звука и видео
- включил RemoteFX для WS2008R2SP1 и клиентов WS2008R2SP1
- отключил сглаживание шрифтов
- ограничил разрядность цветовой палитры на значении 32
- ограничил количество мониторов на значении 1
Что бы кодек RemoteFX начал работать на WS2008R2SP1 необходимо установить роль RDSH, для более новых версий этого можно не делать. Возможно, RemoteFX используется на WS2008R2SP1 без установки RDSH, но в логах отсутствуют события про активацию этого кодека.
Тест 1
В качестве теста я буду использовать ролик на YouTube с разрешением 720p, What’s new in Remote Desktop Services on Windows Server 2019 — BRK2242.
На каждом из серверов я поочередно открою одну rdp сессию и тестовый ролик в Chrome (версия 75.0.3770.80(64bit)).
В этом тесте в качестве клиента будет использоваться тонкий клиент HP t510 под управлением ОС HP ThinOS 4.4 и с пакетом Freerdp-1.1hp10d-all-4.4-x86-SQ. Данный аппарат подключен к монитору с разрешением Full HD, и профиль тонкого клиента был сброшен до заводского.
Графики я снимал с хоста, все первые тесты будут выполняться на сервере HP DL120G7.
Комментарии к результатам первого теста:
В данном тесте ws2008 потребляет в три раза меньше процессорных ресурсов, но при этом в три раза больше трафика чем другие участники теста.
При током трафике, в один гигабит можно поместить 66 сессий, а вот переход на новую версию сервера вероятно уменьшит в три раза количество пользователей которые смогу работать при таком потреблении процессора.
Визуально картинка в данной презентации приемлема на всех версиях Windows Server. Конечно если запустить что-то более динамичное, то более новые версии серверов показывают картинку заметно лучше. Предположу что это связано с количество кадров, больше кадров = плавное воспроизведение = больше нагрузка на процессор.
Тест 2
Сценарий для второго теста остается без изменений, за исключением использования Firefox (версия 67.0.2 (64bit))
Комментарии к результатам второго теста:
Firefox в паре с ws2019 показывает не плохой результат, потребляет немного больше процессора и заметно меньше трафика чем ws2008.
Тест 3
В этом тесте будет использоваться Chrome, но клиентом уже будет выступать ноутбук с Windows 10 1903, ноутбук подключен к монитору с разрешением FullHD.
Комментарии к результатам третьего теста:
В случаи с ws2008 потребляется меньше трафика, другие изменения не значительны…
Также я заметил что Chrome при отображении на фоне ролика прогресс бара потребляет на 1000 мгц больше, а вот в Firefox такого эффекта я не заметил, и прорисовка прогресс бара на количество потребляемых ресурсов не влияет.
Тест 4
Ноутбук с Windows 10 в паре с Firefox
Комментарии к результатам четвертого теста:
В такой комбинации сервер-клиент-браузер, ws2019+Firefox потребляет меньше ресурсов чем с Chrome, но стал потреблять заметно больше процессора если сравнить с результатами Теста 2.
В случаях с ws2012 и ws2016 результаты всех проведенных тестов получаются заметно ровнее, нету такого разброса как у ws2019.
Тест 5
Данный тест заключен в запуске максимального количества rdp сессий и запуска презентации в каждой из сессии. В этом мне будет помогать Remote Desktop Connection Manager, RDCM будет запущен на ноутбуке с Windows 10.
Разрешение сессий пришлось уменьшить до 1440*900. В качестве результатов просто приведу сводную таблицу:
Комментарии к результатам пятого теста:
Неожиданно, 2019 сервер показал результаты хуже чем ws2012 и ws2016. Сервер 2008 смог открыть 8 сессий в то время как сервера 2012/2016 могут открыть 4 сессии, и 5-я поднимает нагрузку до 100%. Сервер 2019 смог работать максимум с 4-мя сессиями.
Firefox не является для меня приоритетным браузером, и поэтому я запускал его только в ws2019 чтобы убедиться в полученных цифрах.
Тест 6
В этом тесте в игру вступает сервер HP ML350G6 с двумя процессорами Е5620, тестировать буду только 2008 и 2019 сервера. Тест прежний, запуск максимального количества сессий, использоваться будет только Chrome.
Комментарии к результатам шестого теста:
Для запуска 10 сессий на сервере 2008 понадобилось 60 процентов процессорных ресурсов, а для запуска всего 5 сессий на 2019 сервере нужно больше 90 процентов.
Заключительная часть — Тюнинг
Все тестовые VM я вернул на сервер HP DL120G7 и в качестве клиента использовал ноутбук с Windows 10 и его штатный экран с разрешением 1366*768.
К сожалению попытки уменьшить потребление процессора я бы не назвал успешными, но сказать что результатов нету тоже нельзя. Вот список всех доступных параметров локальных групповых политик которые можно использовать для тюнига:
В Windows Server 2008R2 параметры «Optimize visual experience when using RemoteFX» позволяют управлять качеством картинки и количеством кадров, и это дает заметный результат. Уменьшение количества кадров снижает нагрузку на процессор и сеть. Для Windows Server 2019 эти параметры не работают.
Качеством картинки в Windows Server 2019 можно управлять параметром «Configure image quality for RemoteFX Adaptive Graphics», а вот изменить количество кадров нечем, или я такой параметр не нашел.
Я пробовал различные комбинации параметров, но заметные изменения в результатах я смог получить только в нескольких случаях. И самое интересное то что можно заметить изменения в трафике но при этом нагрузка на процессор меняется слабо.
— Приоритезация H.264/AVC 444 увеличила нагрузку на процессор но при это трафик заметно снизился с 2х до 1 мегабита.
This policy setting prioritizes the H.264/AVC 444 graphics mode for non-RemoteFX vGPU scenarios. When you use this setting on the RDP server, the server will use H.264/AVC 444 as the codec in an RDP 10 connection where both the client and server can use H.264/AVC 444.
— Отключение компрессии RDP не снизило загрузку на процессор, но при этом трафик увеличился с 2х до 7 мегабит.
— Включение Losles параметра для image quality приводит к не адекватному потреблению трафика, без изменения нагрузки на процессор. Для каких сценариев данная опция добавлена мне не совсем понятно.
If you enable this policy setting and set quality to Lossless, RemoteFX Adaptive Graphics uses lossless encoding. In this mode, the color integrity of the graphics data is not impacted. However, this setting results in a significant increase in network bandwidth consumption. We recommend that you set this for very specific cases only.
Итоги
Если раньше для работы 10 активных пользователей было достаточно 8 ядерного сервера и еще оставалось свободное место, то теперь такого сервера хватит только на 5 пользователей.
Думаю что пора готовится к замене серверов HP G6 и G7 поколения. Очень жалко расставаться с серверами в которых установлено >100 гб оперативной памяти, я предполагал что они послужат дальше.
Не исключаю что в старых процессорах не хватает аппаратных инструкций, по этому в ближайшее время планирую получить на тест современный сервер. Но честно говоря прогноз у меня пессимистичный, думаю что получить желаемый результат будет возможно только грубой силой, увеличением количества процессорных ядер, а это повлечет за собой увеличение количества необходимых лицензий и стоимости.
The End
Windows Server 2012 R2 Datacenter Windows Server 2012 R2 Essentials Windows Server 2012 R2 Foundation Windows Server 2012 R2 Standard Windows Server 2008 R2 Service Pack 1 Windows Server 2008 R2 Datacenter Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Foundation Windows Server 2008 R2 Standard Windows Server 2008 R2 Web Edition Еще…Меньше
Симптомы
Рассмотрим следующий сценарий:
-
Имеется сервер Windows Internet Name Service (WINS) на компьютере под управлением Windows Server 2012 R2 или Windows Server 2008 R2 Пакет обновления 1 (SP1).
-
При попытке добавить запись многосетевым (имя одного узла и несколько IP-адресов) с помощью команды Netsh WINS-сервера.
-
Многосетевые запись указывает настраиваемый параметр Endchar параметром группы . Например запустите следующую команду, чтобы создать запись:
Netsh wins_server добавить имя = тестирования EndChar = 35 IP = группа {192.168.0.2,192.168.0.3} = 3
В этом случае запись имеет имя без IP-адреса и WINS-сервера отображается запись выпуска.
Причина
Эта проблема возникает из-за отсутствия проверки в файле winsmon.dll.
Решение
Для решения этой проблемы для Windows Server 2012 R2 установки накопительного пакета обновления 2955164.
Для решения этой проблемы для Windows Server 2008 R2 с пакетом обновления 1, установите исправление, описанное в данной статье.
Сведения об обновлении
Дополнительные сведения о том, как получить этот накопительный пакет обновления, щелкните следующий номер статьи базы знаний Майкрософт:
2955164 Windows RT 8.1, Windows 8.1 и Windows Server 2012 R2 накопительный пакет обновления: мая 2014
Сведения об исправлении
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте данное исправление только в тех системах, которые имеют данную проблему.
Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этого раздела нет, отправьте запрос в службу технической поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание посетите следующий веб-узел корпорации Майкрософт:
http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Для установки этого исправления необходимо наличие Windows Server 2008 R2 с пакетом обновления 1.
Дополнительные сведения о получении пакета обновления Windows Server 2008 R2 щелкните следующий номер статьи базы знаний Майкрософт:
976932 сведения о Пакет обновления 1 для Windows 7 и Windows Server 2008 R2
Сведения о реестре
Для использования исправления из этого пакета нет необходимости вносить изменения в реестр.
Необходимость перезагрузки
После установки исправления компьютер необходимо перезагрузить.
Сведения о замене исправлений
Это исправление не заменяет ранее выпущенные исправления.
Глобальная версия этого исправления устанавливает файлы с атрибутами, указанными в приведенных ниже таблицах. Дата и время для файлов указаны в формате UTC. Дата и время для файлов на локальном компьютере отображаются в местном времени с вашим текущим смещением летнего времени (DST). Кроме того, при выполнении определенных операций с файлами, даты и время могут изменяться.
-
Файлы, относящиеся к определенному продукту, этапу разработки (RTM, SPn) и направлению поддержки (LDR, GDR) можно определить по номерам версий, как показано в следующей таблице.
Версия
Продукт
Контрольная точка
Направление поддержки
6.1.760 1.22xxx
Windows Server 2008 R2
SP1
LDR
-
Файлы МАНИФЕСТА (.manifest) и MUM (.mum), устанавливаемые для каждой среды, указаны отдельно в разделе Дополнительные сведения о файлах» для Windows Server 2008 R2». MUM, MANIFEST и связанные файлы каталога безопасности (.cat) очень важны для поддержания состояния обновленных компонентов. Файлы каталога безопасности, для которых не перечислены атрибуты, подписаны цифровой подписью корпорации Майкрософт.
Для всех поддерживаемых версий x64 и Windows Server 2008 R2
|
Имя файла |
Версия файла |
Размер файла |
Дата |
Время |
Платформа |
|---|---|---|---|---|---|
|
Winsmon.dll |
6.1.7601.22619 |
142,336 |
07-Mar-2014 |
02:38 |
x64 |
Статус
Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».
Дополнительные сведения
Для получения дополнительных сведений о терминологии обновлений программного обеспечения щелкните следующий номер статьи базы знаний Майкрософт:
Описание 824684 Стандартные термины, используемые при описании обновлений программных продуктов Майкрософт.
Сведения о дополнительных файлах для Windows Server 2008 R2
Дополнительные файлы для всех поддерживаемых версий Windows Server 2008 R2 для систем на базе x64
|
Свойства файла |
Значение |
|---|---|
|
Имя файла |
Amd64_c344509f2146f617fe1781813b03021a_31bf3856ad364e35_6.1.7601.22619_none_14eae746f1ab01cc.manifest |
|
Версия файла |
Неприменимо |
|
Размер файла |
721 |
|
Дата (UTC) |
07-Mar-2014 |
|
Время (UTC) |
08:14 |
|
Платформа |
Неприменимо |
|
Имя файла |
Amd64_microsoft-windows-i..aming-service-netsh_31bf3856ad364e35_6.1.7601.22619_none_75a2b33d154e6334.manifest |
|
Версия файла |
Неприменимо |
|
Размер файла |
2 787 |
|
Дата (UTC) |
07-Mar-2014 |
|
Время (UTC) |
05:40 |
|
Платформа |
Неприменимо |
|
Имя файла |
Update.mum |
|
Версия файла |
Неприменимо |
|
Размер файла |
1,680 |
|
Дата (UTC) |
07-Mar-2014 |
|
Время (UTC) |
08:14 |
|
Платформа |
Неприменимо |