☰

Pacemaker: 장애 조치로 인해 N번 마이그레이션한 후 리소스 중지

tag-icon • tag-icon cluster pacemaker
Pacemaker: 장애 조치로 인해 N번 마이그레이션한 후 리소스 중지

5개 노드로 구성된 구성이 있는데, 4개는 리소스를 호스팅할 수 있고 1개는 리소스를 호스팅할 수 있습니다. 내가 하고 싶은 것은 노드에서 노드로 N번 마이그레이션한 후 리소스를 완전히 중지시키는 것입니다.

따라서 샘플 시나리오는 다음과 같습니다. 노드에서 실행 중인 리소스 VIP1 one; 모니터가 실패하고 migration-threshold도달하면 노드로 이동합니다 two. 그런 다음 다시 실패하고 노드로 이동합니다 three. 그런 다음 다시 실패하지만 (제가 찾고 있는) 어떤 종류의 규칙으로 인해 node 로 마이그레이션되지 않습니다 four. 일종의 마이그레이션 카운터가 필요한 것 같아요.

이는 테스트 구성이므로 실제로는 더 많은 노드와 리소스를 갖게 됩니다. 그래서 구성은 최대한 간단하게 했으면 좋겠습니다. 각 리소스에 대한 선택 또는 선택 해제 위치 선호 전략을 사용하여 이를 달성할 수 있다고 생각하지만 이는 간단하지도 않고 쉽게 유지 관리할 수도 없습니다. 더 좋은 방법이 있나요?

PS 현재 구성에서 VIP를 으로 넘치게 하면 hping완전히 중지되기 전에 모든 노드를 순환하게 됩니다(정리하거나 옵션을 도입할 때까지 실행할 노드가 더 이상 없기 때문입니다 failure-timeout).

버전:

[~] corosync -v
Corosync Cluster Engine, version '2.3.6'
Copyright (c) 2006-2009 Red Hat, Inc.
[~] crm --version
crm 2.2.0
[~] cat /etc/debian_version
8.5

맥박 조정기 구성:

[~] crm configure show
node 1: one
node 2: two
node 3: three
node 4: arbitr \
        attributes standby=on
node 5: four
primitive VIP1 IPaddr2 \
        params ip=10.10.11.230 cidr_netmask=22 \
        op monitor interval=1s timeout=40ms \
        meta migration-threshold=1 target-role=Started
location preferOne VIP1 50: one
property cib-bootstrap-options: \
        dc-version=1.1.14-70404b0 \
        cluster-infrastructure=corosync \
        cluster-name=debian \
        stonith-enabled=false \
        last-lrm-refresh=1474984960 \
        have-watchdog=false

편집: 전체 구성의 컨텍스트와 내용은 다음과 같습니다. 프런트엔드로 트래픽을 프록시하는 LVS가 있는 두 개의 로드 밸런서가 있습니다. 고가용성은 단순한 연결 유지 구성과 2개의 VIP(활성-활성 구성, 일반적인 상황에서는 각 LVS에 1개의 VIP가 있음)를 통해 달성되었습니다. 그러나 일부 사용자는 최근 정기적으로 DDoS를 시작했으며 연결 유지 설정이 더 이상 예상대로 작동하지 않습니다. VIP 1개, 즉 호스트 1개만 DDoS를 하더라도 연결 유지는 다른 호스트의 인바운드 트래픽을 잃고 두 번째 VIP를 확보하여 전체를 손상시킵니다. 체계.

그래서 우리는 a) 브레인 분할을 방지하기 위해 정족수로 VIP를 관리할 수 있는 방법을 찾고; b) LVS 호스트의 두 배 이상.

그래서 맥박 조정기+corosync를 테스트했는데 활성 노드 2개와 대기 노드 1개가 있으면 구성이 정말 간단합니다. 예상한 대로 VIP 중 하나가 DDoSed이면 해당 VIP는 먼저 다른 노드로 마이그레이션한 다음 완전히 종료됩니다. 노드를 추가하면 '리소스 워크'가 길어지는데 이는 우리가 원하는 것과는 다릅니다. VIP가 가능한 한 빨리 종료되기를 원하지만 물론 내부 노드에서 자동으로 복구할 수 있는 기회도 남기고 싶습니다. 하드웨어 문제(노드가 갑자기 다운되면 FE). 그래서 저는... 리소스를 한 번만 마이그레이션하고, 그래도 실패하면 끝내는 방법이 있을 거라고 생각했습니다. 하드웨어 오류로부터 우리를 구해줍니다. 부분적인 DDoS 공격을 받을 때 시간을 절약해 줍니다.

그 정도입니다. 너무 자세하게 설명했다면 죄송합니다. 처음부터 이 문제를 처리하기 위해 잘못된 도구를 선택한 경우 알려 주시기 바랍니다. (물론 우리는 다른 방법으로 DDoS를 방어하지만, 공격이 성공한다면 피해를 최소화하고 싶습니다.)

답변1

확실히 흥미로운 사용 사례입니다. 공유해 주셔서 감사합니다...

VIP가 DDoS 공격을 받는 동안에는 안정적으로 핑을 보낼 수 없을 것입니다. 아마도 Pacemaker의 'ping' 리소스 에이전트를 살펴볼 수도 있습니다.

Clusterlabs 문서에서는 이에 대해 간략하게 언급합니다. http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ch09s03s03.html

선호하는 클러스터 구성 관리 도구를 통해 리소스 에이전트 정보를 확인하면 더 많은 정보를 찾을 수 있습니다.

# crm ra info ping
--or--
# pcs resource describe ping

도움이 되었기를 바랍니다.

관련 정보