[vurd]

Думаю над сабжем.

 

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

Если в простой маршрутизации это очевидные пути, навроде использования ospf и прочих bgp, то с мальтикастом совершенно не понятно как поступать.

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

Мне приходит на ум только смена группы назначения на стримерах путем вызова внешних управляющих программ, но это как-то не "энтерпрайз".

[srg555]

Смотря какой критерий резервирования(переключения) и откуда к вам приходит мультик. Один из вармантов - 2 RP и в них дуть разные сорсы

[vurd]

Источник собственная ГС. Про два rp не догоняю. Каким образом это поможет, источники должны быть в синхроне?

[srg555]

Вы источник хотите резервировать или спд или всё? Что у вас сейчас и что хотите добавить? Pim есть?

[vurd]

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

p.s. выражаюсь я конечно ппц сумбурно :)

[srg555]

Какой критерий переключения? нулевой трафик от источника на протяжении N секунд? Или падениие линка к источнику или что?

[vurd]

Как вариант команда внешнего анализатора, который посчитал картинку не достаточно качественной или не увидел ее вовсе.

А вообще критериев может быть много, приведенные вами же ситуацию вполне тянут на "авария".

[srg555]

Команда от внешнего анализатора это будет скрипт, который, например, поменяет приоритет группы на рп.

 

Вопрос в том как переключать обратно, но это зависит от того как анализатор забирает трафик. В принципе, есть пим ссм + игмп3, с джойном по сорсу

 

ИРЛ, я бы не советовал всё это делать, высока вероятность ложного срабатывания, флаппинга и т.п. Как лаба - задача интересная

 

Проще держать холодный резерв и раз в год вручную его мспользовать

 

Ещё один простой вариант - NAT и, соответственно изменение правла по "команде"

[Merridius]

Врятли получиться без PIM.

[srg555]

Врятли получиться без PIM.

PIm это лишь инструмент, который решает тривиальные задачи. ТС желает создать высокоинтеллектуальную систему переключения между источниками залезая на л7, т.е. декодируя поток(в самом деле надо оба), как-то определяя который лучше

 

Когда речь идёт об обычных очпф, бгп и т.п., то критерии тривиальные - физ. линк, состояние тунеля/сессии и т.п. поэтому всё просто

[Ivan_83]

Свалить на хттп, там это проще делается.

[zhenya`]

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

[Minya]

есть ещё одна говносхема.

Делаем на обоих соурсах одинаковый адрес мультикаст (224.0.2.2), но на интерфейсы с которых они будут вещаться вешаем разные IP (1 и 2).

Ну и на SVI в коммутаторе куда подключен стример вешаем ацесс-лист где разрешаем трафик с источника 1 до назначения 224.0.2.2, а следующей записью запрещаем трафик с источника 2 до назначения 224.0.2.2.

Таким образом ваш стример принимает всегда группу 224.0.2.2 и отдает в сеть ту которую надо (224.0.1.1)

Анализатор при проблеме шлет трап внешнему скрипту, а тот меняет ацл на коммутаторе, а заодно заставляет стример обновить подписку.

[darkagent]

https://supportforums.cisco.com/docs/DOC-8375

[garycat]

Есть еще вариант с использованием проекта astra

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

[srg555]

И сразу возникает вопрос о резервировании сервера astra

[triam]

Вообще правильно резервировать мультикаст, используя схему Any Source Multicast или Source Specific Multicast=) (

То есть для резервирования источника нужно вещать одну и ту же группу из "разных мест".

Если вы хотите просто быть уверенным, что трафик от источника до клиента дойдёт при наличии резервных маршрутов, то нужно делать pim и резервировать RP для ASM и только pim и возможно mapping для SSM.

 

Ну и кординально противоположный вариант - это "загнать всё в HTTP". ( IVAN_83 )

[fox_m]

Anycast RP

http://www.telemultimedia.ru/art.php?id=412

Изменено 26 июня, 2013 пользователем fox_m

[vurd]

Команда от внешнего анализатора это будет скрипт, который, например, поменяет приоритет группы на рп.

 

Вопрос в том как переключать обратно, но это зависит от того как анализатор забирает трафик. В принципе, есть пим ссм + игмп3, с джойном по сорсу

 

ИРЛ, я бы не советовал всё это делать, высока вероятность ложного срабатывания, флаппинга и т.п. Как лаба - задача интересная

 

Проще держать холодный резерв и раз в год вручную его мспользовать

 

Ещё один простой вариант - NAT и, соответственно изменение правла по "команде"

 

У меня есть подобная система, перевещатель, проверет n-потоков и ретранслирует в какую-то определенную группу. Как раз для изначальной цели и написана была. Ну и разумеется этот вариант имеет ложные срабатвания, флаппинги и т.п. (-:

Я ее разобрал к хренам и вот начал искать как делают по нормальному.

 

NAT мальтикаст группы одну в другую?

 

-----

 

Вариант с астрой рассматривался, есть минус - генерация N*3 больше трафика чем это нужно на самом деле.

 

Вариант от triam кажется наиболее интересным. Суть в том, что для ближайщей группы будет выстроен маршрут короче и он победит? (Здесь правда критерием остается полный отвал вещания канала, что происходит довольно редко, обычно какие-то неведомые проблемы с сигналом или декодировкой)

 

Вариант с говносхемой - имеет место быть, но жить с этим... :)))

[triam]

По умолчанию, обычно все делают PIM Sparce mode, Static RP с резервированием через MSDP или PIM (Называется Anycast RP)

Прочитать теорию и как настроить можно в хорошей книжке

[Minya]

Резервирование источника с Anycast RP понятно.

У меня в ходе темы возник вопрос.

Есть два одинаковых источника выдающих одинаковые группы. Я хочу чтобы группы 1,2 и 4 забирались с первого, а группа 3 со второго. С возможностью по желанию менять источники групп, т.е. с первого брать только 4, а остальные перекинуть на прием со второго.

Пока вариантов кроме тех-же ацесс-листов нет.

Книжку уже заказал...

[^rage^]

вы от какой проблемы пытаетесь убежать? если один из источников деградирует по качеству - что делать будете?

[Minya]

ОП, есть новости по теме? Удалось зарезервировать источники?

[heap]

Есть у кого-нибудь живой опыт резервирования при наличии >1 источника? На той же astra, возможно.

[darkagent]

Есть у кого-нибудь живой опыт резервирования при наличии >1 источника?

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

 

- есть внутренний мультикастовый диапазон (то что рисуется на mvr на коммутаторах доступа, и пихается в плейлист),

- есть внешние мультикастовые диапазоны (приходят от разных источников).

- есть линуховый сервак, который переливает одно в другое.

внешний мультик проходит через сервак с линухом, где происходит переливание мультика из одной группы в другую (посредством multicat) и за счет встроенных средств (того же multicat) проверяется поток на предмет жив/мертв скриптом по крону. в случае если поток мертв (нет mpeg\ts заголовков и т.п.) происходит подмена одного источника на другой, а первый источник вливается в "пустую" группу, для сбора статистики на предмет когда появится поток и продолжает ли он сыпаться - на основе этой статистики в дальнейшем принимается решение на подмену второго источника на первый (пока в ручном режиме, ибо сыро).

время простоя зависит от интервала проверки и шустроты сервака (хотя как показала практика - multicat крайне скромен, и спокойно взлетает даже на слабеньких платформах). схема маппинга primary-source/alternate-souce -> destination держится в базе, в которую скриптик лезит при необходимости.