Обзор

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

Zevenet архитектура

Zevenet управляет процессами как из пользовательского пространства, так и из пространства ядра, позволяя получать наибольшую производительность, но с максимальной гибкостью, а также выполнять все задачи, делегированные контроллеру доставки приложений, такие как балансировка нагрузки, безопасность и высокая доступность.

Диаграмма ниже дает общее представление о различных компонентах, которые составляют систему Zevenet внутри. Дополнительные части менее важного были упущены, чтобы предложить более простое и ясное представление.

В следующих разделах будут описаны различные части и как они взаимосвязаны.

Балансировщик нагрузки Zevenet в пространстве пользователя

Подсистемы, используемые в пространстве пользователя:

Веб-интерфейс: веб-графический пользовательский интерфейс, используемый пользователями для управления настройкой и администрированием всей системы; он управляется веб-сервером HTTPS, который использует API Zevenet для всех действий, выполняемых для балансировщика нагрузки.

Зевенет API: или программный интерфейс Zevenet Application, разработанный в соответствии с ОТДЫХ и JSON интерфейсы, используемые через HTTPS, он используется другими пользовательскими интерфейсами с точки зрения пользователя, такими как веб-интерфейс интерфейс или ZCLI (Интерфейс командной строки Zevenet). Этот инструмент проверяет любые действия против подсистемы RBAC, и если это разрешено, действие выполняется в Zevenet Appliance. API может подключаться и управлять любой другой подсистемой пользовательского пространства, описанной на схеме.

RBAC: Управление доступом на основе ролей - это механизм доступа и управления, определенный для пользователей, групп и ролей. Этот модуль определяет, какие действия пользователь может выполнять с высоким уровнем конфигурации между группами, пользователями и ролями. Он полностью интегрирован в веб-интерфейс GUI, который позволяет загружать веб-представления в зависимости от роли пользователя. Кроме того, эта подсистема потребляется через API (Программный интерфейс приложения) или любой другой инструмент, который использует API (Программный интерфейс приложения).

LSLB - HTTP (S): Модуль LSLB (Local Service Load Balancer), состоящий из профиля HTTP (S), выполняется в пространстве пользователя обратным прокси-сервером Zproxy, который способен очень эффективно управлять приложениями с высокой пропускной способностью. Эта подсистема настраивается API и может быть защищена подсистемой IPDS (с использованием черных списков, правил DoS, наборов правил RBL и WAF).

ГСЛБ: Модуль GSLB (Global Service Load Balancer), реализованный с экземпляром профиля GSLB, выполняется в пространстве пользователя процессом DNS-сервера Gdnsd, который может работать как расширенный DNS-сервер имен с функциями балансировки нагрузки. Эта подсистема настраивается с помощью API и может быть защищена подсистемой IPDS (с использованием черных списков, DoS и RBL).

Проверка здоровья: Эта подсистема настраивается API и используется всеми модулями балансировки нагрузки (LSLB, GSLB и DSLB) для проверки работоспособности бэкэндов. Простые и расширенные проверки выполняются с бэкэндом, а затем, если проверка не проходит, бэкэнд для данной фермы помечается как неработающий, и больше не пересылается трафик, пока проверка снова не сработает с бэкэндом. За эти проверки отвечает Farm Guardian, и он разработан с высоким уровнем гибкости и настраиваемости.

Файловая система конфигурации: Этот каталог используется для сохранения конфигурации, любые изменения в этом каталоге будут реплицироваться в кластер, если такая служба включена.

Nftlb: Этот процесс в пользовательском пространстве управляется подсистемой API и используется для двух основных целей: LSLB - L4XNAT управление и настройка IPDS модуль подсистемы.

Балансировщик нагрузки Zevenet в пространстве ядра

Подсистемы, используемые в Kernel Space:

Система сетевого фильтра LSLB L4xNAT: Подсистема Netfilter используется Nftlb для балансировки нагрузки. Правила Netfilter загружаются в ядро ​​этим процессом Nftlb, чтобы создать высокопроизводительный балансировщик нагрузки L4, Nftlb загружает правила балансировки нагрузки в ядре эффективным способом для оптимального управления пакетами трафика. Кроме того, Nftlb загрузит правила Netfilter для предотвращения и защиты от вторжений (BlackLists, RBL и DoS).

Черные списки IPDS: Эта подсистема интегрирована в систему Netfilter и управляется Nftlb. Он состоит из группы правил, настроенных до правил балансировки нагрузки для сбросить соединения для заданных исходных IP-адресов, Внутренне он создает набор правил, упорядоченных по категориям, странам, типам злоумышленников и т. Д., И обновляется ежедневно.

IPDS RBL: Аналогично предыдущей, эта подсистема также интегрирована в Netfilter и управляется Nftlb. Исходный IP-адрес фиксируется до установления соединения, а клиентский IP-адрес проверяется на соответствие внешний DNS-сервис, Если IP-адрес разрешен, он помечается как вредоносный, и соединение будет разорвано.

IPDS DoS: Та же система конфигурации, что и у двух предыдущих модулей, интегрированная в Netfilter и управляемая Nftlb. Это набор правил, настроенных перед правилами балансировки нагрузки, которые проверяют, являются ли пакеты частью Атака отказа в обслуживании, Некоторые правила применяются к потоку пакетов, чтобы перехватить атаку до того, как это будет сделано.

Система отслеживания соединений: Эта система используется подсистемой Netfilter для управления соединениями, трансляции сети и для модуль статистики, А также проверка здоровья подсистема для принудительного подключения действий в момент обнаружения проблемы в бэкэнде. Система отслеживания соединений также используется Кластерная служба чтобы перенаправить состояние соединения на второй узел кластера, в случае сбоя главного узла кластера второй узел может управлять трафиком в том же состоянии соединения, что и предыдущий ведущий.

Система маршрутизации и DSLB: Эти подсистемы управляются API и настраиваются в пространстве ядра. Подсистема маршрутизации построена с iproute2 что позволяет нам управлять несколькими таблицами маршрутизации в порядке чтобы избежать сохранения сложного набора правил для статической маршрутизацииКроме того, благодаря iproute2 создан модуль DSLB (Datalink Service Load Balancer) для обеспечения балансировка нагрузки восходящих линий с несколькими шлюзами.

На момент написания этой статьи Zevenet 6 находится в разработке, поэтому эти подсистемы могут развиваться в будущих версиях, предлагая более высокую производительность или больше функций.

Дополнительная документация

Тесты Zevenet zproxy, профиль LSLB-HTT (S)
Тесты Zevenet nftlb, LSLB - профиль L4xNAT