Jaa

Robert’s Rules of Exchange – многоролевые серверы

  • Artikkeli

Огромный привет всем моим читателям со всего света! Я должен извиниться за долгое молчание. Со времени новогодних праздников я был крайне занят, но действительно хотел вернуться к статьям серии Robert’s Rules, и я надеюсь более глубоко включиться в этот процесс. Кроме того, присылайте важные комментарии и вопросы! Я прочитаю и попытаюсь ответить на каждый из них. Если вы собираетесь на TechEd North America 2011 в Атланту, где я буду присутствовать, делая кое-что вместе с командой MCM Exchange и, как обычно, надоедая всем, то приходите, познакомся!

В этой статье я хочу обсудитьо многоролевех серверы. Это то, что команда Exchange и  Microsoft Services предлагают как эскизный проект («эскизный проект» – это первая идея, первое грубое приближение к тому, что мы предлагаем для внедрения) почти каждому заказчику, с которым мы работаем, и это то, что вызывает много путаницы, поскольку это, безусловно, совершенно другой подход, чем раньше. Так что я хочу обсудить то, что мы подразумеваем под «многоролевыми серверами», почему мы считаем их важным подходом к масштабированию многоролевых внедрений, когда они могут не соответствовать вашим условиям внедрения и каковы реальные последствия отхода от многоролевых серверов в вашем решении.

Что мы подразумеваем под многоролевыми серверами?

Когда мы говорим о многоролевых серверах Exchange 2010, мы говорим об одном сервере с установленными тремя основными ролями – сервера клиентского доступа, транспортного сервера-концентратора и сервера почтовых ящиков. Хотя установка любых двух их них – это технически многоролевое внедрение, и даже в Exchange Server 2007 мы видели много заказчиков, совмещающих роли сервера клиентского доступа итранспортного сервера-концентратора, когда мы говорим о многоролевых серверах, мы в действительности говорим о совмещении всех трех основных ролей на одном сервере.

В Exchange 2007 мы не поддерживали роли сервера клиентского доступа и транспортного сервера-концентратора на кластерных серверах, так что не существовало способа обеспечить высокую доступность (имеются в виду кластеры Cluster Continuous Replication) на многоролевых серверах. В Exchange 2010 мы предложили группы высокой доступности (Database Availability Group, DAG), которые не имеют такого ограничения, и соответственно мы изменили основную рекомендацию, чтобы применять многоролевые серверы везде, где это только возможно. Далее в этой статье обсуждается, почему мы полагаем, что в почти каждом сценарии это решение будет лучшим для наших заказчиков.

Каковы преимущества многоролевых серверов Exchange 2010?

Одна из идей, которую я действительно упорно втолковывал в статье по планированию хранилища, была идея простоты. Каждый раз, когда я садился с заказчиком обсуждать, как они должны развертывать Exchange 2010, я начинал с наиболее простого решения, которое я мог предложить. Вспомните, мы уже убедились, что простота обычно вносит много  “хорошего" в решение. Это “хорошее” включает (но не ограничивается этим) более низкие капитальные затраты, более низкие эксплуатационные затраты, более высокий шанс успеха как во внедрении, так и в соответствии эксплуатационным требованиям. С другой стороны, сложность вносит риск. Сложность, когда она не нужна – это "плохо". Конечно, когда сложность вносится как результат потребностей, то это не “плохо”. Только когда нам не нужна сложность, я имею с ней проблемы.

Из предыдущей статьи (про планирование хранилища) мы знаем, что проект Robert’s Rules использует простую инфраструктуру хранения с системами хранения прямого подключения без RAID – то, что Microsoft называет JBOD (just a bunch of disks). Если мы объединим это с многоролевыми серверами, где каждый сервер, который мы развертываем в нашей инфраструктуре, точно такой же, как другой, то мы значительно уменьшим сложность системы. Каждый сервер имеет точно такое количество памяти, точно такое же количество дисков, точно такую же сетевую карту, точно такую же графическую карту, точно такие же драйверы, точно такую же прошивку/BIOS – всё одинаковое. У вас меньше серверов в вашей лаборатории для тестирования, меньше различных драйверов и прошивок для тестирования, вам легче решить, какую версию какого программного обеспечения или прошивки установить на этих серверах. Более того, у всех серверов одинаковые настройки, включая те же самые настройки ОС и те же самые настройки Exchange, так же как любые другие агенты или антивирусные сканеры или что-то иное на этих серверах. Все то же самое на серверном уровне. Это значительно уменьшает ваши эксплуатационные расходы, потому что у вас единственная платформа для развертывания и поддержки: простота управления означает, что ваши люди должны делать меньше работы для поддержки этих серверов, и это означает, что это стоит вам меньше денег!

Пример серверов с раздельными ролями

Теперь давайте подумаем о количестве серверов, которые нам необходимы в нашей среде. Я собираюсь здесь немного поэкспериментировать с калькулятором требований к роли сервера почтовых ящиков Exchange 2010, так что я загрузил его последнюю версию (14.4 на данный момент). Я также начну с решения, в котором разделены все роли – сервер почтовых ящиков, сервер клиентского доступа и транспортный сервер-концентратор. Такое сочетание полностью поддерживается, и многие из моих заказчиков полагают, что именно его рекомендует Microsoft. После того, как мы рассчитаем это решение и выясним, о каком количестве серверов мы говорим, мы рассмотрим многоролевой вариант.

Просматривая веб-сайт известного производителя серверов, я нашел сервер с процессором Intel X5677, так что я буду использовать этот 8-ядерный сервер как мою базовую систему.  С помощью инструмента расчета процессоров для сервера почтовых ящиков Exchange я нашел, что сервер, использующий этот процессор с 8-ю ядрами на сервер, имеет средний индекс SPECint 2006, равный 297, поэтому я буду использовать именно это значение в калькуляторе ресурсов. Отмечу, что по умолчанию серверы в калькуляторе ресурсов не отмечены как многоролевые.

Открыв калькулятор ресурсов с исходными значениями, я устанавливаю эти параметры конфигурации моего сервера – 8 ядер и значение SPECint2006, равное 297.  Сделав только эти изменения, мы можем затем получить результаты на странице Role Requirements. У нас 6 серверов в DAG, 4 копии данных, у нас 24 000 пользователей, загрузка процессоров 36%, и серверам требуется по 48 Гбайт памяти. В общем, неплохо. Только вот процессор загружен слишком слабо. Откройте калькулятор, страница Role Requirements, секция Server Configuration, поле Mailbox Role CPU Utilization. Там есть комментарий, который поможет вам понять значение величины загрузки. Этот комментарий говорит, что для серверов, установленных с единственной ролью сервера почтовых ящиков и включенных в DAG,  мы не должны превышать загрузку в 80%. Но у нас загрузка равна 36%. Это говорит о том, что процессор большей частью простаивает! Мы потратили деньги на 8-ядерную систему, и мы не используем ее полностью. Так что я собираюсь убрать по 4 ядра из каждого сервера.

Согласно инструменту расчета процессоров для сервера почтовых ящиков, 4-ядерная система с подобным процессором будет иметь значение SPECint2006, равное 153. Давайте посмотрим, что это значит,  поместив его в калькулятор требований к роли сервера почтовых ящиков. Это повысило загрузку процессора до 69%, что намного лучше. Я бы чувствовал себя намного лучше, рекомендуя это моим заказчикам. Это изменение совсем на влияет на требования к памяти.

Следующая вещь, которую мы будем рассматривать – это количество ядер, необходимое для других ролей.  Наверху страницы Role Requirements мы можем увидеть, что это решение потребует 2 ядра для роли транспортного сервера-концентратора и 8 ядер для роли клиентского доступа. Теперь, как хорошие инженеры, мы предложим нашим заказчикам 4-ядерный сервер для роли транспортного сервера-концентратора и два 4-ядерных сервера для роли клиентского доступа, так? Абсолютно нет! Мы спроектировали наше решение в расчете на отказ двух серверов (6 серверов в DAG с 4 копиями могут поддерживать отказ 3 серверов, что является несколько чрезмерным, но поддержка отказа 2 серверов является наиболее частым решением, так что в нашем примере мы будем придерживаться этого). Теперь и для роли клиентского доступа, и для роли транспортного сервера-концентратора нам необходимо по 2 дополнительных сервера для обеспечения сценариев отказа серверов. Если я потеряю 2 сервера клиентского доступа, то мне нужно еще 8 работающих ядер на оставшихся серверах клиентского доступа, чтобы поддерживать полнофункциональную среду – это означает, что мне нужно минимум 4 сервера клиентского доступа с 4 ядрами на каждом. Если я потеряю 2 транспортных сервера-концентратора, то мне нужен еще 1 работающий сервер, чтобы обрабатывать мой почтовый трафик (в действительности половина сервера – 2 ядра – но вы не можете распилить сервер), таким образом нам нужно 3 транспортных сервера-концентратора.

Сколько всего серверов мы получили? У нас 6 серверов почтовых ящиков, 4 сервера клиентского доступа и 3 транспортных сервера-концентратора. Всего 13 серверов. Не слишком плохо для 24 000 пользователей, не так ли? Сколько памяти нужно для этих трех серверов? Рекомендация для сервера клиентского доступа – это 2 Гбайт на ядро, рекомендация для транспортного сервера-концентратора – 1 Гбайт на ядро. Таким образом, у нас 6 серверов с 48 Гбайт (серверы почтовых ящиков), 4 сервера с 8 Гбайт (серверы клиентского доступа) и 4 сервера с 4 Гбайт (транспортные серверы-концентраторы). В нашей относительно простой среде есть 3 различных типа серверов, 3 различных конфигурации памяти, 3 различных конфигурации операционной системы, 3 различных конфигурации Exchange и 3 различных плана поддержки/обновления. Просто? Я думаю, нет.

Пример с многоролевыми серверами

Теперь, используя тот же самый сервер, тот же самый процессор, все то же самое, что и раньше, мы просто переключим калькулятор в  режим multi-role. На странице Input переключатель multi-role (Server Multi-Role Configuration (MBX+CAS+HT)) ставим в Yes. Теперь переходим на страницу Role Requirements и… Ой!!! Страницу окружает большая красная рамка! Что это означает? Явно что-то нехорошее.

Если мы еще раз посмотрим на комментарий, который оставил для нас садист, написавший этот калькулятор, то мы увидим, что многоролевой сервер в решении, обеспечивающем отказоустойчивость почтовых ящиков, должен иметь загрузку процессора, не превышающую 40% для роли сервера почтовых ящиков. Это так, потому что у нас роли сервера клиентского доступа и транспортного сервера-концентратора расположены на этом же сервере, и у них есть свои требования к процессору. Фактически в этой ситуации мы отдаем половину процессора ролям сервера клиентского доступа и транспортного сервера-концентратора. Так что вернемся к нашему 8-ядерному серверу с индексом SPECint2006, равным 297.

Это изменение возвращает нас к правильному уровню загрузки процессора. Посмотрим снова на страницу Role Requirements, теперь у нас значение Mailbox Role CPU Utilization равно 36%. Так как максимальное значение, которое мы можем достичь, равно 39%, то это достойная загрузка для нашего оборудования. Другое изменение, которое мы видим – это  изменение объема памяти с 48 Гбайт на сервер до 64 Гбайт, что также увеличивает стоимость наших серверов, но изменение с 48 Гбайт до 64 Гбайт не столь дорогое, как несколько лет назад, и я видел многих заказчиков, приобретающих 64 Гбайт памяти, если не больше,  для почти всех своих серверов (я действительно видел много машин с 128 Гбайт памяти).

Теперь самое важное: факт, что мы снизили количество серверов до 6. Давайте рассмотрим, как наши решения повлияют на общую стоимость владения серверами:

Стоимость оборудования: оно основано на стоимости серверов и выбранного нами производителя, но стоимость одного 4-ядерного процессора и 16 Гбайт памяти на сервер против 7 дополнительных серверов несложно прикинуть.
Стоимость помещения или места в стойке: каждый раз, когда вы добавляете новый сервер в стойки, вы как-то платите за это. У некоторых из моих заказчиков серверные комнаты переполнены, и добавление новых серверов является трудным или невозможным. Консолидация серверов – это огромный стимул для почти всех моих заказчиков, и консолидация 20 или 30 серверов до 6 – это бОльшая победа, чем консолидация того же самого количества серверов до 13. Также, задействуя оба процессорных гнезда в наших серверах, мы имеем более высокую плотность ядер на то количество мест в стойках, которое мы занимаем. Удаление процессора из гнезда на одном сервере не уменьшает пространства, которое занимает сервер!
Расходы на охлаждение: очевидно, что большее количество процессоров и оперативной памяти ведет к большему выделению тепла каждым из 6 серверов почтовых ящиков, но 7 дополнительных серверов будут выделять больше тепла, чем дополнительные процессоры и память. Легко видеть экономию стоимости и в этом случае.
Расходы на обслуживание:  и опять легкая победа. 6 серверов легче и проще обслуживать, чем 13 серверов, особенно когда вы примете во внимание, что эти 6 серверов будут одинаковыми, в то время как в случае серверов с раздельными ролями мы имеем 3 разных набора серверов и конфигураций.  Самое главное тут заключается в том, что почти в каждом сценарии изменения в эксплуатационных расходах в течение жизни решения (обычно 3-5 лет) оказывают большее влияние, чем изменения в капитальных затратах.

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

Когда многоролевой сервер вам не походит?

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

Можно ли использовать многоролевые серверы в виртуальной среде?

Давайте рассмотрим случай виртуализации. Наша рекомендация по виртуализации – это эмпирическое правило: накладные расходы составляют 10% пользовательской нагрузки на сервер в случае виртуализации. Другими словами, гостевая виртуальная машина сможет делать на 10% меньше работы, чем если бы она работала на физической машине с точно таким же физическим процессором. Или вот другой способ взглянуть на это: каждый пользователь будет вызывать примерно на 10% больше нагрузки в гостевой системе, чем на физической. Таким образом, я могу взять коэффициент 1.1 для Megacycle Multiplication Factor в разделе описания пользователей на странице Input, и это дает мне 39% загрузки процессора для выбранного оборудования. Конечно, мы не берем в расчет тот факт, что мы не распределили ресурсы процессоры для хоста, и тот факт, что мы должны заплатить дополнительные лицензионные отчисления  VMware, если мы хотим запускать 8-ми ядерные гостевые системы.

Если мы вернемся обратно к нашему 4-ядерному примеру, то установка Megacycle Multiplication Factor равным 1.1, и, скажем, установка двух DAG вместо одной приведет к повышению загрузки наших процессоров на этих 4-ядерных многоролевых серверах до 38%, что делает наше виртуализированное многоролевое решение приемлемым. Другие заказчики могут решить разделить роли, например,  6 виртуальных серверов почтовых ящиков и 6 виртуальных серверов с совмещенными ролями сервера клиентского доступа и транспортного сервера-концентратора.

Каждое из этих решений является определенно поддерживаемым, но теперь у нас вдвое больше серверов для мониторинга и обслуживания, чем мы имели бы в случае физических многоролевых серверов. А как мы видели выше, больше серверов будет обычно означать более высокие эксплуатационные расходы. То, что мы пытаемся в действительности сделать тут – это протащить решение виртуализации, в то время как к этому нет никаких предпосылок. Поймите меня правильно: я полностью поддерживаю и рекомендую виртуализированные решения для Exchange, когда требования заказчика таковы, что позволяют нам максимально использовать виртуализацию как средство, которое дает заказчику лучшее решение  за те деньги, которые он вкладывает, но когда заказчики хотят виртуализировать Exchange только потому, что они хотят виртуализировать абсолютно все, это представляет собой попытку засунуть круглый колышек в квадратное отверстие. Замечу, что следующая статья цикла Robert’s Rules будет о виртуализированном Exchange: когда это правильно, а когда нет.

Можно ли устанавливать многоролевые серверы на блейд-серверах?

Я рассматриваю этот вопрос точно так же, как и предыдущий вопрос про виртуализацию. Масштабы требований могут привести к тому, что предлагаемое решение выйдет за рамки, в которых блейд-серверы могут обеспечивать требуемые аппаратные ресурсы. Например, я видел случаи, когда аппаратные требования к многоролевых серверам были несколько больше, чем мог обеспечить блейд-сервер (думаю, это были 16-, 24- или 32-ядерные машины с 128 Гбайт памяти или что-то подобное). В общем, это означает, что если у вас очень высокая пользовательская нагрузка на эти серверы, вам придется уменьшить число ядер или требования к памяти, соответственно уменьшив количество пользователей на сервер. Как мы видели ранее, вы можете сделать это, увеличивая количество серверов или групп доступности баз данных.

Многоролевые серверы и программное выравнивание нагрузки

Мы все знаем про рекомендацию для Exchange 2010 использовать аппаратные выравниватели нагрузки, но фактом является и то, что использование Windows Network Load Balancing (WNLB – это программный выравниватель нагрузки, который входит в состав Windows Server 2008 и Windows Server 2008 R2, а также в более старые версии) поддерживается, и некоторые заказчики будут его использовать. Аппаратные выравниватели нагрузки стоят денег. Иногда в небольших проектах нет денег для приобретения аппаратных выравнивателей нагрузки, хотя существуют некоторые недорогие аппаратные выравниватели от партнеров Microsoft, которые могли бы обеспечить вам высокодоступное решение с аппаратным выравниванием за примерно 3 тыс. долларов. Так что я бы сказал, что существует очень мало заказчиков, которые не могут себе этого позволить.

Единственное реальное ограничение многоролевых серверов – это тот факт, что WNLB не поддерживается на том же сервере, на котором запущен Windows Failover Clustering. Хотя администраторы Exchange 2010 никогда не должны работать с  cluster.exe или любым другим инструментом управления кластером, группы доступности баз данных используют службы Windows Failover Clustering и такие его функции, как кворум и некоторые другие вещи. Это означает, что если у вас DAG с многоролевыми серверами, и вам требуется выравнивание нагрузки (а это нужно для любого решения с высокой доступностью), то вы будете вынуждены приобрести аппаратный выравниватель.

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

Расчет конфигурации для сред с многоролевыми серверами

Как мы уже обсудили, масштабирование многоролевых развертываний Exchange Server 2010 ненамного отличается от масштабирования, которое вы делаете сегодня. Калькулятор роли сервера почтовых ящиков рассчитан на поддержку такой конфигурации. Просто выберите Yes – второй параметр сверху слева на странице Input (по крайней мере, он там в версии 14.4 калькулятора), и убедитесь, что загрузка вашего процессора не превышает 39%. Обратите внимание, что эти 39% основаны на том факте, что Microsoft рекомендует, чтобы максимальная загрузка процессора не превышала 80%. В действительности это произвольное число, которое выбрано Microsoft потому, что оно вполне безопасное – если мы даем рекомендации около этих  80%, и по какой-либо причине у вас загрузка на 10% больше той, на которую вы рассчитывали, то вы все еще будете в безопасности, потому что в худшем случае загрузка этих серверов будет 90%. Некоторые из наших заказчиков выбрали 90% как пороговое число, и это совершенно приемлемое число, когда вы знаете, что вы делаете, и какие риски связаны с вашей оценкой того, как ваши пользователи будут загружать серверы Exchange и процессоры на них. В таблице калькулятора будут красные флаги, но только для того, чтобы вы видели, что есть что-то, что превышает наши эталонные 80%.

К чему приводит совмещение ролей?

Есть некоторые технические отличия в том, как работает Exchange, и как вы будете управлять им в случаях многоролевой и раздельной реализации. Например, когда роли сервра почтовых ящиков и транспортного сервера-концентратора сосуществуют на одной машине, то они знают об этом сосуществовании. В этом сценарии, когда пользователь посылает сообщение, служба Mailbox Submission роли сервера почтовых ящиков по возможности будет выбирать роль транспортного сервера-концентратора на другой машине в том же сайте Active Directory для того, чтобы передать сообщение для доставки (она будет выбирать роль транспортного сервера-концентратора на своей же машине только в том случае, если не существует другой роли транспортного сервера-концентратора в этом же сайте AD). Это позволяет  Exchange как системе устранять критическую точку отказа, когда сообщение направляется из  почтовой базы сервера для доставки на ту же самую машину, и при этом эта машина выходит из строя, не позволяя теневому дублированию обеспечивать надежность доставки. Обратное также верно – если сообщение приходит извне сайта на транспортный серве-концентратор, который совмещен с ролью сервера почтовых ящиков, где расположен почтовый ящик назначения, то сообщение будет перенаправлено по возможности другой роли транспортного сервера-конценстратора, чтобы обеспечить надежность доставки. Дополнительная информация содержится в документации ("Сосуществование ролей транспортного сервера-концентратора и сервера почтовых ящиков при использовании групп обеспечения доступности баз данных").

Другая вещь, которую надо принять во внимание, заключается в том, что когда вы проектируете вашу группу доступности баз данных, вы всегда должны определять, где будет располагаться файловый ресурс-свидетель. Когда вы создаете DAG с помощью командлета New-DatabaseAvailabilityGroup, вы можете не указывать параметры WitnessDirectory и WitnessServer. В этом случае Exchange выберет сервер и папку для вашего ресурса-свидетеля, как правило, на транспортном сервере-концентраторе. В том случае, когда все транспортные серверы-концентраторы в сайте Active Directory входят в DAG, это создает проблему! Где вы разместите файловый ресурс-свидетель? Мое решение в том, чтобы иметь другую машину (возможно виртуальную, но если так, то на другом оборудовании, чем ваши DAG серверы), чтобы размещать сетевую папку. Это могла бы быть машина, используемая как файловый сервер, сервер печати или что-то подобное. Я не стал бы рекомендовать сервер глобального каталога или контроллер домена, потому что как администратор я против сетевых папок на моих контроллерах домена по причинам безопасности, и я не хочу наделять мою группу безопасности Exchange Trusted Subsystem привилегиями доменного администратора!

Существуют также некоторые сценарии управления, которые вам следует принять в расчет. Например, когда вы обновляете многоролевой сервер, вы должны изменить ваши планы обновлений по сравнению с тем, как вы обновляете Exchange 2003 или 2007. Дополнительная информация – в моей статье Patching the Multi-Role Server DAG.

Вам придется настраивать Exchange совершенно одинаково и в случае разделения ролей, и в случае их совмещения. Суть отличий сводится к тому, что мы уже обсуждали: масштабирование серверов, простота в проектировании вашей реализации, простота управления серверами и в большинстве случаев экономия из-за уменьшения количества серверов и более простого управления. Отказ от многоролевых архитектур Exchange 2010 создает сложности в вашей системе, которые в большинстве случаев не оправданы, создает дополнительные затраты и увеличивает уровень риска при реализации Exchange (помните, что любая сложность увеличивает и риск, независимо от степени сложности и уровня риска).

Выводы

Выводы те же самые, которые мы делали не раз. Проект Exchange Server 2010 нужно всегда начинать с самого простого решения – многоролевых серверов с хранилищем JBOD (диски с прямым подключением без RAID). Отходите от этого простейшего решения только тогда, когда для этого есть реальная причина. Как я уже писал, я всегда начинаю обсуждение проекта с многоролевых серверов, и это решение рекомендует команда Exchange.

Если это рекомендация, то почему решение Robert’s Rules не использует многоролевые серверы?

Когда я начал разрабатывать эту серию статей, идея заключалась в том, чтобы показать решение с выравниванием нагрузки. В то время у нас не было доступных виртуализированных версий аппаратных выравнивателей нагрузки, по крайней мере не было для Hyper-V. С момента начала этой серии KEMP выпустил свой выравниватель нагрузки для Hyper-V, и я собираюсь упомянуть его в этом блоге. Росс Смит IV не раз повторял мне, что он не видит пользы в описании решения на базе Windows Network Load Balancing, т.к. мы настоятельно рекомендуем для больших проектов аппаратные выравнивателя нагрузки.

Итак…

Я собираюсь перепроектировать мою реализацию Exchange 2010 в Robert’s Rules под многоролевые серверы. Перед написанием следующей статьи (о виртуализации Exchange, как я уже написал выше) я переделаю сценарий, в котором теперь будет 4-узловая DAG – 2 узла в центре обработки данных HSV, 2 узла в центре обработки данных LF.

И еще раз спасибо всем вам за чтение этих статей! Присылайте ваши вопросы и комментарии!!

Роберт Джиллис

Перевод: Илья Сазонов, MVP

Comments

  • Anonymous
    January 01, 2003
    Спасибо вам, что используете Exchange и изучаете (почти) первоисточники уникальной информации.

  • Anonymous
    May 05, 2011
    Отличная статья. Спасибо за перевод =)