원문 링크:
https://access.redhat.com/articles/216443
번역문서 다운로드:
http://www.digimoon.net/docs/20140714-번역-How to Optimally Configure a Quorum Disk in Red Hat Enterprise Linux Clustering and High-Availability Environments-by_mky.pdf
Red Hat Enterprise Linux Clustering과
High-Availability의 Quorum Disk 구성 최적화
저자: John Ruemker and Lon Hohberger
편집: Allison Pranger
05/18/2011
번역: ㈜리눅스데이타시스템 문경윤
07/14/2014
개요
클러스터에는 quorum disk 추가 여부를 판단하기 위해 참고해야 할 중요 요소들이 존재합니다. 대부분의 경우, QDisk는 필수적이지 않으며 Qdisk는 부정확한 세팅으로 인한 예기치 못한 결과가 나올 가능성을 증가시키면서 구성을 복잡하게 만드는 데에 일조할 수 있습니다.
이 문서는 휴리스틱과 멀티패스를 위한 세팅을 포함하는 QDisk와 QDisk 세팅 최적화 방안에 대한 가장 일반적인 사용 사례를 기술하고 있습니다. 더 많은 정보는 아래를 참고하십시오:
• Official Product Documentation (for both Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6)
• Cluster Administration
• Cluster Suite Overview
• man qdisk
• man cman
• man cluster.conf
• man openais.conf
환경
• Red Hat Enterprise Linux 5+ Advanced Platform (Clustering and GFS/GFS2)
• Red Hat Enterprise Linux 6+ with the High Availability Add-On or Resilient Storage Add-On
QDISK 사용 사례
다음은 QDisk를 위한 전형적인 사용 사례들입니다. 몇몇 사례에서, 원하는 결과를 달성하기 위한 선택사항들이 제공됩니다.
클러스터 heartbeat과 Fencing을 위하여 분리된 네트워크를 갖는 2노드 클러스터
2노드 클러스터는 본질적으로 둘 사이의 통신이 끊어졌을 때 노드들이 각자 클러스터의 유일한 남은 멤버라고 스스로 간주하는 split-brain 시나리오에 취약합니다. 노드가 클러스터로부터 제거되어야 하는 것에 동의할 목적으로 그 노드들은 통신할 수 없기 때문에, 두 노드 모두 펜싱을 통해 다른 것을 제거 시도할 것입니다. 두 호스트가 서로 동시에 펜싱 시도하는 현상을 "fence race"라 합니다. 클러스터 통신용으로 사용하는 네트워크와 동일 네트워크 상에 fence 장치가 연결된 전형적인 환경에서 fence race가 일어날 문제는 없습니다. 왜냐하면 네트워크 연결을 잃은 그 노드는 다른 노드를 fence 할 수 없고 그러므로 race를 잃을 것이기 때문입니다. 일부 공유 펜싱 장치는 액세스를 직렬화합니다. 이는 오직 하나의 호스트만이 성공할 수 있음을 의미합니다. 그러나 노드 당 하나의 펜싱 장치가 있고 그 장치가 클러스터 통신용으로 사용되지 않는 네트워크를 통해 액세스된다면, 모든 호스트가 펜싱 리퀘스트를 동시에 보낼 잠재성이 존재합니다. 이 결과는 "fence death"라 하는데 이는 클러스터의 모든 노드가 power off되는 것입니다.
QDisk는 휴리스틱 또는 automatic master-wins mechanism으로 생존을 유지시킬 노드를 미리 결정하는 방법을 써서 이 상황에서 fence race를 처리할 수 있습니다. 그러나 Red Hat Enterprise Linux 5.6 이상, Red Hat Enterprise Linux 6.1 이상 버전에서 Red Hat은 fencing agent의 delay 옵션을 대신 사용할 것을 권장합니다. 주어진 fencing 에이전트와 더불어 delay 옵션 사용은 fence race에 구성 기반의 winner를 정의하고 이는 quorum disk보다 구성이 단순합니다.
이 환경에서, QDisk는 오직 2노드 클러스터에서만 일어나는 "fencing loops"로 알려진 문제를 예방할 수 있습니다. fencing loops는 클러스터 노드가 펜싱 후 리붓되었으나 클러스터 내부연결이 여전히 안 되기 때문에 클러스터 노드가 클러스터에 rejoin 할 수 없는 때에 발생합니다. 그러고 나서 생존 노드를 펜싱하고 리붓되는 과정이 무한반복됩니다. fencing loops 예방을 위한 대안은 chkconfig utility를 사용하여 부팅 시 클러스터 소프트웨어를 비활성시키는 것입니다.
"Last Man Standing" 기능을 요구하는 클러스터
동작 유지를 위해, Red Hat Enterprise Linux 고가용성 클러스터는 확실한 개수의 멤버 존재를 요구합니다. 클러스터가 quorum(정족수)를 갖기 위해서는 전체 vote 수의 절반보다 많은 수가 존재해야 합니다. 절반보다 적은 경우, 클러스터는 중단될 것이며 모든 클러스터 동작은 quorum이 다시 획득될 때까지 halt될 것입니다.
정전이 허용되지 않는 일부 미션 크리티컬한 환경에서 당신은 대부분의 노드가 더 이상 멤버가 아닌 성능저하 상태에서도 클러스터가 계속되기를 원할 것입니다. 쿼럼을 위한 통상 요구되는 노드 수보다 더 적은 수의 노드로도 클러스터가 정족수를 유지할 수 있도록 하는, 종종 "last man standing"이라 불리는 구성을 QDisk는 허용합니다.
이 구성을 도입 시 1차적인 약점은 수많은 케이스에서 나타나는데, 유일한 생존 노드는 장시간 성능 저하를 일으키며 로드를 적절히 핸들할 수 없다는 것입니다.
서비스 소유 노드에게 우선권을 부여하는 자격을 요구하는 클러스터
클러스터 노드 통신이 끊어진 경우, 노드가 서비스를 실행 중인 것과 같은 확실한 요인에 근거하여 결정되는 멤버쉽을 당신은 원할 수 있습니다. QDisk는 이를 노드 스코어를 결정하는 스크립트를 사용하는 휴리스틱 사용을 통하여 제공합니다.
노드 가입(join) 및 참여 자격을 요구하는 클러스터
몇몇 환경은 클러스터에 join할 수 있기 전 노드가 특별한 요구사항을 충족할 것을 필요로 할 수 있습니다. 이 요구사항은 기준 충족 여부를 체크하는 스크립트를 실행하는 휴리스틱 사용을 통해 시행될 수 있습니다. 예를 들어 클러스터가 1차적으로 고가용성 서비스 용도로 사용되는 경우, 서비스 트래픽에 이용되는 네트워크를 체크하는 것은 클러스터 join을 위한 필요조건이 될 수 있습니다.
QUORUM DISK 세팅
Qdisk는 구성하다보면 복잡해질 수 있으므로, 아래의 필수사항을 고려해야 합니다. quorum disk 사용은 공유 스토리지에 대한 동시성, 동기성, 실시간 접근성을 필요로 합니다. 대부분의 SAN 스토리지 어레이가 만족됩니다. 당신의 QDisk 타이밍은 멀티패스 장애복구를 허용해야 함에 유의하십시오.
• QDisk는 펜싱의 대체제가 아니므로 QDisk 사용 시엔 I/O 펜싱이 필요합니다. 노드들이 적시에 QDisk 업데이트를 중지할 때 QDisk 데몬은 클러스터로부터 노드를 제거하기 위해 클러스터 펜싱 메커니즘을 사용합니다.
• quorum disk로 사용되는 LUN에 deadline scheduler를 사용할 것을 Red Hat은 권장합니다.
• 모든 종류의 분산 또는 복제 스토리지 상단에서 QDisk를 사용하는 것은 지원되지 않습니다.
• QDisk와 결합되어 사용될 시 multipath는 더 긴 클러스터 타임아웃을 요구합니다. (더 많은 정보를 위해 멀티패스 구성 설정을 참고하십시오.)
QDisk와 CMAN 구성 설정
Qdisk를 사용하는 클러스터 구성의 기본 구조는 아래와 같으며 설정 권장사항을 따릅니다.
NOTE: Red Hat Enterprise Linux 6.1부터는 많은 설정이 cluster.conf의 값을 기준으로 자동 계산됩니다. Red Hat Enterprise Linux 6.1 이상에서 당신이 클러스터를 deploy한다면, 자동 계산 설정을 변경하기 보다는 token timeout 완성에 집중할 것을 Red Hat은 권장하는데 이는 아래 이탤릭체의 파라미터를 포함합니다. 또한 휴리스틱 없는 2노드 클러스터 실행 시, master_wins 속성은 qdiskd에 의해 자동 활성됩니다.
|
<cluster alias="mycluster" config_version="1" name="mycluster"> <!-- In Red Hat Enterprise Linux 6.1, votes is assumed to be 1 if not present. --> <clusternode name="node1.example.com" votes="1" nodeid="1"> <fence> <method name="1"> <device name="node1-fence"/> </method> </fence> </clusternode> <clusternode name="node2.example.com" votes="1" nodeid="2"> <fence> <method name="1"> <device name="node2-fence"/> </method> </fence> </clusternode> </clusternodes> <!-- In Red Hat Enterprise Linux 6.0 and later, the quorum_dev_poll parameter is automatically set to the token timeout and does not need to be set in cluster.conf. --> <cman expected_votes="3" quorum_dev_poll="21000"/> <!-- In Red Hat Enterprise Linux 6.1 and later, interval, tko, and votes are automatically calculated based on information already in cluster.conf. --> <quorumd label="myQDisk" interval="1" tko="10" min_score="1" votes="1"> <!-- In Red Hat Enterprise Linux 5.6 and 6.0 (and later), the interval and tko values are automatically calculated based on the quorumd interval and tko values. --> <heuristic program="ping -c1 -w1 192.168.2.1" score="1" interval="2" tko="4" /> </quorumd> <totem token="21000"/> <fencedevices> [...] </fencedevices> </cluster> |
이 설정을 구성할 때, 아래의 권장사항을 고려하십시오.
• totem token 값은 quorumd tko*interval 값의 2배보다 커야 합니다. 위 예에서는, quorumd는 10초의 tko*interval을 가지므로 totem token은 21000ms (21s)입니다. totem token 값은 quorumd interval 값과 같은 다른 값이 seconds 단위인 것과는 달리 milliseconds 단위입니다.
• CMAN의 quorum_dev_poll은 totem token과 같아야 합니다.
• 사용 중인 휴리스틱은 tko*interval보다 낮거나 quorumd interval*(tko-1)과 동일해야 합니다. 위 예에서, quorumd는 interval*(tko-1) 공식에 의해 2*(2-1)=2이며 2 seconds가 heuristic(tko defaults는 1)을 위한 interval로 선택됩니다.
• cman tag를 위한 expected_votes 값은 총 클러스터 노드 수의 2배에서 1을 뺀 값과 같아야 합니다.
• cman tag를 위한 two_node 값은 0이거나 존재하지 않아야 합니다.
• quorumd tag를 위한 vote 값은 총 클러스터 노드 수에서 1을 뺀 값과 같아야 합니다.
• 각 클러스터 노드는 1개의 vote를 가져야 합니다.
Configuration Settings for Multipath
클러스터에서 quorum을 받쳐주기 위한 QDisk 사용 시, device-mapper-multipath는 여분의 장치 보완 용도와 단일 지점 장애를 피하기 위한 용도로 종종 유용합니다. 그러나 당신은 몇몇 세팅을 조절할 필요가 있으므로 QDisk와 CMAN은 노드를 제거하기 전 다른 경로로 장애조치하기 위한 충분한 시간을 멀티패스 장치에 줍니다.
대개, 멀티패스 장치를 사용하는 클러스터 설정을 위한 2개의 전략이 있습니다.
• 장애조치 시간 최소화: 구성된 서비스를 동등하게 실행할 수 있는 다중 노드가 있고 노드 장애가 일어났을 때 리소스가 중요한 딜레이나 페널티를 입지 않을 클러스터를 위해, 당신은 멀티패스 장치가 장애조치되기 위한 대기를 원하지 않을 것입니다. 대신, 더 길게 기다려서 그것을 복구할 수 있는지 여부에 관계없이 당신은 클러스터 세팅을 설정할 수 있으므로 클러스터는 가능한 한 빠르게 노드를 장애 처리합니다. 이런 클러스터 종류를 위해, 당신은 멀티패스 경로를 장애조치하는 데에 얼마나 시간이 걸리는지 일반적으로 고려할 필요 없습니다; QDisk와 클러스터 세팅은 일반적으로 구성될 수 있습니다. (QDisk와 CMAN 섹션을 위한 환경 설정을 보십시오) 만약 노드의 스토리지가 문제를 보인다면, 노드는 quorumd interval * tko seconds를 기다린 뒤 단순하게 제거될 것이고, 클러스터는 작업을 다시 시작할 것입니다.
• 복구 시간 허용: 몇몇 클러스터에서, 노드 실패는 매우 손실이 크고 그것이 자동 복구를 빠르게 하여 정리될 때까지 피해야 합니다. 이 환경에서, 당신은 구성을 조절할 수 있으므로 클러스터는 노드를 제거하기 전 multipath 장치가 다른 active 경로로 장애조치하기 위한 충분한 시간을 기다릴 것입니다.
스토리지 장치가 실패할 수 있으므로 멀티패스 장애조치에 얼마나 긴 최대시간을 줄 것인지 당신은 첫번째로 결정해야 합니다. 멀티패스 장애조치 시간은 각 환경에서 변경될 수 있고, 그러므로 그것은 다른 실패 시나리오 없이 정의되기가 쉬울 수 없습니다. 많은 상황에서, 이 경로 실패는 QDISK를 위한 어떤 I/O 지연을 피하면서 빠르게 일어날 수 있습니다. 그러나 스토리지 타겟 또는 스위치가 응답하지 않는 다른 상황에서 I/O를 대기하는 동안 QDisk 타이밍이 아웃되는 결과를 내며 다른 경로로 장애조치 되기까지 수 분이 걸릴 수 있습니다.
일단 실패되는 데 스토리지 장치가 쓰는 시간의 정확한 이해를 달성하면, QDisk 세팅은 그에 따라 조정될 수 있습니다.
• 만약 멀티패스 장치가 다음 활성 경로로 전환되는 데에 항상 충분히 긴 시간을 기다려야 한다면, quorumd settings interval * tko 곱은 멀티패스 장애조치 시간보다 더 큰 값이 되어야 합니다.
|
<quorumd label="myqdisk" min_score="1" interval="2" tko="10"> <heuristic [...] /> </quorumd> |
• totem token과 cman quorum_dev_poll 세팅은 이 신규 interval과 tko 세팅에 기초한 QDisk와 CMAN 섹션을 위한 구성 설정 가이드라인을 사용하면서 조정되어야 합니다.
NOTE: Red Hat Enterprise Linux 5.5에서, 클러스터 장애조치 시간은 버그 픽스:
https://bugzilla.redhat.com/show_bug.cgi?id=544482 때문에 3 * token 증가할 것입니다. 만약 당신이 totem token을 x * 2.7(x = multipath failover)로 세팅한다면, 클러스터 장애조치 시간은 약 x * 2.7 * 3이 될 것입니다. 이 경우, 클러스터는 노드를 fence할 것이고 노드를 실패 후 약 x * 2.7 * 3 시점에 서비스를 시작할 것입니다. 만약 x가 30s라면, 클러스터 장애조치 시간은 30s x 2.7 x 3 = 243s > 4 minutes입니다. 더 많은 정보를 위해, 다음 기사를 참고하십시오: Why does it take so long (4+ minutes) before the other node is fenced in my Red Hat Enterprise Linux 5.5 cluster?
Heuristics
휴리스틱은 노드에 대한 효과적인 적합성 검사입니다. 휴리스틱의 모든 총 스코어 값은 함께 추가되고, 만약 그들이 최소 필요 스코어를 만난다면, 그 노드는 클러스터에 참가를 계속합니다. 만약 모든 스코어의 총합이 최소 스코어 이하로 떨어진다면, 노드는 클러스터로부터 자신을 제거합니다. (보통 리붓에 의해)
아래는 몇몇 보통의 휴리스틱과 사용 예입니다.
Ping
Ping은 크리티컬 네트워크 리소스에 더 이상 접근할 수 없을 때 전형적으로 클러스터를 제거하기 위해 사용됩니다. 예를 들면, 만약 클라이언트 요청이 192.168.2.1 어드레스와 함께 라우터를 통해 들어온다면, 당신은 라우터가 ping 처리를 할 수 있는지 없는지 체크하기 위해 ping 휴리스틱을 사용할 수 있습니다. 만약 라우터가 ping 처리를 할 수 없다면, 추측하건대 로컬 실행 중인 어떤 서비스는 클라이언트를 사용할 수 없고, 당신은 클러스터로부터 그것을 제거할 수 있습니다.
SAN 연결
QDisk는 몇몇 함축적인 스토리지 모니터링을 제공합니다. 예를 들면, 만약 호스트가 갑자기 quorum 디스크에 접근할 수 없다면, 그것은 다른 클러스터 멤버에 의해 클러스터로부터 제거될 것입니다. 그러나, SAN 연결 휴리스틱은 오직 quorum 디스크로 향하는 경로만을 모니터합니다. 몇몇 케이스에서, 게다가 그것은 다른 장치를 모니터링하기 위한 휴리스틱을 갖는 데 유용할 수 있습니다.
네트워크 연결
몇몇 환경에서, ping보다 하위 레벨에서는 네트워크 연결 모니터링을 이해하지 않을 수 있습니다. 대신, 당신은 Red Hat Enterprise Linux에 포함된 툴을 사용함으로써 위 레벨에서 네트워크 연결을 모니터링하기 위한 휴리스틱 사용을 원할 수 있습니다(예를 들면, 이더넷 또는 인피니밴드 링크 상태).
REFERENCES AND RELATED DOCUMENTATION
• Architecture Review Process for Red Hat Enterprise Linux High Availability, Cluster, and GFS
• Can I Change the I/O Scheduler for a Particular Disk Without the System Rebooting?
• Delaying Fencing in a Two-Node Cluster
• Is an EMC PowerPath-Managed LUN Supported for Use as a Quorum Device on Red Hat Enterprise
Linux Cluster and High Availability?
• Red Hat Enterprise Linux Cluster, High Availability, and GFS Deployment Best Practices
• Unresponsive Storage Device Leads to Excessive SCSI Recovery and device-mapper-multipath
Failover Times in Red Hat Enterprise Linux
• device-mapper-multipath on Red Hat Enterprise Linux 5 Experiences Excessive Delay in Detecting a Lost Path from a Storage Failure that Produces No RSCN or Loop/Link Error
• How Can I Improve the Failover Time of a Faulty Path when Using device-mapper-multipath Over iSCSI?
