Db2 OLTP 아키텍처 구성

안녕하세요. 오늘은 OLTP 업무 환경의 아키텍처 구성에 대해 알아보겠습니다. 

업무 확장성, 복구 신속성(RTO), 투자비용, 관리용이성등 종합적인 요건을 고려하여 선택하면 됩니다. 

모든 아키텍처에 대해 Db2는 장애 시 복구를 위한 클러스터 모듈을 번들로 제공하고 있으므로, 추가 비용 없이 간단한 명령어로 손쉽게 이중화 구성이 가능합니다. 

구분	Active-standby	Mutual Takeover	HADR	pureScale
특징	•일반 Active-standby 구성 •공유 스토리지 •복구시간 : 5분 이내(TSA)	•Mutual Active-standby 구성 •공유 스토리지 •복구시간 : 5분 이내(TSA)	bctive-standby 구성 •비 공유 스토리지 •복구시간 : 1분 이내	•Active-active 구성 •공유 스토리지 •노드(업무) 확장성 지원
구성
장점	• 운영 단순 • S/W 라이선스 비용 절감	• 워크로드 분산으로 자원 활용성 증가 • 장애 시 부분적인 영향으로 가용성 개선	• 빠른 장애 복구 • 스토리지 이중화로 가용성 추가 확보 • Standby 조회 가능	• 가장 빠른 장애 복구 • Zero down time • HADR 조합 구성 가능 • 최대 128노드
단점	• H/W 자원 낭비 • 장애 시 전체 서비스 영향 가능	• Active-standby 대비 추가 S/W 비용 (DBMS, 모니터링, 보안, 백업 등)	• 관리 복잡성 • 추가 인프라 비용 -스토리지 -클러스터용 네트웍 (1GE TCP/IP)	• 관리 복잡성 • 추가 인프라 비용 -2개 CF용 cores(30~40%) -2개 CF용 Memory(80~100%) -클러스터용 네트웍 (10G 이상 RoCE or TCPIP)
라이센스	• active 서버 core수	•두 서버의 합산 Core수	•active서버 core수 + 1 core	양 서버의 모든 core 수
클러스터 모듈	Linux : TSA, Pacemaker Power : TSA	Linux : TSA, Pacemaker Power : TSA	Linux : TSA, Pacemaker Power : TSA	Linux : TSA Power : TSA

※ 최근에 연구소에서는 번들 클러스터에 TSA를 대신하여 Pace Maker로 전환 작업을 진행중입니다.  

미래버전에서 TSA는 지원되지 않을 것이므로 PaceMaker를 사용하는 것이 바람직합니다. 

 

이상으로 OLTP 환경에 아키텍처 구성에 대해 살펴보았습니다.  좋은 하루되세요. ~