Переход на СПО. Заменить Exchange за 10 дней

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

Особенно остро стоит вопрос переноса сложных приложений. Рассмотрим Microsoft Exchange: это не только почта, но и календари, задачи, контакты и многое другое. Что с этим делать? Какой открытый аналог искать?

Принципиальных вариантов два:

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

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

Рассмотрим процесс миграции во втором варианте. В качестве примера возьмем платформу Zimbra — для нее существуют средства планирования архитектуры и перехода с MS Exchange, что облегчает нам задачу (рис. 1). Не будем рассматривать преимущества данного приложения перед продуктом компании Microsoft, это тема отдельной статьи, рассмотрим лишь непосредственно миграцию. Но миграцию не только как перенос данных, а весь процесс целиком, начиная с планирования архитектуры новой системы.

В качестве примера рассмотрим историю миграции средней компании с численностью сотрудников в тысячу человек.

Существующая инфраструктура и мотивация миграции

Инфраструктура системы совместной работы основана на Microsoft Exchange 2003, обеспечивающем работу пятисот пользователей в головном офисе управляющей компании, а также в семи региональных подразделениях. В ближайшем будущем ожидается увеличение количества филиалов, поэтому необходимо строить систему с расчетом на тысячу пользователей.

Существующий Microsoft Exchange работает на одном сервере в головном офисе ( два центральных процессора, 16 Гб оперативной памяти, SCSI RAID10). Используются отдельный внешний антиспам и антивирус Symantec. Система интегрирована с доменом Microsoft Active Directory 2003.

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

Второй мотив: в одном из региональных подразделений было успешно переведено на Linux более 60% рабочих мест, и в перспективе планируется масштабное внедрение Linux-десктопов. Однако для Exchange есть только один полноценный клиент — Microsoft Outlook, который не работает на Linux. Поэтому необходима “более кросс-платформенная” альтернатива.

Была выбрана система на базе Zimbra Collaboration Suite, так как она обеспечивает более дешевую альтернативу Microsoft Exchange, а на работу пользователей повлияет минимально. В том числе есть готовые инструменты для переноса пользовательских данных и настроек, а после миграции пользователи могут применять привычные инструменты для работы (в данном примере основным исторически является Microsoft Outlook). Кроме того, для Zimbra существует кросс-платформенный клиент совместной работы Zimbra Desktop, способный заменить Outlook и при этом работающий на Windows, Linux и Mac OS (рис. 2).

Планирование целевой системы

При проектировании учитывались следующие факторы:

• в качестве антиспама и антивируса для Zimbra будет использоваться существующий фильтр Symantec. Этот фактор крайне важен, так как позволяет отключить на сервере Zimbra встроенные антиспам и антивирус и тем самым заметно снизить нагрузку на него;
• необходима интеграция с Active Directory , поскольку здесь хранятся все пользователи, а также глобальная адресная книга, которые необходимо сохранить;
• архитектуру системы будем рассчитывать так, чтобы максимально допустимый по длительности простой системы в течение нескольких часов случался не чаще раза в год. Этот фактор также крайне важен, так как позволяет для обеспечения отказоустойчивости ограничиться использованием RAID и разумной политики резервного копирования для защиты данных. Создание отдельного отказоустойчивого кластера в данном проекте выглядит избыточной мерой, которая приведет только к излишней сложности и удорожанию инфраструктуры.

Точные требования к оборудованию определялись исходя из анализа нагрузки на существующую систему: число одновременно активных пользователей, используемые протоколы для доступа к системе, общее количество входящих и исходящих сообщений, наличие пиковых периодов, доля сообщений в пиковые периоды, средний размер сообщений и т. д.

Оказалось, что благодаря современной архитектуре Zimbra можно обеспечить работу тысячи пользователей на одном сервере, аналогичном тому, на котором работает имеющийся Microsoft Exchange. Для долговременного хранения архивов и резервных копий данных используются более медленные, но более емкие и дешевые SATA-диски.

Предполагалось, что на первом этапе после миграции большинство пользователей продолжит работать в Microsoft Outlook (синхронизация с Zimbra через MAPI). Фактически пользователи в этом случае не замечают замену сервера. Освоить новый интерфейс придется лишь тем, кто для работы через браузер использовал Outlook Web Access: им нужно будет привыкнуть к Zimbra Web Client (рис. 3). Благодаря такому подходу дальнейший перевод пользователей на Linux и Zimbra Desktop проходит постепенно и не сказывается на работе организации.

Ход проекта

Перед основным развертыванием системы и выполнением миграции, разумеется, необходимо аккуратно обследовать инфраструктуру и по его итогам спланировать весь проект. Затем нужно пройти этап пилотной эксплуатации новой системы на небольшой группе пользователей, чтобы убедиться, что они действительно смогут успешно работать после перехода на Zimbra. Данные этапы по-своему уникальны для каждой организации. К тому же, как правило, в средних компаниях без жесткого проектного планирования они проходят параллельно с текущей работой “в фоновом режиме”. Поэтому приводим описание только основной части проекта — непосредственно перехода на новую систему.

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

Принципиально возможны два подхода:

• отдельно настраивается совместная работа серверов Exchange и Zimbra, пользователи постепенно переводятся с одного на другой без остановки системы (рис. 4);
• существующая система блокируется, выполняется перенос данных, включается новая система.
• В общем случае более изящным выглядит первый подход, но так как он требует дополнительной работы, то зачастую проще оказывается отключить систему на какое-то время в период низкой активности, например, в выходные или праздничные дни.

Результаты

Полный переход с Exchange на Zimbra от момента согласования плана работ до отключения Exchange занял две недели.

• Для активного сопровождения тестовой эксплуатации потребовалась еще одна неделя.
• Пользователи после перехода могут работать с привычными инструментами, такими как Microsoft Outlook.
• Начат поэтапный переход на кросс-платформенный клиент совместной работы Zimbra Desktop, что в дальнейшем позволяет упростить масштабное внедрение Linux-десктопов.