Citrix ADC доставляет операционную целостность при помощи единой базы кода на различных форм-факторах: аппаратных устройствах (MPX), виртуальных (VPX), голом железе (BLX) и контейнерах (CPX). Это значит, что все устройства Citrix ADC могут предоставлять одинаковый набор возможностей.
В развивающемся мире связанных сервисов Citrix ADC CPX разворачивается к каждой единице приложения (поду) для обеспечения поддержки. Этот ADC в контейнере должен быть адаптирован для такого масштаба развертывания за счёт оптимизации размера и производительности. Рассмотрим, что сделал Citrix за последнее время для обеспечения возможности хорошей работы ADC в контейнерных окружениях.
Сетка сервисов (Service Mesh) и прокси (Proxy).
В мире микро-сервисов на долю трафика “восток-запад” (East-West) в облачных приложениях приходится большая часть. Так же он имеет аналогичные требования к маршрутизации, наблюдению и безопасности, как и трафик север-юр (North-South) в традиционных ADC. За счёт размещения прокси ближе к микро-сервису сетка сервисов гарантирует, что трафик восток-запад (East-West) может автоматически контролироваться без явных действий со стороны разработчиков микро-сервисов.
При внутреннем развертывании (Sidecar Deployment), один прокси, обычно, разворачивается для каждого пода, чтобы получить сетку сервисов. Каждый прокси требует памяти, потребляет ресурсы процессора, создаёт дополнительную нагрузку в плоскости управления и обеспечивает дополнительную задержку. Так как кластер Kubernetes масштабируется до тысяч подов, накладные расходы увеличиваются. Очень важно для прокси потреблять крохотный объем памяти, при этом предоставляя богатый набор возможностей и поддерживая низкую задержку в рамках требуемых условий.
Прокси в контейнере, Citrix ADC CPX используется в облачных развертываниях, таких как окружения Kubernetes. За счёт оптимизации потребления памяти и поддержки исходной базы кода, Citrix ADC CPX может быть использован как внутренний прокси для развертывания сетки сервисов. За счёт оптимизации памяти, один узел Kubernetes может запускать тысячи сторонних экземпляров CPX, при этом предоставляя исключительно низкую задержку производительности.
Объем потребляемой памяти Citrix ADC CPX.
Использование памяти одного экземпляра CPX включает всю память, к которой процесс может обратиться, в том числе память подкачки, память которая выделена, но не используется, и память от общих библиотек. Обычно это называется размер виртуального набора (Virtual Set Size, VSS).
Чем больше экземпляров CPX порождается, тем больше памяти используется всеми экземплярами. Чтобы получить актуальное потребление памяти экземпляром CPX в Citrix провели эксперимент: развернули очень большое число экземпляров CPX на одном узле, поддерживая стабильность системы. При отключённой подкачке (Swapping), память, выделяемая на экземпляры, рассчитывалась по формуле: общее использование памяти узлом разделенное на общее число экземпляров прокси.
Так как Citrix ADC имеет единую базу кода на для всех форм факторов, сокращение потребления памяти Citrix ADC CPX – это отдельная инженерная задача. Перезагрузки Citrix ADC (MPX/VPX) обычно происходят раз в несколько месяцев. Они обслуживают множество гигабит ежесекундно и поддерживают высокую пропускную способность. Эти устройства также нуждаются в широком разнообразии управляющих интерфейсов – REST API, SNMP, SSH и прочих. Для удовлетворения этих потребностей выделяется некоторый объем памяти и используется множество управляющих демонов.
Но при развертывании под управлением API прокси разворачивается не на долго и редко превышает пропускную способность в несколько Mbps. Следовательно, оптимизация выполняется с учётом этих требований:
- Отложенное выделение памяти, опирающееся на включение определенных компонентов, таких как внутреннее развёртывание, не требует всех возможностей.
- Масштабирование хэш-таблиц и буферов, выделенных во время запуска специально для ожидаемой нагрузки.
- Сокращение расходов во время запуска, не обязательных для окружения микро-сервисов.
- Устранение демонов, не нужных в окружении микро-сервисов.
- Смена статического выделения на динамическое, сокращение части BSS в сегменте данных процесса CPX.
Создание экземпляра CPX в режиме оптимизированной памяти (Memory Optimized Mode).
Развертывание лёгкого режима CPX (Light Mode) не отличается от обычного CPX. Указание дополнительного параметра окружения NS_CPX_LITE=1 позволит развернуть более лёгкую версию CPX.
docker run ‒ dt -P –privileged=true -e NS_CPX_LITE=1 ОБРАЗ:ТЕГ
Подробнее познакомиться с созданием экземпляров ADC CPX можно в документации по продукту.
Развертывание Citrix ADC CPX.
Режим оптимизированной памяти Citrix ADC CPX, подходит в следующих сценариях:
- Развертывание на входе (Ingress Deployment): Citrix ADC CPX может быть настроен в качестве балансировщика нагрузки сервисов Kubernetes. Он будет использоваться для балансировки траффика “Север-Юг” (North-South) для сервисов Kubernetes, отправляемого клиентами из-за пределов кластера Kubernetes.
- Внутреннее развертывание (Sidecar Deployment): Каждый под содержит Citrix ADC CPX, в качестве стороннего устройства, которое может принимать весь входящий и исходящий трафик для приложения, запущенного в поде. CPX может изолировать основное приложение от всех вспомогательных задач, выступая в качестве внутреннего устройства.
Citrix ADC CPX спроектирован таким образом, чтобы быть многогранным прокси. Клиенты могут использовать одинаковый набор возможностей в центре обработки данных (ЦОД), сетке сервисов и в облаке, полагаясь на единую основу кода, сформированную двумя десятилетиями применения в самых инновационных компаниях мира.
Дополнительную информацию о Citrix ADC CPX можно получить на странице Citrix в Github.
Комментариев нет:
Отправить комментарий