Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Haute disponibilité et évolutivité sur AWS
La plupart des fournisseurs de communications en temps réel s'alignent sur des niveaux de service garantissant une disponibilité comprise entre 99,9 % et 99,999 %. En fonction du degré de haute disponibilité (HA) que vous souhaitez, vous devez prendre des mesures de plus en plus sophistiquées tout au long du cycle de vie de l'application. AWS recommande de suivre ces directives pour atteindre un niveau élevé de haute disponibilité :
+ Concevez le système de manière à ce qu'il n'y ait aucun point de défaillance unique. Utilisez des mécanismes automatisés de surveillance, de détection des défaillances et de basculement pour les composants statiques et dynamiques
+ *Les points de défaillance uniques (SPOF) sont généralement éliminés avec une configuration de redondance N\$11 ou 2N, où N\$11 est obtenu via l'équilibrage de charge entre les nœuds *actifs-actifs*, et 2N est obtenu par une paire de nœuds en configuration actif-veille.*
+ AWS dispose de plusieurs méthodes pour atteindre la haute disponibilité grâce aux deux approches, par exemple via un cluster évolutif à charge équilibrée ou en supposant une paire *actif-veille*.
+ Disponibilité correcte de l'instrument et du système de test.
+ Préparez des procédures opérationnelles pour les mécanismes manuels afin de réagir, d'atténuer et de récupérer après une panne.
Cette section explique comment éliminer tout point de défaillance unique à l'aide des fonctionnalités disponibles sur AWS. Plus précisément, cette section décrit un sous-ensemble de AWS fonctionnalités de base et de modèles de conception qui vous permettent de créer des applications de communication en temps réel hautement disponibles.
# Modèle IP flottant pour la haute disponibilité entre des serveurs dynamiques actifs et en veille
Le modèle de conception IP flottante est un mécanisme bien connu pour réaliser un basculement automatique entre une paire de nœuds matériels actifs et en veille (serveurs multimédias). Une adresse IP virtuelle secondaire statique est attribuée au nœud actif. La surveillance continue entre les nœuds actifs et de secours permet de détecter les défaillances. En cas de défaillance du nœud actif, le script de surveillance attribue l'adresse IP virtuelle au nœud de secours prêt et le nœud de secours prend en charge la fonction active principale. De cette façon, l'adresse IP virtuelle flotte entre le nœud actif et le nœud de secours.
## Applicabilité dans les solutions RTC
Il n'est pas toujours possible d'avoir plusieurs instances actives du même composant en service, par exemple un cluster actif-actif de N nœuds. Une configuration active en veille constitue le meilleur mécanisme pour la haute disponibilité. Par exemple, les composants dynamiques d'une solution RTC, tels que le serveur multimédia ou le serveur de conférence, ou même un serveur SBC ou un serveur de base de données, conviennent parfaitement à une configuration active en veille. Un serveur SBC ou multimédia possède plusieurs sessions ou canaux actifs de longue durée à un moment donné, et en cas de défaillance de l'instance active SBC, les points de terminaison peuvent se reconnecter au nœud de secours sans aucune configuration côté client en raison de l'adresse IP flottante.
### Mise en œuvre le AWS
Vous pouvez implémenter ce modèle sur AWS à l'aide des fonctionnalités de base d'Amazon Elastic Compute Cloud (Amazon EC2), de EC2 l'API Amazon, des adresses IP élastiques et du support d'Amazon EC2 pour les adresses IP privées secondaires.
Pour implémenter le modèle IP flottant sur AWS :
1. Lancez deux EC2 instances pour assumer les rôles de nœuds principal et secondaire, le nœud principal étant supposé être *actif* par défaut.
1. Attribuez une adresse IP privée secondaire supplémentaire à l' EC2 instance principale.
1. Une adresse IP élastique, similaire à une adresse IP virtuelle (VIP), est associée à l'adresse privée secondaire. Cette adresse privée secondaire est l'adresse utilisée par les points de terminaison externes pour accéder à l'application.
1. Une certaine configuration du système d'exploitation (OS) est requise pour que l'adresse IP secondaire soit ajoutée en tant qu'alias à l'interface réseau principale.
1. L'application doit être liée à cette adresse IP élastique. Dans le cas du logiciel Asterisk, vous pouvez configurer la liaison via les paramètres avancés du SIP Asterisk.
1. Exécutez un script de surveillance (personnalisé, KeepAlive sous Linux, Corosync, etc.) sur chaque nœud pour surveiller l'état du nœud homologue. En cas de défaillance du nœud actif actuel, l'homologue détecte cette défaillance et invoque l' EC2 API Amazon pour se réattribuer l'adresse IP privée secondaire.
Par conséquent, l'application qui écoutait sur le VIP associé à l'adresse IP privée secondaire devient accessible aux terminaux via le nœud de secours.
![\[Schéma illustrant le basculement entre des EC2 instances dynamiques à l'aide d'une adresse IP élastique.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/real-time-communication-on-aws/images/failover-stateful.jpg)
#### Avantages
Cette approche est une solution fiable à petit budget qui protège contre les défaillances au niveau de l' EC2 instance, de l'infrastructure ou de l'application.
##### Limites et extensibilité
Ce modèle de conception est généralement limité à une seule zone de disponibilité. Il peut être mis en œuvre dans deux zones de disponibilité, mais avec des variantes. Dans ce cas, l'adresse IP élastique flottante est réassociée entre le nœud actif et le nœud de secours dans différentes zones de disponibilité via l'API d'adresse IP élastique de réassociation disponible. Dans l'implémentation du basculement illustrée dans la figure précédente, les appels en cours sont abandonnés et les terminaux doivent se reconnecter. Il est possible d'étendre cette implémentation avec la réplication des données de session sous-jacentes afin de permettre un basculement fluide des sessions ou une continuité multimédia.
#### Équilibrage de charge pour l'évolutivité et la haute disponibilité avec WebRTC et SIP
L'équilibrage de charge d'un cluster d'instances actives basé sur des règles prédéfinies, telles que le round robin, l'affinité ou la latence, etc., est un modèle de conception largement popularisé par la nature apatride des requêtes HTTP. En fait, l'équilibrage de charge est une option viable dans le cas de nombreux composants d'application RTC.
L'équilibreur de charge fait office de proxy inverse ou de point d'entrée pour les demandes adressées à l'application souhaitée, elle-même configurée pour s'exécuter simultanément sur plusieurs nœuds actifs. À tout moment, l'équilibreur de charge dirige une demande utilisateur vers l'un des nœuds actifs du cluster défini. Les équilibreurs de charge vérifient l'état des nœuds de leur cluster cible et n'envoient aucune demande entrante à un nœud qui échoue au contrôle de santé. Par conséquent, un degré fondamental de haute disponibilité est atteint grâce à l'équilibrage de charge. De plus, étant donné qu'un équilibreur de charge effectue des contrôles de santé actifs et passifs sur tous les nœuds du cluster à des intervalles inférieurs à une seconde, le temps de basculement est quasi instantané.
La décision quant au nœud à diriger est basée sur les règles du système définies dans l'équilibreur de charge, notamment :
+ tournoi à la ronde
+ Affinité de session ou d'adresse IP, qui garantit que plusieurs demandes au sein d'une session ou provenant de la même adresse IP sont envoyées au même nœud du cluster
+ Basé sur la latence
+ Basé sur la charge
## Applicabilité dans les architectures RTC
[Le protocole WebRTC permet d'équilibrer facilement la charge des passerelles WebRTC via un équilibreur de charge basé sur le protocole HTTP, tel que [Elastic Load Balancing (ELB), Application Load](https://aws.amazon.com/elasticloadbalancing/)[Balancer (ALB) ou Network Load](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) Balancer (NLB).](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/) La plupart des implémentations SIP reposant sur le transport via le protocole TCP (Transmission Control Protocol) et le protocole UDP (User Datagram Protocol), vous avez besoin d'un équilibrage de charge au niveau du réseau ou de la connexion, avec prise en charge du trafic TCP et UDP.
## L'équilibrage de charge est activé AWS pour WebRTC à l'aide d'Application Load Balancer et d'Auto Scaling
Dans le cas des communications basées sur le WebRTC, Elastic Load Balancing fournit un équilibreur de charge entièrement géré, hautement disponible et évolutif qui sert de point d'entrée pour les demandes, qui sont ensuite dirigées vers un cluster cible EC2 d'instances associé à Elastic Load Balancing. Les demandes WebRTC étant apatrides, vous pouvez utiliser Amazon Auto EC2 Scaling pour fournir une évolutivité, une élasticité et une haute disponibilité entièrement automatisées et contrôlables.
L'Application Load Balancer fournit un service d'équilibrage de charge entièrement géré, hautement disponible à l'aide de plusieurs zones de disponibilité et évolutif. Cela prend en charge l'équilibrage de charge des WebSocket demandes qui gèrent la signalisation pour les applications WebRTC et la communication bidirectionnelle entre le client et le serveur à l'aide d'une connexion TCP de longue durée. L'Application Load Balancer prend également en charge le routage basé sur le contenu et les [sessions persistantes, en acheminant](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html) les demandes du même client vers la même cible à l'aide de cookies générés par l'équilibreur de charge. Si vous activez les sessions persistantes, la même cible reçoit la demande et peut utiliser le cookie pour récupérer le contexte de session.
La figure suivante montre la topologie cible.
![\[Schéma illustrant l'évolutivité et l'architecture de haute disponibilité du WebRTC.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/real-time-communication-on-aws/images/webrtc-scalability.png)
## Implémentation pour le protocole SIP à l'aide de Network Load Balancer ou d'un produit AWS Marketplace
Dans le cas des communications basées sur SIP, les connexions sont établies via TCP ou UDP, la majorité des applications RTC utilisant UDP. Si le protocole de signal de choix est le SIP/TCP, il est possible d'utiliser le Network Load Balancer pour un équilibrage de charge entièrement géré, hautement disponible, évolutif et performant.
Un Network Load Balancer fonctionne au niveau de la connexion (couche 4) et achemine les connexions vers des cibles telles que les EC2 instances Amazon, les conteneurs et les adresses IP en fonction des données du protocole IP. Idéal pour l'équilibrage de la charge du trafic TCP ou UDP, l'équilibrage de charge réseau est capable de traiter des millions de demandes par seconde tout en maintenant des latences extrêmement faibles. Il est intégré à d'autres services AWS populaires, tels qu'Amazon EC2 Auto Scaling, [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (Amazon ECS), [Amazon Elastic Kubernetes](https://aws.amazon.com/eks/) Service (Amazon EKS) et. [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
Si des connexions SIP sont initiées, une autre option consiste à utiliser un off-the-shelf logiciel [AWS Marketplace](https://aws.amazon.com/marketplace)commercial (COTS). Elle AWS Marketplace propose de nombreux produits capables de gérer l'UDP et d'autres types d'équilibrage de charge de connexion de couche 4. Les COTS incluent généralement la prise en charge de la haute disponibilité et s'intègrent généralement à des fonctionnalités, telles qu'Amazon EC2 Auto Scaling, pour améliorer encore la disponibilité et l'évolutivité. La figure suivante montre la topologie cible :
![\[Schéma illustrant l'évolutivité du RTC basée sur le protocole SIP avec le produit AWS Marketplace.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/real-time-communication-on-aws/images/sip-based-rtc-scalability.jpg)
# Équilibrage de charge et basculement entre régions basés sur le DNS
[Amazon Route 53](https://aws.amazon.com/route53/) fournit un service DNS mondial qui peut être utilisé comme point de terminaison public ou privé pour permettre aux clients RTC de s'inscrire et de se connecter à des applications multimédia. Avec Amazon Route 53, les contrôles de santé du DNS peuvent être configurés pour acheminer le trafic vers des points de terminaison sains ou pour surveiller indépendamment l'état de santé de votre application.
La fonctionnalité Amazon Route 53 Traffic Flow vous permet de gérer facilement le trafic mondial par le biais de différents types de routage, notamment le routage basé sur la latence, le géo-DNS, la géoproximité et le round robin pondéré. Tous ces éléments peuvent être combinés au DNS Failover pour permettre une variété d'architectures à faible latence et tolérantes aux pannes. L'éditeur visuel simple Amazon Route 53 Traffic Flow vous permet de gérer la manière dont vos utilisateurs finaux sont acheminés vers les points de terminaison de votre application, que ce soit dans une seule région AWS ou répartis dans le monde entier.
Dans le cas des déploiements mondiaux, la politique de routage basée sur la latence de Route 53 est particulièrement utile pour diriger les clients vers le point de présence le plus proche d'un serveur multimédia afin d'améliorer la qualité de service associée aux échanges multimédias en temps réel.
Notez que pour appliquer un basculement vers une nouvelle adresse DNS, les caches des clients doivent être vidés. En outre, les modifications du DNS peuvent être retardées lorsqu'elles sont propagées sur les serveurs DNS mondiaux. Vous pouvez gérer l'intervalle d'actualisation pour les recherches DNS à l'aide de l'attribut Time to Live. Cet attribut est configurable au moment de configurer les politiques DNS.
Pour atteindre rapidement les utilisateurs du monde entier ou pour répondre aux exigences liées à l'utilisation d'une adresse IP publique unique, il AWS Global Accelerator peut également être utilisé pour le basculement entre régions. [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)est un service réseau qui améliore la disponibilité et les performances des applications à portée locale et mondiale. AWS Global Accelerator fournit des adresses IP statiques qui agissent comme un point d'entrée fixe vers les points de terminaison de vos applications, tels que vos équilibreurs de charge d'application, vos équilibreurs de charge réseau ou les EC2 instances Amazon dans une ou plusieurs régions AWS. Il utilise le réseau mondial AWS pour optimiser le chemin entre vos utilisateurs et vos applications, en améliorant les performances, telles que la latence de votre trafic TCP et UDP.
AWS Global Accelerator surveille en permanence l'état des points de terminaison de votre application et redirige automatiquement le trafic vers les points de terminaison sains les plus proches en cas de défaillance des terminaux actuels. Pour répondre AWS Global Accelerator à des exigences de sécurité supplémentaires, le Site-to-Site VPN accéléré améliore les performances des connexions VPN en acheminant intelligemment le trafic via le réseau mondial AWS et les emplacements périphériques d'AWS.
![\[Schéma illustrant la conception de la haute disponibilité interrégionale à l'aide d'AWS Global Accelerator ou d'Amazon Route 53.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/real-time-communication-on-aws/images/inter-region-ha-design.png)
# Durabilité des données et haute disponibilité avec stockage persistant
La plupart des applications RTC s'appuient sur le stockage persistant pour stocker et accéder aux données à des fins d'authentification, d'autorisation, de comptabilité (données de session, enregistrements détaillés des appels, etc.), de surveillance opérationnelle et de journalisation. Dans un centre de données traditionnel, garantir la haute disponibilité et la durabilité des composants de stockage persistants (bases de données, systèmes de fichiers, etc.) nécessite généralement de lourdes tâches via la configuration d'un réseau de stockage (SAN), la conception d'un réseau redondant de disques indépendants (RAID) et des processus de sauvegarde, de restauration et de basculement. Cela simplifie et améliore AWS Cloud considérablement les pratiques traditionnelles des centres de données en matière de durabilité et de disponibilité des données.
Pour le stockage d'objets et le stockage de fichiers, AWS des services tels qu'[Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) et [Amazon Elastic File System](https://aws.amazon.com/efs/) (Amazon EFS) fournissent une haute disponibilité et une évolutivité gérées. Amazon S3 a une durabilité des données de 99,999999999 % (11 neuf).
Pour le stockage des données transactionnelles, les clients ont la possibilité de tirer parti de l'Amazon Relational Database Service (Amazon RDS) entièrement géré qui prend en charge Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle et Microsoft SQL Server avec des déploiements à haute disponibilité. Pour la fonction d'enregistrement, le profil des abonnés ou le stockage des dossiers comptables (tels que CDRs), Amazon RDS fournit une option tolérante aux pannes, hautement disponible et évolutive.
# Dimensionnement dynamique avec AWS Lambda Amazon Route 53 et Amazon EC2 Auto Scaling
AWS permet d'enchaîner les fonctionnalités et d'intégrer des fonctions sans serveur personnalisées en tant que service en fonction des événements de l'infrastructure. L'un de ces modèles de conception qui a de nombreuses utilisations polyvalentes dans les applications RTC est la combinaison du dimensionnement automatique des hooks du cycle de vie avec [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html), Amazon Route 53 et [AWS Lambda](https://aws.amazon.com/lambda/)les fonctions. AWS Lambda les fonctions peuvent intégrer n'importe quelle action ou logique. La figure suivante montre comment ces fonctionnalités associées peuvent améliorer la fiabilité et l'évolutivité du système grâce à l'automatisation.
![\[Schéma illustrant le dimensionnement automatique avec des mises à jour dynamiques d'Amazon Route 53.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/real-time-communication-on-aws/images/auto-scaling-dynamic-updates.jpg)
# WebRTC à haute disponibilité avec Amazon Kinesis Video Streams
[Amazon Kinesis Video](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) Streams propose un streaming multimédia en temps réel via WebRTC, permettant aux utilisateurs de capturer, de traiter et de stocker des flux multimédias à des fins de lecture, d'analyse et d'apprentissage automatique. Ces flux sont hautement disponibles, évolutifs et conformes aux normes WebRTC. Amazon Kinesis Video Streams inclut un point de terminaison de signalisation WebRTC pour une détection rapide des pairs et l'établissement de connexions sécurisées. Il inclut des utilitaires gérés de traversée de session pour NAT (STUN) et des utilitaires de traversée utilisant des relais autour des points de terminaison NAT (TURN) pour l'échange de contenu multimédia en temps réel entre pairs. Il inclut également un SDK open source gratuit qui s'intègre directement au microprogramme de la caméra pour permettre une communication sécurisée avec les points de terminaison Amazon Kinesis Video Streams, permettant ainsi la découverte par les pairs et le streaming multimédia. Enfin, il fournit des bibliothèques clientes pour Android et iOS JavaScript qui permettent aux lecteurs mobiles et Web compatibles WebRTC de découvrir et de se connecter en toute sécurité à un appareil photo pour le streaming multimédia et la communication bidirectionnelle.
# Trunking SIP hautement disponible avec Amazon Chime Voice Connector
[Amazon Chime Voice Connector](https://docs.aws.amazon.com/chime-sdk/latest/ag/voice-connectors.html) fournit un service de jonction pay-as-you-go SIP qui permet aux entreprises de passer et/ou de recevoir des appels téléphoniques sécurisés et peu coûteux avec leurs systèmes téléphoniques. Amazon Chime Voice Connector est une alternative peu coûteuse aux liaisons SIP des fournisseurs de services ou aux interfaces à débit primaire (ISDN) du réseau numérique à intégration de services (). PRIs Les clients ont la possibilité d'activer les appels entrants, sortants ou les deux.
Le service utilise le AWS réseau pour offrir une expérience d'appel hautement disponible sur plusieurs réseaux Régions AWS. Vous pouvez diffuser du son à partir d'appels téléphoniques à jonction SIP ou transférer des flux d'enregistrement multimédia basés sur le protocole SIP (SIPREC) vers Amazon Kinesis Video Streams pour obtenir des informations sur les appels professionnels en temps réel. Vous pouvez créer rapidement des applications d'analyse audio grâce à l'intégration à [Amazon Transcribe](https://aws.amazon.com/transcribe/) et à d'autres bibliothèques d'apprentissage automatique courantes.