Требуется много времени…

Исходная статья опубликована в понедельник, 20 февраля 2012 г.

Вслед за недавним объявлением о выпуске накопительного пакета обновления 1 для Exchange 2010 с пакетом обновления 2 мы выпустили множество исправлений, об одном из которых я и хочу здесь поговорить и, может быть, также пролить некоторый свет на то, как появляются подобные проблемы и как мы работаем над их исправлением.

Исправление обозначено как 2556113 и озаглавлено Пользователю требуется много времени для загрузки OAB в организации Exchange Server 2010.

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

Но мы этого не делали. (Хотя мы рассматриваем вопрос Интернета в целом, пытаясь понять, что тут можно сделать, потому что это звучит заманчиво.) Мы просто добавили кое-какую логику, благодаря которой Outlook пытается загрузить OAB с ближайшего сервера клиентского доступа (CAS).

"Зачем?" — спрашиваете вы. Хороший вопрос, на который я отвечу: "Как говорится в статье базы знаний, рассмотрим следующий сценарий".

• У вас есть два сайта Active Directory в медленной сети в организации Microsoft Exchange Server 2010.
• У вас есть сервер клиентского доступа Exchange Server 2010 и почтовый сервер Exchange Server 2010 на одном сайте Active Directory.
• У вас есть сервер клиентского доступа Exchange Server 2010 на другом сайте Active Directory, и вы добавляете там пользователя Office Outlook.
• Пользователь, почтовый ящик которого находится на другом сайте Active Directory, пытается загрузить автономную адресную книгу (OAB) Exchange.

В этом сценарии ему потребуется много времени, чтобы загрузить OAB.

Да-да. Кроме шуток. Такое действительно может быть. Если у вас большая OAB, это правда может занять много времени. Но давайте развернем сценарий чуть-чуть подробнее, поскольку, думается мне, там есть информация, которую вам необходимо знать, да и иметь сайт AD, содержащий только CAS, большинству людей кажется не слишком разумным.

Итак, рассмотрим более подробный сценарий:

• У вас есть централизованное развертывание. Все почтовые ящики находятся в центральном расположении.
• У вас есть множество небольших расположений, в которых работают люди.
• Эти расположения соединяются с центральным офисом через сети низкого качества. Спутниковые, ISDN, PSTN, тропосферная связь(у меня как-то был заказчик с такой; все было прекрасно, пока не началась гроза) и т. д.
• Ваша OAB большого размера. Она большая. Не маленькая. Выберите любое определение, какое вам больше нравится. Достаточно сказать, что ее размер настолько велик, чтобы заставить вас задуматься.
• Ваш клиент Outlook пытается загрузить OAB, которая берется из централизованного центра данных. Так что и сидящий рядом с вами коллега, использующий клиент Outlook, и вон тот забавный парень в углу — все вы загружаете одну и ту же OAB. По одной и той же сети низкого качества. И это происходит очень медленно.

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

Итак, вы добавляете CAS в каждое удаленное расположение. Фактически так, как это предлагается на диаграмме, подробно описанной в статье https://technet.microsoft.com/en-us/library/bb232155.aspx. Идея в том, что клиентский компьютер будет загружать нужную OAB с локального CAS. Да, это классно звучит, но Exchange так никогда не работал. То есть до 2010 SP2 RU1…

Как же тогда это работало? И почему я говорю, что TechNet лгал вам?

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

Чтобы ответить на второй вопрос, необходимо сперва понять, что TechNet никогда не ошибается (мои друзья из UE, например Скотт Шноль (Scott Schnoll), были бы задеты, услышав намеки на ошибочность их статей).  Просто иногда это бывает не совсем верно с определенной точки зрения.  В TechNet это описывается так, как если бы было частью первоначальной спецификации PM в то время, когда создавалась версия 2007. Вероятно, мне не следовало бы говорить вам это, но это так. Знаете, такое случается в программном продукте, содержащем более 20 миллионов строк кода, когда что-то постоянно меняется. TechNet обычно не лжет. Конечно, нет.

Вернемся к тому, как это работает. Задумайтесь на минутку. У вас имеется OAB размером 1 ГБ. И вы добавляете реплику этой OAB в CAS на удаленном и далеком сайте AD, где находятся пользователи. Но они никогда ее не используют. (Ну, за исключением случая, когда их почтовые ящики находятся на том же сайте AD, но это ведь не наш сценарий, верно?) Не тот случай. Да, я слышу ваше возражение. Это выглядит примерно как на следующей диаграмме.

Outlook использует CAS, ближайший к клиентскому компьютеру, для запросов AutoDiscover клиента (ну, он должен , и мы через минуту к этому вернемся), но возвращаемый URL-адрес OAB относится к CAS на том же сайте AD, где расположен почтовый ящик . То есть даже не смотря на реплику OAB на сайте AD B, клиент вытягивает OAB с сайта AD A.

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

1. Они могут уменьшить размер OAB, увеличить скорость территориально-распределенной сети, переместить удаленные офисы поближе и т. д. Все это их не устраивает. Тем не менее, мы спросили.
2. Мы можем создать множество OAB с одинаковым содержимым. И указать на уровне пользователя или базы данных, какую OAB следует загружать пользователю. Затем остается только обеспечить доступность OAB в удаленном расположении. Таким образом, AutoDiscover будет предоставлять единственный возможный URL-адрес. Ну, это звучит неплохо, если не считать того, что пользователи переходят с сайта на сайт. А загрузка тогда будет означать двойной скачок по медленной сети. Ой. Не пойдет.
3. То же самое с почтовыми ящиками — переместить почтовые ящики в удаленные расположения… Да, они перемещаются, но это заметно усложнило бы администрирование и доступность, что привело бы к увеличению затрат.
4. Мы можем сделать что-то вроде обратного сопоставления IP-адреса с сайтом AD. Полагаю, именно этим способом мы первоначально планировали решать проблему, и он на самом деле довольно трудный. Нам бы потребовалось обеспечить наличие всех подсетей, из которых может прийти клиент, в модуле "Сайты и службы AD", а затем попробовать осуществить обратное проектирование сайта AD, на котором находится пользователь, и прикинуть стоимость связывания сайтов, и… Надеюсь, идея понятна. Это сложно и может сорваться из-за NAT или из-за того, что администратор забудет указать все возможные подсети в модуле "Сайты и службы AD".
5. Мы можем попытаться "вмешаться" в DNS или AutoDiscover XML, чтобы заставить клиент думать, что он обращается к централизованному расположению, тогда как на самом деле он обращается к локальному экземпляру IIS. Но это, опять же, непросто, сложно для реализации и поддержки да и просто безобразно, если хотите знать.
6. Что-нибудь еще. Я выбираю этот вариант, поскольку остальные кажутся очень уж сложными.

Давайте мысленно вернемся на несколько абзацев назад к предложению "Outlook использует CAS, ближайший к клиентскому компьютеру, для запросов AutoDiscover клиента", к которому я обещал вернуться. Да, определенно стоит вернуться, поскольку существует такая штука, которая называется AutoDiscoverServiceSiteScope.

AutoDiscoverServiceSiteScope — это параметр CAS, который помогает клиенту Outlook сопоставлять сайты AD с CAS в целях поиска CAS, ближайшего к клиенту, для запросов AutoDiscover. При этом выполняется поиск точек подключения службы (SCP), которые по сути являются указателями на службу AutoDiscover.

Теперь о том, как это работает. Когда клиент Outlook запускается, он направляется в треугольник, иногда и иначе именуемый "AD", и ищет все SCP, созданные программой настройки Exchange. Он находит группу точек (мы надеемся), у каждой из которых имеется атрибут Keywords, который задается, изменяется и иногда портится с помощью Set-ClientAccessServer –AutoDiscoverServiceSiteScope: ADSiteNameA, ADSiteNameB и т. д. Атрибуты Keywords позволяют указать, за какие сайты AD отвечает данный CAS, для запросов AutoDiscover.

Когда клиент Outlook находит более одной SCP, он самостоятельно формирует список применимых SCP, сравнивая значение из атрибута Keywords со своим сайтом AD (который динамически обновляется локальной службой Netlogon при запуске или изменении IP-адреса).

Затем он создает список. В список помещаются либо все SCP, соответствующие его сайту AD (где атрибут Keywords = сайту AD клиента), либо все найденные, если соответствий нет. Эти серверы он может использовать для своих запросов AutoDiscover.

Начинает он сверху списка (который, кстати, всегда упорядочен одинаково, по дате установки) и пытается подключиться к URI, содержащемуся в атрибуте ServiceBindingInformation и указывающему расположение собственно службы AutoDiscover. Затем он отправляет XML, получает ответ и т. д. и дальше живет себе припеваючи. Более подробные сведения обо всем, что касается этой прекрасной службы AutoDiscover, можно найти здесь.

Почему это интересно Ну, AutoDiscoverServiceSiteScope помогает Outlook находить CAS, ближайший к расположению клиента, исходя из предположения, что администратор правильно настроил области сайта (и мы расскажем администраторам, как это делать). Так что нам вовсе не требуется вычислять, какой CAS является ближайшим к клиенту, когда мы получаем запрос, поскольку это уже происходит к тому моменту, когда запрос достигает CAS.

Как только запрос попадает в CAS, мы определяем параметры, которые нужно возвратить клиенту, но затем мы всегда забываем одну вещь — что нужная пользователю OAB может быть локальной для CAS, на котором выполняется запрос, между тем как мы всегда даем пользователю URL-адрес с CAS, расположенного по пути, вон там. И это нам необходимо исправить.

Решить эту проблему теоретически очень просто. Это значит, что нам не надо изобретать новый способ для определения ближайшего к клиенту CAS, поскольку у нас уже имеется один такой, который прекрасно работает, большое спасибо.

Если мы предполагаем, что администратор правильно настроил AutoDiscoverServiceSiteScope, то CAS, к которому подключается клиент для AutoDiscover, будет ближайшим CAS к клиенту. Если это предположение остается в силе, то при определении того, что именно следует возвращать в AutoDiscover XML, CAS требуется просто проверить, является ли он сам копией необходимой пользователю OAB. И если да, он просто предоставляет свой собственный URL-адрес OAB. Другое дело для CAS на сайте AD, где находится почтовый ящик пользователя. Конечно, если он не является копией нужной пользователю OAB, берет верх прежнее поведение, то есть CAS возвращает URL-адрес OAB того CAS, который находится на сайте AD почтового ящика.

То есть, картина меняется и выглядит следующим образом:

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

Что вам нужно сделать, чтобы заработало это новое поведение? Только две вещи. Разверните SP2 RU1 на CAS и обеспечьте правильную настройку параметров AutoDiscoverServiceSiteScope.

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

Грег Тейлор (Greg Taylor)
старший руководитель программы
программа улучшения качества программного обеспечения Exchange

Это локализованная запись блога. Исходная статья доступна по ссылке It Takes a Long Time…