재해 복구

재해 복구를 위해 활성/수동 장애 조치(failover) 전략을 사용하여 여러 사이트가 포함된 XenMobile 배포를 설계하고 구성할 수 있습니다.

이 문서에서 설명하는 권장 재해 복구 전략은 다음으로 구성됩니다.

  • 모든 엔터프라이즈 사용자에게 글로벌 서비스를 제공하는 첫 번째 지리적 위치의 데이터 센터에 있는 단일의 XenMobile 활성 사이트(기본 사이트).
  • 두 번째 지리적 위치의 데이터 센터에 있는 두 번째 XenMobile 사이트(재해 복구 사이트). 이 재해 복구 사이트는 기본 사이트에서 사이트 전체 데이터 센터 장애가 발생하는 경우 활성-비활성 사이트 장애 조치(failover)를 제공합니다. 기본 사이트에는 장애 조치(failover)를 용이하게 하는 XenMobile, SQL 데이터베이스, NetScaler 인프라가 포함되며 기본 사이트에 대한 연결 실패 이벤트를 통해 사용자에게 XenMobile에 대한 액세스를 제공합니다.

재해 복구 사이트의 XenMobile 서버는 정상 작동 중에 오프라인으로 유지되며 기본 사이트의 전체 사이트를 재해 복구 사이트로 장애 조치(failover)해야 하는 재해 복구 시나리오에서만 온라인으로 전환됩니다. 재해 복구 사이트의 SQL Server는 재해 복구 사이트에서 XenMobile 서버를 시작하기 전에 활성 상태이고 연결을 제공할 준비가 되어 있어야 합니다.

이 재해 복구 전략은 중단 시 MDM 및 MAM 연결을 재해 복구 사이트로 라우팅하도록 DNS를 변경함으로써 NetScaler 액세스 계층을 수동으로 장애 조치(failover)합니다.

참고:

이 아키텍처를 사용하려면 비동기식 데이터베이스 백업에 대한 프로세스와 SQL 인프라의 고가용성을 보장할 방법이 있어야 합니다.

재해 복구 장애 조치(failover) 프로세스

  1. 재해 복구 장애 조치(failover) 프로세스를 테스트하려면 기본 사이트에서 XenMobile 서버를 종료하여 사이트 장애를 시뮬레이션합니다.
  2. XenMobile 서버의 공용 DNS 레코드를 재해 복구 사이트의 외부 IP 주소를 가리키도록 변경합니다.
  3. SQL Server의 내부 DNS 레코드를 재해 복구 사이트의 SQL Server IP 주소를 가리키도록 변경합니다.
  4. 재해 복구 사이트에서 XenMobile SQL 데이터베이스를 온라인으로 전환합니다. SQL Server 및 데이터베이스가 활성 상태이고 로컬 XenMobile 서버에서 사이트로의 연결을 제공할 준비가 되었는지 확인합니다.
  5. 재해 복구 사이트에서 XenMobile 서버를 켭니다.

XenMobile 서버 업데이트 프로세스

패치 및 릴리스로 XenMobile을 업데이트할 때는 다음 단계에 따라 기본 서버와 재해 복구 서버의 코드를 동일하게 유지하십시오.

  1. 기본 사이트의 XenMobile 서버에 패치가 적용되었거나 업그레이드되었는지 확인합니다.
  2. SQL Server의 DNS 레코드가 기본 사이트의 활성 SQL Server 데이터베이스로 확인되는지 확인합니다.
  3. 재해 복구 사이트의 XenMobile 서버를 온라인으로 전환합니다. 이 서버는 업그레이드 프로세스 중에만 WAN의 기본 사이트 데이터베이스에 연결합니다.
  4. 필요한 패치 및 업데이트를 모든 재해 복구 사이트의 XenMobile 서버에 적용합니다.
  5. XenMobile Server를 다시 시작하고 패치 또는 업그레이드가 성공했는지 확인합니다.

재해 복구 참조 아키텍처 다이어그램

다음 다이어그램은 XenMobile의 재해 복구 배포에 대한 아키텍처 개요를 보여줍니다.

재해 복구 참조 아키텍처의 다이어그램

재해 복구용 GSLB

이 아키텍처의 주요 요소는 GSLB(Global Server Load Balancing)를 사용하여 트래픽을 올바른 데이터 센터로 전달하는 것입니다.

기본적으로 XenMobile용 NetScaler 마법사에서는 재해 복구에 GSLB를 사용하지 않는 방식으로 NetScaler Gateway가 구성됩니다. 따라서 추가 단계를 수행해야 합니다.

GSLB의 작동 방식

GSLB는 DNS 형태로 존재합니다. 참여 NetScaler 장비는 신뢰할 수 있는 DNS 서버 역할을 하며 DNS 레코드를 올바른 IP 주소(일반적으로 트래픽을 수신할 수 있는 VIP)로 확인합니다. NetScaler 장비는 트래픽을 해당 시스템으로 전달하는 DNS 쿼리에 응답하기 전에 시스템 상태를 확인합니다.

레코드가 확인되면 트래픽을 확인하는 GSLB의 역할이 완료됩니다. 클라이언트는 대상 VIP(가상 IP) 주소와 직접 통신합니다. DNS 클라이언트 동작은 레코드의 만료 방식과 시기를 제어하는 데 있어서 중요한 역할을 합니다. 이는 주로 NetScaler 시스템의 경계 외부에서 수행됩니다. 따라서 GSLB에는 DNS 이름 확인과 동일한 제한이 적용됩니다. 클라이언트가 응답을 캐시하므로 이 방식의 부하 분산은 기존의 부하 분산과 달리 실시간으로 수행되지 않습니다.

NetScaler의 GSLB 구성(사이트, 서비스 및 모니터 포함)은 올바른 DNS 이름 확인을 제공하는 데 사용됩니다.

서버 게시를 위한 실제 구성(이 시나리오에서는 XenMobile용 NetScaler 마법사에서 생성되는 구성)은 GSLB의 영향을 받지 않습니다. GSLB는 NetScaler에 있는 개별 서비스입니다.

XenMobile에서 GSLB를 사용하는 경우의 도메인 위임 문제

XenMobile용 NetScaler Gateway는 XenMobile용 NetScaler 마법사에서 구성됩니다. 이 마법사는 부하 분산 가상 서버 세 개와 NetScaler Gateway 가상 서버 한 개를 생성합니다.

부하 분산 가상 서버 두 개는 포트 443 및 8443에서 MDM 트래픽을 처리합니다. NetScaler Gateway는 포트 8443에서 MAM 트래픽을 수신한 후 세 번째 서버인 MAM 부하 분산 가상 서버에 전달합니다. MAM 부하 분산 가상 서버로 이동하는 모든 트래픽인 NetScaler Gateway를 통과합니다.

MAM 부하 분산 가상 서버에는 XenMobile 서버와 동일한 SSL 인증서가 필요하며 장치 등록 시 사용된 FQDN과 동일한 FQDN이 사용됩니다. 또한 또MAM 부하 분산 서버는 MDM 부하 분산 서버 중 하나와 동일한 포트(8443)를 사용합니다. 트래픽을 확인하기 위해 XenMobile용 NetScaler 마법사는 NetScaler Gateway에 로컬 DNS 레코드를 생성합니다. DNS 레코드는 장치 등록 시 사용된 FQDN과 일치합니다.

이 구성은 XenMobile 서버 URL이 GSLB 도메인 URL이 아닌 경우 적용됩니다. GSLB 도메인 URL이 재해 복구를 이유로 XenMobile 서버 URL로 사용된 경우 로컬 DNS 레코드로 인해 NetScaler Gateway가 MDM 부하 분산 서버로의 트래픽을 확인할 수 없게 됩니다.

GSLB 재해 복구의 CNAME 방법

XenMobile용 NetScaler 마법사의 기본 구성으로 인해 발생하는 문제를 해결하려면 상위 도메인(company.com)에 XenMobile 서버 FQDN에 대한 CNAME 레코드를 생성하고 신뢰할 수 있는 NetScaler의 위임된 하위 영역(gslb.company.com)에 있는 레코드를 가리키면 됩니다. 이렇게 하면 트래픽을 확인하는 데 필요한 MAM 부하 분산 VIP 주소에 대한 정적 DNS A 레코드를 생성할 수 있습니다.

  1. 외부 DNS에서 NetScaler GSLB의 GSLB 도메인 FQDN을 가리키는 XenMobile 서버 FQDN에 대한 CNAME를 생성합니다. 두 개의 GSLB 도메인이 필요합니다. 하나는 MDM 트래픽을 위한 것이고 다른 하나는 MAM(NetScaler Gateway) 트래픽을 위한 것입니다.

    예:

    CNAME = xms.company.com IN CNAME xms.gslb.comany.com

  2. 각 사이트의 NetScaler Gateway 인스턴스에서 CNAME 레코드가 가리키는 FQDN으로 GSLB 가상 서버를 생성합니다.

    예:

    bind gslb vserver xms-gslb -domainName xms.gslb.company.com

    XenMobile용 NetScaler 마법사를 사용하여 NetScaler Gateway를 배포하는 경우 MAM 부하 분산 서버를 구성할 때 XenMobile 서버 URL을 사용하십시오. 그러면 XenMobile 서버 URL에 대한 정적 DNS A 레코드가 생성됩니다.

  3. XenMobile 서버 URL(xms.company.com)을 사용하여 Secure Hub에 등록하는 클라이언트를 테스트합니다.

    이 예에서는 다음 FQDN을 사용합니다.

    • xms.company.com - MDM 트래픽과 장치 등록에 사용되는 URL이며 이 예에서는 XenMobile용 NetScaler 마법사를 사용하여 구성되었습니다.
    • xms.gslb.company.com - XenMobile 서버의 GSLB 도메인 FQDN입니다.