Запросить демо
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Дополнительные услуги
Оставить заявку
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Узнать стоимость
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Дополнительные услуги
Попробовать бесплатно
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Дополнительные услуги
Знать мнение экспертов

Мультиоблачная инфраструктура в России: плюсы и минусы типовых сценариев использования

01.06.2018 0 минут 567

Максим Березин

Директор по развитию бизнеса

Термин «мультиоблачность» возник совсем недавно, и до сих пор среди участников рынка нет единого понимания, какие именно формы потребления вычислительных ресурсов могут попасть в категорию мультиоблачных.

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

Таким образом, «мультиоблачность» — это всего лишь маркетинговая оболочка для привычного явления, и не более того.

Примечательно, что ни в России, ни в мире нет тренда на мультиоблачность. Мы в своей практике редко сталкивались с потребностью бок о бок работать с другим провайдером ради достижения какой-то конкретной цели заказчика. На Западе, по данным аналитиков, компании также предпочитают выбирать одного подрядчика. В частности, IDC говорит, что только 9% компаний готовы использовать услуги разных облачных провайдеров, а 34% европейских организаций не планируют в ближайший год мигрировать свои сервисы в новые облака.

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

Миф 1: о снижении цены на услуги

Один из доводов апологетов мультиоблачности — возможность гибко управлять стоимостью размещения данных и сервисов в облаке, заставляя поставщиков конкурировать друг с другом. Такое действительно возможно, но идет ли демпинг игроков на пользу заказчику? Мы сознательно не участвуем в конкурсах, где конечная стоимость услуг ниже нашей себестоимости, так как принципы работы КРОК не позволяют предоставлять сервис с низким качеством. Однако можем предположить, что так действуют не все поставщики облачных услуг. Увлекаясь гонкой за контракт, они неизбежно ищут возможные способы для уменьшения своих внутренних издержек. Такими способами могут стать использование старого, самортизированного и менее производительного оборудования, а также медленная реакция техподдержки на обращения ночью, в выходные и праздничные дни ввиду отсутствия нужного персонала. Кроме того, не секрет, что у компаний, оказывающих облачные услуги, работают инженеры с разными ставками. При заходе в проект с заведомо невыгодными условиями компании вынуждены привлекать менее квалифицированных сотрудников, которые, естественно, со своими задачами будут справляться хуже. Если заказчик стремится выбрать наиболее дешевые предложения из существующих, он должен помнить о классическом проектном треугольнике, включающим «качество», «сроки» и «стоимость». При низкой цене не бывает профессионального сервиса, либо же сроки реализации проекта будут неудовлетворительными. На подобные риски при выборе поставщиков заказчикам всегда нужно обращать пристальное внимание.

Миф 2: о повышении отказоустойчивости и надежности

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


Рассмотрим типовые случаи, когда резервирование просто необходимо. Золотым правилом, или т.н. best practice, является создание резервных ЦОД для mission и business critical систем. К первым относятся такие системы, простой которых в течение очень короткого времени (допустим, 10 минут или полчаса) может привести к потери бизнеса. Это может быть, например, сервис отчетности, которым пользуются финансовые организации. Если по каким-либо причинам он недоступен, статистические данные не выгружаются и не предоставляются Центробанку в оговоренное время, и финансовая структура может лишиться лицензии. К системам business critical относятся сервисы, для которых допустим более длительный простой — в течение нескольких часов. Сверх этого времени неработоспособность бизнес-приложений чревата штрафами и потерей деловой репутации. Наконец, есть сервисы, которые для бизнеса некритичны, их потеря не повлечет сильных негативных последствий. Но чтобы бизнес работал как часы и был максимально эффективен, такие сервисы и данные также необходимо застраховать, воспользовавшись услугой резервного копирования.


Собственно, и сервисы уровня mission и business critical, и некритичные приложения заказчики часто резервируют на базе облака КРОК. При этом мы рекомендуем для mission critical систем организовать работу двух наших облачных площадок по схеме active-active, когда каждая из них работает в боевом режиме. А для business critical процессов выбрать active-passive схему, при которой происходит менее скоростное переключение. Это позволяет снизить затраты на создание катастрофоустойчивой инфраструктуры с учетом критичности данных.


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

Миф 3: об использовании всех преимуществ аутсорсинга

Работа с одним провайдером подразумевает единую точку ответственности за все процессы, происходящие в инфраструктуре. Дополнительно к этому поставщику облачных услуг также можно передать целиком в режиме managed services (управляемые сервисы) такие задачи, как администрирование оборудования, сетей в облаке и на периметре, резервное копирование данные и даже обеспечение высокой доступности и катастрофоустойчивости. В результате заказчик снимает с себя всю рутину по обслуживанию аппаратной части инфраструктуры, может сконцентрироваться на более важных бизнес-задачах, снизить потребность в квалифицированных администраторах либо же переориентировать их на другие внутренние проекты. Иными словами, воспользоваться всеми неоспоримыми плюсами аутсорсинговых услуг.


Что же происходит, если заказчик начинает работать с несколькими облачными провайдерами?

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


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


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

Миф 4: о простоте миграции в облако

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

Сервисы упоминаемые в статье

  1. Публичное облако КРОК

Не пропустите самые важные, интересные и полезные статьи недели

Ваш e-mail успешно подписан.

Смотрите также