Доставка многоадресной рассылки для нескольких различных гео-местах

голоса
2

Мне нужно использовать адрес многоадресной рассылки на основе одного логического PGM в приложении, а включить такое приложение «бесшовно» работает в нескольких различных гео-мест (т.е. думают США / Европа / Австралия).

Применение достаточно пропускная способность (несколько миллионов биза. Сообщения в день) и латентность требовательной ти много небольших, но очень часто отправлять сообщения. Классическая Atom паб не будет работать здесь из-за какими-то внешние пределами задержек.

Я придумал несколько вариантов, чтобы соединить эти датацентров, но не могу найти лучшую. Варианты, которые я Рассматриваемые: 1) Вперед широковещательные сообщения через VPN (в VPN может справиться с такой большой нагрузкой). 2) Перевести все широковещательные сообщения «оберток сообщений» и направить их через AMQP. 3) Написать специализированные ворота в доме, который туннели широковещательных сообщений через TCP в двух других местах. 4) Любое другое решение

Я бы предпочел вариант 1, поскольку он не нужен дополнительный код, пишет из дэвов. но я боюсь, что это не будет надежное соединение.

Существуют ли какие-либо правила, применяемые для такого подключения?

Что лучшая конфигурация сети в связи с географической конфигурацией для выше ограничений.

Задан 10/12/2008 в 01:12
источник пользователем
На других языках...                            


2 ответов

голоса
0

в CohesiveFT мы столкнулись с очень похожей проблемой, когда мы конструировали наш «VPN-Cubed» продукт для подключения нескольких облаков до серверов за наш собственный брандмауэр, в одном VPN. Мы хотели, чтобы иметь возможность запускать приложения, которые говорили друг с другом с помощью многоадресной рассылки, но, например, Amazon EC2 не поддерживает многоадресную рассылку по причинам, которые должны быть достаточно очевидны, если учесть потенциал для сетевых штормов через целый центр обработки данных. Мы также хотели бы маршрутизировать трафик через глобальную федерацию узлов, использующих Интернет.

Не вдаваясь в излишние подробности, решение участвовать комбинируя туннелирование со стандартными протоколами маршрутизации , как BGP и открытыми технологиями для виртуальных частных сетей. Мы использовали RabbitMQ AMQP для доставки сообщений в стиле PubSub без необходимости физического многоадресного. Это означает , что вы можете поддельные многоадресный в широких подсетях области, даже в разных доменах и брандмауэров, если вы находитесь в безопасной гавани VPN-Cubed. Это работает , потому что это "сеть Перекрытие , как описано в технической записке здесь: http://blog.elasticserver.com/2008/12/vpn-cubed-technical-overview.html

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

Cheers, Alexis

Ответил 10/01/2009 в 11:31
источник пользователем

голоса
0

Просто хотел сказать привет :)

Что же касается темы, мы не имеем большой опыт работы с многоадресной передачи по глобальной сети, однако, мне кажется, что PGM + WAN + большой объем данных приведет к повторной передаче штормам. VPN не сделать эту проблему исчезнуть , как все австралийские приемники бы, сталкиваясь с отсутствующими пакетами, отправить NACKS в Европу и т.д.

спецификация PGM действительно позволяет древовидную структуру узлов для доставки сообщений, так что в теории можно поместить один узел на принимающей стороне, что бы в свою очередь повторной многоадресной передачи данных локально. Тем не менее, я не уверен, доступен ли с реализацией MS МПГ этого вида функциональности. По желанию, вы можете разместить маршрутизатор Cisco с поддержкой PGM на принимающей стороне, что бы справиться с этим для вас.

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

Martin S.

Ответил 29/12/2008 в 22:12
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more