Verteilte Systeme Hochschule Regensburg Vorlesung 6, 16.05.2012 Universit¨ atsstraße 31, 93053 Regensburg Prof. Dr. Jan D¨ unnweber Migration verteilter IT-Systeme: Ein Beispielprojekt Ziel der Migration: Transfer des Kundenbindungsprogramms eines Großunternehmens (F ¯ lexible O ¯ nline C ¯ u ¯ stomer S ¯ ystem, FOCUS, > 18 Mio. User) zu einer SOA (S ¯ pecial A ¯ dvanced M ¯ odern B ¯ usiness A ¯ rchitecture, SAMBA) bei minimaler Downtime http://www.heise.de/ix/inhalt/2010/11/95 FOCUS SAMBA Vertraglich wurde eine Downtime von max. 5 Tagen f¨ ur den Datentransfer (inkl. Transformation) und f¨ ur das Umh¨ angen aller Schnittstellen vereinbart Prof. Dr. Jan D¨ unnweber, Folie 2 von 1 Verteilte Systeme Herausforderungen Das Projekt beinhaltet folgende Herausforderungen: ◮ Transaktionsdaten mit mehr als 625000000 Datens¨ atzen, in > 310 GB DB 2 (Backup nur inkrementell) HD-Benchmark ≈ 80 MB/s ⇒ Speichern dauert > 2,5 Std. ◮ SAMBA (Amadeus/Erding) ist ≈ 400 km vom Altsystem (Kelsterbach) entfernt (max. 200 MBit/s Verbindung) ⇒ ¨ Ubertragung dauert > 3,5 Std. ◮ 80 synchrone und asynchrone, teils bidirektionale Schnittstellen mit garantierter Verf¨ ugbarkeit (SLAs) Die Transformationsprogramme m¨ ussen ¨ außerst hohen Performance-Anspr¨ uchen gen¨ ugen Prof. Dr. Jan D¨ unnweber, Folie 3 von 1 Verteilte Systeme Klassifikation der Schnittstellen: 1. asynchron Credit Card Partners DB2 Hotels, Travel Agencies etc. Car Rental Companies Loyalty System Credit Card Partners DB2 FOCUS Hotels, Travel Agencies etc. Car Rental Companies DB2 Loyalty System Asynchrone Schnittstellen: Punkte-Sammeln Funktionen Parameter (gesammelte Punkte) werden als Flat-Files geschickt F¨ ur den Upload der Flat-Files muss das Altsystem nicht online sein ⇒ ¨ Uberbr¨ uckung f¨ ur Punkte-Sammeln unproblematisch Die Files werden gesammelt und nach der Migration im Batch-Betrieb abgearbeitet Prof. Dr. Jan D¨ unnweber, Folie 4 von 1 Verteilte Systeme
4
Embed
Migration verteilter IT-Systeme: Ein Beispielprojektduj39113/vs_ss12/vs1vl6... · 2013. 10. 3. · Prof. Dr. Jan D¨unnweber Migration verteilter IT-Systeme: ... Vererbeitung im divide-and-conquer
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Die Transformationsprogramme mussen außerst hohenPerformance-Anspruchen genugen
Prof. Dr. Jan Dunnweber, Folie 3 von 1 Verteilte Systeme
Klassifikation der Schnittstellen: 1. asynchron
Credit Card Partners
DB2
Hotels, Travel Agencies etc.
Car Rental Companies
Loyalty
System
Credit Card Partners
DB2
FOCUS
Hotels, Travel Agencies etc.
Car Rental Companies
DB2
Loyalty
System
Asynchrone
Schnittstellen:
Punkte-Sammeln
Funktionen
Parameter (gesammelte
Punkte) werden als
Flat-Files geschickt
Fur den Upload der
Flat-Files muss das
Altsystem nicht online
sein
⇒ Uberbruckung fur Punkte-Sammeln unproblematisch
Die Files werden gesammelt und nach der Migration im
Batch-Betrieb abgearbeitet
Prof. Dr. Jan Dunnweber, Folie 4 von 1 Verteilte Systeme
Klassifikation der Schnittstellen: 2. synchron
Ticket Machines
DB2
FOCUS
Web Stores
Call Centers
Loyalty
System
DB2DB2DB2
Loyalty
System
Synchrone
Schnittstellen:
Partnersysteme nutzen
Direktanbindung fur
Punkte-Ausgeben
Wahrend der Migration
ist keine direkte
Anbindung moglich
Betroffen sind u. a. Call
Center, Web und
Verkaufsautomaten
⇒ Keine Uberbruckung fur Punkte-Ausgeben
u. a. der wichtige Upgrade-Prozess ist wahrend der gesamten
Downtime (ohne aufwendige Uberbruckung) nicht verfugbar
Prof. Dr. Jan Dunnweber, Folie 5 von 1 Verteilte Systeme
Wahl der Migrationsstrategie
Vergleich der Trade-Offs alternativer Strategien
Feststellung: Alle Vorgehensweisen erfordern Downtime
d.h. Systemfunktionalitat vorubergehend nicht (voll) verfugbar
Lange und Auswirkungen der Downtime variieren
Ziele:
1 Anwender bemerken moglichst wenig von der Migration2 Minimierung des Transferaufwands ⇒ kurze Downtime3 Minimierung des Aufwands bei der Implementierung
Welches Ziel soll priorisiert werden?
Zur Entscheidungsfindung:Analyse von drei moglichen Migrationsvarianten:
1 Big Bang Migration2 On The Fly Migration3 Parallelbetrieb
Prof. Dr. Jan Dunnweber, Folie 6 von 1 Verteilte Systeme
Vergleich der Strategien: 1) Der Big Bang
Legacy System Target System
Staging Area
Source-
DBMig.-DB Target-
DB
rea
d
write
extract
1 retrie
vepr
oces
s
formatarrange
store
transform
2
load
3
rea
d
write
business level
tool level
database level
big bang
disc
onne
ct
site
1
site
2
site
3
Legacy System Target System
Staging Area
Source-
DBMig.-DB Target-
DB
rea
d
write
extract
1 retrie
vepr
oces
s
formatarrange
store
transform
2
load
3
rea
d
write
big bang
disc
onne
ct
site
1
site
2
site
3
Legacy System Target System
Staging Area
Source-
DBMig.-DB Target-
DB
rea
d
write
retrie
vepr
oces
s
formatarrange
store
rea
d
write
business level
tool level
database level
big bang
disc
onne
ct
site
1
site
2
site
3
Zentrale Schritte: Extract, Transform & Load
Vertikale Linien stellen Netzwerkgrenzen dar
Horizontale Linien sind Abstraktionsebenen
Prof. Dr. Jan Dunnweber, Folie 7 von 1 Verteilte Systeme
Big Bang: Extract, Transform und Load
Legacy System Target System
Staging Area
Source-
DBMig.-DB Target-
DB
rea
d
write
extract
1 retrie
vepr
oces
s
formatarrange
store
transform
2
load
3
rea
d
write
business level
tool level
database level
big bang
disc
onne
ct
site
1
site
2
site
3
Legacy System Target System
Staging Area
Source-
DBMig.-DB Target-
DB
rea
d
write
extract
1 retrie
vepr
oces
s
formatarrange
store
transform
2
load
3
rea
d
write
business level
tool level
database level
big bang
disc
onne
ct
site
1
site
2
site
3
Legacy System Target System
Staging Area
Source-
DBMig.-DB Target-
DB
rea
d
write
extract
1 retrie
vepr
oces
s
formatarrange
store
transform
2
load
3
rea
d
write
business level
tool level
database level
big bang
disc
onne
ct
site
1
site
2
site
3
Step ➀: Altsystem fur Datenexport abschalten
Step ➁: Pipeline-parallele Verarbeitung der Transformationen
Step ➂: SQL-Loader (oder Batch Insert) furs Laden
Prof. Dr. Jan Dunnweber, Folie 8 von 1 Verteilte Systeme
Big Bang: Vorteile & Nachteile
Legacy System Target System
Staging Area
Source-
DBMig.-DB Target-
DB
rea
d
write
extract
1 retrie
vepr
oces
s
formatarrange
store
transform
2
load
3
rea
d
write
business level
tool level
database level
big bang
disc
onne
ct
site
1
site
2
site
3
⊕ Neue Software nur auf der Staging Area⊕ Vollstandige Datenprufung, vor und nach der Migration⊕ Fault-Tolerance: Fallback mittels Re-Launch das Altsystems
⊖ Wahrnehmbare Downtime fur alle Business-Level Programme
Prof. Dr. Jan Dunnweber, Folie 9 von 1 Verteilte Systeme
2) On-The-Fly Migration
Data Access Layer
Target System
Staging Area
Source
DBMig.-DB Target
DB
rea
d
capture
extraction phases
1 retri
eve
proc
ess
format arrange
store
transformation
phases
2
Ladephasen
3
Legacy System
δ−data
rea
d
apply
Data Access Layer
Transformation von δ-Daten in Datenzugriffsschicht
⊕ Eventuell uberhaupt keine Downtime⊖ δ-Mapping notig (nicht immer eindeutig)
⊖ Terminierung nicht garantiert (wenn δs zu schnell wachsen)
Prof. Dr. Jan Dunnweber, Folie 10 von 1 Verteilte Systeme
3) Der Parallelbetrieb
Target System
Staging Area
Source
DBMig.-DB Fallback
DB
Legacy System write
Coordinator
Target
DB
Target
DB
look
up backup
Source/Target
Gateway
Source/Target
Gateway
extraction
1
transformation
2
load
3
write
read read
Das Altsystem lauft weiter
⊕ Keine Downtime⊖ Komplexe Gateways und redundante Konvertierungen
⊖ Jeder Datenzugriff lauft uber das Netzwerk
Prof. Dr. Jan Dunnweber, Folie 11 von 1 Verteilte Systeme
Vereinigung der Strategien: QuickApply
Mig.-DB
QuickApply
Data Propagator
Target System
Staging Area
Source
DB
Target
DB
re
ad
ca
ptu
re
extraktion
and update
1
load
3
re
ad
write
Legacy System
δ−data
transformation
2
apply
Updates laufen direkt auf die Staging Area (vgl. iX 11/2010)
⊕ Schreibzugriffe werden per DB2 Data Propagator erfasst⊕ Keine zielseitige Datenzugriffsschicht ⇒ kein Mapping
⊕ Effiziente und parallele Verarbeitung der δ-Daten
Prof. Dr. Jan Dunnweber, Folie 12 von 1 Verteilte Systeme
Verteilte Datenverarbeitung in QuickApply
commit
SQ
LJava
JNI
merge
wait
mergemerge
pthread_barrier_wait
mergemerge
merge
JNI
pthread_create
pthread_barrier_wait
Java
C
work unit # order no. customer id date
A74992 39235582 19231 13.12.09
A74A3A 16883604 21844 13.12.09
A72AFD 65878804 21844 13.12.09
sort
UPDATE b136t001 SET
order_no='65878804',customer_id='21844',
date=to_date('13-DEC-09');
INSERT INTO b136t001
(order_no,customer_id,date)
VALUES('39235582','19231',
to_date('13-DEC-09') );
format
Zwei 24 CPU Server mit 8 Cores pro CPU
217 Tabellen
Parallelverarbeitung
mittels POSIX-Threads
1 Thread (LWP) pro Tabelle
Vererbeitung im divide-and-conquer Modus
Jeder Thread vereint zwei Arrays
jeder Schritt unterteilt die Eingabe
C & Java Code kommunizieren via JNI
⇒ Die effizienteste Technologyfur jeden Migrationsschritt
Prof. Dr. Jan Dunnweber, Folie 13 von 1 Verteilte Systeme
Die Implementierung von QuickApply
LOAD DATA LOG NO INDDN SYSREC01 INTO TABLE CD_B136V001