Заблуждения о высокой доступности в Exchange 2010

Оригинал статьи опубликован во вторник 31 мая 2011 г.

Недавно я вернулся с конференции TechEd North America 2011, которая проходила в Атланте, штат Джорджия, где я прекрасно провел время со старыми и новыми друзьями, а также обсуждал с заказчиками и партнерами мою любимую тему – высокую доступность в Exchange Server 2010. Если вы пропустили TechEd, или были там, но пропустили некоторые сессии, то вы можете загрузить слайды и посмотреть презентации на Channel 9.

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

Терминология высокой доступности и отказоустойчивости сайтов в Exchange 2010

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

Итак, с терминами покончили.

Заблуждения о высокой доступности и отказоустойчивости сайтов в Exchange 2010

Давайте обсудим и развеем эти заблуждения в произвольном порядке.

Заблуждение номер 1: альтернативный следящий сервер (Alternate Witness Server, AWS) дублирует следящий сервер (Witness Server, WS)

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

Хотя вы можете настроить альтернативный следящий сервер (и соответствующую альтернативный следящий каталог) для DAG в любое время, альтернативный следящий сервер не будет использоваться этой DAG до тех пор, пока не произойдет переключение между центрами, особенно когда используется командлет Restore-DatabaseAvailabilityGroup.

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

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

Заблуждение номер 2: Microsoft рекомендует размещать следящий сервер в третьем центре обработки данных в случае, если состоящая из двух членов распределена между двумя центрами обработки данных

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

Рисунок 1: Когда группа доступности баз данных распределяется между двумя центрами обработки данных, размещайте следящий сервер в основном

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

Рисунок 2: В случае отключения WAN член DAG в основном центре обработки данных будет поддерживать кворум и обслуживать локальных пользователей

Причина такого поведения кроется в сути того, что есть кворум и группы DAG, в частности:

• Все группы DAG и их члены требуют кворум для своей работы. Если у вас нет кворума, то у вас не будет работоспособной группы доступности. Если кворум потерян, то базы размонтируются, связность невозможна и репликация останавливается.
• Кворум требует большинства голосов, чтобы достигнуть консенсуса. Таким образом, если у вас в DAG четное количество членов, вам необходим внешний компонент, чтобы предоставить решающий голос для одного из участников голосования, чтобы избежать равенства голосов.
  • В Windows Failover Cluster только члены кластера имеют голос. Когда кластер теряет одного голосующего члена, то для поддержания кворума нужен следящий сервер, тогда один из членов DAG, который может связаться со следящим сервером, размещает блокировку Server Message Block (SMB) на файле witness.log, который расположен в следящем каталоге. Член DAG, который размещает блокировку SMB, называется блокирующим узлом. Как только блокировка SMB установлена, ни один другой член DAG не может ее установить.
  • Блокирующий узел при этом обретает право решающего голоса, т.е. он голосует не один раз, а два (за себя и за следящий сервер).
  • Если те члены кластера, которые могут общаться с блокирующим узлом, составляют большинство, то они вместе с блокирующим узлом будут поддерживать кворум и продолжать обслуживать клиентов. Члены DAG, которые не могут общаться с блокирующим узлом, оказываются в меньшинстве, теряют кворум и прекращают работу с DAG.
• Формула большинства для поддержания кворума выглядит как V /2 + 1, результат который всегда есть целое число. Формула равна число голосующих (V) деленное на 2, плюс 1 (для устранения равенства голосов).

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

Рисунок 3: Размещение следящего сервера в третьем центре обработки данных никак не меняет алгоритм переключения

Эта конфигурация никак не меняет алгоритм переключения. В случае потери связи по WAN между Портлендом и Редмондом один член DAG сохранит кворум, а другой потеряет его, как показано ниже:

Рисунок 4: В случае потери связи по WAN между двумя центрами обработки данных один член DAG сохранит кворум

Здесь у нас два члена DAG и, следовательно, два голосующих. Согласно формуле V /2 + 1 нам необходимы по крайней мере 2 голоса, чтобы поддерживать кворум.Если соединение по WAN между Портлендом и Редмондом потеряно, это заставит кластер, лежащий в основе DAG, проверить, сохранился ли кворум.

В этом примере член DAG в Портленде разместил блокировку SMB на файле witness.log, расположенном на сервере слежения в Олимпии. Т.к. член DAG в Портленде является блокирующим узлом, он получает решающий голос, и поэтому теперь обладает двумя голосами, необходимыми, чтобы удержать кворум и сохранить свой кластер и свою группу доступности в рабочем состоянии.

Хотя член DAG в Редмонде может связаться со следящим сервером в Олимпии, он не может разместить блокировку SMB на файле witness.log, т.к. она уже существует. И т.к. он не может взаимодействовать с блокирующим узлом, то он оказывается в меньшинстве, теряет кворум и прекращает работу с кластером и DAG. Помните, что не важно, могут ли другие члены DAG взаимодействовать со следящим сервером: им нужно только взаимодействовать с блокирующим узлом для того, чтобы участвовать в кворуме и оставаться в рабочем состоянии.

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

Заблуждение номер 2a: если у нас DAG с четным количеством членов, распределенных между двумя центрами обработки данных, то размещение следящего сервера в третьем центре повышает надежность

В дополнение к Заблуждению номер 2 существует похожее на него заблуждение в том, что размещение четного количества членов DAG в двух центрах обработки данных и использование следящего сервера в третьем дает бОльшую надежность, т.к. позволяет настроить систему так, чтобы она выполняла аварийное переключение центров обработки данных (datacenter failover). Вы могли заметить, что термина «аварийное
переключение датацентров» (datacenter failover) в приведенном выше списке терминов нет. С точки зрения Exchange такого понятия нет. В результате нет такой конфигурации, которая бы выполняля аварийное переключение центров обработки данных для Exchange.

Помните, что аварийное переключение – это корректирующее действие, автоматически выполняемое системой. Для Exchange 2010 нет механизма для аварийного переключения центров обработик данных. В то время как вышеприведенная конфигурация может обеспечить
аварийное переключение серверов и почтовых баз, она не может выполнять аварийное переключение центров обработки данных. Напротив, процесс восстановления при отказе центра является ручным процессом, называемым переключением центра обработки данных (datacenter switchover), и этот процесс всегда начинается с человека, принимающего решение активировать резервный центр.

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

Как только решение об аварийном переключении центров принято, само переключение – это прямолинейный процесс, хорошо описанный в статье Переключения центра обработки данных.

Заблуждение номер 3: Включение режима DAC предотвращает автоматическое
переключение между центрами обработки данных, поэтому для создания конфигурации с автоматическим переключением центров обработки данных при отказе не нужно включать режим DAC в DAG

Режим координации активации центра обработки данных (Datacenter Activation Coordination, DAC) никак не связан с аварийным переключением. Режим DAC – это свойство DAG, которое, будучи включенным, заставляет членов DAG в момент запуска перехватывать права других членов DAG и монтировать почтовые базы. Режим DAC был создан для следующего сценария:

• У вас группа доступности, распределенная  между двумя центрами обработки данных;
• Потеряно питание в основном центре, что также привело к потере канала WAN между основным и резервным центрами;
• Т.к. питание отсутствует достаточно долго, вы решаете активировать резервный центр и выполняете процедуру переключения центров;
• Неожиданно питание в основном центре восстанавливается, но канал WAN между центрами еще не работает;
• Члены DAG, которые запускаются в основном центре, не могут связаться с членами DAG в резервном.

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

Способ монтирования почтовых баз в Exchange 2010 был изменен. Да, Information Store все еще выполняет монтирование, но делает он это только по просьбе  Active Manager. Даже когда администратор выбирает в EMC команду MountDatabase, он обращается к Active Manager, который предоставляет административный интерфейс для этой задачи и выполняет запрос RPC в Information Store для того, чтобы выполнить монтирование (даже для серверов почтовых ящиков, которые не входят в DAG).

Таким образом, когда член DAG запускается, именно Active Manager решает, посылать ли запрос на монтирование почтовой базы в Information Store. Если в DAG включен режим DAC, его процесс запуска изменяется службой Active Manager таким образом, что в режиме DAC стартующий член DAG должен попросить разрешения у других членов DAG перед тем, как он сможет смонтировать базу.

Режим DAC использует бит памяти в Active Manager, называемый Datacenter Activation Coordination Protocol (DACP). Это замысловатое название просто обозначает бит памяти, который принимает значение 0 или 1. Значение 1 означает, что Active Manager может отправлять запросы на монтирование, а значение 0, что не может.

Начальное значение бита всегда 0, и т.к. это бит памяти, то всякий раз, когда служба Microsoft Exchange Replication (MSExchangeRepl.exe) останавливается или перезапускается, этот бит сбрасывается в 0. Чтобы установить бит DACP в 1 и получить возможность монтировать базы, стартующий член DAG должен:

• Или иметь возможность взаимодействовать с любым другим членом DAG, у которого бит DACP равен 1;
• Или иметь возможность взаимодействовать со всеми членами  DAG, которые перечислены в свойстве StartedMailboxServers.

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

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

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

Кстати, как описано в документации на TechNet в статье Общие сведения о режиме координации активации центра обработки данных, еще одно полезное свойство режима DAC заключается в том, что он дает вам возможность использовать встроенные в Exchange средства обеспечения устойчивости сайтов.

Заблуждение номер 4: параметр AutoDatabaseMountDial контролирует, сколько файлов журналов отбрасываются системой при монтировании базы

Это случай, когда две независимые функции объединились в форме одного заблуждения: параметр AutoDatabaseMountDial и функция, известная как добавочная повторная синхронизация (Incremental Resync, также известная как Incremental Reseed v2). Эти функции действительно не связаны, хотя кажутся такими, т.к. они связаны с примерно одним и тем же количеством файлов журналов на различных копиях одной и той же базы.

Когда в DAG происходит отказ, который влияет на активную копию почтовой базы, пассивная копия активируется одним из двух способов: или автоматически системой, или вручную администратором. Автоматическое восстановление основано на параметре AutoDatabaseMountDial.

Как описано в статье Общие сведения о режиме координации активации центра обработки данных, этот параметр – способ для администратора указать члену DAG максимальное количество потерянных файлов журналов, при котором еще возможно монтирование копий баз. Значение по умолчанию равно BestAvailability, которое разрешает потерять до 12 файлов журналов. Это означает, что если из активной копии в пассивную не передалось 12 или менее файлов журналов, то сервер все еще сможет смонтировать эту копию как новую активную базу. Этот сценарий известен как потеря данных во время переключения при сбое (lossy failover),  и Exchange делает это так, как он спроектирован.

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

У нас две копии DB1; активная копия на EX1 и пассивная копия на EX2. Текущие настройки и статус почтовой базы следующий:

• AutoDatabaseMountDial: BestAvailability
• Copy Queue Length: 4
• Replay Queue Length: 0
• Last log generated by DB1\EX1: E0000000010
• Last Log Received by DB1\EX2: E0000000006

Теперь кто-то случайно выключает EX1, и у нас происходит потеря данных во время переключения, при этом DB1\EX2 монтируется как новая активная копия базы. Т.к. E0000000006 – это последний файл журнала, который есть на DB1\EX2, сервер продолжает генерировать файлы журналов E0000000007, E0000000008, E0000000009, E0000000010 и так далее.

Администратор узнает, что EX1 выключен и перезапускает его. EX1 загружается и запускает процесс Microsoft Exchange Replication. Служба Active Manager, которая запускается в этом сервисе, обнаруживает, что:

• DB1\EX2 была активирована с потерями
• DB1\EX2 – это активная копия
• DB1\EX1 – это теперь несинхронизированная пассивная копия

При любой потере данных во время переключения, когда есть пригодные для использования исходные активные копии, всегда существует различие в потоках файлов журналов, которые система должна учитывать. Это состояние заставляет DB1\EX1 автоматически запустить процесс, называемый повторной синхронизацией (resync), который создан на случай обнаружения различий в потоках файлов журналов. Его назначение – пересинхронизировать копии базы так, чтобы при определенных условиях отказа вам не пришлось бы выполнять полную повторную синхронизацию копии базы.

В нашем примере различие наступает при генерации файла E0000000007:

Рисунок 5: Различие в потоке файлов журналов наступает с файла журнала E0000000007

DB1\EX2 получала журналы с 1 по 6 с базы DB1\EX1, когда та была активной копией. Но после аварии журналы с 7 по 10 не были скопированы с EX1 на EX2. Таким образом, когда DB1\EX2 становится активной копией, она продолжает генерацию журналов с последнего файла, который она имела – то есть с файла 6. В результате DB1\EX2 генерирует свои собственные файлы 7-10, которые теперь содержат данные, которые отличаются от данных, содержащихся в файлах 7-10 базы DB1\EX1.

Чтобы обнаружить (и исправить) это различие, функция добавочной повторной синхронизации запускается с последнего файла (в нашем примере это файл 10) и сравнивает два файла копий баз, затем предыдущую пару и т.д. пока не найдет совпадающие копии. В нашем
примере это файл 6. Т.к. DB1\EX1 теперь является пассивной копей, и т.к. ее журналы с 7 по10 отличаются от журналов с 7 по 10 на DB1\EX2, которая теперь является активной копией, эти файлы журналов исключаются системой. Конечно, это не восстановит потерянных сообщений, т.к. они восстанавливаются через механизм Transport Dumpster.

Затем файлы журналов с 7 по 10 на DB1\EX2 реплицируются на DB1\EX1, и DB1\EX1 становится здоровой актуальной копией базы DB1\EX2, как показано ниже: 

Рисунок 6: Добавочная повторная синхронизация исправляет различие в потоке журналов

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

Как мы увидели в этом примере, хотя DB1\EX2 потерял четыре файла журналов, он все еще может смонтировать новую активную копию почтовой базы, т.к. число потерянных файлов журналов было в пределах значения AutoDatabaseMountDial, сконфигурированного на EX2. Также мы увидели, что для того, чтобы устранить различие в потоке файлов журналов после потери данных во время переключения, функция добавочной повторной синхронизации отбросила четыре файла журналов.

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

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

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

Но предположим, что на самом деле произошел отказ хранилища, и что мы вообще потеряли DB1\EX1. Без жизнеспособной базы добавочная повторная синхронизация тут не поможет, и все, что вы можете сделать – это выполнить операцию повторного заполнения (reseed).

Таким образом, как вы видите:

• AutoDatabaseMountDial не контролирует, сколько файлов журналов файлов отбрасывает система
• AutoDatabaseMountDial – это совершенно отдельный процесс, который не требует возможности или успеха добавочной повторной синхронизации
• Добавочная повторная синхронизация отбрасывает файлы журналов в ходе устранения различий, но не теряет сообщений из-за
  этого

Заблуждение номер 5: транспортныем серверам-маршрутизаторам и серверам клиентского доступа не нужно более 8 Гбайт памяти, т.к. при большем количестве памяти они работают медленнее

Обычно после этого следуют заявления вроде таких:

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

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

Возьмем максимальное число процессорных ядер, которое мы рекомендуем для сервера клиентского доступа или транспортного
сервера-маршрутизатора. Это 12. Теперь возьмем наши рекомендации по памяти: для сервера клиентского доступа это 2 Гбайт на ядро, и для транспортного сервера-маршрутизатора это 1 Гбайт на ядро. Таким образом, если у вас есть 12-ти ядерный сервер клиентского доступа, то вы можете установить 24 Гбайт памяти, а если у вас 12-ти ядерный транспортный сервер-маршрутизатор, то вы можете установить 12 Гбайт памяти.

Exchange 2010 – это высокопроизводительное, хорошо масштабируемое, эффективно использующее ресурсы приложение уровня предприятия. В нашем 64-разрядном мире, где постоянно увеличивается количество процессоров и ядер, а также гнезд памяти, Exchange 2010 безусловно спроектирован так, чтобы управлять гороздо большими объемами памяти, чем 4-6 Гбайт.

Внутренняя служба Microsoft IT (MSIT) знает из первых рук, как хорошо Exchange 2010 масштабируется за пределы 8 Гбайт. Как описано в документе Exchange Server 2010 Design and Architecture at Microsoft: How Microsoft IT Deployed Exchange Server 2010, MSIT внедрило одноролевые транспортные серверы-маршрутизаторы и серверы клиентского доступа с памятью по 16 Гбайт.

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

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

Как указано в вышеприведенной статье и как написано нами выше:

• Наши рекомендации по памяти для выделенного сервера клиентского доступа – это 2 Гбайт/ядро;
• Наши рекомендации по памяти для выделенного транспортного сервера-маршрутизатора – это 1 Гбайт/ядро.

Заблуждение номер 6: DAG из двух членов спроектирована для малых офисов с количеством почтовых ящиков менее 250

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

В действительности правильно  спроектированная группа доступности баз данных может разместить тысячи почтовых ящиков – далеко за 250 пользователей. Например, рассмотрим HP E5000 Messaging System for Exchange 2010. Это стандартное решение, которое использует DAG из двух членов для обеспечения решений высокой доступности для заказчиков с количеством почтовых ящиков от 250 до 15 000.

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

Вы слышали что-то еще?

Вы услышали какие-то другие заблуждения о высокой доступности в Exchange? Не стесняйтесь делиться ими со мной по электронной почте. Кто знает, может быть, это станет темой другой статьи в блоге!

Дополнительная информация

Ознакомьтесь с дополнительной информацией о высокой доступности и отказоустойчивости сайтов в Exchange Server 2010 на следующих
ресурсах:

Блогкасты

• High Availability in Exchange Server 2010, Part 1
• High Availability in Exchange Server 2010, Part 2
• High Availability in Exchange Server 2010, Part 3
• High Availability in Exchange Server 2010, Part 4

Документация TechNet

• Общие сведения о высоком уровне доступности и устойчивости сайта к сбоям
• Общие сведения о группах обеспечения доступности баз данных
• Общие сведения о копиях базы данных почтовых ящиков
• Общие сведения об Active Manager
• Общие сведения о режиме координации активации центра обработки данных
• Примеры проектов группы доступности базы данных
• Проектирование структуры копии базы данных
• Планирование высокой доступности и устойчивости сайтов
• Развертывание высокой доступности и устойчивости сайтов
• Управление высокой доступностью и устойчивостью сайтов
• Переключения и переходы на другой ресурс при сбое
• Переключения центра обработки данных

Презентации TechEd

• EXL312 Designing Microsoft Exchange 2010 Mailbox High Availability for Failure Domains – TechEd North America 2011
• EXL327 Real-World Site Resilience Design in Microsoft Exchange Server 2010?– TechEd North America 2011
• EXL401 Exchange Server 2010 High Availability Management and Operations – TechEd North America 2011
• UNC401 Microsoft Exchange Server 2010: High Availability Deep Dive (including changes introduced by SP1) – TechEd Europe 2010
• UNC302 Exchange Server 2010 SP1 High Availability Design Considerations – TechEd New Zealand 2010

Скотт Шноль (Scott Schnoll)

Это локализованная запись блога. Исходная статья находится по ссылке Exchange 2010 High Availability Misconceptions Addressed.

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