Что является решающим фактором при внедрении нескольких групп доступности баз данных Exchange 2010 (DAG) вместо одной DAG?
Я использую инструмент HP для определения размера Exchange 2010, чтобы составить бюджет, и он спрашивает меня о количестве DAG. Мы собираемся нанять консультантов, чтобы разработать это, но мне просто нужна приблизительная оценка для целей планирования / составления бюджета.
Какая связь между количеством DAG и количеством серверов?
Это зависит от того, что вам нужно от DAG. У вас может быть несколько типов DAG - «нормальный» DAG и «Lagged Copy DAG», который больше используется для аварийного восстановления.
Сколько реплик у вас должно быть - это (на мой взгляд) больше бизнес-решение, чем ИТ-решение.
«Обычная» группа обеспечения доступности баз данных - это, по сути, копия указанных баз данных почтовых ящиков. У вас будет несколько реплик, если вы хотите, чтобы переключение при отказе происходило прозрачно для конечных пользователей. Это позволяет нескольким серверам Exchange выходить из строя (для обслуживания или иным образом) и поддерживать базу данных почтовых ящиков в оперативном режиме.
«Lagged Copy DAG» по-прежнему является группой DAG, которая реплицирует вашу базу данных почтовых ящиков, но немного другим способом. Вы можете установить период задержки для группы DAG с задержкой, чтобы реплика фактически была копией основной базы данных в какой-то момент в прошлом (по умолчанию 14 дней, IIRC). Как только файл журнала транзакций завершен (т. Е. Он достигает 1 МБ и создается другой) в вашей активной копии базы данных, он немедленно копируется во все отсроченные реплики. но не воспроизводится сразу. Этот журнал транзакций будет оставаться в изолированной реплике до истечения периода задержки, после чего он будет записан в базу данных изолированной копии.
Обладая этой информацией, вы сможете дать руководству представление о том, что Exchange может сделать в отношении высокой доступности / аварийного восстановления и, возможно, порекомендовать решение, но позволить им в конечном итоге решить.
Я еще не проголосовал за закрытие этого вызова, но я считаю, что это пограничный вопрос, поскольку на него нельзя "ответить" в его нынешней форме.
Высокая доступность субъективна и полностью зависит от ваших обстоятельств и того, что вы считаете приемлемым уровнем риска.
Вы не указали что-нибудь о вашем приемлемом уровне риска. Например, если вам нужна наименьшая форма HA, без устойчивости сайта, тогда вам понадобятся (2) две группы DAG. Если ваша глобальная сеть является единственной точкой отказа, то вам понадобятся (2) две четырехэлементные группы DAG в (2) двух разных центрах обработки данных.
Эта статья о Дизайн группы доступности базы данных неплохое начало.
Требования к производительности и доступности, в первую очередь, основаны на количестве пользователей, интенсивности использования серверов и возможном отказе ваших систем. Больше использования или точек отказа = больше групп DAG.