Предотвращение и средства исправления переполнения Exchange log-диска

В следующем документе я опишу профилактические меры, которые должны помочь Вам избежать исчерпания дискового пространства и в дополнение я также опишу возможные средства исправления, если это (о, ужас!) уже случилось.

Я нахожу, что Exchange сервер является очень сложной системой и, как это бывает в большинстве сложных систем, большинство «тривиальных вещей» может поставить его на колени. Одной из этих «тривиальных вещей» является недостаток дискового пространства на диске, который содержит log-файлы для определённой группы хранения. Когда Information Store(информационное хранилище) идентифицирует недостаток дискового пространства для файлов регистрации группы хранения, оно будет демонтировать хранилища внутри соответствующей группы хранения.

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

Прежде, чем мы углубимся в наши основные темы, я думаю, что важно понять точную роль, которую играют log-файлы.

Описание системы хранения Exchange

Очень упрощённый анализ Exchange сервера может показать то, что Exchange сервер является не более чем сервером базы данных, который имеет некоторые экзотические расширения, с помощью которых пользователи могут манипулировать своими данными. Этот анализ (даже упрощённый) не так далёк от истины и это подчёркивает важность базы данных, которая хранит пользовательскую информацию на Exchange сервере.

Exchange сервер использует технологию баз данных, названную ESE (Extensible Storage Engine), эта технология баз данных основана на JET (Joint Engine Technology) механизме баз данных.

ESE механизм применяет несколько файлов, на которых построена база данных (я определил только те из них, которые важны для нашей темы):

1. Store files (файлы хранения) - файлы хранения держат информацию, которая уже передана на диск. Каждое Exchange хранилище (частное и публичное) состоит из двух файлов:
2. • EDB - Rich-текстовая база данных- хранит информацию в своём собственном формате, названном Microsoft Database Encapsulated Format (MDBEF), которая утверждена MAPI клиентами.
   • STM - Native Content Database (база данных исходного содержания) держит все данные, которые утверждены не-MAPI клиентами.
3. Transaction Log files (файлы регистрации транзакций) - log-файл хранит изменённые данные перед тем, как они передаются в базу данных. Набор log-файлов уникален для группы хранения. Имена log-файлов начинаются с префикса, который идентифицирует группу хранения, к которой они принадлежат- E00XXXXX.log (принадлежат к первой группе хранения). Суффиксом для каждого имени log-файлов является шестнадцатеричный последовательно назначенный номер.
   Активный log-файл для указанной группы хранения всегда называется: EX0.log (X представляет группу хранения), будучи однажды заполненным (5MB), он переименовывается, с использованием следующей по порядку шестнадцатеричной цифры и создаётся новый EX0.log. Так как по умолчанию log-файлы не стираются (по умолчанию группы хранения не используют круговую регистрацию(circular logging)), пространство на log-диске будет в конечном счёте исчерпано. Стандартной процедурой для удаления неиспользуемых log-файлов является резервное копирование системы (полное или пошаговое).
   Как упоминалось ранее, размер log-файла равен 5120KB, если Вы находите, что размер файлов другой, Вы, возможно, видите повреждённый log-файл.
   Каждый набор log-файлов имеет два placeholder(метка-заполнитель) — файла, названных: res1.log и res2.log. Эти файлы используются группой хранения, когда она выходит за пределы дискового пространства, чтобы сохранить изменённую информацию перед демонтированием группы хранения.
4. Checkpoint File(файл контрольной точки) - файл контрольной точки используется, чтобы проследить, какие транзакции были переданы в базу данных, а какие транзакции должны быть переданы в базу данных. Имя файла- EX0.chk (X стоит вместо группы хранения), а его размер равен 8KB.

Используя файлы, описанные выше, ESE механизм(engine) строит базу данных транзакций. Вы, возможно, заметили, что во время описания файла контрольной точки я упоминал транзакции, не объясняя их сущность, поэтому, чтобы вернуть этот долг, здесь мы проходим: транзакцией является набор команд, которые считаются одним логическим модулем — они должны все пройти успешно или потерпеть неудачу(как блок).

Классическим примером транзакции является денежный перевод в банке:

1. Клиент банка даёт заказ на перевод средств из учётной записи A в учётную запись B
2. Деньги вычитаются из учётной записи A
3. Деньги добавляются в учётную запись B

Если происходит сбой в процессе, перед тем, как деньги добавляются в учётную запись B, то всё событие считается сбойным и делается откат назад — поэтому деньги не теряются. Другими словами, вся транзакция должна пройти успешно или сбойно как единое целое.

Следующие шаги описывают события, которые происходят, когда данные передаются или изменяются в хранилище:

1. Пользователь изменяет элемент, который сохраняется в хранилище данных Exchange.
2. Важная информация (информация, которая должна быть изменена) загружается в RAM.
3. Информация изменяется в RAM и одновременно записывается в log-файл(ы).
4. В предопределённые интервалы времени «новые данные» сбрасываются из RAM в базу данных.

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

Основываясь на предыдущем описании того, как функционирует механизм базы данных, можно сказать, что важность log-файлов заключается в сохранении базы данных в непротиворечивом (консистентном) состоянии.

Если работа базы данных прерывается аварийным способом, пока выполняется транзакция или пока «dirty pages(грязные страницы)» (данные, которые уже были изменены, но ещё не переданы в базу данных) ещё существуют в RAM, в следующий раз, когда монтируется база данных, она пройдёт через процесс безопасного восстановления.

Soft-восстановление заставляет незавершённые транзакции откатить назад, а непереданные данные передаться в базу данных.

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

Симптомы

Признаки заполнения log-диска вполне очевидны, во-первых, все хранилища внутри группы хранения будут демонтированы:

Второй признак будет гораздо более наглядным — когда посмотрите на Application Log(прикладной файл регистрации), Вы найдёте событие ID 9559:

Профилактические меры

Лучший способ иметь дело с потерей дискового пространства на log-диске — это не иметь дело с ней вообще — просто попробуйте предотвратить это. Если группа хранения уже была демонтирована из-за недостатка места, Вы как системный администратор оказались не в состоянии защитить Вашу систему.

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

Итак, на этой стадии Вы должны бы спросить себя, как я могу избежать той ужасной судьбы, которая меня ожидает???

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

Профилактические меры — быть бдительным

Если пространство на log-диске близко к истощению, Вы должны знать об этом. Если Вы достаточно бдительны и определяете проблему, пока она ещё она только назревает, Вы можете предпринять действия, чтобы предотвратить её возникновение вообще.

В основном, Ваше оружие выбора может быть любым из следующего:

1. Проверяйте дисковое пространство каждые несколько часов или как минимум один раз в день вручную. Преимущество этого способа состоит в том, что Вам не нужно вкладывать деньги в какой-либо сервис мониторинга, таким образом Ваш бюджет не пострадает. Дополнительное преимущество состоит в том, что Вы не препятствуете работе сервера, запуская сервис мониторинга, мешающий ему. Недостаток весьма очевиден — Вы должны делать это… Сейчас Вы можете быть очень продуктивным системным администратором, но Вы человек, поэтому Вы можете забывать проверять пространство время от времени, а нападение на сервер может произойти ночью, пока Вы крепко спите.
2. Используйте сервис мониторинга. Это решение является автоматическим решением, которое будет контролировать систему и поднимать тревогу, как только обнаружится проблема. Есть много инструментов мониторинга на рынке, из которых Вы можете выбирать; один из них встроен в операционную систему (Performance Monitor). Perfmon выполнит задание после того, как Вы сконфигурируете Alert(предупреждение) (с порогом в 30% доступного дискового пространства) и лучше всего то, что он бесплатен.
   Дополнительно, Вы можете контролировать System Log(системный журнал) на событие 2013 (предупреждение о недостатке дискового пространства). Это предупреждение фактически говорит Вам, что дисковый накопитель уже достиг порога в 10% свободного пространства или меньше. Этот порог может быть изменён путём редактирования реестра, согласно статье 112509 из базы знаний.

Заглядывая в пропасть

Итак, Вы были бдительны. Ваши системы подняли тревогу и Вы готовы броситься в бой — что Вы делаете? Итак, как я сказал ранее, если Вы получили предупреждение о том, что дисковое пространство на грани исчерпания, есть два варианта действий, которые могут быть предприняты:

1. Запускайте онлайновое резервное копирование (полное или пошаговое) — резервное копирование группы хранения с использованием любого из вышеупомянутых методов, удалит ненужные log-файлы, обеспечивая Вам дополнительное дисковое пространство.
2. • Преимущества — Ваша система скопирована. Если система падает после этого дня, то Вы можете восстановиться до исходного состояния на момент, когда она обрушилась (если новые файлы регистрации, созданные после резервного копирования, пережили аварийный отказ).
     Дополнительное преимущество в том, что при использовании этого метода нет времени простоя и Ваше пользовательское сообщество будет довольно.
   • Недостатки — Процесс резервного копирования может занять драгоценное время, которого Вы не имеете. Если log-файлы не будут удалены перед тем, как Вы исчерпаете дисковое пространство, хранилища будут демонтированы.
3. Включите циклическую регистрацию(Circular Logging) для группы хранения- до того, как Вы заревёте и закричите, я действительно понимаю, что хожу по тонкому льду здесь — но решительные ситуации требуют принятия сильнодействующих мер. При включении опции циклической регистрации для группы хранения, пока хранилища ещё смонтированы, log-файлы будут удалены и только пять log-файлов останутся. Включение циклической регистрации может быть сделано путём доступа в свойства группы хранения и проверки опции, называемой «Enable circular logging(разрешить циклическую регистрацию)». Прочитайте и подтвердите предупреждение, которое появляется, и всё готово — наблюдайте, как log-файлы исчезают.
4. • Преимущества — Единственное преимущество здесь — это время. Это быстрейшее решение проблемы.
   • Недостатки — циклическая регистрация(Circular Logging) лишит Вас возможности восстановить систему до состояния на тот момент времени, в который сервер обрушился.

И затем пошёл дождь

Это неизбежно — дождь в конечном счёте пойдёт, поэтому Вы действительно должны прогуливаться под зонтиком…

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

Подготовка к дождливому дню

В нашем случае подготовка к дождливому дню означает сохранение некоторого дискового пространства. Если log-файлы вышли из-под контроля, высвободите дисковое пространство, которое Вы сохранили, и Вы имеете ещё несколько минут/часов для того чтобы решить проблему…

Я смотрел — этот метод практикуется многими администраторами. Они копируют большие объёмы данных на log-диске (приблизительно от 10% до 15% всего объёма диска) и когда они начинают исчерпывать пространство — просто стирают файлы. Стирая метку-заполнитель (placeholder) файлов, системный администратор позволяет себе сделать дополнительную передышку, пока он решает проблему.

Другое преимущество этого метода обнаруживает себя, как только дисковое пространство для log-файлов истощено. Большинство методов, чтобы исправить проблему, займут некоторое время, в течение которого пользователи не имеют доступа к своим данным. Если Вы заранее подготовились и захватили дисковое пространство, как я советовал ранее, чтобы поднять систему и запуститься, всё, что Вы должны сделать — это стереть файлы метки-заполнителя(placeholder) и повторно установить группу хранения. Как только это сделано, Вы можете спокойно обдумывать поиск подручного решения проблемы (для получения дополнительной информации читайте раздел, названный «Заглядывая в пропасть»).

Перенесите log-файлы

Если Вы имеете достаточно (действительно более чем достаточно, предпочтительно ещё намного больше) дискового пространства, чтобы держать log-файлы на другом томе на той же самой системе, Вы можете переместить их туда. Как только Вы переместили log-файлы, Вы можете монтировать базы данных. Так как это является временным решением, после того, как Ваша система заработала, Вы должны решить проблему, используя один из методов, указанных в более раннем разделе, названном «Заглядывая в пропасть».

Слово предупреждения:
Прежде чем выбрать этот ход действий, убедитесь, что Вы учли время простоя, которое испытают клиенты. В зависимости от общего размера log-файлов, перемещение их в новый том может занять длительное время. Кроме того, имейте в виду, что в конечном счёте Вы захотите переместить log-файлы обратно в их первоначальное местоположение — это означает большее время простоя, поскольку перемещение log-файлов будет автоматически демонтировать базы данных в соответствующих группах хранения.

Путь менее «перемещательный»- удалить ненужные log-файлы вручную

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

Почти все Exchange администраторы знают и живут по золотому правилу: «Не удалять Exchange log-файлы вручную!». В основном, я согласен. Если Вы придерживаетесь любого другого курса действий, который может сработать, когда Вы потеряли всё пустое пространство в системе, то используйте его перед тем, как попробовать это.

Пользовательские данные в Exchange хранятся внутри Exchange хранилищ, которые находятся внутри Exchange групп хранения, которые имеют один набор log-файлов для всех хранилищ, которые находятся в этой группе хранения. В некоторый момент времени пользовательские данные могут быть распределены между хранилищами и log-файлами. Чтобы сохранять непротиворечивость хранения, необходимы все файлы баз данных (EDB и STM) и log-файлы, которые имеют непереданные данные.

Единственные log-файлы, которые могут быть удалены вручную — это log-файлы, которые не содержат непереданных данных. Если log-файл, который нужен одному из хранилищ (содержит непереданные данные), был стёрт по ошибке, хранилище становится неконсистентным и не-сборным(время восстановления-woohooo(й-я-хуу)!!).

В этот момент Вы, должно быть, спрашиваете себя — как я могу знать, какие log-файлы уже были переданы (и должны быть стёрты), а какие не были переданы (и не должны быть стёрты)?

Есть два ответа на Ваш вопрос:

1. Файл контрольной точки(Checkpoint)- как упоминалось ранее, файл контрольной точки используется Exchange системой хранения, чтобы идентифицировать точку, вплоть до которой log-файлы уже были переданы в хранилища. Используя инструмент ESEUTIL, системный администратор может выбрать эту информацию из файла контрольной точки (Рис.4).
   Точная команда, используемая чтобы сделать dump из файла — это eseutil /mk .
   Единственная информация, которой мы интересуемся в нём — это строка, которая выглядит подобно следующей: Checkpoint: . В этой строке внутри скобок Вы видите три порции информации, из которых нас интересует только первая- 0xF. Первая порция информации указывает на log-файл, который является граничным, всё перед ним может быть удалено, а всё после него необходимо, чтобы сохранить согласованность баз данных.
   В нашем случае 0xF фактически означает, что префикс log-файла E00 и суффикс 0000F. Поэтому именем файла является E000000F.log.
   Имейте в виду, что стирая log-файлы Вы теряете возможность восстанавливать систему до «момента во времени», поэтому мой совет — просто перемещайте файлы в другое местоположение. Другая выгода, которая получается от перемещения файлов заключается в том, что если что-то идёт не так, Вы всегда можете скопировать все log-файлы обратно в их первоначальное месторасположение.
2. Рис. 4: Дампинг файла контрольной точки
3. Файлы базы данных — Каждый файл базы данных, используемый хранилищем, содержит информацию о log-файлах, которые ей нужны, чтобы стать консистентной. Чтобы выбрать эту информацию из баз данных, системный администратор должен использовать ESEUTIL опять. Команда немного изменяется: ESEUTIL /mh . Вывод может быть заваливающим, но нас интересуют две строки:
4. • State (статус)- эта строка определяет статус базы данных, который может быть одним из двух:
     • Clean Shutdown (чистое отключение) (рис. 5)- указывает, что база данных была демонтирована надлежащим образом или, другими словами, это значит, что все невыполненные транзанкции были переданы в базу данных и она консистентна (нет необходимости ни в каких log-файлах, чтобы перенести её в консистентное состояние).
     • Рис. 5: Чистое отключение
     • Dirty Shutdown(грязное отключение) (рис. 6)- указывает, что база данных была отключена некорректно — невыполненные транзакции из log-файлов не были переданы и база данных не консистентна. В следующий раз, когда хранилище установлено, файлы базы данных будут нуждаться в наличии определённых log-файлов, чтобы стать консистентными — без них хранилище не будет смонтировано.
     Рис. 6: Грязное отключение
   • Log Required (требуемый файл регистрации) — эти строки определяют log-файлы, необходимые, чтобы сделать файл базы данных консистентным.
   • • State: Clean Shutdown (статус: чистое отключение) — строка Log Required будет показывать 0-0, означая, что в log-файлах нет необходимости.
     • State: Dirty Shutdown (статус: грязное отключение) — строка Log Required будет показывать диапазон чисел, типа 17-19. Это диапазон log-файлов, необходимых, чтобы перенести базу данных в консистентное состояние (17, 18, 19). Чтобы указывать имена log-файлов, числа должны быть преобразованы в шестнадцатиричную систему, в нашем случае 11, 12, 13, добавляя префикс к ним (основанный на log-е префикс для группы хранения) E0000011.log, E0000012.log, E0000013.log.

Из обсуждённых методов я предпочитаю использование файла контрольной точки. Это проще и есть только одно место, куда следует смотреть, в противоположность проверке файла базы данных, где Вы должны проверять несколько мест.

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

В заключение

Не доходите до этого. Лучший способ иметь дело с этой проблемой — не иметь с ней дел вообще, Вы должны попробовать удостовериться, что Вы никогда не выйдете за пределы пространства на диске log-файлов — потому что если это случится, Ваши клиенты будут испытывать сервисные «отключения электричества» (outages). Поэтому — будьте осторожны и возьмите зонт!