Поле
|
Описание
|
IP-адрес
|
Введите новый виртуальный IP-адрес, который будет целевой точкой входа для доступа к реальному серверу. Этот IP-адрес является местом, на которое будут указывать пользователи или приложения для доступа к приложению с балансировкой нагрузки.
|
Маска подсети/Префикс
|
Это поле предназначено для маски подсети, относящейся к сети, в которой находится АЦП
|
Порт
|
Порт входа, используемый при доступе к VIP. Это значение не обязательно должно быть таким же, как у реального сервера, если Вы используете обратный прокси.
|
Название услуги
|
Название услуги - это текстовое представление назначения VIP-клиента. Оно необязательно, но мы рекомендуем Вам указать его для ясности.
|
Тип услуги
|
Существует множество различных типов услуг, которые Вы можете выбрать. Типы услуг уровня 4 не могут использовать технологию flightPATH.
|
Поле
|
Описание
|
Деятельность
|
Поле Activity можно использовать для отображения и изменения статуса реального сервера с балансировкой нагрузки.
Online - Обозначает, что сервер активен и принимает запросы с балансировкой нагрузки
Offline - Сервер находится в автономном режиме и не получает запросы.
Drain - Сервер был переведен в режим drain, чтобы можно было промыть персистентность и перевести сервер в автономное состояние, не затрагивая пользователей.
Standby - Сервер был переведен в состояние ожидания
|
IP-адрес
|
Это значение является IP-адресом реального сервера. Он должен быть точным и не должен быть адресом DHCP.
|
Порт
|
Целевой порт доступа на реальном сервере. При использовании обратного прокси-сервера он может отличаться от порта входа, указанного на VIP-сервере.
|
Взвешивание
|
Эта настройка обычно автоматически конфигурируется АЦП. Вы можете изменить его, если хотите изменить взвешивание приоритетов.
|
Вариант
|
Описание
|
Кластер
|
Кластер - это роль по умолчанию для ADC при установке, а в колонке Primary/Mode будет указан режим, в котором он работает в настоящее время. Если в Вашем датацентре есть пара устройств ADC в режиме HA, одно из них будет показывать Active, а другое Passive.
|
Руководство
|
Роль Manual позволяет паре ADC работать в режиме Active-Active для разных виртуальных IP-адресов. В таких случаях колонка Primary будет содержать поле рядом с каждым уникальным виртуальным IP, которое можно отметить для Active или оставить не отмеченным для Passive.
|
Автономный
|
АЦП работает как автономное устройство и не находится в режиме высокой доступности. Поэтому в колонке Primary будет указано Stand-alone.
|
LED
|
Значение
|
l
|
Онлайн
|
l
|
Failover-Standby. Эта виртуальная служба работает в режиме горячего резервирования
|
l
|
Указывает на то, что "вторичный" задерживает "первичного".
|
l
|
Сервис требует внимания. Этот признак может быть результатом того, что реальный сервер не прошел проверку монитора здоровья или был вручную переведен в автономный режим. Трафик будет продолжать идти, но с уменьшенной пропускной способностью реального сервера.
|
l
|
Не в сети. Серверы содержимого недоступны, или ни один сервер содержимого не включен
|
l
|
Состояние находок
|
l
|
Не лицензированы или лицензированы Виртуальные IP превышены
|
Тип услуги
|
Порт/Протокол
|
Уровень обслуживания
|
Комментарий
|
TCP 4-го уровня
|
Любой порт TCP
|
Уровень 4
|
АЦП не изменяет никакой информации в потоке данных и выполняет стандартную балансировку нагрузки на трафик в соответствии с политикой балансировки нагрузки
|
Уровень 4 UDP
|
Любой UDP-порт
|
Уровень 4
|
Как и в случае с TCP 4-го уровня, ADC не изменяет никакой информации в потоке данных и выполняет стандартную балансировку нагрузки трафика в соответствии с политикой балансировки нагрузки
|
Уровень 4 TCP/UDP
|
Любой порт TCP или UDP
|
Уровень 4
|
Это идеальный вариант, если Ваша служба имеет основной протокол, такой как UDP, но будет возвращаться к TCP. ADC не изменяет никакой информации в потоке данных и выполняет стандартную балансировку трафика в соответствии с политикой балансировки нагрузки
|
DNS
|
!!!
|
|
|
HTTP
|
Протокол HTTP или HTTPS
|
Уровень 7
|
АЦП может взаимодействовать, манипулировать и изменять поток данных с помощью flightPATH.
|
FTP
|
Протокол передачи файлов Протокол
|
Уровень 7
|
Использование отдельных соединений управления и данных между клиентом и сервером
|
SMTP
|
Простой протокол передачи почты
|
Уровень 4
|
Используйте при балансировке нагрузки на почтовые серверы
|
POP3
|
Протокол почтового отделения
|
Уровень 4
|
Используйте при балансировке нагрузки на почтовые серверы
|
IMAP
|
Протокол доступа к интернет-сообщениям
|
Уровень 4
|
Используйте при балансировке нагрузки на почтовые серверы
|
RDP
|
Протокол удаленного рабочего стола
|
Уровень 4
|
Используйте при балансировке нагрузки серверов служб терминалов
|
RPC
|
Удаленный вызов процедуры
|
Уровень 4
|
Используйте при балансировке нагрузки систем, использующих вызовы RPC
|
RPC/ADS
|
Exchange 2010 Статический RPC для службы адресной книги
|
Уровень 4
|
Используйте при балансировке нагрузки серверов Exchange
|
RPC/CA/PF
|
Exchange 2010 Static RPC для клиентского доступа и общих папок
|
Уровень 4
|
Используйте при балансировке нагрузки серверов Exchange
|
DICOM
|
Цифровая визуализация и коммуникации в медицине
|
Уровень 4
|
Используйте при балансировке нагрузки серверов, использующих протоколы DICOM
|
LED
|
Значение
|
l
|
Подключено
|
£
|
Не контролируется
|
l
|
Слив
|
l
|
Offline
|
l
|
В режиме ожидания
|
l
|
Не подключено
|
l
|
Статус находки
|
l
|
Не лицензировано или превышено количество лицензированных серверов Real Servers
|
Вариант
|
Описание
|
Онлайн
|
Все Real Servers, назначенные Online, будут получать трафик в соответствии с политикой балансировки нагрузки, установленной на вкладке Basic.
|
Слив
|
Все реальные серверы, назначенные как "Слив", будут продолжать обслуживать существующие соединения, но не будут принимать новые соединения. Индикатор состояния будет мигать зеленым/синим цветом, пока идет процесс слива. Как только существующие соединения естественным образом закроются, реальные серверы перейдут в автономный режим, а индикатор состояния будет гореть синим цветом. Вы также можете просмотреть эти соединения, перейдя в раздел Навигация > Монитор > Статус.
|
Offline
|
Все реальные серверы, установленные как Offline, будут немедленно переведены в автономный режим и не будут получать трафик.
|
В режиме ожидания
|
Все реальные серверы, установленные как резервные, будут оставаться в автономном режиме до тех пор, пока ВСЕ серверы группы Online не пройдут проверку Server Health Monitor. Трафик будет приниматься резервной группой в соответствии с политикой балансировки нагрузки, когда это произойдет. Если один сервер в группе Online пройдет проверку Server Health Monitor, этот сервер Online будет получать весь трафик, а группа Standby перестанет получать трафик.
|
Вариант
|
Описание
|
Самый быстрый
|
Политика балансировки нагрузки Fastest автоматически рассчитывает время ответа на все запросы для каждого сервера, сглаженное по времени. Колонка Рассчитанный вес содержит автоматически рассчитанное значение. Ручной ввод возможен только при использовании этой политики балансировки нагрузки.
|
Раунд Робин
|
Round Robin обычно используется в брандмауэрах и базовых балансировщиках нагрузки и является самым простым методом. Каждый реальный сервер получает новый запрос по порядку. Этот метод подходит только тогда, когда Вам нужно равномерно распределить нагрузку запросов на серверы; примером могут служить поисковые веб-серверы. Однако, когда Вам нужно сбалансировать нагрузку на основе нагрузки приложения или нагрузки сервера, или даже обеспечить использование одного и того же сервера для сессии, метод Round Robin неуместен.
|
Наименьшие связи
|
Балансировщик нагрузки будет отслеживать количество текущих подключений к каждому Real Server. Сервер Real Server с наименьшим количеством соединений получает последующий новый запрос.
|
Layer 3 Session Affinity/Persistence - IP Bound
|
В этом режиме IP-адрес клиента формирует основу для выбора того, какой Real Server получит запрос. Это действие обеспечивает постоянство. HTTP и протоколы 4-го уровня могут использовать этот режим. Этот метод полезен для внутренних сетей, где топология сети известна, и Вы можете быть уверены, что нет "супер-прокси" выше по течению. При использовании Layer 4 и прокси-серверов все запросы могут выглядеть так, как будто они исходят от одного клиента, и поэтому нагрузка будет неравномерной. В HTTP информация заголовка (X-Forwarder-For) используется при наличии, чтобы справиться с прокси.
|
Слияние/сохранение сеансов 3-го уровня - на основе списка IP-адресов
|
Соединение с Real Server инициируется с использованием "Наименьшего количества соединений", затем на основе IP-адреса клиента достигается привязка к сеансу. По умолчанию список ведется в течение 2 часов, но его можно изменить с помощью jetPACK.
|
Уровень 7 Принадлежность/ постоянство сеанса - Куки сеанса
|
Этот режим является наиболее популярным методом балансировки нагрузки для HTTP. В этом режиме ADC использует балансировку нагрузки на основе IP-списков для каждого первого запроса. Он вставляет cookie в заголовки первого HTTP-ответа. После этого ADC использует cookie клиента для маршрутизации трафика на один и тот же внутренний сервер. Этот файл cookie используется для постоянства, когда клиенту необходимо каждый раз обращаться к одному и тому же внутреннему серверу. Срок действия куки истекает после закрытия сессии.
|
Уровень 7 Принадлежность/постоянство сеанса - Постоянный файл cookie
|
Режим балансировки нагрузки на основе списка IP используется для каждого первого запроса. АЦП вставляет cookie в заголовки первого HTTP-ответа. После этого ADC использует cookie клиента для маршрутизации трафика на один и тот же внутренний сервер. Этот файл cookie используется для постоянства, когда клиент должен каждый раз обращаться к одному и тому же внутреннему серверу. Срок действия cookie истечет через 2 часа, и соединение будет сбалансировано по нагрузке в соответствии с алгоритмом, основанным на списке IP-адресов. Это время истечения срока действия можно настроить с помощью jetPACK.
|
Cookie сессии - Классическая Cookie сессии ASP
|
Active Server Pages (ASP) - это технология Microsoft на стороне сервера. При выборе этой опции ADC будет поддерживать постоянство сеанса на одном и том же сервере, если ASP cookie будет обнаружен и найден в его списке известных cookie. При обнаружении нового файла cookie ASP нагрузка будет сбалансирована с использованием алгоритма наименьших подключений.
|
Cookie сессии - ASP.NET Cookie сессии
|
Этот режим применяется к ASP.net. При выборе этого режима ADC будет поддерживать постоянство сессии на одном и том же сервере, если куки ASP.NET обнаружены и найдены в его списке известных куки. При обнаружении нового куки ASP, нагрузка будет сбалансирована с использованием алгоритма наименьших подключений.
|
Cookie сессии - Cookie сессии JSP
|
Java Server Pages (JSP) - это серверная технология Oracle. При выборе этого режима ADC будет поддерживать постоянство сеанса на одном и том же сервере, если куки JSP будут обнаружены и найдены в списке известных куки. При обнаружении нового JSP cookie, нагрузка будет сбалансирована с использованием алгоритма наименьших соединений.
|
Cookie сессии - JAX-WS Cookie сессии
|
Веб-сервисы Java (JAX-WS) - это технология Oracle на стороне сервера. При выборе этого режима АЦП будет поддерживать постоянство сеанса на одном и том же сервере, если куки JAX-WS будут обнаружены и найдены в его списке известных куки. При обнаружении нового куки-файла JAX-WS, нагрузка будет сбалансирована с использованием алгоритма наименьших подключений.
|
Cookie сессии - PHP Cookie сессии
|
Personal Home Page (PHP) - это технология с открытым исходным кодом на стороне сервера. При выборе этого режима АЦП будет поддерживать постоянство сессии на одном и том же сервере при обнаружении куки PHP.
|
Сессионный куки - постоянство куки 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
|
В этом режиме АЦП посылает эхо-запрос ICMP на IP-адрес сервера контента. Если получен правильный эхо-ответ, ADC считает, что реальный сервер работает, и пропускная способность трафика к серверу продолжается. Он также будет поддерживать доступность услуги на паре H/A. Этот метод мониторинга можно использовать с любым типом услуги.
|
TCP-соединение
|
В этом режиме устанавливается TCP-соединение с реальным сервером и сразу же разрывается без отправки каких-либо данных. Если соединение успешно установлено, АЦП считает, что Реальный сервер работает. Этот метод мониторинга можно использовать с любым типом сервиса. Только службы 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 считает Реальный сервер недоступным. Этот метод мониторинга действителен только для использования с типами служб HTTP и ускоренного HTTP. Если для HTTP-сервера используется тип сервиса 4-го уровня, он может использоваться, если SSL не используется на реальном сервере или обрабатывается соответствующим образом с помощью средства "Content SSL".
|
DICOM
|
TCP-соединение инициализируется с Real Server в режиме DICOM, и Echoscu "Associate Request" выполняется на Real Server при подключении. Разговор, включающий "Associate Accept" от сервера содержимого, передачу небольшого количества данных, за которым следует "Release Request", а затем "Release Response", успешно завершает монитор. Если по какой-либо причине монитор не завершается успешно, то Реальный сервер считается отключенным.
|
Определяется пользователем
|
Любой монитор, настроенный в разделе Мониторинг реального сервера, появится в списке.
|
Вариант
|
Описание
|
Ведущий
|
Кэширование на хост основано на приложении на имя хоста. Для каждого домена/имени хоста будет существовать отдельный кэш. Этот режим идеально подходит для веб-серверов, которые могут обслуживать несколько веб-сайтов в зависимости от домена.
|
Виртуальной службой
|
Кэширование для каждой виртуальной службы доступно при выборе этой опции. Только один кэш будет существовать для всех доменов/хост-имен, которые проходят через виртуальную службу. Эта опция является специализированной настройкой для использования с несколькими клонами одного сайта.
|
Вариант
|
Описание
|
На сайте
|
Отключите сжатие для виртуальной службы
|
Компрессия
|
Когда эта опция выбрана, она включает сжатие для выбранной Виртуальной службы. АЦП динамически сжимает поток данных, передаваемый клиенту по запросу. Этот процесс применяется только к объектам, содержащим заголовок content-encoding: gzip. Пример содержимого включает HTML, CSS или Javascript. Вы также можете исключить определенные типы контента, используя раздел Глобальные исключения.
|
Вариант
|
Описание
|
Нет SSL
|
Трафик от источника к АЦП не шифруется.
|
Все
|
Загружает все доступные сертификаты для использования
|
По умолчанию
|
Эта опция приводит к применению локально созданного сертификата под названием "Default" на стороне канала браузера. Используйте эту опцию для тестирования SSL, если сертификат не был создан или импортирован.
|
AnyUseCert
|
Используйте любой сертификат, имеющийся на АЦП, который пользователь загрузил или сгенерировал
|
Вариант
|
Описание
|
Нет SSL
|
Трафик от АЦП к Реальному серверу не шифруется. Выбор сертификата на стороне браузера означает, что "No SSL" может быть выбран на стороне клиента для обеспечения того, что известно как "SSL Offload".
|
Любой
|
ADC действует как клиент и примет любой сертификат, который представит Real Server. Трафик от АЦП к Реальному серверу шифруется, когда выбрана эта опция. Используйте опцию "Любой", когда сертификат указан на стороне Виртуальной службы, обеспечивая так называемое "SSL Bridging" или "SSL Re-Encryption".
|
SNI
|
ADC действует как клиент и примет любой сертификат, который представит Real Server. Трафик от АЦП к Реальному серверу шифруется, если выбрана эта опция. Используйте опцию "Любой", когда сертификат указан на стороне Виртуальной службы, обеспечивая так называемое "SSL Bridging" или "SSL Re-Encryption". Выберите эту опцию, чтобы включить SNI на стороне сервера.
|
AnyUseCert
|
Здесь отображаются любые сертификаты, которые Вы создали или импортировали в ADC.
|
Вариант
|
Описание
|
Обратный прокси-сервер
|
Обратный прокси является значением по умолчанию и работает на Layer7 со сжатием и кэшированием. И на Уровне 4 без кэширования и сжатия. В этом режиме Ваш ADC действует как обратный прокси и становится адресом источника, который видят реальные серверы.
|
Прямой возврат сервера
|
Прямой возврат сервера или DSR, как он широко известен (DR - Direct Routing в некоторых кругах), позволяет серверу за балансировщиком нагрузки отвечать клиенту напрямую, минуя ADC при ответе. DSR подходит только для использования с балансировкой нагрузки 4-го уровня. Поэтому кэширование и сжатие недоступны при выборе этой опции.
Балансировка нагрузки на уровне 7 не работает с этим DSR. Также нет поддержки постоянства, кроме IP List Based. SSL/TLS балансировка нагрузки с помощью этого метода не идеальна, так как поддержка Source IP persistence является единственным доступным типом. DSR также требует изменений Реального сервера. Пожалуйста, обратитесь к разделу Изменения реального сервера.
|
Шлюз
|
Режим шлюза позволяет Вам направлять весь трафик через ADC, позволяя трафику от Real Servers направляться через ADC в другие сети через виртуальные машины ADC или аппаратные интерфейсы. Использование устройства в качестве шлюза для Real Servers идеально при работе в многоинтерфейсном режиме.
Балансировка нагрузки на уровне 7 с помощью этого метода не работает, так как нет поддержки постоянства, кроме как на основе IP-списка. Этот метод требует, чтобы Real Server установил свой шлюз по умолчанию на локальный адрес интерфейса (eth0, eth1 и т.д.) ADC. Пожалуйста, обратитесь к разделу Изменения реального сервера.
Обратите внимание, что режим шлюза не поддерживает обход отказа в кластерной среде.
|