Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Migration de hsm1.medium vers hsm2m.medium
Vous pouvez migrer votre AWS CloudHSM cluster de hsm1.medium vers hsm2m.medium. Cette rubrique décrit les prérequis, le processus de migration et les procédures de restauration.
Avant de commencer la migration, assurez-vous que votre application suit les recommandations figurant dansConcevez votre cluster pour une haute disponibilité. Cela permet d'éviter les temps d'arrêt pendant le processus.
Mise à jour automatique de la migration
Depuis le 20 janvier 2026, les migrations automatiques vers hsm2m.medium ont commencé.
Présentation du processus de migration de hsm1.medium vers hsm2m.medium
Vous pouvez démarrer la migration à l'aide de la AWS CloudHSM console AWS CLI, de l'API ou de l' AWS CloudHSM API. Quel que soit l'endroit où vous la lancez, la migration du AWS CloudHSM cluster utilise le point de terminaison de l'modify-clusterAPI. Sinon, AWS CloudHSM effectuera automatiquement la migration du cluster en votre nom. Une fois la migration lancée, l'ensemble de votre cluster passe en mode d'écriture limitée. Pour plus d'informations, consultez Mode d'écriture limité en cluster.
Pour minimiser l'impact, remplacez AWS CloudHSM les HSM de hsm1.medium par hsm2m.medium un par un. Les HSM de remplacement conservent les mêmes adresses IP, ce qui ne nécessite aucune modification de configuration pendant ou après la migration.
Voici comment fonctionne la migration :
-
Avant de migrer le premier HSM, AWS CloudHSM créez une sauvegarde complète de l'ensemble du cluster.
-
À l'aide de cette sauvegarde, AWS CloudHSM crée un nouveau HSM du type demandé (hsm2m.medium) pour remplacer le premier HSM.
-
Avant de migrer chaque HSM suivant, AWS CloudHSM crée une nouvelle sauvegarde complète de l'ensemble du cluster.
-
AWS CloudHSM répète les étapes 2 et 3 pour chaque HSM du cluster, en migrant un HSM à la fois.
-
Chaque migration HSM prend environ 30 minutes.
AWS CloudHSM surveille l'état du cluster et effectue des validations tout au long du processus de migration. S'il AWS CloudHSM détecte une augmentation du nombre d'erreurs ou si un contrôle de validation échoue, il arrête automatiquement la migration et rétablit le type HSM d'origine du cluster. Vous pouvez également revenir en arrière manuellement jusqu'à 24 heures après le début de la migration. Avant de revenir en arrière, consultez la section Considérations relatives à la restauration du type HSM.
Conditions préalables à la migration vers hsm2m.medium
Votre AWS CloudHSM cluster existant doit répondre à ces exigences pour migrer vers hsm2m.medium. Si l'une des conditions n'est pas remplie lors des contrôles de validation, rétablit AWS CloudHSM automatiquement le type HSM d'origine du cluster.
Pour obtenir la liste des problèmes de migration connus, consultez Problèmes connus pour AWS CloudHSM modification du cluster
Au cours des 7 derniers jours :
-
Toutes les connexions client ont utilisé le SDK 5.9 ou supérieur.
-
Si vous effectuez la vérification ECDSA, toutes les connexions client ont utilisé le SDK 5.13 ou une version ultérieure.
-
-
AWS CloudHSM les instances n'ont utilisé que des fonctionnalités prises en charge (et aucune des fonctionnalités obsolètes). Consultez la section Notifications de dépréciation pour plus de détails.
Vous devez avoir utilisé un SDK pour vous connecter à au moins un HSM du cluster au cours des 7 derniers jours.
-
Le cluster est dans un état ACTIF.
Le cluster compte 27 HSM ou moins.
Le taux d'erreur pour les opérations HSM n'augmente pas pendant la migration.
Note
La restriction précédente qui empêchait les clients dont les charges de travail étaient liées à des clés symboliques de migrer a été supprimée.
Exemption de l'obligation de connexion au SDK
Si votre cluster n'a eu aucune connexion au SDK ou au client au cours des 14 derniers jours, votre cluster est exempté de l'exigence de connexion au SDK pendant 7 jours.
Mode d'écriture limité en cluster
Lorsque votre cluster démarre la migration, il passe en mode d'écriture limitée. Les opérations susceptibles de modifier l'état du HSM sont rejetées. Toutes les opérations de lecture restent inchangées.
Au cours de la migration, votre application reçoit une erreur du HSM lorsqu'elle tente les opérations suivantes :
Génération et suppression de clés de jeton (les charges de travail des clés de session continuent de fonctionner).
Toutes les créations, suppressions ou modifications d'utilisateurs.
Opérations relatives au quorum.
Modification des clés au sein du HSM, telle que la modification des attributs clés.
Enregistrement mTLS.
AWS CloudHSM place également votre cluster dans un MODIFY_IN_PROGRESS état lors de la migration. Pendant ce temps, vous ne pouvez ni ajouter ni supprimer des HSM du cluster.
Commencer la migration
Le processus de migration du cluster remplace les HSM individuels de votre cluster, un par un. La durée dépend du nombre de HSM de votre cluster. En moyenne, ce processus prend environ 30 minutes par HSM. Vous pouvez suivre les progrès en surveillant le type de HSM de chaque HSM du cluster pour voir combien ont été migrés vers le nouveau type.
Annulation de la migration
AWS CloudHSM surveille les taux d'erreur élevés et effectue des contrôles de validation continus tout au long de la migration. S'il AWS CloudHSM détecte une baisse de la qualité de service ou des échecs de validation, il initie automatiquement un retour au type HSM d'origine de votre cluster. Lors d'une restauration, pour chaque HSM du cluster :
AWS CloudHSM utilise la sauvegarde effectuée au début de la migration de ce HSM.
Il remplace un HSM à la fois jusqu'à ce que tous les HSM retrouvent leur type d'origine.
Votre cluster reste en mode d'écriture limitée tout au long du processus.
Vous pouvez annuler la migration dans les 24 heures suivant son démarrage. Pour vérifier la date limite d'annulation :
-
Exécutez la commande describe-clusters.
-
Recherchez la
HsmTypeRollbackExpirationvaleur. Cet horodatage est votre date limite d'annulation.
Si vous décidez de revenir en arrière, faites-le avant cette date limite. La restauration utilise la dernière sauvegarde de votre type HSM d'origine.
Avertissement
Faites attention à ne pas revenir en arrière une fois la migration terminée. Si vous terminez une migration et que vous l'utilisez AWS CloudHSM pour créer de nouvelles clés ou de nouveaux utilisateurs, l'annulation peut entraîner une perte de données. Par exemple, une clé créée dans hsm2m.medium peut ne pas être disponible dans hsm1.medium une fois la restauration terminée. Consultez la section Synchronisation des données après une restauration pour savoir comment atténuer les pertes de données après une restauration.
Synchronisation des données après une restauration
Pendant la migration, les HSM sont en mode d'écriture limitée, ce qui empêche toute modification de l'état des HSM. Si vous annulez pendant cette période (alors que le cluster l'estMODIFY_IN_PROGRESS), il en résulte un cluster dont le contenu est identique à celui du cluster d'origine.
Une fois que votre cluster est revenu à ACTIVE cet état, le mode d'écriture limitée est levé. Si vous créez une clé ou un utilisateur alors que vous êtes dans ACTIVE cet état, puis que vous revenez en arrière, cette clé ou cet utilisateur ne sera pas présent dans votre cluster annulé.
Pour gérer la synchronisation des utilisateurs, utilisez la gestion des utilisateurs à l'aide de l'interface de ligne de commande CloudHSM pour recréer les utilisateurs manquants sur votre cluster annulé. Les utilisateurs doivent être recréés manuellement car la user replicate commande ne prend pas en charge la synchronisation des utilisateurs entre hsm2m.medium et hsm1.medium. Consultez la section Problèmes connus liés à la réplication par l'utilisateur.
Pour gérer la synchronisation des clés, utilisez la commande key replicate pour répliquer une clé entre deux clusters. Si vous n'avez pas installé l'interface de ligne de commande CloudHSM, consultez les instructions figurant dans. Démarrage avec AWS CloudHSM Interface de ligne de commande (CLI)
Pour synchroniser les clés après la restauration
Suivez ces étapes une fois la restauration terminée. Nous utiliserons les termes suivants :
« cluster-1 » : votre cluster annulé (maintenant hsm1.medium)
« cluster-2 » : un nouveau cluster hsm2m.medium temporaire que vous allez créer
-
Créez un nouveau cluster hsm2m.medium (cluster-2) à l'aide de la dernière sauvegarde hsm2m.medium à partir du cluster-1 :
aws cloudhsmv2 create-cluster --hsm-type hsm2m.medium \ --subnet-ids<subnet ID 1><subnet ID 2><subnet ID N>\ --source-backup-id<backup ID>--mode<FIPS> -
Créez un HSM dans le cluster-2 :
aws cloudhsmv2 create-hsm --cluster-id<cluster-2 ID> -
Répertoriez les clés du cluster-2 qui nécessitent une réplication :
cloudhsm-cli key list --cluster-id<cluster-2 ID> -
Répliquez chaque clé du cluster-2 vers le cluster-1 :
cloudhsm-cli key replicate --source-cluster-id<cluster-2 ID>\ --destination-cluster-id<cluster-1 ID>\ --filter attr.label=<key ID> -
Répétez l'étape 4 pour chaque clé à copier.
-
Supprimez le HSM dans le cluster-2 :
aws cloudhsmv2 delete-hsm --cluster-id<cluster-2 ID>--hsm-id<HSM ID> -
Supprimer le cluster-2 :
aws cloudhsmv2 delete-cluster --cluster-id<cluster-2 ID>
