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

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

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

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

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

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

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


multicast geolocation amqp messaging pgm-protocol
person Libor    schedule 10.12.2008    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Просто хотел поздороваться :)

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

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

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

Мартин С.

person Community    schedule 29.12.2008

arrow_upward
0
arrow_downward

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

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

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

Привет, Алексис

person Community    schedule 10.01.2009