Как стать автором
Обновить
122.02

Липосакция почтовой базы: что бывает, когда она пухнет до 10 ТБ

Время на прочтение 6 мин
Количество просмотров 8.9K
У заказчика более 20 тысяч пользователей корпоративной почты в нескольких регионах. Все эти люди пользуются Exchange-серверами, и чаще всего — разными Outlook’ами. Пользователей большой объём базы почти никогда не беспокоит, если не считать поиска: он идёт медленно и выдаёт сотни писем, по сути, без возможности нормальной фильтрации.

Админов не устраивает, что эта база начинает пухнуть. Добавить ещё 20 ТБ дискового места в сервера не всегда так просто, потому что это будет по факту 40 ТБ: раздел по 20 ТБ должен выдаваться каждой ноде DAG, и их у заказчика две. И ещё бэкап. Полный бэкап должен делаться за ночь раз в неделю в воскресенье, и, если он выходит за окно, то это проблема.

Плюс сама по себе база Exchange — это поле костылей довольно медленная и не поддерживает дедупликацию, только обычное сжатие внутри письма. То есть когда бухгалтерия опять отправит смешную пятимегабайтную гифку на всю компанию, она ляжет в базу ровно столько раз, сколько было получателей.

Мы предложили перенести старые письма в архивную базу с дедупликацией, чтобы на бою осталось только 10–20 % самых «горячих» писем. При этом на месте писем в Outlook показываются их заголовки и первые N символов письма, а архивная база имеет интеграцию с клиентом и подтягивает письмо за пару секунд при обращении к нему. То есть пользователь видит свои старые письма и почти так же удобно работает с ними.

image
Вот так выглядит заглушка.

А ещё это очень упростило поиск (база с индексом) и подарило радость отделу ИБ.

Ниже я расскажу про оптимизацию почтовых баз.

Решение


Заказчик остановился на Entreprise Vault от Veritas. У неё есть аналоги, например, тот же CommVault, но по результатам оценки именно эта система оказалась лучше, в частности, из-за того, что у заказчика был положительный опыт со стеком Veritas. Это платформа, которая специально создана для архивирования файлопомоек и почты. Работает она примерно так:

  1. Вы задаёте в правилах EV критерии «архивный документ» и «горячий». EV присасывается к почтовой базе через локально установленный на нём Outlook.
  2. Запускается процесс архивации.
  3. Письма при попадании в архивное хранилище EV проходят процесс дедупликации.
  4. Индексируются тело письма и его аттачменты для быстрого поиска.
  5. СРК делает первую полную резервную копию данных EV.
  6. После проверки успешности бэкапа EV заменяет в основной базе Exchange-элементы на заглушки, которые при взаимодействии с ними приводят к извлечению из архива оригинального письма.
  7. Этот процесс повторяется изо дня в день с запуском уже инкрементальных бэкапов.
  8. Снимается полный бэкап по расписанию раз в неделю.

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

С учётом стоимости лицензии и сложностей интеграции выходило примерно одно к одному. Но есть один нюанс. Дело в том, что в EV был заинтересован отдел ИБ. Они не имели DLP, поэтому постоянно что-то искали вручную. А EV позволяет делать не только очень быстрые поиски, но и создавать постоянные поиски, которые похожи на папки с фильтрами. То есть один раз настроив фильтр по слову «откат» и синонимам, безопасники могли бы получать детальную информацию о тех весёлых людях, кто договаривается про такое через корпоративную почту. На самом деле их механизмы были куда сложнее, и Veritas был для них очень желанным.

Дело в том, что если вы ставите себе DLP-пакет, то нужно включать журналирование ящиков, потому что пользователи вообще-то могут удалить компрометирующее их письмо. То есть весь трафик будет дублироваться, что совсем уже дико в рамках бюджета заказчика и с учётом опасно разросшейся базы.

«Опасно» — это сами специалисты по Exchange говорят, что так делать не надо:

image

То есть придётся плодить и базы Exchange, и сами сервера Exchange, т. к. если в один сервер положить много баз, то негативный эффект будет тот же, что от одной большой базы.

Как прошло внедрение


Примерно как я описал выше.

На стадии архивации почтовые данные ужались примерно на 40 %. Если обычная почтовая база хранит все копии письма и может только сжать каждую из них чем-то вроде ZIP, то дедупликация на стороне EV позволяет собрать сотни писем в один исходный документ и ссылки на него. Стоит заметить, что дедупликация тут идёт не поблочно, а подокументно, то есть вложения разбираются отдельно от писем.

Далее выяснилось, что вложения индексируются куда лучше, чем мы могли подумать. В EV есть возможность нативно разбирать очень много форматов. И ещё есть распознавание изображений (OCR) в поисках текста для индексации, включая русский текст. Счёт-фактуры и сканы договоров сразу становились русским HTML-документом.

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

Поиск длится пару секунд, потом ещё пару секунд вытягивается на базе индекса (то есть одно письмо, к которому обратился пользователь). Вот поиски:

image

image

Список поддерживаемых полей, в том числе поддержка кастомных тегов в разделе Advanced:

image

Размер заглушек в почтовой базе мы установили в 100 символов. По умолчанию EV предлагает оставлять по 1 000 символов от тела письма. Чтобы прочитать письмо, надо просто кликнуть на него в Outlook, оно онлайн разворачивается из архива и открывается нативно.

Плагин Outlook обеспечивает связку с EV так, что пользователь не выходит из Outlook и не видит, что происходит. Для него это просто отдельная вкладка с другими письмами.

Архитектура выглядит вот так:

image

Тут было важно правильно просчитать баланс между прод-серверами и хранилкой так, чтобы бэкап в пике не перегружал систему. База разбита между пятью инстансами, это 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 по датам. Можно вытащить в архив и все письма старее одного месяца, например.

image

База данных за всем этим 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:

image

Итог


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

У пользователей, условно говоря, снялось ограничение на размер ящика, потому что всё равно всё старое уходит в архив.

Всего мы мигрировали около 26 тысяч почтовых ящиков (из которых активных было около 20, а в остальные иногда надо было заглядывать за старыми письмами).
Теги:
Хабы:
+19
Комментарии 22
Комментарии Комментарии 22

Публикации

Информация

Сайт
croc.ru
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия