Erfolgreiche Planung und Ausführung von Projekten
Werbung
White Paper PlateSpin Transformation Manager PlateSpin Migrate Erfolgreiche Planung und Ausführung von Projekten zur Migration großer Workloads Aktualisiert für PlateSpin Transformation Manager 1.1 und PlateSpin Migrate 12.2 Inhaltsverzeichnis Seite Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 An wen richtet sich dieses White Paper?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Über Workloads und ihre Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Einführung in PlateSpin Migrate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Einführung in PlateSpin Transformation Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Planen von Projekten zur Migration großer Workloads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Erstellen einer für den Projektumfang geeigneten Migrationsinfrastruktur. . . . . . 11 Ausführungsdynamik von Projekten zur Migration großer Workloads. . . . . . . . . . . 15 Erwerb einer Zertifizierung als PlateSpin Migrationsspezialist. . . . . . . . . . . . . . . . . . . 18 Einleitung In der dynamischen Welt von heute wird die Organisation der IT-Ressourcen ständig durch die Notwendigkeit von Kostensenkungen und den Wunsch nach einer höheren operativen Effizienz beeinflusst. Unternehmen suchen unermüdlich nach besseren Möglichkeiten zur Verwaltung ihrer Infrastrukturen, Systeme und Anwendungen – das führt oft zu Projekten, bei denen zahlreiche Workloads zwischen verschiedenen Plattformen und Rechenzentren verschoben werden. Typische Beispiele sind die Migration physischer Server auf eine virtuelle Plattform, die Migration virtueller Maschinen von einer virtuellen Plattform auf eine andere, die Migration lokaler Workloads in eine Public oder Managed Cloud sowie die traditionelle Konsolidierung von Rechenzentren. An wen richtet sich dieses White Paper? Dieses White Paper richtet sich speziell an Projektmanager und Projektarchitekten, die mit der Durchführung von Projekten zur Migration großer Workloads mithilfe von Micro Focus PlateSpin-Tools wie PlateSpin Transformation Manager und PlateSpin Migrate betraut sind. Zusammen können PlateSpin Transformation Manager und PlateSpin Migrate zu einer um bis zu 50 % effizienteren Ausführung von Transformationsprojekten in Rechenzentren bei zugleich minimaler Ausfallzeit der Anwendungen beitragen. Darüber hinaus werden die Risiken gemindert, flexible Tests ermöglicht, die Anzahl von menschlichen Fehlern verringert und die Gesamtausführungszeit der Projekte drastisch verkürzt. _________________________________________________________________ www.microfocus.com 1 White Paper Erfolgreiche Planung und Ausführung von Projekten zur Migration großer Workloads PlateSpin bietet eine um bis zu 50 Prozent höhere Geschwindigkeit, sodass mehr Workloads in kürzerer Zeit und mit besseren Ergebnissen migriert werden können. Abb. 1 PlateSpin bietet eine um bis zu 50 Prozent höhere Geschwindigkeit, sodass mehr Workloads in kürzerer Zeit und mit besseren Ergebnissen migriert werden können. _________________________________________________________________ Über Workloads und ihre Migration Zum Zwecke dieses White Papers steht der Begriff „Workload“ zusammenfassend für ein Betriebssystem einschließlich aller darauf installierten Anwendungen, aller Patches und Konfigurationseinstellungen sowie aller Datendateien oder -blocks, die sich auf den Datenvolumes des Systems befinden. 2 Mit PlateSpin Migrate ist sichergestellt, dass der neue Workload schnell und automatisch erstellt wird und die Funktionalität genau der des OriginalWorkloads entspricht. Workload-Migrationen sind ein wichtiger Bestandteil in vielen, wenn nicht sogar allen, Transformationsprojekten heutiger Rechenzentren. Bei Transformationsprojekten in Rechenzentren ist es für die Migration nicht erstrebenswert, Workloads auf einer neuen Plattform wieder vollkommen neu aufzubauen. Dies liegt daran, dass der Neuaufbau ein manueller, langsamer und fehleranfälliger Prozess ist, der eine Unmenge an kostenintensiven Tests erfordert, um sicherzustellen, dass der Aufbau des neuen Workloads exakt dem Original entspricht. Bei echten Workload-Migrationsvorgängen, wie z. B. mithilfe von PlateSpin Migrate, werden die Blöcke oder Daten des Original-Workloads in eine Reproduktion auf der neuen (Ziel-)Plattform gestreamt. Mit PlateSpin Migrate ist sichergestellt, dass der neue Workload schnell und automatisch erstellt wird und die Funktionalität genau der des OriginalWorkloads entspricht. Workload-Migrationen sind ein wichtiger Bestandteil in vielen, wenn nicht sogar allen, Transformationsprojekten heutiger Rechenzentren. Einführung in PlateSpin Migrate PlateSpin Migrate ist eine leistungsstarke Lösung für Workload-Portabilität zur Automatisierung der Migration von Workloads zwischen physischen Servern, virtuellen Hosts und der Cloud über ein Netzwerk. Mit PlateSpin Migrate werden Workloads per Remote-Zugriff von der zugrunde liegenden Serverhardware entkoppelt, sodass sie von einem zentralen Punkt beliebig zwischen physischen und virtuellen Hosts verschoben werden können. Auf diese Weise erhalten Unternehmen und Service-Anbieter eine ausgereifte, bewährte und auf Data Center spezialisierte Lösung zum infrastrukturübergreifenden Testen, Migrieren und Neuverteilen von Workloads. PlateSpin Migrate unterstützt die folgenden wesentlichen Arten der Workload-Migration: Physisch zu physisch (P2P) – Zum Beispiel das Verschieben von Workloads von einem ­ausgedienten physischen Server auf ein neueres Modell Physisch zu virtuell (P2V) und umgekehrt – Zum Beispiel die Virtualisierung von Workloads, die zurzeit auf einem physischen Server ausgeführt werden Virtuell zu virtuell (V2V) – Zum Beispiel Migrationsvorgänge von VMware auf Hyper-V und umgekehrt Physisch oder virtuell in die Cloud (X2C) und umgekehrt Die folgenden Verfahren werden von PlateSpin Migrate nicht unterstützt: Migrationsvorgänge auf Anwendungsebene Konvertierungen von Unix auf Linux Aktualisierung von Betriebssystemen www.microfocus.com 3 White Paper Erfolgreiche Planung und Ausführung von Projekten zur Migration großer Workloads Zu den wichtigsten Merkmalen von PlateSpin Migrate zählen: Funktionen zur plattformunabhängigen Workload-Migration (einschließlich der meisten führenden Hypervisor-Plattformen und Microsoft Azure) Unterstützung für Workloads auf Basis der meisten Unternehmensversionen von Windows und Linux Mehrere automatisierte inkrementelle Reproduktionen und Testpunkte vor der endgültigen Umstellung vom Quell- auf den Ziel-Workload. Der Wechsel bezeichnet den Zeitpunkt, an dem die Benutzer von dem ausgedienten Server (Quell-Workload) auf den neuen Server (Ziel-Workload) umziehen. In der Regel wird der Quell-Workload bei diesem Vorgang heruntergefahren oder außer Betrieb gesetzt. Möglichkeit zur Skalierung auf bis zu 40 gleichzeitige Migrationsvorgänge pro PlateSpin Migrate-Server Branchenweit führende Automatisierung, einschließlich der Unterstützung für Hooks nach der Migration und einer Kommandozeilenschnittstelle (CLI) Eine typische Workload-Migration mit PlateSpin Migrate umfasst zwei Arten von Reproduktionen: eine vollständige Reproduktion und eine oder mehrere inkrementelle Reproduktionen. Die inkrementellen Reproduktionen werden auch als Synchronisierungen bezeichnet. Die erste Reproduktion des Workloads ist fast immer eine vollständige Reproduktion, d. h. alle Blöcke oder Dateien des Quell-Workloads werden auf den Ziel-Workload übertragen. Nach Abschluss dieser ersten vollständigen Reproduktion wird der Ziel-Workload üblicherweise getestet. Änderungen, die während der Dauer dieser Tests am Quell-Workload vorgenommen werden, müssen daraufhin vor der endgültigen Umstellung mindestens einmal synchronisiert werden. Die Synchronisierung dieser Änderungen erfolgt im Zuge einer inkrementellen Reproduktion. Wenn die Tests sehr lange dauern, werden gewöhnlich mehrere inkrementelle Reproduktionen durchgeführt. Zum Schluss findet die Umstellung des Workloads in Kombination mit einer endgültigen inkrementellen Reproduktion statt, um sicherzustellen, dass alle Änderungen erfasst und synchronisiert wurden. Der Quell-Workload bleibt während des gesamten Prozesses online und für die Unternehmensbenutzer vollständig verfügbar. Erst während der allerletzten Synchronisierung und der abschließenden Umstellung müssen die Dienste für kurze Zeit heruntergefahren werden, ehe sie auf dem Ziel-Workload wieder gestartet werden. Um diese Dienstausfallzeit auf ein Minimum zu beschränken, wurde PlateSpin so konzipiert, dass die zur Synchronisierung benötigte Zeit minimiert wird. Zu diesem Zweck hat PlateSpin einen optional erhältlichen Treiber für blockbasierte Übertragungen (Block-Based Transfer, BBT) entwickelt. Dieser Treiber kann auf dem Quell-Workload installiert werden, um nachzuvollziehen, welche Blöcke zwischen den verschiedenen Reproduktionen geändert wurden. Zu Beginn der Synchronisierung werden diese geänderten Blöcke umgehend durch den Treiber ermittelt und auf den Ziel-Workload übertragen. Der Treiber ist für die Durchführung einer Migration zwar nicht unbedingt erforderlich, jedoch verkürzt er deutlich die für eine Synchronisierung benötigte Zeit. 4 Mit jedem PlateSpin Migrate-Server können in der Regel mehrere hundert Migrationen verwaltet werden, von denen jeweils vierzig zur gleichen Zeit aktiv ausgeführt und reproduziert werden können. Bei großen Projekten empfiehlt es sich, die Migrationen insgesamt über horizontal skalierende PlateSpin MigrateServer zu verteilen. Da alle Daten zentral in der PlateSpin Transformation ManagerDatenbank verwaltet werden, kann der Status des Projekts zu jeder Zeit auf einem Dashboard grafisch dargestellt und optional für den Endkunden freigegeben werden. In PlateSpin Migrate kommt Microsoft SQL Server als Datenbank-Backend zum Einsatz. Dabei können mehrere PlateSpin Migrate-Server gemeinsam auf dieselbe SQL Server-Instanz zugreifen. Dadurch wird die horizontale Skalierung der Migrationsserver vereinfacht. Mit jedem PlateSpin Migrate-Server können in der Regel mehrere hundert Migrationen verwaltet werden, von denen jeweils vierzig zur gleichen Zeit aktiv ausgeführt und reproduziert werden können. Für bestmögliche Leistung empfiehlt es sich, die Gesamtanzahl der Migrationsvorgänge auf mehrere horizontal skalierte PlateSpin Migrate-Server zu verteilen, die von einem PlateSpin Transformation Manager-Server zentral verwaltet werden. Einführung in PlateSpin Transformation Manager PlateSpin Transformation Manager wurde von Grund auf für die ordnungsgemäße Planung, Nachverfolgung und Optimierung von Transformationsprojekten in Rechenzentren konzipiert und wird in der Regel in Kombination mit einem Migrationswerkzeug für Workloads verwendet, wie z. B. PlateSpin Migrate. Die Software verfügt über eine Client-Server-Architektur und ermöglicht es mehreren Benutzern mit unterschiedlichen Rollen, zur gleichen Zeit über einen Webbrowser sicher auf Projektdaten zuzugreifen und diese zu aktualisieren. Dank der Mandantenfähigkeit der Software können mehrere Projekte für unterschiedliche Endkunden gleichzeitig abgewickelt werden. Es wird sichergestellt, dass die Daten unterschiedlicher Kunden ordnungsgemäß voneinander getrennt bleiben und kein Kunde Zugriff auf fremde Daten erhält. Informationen über Quell-Workloads können problemlos in Form eines Tabellendokuments oder über die PlateSpin Transformation Manager-API in ein Projekt importiert werden. Alternativ können die Daten automatisch in Echtzeit von PlateSpin Transformation Manager selbst abgerufen werden. Diese Daten können während der Projektausführung kontinuierlich aktualisiert werden, damit sie alle eventuellen Änderungen an der Quellumgebung widerspiegeln. Nachdem alle Workload-Daten importiert wurden, kann mit der Planung des Projekts begonnen werden. Projektmanager können verschiedene Benutzer unterschiedlichen Projekten zuweisen und große Projekte in kleinere Datenblöcke (sogenannte Waves und Batches) aufteilen, um Projekte in mehreren verwaltungsfreundlichen Teilen auszuführen. Für jeden Workload kann der endgültige Zustand und das letztendliche Ziel festgelegt werden, lange bevor die eigentliche Migration stattfindet. Sobald der endgültige Zustand des Workloads ausreichend beschrieben wurde, kann er an einen Migrationsspezialisten gesendet werden, der innerhalb des geplanten Zeitrahmens für seine Ausführung sorgt. Da alle Daten zentral in der PlateSpin Transformation Manager-Datenbank verwaltet werden, kann der Status des Projekts zu jeder Zeit auf einem Dashboard grafisch dargestellt optional für den Endkunden freigegeben werden. _________________________________________________________________ www.microfocus.com 5 White Paper Erfolgreiche Planung und Ausführung von Projekten zur Migration großer Workloads Kernrollen von PlateSpin Transformation Manager: Administrator Projektleiter Projektarchitekt Migrationsspezialist Dashboard-Betrachter Abb. 2 PlateSpin Transformation Manager ermöglicht es mehreren Benutzern mit unterschiedlichen Rollen, zur gleichen Zeit über einen Webbrowser sicher auf dieselben Daten zuzugreifen und diese zu aktualisieren. _________________________________________________________________ PlateSpin Transformation Manager umfasst die folgenden Kernrollen: Administrator: Der für die Installation des Produkts zuständige Benutzer. Der Administrator kann der erste Projektmanager sein und/oder weitere Projektmanager erstellen. Projektmanager: Dieser erstellt in der Regel neue Projekte sowie Projektarchitekten und Migrationsspezialisten. Der Projektmanager verfügt über alle Berechtigungen für das Projekt. Projektarchitekt: Er verfügt über alle Berechtigungen für die Projekte, die ihm zugewiesen sind. Er kann jedoch keine neuen Projekte erstellen. Der Projektarchitekt kann außerdem Migrationsspezialisten erstellen. Migrationsspezialist: Diese Rolle verfügt über keine Planungsberechtigungen. Der Migrations­ spezialist kann ausschließlich Aufgaben im Rahmen geplanter Workload-Migrationen ausführen. Dashboard-Betrachter: Benutzer mit dieser Rolle können nur das Projekt-Dashboard anzeigen. 6 Zur Vermeidung unnötiger Verzögerungen empfiehlt es sich, den Zertifizierungsprozess möglichst frühzeitig während des Projekts zu starten. Planen von Projekten zur Migration großer Workloads Planen der Ressourcen für PlateSpin Server und Microsoft SQL-Server Es wird empfohlen, alle PlateSpin Server als virtuelle Maschinen auszuführen. Auf diese Weise können diesen Servern im Verlauf des Projekts problemlos je nach Bedarf mehr oder weniger Ressourcen zugewiesen werden. Beispiele für mögliche Ressourcenkonfigurationen finden Sie in der Dokumentation des jeweiligen Produkts. Normalerweise sollte jeweils ein virtueller Server vorgesehen oder bereitgestellt werden für: Den PlateSpin Transformation Manager-Server Ein PlateSpin Migrate-Server für je 200 gleichzeitig verwaltete Workload-Migrationen, von denen 40 zur gleichen Zeit aktiv reproduziert werden können Ein Microsoft SQL-Server (Standard oder Enterprise Edition), auf dem die Daten für die PlateSpin Migrate-Server gehostet werden. (Eine Liste der unterstützten Versionen finden Sie in der Dokumentation zu PlateSpin Migrate.) Hinweis: PlateSpin Transformation Manager wird als herunterladbare Appliance mit einer Größe von etwa 1 GB zur Verfügung gestellt. Planen der Zertifizierung des BBT-Treibers sowie von Wartungszeitfenstern für die Installation des BBT-Treibers Die Installation des BBT-Treibers (der eine kürzere Synchronisierungszeit ermöglicht) erfordert bei Quell-Workloads auf Basis von Microsoft Windows-Betriebssystemen einen Neustart. Um die damit verbundenen Auswirkungen auf ein Minimum zu reduzieren, steht ein eigenständiges Installationsprogramm für den Treiber zur Verfügung. Dieses Installationsprogramm kann zu einer beliebigen Zeit auf dem Quell-Workload ausgeführt werden und registriert einfach den Treiber zur Installation beim nächsten Neustart des QuellWorkloads. Anschließend kann der Quell-Workload zu einem beliebigen Zeitpunkt vor der Migration neu gestartet werden. Da Wartungszeitfenster rar gesät sind, stellt die Organisation dieser Neustarts einen wichtigen Schritt bei der Projektplanung dar. In einigen Umgebungen müssen neue Treiber zertifiziert werden, ehe sie verwendet werden können. Zur Vermeidung unnötiger Verzögerungen empfiehlt es sich, den Zertifizierungsprozess möglichst frühzeitig während des Projekts zu starten. www.microfocus.com 7 White Paper Erfolgreiche Planung und Ausführung von Projekten zur Migration großer Workloads Installieren, Konfigurieren und Initialisieren von PlateSpin Transformation Manager (Software) PlateSpin Transformation Manager wird als herunterladbare Linux-basierte Appliance bereit­ gestellt und erfordert vor dem Start lediglich die Installation eines zusätzlichen Datenträgers (normalerweise mit 40 GB). Beim erstmaligen Start muss eine Reihe einfacher Konfigurations­ einstellungen vorgenommen werden. Nach dieser anfänglichen Konfiguration kann sich der Projektmanager über einen Webbrowser anmelden, die Quell-Workloads, die Zielumgebung und die PlateSpin Migrate-Server ermitteln und anschließend den Projektplan erstellen. Installieren der PlateSpin Migrate-Server (Software) Es wird empfohlen, PlateSpin Migrate auf einem dedizierten Microsoft Windows 2012 R2Betriebssystem zu installieren. Auf diesem System sollten keine anderen Anwendungen installiert sein. Eine vollständige Beschreibung des Installationsprozesses finden Sie in der Produktdokumentation. Ein PlateSpin Migrate-Server kann etwa 200 ermittelte QuellWorkloads gleichzeitig verwalten, von denen 40 zur gleichen Zeit reproduziert werden können. Wenn aufgrund des Projektumfangs mehrere PlateSpin Migrate-Server installiert werden müssen, empfiehlt sich die Installation einer zentralen Microsoft SQL Server-Instanz zur Verwaltung aller migrationsrelevanten Daten (erfordert Microsoft SQL Server Standard oder Enterprise Edition). Zusammenstellen effektiver Ausführungsteams Es wird empfohlen, dass alle Teammitglieder, die mit PlateSpin Migrate arbeiten, an der Schulung zur Administration von PlateSpin Migrate teilnehmen. Mindestens ein Teammitglied sollte ein zertifizierter PlateSpin Migrationsspezialist sein. Weitere Informationen über die Zertifizierung finden Sie am Ende dieses White Papers. Neben den PlateSpin Migrate-Administrationsfertigkeiten empfiehlt es sich, ein Team zusammenzustellen, in dem Mitglieder mit den folgenden Fertigkeiten vertreten sind: Für die Migration von Linux-basierten Workloads: grundlegende Fertigkeiten für die Administration von Linux-Systemen. Bestimmte Versionen von Linux erfordern die Kompilierung eines benutzerdefinierten BBT-Treibers. Dieser Prozess ist nicht schwierig und gut dokumentiert. Es sind jedoch Kenntnisse über die Administration per Linux-Kommandozeilenschnittstelle erforderlich. Eine Liste der Linux-Versionen, für die bereits ein vorkompilierter BBT-Treiber existiert, finden Sie in der Produktdokumentation. Für die Migration von Windows-basierten Workloads: grundlegende Fertigkeiten für die Administration von Windows-Systemen. Es wird ausdrücklich empfohlen, sich umfassend mit den Zielplattformen auseinanderzusetzen, auf die die Workloads migriert werden. Jede Zielplattform ist mit ganz individuellen Heraus­ forderungen verbunden, sodass insbesondere bei der Problembehandlung mindestens fortgeschrittene Kenntnisse über die jeweilige Zielplattform benötigt werden. Bei Migrationen auf VMware-Zielplattformen wird ausdrücklich empfohlen, dass mindestens ein Teammitglied für VMware-Umgebungen zertifiziert ist. Auch bei Migrationen auf andere Zielplattformen ist es ratsam, sich über eventuelle Zertifizierungen für die betreffende Plattform zu informieren und ­mindestens ein Teammitglied die Zertifizierung erwerben zu lassen. 8 Es wird empfohlen, PlateSpin Migrate auf einem Microsoft Windows 2012 R2-Betriebssystem zu installieren. Eine vollständige Beschreibung des Installationsprozesses finden Sie in der Produktdokumentation. Es hat sich außerdem bewährt und wird empfohlen, die Integrität des Dateisystems für jeden Quell-Workload zu überprüfen, ehe die Reproduktion gestartet wird. Netzwerkprobleme sind die Hauptursache für Herausforderungen im Rahmen von Migrations­­ projekten. Diese können sich auf Bandbreitenbeschränkungen, Firewalls oder Netzwerk­ architekturen beziehen, welche die Verwendung bestimmter Kommunikationspfade verhindern. Daher ist die genaue Kenntnis der im Rahmen des Projekts genutzten Netzwerke von entscheidender Bedeutung für den Projekterfolg. Darüber hinaus empfiehlt es sich, mindestens ein Teammitglied mit einer Zertifizierung für TCP/IP-Standardnetzwerke einzusetzen, insbesondere im Hinblick auf Bandbreitenberechnungen. Erfassen von Daten zu Quell-Workloads PlateSpin Transformation Manager verfügt über eine flexible Funktion für den Import von Daten, die auf Microsoft Excel-Tabellen basiert. Auf der Hauptregisterkarte mit der WorkloadÜbersicht auf der Benutzeroberfläche kann ein Widget geladen werden, mit dem Daten zu den Quell-Workloads für ein Projekt importiert werden können. In dem Widget wird ein DownloadLink bereitgestellt, über den ein Mustertabellenblatt schnell und einfach auf den Desktop heruntergeladen werden kann. Im nächsten Schritt müssen in dieses Tabellenblatt Daten zu den Quell-Workloads eingetragen werden. Alternativ können Daten zu den Quell-Workloads auch über die REST-API von PlateSpin Transformation Manager hinzugefügt werden. Im Laufe der Planungsphase können weitere Daten zu den Quell-Workloads verfügbar werden. PlateSpin Transformation Manager ermöglicht den Folgeimport von Daten zu Systemen, die zuvor bereits importiert wurden. Der vollqualifizierte Domänenname (FQDN) dient dabei als Schlüssel für die Identifizierung und Aktualisierung bzw. Ergänzung der bereits vorhandenen Daten. Die Daten der Quell-Workloads werden in Echtzeit ermittelt und können zu jedem beliebigen Zeitpunkt mit den importierten Daten vervollständigt werden. Diese optionale Ermittlung wird von PlateSpin Transformation Manager unter Verwendung von mindestens einem PlateSpin Migrate-Server durchgeführt. Dank dieser zusätzlichen Echtzeit-Ermittlung werden nur wenige Daten für den anfänglichen Import mithilfe von Tabellenblättern oder über die API benötigt. Es ist jedoch zu beachten, dass PlateSpin Migrate hinsichtlich des benötigten freien Speicherplatzes mit zwei Anforderungen an die Quell-Workloads verbunden ist: Für die Installation des PlateSpin Migrate-Controllers werden 100 MB an freiem Speicherplatz benötigt. Der Controller wird in der Regel während der Vorbereitungsphase der Migration ­automatisch installiert. Bei der Migration von Workloads unter Windows müssen auf jedem Volume 10 % Speicherplatz frei sein. Dies liegt daran, dass PlateSpin Migrate während der Reproduktion VSS-Snapshots erstellt, um eine konsistente Datenreproduktion zu gewährleisten. Diese Snapshots erfordern 10 % freien Speicherplatz. Bei Linux-basierten Workloads gelten dieselben Anforderungen, jedoch nur auf Ebene der Volumegruppe und nur bei Verwendung von LVM. Es hat sich außerdem bewährt und wird empfohlen, die Integrität des Dateisystems für jeden Quell-Workload zu überprüfen, ehe die Reproduktion gestartet wird. Der Ziel-Workload wird möglicherweise nicht ordnungsgemäß gestartet, wenn Daten beschädigt sind und diese www.microfocus.com 9 White Paper Erfolgreiche Planung und Ausführung von Projekten zur Migration großer Workloads vom Quell- auf den Ziel-Workload kopiert werden. Das gilt insbesondere für blockbasierte Reproduktionen. Bei Windows-Workloads kann das Dienstprogramm „Check Disk“ (chkdsk) zur Überprüfung der Integrität verwendet werden. Planen des Projekts in PlateSpin Transformation Manager Ein einziges Transformationsprojekt in einem Rechenzentrum kann unter Umständen mehrere zehntausend Workloads umfassen. Doch bereits wenige tausend Workloads können eine schier unlösbare Aufgabe darstellen, wenn es nicht gelingt, Workloads zu kategorisieren und in mehrere verwaltungsfreundliche Blöcke zu gruppieren. PlateSpin Transformation Manager ermöglicht die Gruppierung auf drei Ebenen: Batch: Ein Batch umfasst mindestens einen Workload. Diese Workloads gehören in der Regel zu denselben Anwendungen und die Umstellung nach der Migration muss bei allen zur gleichen Zeit erfolgen. Wave: Ein Wave besteht aus einzelnen oder mehreren Batches. Projekt: Ein Projekt enthält mindestens einen Wave. Während der Projektplanung können Workloads, wie in der folgenden Abbildung gezeigt, problemlos mithilfe erweiterten Such- und Massenbearbeitungswerkzeugen in Waves und Batches gruppiert werden. _________________________________________________________________ Abb. 3 Gruppen von Workloads können leicht über die erweiterte Suchmaske ermittelt werden. 10 Gruppierungsebenen von PlateSpin Transformation Manager: Batch Wave Projekt Basierend auf Erfahrungswerten wird empfohlen, mit PlateSpin nicht mehr als 10 Reproduktionen gleichzeitig in einen VMware-Cluster durchzuführen. Erstellen einer für den Projektumfang geeigneten Migrationsinfrastruktur Eine der Rahmenbedingungen für den Erfolg eines Projekts ist die Architektur der PlateSpin Migrationsinfrastruktur. Die Art der benötigten Infrastruktur ist durch verschiedene Skalier­ barkeitsgrenzen vorgegeben. 1. Skalierbarkeitsgrenzen von PlateSpin Migrate Ein PlateSpin Migrate-Server kann bis zu 40 Reproduktionen gleichzeitig und etwa 200 ermittelte und/oder konfigurierte Workloads gleichzeitig verarbeiten. Bei beiden Werten handelt es sich um „bewegliche Fenster“. Das heißt, dass nach dem Ende einer Reproduktion die jeweils nächste gestartet werden kann, solange die Obergrenze von 40 gleichzeitigen Reproduktionen nicht überschritten wird. Ebenso können die Daten eines Workloads nach der erfolgreichen Migration von dem PlateSpin Migrate-Server gelöscht werden, um Ressourcen für einen neuen Workload freizugeben. Bei Verwendung von PlateSpin Transformation Manager wird für alle Workload-Migrationsvorgänge automatisch ein Lastenausgleich über alle verfügbaren PlateSpin Migrate-Server hinweg durchgeführt. Darüber hinaus können pro PlateSpin Migrate-Server bis zu 30 unterschiedliche Zielplattformen ermittelt und verwaltet werden. Bei Ermittlung eines VMware-Clusters werden die einzelnen ESX(i)-Hosts als Zielplattformen behandelt. Dementsprechend kann ein PlateSpin MigrateServer zum Beispiel 2 VMware-Cluster mit je 15 Hosts oder 3 Cluster mit je 10 Hosts verarbeiten. 2. Skalierbarkeitsgrenzen der Zielplattform Bei der Reproduktion von Workloads auf einer Zielplattform wird die Netzwerk- und Storageinfrastruktur der Zielplattform stärker belastet. Wenn die Plattform über gemeinsam genutzte Ressourcen verfügt, wie es etwa bei Hypervisoren der Fall ist, kann diese zusätzliche Belastung einen negativen Einfluss auf die anderen Workloads haben, die während des Migrationsvorgangs ebenfalls auf der Zielplattform ausgeführt werden. Wenn dies vermieden werden soll, ist eine zweistufige Vorgehensweise empfehlenswert, bei der die Workloads zunächst auf eine „Zwischenplattform“, auf der keine Produktionsworkloads ausgeführt werden, und erst dann auf ihre letztendliche Zielplattform migriert werden. Zusätzlich sollte die maximal mögliche Geschwindigkeit beachtet werden, mit der die Zielplattform die eingehenden Reproduktionen verarbeiten kann. Basierend auf Erfahrungs­ werten wird empfohlen, mit PlateSpin nicht mehr als 10 Reproduktionen gleichzeitig in einen VMware-Cluster durchzuführen. www.microfocus.com 11 White Paper Erfolgreiche Planung und Ausführung von Projekten zur Migration großer Workloads 3. Skalierbarkeitsgrenzen der Quellplattform Die Reproduktion von Workloads belastet auch die Netzwerkinfrastruktur der Quellplattformen zusätzlich. Die Belastung von CPU, RAM und Storage ist hierbei weniger maßgeblich, da Daten nur gelesen und nicht geschrieben werden. Ein wichtiger Faktor, den es zu berücksichtigen gilt, ist die maximale Bandbreite der Netzwerkkarte (NIC – virtuell oder physisch), über die die Quellplattform mit der Netzwerkinfrastruktur verbunden ist. Ganz unabhängig von der Bandbreite der Netzwerkinfrastruktur kann bei einer Migration nicht mehr Bandbreite genutzt werden als die Netzwerkkarte der Quellplattform bietet. Bei virtualisierten Umgebungen ist dieser Faktor umso wichtiger, da hier eine physische Netzwerkkarte möglicherweise von mehreren Workloads gemeinsam genutzt wird. Wenn eine solche Netzwerkkarte nur 1 Gbit/s verarbeiten kann und mehrere Workloads gleichzeitig reproduziert werden, dann teilt sich diese 1 Gbit/s-Verbindung auf alle Reproduktionen auf. Dies führt zu langsamen Migrationsvorgängen, selbst wenn die Netzwerkinfrastruktur einen Durchsatz von 10 Gbit/s oder mehr bewältigen kann. 4. Menschliches Versagen PlateSpin Migrate ist ein Mehrbenutzer-Migrationswerkzeug, mit dem verschiedene Benutzer gleichzeitig an der Migration von Workloads arbeiten können. Um allerdings menschliches Versagen – meist durch mangelnde Übersicht, wer an welchem Workload arbeitet, oder durch einen Administrator, der versehentlich an dem Workload eines anderen Administrators arbeitet – zu vermeiden, empfiehlt es sich, dass nicht mehr als drei Administratoren gemeinsam denselben PlateSpin Migrate-Server nutzen. Mehrere PlateSpin Migrate-Server können von ein und derselben Person betreut werden, aber es sollten niemals mehr als drei Personen ein und denselben PlateSpin Migrate-Server betreuen. Bei einem Migrationsvorhaben sollte jedes Team eine Reihe von Anwendungen bearbeiten und dabei ein und denselben PlateSpin Migrate-Server verwenden, um alle Workloads zu migrieren, die zu diesen Anwendungen gehören. Wenn PlateSpin Transformation Manager verwendet wird, ist diese Art von menschlichem Versagen beinahe ausgeschlossen. _________________________________________________________________ 12 Es wird empfohlen, dass nicht mehr als drei Personen denselben PlateSpin Migrate-Server gemeinsam nutzen. Zudem wird dringend empfohlen, die gesamte verfügbare Bandbreite für alle Netzwerkpfade zwischen Quellund Zielplattformen zu messen, bevor die tatsächlichen Migrationsvorgänge gestartet werden. Abb. 4 Visualisierung einiger der wichtigsten Einschränkungen (am Beispiel einer VMware-Zielinfrastruktur). _________________________________________________________________ 5. Netzwerkinfrastruktur Messen der Bandbreite Selbst wenn theoretisch ein schnelles Netzwerk (z. B. mit 10 Gbit/s) zur Verfügung steht, muss durch Berechnungen sichergestellt werden, dass die verfügbare Bandbreite für die Menge an gleichzeitig übertragenen Daten ausreicht. Die tatsächlich verfügbare Bandbreite zwischen Quell-Workload und Zielplattform sollte so früh wie möglich im Projekt bestimmt werden, da sie maßgeblich für die tatsächliche Migrationsgeschwindigkeit verantwortlich ist. Eine gute Möglichkeit, die tatsächlich verfügbare Bandbreite zu messen, ist das Tool iPerf. iPerf basiert auf dem Client-Server-Prinzip, wobei der Server auf der Zielplattform ausgeführt werden sollte. Bei Zielplattformen auf Basis von VMware kann dies mithilfe einer kleinen dedizierten virtuellen Maschine erfolgen. Der Client kann dann im System des Quell-Workloads heruntergeladen und ausgeführt werden, um die Bandbreite zwischen Quelle und Ziel zu messen. Zudem wird dringend empfohlen, die gesamte verfügbare Bandbreite für alle Netzwerkpfade zwischen Quellund Zielplattformen zu messen, bevor die tatsächlichen Migrationsvorgänge gestartet werden. www.microfocus.com 13 White Paper Erfolgreiche Planung und Ausführung von Projekten zur Migration großer Workloads Optimierung des Netzwerks Das TCP/IP-Empfangsfenster zwischen Quelle und Ziel kann je nach Netzwerklatenz optimiert werden, um bei Reproduktionsvorgängen einen höheren Durchsatz zu erzielen. Detaillierte Angaben zu den einzelnen durchzuführenden Schritten finden Sie in der PlateSpin MigrateDokumentation. Darüber hinaus besitzt jede Netzwerkinfrastruktur eine charakteristische maximale Paketgröße. Diese wird als Maximum Transmission Unit (MTU) bezeichnet. PlateSpin Migrate ermöglicht es Administratoren, den MTU-Wert für jede Reproduktion einzeln festzulegen, um eine Fragmentierung der Pakete und den damit verbundenen Durchsatzverlust zu vermeiden. Detaillierte Angaben zu den einzelnen durchzuführenden Schritten finden Sie in der PlateSpin Migrate-Dokumentation. Komprimierung Bei sehr langsamen Verbindungen wie z. B. über WAN können Daten mit PlateSpin Migrate komprimiert werden, bevor sie über das Netzwerk gesendet werden. Je nach Art der Daten kann eine Komprimierung von bis zu 70 % erzielt werden, sodass die Reproduktionszeiten deutlich verkürzt werden. Da allerdings der Quell-Workload mithilfe der zugehörigen CPU komprimiert wird, muss ein zusätzlicher CPU-Overhead von etwa 5 % berücksichtigt werden. Erforderliche Kommunikationspfade Für eine vollständige Übersicht über alle Kommunikationspfade einschließlich der möglich­ erweise in den Firewalls zu öffnenden Ports kann jederzeit die technische Dokumentation zu PlateSpin Migrate zu Rate gezogen werden. Die wichtigsten Anforderungen sind: Konnektivität zwischen dem PlateSpin Migrate-Server und dem Quell-Workload Konnektivität zwischen dem PlateSpin Migrate-Server und dem ISO-Helper-Abbild mit LinuxRAM-Datenträger (LRD) während der Reproduktion. Im Zuge einer Reproduktion wird der ­Ziel-Workload immer mithilfe dieses Helper-Abbilds gestartet. Die Konnektivität kann je nach Wunsch über ein dediziertes Netzwerk sichergestellt werden. Diese Option kann im Rahmen der Konfiguration des Migrationsvorgangs ausgewählt werden. Konnektivität zwischen Quell-Workload und dem genannten LRD-Helper-Abbild während der Reproduktion. Dieser Netzwerkpfad wird für die Datenübertragung während der Reproduktion genutzt, deshalb muss der erforderlichen Bandbreite hier besondere Beachtung geschenkt werden. Konnektivität zwischen dem PlateSpin Migrate-Server und der Zielplattform (z. B. dem VMware ESX-Server), auf die der Workload migriert wird. Konnektivität zwischen dem PlateSpin Migrate-Server und dem Ziel-Workload in seiner ­endgültigen Form, also nachdem ihm die Produktions-IP-Adresse zugewiesen wurde. Diese Anforderung gilt auch für das Testen des Workloads, nachdem ihm die Test-IP-Adresse zugewiesen wurde. Der Grund für diese Anforderungen ist der Prozess der endgültigen Konfiguration des Ziel-Workloads. Diese erfolgt über einen Konfigurationsdienst, der vor dem ersten Startvorgang in den Ziel-Workload eingefügt wird. Während des Startvorgangs wird die endgültige Anpassung des Workloads durch diesen Konfigurationsdienst vorgenommen, der sich anschließend selbst entfernt. Um jedoch Informationen über die Konfiguration zu erhalten, benötigt der Konfigurationsdienst einen Netzwerkzugang zum PlateSpin Migrate-Server, sodass die entsprechenden Daten heruntergeladen werden können. 14 PlateSpin Migrate ermöglicht es Administratoren, den MTU-Wert für jede Reproduktion einzeln festzulegen, um eine Fragmentierung der Pakete und den damit verbundenen Durchsatzverlust zu vermeiden. Bei der Reproduktion von Workloads mit PlateSpin Migrate wird der Ziel-Workload immer von einem Linux-RAMDatenträger (LRD) über ein ISO-HelperAbbild gestartet. IP-Adressenmanagement Wenn ein Workload mit PlateSpin Migrate reproduziert wird (z. B. im Rahmen einer vollständigen oder inkrementellen Reproduktion), wird der Ziel-Workload immer von einem Linux-RAM-Datenträger (LRD) über ein ISO-Helper-Abbild gestartet. Dieses Helper-Abbild benötigt eine IP-Adresse, damit eine Kommunikation über das Netzwerk mit dem QuellWorkload und dem PlateSpin Migrate-Server möglich ist. Diese IP-Adresse kann im Zuge der Konfiguration des Migrationsvorgangs für den Workload in PlateSpin Migrate festgelegt werden. Das bedeutet, dass an einem vollständigen Migrationsvorgang bis zu vier verschiedene IPAdressen beteiligt sind: IP-Adresse des Quell-Workloads (normalerweise statisch, zumindest bei einer Live-Migration) IP-Adresse des PlateSpin Migrate-Servers (statisch) IP-Adresse des Ziel-Workloads in seiner endgültigen Konfiguration. Diese IP-Adresse ist ­möglicherweise identisch mit der des Quell-Workloads (sofern der Quell-Workload nach erfolgter Umstellung heruntergefahren wird), es kann aber auch eine andere vergeben werden. IP-Adresse des ISO-Helper-Abbilds mit dem LRD während der Reproduktion. Wenn die IPAdresse des Ziel-Workloads in seiner endgültigen Konfiguration eine andere ist als die des QuellWorkloads, kann normalerweise eben diese IP-Adresse des Ziel-Workloads verwendet werden, da es nicht zu einem Konflikt mit der IP-Adresse des Quell-Workloads kommen kann. Wenn allerdings die IP-Adresse des Quell-Workloads später auf dem Ziel-Workload in der endgültigen Konfiguration übernommen wird, muss eine dedizierte IP-Adresse für die Reproduktion eingeplant werden. Die IP-Adresse des Ziel-Workloads kann in diesem Fall nicht verwendet werden, da sie im Konflikt mit der (identischen) IP-Adresse des Quell-Workloads stünde. Es ist zu beachten, dass bei Verwendung von DHCP in der Umgebung des Ziel-Workloads die IP-Adresszuweisung größtenteils automatisch vom DHCP-Dienst verwaltet wird. Ausführungsdynamik von Projekten zur Migration großer Workloads Nachverfolgen des Projektfortschritts mit PlateSpin Transformation Manager Im Zuge der Migration von Workloads werden die Informationen in der Datenbank von PlateSpin Transformation Manager hinsichtlich des Projektfortschritts fortwährend auf dem neuesten Stand gehalten. Wenn Fristen bei der Transformation von Workloads nicht eingehalten werden, wird eine Warnung angezeigt, um zu signalisieren, dass ein Eingreifen durch den Projektarchitekten oder Projektmanager erforderlich ist. Diese können dann entscheiden, ob der Workload einem zukünftigen Batch hinzugefügt, ob ein neuer Batch dafür erstellt oder ob andere Maßnahmen ergriffen werden sollen. www.microfocus.com 15 White Paper Erfolgreiche Planung und Ausführung von Projekten zur Migration großer Workloads PlateSpin Transformation Manager enthält die folgenden Workload-Migrationsstatus: Importiert: Der Projektmanager oder Projektarchitekt hat den Workload (über ein Tabellendokument oder die API) in ein Projekt importiert, aber es wurden noch keine Änderungen daran vorgenommen. Zusätzliche Angaben erforderlich: Der Projektmanager oder Projektarchitekt hat bereits mit der Planung begonnen, für eine erfolgreiche Durchführung der Migration selbst sind jedoch noch weitere Planungstätigkeiten erforderlich. Bereit zum Absenden: Es wurden alle erforderlichen Informationen für eine erfolgreiche Durchführung der Migration angegeben und der Workload kann für die Migration zu einem ­späteren Zeitpunkt (je nach Projektplanung) eingereicht werden. Abgesendet: Der Workload wurde formell durch den Projektmanager oder Projektarchitekten zur Migration eingereicht. In Bearbeitung: Der Workload wird gerade migriert. Beendet. Die Migration des Workloads ist beendet. Die wichtigsten Projektinformationen können jederzeit mit allen Rollen mit entsprechenden Rechten im Projekt-Dashboard eingesehen werden. Optional kann dieses Dashboard mithilfe einer Rolle für Dashboard-Betrachter, die ausschließlich über Anzeigerechte verfügt, für beliebige Dritte freigegeben werden. _________________________________________________________________ Abb. 5 Auf dem Projekt-Dashboard werden die wichtigsten Projektinformationen auf einen Blick angezeigt. 16 WorkloadTransformations­ zustände von PlateSpin Transformation Manager: Importiert Zusätzliche Angaben erforderlich Bereit zum Absenden Abgesendet In Bearbeitung Abgeschlossen Mit PlateSpin Migrate kann das Testen des Ziel-Workloads erfolgen, während der QuellWorkload noch online, also in Betrieb ist. Umstellen Ihrer Workloads: frühzeitig und häufig testen Bevor Sie die Umstellung auf Ihren neuen Server vornehmen, ist fast immer eine gewisse Menge an Tests erforderlich. Mit PlateSpin Migrate kann das Testen des Ziel-Workloads in einer Sandbox-Umgebung erfolgen, während der Quell-Workload noch online, also in Betrieb ist. Die Dauer eines Tests und die Anzahl der vor der Umstellung durchgeführten Tests ist unbegrenzt. Sobald ein Test abgeschlossen ist, wird automatisch eine inkrementelle Reproduktion durchgeführt, um Quell- und Ziel-Workload miteinander zu synchronisieren, damit der Ziel-Workload die neuesten Updates für den nächsten Test enthält. Dieser Prozess des Testens und Synchronisierens kann beliebig oft wiederholt werden. Sobald der Ziel-Workload von den Test-Teams genehmigt ist, wird eine abschließende Synchronisierung zwischen Quellund Ziel-Workload durchgeführt. Danach erfolgt die Umstellung. Damit sichergestellt ist, dass die Daten von Quelle und Ziel zu 100 Prozent konsistent sind, wird als bewährtes Verfahren empfohlen, die in Betrieb befindlichen Dienste des QuellWorkloads vor der letzten Synchronisierung herunterzufahren. Indem die Dienste herunter­ gefahren werden, wird sichergestellt, dass keine weiteren Veränderungen mehr an den Daten stattfinden, während die letzten Änderungsdaten vom Quell- auf den Ziel-Workload übertragen werden. PlateSpin Migrate enthält ein Widget, das die einfache Auswahl der Dienste ermöglicht, die vor der letzten Synchronisierung heruntergefahren werden müssen. Da die Geschäftsdienste während der Umstellung offline sind, ist es äußerst wichtig, die Umstellung so schnell wie möglich durchzuführen. Durch mehrere Synchronisierungs­ vorgänge (in der Regel wie zuvor beschrieben im Wechsel mit Tests) ist sichergestellt, dass die Ausfallzeit während der letzten Synchronisierung und der Umstellung insgesamt auf ein absolutes Minimum (normalerweise wenige Minuten) beschränkt bleibt. Ebenso wichtig ist, dass die Ausfallzeit der Dienste vorhersehbar ist: die letzte Synchronisierung sollte schneller vonstattengehen als jede der vorherigen automatischen Synchronisierungen. _________________________________________________________________ www.microfocus.com 17 www.microfocus.com Abb. 6 Micro Focus Das Planen der Reproduktion eines Workloads mit der PlateSpin Migrate-Weboberfläche ist einfach und erfolgt mithilfe eines Assistenten. ___________________________________________________________ Deutschland Fraunhoferstraße 7 D-85737 Ismaning +49 89 42094 0 Micro Focus Erwerb einer Zertifizierung als PlateSpin Migrationsspezialist Schweiz Merkurstrasse 14 8953 Dietikon Switzerland +41 43 5087660 Micro Focus Migrationsspezialisten, die Experten für PlateSpin Migrate werden möchten, können sich für den Schulungskurs zur Administration von PlateSpin Migrate anmelden. In dem Kurs werden alle Aspekte der Arbeit mit PlateSpin Migrate behandelt, unter anderem die Produktinstallation, die Dynamik einer Massenmigration, Lizenzierungsfragen, die Verwendung der Kommandozeilenschnittstelle, die Verwaltung von Treibern und die Fehlersuche. Nach Abschluss des Kurses kann der Teilnehmer sich für die Prüfung als zertifizierter PlateSpin Migrationsspezialist anmelden. Die Prüfung besteht aus einer Reihe von Multiple-Choice-Fragen, mit denen die Kenntnisse des Teilnehmers zu allen relevanten Themen überprüft werden. Weitere Informationen über Schulungsoptionen und Zertifizierungen finden Sie auf der PlateSpin Migrate-Webseite auf microfocus.com (www.microfocus.com/ products/migrate). 162-DE0113-002 | Q | 05/17 | © 2017 Micro Focus. Alle Rechte vorbehalten. Micro Focus, das Micro Focus Logo und PlateSpin sowie andere Namen sind Marken oder eingetragene Marken von Micro Focus oder Tochterunternehmen bzw. Schwestergesellschaften in Großbritannien, den USA und anderen Ländern. Alle weiteren Marken sind Eigentum ihrer jeweiligen Inhaber. Firmenhauptsitz Vereinigtes Königreich +44 (0) 1635 565200 www.microfocus.com
