День добрый. Сетевая топология звезда с самостоятельными узлами на лучах. Есть места где длинные лучи (за лучевым узлом стоит еще конечная станция). Линки ABC+F, открытый план нумерации. Возьмем один луч с последовательностью: 1. Центральная (узловая); 2. Транзитная на луче; 3. Конечная на этом же луче. На 2 и 3 есть номера вида 64ХХ. На 2 и 3 они распределены как бог на душу положил. Если я на других лучах и центральной напишу в префикс плане Routing number 64, сеть 0, нод 2, 4 цифры. На лучевой транзитной (2) в префикс плане создам Network number с номерами конечной (3), то на сколько все будет корректно работать с точки зрения сетевой инфраструктуры и как это все потом будет жить, когда поползут бродкасты по сети с автоматическим созданием Network number на каждом сетевом узле?
Надо не глумить голову - грохать routing номера, делать аудит по numbering plan. Routing хороши при жестком разделении нумерации. Если абоненты бегают (расположены как попало) - только network number (они создаются, удаляются и перемещаются вместе с абонентом). Был в практике случай - когда образовалось кольцо - 1-й узел считал, что номер на втором, 2-й, что на первом. При наборе номера - занимались и отбивались по кругу ВСЕ тайм-слоты в потоках. Особо страшного не было - но после нескольких таких звонков - начинал тормозить проц.
К стыду своему аудит не использовал на сети. Бродкасты включены и они живут своей половой жизнью, постепенно расползаясь при локальных изменениях в номерном плане, транковых группах или чего там еще включено было в системных настройках. Если не трудно - пару слов о данном инструменте - на что обратить пристальное внимание, где могут быть подводные камни. Все это связано с изменением плана нумерации с 4-х на 5-ти значную. Может есть смысл тогда дать на всех станциях mao -br (вырубить бродкасты). Грохнуть все старое в префикс плане. Пересоздать абонентов и включить бродкасты - само расползется часика за два (там порядка 6000 абонентов на более чем 10 узлах)? Или аудит существенно надежнее? И нужно ли тогда при аудите выключать бродкасты или пусть ползают? P.S. Сейчас на лабораторной станции готовятся базы для рабочих. Экспорт/импорт. При данном подходе проблемы как раз с префикс планом - крадет безумно много времени, которое можно потратить с большей пользой.
Не все так просто - создавая абонентов в одном месте (при включенном броадкасте) - будет расползаться только если не противоречит плану нумерации на других узлах. При выключенном - вообще не будет ПОТОМ расползаться. Тоько аудитом можно все починить. В принципе с ним не проблема потренироваться - там есть режим симуляции - как бы аудит, с выводом результатов, но без реального изменения базы.
А по сути ничего выключать не надо - это два разных инструмента - броадкаст - рассылка по мере создания. Аудит - принудительная синхронизация. Прелесть в том, что аудит можно делать по отдельным объектам (например только по плану нумерации).
Экспорт/импорт - дивная вещь (наверное еще speed dial есть, hunt groups).
Спасибо за советы. Мораторий на изменение баз данных уже объявлен, а то что делается - протоколируется в журнал. Перед переходом безусловно все базы будут сохранены и отложены, если потребуется откат. Здесь все как обычно. Лабораторная АТС с различными релизами на винтах/партициях будет стоять под парами не в сети дабы быстро посмотреть на то, что было. С пословицей сем раз отмерь - один раз отрежь знакомы... Да и не один человек будет переход делать, командой.
Вообще смена нумерации классная штука - DID трансляторы, ентити, потом стартовав - вспоминаешь, что в Ext.services/ trunk COS - для R1.5 указано сколько цифр принимать. Почистив абонентов (при проблемах с броадкастом) - поостается чего-то в phone book. Главное аккуратно - и попорядку. (особенно хорошо если для перефирийных станций на время работ какую-то времянку по внешним линиям можно организовать).
Энтити, ДиДиАй траслятор, калбэк транслятор, количество цифр в транк группе - об этом помним, но как то не посчитали сверх трудоемкой работой, т.к. транковая группа только на центральном, трансляторы правятся на автомате, энтити абонентов и транков пустые: Installation No. (ISDN) : -------- Supplement.Install.No. (ISDN) : -------- Вот почтовые ящики перелопатить на голосовой почте... как то даже не представляю себе что делать. Выход вижу - достать ее на время перехода, а потом самым извращенным способом переставить софт.
Сеть 10 узлов, общая емкость чуть более 4,5 тысяч абонентов. Основная работа по смене плана нумерации заняла чуть более 7 часов. Голосовую почту просто пристрелили. От аудита отказались. Работали три человека. Вот такая статистика...
Поимели аналогичный опыт, переход 4 -> 5 цифр. Сеть - 19 узлов ОХЕ, емкость - 6,3 тыс. абонентов + 90 ОХО. Основная работа - чуть более 3 суток, работало 2,5 человека. Были веселые вещи. 4 центральных узла начинали в Офф-лайне(2 на ЦПУ, 2 на виртуалке, т.к. Апплаянс), но 4760i на одном из узлов осилила импортировать только 600 с чем-то абонентов из 1900, поэтому продолжили в он-лайн. После этого сюрприз преподнесла обычная ОмниВиста - отказалась работать, т.к. кол-во абонентов превысило лицензии, т.к. у ней были и старые и новые абоненты. Вылечилось запуском Daily Job (синхронизация). Файлы для 4760i и для обычной 4760 - не совместимы между собой, поэтому экспортировать надо было из под обеих систем. Для правки файлов оказался очень удобен редактор notepad++. Нюансы были с номерами, начинающимися на 4, т.к. были типы аппаратов 4001, 4004, 4010, 4020 и т.п. Экспортировали абонентов, DDI трансляторы, группы поиска, на центральном узле ещё Speed Dial and Phonebook. Но оказалось, что поле Displayed Name не входит в фонебук. А номера там входят в название в виде текста, причем в разных местах и спереди и сзади, и из-за жесткого ограничения длины поля в 16 символов, пришлось править вручную. Ещё неделю исправлялись средние ошибки. Исправление мелких ошибок продолжается третью неделю, т.к. долго не сообщают об ошибках. На вопрос, почему раньше не сообщали - ответ - думали, само наладится. Аудитом активно пользовались, в т.ч. для удаления сетевой группы поиска.
