LVS+Keepalived에 대한 자세한 설명

고도의 정보화 기반 IT 시대에 기업의 생산 시스템, 사업 운영, 판매 및 지원, 일상 관리 등이 컴퓨터 정보 및 서비스에 점점 더 의존하고 있으며, 이에 따라 고가용성(HA) 기술 적용에 대한 요구도 지속적으로 증가하고 있습니다. 지속적이고 중단 없는 컴퓨터 시스템 또는 네트워크 서비스를 제공합니다.

Keepalived는 VRRP 프로토콜을 기반으로 하는 LVS 서비스용 고가용성 솔루션으로, 정적 라우팅의 단일 실패 지점 문제를 해결할 수 있습니다.

1. Keepalived 도구 및 기능

LVS 및 HA용으로 특별히 설계된 상태 확인 도구

1. LVS 로드 밸런싱 소프트웨어 관리

keepalived는 자체 구성 파일을 읽어 하위 레벨 인터페이스를 통해 LVS 구성과 서비스 시작 및 중지 기능을 직접 관리할 수 있으므로 LVS 애플리케이션이 더욱 쉬워집니다.

2. 자동 장애 조치(Failover) 지원

① 두 호스트 모두에 Keepalived를 설치하고 동시에 서비스를 시작합니다.

마스터 호스트는 기동 시 모든 자원을 획득하여 사용자에게 서비스(요청)를 제공하며, 색보정 백업 호스트 사용 시에는 마스터 상시 대기 역할을 수행한다.

마스터 호스트가 중단되고 장애가 발생하면 백업 호스트는 VIP 리소스 및 해당 리소스 서비스 인수를 포함하여 마스터 호스트의 모든 작업을 자동으로 인수합니다.

② 마스터 호스트 장애가 복구되면 자동으로 원래 처리 작업을 이어받고, 백업 호스트도 마스터 호스트 장애 시 맡았던 작업을 해제합니다.이 시점에서 두 호스트는 원래 역할로 돌아갑니다. 처음 시작했을 때 작동 상태

선점 모드: 마스터가 장애를 복구한 후 백업 노드에서 VIP를 점유합니다.

비선점: 마스터가 장애를 복구한 후 백업을 선점하지 않고 마스터 이후에 백업이 VIP로 업그레이드됩니다.

3. 노드 상태 점검 지원(Health Checking)

keepalived.conf 파일은 LVS를 직접 관리하기 위해 LVS의 노드 IP 및 관련 매개 변수를 구성합니다.

여러 노드 서버가 동시에 실패하고 서비스를 제공할 수 없는 경우, 연결 유지 서비스는 자동으로 LVS 일반 전달 목록에서 실패한 노드 서버를 제거하고 사용자 액세스가 영향을 받지 않도록 다른 일반 노드 서버에 대한 요청을 예약합니다. 장애가 발생한 노드 서버가 복구되면 Keepalived 서비스는 이를 일반 전달 목록에 추가하여 외부 고객에게 서비스를 제공합니다.

4. LVS 로드 밸런싱 스케줄링 서버 노드 서버의 고가용성(HA) 구현

일반적으로 엔터프라이즈 클러스터는 로드 밸런싱, 상태 확인 및 장애 조치의 세 가지 특성을 충족해야 하며, LVS + Keepalived를 사용하면 이러한 요구 사항을 완벽하게 충족할 수 있습니다.

2. 작동 원리

LVS 서비스 클러스터에는 일반적으로 마스터 서버(MASTER)와 백업 서버(BACKUP)의 두 가지 역할을 하는 서버가 있지만 외부에는 가상 IP로 나타나며 마스터 서버는 VRRP 알림 정보를 백업 서버로 보냅니다. 백업 서버가 이를 수신할 수 없는 경우, VRRP 메시지 수신 시, 즉 메인 서버에 이상이 있는 경우, 백업 서버가 가상 IP를 넘겨받아 계속 서비스를 제공함으로써 고가용성을 보장합니다.

Keepalived 고가용성은 VRRP를 통해 통신합니다. VRRP는 선택 메커니즘을 사용하여 마스터와 슬레이브를 결정합니다. 마스터는 슬레이브보다 우선순위가 높습니다. 따라서 작업 시 마스터가 모든 리소스를 먼저 획득하고 슬레이브 노드는 대기 상태에 있습니다. 상태 마스터 노드에 장애가 발생하면 대기 노드가 기본 노드의 자원을 인수한 후 기본 노드를 교체하여 외부 서비스를 제공합니다.

Keepalived 서비스 사이에서는 마스터 서버만이 항상 VRRP 브로드캐스트 패킷을 보내 백업 서버에 살아 있음을 알리는데, 이때 백업 서버는 마스터를 선점하지 않습니다. 마스터가 보낸 브로드캐스트 패킷을 들을 수 없으면 비즈니스 연속성을 보장하기 위해 관련 서비스를 시작하여 리소스를 인수합니다. 가장 빠른 인수 속도는 1초 미만일 수 있습니다.

3. Keepalived 구현 원칙

Keepalived는 VRRP 핫 백업 프로토콜을 사용하여 Linux 서버의 다중 머신 핫 백업 기능을 구현합니다.

4. Keepalived의 주요 모듈

Keepalived 아키텍처에는 core, check 및 vrrp라는 세 가지 주요 모듈이 있습니다.

핵심 모듈: keepalived의 핵심이며 기본 프로세스의 시작 및 유지 관리와 전역 구성 파일의 로드 및 구문 분석을 담당합니다.

vrrp 모듈: VRRP 프로토콜을 구현하는 데 사용됩니다.

check 모듈: 상태 확인을 담당하며 일반적인 방법에는 포트 확인 및 URL 확인이 포함됩니다.

5. VRRP(가상 라우터 중복 프로토콜)

라우터용 백업 솔루션입니다.
상시 대기 그룹은 다수의 라우터로 구성되며, 공유된 가상 IP 주소를 통해 외부 서비스를 제공합니다.
각 핫 대기 그룹에서는 하나의 기본 라우터만 동시에 서비스를 제공하고 다른 라우터는 중복 상태에 있습니다.
현재 온라인 라우터에 장애가 발생하면 설정된 우선순위에 따라 다른 라우터가 자동으로 가상 IP 주소를 넘겨받아 서비스를 계속 제공합니다.

VRRP 통신 원리:

VRRP는 가상 라우터 중복 프로토콜(Virtual Router Redundancy Protocol, 프로토콜 번호: 112)입니다. 이는 정적 라우팅의 단일 실패 지점을 해결하는 것으로 보입니다.

VRRP는 캠페인 프로토콜 메커니즘을 사용하여 라우팅 작업을 VRRP 라우터에 할당합니다.

VRRP는 고가용성 통신을 달성하기 위해 IP 멀티캐스트(기본 멀티캐스트 주소: 224.0.0.18)를 사용합니다.

작업 시 기본 노드는 패킷을 보내고 백업 노드는 패킷을 수신하며, 백업 노드가 기본 노드에서 보낸 데이터 패킷을 수신할 수 없는 경우 인계 프로그램을 시작하여 기본 노드의 자원을 인수합니다. 우선순위를 통해 선출되는 대기 노드는 여러 개가 있을 수 있지만 일반적으로 Keepalived 시스템 운영 및 유지 관리 작업에는 한 쌍만 있습니다.

Keepalive 서비스가 정상적으로 작동하면 마스터 노드는 백업 노드에 하트비트 메시지를 지속적으로 보내(멀티캐스트) 백업 노드에 자신이 아직 살아 있음을 알리고, 마스터 노드에 장애가 발생하면 우울증 메시지를 보낼 수 없습니다. 기본 노드의 하트비트를 감지할 수 없으므로 자체 인수 프로그램을 호출하여 기본 노드의 IP 자원 및 서비스를 인수합니다. 기본 노드가 복구되면 대기 노드는 기본 노드에 장애가 발생했을 때 인수했던 IP 리소스와 서비스를 해제하고 원래의 대기 역할로 돌아갑니다.

VRRP는 암호화 프로토콜을 사용하여 데이터를 암호화하지만 Keepalived 관계자는 현재 인증 유형과 비밀번호를 일반 텍스트로 구성할 것을 권장합니다.

vrrp는 여러 라우터를 가상 라우팅 그룹 vrid로 구성합니다. vrrp는 가상 경로(가상 IP 및 가상 MAC 포함)를 생성합니다. LAN 사용자는 어느 것이 마스터이고 어느 것이 백업인지 상관하지 않습니다. 그들은 가상 경로만 사용합니다. 가상 라우터의 IP를 게이트웨이로 사용) 실제로 가상 IP는 마스터 라우터에서 호스팅되므로 실제 데이터가 마스터를 통해 전달됩니다.

백업은 우선 순위에 따라 마스터 경로를 결정합니다. 우선 순위가 가장 높은 경로가 마스터입니다. 백업은 마스터가 보낸 vrrp 메시지를 정기적으로 모니터링하는 데에만 사용됩니다. 마스터가 보낸 vrrp 메시지가 해당 경로 내에 수신되지 않는 경우 시간이 초과되면 백업이 마스터를 점유하는 경우 가상 IP도 백업 헤드로 이동합니다.

6. 장애 조치 메커니즘

Keepalived 고가용성 서비스 간의 장애 조치 전송은 VRRP를 통해 구현됩니다.

Keepalived 서비스가 정상적으로 작동할 때 메인 마스터 노드는 백업 노드에 하트비트 메시지를 지속적으로 보내(멀티캐스트) 백업 노드가 아직 살아 있음을 알립니다.메인 마스터 노드에 장애가 발생하면 하트비트 메시지를 보낼 수 없으며 백업 노드는 하트비트 메시지를 보낼 수 없으므로 노드는 더 이상 마스터 노드의 하트비트를 감지할 수 없으므로 자체 인수 프로그램을 호출하여 마스터 노드의 IP 자원 및 서비스를 인수합니다.

마스터 노드가 복구되면 백업 노드는 마스터 노드 장애 시 인수했던 IP 리소스와 서비스를 해제하고 원래의 백업 역할로 돌아갑니다.

7. Keepalived 스플릿 브레인과 그 솔루션

1. 연결 유지 분할 두뇌

고가용성(HA) 시스템에서는 두 노드를 연결하는 '하트비트 라인'의 연결이 끊어지면 원래 전체적이고 조율된 작업이었던 HA 시스템이 두 개의 독립된 개체로 분할됩니다. 서로 연락이 끊겼기 때문에 두 사람 모두 상대방이 오작동을 일으켰다고 생각했습니다. 두 노드의 HA 소프트웨어는 "공유 리소스"와 "애플리케이션 서비스"를 놓고 경쟁하는 "분할 두뇌 인간"과 같으며 심각한 결과가 발생하거나 공유 리소스가 분할되어 양쪽의 "서비스"가 발생합니다. 서비스를 제공할 수 없게 됩니다. 또는 양측의 "서비스"가 작동 중이지만 "공유 저장소"를 동시에 읽고 쓰므로 데이터 손상이 발생합니다(일반적으로 온라인 로그의 오류 등) 데이터베이스 폴링의 경우).

2. 분할뇌의 원인

고가용성 서버 쌍 간의 하트비트 링크가 실패하여 정상적인 통신이 실패했습니다. 예를 들어, 하트비트 케이블이 끊어졌습니다(손상 또는 노화 포함).

네트워크 카드 및 관련 드라이버가 깨져서 IP 구성 및 충돌 문제(네트워크 카드 직접 연결)가 발생합니다.

하트비트 케이블(네트워크 카드 및 스위치) 사이에 연결된 장비의 고장으로 인해.

중재 기계에 문제가 있습니다(중재 솔루션 사용).

고가용성 서버에는 iptables 방화벽이 활성화되어 하트비트 메시지 전송을 차단합니다.

Keepalived 구성에서 동일한 VRRP 인스턴스의 양쪽 끝에 있는 virtual_router_id 매개변수 구성이 일치하지 않는 경우에도 분할 브레인 문제가 발생합니다.

vrrp 인스턴스 이름은 일관되지 않고 우선순위는 일관됩니다.

3. 솔루션

이중선(하트비트 선도 HA임)과 같은 중복 하트비트 선을 추가하여 "분할 브레인" 가능성을 최소화합니다.

디스크 잠금을 활성화합니다. 서버가 공유 디스크를 잠그는 경우 "분할 브레인"이 발생하면 상대방은 공유 디스크 리소스를 완전히 빼앗을 수 없습니다. 그러나 잠긴 디스크를 사용하는 데에는 큰 문제가 있는데, 공유 디스크를 점유하고 있는 당사자가 적극적으로 "잠금 해제"하지 않으면 상대방은 공유 디스크를 결코 얻을 수 없습니다. 실제로 서비스 노드가 갑자기 정지되거나 충돌이 발생하는 경우 잠금 해제 명령을 실행할 수 없습니다. 백업 노드는 공유 리소스 및 애플리케이션 서비스를 인계받을 수 없습니다. 그래서 누군가 HA에서 "스마트" 잠금 장치를 설계했습니다. 즉, 서비스 제공자는 모든 하트비트 라인의 연결이 끊어진 것을 발견한 경우에만 디스크 잠금을 활성화합니다(피어는 이를 인식하지 못합니다). 일반적으로 잠겨 있지 않습니다.

중재 메커니즘을 설정합니다. 예를 들어, 참조 IP(예: 게이트웨이 IP)를 설정한 경우 하트비트 라인이 완전히 끊어지면 두 노드가 각각 참조 IP를 핑하고, 연결이 없으면 중단점이 로컬 끝에 있음을 의미합니다. "하트비트"뿐만 아니라 외부 "서비스"에 대한 로컬 네트워크 링크도 끊어졌습니다. 응용 프로그램 서비스를 시작(또는 계속)해도 소용이 없습니다. 그러면 적극적으로 경쟁을 포기하고 참조 IP를 핑할 수 있는 끝이 시작되도록 하십시오. 서비스. . 보다 안전하기 위해 참조 IP를 핑할 수 없는 당사자는 스스로를 다시 시작하여 여전히 점유되어 있는 공유 리소스를 완전히 해제합니다.