# Trabalhar com implantações multi-AZ para o Amazon RDS no AWS Outposts
No caso de implantações multi-AZ, o Amazon RDS cria uma instância de banco de dados primário em um AWS Outpost. O RDS replica de forma síncrona os dados em uma instância de banco de dados em espera em outro Outpost.
Implantações multi-AZ no AWS Outposts funcionam como implantações multi-AZ nas Regiões da AWS, mas com as seguintes diferenças:
+ Elas exigem uma conexão local entre dois ou mais Outposts.
+ Elas exigem grupos de IPs de propriedade do cliente (CoIP). Para ter mais informações, consulte [Endereços IP de propriedade do cliente para o Amazon RDS no AWS Outposts.](rds-on-outposts.coip.md).
+ A replicação é realizada na sua rede local.
O recurso multi-AZ no AWS Outposts está disponível para todas as versões compatíveis do MySQL e do PostgreSQL no RDS on Outposts. Não há compatibilidade para backups locais em implantações multi-AZ. Para ter mais informações, consulte [Criar instâncias de banco de dados para o Amazon RDS on AWS Outposts](rds-on-outposts.creating.md).
## Trabalhar com o modelo de responsabilidade compartilhada
Embora a AWS utilize esforços comercialmente razoáveis para fornecer instâncias de banco de dados configuradas para alta disponibilidade, a disponibilidade usa um modelo de responsabilidade compartilhada. A capacidade do RDS on Outposts de fazer failover e reparar instâncias de banco de dados exige que todos os seus Outposts estejam conectados à sua Região da AWS.
O RDS on Outposts também exige conectividade entre o Outpost que está hospedando a instância de banco de dados primário e o Outpost que está hospedando a instância de banco de dados em espera para replicação síncrona. Qualquer impacto nessa conexão pode impedir que o RDS on Outposts realize um failover.
Talvez você perceba latências elevadas para uma implantação de instância de banco de dados padrão como resultado da replicação de dados síncrona. A largura de banda e a latência da conexão entre o Outpost que hospeda a instância de banco de dados primário e o Outpost que hospeda a instância de banco de dados em espera afetam diretamente as latências. Para ter mais informações, consulte [Pré-requisitos](#rds-on-outposts.maz.prereqs).
## Melhorar a disponibilidade
Recomendamos as seguintes ações para melhorar a disponibilidade:
+ Aloque capacidade adicional suficiente para suas aplicações essenciais à missão para permitir recuperação e o failover se houver um problema de host subjacente. Isso se aplica a todos os Outposts que contêm sub-redes em seu grupo de sub-redes de banco de dados. Para ter mais informações, consulte [Resiliência no AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/disaster-recovery-resiliency.html).
+ Forneça conectividade de rede redundante para o Outposts.
+ Use mais de dois Outposts. Ter mais de dois Outposts permite que o Amazon RDS recupere uma instância de banco de dados. O RDS faz essa recuperação movendo a instância de banco de dados para outro Outpost se o Outpost atual tiver uma falha.
+ Forneça fontes de alimentação duplas e conectividade de rede redundante para o Outpost.
Recomendamos o seguinte para suas redes locais:
+ A latência do tempo de ida e volta (RTT) entre o Outpost que hospeda sua instância de banco de dados primário e o Outpost que hospeda sua instância de banco de dados em espera afeta diretamente a latência de gravação. Mantenha a latência RTT entre o AWS Outposts em milissegundos de um dígito baixo. Recomendamos até cinco milissegundos, mas seus requisitos podem variar.
Você pode encontrar o impacto líquido na latência da rede nas métricas do Amazon CloudWatch para `WriteLatency`. Para ter mais informações, consulte [Métricas do Amazon CloudWatch para o Amazon RDS](rds-metrics.md).
+ A disponibilidade da conexão entre os Outposts afeta a disponibilidade geral de suas instâncias de banco de dados. Tenha conectividade de rede redundante entre os Outposts.
## Pré-requisitos
As implantações multi-AZ no RDS on Outposts têm os seguintes pré-requisitos:
+ Tenha pelo menos dois Outposts, conectados por conexões locais e anexados a diferentes zonas de disponibilidade em uma Região da AWS.
+ Seus grupos de sub-redes de banco de dados devem conter o seguinte:
+ No mínimo duas sub-redes em pelo menos duas zonas de disponibilidade em determinada Região da AWS.
+ Sub-redes somente nos Outposts.
+ Pelo menos duas sub-redes em pelo menos dois Outposts dentro da mesma nuvem privada virtual (VPC).
+ Associe a VPC de sua instância de banco de dados a todas as tabelas de rotas de gateway local. Essa associação é necessária porque a replicação é realizada por sua rede local usando os gateways locais de seus Outposts.
Por exemplo, suponha que sua VPC contenha a sub-rede A no Outpost-A e a sub-rede-B no Outpost-B. O Outpost-A usa LocalGateway-A (LGW-A) e o Outpost-B usa LocalGateway-B (LGW-B). O LGW-A tem RouteTable-A e o LGW-B tem RouteTable-B. Você precisa usar RouteTable-A e RouteTable-B para o tráfego de replicação. Para fazer isso, associe sua VPC a RouteTable-A e RouteTable-B.
Para ter mais informações sobre como criar uma associação, consulte o comando [create-local-gateway-route-table-vpc-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-local-gateway-route-table-vpc-association.html) AWS CLI do Amazon EC2.
+ Verifique se seus Outposts usam o roteamento IP de propriedade do cliente (CoIP). Cada tabela de rotas também deve ter pelo menos um grupo de endereços. O Amazon RDS aloca um endereço IP adicional para as instâncias de banco de dados primário e em espera para sincronização de dados.
+ Verifique se a Conta da AWS que possui as instâncias de banco de dados do RDS tem as tabelas de rotas de gateway local e os grupos de CoIPs. Ou verifique se faz parte de um compartilhamento do Resource Access Manager com acesso às tabelas de rotas de gateway local e aos grupos de CoIPs.
+ Verifique se os endereços IP em seus grupos de CoIPs podem ser roteados de um gateway local do Outpost para os outros.
+ Verifique se os blocos CIDR da VPC (por exemplo, 10.0.0.0/4) e seus blocos CIDR do grupo de CoIPs não contêm endereços IP da Classe E (240.0.0.0/4). O RDS usa esses endereços IP internamente.
+ Não se esqueça de configurar corretamente o tráfego de entrada de saída e relacionado.
O RDS on Outposts estabelece conexão de rede privada virtual (VPN) entre as instâncias de banco de dados primário e em espera. Para que isso funcione corretamente, sua rede local deve permitir tráfego de entrada de saída e relacionado para o Internet Security Association and Key Management Protocol (ISAKMP). Ele faz isso usando a porta 500 do User Datagram Protocol (UDP) e a porta 4500 do IP Security (IPsec) Network Address Translation Traversal (NAT-T) usando UDP.
Para ter mais informações sobre CoIPs, consulte [Endereços IP de propriedade do cliente para o Amazon RDS no AWS Outposts.](rds-on-outposts.coip.md) neste guia e [Endereços IP de propriedade do cliente](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html#ip-addressing) no *Guia do usuário do AWS Outposts*.
## Trabalhar com operações de API para permissões do Amazon EC2
Independentemente de você usar COIPs para sua instância de banco de dados no AWS Outposts, o RDS precisa de acesso aos recursos do grupo de CoIPs. O RDS pode chamar as seguintes operações de API de permissões do EC2 para CoIPs em seu nome para implantações multi-AZ:
+ `CreateCoipPoolPermission`: quando você cria uma instância de banco de dados multi-AZ no RDS on Outposts
+ `DeleteCoipPoolPermission`: quando você exclui uma instância de banco de dados multi-AZ no RDS on Outposts
Essas operações de API concedem ou removem de contas do RDS internas a permissão para alocar endereços de IP elásticos do grupo de CoIPs especificado pela permissão. Você pode visualizar esses endereços IP usando a operação de API do `DescribeCoipPoolUsage`. Para ter mais informações sobre CoIPs, consulte [Endereços IP de propriedade do cliente para o Amazon RDS no AWS Outposts.](rds-on-outposts.coip.md) e [Endereços IP de propriedade do cliente](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html#ip-addressing) no *Guia do usuário do AWS Outposts*.
O RDS também pode chamar as seguintes operações de API de permissões do EC2 para tabelas de rotas de gateway local em seu nome para implantações multi-AZ:
+ `CreateLocalGatewayRouteTablePermission`: quando você cria uma instância de banco de dados multi-AZ no RDS on Outposts
+ `DeleteLocalGatewayRouteTablePermission`: quando você exclui uma instância de banco de dados multi-AZ no RDS on Outposts
Essas operações de API concedem ou removem de contas do RDS internas a permissão para associar internas VPCs do RDS às tabelas de rotas de gateway local. Você pode visualizar essas associações de tabelas de rotas e VPC usando as operações de API do `DescribeLocalGatewayRouteTableVpcAssociations`.