Gestione dei cluster DAX - Amazon DynamoDB

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à.

Gestione dei cluster DAX

In questa sezione vengono descritte alcune attività di gestione comuni per i cluster Amazon DynamoDB Accelerator (DAX).

Autorizzazioni IAM per la gestione di un cluster DAX

Quando si amministra un cluster DAX utilizzando AWS Management Console o il AWS Command Line Interface (AWS CLI), si consiglia vivamente di restringere l'ambito delle azioni che gli utenti possono eseguire. Così facendo, puoi mitigare i rischi seguendo il principio del minimo privilegio.

La discussione seguente è incentrata sul controllo degli accessi per le API di gestione DAX. Per ulteriori informazioni, consulta Amazon DynamoDB Accelerator nella Documentazione di riferimento delle API di Amazon DynamoDB.

Nota

Per informazioni più dettagliate sulla gestione delle autorizzazioni AWS Identity and Access Management (IAM), consulta quanto segue:

Per le API di gestione DAX, non è possibile estendere le operazioni dell'API a una risorsa specifica. L'elemento Resource deve essere impostato su "*". Ciò differisce dalle operazioni API del piano dati DAX come GetItem, Query e Scan. Le operazioni del piano dati sono esposte tramite il client DAX e possono essere orientate verso risorse specifiche.

A titolo illustrativo, si consideri il documento della policy IAM riportato di seguito.

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "dax:*" ], "Effect": "Allow", "Resource": [ "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" ] } ] }

Si supponga che l'intento di questa policy sia quello di consentire le chiamate API di gestione DAX per il cluster DAXCluster01 e solo per quel cluster.

Supponiamo ora che un utente emetta il seguente AWS CLI comando.

aws dax describe-clusters

Questo comando non riesce con un'eccezione Not Authorized, perché la chiamata API DescribeClusters sottostante non può essere orientata a un cluster specifico. Anche se la policy è sintatticamente valida, il comando non riesce perché l'elemento Resource deve essere impostato su "*". Tuttavia, se l'utente esegue un programma che invia le chiamate del piano dati DAX (ad esempio GetItem o Query) su DAXCluster01, queste chiamate avranno esito positivo. Questo perché le API del piano dati DAX possono essere associate a risorse specifiche (in questo caso, DAXCluster01).

Se si desidera scrivere una singola policy IAM completa che comprenda sia le API di gestione DAX che le API del piano dati DAX, è preferibile includere due istruzioni distinte nel documento della policy. Una di queste istruzioni deve riguardare le API del piano dati DAX mentre l'altra istruzione si rivolge alle API di gestione DAX.

Di seguito viene illustrato un esempio di policy che mostra questo approccio. Nota come l'istruzione DAXDataAPIs è orientata alla risorsa DAXCluster01, ma la risorsa per DAXManagementAPIs deve essere "*". Le operazioni mostrate in ogni istruzione sono a solo scopo illustrativo. Puoi personalizzarle in base alle esigenze dell'applicazione.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXDataAPIs", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem" ], "Effect": "Allow", "Resource": [ "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" ]}, { "Sid": "DAXManagementAPIs", "Action": [ "dax:CreateParameterGroup", "dax:CreateSubnetGroup", "dax:DecreaseReplicationFactor", "dax:DeleteCluster", "dax:DeleteParameterGroup", "dax:DeleteSubnetGroup", "dax:DescribeClusters", "dax:DescribeDefaultParameters", "dax:DescribeEvents", "dax:DescribeParameterGroups", "dax:DescribeParameters", "dax:DescribeSubnetGroups", "dax:IncreaseReplicationFactor", "dax:ListTags", "dax:RebootNode", "dax:TagResource", "dax:UntagResource", "dax:UpdateCluster", "dax:UpdateParameterGroup", "dax:UpdateSubnetGroup" ], "Effect": "Allow", "Resource": [ "*" ] } ] }

Dimensionamento di un cluster DAX

Esistono sono due opzioni per il dimensionamento di un cluster DAX. La prima opzione è dimensionamento orizzontale, dove aggiungi le repliche di lettura al cluster. La seconda opzione è dimensionamento verticale, dove selezioni diversi tipi di nodo. Per informazioni su come approcciare la scelta della dimensione del cluster e del tipo di nodo appropriati per l'applicazione, consulta Guida alle dimensioni del cluster DAX.

Dimensionamento orizzontale

Con il dimensionamento orizzontale puoi migliorare il throughput delle operazioni di lettura aggiungendo più repliche di lettura al cluster. Un singolo cluster DAX supporta fino a 10 repliche di lettura e puoi aggiungere o rimuovere le repliche mentre il cluster è in esecuzione.

Quando si aggiunge un nuovo nodo, è necessario sincronizzare i dati della cache da un nodo peer. Pertanto, il tempo di aggiunta varia in base alla dimensione della cache e al carico di lavoro dell'applicazione. Come best practice, consigliamo di pre-dimensionare il cluster per soddisfare i picchi di traffico previsti. Per informazioni sulle linee guida per il corretto dimensionamento e sui consigli di monitoraggio, consulta. Guida alle dimensioni del cluster DAX

AWS CLI Gli esempi seguenti mostrano come aumentare o diminuire il numero di nodi. L'argomento --new-replication-factor specifica il numero totale di nodi nel cluster. Uno è il nodo primario e gli altri nodi sono repliche di lettura.

aws dax increase-replication-factor \ --cluster-name MyNewCluster \ --new-replication-factor 5
aws dax decrease-replication-factor \ --cluster-name MyNewCluster \ --new-replication-factor 3
Nota

Lo stato del cluster cambia in modifying quando modifichi il fattore di replica. Lo stato cambia in available quando la modifica è completata.

Dimensionamento verticale

Se hai un ampio set di dati funzionanti, l'applicazione potrebbe trarre vantaggio dall'utilizzo dei tipi di nodi più grandi. I nodi più grandi possono consentire al cluster di memorizzare più dati in memoria, riducendo i mancati riscontri nella cache e migliorando le prestazioni complessive dell'applicazione. Tutti i nodi in un cluster DAX devono essere dello stesso tipo.

Se il cluster DAX ha un tasso elevato di operazioni di scrittura o mancati riscontri nella cache, l'applicazione potrebbe anche trarre vantaggio dall'utilizzo di tipi di nodi più grandi. Le operazioni di scrittura e i mancati riscontri nella cache utilizzano le risorse sul nodo primario del cluster. Pertanto, l'utilizzo di tipi di nodi più grandi potrebbe aumentare le prestazioni del nodo primario e quindi consentire un throughput maggiore per questi tipi di operazioni.

Non è possibile modificare i tipi di nodo su un cluster DAX in esecuzione. Invece, devi creare un nuovo cluster con il tipo di nodo desiderato. Per un elenco dei tipi di nodo supportati, consulta Nodi.

È possibile creare un nuovo cluster DAX utilizzando il AWS Management Console, AWS CloudFormation AWS CLI, o l'AWS SDK. (Per AWS CLI, utilizzate il --node-type parametro per specificare il tipo di nodo.)

Personalizzazione delle impostazioni del cluster DAX

Quando si crea un cluster DAX, vengono utilizzate le seguenti impostazioni predefinite:

  • Pulizia della cache automatica abilitata con durata (TTL, Time to Live) di 5 minuti

  • Nessuna preferenza per le zone di disponibilità

  • Nessuna preferenza per le finestre di manutenzione

  • Notifiche disabilitate

Per i nuovi cluster, puoi personalizzare le impostazioni al momento della creazione. Per eseguire questa operazione in AWS Management Console, deseleziona Use default settings (Usa impostazioni predefinite) per modificare le impostazioni seguenti:

  • Rete e sicurezza: consente di eseguire singoli nodi del cluster DAX in diverse zone di disponibilità all'interno della regione corrente AWS . Se scegli No Preference (Nessuna preferenza), i nodi vengono distribuiti automaticamente tra le zone di disponibilità.

  • Gruppo di parametri: un set denominato di parametri che vengono applicati a ogni nodo nel cluster. Puoi utilizzare un gruppo di parametri per specificare il comportamento TTL della cache. Puoi modificare il valore di un determinato parametro all'interno di un gruppo di parametri (ad eccezione del gruppo di parametri predefinito default.dax.1.0) in qualsiasi momento.

  • Finestra di manutenzione: un periodo di tempo settimanale durante il quale vengono applicati aggiornamenti software e patch ai nodi del cluster. Puoi scegliere il giorno di inizio, l'ora di inizio e la durata della finestra di manutenzione. Se scegli No Preference (Nessuna preferenza), la finestra di manutenzione viene selezionata a caso da un blocco di tempo di 8 ore per regione. Per ulteriori informazioni, consulta Maintenance window (Finestra di manutenzione).

Nota

Il gruppo di parametri e la finestra di manutenzione possono essere modificati in qualsiasi momento in un cluster in esecuzione.

Quando si verifica un evento di manutenzione, DAX può inviare una notifica tramite Amazon Simple Notification Service (Amazon SNS). Per configurare le notifiche, scegli un'opzione dal selezionatore Argomento per notifica SNS. Puoi creare un nuovo argomento Amazon SNS o usarne uno esistente.

Per informazioni sulla configurazione e la sottoscrizione di un argomento Amazon SNS, consulta Nozioni di base su Amazon SNS nella Guida per gli sviluppatori di Amazon Simple Notification Service.

Configurazione delle impostazioni TTL

DAX gestisce due cache per i dati che legge da DynamoDB:

  • Cache di elementi: per gli elementi recuperati tramite GetItem o BatchGetItem.

  • Cache di query: per i set di risultati recuperati tramite Query o Scan.

Per ulteriori informazioni, consulta Cache degli elementi e Cache delle query.

Il TTL predefinito per ciascuna di queste cache è di 5 minuti. Se si desidera utilizzare diverse impostazioni TTL, è possibile avviare un cluster DAX usando un gruppo di parametri personalizzato. Per eseguire questa operazione nella console, scegli DAX | Parameter groups (Gruppi di parametri) nel pannello di navigazione.

Puoi eseguire queste attività anche utilizzando l' AWS CLI. L'esempio seguente mostra come avviare un nuovo cluster DAX utilizzando un gruppo di parametri personalizzato. In questo esempio, il TTL della cache degli elementi è impostato su 10 minuti e il TTL della cache delle query è impostato su 3 minuti.

  1. Crea un nuovo set di parametri.

    aws dax create-parameter-group \ --parameter-group-name custom-ttl
  2. Imposta il TTL della cache degli elementi su 10 minuti (600000 millisecondi).

    aws dax update-parameter-group \ --parameter-group-name custom-ttl \ --parameter-name-values "ParameterName=record-ttl-millis,ParameterValue=600000"
  3. Imposta il TTL della cache delle query su 3 minuti (180000 millisecondi).

    aws dax update-parameter-group \ --parameter-group-name custom-ttl \ --parameter-name-values "ParameterName=query-ttl-millis,ParameterValue=180000"
  4. Verifica che il parametri siano impostati correttamente.

    aws dax describe-parameters --parameter-group-name custom-ttl \ --query "Parameters[*].[ParameterName,Description,ParameterValue]"

A questi punto è possibile avviare un nuovo cluster DAX con questo gruppo di parametri.

aws dax create-cluster \ --cluster-name MyNewCluster \ --node-type dax.r3.large \ --replication-factor 3 \ --iam-role-arn arn:aws:iam::123456789012:role/DAXServiceRole \ --parameter-group custom-ttl
Nota

Non è possibile modificare un gruppo di parametri che viene utilizzato da un'istanza DAX in esecuzione.

Supporto per l'assegnazione di tag per DAX

Molti AWS servizi, incluso DynamoDB, supportano il tagging, la capacità di etichettare le risorse con nomi definiti dall'utente. È possibile assegnare tag ai cluster DAX, in modo da identificare rapidamente tutte le AWS risorse che hanno lo stesso tag, o per classificare le fatture in base ai tag assegnati. AWS

Per ulteriori informazioni, consulta Aggiunta di tag ed etichette alle risorse.

Utilizzando il AWS Management Console

Come gestire i tag del cluster DAX
  1. Apri la console DynamoDB all'indirizzo https://console.aws.amazon.com/dynamodb/.

  2. Nel riquadro di navigazione, in DAX, scegli Clusters (Cluster).

  3. Scegli il cluster che desideri utilizzare.

  4. Seleziona la scheda Tags (Tag). In questa scheda puoi aggiungere, elencare, modificare o eliminare i tag.

    Dopo aver selezionato le impostazioni desiderate, scegli Applica modifiche.

Utilizzando il AWS CLI

Quando utilizzi AWS CLI per gestire i tag del cluster DAX, devi prima determinare l'Amazon Resource Name (ARN) per il cluster. L'esempio seguente mostra come determinare l'ARN per un cluster denominato MyDAXCluster.

aws dax describe-clusters \ --cluster-name MyDAXCluster \ --query "Clusters[*].ClusterArn"

Nell'output, l'aspetto dell'ARN sarà simile al seguente: arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster

L'esempio seguente mostra come aggiungere i tag al cluster.

aws dax tag-resource \ --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster \ --tags="Key=ClusterUsage,Value=prod"

Elenca tutti i tag per un cluster.

aws dax list-tags \ --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster

Per rimuovere un tag, specifica la chiave.

aws dax untag-resource \ --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster \ --tag-keys ClusterUsage

AWS CloudTrail integrazione

DAX è integrato con AWS CloudTrail e consente di controllare le attività del cluster DAX. È possibile utilizzare CloudTrail i log per visualizzare tutte le modifiche apportate a livello di cluster. Puoi anche visualizzare le modifiche ai componenti del cluster come nodi, gruppi di sottoreti e gruppi di parametri. Per ulteriori informazioni, consulta Registrazione delle operazioni di DynamoDB con AWS CloudTrail.

Eliminazione di un cluster DAX

Se non si utilizza più un cluster DAX, sarà necessario eliminarlo per evitare di ricevere addebiti per le risorse inutilizzate.

È possibile eliminare un cluster DAX utilizzando la console o la AWS CLI. Di seguito è riportato un esempio.

aws dax delete-cluster --cluster-name mydaxcluster