Comment redimensionner un cluster Amazon Redshift ?

Résolution

Quatre méthodes permettent de redimensionner un cluster Amazon Redshift :

• Redimensionnement élastique : Si le redimensionnement élastique est disponible en option, utilisez le redimensionnement élastique pour modifier le type de nœud, le nombre de nœuds ou les deux. Lorsque vous modifiez uniquement le nombre de nœuds, les requêtes sont temporairement interrompues et les connexions restent ouvertes. Un redimensionnement élastique prend environ 10 à 15 minutes. Le cluster est en mode lecture seule, lors d’une opération de redimensionnement.
• Redimensionnement classique : Utilisez le redimensionnement classique lorsque la modification de la taille du cluster ou du nœud n'est pas prise en charge par le redimensionnement élastique. Le redimensionnement classique crée un cluster cible, puis fait migrer vos données et métadonnées du cluster source vers le cluster cible. Si vous utilisez le type de nœud cible RA3, le cluster source redémarre et est indisponible quelques minutes. Une fois le cluster redémarré, il est disponible pour les opérations de lecture et d'écriture. Le redimensionnement se poursuit en arrière-plan. Si vous utilisez un autre type de nœud cible, après un redémarrage, le cluster passe en mode lecture seule pendant que les données migrent vers le cluster cible. Lorsque la migration est terminée, le cluster cible est mis à jour avec le point de terminaison et est disponible pour les tâches de lecture et d'écriture. Pour plus d'informations sur le type de nœud cible à utiliser, reportez-vous à la section Redimensionnement classique.
• Instantané, restauration et redimensionnement : Pour vous assurer que le cluster est disponible lors d'une opération de redimensionnement classique, copiez d'abord le cluster existant. Redimensionnez ensuite le nouveau cluster. Si des données sont écrites sur le cluster source après la prise d'un instantané, elles doivent être copiées manuellement. Cette copie manuelle des données vers le cluster cible nouvellement créé doit avoir lieu une fois la migration terminée.

Pour plus d'informations, reportez-vous à la section Présentation de la gestion des clusters dans Amazon Redshift.

Conditions préalables au redimensionnement

Pour vérifier si votre cluster est éligible au redimensionnement élastique, exécutez cette commande AWS CLI ou AWS CloudShell :

aws redshift describe-node-configuration-options --cluster-identifier <cluster-id> --action-type resize-cluster

Remarque : Si vous recevez des messages d'erreur lors de l'exécution des commandes de l'interface de la ligne de commande AWS (AWS CLI), vérifiez que vous utilisez la version la plus récente de l'AWS CLI Si le cluster est éligible pour le redimensionnement élastique, la sortie est similaire à cet exemple dans AWS CLI :

{
  "NodeConfigurationOptionList": [
    {
      "NodeType": "dc2.large",
      "NumberOfNodes": 2,
      "EstimatedDiskUtilizationPercent": 0.01
    },
    {
      "NodeType": "ra3.16xlarge",
      "NumberOfNodes": 2,
      "EstimatedDiskUtilizationPercent": 0.01
    }
  ]
}

Si le cluster n'est pas éligible au redimensionnement élastique, le résultat est similaire à cet exemple dans l'AWS CLI :

{
  "NodeConfigurationOptionList": []
}

Indice de performance

Pour vous aider à prendre une décision de redimensionnement, effectuez un test de référence sur les charges de travail de cluster existantes et sur les charges de travail de cluster cibles.

Redimensionner la vitesse de fonctionnement

Si le redimensionnement élastique est utilisé pour redimensionner un cluster avec le même type de nœud, l'opération ne crée pas de nouveau cluster. Par conséquent, l'opération se termine rapidement. Le temps requis pour effectuer un redimensionnement classique ou une opération de prise d’instantanée et de restauration peut varier en fonction des facteurs suivants :

• La charge de travail sur le cluster source.
• Le nombre et la taille des tables transférées du cluster source au cluster cible.
• La répartition uniforme des données entre les nœuds et les tranches de calcul.
• Configuration du nœud dans les clusters source et cible.

Remarque : Si vous effectuez un redimensionnement classique sur un cluster contenant un volume de données important et que les nœuds ne sont pas RA3, la migration des données peut être lente. La migration d'un cluster contenant plusieurs téraoctets (To) de données peut prendre plusieurs jours. Le transfert de données pour les nœuds RA3 s'effectue plus rapidement.

Optimisation de la vitesse de fonctionnement

Pour réduire le temps requis pour un redimensionnement classique ou une opération de prise d'instantané et de restauration :

• Migrer vers le type de nœud RA3, car le redimensionnement est plus rapide.
• Exécutez le script inspecteur de tables depuis le référentiel AWS Labs sur le site Web de GitHub pour identifier les tables asymétriques. Pour corriger les tables asymétriques, choisissez une clé de distribution appropriée. Pour plus d'informations, reportez-vous au guide de conception de tables avancées d'Amazon Redshift Engineering : Styles de distribution et clés de distribution.
• Supprimez les tables non utilisées. Pour identifier les tables non utilisées, exécutez le script de résumé des tables non scannées depuis le référentiel AWS Labs sur le site Web de GitHub.
  Remarque : Le résumé de la table non scannée ne montre que l'historique récent (environ 2 et 5 jours). Utilisez l'utilitaire de persistance des objets du système sur le site Web GitHub pour recueillir des données d'utilisation sur une plus longue période.
• Identifiez les tables avec statistiques manquantes dans le référentiel AWS Labs sur le site Web GitHub. Exécutez ensuite la commande ANALYSER sur ces tables.

Pour plus d'informations sur l'optimisation des performances de redimensionnement, reportez-vous à 10 meilleures techniques d'optimisation des performances pour Amazon Redshift. Pour vérifier l'état de votre opération de redimensionnement à l'aide de la console Amazon Redshift, choisissez l'onglet État sur la page des détails du cluster. L'onglet État indique le taux de transfert moyen, le temps écoulé et le temps restant.

Résolution des problèmes

• Lors d'une opération de redimensionnement, la taille de votre table augmente ou diminue. Cette réaction est normale. Pour plus d'informations, reportez-vous à la section Pourquoi une table dans mon cluster Amazon Redshift consomme-t-elle plus ou moins d'espace de stockage sur disque que prévu ?
• Si votre cluster présente un état AUCUN dans l'AWS CLI, alors le cluster cible est toujours en cours de provisionnement. Lorsque votre cluster cible est provisionné, il n'a pas encore été copié. Une fois que votre cluster cible est provisionné, l’état passe à IN_PROGRESS.
• Si vos AWS CloudFormation StackSets ne sont pas redimensionnés et que vous recevez un message d'erreur interne, vérifiez si le cluster est éligible au redimensionnement élastique. Le message d'erreur est similaire à l’exemple suivant : « Une erreur interne s'est produite. Veuillez réessayer votre requête ultérieurement. » Ce message apparaît parce que la pile CloudFormation utilise le redimensionnement élastique et que Classic:false est défini par défaut.
• Si vous recevez le message d'erreur « Veuillez choisir un cluster cible plus important », alors vos données ne tiennent pas dans le cluster cible. Redimensionnez votre cluster Amazon Redshift avec plus de nœuds ou un type de nœud différent.
• Choisissez Annuler le redimensionnement dans la liste des clusters de la console Amazon Redshift pour annuler une opération de redimensionnement avant qu'elle ne soit terminée. Pour plus d'informations, reportez-vous à la section Instantané, restauration et redimensionnement.

Facturation des clusters redimensionnés

• Pendant l'opération de redimensionnement, vous êtes facturé pour les clusters disponibles. Par exemple, pendant l'opération de redimensionnement, vous êtes facturé pour la configuration source. Une fois le redimensionnement terminé, vous n'êtes plus facturé pour la configuration source. La facturation commence pour la configuration cible dès que l'état du cluster passe à Disponible.
• Lorsque vous redimensionnez des types de nœuds plus petits (grand, xlarge) en types de nœuds plus grands (8xlarge), votre cluster a besoin de plus d'espace de stockage par nœud. Plus le stockage par nœud est important, plus les métadonnées écrites lors de l'exécution d'un COMMIT sont nombreuses. Par conséquent, le coût de base d'une seule opération COMMIT est plus élevé pour les nœuds plus grands. Si vous exécutez plusieurs petites opérations COMMIT simultanément, vous risquez de voir les performances diminuer. Pour améliorer les performances, regroupez plusieurs modifications en une seule opération COMMIT.
• Si vous avez acheté des Instances réservées, votre facturation dépend de la configuration du cluster redimensionné, des types de nœuds réservés et du nombre de nœuds réservés. Pour plus d'informations, reportez-vous à la section Comment fonctionnent les nœuds réservés.

Informations connexes

Redimensionnement des clusters dans Amazon Redshift

Résolution des problèmes de connexion dans Amazon Redshift

Création de tests de référence de haute qualité pour Amazon Redshift à l'aide de SQLWorkbench et psql