Jaa

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

  • Artikkeli

Группы высокой доступности (Database Availability Group, DAG) вместе с копиями баз могут обеспечивать автоматическое восстановление при различных авариях серверов, хранилищ, сети и другого оборудования. DAG может также обеспечивать устойчивость сайтов, так что вы можете выполнять переключение между центрами обработки данных во время отказа на уровне сайтов.  Но даже такое комплексное, рациональное и  устойчивое к сбоям решение, как DAG, не может защитить вас от всех возможных аварий, включая аварии, которые воздействуют на всю DAG целиком. Например, рассмотрим DAG из двух членов, расположенных в одном центре обработки данных. Если он подвергается наводнению, пожару или другой катастрофе, которая разрушает DAG, то  всю DAG целиком нужно будет восстановить с нуля. Как вы это сделаете?

Некоторое время назад на TechNet мы опубликовали техническую статью, написанную Тимом МакМайклом и озаглавленную Rebuild an Entire Database Availability Group. В этой статье Тим описывает, как перестроить DAG, которая была полностью потеряна. Он проводит вас через весь процесс, шаг за шагом, включая примеры, сопровождающие этот путь. Подробности ищите в этой прекрасной статье.

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

Наше старое указание:

• Независимо от географического расположения DAG полная сетевая задержка (туда-обратно) между любыим ее членами не должна превышать 250 мс.

Наше новое указание:

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

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

Существует другое изменение в указании по поддержке, которое мы сделали недавно (хотя документация еще не обновлена, т.к. изменение внесено после того, как соответствующий документ был обновлен в последний раз) относительно использования Bitlocker на членах DAG. Наше старое указание (которое будет оставаться на TechNet до следующего цикла обновления, хотя действует уже новое указание) было:

• Кластеры Windows не могут работать с BitLocker.

Наше новое указание (и обновленная статья после публикации ) гласит:

• Кластеры Windows требуют Windows 2008 R2 и хотфикс  KB2446607 (или очередной сервис-пак).   Тома Exchange с включенным BitLocker не поддерживаются на кластерах Windows при работе на более ранних версиях Windows.

Это означает, что если ваша DAG работает на Windows Server 2008 R2 или более поздней, то как только вы загрузите и установите QFE2446607, будет поддерживаться использование BitLocker на томах баз и журналов Exchange в DAG.

Скотт Шнолль

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