Админов не устраивает, что эта база начинает пухнуть. Добавить ещё 20 ТБ дискового места в сервера не всегда так просто, потому что это будет по факту 40 ТБ: раздел по 20 ТБ должен выдаваться каждой ноде DAG, и их у заказчика две. И ещё бэкап. Полный бэкап должен делаться за ночь раз в неделю в воскресенье, и, если он выходит за окно, то это проблема.
Плюс сама по себе база Exchange —
Мы предложили перенести старые письма в архивную базу с дедупликацией, чтобы на бою осталось только 10–20 % самых «горячих» писем. При этом на месте писем в Outlook показываются их заголовки и первые N символов письма, а архивная база имеет интеграцию с клиентом и подтягивает письмо за пару секунд при обращении к нему. То есть пользователь видит свои старые письма и почти так же удобно работает с ними.
Вот так выглядит заглушка.
А ещё это очень упростило поиск (база с индексом) и подарило радость отделу ИБ.
Ниже я расскажу про оптимизацию почтовых баз.
Решение
Заказчик остановился на Entreprise Vault от Veritas. У неё есть аналоги, например, тот же CommVault, но по результатам оценки именно эта система оказалась лучше, в частности, из-за того, что у заказчика был положительный опыт со стеком Veritas. Это платформа, которая специально создана для архивирования файлопомоек и почты. Работает она примерно так:
- Вы задаёте в правилах EV критерии «архивный документ» и «горячий». EV присасывается к почтовой базе через локально установленный на нём Outlook.
- Запускается процесс архивации.
- Письма при попадании в архивное хранилище EV проходят процесс дедупликации.
- Индексируются тело письма и его аттачменты для быстрого поиска.
- СРК делает первую полную резервную копию данных EV.
- После проверки успешности бэкапа EV заменяет в основной базе Exchange-элементы на заглушки, которые при взаимодействии с ними приводят к извлечению из архива оригинального письма.
- Этот процесс повторяется изо дня в день с запуском уже инкрементальных бэкапов.
- Снимается полный бэкап по расписанию раз в неделю.
Админы хотели сэкономить на дисковом пространстве. Понятное дело, что интеграция новой системы вместо покупки ещё пары полок или апгрейда хранилища — это не всегда хорошая идея, но тут цены прямо совсем кусались, учитывая объём базы. Новая полка с дисками также не решала вопрос очень сложного поиска и страдающих пользователей (хотя обычно в таких ситуациях они просто продолжают страдать) и не решала вопрос укладывания бэкапа во временное окно. Естественно, архив хранился бы не на быстрых дисках, сравнение шло с учётом этого.
С учётом стоимости лицензии и сложностей интеграции выходило примерно одно к одному. Но есть один нюанс. Дело в том, что в EV был заинтересован отдел ИБ. Они не имели DLP, поэтому постоянно что-то искали вручную. А EV позволяет делать не только очень быстрые поиски, но и создавать постоянные поиски, которые похожи на папки с фильтрами. То есть один раз настроив фильтр по слову «откат» и синонимам, безопасники могли бы получать детальную информацию о тех весёлых людях, кто договаривается про такое через корпоративную почту. На самом деле их механизмы были куда сложнее, и Veritas был для них очень желанным.
Дело в том, что если вы ставите себе DLP-пакет, то нужно включать журналирование ящиков, потому что пользователи вообще-то могут удалить компрометирующее их письмо. То есть весь трафик будет дублироваться, что совсем уже дико в рамках бюджета заказчика и с учётом опасно разросшейся базы.
«Опасно» — это сами специалисты по Exchange говорят, что так делать не надо:
То есть придётся плодить и базы Exchange, и сами сервера Exchange, т. к. если в один сервер положить много баз, то негативный эффект будет тот же, что от одной большой базы.
Как прошло внедрение
Примерно как я описал выше.
На стадии архивации почтовые данные ужались примерно на 40 %. Если обычная почтовая база хранит все копии письма и может только сжать каждую из них чем-то вроде ZIP, то дедупликация на стороне EV позволяет собрать сотни писем в один исходный документ и ссылки на него. Стоит заметить, что дедупликация тут идёт не поблочно, а подокументно, то есть вложения разбираются отдельно от писем.
Далее выяснилось, что вложения индексируются куда лучше, чем мы могли подумать. В EV есть возможность нативно разбирать очень много форматов. И ещё есть распознавание изображений (OCR) в поисках текста для индексации, включая русский текст. Счёт-фактуры и сканы договоров сразу становились русским HTML-документом.
Поиск по письмам стал полнотекстовым и очень богатым на фичи. Наконец-то появилась возможность нормально сортировать все найденные письма. Те самые фильтры поиска и поиск в результатах поиска очень понравились тем пользователям, кто вообще понял, что произошло с миграцией базы. Кто-то даже использовал регулярные выражения, они тоже поддерживаются.
Поиск длится пару секунд, потом ещё пару секунд вытягивается на базе индекса (то есть одно письмо, к которому обратился пользователь). Вот поиски:
Список поддерживаемых полей, в том числе поддержка кастомных тегов в разделе Advanced:
Размер заглушек в почтовой базе мы установили в 100 символов. По умолчанию EV предлагает оставлять по 1 000 символов от тела письма. Чтобы прочитать письмо, надо просто кликнуть на него в Outlook, оно онлайн разворачивается из архива и открывается нативно.
Плагин Outlook обеспечивает связку с EV так, что пользователь не выходит из Outlook и не видит, что происходит. Для него это просто отдельная вкладка с другими письмами.
Архитектура выглядит вот так:
Тут было важно правильно просчитать баланс между прод-серверами и хранилкой так, чтобы бэкап в пике не перегружал систему. База разбита между пятью инстансами, это best practice хранения. Учитывая, что инстансы соответствуют географическим регионам, это означает разную нагрузку на них в зависимости от того, сколько пользователей в регионе, поэтому у них разные конфигурации. Но серверов четыре штуки, потому что два региона уместились на один инстанс. На каждом из серверов есть диск для операционной системы и отдельный диск для EV (точнее, LUN, презентуемый из хранилки). Плюс физические диски — это для временных файлов, буфера архивации, индексов и так далее (по 4 ТБ).
| Сервер |
Pool |
Имя |
Размер |
Назначение |
Точка монтирования |
| Сервер EV 1 |
Local |
|
100 GB |
Operating System |
C |
| |
50 GB |
Vault Program Files, MSMQ, |
D |
||
| EV Cache, Shopping |
|||||
| Archive |
SQ-TEMP |
200 GB |
Storage Queue |
E |
|
| ev_profile_temp |
|||||
| IDX01 |
800 Gb |
Index |
Z |
||
| VS01 |
4 TB |
Vault Store 1 |
F |
||
| VS02 |
4 TB |
Vault Store 2 |
H |
||
| PST-TEMP |
100G |
For PST migration |
M |
||
| |
|
|
|
|
|
| Сервер EV 2 |
Local |
|
100 GB |
Operating System |
C |
| |
50 GB |
Vault Program Files, MSMQ, |
D |
||
| EV Cache, Shopping |
|||||
| Archive |
SQ-TEMP |
200 GB |
Storage Queue |
E |
|
| ev_profile_temp |
|||||
| IDX01 |
700 Gb |
Index |
Y |
||
| VS01 |
3,5 TB |
Vault Store 1 |
F |
||
| VS02 |
3,5 TB |
Vault Store 2 |
H |
||
| PST-TEMP |
100G |
For PST migration |
M |
||
| |
|
|
|
|
|
| Сервер EV 3 |
Local |
|
100 GB |
Operating System |
C |
| |
50 GB |
Vault Program Files, MSMQ, |
D |
||
| EV Cache, Shopping |
|||||
| Archive |
SQ-TEMP |
200 GB |
Storage Queue |
E |
|
| ev_profile_temp |
|||||
| IDX01 |
700 Gb |
Index |
X |
||
| VtS01 |
3,5 TB |
Vault Store 1 |
F |
||
| VS02 |
3,5 TB |
Vault Store 2 |
H |
||
| PST-TEMP |
100G |
For PST migration |
M |
||
| |
|
|
|
|
|
| Сервер EV 4 |
Local |
|
100 GB |
Operating System |
C |
| |
50 GB |
Vault Program Files, MSMQ, |
D |
||
| EV Cache, Shopping |
|||||
| Archive |
SQ-TEMP |
200 GB |
Storage Queue |
E |
|
| ev_profile_temp |
|||||
| IDX01 |
700 Gb |
Index |
V |
||
| VS01 |
3,5 TB |
Vault Store 1 |
F |
||
| VS02 |
3,5 TB |
Vault Store 2 |
H |
||
| PST-TEMP |
100G |
For PST migration |
M |
||
| |
|
|
|
|
|
| evsql01 |
Local |
|
100 GB |
Operating System |
C |
| Archive |
SQL_EVDB |
1,7 TB |
SQL_DB, SQL_LOGS |
F |
Обычно до очистки архивное письмо хранится пять лет. Мы установили срок на бесконечность. В дальнейшем это значение может быть пересмотрено, если и EV-сервер начнёт пухнуть. Инкремент — раз в день, полный бэкап — раз в неделю. Старыми считаются письма, которые не трогали в пропорции 20/80 по датам. Можно вытащить в архив и все письма старее одного месяца, например.
База данных за всем этим MS SQL с настройками и с хэшами от писем, логами и прочим. Основная база с массивом данных расположена на отдельном отказоустойчивом сервере, который был у заказчика. К нему подключена хранилка. Там RAID на уровне СХД.
Ещё детали
Ещё одна важная часть миграции — это сбор PST-ящиков. То есть кто-то работал через Exchange, а кто-то локально хранил PST-архивы. Их Veritas тоже умеет быстро собирать. То есть мы добровольно-принудительно забираем PST-файлы у пользователя, перекидываем их в архив EV, и заглушки на письма появляются в почтовом ящике Exchange. Собирали способом client drive migration: указываются пользователи на миграцию в конcоли EV и ставится модуль в Outlook. Далее плагин получает инструкции от EV-сервера и начинает плавно тянуть все письма. Этот метод хорош для локальных файлов, для файлшар подходит визард Import PST. Делается это всё next-next-done.
Пара слов — про OCR и разбор форматов. Вот пример списка. Это самая последняя версия Outside In, в текущей версии EV 14, возможно, используется чуть старее, но всё равно и предыдущие версии включали сотни типов файлов. Для старых версий упоминалась поддержка около 400 типов файлов.
Вот языки OCR:
Итог
Вся миграция проходила размеренно и спокойно, от формулирования задачи до сдачи в эксплуатацию прошло шесть месяцев с учётом техзадания, договора, поставок оборудования, ненапряжного снятия бэкапа, всех настроек, обучения и помощи пользователям. Админам понравилось, пользователи получили новую вкладку, но не испытали особых неудобств (зато поиски заработали отлично). Время резервного копирования почтовых баз сократилось. Безопасники никак не прокомментировали официально, но были рады.
У пользователей, условно говоря, снялось ограничение на размер ящика, потому что всё равно всё старое уходит в архив.
Всего мы мигрировали около 26 тысяч почтовых ящиков (из которых активных было около 20, а в остальные иногда надо было заглядывать за старыми письмами).
Комментарии (22)
gotch
29.07.2021 10:21+1Можно было начать и со штатных archive mailboxes.
То есть когда бухгалтерия опять отправит смешную пятимегабайтную гифку на всю компанию, она ляжет в базу ровно столько раз, сколько было получателей.
Все это уже было - SIS для аттачей до Exchange 2010. Но в силу очевидных причин уже удалено.
mvv-rus
29.07.2021 21:05У штатных archive mailboxes есть недостаток — цена: требуется клиентская лицензия Enterprise вместо Standard, Outlook, опять же, не в любой редакции с ними работать умеет, только в достаточно дорогой (для 2010, хорошо помню, требовался Professional, о чем были разбирательства с филиалами в некоем банке, где я тогда работал — там кое-кто на лицензиях экономить пытался).
Правда, это чудо техники, которое нам тут описывают — оно тоже, наверняка, не бесплатно и даже не дешево: все хотят поиметь с кровавого этенрпрайза много денег.Все это уже было — SIS для аттачей до Exchange 2010. Но в силу очевидных причин уже удалено.
Мне вот эти причины до сих пор неочевидны: удаление харнения еднственной копии было сделано под предлогом того, чтобы увличить долю линейного чтения, чтобы можно было хранить базы на SATA-дисках с малым IOPS (семитысячниках, к примеру). Может быть, где-то так и делают, но я что-то не встречал таких: все у кого есть SAN, почему-то стремились под базы Exchange задействовать именно его, а не JBOD.
может использовать
mikhailian
29.07.2021 11:27+2А что мешает хранить письма в Maildir или Mbox формате на сервере? Скриптами выгребать из INBOX прошлогодние письма и и складывать... ну скажем в Inbox_2020. Или дать создание таких архивных папок на откуп пользователю и его техподдержке.
40 терабайт — это не так уж и много для современных СХД. Бекапы можно незаметно для пользователя делать через LVM или ZFS.
ЗЫ: Да, я издеваюсь.
EKorotkikh Автор
29.07.2021 13:23LVM или ZFS это для Linux, у нас Windows. Любой снепшотинг (аппаратный или софтверный) так же требует дисковых ресурсов, т.к. при долгом бэкапе снепшот будет расти. Да и тонкостей там своих предостаточно, особенно когда хочется их такого бэкап отдельные письма уметь восстанавливать. Техподдержке в ящики пользователей руками условно говоря лазить нельзя, а у пользователей есть свои дела и заставлять их что-то делать, особенно в многотысячной компании, так себе затея.
mvv-rus
29.07.2021 21:42Бэкапы и так делаются незаметно для пользователя, со снимков томов, сделанных через VSS (софтовым или аппаратным, если есть, провайдером — VSS вполне умеет использовать аппаратный провайдер для SAN).
Evengard
29.07.2021 12:21А обычная дедупликация WinServer разве не поможет? Я имею ввиду дедупликация на уровне fs.
gotch
29.07.2021 13:44Exchange не поддерживает дедупликацию средствами ОС, только СХД. Но любая база данных дедуплицируется плохо или просто никак. Как правило все блоки в базе уникальны за счет заголовка страницы, дедупликация блочная, а раз все блоки в итоге уникальны то..
Здесь вообще блочная дедупликация слабо применима, база реплицируется, еще и реплики тоже надо дедуплицировать.
Конечно у таких решений есть своя рыночная ниша. С одной стороны костылик, с другой стороны - OCR появился. Сделали систему сложнее, к траблшутингу прибавился еще один слой от другого вендора. Который будет добавлять седых волос на патчах Exchange сервера, Outlook и самого себя.
alzotov
30.07.2021 12:56Можно добавить к предыдущему ответу на этот вопрос, что сама по себе технология OCR появилась уже 5 лет назад и сам по себе EV по нашему опыту является очень и очень стабильным продуктом, чего бывает не скажешь о других решениях.
Ну и в целом EV изначально умеет переводить в html сотни форматов файлов, и это одна из его фич. Мы же не знаем, сможет ли условный Office 2030 открыть документы, созданные в Office 2013, а вот текстовый html точно сможем.
mvv-rus
29.07.2021 21:36Они не имели DLP, поэтому постоянно что-то искали вручную. А EV позволяет делать не только очень быстрые поиски, но и создавать постоянные поиски, которые похожи на папки с фильтрами. То есть один раз настроив фильтр по слову «откат» и синонимам, безопасники могли бы получать детальную информацию о тех весёлых людях, кто договаривается про такое через корпоративную почту. На самом деле их механизмы были куда сложнее, и Veritas был для них очень желанным.
DLP в Exchange сейчас есть встроенный, на уровне транспорта. Т.е это может быыть именно Prevention: неправильное (нарушающее политики) письмо может быть не только перенаправлено безопасникам но и заблокировано для отправки, или потребовать для отправки явно выраженного намерения отправить (с возможным уведомлением безопасников). Но красивых галочек для этого в ванильном Exchange, конечно, маловато.
Что касается поиска, то его можно создать один раз а потом скриптом повторять с нужной периодичностью. Причем, можно указать, что найденное ни в коем случае не должно быть удалено окончательно (InPlace Hold, аналог Litigation Hold, но только не целиком на п/я, а по критериям поиска), а должно храниться вечно или сколько-то дней (настраивается в параметрах запроса).Дело в том, что если вы ставите себе DLP-пакет, то нужно включать журналирование ящиков, потому что пользователи вообще-то могут удалить компрометирующее их письмо.
Вообще-то — не нужно. Свежеполученные (хранящиеся в Корзине, т.е. папках внутри Recovery Items) письма можно защитить от окончательного удаления пользователем, включив Single Item Recovery: тогда при удалении пользователем из Корзины письмо не удаляется а перемещается в недоступную пользователю папку Корзины, где хранится полный срок. Плюс — упомянутый Inplace Hold (правда эта радость небесплатна — Enterprise CAL покупать надо) Ну, и Litigation Hold, на крайняк, есть -если он включен то письма в Корзине хранятся вечно. Правда, размер ящика…alzotov
30.07.2021 12:57Скрипты и костыли – это тоже вариант, но зачем, если есть журналируемый ящик, который можно полностью забирать в архив EV и который не займет дополнительного пространства за счет дедупликации (там те же пользовательские письма) и по которому можно потом осуществлять поиск. Если и этого мало, есть опции Advanced Supervision для анализа и поиска информации инспекторами от ИБ.
mvv-rus
30.07.2021 14:32Затем, что EV — это лишняя сущность, стоящая дополнительных денег и требующая дополнительного обслуживания.
Ну и журналирование небесплатно: создает дополнительную нагрузку на процессор, память и дисковую подсистему сервера Exchange, вполне соизмеримую с рабочей.
В некоем банке (которого теперь нет) безопасникам просто зеркалировался весь трафик SMTP, а дальше они с этим работали на своем оборудовании — и это создавало куда меньшую нагрузку на серверы Exchange (которые на тот момент были перегружены).
PS Скрипты, чтобы они не были костылями, достаточно вполне адекватно документировать.alzotov
02.08.2021 12:32Зачем, к примеру, внедрять бэкапы, если можно все заскриптовать? Зачем кластеризовать системы, если опять же можно и руками все делать? С SMTP известная тема и широко используемая ИБ, но тут все же решается другая задача, а тема с ИБ условно бонусная. Опять же EV может выступать агрегатором информации из разных источников (самое популярное - тот же Skype for Business и переписки в нем).
mvv-rus
02.08.2021 15:23Зачем, к примеру, внедрять бэкапы, если можно все заскриптовать? Зачем кластеризовать системы, если опять же можно и руками все делать?
Баланс «цена-качество» (в «качество» вхдят время реакции на сбой для кластеризации, упрощение отслеживания успешности процесса для резервного копирования и т.д.). Баланс — он для всех разный.
И про недостатки журналирования как средства обеспечения Discovery вы проигнорировали: встроенная eDiscovery, обрабатывающая сообщения по месту, куда как менее прожорлива. И что-то мне подсказывает, что наверняка кто-нибдь прикрутил к ней человеческий интерфейс (благо программный интерфейс для земли и облака примерно одинаков), только вот смотреть и искать откровенно лень.
И, кстати, ЕМНИП агрегатором информации из Lync/SfB Exchange умеет работать и в стандартной комплектации.alzotov
03.08.2021 16:47Скажу так: инструментов масса, у каждого есть плюсы и минусы, и все утилиты подбираются индивидуально. В статье рассказано об одном из них, пользоваться им или нет, каждый решает сам.
mvv-rus
03.08.2021 17:47Все правильно.
Конечно, хотелось бы в этой же статье и про альтернативы хоть немного увидеть,
но понимаю, что нельзя объять необъятное.
werter_l
02.08.2021 11:55Piler — open source email archiving c дедупликацией
bitbucket.org/jsuto/piler/src/master
www.mailpiler.org/wiki/start
Gengenid
Был в предыдущей компании этот enterprise vault - ну и мерзость, работать невозможно.
Не придумали ничего лучше и быстрее пока, чем складывать письма старше какого-то периода в локальный PST.
alzotov
Да, а потом этот PST благополучно теряется вместе со всей старой почтой при выходе из строя локального диска дектопа или утере ноутбука.
Если работать невозможно, то это скорее всего неправильно подобранные политики отправки данных в архив (когда еще «горячие» данные уже лежат в архиве) или когда экономят и архив хранят, к примеру, на ленте, тогда открытие одного письма занимает хорошо если минуты.
Gengenid
А кто мешает делать бэкап локального PST?
Даже 10 секунд на открытие одного письма это очень много. А с enterpise vault даже 10 секунд не получится. Плюс поиск встроенный в Outlook много удобнее.
Но вы, понятно, не согласитесь. У вас же задача прорекламировать, а не честный обзор. Иначе на этой статье не было бы накрученных плюсов.
alzotov
Потому что бэкапить данные из единой точки немного удобнее, чем делать это на сотнях и тысячах рабочих станций. А если это ноутбук, который в случайные промежутки времени включен по питанию и подключен к какой-либо сети, то задача становится еще интереснее. Насчет скорости открытия писем вот не поленился, специально прокликал рандомные старые письма в Аутлуке - занимает доли секунды, хотя архивы лежат на какие-то недорогих VNX'ах с обычными SATAшными дисками.
Gengenid
А теперь разверните историю с ноутбуком в обратную сторону.
Удаленка, доступ к корпоративной сети со скоростью даст бог мегабит-два.
И вам надо что-то в этом EV найти.
alzotov
Во-первых, мегабит – это очень даже хорошо и хватает для открытия веб-страничек, что собой и представляет интерфейс поиска EV. Во-вторых, насколько у вас тяжелые письма, если через мегабит они долго открываются? А как тогда обычная почта загружается, в чем отличие?
Далее, есть VDI, есть Citrix, есть RDP наконец, вариантов удаленной работы масса.
Ну, и вишенка: Vault Cache – возможность держать зеркало архива у себя локально + при необходимости подключать по аналогии с PST. Но в отличие от PST потеря кэша никакие печальные последствия не создает.