Pacemaker OVerview

Pacemaker는 오픈 소스 소프트웨어 (OSS)로 개발되어, HA 클러스터 소프트웨어입니다. 이전에는 'Heartbeat'라는 이름으로 개발 된 소프트웨어의 후속입니다.

HA 클러스터는 여러 대의 컴퓨터를 연결 전체에서 하나의 컴퓨터처럼 대접하는 것으로, 시스템 전체의 가동률을 높이는 기술입니다. 
HA는 "High Availability"(= 고 가용성)의 약자로 말 그대로 가용성 (*)가 높은 상태를 나타냅니다. * 가용성은 고장 등을 포함한 시스템이 어떻게 멈추지 않고 가동하고 있는지의 정도.

Pacemaker는 여러 대의 컴퓨터를 NW 등으로 연계하여 고장을 감지 한 후 다른 컴퓨터에 자동적으로 대납 (장애)시키는 등 '고 가용성'을 제공합니다.

Contents [ hide ]

• 1 Pacemaker의 기능과 대응 가능한 고장
• 2 일반적인 클러스터 구성
• 3 Pacemaker와 가동률
• 4 Pacemaker 버전의 선택
• 5 자원 및 자원 에이전트
• 6 좌우 분열과 배타 제어
• 7 리스트

Pacemaker의 기능과 대응 가능한 고장

Pacemaker는 크게 다음 다섯 가지 기능을 가지고 있습니다. 
이렇게하면 서버에서 발생할 수있는 대부분의 고장에 있습니다.

• 응용 프로그램 모니터링 및 제어 기능
  • Apache, nginx, Tomcat, JBoss, PostgreSQL, Oracle, MySQL, 파일 시스템 관리, 가상 IP 주소 제어 등 많은 리소스 에이전트 (RA)를 포함하고 있습니다. 또한 RA를 자작하면 어떤 응용 프로그램에서도 모니터링 할 수 있습니다.
• 네트워크 모니터링 및 제어 기능
  • 정기적으로 지정된 대상에 ping을 전송하여 네트워크 연결 상태를 모니터링 할 수 있습니다.
• 노드 모니터링 기능
  • 정기적으로 서로 하트 비트 통신 노드 모니터링을합니다. 또한 STONITH 기능은 통신 불가능한 상태가 된 노드의 전원을 강제로 중지하고 양계 상태 (split-brain)를 피할 수 있습니다.
• 자기 감시 기능
  • Pacemaker 관련 프로세스를 종료 할 때 영향 정도에 따라 적절한 프로세스를 재시작하거나 장애를 실시합니다. 또한 watchdog 기능을 함께 사용하여 메인 프로세스 정지시 자동으로 OS 재시작 (및 장애)를 실행합니다.
• 디스크 모니터링 및 제어 기능
  • 지정된 디스크 읽기를 정기적으로 실시하고 디스크 액세스 상태를 모니터링합니다.

다음 공유 디스크 구성 Pacemaker가 대응할 수있는 고장 부분의 이미지입니다. (×의 개소의 고장에 대응할 수 있습니다.)

일반적인 클러스터 구성

Pacemaker는 다양한 구성의 HA 클러스터에 대응하고 있습니다.

대체적으로 "데이터의 인계 방법"및 "노드 대수」에 따라 클러스터 구성을 분류 할 수 있습니다. 
다음에 Pacemaker가 대응 가능한 클러스터 구성을 보여줍니다.

데이터 인계 방법에 따른 분류

• 공유 구성
  • 두 노드 모두에서 액세스 할 수있는 공유 디스크를 이용해 데이터를 통해 구성입니다. 옛부터 많은 시스템에서 사용되는 가장 일반적인 구성입니다.
• 비공유 구성 (PG-REX / DRBD 이용)
  • 공유 디스크는 사용하지 않고 소프트웨어로 데이터 복제 기능을 사용하여 데이터를 통해 구성입니다.Pacemaker는 PostgreSQL의 스트리밍 복제 기능 에 의한 PG-REX 구성 , 그리고 DRBD 를 이용한 구성에 대응하고 있습니다. 비싼 공유 디스크가 필요하지 않기 때문에 저렴하게 시스템을 구축 할 수 있습니다.

 

노드 대수에 따른 분류

• 1 + 1 구성
  • 2 대의 서버를 Active 서버와 Standby 서버로, Active 서버의 고장시 Standby 서버로 장애를 구성합니다.많은 시스템에서 사용되는 가장 일반적인 구성입니다.
• N + 1 구성
  • N 대 (2 대 이상) 서버를 Active 하나를 Standby로 각 Active 서버의 고장시에는 하나의 Standby 서버에 장애 구성입니다. Standby 서버를 통합함으로써 서버 활용도를 높이고 낭비를 최소화합니다. 여러 대의 고장시에는 하나의 Standby 여러 서비스를 실행하는 축퇴 운전입니다. (*)
• N + M 구성
  • N 대의 서버를 Active, M 대의 서버를 Standby로 구성되어 있습니다. Pacemaker-1.1 이후에 대응했습니다. 서버 가동률과 타락한시 성능 저하의 균형에 의해 임의의 대수로 구성 할 수 있습니다.

(*) Pacemaker-1.1 이후로는 두 번째 이후의 장애를 억제하는 설정도 가능합니다.

Pacemaker와 가동률

Pacemaker는 장애시 해당 자원의 중지, 시작을 실행합니다. 
응용 프로그램에 따라 다르지만 대체로 수십 초에서 몇 분에 장애가 가능합니다.

따라서 Pacemaker는 대체로 ~ 99.999 %의 가동률 (* 1)를 실현 가능 (* 2)입니다. 
99.9999 %는 고장 패턴에 따라 초과 할 수 있습니다.

* 1 일정 기간 동안 시스템이 실행되는 시간의 비율. 가용성의 지표가된다. 
* 2 어디 까지나 년에 1 ~ 2 회 고장이 발생한다고 가정했을 경우의 기준입니다. 자원 구성, 애플리케이션, 고장 발생 빈도 등에 의해 실현 될 수없는 경우도 있습니다.

다음에 가동률과 구체적인 가동 시간 (연간) Pacemaker에서의 대응 여부를 정리해 보겠습니다.

가동률 [%]	허용되는 연간 정지 시간	실현 방법 이미지
99	약 3.6 일	이상이 있으면 메일이 발송되며 운영자가 달려 대응 정도로 OK
99.9	약 8.7 시간	운영자가 가까이 있으면 좋지만, 먼 곳이라 어려울지도. 수동도 좋지만, Pacemaker 가 갖고 싶어 나 할까.
99.99	약 52 분	상용 시스템은 대체로이 정도를 요구 되는가? Pacemaker 에 대응 가능.
99.999	약 5 분	이른바 파이브 나인. Pacemaker 에 대응 가능.
99.9999	31 초	자원 구성 고장 패턴에 따라 어떻게 든 Pacemaker에 대응할 수있는 ...? 하드웨어 및 가상 머신 레벨에서 FT (내결함성)도 원하는 곳.

Pacemaker 버전의 선택

Pacemaker는 크게 "리소스 제어 기능" 과 "클러스터 제어 기능" 의 2 개의 내부 구성 요소가 나누어 져있어 각각 선택 결합 할 수 있습니다.

각각 메이저 버전의 차이도 포함 해 다음 옵션이 있습니다.

리소스 제어 기능

• Pacemaker 1.0 계
• Pacemaker 1.1 계 (최신)

클러스터 제어 기능

• Heartbeat 3 계
• Corosync 1 계
• Corosync 2 계 (최신)

한마디로 Pacemaker해도 위 2 × 3 = 6 개의 조합이 존재하는 것입니다.

구성 요소와 버전이 다르면 당연히 조작 방법이나 행동이 조금씩 달라집니다. 
동안 안정된 동작을하지 or 원래 지원되지 않는 조합도 있습니다.

Linux-HA Japan 커뮤니티로는 다음 2 패턴의 조합을 권장하고 있습니다.

• 추천 조합 1 : OS, 미들 버전 모두 현재를 사용할 수있는 사람을위한
  • 리소스 제어 기능 : Corosync 2 계
  • 클러스터 제어 기능 : Pacemaker 1.1 계
    • 대응 OS : RHEL6.X 및 RHEL7.X (포함 RHEL 클론 OS)
    • 2014 년 12 월에이 조합의 저장소 패키지를 릴리스했습니다.
    • 주로 Corosync의 효율적인 노드 관리를 통해 2의 조합보다 동작이 빠르다 입니다.
    • 2 조합에서는 불가능한 구성, 동작이 새로운 기능 을 통해 가능합니다. (N + M 구성과 리소스 할당 전략 기능 등)
    • 다운로드 / 설치 방법은 여기

• 추천 조합 2 : 오래된 OS를 사용하거나 이미 Pacemaker (+ Heartbeat)를 사용하고 있으며, 노하우 등을 유용하고 사람을위한
  • 리소스 제어 기능 : Pacemaker 1.0 계
  • 클러스터 제어 기능 : Heartbeat 3 계
    • 대응 OS : RHEL5.X 및 RHEL6.X (포함 RHEL 클론 OS)
    • 2011 년 출시 이후 상용 시스템에 채용을 포함한 실적이 풍부합니다.
    • 노하우도 많이 축적되어 있습니다.
    • 현재 새로운 기능의 추가는 실시하지 않습니다.
    • 저장소 패키지의 최신은 2014 년 8 월 출시 Pacemaker 1.0.13-2.1 입니다. 다운로드는 여기

자원 및 자원 에이전트

Pacemaker는 다양한 응용 프로그램을 HA 클러스터링 할 수 있습니다. 
Pacemaker는 제어 대상을 자원 이라고합니다.

각 자원의 시작 / 감시 / 정지 등의 제어는 자원 에이전트 (RA) 라는 각 리소스 전용 모듈을 통해 이루어집니다. 전용 모듈을 통한 것으로, 각각의 애플리케이션 제어 방법의 차이를 랩하고 Pacemaker에서 통일적으로 취급 할 수 있도록하고 있습니다.

Pacemaker에는 Apache, PostgreSQL, Oracle, MySQL, Tomcat 가상 IP 주소, 파일 시스템 등 여러 리소스 에이전트가 처음부터 포함 되어 있습니다.

또한 자원 에이전트는 많은 쉘 스크립트로 작성되어 있으며, Open Cluster Framework (OCF)라는 사양 에 따르면 자신의 물건을 만들어 사용할 수도 있습니다. 
OCF는 정의 할 메소드 (start / monitor 등) 및 반환 할 결과 등의 규정이되어 있습니다. 방법과 결과 등의 규정을 따른다면 구현하는 프로그램 언어는 묻지 않습니다. 그러나 배포판에 의존하지 않는, 예를 들어 bash가 아닌 sh에서 설명하는 등의 배려가 필요합니다.

좌우 분열과 배타 제어

HA 클러스터에서 리소스를 클러스터에 하나만 유지하는 것이 매우 중요합니다. 
예를 들어, 공유 디스크를 갖는 이른바 공유 구성에서 여러 서버에서 동시에 마운트 / 액세스 해 버리면 공유 디스크 파일 시스템은 파괴되고 데이터가 손실 될 수 있습니다. 또한 공유 아무것도 구성에서도 예를 들면 DBMS가 여러 서버에서 실행하면 동일한 세그먼트에 여러 DBMS가 존재하게되고, 클라이언트에서 데이터가 분산되어 버렸 데이터 불일치가 발생합니다.

클러스터를 구성하는 서버 간의 통신이 정상적인 경우는 서버끼리 연계 할 수 있기 때문에 자원을 하나만 유지하는 것은 쉽습니다. 그러나 서버 사이의 통신 경로가 끊겼거나 노드가 다운되는 등 서버가 통신 할 수없는 경우에 위와 같은 문제가 발생합니다. 이 상태를 좌우 분열 이라고합니다.

그림 : 배타 제어를하지 않는 경우의 문제 (split-brain)

Pacemaker는 좌우 분열을 방지하려면 다음 세 가지의 배타 제어기구를 가지고 있습니다. 
이 중에서 가장 신뢰성이 높고, 일반적인 것은 STONITH 입니다.

표 : 배타 제어의 종류

배타 제어 이름 (읽기)	요약	중지 실패에 대한 대응
STONITH (스토니스)	네트워크를 통해 상대 노드의 전원을 강제로 떨어 뜨린다	OK
SFEX (공상 과학이 엑스)	공유 디스크에 잠금 정보를 기록	NG
VIPcheck (빗뿌 체크)	가상 IP 주소로 ping을 수행 상대 노드의 상태를 확인하는	NG

배타 제어기구 중 STONITH 자원 중지에 실패했다 경우에도 유효 합니다. 
일반적으로 장애 발생시 등의 자원 정지는 자원 에이전트에 의해 이루어 지지만, 이것은 어떤 이유로 실패 해 버리는 경우가 있습니다. (ex 프로세스가 완전히 무 반응 등) 
자원은 클러스터에 하나만 유지해야하므로 제대로 정지 한 것을 확인 할 수없는 장애를 계속할 수 없으며이 경우 장애는 실패 버립니다. 
그러나이 경우에도 STONITH를 사용하는 경우, 정지 실패한 노드의 전원을 강제로 끌 수 있도록 장애를 계속 서비스를 유지할 수 있습니다.

배타 제어에 대한 더 자세한 내용은 OSC2015 Tokyo / Fall 강연 「시도 기억 Pacemaker 입문 배타 제어 기능편」을 참고해주십시오.