Инструкция по переходу на российские облака
Облачные технологии создавались по аналогии с электростанциями. Когда-то каждое крупное производство имело собственную подстанцию, но со временем компании пришли к выводу что это не профильный актив и необходимо использовать общую подстанцию для экономии средств.
Так же и с облаками. Для организации отказоустойчивой инфраструктуры необходимо резервировать оборудование для каждого бизнес-критичного сервиса, желательно размещая резервные мощности в локации, которая находится в другом здании или городе. Плюс ко всему появляются дополнительные расходы на аренду помещений, запасные части для серверов, затраты на поддержку и прочие накладные расходы. Поэтому облака помогают бизнесу решать следующие задачи:
-
Непрерывность бизнес-сервисов
-
Экономия на оборудовании и аренде помещений
-
Оплата только за тот объём ресурсов, которым пользуется организация
-
Быстрый запуск продуктов и сервисов (time to market)
-
Отказоустойчивость и катастрофоустойчивость
-
Возможность обращаться за помощью к высококвалифицированным специалистам, помощь которых требуется раз в квартал или год.
Подготовительный этап
Любой проект необходимо начинать с обследования текущей архитектуры.
1. Опишите сервисы, которые вы планируете мигрировать в облако
2. Включите в описание этих сервисов компоненты, из которых они состоят
-
Названия серверов (внешние и внутренние DNS имена)
-
Сервер приложений, база данных, операционная система, версионность ПО и ОС
-
Порты, по которым приложение работает
-
Варианты доступа к приложению (https, VPN, RDP)
-
Оцените объём данных приложения или сервиса
-
Метод доступа к приложению (SSO, ActiveDirectory, RMS, стороннее приложение)
-
Пользователи или группа пользователей, которые имеют доступ к приложению
3. Сделайте резервную копию сервиса или приложения, которое собираетесь мигрировать
4. Согласуйте с бизнесом сервисные окна, в которые приложение или сервис можно будет мигрировать
Выбор провайдера
Облачных провайдеров в России много, но можно ограничить круг поиска используя следующие критерии:
-
Как долго облачный провайдер работает на российском рынке? Как правило выбирают тех, кто работает больше 5-7 лет.
-
Есть ли среди клиентов облачного провайдера известные компании (как коммерческие, так и государственные).
-
Может ли провайдер оказывать услугу под ключ? Способен ли провайдер помимо доступа к своему облаку оказывать услуги внедрения, сопровождения или доработок под Ваше ТЗ?
-
Запросите у облачного провайдера статистику работоспособности сервисов за последний год. Это покажет вам на сколько часто у провайдера происходят сбои или аварии.
-
Запросите количество ДатаЦентров в РФ. Их должно быть не меньше 3-4.
Выбор типа облака (публичное, частное, гибридное). Архитектурные особенности облака
Для того, чтобы определиться с типом облака используйте следующие индикативы:
Публичное облако – это облако, которое работает на оборудовании провайдера. Ресурсы в публичном облаке распределяются между всеми клиентами провайдера в соответствии в SLA, которые указаны по каждому облачному сервису. Как правило стоимость таких облаков существенно ниже всех остальных вариантов.
Плюсы такого варианта – цена
Минусы – изменения стандартных шаблонов и сервисов для публичного облака не доступны в связи со стандартизацией данной услуги.
Частное облако – это облако, которое работает в ДатаЦентре клиента на оборудовании самого клиента. Смысл облака заключается в том, что у вас появляется возможность изолировать сервисы для структурных подразделений или юридических лиц вашей компании на одном оборудовании. Проще говоря на одном сервере две фирмы, могут запускать одноимённый сервис, который не будет конфликтовать со своим клоном.
Плюсы такого варианта – всем управляете только вы сами
Минусы – затраты на оборудование, аренду, запасные части, дополнительная аренда помещений, необходимость затрат на обновление серверного парка спустя 3-5 лет.
Гибридное облако – это облако, которое работает и у вас, и у провайдера одновременно. Другими словами, одна база данных может работать в вашей серверной и копироваться для аварийного восстановления к облачному провайдеру. Либо это может быть сервис 1С, где база данных храниться в Вашем ДЦ а сервер приложений работает на стороне облачного провайдера.
Плюсы такого варианта – избыточная отказоустойчивость
Минусы – при выходе из строя Вашего ДЦ те сервисы, которые не были дублированы на стороне облачного провайдера, станут не доступными на время восстановления.
Выбор технологии миграции
Использование технологии миграции зависит от того, на какое время сервис может быть недоступен бизнесу. Перечислим основные технологии:
-
Бэкап и последующее восстановление. Этот вариант подходит тем компаниям, которые переносят сервис в нерабочее время. Первым этапом мы создаём резервную копию сервиса в нашей инфраструктуре, а вторым этапом восстанавливаем сервис из резервной копии на стороне провайдера. После восстановления сервиса запускаем виртуальные машины и настраиваем программное обеспечение клиентов на использование нового адреса.
-
Параллельный запуск. Этот вариант подходит компаниям, которые переносят сервис, который может прерываться на короткое время. Изначально, как и в первом варианте создаётся резервная копия сервиса, которая в последующем разворачивается в облаке провайдера. Затем сервис запускается параллельно работающему сервису и настраивается синхронизация баз данных и/или приложений. В согласованное с бизнесом время пользовательский трафик переключается из ДЦ клиента в ДЦ облачного провайдера.
-
Аварийное восстановление. Данный сценарий используется компаниями, которые создают на стороне облачного провайдера зеркальный экземпляр сервиса на случай выхода из строя собственной инфраструктуры. Для этих целей облачные провайдеры используют специальное программное обеспечение, которое в режиме реального времени синхронизирует приложение из ДЦ клиента в ДЦ облачного провайдера. В момент, когда ДЦ провайдера становится недоступным запускается экземпляр приложения на стороне облачного провайдера и пользовательский трафик переключается на облако провайдера. Как только ДЦ клиента снова доступен и начинает работать в обычном режиме пользовательский трафик переключается обратно в ДЦ клиента. Плата за данный сервис взимается за дисковое пространство и время работы авариного экземпляра.
Миграция и последующая эксплуатация
После того как сервис успешно переносится к облачному провайдеру клиенты тестируют решение в рамках месяца. После успешного тестирования пользовательская нагрузка переключается на облако, а приложение или сервис в ДЦ клиента выключается.
Резюме
Большинство бизнес-сервисов можно перенести в облако для экономии средств и ресурсов компании. Как правило в облако переносят непрофильные активы или сервисы, которые используют абсолютно все организации. Среди таких сервисов можно перечислить следующие:
-
Терминальный сервер
-
Сервер 1С
-
Файловый сервер
-
Почтовый сервер
-
CRM система
-
Сайт или корпоративный портал
-
Пилотная или тестовая инфраструктура
-
Сервер резервного копирования
-
Сервер мониторинга
Список можно продолжать долго. Самое главное – это польза от ИТ для бизнеса, а вариант реализации конечно же каждая компания должна выбирать сама.
Опубликовано 30.06.2022
