Windows Server Backup (WSB) — функция Windows Server, на основе которой можно создать эффективный подход к созданию резервных копий данных Exchange, но она накладывает кое-какие специфические требования к конфигурации. При резервировании данных Exchange с помощью WSB вам потребуется как минимум один диск для хранения резервных копий. Это может быть либо физический диск сервера, либо диск устройства хранения.
При запуске WSB не будет никакого сообщения о том, что он поддерживает Exchange Server 2010. Если базы данных Exchange находятся, например, на дисках G:\ и H:\, вы должны вручную выбрать эти диски в WSB.
После выбора этих дисков выберите еще один диск для хранения самих резервных копий. Это может быть любой диск, за исключением тех, на которых в данный момент выполняется резервирование, или системного диска (т.е. диска C:\). При запуске резервирования вы увидите, что WSB проверяет целостность базы данных Exchange.
Когда WSB завершит резервирование базы данных Exchange, заголовок базы данных обновится соответствующей информацией о резервировании. Можно посмотреть статус базы данных командой ESEUTIL /MH:
G:\mailbox database 0242942819>eseutil /mh "mailbox database 0242942819.edb"
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.00
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Database: mailbox database 0242942819.edb
Previous Full Backup:
Log Gen: 4-5 (0x4-0x5) - OSSnapshot
Mark: (0x6,8,16)
Mark: 08/08/2009 11:39:06
Previous Incremental Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00
Operation completed successfully in 0.31 seconds.
G:\mailbox database 0242942819>
[Edited for readability]
Кроме того, WSB протоколирует все операции в журнале событий. При его просмотре в Event Viewer вы увидите события Extensible Storage Engine (ESE) и MSExchangeIS, например:
Log Name: Application
Source: ESE
Date: 8-8-2009 11:39:05
Event ID: 2005
Task Category: ShadowCopy
Level: Information
Keywords: Classic
User: N/A
Computer: EXMBX12.labs.local
Description:
Information Store (2444) Shadow copy instance 1 starting. This will be a Full shadow copy.
For more information, click http://www.microsoft.com/contentredirect.asp.
Кроме того, вы увидите что-то наподобие:
Log Name: Application
Source: MSExchangeIS
Date: 8-8-2009 11:39:05
Event ID: 9811
Task Category: Exchange VSS Writer
Level: Information
Keywords: Classic
User: N/A
Computer: EXMBX12.labs.local
Description:
Exchange VSS Writer (instance 1) has successfully prepared the database engine for a full or copy backup of database 'mailbox database 0242942819'.
После успешного завершения резервирования файлы журнала будут удалены. Какие именно файлы журнала удаляются, зависит от того, насколько загружен сервер во время резервирования (например, имеется ли много новых сообщений, происходит ли перемещение почтовых ящиков и т.д.) и от глубины контрольных точек. Удаление файлов журнала также отображается в журнале событий:
Log Name: Application
Source: ESE
Date: 8-8-2009 11:39:19
Event ID: 224
Task Category: ShadowCopy
Level: Information
Keywords: Classic
User: N/A
Computer: EXMBX12.labs.local
Description:
Information Store (2444) mailbox database 0242942819: Deleting log files G:\mailbox database 0242942819\E0000000001.log to G:\mailbox database 0242942819\E0000000003.log.
WSB поддерживает только полное резервирование (full backup) или резервирование копированием (copy backup). Он не позволяет создавать инкрементные или разностные резервные копии.
Репликация баз данных
Кроме того, WSB может создавать резервные копии баз данных, которые входят в группы доступности баз данных (database availability group, DAG). Однако у WSB имеется одно ограничение — то, что можно резервировать только активную копию базы данных. Если вы резервируете активную копию, то резервирование пройдет успешно. Когда активная копия переносится на другой сервер и локальная база данных становится пассивной, резервирование терпит неудачу.
Процесс создания резервных копий идентичен описанному ранее, если не считать усечения файлов журнала. Файлы журнала усекаются, только если все файлы журнала реплицированы и переданы в другие копии базы данных. Только после этого файлы журнала активной копии усекаются. Для этого требуется некоторое время, не такое большое, чтобы беспокоиться. Информация об этом также отражается в журнале событий:
Log Name: Application
Source: MSExchangeIS
Date: 8-8-2009 11:54:16
Event ID: 9827
Task Category: Exchange VSS Writer
Level: Information
Keywords: Classic
User: N/A
Computer: EXMBX01.labs.local
Description:
Exchange VSS Writer (instance 725e6ff5-7fd0-4c52-9bf1-f62fafc425ea:5) has successfully completed the full or incremental backup of replicated database 'Mailbox Database 1444276156'.
Файлы журнала будут усекаться после того, как вы примените содержащиеся в них изменения.
Высокая доступность
Чтобы среда Exchange Server 2010 полностью обеспечивала высокую доступность, вы должны настроить не только сами по себе серверы Mailbox, но и еще серверы Hub Transport, Client Access servers и Edge Transport (если вы их используете). Конфигурации этих серверных ролей, поддерживающие высокую доступность (high availability, HA) довольно сильно отличаются от конфигураций серверной роли Mailbox. Однако они аналогичны конфигурациям этих ролей в Exchange Server 2007.
Серверы Hub Transport
Чтобы обеспечить избыточность при транспортировке, потребуется как минимум два сервера Hub Transport. При создании Send Connector можно определить исходный сервер, который отправляет сообщения через него. Для обеспечения избыточности можно добавить второй Hub Transport как исходный сервер:
- Войдите в Exchange Server и откройте Exchange Management Console.
- Раскройте сервер Exchange On-Premises и раскройте лист Organization. Щелкните лист Hub Transport и выберите вкладку Send Connectors.
- Щелкните правой кнопкой Send Connector, который собираетесь изменить, и выберите Properties.
- В свойствах Send Connector выберите вкладку Source Server.
- Щелкните кнопку Add, чтобы добавить в Send Connector второй сервер Hub Transport.
- После выбора второго сервера дважды щелкните OK.
Теперь для сервера Hub Transport будет поддерживаться резервный путь (redundant path) и будет осуществляться автоматическое балансирование исходящих сообщений между двумя исходными серверами. При балансировании исходящего SMTP-трафика между двумя серверами Hub Transport будет использоваться циклический механизм.
Для входящих сообщений потребуется вручную реализовать решение по балансированию нагрузки. Это может быть решение на основе Interent Security and Acceleration (ISA) Server 2006 или на основе любой аппаратуры, поддерживающей балансирование входящего SMTP-трафика. Можно также использовать Windows Server 2008 Network Load Balancing (NLB), учитывая, что это готовое решение Microsoft.
С помощью NLB можно построить решение по балансированию нагрузки под управлением Windows, которое будет отслеживать все входящие соединения и автоматически балансировать запросы между серверами Hub Transport. Такие решения полностью поддерживаются, начиная с Exchange Server 2007 SP1. Последний вариант — использовать для балансирования нагрузки, создаваемой входящим трафиком, циклический метод распределения нагрузки DNS.
NLB поддерживает только входящие SMTP-соединения, но не исходящие. Вы не можете установить его на любой сервер, который уже служит хостом для DAG. На сервере, который служит хостом для DAG, должен функционировать кластер Windows с поддержкой восстановления после сбоя, а NLB не может сосуществовать с такими кластерами.
Серверы Client Access
Для обеспечения избыточности на уровне серверов Client Access потребуется реализовать как минимум два сервера, для которых должно осуществляться балансирование нагрузки на уровне протокола. Решением по балансированию нагрузки может быть либо решение на основе Microsoft ISA Server 2006, либо аппаратное решение по балансированию нагрузки. Как и в случае серверов Hub Transport, можно еще использовать NLB для балансирования нагрузки при соединении с серверами Client Access (если они не служат хостами для DAG).
Серверы Edge Transport
При использовании решения Edge Transport в DMZ вашей сети потребуется как минимум два сервера Edge Transport. Имейте в виду, что у всех серверов Edge Transport свои собственные экземпляры Active Directory Lightweight Directory Service (AD LDS, ранее называлась Active Directory Application Mode или ADAM). Кроме того, все серверы Edge Transport имеют свои собственные подписки на серверы Hub Transport сети компании.
Когда несколько серверов Edge Transport подсоединены к одному и тому же сайту, они автоматически добавляются как исходные серверы в принимающий Send Connector. Между серверами Edge Transport осуществляется балансирование нагрузки аналогично тому, как это делается между серверами Hub Transport.
Благодаря новой функциональности DAG в Exchange Server 2010 теперь можно создавать HA-решения на уровне серверов Mailbox. Эта функциональность замещает Continuous Cluster Replication (CCR) и Standby Continuous Replication (SCR) в Exchange 2007. Скажем прямо: DAG это, чем должны были быть CCR/SCR. Это более гибкое и мощное и менее сложное решение, чем CCR/SCR. И оно, в самом деле, содержит лучшее из этих двух технологий.
HA-решения в серверных ролях Hub Transport и Client Access реализуются с балансированием нагрузки на уровне протокола. Вы можете добиться этого, используя аппаратный балансировщик нагрузки, или Windows NLB, или с помощью циклического метода распределения нагрузки DNS. Этот процесс особо не изменился.
Теперь вы знаете, как добиться, чтобы ваш Exchange Server всегда был работоспособен. Конечно, это всего лишь практическое руководство, позволяющее приступить к работе. Чтобы сделать вашу среду Exchange устойчивой к катастрофам, придется изучить гораздо больше.