리눅스 HA(corosync, pacemaker) – Part 1

리눅스 HA 구성(CentOS7, corosync, pacemaker 이용)

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화일에 아래 내용을 등록.

2. corosync, pacemaker 설치(양쪽 노드)
corosync, pacemaker를 양쪽 노드 모두 설치해준다. 여기서는 yum을 이용해 rpm 패키지로 설치한다.

3. selinux, 방화벽(iptables)설정
selinux와 방화벽은 사용하지 않음으로 미리 설정했다. 혹시 방화벽을 사용한다면, TCP 포트 2224, 3121, 21064 그리고 UDP 포트 5405를 열어주어야 한다.

4. 설정
양쪽 노드 모두에서 pcs 데몬을 실행한다. (참고로, 옛날버전에서는 crm을 사용했었다) 이 데몬은 pcs 커맨드라인 인터페이스와 함께 모든 클러스터 노드에서 구성을 동기화하는 일을 한다.

양쪽노드에서 pcsd를 실행하고, (재부팅시 자동으로 실행되도록) 서비스를 enable 시킨다.

양쪽노드에서, (자동으로 생성된) hscluster 계정의 비밀번호를 양쪽 동일하게 설정한다.

corosync를 설정한다.
한쪽 노드에서 아래 커맨드로 hacluster 사용자로 인증한다.

한쪽 노드에서 아래 커맨드로 corosync를 구성하고 다른 노드와 동기화한다.

5. 클러스터 실행과 상태 확인

아래 커맨드로 클러스터를 실행한다.

클러스터 통신을 확인한다.

멤버쉽과 쿼럼을 확인한다.

6. Active/Passive 클러스터 생성

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

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

가상 IP 리소스 생성
아래 명령어로 가상아이피를 리소스로 추가한다. 가상아이피는 노드가 다운되면 다른 노드로 이동하며, 실제로 서비스에 이용되는 IP 주소로 이용한다.

클러스터 상태를 확인해 보면, 리소스리스트에 VirtualIP가 추가된 것을 볼 수 있고, ip 주소를 확인해보면, 설정한 아이피주소가 나타남을 확인 할 수 있다.

위에서 추가한 리소스 VirtualIP는 세 부분 ocf:heartbeat:IPaddr2 의 형태로 구분했다. 여기에서, 첫번째 필드는 resource standard 두번째 필드는 표준에 따라 다르며 세번째 필드는 리소스 스크립트의 이름이다.
리소스 standard는 다음 명령어로 확인 가능하다.

위 결과에서 각각의 의미는 다음과 같다.
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의 리소스 프로바이더는 아래 커맨드로 확인가능하다

세번째 필드인 리소스 스크립트는 아래처럼 확인 가능하다.

이제, wolf1 을 정지시켜 failover를 확인해본다.

wolf2 에서 클러스터 상태를 확인해 보면,

wolf1에서 클러스터를 다시 실행해도, 리소스는 wolf1으로 돌아오지 않는다.

resource sickness – 자원의 이동에는 대부분 가동중지 시간이 필요하며, 데이타베이스처럼 복잡한 서비스는 이 시간이 길어질 수 있다. 이 문제를 해결하기위해서 pacemaker에서 제공하는 개념이 리소스 stickness. 기본값은 0 이지만, 이 숫자를 늘여서 서비스가 이동하는 것을 제어할 수 있다.

7. 클러스터 서비스로 아파치 웹서버 등록하기
설치는 양쪽 노드에 아래 커맨드로 설치한다. wget은 서비스 상태를 모니터링하기 위해 설치한다.

설치를 마친후 /var/www/html/index.html 화일을 만든다.
/etc/httpd/conf.d/status.conf 화일에 아래 내용을 입력한다(양쪽 노드 모두).

아래커맨드로 리소스를 등록한하고 확인한다.

위의 상태를 보면, 가상ip주소는 wolf1에, 웹서비스는 wolf2에서 실행되고 있음을 볼 수 있다. 이 문제는 colocation constraint 두 리소스를 묶어줌으로써 해결된다.

이제 확인해보면 두 리소스 VirtualIP, WebService가 같은 노드에서 실행되고 있음을 볼 수 있다.

만약 어떤 서비스가 먼저 실행되고 난 이후 서비스가 실행되어야 할 필요가 있을때는 아래와 같은 방법을 사용한다. 아래는 VirtualIP가 먼저 실행된 후 WebService가 실행되도록 한다.

Pacemaker는 두 노드의 하드웨어사양이 동일할 필요가 없기 때문에, 보다 강력한 노드에서 서비스를 실행하도록 하는 것이 가능하다. 이는 constraint location을 지정함으로써 가능하다.

8. 수동으로 리소스 강제 이동하기
리소스를 강제로 다른 노드로 이동하기 위해서는 constraint location의 스코어를 INFINITY로 변경하면된다. 아래는 WebService 리소스를 wolf2 노드로 강제 이동하는 명령어이다.

constraint location 삭제는 아래와 같이 할 수 있다.
현재의 constraint를 확인하고,

id를 확인하고, remove 한다.

* 2019.10.17 아래내용 추가.
늦었지만, 리눅스 HA(corosync, pacemaker, DRBD) – Part 2로 이어집니다.

23 comments

Skip to comment form

  1. 위 처럼 HA 구성한 것은 Cluster개념은 아니죠?
    storage 하나를 두고 서버 두개 운용하는 방법은 아닌거죠?

    1. 제가 구성한것에서는 shared storage가 빠져 있습니다. 다만, shared storage 붙여서 active/passive, active/active 구성도 가능합니다.

  2. 좋은 글 감사합니다. 한가지 궁금한 것이 있는데요.

    Standby –> Active로 구성될 때..
    별도의 서비스 모듈(데몬)을 실행하기 위해서는 어떻게 해야 하나요?

    1. 제가 작성한 글에서는 apache를 예로 들었습니다. 양쪽 노드에 apache를 설치하고 테스트 했습니다.

      Standby->Active란 것이 failover 발생후 원상 복구를 의미하는 것인지요? 이 경우는 제 글의 8번 항목을 참고하시면 될 것 같습니다.

      그것이 아니라, 특정한 서비스를 등록하는 것을 의미하는 것이라면 서비스 등록문제는 리소스 스크립트가 제공되는 서비스는 특별한 문제는 없을 것으로 생각됩니다. 다만, 제공되지 않는다면 스크립트를 만들거나 제공되는 스크립트를 수정해야 합니다. 그리고 서비스가 실행되는것은, pcs cluster start –all 명령어에 의해 등록된 서비스가 자동으로 실행됩니다. 물론 이때 만들거나 수정한 스크립트라면, 서비스 시작/정지 스크립트가 이상이 없이 잘 작동해야 합니다. 즉, 원하는 서비스를 클러스터에 리소스 등록하면, 원하는 서비스의 시작/정지는 클러스터가 알아서 실행하는 것이지요.
      답변이 되었나 모르겠네요..

    • kbg on 2018년 8월 24일 at 3:12 오후
    • Reply

    글 잘 보았습니다.

    위 구성에 스토리지 한대를 추가해서 2개의 노드가 한개의 스토리지를 바라볼수 있게

    멀티패스 구성에 대해서 어찌 하는지 궁급합니다.^^

    1. 공유스토리지를 서버 1, 2에 모두 할당하고, pcs clvm으로 구성했던것으로 기억합니다. active-passive인 경우는 lvm 만으로도 가능할거예요.
      이거 오래전에 했던거라서…
      part 2에서 정리하려고 했었는데, 이런저런 사정으로 part2를 못만들었네요.

    • hkk1465 on 2018년 12월 9일 at 8:27 오후
    • Reply

    리소스 그룹으로 vip 와 webservice 를 묶는 것과 위 설정 하신것과의 차이 점이 있을까요?

      • snowffox on 2018년 12월 11일 at 10:07 오전
      • Reply

      위의 구성은 단순하게 웹서비스만 돌려보는것이라서 별 문제가 없지만,
      위의 구성에 공유스토리지, 데이타베이스 등등 서로 연관된 서비스들이 더 들어가야하는 상황이라면 관련서비스들을 리소스그룹으로 묶어주는것이 더 좋은 구성이 되겠지요.

    • hahagoshipda on 2019년 7월 3일 at 7:49 오후
    • Reply

    안녕하세요 제가 하고있는것과 비슷한 작업을 작성자님께서 해주셔서 이렇게 글을적습니다.
    제가 하고싶은것은 node1과 node2 두개를 ha(high availability)로 엮고 node1이 down되었을경우 node2가 동작이 되게 하고싶습니다.
    거기에다가 node1과 node2에 공통의 저장장치를 달지않고 각각의 저장장치에 일정시간마다 동기화 시키는 방식으로 설계하고싶은데 인터넷을 찾아본결과 drbd와 nfs등등이 있던데 어떤것을 사용하는게 좋을까요??
    많이 찾아보고 시행착오를 많이 겪어보다 질문드립니다…답변 부탁드립니다.

    1. 공유스토리지(SAN, iscsi 또는 NFS등으로 구성 가능)를 사용하면, 두개 이상의 서버가 동일한 디스크를 공유하게 되므로 서버단위의 장애발생시에도 크게 문제되지 않습니다. 다만 추가적으로 스토리지 장치가 필요하게 됩니다(서버나 SAN 스토리지 또는 NAS등등). 서버가 단 2대 밖에 없는경우에는 서버의 로컬디스크를 같은 내용으로 유지하면 하나의 서버가 다운되는 경우에도 디스크에는 동일한 내용이 기록되어 있게되므로 장애 발생에도 서비스에 문제가 없습니다. 이 경우에 DRBD를 구성하면 서버1, 서버2의 디스크를 네트워크를 통해 mirror 할 수 있습니다.
      별도의 주기가 아니라 네트워크를 통해 실시간 동기화됩니다.
      다만, 실시간 동기화가 필요없는경우(서버1, 서버2의 내용이 동일하여 거의 변화가 없는경우)에 active(서버1)-backup(서버2)으로 구성한다면 서버1과 서버2의 필요한 디렉토리를 주기적으로 복사(scp, rsync, ftp등등의 방법으로)하는 방법을 사용하시면됩니다.
      서비스에 따라 필요한 방법으로 구성하시면 될것 같습니다.

    • nanclab on 2019년 9월 3일 at 2:08 오후
    • Reply

    drbd를 pacemaker resources에 등록하려고 하는데 혹시 등록하는 방법을 아시는지 여쭤보고 싶습니다.
    인터넷을 찾아보니 drbd를 pacemaker corosync과 같은 것들을 묶어서 사용하는게 파워풀하다고 나와있어서 여쭤봅니다.

    • hahegi on 2019년 9월 4일 at 6:05 오후
    • Reply

    안녕하세요.
    질문이 있어서 이렇게 글을 적게 되었습니다.
    pacemaker에서 drbd를 resource에 넣는 방법을 찾고있는데 잘안되서 질문들 적습니다.
    혹시 아시는 방법이 있다면 알려주시면 감사하겠습니다.

      • snowffox on 2019년 9월 10일 at 10:20 오전
      • Reply

      https://www.learnitguide.net/2016/07/integrate-drbd-with-pacemaker-clusters.html
      문서를 참고해보시는것도 좋을듯 합니다.
      실제로 구현해 보지는 않았습니다.

        • hahegi on 2019년 9월 11일 at 5:57 오후
        • Reply

        일단 답변 감사합니다.
        제가 올려주신 사이트를 참고하여 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부분에 추가할때 다양한 옵션을 추가해서 진행하던데 그 옵션들에 대한 설명이 나와있는곳이 없더군요…그래서 혹시 그에 대한 설명을 부탁드려도 될까요??
        제가 여쭤 보고 싶은게 많다 보니 정리가 안됬네요… 죄송합니다…

  3. 저도 해봤는데, 비슷한 오류가 나오네요.
    클러스터에서 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

    확인을 더 해봐야겠어요.

      • hahegi on 2019년 9월 16일 at 12:32 오후
      • Reply

      저도 조금 더 찾아보겠습니다.
      혹시 해결방법을 찾게 된다면 답변 부탁드립니다…
      감사합니다.

      1. 혹시 /etc/hosts 에서, virtual ip에 호스트네임 넣으셨나요?
        제 경우는 클러스터가 올라가면서 호스트네임이 wolf로 바뀌면서 drbd에 문제가 생겼습니다.
        그래서, virtual ip 에 호스트네임 삭제 했더니 잘 되네요.

          • hahegi on 2019년 9월 17일 at 7:30 오후
          • Reply

          덕분에 잘 해결되었습니다.
          실례가 안된다면 제가 하나 더 묻고 싶은게 있는데요…
          제가 pacemaker corosync pcs의 fail over시간을 체크하고 싶어서 이것저것 해보고 있는 중인데 잘 안되서요…혹시 지혜를 빌려주실 수 있는지 여쭤보고 싶습니다.

            • snowffox on 2019년 9월 18일 at 8:12 오전
              Author

            failover 시간 체크라는 것이 어떤 의미인지요? failover에 걸리는 시간을 측정 하시려는 것인가요? 아니면 실제로 failover 에 걸리는 시간을 조정 하시려는 것인지요?

            • hahegi on 2019년 9월 18일 at 9:37 오전

            일단 첫번째로 failover에 걸리는 시간을 측정하고 첫번째가 성공된다면 두번째로 failover에 걸리는 시간을 조정하고자 합니다.
            그래서 첫번째로 failover에 걸리는 시간을 측정하고자 합니다.

            • snowffox on 2019년 9월 19일 at 8:15 오후
              Author

            음.. 이미 아시겠지만, 단순한 명령어라면 time 명령어를 이용해서 실행시간 측정하겠지만. 이 경우는 힘들것 같고요. 로그파일 보면서 확인해 보는 방법은 어떨지요? centos7의 경우는 /var/log/cluster, /var/log/pcsd 에 로그가 있으니 시간 확인해 보는 것은 어떨지요.

            resource 별로 monitor interval, timeout을 가지므로, 적절히 조정하면 failover 시간은 조정가능할 것 같은 생각도 드네요(해 보지는 않았습니다.).

            암튼, 이번 건은 별 도움이 안될 것 같은데요?

    • gugugu on 2019년 10월 17일 at 2:12 오후
    • Reply

    안녕하세요
    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

    1. 클러스터 설정 전에 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 설정 내용을 알려주실 수 있는지요?

댓글 남기기

Your email address will not be published.

%d 블로거가 이것을 좋아합니다: