Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Migration von hsm1.medium zu hsm2m.medium
Sie können Ihren Cluster von hsm1.medium nach hsm2m.medium migrieren. AWS CloudHSM In diesem Thema werden die Voraussetzungen, der Migrationsprozess und die Rollback-Verfahren beschrieben.
Bevor Sie mit der Migration beginnen, stellen Sie sicher, dass Ihre Anwendung die Empfehlungen unter befolgt. Richten Sie Ihren Cluster auf Hochverfügbarkeit aus Dies hilft, Ausfallzeiten während des Prozesses zu vermeiden.
Automatisches Migrationsupdate
Am 20. Januar 2026 haben automatische Migrationen zu hsm2m.medium begonnen.
Überblick über den Migrationsprozess von hsm1.medium nach hsm2m.medium
Sie können die Migration mithilfe der AWS CloudHSM Konsole, der oder der API starten. AWS CLI AWS CloudHSM Unabhängig davon, wo Sie sie initiieren, verwendet die AWS CloudHSM Cluster-Migration den modify-cluster API-Endpunkt. Alternativ migriert AWS CloudHSM den Cluster automatisch in Ihrem Namen. Sobald die Migration beginnt, wechselt Ihr gesamter Cluster in einen eingeschränkten Schreibmodus. Weitere Informationen finden Sie unter Eingeschränkter Cluster-Schreibmodus.
Um die Auswirkungen zu minimieren, AWS CloudHSM ändern Sie die HSMs nacheinander von hsm1.medium in hsm2m.medium. Die Ersatz-HSMs behalten dieselben IP-Adressen bei, sodass während oder nach der Migration keine Konfigurationsänderungen erforderlich sind.
So funktioniert die Migration:
-
AWS CloudHSM Erstellt vor der Migration des ersten HSM ein vollständiges Backup des gesamten Clusters.
-
AWS CloudHSM Erstellt mithilfe dieses Backups ein neues HSM des angeforderten Typs (hsm2m.medium), das das erste HSM ersetzt.
-
Vor der Migration jedes nachfolgenden HSM wird ein neues vollständiges Backup des gesamten AWS CloudHSM Clusters erstellt.
-
AWS CloudHSM wiederholt die Schritte 2 und 3 für jedes HSM im Cluster und migriert jeweils ein HSM.
-
Jede einzelne HSM-Migration dauert ungefähr 30 Minuten.
AWS CloudHSM überwacht den Zustand des Clusters und führt während des gesamten Migrationsprozesses Validierungen durch. Wenn eine AWS CloudHSM Zunahme von Fehlern festgestellt wird oder eine Validierungsprüfung fehlschlägt, wird die Migration automatisch gestoppt und der Cluster wird auf seinen ursprünglichen HSM-Typ zurückgesetzt. Sie können auch bis zu 24 Stunden nach dem Start der Migration ein manuelles Rollback durchführen. Bevor Sie ein Rollback durchführen, lesen Sie die Überlegungen zum Rollback vom Typ HSM.
Voraussetzungen für die Migration zu hsm2m.medium
Ihr vorhandener AWS CloudHSM Cluster muss diese Anforderungen erfüllen, um zu hsm2m.medium migrieren zu können. Wenn bei den Validierungsprüfungen eine Bedingung nicht erfüllt AWS CloudHSM wird, wird der Cluster automatisch auf seinen ursprünglichen HSM-Typ zurückgesetzt.
Eine Liste der bekannten Migrationsprobleme finden Sie unter Bekannte Probleme für AWS CloudHSM Cluster-Modifizierung
In den letzten 7 Tagen:
-
Alle Client-Verbindungen haben SDK 5.9 oder höher verwendet.
-
Bei der Ausführung von ECDSA Verify wurde für alle Client-Verbindungen SDK 5.13 oder höher verwendet.
-
-
AWS CloudHSM Instanzen haben nur unterstützte (und keine der veralteten) Funktionen verwendet. Weitere Informationen finden Sie unter Benachrichtigungen über veraltete Versionen.
Sie müssen in den letzten 7 Tagen ein SDK verwendet haben, um eine Verbindung mit mindestens einem HSM im Cluster herzustellen.
-
Der Cluster befindet sich in einem AKTIVEN Zustand.
Der Cluster hat 27 HSMs oder weniger.
Die Fehlerrate für HSM-Operationen steigt während der Migration nicht an.
Anmerkung
Die vorherige Einschränkung, die Kunden mit Token-Key-Workloads an der Migration hinderte, wurde aufgehoben.
Ausnahme von der SDK-Verbindungsanforderung
Wenn Ihr Cluster in den letzten 14 Tagen keine SDK- oder Client-Verbindungen hatte, ist Ihr Cluster von der 7-tägigen SDK-Verbindungsanforderung ausgenommen.
Eingeschränkter Cluster-Schreibmodus
Wenn Ihr Cluster mit der Migration beginnt, wechselt er in einen eingeschränkten Schreibmodus. Vorgänge, die den HSM-Status ändern können, werden abgelehnt. Alle Lesevorgänge bleiben davon unberührt.
Während der Migration erhält Ihre Anwendung eine Fehlermeldung vom HSM, wenn Sie diese Operationen ausführen:
Generierung und Löschung von Token-Schlüsseln (Sitzungsschlüssel-Workloads werden weiterhin ausgeführt).
Alle Benutzererstellungen, Löschungen oder Änderungen.
Quorum-Operationen.
Änderung von Schlüsseln innerhalb des HSM, z. B. Ändern von Schlüsselattributen.
mTLS-Registrierung.
AWS CloudHSM versetzt Ihren Cluster auch während der Migration in einen MODIFY_IN_PROGRESS Zustand. Während dieser Zeit können Sie dem Cluster keine HSMs hinzufügen oder daraus entfernen.
Die Migration wird gestartet
Der Cluster-Migrationsprozess ersetzt einzelne HSMs in Ihrem Cluster nacheinander. Die Dauer hängt von der Anzahl der HSMs in Ihrem Cluster ab. Im Durchschnitt dauert dieser Vorgang etwa 30 Minuten pro HSM. Sie können den Fortschritt verfolgen, indem Sie den HSM-Typ der einzelnen HSMs im Cluster überwachen, um zu sehen, wie viele auf den neuen Typ migriert wurden.
Die Migration wird rückgängig gemacht
AWS CloudHSM überwacht erhöhte Fehlerraten und führt während der gesamten Migration kontinuierliche Validierungsprüfungen durch. Wenn eine AWS CloudHSM Verschlechterung der Servicequalität oder ein Fehler bei der Validierung festgestellt wird, wird automatisch ein Rollback auf den ursprünglichen HSM-Typ Ihres Clusters eingeleitet. Während eines Rollbacks gilt für jedes HSM im Cluster Folgendes:
AWS CloudHSM verwendet das Backup, das zu Beginn der Migration dieses HSM erstellt wurde.
Es ersetzt jeweils ein HSM, bis alle HSMs auf den ursprünglichen Typ zurückgesetzt sind.
Ihr Cluster bleibt während des gesamten Vorgangs im Modus mit eingeschränktem Schreibzugriff.
Sie können die Migration innerhalb von 24 Stunden nach dem Start rückgängig machen. Um die Frist für das Rollback zu überprüfen:
-
Führen Sie den Befehl describe-clusters aus.
-
Suchen Sie nach dem Wert
HsmTypeRollbackExpiration. Dieser Zeitstempel ist Ihre Frist für das Rollback.
Wenn Sie sich für ein Rollback entscheiden, tun Sie dies vor Ablauf dieser Frist. Das Rollback verwendet das neueste Backup Ihres ursprünglichen HSM-Typs.
Warnung
Seien Sie vorsichtig, wenn Sie nach Abschluss einer Migration ein Rollback durchführen. Wenn Sie eine Migration abschließen und diese dann verwenden AWS CloudHSM , um neue Schlüssel oder Benutzer zu erstellen, kann ein Rollback zu Datenverlust führen. Beispielsweise ist ein in hsm2m.medium erstellter Schlüssel möglicherweise nicht in hsm1.medium verfügbar, wenn das Rollback abgeschlossen ist. Unter Synchronisieren von Daten nach einem Rollback erfahren Sie, wie Sie den Datenverlust nach einem Rollback minimieren können.
Synchronisieren von Daten nach einem Rollback
Während der Migration befinden sich HSMs im eingeschränkten Schreibmodus, wodurch Änderungen am HSM-Status verhindert werden. Wenn Sie während dieser Zeit ein Rollback durchführen (während der Cluster aktiv istMODIFY_IN_PROGRESS), entsteht ein Cluster, dessen Inhalt mit dem ursprünglichen Cluster identisch ist.
Nachdem Ihr Cluster in den ACTIVE Status zurückgekehrt ist, wird der eingeschränkte Schreibmodus aufgehoben. Wenn Sie einen Schlüssel oder Benutzer erstellen, während er sich im ACTIVE Status befindet, und dann ein Rollback durchführen, ist dieser Schlüssel oder Benutzer in Ihrem Rollback-Cluster nicht vorhanden.
Um die Benutzersynchronisierung zu gewährleisten, verwenden Sie die Benutzerverwaltung mit der CloudHSM CLI, um die fehlenden Benutzer in Ihrem Rollback-Cluster neu zu erstellen. Die Benutzer müssen manuell neu erstellt werden, da der user replicate Befehl das Synchronisieren von Benutzern von hsm2m.medium nach hsm1.medium nicht unterstützt. Weitere Informationen finden Sie unter Bekannte Probleme bei der Benutzerreplikation.
Um die Schlüsselsynchronisierung zu beheben, verwenden Sie den Befehl key replicate, um einen Schlüssel zwischen zwei Clustern zu replizieren. Wenn Sie CloudHSM CLI nicht installiert haben, lesen Sie die Anweisungen unter. Erste Schritte mit AWS CloudHSM Befehlszeilenschnittstelle (CLI)
Um Schlüssel nach dem Rollback zu synchronisieren
Folgen Sie diesen Schritten, nachdem Sie das Rollback abgeschlossen haben. Wir verwenden diese Begriffe:
„cluster-1": Ihr Rollback-Cluster (jetzt hsm1.medium)
„cluster-2": Ein neuer temporärer hsm2m.medium-Cluster, den Sie erstellen werden
-
Erstellen Sie einen neuen hsm2m.medium-Cluster (Cluster-2) mit dem neuesten hsm2m.medium-Backup von 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> -
Erstellen Sie ein HSM in Cluster-2:
aws cloudhsmv2 create-hsm --cluster-id<cluster-2 ID> -
Listen Sie die Schlüssel in Cluster-2 auf, die repliziert werden müssen:
cloudhsm-cli key list --cluster-id<cluster-2 ID> -
Replizieren Sie jeden Schlüssel von Cluster-2 nach Cluster-1:
cloudhsm-cli key replicate --source-cluster-id<cluster-2 ID>\ --destination-cluster-id<cluster-1 ID>\ --filter attr.label=<key ID> -
Wiederholen Sie Schritt 4 für jeden Schlüssel, der kopiert werden muss.
-
Löschen Sie das HSM in Cluster-2:
aws cloudhsmv2 delete-hsm --cluster-id<cluster-2 ID>--hsm-id<HSM ID> -
Löschen Sie Cluster-2:
aws cloudhsmv2 delete-cluster --cluster-id<cluster-2 ID>
