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..
-
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.
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.
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.
-
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. -
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 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. neste guia e Endereços IP de propriedade do cliente 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. e Endereços IP de propriedade do cliente 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.
