Pilastro dell'affidabilità

Il pilastro dell'affidabilità comprende la capacità di un carico di lavoro di svolgere la funzione prevista in modo corretto e coerente quando previsto. Ciò include la capacità di utilizzare e testare il carico di lavoro durante l'intero ciclo di vita.

La configurazione di un carico di lavoro affidabile inizia con decisioni di progettazione iniziali sia per il software che 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 ottenere l'affidabilità, è necessario seguire schemi 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 e scalabilità delle istanze InfluxDB

Architettura del carico di lavoro, incluse quote di servizio e modelli di implementazione

Ciascuno Account AWS ha delle quote per le risorse offerte in ciascuno di essi. Regione AWS Ad esempio, ogni regione ha una quota per Timestream per le istanze InfluxDB, indipendentemente dalla dimensione dell'istanza. Dopo aver raggiunto il numero massimo di istanze in una regione, le chiamate aggiuntive per creare istanze hanno esito negativo con un'eccezione. Il volume di archiviazione di un'istanza Timestream for InfluxDB può raggiungere una dimensione massima di 16 tebibyte () in tutte le istanze supportate. TiBs Regioni AWS

Modelli di implementazione

Per l'elevata disponibilità e il supporto di failover per Timestream per le istanze InfluxDB, puoi utilizzare implementazioni Multi-AZ con una singola istanza DB in standby. Questo tipo di implementazione è chiamato una implementazione di istanza database Multi-AZ. Amazon Timestream for InfluxDB utilizza la tecnologia di failover di Amazon. In una distribuzione di istanze DB Multi-AZ, Amazon Timestream effettua automaticamente il provisioning e mantiene una replica sincrona in standby in una zona di disponibilità diversa. Per fornire la ridondanza dei dati, l'istanza DB principale viene replicata in modo sincrono tra le zone di disponibilità nella replica di standby.

L'esecuzione di un'istanza DB con elevata disponibilità può garantire la disponibilità in caso di guasto dell'istanza DB o di interruzione della zona di disponibilità. Se un'interruzione non pianificata dell'istanza DB deriva da un difetto dell'infrastruttura, Amazon Timestream for InfluxDB passa automaticamente alla replica in standby. Il tempo necessario per il completamento del failover varia in base all'attività del database e ad altre condizioni presenti quando l'istanza database primaria diventa non disponibile.

Il failover richiede in genere da 60 a 120 secondi, Tuttavia, transazioni di grandi dimensioni con dati ad alta cardinalità o un lungo processo di ripristino con requisiti di pre-riscaldamento possono aumentare i tempi di failover. Una volta completato il failover, potrebbe essere necessario più tempo prima che la console Timestream rifletta la nuova zona di disponibilità.

Se l'applicazione deve rimanere disponibile durante un' Regione AWS interruzione completa, prendete in considerazione la possibilità di configurare la replica o la scrittura in un'altra regione come parte dei piani di disaster recovery (DR). Tuttavia, prima di configurare la replica, assicurati di averne compreso i limiti. Per ulteriori informazioni, consultate la documentazione di InfluxDB.

Amazon Timestream for InfluxDB esegue periodicamente backup interni e li conserva per 24 ore per supportare la disponibilità e la durabilità. Le istantanee vengono scattate durante le eliminazioni e conservate per 30 giorni per supportare i ripristini. Per accedervi o utilizzarle, crea un caso all'indirizzo. Supporto AWS

Gestisci e ridimensiona Timestream per InfluxDB

Timestream for InfluxDB supporta classi di istanze ideali per l'esecuzione di carichi di lavoro che richiedono molta memoria in database InfluxDB open source. Le diverse classi di istanze db.influx hanno limiti su v, memoria, archiviazione e larghezza di banda di rete. CPUs Per scegliere la classe di istanza più adatta ai requisiti di latenza di scrittura e query della tua applicazione, osserva Amazon CloudWatch CPUUtilization e i DiskUtilization parametri durante i test. MemoryUtilization Puoi scalare le istanze verso l'alto e verso il basso in base ai requisiti del carico di lavoro. Timestream for InfluxDB offre più livelli di storage preconfigurati con IOPS e throughput ottimali necessari per diversi tipi di carichi di lavoro. Scegli ciò che funziona meglio per il tuo carico di lavoro in base alle tue esigenze.

Se le tue esigenze di scalabilità cambiano in momenti prevedibili, puoi utilizzare una AWS Lambda funzione o uno scheduler personalizzato ed eseguire un'API o un SDK per scalare verso l'alto e verso il basso con un po' di tempo di buffer.

È possibile gestire la configurazione di InfluxDB in Timestream for InfluxDB utilizzando i parametri in un gruppo di parametri. I gruppi di parametri fungono da contenitore per le opzioni di configurazione di InfluxDB applicate a una o più istanze DB. Quando modificate i parametri nei gruppi di parametri, comprendete la differenza tra parametri statici e dinamici e come e quando vengono applicati. Per vedere la configurazione attualmente applicata, utilizzate l'azione GetDbParameterGroupAPI.