LED
|
Значение
|
?
|
Подключено
|
?
|
Не контролируется
|
?
|
Слив
|
?
|
Offline
|
?
|
В режиме ожидания
|
?
|
Не подключено
|
?
|
Состояние выводов
|
?
|
Не лицензировано или превышено количество лицензированных серверов Real Servers
|
Вариант
|
Описание
|
Онлайн
|
Все Real Servers, назначенные Online, будут получать трафик в соответствии с политикой балансировки нагрузки, установленной на вкладке Basic.
|
Дренаж
|
Все реальные серверы, назначенные как Drain, будут продолжать обслуживать существующие соединения, но не будут принимать новые соединения. Индикатор состояния будет мигать зеленым/синим, пока идет процесс слива. После естественного закрытия существующих соединений реальные серверы перейдут в автономный режим, а индикатор состояния будет гореть синим цветом. Вы также можете просмотреть эти соединения, перейдя в раздел Навигация > Монитор > Статус.
Поведение слива можно изменить на вкладке "Дополнительные настройки".
|
Offline
|
Все реальные серверы, установленные как Offline, будут немедленно переведены в автономный режим и не будут принимать трафик.
|
В режиме ожидания
|
Все реальные серверы, установленные в качестве резервных, будут оставаться в автономном режиме до тех пор, пока ВСЕ серверы группы Online не пройдут проверку Server Health Monitor. Когда это произойдет, трафик будет приниматься группой Standby в соответствии с политикой балансировки нагрузки. Если один сервер в группе Online пройдет проверку Server Health Monitor, этот сервер Online будет получать весь трафик, а группа Standby перестанет получать трафик.
|
Вариант
|
Описание
|
Наименьшее количество соединений
|
Балансировщик нагрузки будет отслеживать количество текущих соединений с каждым Real Server. Сервер Real Server с наименьшим количеством соединений получает последующий новый запрос.
|
Самый быстрый
|
Политика балансировки нагрузки Fastest автоматически рассчитывает время ответа на все запросы для каждого сервера, сглаженное по времени. В столбце Вычисленный вес содержится автоматически вычисленное значение. Ручной ввод возможен только при использовании этой политики балансировки нагрузки.
|
Постоянный файл cookie
|
Уровень 7 Принадлежность/сохранение сеанса
Режим балансировки нагрузки на основе списка IP-адресов используется для каждого первого запроса. ADC вставляет cookie в заголовки первого HTTP-ответа. После этого ADC использует клиентский cookie для маршрутизации трафика к одному и тому же внутреннему серверу. Этот файл cookie используется для сохранения трафика, когда клиент должен каждый раз обращаться к одному и тому же внутреннему серверу. Срок действия куки истечет через 2 часа, и соединение будет сбалансировано по нагрузке в соответствии с алгоритмом, основанным на списке IP-адресов. Это время истечения настраивается с помощью jetPACK.
|
Раунд Робин
|
Round Robin обычно используется в брандмауэрах и базовых балансировщиках нагрузки и является самым простым методом. Каждый реальный сервер получает новый запрос в порядке очереди. Этот метод подходит только в том случае, если вам нужно равномерно распределить нагрузку запросов на серверы; примером могут служить поисковые веб-серверы. Однако если вам нужно сбалансировать нагрузку в зависимости от нагрузки на приложение или сервер, или даже обеспечить использование одного и того же сервера для сеанса, метод Round Robin не подходит.
|
IP Bound
|
Layer 3 Session Affinity/Persistence Cookie.
В этом режиме IP-адрес клиента служит основой для выбора сервера Real Server, который получит запрос. Это действие обеспечивает постоянство. В этом режиме могут работать протоколы HTTP и Layer 4. Этот метод полезен для внутренних сетей, где топология сети известна, и вы можете быть уверены в отсутствии "суперпрокси" выше по течению. При использовании Layer 4 и прокси-серверов все запросы могут выглядеть так, как будто они поступают от одного клиента, и поэтому нагрузка будет неравномерной. В HTTP информация заголовка (X-Forwarder-For) используется при наличии, чтобы справиться с прокси.
|
Список IP-адресов
|
Соединение с сервером Real Server инициируется с использованием "Наименьшего количества соединений", затем на основе IP-адреса клиента достигается привязка к сеансу. По умолчанию список ведется в течение 2 часов, но его можно изменить с помощью jetPACK.
|
Список общих IP-адресов
|
Этот тип службы доступен только в том случае, если для параметра Режим подключения установлено значение Прямое возвращение сервера. Он был добавлен в основном для поддержки балансировки нагрузки VMware.
|
Постоянный файл cookie
|
Уровень 7 Принадлежность/сохранение сеанса
Режим балансировки нагрузки на основе списка IP-адресов используется для каждого первого запроса. ADC вставляет cookie в заголовки первого HTTP-ответа. После этого ADC использует клиентский cookie для маршрутизации трафика к одному и тому же внутреннему серверу. Этот файл cookie используется для сохранения трафика, когда клиент должен каждый раз обращаться к одному и тому же внутреннему серверу. Срок действия куки истечет через 2 часа, и соединение будет сбалансировано по нагрузке в соответствии с алгоритмом, основанным на списке IP-адресов. Это время истечения настраивается с помощью jetPACK.
|
Классический файл cookie сеанса ASP
|
Active Server Pages (ASP) - это технология Microsoft, используемая на стороне сервера. При выборе этой опции ADC будет поддерживать постоянство сеанса на одном и том же сервере, если куки ASP обнаружены и находятся в списке известных куки. При обнаружении нового файла cookie ASP нагрузка будет сбалансирована с использованием алгоритма наименьших подключений.
|
Cookie сеанса ASP.NET
|
Этот режим применяется к ASP.net. При выборе этого режима ADC будет поддерживать постоянство сеанса на одном и том же сервере, если куки ASP.NET будут обнаружены и найдены в списке известных куки. При обнаружении нового файла cookie ASP нагрузка будет сбалансирована с использованием алгоритма наименьших подключений.
|
Cookie сеанса JSP
|
Java Server Pages (JSP) - это серверная технология Oracle. При выборе этого режима ADC будет поддерживать постоянство сеанса на одном и том же сервере, если куки JSP будут обнаружены и найдены в списке известных куки. При обнаружении нового файла cookie JSP нагрузка на него будет сбалансирована с использованием алгоритма наименьших подключений.
|
JAX-WS Session Cookie
|
Веб-службы Java (JAX-WS) - это технология Oracle для сервера. При выборе этого режима ADC будет сохранять сеанс на одном и том же сервере, если куки JAX-WS будут обнаружены и найдены в списке известных куки. При обнаружении нового файла cookie JAX-WS нагрузка будет сбалансирована с использованием алгоритма наименьших подключений.
|
Cookie сеанса PHP
|
Personal Home Page (PHP) - это серверная технология с открытым исходным кодом. При выборе этого режима ADC будет сохранять сеанс на одном и том же сервере при обнаружении куки PHP.
|
Постоянство файлов cookie RDP
|
Этот метод балансировки нагрузки использует созданный Microsoft RDP Cookie на основе имени пользователя/домена для обеспечения постоянства соединения с сервером. Преимущество этого метода заключается в том, что соединение с сервером можно поддерживать даже при изменении IP-адреса клиента.
|
На основе идентификатора cookie
|
Новый метод, очень похожий на "PhpCookieBased" и другие методы балансировки нагрузки, но использующий CookieIDBased и cookie RegEx h=[^;]+.
Этот метод будет использовать значение, установленное в поле примечаний реального сервера "ID=X;" в качестве значения cookie для идентификации сервера. Это означает, что метод аналогичен методу CookieListBased, но использует другое имя cookie и хранит уникальное значение cookie, не зашифрованный IP, а ID реального сервера (считывается при загрузке).
Значение по умолчанию - CookieIDName="h"; однако если в расширенных настройках виртуального сервера есть значение переопределения, используйте его. ПРИМЕЧАНИЕ: Мы перезаписываем выражение cookie выше, чтобы заменить h= новым значением, если это значение установлено.
Последнее замечание: если приходит неизвестное значение cookie и совпадает с одним из идентификаторов реального сервера, следует выбрать этот сервер; в противном случае используйте следующий метод (делегирование).
|
Вариант
|
Описание
|
Нет
|
В этом режиме мониторинг реального сервера не ведется, и он всегда работает правильно. Настройка None полезна в ситуациях, когда мониторинг расстраивает сервер, и для служб, которые не должны участвовать в отказоустойчивом действии ADC. Это маршрут для размещения ненадежных или устаревших систем, которые не являются основными для операций H/A. Используйте этот метод мониторинга с любым типом службы.
|
Ping/ICMP Echo
|
В этом режиме ADC отправляет эхо-запрос ICMP на IP-адрес сервера контента. Если получен корректный эхо-ответ, ADC считает, что сервер Real Server работает, и пропуск трафика к серверу продолжается. Кроме того, служба будет доступна на паре H/A. Этот метод мониторинга можно использовать с любым типом сервиса.
|
TCP-соединение
|
В этом режиме устанавливается TCP-соединение с реальным сервером и немедленно разрывается без отправки каких-либо данных. Если соединение успешно установлено, ADC считает, что реальный сервер работает. Этот метод мониторинга можно использовать с любым типом сервиса, но сервисы UDP в настоящее время не подходят для мониторинга TCP-соединений.
|
ICMP Unreachable
|
ADC отправит проверку работоспособности UDP на сервер и пометит Real Server как недоступный, если получит сообщение ICMP port unreachable. Этот метод может быть полезен, когда нужно проверить, доступен ли на сервере порт службы UDP, например порт DNS 53.
|
RDP
|
В этом режиме TCP-соединение инициализируется, как описано в методе ICMP Unreachable. После инициализации соединения запрашивается RDP-соединение уровня 7. Если соединение подтверждается, ADC считает, что Real Server работает. Этот метод мониторинга можно использовать с любым терминальным сервером Microsoft.
|
200 OK
|
В этом методе инициализируется TCP-соединение с реальным сервером. После успешного соединения АЦП отправляет реальному серверу HTTP-запрос. Ожидается HTTP-ответ и проверяется наличие кода ответа "200 OK". АЦП считает, что реальный сервер работает, если получен код ответа "200 OK". Если ADC не получает код ответа "200 OK" по какой-либо причине, включая таймауты, невозможность подключения и другие причины, ADC отмечает Real Server недоступным. Этот метод мониторинга применим только для типов служб HTTP и ускоренный HTTP. Если для HTTP-сервера используется тип службы уровня 4, его можно использовать, если SSL не используется на реальном сервере или обрабатывается соответствующим образом с помощью средства "Content SSL".
|
DICOM
|
TCP-соединение инициализируется с Real Server в режиме DICOM, и при подключении к Real Server выполняется "Ассоциативный запрос" Echoscu. Общение, включающее "Associate Accept" от сервера контента, передачу небольшого количества данных, затем "Release Request" и "Release Response", успешно завершает монитор. Если монитор не завершается успешно, то реальный сервер считается отключенным по какой-либо причине.
|
Определяется пользователем
|
В списке появится любой монитор, настроенный в разделе Мониторинг реального сервера.
|
Вариант
|
Описание
|
Хозяин
|
Кэширование на хост основано на приложении для каждого имени хоста. Для каждого домена/хоста будет существовать отдельный кэш. Этот режим идеально подходит для веб-серверов, которые могут обслуживать несколько веб-сайтов в зависимости от домена.
|
Виртуальная служба
|
При выборе этой опции доступно кэширование для каждой виртуальной службы. Только один кэш будет существовать для всех доменов/хост-имен, которые проходят через виртуальный сервис. Эта опция является специализированной настройкой для использования с несколькими клонами одного сайта.
|
Вариант
|
Описание
|
С сайта
|
Отключите сжатие для виртуальной службы
|
Компрессия
|
При выборе этого параметра включается сжатие для выбранной виртуальной службы. ADC динамически сжимает поток данных, передаваемый клиенту по запросу. Этот процесс применяется только к объектам, содержащим заголовок content-encoding: gzip. Пример содержимого включает HTML, CSS или JavaScript. Вы также можете исключить определенные типы содержимого с помощью раздела "Глобальные исключения".
|
Вариант
|
Описание
|
Нет SSL
|
Трафик от источника к ADC не шифруется.
|
Все
|
Загружает все доступные сертификаты для использования
|
По умолчанию
|
Эта опция приводит к применению локально созданного сертификата "По умолчанию" на стороне канала браузера. Используйте этот параметр для проверки SSL, если сертификат не был создан или импортирован.
|
Вариант
|
Описание
|
Нет SSL
|
Трафик от ADC к Real Server не шифруется. Выбор сертификата на стороне браузера означает, что "No SSL" может быть выбран на стороне клиента для обеспечения так называемой "разгрузки SSL".
|
Любой
|
ADC выступает в роли клиента и принимает любой сертификат, представленный Real Server. При выборе этой опции трафик от ADC к реальному серверу шифруется. Используйте параметр "Любой", когда сертификат указан на стороне виртуальной службы, обеспечивая так называемое "SSL Bridging" или "SSL Re-Encryption".
|
SNI
|
SNI, или Server Name Indication, - это расширение сетевого протокола TLS, с помощью которого клиент указывает имя хоста, к которому он пытается подключиться, в начале процесса передачи данных . Эта настройка позволяет ADC представлять несколько сертификатов на одном виртуальном IP-адресе и TCP-порту.
|
По умолчанию
|
Здесь отображаются все созданные вами самоподписанные сертификаты.
|
Вариант
|
Описание
|
Обратный прокси-сервер
|
Обратный прокси - это значение по умолчанию, которое использует сжатие и кэширование при использовании на уровне 7. На уровне 4 обратный прокси работает без кэширования и сжатия. В этом режиме ваш ADC действует как обратный прокси и становится адресом источника, который видят реальные серверы.
|
Прямое возвращение сервера
|
Direct Server Return или DSR, также известный как DR - Direct Routing, позволяет серверу, находящемуся за балансировщиком нагрузки, отвечать клиенту напрямую, минуя ADC при ответе. DSR подходит только для использования с балансировкой нагрузки 4-го уровня. Поэтому кэширование и сжатие недоступны при выборе этой опции.
Этот режим можно использовать только с типами служб TCP, UDP и TCP/UDP.
Политики сохранения балансировки нагрузки также ограничены наименьшим количеством соединений, общим списком IP-адресов, круговым обходом и списком IP-адресов.
![]() Использование DSR также требует внесения изменений в Real Server. Обратитесь к разделу Изменения реального сервера.
|
NAT
|
По умолчанию ADC использует IP-адрес ADC в качестве IP-адреса источника, а серверы Real Server отправляют ответ обратно в ADC для возврата клиенту. Это хорошо почти во всех обстоятельствах, но есть сценарии, когда реальный сервер должен видеть исходный IP-адрес клиента, а не ADC.
Когда применяется режим NAT, ADC получает входящий запрос, а затем отправляет его на реальный сервер после того, как изменит IP-адрес источника на адрес виртуальной службы (VIP-адрес).
Этот режим можно использовать только со следующими политиками балансировки нагрузки:
![]() |
Шлюз
|
Режим шлюза позволяет направлять весь трафик через ADC, позволяя направлять Real Servers через ADC в другие сети через виртуальные сервисы ADC или аппаратные интерфейсы. Использование устройства в качестве шлюза для серверов Real Servers идеально при работе в многоинтерфейсном режиме.
Политики сохранения балансировки нагрузки также ограничены наименьшим количеством соединений, общим списком IP-адресов, круговым обходом и списком IP-адресов.
![]() Этот метод требует, чтобы Real Server установил шлюз по умолчанию на адрес локального интерфейса ADC (eth0, eth1 и т. д.). Обратитесь к разделу "Изменения реального сервера".
Обратите внимание, что режим шлюза не поддерживает обход отказа в кластерной среде.
|
Вариант
|
Описание
|
Нет
|
Если заголовок Proxy отсутствует или не поддерживается в текущем типе сервиса.
|
Удалить
|
Удаляет заголовок Proxy из TCP-пакета
|
Вперед
|
Передает заголовок Proxy на сервер
|
Вариант
|
Описание
|
Версия 1
|
Текстовый формат, простой в реализации и отладке.
Предоставляет основную информацию о подключении клиента, включая IP-адрес источника, IP-адрес назначения, порт источника и порт назначения.
Строка протокола добавляется в начало TCP-соединения, что делает его удобочитаемым, но несколько менее эффективным с точки зрения производительности по сравнению с двоичными форматами.
|
Версия 2
|
Двоичный формат, разработанный для повышения производительности и эффективности.
Расширяет информацию, которая может быть передана о соединении, поддерживая дополнительные данные, такие как семейство адресов и специфическая информация о протоколе.
Обеспечивает лучшую совместимость с современными сетевыми протоколами и функциями, включая поддержку IPv6 и транспортных протоколов за пределами TCP.
|
Вариант
|
Описание
|
Базовый IP-адрес (по умолчанию)
|
В качестве исходного IP-адреса запроса используется eth0 или базовый IP-адрес АЦП.
|
Виртуальный IP
|
Используется виртуальный IP-адрес службы.
|
<IP-адрес>
|
Позволяет указать IP-адрес, который является частью ADC. Это может быть другой сетевой интерфейс или другой VIP.
|
Вариант
|
Описание
|
Управляемые постоянством
|
Это выбор по умолчанию.
Всякий раз, когда пользователь посещает сессию персистентности, она расширяется.
При круглосуточном использовании возможно, что слив никогда не произойдет.
Однако если количество соединений с реальным сервером достигает 0, слив завершается, сессии сохранения удаляются, а все посетители заново балансируются при следующем соединении.
|
Миграция посетителей
|
Постоянная сессия игнорируется при повторном подключении - (устаревшее поведение до 2022 года)
Новые TCP-соединения (независимо от того, являются ли они частью существующей сессии или нет) всегда устанавливаются с реальным сервером в режиме онлайн.
Если сессия сохранения была связана с истощающимся реальным сервером, она перезаписывается.
Виртуальная служба будет фактически игнорировать постоянство для любых новых соединений, и они будут перераспределены на новый сервер.
|
Сессии на пенсии
|
Постоянные сессии не продлеваются.
Входящие пользовательские соединения будут назначены на желаемый сервер, но их сессия сохранения не будет продлена. Поэтому по истечении времени сессии персистенции они будут рассматриваться как новые соединения и перемещаться на другой сервер.
|