NGINX Plus

클러스터에서 NGINX 구성 동기화하기

NGINX Plus 인스턴스 클러스터 전체에서 구성을 동기화합니다. 고가용성 배포를 위해 설계되었지만 이 솔루션은 모든 클러스터에서 작동합니다.

목차

1. 개요
2. 지침
2-1. Primary 머신에 nginx-sync를 설치합니다.
2-2. Peer에 대한 root SSH 액세스 구성하기
2-3. Primary 노드에서 nginx-sync.conf 구성 파일을 생성합니다.
2-4. 구성 테스트
3. 자주 묻는 질문
3-1. root에 SSH 액세스 권한을 부여해야 하는 이유
3-2. 기본 구성이 실패하면 어떻게 동기화하나요?
3-3. Peer 노드에 장애가 발생하면 어떻게 되나요?

1. 개요

NGINX Plus 는 두 대 이상의 장치로 구성된 고가용성(HA) 클러스터에 배포되는 경우가 많습니다. 구성 공유 기능을 사용하면 클러스터의 Primary 머신 한 대에서 Peer 머신으로 구성을 Push할 수 있습니다.

nginx-sync.sh

이 기능을 구성하려면 다음을 수행합니다.

1. Primary 머신에 nginx-sync 패키지를 설치합니다.

2. Primary 머신에 Peer 머신에 root로 ssh 액세스 권한을 부여합니다.

3. Primary 머신에서 구성 파일 /etc/nginx-sync.conf를 생성합니다.

NODES="node2.example.com node3.example.com node4.example.com"
CONFPATHS="/etc/nginx/nginx.conf /etc/nginx/conf.d"
EXCLUDE="default.conf"

4. Primary에서 nginx-sync.sh 명령을 실행하여 CONFPATHS에 있는 구성 파일 이름을 지정된 NODES로 푸시하고 EXCLUDE에 있는 구성 파일은 생략합니다.

nginx-sync.sh에는 여러 가지 안전 검사 기능이 포함되어 있습니다.

  • 진행하기 전에 시스템 사전 요구 사항을 확인합니다.
  • 로컬(Primary) 구성의 유효성을 검사하고(nginx -t) 실패하면 종료합니다.
  • 각 Peer에 구성의 원격 백업을 생성합니다.
  • rsync를 사용하여 기본 구성을 Peer로 Push하고, Peer에서 구성의 유효성을 검사하고(nginx -t), 성공하면 Peer에서 NGINX Plus 를 Reload합니다(service nginx reload).
  • 단계가 실패하면 Peer에 있는 백업으로 Rollback합니다.

2. 지침

2-1. Primary 머신에 nginx-sync를 설치합니다.

RHEL 또는 CentOS의 경우:

$ sudo yum install nginx-sync

Ubuntu 또는 Debian의 경우:

$ sudo apt-get install nginx-sync

2-2. Peer에 대한 root SSH 액세스 구성하기

이 절차를 통해 Primary 노드의 root 사용자는 각 Peer의 root 계정으로 ssh할 수 있으며, 이는 Peer에 파일을 rsync하고 Peer에서 명령을 실행하여 구성의 유효성을 검사하고 NGINX Plus 를 Reload하는 등의 작업을 수행하는 데 필요합니다.

1. Primary 노드에서 root에 대한 SSH 인증 키 쌍을 생성하고 키의 공개 부분을 확인합니다.

$ sudo ssh-keygen -t rsa -b 2048
$ sudo cat /root/.ssh/id_rsa.pub
ssh-rsa AAAAB3Nz4rFgt...vgaD root@node1

2. Primary 노드의 IP 주소를 가져옵니다(다음 예제에서는 192.168.1.2).

$ ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default 
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host 
      valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether 52:54:00:34:6c:35 brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0
      valid_lft forever preferred_lft forever
   inet6 fe80::5054:ff:fe34:6c35/64 scope link 
      valid_lft forever preferred_lft forever

3. 각 Peer 노드에서 root의 authorized_keys 파일에 Public Key를 추가합니다. from=192.168.1.2 접두사는 Primary 노드의 IP 주소로만 액세스를 제한합니다.

$ sudo mkdir /root/.ssh
$ sudo echo ‘from=”192.168.1.2" ssh-rsa AAAAB3Nz4rFgt...vgaD root@node1' >> /root/.ssh/authorized_keys

4. etc/ssh/sshd_config에 다음 줄을 추가합니다.

PermitRootLogin without-password

5. 각 Peer( Primary는 제외)에서 sshd를 Reload하여 SSH Key 인증을 허용합니다.

RHEL 또는 CentOS의 경우:

$ sudo service sshd reload

Ubuntu 또는 Debian의 경우:

$ sudo service ssh reload

6. root 사용자가 비밀번호를 제공하지 않고도 다른 각 노드에 ssh할 수 있는지 확인합니다.

$ sudo ssh root@node2.example.com <hostname>

2-3. Primary 노드에서 nginx-sync.conf 구성 파일을 생성합니다.

Primary 노드에서 다음과 같은 내용으로 /etc/nginx-sync.conf 파일을 생성합니다.

NODES="node2.example.com node3.example.com node4.example.com"
CONFPATHS="/etc/nginx/nginx.conf /etc/nginx/conf.d"
EXCLUDE="default.conf"

공통 매개변수

공백 또는 개행 문자를 사용하여 각 목록의 항목을 구분합니다.

  • NODES – 기본 설정에서 구성을 수신하는 Peer 목록
  • CONFPATHS – Primary에서 Peer로 배포할 파일 및 디렉터리 목록
  • EXCLUDE – (선택 사항) Peer에게 배포하지 않을 Primary 구성 파일 목록

고급 매개변수

  • BACKUPDIR -각 Peer에서 백업 위치(기본값 /var/lib/nginx-sync)
  • DIFF – diff Binary 위치(기본값 /usr/bin/diff)
  • LOCKFILE – 한 번에 하나의 nginx-sync 작업만 실행되도록 하는 데 사용되는 잠금 파일의 위치(기본값 /tmp/nginx-sync.lock)
  • NGINX – nginx-plus Binary 위치(기본값 /usr/sbin/nginx)
  • POSTSYNC – 각 원격 노드에서 수행할 파일 치환의 공백으로 구분된 목록으로, '<filename>|<sed-expression>' 형식입니다. 치환이 적용됩니다.
sed -i'' <sed-expression> <filename>

예를 들어, 이 명령은 keepalived.conf에서 node2.example.com의 IP 주소(192.168.2.2)를 node1.example.com의 IP 주소(192.168.2.1)로 대체합니다.

POSTSYNC="/etc/keepalived/keepalived.conf|'s/192\.168\.2\.1/192.168.2.2/'"
  • RSYNC – rsync Binary 위치(기본값 /usr/bin/rsync)
  • SSH – ssh Binary 위치(기본값 /usr/bin/ssh)

2-4. 구성 테스트

테스트하기 전에 구성을 백업하세요.

  • 구성 동기화 및 Peer에서 NGINX Plus Reload – nginx-sync.sh
  • 사용량 정보 표시 – nginx-sync.sh -h
  • Primary 구성과 Peer 간의 구성 비교 – nginx-sync.sh -c
  • Primary 구성과 모든 Peer 구성 비교 – nginx-sync.sh -C

3. 자주 묻는 질문

3-1. root에 SSH 액세스 권한을 부여해야 하는 이유

Primary 노드는 root 사용자로서 Peer에서 원격으로 명령을 실행할 수 있어야 하며(예: service nginx reload), root가 소유한 구성 파일(예: /etc/nginx/에 있음)을 업데이트할 수 있어야 합니다.

root에 SSH 액세스 권한을 부여하는 것은 너무 많은 권한을 부여하는 것처럼 보일 수 있지만, 원격 NGINX Plus 구성을 작성하고 원격 NGINX Plus 프로세스를 Reload할 수 있는 모든 프로세스가 이 프로세스를 무력화하여 서버에 대한 원격 root 액세스 권한을 얻을 수 있다는 점을 기억하는 것이 중요합니다.

따라서 Primary 노드에서 root 액세스 권한을 얻은 사용자는 Peer 노드에서도 root 액세스 권한을 가진다고 가정합니다.

3-2. Primary 구성이 실패하면 어떻게 동기화하나요?

Primary 계정에서 장애가 발생하여 곧 서비스를 재개할 수 없는 경우에는 설치의 안내에 따라 Peer를 Primary 계정으로 승격시켜야 합니다. 여기에는 다음이 포함됩니다.

  1. nginx-sync.sh 스크립트 설치
  2. 나머지 Peer에게 SSH 액세스 권한 부여
  3. 구성 파일 생성하기

여러 대의 머신이 Primary 노드로 작동하도록 사전 구성할 수 있지만, 주어진 시간에 실제로 하나의 노드만 Primary 노드로 실행되도록 해야 합니다.

3-3. Peer 노드에 장애가 발생하면 어떻게 되나요?

Peer 노드가 실패하면 더 이상 구성 업데이트를 받지 못합니다. nginx-sync.sh 스크립트는 오류를 반환하지만 나머지 Peer에 구성을 계속 배포합니다.

노드가 복구되면 구성이 오래된 것입니다. nginx-sync.sh -c <recovered-peer-node> -d를 실행하여 구성 차이를 표시할 수 있습니다.

$ nginx-sync.sh -c node2.example.com -d

명령의 출력입니다.

diff -ru /tmp/localconf.1XrIqP7f/etc/nginx/conf.d/responder.conf /tmp/remoteconf.Xq5LWGKU/etc/nginx/conf.d/responder.conf
--- /tmp/localconf.1XrIqP7f/etc/nginx/conf.d/responder.conf    2020-09-25 10:29:36.988064021 -0800
+++ /tmp/remoteconf.Xq5LWGKU/etc/nginx/conf.d/responder.conf    2020-09-25 10:28:39.764066539 -0800
@@ -4,6 +4,6 @@
    listen 80;

    location / {
-        return 200 "Received request on $server_addr on host $hostname blue\n";
+        return 200 "Received request on $server_addr on host $hostname red\n";
    }
}

* Synchronization ended at Fri Sep 25 18:30:49 UTC 2020

다음으로 nginx-sync.sh를 실행하면 노드가 현재 Primary 구성으로 업데이트됩니다.