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.
# Mit einer AWS DMS Replikationsinstanz arbeiten
Wenn Sie eine AWS DMS Replikationsinstanz erstellen, AWS DMS erstellt sie auf einer Amazon EC2 EC2-Instance in einer Virtual Private Cloud (VPC), die auf dem Amazon VPC-Service basiert. Sie verwenden diese Replikations-Instance für die Durchführung Ihrer Datenbankmigration. Die Replikations-Instance bietet hohe Verfügbarkeit und Failover-Support über eine Multi-AZ-Bereitstellung bei Auswahl der Option **Multi-AZ**.
In einer Multi-AZ-Bereitstellung AWS DMS wird automatisch eine synchrone Standby-Replik der Replikationsinstanz in einer anderen Availability Zone bereitgestellt und verwaltet. Die primäre Replikations-Instance wird über die Availability Zones synchron auf das Standby-Replikat repliziert. Dieser Ansatz bietet Datenredundanz, verhindert Blockaden und minimiert I/O Latenzspitzen.
![\[AWS Replikationsinstanz des Datenbankmigrationsdienstes\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-conceptual2.png)
AWS DMS verwendet eine Replikationsinstanz, um eine Verbindung zu Ihrem Quelldatenspeicher herzustellen, die Quelldaten zu lesen und die Daten für den Zieldatenspeicher zu formatieren. Eine Replikations-Instance lädt zudem die Daten in den Ziel-Datenspeicher. Der Großteil dieser Verarbeitung erfolgt im Arbeitsspeicher. Allerdings werden umfangreiche Transaktionen ggf. auf Festplatte gepuffert. Zwischengespeicherte Transaktionen und Protokolldateien werden ebenfalls auf Festplatte geschrieben.
Sie können eine AWS DMS Replikationsinstanz in den folgenden AWS Regionen erstellen.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_ReplicationInstance.html)
AWS DMS unterstützt eine spezielle AWS Region namens „Region“ AWS GovCloud (US) , die es US-Regierungsbehörden und Kunden ermöglicht, sensible Workloads in die Cloud zu verlagern. AWS GovCloud (US) geht auf die spezifischen regulatorischen und Compliance-Anforderungen der US-Regierung ein. Weitere Informationen zu AWS GovCloud (US) finden Sie unter [Was ist AWS GovCloud (USA)?](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/whatis.html)
In den folgenden Abschnitten erhalten Sie weitere Informationen zu Replikations-Instances.
**Topics**
+ [Auswahl der richtigen AWS DMS-Replikationsinstanz für Ihre Migration](CHAP_ReplicationInstance.Types.md)
+ [Auswahl der besten Größe für eine Replikations-Instance](CHAP_BestPractices.SizingReplicationInstance.md)
+ [Arbeiten mit Versionen der Replikations-Engine](CHAP_ReplicationInstance.EngineVersions.md)
+ [Öffentliche und private Replikations-Instances](CHAP_ReplicationInstance.PublicPrivate.md)
+ [IP-Adressierung und Netzwerktypen](CHAP_ReplicationInstance.IPAddressing.md)
+ [Einrichten eines Netzwerks für eine Replikations-Instance](CHAP_ReplicationInstance.VPC.md)
+ [Festlegen eines Verschlüsselungsschlüssels für eine Replikations-Instance](CHAP_ReplicationInstance.EncryptionKey.md)
+ [Erstellen einer Replikations-Instance](CHAP_ReplicationInstance.Creating.md)
+ [Ändern einer Replikations-Instance](CHAP_ReplicationInstance.Modifying.md)
+ [Neustarten einer Replikations-Instance.](CHAP_ReplicationInstance.Rebooting.md)
+ [Löschen einer Replikations-Instance](CHAP_ReplicationInstance.Deleting.md)
+ [Mit dem AWS DMS Wartungsfenster arbeiten](CHAP_ReplicationInstance.MaintenanceWindow.md)
# Auswahl der richtigen AWS DMS-Replikationsinstanz für Ihre Migration
AWS DMS erstellt die Replikationsinstanz auf einer Amazon EC2 EC2-Instance. AWS DMS unterstützt derzeit die Amazon EC2 EC2-Instance-Klassen T3, C5, C6i, R5 und R6i für Replikationsinstanzen:
+ T3-Instances sind der Burstable-Allzweck-Instance-Typ der nächsten Generation. Dieser Typ bietet eine grundlegende CPU-Leistung mit der Fähigkeit, die CPU-Nutzung jederzeit so lange wie nötig zu steigern. T3-Instances bieten ein ausgewogenes Verhältnis von Computing-, Speicher- und Netzwerkressourcen und sind ideal für Workloads mit moderater CPU-Nutzung, bei der temporäre Nutzungsspitzen auftreten. T3-Instances akkumulieren CPU-Guthaben, wenn ein Workload unter dem Basisschwellenwert arbeitet. Jedes CPU-Guthaben bietet der T3-Instance die Möglichkeit, bei Bedarf eine Minute lang die Leistung eines vollen CPU-Kerns zu nutzen.
T3-Instances können jederzeit so lange wie möglich im `unlimited`-Modus erweitert werden. Weitere Informationen zum `unlimited`-Modus finden Sie unter [Arbeiten mit dem unbegrenzten Modus für Burstable Performance Instances](#CHAP_ReplicationInstance.Types.UnlimitedMode).
+ C5-Instances sind der Instance-Typ der nächsten Generation, der für die Ausführung anspruchsvoller rechenintensiver Workloads kostengünstige Höchstleistung zu einem niedrigen Preis pro Rechenleistung bietet. Dazu gehören Workloads wie Hochleistungs-Webserver, High Performance Computing (HPC), Stapelverarbeitung, Ad-Serving, hoch skalierbare Multiplayer-Spiele und Videokodierung. Andere Workloads, für die sich C5-Instances eignen, sind etwa wissenschaftliche Modellierung, verteilte Analysen sowie Inferenz für Machine und Deep Learning. Die C5-Instances sind mit einer Auswahl an Prozessoren von Intel und AMD erhältlich.
+ C6i-Instances bieten ein um bis zu 15 % besseres Computing-Preis-Leistungs-Verhältnis als vergleichbare Gen5-Instances für eine Vielzahl von Workloads sowie eine Always-On-Speicherverschlüsselung. C6i-Instances sind ideal geeignet für rechenintensive Workloads, z. B. Stapelverarbeitung, verteilte Analysen, High Performance Computing (HPC), Ad-Serving, hoch skalierbare Multiplayer-Spiele und Videokodierung.
+ R5-Instances sind die nächste Generation arbeitsspeicheroptimierter Instance-Typen für Amazon EC2. R5-Instances sind gut geeignet für speicherintensive Anwendungen, z. B. Hochleistungsdatenbanken, verteilte Web-Scale-In-Memory-Caches, mittelgroße In-Memory-Datenbanken, Big-Data-Analytik in Echtzeit und andere Unternehmensanwendungen. Laufende Migrationen oder Replikationen von Transaktionssystemen mit hohem Durchsatz können ebenfalls große Mengen an CPU und Arbeitsspeicher beanspruchen. AWS DMS
+ R6i-Instances bieten ein um bis zu 15 % besseres Computing-Preis-Leistungs-Verhältnis als vergleichbare Gen5-Instances für eine Vielzahl von Workloads sowie eine Always-On-Speicherverschlüsselung. R6i-Instances sind SAP-zertifiziert und eignen sich ideal für Workloads wie SQL- und NoSQL-Datenbanken, verteilte webbasierte In-Memory-Caches wie Memcached und Redis OSS, In-Memory-Datenbanken wie SAP HANA und Big-Data-Analysen in Echtzeit wie Hadoop- und Spark-Cluster.
+ C7i-Instances bieten eine bessere Rechenleistung als vergleichbare Instances der vorherigen Generation. Bei AWS DMS Workloads zeichnen sich C7i-Instances durch die Beschleunigung von Datentransformationsprozessen, die Bewältigung rechenintensiver Schemakonvertierungen und die Aufrechterhaltung eines konsistenten Durchsatzes bei umfangreichen Migrationsaufgaben aus. Diese Instances bieten ein ideales Gleichgewicht zwischen Rechenleistung, die eine kontinuierliche CPU-Leistung erfordert.
+ R7i-Instances bieten eine bessere Rechenleistung als vergleichbare Instances der vorherigen Generation, kombiniert mit einer hohen Speicherkapazität für speicherintensive Workloads. Für AWS DMS Workloads eignen sich R7i-Instances besonders gut für Aufgaben mit großen Datenbanken, die große Mengen gleichzeitiger Datenbanktransaktionen verarbeiten. Dies ermöglicht eine effiziente Handhabung speicherintensiver Replikationsszenarien und komplexer Datenvalidierungsprozesse, die umfangreiche Speicherpuffer erfordern.
Jede Replikations-Instance verfügt über eine spezifische Konfiguration für Arbeitsspeicher und vCPU. Die folgende Tabelle zeigt die Konfiguration für die einzelnen Replikations-Instance-Typen. Informationen zu den Preisen finden Sie auf der Seite [AWS Database Migration Service -Service – Preise](https://aws.amazon.com/dms/pricing/).
**Instance-Typen für allgemeine Replikationszwecke**
| Typ | vCPU | Arbeitsspeicher (GiB) |
| --- | --- | --- |
| dms.t3.micro | 2 | 1 |
| dms.t3.small | 2 | 2 |
| dms.t3.medium | 2 | 4 |
| dms.t3.large | 2 | 8 |
**Computing-optimierte Replikations-Instance-Typen**
| Typ | vCPU | Arbeitsspeicher (GiB) |
| --- | --- | --- |
| dms.c5.large | 2 | 4 |
| dms.c5.xlarge | 4 | 8 |
| dms.c5.2xlarge | 8 | 16 |
| dms.c5.4xlarge | 16 | 32 |
| dms.c5.9xlarge | 36 | 72 |
| dms.c5.12xlarge | 48 | 96 |
| dms.c5.18xlarge | 72 | 144 |
| dms.c5.24xlarge | 96 | 192 |
| dms.c6i.large | 2 | 4 |
| dms.c6i.xlarge | 4 | 8 |
| dms.c6i.2xlarge | 8 | 16 |
| dms.c6i.4xlarge | 16 | 32 |
| dms.c6i.8xlarge | 32 | 64 |
| dms.c6i.12xlarge | 48 | 96 |
| dms.c6i.16xlarge | 64 | 128 |
| dms.c6i.24xlarge | 96 | 192 |
| dms.c6i.32xlarge | 128 | 256 |
| dms.c7i.large | 2 | 4 |
| dms.c7i.x groß | 4 | 8 |
| dms.x7i.2 x groß | 8 | 16 |
| dms.x7i.4x groß | 16 | 32 |
| dms.x7i.8xgroß | 32 | 64 |
| dms.x7i.12xlarge | 48 | 96 |
| dms.x7i.16x groß | 64 | 128 |
| dms.x7i.24x groß | 96 | 192 |
| dms.x7i.48x groß | 192 | 384 |
**Speicher-optimierte Replikations-Instance-Typen**
| Typ | vCPU | Arbeitsspeicher (GiB) |
| --- | --- | --- |
| dms.r5.large | 2 | 16 |
| dms.r5.xlarge | 4 | 32 |
| dms.r5.2xlarge | 8 | 64 |
| dms.r5.4xlarge | 16 | 128 |
| dms.r5.8xlarge | 32 | 256 |
| dms.r5.12xlarge | 48 | 384 |
| dms.r5.16xlarge | 64 | 512 |
| dms.r5.24xlarge | 96 | 768 |
| dms.r6i.large | 2 | 16 |
| dms.r6i.xlarge | 4 | 32 |
| dms.r6i.2xlarge | 8 | 64 |
| dms.r6i.4xlarge | 16 | 128 |
| dms.r6i.8xlarge | 32 | 256 |
| dms.r6i.12xlarge | 48 | 384 |
| dms.r6i.16xlarge | 64 | 512 |
| dms.r6i.24xlarge | 96 | 768 |
| dms.r6i.32xlarge | 128 | 1024 |
| dms.r7i groß | 2 | 16 |
| dms.r7i.x groß | 4 | 32 |
| dms.r7i.2 x groß | 8 | 64 |
| dms.r7i.4x groß | 16 | 128 |
| dms.r7i.8xgroß | 32 | 256 |
| dms.r7i.12x groß | 48 | 384 |
| dms.r7i.16x groß | 64 | 512 |
| dms.r7i.24x groß | 96 | 768 |
| dms.r7i.48x groß | 192 | 1536 |
In den obigen Tabellen sind alle Typen von AWS DMS Replikationsinstanzen aufgeführt, aber die Typen, die in Ihrer Region verfügbar sind, können variieren. Um die in Ihrer Region verfügbaren Typen von Replikations-Instances zu sehen, können Sie den folgenden [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)-Befehl ausführen:
```
aws dms describe-orderable-replication-instances --region your_region_name
```
**Topics**
+ [Entscheidung, welche Instance-Klasse verwendet werden soll](#CHAP_ReplicationInstance.Types.Deciding)
+ [Arbeiten mit dem unbegrenzten Modus für Burstable Performance Instances](#CHAP_ReplicationInstance.Types.UnlimitedMode)
## Entscheidung, welche Instance-Klasse verwendet werden soll
Um herauszufinden, welche Replikationsinstanzklasse für Sie am besten geeignet ist, schauen wir uns den AWS DMS verwendeten Change Data Capture-Prozess (CDC) an.
Angenommen, Sie führen einen vollständigen Ladevorgang plus CDC-Aufgabe (Massenladevorgang plus laufende Replikation) aus. In diesem Fall verfügt die Aufgabe über ein eigenes SQLite Repository zum Speichern von Metadaten und anderen Informationen. Bevor ein vollständiger Ladevorgang AWS DMS gestartet wird, werden die folgenden Schritte ausgeführt:
+ AWS DMS beginnt mit der Erfassung von Änderungen für die Tabellen, die migriert werden, aus dem Transaktionslog der Quell-Engine (wir nennen diese *Änderungen zwischengespeichert*). Nachdem das vollständige Laden abgeschlossen ist, werden diese zwischengespeicherten Änderungen gesammelt und auf das Ziel angewendet. Abhängig von der Menge der zwischengespeicherten Änderungen können diese Änderungen direkt aus dem Arbeitsspeicher angewendet werden, wo sie zuerst bis zu einem festen Schwellenwert gesammelt werden. Alternativ können sie auch von der Festplatte aus angewendet werden, wohin Änderungen geschrieben werden, wenn sie nicht im Arbeitsspeicher gehalten werden können.
+ Nachdem die zwischengespeicherten Änderungen übernommen wurden, wird standardmäßig ein transaktionaler Apply-Prozess auf der Zielinstanz AWS DMS gestartet.
AWS DMS Verwendet während der Phase der angewendeten zwischengespeicherten Änderungen und der Phase der laufenden Replikationen zwei Stream-Puffer, jeweils einen für eingehende und ausgehende Daten. AWS DMS verwendet außerdem eine wichtige Komponente, den sogenannten *Sorter, bei dem es sich um einen weiteren Speicherpuffer* handelt. Im Folgenden sind zwei wichtige Anwendungen der Sorter-Komponente beschrieben (es gibt noch andere):
+ Er verfolgt alle Transaktionen und stellt sicher, dass er nur relevante Transaktionen in den Ausgangspuffer weiterleitet.
+ Es stellt sicher, dass Transaktionen in der gleichen Commit-Reihenfolge wie auf der Quelle weitergeleitet werden.
Wie Sie sehen, haben wir drei wichtige Speicherpuffer in dieser Architektur für CDC in AWS DMS. Wenn einer dieser Puffer unter Speicherdruck steht, kann es bei der Migration zu Leistungsproblemen kommen, die zu Ausfällen führen können.
Wenn Sie hohe Workloads mit einer hohen Anzahl von Transaktionen pro Sekunde (TPS) in diese Architektur einbinden, finden Sie möglicherweise den zusätzlichen Speicher nützlich, der von R5- und R6i-Instances zur Verfügung gestellt wird. Sie können R5- und R6i-Instances verwenden, um eine große Anzahl von Transaktionen im Speicher zu halten und Speicherdruckprobleme bei laufenden Replikationen zu vermeiden.
## Arbeiten mit dem unbegrenzten Modus für Burstable Performance Instances
Eine als `unlimited` konfigurierte Burstable Performance Instance, wie etwa eine T3-Instance, kann eine hohe CPU-Auslastung je nach Bedarf in jedem erforderlichen Zeitraum aufrechterhalten. Der stündliche Preis für die Instance kann automatisch alle CPU-Auslastungsspitzen abdecken. Dies geschieht, wenn die durchschnittliche CPU-Nutzung der Instance in einem fortlaufendem 24-Stunden-Zeitraum oder über die Lebensdauer der Instance hinweg (es gilt der jeweils kürzere Zeitraum) bei oder unterhalb der Baseline liegt.
Für die meisten allgemeinen Workloads bieten als `unlimited` konfigurierte Instances ausreichend Leistung ohne zusätzliche Gebühren. Wenn die Instance für einen längeren Zeitraum mit einer höheren CPU-Nutzung ausgeführt wird, kann sie dies zu einer pauschalen Zusatzgebühr pro vCPU-Stunde tun. Informationen zu den Preisen für T3-Instances finden Sie unter „T3-CPU-Credits“ in [AWS Database Migration Service](https://aws.amazon.com/dms/pricing/).
Weitere Informationen zum `unlimited` Modus für T3-Instances finden Sie unter [Unbegrenzter Modus für Burstable-Performance-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
**Wichtig**
Wenn Sie eine `dms.t3.micro` Instance im Rahmen des [AWS Free Tier](https://aws.amazon.com/free/)-Angebots verwenden und sie im `unlimited`-Modus verwenden, können Gebühren anfallen. Insbesondere können Gebühren anfallen, wenn Ihre durchschnittliche Auslastung in einem fortlaufendem 24-Stunden-Zeitraum die Basisauslastung der Instance überschreitet. Weitere Informationen finden Sie unter [Basisauslastung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html#baseline_performance) im *Amazon EC2 EC2-Benutzerhandbuch*.
T3-Instances werden standardmäßig als `unlimited` gestartet. Wenn die durchschnittliche CPU-Auslastung über einen Zeitraum von 24 Stunden den Basiswert überschreitet, werden ebenso Gebühren für überschüssiges Guthaben anfallen. In einigen Fällen können Sie T3-Spot-Instances als `unlimited` starten und planen, sie sofort und für eine kurze Dauer zu verwenden. Wenn Sie dies ohne Leerlaufzeit für die Anrechnung von CPU-Guthaben tun, entstehen Gebühren für überschüssiges Guthaben. Wir empfehlen Ihnen, Ihre T3-Spot-Instances im Standardmodus zu starten, um höhere Kosten zu vermeiden. Weitere Informationen finden Sie unter [Überschüssiges Guthaben, für das Gebühren anfallen können](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html#unlimited-mode-surplus-credits), [T3-Spot-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html#t3-spot-instances) und [Standardmodus für Burstable-Performance-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
# Auswahl der besten Größe für eine Replikations-Instance
Die Wahl der geeigneten Replikations-Instance hängt von mehreren Faktoren ab, die sich auf Ihren Anwendungsfall beziehen. Um zu verstehen, wie die Replikations-Instance-Ressourcen verwendet werden, lesen Sie die folgende Diskussion. Sie deckt das übliche Szenario einer Volllast \$1 CDC-Aufgabe ab.
AWS DMS Lädt während einer Aufgabe zum vollständigen Laden die Tabellen einzeln. Standardmäßig werden acht Tabellen gleichzeitig geladen. AWS DMS erfasst laufende Änderungen an der Quelle während einer Aufgabe zum vollständigen Laden, sodass die Änderungen später auf dem Zielendpunkt angewendet werden können. Die Änderungen werden zwischengespeichert. Wenn der verfügbare Arbeitsspeicher erschöpft ist, werden die Änderungen auf der Festplatte zwischengespeichert. Wenn eine Vollladeaufgabe für eine Tabelle abgeschlossen ist, AWS DMS werden die zwischengespeicherten Änderungen sofort auf die Zieltabelle angewendet.
Nachdem alle ausstehenden zwischengespeicherten Änderungen für eine Tabelle übernommen wurden, befindet sich der Ziel-Endpunkt in einem transaktionskonsistenten Status. Zu diesem Zeitpunkt ist das Ziel in Bezug auf die letzten zwischengespeicherten Änderungen mit dem Quellendpunkt synchron. AWS DMS beginnt dann mit der laufenden Replikation zwischen der Quelle und dem Ziel. Dazu werden die AWS DMS Änderungsvorgänge aus den Quelltransaktionsprotokollen übernommen und auf transaktionskonsistente Weise auf das Ziel angewendet. (Bei diesem Vorgang wird davon ausgegangen, dass die Option „Batch-optimiert anwenden“ nicht ausgewählt ist). AWS DMS streamt laufende Änderungen nach Möglichkeit durch den Speicher der Replikationsinstanz. Andernfalls werden Änderungen auf die Festplatte der Replikationsinstanz AWS DMS geschrieben, bis sie auf das Ziel angewendet werden können.
Sie haben eine gewisse Kontrolle darüber, wie die Replikations-Instance die Änderungsverarbeitung handhabt und wie der Arbeitsspeicher bei diesem Prozess verwendet wird. Weitere Informationen zur Optimierung der Änderungsverarbeitung finden Sie unter [Einstellungen für die Optimierung der Verarbeitung von Änderungen](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
## Zu berücksichtigende Faktoren
Arbeitsspeicher und Festplattenspeicher sind wichtige Faktoren bei der Auswahl einer geeigneten Replikations-Instance für Ihren Anwendungsfall. Im Folgenden finden Sie eine Beschreibung der Anwendungsfallmerkmale, die analysiert werden müssen, um eine Replikations-Instance auszuwählen.
+ Datenbank- und Tabellengröße
Das Daten-Volume hilft bei der Bestimmung der Aufgabenkonfiguration, um die Leistung bei Volllast zu optimieren. Beispielsweise können Sie für zwei 1-TB-Schemata Tabellen in vier Aufgaben mit 500 GB partitionieren und diese parallel ausführen. Die mögliche Parallelität hängt von der CPU-Ressource ab, die in der Replikations-Instance verfügbar ist. Aus diesem Grund ist es eine gute Idee, die Größe Ihrer Datenbank und Ihrer Tabellen zu kennen, um die Leistung bei Volllast zu optimieren. Dies hilft, die Anzahl der Aufgaben zu bestimmen, die Sie möglicherweise haben können.
+ Große Objekte
Die Datentypen, die in Ihrem Migrationsbereich vorhanden sind, können sich auf die Leistung auswirken. Insbesondere große Objekte (LOBs) wirken sich auf Leistung und Speicherverbrauch aus. AWS DMS Führt einen zweistufigen Prozess durch, um einen LOB-Wert zu migrieren. AWS DMS Fügt zunächst die Zeile ohne den LOB-Wert in das Ziel ein. Zweitens AWS DMS aktualisiert die Zeile mit dem LOB-Wert. Dies hat Auswirkungen auf den Speicher. Daher ist es wichtig, die LOB-Spalten an der Quelle zu identifizieren und ihre Größe zu analysieren.
+ Ladefrequenz und Transaktionsgröße
Ladefrequenz und Transaktionen pro Sekunde (TPS) beeinflussen die Speichernutzung. Eine hohe Anzahl von TPS- oder DML-Aktivitäten (Data Manipulation Language) führt zu einer hohen Speicherauslastung. Dies geschieht, weil DMS die Änderungen zwischenspeichert, bis sie auf das Ziel angewendet werden. Während des CDC-Vorgangs führt dies zu Swapping (Schreiben auf die physische Festplatte aufgrund eines Speicherüberlaufs), was zu Latenz führt.
+ Tabellenschlüssel und referenzielle Integrität
Informationen zu den Schlüsseln der Tabelle bestimmen den CDC-Modus (Batch Apply oder Transactional Apply), den Sie für die Datenmigration verwenden. Im Allgemeinen ist Transactional Apply langsamer als Batch Apply. Bei Transaktionen mit langer Laufzeit müssen möglicherweise viele Änderungen migriert werden. Wenn Sie transactional apply verwenden, ist AWS DMS möglicherweise mehr Speicher zum Speichern der Änderungen erforderlich als beim Batch-Anwenden. Wenn Sie Tabellen ohne Primärschlüssel migrieren, schlägt Batch Apply fehl und die DMS-Aufgabe wechselt in den Transactional-Apply-Modus. Wenn die referenzielle Integrität zwischen Tabellen während CDC aktiviert ist, AWS DMS verwendet standardmäßig transactional apply. Weitere Informationen zu Batch Apply im Vergleich zu Transactional Apply finden Sie unter [Wie kann ich das DMS-Batch-Apply-Feature verwenden, um die CDC-Replikationsleistung zu verbessern?](https://aws.amazon.com/premiumsupport/knowledge-center/dms-batch-apply-cdc-replication/).
Ermitteln Sie anhand dieser Metriken, ob die Replikations-Instance datenverarbeitungs- oder speicheroptimiert sein muss.
## Häufige Probleme
Möglicherweise stoßen Sie während der Migration auf die folgenden häufigen Probleme, die zu Ressourcenkonflikten auf der Replikations-Instance führen. Weitere Informationen zu Metriken für Replikations-Instances finden Sie unter [Metriken zur Replikations-Instance](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.CloudWatch).
+ Wenn der Arbeitsspeicher in einer Replikations-Instance nicht mehr ausreicht, führt dies dazu, dass Daten auf die Festplatte geschrieben werden. Das Lesen von der Festplatte kann zu Latenz führen, die Sie vermeiden können, indem Sie die Größe der Replikations-Instance mit ausreichend Arbeitsspeicher ausstatten.
+ Die der Replikations-Instance zugewiesene Festplattengröße kann kleiner als erforderlich sein. Die Festplattengröße wird verwendet, wenn Daten im Speicher überlaufen. Sie wird auch zum Speichern der Aufgabenprotokolle verwendet. Der maximale IOPS-Wert hängt ebenfalls davon ab.
+ Das Ausführen mehrerer Aufgaben oder von Aufgaben mit hoher Parallelität wirkt sich auf die CPU-Auslastung der Replikations-Instance aus. Dies verlangsamt die Verarbeitung der Aufgaben und führt zu Latenz.
## Best Practices
Beachten Sie bei der Dimensionierung einer Replikations-Instance diese beiden gängigsten bewährten Methoden. Weitere Informationen finden Sie unter [Bewährte Verfahren für AWS Database Migration Service](CHAP_BestPractices.md).
1. Definieren Sie Ihren Workload und finden Sie heraus, ob er computing- oder speicherintensiv ist. Auf dieser Grundlage können Sie die Klasse und Größe der Replikations-Instance bestimmen:
+ AWS DMS Prozesse im Speicher. LOBs Dieser Vorgang benötigt eine beträchtliche Menge an Arbeitsspeicher.
+ Die Anzahl der Aufgaben und die Anzahl der Threads wirken sich auf die CPU-Auslastung aus. Vermeiden Sie es, während des Volllastvorgangs mehr als acht `MaxFullLoadSubTasks` zu verwenden.
1. Erhöhen Sie den der Replikations-Instance zugewiesenen Festplattenspeicher, wenn Sie bei Volllast einen hohen Workload haben. Auf diese Weise kann die Replikations-Instance den ihr zugewiesenen maximalen IOPS-Wert verwenden.
Die vorangegangenen Richtlinien decken nicht alle möglichen Szenarien ab. Es ist sehr wichtig, die Besonderheiten Ihres speziellen Anwendungsfalls zu berücksichtigen, wenn Sie die Größe Ihrer Replikations-Instance bestimmen.
Die vorherigen Tests haben gezeigt, dass CPU und Arbeitsspeicher je nach Workload variieren. Insbesondere LOBs wirken sie sich auf den Arbeitsspeicher aus, und die Anzahl der Aufgaben oder die Parallelität wirken sich auf die CPU aus. Nachdem die Migration gestartet wurde, überwachen Sie die Werte für CPU, freigebbaren Arbeitsspeicher, freien Speicherplatz und E/A-Leistung pro Sekunde Ihrer Replikations-Instance. Basierend auf den Daten, die Sie erfassen, können Sie Ihre Replikations-Instance nach Bedarf vergrößern oder verkleinern.
# Arbeiten mit Versionen der Replikations-Engine
Die *Replication Engine* ist die AWS DMS Kernsoftware, die auf Ihrer Replikationsinstanz ausgeführt wird und die von Ihnen angegebenen Migrationsaufgaben ausführt. AWS veröffentlicht regelmäßig neue Versionen der AWS DMS Replication Engine-Software mit neuen Funktionen und Leistungsverbesserungen. Jede Version der Replikations-Engine-Software verfügt über eine eigene Versionsnummer, um sie von anderen Versionen zu unterscheiden.
Wenn Sie eine neue Replikationsinstanz starten, wird auf ihr die neueste AWS DMS Engine-Version ausgeführt, sofern Sie nichts anderes angeben. Weitere Informationen finden Sie unter [Mit einer AWS DMS Replikationsinstanz arbeiten](CHAP_ReplicationInstance.md).
Wenn Sie eine Replikationsinstanz haben, die gerade läuft, können Sie sie auf eine neuere Engine-Version aktualisieren. (unterstützt AWS DMS keine Downgrades der Engine-Version.) Weitere Informationen zu Versionen des Replikationsmoduls finden Sie unter [AWS DMS-Versionshinweise](CHAP_ReleaseNotes.md).
## Aktualisieren der Engine-Version über die Konsole
Sie können eine AWS DMS Replikationsinstanz mit dem AWS-Managementkonsole aktualisieren.
**So aktualisieren Sie eine Replikations-Instance über die Konsole**
1. Öffnen Sie die AWS DMS Konsole auf [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Wählen Sie im Navigationsbereich **Replication instances (Replikations-Instances)** aus.
1. Wählen Sie Ihre Replikations-Engine aus und klicken Sie dann auf **Modify**.
1. Wählen Sie im Feld **Engine-Version** die Versionsnummer aus, die Sie suchen, und klicken Sie anschließend auf **Ändern**.
**Anmerkung**
Wir empfehlen, dass Sie alle Aufgaben beenden, bevor Sie die Replikations-Instance aktualisieren. Wenn Sie die Aufgabe nicht beenden, AWS DMS wird sie vor dem Upgrade automatisch beendet. Wenn Sie die Aufgabe manuell anhalten, müssen Sie die Aufgabe nach Abschluss des Upgrades manuell starten. Das Aktualisieren der Replikations-Instance dauert einige Minuten. Sobald die Instance bereit ist, ändert sich ihr Status zu **available**.
## Aktualisierung der Engine-Version mit dem AWS CLI
Sie können eine AWS DMS Replikationsinstanz wie folgt mit dem AWS CLI aktualisieren.
**Um eine Replikationsinstanz zu aktualisieren, verwenden Sie den AWS CLI**
1. Bestimmen Sie den Amazon-Ressourcennamen (ARN) Ihrer Replikations-Instance anhand des folgenden Befehls.
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceArn,ReplicationInstanceClass]"
```
Beachten Sie in der Ausgabe den ARN für die Replikations-Instance, die Sie aktualisieren möchten, beispielsweise: `arn:aws:dms:us-east-1:123456789012:rep:6EFQQO6U6EDPRCPKLNPL2SCEEY`
1. Bestimmen Sie, welche Replikations-Instance-Versionen verfügbar sind, anhand des folgenden Befehls.
```
aws dms describe-orderable-replication-instances \
--query "OrderableReplicationInstances[*].[ReplicationInstanceClass,EngineVersion]"
```
Beachten Sie in der Ausgabe die Engine-Versionsnummer(n), die für Ihre Replikations-Instance-Klasse verfügbar ist/sind. Sie sollten diese Informationen in der Ausgabe von Schritt 1 sehen.
1. Aktualisieren Sie die Replikations-Instance anhand des folgenden Befehls.
```
aws dms modify-replication-instance \
--replication-instance-arn arn \
--engine-version n.n.n
```
Ersetzen Sie *arn* den vorherigen durch den tatsächlichen ARN der Replikationsinstanz aus dem vorherigen Schritt.
*n.n.n *Ersetzen Sie es durch die gewünschte Engine-Versionsnummer, zum Beispiel: `3.4.5`
**Anmerkung**
Das Aktualisieren der Replikations-Instance dauert einige Minuten. Sie können den Replikations-Instance-Status mit dem folgenden Befehl anzeigen.
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceStatus]"
```
Sobald die Replikations-Instance bereit ist, ändert sich ihr Status zu **available**.
# Öffentliche und private Replikations-Instances
Sie können festlegen, ob eine Replikations-Instance eine öffentliche oder private IP-Adresse hat, die von der Instance verwendet wird, um eine Verbindung mit der Quell- und Zieldatenbank herzustellen.
Eine *private Replikations-Instance* verfügt über eine private IP-Adresse, auf die Sie von außerhalb des Replikationsnetzwerks nicht zugreifen können. Sie verwenden eine private Instance, wenn sich sowohl Quell- als auch Zieldatenbanken in demselben Netzwerk befinden, das mit der Virtual Private Cloud (VPC) der Replikations-Instance verbunden ist. Das Netzwerk kann über ein virtuelles privates Netzwerk (VPN) oder VPC-Peering mit der VPC verbunden werden. Direct Connect
Eine *VPC-Peering-Verbindung* ist eine Netzwerkverbindung zwischen zwei. VPCs Dies ermöglicht das Routing unter Verwendung der privaten IP-Adressen jeder VPC, als ob sie sich im selben Netzwerk befinden würden. Weitere Informationen zu VPC Peering finden Sie unter [VPC Peering](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) im *Amazon VPC Benutzerhandbuch*.
Eine *öffentliche Replikations-Instance* kann die VPC-Sicherheitsgruppe der Replikations-Instance und die öffentliche IP-Adresse der Replikations-Instance oder die öffentliche IP-Adresse des NAT-Gateways verwenden. Diese Verbindungen bilden ein Netzwerk, das Sie für die Datenmigration nutzen.
# IP-Adressierung und Netzwerktypen
AWS DMS erstellt Ihre Replikationsinstanz immer in einer Amazon Virtual Private Cloud (VPC). Wenn Sie Ihre VPC erstellen, können Sie die zu verwendende IP-Adressierung festlegen: entweder IPv4 oder IPv6 oder beides. Wenn Sie dann eine Replikationsinstanz erstellen oder ändern, können Sie die Verwendung eines IPv4 Adressprotokolls oder eines IPv6 Adressprotokolls im *Dual-Stack-Modus* angeben.
**IPv4 Adressen**
Wenn Sie eine VPC erstellen, können Sie einen IPv4 Adressbereich für die VPC in Form eines CIDR-Blocks (Classless Inter-Domain Routing) angeben, z. B. 10.0.0.0/16. Eine Subnetzgruppe definiert den Bereich der IP-Adressen in diesem CIDR-Block. Diese IP-Adressen können privat oder öffentlich sein.
Eine private IPv4-Adresse ist eine IP-Adresse, die nicht über das Internet erreichbar ist. Sie können private IPv4-Adressen zur Kommunikation zwischen Ihrer Replikations-Instance und anderen Ressourcen, wie Amazon-EC2-Instances, in derselben VPC verwenden. Jede Replikations-Instance hat eine private IP-Adresse für die Kommunikation in der VPC.
Eine öffentliche IP-Adresse ist eine Adresse, die über das Internet erreichbar ist IPv4 . Sie können öffentliche Adressen zur Kommunikation zwischen Ihrer Replikations-Instance und Ressourcen im Internet verwenden. Sie können kontrollieren, ob Ihre Replikations-Instance eine öffentliche IP-Adresse erhält
**Dual-Stack-Modus und Adressen IPv6 **
Wenn Sie über Ressourcen verfügen, die mit Ihrer Replikationsinstanz kommunizieren müssen IPv6, verwenden Sie den *Dual-Stack-Modus*. Um den Dual-Stack-Modus zu verwenden, stellen Sie sicher, dass jedem Subnetz in der Subnetzgruppe, die Sie der Replikationsinstanz zuordnen, ein IPv6 CIDR-Block zugeordnet ist. Sie können eine neue Replikations-Subnetzgruppe erstellen oder eine vorhandene Replikations-Subnetzgruppe ändern, um diese Anforderung zu erfüllen. Jede IPv6 Adresse ist weltweit einzigartig. Der IPv6 CIDR-Block für Ihre VPC wird automatisch aus dem Amazon-Adresspool zugewiesen. IPv6 Sie können den Bereich nicht selbst auswählen.
DMS deaktiviert den Internet-Gateway-Zugriff für IPv6 Endpunkte von privaten Replikationsinstanzen im Dual-Stack-Modus. DMS tut dies, um sicherzustellen, dass Ihre IPv6 Endpoints privat sind und nur von Ihrer VPC aus darauf zugegriffen werden kann.
**Sie können die AWS DMS Konsole verwenden, um eine Replikationsinstanz zu erstellen oder zu ändern, und im Abschnitt Netzwerktyp den Dual-Stack-Modus angeben.** Die folgende Abbildung zeigt den Abschnitt **Network type** (Netzwerktyp) in der Konsole.
![\[AWS Netzwerktyp des Database Migration Service\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-network-type.png)
**Referenzen**
+ Modusinformationen zu IPv4 und IPv6 Adressen finden Sie unter [IP-Adressierung](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#vpc-ip-addressing) im *Amazon VPC-Benutzerhandbuch*.
+ Weitere Hinweise zum Erstellen einer Replikations-Instance im Dual-Stack-Modus finden Sie unter [Erstellen einer Replikations-Instance](CHAP_ReplicationInstance.Creating.md).
+ Weitere Informationen zum Ändern einer Replikations-Instance finden Sie unter [Ändern einer Replikations-Instance](CHAP_ReplicationInstance.Modifying.md).
# Einrichten eines Netzwerks für eine Replikations-Instance
AWS DMS erstellt die Replikationsinstanz immer in einer VPC, die auf Amazon VPC basiert. Geben Sie die VPC an, in der sich Ihre Replikations-Instance befindet. Sie können Ihre Standard-VPC für Ihr Konto und Ihre AWS Region verwenden oder eine neue VPC erstellen.
Stellen Sie sicher, dass das für die VPC Ihrer Replikations-Instance zugewiesene Elastic Network Interface einer Sicherheitsgruppe zugeordnet ist. Stellen Sie außerdem sicher, dass die Regeln dieser Sicherheitsgruppe zulassen, dass der gesamte Datenverkehr auf allen Ports die VPC verlässt (ausgehender Datenverkehr). Dieser Ansatz ermöglicht die Kommunikation von der Replikations-Instance zu Ihren Quell- und Zieldatenbankendpunkten, sofern auf den Endpunkten die korrekten Eingangsregeln aktiviert sind. Wir empfehlen, die Standardeinstellungen für die Endpunkte zu verwenden. Diese erlauben ausgehenden Zugriff auf allen Ports für alle Adressen.
Die Quell- und Zielendpunkte greifen auf die Replikations-Instance zu, die sich in der VPC befindet, indem sie sich entweder mit der VPC verbinden oder sich selbst innerhalb der VPC befinden. Die Datenbank-Endpoints müssen Netzwerkzugriffskontrolllisten (ACLs) und Sicherheitsgruppenregeln (falls zutreffend) enthalten, die eingehenden Zugriff von der Replikationsinstanz ermöglichen. Wie Sie dies einrichten, hängt von der verwendeten Netzwerkkonfiguration ab. Sie können die VPC-Sicherheitsgruppe der Replikations-Instance, die private oder öffentliche IP-Adresse der Replikations-Instance oder die öffentliche IP-Adresse des NAT-Gateways verwenden. Diese Verbindungen bilden ein Netzwerk, das Sie für die Datenmigration nutzen.
**Anmerkung**
Da sich eine IP-Adresse aufgrund von Änderungen an der zugrunde liegenden Infrastruktur ändern kann, empfehlen wir Ihnen, einen VPC-CIDR-Bereich zu verwenden oder den ausgehenden Datenverkehr Ihrer Replikations-Instance über eine mit NAT GW verknüpfte Elastic IP weiterzuleiten. Weitere Informationen zum Erstellen einer VPC, einschließlich eines CIDR-Blocks, finden Sie unter [Arbeiten mit VPCs und Subnetzen](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html) im *Amazon Virtual Private Cloud Cloud-Benutzerhandbuch*. Weitere Informationen zu Elastic IP-Adressen finden Sie im *Amazon-Elastic-Compute-Cloud-Benutzerhandbuch* unter [Elastic IP-Adressen](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-ip-addresses-eip.html).
## Netzwerkkonfigurationen für die Datenbankmigration
Sie können mehrere verschiedene Netzwerkkonfigurationen mit AWS Database Migration Service verwenden. Im Folgenden werden einige häufige Konfigurationen für ein Netzwerk erörtert, die für die Datenbankmigration verwendet werden.
**Topics**
+ [Konfiguration mit allen Datenbankmigrationskomponenten in einer VPC](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioAllVPC)
+ [Konfiguration mit mehreren VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCPeer)
+ [Konfiguration mit gemeinsam genutzter VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCShared)
+ [Konfiguration für ein Netzwerk zu einer VPC unter Verwendung Direct Connect eines VPN](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioDirect)
+ [Konfiguration für ein Netzwerk zu einer VPC über das Internet](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioInternet)
+ [Konfiguration mit einer RDS-DB-Instance, die sich nicht in einer VPC befindet, zu einer DB-Instance in einer VPC mit ClassicLink](#CHAP_ReplicationInstance.VPC.Configurations.ClassicLink)
+ [Konfiguration für ein Netzwerk, das eine Verbindung zu AWS Diensten herstellt](#CHAP_ReplicationInstance.VPC.Configurations.networkconnecting)
+ [Konfiguration für ein Netzwerk, das über VPC-Endpunkte eine Verbindung zu AWS Diensten herstellt](#CHAP_ReplicationInstance.VPC.Configurations.vpcendpoints)
+ [Konfiguration für ein Netzwerk, das über das Internet eine Verbindung zu Diensten AWS herstellt](#CHAP_ReplicationInstance.VPC.Configuration.networkconnectingusinginternet)
Wenn möglich, empfehlen wir, dass Sie eine DMS-Replikations-Instance in derselben Region wie Ihr Zielendpunkt und in derselben VPC oder demselben Subnetz wie Ihr Zielendpunkt erstellen.
### Konfiguration mit allen Datenbankmigrationskomponenten in einer VPC
Die einfachste Netzwerkkonfiguration für die Datenbankmigration besteht darin, dass sich Quellendpunkt, Replikations-Instance und Zielendpunkt alle in derselben VPC befinden. Diese Konfiguration eignet sich, wenn sich Ihre Quell- und Zielendpunkte auf einer Amazon-RDS-DB-Instance oder einer Amazon-EC2-Instance befinden.
Die folgende Abbildung zeigt eine Konfiguration, bei der sich eine Datenbank auf einer Amazon EC2-Instance mit der Replikations-Instance verbindet und die Daten zu einer Amazon RDS-DB-Instance migriert werden.
![\[AWS Database Migration Service Alles in einem VPC-Beispiel\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-scenarioAllVPC.png)
Die VPC-Sicherheitsgruppe, die in dieser Konfiguration verwendet wird, muss eingehenden Zugriff am Datenbank-Port von der Replikations-Instance erlauben. Dafür stehen Ihnen mehrere Optionen zur Verfügung. Stellen Sie sicher, dass die von der Replikations-Instance verwendete Sicherheitsgruppe Zugang zu den Endpunkten hat. Oder Sie können den VPC-CIDR-Bereich, NAT GW Elastic IP oder die private IP-Adresse der Replikations-Instance zulassen, falls Sie eine verwenden. Wir empfehlen jedoch nicht, die private IP-Adresse der Replikations-Instance zu verwenden, da dies Ihre Replikation unterbrechen kann, wenn sich die Replikations-IP-Adresse ändert.
### Konfiguration mit mehreren VPCs
Wenn sich Ihr Quellendpunkt und Ihr Zielendpunkt unterscheiden VPCs, können Sie Ihre Replikationsinstanz in einem der VPCs beiden erstellen. Sie können die beiden dann mithilfe VPCs von VPC-Peering verknüpfen.
Eine VPC-Peering-Verbindung ist eine Netzwerkverbindung zwischen zwei VPCs , die das Routing unter Verwendung der privaten IP-Adressen jeder VPC ermöglicht, als ob sie sich im selben Netzwerk befinden würden. Sie können eine VPC-Peering-Verbindung zwischen Ihrer eigenen VPCs, mit einer VPC in einem anderen AWS Konto oder mit einer VPC in einer anderen Region herstellen. AWS Weitere Informationen zu VPC Peering finden Sie unter [VPC Peering](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) im *Amazon VPC Benutzerhandbuch*.
Die folgende Abbildung zeigt eine Beispielkonfiguration unter Verwendung von VPC-Peering. Hier wird die Quell-Datenbank auf einer Amazon-EC2-Instance in einer VPC über VPC-Peering mit einer VPC verbunden. Diese VPC enthält die Replikations-Instance und die Zieldatenbank auf einer Amazon-RDS-DB-Instance.
![\[AWS Replikationsinstanz des Datenbankmigrationsdienstes\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-scenarioVPCPeer.png)
Um VPC-Peering zu implementieren, folgen Sie den Anweisungen unter [Arbeiten mit VPC-Peering-Verbindungen](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html) in der Dokumentation *Amazon Virtual Private Cloud, VPC Peering*. Stellen Sie sicher, dass die Routing-Tabelle einer VPC den CIDR-Block der anderen enthält. Wenn VPC A beispielsweise das Ziel 10.0.0.0/16 und VPC B das Ziel 172.31.0.0 verwendet, sollte die Routing-Tabelle von VPC A 172.31.0.0 enthalten und die Routing-Tabelle von VPC B muss 10.0.0.0/16 enthalten. Ausführlichere Informationen finden Sie unter [Aktualisieren Ihrer Routing-Tabellen für VPC-Peering-Verbindungen](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html) in der Dokumentation *Amazon Virtual Private Cloud, VPC-Peering*.
Die VPC-Sicherheitsgruppen, die in dieser Konfiguration verwendet werden, müssen eingehenden Zugriff am Datenbank-Port von der Replikations-Instance oder den Eingang auf dem CIDR-Block für die VPC für das Peering zulassen.
### Konfiguration mit gemeinsam genutzter VPCs
AWS DMS behandelt Subnetze, die für ein teilnehmendes Kundenkonto in einer Organisation gemeinsam genutzt werden, genauso wie reguläre Subnetze in demselben Konto. Im Folgenden finden Sie eine Beschreibung der AWS DMS Handles VPCs und Subnetze sowie der Verwendungsmöglichkeiten von Shared. VPCs
Sie können Ihre Netzwerkkonfiguration so konfigurieren, dass sie in benutzerdefinierten Subnetzen funktioniert oder VPCs indem Sie Objekte erstellen`ReplicationSubnetGroup`. Wenn Sie eine `ReplicationSubnetGroup` erstellen, können Sie wählen, ob Sie Subnetze von einer bestimmten VPC in Ihrem Konto angeben möchten. Die Liste der von Ihnen angegebenen Subnetze muss mindestens zwei Subnetze enthalten, die sich in separaten Availability Zones befinden, und alle Subnetze müssen sich in derselben VPC befinden. Beim Erstellen eines `ReplicationSubnetGroup` geben Kunden nur Subnetze an. AWS DMS bestimmt die VPC in Ihrem Namen, da jedes Subnetz mit genau einer VPC verknüpft ist.
Wenn Sie eine AWS DMS `ReplicationInstance` oder eine erstellen, können Sie wählen AWS DMS `ReplicationConfig`, ob Sie `ReplicationSubnetGroup` and/or eine VPC-Sicherheitsgruppe angeben möchten, in der die `ReplicationInstance` oder die serverlose Replikation ausgeführt wird. Falls nicht angegeben, AWS DMS wählt der Kundenstandard `ReplicationSubnetGroup` (der in Ihrem Namen AWS DMS erstellt wird, falls nicht für alle Subnetze in der Standard-VPC angegeben) und die Standard-VPC-Sicherheitsgruppe.
Sie können wählen, ob Sie Ihre Migrationen in einer von Ihnen angegebenen Availability Zone oder in einer der Availability Zones in Ihrer `ReplicationSubnetGroup` ausführen möchten. Wenn AWS DMS versucht wird, eine Replikationsinstanz zu erstellen oder eine serverlose Replikation zu starten, werden die Verfügbarkeitszonen Ihrer Subnetze in Verfügbarkeitszonen im Hauptdienstkonto übersetzt, um sicherzustellen, dass wir Instances in der richtigen Availability Zone starten, auch wenn die Availability Zone-Zuordnungen zwischen den beiden Konten nicht identisch sind.
Wenn Sie eine gemeinsam genutzte VPC verwenden, müssen Sie sicherstellen, dass Sie `ReplicationSubnetGroup`-Objekte erstellen, die den Subnetzen zugeordnet sind, die Sie von einer gemeinsam genutzten VPC aus verwenden möchten. Wenn Sie eine `ReplicationInstance` oder eine `ReplicationConfig` erstellen, müssen Sie eine `ReplicationSubnetGroup` für die gemeinsam genutzte VPC und eine VPC-Sicherheitsgruppe angeben, die Sie für Ihre gemeinsam genutzte VPC mit Ihrer Create-Anfrage erstellt haben.
Beachten Sie Folgendes im Zusammenhang mit der Verwendung einer gemeinsam genutzten VPC:
+ Der VPC-Eigentümer kann keine Ressource für einen Teilnehmer freigeben, aber der Teilnehmer kann eine Serviceressource im Subnetz des Eigentümers erstellen.
+ Der VPC-Eigentümer kann nicht auf eine Ressource (z. B. eine Replikations-Instance) zugreifen, die der Teilnehmer erstellt, da alle Ressourcen kontospezifisch sind. Solange Sie die Replikations-Instance jedoch in der gemeinsam genutzten VPC erstellen, kann sie unabhängig vom Eigentümerkonto auf die Ressourcen in der VPC zugreifen, sofern der Replikationsendpunkt oder die Aufgabe über die korrekten Berechtigungen verfügte.
+ Da Ressourcen kontospezifisch sind, können andere Teilnehmer nicht auf Ressourcen zugreifen, die anderen Konten gehören. Es gibt keine Berechtigungen, die Sie anderen Konten erteilen können, damit sie auf Ressourcen zugreifen können, die in der gemeinsam genutzten VPC mit Ihrem Konto erstellt wurden.
### Konfiguration für ein Netzwerk zu einer VPC unter Verwendung Direct Connect eines VPN
Remote-Netzwerke können über verschiedene Optionen wie AWS Direct Connect oder eine Software- oder Hardware-VPN-Verbindung eine Verbindung zu einer VPC herstellen. Diese Optionen werden oft verwendet, um lokale Services zu integrieren, wie beispielsweise Überwachung, Authentifizierung, Sicherheit, Daten oder andere Systeme, indem ein internes Netzwerk in die AWS Cloud erweitert wird. Mit dieser Art von Netzwerkerweiterung können Sie problemlos eine Verbindung mit von AWS gehosteten Ressourcen wie einer VPC herstellen.
Die folgende Abbildung zeigt eine Konfiguration, bei der der Quellendpunkt eine lokale Datenbank in einem firmeneigenen Rechenzentrum ist. Die Verbindung erfolgt über Direct Connect oder ein VPN mit einer VPC, die die Replikations-Instance und eine Zieldatenbank auf einer Amazon-RDS-DB-Instance enthält.
![\[AWS Replikationsinstanz des Datenbankmigrationsdienstes\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-scenarioDirect.png)
Bei dieser Konfiguration muss die VPC-Sicherheitsgruppe eine Routing-Regel enthalten, die den für einen VPC-CIDR-Bereich oder eine spezifische IP-Adresse bestimmten Datenverkehr an einen Host sendet. Dieser Host muss dazu in der Lage sein, den von der VPC kommenden Datenverkehr in ein lokales VPN weiterzuleiten. In diesem Fall enthält der NAT-Host seine eigenen Sicherheitsgruppeneinstellungen. Diese Einstellungen müssen Datenverkehr aus dem VPC-CIDR-Bereich, der privaten IP-Adresse oder der Sicherheitsgruppe der Replikations-Instance in die NAT-Instance zulassen. Wir empfehlen jedoch nicht, die private IP-Adresse der Replikations-Instance zu verwenden, da dies Ihre Replikation unterbrechen kann, wenn sich die Replikations-IP-Adresse ändert.
### Konfiguration für ein Netzwerk zu einer VPC über das Internet
Wenn Sie kein VPN verwenden oder keine Verbindung Direct Connect zu AWS Ressourcen herstellen, können Sie Ihre Datenbank über das Internet migrieren. In diesem Fall können Sie entweder zu einer AmazonEC2-Instance oder einer Amazon-RDS-DB-Instance migrieren. Diese Konfiguration umfasst eine öffentliche Replikations-Instance in einer VPC mit einem Internet-Gateway, das den Zielendpunkt und die Replikations-Instance enthält.
![\[AWS Replikationsinstanz des Datenbankmigrationsdienstes\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-scenarioInternet.png)
Informationen zum Anfügen eines Internet-Gateways zu Ihrer VPC finden Sie unter [Anfügen eines Internet-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway) im *Amazon VPC Benutzerhandbuch*.
Die VPC-Routing-Tabelle muss Routing-Regeln enthalten, die den nicht für die VPC bestimmten Datenverkehr standardmäßig an das Internet-Gateway senden. Bei dieser Konfiguration stammt die Verbindung mit dem Endpunkt scheinbar von der öffentlichen IP-Adresse der Replikations-Instance und nicht von der privaten IP-Adresse. Weitere Informationen finden Sie unter [VPC-Routing-Tabellen](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) im *Amazon-VPC-Benutzerhandbuch*.
### Konfiguration mit einer RDS-DB-Instance, die sich nicht in einer VPC befindet, zu einer DB-Instance in einer VPC mit ClassicLink
| |
| --- |
| EC2-Classic wird am 15. August 2022 eingestellt. Wir empfehlen Ihnen die Migration von EC2-Classic zu einer VPC. Weitere Informationen finden Sie unter [Migration von EC2-Classic zu einer VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html) im Benutzerhandbuch für Amazon EC2 und im Blog [EC2-Classic Networking is Retiring – Here’s How to Prepare](https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-heres-how-to-prepare/) (EC2-Classic Networking geht in den Ruhestand – So bereiten Sie sich vor). |
Um eine Amazon RDS-DB-Instance, die sich nicht in einer VPC befindet, mit einem DMS-Replikationsserver und einer DB-Instance in einer VPC zu verbinden, können Sie sie ClassicLink mit einem Proxy-Server verwenden.
ClassicLink ermöglicht es Ihnen, eine EC2-Classic-DB-Instance mit einer VPC in Ihrem Konto innerhalb derselben Region zu verknüpfen. AWS Nachdem Sie die Verknüpfung erstellt haben, kann die DB-Quell-Instance mit der Replikations-Instance in der VPC über ihre privaten IP-Adressen kommunizieren.
Da die Replikationsinstanz in der VPC nicht direkt auf die Quell-DB-Instance auf der EC2-Classic-Plattform zugreifen kann ClassicLink, verwenden Sie einen Proxyserver. Der Proxy-Server verbindet die Quell-DB-Instance mit der VPC, die die Replikations-Instance und Ziel-DB-Instance enthält. Der Proxyserver verwendet ClassicLink , um eine Verbindung zur VPC herzustellen. Die Port-Weiterleitung auf dem Proxy-Server ermöglicht die Kommunikation zwischen der Quell-DB-Instance und der Ziel-DB-Instance in der VPC.
![\[AWS Database Migration Service mit ClassicLink\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-scenarioClassicLink.png)
#### Verwendung ClassicLink mit AWS Database Migration Service
Sie können eine Amazon RDS-DB-Instance, die sich nicht in einer VPC befindet, mit einem AWS DMS-Replikationsserver und einer DB-Instance verbinden, die sich in einer VPC befinden. Dazu können Sie Amazon EC2 ClassicLink mit einem Proxy-Server verwenden.
Das folgende Verfahren zeigt, wie Sie es ClassicLink für diesen Zweck verwenden. Dieses Verfahren verbindet eine Amazon RDS-Quell-DB-Instance, die sich nicht in einer VPC befindet, mit einer VPC, die eine AWS DMS-Replikations-Instance und eine Ziel-DB-Instance enthält.
+ Erstellen Sie eine AWS DMS-Replikationsinstanz in einer VPC. (Alle Replikationsinstanzen werden in VPCs erstellt.)
+ Verknüpfen Sie eine VPC-Sicherheitsgruppe mit der Replikations-Instance und der DB-Ziel-Instance. Wenn zwei Instances gemeinsam eine VPC-Sicherheitsgruppe verwenden, können sie standardmäßig miteinander kommunizieren.
+ Richten Sie einen Proxy-Server auf einer EC2-Classic-Instance ein.
+ Stellen Sie eine Verbindung ClassicLink zwischen dem Proxyserver und der VPC her.
+ Erstellen Sie AWS DMS-Endpunkte für die Quell- und Zieldatenbanken.
+ Erstellen Sie eine AWS DMS-Aufgabe.
**Wird verwendet, ClassicLink um eine Datenbank auf einer DB-Instance, die sich nicht in einer VPC befindet, zu einer Datenbank auf einer DB-Instance in einer VPC zu migrieren**
1. Erstellen Sie eine AWS DMS-Replikationsinstanz und weisen Sie eine VPC-Sicherheitsgruppe zu:
1. [Melden Sie sich bei v2/ an AWS-Managementkonsole und öffnen Sie die AWS DMS Konsole. https://console.aws.amazon.com/dms/](https://console.aws.amazon.com/dms/v2/)
Wenn Sie als AWS Identity and Access Management (IAM-) Benutzer angemeldet sind, stellen Sie sicher, dass Sie über die entsprechenden Zugriffsberechtigungen verfügen. AWS DMS Weitere Informationen zu den erforderlichen Berechtigungen für die Datenbankmigration finden Sie unter [Für die Verwendung sind IAM-Berechtigungen erforderlich AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. Wählen Sie auf der Seite **Dashboard** **Replication Instance (Replikations-Instance)**. Befolgen Sie die Anweisungen unter [Schritt 1: Erstellen Sie eine Replikationsinstanz mithilfe der AWS DMS Konsole](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.ReplicationInstance) zum Erstellen einer Replikations-Instance.
1. Nachdem Sie die AWS DMS-Replikationsinstanz erstellt haben, öffnen Sie die EC2-Servicekonsole. Wählen Sie im Navigationsbereich **Netzwerk-Interfaces** aus.
1. Wählen Sie die *DMSNetworkSchnittstelle* und dann im Menü **Aktionen** die Option **Sicherheitsgruppen ändern** aus.
1. Wählen Sie die Sicherheitsgruppe aus, die Sie für die Replikations-Instance und die DB-Ziel-Instance verwenden möchten.
1. Verknüpfen Sie die Sicherheitsgruppe aus dem letzten Schritt mit der DB-Ziel-Instance:
1. Öffnen Sie die Amazon RDS-Konsole. Wählen Sie im Navigationsbereich **Instances** aus.
1. Wählen Sie die DB-Ziel-Instance aus. Wählen Sie für **Instance-Aktionen** die Option **Ändern**.
1. Wählen Sie für den Parameter **Sicherheitsgruppe** die Sicherheitsgruppe aus, die Sie im vorherigen Schritt verwendet haben.
1. Wählen Sie **Weiter** und dann **DB-Instance ändern**.
1. Schritt 3: Einrichten eines Proxy-Servers auf einer EC2-Classic-Instance mit NGINX. Verwenden Sie ein AMI Ihrer Wahl, um eine EC2-Classic-Instance zu starten. Das folgende Beispiel basiert auf AMI Ubuntu Server 14.04 LTS (HVM).
So richten Sie einen Proxy-Server auf einer EC2-Classic-Instance ein
1. Stellen Sie eine Verbindung mit der EC2-Classic-Instance her und installieren Sie NGINX mithilfe der folgenden Befehle:
```
Prompt> sudo apt-get update
Prompt> sudo wget http://nginx.org/download/nginx-1.9.12.tar.gz
Prompt> sudo tar -xvzf nginx-1.9.12.tar.gz
Prompt> cd nginx-1.9.12
Prompt> sudo apt-get install build-essential
Prompt> sudo apt-get install libpcre3 libpcre3-dev
Prompt> sudo apt-get install zlib1g-dev
Prompt> sudo ./configure --with-stream
Prompt> sudo make
Prompt> sudo make install
```
1. Bearbeiten Sie die NGINX-Daemon-Datei, `/etc/init/nginx.conf`, mit folgendem Code:
```
# /etc/init/nginx.conf – Upstart file
description "nginx http daemon"
author "email"
start on (filesystem and net-device-up IFACE=lo)
stop on runlevel [!2345]
env DAEMON=/usr/local/nginx/sbin/nginx
env PID=/usr/local/nginx/logs/nginx.pid
expect fork
respawn
respawn limit 10 5
pre-start script
$DAEMON -t
if [ $? -ne 0 ]
then exit $?
fi
end script
exec $DAEMON
```
1. Erstellen Sie eine NGINX-Konfigurationsdatei unter `/usr/local/nginx/conf/nginx.conf`. Fügen Sie in der Konfigurationsdatei Folgendes hinzu:
```
# /usr/local/nginx/conf/nginx.conf - NGINX configuration file
worker_processes 1;
events {
worker_connections 1024;
}
stream {
server {
listen DB instance port number;
proxy_pass DB instance identifier:DB instance port number;
}
}
```
1. Starten Sie von der Befehlszeile NGINX mithilfe der folgenden Befehle:
```
Prompt> sudo initctl reload-configuration
Prompt> sudo initctl list | grep nginx
Prompt> sudo initctl start nginx
```
1. Stellen Sie eine ClassicLink Verbindung zwischen dem Proxyserver und der Ziel-VPC her, die die Ziel-DB-Instance und die Replikationsinstanz enthält:
1. Öffnen Sie die EC2-Konsole und wählen Sie die EC2-Classic-Instance aus, auf der der Proxy-Server ausgeführt wird.
1. Wählen Sie für **Aktionen** die Option **ClassicLink**und anschließend **Link to VPC** aus.
1. Wählen Sie die Sicherheitsgruppe aus, die Sie zuvor in diesem Verfahren verwendet haben.
1. Wählen Sie **Mit VPC verknüpfen**.
1. Schritt 5: Erstellen Sie AWS DMS-Endpunkte mithilfe des Verfahrens unter. [Schritt 2: Angeben von Quell- und Zielendpunkten](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Endpoints) Sie müssen den internen EC2-DNS-Host-Namen des Proxy-Servers als Servernamen verwenden, wenn Sie den Quellendpunkt angeben.
1. Erstellen Sie eine AWS DMS-Aufgabe mit dem Verfahren unter. [Schritt 3: Erstellen einer Aufgabe und Migrieren der Daten](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Tasks)
### Konfiguration für ein Netzwerk, das eine Verbindung zu AWS Diensten herstellt
Um eine Verbindung mit AWS Diensten herzustellen, verwenden Sie entweder eine Internetverbindung oder Virtual Private Cloud (VPC) -Endpunkte. Dies gilt, wenn:
Ihre Quell- oder Zielendpunkte nutzen AWS Dienste wie:
+ AWS Secrets Manager
+ Amazon Simple Storage Service
Ihr Zielendpunkt ist ein AWS Dienst wie:
+ Amazon S3
+ Amazon Kinesis
+ Amazon DynamoDB
+ Amazon Redshift
+ OpenSearch Amazon-Dienst
+ Amazon Athena
### Konfiguration für ein Netzwerk, das über VPC-Endpunkte eine Verbindung zu AWS Diensten herstellt
VPC-Endpunkte bieten sichere Verbindungen zwischen Ihren AWS Ressourcen und verbinden VPC-Ressourcen mit AWS Diensten, ohne dass ein Internetzugang erforderlich ist. Ihre Anwendungen in privaten Subnetzen können auf AWS Dienste zugreifen und bleiben gleichzeitig im AWS Netzwerk, wodurch die Sicherheit verbessert und die Latenz reduziert wird. Bitte schauen Sie sich das Bild unten an:
![\[\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/aws_dms_vpc_endpoints.jpg)
Weitere Informationen finden Sie unter [VPC-Endpunkte als AWS DMS Quell- und Zielendpunkte konfigurieren und AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_VPC_Endpoints.html) [Secrets Manager VPC-Endpoint konfigurieren](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Advanced.Endpoints.secretsmanager.html).
### Konfiguration für ein Netzwerk, das über das Internet eine Verbindung zu Diensten AWS herstellt
Eine Replikationsinstanz benötigt Internetzugang, um während der Datenmigration eine Verbindung zu AWS Ressourcen herzustellen.
Weitere Informationen zu privaten und öffentlichen Subnetzen innerhalb einer VPC finden Sie unter [Beispiel: VPC mit Servern in privaten Subnetzen und NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html) im *Amazon Virtual Private* Cloud Cloud-Benutzerhandbuch. Sie müssen sicherstellen, dass Ihre Netzwerkkonfiguration auf Konnektivität mit allen erforderlichen Diensten getestet wird.
## Erstellen einer Replikationssubnetzgruppe
Als Teil des für die Datenbankmigration zu verwendenden Netzwerks müssen Sie angeben, welche Subnetze in Ihrer Virtual Private Cloud (VPC) verwendet werden sollen. Diese VPC muss auf dem Amazon-VPC-Service basieren. Ein *Subnetz* ist ein IP-Adressbereich in Ihrer VPC in einer bestimmten Availability Zone. Diese Subnetze können auf die Availability Zones der AWS Region verteilt werden, in der sich Ihre VPC befindet.
Wenn Sie eine Replikationsinstanz oder ein Instanzprofil in der AWS DMS-Konsole erstellen, können Sie das von Ihnen gewählte Subnetz verwenden.
Sie erstellen eine Replikationssubnetzgruppe, um zu definieren, welche Subnetze verwendet werden. Sie müssen Subnetze in mindestens zwei Availability Zones angeben.
**So erstellen Sie eine Replikationssubnetzgruppe**
1. [Melden Sie sich bei v2/ an AWS-Managementkonsole und öffnen Sie die AWS DMS Konsole. https://console.aws.amazon.com/dms/](https://console.aws.amazon.com/dms/v2/)
Wenn Sie als IAM-Benutzer angemeldet sind, müssen Sie über die entsprechenden Berechtigungen für den Zugriff auf AWS DMS verfügen. Weitere Informationen zu den erforderlichen Berechtigungen für die Datenbankmigration finden Sie unter [Für die Verwendung sind IAM-Berechtigungen erforderlich AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. Wählen Sie im Navigationsbereich **Subnetzgruppe** aus.
1. Wählen Sie **Create subnet group** (Subnetz-Grupp erstellen) aus.
1. Geben Sie auf der Seite **Replikations-Subnetzgruppe bearbeiten** die Informationen zu Ihrer Replikationssubnetzgruppe an. In der folgenden Tabelle sind die Einstellungen beschrieben.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html)
1. Wählen Sie **Create subnet group** (Subnetz-Grupp erstellen) aus.
## Auflösen von Domain-Endpunkten mithilfe von DNS
Normalerweise verwendet eine AWS DMS Replikationsinstanz den Domain Name System (DNS) -Resolver in einer Amazon EC2 EC2-Instance, um Domain-Endpunkte aufzulösen. Wenn Sie eine DNS-Auflösung benötigen, können Sie den Amazon Route 53 Resolver verwenden. Weitere Informationen zur Verwendung von Route 53 DNS Resolver finden Sie unter [Erste Schritte mit Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html).
Für Informationen dazu, wie Sie Ihren eigenen On-Premises-Namensserver verwenden, um bestimmte Endpunkte aufzulösen, wenn Sie den Amazon Route 53 Resolver verwenden, siehe [Verwenden Ihres eigenen Vor-Ort-Nameservers](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver).
# Festlegen eines Verschlüsselungsschlüssels für eine Replikations-Instance
AWS DMS verschlüsselt den von einer Replikationsinstanz verwendeten Speicher und die Verbindungsinformationen des Endpunkts. Um den von einer Replikationsinstanz verwendeten Speicher zu verschlüsseln, verwendet AWS DMS eine, AWS KMS key die für Ihr Konto eindeutig ist. AWS Sie können diesen KMS-Schlüssel mit AWS Key Management Service ()AWS KMS anzeigen und verwalten. Sie können den Standard-KMS-Schlüssel in Ihrem Konto (`aws/dms`) verwenden oder Sie können einen eigenen KMS-Schlüssel erstellen. Wenn Sie bereits über einen AWS KMS Verschlüsselungsschlüssel verfügen, können Sie diesen Schlüssel auch für die Verschlüsselung verwenden.
Sie können Ihren eigenen Verschlüsselungsschlüssel angeben, indem Sie eine KMS-Schlüssel-ID zur Verschlüsselung Ihrer AWS DMS-Ressourcen angeben. Wenn Sie Ihren eigenen Verschlüsselungsschlüssel angeben, muss das Benutzerkonto, mit dem die Datenbankmigration durchgeführt wird, Zugriff auf diesen Schlüssel haben. Weitere Informationen zum Erstellen eigener Verschlüsselungsschlüssel und zum Erteilen von Zugriffsrechten auf einen Verschlüsselungsschlüssel für Benutzer finden Sie im *[Entwicklerhandbuch für AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)*.
Wenn Sie keine KMS-Schlüssel-ID angeben, verwendet AWS DMS Ihren Standard-Verschlüsselungsschlüssel. KMS erstellt den Standard-Verschlüsselungsschlüssel für AWS DMS für Ihr AWS Konto. Ihr AWS Konto hat für jede AWS Region einen anderen Standardverschlüsselungsschlüssel.
Um die Schlüssel zu verwalten, die für die Verschlüsselung Ihrer AWS DMS-Ressourcen verwendet werden, verwenden Sie. AWS KMS Sie finden es AWS KMS in, AWS-Managementkonsole indem Sie im Navigationsbereich nach **KMS** suchen.
AWS KMS kombiniert sichere, hochverfügbare Hardware und Software zu einem für die Cloud skalierten Schlüsselverwaltungssystem. Mithilfe AWS KMS können Sie Verschlüsselungsschlüssel erstellen und die Richtlinien definieren, die steuern, wie diese Schlüssel verwendet werden können. AWS KMS unterstützt AWS CloudTrail, sodass Sie die Verwendung von Schlüsseln überprüfen können, um sicherzustellen, dass die Schlüssel ordnungsgemäß verwendet werden. Ihre AWS KMS Schlüssel können in Kombination mit AWS DMS und anderen unterstützten AWS Diensten verwendet werden. Zu den unterstützten AWS -Services gehören Amazon RDS, Amazon S3, Amazon Elastic Block Store (Amazon EBS) und Amazon Redshift.
Wenn Sie Ihre AWS DMS-Ressourcen mit einem bestimmten Verschlüsselungsschlüssel erstellt haben, können Sie den Verschlüsselungsschlüssel für diese Ressourcen nicht ändern. Stellen Sie sicher, dass Sie Ihre Anforderungen an den Verschlüsselungsschlüssel ermitteln, bevor Sie Ihre AWS DMS-Ressourcen erstellen.
# Erstellen einer Replikations-Instance
Ihre erste Aufgabe bei der Migration einer Datenbank besteht darin, eine Replikations-Instance zu erstellen. Die Replikations-Instance benötigt genügend Speicherplatz und Rechenleistung für die Durchführung der zugewiesenen Aufgaben und die Migration der Daten von der Quelldatenbank zur Zieldatenbank. Die erforderliche Größe dieser Instance hängt von der Menge der Daten ab, die Sie migrieren müssen, sowie von den Aufgaben, die die Instance ausführen muss. Weitere Informationen zu Replikations-Instances finden Sie unter [Mit einer AWS DMS Replikationsinstanz arbeiten](CHAP_ReplicationInstance.md).
**So erstellen Sie eine Replikationsinstanz mithilfe der AWS Konsole**
1. Wählen Sie im Navigationsbereich der AWS DMS Konsole **Replikationsinstanzen** und dann **Replikationsinstanz erstellen** aus.
1. Legen Sie auf der Seite **Create replication instance** die Angaben zur Replikations-Instance fest. In der folgenden Tabelle sind die möglichen Einstellungen beschrieben.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Wählen Sie die Registerkarte **Advanced (Erweitert)** aus, um ggf. Werte für Netzwerk- und Verschlüsselungseinstellungen festzulegen. In der folgenden Tabelle sind die Einstellungen beschrieben.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Geben Sie die **Maintenance**-Einstellungen an. In der folgenden Tabelle sind die Einstellungen beschrieben. Weitere Informationen zu den Wartungseinstellungen finden Sie unter [Mit dem AWS DMS Wartungsfenster arbeiten](CHAP_ReplicationInstance.MaintenanceWindow.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Wählen Sie **Create replication instance (Replikations-Instance erstellen)** aus.
# Ändern einer Replikations-Instance
Sie können die Einstellungen für eine Replikations-Instance ändern, um z. B. die Instance-Klasse zu ändern oder den Speicher zu erhöhen.
Wenn Sie eine Replikations-Instance ändern, können Sie die Änderungen sofort anwenden. Damit Änderungen sofort übernommen werden, wählen Sie die Option **Sofort anwenden** in der AWS-Managementkonsole aus. Oder verwenden Sie den `--apply-immediately` Parameter beim Aufrufen von AWS CLI, oder setzen Sie den `ApplyImmediately` Parameter auf, `true` wenn Sie die DMS-API verwenden.
Wenn Sie sich entscheiden, die Änderungen nicht sofort zu übernehmen, werden die Änderungen in die Warteschlange für ausstehende Änderungen aufgenommen. Während des nächsten Wartungsfensters, werden alle ausstehenden Änderungen in der Warteschlange angewandt.
**Anmerkung**
Wenn Sie sich entscheiden die Änderungen sofort zu übernehmen, werden alle Änderungen in der auch alle ausstehenden Änderungen in der Warteschlange übernommen. Wenn eine der ausstehenden Änderungen eine Ausfallzeit erfordert, kann die Auswahl von **Apply changes immediately** (Änderungen sofort übernehmen) einen unerwarteten Ausfall verursachen.
**Um eine Replikationsinstanz mithilfe der AWS Konsole zu ändern**
1. Melden Sie sich bei [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) an AWS-Managementkonsole und öffnen Sie die AWS DMS Konsole.
1. Wählen Sie im Navigationsbereich **Replication instances (Replikations-Instances)** aus.
1. Wählen Sie die Replikations-Instance aus, die Sie ändern möchten. Die folgende Tabelle beschreibt die Änderungen, die Sie vornehmen können.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html)
## Bewährte Methoden beim Ändern einer Replikationsinstanz
Wenn Sie eine Replikationsinstanz ändern, trägt die Einhaltung dieser bewährten Methoden dazu bei, ein erfolgreiches Update mit minimalen Auswirkungen auf Ihre Migrationsworkflows sicherzustellen. Führen Sie vor, während und nach Änderungen die folgenden wichtigen Schritte durch, um die Datenintegrität und betriebliche Effizienz während des gesamten Prozesses aufrechtzuerhalten.
**Zeitplan für Änderungen planen:**
+ Sie können die Änderungen entweder sofort anwenden oder sie für das nächste Wartungsfenster planen.
+ Planen Sie in Zeiten mit wenig Verkehr, um die Auswirkungen zu minimieren.
**Schritte vor der Änderung:**
+ Beenden Sie alle aktiven Replikationsaufgaben.
+ Stellen Sie sicher, dass alle Aufgaben erfolgreich beendet wurden.
+ Dokumentieren Sie die aktuellen Einstellungen der Konfigurationsaufgaben.
**Während der Änderung:**
+ Überwachen Sie den Fortschritt der Änderung.
+ Warten Sie auf den Status „Verfügbar“, bevor Sie fortfahren.
**Schritte nach der Änderung:**
+ Setzt alle zuvor gestoppten Aufgaben fort.
+ Stellen Sie sicher, dass die Aufgaben korrekt ausgeführt werden.
# Neustarten einer Replikations-Instance.
Sie können eine AWS DMS Replikationsinstanz neu starten, um die Replikations-Engine neu zu starten. Ein Neustart führt zu einem kurzzeitigen Ausfall der Replikations-Instance, bei dem der Instance-Status auf **Neustarten** gesetzt wird. Wenn die AWS DMS Instanz für Multi-AZ konfiguriert ist, kann der Neustart mit einem Failover durchgeführt werden. Ein AWS DMS Ereignis wird erzeugt, wenn der Neustart abgeschlossen ist.
Wenn es sich bei Ihrer AWS DMS Instance um eine Multi-AZ-Bereitstellung handelt, können Sie beim Neustart einen geplanten Failover von einer AWS Availability Zone in eine andere erzwingen. Wenn Sie einen geplanten Failover Ihrer AWS DMS Instance erzwingen, werden aktive Verbindungen auf der aktuellen Instance AWS DMS geschlossen, bevor automatisch zu einer Standby-Instance in einer anderen Availability Zone gewechselt wird. Durch einen Neustart mit einem geplanten Failover können Sie ein geplantes Failover-Ereignis einer AWS DMS Instanz simulieren, z. B. bei der Skalierung der Replikationsinstanzklasse.
**Anmerkung**
Nachdem ein Neustart ein Failover von einer Availability Zone zu einer anderen erzwungen hat, wird die Änderung der Availability Zone möglicherweise für mehrere Minuten nicht widergespiegelt. Diese Verzögerung tritt in der und in Aufrufen der AWS-Managementkonsole AND-API auf. AWS CLI AWS DMS
Wenn bei einem Neustart Migrationsaufgaben auf der Replikations-Instance ausgeführt werden, tritt kein Datenverlust auf, aber die Aufgabe wird beendet und der Aufgabenstatus ändert sich zu einem Fehlerstatus.
Wenn sich die Tabellen in der Migrationsaufgabe mitten in einem Massenladevorgang befinden (Volllastphase) und noch nicht gestartet wurden, gehen sie zu einem Fehlerstatus über. Tabellen, die zu diesem Zeitpunkt vollständig sind, bleiben jedoch in einem vollständigen Zustand. Wenn während der Volllastphase ein Neustart stattfindet, empfehlen wir, einen der folgenden Schritte auszuführen.
+ Entfernen Sie die Tabellen, die sich in einem vollständigen Zustand befinden, aus der Aufgabe und starten Sie die Aufgabe mit den verbleibenden Tabellen neu.
+ Erstellen Sie eine neue Aufgabe mit Tabellen, die sich in einem Fehlerstatus befinden, sowie mit Tabellen, die noch ausstehen.
Wenn sich Tabellen in der Migrationsaufgabe in der laufenden Replikationsphase befinden, wird die Aufgabe nach Abschluss des Neustarts wieder aufgenommen.
Sie können Ihre AWS DMS Replikationsinstanz nicht neu starten, wenn ihr Status nicht im Status **Verfügbar** ist. Ihre AWS DMS Instance kann aus verschiedenen Gründen nicht verfügbar sein, z. B. aufgrund einer zuvor angeforderten Änderung oder einer Aktion im Wartungsfenster. Die Zeit, die für den Neustart einer AWS DMS Replikationsinstanz benötigt wird, ist in der Regel gering (unter 5 Minuten).
## Neustarten einer Replikationsinstanz mithilfe der Konsole AWS
Verwenden Sie die Konsole, um eine Replikationsinstanz neu zu starten. AWS
**Um eine Replikationsinstanz mithilfe der AWS Konsole neu zu starten**
1. Melden Sie sich bei [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) an AWS-Managementkonsole und öffnen Sie die AWS DMS Konsole.
1. Wählen Sie im Navigationsbereich **Replication instances (Replikations-Instances)** aus.
1. Wählen Sie die Replikations-Instance aus, die Sie neustarten möchten.
1. Wählen Sie **Reboot**. Das Dialogfeld **Replikations-Instance neu starten** wird geöffnet.
1. Wählen Sie die Option **Neustart mit Failover?**, wenn Sie Ihre Replikations-Instance für die Multi-AZ-Bereitstellung konfiguriert haben und möchten, dass ein Failover zu einer anderen AWS -Availability Zone durchgeführt wird.
1. Wählen Sie **Reboot**.
## Neustarten einer Replikations-Instance mithilfe der CLI
Verwenden Sie den AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html)Befehl mit dem folgenden Parameter, um eine Replikationsinstanz neu zu starten:
+ `--replication-instance-arn`
**Example Beispiel für einen einfachen Neustart**
Im folgenden AWS CLI Beispiel wird eine Replikationsinstanz neu gestartet.
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance
```
**Example Beispiel für einen einfachen Neustart mit Failover**
Im folgenden AWS CLI Beispiel wird eine Replikationsinstanz mit Failover neu gestartet.
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance \
--force-planned-failover
```
## Neustarten einer Replikations-Instance mithilfe der API
Verwenden Sie die AWS DMS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)API-Aktion mit den folgenden Parametern, um eine Replikationsinstanz neu zu starten:
+ `ReplicationInstanceArn = arn of my rep instance`
**Example Beispiel für einen einfachen Neustart**
Im folgenden Code-Beispiel wird eine Replikations-Instance neu gestartet.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
**Example Beispiel für einen einfachen Neustart mit Failover**
Das folgende Codebeispiel startet eine Replikationsinstanz neu und führt ein Failover zu einer anderen AWS Availability Zone durch.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &ForcePlannedFailover=true
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
# Löschen einer Replikations-Instance
Sie können eine AWS DMS Replikationsinstanz löschen, wenn Sie sie nicht mehr verwenden. Wenn Sie Migrationsaufgaben haben, die die Replikations-Instance verwenden, müssen Sie die Aufgaben stoppen und löschen, bevor Sie die Replikations-Instance löschen.
Wenn Sie Ihr AWS Konto schließen, werden alle mit Ihrem Konto verknüpften AWS DMS Ressourcen und Konfigurationen nach zwei Tagen gelöscht. Zu diesen Ressourcen gehören alle Replikations-Instances, Quell- und Ziel-Endpunktkonfiguration, Replikationsaufgaben und SSL-Zertifikate. Wenn Sie sich nach zwei Tagen für eine AWS DMS erneute Nutzung entscheiden, erstellen Sie die benötigten Ressourcen neu.
Wenn Ihre Replikations-Instance alle Kriterien für das Löschen erfüllt und sie über einen längeren Zeitraum im `DELETING`-Status bleibt, wenden Sie sich an den Support, um das Problem zu beheben.
## Löschen einer Replikationsinstanz mithilfe der Konsole AWS
Verwenden Sie die AWS Konsole, um eine Replikationsinstanz zu löschen.
**Um eine Replikationsinstanz mithilfe der AWS Konsole zu löschen**
1. Melden Sie sich bei [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) an AWS-Managementkonsole und öffnen Sie die AWS DMS Konsole.
1. Wählen Sie im Navigationsbereich **Replication instances (Replikations-Instances)** aus.
1. Wählen Sie die Replikations-Instance aus, die Sie löschen möchten.
1. Wählen Sie **Löschen** aus.
1. Wählen Sie im Dialogfeld (Bestätigung) **Delete (Löschen)** aus.
## Löschen einer Replikations-Instance über die CLI
Um eine Replikationsinstanz zu löschen, verwenden Sie den AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html)Befehl mit dem folgenden Parameter:
+ `--replication-instance-arn`
**Example Beispiel für das Löschen**
Im folgenden AWS CLI Beispiel wird eine Replikationsinstanz gelöscht.
```
aws dms delete-replication-instance \
--replication-instance-arn arn of my rep instance
```
## Löschen einer Replikations-Instance über die API
Verwenden Sie die AWS DMS [https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html](https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html)API-Aktion mit den folgenden Parametern, um eine Replikationsinstanz zu löschen:
+ `ReplicationInstanceArn = arn of my rep instance`
**Example Beispiel für das Löschen**
Im folgenden Codebeispiel wird eine Replikations-Instance gelöscht.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=DeleteReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
# Mit dem AWS DMS Wartungsfenster arbeiten
Jede AWS DMS Replikationsinstanz hat ein wöchentliches Wartungsfenster, in dem alle verfügbaren Systemänderungen angewendet werden. Sie können sich das Wartungsfenster als Möglichkeit vorstellen, zu kontrollieren, wann Änderungen und Software-Patches auftreten.
Wenn AWS DMS festgestellt wird, dass in einer bestimmten Woche eine Wartung erforderlich ist, erfolgt die Wartung während des 30-minütigen Wartungsfensters, das Sie bei der Erstellung der Replikationsinstanz ausgewählt haben. AWS DMS schließt die meisten Wartungsarbeiten während des 30-minütigen Wartungsfensters ab. Allerdings können größere Änderungen mehr Zeit in Anspruch nehmen.
## Auswirkungen der Wartung auf vorhandene Migrationsaufgaben
Wenn eine AWS DMS Migrationsaufgabe auf einer Instanz ausgeführt wird, treten bei der Installation eines Patches die folgenden Ereignisse auf:
+ Wenn die Tabellen in der Migrationsaufgabe sich in der laufenden Änderungsphase der Replikation (CDC) befinden, pausiert AWS DMS die Aufgabe für einen Moment, während der Patch angewendet wird. Die Migration wird dann an der Stelle fortgesetzt, an der sie unterbrochen wurde, als der Patch angewendet wurde.
+ Wenn AWS DMS eine Tabelle im Rahmen einer Aufgabe zum Migrieren **vorhandener Daten oder zum Migrieren vorhandener Daten** **und Replizieren laufender Änderungen migriert** wird, stoppt DMS die Migration für alle Tabellen, die sich in der Volllastphase befinden, während der Patch angewendet wird, und startet sie dann neu. DMS stoppt außerdem alle Tabellen, die sich in der CDC-Phase befinden, und setzt sie fort, während der Patch angewendet wird.
## Ändern der Einstellung des Wartungsfensters
Sie können den Zeitrahmen für das Wartungsfenster mithilfe der AWS-Managementkonsole, oder der AWS CLI API ändern. AWS DMS
### Ändern der Einstellung des Wartungszeitfensters mit der Konsole
Sie können den Zeitraum des Wartungsfensters über die AWS-Managementkonsoleändern.
**So ändern Sie das bevorzugte Wartungsfenster mithilfe der Konsole**
1. Melden Sie sich bei [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) an AWS-Managementkonsole und öffnen Sie die AWS DMS Konsole.
1. Wählen Sie im Navigationsbereich **Replication instances (Replikations-Instances)** aus.
1. Wählen Sie die Replikations-Instance aus, die Sie ändern möchten, und wählen Sie **Modify** aus.
1. Erweitern Sie den Abschnitt **Wartung** und wählen Sie Datum und Uhrzeit Ihres Wartungsfensters aus.
1. Wählen Sie **Apply changes immediately** aus.
1. Wählen Sie **Ändern** aus.
### Ändern der Einstellung des Wartungsfensters mithilfe der CLI
Verwenden Sie den AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)Befehl mit den folgenden Parametern, um das bevorzugte Wartungsfenster anzupassen.
+ `--replication-instance-identifier`
+ `--preferred-maintenance-window`
**Example**
Im folgenden AWS CLI Beispiel wird das Wartungsfenster auf dienstags von 4:00 bis 4:30 Uhr festgelegt. festgelegt.
```
aws dms modify-replication-instance \
--replication-instance-identifier myrepinstance \
--preferred-maintenance-window Tue:04:00-Tue:04:30
```
### Ändern der Einstellung des Wartungsfensters mithilfe der API
Verwenden Sie die AWS DMS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)API-Aktion mit den folgenden Parametern, um das bevorzugte Wartungsfenster anzupassen.
+ `ReplicationInstanceIdentifier = myrepinstance`
+ `PreferredMaintenanceWindow = Tue:04:00-Tue:04:30`
**Example**
Im folgenden Codebeispiel wird das Wartungszeitfenster auf dienstags von 04:00 Uhr bis 04:30 Uhr gesetzt. festgelegt.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=ModifyReplicationInstance
3. &DBInstanceIdentifier=myrepinstance
4. &PreferredMaintenanceWindow=Tue:04:00-Tue:04:30
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```