12
./test1.sh соответственно на второй консоле второй скрипт, на третьей
третий.
ВАЖНО!
Перед тем как запустить скрипт, необходимо выдать данному скрипту
права, на чтение\запись\формирование\удаление. Команда для выдачи прав
выглядит примерно так:
chmod 777 ./test1.sh
После выполнения скрипта должны сформироваться три файла sort1,
sort2, sort3.
Далее с помощью notepad клиента необходимо скопировать все номера
из 1 и 3 файла во второй и выполнить следующую команду:
less sort2.txt | sort +9 | uniq » sorting_total.txt (данная команда выполняет
фильтрацию, сортировку и формирует новые данные в текстовый файл
sorting_total.txt)
После этой команды должен появиться новый файл "sorting_total.txt"
Далее необходимо зайти в утилиту SQL Developer и зайти в базу
данных MMSC и выполнить следующий запрос:
select main_phone from subscriber_common order by 1 asc; Данный запрос
выводит общее количество абонентов, которые находятся на данный момент
в БД.
Должно появиться большое количество номеров абонентов. Всех их
необходимо выделить и скопировать в xlsx документ, а затем уже перевести в
текстовый документ. Делается это для удобства, а так-же для возможности
корректной работы следующего скрипта.
Далее важно открыть созданный файл и удалить оттуда первую строку,
номер там должен быть 0000000- данный номер является техническим и
13
необходим для корректной маршрутизации элементов БД, лог файлов, и CDR
(Call Data Record-записи об активности абонета) записей.
После нужно переместить файлы 3profiles.py (описание ниже),
sorting_total и new 2 в c:/users/учетная запись администратора MMSC/, при
этом необходимо переименовать файлы sorting_total и new 2 в sort.txt и
base.txt соответственно - данное действие выполняется с рабочего
компьютера администратора системы MMSC.
Теперь необходимо открыть cmd (Win+r, cmd, Enter) и выполняем
следующую команду
start 3profiles.py
Данный питоновский скрипт был разработан для выполнения сравнения
данных БД и нашего отсортированного файла, для формирования файла с
номерами, которые необходимо удалить.
Выглядит скрипт следующим образом:
import sys
import time
a = []
with open('base.txt') as f:
a = f.read().splitlines()
b = []
with open('sort.txt') as d:
b = d.read().splitlines()
rezult=list(set(a)-set(b))
timestr = time.strftime("%Y%m%d")
f=open('HIACommands'+timestr+'.tmp', 'w')
for x in rezult:
14
rezult[rezult.index(x)]='d '+x+'\n'
f.writelines(rezult)
f.close()
После ввода команды необходимо подождать некоторое время, как
правило это час или полтора.
После того как скрипт 3profiles.py закончит свою работу должен
появиться файл "profiles_test.txt", необходимо открыть файл и проверить его
на наличие технических номеров, о которых говорилось выше. Открывать и
выполнять поиск, лучше всего через редактор notepad, так как данный
редактор лучше всего справляется с файлами большого объема.
Теперь необходимо зайти на сервер базы данных MMSC и выполняем
команду hastatus -sum (с помощью данной команды можно посмотреть
процессы и на каком из серверов они бегут, что-бы узнать где сейчас активен
компас - процесс, отвечающий за обработку профилей абонентов.)
Переименовываем получившийся после питон скрипта файл в
HIACommands20160526.tmp – это необходимо что бы сервер понял
сформированный список номеров и закидываем его на активный сервер в
директорию:
/data/APPS/compas/prov/out
После чего, нужно снова открыть консоль и выполнить команду
./startBatch.sh - активирует скрипт который выполняет удаление профайлов
номеров находящихся в списке HIACommands20160526.tmp.
После этого начинается удаление ненужных профайлов.
Работает данный скрипт как правило 5-6 часов, результат представлен
на скриншоте ниже.
15
Рис.2 Результат работы скрипта по удалению профайлов на MMSC
16
1.2. Удаление партнерского соединения из таблицы
маршрутизации MMSC
Для выполнения задачи по удалению партнерского соединения из
таблицы маршрутизации, необходимо зайти на сервера отвечающие за
логические операции на системе MMSC.
Так как серверов, отвечающих за логику на MMSC четыре, то
изменения необходимо выполнить на всех четырех.
Далее необходимо выполнить команды:
/opt/path/global/bin/mgr -w mmsc remote route mms.test.uz DELETE
111.22.33.44
Команда, указанная выше, удаляет маршрутизацию в сторону партнера
test имеющего IP адрес 111.22.33.44
/opt/path/global/bin/mgr -w mmsc remote domain del mms.test.uz
Команда, указанная выше, удаляет домен test
Затем необходимо перейти к файлу, хранящему маршруты:
cd $PATH/adrData.xml
В данном файле хранятся все маршруты, прописанные на MMSC, так
как до этого мы удалили активное соединение к партнерской системе,
необходимо так же удалить все строки маршрутизации в файле adrData.xml
для исключения возникновения ошибок о неверной маршрутизации.
Открываем файл командой:
vi adrData.xml
Находим необходимую строку с названием test и жмем два раза подряд
клавишу d ней, строка удалится. После выполнения данной операции
необходимо сохранить этот документ и выйти из него, для этого необходимо
выполнить команду :wq! В самом файле.
17
После нужно перегрузить процесс, отвечающий за таблицу
маршрутизации, перезагрузка требуется для применения новых настроек.
Замечу, что сервис не будет страдать если выполнять перезагрузку
поочередно.
mms_control rel_mon restart
Ждем пока не появится:
Starting relay_monitor
mms4:/usr/mms/dsu/APPS/share/common/config.UI_V_2.0_04/Adr[44]
Broadcast Message from mms (???) on mms4 Thu Jan 5 23:51:02...
The MMS Relay is running
После выполнения данной процедуры, маршрут test с ip адресом
111.22.33.44 будет окончательно удален из системы.
18
1.3. Решение проблем с базой данных системы MMSC
В ходе работ по администрированию MMSC, возникали проблемы с
распределением основных процессов базы данных, обнаружилась данная
проблема благодаря системе мониторинга OVO на базе HP которая считывает
с сервера базы данных последние логи о состоянии системы, анализирует их
и выдает в итоге в табличном виде подсвечивая аварию определенным цветом
(в зависимости от критичности аварии: красный-критично, оранжевый-
средней критичности, синий-минимальная критичность).
Возникновение ниже приведенной аварий характеризуется как правило
проблемами с питанием, железом или же сбоем в работе логики системы.
В данном случае, в результате не корректно проведенных работ со
стороны сотрудников энергоснабжения, часть серверов MMSC было
перезагружено, по причине этого в самой системе MMSC произошел сбой в
работе логики и такие процессы как OMAPP –который отвечает за
отслеживание мультимедийного сообщения (прием, обработка, доставка,
статус доставки) и MIPS – процесс отвечающий за поддержку сетевого
почтового ящика абонента, где хранятся мультимедийные сообщения
абонента, до тех пор пока он их не откроет.
— SYSTEM STATE
— System State Frozen
A bec1 RUNNING 0
A bec2 RUNNING 0
— GROUP STATE
— Group System Probed AutoDisabled State
B Base bec1 Y N ONLINE
19
B Base bec2 Y N ONLINE
B CDB bec1 Y N ONLINE
B CDB bec2 Y N OFFLINE
B CDRM bec1 Y N ONLINE
B CDRM bec2 Y N ONLINE
B COMPAS bec1 Y N ONLINE
B COMPAS bec2 Y N OFFLINE
B ClusterService bec1 Y N ONLINE
B ClusterService bec2 Y N OFFLINE
B MIPS bec1 Y N ONLINE
B MIPS bec2 Y N OFFLINE|FAULTED
B NTPS bec1 Y N ONLINE
B NTPS bec2 Y N OFFLINE
B OMAAPP bec1 Y N STARTING|PARTIAL
B OMAAPP bec2 Y N OFFLINE|FAULTED
B RDB bec1 Y N OFFLINE
B RDB bec2 Y N ONLINE
B SCHEDULER bec1 Y N OFFLINE
B SCHEDULER bec2 Y N ONLINE
B SRG bec1 Y N ONLINE
B SRG bec2 Y N OFFLINE
— RESOURCES FAILED
— Group Type Resource System
C MIPS Application MIPS_APP bec2
20
C OMAAPP Application OMA_APP bec2
— RESOURCES ONLINING
— Group Type Resource System IState
E OMAAP Application OMA_APP bec1 W_ONLIN
Для того что бы поправить процессы и восстановить штатную работу
системы необходимо следующее:
-выполнить команды:
hagrp -clear MIPS - очищает полностью процесс MIPS
hagrp -clear OMAAPP - очищает полностью процесс OMAAPP
hagrp -offline OMAAPP -sys bec2 - полностью отключает процесс
OMAAPP
hagrp -offline MIPS -sys bec2 - полностью отключает процесс MIPS
Данная процедура выполняется для банального сброса процессов, что
бы при дальнейшем запуске они снова не зависли.
Теперь выполнив очистку и выключение, необходимо запустить
процессы:
hagrp -online OMAAPP -sys bec1
hagrp -online MIPS -sys bec1
На втором сервере статус двух этих процессов автоматически перейдет
в статус offline, но не стоит путать данный режим с полным отключением, на
самом деле на втором сервере, данный процесс будет находиться в спящем
режиме и при возникновении каких-либо проблем с первым сервером,
процесс сразу же перейдет в статус online
Далее проверить результат командой: hastatus –sum
Пример результата выполнения данной команды приведен ниже:
21
— SYSTEM STATE
— System State Frozen
A bec1 RUNNING 0
A bec2 RUNNING 0
— GROUP STATE
— Group System Probed AutoDisabled State
B Base bec1 Y N ONLINE
B Base bec2 Y N ONLINE
B CDB bec1 Y N ONLINE
B CDB bec2 Y N OFFLINE
B CDRM bec1 Y N ONLINE
B CDRM bec2 Y N ONLINE
B COMPAS bec1 Y N ONLINE
B COMPAS bec2 Y N OFFLINE
B ClusterService bec1 Y N ONLINE
B ClusterService bec2 Y N OFFLINE
B MIPS bec1 Y N ONLINE
B MIPS bec2 Y N OFFLINE
B NTPS bec1 Y N ONLINE
B NTPS bec2 Y N OFFLINE
B OMAAPP bec1 Y N ONLINE
B OMAAPP bec2 Y N OFFLINE
B RDB bec1 Y N OFFLINE