2004 MAR MC Seminar HPUX와 오라클 DB의 HA

2004 MAR MC Seminar HPUX와 오라클 DB의 HA 아키텍처 구성 황명석 한국 HP / 2004. 3. 18

Agenda 1. Parallel Hardware Architecture 2. Oracle RAC 성능 3. Oracle RAC와 hp Cluster Type 4. Oracle RAC의 TAF

Parallel Hardware Architecture

Parallel Hardware Architecture • Tightly Coupled System • Loosely Coupled System • Massively Parallel System

Tightly Coupled System 다수의 CPU가 memory 공유 • 각 CPU는 common Bus를 통해 shared memory access • Performance는 Memory Bus의 Bandwidth에 의해 결정 • SMP System (Symmetric Multiple Process) •

Loosely Coupled Systems Loosely Coupled systems (cluster)의 shared disk는 하드웨어 레벨에서 구현. • Shared disk system는 물리적으로 cluster node간에 동일한 disk array를 공유. •

Shared Nothing Implementations - MPP • Shared Nothing Implementations - MPP – 각 노드는 하나 이상의 CPU를 갖는다. – 메모리는 노드간에 공유하지 않는다. – High-speed interconnect 사용을 기반으로 한다. – File의 I/O request는 user program에게 투명한 high-speed interconnect를 통하여 remote disk를 accessing 한다.

Oracle RAC의 성능

e-Business 시대의 RAC 필요성 Ÿ e-Business 요구사항 Ÿ Ÿ Ÿ Ÿ 높은 가용성 (High Availability) 높은 확장성 (High Scalability) 높은 서비스품질 (High Quality Of Services) 시장의 확대 (Extend Market – Globalization) DBA 생산성 향상 On-Line Management Business intelligence E-business를 위한 개발 환경

Cache Fusion Architecture • 완벽한 Cache Fusion – Cache-to-Cache 데이터 전송 – 공유 캐쉬는 느린 I/O 작 업을 줄인다. – 데이터는 고성능 interconnect 를 통해 다 른 노드에 직접 전송 • 확장성 제공

Oracle 9 i RAC Scalability HP-UX 기반 Platform에서의 테스트 결과

Oracle RAC와 hp Cluster Type

HP Service. Guard Cluster Protection Levels Flexibility Functionality Metro Cluster Local Cluster Campus Cluster • single cluster • same city, separate sites • single cluster • same site, separate bldgs • automatic failover • within single data center Continen tal Cluster • multiple clusters • different cities, different countries • automatic failover • “Push-button” failover • automatic failover Distance

Local Cluster supported with 9 i RAC • Single Cluster • Automatic Failover • Distances • up to 500 m with direct FC • up to 11 km with FC switches (500 m to switch, 10 km between switches) • up to 25 m with direct SCSI within single data center RAC Node A Data Center 1 Node B Storage

Campus Cluster supported with 9 i RAC • Single Cluster • Automatic Failover • Software Mirroring with HP Mirror. Disk/UX • Only 2 node cluster supported with RAC & SLVM, and 4 nodes supported with RAC & Veritas CVM. • For all storage types • Distances • up to 10 km with Oracle 9 i RAC with FC switch/hub • up to 100 km only with MC/SG (extended Campus. Cluster) with DWDM same site, separate buildings RAC Node A Node B Mirror. UX Storage Data Center 1 Data Center 2

Metro Cluster not supported with 9 i RAC • Single Cluster • Rapid, automatic site recovery without human intervention • Storage Hardware Mirroring • separate arbitrator for split brain situations • Distances for CA/SRDF • ESCON, ca. 43 km • FC direct, ca. 500 m • FC switches, ca. 10 km • FC switches plus ultra long haul GBIC ca. 80 km • DWDM, ca. 100 km same city, separate sites Node C MC/SG Arbitrator Node A XP/EMC Node B CA / SRDF Data Center 1 XP/EMC Data Center 2

Continental Cluster supported with 9 i RAC • Separate Cluster • Locate data centers at economically and/or strategically best locations • “Push-button” failover across 1000 s of km • Distances • Unlimited distance between data centers! different cities, different countries RAC Node A Node B XP/EMC Data Center 1 WAN Node B XP/EMC Data Center 2

Oracle Data. Guard supported with 9 i RAC • RAC cluster in one data center • Changes get propagated to second data center with Oracle Data. Guard (formerly Automated Standby Database) • Distances RAC Node A Node B Oracle Data. Guard Node C • no limitation for Oracle Data. Guard Storage disaster tolarant Data Center 1 Data Center 2

Standby Database History 정리 • Oracle Version 7. 3 custom Standby Databases – • Current Log 반영 불가(Only transferred arch. files) Oracle 8 i Automated Standby Read only databases, Managed recovery – Remote archiving – • Oracle 8 i Data Guard Automation: Single command switchover and failover – OPS and OFS support – • Oracle 9 i Data Guard Built in zero Data Loss capability (Current log 반영) – GUI interface integrated with OEM – • Oracle 9 i R 2 Data Guard Oracle 9 i Data Guard Logical Standby database – SQL apply instead of log – Query & Reporting enabled –

Oracle RAC의 Transparent Application Failover Oracle RAC의 TAF

What do you want to avoid? • Database connections are stateful, simple network failover is insufficient • Even after a fast database recovery clients were forced to exit their application and reconnect to the database • Very intrusive • Work lost 27

Client Side Load Balancing • Clients connect to instance using random method (uses address list in tnsnames. ora) Node 1 Client 2 Network Client 3 lsnr 1 rac 1 instance Node 2 Client n lsnr 2 9 i. RAC Database rac 2 instance 28

Listener Load Balancing • Listeners balance load using CPU/user load Node 1 Client 2 Network Client 3 lsnr 1 rac 1 instance Node 2 Client n lsnr 2 9 i. RAC Database rac 2 instance 29

Listener Load Balancing • Listeners balance load using CPU/user load Node 1 Client 2 Network Client 3 lsnr 1 rac 1 instance Node 2 Client n lsnr 2 9 i. RAC Database rac 2 instance 30

Connect Time Failover • Automatically retries the connection (uses the next entry in the address list in tnsnames. ora) Node 1 Client lsnr 1 rac 1 instance TNS Node 2 lsnr 2 9 i. RAC Database rac 2 instance 31

TAF, Overview • Oracle 9 i provides a high availability architecture that provides transparent client failover capability Little or no user downtime – Applications and users are automatically and transparently reconnected to another system – Applications and queries continue uninterrupted – Login context maintained – Computer A Computer B Node A in an RAC cluster fails, users are migrated Computer A Computer B 32

Characteristics of TAF • TAF protects or fails-over: • Client/server connection • User session state • Active cursors (select statements) that have begun to return results • Not failed over: - Active update transactions - PL/SQL server-side package variables 33

Three “Levels” of TAF Functionality • TYPE=SESSION, METHOD=BASIC (Login Failover) • Client is automatically logged into surviving node of cluster • TYPE=SELECT (Statement Failover) • Node failure occurs during query • Client fails over to a surviving node and is logged in • Query replayed on surviving node but only rows not returned during the original query execution are returned • METHOD=PRECONNECT (“Fast” Session Failover) • Client connected to two instances at session establishment • Avoid impact of “login storm” during failover to surviving node in Real Applications Cluster or Oracle Parallel Server 34

TAF Select Failover allows the application to continue execution or fetching • Leverages Oracle’s multi-versioning read consistency to ensure results are identical • Client SELECT * FROM emp; empno SELECT * FROM emp; name 7369 Smith 7499 Allen 7521 Ward 7566 Jones 7654 Martin 7698 Blake Rows Partially Returned When Failover Occurred empno Instance 1 Instance 2 name 7369 Smith 7499 Allen Continues Returning 7521 Ward Remaining Rows from here 7566 Jones 7654 Martin 7698 Blake DB 35