Интернет можно представить в виде океана, а потоки трафика — уподобить океанским течениям. Для того чтобы управлять такими потоками, а также формализовать обмен трафиком и взаимодействие интернет-провайдеров, в конце 1980-х годов был разработан верхнеуровневый протокол междоменной маршрутизации Border Gateway Protocol (BGP), ставший основой современной Сети и позволяющий владельцам автономных систем (узлов сети) обмениваться информацией о маршрутах движения трафика (стандарт RFC 1105). Иногда его также называют Money Vector Protocol, поскольку у BGP есть индикаторы, отражающие денежные отношения сторон, провайдеров связи, при использовании протокола для передачи трафика.

Помимо регулирования взаимодействия между операторами связи, BGP играет сегодня ключевую роль при построении облаков и обеспечении их отказоустойчивости. Согласно формулировке Национального института стандартов и технологий США (NIST), облака — это модель обеспечения повсеместного и удобного сетевого доступа к вычислительным ресурсам, обладающая свойством мгновенной эластичности (rapid provisioning). Иначе говоря, в случае необходимости вычислительные ресурсы (сети, серверы, системы хранения, приложения) оперативно предоставляются пользователю и так же быстро возвращаются обратно в общий доступ.

На волне «облачного» ажиотажа в начале 2010-х годов было построено немало облачных систем с мгновенной эластичностью, причем утверждалось, что облака предоставят автоматическую отказоустойчивость, масштабируемость, безопасность и «безоблачную жизнь» для приложений. На самом деле это не так: если приложение загрузить в ЦОД, то далеко не всегда можно говорить о его высокой отказоустойчивости и масштабируемости. В итоге возникла классическая ситуация — стадия неоправданных ожиданий, когда технологии Cloud Computing переползли на кривой Gartner пик чрезмерных ожиданий и скатились в «яму разочарований».

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

К геораспределенному облаку предъявляются два дополнительных требования: устойчивость к неблагоприятным внешним воздействиям наподобие DDoS-атак и выносливость, то есть способность продолжительное время выдерживать недружественные воздействия. Оба напрямую влияют на надежность облака в целом, которая может быть нарушена не только по внутренним причинам (скажем, отключение сервера провайдера), но и вследствие внешних факторов (атаки на ЦОД), которые гораздо опаснее, так как их невозможно контролировать.

Ясно, что без геораспределенности облачного решения ни о какой устойчивости, выносливости и отказоустойчивости речи быть не может. Например, сети фильтрации трафика без геораспределенности не выживают, в противном случае компаниям пришлось бы платить за трансатлантические стыки при прохождении трафика, что сразу сделает бизнес невыгодным. Два ведущих сегодня многофункциональных облака, Amazon Web Services и Microsoft Azure, по-разному решили задачу построения геораспределенной конфигурации.

В Amazon для геобалансировки использовали функциональность системных доменных имен (Domain Name System, DNS), что просто и быстро при реализации. Однако у DNS имеется множество недостатков (см. рисунок) — в ее работе всегда присутствует «третья сторона» (resolver), набор процедур из библиотеки, предоставляющий доступ к системе доменных имен. Как правило, этот набор контролируется интернет-провайдером — весь фактический трафик и «правила поведения» задаются третьими лицами, которые неподконтрольны ни клиенту, ни серверу. Кроме того, вместо фактической топологии сети используется ее отображение, в котором теряется детализация, а картина слишком упрощена. Сложная топология сетевой связности проецируется на простой набор «IP-адрес — регион»; точность данных снижается. Помимо всего прочего, DNS тоже надо уметь геораспределенно масштабировать, а для этого придется опять вернуться к протоколу BGP и строить сеть BGP anycast, маршрут к которой анонсируется одновременно из нескольких точек. В конце концов протоколом взаимодействия автономных систем между собой является именно BGP.

Иллюстрация локализации трафика с использованием механизма GeoDNS. Явно видна неконсистентная локализация трафика в макрорегионах, особенно на «пересечении» Европы и США. По замыслу провайдера, пользователь из конкретного макрорегиона не должен направляться на сервер из другого региона, однако видно, что для некоторых точек в Европе выдается североамериканский IP-адрес, следовательно, трафик от них будет идти из Европы в США, что пользователю добавит задержку до 100 мс, а провайдеру — дополнительные издержки. Разные цвета соответствуют разным регионам
Иллюстрация локализации трафика с использованием механизма GeoDNS. Явно видна неконсистентная локализация трафика в макрорегионах, особенно на «пересечении» Европы и США. По замыслу провайдера, пользователь из конкретного макрорегиона не должен направляться на сервер из другого региона, однако видно, что для некоторых точек в Европе выдается североамериканский IP-адрес, следовательно, трафик от них будет идти из Европы в США, что пользователю добавит задержку до 100 мс, а провайдеру — дополнительные издержки. Разные цвета соответствуют разным регионам

 

А в облаке Microsoft Azure изначально было принято решение о работе на базе сети BGP anycast. Плюс у такой реализации один — BGP работает без сбоев. Однако любая компания, которая строит облако BGP anycast, должна выполнить ряд технологических условий, и первое из них — локализация трафика. Топология и география Сети — понятия, между собой связанные, но эта связь часто неочевидна. Например, возможна ситуация, когда два взаимодействующих пользователя находятся в Новосибирске в соседних зданиях, но при этом обмен пакетами трафика осуществляется через Москву, поскольку экономические взаимоотношения операторов связи диктуют именно такую политику. И все бы ничего, но нельзя забывать про скорость передачи трафика и задержки, поэтому при построении сети BGP anycast очень важно сделать так, чтобы трафик не покидал домашнего региона.

Таким образом, для построения отказоустойчивого облака обязательно моделирование Сети на уровне BGP, и любая компания, перед которой стоит задача построения геораспределенной сети, обязательно столкнется с этой задачей.

На рынке имеются различные коммерчески доступные или закрытые решения по моделированию: Oracle Dyn (решение компании Renesys, купленное компанией Dyn, а впоследствии Oracle); Cisco Security Everywhere (решение BGPmon, приобретенное компанией OpenDNS, в дальнейшем ставшей частью Cisco); Microsoft Hurricane Electric — продукт для собственных нужд компании. Для планирования размещения точек присутствия облака компания Qrator предложила модель Сети на базе открытой и общедоступной разработки Qrator.Radar [1], призванной повысить эффективность эксплуатации и проектирования сетей поддержки облаков. Qrator.Radar анализирует отношения действующих в Интернете автономных систем с использованием методов математического моделирования и позволяет спланировать нагрузки при внешних воздействиях, таких как DDoS-атаки.

Однако одного лишь моделирования недостаточно — имеется еще проблема безопасности самого протокола BGP. Используя недоработки протокола BGP, злоумышленники могут перехватывать трафик, проводить атаки типа man-in-the-middle (когда злоумышленник перехватывает и подменяет сообщения, которыми обмениваются корреспонденты, причем ни один из них не догадывается о присутствии постороннего в канале), блокировать доступ к неугодному ресурсу, например путем DDoS-атаки. Более того, чем больше облако, тем больше площадь его поражения и тем выше риски провайдера получить проблемы с безопасностью.

Эффективных решений для обеспечения безопасности BGP пока нет, хотя и разработан стандарт BGPSec, представляющий собой расширение протокола BGP и регламентирующий процессы авторизации списка автономных систем, передаваемых в сообщениях об обновлении маршрута, но и он не решает всех проблем с безопасностью протокола. В рамках Internet Engineering Task Force компания Qrator Labs также вносит свой вклад в развитие стандартов сети, предложив на рассмотрение IETF инициативу по обнаружению и устранению «утечек маршрутов» BGP. Пока же можно лишь вручную выявлять проблемы и устранять их административными методами, используя мониторинг BGP-аномалий для получения уведомлений об инцидентах, потенциально связанных с атаками или попытками перехвата трафика.

***

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

Литература

  1. Алексей Семеняка. Интеллектуальная защита ресурсов цифрового бизнеса // Открытые системы.СУБД. — 2016. — № 2. — С. 25–27. URL: https://www.osp.ru/os/2016/02/13049286/ (дата обращения: 05.12.2017).

Александр Лямин (la@qrator.net) — генеральный директор, Qrator Labs (Москва).