Вы находитесь на странице: 1из 24
Схемы резервирования MVTS Руководство пользователя © MERA.ru 2007

Схемы резервирования MVTS

Руководство пользователя

пограничный контроллер соединений MVTS

Обеспечение отказоустойчивости системы

Документ :

1

Тип документа:

Руководство пользователя

Статус документа:

Version 2.0.0

Дата выпуска:

15.08.2007

Ответственное лицо:

Технический писатель

Copyright © 2007 MERA.ru. All rights reserved.

MERA.ru оставляет за собой право вносить изменения в содержащуюся в данном документе информацию без предварительного уведомления.

ИНФОРМАЦИЯ О ПРАВЕ СОБСТВЕННОСТИ

Информация, содержащаяся в данном документе, является собственностью MERA.ru. Никакая часть этого документа не может быть воспроизведена или заимствована в какой бы то ни было форме или каким-либо способом в графическом, электронном виде или механическим путем, включая фотокопирование, запись, в том числе и на магнитные носители или любые другие устройства, предназначенные для хранения информации без письменного разрешения MERA.ru Подобное разрешение не может быть выдано третьей стороной, будь то организация или частное лицо.

История изменений

Дата

Версия

Автор и описание изменений

06.06.2006

Draft

azharkov: изменен рисунок и исправлена таблица для схемы резервирования Привратник – RAS- пользователь.

19.06.2006

Draft

аzharkov: добавлено примечание к главе Схема резервирования с использованием общего IP- адреса’.

15.08.07

Release

тех. писатель: добавлено описание схемы резервирования N+1

Содержание

1 ВВЕДЕНИЕ

6

1.1 АННОТАЦИЯ

6

1.2 АУДИТОРИЯ

6

1.3 ТИПОГРАФСКИЕ СОГЛАШЕНИЯ

6

1.4 СТРУКТУРА ДОКУМЕНТА

6

2 СХЕМЫ РЕЗЕРВИРОВАНИЯ MVTS

7

2.1 ОБЩИЕ СВЕДЕНИЯ

7

2.2 РЕЗЕРВИРОВАНИЕ ПО СХЕМЕ «ПРИВРАТНИК RAS-ПОЛЬЗОВАТЕЛЬ»

7

2.3 СХЕМА РЕЗЕРВИРОВАНИЯ С ИСПОЛЬЗОВАНИЕМ ОБЩЕГО IP-АДРЕСА

11

2.3.1 Обзор

11

2.3.2 Детали

13

2.4 КОНФИГУРАЦИЯ СЕКЦИИ [REDUNDANCY] НА ОСНОВНОМ И РЕЗЕРВНОМ СЕРВЕРЕ MVTS

15

2.5 СХЕМА РЕЗЕРВИРОВАНИЯ ‘ORDINARY REDUNDANCY

16

2.6 СХЕМА РАСПРЕДЕЛЕНИЯ НАГРУЗКИ В ПЕРЕДЕЛАХ ОДНОЙ ЛИЦЕНЗИИ

17

2.7 СХЕМА РЕЗЕРВИРОВАНИЯ N+1

17

2.7.1 Обзор

17

2.7.2 Детали

18

3 ДОВЕРИТЕЛЬНЫЕ ОТНОШЕНИЯ МЕЖДУ ОСНОВНЫМ И РЕЗЕРВНЫМ СЕРВЕРОМ

23

3.1

СИНХРОНИЗАЦИЯ НАСТРОЕК ОСНОВНОГО И РЕЗЕРВНОГО СЕРВЕРОВ

24

Дополнительная литература

Ссылка

Название документа

[1]

Конфигурирование MVTS

1

ВВЕДЕНИЕ

1.1 АННОТАЦИЯ

В данном документе описываются три основных способа обеспечения отказоустойчивости системы MVTS.

1.2 АУДИТОРИЯ

Настоящее руководство предназначено для системных администраторов и пользователей. В руководстве описываются основные принципы резервирования системы MVTS. Предполагается, что читатели настоящего руководства знакомы с программным коммутатором MVTS и способами его настройки.

1.3 ТИПОГРАФСКИЕ СОГЛАШЕНИЯ

В настоящем документе используются следующие типографские соглашения (см. Таблица 1) .

Таблица 1: Типографские соглашения

Пример

Описание

Примечание:

Важная информация, требующая особого внимания

текст

[N]

Ссылка на другой документ

void

Примеры исходного кода, вывода программ, журналов, конфигурационных файлов и т.п.

Ulimit

Наименования программ и файлов

1.4 СТРУКТУРА ДОКУМЕНТА

Настоящий документ имеет следующую структуру:

Глава 1: Содержит сведения о назначении настоящего документа, его целевой аудитории и используемых типографских соглашениях.

Глава 2: Содержит описание всех способов резервирования системы MVTS.

Глава 3: Описывает способы установки доверительных отношений между основным и резервным серверами для обеспечения синхронизации настроек серверов и удаленного доступа к резервному серверу с правами пользователя root.

2 СХЕМЫ РЕЗЕРВИРОВАНИЯ MVTS

2.1 ОБЩИЕ СВЕДЕНИЯ

Все способы резервирования системы MVTS, описываемые в данном документе, подразумевают использование дополнительного сервера, способного принимать и обрабатывать трафик при выходе основного сервера из строя в течение определенного времени, необходимого для восстановления основного сервера. Обычно это время составляет 24 часа, в течение которых оператору необходимо провести мероприятия по восстановлению работоспособности основной системы (поиск и устранение неисправностей, замена аппаратной части и т.д.), т.к. HASP- ключ резервной системы настроен таким образом, что позволяет функционировать резервной системе под коммерческой нагрузкой в течение именно этого времени. Если проблема не может быть устранена за 24 часа, то оператору следует использовать HASP-ключ основного MVTS на резервной системе, что позволит получить неограниченное количество времени для устранения возникших неисправностей. При этом в конфигурационном файле meraproxy.cfg секции [Redundancy] необходимо обязательно установить параметр redundancy_type= в значение 0, либо закомментировать его символом #. После этого следует перезапустить MVTS, выполнив последовательность команд stop и start.

После восстановления работоспособности основного сервера его можно включить в резервную пару в качестве резервного, запустив его, используя HASP-ключ резервной системы. Следует отметить, что смена ролей основного и резервного серверов подразумевает внесение соответствующих изменений в конфигурационные файлы.

Все описываемые в документе способы резервирования имеют свои сильные и слабые стороны, и при выборе того или иного способа пользователь должен руководствоваться соображениями рациональности и эффективности эксплуатации системы.

В двухуровневой кластерной версии MVTS дополнительный сервер используется для резервирования сигнального MVTS. В трехуровневой кластерной версии системы дополнительный сервер используется для резервирования регулятора распределения нагрузки.

2.2 РЕЗЕРВИРОВАНИЕ ПО СХЕМЕ «ПРИВРАТНИК – RAS- ПОЛЬЗОВАТЕЛЬ»

В данной схеме резервирование системы обеспечивается использованием дополнительного сервера с установленной на нем версией MVTS и HASP-ключом, идентифицирующем дополнительную версию приложения MVTS как резервную.

Для обеспечения плавного и незаметного перевода трафика с основного сервера на резервный при выходе первого из строя, резервный MVTS конфигурируется как оконечный RAS-пользователь в файле user.cfg основного MVTS, а основной MVTS описывается как главный и единственный привратник в конфигурационных файлах резервного MVTS.

файлах резервного MVTS. Рисунок 1 Настройка основного и

Рисунок 1 Настройка основного и резервного серверов по схеме «привратник – RAS-пользователь»

1.

Введите параметры RAS-пользователя (резервного MVTS) в конфигурационный файл user.cfg основного MVTS.

2. На резервном сервере выберите схему резервирования с помощью параметра redundancy_type= в секции [Redundancy]. Для данного случая параметр redundancy_type=1

3. Опишите основной MVTS как удаленный привратник в конфигурационных файлах резервного MVTS: в поле master_gatekeeper= секции [Redundancy] файла meraproxy.cfg, а так же создайте соответствующую запись в файле gatekeeper.cfg (см. таблицу).

Таблица 2 Настройка отказоустойчивости MVTS по схеме Привратник – RAS-пользователь

Конфигурационные файлы основного сервера MVTS

Конфигурационные файлы резервного сервера MVTS

user.cfg

gatekeeper.cfg

[Backup_Server]

[Main_MERA]

user=user_name

type=1

password=pswd

user=user_name

… … …

password=pswd

… … …

 

… … …

meraproxy.cfg

… … …

 
 

[Redundancy]

 

redundancy_type=1

 

master_gatekeeper=Main_MERA

Все настройки, относящиеся к обработке трафика, у основного и резервного серверов должны быть идентичными.

Когда резервный MVTS находится в дежурном режиме, все вызовы и регистрации по RAS-протоколу проходят через основной MVTS.

При выходе основной системы из строя (для резервной системы это означает разрыв регистрации с привратником, т.е. основной системой, по RAS-протоколу) резервная система начинает обрабатывать трафик и регистрировать RAS-пользователей. В это же время резервное приложение MVTS направляет электронное уведомление о выходе основной системы из строя по электронному адресу, указанному в поле mail_alert= секции [Administration] конфигурационного файла meraproxy.cfg.

После восстановления основного сервера оператор по своему усмотрению может вернуть систему к первоначальному состоянию, не

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

принудительно

прерывается.

2.3 СХЕМА РЕЗЕРВИРОВАНИЯ С ИСПОЛЬЗОВАНИЕМ ОБЩЕГО IP- АДРЕСА

Функциональная зависимость системы обусловлена использованием дополнительного сервера, работающего в режиме постоянного резервирования и готового принять на себя функции основного MVTS в случае сбоя. Схема функционирования основного и резервного серверов описана ниже.

2.3.1

ОБЗОР

Предположим, что основной сервер MVTS имеет три сетевые интерфейсные платы и использует три IP-адреса (IP1, IP2 и IP3) для входящего трафика. При реализации схемы, в которой используются одинаковые IP-адреса, резервный сервер также должен иметь три сетевых интерфейса для обеспечения доступности адресов как на основном, так и на резервном сервере. В любой момент функционирования системы IP-адреса «подняты» и активны только на одном из серверов.

только на одном из серверов . Рисунок 2 Схема резервирования

Рисунок 2 Схема резервирования с использованием общего IP- адреса: нормальное функционирование

При нормальном функционировании адреса IP1-IP3 «подняты» и активны на основном сервере MVTS. Через равные промежутки времени, длина которых может быть задана в конфигурационных параметрах, резервный сервер пытается установить тестовое TCP-соединение со всеми тремя адресами. Достижение определенного количества неудачных соединений (которое также задается в конфигурационных параметрах) сигнализирует о выходе основного MVTS из строя. В этом случае резервный сервер «поднимает» на своих сетевых картах все три IP-адреса и начинает обрабатывать трафик.

начинает обрабатывать трафик . Рисунок 3 Схема резервирования

Рисунок 3 Схема резервирования с использованием общего IP- адреса: выход основного сервера MVTS из строя

После восстановления, основной MVTS проверяет активность IP- адресов на резервном сервере и, в случае если адреса не используются, возобновляет работу в нормальном режиме. Если же адреса оказываются активными, основной MVTS посылает специальную команду на IP-адреса резервного сервера (обрабатывающего трафик). В ответ на эту команду резервный MVTS деактивирует эти адреса и переходит в резервный режим работы. После этого основной MVTS

2.3.2

«поднимает»

обрабатывать трафик.

эти

адреса

ДЕТАЛИ

на своих сетевых платах и начинает

Приложения MVTS, установленные на основном и резервном серверах, отличаются HASP-ключами, подключенными к серверам. HASP-ключ резервного сервера запрограммирован на 24 часа независимой работы под коммерческой нагрузкой.

Основной и резервный серверы имеют свои собственные адреса, а так же адреса для обработки трафика, количество которых соответствует количеству сетевых интерфейсных карт установленных на сервере.

Основной сервер MVTS различает два режима работы режим при работающем резервном MVTS и режим при неисправном резервном MVTS. Функционально оба режима абсолютно идентичны и используются только для определения сбоев в работе резервного MVTS.

Резервный MVTS имеет три режима работы режим ожидания, при котором резервный MVTS ожидает TCP-соединения с основным MVTS, дежурный режим при нормальном функционировании основного MVTS, и рабочий режим при выходе основного MVTS из строя.

Во время работы основной и резервный MVTS используют TCP- соединения для обмена пакетами с определенным содержанием. Наличие TCP-соединений свидетельствует о нормальном функционировании обоих серверов.

Первоначально основной MVTS предполагает, что он функционирует самостоятельно без резервного MVTS. При установлении тестового TCP-соединения основной MVTS переходит в режим работы с резервным MVTS. При отсутствии тестовых TCP-соединений в течении 30 секунд основной MVTS считает, что резервный MVTS не функционирует, и переходит в режим работы при неисправном резервном MVTS, а также генерирует электронное уведомление о неисправности резервного сервера.

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

При невозможности установить тестовое соединение со всеми рабочими IP-адресами резервный MVTS начинает обрабатывать трафик, о чем высылает соответствующее электронное уведомление.

Существует два возможных варианта развития событий в том случае, когда обработка трафика переходит на резервный MVTS: успешное соединение с основным MVTS, когда резервный MVTS вновь переходит в дежурный режим функционирования, и истечение

запрограммированного периода работы под коммерческой нагрузкой, когда резервный MVTS перестает обрабатывать трафик, высылает об этом соответствующее электронное уведомление и переходит в режим ожидания успешного TCP-соединения с основным MVTS.

Настройка резервирования системы производится в конфигурационном файле meraproxy.cfg, секция [Redundancy].

Примечание:

1. Для корректной работы схемы резервирования с использованием общего IP-адреса (Shared IP Redundancy) необходимо, чтобы оборудование, взаимодействующее с MVTS (шлюзы и маршрутизаторы, находящиеся в одной с ним локальной сети), было настроено на принудительное обновление ARP-таблиц каждые 10 секунд, либо имело возможность обновления ARP-таблиц по внешнему воздействию (по пингу, TCP-соединению и т.п.). В противном случае, при сбое в работе основного сервера и переходе резервного MVTS в активный режим, пакеты, предназначенные для отправки на общий IP-адрес (Shared IP), будут отправляться на MAC-адрес вышедшего из строя основного сервера.

2. При необходимости отправки данных с общего IP-адреса, требуется отключить чтение таблицы маршрутизации ядра операционной системы в конфигурации MVTS (параметр read_route_table=0) и настроить альтернативную таблицу маршрутизации с помощью параметра

alias_route_path=.

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

4. IP-адреса, которые будут использоваться в качестве общих (shared), рекомендуется использовать не на реальных интерфейсах, а на их псевдонимам (alias), так как «поднять»/«опустить» IP-адрес псевдонима интерфейса с помощью команды от удаленного сервера намного легче, нежели IP-адрес самого интерфейса.

5. Тестирование данной схемы резервирования настоятельно рекомендуется проводить при отсутствии реальной коммерческой нагрузки на основном сервере MVTS.

6. Желательно, чтобы настройка данной схемы резервирования осуществлялась при участии инженера технической поддержки компании MERA Systems.

2.4 КОНФИГУРАЦИЯ СЕКЦИИ [REDUNDANCY] НА ОСНОВНОМ И РЕЗЕРВНОМ СЕРВЕРЕ MVTS

Предположим, IP-адрес основного MVTS - 192.168.132.115, а резервного - 192.168.132.114. Оба сервера настроены на использование адреса 192.168.132.140 для обработки трафика. Для обеспечения плавного и незаметного переключения трафика с основного сервера на резервный укажите следующие параметры в секции [Redundancy] конфигурационного файла meraproxy.cfg.

Файл meraproxy.cfg основного сервера MVTS, секция [Redundancy]

Файл meraproxy.cfg резервного сервера MVTS, секция [Redundancy]

redundancy_type=2

redundancy_type=2

check_period=10

check_period=10

max_failed_retries=3

max_failed_retries=3

connect_timeout=3

connect_timeout=3

master_address=192.168.132.115

master_address=192.168.132.115

slave_address=192.168.132.114

slave_address=192.168.132.114

check_address=192.168.132.140|192.168.13

check_address=192.168.132.140|192.16

2.115|/sbin/ifconfig eth0:0 inet 192.168.132.140 up|/sbin/ifconfig eth0:0 down

8.132.114|/sbin/ifconfig eth0:0 inet 192.168.132.140 up|/sbin/ifconfig eth0:0 down

При данной конфигурации основного и резервного серверов, каждый MVTS пытается установить тестовое TCP-соединение каждые 10 секунд (check_period=10). При неудачной первой попытке соединения MVTS попробует установить соединение еще два раза (max_failed_retries=3) с интервалом 3 секунды (connect_timeout = 3). IP-адрес, подвергающийся периодической проверке (в нашем случае 192.168.132.140), указывается в параметре check_address=. IP-адрес, отделенный от проверяемого вертикальной чертой, является адресом, с которого производится проверка.

Параметр check_address=192.168.132.140|192.168.132.114|/sbin/ifconfig eth0:0 inet 192.168.132.140 up|/sbin/ifconfig eth0:0 down в конфигурационном файле резервного MVTS означает, что резервный сервер будет осуществлять проверку IP-адреса 192.168.132.140 со своего локального адреса 192.168.132.114. При неудачной проверке резервный MVTS попытается «опустить» адрес 192.168.132.140 на основном сервере с помощью команды /sbin/ifconfig eth0:0 down и «поднять» этот адрес на себе с помощью команды /sbin/ifconfig eth0:0 inet

192.168.132.140 up.

2.5 СХЕМА РЕЗЕРВИРОВАНИЯ ‘ORDINARY REDUNDANCY

Схема резервирования «Ordinary Redundancy», как и все остальные схемы, предполагает наличие вспомогательного (резервного) сервера с копией приложения MVTS. После запуска вспомогательный сервер пытается установить ТСР-соединение с основным MVTS для проверки его рабочего состояния.

Для настройки данного типа резервирования необходимо использовать следующие конфигурационные параметры из секции [Redundancy] файла meraproxy.cfg:

"master_address="

"slave_address="

"check_period=",

"max_failed_retries=",

"connect_timeout="

"check_address="

Для получения более детальной информации по конфигурационным параметрам системы используйте документ [1].

Вышеперечисленные параметры используются таким же образом, как и при настройке схемы резервирования с общим IP адресом (Схема резервирования с использованием общего IP-адреса). Единственное отличие составляет параметр check_address=.

Данный параметр настраивается на резервном сервере и должен содержать по меньшей мере один IP-адрес (может содержать и большее количество IP-адресов, по числу сетевых интерфейсов главного MVTS сервера), с которым будет устанавливается TCP-соединение.

Если вспомогательный сервер не может установить соединение ни с одним из адресов, указанных в поле check_address=, определенное количество раз (максимальное количество неуспешных соединений указывается в параметре max_failed_retries=), он переключается из дежурного режима в рабочий и начинает выполнять функции главного MVTS сервера: обрабатывать трафик, принимать запросы о регистрации ит.д.

Если вспомогательный MVTS сервер, находясь в дежурном режиме, получает запрос о регистрации (RRQ или GRQ) от какого-либо удаленного клиента, он отвечает сообщением GRJ/RRJ, в который включается список привратников из поля alternate_gatekeeper= (в этом случае, ответ GRJ/RRJ будет скорее служить указанием для пользователя, приславшего запрос, переадресовать этот запрос на основной MVTS сервер).

Находясь в рабочем режиме, резервный MVTS сервер продолжает попытки установить ТСP-соединение с основным MVTS хостом, для

проверки его доступности. Установлениe такого соединения означает, что основной MVTS был восстановлен и вспомогательный сервер снова переходит в дежурный режим.

2.6 СХЕМА РАСПРЕДЕЛЕНИЯ НАГРУЗКИ В ПЕРЕДЕЛАХ ОДНОЙ ЛИЦЕНЗИИ

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

Приложение MVTS, установленное на основном сервере, определяется HASP-ключом как полнофункциональное, в то время как HASP-ключ резервного приложения, определят его как резервное.

Каждый сервер MVTS имеет свой собственный IP-адрес. Оба сервера функционируют и обрабатывают трафик при условии, что общее количество одновременных вызовов не превышает количества, определяемого лицензией.

Так, если количество вызовов, определяемое лицензией, составляет 360 одновременных звонков, то основной сервер может обрабатывать, например, 250 одновременных вызовов, а резервный не более 110. При выходе основного сервера из строя резервный трафик будет обрабатывать весь трафик, но в пределах периода «горячей замены», запрограммированном в HASP-ключе. При истечении данного периода резервный MVTS перестанет функционировать.

При восстановлении основного сервера, которое определяется установлением тесового TCP-соединения, резервный сервер переходит в нормальный резервный режим функционирования (значение периода «горячей замены» восстанавливается).

Для данной схемы резервирования необходимо задать три параметра в секции [Redundancy] основного файла конфигурации meraproxy.cfg:

схему резервирования, IP адрес основного и резервного серверов.

redundancy_type=3

master_address=<IP основого сервера>

slave_address=<IP резервного сервера>

2.7 СХЕМА РЕЗЕРВИРОВАНИЯ N+1

2.7.1

ОБЗОР

В данной схеме резервирования участвуют 1 основной сервер MVTS (master) с главным HASP-ключом и N резервных серверов (slave) с

резервными ключами. Максимальное количество одновременных вызовов, которое может обрабатываться системой, определяется количеством лицензий, запрограммированым в основном ключе.

В настоящее время распределение вызовов осуществляется равномерно среди всех активных серверов MVTS, т.е. в системе, состоящей из активных 4 серверов и имеющей лицензию на 1000 вызовов, каждый из серверов сможет одновременно обрабатывать не более 250 вызовов. Контроль общего количества одновременных вызовов на всех серверах осуществляется основным сервером MVTS.

Каждый резервный серевер периодически проверяет наличие активного основного сервера. В случае отказа в работе основного сервера один из резервных серверов берет на себя роль основного, т.е. есть становится «псевдомастером» (acting master). В отсутствие основного сервера резервные сервера (в том числе и «псевдомастер») могут работать в только течение периода, информация о продолжительности которого запрограммирована в каждом резервном HASP-ключе.

Настройка конфигурационных параметров осуществляется в секции [Redundancy] файла meraproxy.cfg:

redundancy_type = 5 (тип резервирования N+1);

master_address – IP адрес основного сервера MVTS;

slave_address – список IP адресов резервных серверов (разделяются точкой с запятой);

check_period периодичность (в секундах), с которой резервный сервер проверяет наличие основного сервера и информирует его о своем состоянии. Значение по умолчанию: 10.

max_failed_retries – количество последовательных неудачных попыток установить соединение с основным сервером, превышение которого является сигналом того, что основной сервер MVTS вышел из строя. Значение по умолчанию: 3.

connect_timeout – время (в секундах), в течение которого ожидается установление TCP-соединения с основным сервером. Значение по умолчанию: 3.

2.7.2

ДЕТАЛИ

При запуске основной сервер входит в активный режим (StateMasterWorking), в котором пребывает все время. Основной сервер контролирует состояние резервных серверов и равномерно распределяет между ними лицензии. Если основной сервер обнаруживает, что один из резервных серверов вышел из строя, производится перераспределение между оставшимися серверами. Перераспределение лицензий

производится во всех случаях, когда изменяется количество активных резервных серверов.

Резервный сервер при старте входит в режим ожидания основного сервера (StateSlaveWaitForMaster) и находится в нем до момента установления соединения с основным сервером. После успешного установления соединения резервный сервер переходит в режим StateSlaveWaitForAdmission, и находится в этом режиме до тех пор, пока основной сервер не даст разрешение на активную работу и сообщит максимально возможное количество одновременных вызовов. После получения разрешения от основного сервера резервный сервер переходит в активный рабочий режим (StateSlaveWorking), начинает обрабатывать вызовы и периодически устанавливает tcp-соединение с основным сервером (периодичность задается параметром ‘check_period’). В ответ основной сервер сообщает резервному серверу актуальное максимально возможное количество одновременных вызовов. В случае ели резервному серверу не удается установить соединение с основным сервером определенное количество раз (задается параметром ‘max_failed_retries’), резервный сервер с наименьшим IP адресом из списка, заданного в параметре ‘slave_address’, берет на себя роль «псевдомастера» (acting master). «Псевдомастер» исполняет все функции основного сервера в течение периода, информация о продолжительности которого запрограммирована в каждом резервном HASP-ключе.

В случае восстановления работоспособности основного сервера в течение этого периода, «псевдомастер» опять становится резервным сервером.

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

В случае выхода из строя «псевдомастера», его место занимает один из оставшихся резервных серверов, при этом заданный период работы без основного сервера не продлевается.

Внимание: Для данного типа резервирования конфигурационные параметры секции [Redundancy] на всех серверах должны быть идентичны.

Примечания

Для целей отладки можно повысить уровень детализации протокола в конфигурационном файле meraproxy.cfg:

[Debug]

trace_level=4

В этом случае можно будет отслеживать функционирование данного типа резервирования в трассировочном журнале MVTS (сообщения начинаются с «(N+1):»)

Пример вывода команды “sh re” для основного сервера MVTS:

Redundancy type

: N+1

License type

: Main node

Check period

: 10

Connect timeout

:

3

Max failed retries: 3

Master node:

X.X.X.X:1720

Slave nodes: (2 items)

Y.Y.Y.Y:1720

Z.Z.Z.Z:1720

Nodes information:

---------------------------------------------------------------------

> LOCAL NODE:

Address:

X.X.X.X:1720

Role:

Master

State:

StateMasterWorking

Active calls:

0 (34)

Timers:

1 timer(s)

- TimerInternalGarbageCollector (103)

> REMOTE NODE:

Address:

Y.Y.Y.Y:1720

Role:

Slave

State:

StateSlaveWorking

Active calls:

0 (33)

Timers:

1 timer(s)

- TimerMasterSlaveKeepalive (22)

socket state:

last connection: 2007-04-20 15:58:55

failed retries: 0

Undefined

> REMOTE NODE:

Address:

Z.Z.Z.Z:1720

Role:

Slave

State:

StateSlaveWorking

Active calls:

0 (33)

Timers:

1 timer(s)

- TimerMasterSlaveKeepalive (22)

socket state:

Undefined

last connection: 2007-04-20 15:58:55 failed retries: 0

0 forgotten node(s):

Пример вывода команды “sh re” для резервного сервера MVTS:

Redundancy type

: N+1

License type

: Backup node

Check period

: 10

Connect timeout

:

3

Max failed retries: 2

Master node:

X.X.X.X:1720

Slave nodes: (2 items)

Y.Y.Y.Y:1720

Z.Z.Z.Z:1720

Nodes information:

---------------------------------------------------------------------

> LOCAL NODE:

Address:

Y.Y.Y.Y:1720

Role:

Slave

State:

StateSlaveWorking

Active calls:

0 (33)

Timers:

1 timer(s)

- TimerInternalGarbageCollector (46)

> REMOTE NODE:

Address:

X.X.X.X:1720

Role:

Master

State:

StateMasterWorking

Active calls:

0

Timers:

1 timer(s)

- TimerSlaveReport (8)

socket state:

last connection: 2007-04-20 12:10:09

failed retries: 0

Undefined

0 forgotten node(s):

Пояснение:

Секция ‘> LOCAL NODE:’ содержит информацию о локальном сервере MVTS;

Секция ‘> REMOTE NODE:’ содержит информацию об удаленном сервере MVTS;

‘License type’ может принимать два значения ‘Main node’ или ‘Backup node’;

‘Role’ может принимать три значения ‘Master’, ‘Slave’ и ‘Acting Master’;

‘State’ - состояние данного сервера MVTS;

‘Active calls’ содержит информацию об активном количестве звонков на данном сервере MVTS и о текущем размере лицензии (в скобках);

‘Timers’ содержит отладочную информацию для разработчиков MVTS;

‘socket

state’

cодержит

отладочную информацию

для разработчиков

MVTS;

‘forgotten

node(s):’

содержит отладочную информацию для

разработчиков MVTS.

3 ДОВЕРИТЕЛЬНЫЕ ОТНОШЕНИЯ МЕЖДУ ОСНОВНЫМ И РЕЗЕРВНЫМ СЕРВЕРОМ

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

Доверительные отношения обеспечивают удаленный доступ к резервному серверу с правами пользователя “root” без необходимости введения пароля.

Доверительные отношения между серверами позволяют удаленно выполнять команды по протоколу ssh, а также запускать скрипты, позволяющие автоматизировать административные и рабочие процедуры. Для обеспечения автоматического доступа по протоколу ssh с резервного сервера на основной (без необходимости введения пароля пользователя root) необходимо произвести следующие настройки ssh.

Предположим, что основной и резервный серверы называются master.com и backup.com, соответственно. Для установления доверительных отношений между серверами с целью обеспечения удаленного доступа по протоколу ssh произведите следующие операции.

1) Войдите на сервер backup.com как пользователь root и введите следующие команды в командной строке:

#> ssh-keygen -t dsa

Утилита ssh-keygen сгенерирует открытый и закрытый ключи и запишет

их в файлы

соответственно. При работе с утилитой ssh-keygen нажимайте клавишу ENTER в ответ на все запросы приложения (при запросе приложения "Enter passphrase (empty for no passphrase)" ничего не вводите, просто нажмите клавишу ENTER).

Запустите утилиту scp:

/root/.ssh/id_dsa

и

/root/.ssh/id_dsa.pub,

#> scp /root/.ssh/id_dsa.pub root@master.com:/root/.ssh/authorized_keys2

Утилита scp скопирует файл id_dsa.pub с сервера backup.com на сервер master.com, запишет его в файл root/.ssh/authorized_keys2 и попросит ввести пароль пользователя root для сервера master.com.

В результате, при введении в командной строке ssh root@master.com для сервера master.com будет открыт удаленный доступ на сервер backup.com с правами пользователя root.

Примечание : Установление доверительных отношений между компьютерами является серьезным нарушением требований безопасности. Используйте данную возможность только в тех случаях, когда это действительно необходимо.

3.1 СИНХРОНИЗАЦИЯ НАСТРОЕК ОСНОВНОГО И РЕЗЕРВНОГО СЕРВЕРОВ

Для автоматической синхронизации конфигурационных файлов приложений MVTS, установленных на основном (master) и резервном (backup) серверах, используйте скрипт synchro.sh. Данный скрипт обеспечивает копирование файлов с основного сервера на резервный через равные промежутки времени. Скрипт synchro.sh запускается на резервном сервере, проверяет конфигурационные файлы на основном сервере и копирует их с необходимыми изменениями на резервный сервер.

Скрипт synchro.sh использует .diff файлы, содержащие описание инструкций для утилиты sed, производящей необходимые изменения в конфигурационных файлах MVTS (например, изменяет IP-адрес основного сервера на IP-адрес резервного и т.п.). Таким образом, файл meraproxy.cfg.diff содержит инструкции по изменению файла meraproxy.cfg, файл dialpeer.cfg.diff инструкции по изменению файла dialpeer.cfg и т.д.

Примечание: Отсутствие инструкции s/IP_address_master/Ip_address_backup/g в .diff файлах приведет копированию конфигурационных файлов без изменений, результатом чего станет некоррекетное функционирование резервного MVTS.

После внесения необходимых данных в .diff файлы запустите скрипт synchro.sh.

Для запуска скрипта на резервном сервере используйте cron-службу или утилиту “at”.