Переезжаем в облако наполовину: как не наделать ошибок при частичной миграции сервисов

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

Почему бизнес идет на частичный перенос инфраструктуры

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

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

Помимо расходов на старте нужно учитывать постоянный рост нагрузок и необходимость обновления оборудования и ПО. В облаке расширить инфраструктуру — дело минут, а докупать серверы и вводить их в строй — часто месяцы. Но главное — аренда облачных ресурсов под ключ выходит дешевле аренды одной стойки в ЦОД и точно перекрывает затраты на работу в on-premise. Многим выгоднее и проще отдать это облачному провайдеру и сосредоточить усилия собственно на бизнес-сервисах компании, чем разбираться в непрофильной сфере и тратить на это ресурсы.

Что оставлять на собственных серверах, а что переносить в облако

Сейчас облака в РФ уже достаточно зрелые, чтобы надежно работать с любыми сервисами. Мы наблюдаем два параллельных тренда. Малый и средний бизнес разворачивает сервисы и работает с ними сразу в облаке. Крупный бизнес в любом случае создает гибридную инфраструктуру: размещает ключевые сервисы в собственном контуре, а в облако переносит только часть инфраструктуры, включая тестовые среды.

Обычно в локальной сети оставляют то, что требовательно к задержкам. Например, не выше 2 мс. Хотя в облаке тоже можно получить быстрый отклик, если подключаться не через интернет, а по выделенному каналу до ЦОДа провайдера.

Решение, что переносить, чаще всего лежит на стыке запросов бизнеса, его финансовых возможностей и стоимости простоя системы. Мы как провайдер задаем десяток вопросов, чтобы выявить истинные потребности заказчика.

Вот что чаще всего делегируют облаку:

• Тестовые среды и среды разработки. В облаке можно гибко добавлять ресурсы и тестировать железо, не покупая его. Можно проверить, как будет работать задача на процессорах разных поколений или с разной частотой — выше 3 ГГц или ниже. Это хороший вариант, чтобы выбрать подходящий сервер, который затем можно использовать и локально, и в облаке провайдера. Также этот опыт поможет выбрать и самого провайдера.

• Почтовые серверы. Несмотря на то что многие используют публичные почтовые сервисы, корпоративная почта сейчас есть у всех компаний. С уходом из России Microsоft многие стали мигрировать с Exchange Server и Office 365 на другие почтовые серверы, в том числе оставляя их в локальной инфраструктуре. Однако в облаке развернуть их быстрее и проще. Не нужно покупать лицензию. Можно платить по количеству пользователей: стало больше — добавили, меньше — убавили. Плюс администрирование этих сервисов — уже забота провайдера. От внутренних специалистов потребуется только участие в настройке сервиса и мониторинге. Поэтому почтовые серверы тоже часто переносят в облако.

• ERP, СУБД. Некоторые приложения изначально требовательны к инфраструктуре: рабочему серверу, веб-серверу, сетевому оборудованию, дисковому пространству. К примеру, большинству ERP-систем нужен внушительный объем оперативной памяти сервера — до нескольких терабайт. Такое может обеспечить не каждый.

  Самое распространенное корпоративное приложение — 1С. Особенно его доля выросла после ухода западных вендоров. И число миграций проектов по 1С в облако растет соответственно.

А вот примеры из нашей практики, какие еще задачи удобнее решать, если часть сервисов перенести в облако.

Одному из заказчиков mClouds нужно было создать резервный ЦОД в облаке — на случай проблем на стороне компании и чтобы не вкладываться в построение второй площадки для дублирования.

Другому — нарастить мощности, чтобы проводить расширенное тестирование обновлений и разработок перед вводом в продакшен. Текущего тестирования «на земле» ему было недостаточно: не хватало объема памяти, поскольку среда полностью зеркалировалась, а тесты проводили во время «больших обновлений». Проблему можно было решить и своими силами: создать снапшот и выполнить обновления, в случае успеха — удалить снимок системы, в случае провала — откатиться назад. Но инженеры заказчика такой вариант отмели, чтобы не затрагивать целостность «боевой» системы и не пересекаться с расписанием выполнения резервной копии. Так, изначально заказчик искал внешнюю площадку для тестирования, а в итоге пришел к размещению своей системы в облаке, а под тестирование отвел площадку «на земле».

Частичная миграция: как провести, чтобы не парализовало всю систему

Миграцию можно провести онлайн. Один вариант — перенести последние образцы виртуальных машин или восстановить их резервные копии сразу в облако. Другой — постепенно отгружать в облако реплицированные виртуальные машины.

Для непрерывной репликации рабочих нагрузок мы используем Hystax Acura. На стороне клиента устанавливается агент, который постепенно реплицирует данные в облако. Дальше остается только переключиться на реплицированную копию в облаке, и можно продолжать работу.

Собрали несколько рекомендаций, как сделать процесс миграции плавным и безболезненным, какой бы способ миграции вы ни выбрали:

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

• Спланировать миграцию. Обозначьте даты, сроки и определитесь, какие части инфраструктуры будете переносить в облако. Оцените объем данных. Распишите по шагам, что и в какой момент будете делать. В процессе важные вещи могут выпасть из фокуса и нарушить работу.

• Сделать бэкапы. Если в ходе миграции что-то пойдет не так, резервная копия будет весьма кстати. Казалось бы, очевидный момент. Но лучше всё равно прописать, чтобы не упустить из виду.

• С умом выбрать время миграции. Не переносите сервисы онлайн в самые загруженные периоды. В процессе могут появиться новые вводные, которые увеличат время переноса нагрузок в облако.

• Скоординировать работу администраторов корпоративных сервисов и инженеров облачного провайдера. Чтобы процесс прошел максимально бесшовно, обе стороны должны работать в тесной связке. В инфраструктуре компании могут быть разные особенности, о которых нужно знать провайдеру. Например, заказчик развернул в облаке контроллер домена для отказоустойчивости, а «на земле» — выключил. Одна из баз PostgreSQL оказалась недоступна, хотя СУБД была на выделенной виртуальной машине и данные хранились там же. Через некоторое время администратор из отпуска пояснил, что на втором контроллере домена «на земле» была NFS-шара, где хранилась база данных, которая была недоступна. Из-за того, что провайдер был не в курсе, он не смог оперативно помочь.

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

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