Последние несколько недель занимался реструктуризацией почтовых баз. В итоге количество баз увеличилось примерно в 2 раза, средний размер составляет 20-25Гб. Несколько гигантских баз было расформировано и удалено (например 2 базы по 70Гб). К этому решению шёл долго. Началось всё с, казалось бы, незначительной проблемы с рассылкой почты по спискам распространения. Случайно выяснилось, что при рассылке почта доходит не всем адресатам. Доходя до некоторых адресатов почта застревает в очереди и либо через несколько попыток доходит, либо (что происходило чаще) через 3 дня с начала отправки формируется NDR и сообщение из очереди удаляется. Вот здесь пытался разобраться с этой проблемой. Как оказалось дело в том, что нарушена целостность почтовых баз. Решений оказалось всего три:
1. Нахождение проблемных пользователей, выгрузка их почты в PST, пересоздание почтового ящика и загрузка PST обратно.
2. Проверка почтовых баз и исправление ошибок с помощью isinteg.
3. Создание новых хранилищ и перенос пользовательских данных в них.
Первый пункт в моем случае оказался малопродуктивным (слишком много проблемных пользователей), со вторым возникла некоторая проблема. Как известно isinteg /fix работает примерно со скоростью 10Гб/с на базе без ошибок, а при исправлении ошибок скорость снижается на 3 порядка. В итоге 2 проблемные базы на 70Гб так до конца проверить и не получилось, так как оставлять часть офиса без почты более чем на 10 часов даже в выходные мне было запрещено. Остался только третий пункт. При переносе заметил следующую особенность – скорость переноса сильно зависит не от объёма ящика, как можно было бы подумать, а от количества сообщений в нём. Помимо этого скорость зависит ещё от количества одновременно переносимых ящиков. В итоге экспериментальным путём установил, что ящик, в котором около 30000 сообщений, переносится в районе часа.
Параллельно с процессом переноса решалась задача о соответствии структуры хранилищ организационной структуре компании. В итоге сваял простенький запрос на PoSh для вытаскивания на свет информации о пользователе, отделе в котором он работает, компании (у нас несколько юридических лиц и эта информация отображается в учётной записи пользователя) и базе, в которой находится его ящик:
Get-QADUser -IncludeAllProperties -SerializeValues -SizeLimit 0 | Where-Object {$_.homeMDB -notlike ''} | Select-Object Name, homeMDB, department, Company | Export-Csv f:tmp.csv
Очень удобно для составления таблицы с указанием какие пользователи в каких базах хранятся. Для полного счастья не хватает ещё информации о размере ящиков и количестве сообщений в них. Видимо этот запрос надо скомбинировать с запросом, который находится здесь. В общем пока эта задачка ещё ждёт решения.
А это такие штуки теперь cmd.exe умеет делать?
2 Peter Lemenkov: разумеется не cmd.exe 😉 Windows PowerShell 🙂
2 Станислав: Нужна какая то помощь по задачке для полного счастья? 🙂
При переносе заметил следующую особенность – скорость переноса сильно зависит не от объёма ящика, как можно было бы подумать, а от количества сообщений в нём.
На 100% не знаю, но все эти переносы работают по MAPI, с одного ящика выкачиваются, в другой складываются. Соответственно скорость зависит от количества сообщений.
2Xaegr:
Ну если ты найдёшь время и опишешь как можно получить из AD+Exchange комбинированную информацию со свойствами как из AD, так и из Exchange то я буду премного благодарен =)
2Pavel Nagaev
Эта информация получена экспериментальным путём и утверждать о линейной зависимости я не буду. Более того, скажу, что в случаях с ящиками, в которых сообщений меньше чем 5-10 тыс. в моем случае более важным становится размер почтового ящика. Как себя система ведёт с ящиками в несколько сот тысяч сообщений я не могу утверждать – у меня нет таких данных… Вообще тема с производительностью крайне нетривиальна, хочу про это написать, но пока из отрывочных мыслей целостной картинки не складывается.
Done 😉
http://xaegr.wordpress.com/2008/08/25/ad-plus-wmi-query/
2Xaegr
Огромное спасибо!