Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Utilizzo di implementazioni Multi-AZ per Amazon RDS su AWS Outposts
Per le implementazioni Multi-AZ, Amazon RDS crea un'istanza DB primaria su un Outpost. AWS RDS replica in modo sincrono i dati in un'istanza database in standby in un Outpost diverso.
Le implementazioni Multi-AZ AWS Outposts funzionano come le implementazioni Multi-AZ in, ma con le seguenti differenze: Regioni AWS
-
Richiedono una connessione locale tra due o più outpost.
-
Richiedono pool IP (CoIP) di proprietà del cliente. Per ulteriori informazioni, consulta Indirizzi IP di proprietà del cliente per Amazon RDS in AWS Outposts.
-
La replica viene eseguita sulla rete locale.
Multi-AZ on AWS Outposts è disponibile per tutte le versioni supportate di MySQL e PostgreSQL on RDS on Outposts. I backup locali non sono supportati per le implementazioni Multi-AZ. Per ulteriori informazioni, consulta Creazione delle istanze database per Amazon RDS su AWS Outposts.
Operare con il modello di responsabilità condivisa
Sebbene compia sforzi commercialmente ragionevoli per fornire istanze DB configurate per l'elevata disponibilità, la disponibilità AWS utilizza un modello di responsabilità condivisa. Affinché RDS su Outposts possa eseguire il failover e riparare le istanze database, è necessario che ciascuno degli outpost sia collegato alla propria Regione AWS.
Inoltre, per poter eseguire la replica sincrona, RDS su Outposts richiede che ci sia connettività tra l'outpost che ospita l'istanza database primaria e quello che ospita l'istanza database in standby. Qualsiasi cosa ostacoli questa connessione può impedire l'esecuzione del failover da parte di RDS su Outposts.
Le implementazioni standard dell'istanza database risultanti dalla replica sincrona dei dati presentano spesso una latenza elevata. La larghezza di banda e la latenza della connessione tra l'outpost che ospita l'istanza database primaria e quello che ospita l'istanza database in standby influiscono direttamente sulle latenze. Per ulteriori informazioni, consulta Prerequisiti.
Miglioramento della disponibilità
Per migliorare la disponibilità, ti consigliamo di eseguire queste azioni:
-
Assegna una capacità aggiuntiva sufficiente per le applicazioni mission-critical, al fine di consentire il ripristino e il failover in caso di problemi con l'host sottostante. Ciò vale per tutti gli outpost aventi sottoreti nel tuo gruppo di sottoreti database. Per ulteriori informazioni, vedere Resilience in. AWS Outposts
-
Fornisci una connettività di rete ridondante agli outpost in uso.
-
Utilizza più di due outpost. Se Amazon RDS ha a disposizione più di due Outpost, può recuperare un'istanza database. RDS esegue questo ripristino spostando l'istanza database in un altro Outpost se si verifica un errore nell'Outpost corrente.
-
Fornisci all'outpost una doppia sorgente di alimentazione e una connettività di rete ridondante.
Per le reti locali, ti consigliamo quanto segue:
-
La latenza dovuta al tempo di round trip (RTT) tra l'outpost che ospita l'istanza database primaria e quello che ospita l'istanza database in standby, influisce direttamente sulla latenza di scrittura. Mantieni la latenza RTT tra gli AWS Outposts nei millisecondi bassi a una cifra. Idealmente non più di 5 millisecondi, ma i requisiti possono variare.
Puoi trovare l'impatto netto sulla latenza di rete nelle CloudWatch metriche di Amazon per.
WriteLatencyPer ulteriori informazioni, consulta CloudWatch Parametri Amazon per Amazon RDS. -
La presenza di connessione tra gli outpost influisce sulla disponibilità complessiva delle istanze database. Connettività di rete ridondante tra gli outpost.
Prerequisiti
I prerequisiti per le implementazioni multi-AZ in RDS su Outposts sono i seguenti:
-
Due outpost connessi tra loro tramite connessione locale e collegati a diverse zone di disponibilità in una Regione AWS.
-
Verifica che i gruppi di sottorete database contengano i seguenti elementi:
-
Minimo due sottoreti in almeno due zone di disponibilità in una determinata Regione AWS.
-
Sottoreti localizzate esclusivamente in outpost.
-
Minimo due sottoreti in almeno due outpost all'interno dello stesso cloud privato virtuale (VPC).
-
-
Associa il VPC dell'istanza database a tutte le tabelle di routing del gateway locale. Questa associazione è necessaria perché la replica viene eseguita sulla rete locale utilizzando i gateway locali Outpost.
Ad esempio, supponiamo che il tuo VPC contenga la sottorete-A nell'Outpost-A e la subnet-B nell'Outpost-B. Outpost-A utilizza -A (LGW-A) e Outpost-B utilizza -B (LGW-B). LocalGateway LocalGateway RouteTableLGW-A ha -A RouteTable e LGW-B ha -B. Si desidera utilizzare sia RouteTable -A che -B per il traffico di replica. RouteTable Per fare ciò, associa il tuo VPC sia a -A che a RouteTable -B. RouteTable
Per ulteriori informazioni su come creare un'associazione, consulta il comando Amazon EC2 create-local-gateway-route- table-vpc-association AWS CLI .
-
Assicurati che gli outpost utilizzino l'IP routing (CoIP) di proprietà del cliente. Ogni tabella di routing deve inoltre avere almeno un pool di indirizzi. Amazon RDS assegna un indirizzo IP aggiuntivo alle istanze database primarie e uno alle istanze database in standby per la sincronizzazione dei dati.
-
Assicurati Account AWS che il proprietario delle istanze DB RDS possieda le tabelle di routing del gateway locale e i pool CoIP. In alternativa assicurati che faccia parte di una condivisione Resource Access Manager con accesso alle tabelle di routing del gateway locale e ai pool CoIP.
-
Assicurati che gli indirizzi IP dei pool CoIP possano essere instradati da un gateway locale Outpost all'altro.
-
Assicurati che i blocchi CIDR del VPC (ad esempio, 10.0.0.0/4) e i blocchi CIDR del pool CoIP non contengano indirizzi IP di classe E (240.0.0.0/4). RDS utilizza questi indirizzi IP internamente.
-
Assicurati di aver impostato correttamente il traffico correlato in entrata e in uscita.
RDS su Outposts stabilisce una connessione di rete privata virtuale (VPN) tra le istanze database primarie e quelle in standby. Affinché la connessione funzioni correttamente, la rete locale deve consentire il traffico correlato in entrata e in uscita per Internet Security Association and Key Management Protocol (ISAKMP). A tale scopo utilizza la porta UDP (User Datagram Protocol) 500 e IP Security () Network Address Translation Traversal (IPsecNAT-T) utilizzando la porta UDP 4500.
Per ulteriori informazioni su CoIPs, consultate questa guida e gli indirizzi IP di proprietà Indirizzi IP di proprietà del cliente per Amazon RDS in AWS Outposts del cliente nella Guida per l'utente.AWS Outposts
Utilizzo delle operazioni API per ottenere autorizzazioni Amazon EC2
Indipendentemente dal fatto che utilizzi Co IPs per la tua istanza DB AWS Outposts, RDS richiede l'accesso alle risorse del pool CoIP. RDS può richiamare le seguenti operazioni API di autorizzazione EC2 per Co per conto dell'utente per le implementazioni IPs Multi-AZ:
-
CreateCoipPoolPermission- quando crei un'istanza database Multi-AZ in RDS su Outposts -
DeleteCoipPoolPermission- quando elimini un'istanza database Multi-AZ in RDS su Outposts
Queste operazioni API concedono o rimuovono dagli account RDS interni l'autorizzazione ad assegnare indirizzi IP elastici provenienti dal pool CoIP specificato dall'autorizzazione. È possibile visualizzare questi indirizzi IP utilizzando l'operazione API DescribeCoipPoolUsage. Per ulteriori informazioni su CoIPs, consulta gli indirizzi IP di proprietà del cliente nella Indirizzi IP di proprietà del cliente per Amazon RDS in AWS Outposts Guida per l'utente.AWS Outposts
Durante le implementazioni Multi-AZ, RDS può anche chiamare le seguenti operazioni API per richiedere per tuo conto le autorizzazioni EC2 relative alle tabelle di routing gateway locali:
-
CreateLocalGatewayRouteTablePermission- quando crei un'istanza database Multi-AZ in RDS su Outposts -
DeleteLocalGatewayRouteTablePermission- quando elimini un'istanza database Multi-AZ in RDS su Outposts
Queste operazioni API concedono o rimuovono dagli account RDS interni l'autorizzazione ad associare RDS interno alle tabelle di routing del VPCs gateway locale. È possibile visualizzare queste associazioni tra tabella di routing e VPC utilizzando le operazioni API DescribeLocalGatewayRouteTableVpcAssociations.
