Split Brain 은 Clustering 또는 다중 노드/스토리지 구성의 각종 솔루션들(주로 고가용성과 부하분산, 즉 HA 용도), 예를 들어 Redis-Sentinel, MariaDB Galera Cluster, GlusterFS 파일 분산복제 설정, Oracle RAC, vSphere HA 구성 등에서 중요한 장애 유발 요인이며, Production 환경에서 점검해야 할 중요한 아키텍처적 회피 대상 항목에 해당한다.




1. Split Brain 이 도대체 무엇일까?


문자 그대로 "뇌가 양쪽으로 분단 된" 모양 또는 상황 그자체를 표현한다. IT와 무관한 비유를 해 보자면, 머리 둘 달린 용이 왼쪽으로 갈지 오른쪽으로 갈지 몰라서 갈팡질팡하는 형국이라고 할 수도 있겠다. 실제로 인간의 뇌는 좌뇌와 우뇌로 구성되는데, 양쪽 뇌를 연결해주는 '뇌량'을 절단해 버리면 왼쪽 뇌와 오른쪽 뇌의 인지 부조화와 같은 심각한 부작용이 나타난다고 알려져 있다.


이번 글에서는 MySQL 호환 데이터베이스 클러스터링 솔루션인 MariaDB Galera Cluster 의 기본 3대 구성에서 장애/점검 등을 이유로 1 대가 빠진 상태를 구체적인 예를 들어 설명해 보도록 한다. 3대 구성이 기본인 이유는, Leader 의 선출(투표에 의한)시 과반수 이상의 득표가 가능한 구조여야 하기 때문이다. 즉 3명(Quorom[각주:1]=3)이 투표에 참여하여 2 이상의 득표자가 Leader가 되는 경우를 생각해 보면 되겠다.   



위의 첫 번 째 그림은 전형적인 Split Brain 의 가능성이 내재된 상황을 표현하고 있다. 그렇다면 이 상황에서 100% Split Brain 이 발생한다고 단정할 수 있는가 하면 그건 아니다. 즉 물리적인 연결 구성과 함께 Network Topology를 보고 판단해야 하기 때문이다. 다음 그림을 보자.



만약 처음에 보았던 논리적 Diagram의 실제 네트워크 구성이 이 그림과 같이 단일 네트워크로 이루어져 있고 DB Client(또는 WAS)에서 Load Balancer를 거쳐서 Galera-1, Galera-2 로 접속이 되는 방식이라면, Split Brain은 발생하지 않는다. 따라서 Galera-1 서버가 다운되거나 네트워크 접속이 끊기면, DB Client는 정상적으로 Galera-2 로 접속되고 Galera-2는 자신을 DB Master로 인식하여 정상 작동을 하게 된다. 위의 구성도를 Topology로 표현하면 아래의 그림과 유사한 모양이 된다.




그렇다면 도대체 어떤 상황에서 Split Brain 이 발생할 수 있다는 말일까? 다음의 2개의 그림이 바로 그에 대한 답이 된다.



위의 네트워크 구성도에서, Galera-1과 Galera-2 사이의 데이터 복제 및 Alive-check는 Switch-2의 DB망을 통해서 이루어 지며, 실제 Production 환경에서의 전형적 네트워크 구성도의 예시를 들어 보자면 개략적으로 다음 그림과 같은 모습이 될 것이다.




위의 2가지 네트워크 구성도의 Topology를 그려 보면, 공통적으로 아래의 그림과 같이 나타난다. 이 상황에서 Galera-1, Galera-2 사이의 경로가 끊어지면, 바로 Split Brain 상황이 발생하게 되는데, DB Client 입장에서는 2개 DB 모두로의 접속 자체는 가능하지만, 데이터베이스 관련 각종 쿼리(use database, select, insert 문 등)가 실패 되는 현상이 발생하게 된다. 다시 전문용어를 써서 상세히 표현하자면, "네트워크의 부분적인 장애로 DB접속자(Client, WAS)에게는 2개의 DB 서버 모두 정상적으로 보이지만, 각 DB 서버는 상대방이 비정상이라고 판단하여 데이터 동기화 및 읽기 쓰기가 비정상 상태에 빠지는 것" 이라고 할 수 있으며, 다른 말로 Network Partition 또는 Cluster Partition 이라고도 한다.


위의 구성도를 Topology로 표현하면 아래의 그림과 유사한 모양이 된다.




2. 정상적 Cluster 구성상태의 점검/확인 방법


* MariaDB Galera Cluster 의 설치 과정은 다음 링크를 참고한다

☞ http://bryan.wiki/246


위의 섹션 1에서 Split-Brain 상황이 발생한 구조와 같이 2대의 MariaDB를 사용하는 경우(3대 중 1대의 동작이 중지되어 2대가 남은 상태)와 동일한 구성을 갖추기 위해 다음의 2개 VM을 준비하고 /etc/my.cnf.d/server.cnf 내용을 각각 설정하여 정상적인 2대 구성의 Cluster 환경을 갖춘다. 



[maria1]

  • CentOS 7.3, MariaDB-server
  • NIC1(ens160): 192.168.30.105 - DB Client와 DB간 연결 네트워크
  • NIC2(ens192): 10.199.30.105 - DB간 연결 네트워크

#

# * Galera-related settings

#

[galera]

# Mandatory settings

wsrep_on=ON

wsrep_provider=/usr/lib64/galera/libgalera_smm.so

wsrep_cluster_address='gcomm://'

#wsrep_cluster_address='gcomm://10.199.30.105,10.199.30.106'

wsrep_cluster_name='galera'

wsrep_node_address='10.199.30.105'

wsrep_node_name='maria1'

wsrep_sst_method=rsync


binlog_format=row

default_storage_engine=InnoDB

innodb_autoinc_lock_mode=2

#

# Allow server to accept connections on all interfaces.

#

bind-address=0.0.0.0

#

# Optional setting

#wsrep_slave_threads=1

innodb_flush_log_at_trx_commit=2



[maria2]

  • CentOS 7.3, MariaDB-server
  • NIC1(ens160): 192.168.30.106 - DB Client와 DB간 연결 네트워크
  • NIC2(ens192): 10.199.30.106 - DB간 연결 네트워크

#

# * Galera-related settings

#

[galera]

# Mandatory settings

wsrep_on=ON

wsrep_provider=/usr/lib64/galera/libgalera_smm.so

wsrep_cluster_address='gcomm://10.199.30.105,10.199.30.106'

wsrep_cluster_name='galera'

wsrep_node_address='10.199.30.106'

wsrep_node_name='maria2'

wsrep_sst_method=rsync


binlog_format=row

default_storage_engine=InnoDB

innodb_autoinc_lock_mode=2

#

# Allow server to accept connections on all interfaces.

#

bind-address=0.0.0.0

#

# Optional setting

#wsrep_slave_threads=1

innodb_flush_log_at_trx_commit=2



Cluster의 정상적인 동작상황에서는 다음의 4가지 점검 사항을 확인해 보고, 필요 시 튜닝 또는 설정값 조정을 진행해야 한다.


1. Cluster Integrity Check

 Maria1

Maria2 

select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like 'wsrep_cluster_state_uuid' or VARIABLE_NAME like 'wsrep_cluster_conf_id' or VARIABLE_NAME like 'wsrep_cluster_size' or VARIABLE_NAME like 'wsrep_cluster_status';

+--------------------------+--------------------------------------+

| VARIABLE_NAME | VARIABLE_VALUE |

+--------------------------+--------------------------------------+

| WSREP_CLUSTER_CONF_ID | 2 |

| WSREP_CLUSTER_SIZE | 2 |

| WSREP_CLUSTER_STATE_UUID | b04a71b5-161b-11e7-b1e1-bbd969deabbb |

| WSREP_CLUSTER_STATUS | Primary |

+--------------------------+--------------------------------------+

select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like 'wsrep_cluster_state_uuid' or VARIABLE_NAME like 'wsrep_cluster_conf_id' or VARIABLE_NAME like 'wsrep_cluster_size' or VARIABLE_NAME like 'wsrep_cluster_status';

+--------------------------+--------------------------------------+

| VARIABLE_NAME | VARIABLE_VALUE |

+--------------------------+--------------------------------------+

| WSREP_CLUSTER_CONF_ID | 2 |

| WSREP_CLUSTER_SIZE | 2 |

| WSREP_CLUSTER_STATE_UUID | b04a71b5-161b-11e7-b1e1-bbd969deabbb |

| WSREP_CLUSTER_STATUS | Primary |

+--------------------------+--------------------------------------+

 수행결과 캡처

 


 항목별 점검/확인 포인트

  • WSREP_CLUSTER_STATE_UUID : 모든 노드에서 동일해야 함. 값이 다른 노드는 Cluster 에서 제외되었음을 의미
  • WSREP_CLUSTER_CONF_ID : 위와 같음. 단 Cluster가 단절되었다가 복구될 때마다 +1 씩 값이 증가함
  • WSREP_CLUSTER_SIZE : Cluster 내의 노드 갯수
  • WSREP_CLUSTER_STATUS : 모든 쓰기 가능한 노드는 Primary 이어야 함



2. Node Status Check

 Maria1

Maria2 

select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like 'wsrep_ready' or VARIABLE_NAME like 'wsrep_connected' or VARIABLE_NAME like 'wsrep_local_state_comment';

+---------------------------+----------------+

| VARIABLE_NAME | VARIABLE_VALUE |

+---------------------------+----------------+

| WSREP_CONNECTED | ON |

| WSREP_LOCAL_STATE_COMMENT | Synced |

| WSREP_READY | ON |

+---------------------------+----------------+

select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like 'wsrep_ready' or VARIABLE_NAME like 'wsrep_connected' or VARIABLE_NAME like 'wsrep_local_state_comment';

+---------------------------+----------------+

| VARIABLE_NAME | VARIABLE_VALUE |

+---------------------------+----------------+

| WSREP_CONNECTED | ON |

| WSREP_LOCAL_STATE_COMMENT | Synced |

| WSREP_READY | ON |

+---------------------------+----------------+

 수행결과 캡처

 


 항목별 점검/확인 포인트

  • WSREP_READY : true(ON) 이면 해당 노드는 SQL 처리가 가능한 상태
  • WSREP_CONNECTED : true(ON) 이면 정상, WSREP_LOCAL_STATE_COMMENT 값이 'Synced'.
  • false(OFF) 이면 해당 노드가 정상적으로 Cluster 에 참여하지 못한 상태로 WSREP_LOCAL_STATE_COMMENT 값을 참조해야 함
  • WSREP_LOCAL_STATE_COMMENT : 동기화 진행중이면 Joining/Waiting for SST/Joined 중 하나의 값




3. Replication Status  Check

 Maria1

Maria2 

select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like 'wsrep_flow_control_paused' or VARIABLE_NAME like 'wsrep_cert_deps_distance';

+---------------------------+----------------+

| VARIABLE_NAME | VARIABLE_VALUE |

+---------------------------+----------------+

| WSREP_CERT_DEPS_DISTANCE | 0.000000 |

| WSREP_FLOW_CONTROL_PAUSED | 0.000000 |

+---------------------------+----------------+

select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like 'wsrep_flow_control_paused' or VARIABLE_NAME like 'wsrep_cert_deps_distance';

+---------------------------+----------------+

| VARIABLE_NAME | VARIABLE_VALUE |

+---------------------------+----------------+

| WSREP_CERT_DEPS_DISTANCE | 0.000000 |

| WSREP_FLOW_CONTROL_PAUSED | 0.000000 |

+---------------------------+----------------+

 수행결과 캡처

 


 항목별 점검/확인 포인트

  • WSREP_FLOW_CONTROL_PAUSED : 마지막 상태점검 시간부터 현재까지의 전체 시간 중 Replication이 중지된 시간의 비율. 0에 가까울수록 Lag이 적음을 의미하고 1이면 완전 중지. DB의 전체적 성능이 저하되었다고 판단될 경우 Cluster 전체 노드 중, 이 값이 가장 큰 노드(Slave Lag이 커서 전체 성능에 영향을 줌)을 제거해야 함
  • WSREP_CERT_DEPS_DISTANCE : 병렬처리 가능한 트랜잭션 수. 튜닝시는 이 값보다 적당히 크게 wsrep_slave_threads 정수값을 설정할 수 있음




4. Slow Cluster  Check

 Maria1

Maria2 

select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like 'wsrep_flow_control_sent' or VARIABLE_NAME like 'wsrep_local_recv_queue_avg' or VARIABLE_NAME like 'wsrep_local_send_queue_avg';

+----------------------------+----------------+

| VARIABLE_NAME | VARIABLE_VALUE |

+----------------------------+----------------+

| WSREP_FLOW_CONTROL_SENT | 0 |

| WSREP_LOCAL_RECV_QUEUE_AVG | 0.000000 |

| WSREP_LOCAL_SEND_QUEUE_AVG | 0.000000 |

+----------------------------+----------------+

select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like 'wsrep_flow_control_sent' or VARIABLE_NAME like 'wsrep_local_recv_queue_avg' or VARIABLE_NAME like 'wsrep_local_send_queue_avg';

+----------------------------+----------------+

| VARIABLE_NAME | VARIABLE_VALUE |

+----------------------------+----------------+

| WSREP_FLOW_CONTROL_SENT | 0 |

| WSREP_LOCAL_RECV_QUEUE_AVG | 0.000000 |

| WSREP_LOCAL_SEND_QUEUE_AVG | 0.000000 |

+----------------------------+----------------+

 수행결과 캡처



 항목별 점검/확인 포인트

  • WSREP_FLOW_CONTROL_SENT : 이 값이 클수록 처리 성능이 낮음
  • WSREP_LOCAL_RECV_QUEUE_AVG : 이 값이 클수록 처리 성능이 낮음
  • WSREP_LOCAL_SEND_QUEUE_AVG : 이 값이 클수록 네트워크 링크의 속도가 낮음(OS, 네트워크의 물리 구성 등 여러가지 영향 분석 필요)


위의 1, 2번 항목 점검에 의해 maria1, maria2 두개의 노드는 정상적 Cluster 상태를 유지하고 있음을 확인할 수 있다.



3. Split Brain 상태의 유발, 복구 및 쿼리 실행 결과 확인


maria1과 maria2 사이의 DB간 네트워크를 단절시키는 장애 상황을 시뮬레이션하기 위해 2대 중 1대에서 ifdown ens192(또는 iptables -A INPUT -d 10.199.30.106 -s 10.199.30.105 -j REJECT)를 실행하고, 양 DB서버간 복제/동기화를 위한 접속이 불가능함을 확인한다. 


아래 화면캡처 중간 부분의 DB client 측 터미널 화면에서 maria1, maria2 양쪽 DB 서버 모두에게 DB 접속은 가능하지만 실제 DB query는 실패 됨을 확인할 수 있다.




장애 요인(DB간 네트워크 단절)을 제거하여(원상 복구된 상황),  각 DB 서버의 상태를 점검, 데이터 복제 여부를 확인한 결과는 다음과 같이 나타나게 된다.





- Barracuda -


  1. 쿼럼; 정족수, 즉 투표=vote 에 의한 의사결정이 이루어 지기 위한 최소한의 구성원 수. 클러스터링 개념에서는 과반수=majority 득표를 위한 노드 또는 참여자 수로, 일반적으로는 최소 3개가 되어야 한다. [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들

Gluster 파일시스템의 Geo-replication 환경을 구축하고 테스트 하는 과정을 정리해 보자. 작업 환경을 단순하게, 과정을 직관적으로 표현하기 위해 추가 디스크 없는 VM 2개만으로 모든 내용을 소화해 보기로 한다. 이를 위해 Linux 의 Sparse 파일을 가상 디스크로 매핑하여, 마치 추가 디스크가 장착된, 또는 별도 파티션 된 물리 디스크 볼륨이 있는 것처럼 흉내 내는 방법을 같이 다루어 보고자 한다(블록디바이스를 통한 비슷한 테스트를 진행해야 할 때 유용한 방법으로 써먹을 수 있을 것이다).



CentOS 7.2에 Gluster Filesystem 설치


먼저 위의 그림과 같이 네트워크가 연결된 2개의 가상머신을 준비한다(CentOS 7.2 또는 RHEL 7.2는 이미 설치되었다고 가정하자). Redhat 이나 CentOS의 경우 대개 EPEL 을 통해 Gluster 를 설치하게 된다.


* 주의: 2개의 서버 노드를 peer 로 연결하여 Cluster 에 투입하는 것은 아니며, 서로 독립된 Gluster 세트가 원격지에 각각 존재하는 경우에 대한 내용을 다룬다. 여러 peer 를 통하여 Brick을 구성하고 데이터가 분산(distributed) 또는 중복(replica)되는 Volume 구성에 대해서는 여기서 논외로 하자.


* 2개의 서버 각각에 다음과 같이 gluster 를 설치한다.

# yum install -y wget

# wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-8.noarch.rpm

# rpm -ivh epel-release-7-8.noarch.rpm

# yum install -y centos-release-gluster38.noarch

# yum install -y glusterfs-server

yum install -y glusterfs-geo-replication

# systemctl start glusterd

# systemctl enable glusterd


* RHEL 7 에서는 약간 과정이 다르다. 다음과 같이 해 보자.

# yum install -y wget

# wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-8.noarch.rpm

# rpm -ivh epel-release-7-8.noarch.rpm

# vi /etc/yum.repos.d/Gluster.repo

[gluster38]

name=Gluster 3.8

baseurl=http://mirror.centos.org/centos/7/storage/$basearch/gluster-3.8/

gpgcheck=0

enabled=1

# yum install -y glusterfs-server

# yum install -y glusterfs-geo-replication

# systemctl start glusterd

# systemctl enable glusterd


* 커맨드를 단순하게 하기 위해 /etc/hosts 파일에 다음의 2 라인을 추가

10.10.10.10 gnode1

10.10.10.11 gnode2


* 호스트 명을 각각 gnode1, gnode 로 변경하고 재접속

hostnamectl set-hostname gnode1



준비1: 데이터를 동기화할 가상 블록디바이스 장착

서두에서 말한 것처럼 Sparse 파일(1 GByte 짜리 ^^;;)을 만들어 가상디스크로 붙이고, 이를 데이터 동기화용 블록디바이스로 활용할 것이다. VM 2개에 각각 다음과 같이 작업한다.


* losetup -f 로 Sparse 이미지 파일을 LO 디바이스에 매핑하면, 자동으로 다음의 빈 LO 디바이스(아래의 경우, /dev/loop2)가 찾아져서 매핑됨

* 블록디바이스가 준비되었으므로 xfs 로 파일시스템을 포맷하고 마운트포인트를 /mnt/gnode_disk1 디렉토리로 하여 시스템에 마운트하면 준비 끝

[root@gnode1 ~]# mkdir gluster_disk

[root@gnode1 ~]# cd gluster_disk/

[root@gnode1 ~]# dd if=/dev/zero of=./disk1.img bs=1M count=1024

[root@gnode1 ~]# losetup -f /root/gluster_disk/disk1.img

[root@gnode1 ~]# losetup

NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE

...

/dev/loop2         0      0         0  0 /root/gluster_disk/disk1.img 

[root@gnode1 ~]# mkfs.xfs /dev/loop2

[root@gnode1 ~]# mkdir /mnt/gnode_disk1

[root@gnode1 ~]# mount /dev/loop2 /mnt/gnode_disk1/



준비2: Password-less 로그인 설정

Geo-replication 이 가능하게 하기 위해서는, 2개의 서버에서 각각 상대방 서버로 패스워드 없이 root 계정으로 접속할 수 있도록 ssh 키를 교환해 두어야 한다. 다음과 같이 진행하자.


* Password-less ssh 접속을 위한 키 교환. 상대방 서버에 ssh 접속하고 암호를 입력해 두면 다음에는 암호 없이 로그인 가능

[root@gnode1 ~]# ssh-keygen 

[root@gnode1 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.10.10.11

[root@gnode1 ~]# ssh gnode2



Gluster Volume 생성 및 기동

각각의 Gluster 서버에서 다음과 같이 Volume 을 생성하고 기동한다. 


* 주의: 마운트포인트 아래에 서브디렉토리를 생성하여 볼륨(여기서는 distvol)에 할당해야 함

[root@gnode1 ~]# mkdir -p /mnt/gnode_disk1/brick

[root@gnode1 ~]# gluster volume create distvol gnode1:/mnt/gnode_disk1/brick

[root@gnode1 ~]# gluster volume start distvol

[root@gnode1 ~]# gluster volume info

Volume Name: distvol

Type: Distribute

Volume ID: 9754b79a-d0e7-4823-9e85-38340d99e732

Status: Started

Snapshot Count: 0

Number of Bricks: 1

Transport-type: tcp

Bricks:

Brick1: gnode1:/mnt/gnode_disk1/brick

Options Reconfigured:

nfs.disable: on

performance.readdir-ahead: on

transport.address-family: inet


[root@gnode2 ~]# mkdir -p /mnt/gnode_disk1/brick

[root@gnode2 ~]# gluster volume create distvol gnode2:/mnt/gnode_disk1/brick

[root@gnode2 ~]# gluster volume start distvol

[root@gnode2 ~]# gluster volume info

Volume Name: distvol

Type: Distribute

Volume ID: e12db607-2e19-4a45-bc3b-eb6e922f59e5

Status: Started

Snapshot Count: 0

Number of Bricks: 1

Transport-type: tcp

Bricks:

Brick1: gnode2:/mnt/gnode_disk1/brick

Options Reconfigured:

nfs.disable: on

performance.readdir-ahead: on

transport.address-family: inet



Geo-replication 설정 및 테스트

* Geo-replication 설정은 Master(여기서는 gnode1) 에서만 수행

[root@gnode1 ~]# gluster system:: execute gsec_create

[root@gnode1 ~]# gluster volume geo-replication distvol gnode2::distvol create push-pem

[root@gnode1 ~]# gluster volume geo-replication distvol gnode2::distvol start

[root@gnode1 ~]# gluster volume geo-replication distvol gnode2::distvol status

MASTER NODE    MASTER VOL    MASTER BRICK              SLAVE USER    SLAVE              SLAVE NODE    STATUS    CRAWL STATUS       LAST_SYNCED                  

-----------------------------------------------------------------------------------------------------------------------------------------------------

gnode1         distvol       /mnt/gnode_disk1/brick    root          gnode2::distvol    gnode2        Active    Changelog Crawl    2016-10-10 01:10:04

[root@gnode1 ~]# gluster volume info distvol

Volume Name: distvol

Type: Distribute

Volume ID: 9754b79a-d0e7-4823-9e85-38340d99e732

Status: Started

Snapshot Count: 0

Number of Bricks: 1

Transport-type: tcp

Bricks:

Brick1: gnode1:/mnt/gnode_disk1/brick

Options Reconfigured:

changelog.changelog: on

geo-replication.ignore-pid-check: on

geo-replication.indexing: on

nfs.disable: on

performance.readdir-ahead: on

transport.address-family: inet



동기화 테스트

동기화 테스트를 수행하기 위해 별도의 Gluster Client 를 사용해야 하지만, Gluster 서버 자신을 클라이언트로 사용해도 된다. 다시 말해 Gluster 서버에서 자신의 Volume 을 리모트 마운트하는 것이다. 다음과 같이 진행해 보자.


* gnode1: Gluster Fuse Client 로 distvol 볼륨을 로컬의 /mnt/gnode1_distvol/ 디렉토리로 마운트하고 해당 디렉토리로 이동

[root@gnode1 ~]# mkdir /mnt/gnode1_distvol

[root@gnode1 ~]# mount.glusterfs gnode1:/distvol /mnt/gnode1_distvol/

[root@gnode1 ~]# cd /mnt/gnode1_distvol/


* gnode2: Gluster Fuse Client 로 distvol 볼륨을 로컬의 /mnt/gnode2_distvol/ 디렉토리로 마운트하고 해당 디렉토리로 이동

[root@gnode2 ~]# mkdir /mnt/gnode2_distvol

[root@gnode2 ~]# mount.glusterfs gnode1:/distvol /mnt/gnode2_distvol/

[root@gnode2 ~]# cd /mnt/gnode2_distvol/


* gnode1: 파일 생성, 수정 및 삭제

[root@gnode1 ~]# echo abcdef----xyzxyz----xxxx > test.txt

[root@gnode1 ~]# cp test.txt s

[root@gnode1 ~]# cat test.txt >> s

[root@gnode1 ~]# cp s x

[root@gnode1 ~]# cat s >> x

[root@gnode1 ~]# vi x

[root@gnode1 ~]# rm tttt

...

[root@gnode1 ~]# gluster volume geo-replication distvol gnode2::distvol status

MASTER NODE    MASTER VOL    MASTER BRICK              SLAVE USER    SLAVE              SLAVE NODE    STATUS    CRAWL STATUS       LAST_SYNCED                  

-----------------------------------------------------------------------------------------------------------------------------------------------------

gnode1         distvol       /mnt/gnode_disk1/brick    root          gnode2::distvol    gnode2        Active    Changelog Crawl    2016-10-10 01:15:22


* gnode2 디렉토리 내의 파일 변화 관찰, 확인

[root@gnode2 gnode2_distvol]# ls

s  test.txt  x

[root@gnode2 gnode2_distvol]# cat test.txt

abcdef----xyzxyz----xxxx

[root@gnode2 gnode2_distvol]#


몇 가지 팁들 ... port 변경, 작은 파일에 유리한 option 등

Gluster 의 geo-replication은 내부적으로 ssh를 통한 rsync 방식으로 동작한다. 일반적으로 ssh는 TCP 22 포트를 사용하는데, 임의의 포트번호로 설정하려면 다음과 같이 진행하면 된다(사실, "How to replicate to slave via non-standard ssh port..." 에 대한 답이다).


우선 양쪽 Gluster 서버에서 ssh port 를 변경한다


# vi /etc/ssh/sshd_config

...

Port 22222

...


# systemctl restart sshd

# netstat -anp | grep 22222

tcp   0   0   0.0.0.0:22222    0.0.0.0:*    LISTEN    8425/sshd

...


만약 netstat 결과에 해당 포트번호로 바인딩되어 있지 않고 ssh 접속이 안된다면 SELINUX가 ssh의 기본 Port인 22번으로 바인딩하게 고정해 둔 것일 게다. 그러면 다음과 같은 semanage 명령을 수행하고 조금 시간이 지난 뒤에 다시 접속해 본다.


# semanage port -a -t ssh_port_t -p tcp 22222


Linux 서버에서 파이어월(firewalld)이 사용되고 있다면 다음과 같이 해당 포트를 허용해 주는 것도 잊지 않도록 하자.


# firewall-cmd --permanent --zone=public --add-port=22222/tcp

# firewall-cmd --reload


성공적으로 ssh 포트 번호를 변경하였다면, 이번에는 Gluster 에서 새로운 포트로 Geo-replication 이 되도록 설정하면 된다.


[root@gnode1 ~]# gluster volume geo-replication distvol gnode2::distvol stop

[root@gnode1 ~]# gluster volume geo-replication distvol gnode2::distvol delete

[root@gnode1 ~]# gluster volume geo-replication distvol gnode2::distvol create ssh-port 22222 push-pem

[root@gnode1 ~]# gluster volume geo-replication distvol gnode2::distvol config ssh-port 22222

[root@gnode1 ~]# gluster volume geo-replication distvol gnode2::distvol start



Rsync는 Block 방식의 전송이기 때문에 파일의 크기가 큰 경우에 좀 더 유리하다. 반대로 말하면 크기가 작은(대략 수 KB~수백KB 이내) 파일의 경우 전송 지연이 발생할 수 있게 되는데, 이 때에는 다음과 같은 옵션을 적용하여 테스트해 보기를 권한다. Geo-replication 이 작동되는 도중에도 실행해 볼 수 있다.


[root@gnode1 ~] gluster volume geo-replication distvol gnode2::distvol config use-tarssh true


참고로, 간단히 테스트 해 보니 50KB 크기의 몇 백 개 파일 전송에 1분 26초 정도 걸리던 것이, 옵션 변경 후에 약 10초 가량 전송 시간이 줄어든 것을 볼 수 있었다.


원래의 기본 전송방식인 Rsync 방식으로 돌아가려면 다음과 같이 하면 된다.

[root@gnode1 ~] gluster volume geo-replication distvol gnode2::distvol config \!use-tarssh



Good Luck !


- Barracuda -


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


(참고)Opensuse 에서는 본 과정이 필요하지 않았음.
CentOS에서 별도로 ctype의 설정이 필요한 것을 보면 RHEL 등의 redhad 계열에서 모두 필요한 과정으로 보임.

Dependancy: fuse, fuse-devel, flex, bison, python-devel, ctype

위의 의존성 있는 패키지들을 모두 설치하여야 한다.
단, ctype은 기본 centOS repository 에 포함되어 있지 않으므로 Source로 다운로드해서 빌드한다.

 # wget wget  http://downloads.sourceforge.net/project/ctypes/ctypes/1.0.2/ctypes-1.0.2.tar.gz
# tar xvzf  ctypes-1.0.2.tar.gz
# cd  ctypes-1.0.2
# python setup.py build
# python setup.py install

이제 Gluster Source를 다운로드하고 설치한다.

# wget http://download.gluster.com/pub/gluster/glusterfs/3.2/3.2.2/glusterfs-3.2.2.tar.gz
# tar xvzf glusterfs-3.2.2.tar.gz
# cd  glusterfs-3.2.2
# ./configure --enable-fusermount
# make && make install
# ldconfig

Gluster volume 을 마운트하고 테스트해본다
# mount -t glusterfs w.x.y.z:/volname /local_mount_point


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


* 본 정보는 Opensuse 12.1 에도 그대로 적용 가능하다.

Opensuse 에 기본으로 제공되는 scim(xim)은 terminal 에서 한글 입력이 거의 안된다. 무슨 말인지 모르겠다면 직접 설치해서 gedit 이나 chrome 에서 한글을 입력해 보면 된다. 아마도 '우리는' 이라고 치면 '우루는' 이라고 입력되는 꼬락서니를 볼 수 있을 것이다.

* 선행 패키지 설치(su - 로 root 로 변신)

  # zypper in -y gcc make autoconf libhangul libhangul-devel

  -> http://code.google.com/p/libhangul/downloads/list 에서 libhangul 최신 버전 확인

  -> wget http://libhangul.googlecode.com/files/libhangul-0.1.0.tar.gz

  -> configure --prefix=/usr; make; make install



* Nabi source download & build

  # wget http://kldp.net/projects/nabi/download/5926?filename=nabi-0.99.9.tar.gz

  -> http://code.google.com/p/nabi/downloads/list 에서 최신 버전 확인 

  -> wget http://nabi.googlecode.com/files/nabi-0.99.11.tar.gz


  # tar xvzf nabi-0.99.11.tar.gz

  # ./configure --prefix=/usr
  # make && make install


* nabi 설정

  # vi /etc/X11/xim.d/nabi

  OLD_PATH=$PATH
  PATH=/usr/bin:/usr/X11R6/bin:$PATH

  if ! type -p nabi > /dev/null 2>&1 ; then
    echo "nabi is not available."
    return 1
  fi

  export XMODIFIERS="@im=nabi"
  export GTK_IM_MODULE=xim
  export QT_IM_SWITCHER=imsw-multi
  export QT_IM_MODULE=xim

  case $WINDOWMANAGER in
    *kde|*windowmaker|*wmaker)
    nabi -wm -wait &
    ;;
  *)
    nabi &
    ;;
  esac

  PATH=$OLD_PATH

  # success:
  return 0


# vi /etc/sysconfig/language, 아래 내용으로 편집/수정

  INPUT_METHOD="nabi"



* Logout하고 다시 Login 하면 우측하단 Tray에서 nabi icon 을 확인할 수 있다 


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


이 부분을 이해 하려면 Unix의 RunLevel에 대해 알아야 한다.

기본적으로 Unix 계열의 OS는 아래의 7개 모드로 구분된 Run level을 가진다
 0 - Halt status
 1 - Single User
 2 - Multi User, No Networking
 3 - Multi User, Full Networking
 4 - Reserved
 5 - 3 & X windows
 6 - Restarting status

위 각각의 상태로 시스템이 전환될 때 자동적으로
/etc/rc.d/rc?.d/ 의 스타일로 7개의 서브 dir 이 준비되어 있고
각각의 디렉토리내에는 S??scriptname, K??scriptname 형태의 파일들이 존재하는데
S는 start, K는 kil, ??의 숫자는 해당 모드로 진입했을때의 실행순서이고
scriptname은 실행되어야 할 스크립트 파일의 이름이다. 일반적인 Daemon들의 실행방식이라면
scriptname start | stop | restart 의 형식으로 동작될 것이다.

예를 들어 aaa 라는 프로그램을 만들고 이를 실행, 중지, 재기동할 수 있는 script를 runaaa 라고 만들었다면, 이 runaaa 라는 파일을 /etc/init.d(Debian계열, ubuntu 등) 또는 /etc/rc.d/init.d(RH계열, cent등)에 복사하고 ln 명령으로 symbolic link를 /etc/rc?.d/S99runaaa 내에 생성한다. 99는 rc?.d 디렉토리의 기존 스크립트 번호를 기준으로 설정자 판단에 따라 결졍하는 순서 값이다.

실제로는 아래의 7개 link 명령을 root 계정으로 수행한다.
# ln -s /etc/init.d/runaaa /etc/rc0.d/K99runaaa
# ln -s /etc/init.d/runaaa /etc/rc1.d/K99runaaa
# ln -s /etc/init.d/runaaa /etc/rc2.d/S99runaaa
# ln -s /etc/init.d/runaaa /etc/rc3.d/S99runaaa
# ln -s /etc/init.d/runaaa /etc/rc4.d/S99runaaa
# ln -s /etc/init.d/runaaa /etc/rc5.d/S99runaaa
# ln -s /etc/init.d/runaaa /etc/rc6.d/K99runaaa
즉 위의 설정으로 runlevel 0, 1, 6일때는 Kill을, 2, 3, 4, 5 일때는 Start를 시스템에서 자동으로 수행시켜 준다

이 과정을 자동으로 해 주는 시스템유틸리티가 chkconfig 이다. 즉 /etc/init.d에 runaaa 스크립트를 복사한 상태에서
# chkconfig --add runaaa
를 수행하면 별도로 위에서처럼 symbolic link 를 수행해주지 않아도 된다. 아래와 같이 확인 해 보자
# chkconfig --list | grep runaaa

만약 chkconfig가 시스템에 설치되어 있지 않다면 yum 또는 apt-get 으로 설치하여 사용한다
# sudo apt-get install chkconfig


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


테스트 기종: Sony Vaio Z46/LD
필요조건: VMware 7.0 worksation 설치, System Bios에서 VT를 enable(사전에 최신 VT 지원 bios patch), Internet 연결

사전 다운로드 필요파일들
 - h-sl106.iso(약 7.5 G) <-- Mac OS X Snow Leopard 10.6 HOTiSO image(Retail version의 DVD image)
 - vmware-darwin-200(+darwin.iso 포함) <-- Mac EFI Bootloader emulator

설치 방법은 크게 2가지
 1. Windows 7을 native(host)로 하여 VMware 내에서 Mac OS X 사용
 2. 설치 자체는 VMware를 통하여 진행하되, BootThink를 통한 멀티부트로 Mac OS X사용
   (이 경우 안정적으로 사용하기 위해 별도 HDD가 하나 필요함)

설치방법(먼저 Shovel action...(삽질)해 주신 분들에게 경의를... ㅋㅋㅋ)
 - 위 1번은 http://blog.naver.com/PostView.nhn?blogId=laizenti&logNo=40099413078 <- 그대로 따라 하면 거의 승률 100%
      또는    http://blog.naver.com/baljern/140098696647
 - 위 2번은 http://smok95.tistory.com/172 의 내용을 참조하여 진행하면 된다

설치후 Mac OS X on vmware용 VGA, audio 드라이버들을 sourceforge VMsvga2 프로젝트에서 다운로드 받고 설치하면
기본적인 Mac OS X SnowLeopard 사용에 큰 지장이 없을 것이다.

Mac OS 내에서 Safari 를 띄우고 http://vmsvga2.sourceforge.net/ 에 접속하여 각각 다운로드, 설치한다
 - VGA는 VMsvga2_v1.2.2_Common_Installer.pkg
 - audio는 EnsoniqAudioPCI_1.0.2_for_SnowLeopard.mpkg.tar.gz

끝.


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


VMware 7에서 Guest OS로 Ubuntu 9.10을 설치하고 난 후
깔끔한 desktop의 동작을 위해 vmware tools를 설치해야 하는데, vmware에서 easy install을 선택하면
vmware내의 메뉴를 통해서는 toos가 설치가 되지 않는군... ㅡ_-;;

vmware tools가 설치되기 위한 개발 환경 설정이 필요하다
> sudo apt-get install build-essential linux-headers-`uname -r` psmisc

ctrl+alt 하여 이제 VMware 메뉴의 VM>Re-install Vmware tools 메뉴를 선택하면

Ubuntu 바탕화면에 DVD 아이콘이 설치되고 파일찾아보기 팝업창이 뜨게 된다.

여기서 VMwareTools-***.tar.gz 파일이 나타날텐데 double-click하고 압축 해제한다.

~/Desktop에 압축해제하였다면 ~/Desktop/vmware-tools-distrib 에 파일들이 존재할 것이다
> cd ~/Desktop/vmware-tools-distrib
> sudo ./vmware-install.pl
설치 과정에서 모든 질문에 <enter> 만 두드려주면 된다.

설치가 끝나면 xServer가 재기동되고 enjoy...뭐라뭐라 하면서
prompt가 떨어질 것이다

이제
> vmware-toolbox 또는
> sudo vmware-toolbox
로 vmware tool을 재설정할 수 있게된다.

저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


기본으로 설치되는 iBUS는 문제가 있어서 여러 해결 방법들이 있지만
Simple is the best 라고 했던가...
nabi를 설치하고 입력 인터페이스 패키지로 지정하면 된다

nabi 가 설치 되지 않은 경우에 대비해서 다운로드/설치를 수행한다
> sudo apt-get install nabi

성공적으로 설치되었거나 이미 설치되었다고 나오거나 둘 중 하나일 것이다
다음으로

입력 패키지를 지정한다
> sudo im-switch -c

System wide default for ko_KR locale is marked with [+].
There are 2 choices for the alternative xinput-ko_KR (providing /etc/X11/xinit/xinput.d/ko_KR).

  Selection    Path                          Priority   Status
------------------------------------------------------------
* 0            /etc/X11/xinit/xinput.d/ibus   60        auto mode
  1            /etc/X11/xinit/xinput.d/ibus   60        manual mode
  2            /etc/X11/xinit/xinput.d/nabi   50        manual mode

Press enter to keep the current choice[*], or type selection number:

위 결과에서 선택을 물어 오는데 여기서 2번을 지정하면 된다

이제 reboot하고 확인작업에 들어 가면 끝.

저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들