zookeeper Replication (3 host clustering) 설정하기

이전 포스팅에서 zookeeper 설치 및 환경 설정을 해보았는데, 이번 포스팅에서 zookeeper를 3개 host에서 실행하고 keepalived를 사용하여 하나의 vip로 묶는과정까지 진행해보자.

 

1. zookeeper 설정파일

zoo.cfg파일 내용이다. 이전 포스팅에서 설정파일에 대한 설명이 나와있으니 자세한 설명을 생략!

tickTime=2000
dataDir=/~~/~~/~~/zookeeperDataDir
clientPort=2181
initLimit=5
syncLimit=2
server.1=10.113.78.147:2888:3888
server.2=10.113.79.117:2888:3888
server.3=10.113.97.243:2888:3888

* zoo.cfg파일의 dateDir에 myid라는 이름의 파일을 생성해주어야 한다는 점을 기억하자. myid의 내용은 server.X << 숫자

 

2. zookeeper service 생성

zookeeper를 zkServer.sh start를 통해 실행할 수 있지만, service로 등록해서 실행하는 것이 바람직하다. zookeeper-server.service라는 이름의 파일을 하나 생성하자.

vim zookeeper-server.service

 

zookeeper-server.service

service 파일 설정값에 대한 정보는 service, systemctl 포스팅을 참고하자.

[Unit]
Description=zookeeper-server
After=network.target

[Service]
Type=forking
SyslogIdentifier=zookeeper-server
WorkingDirectory=/blabla
Restart=always
RestartSec=1s
ExecStart=/~~/zkServer.sh start
ExecStop=/~~/zkServer.sh stop

[Install]
Alias=zookeeper-server

 

systemd의 파일을 새로 만들거나 기존 파일을 수정한 이후에는 반드시 systemd 재시작을 위해 systemctl daemon-reload를 실행해야 한다. 그 후 아래 명령어를 차례로 입력하여 zookeeper를 실행하면 된다.

 

sudo systemctl enable zookeeper-server
sudo systemctl start zookeeper-server

 

실행한 zookeeper-server의 상태 확인 :  sudo systemctl status zookeeper-server

 

3. zookeeper cli로 접속 테스트

zkClie.sh -server 127.0.0.1:2181

 

zookeeper cli로 접속해보면 아래와 같은 에러가 발생한다.

Closing socket connection. Attempting reconnect except it is a SessionExpiredException.
EndOfStreamException: Unable to read additional data from server sessionid 0x0, likely server has closed socket

zookeeper cluseter는 3개 호스트로 구성했는데, 실제 동작하는 호스트는 1개이기 때문에 최소 쿼럼을 만족하지 못해서 에러가 발생한다. 쿼럼을 만족하면 에러는 발생하지 않는다. (쿼럼-Quorum : 분산시스템에서 작업을 수행하기 위해 트랙잭션이 획득해야 하는 최소 투표수, 쉽게 생각해서 /2 + 1이라고 생각하면 된다. 3의 쿼럼은 3/2+1=2, 5의 쿼럼은 5/2+1=3)

 

나머지 호스트에도 위와 동일하게 zookeeper service 등록하고 실행하면 zookeeper cli를 사용했을 때, 정상적으로 커넥션이 된다.

 

4. keepalived를 사용하여 주키퍼 호스트들을 묶는 vip생성

 Zookeeper Golang Client를 사용해보니, 주키퍼 앙상블에 속한 서버들 전체에 대한 Connection을 갖고 있으며, 그중 접속이 가능한 서버와 통신을 하게 구성이 되어 있어서 따로 keepalived를 통해 VIP를 묶지 않아도 될 듯하다.

 

하지만, Keepalived는 이중화 구성에서 좋은 방법인듯 하니, 공부하고 알아두면 도움이 될거 같다.

 

맨 처음, KeepAlived를 사용하려 했었던 이유 :

현재 주키퍼 앙상블(클러스터)는 3개 호스트로 구성되어 있으며, 어느 호스트의 IP로 접근해도(API 호출해도) 앙상블로 묶여있기 때문에 동일한 결과를 낸다. 하지만 실제 zookeeper를 사용하는 client에서 어느 호스트의 IP로 접근해야 하는지에 대한 문제가 남아있다.

 

클라이언트에서 호스트 A를 통해 주키퍼 앙상블과 통신을 하고 있었다고 가정할 때, 호스트 A에 장애가 발생하여 통신이 되지 않게 되면, 주키퍼 앙상블은 정상적으로 동작하지만, 클라이언트는 주키퍼 앙상블을 이용할 수 없기 때문이다.

 

따라서 주키퍼 앙상블의 호스트를 묶어주는 vip가 필요 (앙상블을 대표하는 ip) 하고, 이를 keepalived를 통해 그나마 손쉽게(?) 설정할 수 있다.

 

keepalived는 VRRP 프로토콜을 사용하며, 꽤 복잡한 구성을 갖고있다. 이번에는 zookeeper 호스트를 묶는 vip생성에만 초점을 맞춰서 간단하고 빠르게 진행해보자.

 

keepalivd와 VRRP에 대한 정보는 아래 링크에 정말 잘 나와있다. 따라서 구성해보면 vip 구성완료!

springboot.cloud/24