리눅스 HA 구성(CentOS7, corosync, pacemaker 이용)
참고:
리눅스 HA(corosync, pacemaker, DRBD) – Part 2
리눅스 HA (pacemaker, corosync, iscsi shared storage) – part 3
리눅스 HA(corosync, pacemaker, shared disk)에 zabbix 모니터링 서버 구성 – part 4
corosync와 pacemaker를 이용하여 리눅스 HA 클러스터를 구성한다.
Corosync – 클러스터의 저수준 인프라를 제공하며, 클러스터에 대한 쿼럼정보, 멤버쉽, 안정적인 메시징을 제공. 비슷한 프로젝트로는 heartbeat가 있음.
Pacemaker – 클러스터의 리소스 관리자. 클러스터 상태에 따른 자원이동, 노드 정지등을 담당함.
corosync와 pacemaker의 역할이 다르므로 보통 두가지를 같이 사용하여 HA 클러스터를 구성한다.
구성 환경
* 노드1
호스트네임 : wolf1
ip주소 : 192.168.100.31(eth1), 172.16.1.31(eth0)
OS : CentOS 7 minimal version
* 노드2
호스트네임 : wolf2
ip주소 : 192.168.100.32(eth1), 172.16.1.32(eth0)
OS : CentOS 7 minimal version
* 가상 IP주소 : 192.168.100.30 (eth0)
* corosync 2.4, pacemaker 1.1.15
* OS disk : vda
* Shared disk : vdb
1. 설치전 확인사항(양쪽 노드)
각 노드의 ip 주소를 설정하며, /etc/hosts화일에 각 노드를 등록해준다. /etc/hosts화일에 아래 내용을 등록.
# cat /etc/hosts 192.168.100.31 wolf1 192.168.100.32 wolf2 192.168.100.30 wolf
2. corosync, pacemaker 설치(양쪽 노드)
corosync, pacemaker를 양쪽 노드 모두 설치해준다. 여기서는 yum을 이용해 rpm 패키지로 설치한다.
# yum install -y pacemaker corosync pcs psmisc policycoreutils-python
3. selinux, 방화벽(iptables)설정
selinux와 방화벽은 사용하지 않음으로 미리 설정했다. 혹시 방화벽을 사용한다면, TCP 포트 2224, 3121, 21064 그리고 UDP 포트 5405를 열어주어야 한다.
4. 설정
양쪽 노드 모두에서 pcs 데몬을 실행한다. (참고로, 옛날버전에서는 crm을 사용했었다) 이 데몬은 pcs 커맨드라인 인터페이스와 함께 모든 클러스터 노드에서 구성을 동기화하는 일을 한다.
양쪽노드에서 pcsd를 실행하고, (재부팅시 자동으로 실행되도록) 서비스를 enable 시킨다.
# systemctl start pcsd.service # systemctl enable pcsd.service Created symlink from /etc/systemd/system/multi-user.target.wants/pcsd.service to /usr/lib/systemd/system/pcsd.service.
양쪽노드에서, (자동으로 생성된) hscluster 계정의 비밀번호를 양쪽 동일하게 설정한다.
# passwd hacluster hacluster 사용자의 비밀 번호 변경 중 새 암호: 새 암호 재입력: passwd: 모든 인증 토큰이 성공적으로 업데이트 되었습니다.
corosync를 설정한다.
한쪽 노드에서 아래 커맨드로 hacluster 사용자로 인증한다.
# pcs cluster auth wolf1 wolf2 Username: hacluster Password: wolf1: Authorized wolf2: Authorized
CentOS8 에서는,
# pcs host auth wolf1 wolf2 Username: hacluster Password: wolf1: Authorized wolf2: Authorized
한쪽 노드에서 아래 커맨드로 corosync를 구성하고 다른 노드와 동기화한다.
# pcs cluster setup --name wolf_cluster wolf1 wolf2 Destroying cluster on nodes: wolf1, wolf2... wolf1: Stopping Cluster (pacemaker)... wolf2: Stopping Cluster (pacemaker)... wolf2: Successfully destroyed cluster wolf1: Successfully destroyed cluster Sending cluster config files to the nodes... wolf1: Succeeded wolf2: Succeeded Synchronizing pcsd certificates on nodes wolf1, wolf2... wolf1: Success wolf2: Success Restarting pcsd on the nodes in order to reload the certificates... wolf1: Success wolf2: Success
CentOS 8에서는,
# pcs cluster setup wolf_cluster wolf1 wolf2 No addresses specified for host 'wolf1', using 'wolf1' No addresses specified for host 'wolf2', using 'wolf2' Destroying cluster on hosts: 'wolf1', 'wolf2'... wolf2: Successfully destroyed cluster wolf1: Successfully destroyed cluster Requesting remove 'pcsd settings' from 'wolf1', 'wolf2' wolf1: successful removal of the file 'pcsd settings' wolf2: successful removal of the file 'pcsd settings' Sending 'corosync authkey', 'pacemaker authkey' to 'wolf1', 'wolf2' wolf1: successful distribution of the file 'corosync authkey' wolf1: successful distribution of the file 'pacemaker authkey' wolf2: successful distribution of the file 'corosync authkey' wolf2: successful distribution of the file 'pacemaker authkey' Sending 'corosync.conf' to 'wolf1', 'wolf2' wolf1: successful distribution of the file 'corosync.conf' wolf2: successful distribution of the file 'corosync.conf' Cluster has been successfully set up.
5. 클러스터 실행과 상태 확인
아래 커맨드로 클러스터를 실행한다.
# pcs cluster start --all wolf1: Starting Cluster... wolf2: Starting Cluster...
클러스터 통신을 확인한다.
# corosync-cfgtool -s Printing ring status. Local node ID 1 RING ID 0 id = 192.168.100.31 status = ring 0 active with no faults
멤버쉽과 쿼럼을 확인한다.
# corosync-cmapctl | egrep -i members runtime.totem.pg.mrp.srp.members.1.config_version (u64) = 0 runtime.totem.pg.mrp.srp.members.1.ip (str) = r(0) ip(192.168.100.31) runtime.totem.pg.mrp.srp.members.1.join_count (u32) = 1 runtime.totem.pg.mrp.srp.members.1.status (str) = joined runtime.totem.pg.mrp.srp.members.2.config_version (u64) = 0 runtime.totem.pg.mrp.srp.members.2.ip (str) = r(0) ip(192.168.100.32) runtime.totem.pg.mrp.srp.members.2.join_count (u32) = 1 runtime.totem.pg.mrp.srp.members.2.status (str) = joined
# pcs status corosync
Membership information
----------------------
Nodeid Votes Name
1 1 wolf1 (local)
2 1 wolf2
# pcs status Cluster name: wolf_cluster WARNING: no stonith devices and stonith-enabled is not false Stack: corosync Current DC: wolf1 (version 1.1.15-11.el7_3.2-e174ec8) - partition with quorum Last updated: Sun Jan 22 20:36:20 2017 Last change: Sun Jan 22 20:28:40 2017 by hacluster via crmd on wolf1 2 nodes and 0 resources configured Online: [ wolf1 wolf2 ] No resources Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled
6. Active/Passive 클러스터 생성
클러스터 설정을 변경하기 전에 아래처럼 crm_verify 명령어로 유효성을 확인해 두는 것이 좋다. STONITH 부분에서 오류가 발생한다.
# crm_verify -L -V error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined error: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option error: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity Errors found during check: config not valid
데이타의 무결성을 확보하기 위해 기본으로 STONITH가 활성화되어 있는데 이것을 비활성하고 다시 확인해보면 아무런 오류가 발생하지 않는다.
# pcs property set stonith-enabled=false # crm_verify -L
가상 IP 리소스 생성
아래 명령어로 가상아이피를 리소스로 추가한다. 가상아이피는 노드가 다운되면 다른 노드로 이동하며, 실제로 서비스에 이용되는 IP 주소로 이용한다.
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.100.30 cidr_netmask=24 op monitor interval=30s
클러스터 상태를 확인해 보면, 리소스리스트에 VirtualIP가 추가된 것을 볼 수 있고, ip 주소를 확인해보면, 설정한 아이피주소가 나타남을 확인 할 수 있다.
# pcs status
Cluster name: wolf_cluster
Stack: corosync
Current DC: wolf1 (version 1.1.15-11.el7_3.2-e174ec8) - partition with quorum
Last updated: Sun Jan 22 21:46:00 2017 Last change: Sun Jan 22 21:43:48 2017 by root via cibadmin on wolf1
2 nodes and 1 resource configured
Online: [ wolf1 wolf2 ]
Full list of resources:
VirtualIP (ocf::heartbeat:IPaddr2): Started wolf1
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
[root@wolf1 etc]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:61:39:09 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.31/24 brd 172.16.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe61:3909/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:c7:94:dc brd ff:ff:ff:ff:ff:ff
inet 192.168.100.31/24 brd 192.168.100.255 scope global eth1
valid_lft forever preferred_lft forever
inet 192.168.100.30/24 brd 192.168.100.255 scope global secondary eth1
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fec7:94dc/64 scope link
valid_lft forever preferred_lft forever
위에서 추가한 리소스 VirtualIP는 세 부분 ocf:heartbeat:IPaddr2 의 형태로 구분했다. 여기에서, 첫번째 필드는 resource standard 두번째 필드는 표준에 따라 다르며 세번째 필드는 리소스 스크립트의 이름이다.
리소스 standard는 다음 명령어로 확인 가능하다.
# pcs resource standards ocf lsb service systemd
위 결과에서 각각의 의미는 다음과 같다.
ocf – Open cluster Framework
lsb – Linux standard base (보통 init scripts)
service – Based on Linux “service” command.
systemd – systemd based service Management
stonith – Fencing Resource standard.
두번째 필드인 ocf의 리소스 프로바이더는 아래 커맨드로 확인가능하다
# pcs resource providers heartbeat openstack pacemaker
세번째 필드인 리소스 스크립트는 아래처럼 확인 가능하다.
# pcs resource agents ocf:heartbeat CTDB Delay Dummy Filesystem IPaddr IPaddr2 IPsrcaddr LVM MailTo Route SendArp Squid VirtualDomain Xinetd apache clvm conntrackd db2 dhcpd docker ethmonitor exportfs galera garbd iSCSILogicalUnit iSCSITarget iface-vlan mysql nagios named nfsnotify nfsserver nginx oracle oralsnr pgsql portblock postfix rabbitmq-cluster redis rsyncd slapd symlink tomcat
이제, wolf1 을 정지시켜 failover를 확인해본다.
# pcs cluster stop wolf1 wolf1: Stopping Cluster (pacemaker)... wolf1: Stopping Cluster (corosync)... [root@wolf1 etc]# pcs status Error: cluster is not currently running on this node
wolf2 에서 클러스터 상태를 확인해 보면,
[root@wolf2 ~]# pcs status Cluster name: wolf_cluster Stack: corosync Current DC: wolf2 (version 1.1.15-11.el7_3.2-e174ec8) - partition with quorum Last updated: Sun Jan 22 23:21:08 2017 Last change: Sun Jan 22 21:43:48 2017 by root via cibadmin on wolf1 2 nodes and 1 resource configured Online: [ wolf2 ] OFFLINE: [ wolf1 ] Full list of resources: VirtualIP (ocf::heartbeat:IPaddr2): Started wolf2 Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled
wolf1에서 클러스터를 다시 실행해도, 리소스는 wolf1으로 돌아오지 않는다.
[root@wolf1 ~]# pcs cluster start wolf1 wolf1: Starting Cluster... [root@wolf1 ~]# pcs status Cluster name: wolf_cluster Stack: corosync Current DC: wolf2 (version 1.1.15-11.el7_3.2-e174ec8) - partition with quorum Last updated: Sun Jan 22 23:28:54 2017 Last change: Sun Jan 22 21:43:48 2017 by root via cibadmin on wolf1 2 nodes and 1 resource configured Online: [ wolf1 wolf2 ] Full list of resources: VirtualIP (ocf::heartbeat:IPaddr2): Started wolf2 Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled
resource stickniess – 자원의 이동에는 대부분 가동중지 시간이 필요하며, 데이타베이스처럼 복잡한 서비스는 이 시간이 길어질 수 있다. 이 문제를 해결하기위해서 pacemaker에서 제공하는 개념이 리소스 stickiness. 기본값은 0 이지만, 이 숫자를 늘여서 서비스가 이동하는 것을 제어할 수 있다.
[root@wolf1 ~]# pcs resource defaults No defaults set [root@wolf1 ~]# pcs resource defaults resource-stickiness=60 [root@wolf1 ~]# pcs resource defaults resource-stickiness: 60
7. 클러스터 서비스로 아파치 웹서버 등록하기
설치는 양쪽 노드에 아래 커맨드로 설치한다. wget은 서비스 상태를 모니터링하기 위해 설치한다.
[root@wolf1 ~]# yum install httpd wget [root@wolf1 ~]# ssh root@192.168.100.32 yum install -y httpd wget
설치를 마친후 /var/www/html/index.html 화일을 만든다.
/etc/httpd/conf.d/status.conf 화일에 아래 내용을 입력한다(양쪽 노드 모두).
# cat /etc/httpd/conf.d/status.conf
<Location /server-status>
SetHandler server-status
Require local
</Location>
아래커맨드로 리소스를 등록한하고 확인한다.
# pcs resource create WebService ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf statusurl="http://localhost/server-status" op monitor interval=1min # pcs resource op defaults No defaults set # pcs resource op defaults timeout=60s # pcs resource op defaults # pcs status Cluster name: wolf_cluster Stack: corosync Current DC: wolf2 (version 1.1.15-11.el7_3.2-e174ec8) - partition with quorum Last updated: Mon Jan 23 01:43:57 2017 Last change: Mon Jan 23 01:43:08 2017 by root via cibadmin on wolf1 2 nodes and 2 resources configured Online: [ wolf1 wolf2 ] Full list of resources: VirtualIP (ocf::heartbeat:IPaddr2): Started wolf1 WebService (ocf::heartbeat:apache): Started wolf2 Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled
위의 상태를 보면, 가상ip주소는 wolf1에, 웹서비스는 wolf2에서 실행되고 있음을 볼 수 있다. 이 문제는 colocation constraint 두 리소스를 묶어줌으로써 해결된다.
# pcs constraint Location Constraints: Ordering Constraints: Colocation Constraints: Ticket Constraints: # pcs constraint colocation add WebService with VirtualIP INFINITY # pcs constraint Location Constraints: Ordering Constraints: Colocation Constraints: WebService with VirtualIP (score:INFINITY) Ticket Constraints:
이제 확인해보면 두 리소스 VirtualIP, WebService가 같은 노드에서 실행되고 있음을 볼 수 있다.
# pcs status Cluster name: wolf_cluster Stack: corosync Current DC: wolf1 (version 1.1.15-11.el7_3.2-e174ec8) - partition with quorum Last updated: Mon Jan 23 13:32:16 2017 Last change: Mon Jan 23 13:30:03 2017 by root via cibadmin on wolf1 2 nodes and 2 resources configured Online: [ wolf1 wolf2 ] Full list of resources: VirtualIP (ocf::heartbeat:IPaddr2): Started wolf1 WebService (ocf::heartbeat:apache): Started wolf1 Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled
만약 어떤 서비스가 먼저 실행되고 난 이후 서비스가 실행되어야 할 필요가 있을때는 아래와 같은 방법을 사용한다. 아래는 VirtualIP가 먼저 실행된 후 WebService가 실행되도록 한다.
# pcs constraint Location Constraints: Ordering Constraints: Colocation Constraints: WebService with VirtualIP (score:INFINITY) Ticket Constraints: # pcs constraint order VirtualIP then WebService Adding VirtualIP WebService (kind: Mandatory) (Options: first-action=start then-action=start) # pcs constraint Location Constraints: Ordering Constraints: start VirtualIP then start WebService (kind:Mandatory) Colocation Constraints: WebService with VirtualIP (score:INFINITY) Ticket Constraints:
Pacemaker는 두 노드의 하드웨어사양이 동일할 필요가 없기 때문에, 보다 강력한 노드에서 서비스를 실행하도록 하는 것이 가능하다. 이는 constraint location을 지정함으로써 가능하다.
# pcs constraint location WebService prefers wolf2=50
# pcs constraint
Location Constraints:
Resource: WebService
Enabled on: wolf2 (score:50)
Ordering Constraints:
start VirtualIP then start WebService (kind:Mandatory)
Colocation Constraints:
WebService with VirtualIP (score:INFINITY)
Ticket Constraints:
8. 수동으로 리소스 강제 이동하기
리소스를 강제로 다른 노드로 이동하기 위해서는 constraint location의 스코어를 INFINITY로 변경하면된다. 아래는 WebService 리소스를 wolf2 노드로 강제 이동하는 명령어이다.
# pcs constraint
Location Constraints:
Resource: WebService
Enabled on: wolf2 (score:50)
Ordering Constraints:
start VirtualIP then start WebService (kind:Mandatory)
Colocation Constraints:
WebService with VirtualIP (score:INFINITY)
Ticket Constraints:
# pcs constraint location WebService prefers wolf2=INFINITY
# pcs constraint
Location Constraints:
Resource: WebService
Enabled on: wolf2 (score:INFINITY)
Ordering Constraints:
start VirtualIP then start WebService (kind:Mandatory)
Colocation Constraints:
WebService with VirtualIP (score:INFINITY)
Ticket Constraints:
# pcs status
Cluster name: wolf_cluster
Stack: corosync
Current DC: wolf1 (version 1.1.15-11.el7_3.2-e174ec8) - partition with quorum
Last updated: Mon Jan 23 14:08:17 2017 Last change: Mon Jan 23 14:08:00 2017 by root via cibadmin on wolf1
2 nodes and 2 resources configured
Online: [ wolf1 wolf2 ]
Full list of resources:
VirtualIP (ocf::heartbeat:IPaddr2): Started wolf2
WebService (ocf::heartbeat:apache): Started wolf2
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
constraint location 삭제는 아래와 같이 할 수 있다.
현재의 constraint를 확인하고,
# pcs constraint
Location Constraints:
Resource: WebService
Enabled on: wolf1 (score:INFINITY)
Disabled on: wolf2 (score:-INFINITY)
Ordering Constraints:
start VirtualIP then start WebService (kind:Mandatory)
Colocation Constraints:
WebService with VirtualIP (score:INFINITY)
id를 확인하고, remove 한다.
# pcs constraint --full
Location Constraints:
Resource: WebService
Enabled on: wolf1 (score:INFINITY) (id:location-WebService-wolf1-INFINITY)
Disabled on: wolf2 (score:-INFINITY) (id:location-WebService-wolf2--INFINITY)
Ordering Constraints:
start VirtualIP then start WebService (kind:Mandatory) (id:order-VirtualIP-WebService-mandatory)
Colocation Constraints:
WebService with VirtualIP (score:INFINITY) (id:colocation-WebService-VirtualIP-INFINITY)
Ticket Constraints:
# pcs constraint remove location-WebService-wolf2--INFINITY
* 2019.10.17 아래내용 추가.
늦었지만, 리눅스 HA(corosync, pacemaker, DRBD) – Part 2로 이어집니다.
리눅스 HA(Pacemaker, corosync, iscsi shared storage, lvm2) – part 3
37 comments
Skip to comment form
위 처럼 HA 구성한 것은 Cluster개념은 아니죠?
storage 하나를 두고 서버 두개 운용하는 방법은 아닌거죠?
Author
제가 구성한것에서는 shared storage가 빠져 있습니다. 다만, shared storage 붙여서 active/passive, active/active 구성도 가능합니다.
좋은 글 감사합니다. 한가지 궁금한 것이 있는데요.
Standby –> Active로 구성될 때..
별도의 서비스 모듈(데몬)을 실행하기 위해서는 어떻게 해야 하나요?
Author
제가 작성한 글에서는 apache를 예로 들었습니다. 양쪽 노드에 apache를 설치하고 테스트 했습니다.
Standby->Active란 것이 failover 발생후 원상 복구를 의미하는 것인지요? 이 경우는 제 글의 8번 항목을 참고하시면 될 것 같습니다.
그것이 아니라, 특정한 서비스를 등록하는 것을 의미하는 것이라면 서비스 등록문제는 리소스 스크립트가 제공되는 서비스는 특별한 문제는 없을 것으로 생각됩니다. 다만, 제공되지 않는다면 스크립트를 만들거나 제공되는 스크립트를 수정해야 합니다. 그리고 서비스가 실행되는것은, pcs cluster start –all 명령어에 의해 등록된 서비스가 자동으로 실행됩니다. 물론 이때 만들거나 수정한 스크립트라면, 서비스 시작/정지 스크립트가 이상이 없이 잘 작동해야 합니다. 즉, 원하는 서비스를 클러스터에 리소스 등록하면, 원하는 서비스의 시작/정지는 클러스터가 알아서 실행하는 것이지요.
답변이 되었나 모르겠네요..
글 잘 보았습니다.
위 구성에 스토리지 한대를 추가해서 2개의 노드가 한개의 스토리지를 바라볼수 있게
멀티패스 구성에 대해서 어찌 하는지 궁급합니다.^^
Author
공유스토리지를 서버 1, 2에 모두 할당하고, pcs clvm으로 구성했던것으로 기억합니다. active-passive인 경우는 lvm 만으로도 가능할거예요.
이거 오래전에 했던거라서…
part 2에서 정리하려고 했었는데, 이런저런 사정으로 part2를 못만들었네요.
리소스 그룹으로 vip 와 webservice 를 묶는 것과 위 설정 하신것과의 차이 점이 있을까요?
위의 구성은 단순하게 웹서비스만 돌려보는것이라서 별 문제가 없지만,
위의 구성에 공유스토리지, 데이타베이스 등등 서로 연관된 서비스들이 더 들어가야하는 상황이라면 관련서비스들을 리소스그룹으로 묶어주는것이 더 좋은 구성이 되겠지요.
안녕하세요 제가 하고있는것과 비슷한 작업을 작성자님께서 해주셔서 이렇게 글을적습니다.
제가 하고싶은것은 node1과 node2 두개를 ha(high availability)로 엮고 node1이 down되었을경우 node2가 동작이 되게 하고싶습니다.
거기에다가 node1과 node2에 공통의 저장장치를 달지않고 각각의 저장장치에 일정시간마다 동기화 시키는 방식으로 설계하고싶은데 인터넷을 찾아본결과 drbd와 nfs등등이 있던데 어떤것을 사용하는게 좋을까요??
많이 찾아보고 시행착오를 많이 겪어보다 질문드립니다…답변 부탁드립니다.
Author
공유스토리지(SAN, iscsi 또는 NFS등으로 구성 가능)를 사용하면, 두개 이상의 서버가 동일한 디스크를 공유하게 되므로 서버단위의 장애발생시에도 크게 문제되지 않습니다. 다만 추가적으로 스토리지 장치가 필요하게 됩니다(서버나 SAN 스토리지 또는 NAS등등). 서버가 단 2대 밖에 없는경우에는 서버의 로컬디스크를 같은 내용으로 유지하면 하나의 서버가 다운되는 경우에도 디스크에는 동일한 내용이 기록되어 있게되므로 장애 발생에도 서비스에 문제가 없습니다. 이 경우에 DRBD를 구성하면 서버1, 서버2의 디스크를 네트워크를 통해 mirror 할 수 있습니다.
별도의 주기가 아니라 네트워크를 통해 실시간 동기화됩니다.
다만, 실시간 동기화가 필요없는경우(서버1, 서버2의 내용이 동일하여 거의 변화가 없는경우)에 active(서버1)-backup(서버2)으로 구성한다면 서버1과 서버2의 필요한 디렉토리를 주기적으로 복사(scp, rsync, ftp등등의 방법으로)하는 방법을 사용하시면됩니다.
서비스에 따라 필요한 방법으로 구성하시면 될것 같습니다.
drbd를 pacemaker resources에 등록하려고 하는데 혹시 등록하는 방법을 아시는지 여쭤보고 싶습니다.
인터넷을 찾아보니 drbd를 pacemaker corosync과 같은 것들을 묶어서 사용하는게 파워풀하다고 나와있어서 여쭤봅니다.
안녕하세요.
질문이 있어서 이렇게 글을 적게 되었습니다.
pacemaker에서 drbd를 resource에 넣는 방법을 찾고있는데 잘안되서 질문들 적습니다.
혹시 아시는 방법이 있다면 알려주시면 감사하겠습니다.
https://www.learnitguide.net/2016/07/integrate-drbd-with-pacemaker-clusters.html
문서를 참고해보시는것도 좋을듯 합니다.
실제로 구현해 보지는 않았습니다.
일단 답변 감사합니다.
제가 올려주신 사이트를 참고하여 resources에 추가를 진행하였더니 아래와 같이 failed라고 떠서 다시 질문드립니다.
Full list of resources:
Master/Slave Set: DrbdDataClone [DrbdData]
DrbdData (ocf::linbit:drbd): FAILED node2 (blocked)
DrbdData (ocf::linbit:drbd): FAILED node1 (blocked)
Failed Actions:
* DrbdData_stop_0 on node2 ‘not installed’ (5): call=10, status=complete, exitreason=’none’,
last-rc-change=’Wed Sep 11 09:35:42 2019′, queued=0ms, exec=554ms
* DrbdData_stop_0 on node1 ‘not installed’ (5): call=10, status=complete, exitreason=’none’,
last-rc-change=’Wed Sep 11 09:35:42 2019′, queued=1ms, exec=563ms
그리고 제가 진행하다보니 resources부분에 추가할때 다양한 옵션을 추가해서 진행하던데 그 옵션들에 대한 설명이 나와있는곳이 없더군요…그래서 혹시 그에 대한 설명을 부탁드려도 될까요??
제가 여쭤 보고 싶은게 많다 보니 정리가 안됬네요… 죄송합니다…
Author
저도 해봤는데, 비슷한 오류가 나오네요.
클러스터에서 DRBD가 정상적으로 제어가 되지 않는것 같아요.
클러스터 실행후 drbdadm status로 확인해 보면 한쪽은 정상인데, 다른쪽은 실행되지 않아서 발생하는 문제로 보입니다.
Full list of resources:
VirtualIP (ocf::heartbeat:IPaddr2): Started wolf2
WebService (ocf::heartbeat:apache): Stopped
Master/Slave Set: DrbdDataClone [DrbdData]
Masters: [ wolf1 ]
Stopped: [ wolf2 ]
DrbdFS (ocf::heartbeat:Filesystem): Started wolf1
Failed Actions:
* DrbdData_start_0 on wolf2 ‘not installed’ (5): call=19, status=complete, exitreason=”,
last-rc-change=’Sun Sep 15 10:09:12 2019′, queued=0ms, exec=167ms
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
확인을 더 해봐야겠어요.
저도 조금 더 찾아보겠습니다.
혹시 해결방법을 찾게 된다면 답변 부탁드립니다…
감사합니다.
Author
혹시 /etc/hosts 에서, virtual ip에 호스트네임 넣으셨나요?
제 경우는 클러스터가 올라가면서 호스트네임이 wolf로 바뀌면서 drbd에 문제가 생겼습니다.
그래서, virtual ip 에 호스트네임 삭제 했더니 잘 되네요.
덕분에 잘 해결되었습니다.
실례가 안된다면 제가 하나 더 묻고 싶은게 있는데요…
제가 pacemaker corosync pcs의 fail over시간을 체크하고 싶어서 이것저것 해보고 있는 중인데 잘 안되서요…혹시 지혜를 빌려주실 수 있는지 여쭤보고 싶습니다.
Author
failover 시간 체크라는 것이 어떤 의미인지요? failover에 걸리는 시간을 측정 하시려는 것인가요? 아니면 실제로 failover 에 걸리는 시간을 조정 하시려는 것인지요?
일단 첫번째로 failover에 걸리는 시간을 측정하고 첫번째가 성공된다면 두번째로 failover에 걸리는 시간을 조정하고자 합니다.
그래서 첫번째로 failover에 걸리는 시간을 측정하고자 합니다.
Author
음.. 이미 아시겠지만, 단순한 명령어라면 time 명령어를 이용해서 실행시간 측정하겠지만. 이 경우는 힘들것 같고요. 로그파일 보면서 확인해 보는 방법은 어떨지요? centos7의 경우는 /var/log/cluster, /var/log/pcsd 에 로그가 있으니 시간 확인해 보는 것은 어떨지요.
resource 별로 monitor interval, timeout을 가지므로, 적절히 조정하면 failover 시간은 조정가능할 것 같은 생각도 드네요(해 보지는 않았습니다.).
암튼, 이번 건은 별 도움이 안될 것 같은데요?
안녕하세요
pcsd + drbd 조합으로 실습중입니다. 혹시 제 문제의 해결방안을 알고 계실지도 모른다는 생각이 들어 댓글 남겼습니다.
crm_mon으로 pcsd 상태를 확인하면 아래와 같이 나옵니다.
DrbdData를 만든 후, 처음부터 저렇게 FAILED가 떠서 DrbdFS은 생성하지 않은 상태입니다.
FAILED가 뜨기 전에는, Demoting vm-test06 이라고 뜨다가, 아래와 같은 Failed Actions이 발생하면서 FAILED vm-test06 (blocked) 상태가 됩니다.
구글링을 통해 해결방안을 찾아보았지만 계속 찾지 못하여 댓글 남깁니다.
혹시 해결방법 알고 계신가요??
2 nodes configured
4 resources configured
Online: [ vm-test06 vm-test07 ]
Active resources:
VirtIP (ocf::heartbeat:IPaddr2): Started vm-test06
Httpd (ocf::heartbeat:apache): Started vm-test06
Master/Slave Set: DrbdDataClone [DrbdData]
DrbdData (ocf::linbit:drbd): FAILED vm-test06 (blocked)
Slaves: [ vm-test07 ]
Failed Actions:
– DrbdData_stop_0 on vm-test06 ‘unknown error’ (1): call=53, status=Timed Out, exitrea
son=”,
last-rc-change=’Thu Oct 17 13:59:16 2019′, queued=0ms, exec=100009ms
Author
클러스터 설정 전에 DRBD 단계부터 에러가 발생한것인가요?
위의 에러 메시지는 drbd 설정 먼저 진행해서 이상 없고, 이후 클러스터 설정단계에서
/etc/hosts 파일에서 virtual ip에 호스트네임을 설정한 경우에 발생했습니다.
# cat /etc/hosts
192.168.100.31 wolf1
192.168.100.32 wolf2
192.168.100.30 wolf —> 이 부분을 삭제하거나 주석처리 하면 에러 발생하지 않음.
같은 경우인지 확인이 필요하고요, 확인을 위해서 설정하신 /etc/hosts 파일 내용과 drbd 설정 내용을 알려주실 수 있는지요?
안녕하세요, 답변을 보기 전에 서버를 갈아엎고 다시 현재 이 글과 다음 글로 적어주신(https://blog.boxcorea.com/wp/archives/2660) 진행중에 있습니다.
DRBD만 설치하고 primary-secondary 테스트를 진행했을때는 문제 없이 primary node가 넘어갔습니다.
그런데, https://blog.boxcorea.com/wp/archives/2660 글에서
# pcs cluster cib-push drbd_cfg
# pcs status
진행시, 아래와 같은 결과를 보여줍니다.
[root@vm-test06:/]# pcs cluster cib-push drbd_cfg
CIB updated
[root@vm-test06:/]# pcs status
Cluster name: test_cluster
Stack: corosync
Current DC: vm-test06 (version 1.1.19-8.el7_6.4-c3c624ea3d) – partition with quorum
Last updated: Tue Oct 22 14:27:09 2019
Last change: Tue Oct 22 14:27:01 2019 by root via cibadmin on vm-test06
2 nodes configured
4 resources configured
Online: [ vm-test06 vm-test07 ]
Full list of resources:
VirtualIP (ocf::heartbeat:IPaddr2): Started vm-test06
WebService (ocf::heartbeat:apache): Started vm-test06
Master/Slave Set: DrbdDataClone [DrbdData]
DrbdData (ocf::linbit:drbd): Demoting vm-test06
Slaves: [ vm-test07 ]
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
위처럼 DrbdData가 demoting을 시도하다가 Failed로 아래와 같이 status가 변경됩니다.
Cluster name: test_cluster
Stack: corosync
Current DC: vm-test06 (version 1.1.19-8.el7_6.4-c3c624ea3d) – partition with quorum
Last updated: Tue Oct 22 14:29:47 2019
Last change: Tue Oct 22 14:27:01 2019 by root via cibadmin on vm-test06
2 nodes configured
4 resources configured
Online: [ vm-test06 vm-test07 ]
Full list of resources:
VirtualIP (ocf::heartbeat:IPaddr2): Started vm-test06
WebService (ocf::heartbeat:apache): Started vm-test06
Master/Slave Set: DrbdDataClone [DrbdData]
DrbdData (ocf::linbit:drbd): FAILED vm-test06
Slaves: [ vm-test07 ]
Failed Actions:
* DrbdData_demote_0 on vm-test06 ‘unknown error’ (1): call=26, status=Timed Out, exitreason=”,
last-rc-change=’Tue Oct 22 14:27:02 2019′, queued=1ms, exec=90017ms
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
현재 제 drbd 설정과 /etc/hosts는 아래와 같습니다.
[root@vm-test06:/]# cat /etc/drbd.d/cluster_disk.res
resource disk_wolf {
on vm-test06 {
device /dev/drbd0;
disk /dev/xvdb;
address 192.168.2.36:7789;
meta-disk internal;
}
on vm-test07 {
device /dev/drbd0;
disk /dev/xvdb;
address 192.168.2.37:7789;
meta-disk internal;
}
}
[root@vm-test06:/]# cat /etc/hosts
10.203.73.36 vm-test06
10.203.73.37 vm-test07
10.203.73.38 vm-test
그런데, 에러 항목이 unknown error로, not installed 에러가 아니어서 /etc/hosts 에러로는 보이지 않습니다. 혹시 해결방안 있으신가요?
Author
클러스터 구성 전에 DRBD 구성에 문제가 없었다고하면, DRBD 구성 보다는 클러스터와 연계되는 부분에서 문제가 발생하는 것으로 생각되네요.
일단, 각 노드에서 아래 명령어로 DRBD 상태를 확인해봅니다.
drbdadm status
drbdadm cstate disk_wolf
drbdadm dstate disk_wolf
양쪽 노드 모두에서 오류가 발생한것인지 아니면 한쪽은 정상인지 먼저 확인 해 보시죠.
혹시 모르니, /etc/hosts에서 vip에 할당한 호스트네임도 일단 주석 처리 해 보는것도 좋을듯 합니다.
답변 감사드립니다,
그런데 추가적으로 한 가지 더 궁금한게 있어 댓글 남깁니다.
제 현상의 문제를 생각해보면,
– DrbdData의 master가 slave로 demoting (X)
– DrbdData의 slave가 master로 promoting (X)
이렇게 나타납니다.
구글링 도중 특정 글에서 pcs 설정 전, systemctl stop drbd로 drbd 서비스를 drbd를 stop 시킨 후 적용하는 글을 보았는데, 혹시 그렇게 하셨는지 궁금합니다.
제가 drbd 설정 후 pcsd 설정을 할 때에, drbd 서비스를 켜 둔 채로 진행을 해 보았기 때문에 혹시 이 부분이 문제이지는 않을까 의문점이 듭니다.
snowffox님이 말씀해 주신 명령어는 내일 오전에 서버 접속 가능할 때에 시도해보겠습니다.
답변 감사드립니다,
그런데 추가적으로 한 가지 더 궁금한게 있어 댓글 남깁니다.
제 현상의 문제를 생각해보면,
– DrbdData의 master가 slave로 demoting (X)
– DrbdData의 slave가 master로 promoting (X)
이렇게 나타납니다.
구글링 도중 특정 글에서 pcs 설정 전, systemctl stop drbd로 drbd 서비스를 drbd를 stop 시킨 후 적용하는 글을 보았는데, 혹시 그렇게 하셨는지 궁금합니다.
제가 drbd 설정 후 pcsd 설정을 할 때에, drbd 서비스를 켜 둔 채로 진행을 해 보았기 때문에 혹시 이 부분이 문제이지는 않을까 의문점이 듭니다(drbd가 움직이지 않는 이유가 제가 pcs로 제어하지 않고, 처음에 secondary/secondary 또는 primary/secondary로 drbd를 제어해뒀던 것이 아닌가 하는 의문이 듭니다).
snowffox님이 말씀해 주신 명령어는 내일 오전에 서버 접속 가능할 때에 시도해보겠습니다.
Author
확인해 보니 아래와 같이 enable 되어 있습니다.
# systemctl status drbd
● drbd.service – DRBD — please disable. Unless you are NOT using a cluster manager.
Loaded: loaded (/usr/lib/systemd/system/drbd.service; enabled; vendor preset: disabled)
Active: active (exited) since 화 2019-10-22 10:33:20 EDT; 3min 35s ago
Process: 3016 ExecStart=/lib/drbd/drbd start (code=exited, status=0/SUCCESS)
Main PID: 3016 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/drbd.service
양쪽 모두 아래 상태(secondary)로, 사용 가능한 상태는 아닙니다.
# drbdadm status
disk_wolf role:Secondary
disk:UpToDate
drbd 리소스를 클러스터에 등록해 두었으므로,
systemctl disable drbd 하고 재부팅 후(drbd stop 상태) 클러스터 실행하면 정상적으로 잘 붙습니다.
클러스터 설정시에는 drbd stop 상태로 설정하는 것이 옳다고 생각되네요.
resource sickness에 대해서 이해가 잘 가지않는데 설명 부탁드려도 될까요??
Author
본문에 오타가 있었습니다. sickness가 아니고, stickiness로 정정했습니다. 여러 문서들에서 예로 드는 경우는 오라클인데요.
제가 이해하고 있는 바로는…
음, 예를 들어 클러스터 구성된 네트워크 스위치의 포트를 변경한다고 해 보죠. 이때 포트 변경시간 자체는 얼마 안걸릴겁니다.
그런데, 한쪽 노드의 네트워크 연결이 끊기는 경우에 장애로 인식하고 다른노드로 리소스(서비스)가 이동하는 시간이 걸립니다.
이동을 시작했는데, 네트워크가 곧 원상복구된다면 서비스는 다시 원래 노드로 되돌아오겠죠(물론 구성에 따라 원상복구는 수동으로 할 수도 있지만).
즉, 불필요한 서비스 이동이 필요하고 특히 리소스 이동시간이 오래 걸리는 경우는 서비스 정지 시간이 길어 지겠죠.
이런 경우, stickiness 값을 조정해서 리소스가 다른 노드로 즉시 이동하지 않도록 설정하는 부분이 resource stickiness 입니다.
Author
답변이 잘못되었네요. 사실 이 값을 조정함으로써 리소스가 다른 노드로 이동하는것을 방지하는 효과가 있습니다.
위 설명은 저의 이해가 잘못된것이고요.
정정하자면, 노드1의 장애시 리소스가 노드2로 넘어간 상황에서 노드1이 복구된경우 리소스가 노드1로 다시 넘어온다면 그 시간동안 서비스 정지가 발생하는데, 이 서비스 정지를 방지하기위해서 그냥 서비스가 노드2에서 계속 돌도록 하기위해 설정하는 값입니다.
기본값이 0 이고 이 경우 장애복구시 서비스가 원래 노드로 되돌아옵니다.
이 값을 크게 조정하면 장애복구에도 서비스는 원래 노드로 되돌아오지 않습니다.
pcs constraint 설명이 부족해 보입니다.
“리소스를 묶어줌으로써 해결된다” 라고 본분에 적혀 있는데
constraint 는 리소스가 기본 위치하는 score 값을 수정해서 원하는 위치로 설정하기 위한
명령어 아닌가요?
해명해주세요!
해명(?)이 될 지는 모르겠으나, 설명이 부족한것은 제 독해력, 문해력, 이해력 등등 능력이 부족하기 때문이겠지요.
좋은 지적과 설명 감사드리며, 앞으로도 잘못된 내용 있으면 지적 바랍니다.
감사합니다.
안녕하세요 너무 오래된 글이라 답변을 주실지 모르겠으나 남겨봅니다.
현재 이렇게 설정해 놓았는데요
[root@114 usr]# pcs status
Cluster name: web-cluster
Status of pacemakerd: ‘Pacemaker is running’ (last updated 2023-08-01 11:44:32 +09:00)
Cluster Summary:
* Stack: corosync
* Current DC: pcs-test-002 (version 2.1.5-9.el9_2-a3f44794f94) – partition with quorum
* Last updated: Tue Aug 1 11:44:32 2023
* Last change: Tue Aug 1 11:38:09 2023 by root via cibadmin on pcs-test-001
* 2 nodes configured
* 2 resource instances configured
Node List:
* Online: [ pcs-test-001 pcs-test-002 ]
Full List of Resources:
* Virtual_IP (ocf:heartbeat:IPaddr2): Started pcs-test-001
* webserver (ocf:heartbeat:mysql): Started pcs-test-001
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
mysql을 1번서버에서 종료해도 자동으로 2번으로 넘어가지 않아서 뭐가 잘못된건지 궁금합니다.
이렇게 넘어가지를 않고 계속 잡고있습니다.
[root@114 usr]# ip addr | grep 192.168.0.
inet 192.168.0.114/24 brd 192.168.0.255 scope global dynamic noprefixroute ens33
inet 192.168.0.120/32 brd 192.168.0.255 scope global ens33
일단 주신 정보만으로는 안되는 원인을 알기 어렵네요.
혹시 mysql을 수동으로 2번 서버로 강제 이동시키면 작동 하나요?
선생님 안녕하세요!
작성 후 늦은 댓글이라 답장이 올지 모르지만 댓글을 남겨 봅니다
구성을 하실 때 가상으로 구성을 하신 것인지, 아니면 실질적인 물리적인 서버로 구성을 한것인지 궁금합니다
가상으로 하셨다면 어떤것으로 진행을 하였는지 알 수 있을까요
Author
리눅스 kvm 가상머신을 이용했습니다. 하지만, 물리 서버나 다른 vm 환경이나 큰 차이는 없을 것으로 생각됩니다.