Кластеризация Exchange

Разбираюсь с кластеризацией Exchange 2007, иногда перевожу куски статей для личного пользования. по предложению Бурята выкладываю сюда некоторые куски, вдруг еще комунить понадобится =)

Нижеследующий текст - мой малопрофессиональный перевод содержательной части данной статьи: http://blogs.technet.com/mcs-ireland-infrastructure/archive/2007/12/20/what-s-new-in-exchange-2007-clustering.aspx
Переводить "воду" не люблю, потому придетсяо бойтись без авторских рассуждений.

4 новых системы кластеризации и 4 новых сокращения.
Ура – 4 новых сокращения, чтобы смущать наших коллег и начальников и выглядеть умным. Итак:
• SCC - Single Copy Cluster
• LCR - Local Continuous Replication
• CCR - Cluster Continuous Replication
• SCR - Standby Continuous Replication

Давайте рассмаотрим их поближе.

1. SCC - Single Copy Cluster – «Классическая кластеризация»

Изначальный тип кластеризации теперь известен как Single Copy Cluster. Это там, где мы обеспечиваем избыточность для наших серверов, но все еще имеем единую точку отказа – общие диски, содержащие кворум кластера, базы данных Exchange и логи. В E2007 основы работы данной системы не изменились, однако появилось некоторое число дополнений и улучшений. Вот наиболее важные из них:

• В предыдущих версиях, когда вы инсталлировали Exchange, вы все получали в одном решении и должны были отключать все, что вам не требовалось. Это распространялось и на кластера, и имело тенденцию приводить к появлению функционала, который никогда не использовался. В Е2007, используя концепцию ролей сервера, вы можете выбрать, какую роль вы хотите получить – хранилища, концентратора, пограничного сервера или сервера объединённых коммуникаций. В этом случае Single Copy Cluster (и все другие типы кластеров) распространяются только на роль сервера хранилища. Это упрощение крайне выгодно. Отказоустойчивость остальных ролей достигается другими методами – NLB и т.п.

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

• В прошлых версиях Single Copy Cluster требовал серьёзных навыков в администрировании кластеров и связанных с ними моментов. В Е2007 большая часть управления кластерами теперь часть Exchange Management Shell. Вам все еще требуется немного поработать администратором кластеров (или попросить кого-нибудь это сделать за вас), но вы можете контролировать процесс используя новые коммандлеты в EMS. Да, вам придётся учить EMS, но это не так уж и плохо.

2. Continuous Replication - LCR, CCR, SCR – Непрерывная репликация

В мире электронной почты принцип репликации приносит большую выгоду – вспомните о режиме кэширования Outlook. Репликация – это здорово, репликацию мы любим. Непрерывная репликация (CR), известная также как пересылка логов (log shipping) – это проверенная концепция корпоративных баз данных. Как это работает в Exchange? Вот так:

• Начиная с E2000, у нас были группы хранения и в каждой группе хранения базы данных и логи. В Е2007 все схоже, но с одной ключевой разницей, требующейся для поддержки CR – разрешена только одна база данных и один ассоциированный набор логов на каждую группу хранения (Вы можете иметь до 50 групп хранения). Это изменение облегчает пересылку логов, являющуюся «сердцем» CR.

• Используя CR, вы имеете «живую копию» ваших данных – обновляемую напрямую конечными пользователями. На диске (исключая то, что находится а памяти), это «изображается» суммой базы данных (.edb) и не подтверждённые транзакции в лог-файле. Это классический метод создания высоконадежных баз данных.

• Когда вы проводите первоначальный запуск CR (используя командлеты), вы берёте вашу работующую базу данных и копируете в другое место (лучше всего на разные физические диски, находящиеся на одном или даже на разных серверах). Как только файлы логов заполняются на рабочем сервере, непрерывно копируются в это новое местоположение и замещают старые. Этот способ позволяет поддерживать вашу рабочую и ожидающую базы данных практически идентичными (другое название – асинхронная пересылка логов). В E2007 размер файла лога уменьшен с 5 мегабайт до 1, что упрощает процесс – меньше лог, быстрее передаётся файл и меньше потенциальный разрыв между активным и пассивным узлом. Но как мне кажется, ваши пользователи не желают терять НИЧЕГО. Как этого добиться? В Е2007 есть решение – оно называется Transport Dumpster.

• Transport Dumpster – это компонент роли сервера-концентратора. Примерно это выглядит так – сервер-концентратор сохраняет копию каждого сообщения (только в ролях CCR, LCR) за определённый период. В случае экстренного восстановления новоактивированный кластер запрашивает у всех концентраторов передать все, что накопилось в Transport Dumpster’е. Если сообщение уже есть – его отбрасывают, если нет – доставляют. Это не гарантирует полной безопасности, но позволит вам в случае падения поднять почтовую систему с минимальными потерями данных.
LCR, CCR и SCR – это различные варианты этого решения со своими плюсами и минусами. В LCR репликация может производиться на самом сервере. В CCR используется другой вариант Windows Clustering, называемый Majority Node Set для создания 2-х нодового кластера. SCR можно комбинировать SCC, LCR и CCR для получения целого набора интересных возможностей.