Utilisation des déploiements multi-AZ pour Amazon RDS on AWS Outposts

Pour les déploiements multi-AZ, Amazon RDS crée une instance de base de données principale sur un AWS Outpost. RDS réplique de manière synchrone les données vers une instance de base de données en veille sur un Outpost différent.

Les déploiements Multi-AZ sur AWS Outposts fonctionnent comme les déploiements Multi-AZ dans Régions AWS, mais avec les différences suivantes :

• Ils nécessitent une connexion locale entre deux Outposts ou plus.

• Ils nécessitent des groupes d'IP appartenant aux clients (CoIP). Pour de plus amples informations, veuillez consulter Adresses IP appartenant au client pour Amazon RDS on AWS Outposts.

• La réplication fonctionne sur votre réseau local.

Les déploiements Multi-AZ sur AWS Outposts sont disponibles pour toutes les versions prises en charge de MySQL et de PostgreSQL sur RDS on Outpost. Les sauvegardes locales ne sont pas prises en charge pour les déploiements Multi-AZ. Pour de plus amples informations, veuillez consulter Création d'instances de base de données pour Amazon RDS sur AWS Outposts.

Utiliser le modèle de responsabilité partagée

Bien que AWS fasse des efforts commercialement raisonnables pour fournir des instances de base de données configurées pour une haute disponibilité, la disponibilité utilise un modèle de responsabilité partagée. La capacité de RDS on Outposts à basculer et à réparer les instances de base de données nécessite que chacun de vos Outposts soit connecté à sa propre Région AWS.

RDS on Outposts nécessite également une connectivité entre l'Outpost qui héberge l'instance de base de données principale et l'Outpost qui héberge l'instance de base de données en veille pour la réplication synchrone. Tout impact sur cette connexion peut empêcher RDS on Outposts d'effectuer un basculement.

Vous pouvez constater des latences élevées pour un déploiement d'instance de base de données standard en raison de la réplication synchrone des données. La bande passante et la latence de la connexion entre l'Outpost hébergeant l'instance de base de données principale et l'Outpost hébergeant l'instance de base de données de secours affectent directement les latences. Pour de plus amples informations, veuillez consulter Prérequis.

Amélioration de la disponibilité

Nous recommandons les actions suivantes pour améliorer la disponibilité :

• Allouez une capacité supplémentaire suffisante à vos applications stratégiques pour permettre la reprise et le basculement en cas de problème d'hôte sous-jacent. Ceci s'applique à tous les Outposts qui contiennent des sous-réseaux dans votre groupe de sous-réseaux de base de données. Pour plus d'informations, consultez Résilience dans AWS Outposts.

• Fournissez une connectivité réseau redondante pour vos Outposts.

• Utilisez plus de deux Outposts. Avoir plus de deux Outposts permet à Amazon RDS de récupérer une instance de base de données. RDS effectue cette restauration en déplaçant l'instance de base de données vers un Outpost si l'Outpost actuel subit une panne.

• Fournissez deux sources d'alimentation et une connectivité réseau redondante pour votre Outpost.

Nous recommandons les éléments suivants pour vos réseaux locaux :

• La latence de durée du cycle (RTT) entre l'Outpost hébergeant votre instance de base de données principale et l'Outpost hébergeant votre instance de base de données de secours affecte directement la latence d'écriture. Maintenez la latence RTT entre les Outposts AWS dans une plage de valeurs en millisecondes la plus basse possible (un chiffre). Nous recommandons de ne pas dépasser cinq millisecondes, mais vos besoins peuvent varier.

  Vous pouvez trouver l'impact net sur la latence du réseau dans les métriques Amazon CloudWatch pour WriteLatency. Pour de plus amples informations, veuillez consulter CloudWatch Métriques Amazon pour Amazon RDS.

• La disponibilité de la connexion entre les Outposts affecte la disponibilité globale de vos instances de base de données. Disposez d'une connectivité réseau redondante entre les Outposts.

Prérequis

Les déploiements Multi-AZ sur RDS on Outpost présentent les prérequis suivants :

• Disposez d'au moins deux Outposts, reliés par des connexions locales et attachés à des zones de disponibilité différentes dans une Région AWS

• Assurez-vous que vos groupes de sous-réseau de base de données contiennent les éléments suivants :

  • Au moins deux sous-réseaux dans au moins deux zones de disponibilité au sein d'une Région AWS donnée.

  • Sous-réseaux uniquement dans les Outposts.

  • Au moins deux sous-réseaux dans au moins deux Outposts au sein du même cloud privé virtuel (VPC).

• Associez le VPC de votre instance de base de données à toutes vos tables de routage de passerelles locales. Cette association est nécessaire car la réplication s'effectue sur votre réseau local en utilisant les passerelles locales de vos Outposts.

  Par exemple, supposons que votre VPC contienne le sous-réseau-A dans l'Outpost-A et le sous-réseau-B dans l'Outpost-B. L'Outpost-A utilise LocalGateway-A (LGW-A) et l'Outpost-B utilise LocalGateway-B (LGW-B). LGW-A possède RouteTable-A, et LGW-B possède RouteTable-B. Vous souhaitez utiliser à la fois RouteTable-A et RouteTable-B pour le trafic de réplication. Pour ce faire, associez votre VPC à la fois à RouteTable-A et RouteTable-B.

  Pour plus d'informations sur la création d'une association, consultez la commande AWS CLI Amazon EC2 create-local-gateway-route-table-vpc-association.

• Assurez-vous que vos Outposts utilisent des routages IP appartenant au client (CoIP). Chaque table de routage doit également avoir au moins un groupe d'adresses. Amazon RDS alloue une adresse IP supplémentaire à chacune des instances de base de données principale et de veille pour la synchronisation des données.

• Assurez-vous qu'Compte AWS à qui appartiennent les instances de base de données RDS possède les tables de routage de la passerelle locale et les groupes d'adresses IP clients. Ou assurez-vous qu'il fait partie d'un partage Resource Access Manager ayant accès aux tables de routage de la passerelle locale et aux groupes d'adresses IP clients.

• Assurez-vous que les adresses IP de vos groupes CoIP peuvent être routées d'une passerelle locale d'un Outpost vers les autres.

• Assurez-vous que les blocs d'adresse CIDR du VPC (par exemple, 10.0.0.0/4) et les blocs d'adresse CIDR de votre groupe de CoIP ne contiennent pas d'adresses IP de la classe E (240.0.0.0/4). RDS utilise ces adresses IP en interne.

• Assurez-vous que vous avez correctement configuré le trafic sortant et le trafic entrant correspondant.

  RDS on Outposts établit une connexion de réseau VPN entre les instances de base de données principale et de veille. Pour que cela fonctionne correctement, votre réseau local doit autoriser le trafic sortant et le trafic entrant correspondant pour le protocole ISAKMP (Internet Security Association and Key Management Protocol). Il utilise pour cela le port 500 du protocole UDP (User Datagram Protocol) et le port 4500 du protocole NAT-T (Network Address Translation Traversal) de la sécurité IP (IPsec).

Pour plus d'informations sur les CoIP, consultez Adresses IP appartenant au client pour Amazon RDS on AWS Outposts dans ce guide et la section Customer-owned IP addresses (Adresses IP appartenant au client) dans le Guide de l'utilisateur AWS Outposts.

Utilisation des opérations API pour les autorisations Amazon EC2

Que vous utilisiez ou non des CoIP pour votre instance de base de données on AWS Outposts, RDS a besoin d'accéder aux ressources de votre groupe de CoIP. RDS peut appeler les opérations suivantes de l'API d'autorisations EC2 pour les CoIP en votre nom pour les déploiements Multi-AZ :

• CreateCoipPoolPermission : lorsque vous créez une instance de base de données Multi-AZ sur RDS on Outposts

• DeleteCoipPoolPermission : lorsque vous supprimez une instance de base de données Multi-AZ sur RDS on Outposts

Ces opérations API accordent ou retirent aux comptes internes RDS l'autorisation d'allouer des adresses IP élastiques à partir du groupe de CoIP spécifié par l'autorisation. Vous pouvez visualiser ces adresses IP en utilisant l'opération API DescribeCoipPoolUsage. Pour plus d'informations sur les CoIP, consultez Adresses IP appartenant au client pour Amazon RDS on AWS Outposts et Customer-owned IP addresses (Adresses IP appartenant au client) dans le Guide de l'utilisateur AWS Outposts.

RDS peut également appeler les opérations suivantes de l'API d'autorisations EC2 pour les tables de routage des passerelles locales en votre nom pour les déploiements Multi-AZ :

• CreateLocalGatewayRouteTablePermission : lorsque vous créez une instance de base de données Multi-AZ sur RDS on Outposts

• DeleteLocalGatewayRouteTablePermission — lorsque vous supprimez une instance de base de données Multi-AZ sur RDS on Outposts

Ces opérations API accordent ou retirent aux comptes RDS internes l'autorisation d'associer les VPC RDS internes aux tables de routage de votre passerelle locale. Vous pouvez visualiser ces associations table de routage-VPC à l'aide des opérations API DescribeLocalGatewayRouteTableVpcAssociations.