Загадочные увеличения размера вложений, репликация общих папок и прочее

Мы столкнулись со странным поведением, которое, похоже, относится к размеру файлов присоединенных к сообщению. При отправке внешнему пользователю сообщения электронной почты со, скажем, 11-мегабайтным вложением, сообщение доставляется получателю, как и ожидается. Но если это сообщение (включая вложение) перенаправляется обратно отправителю во внутренней сети, отправитель получает отчет о недоставке (non-delivery report – NDR), указывающий, что сообщение больше, чем текущее системное ограничение или что почтовый ящик получателя полон.

После более пристального рассмотрения вопроса, мы обнаружили, что в какой-то момент после оставления сообщением организации размер вложения увеличивается примерно на 30%. Вопрос таков: почему размер вложений увеличивается при отправке и получении сообщений электронной почты через Интернет? И, что более важно: является ли это ожидаемым поведением?

Ответ: коротко говоря – «да». Часто это ожидаемое поведение не только для Exchange Server 2007, но также и для предыдущих версий Exchange Server, а также для любых систем обмена сообщениями, поддерживающих MIME и использующих Base64, когда нужно закодировать вложения. Когда внутренний пользователь Exchange отправляет сообщение получателю внутри организации Exchange, сообщение не требует преобразования содержимого. Это значит, что роста сообщения или вложений при доставке заметно не будет. Сообщения, отправленные внешним получателям, с другой стороны, могут потребовать преобразования содержимого.

Стандартное сообщение SMTP (также известное как сообщение обычного текста) состоит из оболочки сообщения и содержания сообщения – заголовка и тела сообщения. Эти элементы основаны на простом 7-разрядном тексте US-ASCII. Когда сообщение содержит элементы, не являющиеся простым текстом US-ASCII, эти элементы необходимо закодировать. При работе с таким нетекстовым содержимым, включая вложения, для кодирования используется MIME. Как Exchange 2007, так и предыдущие версии Exchange Server используют алгоритм Base64 для кодирования вложений. И недостатком Base64 является то, что он раздувает вложения на 33%.

В Exchange 2007, за исключением случая использования Outlook Web Access, основная часть относящихся к передаче преобразований содержимого выполняется на транспортном сервере-концентраторе. Подробное объяснение этого можно увидеть в теме "Understanding Content Conversion" («Разбираясь в преобразовании содержимого») на technet.microsoft.com/library/bb232174.

Вопрос: Мы в середине перехода с Exchange 2003 на Exchange 2007. Мы перенесли все почтовые ящики пользователей на серверы почтовых ящиков Exchange 2007, которые все настроены с использованием кластерной непрерывной репликации (Cluster Continuous Replication – CCR). В настоящий момент мы реплицируем все общие папки с нашего старого сервера общих папок Exchange 2003 на сервер почтовых ящиков, использующий CCR. Однако в ходе тестирования мы обнаружили, что если перемещение при сбое, ведущее к потере данных, происходит в кластере CCR, база данных общих папок не восстанавливается на другом узле. Мы также не можем восстановить ее вручную после переноса.

У нас имеется лабораторная среда, отражающая нашу инфраструктуру Exchange 2007 в производственной среде и тестирование показывает, что проблема возникает также и здесь. Мы не сталкиваемся с этой проблемой в случае с любой из наших баз данных почтовых ящиков или любого их кластеров CCR, на котором происходит перемещение при сбое, ведущем к потере данных, так что проблема, похоже относится исключительно к базам данных общих папок на кластерах CCR. Поскольку мы желаем достигнуть настоящего дублирования для всех баз данных, включая базу данных общих папок, не могли бы вы подсказать, что могло вызвать это поведение?

Ответ: методы репликации, используемые CCR и репликацией общих папок в Exchange 2007 чрезвычайно различны. В силу этого, не рекомендуется сочетать несколько баз данных общих папок в организации Exchange с серверами почтовых ящиков на основе CCR, если одна из первых размещена на одном из последних. Это можно проделать в ходе перехода и группа продуктов Exchange поддерживает наличие базы данных общих папок на сервере почтовых ящиков, использующем CCR и, для примера, старом сервере Exchange 2003. Но настоятельно рекомендуется удалить базу данных общих папок с не использующего CCR сервера почтовых ящиков, после репликации всех данных общих папок.

То, что происходит в вашей среде обмена сообщениями Exchange, нормально. При наличии нескольких баз данных общих папок и размещения одной из них на сервере почтовых ящиков, использующем CCR, база данных общих папок на использующем CCR сервере почтовых ящиков, не возвратится к работе при сбое, ведущем к потере данных (то есть, незапланированном отключении питания).

На деле, базу данных общих папок нельзя вернуть к работе, пока ранее бывший активным узел не станет активным снова. Вдобавок, все файлы журнала транзакций для группы хранения, в которой находится база данных общей парки, должны быть доступны.

Если это невозможно, то первой линей защиты должно стать восстановление хранилища общих папок из последней работоспособной резервной копии, проигрывание через доступные журналы и повторное заполнение другого узла из восстановленной базы данных. Как вариант, хранилище общих папок можно создать с нуля. В таком случае, необходимо восстановить первоначальный активный узел, создать новую базу данных общих папок и реплицировать данные общих папок с другого сервера общих папок в организации Exchange.

Что может показаться странным, так это то, что при выполнении отключения без потерь (запланированного) база данных общих папок возвращается к работе. Такое поведение ожидаемо. Дополнительную информацию можно найти в статье "Cluster Continuous Replication and Public Folder Databases" («Кластерная непрерывная репликация и базы данных общих папок») в материалах по "Planning for Cluster Continuous Replication («Планирование кластерной непрерывной репликации»)".

Вопрос: Все серверы почтовых ящиков внутри нашей инфраструктуры обмена сообщениями, основанной на Exchange 2007, настроены с помощью CCR. Мы вполне удовлетворены работой CCR, но у нас есть вопрос, на который, мы надеемся, вы сможете ответить.

При выполнении оперативного обслуживания каждую ночь, одной из задач является оперативная дефрагментация. Как обеспечить, чтобы базы данных на пассивном узле в кластере CCR подвергались дефрагментации в ходе оперативного обслуживания?

Ответ: Задача оперативной дефрагментации, удаляющая все элементы, помеченные для удаления и превращающая пространство, использовавшееся этими элементами в пустое пространство, создаст новый журнал транзакций в ходе процесса. Любые файлы журнала транзакций, созданные на активном узле CCR, будут реплицированы на пассивный узел, ведя к выполнению изменениям, выполняемых в базах данных также и на пассивном узле.

Держа это в уме, пожалуйста убедитесь, что временное окно оперативного обслуживания установлено так, что оно не конфликтует с окном резервного копирования, поскольку это приводит к остановке оперативной дефрагментации. Если на то пошло, выполнение дефрагментации каждый день, неделю и даже каждую вторую неделю необязательно. В прошлом, рекомендации от группы разработчиков Exchange указывали на необходимость выполнения оперативной дефрагментации, как минимум, каждую вторую неделю. Но это изменилось с выходом Exchange Server 2007 с пакетом обновления 1, поскольку среда каждой организации различна. Дополнительные сведения об этом новом руководстве можно найти, прочитав запись в Блоге группы Microsoft Exchange.

Вопрос: Мы планируем использовать Exchange 2007 CCR, чтобы достичь настоящего дублирования для наших серверов почтовых ящиков. В настоящий момент, мы рассматриваем то, как транспортная корзина используется в сочетании с CCR, чтобы обеспечить отсутствие потери сообщений в случае перемещения при сбое, ведущем к потере данных, с активного узла CCR на пассивный. Знаете ли вы о каких-либо ловушках, связанных с транспортной корзины, которые нам лучше держать в уме?

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

Вопрос: в настоящий момент мы планируем перенос между лесами из организации Exchange 2003 в организацию Exchange 2007, в новом лесу Active Directory. Мы тщательно изучили документацию по переносу между лесами, "How to Transition from Single Forest to Cross-Forest («Как выполнить переход от одного леса к нескольким»)", которая указывает на то, что следует создать доверие лесов, а не внешние отношения доверия между лесами. Почему нельзя использовать внешние отношения доверия?

Ответ: Хотя документация Exchange 2007 на TechNet и говорит, что вместо внешних отношений доверия следует использовать доверие лесов, это не значит, что нельзя использовать первые. На самом деле, они вполне нормально работают для переноса Exchange между лесами, но у них имеется один недостаток. Для доступа к контроллеру домена в доверенном лесу при создании связанного почтового ящика необходимо указать учетную запись с должными разрешениями (см. рис. 1), поскольку учетные данные вошедшего в систему пользователя невозможно использовать, вне зависимости от того, какие ему выделены разрешения.

Увеличить

Рис. 1. Указание учетной записи на странице основной учетной записи при создании связанного почтового ящика

Вопрос: наша организация только что перешла на Exchange 2007 и пока что мы очень довольны новой версией, за одним возможным исключением. Когда мы еще использовали Exchange 2003 с пакетом обновления 2, мы имели возможность настраивать нашу среду так, что простое отображаемое имя почтового ящика пользователя демонстрировалось как отправитель исходящего сообщения. К нашему разочарованию, мы не смогли найти подобной функции в Exchange 2007. Пожалуйста не говорите нам, что эта функция отсутствует в Exchange 2007!

Ответ: эта функция действительно отсутствовала начиная от окончательной первоначальной версии Exchange 2007 и до Exchange 2007 с пакетом обновления 1 и набором обновлений 4 (RU4), выпущенного в октябре 2008. В SP1 RU4, можно опять, как и в Exchange 2003 с пакетом обновления 2, настроить Exchange на демонстрацию простого отображаемого имени на исходящих сообщениях. Эту задачу можно выполнить, используя командлет Windows PowerShell Set-RemoteDomain с параметром –UseSimpleDisplayName. Например, чтобы сделать возможным простые отображаемые имена в исходящих сообщениях, отправляемых домену contoso.com, используйте команду, показанную на рис. 2.

Увеличить

Рис. 2. Использование простых отображаемых имен для исходящих сообщений

Вопрос: каков лучший способ дефрагментации копий базы данных на пассивном узле сервера почтовых ящиков, использующего Exchange 2007-CCR? Не запутается ли Exchange, если базы данных на одном из узлов в CCR дефрагментированы, а на других нет?

Ответ: если требуется оперативная дефрагментация, ее всегда следует выполнять на активном узле в кластере CCR, а не на пассивном. Держите в уме, что при выполнении оперативной дефрагментации одной или нескольких баз данных на активном узле, требуется полное перезаполнение этих баз данных на пассивном узле.

Это значит, например, что при наличии базы данных объемом в 200 ГБ (при использовании CCR, рекомендованный объем базы данных составляет 200 ГБ при репликации через 1-гигабайтную сеть), ее дефрагментация займет несколько часов (стоит ориентироваться на 2-4 ГБ в час). Но после завершения процесса дефрагментации также потребуется реплицировать свыше 200 ГБ данных на пассивный узел. Если доставка файла журнала происходит через общую сеть, это может сказаться на общей производительности сети, с которой имеют дело конечные пользователи.

В большинстве случаев, причиной выполнения оперативной дефрагментации является удаление любых пробелов в базе данных, чтобы уменьшить ее размер. Но это редко необходимо, поскольку пустые места будут использованы повторно, прежде чем база данных вырастет дальше. И то, имеется ли доступное место в базе данных, или на самом диске, не имеет значения, верно?

Если в базе данных имеется много гигабайт пустого пространства и его требуется удалить, лучшим подходом будет перемещение всех почтовых ящиков из старой базы данных в новую.