Архитектура хранилища Exchange Server
ESE и управление памятью. Перед загрузкой страницы в память ESE должна зарезервировать в памяти область для использования ее в своих целях. Динамическое отведение буфера (DBA) является процессом увеличения размера кэша буфера базы данных перед тем, как возникает надобность в использовании памяти. Достаточно большое число администраторов Exchange пришли к выводу, что Exchange занимает на серверах всю память. Эта ситуация является умышленной, и хотя она не обязательно должна приводить к использованию всей памяти, память, отводимая для Exchange, не является недоступной для других системных процессов. Если процессам требуется дополнительная память, Exchange освободит память для их эффективной работы. Это происходит непосредственно во время работы, и методы, используемые ESE, не являются настраиваемыми.
В Exchange 4 и 5.0 размер кэша устанавливался компонентом Performance Optimizer (Оптимизатор производительности). В Exchange 5.5 этот процесс стал динамическим: ESE исследует систему и настраивает размер кэша базы данных по мере необходимости. Для выяснения объема памяти, резервируемого процессом Store, следует использовать счетчик производительности Cache Size (Размер кэш-памяти).
Теперь самое время выделить общие цели, для достижения которых предназначен процесс DBA. Их знание и понимание поможет легко ответить на любые вопросы относительно управления памятью в Exchange Server 2003. Целями создания DBA являются:
- достижение максимального уровня производительности системы. Процесс Store использует общее значение активности страничной организации памяти и ввода/вывода, а также другие факторы для определения количества оперативной памяти, отводимой для буфера базы данных. Данная цель в действительности сфокусирована на общей производительности системы. Ускорение работы Exchange бесполезно, если операционная система постоянно выполняет работу со страницами памяти;
- максимизация использования памяти. Неиспользуемая системная память – это потерянные деньги. ESE отводит для себя столько памяти, сколько это возможно, без негативного влияния на другие приложения. Если запускается другое приложение, требующее дополнительного объема памяти, ESE освобождает память для обеспечения эффективной работы этого приложения.
Не стоит беспокоиться, если вы увидите, что в Task Manager (Диспетчер задач) от 1 Гб оперативной памяти системы осталось только 200 Мб, и процесс Store использует все 800 Мб. Недостатка в памяти нет, и процесс Store.exe не содержит утечку памяти. Это лишь означает, что функция DBA машины ESE отвела дополнительный объем оперативной памяти для увеличения производительности системы. На рисунках 2.6 и 2.7 показано, как это выглядит в программе Task Manager (Диспетчер задач). На рисунке 2.6 видно, что процессы Store.exe и Mad.exe используют больший объем памяти, чем большинство других процессов. Это изображение сохранено с экрана сервера, который не был загружен работой, а процесс Store.exe по-прежнему находился на первом месте в списке по уровню использования памяти. На рисунке 2.7 видно, что доступный объем системной памяти равен лишь 49 176 Кб. Обратите внимание на область Physical Memory (K) (Физическая память, Кб), а именно на значение Available (Доступно).
Рис. 2.6. Вкладка Processes (Процессы) в Диспетчере задач Windows, отображающая объем памяти, отведенный для процессов Store.exe и Mad.exe
Рис. 2.7. Вкладка Performance (Производительность) в Диспетчере задач Windows, отображающая уровень использования памяти и ее свободный объем
Файлы журналов транзакций. Теоретически файл журнала транзакции может постоянно увеличиваться. Однако если его размер увеличится до такой степени, что займет очень много пространства на диске, то это сделает работу с ним крайне затруднительной. По этой причине журнал разбивается на поколения, т.е. на несколько файлов, каждый из которых имеет размер 5 Мб и представляет собой определенное поколение. Поколению файла журнала присваивается имя EdbXXXXX.log, где XXXXX представляет собой последовательно увеличивающееся шестнадцатеричное число.
Файл Edb.log представляет собой самое первое поколение. Когда он заполняется, ему присваивается имя со следующим шестнадцатеричным номером. При этом создается временный файл журнала Edbtemp.log для регистрации транзакций, пока не будет создан новый файл Edb.log.
Каждый файл журнала состоит из двух частей – заголовка и данных. Заголовок содержит жестко запрограммированные пути к соответствующим базам данных. В Exchange Server 2003 несколько баз данных могут использовать один и тот же файл журнала, так как файлы журналов обслуживают всю группу хранилищ. С точки зрения администрирования данный подход упрощает процесс восстановления. Независимо от того, какая база данных в группе хранилищ подвергается восстановлению, будет происходить обращение к одним и тем же файлам журналам рассматриваемой группы. Заголовок также содержит подпись, сверенную с подписью базы данных. Это предотвращает сопоставление файла журнала другой базе данных с идентичным именем.
Можно осуществлять разгрузку информации заголовка файла журнала с помощью команды ESEUTIL /ML (см. рис. 2.8). В процессе разгрузки отображается номер поколения, пути базы данных и подписи. Часть файла журнала с данными содержит данные о транзакциях, например BeginTransaction (Начало транзакции), Commit (Фиксирование) и Rollback (Откат). Большая часть файла содержит низкоуровневые физические изменения базы данных. Иными словами, эти записи можно интерпретировать следующим образом: "Данная информация была добавлена в эту страницу в такое-то место".
Изменение базы данных состоит из нескольких этапов. Во-первых, страница считывается в кэш базы данных, после чего обновляется временной штамп этой страницы. Временной штамп инкрементируется для каждой базы данных по отдельности. После этого создается запись журнала с констатацией того, какие действия будут произведены в базе данных. Это происходит в буфере кэш-памяти журнала. Затем страница подвергается изменению, и между этими двумя записями устанавливается связь, не позволяющая записать страницу на диск без предварительного переноса на диск записи файла журнала. Данный этап гарантирует запись изменения базы данных в файл журнала перед обновлением базы данных на диске.
Таким образом, существует разумная концепция кэширования обратной записи, реализуемая на диске с файлом журнала. По существу, кэширование обратной записи подразумевает под собой процесс, в ходе которого оборудование передает обратно в ESE отчеты об успешной записи на диск, даже если информация находится в буфере диска контроллера, и ее непосредственная запись на диск отложена на более позднее время. Кэширование обратной связи, несмотря на улучшение производительности, может прерывать процесс ESE записи изменений в файл журнала перед их занесением в базу данных. При неполадках в работе контроллера или диска может возникнуть ситуация, когда страница будет записана на диск, но не зарегистрирована в файле журнала, что приведет к повреждению базы данных.
Повторное считывание файлов журнала при восстановлении. После восстановления базы данных журналы повторно считываются при запуске процесса Store.exe. Повторное считывание журналов и последующий откат операций являются составными частями "запуска" процесса Store; эта процедура часто называется процессом восстановления. Повторное считывание журналов транзакций представляет собой первую часть процесса восстановления и занимает большую часть времени, необходимого для запуска процесса Store.exe.
Повторное считывание файлов журналов транзакций заключается в том, что для каждой записи журнала считывается страница, соответствующая записи, и временной штамп на этой странице сравнивается с временным штампом записи журнала, ссылающейся на эту страницу. Если временным штампом записи журнала является 12, а страницы, считываемой из базы данных – 11, ESE определяет, что изменение, зафиксированное в файле журнала, не было записано на диск, и запись журнала заносится в базу данных. Однако если значение временного штампа страницы на диске больше или равно временному штампу записи журнала, ESE не записывает эту запись журнала на диск и переходит к следующей записи в журнале.
Во второй, завершающей, фазе процесса восстановления происходит откат всех незафиксированных операций: если передана часть сообщения электронной почты, то его передача отменяется, если сообщение удалено, оно восстанавливается. Этот процесс называется физическим повторением и логической отменой. Восстановление происходит при каждом запуске процесса Store.exe. Если остановить и запустить процесс Store пять раз, то процесс восстановления также будет выполнен пять раз.
Несмотря на то что процесс восстановления выполняет действия с файлами журналов и не затрагивает базы данных, в случае перемещения баз данных восстановление не будет функционировать, так как закодированный в заголовке файла журнала путь к базе данных уже не будет указывать на базу данных. По окончании восстановления выполнение процесса будет казаться успешным, однако при попытке использования соответствующей базы данных сгенерируется сообщение об ошибке с идентификатором события 9519 из журнала приложения MSExchangeIS, предупреждающее об ошибке запуска базы данных (см. рис. 2.9).
Если возвратить базу данных в место расположение, указанное в заголовке файла журнала, а затем запустить процесс Store, процесс восстановления вернет базу данных в консистентное рабочее состояние.
Файл контрольной точки. Файл контрольной точки оптимизирует процесс восстановления. Он фиксирует информацию о том, какие записи в файлах журналов уже записывались на диск. Если все записи файлов журналов записаны на диск, то в процессе восстановления не потребуется их повторного считывания. Файл контрольной точки может сократить время восстановления, сообщая ESE о том, какие записи файла журнала нужно считать повторно, и какие не требуют повторного считывания.
Иногда ускорить процесс восстановления баз данных помогает использование циклического ведения журналов. При этом происходит удаление файлов журналов, более старых, нежели текущее местонахождение контрольной точки. Недостаток циклического ведения журналов заключается в том, что теряется возможность восстановления работоспособности системы с повтором всех завершенных транзакций, записанных на архивный накопитель. Если некоторые файлы журналов удалены в рамках циклического ведения журналов после проведения последней полной архивации, можно произвести восстановление только с использованием последнего полного архива. Однако при наличии всех старых файлов журналов восстановление с помощью последнего полного архива базы данных с резервного накопителя позволит произвести полное восстановление вплоть до момента сбоя, так как все файлы журналов смогут быть повторно считаны и записаны в восстановленную базу данных. Следует помнить, что для осуществления полного восстановления база данных должна находиться в том же физическом состоянии, в котором она находилась в момент записи файлов журналов. Физически поврежденную базу данных восстановить нельзя.
Внимание! Никогда, никогда, никогда не удаляйте файлы журналов! Предположим, файл журнала 9 содержит команду добавления новой страницы в определенное место базы данных. Файл журнала 10 содержит команду удаления этой страницы. Теперь предположим, что администратор удаляет файл журнала 9, возможно, по причине того, что этот файл слишком устарел, и удаляет файл контрольной точки. После этого администратор решает перезагрузить систему по каким-либо иным причинам. При запуске процесса Store.exe ESE автоматически переходит в режим восстановления. Не обнаружив файла контрольной точки, ESE не сможет сделать ничего, кроме повторного считывания всех файлов журналов. При повторном считывании файла журнала 10 команда удаления будет выполнена на соответствующей странице, и ее содержимое будет уничтожено. ESE не известно о том, что имела место более ранняя команда добавления новой страницы в это расположение базы данных,
так как файл журнала 9 удален. Таким образом, база данных станет поврежденной. Ни при каких обстоятельствах не удаляйте файлы журналов! Более того, имейте в виду, что кэширование обратной записи может вызвать удаление файлов журналов. Рекомендуется отключить кэширование обратной записи и никогда не удалять файлы журналов и файл контрольной точки.Занесение в базу данных записей журнала. Как уже упоминалось ранее, измененные страницы в памяти и фиксированные транзакции в области буфера журнала не записываются на диск немедленно. Фиксированные транзакции в файле журнала транзакций копируются в базу данных при возникновении одного из следующих условий:
- контрольная точка находится слишком далеко в прежнем файле журнала. Если число фиксированных транзакций в файлах журналов достигает определенного порогового значения, ESE сбрасывает эти изменения на диск;
- число свободных страниц в памяти стало слишком мало, что, возможно, сказывается на производительности системы. В этом случае фиксированные транзакции в памяти сбрасываются на диск, чтобы освободить страницы в памяти для использования системой;
- другая служба запрашивает дополнительный объем памяти, и ESE требуется освободить некоторое количество памяти, занимаемой ESE в данный момент. ESE сбрасывает страницы из памяти в базу данных, после чего обновляет файл контрольной точки;
- служба базы данных отключается. В этом случае все обновленные страницы в памяти копируются в файл базы данных.
Имейте в виду, что страницы не копируются из памяти в каком-либо определенном порядке и могут не копироваться все сразу. Случайный порядок копирования страниц на диск означает, что при сбое в системе во время записи страниц на диск файл базы данных может содержать лишь части фиксированной транзакции, обновленные непосредственно в файле. В этом случае при запуске процесса Store транзакция будет повторно считана из файлов журнала транзакций, и обновление базы данных будет произведено полностью.