Considerazioni sull’utilizzo dei cluster con provisioning Amazon Redshift - Amazon Redshift
Considerazioni su regioni e zone di disponibilitàManutenzione del cluster

Amazon Redshift non supporterà più la creazione di nuove UDF Python a partire dal 1º novembre 2025. Se desideri utilizzare le UDF Python, creale prima di tale data. Le UDF Python esistenti continueranno a funzionare normalmente. Per ulteriori informazioni, consulta il post del blog.

Considerazioni sull’utilizzo dei cluster con provisioning Amazon Redshift

Dopo avere creato il cluster, in questa sezione puoi trovare informazioni sulle Regioni in cui sono disponibili funzionalità, attività di manutenzione, tipi di nodi e limiti di utilizzo.

Considerazioni su regioni e zone di disponibilità

Amazon Redshift è disponibile in diverse regioni AWS. Per impostazione predefinita, Amazon Redshift effettua il provisioning del cluster in una zona di disponibilità (AZ) selezionata casualmente all'interno della regione AWS scelta. Viene effettuato il provisioning di tutti i nodi del cluster nella stessa zona di disponibilità.

Facoltativamente, è possibile richiedere una zona di disponibilità specifica se Amazon Redshift è disponibile in tale zona. Ad esempio, se si dispone già di un'istanza Amazon EC2 in esecuzione in una zona di disponibilità, potrebbe essere necessario creare il proprio cluster Amazon Redshift nella stessa zona per ridurre la latenza. D'altra parte, potrebbe essere necessario scegliere un'altra zona di disponibilità con una maggiore disponibilità. Amazon Redshift potrebbe non essere disponibile in tutte le zone di disponibilità all'interno di una regione AWS.

Per un elenco di regioni AWS in cui è possibile eseguire il provisioning di un cluster Amazon Redshift, consulta Endpoint Amazon Redshift nei Riferimenti generali di Amazon Web Services.

Manutenzione del cluster

Amazon Redshift esegue periodicamente la manutenzione per applicare aggiornamenti al cluster. Durante questi aggiornamenti, il cluster Amazon Redshift non è disponibile per le operazioni normali. Esistono diversi modi per controllare come poter effettuare la manutenzione del cluster. Ad esempio, puoi controllare come distribuire gli aggiornamenti sui cluster. Puoi anche scegliere se il cluster esegue sempre la versione di rilascio più recente o quella precedente alla più recente. Infine, puoi anche decidere di posticipare gli aggiornamenti di manutenzione non obbligatori.

Finestre di manutenzione

Amazon Redshift assegna casualmente una finestra di manutenzione di 30 minuti da un blocco di tempo di 8 ore per regione AWS, che si verifica in un giorno casuale della settimana (da lunedì a sabato inclusi).

Finestre di manutenzione predefinite

Il seguente elenco elenca i blocchi temporali per ciascuna regione AWS da cui sono assegnate le finestre di manutenzione predefinite:

  • Regione Stati Uniti orientali (Virginia settentrionale): 03:00-11:00 UTC

  • Regione Stati Uniti orientali (Ohio): 03:00 - 11:00 UTC

  • Regione Stati Uniti occidentali (California settentrionale): 06:00-14:00 UTC

  • Regione Stati Uniti occidentali (Oregon): 06:00 - 14:00 UTC

  • Regione Africa (Città del Capo): 20:00 - 04:00 UTC

  • Regione Asia Pacifico (Hong Kong): 13:00 - 21:00 UTC

  • Regione Asia Pacifico (Hyderabad): 16:30-00:30 UTC

  • Regione Asia Pacifico (Jakarta): 15:00 – 23:00 UTC

  • Regione Asia Pacifico (Malesia): 14:00 - 22:00 UTC

  • Regione Asia Pacifico (Melbourne): 12:00 - 20:00 UTC

  • Regione Asia Pacifico (Mumbai): 16:30 - 00:30 UTC

  • Regione Asia Pacifico (Nuova Zelanda): 10:00 - 18:00 UTC

  • Regione Asia Pacifico (Tokyo): 13:00 – 21:00 UTC

  • Regione Asia Pacifico (Seoul): 13:00 – 21:00 UTC

  • Regione Asia Pacifico (Singapore): 14:00-22:00 UTC

  • Regione Asia Pacifico (Sydney): 12:00 - 20:00 UTC

  • Regione Asia Pacifico (Taipei): 14:00 - 22:00 UTC

  • Regione Asia Pacifico (Thailandia): 15:00 - 23:00 UTC

  • Regione Asia Pacifico (Tokyo): 13:00-21:00 UTC

  • Regione Canada (Centrale): 03:00 - 11:00 UTC

  • Regione Canada occidentale (Calgary): 04:00 - 12:00 UTC

  • Regione Cina (Pechino): 13:00 - 21:00 UTC

  • Regione Cina (Ningxia): 13:00 - 21:00 UTC

  • Regione Europa (Francoforte): 06:00 - 14:00 UTC

  • Regione Europa (Irlanda): 22:00-06:00 UTC

  • Regione Europa (Londra): 22:00 - 06:00 UTC

  • Regione Europa (Milano): 21:00 - 05:00 UTC

  • Regione Europa (Parigi): 23:00 - 07:00 UTC

  • Regione Europa (Stoccolma): 23:00 - 07:00 UTC

  • Regione Europa (Zurigo): 22:00-04:00 UTC

  • Regione di Israele (Tel Aviv): 20:00 — 04:00 UTC

  • Regione Messico (Centrale): 04:00 - 12:00 UTC

  • Regione Europa (Spagna): 21:00-05:00 UTC

  • Regione Medio Oriente (Bahrein): 13:00 - 21:00 UTC

  • Regione Medio Oriente (EAU): 18:00–02:00 UTC

  • Regione Sud America (San Paolo): 19:00 - 03:00 UTC

Se in una determinata settimana è pianificato un evento di manutenzione, tale evento viene avviato durante la finestra di manutenzione di 30 minuti assegnata. Mentre Amazon Redshift esegue la manutenzione, verranno terminate le query e tutte le altre operazioni in corso. La maggior parte del processo di manutenzione viene completato durante la finestra di manutenzione di 30 minuti, ma l'esecuzione di alcune attività di manutenzione potrebbe continuare anche dopo la chiusura della finestra. Se non sono previste attività di manutenzione da eseguire durante una finestra di manutenzione pianificata, il cluster continuerà a funzionare normalmente fino alla successiva finestra di manutenzione pianificata.

È possibile cambiare la finestra di manutenzione programmata modificando il cluster a livello di codice o utilizzando la console Amazon Redshift. Puoi trovare la finestra di manutenzione e impostare il giorno e l’ora in cui si verifica per il cluster nella scheda Manutenzione.

È possibile riavviare un cluster al di fuori di una finestra di manutenzione. Questo può avvenire per alcuni motivi. Un motivo più comune è che è stato rilevato un problema nel cluster e sono in corso operazioni di manutenzione per riportarlo a uno stato integro. Per ulteriori informazioni consulta l'articolo Why did my Amazon Redshift cluster reboot outside of the maintenance window?, che fornisce dettagli sul motivo per cui ciò potrebbe verificarsi.

Posticipazione della manutenzione

Per pianificare nuovamente la finestra di manutenzione del cluster, puoi posticipare la manutenzione fino a un massimo 45 giorni. Ad esempio, se la finestra di manutenzione del cluster è impostata a mercoledì 8:30 - 9:00 UTC ed è necessario accedere al cluster in quel periodo, puoi posticipare la manutenzione impostandola a un periodo successivo.

Se rinvii la manutenzione, Amazon Redshift continuerà ad applicare aggiornamenti hardware o altri aggiornamenti di sicurezza obbligatori al cluster. Durante questi aggiornamenti il cluster non è disponibile.

Se durante la prossima finestra di manutenzione è pianificato un aggiornamento hardware o un altro aggiornamento di sicurezza obbligatorio, Amazon Redshift ti invia notifiche anticipate nella categoria In sospeso. Per ulteriori informazioni sulle notifiche di eventi In sospeso, consulta Notifiche di eventi del cluster con provisioning Amazon Redshift.

Puoi anche scegliere di ricevere notifiche tramite SMS da Amazon Simple Notification Service (Amazon SNS). Per ulteriori informazioni sulla sottoscrizione alle notifiche eventi di Amazon SNS, consulta Abbonamenti alle notifiche di eventi del cluster Amazon Redshift.

Se posticipi la manutenzione del cluster, la finestra di manutenzione successiva al periodo di posticipazione non può essere posticipata.

Nota

Non è possibile posticipare la manutenzione dopo che è iniziata.

Per ulteriori informazioni sulla manutenzione dei cluster, consulta la documentazione seguente:

Selezione delle tracce di manutenzione del cluster

Quando è disponibile una nuova versione del cluster Amazon Redshift, il cluster viene aggiornato durante la relativa finestra di manutenzione. Puoi controllare se il cluster è aggiornato alla versione più recente o alla versione precedente.

La traccia controlla quale versione del cluster viene applicata durante una finestra di manutenzione. Quando Amazon Redshift rilascia una nuova versione del cluster, quella versione viene assegnata alla traccia corrente e la versione precedente viene assegnata alla traccia finale.

Per ulteriori informazioni sulle tracce del cluster, consulta Tracce per cluster con provisioning e gruppi di lavoro serverless Amazon Redshift.

Informazioni su come i nodi RA3 separano il calcolo e l’archiviazione

In queste sezioni vengono descritte nei dettagli le attività disponibili per i tipi di nodi RA3, mostrandone l’applicabilità a una raccolta di casi d’uso e illustrandone specificamente i vantaggi rispetto ai tipi di nodi precedentemente disponibili.

Vantaggi e disponibilità dei nodi RA3

I nodi RA3 offrono i seguenti vantaggi:

  • Sono flessibili per aumentare la capacità di elaborazione senza aumentare i costi di storage. Ridimensionano lo storage senza un eccessivo provisioning della capacità di elaborazione.

  • Utilizzano SSD ad alte prestazioni per i dati hot e Amazon S3 per i dati cold. Pertanto offrono facilità d'uso, storage conveniente ed elevate prestazioni di query.

  • Utilizzano reti a larghezza di banda elevata basate sul sistema AWS Nitro per ridurre ulteriormente il tempo richiesto per scaricare i dati e recuperarli da Amazon S3.

Valuta l'opportunità di scegliere i tipi di nodo RA3 nei casi seguenti:

  • Hai bisogno di flessibilità per scalare e pagare il calcolo separatamente dallo storage.

  • Esegui query su una frazione dei dati totali.

  • Il volume di dati cresce rapidamente o prevedi cresca rapidamente.

  • Desideri la flessibilità per dimensionare il cluster solo in base alle esigenze di prestazioni.

Per utilizzare i tipi di nodo RA3, la regione AWS deve supportare RA3. Per ulteriori informazioni, consultare Disponibilità dei tipi di nodo RA3 nelle regioni AWS.

Importante

È possibile utilizzare i tipi di nodo ra3.xlplus solo con la versione del cluster 1.0.21262 o successiva. È possibile visualizzare la versione di un cluster esistente con la console Amazon Redshift. Per ulteriori informazioni, consulta Determinazione della versione del gruppo di lavoro o del cluster.

Assicurarsi di utilizzare la nuova console Amazon Redshift quando lavori con i tipi di nodo RA3.

Inoltre, per utilizzare i tipi di nodo RA3 con le operazioni Amazon Redshift che utilizzano la traccia, il valore della traccia di manutenzione deve essere impostato su una versione del cluster che supporti RA3. Per ulteriori informazioni sulle tracce, consulta Selezione delle tracce di manutenzione del cluster.

Considerare quanto segue quando si utilizzano tipi di nodi RA3 a nodo singolo.

  • I produttori e i consumatori di datasharing sono supportati.

  • Per modificare i tipi di nodi, è supportato solo il ridimensionamento classico. La modifica del tipo di nodo con il ridimensionamento elastico o il ripristino dello snapshot non è supportata. Sono supportati gli scenari seguenti:

    • Ridimensionamento classico di un dc2.xlarge a 1 nodo a un ra3.xlplus a 1 nodo e viceversa.

    • Ridimensionamento classico di un dc2.xlarge a 1 nodo su un ra3.xlplus a nodo multiplo e viceversa.

    • Ridimensionamento classico di un dc2.xlarge a più nodi ra3.xlplus a 1 nodo e viceversa.

Utilizzo dello spazio di archiviazione gestito di Amazon Redshift

Con l'archiviazione gestita di Amazon Redshift, è possibile archiviare ed elaborare tutti i dati in Amazon Redshift ottenendo una maggiore flessibilità per scalare separatamente la capacità di calcolo e quella di archiviazione. I dati continuano a essere inseriti con il comando COPY o INSERT. Per ottimizzare le prestazioni e gestire il posizionamento dei dati automatico nei vari livelli di storage, Amazon Redshift si avvale di ottimizzazioni quali temperatura di blocco dei dati, età di blocco dei dati e modelli di carichi di lavoro. Quando necessario, Amazon Redshift dimensiona automaticamente l'archiviazione in Amazon S3 senza richiedere alcuna azione manuale.

Per ulteriori informazioni sui costi di archiviazione, consultare Prezzi di Amazon Redshift.

Gestione dei tipi di nodo RA3

Per sfruttare la separazione del calcolo dallo storage, puoi creare o aggiornare il cluster con il tipo di nodo RA3. Per utilizzare i tipi di nodo RA3, è necessario creare i cluster in un virtual private cloud (EC2-VPC).

Per modificare il numero di nodi del cluster Amazon Redshift con un tipo di nodo RA3, effettuare una delle operazioni seguenti:

  • Aggiungere o rimuovere nodi con l'operazione di ridimensionamento elastico. In alcune situazioni, la rimozione di nodi da un cluster RA3 non è consentita con il ridimensionamento elastico. Ad esempio, quando un aggiornamento del numero di nodi 2:1 imposta il numero di sezioni per nodo su 32. Per ulteriori informazioni, consulta Ridimensionamento di un cluster. Se il ridimensionamento elastico non è disponibile, utilizzare il ridimensionamento classico.

  • Aggiungere o rimuovere nodi con l'operazione di ridimensionamento classico. Scegliere questa opzione quando si sta ridimensionando una configurazione che non è disponibile tramite il ridimensionamento elastico. Il ridimensionamento elastico è più veloce del ridimensionamento classico. Per ulteriori informazioni, consulta Ridimensionamento di un cluster.

Disponibilità dei tipi di nodo RA3 nelle regioni AWS

I tipi di nodo RA3 sono disponibili solo nelle seguenti regioni AWS:

  • Regione Stati Uniti orientali (Virginia settentrionale) (us-east-1)

  • Regione Stati Uniti orientali (Ohio) (us-east-2)

  • Regione Stati Uniti occidentali (California settentrionale) (us-west-1)

  • Regione Stati Uniti occidentali (Oregon) (us-west-2)

  • Regione Africa (Città del Capo) (af-south-1)

  • Regione Asia Pacifico (Hong Kong) (ap-east-1)

  • Regione Asia Pacifico (Hyderabad) (ap-south-2)

  • Regione Asia Pacifico (Jakarta) (ap-southeast-3)

  • Regione Asia Pacifico (Malesia) (ap-southeast-5)

  • Regione Asia Pacifico (Melbourne) (ap-southeast-4)

  • Regione Asia Pacifico (Mumbai) (ap-south-1)

  • Regione Asia Pacifico (Nuova Zelanda) (ap-southeast-6)

  • Regione Asia Pacifico (Osaka) (ap-northeast-3)

  • Regione Asia Pacifico (Seoul) (ap-northeast-2)

  • Regione Asia Pacifico (Singapore) (ap-southeast-1)

  • Regione Asia Pacifico (Sydney) (ap-southeast-2)

  • Regione Asia Pacifico (Taipei) (ap-east-2)

  • Regione Asia Pacifico (Thailandia) (ap-southeast-7)

  • Regione Asia Pacifico (Tokyo) (ap-northeast-1)

  • Regione Canada (Centrale) (ca-central-1)

  • Regione Canada occidentale (Calgary) (ca-west-1)

  • Regione Cina (Pechino) (cn-north-1)

  • Regione Cina (Ningxia) (cn-northwest-1)

  • Regione Europa (Francoforte) (eu-central-1)

  • Regione Europa (Zurigo) (eu-central-2)

  • Regione Europa (Irlanda) (eu-west-1)

  • Regione Europa (Londra) (eu-west-2)

  • Regione Europa (Milano) (eu-south-1)

  • Regione Europa (Spagna) (eu-south-2)

  • Regione Europa (Parigi) (eu-west-3)

  • Regione Europa (Stoccolma) (eu-north-1)

  • Regione di Israele (Tel Aviv) (il-central-1)

  • Regione Messico (Centrale) (mx-central-1)

  • Regione Medio Oriente (Bahrein) (me-south-1)

  • Regione Medio Oriente (EAU) (me-central-1)

  • Regione Sud America (San Paolo) (sa-east-1)

  • AWS GovCloud (Stati Uniti-Est) (us-gov-east-1)

  • AWS GovCloud (Stati Uniti-Ovest) (us-gov-west-1)

Aggiornamento ai tipi di nodo RA3

Per aggiornare il tipo di nodo esistente a RA3, sono disponibili le seguenti opzioni per modificare il tipo di nodo:

  • Ripristino da uno snapshot: Amazon Redshift utilizza lo snapshot più recente del cluster e lo ripristina per creare un nuovo cluster RA3. Al termine della creazione del cluster (in genere entro pochi minuti), i nodi RA3 sono pronti per eseguire il carico di lavoro di produzione completo. Poiché il calcolo è separato dallo storage, i dati hot vengono trasferiti nella cache locale a velocità elevate grazie all'ampia larghezza di banda di rete. Se esegui il ripristino dallo snapshot DC2 più recente, RA3 conserva le informazioni del blocco hot del carico di lavoro DC2 e popola la cache locale con i blocchi più hot. Per ulteriori informazioni, consulta Ripristino di un cluster da uno snapshot.

    Per mantenere lo stesso endpoint per le applicazioni e gli utenti, puoi rinominare il nuovo cluster RA3 con lo stesso nome del cluster DC2 originale. Per rinominare il cluster, modificare il cluster nella console Amazon Redshift o con l'operazione API ModifyCluster. Per ulteriori informazioni, consultare Ridenominazione di un cluster o Operazione API ModifyCluster nella Guida di riferimento dell'API di Amazon Redshift.

  • Ridimensionamento elastico: ridimensiona il cluster utilizzando il ridimensionamento elastico. Quando si utilizza il ridimensionamento elastico per modificare il tipo di nodo, Amazon Redshift crea automaticamente uno snapshot, crea un nuovo cluster, elimina il cluster precedente e rinomina il nuovo cluster. L'operazione di ridimensionamento elastico può essere eseguita on demand o pianificata per l'esecuzione in un secondo momento. Puoi aggiornare rapidamente i cluster del tipo di nodo DC2 esistenti a RA3 con ridimensionamento elastico. Per ulteriori informazioni, consulta Elastic resize (Ridimensionamento elastico).

Nella tabella seguente vengono illustrati i suggerimenti durante l'aggiornamento a tipi di nodo RA3. (Queste raccomandazioni si applicano anche ai nodi riservati.)

I suggerimenti in questa tabella riguardano i tipi e le dimensioni iniziali dei nodi del cluster, ma dipendono dai requisiti di calcolo del carico di lavoro. Per valutare meglio i requisiti, prendi in considerazione la possibilità di condurre un proof of concept (POC) che utilizzi Test Drive per eseguire potenziali configurazioni. Esegui il provisioning di un cluster per il data warehouse POC anziché Redshift serverless. Per ulteriori informazioni sull’esecuzione di un proof of concept, consulta Eseguire un proof of concept (POC) per Amazon Redshift nella Guida per sviluppatori di database di Amazon Redshift.

Tipo di nodo esistente Numero di nodi esistenti Nuovo tipo di nodo consigliato Operazione di aggiornamento

dc2.8xlarge

2-15

ra3.4xlarge

Inizia con 2 nodi di ra3.4xlarge per ogni nodo di dc2.8xlarge1.

dc2.8xlarge

16-128

ra3.16xlarge

Inizia con 1 nodo di ra3.16xlarge per ogni 2 nodi di dc2.8xlarge1.

dc2.large

1-4

ra3.large

Inizia con 1 nodo di ra3.large per ogni nodo di dc2.large1.

Inizia con 2 nodi di ra3.large per ogni 2 nodi di dc2.large1.

Inizia con 3 nodi di ra3.large per ogni 3 nodi di dc2.large1.

Inizia con 3 nodi di ra3.large per ogni 4 nodi di dc2.large1.

dc2.large

5–15

ra3.xlplus

Inizia con 3 nodi di ra3.xplus per ogni 8 nodi di dc2.large1.

dc2.large

16-32

ra3.4xlarge

Inizia con 1 nodo di ra3.4xlarge per ogni 8 nodi di dc2.large1,2.

1Nodi aggiuntivi potrebbero essere necessari a seconda dei requisiti del carico di lavoro. Aggiungere o rimuovere nodi in base ai requisiti di calcolo delle prestazioni delle query richieste.

2I cluster con il tipo di nodo dc2.large sono limitati a 32 nodi.

Il numero minimo di nodi per alcuni tipi di nodo RA3 è due. Tenere presente questo aspetto quando si crea un cluster RA3.

Funzionalità di rete supportate dai nodi RA3

I nodi RA3 supportano una serie di funzionalità di rete non disponibili per altri tipi di nodi. Questa sezione fornisce brevi descrizioni di ciascuna funzionalità e i link a documentazione aggiuntiva:

  • Endpoint VPC di cluster con provisioning: quando crei o ripristini un cluster RA3, Amazon Redshift utilizza una porta compresa negli intervalli 5431-5455 o 8191-8215. Quando il cluster è impostato su una porta in uno di questi intervalli, Amazon Redshift crea automaticamente un endpoint VPC nell’account AWS per il cluster e a esso collega un indirizzo IP privato. Se imposti il cluster come accessibile al pubblico, Redshift crea un indirizzo IP elastico nell’account AWS e lo collega all’endpoint VPC. Per ulteriori informazioni, consulta Configurazione delle impostazioni di comunicazione dei gruppi di sicurezza per un cluster Amazon Redshift o gruppo di lavoro Amazon Redshift serverless.

  • Cluster RA3 a sottorete singola: è possibile creare un cluster RA3 con una singola sottorete, ma non può utilizzare funzionalità di ripristino di emergenza. Si verifica un’eccezione se abiliti la rilocazione del cluster quando la sottorete non dispone di più zone di disponibilità (AZ).

  • Cluster RA3 con più sottoreti e gruppi di sottoreti: puoi creare un cluster RA3 con più sottoreti creando un gruppo di sottoreti quando esegui il provisioning del cluster nel cloud privato virtuale (VPC). Un gruppo di sottoreti del cluster consente di specificare un set di sottoreti nel VPC e Amazon Redshift crea il cluster in una di esse. Dopo avere creato un gruppo di sottoreti, puoi rimuovere le sottoreti aggiunte in precedenza o aggiungerne altre. Per ulteriori informazioni, consulta Gruppi di sottoreti del cluster Amazon Redshift.

  • Accesso agli endpoint su più account o più VPC: puoi accedere a un cluster con provisioning o un gruppo di lavoro Amazon Redshift serverless configurando un endpoint VPC gestito da Redshift. Ad esempio, puoi configurarlo come connessione privata tra un VPC che contiene un cluster o un gruppo di lavoro e un VPC in cui esegui uno strumento client. Con questo approccio puoi accedere al data warehouse senza utilizzare un indirizzo IP pubblico o senza instradare il traffico su Internet. Per ulteriori informazioni, consulta Utilizzo degli endpoint VPC gestiti da Redshift.

  • Rilocazione del cluster: puoi spostare un cluster in un’altra zona di disponibilità (AZ) senza alcuna perdita di dati in caso di interruzione del servizio. Per attivarlo  nella console Per ulteriori informazioni, consulta Rilocazione di un cluster.

  • Nome di dominio personalizzato: puoi creare un nome di dominio personalizzato, noto anche come URL personalizzato, per il cluster Amazon Redshift. È un record DNS di facile lettura che indirizza le connessioni client SQL all'endpoint del cluster. Per ulteriori informazioni, consulta Nomi di dominio personalizzati per le connessioni client.