Когда использовать Loose truncation

Достаточно давно в Exchange Server 2013 добавлена функция loose truncation.

Описание есть в статье Managing mailbox database copies и в блоге What’s new in Exchange 2013 SP1: Loose Truncation

Я бы про нее не вспоминал, если бы кто-то не поинтересовался, а есть ли от неё какая-то практическая польза.

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

Какие могут быть варианты, при которых есть польза от loose truncation?

Вариант 1

Суть функции кратко в том, что если выключено циклическое логирование, то логи почтовой базы удаляются только при бакапе базы. Если же включить loose truncation, то сервер будет удалять логи почтовой базы, когда их накопится больше определенного объёма, не дожидаясь бакапа базы.

Первый критерий: вы используете бакап (резервное копирование), не используете DAG и не используете циклическое логирование

Второй критерий: место под базу сильно ограничено

Третий критерий: возможность делать бакап достаточно часто, чтобы удалять логи, ограничена (нет места, время бакапа установлено административно и т.п.)

Вывод: loose truncation может помочь от остановки сервиса

Проблема: после начала удаления логов будет неизбежная потеря информации в случае если делать восстановление из бакапа.

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

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

Вариант 2

Теперь вариант с DAG. Обычная схема подразумевает включение циклического логирования и наличие lagged copy. Этого достаточно для обеспечения высокой надежности. (Ничто не мешает делать ещё и бакап.)

Если одна из пассивных копий не работает по какой-то причине (остановлена администратором, отказ диска или сервера), то логи активной базы начинают копиться, могут заполнить весь диск и вызвать останов сервиса. Включение loose truncation в подобной ситуации также может помочь. В случае DAG loose truncation учитывает, какое число пассивных копий должно быть здорово прежде, чем начнется удаление логов. (Это важно, т.к. после начала удаления не применённых логов неработающую пассивную копию придется пересоздавать.)

Первый критерий: вы используете DAG и циклическое логирование

Второй критерий: есть достаточно много пассивных копий (четыре как минимум)

Третий критерий: возможность быстро обнаружить отказ пассивной копии и устранить его ограничена (нет мониторинга, нет постоянно доступного специалиста)

Вывод: loose truncation может помочь от остановки сервиса

Проблема: после начала удаления логов неработающую пассивную копию придется пересоздавать

Пример. В описанной конфигурации систему обслуживает приходящий специалист или сильно загруженный администратор – о проблеме они могут узнать только после останова сервиса. Если же работает loose truncation, то останова сервиса не будет, и проблему они найдут при очередной профилактике (когда руки дойдут).

Вариант 3

Вариант с DAG без циклического логирования аналогичен предыдущим вариантам.

Вывод

В определенных случаях вы можете с пользой применить loose truncation. Особенность рассмотренных вариантов в том, что их можно всегда избежать при правильном проектировании, развертывании, мониторинге и эксплуатации системы. Более того это нужно обязательно делать, т.к. loose truncation решает очень узкий круг проблем связанных с недостатком ресурсов, но далеко не все: недостаток ресурсов может вызвать массу других проблем. Таким образом loose truncation носит характер «костыля», который тем не менее в некоторых практических ситуациях может быть полезен. Основное правило должно быть таким: бизнес объективно хочет исправить, но не имеет в данный момент возможности сделать это (например, новое оборудование поступит через полгода) – тогда имеет смысл временно настроить loose truncation.