Versions Compared

Version Old Version 16 New Version 17
Changes made by

Former user

Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Enterprise Edition은, 빠른 입력 속도와 표준 SQL로 조회가 가능한 MachBase Standard Fog Edition 으로도 처리할 수 없는 초대용량의 데이터 입력/조회를 분산 환경에서 처리할 수 있는 제품이다.


용어

Host

물리적인 서버 1대, 또는 클라우드/VM 에서의 OS 인스턴스 1대를 나타낸다.


Node

서버에 상주하는 MACHBASE Process 를 나타낸다.

Process 타입은 아래의 Node Type 과 동일하다.

  • Coordinator
  • Deployer
  • Broker
  • Warehouse



Ui text box

목차

Table of Contents
maxLevel3
indent30px
exclude목차
classtoc




구조

Machbase Enterprise Edition 은, Host 에 상주하는 여러 Node 가 하나의 클러스터를 구성한다.

Node의 분류

각 Node는 다음과 같이 분류할 수 있다.

분류설명프로세스 이름
Coordinator모든 범용 서버와 Node를 관리하는 프로세스.machcoordinatord
Deployer

Host 마다 하나씩

생성하는

상주하는 프로세스.

Broker/Warehouse 의 설치와 업그레이드, 상태 관찰을 담당한다.

machdeployerd
Broker

실제 클라이언트 프로그램을 맞이하는 프로세스.

클라이언트의 데이터 입력/데이터 조회 쿼리를 Warehouse 에 분산 수행시키는 역할을 한다.

machbased
LeaderDDL 수행이 가능한 Broker
Warehouse

실제 데이터를 저장하고 있는 프로세스.

전체 클러스터 데이터 중 일부를 저장하고 있으며, Broker 로부터 전달받은 명령을 수행한다.

machbased

Special Node : Deployer

Coordinator에 의해 관리되지만, 단순히 Broker/Warehouse Node의 설치/제거를 담당하는 Process 이다.
보통은 Node 를 설치할 Host 에 1대씩 추가하지만, 설치 성능을 위해 여러 Deployer를 추가할 수도 있다.

Ui text box
typetip

서버에서 설치 예제

아래 그림(a)는, 범용 서버 4대에 2개의 Coordinator, 2개의 Broker, 4개의 Warehouse Active, 4개의 Warehouse Standby Node를 설치한 것을 나타낸 것이다.
그림 처럼, 범용 서버의 호스트 이름과 할당된 포트 번호가 이어진 'hostname:port' 로 각 Node를 구분할 수 있다.


Node의 Port 관리

각 Node는 Port를 여러 개 열어두고 있어야 하는데, 다음과 같이 구분된다.

Port 구분설명필요한 Node
Cluster PortNode 간 통신을 위한 Port모든 Node
Service Port클라이언트가 직접 접속하게 되는 PortBroker / Warehouse
Admin Port관리 목적으로 통신하기 위한 PortCoordinator / Deployer
Replication Port

Warehouse 간에 Replication 용 통신을 위한 Port

Warehouse


Broker / Warehouse 소개

Broker / Warehouse 는 모두 machbased 프로세스이지만, 역할에 따라 수행하는 작업이 다르다.

Broker

 Broker는 말 그대로 Client의 명령을 Warehouse에게 전달하고, Warehouse의 결과를 Client에 모아서 전달하는 역할을 한다.

  • 데이터 입력 시, Broker는 Warehouse에게 데이터 입력을 골고루 가도록 한다.
  • 데이터 조회 시, Broker는 Warehouse에게 데이터를 가져오도록 한 뒤에 모든 결과를 모아서 전달한다.

Broker는 Log Table의 데이터를 가지고 있지 않지만, Volatile Table의 데이터는 가지고 있는다.

Ui text box
sizemedium
typeinfo

Leader Broker

모든 Broker가 동시에 DDL을 수행하면 클러스터 전체 정합성에 문제가 생긴다.
이를 해결하기 위해 클러스터 차원에서 DDL 명령을 제어하기 시작하면, DDL 자체에 대한 성능 저하가 발생한다.

따라서 DDL을 수행할 수 있는 Broker를 지정해야만 했는데, 이를 Leader Broker 라고 한다.
Leader Broker는 DDL 수행이 가능하지만, 그 외의 Broker는 DDL 수행이 불가능하다.

Warehouse

Warehouse 는 Log Table 데이터를 직접 저장하게 되고, Broker가 전달한 명령을 실제로 수행하는 역할을 한다.

Broker 처럼 Warehouse 에도 직접 클라이언트 접속이 가능하지만, 데이터 입력/갱신/삭제는 할 수 없고 오로지 해당 Warehouse 데이터 조회만 가능하다.

Ui text box
sizemedium
typeinfo

Warehouse Group

Warehouse 는, 자신이 속할 Group 을 지정할 수 있다.

  • Broker 가 데이터를 입력할 때, 같은 Group 에 있는 모든 Warehouse는 동일한 레코드를 입력받는다.
  • Group 의 특정 Warehouse 가 탈락하더라도, 데이터 조회는 이상 없다.
  • Group 에 새로운 Warehouse 가 추가되면, 이중화 (Replication) 를 통해 동일한 레코드를 유지한다.

Warehouse Group 의 상태

상태INSERT / APPENDSELECT
NormalOO
ReadonlyXO

Readonly 상태로 변하는 조건은 다음과 같다.

  • INSERT/APPEND 도중, Group 의 일부 Warehouse 가 입력에 실패하는 경우
    • 실패한 Warehouse 와 성공한 Warehouse 간의 데이터 불일치가 발생했기 때문에,
      실패한 Warehouse 는 Scrapped 상태로 만들고 해당 Group 은 더 이상의 입력을 받지 않기 위해 Readonly 상태로 전환된다. (warning)
  • 새로운 Warehouse 가 추가된 경우
    • 이중화 과정이 진행되는 동안에도 입력을 받게 되면, 이중화 끝을 알 수 없기 때문에 Readonly 상태로 전환된다. (warning)


Ui text box
sizemedium
typetip

직접 접속 후, 수행 가능한 명령

다음은 각 Node에 직접 접속해서, 명령 수행이 가능한 것과 불가능한 것을 표로 나타낸 것이다.
모든 Node는 Client 를 통한 접속이 가능하지만, Node 종류에 따라 불가능한 쿼리가 존재한다.


Broker (Leader)Broker (non-leader)Warehouse Standby
Client 접속OOO
DDLOXX
DELETEOOX
INSERTOOX 1)
APPENDOOX 1)
SELECTOOO


Ui text box
sizemedium
typewarning

1) CLUSTER_WAREOUSEWAREHOUSE_DIRECT_DML_ENABLE Property 를 변경하고 Warehouse 를 재부팅하면 가능하지만, 해당 Group 의 데이터 불일치가 발생한다.




이중화

이중화란, 기존에 설치된 Node 의 실패를 대비해 똑같은 Node 를 복제하는 과정 또는 그 상태를 의미한다.

Coordinator Replication

Enterprise Edition 에서 Coordinator는 최대 2개까지 생성이 가능하다.
2개 중 하나는 Primary Coordinator, 다른 하나는 Secondary Coordinator 가 된다.

두 Coordinator는 지속적으로 Cluster Node 정보를 계속 유지한다.
어느 한 쪽이 비정상적으로 종료되더라도, 나머지 Coordinator가 Cluster Node 관리를 계속 할 수 있다.

Ui text box
typewarning
Primary Coordinator 가 재시작되는 경우, 의도치 않은 상황이 발생하므로, 주의가 필요하다. (현재 해당 부분에 대한 패치가 진행 중이다.)

Secondary Coordinator 가 재시작되는 경우, Primary Coordinator 의 최신 정보를 받을 수 있다.


Broker Replication

Broker는 Replication 대상이 아니다.

따라서 Broker A에 들어있는 Volatile Table의 데이터 레코드는 Broker B에 똑같이 유지되지 않는다. (not synchronized)
다만, Cluster 전체의 테이블/인덱스 스키마는 모두 동일하므로, Broker A에 Volatile Table VOL_TBL1 이 존재하면 Broker B에도 Volatile Table VOL_TBL1 이 존재한다.

Warehouse Replication

Group 에 새로운 Warehouse 가 추가되는 경우, 다음 과정을 통해서 Warehouse 가 이중화된다.

Ui steps
sizesmall


Ui step

Coordinator 가, 새로운 Warehouse 에게 DDL 이중화를 시작한다.


Ui step

Group 이 Readonly 상태로 전환된다.


Ui step

Group 중 1개의 Warehouse 가, 새로운 Warehouse 에게 데이터 이중화를 시작한다.


Ui step

데이터 이중화가 끝나면 Group 은 Normal 상태로 전환된다.


데이터 입력의 경우, Broker 가 같은 Group 에는 같은 데이터를 전송함으로써 이중화를 보장한다.



복구 방법

Node가 비정상적으로 종료되어도, 아래와 같은 방법으로 서비스를 계속할 수 있다.

자세한 내용은 운영 가이드를 참고한다.

종류Fail-over 방법
Coordinator

Primary Coordinator가 비정상 종료되어도, Secondary Coordinator 가 Primary Coordinator가 되면서 클러스터 관리를 계속 할 수 있다.

최악의 상황으로 Coordinator가 모두 종료되어도, 클러스터 관리를 할 수 없을 뿐 전체 서비스 (데이터 입력/조회) 는 계속 할 수 있다.
(물론, 이 때 Broker나 Warehouse가 종료되면 클러스터 관리를 할 수 없다.)

Deployer해당 Host 로 Node Operation (ADD, REMOVE..) 을 할 수 없고, 해당 Host 의 통계 정보를 수집할 수 없다.
Broker

Broker가 종료되어도, 다른 Broker가 존재한다면 계속 서비스를 지속할 수 있다.
단, 종료된 Broker와 연결된 클라이언트의 접속은 끊어지기 때문에 다른 Broker로 재접속해야 한다.

만약 Leader Broker가 중단되면, Coordinator가 Broker 중에서 Leader Broker를 다시 선출해서 DDL 수행을 가능하게 한다.

Ui text box
typenote

Broker 에 저장된 Lookup Table 데이터는 이중화되지 않으므로, 주의해야 한다.


Warehouse

Group 에 다른 Warehouse(s) 가 존재하면, 해당 Warehouse(s) 가 SELECT 와 APPEND 를 그대로 참여한다.