Недавний инцидент с обновлением CrowdStrike наглядно продемонстрировал, насколько рискованно бывает полагаться на единственного подрядчика. Всего одна ошибка в обновлении привела к глобальному хаосу: миллионы ПК на Windows поймали BSOD. Сбой затронул аэропорты, больницы, банки — всё встало. Ошибку быстро нашли и устранили, но последствия «синего экрана смерти» госконторы и бизнес разгребали долго. Этот инцидент заставил многих задуматься: не пора ли диверсифицировать свою облачную стратегию и перейти от работы с одним провайдером на мультиклауд?

В России, по разным данным, 20–30% компаний уже используют мультиоблако. Для сравнения: в Великобритании 46% предприятий планируют работать сразу в нескольких публичных облаках одновременно. Это мировой тренд, который, по всей видимости, будет нарастать. В статье разберем, какие у мультиклауда есть подводные камни и куда рынок двинется дальше.

Когда пора переходить на мультиоблако: распространенные сценарии

Для одних мультиоблачная стратегия — вопрос выбора, для других — вынужденная мера. Вот пять самых распространенных сценариев из практики mClouds, когда компании переходят на мультиклауд.

Разные подразделения — по разным облакам. Чаще всего мультиоблачную модель выбирают организации со сложной структурой — группы компаний, холдинги. Чтобы не складывать все яйца в одну корзину, разные подразделения и структуры в таких организациях работают с разными облаками. Так в случае сбоя или нештатной ситуации на стороне провайдера — такое случается абсолютно у всех облачных провайдеров независимо от их размера — проблема не заденет всех сразу. По той же причине, кстати, локальную инфраструктуру тоже часто распределяют или территориально, или по разным ЦОД.

Другой вариант: холдинг покупает небольшую компанию, инфраструктура которой уже привязана к какому‑то локальному провайдеру. Обычно оставить всё как есть бывает дешевле и проще, чем пытаться перенести всю IT‑инфраструктуру на основное облако головной компании. В итоге холдинг обзаводится несколькими облаками и поневоле переходит на мультиклауд.

Разные сервисы — по разным облакам. Компании поменьше по созвучным причинам делят по разным облакам сервисы. Например, 1С у них работает из облака одного провайдера, а DR‑сервис — другого.

Второе облако как резервная площадка. Еще один распространенный кейс перехода на мультиоблако — когда компания строит свою IT‑инфраструктуру на базе одного облачного провайдера, а резервные копии и холодные данные хранит у другого. Реже второе облако используют как полноценную резервную площадку для репликации данных, на которую можно быстро перейти в случае проблем в основном облаке.

Разные регионы — по разным облакам. Иногда для работы сервисов, которые компания предоставляет конечным пользователям, важна мгновенная скорость отклика. Например, в компьютерных играх. Добиться такой скорости можно только с помощью локальных провайдеров, чьи облака максимально приближены к пользователям. У таких компаний обычно целая сеть облачных провайдеров в разных регионах.

Разные страны — по разным облакам. Второй сценарий, когда компании буквально вынуждены переходить на мультиоблако, связан с требованием законодательства той или иной страны к хранению персональных и других чувствительных данных. Такие требования есть не только в России. Это заставляет международные компании прибегать к услугам местных облачных провайдеров для локализации данных пользователей.

Три подхода к созданию мультиоблачной инфраструктуры

Задачи, которые решает мультиклауд, определяют подход к созданию такой инфраструктуры. Их всего три.

• Разделение. Компания делит свои продукты, проекты или подразделения по разным облакам. Такой вариант используют, когда связанность между разными сущностями не важна. Например, когда подразделение в Самаре работает с самарским облачным провайдером, а в Балашихе — с подмосковным.

• Дубляж. Такой подход еще называют Active‑Passive — когда компания разворачивает веб‑сервисы сразу в нескольких облаках, одно из которых будет резервным. В случае проблем с основным облаком можно будет вручную переключить трафик на резервное, а с опытной командой время простоя удастся сократить с нескольких часов до нескольких минут. Плюс такого подхода — в резервном облаке можно тестировать обновления, ничем не рискуя.

• Параллельная работа. Схема Active‑Active предполагает, что сервисы компании работают на нескольких облаках одновременно, а бэкапы и оркестрация выполняются автоматически. Это самый сложный в реализации подход, который приносит бизнесу максимальную пользу, если всё правильно спланировать.

Как это работает

Пока управление мультиоблаком — не самая простая на свете задачка. В России мы пока не встречали единых консолей, которые позволяли бы нормально работать с облаками разных провайдеров. Обычно сисадмины управляют разными облаками вручную из разных консолей. Для пользователей все это выглядит как единое облако, даже если 1С или другие базы работают в одном облаке, а часть данных подгружается из S3-хранилища в другом.

Пока самая толковая платформа для оркестрации и управления мультиоблачной инфраструктурой — Terraform. Она умеет координировать работу с несколькими облачными провайдерами в рамках единого рабочего процесса. Подробнее о своем опыте работы с этой платформой писали здесь.

Плюсы и минусы мультиоблака

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

Из плюсов:

• Работа с региональными провайдерами позволяет поднять до максимума скорость отклика и доступность продуктов компании для конечных пользователей. Такой эффект достигается просто за счет географической близости облачных площадок провайдеров к пользователям.

• Диверсификация облачной инфраструктуры повышает устойчивость IT‑систем компании к форс‑мажорам: у облачного провайдера загорелся ЦОД или вышло кривое обновление — неважно, бизнес‑приложения продолжают работать из другого облака.

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

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

Из минусов:

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

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

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

• При обмене данными между облаками могут возникать задержки. Их продолжительность зависит от степени интеграции между облаками разных провайдеров, удаленности ЦОДов и частоты взаимодействия.

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

Резюме

Мы в mClouds рекомендуем клиентам, которые рассматривают переход на мультиоблако, подумать вот о чем:

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

• Ваш текущий провайдер точно не способен обеспечить работу бизнес‑приложений в регионах присутствия? Если речь идет только о disaster recovery, возможно, проблему можно решить в рамках текущего провайдера.

• Насколько совместимы между собой инструменты разных облачных провайдеров? При переходе на мультиоблако есть шанс получить два альтернативных набора инструментов, которые решают одни и те же задачи и плохо дружат между собой.

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