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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Ура, Алексис

Answer 2

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

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

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

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

Мартин С.