|
Настоящие серверы
В разделе Real Servers приборной панели есть несколько вкладок: Server, Basic, Advanced и flightPATH.
Сервер
На вкладке Сервер содержатся определения реальных внутренних серверов, сопряженных с выбранной в данный момент виртуальной службой. В раздел "Реальные серверы" необходимо добавить хотя бы один сервер.
Добавить сервер
Выберите соответствующий VIP, который вы ранее определили.
Нажмите Добавить сервер
Появится новая строка с мигающим курсором в колонке IP-адрес
Введите IPv4-адрес вашего сервера в десятичной системе счисления. Реальный сервер может находиться в той же сети, что и виртуальная служба, в любой непосредственно подключенной локальной сети или в любой сети, к которой может быть проложен маршрут ADC. Пример "10.1.1.1".
Перейдите в столбец Порт и введите номер порта TCP/UDP для вашего сервера. Номер порта может совпадать с номером порта виртуальной службы или быть другим номером порта для подключения обратного прокси. ADC автоматически переведет порт на этот номер.
Перейдите в раздел "Примечания", чтобы добавить все необходимые сведения о сервере. Пример: "Веб-сервер IIS 1".
Название группы
После добавления серверов, составляющих набор для балансировки нагрузки, вы также можете указать имя группы. После редактирования этого поля его содержимое сохраняется без необходимости нажимать кнопку Update.
Индикаторы состояния реального сервера
Состояние реального сервера можно определить по светлому цвету в столбце "Состояние". См. ниже:
|
LED
|
Значение
|
|
?
|
Подключено
|
|
?
|
Не контролируется
|
|
?
|
Слив
|
|
?
|
Offline
|
|
?
|
В режиме ожидания
|
|
?
|
Не подключено
|
|
?
|
Состояние выводов
|
|
?
|
Не лицензировано или превышено количество лицензированных серверов Real Servers
|
Деятельность
Вы можете в любой момент изменить Активность реального сервера с помощью выпадающего меню. Для этого дважды щелкните по строке Real Server, чтобы перевести ее в режим редактирования.
|
Вариант
|
Описание
|
|
Онлайн
|
Все Real Servers, назначенные Online, будут получать трафик в соответствии с политикой балансировки нагрузки, установленной на вкладке Basic.
|
|
Дренаж
|
Все реальные серверы, назначенные как Drain, будут продолжать обслуживать существующие соединения, но не будут принимать новые соединения. Индикатор состояния будет мигать зеленым/синим, пока идет процесс слива. После естественного закрытия существующих соединений реальные серверы перейдут в автономный режим, а индикатор состояния будет гореть синим цветом. Вы также можете просмотреть эти соединения, перейдя в раздел Навигация > Монитор > Статус.
Поведение слива можно изменить на вкладке "Дополнительные настройки".
|
|
Offline
|
Все реальные серверы, установленные как Offline, будут немедленно переведены в автономный режим и не будут принимать трафик.
|
|
В режиме ожидания
|
Все реальные серверы, установленные в качестве резервных, будут оставаться в автономном режиме до тех пор, пока ВСЕ серверы группы Online не пройдут проверку Server Health Monitor. Когда это произойдет, трафик будет приниматься группой Standby в соответствии с политикой балансировки нагрузки. Если один сервер в группе Online пройдет проверку Server Health Monitor, этот сервер Online будет получать весь трафик, а группа Standby перестанет получать трафик.
|
IP-адрес
В этом поле указывается IP-адрес вашего сервера Real Server. Пример "192.168.1.200".
Порт
Номер порта TCP или UDP, который прослушивает Real Server для данной службы. Пример "80" для веб-трафика.
Вес
Этот столбец станет доступным для редактирования, когда будет указана соответствующая политика балансировки нагрузки.
Вес по умолчанию для Real Server равен 100, а вы можете ввести значения от 1 до 100. Значение 100 означает максимальную нагрузку, а 1 - минимальную.
Пример для трех серверов может выглядеть следующим образом:
Вес сервера 1 = 100
Вес сервера 2 = 50
Вес сервера 3 = 50
Если учесть, что политика балансировки нагрузки установлена на "Наименьшее количество подключений", а общее количество клиентских подключений составляет 200;
Сервер 1 получит 100 одновременных соединений
Сервер 2 получит 50 одновременных соединений
Сервер 3 получит 50 одновременных соединений
Если бы мы использовали метод балансировки нагрузки Round Robin, который ротирует запросы через набор серверов с балансировкой нагрузки, изменение весов влияет на то, как часто серверы выбираются в качестве целевых.
Если мы считаем, что политика балансировки нагрузки Fastest использует наименьшее время, необходимое для получения ответа, то регулировка весов изменяет смещение аналогично Least Connections.
Расчетный вес
Расчетный вес каждого сервера можно просматривать динамически, он рассчитывается автоматически и не редактируется. Поле показывает фактический вес, который ADC использует при учете ручного взвешивания и политики балансировки нагрузки.
Конечная точка мониторинга
Эта функция позволяет указать определенные конечные точки для мониторинга и, таким образом, определить состояние здоровья для записи Real Server. Вы можете оставить значение по умолчанию "Self", и тогда функция будет полагаться на мониторы реального сервера, указанные для виртуальной службы. Кроме того, можно указать IP-адрес, порт или IP-адрес:порт, что позволит вам контролировать другую конечную точку в вашей сети. В качестве примера можно привести, например, сервер базы данных, от которого зависят службы.
Примечания
Введите в поле Notes любые примечания, которые помогут описать определяемую запись. Например, "IIS Server1 - London DC". Это поле можно использовать для особых нужд в правилах flightPATH и GSLB.
ID
Эта настройка имеет несколько вариантов использования.
Настойчивость
Это значение можно использовать в сочетании с методом сохранения на основе идентификатора куки. Этот метод очень похож на метод сохранения на основе сессий PHP, но использует новую технику, называемую Cookie ID Based и cookie RegEx h=[^;]+. Метод сохранения на основе идентификатора Cookie будет использовать значение в поле ID для создания Cookie.
Использование flightPATH
Вы также можете использовать значение в этом поле для направления трафика и т. д.
Основные
Политика балансировки нагрузки
В раскрывающемся списке отображаются поддерживаемые в настоящее время политики балансировки нагрузки. Список политик балансировки нагрузки с пояснениями приведен ниже.
|
Вариант
|
Описание
|
|
Наименьшее количество соединений
|
Балансировщик нагрузки будет отслеживать количество текущих соединений с каждым 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 и совпадает с одним из идентификаторов реального сервера, следует выбрать этот сервер; в противном случае используйте следующий метод (делегирование).
|
Мониторинг сервера
Ваш ADC содержит несколько предустановленных методов мониторинга реального сервера.
Выберите метод мониторинга, который вы хотите применить к виртуальной службе (VIP).
Важно выбрать правильный монитор для службы. Например, если Real Server - это RDP-сервер, монитор 200OK не имеет значения. В равной степени выбор TCP Connection и 200OK также не имеет смысла, поскольку для работы 200OK необходимо рабочее TCP-соединение. Если вы не знаете, какой монитор выбрать, то для начала лучше всего выбрать TCP Connection
Вы можете выбрать несколько мониторов, поочередно щелкая каждый монитор, который вы хотите применить к службе. Выбранные мониторы выполняются в том порядке, в котором вы их выбрали; поэтому сначала начните с мониторов нижних уровней. Например, если установить мониторы Ping/ICMP Echo, TCP Connection и 200OK, то на приборной панели появятся события, как показано на рисунке ниже:
Мы видим, что уровень 3 Ping и уровень 4 TCP Connect прошли успешно, если мы посмотрим на верхнюю строку, но уровень 7 200OK потерпел неудачу. Эти результаты мониторинга дают достаточно информации, чтобы указать, что с маршрутизацией все в порядке и на соответствующем порту запущена служба, но веб-сайт не отвечает корректно на запрошенную страницу. Теперь пришло время взглянуть на веб-сервер и раздел Library > Real Server Monitor (Библиотека > Монитор реального сервера), чтобы увидеть детали отказавшего монитора.
|
Вариант
|
Описание
|
|
Нет
|
В этом режиме мониторинг реального сервера не ведется, и он всегда работает правильно. Настройка 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", успешно завершает монитор. Если монитор не завершается успешно, то реальный сервер считается отключенным по какой-либо причине.
|
|
Определяется пользователем
|
В списке появится любой монитор, настроенный в разделе Мониторинг реального сервера.
|
Стратегия кэширования
По умолчанию стратегия кэширования отключена и установлена как Off. Если тип вашего сервиса - HTTP, то вы можете применить два типа стратегии кэширования.
Для настройки подробных параметров кэширования обратитесь к странице Настройка кэша. Обратите внимание, что когда кэширование применяется к VIP с типом службы Accelerated "HTTP", сжатые объекты не кэшируются.
|
Вариант
|
Описание
|
|
Хозяин
|
Кэширование на хост основано на приложении для каждого имени хоста. Для каждого домена/хоста будет существовать отдельный кэш. Этот режим идеально подходит для веб-серверов, которые могут обслуживать несколько веб-сайтов в зависимости от домена.
|
|
Виртуальная служба
|
При выборе этой опции доступно кэширование для каждой виртуальной службы. Только один кэш будет существовать для всех доменов/хост-имен, которые проходят через виртуальный сервис. Эта опция является специализированной настройкой для использования с несколькими клонами одного сайта.
|
Ускорение
|
Вариант
|
Описание
|
|
С сайта
|
Отключите сжатие для виртуальной службы
|
|
Компрессия
|
При выборе этого параметра включается сжатие для выбранной виртуальной службы. ADC динамически сжимает поток данных, передаваемый клиенту по запросу. Этот процесс применяется только к объектам, содержащим заголовок content-encoding: gzip. Пример содержимого включает HTML, CSS или JavaScript. Вы также можете исключить определенные типы содержимого с помощью раздела "Глобальные исключения".
|
Примечание: Если объект кэшируемый, ADC будет хранить сжатую версию и обслуживать ее статически (из памяти) до тех пор, пока срок действия содержимого не истечет и оно не будет повторно подтверждено.
Сертификат SSL виртуальной службы (шифрование между клиентом и ADC)
По умолчанию установлено значение Нет SSL. Если тип вашей службы - "HTTP", вы можете выбрать сертификат из выпадающего списка, чтобы применить его к виртуальной службе. В этом списке появятся сертификаты, которые были созданы или импортированы.
Можно также выделить несколько сертификатов для применения к службе. Эта операция автоматически включит расширение SNI, чтобы разрешить сертификат на основе "Доменного имени", запрошенного клиентом.
|
Вариант
|
Описание
|
|
Нет SSL
|
Трафик от источника к ADC не шифруется.
|
|
Все
|
Загружает все доступные сертификаты для использования
|
|
По умолчанию
|
Эта опция приводит к применению локально созданного сертификата "По умолчанию" на стороне канала браузера. Используйте этот параметр для проверки SSL, если сертификат не был создан или импортирован.
|
SSL-сертификат реального сервера (шифрование между АЦП и реальным сервером)
По умолчанию для этого параметра установлено значение No SSL. Если ваш сервер требует зашифрованного соединения, это значение должно быть любым другим, кроме No 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 и т. д.). Обратитесь к разделу "Изменения реального сервера".
Обратите внимание, что режим шлюза не поддерживает обход отказа в кластерной среде.
|
Параметры шифра
Шифры составляют основу криптографии SSL и чрезвычайно важны для успешной и безопасной доставки веб-контента и приложений.
ADC содержит встроенный набор шифров по умолчанию, включающий самые современные и безопасные из доступных для использования.
Бывают случаи, когда пользователь хочет объявить о наличии определенного набора шифров, и ADC позволяет создавать такие шифры с помощью написанных пользователем jetPACKS. Написанные пользователями jetPACKS могут быть импортированы в ADC через Configuration > Software, а затем доступны для выбора с помощью меню Cipher Options.
Варианты шифров индивидуальны для каждого VIP-клиента, обеспечивая высокую гибкость и безопасность.
Дополнительную информацию о параметрах шифра см: Шифр
Переговоры клиента SSL
Отметьте этот флажок, если хотите разрешить инициированное клиентом повторное согласование SSL. Чтобы предотвратить возможные DDOS-атаки на уровень SSL, снимите этот флажок.
Возобновление работы SSL клиента
Отметьте этот флажок, если хотите включить возобновление сеансов сервера SSL, добавленных в кэш сеансов. Когда клиент предлагает повторно использовать сессию, сервер попытается использовать ее повторно, если она будет найдена. Если флажок "Возобновление" не установлен, кэширование сеансов для клиента или сервера не происходит.
Сертификат SNI по умолчанию
Во время SSL-соединения с включенной функцией SNI на стороне клиента, если запрашиваемый домен не соответствует ни одному из сертификатов, назначенных службе, ADC представит сертификат SNI по умолчанию. По умолчанию установлено значение Нет, что приведет к обрыву соединения в случае отсутствия точного совпадения. Выберите любой из установленных сертификатов из выпадающего списка, чтобы представить его в случае, если точное совпадение SSL-сертификата не удастся.
Протокол прокси
Протокол Proxy Protocol разработан для того, чтобы сетевые прокси-серверы могли передавать информацию о клиентском соединении (например, IP-адрес и номер порта) на принимающий сервер. Этот протокол особенно полезен в сценариях, когда необходимо сохранить фактический IP-адрес конечного пользователя при маршрутизации трафика через балансировщик нагрузки или обратный прокси. Он помогает сохранить исходный IP-адрес клиента для ведения журнала, статистики или в целях безопасности, повышая возможность принятия обоснованных решений на основе истинного источника трафика.
Заголовок клиентского прокси-сервера
Заголовок клиентского прокси означает заголовок, добавляемый ADC к запросу клиента и содержащий исходную информацию о соединении (например, IP-адрес и порт клиента). Это очень важно в средах, где ADC выступает в роли прокси, а серверу необходимо знать исходные данные клиента для таких целей, как ведение журнала, оценка безопасности и поддержание специфического для клиента поведения. Заголовок Client Proxy Header гарантирует, что, несмотря на посредническую роль ADC, сервер может точно определить исходные данные соединения клиента и взаимодействовать с ним.
Опции включают:
|
Вариант
|
Описание
|
|
Нет
|
Если заголовок Proxy отсутствует или не поддерживается в текущем типе сервиса.
|
|
Удалить
|
Удаляет заголовок Proxy из TCP-пакета
|
|
Вперед
|
Передает заголовок Proxy на сервер
|
Заголовок прокси-сервера
Существует две версии заголовков серверного прокси: Версия 1 и Версия 2.
|
Вариант
|
Описание
|
|
Версия 1
|
Текстовый формат, простой в реализации и отладке.
Предоставляет основную информацию о подключении клиента, включая IP-адрес источника, IP-адрес назначения, порт источника и порт назначения.
Строка протокола добавляется в начало TCP-соединения, что делает его удобочитаемым, но несколько менее эффективным с точки зрения производительности по сравнению с двоичными форматами.
|
|
Версия 2
|
Двоичный формат, разработанный для повышения производительности и эффективности.
Расширяет информацию, которая может быть передана о соединении, поддерживая дополнительные данные, такие как семейство адресов и специфическая информация о протоколе.
Обеспечивает лучшую совместимость с современными сетевыми протоколами и функциями, включая поддержку IPv6 и транспортных протоколов за пределами TCP.
|
Параметры заголовка Client Proxy Header и Server Proxy header доступны только для типов служб Layer 4 и Layer 7 HTTP.
Адрес источника реального сервера
Эта настройка работает вместе с обратным прокси и службой Layer 4 TCP, Layer 4 UDP или HTTP(S). Настройка предоставляет три варианта, которые вы можете выбрать.
|
Вариант
|
Описание
|
|
Базовый IP-адрес (по умолчанию)
|
В качестве исходного IP-адреса запроса используется eth0 или базовый IP-адрес АЦП.
|
|
Виртуальный IP
|
Используется виртуальный IP-адрес службы.
|
|
<IP-адрес>
|
Позволяет указать IP-адрес, который является частью ADC. Это может быть другой сетевой интерфейс или другой VIP.
|
Журнал безопасности
Значение "Вкл." установлено по умолчанию и используется для каждого сервиса, позволяя регистрировать информацию об аутентификации в журналах W3C. Нажав на значок Cog, вы перейдете на страницу System > Logging, где можно проверить настройки протоколирования W3C.
Макс. Соединения
Ограничивает количество одновременных подключений Real Server и задается для каждой службы. Например, если вы установите значение 1000 и у вас будет два сервера Real Server, ADC ограничит каждый сервер Real Server до 1000 одновременных подключений. Вы также можете выбрать отображение страницы "Сервер слишком занят" при достижении этого предела на всех серверах, чтобы помочь пользователям понять причину отсутствия ответа или задержки. Оставьте этот параметр пустым для неограниченного числа подключений. То, что вы установите здесь, зависит от ресурсов вашей системы.
Таймаут соединения
По умолчанию таймаут соединения составляет 600 секунд или 10 минут. Этот параметр регулирует время, в течение которого соединение будет прерываться при отсутствии активности. Уменьшите этот параметр для недолговечного веб-трафика без статических данных, который обычно составляет 90 секунд или меньше. Увеличьте этот параметр для соединений с активным состоянием, таких как RDP, до 7200 секунд (2 часа) или более, в зависимости от вашей инфраструктуры. Пример с таймаутом RDP означает, что если пользователь неактивен в течение 2 часов или менее, соединения останутся открытыми.
Таймаут постоянства
Параметр Persistence Timeout в балансировщиках нагрузки определяет продолжительность сохранения балансировщиком нагрузки информации о сеансе для клиента. Это гарантирует, что последующие запросы от одного и того же клиента будут направлены на один и тот же внутренний сервер, что способствует согласованности сеансов и взаимодействию с учетом состояния. По истечении указанного периода без дальнейшей активности клиента информация о сессии удаляется, и новые запросы могут быть направлены на другой сервер.
Интервал мониторинга
Интервал - это время в секундах между мониторами. По умолчанию интервал составляет 1 секунду. Хотя 1 с является приемлемым для большинства приложений, может быть полезно увеличить это значение для других приложений или во время тестирования.
Таймаут мониторинга
Значение таймаута - это время, в течение которого ADC будет ждать ответа сервера на запрос соединения. По умолчанию это значение равно 2 с. Увеличьте это значение для загруженных серверов.
Мониторинг в графе
Значение по умолчанию для этого параметра равно 2. Значение 2 означает, что сервер Real Server должен пройти две успешные проверки работоспособности, прежде чем он будет запущен. Увеличение этого значения повышает вероятность того, что сервер сможет обслуживать трафик, но в зависимости от интервала времени ему потребуется больше времени для введения в эксплуатацию. Уменьшение этого значения приведет к более быстрому вводу сервера в эксплуатацию.
Счетчик выходов мониторинга
Значение по умолчанию для этого параметра равно 3, что означает, что монитор Real Server должен трижды потерпеть неудачу, прежде чем ADC прекратит отправку трафика на сервер, и он будет помечен как RED и Unreachable. Увеличение этого показателя приведет к улучшению и повышению надежности обслуживания за счет времени, которое требуется ADC для прекращения отправки трафика на этот сервер.
Мониторинг KCD Realm
Этот параметр позволяет включить мониторинг Kerberos Constrained Delegation Realm, который вы установили в определениях Kerberos. См. раздел Аутентификация > Kerberos.
Поведение при сливе
Когда какой-либо реальный сервер переводится в режим Drain, всегда лучше иметь возможность контролировать поведение трафика, отправляемого на него. Меню Drain Behaviour позволяет выбрать поведение трафика для каждой виртуальной службы. Возможны следующие варианты:
|
Вариант
|
Описание
|
|
Управляемые постоянством
|
Это выбор по умолчанию.
Всякий раз, когда пользователь посещает сессию персистентности, она расширяется.
При круглосуточном использовании возможно, что слив никогда не произойдет.
Однако если количество соединений с реальным сервером достигает 0, слив завершается, сессии сохранения удаляются, а все посетители заново балансируются при следующем соединении.
|
|
Миграция посетителей
|
Постоянная сессия игнорируется при повторном подключении - (устаревшее поведение до 2022 года)
Новые TCP-соединения (независимо от того, являются ли они частью существующей сессии или нет) всегда устанавливаются с реальным сервером в режиме онлайн.
Если сессия сохранения была связана с истощающимся реальным сервером, она перезаписывается.
Виртуальная служба будет фактически игнорировать постоянство для любых новых соединений, и они будут перераспределены на новый сервер.
|
|
Сессии на пенсии
|
Постоянные сессии не продлеваются.
Входящие пользовательские соединения будут назначены на желаемый сервер, но их сессия сохранения не будет продлена. Поэтому по истечении времени сессии персистенции они будут рассматриваться как новые соединения и перемещаться на другой сервер.
|
Переход в автономный режим при сбое
Если этот флажок установлен, реальные серверы, не прошедшие проверку здоровья, переводятся в автономный режим и могут быть запущены только вручную.
flightPATH
flightPATH - это технология управления трафиком, разработанная компанией Edgenexus и доступная исключительно в ADC. В отличие от движков на основе правил других производителей, flightPATH не работает через командную строку или консоль ввода сценариев. Вместо этого он использует графический интерфейс пользователя для выбора различных параметров, условий и действий, которые необходимо выполнить для достижения нужной цели. Эти особенности делают flightPATH чрезвычайно мощным и позволяют сетевым администраторам манипулировать HTTPS-трафиком весьма эффективными способами.
flightPATH доступен только для использования с HTTPS-соединениями, и этот раздел не отображается, если тип виртуального сервиса не HTTP.
Как видно из изображения выше, слева находится список доступных правил, а справа - правила, применяемые к виртуальной службе.
Примените доступное правило, перетащив его с левой стороны на правую, или выделите правило и нажмите стрелку вправо, чтобы переместить его на правую сторону.
Порядок выполнения важен и начинается с того, что первым выполняется верхнее правило. Чтобы изменить порядок выполнения, выделите правило и перемещайте его вверх и вниз с помощью стрелок.
Важно понимать, что правила flightPATH в этом разделе ADC работают по принципу булева ИЛИ, в то время как условия и действия в области определения flightPATH работают по принципу И.
Чтобы удалить правило, перетащите его обратно в инвентарь правил слева или выделите правило и нажмите стрелку влево.
Добавлять, удалять и редактировать правила flightPATH можно в разделе "Настройка flightPATH" данного руководства.