Bevor Sie einen PlateSpin Migrate-Server in der Cloud installieren, vergewissern Sie sich, dass Sie die folgenden Anforderungen an Ihre Cloud-Umgebung verstanden haben.
Richten Sie ein Konto in der Cloud-Umgebung ein. Vergewissern Sie sich, dass das Cloud-Konto richtig konfiguriert und verfügbar ist. Informationen zu AWS-Konten finden Sie in Tabelle 2-1. Für Azure-Konten können Sie Tabelle 2-2 zurate ziehen.
Tabelle 2-1 Voraussetzungen für AWS-Konten
|
AWS-Konfiguration |
Beschreibung |
|---|---|
|
AWS-Konto |
Legen Sie das AWS-Konto über die Amazon Web Services-Konsole an. |
|
AWS-EC2-Subscription |
PlateSpin unterstützt lediglich die Amazon-VPC (Virtual Private Cloud). |
|
Amazon-VPC (Virtual Private Cloud) |
Erstellen Sie eine AWS-VPC, über die die AWS-Ressourcen im virtuellen Netzwerk gestartet werden sollen. Weitere Informationen finden Sie in der Dokumentation zu Amazon-VPC. |
|
AWS-Benutzerberechtigungsnachweis |
Sie benötigen einen AWS-IAM-Benutzer (Identity and Access Management) im AWS-Konto, der die entsprechende IAM-Rolle für Migrationen zur VPC mithilfe der AWS-APIs besitzt. Mit dem AWS-Rollenwerkzeug von PlateSpin Migrate können Sie es einem verwaltungsbefugten Benutzer ermöglichen, eine neue IAM-Richtlinie auf der Grundlage der Standardrichtlinie zu erstellen und dieser Richtlinie einen IAM-Benutzer zuzuweisen. Weitere Informationen hierzu finden Sie unter Erstellen einer IAM-Richtlinie und Zuweisen eines IAM-Benutzers im PlateSpin Migrate 2018.11-Benutzerhandbuch. Aktivieren Sie den programmatischen Zugriff für den IAM-Benutzer, sodass ein Zugriffsschlüssel und ein geheimer Zugriffsschlüssel erstellt werden können. Der Zugang zur AWS-Verwaltungskonsole ist optional, kann jedoch die Fehlerbehebung erleichtern. Weitere Informationen hierzu finden Sie unter Zugriffsschlüssel (Zugriffsschlüssel-ID und geheimer Zugriffsschlüssel). HINWEIS:Wir empfehlen, dass Administratoren die Zugriffsschlüssel für IAM-Benutzer regelmäßig rotieren. Die Schlüssel dürfen jedoch nur rotiert werden, wenn Sie sichergestellt haben, dass kein Migrations-Workflow im Gange ist. Weitere Informationen finden Sie im Abschnitt |
Tabelle 2-2 Voraussetzungen für Azure-Konten
|
Azure-Konfiguration |
Beschreibung |
|---|---|
|
Microsoft Azure-Konto. |
Legen Sie ein Konto in der Azure-Umgebung an, zu der die Workloads migriert werden sollen: Es wird ein Administrator für das Konto benötigt, um die Anwendungseinrichtung durchzuführen, den programmatischen PRE-Zugriff zu aktivieren und einen beitragenden Benutzer anzulegen, der von Migrate verwendet werden soll. |
|
Azure-Subscription-ID |
Die ID für die Azure-Subscription im angegebenen Azure-Konto, der die Kosten für Azure in Rechnung gestellt werden sollen. Ein Konto kann mehrere Subscriptions umfassen. |
|
Beitragender Benutzer für die im Azure Active Directory erstellte Subscription |
Ein Benutzer, der als Beitragender für die angegebene Subscription im Azure Active Directory angelegt wurde Verwenden Sie in Migrate den Berechtigungsnachweis des beitragenden Benutzers, um Azure als Ziel in Migrate hinzuzufügen. Migrate verwendet den Berechtigungsnachweis für diesen Benutzer beim Zugriff auf die Migrate Azure-API über das entsprechende Abonnement. |
|
Azure Virtual Network und Subnetz |
In der angegebenen Subscription müssen Sie mindestens ein virtuelles Netzwerk mit einem Subnetz erstellen. Wenn ein Site-to-Site-VPN eingerichtet ist, darf das Subnetz nicht mit dem standardmäßigen Gateway-Subnetz identisch sein. |
Ein cloudbasierter PlateSpin Migrate-Server benötigt keine Site-to-Site-VPN-Verbindung zwischen Ihrem lokalen Rechenzentrum und der Ziel-Cloud-Plattform. Wenn kein VPN vorhanden ist:
Internetzugriff ist erforderlich.
Für den PlateSpin Migrate-Server, das Reproduktionsnetzwerk und die Zielcomputer werden öffentliche IP-Adressen benötigt. Bei Verwendung von Migrate Agent ist für den Ursprungscomputer keine öffentliche IP-Adresse erforderlich. Wenn Sie Migrate Agent nicht verwenden, benötigen alle Komponenten öffentliche IP-Adressen.
Verwenden Sie Migrate Agent, um Workloads beim cloudbasierten Migrate-Server zu registrieren. Migrate Agent verwendet sichere Kommunikationsverbindungen über das öffentliche Internet.
Sie sollten die Datenübertragung zwischen dem Ursprungsnetzwerk und dem Cloud-Standort verschlüsseln.
Für Cloud-Ziele ist die Komprimierung standardmäßig auf „Optimal“ festgelegt.
Verwenden Sie eine statische IP-Adresse für den Migrate-Server, um sicherzustellen, dass sich die IP-Adresse beim Neustart des Servers nicht ändert. Eine Änderung der IP-Adresse auf dem PlateSpin-Server unterbricht die Heartbeat-Kommunikation mit den Ursprungs-Workloads.
AWS: Geben Sie Elastic (Elastisch) als Zuweisungsmethode für die öffentliche IP-Adresse des Migrate-Servers an.
Azure: Geben Sie Statisch als Zuweisungsmethode für die öffentliche IP-Adresse des Migrate-Servers an.
HINWEIS:Sie können die tatsächliche IP-Adresse, die der öffentlichen IP-Ressource zugewiesen ist, nicht angeben. Der Cloud-Anbieter übernimmt die Zuweisung und Reservierung von IP-Adressen im Pool der verfügbaren IP-Adressen an dem Standort, an dem Sie den Migrate-Server bereitstellen.
Stellen Sie sicher, dass die Netzwerksicherheitsgruppe für den PlateSpin Migrate-Server die in Abschnitt 2.3, Erforderliche Einstellungen der Netzwerksicherheitsgruppe für den PlateSpin Migrate-Server beschriebenen Port-Mindesteinstellungen zulässt.
Transport Layer Security (TLS) 1.2 ist automatisch für das Windows-Betriebssystem auf dem virtuellen PlateSpin Migrate Server-Host für Migrate-Server aktiviert, die auf einem Cloud-Marktplatz verfügbar sind. TLS 1.0 und TLS 1.0 sind standardmäßig deaktiviert.
Migrate stellt im Ordner C:\Windows\OEM Skripte zur Verfügung, um TLS 1.0 und TLS 1.1 auf dem virtuellen Migrate-Server-Host einfach zu aktivieren und zu deaktivieren: