[NCP/Network] PCS를 활용한 Active-Stanby 구조 HA cluster 구성 방법

테스트 환경: NCP VPC 환경 Server centos-7.3-64

 

이전 포스팅에서는 NCP Classic 환경에서 Keepalived를 활용하여 HA를 구성하는 방법에 대해 작성했었다.

 

이번 포스팅 내용 역시 HA를 구성하는 방법에 대해 작성하려고 한다.

NCP VPC 환경에서는 Keepalived 및 VRRP를 지원하지 않기 때문에 Pacemaker를 활용하여 VPC 환경에서 HA cluster 를 구성을 해보았다.

 

VPC 환경에서 LB+Pacemaker+corosync + (pcs) 의 형태로 구성하였고, Load Balancer 에 바인딩하여 웹 서버가 정상 Active-Stanby 구조로 Failover 되는지와 80 port로 헬스 체크 시 트래픽이 어느 쪽으로 흘러가는지까지 확인해 보려고 한다.

 

pcs: pacemaker/corosync 설정,관리 시스템

* pacemaker: 고가용성 클러스터 리소스 관리자 (고장을 인지한 경우 대기장비로 서비스를 넘김.- failover)
* corosync: 그룹커뮤니케이션 시스템을 구현하기 위한 HA기능 API 제공 (node status)

 

구성은 아래와 같이 진행하였다.

 

1. NCP VPC 환경 2대의 서버 생성

 

- VPC 환경에서 2대의 centos서버를 KR-2존에 생성하였다.

 

 

2. 필요한 패키지 파일 설치(corosync, pcs, pacemaker, nginx)

 

- yum  저장소에는 nginx가 없기 때문에 외부 저장소를 추가 후 설치해야 한다. /etc/yum.repos.d/ 경로에 nginx.repo 파일을 추가하고 아래와 같이 작성해 준다.

* 다른 웹 서버 애플리케이션을 이용할 예정이라면 이용하고자하는 웹 서버 애플리케이션을 설치해주면 되며, 해당 과정은 패스해도 됨.

$> vi /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1
* OS가 다르다면 해당 OS에 맞게 수정해 주면 된다. 
* 웹 서버 연결에는 nginx를 사용할 예정이라 미리 설치했으며, nginx를 미리 설치할 필요는 없다. 

 

- 구성에 필요한 패키지들을 두 서버에 설치를 먼저 진행한다.

[root@pcs-test-001 ~]# yum -y install corosync pcs pacemaker nginx
[root@pcs-test-002 ~]# yum -y install corosync pcs pacemaker nginx

 

- nginx resource 추가를 진행해 준다. /lib/ocf/resource.d/heartbeat 는 기본적으로 제공하는 LSB 익스텐션 경로로, 아래 script 를 추가해준다.

* nginx 설치 시 기본적으로 해당 script 파일과 755 권한이 부여되어 있어, 없는 경우에만 진행하면 된다.
# cd /usr/lib/ocf/resource.d/heartbeat
# wget https://raw.githubusercontent.com/ClusterLabs/resource-agents/master/heartbeat/nginx
# chmod 755 nginx

 

 

3. cluster 를 구성할 각 노드의 ip 주소를 설정

 

- /etc/hosts에 각 노드를 등록해 준다.

[root@pcs-test-001 ~]# vi /etc/hosts
[root@pcs-test-002 ~]# vi /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

172.16.1.13 pcs-test-001
172.16.1.14 pcs-test-002

 

 

4. 방화벽 설정

 

- 클라우드 환경에서는 방화벽 비활성화가 default 이므로 해당 명령을 수행하지 않았지만, 방화벽을 사용하는 경우라면 방화벽을 열어줘야한다.

[root@pcs-test-001 ~]# firewall-cmd --permanent --add-service=high-availability
[root@pcs-test-002 ~]# firewall-cmd --permanent --add-service=high-availability

 

- 고 가용성 추가 기능을 위해 활성화되어야 하는 포트 목록

# firewall-cmd --zone=public --permanent --add-port=2224/tcp;
success
# firewall-cmd --zone=public --permanent --add-port=3121/tcp;
success
# firewall-cmd --zone=public --permanent --add-port=5403/tcp;
success
# firewall-cmd --zone=public --permanent --add-port=21064/tcp;
success
# firewall-cmd --zone=public --permanent --add-port=9929/tcp;
success
# firewall-cmd --zone=public --permanent --add-port=5404/udp;
success
# firewall-cmd --zone=public --permanent --add-port=5405/udp;
success
# firewall-cmd --zone=public --permanent --add-port=9929/udp;
success
# firewall-cmd --reload
success
# firewall-cmd --zone=public --list-all

 

 

5. pacemaker 데몬 시작 및 autostart 추가

 

- 위 설정이 완료되었다면 pacemaker 데몬을 시작해주고 autostart 까지 추가해주도록 한다.

[root@pcs-test-001 ~]# systemctl start pcsd
[root@pcs-test-001 ~]# systemctl enable pcsd; systemctl enable corosync; systemctl enable pacemaker
[root@pcs-test-002 ~]# systemctl start pcsd
[root@pcs-test-002 ~]# systemctl enable pcsd; systemctl enable corosync; systemctl enable pacemaker

 

 

6. 클러스터 계정 설정

 

- 패스워드 설정 시 두 서버 모두 동일하게 설정해야 한다.

# id hacluster
uid=189(hacluster) gid=189(haclient) groups=189(haclient)
[root@pcs-test-001 ~]# passwd hacluster 
[root@pcs-test-002 ~]# passwd hacluster 

 

 

7. 클러스터의 각 노드에 대해 인증 확인

 

- hacluster에 패스워드를 입력하여 각 노드에 대해 인증을 확인하는 절차를 진행해준다.

[root@pcs-test-001 ~]# pcs cluster auth pcs-test-001 pcs-test-002
Username: hacluster
Password: 
pcs-test-001: Authorized
pcs-test-002: Authorized

 

* 만약 "Error: Unable to communicate with" 에러가 나오면 아래 두 가지 경우를 확인해봐야 한다.

1) /etc/hosts 에 각 노드가 등록되지 않은 경우가 있다. 위 3번을 참고하여 등록을 진행

2) 고 가용성 추가 기능을 위해 활성화되어야 하는 포트가 방화벽 문제로 막혀있을 가능성이 있다.
위 4번의 방화벽 설정 포트 내용에 나와있는 포트들을 열어줘야 하며, 방화벽 오픈 및 reload 하여 오픈된 리스트를 확인 후 양쪽 노드 다 오픈후 다시 인증 시도

 

 

8. 클러스터 생성 및 실행

 

- 클러스터 노드에 대한 인증이 확인되었다면 클러스터를 생성하여 실행하는 과정을 진행해준다.

[생성]
[root@pcs-test-001 ~]# pcs cluster setup --name web-cluster pcs-test-001 pcs-test-002
[데몬 시작]
[root@pcs-test-001 ~]# systemctl start pacemaker; systemctl start corosync
[root@pcs-test-002 ~]# systemctl start pacemaker; systemctl start corosync
[실행]
[root@pcs-test-001 ~]# pcs cluster start --all

 

- cluster를 실행 후 # pcs status, # corosync-cmapctl | egrep -i members, # pcs status corosync 과 같은 명령어로 확인 했을 때 pcs-test-002 노드가 올라와 있지 않는 경우가 있다.

클러스터 상태 확인

멤버쉽과 쿼럼을 확인

 

- UDP 통신을 하는데 UDP 통신이 막혀 있을 경우 이런 현상이 있을 수 있으므로, 포트 및 접근 제한 부분을 확인해 보면 된다.

NCP의 경우 ACG에 UDP 허용이 되어 있는지 확인해 봐야 한다.

테스트용 ACG라 모든 UDP, TCP 오픈으로 설정해놓음

 

 

9. 통신 및 상태 확인

 

- 중간중간 클러스터 상태를 확인하며 진행하는 것이 좋다.

[클러스터 통신을 확인]
[root@pcs-test-001 ~]# corosync-cfgtool -s

[멤버쉽과 쿼럼을 확인]
[root@pcs-test-001 ~]# corosync-cmapctl | egrep -i members

[corosync 상태확인]
[root@pcs-test-001 ~]# pcs status corosync

[클러스터 상태 확인]
[root@pcs-test-001 ~]# pcs status

 

 

10. Active/Passive cluster property 추가

 

- 클러스터 설정을 변경하기 전에 아래처럼  STONITH 부분에서 오류가 발행할 수 있어 crm_verify 명령어로 유효성을 확인해 두는 것이 좋다.

 

- 데이타의 무결성을 확보하기 위해 기본으로 STONITH가 활성화되어 있는데 이것을 비활성하고 다시 확인해 보면 아무런 오류가 발생하지 않는다.

* STONITH: (Shoot The Head in The Head) 가짜 노드 혹은 의도치 않은 동시 엑세스로 인한 데이터 손상을 보호한다. 
[root@pcs-test-001 ~]# pcs property set stonith-enabled=false
[root@pcs-test-001 ~]# crm_verify -L -V

 
- no-quorum-policy: 클러스터에 quorum이 없을 때의 수행 작업을 설정하는 작업인데 노드가 2개일 때는 quorum 정책이 오히려 비효율적이라 quorum policy를 ignore로 변경하였다.

[root@pcs-test-001 ~]# pcs property set no-quorum-policy=ignore

 

- resource-stickiness: 서비스 지속력

[root@pcs-test-001 ~]# pcs property set default-resource-stickiness=100

* PCS 설정 삭제
만약 설정을 잘못 하여 전부 지우고 다시 설정하고 싶을 때는 정지 및 삭제 후 다시 설정할 수 있다.
​[root@pcs-test-001 ~]# pcs cluster stop --all
[root@pcs-test-001 ~]# pcs cluster destroy --all

 

 

11. cluster ip 설정 및 resource 생성 및 web server resource 생성

 

- Virtual_IP를 리소스로 추가, Virtual_IP는 노드가 다운되면 다른 노드로 이동하며, 실제로 서비스에 이용되는 IP 주소로 이용.

- Virtual_IP는 세 부분 ocf:heartbeat:IPaddr2 의 형태로 구분되며, 여기에서, 첫번째 필드는 resource standard 두번째 필드는 표준에 따라 다르며 세번째 필드는 리소스 스크립트의 이름이다.

​[root@pcs-test-001 ~]#  pcs resource create Virtual_IP ocf:heartbeat:IPaddr2 ip=172.16.1.100 cidr_netmask=32 op monitor interval=30s
​[root@pcs-test-001 ~]#  pcs resource create webserver ocf:heartbeat:nginx configfile=/etc/nginx/nginx.conf op monitor timeout="5s" interval="5s"

 

 

12. cluster rule 추가

 

- Virtual_IP 와 webserver가 동일한 서버에 active로 올라오도록 설정

[resources 통합]
​[root@pcs-test-001 ~]# pcs constraint colocation add webserver Virtual_IP INFINITY

[설정값 확인​]
[root@pcs-test-001 ~]# pcs constraint order Virtual_IP then webserver

[priority 설정]
​[root@pcs-test-001 ~]# pcs constraint location webserver prefers pcs-test-001=50
* priority를 더 높임으로서 수동으로 리소스를 강제 이동시키도록 constraint location의 스코어를 50으로 설정하였으나, 만약 동작하지 않는 다면 constraint location의 스코어를 INFINITY로 변경하면된다. 

 

- 설정 확인 후 클러스터 재시작

​[root@pcs-test-001 ~]# pcs constraint
​[root@pcs-test-001 ~]# pcs cluster stop --all; pcs cluster start --all

 

 

13. Load Balancer에 바인딩

 

- Target Group에 HTTP 프로토콜로 80 port 로 헬스 체크가 되도록 pcs-test-001, pcs-test-002 서버를 타겟으로 지정하였다.

 

- 해당 Target Group을 ALB에 바인딩하였다. (NLB에 80 port로 생성해도 무방)

 

 

14. Failover 테스트 및 확인

 

- 모든 구성 및 설정이 완료되었다면 active-standby 구조로 정상작동하는지 확인해 봐야 한다.

- 현재 pcs-test-001 서버만 active 상태로 정상헬스 체크되고 있다.

 

- Failover가 작동하는지 확인하기 위해서는 cluster 정지하거나 active 상태의 cluster를 standby상태로 변경해준다. 물론 아예 서버를 정지시켜도 된다.

​[root@pcs-test-001 ~]# pcs cluster stop pcs-test-001
or
​[root@pcs-test-001 ~]# pcs cluster standby pcs-test-001
or

서버 정지 상태

 

- 정지시키면 아래와 같이 vip와 webserver가 pcs-test-002로 넘어가 Failover가 정상적으로 동작하고 있는 것을 확인할 수 있다.

[root@pcs-test-002 ~]# ip addr | grep 172.16.1.
    inet 172.16.1.14/24 brd 172.16.1.255 scope global eth0
    inet 172.16.1.100/32 brd 172.16.1.255 scope global eth0

 

 

- cluster를 다시 시작 하면 priority에 의해 다시 pcs-test-001 서버가 active 상태로 넘어오게 된다.

[root@pcs-test-001 ~]# pcs cluster start pcs-test-001
or
[root@pcs-test-001 ~]# pcs cluster unstandby pcs-test-001

 

 

 

마무리

 

- 결과적으로, pcs-test-001 (acitve; priority 50) 가 서버 정지되면, UDP heartbeat을 받을 수 없으므로, pcs-test-002가 active 되며, Load Balancer는 pcs-test-002만 80 port 상태를 확인하여 해당 서버로 트래픽을 흘리게 되고, pcs-test-001을 다시 시작하면 priority에 의해 pcs-test-001이 active되며 pcs-test-002의 NginX는 shut down 되므로 Load Balancer는 해당 서버로 트래픽을 흘리지 않게된다.

 

- 클라우드 환경에서는 DB 같은 경우에도 완전 관리형으로 서비스가 제공되고 있고 웹-앱 서버도 Auto Scaling을 통해 scale in/out 할 수 있기 때문에 일반적으로는 Keepalived 나 Pacemaker 와 같은 라우팅 소프트웨어들을 활용하여 HA를 구성하는 경우가 많지는 않을 것이라고 생각되지만 일반 VM에 설치형으로 DB를 사용하거나 특수한 목적에서 Failover 기능을 구성할 때 유용하게 활용될 수 있을 것으로 보인다.