View a markdown version of this page

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ù l'uso delle UDF Python dopo il 30 giugno 2026. Inizieremo ad applicarlo per fasi. Per ulteriori informazioni sulla fine del ciclo di vita e sulle opzioni di migrazione di Python, consulta il post del blog pubblicato il 30 giugno 2025.

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

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 AWS regioni. Per impostazione predefinita, Amazon Redshift esegue il provisioning del cluster in una zona di disponibilità (AZ) selezionata casualmente all'interno della AWS regione 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 delle AWS regioni supportate in cui è possibile effettuare il provisioning di un cluster Amazon Redshift, consulta gli endpoint di Amazon Redshift nel. 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 una finestra di manutenzione di 30 minuti a caso su un blocco di 8 ore per AWS regione, in un giorno della settimana casuale (dal lunedì alla domenica inclusi).

Finestre di manutenzione predefinite

L'elenco seguente mostra i blocchi temporali per ciascuna AWS regione a partire dai quali vengono 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. I tempi di inattività verificatisi durante la manutenzione pianificata non sono considerati tempi di inattività o indisponibilità mensili nell'accordo sul livello di servizio di Amazon Redshift. 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 riprogrammare la finestra di manutenzione del cluster, puoi posticipare la manutenzione fino a 60 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.

Comprendere in che modo i nodi RG e RA3 separano elaborazione e storage

Queste sezioni descrivono in dettaglio le attività disponibili per i tipi di nodi RG e RA3, mostrandone l'applicabilità a una raccolta di casi d'uso e descrivendone i vantaggi rispetto ai tipi di nodi precedentemente disponibili.

Vantaggi e disponibilità dei nodi RG e RA3

I nodi RG e 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 una rete a larghezza di banda elevata basata sul sistema AWS Nitro per ridurre ulteriormente il tempo impiegato per lo scaricamento e il recupero dei dati da Amazon S3.

Valuta la possibilità di scegliere i tipi di nodi RG e RA3 in questi casi:

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

Considerazioni sull'elaborazione delle query sui data lake: sui cluster con provisioning DC2 e RA3, le query sui data lake vengono eseguite su Redshift Spectrum, che utilizza server Amazon Redshift dedicati indipendenti dal cluster. Nei cluster con provisioning RG, le query sui data lake vengono eseguite sulle risorse di elaborazione proprie del cluster e condividono tali risorse con altri carichi di lavoro. Per i carichi di lavoro con un utilizzo intensivo di query sui data lake, tieni in considerazione questo aspetto quando ridimensioni il tuo cluster RG.

Per utilizzare i tipi di nodi RG, la tua AWS regione deve supportare RG. Per ulteriori informazioni, consulta Disponibilità del tipo di nodo RG in AWS Regioni.

Per utilizzare i tipi di nodo RA3, la tua AWS regione deve supportare RA3. Per ulteriori informazioni, consulta Disponibilità del tipo di nodo RA3 in AWS Regioni.

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.

Assicurati di utilizzare la nuova console Amazon Redshift quando lavori con tipi di nodi RG o RA3.

Inoltre, per utilizzare i tipi di nodi RG o RA3 con le operazioni di Amazon Redshift che utilizzano la traccia, il valore della traccia di manutenzione deve essere impostato su una versione del cluster che supporti RG o 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 nodi RG o RA3

Per trarre vantaggio dalla separazione dell'elaborazione dallo storage, puoi creare o aggiornare il cluster con il tipo di nodo RG o RA3. Per utilizzare i tipi di nodo RG o RA3, crea i tuoi cluster in un cloud privato virtuale (). EC2-VPC

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

  • Aggiungere o rimuovere nodi con l'operazione di ridimensionamento elastico. In alcune situazioni, la rimozione di nodi da un cluster RG o 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à del tipo di nodo RG in AWS Regioni

I tipi di nodo RG 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 (Taipei) (ap-east-2)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Regione Europa (Milano) (eu-south-1) (solo rg.xlarge e rg.4xlarge)

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

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

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

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

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

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

  • AWS GovCloud US-East() (us-gov-east-1)

  • AWS GovCloud (US-West) (usa-gov-west-1)

Disponibilità del tipo di nodo RA3 in AWS Regioni

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 (US-East) (us-gov-east-1)

  • AWS GovCloud (US-West) (usa-gov-west-1)

Aggiornamento ai tipi di nodo RG o RA3

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

  • Ripristino da un'istantanea: Amazon Redshift utilizza l'istantanea più recente del cluster e la ripristina per creare un nuovo cluster RG o RA3. Non appena la creazione del cluster è completa (di solito entro pochi minuti), i nodi RG o RA3 sono pronti per eseguire l'intero carico di lavoro di produzione. 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 dall'ultima istantanea DC2, RG e RA3 conservano le informazioni sugli hot block del carico di lavoro DC2 e popolano la cache locale con i blocchi più caldi. Per ulteriori informazioni, consulta Ripristino di un cluster da uno snapshot.

    Per mantenere lo stesso endpoint per applicazioni e utenti, puoi rinominare il nuovo cluster RG o 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 di tipo di nodo DC2 esistenti a RG o RA3 con elastic resize. Per ulteriori informazioni, consulta Elastic resize (Ridimensionamento elastico).

Nota

Per migrare i cluster RA3 esistenti su rg.xlarge o rg.4xlarge, il cluster di origine deve eseguire la versione della patch P201 o successiva. Per migrare a rg.large o rg.12xlarge, il cluster di origine deve eseguire P202 o versione successiva. I cluster DC2 possono migrare a RG indipendentemente dalla versione della patch.

La tabella seguente mostra i consigli per l'aggiornamento ai tipi di nodi RG. (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

ra3.16xlarge

2-128

rg.12xlarge

Inizia con 1 nodo di rg.12xlarge per ogni nodo di ra3.16xlarge 1.

ra3.4xlarge

2-64

gr. 4x grande

Inizia con 3 nodi di rg.4xlarge per ogni 4 nodi di ra3.4xlarge 1.

ra3.xlplus

2—32

rg.xlarge

Inizia con 1 nodo di rg.xlarge per ogni nodo di ra3.xlplus 1.

ra3.large

2—16

rg. grande

Inizia con 1 nodo di rg.large per ogni nodo di ra3.large 1.

dc2.8xlarge

2-15

rg.4xlarge

Inizia con 3 nodi di rg.4xlarge per ogni 2 nodi di dc2.8xlarge 1.

dc2.8xlarge

16-128

rg.12xlarge

Inizia con 1 nodo di rg.12xlarge per ogni 2 nodi di dc2.8xlarge 1.

dc2.large

1—3

rg. grande

Inizia con 1 nodo di rg.large per ogni nodo di dc2.large 1.

dc2.large

4

rg.large

Inizia con 3 nodi di rg.large 1.

dc2.large

5–15

rg.xlarge

Inizia con 3 nodi di rg.xlarge ogni 8 nodi di dc2.large 1.

dc2.large

16-32

rg.4xlarge

Inizia con 1 nodo di rg.4xlarge ogni 10 nodi di dc2.large 1.

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.

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.

2 I 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 RG e RA3

I nodi RG e RA3 supportano una raccolta 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:

  • Provisioned-cluster Endpoint VPC: quando si crea o si ripristina un cluster RG o RA3, Amazon Redshift utilizza una porta compresa tra 5431-5455 o 8191-8215. Quando il cluster è impostato su una porta in uno di questi intervalli, Amazon Redshift crea automaticamente un endpoint VPC nel tuo account per il cluster e gli associa un indirizzo IP privato. AWS 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.

  • Single-subnet Cluster RG o RA3: puoi creare un cluster RG o RA3 con una singola sottorete, ma non puoi utilizzare le funzionalità di disaster recovery. Si verifica un’eccezione se abiliti la rilocazione del cluster quando la sottorete non dispone di più zone di disponibilità (AZ).

  • Multi-subnet Cluster e gruppi di sottorete RG o RA3: puoi creare un cluster RG o RA3 con più sottoreti creando un gruppo di sottoreti quando esegui il provisioning del cluster nel tuo 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.

  • Cross-account o accesso a endpoint tra VPC: puoi accedere a un cluster predisposto o a un gruppo di lavoro Amazon Redshift Serverless configurando un endpoint VPC. Redshift-managed 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 Lavorare con gli endpoint VPC. Redshift-managed

  • 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 SQL-client connessioni all'endpoint del cluster. Per ulteriori informazioni, consulta Nomi di dominio personalizzati per le connessioni client.

Aspetti da considerare quando si esegue l'aggiornamento ai nodi RG

Versione della patch

Per migrare da RA3 a RG, il cluster di origine deve soddisfare la versione di patch minima richiesta: P201 per rg.xlarge e rg.4xlarge e P202 per rg.large e rg.12xlarge. I cluster DC2 possono migrare a RG indipendentemente dalla versione della patch. Prima della migrazione, testa i carichi di lavoro ripristinando un'istantanea su un cluster RG prima di spostare il traffico di produzione. Per informazioni dettagliate, consulta Patch Amazon Redshift 201 e Patch 202 di Amazon Redshift.

Carichi di lavoro Spectrum

I cluster con carichi di lavoro che utilizzano intensamente Spectrum possono osservare prestazioni delle query più lente dopo la migrazione a RG. A differenza di RA3 e DC2, RG esegue il motore di interrogazione del data lake integrato direttamente sui nodi di calcolo del cluster anziché su una flotta Spectrum separata. Se riscontri un calo delle prestazioni di Spectrum, aumenta il numero di nodi nel tuo cluster RG o esegui la migrazione a un tipo di nodo RG più grande.

I cluster RG supportano anche l'interrogazione dei dati in bucket Amazon S3 situati in una AWS regione diversa, eliminando la limitazione della stessa regione che si applica ai cluster RA3 e DC2 che utilizzano Spectrum. Cross-region le interrogazioni comportano costi aggiuntivi per il trasferimento dei dati. Per ulteriori informazioni, consulta Interrogare il data lake.

Cursor-based carichi di lavoro

I nodi RG hanno dimensioni del cursore supportate diverse rispetto a RA3 e DC2. Per i limiti di dimensione del cursore, fare riferimento a Cursor Constraints. Se il carico di lavoro dipende in larga misura dai cursori e riscontri dei limiti di dimensione del cursore, esegui la migrazione a un tipo di nodo RG più grande: puoi ridurre il numero di nodi in modo proporzionale per mantenere dimensioni e costi totali del cluster simili.

Idoneità alla scalabilità della concorrenza

Se il tuo cluster utilizza Concurrency Scaling e ha più di 32 nodi e desideri migrare a rg.12xlarge, usa elastic resize o snapshot restore per mantenere il supporto per il Concurrency Scaling. Se il cluster ha più di 32 nodi ed esegui un ridimensionamento classico a rg.12xlarge, il cluster perde il supporto per il Concurrency Scaling. I cluster rg.12xlarge appena creati con più di 32 nodi non supportano il Concurrency Scaling. Per ulteriori informazioni, consulta Concurrency Scaling Candidate. https://docs.aws.amazon.com/redshift/latest/dg/concurrency-scaling.html#concurrency-scaling-candidates