У заказчика более 20 тысяч пользователей корпоративной почты в нескольких регионах. Все эти люди пользуются Exchange-серверами, и чаще всего — разными Outlook’ами. Пользователей большой объём базы почти никогда не беспокоит, если не считать поиска: он идёт медленно и выдаёт сотни писем, по сути, без возможности нормальной фильтрации.
Админов не устраивает, что эта база начинает пухнуть. Добавить ещё 20 ТБ дискового места в сервера не всегда так просто, потому что это будет по факту 40 ТБ: раздел по 20 ТБ должен выдаваться каждой ноде DAG, и их у заказчика две. И ещё бэкап. Полный бэкап должен делаться за ночь раз в неделю в воскресенье, и, если он выходит за окно, то это проблема.
Плюс сама по себе база Exchange —это поле костылей довольно медленная и не поддерживает дедупликацию, только обычное сжатие внутри письма. То есть когда бухгалтерия опять отправит смешную пятимегабайтную гифку на всю компанию, она ляжет в базу ровно столько раз, сколько было получателей.
Мы предложили перенести старые письма в архивную базу с дедупликацией, чтобы на бою осталось только 10–20 % самых «горячих» писем. При этом на месте писем в Outlook показываются их заголовки и первые N символов письма, а архивная база имеет интеграцию с клиентом и подтягивает письмо за пару секунд при обращении к нему. То есть пользователь видит свои старые письма и почти так же удобно работает с ними.
Вот так выглядит заглушка.
А ещё это очень упростило поиск (база с индексом) и подарило радость отделу ИБ.
Ниже я расскажу про оптимизацию почтовых баз.
С учётом стоимости лицензии и сложностей интеграции выходило примерно одно к одному. Но есть один нюанс. Дело в том, что в 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 ТБ).
Вот сайзинги, по ним это хорошо видно:
Обычно до очистки архивное письмо хранится пять лет. Мы установили срок на бесконечность. В дальнейшем это значение может быть пересмотрено, если и EV-сервер начнёт пухнуть. Инкремент — раз в день, полный бэкап — раз в неделю. Старыми считаются письма, которые не трогали в пропорции 20/80 по датам. Можно вытащить в архив и все письма старее одного месяца, например.
База данных за всем этим MS SQL с настройками и с хэшами от писем, логами и прочим. Основная база с массивом данных расположена на отдельном отказоустойчивом сервере, который был у заказчика. К нему подключена хранилка. Там RAID на уровне СХД.
Пара слов — про OCR и разбор форматов. Вот пример списка. Это самая последняя версия Outside In, в текущей версии EV 14, возможно, используется чуть старее, но всё равно и предыдущие версии включали сотни типов файлов. Для старых версий упоминалась поддержка около 400 типов файлов.
Вот языки OCR:
У пользователей, условно говоря, снялось ограничение на размер ящика, потому что всё равно всё старое уходит в архив.
Всего мы мигрировали около 26 тысяч почтовых ящиков (из которых активных было около 20, а в остальные иногда надо было заглядывать за старыми письмами).
habr.com
Админов не устраивает, что эта база начинает пухнуть. Добавить ещё 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 ТБ).
Вот сайзинги, по ним это хорошо видно:
Обычно до очистки архивное письмо хранится пять лет. Мы установили срок на бесконечность. В дальнейшем это значение может быть пересмотрено, если и 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, а в остальные иногда надо было заглядывать за старыми письмами).
Липосакция почтовой базы: что бывает, когда она пухнет до 10 ТБ
У заказчика более 20 тысяч пользователей корпоративной почты в нескольких регионах. Все эти люди пользуются Exchange-серверами, и чаще всего — разными Outlook’ами. Пользователей большой объём базы...
habr.com