Oracle db downtime minimalizálása

Adatbázis: SQL, XML DB

Sziasztok!

Adott egy adatbázis, 150 Gb méretű, néhány ias szerver meg kb. 100 user akaszkodik rá. A megoldandó feladat az esetleges downtime minimalizálása. A fő probléma a jelenlegi (***r) megoldással, hogy hw hiba esetén a tartalék szerver+db felépítés plusz a mentések visszatöltése több órás folyamat lenne, ami nem igazán megengedhető.

A megoldás keresésénél a következők a főbb prioritások:

1. Majdnem zero downtime
2. A jelenlegi performancia (SAS diszk alrendszer) megtartása vagy a hatékonyság növelése
3. A komponensek illetve megoldások ára, support stb.

Én első körben egy aktív meg egy passzív gépből álló megoldásra gondoltam, ami egy shared storage-ot ér el (ami esetleg redundáns vagy közel real time replikál egy másik ugyanolyan storage-ra). (FreeNAS zfs-el pl.).
Ha az aktív node kiesik, akkor a passzív felcsatolja a db-t és megy az élet tovább, ahonnan az aktív abbahagyta.
Esetleg mindezt vmware alapokon.

Félelmeim között szerepel a lehetséges gyatra IOPS pl. egy iSCSI megoldással, de fixme pls.
Egyelőre ötleteket gyűjtök, hogy ki hogy csinálná illetve van e hasonló problémára működő megoldása.
Oracle RAC nem az elsők között lenne, de nyilván szóba jöhet.
Köszönöm előre is!

  • 92685 megtekintés

( f0xhu v | 2013. 06. 27., cs – 09:34 )

Az első körös felvetésed használjuk. VMWare-es virtuális gépek, a DB RDM disken az egyik node-on, shared SCSI-val a másikon megosztva (high end storage-ról prezentálva), felettük Pacemaker. Annyi csavarral, hogy kvázi aktív-aktív, egyik oldalon a dev, másikon a prd db, hiba esetén meg vándorlás, esetleg dev leállítás, de ezt a cluster logika kezeli. Ami itt nem működik rendesen, az az IAS clusterezés pacemakerrel, erre kerülő megoldás lett kidolgozva.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

Mindkét node-on két példány van létrehozva (prod,dev), de mindegyiken csak egyik megy ?
vMotion játszik e vagy a Pacemaker indítja a példányokat, ha a másik node kiesik ?

iSCSI:

- storage-ről mondanál bővebbet (akár pm -ben) ?
- milyen NIC van a node-okban ?
- performancia

Köszönöm!

DB-ből 1 prd - 1 dev, mindkettőnek van egy-egy preferált node-ja (vmware vm), ahol a PM megpróbálja elindítani. Billenésnél a teljes VG, LV struktúrát (amin maga az Oracle van [db+app]) visszük a másik node-ra és felindítjuk (ezért az RDM, preferált node-on RDM, másik node-on ugyanez a disk shared scsi). Magát a "költöztetést" a Pacemaker végzi. Amiből kettő van, az az IAS mert nem szereti a pacemakert, alatta billenésnél csak a "docroot" cserélődik.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

( o_O v | 2013. 06. 27., cs – 11:18 )

Ket megoldas van az egyik a RAC amit leirtal a masik egy standby adatbazis.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

( traktor | 2013. 06. 27., cs – 15:09 )

Amit te leirtal az nagyabol az Oracle RAC-nak egy fapados megvalositasa. A RAC valojaban sokkal tobbet tud (pl aktiv-aktiv). Mi a baj a RAC-cal, draga?

Megcsinalhatod ket fuggetlen DB-vel is (ugy ertem fuggetlenek, tehat a disk nem/sem kozos), pl ugy hogy triggerekkel szinkronizalod a ket DB-t. Ilyesmit meg az Oracle Data Guard csinal, bar az is joval tobbet tud mint amit te osszerakhatsz kezzel (tud SQL szinten es block szinten is szinkronizalni asszem).

( kz86 | 2013. 06. 27., cs – 19:29 )

Mi mostanában csináltunk hasonlót. Ha aktív-passzív megoldást választasz, akkor arra figyelj, hogy a passzív node-on egy évben csak 10 napig futhat a db, különben meg kell venned a passzív node-ra is az oracle database license-t. Ha vmware clusteren futtatod, akkor elvileg az összes nodra meg kell venni a license-t és talán a fizikai node paramétereivel kell számolni, akkor is ha csak 1 cpu-t adsz a virtuális gépnek, bár ebben nem vagyok biztos. Mi clusterware-el oldottuk meg az adatbázis redundanciát, a storage-ét pedig netapp metroclusterrel, ami kicsit drága mulatság. Storage-ra még esetleg az is járható út lehet, hogy van két storage-od, mindkettőről kiosztasz 1-1 LUN-t és normál redundanciát konfigurálsz az ASM diskgroupokon(ha ASM-en van a db) és akkor nem kell storage szinten szinkronizálni, bár ezt mi nem teszteltük, de elvileg ez is támogatott megoldás. Szerintem akkor jársz a legjobban ha Oracle Enterprise Linux + Oracle Clusterware + ASM irányba indulsz el. Így egy cégtől kapod a supportot az OS-re, clusterre és a db-re. Ráadásul ha jól összerakod a clusterware-t, akkor később onnan már csak egy lépés RAC-ra átállni és ha van Enterprise Manageretek, akkor az is natívan tudja monitorozni a clusterware-t.

( vl v | 2013. 06. 27., cs – 23:53 )

Első eldöntendő kérdés:
a) shared storage alapú megoldások
b) shared nothing alapú megoldások

a/1): manuális HA. Két gép, mindkettő el bírja érni a shared storage-ot, mind a kettő fel van konfigurálva, de csak az egyiken van beindítva az RDBMS, ha lehal, vagy bármi baja esik, akkor az operátor konstatálja, gondoskodik róla, hogy az aktív oldal ne tudjon tovább futni (worst case: odamegy, és kihúzza a tápcsatlakozót), majd kézzel elindítja a második gépen az RDBMS-t.
a/2): automatikus HA: Valamilyen cluster szoftver felügyeli a két gépet és rajta az RDBMS szolgáltatást; gondoskodik róla, hogy semmiképpen ne futhasson mindkét gépen a program.
a/3): párhuzamos aktív-aktív adatbázis: Oracle RAC. Az adatbázis egyszerre fut a két gépen, bármelyikre kapcsolódhat a kliens, és mindketten ugyanazt a shared diszkterületet buzerálják, a szükséges szinkronizálást a két RDBMS példány egymás között intézi.
b/1): alkalmazás szintű replikáció: Egy-egy gép, rajtuk egy-egy adatbázis példány, amikre bejelentkezik "az" alkalmazás, akinek a replikáció a feladata.
b/2): adatbázis szintű replikáció: Oracle Data Guard, egy-egy gép, rajtuk egy-egy adatbázis példány, az elsődleges a tartaléknak átküldi a végrehajtott tranzakciókat, probléma esetén a tartalékból elsődlegest lehet faragni.

Mindegyiknek megvan a maga előnye és hátránya.
A shared storage verziókhoz kell shared storage, ami nem olcsó, pluszban nem véd a shared storage-ot érintő hibák ellen (ergó teljesen redundáns shared storage az értelmes minimum, ami pláne nem olcsó). Egyik verzió sem véd a súlyos vagy szándékos operátori károkozástól (bejelentkezünk és töröljük a diszkről a fájlokat).
A shared nothing architektúráknál vagy szinkron replikálunk, és akkor az jelentősen le tudja rontani a latenciát (minél nagyobb a fizikai távolság, ez annál inkább probléma), vagy aszinkron replikálunk, akkor meg elveszhetnek már comittált tranzakciók.
A manuális HA esetén az operátor el tudja baszni a rendszert (elindítja a második példányt, miközben az első még túrja a diszkeket), aminek kb. az lesz a vége, hogy "és akkor vegyük elő a mentést".
Automatikus HA ill. RAC esetén meg kell oldani a quorum-problémát, amihez vagy legalább három gép kell, vagy okos, ügyes és intelligens shared storage.
RAC esetén igen-igen combos interconnect is kell, különben gyatra lesz a teljesítmény; ezen felül igen erőteljesen függ az adatbázis szerkezetétől és az alkalmazástól, hogy mennyire tolerálja a RAC teljesítményvesztés nélkül, ha ugyanazt az adatbázist egyszerre egynél több node-on támadja az alkalmazás. A RAC ezen felül kiba drága is.
Az alkalmazásszintű replikáció nehézkes és bonyolult lehet, ugyanakkor maximálisan tud igazodni az adatbázis sajátosságaihoz. Replikációnál szintén meg kell oldani a quorum-problémát, viszont itt csak a kettőnél több node jöhet szóba (vagy a manuális átkapcsolás).