DRDB 및 NFS : 장애 조치 복원 중 NFS 가동 중지 시간


0

DRBD와 NFS를 처음 접했고 회사의 NFS 공유에 사용할 하트 비트로 DRDB 서버를 테스트하는 과정에 있습니다.

NFS 상태 디렉토리가 실제 공유와 함께 DRDB 공유에서 실행되면서 전체 설정이 정상적으로 실행됩니다.

내가 겪고있는 문제는 테스트중인 장애 조치 시나리오에서 비롯됩니다. 장애 조치 시나리오에서는 node1에서 네트워크 연결 (ifconfig eth0 down)을 비활성화하는 문제가 발생합니다. 장애 조치는 훌륭하게 작동하고 약 5 초 안에 작업을 수행하지만 다시 가져 오면 (ifconfig eth0 및 중지되면 서비스 하트 비트 시작) NFS가있는 동안 다시 가져 오는 데 3-5 분 이상 걸립니다. 공유를 사용할 수 없습니다.

웹 환경에서이 3-5 분은 가동 중지 시간에 매우 중요합니다. 이것이 정상입니까? 내가 무엇을 잘못하고 있지?

drbd.conf 파일을 아래에 붙여 넣었습니다.

resource r0 {
 protocol C;
 startup {
    degr-wfc-timeout 60;    # 1 minute.
  }
  disk {
    on-io-error   detach;
  }
  net {
  }
  syncer {
    rate 10M;
    al-extents 257;
  }
 on tsa-dev-nfstest1 {                # ** EDIT ** the hostname of server 1 (un
   device     /dev/drbd0;        #
   disk       /dev/sdc1;         # ** EDIT ** data partition on server 1
   address    10.61.2.176:7788; # ** EDIT ** IP address on server 1
   meta-disk  /dev/sdb1[0];      # ** EDIT ** 128MB partition for DRBD on serve
  }
 on tsa-dev-nfstest2 {                # ** EDIT ** the hostname of server 2 (un
   device    /dev/drbd0;         #
   disk      /dev/sdc1;          # ** EDIT ** data partition on server 2
   address   10.61.2.177:7788;  # ** EDIT ** IP address on server 2
   meta-disk /dev/sdb1[0];       # ** EDIT ** 128MB partition for DRBD on serve
  }
}

답변:


0

하트 비트 자원 그룹에 NFS 서비스를위한 논리 IP가 포함되어 있습니까?

마지막으로 "위로"올라간 리소스는 "아래로"마지막 리소스 여야합니다. 클라이언트는이 IP를 사용하여 NFS 서비스에 액세스해야합니다.

IP를 정의한 경우 IPAddr에 대해 다른 리소스 유형 (내가 기억하는 한 IPAddr2)을 사용하려고 할 수 있습니다. IP 스택에서 약간 다르게 동작합니다.

기본적으로 두 가지 유형 모두 IP가 시작된 후 arp- 브로드 캐스트로 연결해야합니다. 연결된 라우터와 스위치가 mac-table을 다시 학습하여 장애 조치가 발생한 후 패킷을 전달할 위치를 알아야합니다.

일부 NFS 구현에서는 이미 연결된 클라이언트를 명시 적으로 arp해야합니다. 이를 위해 연결된 클라이언트 데이터를 대기 노드에도 미러링해야합니다.


0

회사의 drbd 백업 고 가용성 NFS 서버를 개발하는 동안 클러스터 된 IP가 테스트 후 원래 노드로 돌아 왔을 때 클라이언트에 몇 분 (최대 약 10)의 다운 타임이 있음을 발견했습니다. 이 상황에서 새 연결이 즉시 수락되어 서비스되었지만 이미 연결된 클라이언트가이 분의 다운 타임을 경험했습니다.

tcpdump를 사용하여 네트워크 트래픽을 검사 한 후 TCP 연결이 시퀀스 번호의 동기화를 벗어나서 재설정해야하는 문제라는 것을 알았습니다.

하트 비트 대신 Pacemaker를 사용하여 클러스터를 관리하는 것이 좋습니다. 그렇게하면 실제 상황에서 Pacemaker는이 상황이 발생하지 않도록하는 STONITH (헤드의 다른 노드 촬영) 요청을 발행 할 수 있습니다. 기본적으로 다른 노드를 재부팅하여 TCP 문제를 해결합니다.

또한 Pacemaker는 모니터링에서 하트 비트보다 훨씬 좋습니다. 이 사이트를 살펴보십시오 :

맥박 조정 장치

Linbit의 NFS over DRBD

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.