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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Мартин С.

Answer 2

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

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

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

Твое здоровье, Алексис