Защита данных и восстановление после сбоев в среде Exchange Server 2007
Среда Microsoft Exchange Server разрабатывалась с учетом необходимости операций архивации. Организациям необходимо архивировать данные обмена сообщениями, а также иметь возможность восстанавливать их. Чтобы удовлетворить эти потребности, в корпорации Майкрософт создан полный спектр возможностей защиты данных, начиная с простых традиционных возможностей архивации и восстановления, обеспечивающих непрерывность рабочего процесса, вплоть до решений, в полном объеме обеспечивающих непрерывность всей деятельности предприятия и предоставляющих высочайший уровень доступности и восстановления после сбоев. В данной статье будут рассмотрены эти возможности и сделана попытка помочь читателю выбрать способ реализации решения для восстановления, оптимальный для конкретной организации.
УРОВЕНЬ 1: БАЗОВЫЕ АРХИВАЦИЯ И ВОССТАНОВЛЕНИЕ
Файлы Exchange можно архивировать, переведя базы данных в автономный режим, но архивирование можно выполнять также и во время работы базы данных. В действительности, в большинстве случаев для архивирования Exchange предпочтительным является последний вариант. Но Exchange не сводится к набору файлов. Он является хранилищем информации, содержащим большие файлы баз данных и журналы транзакций. Сообщения, передаваемые в Exchange, незамедлительно записываются в журналы транзакций, и при появлении у системы свободного цикла (обычно несколько миллисекунд спустя) сообщения копируются непосредственно в базу данных. Отправляя информацию на диск как можно быстрее, Exchange обеспечивает очень высокий уровень восстанавливаемости. Для Exchange существенно наличие доступа к обоим наборам данных. В случае сбоя системы именно сочетание предшествующего архива со всеми транзакциями, выполненными после этого момента, позволяет восстановить Exchange с наиболее свежими данными. Отметим, что при необходимости Exchange автоматически воспроизводит транзакции на восстановленной базе данных.
Способ, которым программы архивации получают доступ к информации в базах данных Exchange, состоит в использовании интерфейса API архивации ESE (Extensible Storage Engine) или более новых решений VSS, о которых речь пойдет позднее. При каждом запуске архивации ESE временно приостанавливаются все операции Exchange по выполнению записи в базы данных. В это же время ESE временно переводит базу данных в режим только для чтения, что позволяет выполнить полную архивацию базы данных; кроме этого, для поддержки транзакций, возникших во время архивирования, используется временная база данных. По завершении архивирования ESE возвращает базу данных в нормальный режим чтения/записи и применяет транзакции, накапливавшиеся во временной базе данных. В рамках архивации журналы старых транзакций удаляются в конце нормально завершающегося процесса архивирования.
Хотя этот процесс архивирования является простым и понятным даже для пользователей, которые вошли в систему среди ночи, во время выполнения архивирования, механизму ESE может потребоваться значительное время для завершения работы, в особенности потому, что размер баз данных Exchange может колебаться в пределах от нескольких гигабайт до поддающихся управлению 30 – 50 или даже до 100 ГБ, архивирование которых оказывается почти невозможным выполнить в течение ночи с использованием стандартных технологий. Чтобы получить представление о вариантах, доступных при использовании NTBackup.exe, обратимся к рис. 1.
Рис. 1 Использование служебной программы NTBackup
Рекомендации для Exchange
Если требуется обеспечить возможность быстрого восстановления после обычных сбоев оборудования или системных сбоев, необходимо в ночное время запускать операции полной архивации Exchange. Для повышения производительности и восстанавливаемости важно при использовании сервером Exchange локальных дисков всегда использовать для хранения баз данных Exchange и журналов транзакций Exchange отдельные массивы RAID. При таком подходе, сохраняется возможность восстановления, если отказывает контроллер массива RAID, или в массиве возникает сбой нескольких дисков, не позволяющий использовать оставшиеся диски для реконструкции данных с чередующихся томов. В случае утраты журналов транзакций остаются обновленные базы данных Exchange на других дисках, что позволяет продолжать нормальные операции с новыми журналами транзакций. Если утрачены диски с базами данных, стратегия восстановления заключается в возврате к полному архиву баз данных Exchange, полученному накануне ночью, и применению журналов транзакций текущего дня для получения обновленного состояния баз данных.
Важно ограничивать размер баз данных Exchange, чтобы архивирование каждой из них (и, что более существенно, восстановление) можно было выполнить за приемлемое время. Для большинства организаций эта рекомендация подразумевает поддержание размера баз данных в интервале от 30 до 50 ГБ. Когда база данных выходит за эти пределы, рекомендуется разделить ее на несколько баз данных, что добиться управляемости процесса восстановления.
Непрерывный спектр решений для архивации и восстановления
Размещение баз данных и журналов транзакций является крайне важным обстоятельством не только для производительности процесса архивирования, но также для скорости восстановления. В настоящее время все серверы поддерживают разную степень избыточности дисков, известную под названием RAID. В принципе, RAID позволяет сохранить работоспособность системы при выходе диска из строя, хотя производительность системы уменьшается до момента замены или восстановления диска. До этого времени контроллер массива дисков должен «на ходу» реконструировать данные с оставшихся дисков в ответ на все запросы, требующие доступа к этому диску. Для получения дополнительных сведений о конструкции хранилищ для серверов почтовых ящиков ознакомьтесь со статьей Майкрософт IT Showcase под названием "Переход на 64-разрядные технологии в Exchange Server 2007".
Основная особенность Exchange определяется проектом баз данных, предусматривающим использование единственного экземпляра. Это означает, что в базе данных Exchange хранится единственная копия конкретного сообщения вместе с единственным вложением (при его наличии). Если сообщение было передано нескольким получателям в одном и том же хранилище данных, создаются дополнительные указатели на объекты (сообщение, вложение), но сами объекты не дублируются. Такой подход не только обеспечивает значительное преимущество с точки зрения эффективности доставки, но и позволяет Exchange экономить пространство как на диске, так и на ленте.
Хотя Exchange хорошо справляется с восстановлением базы данных в целом, для восстановления индивидуальных почтовых ящиков, папок или сообщений требуется сначала восстановить всю ленту. Не удивительно, что пользователям хотелось бы иметь более дифференцированные возможности восстановления. Единственный экземпляр на ленте значительно затрудняет это. Поставщики средств архивации откликнулись на эту проблему созданием «Brick-Level Backup» (Архивация на уровне базовых блоков) (пользоваться которой я не рекомендую). По завершении полной архивации базы данных Exchange с помощью испытанного интерфейса API механизма ESE программные продукты архивации добавляют на архивную ленту все почтовые ящики. Поскольку интерфейс API средств архивации не предоставляет возможности извлекать данные из отдельных почтовых ящиков, используется MAPI. В результате лента с архивом становится значительно длиннее, поскольку дублируются все эти сообщения и вложения.
В корпорации Майкрософт были внесены некоторые улучшения, которые частично устраняют эту проблему. Например, в административной мусорной корзине (или мусорном контейнере) удаленные пользователями элементы хранятся в течение некоторого периода времени на тот случай, если они понадобятся. Кроме этого, больше нет необходимости в наличии резервного сервера в качестве леса восстановления Exchange; группы хранения для восстановления дают администратору возможность частично подключать восстановленные базы данных, перенесенные с ленты, и копировать или объединять данные на уровне почтового ящика.
«Практика — путь к совершенству»
Многие организации знают по собственному горькому опыту, что, несмотря на решение, принятое относительно уровня архивации и восстановления, необходимо регулярно проверять носители архивов и процедуры восстановления. Очень многие администраторы только после сбоя узнают о том, справляются ли со своими функциями технология архивации и процедуры восстановления. Оптимальный момент для проверки — это день после установки и настройки нового сияющего сервера, когда он уже функционирует в качестве компонента организации Exchange, но с ним работают всего несколько пользователей. На этом этапе следует выполнять полную архивацию Exchange, регулярные архивирования дисков, а также собирать данные о состоянии системы, в которые входят важнейшие файлы на системном диске, а также метабаза IIS (содержащая настройку маршрутизации Exchange). Затем спокойно переформатируйте новый сервер и начните сначала, обновляя записи, сделанные при первоначальной установке сервера. Необходимо иметь возможность восстанавливать параметры на основе данных о состоянии системы, но, кроме этого, необходимо иметь соответствующую документацию для повторной установки параметров настройки системы вручную.
Время, затрачиваемое на эту практическую проверку, значительно сократит время, которое потребуется для восстановления в будущем. Периодически повторяйте эту процедуру. Занимаясь этим, засеките время, требуемое для доставки лент извне организации. Те, кто мучился в течение этого кажущегося бесконечным интервала времени, зачастую задумываются более серьезно о том, насколько важным компонентом стратегии архивации и восстановления является архивирование данных с диска на диск — даже если ленточный накопитель вне организации продолжает оставаться последней поддержкой для восстановления после сбоя.
Сложности, связанные с архивированием на ленты
Восстановление с ленты занимает слишком много времени. В настоящее время Exchange играет настолько важную роль в работе организаций, что пользователи и руководство рассчитывают на то, что он будет доступен постоянно. При возникновении серьезной проблемы большинство организаций оказываются захваченными врасплох. Никто не готов к сообщению о том, что для восстановления с ленты базы данных в 75 Гбайт потребуется восемь часов даже без учета времени на доставку лент из находящегося за пределами организации хранилища или переустановки операционной системы.
Более того, существует также проблема извлечения с ленты требуемой базы данных. В течение 10 лет, прошедших с момента первого выпуска Exchange, стоимость дискового хранилища и глобальной сети значительно упала. В результате многие организации могут позволить себе более быстрые методы архивации и восстановления. У этих организаций есть реальная возможность воспользоваться преимуществом технологий, позволяющих добиться непрерывности рабочего процесса и восстановления после сбоев в рамках инфраструктуры Exchange.
УРОВЕНЬ 2: НЕПРЕРЫВНОСТЬ РАБОЧЕГО ПРОЦЕССА
Под непрерывным рабочим процессом понимается набор процедур и технологий, подразумевающих максимально быстрое восстановление и минимизацию непредвиденных простоев. Непрерывность рабочего процесса предлагает улучшенные целевое значение времени восстановления и целевую точку восстановления на ленте для локального восстановления. Прилагаются усилия к тому, чтобы везде, где это возможно, избавиться от затрат времени на доставку лент к месту восстановления. Обратимся к рис. 2, чтобы сравнить архивацию и восстановление по методу непрерывного рабочего процесса и по методу DR.
Рис. 2 Непрерывное множество решений для восстановления
На этой схеме иллюстрируется непрерывное множество решений для восстановления и доступности от медленного и дешевого в левой нижней части до быстрого и дорогостоящего в правой верхней части с преднамеренно нечетким переходом между решениями для непрерывного рабочего процесса и для восстановления после сбоя.
Этот график дает представление о компромиссах между ценой, временем восстановления и доступностью в рамках этих подходов. В данной статье целенаправленно подчеркивалось отличие процедур, обеспечивающих локальную непрерывность работы, и решений по восстановлению после сбоя. Решение для восстановления после сбоев всегда рассматривается как удаленное, в котором основной целью является доставка данных за пределы организации. Расстояние вносит дополнительные сложности и обычно сопряжено с гораздо большей стоимостью, но решение для восстановления после сбоев относится к обеспечению функционирования предприятия после катастрофических событий. Более глубоко эта сторона проблемы будет рассмотрена далее.
Немного истории
Чем более жизненно важной частью инфраструктуры становился Exchange и чем больше информации хранилось в его базах данных, тем очевиднее становилось, что необходимо сокращать время архивирования и восстановления. Работая с Майкрософт, некоторые большие организации предложили подход, в котором обеспечивается улучшенный вариант возврата к частичным операциям. Если бы организация могла получать и отправлять сообщения электронной почты во внешний мир, все выглядело бы так, как будто ничего не случилось. В конце концов, важен вид со стороны.
Чтобы реализовать для Exchange этот ускоренный вариант восстановления, на место поврежденной помещалась новая база данных. Затем Exchange и Active Directory® создавали новые почтовые ящики с соответствующими разрешениями, и пользователи могли продолжать отправлять и получать сообщения. После того как лента с архивом доставлялась на место и данные восстанавливались, базу данных можно было подключить в режиме администратора. После этого администратор Exchange объединял восстановленные почтовые ящики с почтовыми ящиками тонального вызова. При необходимости почтовым ящикам можно было назначать приоритеты. Хотя эта процедура обеспечивала улучшение, она была сложной и требовала много времени; сначала в ней использовалась программа EXMERGE, а впоследствии она была приспособлена для групп хранения для восстановления. Тем не менее, следует отметить, что полное восстановление после использования ускоренного восстановления могло оказаться тяжелой и сложной задачей (в особенности с учетом того, что в Exchange 2007 возможно существование до 50 групп хранения). Если вы рассматриваете возможность реализации схемы ускоренного восстановления, необходимо соблюдать осторожность, убеждаясь, что преимущества стоят затраченных усилий.
Службы теневого копирования тома
Чтобы воспользоваться преимуществами дешевизны дисков и избавиться от перегрузки процессора на производственных серверах Exchange, для Microsoft® Windows Server® 2003 и Exchange был разработан новый интерфейс API архивации. Для получения согласованных копий данных на определенный момент времени была создана служба теневого копирования тома VSS. Эти моментальные снимки являются копиями только для чтения данных Exchange, в которые последовательно включаются только измененные данные. Эти копии обычно указывают на другой сервер со свободным дисковым пространством или сеть области хранения SAN. Можно поддерживать несколько снимков, с архивными копиями на ленте. В результате производственный сервер Exchange больше не испытывает влияния на производительность, оказываемого программным обеспечением для архивации и перегрузки, вызываемой копированием ленты.
Существует несколько преимуществ использования VSS для защиты данных Exchange. Во-первых, сервер Exchange можно освободить от нагрузки на производительность со стороны операций архивирования на ленту. Хотя по-прежнему сохраняется необходимость архивирования на ленту, для нее можно использовать копию данных Exchange без последствий для производительности пользователей. Во-вторых, появляется возможность делать снимки чаще, чем один раз за ночь. И, в качестве награды, можно поддерживать несколько снимков на дополнительном сервере или в другом локальном хранилище.
На рынке существует ряд программных продуктов сторонних производителей, которые используют преимущества возможности создания снимков VSS. Некоторые просто сокращают время, требуемое для архивирования и восстановления баз данных Exchange, в то время как другие добавляют такие возможности, как восстановление с большей степенью дифференцированности по сравнению с предоставляемой встроенной в Exchange процедурой, так что восстановление можно выполнять на уровне почтовых ящиков. Хотя никому такие блочные архивации не по душе, всем требуется возможность восстановления конкретных папок или даже отдельных сообщений.
Технологии репликации
Отказоустойчивость Exchange, обеспечиваемая программным способом, является возможностью, предлагаемой некоторыми поставщиками репликаций. При таком методе резервный сервер Exchange переводится в активное состояние, после чего компоненту Active Directory передается информация о том, что все пользовательские почтовые ящики перемещены. Существует два способа достижения этого результата, и для обоих требуются некоторые специальные настройки в среде Exchange и среде Windows. В одном из них играют роль некоторые хитрости, применяемые в DNS, в результате чего резервный сервер получает имя и адрес сервера, на котором возник сбой. Преимущество этого подхода состоит в легкости его применения на клиентских рабочих станциях, поскольку Outlook® считает, что по-прежнему используется прежний сервер.
Во втором подходе используется резервный сервер, на котором выполняется Exchange, поддерживающий копии базы данных, но к которому ничего не подключено. В случае сбоя резервный сервер сообщает компоненту Active Directory, что все пользовательские почтовые ящики были перемещены на него. Затем запускается сценарий или распределяется групповая политика, сообщающая клиентам, что они находятся на другом почтовом сервере. Outlook 2007 поддерживает Active Directory, что облегчает данный процесс, поскольку он сам выполняет автоматическое вычисление этих отображений.
Локальная кластеризация посредством MSCS
Выше в непрерывном множестве решений находятся службы кластеризации Майкрософт MSCS (Microsoft Cluster Services); Exchange является приложением, поддерживающим кластеризацию. При кластеризации информация делится между двумя или несколькими компьютерами, чтобы при сбое одного его функции на себя брали другие. В настоящее время большинство кластеров Exchange состоят из двух или четырех узлов, хотя предусмотрено использование до восьми узлов. Один узел всегда назначается пассивным — работает с выполняющимся на нем Windows Server и установленным Exchange Server, но не имеет активных почтовых ящиков. В Exchange 2003 существовал состоящий из двух узлов активный/активный кластер, но вследствие нагрузки на производительность он в настоящее время отменен и не будет поддерживаться в Exchange 2007.
Как и при организации кластеров в Exchange 2003, кластеры в Exchange 2007, в которые входит пассивный узел, по-прежнему могут использовать отдельный массив для совместного хранения. Хотя массивы хранения кластерного типа обычно имеют ряд функций резервирования, предназначенных для преодоления разных типов сбоев, они по-прежнему обеспечивают только одну копию данных, что оставляет окно для уязвимости. По этой причине такие кластеры называются кластерами одной копии (SCC), чтобы отличать их от следующего рубежа в защите данных, который возникает с появлением кластеров нескольких копий (MCC) в Exchange 2007. Кластеры MCC будут обсуждаться далее при рассмотрении восстановления после сбоя.
Локальная непрерывная репликация
Локальная непрерывная репликация (LCR) является новым компонентом Exchange 2007, обеспечивающим усовершенствованный способ поддержания второй копии баз данных Exchange и журналов транзакций в пределах одного сервера. Этим добавляется слой резервирования к оптимальной практике размещения базы данных Exchange на одном массиве RAID, а журналов транзакций — на другом: LCR предоставляет возможность хранения дополнительной копии журналов на массиве, где хранится основная копия базы данных, и хранения дополнительной копии базы данных на массиве, где хранится основная копия журналов (см. рис. 3). В случае сбоя одного из контроллеров RAID или массива сохраняется доступ к базе данных и журналам транзакций на другом массиве. При этом подходе можно продолжать работу (хотя в несколько нервной обстановке и с некоторым ухудшением производительности) до тех пор, пока не появится возможность восстановления работоспособности массива, на котором возник сбой.
Рис. 3 Настройка LCR
LCR является решением, обеспечивающим непрерывность рабочего процесса в локальной среде, а не решением архивации, поэтому по-прежнему необходимо предусмотреть стратегию полной архивации. Кроме этого, LCR приводит к снижению производительности, поскольку сервер теперь создает две копии базы данных и журналов транзакций. Более того, в реализации Exchange 2007 имеются некоторые ограничения, из-за которых LCR оказывается подходящей только для небольших организаций, поскольку LCR поддерживает только одну базу данных в группе хранения и только одну базу данных общих папок в организации.
Обеспечение отказоустойчивости с помощью восстановления после сбоя, обеспечиваемого LCR, выполняется не мгновенно — знающему специалисту по ИТ придется запустить сценарии для восстановления Exchange. Для этой процедуры требуется выполнение команд командной консоли Exchange, которые запускаются вне консоли управления Exchange.
В то время как Exchange Server 2003 Enterprise Edition позволяет организации поддерживать до 20 работающих баз данных Exchange (четыре группы хранения, в каждой из которых до пяти баз данных), в Exchange 2007 Enterprise Edition предусмотрено поддержание до 50 групп хранения, каждая со своей собственной базой данных. Объем журналов транзакций также был сокращен с файлов по 5 МБ в Exchange 2003 до файлов по 1 МБ в Exchange 2007. Оба эти изменения имеют целью поддержку LCR и, дополнительно, кластерной непрерывной репликации (CCR), которая вскоре потребуется.
В небольших организациях и организациях среднего масштаба LCR будет использоваться для улучшения защиты данных при работе с Exchange. LCR легко внедряется, но все-таки требует выполнения некоторых операций вручную. В качестве решения «тот же сервер/локальный диск» LCR является всего лишь первым шагом на пути повышения непрерывности рабочего процесса. Хотя она предназначена для защиты от сбоев массива RAID и контроллеров RAID, одновременное повреждение нескольких дисков или контроллеров RAID возникает не часто. Большей частью в ситуации сбоя отказывает сервер в целом, что приводит нас к следующему шагу в обеспечении защиты Exchange.
Локальная репликация «вне размещения», созданная сторонними разработчиками
Для развития возможностей восстановления после сбоя Exchange, сторонними поставщиками разработаны программные продукты, использующие преимущество репликации «вне размещения», в которой файлы журналов Exchange используются для поддержания резервной копии базы данных Exchange на другом компьютере. В этом случае решение для защиты данных или архивации выполняет полную архивацию ESE для Exchange на другом компьютере, после чего переносит журналы транзакций по мере того, как Exchange их закрывает. Эти транзакции вставляются в копию соответствующей базы данных Exchange для постоянного поддержания их в обновленном состоянии. Как было отмечено, эти журналы имеют относительно небольшой объем (5 МБ в Exchange 2003 и 1 МБ в Exchange 2007), чтобы по завершении полной архивации на сервере Exchange не возникало перегрузки вследствие копирования файлов журналов на сервер вне узла.
УРОВЕНЬ 3: ВОССТАНОВЛЕНИЕ ПОСЛЕ СБОЯ И ВЫСОКАЯ ДОСТУПНОСТЬ
Решение для восстановления после сбоя обеспечивает возврат базы данных в исходное состояние и ее запуск в случае недоступности основного центра данных. Exchange заслуживает эффективного восстановления после сбоя, поскольку в настоящее время функции электронной почти и календаря являются жизненно необходимыми для многих организаций.
Некоторые компании полагают, что их традиционные архивы на лентах, хранящиеся вне организации, являются формой обеспечения восстановления после сбоя, но если ваш единственный центр данных оказывается разрушенным вследствие пожара или наводнения, в фургоне, доставившем бобины лент, мало пользы. Восстановление после сбоя с необходимостью включает в себя не только перемещение данных в другое место, но также технологию и процедуры, обеспечивающие возврат в исходное состояние и запуск приложений. Для обеспечения эффективности восстановления после сбоя оно опирается на разнесение основной и резервной систем на некоторое расстояние. Насколько далеко должны находиться эти площадки, зависит от размера сбоя, который предстоит преодолевать. Если есть основания опасаться пожара, возможно, другое здание в пределах кампуса находится на достаточном расстоянии. Однако инфраструктурные бедствия, связанные с поездами и самолетами, могут иметь последствия в радиусе мили или более. Многие бедствия имеют региональный масштаб: наводнения, ледяные дожди, землетрясения и даже отключения электроэнергии. Линии связи могут переживать свои собственные катастрофы — все что угодно, начиная от экскаватора, перерезавшего линию связи с вашим поставщиком услуг Интернета, до атак типа отказа в обслуживании и DoS-атак из Интернета, ориентированных на торговые операции в целом.
В качестве практичной меры, если в вашей организации уже есть более одной площадки, на которой работают сотрудники отдела ИТ, одно из этих мест могло бы отвечать критериям удаленного непрерывного рабочего процесса исходя из тех типов сбоев, к борьбе с которыми вы готовитесь. Использование своих собственных средств и персонала обойдется гораздо дешевле, чем заключение договора с поставщиком услуг по восстановлению после сбоя или аренда пространства для хранения в новом месте.
В конечном счете, восстановление после сбоя всегда имеет дело с восприятием: необходимо обеспечить клиентам уверенность в том, что ваш бизнес по-прежнему существует. Люди относятся с пониманием к сбоям, затронувшим город или область, но если ваша компания не возвращается в оперативный режим в течение нескольких дней или недели, есть шанс, что клиенты и поставщики будут предполагать худшее; по этой причине потерпели неудачу многие компании. Для клиента ваша деятельность должна выглядеть как находящаяся в режиме восстановления, чтобы клиенты были уверены в том, что ваше предприятие продолжает работать. У клиентов разные представления о своевременном восстановлении: по понятным причинам они менее терпимо относятся к сбоям в компаниях, предоставляющих им финансовые услуги, чем, скажем, в компаниях, поставляющих офисную мебель.
Требования режима восстановления после сбоя
Способность вернуть Exchange в оперативный режим работы после сбоя требует репликации данных на резервную площадку и использования технологии репликации, подготовленной для представления данных включенному серверу Exchange, готовому для их запуска, и последующего уведомления клиентов Outlook о том, что их почтовые ящики перемещены.
С точки зрения репликации Exchange является требовательным приложением, особенно при преодолении больших расстояний. Для подлинно транзакционной базы данных порядок выполнения каждой операции записи является крайне важным. Задача усложняется тем, что Exchange для обмена данными всех транзакций и системными данными между серверами использует в качестве транспортного протокола SMTP, известный протокол, интенсивно использующий полосу пропускания. Более того, в кластерах Exchange импульс синхронизации должен поддерживаться между системами каждые 500 миллисекунд. Если резервный узел не получает импульс синхронизации, он может запустить начало процедуры перехода на другой ресурс.
Сложности решения таких задач, возможно, являются причиной того, что Майкрософт только сейчас начинает работать с Exchange 2007 в этой области. В отсутствие разработок Майкрософт сторонними разработчиками было создано несколько решений для репликации данных Exchange, в которых используется репликация на основе узла или на основе массива.
Поставщики пришли к мысли о том, что можно расширить кластер посредством разнесения узлов в разные места; такой кластер называется растянутым. В настоящее время наиболее распространенным способом реализации растянутых кластеров является использование программных продуктов для репликации данных, созданных сторонними производителями и имеющих общее назначение, либо предназначенных именно для растягивания узла Exchange. Этого можно достичь с помощью MSCS, но в сети WAN сложно выполнять требования, предъявляемые к подсети. Кластеризация и сложности обеспечения надежной широкополосной связи для удаленных центров данных по понятной причине увеличивают стоимость и требования к персоналу, связанные с созданием, поддержанием и периодическим тестированием систем восстановления после сбоя.
Кластерная непрерывная репликация
Корпорация Майкрософт расширяет поддержку кластеров посредством кластерной непрерывной репликации в Exchange 2007. В CCR расширяется способность LCR поддерживать две копии базы данных и журналы транзакций Exchange, чтобы реализовать эту же идею на двух узлах кластера. В процедуре восстановления после сбоя предполагается географическое разделение основной и резервной систем, и кластеры Майкрософт с несколькими копиями (MCC) будут не в состоянии перекрывать значительные расстояния до тех пор, пока Windows Server 2008, ранее носивший кодовое название «Longhorn», не сделает возможным растягивание кластеров.
Технология, позволяющая узлам MCC иметь отдельные копии данных, называется набором узлов большинства (MNS), что напоминает о процедуре выборов, которая приводит к тому, что два или несколько узлов определяют, на котором будет содержаться активная копия данных. При возникновении сбоя оставшиеся узлы проводят новые выборы для определения, который из них станет новым основным сервером обработки/данных. Поддержку этой технической демократии осуществляет CCR, обеспечивающая на каждом узле обновленное состояние базы данных. Кластеры Exchange 2007, использующие CCR, ограничены только двумя узлами.
В крупных магазинах серверы Exchange обычно настраивают локальный системный диск на самом сервере, а затем подключаются к базе данных Exchange по сети SAN, использующей массивы дисков со связью по SCSI, оптоволокону или iSCSI. В отношении кластера MCC/MNS возникает интересный вопрос о том, не пройдет ли новейшее хранилище Exchange обратное развитие к использованию локальных массивов RAID для каждого узла. Если назначением кластера MNS является обеспечение каждого узла своим собственным отдельным хранилищем, будет ли смысл в указании каждого узла для SAN, основным назначением которого является предоставление общего хранилища?
Вероятным вариантом промежуточного развития кластеров MCC/MNS будет наличие основного узла с хранилищем в сети SAN и резервного узла кластеров либо с локальными дисками, либо с меньшей по стоимости сетью SAN на iSCSI. Этот резервный узел может находиться на определенном расстоянии от основного центра данных, в месте, не имеющем инфраструктуры SAN.
Независимо от того, как происходит реорганизация, использование MNS и CCR кластерами MCC является следующей ступенькой в иерархии резервирования и повышенной доступности, поскольку несколько компьютеров могут переходить на резервный ресурс, и данные реплицируются на отдельных элементах хранения. Тем не менее, до момента появления Windows Server 2008 такой подход по-прежнему полностью заключен в рамки единственного центра данных. В Windows Server 2008 будет встроена поддержка растянутых кластеров, позволяющая географически разносить узлы в кластере MNS на любое требуемое расстояние — при условии, что задержка сети между узлами гарантированно не превышает 500 миллисекунд. До тех пор (и потом) технологии кластеров сторонних производителей могут располагаться поверх Microsoft MNS и CCR и обеспечивать географическое разделение, необходимое для растянутых кластеров, чтобы оставаться эффективным решением для восстановления после сбоя.
Кластеризация находится в высшей точке непрерывного множества решений для восстановления после сбоя, и CCR удачно позиционируется в качестве функции, обеспечивающей в Exchange высокую доступность. Несмотря на то, что это сочетание влечет финансовые и трудовые издержки, оно обещает стать замечательным и самым современным решением для клиентов, которым для работы необходима однородная среда Майкрософт.
Непрерывность рабочего процесса в удаленном режиме, обеспечиваемая сторонними производителями
Нет никаких сомнений в том, что решение Майкрософт, когда оно станет доступным, и расширения, созданные сторонними производителями, займут высшее место в непрерывном множестве решений для восстановления. Автоматический переход на другой ресурс в течение секунд — это самое лучшее, что может быть. Тем не менее, такой уровень доступности и непрерывности рабочего процесса требуется не каждой компании, и точно так же не каждая компания может себе позволить вкладывать сотни тысяч долларов, необходимые для достижения этого уровня. Для многих компаний требуемую непрерывность рабочего процесса обеспечит надежное решение, полностью восстанавливающее Exchange в течение минут.
Приведем в качестве пример компанию Mimosa Systems, расширяющую непрерывность рабочего процесса в пределах единственного центра данных до уровня непрерывности удаленного рабочего процесса. Группа восстановления данных компании Mimosa поддерживает на удаленной площадке копию, обеспечивая актуальность ее состояния посредством доставки журналов транзакций с основного сервера Exchange, и всегда готова перевести эту копию в активное состояние, доступное резервному серверу Exchange. Удаленный сервер Exchange использует стандартное серверное оборудование и, в точности как в реализации с единственным центром данных, поддерживает его включенным и всегда готовым к активированию в случае возникновения сбоя. Если случится сбой, оператор на удаленном узле инициирует переход на другой ресурс и выполнит этот переход, выполняя подключение файлов резервной базы данных, повторное подключение почтовых ящиков и профилей Outlook. Тем не менее, следует отметить, что эти решения сторонних разработчиков зависят от ограниченности поддержки, определенной в статье базы данных «Политика Майкрософт по поддержке программных продуктов сторонних производителей, изменяющих или извлекающих содержимое баз данных Exchange».
Заключение
Защита данных Exchange доступна в виде непрерывного множества технологий и процедур, которые можно сгруппировать на трех уровнях, исходя из их стоимости и возможностей. Обдумывая предъявляемые ими требования, необходимые для обеспечения защиты данных Exchange, следует учитывать время простоя, с которым готовы мириться заинтересованные лица. Высокая производительность и быстрота восстановления требуют больших затрат, и для самых современных вариантов эта стоимость выражается шестизначными числами. При этом же подходе существуют более доступные по стоимости решения, но они не достигают самых высоких уровней обеспечения доступности данных. Выбор варианта защиты должен основываться на реальных потребностях организации.
Пакет обновления 1 (SP1) для Exchange 2007 В настоящее время пакет обновления 1 (SP1) для Exchange 2007 находится в процессе бета-тестирования, и в нем запланирован ряд компонентов, которых недоставало администраторам, включая усовершенствования OWA, дополнительные возможности графического интерфейса пользователя для режима консоли и многое другое.
Особенный интерес для администраторов, планирующих использование решений восстановления, представляет включение в Exchange 2007 пакет обновления 1 (SP1) также и третьего решения по обеспечению доступности, дополняющего LCR и CCR: резервная непрерывная репликация (SCR). Это промежуточный подход, и Майкрософт рассматривает его как наиболее благоприятный вариант развития возможностей восстановления, не сопровождаемый сложностями обеспечения полной "высокой доступности."
SCR обеспечивает репликацию базы данных и журналов транзакций Exchange на другой сервер, отличный от сервера, на котором обычно размещаются почтовые ящики. Целевой сервер SCR может быть локальным или удаленным и может быть резервным сервером или кластером Exchange. Однако SCR не требует наличия кластера ни на какой площадке и отличается от CCR тем, что целевой сервер является резервной средой, а обеспечение отказоустойчивости выполняется вручную. Отметим, что по-прежнему сначала необходимо получить большую копию по проводной связи — фактически полную резервную копию. Время от времени может потребоваться выполнение такой обширной репликации, и следует отдавать себе отчет о ее последствиях для сети, так же, как в случае решений CCR и решений сторонних разработчиков. Я надеюсь на широкое распространение как SCR, так и CCR и дополнительных программных продуктов, предоставляющих аналогичные и иногда более существенные возможности.
-------------------------------------------------------------------------------- Ли Бенджамен (Lee Benjamin) управляет компанией ExchangeGuy, предоставляющей консультативные услуги, где он работает в непосредственном контакте с клиентами, и является консультантом в рамках программы Microsoft Partners. Ли является председателем самой большой в мире группы пользователей Exchange, ExchangeServerBoston, и директором компании BostonUserGroups. Кроме этого, Ли имеет звание MVP по Exchange, является сертифицированным преподавателем Майкрософт и регулярно выступает с докладами на отраслевых конференциях. -------------------------------------------------------------------------------- Из July 2007 выпуска TechNet Magazine
