для чего нужны узел исходящей связи и узел входящей связи

Для чего нужны узел исходящей связи и узел входящей связи

Узел связи представляет собой комплексную систему различных служб и технических средств (мини АТС, WEB и т.д.), а также маршрутизаторов, необходимых для обеспечения соединения с провайдером. С физической точки зрения узел размещается в большой стойке, также в нем устанавливаются маршрутизаторы и серверы.

Если вы владеете собственной телефонной станцией, уделите особое внимание к организации узла связи. Грамотно выстроенная структура АТС способна на протяжении длительного времени поддерживать процесс соединения между аппаратами, а также предоставлять целый ряд дополнительных возможностей.

Помещение для узла связи

Начать нужно с выбора правильного помещения для его размещения, оно не обязательно должно быть большим, главное – пол должен выдерживать нагрузку, которую вы запланировали. Разместите шкафы, стойки и стеллажи так, чтобы они не мешали друг другу и их детали не соприкасались. Обязательно установите систему кондиционирования и ее резерв, чтобы избежать перегрева АТС и их выхода из строя.

Над помещением не должны располагаться коммуникации, по которым проходит вода, а полы в нем обязательно нужно делать несгораемыми. Если в будущем узле есть окна, нужно их затонировать или закрыть фанерой, поскольку попадание солнечных лучей на оборудование нежелательно. В комнате должно быть хорошее освещение, все конструкции из металла нужно обязательно заземлить и дополнительно отгородить материалами, которые не проводят ток. Также рекомендуется разместить в помещении диэлектрические ковры из резины, огнетушители углекислотного типа и аптечку.

Телекоммуникационные стойки и шкафы

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

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

Неважно, что именно вы строите: районный узел связи или же городской, в любом случае необходимо сразу же создавать резервные мощности. В том случае, если один из узлов придет в негодность, вы сможете сразу же перебросить нагрузку на резервный. Особое внимание нужно обратить на то, что в выстроенное вами помещение могут иметь доступ только те, кто обладает соответствующим допуском, это обязательное требование Министерства информационной связи.

Источник

Инфраструктура узла связи от чайника, или очередное строительство серверных — часть 1

Здравствуйте! Начитавшись публикаций на тему строительства ЦОД небольшого хостинг провайдера, а так же «как сделать серверную комнату своими руками», от людей, которые, видимо, не знали как сказать, зачем надо заказывать их услуги, я решил изложить свой опыт строительства небольшого узла связи в течение этого года, для размещения, с последующей регистрацией в Роскомнадзоре, таких объектов, как ОТМУС, ТЗУС, СПД.

В этом году приходилось настолько много информации искать и применять, что я почувствовал свой предел в запоминания полезной информации. Поэтому мне сложно сразу вспомнить откуда я брал информацию (я говорю о приказах Минкомсвязи, Мининформсвязи, Роскомнадзора, СНИП, ВСН… ).

Под катом я постараюсь поверхностно пройтись по всем аспектам, по которым надо принять решение и реализовать в вашей аппаратной.

Инфраструктура помещения

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

Электроснабжение

В зависимости от того, какие у вас планы на ваш автозал, вы можете выбрать определенный уровень защищённости от отключений электроэнергии.

Вы можете открыть любую из частей «Правил применение оборудования транзитных, оконечно-транзитных и оконечных узлов связи» (там 14 частей под разные типы узлов связи) и во всех будет отсылка на

7. Для обеспечения бесперебойности электроснабжения электроприемников I категории надежности, включая электроприемники особой группы I категории надежности, при нарушении электроснабжения на время переключения с одного источника электропитания на другой используются аккумуляторные батареи с емкостью, обеспечивающей электроснабжение электроприемников с расчетным временем разряда в час наибольшей нагрузки не менее 2 часов для электроприемников особой группы I категории надежности и не менее 8 часов для электроприемников I категории надежности.

8. Электроснабжение электроприемников II категории надежности в нормальном режиме осуществляется от двух независимых взаимно резервирующих источников электропитания.

9. В качестве одного из независимых источников электропитания электроприемников II категории надежности допускается использование дизель-электрической станции.

… который в свою очередь утратил силу в связи с кучей изменений… и в общем теперь надо руководствоваться

Но при этом ссылка на 32 приказ есть, а в 97 не расписано, какой узел связи к какой категории электроприёмников относится. В связи с этим не понятно, какую категорию требуется обеспечить. Если вдруг кто в теме — поделитесь, пожалуйста, информацией.

Но допустим вы определились с тем, какая категория электроприёмника у вас и вы принимаетесь её обеспечивать. Для безопасности вашего бизнеса у вас в любом случае должен быть ввод с городской подстанции, ИБП и генератор на 2-5кВт (примерно столько вам потребуется для небольшой аппаратной с двумя стойками, забитыми различным оборудованием). А значит необходимо в вводно-распределительном устройстве (ВРУ) организовать АВР (автоматический ввод резерва) с функциями запуска генератора (можно вручную, если есть дежурная смена на объекте).

Возможно у кого то встанет вопрос, как всё это реализовывать, в каком виде, как разместить?

Итак, вы имеете электроустановку внутри вашего будущего автозала. Дальше вам нужно будет отводить оттуда линии на нагрузку. Ввиду того, что по периметру помещение обычно располагаются стеллажи для оборудования, шкафы для АКБ и прочие металлические конструкции (включая дверь), то хорошо бы сделать по периметру ленту заземления, к которой можно цеплять всё, что вам захочется поставить вдоль стен и будет необходимо заземлить.

Ввиду того, что у ваше оборудование должно быть подключено через ИБП, то первая очевидная линия от вашего ВРУ пойдёт именно к ИБП. В моём случае это 3-х фазный APC Symmetra, которую я бы не советовал покупать, ввиду её текущей стоимости. Можно найти ИБП более скромных производителей. Основными я бы выделил следующие критерии для себя:

Здесь в схеме электропитания есть узкое место — ИБП. Поэтому конструкция ИБП должна быть либо такая, в которой ломаться нечему (APC Symmetra например, без силовых и батарейных модулей представляет из себя просто медные шины (практически)).

Если вы используете ИБП индивидуально на шкаф, то позаботьтесь о том, что бы в шкафы были линии от разных ИБП, а блоки питания оборудования были подключены к разным ИБП.

Или же есть третий вариант: у вас ИБП позволяет забрать от него силовую линию, затащить обратно в ваш АВР, а дальше собрать схему, при которой можно подавать питания на линию либо через ИБП, либо напрямую от городского ввода или генератора. Такая схема позволит снимать ИБП с линии для регламентного обслуживания и ремонта.

С инвертором тока схемы аналогичны схемам с ИБП, если он у вас достаточно серьёзный, что бы на нагрузку линии уходили с более или менее серьёзных клемм. А если у вас небольшие инверторы, то, как правило они и не заточены под то, что бы с ним забирать большим сечением питание на нагрузку. Такие ставятся внутри стойки, где они будут использоваться. А если есть потребность подключить много оборудование (а не одну-две железки), то с клеммной колодки инвертора отводится линия в РЩ в самом шкафу и там через шины или АВ 2P (или через АВ для минуса и шину для плюса) уже отводятся линии на нагрузку.

У меня для целей размещения ИБП и инверторов установленная отдельная каркасная стойка с большой цифрой в значение несущей массы, в которую приходят линии питания от ВРУ с АВР. А затем из которой уходят линии питания на шкафы с оборудованием.

Здесь я бы хотел отметить пару моментов, связанных с выбором материалов и комплектующих:

Расчёт автономности вашей электроустановки и выбор АКБ

Для того, что бы понять, сколько вам нужно купить аккумуляторов (а именно в этом вопрос, потому как это требует много денег), то нет ничего сложно если вы знаете, на какую нагрузку на вашу энергосистему вы рассчитываете в ЧНН (час наибольшей нагрузки). Для встроенных внутрь батарейных блоков информацию по автономности вы найдёте в материалах для ИБП, а для подсчёта необходимой ёмкости внешней сборки нужно перемножить вольтаж сборки на ёмкость и поделить на нагрузку (t=V*Ah/Wt). Но так как разряд аккумулятора это не линейный процесс, то надо в мануалах к аккумуляторам посмотреть графики разряда и в зависимости от времени, которое у вас получилось, применить коэффициент найденный в паспорте. Тогда вы получите более или менее реальное время автономии от вашей системы АКБ. Исходя из этого вы поймёте, какую ёмкость вашей сборки АКБ надо обеспечить.

В статье про строительство собственного маленького ЦОД для маленького хостинг провайдера использовались автомобильные аккумуляторы, ввиду их дешевизны относительно не обслуживаемых АКБ разработанных для применения на сетях связи (особые режимы эксплуатации — постоянный заряд, редкий разряд, длительная отдача). Если хотите через 1-2 года их менять (в зависимости от разрядки и глубины этой разрядки), то конечно можете пользовать таким вариантом. Только надо учесть, что эти АКБ являются обслуживаемые, а значит в случае чего (перегрев например), они могу потечь или испаряться через крышечки — а значит их нужно в отдельное вентилируемое помещение ставить и всё такое… В случае же использования герметичных не обслуживаемых АКБ вы можете размещать их хоть в стойках с оборудованием (на дне шкафа или на консольных полках), эксплуатировать от 3 до 8 лет (смотря какая гарантия от производителя на жизненный цикл) и проводить тестирование вашей системы питания по регламенту.

Альтернативное мнение

Я выше писал про блоки розеток… но на самом деле я считаю, что правильнее подключать оборудование от АВ в РЩ внутри стойки. Так соединение получается надёжным и защищённым. Но тут есть некоторые неудобства. В основном они связаны с тем, что оборудование имеет совершенно конкретную розетку С14, вилку для которого (С13) не всегда можно найти надлежащего качества. В итоге она может там шататься и слабое место уже будет там. К тому же надо учесть, что не все инженеры хотя бы знают что такое ПУЭ, а им надо иметь возможность безопасно включить оборудование (опустим тот момент, что по технике безопасности любой инженер должен быть как минимум с 3-ей группой в корочке по электробезопасности + сопровождение ответственного с 4-ой группой — все мы понимаем реальность бытия).

Инфраструктура кабельных трасс

Для того, что бы прокладывать кабель из разных уголков вашего автозала (от вводов в саму аппаратную или от шкафа с аккумуляторами) вам потребуются кабельные лотки. Это может быть система кабельных лотков под фальшполом, или лотки под потолком, проходящие по периметру помещения и над стойками… В моём случае было принято оптимальное решение: под потолком идут кабельные локти, а в полу был вырезан жёлоб проходящий под телекоммуникационными шкафами, шкафа с АКБ и ответвление к ВРУ на стене. Жёлоб оббит железом (и заземлён), а сверху накрыт 4мм стальными листами, которые так же как и весь остальной пол, покрыты антистатическим не горючим линолеумом. Нужно поставить новые стойки – убрать с нужных мест лючки, поставили стойки, подтащили по жёлобу линии питания постоянного и переменного тока и всё. При этом жёлоб в полу используется только для силовой проводки, а сетчатые локти под потолком используются для медных СЛ и оптического кабеля.

Несмотря на то, что оборудование ещё не инсталлировалось в этот автозал, кабельные локти уже занимаются жгутами медных линий и оптическими кабелями. А именно были сдельны перекидные кроссы между стойками. У меня есть две кроссовые конструкции: стойка однорамная и конструктив с трубчатыми монтажными профилями для 10-ти парных плинтов. Из телекоммуникационных стоек в однорамную стойку приходят жгуты UTP из каждой стойки, которые с обеих сторон расшиты на патч панели. Аналогично организован оптический перекидной кросс.Таким образом любые кроссировки между оборудование в разных стойках выполняется короткими патч-кордами внутри своей стойки. А входящие единичные медные линии в автозал (СКС из офиса на 8 линий и медные соединения с партнёрами тоже приходят на раму с кроссами, после чего перекидываются уже на нужное оборудование.

А здоровенная рама для плинтов мне нужна ввиду необходимости организовать большой объём соединений PRI портов между станционной и транспортной стороной. Плата транспорта SDH или медиа шлюза расшивается сразу на нужную сторону конструктива, затем кроссируется при необходимости обычным кроссировочным шнуром.

Благодаря тому, что силовые кабели у меня идут по жёлобу в полу, а слаботочка заходит в шкафы сверху, они практически не пересекаются друг с другом (у меня есть оборудование, питание которого включается спереди), даже с учётом того, что кроссы расположены на задних монтажных профилях.

Телекоммуникационные шкафы и стойки

По моему мнению, если вы строите узел связи или серверную, где будет ваше основное, или одно из основных мест дислокации, то минимальные размеры шкафа должны быть 800х1000 (ШхГ), стандартной высотой 42U, с цоколем или на 10см приподнятые над полом, а так же отверстиями для ввода кабельной инфраструктуры, как через цоколь, так и через потолок. Хотя я предпочитаю 47U, потому что когда в шкаф всякого набивается, юниты становятся дефицитом и сделать с этим ничего нельзя будет.

И я не просто так написал «размеры шкафа». Я считаю, что стойки (просто двойная каркасная рама) использовать можно только для стендов тестирования и кроссов. Спустя некоторое время эксплуатации ряда стоек, вы обнаружите, что патч-корды были прокинуты лианами между стойками со всех сторон, даже если вы сами любите порядок, то кто-то другой обязательно для ускорения процесса кинет такую соплю, а потом забудет переделать до того, как там пустят клиентский сервис. Именно поэтому должны быть шкафы и у них обязательно должны быть закрытые боковые панели и закрывающиеся двери.

Для того, что бы двери закрывались всегда, необходимо монтажные профили устанавливать хотя бы на 10см вглубь, как спереди, так и сзади. Если их ставить близко к двери — могут возникнуть неудобства с оборудованием, которое выступает вперёд своей передней панелью за монтажные профили, + SFP модуль торчит + оптический патч-корд в нём. Как результат — дверь будет гнуть патч-корды, если вообще сможет закрыться. Буквально недавно из-за такой не продуманности пришлось несколько раз ездить на узел, где у нас был установлен cwdm в арендуемой стойке (к слову сам он даже не выпирал за пределы плоскости монтажных профилей). Дверь могли закрыть по-разному и она по-разному прижимала патч-корды, роняя линки. Хорошо, что поняли в чём дело ещё на этапе тестирования и наколхозили по-быстрому решение. А для того, что бы иметь возможность утопить монтажные профили, и нужна глубина шкафа от 1000мм — в случае приобретения довольного сервера (на 800 например), вы не сможете закрепить салазки на профилях расставленных ближе чем 800мм, а сам сервер не сможет до конца заехать в стойку. (по крайней мере у платформ Intel такая конструкция салазок).

Сами двери бывают стеклянные или перфорированные (кто-то покупает целиком стальные без перфорации). Здесь выбор под задачи и способы обеспечивания климата. Если холодный воздух у вас подаётся в коридор, то смысла брать стеклянную дверь (или дверь без перфорации) никакого нет. Берите перфорированные двери и всё ваше оборудование будет охлаждаться забирая воздух с фронтальной части (сервера особенно), выгоняя нагретый назад. Если же вы подводите рукава с холодом под стойку, то нужно брать стойки с глухими дверями.

В шкафу обязательно должны быть вертикальные органайзеры на переднем монтажном профиле и, по необходимости, на задних. У меня вертикальные органайзеры с обеих сторон, потому как спереди организуется подъём и спуск меди и оптики, а сзади подвод питания к оборудованию и UTP от серверов (опять же медь с данными идёт по одной стороне, а силовые шнуры по другой). Причём при подводе питающих кабелей в стойку, прикиньте, с какой стороны у вас будут блоки питания — с той и подводите линию. Тогда другая у вас будет для укладки меди от серверов и каталистов (для примера) с платами в задних слотах…

Климат

Считается вроде бы не сложно. Если вы сейчас не знаете, какие у вас будут потребности потом, то можно быстро прикинуть и выйти на 2 варианта:

Ещё можно заниматься автоматизацией и мониторингом, в зависимости от того, на что способны кондиционеры… У нас например есть блок управления сплит системой, который мониторит температуры в нескольких точках автозала и задаёт режим работы нескольких кондиционеров.

Но в общем для меня эта тема довольно далека и всё, что нам необходимо было делать по этому вопросу — делала подрядная организация. В планах только прикрутить к этой системе сигнализацию от систем типа netping или чего-то подобного, что бы запускались дополнительные кондиционеры не только, когда большой отключится.

Системы безопасности

Готовясь к вводу в эксплуатацию

В связи с тем, что небольшие операторы связи имеют право регистрировать узлы по упрощённой схеме, с недавних пор отпала необходимость готовить проекты на все инженерные системы узла (электропитание, кондиционирование, освещение, пожаротушение, и кажется был раньше проект кабельных трасс). Это значит, что при подаче документов в Роскомнадзор на регистрацию узла связи, вы имеете право не предоставлять этот пакет документов. Но сделано у вас всё должно быть, потому как проверочные комиссии технадзора никто не отменял и они вполне себе могут прийти и провести инспекцию вашего опасного (или особо опасного) объекта. Поэтому не стоит отступать от реализации всего этого только потому, что ваше руководство выяснило, что ничего этого не надо для регистрации узла. Рано или поздно эти системы отработают и спасут от убытков или смерти.

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

Почему я ничего не написал борьбе с шумом?

Бессмысленно бороться с шумом невиданными стойками с шумоизолирующими панелями… Тишуну можно сделать только тремя способами:

Можно начать с этим документов и постараться понять чего нужно придерживаться. НТП 112-2000 РД 45.120-2000 — документы с кучей ссылок на всё то, на что надо опираться при строительстве узла связи. Из него правда пригодится всем, наверное, только несколько пунктов:

Наверное многие скажут, что не нужно им это всё в серверных, тем более в малом бизнесе. Вы правы, но стремиться к чему-то ведь надо? Выбирайте пределы, которые вы готовы достичь и достигайте. В любом случае норматива из области связи мне кажется самой адекватной и обоснованной.

В следующей части я постараюсь изложить принципы выбора и размещения оборудования, а так же способы подключения к слаботочным сетям и электропитанию.

Все замечания по орфографии, правописанию и опечаткам пожалуйста в личные сообщения.

Так же я буду рад, если вы поделитесь тем, какие решения вы применяли при обустройстве инфраструктура.

PS: простите меня пожалуйста за отсутствие табуляции — в редакторе она есть, но в пост парсером не переносится. Решить этот вопрос никак не смог.

Источник

Архитектура и принципы работы системы

В состав комплекса ECSS-10 входят:

Рисунок 1 — Пример схемы включения комплекса ECSS-10

Гибкий коммутатор SSW является системой, состоящей из набора промышленных серверов и запускаемого на них специализированного программного обеспечения.

В комплексе используются промышленные серверы на платформах Intel и AMD от ведущих производителей.
Конфигурация выбирается в зависимости от требуемых показателей системы (цена, производительность, надежность).
Система ECSS-10 в минимальной версии может быть развернута на одном сервере (без поддержки аппаратного резервирования).
Минимальная конфигурация с поддержкой аппаратного резервирования строится на двух серверах, рисунок 2.
Высоконагруженные решения разворачиваются на большем количестве серверов, число которых определяется параметрами определенного узла связи.

Рисунок 2 — Схема включения оборудования ECSS-10:

Типовые варианты построения систем

ECSS-10 является универсальной системой, на базе которой могут быть построены как типовые узлы связи, так и различные их комбинации.

Узел связи корпоративного уровня

Использование ECSS-10 в качестве коммуникационной платформы корпоративного уровня позволяет:

На рисунке 3 представлена распределённая корпоративная инфокоммуникационная сеть на основе оборудования производства компании Элтекс. В центральном офисе устанавливается платформа ECSS-10, которая является ключевым элементом данной сети. Подключение абонентской ёмкости к платформе осуществляется с помощью программных SIP-клиентов и IP-телефонов напрямую, с помощью аналоговых телефонов — через абонентские шлюзы TAU-72.IP. Стыковка с телефонной сетью общего пользования (ТфОП) выполнена через цифровой шлюз SMG-1016M. Дополнительные офисы и мобильные клиенты подключаются через пограничный контроллер сессий (SBC), который обеспечивает функции безопасности от внешних угроз. В крупных дополнительных офисах возможна установка отдельных платформ ECSS-10 для концентрации внутреннего трафика. Подключение платформ в дополнительных офисах к центральной системе осуществляется с помощью соответствующих SIP-транков.

Рисунок 3 — Пример построения распределённой корпоративной сети на основе ECSS-10

Рисунок 4 — Модель реализации сервиса видео-конференц-связи на основе платформы ECSS-10

Узел связи операторского уровня

Модульная архитектура комплекса ECSS-10 позволяет строить на его основе высоконагруженные отказоустойчивые узлы связи различного уровня: местный, зоновый, оконечно-транзитный, междугородний, международный. Платформа ECSS-10 удовлетворяет всем требованиям действующих российских нормативных документов для Системы оперативно-розыскных мероприятий (СОРМ) и имеет все виды российских сертификатов*.

*Сертификация платформы ECSS-10 на соответствие требованиям для междугородних, международных узлов возможна по дополнительному запросу.

Местный узел связи

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

Рисунок 5 — Пример построения городского узла связи на основе ECSS-10

Рисунок 6 — Пример построения современной IP-сети с использованием на «последней миле» технологии PON

Рисунок 7 — Пример построения сельского узла связи на основе ECSS-10

Зоновый узел связи

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

Рисунок 8 — Пример построения зонового узла связи на основе ECSS-10

Оконечно-транзитный узел связи

Программно-аппаратный комплекс ECSS-10 может быть использован одновременно как для организации единой точки подключения к внешней сети нескольких цифровых АТС, так и для подключения абонентов с помощью абонентских VoIP-шлюзов с единой системой маршрутизации соединений

Рисунок 9 — Пример построения оконечно-транзитного узла связи на основе ECSS-10

SaaS платформа

Возможность логического разделения ресурсов комплекса ECSS-10 позволяет использовать его в качестве облачной платформы для предоставления виртуальных АТС с поддержкой широкого набора сервисов (в том числе видеосвязи и видео-конференц-связи). Оператору/сервис-провайдеру предоставляется гибкий инструментарий для разработки индивидуальных сервисов.

Рисунок 10 — Пример построения SaaS платформы на основе ECSS-10

Применение ECSS-10 позволяет:

Типовые варианты распределения подсистем на серверах

Рисунок 11 — Системы малой емкости

Рисунок 12 — Системы средней емкости

Рисунок 13 — Системы high-end класса

Программные компоненты

Главным элементом системы ECSS-10 является программное обеспечение (далее ПО). ПО состоит из кластеров, выполняющих различные функции. Каждый кластер включает в себя одну или несколько нод. Прикладное программное обеспечение является полностью переносимым, что позволяет использовать любую операционную систему, как семейства Unix/Linux, так и серверные OC от Microsoft, а также использовать широкий спектр аппаратных архитектур, не ограничиваясь серверными платформами Intel/AMD, например, ОС Эльбрус/МЦСТ.

В настоящий момент в системе ECSS-10 используется операционная система с открытым исходным кодом Ubuntu Server. Переносимость, высокая надежность и эффективность ПО обеспечиваются:

В состав ПО системы ECSS-10 входят следующие типы кластеров, рисунок 14:

Рисунок 14 — Функциональный состав ПО системы ECSS-10

Кластер BUS

Одной из важных особенностей ECSS-10 является осуществление взаимодействия между программными компонентами комплекса через интеграционную шину — BUS.

Кластер BUS построен на базе сервера обмена сообщениями (брокера) собственной разработки Mycelium, который поддерживает функционал очередей сообщений и транзакционный механизм обмена. Взаимодействие с клиентами осуществляется по протоколу AMQP (Advanced Message Queuing Protocol) версии 0-10.

При отправке клиентом сообщения на брокер в качестве пункта назначения указывается адрес точки обмена (exchange) на брокере, который представляет собой строку определенной структуры. Точка обмена представляет собой механизм маршрутизации сообщений, который позволяет направить поступающие в точку обмена сообщения в одну или несколько очередей по правилам, регламентированным протоколом AMQP. Далее из точки обмена сообщение попадает в очередь, из которой отправляется клиентам, подписанным на сообщения очереди.
Транзакционность отправки, поддерживаемая брокером, позволяет гарантировать то, что сообщение будет отправлено на брокер, пройдет механизм маршрутизации и поступит в одну или несколько очередей, а значит, не будет потеряно. Если в процессе отправки сообщения происходит ошибка, то клиент об этом незамедлительно информируется.

Для получения сообщения от брокера клиент должен подписаться на определенную очередь. Когда на сообщения одной и той же очереди подписаны несколько клиентов, доставка их осуществляется в режиме равномерного распределения сообщений между клиентами (round-robin). Эта возможность позволяет реализовать в системе режим разделения нагрузки между нодами кластера.
Транзакционность доставки, поддерживаемая брокером, позволяет гарантировать то, что сообщение будет доставлено клиенту. При отказе клиента или ошибке доставки производится повторная доставка сообщения другому клиенту, подписанному на данную очередь.
Взаимодействие через интеграционную шину обеспечивает унификацию механизмов взаимодействия, слабую связанность между подсистемами и позволяет повысить надежность доставки.

Режим разделения нагрузки при доставке сообщения клиенту используется для реализации в ECSS-10 резервирования «active-active». При такой схеме резерва все компоненты находятся в активном состоянии и обслуживают поступающую нагрузку в режиме разделения нагрузки. Конфигурационная информация и операционные данные системы синхронизируются между зарезервированными элементами. Если из строя выйдет какой-либо программный компонент, то за счет механизмов BUS вся поступившая на программный компонент нагрузка (все сообщения) будет считаться не обслуженной, и произойдет её повторная доставка на однотипный резервирующий программный компонент (другую ноду того же кластера), который осуществит обработку данной нагрузки. В случае выхода из строя аппаратной части (хоста) произойдет полное переключение обработки текущей и вновь поступающей нагрузки на оставшиеся в работе компоненты системы (ноды находящиеся на другом хосте). При восстановлении работоспособности вышедшего из строя компонента происходит его регистрация в системе и подписка на требуемые для его работы потоки информации (очереди), что приводит к началу поступления на него сообщений — компонент встает в работу.

Кластер Storage

Кластер Storage выполняет функцию распределенного хранилища конфигурационных данных всей системы. Также в рамках этой подсистемы реализован модуль маршрутизации телефонных вызовов, обладающий высокой производительностью.
Storage использует для хранения конфигурационных данных документо-ориентированной базы данных Mnesia, которая является частью комплекта библиотек OTP (Open Telecom Platform), поставляемых вместе с Erlang. Кластер обеспечивает зеркалирование хранимой в БД информации между всеми нодами кластера. Зеркалирование обеспечивается транзакционными механизмами Mnesia — внесение изменений в данные считается выполненным, если подтверждение о применении этих изменений приходит со всех нод кластера.
В системе должен быть один кластер Storage.

Storage хранит в себе следующую информацию о конфигурации и текущем состоянии системы:

В процессе работы системы кластер Storage взаимодействует со всеми остальными кластерами системы ECSS-10 для выдачи им конфигурационных и оперативных данных, а также сохранения изменений в этих данных.

Кластер Core

Кластер Core реализует логику управления обработкой телефонных вызовов (функции Call Control) и предоставления услуг. Алгоритм обслуживания вызовов реализован с использованием эталонных конечных автоматов O-BCSM и T-BCSM модели реализации интеллектуальных сетей связи (IN) с набором возможностей CS-3 согласно Рекомендации ITU-T Q.1238. Такой подход позволяет регулировать стандартный процесс обслуживания вызова и реализовывать различные услуги.
Реализация услуг выполнена в виде отдельных загружаемых модулей, что дает возможность расширять набор поддерживаемых сервисов и формировать различные пакеты дополнительных услуг для каждого оператора.
В правильно настроенной системе должен быть минимум один кластер Core (в высоконагруженных системах может быть несколько кластеров). Ноды кластера Core работают в режиме разделения нагрузки, обслуживая поступающие вызовы. Данные об обслуживаемых в каждый момент вызовах синхронизируются между нодами кластера, что позволяет незаметно для абонента перевести обслуживание вызова с одной ноды кластера на другую. Это может потребоваться в ситуациях отказа ноды в обслуживании, выходе из строя хоста или при выводе хоста или ноды из работы для проведения работ по их обслуживанию.

Сервис TTS реализует функционал сбора данных о вызовах и формирование файлов с записями о разговорах CDR (Call Detail Record). TTS поддерживает различные режимы сохранения CDR с возможностью адаптации информации в CDR и формата файла под определенного заказчика. Сервис TTS обеспечивает кластерное сохранение CDR, когда файлы с данными о вызовах записываются одновременно на всех нодах кластера.

В процессе работы системы кластер Core взаимодействует со всеми остальными кластерами системы ECSS-10 следующим образом:

Кластер Adapter

Кластер Adapter осуществляет адаптацию сетевого сигнального протокола, по которому подключаются внешние по отношению к гибкому коммутатору системы и оборудование, к внутреннему сигнальному протоколу системы (ACP).
В настоящее время реализованы следующие адаптеры протоколов:

Кластер Adapter состоит из одной или нескольких нод, работающих в режиме разделения нагрузки и синхронизирующих оперативные данные процесса обслуживания вызовов между собой. Такая структура позволяет обрабатывать ситуации принудительного или произвольного отказа в обслуживании ноды с автоматическим переводом обслуживания вызовов на другие ноды кластера.
Также Adapter отрабатывает ситуации отказа сети передачи данных (выход из строя сетевого адаптера, коммутатора, патч-корда и т.п.), приводящие к невозможности обмена пакетами.
В Adapter’е реализована виртуализация сетевого адреса, по которому осуществляется обмен сигнальными пакетами целевого сигнального протокола. Использование виртуализации позволяет резервировать IP-адрес системы ECSS-10, который используется при обмене с шлюзами и абонентским оборудованием. Для виртуализации сетевого адреса используется реализация протокола VRRP, выполненная в сервисе keepalived ОС Linux.
В правильно настроенной системе должно быть как минимум по одному кластеру Adapter’a для каждого протокола, используемого при подключении шлюзов и абонентов к системе.

В процессе работы системы кластер Adapter взаимодействует с другими кластерами системы ECSS-10 следующим образом:

Кластер Mediator

Кластер Mediator реализует:

Как и другие подсистемы ECSS-10 кластер Mediator обеспечивает резервирование своих данных (данные о статистике и обнаруженных авариях). Резервирование данных осуществляется посредством механизмов распределённых транзакций БД Mnesia, в которой они хранятся. Поэтому отказ в обслуживании ноды или хоста, на котором запущена нода, не приводит к их потере.
В правильно настроенной системе должен быть один кластер Mediator.

В процессе работы системы кластер Mediator взаимодействует с другими кластерами ECSS-10 следующим образом:

Процесс обслуживания вызовов. Внутренний протокол сигнализации

В процессе обслуживания вызова участвуют все компоненты системы. Основными компонентами являются Adapter и Core, которые непосредственно работают с сигнализацией и отслеживают фазы вызова.
Обмен сообщениями осуществляется через интеграционную шину, которую обеспечивает кластер BUS. Кластера Adapter и Core обмениваются сообщениями внутреннего протокола ACP (Adapter Core Protocol). Этот протокол является модификацией протокола DSS и основан на примитивах обмена, описанных в стандарте ITU-T Q.1238 для интеллектуальных сетей.

В протоколе ACP выделяют следующие типы сообщений:

Для этих сообщений применяются модификаторы, которые описывают фазу передачи сообщения.

Различают следующие модификаторы:

Полный набор сообщений, которые присутствуют в протоколе ACP с учетом модификаторов, имеет вид:

Основные параметры сигнальных сообщений:

SetupInd/Req

SetupResp/Conf

SubsequentAddressInd

AddressEndInd

CallProgressInd/Req

ReleaseInd/Req

Далее будут рассмотрены процессы обслуживания вызова на sequence-диаграммах, из которых будет виден процесс обмена сообщениями.

Рисунок 15 — Базовый вызов по протоколу SIP в режиме «enblock», упрощенный вид

Рисунок 16 — Разъединение вызова по инициативе абонента А, упрощенный вид

Рисунок 17 — Разъединение вызова по инициативе абонента Б, упрощенный вид

Рисунок 18 — Базовый вызов по протоколу H.248/Megaco в режиме «enblock», упрощенный вид

Рисунок 19 — Разъединение вызова по инициативе абонента А по протоколу H.248/Megaco, упрощенный вид

Рисунок 20 — Разъединение вызова по инициативе абонента Б по протоколу H.248/Megaco, упрощенный вид

Примеры неуспешных вызовов

Рисунок 21 — Неуспешный вызов по причине того, что номер Б не существует

Рисунок 22 — Неуспешный вызов по причине того, что номер Б не существует

Рисунок 23 — Неуспешный вызов по причине того, что интерфейс абонента Б не активен

Процесс обслуживания вызовов. Схема обмена данными

В данном разделе описан общий порядок обмена информацией в процессе обслуживания вызова.

Adapter A

Рисунок 24 — Диаграмма работы originating кластера Adapter (Adapter A)

Описание действий, выполняемых в функциональных блоках на диаграмме работы originating кластера Adapter (Adapter A):

Обработка 1 — входящий вызов по протоколу сигнализации поступает в ноду originating кластера Adapter (Adapter A), в которой:

Обработка 2 — от ядра получено сообщение о выдаче абоненту Б сигнала «Посылка вызова», выполняются следующие действия:

Обработка 3 — от ядра получено промежуточное сообщение о статусе процесса установления соединения, выполняются следующие действия:

Обработка 4 — от ядра получено сообщение об ответе абонента Б (SetupConf), выполняются следующие действия:

Рисунок 25 — Диаграмма работы кластера Core

Описание действий, выполняемых в функциональных блоках на диаграмме работы кластера Core:

Обработка 1

В кластер Core поступает сообщение «SetupInd», информирующее о начале обработки нового вызова. Выполняются следующие операции:

В результате маршрутизации был успешно найден интерфейс локального абонента Б:

В результате маршрутизации был успешно найден интерфейс/интерфейсы исходящего транка абонента Б:

В результате маршрутизации был определен неполный номер:

В результате маршрутизации была возвращена ошибка:
Обслуживание вызова продолжается по процедуре «Обработка 3».

Обработка 2

Получили одну или несколько цифр номера в случае посимвольного набора, выполняется следующая обработка:

Дальнейшие действия по обработке вызова аналогичны действиям из процедуры «Обработка 1» после получения результатов маршрутизации.

Обработка 3

Производятся действия по обработке ошибки, которая была выявлена в процессе обслуживания вызова:

В результате маршрутизации был определен неактивный интерфейс абонента Б:

Неактивный интерфейс абонента Б — это когда по номеру Б была найдена соответствующая ему локальная абонентская запись либо транковый интерфейс, но оперативные данные показывают, что интерфейс, соответствующий этому абоненту, не активен (абонент не был зарегистрирован либо регистрация истекла, для транка не прошла регистрация либо не отработал механизм OPTIONS-контроля).

В результате маршрутизации было определено, что у абонента А закрыт доступ к номеру абонента Б:

Запрет доступа абонента А к номеру абонента Б может быть введен на уровне групп доступа или режима обслуживания, и служит для ограничения видов доступа в зависимости от соглашении об уровне сервиса между абонентом и оператором (например использование междугородней связи запрещено или действует временное ограничение исходящей связи по причине неоплаты услуг связи).

В результате маршрутизации был определен несуществующий номер:

Несуществующий номер — это когда формат номера соответствует формату, заданному планом нумерации, номер относится к локальным абонентским номерам, но абонента с таким номером не создано.

В результате маршрутизации был определен неправильный номер:

Неправильный номер — это когда формат номера не соответствует форматам, заданным планом нумерации.

Обработка 4

Процедура выполняется при получении сообщения о разъединении «ReleaseInd» из кластера Adapter A до получения из кластера Adapter Б:

Обработка 5

Кластер Adapter Б подтвердил обработку вызова, получено сообщение «SetupReqInd», отложенных «ReleaseInd» в буфере процесса обработки вызова нет, идет нормальная обработка вызова:

Обработка 6

В состоянии ожидания ответного сообщения из кластера Adapter Б (STATE3) сработал таймер TResponse, что означает, что Adapter Б не прислал никаких сообщений за заданный интервал времени, ситуация аварийная для вызова:

Обработка 7

В состоянии ожидания ответного сообщения из кластера Adapter Б (STATE3) получено сообщение разъединения ReleaseInd от кластера Adapter A, что означает, что абонент А положил трубку:

Обработка 8

В состоянии ожидания ответного сообщения из кластера Adapter Б (STATE3) получено сообщение «CallProgressInd» с индикатором выдачи абоненту Б сигнала «Посылка вызова» (BPtyAlerting):

Обработка 9

В состоянии ожидания ответного сообщения из кластера Adapter Б (STATE3) получено сообщение «CallProgressInd» (промежуточное сообщение процесса установления соединения):

Обработка 10

В состоянии ожидания ответа абонента Б (STATE3 или STATE4) получено сообщение об ответе абонента Б (SetupResp):

Adapter Б

Рисунок 26 — Диаграмма работы terminating кластера Adapter (Adapter Б)

Описание действий, выполняемых в функциональных блоках диаграммы:

Обработка 1

В кластере Adapter Б получено сообщение о инициации вызова SetupReq.Выполняются следующие операции:

Обработка 2

В состоянии ожидания ответного сообщения от абонента/транка Б получено промежуточное сообщение «Progress»:

Обработка 3

В состоянии ожидания ответного сообщения от абонента/транка Б получено промежуточное сообщение «Progress» с индикатором «Alerting».

Обработка 4

В состоянии ожидания ответного сообщения от абонента/транка Б (STATE1) или в состоянии ожидания ответа абонента Б (STATE2) получено сообщение об ответе абонента Б (Answer).Выполняется:

Обработка 5

Получено сообщение о разъединении с кластера Adapter А:

Обработка 6

Получено сообщение о разъединении от абонента/транка Б:

Обработка 7

В состоянии ожидания ответа абонента Б получено промежуточное сообщение «Progress»:

Контейнеры параметров

В ECSS реализована иерархическая система контейнирования свойств различных сущностей.

На уровне системы определяются следующие виды сущностей:

Каждый вид сущностей обладает набором существенных характеристик:

Каждый экземпляр сущности обладает своим набором параметров.
Например, определенный алиас характеризуется определенным адресом, определенным именем домена и определенным именем интерфейса, а также содержит в себе набор параметров, специфичных именно для этого алиаса.

Набор параметров определенного экземпляра сущности является совокупностью параметров взятой из иерархии профилей этой сущности.

Существуют следующие иерархии профилей/контейнеров параметров:

Параметры интерфейсов являются внутрисистемными, и не должны задаваться пользователями ECSS-10 непосредственно через CoCon.

Параметры профиля с меньшей областью действия переопределяют параметры профиля с большей областью действия.
В приведенных выше иерархиях параметры уровня 1 переопределяют параметры уровня 2 и больших, и т.д.

На практике рекомендуется задавать значения параметров в наиболее общих профилях, т.е. на больших уровнях иерархии. Это позволяет хранить меньше данных, вносить групповые изменения в одном месте.

Схема информационных потоков

Система ECSS-10 поддерживает следующие способы обмена информацией (помимо VoIP):

Интеграционная шина

Для унификации обмена сообщениями между кластерами системы ECSS-10 применяется обмен через интеграционную шину, которую обеспечивает кластер Bus.
Обмен сообщениями осуществляется по протоколу AMQP версии 0-10. Со спецификациями протокола AMQP версии 0-10 можно ознакомиться по ссылке: http://www.amqp.org/sites/amqp.org/files/amqp0-10.zip.

Далее будут рассмотрены механизмы, которые используются в ECSS-10 при взаимодействии через Bus.

AMQP является протоколом, ориентированным на передачу сообщений через очередь с поддержкой механизмов транзакционности и гарантии доставки.
Брокером AMQP называется сервер, который выполняет функции приема, маршрутизации, хранения сообщения в очереди и доставки сообщения получателю.
В AMQP различают клиента отправителя (Publisher) и клиента получателя

я (Consumer) сообщения.
Точка обмена (Exchange) выполняет функции маршрутизации сообщения при получении его брокером от отправителя. Целью «exchange» является определение того, в какую очередь должно быть доставлено каждое сообщение на основании транспортных параметров сообщения.

Свойство транзакционности и гарантии доставки, поддерживаемое протоколом AMQP, позволяет гарантировать как доставку сообщения от отправителя до брокера с одной стороны, так и доставку от брокера до получателя с другой. При этом поддерживаются механизмы подтверждения доставки сообщения до всех нод кластера в случае схем с резервированием.

Типовой процесс доставки сообщения по протоколу AMQP можно отобразить следующим образом:

В процессе отправки сообщения отправитель устанавливает для сообщения различные параметры, которые влияют на процесс обработки и доставки сообщения.
Ключевыми параметрами, которые используются в ECSS-10, являются:

Точка обмена (Exchange)

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

В системе ECSS-10 используется Direct Exchange.

В Direct Exchange маршрутизация входящих сообщений осуществляется в очереди на основании значения параметра «routing key» сообщения. Этот тип точки обмена идеален для организации unicast-потоков обмена сообщениями (можно организовать и multicast обмен).Direct Exchange работает следующим образом:

Direct exhange часто используется в ситуациях, когда нужно распределять задачи между несколькими однотипными обработчиками в режиме распределения нагрузки (round robin).

Схематически работа Direct exhcnage:

Очередь (Queue)

Очереди в AMQP очень похожи на очереди в других системах доставки сообщений или обработки задач и представляют собой накопитель сообщений, работающий по принципу FIFO (First In First Out).Часть параметров очередь наследует от точки обмена, а также обладает следующими индивидуальными параметрами:

Для того чтобы очередь можно было использовать её необходимо задекларировать (declare). Декларация очереди ведет к её созданию, если очереди с таким именем и тем же набором атрибутов не существует. Декларация очереди не происходит, если уже существует очередь с именно таким именем и набором атрибутов (очередь уже существует, декларация считается успешно выполненной). Если же происходит декларация очереди и определяется, что очередь с таким именем, но отличающимся набором параметров, уже существует — возвращается ошибка «PRECONDITIONS_FAILED».

AMQP 0-10 определяет следующие общие правила именования очередей:

В системе ECSS-10 применяются следующие дополнительные правила именования очередей:

В настоящий момент используются следующие общие правила формирования имен очередей:

Правила связывания (Bindings)

Bindings — это правила связывания/маршрутизации, которые используются в точке обмена для маршрутизации сообщений в очереди.
Для того чтобы точка обмена E могла направлять сообщения в очередь Q необходимо, чтобы Q была связана с E.
Правило связывания может иметь дополнительный «routing key» атрибут, который используется в некоторых типах точек обмена.
Назначение «routing key» в том, чтобы выбрать определенные сообщения, размещенные в «exchange», и направить их в соответствующую очередь. Таким образом, «routing key» работает как фильтр.

Если сообщение не может быть смаршрутизировано в точке обмена (например, нет соответствующего правила связывания), то оно отбрасывается либо возвращается отправителю (зависит от настроек атрибутов сообщения).

Получатели (Consumers)

Получатель подписывается на сообщения определенной очереди. На сообщения очереди может быть подписано несколько получателей.
Также предусмотрен механизм эксклюзивной подписки на очередь, тогда получатель сообщений у очереди может быть только один.

Процесс доставки сообщения получателю

Получатели представляют собой приложения, которые обрабатывают получаемые сообщения, производят определенные манипуляции, могут отправить какой-то ответ. В процессе своей работы у получателя может произойти ошибка (в том числе в процессе обработки полученного сообщения), которая приведет к рестарту получателя. Также к подобным последствиям потенциально могут привести ошибки на сети.
Эти ситуации вызывают вопрос о том, когда брокеру можно удалить сообщение из очереди.

Спецификации протокола AMQP определяют 2 возможных алгоритма доставки сообщения:

Первый вариант доставки сообщения называется режимом «автоматического подтверждения». Второй вариант можно назвать режимом «явного подтверждения». Особенностью второго варианта является то, что получатель может подтвердить доставку сообщения как сразу после получения сообщения, так и через какое-то время, после выполнения заложенной в нем бизнес-логики (например, после завершения транзакции по записи изменений в базу данных).

Если процесс получателя падает (падает коннекция к брокеру) либо истекает таймер ожидания подтверждения, брокер производит повторную доставку сообщения другому получателю. Если других получателей нет, то брокер будет ожидать появления получателя для последующей доставки ему сообщения.

В процессе обработки сообщения получателем может сложиться ситуация когда получатель не может обработать сообщение (некорректная информация, какая-то ошибка в логике, недоступность подсистем и т.п.). Получатель может просигнализировать брокеру об ошибке обработки сообщения путем отправки ему сообщения «reject». В процессе отправки «reject» получатель может сигнализировать брокеру о том, что сообщение должно быть сброшено либо предоставлено другому получателю (зависит от прикладной логики и характера ошибки).

Механизм управления потоком сообщений к получателю

В AMQP введен очень полезный механизм ограничения количества сообщений, которые брокер отправляет одному получателю. Обычно такие механизмы называются «flow control» (механизм управления потоком сообщений).

Механизм управления потоком AMQP позволяет ограничивать поток информации, отправляемой брокером получателю по:

В системе ECSS-10 этот механизм используется практически во всех кластерах и служит способом ограничения входящей нагрузки на процессы обрабатывающие сообщения.

Внутрисистемный обмен

С точки зрения транспорта взаимодействие компонент системы можно схематично изобразить следующим образом:

Рисунок 27 — Взаимодействие компонентов системы

Рисунок 28 — Схема путей обмена сообщениями между кластерами через информационную шину

Для упрощения схемы взаимодействия далее в описании будет опущен кластер Bus. Но будет подразумеваться, что при обмене через AMQP все сообщения передаются через кластер Bus.

В процессе работы системы существуют следующие виды связей между кластерами:

Рисунок 29 — Обмен сообщениями в системе ECSS-10 в рамках обслуживания вызова

На рисунке 29 приведена схема обмена сообщениями в системе ECSS-10 в рамках обслуживания вызова, где

Рисунок 30 — Пути отправки сообщения об аварии системе ECSS-10

Информационные потоки сообщений распределенной консоли CoCon.
CoCon представляет собой распределенную облачную среду, к которой подключены все компоненты системы ECSS-10. Каждый подключенный компонент несет в себе функционал SSH-сервера, обеспечивающий возможность подключения клиентских терминалов по протоколу SSH. Каждый функциональный компонент содержит реализацию базовых команд CoCon (переходы по каталогам, команды управления нодой) и реализацию команд управления специфичных для этого компонента. При запуске компонента CoCon обеспечивает автоматическое связывание всех компонент в единую среду, за счет чего предоставляется возможность подключения к любому хосту системы ECSS-10 по протоколу SSH с возможностью выполнения любой команды вне зависимости от того где физически расположен компонент её реализующий. При выходе из строя какого-то компонента системы ECSS-10 он автоматически пропадает из CoCon (пропадает нода), а также пропадают команды, которые реализованы в этом компоненте. Когда компонент восстанавливает свою работу, он автоматически появляется в CoCon.

Рисунок 31 — Информационные потоки механизма мониторинга компонентов системы tring

Внутрисистемный обмен контроля состояния доступности интерфейсов

Система ECSS-10 при работе с подключаемыми к ней абонентами и шлюзами выглядит как единая система с одним IP-адресом для подключения, например, по протоколу SIP, несмотря на то, что в схеме с резервированием система разворачивается минимум на двух хостах.
Такое функционирование системы обеспечивается организацией виртуального «расшаренного» между хостами интерфейса, который в каждый момент времени присутствует только на одном хосте. Этот функционал предоставляется службой keepalived и используется в протокольных адаптерах, которые непосредственно взаимодействуют с абонентами и шлюзами по VoIP-протоколам.

Механизм организации виртуального IP-адреса в keepalived реализован за счет использования протокола VRRP, который поддерживается на коммутаторах.
При конфигурировании системы каждому хосту устанавливается индивидуальный приоритет. В процессе работы keepalived посылает на коммутатор широковещательные запросы протокола VRRP, анонсируя информацию о хосте и приоритете. Остальные хосты получают эту информацию, сравнивают со своей. Если их приоритет ниже указанного в пакете, то не выполняют какие-либо действия. Если за заданный интервал времени хост не получает сообщения о том, что в сети доступен хост с более высоким приоритетом, то хост запускает механизм активации виртуального интерфейса у себя (становится мастером).
Keepalived осуществляет отправку контрольных пакетов с заданной в конфигурации периодичностью, при этом перед отправкой проверяет корректность функционирования ПО ноды кластера адаптера. Если ПО функционирует не корректно — пакет не отправляется. Это позволяет отрабатывать ситуации, когда ПО ноды выходит из строя, и переводить виртуальный интерфейс на другую ноду кластера.

Рисунок 32 — Работа службы Keepalived

Транки и бриджи

Транки

Транк представляет собой интерфейс, соответствующий выходу из виртуальной АТС (домена). Соответствует транку на бридже (см. Менеджер бриджей (Bridge manager)). Представляет собой совокупность ресурсов для обслуживания телефонных вызовов в заданном направлении. Используется в маршрутизации, а так же и для ограничения входящих и исходящих линий.

Транки создаются либо с помощью команды declare, выполненной на соответствующем протокольном адаптере, например:

либо при создании бриджа:

Для транка могут быть настроены как на уровне системы, так и на уровне домена следующие ограничения:

Кроме ограничений по количеству линий можно настроить ограничения по CPS.

В примере показаны значения по умолчанию для транка:

Логика работы системных и доменных ограничений для транков такая, как и для бриджей.

Транки используются в маршрутизации вызовов (подробнее Виртуальная АТС. Маршрутизация телефонных вызовов).

Подробнее об управлении SIP-транками — см. раздел Управление SIP-транками.

Бриджи

Бридж (Bridge) — виртуальный транк, позволяющий соединять между собой две виртуальные АТС в рамках одной системы ECSS-10 (см. Менеджер бриджей (Bridge manager)).

При создании бриджа в каждом из двух доменов автоматически декларируется по одному транку, связанному с данным бриджем.

Как видно из данной таблицы, при вычислении актуального значения, будет использовано минимальное из двух значений — системного и доменного.

В версиях ECSS-10 до 3.10.0 значение unbounded не поддерживалось.

Бридж может работать в симплексном и дуплексном режимах. Симплексный бридж из домена А в домен Б пропускает вызовы только из домена А в домен Б. Дуплексный бридж пропускает вызовы в обоих направлениях. Подробнее о создании дуплексных и симплексных бриджей см. раздел /bridge/ — команды управления bridge-интерфейсами.

Описание системы СОРМ

Для выполнения требований по поддержке СОРМ в системе ECSS-10 устанавливается специализированный модуль Посредник СОРМ, который обеспечивает подключение ПУ СОРМ по стандартизированному интерфейсу к системе. Посредник СОРМ выполнен в конструктиве SMG1016M.

Программный модуль SORM кластера CORE системы ECSS-10 получает команды от Посредника СОРМ по шифрованному SSH-каналу и отправляет оперативную информацию о вызовах на Посредник СОРМ.

В процессе работы модуль SORM накапливает всю необходимую для взаимодействия с Посредником СОРМ информацию об активности наблюдаемых вызовов:

Все эти данные хранятся в надежном, резервированном хранилище кластера CORE и предоставляются в Посредник СОРМ, а далее в ПУ СОРМ.

Для обеспечения требований стандарта на СОРМ оперативная информация о вызовах предоставляется модулю SORM кластером Core в режиме реального времени.
Режим прослушивания телефонных разговоров обеспечивается принудительным проключением вызовов абонентов, за которыми идет наблюдение через Посредник СОРМ, который осуществляет передачу медиапотока вызова в канал к ПУ СОРМ.

Организация распределенной отказоустойчивой сети

Исходные данные

Исходные данные — требуется организовать распределенную отказоустойчивую сеть со следующими элементами:

Рисунок 33 — Типовая схема организации распределенной отказоустойчивой сети

Описание вынесенных узлов связи

Вынесенные узлы связи могут в себе содержать различный набор оборудования. Ниже приведено описание узлов связи их типовой схемы, расположенной сверху.

Узел А

В данном узле содержится две SMG-2016 в стеке, которые обеспечивают резервирование потоков Е1.
Данная SMG имеет выход в городскую сеть по потоку Е1. Также на SMG-2016 зарегистрированы Smart терминалы (Eltex VP-12/15, телефоны вендров Yealink, Cisco, GrandStream).
ТАУ-72 используется для подключения аналоговых абонентских терминалов через FXS порты. Сама ТАУ-72 регистрирует своих абонентов на SMG-2016.

Узел В

В данном узле вместо SMG-2016 содержится маршрутизатор с функциями VoIP — ESR-14VF.
Данный маршрутизатор имеет в себе встроенный VoIP-сервер, который способен обслуживать как Smart терминалы, так и аналоговые терминалы, подключенные к нему через встроенные FXS порты.
Выход в сеть IP осуществляется за счет отдельного линка, уходящего в сеть Интернет.
Для резервирования медиа трафика в данном узле стоит вынесенный медиа сервер MSR.

Узел C

В данном узле содержится SMG-200. На данной SMG включен режим транзитной регистрации.
К данной SMG подключены Smart терминалы (Eltex VP-12/15, телефоны вендров Yealink, Cisco, GrandStream).
Также к ней подключены аналоговые телефонные аппараты через встроенные FXS порты.

Таких узлов может быть гораздо больше, схема является масштабируемой. В самих узлах также имеется возможность использовать различное оборудование, набор которого не ограничен приведенным выше примером.

Описание работы резервирования

Резервирование Софтсвича ECSS-10

Резервирование программного коммутатора ECSS-10 может обеспечиваться за счет собранного кластера. Описание настройки Софтсвича ECSS-10 в качестве кластера содержится в разделе Конфигурирование кластеров.
Кроме того, система Софтсвича ECSS-10 позволяет обеспечить географическое резервирование в случае сильной территориальной разрозненности сети. Данный пункт описан в разделе Настройка георезерва.
Также требуется обеспечивать резервирование DNS серверов, который резолвят dns-имена для всех шлюзов в рамках данной сети.

Резервирование вынесенных узлов связи

Для того чтобы обеспечить резервирование в вынесенных узлах сети, требуется настроить на шлюзах SMG транзитную регистрацию.
Полная настройка транзитной регистрации на SMG описана в разделе Сервер выживания (транзитная регистрация).

Софтсвич ECSS-10 имеет в своей базе всех абонентов и индивидуальные настройки ДВО, которых обслуживает в рамках сети. В свою очередь, в вынесенных узлах обслуживается только часть абонентов из всех сети. Поэтому на SMG требуется сконфигурировать только тех абонентов, которые обслуживаются в рамках данного узла. Также, им требуется назначить тот набор ДВО, который позволит абонентам комфортно пользоваться услугами связи даже в аварийной ситуации на сети. Тем самым, обеспечится резервирование сигнализации.
Изначально, телефонные аппараты будут совершать регистрацию и звонки через вышестоящий шлюз SMG, который в свою очередь будет делать вызов на Софтсвич ECSS-10.
В случае падения линка до Софтсвича ECSS-10, вся локальная связь, а также связь с внешним миром, будет осуществляться через SMG. Это осуществляется за счет транзитной регистрации.
Также, имеется возможность обеспечить резервирование медиа трафика за счет вынесенных медиа серверов.

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

Пример настройки

Софтсвитч ECSS-10 обслуживает в рамках сети 3000 абонентов, чьи номера начинаются с 1000 по 4000. Каждый такой абонент может пользоваться услугами HOLD, 3way conference, DND, CFU
На сети имеется три вынесенных узла связи, каждый из которых обслуживает 1000 внутренних абонентов. Узел А обслуживает номера с 1000 по 1999, Узел В обслуживает номера с 2000 по 2999 и т.д.

Настройка Софтсвитч ECSS-10:

Создание абонентов. Описание создания абонентов описано в пункте Добавление абонента.

Включение и активация услуг на абонентах. Описание работы с услугами описано в пункте Инсталляция и управление услугами.

Создание транкового направления в сторону вынесенного Узла А. Описание создания транка описано в пункте Команды управления транками SIP.

Источник