Trabajo con implementaciones Multi-AZ para Amazon RDS on AWS Outposts
Para implementaciones Multi-AZ, Amazon RDS crea una instancia de base de datos principal en un Outpost de AWS. RDS replica sincrónicamente los datos en una instancia de base de datos en espera en un Outpost diferente.
Las implementaciones Multi-AZ en AWS Outposts operan como implementaciones Multi-AZ en Regiones de AWS, pero con las siguientes diferencias:
-
Requieren una conexión local entre dos o más Outposts.
-
Requieren grupos IP propiedad del cliente (CoIP). Para obtener más información, consulte Direcciones IP propiedad del cliente para Amazon RDS en AWS Outposts.
-
La replicación se ejecuta en la red local.
Multi-AZ on AWS Outposts está disponible para todas las versiones compatibles de MySQL y PostgreSQL en RDS on Outposts. No se admiten las copias de seguridad locales de las implementaciones Multi-AZ. Para obtener más información, consulte Creación de instancias de base de datos para Amazon RDS on AWS Outposts.
Trabajo con el modelo de responsabilidad compartida
Aunque AWS hace los esfuerzos comercialmente razonables para proporcionar instancias de base de datos configuradas para una alta disponibilidad, la disponibilidad utiliza un modelo de responsabilidad compartida. La capacidad de RDS on Outposts de conmutación por error y reparación de instancias de base de datos requiere que cada uno de los Outposts esté conectado a su Región de AWS.
RDS on Outposts también requiere conectividad entre el Outpost que aloja la instancia de base de datos principal y el Outpost que aloja la instancia de base de datos en espera para la replicación sincrónica. Cualquier impacto en esta conexión puede impedir que RDS on Outposts realice una conmutación por error.
Pueden producirse latencias elevadas para una implementación de instancia de base de datos estándar como resultado de la replicación de datos sincrónica. El ancho de banda y la latencia de la conexión entre Outpost que aloja la instancia de base de datos principal y el Outpost que aloja la instancia de base de datos en espera afectan directamente a las latencias. Para obtener más información, consulte Requisitos previos.
Mejora de la disponibilidad
Le recomendamos que utilice las siguientes acciones para mejorar la disponibilidad:
-
Asigne suficiente capacidad adicional para sus aplicaciones de misión crítica para permitir la recuperación y la conmutación por error si se produce un problema de host subyacente. Esto se aplica a todos los Outposts avanzados que contienen subredes de su grupo de subredes de base de datos. Para obtener más información, consulte Resiliencia en AWS Outposts.
-
Proporcione conectividad de red redundante para sus Outpost.
-
Utilice más de dos Outposts. Tener más de dos Outposts permite a Amazon RDS recuperar una instancia de base de datos. RDS realiza esta recuperación trasladando la instancia de base de datos a otro Outpost si el Outpost actual tiene un error.
-
Proporcione fuentes de alimentación duales y conectividad de red redundante para su Outpost.
Le recomendamos lo siguiente para las redes locales:
-
La latencia del tiempo de ida y vuelta (RTT) entre Outpost que aloja su instancia de base de datos principal y la Outpost que aloja su instancia de base de datos en espera afecta directamente a la latencia de escritura. Mantenga la latencia de RTT entre el Outposts de AWS en milisegundos bajos de un solo dígito. Recomendamos no más de 5 milisegundos, pero sus requisitos pueden variar.
Puede encontrar el impacto neto en la latencia de red en las métricas de Amazon CloudWatch para
WriteLatency. Para obtener más información, consulte Métricas de Amazon CloudWatch para Amazon RDS. -
La disponibilidad de la conexión entre los Outposts afecta a la disponibilidad general de las instancias de base de datos. Tenga conectividad de red redundante entre los Outposts.
Requisitos previos
Las implementaciones Multi-AZ en RDS on Outposts tienen los siguientes requisitos previos:
-
Tener al menos dos Outposts, conectados a través de conexiones locales y conectados a diferentes zonas de disponibilidad en una Región de AWS.
-
Asegúrese de que los grupos de subredes de base de datos contengan lo siguiente:
-
Al menos dos subredes y en al menos dos zonas de disponibilidad en una Región de AWS dada.
-
Subredes solo en Outposts.
-
Al menos dos subredes en al menos dos Outposts dentro de la misma nube privada virtual (VPC).
-
-
Asocie la VPC de su instancia de base de datos a todas las tablas de enrutamiento de la puerta de enlace local. Esta asociación es necesaria porque la replicación se ejecuta a través de la red local mediante las puertas de enlace locales de Outposts.
Por ejemplo, supongamos que la VPC contiene la subred A en la salida A y la subred B en Outpost-B. Outpost A utiliza LocalGateway-A (LGW-A) y Outpost-B utiliza LocalGateway-B (LGW-B). LGW-A tiene la tabla de enrutamiento A y LGW-B tiene la tabla de enrutamiento B. Utilice RouteTable-A y RouteTable-B para el tráfico de replicación. Para ello, asocie su VPC con RouteTable-A y RouteTable-B.
Para obtener más información sobre cómo crear una asociación, consulte el comando de la AWS CLI de Amazon EC2 create-local-gateway-ruta-table-vpc-association.
-
Asegúrese de que los Outposts utilicen enrutamiento IP propiedad del cliente (CoIP). Cada tabla de rutas también debe tener al menos un grupo de direcciones. Amazon RDS asigna una dirección IP adicional para las instancias de base de datos principal y en espera para la sincronización de datos.
-
Asegúrese deCuenta de AWS que la propietaria de las instancias de base de datos de RDS es propietaria de las tablas de enrutamiento de la puerta de enlace local y los grupos CoIP. O forma parte de un recurso compartido de Resource Access Manager con acceso a las tablas de enrutamiento de la puerta de enlace local y a los grupos CoIP.
-
Asegúrese de que las direcciones IP de sus grupos CoIP se puedan enrutar desde una puerta de enlace local Outpost a las demás.
-
Asegúrese de que los bloques CIDR de la VPC (por ejemplo, 10.0.0.0/4) y los bloques CIDR del grupo CoIP no contengan direcciones IP de la clase E (240.0.0.0/4). RDS utiliza estas direcciones IP internamente.
-
Asegúrese de configurar correctamente el tráfico entrante y saliente relacionado.
RDS on Outposts establece una conexión de red privada virtual (VPN) entre las instancias de base de datos principal y en espera. Para que esto funcione correctamente, la red local debe permitir el tráfico entrante y saliente relacionado para Internet Security Association and Key Management Protocol (ISAKMP). Lo hace en el puerto 500 del Protocolo de datagrama de usuario (UDP) y la transferencia de traducción de direcciones de red (NAT-T) de seguridad IP (IPSec) en el puerto UDP 4500.
Para obtener más información sobre los CoIP, consulte Direcciones IP propiedad del cliente para Amazon RDS en AWS Outposts en esta guía y Direcciones IP propiedad del cliente en la Guía del usuario de AWS Outposts.
Trabajo con operaciones de la API para permisos de Amazon EC2
Independientemente de si utiliza COIP para su instancia de base de datos en AWS Outposts, RDS requiere acceso a los recursos del grupo CoIP. RDS puede llamar a las siguientes operaciones de API de permisos de EC2 para COIP en implementaciones Multi-AZ:
-
CreateCoipPoolPermission: cuando crea una instancia de base de datos Multi-AZ en RDS on Outposts -
DeleteCoipPoolPermission: cuando elimina una instancia de base de datos Multi-AZ en RDS on Outposts
Estas operaciones de API otorgan el permiso (o lo eliminan) a las cuentas RDS internas para asignar direcciones IP elásticas del grupo CoIP especificado por el permiso. Puede ver estas direcciones IP mediante la operación de API DescribeCoipPoolUsage. Para obtener más información sobre los CoIP, consulte Direcciones IP propiedad del cliente para Amazon RDS en AWS Outposts y Direcciones IP propiedad del cliente en la Guía del usuario de AWS Outposts.
RDS también puede llamar a las siguientes operaciones de API de permisos de EC2 para tablas de enrutamiento de puerta de enlace local en implementaciones Multi-AZ:
-
CreateLocalGatewayRouteTablePermission: cuando crea una instancia de base de datos Multi-AZ en RDS on Outposts -
DeleteLocalGatewayRouteTablePermission: cuando elimina una instancia de base de datos Multi-AZ en RDS on Outposts
Estas operaciones de API otorgan (o eliminan) a las cuentas de RDS internas el permiso para asociar VPC RDS internas a las tablas de enrutamiento de la puerta de enlace local. Puede ver estas asociaciones de VPC de tablas de enrutamiento con las operaciones de la API DescribeLocalGatewayRouteTableVpcAssociations
