RHCS관련 QUORUM을 위한 심화학습

아래의 글은  RHCS 관련 Quorum을 위한 관련 내용을 소개한 글입니다.. 아래의 참조된 링크의 글입니다.

참조 : http://joonlinux.blogspot.kr/2013/04/rhcs.html



RHCS 관련 quorum 을 위한 심화 학습
 쿼럼 디바이스는 CMAN 에서 사용하는 vote 알고리즘이다. 클러스터에서 필요한 정족수(과반수)를 유지하므로써 1개의 노드만 살이있는 경우에도 서비스를 하게 해주며, 하나의 노드에서 마스터가 선출되어 스프리트 브레인이 발생하는 것을 방지해 준다.

 하지만 “쿼럼” 이 스프리트 브레인이 발생하는 상황을 방지해 주지는 못한다.
즉 별도의 하트비트 라인 같은 역활을 하지 않는 다는 것이다. 보통 RHCS 을 도입한 고객이 쿼럼 디바이스를 사용하는데 스프리트 브레인이 왜 발생하는지 물어 보는 경우가 있는데 이 것은 쿼럼의 역활을 잘못 이해하고
있는 경우이다.

쿼럼은 하트비트의 역활이 아니라 하나의 노드가 투표에서 이겨 오직 하나의 노드에서만 서비스를 띄울 수 있도록 (오직 하나의 노드에서만 Active 가 될 수 있도록) 하는 역활을 해준다.

 현재 RHCS 클러스터는 128 개의 맴버가 있을 수 있다. 하지만 qdisk 는 노드간의 I/O 경합의 문제로 16개의 맴버만 지원을 한다. 이러한 이유로 RHCS 의 구성 가능한 노드를 보통 16개로 설명한다. 쿼럼없는 경우 128개까지 가능하지만 이경우 정족수를 유지하기위해서는 과반수 이상의 서버가 구동 중이어야 한다. (물론 전체 vote 수를 조절하여 가능하지만 어떠한 경우라도 2대 이상은 살아 있어야 한다.)

 기본값:expected_votes = total_vote = nodes total votes + quorum disk votes


 쿼럼의 정족수 기능에 대한 설명

 이때 쿼럼 디바이스가 없고 전체 4개 노드가 클러스터로 구성되어 있으며 각각의 노드 vote 가 1이라면,

expected_votes = 4 = 1+1+1+1

 이 같은 경우 정족수는 3이된다. (flor(expected_votes/2)+1) 즉 최소한 3개의 노드가 살아 있어야 vote 가되며 서비스 노드가 선정될 수 있다. 그래서 하나의 클러스터만 살아도 서비스가 되어야 한다면 기본적으로 vote 를 쿼럼이 필요하게 되는 것이다. 이것을 all-but-one 상태다라고 말한다.

위의 상황에서 쿼럼을 추가한다면 쿼럼의 투표수는 기본값이 “전체 노드수 -1” 이 된다
.
 expected_votes = 7 = 1+1+1+1+3

커럼이 있을 경우 각 노드의 투표수는 1이 되어야 하므로 (3=total_vote-1)과 통일하다. 쿼럼의 투표수를 전체 노드 수와  동일하게 하면(쿼럼 투표수를 4로 한 경우) 1가 살아 있더라도 과반수를 넘게 되므로 all-but-one 상태서도 서비스가

가능하다. (flor(8/2)+1)=5) -> 쿼럼 투표수가 “4”이고 노드 하나의 투표수는 “1” 이므로
만족만일 기본값인 쿼럼 투표수인 “3”을 사용한다면 적어도 2개의 노드가 살아 있어야 클러스터 구성된다.


  하나의 노드에대해 마스터를 선출하는 방법

 클러스터내 노드간의 통신에 문제가 발생하면 클러스터는 마스터를 선출하는 과정을
거치게 된다. 기본적으로 쿼럼이 없는 환경에서 장애 노드를 클러스터에서 제거하고 남아있는 노드끼리 마스터를 선출하는 과정을 거치게되므로 문제없이 장애 조치가 진행된다.

 하지만 어쩌한 원인에 의해 클러스터내 스프리트브레인이 발생하면 각자 마스터로 인식
서비스를 구동하게 된다. 쿼럼이 있다고 하더라도 스프리트브레인을 막을 수는 없다. 다만 스프리트브레인 상태에서는 각 노드가 상대노드를 장애로 인식하기때문에

fence-race(서로 상대 노드를 빨리 죽인 노드가 최종적으로 서비스 노드가 되는 경합상태) 가 발생하게 된다.fence-race 방지하기 위해서는 쿼럼을 사용하게 된다. 쿼럼을 사용하는 경우 하나의 마스터가 선출될 수 있도록 해주기 때문이다. (물론 우선 순위가 있는 경우 틀리지만 여기에선 쿼럼 마스터 = 서비스노드 로 설명 하겠다.)


쿼럼없이 2개의 노드로 구성된 경우에서는 fence-race 를 피할 수 없다. 이경우 Redhat 에서 Fence Delay 를 이용하여 구성을 하도록 권장하고 있다.

 https://access.redhat.com/site/solutions/54829
 <cman two_node="1" expected_votes="1"/>
            <clusternodes>
                    <clusternode name="node1.cs” votes="1" nodeid="1">
                            <fence>
                                      <method name="1">
                                          <device name="node1-fence"/>
                                      </method>
                            </fence>
                    </clusternode>
                    <clusternode name="node2.cs" votes="1" nodeid="2">
                            <fence>
                                      <method name="1">
                                          <device name="node2-fence"/>
                                      </method>
                            </fence>
                    </clusternode>
            </clusternodes>
            <fencedevices>
                    <fencedevice name="node1-fence" agent="fence_ilo" ipaddr="node1-ilo" login="user" passwd="passwd" delay="10" />
                    <fencedevice name="node2-fence"  agent="fence_ilo" ipaddr="node2-ilo" login="user"  passwd="passwd" />

            </fencedevices>
            ....

* 최소한 펜싱 지연은 5초 이상으로 설정해야 한다.

 스프리트브레인을 막기위해서는 하트비트를 “single point of failure (SPOF)” 회피를 위한 다중화 구성을 통해서 가능하다.

 * RHCS 의 경우 아래와 같은 설정으로 가능하다. (RHEL 6.X 이상)
 <clusternode name="nd1" nodeid="1">
                  <altname name="nd1a" port="6809" mcast="239.192.0.2"/>
</clusternode>


 쿼럼이 없는 경우 Fence-racong 을 막는 방법을 알아 보았다. 그리고 스프리트브레인을 막기위한 방안도 함께 확인해 보았다. 이게 쿼럼을 사용하는 경우 어떠한 원리로 마스터 노드가 선정되어 확인해 보기로 하자.



 새로운 마스터를 선출하는 기술적인 방법

쿼럼의 마스터를 선출하는데 있어서 앞서 말했듯이 스코어(Score) 에 의해 결정된다. 스코어는 휴리스틱에 등록한 스코어의 총합을 말한다. 다수의 노드가 있으며 스코어가 다르다면 스코어가 높은 서버가 당연히 마스터가되므로
이해가 쉽다. 하지만 다수의 노드가  모두 동일한 스코어를 가진다면 어떨까?
 
 1) 쿼럼을 사용 중이지만 휴리스틱이 없는 경우 가 없는 경우

    maxscore = score = 1 로 세팅이 된다.
 
 2) 쿼럼을 사용 중이고 휴리스틱이 설정된 경우
 maxscore += score 로 설정된다. 휴리스틱은 모두 10개까지 등록 가능하다. 보통 노드의 가용성을 판단할 수 있는 명령어로 등록하면 된다. (ping 점검, Link 점검, SAN 점검 등등)
 등록은 엔지니어의 경험적인 명령어로 등록으로 처리한다.
 
 개인적으로는 게이트웨이로 ping, mkqdisk 명령어로 qdisk 체크 명령어 등을 등록한다. 2개모두 실패한 경우 네트워크 자원 사용 불가 및 SAN 자원 불가이므로 서비스 노드로 선출될 수 없는 노드이기때문이다. iSCSI 를 사용한다면 iSCSI 서버의 IP 도 ping 리소스에 등록해 준다.

(참고로 나는 게이트웨이 ping 점검은 불필요하다고 생각한다. HA 에서 게이트웨이의 장애를 판단할 필요는 없기때문이다. HA 리소스의 문제가 아니라 외부 문제로 FailOver 를 진행한다는 이야기인데 외부 문제가 진짜 문제인지 혹은 문제가 아닌지 HA 내에서는 판단할 근거가 없기 때문이다.)
 
 가장 우선적으로 마스터 선출(입찰)은 Score 에 의해서 판단된다. Score 은 휴레스틱 설정을 통해서 이루어 지며 각 휴레스틱의 Score 값이 높은 노드가 선출되게 된다.
 
 마스터 선정시 (마스터 선정을 노드 측에서 경매에서의 "입찰"로 설명한다.) 각 노드는 마스터가 되기위해 biding 이 붙게 된다.

 다른 노드가 낮은 ID (lowest bidding ID) 값을 가지고 있는 경우 해당 노드는 마스터 요청 중지 (입찰 중지) 하게 된다. 그리고 낮은 ID를 가진 노드가 마스터로 선출되게 된다.
 다른 노드가 모두 동의하게 되면 lowest bidding ID 노드가 마스터로 선출되게 된다. 다른 노드는 NACK 상태로
아무런 작동 하지 않게 된다. 그리고 입찰에서 마스터가 선출되지 않는다면 대기 상태로 표시되고 다음 입찰을 기다리고 있다가 마스터를 새로 선출되는 과정이 진행된다.
 
 참고) lower id 는 check_votes() 함수에서 low_id = ctx->qc_my_id 로 선언되어 있다. 즉 노드 ID 와는 무관한 값이다.마스터가 선출된 이후 장애 노드에 대한 펜싱이 진행된다.
 
 휴리스틱은 쿼럼의 마스터를 결정하기위한 방법론적 수단이다. 여러 리소스 구성 요소에 대해 확인하여 최선의 마스터를 선출하여 Active 노드로 선출한다. 다수의 노드로 구성된 경우 최선의 노드로 선정해 주기위해 시스템에 따라 설정해 준다.

 2노드 클러스터의 경우, 기본적으로 쿼럼과 휴리스틱이 불필요하다. 2노드 구성시
Fence-race 방지 설정을 해주도록 한다.  쿼럼은 구성이 가능하지만 휴리스틱은 등록할 필요가 없다.(어차피 쿼럼 마스터가 되는 서버는 둘 중 하나이다.)


쿼럼 관련 세부 시간 설정 확인

1. 쿼럼 디바이스 개괄

쿼럼 디바이스의 각 블럭별로 각 노드가 타임스템프를 찍게 된다. 이때 특정한 노드가 쿼럼 디바이스에 타임스템프를 갱신하지 못하면 오프라인으로 판단한다.

- Timestamp
- Internal state (available / not available)
- Score
- Known max score (may be used in the future to detect invalid configurations)
- Vote/bid messages
- Other nodes it thinks are online

쿼럼 디바이스는 휴리스틱 스코어에 영향을 받습니다. 휴리스틱 설정의 경우 공유 스토리지의 가용성을 점검할 수 있는 명령어를 사용하여 등록합니다.
-> 스토리지 스위치 네트워크나 네트워크 스토리지나 혹은 채널의 링크 상태 등등
위의 설명을 참고 해 주시길 바랍니다. 소인의 생각으로는 스토리지 가용성을 점검하는 방법이 가장 좋다고 아직 생각 합니다. 아래 예제와 같은 형태로 명령어를 추가적으로 사용 할 수 있을 것 같습니다.

1) ping -c 3 -i 0.5 <GATEWAY>                        # 네트워크 가용성 채크
2) mkqdisk -L <LABEL>                                        # SAN 영역 가용성 채크
3) ethtool eth0 | grep "Link detected: yes"    # 네트워크 가용성 채크
4) ls -d /usr/service                                                # 서비스 디렉토리 존재 여부
5) ls /dev/mapper/<DEVICE>                              # SAN 영역 가용성 채크


2. 마스터 선출 알고리즘

주: floor(x) 은 수학에서의 바닥함수로 x 보다 크지 않는 최대 정수 이다.

- interval :  읽기/쓰기 초 간격

- tko : 쿼럼이 죽었는지 판단하는 싸이클(반복) 횟수를 뜻한다. 해당 설정은 토큰의 타임 아웃 설정에 영향을
  미칩니다. ( 오프라인 판정: interval*tko )

- tko_up : 쿼럼이 온라인 상태인지 판단하는 싸이클(반복) 회수를 뜻합니다.
  기본값은 floor(tko/3) 입니다.

-  upgrade_wait : 휴리스틱 점수가 충분한 상태에서 마스터를 선정하는데 있어서 상태를 
  업그레이드 하는데    대기하는 싸이클 회수를 뜻한다. 기본값 "2"
  ( 0<upgrade_wait<tko )

- master_wait : 쿼럼에서 자기가 마스터로 선정된 경우 노드가 자신이 마스터 노드 인
  것으로 판단하는데 있어서 대기하는 싸이클 회수를 뜻한다.  기본값 floor(tko/2)
  ( 2<=master_wait & tko_up<master_wait<tko )

- vote : CMAN 에게 알리는 투표수입니다. 기본값: 노드수-1, 온라인 변경 가능

- min_score : 쿼럼이 살이 있다고 판단하느 최소 요구값이다. 미 설정이거나 0 인
  경우 floor((n+1)/2) 이다. 이때 n 은 휴리스틱 점수의 전체 합과 같다. 이 값은 휴레스틱
  값 의 총합보다 작아야 합니다. 만일 큰 경우에는 쿼럼을 사용하지 못함.



3. 쿼럼 관련 토템 장애 판정 시간

- 10초 이하로 장애 판정이 이루어져 페일오버되야 하는 환경에서 사용 할 수 없음. 즉 빠른 장애 복구가 필요한 경우에는 쿼럼 디바이스를 사용하는 것은 적합하지 않으므로 투표수를 조정하여 관리해야 한다.즉 99.9999% 의 가용성이 필요한 클러스터의 경우 RHCS(쿼럼)이 적당하지 않습니다.

토큰 타임 아웃 수동 설정시 참고 시간 : interval * (tko + master_wait + upgrade_wait)

토큰 타임 아웃의 경우 수동 설정시 위의 시간 식에서 산정된 시간보다 큰값을 설정해 주어야 합니다. 즉 수동 설정시 토큰 시간의 최소값은 아래와 같습니다.

토큰 타임 아웃값: interval * (tko + master_wait + upgrade_wait) +  interval * 1

위의 시간 공식을 확인해 보면 새로운 마스터 설정 시간과 연관이 있는 것을 알 수 있습니다. 즉 interval * tko 로 채크를 하며 실패시에 새로운 마스터를 선정하게 되는데
이때 upgrade_wait 와 master_wait 만큼의 싸이클 만큼 더 기다려야 마스터 노드가 Active 상태를 진행하기 때문입니다.

권장값:
token > (interval * tko) * 2

이것을 감안하여 시간을 산정하면 최소값으로 계산된 경우 마스터선정시간은 1*(5+2+2) 로 10초 가되며 페일오버 소요시간은 최소 10초 이상 된다.

레드헷의 권장값은 interval=3 입니다. 이것은 I/O가 많은 환경에서 실패를 줄이는 적정한 값이기 때문입니다.

즉 권장값을 적용하는 경우, tko 를 7으로 했을때, 마스터선출시간: 3*(7+3+2) 로 39초가 되게 된다. 매뉴얼의 문서상 tko를 10으로 기본값으로 했는데 이 값을 최소한도로 조절한다고 하였을때도 5보다 작을 경우 master_wait 이 2보다 어야 한다는 값을 만족하지 못하므로 별도로 설정하지 않는 이상 값을 더이상 줄이면 문제가 된다.


휴리스틱 관련 세부 시간 설정 확인

4. 휴리스틱 타임 아웃 관련

휴리스틱은 쿼럼 데몬에 의해서 수행됩니다. 쿼럼에 종속적이며 쿼럼의 온라인 상태를 확인합니다. 스크립트나 명령어 등을 수행하여 판단하게 되며 이 값은 명령어 완료 시간을 감안하여 설정해 주면 됩니다. 여기서 중요한 것은 쿼럼의 score 로 "1" 이 기본값입니다.

여러개의 류리스틱을 등록 하였을때 score 을 저정하게되면 min_score 에 영향을 미칠 수 있습니다. 즉 1,1,1 의 score 가 있는 경우 min_score=floor((3+1)/2)=2 이 됩니다.

따라서 1의 score 휴리스틱 한개가 실패한 경우 만족하지만 2개 이상 실패한 경우에는 min_score를 만족하지 못하여 쿼럼이 오프라인이 되게 됩니다. 따라서 1개라도 성공하면 성공으로 처리하기위해서는 min_score=1 설정을 추가해 주어야 합니다.

권고는 휴리스틱 2개 이상 등록에  min_score=1 설정 추가
쿼럼의 쓰기/읽기에 의한 점검과 휴리스틱 점검은 서로 독립적입니다. 큐디스크 데몬의 2개 의 쓰레드가 생성되며 2개가 각각 I/O 및 휴리스틱을 진행합니다.


CMAN 관련 세부 시간 설정 확인

5. CMAN 토큰 설정

토큰은 클러스터내 노드간의 통신에 사용 됩니다. 보통 쿼럼 타임아웃 값(interval*tko)의 2배로 설정을 해라고 말하는 이유는 CMAN의 quorum_dev_poll 값이 토템의 타임아웃값과 같아야 하며  쿼럼 타임아웃 값(interval*tko)이 토템 타임 아웃의 절반보다 작아야 하기때문이다.

쿼럼 타임아웃 값(interval*tko)*2<quorum_dev_poll=token

이때 이와같이 설정하는 이유는 쿼럼을 쓰기/읽기 작업을 수행 중으로 프로세스 "D" 상태에 있을 수 있기때문입니다. 이경우 헬로 메세지를 보내는데 실패하기때문에 큐디스크 데몬이 CMAN으로 헬로메세지를 보낼때 quorum_dev_poll 의 설정된 시간 이상 걸리게 되어 타임 아웃이 선언됩니다.

- token : 토큰이 유실될때의 타임 아웃 값입니다. 기본 설정된 값은 10초
  (10 마이크로세컨드) 입니다. (예제)
============================================================

<cman expected_votes="3" quorum_dev_poll="21000"/>
<totem token="21000"/>
<quorumd tko="10" interval="1" label="myqdisk" min_score="1" votes="1">
============================================================

- token_retransmits_before_loss_const : 토큰을 다시 재전송을 받을때 까지의 대기시간으로 기본값은 0.02초(20 마이크로세컨드) 입니다. 이값은 변경하는 것을 권장하지 않습니다.

- join : 노드가 클러스터에 가입을하는데 대기하는 시간입니다. 기본값은 0.06초
 (60 마이크로세컨드)

- consensus : 클러스터 노드간에 합의를 달성할때 까지 대기할 시간을 설정한다. 기본값은  4.8초 (4800 마이크로세컨드) 입니다




퍼온 사이트: http://ssambback.tistory.com/133