Пиринг для облаков

Распределение дата-центров по территории нашей страны неравномерно. Большая их часть расположена в столице и ее окрестностях. «73% процента стойко-мест находятся в Москве и ближайшем Подмосковье. Еще 13% приходится на Санкт-Петербург», – отметил директор по развитию бизнеса iKS-Consulting Дмитрий Горкавенко на прошедшем в Москве Пиринговом форуме MSK-IX 2019. Эта неравномерность легко объяснима – как правило, точкой входа в облако является московский офис клиента, да и сбыт продукции чаще всего происходит в столице.

В последние годы ситуация стала меняться. Расширился спектр используемых облачных сервисов, появился спрос из регионов, начали предъявляться определенные требования к времени, проходящему между отправкой пакета по сети и окончанием его обработки (RTT, round trip time). Страна большая, а физику не обманешь. Расстояние между Москвой и Владивостоком по магистралям, проложенным вдоль автотрасс, – более 9 тыс. км, так что даже задействовав оптоволоконные каналы, RTT меньше 30 мс получить не удастся. Но это в теории, на практике картина хуже. По данным совместного исследования iKS-Consulting и CDNvideo, при работе с облаком, физически локализованном в Москве, RTT во Владивостоке составит 114 мс, в Хабаровске – 106, Якутске – 111, Чите – 81, Иркутске – 71, Красноярске – 53, Омске – 42 мс.

По оценкам iKS-Consulting, если RTT составляет 20 мс, подавляющее число приложений будет функционировать успешно. При задержке от 20 до 40 мс потребуется тщательное тестирование, но, скорее всего, наиболее востребованные сервисы будут по-прежнему работоспособны. При задержках 40–80 мс можно пользоваться только облачными сервисами бэкапа и хранения данных. Граница зоны в 20 мс на востоке и юге страны проходит по Самаре и Ростову. А дальше Красноярска если что-либо из московских облачных сервисов и работает, то это не масштабируемые решения. 

Имеющейся сетевой инфраструктуры недостаточно, чтобы соответствовать требованиям, заложенным в национальную программу «Цифровая экономика РФ». Необходимо строительство ЦОДов в регионах. По оценкам iKS-Consulting, чтобы для 90% российских пользователей RTT составляло менее 10 мс, нужно построить ЦОДы в 17 городах, менее 15 мс – в 16.

Строить сеть из полутора десятков ЦОДов долго и дорого. Если же пытаться охватить облачными услугами с приемлемым временем отклика лишь половину российских пользователей, то можно с помощью восьми ЦОДов снизить задержку до 17 мс. Наилучший вариант их размещения надо выбирать по дополнительным параметрам. Например, по доступности энергетических мощностей, тарифам, наличию ресурсов, коннективностью с зарубежными ЦОДами. Даже запуск в оптимально выбранных местах всего четырех ЦОДов уменьшает задержку до 23 мс. «Интеграция каналов и дата-центров – вот то, что открывает окно возможностей для внедрения современных цифровых технологий», – резюмировал Дмитрий Горкавенко.

Строительство ЦОДов в регионах коммерческими компаниями должно быть экономически оправдано. «Основные пользователи сосредоточены в Москве. Экономическая целесообразность выхода в регионы пока под большим вопросом», – заявил директор по развитию бизнеса «Яндекс. Облако» Олег Коверзнев. Компания по-прежнему делает ставку на три дата-центра во Владимирской, Рязанской и Московской областях.

Впрочем, запуск «Ростелекомом» ЦОДа в Екатеринбурге показал, что спрос в регионах есть. Уже на момент запуска вся емкость первой очереди дата-центра была зарезервирована заказчиками, причем сам оператор занял только 10% стоек.

Участники дискуссии «Дорога в облака: зачем нужен хороший транспорт», организованной «ИКС-Медиа», указали, что следует обращать внимание не только на минимизацию задержек, но и на надежность связи. Любой скоростной канал может быть случайно перерезан неквалифицированным экскаваторщиком, и компании должны учитывать такие риски. Олег Коверзнев призвал не рассчитывать на показатели надежности ЦОДа, не держать всё в одном дата-центре на одной виртуальной машине, а обеспечивать отказоустойчивость на уровне приложений.

Другой путь – услуги гарантированного подключения к облакам, которые могут предлагаться по сервисной модели с требованиями, зафиксированными в SLA. Такие решения для доступа к наиболее популярным зарубежным облакам уже существуют. «Корпоративный бизнес в основном использует сети MPLS, но сейчас на пятки наступает SD-WAN, и нам в любом случае необходимо обеспечивать хорошую коннективность через публичный интернет к основным облачным платформам и частным облакам», – отметил технический директор российского представительства Vodafone Александр Котов.

Доступ к облакам через публичный интернет может пропасть из-за блокировок Роскомнадзора. В этом случае не поможет резервирование через разных облачных провайдеров. «Если к публичному облаку доступ идет через несколько аплинков, то в случае блокировки все аплинки разрываются и без использования Direct Connect в него попасть нельзя», – пояснил Евгений Морозов, коммерческий директор MSK-IX. 

На RTT влияют не только расстояние до облака, но и топология сети, маршрут транспорта. Для предоставления SLA c хорошими показателями доступности облачного сервиса и RTT оператору следует анализировать задержки на всех маршрутах и физические характеристики трасс.

Важность быстрого и надежного канала до облака возрастает при использовании мультиклаудных технологий. Термин «мультиклауд» эксперты понимают по-разному. Одни – как набор лучших приложений из набора облаков, другие – как интегрированную с несколькими облаками систему заказчика. По мнению Евгения Морозова, «мультиклауд – это когда сервис настолько важен, что распределен по различным облачным сервисам с целью резервирования». «С развитием PaaS облака будут сильно дифференцироваться по функционалу. В одном облаке можно найти один нужный функционал, в другом – другой. А управление сделать в рамках единой технической политики. В этом случае возникает мультиклауд», – считает коммерческий директор NGENIX Константин Анохин. В зависимости от конфигурации системы клиенту понадобятся канал до частного облака (как правило, выделенная линия), каналы до публичных облаков, от частного к публичным, а в перспективе, возможно, и канал между публичными облаками. 

Озабоченность профессионального сообщества вызывает также вопрос о действиях операторов связи в случае установки в каналах технических средств противодействия угрозам в рамках реализации закона о «суверенном интернете». Системы фильтрации трафика (DPI, Deep Packet Inspection) будут находиться под внешним управлением, и непонятно, смогут ли операторы в таких условиях обеспечить выполнение SLA и кто будет отвечать за доступ к облакам.

Закон может отрицательно сказаться и на облачном рынке. Бизнес и так с осторожностью относится к идее размещения в облаке чувствительной информации. При установке в каналах связи систем DPI риски утечек возрастут. Увеличится и RTT – ведь устройствам DPI нужно время на анализ передаваемых данных.

«Часто люди, принимающие решения, не думают о технической реализации. Можно наставить таких ловушек, что никакие облака работать не будут. Будем надеяться, что победят логика и целесообразность», – подвел итог Евгений Морозов.

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!

<< Предыдущая статья   Вернуться к содержанию   Следующая статья >>