Архитектура Full-Proxy ЦОД

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

Платформа Full-Proxy

Различие систем прокси и Full-Proxy проявляется в способе обработки устройством сетевых соединений. Все прокси располагаются между двумя объектами — в эпоху Интернета это почти всегда клиент и сервер — и играют роль посредника в соединении. Все системы Full-Proxy являются прокси-устройствами, а вот обратное не всегда верно. Не все прокси являются Full-Proxy-системами, и эту особенность необходимо учитывать, принимая решения, которые могут повлиять на архитектуру ЦОД.

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

Устройство Full-Proxy с раздельной обработкой соединения на каждой из сторон «зазора» способно справиться с этими проблемами. Прокси-система может формально быть и Full-Proxy, но обычно просто использует метод buffer-and-stitch для управления соединением и не может эффективно решить указанные проблемы. Типичный прокси осуществляет буферизацию соединения в начале TCP-сессии и иногда при передаче нескольких первых пакетов с данными приложения, а затем закрепляет соединение в таблице сессии, пусть и с использованием данных прикладного уровня. В этом случае, соединение будет представлять собой единый сквозной поток данных и прокси придется выбирать, какие характеристики (клиентские или серверные) к нему применить, так как одновременно оптимизировать и те и другие не удастся.

Другое преимущество архитектуры Full-Proxy состоит в том, что она способна реализовать больше возможностей по обработке передаваемых данных с помощью различных функциональных подсистем. Благодаря своему способу установки соединения Full-Proxy может направить на обработку той или иной функциональной подсистемой только характерные для нее данные. Каждая подсистема, в свою очередь, предпринимает специальные действия для анализа, обработки или модификации данных и отправляет их дальше. Это позволяет инспектировать SSL-соединения, применять прикладные политики безопасности, предоставлять сервисы с заданным уровнем производительности отдельным клиентам или приложениям и одновременно обеспечивать наилучший уровень производительности за счет экономии ресурсов системы.

Такие возможности все более широко используются в архитектуре ЦОД для реализации уровня доставки приложений, на котором проблемы эксплуатационных рисков могут быть решены за счет принудительного применения различных политик. Фактически, F5 Networks создала архитектуру Full-Proxy ЦОД, в которой уровень доставки приложений является посредником между клиентами и приложениями, осуществляя полное разделение их взаимодействия.

Архитектура Full-Proxy-ЦОД

Архитектура Full-Proxy ЦОД создает коммутационный «зазор» между пользователями и приложениями, играя роль агрегации (и, наоборот, разделения) для сервисов. Поскольку сегодня все коммуникации сосредоточены в виртуализованных приложениях и сервисах на уровне доставки приложений, последний служит стратегической точкой управления, на нем можно реализовать политики доставки для снижения эксплуатационных рисков (производительности, доступности, безопасности).

Преимущество архитектуры Full-Proxy ЦОД заключается в изоляции конечных пользователей от неустойчивости нагрузки, свойственной виртуализованным и динамичным облачным средам. Это позволяет создавать решения, предназначенные для преодоления ограничений технологии виртуализации, подобных ограничениям POD-архитектуры в средах VMware View. Традиционно, технологии управления доступом оперируют именами хостов и IP-адресами для определения объектов доступа. В виртуализованных или облачных средах это ограничение может грозить катастрофическими последствиями для производительности или даже работоспособности сервиса. Реализация управления доступом на уровне доставки приложений — на устройстве класса Full-Proxy — позволяет устранить эту неустойчивость путем виртуализации ресурсов. При этом контроллер доставки приложения берет на себя такие детали, как знание IP-адресов и VLAN, а само решение определяет, разрешено ли данному пользователю или данному устройству получать доступ к определенному сервису.

По существу, F5 Networks просто расширила концепцию Full-Proxy на всю архитектуру. Введение уровня доставки приложений делает ее более адаптируемой, гибкой, способной реагировать на быстрые изменения, с которыми приходится сталкиваться современным ИТ-подразделениям.

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

Программно-определяемые сервисы приложений

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

Вопрос о том, что делать с сервисами 4–7-го уровня с учетом развития SDN-подхода, обсуждался очень активно, на эту тему было сказано много, но до F5 Networks никто не предложил решения, которое бы интегрировалось как с приложениями (оркестровка облачных вычислений и виртуализации), так и с инструментами для оркестровки сети. F5 Synthesis применяет принципы SDN к сетям сервисов, абстрагируя сетевые ресурсы приложения для его доставки на уровне, находящемся между сетевым уровнем и уровнем самих сервисов. Такое решение позволяет реализовать программно-определяемые сервисы приложений SDAS (Software Defined Application Services).

SDAS представляет собой результат доставки сервисов приложений из унифицированного высокопроизводительного набора сервисов (service fabric), оркестровка которой выполняется решением BIG-IQ. Главная идея заключается в использовании преимуществ ресурсов, объединенных в пулы физических, виртуальных и облачных платформ F5 Networks в любых их сочетаниях. Ресурсы будут выделяться именно сервисам, а не отдельным устройствам, появится возможность реализовывать достоинства подхода Full-Proxy компании F5 Networks. Гибкие сервисы SDAS имеют программные интерфейсы не только на уровнях управления (iControl, REST API) и плоскости передачи данных (iRules, node.js, Groovy), но и на конфигурационном (iCall и iApps), что позволяет изменять их настройки в режиме реального времени на основе событий.

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

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365