Александр Серебряков, системный инженер, F5 Networks
Согласованное последовательное применение сервисов – сервисных цепочек – позволяет сети развиваться и принимать активное участие в бизнес-процессах.
Между тем сам термин «сервисные цепочки» (Service chaining) еще не получил широкого распространения в ИТ-сообществе. Сегодня он рассматривается как технический механизм для направления пакетов, потоков или сообщений (в зависимости от того, какой сегмент сетевого стека рассматривается) в рамках сети.
Технология сцепления сервисов является ответом на вопрос, как организовать потоки данных в условиях различия подходов к L2-3 и L4-7. На данный момент уже реализовано множество различных подобных решений.
В одних используются преимущества оверлейных протоколов VXLAN и NVGRE, в других – специализированные нестандартизованные теги. Отдельные решения работают на прикладном уровне и задействуют встроенные в HTTP функции перенаправления для перевода данных из одного сервиса в другой.
И здесь важен не столько механизм работы данного решения (в Рабочей группе по инженерным проблемам Интернета IETF уже существует множество эскизных предложений), сколько понимание: то, что мы пытаемся сделать, – это попытка организовать бизнес-процесс в рамках возможностей приложения и сетевых сервисов.
Важность «цепочки сервисов» для операторов связи
SDN и NFV не смогли разрушить мнение о том, что сеть представляет собой просто магистраль, а сервисы, размещаемые в ней, – всего лишь возможность передавать пакеты данных тем или иным образом. Для многих понятие «сетевые сервисы» ассоциируется с VLAN, QoS-политиками или ограничениями полосы пропускания. Даже сервисы более высокого порядка, включая балансировку нагрузки и ускорение приложений, рассматриваются не как сервисы, а как дискретные сетевые функции. Таким образом, непонятно, что собой представляет сервис в контексте инфраструктуры и новых технологий, таких как SDN, облачные среды и NFV, а это, в свою очередь, размывает их ценность для бизнес-процесса.
Операторы связи более близки к пониманию того, что технологии, в том числе создание сервисных цепочек, имеют такое же отношение к организации бизнес-процесса, как и к направлению трафика в сети. Давайте рассмотрим более привычные «сервисы с добавленной стоимостью» (VAS), которые предлагаются операторами для абонентов.
Мы знаем, что эти сервисы применяются только в том случае, когда они нужны подписчику. Если я не подписался на сервис «родительский контроль», мои данные не должны тратить ресурсы, связанные с предоставлением такой услуги. И это справедливо для всех VAS на сети оператора: зря потраченные на обработку трафика ресурсы – это зря потраченные деньги.
Поэтому операторы должны иметь возможность определить нужную им «цепочку сервисов», через которую трафик определенного абонента будет передаваться в зависимости от того, являются ли он заказчиком данного сервиса, т. е. приносит ли это дополнительный доход. Таким образом, определение цепочек сервисов становится не только техническим решением, но и бизнес-задачей и должно управляться бизнес-процессами.
Организация сетевых и прикладных сервисов
На предприятиях имеются сервисы, которые аналогичны тем, что предоставляют операторы связи, но должны организовываться в рамках более крупного процесса. По мере того как приложения разделяются на микросервисы и прикладные интерфейсы API, необходимость в организации потоков приложений в рамках сервисов становится главенствующей. И здесь дело не только в приложениях, но и в прикладных и сетевых службах, которые являются частью потоков данных для приложений, а значит, и частью производственных процессов.
Существует множество служб, которые находятся в сети и прикладной инфраструктуре, являющихся частью более крупных задач. Не для каждого запроса пользователя требуется аутентификация и не для каждого ответа или запроса – проверка системой защиты от фальсификации.
Только производственная необходимость – бизнес-процесс – определяет необходимость в оценке, анализе или последующей обработке входящего и исходящего трафика, как в центрах обработки данных, так и в сетях операторов. Возможность организовывать работу сетевых и прикладных сервисов, руководствуясь производственными потребностями, – это то, что предлагают нам новые технологии, такие как SDN и NFV.
Мы можем называть это гибкостью или оперативностью, но реальность заключается в том, что технологии, которые обеспечивают возможность организации сервисов и их последовательностей, делают это с целью реализовать бизнес-процесс независимо от того, касается это сетевого или прикладного уровня инфраструктуры.
Таким образом, создание сервисных цепочек может быть критической и основополагающей технологией, отвечающей на вопрос, как мы будем управлять сетью для поддержки бизнес-процессов, определяющих результат деятельности всей организации.
Сервисные цепочки – это способ управления бизнес-процессами в сети. Организации, которые смогут понять суть данной технологии сегодня, получат значительные конкурентные преимущества.
Сервисные цепочки и непредвиденные результаты
При реализации сервисных цепочек возможны и непредвиденные последствия, которые заключаются в том, что изменения могут оказать воздействие на производительность работы, в частности, когда сцепления включают в себя несколько провайдеров. Рассмотрим реальный пример организации цепочек сервисов, которая создает определенные трудности для технологии SSL в плане производительности.
Как известно, установление безопасной связи по протоколу SSL обусловливает появление задержек. Это происходит в связи с тем, что помимо выполнения функций шифрования, занимающих много времени, требуются дополнительные соединения между клиентом (браузером) и сервером (или промежуточным сетевым прокси, например, балансировщиком, или ADC) для обмена информацией, необходимой для шифровки и расшифровки последующих коммуникаций.
Но это еще не все. Сертификат серверного устройства может вызывать подозрения, и это связано с большим количеством инцидентов, когда фальшивые сертификаты использовались для сайта в целях обмана пользователя. Одновременно продолжает развиваться SSL Everywhere, и браузеры тщательно проверяют сертификаты, запрашивая у респондера, работающего по протоколу OCSP (Online Certificate Status Protocol), информацию о статусе сертификата (это является предпочтительным решением по сравнению с использованием CRL (Certificate Revocation Lists) для устранения недоработок данной технологии). То есть во время установления связи SSL клиент отправляет запрос OCSP респондеру, что представляет собой дополнительный сервис в данной цепочке, который увеличивает общую задержку, поэтому процесс должен выполняться максимально быстро.
Итак, браузер направляет запрос респондеру. Эта операция выполняется путем выбора респондера из списка элементов, поддерживающих сервер сертификатов CA (Certificate Authority), который отправил сертификат. Реальное количество глобальных CA для SSL небольшое. Таким образом, высока вероятность того, что респондер имеет достаточно большие размеры и, скорее всего, получает миллиарды запросов ежедневно со всего мира. Это звено цепочки существенно снижает общую скорость работы приложения для конечного пользователя. При работе с мобильными пользователями стоит обратить внимание на влияние мобильных сетей и ограниченные функциональные возможности устройств, как это было описано американским разработчиком ПО из Силиконовой Долины Майком Белшем, принявшим участие в разработке протокола SPDY («speedy»). Так как этот процесс достаточно дорогостоящий, особенно в отношении мобильных сетей, он провел быструю оценку его собственного сервиса по сетям 3G:
- DNS (1334 мс);
- установление связи TCP (240 мс);
- установление связи SSL (376 мс);
- отслеживание цепочки сертификатов (1011 мс);
- DNS в CA (300 мс);
- TCP в CA (407 мс);
- OCSP в CA № 1 (598 мс) – StartSSL CA использует отдельное соединение для каждого;
- TCP в CA № 2 (317 мс);
- OCSP в CA № 2 (444 мс);
- завершение установки связи SSL (1270 мс).
Выделенные части транзакции относятся к процессу проверки сертификата, который выполняет браузер в качестве меры предосторожности. В случае с немобильной сетью можно было бы ожидать повышения скорости работы, однако влияние «обычных» браузеров тоже не стоит недооценивать. В прошлом году известный криптограф Адам Лэнгли (Adam Langley) обратил внимание на эту проблему и предложил отключить проверку OSCP в Chrome:
«Среднее время успешной проверки OCSP составляет примерно 300 мс, а ее среднее значение составляет почти секунду. Это задерживает загрузку страницы и заставляет сайты отказаться от использования HTTPS. Кроме того, существуют проблемы, связанные с конфиденциальностью, так как CA узнает IP-адреса пользователей и сайты, которые они посещают. Поэтому мы планируем отключить онлайн-проверки в будущих версиях Chrome».
Обнаружить и предотвратить
Создание сервисных цепочек в других условиях, например в сетях ЦОД, не будет связано с таким уровнем задержки только потому, что мы говорим о более высоких скоростях LAN. Тем не менее реальное воздействие сцепления сервисов, особенно когда такие цепочки включают большие наборы сервисов, не должно игнорироваться или недооцениваться. Подобные цепочки создают дополнительные задержки, часто в виде ненужных, повторяющихся функций. Мониторинг нагрузки и использования ресурсов, а также масштабирование отдельных сервисов – важные условия для достижения успеха в любой архитектуре, в которой применяются подобные стратегии.
Технологии, включая SDN и облачные решения, предлагают меры коррекции в случае нарушения, но необходимо обратить внимание на то, что подобные исправления являются реакциями на нарушения. Это означает, что работа как минимум одного пользователя нарушается до того, как будут приняты корректирующие меры. В некоторых случаях нарушение останется незамеченным, но основная проблема заключается в том, что это нарушение могло быть обнаружено.
