Speichermigration leicht gemacht

IBM Global Technology Services
Juni 2007
Speichermigration leicht gemacht
Die technologische Modernisierung meistern
Speichermigration leicht gemacht.
Seite 2
Kurzübersicht
Inhalt
2
Kurzübersicht
4
Einführung
6
Datenmigrationssoftware
10 Beispiele für technologische
Modernisierung
28 Zusammenfassung
Die Auswirkungen von Datenmigrationen auf die Geschäftsabläufe zu
minimieren, bildet einen wesentlichen Teil der Aufgaben eines RZ-Managers.
Studien haben gezeigt, dass technologische Modernisierung — d. h. Ersatz
eines älteren Servers oder Speicher-Arrays durch eine neue Komponente —
das wichtigste Argument für die Datenmigration ist. Nach dem Austausch von
Speicherhardware und Speicherservern oder bei Ablauf der Leasingdauer von
Massenspeichern müssen Speichermanager regelmäßig Daten verlagern. Dies
kann jedoch wegen der Anforderungen an die Anwendungsverfügbarkeit,
der Inkompatibilitäten von Quell- und Zielsystemen oder der zeitlichen
und finanziellen Rahmenbedingungen problematisch sein. Projekte zur
technologischen Modernisierung werden in der Regel außerhalb der
Geschäftszeiten realisiert. In dem rund um die Uhr aktiven Umfeld von heute
müssen Anwendungen aber auch außerhalb der Geschäftszeiten online sein.
Neue Software ermöglicht eine unterbrechungsfreie Migration. Das bedeutet,
dass Anwendungen auch während der Migration online bleiben, und zwar ohne
wesentliche Leistungseinbußen. Zur Unterstützung von Planung, Durchführung,
Prüfung und Bewertung von Datenmigrationen gibt es zuverlässige Methoden,
die eine kundenspezifische Anpassung ermöglichen, den Prozess beschleunigen
und die Datenintegrität gewährleisten — und damit die gesamte Modernisierung
der Technologie vereinfachen.
Speichermigration leicht gemacht.
Seite 3
Highlights
Technologische Modernisierung
Die folgende Tabelle zeigt anhand von fünf Schlüsselfaktoren, wie Datenmigrationssoftware die Modernisierung der Technologie vereinfachen
kann und wie Softek Transparent Data Migration Facility (TDMF) diesen
Anforderungen gerecht wird.
Schlüsselfaktoren
Beschreibung
Realisierung mit Softek TDMF
Leistung
Leistungsmessungen
müssen berücksichtigen,
wie schnell Daten
zwischen Quelle und
Ziel kopiert werden,
und auf Netzbandbreite
und Systembelastung
abgestimmt sein.
TDMF-Software besitzt eine
dynamische Regelung/Dosierung, die den Prozess der
Datenübertragung je nach
Systemanforderungen beschleunigt oder bremst und so die
Abstimmung der Migration mit
sonstigen Prozessen vereinfacht.
Rollback-Funktion
Bei Bedarf kann die
Migration beendet und neu
gestartet werden, oder die
Anwendungsverarbeitung
kann mit den Quelldaten
oder dem Quellgerät
fortgesetzt werden.
TDMF-Software ermöglicht ein
einfaches Rollback, was mit
anderen Technologien wie etwa
Volume Managern durchaus
problematisch sein kann.
Steigerung der
Volume-Größe
Laut einer neueren
TDMF-Software ermöglicht die
Umfrage wurden bei
Vergrößerung der Volumes.
40 Prozent der Migrationen
auch die Volumes
zwischen Quelle und Ziel
vergrößert.
Heterogene Hardware
in Quelle und Ziel
Die meisten Host-basierten TDMF-Software ist
Produkte unterstützen
hardwareunabhängig.
unterschiedliche Speichergeräte. Die meisten arraybasierten Produkte dagegen fordern, dass Quelle
und Ziel vom selben
Hersteller stammen.
Anwendungsausfallzeit
Die Verfügbarkeit der
geschäftskritischen
Anwendungen sollte
möglichst erhalten werden.
ist das wichtigste Argument für
die Datenmigration.
TDMF-Software ermöglicht
unterbrechungsfreie Datenmigration, sodass Anwendungen
online bleiben und während des
gesamten Migrationsprozesses
für die Datenverarbeitung zur
Verfügung stehen.
Speichermigration leicht gemacht.
Seite 4
Einführung
Highlights
Was treibt die Datenmigration an? In einer neueren Umfrage von Softek wurde
die Modernisierung der Technologie als Hauptgrund für die Verlagerung von
Daten genannt. Technologische Modernisierung ist als Ersatz eines Arrays
durch ein neues Array definiert und findet am häufigsten in den folgenden
Situationen statt:
•
•
•
•
IT-Abteilungen rechtfertigen neue
Hardware damit, dass sie mit dem
Wachstum Schritt halten kann,
schneller arbeitet und damit bessere
Leistung bietet und das Risiko für
Hardwarefehlfunktionen minimiert.
Wenn die Leasingdauer von Speichersystemen endet.
Daten werden von einem alten zu einem neuen Speicher verlagert.
Es wird ein Upgrade eines Speichersystems durchgeführt.
Das Unternehmen will eine bestimmte Technologie standardisieren.
Die meisten Rechenzentren leasen ihre Speicherhardware für drei Jahre. Sobald
der Vertrag endet, muss die Hardware ausgetauscht und die darauf gespeicherten
Daten müssen auf neue Speicherhardware verlagert werden. Die Datenmigration
muss abgeschlossen sein, bevor die Zugangsberechtigung abläuft, um weitere
Leasingkosten zu vermeiden. Wurde die Speicherhardware nicht geleast, sondern
gekauft, kann die Wartung älterer, nicht mehr unterstützter Arrays äußerst kostspielig werden. Aber auch bei Kauf und Implementierung neuer Hardware ist die
Migration der Daten aus den älteren Arrays erforderlich.
IT-Abteilungen begründen den Kauf oder das Leasing neuer Hardware damit,
dass sie billiger zu warten ist, höhere Leistung bietet und zusätzliche Features
unterstützt. Neue Arrays haben mehr Kapazität, um mit dem Wachstum der
Anwendungen Schritt zu halten, schnellere Prozessoren für höhere Leistung
oder neue Features wie Snapshot-Kopien. Schließlich werden neue Arrays mit
der Minimierung des Risikos für Hardwarefehlfunktionen gerechtfertigt, da
ältere Arrays als weniger zuverlässig angesehen werden.
Speichermigration leicht gemacht.
Seite 5
Highlights
Für die meisten Branchen bewegen
sich die Schätzungen des Anstiegs
der Datenbestände in der Regel
zwischen 25 und 50 Prozent pro
Jahr.
In vielen Fällen bedeutet technologische Modernisierung nicht nur einen
Austausch der Speicher-Arrays sondern auch einen Upgrade der zugehörigen
Server, um Service-Level-Agreements (SLA) besser erfüllen zu können oder
weil die Server, genau wie die Speichersysteme, das Ende der Leasingdauer
erreicht haben. Außerdem wird die Speicher- und Serverkapazität mindestens
einmal jährlich erhöht, um mit dem Anstieg von Daten und Anwendungen
Schritt zu halten. Die Schätzungen des Anstiegs der Datenbestände variieren,
bewegen sich aber in der Regel für die meisten Branchen zwischen 25 und
50 Prozent pro Jahr.
2008
2007
2006
2005
2004
2003
2002
Insgesamt in
Betrieb (TB)
Neu (TB)
659
507
390
300
230
177
136
152
117
90
70
53
41
31
Ersetzt (TB)
115
77
60
45
24
19
14
Gekauft (TB)
267
194
150
115
77
60
45
Abbildung 1
Beispiel für jährliche Migrationsanforderungen
So schafft ein typisches Unternehmen in jedem Jahr Speichertechnologie an,
um Arrays zu ersetzen, für die Leasing- oder Wartungsverträge auslaufen, sowie
zusätzliche Kapazität, um mit dem erwarteten Wachstum Schritt zu halten.
Infolgedessen muss die IT-Abteilung ziemlich regelmäßig Daten zwischen
Servern und Speicherhardware verlagern. Das Mantra für Speicher lautet:
Du hast Daten, also musst du sie auch verlagern.
Speichermigration leicht gemacht.
Seite 6
Highlights
Es ist eine ständige Herausforderung zu entscheiden, wie mit dem
Die IT-Abteilungen stehen im Zusammenhang mit der technologischen
Modernisierung vielen Herausforderungen gegenüber. Insbesondere müssen
sie entscheiden, wie sie mit dem Anwachsen der Datenbestände umgehen, und
festlegen, wie, wann und wohin die Daten verlagert werden sollen. Zu den
wichtigsten Problemen in diesem Zusammenhang gehören:
Anwachsen der Datenbestände
umgegangen werden soll und wie,
wann und wohin die Daten verlagert
werden sollen.
• Überlappende Leasing- oder doppelte Wartungskosten, wenn alte und neue
Hardware gleichzeitig im Rechenzentrum in Betrieb ist.
• Migration von Daten zwischen Arrays verschiedener Hersteller, da zwischen
Ihnen eine beträchtliche Inkompatibilität bestehen kann.
• Risiko von Datenverfälschung oder Datenverlust bei nicht ordnungsgemäßer
Durchführung der Migration.
• Lange Ausfallzeiten von Anwendungen oder sogar kein Wiederanlauf mehr.
Dieses Dokument beschäftigt sich mit der Frage, wie Organisationen diese
Herausforderungen mithilfe von Datenmigrationssoftware bewältigen können.
Datenmigrationssoftware
Die Unternehmen können diese
Herausforderungen mithilfe verschiedener Typen von Datenmigrationssoftware bewältigen.
Je nach der Priorität der Anwendungen, der Menge der zu verlagernden
Daten und der zulässigen Ausfallzeit können Organisationen unter vielen
Datenmigrations-Tools wählen, bei denen jeweils eigene Voraussetzungen und
Einschränkungen zu beachten sind.
Offline-Migrationsmethoden
Bei Offlinemigrationsmethoden müssen die Anwendungen während der
Datenverlagerung offline sein, weshalb sie sich nur für Situationen eignen, in
denen nennenswerte Ausfallzeiten toleriert werden können. Da die Länge der
Ausfallzeit in der Regel von der Menge der übertragenen Daten abhängt, wird
Speichermigration leicht gemacht.
Seite 7
Highlights
Zu den Onlinemigrationsmethoden
gehören array-basierte Replikation,
Volume-Management oder -Replikation und host-basierte Spiegelung.
dieser Offlinemigrationsmechanismus für viel verwendete Anwendungen oder
Anwendungen, die auch außerhalb der üblichen Geschäftszeiten verfügbar
sein müssen, nicht empfohlen. Bei der Offlinemigration ist normalerweise
eine manuelle Manipulation von Daten oder Dateien erforderlich. Damit steigt
das Risiko für Benutzerfehler, weshalb sie sich für verteilte oder RemoteMigrationen nur bedingt eignet.
Wiederherstellung von Sicherungsbändern
Bei dieser Methode wird zuerst eine Sicherungskopie der Daten angefertigt.
Anschließend werden die zugehörigen Arrays und/oder Server in den
Offlinestatus versetzt, damit keine neuen Daten hinzugefügt werden. Danach
werden die Daten von den Sicherungsbändern in den neuen Arrays und/oder
Servern wiederhergestellt. Sobald der Wiederherstellungsprozess abgeschlossen
ist, werden die Systeme wieder in den Onlinestatus versetzt. Dies ist eine
sehr kostengünstige Lösung, vor allem weil bereits fast alle Organisationen
Sicherungssoftware verwenden. Andererseits erfordert sie aber einen beträchtlichen administrativen Aufwand und signifikante Ausfallzeiten der betroffenen
Anwendungen.
FTP-Übertragung
Bei dieser Methode werden Dateien manuell von den Quellsystemen über
FTP (File Transfer Protocol) in die Zielsysteme kopiert. Da die Dateien nacheinander übertragen werden, wird diese Methode nicht empfohlen, wenn es sich
um eine große Anzahl einzelner Dateien handelt. Bei der FTP-Übertragung
besteht keine Kontrolle über die für die Migration verwendete Netzbandbreite,
was andere Anwendungen und Benutzer in der Netzumgebung beeinträchtigen
kann. Außerdem kann die Vollständigkeit der Datenübertragung nicht überprüft
werden.
Online-Migrationsmethoden
Zu den Online-Migrationsmethoden
gehören arraybasierte Replikation,
Volume-Management oder -Replikation und Host-basierende
Spiegelung.
Onlinemigrationsmethoden ermöglichen im Allgemeinen die Datenverlagerung,
während Anwendungen betriebsbereit sind. Es gibt darunter jedoch Methoden,
die auf Umgebungen mit Komponenten nur eines Herstellers beschränkt
sind. Bei anderen Methoden kann es zu einer beträchtlichen Belastung der
Zentraleinheit (CPU) kommen, was Leistungsminderungen bei Anwendungen
oder andere Beeinträchtigungen zur Folge haben kann.
Speichermigration leicht gemacht.
Seite 8
Arraybasierte Replikation
Highlights
Bei dieser Methode können hohe Service-Levels garantiert werden, sie
erfordert aber die Übertragung zwischen ähnlichen Speichergeräten. Dies
senkt die Kosten, beschränkt das Rechenzentrum aber auf einen Hersteller.
Volume-Management oder -Replikation
Das Volume-Management wird hauptsächlich für die Verwaltung von Plattenressourcen durch Zuordnung der logischen Sicht des Speicherbereichs zu
den eigentlichen physischen Platten verwendet. Es eignet sich zwar für die
Verlagerung kleiner Datenmengen, kann aber sehr langsam sein. Diese Lösung
benötigt eine heterogene Speicherumgebung über ein IP-Netzwerk und kann
die kostspielige Installation zusätzlicher Software erforderlich machen.
Host-basierende Spiegelung
Bei der host-basierten Spiegelung oder Replikation werden im Allgemeinen
die Dateien nacheinander übertragen, um eine sekundäre Kopie der Daten
für eine eventuelle Wiederherstellung nach einem Katastrophenfall zu
erstellen. Bei ihrer Verwendung für die Datenmigration verursacht dieses
Konzept möglicherweise zusätzlichen Aufwand für die Anwendungsserver und
kann ein kostenintensives Management erfordern, besonders in heterogenen
Umgebungen.
Unterbrechungsfreie Online-Migration — Datenmigrationsprodukte von Softek
Die TDMF-Software von Softek
erleichtert das Upgrade des
Speichers, erhöht die Leistung
der Anwendungen und vereinfacht die Verwaltung der Verfügbarkeit von Daten über ihre
gesamte Lebensdauer.
Zurzeit sind nur wenige Produkte auf dem Markt, die eine unterbrechungsfreie
Datenmigration, also die Datenverlagerung ohne Beeinträchtigung oder Ausfall
von Anwendungen, bieten können. Die Datenmigrationssoftware von Softek
ist der bewährte Standard für die heterogene Onlinedatenverlagerung, die den
Anforderungen an Anwendungsverfügbarkeit und technische Kompatibilität
zwischen Quell- und Zielspeicher gerecht wird. Mit der TDMF-Software
von Softek können Daten während der Verfügbarkeit von Anwendungen
übertragen werden, was das Upgrade des Speichers erleichtert, die Leistung
der Anwendungen erhöht und die Verwaltung der Verfügbarkeit von Daten
über ihre gesamte Lebensdauer vereinfacht. Ganz gleich, ob die Organisation
ein Upgrade auf neue Speicherhardware (auch Hardware verschiedener
Hersteller) durchführen muss oder eine effektivere Methode zur Migration
Speichermigration leicht gemacht.
Seite 9
Highlights
Anhand echter Implementierungen
von Daten hinsichtlich Aufwand/Leistung benötigt, die Software TDMF kann
die Lösung bieten. Zusammen mit der Software Softek Logical Data Migration
Facility (LDMF) für das Verlagern von Mainframe-Daten auf Datensatzebene
bietet die TDMF-Technologie von Softek die Lösung für eine breite Palette
an Anforderungen im Rahmen von technologischer Modernisierung und
Datenmigration.
lässt sich veranschaulichen, wie
mit Technologie von Softek die
technologische Modernisierung
vereinfacht werden kann.
Die Software von Softek kann den
Anforderungen im Rahmen der
Anhand echter Szenarios aus der heutigen Geschäftswelt lässt sich veranschaulichen, wie mit Datenmigrationsprodukten von Softek die technologische
Modernisierung vereinfacht werden kann:
• Ein Fertigungsunternehmen, das mit einem projektkritischen Oracle-System
für Kundenaufträge und deren Verfolgung unter Solaris Systemen arbeitet
und eine lokale UNIX-Migration von Array zu Array durchführt.
• Eine große Bank, die mit einer Anwendung für Lastschriften und Gutschriften unter IBM z/OS arbeitet und eine lokale Mainframe-Migration von
Array zu Array durchführt.
• Ein großes Anlagen- und Kreditinstitut, das mit einer Anwendung auf der
Basis von IBM DB2, IBM CICS und Virtual Storage Access Method (VSAM)
mit Hochverfügbarkeitsanforderungen arbeitet und eine MainframeMigration mit Volume-Konsolidierung durchführt.
• Ein Fortune-500-Finanzdienstleistungsunternehmen, das mit einem projektkritischen DB2 Data Warehouse arbeitet und eine UNIX-Multi-ServerMigration von Array zu Array mit Konsolidierung durchführt.
• Eine Fortune-1000-Bank, die mit einer Finanzanwendung von Sybase
arbeitet und eine globale Migration auf neue Speicher über große Entfernung durchführt.
• Ein Versicherungsunternehmen mit einer projektkritischen Oracle-Anwendung zur Bearbeitung von Ansprüchen, das eine globale Migration auf neue
Server und neue Speicher durchführt.
• Eine Fortune-500-Bank, die mit einer Unternehmensanwendung für das
Compliance-Management arbeitet und eine lokale Microsoft-WindowsMigration von Array zu Array durchführt.
technologischen Modernisierung
gerecht werden und zu einer
Rationalisierung entsprechender
Projekte beitragen.
Die folgenden detaillierten Beschreibungen dieser Szenarios zeigen, wie Softek
den Anforderungen im Rahmen der technologischen Modernisierung gerecht
wird und zu einer Rationalisierung entsprechender Projekte beitragen kann.
Speichermigration leicht gemacht.
Seite 10
Beispiele für technologische Modernisierung
Highlights
Ein Fertigungsunternehmen verlagert mithilfe von Softek-Software
ohne wesentliche Ausfallzeiten 3 TB
Lokale UNIX-Migration von Array zu Array
In diesem Beispiel musste ein Fertigungsunternehmen, das mit einem projektkritischen Oracle-System für Kundenaufträge und deren Verfolgung unter
Solaris arbeitet, 3 TB an Bestandsdaten von einem alten Speicher-Array auf
ein neues verlagern.
an Bestandsdaten von einem alten
Speicher-Array auf ein neues.
Das Unternehmen stand vor folgenden Herausforderungen:
• Begrenzte Ausfallzeit — Die Ausfallzeit wurde auf vier Stunden am Wochenende beschränkt.
• Großes Datenvolumen — Der Anwendungsspeicher bestand aus zehn Volumes
zu je 300 GB.
• Vergrößerung der Volumes — Das geplante Kapazitätswachstum erforderte
während der Migration eine Vergrößerung der Volumes.
Das Unternehmen berücksichtigte die Vor- und Nachteile folgender
Migrationsoptionen:
• Wiederherstellung von Sicherungsbändern — Bei dieser Option hätte das
Kopieren der Daten länger als vier Stunden gedauert, was die maximale
Ausfallzeit der Anwendung überschritten hätte.
• Sun Solstice Volume Manager — Diese Option unterstützt die Vergrößerung
der Volumes nicht.
• Array-basierte Replikation — Bei dieser Option wäre eine kostspielige
Installation erforderlich gewesen, und das Unternehmen hatte nicht vor,
sie im Anschluss an die Migration zu nutzen. Zusätzlich wären Upgrades
der Firmware für die vorhandenen Arrays erforderlich gewesen, um die
aktuelle Version der array-basierten Replikation zu unterstützen, was
Ausfallzeit und Komplexität des Projekts erhöht hätte.
• VERITAS Volume Replicator (VVR) — Bei dieser Option hätte als Voraussetzung der VERITAS Volume Manager installiert werden müssen.
Speichermigration leicht gemacht.
Seite 11
Highlights
Am wichtigsten war die
Transparenz des Upgrades der
Speichertechnologie für die
Benutzer.
Das Unternehmen entschied sich für die TDMF-Technologie von Softek,
weil die asynchrone, host-basierte Migration eine kosteneffi ziente Lösung
für die Arbeit mit unterschiedlichen Plattformen war, keine Änderungen
an der Quellumgebung erforderte und die geforderte Volume-Größe in
der Zielumgebung realisieren konnte. Ein Vorteil der TDMF-Lösung war
die Vergrößerung der Speicher-Volumes der Oracle-Anwendung, was
eine ständige Ausweitung der Kapazität ermöglicht. Außerdem wurde
die Migration ohne wesentliche Ausfallzeiten für diese projektkritische
Anwendung abgeschlossen. Am wichtigsten war aber die Transparenz
des Upgrades der Speichertechnologie für die Benutzer der Anwendung.
Softek-Lösung: Lokale UNIX-Migration von Array zu Array mit
der Softek TDMF-Lösung
1. Vor der wöchentlich geplanten Betriebsunterbrechung wurde die Softek
TDMF-Technologie auf dem Host installiert und so konfiguriert, dass
die Quell- und Zielgeräte einander zugeordnet waren. Es wurde ein
Skript für ‚Unmount’ und ‚Remount’ der Quellgeräte während der
Betriebsunterbrechung am Wochenende geschrieben und im Anschluss an
die wöchentlichen Datensicherungen ausgeführt. Die dafür benötigten
30 Sekunden wirkten sich auf die geplante Ausfallzeit praktisch nicht aus.
2. Die TDMF-Lösung startete den Kopiervorgang, sobald die Anwendungen
wieder online waren. Das Kopieren lief langsam im Hintergrund ab, sodass
der Betrieb der Anwendung nicht beeinträchtigt wurde.
3. Alle Volumes wurden innerhalb von 48 Stunden synchronisiert.
4. Das Umschalten erfolgte ohne Serviceausfall. Während der Prüfung der
Leistung der neuen Volumes blieben die alten Volumes an ihrem Platz.
Speichermigration leicht gemacht.
Seite 12
Highlights
5. Die alten Volumes wurden aus der Konfiguration entfernt.
6. Die TDMF-Software wurde im System belassen und für die
unterbrechungsfreie Übertragung zweier Volumes innerhalb des neuen
Speicher-Arrays verwendet, um Leistungsprobleme zu beseitigen, die von
Pfadproblemen in der neuen Hardware verursacht wurden.
Solaris-Server mit aktiver
Oracle-Anwendung
6
Vorhanden
TDMF
1
1
4
15 Minuten
Ausfallzeit
15 Minuten
Ausfallzeit
3
Installierte ältere Arrays
2
Installierte neue Arrays
48 Stunden
5
Abbildung 2
Lokale UNIX-Migration von Array zu Array
Lokale Mainframe-Migration von Array zu Array
Ein Finanzinstitut kann sich bei
der Verlagerung aus vorhandenem
Speicher in neue Speicher-Arrays
In diesem Szenario musste eine große kanadische Bank, die mit einer Anwendung
für Lastschriften und Gutschriften auf der Plattform IBM z/OS arbeitete, die
Verlagerung aus vorhandenem Speicher in neue Speicher-Arrays vornehmen.
keine Ausfallzeiten leisten.
Die Bank stand vor folgenden Herausforderungen:
• Keine Ausfallzeit der Anwendung – Die Anwendung war ein Schlüsselfaktor
für den Umsatz und musste rund um die Uhr verfügbar sein. Die voraussichtliche Ausfallzeit von 18 Stunden für Installation und Konfiguration
neuer Arrays und vollständige Migration würde die unternehmensinterne
IT-Richtlinie verletzen und Tausende Dollar Einnahmeverlust bedeuten.
Speichermigration leicht gemacht.
Seite 13
Highlights
Bei der Migration in neue SpeicherArrays einer großen Bank war
• Große Anzahl an Volumes — Vierhundert Volumes mussten vom alten in das
neue Speicher-Array übertragen werden.
• Budgetrestriktionen — Im Budget für die Migration waren Kosten für
externe Beratung nicht berücksichtigt.
Die TDMF-Technologie von Softek war die einzige Option, da mit keiner
anderen Lösung die Migration ohne Ausfallzeiten möglich gewesen wäre.
TDMF von Softek die einzige
Option, da mit keiner anderen
Lösung die Migration ohne
Ausfallzeiten möglich gewesen
wäre.
Mit der Lösung von Softek wurde das Migrationsprojekt der Bank planmäßig
und ohne externe Ressourcen abgewickelt, sodass auch das Budget eingehalten
wurde. Und da es weder zu einer Leistungsbeeinträchtigung noch zu einem
Ausfall der Anwendung kam, konnte die Bank auch während der Migration
Geschäfte machen.
Softek-Lösung: Lokale Mainframe-Migration von Array zu Array
1. Die Softek-TDMF-Software wurde unterbrechungsfrei auf dem Host
installiert.
2. Die Speicheradministratoren führten ohne eine vorherige formale Schulung
die TDMF-Tasks “Initialisierung”, “Aktivierung” und “Kopieren” anhand
der Beispiele im Handbuch von Softek durch.
3. In der ersten Woche migrierten die Administratoren 50 Prozent der Volumes
ohne Beeinträchtigung der Systemleistung in die Zielspeicher-Arrays.
Die Migration konnte auch in Spitzenbelastungsphasen ablaufen, da
die TDMF-Software über eine dynamische Regelung verfügt, die den
Migrationsprozess je nach den Anforderungen der Anwendung beschleunigt oder bremst.
4. Zur Synchronisierung zwischen Quelle und Ziel wurden regelmäßig
Aktualisierungen durchgeführt, damit auch die Updates, die während
der Kopierphase am Quell-Volume erfolgt waren, in das Ziel-Volume
übernommen werden konnten.
5. In der zweiten Woche migrierten die Administratoren die letzten
50 Prozent der Volumes, ebenfalls ohne Beeinträchtigung der Anwendung.
Speichermigration leicht gemacht.
Seite 14
Highlights
6. Nach der abschließenden Synchronisierung nahm die TDMF-Software die
Umschaltoperation vor, um die Mainframe-E/A-Ströme an die Ziel-Volumes
umzulenken, die danach die primären Volumes waren. Das Umschalten
erfolgte ohne Serviceausfall.
7. Für den Fall eines Fehlers in einer der Phasen war eine
Zurücksetzungsoption vorgesehen: Das ursprüngliche Quell-Volume enthielt
alle Schreiboperationen, die während der Migration durchgeführt wurden.
8. Die alten Volumes wurden aus der Konfiguration entfernt.
Diese Grafik zeigt die lokale
Mainframe-Migration von
Anwendung für
Lastschriften und
Gutschriften
2
Array zu Array.
1
TDMF
6
IBM Mainframe
7
3
JANUAR
S
M
T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
8
T W
4
5
JANUAR
S
Altes Speicherarray
Abbildung 3
Lokale Mainframe-Migration von Array zu Array
M
T W
T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Neues Speicherarray
Speichermigration leicht gemacht.
Seite 15
Lokale Mainframe-Migration mit Volume-Konsolidierung
Highlights
Für das Anlagen- und Kreditinstitut
hießen die Herausforderungen
Ein großes Anlagen- und Kreditinstitut wollte ein älteres lokal angeschlossenes
Speicher-Array durch ein neues ersetzen. Das Institut arbeitete mit VSAMAnwendungen auf der Basis von DB2 und CICS mit Hochverfügbarkeitsanforderungen.
personelle Einschränkungen und
hohe Verfügbarkeit.
An die Migration wurden im Wesentlichen die folgenden Anforderungen
gestellt:
• Konvertierung der Daten zwischen Volumes unterschiedlicher Größen —
Das Projekt erforderte die Übertragung aus MOD3-Arrays in MOD3 sowie
in MOD9 sowohl auf Volume- als auch auf Datensatzebene.
• Begrenzte Ausfallzeit — Die Ausfallzeit wurde auf Sonntagmorgen beschränkt.
• Personelle Restriktionen — Für die Migration stand Personal nur in begrenztem Umfang zur Verfügung.
• Komplexes Projekt — Wegen der Komplexität der Migration und der personellen Einschränkungen wurde für das Projekt eine Dauer von mindestens
zwei Wochen vorgesehen.
Das Anlagen- und Kreditinstitut bewertete mehrere Migrationsoptionen:
• Manuelle Methoden — Diese Option wurde als zu arbeitsintensiv angesehen,
vor allem wegen des “überarbeiteten und unterbesetzten” Kundenpersonals.
Außerdem wären negative Auswirkungen auf die Bandbreite kaum zu vermeiden gewesen.
• Array-basierte Replikation — Diese Option konnte nicht verwendet werden,
da die Migration aus MOD3 in MOD9 erforderlich war.
Speichermigration leicht gemacht.
Seite 16
Highlights
Nach der Bewertung mehrerer
Migrationsoptionen entschied sich
das Anlagen- und Kreditinstitut
für TDMF- und LDMF-Software
Kombination aus TDMF- und LDMF-Software von Softek, weil damit Daten
unterbrechungsfrei migriert, MODs vergrößert und spezielle Daten auf Datensatzebene verlagert werden können. Das Projekt wurde vorfristig abgeschlossen
(geplant: 60 Stunden, tatsächlich: 55 Stunden), wobei die Datenmigration
38 Stunden dauerte. Dies war beträchtlich schneller als erwartet, außerdem
lief die Migration bei aktivem Mainframe und ohne negative Auswirkungen
auf die Benutzer ab.
von Softek, weil damit Daten
unterbrechungsfrei migriert, mit
Softek-Lösung: Lokale Mainframe-Migration mit Volume-Konsolidierung
unterschiedlich großen MODs
umgegangen und spezielle Daten
auf Datensatzebene verlagert
werden konnten.
1. Die TDMF- und die LDMF-Software wurde unterbrechungsfrei auf dem
IBM Z800 Mainframe installiert und vom Implementierungsteam geprüft.
2. Das Team ordnete Quell- und Ziel-Volumes für die TDMF-Migration zu. Die
LDMF-Software wurde verwendet, um ein einzelnes Quell-MOD3 in ein MOD9
zu migrieren, wodurch das Ziel-MOD9 in der Umgebung des vorhandenen
Speichermanagementsubsystems (SMS) erstellt wurde und keine SMS-Konfiguration für die neuen MOD9-Volumes mehr erforderlich war.
3. Das Team ordnete die restlichen MOD3 und MOD9 für die Migration zu, die
mit der LDMF-Software durchgeführt wurde. Die Zuordnung dokumentierte
die SMS-Speichergruppen und -Speicherklassen der Ziel-Volumes. Dabei
wurden auch die Volumes identifiziert, die nicht von SMS gesteuert wurden.
4. Die TDMF-Migration wurde gestartet. Im Verlaufe von zehn Stunden
(inkl. Prüfung) migrierte das Implementierungsteam 200 MOD3 in
200 MOD3 sowie 240 MOD3 in 240 MOD9. Die gesamte Migration
wurde während der Produktionszeiten durchgeführt.
5. Das Implementierungsteam konfigurierte die LDMF-Migration, indem es
Migrationsgruppen aus Quell- und Zieldatensätzen erstellte (460 QuellVolumes zu 240 Ziel-Volumes auf Datensatzebene).
6. Die LDMF-Migration wurde innerhalb von 28 Stunden durchgeführt
(Übergabe der Gruppenmigrationen, Überwachung des Fortschritts und
Prüfung der Ergebnisse). Während des gesamten Zeitraums wurde keine
Beeinträchtigung der Anwendung gemeldet.
Speichermigration leicht gemacht.
Seite 17
Highlights
7. Nach der Migration erfolgte der automatische Wiederanlauf aller
Datenbankanwendungen. Die Gesamtdauer des Ausfalls lag für alle
Anwendungen unter einer Stunde.
Diese Grafik zeigt die Migration von
7
Array zu Array mit Konsolidierung,
VSAM-Anwendungen auf
Basis von DB2 und CICS
wie sie mit Softek-Software möglich
ist.
2
1
TDMF
LDMF
IBM Z800
4
240 MOD3 zu 240 MOD9
2
4
240 MOD3 zu 240 MOD9
2
5
5
6
460 Quell-Volumes zu 240
Ziel-Volumes auf Datensatzebene
3
Ältere Arrays
Abbildung 4
Lokale Migration von Array zu Array mit Konsolidierung
Neue Arrays
Speichermigration leicht gemacht.
Seite 18
UNIX-Multi-Server-Migration von Array zu Array mit Konsolidierung
Highlights
Ein Fortune-500-Finanzdienstleistungsunternehmen arbeitete mit einem
projektkritischen DB2 Data Warehouse (24 TB DB2, 10 TB unterstützende
Dateien) auf sieben Serverplattformen IBM AIX 5.1. Der zugehörige Speicher
befand sich auf neun unterschiedlichen Speicher-Arrays, von denen einige
mehr als fünf Jahre alt waren.
Ein Finanzdienstleistungsunternehmen, das mit ständig
Das Unternehmen stand vor folgenden Herausforderungen:
wachsendem Speicher und
weiteren Herausforderungen
zu kämpfen hatte.
• Anwachsen des Speichers — Die Speicherkapazität wuchs innerhalb von
drei Jahren von 4 TB auf 30 TB. Der Speicher wurde nicht planmäßig,
sondern bedarfsorientiert vergrößert.
• Lokalisieren des Speichers — Die Speicheradministratoren waren nicht in
der Lage, den Speicher genau zu lokalisieren.
• Komplexe Umgebung — Upgrades und Änderungen am System waren
nur schwer möglich, was zu vielen Beschwerden von Benutzern über die
Systemleistung führte.
• Verlagern von Daten — Es wurde ein neues Speicher-Array gekauft, um die
Leistung mit Migration und Rekonfiguration von Volumes zu verbessern.
• Inkompatibilitäten zwischen Quelle und Ziel — Auf Grund der Komplexität
der Umgebung war das Unternehmen war nicht in der Lage, eine Migration
durchzuführen. Aufgrund der Inkompatibilität zwischen Quell- und
Zielspeicher-Arrays blieb das neue Array zwei Monate lang ungenutzt.
Das Unternehmen bewertete mehrere Migrationsoptionen:
• Offlinesicherung und -wiederherstellung mit Sicherungsbändern — Diese
Option wurde wegen der zeitlichen Restriktionen abgelehnt.
• Synchronisationstools der Betriebssysteme (BS) — Diese Option wurde
abgelehnt, da es nicht möglich war, die Start- und Endzeitpunkte für die
Migration zu kontrollieren.
• Array-basierte Replikation — Diese Option stand wegen der Inkompatibilitäten zwischen Quell- und Zielspeicher nicht zur Verfügung.
• Spiegelung mit dem Logical Volume Manager des AIX-Servers — Dies wurde
abgelehnt, da der Volume-Manager zu langsam und außerdem nicht für die
Spiegelung konfiguriert war.
Speichermigration leicht gemacht.
Seite 19
Highlights
Ein Fortune 500-Finanzdienstleistungsunternehmen entschied
sich für die Software TDMF UNIX
IP) von Softek, da sie in der Lage
war, zwischen unterschiedlichen
Plattformen zu migrieren und
mit verschiedenen logischen
Definitionen zu arbeiten.
Mit der Softek-Methodologie
für die Implementierung wurde
Das Unternehmen entschied sich für die Software TDMF UNIX (IP) von Softek,
mit der zwischen unterschiedlichen Plattformen migriert und mit verschiedenen
logischen Definitionen gearbeitet werden kann. Ein Vorteil der TDMF-Lösung
war, dass die Datenmigration auch in einer schwierigen Umgebung innerhalb
geplanter Zeitfenster durchgeführt werden konnte. Letztendlich konnte das
Unternehmen von seiner neuen Hardware profitieren. Mit dem neuen Array
waren Abfragen vier Mal schneller möglich. Außerdem konnten das Datenlayout
verbessert und die Administration stark vereinfacht werden. Am wichtigsten
war jedoch, dass fast keine Beschwerden von Benutzern über die Systemleistung
mehr eingingen. Außerdem brauchte das Unternehmen keine Leasinggebühren
für ungenutzte oder veraltete Hardware mehr zu bezahlen. Mit der SoftekMethode für die Implementierung wurde sichergestellt, dass es keine manuellen
Fehler gab und vorhandene Ressourcen effizient genutzt wurden.
Softek-Lösung: UNIX-Multi-Server-Migration von Array zu Array mit
Konsolidierung
sichergestellt, dass es keine
manuellen Fehler gab und
vorhandene Ressourcen effizient
genutzt wurden.
1. In der Phase der Vormigration erarbeitete Softek gemeinsam mit dem
Speicherhersteller einen umfassenden Test- und Konzeptnachweis, um die
Realisierbarkeit der Migrationsstrategie nachzuweisen. Das Unternehmen
entschied, die Migration mit einer geschätzten Gesamtdauer von 24 Stunden
während geplanter Ausfallzeiten an Wochenenden durchzuführen.
2. Zur Migration wurde dem Migrationsteam das System am Samstag um
20:00 Uhr übergeben. Es installierte die TDMF-Software in weniger als
15 Minuten auf sieben AIX-Hosts.
3. Der Migrationsprozess wurde mit einer Loopback-Konfiguration gestartet.
Die eigentliche Migration begann um 0:00 Uhr und endete um 4:00 Uhr.
In diesen vier Stunden wurden 22 TB an Daten verlagert.
4. Im Rahmen des Migrationsprozesses änderte das Implementierungsteam die
Größe physischer Partitionen in Volume-Gruppen, verbesserte das Layout der
Volumes im neuen Array und passte die Protokolle des IBM Journaled File
System (JFS, Journalling-Dateisystem des Betriebssystems AIX) an.
5. Am Sonntag um 15:00 Uhr, also weit vor dem geplanten Zeitpunkt wurde
das System für Vorabtests zurück übergeben. Das DB2 Data Warehouse
startete einwandfrei und ein Prüfskript konnte ausgeführt werde.
6. Das Unternehmen führte umfangreiche Tests durch, und am Ende der geplanten Unterbrechungszeit der Anwendung ging das System vollständig
in Betrieb.
Speichermigration leicht gemacht.
Seite 20
Highlights
7. Bei der nächsten geplanten Unterbrechung wurden die alten Quell-Arrays
außer Betrieb genommen und an den Besitzer zurückgegeben.
1
5
DB2 Data Warehouse
6
2
TDMF
TDMF
TDMF
TDMF
TDMF
TDMF
TDMF
AIX 5.1-Server
DS1
DS2
3
4 Stunden
22 TB
DS3
DS4
4
DS5
DS6
DS7
DS8
DS9
DS10
DS11
DS12
7
Neues Array
Alte Arrays
Abbildung 5
Multi-Server-Migration mit Konsolidierung
Globale Migration auf neue Speicher über große Entfernung
Eine Bank benötigte Hilfe bei der
Verlagerung von vier Servern in
einen anderen Bundesstaat.
Eine Fortune-1000-Bank, die mit einer Finanzanwendung von Sybase arbeitet,
verlagerte vier Server aus einem Rechenzentrum in New Jersey in ein Rechenzentrum in New York City, wobei die vorhandenen Speicher-Arrays gegen neue
ausgetauscht werden sollten.
An die Migration wurden folgende Anforderungen gestellt:
• Höherer Speicherbedarf und interne Konsolidierung — Diese Faktoren
waren die Treiber der technologischen Modernisierung.
Speichermigration leicht gemacht.
Seite 21
Highlights
• Ablauf von Zugangsberechtigungen zu Massenspeichern — Der Speicher in
New Jersey musste an den Besitzer zurückgegeben werden.
• Verlagerung von Hardware — Physische Server mussten per Kurier
verlagert werden.
• Datenverlagerung über große Entfernung — Aus dem SAN (Storage Area
Network) in New Jersey mussten Daten in das SAN in New York City
verlagert werden.
• Begrenzte Ausfallzeit — Die Ausfallzeit wurde auf die Zeit von Freitagabend bis Samstag beschränkt.
Die Bank analysierte mehrere Migrationsoptionen:
• Offlinemigration — Die Wiederherstellung von Sicherungsbändern nach
der physischen Verlagerung der Server war zwar möglich, hätte aber das
vollständige Herunterfahren von Anwendungsservern über einen Zeitraum
von 48 Stunden erfordert. Die Anforderungen an die Verfügbarkeit machten
diese Option unmöglich.
• FTP-Übertragung — Der Mangel an Kontrolle über die Bandbreite, die
Unmöglichkeit der Überprüfung der vollständigen Datenübertragung und
die Notwendigkeit der dateiweisen Übertragung führten zur Ablehnung
dieser Option.
• VERITAS Volume Replicator — Diese Option erforderte die Installation
des VERITAS Volume Manager auf den Quell- und Zielmaschinen.
• Hardwarebasierte Spiegelung — Diese Option war nicht möglich, da
sich Quell- und Ziel-Arrays voneinander unterschieden.
Eine Fortune-1000-Bank entschied
sich für die Software TDMF UNIX (IP)
von Softek, um bei der Migration
mit mehreren Betriebssystemen
zu arbeiten und schnelle Übertragungen durchzuführen.
Die Bank entschied sich für die Software TDMF UNIX (IP) von Softek, weil
damit mit mehreren Betriebssystemen gearbeitet und schnelle, kontrollierbare
Übertragungen durchgeführt werden können.
Die Migration ermöglichte der Bank, Größenvorteile zu realisieren und die
administrative Kontrolle zu verbessern. Zusätzlich konnte die Bank mit der
größeren Speicherkapazität die Sybase-Anwendung für die wichtigsten
Prozesse besser nutzen.
Softek-Lösung: Globale Migration auf neue Speicher über große
Entfernung
1. In der Zielumgebung wurde völlig neuer Speicher definiert. Die Bank hatte
die Möglichkeit, einen ’Swing-Server’ für die Migration zu nutzen. Die Daten
für die Server in New Jersey wurden auf den Swing-Server gebracht, der
während der Migration als Proxy diente.
Speichermigration leicht gemacht.
Seite 22
Highlights
Die Softek-Lösung ermöglichte eine
schnelle, sichere Migration von
der Quelle zum Ziel.
2. Am Freitag um 17:00 Uhr wurden die Anwendungen offline geschaltet und
TDMF wurde auf den Servern in New Jersey installiert.
3. Die Migration wurde so konfiguriert, dass sie von den vier Servern an ein Ziel
erfolgte. Danach wurde sie gestartet. Die vollständige Aktualisierung dauerte
zwei Stunden. Dabei wurden 2,2 TB über das WAN (Wide Area Network)
der Bank übertragen. Nach dem Abschluss übernahm die TDMF-Lösung die
Synchronisierung zwischen Quell- und Zielumgebung.
4. Nach Abschluss der Migration wurde für die Daten eine Funktionsprüfung
durchgeführt.
5. Die Server in New Jersey wurden heruntergefahren, physisch nach New York
City transportiert und am Standort der Bank installiert.
6. In der Zielumgebung wurde der Speicher des Swing-Servers für die
verlagerten Server neu gezont.
7. Die Server wurden in Betrieb genommen und getestet. Danach wurden die
Anwendungen in Betrieb genommen und getestet. Am Samstag um 6:00 Uhr
ging die Anwendung vollständig in Betrieb.
8. Bei der nächsten geplanten Unterbrechung wurde das Speicher-Array in
New Jersey offline geschaltet und für die Rückgabe an den Besitzer abgebaut.
Sybase-Anwendungen
New Jersey
TDMF
2
New York
Zielumgebung
7
2
5
3
SwingServer
1
6
WAN
1
4
8
Älteres Array
Abbildung 6
Globale Migration auf neue Speicher über große Entfernung
Neues Array
Speichermigration leicht gemacht.
Seite 23
Globale Migration auf neue Server und neue Speicher
Highlights
Ein Versicherungsunternehmen
benötigte Hilfe, um bei der Migration
einer projektkritischen Anwendung
zur Bearbeitung von Ansprüchen
Ein Versicherungsunternehmen arbeitete mit einer projektkritischen OracleAnwendung zur Bearbeitung von Ansprüchen. Es hatte ein Upgrade der vorhandenen Server mit Solaris 8 und VERITAS Filesystem/Solstice Disksuite auf
neue Server mit Solaris 9 und VERITAS Volume Manager beschlossen. Sechs TB
(reservierte 2 TB pro Server) auf einer älteren Platteneinheit sollten durch ein
neues Array ersetzt werden.
die Verfügbarkeit der Anwendung
aufrecht erhalten zu können.
Das Versicherungsunternehmen stand vor folgenden Herausforderungen:
• Begrenzte Ausfallzeit — Für jede Anwendung waren pro Woche nur
vier Stunden Ausfallzeit erlaubt.
• Restriktionen bei der Hardwareverlagerung — Es konnte immer nur ein
Server umgesetzt werden, um Risiken für die Anwendungsinfrastruktur
zu vermeiden.
• Kompatibilität zwischen neuem Speicher und vorhandenen Servern — Für
den direkten Anschluss des neuen Speichers an die vorhandenen Server
reichten die Verbindungen nicht aus. Außerdem war es riskant, neue
Gerätetreiber auf den vorhandenen Servern zu installieren.
Folgende Migrationsoptionen wurden in Betracht gezogen:
• Offlinemigration — Dies hätte zu mehreren Ausfällen geführt, die jeweils
länger als 12 Stunden gedauert hätten.
• Array-basierte Replikation — Diese Option konnte nicht verwendet werden,
da sich Quell- und Zielspeicher voneinander unterschieden und die
Plattensubsysteme nicht kompatibel waren.
• VERITAS Volume Replicator — Diese Option hätte die Installation des
VERITAS Volume Manager auf den Quellservern erfordert.
• Strukturbasierte Gerätereplikation — Dies wurde wegen der Risiken bei
der Rekonfiguration des SAN abgelehnt.
• Kashya — Dies wurde abgelehnt, weil hierbei Host-System Spiegel erstellt und
konfiguriert werden sollten. Dies war wegen der notwendigen Änderungen und
der damit verbundenen zugehörigen Betriebsunterbrechung nicht akzeptabel.
Speichermigration leicht gemacht.
Seite 24
Highlights
Ein Versicherungsunternehmen
entschied sich für die Software
TDMF UNIX (IP) von Softek als
Das Unternehmen entschied sich für die Software TDMF UNIX (IP) von Softek
als die am wenigsten riskante Option, da keine Systemneustarts erforderlich
waren. Die Migration wurde ohne den Neustart eines kritischen Services
durchgeführt. Während der Migration war die Verfügbarkeit der Anwendungen
ständig gewährleistet und für die Benutzer kam es nicht zu Ausfällen oder einer
nennenswerten Beeinträchtigung von Services.
die am wenigsten riskante Option,
die keine Neustarts erforderte.
Bei der Migration war kein Neustart
eines kritischen Service erforderlich. Außerdem war die Verfügbarkeit der Anwendungen ständig
gewährleistet und für die Benutzer
kam es nicht zu Ausfällen oder
Beeinträchtigungen von Services.
Softek-Lösung: Globale Migration auf neue Server und neue Speicher
1. In der Anfangsphase wurden Konfigurationen vorab erstellt und vom
Benutzer einstellbare Skripts für den Unmount, den Austausch der Datei
“vfstab” und den Remount der Dateisysteme geschrieben.
2. Vor dem wöchentlichen Herunterfahren wurde die TDMF-Software bei
laufendem Betrieb installiert. Nach einer Zeitspanne von insgesamt
15 Minuten für TDMF-Installation und -Konfiguration waren alle Server
konfi guriert.
3. Im Verlaufe einer Woche wurde eine vollständige Aktualisierung von
Quellserver A zu Zielserver A durchgeführt. Ein BAB (Big Asynchronous
Buffer) fing die Spitzen in der Schreibaktivität auf vorhandenen Servern ab,
um die CPU-Belastung zu minimieren und eine zu hohe E/A-Belastung zu
verhindern.
4. Die auf Zielserver A vorinstallierten neuen Versionen von Oracle und
sonstiger Software wurden getestet. Zu den täglichen Tests gehörten auch
mehrere anwendungskonsistente Versionen von Produktionsplatten. Um
nicht jedes Mal die Produktionsplatten aktualisieren zu müssen, wurden
ein Checkpoint und eine Kettungskonfiguration verwendet.
5. Nach Abschluss der Tests wurde auf die Ziel-Volumes ein Journal
geschrieben, um bei der Resynchronisation die Datenübertragung möglichst
gering zu halten.
6. Während der Betriebsunterbrechung am nächsten Wochenende wurden
die Anwendungen auf Zielserver A gestartet und für die neuen SpeicherVolumes konfiguriert. Der Quellserver A wurde außer Betrieb genommen.
Speichermigration leicht gemacht.
Seite 25
Highlights
7. In den folgenden zwei Wochen wurde dieser Prozess für die Quellserver B
und C wiederholt.
8. Während der nächsten geplanten Unterbrechung wurde das alte SpeicherArray außer Betrieb genommen.
Diese Grafik zeigt, wie die globale
7
Migration des Versicherungsuntern
7
ehmens durchgeführt wurde.
Oracle-Anwendungen
Quellumgebung
Zielumgebung
6
2
TDMF
TDMF
QuellQuellServer C Server B
3
2
4
TDMF
1
BAB
QuellServer A
Checkpoint
ZielServer A
1
4
7
4
7
3
6
5
A
JournalCheckpointBereich
B
C
Altes Array
Neue Arrays
8
Abbildung 7
Globale Migration auf neue Server und neue Speicher
Lokale Windows-Migration von Array zu Array
Eine Fortune-500-Bank, die mit einer Unternehmensanwendung für das
Compliance-Management auf der Basis von Microsoft SQL arbeitet, besaß
5,8 TB Daten auf zwei Servern. Die Bank entschied sich für eine Verlagerung
von einem älteren lokal angeschlossenen Speicher-Array auf ein neues.
Speichermigration leicht gemacht.
Seite 26
An die Migration wurden folgende Anforderungen gestellt:
Highlights
• Neuer Speicher — Der vorhandene Speicher sollte durch neuen schnelleren
und kostengünstigeren Speicher ersetzt werden.
• Begrenzte Ausfallzeit — Für den Ausfall der Anwendung standen Zeitfenster
von 0:00 Uhr bis 6:00 Uhr am Samstagmorgen und von 0:00 Uhr bis
2:00 Uhr am Dienstagmorgen zur Verfügung — die vollständige Migration
würde aber schätzungsweise eine Woche dauern.
• Rekonfiguration einer großen Anzahl an Volumes — 30 Volumes mussten
verlagert werden, was potenzielle Konfigurationsprobleme mit sich brächte.
Die Bank zog folgende Migrationsoptionen in Betracht:
Eine Fortune-500-Bank entschied
sich für die Software TDMF
Windows (IP) von Softek aufgrund
ihrer Benutzerfreundlichkeit,
• Wiederherstellung von Sicherungsbändern — Dies war wegen der Anforderungen an die Anwendungsverfügbarkeit nicht möglich.
• EMC Open Migrator — Diese anfänglich gewählte Option fiel bei einem
frühzeitigen Migrationstest durch.
• Migration/Replikation auf Dateiebene — Diese Option wurde als zu
aufwändig verworfen. Außerdem wurde vermutet, dass Benutzer ohne
ausreichende Erfahrung in der Implementierung Schwierigkeiten bei
der Konfiguration haben würden.
ihres Preises und der Möglichkeit,
während der Datenmigration die
Verfügbarkeit der Anwendungen
aufrecht erhalten zu können.
Die Bank entschied sich für die Software TDMF Windows (IP) von Softek.
Die Gründe waren die Benutzerfreundlichkeit, der Preis und die Möglichkeit,
während der Datenmigration die Verfügbarkeit der Anwendungen aufrecht
erhalten zu können.
Softek-Lösung: Lokale Windows-Migration von Array zu Array
1. Während der geplanten Unterbrechung am Samstag wurde die SoftekTDMF-Software auf dem Produktionsserver installiert. Die Ziel-Volumes
wurden mit dem Volume-/Disk-Manager verbunden. Das System wurde
neu gestartet, um den BAB-Puffer (RAM) anzulegen und das Ziel-Volume
beim Volume-/Disk-Manager zu registrieren. Die Installation dauerte
zehn Minuten pro Server. Am Ende der geplanten Unterbrechung wurde
die Anwendung neu gestartet.
Speichermigration leicht gemacht.
Seite 27
Highlights
Die lokale Windows-Migration von
Array zu Array war ein Erfolg.
2. Das Implementierungsteam konfigurierte Migrationsgruppen in Quelle und
Ziel. Mit Fernunterstützung von Softek erstellte das Team Mount-Punkte, um
das Problem des fehlenden Vorrats an Laufwerkbuchstaben zu beseitigen,
das aufgrund der vielen zu migrierenden Volumes aufgetreten war.
3. Die vollständige Aktualisierung mit TDMF wurde in einer Loopback-Konfiguration gestartet. Sie dauerte etwa 24 Stunden und erfolgte online und
ohne Beeinträchtigung der Anwendung.
4. Mit TDMF im Normalmodus prüfte das Team mit der Checkpoint-Funktion
der TDMF-Software die Daten, die zum neuen Speicher-Array migriert
wurden.
5. Während der geplanten Unterbrechung am Dienstag wurde die Anwendung
beendet und die Quell-Volumes wurden entfernt. Die Ziel-Volumes wurden
umbenannt, und die Anwendung ging mit den neuen Arrays vollständig in
Betrieb.
6. Die alten Arrays wurden stillgelegt.
5
5
1
TDMF
3
BAB
3
Produktionsserver
24 Stunden
24 Stunden
4
Checkpoint
8
2
2
Alte Arrays
Abbildung 8
Lokale Windows-Migration von Array zu Array
2
Neue Arrays
Zusammenfassung
Für die IT-Manager stellt sich die technologische Modernisierung permanent als
problematischer Prozess dar, der jedoch mit Datenmigrationssoftware vereinfacht
und rationalisiert werden kann.
Die dargestellten Szenarios veranschaulichen, wie Projekte zur technologischen
Modernisierung mit Datenmigrationssoftware von Softek rationalisiert werden
können. Softek bietet unterbrechungsfreie und flexible Speziallösungen für die
komplexen Herausforderungen der technologischen Modernisierung.
Mit Lösungen von Softek bleiben Anwendungen online und stehen im gesamten
Migrationsprozess für die Datenverarbeitung zur Verfügung. Die TDMF-Software
von Softek ist vollständig hardwareunabhängig, ermöglicht die Vergrößerung der
Volumes, passt sich den Systemanforderungen an und ermöglicht Rollbacks.
Weitere Informationen
Weitere Informationen zu Softek-Lösungen für die technologische Modernisierung finden Sie unter:
ibm.com/services/storage/migration
© Copyright IBM Corporation 2007
IBM Global Services
Route 100
Somers, NY 10589
USA
Hergestellt in den USA
06-07
Alle Rechte vorbehalten.
IBM, das IBM Logo, AIX, CICS, DB2 und z/OS
sind Marken oder eingetragene Marken der
International Business Machines Corporation in
den USA und/oder anderen Ländern.
Softek, LDMF und TDMF sind Marken oder
eingetragene Marken der Softek Storage
Solutions Corporation in den USA und/oder
anderen Ländern. Softek Storage Solutions ist ein
Unternehmen der IBM Company.
Microsoft und Windows sind Marken der
Microsoft Corporation in den USA und/oder anderen
Ländern.
UNIX ist eine eingetragene Marke der The Open
Group in den USA und/oder anderen Ländern.
Andere Namen von Unternehmen, Produkten und
Services können Marken oder Servicemarken
anderer Besitzer sein.
Verweise in dieser Veröffentlichung auf Produkte
und Services von IBM implizieren nicht, dass IBM
diese Produkte und Services in allen Ländern, in
denen IBM tätig ist, verfügbar machen wird.
GTD01274-DEDE-00