Date: 4월 6, 2024
Linux에서 SIOS LifeKeeper를 사용하여 NFS 파일 감시를 설정하는 단계별 가이드
SIOS Lifekeeper 및 NFS 기반 파일 감시 시작하기
~ 안에고가용성 클러스터링, 증인은 클러스터의 무결성과 신뢰성을 보장하는 데 중요한 역할을 합니다. 없이세 번째 노드, 두 노드가 모두 활성화되어야 한다고 생각하는 연결을 끊는 데 도움이 되는 데이터가 없기 때문에 쿼럼을 달성하기 어려울 수 있습니다.분열된 두뇌). 예를 들어 전용 감시 서버, 전체 클러스터에서 볼 수 있는 공유 스토리지 경로를 제공하거나 단순히 클러스터 자체에 더 많은 노드(최소 3개!)를 두는 등 다양한 방법으로 이 문제를 해결할 수 있습니다. 고맙게도,SIOS 라이프키퍼Linux 환경에서 고가용성 클러스터를 설정하기 위한 강력한 솔루션을 제공하며 쿼럼을 개선하기 위한 감시 구성은 필수 기능입니다.
이 가이드에서는 Linux에서 SIOS LifeKeeper를 사용하여 NFS 기반 파일 감시를 설정하는 단계를 안내하여 클러스터된 애플리케이션의 가용성과 복원력을 향상시키는 데 도움을 줍니다.
목표:
아래 다이어그램에 표시된 대로 NFS 기반 스토리지 감시를 사용하여 2노드 클러스터를 구현하려면 다음을 수행하세요.
전제조건: 시작하기 전에 다음이 있는지 확인하십시오.
- Linux 서버는 관리 권한(예: 루트 액세스)으로 구성 및 연결됩니다.
- SIOS LifeKeeper는 설치 또는 다운로드되어 각 서버에 설치할 준비가 되어 있습니다.
- NFS 공유는 클러스터의 모든 서버에 액세스할 수 있습니다.
1단계: SIOS LifeKeeper 설치/수정:
이 단계에서 LifeKeeper를 설치하거나 이전에 Witness 기능을 이미 포함하지 않은 경우 설정을 다시 실행하여 Witness 기능을 추가해야 합니다.
제 경우에는 RHEL8.8을 사용하고 있으므로 RHEL8.8에 필요한 추가 패키지로 설정을 실행하기 전에 ISO를 마운트하겠습니다.
[root@server1-LK ~]# 마운트 /root/sps.img /mnt/loop -t iso9660 -o 루프
[root@server1-LK ~]# cd /mnt/loop/
[root@server1-LK 루프]# ./setup –addHADR /root/HADR-RHAS-4.18.0-477.10.1.el8_8.x86_64.rpm
여기서 우리 목적에 있어 중요한 부분은 아래 스크린샷과 같이 감시 기능을 활성화하는 것입니다. 그러나 여기에 추가하거나 나중에 재량에 따라 명령줄을 통해 추가할 수 있는 추가 라이센스 파일도 필요합니다.
그렇지 않은 경우 목적에 맞게 LifeKeeper를 구성하거나, 이미 구성된 경우 “정족수/감시 기능 사용” 옵션을 포함시킨 후 설정을 계속 진행하십시오.
명령줄을 통해 라이선스를 추가하기로 결정한 경우 라이선스 파일의 올바른 경로를 사용하여 클러스터의 각 노드에서 다음 명령도 실행합니다.
[root@server1-LK ~]# /opt/LifeKeeper/bin/lkkeyins /<path-to-license-file>l/quorum-disk.lic
2단계: 공유 저장소 설정 및 마운트:
클러스터의 모든 서버에 액세스할 수 있는 공유 스토리지가 있는지 확인하십시오.
‘mount’ 명령을 사용하거나 ‘findmnt’를 사용하여 각 서버가 로컬로 마운트되었는지 확인할 수 있습니다.
[root@server1-LK 루프]# 마운트 | 그렙 nfs
/var/lib/nfs/rpc_pipefs의 sunrpc 유형 rpc_pipefs(rw,relatime)
172.16.200.254:/nfs/general 유형 nfs4의/var/nfs/general(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,
proto=tcp,timeo=600,retrans= 2,sec=sys,clientaddr=172.16.205.151,local_lock=none,addr=172.16.200.254)
또는
[root@server1-LK ~]# findmnt -l /nfs/general
대상 소스 FSTYPE 옵션
/nfs/general 172.16.200.254:/var/nfs/general nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,
retrans=2,sec =sys,클라이언트주소=172.16.205.151,local_lock=없음,주소=172.16.200.254
그래도 공유를 직접 마운트해야 하는 경우 다음 단계를 따르세요.
먼저 호스트 서버에서 NFS 공유를 볼 수 있는지 확인합니다.
[root@server1-LK ~]# showmount -e 172.16.200.254
172.16.200.254에 대한 목록 내보내기:
/집 172.16.205.244,172.16.205.151
/var/nfs/일반 172.16.205.244,172.16.205.151
제 경우에는 ‘/var/nfs/general’ 공유를 마운트하고 싶습니다.
이 공유를 마운트하려면 먼저 공유를 마운트하려는 디렉터리가 존재하는지 확인하세요. 그렇지 않은 경우 작성하십시오.
[root@server1-LK ~]# mkdir -p /nfs/general
이제 다음 명령을 사용하여 공유를 수동으로 마운트하여 연결할 수 있는지 확인할 수 있으며 작동합니다.
[root@server1-LK ~]# 마운트 172.16.200.254:/var/nfs/general /nfs/general
마지막으로 만족스러우면 마운트 지점을 /etc/fstab 파일에 추가하여 부팅 시 마운트되도록 합니다.
[root@server1-LK ~]# cat /etc/fstab
#
# /etc/fstab
# 2024년 1월 25일 목요일 12:07:15에 anaconda에 의해 생성됨
#
# 참조로 접근 가능한 파일 시스템은 ‘/dev/disk/’에 유지됩니다.
# 자세한 내용은 맨 페이지 fstab(5), findfs(8), mount(8) 및/또는 blkid(8)를 참조하십시오.
#
# 이 파일을 편집한 후 ‘systemctl daemon-reload’를 실행하여 systemd를 업데이트합니다.
이 파일에서 # 단위가 생성되었습니다.
#
/dev/mapper/rhel-root / xfs 기본값 0 0
UUID=6b22cebf-8f1c-405b-8fa8-8f12e1b6b56c /boot xfs 기본값 0 0
/dev/mapper/rhel-swap 없음 스왑 기본값 0 0
#NFS 공유에 추가됨
172.16.200.254:/var/nfs/general /nfs/general nfs4 기본값 0 0
이제 mount 명령을 사용하여 마운트되었는지 확인할 수 있습니다.
[root@server1-LK ~]# mount -l | 그렙 nfs
/var/lib/nfs/rpc_pipefs의 sunrpc 유형 rpc_pipefs(rw,relatime)
172.16.200.254:/nfs/general 유형 nfs4의/var/nfs/general(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,
proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.16.205.151,local_lock=none,
addr=172.16.200.254)
위에 강조 표시된 텍스트에서 볼 수 있듯이 이제 성공적으로 마운트되었습니다. 계속하기 전에 모든 서버에 공유가 마운트되어 있는지 확인할 때까지 모든 서버에서 반복하십시오.
4단계: 호스트 이름을 확인하고 /etc/default/LifeKeeper 설정을 구성합니다.
각 노드에서 다음 명령을 실행하면 LifeKeeper가 각 서버에 대해 알고 있는 호스트 이름을 확인할 수 있습니다.
/opt/LifeKeeper/bin/lcduname
/etc/default/LifeKeeper 파일에 추가해야 하는 설정의 예:
WITNESS_MODE=저장소
QWK_STORAGE_TYPE=파일
QWK_STORAGE_HBEATTIME=6
QWK_STORAGE_NUMHBEATS=9
QWK_STORAGE_OBJECT_server1_LK_localdomain=/nfs/general/nodeA
QWK_STORAGE_OBJECT_server2_LK_localdomain=/nfs/general/nodeB
‘QWK_STORAGE_OBJECT_<server-name>’의 경우 각 노드에 대해 이를 선언해야 하며 호스트 이름과 경로, 감시 파일 자체의 원하는 위치를 사용하여 구성됩니다.
호스트 이름에 “-” 또는 “.”가 포함된 경우 밑줄 “_”로 바꾸십시오(예: lksios-1 → lksios_1 또는 lksios-1.localdomain → lksios_1_localdomain ).
내 예에서는 다음과 같은 호스트 이름을 사용했습니다.
server1-LK.localdomain
server2-LK.localdomain
이는 다음 ‘QWK_STORAGE_OBJECT_’ 정의를 추가하는 것을 의미합니다.
QWK_STORAGE_OBJECT_server1_LK_localdomain=/nfs/general/nodeA
QWK_STORAGE_OBJECT_server2_LK_localdomain=/nfs/general/nodeB
또한 /etc/default/LifeKeeper의 기존 설정 중 하나를 조정해야 합니다.
QUORUM_MODE=저장소
WITNESS_MODE 및 QUORUM_MODE를 모두 스토리지로 설정한 이유를 이해하려면 다음 표를 살펴보세요.
지원되는 쿼럼 모드와 감시 모드의 조합
LifeKeeper는 다음 조합을 지원합니다.
| QUORUM_MODE | |||||
| 다수 | tcp_remote | 저장 | 없음/꺼짐 | ||
| WITNESS_MODE | 원격_확인 | 지원3개 이상의 노드 | 지원3개 이상의 노드 | 지원되지 않음 | 지원3개 이상의 노드 |
| 저장 | 지원되지 않음 | 지원되지 않음 | 지원됨2~4개 노드 사이 | 지원되지 않음 | |
| 없음/꺼짐 | 지원3개 이상의 노드 | 지원2개 이상의 노드 | 지원되지 않음 | 지원됨 | |
쿼럼에 대해 외부 저장소를 사용하려는 2노드 클러스터가 있으므로 지원되는 유일한 조합은 두 값 모두에 대해 ‘저장소’입니다. 그러나 더 많은 노드가 필요할 때 이것이 얼마나 유연한지 표를 통해 확인할 수 있으며, 이는 통신을 달성하고 쿼럼을 제공하는 다양한 방법을 제공합니다.
4단계: 감시 파일 초기화:
감시 파일을 초기화하고 사용을 활성화하려면 각 노드에서 다음 명령을 실행해야 합니다.
[root@server1-LK ~]# /opt/LifeKeeper/bin/qwk_storage_init
각 노드가 완료될 때까지 실행이 일시 중지되므로 클러스터의 첫 번째 노드에서 명령을 실행한 다음 두 번째 노드 등에서 명령을 실행한 후 다시 돌아와서 명령이 오류 없이 완료되었는지 확인합니다.
예:
[root@server1-LK ~]# /opt/LifeKeeper/bin/qwk_storage_init
ok: LifeKeeper가 실행 중입니다.
ok: LifeKeeper 라이센스 키가 성공적으로 설치되었습니다.
ok: QWK 매개변수가 유효합니다.
/nfs/general/nodeA의 QWK 개체는 아직 사용할 수 없습니다.
/nfs/general/nodeA는 이미 QWK_STORAGE_OBJECT가 아닌 것으로 존재합니다: 덮어쓰시겠습니까? (y/n): y
ok: QWK 개체의 경로가 유효합니다.
확인: 다운: /opt/LifeKeeper/etc/service/qwk-storage: 1377s
ok: 자체 노드의 QWK 객체 초기화가 완료되었습니다.
/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.
/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.
/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.
/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.
/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.
/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.
/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.
ok: 쿼럼 시스템이 준비되었습니다.
ok: 실행: /opt/LifeKeeper/etc/service/qwk-storage: (pid 14705) 1s, 일반적으로 다운
성공적인.
5단계: 구성 확인:
다음 명령을 실행하여 구성을 확인할 수 있습니다.
/opt/LifeKeeper/bin/lktest
오류가 발견되면 터미널에 인쇄됩니다. 아래 예에서는 호스트 이름의 특수 문자를 바꾸지 않았으므로 스토리지를 찾을 수 없음이 강조되었습니다.
[root@server1-LK ~]# /opt/LifeKeeper/bin/lktest
/opt/LifeKeeper/bin/lktest: /etc/default/LifeKeeper[308]: QWK_STORAGE_OBJECT_server1_LK.localdomain=/nfs/general/nodeA: 찾을 수 없음
/opt/LifeKeeper/bin/lktest: /etc/default/LifeKeeper[309]: QWK_STORAGE_OBJECT_server2_LK.localdomain=/nfs/general/nodeB: 찾을 수 없음
FS UID PID PPID C CLS PRI NI SZ STIME TIME CMD
4 S 루트 2348 873 0 TS 39 -20 7656 15:49 00:00:00 lcm
4 S 루트 2388 882 0 TS 39 -20 59959 15:49 00:00:00 ttymonlcm
4 S 루트 2392 872 0 TS 29 -10 10330 15:49 00:00:00 lcd
4 S 루트 8591 8476 0 TS 19 0 7670 15:58 00:00:00 lcdremexec -d server2-LK.localdomain -e — cat /proc/mdstat
다음과 같이 명령줄을 통해 감시 파일이 업데이트되고 있는지 확인할 수도 있습니다.
[root@server1-LK ~]# cat /nfs/general/nodeA
서명=lifekeeper_qwk_object
local_node=server1-LK.localdomain
시간=2024년 2월 15일 목요일 14:10:56
시퀀스=157
노드=server2-LK.localdomain
통신상태=UP
체크섬=13903688106811808601
NFS를 사용한 성공적인 파일 공유 감시
NFS를 사용하여 파일 공유 감시를 설정하는 것은 쉽습니다! 두 개의 노드로 제한되어 있지만 특히 AWS의 EFS와 같은 기능을 활용할 수 있는 클라우드에서 분할 브레인 이벤트에 대한 더 나은 복원력이 필요한 경우 강력할 수 있습니다. 또 다른 필수 부분은 더 많은 통신 경로를 활용할 수 있지만 이는 다른 블로그입니다. 그러나 이 가이드에 설명된 단계를 따르면 클러스터링된 애플리케이션의 복원력을 향상하고 가동 중지 시간의 위험을 최소화할 수 있습니다. 항상 참고하세요SIOS 문서고가용성 설정에 대한 추가 지침 및 최적화를 위한 모범 사례입니다. 공개적으로 이용 가능하며 매우 포괄적입니다!
SIOS 고가용성 및 재해 복구
SIOS Technology Corporation이 제공하는고가용성그리고재해 복구가장 중요한 애플리케이션에 대한 클러스터 관리를 통해 IT 인프라를 보호하고 최적화하는 제품입니다.오늘 저희에게 연락하십시오당사 서비스 및 전문 지원에 대한 자세한 내용을 알아보십시오.
다음의 허가를 받아 복제됨시오스