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

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

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

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

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

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

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

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

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

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

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

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