Diffusez la multidiffusion vers plusieurs géolocalisations différentes

Question

Je dois utiliser une adresse de multidiffusion logique basée sur PGM dans l'application tout en permettant à une telle application de fonctionner "de manière transparente" sur plusieurs géolocalisations différentes (c'est-à-direpensez aux États-Unis/Europe/Australie).

L'application est assez performante (plusieurs millions de business.messages par jour) et une latence exigeante avec beaucoup de petits messages envoyés très fréquemment.La pub Atom classique ne fonctionnera pas ici en raison de certaines limites externes de latence.

J'ai proposé plusieurs options pour connecter ces centres de données, mais je ne trouve pas la meilleure.Les options que j'ai envisagées sont :1) Transférer les messages de multidiffusion via VPN (le VPN peut-il gérer une charge aussi importante).2) Traduisez tous les messages multicast en « messages wrapper » et transférez-les via AMQP.3) Écrivez une porte interne spécialisée qui tunnelise les messages de multidiffusion via TCP vers deux autres emplacements.4) Toute autre solution

Je préférerais l'option 1 car elle ne nécessite pas d'écriture de code supplémentaire de la part des développeurs.mais j'ai peur que ce ne soit pas une connexion fiable.

Existe-t-il des règles à appliquer pour une telle connectivité ?

Quelle est la meilleure configuration réseau en ce qui concerne la configuration géographique pour les contraintes ci-dessus.

Answer 1

Je voulais juste dire bonjour:)

En ce qui concerne le sujet, nous avons l'expérience avec pas beaucoup plus étendu multicasting, cependant, mon sentiment est que PGM + WAN + volume élevé de données conduirait à des tempêtes de retransmission. VPN ne fera pas disparaître ce problème comme tous les récepteurs australiens, lorsqu'ils sont confrontés à des paquets manquants, envoyer NACKS en Europe etc.

spécification PGM ne permet pour la structure arborescente des noeuds pour la distribution des messages, donc en théorie vous pouvez placer un seul nœud sur le côté de réception qui serait à son tour re-multidiffusion les données localement. Cependant, je ne suis pas sûr que ce type de fonctionnalité est disponible avec la mise en œuvre de MS PGM. En option, vous pouvez placer un routeur Cisco avec prise en charge PGM sur le côté de la réception qui traiterait pour vous.

Dans tous les cas, ma préférence serait de convertir les données en flux TCP, passer sur le réseau étendu, puis reconvertir en PGM de l'autre côté. Une partie du code doit être écrit, mais pas de mauvaises surprises sont à prévoir.

Martin S.

Answer 2

Chez CohesiveFT, nous avons rencontré un problème très similaire lorsque nous avons conçu notre produit "VPN-Cubed" pour connecter plusieurs cloud à des serveurs derrière notre propre pare-feu, dans un seul VPN.Nous voulions pouvoir exécuter des applications qui communiquaient entre elles via la multidiffusion, mais par exemple, Amazon EC2 ne prend pas en charge la multidiffusion pour des raisons qui devraient être assez évidentes si l'on considère le potentiel de tempêtes de réseau dans l'ensemble d'un centre de données.Nous souhaitions également acheminer le trafic à travers une vaste fédération de nœuds utilisant Internet.

Sans entrer dans les détails, la solution impliquait de combiner le tunneling avec des protocoles de routage standards comme BGP et des technologies ouvertes pour les VPN.Nous avons utilisé RabbitMQ AMQP pour transmettre des messages dans un style pubsub sans avoir besoin de multidiffusion physique.Cela signifie que vous pouvez simuler la multidiffusion sur des sous-réseaux étendus, même à travers des domaines et des pare-feu, à condition que vous soyez dans la sphère de sécurité VPN-Cubed.Cela fonctionne car il s'agit d'une « superposition de réseau » comme décrit dans la note technique ici : http://blog.elasticserver.com/2008/12/vpn-cubed-technical-overview.html

Je n'ai pas l'intention de vous proposer une solution spécifique, mais j'espère que cette réponse vous donnera la confiance nécessaire pour essayer certaines de ces approches.

Bravo, Alexis