Общие сведения о факторах высокой доступности

 

Применимо к: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Последнее изменение раздела: 2015-03-09

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

• Будет ли выполняться развертывание нескольких копий базы данных?

• Сколько копий базы данных планируется развернуть?

• Будет ли архитектура обеспечивать устойчивость сайтов?

• Какой тип модели устойчивости сервера почтовых ящиков будет развертываться?

• Сколько серверов почтовых ящиков планируется развернуть?

• Каким образом будут распределяться копии баз данных?

• Какая модель резервного копирования будет использоваться?

• Какая архитектура хранилища будет использоваться?

Система Microsoft Exchange Server 2010 позволяет развертывать инфраструктуру сервера почтовых ящиков с помощью серверов почтовых ящиков, которые являются автономными или настроены на обеспечение устойчивости почтовых ящиков. Для серверов второго типа применяется группа обеспечения доступности баз данных (DAG) с несколькими копиями баз данных, эффективно распределяемыми через группу DAG. Развертывание нескольких копий баз данных позволяет:

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

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

• Использовать вместо традиционной конфигурации RAID альтернативные архитектуры хранилища, например JBOD (простой массив дисков), при развертывании трех и более копий баз данных. Сочетание массива JBOD и менее дорогих дисков позволяет добиться экономии в организационных расходах.

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

Дополнительные сведения см. в разделах Планирование высокой доступности и устойчивости сайтов и Общие сведения об архивации, восстановлении и аварийном восстановлении.

Содержание

Планирование количества развертываемых копий баз данных

Типы копий баз данных

Устойчивость сайтов

Планирование модели устойчивости для сервера почтовых ящиков

Планирование количества развертываемых серверов почтовых ящиков

Планирование структуры копии базы данных

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

Планирование архитектуры модели хранилища

Необходимы сведения о задачах управления, связанных с обеспечением высокой доступности? См. раздел Управление высокой доступностью и устойчивостью сайтов.

Планирование количества развертываемых копий баз данных

Как обсуждалось в разделе Общие сведения о копиях базы данных почтовых ящиков, член группы обеспечения доступности баз данных (DAG) может размещать одну копию каждой базы данных почтовых ящиков, причем не более 100 баз данных на сервер в выпуске Enterprise Edition данного продукта (учитываются как активные, так и пассивные копии). Это означает, что существует предельное значение 1600 для количества баз данных, поддерживаемых группой DAG с 16 членами (100 копий баз данных на сервер х 16 серверов на группу DAG = 1600 баз данных на группу DAG).

В конфигурации с высокой доступностью отсутствует смысл в развертывании одной копии базы данных, так как она не обеспечивает избыточность данных. Для определения числа баз данных, которое может поддерживать заданная группа DAG, используется определенная формула. Например, если D — число развертываемых баз данных, C — число копий каждой базы данных, а S — число серверов, то применяются следующие формулы:

• D × C = общее число копий баз данных в группе DAG

• (D × C) ÷ S = число копий баз данных на сервер

Примечание.
Результирующее количество баз данных на сервер не должно превышать 100 при использовании выпуска Enterprise Edition или не более 5 — для выпуска Standard Edition.

Например, допустим, что имеется группа DAG с 6 серверами и 84 базами данных почтовых ящиков с 3 копиями для каждой базы данных. (Заметьте, что число серверов 6 кратно 3 — числу копий.) Применив формулы, получим следующее:

• 84 базы данных × 3 копии = всего 252 базы данных

• 252 базы данных ÷ 6 серверов = 42 копии баз данных на сервер

В другом примере допустим, что имеется группа DAG с 4 серверами и 136 базами данных почтовых ящиков с 3 копиями для каждой базы данных. Применив формулы, получим следующее:

• 136 баз данных × 3 копии = всего 408 баз данных

• 408 баз данных ÷ 4 сервера = 102 копии баз данных на сервер

Так как 102 больше, чем 100, то предлагаемый сценарий не является допустимым проектом группы DAG.

В начало

Типы копий баз данных

Существует два типа копий баз данных:

• высокодоступные копии баз данных;

• изолированные копии баз данных.

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

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

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

Дополнительные сведения о блокировке активации на уровне сервера почтовых ящиков или приостановке активации для одной или нескольких копий базы данных с целью предотвращения автоматической активации копии базы данных (например, изолированной) см. в разделах Set-MailboxServer и Suspend-MailboxDatabaseCopy.

В начало

Устойчивость сайтов

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

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

• модель распределения пользователей «активный-пассивный»;

• модель распределения пользователей «активный-активный».

Если почтовые ящики пользователей располагаются главным образом в одном центре обработки данных (или если пользователи получают доступ к своим данным через один центр), а в соглашении об уровне обслуживания также имеется требование к пользователям, заключающееся в том, что они должны продолжать получать доступ через основной центр при выполнении стандартных операций, то данная архитектура относится к модели «активный-пассивный».

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

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

Модель распределения пользователей «активный-пассивный» с двумя центрами обработки данных

Архитектура, показанная на следующем рисунке, потенциально может использоваться и для модели «активный-активный».

Модель распределения пользователей «активный-активный» с двумя центрами обработки данных

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

Чтобы снизить риск для моделей распределения пользователей «активный-активный», рекомендуется развертывать две группы DAG, как показано на следующем рисунке.

Две группы DAG для модели распределения пользователей «активный-активный»

В группе DAG1 размещаются активные почтовые ящики для центра обработки данных в Редмонде, здесь реализована модель «активный-пассивный», а пассивные копии баз данных развертываются в центре в Портленде. В группе DAG2 размещаются активные почтовые ящики для центра обработки данных в Портленде, здесь реализована модель «активный-пассивный», а пассивные копии баз данных развертываются в центре в Редмонде.

Данная архитектура может выдерживать потерю глобальной сети:

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

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

Дополнительные сведения см. в разделе Планирование высокой доступности и устойчивости сайтов.

В начало

Планирование модели устойчивости для сервера почтовых ящиков

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

Модель для всех активированных копий баз данных

При этой архитектуре сервера обрабатывается 100% всех размещенных копий баз данных, которые становятся активными. Например, если на сервере размещено 35 копий баз данных, то процессор и память проектируются для обслуживания всех 35 баз данных, активных в период максимальной активности пользователей. Это решение обычно развертывается в парном варианте. Например, если развертываются четыре сервера, то одну пару серверов образуют серверы 1 и 2, а другую — серверы 3 и 4. Помимо этого, в процессе разработки этого сценария необходимо определять размер каждого сервера с учетом того требования, что для стандартных операций выделяется не более 40 процентов доступных ресурсов.

Из двух моделей, обсуждаемых в этом разделе, эта имеет более высокое число серверов.

Модель для целевых сценариев сбоя

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

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

• Проект на случай сбоев на автоматическом одиночном сервере в конфигурациях группы DAG с двумя или тремя членами и двумя высокодоступными копиями баз данных на каждую базу данных почтовых ящиков.

• Проект на случай сбоев на двух серверах (ручная активация после второго сбоя) в конфигурациях группы DAG с тремя членами и тремя высокодоступными копиями баз данных на каждую базу данных почтовых ящиков.

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

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

Ограничить количество баз данных можно, настроив параметр максимального количества активных баз данных. Этот параметр можно настроить в командной консоли Exchange, выполнив командлет Set-MailboxServer -MaximumActiveDatabases. Это значение настраивается для каждого сервера в группе обеспечения доступности баз данных в соответствии с максимальным количеством активных баз данных, поддерживаемым в данном развертывании.

Дополнительные сведения см. в разделе Примеры проектов группы доступности базы данных.

В начало

Планирование количества развертываемых серверов почтовых ящиков

При определении количества развертываемых серверов почтовых ящиков искомое число должно быть кратным количеству развертываемых копий баз данных. Например, если предполагается развернуть три копии базы данных, проектирование следует начинать со значений 3, 6, 9, 12 или 15 серверов.

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

Одно из ограничений проекта, имеющееся во многих организациях, — это максимальное количество почтовых ящиков, которое можно разместить на сервере. Например, если в организации имеется 20 000 почтовых ящиков и только 25 процентов из них могут испытывать влияние в случаях сбоев, то максимальное количество почтовых ящиков, которое можно развернуть на одном сервере, равно 5000. Для этого требуется развернуть не менее четырех серверов почтовых ящиков.

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

Сравнение серверов с несколькими ролями и серверов с автономной ролью

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

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

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

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

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

Дополнительные сведения см. в разделе Общие сведения о нескольких конфигурациях ролей сервера при планировании загрузки.

В начало

Планирование структуры копии базы данных

Один из этапов проектирования системы с высокой доступностью заключается в выборе структуры копии базы данных. При планировании структуры копии базы данных необходимо использовать следующие принципы проектирования.

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

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

Дополнительные сведения см. в разделе Проектирование структуры копии базы данных.

В начало

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

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

Проблема	Уменьшение отрицательных последствий
Сбои ПО	Устойчивость почтовых ящиков (несколько копий базы данных)
Сбои оборудования	Устойчивость почтовых ящиков (несколько копий базы данных)
Сбои на сайтах или в центрах обработки данных	Устойчивость почтовых ящиков (несколько копий базы данных)
Случайное или умышленное удаление элементов	Восстановление одного элемента и хранение удаленных элементов с временным окном, которое удовлетворяет требованиям соглашения об уровне обслуживания для восстановления элементов или превышает их
Сценарии физического повреждения	Восстановление одной страницы (высокодоступные копии базы данных)
Сценарии логического повреждения	Восстановление одного элемента Помощник по восстановлению календаря Перемещения почтовых ящиков Командлет New-MailboxRepairRequest Резервная копия на определенный момент времени
Административные ошибки	Резервная копия на определенный момент времени
Ошибки программирования	Резервная копия на определенный момент времени
Администраторы без полномочий	Резервная копия на определенный момент времени (изолированная)
Требования по соответствию корпоративным или регулятивным нормам	Резервная копия на определенный момент времени (изолированная)

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

• При восстановлении отдельного элемента, если пользователь изменяет определенные свойства элемента в какой-либо папке почтового ящика, то копия этого элемента сохраняется в папке «Элементы для восстановления» до того, как изменение будет записано в базу данных. Если изменение сообщения приводит к повреждению копии, то исходный элемент может быть восстановлен.

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

• Во время перемещения почтовых ящиков служба репликации почтовых ящиков Exchange обнаруживает поврежденные элементы и в таких случаях не перемещает их в целевую базу данных почтовых ящиков.

• В версии Exchange 2010 с пакетом обновления 1 (SP1) представлен командлет New-MailboxRepairRequest, который может устранять повреждения в папках поиска, ошибки в значениях количества элементов, представлениях папок и неполадки в родительских/дочерних папках.

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

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

• Развертывание изолированных копий баз данных имеет определенные последствия для хранилищ. Для журналов транзакций в изолированной копии базы данных необходимо выделить дополнительное место в связи с параметрами ReplayLagTime. Помимо этого, размещение изолированной копии может оказывать влияние на архитектуру хранилища. (Дополнительные сведения см. в подразделе «Планирование архитектуры модели хранилища» далее в этом разделе.)

• Развертывание традиционного решения резервного копирования имеет некоторые последствия для формата логического номера устройства (LUN), в зависимости от типа решения службы теневого копирования томов (VSS), так как для аппаратных решений клонирования VSS требуются два номера LUN на каждую архитектуру базы данных.

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

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

Дополнительные сведения о планировании резервных копий см. в следующих разделах:

• Общие сведения об архитектуре LUN в Exchange 2010

• Общие сведения о факторах для базы данных почтовых ящиков и свободного места для журналов

• Общие сведения о восстановлении календаря

• Общие сведения об элементах для восстановления

В начало

Планирование архитектуры модели хранилища

Система Exchange 2010 обеспечивает гибкость при проектировании хранилища. Сервер Exchange 2010 улучшен с точки зрения производительности, надежности и высокой доступности, что позволяет организациям применять систему Exchange для широкого спектра устройств хранения. Благодаря усовершенствованию дисковой системы ввода-вывода, представленной в версии Exchange 2007, в последней версии Exchange предъявляются не такие высокие требования к производительности хранилища и обеспечивается большая устойчивость к его сбоям.

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

Массив RAID или JBOD

Определите, следует ли реализовывать платформу хранилища, используя технологию RAID или подход JBOD (при том условии, что платформа хранилища допускает применение конфигураций JBOD). С точки зрения системы Exchange, массив JBOD подразумевает хранение базы данных и связанных с ней журналов на одном диске. Чтобы выполнить развертывание в массиве JBOD, необходимо развернуть не менее трех высокодоступных копий базы данных. Использование одного диска — это единственная точка сбоя, поскольку при сбоях на диске теряется копия базы данных на этом диске. Наличие не менее трех копий базы данных гарантирует отказоустойчивость благодаря остальным двум копиям в тех случаях, когда в одной из копий (или на диске) возникает ошибка. Тем не менее, размещение трех высокодоступных копий базы данных, так же как и использование изолированных копий базы данных, может оказывать влияние на проект хранилища. В следующей таблице приводятся указания по выбору технологии RAID или JBOD.

Рекомендации по выбору технологии RAID или JBOD

Серверы для центров обработки данных	Две высокодоступных копии (всего)	Три высокодоступных копии (всего)	Две или более высокодоступных копии на каждый центр обработки данных	Одна изолированная копия	Две или более изолированных копии на каждый центр обработки данных
Серверы для основного центра обработки данных	RAID	RAID или JBOD (2 копии)	RAID или JBOD	RAID	RAID или JBOD
Серверы для дополнительного центра обработки данных	RAID	RAID (1 копия)	RAID или JBOD	RAID	RAID или JBOD

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

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

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

Дополнительные сведения см. в разделе Общие сведения о конфигурации хранения.

В начало

 © Корпорация Майкрософт (Microsoft Corporation), 2010. Все права защищены.