Data Guard Avaloq - doag.org · ADABAS 105 PTF's 119 ReportDaten 131 DepUebertrag 39 ValK 40 ValSt...

OracleData Guard

Für die Bankenlösung Avaloq

[email protected] Vontobel AG

[email protected] AG

Agenda

� Einleitung

� Avaloq Architektur

� Rahmenbedingungen

� Hochverfügbarkeits-Varianten

� Implementation

� Umsetzung spezieller HA-Anforderungen

� Ausblick auf 10g

Bank Vontobel AG

� Die 1924 gegründete Vontobel-Gruppe ist in schweizerischer Privatbank-Tradition auf das Vermögensmanagement ausgerichtet. Ihre beiden Kernkompetenzen sind die Vermögensverwaltung und das Investment Banking für anspruchsvolle private und institutionelle Kunden.

� Raiffeisen gehört als drittgrösste Bankengruppe der Schweiz zu den führenden Schweizer Retailbanken.

� Die Raiffeisen-Gruppe bietet seit 2004 an allen ihren Standorten in der Schweiz exklusiv Anlagedienstleistungen von Vontobel an. Im Oktober 2006 hat die Vontobel-Gruppe die Depotverwaltung für alle Raiffeisenkunden übernommen.

Trivadis AG

� Trivadis sind in Deutschland, Österreich und der Schweiz tätig. Zu ihren Dienstleistungen gehören Design, Entwicklung und Betrieb von datenbankzentrierten Gesamtlösungen (Oracle RDBMS, Microsoft SQL Server, IBM DB2, MySQL).

� an 12 Standorten arbeiten mehr als 480 Mitarbeiter, http://www.trivadis.com- Düsseldorf, Frankfurt, Freiburg, Hamburg, München, Stuttgart- Wien- Baden, Basel, Bern, Lausanne, Zürich

� Kennzahlen 2006

- Konsolidierter Umsatz CHF 86 Mio / EUR 55 Mio

- 500 Kunden, 1500 Projekte

- 120 Service Level Agreements, 5'000 Schulungsteilnehmer

- Forschungs- und Entwicklungsbudget: CHF 4.5 Mio / EUR 2.8 Mio

Produkt Avaloq

� Das Avaloq Banking System ist ein das ganze Banking umfassendes Produkt. Es liefert sämtliche Werkzeuge zur individuellen Realisation aktueller und zukünftiger Marktleistungen von Retail-, Kommerz-, Privat- und Universalbanken. (Quelle: www.avaloq.ch)

� Das Avaloq Banking System wird bei der Bank Vontobel als Core-Banking-Applikation für die Raiffeisen Wertschriftenabwicklung eingesetzt.

� Die Bank Vontobel setzte bisher für ihre eigenen Kunden ihr eigenentwickeltes Corebanking-System ein. Per 1.1.2009 wird dieses durch die Standardlösung Avaloq ersetzt.

Historie

1.1.09

Einführung Avaloq für VontobelRelease 2.6

Mitte 08

Release 2.5(Oracle 10g)

Oktober 06

Einführung Avaloq 2.2 für Raiffeisen

Mai 07

Release 2.4

April 06

Architektur-entscheid

Produktions-umgebung

Juni 06

Wertschöpfungskette

RaiffeisenRaiffeisen

Bank Vontobel

Wertschriften-Steuerungs-und Prozessdaten

Buch-haltung

Druck Kunden-output

FührungKunden-depots

ErstellungKunden-Abrechung

AbrechungAbschluss

Kundendepot

Settlement gegenüber Depotstelle

Geschäfts-abschlussam Markt

ErteilungBörsenauftrag

Avaloq Architektur

Die Architektur basiert auf einer Client-Software-Komponente, die sich über ein TCP/IP-basierendesproprietäres Protokoll auf den Avaloq Dämon verbindet.

Der Avaloq Dämon wiederum verbindet sich via Oracle Net auf die Datenbank.

Weiter sind diverse Software Interfaces angeschlossen, wie z.B. für Messaging, File Delivery und Printer Queues.Der Avaloq Dämon und die Datenbank befinden sich im hier vorliegenden Fall auf dem gleichen Server. Die Datenbank spielt dabei die Hauptrolle, da ein Grossteil der Business-Logik in SQL und PL/SQL implementiert ist.

Rahmenbedingungen 1/2

Stand: 1.1.2006

OS:Solaris 8

Oracle:Release 9i

Avaloq:Release 2.2

Luftlinie: 2.86kmLeitungslänge Weg 1: ca. 4.50kmLeitungslänge Weg 2: ca. 9.00km

RZ1

RZ2

Rahmenbedingung 2/2

Verfügbarkeit (durchschnittlich pro Quartal)

Max. Datenverlust

Max. Ausfallzeit pro Incident

Zeitraum

Betriebsmodi

98,6% =3.0h pro Monat

99,3 % = 1,5h pro Monat

KeinerKatastrophe

KeinerOperational

12 hKatastrophe

2h1hOperational

Mo – Fr 18:00 – 7:00Fr 18:00 – Sa

Mo – Fr 7:00 – 18:00

Batch / (Offline)Online

Architektur Avaloq @ Bank Vontobel AG

Middleware-R

BOSS

Middleware-V

ArchitekturSilvia_16.vsd

OTMS-R OTMS-V

Börse

DIALBA2000RB Funktionen

BOSS FTR

Output-Management

Preprocessing / Datenanreicherung

Archiv

Archivierung

Postprocessing / Formattierung

<d>

DB

Quantax

JVC90

e-Banking

DB

Handelsbuch

DB

DB

DB

DBDB

Avaloq

DB

14 D

ep

St

18 K

toS

t

19

Kd

St

20 V

alK

21 V

alS

t

32 DepPosAbst

33 ValK

34 ValSt

41DepSt

44 KdSt

45 KtoSt

47 WSFonds

38 Abstimmung

57 B

uD

epR

AI

Data-Warehouse

DB

FFS-Mart

GBA-Mart

73 VersandDaten

23

DG

Ab

r

28

Ste

ue

rau

sz

26

Ou

tpu

tMa

rktO

p

25

Tit

Lie

fAn

z

Wertschriften-Dispatcher

55 AuftrKO

27 R

ep

Lis

t

35 Tabellen

Fonds

Corona

DB

AbstimmungNostrokonto(und Depot)

Bankenbuch

Handels-PF

62 Order/Trade 46 Order/Trade

5 DepPosBewertet

Lieferungen

Corporate Actions

Börse

Fonds

Derivate

Valorenstamm

Depotbuchhatlung

Kundenverwaltung ZB

Marktoperationen

Settlement / Lieferungen

Bestand und Valor

Depotgebühren

Corporate Actions

Steuerausweis/Reports

Valorenführung

Tresor

Global Custody

Handel

Kontrollen

Ergänzen Daten

Aufbereitung

Monitoring

56 Output

Kontrolle

30FinBuBOSS

9 DepTrxComp

Fx

UBIXDerivate

36

Deri

vat

Po

s&

Sta

mm

37 DerivatAbschl

87 DerivatAbschl89 DerivatMargins

90 PosSVRB

Tools

DB

Q-Tool

IKS

SECOMigtAktionärdaten

DB

10

3 U

SQ

/EU

QR

ep

ort

date

n

Aufbereitung Output

2 RequDepPos

Invest

DB

AnlagevorschlagDB 1

10

Bö

PlT

ab

109 Tabellen

DB

Emissionen

58 EinAusLief

49 MeldEBKJourn

50 Abschl

98 CorporateActions

114 CAPositions

129 CAEvent

ZB-Funktionen

BOSS

ADABAS

105 PTF's

119 ReportDaten

131 DepUebertrag

39 ValK

40 ValSt

11

2 K

on

form

24

CA

Ab

r

93 Abstimm

138 EinAusLief

8 DepPos&St

11 ValStValK

141 FxSVRB

14

2 F

xS

VR

B

14

3 B

uc

hu

ng

118 DepBew

91 ValStEröffn

145 DevKurseFsp

146 Tabellen

102

Co

ntr

actN

ote

s

148 FspAuftr

149 WSFonds

144 DevEvalKurs

13 DepPos

130 OrdClosed

SQL-Server

DB

15

0 D

ruc

kO

utp

utT

ran

s

Fire

DB

Legal Reporting

68 ArchivGut

119 ReportDaten

RSD

147 Depotgebühren

117 EEGVollmachtsDaten

152 TransCashFlows

153

Ko

nto

Sa

ldo

DVZ

Druck

Verpackung

154 Output

155 AvaloqKeys

29 FinTrx

120

Va

lStE

m

12

1 K

dS

t

12

2 D

ep

St

12

3 D

ep

Po

sB

ew

94

Ab

sti

mm

156

DG

Be

rErt

rag

157 SettlDirectDeals

42 F

inB

uD

ialb

a158 GeldVerbucht

Hochverfügbarkeit: Bewertungskriterien

� Service Hochverfügbarkeit- Ausfall des gesamten Servers- Ausfall eines Standortes

� Daten Hochverfügbarkeit- Ausfall des Storage der Datenbank (SAN)- Avaloq Softwarefehler wie z.B. logisch falsche Daten- Menschliche Fehler wie z.B. drop tablespace- Datenbankkorruptionen (durch Oracle RDBMS Software, Hardware Fehler etc.)

Hochverfügbarkeits-Varianten

Variante

Kriterium

Stretched

Cluster

Stretched

RAC

Data Guard

Max. Protect.

Data Guard

Max. Avail.

Abgedeckte

Szenarien

Failover / Switchover

HA Anforderungen

Business

Installierte

Serverleistung

Kosten Einstieg

(CHF/Jahr)

Kosten Maximal

(CHF/Jahr)

Komplexität

Bedienbarkeit

Support Avaloq /

Kundenbasis

‚Data Guard‘-Konzept

Primary

DatabaseStandby

Database

Online

Log Files

LocalArchiving

Archived

Log Files L og Apply:

L og Apply:

L og Apply:

L og Apply:

Ent weder

Ent weder

Ent weder

Ent wederPhy si cal St andby ( redo apply)

Phy si cal St andby ( redo apply)



oder

oder

oder

oderL ogical Standby (

L ogical Standby (

L ogical Standby (

L ogical Standby ( sql

s ql

s ql

s qlapply)

apply)

apply)

apply)

ent weder

ent weder

ent weder

ent wederRealtime

Realtime

Realtime

Realtimeoder

oder

oder

oderv ia archi ved

v ia archi ved

v ia archi ved

v ia archi ved

Redo Logs

Redo Logs

Redo Logs

Redo Logs

Log Transport:Log Transport:Log Transport:Log Transport:EntwederEntwederEntwederEntweder via ARCHvia ARCHvia ARCHvia ARCH

oderoderoderoder via LGWR via LGWR via LGWR via LGWR ProzessProzessProzessProzess

Standby

Log Files

RZ1 RZ 2

‚Stretched Cluster‘-Konzept

RZ1 RZ 2

ProductionDatabase

Hochverfügbarkeits-Varianten

Variante

Kriterium

Stretched

Cluster

Stretched

RAC

Data Guard

Max. Protect.

Data Guard

Max. Avail.

Abgedeckte

Szenarien

Failover / Switchover

HA Anforderungen

Business

Installierte

Serverleistung

Kosten Einstieg

(CHF/Jahr)

Kosten Maximal

(CHF/Jahr)

Komplexität

Bedienbarkeit

Support Avaloq /

Kundenbasis

Vorteile ‘Data Guard’

� Desasterschutz: deutlich geringerer Bandbreitenverbrauch (selten mehrals 70 MBit/s)

� Keine extra Softwareschicht neben OS und Datenbank nötig(Feind Nr.1 der Hochverfügbarkeit: Komplexität…)

� Keine zusätzlichen Lizenzkosten(vorausgesetzt, lizenzierte Enterprise Edition)

� Server- oder Instanzabsturz: Restart im zweiten RZ benötigt keineInstanz Recovery im zweiten RZ (Voraussetzungen: Datenbank mind. imProtection Level ‘MaxAvailability’ und Real Time Apply und Standby sindsynchron)

� Verzögertes Nachführen der Datenbank bei gleichzeitig vorhandenemSchutz möglich

Vorteile ‘Stretched(Failover)Cluster’

� Daten müssen ausserhalb der Datenbank gespiegelt werden(z.B. Filesysteme)

� Client Applikationen benötigen fixe IP für Verbindung und könnenvorhandene Server nicht ‘durchprobieren’ (VIP notwendig)

� Keine DBA-Ressourcen� Stretched Cluster in der Breite eingeführt und seit Jahren

erfolgreich in Betrieb

Der Entscheid

� Bank Vontobel entschied sich für ‘Data Guard’, obwohl einigeder Gründe für einen ‘Stretched Cluster’ sprachen

� Einer der ersten produktivern Avaloq Anwender mit ‘Data Guard’, abermit langjähriger Erfahrung im ‘Data Guard’-Umfeld und voll unterstütztdurch Avaloq

� Zwei offene Punkte: VIP für die Avaloq Clients und zu duplizierendes Output-Filesystem

Implementation

Netzauslastung

� Bandbreitenbedarf von 7MByte/s (56Mbit/s) bei Redo-Generierungsrate von maximal 12GByte/h bei einer dediziert zugewiesenen Bandbreite von 1Gbit/s

� Bei der synchronen Übertragung Verlangsamung der Batch-Jobs um weniger als 10%, Beeinflussung im Online-Betrieb nicht spürbar

� Redo-Logs: Verzögerte Applizierung von einer Stunde, im Falle einer Umschaltung können 12GB in ca. 16min recovered werden

Monitoring

� Monitoring der ‚Data Guard‘-Umgebung erfolgt über Abfrage auf v$database über den BMC Patrol-Agent

� Geprüft wird das Attribut PROTECTION_LEVEL, das den IST-Zustandreflektiert im Gegensatz zum PROTECTION_MODE, der den SOLL-Zustandreflektiert. Der Level, resp. Mode kann folgende Werte annehmen:MAXIMUM PROTECTIONMAXIMUM AVAILABILITY ->> erwarteter Return-ValueRESYNCHRONIZATIONMAXIMUM PERFORMANCEUNPROTECTED

� Die entsprechende Abfrage, welche ins Patrol eingebunden wird, sieht wie folgt aus:SQL> select PROTECTION_LEVEL,PROTECTION_MODE from v$database;PROTECTION_LEVEL PROTECTION_MODE-------------------- --------------------MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY

HA-Anforderungen jenseits von ‚Data Guard‘ (1)

� Avaloq produziert aus der Datenbank täglich bis zu 1.5 GByte an XML und PS Dateien (ca. 90000 Dateien)

� Im Desasterfall müssen die Dateien auf der Standby-Seitezur Verfügung stehen

� Die Avaloq Clients kennen keine spezielle HA-Konfiguration und können nur für einen Host/eine IP-Adresse konfiguriert werden

� virtuelle IP nötig, die auf dem jeweils produktiven Server aktiv ist

� Gründe für einen ‚Stretched Failover Cluster‘, bedingt jedoch parallele Kombination von ‚Failover Cluster‘ und ‚Data Guard‘(nicht zu verwechseln mit einer MAA-Lösung)

� Widerspruch zum Prinzip der möglichst geringen Komplexität einer HA- Umgebung(obwohl ‚Data Guard‘-Agenten für den in der Bank Vontobel verwendeten Veritas-Cluster existiert)

HA-Anforderungen jenseits von ‚Data Guard‘ (2)

� Lösung

- Spiegelung der Devices via Volume Manager über die Standorte

- Manuelles Einbinden des Output-Filesystems und Starten der VIP via eines per Role-Based Access Control (RBAC) auszuführenden Scripts

- aktuell Oracle 9i basierte Infrastruktur: Standby-Datenbank muss manuell aktiviert werden

Ausblick auf 10g (1)

� Produktiv ging das Projekt mit Avaloq 2.2 auf Oracle 9i im Oktober 2006� Die Migration auf 2.4 erfolgt ein halbes Jahr später im Mai 2007� Avaloq 2.5 ist für Juni 2008 geplant, mit Oracle 10g

� Zentraler Punkt bei der Migration auf Oracle 10g wird die möglichst vollständige Automatisierung des Failovers sein. Kernpunkt ist dabei der Einsatz eines Observers an einem dritten Standort

Primary Standby

Ausblick auf 10g (2)

� Das automatisierte Mounten und Aktivieren der VIP kann Script und Trigger-gesteuert (DB_ROLE_CHANGE Event) angebunden werden

� Um Split-Brain-Situationen zu behandeln, braucht es einen externen Dämon auf der Primary-Seite, der den FS_FAILOVER_STATUS überwacht und mit Unmount/VIP-Shutdown reagiert

� Fazit- machbar, automatisierter als in Oracle 9i, aber unschön

� Ziel- Beliebige mit einer Primary-Datenbank assoziierte Ressourcen - Brauchbares Filesystem in der Datenbank

‘In a nutshell’

� Einer der ersten produktiven ‘Data Guard’-Anwender mit Avaloq

� Stabile und performante Lösung

� Aber die Datenbank ist nicht alles: Filesysteme und VIP

***

Wir beantworten jetzt gerne Ihre Fragen.

Data Guard Avaloq - doag.org · ADABAS 105 PTF's 119 ReportDaten 131 DepUebertrag 39 ValK 40 ValSt...

Documents

Transcript of Data Guard Avaloq - doag.org · ADABAS 105 PTF's 119 ReportDaten 131 DepUebertrag 39 ValK 40 ValSt...