Vodafone ODI ETL eszközzel töltött adattárház Disaster Recovery megoldása Rákosi Péter és Lányi Árpád
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
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
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)
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
Architektúra ábra Primary Site - RAC Data Guard DR Site - RAC Primary Storage Stand By Storage
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
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
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
Ö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
Köszönjük a megtisztelő figyelmet!