Tibero DB구성 (HA, TAC, TAS, TSC, TBCM..)

티베로 DB 구성

 

Single Instance 

 - 기본적인 구조로서 하나의 서버에 하나의 DB Instance를 이루는 구조이다.

 

Multi Instance

 

하나의 서버에 두개 이상의 독립적인 DB Instance를 이루는 구조이다.

제한된 자원으로 여러 서비스를 운영하고자 할 때 구성하고, 이 경우에는 OS 유저를 분리하여 각각의 유저에서 Instance를 기동하는 것을 권고한다.

 

SID : tibero  - Instance #1

SID : tibero2 - Instance #2

---

 

HA 구성 (Active - Standby)

HA라 하는 것은 (High Avaliability) 으로 고가용성을 뜻한다.

평시 싱글 인스턴스와 동일한 구성으로 운영된다. 운영 서버에 이상 발생 시 Stnad-by 서버로 Fail-over 되는 구조로서 서버 장애시의 가용성을 보장한다.

 

일반적인 HA는 노드간 Active - Standby로 구성되어 서로의 서비스를 체크하고 공유한다. 서비스의 양호성은 서버에서 제공하는 HA 모니터링 툴을 이용하는 것이 일반적이라고 할 수 있다. 

하나의 노드가 장애가 나면 해당 노드의 사용자 세션은 소실되고 Standby 노드가 기동되는 시간 만큼의 다운타임이 발생한다.

싱글 인스턴스 구성 대비 추가로 한 개의 서버와 공유 볼륨, 클러스터 웨어가 필요하다.

HA는 두가지 방식이 있다.

 

1. Disk 절체 방식 

- 디스크를 양쪽 노드에서  접근이 가능한 것을 의미한다.
- 양쪽노드에 데몬이 떠 있으면 데몬이 계속 모니터링을 한다. 

   Active가 죽은 것을 모니터링 하게 되면 Active에서는 Disk 접근 불가하게 만들며 Standby에서 접근이 가능하도록 하는데 이것을 절체방식이라고 한다. (평소에는 Standby 에서 접근이 되지 않는다)

   ㄴ-> Stanby 에서 ReadWrite가 안되는 것은 데몬으로(소프트웨어적으로) 막은 것이다.

 

- 절체방식을 사용하려면 공유 Disk로 구성이 되어야 한다.

2. Disk Mirror 방식
- Active와 Standby 구성이 있고 각각의 디스크가 따로 구성이 되어있다. 
  Standby에서는 Read,Write가 불가하다. (DB Node에서 접근 불가를 말한다)
  
- Active가 장애났을때, Disk 블록 변경 분을 반영 완료하게 되면 Standby에서 Disk에 Read,Write가능
- 다시 원복시 Standby(2번 노드)의 Disk블록 변경 분을 다시 1번 노드로 미러시킴

- 솔루션을 연결시키는 분한테는 Datafile(DF,LOG,controlfile,.passwd,archivelog file)
  DB 엔진,tip파일 등을 알려줘야한다.
  
- Mirror 솔루션 이름
  1. MCCS
  2. LifeKeeper
  3rd Party 연동 현황에 있을 것~ (Tims 영업정보)   

구성 목적
- 장애 발생시 다운타임 최소화
- DR 구성 
Disaster Recovery 구성이라고 하며 데이터 센터의 위치를 서울-서울이 아닌 서울 - 대구 식으로한다

---

 

TAC (Tibero Active Cluster) 구성 (Active - Active)

 

하나의 DB에 두 개 이상의 독립적인 인스턴스를 기동하여 업무 및 부하의 분산과 가용성을 모두 확보할 수 있는 구조임.

(오라클의 RAC 기능과 매칭된다)

공유 스토리지가 필요하고 양 노드에서 공유 스토리지에 동시 접근이 가능하게끔 셋팅이 필요하다.

TAC 환경에서 실행 중인 모든 인스턴스는 공유된 데이터베이스를 통해 트랜잭션을 수행하고 데이터의 일관성 / 정합성 유지를 위하여 상호 통제하에 이루어진다. 

(이 부분을 클러스터웨어가 역할을 하기도 하지만, Linux 경우 스토리지 파라미터 세팅으로 가능하다)

Gigabit 이상의 인터커넥트가 필요하고 L2 스위치가 권고된다

TAC는 공유 디스크 기반의 클러스터 데이터베이스이다. 여러 데이터베이스 서버의 인스턴스가 물리적으로 같은 데이터베이스 파일을 보고 사용하기 때문에 데이터베이스 생성은 한 서버에서 한번만 수행하면 된다.

 '모든 서버의 인스턴스가 동일한 컨트롤 파일 및 데이터 파일' 을 읽고 쓰게 된다.

TAC에서는 공유 디스크에서 데이터 접근의 경합을 최소화하기 위해 Redo 로그 및 Undo에 대해서는 인스턴스마다 별도의 파일을 가지고 있어야 한다. Redo 로그 및 Undo 정보는 각 서버의 인스턴스들이 별도의 파일에 저장하지만 복구 상황 등에 따라 다른 인스턴스의 정보를 읽어야 하므로 반드시 공유 디스크상에 존재해야 한다.

 

구분	HA	TAC	비고
구성방식	2개 노드 Active - Standby	2개노드 Active - Active	TAC의 경우 추가 노드 구성 가능
스토리지 구성	일반 File System 사용	RAW 디바이스  (File System 구성시 GPFS 도입 필요)
Data 파일관리	여유공간 범위에서 지정한 크기의 Data 파일 생성가능 관리자가 Tablespace Datafile 이름 지정가능	사전 설정한 Raw 디바이스 크기만큼 Data 파일 생성  Raw 디바이스 별 Tablespace 파일 매칭 필요
장애 발생	장애 발생 Standby 전환 시 Down Time 발생 Standby서버 서비스 전환시 기동 오류 발생 가능성	장애시 서비스 영향 없음 Down Time 발생 최소
Data 복구시	Full Backup + Archive File 복구	Full backup + Archive File 복구	복구시간 차이 없음

 

 

 

---

 

TAS (스토리지 가상화 기술 지원) = Oracle ASM

스토리지 가상화란, 스토리지와 서버 사이에 소프트웨어 또는 하드웨어 계층을 추가함으로써 DBMS 구동 시 데이터를 찾기 위해 특정 디스크 드라이브, 파티션 또는 스토리지 하위 시스템을 인식하지 않아도 스토리지가 서로 독립적으로 관리될 수 있도록 하는 기술이다. 

 

1. TAS를 통해 여러개의 스토리지 들을 논리적인 하나의 데이터 볼륨으로 가상화 하고 DBMS는 이를 통합된 단일 데이터 저장소로 인식한다.

 

2. TAS는 TAC와는 별도의 계층에 위치해 스토리지 클러스터를 구성하고 별도의 외부 솔루션 없이 직접 디스크 장치를 관리하여 티베로 운영에 필요한 데이터 파일, 로그 파일 등을 저장하기 위한 논리적 볼륨 관리자이다.

또한, 공유 디스크클  사용할 경우 TAC기능을 사용할 수 있도록 클러스터링 기능을 제공한다.

 

3. TAS는 여러개의 디스크들을 디스크 스페이스로 관리한다. 디스크 스페이스는 논리 볼륨 위에 파일시스템을 생성한 것과 유사하다. 디스크 스페이스를 사용해 티베로 운영 중 데이터베이스를 종료하지 않아도 디스크를 추가 / 제거 할 수 있다.

디스크를 추가 / 제거 하게 될 경우 TAS는 자동으로 디스크 스페이스에 있는 모든 디스크의 데이터를 균등하게 배분하는 Rebalancing(재배치) 기능을 제공한다.

 

4. TAS는 미러링과 스트라이핑 기능을 통해서 디스크 공간을 관리할 수 있다.

스트라이핑 : 디스크 간 병렬 처리로 최대한 성능을 낼 수 있도록 분산 저장

미러링 : 티베로 데이터를 복제저장 (2-Way Or 3-Way) 하여 스토리지에 대한 고가용성을 유지할 수 있음.

 

 

OS File System 을 이용하지 않는 Raw Device나 파티셔닝이 되지 않은 Disk 에도 구성이 가능함.

 

* 파일 시스템

  컴퓨터에서 파일이나 자료를 쉽게 발견할 수 있도록 유지, 관리하는 방법이다.

  저장매체에는 많은 파일이 있으므로 이러한 파일을 관리하는 방법을 말한다.

 

* 물리 볼륨

  1. 논리 볼륨을 구성하기 위한 가장 기본적인 단계

  2. 디스크 전체 또는 일부를 파티션으로 지정하고 그 파티션으로 물리 볼륨을 생성한다.

 

* 논리 볼륨

  1. 파일시스템에서 데이터를 저장할 수 있는 볼륨을 생성하는 단계

  2. 논리 볼륨을 생성할 때 이름, 사이즈, 볼륨 그룹을 지정한다.

 

* 논리 볼륨 관리자 (Logical Volume Manager) 

   우리가 사용하는 물리적인 (하드)디스크 ex) hda, sda 등 여러개를 논리적인 디스크로 할당하여 유연하게 관리할 수 있게 해준다.

   물리적인 디스크를 논리적 볼륨 그룹으로 구성하여 이 논리적인 볼륨그룹 내에 사용자가 원하는 크기만큼 논리볼륨을 할당하여 사용하는 방식이다.

 

---

TSC (Tibero Standby Cluster)

데이터베이스의 고가용성, 데이터의 보호, 재난 복구 등을 목적으로 제공하는 Tibero의 핵심 기능이다. 

Tibero Standby 서버는 물리적으로 독립된 장소에 원본 데이터베이스의 복사본을 트랜잭션 단위로 보관.

복사할 대상이 되는 DB = Primary DB라 하고 / 복사된 데이터가 저장되는 DB= Standby DB 라고 한다.

 

TSC는 Primary에서 생성된 Redo  로그를 배경 프로세스가 Standby로 전송, Standby는 Redo로그를 이용해 Primary의 모든 변화를 똑같이 반영하는 것임.

 

* 어떻게 보면 HA와 비슷할 수 있는데 이것은 DB자체가 서로 독립적인 것임. *

 

 

 

TSC 동작구조

 

Tibero Standby Cluster의 동작 원리는 Primary DB에서 생성된 Redo 로그를 백그라운드 프로세스가 Standby DB들에게 전송하고, Standby DB 들은 이 Redo 로그를 이용해 Primary DB의 모든 변화를 똑같이 적용하도록 구성된다.

 

데이터의 복사를 통해 Primary DB는 서비스가 요청한 데이터 처리에 실패했을 경우 Standby DB의 데이터를 활용해 해당 서비스를 신속히 재개할 수 있다. 또한 Primary DB의 서버만으로는 손상된 데이터를 복구할 수 없는 경우에도 쉽게 대처할 수 있다. 예를 들면  Primary DB의 서버의 디스크가 손상된 경우 Stanby DB를 통해 손상된 데이터를 보호할 수 있음

 

TSC가 어떻게 동작하는지를 나타내는 그림

 

 

Primary(TAC1 - TAC2) ---- (TSC) --->> Standby (TAC1 - TAC2)

 

TAC - TSC 구성 가이드 https://m.blog.naver.com/rapisne7/222013475829 

TAC-TSC 구성 가이드 1- tbrmgr backup

---

 

TBCM (Tibero Cluster Manager)

TBCM은 클러스터의 가용성을 높이고 관리의 편의를 지원하는 Tibero의 부가기능이다.

 

TBCM은 클러스터에 속한 전체 노드의 Tibero 서버의 동작 상태를 지속적으로 파악한다.

구체적으로 클러스터를 구성하는 TBCM의 노드들은 네트워크 또는 공유디스크를 통해 주기적으로 자신이 살아 있음을 알리는 heartbeat 메시지를 서로 주고 받으면서 주변 노드들의 상태를 파악한다. 

클러스터의 특정 노드에서 동작하고 있는 Tibero 서버가 비정상적인 경우 TBCM이 감지하여 클러스터의 멤버십 구성을 자동으로 변경한다.

전체 클러스터의 서비스가 중단되지 않도록 하기 위해서 이다.

 

TBCM 멤버십(Membership)은 지정된 클러스터 파일을 통해 자동으로 관리된다.

클러스터 구성에서 최초로 실행된 TBCM 데몬은 마스터 역할을 수행하며 클러스터 멤버십 구성을 관리.

TBCM은 Tibero와 환경변수 및 환경설정 파일을 공유

TB_HOME, TB_SID 환경변수를 설정하고 TBCM을 사용하기위한 초기화 파라미터를 TB_SID.tip 파일에 설정해야함.