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à.
Un cluster Amazon DynamoDB Accelerator DAX () è costituito da componenti dell'infrastruttura. AWS In questa sezione sono descritti questi componenti e come funzionano insieme.
Argomenti
Nodi
Il nodo è il più piccolo elemento di base di un cluster DAX. Ogni nodo esegue un'istanza del software DAX e mantiene una singola replica dei dati memorizzati nella cache.
Puoi dimensionare il tuo cluster DAX in uno dei due modi seguenti:
-
Aggiungendo più nodi al cluster. Questo aumenta il throughput di lettura complessivo del cluster.
-
Usando un tipo di nodo più grande. I tipi di nodi più grandi forniscono più capacità e possono aumentare il throughput. (Devi creare un nuovo cluster con il nuovo tipo di nodo.)
Ogni nodo all'interno di un cluster è dello stesso tipo di nodo ed esegue lo stesso software di cache DAX. Per un elenco dei tipi di nodi disponibili, consulta Prezzi di Amazon DynamoDB
Cluster
Un cluster è un raggruppamento logico di uno o più nodi gestiti da DAX come un'unità. Uno dei nodi nel cluster è designato come il nodo primario e gli altri nodi, se presenti, sono le repliche di lettura.
Il nodo primario è responsabile per quanto segue:
-
Soddisfare le richieste delle applicazioni per i dati memorizzati nella cache.
-
Gestione delle operazioni di scrittura in DynamoDB.
-
Espellere i dati dalla cache in base alla policy di espulsione del cluster.
Quando vengono apportate modifiche ai dati memorizzati nella cache sul nodo primario, DAX propaga le modifiche a tutti i nodi di replica letti utilizzando i log di replica. Dopo aver ricevuto la conferma da tutte le repliche di lettura, DynamoDB elimina i log di replica dal nodo primario.
Un DAX cluster può supportare fino a 11 nodi per cluster (il nodo principale più un massimo di 10 repliche di lettura).
Le repliche di lettura sono responsabili per quanto segue:
-
Soddisfare le richieste delle applicazioni per i dati memorizzati nella cache.
-
Espellere i dati dalla cache in base alla policy di espulsione del cluster.
Tuttavia, a differenza del nodo primario, le repliche di lettura non scrivono su DynamoDB.
Le repliche di lettura hanno due scopi aggiuntivi:
-
Scalabilità. Se hai un numero elevato di client applicativi che devono accedere a DAX contemporaneamente, puoi aggiungere più repliche per il dimensionamento della lettura. DAX distribuisce il carico in modo uniforme in tutti i nodi del cluster. Un altro modo per aumentare il throughput è utilizzare tipi di nodi di cache più grandi.
-
Elevata disponibilità. Nel caso di un errore del nodo primario, DAX esegue automaticamente il failover su una replica di lettura e lo designa come nuovo nodo primario. Se un nodo di replica non riesce, altri nodi nel cluster DAX sono ancora in grado di assolvere le richieste finché il nodo con l'errore non viene ripristinato. Per la massima tolleranza ai guasti, devi distribuire le repliche di lettura in zone di disponibilità separate. Questa configurazione garantisce che il tuo cluster DAX possa continuare a funzionare anche se un'intera zona di disponibilità diventa non disponibile.
Importante
Per l'uso in produzione, consigliamo vivamente di utilizzare DAX con almeno tre nodi, in cui i nodi sono collocati in diverse zone di disponibilità. Per fare in modo che un cluster DAX sia tollerante ai guasti sono richiesti tre nodi.
Un cluster DAX può essere distribuito con uno o due nodi per lo sviluppo o il test di carichi di lavoro. I cluster a uno o due nodi non tollerano i guasti e non è consigliabile utilizzare meno di tre nodi per l'uso in produzione. Se in un cluster a uno o due nodi si verificano errori software o hardware, il cluster può diventare non disponibile o perdere i dati memorizzati nella cache.
Importante
Un DAX cluster supporta un massimo di 500 tabelle DynamoDB. Se superi le 500 tabelle, il cluster potrebbe subire un peggioramento della disponibilità e delle prestazioni.
Regioni e zone di disponibilità
Un DAX cluster in una AWS regione può interagire solo con le tabelle DynamoDB che si trovano nella stessa regione. Per questo motivo, assicurati di avviare il cluster DAX nella regione corretta. Se hai tabelle DynamoDB in altre regioni, devi DAX avviare i cluster anche in quelle regioni.
Ogni regione è pensata per essere completamente isolata dalle altre regioni . All'interno di ciascuna regione ci sono più zone di disponibilità. Avviando i nodi in diverse zone di disponibilità, puoi ottenere la massima tolleranza ai guasti possibile.
Importante
Non posizionare tutti i nodi del cluster in un'unica zona di disponibilità. In questa configurazione, il cluster DAX diventa non disponibile in caso di un guasto della zona di disponibilità.
Per l'uso in produzione, consigliamo vivamente di utilizzare DAX con almeno tre nodi, in cui i nodi sono collocati in diverse zone di disponibilità. Per fare in modo che un cluster DAX sia tollerante ai guasti sono richiesti tre nodi.
Un cluster DAX può essere distribuito con uno o due nodi per lo sviluppo o il test di carichi di lavoro. I cluster con uno o due nodi non sono tolleranti ai guasti e non consigliamo di utilizzare meno di tre nodi in produzione. Se un cluster con uno o due nodi rileva errori software o hardware, il cluster può diventare non disponibile o perdere i dati memorizzati nella cache.
Gruppi di parametri
I gruppi di parametri vengono utilizzati per gestire le impostazioni di runtime per i cluster. DAX DAXdispone di diversi parametri che è possibile utilizzare per ottimizzare le prestazioni (come la definizione di una TTL politica per i dati memorizzati nella cache). Un gruppo di parametri è un set denominato di parametri applicabili a un cluster. Puoi assicurarti che tutti i nodi di quel cluster siano configurati esattamente nello stesso modo.
Gruppi di sicurezza
Un DAX cluster viene eseguito in un ambiente Amazon Virtual Private Cloud (AmazonVPC). Questo ambiente è una rete virtuale dedicata al tuo AWS account ed è isolata dagli altriVPCs. Un gruppo di sicurezza funge da firewall virtuale per teVPC, consentendoti di controllare il traffico di rete in entrata e in uscita.
Quando avvii un cluster nel tuoVPC, aggiungi una regola di ingresso al tuo gruppo di sicurezza per consentire il traffico di rete in entrata. La regola di ingresso specifica il protocollo (TCP) e il numero di porta (8111) per il cluster. Dopo aver aggiunto questa regola al gruppo di sicurezza, le applicazioni in esecuzione all'interno del gruppo VPC possono accedere al cluster. DAX
Cluster ARN
A ogni DAX cluster viene assegnato un Amazon Resource Name (ARN). Il ARN formato è il seguente.
arn:aws:dax:
region
:accountID
:cache/clusterName
Il cluster viene utilizzato ARN in una IAM politica per definire le autorizzazioni per le DAX API operazioni. Per ulteriori informazioni, consulta DAXcontrollo degli accessi.
Endpoint del cluster
Ogni cluster DAX fornisce un endpoint del cluster per l'uso da parte dell'applicazione. Accedendo al cluster tramite questo endpoint, l'applicazione non ha bisogno dei nomi host e dei numeri di porta dei singoli nodi nel cluster. L'applicazione viene a "conoscenza" automaticamente di tutti i nodi del cluster, anche se aggiungi o rimuovi le repliche di lettura.
Di seguito è riportato un esempio di endpoint cluster nella regione us-est-1 che non è configurato per l'utilizzo della crittografia in transito.
dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
Di seguito è riportato un esempio di endpoint cluster nella stessa regione che è configurata per l'utilizzo della crittografia in transito.
daxs://my-encrypted-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com
Endpoint dei nodi
Ciascuno dei singoli nodi di un DAX cluster ha il proprio nome host e numero di porta. Di seguito è riportato un esempio di un endpoint del nodo.
myDAXcluster-a.2cmrwl.clustercfg.dax.use1.cache.amazonaws.com:8111
L'applicazione può accedere a un nodo direttamente utilizzando il suo endpoint. Tuttavia, ti consigliamo di trattare il cluster DAX come una singola unità e accedervi utilizzando l'endpoint del cluster. L'endpoint del cluster evita all'applicazione di dover gestire un elenco di nodi e di doverlo mantenere aggiornato quando aggiungi o rimuovi nodi dal cluster.
Gruppi di sottoreti
L'accesso ai nodi DAX del cluster è limitato alle applicazioni in esecuzione su EC2 istanze Amazon all'interno di un VPC ambiente Amazon. Puoi utilizzare i gruppi di sottoreti per concedere l'accesso ai cluster da EC2 istanze Amazon in esecuzione su sottoreti specifiche. Un gruppo di sottoreti è una raccolta di sottoreti (in genere private) che puoi designare per i tuoi cluster in esecuzione in un ambiente Amazon. VPC
Quando si crea un cluster DAX, è necessario specificare un gruppo di sottoreti. DAX usa il gruppo di sottoreti per selezionare una sottorete e un indirizzo IP all'interno di quella sottorete da associare ai nodi.
Eventi
DAX registra gli eventi significativi all'interno dei cluster, ad esempio l'impossibilità di aggiungere un nodo, l'aggiunta di un nodo o le modifiche ai gruppi di sicurezza. Tramite il monitoraggio degli eventi chiave, puoi conoscere lo stato corrente dei cluster e, in base all'evento, essere in grado di intraprendere operazioni correttive. Puoi accedere a questi eventi utilizzando l'azione AWS Management Console o nella DescribeEvents
gestione. DAX API
Puoi anche richiedere che le notifiche vengano inviate a un argomento specifico di Amazon Simple Notification Service (AmazonSNS). In questo modo saprai immediatamente quando un evento si verifica nel cluster DAX.
Maintenance window (Finestra di manutenzione)
Ogni cluster dispone di una finestra di manutenzione settimanale per applicare le modifiche al sistema. Man mano che le modifiche vengono applicate in sequenza, un nodo esistente viene sostituito e un nuovo nodo con le modifiche applicate viene aggiunto al cluster. Durante questo periodo, l'applicazione potrebbe riscontrare errori o rallentamenti temporanei. Pertanto, si consiglia di pianificare la finestra di manutenzione durante il periodo di utilizzo minimo e di modificarla periodicamente in base alle esigenze. Puoi specificare un intervallo di tempo di 24 ore al massimo durante il quale si verificano le attività di manutenzione richieste.
Se non specifichi una finestra di manutenzione preferita quando crei o modifichi un cluster di cache, DAX assegna una finestra di manutenzione di 60 minuti in un giorno feriale casuale. Questa finestra di manutenzione di 60 minuti viene selezionata casualmente tra un periodo di 8 ore per ciascuna. Regione AWS La seguente tabella elenca i blocchi temporali per ciascuna regione da cui sono assegnate le finestre di manutenzione predefinite.
Codice regione | Nome Regione | Maintenance window (Finestra di manutenzione) |
---|---|---|
ap-northeast-1 | Regione Asia Pacifico (Tokyo) | 13:00 — 21:00 UTC |
ap-southeast-1 | Regione Asia Pacifico (Singapore) | 14:00 — 22:00 UTC |
ap-southeast-2 | Asia Pacifico (Sydney) | 12:00 — 20:00 UTC |
ap-south-1 | Regione Asia Pacifico (Mumbai) | 17:30 — 1:30 UTC |
cn-northwest-1 | Regione Cina (Ningxia) | 23:00 — 07:00 UTC |
cn-north-1 | Regione Cina (Pechino) | 14:00 — 22:00 UTC |
eu-central-1 | Regione Europa (Francoforte) | 23:00 — 07:00 UTC |
eu-north-1 | Regione Europa (Stoccolma) | 01:00 — 09:00 UTC |
eu-south-2 | Regione Europa (Spagna) | 21:00 — 05:00 UTC |
eu-west-1 | Europa (Irlanda) | 22:00 — 06:00 UTC |
eu-west-2 | Regione Europa (Londra) | 23:00 — 07:00 UTC |
eu-west-3 | Regione Europa (Parigi) | 23:00 — 07:00 UTC |
sa-east-1 | Regione Sud America (San Paolo) | 01:00 — 09:00 UTC |
us-east-1 | Stati Uniti orientali (Virginia settentrionale) | 03:00 — 11:00 UTC |
us-east-2 | Stati Uniti orientali (Ohio) | 23:00 — 07:00 UTC |
us-west-1 | Regione Stati Uniti occidentali (California settentrionale) | 06:00 — 14:00 UTC |
us-west-2 | Stati Uniti occidentali (Oregon) | 06:00 — 14:00 UTC |