В поисках мультиклауда
06.05.2020
Облачные услуги постепенно стали необходимы бизнесу как воздух – или, вернее, как электричество. По-настоящему удобны они делаются тогда, когда их можно использовать по мультиклаудной модели: брать разные услуги у разных провайдеров и легко их менять.
Появление облачных технологий любили сравнивать с появлением электричества. Когда-то в жилище с наступлением темноты зажигали свечи или керосиновую лампу. Теперь достаточно щелкнуть выключателем. И не надо думать, какая ГЭС произвела электричество, какая электросеть его доставила. Магистральные сети страны связаны, нехватка мощности в одном районе легко компенсируется свободными мощностями другого.
В облачных технологиях до этого еще не дошло, и потребитель должен сам выбирать, какую «ГЭС» использовать, разбираться в ее особенностях и подстраивать под нее свое оборудование. Но процесс идет. Облачные услуги все больше становятся типовыми, успех нового сервиса у одного облачного провайдера приводит к появлению аналогичных сервисов у конкурентов. Потребитель не хочет быть привязан к одной «электростанции», ему нужна свобода выбора. У одного поставщика выгоднее тариф на одну услугу, у другого – на другую. Один провайдер предлагает отличное решение в области финансов, другой – в лингвистике. Хочется взять все лучшее, чтобы все работало в комплексе, но без жесткой привязки к поставщикам услуг, чтобы при изменении ситуации можно было безболезненно перенести сервис от одного провайдера к другому. Перейти к связанности «магистральных сетей», к использованию мультиоблака.
От облака к мультиклауду
Термин «мультиклауд» и его перевод «мультиоблако» употребляются в статьях и докладах на конференциях все чаще. При этом специалисты понимают термин по-разному. Попробуем разобраться, какой смысл вкладывают в него эксперты на российском рынке.
В моем понимании мультиклаудные вычисления – это потребление облачных сервисов от разных поставщиков или на разных платформах при построении единой интегрированной инфраструктуры заказчика. Например, когда клиент разворачивает инфраструктуру в облаках двух разных провайдеров, которые резервируют друг друга для обеспечения отказоустойчивости, или инфраструктура распределяется между облаками на разных платформах для использования преимуществ каждой них при решении конкретных задач. То есть мультиклауд предполагает администрирование нескольких облаков. Специальные программные инструменты для единообразного управления разными облаками помогают повысить эффективность мультиклаудных инфраструктур. А вот системы, распределенные по разным кластерам (зонам доступности) одной платформы одного провайдера, скажем, традиционные решения для обеспечения катастрофоустойчивости, я мультиклаудом не считаю. Хотя, возможно, в будущем понятие мультиклауда будет расширено и на такие случаи. Илья Хала, генеральный директор, 3data
|
В самом использовании нескольких облаков нет ничего нового. Еще лет восемь назад в банке, где я работал, по модели SaaS функционировала система интернет-банкинга, расположенная в облаке ЦФТ в Новосибирске, у другого провайдера размещалась почта, у третьего – веб-сайт организации. Формально можно считать, что уже тогда у нас было мультиоблако, хотя такого термина мы не знали. В терминологии архитектора облачных решений компании Crayon Андрея Дубровина у нас был «мультиклауд 1.0» – традиционное решение, подразумевающее использование нескольких облачных сервисов от разных провайдеров.
Сейчас у большинства специалистов сформировалось понимание, что мультиклауд – это нечто большее – некая интегрированная система из нескольких облаков (рис. 1). Если смотреть с точки зрения облачного провайдера, то она должна быть как минимум объединена общим биллингом. Например, по такой схеме работает ряд российских облачных провайдеров, предоставляющих доступ к облакам гиперскейлеров Amazon Web Services, Microsoft Azure, Google Cloud Platform и Alibaba Cloud и позиционирующих услугу как мультиоблачную. В этом случае клиент работает с одним поставщиком, что удобно прежде всего его бухгалтерии: можно получить сводную ведомость по расчетам с разными облаками и все необходимые финансовые документы, да еще и произвести оплату в рублях.
Рис. 1. Этапы развития мультиоблачных технологий
А вот, скажем, Gartner не акцентирует внимание на биллинге, считая, что мультиоблако – это несколько сервисов облачных вычислений в единой гетерогенной архитектуре, используемой для ослабления зависимости от отдельных поставщиков, повышения гибкости и предотвращения аварийных ситуаций. От гибридного облака оно отличается тем, что охватывает несколько провайдеров общедоступных облаков, а не несколько режимов развертывания (публичный, частный).
Шире трактует понятие IDC, включая в мультиклауд помимо публичных частные облака: «Мультиклауд – это организационная стратегия или архитектурный подход к проектированию сложной цифровой услуги, которая включает использование облачных услуг более чем одного поставщика сервисов. Это могут быть частные облачные сервисы, сервисы вычислений в публичном облаке, хранилища общедоступных объектов от нескольких провайдеров или IaaS- и SaaS-сервисы от одного или нескольких провайдеров облачных сервисов».
Компания VMware включает в свое определение мультиклауда и гибридное облако. Так, архитектор бизнес-решений VMware в России и СНГ Артем Гениев считает, что оно является подвидом мультиоблака в случае, когда помимо собственных on-premise-облаков компания использует облака нескольких провайдеров.
Мультиоблако – это не обязательно несколько разных облачных провайдеров и/или платформ разных вендоров. Андрей Гусев,
руководитель направления по решениям для управления облачной инфраструктурой, IBM в России и СНГ
|
А некоторые эксперты считают целесообразным выделять два вида мультиклауда – частный и гибридный. Частный мультиклауд объединяет несколько частных облаков – например, облака на Hyper-V, VMware и OpenStack. Основная задача такой системы – интеграция управления и мониторинга частных облаков. Гибридный мультиклауд – это публичные облака нескольких провайдеров плюс частная инфраструктура. «Многие банки используют облако для размещения сред разработки и тестирования, но при этом оставляют в частной инфраструктуре продуктив, который нужно контролировать строже. В этом случае публичные облака увеличивают мощность частной инфраструктуры, что особенно актуально в отраслях, которые только прошли или проходят цифровизацию. Кроме того, привлечение публичных аутсорсеров-разработчиков тоже стимулирует «гибрид»: пустить их в публичное облако безопаснее, чем в частную корпоративную систему», – поясняет руководитель Mail.ru Cloud Solutions Илья Летунов.
Функциональный подход
К определению понятия «мультиклауд» можно подходить через его характеристики. Судя по итогам голосования на сайте iksmedia.ru, наиболее важной характеристикой для мультиклауда (35% ответов) является наличие единой системы управления несколькими облаками (рис. 2). Отмечались также «возможность автоматизированной переброски нагрузки между облаками» (17% проголосовавших выделили эту характеристику как наиболее важную), «использование конкурирующих сервисов из нескольких облаков» (11%).
Рис. 2. Наиболее важные характеристики мультиклауда
В опросе, который был проведен в группе RCCPA на Facebook, предлагалось указать несколько характеристик, обязательных для того, чтобы решение относилось к мультиоблачным. Помимо очевидной характеристики – наличия нескольких облаков, эксперты выделили возможность автоматизированной переброски нагрузки между облаками. То есть мнение, что мультиоблако – это не только набор используемых облаков («мультиклауд 1.0»), но и многооблачный сервис с возможностью миграции между облаками, на нашем рынке уже сложилось.
Важность переброски нагрузки между облаками отметили и опрошенные «ИКС» эксперты. «Мультиклауд – это в первую очередь возможность быстрой и прозрачной для пользователей миграции рабочих нагрузок между различными поставщиками облачных услуг», – заявил руководитель департамента R&D ActiveCloud Сергей Горлинский.
Интересный результат – невысокий процент опрошенных экспертов RCCPA, считающих необходимым свойством мультиклауда наличие единой системы биллинга. Так, заместитель генерального директора Selectel Сергей Пимков уверен: «Единый биллинг, панель управления, способ оплаты или автоматизация развертывания не являются неотъемлемыми элементами мультиклаудного решения. Эти возможности лишь повышают удобство его использования, а в ряде случаев выступают потенциальным источником проблем. Например, общий биллинг в такой системе может стать единой точкой отказа». Но у отнесения единого биллинга к необходимым свойствам мультиоблака есть и сторонники.
В то же время многие эксперты рассматривают как критически важную для мультиклауда единую систему управления несколькими облаками. По мнению И. Летунова, основное преимущество мультиоблачной архитектуры – это интеграция: общая панель управления сервисами разных поставщиков с агрегированными управлением, мониторингом, биллингом и отчетом по расходам. В части управления важно, что мультиклауд позволяет обслуживать облака самостоятельно, без ручных операций со стороны провайдеров.
Схожее мнение о необходимости единой системы управления имеет и директор NetApp в России и СНГ Татьяна Бочарникова: «Наиболее важными свойствами на сегодня считаю возможность выбора сервисов из нескольких облаков, наличие единой системы управления ресурсами нескольких провайдеров и возможность беспроблемной переброски нагрузки между облаками».
И конечно, важная функция мультиклауда – обеспечение отказоустойчивости. В этом случае использование разных облачных провайдеров является обязательным, поскольку ликвидирует единую точку отказа.
В целом же определение мультиклауда (мультиоблака) еще не устоялось. «Мультиклауд – очередной маркетинговый термин в сфере облачных услуг, – уверен директор практики облачных решений AT Consulting Михаил Бараблин. – Значение во многом зависит от желаний продавцов, в каждом отдельном случае оно свое. Тем не менее общий смысл есть».
Оптимистично настроен Дмитрий Хороших, менеджер по развитию бизнеса Cisco: «Ситуация очень похожа на ту, что была 10 лет назад с «просто облаками». Сегодня Cisco рассматривает мультиклауд как систему, которая позволяет один раз задать структуру приложения, определить состав его компонентов, связей между ними, требований к вычислительным ресурсам, сетевой связности и безопасности. А затем единообразно размещать это приложение в частном или публичном облаке, возможно, даже разнести компоненты по разным облакам. При этом все установленные требования должны выполняться и должны осуществляться мониторинг приложения в целом и единое управление его стоимостью. Звучит как фантастика, но на современном уровне развития технологий здесь нет ничего невозможного».