Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Floating-IP-Muster für HA zwischen aktiven und statusbehafteten Standby-Servern

Das Floating-IP-Entwurfsmuster ist ein bekannter Mechanismus, um einen automatischen Failover zwischen einem aktiven und einem Standby-Paar von Hardwareknoten (Medienservern) zu erreichen. Dem aktiven Knoten wird eine statische sekundäre virtuelle IP-Adresse zugewiesen. Durch die kontinuierliche Überwachung zwischen dem aktiven Knoten und dem Standby-Knoten wird ein Fehler erkannt. Wenn der aktive Knoten ausfällt, weist das Überwachungsskript die virtuelle IP dem bereiten Standby-Knoten zu und der Standby-Knoten übernimmt die primäre aktive Funktion. Auf diese Weise schwebt die virtuelle IP zwischen dem aktiven und dem Standby-Knoten.

Anwendbarkeit in RTC-Lösungen

Es ist nicht immer möglich, mehrere aktive Instanzen derselben Komponente in Betrieb zu haben, z. B. ein aktiv-aktives Cluster mit N Knoten. Eine Aktiv-Standby-Konfiguration bietet den besten Mechanismus für HA. Beispielsweise eignen sich die statusbehafteten Komponenten in einer RTC-Lösung, wie der Medienserver oder Konferenzserver oder sogar ein SBC- oder Datenbankserver, gut für eine Active-Standby-Konfiguration. Auf einem SBC- oder Medienserver sind zu einem bestimmten Zeitpunkt mehrere lang laufende Sitzungen oder Kanäle aktiv. Falls die aktive SBC-Instance ausfällt, können sich die Endpunkte aufgrund der Floating-IP ohne clientseitige Konfiguration wieder mit dem Standby-Knoten verbinden.

Implementierung am AWS

Sie können dieses Muster in AWS mithilfe der Kernfunktionen von Amazon Elastic Compute Cloud (Amazon EC2), der Amazon EC2 API, Elastic IP-Adressen und der Unterstützung von Amazon EC2 für sekundäre private IP-Adressen implementieren.

Um das Floating-IP-Muster zu implementieren auf AWS:

Vorteile

Dieser Ansatz ist eine zuverlässige Low-Budget-Lösung, die vor Ausfällen auf EC2 Instanz-, Infrastruktur- oder Anwendungsebene schützt.

Einschränkungen und Erweiterbarkeit

Dieses Entwurfsmuster ist in der Regel auf eine einzelne Availability Zone beschränkt. Es kann in zwei Availability Zones implementiert werden, jedoch mit einer Variation. In diesem Fall wird die Floating Elastic IP-Adresse über die verfügbare Elastic IP Address API zwischen aktivem Knoten und Standby-Knoten in verschiedenen Availability Zones neu zugeordnet. Bei der in der vorherigen Abbildung gezeigten Failover-Implementierung werden laufende Anrufe gelöscht und die Endgeräte müssen erneut eine Verbindung herstellen. Es ist möglich, diese Implementierung um die Replikation der zugrunde liegenden Sitzungsdaten zu erweitern, um ein nahtloses Failover der Sitzungen oder auch die Medienkontinuität zu gewährleisten.

Lastenausgleich für Skalierbarkeit und HA mit WebRTC und SIP

Der Lastenausgleich eines Clusters aktiver Instances auf der Grundlage vordefinierter Regeln wie Round-Robin, Affinität oder Latenz usw. ist ein Entwurfsmuster, das aufgrund der statusfreien Natur von HTTP-Anfragen weit verbreitet ist. Tatsächlich ist der Lastenausgleich bei vielen RTC-Anwendungskomponenten eine praktikable Option.

Der Load Balancer fungiert als Reverse-Proxy oder als Einstiegspunkt für Anfragen an die gewünschte Anwendung, die selbst so konfiguriert ist, dass sie auf mehreren aktiven Knoten gleichzeitig ausgeführt wird. Zu einem beliebigen Zeitpunkt leitet der Load Balancer eine Benutzeranfrage an einen der aktiven Knoten im definierten Cluster weiter. Load Balancer führen eine Integritätsprüfung für die Knoten in ihrem Zielcluster durch und senden keine eingehende Anfrage an einen Knoten, der die Zustandsprüfung nicht besteht. Daher wird durch den Lastenausgleich ein grundlegender Grad an Hochverfügbarkeit erreicht. Da ein Load Balancer aktive und passive Integritätsprüfungen für alle Clusterknoten in Intervallen von weniger als einer Sekunde durchführt, erfolgt der Failover zudem fast augenblicklich.

Die Entscheidung, welcher Knoten geleitet werden soll, basiert auf den im Load Balancer definierten Systemregeln, darunter:

Anwendbarkeit in RTC-Architekturen

Das WebRTC-Protokoll ermöglicht den einfachen Lastenausgleich von WebRTC-Gateways über einen HTTP-basierten Load Balancer wie Elastic Load Balancing (ELB), Application Load Balancer (ALB) oder Network Load Balancer (NLB). Da die meisten SIP-Implementierungen auf den Transport sowohl über das Transmission Control Protocol (TCP) als auch über das User Datagram Protocol (UDP) angewiesen sind, benötigen Sie einen Lastenausgleich auf Netzwerk- oder Verbindungsebene mit Unterstützung für TCP- und UDP-basierten Datenverkehr.

Load Balancing AWS für WebRTC mit Application Load Balancer und Auto Scaling aktiviert

Im Fall von WebRTC-basierter Kommunikation bietet Elastic Load Balancing einen vollständig verwalteten, hochverfügbaren und skalierbaren Load Balancer, der als Einstiegspunkt für Anfragen dient, die dann an einen Zielcluster von EC2 Instances weitergeleitet werden, die mit Elastic Load Balancing verknüpft sind. Da WebRTC-Anfragen zustandslos sind, können Sie Amazon EC2 Auto Scaling verwenden, um vollautomatische und kontrollierbare Skalierbarkeit, Elastizität und Hochverfügbarkeit bereitzustellen.

Der Application Load Balancer bietet einen vollständig verwalteten Lastausgleichsdienst, der über mehrere Availability Zones hochverfügbar und skalierbar ist. Dies unterstützt den Lastenausgleich von WebSocket Anfragen, die die Signalisierung für WebRTC-Anwendungen verarbeiten, und die bidirektionale Kommunikation zwischen dem Client und dem Server über eine lang andauernde TCP-Verbindung. Der Application Load Balancer unterstützt auch inhaltsbasiertes Routing und Sticky-Sessions, bei denen Anfragen von demselben Client mithilfe von Load Balancer-generierten Cookies an dasselbe Ziel weitergeleitet werden. Wenn Sie Sticky Sessions aktivieren, empfängt dasselbe Ziel die Anfrage und kann das Cookie verwenden, um den Sitzungskontext wiederherzustellen.

Die folgende Abbildung zeigt die Zieltopologie.

Implementierung für SIP mit Network Load Balancer oder einem Produkt AWS Marketplace

Bei SIP-basierter Kommunikation werden die Verbindungen über TCP oder UDP hergestellt, wobei die meisten RTC-Anwendungen UDP verwenden. Wenn SIP/TCP das Signalprotokoll der Wahl ist, ist es möglich, den Network Load Balancer für einen vollständig verwalteten, hochverfügbaren, skalierbaren und leistungsfähigen Lastenausgleich zu verwenden.

Ein Network Load Balancer arbeitet auf der Verbindungsebene (Layer 4) und leitet Verbindungen zu Zielen wie EC2 Amazon-Instances, Containern und IP-Adressen auf der Grundlage von IP-Protokolldaten weiter. Der Netzwerklastenausgleich eignet sich ideal für den Lastenausgleich des TCP- oder UDP-Datenverkehrs und ist in der Lage, Millionen von Anfragen pro Sekunde zu verarbeiten und gleichzeitig extrem niedrige Latenzen aufrechtzuerhalten. Es ist in andere beliebte AWS-Services wie Amazon EC2 Auto Scaling, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) und integriert. AWS CloudFormation

Wenn SIP-Verbindungen initiiert werden, besteht eine weitere Option darin, AWS Marketplacekommerzielle off-the-shelf Software (COTS) zu verwenden. The AWS Marketplace bietet viele Produkte, die mit UDP und anderen Arten des Lastenausgleichs von Layer-4-Verbindungen umgehen können. COTS bieten in der Regel Unterstützung für Hochverfügbarkeit und lassen sich häufig in Funktionen wie Amazon EC2 Auto Scaling integrieren, um die Verfügbarkeit und Skalierbarkeit weiter zu verbessern. Die folgende Abbildung zeigt die Zieltopologie: