вернуться на главную
Статьи

Правильная стратегия:

Почему мультиоблако лучше, чем облако от одного провайдера

Gartner предполагает, что глобальные расходы на внедрение облачных технологий вырастут к 2023 году до $500 млрд (по итогам 2019 они составили $229 млрд). И один из трендов этого рынка – мультиоблачная стратегия. Что это такое, кому она может быть интересна и для чего нужна? Как управлять сервисами в мультиоблаке? Попробуем разобраться.

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

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

Частное

Глобальный сервис AmoCRM работает сегодня на мультиоблаке, у которого три плеча: российское, основное – на Mail.ru Cloud Solution (MCS), резервное – на Amazon WS и американское – Rackspace, основное для американцев.

До определенного момента компания обходилась двумя зарубежными площадками. К переменам их подвигли неожиданно возникшие проблемы с доступом – в связи с блокировками Роскомнадзора, а также необходимость соблюдать требования российского законодательства по хранению персональных данных на территории РФ. И вот что удивительно: хотя переезд на платформу российского провайдера первоначально выглядел как вынужденный, он принес неожиданный позитивный эффект и в техническом отношении, и в экономическом. После миграции на MCS российские клиенты сервиса стали загружать файлы в 2–2,5 раза быстрее, а плата за хранение и скачивание составляет примерно столько же, сколько раньше выходило за одно хранение. И что еще важно: техническая поддержка – на уровне западных стандартов качества.

Кому оно нужно?

На сегодня мультиоблако интересует, прежде всего, крупный, территориально-распределенный бизнес – например, из банковской сферы, а также поставщиков разнообразных SaaS-сервисов, которым нужно гарантировать доступность, близкую к 100%. Для глобальных компаний важным является выполнение требований местного законодательства по хранению персональных данных, а также скорость доставки контента, которую можно увеличить за счет сервиса по доставке контента (CDN) от местного провайдера.

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

Есть отраслевые вариации и в использовании частной или публичной моделей. Так, публичное мультиоблако распространено среди цифровых компаний, а в корпоративном сегменте – нефтегазовая отрасль, добывающие, металлообрабатывающие компании, – наоборот, преобладает вариант частного мультиоблака. Зачастую облачная эволюция в сегменте еnterprise начинается с конфигурации частного мультиоблака, а затем добавляется публичное плечо.

Какие риски нивелируем

Итак, основной риск использования одной облачной платформы – зависимость от одного вендора (vendor lock). Производные от него риски – временная недоступность сервиса в

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

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

Не все так мило

Конечно, как у любой технологии у мультиоблака есть свои ограничения, о которых следует знать и помнить. Дело в том, что по своей сути оно предполагает объединение различных в технологическом отношении платформ. Из-за этого возникают сложности по организации единого управления приложениями или сервисами, снижается гибкость платформы в целом. Мультиоблако, одновременно поддерживающее и MCS, и AWS, и Azure, и Google Cloud, сильно ограничено по функционалу, потому что у каждой из платформ свои стандарты, и отсутствуют единые.

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

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

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

… и не все так плохо

Технологии Kubernetes и Docker позволяют снять многие свойственные мультиоблаку ограничения, и это очень перспективное направление развития. Да – у облачных платформ разные гипервизоры, системы виртуализации, форматы хранения файлов операционных систем и образов приложений. Зато технология Docker обеспечивает единый формат приложений. В результате одно и то же приложение можно запустить на любой платформе, и во всех случаях это будет один и тот же файл, который запускается без изменений. Федеративный кластер Kubernetes, со своей стороны, дает возможность установить, отмасштабировать приложение из единой панели управления. Отметим, что у MCS есть такой инструмент, и это как раз пример взаимовыгодного сотрудничества двух крупных облачных провайдеров – AWS и MCS.

Как перейти

Основные этапы перехода на мультиоблако:

1. Четкое понимание, зачем нужен еще один облачный провайдер, какие преимущества это даст;

2. Отказ от проприетарных сервисов в пользу базовых, воспроизводимых на любой из платформ – это обеспечивает гибкость мультиоблака, дает возможность удобно администрировать сервисы с одной консоли;

3. Описание инфраструктуры декларативным языком, представление ее как определенного кода (IaC) – если это сделать, можно будет переходить от одного провайдера к другому, всего лишь изменив несколько строк в коде и точку назначения (end point);

4. Настроить репликацию данных между платформами;

5. Протестировать инфраструктуры в новой, мультиоблачной конфигурации – например, отключить одного из провайдеров, чтобы убедиться в том, что все работает у другого.

Есть еще другой вариант создания мультиоблака: клиент хочет воспользоваться проприетарным сервисом конкретного провайдера – например, в целях экономии. В этом случае просто возникнут дополнительные сложности при администрировании, поскольку понадобится использовать для управления сервисами разный инструментарий.

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

MCS помогает и в стратегии, и в тактике

MCS оказывает клиентам полную поддержку при создании мультиоблака – и стратегическую, и тактическую.

Один из важных платформенных (PaaS) сервисов – инструмент по созданию мультиоблачных кластеров на основе федерации Kubernetes, который уже упоминался выше.

Он дает возможность управления приложениями, которые находятся одновременно и в публичном (или частном) облаке MCS, и на облаке Amazon. Например, глобальная игровая компания, запускается на AWS, имея плечо в виде кластера Kubernetes на MCS. Это позволяет, в том числе, и в случае падения одного из провайдеров осуществлять перенос нагрузки из одного облако в другое. Вторая поддержка, которую оказывает MCS в контексте мультиоблака, – партнерство с компанией Acronis. Их совместное решение позволяет клиентам создавать резервные копии в другом облаке. Есть и специальные сервисы, позволяющие делать аварийное восстановление (Disaster Recovery) в мультиоблачной модели.

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

 

Автор текста: TAdviser
Персональный
воркшоп по облакам
Вы задаете вопросы – эксперты Mail.ru Cloud Solutions готовятся и отвечают
Зарегистрироваться