uzluga.ru
добавить свой файл
1
Министерство образования и науки РФ

ФГАОУ ВПО «Уральский федеральный университет

имени первого Президента России Б.Н.Ельцина»

Кафедра «Теплофизика и информатика в металлургии»


ПО «SL Balancer»


Руководство к beta версии


Руководитель

Старший преподаватель В.Ю. Носков

должность, звание подпись расшифровка подписи

Студенты:

Мт – 570502 К.А. Криницын

номер группы подпись расшифровка подписи

Мт – 570503 А.В. Пономарев

номер группы подпись расшифровка подписи


Екатеринбург

2012

Оглавление





1Установка и настройка службы SNMP 3

1.1 Настройка для Linux Debian 3

1.2 Настройка для ОС Windows 4

2.1 Пример конфигурационно файла: 8

3Настройка BIND 9

4 Настройка NGINX 12

5 Описание log-файла 14

5.1 Пример описание записей log-файла 14

6 Описание файлов по балансировке 16

6.1 Описание файла BIND 16

6.1 Описание файла NGINX 17



  1. Установка и настройка службы SNMP

1.1 Настройка для Linux Debian


Для снятия статистики загрузки с серверов «Балансировщик» использует службу  snmpd. После её конфигурации становится возможным получение значения загрузки центрального процессора сервера, использование памяти и др.

Пример установки и конфигурации службы snmpd будет приводиться для ОС Linux Debian/Ubuntu. Но для остальных операционных систем процесс схожий, и особенности начтройки можно найти в сети Internet.

Устанавливаем пакет snmpd через командную строку: apt-get install snmpd

Вносим коррективы в файл: /etc/default/snmp.conf. По умолчанию служба snmpd «слушает» обращения только с localhost: 127.0.0.1. Для того чтобы «слушал» все направления – изменяем строку

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'

до такого состояния: SNMPDOPTS='-Lsd -Lf /dev/null -p /var/run/snmpd.pid'

Корректируем файл /etc/snmp/snmpd.conf

com2sec local localhost public # для подключения с localhost используем «пароль — комьюнити» public (по умолчанию в ОС ставится коммунити public)
com2sec localnet 192.168.0.0/24 public # для подключения с адресов 192.168.0.* используем «пароль — комьюнити» public

# не забудьте поменять «пароли» на свои:


group MyROSystem v1 local
group MyROSystem v2c local
group MyROSystem usm local
group MyROGroup v1 localnet
group MyROGroup v2c localnet
group MyROGroup usm localnet
group MyRWGroup v1 local
group MyRWGroup v2c local
group MyRWGroup usm local


view all included .1 80
view system included .iso.org.dod.internet.mgmt.mib-2.system


access MyROSystem "" any noauth exact system none none
access MyROGroup "" any noauth exact all none none
access MyRWGroup "" any noauth exact all all none


syslocation MainDatacenter # (здесь можно указать информацию о себе)
syscontact
 admin@mail.ru # (здесь можно указать контактную информацию)


Для того чтобы snmp принимала запросы из разных подсетей нужно вставить следующие строчки в раздел


syscontact Admin mail.com>
rocommunity Community 127.0.0.1
rocommunity Community 192.168.1.0/24 //необходима строчка для подсети


Также для того чтобы snmpd разрешала доступ к закрытым веткам oid необходимо внести изменения в разделе # ACCESS CONTROL


# Full access from the local host
rocommunity public localhost
rwcommunity public localhost (Добавить эту строчку)

# Default access to basic system info
#rocommunity public default -V systemonly

Сохраняем изменения

Перезапускаем snmpd: snmpd restart

Теперь можно тестировать службу: snmpwalk –v2c –c public localhost .1.3.6.1.4.1.2021.10.1.3.1 Ответ будет являться средняя загрузка системы в течение последней минуты.

1.2 Настройка для ОС Windows


В ОС Windows службы SNMP доступна в виде компонентов Windows, но они не устанавливаются по умолчанию.

Для установки SNMP в Windows, выполните следующие действия:

  • Нажмите кнопку Пуск – Панель управления

  • Нажмите кнопку «Установка и удаление программ».

  • В левой панели, нажмите кнопку «Добавить / удалить компоненты Windows»

  • Найдите и выберите пункт Management and Monitoring Tools (Средства управления и наблюдения) и нажмите кнопку “Details” (Состав)

  • Выберите «Simple Network Management Protocol»

  • Вы также можете установить WMI SNMP Provider (WMI поставщик SNMP), который позволяет клиентам получать доступ к информации SNMP через интерфейсы WMI (Windows Management Instrumentation)




Рисунок 1.2 — Установка службы SNMP


После установки, найдите соответствующие службы в консоли управления службами(services.msc).

Запустите “SNMP Service”, чтобы включить агента SNMP, и службу “SNMP Trap Service”, чтобы иметь возможность получать SNMP сообщения (SNMP Traps) от других агентов.


Настройка SNMP агента в Windows:

  • Нажмите кнопку Пуск – Выполнить – введите «services.msc» и нажмите ввод. В результате откроется консоль управления службами.



Рисунок 1.3 — Результат выполнения команды services.msc


  • На правой панели щелкните правой кнопкой мыши по службе SNMP и выберите пункт «Свойства»

  • Перейдите на вкладку Agent (Агент SNMP), введите контактное имя и месторасположение сервера, а также отметьте события, сообщения о которых нужно передавать на сервер управления SNMP.

  • Перейдите на вкладку Traps (Ловушки) и введите наименование группы и получателей сообщений (Trap). Это укажет агенту SNMP сервера, на которые необходимо слать SNMP сообщения в случае возникновения неполадок.. Community name (Имя сообщества)– это имя сервера управления SNMP.

  • На вкладке Security (Безопасность) мы можем установить различные параметры безопасности для различных серверов SNMP, существуют следующие уровни: “Notify”, “READ ONLY”, “READ WRITE”, “READ CREATE”. » Read Write» - максимально допустимый уровень разрешений, при которых сервер управления SNMP может вносить изменения в систему, а уровень “READ ONLY”- подразумевает возможность лишь опрашивать систему, а вносить какие-либо изменения нельзя.

  • Кроме того, по соображениям безопасности, вы можете выбрать опцию  Accept SNMP Packets from these hosts (Приемлимые имена сообществ), с помощью которой можно определить список авторизованных серверов, которые могут опрашивать этого агента.



Рисунок 1.4 — Приемлимые имена сообществ

  • Нажмите кнопку Применить и ОК.

  • Щелкните правой кнопкой мыши по службе и выберите пункт «Перезапустить», чтобы изменения вступили в силу.

  1. Конфигурация «Балансировщика»


После установки и запуска балансировщика в директории /etc/sl_balacer/ появится два текстовых файла:

  • netball.conf;

  • log.txt.

Пользователь может взаимодействовать с ПО через конфигурационный файл (netball.conf), передавать программе различные параметры работы.


ПО «SL Balancer» представляет собой универсальный алгоритм для работы как с NGinx так и с DNS сервером BIND. Для того чтобы ПО взаимодействовало с этими процессами необходимо указать объект взаимодействия в строчке Model. В этой строке необходимо указать режим взаимодействия либо с BIND, либо с NGinx. Слова необходимо указывать сразу после знака «=» без пробелов с большой буквы буквы:


Model=BIND (Model=NGINX)


Затем в необходимо указать расположение файла в котором находятся IP адреса и в котором будут производиться изменения «весов» серверов. Расположение файлов не обходимо писать сразу после знака «=» со строчной буквы:


Bind directory=/etc/bind/bind.zone


или


NGINX directory=/etc/nginx/nginx.zone


Далее указываются реквизиты доступа к службе snmp на серверах, для которых происходит пересчет рейтинга. Т.к. тестовая версия предполагает предварительную расширенную настройку snmp службы, то значения всех запрошенных переменных можно будет получить с меткой public. Коммьюнити так же необходимо писать сразу после знака «=» и со строчной буквы:


Community=public


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


Request timer=5


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

Для того чтобы IP адреса сервера брались из файла BIND или NGINX нужно поставить «YES» в следующую строчку с прописной буквы сразу после знака «=»:


IP's from file=YES


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

В ПО «Балансировщик» предусмотрена возможность логирования. Для того чтобы ПО записывало сообщения о своей работе нужно указать расположение файла лога в строчке «Log drectory». По умолчанию, лог файл создается в папке балансировщика: /etc/sl_balancer/log.txt. При необходимости расположение файл можно поменять, достаточно после фразы «Log directory» с прописной буквы указать расположение нового лог-файла:


Log directory=/etc/sl_balancer/log.txt


На данный момент возможно только 1 уровень логирования, уоторый и стоит по умолчанию. Чтобы «Балансировщик» начал записывать сообщения нужно что бы после записи «Log detail=» стояло число 1:


Log detail=1

2.1 Пример конфигурационно файла:



Model=BIND

Bind directory=/etc/bind/bind.conf

Community=public

Request timer=5

IP's from file=YES

Log directory=/etc/sl_balancer/log.txt

Log detail=1


  1. Настройка BIND


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

В BIND 9 оператор controls точно так же используется для определения способа приема управляющих сообщений. Синтаксис оператора отличается незначительно — допустимо только одно предписание /net. (BIND 9.1.0 не поддерживает Unix-сокеты для управляющего канала, и, исходя из заявлений консорциума ISC, Unix-сокеты в BIND 9 никогда не появятся).

В BIND 9 можно не указывать номер порта, и в этом случае сервер будет прослушивать стандартный порт 953. Необходимо включать в предписание раздел keys:


controls {

inet * allow { any; } keys { "rndc-key"; };};


Таким образом определяется криптографический ключ, с помощью которого должны идентифицировать себя пользователи rndc перед отправкой DNS-серверу управляющих сообщений. Если раздел keys отсутствует, после запуска DNS-сервера в log-файле можно обнаружить следующее сообщение:


Jan 13 18:22:03 terminator named[13964]: type 'inet' control channel

has no 'keys' clause; control channel will be disabled


Ключ или ключи, перечисленные в разделе keys, должны быть предварительно определены с помощью оператора key:


key "rndc-key" {

algorithm hmac-md5;

secret "Zm9vCg==";

};


Оператор key может присутствовать непосредственно в файле named.conf, но если named.confдоступен для чтения не только владельцу (группе), будет безопаснее поместить определение ключа в отдельный файл, который имеет более ограниченные права доступа, и включать этот файл в named.conf следующим образом:


include "/etc/rndc.key";


В настоящее время поддерживается только алгоритм HMAC-MD5, то есть механизм идентификации на основе быстрого МD5-алгоритма создания устойчивого хеш-значения. Ключ является общим для named и пользователей rndc паролем в кодировке Base 64. Ключ можно сгенерировать с помощью таких программ как mmencode и dnssec-keygen из пакета BIND.

Чтобы пользоваться программой rndc, следует создать файл rndc.conf — источник информации о ключах и серверах имей для программы rndc. rndc.conf обычно находится в каталоге /etc. Вот пример простого файла rndc.conf:


options {

default-server localhost;

default-key "rndc-key";

};

key "rndc-key" {

algorithm hmac-md5;

secret "Zm9vCg==";

};


Синтаксис этого файла очень похож на синтаксис файла named.conf. В операторе options определяется DNS-сервер, которому по умолчанию посылаются управляющие сообщения (эту настройку можно изменить из командной строки), а также имя ключа, который по умолчанию предоставляется удаленным DNS-серверам (имя ключа также можно изменить из командной строки).

Синтаксис оператора key идентичен используемому в файле named.conf, который описан ранее. Имя ключа в rndc.conf, а также связанный с именем секрет должны совпадать с определением ключа в named.conf.

В случае, когда ключи — по сути дела, пароли — хранятся в файлах rndc.conf и namedxonf, следует убедиться, что ни один из этих файлов не может быть прочитан пользователями, которые не должны управлять DNS-сервером.

Если rndc применяется для управления единственным DNS-сервером. настройка не представляет сложностей. Ключ идентификации определяется идентичными операторами key в файлах named.conf rndc.conf. Затем DNS-сервер указывается в качестве используемого по умолчанию в разделе default-server оператора options, в файле rndc.conf, a ключ — в качестве ключа, используемого по умолчанию, в default-key. После этого следует выполнить rndc следующим образом:


% rndc reload


Если существует необходимость управлять набором серверов, можно связать каждый из них с отдельным ключом. Ключи следует определить в отдельных операторах key, а затем связать каждый из ключей с сервером с помощью набора операторов server:


server localhost {

key "rncc-key";

};

server wormhole.movie.edu {

key "wormhole-key";

};


После этого можно выполнять rndc, указывая в качестве аргумента ключа s имя DNS-сервера, с которым следует работать:


% rndc -s wormhole.movie.edu reload


Если ключ не был связан с определенным DNS-сервером, используемый ключ можно задать в командной строке, используя ключ -y программы rndc:


% rndc -s wormhole.movie.edu -у rndc-wormhole reload


И наконец, если DNS-сервер ожидает получения управляющих сообщений через нестандартный порт (то есть не через порт с номером 953), следует использовать ключ командной строки -p для указания порта:


% rndc -s terminator.movie.edu -р 54 reload


В BIND 9.0.0 программа rude поддерживает только команду reload, но не перезагрузку отдельных зон, которая не поддерживается вплоть до версии 9.1.0. В BIND 9.1.0 поддерживаются не все существующие в BIND 8 команды; поддерживаются — reload, stop, stats, querylog и dumpdh, а также новые команды refresh и halt:


refresh

Принудительное выполнение служебных операций для вторичной зоны.

halt

Прекращение работы DNS-сервера без записи в файлах журнала информации о незавершенных обновлениях файлов зон.


4 Настройка NGINX


Особенной настройки nginx не требуется. Достаточно передать балансировщику номер главного процесса. Номер главного процесса по умолчанию записывается в файл /usr/local/nginx/logs/nginx.pid. Изменить имя этого файла можно при конфигурации сборки или же в nginx.conf директивой pid. Достаточно просто проверить что nginx принимает команду HUP, которая нужна для того, чтобы nginx перечитал файл конфигурации. Главный процесс сначала проверит синтаксическую правильность конфигурации, а затем попытается применить новую конфигурацию, то есть, открыть лог-файлы и новые listen сокеты. Если ему это не удаётся, то он откатывает изменения и продолжает работать со старой конфигурацией. Если же удаётся, то он запускает новые рабочие процессы, а старым шлёт сообщение о плавном выходе. Старые рабочие процессы закрывают listen сокеты и продолжают обслуживать старых клиентов. После обслуживания всех клиентов старые рабочие процессы завершаются.

Предположим, на FreeBSD 4.x команда


ps ax -o pid,ppid,user,%cpu,vsz,wchan,command | egrep '(nginx|PID)'


показывает примерно такую картину:


PID PPID USER %CPU VSZ WCHAN COMMAND

33126 1 root 0.0 1148 pause nginx: master process /usr/local/nginx/sb

33127 33126 nobody 0.0 1380 kqread nginx: worker process (nginx)

33128 33126 nobody 0.0 1364 kqread nginx: worker process (nginx)

33129 33126 nobody 0.0 1364 kqread nginx: worker process (nginx)


Если послать сигнал HUP главному процессу, то картина может быть такой:


PID PPID USER %CPU VSZ WCHAN COMMAND

33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sb

33129 33126 nobody 0.0 1380 kqread nginx: worker process is shutting down (n

33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)

33135 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)

33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)


Один старый рабочий процесс 33129 всё ещё продолжает работать. По истечении некоторого времени он завершается:

PID PPID USER %CPU VSZ WCHAN COMMAND

33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sb

33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)

33135 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)

33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)


5 Описание log-файла


На протяжении своей работы балансировщик собирает и записывает информацию о своей работе в log-файл, который по умолчанию находится в директории /etc/sl_balancer/log.txt.

5.1 Пример описание записей log-файла


127.0.0.1 - Initialize a session – эта запись обозначает об начале инициализации сессии с опредленным сервером (в данном примере с localhost);

public - community used – говорит о том, что при взаимодействии с удаленным сервером по протоколу SNMP успользуется комьюнити public;

50 - Requested value from oid CPU Load – 50 – получено значение загрузки сервера, с котором было установлено соединение по протоколу SNMP;

2- Count of CPU – количество ядер процессора у сервера, с которым установлено взаимодействие по протоколу SNMP;

50- AVG load of CPU's – среднеарифметическая загрузка процессора сервера;

784684 - requested value from oid .1.3.6.1.4.1.2021.4.11.0 – ответ сервера по протоколу SNMP, который показывает объем свободной RAM у сервера, с которым установлено взаимодйствие;

DNS error: Cannot reload Bind! – запись, обозначающая, что не удалось выполнить мягкий сбой DNS-сервера BIND. Это может быть связано с некорректной настройкой BIND. Появление этой записи говорит о том, что серверам, по адресам которых проходила балансировка, не будет присвоен пропорциональный вес и они будут работать в предыдущем режиме (до которого происходила балансировка);

DNS FILE: CANT OPEN DNS FILE! – появление этой записи в логе обозначает либо отсутствие файла для балансировки, которые администратор указал в полях либо «BIND Directory=» либо «NGINX Directory=». Так же эта ошибка может записываться в лог если у пользователя нету прав к указываемым в этих полях файлах.

DNS: Bind was reload successful! – запись, говорящая о том, что мягкий сбой DNS сервера Bind прошел успешно и сетевая нагрузка распределена пропорционально между всеми серверами;

NGINX error: Cannot reload NGINX! – запись, обозначающая, что не удалось выполнить мягкий сбой сервера Nginx. Это может быть связано с некорректной настройкой Nginx или отсутствием прав у пользователя. Появление этой записи говорит о том, что серверам, по адресам которых проходила балансировка, не будет присвоен пропорциональный вес и они будут работать в предыдущем режиме (до которого происходила балансировка);

NGINX: Nginx was reload successful - запись, говорящая о том, что мягкий сбой сервера Nginx прошел успешно и сетевая нагрузка распределена пропорционально между всеми серверами;

127.0.0.1 Timeout: No Response from server эта запись говорит о том, что с сервером не удается установить соединение по протоколу SNMP. Ее появление говорит о том, что серверу (в данном примере 127.0.0.1) будет присвоено значение нулевого рейтинга, т.е. ему не будут поступать запросы пользователей. Эта ошибка может появиться в результате:

  • некорректной настройки службы SNMP на сервере;

  • отсутствием связи между сервером и балансировщиком;

  • неправильного комьюнити (Community) для взаимодействия между балансировщиком и сервером.



6 Описание файлов по балансировке


SL Balancer может одновременно балансировать до 10 различных зон. Для корректной балансировки необходимо правильно оформить файл с зонами для балансировки.

6.1 Описание файла BIND


Для каждой из 10 зон предусмотрен свой специальный комментарий, который необходимо размещать перед каждый IP-адресом. В общем виде этот комментарий выглядит так:


/*bi*/ IP-адрес сервера


где i – номер зоны для балансировки (от 0 до 9).


Каждый IP-адрес сервера нужно писать в отдельной строке вместе со специальным комментарием. После комментария обязательно должен стоять пробел. Пример оформления файла с зонами:


IN SOA mydomain.com. mydomain2.com. mydomain.com3.

2004071001 ;serial

108000 ;refresh

1800 ;retry

1209600 ;expiry

(604800)

mydomain1.com IN A /*b1*/ 192.168.0.34

mydomain1.com IN A /*b1*/ 192.168.0.35

mydomain1.com IN A /*b1*/ 192.168.0.36


mydomain2.com IN A /*b2*/ 192.168.100.71

mydomain2.com IN A /*b2*/ 192.168.100.72

mydomain2.com IN A /*b2*/ 192.168.100.75


mydomain3.net IN A /*b9*/ 116.171.68.78


После выполнения цикла работы балансировщик в файл столко повторений IP-адресов, каков получился рейтинг каждого сервера

Допустим, что после выполнения работы рейтинг сервера 192.168.0.34 стал равным 2, сервера 192.168.0.36 раным 3, а у сервера 192.168.0.36 одному.

В результате балансировщик перезапишет файл DNS следующим образом:


localhost. IN SOA localhost.root.localhost. (

2004071001 ;serial

108000 ;refresh

1800 ;retry

1209600 ;expiry

(604800)

mydomain1.com IN A /*b1*/ 192.168.0.34

mydomain1.com IN A /*b1*/ 192.168.0.35

mydomain1.com IN A /*b1*/ 192.168.0.36

mydomain1.com IN A 192.168.0.34

mydomain1.com IN A 192.168.0.35

mydomain1.com IN A 192.168.0.35


mydomain2.com IN A /*b2*/ 192.168.100.71

mydomain2.com IN A /*b2*/ 192.168.100.72

mydomain2.com IN A /*b2*/ 192.168.100.75


mydomain3.net IN A /*b10*/ 116.171.68.78


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

6.1 Описание файла NGINX


Для каждого из серверов модулей upstream, так же как и для BIND’а, предусмотрен свой специальный комментарий, который необходимо размещать перед каждым IP-адресом. В общем виде этот комментарий выглядит так:


/*bi*/ IP-адрес сервера


где i – номер зоны для балансировки (от 0 до 9).

Каждый IP-адрес сервера нужно писать в отдельной строке вместе со специальным комментарием. После комментария обязательно должен стоять пробел. Пример оформления файла с зонами:


upstream zone1
 
{
server /*b1*/ 192.168.0.4
server /*b1*/ 192.157.13.20 
}

upstream zone2 
{
server /*b2*/ 192.170.0.15
server /*b2*/ 192.157.18.27 
}

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


upstream zone1 
{
server /*b1*/ 192.168.0.4 weight=1;
server /*b1*/ 192.157.13.20 weight=5;
}

upstream zone2 
{
server /*b2*/ 192.170.0.15 weight=3;
server /*b2*/ 192.157.18.27 weight=4;
}