Iis о планировании пропускной способности


Содержание

Ограничение использования CPU для Application Pool в IIS 8

Важной функцией любого веб-сервера является возможность ограничения использования процессорных ресурсов CPU определенным сайтом, в противном случае один сайт может монополизировать ресурсы CPU, что может быть неприемлемо, особенно для серверов веб-хостинга, разделяемых ресурсы между несколькими клиентами с разными сайтами. В IIS (Internet Information Services) 7.0 и более ранних версиях, присутствовала возможность мониторинга использования CPU веб приложениями и отключения на несколько минут пула приложений, превысившего заданный лимит. Полноценная возможность управления потреблением ресурсов CPU, доступных каждому пулу приложений, появилась только в IIS 8.0 (Windows Server 2012 и выше). Эта возможность называется CPU Throttling и позволяет вместо временной остановки чрезмерного агрессивного к процессору пула приложений, задать максимальное количество ресурсов CPU, доступных каждому пулу IIS.

В этой статье мы покажем, как ограничить использование CPU пулами приложений в IIS 8 (и выше) на примере веб-сервера на базе Windows Server 2012.

Откройте консоль Internet Information Services (IIS) Manager (%systemroot%\system32\inetsrv\iis.msc), разверните в дереве ваш сервер и выберите раздел Application Pools. Настройки CPU Throttling в IIS находятся в разделе параметров каждого пула.

  • Если нужно включить ограничения для конкретного пула, выберите его в списке и перейдите в раздел настроек Advanced Settings.
  • Если нужно задать настройки лимитов по-умолчанию для всех пулов, нужно выбрать секцию Set Application Pool Defaults.

В окне настроек Advanced Settings нас интересуют параметры, задаваемые в секции CPU:

  • Limit – максимальный % процессорного времени, который может использовать пул приложений. При превышении этого значения, выполняется действие, указанное в поле Limit. В IIS 8 процент задается в тысячных долях (1/ 1000 процента ). К примеру, чтобы ограничить потребление CPU в 20%, в поле Limit нужно указать 20000. В IIS 8.5 значение указывается в обычных процентах. Отключить лимит использования можно, задав 0
  • Limit Action – действие, которое выполняется с пулом при превышении лимита использования CPU
  • Limit Interval (minutes) – периодичность проверки и сброса результатов загрузки при приостановке рабочего процесса. Этот параметр не используется для CPU Throttling, и используется для совместимости с предыдущими версиями IIS.

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

  • NoAction – никаких действий не выполняется, а в журнал записывается событие о превышении CPU
  • KillW3wp (Kill worker processes) — рабочий процесс пула, превысившего лимит приостанавливается на время, указанное в поле Limit Interval. В журнал добавляется соответствующая запись.
  • Throttle – жесткое ограничение доступных ресурсов CPUзначением, заданным в поле Limit. Значение поля Limit в этом случае игнорируется, а в журнал пишется событие.
  • ThrottleUnderLimit – ограничения работают только при высокой загрузке сервера. При наличии свободных ресурсов CPU, пул может превысить заданный лимит.

Настроить CPU Throttling можно и из командной строки с помощью утилиты appcmd. Например, чтобы для пула DefaultAppPool установить ограничение в 30% использования CPU, нужно выполнить команду:

%systemroot%\system32\inetsrv\appcmd set apppool DefaultAppPool /cpu.limit:30000 /cpu.action:Throttle

Включить ограничение для всех пулов IIS можно так:

%systemroot%\system32\inetsrv\appcmd set config -section:system.applicationHost/applicationPools /applicationPoolDefaults.cpu.limit:10000 /cpu.action:Throttle /commit:apphost

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

Таким образом, в IIS 8 появилась возможность гибкого регулирования загрузки сервера запущенными веб-приложениями. Но нужно понимать, что CPU Throttling используется только для ограничения максимальной загрузки CPU, но не для резервирования процессорных мощностей для веб-приложения.

Настройка IIS

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

Кэширование вывода

Мы уже знаем, что ASP.NET поддерживает собственный механизм кеширования вывода, зачем же использовать еще один подобный механизм в IIS? Ответ на этот вопрос прост: помимо страниц ASP.NET существуют и другие виды содержимого, которое можно кешировать. Например, мы можем кешировать часто запрашиваемые статические файлы изображений или вывод собственных обработчиков HTTP-запросов. Для этой цели как раз и можно использовать механизм кеширования, поддерживаемый веб-сервером IIS.

В IIS имеется два механизма кеширования: кеш в пространстве пользователя и кеш в пространстве ядра.

Кеширование в пространстве пользователя

Так же как ASP.NET, веб-сервер IIS способен кешировать ответы в памяти, чтобы ответы на последующие запросы могли отправляться из кеша в памяти, без обращения к статическим файлам на диске и без вызова программного кода на стороне сервера.

Чтобы настроить кеширование, откройте приложение IIS Manager, выберите свое веб-приложение, откройте настройку Output Caching (Кеширование вывода), щелкните на ссылке Add (Добавить) в панели Actions (Действия), чтобы добавить новое правило кеширования, или выберите существующее правило для редактирования.

Чтобы создать новое правило кеширования в пространстве пользователя, добавьте новое правило, введите расширение имен файлов, которые требуется кешировать, и отметьте флажок User-mode caching (Кеширование в режиме пользователя) в диалоге Add Cache Rule (Добавить правило кеширования), как показано на рисунке ниже:

Отметив флажок, вы получите возможность выбирать, когда кешированный элемент будет удаляться из памяти, после обновления файла на диске или спустя некоторое время с момента кеширования. Для статических файлов больше подходит вариант удаления после обновления, тогда как определение интервала времени больше подходит для динамического содержимого. Щелкнув на кнопке Advanced (Дополнительно) можно получить доступ к настройкам, управляющим кешированием различных версий вывода (согласно параметрам в строке запроса или HTTP-заголовкам).

После добавления правила кеширования, настройки сохраняются в файле web.config приложения, в разделе system.webServer caching. Например, для правила кеширования страниц .aspx на срок до 30 минут, с учетом HTTP-заголовка Accept-Language, будет сгенерирован следующий код в конфигурационном файле:

Кеширование в пространстве ядра

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

Настройка правил кеширования в пространстве ядра выполняется почти так же, как кеширование в пространстве пользователя. В диалоге настройки правила установите флажок Kernel-mode caching (Кеширование в режиме ядра) и выберите желаемый способ кеширования.

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

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

Настройка пула приложения

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

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

Перезапуск

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

Для проверки количества и частоты перезапусков пула приложения можно использовать счетчик производительности ASP.NET\Worker Process Restarts. Если вы увидите слишком большое количество перезапусков без явной на то причины, попробуйте сопоставить полученные значения с потреблением памяти приложением и нагрузкой на процессор, потому что перезапуски могут быть обусловлены превышением других пределов, определяемых настройками пула приложения.

Тайм-аут простоя

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

Привязка процессов к ядрам процессора

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


Веб-сад

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

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

Другим примером, когда может пригодиться наличие нескольких процессов, выполняющих одно и то же веб-приложение — использование 64-разрядного сервера IIS, выполняющего 32-разрядное веб-приложение. 64-разрядные серверы обычно имеют большой объем памяти, а 32-разрядное приложение может использовать не более 2 Гбайт, что часто приводит к увеличению частоты сборки мусора и, вероятно, к перезапускам пула приложения. Поддерживая два или три рабочих процесса для 32-разрядного веб-приложения, можно добиться более полного использования памяти сервера, уменьшить частоту сборки мусора и перезапусков пула приложения.

В настройках IIS пула приложения можно определить максимальное количество рабочих процессов, которое можно запустить для обслуживания запросов. Если установить этот параметр в значение больше 1 (значение по умолчанию), с ростом нагрузки на веб-приложение для него будут запускаться дополнительные рабочие процессы, вплоть до указанного максимума. Пул приложения, имеющий более одного процесса, называется «веб-садом» («Web Garden»). Каждый раз, когда устанавливается соединение с клиентом, оно связывается с рабочим процессом, который будет обслуживать запросы от этого клиента, при этом соблюдается равномерное распределение запросов от пользователей между процессами и уменьшаются накладные расходы на конкуренцию.

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

Десять лучших способов улучшения производительности IIS 7.0

Посетителей: 11846 | Просмотров: 14496 (сегодня 2) Шрифт:

Чтобы понять причину этого явления, необходимо сначала разобраться с сутью последнего выпуска IIS. Версия IIS 6.0 содержала существенные технологические изменения, направленные на достижение трех целей: повышение уровня безопасности, увеличение надежности и улучшение производительности. Выпуск версии IIS 7.0 преследовал совершенно иную цель: на основе высокопроизводительного кода базовых компонентов веб-сервера, написанного для версии 6.0, создать модульную и расширяемую платформу, которая поддерживала бы основные сценарии развертывания веб-приложений и управления ими.

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

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

Скорее всего, просто переход на IIS 7.0 не выявит всех преимуществ нового веб-сервера, хотя в некоторых случаях и этого будет достаточно. Например, на узле Microsoft.com было отмечено 10-процентное улучшение эффективности использования ЦП (полный анализ доступен в блоге группы разработки Microsoft.com наgo.microsoft.com/fwlink/?Link >® (оба процесса теперь выполняются на уровне ядра), а также улучшение вертикальной масштабируемости на многопроцессорных и многоядерных машинах.

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

Экономичные веб-серверы

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

Полный набор функций веб-сервера IIS 7.0 состоит из 44 модулей, включая собственные модули IIS и ASP.NET, предоставляющие службы для интегрированного конвейера. В модулях реализованы такие функции, как проверка подлинности (модули проверки подлинности Windows и дайджест-проверки подлинности), поддержка инфраструктуры приложения (модуль FastCGI), службы приложений (модуль состояния сеанса), обеспечение безопасности (модуль фильтрации запросов) и производительности (модуль кэширования выходных данных). Однако минимальному веб-серверу, обслуживающему статические страницы, для работы требуется всего 2 модуля!

Количество дополнительные данных от неиспользуемых модулей может быть довольно значительным — например, от модуля записи запросов в журнал или от модуля трассировки неудачно завершившихся запросов. Если удалить эти модули из окружения, где они не нужны, можно получить прирост общей пропускной способности и уменьшение времени реакции сервера, что в свою очередь улучшит такие характеристики нагрузки на сервер, как время до получения первого байта (TTFB) и время до получения последнего байта (TTLB).

На рис. 1 показаны результаты простых тестов пропускной способности для HTML-файла (статическая нагрузка) и страницы «Здравствуй, мир», написанной на ASP.NET (нагрузка ASP.NET). Использовались три конфигурации веб-сервера: с полным набором функций, с предлагаемым по умолчанию набором функций для каждого типа нагрузки и с минимальным набором необходимых для каждого типа нагрузки функций. Можно заметить, что, хотя большинство необязательных функций отключены даже в полной конфигурации сервера, пропускную способность можно существенно увеличить как в случае статической нагрузки, так и при работе ASP.NET, если полностью удалить ненужные функции.

Рис. 1. Пропускная способность сервера при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами

Кроме того, может снизиться объем занимаемой памяти и повыситься плотность веб-узлов, особенно в случае сред совместного размещения или при использования большого количества рабочих процессов. Это происходит за счет уменьшения количества библиотек DLL, загружаемых каждым процессом, а также количества запросов на выделение памяти, происходящих при инициализации модуля и обработке запроса. На рис. 2 изображено использование памяти (в байтах исключительного использования рабочими процессами IIS) в тестах пропускной способности, о которых говорилось выше. И, хотя приведенные в этом примере изменения не так заметны, они, тем не менее, соответствуют всем ожиданиям. Дело в том, что поддержка приложений ASP.NET требует больше служебных данных, чем можно высвободить удалением модулей.

Рис. 2 Использование памяти (в байтах исключительного использования рабочими процессами IIS) сервером при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами

При помощи наборов необходимых условий IIS 7.0 также предоставляет дополнительные возможности по управлению тем, какие модули будут включены на уровне приложения, а также по использованию модулей в зависимости от рабочей нагрузки на них. Хотя для этого и потребуется профессиональная настройка веб-сервера, многоузловые серверы или приложения с несколькими видами рабочей нагрузки могут получить значительные дополнительные преимущества.

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

Использование экономичной операционной системы

В Windows Server ® 2008 реализовано выделение компонентов на уровне операционной системы, посредством чего можно дополнительно сократить контактную зону веб-сервера. Минимальным режимом установки Windows Server 2008 является режим «Server Core», который содержит минимальный набор основных подсистем операционной системы. Для экономичных веб-серверов на базе IIS 7.0 лучшим вариантом установки является именно Server Core.

Однако, рассматривая возможности Server Core, необходимо учитывать, какие его ограничения могут отразиться на работе вашего приложения. В Server Core отсуствует поддержка платформы Microsoft ® .NET Framework, то есть нет ASP.NET, расширений.NET для IIS и диспетчера служб IIS. Кроме того, решение задач местного управления потребует использования средств командной строки, поскольку консоль управления (MMC) также отсутствует. Между приложениями, работающими под управлением Server Core и полной версией Windows Server, не будет особых отличий в объеме занимаемой памяти и пропускной способности приложений, если уже были использованы преимущества компонентной структуры IIS. Работа, выполняемая IIS и вашими приложениями, одинакова на обеих платформах. Однако есть характеристика, где разница будет заметна: место, занимаемое сервером, как на жестком диске, так и в оперативной памяти.

В качестве примера на рис. 3 показана разница в занимаемом объеме после одинаковой статической рабочей нагрузки на серверы, работающие под управлением Windows Server 2008 в полной конфигурации и Server Core. Хотя IIS занимает в обоих случаях почти одинаковое место, общий объем места, занимаемого операционной системой Server Core меньше, что позволяет поддерживать ту же рабочую нагрузку, используя существенно меньший объем памяти. Из-за меньшего размер установки может появиться возможность использовать менее мощное аппаратное обеспечение для работы приложения. При этом основная мощность процессора будет тратиться на обработку запросов приложения, а не операционной системы, что делает Server Core отличным вариантом для виртуализированных сред.

Рис. 3. Память, занимаемая Windows Server 2008 в полной конфигурации и Server Core после выполнения теста на статическую нагрузку

Применение топологий, адаптированных для нужд приложения

Оптимизируя нагрузку на приложение, в ней можно выделить отдельные части. Например, вместо 30 одинаковых веб-серверов можно обойтись 10 веб-серверами, 3 серверами приложений и 3 прокси-серверами, последние из которых будут выполняли бы кэширование и сжатие данных.

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

Во-вторых, специализация может привести к тому, что приложение будет лучше размещено в кэше, что увеличит его производительность. Это относится к кэшам низкого уровня, таким как аппаратный буфер TLB виртуальной памяти, кэш файловой системы, а также другие средства кэширования, реализуемые как операционной системой, так и приложением. Другим источником хорошего местоположения является ЦП. Уменьшение числа одновременно выполняемых операций путем уделения основного внимания только определенной части приложения позволяет уменьшить количество переключений контекста максимально увеличить объем работы, выполняемой ЦП.

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

Это возможно только в конфигурации потоков IIS и ASP.NET, которая существенно влияет параллелизм и косвенно сказывается на использовании памяти, задержке и пропускной способности множества приложений. Рабочая нагрузка статического файла IIS крайне асинхронна и требует максимального уровня одновременных запросов, но использует очень небольшое количество доступных потоков. С другой стороны, многие функции ASP.NET синхронны, отличаются длительной блокировкой и требуют большого количества потоков, тогда как для других функций требуется более низкий предел параллелизма для снижения воздействия на память. Путем выделения статической нагрузки и поврежденных частей конвейера обработки процессов в отдельный процесс или сервер можно оптимизировать параллелизм каждой отдельной нагрузки.

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

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

Улучшенная поддержка приложения

Службы IIS 7.0 включают в себя расширенную поддержку платформ приложений с помощью FastCGI, открытого протокола, поддерживаемого множеством платформ приложений с открытым исходным кодом, которые в противном случае могут не поддерживать надежную и высокопроизводительную собственную интеграцию с IIS. В отличие от протокола CGI, который в течение длительного времени поддерживался IIS, FastCGI обеспечивает значительно улучшенную производительность на платформе Windows. В основном это обусловлено архитектурой многократно используемых процессов FastCGI, уменьшающей значительные затраты на создание процессов для отдельных запросов, что позволяет клиентам использовать преимущества постоянных открытых соединений.

При поддержке платформ приложений в IIS с помощью CGI или другого механизма можно улучшить производительность (а в некоторых случаях и стабильность) путем перехода на протокол FastCGI.

Первой платформой приложений, использующей преимущества этой поддержки, является PHP. Группа разработчиков IIS фактически напрямую работала с компанией Zend Technologies для обеспечения успешной работы реализации FastCGI IIS с PHP и улучшения производительности платформы PHP в Windows. (Более подробные сведения об этом проекте см. в моем блоге по адресу go.microsoft.com/fwlink/?Link >

Перенос PHP и других платформ приложений на IIS 7.0 и FastCGI позволит использовать преимущества различных функций IIS 7.0, в том числе интегрированный контейнер ASP.NET. Это предоставляет очень удобный способ улучшения платформ приложений при помощи служб ASP.NET без их преобразования в ASP.NET. Это также позволяет совместно работать приложениям, использующим различные платформы. Пример использования этого для улучшения существующих приложений при помощи функций и повышения производительности без изменения кода см. в моей статье «Улучшите приложения при помощи интегрированного конвейера ASP.NET» в журнале MSDN ® Magazine (доступна по адресу msdn.microsoft.com/magazine/cc135973.aspx).

Увеличенная плотность приложений

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

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

Обратите внимание на то, что службы IIS 7.0 теперь позволяют подготавливать на каждом сервере больше приложений, чем раньше — в нескольких внутренних тестах достигалась цифра в 100 000 узлов на одном сервере. Это обеспечивает возможность создания и настройки большого числа узлов и приложений.


В качестве предупреждения: для достижения высокоскоростной подготовки необходимо перейти на новые API настройки, поскольку старые API настройки не позволяют этого. Кроме того, не все API настройки IIS предоставляют одинаковые характеристики производительности, поэтому для обеспечения максимальной производительности необходим тщательный выбор API. При возникновении сомнений используйте параметры конфигурации, которые напрямую используют новые объекты настройки IIS, включая пространство имен Microsoft.Web.Administration, служебную программу командной строки AppCmd.exe и объекты настройки IIS COM, которые можно вызвать из сценария, кода .NET или C++.

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

Поскольку для каждого активного приложения необходим определенный объем памяти и рабочий процесс (при использовании рекомендуемой модели изоляции приложений), количество активных приложений сильно зависит от объема памяти приложения. Поэтому хотя для рабочего процесса одного приложения, выполняющего только обслуживание статического содержимого, требуется всего 3 МБ (подобные приложения часто могут использовать рабочий процесс совместно с другими приложениями, работающими со статическим содержим), для некоторых динамических приложений может требоваться 100 МБ ОЗУ или больше даже при низкой загрузке. Это обуславливает незначительную загрузку памяти самим рабочим процессом IIS по сравнению с местом, которое занимает приложение, при определении максимальной возможной плотности.

В типичном сценарии совместного размещения часто можно увидеть так называемое распределение 80/20, когда 80 процентов запросов выполняются к 20 процентам узлов. Результат – небольшой процент активных узлов в любой определенный момент времени. Для обеспечения большего количества активных узлов службы IIS 7.0 предоставляют активное управление временем существования. Это помогает высвободить память неактивных приложений, чтобы можно было разместить большее количество активных приложений.

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

Для обеспечения возможности размещения множества активных приложений также следует использовать преимущества 64-разрядной операционной системы, заключающиеся в возможности использования более 4 ГБ ОЗУ. На основе этого можно настроить рабочие процессы IIS для работы в 32-разрядном режиме (SysWoW64), в котором они используют меньше памяти, одновременно позволяя операционной системе работать с большим объемом памяти, чем возможно в 32-разрядной среде.

Сокращение занимаемой полосы пропускания за счет сжатия данных

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

Одним из наиболее эффективных способов уменьшения полосы пропускания, необходимой для доставки ответов приложения, является использование сжатия HTTP. Оно позволяет значительно уменьшить размер ответа, часто даже в 10 раз, для просто сжимаемого содержимого, такого как HTML. Лучше всего то, что сжатие HTTP поддерживают практически все обозреватели для настольных систем, а затраты на распаковку на оборудовании настольных систем минимальны по сравнению с неявной экономией отправки меньшего количества данных. А поскольку сжатие основано на согласовании кодировки содержимого, определенном в протоколе HTTP 1.1, включение этой функции безопасно для клиентов, не поддерживающих сжатие — эти клиенты просто получают несжатую версию содержимого.

Илон Маск рекомендует:  Деление рисунка для рамки на области. Свойство border-image-slice в пикселях и процентах

Службы IIS 7.0 предоставляет две функции сжатия, представленные в их предшественнике: статическое сжатие и динамическое сжатие. Статическое сжатие выполняет предварительное сжатие статического содержимого и сохраняет его на диск, таким образом, позволяя будущим запросам работать напрямую со сжатым содержимым без затрат на сжатие. Динамическое сжатие выполняет сжатие ответов в реальном времени, и позволяет сжимать созданные приложениями ответы. Все платформы приложений на IIS 7.0 могут использовать преимущества динамического сжатия, включая ASP, ASP.NET и PHP.

Несмотря на распространенный миф, обычно динамическое сжатие не вызывает чрезмерную загрузку ЦП. Фактически, часто динамическое сжатие использует меньше 5 процентов ресурсов ЦП загруженного сервера. Динамическое сжатие может использоваться довольно свободно, обеспечивая максимальную экономию полосы пропускания для выполняющихся приложений.

Можно дополнительно оптимизировать загрузку сжатия, настроив уровень сжатия для достижения необходимого соотношения сжатия и загрузки ЦП. Но на этом все не заканчивается — также можно настроить приложение для поддержки кэширования сжатого содержимого, что устраняет загрузку сжатия на попадания в кэше благодаря работе с уже сжатым содержимым. Имейте в виду, что в кэши вывода ASP.NET и IIS включена дополнительная возможность кэширования сжатого содержимого для поддерживающих это клиентов, а также обработка запросов клиентов, для которых необходимо несжатое содержимое.

Регулировка полосы пропускания для мультимедийных файлов

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

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

Если среднее время просмотра ваших видео составляет всего 5 секунд, но за это время предоставляются (буферизируются) видеоданные длительностью 30 секунд, скорее всего, вы теряете более 80 процентов полосы пропускания!

Год назад для разрешения этой проблемы для клиента, переходящего на бета-выпуск IIS 7.0, я написал модуль регулировки полосы пропускания, автоматически определяющий скорость видео и обеспечивающий предоставление сервером видео клиенту приблизительно с этой же скоростью. Группа мультимедиа IIS использовала этот модуль, называющийся модулем регулировки скорости (см. рис. 4 ) и доступный в центре загрузок iis.net (iis.net/downloads/?tab >

Рис. 4. Регулировки скорости уменьшает использование полосы пропускания

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

Кэширование выводимых данных

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

До IIS 7.0, как IIS, так и ASP.NET предоставляли возможности кэширования в форме кэша ядра IIS и кэша вывода ASP.NET. Кэш ядра IIS обеспечивал максимальную производительность, но ограничивался преимущественно статическим содержимым. Кэш вывода ASP.NET был гораздо более полным решением для кэширования динамического содержимого, за исключением более низкой производительности и менее эффективного управления памятью. Новый кэш вывода в IIS 7.0 ликвидирует разрыв между кэшем ядра IIS и кэшем вывода ASP.NET.

Кэш вывода IIS 7.0 обеспечивает возможность кэширования динамического содержимого из любого приложения, включая ASP, ASP.NET, PHP и любых других платформ приложений, совместимых с IIS 7.0. Предоставляя базовую поддержку изменчивости и срока действия содержимого, эта новая функция позволяет реализовывать кэширование для содержимого, которое не может кэшироваться кэшем ядра IIS. Кэш ядра по-прежнему может использоваться для содержимого, не соответствующего ограничениям.

Кроме того, кэш ядра IIS 7.0 также предоставляет высокопроизводительную альтернативу кэшу вывода ASP.NET для содержимого ASP.NET, не требующего дополнительных функций кэширования (таких как зависимости кэша и недействительность данных в кэше), которые доступны только в кэше вывода ASP.NET.

Что касается кэширования выводимых данных, обычно проблемы связаны с определением верных политик срока действия содержимого, недействительности данных и изменчивости, обеспечивающих эффективное кэширование ответов и одновременное поддержание необходимой правильности и свежести кэша. В большинстве случаев это можно выполнить путем простой настройки верных правил кэширования, хотя иногда требуются более сложные политики, зависящие от информации времени выполнения. Для решения этой проблемы кэш вывода IIS 7.0 предоставляет программные API, которые могут использоваться для обеспечения необходимого поведения кэширования. Это разблокирует потенциал эффективности кэширования для содержимого, кэширование которого в противном случае было бы невыгодным. Кроме того, интегрированный конвейер ASP.NET позволяет использовать кэш вывода ASP.NET для содержимого, не относящегося к ASP.NET.

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

Но выполнение этой сложной работы почти всегда оправдано. Реализация кэша вывода IIS 7.0 позволяет в несколько раз улучшить общую пропускную способность приложения и соответственно уменьшить нагрузку на базу данных и компоненты уровня предприятия.

Преобразование кода ISAPI в модули IIS 7.0

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

Однако IIS 7.0 предоставляет возможность поддержки существующих фильтров и расширений ISAPI путем использования слоя совместимости, реализуемого посредством дополнительных модулей IIS 7.0. Это позволяет существующим компонентам ISAPI работать в IIS 7.0 без необходимости переписывания.

Хотя использование существующих вложений в ISAPI снижает планку для перехода на IIS 7.0, следует серьезно рассмотреть перенос устаревшего кода ISAPI на новые API IIS 7.0. Это устраняет затраты на слой совместимости ISAPI и позволяет использовать преимущества производительности, недоступные для компонентов ISAPI. В зависимости от работы, выполняемой компонентом ISAPI, эти преимущества производительности могут быть довольно значительными. Например, API модуля IIS 7.0 предоставляет встроенную поддержку кэширования метаданных конфигурации и других произвольных данных, связанных с узлами, приложениями, URL-адресами, что можно значительно увеличить скорость выполнения внутренних операций компонента.

Помимо этого, API модуля IIS позволяет модулям асинхронно выполнять длительные операции, такие как получение данных объекта запроса и отправка ответа. Асинхронное выполнение этих задач позволяет серверу масштабироваться до большого количества одновременно клиентов (десятки тысяч) вместо прежнего максимального количества в несколько десятков или самое большое нескольких сотен одновременных клиентов из-за ограничений количества потоков запросов. Асинхронная обработка также может устранить эффект обработки на других запросах и действиях в приложении, снизить загрузку памяти и обеспечить гораздо лучшее использование ЦП.

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

Для этого могут быть необходимы определенные эксперименты и прототипы для определения оптимальной архитектуры, наилучшим образом использующую улучшения перехода. Из-за фундаментальных архитектурных различий ISAPI и API модуля IIS 7.0 прямой маршрут переноса не всегда является верным. Хорошая новость заключается в том, что API модуля IIS 7.0 также более прост в использовании, чем ISAPI, что упрощает переход.

Расширяемость сервера

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

Это может быть выполнено путем замены каких-либо встроенных функций IIS 7.0 пользовательскими реализациями. Хотя IIS 7.0 претерпели значительную оптимизацию и тестирование производительности, они, конечно же, не оптимизированы для всех возможных применений. Поэтому можно повысить производительность определенных модулей путем создания оптимизаций для конкретной рабочей нагрузки. Например, можно решить повторно реализовать модуль вывода каталогов для кэширования списков содержимого каталогов в памяти вместо использования интерфейсов API операционной системы для перечисления файлов.

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

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

Заключение

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

Планирование развертывания WSUS Plan your WSUS deployment

Область применения. Windows Server (половина ежегодного канала), Windows Server 2020, Windows Server 2012 R2, Windows Server 2012 Applies To: Windows Server (Semi-Annual Channel), Windows Server 2020, Windows Server 2012 R2, Windows Server 2012

Первым шагом в процессе развертывания службы Windows Server Update Services (WSUS) является принятие таких важных решений, как выбор сценария развертывания службы WSUS, топологии сети и осмысливание требований к системе. The first step in the deployment of Windows Server Update Services (WSUS) is to make important decisions, such as deciding the WSUS deployment scenario, choosing a network topology, and understanding the system requirements. В следующем контрольном списке перечислены шаги, которые выполняются при подготовке к развертыванию. The following checklist summarizes the steps that are involved in preparing for your deployment.

Задача Task Описание Description
[1,1. Рекомендации по проверке и требования к системе @ no__t-0 1.1. Review considerations and system requirements Проанализируйте список факторов, которые необходимо учесть, а также требования к системе, чтобы убедиться, что у вас есть все необходимое оборудование и программное обеспечение для развертывания службы WSUS. Review the list of considerations and system requirements to ensure that you have all the necessary hardware and software to deploy WSUS.
[1,2. Выбор сценария развертывания WSUS @ no__t-0 1.2. Choose a WSUS deployment scenario Выберите сценарий развертывания службы WSUS, который будет использован. Decide which WSUS deployment scenario will be used.
[1,3. Выберите стратегию хранилища WSUS @ no__t-0 1.3. Choose a WSUS storage strategy Выберите, какая из стратегий хранения данных для службы WSUS наиболее подходит для данного развертывания. Decide which WSUS storage strategy best fits your deployment.
[1,4. Выберите языки обновления WSUS @ no__t-0 1.4. Choose WSUS update languages Выберите те языки обновления для службы WSUS, которые будут установлены. Decide which WSUS update languages will be installed.
[1,5. Планирование групп компьютеров WSUS @ no__t-0 1.5. Plan WSUS computer groups Спланируйте, какой подход относительно групп компьютеров службы WSUS вы будете использовать в ходе развертывания. Plan the WSUS computer group approach that you will use for your deployment.
[1,6. Планирование вопросов производительности WSUS: Фоновая интеллектуальная служба передачи @ no__t-0 1.6. Plan WSUS Performance Considerations: Background Intelligent Transfer Service Разработайте модель службы WSUS, которая позволяла бы добиться оптимизированной производительности. Plan a WSUS design for optimized performance.
[1,7. Автоматическое обновление параметров плана @ no__t-0 1.7. Plan Automatic Updates settings Продумайте, как будете настраивать параметры автоматического обновления в своем сценарии. Plan how you will configure the automatic updates settings for your scenario.


1.1. 1.1. Анализ существующих факторов и требований к системе Review considerations and system requirements

Требования к системе System Requirements

Перед активацией роли сервера службы WSUS подтвердите, что сервер соответствует требованиям к системе, а также что у вас есть необходимые разрешения для завершения установки, руководствуясь следующими указаниями. Before you enable the WSUS server role, confirm that the server meets the system requirements and confirm that you have the necessary permissions to complete the installation by adhering with the following guidelines:

Требования к оборудованию сервера для включения роли WSUS привязаны к требованиям к оборудованию. Server hardware requirements to enable WSUS role are bound to hardware requirements. Минимальные аппаратные требования к WSUS The minimum hardware requirements for WSUS are:

Степпинг процессор x64 с частотой 1,4 ГГц (рекомендуется 2 ГГц или выше) Processor: 1.4 gigahertz (GHz) x64 processor (2 Ghz or faster is recommended)

Свободной Для WSUS требуется еще 2 ГБ ОЗУ, чем требуется для сервера, а также для других служб и программного обеспечения. Memory: WSUS requires an additional 2 GB of RAM more than what is required by the server and all other services or software.

Свободное место на диске: 10 ГБ (рекомендуется 40 ГБ или выше) Available disk space: 10 GB (40 GB or greater is recommended)

Сетевой адаптер: 100 мегабит в секунду (Мбит/с) или более Network adapter: 100 megabits per second (Mbps) or greater

Требования к программному обеспечению: Software Requirements:

  • Для просмотра отчетов WSUS требуется пакет Microsoft Report Viewer Redistributable 2008. For viewing reports, WSUS requires the Microsoft Report Viewer Redistributable 2008. В Windows Server 2020 для WSUS требуется Среда выполнения Microsoft Report Viewer 2012 On Windows Server 2020, WSUS requires Microsoft Report Viewer Runtime 2012

Если вы устанавливаете роли или обновления программного обеспечения, которые требуют перезагрузки сервера по окончании установки, то перезагрузите сервер перед тем, как активировать роль сервера службы WSUS. If you install roles or software updates that require you to restart the server when installation is complete, restart the server before you enable the WSUS server role.

На сервере, где будет установлена роль сервера службы WSUS, должна быть установлена платформа Microsoft .NET Framework 4.0. Microsoft .NET Framework 4.0 must be installed on the server where the WSUS server role will be installed.

Чтобы оснастка администрирования WSUS отображалась корректно, учетная запись NT Authority\Network Service должна иметь разрешения на полный доступ к следующим папкам: The NT Authority\Network Service account must have Full Control permissions for the following folders so that the WSUS Administration snap-in displays correctly:

%windir%\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files %windir%\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Данный путь может и не существовать до установки роли веб-сервера, которая содержит службы IIS. This path might not exist prior to install Web Server Role that contains Internet Information Services (IIS).

Подтвердите, что учетная запись, которую вы планируете использовать для установки службы WSUS, входит в группу локальных администраторов. Confirm that the account you plan to use to install WSUS is a member of the Local Administrators group.

Рекомендации по установке Installation Considerations

В ходе установки служба WSUS будет устанавливать по умолчанию следующие компоненты. During the installation process, WSUS will install the following by default:

Командлеты .NET API и Windows PowerShell .NET API and Windows PowerShell cmdlets

Внутреннюю базу данных Windows (WID), которую использует служба WSUS Windows Internal Database (WID), which is used by WSUS

Службы, используемые WSUS Services used by WSUS, which are:

Служба обновления Update Service

Веб-служба отчетов Reporting Web Service

Веб-служба клиентов Client Web Service

Веб-служба простой веб-проверки подлинности Simple Web Authentication Web Service

Служба синхронизации сервера Server Synchronization Service

Веб-служба проверки подлинности DSS DSS Authentication Web Service

Рекомендации в отношении компонентов по требованию Features on Demand Considerations

Помните, что настройка клиентских компьютеров (включая серверы) для обновления с помощью служб WSUS приведет к следующим ограничениям. Be aware that configuring client computers (including servers) to update by using WSUS will result in the following limitations:

Роли сервера, для которых полезная нагрузка была удалена с помощью установки «Компоненты по требованию», нельзя установить по запросу из Центра обновления Майкрософт. Server roles that have had their payloads removed using Features on Demand cannot be installed on demand from Microsoft Update. Необходимо указать источник установки во время попытки установить такие роли сервера или настроить источник для компонентов по запросу в групповая политика. You must either provide an installation source at the time you try to install such server roles, or configure a source for Features on Demand in Group Policy.

Клиентские выпуски Windows не смогут установить .NET 3.5 по запросу из Интернета. Windows client editions will not be able to install .NET 3.5 on demand from the web. К .NET 3.5 применяются те же рекомендации, что и к ролям сервера. The same considerations as server roles apply to .NET 3.5.

Настройка компонентов в источнике установки по требованию не включает службы WSUS. Configuring a Features on Demand installation source does not involve WSUS. Сведения о настройке компонентов см. в разделе Настройка компонентов по требованию в Windows Server. For information on how to configure Features, see Configure Features on Demand in Windows Server.

Корпоративные устройства под управлением Windows 10 версии 1709 или 1803 не могут устанавливать какие бы то ни было функции по запросу непосредственно из служб WSUS. Enterprise devices running Windows 10, version 1709 or version 1803, cannot install any Features on Demand directly from WSUS. Чтобы установить компоненты по требованию, Создайте файл компонента (Параллельное хранилище) или получите пакет компонента по запросу из одного из следующих источников: To install Features on Demand, create a feature file (side-by-side store) or obtain the Feature on Demand package from one of the following sources:

Служба корпоративного лицензирования Service Center (VLSC) — требуется доступ к корпоративной программе Volume Licensing Service Center (VLSC) — VL access is required

OEM Portal — требуется доступ к изготовителям оборудования OEM Portal — OEM access is required

Загрузка MSDN — требуется подписка MSDN MSDN Download — MSDN subscription is required

С помощью параметров командной строки DISMможно установить отдельный компонент для пакетов по запросу. Individually-obtained Feature on Demand packages can be installed using DISM command-line options.

Требования к базе данных службы WSUS WSUS database requirements

Для службы WSUS требуется одна из перечисленных ниже баз данных. WSUS requires one of the following databases:

Внутренняя база данных Windows (WID) Windows Internal Database (WID)

Microsoft SQL Server 2020 Microsoft SQL Server 2020

Microsoft SQL Server 2020 Microsoft SQL Server 2020

Microsoft SQL Server 2014 Microsoft SQL Server 2014

Microsoft SQL Server 2012 Microsoft SQL Server 2012


Microsoft SQL Server 2008 R2 Microsoft SQL Server 2008 R2

Следующие выпуски SQL Server поддерживаются службами WSUS: The following editions of SQL Server are supported by WSUS:

Функции корпоративного уровня Enterprise

Размер базы данных SQL Server Express 2008 R2 ограничен десятью гигабайтами. SQL Server Express 2008 R2 has a database size limitation of 10 GB. Базы данных такого размера будет достаточно для служб WSUS, хотя значительного выигрыша при использовании этой базы вместо внутренней базы данных Windows нет. This database size is likely to be sufficient for WSUS, although there is no appreciable benefit to using this database instead of WID. Для базы данных WID требуется минимальный объем ОЗУ в 2 ГБ, превышающий стандартные требования к системе Windows Server. WID database has a minimum RAM memory requirement of 2 GB beyond the standard Windows Server system requirements.

Вы можете установить роль службы WSUS на компьютере, отдельном от компьютера-сервера базы данных. You can install the WSUS role on a computer that is separate from the database server computer. В данном случае вступают в силу следующие дополнительные критерии. In this case, the following additional criteria apply:

Сервер баз данных нельзя настроить так, чтобы он выполнял роль контроллера домена. The database server cannot be configured as a domain controller.

Сервер службы WSUS не может запускать службы удаленных рабочих столов. The WSUS server cannot run Remote Desktop Services.

Сервер базы данных должен находиться в том же домене Active Directory, что и сервер WSUS, или иметь доверительные отношения с доменом Active Directory сервера WSUS. The database server must be in the same active directory domain as the WSUS server, or it must have a trust relationship with the active directory domain of the WSUS server.

Сервер WSUS и сервер базы данных должны быть в одном часовом поясе или синхронизированы с источником времени по Гринвичу (UTC). The WSUS server and the database server must be in the same time zone or be synchronized to the same Coordinated Universal time (Greenwich Mean time) source.

1.2. 1.2. Выбор сценария развертывания службы WSUS Choose a WSUS deployment scenario

Данный раздел описывает основные функции всех развертываний службы WSUS. This section describes the basic features of all WSUS deployments. Используйте данный раздел для ознакомления с простым процессом развертывания на примере одиночного сервера службы WSUS. Дополнительно описываются более сложные сценарии, такие как иерархия сервера WSUS или сервер WSUS в изолированном сегменте сети. Use this section to familiarize yourself with a simple deployment with a single WSUS server, in addition to more complex scenarios, such as a WSUS server hierarchy or a WSUS server on an isolated network segment.

Простое развертывание службы WSUS Simple WSUS deployment

Наиболее базовое развертывание WSUS состоит из сервера в корпоративном брандмауэре, который обслуживает клиентские компьютеры в частной интрасети. The most basic WSUS deployment consists of a server inside the corporate firewall that serves client computers on a private intranet. Для загрузки обновлений сервер WSUS подключается к центру обновления Майкрософт. The WSUS server connects to Microsoft Update to download updates. Это называется синхронизация. This is known as synchronization. В ходе синхронизации служба WSUS определяет, появились ли доступные свежие обновления с момента последней синхронизации. During synchronization, WSUS determines if any new updates have been made available since the last time you synchronized. Если это первая синхронизация WSUS, то все обновления становятся доступными для загрузки. If it is your first time synchronizing WSUS, all updates are made available for download.

Первичная синхронизация может занять более часа. Initial synchronization can take over an hour. Все последующие синхронизации должны происходить значительно быстрее. All synchronizations after that should be significantly quicker.

Для получения обновлений от Майкрософт сервер WSUS по умолчанию использует порт 80 для протокола HTTP и порт 443 для протокола HTTPS. By default, the WSUS server uses port 80 for HTTP protocol and port 443 for HTTPS protocol to obtain updates from Microsoft. Если выход из вашей сети в Интернет защищен корпоративным брандмауэром, то необходимо будет открыть порты на сервере, который непосредственно подключается к центру обновления Майкрософт. If there is a corporate firewall between your network and the Internet, you will have to open these ports on the server that communicates directly to Microsoft Update. Если вы планируете использовать для этого взаимодействия пользовательские порты, то необходимо открыть эти порты. If you are planning to use custom ports for this communication, you must open those ports instead. Вы можете настроить несколько серверов WSUS так, чтобы они синхронизировались с родительским WSUS-сервером. You can configure multiple WSUS servers to synchronize with a parent WSUS server. Для передачи обновлений на клиентские рабочие станции сервер WSUS по умолчанию использует порт 8530 для протокола HTTP и порт 8531 для протокола HTTPS. By default, the WSUS server uses port 8530 for HTTP protocol and port 8531 for HTTPS protocol to provide updates to client workstations.

Несколько серверов WSUS Multiple WSUS servers

Администраторы могут развернуть несколько серверов с WSUS, которые синхронизируют все содержимое в интрасети своей организации. Administrators can deploy multiple servers running WSUS that synchronize all content within their organization’s intranet. В Интернет может быть предоставлен только один сервер, который будет единственным сервером, который скачивает обновления из Центр обновления Майкрософт. You might expose only one server to the Internet, which would be the only server that downloads updates from Microsoft Update. Этот сервер настроен в качестве вышестоящего сервера источника, на который синхронизируются подчиненные серверы. This server is set up as the upstream server the source to which the downstream servers synchronize. Там, где это возможно, серверы могут располагаться на всем протяжении территориально разнесенной сети, чтобы обеспечивать наилучшее качество подключения для всех клиентских компьютеров. When applicable, servers can be located throughout a geographically dispersed network to provide the best connectivity to all client computers.

Отключенный WSUS-сервер Disconnected WSUS server

Если политика организации или другие условия ограничивают доступ компьютера в Интернет, администраторы могут настроить внутренний сервер, чтобы он запускал WSUS. If corporate policy or other conditions limit computer access to the Internet, administrators can set up an internal server to run WSUS. Примером этого может служить сервер, подключенный к Интрасети, но изолированный от Интернета. An example of this is a server that is connected to the intranet but is isolated from the Internet. После загрузки, тестирования и одобрения обновления на этом сервере администратор экспортирует метаданные и содержимое обновления на DVD-диск. After downloading, testing, and approving the updates on this server, an administrator would export the update metadata and content to a DVD. Метаданные и содержимое обновления импортируются с DVD-диска на серверы, работающие с WSUS в Интрасети. The update metadata and content is imported from the DVD to servers running WSUS within the intranet.

Иерархии серверов WSUS WSUS server hierarchies

Вы можете создавать сложные иерархии серверов WSUS. You can create complex hierarchies of WSUS servers. Вам необходимо иметь только один сервер WSUS, подключенный к Центру обновления Майкрософт, поскольку остальные серверы WSUS могут синхронизироваться между собой, а не с Центром обновления Майкрософт. Because you can synchronize one WSUS server with another WSUS server instead of with Microsoft Update, you need to have only a single WSUS server that is connected to Microsoft Update. При подключении серверов WSUS между собой один из них является вышестоящим, а другой — подчиненным. When you link WSUS servers together, there is an upstream WSUS server and a downstream WSUS server. Развертывание иерархии сервера WSUS имеет следующие преимущества. A WSUS server hierarchy deployment offers the following benefits:

Вы можете загрузить обновления из Интернета один раз, а затем распространить их на клиентские компьютеры посредством подчиненных серверов. You can download updates one time from the Internet and then distribute the updates to client computers by using downstream servers. Данный метод сохраняет пропускную способность интернет-подключения в организации. This method saves bandwidth on the corporate Internet connection.

Обновления можно загружать на те серверы WSUS, которые физически находятся ближе к клиентским компьютерам, например в филиалах. You can download updates to a WSUS server that is physically closer to the client computers, for example, in branch offices.

Можно настроить отдельные серверы WSUS для обслуживания клиентских компьютеров, использующих продукты корпорации Майкрософт на различных языках. You can set up separate WSUS servers to serve client computers that use different languages of Microsoft products.

Можно развернуть WSUS в масштабе крупной организации, в которой клиентских компьютеров больше, чем то количество, которым может эффективно управлять один сервер WSUS. You can scale WSUS for a large organization that has more client computers than one WSUS server can effectively manage.

Не рекомендуется создавать иерархию серверов WSUS глубиной более трех уровней. We recommend that you do not create a WSUS server hierarchy that is more than three levels deep. Каждый уровень увеличивает время распространения обновлений через подключенные серверы. Each level adds time to propagate updates throughout the connected servers. Хотя теоретически ограничения на иерархию отсутствуют, корпорация Майкрософт проверила только те развертывания, которые имеют иерархию из пяти уровней. Although there is no theoretical limit to a hierarchy, only deployments that have a hierarchy of five levels deep have been tested by Microsoft.

Кроме того, подчиненные серверы должны иметь ту же или более раннюю версию WSUS, что и вышестоящий источник синхронизации сервера. Also, downstream servers must be at the same version or an earlier version of WSUS as the upstream server synchronization source.

Можно подключить серверы WSUS в автономном режиме (чтобы достичь распределенного администрирования) или в режиме репликации (чтобы достичь централизованного администрирования). You can connect WSUS servers in Autonomous mode (to achieve distributed administration) or in Replica mode (to achieve centralized administration). Необязательно разворачивать серверную иерархию, которая использует только один режим: можно развернуть решения WSUS, которые используют как автономные серверы, так и серверы-реплики WSUS. You do not have to deploy a server hierarchy that uses only one mode: you can deploy a WSUS solution that uses both autonomous and replica WSUS servers.

Автономный режим Autonomous mode

Автономный режим, также называемый распределенным администрированием, является параметром установки по умолчанию для WSUS. The Autonomous mode, also called distributed administration, is the default installation option for WSUS. В автономном режиме вышестоящий сервер WSUS делит обновления с подчиненными серверами при синхронизации. In Autonomous mode, an upstream WSUS server shares updates with downstream servers during synchronization. Администрирование подчиненных серверов WSUS происходит по-отдельности, и они не получают статуса утверждения обновлений или сведений о группах компьютеров от вышестоящего сервера. Downstream WSUS servers are administered separately, and they do not receive update approval status or computer group information from the upstream server. С помощью модели распределенного управления администратор каждого сервера WSUS выбирает языки обновления, создает группы компьютеров, назначает компьютеры группам, тестирует и утверждает обновления, а также убеждается, что на соответствующие группы компьютеров установлены нужные обновления. By using the distributed management model, each WSUS server administrator selects update languages, creates computer groups, assigns computers to groups, tests and approves updates, and makes sure that the correct updates are installed to the appropriate computer groups. Следующий рисунок показывает, как можно развернуть автономные серверы WSUS в среде филиала: The following image shows how you might deploy autonomous WSUS servers in a branch office environment:

Режим реплики Replica mode

Режим реплики, называемый также централизованным администрированием, предполагает, что вышестоящий сервер WSUS разделяет обновления, статус утверждения и группы компьютеров с подчиненными серверами. The Replica mode, also called centralized administration, works by having an upstream WSUS server that shares updates, approval status, and computer groups with downstream servers. Серверы-реплики наследуют утверждения обновлений, и ими нельзя управлять независимо с соответствующего вышестоящего сервера WSUS. Replica servers inherit update approvals and are not administered separately from the upstream WSUS server. Следующий рисунок показывает, как можно развернуть серверы-реплики WSUS в среде филиала: The following image shows how you might deploy replica WSUS servers in a branch office environment.

Если вы настроили несколько серверов-реплик на подключение к одному вышестоящему серверу WSUS, то не назначайте запуск синхронизации на каждом из серверов-реплик в одно и то же время. If you set up several replica servers to connect to a single upstream WSUS server, do not schedule synchronization to run at the same time on each replica server. Данная методика позволит избежать внезапных колебаний пропускной способности. This practice will avoid sudden surges in bandwidth usage.

Филиалы Branch offices

Для оптимизации развертывания службы WSUS можно использовать функцию «Филиал» в Windows. You can leverage the Branch Office feature in Windows to optimize WSUS deployment. Данный тип развертывания предлагает следующие преимущества. This type of deployment offers the following advantages:

помогает сократить использование каналов WAN и повысить скорость реагирования приложений. helps reduce WAN link utilization and improves application responsiveness. Чтобы активировать ускорение передачи содержимого BranchCache от сервера WSUS, установите компонент BranchCache на сервере и клиентах и убедитесь, что служба BranchCache запустилась. To enable BranchCache acceleration of content that is served by the WSUS server, install the BranchCache feature on the server and the clients, and ensure that the BranchCache service has started. Другие действия не требуются. No other steps are necessary.

Функцию «Филиал» можно также использовать в филиалах, которые имеют подключение к центральному офису через канал с низкой пропускной способностью, а подключение к Интернету через канал с высокой пропускной способностью. In branch offices that have low-bandwidth connections to the central office but high-bandwidth connections to the Internet, the Branch Office feature can also be used. В таком случае можно настроить подчиненные серверы WSUS так, чтобы они принимали информацию об обновлениях, которые надо установить, от центрального сервера WSUS, но загружали эти обновления из Центра обновления Майкрософт. In this case you may want to configure downstream WSUS servers to get information about which updates to install from the central WSUS server, but download the updates from Microsoft Update.

Балансировка сетевой нагрузки Network Load Balancing

Балансировка сетевой нагрузки (NLB) повышает надежность и производительность вашей сети на WSUS. Network Load Balancing (NLB) increases the reliability and performance of your WSUS network. Можно настроить несколько серверов WSUS, совместно использующих один отказоустойчивый кластер, SQL Server например SQL Server 2008 R2 с пакетом обновления 1 (SP1). You can set up multiple WSUS servers that share a single failover cluster running SQL Server such as SQL Server 2008 R2 SP1. При такой конфигурации необходимо использовать полную установку SQL Server , а не установку внутренней базы данных Windows, которая поставляется WSUS, при этом роль базы данных должна быть установлена на всех серверах WSUS переднего плана. In this configuration you must use a full SQL Server installation, not the Windows Internal Database installation that is provided by WSUS, and the database role must be installed on all WSUS front-end servers. Можно также сделать так, чтобы все серверы WSUS использовали распределенную файловую систему (DFS), чтобы хранить свое содержимое. You can also have all the WSUS servers use a distributed file system (DFS) to store their content.

Установка WSUS для балансировки сетевой нагрузки: по сравнению с программой установки WSUS 3,2 для балансировки сетевой нагрузки, Специальный вызов установки и параметры больше не нужны для настройки служб WSUS для балансировки сетевой нагрузки. WSUS setup for NLB: compared to WSUS 3.2 setup for NLB, a special setup call and parameters are no longer required to configure WSUS for NLB. Необходимо настроить только каждый сервер WSUS, учитывая следующие моменты. You need only setup each WSUS server, keeping the following considerations in mind.

Службы WSUS необходимо настроить, используя базу данных SQL вместо WID. WSUS must be setup using the SQL database option instead of WID.

Если обновления хранятся локально, к папке содержимого необходимо предоставить общий доступ для серверов WSUS, которые совместно используют одну базу данных SQL. If storing updates locally, the same Content folder must be shared between the WSUS servers that are sharing the same SQL database.

Установка служб WSUS должна выполняться последовательно. WSUS setup must be done in serial. Задачи после установки нельзя выполнять на нескольких серверах одновременно при использовании совместного доступа к одной базе данных SQL. Postinstall tasks cannot be run on more than one server at the same time when sharing the same SQL database.

Развертывание службы WSUS с роумингом клиентских компьютеров WSUS deployment with roaming client computers

Если в сети есть мобильные пользователи, которые выполняют вход в сеть из различных мест, можно настроить службы WSUS так, чтобы позволить пользователям в роуминге осуществлять обновление на своих клиентских компьютерах с ближайшего к ним географически сервера WSUS. If the network includes mobile users who log on to the network from different locations, you can configure WSUS to let roaming users update their client computers from the WSUS server that is closest to them geographically. Например, вы можете развернуть один сервер WSUS в каждом регионе и использовать разные подсети DNS для каждого региона. For example, you might deploy one WSUS server each region and use a different DNS subnet for each region. Все клиентские компьютеры могут быть направлены на один и тот же сервер WSUS, который разрешается в каждой подсети на ближайший физический сервер WSUS. All client computers could be directed to the same WSUS server, which resolves in each subnet to the nearest physical WSUS server.


1.3. 1.3. Выбор стратегии хранения данных для службы WSUS Choose a WSUS storage strategy

Службы Windows Server Update Services (WSUS) используют два типа систем хранения: базу данных для хранения настроек WSUS и метаданных обновлений, а также дополнительную локальную файловую систему, чтобы хранить файлы обновлений. Windows Server Update Services (WSUS) uses two types of storage systems: a database to store WSUS configuration and update metadata, and an optional local file system to store update files. Перед установкой WSUS необходимо решить, каким образом будет реализовано хранение данных. Before you install WSUS, you should decide how you want to implement storage.

Обновления состоят из двух частей: метаданные, которые описывают обновление, и файлы, которые необходимы для установки обновления. Updates are composed of two parts: metadata that describes the update, and the files that are required to install the update. Размер метаданных обновлений обычно намного меньше, чем размер самого обновления, а хранятся они в базе данных WSUS. Update metadata is typically much smaller than the actual update, and it is stored in the WSUS database. Файлы обновлений хранятся на локальном сервере WSUS или на веб-сервере Центра обновления Майкрософт. Update files are stored on a local WSUS server or on a Microsoft Update Web server.

База данных службы WSUS WSUS database

Для служб WSUS необходимо иметь по базе данных на каждом сервере WSUS. WSUS requires a database for each WSUS server. WSUS может поддерживать использование базы данных, которая находится не на сервере WSUS, а на другом компьютере, но при этом есть некоторые ограничения. WSUS supports the use of a database that resides on a different computer than the WSUS server, with some restrictions. Список поддерживаемых баз данных и ограничений удаленной базы данных см. в разделе «1,1 обзор первоначальных соображений и системных требований» этого руководством. For a list of supported databases and remote database limitations, see section «1.1 Review initial considerations and system requirements,» in this guide.

База данных WSUS хранит следующую информацию. The WSUS database stores the following information:

Сведения о конфигурации сервера WSUS WSUS server configuration information

Метаданные, описывающие обновление Metadata that describes each update

Сведения о клиентских компьютерах, обновлениях и взаимодействиях Information about client computers, updates, and interactions

При установке нескольких серверов WSUS необходимо поддерживать отдельные базы данных для каждого сервера WSUS, независимо от того, является ли этот сервер автономным или сервером-репликой. If you install multiple WSUS servers, you must maintain a separate database for each WSUS server, whether it is an autonomous or a replica server. Нельзя хранить несколько баз данных WSUS на одном экземпляре SQL Server за исключением хранения в кластерах балансировки сетевой нагрузки (NLB), которые используют отказоустойчивость SQL Server. You cannot store multiple WSUS databases on a single instance of SQL Server, except in Network Load Balancing (NLB) clusters that use SQL Server failover.

SQL Server, SQL Server Express и внутренняя база данных Windows обеспечивают одинаковые характеристики производительности для конфигурации, в которой используется один сервер, а база данных и служба WSUS расположены на одном компьютере. SQL Server, SQL Server Express, and Windows Internal Database provide the same performance characteristics for a single-server configuration, where the database and the WSUS service are located on the same computer. Конфигурация с одним сервером может поддерживать несколько тысяч клиентских компьютеров WSUS. A single-server configuration can support several thousand WSUS client computers.

Не пытайтесь управлять службами WSUS через прямой доступ к базе данных. Do not attempt to manage WSUS by accessing the database directly. непосредственное управление базой данных может привести к повреждению базы данных. directly manipulating the database can cause database corruption. Такое повреждение может незаметно сразу, но помешает обновлению продукта до следующей версии. The corruption might not be immediately obvious, but it can prevent upgrades to the next version of the product. Управление WSUS можно осуществлять через консоль WSUS или программный интерфейс WSUS. You can manage WSUS by using the WSUS console or WSUS application programming interfaces (APIs).

WSUS с внутренней базой данных Windows WSUS with Windows Internal Database

По умолчанию мастер установки создает и использует внутреннюю базу данных Windows, которая называется SUSDB.mdf. By default, the installation wizard creates and uses a Windows Internal Database that is named SUSDB.mdf. Эта база данных находится в папке %windir%\wid\data\ , где %windir% — локальный диск, на котором установлено серверное программное обеспечение WSUS. This database is located in the %windir%\wid\data\ folder, where %windir% is the local drive on which the WSUS server software is installed.

Внутренняя база данных Windows (WID) появилась в Windows Server 2008. Windows Internal Database (WID) was introduced in Windows Server 2008 .

WSUS поддерживает проверку подлинности Windows только для базы данных. WSUS supports Windows authentication only for the database. Нельзя использовать проверку подлинности SQL Server совместно с WSUS. You cannot use SQL Server authentication with WSUS. Если для базы данных WSUS используется внутренняя база данных Windows, то программа установки WSUS создает экземпляр SQL Server с названием server\Microsoft##WID, где server — это имя компьютера. If you use Windows Internal Database for the WSUS database, WSUS Setup creates an instance of SQL Server that is named server\Microsoft##WID, where server is the name of the computer. С каждым параметром базы данных программа установки WSUS создает базу данных с названием SUSDB. With either database option, WSUS Setup creates a database named SUSDB. Название этой базы данных нельзя перенастраивать. The name of this database is not configurable.

Внутреннюю базу данных Windows рекомендуется использовать в следующих случаях. We recommend that you use Windows Internal Database in the following cases:

Организация еще не приобрела или ей не требуется продукт SQL Server для других приложений. The organization has not already purchased and does not require a SQL Server product for any other application.

Организации не требуется решение NLB WSUS. The organization does not require an NLB WSUS solution.

Предполагается развернуть несколько серверов WSUS (например, в филиалах). You intend to deploy multiple WSUS servers (for example, in branch offices). В данном случае необходимо рассмотреть вопрос об использовании внутренней базы данных Windows на серверах-получателях, даже если на корневом сервере WSUS будет использоваться SQL Server. In this case, you should consider using Windows Internal Database on the secondary servers, even if you will use SQL Server for the root WSUS server. Поскольку каждый сервер WSUS требует отдельного экземпляра SQL Server, вы быстро испытаете проблемы с производительностью базы данных, если только один экземпляр SQL Server будет работать с несколькими серверами WSUS. Because each WSUS server requires a separate instance of SQL Server, you will quickly experience database performance issues if only one instance of SQL Server handles multiple WSUS servers.

Внутренняя база данных Windows не предоставляет пользовательский интерфейс или какие-либо инструменты управления базой данных. Windows Internal Database does not provide a user interface or any database management tools. Если эта база данных будет выбрана для WSUS, то возникнет необходимость использования внешних инструментов управления базой данных. If you select this database for WSUS, you must use external tools to manage the database. Дополнительные сведения см. в следующих разделах: For more information, see:

Использование WSUS с SQL Server WSUS with SQL Server

Использование SQL Server совместно с WSUS рекомендуется в следующих случаях. We recommend that you use SQL Server with WSUS in the following cases:

Вам необходимо решение NLB WSUS. You require an NLB WSUS solution.

У вас уже установлен по крайней мере один экземпляр SQL Server. You already have at least one instance of SQL Server installed.

Вы не можете запускать службу SQL Server из-под локальной учетной записи, которая не является системной, или с использованием проверки подлинности SQL Server. You cannot run the SQL Server service under a local non-system account or by using SQL Server authentication. Служба WSUS поддерживает только проверку подлинности Windows. WSUS supports Windows authentication only.

Хранение обновлений WSUS WSUS update storage

Когда обновления синхронизируются на сервере WSUS, файлы метаданных и файлы обновлений хранятся в двух разных расположениях. When updates are synchronized to your WSUS server, the metadata and update files are stored in two separate locations. Метаданные хранятся в базе данных WSUS. Metadata is stored in the WSUS database. Файлы обновлений могут храниться на сервере WSUS или на серверах Центра обновления Майкрософт (в зависимости настройки параметров синхронизации). Update files can be stored on your WSUS server or on Microsoft Update servers, depending on how you have configured your synchronization options. Если вы решили хранить файлы обновлений на сервере WSUS, клиентские компьютеры будут загружать утвержденные обновления с локального сервера WSUS. If you choose to store update files on your WSUS server, client computers will download approved updates from the local WSUS server. В противном случае клиентские компьютеры будут загружать утвержденные обновления напрямую из Центра обновления Майкрософт. If not, client computers will download approved updates directly from Microsoft Update. Наиболее оптимальный выбор для вашей организации будет зависеть от пропускной способности подключения к Интернету, пропускной способности интрасети, а также доступности локального хранилища. The option that makes the most sense for your organization will depend on network bandwidth to the Internet, network bandwidth on the intranet, and local storage availability.

Для каждого развернутого сервера WSUS можно выбрать различные решения для хранения обновлений. You can select a different update storage solution for each WSUS server that you deploy.

Хранение данных на локальном сервере WSUS Local WSUS server storage

Задание локального хранения файлов обновлений происходит по умолчанию при установке и настройке службы WSUS. Local storage of update files is the default option when you install and configure WSUS. Данный параметр позволяет экономить пропускную способность в корпоративном подключении к Интернету, поскольку клиентские компьютеры загружают обновления непосредственно с локального сервера WSUS. This option can save bandwidth on the corporate connection to the Internet because client computers download updates directly from the local WSUS server.

Данный параметр требует, чтобы на сервере было достаточно дискового пространства для хранения всех необходимых обновлений. This option requires that the server have sufficient disk space to store all needed updates. как минимум, WSUS требует 20 ГБ для локального хранения обновлений; Однако мы рекомендуем использовать 30 ГБ на основе протестированных переменных. at a minimum, WSUS requires 20 GB to store updates locally; however, we recommend 30 GB based on tested variables.

Удаленное хранение данных на серверах Центра обновления Майкрософт Remote storage on Microsoft Update servers

Можно хранить обновления удаленно на серверах Центра обновления Майкрософт. You can store updates remotely on Microsoft Update servers. Данная возможность полезна, поскольку большинство клиентских компьютеров подключаются к серверу WSUS через медленное WAN-подключение, а к Интернету они подключаются по каналам с высокой пропускной способностью. This option is useful if most client computers connect to the WSUS server over a slow WAN connection, but they connect to the Internet over a high-bandwidth connection.

В данном случае корневой сервер WSUS синхронизируется с Центром обновления Майкрософт и получает метаданные обновлений. In this case, the root WSUS server synchronizes with Microsoft Update and receives the update metadata. После утверждения обновлений клиентские компьютеры загружают утвержденные обновления с серверов Центра обновления Майкрософт. After you approve the updates, the client computers download the approved updates from Microsoft Update servers.

1.4. 1.4. Выбор языков обновления для службы WSUS Choose WSUS update languages

При развертывании иерархии сервера WSUS следует определить, на каком языке необходимы обновления в организации. When you deploy a WSUS server hierarchy, you should determine which language updates are required throughout the organization. Необходимо настроить корневой сервер WSUS на загрузку обновлений на всех языках, которые используются в организации. You should configure the root WSUS server to download updates in all languages that are used throughout the entire organization.

Например, главному офису необходимы обновления на английском и французском языках, в одном филиале необходимы обновления на английском, французском и немецком языках, а в другом — на английском и испанском. For example, the main office might require English and French language updates, but one branch office requires English, French, and German language updates, and another branch office requires English and Spanish language updates. В данной ситуации необходимо настроить корневой сервер WSUS на загрузку обновлений на английском, французском, немецком и испанском языках. In this situation, you would configure the root WSUS server to download updates in English, French, German, and Spanish. Затем надо настроить сервер WSUS первого филиала на загрузку обновлений только на английском, французском и немецком языках, а сервер второго филиала — на загрузку обновлений только на английском и испанском языках. You would then configure the first branch office WSUS server to download updates in English, French, and German only, and configure the second branch office to download updates in English and Spanish only.

Страница Выбор языков мастера настройки WSUS позволяет получать обновления на всех языках или на какой-то определенной подгруппе языков. The Choose Languages page of the WSUS Configuration Wizard allows you to get updates from all languages or from a subset of languages. Выбор подмножества языков экономит место на диске, но важно выбрать все языки, необходимые всем подчиненным серверам и клиентским компьютерам сервера WSUS. selecting a subset of languages saves disk space, but it is IMPORTANT to choose all the languages that are needed by all the downstream servers and client computers of a WSUS server.

Ниже приведены некоторые важные замечания о языке обновления, о которых следует помнить перед настройкой этого параметра. Following are some IMPORTANT notes about the update language that you should keep in mind before configure this option:

Всегда включайте английский язык в дополнение к другим языкам, используемым в вашей организации. Always include English in addition to any other languages that are required throughout your organization. Все обновления имеют в своей основе языковой пакет на английском языке. All updates are based on English language packs.

Подчиненные серверы и клиентские компьютеры не будут получать все необходимые обновления, если вы не выберете все необходимые языки для вышестоящего сервера. Downstream servers and client computers will not receive all the updates they need if you have not selected all the necessary languages for the upstream server. Убедитесь, что вы выбрали все языки, которые понадобятся на клиентских компьютерах, связанных со всеми подчиненными серверами. Make sure you select all the languages that will be needed by all the client computers that are associated with all the downstream servers.

Необходимо в основном загрузить обновления на всех языках на корневой сервер WSUS, который синхронизируется с Центром обновления Майкрософт. You should generally download updates in all languages on the root WSUS server that synchronizes to Microsoft Update. Данный выбор гарантирует, что все подчиненные серверы и клиентские компьютеры получат обновления на необходимых языках. This selection guarantees that all downstream servers and client computers will receive updates in the languages that they require.

Если вы храните обновления локально и настроили сервер WSUS на загрузку обновлений на ограниченном количестве языков, вы можете заметить, что есть обновления на языках, отличающихся от указанных вами. If you are storing updates locally, and you have set up a WSUS server to download updates in a limited number of languages, you may notice that there are updates in languages other than the ones you specified. Многие файлы обновлений объединяются в пакет из нескольких различных языков, которые имеют в своем составе один из языков, указанных на сервере. Many update files are bundles of several different languages, which include at least one of the languages specified on the server.

Вышестоящее серверы Upstream servers


Настройте вышестоящие серверы для синхронизации обновлений на всех языках, необходимых для подчиненных серверов-реплик. Configure upstream servers to synchronize updates in all languages that are required by downstream replica servers. Пользователи не будут получать уведомления о необходимых обновлениях на несинхронизированных языках. You will not be notified of needed updates in the unsynchronized languages.

Обновления будут отображаться как неприменимые на клиентских компьютерах, требующих данный язык. Updates will appear as Not Applicable on client computers that require the language. Чтобы избежать этого, убедитесь, что все языки операционных систем включены в параметры синхронизации сервера WSUS. To avoid this, make sure all operating system languages are included in your WSUS server’s synchronization options. Все языки операционной системы можно просмотреть, перейдя в представление Компьютеры консоли администрирования WSUS и сортируя компьютеры по языку операционной системы. You can see all the operating system languages by going to the computers view of the WSUS Administration Console and sorting the computers by operating system language. Однако может потребоваться включить больше языков, если на нескольких языках есть приложения Майкрософт (например, если на некоторых компьютерах установлена французская версия Microsoft Word, использующая английскую версию Windows 8). However, you may want to include more languages if there are Microsoft applications in more than one language (for example, if the French version of Microsoft Word is installed on some computers that use the English version of Windows 8.

Выбор языков для вышестоящего сервера отличается от выбора языков для подчиненного сервера. Choosing languages for an upstream server is not the same as choosing languages for a downstream server. Следующие процедуры поясняют различия. The following procedures explain the differences.

Выбор языков обновлений для сервера, синхронизированного с Центром обновления Майкрософт To choose update languages for a server synchronizing from Microsoft Update

В мастере настройки WSUS выполните следующие действия. In the WSUS Configuration Wizard:

Для получения обновлений на всех языках щелкните Загружать обновления на всех языках, включая новые. To get updates in all languages, click Download updates in all languages, including new languages.

Для получения обновлений только для определенных языков выберите Загружать обновления только для следующих языков, а затем выберите языки, для которых вы желаете получать обновления. To get updates only for specific languages, click Download updates only in these languages, and then select the languages for which you want updates.

Выбор языков обновлений для подчиненного сервера To choose update languages for a downstream server

  1. Если вышестоящий сервер настроен на загрузку файлов обновления в подмножестве языков: В мастере настройки служб WSUS нажмите кнопку загрузить обновления только на этих языках (на вышестоящем сервере поддерживаются только языки, отмеченные звездочкой) , а затем выберите языки, для которых требуется установить обновления. If the upstream server has been configured to download update files in a subset of languages: In the WSUS Configuration Wizard, click Download updates only in these languages (only languages marked with an asterisk are supported by the upstream server), and then select the languages for which you want updates.

Эту процедуру необходимо выполнить, даже если требуется загружать на подчиненном сервере те же языки, что и на вышестоящем сервере. You should do this even though you want the downstream server to download the same languages as the upstream server.

  1. Если вышестоящий сервер настроен на загрузку файлов обновления на всех языках: В мастере настройки служб WSUS нажмите кнопку загрузить обновления на всех языках, поддерживаемых вышестоящим сервером. If the upstream server has been configured to download update files in all languages: In the WSUS Configuration Wizard, click Download updates in all languages supported by the upstream server.

Эту процедуру необходимо выполнить, даже если требуется загружать на подчиненном сервере те же языки, что и на вышестоящем сервере. You should do this even though you want the downstream server to download the same languages as the upstream server. Этот параметр задает загрузку вышестоящим сервером обновлений на всех языках, включая языки, которые первоначально не были настроены для вышестоящего сервера. This setting causes the upstream server to download updates in all languages, including languages that were not originally configured for the upstream server. При добавлении языков для вышестоящего сервера следует скопировать новые обновления на его серверы-реплики. If you add languages to the upstream server, you should copy the new updates to its replica servers.

Изменение параметров языка только на вышестоящем сервере может привести к несоответствию числа обновлений, утвержденных на центральном сервере, и числа обновлений, утвержденных на серверах-репликах. Changing language options on the upstream server alone might cause a mismatch between the number of updates that are approved on the central server and the number of updates approved on the replica servers.

1.5. 1.5. Планирование групп компьютеров службы WSUS Plan WSUS computer groups

Служба WSUS позволяет направлять обновления на группы клиентских компьютеров, таким образом обеспечивается получение определенными компьютерами нужных обновлений в самое подходящее время. WSUS allows you to target updates to groups of client computers, so you can ensure that specific computers always get the right updates at the most convenient times. Например, если компьютеры в одном отделе (например, бухгалтерии) имеют особую конфигурацию, то можно настроить группу для данного отдела, определить, какие обновления нужны на их компьютерах и в какое время их нужно устанавливать, а затем использовать отчеты WSUS для оценки данных обновлений. For example, if all the computers in one department (such as the Accounting team) have a specific configuration, you can set up a group for that team, decide which updates their computers need and what time they should be installed, and then use WSUS reports to evaluate the updates for the team.

Если сервер WSUS работает в режиме реплики, группы компьютеров нельзя создать на сервере. If a WSUS server is running in replica mode, computer groups cannot be created on that server. Все группы компьютеров, которые необходимы для клиентских компьютеров сервера-реплики, должны быть созданы на корневом сервере WSUS иерархии серверов WSUS. All the computer groups that are needed for client computers of the replica server must be created on the WSUS server that is the root of the WSUS server hierarchy. Дополнительные сведения о режиме реплики см. в разделе Управление серверами реплик WSUS Управление серверами реплик WSUS в руководстве пользователя WSUS 3,0 с пакетом обновления 2 (SP2). For more information about replica mode, see Manage WSUS Replica Servers Manage WSUS Replica Servers in the WSUS 3.0 SP2 Operations Guide.

Компьютеры всегда назначаются группе » все компьютеры » и остаются назначенными группе » Неназначенные компьютеры «, пока они не будут назначены другой группе. Computers are always assigned to the All computers group, and they remain assigned to the Unassigned computers group until you assign them to another group. Компьютеры могут входить в несколько групп. Computers can belong to more than one group.

Можно создать иерархические группы компьютеров (например, создать группу «Зарплата» и группу «Расчеты с поставщиками» в группе «Бухгалтерия»). Computer groups can be set up in hierarchies (for example, the Payroll group and the Accounts Payable group below the Accounting group). Обновления, одобренные для высшей группы, будут автоматически развернуты помимо высшей группы и в низшей группе. Updates that are approved for a higher group will automatically be deployed to lower groups, in addition to the higher group. В данном примере после одобрения Обновление 1 для группы «Бухгалтерия» будет развернуто на всех компьютерах этой группы, всех компьютерах группы «Зарплата», а также на всех компьютерах группы «Расчеты с поставщиками». In this example, if you approve Update1 for the Accounting group, the update will be deployed to all the computers in the Accounting group, all the computers in the Payroll group, and all the computers in the Accounts Payable group.

Поскольку компьютеры могут состоять в нескольких группах, то возможна ситуация, когда одно обновление будет одобрено несколько раз на одном и том же компьютере. Because computers can be assigned to multiple groups, it is possible for a single update to be approved more than once for the same computer. Тем не менее само обновление будет развернуто только один раз, а любые конфликты будут разрешены сервером WSUS. However, the update will be deployed only once, and any conflicts will be resolved by the WSUS server. Чтобы продолжить работу с предыдущим примером, если компьютер a назначен группе зарплаты и группе расчетов с поставщиками, а update1 утвержден для обеих групп, он будет развернут только один раз. To continue with the previous example, if computerA is assigned to the Payroll group and the Accounts Payable group, and Update1 is approved for both groups, it will be deployed only once.

Для добавления компьютеров в группы можно использовать один из двух методов: указание на стороне сервера и указание на стороне клиентов. You can assign computers to computer groups by using one of two methods, server-side targeting or client-side targeting. Далее следуют определения для каждого из методов. Following are the definitions for each method:

Целевая настройка на стороне сервера: Один или несколько клиентских компьютеров вручную назначаются нескольким группам одновременно. Server-side targeting: You manually assign one or more client computers to multiple groups simultaneously.

Нацеливание на стороне клиента: Вы используете групповая политика или редактируете параметры реестра на клиентских компьютерах, чтобы разрешить этим компьютерам автоматически добавлять себя в ранее созданные группы компьютеров. Client-side targeting: You use Group Policy or edit the registry settings on client computers to enable those computers to automatically add themselves into the previously created computer groups.

Устранение конфликтов Conflict Resolution

Сервер применяет следующие правила для устранения конфликтов и определения результирующего действия на клиентах: The server applies the following rules to resolve conflicts and determine the resultant action on clients:

Предельный срок Deadline

Priority Priority

Действия, связанные с группой наивысшего приоритета, переопределяют действия других групп. The actions associated with the group of the highest priority override the actions of other groups. Чем глубже группа расположена в иерархии групп, тем выше ее приоритет. The deeper a group appears within the hierarchy of groups, the higher its priority. Приоритет назначается только на основании глубины. Все ветви обладают одинаковым приоритетом. Priority is assigned only based on depth; all branches have equal priority. Например, группа двумя уровнями ниже ветви «Настольные компьютеры» обладает более высоким приоритетом, чем группа, располагающаяся на один уровень ниже ветви «Сервер». For example, a group two levels beneath the Desktops branch has a higher priority than a group one level beneath the Server branch.

В следующем текстовом примере панели Иерархия консоли обновления для сервера WSUS с именем WSUS-01 группы компьютеров с именем настольные компьютеры и сервер были добавлены в группу все компьютеры по умолчанию. In the following text example of the Update Services console hierarchy pane, for a WSUS server named WSUS-01, computer groups named Desktop computers and Server have been added to the default All computers group. Настольные компьютеры и группы серверов находятся на одном иерархическом уровне. Both the Desktop computers and Server groups are at the same hierarchical level.

Службы обновления Update Services

WSUS – 01 WSUS-01

Обновляем Updates

компьютером computers

Все компьютеры All computers

Неназначенные компьютеры Unassigned computers

Настольные компьютеры Desktop computers

Настольные компьютеры — L1 Desktops-L1

  • Настольные компьютеры — L2Desktops-L2

Серверы Servers

  • Серверы — L1Servers-L1


Подчиненные серверы Downstream Servers

Синхронизации Synchronizations

Отчеты Reports

Параметры Options

В этом примере группа на двух уровнях под настольными компьютерами (настольные компьютеры L2) имеет более высокий приоритет, чем группа на один уровень ниже ветви сервера (Servers L1). In this example, the group two levels beneath the Desktop computers branch (Desktops L2) has a higher priority than the group one level beneath the Server branch (Servers L1). Соответственно, для компьютера, являющегося членом сразу двух групп, «Настольные компьютеры-У2» и «Серверы-У1», все действия для группы «Настольные компьютеры-У2» обладают более высоким приоритетом по сравнению с действиями, определенными для группы «Серверы-У1». Accordingly, for a computer that has membership in both the Desktops-L2 and the Servers-L1 groups, all actions for the Desktops-L2 group take priority over actions specified for the Servers-L1 group.

Приоритет установки и удаления Priority of Install and Uninstall

Действия «Установить» переопределяют действия «Удалить». Install actions override uninstall actions. Обязательные установки переопределяют необязательные (последние доступны только через API; при изменении утверждения обновления через консоль администрирования WSUS все необязательные утверждения будут удалены.) Required installs override optional installs (optional installs are only available through the API and changing an approval for an update using the WSUS Administration Console will clear all optional approval.)

Приоритет крайних сроков Priority of Deadlines

Действия, для которых установлен предельный срок, переопределяют действия без предельного срока. Actions that have a deadline override those with no deadline. Действия с более ранним предельным сроком переопределяют действия с более поздним предельным сроком. Actions with earlier deadlines override those with later deadlines.

1.6. 1.6. Рекомендации по планированию производительности службы WSUS Plan WSUS performance considerations

Прежде чем развертывать службы WSUS, можно тщательно спланировать их, чтобы обеспечить оптимальную производительность. There are some areas that you should carefully plan before deploying WSUS so that you can have optimized performance. Ключевые моменты The key areas are:

Настройка сети Network setup

Отложенная загрузка Deferred download

Развертывание крупных обновлений Large update deployments

Фоновая интеллектуальная служба передачи (BITS) Background Intelligent Transfer Service (BITS)

Настройка сети Network setup

Чтобы оптимизировать производительность в сетях WSUS, примите во внимание следующие советы. To optimize performance in WSUS networks, consider the following suggestions:

Для сетей WSUS предпочтительнее звездообразная топология, чем иерархическая. Set up WSUS networks in a hub-and-spoke topology rather than in a hierarchical topology.

Используйте сетевую маску DNS, направленную на клиентские компьютеры в роуминге, настройте эти компьютеры так, чтобы они получали обновления с локального сервера WSUS. Use DNS netmask ordering for roaming client computers, and configure roaming client computers to obtain updates from the local WSUS server.

Отложенная загрузка Deferred download

Можно утверждать обновления и загружать метаданные обновлений перед загрузкой файлов обновлений. Данный метод называется отложенные загрузки. You can approve updates, and download the update metadata before you download the update files, this method is called deferred downloads. Когда загрузка откладывается, обновление загружается только после его утверждения. When you defer downloads, an update is downloaded only after it is approved. Рекомендуется использовать отложенную загрузку, поскольку это оптимизирует пропускную способность сети и дисковое пространство. We recommend that you defer downloads because it optimizes network bandwidth and disk space.

В иерархии серверов WSUS служба WSUS автоматически настраивает подчиненные серверы использовать параметр отложенной загрузки корневого сервера WSUS. In a hierarchy of WSUS servers, WSUS automatically sets all downstream servers to use the deferred download setting of the root WSUS server. Данный параметр по умолчанию можно поменять. You can change this default setting. Например, можно настроить вышестоящий сервер на выполнение полной немедленной синхронизации, а затем настроить подчиненный сервер на отложенную загрузку. For example, you can configure an upstream server to perform full, immediate synchronizations, and then configure a downstream server to defer the downloads.

При развертывании иерархии подключенных серверов WSUS рекомендуется не располагать серверы глубоко. If you deploy a hierarchy of connected WSUS servers, we recommend that you do not deeply nest the servers. Если включена отложенная загрузка, а подчиненный сервер запрашивает обновление, которое не было утверждено на вышестоящем сервере, запрос подчиненного сервера принудительно загружается на вышестоящем сервере. If you enable deferred downloads and a downstream server requests an update that is not approved on the upstream server, the downstream server’s request forces a download on the upstream server. Затем подчиненный сервер загружает обновление при последующей синхронизации. The downstream server then downloads the update on a subsequent synchronization. На глубоких уровнях иерархии серверов WSUS при запросе обновлений, их загрузке и прохождении через иерархию могут возникать задержки. In a deep hierarchy of WSUS servers, delays can occur as updates are requested, downloaded, and then passed through the server hierarchy. По умолчанию отложенные загрузки активированы при локальном хранении обновлений. By default, deferred downloads are enabled when you store updates locally. Данный параметр можно поменять вручную. You can change this option manually.

Фильтры Filters

Служба WSUS позволяет фильтровать синхронизацию обновлений по таким признакам, как язык, продукт и класс. WSUS lets you filter update synchronizations by language, product, and classification. В иерархии серверов WSUS служба WSUS автоматически настраивает подчиненные серверы использовать параметры фильтрации обновлений, которые выбраны на корневом сервере WSUS. In a hierarchy of WSUS servers, WSUS automatically sets all downstream servers to use the update filtering options that are selected on the root WSUS server. Серверы загрузок можно настроить на прием только подмножества языков. You can reconfigure download servers to receive only a subset of the languages.

По умолчанию продукты, которые должны обновляться — Windows и Office, а классами по умолчанию являются критические обновления, обновления группы безопасности и определений. By default, the products to be updated are Windows and Office, and the default classifications are Critical updates, Security updates, and Definition updates. Для сохранения пропускной способности и дискового пространства рекомендуется ограничить количество языков до действительно используемого. To conserve bandwidth and disk space, we recommend that you limit languages to those that you actually use.

Установка Installation

Обновления обычно состоят из новых версий файлов, которые уже существуют на компьютере и обновление которых выполняется. Updates typically consist of new versions of files that already exist on the computer that is being updated. На уровне двоичного кода эти существующие файлы могут и не сильно отличаться от обновленных версий. On a binary level, these existing files might not differ very much from updated versions. Функция экспресс-установки файлов определяет точное различие в байтах между версиями, создает и распространяет обновления, в которых учтены именно эти различия, а затем дополняет существующие файлы обновленными байтами. The express installation files feature identifies the exact bytes between versions, creates and distributes updates of only those differences, and then merges the existing file together with the updated bytes.

Иногда эта функция называется «разностная Доставка», так как она скачивает только разницу (разницу) между двумя версиями файла. Sometimes this feature is called «delta delivery» because it downloads only the delta (difference) between two versions of a file. Файлы экспресс-установки имеют больший размер, чем обновления, которые распространяются на клиентские компьютеры, поскольку эти файлы содержат все возможные версии каждого обновляемого файла. Express installation files are larger than the updates that are distributed to client computers because the express installation file contains all possible versions of each file that is to be updated.

Файлы экспресс-установки можно использовать для ограничения пропускной способности, потребляемой в локальной сети, так как службы WSUS передают только изменившиеся данные, применимые к конкретной версии обновляемого компонента. You can use express installation files to limit the bandwidth that is consumed on the local network, because WSUS transmits only the delta applicable to a particular version of an updated component. Однако это достигается за счет дополнительной полосы пропускания между сервером WSUS, любыми вышестоящими серверами WSUS и Центром обновления Майкрософт и требует дополнительного дискового пространства. However, this comes at the cost of additional bandwidth between your WSUS server, any upstream WSUS servers, and Microsoft Update, and requires additional local disk space. По умолчанию служба WSUS не использует файлы экспресс-установки. By default, WSUS does not use express installation files.

Не все обновления подходят для распространения посредством файлов экспресс-установки. Not all updates are good candidates for distribution by using express installation files. При выборе данного параметра вы получите файлы экспресс-установки для всех обновлений. If you select this option, you obtain express installation files for all updates. Если вы не храните обновления локально, агент обновления Windows будет решать, загружать ли файлы экспресс-установки или распространяемые пакеты полного обновления. If you do not store updates locally, the Windows Update Agent will decide whether to download the express installation files or the full-file update distributions.

Развертывание крупных обновлений Large update deployment

Чтобы избежать перегрузки сети при развертывании крупных обновлений (таких как пакеты обновлений), применяются следующие методики. When you deploy large updates (such as service packs), you can avoid saturating the network by using the following practices:

Регулирование количества запросов фоновой интеллектуальной службы передачи (BITS). Use Background Intelligent Transfer Service (BITS) throttling. Ограничения пропускной способности BITS можно контролировать посредством истинного времени, но эти ограничения распространяются на все приложения, которые используют BITS. BITS bandwidth limitations can be controlled by time-of-day, but they apply to all applications that are using BITS. Дополнительные сведения об управлении регулированием BITS см. в разделе групповые политики. To learn how to control BITS throttling, please see Group Policies.

Регулирование количества запросов Internet Information Services (IIS) для ограничения количества запросов к одной или нескольким веб-службам. Use Internet Information Services (IIS) throttling to limit throttling to one or more web services.

Использование групп компьютеров для контроля управления выгрузкой. Use computer groups to control the rollout. Клиентский компьютер определяет себя членом отдельной группы компьютеров, когда отсылает сведения на сервер WSUS. A client computer identifies itself as a member of a particular computer group when it sends information to the WSUS server. Сервер WSUS использует данную информацию для определения тех обновлений, которые необходимо развернуть на этом компьютере. The WSUS server uses this information to determine which updates should be deployed to this computer. Можно настроить несколько групп компьютеров и последовательно утвердить загрузки крупных пакетов обновлений для подмножества этих групп. You can set up multiple computer groups and sequentially approve large service pack downloads for a subset of these groups.

Фоновая интеллектуальная служба передачи Background Intelligent Transfer Service

Для всех своих задач по передаче файлов служба WSUS использует протокол фоновой интеллектуальной службы передачи (BITS). WSUS uses the Background Intelligent Transfer Service (BITS) protocol for all its file transfer tasks. Это включает в себя загрузки на клиентские компьютеры и синхронизацию серверов. This includes downloads to client computers and server synchronizations. BITS позволяет программам загружать файлы, используя запасную пропускную способность. BITS enables programs to download files by using spare bandwidth. BITS поддерживает передачу файлов во время отключения сети или перезагрузок компьютера. BITS maintains file transfers through network disconnections and computer restarts. Дополнительные сведения см. в следующих разделах: Фоновая интеллектуальная служба передачи. For more information, see: Background Intelligent Transfer Service.

1.7. 1.7. Планирование параметров автоматического обновления Plan Automatic Updates settings

Можно задать предельный срок утверждения обновлений на сервере WSUS. You can specify a deadline to approve updates on the WSUS server. Предельный срок побуждает клиентский компьютер устанавливать обновление в определенное время, но существует ряд различных ситуаций, зависящих от таких факторов как: истек ли предельный срок, есть ли другие обновления в очереди на установку, требует ли обновление (или другое обновление в очереди) перезагрузки компьютера. The deadline causes client computers to install the update at a specific time, but there are a number of different situations, depending on whether the deadline has expired, whether there are other updates in the queue for the computer to install, and whether the update (or another update in the queue) requires a restart.

По умолчанию автоматическое обновление опрашивает сервер WSUS на наличие утвержденных обновлений каждые 22 часа за вычетом случайной задержки. By default, Automatic Updates polls the WSUS server for approved updates every 22 hours minus a random offset. Если необходимо установить новые обновления, они будут скачаны. If new updates need to be installed, they are downloaded. Время между каждым циклом обнаружения можно менять от 1 до 22 часов. The time between each detection cycle can be manipulated from 1 to 22 hours.


С параметрами уведомлений можно производить следующие действия. You can manipulate the notification options as follows:

Если автоматическое обновление настроено на уведомление пользователей об уже установленных обновлениях, то уведомление передается в журнал системы и область уведомлений клиентского компьютера. If Automatic Updates is configured to notify the user of updates that are ready to be installed, the notification is sent to the System log and to the notification area of the client computer.

Когда пользователь с соответствующими учетными данными щелкает значок области уведомлений, автоматическое обновление отображает доступные для установки обновления. When a user with appropriate credentials clicks the notification area icon, Automatic Updates displays the available updates to install. Чтобы запустить процесс установки, пользователь должен щелкнуть Установка. The user must click Install to start the installation. Если для окончания обновления требуется перезагрузить компьютер, то появляется сообщение. A message appears if the update requires the computer to be restarted to complete the update. При поступлении запроса на перезагрузку автоматическое обновление не может обнаруживать дополнительные обновления, пока компьютер не будет перезагружен. If a restart is requested, Automatic Updates cannot detect additional updates until the computer is restarted.

Если автоматическое обновление настроено устанавливать обновления по имеющемуся расписанию, то подходящие обновления загружаются и помечаются как готовые к установке. If Automatic Updates is configured to install updates on a set schedule, applicable updates are downloaded and marked as ready to install. Автоматическое обновление уведомляет пользователей с соответствующими учетными данными с помощью значка области уведомлений, а событие заносится в журнал системы. Automatic Updates notifies users who have appropriate credentials by using a notification area icon, and an event is logged in the System log.

В назначенный день и время автоматическое обновление устанавливает обновление и перезагружает компьютер (по необходимости), даже если локальный администратор не вошел в систему. At the scheduled day and time, Automatic Updates installs the update and restarts the computer (if necessary), even if no local administrator is logged on. Если локальный администратор вошел в систему, а компьютеру требуется перезагрузка, автоматическое обновление выводит на экран предупреждение и обратный отсчет времени до перезагрузки. If a local administrator is logged on and the computer requires a restart, Automatic Updates displays a warning and a countdown for the restart. Иначе установка происходит в фоновом режиме. Otherwise, the installation occurs in the background.

Если компьютер необходимо перезагрузить, а в систему вошел какой-либо пользователь, то на экран выводится аналогичное диалоговое окно с обратным отсчетом времени, которое предупреждает пользователя о предстоящей перезагрузке. If the computer must be restarted, and any user is logged on, a similar countdown dialog box is displayed, which warns the user about the impending restart. Управлять перезагрузками компьютера можно с помощью групповой политики. You can manipulate computer restarts with Group Policy.

После загрузки свежих обновлений автоматическое обновление запрашивает у сервера WSUS список утвержденных пакетов для подтверждения того, что срок действия пакетов, которые оно загрузило, не истек, а сами пакеты являются утвержденными. After the new updates are downloaded, Automatic Updates polls the WSUS server for the list of approved packages to confirm that the packages it downloaded are still valid and approved. Это означает, что если администратор WSUS удалит обновления из списка утвержденных обновлений в ходе их загрузки автоматическим обновлением, то будут установлены лишь те обновления, которые до сих пор находятся в списке утвержденных. This means that, if a WSUS administrator removes updates from the list of approved updates while Automatic Updates is downloading updates, only the updates that are still approved are actually installed.

Windows — ограничиваем скорость копирования по сети

Как-то раз мне понадобилось по самбе с одного сервера на другой скопировать большой объём данных. Сервер просел по дискам и всё закончилось гневными криками и копирование пришлось отменить. Как же быть? Ограничиваем скорость копирования по сети встроенными средствами Windows. Для ограничения трафика используем QoS.

QoS — quality of service (качество обслуживания). Это технология предоставления различным классам трафика различных приоритетов в обслуживании.

Шейпинг (shaping traffic) — ограничение пропускной способности канала для отдельного узла сети ниже технических возможностей канала. Шейпинг обычно используется как средство ограничения максимального потребления трафика со стороны узла сети.

Первым делом заходим в свойства сетевой карты, которую будем ограничивать. Устанавливаем галку на Qos Packet Scheduler.

Далее открываем консоль Local Group Policy Editor (Редактор локальной групповой политики) или выполняем:

Заходим в Local Computer Policy > Computer Configuration > Windows Settings > Policy-based QoS.

Создаём новую политику, правой кнопкой — Create new policy. Открывается окошко создания политики.

Policy name — указываем любое.

Cpecify Throttle Rate — вот здесь и будем ограничивать скорость, попробуем 1024 Кб в секунду.

Переключаемся на вкладку Application Name.

Применяем политику для всех приложений- All applications. Переключаемся на вкладку IP Addresses.

Источник я не буду ограничивать — Any source IP Address. А вот получателя буду, в поле Only for the following destination IP address or prefix указываю IP адрес, на который буду закачивать данные. Переключаемся на вкладку Protocol and Ports.

Я собираюсь резать только трафик на самбу. поэтому указываю протокол TCP, и номер порта 445. OK

Собственно, всё готово. Проверяю скорость. Запускаю на копирование массив данных.

Вижу 881 KB/sec на отправителе.

Меняю в политике скорость, указываю 2048 Кб в секунду.

Нажимаю ОК и проверяю скорость.

1,14 MB/sec — скорость подросла. На получателе наблюдаю такую картину нагрузки на сеть в момент изменения политики.

Видно, что нагрузка резко выросла примерно в два раза и составляем 16,5 Мегабит в секунду. Если перевести в Мегабайты, получится 2014 Кб в секунду, почти то, что указали в политике.

Проверим ещё раз как работает изменение скорости копирования налету. Меняю в политике скорость, указываю 4096 Кб в секунду.

Нажимаю ОК и проверяю скорость.

1,54 MB/sec — скорость ещё подросла. На получателе наблюдаю такую картину.

Всё работает как часы, небольшой провал — не в счёт. Настройка заняла минимальное время, несколько кликов мышкой — и скорость загрузки по самбе ограничена указанными вами значениями.

Ограничения IIS?

На локальном сервере поднят IIS, на нем несколько сайтов. Когда на одном из сайтов подключается порядка 140-160 пользователей, подключение нового становится невозможным. т.е. отправляется http запрос, но ответ не доходит, типа страница грузится… При этом нагрузка на процессор не более 15% и свободной памяти более 50%. Причем остальные сайты на сервере грузятся без проблем. Такое ощущение что в настройках пула стоит ограничение на число сессий…

Подскажите в чем может быть проблема…

  • Вопрос задан более трёх лет назад
  • 6969 просмотров

Performance Monitor, или, если есть — Resource Monitor (запускается из TaskManager).
Если при большой нагрузке средние дисковые очереди больше чем 2 * (суммарное количество шпинделей у дисков) — это проблема.

Ограничение пропускной способности для каждого пользователя в IIS

Я хочу ограничить пропускную способность в IIS. мой сценарий — каждый пользователь может загружать только 300 Кбит/с.

Я проверяю MaxBandwidth в IIS, но он ограничивает количество пользователей не для каждого пользователя. также я проверяю Throttling Bandwidth но он ограничивает ширину полосы пропускания.

так как я могу ограничить пропускную способность для каждого пользователя или каждого файла в IIS?

Я думаю, вы не можете наложить ограничение пропускной способности для одного потока (одно соединение) на свой веб-сайт в IIS. Вместо этого вы можете использовать что-то вроде этого, для max-соединений

Проверьте URL-адрес ниже:


Чтобы ограничить загрузку, проверьте приведенный ниже URL-адрес:

ИТ База знаний

ShareIT — поделись знаниями!

Полезно

Узнать IP — адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP — АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Похожие статьи

Установка и настройка Docker Swarm

Chef — как готовить вашу сеть и никогда не пересаливать

Топ 20 бесплатных программ для системных администраторов

ELK (ElasticSearch, LogStash, Kibana): базовая настройка

Apache или IIS – сравнение и преимущества

Про веб — сервера

Если вы, или ваша организация намереваетесь создать Web – сервис, будь то сайт или приложение, то так или иначе вы обратите внимание на наиболее популярные на рынке платформы для создания web – серверов – Apache или Internet Information Services (IIS), которые занимают около 70% от всей доли интернета.

Многие сравнивают противостояние этих двух платформ как соперничество между Microsoft и Linux. В данной статье мы беспристрастно и объективно рассмотрим плюсы и минусы этих платформ.

Apache

Apache HTTP web – сервер – полное название платформы, распространяемой организацией Apache Software Foundation как открытое программное решение или проще говоря «open-source». Программное обеспечение сервера распространяется абсолютно бесплатно и его лицензия позволяет конечному пользователю редактировать исходный код, чтобы адаптировать Apache под свои нужды, а так же, внести вклад в будущее развитие серверной платформы.

Веб – сервер Apache может работать на всех популярных операционных системах, но чаще всего он используется в рамках Linux. Именно в паре с СУБД MySQL и PHP – скриптами образуется известный комплекс программного обеспечения LAMP Web – сервер (Linux, Apache, MySQL, PHP), который повсеместно используется в сети интернет.

В рамках исследования Netcraft, проводимого в феврале 2014 года, web – сервер Apache занимал 42% рынка. Однако стоит отметить, что в том же июне 2013 года этот показатель составлял 54% и 59% в 2010 году. Это связано с улучшением позиций основного конкурента IIS и ростом позиций Nginx.

С точки зрения функционала, Apache имеет впечатляющие характеристики. Многие функции реализуются как совместимые модули, расширяющие базовый функционал, диапазон которых варьируется от поддержки языков программирования до обеспечения различных схем аутентификации. Например, это могут быть языки Perl или Python. Модули аутентификации включают в себя элементы управления доступом к различным директориям сервера, пароль, установление подлинности и так далее. Многие другие функции, такие как Secure Sockets Layer (SSL) или TLS (Transport Layer Security) так же обеспечивается модульной системой. Помимо этого, Apache поддерживает возможность развернуть несколько web – сайтов, или графических интерфейсов приложений. Веб – сервер сжимает страницы, чтобы уменьшить их размер, что обеспечивает высокую скорость их загрузки. Наряду с высоким показателем безопасности, это является конкурентной чертой Apache.

Выделим два основных недостатка Apache HTTP web – сервера:

  • Перенасыщенность функционалом: Еще раз стоит подчеркнуть, что Apache действительно чрезвычайно богат на функции, возможности и инструментарий. Но, к сожалению, в рамках типовой инсталляции пользователь задействует только 10 % от этих функций.
  • С точки зрения архитектуры, Apache, работает по модели «процессов». Это означает, что для каждого соединения Apache выделяет отдельную «коннекцию», или другими словами поток данных, что вызывает значительную загрузку. Конкуренты, а именно асинхронные платформы и сервера работающие по модели «событий», имеют преимущество обработки нескольких процессов одновременно в рамках одной транзакции.

Internet Information Services (IIS) это веб – сервер разработки компании Microsoft и занимает второе место на рынке вслед за Apache. Платформа IIS будет работать только с Windows и поставляется в комплекте с этой операционной системы. В отличие от Apache, где основную поддержку продукта предоставляет сообщество разработчиков, IIS официально поддерживается компанией Microsoft. Разработка этого продукта не так стремительна по сравнению с Apache, но как было сказано выше, одним из главных конкурентных преимуществ IIS является официальная поддержка компании Microsoft, что очень важно для крупного бизнеса. Многие специалисты в области ИТ признают IIS одним из немногих коммерческих продуктов, который по настоящему может быть конкурентом «open-source» решению.

Постоянная доработка безопасности, производительности и удобства администрирования позволили увеличить долю присутствия на рынке IIS с 21% в 2010 году до 32% в феврале 2014 (ранее указанное исследование компании Netcraft). Самые большие продвижения были сделаны с точки зрения безопасности. Версия IIS 6.0 была уязвима к атакам: известный вирус Code Red, который заменял содержимое web – сайта на баннер об авторах вируса. Важно отметить, что многие уязвимости проявляются на уровне операционной системы.

Как и Apache, IIS использует различные расширения для внедрения дополнительного функционала. Например, работа с файлами по FTP, маршрутизация с помощью Application Request Routing (ARR), который позволяет вести балансировку нагрузки и повышать отказоустойчивость, различные медиа – компоненты, аудио, видео, динамическое изменение URL и прочие. Веб – сервер IIS предлагает более высокую совместимость с программной платформой .NET Framework и ASPX (Active Server Pages) чем Apache. Важно, что в IIS поддерживаются такие функции как мониторинг, отслеживание запросов в режиме реального времени. Конечно, IIS можно назвать «условно» бесплатным, так как распространяется он в комплекте с Microsoft Windows Server.

С точки зрения производительности, IIS уступает Apache, в виду архитектурной особенности и строгой работы на Windows.

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

И IIS и Apache имеют свои плюсы и минусы. Определиться с web – сервером поможет учет следующих факторов: Сервер IIS должен быть приобретен в комплекте с Windows, Apache не имеет официальной технической поддержки, но имеет высокие показатели безопасности, IIS отлично совместим с .NET и так далее. В таблице ниже приведены некоторые сравнительные характеристики:

Опция Apache IIS
Поддерживаемая ОС Windows, Linux, Unix, Mac OS Windows
Техническая поддержка Сообщество Корпоративная
Стоимость Полностью бесплатно Покупается в комплекте с Windows
Разработка «open-source» Проприетарное решение
Безопасность Хорошо Отлично
Производительность Хорошо Хорошо
Рынок 42% 32%
  • WEB сервер Apache
  • IIS
  • 5895
  • 83

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас :( Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации :) Просто оставьте свои данные в форме ниже.

Оптимизация IIS для пропускной способности ASP.NET

У меня есть приложение asp.net mvc, размещенное в IIS, на 100% asp.net — оно не обслуживает никакие бритвенные страницы или статические файлы.

Могу ли я каким-либо образом настроить параметры IIS для оптимизации пропускной способности asp.net, учитывая, что я не обслуживаю пользовательский интерфейс или статические файлы?

Обратите внимание, что я застрял на IIS / MVC в настоящее время.

1 ответ

Обратите внимание, что вы также должны настроить пул приложений, который использует ваше приложение. См. Руководство по настройке, настройке и настройке пулов приложений в IIS .

Оптимизация IIS для пропускной способности ASP.NET

У меня есть приложение asp.net mvc, размещенное в IIS, на 100% asp.net — оно не обслуживает ни страницы бритвы, ни статические файлы.

Могу ли я настроить настройки IIS, чтобы оптимизировать пропускную способность asp.net, учитывая, что я не обслуживаю ни пользовательский интерфейс, ни статические файлы?

Заметьте, что я застрял в IIS/MVC.

Обратите внимание, что вы также должны настроить пул приложений, который использует ваше приложение. См. » Управление, настройка и настройка пулов приложений» в IIS для руководства.

Илон Маск рекомендует:  Что такое код getprotobyname
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL