Продолжение цикла постов об «опытных мелочах», о нюансах, примерах, скриптах, решениях разных интересных или рутинных задач, с которыми мне приходилось сталкиваться за годы работы windows-админом.
В пилотном выпуске речь шла о задаче «определить какой пользователь за каким компьютером работает», сегодня речь пойдет о проблеме роста почтовых баз и одном из способов ее решения на сервере MS Exchange.
Суть проблемы была тривиальна – ОЧЕНЬ БОЛЬШОЙ ОБЪЕМ почтовых баз. На тот момент это было около 800 Гб, лежащих на одном сервере (справедливости ради надо сказать, что сервер с нагрузкой худо-бедно справлялся, хотя 32-битность Exchange 2003 ему сильно в этом мешала).
Специфика работы компании накладывала вот какие ограничения:
Стратегически решение проблемы было в общем понятно — нужно вводить квоты на почтовые ящики (можно дифференцированно в зависимости от отдела, нужд пользователя и т.п.) и переносить старые письма в архивы. Весь вопрос был в том, как это лучше (для админов) и удобнее (для пользователей) сделать. Вариантов было несколько, их я и начал отрабатывать «на кошечках».
Наконец я вспомнил про закон изобретателя велосипеда, и решил вручную повторить то, что и так уже сделали, но в связке Exchange 2010 — Outlook 2010 (тем кто не в курсе рекомендую почитать документацию, такой функционал, как архивные ящики появился в этой версии Exchange, и, по отзывам знакомых, довольно неплохо работает). В итоге получилось вот что:
Минусом придуманного стало то, что в архив переносить письма пользователю приходится руками (в отличие например от связки Exchange 2010 — Outlook 2010, где это можно настроить автоматически), ориентируясь по уведомлениям Exchange о достижении порога квоты. Но с другой стороны это стало даже и плюсом, т.к. при ручном переносе пользователи как раз и сортируют свою почту так, как считают нужным, по им одним только ведомым критериям.
Продолжение следует.
В пилотном выпуске речь шла о задаче «определить какой пользователь за каким компьютером работает», сегодня речь пойдет о проблеме роста почтовых баз и одном из способов ее решения на сервере MS Exchange.
Постановка задачи
Суть проблемы была тривиальна – ОЧЕНЬ БОЛЬШОЙ ОБЪЕМ почтовых баз. На тот момент это было около 800 Гб, лежащих на одном сервере (справедливости ради надо сказать, что сервер с нагрузкой худо-бедно справлялся, хотя 32-битность Exchange 2003 ему сильно в этом мешала).
Специфика работы компании накладывала вот какие ограничения:
- подавляющему большинству пользователей необходим доступ к их старым письмам, желательно в отсортированном ими виде (контрагенты, города, размер бородавок на носу и прочие субъективные критерии)
- руководство страстно желало иметь возможность восстановить почту своих сотрудников, если ее случайно\неслучайно удалили, пусть даже жестко и «без возможности восстановления», если сломался компьютер и т.п.
- админам хотелось чтобы бэкап почты не ворочался как беременный слон по 30-40 часов, а мог выполняться хотя бы за ночь
- сохранность данных, защита от удаления, была важнее всего, руководство панически боялось потерять «что нибудь важное».
- В компании работал MS Exchange 2003 и Outlook 2003. Уже был куплен, но по разным причинам не внедрен MS Exchange 2007, вследствии чего разговор об апгрейде до 2010 был встречен дружным непониманием и полным нежеланием расходовать вполне себе немаленькие деньги.
Месье знает толк в извращениях, или варианты решения
Стратегически решение проблемы было в общем понятно — нужно вводить квоты на почтовые ящики (можно дифференцированно в зависимости от отдела, нужд пользователя и т.п.) и переносить старые письма в архивы. Весь вопрос был в том, как это лучше (для админов) и удобнее (для пользователей) сделать. Вариантов было несколько, их я и начал отрабатывать «на кошечках».
- Самым простым было банально заставить всех удалять старую почту, мотивируя это тем, что почтовый клиент не для хранения данных, а для оперативной переписки. А в случае необходимости — доставать нужные письма из бэкапов. Сразу стало понятно что метод — бесперспективен, мол того что он был встречен агрессивным непониманием со стороны всех пользователей, включая руководство, так еще и процесс вытаскивания из бэкапа был невероятно муторным и долгим, а ситуация когда человеку ОЧЕНЬ СРОЧНО нужен его архив за 2006 год, была не так уж и редка.
- Отвергнув первый порыв, я банально слил все старые письма в локальные PST и настроил автоархивацию средствами Outlook. Минусов получилось больше чем плюсов: почта лежала на рабочих станциях, была незащищена от сгоревшего HDD и архивы нельзя было посмотреть зайдя через WEB-интерфейс (давать всем-всем удаленный RDP-доступ на свои компы не разрешал отдел СБ, и на мой взгляд правильно делал).
- Затем я повозился с скриптом «раз в неделю обходить компы по списку и сливать PST в папку на сервере» — было весело, навозился вдоволь, особенно с хитромудрым Outlook, который в открытом состоянии ТАК блокирует PST файл, что скопировать его нельзя никак, пока Outlook не закроется.
- Следующим логичным шагом был перенос PST-архивов в централизованное хранилище, в сеть. Здесь начались проблемы с тем, что если в момент открытия\работы\закрытия Outlook сеть обрывалась, то пользователь получал 50% шанс при следующем открытии получить окошко «идет проверка неправильно закрытого PST», которое могло висеть от 5 минут до часа, в зависимости от размеров PST. И даже если закрыть на все это глаза, все равно не находилось способа дать людям работать с архивами удаленно.
Что получилось в итоге.
Наконец я вспомнил про закон изобретателя велосипеда, и решил вручную повторить то, что и так уже сделали, но в связке Exchange 2010 — Outlook 2010 (тем кто не в курсе рекомендую почитать документацию, такой функционал, как архивные ящики появился в этой версии Exchange, и, по отзывам знакомых, довольно неплохо работает). В итоге получилось вот что:
- Перво-наперво мигрировал на Exchange 2007, коль уж есть такая возможность — грех упускать. Отдельно повозившись настроил OWA через ISA. Стало чуть-чуть полегче, т.к. 2007 64-битный и понимает толк в «много-много оперативной памяти», уж чего-чего, а этого добра я никогда для серверов не жалел.
- для каждого пользователя, который не влезал в предопределенную квоту, был создан фантомный пользователь "Архив username" с альясом arc.username, и у него соответственно также был почтовый ящик. Для разнообразия я сделал их всех Equipment type, чтобы можно было в дальнейшем гарантированно отличать от обычных, рабочих. Соответственно были розданы права, чтобы обычный пользователь имел полный доступ к ящику своего «фантома»
- Всех фантомов скрыл из Global Address List, «для порядку», и сгруппировал в отдельные Database в Storage group, где включен Circullar logging и которые лежат на большом-большом RAID разделе.
- В этой же Storage Group также находились т.н. ящики СБ, куда сливалось журналирование особо важных пользователей.
- Каждому пользователю саппорт подключил его фантомного коллегу в Outlook, и перекачали в фантомный ящик всю почту, которая попадала под критерий архивной.
- Любой у кого есть архив, теперь может удаленно, через OWA спокойно в нем покопаться, на этот счет написана небольшая инструкция для особо непонятливых.
- Размер «оперативных» баз Exchange, тех которые ворочаются каждый день, и бэкапятся 3 раза в неделю уменьшился до приемлемых 200 Гб
- Архивные базы бэкапятся реже, вместе с ящиками СБ, раз в неделю, на выходных. По времени успеваем замечательно (а после обновления версии бэкап-сервера вообще стали делать полный бэкап всей всей почты за 25 часов).
Минусом придуманного стало то, что в архив переносить письма пользователю приходится руками (в отличие например от связки Exchange 2010 — Outlook 2010, где это можно настроить автоматически), ориентируясь по уведомлениям Exchange о достижении порога квоты. Но с другой стороны это стало даже и плюсом, т.к. при ручном переносе пользователи как раз и сортируют свою почту так, как считают нужным, по им одним только ведомым критериям.
Продолжение следует.