将多播传送到多个不同的地理位置
我需要在应用程序中使用一个基于 PGM 的逻辑多播地址，同时使此类应用程序能够“无缝”运行在多个不同的地理位置（即美国/欧洲/澳大利亚）。
应用程序具有相当大的吞吐量（每天数百万条商业消息）和延迟要求，并且发送大量小但非常频繁的消息。 由于延迟的一些外部限制，经典 Atom pub 在这里无法工作。
我提出了几种连接这些数据中心的选项，但找不到最好的一种。 我考虑过的选项是： 1）通过VPN转发组播消息（VPN可以处理这么大的负载）。 2）将所有多播消息转换为“包装消息”并通过AMQP转发它们。 3) 编写专门的内部门，通过 TCP 将多播消息隧道传输到其他两个位置。 4) 对于任何其他解决方案，
我更喜欢选项 1，因为它不需要开发人员编写额外的代码。 但恐怕连接不可靠。
是否有适用于此类连接的任何规则？
针对上述限制，针对地理配置的最佳网络配置是什么。
I need to use one logical PGM based multicast address in application while enable such application "seamlessly" running across several different geo-locations (i.e. think US/Europe/Australia).
Application is quite throughput (several million biz. messages a day) and latency demanding whith a lot of small but very frequently send messages. Classical Atom pub will not work here due some external limits of latencies.
I have come up with several options to connect those datacenters but can’t find the best one.
Options which I have considered are:
1) Forward multicast messages via VPN’s (can VPN handle such big load).
2) Translate all multicast messages to “wrapper messages” and forward them via AMQP.
3) Write specialized in-house gate which tunnels multicast messages via TCP to other two locations.
4) Any other solution
I would prefer option 1 as it does not need additional code writes from devs. but I’m afraid it will not be reliable connection.
Are there any rules to apply for such connectivity?
What the best network configuration with regard to the geographical configuration is for above constrains.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只是想打个招呼:)
至于这个话题，我们对 WAN 组播没有太多经验，但是，我的感觉是 PGM + WAN + 大数据量会导致重传风暴。 VPN 不会让这个问题消失，因为所有澳大利亚接收者在遇到丢失数据包时都会向欧洲发送 NACKS 等。PGM
规范确实允许采用树形结构的节点进行消息传递，因此理论上您可以在接收端放置一个节点，该节点将在本地重新多播数据。 然而，我不确定这种功能是否可以在 MS 的 PGM 实现中使用。 或者，您可以在接收端放置一个支持 PGM 的 Cisco 路由器来为您处理此问题。
无论如何，我的偏好是将数据转换为 TCP 流，通过 WAN 传递，然后在另一端将其转换回 PGM。 必须编写一些代码，但不会出现令人讨厌的意外情况。
马丁·S。
Just wanted to say hello :)
As for the topic, we have not much experience with multicasting over WAN, however, my feeling is that PGM + WAN + high volume of data would lead to retransmission storms. VPN won't make this problem disappear as all the Australian receivers would, when confronted with missing packets, send NACKS to Europe etc.
PGM specification does allow for tree structure of nodes for message delivery, so in theory you could place a single node on the receiving side that would in its turn re-multicast the data locally. However, I am not sure whether this kind of functionality is available with MS implementation of PGM. Optionally, you can place a Cisco router with PGM support on the receiving side that would handle this for you.
In any case, my preference would be to convert the data to TCP stream, pass it over the WAN and then convert it back to PGM on the other side. Some code has to be written, but no nasty surprises are to be expected.
Martin S.
在 CohesiveFT，当我们设计“VPN-Cubed”产品时，我们遇到了一个非常相似的问题，该产品用于在一个 VPN 中将多个云连接到我们自己的防火墙后面的服务器。 我们希望能够运行使用多播相互通信的应用程序，但例如 Amazon EC2 不支持多播，如果考虑到整个数据中心可能出现网络风暴，原因应该是相当明显的。 我们还希望使用互联网在广域节点联盟中路由流量。
无需赘述，该解决方案涉及将隧道与 BGP 等标准路由协议以及 VPN 开放技术相结合。 我们使用 RabbitMQ AMQP 以 pubsub 风格传递消息，而不需要物理多播。 这意味着您可以在广域子网上伪造多播，甚至可以跨域和防火墙，前提是您位于 VPN-Cubed 安全港中。 它之所以有效，是因为它是一个“网络覆盖”，如技术说明中所述： http://blog.elasticserver.com/2008/12/vpn-cubed-technical-overview.html
我并不打算实际为您提供具体的解决方案，但我确实希望这个答案给出您有信心尝试其中一些方法。
干杯，亚历克西斯
at CohesiveFT we ran into a very similar problem when we designed our "VPN-Cubed" product for connecting multiple clouds up to servers behind our own firewall, in one VPN. We wanted to be able to run apps that talked to each other using multicast, but for example Amazon EC2 does not support multicast for reasons that should be fairly obvious if you consider the potential for network storms across a whole data center. We also wanted to route traffic across a wide area federation of nodes using the internet.
Without going into too much detail, the solution involved combining tunneling with standard routing protocols like BGP, and open technologies for VPNs. We used RabbitMQ AMQP to deliver messages in a pubsub style without needing physical multicast. This means you can fake multicast over wide area subnets, even across domains and firewalls, provided you are in the VPN-Cubed safe harbour. It works because it is a 'network overlay' as described in technical note here: http://blog.elasticserver.com/2008/12/vpn-cubed-technical-overview.html
I don't intend to actually offer you a specific solution, but I do hope this answer gives you confidence to try some of these approaches.
Cheers, alexis