Ubuntu 14.04에서 Corosync, Pacemaker 및 예약된 IP로 고가용성 설정을 만드는 방법

소개

이 튜토리얼에서는 예약된 IP와 함께 Corosync 및 Pacemaker를 사용하여 DigitalOcean에서 고가용성(HA) 서버 인프라를 생성하는 방법을 보여줍니다.

Corosync는 종종 메시징 계층이라고 하는 클러스터 구성원 및 메시징 기능을 클라이언트 서버에 제공하는 오픈 소스 프로그램입니다. Pacemaker는 클러스터에서 관리하고 고가용성을 제공하는 리소스와 서비스를 조정하는 시스템인 오픈 소스 클러스터 리소스 관리자(CRM)입니다. 본질적으로 Corosync는 서버가 클러스터로 통신할 수 있도록 하고 Pacemaker는 클러스터 작동 방식을 제어하는 기능을 제공합니다.

목표

완료되면 HA 설정은 능동/수동 구성의 Ubuntu 14.04 서버 2개로 구성됩니다. 이는 실패가 감지되지 않는 한 사용자가 웹 서비스에 액세스하는 방법인 예약된 IP를 지정하여 기본(활성) 서버를 지정함으로써 수행됩니다. Pacemaker가 기본 서버를 사용할 수 없음을 감지하는 경우 보조(수동) 서버는 DigitalOcean API를 통해 예약된 IP를 자신에게 재할당하는 스크립트를 자동으로 실행합니다. 따라서 예약된 IP에 대한 후속 네트워크 트래픽은 활성 서버 역할을 하고 들어오는 트래픽을 처리하는 보조 서버로 전달됩니다.

이 다이어그램은 설명된 설정의 개념을 보여줍니다.

참고: 이 자습서에서는 게이트웨이 수준에서 능동/수동 고가용성 설정에 대해서만 다룹니다. 즉, 여기에는 예약된 IP와 로드 밸런서 서버(기본 및 보조)가 포함됩니다. 또한 데모 목적으로 각 서버에 리버스 프록시 로드 밸런서를 구성하는 대신 각각의 호스트 이름과 공용 IP 주소로 응답하도록 구성하기만 하면 됩니다.

이 목표를 달성하기 위해 다음 단계를 따릅니다.

• 트래픽을 수신할 2개의 Droplet 만들기
• 예약된 IP를 생성하고 Droplet 중 하나에 할당
• Corosync 설치 및 구성
• Pacemaker 설치 및 구성
• 예약된 IP 재할당 클러스터 리소스 구성
• 테스트 장애 조치
• Nginx 클러스터 리소스 구성

전제 조건

예약된 IP 재할당을 자동화하려면 DigitalOcean API를 사용해야 합니다. 즉, 읽기 및 쓰기 액세스 권한이 있는 DigitalOcean 계정에 인증하는 데 사용할 수 있는 API 토큰인 개인 액세스 토큰(PAT)을 생성해야 합니다. API 자습서의 개인용 액세스 토큰을 생성하는 방법 섹션을 따릅니다. PAT는 클러스터의 두 서버에 추가될 스크립트에서 사용되므로 참조용으로 DigitalOcean 계정에 대한 전체 액세스를 허용하므로 안전한 곳에 보관하십시오.

API 외에도 이 튜토리얼에서는 다음과 같은 DigitalOcean 기능을 활용합니다.

• 예약된 IP
• 메타데이터
• 사용자 데이터(Cloud-Config 스크립트)

이에 대해 자세히 알아보려면 링크된 자습서를 읽으십시오.

물방울 만들기

첫 번째 단계는 위에서 설명한 기본 및 보조 서버 역할을 하는 동일한 데이터 센터에서 사설 네트워킹이 활성화된 두 개의 Ubuntu Droplet을 만드는 것입니다. 예제 설정에서는 쉽게 참조할 수 있도록 "primary\ 및 "secondary\로 이름을 지정합니다. 두 Droplet 모두에 Nginx를 설치하고 인덱스 페이지를 고유하게 식별하는 정보로 대체합니다. 이렇게 하면 HA 설정이 작동하는지 간단하게 보여줄 수 있습니다. 실제 설정을 위해 서버는 Nginx 또는 HAProxy와 같이 원하는 웹 서버 또는 로드 밸런서를 실행해야 합니다.

두 개의 Ubuntu 14.04 Droplet(기본 및 보조)을 만듭니다. 예제 설정을 따르려면 이 bash 스크립트를 사용자 데이터로 사용하십시오.

#!/bin/bash

apt-get -y update
apt-get -y install nginx
export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
export PUBLIC_IPV4=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
echo Droplet: $HOSTNAME, IP Address: $PUBLIC_IPV4 > /usr/share/nginx/html/index.html

이 사용자 데이터는 Nginx를 설치하고 index.html의 내용을 드롭릿의 호스트 이름 및 IP 주소로 바꿉니다(메타데이터 서비스 참조). 공용 IP 주소를 통해 Droplet에 액세스하면 Droplet 호스트 이름과 IP 주소가 포함된 기본 웹페이지가 표시되며, 예약된 IP가 특정 순간에 가리키는 Droplet을 테스트하는 데 유용합니다.

예약 IP 생성

DigitalOcean Control Panel의 상단 메뉴에서 네트워킹을 클릭한 다음 측면 메뉴에서 예약된 IP를 클릭합니다.

기본 Droplet에 예약된 IP를 할당한 다음 예약된 IP 할당 버튼을 클릭합니다.

예약된 IP가 할당된 후 해당 IP 주소를 기록해 둡니다. 웹 브라우저에서 예약된 IP 주소를 방문하여 할당된 Droplet에 도달할 수 있는지 확인합니다.

http://your_reserved_ip

기본 Droplet의 인덱스 페이지가 표시되어야 합니다.

DNS 구성(선택 사항)

도메인 이름을 통해 HA 설정에 액세스할 수 있으려면 도메인을 예약된 IP 주소로 가리키는 DNS에 A 레코드를 만드십시오. 도메인에서 DigitalOcean의 이름 서버를 사용하는 경우 DigitalOcean으로 호스트 이름을 설정하는 방법 자습서의 3단계를 따르십시오. 전파되면 도메인 이름을 통해 활성 서버에 액세스할 수 있습니다.

우리가 사용할 예제 도메인 이름은 example.com입니다. 지금 사용할 도메인 이름이 없는 경우 대신 예약된 IP 주소를 사용하여 설정에 액세스합니다.

시간 동기화 구성

특히 클러스터링 소프트웨어를 사용하여 여러 서버가 서로 통신할 때마다 시계가 동기화되도록 하는 것이 중요합니다. NTP(Network Time Protocol)를 사용하여 서버를 동기화합니다.

두 서버 모두에서 이 명령을 사용하여 시간대 선택기를 엽니다.

sudo dpkg-reconfigure tzdata

원하는 시간대를 선택합니다. 예를 들어 America/New_York를 선택합니다.

다음으로 apt-get을 업데이트합니다.

sudo apt-get update

그런 다음 이 명령으로 ntp 패키지를 설치합니다.

sudo apt-get -y install ntp

이제 NTP를 사용하여 서버 시계를 동기화해야 합니다. NTP에 대해 자세히 알아보려면 시간대 및 네트워크 시간 프로토콜 동기화 구성 자습서를 확인하십시오.

방화벽 구성

Corosync는 포트 5404와 5406 사이의 UDP 전송을 사용합니다. 방화벽을 실행 중인 경우 해당 포트의 통신이 서버 간에 허용되는지 확인하십시오.

예를 들어 iptables를 사용하는 경우 다음 명령을 사용하여 이러한 포트 및 eth1(사설 네트워크 인터페이스)에서 트래픽을 허용할 수 있습니다.

sudo iptables -A INPUT  -i eth1 -p udp -m multiport --dports 5404,5405,5406 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT  -o eth1 -p udp -m multiport --sports 5404,5405,5406 -m conntrack --ctstate ESTABLISHED -j ACCEPT

제공된 예보다 더 제한적인 방화벽 규칙을 사용하는 것이 좋습니다.

Corosync 및 Pacemaker 설치

두 서버 모두에서 apt-get을 사용하여 Corosync 및 Pacemaker를 설치합니다.

sudo apt-get install pacemaker

Corosync는 Pacemaker 패키지의 종속 항목으로 설치됩니다.

이제 Corosync 및 Pacemaker가 설치되었지만 유용한 작업을 수행하기 전에 구성해야 합니다.

Corosync 구성

서버가 클러스터로 통신할 수 있도록 Corosync를 구성해야 합니다.

클러스터 인증 키 생성

노드가 클러스터에 가입할 수 있도록 하기 위해 Corosync는 각 노드가 동일한 클러스터 인증 키를 소유해야 합니다.

기본 서버에서 haveged 패키지를 설치합니다.

sudo apt-get install haveged

이 소프트웨어 패키지를 사용하면 corosync-keygen 스크립트에 필요한 서버의 엔트로피 양을 쉽게 늘릴 수 있습니다.

기본 서버에서 corosync-keygen 스크립트를 실행합니다.

sudo corosync-keygen

이렇게 하면 128바이트 클러스터 인증 키가 생성되고 /etc/corosync/authkey에 기록됩니다.

이제 더 이상 haveged 패키지가 필요하지 않으므로 기본 서버에서 제거하겠습니다.

sudo apt-get remove --purge haveged
sudo apt-get clean

기본 서버에서 authkey를 보조 서버에 복사합니다.

sudo scp /etc/corosync/authkey username@secondary_ip:/tmp

보조 서버에서 authkey 파일을 적절한 위치로 이동하고 권한을 루트로 제한합니다.

sudo mv /tmp/authkey /etc/corosync
sudo chown root: /etc/corosync/authkey
sudo chmod 400 /etc/corosync/authkey

이제 두 서버 모두 /etc/corosync/authkey 파일에 동일한 인증 키가 있어야 합니다.

Corosync 클러스터 구성

원하는 클러스터를 시작하고 실행하려면 다음을 설정해야 합니다.

두 서버 모두에서 corosync.conf 파일을 열어 선호하는 편집기에서 편집합니다(vi 사용).

sudo vi /etc/corosync/corosync.conf

다음은 서버가 클러스터로 통신할 수 있게 해주는 Corosync 구성 파일입니다. 강조 표시된 부분을 적절한 값으로 바꾸십시오. bindnetaddr은 현재 작업 중인 서버의 사설 IP 주소로 설정해야 합니다. 강조 표시된 다른 두 항목은 표시된 서버의 사설 IP 주소로 설정되어야 합니다. bindnetaddr을 제외하고 파일은 두 서버에서 동일해야 합니다.

corosync.conf의 내용을 이 구성으로 바꾸고 사용자 환경에 맞는 변경 사항을 적용하십시오.

totem {
  version: 2
  cluster_name: lbcluster
  transport: udpu
  interface {
    ringnumber: 0
    bindnetaddr: server_private_IP_address
    broadcast: yes
    mcastport: 5405
  }
}

quorum {
  provider: corosync_votequorum
  two_node: 1
}

nodelist {
  node {
    ring0_addr: primary_private_IP_address
    name: primary
    nodeid: 1
  }
  node {
    ring0_addr: secondary_private_IP_address
    name: secondary
    nodeid: 2
  }
}

logging {
  to_logfile: yes
  logfile: /var/log/corosync/corosync.log
  to_syslog: yes
  timestamp: on
}

Corosync가 클러스터 구성원에 사용하는 Totem 프로토콜을 참조하는 totem 섹션(1-11행)은 클러스터 구성원이 서로 통신해야 하는 방법을 지정합니다. 설정에서 중요한 설정에는 transport: udpu(유니캐스트 모드 지정) 및 bindnetaddr(Corosync가 바인딩해야 하는 네트워크 주소 지정)가 포함됩니다.

쿼럼 섹션(13-16행)은 이것이 2노드 클러스터임을 지정하므로 쿼럼에는 단일 노드만 필요합니다(two_node: 1). 이것은 쿼럼을 달성하려면 클러스터에 최소 3개의 노드가 필요하다는 사실에 대한 해결 방법입니다. 이 설정을 사용하면 2노드 클러스터가 지정된 시간에 클러스터를 제어하는 노드인 코디네이터(DC)를 선택할 수 있습니다.

nodelist 섹션(18-29행)은 클러스터의 각 노드와 각 노드에 도달할 수 있는 방법을 지정합니다. 여기에서 기본 노드와 보조 노드를 모두 구성하고 각각의 개인 IP 주소를 통해 연결할 수 있도록 지정합니다.

로깅 섹션(31-36행)은 Corosync 로그가 /var/log/corosync/corosync.log에 기록되어야 한다고 지정합니다. 이 자습서의 나머지 부분에서 문제가 발생하면 문제를 해결하는 동안 여기를 확인하십시오.

저장 및 종료.

다음으로 Pacemaker 서비스를 허용하도록 Corosync를 구성해야 합니다.

두 서버 모두에서 편집기를 사용하여 Corosync 서비스 디렉토리에 pcmk 파일을 만듭니다. 우리는 vi를 사용할 것입니다:

sudo vi /etc/corosync/service.d/pcmk

그런 다음 Pacemaker 서비스를 추가합니다.

service {
  name: pacemaker
  ver: 1
}

저장 및 종료. 이는 Corosync 구성에 포함되며 Pacemaker가 Corosync를 사용하여 서버와 통신할 수 있도록 합니다.

기본적으로 Corosync 서비스는 비활성화되어 있습니다. 두 서버 모두에서 /etc/default/corosync를 편집하여 변경합니다.

sudo vi /etc/default/corosync

START 값을 yes로 변경합니다.

START=yes

저장 및 종료. 이제 Corosync 서비스를 시작할 수 있습니다.

두 서버 모두에서 다음 명령을 사용하여 Corosync를 시작합니다.

sudo service corosync start

Corosync가 두 서버에서 실행되면 함께 클러스터링되어야 합니다. 다음 명령을 실행하여 이를 확인할 수 있습니다.

sudo corosync-cmapctl | grep members

출력은 기본(노드 1) 및 보조(노드 2)가 클러스터에 조인되었음을 나타내는 다음과 같아야 합니다.

corosync-cmapctl output:
runtime.totem.pg.mrp.srp.members.1.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.1.ip (str) = r(0) ip(primary_private_IP_address)
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(secondary_private_IP_address)
runtime.totem.pg.mrp.srp.members.2.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.2.status (str) = joined

이제 Corosync가 제대로 설정되었으므로 Pacemaker 구성으로 이동하겠습니다.

Pacemaker 시작 및 구성

이제 Corosync의 메시징 기능에 의존하는 Pacemaker를 시작하고 기본 속성을 구성할 준비가 되었습니다.

Pacemaker 활성화 및 시작

Pacemaker 서비스를 사용하려면 Corosync가 실행 중이어야 하므로 기본적으로 비활성화되어 있습니다.

두 서버 모두에서 다음 명령을 사용하여 Pacemaker가 시스템 부팅 시 시작되도록 활성화합니다.

sudo update-rc.d pacemaker defaults 20 01

이전 명령을 사용하여 Pacemaker의 시작 우선 순위를 20으로 설정했습니다. Pacemaker가 Corosync 이후에 시작되도록 Corosync(기본적으로 19)보다 높은 시작 우선 순위를 지정하는 것이 중요합니다.

이제 Pacemaker를 시작하겠습니다.

sudo service pacemaker start

Pacemaker와 상호 작용하기 위해 crm 유틸리티를 사용합니다.

crm으로 Pacemaker 확인:

sudo crm status

다음과 같이 출력되어야 합니다(그렇지 않은 경우 30초 동안 기다린 후 명령을 다시 실행하십시오).

crm status:
Last updated: Fri Oct 16 14:38:36 2015
Last change: Fri Oct 16 14:36:01 2015 via crmd on primary
Stack: corosync
Current DC: primary (1) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
0 Resources configured


Online: [ primary secondary ]

이 출력에 대해 몇 가지 유의할 사항이 있습니다. 먼저 Current DC(Designated Coordinator)를 primary(1) 또는 secondary(2)로 설정해야 합니다. 둘째, 2개의 노드가 구성되고 0개의 리소스가 구성되어야 합니다. 셋째, 두 노드 모두 온라인으로 표시되어야 합니다. 오프라인으로 표시된 경우 30초 동안 기다린 후 상태가 자동으로 수정되는지 다시 확인하십시오.

이 시점부터 다른 SSH 창(클러스터 노드에 연결됨)에서 대화형 CRM 모니터를 실행할 수 있습니다. 그러면 각 노드의 상태와 각 리소스가 실행되는 위치에 대한 실시간 업데이트가 제공됩니다.

sudo crm_mon

이 명령의 출력은 계속 실행된다는 점을 제외하면 crm status의 출력과 동일합니다. 종료하려면 Ctrl-C를 누르십시오.

클러스터 속성 구성

이제 Pacemaker의 기본 속성을 구성할 준비가 되었습니다. 모든 Pacemaker(crm) 명령은 모든 구성원 노드에서 모든 클러스터 관련 변경 사항을 자동으로 동기화하므로 노드 서버에서 실행할 수 있습니다.

원하는 설정을 위해 많은 클러스터가 결함이 있는 노드를 제거하는 데 사용하는 모드인 STONITH를 비활성화하려고 합니다. 2노드 클러스터를 설정하고 있기 때문입니다. 이렇게 하려면 두 서버 중 하나에서 다음 명령을 실행합니다.

sudo crm configure property stonith-enabled=false

또한 로그에서 쿼럼 관련 메시지를 비활성화하려고 합니다.

sudo crm configure property no-quorum-policy=ignore

다시 말하지만 이 설정은 2노드 클러스터에만 적용됩니다.

Pacemaker 구성을 확인하려면 다음 명령을 실행합니다.

sudo crm configure show

활성 Pacemaker 설정이 모두 표시됩니다. 현재 여기에는 두 개의 노드와 방금 설정한 STONITH 및 쿼럼 속성만 포함됩니다.

예약된 IP 재할당 리소스 에이전트 만들기

이제 Pacemaker가 실행되고 구성되었으므로 관리할 리소스를 추가해야 합니다. 소개에서 언급했듯이 리소스는 클러스터가 고가용성을 담당하는 서비스입니다. Pacemaker에서 리소스를 추가하려면 관리할 서비스에 대한 인터페이스 역할을 하는 리소스 에이전트를 사용해야 합니다. Pacemaker는 공통 서비스를 위한 여러 리소스 에이전트와 함께 제공되며 사용자 지정 리소스 에이전트를 추가할 수 있습니다.

설정에서 우리는 웹 서버(기본 및 보조)에서 제공하는 서비스가 활성/수동 설정에서 고가용성인지 확인하려고 합니다. 사용할 수 있는 서버입니다. 이를 활성화하려면 각 노드가 예약 IP를 소유하고 있는지 확인하기 위해 실행할 수 있는 리소스 에이전트를 설정하고 필요한 경우 예약 IP를 자신에게 가리키는 스크립트를 실행해야 합니다. 예약된 IP는 유동 IP라고도 합니다. 다음 예에서는 리소스 에이전트를 "FloatIP OCF\라고 하고 예약된 IP 재할당 스크립트를 assign-ip라고 합니다. FloatIP OCF 리소스 에이전트를 설치하면 다음을 수행할 수 있습니다. 리소스 자체를 정의합니다. FloatIP라고 합니다.

assign-ip 스크립트 다운로드

방금 언급했듯이 FloatIP 리소스를 다른 노드로 이동해야 하는 경우 예약된 IP가 가리키는 Droplet을 재할당할 수 있는 스크립트가 필요합니다. 이를 위해 DigitalOcean API를 사용하여 예약된 IP를 지정된 Droplet ID에 할당하는 기본 Python 스크립트를 다운로드합니다.

두 서버 모두에서 assign-ip Python 스크립트를 다운로드합니다.

sudo curl -L -o /usr/local/bin/assign-ip http://do.co/assign-ip

두 서버 모두에서 실행 가능하게 만드십시오.

sudo chmod +x /usr/local/bin/assign-ip

assign-ip 스크립트를 사용하려면 다음 세부 정보가 필요합니다.

• 예약 IP: 스크립트에 대한 첫 번째 인수, 할당되는 예약 IP
• Droplet ID: 스크립트에 대한 두 번째 인수, 예약된 IP가 할당되어야 하는 Droplet ID
• DigitalOcean PAT(API 토큰): 읽기/쓰기 DigitalOcean PAT인 DO_TOKEN 환경 변수로 전달됩니다.

계속하기 전에 스크립트의 내용을 자유롭게 검토하십시오.

따라서 이 스크립트를 수동으로 실행하여 예약된 IP를 재할당하려면 다음과 같이 실행할 수 있습니다. droplet_id. 그러나 이 스크립트는 FloatIP 리소스를 다른 노드로 이동해야 하는 경우 FloatIP OCF 리소스 에이전트에서 호출됩니다.

다음으로 Float IP 리소스 에이전트를 설치하겠습니다.

FloatIP OCF 리소스 에이전트 다운로드

Pacemaker를 사용하면 OCF 리소스 에이전트를 특정 디렉터리에 배치하여 추가할 수 있습니다.

두 서버 모두에서 다음 명령을 사용하여 digitalocean 리소스 에이전트 공급자 디렉터리를 만듭니다.

sudo mkdir /usr/lib/ocf/resource.d/digitalocean

두 서버 모두에서 FloatIP OCF 리소스 에이전트를 다운로드합니다.

sudo curl -o /usr/lib/ocf/resource.d/digitalocean/floatip https://gist.githubusercontent.com/thisismitch/b4c91438e56bfe6b7bfb/raw/2dffe2ae52ba2df575baae46338c155adbaef678/floatip-ocf

두 서버 모두에서 실행 가능하게 만드십시오.

sudo chmod +x /usr/lib/ocf/resource.d/digitalocean/floatip

계속하기 전에 자원 에이전트의 내용을 자유롭게 검토하십시오. start 명령으로 호출하면 (메타데이터를 통해) 호출하는 노드의 Droplet ID를 조회하고 예약된 IP를 Droplet ID에 할당하는 bash 스크립트입니다. 또한 호출하는 Droplet에 할당된 예약 IP가 있는지 여부를 반환하여 status 및 monitor 명령에 응답합니다.

다음 OCF 매개변수가 필요합니다.

• do_token:: 예약된 IP 재할당에 사용할 DigitalOcean API 토큰, 즉 DigitalOcean 개인 액세스 토큰
• reserved_ip:: 재할당해야 하는 경우를 대비하여 예약된 IP(주소)

이제 FloatIP OCF 리소스 에이전트를 사용하여 FloatIP 리소스를 정의할 수 있습니다.

FloatIP 리소스 추가

FloatIP OCF 리소스 에이전트가 설치되었으므로 이제 FloatIP 리소스를 구성할 수 있습니다.

서버 중 하나에서 다음 명령을 사용하여 FloatIP 리소스를 생성합니다(강조 표시된 두 매개변수를 자신의 정보로 지정해야 함).

sudo crm configure primitive FloatIP ocf:digitalocean:floatip \
  params do_token=your_digitalocean_personal_access_token \
  reserved_ip=your_reserved_ip

이렇게 하면 앞서 생성한 FloatIP OCF 리소스 에이전트(ocf:digitalocean:floatip)를 사용하여 "FloatIP\라고 하는 클러스터 리소스의 일반적인 유형인 기본 리소스가 생성됩니다. 매개변수로 전달되는 do_token 및 reserved_ip 예약된 IP를 재할당해야 하는 경우에 사용됩니다.

클러스터의 상태(sudo crm status 또는 sudo crm_mon)를 확인하면 FloatIP 리소스가 정의되고 시작된 것을 확인할 수 있습니다. 노드 중 하나:

crm_mon:
...
2 Nodes configured
1 Resource configured

Online: [ primary secondary ]

 FloatIP	(ocf::digitalocean:floatip):	Started primary

모든 것이 제대로 설정되었다고 가정하면 이제 활성/수동 HA 설정이 있어야 합니다! 그대로, 예약된 IP는 FloatIP가 시작된 노드가 오프라인 상태가 되거나 대기 모드가 되면 온라인 서버에 재할당됩니다. 현재 활성 노드(예제 출력에서는 기본 노드)를 사용할 수 없게 되면 클러스터는 보조 노드에 지시하여 FloatIP 리소스를 시작하고 자체적으로 예약된 IP 주소를 요청합니다. 재할당이 발생하면 예약된 IP는 사용자를 새로 활성화된 보조 서버로 안내합니다.

현재 장애 조치(예약된 IP 재할당)는 활성 호스트가 오프라인이 되거나 클러스터와 통신할 수 없는 경우에만 트리거됩니다. 이 설정의 더 나은 버전은 Pacemaker에서 관리해야 하는 추가 리소스를 지정합니다. 이를 통해 클러스터는 로드 밸런서 또는 웹 서버 소프트웨어와 같은 특정 서비스의 장애를 감지할 수 있습니다. 그러나 이를 설정하기 전에 기본 장애 조치가 작동하는지 확인해야 합니다.

고가용성 테스트

고가용성 설정이 작동하는지 테스트하는 것이 중요하므로 지금 테스트해 보겠습니다.

현재 예약된 IP는 노드 중 하나에 할당되어 있습니다(기본이라고 가정). IP 주소 또는 이를 가리키는 도메인 이름을 통해 지금 예약된 IP에 액세스하면 기본 서버의 인덱스 페이지만 표시됩니다. 예제 사용자 데이터 스크립트를 사용한 경우 다음과 같이 표시됩니다.

Reserved IP is pointing to primary server:
Droplet: primary, IP Address: primary_ip_address

이는 실제로 예약된 IP가 기본 Droplet에 할당되었음을 나타냅니다.

이제 새 로컬 터미널을 열고 curl을 사용하여 1초 루프에서 예약된 IP에 액세스해 보겠습니다. 이렇게 하려면 이 명령을 사용하되 URL을 도메인 또는 예약된 IP 주소로 바꿔야 합니다.

while true; do curl reserved_IP_address; sleep 1; done

현재 이것은 기본 서버의 동일한 Droplet 이름과 IP 주소를 출력합니다. 기본 서버의 전원을 끄거나 기본 노드의 클러스터 상태를 대기로 변경하여 기본 서버에 장애가 발생하면 예약된 IP가 보조 서버에 다시 할당되는지 확인합니다.

이제 기본 서버를 재부팅하겠습니다. DigitalOcean Control Panel을 통하거나 주 서버에서 다음 명령을 실행하여 그렇게 하십시오.

sudo reboot

잠시 후 기본 서버를 사용할 수 없게 됩니다. 터미널에서 실행 중인 curl 루프의 출력에 주의하십시오. 다음과 같은 출력이 표시됩니다.

curl loop output:
Droplet: primary, IP Address: primary_IP_address
...
curl: (7) Failed to connect to reserved_IP_address port 80: Connection refused
Droplet: secondary, IP Address: secondary_IP_address
...

즉, 예약된 IP 주소는 보조 서버의 IP 주소를 가리키도록 재할당되어야 합니다. 이는 성공적인 자동 장애 조치가 발생했기 때문에 HA 설정이 작동 중임을 의미합니다.

기본 서버 오류와 예약된 IP 재할당 완료 사이에 예약된 IP에 액세스를 시도하는 경우 발생할 수 있는 연결 거부됨 오류가 표시되거나 표시되지 않을 수 있습니다.

Pacemaker의 상태를 확인하면 보조 서버에서 FloatIP 리소스가 시작되었음을 확인할 수 있습니다. 또한 기본 서버는 일시적으로 OFFLINE으로 표시되어야 하지만 재부팅을 완료하고 클러스터에 다시 합류하는 즉시 Online 목록에 합류합니다.

장애 조치 문제 해결(선택 사항)

HA 설정이 예상대로 작동하는 경우 이 섹션을 건너뛰십시오. 장애 조치가 예상대로 발생하지 않은 경우 계속 진행하기 전에 설정을 검토해야 합니다. 특히 노드 IP 주소, 예약된 IP 및 API 토큰과 같은 자체 설정에 대한 참조가 있는지 확인하십시오.

문제 해결에 유용한 명령

다음은 설정 문제를 해결하는 데 도움이 되는 몇 가지 명령입니다.

앞에서 언급했듯이 crm_mon 도구는 노드와 리소스의 실시간 상태를 보는 데 매우 유용할 수 있습니다.

sudo crm_mon

또한 다음 명령을 사용하여 클러스터 구성을 볼 수 있습니다.

sudo crm configure show

crm 명령이 전혀 작동하지 않는 경우 Corosync 로그에서 단서를 찾아야 합니다.

sudo tail -f /var/log/corosync/corosync.log

기타 CRM 명령

이러한 명령은 클러스터를 구성할 때 유용할 수 있습니다.

다음 명령으로 노드를 사용할 수 없게 되는 노드를 시뮬레이트하는 데 사용할 수 있는 대기 모드로 설정할 수 있습니다.

sudo crm node standby NodeName

다음 명령을 사용하여 노드의 상태를 대기에서 온라인으로 변경할 수 있습니다.

sudo crm node online NodeName

다음 명령을 사용하여 리소스를 재구성할 수 있는 리소스를 편집할 수 있습니다.

sudo crm configure edit ResourceName

다음 명령을 사용하여 삭제하기 전에 중지해야 하는 리소스를 삭제할 수 있습니다.

sudo crm resource stop ResourceName
sudo crm configure delete ResourceName

마지막으로 crm 명령을 단독으로 실행하여 대화형 crm 프롬프트에 액세스할 수 있습니다.

crm

대화형 crm 프롬프트의 사용법은 다루지 않지만 지금까지 수행한 모든 crm 구성을 수행하는 데 사용할 수 있습니다.

Nginx 리소스 추가(선택 사항)

이제 예약 IP 장애 조치가 작동하는지 확인했으므로 클러스터에 새 리소스를 추가하는 방법을 살펴보겠습니다. 예제 설정에서 Nginx는 고가용성을 제공하는 기본 서비스이므로 클러스터가 관리할 리소스로 추가해 보겠습니다.

Pacemaker는 Nginx 리소스 에이전트와 함께 제공되므로 Nginx를 클러스터 리소스로 쉽게 추가할 수 있습니다.

이 명령을 사용하여 "Nginx”라는 새로운 기본 클러스터 리소스를 만듭니다.

sudo crm configure primitive Nginx ocf:heartbeat:nginx \
  params httpd="/usr/sbin/nginx" \
  op start timeout="40s" interval="0" \
  op monitor timeout="30s" interval="10s" on-fail="restart" \
  op stop timeout="60s" interval="0"

지정된 리소스는 10초마다 Nginx를 모니터링하고 사용할 수 없게 되면 다시 시작하도록 클러스터에 지시합니다.

sudo crm_mon 또는 sudo crm status를 사용하여 클러스터 리소스의 상태를 확인합니다.

crm_mon:
...
Online: [ primary secondary ]

 FloatIP	(ocf::digitalocean:floatip):	Started primary
 Nginx	(ocf::heartbeat:nginx):	Started secondary

안타깝게도 Pacemaker는 리소스 제약 조건을 정의하지 않았기 때문에 별도의 노드에서 Nginx 및 FloatIP 리소스를 시작하기로 결정합니다. 이것은 Reserved IP가 하나의 Droplet을 가리키는 반면 Nginx 서비스는 다른 Droplet에서만 실행된다는 것을 의미하기 때문에 문제가 됩니다. 예약된 IP에 액세스하면 가용성이 높아야 하는 서비스를 실행하지 않는 서버로 연결됩니다.

이 문제를 해결하기 위해 기존 기본 리소스가 여러 노드에서 시작되어야 함을 지정하는 복제 리소스를 생성합니다.

다음 명령을 사용하여 "Nginx-clone”이라는 Nginx 리소스의 클론 리소스를 만듭니다.

sudo crm configure clone Nginx-clone Nginx

클러스터 상태는 이제 다음과 같아야 합니다.

crm_mon:
Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
 Clone Set: Nginx-clone [Nginx]
     Started: [ primary secondary ]

보시다시피 클론 리소스인 Nginx-clone이 이제 두 노드 모두에서 시작됩니다.

마지막 단계는 코로케이션 제한을 구성하여 FloatIP 리소스가 활성 Nginx-clone 리소스가 있는 노드에서 실행되도록 지정하는 것입니다. "FloatIP-Nginx”라는 공동 배치 제한을 생성하려면 다음 명령을 사용하십시오.

sudo crm configure colocation FloatIP-Nginx inf: FloatIP Nginx-clone

crm status 출력에는 차이가 없지만 다음 명령으로 코로케이션 리소스가 생성되었음을 확인할 수 있습니다.

sudo crm configure show

이제 두 서버 모두 Nginx를 실행해야 하며 그 중 하나만 FloatIP 리소스를 실행해야 합니다. 이제 Nginx 서비스를 중지하고 활성 서버를 재부팅하거나 전원을 꺼서 HA 설정을 테스트할 적기입니다.

결론

축하해요! 이제 Corosync, Pacemaker 및 DigitalOcean Reserved IP를 사용하는 기본 HA 서버 설정이 있습니다.

다음 단계는 예제 Nginx 설정을 리버스 프록시 로드 밸런서로 교체하는 것입니다. 이 목적으로 Nginx 또는 HAProxy를 사용할 수 있습니다. 로드 밸런서를 앵커 IP 주소에 바인딩하여 사용자가 예약된 IP 주소를 통해서만 서버에 액세스할 수 있도록 해야 합니다(각 서버의 공용 IP 주소를 통해서가 아님). 이 프로세스는 Ubuntu 14.04 자습서에서 Corosync, Pacemaker 및 예약된 IP를 사용하여 고가용성 HAProxy 설정을 만드는 방법에 자세히 설명되어 있습니다.