Главная Exchange/UC, Без рубрики, Новое Client Throttling Policies в Exchnage 2010 (Политики регулирования клиентов)
  • Client Throttling Policies в Exchnage 2010 (Политики регулирования клиентов)

    clip_image002

    Очевидно, что вопрос мониторинга ресурсов, потребляемых пользователями на сервере Exchange, рано или поздно встает перед каждым администратором крупной или даже средней организации. Ранее, администраторы почтовых серверов Microsoft Exchange, при помощи утилиты Exchange User Monitor (ExMon), могли в ручном режиме выявлять пользователей, которые неоправданно сильно загружают сервер и отключать их сеансы. Нужно заметить, что утилиту ExMon можно и сейчас скачать с сайта Microsoft и использовать совместно с сервером Exchange 2010, но далее мы поговорим не о ней.

    Начиная с сервера MS Exchange 2007, нам предлагается несколько другой подход к регулированию нагрузки, потребляемой пользователями. Теперь мы можем не мониторить нагрузку, а ограничивать её. При этом есть два основных механизма регулирования:

    • · Регулирование количества сообщений (Message Throttling);
    • · Политики регулирования клиентов (Client Throttling Policies).

    Механизм регулирования количества сообщений перешел из MS Exchange 2007 в 2010-ю версию сервера практически без изменений. Принцип его действия состоит в том, что он позволяет установить на транспортных серверах организации временные и количественные ограничения для процесса отправки и получения писем. При этом ограничения могут быть применены:

    • · К самому транспортному серверу;
    • · К соединителю отправки;
    • · К соединителю получения.

    Примечание: Данный вид регулирования может быть установлен только на транспортных серверах, т.е. на транспортном сервере-концентраторе (HUB), либо на пограничном транспортном сервере (Edge).

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

    Политики регулирования клиентов

    Политики регулирования клиентов (Client Throttling Policies) – это механизм, позволяющий отслеживать количество потребляемых ресурсов сервера каждым пользователем и устанавливать для них предельные значения.

    Политики регулирования клиентов перешли из 2007-й версии Exchange в 2010-ю с серьезными изменениями. На сервере MS Exchange 2007 была возможность контролировать лишь нагрузку оказываемую RPC-клиентоами, в MS Exchange 2010, был добавлен ещё ряд механизмов.

    Параметры политик регулирования клиентов

    Начнем с того, что после инсталляции на сервере Exchange автоматически создается политика регулирования клиентов по умолчанию (DefaultThrottlingPolicies_<GUID>). В стандартных ситуациях данной политики будет вполне достаточно. Но если она не удовлетворяет требованиям вашей организации, то вы можете её отредактировать либо создать ещё несколько новых политик.

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

    В результате выполнения командлета мы увидим достаточно большой набор свойств:

    clip_image004

    Рис.1: Политика регулирования клиентов по умолчанию.

    Если у вас несколько политик, то политику по умолчанию можно получить командой

    Get-ThrottlingPolicy | Where {$_.IsDefault –eq $True}

    В поле Name отображается имя политики, которое придется использовать в дальнейшем. Очевидно, что пользоваться политикой с таким длинным именем крайне неудобно, поэтому на будущее полезно будет её переименовать, например, в DefPolicy следующим образом:

    Get-ThrottlingPolicy | Where {$_.IsDefault –eq $True} | Set-ThrottlingPolicy –Name DefPolicy

    Сфера влияния политики

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

    • · Microsoft Exchange ActiveSync  (EAS);
    • · Веб-службы Exchange (EWS);
    • · IMAP (IMAP4);
    • · Outlook Web App (OWA);
    • · POP (POP3);
    • · Windows PowerShell (PowerShell).

    Чтобы отфильтровать вывод по конкретной службе, можно выполнить следующую команду:

    Get-ThrottlingPolicy | Select EWS*

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

    • · MaxConcurrency – Максимальное количество одновременных подключений для одного пользователя. Попытка создать более количество подключений будет отклонена;
    • · PercentTimeInCAS – время в процентах относительно одной минуты, в течении которого можно выполнять код на сервере клиентского доступа;
    • · PercentTimeInAD – время в процентах относительно одной минуты, в течении которого можно выполнять запросы к Active Directory;
    • · PercentTimeInMailboxRPC – время в процентах относительно одной минуты, в течении которого можно выполнять RPC запросы;
    • · PowerShellMaxConcurrency – указывает максимальное число сеансов удаленной командной консоли для одного пользователя;
    • · PowerShellMaxCmdlets – указывает число нерегулируемых командлетов, которое можно выполнить за определенный период времени;
    • · PowerShellMaxCmdletsTimePeriod – указывает период времени (в секундах), в течение которого пользователь может выполнить число командлетов, определенное параметром PowerShellMaxCmdlets;
    • · PowerShellMaxCmdletQueueDepth – указывает число операций, которое пользователь может одновременно выполнить.

    Примечание: Важное отличие политик регулирования клиентов на сервере Exchange 2010 RTM и Exchange 2010 SP1 заключается в том, что если в первом случае клиент превышает одно из пороговых значений, то все остальные его запросы сервер игнорирует. Во втором случае игнорирования запросов не происходит, они остаются в очереди и продолжают обрабатываться постепенно.

    Также стоит обратить внимание ещё на одно свойств политики – это IsDefault (рис.1). Именно оно делает простую политику политикой по умолчанию.

    Управление политиками регулирования

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

    Нужно заметить, что по умолчанию пользователю не назначено ни каких политик, это можно легко проверить, посмотрев на свойство –ThrottlingPolicy:

    Get-Mailbox –Identity <User> | FL ThrottlingPolicy

    Раз так, то очевидно, что на него распространяется политика по умолчанию. Чтобы назначить конкретную политику регулирования пользователю, необходимо сначала её создать, например, так:

    New-ThrottlingPolicy –Name <MyPolicy> –OWAMaxConcurrency 10

    А потом присвоить пользователю:

    Set-Mailbox –Identity <YourUser> –ThrottlingPolicy <MyPolicy>

    При этом отредактировать политику можно при помощи командлета Set-ThrottlingPolicy, например следующим образом:

    Set-ThrottlingPolicy –Identity <MyPolicy> -PercentTimeInAD 20

    Либо сделать политику используемой по умолчанию:

    Set-ThrottlingPolicy –Identity <MyPolicy> -IsDefault $True

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

    Заключение

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

    Алексей Богомолов (Alexx)
    http://alexxhost.ru

Комментарии

  1. Спасибо. Актуальная тема в организации больше 1000 ящиков.

  2. А чем эта информация отличается от аналогичной на сайте technet ?

  3. >А чем эта информация отличается от аналогичной на сайте technet ?
    Подачей и ни чем более. А чем ещё вы хотите чтобы она отличалась? Или вы думаете что я могу написать что-то, чего нет на TechNet`e?
    Плюсом к этому, далеко не все знают про небольшие фичи, подробно расписанные на TechNet`e. Задача именно этой статьи рассказать коллегам о тех механизмах, которых возможно они не знают.

  4. to Andrey
    а Вы всю информацию по Exchange 2010 с технета прочитали? там несколько тысяч страниц =) Вы отслеживаете изменения в документации на технете? =Р

  5. #А чем эта информация отличается от аналогичной на сайте technet ?#

    ДАВНО хотел задать подобный вопрос: ЗАЧЕМ авторы ПЕРЕПИСЫВАЮТ одну и ту же информацию, которую леГКо найти на сотне сайтов одним кликом, причем “от производителя”? нравится переписывать…или, может быть, некоторая форма тщеславия?

  6. Неет, my-my, у нас просто времени свободного стооооолько много, что дабы себя хоть чем-нить занять, мы с умным лицом копипастим все подряд из течнета неглядя, и всего делов-то… 🙂

  7. кол-во критиков последнее время зашкаливает.

    Ребята, я вам тезисно отвечу:

    1. Все уже написано производителем ПО, абсолютно все.
    2. Все это есть в двух вариантах, водянистым английским и не читаемым “промтовым” русским. Вся информация размазана по сотням тысяч страниц течнета и мсдн-а.
    3. Если вы хотите читать течнет – супер, можете тратить жизнь на копание в самом бездарно организованном архиве информации.
    4. У итбанд задача как у журнала, каждый день показывать какието ит-фишки и повышать общий уровень грамотности. При этом не вываливая на человека сотни страниц маркетинга и просто воды. Статьи здесь самые разные и самых разных уровней. Если вы видите статью и она для вам не нова – я вас поздравляю, вы молодец. Не надо думать, что тут вам чего то должны, не нравится статья, ну и хрен с ней, понравится другая. Не нравится вообще ничего, ресурсом в Инете много, найдите лучше. А вот этот подход, мда…. это видели… это не ново… он реально надоел. Можете лучше – делайте, а советчики, мы и сами со стажем.

  8. Илья, не кипятись… Сам прекрасно знаешь, что п1 неправда. не мне тебе рассказывать про недокументированные фичи.
    п.2 и 3 в общем-то правда.
    п.4 – свыкнись. Если делаешь что-то, всегда найдется тот, кому нравится и тот, кому не нравится. И это нормально, невозможно угодить всем. И если комментарий аргументирован, как #2 или первая часть #5, то нужно на неё спокойно реагировать.

    Заметка нормуль!

  9. Alexx, хоть часть правды сказал, насчет “занятости”… 🙂

  10. Илья Рудь, #Если вы хотите читать течнет — супер, можете тратить жизнь на копание в самом бездарно организованном архиве информации.#
    т.е. нарываясь на “блоговые” огрызки все усваивается быстрее и плодотворнее?
    з.ы. 99% макулатуры (книги/пособия) – офиц хэлп, “течнет” + “от автора”, разве нет?

    чуть конструктивно: я к тому клоню, что всегда интереснее статьи, которые более “из жизни” что-ли, а не копипаста/переводчик/каталогизатор

  11. Я так понимаю, вы хотите читать HOW-TO. На данном ресурсе и такого плана статей очень много.

  12. Как обзорная, статья мне понравилась. Очень неплохое начало для разбирательства с этими политиками, понятное переложение водянистого (тут полностью согласен) языка технета + некоторая структура изложения, которой там просто нет.
    Однако, я бы оставил в ней “зацепки” для более подробного изучения – можно ссылок, а можно собственного опыта использования.

    Возьму смелость добавить немного от себя 🙂
    Политики Client Throttling, на самом деле, не очень много дают обычной организации (со “стандартными”, в основном, решениями в инфраструктуре – никакой потребности в них практически нет). Зато выступают на первый план при работе сторонних приложений с эксченжем (самостоятельно разработанных, или приобретенных, и даже таких распространенных как Blackberry enterprise server).
    И здесь возникают вилы. Особенно в части троттлинга RPC и EWS, как наиболее часто используемых сервисов: Microsoft очень хорошие команды придумали для этого механизма, например RPC wait или backoff. Но далеко не все приложения обучены их понимать. Тот же блэкберри, например, если получает ‘wait’, начинает считать что объекта, за которым он к эксченжу обратился, просто нет – и синхронизирует это ‘отсутствие’ с мобильным девайсом/БД/… – и проявления такого непонимания можно наблюдать в разных приложениях, будь то BES, Enterprise vault или кастомное приложение под EWS.

  13. ktroitskiy, спасибо за полезный коммент.

  14. Спасибо за статью.
    Остался неосвещенным аспект, ответа на который я не смог найти ни на одном ресурсе.
    Как отменить присвоение пользователю политики?