회사 개요 #

이 가이드는 GSLB(Global Server Load Balancing / GTM) 구성을 검증하고 문제를 해결하기 위한 체계적인 접근 방식을 제공합니다. RELIANOID 특히 온프레미스에서 재해 복구(DR) 사이트로 서비스가 자동으로 장애 조치될 것으로 예상되는 환경에서 그렇습니다.

또한 애플리케이션 기반 공용 IP 및 내부 GSLB 서비스에 대한 모범 사례도 포함되어 있습니다.

검증 범위 #

이 가이드는 다음에 적용됩니다.

• 다중 사이트(온프레미스 + 재해 복구)를 사용하는 GSLB 배포
• 공용 IP를 통해 노출되는 서비스
• DNS 기반 페일오버를 사용 RELIANOID GSLB
• 상태 점검 기반 자동 장애 조치 시나리오

검증해야 할 주요 구성 요소 #

장애 조치 동작 문제를 해결하기 전에 다음 사항을 확인하십시오.

GSLB 구성 #

• GSLB 서비스가 다음과 같이 올바르게 구성되었습니다.
  • 다수의 백엔드 사이트(온프레미스 + 재해 복구)
  • 올바른 해상도 정책(우선순위, 지연 시간 등)을 설정하십시오.
• DNS 영역 및 레코드가 올바르게 정의되었습니다.

건강 검진 #

• 건강 검진 항목은 다음과 같습니다:
  • 모든 백엔드 서비스에 대해 활성화됨
  • 애플리케이션 엔드포인트를 정확하게 타겟팅해야 합니다(IP/포트만 사용하는 것이 아니라).
• 예상 응답 코드 또는 콘텐츠 유효성 검사가 구성되었습니다.

DNS 구성 #

• TTL 값이 적절하게 구성되었습니다(페일오버를 위해서는 낮은 TTL 값을 권장합니다).
• 권한 있는 DNS 서버가 다음을 가리키고 있습니다. RELIANOID GSLB

온프레미스에서 재해 복구(DR)로의 페일오버 유효성 검사 #

1단계: 정상 작동 확인 (주 작동) #

• DNS 쿼리 확인:

  파기

• 다음 사항을 확인하십시오.
  • 확인된 IP 주소는 온프레미스 사이트에 해당합니다.
  • 애플리케이션은 접근성이 좋고 건전합니다.

2단계: 고장 시뮬레이션 #

기본 사이트에서 장애 조건을 발생시키세요:

• 백엔드 서비스를 중지합니다.
• 블록 상태 확인 엔드포인트
• 농장 또는 백엔드를 비활성화합니다.

3단계: 상태 점검 감지 유효성 검사 #

• 확인하기 RELIANOID 주요 사이트를 다운으로 표시합니다.
• 로그 및 모니터링 시스템을 확인하여 다음 사항을 확인하십시오.
  • 건강 검진 결과가 예상대로 나오지 않고 있습니다.
  • 오탐/오류 없음

4단계: DNS 페일오버 유효성 검사 #

• DNS 쿼리를 다시 실행하세요:

  파기

• 예상 결과:
  • 이제 IP 주소가 재해 복구(DR) 사이트로 확인될 것입니다.

참고: DNS 캐싱은 TTL에 따라 전파를 지연시킬 수 있습니다.

5단계: 애플리케이션 가용성 검증 #

• 확인된 재해 복구(DR) IP를 사용하여 애플리케이션에 액세스하십시오.
• 확인 :
  • 애플리케이션은 모든 기능이 정상적으로 작동합니다.
  • 의존성 문제(데이터베이스, API 등) 없음

일반적인 문제 및 문제 해결 #

장애 조치가 트리거되지 않았습니다 #

• 상태 검사가 너무 관대함 (예: HTTP 대신 TCP 유효성 검사)
• 잘못된 상태 점검 엔드포인트
• 백엔드가 아직 부분적으로만 응답하고 있습니다.

해결 방법 : 애플리케이션 수준의 검사(HTTP 상태, 응답 본문)를 사용합니다.

DNS는 여전히 기본 DNS로 확인됩니다. #

• TTL이 너무 높음
• 클라이언트 측 DNS 캐싱
• 재귀 DNS 서버가 새로 고쳐지지 않았습니다.

고치다 :

• TTL을 낮추세요 (예: 30~60초)
• 로컬 DNS 캐시를 플러시합니다
• 외부 리졸버를 사용하여 테스트하십시오(dig @8.8.8.8).

재해 복구 사이트가 트래픽을 처리하지 않습니다. #

• DR 백엔드가 제대로 구성되지 않았습니다.
• 필수 종속 항목(데이터베이스, 스토리지, 인증)이 누락되었습니다.
• 방화벽 또는 라우팅 문제

해결 방법 : 로드 밸런서뿐만 아니라 전체 재해 복구(DR) 스택의 준비 상태를 검증합니다.

간헐적 페일오버(플래핑) #

• 불안정한 건강 검진
• 네트워크 지연 또는 패킷 손실
• 일관성 없는 백엔드 응답

고치다 :

• 상태 점검 간격 및 임계값을 조정하세요
• 고장 허용 오차를 높이세요

애플리케이션 기반 공용 IP 고려 사항 #

사이트별 공용 IP를 사용하는 경우:

• 각 사이트가 자체 공용 IP 주소를 공개하도록 하십시오.
• GSLB는 사이트별로 올바른 IP 주소를 반환해야 합니다.
• 확인:
  • NAT 및 방화벽 규칙
  • 엔드포인트별 SSL 인증서
  • 사이트 전반에 걸쳐 일관된 애플리케이션 동작

GSLB 내부 서비스 지침 #

내부 전용 서비스(프라이빗 DNS/내부 앱)의 경우:

DNS 구성 #

• 통합된 내부 DNS 서버를 사용합니다. RELIANOID GSLB
• 클라이언트가 올바른 내부 해결 방법을 통해 문제를 해결하도록 하십시오.

네트워크 고려 사항 #

• 사이트 간 라우팅(VPN/MPLS)을 확인하십시오.
• 모든 클라이언트 네트워크에서 재해 복구(DR) 사이트에 접속할 수 있는지 확인하십시오.

건강 검진 #

• 내부 엔드포인트(사설 IP)를 사용하십시오.
• 애플리케이션 계층 응답을 검증합니다.

분열뇌 방지 #

• GSLB 노드 간의 적절한 동기화를 보장합니다.
• 두 사이트 모두 잘못된 상태로 활성으로 간주되는 상황을 피하십시오.

모범 사례 #

• 장애 조치 속도를 높이려면 낮은 TTL 값을 사용하십시오.
• 항상 애플리케이션 수준의 상태 점검을 사용하십시오.
• 정기적으로 장애 조치 훈련을 실시하십시오.
• DNS 확인을 전 세계적으로 모니터링합니다.
• 기본 시스템과 재해 복구 시스템 간의 구성 일관성을 확보하십시오.

검증 체크리스트 #

[ ] 모든 사이트에 GSLB 서비스가 구성되었습니다.
[ ] 건강 검진 결과가 검증되었으며 신뢰할 수 있습니다.
[ ] TTL이 적절하게 구성되었습니다
[ ] 재해 복구 환경이 완전히 가동 중입니다.
[ ] DNS 페일오버 테스트 및 확인 완료
[ ] 장애 조치 후 애플리케이션 테스트 완료
[ ] 내부 서비스 유효성 검사 완료(해당되는 경우)

제품 개요 #

적절한 검증 RELIANOID GSLB는 온프레미스 환경에서 재해 복구(DR) 환경으로의 원활한 자동 페일오버를 보장하여 다운타임을 최소화하고 서비스 연속성을 유지합니다.

성공적인 배포를 위해서는 다음 간의 협력이 필요합니다.

• DNS 구성
• 상태 확인
• 애플리케이션 준비 상태
• 네트워크 디자인