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à.
Pilastro dell'affidabilità
Il pilastro dell'affidabilità del AWS Well-Architected Framework comprende la capacità di un carico di lavoro di svolgere la funzione prevista in modo corretto e coerente quando previsto. Ciò comprende la possibilità di utilizzare e testare il carico di lavoro per tutto il ciclo di vita.
Un carico di lavoro affidabile comincia con decisioni iniziali di progettazione sia per il software sia per l'infrastruttura. Le tue scelte architetturali avranno un impatto sul comportamento del carico di lavoro su tutti i pilastri del Framework Well-Architected. Per l'affidabilità, è necessario seguire modelli specifici.
Il pilastro dell'affidabilità si concentra sulle seguenti aree chiave:
-
Architettura del carico di lavoro, comprese le quote di servizio e i modelli di implementazione
-
Gestione delle modifiche
-
Gestione dei guasti
Comprendi le quote di servizio di Neptune
Un volume cluster Neptune può crescere fino a una dimensione massima di 128 tebibyte (TiB) in tutte le aree supportate Regioni AWS tranne la Cina e GovCloud, dove la quota è di 64 TiB.
La quota di 128 TiB è sufficiente per memorizzare circa 200-400 miliardi di oggetti nel grafico. In un grafico delle proprietà etichettate (LPG), un oggetto è un nodo, un bordo o una proprietà su un nodo o un bordo. In un grafico RDF (Resource Description Framework), un oggetto è un quadrilatero.
Per qualsiasi cluster Neptune Serverless, è possibile impostare sia il numero minimo che il numero massimo di unità di capacità Neptune (). NCUs Ogni NCU è composta da 2 gibibyte (GiB) di memoria e dalla vCPU e rete associate. I valori NCU minimo e massimo si applicano a tutte le istanze serverless del cluster. Il valore NCU massimo che è possibile impostare è 128,0 e il valore minimo è 1,0 NCUs. NCUs Ottimizza la gamma NCU più adatta alla tua applicazione osservando le CloudWatch metriche di Amazon e acquisendo l'intervallo in cui lavori di solito ServerlessDatabaseCapacity e NCUUtilization correlando comportamenti o costi indesiderati all'interno di tale intervallo. Se ritieni che il tuo carico di lavoro non sia sufficientemente scalabile, aumenta il valore minimo NCUs per fornire un'elaborazione sufficiente per il picco iniziale durante la scalabilità.
Account AWS Ciascuna di esse prevede quote per ogni regione sul numero di risorse di database che è possibile creare. Queste risorse includono le istanze database e i cluster di database. Dopo aver raggiunto il limite per una risorsa, le ulteriori richieste di creazione di tale risorsa restituiranno un errore con un'eccezione. Alcune quote sono quote flessibili che possono essere aumentate su richiesta. Per un elenco delle quote condivise tra Amazon Neptune e Amazon RDS, Amazon Aurora e Amazon DocumentDB (con compatibilità con MongoDB), insieme ai link per richiedere aumenti delle quote quando disponibili, consulta Quotas in Amazon RDS.
Comprendi i modelli di implementazione di Neptune
Nei cluster Neptune DB, esiste un'istanza DB principale e fino a 15 repliche Neptune. L'istanza DB principale supporta le operazioni di lettura e scrittura ed esegue tutte le modifiche ai dati sul volume del cluster. Le repliche Neptune si connettono allo stesso volume di storage dell'istanza DB principale e supportano solo operazioni di lettura. Le repliche Neptune possono scaricare i carichi di lavoro di lettura dall'istanza DB principale.
Per ottenere un'elevata disponibilità, utilizzate le repliche di lettura. La disponibilità di una o più istanze di replica di lettura in diverse zone di disponibilità può aumentare la disponibilità perché le repliche di lettura fungono da obiettivi di failover per l'istanza principale. Se l'istanza writer fallisce, Neptune promuove un'istanza di replica in lettura facendola diventare l'istanza principale. Quando ciò accade, si verifica una breve interruzione (generalmente inferiore a 30 secondi) durante il riavvio dell'istanza promossa, durante la quale le richieste di lettura e scrittura fatte all'istanza principale hanno esito negativo con un'eccezione. Per la massima affidabilità, prendi in considerazione due repliche di lettura in zone di disponibilità diverse. Se l'istanza principale nella Zona di disponibilità 1 va offline, l'istanza nella Zona di disponibilità 2 viene promossa a principale, ma non può gestire le query mentre ciò accade. Pertanto è necessaria un'istanza nella Zona di disponibilità 3 per gestire le query di lettura durante la transizione.
Se utilizzi Neptune Serverless, le istanze di lettura e scrittura in tutte le zone di disponibilità verranno scalate verso l'alto e verso il basso, indipendentemente l'una dall'altra, a seconda del carico del database. È possibile impostare il livello di promozione di un'istanza Reader su 0 o 1 in modo che venga scalato verso l'alto e verso il basso in base alla capacità dell'istanza writer. In questo modo è pronta ad assumersi il carico di lavoro corrente in qualsiasi momento.
Gestisci e ridimensiona i cluster Neptune
È possibile utilizzare l'auto-scaling di Neptune per regolare automaticamente il numero di repliche Neptune in un cluster DB per soddisfare i requisiti di connettività e carico di lavoro in base alle soglie di utilizzo della CPU. Con l'auto-scaling, il cluster Neptune DB è in grado di gestire aumenti improvvisi del carico di lavoro. Quando il carico di lavoro diminuisce, l'auto-scaling rimuove le repliche non necessarie in modo da non dover pagare per la capacità inutilizzata. Tieni presente che l'avvio di una nuova istanza può richiedere fino a 15 minuti, quindi l'auto-scaling da solo non è una soluzione sufficiente per i rapidi cambiamenti della domanda.
Puoi utilizzare l'auto-scaling solo con un cluster Neptune DB che ha già un'istanza writer principale e almeno un'istanza di lettura-replica (vedi Amazon Neptune DB Clusters and Instances). Inoltre, tutte le istanze di replica di lettura nel cluster devono essere in stato disponibile. Se una replica di lettura si trova in uno stato diverso da quello disponibile, l'auto-scaling di Neptune non fa nulla finché non sono disponibili tutte le repliche di lettura nel cluster.
Se riscontri rapidi cambiamenti nella domanda, prendi in considerazione l'utilizzo di istanze serverless. Le istanze serverless possono essere scalate verticalmente per brevi periodi, mentre l'auto-scaling è scalabile orizzontalmente per periodi più lunghi. Questa configurazione offre una scalabilità ottimale perché le istanze serverless scalano verticalmente, mentre l'auto-scaling crea istanze di nuove repliche di lettura per gestire il carico di lavoro oltre la capacità massima di una singola istanza serverless. Per ulteriori informazioni sulla scalabilità della capacità di Amazon Neptune Serverless, consulta Scalabilità della capacità in un cluster DB Neptune Serverless.
Se le tue esigenze di scalabilità cambiano in tempi prevedibili, puoi pianificare le modifiche alle istanze minime, alle istanze massime e alle soglie per gestire meglio queste mutevoli esigenze. Ricorda di pianificare gli eventi di scalabilità orizzontale con almeno 15 minuti di anticipo per consentire a tali istanze di essere online quando necessario.
Puoi gestire la configurazione del database in Amazon Neptune utilizzando i parametri in un gruppo di parametri. I gruppi di parametri fungono da container per i valori di configurazione di un motore applicati a una o più istanze database. Quando modificate i parametri del cluster in gruppi di parametri, comprendete la differenza tra parametri statici e dinamici e come e quando vengono applicati. Usa l'endpoint di stato per vedere la configurazione attualmente applicata.
Gestisci i backup e gli eventi di failover
Neptune esegue automaticamente il backup del volume del cluster e conserva i dati di backup per tutta la durata del periodo di conservazione del backup. I backup di Neptune sono continui e incrementali, in modo da poter eseguire rapidamente un ripristino a qualsiasi momento nel tempo del periodo di conservazione del backup. È possibile specificare un periodo di conservazione dei backup da 1 a 35 giorni quando si crea o si modifica un cluster DB.
Per conservare un backup oltre il periodo di conservazione del backup, puoi anche scattare un'istantanea dei dati nel volume del cluster. All'archiviazione degli snapshot verranno applicati i costi di archiviazione standard per Neptune.
Quando crei uno snapshot Amazon Neptune di un cluster DB, Neptune crea uno snapshot del volume di storage del cluster, eseguendo il backup di tutti i dati, non solo delle singole istanze. È possibile creare un nuovo cluster database ripristinandolo da questo snapshot. Quando ripristini il cluster DB, fornisci il nome dello snapshot del cluster DB da cui eseguire il ripristino, quindi fornisci un nome per il nuovo cluster DB creato dal ripristino.
Verifica la risposta del sistema agli eventi di failover. Usa l'API Neptune per forzare un evento di failover. Il riavvio con failover è utile quando si desidera simulare un guasto di un'istanza DB per eseguire test o ripristinare le operazioni nella zona di disponibilità originale dopo un failover. Per ulteriori informazioni, consulta Configurazione e gestione di un'implementazione Multi-AZ. Quando si riavvia un'istanza di DB Writer, questa passa alla replica in standby. Il riavvio di una replica Neptune non causa un failover.
Progetta i tuoi clienti in modo da renderli affidabili. Verifica il loro comportamento durante gli eventi di failover. Implementa la logica di ripetizione dei tentativi nel tuo client con una logica di backoff esponenziale. Esempi di codice che implementano questa logica sono disponibili negli esempi di AWS Lambda funzioni per Amazon Neptune.
Prendi in considerazione l'utilizzo AWS Backup
