Как гласит народная пословица: «Переезд — это как половина пожара». Но все еще сложнее, если переезжает ИТ-оборудование, работающее в режиме онлайн. Меня зовут Юрий Десятниченко, я главный инженер в РТК-Сервис и сегодня я расскажу вам о том, как мы перевозили коммутационные полки «Ростелекома» в минимальные ночные окна. Под катом — подробный рассказ о том, как мы готовились к этому проекту, где нашли дополнительные ресурсы и как умудрились сделать все за месяц.
Итак, вот с чего все началось. Компания «Ростелеком» решила освободить одно из зданий в Оренбурге. Здание выставили на продажу, в связи с этим возникла задача переместить из него все оборудование, включая средства Междугородной и Международной телефонии. Все коммутационное оборудование нужно было перенести на другую площадку в пределах стандартного окна ночных работ, а также с минимальным перерывом сервиса.
Три сценария
У Заказчика было три (на наш взгляд) варианта действий:
1. Для отважных. В одну ночь взять, выключить всё оборудование на старой площадке, демонтировать его, погрузить в машину, перевезти на новую площадку, смонтировать, запитать и …. Молиться чтобы оно заработало. Но мы же знаем, что если что-то может пойти не так, то оно обязательно пойдёт не так. В этом плане пойти не так могло очень многое. С большой долей вероятности, коллеги бы встретили рассвет с нерабочим узлом связи. И это была бы не та ситуация, когда можно было бы просто сделать Rollback (откат работ) и сервис бы восстановился. В общем, вариант очень рискованный, который мог бы вылиться и в прямые финансовые, и в репутационные потери.
2. Для богатых. Построить абсолютную копию той площадки, которую собираются переносить, на новом месте, скопировать конфигурацию со старой площадки на новую. Потом просто (это только на словах, конечно, просто) выключить старую и включить новую. Менее трудозатратно, но более дорого. Примерная стоимость оборудования – 10-15 млн рублей.
3. Для умных. Итак, лишних денег нет, лишнего оборудования нет. Значит рассчитывать приходится только на профессионализм сотрудников. А поскольку речь шла про оборудование для телефонии Huawei, в «Ростелекоме» хорошо знают, что мы умеем с ним работать. Собственно говоря, мы уже не первый год ведем постгарантийное обслуживание всего оборудования Huawei на сети нашего ключевого заказчика. В итоге коллеги обратились к нам с просьбой оценить возможность такого переноса. И мы нашли способ реализовать его максимально точно, контролируемо и безопасно, с минимальными потерями сервиса, используя потенциал существующего оборудования.
Секрет двух полок
Секрет успеха этого проекта в том, что комплектация узла состояла из двух одинаковых полок с коммутационными платами. Для повышения надежности все коммутационные платы дублированы. А это значит, что на самом деле у нас есть двойной комплект оборудования. Задача состояла в том, чтобы высвободить одну полку и все резервные платы, после чего собрать из них точную аппаратную копию работающего элемента. Основную сложность составляла конфигурация плат и резервирования для них – это базовые данные, которые поменять на работающем оборудовании стандартными способами нельзя. Но нашлись способы нестандартные: прямая модификация базы данных SQL, в которой хранится вся конфигурация. Давайте разберем это подробнее. Итак, вот две полки SoftX3000 в графическом интерфейсе системы управления:
Платы, обозначенные зеленым – активные. Голубым – резервные. Основная сложность – перераспределить FCCU. На этих платах находятся обработчики всей сервисной логики, прописаны абоненты и каналы транковых групп. Три группы плат, соответственно три модуля с внутренними номерами 22, 23 и 24, каждый берет свою часть нагрузки. Если просто вытащить резервные, слот за ними останется закреплен, и на нулевой полке не будет места чтобы вместить 3 модуля (позиции 7 и 9 занимать нельзя – зарезервированы системой под SMUI). Просто так в терминале управления удалить резервную также нельзя – это базовая конфигурация. Сделали так:
SoftX3000 хранит всю конфигурацию в СУБД Microsoft SQL. Данные по платам прописаны в таблицах Tbl_DloadInfo и Tbl_BoardDesc.
Формат данных в этих таблицах следующий:
Удаляем резервные платы FCCU следующим скриптом через SQL Query Analyzer:
use Bam;
delete from tbl_DLoadInfo where iFrameNo = 0 and iSlotNo = 3
delete from tbl_DLoadInfo where iFrameNo = 1 and iSlotNo = 1
delete from tbl_DLoadInfo where iFrameNo = 1 and iSlotNo = 3
update tbl_BoardDesc set iStatus = 0 where iFrameNo = 0 and iSlotNo = 3 and iLocation = 0
update tbl_BoardDesc set iStatus = 0 where iFrameNo = 1 and iSlotNo = 1 and iLocation = 0
update tbl_BoardDesc set iStatus = 0 where iFrameNo = 1 and iSlotNo = 3 and iLocation = 0
update tbl_BoardDesc set iAssistBoardSlotNo = -1 where iFrameNo = 0 and iSlotNo = 2 and iLocation = 0
update tbl_BoardDesc set iAssistBoardSlotNo = -1 where iFrameNo = 1 and iSlotNo = 0 and iLocation = 0
update tbl_BoardDesc set iAssistBoardSlotNo = -1 where iFrameNo = 1 and iSlotNo = 2 and iLocation = 0
Далее, перемещаем активные платы с 1-й полки на нулевую стандартной командой в терминале управления:
MOD MDUPOS: MN=23, NFN=0, NSN1=3;
MOD MDUPOS: MN=24, NFN=0, NSN1=5;
После этого форматируем данные и перегружаем всю полку. В итоге получаем желаемый результат: в слотах 2, 3 и 4 нулевой полки стоят активные платы FCCU модулей 22, 23 и 24.
Остальное – дело техники. Сигнальные линки с плат BSGI 1-й полки переносим на BSGI 0-й полки стандартными средствами, просчитав предварительно по статистике что производительности хватит. После этого 1-я полка свободна, можно перевозить и комплектовать платами, которые стояли в резерве.
Вперед!
Итак, мы взяли неделю на подготовку и 3 недели на выполнение. Общее время перерыва сервиса за 4 ночных работы составило 2 часа и 20 минут. Сейчас я расскажу, как это было.
Неделя номер 0: Подготовка, изучение схем подключения и инфраструктуры, анализ конфигурации, подготовка планов ночных работ и скриптов.
Неделя номер 1: Оптимизация конфигурации, перенос нагрузки с 1 на 0 полку, с выполнением скриптов и рестартом полки. Контроль успешности снятия нагрузки с 1 и наблюдение за сервисами на 0 полке.
Неделя номер 2: Выключение 1 полки, перевоз её на новую площадку вместе с IP оборудованием и SBC, подготовка и запуск 1 полки (прогрузка БД, лицензий и ПО).
Неделя номер 3: Переключение сервисов на новую площадку, контроль успешности. Выключение оборудования на старой площадке и перенос его на новую. Включение и распределение нагрузки между 0 и 1 полками (приведение в исходное состояние). Финальный контроль успешности.
Заключение
Эта операция была в каком-то смысле хирургической: нужно было не потерять сервис, не сломать то, что работает. Но оно того стоило: минимальные простои, полностью управляемый процесс, каждый шаг имел простую возможность откатить изменения. На самом деле очень много деталей и тонкостей, и здесь, просто как факт, не обойтись без большого опыта работы с оборудованием и глубокого понимания процессов и принципов его работы.
А вообще очень полезно изучить реальную инфраструктуру, оценить особенности схем ее работы и так далее. Может быть окажется так, что у вас на самом деле есть те ресурсы, которые необходимы для переезда, миграции, расширения сервисов или мало ли чего еще!
Нам в РТК-Сервис нередко подкидывают такие проекты, которые требуют особого подхода, и задачи, решение которых оказывается неочевидным. Я рад, что с нами работают лучшие специалисты сетевым технологиям. А если вы хотите почитать, какие нам частенько достаются «в подарок» трудные или нестандартные проекты, в Telecom Daily выходила статья на эту тему.
Расскажите, а вам приходилось решать задачи со звездочкой? Какие интересные приемы вы для этого применяли?