PlateSpin Migrate unterstützt die Migration der folgenden Windows- und Linux-Workloads zu Plattformen außerhalb der Cloud (z. B. physische Computer und virtuelle Computer auf unterstützten Hypervisoren). Weitere Informationen hierzu finden Sie in Unterstützte Ziel-Virtualisierungsplattformen.
Die folgenden Migrationsfunktionen werden bei der Migration zu Plattformen außerhalb der Cloud unterstützt:
Peer-to-Peer-Migrationen (P2V, V2V, V2P, P2P)
Peer-to-Peer-Workload-Synchronisierung (P2V, V2V, P2P, V2P)
HINWEIS:Nicht alle Workloads werden auf allen Ziel-Virtualisierungsplattformen unterstützt. Die Migration von Workloads zu einer Ziel-Virtualisierungsplattform ist abhängig von der Unterstützung des Gast-Betriebssystems auf dem Ziel-Host durch den Host-Anbieter.
Lesen Sie hierzu die folgenden Abschnitte:
PlateSpin Migrate unterstützt die nachfolgenden Microsoft Windows-Plattformen für die Migration zu virtuellen Computern (auf Virtualisierungshosts) bzw. zu physischen Computern, mit Ausnahme der unter Tabelle 2-1 genannten Fälle. Weitere Informationen finden Sie auch unter Unterstützter Workload-Speicher und Unterstützte Workload-Architekturen.
Tabelle 2-1 Plattformen außerhalb der Cloud: Unterstützte Windows-Workloads
|
Betriebssystem |
Anmerkungen |
|---|---|
|
Server |
|
|
Windows Server 2016 |
Für die Migration zu einer VMware-VM ist VMware vCenter 6.0 (oder höher) erforderlich. |
|
|
|
Umfasst auch Domänencontroller(DC)-Systeme und Small Business Server-Editionen. Keine Unterstützung der Migration von Windows Server 2008 R2 SP0 zu Hyper-V, da Microsoft diese Konstellation nicht mehr unterstützt. Siehe Microsoft TechNet-Website. |
|
|
|
Cluster |
|
|
Windows Server 2016-Cluster Unterstützt Quorum-Modelle:
|
Sowohl der Migrate-Client als auch die Weboberfläche unterstützen die automatisierte Migration von Windows-Clustern zu VMware vCenter-Containern. Der Migrate-Client unterstützt außerdem die halbautomatisierte Migration von Windows-Clustern zu physischen Computern über den X2P-Workflow. Weitere Informationen hierzu finden Sie in Abschnitt 23.0, Vorbereiten der Migration von Windows-Clustern. Für die Migration von Windows Server 2016-Clustern zu VMware ist VMware 6.0 (oder höher) erforderlich. PlateSpin Migrate unterstützt nicht die Migration von Windows Server-Clustern in die folgenden Ziel-Infrastrukturen:
PlateSpin Migrate unterstützt für Cluster lediglich die Reproduktion auf Blockebene. Die Reproduktion auf Dateiebene wird nicht unterstützt. Die Unterstützung umfasst die blockbasierte Datenübertragung mit einem Treiber (nur Fibre Channel SANs) oder ohne einen Treiber für inkrementelle Reproduktionen für Cluster. ACHTUNG:Versuchen Sie nicht, den blockbasierten Treiber auf Clustern mit freigegebenen iSCSI-Laufwerken zu verwenden. Dadurch können die Cluster nicht mehr verwendet werden. |
Unterstützt Quorum-Modelle:
|
|
Unterstützt Quorum-Modelle:
|
|
Unterstützt Quorum-Modell:
|
|
|
Desktops |
|
|
Windows 8 und 8.1 |
Der Hochleistungs-Energiesparplan ist erforderlich. |
|
Windows 7 |
Unterstützt lediglich Professional, Enterprise und Ultimate. |
PlateSpin Migrate unterstützt die nachfolgenden Linux-Plattformen für die Migration zu virtuellen Computern (auf Virtualisierungshosts) bzw. auf physischen Computern, mit Ausnahme der unter Tabelle 2-2 genannten Fälle. Weitere Informationen finden Sie auch unter Unterstützter Workload-Speicher und Unterstützte Workload-Architekturen.
Tabelle 2-2 Plattformen außerhalb der Cloud: Unterstützte Linux-Workloads
|
Linux-Distribution |
Version |
Anmerkungen |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
AS/ES/WS 4.x, 5.0 bis 5.11, 6.0 bis 6.9 und 7.0 bis 7.3 |
PlateSpin Migrate bietet keine Unterstützung für das XFS-Dateisystem Version 5 (v5) unter RHEL 7.3 und unter Distributionen auf der Grundlage von RHEL 7.3. Für Red Hat Enterprise Linux 6.7-, Oracle Linux 6.7- und CentOS 6.7-Workloads mit LVM-Volumes unterstützt PlateSpin Migrate die inkrementelle Reproduktion nur für den neuesten verfügbaren Kernel (Version 2.6.32-642.13.1.el6) für die 6.7-Distribution. Dies ist der gleiche Kernel, der von der RHEL 6.8-Distribution verwendet wird. Die Migration eines paravirtualisierten Ursprungs-Workloads zu einer Zielplattform als vollständig virtualisierter Workload wird für RHEL 5 unterstützt. Weitere Informationen hierzu finden Sie in Paravirtualisierte Ursprungs-Workloads. |
|
SUSE Linux Enterprise Server (SLES) |
9, 10, 11 (SP1, SP2, SP3 und SP4) |
SLES 11 SP2 (32 Bit) mit Kernel 3.0.13-0.27-pae wird nicht unterstützt. Der Kernel für diese Version von SLES muss auf 3.0.51-0.7.9-pae aufgerüstet werden, damit die Konvertierung funktioniert. Die Migration eines paravirtualisierten Ursprungs-Workloads zu einer Zielplattform als vollständig virtualisierter Workload wird für SLES 10 und 11 unterstützt. Weitere Informationen hierzu finden Sie in Paravirtualisierte Ursprungs-Workloads. |
|
CentOS |
Siehe Red Hat Enterprise Linux. |
Gleiche Unterstützung wie für Workloads, die RHEL ausführen; CentOS 4.x wird nicht für Hyper-V unterstützt. Für die Migration von CentOS 7.x zu VMware ist VMware vCenter 5.5 (oder höher) erforderlich. |
|
Oracle Linux (OL) (früher Oracle Enterprise Linux) |
Siehe Red Hat Enterprise Linux. |
Gleiche Unterstützung für Standard-Kernels wie für Workloads, die RHEL ausführen; OEL 4.x wird nicht für Hyper-V unterstützt. Gleiche Unterstützung für UEK-Kernels (Unbreakable Enterprise Kernel) auf unterstützten RHEL-Distributionen für OL 6.7 (oder höher) |
HINWEIS:Die folgenden Richtlinien gelten für Linux-Migrationen zu Zielplattformen außerhalb der Cloud:
Workload-Imaging wird für Linux-Workloads nicht unterstützt.
Die Konvertierung eines BIOS-basierten Linux-Systems in ein UEFI-basiertes System wird nicht unterstützt.
Um Workloads in Microsoft Azure und VMware vCloud Director zu migrieren, verwenden Sie die PlateSpin Migrate-Weboberfläche. Um Workloads in Amazon Web Services zu migrieren, verwenden Sie PlateSpin Migrate Client.
Nur P2C- und V2C-Migrationen werden unterstützt.
HINWEIS:
Nicht alle Workloads werden auf allen Ziel-Cloud-Plattformen unterstützt. Die Migration von Workloads zu einem Cloud-Container ist abhängig von der Unterstützung des Gast-Betriebssystems auf der Ziel-Cloud-Plattform durch den Cloud-Anbieter.
Windows- und Linux-UEFI-Workloads werden als BIOS-Workloads zur Ziel-Cloud-Plattform migriert.
Soll ein paravirtualisierter Linux-Ursprungs-Workload, der auf Citrix XenServer oder KVM ausgeführt wird, als vollständig virtualisierter Gast zu einer Zielplattform migriert werden, beachten Sie zunächst Paravirtualisierte Ursprungs-Workloads.
Lesen Sie hierzu die folgenden Abschnitte:
PlateSpin Migrate unterstützt die nachfolgenden Plattformen für die Migration zur Microsoft Azure-Cloud für die globale Umgebung oder zur unabhängigen chinesischen Azure-Umgebung. Weitere Informationen finden Sie auch unter Unterstützter Workload-Speicher und Unterstützte Workload-Architekturen.
Weitere Informationen zum Migrieren von Workloads zu Microsoft Azure finden Sie unter Voraussetzungen für die Migration zu Microsoft Azure und Migration zu Microsoft Azure.
Tabelle 2-3 Azure: Unterstützte Windows-Plattformen
|
Betriebssystem |
Anmerkungen |
|---|---|
|
Microsoft Windows Server 2016 |
|
|
Microsoft Windows Server 2012 R2 |
|
|
Microsoft Windows Server 2012 |
|
|
Microsoft Windows Server 2008 R2 |
|
Tabelle 2-4 Azure: Unterstützte Linux-Plattformen
|
Linux-Distribution |
Version |
Anmerkungen |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
6.7 bis 6.9 und 7.1 bis 7.3 |
PlateSpin Migrate bietet keine Unterstützung für das XFS-Dateisystem v5 unter RHEL 7.3 und unter Distributionen auf der Grundlage von RHEL 7.3. Für Red Hat Enterprise Linux 6.7-, Oracle Linux 6.7- und CentOS 6.7-Workloads mit LVM-Volumes wird eine inkrementelle Reproduktion nur für den neuesten verfügbaren Kernel (Version 2.6.32-642.13.1.el6) für die 6.7-Distribution unterstützt. Dies ist der gleiche Kernel, der von der RHEL 6.8-Distribution verwendet wird. |
|
SUSE Linux Enterprise Server (SLES) |
11 (SP3 und SP4) |
Die Migration eines paravirtualisierten Ursprungs-Workloads zu einer Zielplattform als vollständig virtualisierter Workload wird für SLES 11 unterstützt. Weitere Informationen hierzu finden Sie in Paravirtualisierte Ursprungs-Workloads. |
|
CentOS |
Siehe Red Hat Enterprise Linux. |
Gleiche Unterstützung wie für Workloads, die RHEL ausführen |
|
Oracle Linux (OL) (früher Oracle Enterprise Linux) |
Siehe Red Hat Enterprise Linux. |
Gleiche Unterstützung für Standard-Kernels wie für Workloads, die RHEL ausführen Gleiche Unterstützung für UEK-Kernels (Unbreakable Enterprise Kernel) auf unterstützten RHEL-Distributionen für OL 6.7 (oder höher) |
HINWEIS:PlateSpin Migrate unterstützt keine Migration von Linux-Ursprungs-Workloads zu Azure, wenn sich die Boot-Partition (/boot) auf einem anderen Datenträger befindet als die Root-Partition (/).
PlateSpin Migrate unterstützt die nachfolgenden Plattformen für die Migration zu VMware vCloud Director. Weitere Informationen finden Sie auch unter Abschnitt 2.1.3, Unterstützter Workload-Speicher und Abschnitt 2.1.4, Unterstützte Workload-Architekturen.
Weitere Informationen zum Migrieren von Workloads zu VMware Cloud Director finden Sie unter Abschnitt 10.0, Voraussetzungen für die Migration zu VMware vCloud Director und Abschnitt 29.0, Migration zu VMware vCloud Director.
Tabelle 2-5 vCloud: Unterstützte Windows-Plattformen
|
Betriebssystem |
Anmerkungen |
|---|---|
|
Microsoft Windows Server 2016 |
|
|
Microsoft Windows Server 2012 R2 |
|
|
Microsoft Windows Server 2012 |
|
|
Microsoft Windows Server 2008 R2 |
|
|
Microsoft Windows Server 2008 |
|
|
Microsoft Windows Server 2003 R2 |
DoNotReplaceSysFiles muss auf True eingestellt werden. |
|
Microsoft Windows Server 2003 mit Service Pack 1 (SP1) oder höher |
DoNotReplaceSysFiles muss auf True eingestellt werden. |
Tabelle 2-6 vCloud: Unterstützte Linux-Plattformen
|
Linux-Distribution |
Version |
Anmerkungen |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
4.x, 5.0 bis 5.11, 6.0 bis 6.9 und 7.0 bis 7.3 |
PlateSpin Migrate bietet keine Unterstützung für das XFS-Dateisystem v5 unter RHEL 7.3 und unter Distributionen auf der Grundlage von RHEL 7.3. Für Red Hat Enterprise Linux 6.7-, Oracle Linux 6.7- und CentOS 6.7-Workloads mit LVM-Volumes wird eine inkrementelle Reproduktion nur für den neuesten verfügbaren Kernel (Version 2.6.32-642.13.1.el6) für die 6.7-Distribution unterstützt. Dies ist der gleiche Kernel, der von der RHEL 6.8-Distribution verwendet wird. Die Migration eines paravirtualisierten Ursprungs-Workloads zu einer Zielplattform als vollständig virtualisierter Workload wird für RHEL 5 unterstützt. Weitere Informationen hierzu finden Sie in Paravirtualisierte Ursprungs-Workloads. |
|
SUSE Linux Enterprise Server (SLES) |
10 und 11 (SP1, SP2, SP3 und SP4) |
Die Migration eines paravirtualisierten Ursprungs-Workloads zu einer Zielplattform als vollständig virtualisierter Workload wird für SLES 10 und 11 unterstützt. Weitere Informationen hierzu finden Sie in Paravirtualisierte Ursprungs-Workloads. |
|
CentOS |
Siehe Red Hat Enterprise Linux. |
Gleiche Unterstützung wie für Workloads, die RHEL ausführen |
|
Oracle Linux (OL) (früher Oracle Enterprise Linux) |
Siehe Red Hat Enterprise Linux. |
Gleiche Unterstützung für Standard-Kernels wie für Workloads, die RHEL ausführen Gleiche Unterstützung für UEK-Kernels (Unbreakable Enterprise Kernel) auf unterstützten RHEL-Distributionen für OL 6.7 (oder höher) |
PlateSpin Migrate unterstützt die nachfolgenden Plattformen für die Migration zu Amazon Web Services. Weitere Informationen finden Sie auch unter Abschnitt 2.1.3, Unterstützter Workload-Speicher und Abschnitt 2.1.4, Unterstützte Workload-Architekturen.
Weitere Informationen zum Migrieren von Workloads zu Amazon Web Services finden Sie unter Abschnitt 8.0, Voraussetzungen für die Migration zu Amazon Web Services und Abschnitt 27.0, Migration zu Amazon Web Services.
Tabelle 2-7 AWS: Unterstützte Windows-Plattformen
|
Betriebssystem |
Anmerkungen |
|---|---|
|
Microsoft Windows Server 2016 |
|
|
Microsoft Windows Server 2012 R2 |
|
|
Microsoft Windows Server 2012 |
|
|
Microsoft Windows Server 2008 R2 |
|
|
Microsoft Windows Server 2008 |
|
|
Microsoft Windows Server 2003 R2 |
|
|
Microsoft Windows Server 2003 mit Service Pack 1 (SP1) oder höher |
|
Tabelle 2-8 AWS: Unterstützte Linux-Plattformen
|
Linux-Distribution |
Version |
Anmerkungen |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
5.1 bis 5.11, 6.1 bis 6.9 und 7.0 bis 7.3 |
PlateSpin Migrate bietet keine Unterstützung für das XFS-Dateisystem v5 unter RHEL 7.3 und unter Distributionen auf der Grundlage von RHEL 7.3. Für Red Hat Enterprise Linux 6.7-, Oracle Linux 6.7- und CentOS 6.7-Workloads mit LVM-Volumes wird eine inkrementelle Reproduktion nur für den neuesten verfügbaren Kernel (Version 2.6.32-642.13.1.el6) für die 6.7-Distribution unterstützt. Dies ist der gleiche Kernel, der von der RHEL 6.8-Distribution verwendet wird. Die Migration eines paravirtualisierten Ursprungs-Workloads zu einer Zielplattform als vollständig virtualisierter Workload wird für RHEL 5 unterstützt. Weitere Informationen hierzu finden Sie in Paravirtualisierte Ursprungs-Workloads. |
|
SUSE Linux Enterprise Server (SLES) |
11 (SP2 und SP3) |
Die Migration eines paravirtualisierten Ursprungs-Workloads zu einer Zielplattform als vollständig virtualisierter Workload wird für SLES 11 unterstützt. Weitere Informationen hierzu finden Sie in Paravirtualisierte Ursprungs-Workloads. |
|
CentOS |
Siehe Red Hat Enterprise Linux. |
Gleiche Unterstützung wie für Workloads, die RHEL ausführen |
|
Oracle Linux (OL) (früher Oracle Enterprise Linux) |
Siehe Red Hat Enterprise Linux. |
Gleiche Unterstützung für Standard-Kernels wie für Workloads, die RHEL ausführen Gleiche Unterstützung für UEK-Kernels (Unbreakable Enterprise Kernel) auf unterstützten RHEL-Distributionen für OL 6.7 (oder höher) |
Die folgenden Workload-Speicherrichtlinien gelten für alle Migrationen:
PlateSpin Migrate unterstützt die Partitionierungsschemata MBR (Master Boot Record) und GPT (GUID-Partitionstabelle) für Windows- und Linux-Workloads. Die Workloads und der Speicher für die Migration müssen auf Datenträgern konfiguriert sein, die mit MBR oder GPT partitioniert sind. Bei GPT sind bis zu 128 Partitionen pro Datenträger zulässig; PlateSpin Migrate unterstützt jedoch nur maximal 57 GPT-Partitionen pro Datenträger.
PlateSpin Migrate unterstützt auf allen unterstützten Windows-System ausschließlich das NTFS-Dateisystem. Windows-FAT- oder ReFS-Dateisysteme werden bei der Migration nicht unterstützt.
HINWEIS:Wenn die Volumes mit der BitLocker-Datenträgerverschlüsselungsfunktion verschlüsselt sind, müssen sie zur Migration entsperrt (entschlüsselt) werden.
PlateSpin Migrate unterstützt die Dateisysteme EXT2, EXT3, EXT4, REISERFS und XFS.
HINWEIS:
PlateSpin Migrate bietet keine Unterstützung für das XFS-Dateisystem v5 unter RHEL 7.3 und unter Distributionen auf der Grundlage von RHEL 7.3.
Die Migration von verschlüsselten Volumes wird nicht unterstützt. Wenn die Volumes verschlüsselt sind, müssen sie zur Migration entsperrt (entschlüsselt) werden.
PlateSpin Migrate unterstützt mehrere Arten von Datenplatten, darunter einfache Festplatten, dynamische Windows-Ursprungsdatenträger, LVM2, RAID, NAS und SAN.
HINWEIS:Für Speicherdatenträger gelten die folgenden Einschränkungen:
Dynamische Festplatten unter Windows: PlateSpin Migrate unterstützt keine dynamischen Windows-Datenträger im Ziel.
Bei dynamischen Datenträgern befolgt der Speicher nicht die Zuordnungsstrategie „Wie Ursprung“. Sowohl einfache dynamische Volumes als auch übergreifende dynamische Volumes werden im Ziel-Workload als einfache Basis-Volume-Datenträger behandelt. Der Zieldatenträger wird mit GPT partitioniert, wenn die Gesamtgröße der Mitgliedsdatenträger im dynamischen Volume die maximal zulässige MBR-Partitionsgröße überschreitet. Weitere Informationen finden Sie unter Microsoft TechNet: Understanding the 2 TB limit in Windows Storage.
Linux-Software-RAID: PlateSpin Migrate unterstützt keine Linux-Workloads mit Volumes auf Software-RAIDs.
Migrate unterstützt Linux-Workloads, für die /boot auf den ersten Datenträger (sda) eingestellt ist.
Auf der Bootpartition eines Linux-Ursprungs-Workloads müssen mindestens 100 MB Speicherplatz frei sein. Im Rahmen der Migration legt PlateSpin Migrate im freien Speicherplatz ein neues initrd-Image mit allen erforderlichen Treibern an, damit der Computer erstmalig gebootet werden kann.
Nicht-Volume-Speicher wie eine Swap-Partition, die mit dem Ursprungs-Workload verknüpft ist, werden im migrierten Workload neu erstellt.
Bei der Zuordnungsstrategie „Wie Ursprung“ bleibt die Anordnung der Volume-Gruppen und der logischen Volumes für LVM2 unverändert erhalten und kann während der Migration neu angelegt werden.
LVM-Rohdatenträger-Volumes werden in Speicherkonfigurationen des Typs „Wie Ursprung“ in Linux-Workloads unterstützt.
Bei Linux-Workloads unterstützt Migrate lediglich die blockbasierte Live-Datenübertragung mit einem blkwatch-Treiber. Eine Liste der vorkonfigurierten blkwatchTreiber finden Sie unter Abschnitt D.2.2, Liste der Verteilungen.
Einige der unterstützten Linux-Versionen erfordern, dass Sie das PlateSpin blkwatch-Modul für Ihren spezifischen Kernel kompilieren. Diese Workloads werden explizit ausgerufen.
Vorkompilierte blkwatch-Treiber sind wie in Abschnitt D.2.2, Liste der Verteilungen angegeben für den Standardkernel und den Unbreakable Enterprise Kernel (UEK) verfügbar. Für andere Oracle Linux-Distributionen sind vorkompilierte Treiber nur für den entsprechenden Red Hat Compatible Kernel (RHCK) verfügbar.
PlateSpin Migrate unterstützt das FC-SAN-Datenübertragungsprotokoll (Fibre Channel).
Fibre Channel over Ethernet (FCoE) wird für P2P- und P2V-Migrationen der Workloads unterstützt, die unter Tabelle 2-9 aufgeführt sind. Die Migration wurde mit FCoE-Geräten von Qlogic getestet.
Tabelle 2-9 Unterstützte Ursprungs-Workloads für FCoE
|
Ursprungs-Workloads mit FCoE |
Version |
Anmerkungen |
|---|---|---|
|
|
Nur eigenständige Server; keine Cluster |
|
SUSE Linux Enterprise Server |
11 SP4 |
|
Das PlateSpin-ISO-Image umfasst FCoE-Treiber und die FCoE-Unterstützung. Weitere Informationen hierzu finden Sie in Herunterladen der PlateSpin-ISO-Images.
PlateSpin Migrate unterstützt die Migration eines für MPIO (Multipath I/O) konfigurierten Ursprungs-Workloads in einer FC-SAN-Umgebung (Fibre Channel). Der Ziel-Workload kann sich in derselben oder in einer anderen SAN-Umgebung befinden. Der Ursprungs- und der Ziel-Workload müssen ausschließlich SAN-Datenträger umfassen.
HINWEIS:Der Workload muss von einem SAN-Datenträger gebootet werden. Workloads mit gemischten lokalen Datenträgern und SAN-Datenträgern werden nicht unterstützt, soweit nicht unter Tabelle 2-10 anders angegeben.
Das PlateSpin-ISO-Image umfasst die MPIO-Unterstützung. Weitere Informationen hierzu finden Sie in Herunterladen der PlateSpin-ISO-Images.
Unter Tabelle 2-10 finden Sie eine Liste der Plattformen, die für Migrationen in MPIO-Umgebungen getestet wurden.
Tabelle 2-10 Unterstützte Ursprungs-Workloads für MPIO
|
Plattform |
Version |
Anmerkungen |
|---|---|---|
|
Microsoft Windows Server |
|
|
|
Microsoft Windows-Server in einem Failover-Cluster |
2012 R2 |
Die Cluster-Migration wurde auch mit einem lokalen Systemdatenträger getestet, wobei sich alle Datenplatten in einem FC-SAN befanden. Weitere Informationen zum Wiederherstellen des Clusters nach der Migration des aktiven Knotens auf einen neuen freigegebenen FC-Speicher finden Sie im KB-Artikel 7022400. |
|
Red Hat Enterprise Linux (RHEL) |
|
|
Für MPIO muss zusätzliche Multipath-Software im Betriebssystem installiert sein (als Windows-Funktion oder als Linux-Paket/-Modul). Mit den MPIO-Verwaltungstools aktivieren und konfigurieren Sie MPIO-Richtlinien für SAN-Geräte mit mehreren Pfaden. Weitere Informationen zum Einrichten der Hardware mit mehreren Pfaden für ein Speichergerät sowie zum Installieren und Konfigurieren von MPIO finden Sie in der Herstellerdokumentation.
Weitere Informationen zu unterstützten MPIO-Migrationsszenarien und zu den Erwartungen an die Ziel-Workloads finden Sie unter Tabelle 2-11.
Tabelle 2-11 Unterstützte MIPO-Migrationsszenarien
|
Quell-Workload |
Ziel-Workload |
|
|---|---|---|
|
MPIO-Software |
Mehrere Speicherpfade verfügbar |
Einzelner Speicherpfad verfügbar |
|
Die MPIO-Software ist installiert. MPIO ist aktiviert und konfiguriert. |
Die MPIO-Software wird auf dem Ziel-Workload automatisch für die MPIO-Zielumgebung neu konfiguriert. Soll MPIO deaktiviert werden, müssen Sie MPIO im Workload manuell neu konfigurieren. |
Die MPIO-Software bleibt erhalten und MPIO wird für einen einzelnen Pfad neu konfiguriert. Sie können die Software beibehalten oder manuell entfernen, je nach dem geplanten Netzwerk. Wenn Sie nach der Migration weitere MPIO-Hardware hinzufügen, müssen Sie MPIO im Workload manuell neu konfigurieren. |
|
Die MPIO-Software ist installiert. MPIO ist deaktiviert. |
Die MPIO-Software bleibt installiert, wird jedoch deaktiviert. Soll MPIO aktiviert werden, müssen Sie MPIO im Workload manuell konfigurieren. |
Die MPIO-Software bleibt installiert, wird jedoch deaktiviert. Sie können die Software beibehalten oder manuell entfernen, je nach dem geplanten Netzwerk. Wenn Sie nach der Migration weitere MPIO-Hardware ergänzen, müssen Sie MPIO im Workload manuell konfigurieren. |
|
Die MPIO-Software ist nicht installiert. |
Die MPIO-Software ist nicht installiert. Soll MPIO aktiviert werden, müssen Sie MPIO im Workload manuell installieren und konfigurieren. |
Am Workload werden keine MPIO-spezifischen Veränderungen vorgenommen. |
Die folgenden Workload-Architekturrichtlinien gelten für alle Migrationen:
Linux-basierte Ursprungs-Workloads müssen auf einem Secure Shell (SSH)-Server ausgeführt werden.
PlateSpin Migrate unterstützt die Migration von x86-basierten physischen und virtuellen Workloads in Ihrem Rechenzentrum:
64 Bit
32 Bit
Für VM-Container mit VMware 5.1, 5.5 und 6.0 und mindestens VM-Hardware-Ebene 8 ermöglicht es PlateSpin Migrate, die Anzahl der Sockets sowie die Anzahl der Kerne pro Socket für den Ziel-Workload anzugeben. Die Gesamtzahl der Kerne wird automatisch berechnet. Dieser Parameter gilt für die anfängliche Einrichtung eines Workloads mit der anfänglichen Reproduktionseinstellung Vollreproduktion.
HINWEIS:Die maximale Anzahl der Kerne, die ein Workload nutzen kann, ist abhängig von externen Faktoren, beispielsweise vom Gast-Betriebssystem, von der VM-Hardware-Version, der VMware-Lizenzierung für den ESXi-Host und den berechneten ESXi-Host-Höchstwerten für vSphere (siehe ESXi/ESX – Konfigurationshöchstwerte (VMware-KB 1003497)).
In bestimmten Distributionen von Gast-Betriebssystemen wird die Konfiguration der Kerne und der Kerne pro Socket unter Umständen nicht berücksichtigt. Gast-Betriebssysteme mit SLES 10 SP4 behalten beispielsweise die ursprünglich installierten Einstellungen für Kerne und Sockets bei, während andere SLES- und RHEL-Distributionen die Konfiguration beachten.
Für VM-Container mit VMware 4.1 können Sie in PlateSpin Migrate die erforderliche Anzahl von vCPUs (virtuellen CPUs) angeben, die dem Ziel-Workload zugewiesen werden sollen. Dieser Parameter gilt für die anfängliche Einrichtung eines Workloads mit der anfänglichen Reproduktionseinstellung Vollreproduktion. Die vCPUs werden im Gast-Betriebssystem auf dem VM-Container jeweils als CPU mit einem einzelnen Kern und einem einzelnen Socket dargestellt.
Die Migration UEFI-basierter Windows- und Linux-Ursprungs-Workloads wird für alle Zielplattformen unterstützt. Bei den Ziel-Cloud-Plattformen Amazon Web Services, Microsoft Azure und VMware vCloud Director wird der Ziel-Workload von UEFI in BIOS konvertiert. Bei anderen Plattformen wird der Ziel-Workload als UEFI oder BIOS konfiguriert, je nach Unterstützung durch den Anbieter der Zielplattform.
Hierbei werden Workloads vom Ursprung zum Ziel übertragen, während die unterstütze Firmware für das zugehörige Ursprungs- bzw. Zielbetriebssystem durchgesetzt wird. Sobald eine Migration zwischen UEFI- und BIOS-Systemen eingeleitet wird, analysiert Migrate diesen Übergang und Sie erhalten eine Mitteilung über dessen Gültigkeit.
HINWEIS:Wenn Sie einen UEFI-basierten Workload zu einem vSphere-Zielcontainer migrieren und weiterhin denselben Firmware-Startmodus nutzen möchten, muss der Zielcontainer mindestens vSphere 5.0 aufweisen.
Die folgenden Beispiele zeigen das Migrate-Verhalten bei der Konvertierung zwischen UEFI- und BIOS-basierten Systemen:
Beim Migrieren eines UEFI-basierten Workloads zu einem VMware vSphere 4.x- oder Cloud-Container (der UEFI nicht unterstützt) führt Migrate einen Übergang der UEFI-Firmware des Workloads in BIOS-Firmware aus.
Beim Migrieren eines UEFI-basierten Ursprungs zu einem BIOS-basierten Ziel konvertiert Migrate die Startlaufwerke des UEFI-Systems (bislang GPT) in MBR-Laufwerke.
(Für Windows-Workloads) Wenn Sie einen BIOS-Workload zu einem UEFI-basierten Ziel migrieren, konvertiert Migrate die Startlaufwerke des BIOS-Systems (bislang MBR) in GPT-Laufwerke.
Die Konvertierung von paravirtualisiert zu vollständig virtualisiert wird für die folgenden Ursprungs-Workloads auf einem Citrix XenServer oder einem virtuellen KVM-Host unterstützt:
Red Hat Enterprise Linux (RHEL) 6.0 und Linux-Distributionen auf der Grundlage von RHEL 6.0
Red Hat Enterprise Linux (RHEL) 5.x und Linux-Distributionen auf der Grundlage von RHEL 5.x
SUSE Linux Enterprise Server 10 und 11
Es werden nur blockbasierte Konvertierungen unterstützt.
Soll ein paravirtualisierter Linux-Ursprungs-Workload, der auf Citrix XenServer oder KVM ausgeführt wird, als vollständig virtualisierter Gast zu einer Zielplattform migriert werden, gehen Sie wie folgt vor:
Sowohl der paravirtuelle Kernel als auch der Standard-Kernel müssen im paravirtualisierten Ursprungs-Workload installiert sein.
Kompilieren Sie die blockbasierten Treiber für den Xen-Kernel manuell.
PlateSpin Migrate unterstützt die nachfolgenden Ziel-Virtualisierungsplattformen.
Unter Tabelle 2-12 finden Sie die unterstützten VMware-Zielplattformen für die PlateSpin Migrate-Weboberfläche und den Migrate-Client. Der Migrate-Client unterstützt die automatisierte Migration und die halbautomatisierte Migration mit dem X2P-Workflow. Die Weboberfläche unterstützt die automatisierte Migration. Weitere Informationen hierzu finden Sie in:
Siehe auch Voraussetzungen für die Migration zu VMware.
HINWEIS:Weitere Informationen zum Erstellen des VM-Zieldatenträgers auf VMware-Containern mit RDM (Raw Device Mapping) finden Sie unter Migration zu VMware.
Unter Tabelle 2-13 finden Sie eine Liste der unterstützten Zielvirtualisierungsplattformen für den PlateSpin Migrate-Client mit dem halbautomatisierten X2P-Workflow.
HINWEIS:
Die Migration von Workloads zu einer Ziel-Virtualisierungsplattform ist abhängig von der Unterstützung des Gast-Betriebssystems auf dem Ziel-Host durch den Host-Anbieter.
Für den migrierten Ziel-Workload benötigen Sie eine Betriebssystemlizenz.
Tabelle 2-12 Unterstützte VMware-Zielplattformen für PlateSpin Migrate-Weboberfläche und Migrate-Client
|
Plattform |
Version |
Anmerkungen |
|---|---|---|
|
VMware vCenter |
|
Bei vCenter 6.2 werden Zielcontainer mit VMware Virtual SAN (vSAN) 6.2-Speicher unterstützt. Bei vCenter 5.5 werden Zielcontainer mit VMware Virtual SAN (vSAN) 5.5-Speicher unterstützt. RDM (Raw Device Mapping) für Ziel-VMs wird über den X2P-Workflow unterstützt. Die folgenden VMware-Datenablagetypen in VMware 6.0 (oder höher) werden nicht unterstützt:
|
|
VMware ESXi |
|
Alle ESXi-Versionen erfordern eine erworbene Lizenz. Die Migration wird bei diesen Systemen nicht unterstützt, wenn sie mit einer kostenlosen Lizenz ausgeführt werden. RDM (Raw Device Mapping) für Ziel-VMs wird über den X2P-Workflow unterstützt. Die folgenden VMware-Datenablagetypen in VMware 6.0 (oder höher) werden nicht unterstützt:
|
|
VMware ESX |
|
RDM (Raw Device Mapping) für Ziel-VMs wird über den X2P-Workflow unterstützt. |
Tabelle 2-13 Unterstützte Ziel-Virtualisierungsplattformen nur für Migrate-Client
|
Plattform |
Version |
Anmerkungen |
|---|---|---|
|
Microsoft Windows Server mit Hyper-V |
|
Unterstützt über den automatisierten Workflow oder den X2P-Workflow. Siehe Siehe auch Voraussetzungen für die Migration zu Microsoft Hyper-V. |
|
Citrix XenServer |
6.0 bis 6.2 und 6.5 |
Vollständig virtualisierte Gäste werden unterstützt. Booten Sie den virtuellen Computer mit der PlateSpin-ISO für SUSE Linux Enterprise Server 11 SP3 als LRD. Citrix XenServer 6.5 (oder früher) bietet keine Unterstützung für SLES 11 SP4. Unterstützt über den X2P-Workflow. Weitere Informationen hierzu finden Sie in Migration zu virtuellen Computern auf Citrix XenServer. Siehe auch Voraussetzungen für die Migration zu VMs auf Citrix XenServer. |
|
SUSE Linux Enterprise Server mit Xen |
11 SP3 und 11 SP4 |
Vollständig virtualisierte Gäste werden unterstützt. Unterstützt über den X2P-Workflow. Weitere Informationen hierzu finden Sie in Migration zu virtuellen Maschinen auf Xen. Siehe auch Voraussetzungen für die Migration zu VMs auf Xen. |
|
SUSE Linux Enterprise Server (SLES) mit KVM |
11 SP4 und 12 SP1 |
Vollständig virtualisierte Gäste werden unterstützt. Virtio-Geräte werden unterstützt. Unterstützt über den X2P-Workflow. Weitere Informationen hierzu finden Sie in Migration zu virtuellen Maschinen auf KVM. Siehe auch Voraussetzungen für die Migration zu VMs auf KVM. |
|
Red Hat Enterprise Linux (RHEL) mit KVM |
7.0 und 7.2 |
Vollständig virtualisierte Gäste werden unterstützt. Virtio-Geräte werden unterstützt. Unterstützt über den X2P-Workflow. Weitere Informationen hierzu finden Sie in Migration zu virtuellen Maschinen auf KVM. Siehe auch Voraussetzungen für die Migration zu VMs auf KVM. |
PlateSpin Migrate unterstützt die Migration von Workloads zu Ziel-Cloud-Plattformen. Microsoft Azure und VMware vCloud Director werden in der Migrate-Weboberfläche unterstützt. Amazon Web Services wird im Migrate-Client unterstützt. Weitere Informationen hierzu finden Sie unter Tabelle 2-14 und Tabelle 2-15.
Tabelle 2-14 Unterstützte Ziel-Cloud-Plattformen für die Migrate-Weboberfläche
|
Plattform |
Version |
Anmerkungen |
|---|---|---|
|
Microsoft Azure |
|
Jeder PlateSpin-Server kann nur jeweils eine der unterstützten Azure-Umgebungen unterstützen, nicht beide Umgebungen gleichzeitig. Weitere Informationen hierzu finden Sie in Abschnitt 9.9, Konfigurieren der IaaS-Zielumgebung für die Azure-Cloud. HINWEIS:Weitere Informationen zum Migrieren von Workloads zu anderen unabhängigen Azure-Umgebungen erhalten Sie beim Micro Focus-Support und Kundendienst. Siehe auch Voraussetzungen für die Migration zu Microsoft Azure. |
|
VMware vCloud Director |
5.5.x und 5.6.x |
Siehe auch Voraussetzungen für die Migration zu VMware vCloud Director. |
Tabelle 2-15 Unterstützte Ziel-Cloud-Plattform für den Migrate-Client
|
Plattform |
Version |
Anmerkungen |
|---|---|---|
|
Amazon Web Services (AWS) |
Amazon EC2-Umgebung |
Siehe auch Voraussetzungen für die Migration zu Amazon Web Services. |
Zusätzlich zu Englisch unterstützt PlateSpin Migrate die Landessprachen vereinfachtes Chinesisch (ZH-CN), traditionelles Chinesisch (ZH-TW), Französisch (FR-FR), Deutsch (DE-DE) und Japanisch (JA-JP).
Für diese Sprachen sowie für Spanisch (ES-ES) und brasilianisches Portugiesisch (PT-BR) steht eine lokalisierte Online-Dokumentation zur Verfügung.
Die PlateSpin Migrate-Weboberfläche und die PlateSpin-Konfigurationsoptionen sind über einen unterstützten Webbrowser verfügbar:
Google Chrome, Version 34.0 und höher
Microsoft Internet Explorer, Version 11.0 und höher
Mozilla Firefox, Version 29.0 und höher
HINWEIS:JavaScript (Active Scripting) muss in Ihrem Browser aktiviert sein.
Informationen zur Verwendung der Weboberfläche in einer der unterstützten internationalen Sprachen finden Sie unter Konfigurieren der Spracheinstellungen für internationale Versionen.