Download Oracle RAC와 hp Cluster Type

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Relational model wikipedia , lookup

Database wikipedia , lookup

Clusterpoint wikipedia , lookup

Oracle Database wikipedia , lookup

Object-relational impedance mismatch wikipedia , lookup

Database model wikipedia , lookup

Transcript
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 를 통해 다
른 노드에 직접 전송
•
확장성 제공
Oracle9i RAC Scalability
HP-UX 기반 Platform에서의
테스트 결과
Oracle RAC와 hp
Cluster Type
HP ServiceGuard Cluster
Protection Levels
Flexibility
Functionality
Metro
Cluster
Local
Cluster
Campus
Cluster
• single cluster
• single cluster
• same city,
separate sites
• single cluster
• same site,
separate bldgs
• automatic
failover
• within single
data center
• automatic
failover
Continen
tal
Cluster
• multiple clusters
• different cities,
different
countries
• “Push-button”
failover
• automatic
failover
Distance
Local Cluster supported with 9i RAC
• Single Cluster
• Automatic Failover
• Distances
• up to 500m with direct FC
• up to 11km with FC switches
(500m
to switch, 10km between
switches)
• up to 25m with direct SCSI
within single data center
RAC
Node A
Data Center 1
Node B
Storage
Campus Cluster supported with 9i RAC
• Single Cluster
• Automatic Failover
• Software Mirroring with HP
MirrorDisk/UX
• Only 2 node cluster supported with
RAC & SLVM, and 4 nodes
supported with RAC & Veritas CVM.
• For all storage types
• Distances
RAC
Node A
Node B
MirrorUX
MirrorUX
• up to 10km with Oracle9i RAC
with FC switch/hub
• up to 100km only with MC/SG
(extended CampusCluster) with
DWDM
same site, separate buildings
Storage
Storage
Data Center 1
Data Center 2
Metro Cluster not supported with 9i 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. 43km
• FC direct, ca. 500m
• FC switches, ca. 10km
• FC switches plus ultra long haul
GBIC
ca. 80km
• DWDM, ca. 100km
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 9i RAC
• Separate Cluster
• Locate data centers at economically
and/or strategically best locations
• “Push-button” failover across 1000s
of km
• Distances
•Unlimited distance between data
centers!
RAC
RAC
Node A
Node A
Node B
Node B
WAN
XP/EMC
XP/EMC
different cities, different countries
Data Center 1
Data Center 2
Oracle DataGuard supported with 9i RAC
• RAC cluster in one data center
• Changes get propagated to second data center
with Oracle DataGuard
(formerly Automated Standby
Database)
•Distances
RAC
Node A
Node B
Oracle
DataGuard Node C
• no limitation for Oracle DataGuard
Storage
Storage
disaster tolarant
Data Center 1
Data Center 2
Standby Database History 정리
•
Oracle Version 7.3 custom Standby Databases
–
•
Oracle8i Automated Standby
–
–
•
–
Automation: Single command switchover and failover
OPS and OFS support
Oracle9i Data Guard
–
–
•
Read only databases, Managed recovery
Remote archiving
Oracle8i Data Guard
–
•
Current Log 반영 불가(Only transferred arch. files)
Built in zero Data Loss capability (Current log 반영)
GUI interface integrated with OEM
Oracle9i R2 Data Guard
–
–
–
Oracle9i 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
page 27
Client Side Load Balancing
•
Clients connect to instance using random method (uses
address list in tnsnames.ora)
Node 1
Client 1
Client 2
lsnr1
rac1
instance
Client 3
Node 2
Client n
lsnr2
9iRAC
Database
rac2
instance
page 28
Listener Load Balancing
•
Listeners balance load using CPU/user load
Node 1
Client 1
Client 2
lsnr1
rac1
instance
Client 3
Node 2
Client n
lsnr2
9iRAC
Database
rac2
instance
page 29
Listener Load Balancing
•
Listeners balance load using CPU/user load
Node 1
Client 1
Client 2
lsnr1
rac1
instance
Client 3
Node 2
Client n
lsnr2
9iRAC
Database
rac2
instance
page 30
Connect Time Failover
•
Automatically retries the connection (uses the next entry in
the address list in tnsnames.ora)
Node 1
Client
lsnr1
rac1
instance
TNS
Node 2
lsnr2
9iRAC
Database
rac2
instance
page 31
TAF, Overview
•
Oracle9i 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
page 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
page 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
page 34
TAF Select Failover
•
•
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
7698Partially
Blake
Rows
Returned
When Failover Occurred
empno
Instance 1
Instance 2
name
7369
Smith
7499
Allen
Continues
7521 Returning
Ward
Remaining
Rows
from here
7566
Jones
7654
Martin
7698
Blake
DB
page 35