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

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


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


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


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


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


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


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


Big Bang: Extract, Transform und Load


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


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


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


Big Bang: Vorteile & Nachteile


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


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)


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


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


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


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',




VALUES('43233433','43431',to_date('13-DEC-09');







UPDATE b136t001 SET

order_no='16883604',customer_id='21844',


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


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.


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


Documents

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