Migration vers un cluster HSM chiffré

Pour migrer un cluster non chiffré vers un cluster chiffré à l'aide d'un module de sécurité matériel (HSM), vous créez un nouveau cluster chiffré et vous déplacez vos données vers le nouveau cluster. Vous ne pouvez pas migrer vers un cluster HSM chiffré en modifiant le cluster.

Pour migrer d'un cluster non chiffré vers un cluster HSM chiffré, vous devez d'abord décharger vos données du cluster source existant. Vous devez ensuite les recharger dans un nouveau cluster cible avec le paramètre de chiffrement choisi. Pour plus d'informations sur le lancement d'un cluster chiffré, consultez Chiffrement de base de données Amazon Redshift.

Jusqu'à la dernière étape du processus de migration, votre cluster source reste disponible pour les requêtes en lecture seule. La dernière étape consiste à renommer les clusters source et cible afin de permuter les points de terminaison de manière à ce que la totalité du trafic soit redirigée vers le nouveau cluster cible. Le cluster cible est indisponible tant que vous ne l'avez pas redémarré après l'avoir renommé. Suspendez tous les chargements de données et autres opérations en écriture sur le cluster source pendant le transfert des données.

Pour préparer la migration

1. Identifiez tous les systèmes dépendants qui interagissent avec Amazon Redshift, par exemple les outils de business intelligence (BI) et les systèmes d'extraction, de transformation et de chargement (ETL).

2. Identifiez les requêtes de validation permettant de tester la migration.

   Par exemple, vous pouvez utiliser la requête suivante pour trouver le nombre de tables définies par l'utilisateur.

   select count(*)
   from pg_table_def
   where schemaname != 'pg_catalog';

   La requête suivante renvoie la liste de toutes les tables définies par l'utilisateur et le nombre de lignes de chacune d'entre elles.

   select "table", tbl_rows
   from svv_table_info;

3. Choisissez le moment opportun pour réaliser la migration. Pour déterminer le moment où l'utilisation du cluster est la plus faible, surveillez les indicateurs du cluster tels que CPU l'utilisation et le nombre de connexions à la base de données. Pour de plus amples informations, veuillez consulter Affichage des données de performances de cluster.

4. Ignorez les tables inutilisées.

   Pour obtenir la liste des tables et la fréquence d'interrogation de chacune, exécutez la requête suivante.

   select database,
   schema,
   table_id,
   "table",
   round(size::float/(1024*1024)::float,2) as size,
   sortkey1,
   nvl(s.num_qs,0) num_qs
   from svv_table_info t
   left join (select tbl,
   perm_table_name,
   count(distinct query) num_qs
   from stl_scan s
   where s.userid > 1
   and   s.perm_table_name not in ('Internal worktable','S3')
   group by tbl,
   perm_table_name) s on s.tbl = t.table_id
   where t."schema" not in ('pg_internal');

5. Lancez un nouveau cluster chiffré.

   Indiquez le même numéro de port pour le cluster cible que celui qu'utilisait le cluster source. Pour plus d'informations sur le lancement d'un cluster chiffré, consultez Chiffrement de base de données Amazon Redshift.

6. Configurez les processus de déchargement et chargement des données.

   Vous pouvez faire appel à l'utilitaire de déchargement/copie Amazon Redshift pour vous aider à effectuer la migration des données entre les deux clusters. L'utilitaire exporte les données depuis le cluster source vers un emplacement sur Amazon S3. Les données sont cryptées avec AWS KMS. L'utilitaire importe ensuite automatiquement les données sur le cluster cible. En option, vous pouvez utiliser l'utilitaire pour nettoyer Amazon S3 une fois la migration terminée.

7. Effectuez un test afin de vérifier que le processus fonctionne et d'estimer la durée pendant laquelle les opérations en écriture doivent être suspendues.

   Lors des opérations de déchargement et chargement des données, vous devez préserver la cohérence des données en suspendant tous les chargements habituels et autres opérations en écriture. Utilisez l'une de vos plus grandes tables pour exécuter le test de déchargement/chargement et estimer les délais requis.

8. Créez des objets de base de données, tels que des schémas, vues ou tables. Pour vous aider à générer les instructions du langage de définition des données (DDL) nécessaires, vous pouvez utiliser AdminViewsles scripts du AWS GitHub référentiel.

Pour migrer votre cluster

1. Arrêtez tous les ETL processus sur le cluster source.

   Pour vérifier qu'aucune opération d'écriture n'est en cours, utilisez la console de gestion Amazon Redshift pour surveiller l'écriture. IOPS Pour de plus amples informations, veuillez consulter Affichage des données de performances de cluster.

2. Exécutez les requêtes de validation que vous avez identifiées précédemment afin de collecter des informations sur le cluster source chiffré avant de procéder à la migration.

3. (Facultatif) Créez une file d'attente de gestion de charge de travail (WLM) pour utiliser le maximum de ressources disponibles dans le cluster source et le cluster cible. Par exemple, créez une file d'attente nommée data_migrate et configurez-la avec 95 % de mémoire et un niveau de simultanéité de 4. Pour de plus amples informations, veuillez consulter la rubrique Acheminement des requêtes vers les files d'attente dans le Guide du développeur de bases de données Amazon Redshift.

4. À l'aide de la data_migrate file d'attente, exécutez le UnloadCopyUtility.

   Surveillez le COPY processus UNLOAD et à l'aide de la console Amazon Redshift.

5. Exécutez à nouveau les requêtes de validation et vérifiez que leurs résultats correspondent à ceux du cluster source.

6. Renommez vos clusters source et cible pour permuter les points de terminaison. Pour éviter une interruption de l'activité, effectuez cette opération en dehors des heures de travail,

7. Vérifiez que vous pouvez vous connecter au cluster cible à l'aide de tous vos SQL clients, tels que ETL des outils de reporting.

8. Fermez le cluster source non chiffré.