Создание и балансировка отказоустойчивых служб с помощью Cisco Content Switch

Виталий Банковский

Создание и балансировка отказоустойчивых служб с помощью Cisco Content Switch

Как построить отказоустойчивый сервис? Можно вбух... вложить крупную сумму в супер-сервер с функцией «горячей» замены процессоров, памяти, блоков питания и т. д., а затем молиться на этот сервер. Убедившись, что молитва все-таки не помогла, перейти к кластерному решению из недорогих компонентов.  Предлагаем вам начать сразу со второго варианта и построить недорогой отказоустойчивый сервис с использованием Cisco Content Switch (CCS).

Итак, для начала немного о ситуации с которой я столкнулся и которая, наверное, знакома большинству системных администраторов.

В нашей компании используются два выделенных DNS-сервера, на каждом из которых установлено два типа DNS-демонов – MyDNS (порядка 10 000 доменов и 2 000 000 записей) для обслуживания запросов, приходящих из Интернета, и DNS cache для обслуживания запросов серверов, расположенных внутри корпоративной сети.

И хотя такое решение являлось достаточно стабильным, но существовал ряд проблем:

• Отсутствие балансировки. Несмотря на то что в корневых серверах DNS зарегистрированы оба DNS-сервера, соотношение запросов к первому и ко второму DNS составляло около 90/10.
• Так как первичный сервер DNS cache был указан первым на всех серверах в файле resolv.conf, то он же и обслуживал все 100% запросов, приходящих из локальной сети (для клиентов, не поддерживающих ротацию серверов DNS в resolv.conf).
• Замедление обслуживания в случае отказа одного из серверов. Из-за того, что вся система DNS построена на протоколе UDP, клиенты вынуждены ожидать стандартное время перед обращением к следующему серверу, что вызывает сильное замедление ответов сервисов.
• В случае отказа первого сервера с DNS cache многие службы (основанные на проколах POP, FTP, SMTP), использующие обратное преобразование адреса IP в доменное имя, отвечают клиентам с большой задержкой. И это также вызывает шквал сообщений от систем мониторинга из-за превышения времени ожидания (timeout).
• Невозможность указания более трех серверов DNS для многих служб, использующих DNS, что может быть серьезным ограничением для высоконагруженных сетей.

Одно время я попытался обратиться к проекту Linux-HA (The High Availability Linux Project), но такие ограничения, как отсутствие балансировки, сложная структура при использовании более двух серверов, большое время переключения (порядка 5-7 секунд) на запасной сервер, не позволили использовать этот проект для устранения вышеописанных проблем.

После некоторого исследования был обнаружен замечательный продукт Cisco Content Switch (CCS), который позволил реализовать следующие очень важные функции:

• Балансировку нагрузки.
• Обнаружение отказа одного из серверов и исключение его из списка используемых.
• Построение «виртуального» маршрутизатора. Если установлено два и более CCS, то в случае выхода одного из них клиенты прозрачно переключаются на запасной CCS.
• Возможность использования более трех серверов DNS.

Аппаратное обеспечение

Семейство Cisco Content Switch включает в себя различные модели, начиная от простейших моделей типа Cisco CCS 11000 до высокопроизводительных Cisco CSS 11506 с полным дублированием всех подсистем (см. таблицу). В моем случае скорость потока к серверам DNS составляла порядка 10 Мбит/c, поэтому я остановился на CCS 11000.

Сравнительные характеристики различных моделей CCS

	CCS 11000	WS-X6066-SLB-APC	CSS11501	CSS11503	CSS11506
Производительность (Гбит/с)	4	4	6	20	40
Количество портов 10/100 Ethernet	8	Встраивается в шасси Cisco 6500	8*	32*	80*
Количество портов 1000 Ethernet	2	–	2*	6*	12*
Дублирование подсистем	Нет	Требуется два модуля	Нет	Нет	Да
Стоимость на вторичном рынке ($, US)	300	13 000	4 000	6 000	14 000

* Модульная структура. Каждый модуль включает в себя 8 10/100 Ethernet или 2 1000 Ethernet-портов.

Здесь стоило бы указать причины, почему я привел цены для б/у оборудования Cisco.

В электронных устройствах одним из основных компонентов, который влияет на долговечность, является конденсатор. Ведущие производители сетевого оборудования применяют танталовые конденсаторы, которые в отличие от электролитических не подвержены процессу высыхания. Благодаря этому устройства Cisco работают годами даже в «тяжелых условиях».

Второй причиной, которая подвигнула меня на использование б/у устройств, является поддержка технологии «Виртуальный маршрутизатор». Цена на б/у устройства Cisco составляет около 10-40% от оригинальной стоимости, что дало мне возможность установить большее количество CCS при сохранении конечной стоимости решения при одновременном увеличении количества «запасных» CCS.

Избыточность и VRRP

Протокол VRRP – проприетарный протокол компании Cisco Systems, Inc., позволяющий образовывать так называемый «виртуальный» маршрутизатор из устройств, поддерживающих этот протокол. В каждом таком устройстве создается виртуальный интерфейс виртуального маршрутизатора с адресом VIP (виртуальный IP-адрес – VIP address) , и все виртуальные интерфейсы физических устройств объединяются в виртуальный маршрутизатор. Адрес VIP является одинаковым для всех интерфейсов, входящих в виртуальный маршрутизатор, и клиенты, обращающиеся к этой системе, запрашивают этот адрес.

При запуске такой системы выбирается физический маршрутизатор со старшим IP-адресом, который и становится активным маршрутизатором. При выходе из строя активного маршрутизатора один из запасных маршрутизаторов переходит в активное состояние, и клиенты продолжают использовать адрес VIP, расположенный на активном CCS.

Структура сети

Для примера я приведу структуру свой сети, состоящей из двух серверов DNS – dns1 и dns2, и двух Cisco CCS 11000 (см. рисунок).

Схема подключения серверов и CCS к локальной сети

Были созданы два виртуальных маршрутизатора, с двумя адресами VIP в каждом из них. Первый адрес VIP используется для запросов, приходящих из Интернета, второй – для обслуживания запросов, приходящих от серверов, расположенных в локальной сети.

Здесь нужно обратить внимание, что CCS производит трансляцию адресов (NAT), и необходимо, чтобы ответ от серверов DNS приходил обратно на CCS (а не на инициатора запроса).

По этой причине адрес VIP 66.66.66.195 (на который приходят запросы из Интернета) является маршрутом по умолчанию для серверов dns1 и dns2. И аналогично, адрес VIP 10.40.12.195 (на который приходят запросы из локальной сети) является маршрутом для серверов dns1 и dns2 для ответов на запросы из локальной сети.

Примечание. Virtual router 1 обрабатывает запросы, приходящие из Интернета. Virtual router 2 обрабатывает запросы, приходящие из локальной сети.

Теперь разберем, как работает такая схема на примере виртуального маршрутизатора №2:

• При запуске системы маршрутизатор CCS2 становится мастером как имеющий старший адрес.
• Каждые несколько секунд оба CCS проверяют работоспособность демонов MyDNS и DNS cache на каждом из серверов, на основании чего составляется список активных сервисов.
• Наш сервер DNS зарегистрирован в корневых серверах DNS по IP-адресу 66.66.66.195. При получении запроса извне на адрес 66.66.66.195 CSS переадресовывает этот запрос на один из серверов DNS (из списка активных).
• Этот сервер отсылает ответ на адрес 66.66.66.195, CCS заменяет IP-адрес в ответе на адрес 66.66.66.195 и пересылает ответ запрашивающей стороне, находящейся в Интернете.

Конфигурация Cisco Content Switch

В этом разделе приведен пример конфигурации обоих CCS для создания виртуальных маршрутизаторов, служб и описание серверов dns1 и dns2:

# Маршрут по умолчанию

ip route 0.0.0.0 0.0.0.0 66.66.66.193 1

# Физический интерфейс CCS, который подключен к коммутатору

# локальной сети и привязан к виртуальному интерфейсу

# circuit VLAN3

interface ethernet-13

  bridge vlan 3

# Виртуальный интерфейс, на котором определены наши

# виртуальные маршрутизаторы

circuit VLAN3

    # Локальный адрес виртуального маршрутизатора

    # «Virtual router 1». Служит для обращения

    # к серверам DNS и работы протокола VRRP

    ip address 10.40.12.203 255.255.255.240

    # Идентификатор  виртуального маршрутизатора

    ip virtual-router 1

    # Адрес VIP. К этому адресу обращаются сервера

    # в локальной сети

    ip redundant-interface 1 10.40.12.195

    # *************************************************

    # Аналогично, локальный адрес виртуального

    # маршрутизатора «Virtual router 2».

    ip address 66.66.66.203 255.255.255.240

    # Идентификатор виртуального маршрутизатора

           IP VIRTUAL-ROUTER 2

    # Адрес VIP. К этому адресу обращаются клиенты

    # из Интернета

           IP REDUNDANT-INTERFACE 2 66.66.66.195

# *************************************************

# Определение правила, по которому будет определяться

# работоспособность серверов DNS. Здесь определены IP-адреса

# обоих демонов (DNS cache и MyDNS) на обоих серверах

# Сервер dns1, демон DNS cache

keepalive dns1-cache

  ip address 10.40.12.196

  active

# Сервер dns1, демон MyDNS

keepalive dns1

  ip address 10.40.12.200

  active

# Сервер dns2, демон dns cache

keepalive dns2-cache

  ip address 10.40.12.197

  active

# Сервер dns2, демон MyDNS

keepalive dns2

  ip address 10.40.12.201

  active

# ***************************************************

# Далее описаны службы MyDNS и DNS cache, к которым

# обращается CCS

service dns1

  protocol udp

  port 53

  ip address 10.40.12.200

  keepalive type named dns1

  active

SERVICE DNS1-CACHE

  keepalive type named dns1-cache

  protocol udp

  port 53

  ip address 10.40.12.196

  active

service dns2

  protocol udp

  port 53

  ip address 10.40.12.201

  keepalive type named dns2

  active

SERVICE DNS2-CACHE

  protocol udp

  port 53

  ip address 10.40.12.197

  keepalive type named dns2-cache

  active

#******************************************************

# Следующая секция – определение правил, которые используются

# для обработки  запросов, приходящих на CCS.

# Имя владельца сервиса

OWNER EXAMPLE

  # Разрешить прием и отправку DNS-запросов

  dns both

    # Определение сервиса. В данном случае – сервис DNS

    # для обработки запросов извне

    CONTENT DNS

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

           vip address 66.66.66.195

                 PROTOCOL UDP

                 port 53

           # Добавить сервисы dns1 и dns2 как один

           # из доступных сервисов

           add service dns2

           add service dns1

                 active

           # Определение сервиса для обработки

           # запросов, приходящих из локальной сети

           CONTENT DNS-CACHE

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

           vip address 10.40.12.195

                 PROTOCOL UDP

                 PORT 53

           # Добавление сервисов mdns1-cache и mdns2-cache

           add service dns1-cache

                 ADD SERVICE DNS2-CACHE

                 active

# Включение трансляции адресов для прокотола UDP

GROUP DNS

  vip address 66.66.66.195

  add service dns1

  add service dns2

  active

GROUP DNS-CACHE

  vip address 10.40.12.195

  add service dns1-cache

  add service dns2-cache

  active

Конфигурация второго CCS аналогична, только локальные адреса на виртуальных интерфейсах отличны от первого CCS:

circuit VLAN3

    ip address 10.40.12.204 255.255.255.240

           ip virtual-router 1

           ip redundant-interface 1 10.40.12.195

    ip address 66.66.66.204 255.255.255.240

           ip virtual-router 2

           ip redundant-interface 2 66.66.66.195

Тестирование

Тестирование включает в себя три этапа:

• Проверка работы виртуальных маршрутизаторов.
• Проверка работоспособности сервисов DNS со стороны CCS.
• Проверка работы CCS со стороны внешнего клиента.
• Проверка балансировки сервисов.

Проверка работы виртуальных маршрутизаторов

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

Состояние виртуальных маршрутизаторов на CCS1:

Interface Address: 10.40.12.203      VRID: 1   STATE:         MASTER       MASTER IP:         10.40.12.203  STATE CHANGES: 3           INTERFACE ADDRESS: 66.66.66.203    VRID: 2   STATE:         MASTER       MASTER IP:         66.66.66.203  STATE CHANGES: 3            LAST CHANGE:       09/06/2007

Состояние виртуальных маршрутизаторов на CCS2:

Interface Address: 10.40.12.204      VRID: 1   STATE:         BACKUP       MASTER IP:         10.40.12.203  STATE CHANGES: 2            LAST CHANGE:       09/09/2007   Interface Address: 66.66.66.204    VRID: 2  STATE:         BACKUP       MASTER IP:         66.66.66.203  STATE CHANGES: 2            LAST CHANGE:       09/06/2007

Также необходимо проверить механизм переключения с основного CCS на запасной в случае аварии. Для этого отключаем CCS1 от сети и, выждав 2-3 секунды, проверяем опять состояние маршрутизатора на CCS2:

sh virtual-routers Interface Address: 10.40.12.204      VRID: 2   Priority:      100          Config. Priority:  100  State:         Master       Master IP:         10.40.12.204  State Changes: 3            Last Change:              Interface Address: 66.66.66.204      VRID: 1   Priority:      100          Config. Priority:  100  State:         Master       Master IP:         66.66.66.204  State Changes: 3            Last Change:

Как можно убедиться, состояние виртуальных маршрутизаторов поменялось с «Backup» на «Master» и адреса ведущих маршрутизаторов поменялись с 10.40.12.203 на 10.40.12.204 и с 66.66.66.203 на 66.66.66.204.

Проверка работоспособности сервисов DNS со стороны CCS

Для проверки работоспособности демонов DNS на серверах dns1 и dns2 нужно воспользоваться командой «show service». Если не указано имя конкретного сервиса, то будут показаны все сервисы. Для простоты приведу пример результатов проверки одного из сервисов:

show service dns1 Name: dns1             Index: 10    Type: Local            State: Alive RULE ( 10.40.12.200 UDP  53 ) REDIRECT DOMAIN:  REDIRECT STRING:  KEEPALIVE: DNS1 MTU:               1500        STATE TRANSITIONS:  0 CONNECTIONS:       0           MAX CONNECTIONS:    0 TOTAL CONNECTIONS: 0           TOTAL REUSED CONNS: 0 WEIGHT:            1           LOAD:               2

Для проверки, как CCS определяет отказ одного из серверов, просто отключим первый сервер от сети и заново проверим состояние сервисов MyDNS и DNS cache на первом сервере:

show service dns1 NAME: DNS1             INDEX: 10    TYPE: LOCAL            STATE: DOWN RULE ( 10.40.12.200 UDP  53 ) REDIRECT DOMAIN:  REDIRECT STRING:  KEEPALIVE: DNS1 MTU:               1500        STATE TRANSITIONS:  0 CONNECTIONS:       0           MAX CONNECTIONS:    0 TOTAL CONNECTIONS: 0           TOTAL REUSED CONNS: 0 WEIGHT:            1           LOAD:               2

show service dns1-cache NAME: DNS1-CACHE       INDEX: 11    TYPE: LOCAL           STATE: DOWN RULE ( 10.40.12.196 UDP  53 ) REDIRECT DOMAIN:  REDIRECT STRING:  KEEPALIVE: DNS1-CACHE MTU:               1500        STATE TRANSITIONS:  0 CONNECTIONS:       0           MAX CONNECTIONS:    0 TOTAL CONNECTIONS: 0           TOTAL REUSED CONNS: 0 WEIGHT:            1           LOAD:               2

Таким образом, мы видим, что CCS исключила сервисы MyDNS и DNS cache, расположенные на сервере dns1, из списка активных, соответственно, дальнейшие запросы будут переадресованы только сервисам на сервере dns2. Однако оба CCS будут продолжать проверять доступность сервисов на сервере dns1, и в случае восстановления работоспособности оба сервиса будут включены в список активных.

Проверка работы 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) должны быть короче этого интервала.

1. http://cr.yp.to/djbdns.html.
2. http://cisco.com.
3. http://mydns.bboy.net.