Vodafone ODI ETL eszközzel töltött adattárház Disaster Recovery megoldása. Rákosi Péter és Lányi Árpád

Átírás

1 Vodafone ODI ETL eszközzel töltött adattárház Disaster Recovery megoldása Rákosi Péter és Lányi Árpád

2 Adattárház korábbi üzemeltetési jellemzői Online szolgáltatásokat nem szolgált ki, klasszikus elemzésre volt használva Az adattárházak sajátosságai miatt enyhébb, más típusú SLA-k, nem OLTP A töltések optimalizálása érdekében NOARCHIVELOG üzemmód volt a jellemző Backup/recovery offline mentésekből, mivel a mentést követő adat módosítások reprodukálhatók Az enyhe SLA miatt a HA ás DR jellemzően backup visszatöltéssel megoldva

3 A mai adattárházak üzemeltetési jellemzői A klasszikus adattárház kiszolgálás kibővül online szolgáltatásokkal Egyre fontosabb a 7*24-es rendelkezésre állás A HW erőforrások megengedik az ARCHIVELOG üzemmódot Az ARCHIVELOG üzemmód gyorsabb helyreállást biztosít A High Availability (HA) és Disaster Recovery (DR) megoldások alkalmazása szükséges

4 DWH architektúra Adattárház (~50 TB) Több node-os 11gR2-es Oracle Real Application Clusters, ASM fájlrendszeren A redo generálás Töltési időszakban mért csúcsérték: 100 MB/s (átlag ~18 MB/s) 24 h alatt 0,5 TB 1,5 TB összes redo log DWH szolgáltatások: Reporting, kampánymenedzsment, boltok kiszolgálása, adatbetöltés DWH SLA-k (óránkénti és 20 percenkénti betöltés az éjszakai mellett, 7*24-es rendelkezésre állás) Az adattárház ETL folyamata az ODI ELT eszközzel van megvalósítva HA -> Real Application Clusters (RAC), DR -> Data Guard (DG)

5 Data Guard konfiguráció Maximum Performance üzemmód Log Transport: LGWR-rel ROLE based service használat: PROD service család Active DG read-only service család Backup a standby adatbázisról Data Guard Broker és Oracle Enterprise Manager Cloud Control eszközöket használva management célokra

6 Architektúra ábra Primary Site - RAC Data Guard DR Site - RAC Primary Storage Stand By Storage

7 ODI RAC - HA konfiguráció standalone agent konfig minden node-on egy agent, az adott agent csak az adott node-on futó adatbázis példányhoz kapcsolódik, ott futtat betöltési lépéseket ETL futás közben load balancing van, terheltségtől (CPU, memória, IO, és parallelizáció) függően dedikálunk ETL lépéseket node-okra (agent-re, és így adatbázis példányra) ha egy node kiesik, a többi node-on futó agent tovább tudja vinni az ETL folyamatot, nincs kiemelt agent

8 ODI DG DR konfiguráció DR oldalon is minden node-on standalone agent van (a primary-ről agent domain másolással kell telepíteni) standby oldalon nem futnak az agent-ek átkapcsolás során manuális konfiguráció átállítás (ODI repo-ban a node címek/nevek update-je; agent indítás a primary-n, standby-on leállítás) ETL folyamatok ODI load plan-ek, amik elemi lépései az ODI mappingek. Hibakezelés mapping szinten történik (hiba esetén mappinget lehet újraindítani) egy ODI mapping 1 tranzakcióban fut (ODI Knowledge Module megoldás), így hiba esetén a mapping rollback-elődik, és újra lehet futtatni forrásrendszerekből file-okból töltünk, NFS-sel ki van ajánlva a primary és standby összes node-jára. Átkapcsolás során így ugyanazok lesznek a forrás állományok, és így konzisztensen tudjuk a betöltést tovább folytatni

9 Alternatív DR megoldások Backup/recovery alkalmazás: Hátránya: sok idő a nagy adatmennyiség visszaállítása Storage szintű szinkronizálás: 8-10-szer annyi bit másolására van szükség a szinkronizálásához Korrupció védelmet nem biztosít, mivel a storage számára a korrupt bit ugyanolyan mint a nem korrupt, ezért átmásolja

10 Összegzés A redo log szinkron csúcs időben 100 MB/s és átlagosan 18 MB/s sávszélességet igényel Az LGWR fél-egy core CPU-t igényel log küldéshez A telephelyváltás ~15 perc időt vesz igénybe A körültekintő ODI fejlesztési módszertan konzisztens telephelyváltást biztosít Normál üzemben a standby erőforrásai használhatók read-only lekérdezésekre és a backup végrehajtására

11 Köszönjük a megtisztelő figyelmet!