Итак, вы решили перенести Exchange в облако. Что дальше? Для начала ответьте на вопросы:
- Что представляет собой инфраструктура?
- Как переместить данные и что это за данные?
- Как обеспечить целостность и подлинность?
- Как обеспечить безболезненное существование инфраструктуры на момент переезда в облако?
- Как обеспечить управление конечными пользователями?
Списком этих вопросов поделился Дэвид Оделл, сервис-архитектор компании Dimension Data, специализирующейся на предоставлении услуг в сфере информационно-коммуникационных технологий. Оделл и его команда накопили колоссальный опыт по переносу почтовых серверов Exchange в облако. В этой статье поделимся практическими советами Dimension Data, которые облегчают процесс переноса почтовых сервисов на облачную площадку.
# Рекомендация 1: Оцените собственное окружение Exchange
«Легко переехать в облако, но нелегко перенести то, что должно находиться в нем. Для успешного переноса инфраструктуры определите, из каких компонентов она состоит и как используется. Это один из сложных и важных моментов», — отмечает Оделл.
# Рекомендация 2: Придерживайтесь стратегии дозированной, последовательной миграции
Многие организации привыкли к онпремизной миграции, которая выполняется в условиях высокой пропускной способности. При миграции в облако этот показатель значительно ниже. Облачные поставщики, защищая себя от потенциальных нарушений SLA, регулируют трафик согласно требованиям, необходимым для осуществления миграции клиента. Оделл приводит пример, в котором компания переносит в облако 12 Тб данных, которые используют 8 тыс. пользователей. Ограничивающим фактором здесь выступает то, насколько быстро возможно осуществить перенос. Учитывая, что в среднем за час переносится 20 Гб данных, мы получаем 614 часов, необходимых для завершения процесса, или 50 дней при условии, что каждый день на миграцию уходит 12 часов. Такие сроки для миграции приемлемы. Если же за час удается скопировать 2 Гб данных, на их перенос с учетом затраченных 12 часов в сутки уйдет минимум 500 дней, а это не очень хороший показатель.
Проще говоря, чем больше данных — тем дольше перенос. Оделл советует переносить данные порционно, передавая сначала необходимый минимум, а затем остальное. Ниже еще несколько советов:
- Оцените пользовательское окружение, выявите, какие почтовые данные следует перенести в первую очередь. Используйте инструменты архивации — они помогут минимизировать объем переносимой информации.
- Пообщайтесь с поставщиком услуг и выясните, может ли он обеспечить достаточную для миграции пропускную способность, определите ограничения по объему перемещаемых данных.
- Оцените инструменты миграции и используйте их на практике.
- Разбейте процесс миграции на этапы и выполняйте перенос данных пошагово. Начните с перемещения почтовых сообщений за последние шесть месяцев, затем перейдите к остальным.
- Уделите внимание вопросу управления первоначальными загрузками. Многие почтовые решения, включая Exchange, используют режим кэширования, позволяющий автоматически скачивать новые сообщения при запуске Outlook и получать доступ к данным с рабочих станций, а не с сервера в облаке. При незначительных объемах миграции этот функционал не имеет значения. Но если 500 пользователей сразу после миграции скачивают почту утром в понедельник, это может сказаться на загрузке сети. Желательно, чтобы при первом обращении такое воздействие было минимальным.
# Рекомендация 3: Уделяйте внимание вопросу управления миграцией
Организации с количеством рабочих мест от 1 тыс. и выше, следуя советам поэтапной миграции, уходят от локального Exchange в сторону облака. В момент миграции одни пользователи работают с локальным Exchange, другие с облачным. Уровень такого гибридного сосуществования определяется бизнес-требованиями. Не переносите Exchange под конец года — в это время стабильность работы систем обработки электронной корреспонденции имеет особую значимость для пользователей.
Сегодня существует огромное количество инструментов миграции для Exchange, но функционал каждого из них отличается. Одни инструменты маршрутизируют почту между двумя площадками, используют маршрутные правила, обеспечивающие доставку почты. Другие работают с локальным почтовым кэшем, помогая исключить проблему «загрузки первого дня».
# Рекомендация 4: Избегайте проблем идентификации в Active Directory
Проработайте вопрос идентификации конечных пользователей. Как правило, на стороне облачного провайдера разворачивается контроллер домена (Active Directory, AD), выполняется синхронизация атрибутов объектов пользователей, куда входят логин и пароль. Для таких задач используйте инструменты управления объектами AD, которые умеют синхронизировать необходимые атрибуты.
# Рекомендация 5: Помните, счастливый клиент — залог успеха
На перенос 1 тыс. пользователей в среднем уходит две недели. Поскольку процесс миграции выполняется постепенно, в этот период возможны следующие проблемы:
- Задержка в доставке почты.
- Некорректное отображение списка участников собрания.
- Некорректное отображение списка доступных «переговорок» и другое.
С точки зрения Оделла, «необходимо наладить коммуникацию с пользователями до, в процессе и после миграции. Сообщить им, чего ожидать, и озвучить временные ограничения сервиса на момент миграции».
Заключение
Проверив работоспособность перенесенного в облако почтового сервера и убедившись в корректности доставки почты, процесс миграции можно считать завершенным. С этого момента нет необходимости в поддержке локальной почтовой инфраструктуры и можно приступать к выводу Exchange-серверов из организации. Сегодня компании чаще отдают предпочтение облачной инфраструктуре, вынося туда ключевые сервисы. Сеть магазинов Hamleys тому подтверждение: ретейлер разместил в облаке «ИТ-ГРАД» Microsoft Exchange, который одновременно выполняет функцию сервера клиентского доступа (CAS) и транспортного концентратора (HT). Размещаясь в облаке IaaS-провайдера, почтовые сервисы вот уже более четырех лет обеспечивают бесперебойную и надежную почтовую коммуникацию.
*Текст подготовлен с использованием материала Dimension Data
