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à.
Operare con le implementazioni Multi-AZ per Amazon RDS su AWS Outposts
Per eseguire le implementazioni multi-AZ, Amazon RDS crea un'istanza database primaria in un AWS outpost. RDS replica in modo sincrono i dati in un'istanza database in standby in un Outpost diverso.
Le implementazioni Multi-AZ su AWS Outposts e nelle Regioni AWS seguono la stessa modalità, ma presentano le seguenti differenze:
-
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 è disponibile su AWS Outposts per tutte le versioni supportate di MySQL e PostgreSQL in RDS su 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 AWS si impegni in modo commercialmente ragionevole a fornire istanze database configurate per l'alta disponibilità, tale disponibilità si basa su 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, consulta Resilienza 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 outpost AWS al di sotto dei 10 millesecondi. Idealmente non più di 5 millisecondi, ma i requisiti possono variare.
Per verificare l'impatto netto sulla latenza di rete, cerca
WriteLatencytra i parametri di Amazon CloudWatch. Per ulteriori informazioni, consulta CloudWatch Metriche 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 sottorete-B nell'outpost-B. L'outpost-A utilizza il GatewayLocale-A (LGW-A) e l'outpost-B utilizza il GatewayLocale-B (LGW-B). All'LGW-A è assegnata la TabellaDiRouting-A e all'LGW-B la TabellaDiRouting-B. Vuoi utilizzare sia la TabellaDiRouting-A sia la TabellaDiRouting-B per il traffico di replica. Per fare ciò, dovrai associare il tuo VPC sia alla TabellaDiRouting-A sia alla TabellaDiRouting-B.
Per ulteriori informazioni su come creare un'associazione, consulta il comando della AWS CLI Amazon EC2 create-local-gateway-route-table-vpc-association.
-
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 che l'Account AWS proprietario delle istanze database RDS sia anche il proprietario delle tabelle di routing del gateway locale e dei 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). Per fare ciò, utilizza la porta UDP (User Datagram Protocol) 500 e l'attraversamento NAT-T (Network Address Translation Traversal) con protezione IP Security (IPSec), che utilizza la porta UDP 4500.
Per ulteriori informazioni sui CoIP, consulta Indirizzi IP di proprietà del cliente per Amazon RDS in AWS Outposts in questa guida e Indirizzi IP di proprietà del cliente nella Guida per l'utente di AWS Outposts.
Utilizzo delle operazioni API per ottenere autorizzazioni Amazon EC2
RDS richiede l'accesso alle risorse del pool CoIP indipendentemente dal fatto che utilizzi o meno dei CoIP per la tua istanza database su AWS Outposts. Durante l'esecuzione di un'implementazione Multi-AZ, RDS può chiamare le seguenti operazioni API per richiedere per tuo conto le autorizzazioni EC2 relative ai COIP:
-
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 sui CoIP, consulta Indirizzi IP di proprietà del cliente per Amazon RDS in AWS Outposts e Indirizzi IP di proprietà del cliente nella Guida per l'utente di 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 i VPC RDS interni con le tue tabelle di routing gateway locali. È possibile visualizzare queste associazioni tra tabella di routing e VPC utilizzando le operazioni API DescribeLocalGatewayRouteTableVpcAssociations.
