 |
|
|
|
Создание и балансировка отказоустойчивых служб с помощью Cisco Content Switch
Создание и балансировка отказоустойчивых служб с помощью Cisco Content Switch Как построить отказоустойчивый сервис? Можно вбух... вложить крупную сумму в супер-сервер с функцией «горячей» замены процессоров, памяти, блоков питания и т. д., а затем молиться на этот сервер. Убедившись, что молитва все-таки не помогла, перейти к кластерному решению из недорогих компонентов. Предлагаем вам начать сразу со второго варианта и построить недорогой отказоустойчивый сервис с использованием Cisco Content Switch (CCS). Итак, для начала немного о ситуации с которой я столкнулся и которая, наверное, знакома большинству системных администраторов. В нашей компании используются два выделенных DNS-сервера, на каждом из которых установлено два типа DNS-демонов – MyDNS (порядка 10 000 доменов и 2 000 000 записей) для обслуживания запросов, приходящих из Интернета, и DNS cache для обслуживания запросов серверов, расположенных внутри корпоративной сети. И хотя такое решение являлось достаточно стабильным, но существовал ряд проблем:
Одно время я попытался обратиться к проекту Linux-HA (The High Availability Linux Project), но такие ограничения, как отсутствие балансировки, сложная структура при использовании более двух серверов, большое время переключения (порядка 5-7 секунд) на запасной сервер, не позволили использовать этот проект для устранения вышеописанных проблем. После некоторого исследования был обнаружен замечательный продукт Cisco Content Switch (CCS), который позволил реализовать следующие очень важные функции:
Аппаратное обеспечение Семейство Cisco Content Switch включает в себя различные модели, начиная от простейших моделей типа Cisco CCS 11000 до высокопроизводительных Cisco CSS 11506 с полным дублированием всех подсистем (см. таблицу). В моем случае скорость потока к серверам DNS составляла порядка 10 Мбит/c, поэтому я остановился на CCS 11000. Сравнительные характеристики различных моделей CCS
* Модульная структура. Каждый модуль включает в себя 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:
Конфигурация 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 Тестирование Тестирование включает в себя три этапа:
Проверка работы виртуальных маршрутизаторов Как уже упоминалось, в нашей системе сконфигурированы два виртуальных маршрутизатора, состояние которых можно проверить с помощью команды «show virtual-routers», выполненной на каждом CCS. Приблизительные результаты работы этой команды приведены ниже: Состояние виртуальных маршрутизаторов на CCS1:
Состояние виртуальных маршрутизаторов на CCS2:
Также необходимо проверить механизм переключения с основного CCS на запасной в случае аварии. Для этого отключаем CCS1 от сети и, выждав 2-3 секунды, проверяем опять состояние маршрутизатора на CCS2:
Как можно убедиться, состояние виртуальных маршрутизаторов поменялось с «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». Если не указано имя конкретного сервиса, то будут показаны все сервисы. Для простоты приведу пример результатов проверки одного из сервисов:
Для проверки, как CCS определяет отказ одного из серверов, просто отключим первый сервер от сети и заново проверим состояние сервисов MyDNS и DNS cache на первом сервере:
Таким образом, мы видим, что CCS исключила сервисы MyDNS и DNS cache, расположенные на сервере dns1, из списка активных, соответственно, дальнейшие запросы будут переадресованы только сервисам на сервере dns2. Однако оба CCS будут продолжать проверять доступность сервисов на сервере dns1, и в случае восстановления работоспособности оба сервиса будут включены в список активных. Проверка работы CCS со стороны внешнего клиента И, наконец, пора проверить, как работает вся система. Для этого воспользуемся программой dig, с помощью которой сформируем DNS-запросы к адресам VIP:
Проверим балансировку. Теперь можно подключить первый сервер обратно в сеть и проверить балансировку запросов между серверами. Для генерации запросов к DNS?серверов можно переключить локальных пользователей DNS на использование адреса VIP 10.40.12.195. Или можно запустить следующую команду: WATCH -N 1 "DIG +SHORT @10.40.12.195 GOOGLE.COM" Эта команда будет формировать запрос к нашей системе один раз в секунду. После этого можно выждать некоторое время и проверить, как работает балансировка на активном CCS с помощью команды «show summary»:
У меня после 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) должны быть короче этого интервала. |
Виталий Банковский
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
