View
0
Download
0
Category
Preview:
Citation preview
Verteilte SystemeHochschule RegensburgVorlesung 6, 16.05.2012
Universitatsstraße 31, 93053 Regensburg
Prof. Dr. Jan Dunnweber
Migration verteilter IT-Systeme: Ein Beispielprojekt
Ziel der Migration: Transfer des Kundenbindungsprogramms einesGroß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 fur den
Datentransfer (inkl. Transformation) und fur das Umhangen aller
Schnittstellen vereinbart
Prof. Dr. Jan Dunnweber, Folie 2 von 1 Verteilte Systeme
Herausforderungen
Das Projekt beinhaltet folgende Herausforderungen:◮ Transaktionsdaten mit mehr als 625000000 Datensatzen,
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 Schnittstellenmit garantierter Verfugbarkeit (SLAs)
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
( stmt_type POSITION ( 1 ) CHAR ( 10 ) ,
tstamp POSITION ( 11 ) TIMESTAMP EXTERNAL ( 26 ),
seq_num POSITION ( 39 ) CHAR ( 10 ),
work_unit_num POSITION ( 50 ) CHAR ( 10 ),
order_no POSITION ( 61 ) CHAR ( 10 ),
customer_id POSITION ( 72 ) NUMBER ( 8 ),
date POSITION ( 81 ) DATE ( 8 ) )
public class CNTLParser {
HashMap<String, HashMap<String, Scaling>> scalingMap;
public final String EBCDIC = "Cp037", ISO8859_1 = "ISO8859_1"
public DDLdata createDDL(File cntlFile) throws Exception {
DDLdata ddl = new DDLdata();
try {
InputStreamReader isr = new InputStreamReader(new FileInputStream(cntlFile), EBCDIC);
StringTokenizer tokens = new StringTokenizer(sourceFile, " ");
while (tokens.hasMoreTokens()) {
String token = tokens.nextToken();
if (token.contains(columnSeparator) && tokens.hasMoreElements()) {
column.setName(parseColumn(trimQuotes(token)));
ddl.addColumn(column);
} else if (token.startsWith("POSITION") && tokens.hasMoreElements()) {
token = tokens.nextToken();
column.setPosition(parsePosition(token));
}
} catch (UnsupportedEncodingException usee) {
throw new DDLProcessingException("Control File " + cntlFile + " is not properly encoded");
}
return ddl;
}
}
stmt type tstamp seq # work unit # order no. customer id date
INSERT 13.12.09 08:01:27,629119 C53A702 A74992 39235582 19231 13.12.09
UPDATE 13.12.09 09:02:26,262539 C53A776 A74A3A 16883604 21844 13.12.09
UPDATE 13.12.09 09:12:26,542545 C53A776 A74AFD 65878804 21844 13.12.09
DELETE 12.12.09 18:32:59,355835 C53AFD 5 A36112 12383655 12844 12.12.09
INSERT 12.12.09 18:21:27,239154 C53A702 A74422 43233433 43431 12.12.09
INSERT 12.12.09 14:01:22,354914 C53A702 A35544 39234534 23431 12.12.09
INSERT 13.12.09 14:44:27,124145 C53AA2 2 C233C 3 35452224 54431 13.12.09
INSERT 13.12.09 16:12:07,456165 C53AA2 2 C2FF0 1 12323582 12331 13.12.09
char prkeys[][][] = {
{ “order_no", "customer_id" },
{ "valid_since”, “type_code” },
{ "name", "effective_date" },
{ "internal_id”, "line_nbr", "language_ind" },
...}
int pkpos[][] = { { 4, 5 }, { 6, 9 }, ... }
int pklength[] = { 2,2,2,3,3,1,1 ...}
int sizes[] = { 7,5,15,14,7,5, ... }
char columns[][][] = {
{ "stmt_type","tstamp",
"seq_num","work_unit_num",
"order_no","customer_id","date",
}, {
"stmt_type","tstamp",
"seq_num","work_unit_num",
"item_id", “item_type”,
“valid_since”, “country_id”,
“cust_ref”, “type_code” },
} ... }
#include <pthread.h>
#include <stdio.h>
int comp(const void *in1, const void *in2) {
char ***lval = (char ***)in1,
***rval = (char ***)in2;
par1 = strtol((*lval)[1], NULL, 16),
par2 = strtol((*rval)[1], NULL, 16);
return par1 - par2; }
result *process(char *source, char *tabnam) {
char ***deltas = read(source, &records);
qsort(deltas, records, sizeof(char **), comp);
format(deltas, records, tabname);
}
int main(int argc, char **argv) {
pthread_t *sorters = malloc(TABLES);
pthread_barrier_init(&barrier, NULL, TABLES);
for(i = 0; i < TABLES; ++i) {
pthread_create(&sorters[i], NULL, process);
fprintf(output[i], "%s\n", res.stats[i]);
fclose(output[i]);
return 0u; }
DELETE FROM b136t001
where order_no='12383655',
customer_id='12844',
date=to_date('12-DEC-09');
INSERT INTO b136t001
(order_no,customer_id,date)
VALUES('43233433','43431',to_date('13-DEC-09');
INSERT INTO b136t001
(order_no,customer_id,date)
VALUES('39234534','23431',to_date('13-DEC-09');
INSERT INTO b136t001
(order_no,customer_id,date)
VALUES('39235582','19231',to_date('13-DEC-09');
UPDATE b136t001 SET
order_no='16883604',customer_id='21844',
date=to_date('13-DEC-09');
CDC Database Table
CNTL File
Java
(CNTL file parser)
C Header
(data definitions)Parallel C Program
(format + sort)
SQL
(apply statements)
Input Output Result
auto-generated
auto-generated auto-generated
1 2 3 4
Eingabe sind Change-Data-Capture Tabellen (CDC , i. e. , δ-Daten)
Ein Java-Programm fugt δ-Daten in ein C-Template ein
Der resultierende C-code generiert SQL fur den verteilten Apply
⇒ Der meiste Code wird generiert
Prof. Dr. Jan Dunnweber, Folie 14 von 1 Verteilte Systeme
Auswertung und Schlußfolgerungen
Laden, Sortieren und Formatieren
innerhalb weniger Minuten
Java
C+POSIX Threads
906672
3485068
6095741
0
100
200
300
400
500
600
Java-Teil benotigt ≈ 6 Min.
C-Teil benotigt ≈ 2 Min.
SQL-Teil benotigt ≈ 1-2 Min.
pro Tabelle
Volle Replication dauert ≈ 2 Std.
Dump-Transfer(bei 30 MBit/s) benotigt
dagegen ca. 2 Tage
⇒ Verteilte Datenverarbeitung beschleunigt die Migration ungemein.
Prof. Dr. Jan Dunnweber, Folie 15 von 1 Verteilte Systeme
Zusammenfassung
Was haben wir gelernt?
Migrations und Integrationsprojekte haben Extract, Transform und
Load-Phasen (ETL)
Uber Abfolge, Verteilung und Implementierung der Phasen
entscheidet die Migrationsstrategie
Standardverfahren sind: Big Bang, On-The-Fly und Parallelbetrieb
Je nach Bedarf sind auch Mischformen der Strategien moglich
Fur die Replikation und ETL konnen Standardtools
(DataPropagator, etc.) oder Individualsoftware zum Einsatz
kommen
Prof. Dr. Jan Dunnweber, Folie 16 von 1 Verteilte Systeme
Recommended