Работа с группами хранения
Планирование пространства на диске
Рассмотрим некоторые вопросы планирования. Надеемся, что вы уделите достаточное внимание этому параграфу. Поскольку данная лекция посвящена группам хранения, мы рассмотрим здесь планирование таких аспектов, как объем пространства на диске, использование нескольких баз данных и нескольких групп хранения. (Для получения более подробных сведений по планированию для Exchange Server 2003 обратитесь к "Определение требований" .) Планируя объем пространства на диске для сервера Exchange 2003, следует учесть следующие ключевые факторы:
- количество пользователей, которых нужно разместить на данном сервере Exchange;
- типы пользователей, которых нужно разместить на данном сервере Exchange;
- средний размер одного сообщения и одного вложения электронной почты, а также количество вложений, которое потребуется отправлять и получать пользователям;
- количество и размер общих папок.
В следующих двух разделах описано, как рассчитать необходимый объем пространства на диске сервера Exchange.
Расчет пространства на диске для сообщений и вложений электронной почты
Прогнозирование интенсивности обмена сообщениями между пользователями информационной системы является нелегким делом. Некоторые пользователи отправляют и принимают лишь несколько сообщений в день. Другие отправляют и получают множество сообщений и некоторые – с большими вложениями. Очевидно, что при одинаковых возможностях оборудования можно разместить в одном хранилище почтовых ящиков больше пользователей с небольшим объемом корреспонденции. Это наиболее простой путь, но все же будет лучше, если разработать систему классификации для рассматриваемой среды и затем провести подсчеты, чтобы определить, сколько пользователей можно разместить в каждом хранилище, в каждой группе хранения и, наконец, на каждом сервере. Если получится составить приблизительную картину текущего использования системы обмена сообщениями, то представится возможным более точно прогнозировать требования к оборудованию и группам хранения.
Для достижения этой цели рекомендуется получить случайную выборку пользователей системы (не менее 15%) и затем провести анализ текущего использования электронной почты в папке Sent Items (Отправленные), чтобы получить представление о количестве сообщений, отправляемых каждый день, и о размере этих сообщений. Вы можете также определить, сколько сообщений содержат вложения, а раскрыв сообщения, – размеры этих вложений. Соображения безопасности могут не позволить получить эту информацию от некоторых пользователей, и в этих случаях попросите их заполнить небольшую анкету.
Собрав необходимые данные, их необходимо проанализировать. Эта часть работы состоит из расчета некоторых показателей. Рассмотрим следующий пример. Предположим, что проводится анализ по 45 пользователям (из 300) в течение 60 дней и определяется, что среднее количество сообщений электронной почты в день, приходящихся на одного пользователя, равно 14 с двумя вложениями. И еще предположим, что средний размер каждого сообщения составляет 1 Кб, а средний размер каждого вложения – 200 Кб. Расчет проводится следующим образом:
- 14 сообщений x 1 Кб = 14 Кб в день для сообщений электронной почты;
- 2 вложения x 200 Кб = 400 Кб в день для вложений;
- средний объем используемого пространства на диске: 828 Кб в день (414 Кб для хранилища и 414 Кб для журналов транзакций);
- 828 Кб x 300 пользователей = 248400 Кб (248,4 Мб) пространства на диске в день для всех 300 пользователей. На два месяца (60 дней) приходится 44 рабочих дня, то есть потребуется 10929 Мб (10,9 Гб) пространства на диске.
Это последнее значение несколько неточно, поскольку журналы транзакций не хранятся бесконечно долго. В конечном счете, система ESE удалит старые журналы, освобождая пространство на диске, которое будет снова использоваться журналами транзакций. Поэтому давайте предположим, что ESE хранит только часть журналов за последнюю неделю, то есть 5 x 414 Кб = 2070 Кб. Таким образом, для работы Exchange Server 2003 через два месяца потребуется только 5466870 Кб, то есть 5.4 Гб (44 дня x 414 Кб в среднем х 300 пользователей плюс 2070 Кб для журналов).
И это еще не все. Мы только определили объем пространства на диске, необходимый для записи сообщений и вложений электронной почты. Нам нужно еще оценить общие папки и производительность устройств резервного копирования.
Расчет пространства на диске для общих папок
Чтобы показать, как рассчитывается объем пространства на диске, необходимого для общих папок, предположим, что каждый пользователь помещает в общие папки примерно три документа в день со средним размером одного документа 6 Кб. (Если этот размер документа кажется слишком большим, обратитесь к "Архитектура хранилища Exchange Server" , где рассматривается архитектура хранилища. Мы еще не раз будем рассматривать хранение различных типов документов в Exchange.) Рассчитаем объем пространства на диске для общих папок следующим образом: 3 документа x 300 пользователей x 6 Кб x 2 (поскольку каждый документ записывается в хранилище и журнал транзакций). В результате получаем, что для размещения документов пользователей в общих папках требуется 10800 Кб (10,8 Мб) пространства на диске. На 44 дня потребуется 237600 Кб (237,6 Мб) плюс 27000 Кб для журналов транзакций (3 документа х 300 пользователей х 6 Кб х 5 дней), что даст в сумме за два месяца 264600 Кб (264,6 Мб) пространства на диске, необходимого для общих папок. Таким образом, потребуется 5,46 Гб для сообщений электронной почты и 264,6 Мб для общих папок, или приблизительно 5,7 Гб на период в два месяца. Но планирование еще не закончено. Теперь нужно определить, как использовать эти значения в процессе планирования групп хранения.
Планирование нескольких групп хранения
Получив оценку необходимого пространства на диске, необходимо оценить, сколько потребуется групп хранения. Одним из факторов, который нужно учесть, является различие приоритетов работы, которую выполняют пользователи. Предположим, что 20 из 300 пользователей рассматриваемой системы выполняют критически важную работу. Возможно, это персонал отдела продаж, который принимает заказы по телефону или обрабатывает заказы клиентов, размещаемые в общей папке, представленной на веб-сайте. Предположим, что при отключении этих пользователей даже на 15 минут компания теряет более 50000 долларов. При подобной ситуации стоит подумать о том, чтобы разбить этих пользователей на две группы и поместить каждую группу в ее собственные хранилища почтовых ящиков и общих папок. Однако здесь нет необходимости размещать их в отдельной группе хранения.
Причиной такой рекомендации является то, что в случае повреждения других баз данных эти пользователи смогут продолжать свою работу, поскольку вы можете отключить и восстанавливать одно или несколько хранилищ, в то время как другие хранилища той же группы хранения продолжают работать. И если потребуется восстановление базы данных одной группы этих пользователей, это будет сделано быстро, поскольку эта база данных намного меньше, чем база данных всей компании, в которой хранится информация остальных 280 пользователей. Кроме того, поскольку критические пользователи распределены по двум базам данных, вторая половина группы сможет продолжать работу. Таким образом, следует планировать группы хранения, уделяя большее внимание вопросам аварийного восстановления, чем вопросам использования пространства на диске.
Планирование производительности устройств резервного копирования
Еще одним фактором в планировании групп хранения является уровень производительности, который потребуется при восстановлении. Предположим, что вы приобрели ленточный накопитель с максимальной скоростью 10 Гб в час, или 166,6 Mб в минуту. При такой скорости восстановление баз данных с резервной копии на ленте займет приблизительно 35 минут, если все пользователи включены в одну базу данных. С учетом времени, необходимого для диагностирования проблемы, поиска лент и восстановления, можно предположить, что пользователи системы не смогут пользоваться электронной почтой и общими папками от одного до двух часов (в зависимости от характера проблемы, а также от времени, которое потребуется, чтобы вернуться к точке, с которой можно начать операцию восстановления).
В некоторых компаниях отключение системы на 1-2 часа не столь существенно. Для других компаний это катастрофа. Поэтому следует определить, сколько времени пользователи смогут обходиться без услуг Exchange во время восстановления. Консультации с руководителем помогут определить длительность приемлемого простоя в случае аварии.
Предположим, что в результате этих консультаций определено, что ни один из пользователей не должен оставаться без услуг Exchange более 30 минут. Чтобы запланировать меры, позволяющие укладываться в это максимальное время простоя, необходимо взять рассчитанное выше время восстановления и разделить его на максимальное время простоя, допускаемое политикой руководства. В результате будет получено количество хранилищ, которое потребуется создать на сервере Exchange. Чтобы определить минимальное количество групп хранения, которое вам потребуется, разделите количество хранилищ на 5 (количество хранилищ на одну группу хранения).
В данном примере мы знаем, что восстановление данных для 300 пользователей потребует 35 минут. Однако это время соответствует хранению данных только в течение двух месяцев. В большинстве компаний хранят информацию намного дольше. Поэтому, если мы примем в данном примере более реальный период хранения в один год, то нам потребуется умножить рассчитанные выше значения на 6, чтобы определить картину восстановления для годичного запаса данных. Таким образом, восстановление баз данных, содержащих накопленную за год информацию, займет 210 минут (3,5 часа). Что делать в этом случае? А ведь нам нужно, чтобы базы данных можно было восстанавливать в течение 15 минут, чтобы был запас времени, позволяющий уложиться в 30-минутное требование максимального простоя, принятое в рассматриваемой компании. Поэтому нам потребуется создать не менее 14 отдельных хранилищ почтовых ящиков и 14 отдельных хранилищ общих папок (210/15). Здесь, конечно, предполагается, что будут использоваться базы данных приблизительно одинакового размера. Если некоторые базы данных оказываются намного больше, чем допускается временем восстановления, то имеет смысл создать дополнительные хранилища или переместить почтовые ящики некоторых пользователей в другие хранилища, чтобы размеры хранилищ отвечали поставленным целям.
В данном случае нам потребуется не менее пяти групп хранения, чтобы в них можно было поместить 28 хранилищ. Поскольку на одном сервере допускается не более четырех групп хранения, то для размещения этих хранилищ нам потребуются два сервера Exchange. Лучше всего по возможности равномерно распределить эти базы данных между двумя серверами. Кроме того, поскольку в системе на одну группу хранения приходится один набор журналов транзакций, то увеличение количества групп хранения будет препятствовать образованию большого количества журналов транзакций на одну группу хранения, хотя и приведет к общему увеличению количества журналов транзакций для системы в целом.
Создание группы хранения
Группа хранения создается быстро и без проблем. Напомним, что на одном сервере Exchange 2003 нельзя создать более четырех групп хранения. При попытке сделать это появится сообщение об ошибке.
Чтобы создать группу хранения, откройте оснастку Exchange System и найдите нужный объект-сервер. Щелкните правой кнопкой мыши на этом объекте-сервере, укажите пункт New (Создать) и выберите пункт Storage Group (Группа хранения) из соответствующего подменю ( рис. 11.2). Появится страница свойств новой группы хранения ( рис. 11.3). При вводе имени группы хранения станет видно, что это имя одновременно вводится во все три поля. Это защищает от ошибок в местоположении журналов транзакций (Transaction log location) или системного пути доступа к хранилищам (System path location).
На странице свойств можно включить опции Zero Out Deleted Database Pages (Обнуление удаленных страниц баз данных) и Enable Circular Logging (Активизировать циклическое ведение журналов). Параметр Zero Out Deleted Database Pages указывает, чтобы при резервном копировании в режиме он-лайн во все удаленные страницы всех хранилищ, входящих в данную группу хранения, записывались нули. Установите этот флажок, если хотите, чтобы удаленные данные нельзя было восстановить. Это потребует дополнительной обработки в процессе копирования и замедлит процесс, но улучшит защиту от доступа к удаленным данным. В поле Log File Prefix (Префикс для файлов журналов) можно указывать префикс, который помещается перед началом имени каждого файла журнала. Это позволяет хранить все файлы журналов в одном месте и при этом видеть, какие журналы относятся к соответствующей группе хранения.
Опция Enable Circular Logging позволяет использовать циклическое ведение журналов для данной группы хранения. Активизируйте это средство только для тех групп хранения, которые не содержат критически важных данных. Использование циклического ведения журналов не приводит к снижению количества журналов транзакций, создаваемых процессом Store системы ESE, но лишает возможности восстановления баз данных вплоть до точки аварийного отказа. При циклическом ведении журналов возможно осуществить восстановление только с последней полной резервной копии. Прежде чем выбрать эту опцию, тщательно продумайте возможные последствия потери новых данных в базах данных Exchange.
В окне вкладки Details (Дополнительно) группы хранения можно вводить примечания по данной группе хранения, например, кто ее создал, и для чего она предназначена.