Considérations relatives à l’utilisation des clusters alloués Amazon Redshift - Amazon Redshift
Considérations sur les régions et les zones de disponibilitéMaintenance du cluster

Amazon Redshift ne prendra plus en charge la création de nouvelles fonctions Python définies par l’utilisateur à compter du 1er novembre 2025. Si vous souhaitez utiliser des fonctions Python définies par l’utilisateur, créez-les avant cette date. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement. Pour plus d’informations, consultez le billet de blog .

Considérations relatives à l’utilisation des clusters alloués Amazon Redshift

Une fois votre cluster créé, vous trouverez dans cette section des informations sur les régions où les fonctionnalités sont disponibles, les tâches de maintenance, les types de nœuds et les limites d’utilisation.

Considérations sur les régions et les zones de disponibilité

Amazon Redshift est disponible dans plusieurs régions AWS. Par défaut, Amazon Redshift alloue votre cluster dans une zone de disponibilité (AZ) sélectionnée de manière aléatoire dans la région AWS que vous avez choisie. Tous les nœuds de cluster sont alloués dans la même zone de disponibilité.

Vous pouvez éventuellement demander une zone de disponibilité spécifique si Amazon Redshift est disponible dans cette zone. Par exemple, si vous avez déjà une instance Amazon EC2 en exécution dans une zone de disponibilité, vous pouvez créer votre cluster Amazon Redshift dans la même zone pour réduire la latence. D’autre part, vous pouvez choisir une autre zone de disponibilité pour une plus grande disponibilité. Amazon Redshift peut ne pas être disponible dans toutes les zones de disponibilité d’une région AWS.

Pour obtenir la liste des régions AWS prises en charge dans lesquelles vous pouvez provisionner un cluster Amazon Redshift, consultez Points de terminaison Amazon Redshift dans Référence générale d'Amazon Web Services.

Maintenance du cluster

Amazon Redshift effectue régulièrement une maintenance pour appliquer les mises à niveau à votre cluster. Au cours de ces mises à jour, votre cluster Amazon Redshift n’est pas disponible pour les opérations normales. Il existe plusieurs manières de contrôler la gestion de votre cluster. Par exemple, vous pouvez contrôler le déploiement des mises à jour sur vos clusters. Vous pouvez également choisir si votre cluster est exécuté sur la version la plus récente ou sur la version publiée juste avant celle-ci. Enfin, vous avez également la possibilité de reporter les mises à jour de maintenance non obligatoires pendant une certaine période.

Fenêtres de maintenance

Amazon Redshift attribue une fenêtre de maintenance de 30 minutes de manière aléatoire à partir d’un bloc de 8 heures par région AWS, survenant un jour aléatoire de la semaine (du lundi au dimanche inclus).

Fenêtres de maintenance par défaut

La liste suivante répertorie les périodes de chaque région AWS au sein desquelles les fenêtres de maintenance par défaut sont attribuées :

  • Région USA Est (Virginie du Nord) : 03:00 – 11:00 UTC

  • Région USA Est (Ohio) : 03:00 – 11:00 UTC

  • Région USA Ouest (Californie du Nord) : 06:00 – 14:00 UTC

  • Région USA Ouest (Oregon) : 06:00 – 14:00 UTC

  • Région Afrique (Le Cap) : 20:00 – 04:00 UTC

  • Région Asie-Pacifique (Hong Kong) : 13:00 – 21:00 UTC

  • Région Asie-Pacifique (Hyderabad) : 16:30 – 00:30 UTC

  • Région Asie-Pacifique (Jakarta) : 15:00 – 23:00 UTC

  • Région Asie-Pacifique (Malaisie) : 14:00 – 22:00 UTC

  • Région Asie-Pacifique (Melbourne) : 12:00 – 20:00 UTC

  • Région Asie-Pacifique (Mumbai) : 16:30 – 03:00 UTC

  • Région Asie-Pacifique (Nouvelle Zélande) : 10:00 – 18:00 UTC

  • Région Asie-Pacifique (Osaka) : 13:00 – 21:00 UTC

  • Région Asie-Pacifique (Seoul) : 13:00 – 21:00 UTC

  • Région Asie-Pacifique (Singapour) : 14:00 – 22:00 UTC

  • Région Asie-Pacifique (Sydney) : 12:00 – 20:00 UTC

  • Région Asie-Pacifique (Taipei) : 14:00 – 22:00 UTC

  • Région Asie-Pacifique (Thaïlande) : 15:00 – 23:00 UTC

  • Région Asie-Pacifique (Tokyo) : 13:00 – 021:00 UTC

  • Région Canada (Centre) : 03:00 – 11:00 UTC

  • Région Canada Ouest (Calgary) : 4 h 00–12 h 00 UTC

  • Région Chine (Beijing) : 13:00 – 21:00 UTC

  • Région Chine (Ningxia) : 13:00 – 21:00 UTC

  • Région Europe (Francfort) : 06:00 – 14:00 UTC

  • Région Europe (Irlande) : 22:00 – 06:00 UTC

  • Région Europe (Londres) : 22:00 – 06:00 UTC

  • Région Europe (Milan) : 21:00 – 05:00 UTC

  • Région Europe (Paris) : 23:00 – 07:00 UTC

  • Région Europe (Stockholm) : 23:00 – 07:00 UTC

  • Région Europe (Zurich) : 20:00 – 04:00 UTC

  • Région Israël (Tel Aviv) : 20:00 – 04:00 UTC

  • Région Mexique (Centre) : 04:00 – 12:00 UTC

  • Région Europe (Espagne) : 21:00 – 05:00 UTC

  • Région Moyen-Orient (Bahreïn) : 13:00 – 21:00 UTC

  • Région Moyen-Orient (EAU) : 18:00 – 02:00 UTC

  • Région Amérique du Sud (São Paulo) : 19:00 – 03:00 UTC

Si un événement de maintenance est planifié pour une semaine donnée, il démarre pendant la fenêtre de maintenance de 30 minutes attribuée. Pendant qu’Amazon Redshift effectue la maintenance, il met fin à toutes les requêtes ou autres opérations en cours. La plus grande partie de la maintenance s’effectue pendant la fenêtre de maintenance de 30 minutes, mais certaines tâches de maintenance peuvent continuer à s’exécuter après la fermeture de la fenêtre. S’il n’y a aucune tâche de maintenance à effectuer pendant la fenêtre de maintenance planifiée, votre cluster continue à fonctionner normalement jusqu’à la prochaine fenêtre de maintenance.

Vous pouvez modifier la fenêtre de maintenance planifiée en modifiant le cluster, soit de manière programmatique, soit en utilisant la console Amazon Redshift. Vous pouvez trouver la fenêtre de maintenance et définir le jour et l’heure auxquels elle se produit pour le cluster sous l’onglet Maintenance.

Il est possible qu’un cluster redémarre en dehors d’une fenêtre de maintenance. Cela peut se produire pour plusieurs raisons. Une des raisons les plus courantes est qu’un problème a été détecté avec le cluster et que des opérations de maintenance sont en cours pour le ramener à un état sain. Pour plus d’informations, consultez l’article Pourquoi mon cluster Amazon Redshift a-t-il redémarré en dehors de la fenêtre de maintenance ?, qui fournit des détails sur les raisons pour lesquelles cela peut se produire.

Report de la maintenance

Pour replanifier la fenêtre de maintenance de votre cluster, vous pouvez reporter la maintenance de 45 jours au plus. Par exemple, si la fenêtre de maintenance de votre cluster est définie sur mercredi 8 h 30 – 9 h UTC, mais que vous devez accéder à votre cluster à ce moment précis, vous pouvez reporter la maintenance.

Si vous reportez la maintenance, Amazon Redshift appliquera toujours les mises à jour matérielles ou autres mises à jour de sécurité obligatoires à votre cluster. Votre cluster n’est pas disponible au cours de ces mises à jour.

Si une mise à jour matérielle ou une autre mise à jour de sécurité obligatoire est planifiée pendant la prochaine fenêtre de maintenance, Amazon Redshift vous envoie des notifications anticipées dans la catégorie En attente. Pour en savoir plus sur les notifications d’événements En attente, consultez Notifications d’événement d’un cluster alloué Amazon Redshift.

Vous pouvez également choisir de recevoir des notifications d’événements d’Amazon Simple Notification Service (Amazon SNS). Pour plus d’informations sur l’abonnement à la notification d’événements Amazon RDS, consultez Abonnements aux notifications d’événements de cluster Amazon Redshift.

Si vous reportez la maintenance de votre cluster, la fenêtre de maintenance suivant la période de report ne peut pas être reportée.

Note

Vous ne pouvez pas reporter une opération de maintenance une fois celle-ci entamée.

Pour plus d’informations sur la maintenance du cluster, consultez la documentation suivante :

Sélection du suivi de maintenance des clusters

Lorsque Amazon Redshift publie une nouvelle version du cluster, votre cluster est mis à jour pendant sa fenêtre de maintenance. Vous pouvez vérifier si votre cluster est mis à jour par rapport à la dernière version ou à la précédente.

Le suivi contrôle la version du cluster qui est appliquée au cours d’une fenêtre de maintenance. Lorsqu’Amazon Redshift publie une nouvelle version du cluster, cette version est assignée au suivi Current (Actuellle) et la version précédente est assignée au suivi Trailing (Précédente).

Pour plus d’informations sur le suivi du cluster, consultez Suivi des clusters alloués Amazon Redshift et des groupes de travail sans serveur.

Comprendre comment les nœuds RA3 séparent le calcul du stockage

Ces sections détaillent les tâches disponibles pour les types de nœuds RA3, en montrant leur applicabilité dans un ensemble de cas d’utilisation et en détaillant leurs avantages par rapport aux types de nœuds précédemment disponibles.

Avantages et disponibilité des nœuds RA3

Les nœuds RA3 offrent les avantages suivants :

  • Ils sont flexibles pour augmenter votre capacité de calcul sans augmenter vos coûts de stockage. De plus, ils adaptent votre stockage sans surprovisionner la capacité de calcul.

  • Ils utilisent des disques SSD haute performance pour vos données sensibles (hot data) et Amazon S3 pour les données non sensibles (cold data). Ils offrent ainsi une facilité d’utilisation, un stockage économique et des performances de requête élevées.

  • Ils utilisent un réseau à large bande passante basé sur le système Nitro d’AWS pour réduire davantage le temps nécessaire au déchargement et à la récupération des données sur Amazon S3.

Envisagez de choisir des types de nœuds RA3 dans les cas suivants :

  • Si vous avez besoin de la flexibilité nécessaire pour dimensionner et payer le calcul indépendamment du stockage.

  • Vous interrogez une fraction de vos données totales.

  • Votre volume de données augmente rapidement ou devrait croître rapidement.

  • Vous souhaitez avoir la flexibilité nécessaire pour dimensionner le cluster uniquement en fonction de vos besoins en performances.

Pour utiliser des types de nœuds RA3, votre région AWS doit prendre en charge RA3. Pour plus d'informations, consultez Disponibilité du type de nœud RA3 dans les régions AWS.

Important

Vous pouvez utiliser les types de nœuds ra3.xlplus uniquement avec la version de cluster 1.0.21262 ou ultérieure. Vous pouvez consulter la version d’un cluster existant avec la console Amazon Redshift. Pour plus d’informations, consultez Déterminer la version du groupe de travail ou du cluster.

Assurez-vous d’utiliser la nouvelle console Amazon Redshift lorsque vous travaillez avec les types de nœuds RA3.

En outre, pour utiliser les types de nœuds RA3 avec les opérations Amazon Redshift qui utilisent le suivi, la valeur de ce dernier doit être définie sur une version de cluster qui prend en charge RA3. Pour plus d’informations sur le suivi, consultez Sélection du suivi de maintenance des clusters.

Prenez en compte les points suivants lorsque vous utilisez des types de nœuds RA3 à nœud unique.

  • Les producteurs et consommateurs d’unités de partage des données sont pris en charge.

  • Pour modifier les types de nœuds, seul le redimensionnement classique est pris en charge. La modification du type de nœud avec le redimensionnement élastique ou la restauration d’instantané n’est pas prise en charge. Les scénarios suivants sont pris en charge :

    • Redimensionnement classique de dc2.xlarge à 1 nœud vers ra3.xlplus à 1 nœud, et vice versa.

    • Redimensionnement classique de dc2.xlarge à 1 nœud vers ra3.xlplus à nœuds multiples, et vice versa.

    • Redimensionnement classique de dc2.xlarge à nœuds multiples vers ra3.xlplus à 1 nœud, et vice versa.

Utilisation du stockage géré Amazon Redshift

Avec le stockage géré d’Amazon Redshift, vous pouvez stocker et traiter toutes vos données dans Amazon Redshift tout en bénéficiant d’une plus grande flexibilité pour faire évoluer séparément la capacité de calcul et de stockage. Vous continuez à ingérer des données avec la commande COPY ou INSERT. Pour optimiser les performances et gérer le placement automatique des données sur les différents niveaux de stockage, Amazon Redshift tire parti d’optimisations telles que la température des blocs de données, leur âge et les modèles de charge de travail. Lorsque cela est nécessaire, Amazon Redshift met automatiquement à niveau le stockage vers Amazon S3 sans nécessiter d’action manuelle.

Pour plus d’informations sur les coûts de stockage, consultez Tarification Amazon Redshift.

Gestion des types de nœuds RA3

Pour tirer parti de la séparation du calcul du stockage, vous pouvez créer ou mettre à niveau votre cluster avec le type de nœud RA3. Pour utiliser les types de nœuds RA3, créez vos clusters dans un cloud privé virtuel (EC2-VPC).

Pour modifier le nombre de nœuds du cluster Amazon Redshift avec un type de nœud RA3, effectuez l’une des opérations suivantes :

  • Ajoutez ou supprimez des nœuds avec l’opération de redimensionnement élastique. Dans certaines situations, la suppression de nœuds d’un cluster RA3 n’est pas autorisée avec le redimensionnement élastique. Par exemple, lorsqu’une mise à niveau du nombre de nœuds 2:1 place le nombre de tranches par nœud à 32. Pour plus d’informations, consultez Redimensionnement d’un cluster. Si le redimensionnement élastique n’est pas disponible, utilisez le redimensionnement classique.

  • Ajoutez ou supprimez des nœuds avec l’opération de redimensionnement classique. Choisissez cette option lorsque vous effectuez un redimensionnement sur une configuration qui ne permet pas le redimensionnement Elastic Le redimensionnement élastique est plus rapide que le redimensionnement classique. Pour plus d’informations, consultez Redimensionnement d’un cluster.

Disponibilité du type de nœud RA3 dans les régions AWS

Les types de nœuds RA3 sont disponibles uniquement dans les régions AWS suivantes :

  • Région USA Est (Virginie du Nord) (us-east-1)

  • Région USA Est (Ohio) (us-east-2)

  • Région US Ouest (Californie du Nord) (us-west-1)

  • Région USA Ouest (Oregon) (us-west-2)

  • Région Afrique (Le Cap) (af-south-1)

  • Région Asie-Pacifique (Hong Kong) (ap-east-1)

  • Région Asie-Pacifique (Hyderabad) (ap-south-2)

  • Région Asie-Pacifique (Jakarta) (ap-southeast-3)

  • Région Asie-Pacifique (Malaisie) (ap-southeast-5)

  • Région Asie-Pacifique (Melbourne) (ap-southeast-4)

  • Région Asie-Pacifique (Mumbai) (ap-south-1)

  • Région Asie-Pacifique (Nouvelle Zélande) (ap-southeast-6)

  • Région Asie-Pacifique (Osaka) (ap-northeast-3)

  • Région Asie-Pacifique (Séoul) (ap-northeast-2)

  • Région Asie-Pacifique (Singapour) (ap-southeast-1)

  • Région Asie-Pacifique (Sydney) (ap-southeast-2)

  • Région Asie-Pacifique (Taipei) (ap-east-2)

  • Région Asie-Pacifique (Thaïlande) (ap-southeast-7)

  • Région Asie-Pacifique (Tokyo) (ap-northeast-1)

  • Région Canada (Centre) (ca-central-1)

  • Région Canada Ouest (Calgary) (ca-west-1)

  • Région Chine (Beijing) (cn-north-1)

  • Région Chine (Ningxia) (cn-northwest-1)

  • Région Europe (Francfort) (eu-central-1)

  • Région Europe (Zurich) (eu-central-2)

  • Région Europe (Irlande) (eu-west-1)

  • Région Europe (Londres) (eu-west-2)

  • Région Europe (Milan) (eu-south-1)

  • Région Europe (Espagne) (eu-south-2)

  • Région Europe (Paris) (eu-west-3)

  • Région Europe (Stockholm) (eu-north-1)

  • Région Israël (Tel Aviv) (il-central-1)

  • Région Mexique (Centre) (mx-central-1)

  • Région Moyen-Orient (Bahreïn) (me-south-1)

  • Région Moyen-Orient (Émirats arabes unis) (me-central-1)

  • Région Amérique du Sud (Sao Paulo) (sa-east-1)

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

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

Mise à niveau vers des types de nœuds RA3

Pour mettre à niveau votre type de nœud existant vers RA3, vous disposez des options suivantes afin de modifier le type de nœud :

  • Restauration à partir d’un instantané : Amazon Redshift utilise l’instantané le plus récent de votre cluster et le restaure pour créer un nouveau cluster RA3. Dès que la création du cluster est terminée (généralement en quelques minutes), les nœuds RA3 sont prêts à exécuter votre charge de travail de production complète. Comme le calcul est séparé du stockage, les données chaudes sont introduites dans le cache local à des vitesses rapides grâce à une large bande passante réseau. Si vous effectuez une restauration à partir du dernier instantané DC2, RA3 conserve les informations sur les blocs chauds de la charge de travail DC2 et remplit son cache local avec les blocs les plus chauds. Pour plus d’informations, consultez Restauration d’un cluster à partir d’un instantané.

    Pour conserver le même point de terminaison pour vos applications et utilisateurs, vous pouvez renommer le nouveau cluster RA3 avec le même nom que le cluster DC2 d’origine. Pour renommer le cluster, modifiez le cluster dans la console Amazon Redshift ou via l’opération API ModifyCluster. Pour plus d’informations, consultez Renommer un cluster ou Opérations de l’API de ModifyCluster dans la Référence API Amazon Redshift.

  • Redimensionnement élastique – Redimensionner le cluster à l’aide du redimensionnement Elastic. Lorsque vous utilisez le redimensionnement Elastic pour changer de type de nœud, Amazon Redshift crée automatiquement un instantané, puis un nouveau cluster, supprime l’ancien cluster et renomme le nouveau cluster. L’opération de redimensionnement Elastic peut être exécutée à la demande ou programmée pour être exécutée plus tard. Vous pouvez rapidement mettre à niveau vos clusters de type nœud DC2 existants vers RA3 avec un redimensionnement élastique. Pour plus d’informations, consultez Elastic resize (Redimensionnement élastique).

Le tableau suivant présente des recommandations lors de la mise à niveau vers des types de nœuds RA3. (Ces recommandations s’appliquent également aux nœuds réservés.)

Les recommandations de cette table concernent les types et tailles de nœuds de cluster de départ, mais dépendent des exigences informatiques de votre charge de travail. Pour mieux estimer vos besoins, envisagez de réaliser une preuve de concept (POC) qui utilise Test Drive pour exécuter des configurations potentielles. Allouez un cluster pour votre entrepôt de données POC au lieu de Redshift sans serveur. Pour plus d’informations sur la réalisation d’une preuve de concept, consultez Réaliser une preuve de concept (POC) pour Amazon Redshift dans le Guide du développeur de base de données Amazon Redshift.

Type de nœud existant Nombre de nœuds existants Nouveau type de nœud recommandé Action de mise à niveau

dc2.8xlarge

2–15

ra3.4xlarge

Commencez par 2 nœuds de ra3.4xlarge pour chaque nœud de dc2.8xlarge1.

dc2.8xlarge

16–128

ra3.16xlarge

Commencez par 1 nœud de ra3.16xlarge pour tous les 2 nœuds de dc2.8xlarge1.

dc2.large

1 – 4

ra3.large

Commencez par 1 nœud de ra3.large pour chaque nœud de dc2.large1.

Commencez par 2 nœuds de ra3.large tous les 2 nœuds de dc2.large1.

Commencez par 3 nœuds de ra3.large tous les 3 nœuds de dc2.large1.

Commencez par 3 nœuds de ra3.large tous les 4 nœuds de dc2.large1.

dc2.large

5–15

ra3.xlplus

Commencez par 3 nœuds de ra3.xlplus tous les 8 nœuds de dc2.large1.

dc2.large

16–32

ra3.4xlarge

Commencez par 1 nœud de ra3.4xlarge tous les 8 nœuds de dc2.large1,2.

1Des nœuds supplémentaires peuvent être nécessaires en fonction des exigences de charge de travail. Ajoutez ou supprimez des nœuds en fonction des besoins de calcul de vos performances de requête requises.

2Les clusters avec le type de nœud dc2.large sont limités à 32 nœuds.

Le nombre minimum de nœuds pour certains types de nœud RA3 est de deux nœuds. Prenez cela en compte lors de la création d’un cluster RA3.

Fonctionnalités de mise en réseau prises en charge par les nœuds RA3

Les nœuds RA3 prennent en charge un ensemble de fonctionnalités de mise en réseau auxquelles les autres types de nœuds n’ont pas accès. Cette section fournit une brève description de chaque fonctionnalité et des liens vers de la documentation supplémentaire :

  • Point de terminaison d’un VPC de cluster alloué : lorsque vous créez ou restaurez un cluster RA3, Amazon Redshift utilise un port compris dans les plages 5431-5455 ou 8191-8215. Lorsque le cluster est défini sur un port de l’une de ces plages, Amazon Redshift crée automatiquement un point de terminaison d’un VPC dans votre compte AWS pour le cluster et y attache une adresse IP privée. Si vous configurez le cluster pour qu’il soit accessible au public, Redshift crée une adresse IP Elastic dans votre compte AWS et l’attache au point de terminaison d’un VPC. Pour plus d’informations, consultez Configuration des paramètres de communication des groupes de sécurité pour un cluster Amazon Redshift ou un groupe de travail Amazon Redshift sans serveur

  • Clusters RA3 à sous-réseau unique – Vous pouvez créer un cluster RA3 avec un seul sous-réseau, mais il ne peut pas utiliser les fonctionnalités de reprise après sinistre. Une exception se produit si vous activez la relocalisation de cluster alors que le sous-réseau ne dispose pas de plusieurs zones de disponibilité (AZ).

  • Clusters RA3 et groupes de sous-réseaux à sous-réseaux multiples : vous pouvez créer un cluster RA3 avec plusieurs sous-réseaux en créant un groupe de sous-réseaux lorsque vous allouez le cluster dans votre cloud privé virtuel (VPC). Un groupe de sous-réseaux de cluster vous permet de spécifier un ensemble de sous-réseaux dans votre VPC et Amazon Redshift crée le cluster dans l’un d’entre eux. Après avoir créé un groupe de sous-réseaux, vous pouvez supprimer les sous-réseaux ajoutés précédemment ou en ajouter plus. Pour de plus amples informations, consultez Groupes de sous-réseaux de cluster Amazon Redshift.

  • Accès aux points de terminaison entre comptes ou entre VPC : vous pouvez accéder à un cluster alloué ou à un groupe de travail Amazon Redshift sans serveur en configurant un point de terminaison d’un VPC géré par Redshift. Vous pouvez le configurer en tant que connexion privée entre un VPC qui contient un cluster ou un groupe de travail et un VPC dans lequel vous exécutez un outil client, par exemple. Ainsi, vous pouvez accéder à l’entrepôt des données sans utiliser d’adresse IP publique ni acheminer le trafic sur Internet. Pour plus d’informations, consultez Utilisation des points de terminaison d’un VPC géré par Redshift.

  • Relocalisation de cluster : vous pouvez déplacer un cluster vers une autre zone de disponibilité (AZ) sans subir la moindre de perte de données en cas d’interruption de service. Vous devez l’activer dans la console. Pour plus d’informations, consultez Relocalisation d’un cluster.

  • Nom de domaine personnalisé – Vous pouvez créer un nom de domaine personnalisé, également appelé URL personnalisée, pour votre cluster Amazon Redshift. Il s’agit d’un enregistrement DNS facile à lire qui achemine les connexions client SQL vers le point de terminaison de votre cluster. Pour plus d’informations, consultez Noms de domaine personnalisé pour les connexions client.