Проверка работы CCS со стороны внешнего клиента

И, наконец, пора проверить, как работает вся система. Для этого воспользуемся программой dig, с помощью которой сформируем DNS-запросы к адресам VIP:

# Проверка работы DNS cache для внешних доменов

DIG +SHORT @10.40.12.195  GOOGLE.COM

64.233.167.99

72.14.207.99

64.233.187.99

# Проверка работы DNS cache для доменов обслуживаемых MyDNS

DIG +SHORT @66.66.66.195  HOST.EXAMPLE.COM

66.66.66.5

Проверим балансировку. Теперь можно подключить первый сервер обратно в сеть и проверить балансировку запросов между серверами. Для генерации запросов к DNS‑серверов можно переключить локальных пользователей DNS на использование адреса VIP 10.40.12.195. Или можно запустить следующую команду:

WATCH -N 1 'DIG +SHORT @10.40.12.195  GOOGLE.COM'

Эта команда будет формировать запрос к нашей системе один раз в секунду. После этого можно выждать некоторое время и проверить, как работает балансировка на активном CCS с помощью команды «show summary»:

sh summary

CONTENT RULES    STATE   SERVICES    SERVICE HITS

DNS              ACTIVE  DNS1        0

                         DNS2        0

dns-cache        Active  dns1-cache  100

                         dns2-cache  101

У меня после 4 часов работы такой системы в качестве DNS, обслуживающего локальную сеть, соотношение обслуженных запросов к сервисам dns1-cache и dns2-cache составило 22315/22316, т.е. разбалансировка была менее 0.0001%.

Балансировка других служб

Балансировка таких сервисов, как POP3, MySQL, FTP и HTTPD, выполняются аналогично, только с той разницей, что используются другие номера портов и соответствующие протоколы (TCP или UDP).

В случае необходимости привязать клиента к конкретному серверу в кластере (например, используются сессии при работе с приложениями под управлением сервера HTTPD или для доступа к серверам MySQL/FTP/POP3), можно воспользоваться опцией «advanced-balance sticky-srcip», которая применяется в секции «content».

Пример такой конфигурации может выглядеть следующим образом:

CONTENT HTTPD.EXAMPLE.COM

# Адрес VIP, на который приходят запросы

vip address 66.66.66.195

    PROTOCOL TCP

    PORT 80

advanced-balance sticky-srcip

add service www1

add service www2

    active

Cisco Content Switch содержит специальную таблицу, где находятся пары «Source IP» и «Destination IP». Эта таблица управляется по принципу FIFO (First In, First Out). Максимальное количество элементов в таблице – от 32 до 128 тысяч. Таким образом «устаревшие» привязки клиентов к серверам будут удалены по мере появления новых записей. Я советую использовать опцию «sticky-inact-timeout», которая указывает, что по истечении интервала, указанного в этой опции (в минутах), необходимо удалять записи, возраст которых превышает этот параметр. И, соответственно, время сессий на серверах (httpd, mysqld, ftpd) должны быть короче этого интервала.