|
|||||
|
|||||
|
|
|||||||
|
|||||||
|
|
Поле
|
Описание
|
|
IP-адрес
|
Введите новый виртуальный IP-адрес, который будет целевой точкой входа для доступа к реальному серверу. Этот IP-адрес будет использоваться пользователями или приложениями для доступа к приложению с балансировкой нагрузки.
|
|
Маска подсети/Префикс
|
Это поле предназначено для маски подсети, относящейся к сети, в которой находится АЦП.
|
|
Порт
|
Порт входа, используемый при доступе к VIP. Это значение не обязательно должно совпадать со значением реального сервера, если вы используете обратный прокси.
|
|
Название услуги
|
Название услуги - это текстовое представление назначения VIP-клиента. Оно необязательно, но мы рекомендуем указать его для ясности.
|
|
Тип услуги
|
Существует множество различных типов услуг, которые вы можете выбрать. Типы услуг уровня 4 не могут использовать технологию flightPATH.
|
|
Поле
|
Описание
|
|
Деятельность
|
Поле Activity можно использовать для отображения и изменения статуса реального сервера с балансировкой нагрузки.
Online - Обозначает, что сервер активен и принимает запросы с балансировкой нагрузки.
Offline - сервер находится в автономном режиме и не принимает запросы.
Drain - сервер был переведен в режим drain, чтобы можно было промыть персистентность и перевести сервер в автономное состояние, не затрагивая пользователей.
Standby - сервер был переведен в состояние ожидания
|
|
IP-адрес
|
Это значение является IP-адресом сервера Real Server. Он должен быть точным и не должен быть адресом DHCP.
|
|
Порт
|
Целевой порт доступа на реальном сервере. При использовании обратного прокси он может отличаться от порта входа, указанного на VIP.
|
|
Взвешивание
|
Эта настройка обычно автоматически конфигурируется АЦП. Вы можете изменить его, если хотите изменить взвешивание приоритетов.
|
|
Вариант
|
Описание
|
|
Кластер
|
Кластер - это роль по умолчанию для ADC при установке, а в столбце Primary/Mode указывается режим, в котором он работает в настоящее время. Если в вашем центре данных есть HA пара устройств ADC, одно из них будет показывать 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
|
TCP/UDP
|
Уровень 4
|
Используется для балансировки нагрузки 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.
|
|
Слив
|
Все реальные серверы, назначенные как Drain, будут продолжать обслуживать существующие соединения, но не будут принимать новые соединения. Индикатор состояния будет мигать зеленым/синим цветом, пока идет процесс слива. После естественного закрытия существующих соединений реальные серверы перейдут в автономный режим, а индикатор состояния будет гореть синим цветом. Вы также можете просмотреть эти соединения, перейдя в раздел Навигация > Монитор > Статус.
|
|
Offline
|
Все реальные серверы, установленные как Offline, будут немедленно переведены в автономный режим и не будут получать трафик.
|
|
В режиме ожидания
|
Все реальные серверы, установленные как резервные, будут оставаться в автономном режиме до тех пор, пока ВСЕ серверы группы Online не пройдут проверку Server Health Monitor. Трафик будет приниматься резервной группой в соответствии с политикой балансировки нагрузки, когда это произойдет. Если один сервер в группе Online пройдет проверку Server Health Monitor, этот сервер Online получит весь трафик, а группа Standby перестанет получать трафик.
|
|
Вариант
|
Описание
|
|
Самый быстрый
|
Политика балансировки нагрузки Fastest автоматически рассчитывает время ответа на все запросы для каждого сервера, сглаженное по времени. В столбце Рассчитанный вес содержится автоматически рассчитанное значение. Ручной ввод возможен только при использовании этой политики балансировки нагрузки.
|
|
Раунд Робин
|
Round Robin обычно используется в брандмауэрах и базовых балансировщиках нагрузки и является самым простым методом. Каждый реальный сервер получает новый запрос по порядку. Этот метод подходит только тогда, когда вам нужно равномерно распределить нагрузку запросов на серверы; примером могут служить поисковые веб-серверы. Однако, когда вам нужно сбалансировать нагрузку на основе нагрузки приложения или нагрузки сервера, или даже обеспечить использование одного и того же сервера для сессии, метод Round Robin неуместен.
|
|
Наименьшие связи
|
Балансировщик нагрузки будет отслеживать количество текущих подключений к каждому Real Server. Сервер Real Server с наименьшим количеством соединений получает последующий новый запрос.
|
|
IP Bound
Layer 3 Session Affinity/Persistence
|
В этом режиме IP-адрес клиента является основой для выбора сервера Real Server, который получит запрос. Это действие обеспечивает постоянство. HTTP и протоколы четвертого уровня могут использовать этот режим. Этот метод полезен для внутренних сетей, где топология сети известна, и вы можете быть уверены, что нет "суперпрокси" выше по течению. При использовании Layer 4 и прокси-серверов все запросы могут выглядеть так, как будто они исходят от одного клиента, и поэтому нагрузка будет неравномерной. В HTTP информация заголовка (X-Forwarder-For) используется при наличии, чтобы справиться с прокси.
|
|
На основе списка IP-адресов
Layer 3 Session Affinity/Persistence
|
Соединение с Real Server инициируется с использованием "Наименьшего количества соединений", затем на основе IP-адреса клиента достигается привязка к сеансу. По умолчанию список ведется в течение 2 часов, но его можно изменить с помощью jetPACK.
|
|
Cookie сессии
Уровень 7 Принадлежность/постоянство сеанса
|
Этот режим является наиболее популярным методом сохранения балансировки нагрузки HTTP. В этом режиме ADC использует балансировку нагрузки на основе списка IP для каждого первого запроса. Он вставляет cookie в заголовки первого HTTP-ответа. После этого ADC использует cookie клиента для маршрутизации трафика на один и тот же внутренний сервер. Этот файл cookie используется для постоянства, когда клиенту необходимо каждый раз обращаться к одному и тому же внутреннему серверу. Срок действия куки истекает после закрытия сессии.
|
|
Постоянный файл cookie
Уровень 7 Принадлежность/постоянство сеанса
|
Режим балансировки нагрузки на основе списка IP используется для каждого первого запроса. ADC вставляет cookie в заголовки первого HTTP-ответа. После этого ADC использует cookie клиента для маршрутизации трафика на один и тот же внутренний сервер. Этот файл cookie используется для сохранения информации, когда клиент должен каждый раз обращаться к одному и тому же внутреннему серверу. Срок действия cookie истекает через 2 часа, и соединение будет сбалансировано по нагрузке в соответствии с алгоритмом, основанным на списке IP-адресов. Это время истечения срока действия настраивается с помощью jetPACK.
|
|
Куки сеанса - Классический куки сеанса ASP
|
Active Server Pages (ASP) - это технология Microsoft на стороне сервера. При выборе этой опции ADC будет поддерживать постоянство сеанса на одном и том же сервере, если куки ASP обнаружены и находятся в списке известных куки. При обнаружении нового файла cookie ASP нагрузка будет сбалансирована с использованием алгоритма наименьших подключений.
|
|
Cookie сеанса - ASP.NET Cookie сеанса
|
Этот режим применяется к ASP.net. При выборе этого режима ADC будет поддерживать постоянство сеанса на одном и том же сервере, если куки ASP.NET обнаружены и находятся в его списке известных куки. При обнаружении нового файла cookie ASP нагрузка будет сбалансирована с использованием алгоритма наименьших подключений.
|
|
Cookie сеанса - Cookie сеанса JSP
|
Java Server Pages (JSP) - это серверная технология Oracle. При выборе этого режима ADC будет поддерживать постоянство сеанса на одном и том же сервере, если куки JSP будут обнаружены и найдены в списке известных куки. При обнаружении нового файла cookie JSP нагрузка на него будет сбалансирована с использованием алгоритма наименьших подключений.
|
|
Cookie сессии - JAX-WS Cookie сессии
|
Веб-службы Java (JAX-WS) - это технология Oracle для сервера. При выборе этого режима ADC будет поддерживать постоянство сеанса на одном и том же сервере, если куки JAX-WS обнаружены и находятся в его списке известных куки. При обнаружении нового файла cookie JAX-WS нагрузка будет сбалансирована с использованием алгоритма наименьших подключений.
|
|
Cookie сессии - PHP Cookie сессии
|
Personal Home Page (PHP) - это технология с открытым исходным кодом на стороне сервера. При выборе этого режима ADC будет поддерживать постоянство сеанса на одном и том же сервере при обнаружении куки 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 и совпадает с одним из идентификаторов реального сервера, следует выбрать этот сервер; в противном случае используйте следующий метод (делегирование).
|
|
Список общих IP-адресов
|
Этот тип службы доступен только в том случае, если для параметра Connectivity Mode установлено значение Gateway или Direct Server Return. Он был добавлен в основном для поддержки балансировки нагрузки VMware.
|
|
Вариант
|
Описание
|
|
Нет
|
В этом режиме мониторинг реального сервера не ведется, и он всегда работает правильно. Настройка None полезна в ситуациях, когда мониторинг расстраивает сервер, а также для служб, которые не должны участвовать в отказоустойчивом действии ADC. Это маршрут для размещения ненадежных или устаревших систем, которые не являются основными для операций H/A. Используйте этот метод мониторинга с любым типом службы.
|
|
Ping/ICMP Echo
|
В этом режиме ADC отправляет эхо-запрос ICMP на IP-адрес сервера контента. Если получен правильный эхо-ответ, ADC считает, что реальный сервер работает, и пропускная способность трафика к серверу продолжается. Он также будет поддерживать доступность услуги на паре 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 помечает реальный сервер как недоступный. Этот метод мониторинга действителен только для использования с типами служб HTTP и ускоренного HTTP. Если для HTTP-сервера используется тип службы уровня 4, он может использоваться, если SSL не используется на реальном сервере или обрабатывается соответствующим образом с помощью средства "Content SSL".
|
|
DICOM
|
TCP-соединение инициализируется с Real Server в режиме DICOM, и при подключении к Real Server выполняется "Associate Request" от Echoscu. Общение, включающее "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.
|
|
Вариант
|
Описание
|
|
Обратный прокси-сервер
|
Reverse Proxy - значение по умолчанию, работает на Layer7 со сжатием и кэшированием. И на уровне Layer4 без кэширования и сжатия. В этом режиме ваш ADC действует как обратный прокси и становится адресом источника, который видят реальные серверы.
|
|
Прямой возврат сервера
|
Прямой возврат сервера или DSR, как он широко известен (DR - Direct Routing в некоторых кругах), позволяет серверу за балансировщиком нагрузки отвечать клиенту напрямую, минуя ADC при ответе. DSR подходит только для использования с балансировкой нагрузки 4-го уровня. Поэтому кэширование и сжатие недоступны при выборе этой опции.
Этот режим можно использовать только с типами услуг TCP, UDP и TCP/UDP.
Балансировка нагрузки на уровне 7 не работает с этим DSR. Также нет поддержки постоянства, кроме IP List Based. SSL/TLS балансировка нагрузки с помощью этого метода не идеальна, так как поддержка Source IP persistence является единственным доступным типом. DSR также требует изменений реального сервера. Пожалуйста, обратитесь к разделу Изменения реального сервера.
|
|
Шлюз
|
Режим шлюза позволяет направлять весь трафик через ADC, позволяя направлять Real Servers через ADC в другие сети через виртуальные машины ADC или аппаратные интерфейсы. Использование устройства в качестве шлюза для Real Servers идеально при работе в многоинтерфейсном режиме.
Балансировка нагрузки на уровне 7 с помощью этого метода не работает, так как нет поддержки постоянства, кроме IP List Based. Этот метод требует, чтобы Real Server установил свой шлюз по умолчанию на адрес локального интерфейса ADC (eth0, eth1 и т.д.). Обратитесь к разделу Изменения реального сервера.
Обратите внимание, что режим шлюза не поддерживает обход отказа в кластерной среде.
|
