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
DR Site - RAC
Data Guard
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!
