Одним из основных направлений разработки высокой доступности в Microsoft Exchange Server 2007 было решительное изменение практик и возможностей настройки высокой доступности, сложившихся в предыдущих версиях Exchange Server. Следуя структурированному процессу планирования с помощью Exchange 2007, можно понизить затраты на развертывание и эксплуатацию, в то же время предоставляя больше услуг конечным пользователям.
Решения высокой доступности в Exchange Server 2003 успешно развернуты в рабочей среде корпорацией Microsoft и многими клиентами, предоставляя высокодоступную среду обмена сообщениями. Вдобавок, многие клиенты успешно развернули технологию репликации партнеров и создали решения, автоматически переходящие на вторую копию данных при сбое. В состав Exchange 2007 входят улучшения старых решений высокой доступности, знакомых по Exchange 2003, и новые функции высокой доступности, устраняющие необходимость в технологиях репликации от сторонных производителей и понижающие стоимость и сложность решения в целом. Ключевыми причинами этих улучшений явились отзывы пользователей, сообщавших что:
- Требование общего хранилища для решения повысило стоимость и
сложность решения. Например, оборудование для всего решения надо
было выбирать из категории «Кластерные решения» в каталоге
прошедших испытания продуктов Windows Server. В
Exchange 2007 кластеры с единым хранилищем (SCC) сохраняют это
требование, но кластерные серверы почтовых ящиков, которые
настроены в среде кластерной непрерывной репликации, избавлены от
него.
- Использование единого хранилища для данных почтовых ящиков
означало, что сбои этих данных или их хранилища причиняли много
вреда, часто приводя к длительным отключениям и порой к потере
данных.
- Отсутствие интеграции в установке и управлении между службой
кластеров и Exchange Server заставляло администраторов
Exchange углубляться в концепции и функции кластеров. Это требовало
значительных усилий от некоторых администраторов Exchange.
- "Коробочные" параметры по умолчанию не были оптимальны для
восстановления. От администраторов требовалось вручную
перенастраивать параметры и ресурсы кластеров, чтобы следовать
практическим рекомендациям.
- Все серверы Exchange (клиентского доступа, транспортный и
хранения) использовали одну и ту же стратегию доступности, несмотря
на резкие различия в их архитектуре, включая разные стратегии
высокой доступности.
- Многим клиентам требовались партнерские технологии, чтобы
добиться решения, хранящего две копии их данных почтовых ящиков.
Эти решения увеличивали стоимость и сложность развертывания.
Решения высокой доступности в Exchange 2007 предназначены для устранения всех недостатков подхода Exchange 2003 к вопросу высокой доступности. Exchange 2007 устраняет их путем изменений в архитектуре, поддержки новых конфигураций, изменения в моделях управления и внедрения новых подходов к высокой доступности. Результатом является гибкое решение, предоставляющее каждой организации свободы выбора варианта решения, соответствующего ее нуждам.
Варианты развертывания высокой
доступности
Высокую доступность всегда следует разрабатывать как на уровне отдельных компонентов, так и в контексте всей системы или решения. Как правило, существует два типа вариантов развертывания высокой доступности для Exchange 2007:
- Развертывания с одним центром данных и избыточностью, которые
могут автоматически восстановиться после части сбоев, испытав
кратковременное отключение. В случае сбоя сайта такое решение
полагается на процедуры аварийного восстановления для возвращения в
оперативное состояние.
- Развертывания с несколькими центрами данных и избыточностью,
которые могут автоматически восстановиться после большинства
отдельных сбоев. Решение с несколькими центрами данных позволяет
организации пережить сбой центра данных, не обращаясь к процедурам
аварийного восстановления. Сбои, не поддающиеся восстановлению,
например полный сбой сайта, требуют человеческого вмешательства для
исправления.
Оба этих варианта развертывания подробно освещены ниже.
Конфигурации с одним центром данных
Конфигурации с одним центром данных для ролей транспортных серверов-концентраторов, серверов клиентского доступа, пограничных транспортных серверов и серверов единой системы обмена сообщениями включают настроенные сходным образом избыточные серверы. Для серверов почтовых ящиков имеется три конфигурации высокой доступности, предоставляющие данные и доступ к службам через единый центр данных: кластер с единым хранилищем (SCC), кластерная непрерывная репликация (CCR) и локальная непрерывная репликация (LCR). Следующий рисунок иллюстрирует общее развертываенние полностью избыточной конфигурации с одним центром данных.
На предыдущем рисунке конфигурация избыточности для роли сервера почтовых ящиков показана абстрактно. Это сделано потому, что для организации доступы несколько ее вариантов, включая набор конфигураций, использующих кластер с единым хранилищем и кластерную непрерывную репликацию.
Кластеры с единым хранилищем
Конфигурация кластера с общим хранилищем в Exchange 2007 называется кластером с единым хранилищем (SCC). Кластер с единым хранилищем использует службу кластеров и общее хранилище для размещения кластерного сервера почтовых ящиков. Кластерный сервер почтовых ящиков - логический компьютер, перемещающийся между физическими узлами на протяжении своего существования. Это возможно благодаря способности службы кластеров создавать перемещаемый сетевой идентификатор и управлять им. Перемещаемый сетевой идентификатор служит сетевым идентификатором кластерного сервера почтовых ящиков. Программа установки Exchange автоматически создает этот сетевой идентфикатор, используя имя узла и IP-адрес, предоставленные администратором. Перемещаемый сетевой идентификатор переходит от одного узла кластера к другому, основываясь на доступности узлов и нуждах обслуживания. Эти механизмы позволяют пользователям получать доступ к данным своих почтовых ящиков, пока хранилище доступно и по крайней мере один из двух узлов работоспособен. Exchange и служба кластеров вместе обеспечивают восстановление после сбоев, переводя кластерный сервер почтовых ящиков в оперативный режим на доступном узле после сбоя.
Ниже приведено несколько ключевых улучшений Exchange 2007 по сравнению с кластерами с общим хранилищем, присутствовавшими в предыдущих версиях Exchange Server:
- Только роль сервера почтовых ящиков поддерживает кластеры, и
это единственная роль, которая может быть установлена в
отказоустойчивом кластере.
- Стандартное поведение кластера при перемещении при сбое
оптимизировано, чтобы перемещение происходило лишь при наличии
высокой вероятности улучшения доступности за счет этого. Только
полный сбой узла или его неспособность связываться с клиентами
приводят к перемещению.
- Основная часть администирования была передана от программы
«Администратор кластера» средствам Exchange, таким как командная
консоль Exchange. Это упрощает освоение работы администраторам
кластера с единым хранилищем.
- Установка кластерного сервера почтовых ящиков интегрирована в
программу установки, обеспечивая такой же свособ работы, как и при
отдельной установке.
На следующем рисунке изображена обычная конфигурация для кластера с единым хранилищем. Кластер с единым хранилищем поддерживает кластеры, имеющие до восьми узлов, из которых как минимум один должен быть пассивным.
Рисунок 2. Базовая архитектура кластера с единым хранилищем
На предшествующем рисунке два узла связаны в отказоустойчивый кластер. Кластер использует общий диск для управления ресурсом кворума кластера, который представлен диском Quorum. Активный узел владеет ресурсами диска в настоящий момент и размещает журналы кластерного сервера почтовых ящиков, а также файлы базы данных. Это владение отмечено синими линиями от активного узла к дискам. В данной конфигурации диски доступны для активного узла, но не для пассивного одновременно.
Активный и пассивный узлы подключены друг к другу как минимум двумя сетями (частной и смешанной). Только одна из двух сетей используется для связи с клиентами (смешанная) Служба кластеров регулярно проверяет работоспособность связи обоих сетей.
Дополнительные сведения о кластерах единой копии приведены в разделе Кластеры единой копии.
Кластерная непрерывная репликация
Как подразумевает его название, кластер с единым хранилищем хранит лишь одну копию данных почтовых ящиков. Сбой хранилища, где размещены почтовые ящики, не завершается автоматическим восстановлением. На деле такой сбой обычно приводит к продолжительной неработоспособности и потере данных. Улучшения в кластере с единым хранилищем по сравнению с предыдущими кластерными решениями разрешают многие проблемы, на которые указывали пользователи предыдущих решений высокой доступности. Однако кластер с единым хранилищем по прежнему отличается сложностью, вызываемой использованием общего хранилища. Он изначально содержит минимум два отказоуязвимых места: единственный диск кворума и единственную копию данных Exchange. В Exchange 2007 имеется второй тип конфигурации высокой доступности, предоставляющий полную избыточность и не требующий оборудования из категории кластерных решений из каталога прошедших испытания продуктов Windows Server. Это решение называется кластерной непрерывной репликацией (CCR).
Кластерная непрерывная репликация использует встроенную асинхронную доставку журналов для репликации данных почтовых ящиков между двумя серверами в отказоустойчивом кластере. Интеграция репликации и кластеризации дает возможность получить решение, в котором нет единого отказоуязвимого места и которое предоставляет автоматическое восстановление после сбоев сервера. Вдобавок, оно устраняет необходимость в общем хранилище, тем самым уменьшая сложность и стоимость развертывания. Кластерная непрерывная репликация поддерживает только двухузловые кластеры и только две копии данных (активную и пассивную). На следующем рисунке изображена типичная конфигурация кластера с непрерывной репликацией.
Два существенных изменения видны на данном рисунке - отсутствие общего диска кворума и присутствие общего файлового ресурса на третьем компьютере вне кластера. Общий файловый ресурс является частью новых возможностей кворума кластера, вносимых обновлением, описанным в статье 921181 базы знаний корпорации Microsoft, «Доступно обновление, добавляющее функциональные возможности свидетеля общего файлового ресурса и настраиваемой синхронизации кластера, кластерам на основе Windows Server 2003 с пакетом обновления 1»(на английском языке). Обновление позволяет службе кластера использовать ресурс кворума, использующий общий файловый ресурс, вместо узла голосования в кластере. Без обновления кворум позволяет только использовать общий диск или традиционную конфигурацию набора большинства узлов, а оба этих варианта имеют недостатки и повышают издержки:
- Использование общего диска возвращает в решение повышенную
сложность общего хранилища.
- Кворум набора большинства узлов требует трех или более узлов. В
этой конфигурации дополнительный узел должен выступать в роли узла
голосования в кластере.
Дополнительные сведения о кластерной непрерывной репликации приведены в разделе Непрерывная репликация кластера.
Локальная непрерывная репликация
Кластерная непрерывная репликация предоставляет полную избыточность данных и служб, а кластер с единым хранилищем предоставляет избыточность служб. Для организаций, которым необходима избыточность данных без избыточности служб, существует локальная непрерывная репликация (LCR). Локальная непрерывная репликация - это не кластерное решение, и, следовательно, она не обеспечивает доступности служб. На следующем рисунке изображена типичная конфигурация локальной непрерывной репликации.
Локальная непрерывная репликация использует встроенную технологию непрерывной репликации, описанную в предыдущем подразделе, посвященном кластерной непрерывной репликации, для создания второй копии (именуемой пассивной копией) группы хранения на локальном компьютере. Компьютер должен являться автономным (не кластерным) сервером почтовых ящиков. В среде локальной непрерывной репликации администратор решает, какие группы хранения будут иметь пассивную копию, и настраивает второе местоположения для пассивной копии на том же сервере.
При использовании локальной непрерывной репликации администратор должен явным образом определить, какие группы хранения должны иметь пассивные копии. Администраторы могут решить создать пассивную копию существующей группы хранения или задейстовать локальную непрерывную репликацию для новой группы в процессе ее создания. Администратор должен настроить второе местоположение для файлов журнала и баз данных тех групп хранения, которые поддерживают локальную непрерывную репликацию.
В локальной непрерывной репликации активация второй копии производится вручную. В локальной непрерывной репликации отсутствует переход на другой ресурс при сбое, поскольку это операция кластера, а локальная непрерывная репликация не является кластерным решением. Вместо этого администратор должен решить, когда применение активной копии более недопустимо, и вручную активировать пассивную копию, делая ее новой активной копией. Процесс активации пассивной копии прост и быстр.
Администратор может решить включить локальную непрерывную репликацию и создать пассивную копию существующей базы данных в любое время, также он может сделать это при создании новой базы данных. После включения локальной непрерывной репликации создается базовая копия с помощью процесса, называемого начальным заполнением, после чего начинается репликация (доставка журналов). В идеале следует разместить пассивную копию на дисках или в отдельном хранилище, изолированном от активной копии. Это сводит к минимуму шансы одновременного сбоя обоих копий. Локальная непрерывная репликация требует заметной доли ресурсов сервера почтовых ящиков. Сервер почтовых ящиков выполняет всю обработку данных, связанных с непрерывной репликацией, и это следует учитывать при планировании загрузки мощностей сервера. Нагрузка ввода-вывода на активную копию ограничена, поскольку основная часть ввода-вывода для пассивной копии связана с ее собственными файлами журнала и базы данных.
Локальная непрерывная репликация поддерживает создание резервных копий пассивной копии с помощью службы теневого копирования томов (VSS), поддерживающей Exchange. Когда тома диска, содержащие активную копию, должным образом отделены от пассивной копии, создание резервных копий VSS без поддержки аппаратного теневого копирования является хорошим вариантом. Создание резервных копий с пассивной копии уменьшает ввод-вывод, связанный с резервным копированием, на томах диска активной копии. Поскольку от пассивной копии не требуется способность отвечать клиентам в режиме реального времени, она может позволить себе дополнительные нагрузки, связанные с использованием программного теневого копирования. Вдобавок, в зависимости от существующих планов загрузки мощностей может оказаться практичным расширение окна резервного копирования на сервере с локальной непрерывной репликацией. Ключевым фактором явяется способность поддерживать нагрузку агента резервного копирования на ЦП в течение окна резервного копирования.
Пассивная копия является первым рубежом защиты от сбоев и порчи данных. Благодаря локальной непрерывной репликации первое восстановление после сбоя может иметь сравнительно короткое соглашение об уровне обслуживания (SLA). Двойной сбой требует восстановления с резервной копии. При использовании вышеописанной модели соглашение об уровне обслуживания для двойного сбоя может оказаться гораздо длиннее. Как следствие, рекомендуется поддерживать режим еженедельного полного резервного копирования и ежедневного инкрементного резервного копирования. Такая стратегия также уменьшает общий объем содержимого, переносимого на резервные носители.
Подводя итог, можно сказать, что локальная непрерывная репликация является превосходным решением для организаций, которым необходимо быстрое восстановление данных после сбоя или повреждения, но которые, в то же время, допускают запланированные и внеплановые отключения сервера. Локальная непрерывная репликация предоставляет следующие преимущества:
- Быстрое двухэтапное восстановление активной базы данных после
повреждения или сбоя.
- Избирательная работа администратора, защищающего пользователей,
которые наиболее в этом нуждаются.
- Доступность на сервере почтовых ящиков любого размера и во всех
продуктах.
- Минимальное влияние на активную базу данных и на операции
ввода-вывода диска, на котором хранится журнал.
- Способность уменьшить объем ввода-вывода, связанный с резервным
копированием, для активной базы данных и томов журнала.
- Возможность уменьшения общего объема данных, перемещаемых на
резервные носители, при расширении окна резервного копирования.
- Абстрагирование администрирования на уровне Exchange
посредством использования консоли управления Exchange или командной
консоли Exchange.
Дополнительные сведения о локальной непрерывной репликации приведены в разделе Локальная непрерывная репликация.