Blog of Khlebalin Dmitriy

(Записки из мира IT…)

Exchange 2010, рабочие будни.


Вчера столкнулись с проблемой, которую совсем не ждали. Проблема касается нашего почтовика Exchange 2010 Standart. Несколько лет назад почтовик был спроектирован из расчета 150 пользователей (по 2 гига каждому) или 4 базы по 75 гиг, все как учили :). Но с тех пор утекло много воды, пользователи жаловались руководству компании, мол вся почта нужна за последние 5 лет, я каждый день ее читаю и все в этом роде.  Тогда и была нами допущена важная ошибка, были убраны квоты на стораджи. Базы постепенно стали расти, мы постепенно добавляли места на виртуальных дисках VmWare… Шли годы…. В итоге, сегодня у нас на этом же сервере 300 пользователей и 4 базы по 300 гигов (понятно, что компания Microsoft рекомендует несколько другие конфигурации для таких объемов, но тут бюджет, кризис и все такое, в общем приходится обходится тем, что есть). Но безгранично добавлять место в корзинах тоже нельзя и вчера мы уперлись в предел (мыльный пузырь, разрастающийся все эти годы, лопнул), но не просто лопнул, а принес еще не мало проблем. Позавчера ночью, место на разделе закончилось и стораджи отмонтировались автоматически, Exchange впал в гидростопор, слабо реагировал на внешние раздражители… Добавили немного места, решили перезагрузить сервер, за одно «накатили» все обновления вышедшие за это время. Сервер благополучно ушел в ребут, благополучно загрузился, но 3 из 4 стораджей отказались монтироваться.

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

Ошибка Microsoft Exchange
--------------------------------------------------------
Не удалось подключить базу данных 'vip'.
vip
Ошибка
Ошибка:
Не удалось подключить указанную базу данных. Указанная база данных: Managers; код ошибки: Сбой операции Active Manager. Ошибка: Сбой действия базы данных. Ошибка: Сбой операции с сообщением: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-550)

оставшаяся  четвертая база и Publicfolder примонтировались, как не в чем не бывало и продолжили работать.

Запускаю PowerShell:

eseutil /mh «d:\database\vip.edb»

понимаю, что все три базы в статусе Dirty Shutdown. Это означает, что наша база некорректно выключилась и часть информации не перенесена из лога в базу. Если у нас есть логи и они не испорчены, то мы сможем все восстановить. Если логов нет или они испорчены, то часть данных будет потеряна.

Проверяем логи:

eseutil /ml «e:\logs\e03.log»

Понимаю, что логи содержат ошибку и прибегнуть к так называемому «мягкому восстановлению» типа:

eseutil /r «E03» /l "d:\database" /d "d:\database\vip.edb"
E03 — имя лога

не удастся.

можно игнорировать ошибку в логах, но это не всегда хорошо

eseutil /r «E03» /a /i /l "d:\database" /d "d:\database\vip.edb"

Если ошибок в логах нет, то это самый быстрый вариант восстановить базу и примонтировать ее, но это не наш случай.

Попробовали достать ночную резервную копию базы с Veeam сервера бэкапа, но она тоже отказалась монтироваться, пришлось прибегнуть к так называемому «жесткому восстановлению» без логов:

eseutil /p «d:\database\vip.edb»

Этот вариант как правило безотказен, база начала восстанавливаться, но таких базы три.

Вот тут как раз нас и ждал «кулак дружбы» при работающем сервере (даже с одной работающей базой) возможно восстанавливать только одну базу, так как, если параллельно, здесь же, запустить восстановление второй, то все наглухо зависает и сервер начинает дико «буксовать». Никакие высокоскоростные диски SAS в этом случае не спасают, почта до пользователей рабочей базы начинает доставляться крайне медленно, что-то еще запустить вообще не возможно (я про оснастку или приложение), поэтому восстановление поврежденной базы в один поток. Это первый подводный камень. Вторым подводным камнем стало то, что за полный рабочий день база в 300 гиг в один поток восстановления так и не восстановилась. Вечером пришлось остановить службу и отмонтировать рабочий сторадж и Publicfolder, тогда восстановление стало несколько быстрей. Если быть точным, то восстановление одной базы в 300 гиг на нерабочем сервере без всякой нагрузки (то есть ночью), заняло примерно 9 часов. Если почтовый сервис для компании является критикал сервисом, то восстановление нескольких таких баз затянется на долгие часы а может и дни, не стоит рассчитывать, что это будет быстро.

Мораль басни какова:

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

— Четко следите за размерами хранилищ и их количеством и правильно выбирайте лицензии (Standart или Enterprise) при проектировании почтовой системы, здесь не стоит экономить.

Спустя 25 часов 31 минуту, почтовый сервер вернулся в строй-это крайне долго и крайне печально для бизнеса, но что есть, то есть.  Как я уже ранее писал, если почтовый сервис критикал и бюджет позволяет, то конечно же это должен быть отказоустойчивый кластер, а не единственный сервер. Нагрузка на одиночный сервер при таких масштабах тоже не малая.

snap

snap1

Не наступайте на наши грабли. Всем хорошей работы !!!

P.S. Да совсем забыл упомянуть еще один важный момент, который также может в определенный момент сыграть злую шутку, с этой проблемой столкнулись наследующий день, после выше описанного события. А именно, если начинает отрабатывать Storage DRS и тот  же vmdk Exchange начинает мигрировать на другой менее загруженный объект и в это время Veeam начинает делать его бэкап, то все это хозяйство также автоматически становится «колом», все это висит многие и многие часы, в итоге бэкап вылетает с ошибкой и миграция также не происходит. Если все это приостановить руками (например, ночью бэкап не сложился, а в рабочее время его делать уже нельзя), то почтовик (или другая подобная виртуалка) дико тупит, так как снепшоты остались не удаленными. Обратите на это пристальное внимание в том числе.

Реклама

02.11.2016 - Posted by | ms exchange 2010

Sorry, the comment form is closed at this time.

%d такие блоггеры, как: