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.
# Hohe Verfügbarkeit und Skalierbarkeit auf AWS
Die meisten Anbieter von Echtzeitkommunikation orientieren sich an Service Levels, die eine Verfügbarkeit von 99,9% bis 99,999% bieten. Je nachdem, welchen Grad an Hochverfügbarkeit (HA) Sie wünschen, müssen Sie während des gesamten Lebenszyklus der Anwendung immer ausgefeiltere Maßnahmen ergreifen. AWS empfiehlt, die folgenden Richtlinien zu befolgen, um ein stabiles Maß an Hochverfügbarkeit zu erreichen:
+ Entwerfen Sie das System so, dass es keine einzige Fehlerquelle gibt. Verwenden Sie automatische Überwachungs-, Fehlererkennungs- und Failover-Mechanismen sowohl für statusfreie als auch für zustandsbehaftete Komponenten
+ *Single Points of Failure (SPOF) werden in der Regel durch eine N\$11- oder 2N-Redundanzkonfiguration vermieden, wobei N\$11 durch Lastenausgleich zwischen *aktiv-aktiven Knoten und 2N durch ein Knotenpaar* in einer Active-Standby-Konfiguration erreicht wird.*
+ AWS bietet mehrere Methoden, um HA mit beiden Ansätzen zu erreichen, z. B. durch einen skalierbaren Cluster mit Lastenausgleich oder die Annahme eines *Aktiv-Standby-Paars*.
+ Richtiges Instrumentieren und Testen der Systemverfügbarkeit.
+ Bereiten Sie Betriebsverfahren für manuelle Mechanismen vor, um auf den Ausfall zu reagieren, ihn zu mindern und ihn zu beheben.
Dieser Abschnitt konzentriert sich darauf, wie mithilfe der verfügbaren Funktionen erreicht werden kann, dass kein einziger Ausfallpunkt erreicht wird. AWS In diesem Abschnitt wird insbesondere ein Teil der AWS Kernfunktionen und Entwurfsmuster beschrieben, mit denen Sie hochverfügbare Echtzeitkommunikationsanwendungen erstellen können.
# 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:
1. Starten Sie zwei EC2 Instances, um die Rollen des primären und des sekundären Knotens zu übernehmen, wobei davon ausgegangen wird, dass sich der primäre Knoten standardmäßig im *aktiven* Zustand befindet.
1. Weisen Sie der primären EC2 Instanz eine zusätzliche sekundäre private IP-Adresse zu.
1. Eine elastische IP-Adresse, die einer virtuellen IP (VIP) ähnelt, ist der sekundären privaten Adresse zugeordnet. Diese sekundäre private Adresse ist die Adresse, die von externen Endpunkten für den Zugriff auf die Anwendung verwendet wird.
1. Eine Konfiguration des Betriebssystems (OS) ist erforderlich, damit die sekundäre IP-Adresse als Alias zur primären Netzwerkschnittstelle hinzugefügt wird.
1. Die Anwendung muss an diese elastische IP-Adresse gebunden werden. Bei der Asterisk-Software können Sie die Bindung über erweiterte Asterisk-SIP-Einstellungen konfigurieren.
1. Führen Sie auf jedem Knoten ein Überwachungsskript (benutzerdefiniert, KeepAlive unter Linux, Corosync usw.) aus, um den Status des Peer-Knotens zu überwachen. Falls der aktuell aktive Knoten ausfällt, erkennt der Peer diesen Fehler und ruft die EC2 Amazon-API auf, um sich selbst die sekundäre private IP-Adresse neu zuzuweisen.
Daher wird die Anwendung, die den mit der sekundären privaten IP-Adresse verknüpften VIP abgehört hat, für Endgeräte über den Standby-Knoten verfügbar.
![\[Ein Diagramm, das den Failover zwischen statusbehafteten EC2 Instances unter Verwendung einer elastischen IP-Adresse darstellt.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/real-time-communication-on-aws/images/failover-stateful.jpg)
#### 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:
+ Rundenturnier
+ Sitzungs- oder IP-Affinität, wodurch sichergestellt wird, dass mehrere Anfragen innerhalb einer Sitzung oder von derselben IP an denselben Knoten im Cluster gesendet werden
+ Basierend auf Latenz
+ Lastbasiert
## 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](https://aws.amazon.com/elasticloadbalancing/) (ELB), [Application Load Balancer (ALB) oder Network Load Balancer (NLB](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/)).](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/) 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](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html), 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.
![\[Ein Diagramm, das die Skalierbarkeit und Hochverfügbarkeitsarchitektur von WebRTC darstellt.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/real-time-communication-on-aws/images/webrtc-scalability.png)
## 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](https://aws.amazon.com/ecs/) ECS), [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) (Amazon EKS) und integriert. [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
Wenn SIP-Verbindungen initiiert werden, besteht eine weitere Option darin, [AWS Marketplace](https://aws.amazon.com/marketplace)kommerzielle 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:
![\[Ein Diagramm, das die SIP-basierte RTC-Skalierbarkeit mit dem Produkt AWS Marketplace darstellt.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/real-time-communication-on-aws/images/sip-based-rtc-scalability.jpg)
# Regionsübergreifender DNS-basierter Lastenausgleich und Failover
[Amazon Route 53](https://aws.amazon.com/route53/) bietet einen globalen DNS-Service, der als öffentlicher oder privater Endpunkt für RTC-Clients zur Registrierung und Verbindung mit Medienanwendungen verwendet werden kann. Mit Amazon Route 53 können DNS-Zustandsprüfungen so konfiguriert werden, dass sie den Datenverkehr an fehlerfreie Endpunkte weiterleiten oder den Zustand Ihrer Anwendung unabhängig überwachen.
Die Amazon Route 53 Traffic Flow-Funktion erleichtert Ihnen die globale Verwaltung des Datenverkehrs mithilfe einer Vielzahl von Routingtypen, darunter latenzbasiertes Routing, Geo-DNS, Geoproximity und Weighted Round Robin. All diese Optionen können mit DNS-Failover kombiniert werden, um eine Vielzahl von fehlertoleranten Architekturen mit niedriger Latenz zu ermöglichen. Mit dem einfachen visuellen Editor von Amazon Route 53 Traffic Flow können Sie verwalten, wie Ihre Endbenutzer zu den Endpunkten Ihrer Anwendung weitergeleitet werden — ob in einer einzelnen AWS-Region oder auf der ganzen Welt verteilt.
Bei globalen Bereitstellungen ist die latenzbasierte Routing-Richtlinie in Route 53 besonders nützlich, um Kunden zum nächstgelegenen Point of Presence für einen Medienserver zu leiten und so die Servicequalität im Zusammenhang mit dem Medienaustausch in Echtzeit zu verbessern.
Beachten Sie, dass die Client-Caches geleert werden müssen, um einen Failover auf eine neue DNS-Adresse zu erzwingen. Außerdem kann es bei DNS-Änderungen zu Verzögerungen kommen, wenn sie über globale DNS-Server verteilt werden. Sie können das Aktualisierungsintervall für DNS-Lookups mit dem Time to Live-Attribut verwalten. Dieses Attribut kann zum Zeitpunkt der Einrichtung von DNS-Richtlinien konfiguriert werden.
AWS Global Accelerator Kann auch für regionsübergreifendes Failover verwendet werden, um globale Benutzer schnell zu erreichen oder um die Anforderungen der Verwendung einer einzigen öffentlichen IP zu erfüllen. [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/?blogs-global-accelerator.sort-by=item.additionalFields.createdDate&blogs-global-accelerator.sort-order=desc&aws-global-accelerator-wn.sort-by=item.additionalFields.postDateTime&aws-global-accelerator-wn.sort-order=desc)ist ein Netzwerkdienst, der die Verfügbarkeit und Leistung von Anwendungen mit lokaler und globaler Reichweite verbessert. AWS Global Accelerator stellt statische IP-Adressen bereit, die als fester Einstiegspunkt zu Ihren Anwendungsendpunkten dienen, wie z. B. Ihren Application Load Balancers, Network Load Balancers oder EC2 Amazon-Instances in einer oder mehreren AWS-Regionen. Es nutzt das globale AWS-Netzwerk, um den Pfad von Ihren Benutzern zu Ihren Anwendungen zu optimieren und so die Leistung zu verbessern, z. B. die Latenz Ihres TCP- und UDP-Datenverkehrs.
AWS Global Accelerator überwacht kontinuierlich den Zustand Ihrer Anwendungsendpunkte und leitet den Datenverkehr automatisch an die nächstgelegenen fehlerfreien Endpunkte weiter, falls die aktuellen Endgeräte nicht mehr richtig funktionieren. Für zusätzliche Sicherheitsanforderungen verwendet Accelerated Site-to-Site VPN, AWS Global Accelerator um die Leistung von VPN-Verbindungen zu verbessern, indem der Datenverkehr intelligent über das globale AWS-Netzwerk und die AWS-Edge-Standorte geleitet wird.
![\[Ein Diagramm, das das regionsübergreifende Hochverfügbarkeitsdesign mit AWS Global Accelerator oder Amazon Route 53 darstellt.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/real-time-communication-on-aws/images/inter-region-ha-design.png)
# Datenbeständigkeit und HA mit persistentem Speicher
Die meisten RTC-Anwendungen verlassen sich auf persistenten Speicher, um Daten für Authentifizierung, Autorisierung, Abrechnung (Sitzungsdaten, Anrufdetails usw.), Betriebsüberwachung und Protokollierung zu speichern und darauf zuzugreifen. In einem herkömmlichen Rechenzentrum erfordert die Sicherstellung einer hohen Verfügbarkeit und Beständigkeit der persistenten Speicherkomponenten (Datenbanken, Dateisysteme usw.) in der Regel viel Arbeit. Dazu gehören die Einrichtung eines Storage Area Network (SAN), das RAID-Design (Redundant Array of Independent Disks) und Prozesse für Backup, Wiederherstellung und Failover-Verarbeitung. Dies AWS Cloud vereinfacht und verbessert die traditionellen Abläufe in Rechenzentren in Bezug auf Datenbeständigkeit und Verfügbarkeit erheblich.
Für Objekt- und Dateispeicherung bieten AWS Dienste wie [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) und [Amazon Elastic File System](https://aws.amazon.com/efs/) (Amazon EFS) verwaltete Hochverfügbarkeit und Skalierbarkeit. Amazon S3 hat eine Datenbeständigkeit von 99,999999999% (11 Neun).
Für die Speicherung von Transaktionsdaten haben Kunden die Möglichkeit, den vollständig verwalteten Amazon Relational Database Service (Amazon RDS) zu nutzen, der Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle und Microsoft SQL Server mit Hochverfügbarkeitsbereitstellungen unterstützt. Für die Registrar-Funktion, das Abonnentenprofil oder die Speicherung von Buchhaltungsunterlagen (z. B. CDRs) bietet Amazon RDS eine fehlertolerante, hochverfügbare und skalierbare Option.
# Dynamische Skalierung mit AWS Lambda Amazon Route 53 und Amazon EC2 Auto Scaling
AWS ermöglicht die Verkettung von Funktionen und die Möglichkeit, benutzerdefinierte serverlose Funktionen als Service auf der Grundlage von Infrastrukturereignissen zu integrieren. Ein solches Entwurfsmuster, das in RTC-Anwendungen vielseitig einsetzbar ist, ist die Kombination von automatischen Skalierungslebenszyklus-Hooks mit [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html), Amazon Route 53 und [AWS Lambda](https://aws.amazon.com/lambda/)Funktionen. AWS Lambda Funktionen können jede Aktion oder Logik einbetten. Die folgende Abbildung zeigt, wie diese miteinander verketteten Funktionen die Zuverlässigkeit und Skalierbarkeit des Systems durch Automatisierung verbessern können.
![\[Ein Diagramm, das die automatische Skalierung mit dynamischen Updates für Amazon Route 53 darstellt.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/real-time-communication-on-aws/images/auto-scaling-dynamic-updates.jpg)
# Hochverfügbares WebRTC mit Amazon Kinesis Video Streams
[Amazon Kinesis Video Streams](https://aws.amazon.com/kinesis/video-streams/?nc=sn&loc=0&amazon-kinesis-video-streams-resources-blog.sort-by=item.additionalFields.createdDate&amazon-kinesis-video-streams-resources-blog.sort-order=desc) bietet Medienstreaming in Echtzeit über WebRTC, sodass Benutzer Medienstreams für Wiedergabe, Analyse und maschinelles Lernen erfassen, verarbeiten und speichern können. Diese Streams sind hochverfügbar, skalierbar und entsprechen den WebRTC-Standards. Amazon Kinesis Video Streams enthalten einen WebRTC-Signalendpunkt für schnelle Peer-Erkennung und sicheren Verbindungsaufbau. Es umfasst Managed Session Traversal Utilities for NAT (STUN) und Traversal Using Relays around NAT (TURN) -Endpunkte für den Medienaustausch zwischen Peers in Echtzeit. Es enthält auch ein kostenloses Open-Source-SDK, das direkt in die Kamera-Firmware integriert ist, um eine sichere Kommunikation mit Amazon Kinesis Video Streams Streams-Endpunkten zu ermöglichen und Peer-Discovery und Medienstreaming zu ermöglichen. Schließlich bietet es Clientbibliotheken für Android und iOS, JavaScript die es WebRTC-kompatiblen Mobil- und Webplayern ermöglichen, ein Kameragerät für Medienstreaming und bidirektionale Kommunikation sicher zu erkennen und eine Verbindung mit diesem herzustellen.
# Hochverfügbares SIP-Trunking mit Amazon Chime Voice Connector
[Amazon Chime Voice Connector](https://docs.aws.amazon.com/chime-sdk/latest/ag/voice-connectors.html) bietet einen pay-as-you-go SIP-Trunking-Service, der es Unternehmen ermöglicht, sichere und kostengünstige Telefonanrufe mit ihren Telefonsystemen zu tätigen und/oder zu empfangen. Amazon Chime Voice Connector ist eine kostengünstige Alternative zu SIP-Trunks von Dienstanbietern oder ISDN (Integrated Services Digital Network) -Primary Rate Interfaces (). PRIs Kunden haben die Möglichkeit, eingehende Anrufe, ausgehende Anrufe oder beides zu aktivieren.
Der Dienst nutzt das AWS Netzwerk, um ein hochverfügbares Anruferlebnis über mehrere Kanäle hinweg bereitzustellen. AWS-Regionen Sie können Audio von SIP-Trunking-Telefonanrufen oder SIPREC-Feeds (Forward SIP-Based Media Recording) an Amazon Kinesis Video Streams streamen, um in Echtzeit Erkenntnisse aus Geschäftsanrufen zu gewinnen. Durch die Integration mit [Amazon Transcribe und anderen gängigen Bibliotheken für maschinelles Lernen können](https://aws.amazon.com/transcribe/) Sie schnell Anwendungen für Audioanalysen erstellen.