Alcatel-Lucent OXE. Перезагрузка платы CPU, резервное копирование, смена роли платы.

Предисловие

За четыре года администрирования телефонных станций Alcatel-Lucent у меня накопилось некоторое количество мануалов, которые я писал для себя. Прошло некоторое время с той поры, и я решил вывалить это добро в сеть.

Самая суть

OXE поддерживает возможность резервирования CPU. В конфигурации, с которой мне довелось работать, на каждой телефонной станции было установлено по две платы CPU (CPU7-2). Одна из этих плат находится в рабочем (активном) режиме, вторая – в резервном. Каждой станции соответствуют три IP-адреса:

• Первый – IP-адрес основной платы, 
• Второй – IP-адрес резервной платы, 
• Третий – «виртуальный» адрес, который всегда ссылается на ту плату, которая в данный момент работает в активном режиме. 

Через систему управления OmniVista можно в режиме конфигурации зайти на любую станцию и посмотреть установленные платы, их адреса и в каком режиме они находятся (см. Рис. 1):

Рис. 1.

В полке ACT платы CPU располагаются по центру кристалла, в слотах 6 и 20. При этом, как правило, если станция функционирует в штатном режиме, роль основной платы выполняет та, которая установлена в слоте №6. При доступе на эту плату через telnet она имеет имя вида xb….

Для доступа через telnet к платам CPU лучше пользоваться программным обеспечением putty или его форком kitty. 

Проверка состояния платы

Залогинившись на плату, первым делом смотрим на строку приглашения. Она должна выглядеть следующим образом (боевой пример с 6-го узла ABC-F-сети, состоящей из семи станций):
(106)xb001006>
В скобках указывается номер узла в сети ABC-F. Если в скобках находится буква E, значит, что-то не так, и на плате не запущены сервисы телефонии.
Чтобы узнать роль платы, на которую мы залогинились, необходимо выполнить команду role:
(106)xb001006> role
MAIN
Если бы плата была резервной, мы бы получили ответ STAND-BY.
Теперь необходимо проверить состояние синхронизации с резервной платой CPU, выполнив команду twin:
(106)xb001006> twin
Tue Nov 15 08:17:07 GMT-4 2011
Usage : twin [Redundancy Cpu Enable (y/n)]
Role and CPU positions:
Role of the CPU : MAIN
CPU position : 06
CPU address : 10.162.67.70
Twin CPU position : 20
Twin CPU address : 10.162.67.69
Redundancy State:
Duplicated configuration : YES
Wished sig. transfer mode : C1 signalling channel
Used sig. transfer mode : C1 signalling channel
Transmission CPU-CPU : READY
Telephony redundancy : READY
monitel redundancy : READY
memloader redundancy : READY
All applications redundancy : READY

В выводе данной команды мы видим, в каких позициях установлены основная и резервная плата, их IP-адреса, а также состояние сервисов репликации данных между платами. Если состояние сервисов отлично от READY, значит синхронизация между платами нарушена, и менять роли плат не рекомендуется. В таком случае нужно залогиниться на резервную плату и вручную скопировать базы с основной через интерфейс команды swinst. Об этом речь пойдёт позже.

Ещё перед тем как всё ломать, рекомендуется проверить состояние остальных плат конструктива при помощи команды config. Аргумент для этой команды – номер кабинета ACT (к примеру, в станции ГУ их два: 0 и 2). Можно выполнить команду config all, и тогда мы сможем увидеть все сконфигурированные кристаллы станции, в т.ч. виртуальные:

(106)xb001006> config 0
Tue Nov 15 08:32:49 GMT-4 2011
+-------------------------------------------------------------------+
| Cr | cpl| cpl type | hw type | cpl state | coupler ID |
|----|----|------------|-----------|--------------|-----------------|
| 0 | 0 | NPRAE|---------- | IN SERVICE | 3BA23254ABJE02 |
| 0 | 2 | eUA32|---------- | IN SERVICE | 3BA23266AAJA03 |
| 0 | 4 | eUA32|---------- | IN SERVICE | 3BA23266AAJA03 |
| 0 | 6 | CPU7_STEP2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 8 | NDDI2|---------- | IN SERVICE | 3BA23171ABBE02 |
| 0 | 9 | eUA32|---------- | IN SERVICE | 3BA23266AAJA03 |
| 0 | 11 | eUA32|---------- | IN SERVICE | 3BA23266AAJA03 |
| 0 | 12 | eZ32|---------- | IN SERVICE | 3BA23265ABLB03 |
| 0 | 14 | EMTL|---------- | IN SERVICE | 3BA53116AAAB |
| 0 | 15 | INTIPA| INT-IP | IN SERVICE | 3BA23193ACJF05 |
| 0 | 17 | BRA2|---------- | IN SERVICE | 3BA23073ABJD04 |
| 0 | 20 | CPU7_STEP2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 22 | BRA2|---------- | IN SERVICE | 3BA23073ABJD04 |
| 0 | 24 | BRA2|---------- | IN SERVICE | 3BA23073ABJD04 |
| 0 | 25 | GPA2|---------- | IN SERVICE | 3BA23241AAJC05 |
| 0 | 26 | RMA|---------- |ONLY MAO FILE | BAD PCMS CODE |
| 0 | 27 | NDDI2|---------- | IN SERVICE | 3BA23171ABBE02 |
+-------------------------------------------------------------------+
> Reference rack not set

В идеале в столбце cpl state все состояния плат кроме RMA должны быть IN SERVICE, а в поле coupler ID напротив всех плат кроме CPU и RMA должны находиться идентификаторы плат. Если состояние какой-нибудь платы не соответствует описанному, можно попробовать сбросить её командой rstcpl x y, где x – значение первого, а y – значение второго столбца из таблицы, выдаваемой командой config. 

Это, соответственно, номер кристалла и номер платы.

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

Смена ролей между основной и резервной платой

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

Зачем вообще нужен перенос ролей? Он полезен в одном из следующих случаев:​ 

• Какая-либо неисправность основной платы; 
• Необходимость перезагрузки платы (в случае смены времени, например) ; 
• Резервное копирование данных с жесткого диска платы; 
• Установка обновлений; 

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

Потеря синхронизации между платами

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

1. Остановить телефонию;
2. Выполнить команду swinst (пароль по дефолту: SoftInst, но ДОЛЖЕН быть сменён);
3. Выбрать последовательно: Expert Menu - Cloning & duplicate operations - CPU cloning;
4. По очереди выполнить команды: Cloning Linux data, Cloning delivery и Cloning databases. Со всем соглашаться.

Резервное копирование HDD станции

Теперь, когда мы всё умеем проверять, рассказываю методику резервного копирования жёстких дисков АТС, осуществлять которую заставила меня судьба.
Для успешного осуществления резервного копирования нам понадобится следующее барахло:

• Ноутбук или десктоп. Там должен быть COM-порт (подойдёт USB-переходник), Ethernet-порт, CD-ROM, два USB-порта. 
• Переходник SATA-USB. 
• Загрузочный CD-ROM Acronis True Image. 
• Отвёртка с насадкой типа «звёздочка». 
• Кабель для COM. 
• Ethernet патч-корд. 

По идее здесь должна быть информация о том, как законнектиться на COM-порт или воткнуть сетевой кабель в Ethernet-разъём АТС-ки, чтобы можно было получить telnet-доступ к плате, но я пока опущу эти базовые сведения. Будем считать, что мы уже залогинились.

1. Логинимся на основную плату CPU (20-й слот).
2. Проверяем всё так, как описано во втором пункте данного руководства.
3. Меняем роли плат.
4. Выключаем плату, ставшую резервной, при помощи команды shutdown.
5. Вынимаем плату из АТС. Откручиваем три болта крепления переходника HDD, откручиваем три болта крепления HDD к переходнику, вынимаем HDD из переходника.
6. Подключаем HDD к переходнику SATA-USB, переходник втыкаем в рабочую станцию. Загружаемся с диска, бекапим.
7. Втыкаем диск обратно в плату, плату в АТС. Включаем.
8. Логинимся на вторую плату CPU (6-й слот). Проверяем, что забекапленная плата поднялась, находится в режиме STAND-BY, синхронизация ок, телефония на ней запустилась.
9. Повторяем пункты 2-8 для второй платы.

Резервное копирование настроек станции по сети

Ежедневные архивы настроек станции лежат на самой станции, на активной процессорной плате, в каталоге /usr4/BACKUP/DAY. Всё, что нам нужно – это забрать эти настройки по FTP.
На гитхаб лежит готовый скрипт с комментариями, конфигурационный файл для скрипта, содержащий построчно имя станции, IP-адрес, имя и пароль пользователя для FTP-подключения и путь, куда сохранять скачанное.

Получение OPS-файлов по сети

OPS-файлы тоже можно забрать по FTP, они на станции в каталоге /usr4/BACKUP/OPS/. Однако, перед тем, как забрать файлы, необходимо сформировать их свежую версию, выполнив на станции следующие действия:

1. Залогиниться на основную плату под пользователем mtcl;
2. Запустить swinst;
3. Выбрать п. 1 Easy menu;
4. Выбрать п. 5 Backup OPS files on cpu disk;
5. Подтвердить бекап файлов Confirm the backup of OPS files (y/n, default y): y

Все эти действия можно выполнить автоматически, используя программное обеспечение под названием Telnet Scripting Tool. Для этого необходимо сформировать Telnet-script в формате данной программы и скормить его ей.
На гитхабе также лежит скрипт сбора OPS-файлов, пример конфигурационного файл станций и исполняемый модуль Telnet Scripting Tool. По каждой станции также ведётся лог выполненных команд, который пишется в этот же каталог.