장애 조치가 발생하는 원인은 무엇입니까?

Date: 5월 11, 2024

장애 조치가 발생하는 원인은 무엇입니까?

지원 업무를 하면서 우리가 고객으로부터 받는 가장 일반적인 질문 중 하나는 “무엇이장애 조치내 기본 노드에서 보조 노드로?”

이러한 현상이 발생하는 데는 여러 가지 이유가 있습니다. 가장 일반적인 원인과 이를 식별하는 방법을 설명하겠습니다.

시작하기 전에 먼저‘장애 조치’와 ‘전환’을 구별합니다., 많은 고객이 이러한 용어를 같은 의미로 사용하기 때문입니다.

‘전환’은 계층 구조를 기본 노드에서 보조 노드로 수동으로 이동하는 작업입니다. 이 작업은 보조 노드에서 ‘서비스 중’을 수행하거나 명령줄을 통해 GUI를 통해 수행할 수 있습니다.

Perform_action -a Restore -t $LKTag(계층 구조를 서비스로 가져옴)

반면에 ‘장애 조치’는 수동 상호 작용 없이 수행되며 이전에 활성화된 서버, 애플리케이션 또는 하드웨어/네트워크에 오류가 발생하면 백업 서버로 자동 전환되는 것으로 정의됩니다.

장애 조치(failover)와 전환(switchover)은 장애 조치(failover)가 자동이고 전환이라는 점을 제외하면 본질적으로 동일한 작업입니다.보통 경고 없이 작동함, 전환은 의도적이며 사람의 개입이 필요합니다.

다음은 ‘장애 조치’를 시작하는 가장 일반적인 ‘실패’입니다.

1. 서버 수준 원인

서버 장애

• 기본 서버의 전원이 꺼지거나 꺼졌습니다.
• 과도한 로드로 인한 CPU 사용량 — 매우 높은 I/O 로드에서 지연 및 메모리 부족 상태로 인해 시스템이 응답하지 않을 수 있습니다.생명의 수호자서버가 다운된 것을 감지하고 장애 조치를 시작할 수 있습니다.
• 쿼럼/감시 – 쿼럼/감시 I/O 펜싱 메커니즘의 일부로 기본 서버가 쿼럼을 잃으면 “빠른 부팅“:,”빨리 죽여라” 또는 “오수“가 수행되고(설정에 따라) 장애 조치가 시작됩니다. 장애 조치(failover) 시기를 결정할 때 미러링 모니터 서버는 주 서버가 실패했고 더 이상 클러스터의 일부가 아님을 확인하는 경우에만 리소스가 백업 서버에서 서비스되도록 허용합니다. 이렇게 하면 해당 오류가 서비스 중인 노드에 대한 전반적인 액세스 및 성능에 영향을 미치지 않는 경우 노드 간의 단순한 통신 오류로 인해 발생하는 장애 조치를 방지할 수 있습니다.

통신(하트비트) 실패

LifeKeeper에는 페어링된 서버가 작동 중임을 구성에 있는 각 서버에 주기적으로 알리는 “하트비트” 신호가 내장되어 있습니다. 기본적으로 LifeKeeper는 5초마다 서버 간에 하트비트를 보냅니다(사용량이 많은 클러스터에 대해 조정 가능). 통신 문제로 인해 심장 박동이 두 번 건너뛰었지만 세 번째 심장 박동에서 재개되는 경우 LifeKeeper는 아무런 조치도 취하지 않습니다. 그러나 통신 경로가 3비트 동안 작동하지 않는 경우 LifeKeeper는 해당 통신 경로를 작동하지 않는 것으로 표시합니다. 중복 통신 경로도 작동하지 않는 경우 장애 조치를 시작합니다(두 개의 경로 권장).

다음과 같은 경우 하트비트가 누락될 수 있습니다.

• 기본 서버에 대한 네트워크 연결이 끊어졌습니다.
• 네트워크 대기 시간.
• TCP 통신 경로의 과도한 네트워크 트래픽으로 인해 잘못된 장애 조치 및 LifeKeeper 초기화 문제를 비롯한 예상치 못한 동작이 발생할 수 있습니다.
• NIC에 오류가 발생했습니다.
• 네트워크 전환에 실패했습니다.
• 수동으로 네트워크 연결 풀링/제거
• 기본 서버의 전원이 꺼지거나 꺼졌습니다.
• 과도한 로드로 인한 CPU 사용량 — I/O 로드가 매우 심한 경우 지연 및 메모리 부족 상태로 인해 시스템이 응답하지 않게 되어 LifeKeeper가 서버가 다운된 것을 감지하고 장애 조치를 시작할 수 있습니다.

하트비트 매개변수 조정:

LCMNUMHBEATS=Y(여기서 Y는 통신 경로 실패 오류를 로그에 기록하기 전의 하트비트 수입니다). 기본값은 3이며 시스템이 사용량이 많거나 잘못된 통신 경로 실패를 방지하기 위해 WAN을 통과하는 경우 변경할 수 있습니다.

LCMHBEATTIME=5(초 단위 간격이며 기본값이며 변경하면 안 됩니다).

이러한 조정 가능 항목은 기본적으로 /etc/default/LifeKeeper 파일에 없습니다. 하트비트 값을 변경하려면 이를 추가해야 합니다.

/etc/default/LifeKeeper에 이러한 조정 가능 항목과 값을 추가한 후 LifeKeeper를 중지하고 다시 시작해야 합니다. LifeKeeper를 중지하지만 보호된 응용 프로그램을 종료하지 않는 lkstop -f 명령을 사용할 수 있습니다.

그리고 두 시스템 모두에서 이 작업을 수행해야 합니다.

LifeKeeper가 통신 경로를 실패로 표시하기 전에 5회 Y초가 소요됩니다.

분할 브레인(Split-Brain)이란 무엇이며 그 원인은 무엇입니까?

단일 통신 경로가 사용되고 통신 경로가 실패하는 경우 LifeKeeper 계층은 여러 시스템에서 동시에 서비스를 시도할 수 있습니다. 이를 잘못된 장애 조치(failover) 또는 “분할 브레인(split-brain)” 시나리오라고 합니다. 에서“분할 두뇌” 시나리오, 각 서버는 자신이 애플리케이션을 제어하고 있다고 믿고 공유 저장 장치에 액세스하여 데이터를 쓰려고 시도할 수 있습니다. 분할 브레인 시나리오를 해결하기 위해 LifeKeeper는 모든 공유 데이터의 데이터 무결성을 보장하기 위해 서버의 전원을 끄거나 재부팅하거나 계층 구조를 서비스 중단 상태로 둘 수 있습니다. 또한 TCP 통신 경로의 과도한 네트워크 트래픽으로 인해 잘못된 장애 조치 및 LifeKeeper의 적절한 초기화 실패 등 예상치 못한 동작이 발생할 수 있습니다.

다음은 분할 브레인이 발생할 수 있는 시나리오입니다.

• 위에 나열된 통신 오류 중 하나
• LifeKeeper의 부적절한 종료
• 서버 리소스 부족
• 모든 네트워크 경로 손실
• DNS 또는 기타 네트워크 결함
• 시스템 잠금

쿼럼/감시를 사용하여 분할 브레인 방지

• LifeKeeper용 쿼럼/위트니스 서버 지원 패키지(steeleye-lkQWK, 이하 “쿼럼/위트니스 패키지”)는 LifeKeeper 코어의 기존 장애 조치 프로세스와 결합되어 전체 네트워크 장애가 발생할 수 있는 상황에서 시스템 장애 조치가 더 큰 확신을 가지고 발생할 수 있도록 합니다. 흔하다. 이는 로컬 사이트 장애 조치 및 WAN을 통한 노드에 대한 장애 조치를 수행하는 동시에 다음과 같은 위험을 크게 줄일 수 있음을 의미합니다.분할 두뇌상황.
• 네트워크 분할을 고려하는 분산 시스템에는 클러스터 전체의 합의를 얻기 위해 쿼럼이라는 개념이 있습니다. 쿼럼을 갖는 노드는 모든 클러스터의 합의를 얻을 수 있고 자원을 서비스에 가져올 수 있는 노드입니다. 반면, 쿼럼이 없는 노드는 모든 클러스터의 합의를 얻을 수 없고 자원을 서비스할 수 없는 노드입니다. 이렇게 하면 분할 뇌가 발생하는 것을 방지할 수 있습니다. 노드에 쿼럼이 있는지 확인하는 것을 쿼럼 확인이라고 합니다. 쿼럼이 있으면 “쿼럼 확인 성공”으로 표시되고, 쿼럼이 없으면 “쿼럼 확인 실패”로 표시됩니다.
• 통신 오류가 발생한 경우 오류가 발생한 노드 하나와 다른 여러 노드(또는 기타 장치)를 사용하면 노드가 오류가 발생한 노드의 상태에 대한 “2차 의견”을 얻을 수 있습니다. “2차 의견”을 얻는 노드를 증인 노드(또는 증인 장치)라고 하며, “2차 의견”을 얻는 것을 증인 확인이라고 합니다. 장애 조치 시기를 결정할 때 감시 노드(감시 장치)는 기본 서버가 실패했고 더 이상 클러스터의 일부가 아님을 확인하는 경우에만 백업 서버에서 리소스를 서비스할 수 있도록 허용합니다. 이렇게 하면 해당 오류가 서비스 중인 노드에 대한 전반적인 액세스 및 성능에 영향을 미치지 않는 경우 노드 간의 단순한 통신 오류로 인해 장애 조치가 발생하는 것을 방지할 수 있습니다. 실제 작동 중에 LifeKeeper가 시작되거나 실패한 통신 경로가 복원되면 감시 노드(감시 장치)가 참조됩니다. 증인 확인은 쿼럼이 있는 노드에 대해서만 수행할 수 있습니다.

2. 자원 장애 원인

LifeKeeper는 개별 응용 프로그램 및 관련 응용 프로그램 그룹을 모니터링하고 보호된 응용 프로그램이 실패할 경우 주기적으로 로컬 복구 또는 알림을 수행하도록 설계되었습니다. 예를 들어 관련 애플리케이션은 기본 애플리케이션이 하위 수준 스토리지 또는 네트워크 리소스에 의존하는 계층입니다. LifeKeeper는 이러한 보호된 리소스의 상태를 모니터링합니다. 리소스가 장애 상태로 판단되면 외부 개입 없이 현재 시스템(서비스 중인 노드)에서 리소스나 애플리케이션을 복원하려고 시도합니다. 이 로컬 복구가 실패하면 리소스 장애 조치가 시작됩니다.

신청 실패

• 애플리케이션 오류가 감지되었지만 로컬 복구 프로세스가 실패했습니다.
• 오류 제거 – 리소스 장애 조치 프로세스 중에 중요한 애플리케이션의 전체 기능을 제공하려면 특정 리소스를 기본 서버의 서비스에서 제거한 다음 선택한 백업 서버의 서비스로 가져와야 합니다. 이 제거 프로세스가 실패하면 기본 서버 재부팅이 수행되어 완전한 서버 장애 조치가 수행됩니다.

제거 실패의 예:

• 파일 시스템을 마운트 해제할 수 없습니다.
• 보호된 애플리케이션(oracle, mysql, postgres 등)을 종료할 수 없습니다.

파일 시스템 문제

• 디스크 가득 참 – LifeKeeper의 파일 시스템 상태 모니터링은 파일 시스템 리소스의 장애 조치를 초래할 수 있는 디스크 가득 참 파일 시스템 상태를 감지할 수 있습니다.
• 마운트 해제되거나 잘못 마운트된 파일 시스템 – 사용자가 서비스 내 및 LK 보호 파일 시스템에서 옵션을 수동으로 마운트 해제하거나 변경합니다.
• 재마운트 실패 – 다음은 장애 조치로 이어질 수 있는 재마운트 실패의 일반적인 원인 목록입니다.
• 손상된 파일 시스템(fsck 실패)
• 마운트 지점 디렉터리 생성 실패
• 마운트 포인트가 사용 중입니다
• 마운트 실패
• LifeKeeper 내부 오류

IP 주소 실패

IP 복구 키트에서 IP 주소 오류가 감지되면 결과 오류로 인해 IP 로컬 복구 스크립트가 실행됩니다. LifeKeeper는 먼저 현재 네트워크 인터페이스에서 IP 주소를 다시 서비스하도록 시도합니다. 로컬 복구 시도가 실패하면 LifeKeeper는 IP 주소와 모든 종속 리소스를 백업 서버로 장애 조치합니다. 장애 조치 중에 제거 프로세스는 백업 서버에서 구성될 수 있도록 현재 서버에서 IP 주소의 구성을 해제합니다. 이 제거 프로세스가 실패하면 시스템이 재부팅됩니다.

• IP 충돌
• IP 충돌
• DNS 확인 실패
• NIC 또는 스위치 오류

예약 충돌

• 보호된 장치에 대한 예약이 분실되거나 도난당했습니다.
• 보호된 리소스 장치의 예약 또는 제어를 다시 얻을 수 없음(수동 사용자 개입, HBA 또는 스위치 오류로 인해 발생)

SCSI 장치

• 보호된 SCSI 장치를 열 수 없습니다. 장치에 오류가 있거나 시스템에서 제거되었을 수 있습니다.

장애 조치 원인을 식별하기 위한 리소스

/var/log/lifekeeper.log

LifeKeeper가 작성한 이 로그 파일은 장애 조치의 원인을 판별할 때 가장 먼저 살펴봐야 할 곳입니다.

예를 들어, 가장 일반적인 이유 중 하나는 통신 경로 오류입니다. 다음은 이러한 상황이 발생할 때 lifekeeper.log에서 찾을 수 있는 항목의 예입니다.

_{Sep 21 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:dev 10.236.17.226/10.238.17.226(lcm 드라이버 번호 = 129)에서 하트비트 48개 중 1개를 놓쳤습니다.}

_{Sep 21 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:dev 10.236.17.226/10.237.17.226(lcm 드라이버 번호 = 1360929)에서 하트비트 48개 중 1개를 놓쳤습니다.}

_{Sep 21 11:07:02 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:dev 10.236.17.226/10.238.17.226(lcm 드라이버 번호 = 129)에서 하트비트 48개 중 2개를 놓쳤습니다.}

최대 하트비트 수에 도달하면 장애 조치가 시작됩니다.

_{Sep 21 11:10:49 es6ecc08tev lcm[9416]: INFO:lcm.tli_hand:::005257:dev 10.237.17.226/10.236.17.226(lcm 드라이버 번호 = 71)에서 하트비트 47/48이 누락되었습니다.}

_{9월 21일 11:10:49 es6ecc08tev eventslcm[47082]: WARN:lcd.net:::004258:10.237.17.226/10.236.17.226에 의한 es1ecc08tev와의 통신 실패}

_{Sep 21 11:10:49 es6ecc08tev eventslcm[47082]: WARN:lcd.net:::004261:COMMUNICATIONS 시스템 “es1ecc08tev”에서 장애 조치가 시작됩니다.}

_{9월 21일 11:10:49 es6ecc08tev lifekeeper[47121]: NOTIFY:event.comm_down:::010466:통신 es1ecc08tev 실패}

/var/log/메시지

이 Linux 생성 파일에는 일반적으로 시스템에서 실행되는 다양한 프로세스 및 서비스에 의해 생성된 시스템 메시지가 포함되어 있습니다. 이러한 메시지에는 다음이 포함될 수 있습니다.

시스템 부팅 메시지: 커널 메시지와 systemd 또는 기타 init 시스템의 메시지를 포함하여 시스템 부팅 프로세스에 대한 정보입니다.

서비스 시작 및 종료 메시지: 프로세스 중에 발생한 오류나 경고를 포함하여 서비스가 시작되거나 중지되는 시기를 나타내는 메시지입니다.

커널 메시지: 하드웨어 감지, 장치 초기화, 커널 오류 또는 경고를 포함한 Linux 커널 작동에 대한 정보입니다.

네트워크 관련 메시지: 네트워크 연결, 방화벽 활동 및 네트워크 구성 변경에 대한 정보입니다.

시스템 성능 정보: CPU 사용량, 메모리 사용량, 디스크 I/O 통계 등 시스템 성능 모니터링과 관련된 메시지입니다.

SIOS 고가용성 및 재해 복구

SIOS Technology Corporation이 제공하는고가용성그리고재해 복구가장 중요한 애플리케이션에 대한 클러스터 관리를 통해 IT 인프라를 보호하고 최적화하는 제품입니다.오늘 저희에게 연락하십시오자세한 내용은.

다음의 허가를 받아 복제됨시오스