82
Так как лицензии SFE установлены на максимальное значение, расчет
придела MO нагрузки основывается на сигнальных линках (MO и MT) и
емкости аппаратной части MAP и SFE серверов.
max_user_capacity параметр должен быть установлен на 200
Необходимо задать параметры следующим способом:
smsc -class CTRL rm_set -pass NETPASSNETPASS
max_user_capacity=200
smsc -class CTRL rm_set -pass NETPASSNETPASS C7.traffic_limit=540
smsc -class MAP rm_set -pass NETPASSNETPASS
MAP.traffic_limit.enable=yes
smsc -class MAP rm_set -pass NETPASSNETPASS
MAP.traffic_limit.logic_type=fixed_frame
smsc -class MAP rm_set -pass NETPASSNETPASS
MAP.traffic_limit.major_frame=
1
smsc -class MAP rm_set -pass NETPASSNETPASS
MAP.traffic_limit.minor_frame=1
Логическая лицензия работает в нескольких режимах:
Minor frame
Major frame
Fixed frame
minor если аппликация превышает установленное ограничение, то
прием по этому порту блокируется на 60 секунд
major на 3600
fixed сбрасывает всё что выше установленного ограничения и не
блокирует приём
83
smsc -class MAP rm_set -pass NETPASSNETPASS
MAP.traffic_limit.max_successive_upper_violations_allowed=0
Проверка, что значения успешно изменились:
smsc -class CTRL rm_get -pass
NETPASSNETPASS max_user_capacity; echo ""
smsc -class CTRL rm_get -pass NETPASSNETPASS C7.traffic_limit; echo
""
smsc -class MAP rm_get -pass NETPASSNETPASS
MAP.traffic_limit.enable; echo ""
smsc -class MAP rm_get -pass NETPASSNETPASS
MAP.traffic_limit.logic_type; echo ""
smsc -class MAP rm_get -pass NETPASSNETPASS
MAP.traffic_limit.major_frame; echo ""
smsc -class MAP rm_get -pass NETPASSNETPASS
MAP.traffic_limit.minor_frame; echo ""
smsc -class MAP rm_get -pass NETPASSNETPASS
MAP.traffic_limit.max_successive_upper_violations_allowed; echo ""
Активация изменений на MAP серверах.
Необходимо выполнить команду Terminate 0 на всех серверах MAP
CEs, данная комана отключит приложение omni, затем выполнить команду
go, которая запустит приложение уже с новыми настройками.
84
ГЛАВА 3. Мониторинг систем VAS
3.1. Способы мониторинга и устранения аварий на системах
VAS
Для мониторинга нагрузки на все VAS системы использовалось open-
source веб-приложение Cacti, данная система позволяет строить графики при
помощи RRDtool. Cacti собирает статистические данные за определённые
временные интервалы и позволяет отобразить их в графическом виде.
Преимущественно используются стандартные шаблоны для отображения
статистики по загрузке процессора, выделению оперативной памяти,
количеству запущенных процессов, использованию входящего/исходящего
трафика.
Хоть и Cacti является удобным интерфейсом и для этого приложения не
важно какое количество объектов будет установлено на мониторинг, так как
он не хранит полностью все данные в базе данных (как например Zabbix). Но
тем не менее у Cacti есть и свои недостатки, как например, неспособность
системы отслеживания возможностей случайного сброса контролируемого
параметра, что в свою очередь приводит к целочисленному переполнению и
большим скачкам на графиках. К примеру, в случае если устройство
перегрузилось и сбросило счетчики in/out octets. После перезагрузки Cacti
снимает новые данные со счетчиков, считает разницу с предыдущими
параметрами и рисует на графике пи загрузки канала 100 Мбит, хотя в
действительности канал был загружен не более чем на 2Мбита. Так же из
очевидных минусов Cacti можно считать не уменее самому создавать rrd с
отрицательными значениями, в результате чего администратор вынужден
исправлять график вручную с помощью rrdtune.
85
Ввиду того, что сервер мониторинга разворачивался исключительно по
инициативе самих администраторов и с максимальной финансовой
экономией, для развертывания системы мониторинга был использован старый
сервер Langley 2, куда в свою очередь было установлено приложение Cacti.
Система мониторинга сетевых устройств Cacti это PHP скрипт для
сбора SNMP данных, и представления их в удобном виде. Программу
отличает удобный интерфейс и простота настройки.
Для работы Cacti требуется:
Apache или IIS
MySQL 4.1.x или 5.x и более
RRdTool 1.0.49 или 1.2.x и более
PHP 4.3.6 и более
Поддержку SNMP на хосте.
Так же рекомендуется установить модуль php-snmp и php-cli (консоль
php).
Для опроса хоста необходимо поднять демона SNMP.
Структура предоставления данных.
Cacti опрашивает хосты. Хост - это любой ресурс сети, имеющий IP с
поднятым на нём SNMP. У каждого хоста есть data source, это может быть
какой-либо параметр системы. Каждый data source может быть представлен в
виде графика. Каждый график может быть представлен в общем дереве.
Дерево может состоять из заголовков (headers) на разных уровнях, хосты
располагаются внутри заголовков, каждый хост отображается как страничка с
86
графиками. Опрос хостов может происходить двумя способами, при помощи
php-скрипта и cron.
К примеру:
*/5 * * * * root php /var/www/html/cacti/poller.php > /dev/null 2>&1
В crontab
Cacti поддерживает большое количество шаблонов для опроса
специфичных параметров различных устройств. По умолчанию у нас есть
только основные типы запросов, однако можно добавить и множество других.
На пример можно мониторить скорость вращения кулера или интенсивность
работы жёстких дисков, работу различных сервисов (почты, www и тп.).
3.2. Процедура сброса CMOS (микросхемы динамической
памяти) на сервере Langley 2
Процедура под названием очищение CMOS единстенный путь на Intel
платформе позволяющий решить проблему с сервером Langley, в случае
возникновения проблем с ним. Данная процедура не гарантирует полное
востановление сервера, но на 100% гарантирует проведение диагностики
аппаратной части, благодаря которой можно в точности выявить какой
компонент аппаратной части вышел из строя и в дальнейшем принять
решение, востанавливать имеющийся сервер, либо же полностью его
заменить. Эта процедура работает как на серверах Langley версии 2, так и на
серверах Langley версии 4.
В данной главе, я покажу как вручную очистить CMOS на Langley 2 и 4.
Один из признаков, с помощью которого можно отличить Langley
версии 2 от Langley версии 4, это наличие двух USB портов на передней
87
панели сервера Langley 2, тогда как на Langley 4, на передней панеле имеется
всего один порт.
Как очистить CMOS на сервере Langley 2
Эта процедура требует полного отключение сервера от какой-либо системы
Важно выполнять данную процедуру последовательно.
Отключить сервер, после отключить оба кабеля питания от двух блоков
питания позади сервера.
Извлечь сервер из кабинета системы.
Имеются три синих квадратных джампера находящиеся рядом. Каждый
из них имеет три пина но перемычка закрывает только два. Джампер
для очистки CMOS находится в самом краю с права (ближе к задней
части сервера), это можно увидеть на картинке 1 в приложении 3.
Необходимо попросту переместить перемычку на одну ступень левее и
перекрыть два левых пина.
Подключить сервер к питанию и включить его.
Визуально осматриваем индикаторы на материнской плате, все ли
индикаторы были включены (CPU, DIMM и.т.д).
Выключаем сервер, отсоединяем кабеля питания.
Возвращаем CMOS перемычку обратно.
Подключаем кабеля питания обратно и включаем сервер
Повторно осматриваем материнскую плату на наличие включенных
индикаторов (CPU, RAM)
Необходимо уделить особое внимание на индикаторы возле
оперативной памяти и CPU.
Необходимо проверить консоль на наличие сообщений об ошибке.
Как очистить CMOS на сервере Langley 4
88
Отключаем сервер и извлекаем все кабеля питания и сети, так же
извлекаем сервер из стойки.
Открываем сервер и перемещаем CMOS перемычку A (картинка ниже)
из положения A1-A2 в положение A2-A3. Это приведет к очистке
CMOS.
Заново подключаем кабеля питания и блоки питания к серверу и
включаем его.
Визуально осматриваем индикаторы на материнской плате, все ли
индикаторы были включены (CPU, DIMM и.т.д). Делаем фотографию
(при необходимости)
Снова отключаем сервер и извлекаем кабеля питания и блоки питания.
Переставляем CMOS перемычку на ее прежнее местоположение –пины
1 и 2.
Подключаем блоки питания, кабеля и включаем сервер
Снова визуально осматриваем материнскую плату, горят ли
индикаторы (CPU, DIMM и.т.д), делаем фотографию при
необходимости.
Необходимо заострить особое внимание на индикаторы возле DIMM
плат и CPU.
Смотрим на экран консоли на наличие ошибок.
В приложении 3, рисунок 3 можно увидеть схему материнской платы, а
так-же, место где находится перемычка.
89
3.3. Решение проблем с сервером мониторинга
Из-за переодических проблем с аппаратной частью в приложении Cacti
переодически происходили сбои, которые решались следующим образом:
Переодически на странице мониторинга выходило сообщение о том,
что невозможно соединиться с базой данных и все графики были недоступны.
Для решения данного рода проблем следует зайти на сам сервер мониторинга
и выполнить следующие команды:
service mysqld restart
service httpd restart
В случае если процедура, описанная выше не помогла и сервер работает
очень медленно, то логичнее перезапустить его командой init6.
Далее необходимо будет заново смонтировать все графики. Для этого
необходимо последовательно вводить команды, указанные ниже:
mount 172.30.38.4:/var/log/stat/ /home/statistics/p4m/pppr/
mount 172.30.29.66:/var/cti/omni/Logs/in /home/statistics/ussd/ugs1a
mount 172.30.29.67:/var/cti/omni/Logs/in /home/statistics/ussd/ugs1b
mount 172.17.2.10:/home/statisticsmanager/log/
/home/statistics/whc/whc_new/whc1
mount 172.17.2.11:/home/statisticsmanager/log/
/home/statistics/whc/whc_new/whc2
mount 172.17.2.17:/home/statisticsmanager/log/
/home/statistics/whc/whc_new/whc3
mount 172.30.29.46:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe1b
mount 172.30.29.45:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe1a
90
mount 172.30.29.62:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe6b
mount 172.30.29.61:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe6a
mount 172.30.29.59:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe5a
mount 172.30.29.60:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe5b
mount 172.30.29.54:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe4a
mount 172.30.29.55:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe4b
mount 172.30.29.44:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe3b
mount 172.30.29.43:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe3a
mount 172.30.29.51:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe2a
mount 172.30.29.50:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mo/SMPP/stat_sfe2b
mount 172.30.29.110:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mt/SMPP/stat_sfe1
mount 172.30.29.112:/home/smsc/site/trace/stat_backup.d
/home/statistics/smsc/mt/SMPP/stat_sfe2
mount 172.30.28.9:/var/log/stat /home/statistics/fd/dsu2a
mount 172.30.28.58:/home/omni/ccs2b/tmp/ /home/statistics/fd/ccs2b/
91
mount 172.30.28.49:/home/omni/ccs2a/tmp/ /home/statistics/fd/ccs2a/
mount 172.30.28.10:/var/log/stat /home/statistics/fd/dsu2b
Бывали так же случаи что проблема возникала с определенным
графиком. В таком случае необходимо было разобраться в проблеме более
детально.
Итак, например, появилась проблема с графиком SMSC, он показывает
только абсолютно прямую линию, что является не корректно, так как трафик
на SMSC как правило поступает хаотично.
Для решения такого случая была разработана следующая процедура:
заходим на сервер мониторинга
проходим по пути /home/statistics/smsc/mt (здесь хранятся все файлы,
которые сервер мониторинга получает от системы SMSC) и находим
файлы
m3ua mt_prep.sh SFE sfe1_stat.txt sfe2_stat.txt sfe3_stat.txt sfe4_stat.txt
sfe_mt_stat.txt SMPP smsc.txt sum_sfe_mt.py
для конкретизации того что имеется проблема можно запустить скрипт
mt_prep.sh (данный скрипт проводит анализ файлов, которые поступили
от SMSC)
[root@monitoring ~]# /home/statistics/smsc/mt/mt_prep.sh
sfe1_stat.txt
100% 1667KB 1.6MB/s 00:00
sfe2_stat.txt
100% 1665KB 1.6MB/s 00:00
sfe3_stat.txt
100% 1665KB 1.6MB/s 00:00