This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
재해 복구
활성-수동 페일오버 전략을 사용하여 여러 사이트를 포함하는 XenMobile® 배포를 재해 복구용으로 설계하고 구성할 수 있습니다.
이 문서에서 설명하는 권장 재해 복구 전략은 다음으로 구성됩니다.
- 전 세계 모든 엔터프라이즈 사용자에게 서비스를 제공하는 단일 XenMobile 활성 사이트(기본 사이트라고 함)가 한 지리적 위치의 데이터 센터에 있습니다.
- 두 번째 지리적 위치의 데이터 센터에 있는 두 번째 XenMobile 사이트(재해 복구 사이트라고 함). 이 재해 복구 사이트는 기본 사이트에서 사이트 전체 데이터 센터 장애가 발생할 경우 활성-수동 사이트 페일오버를 제공합니다. 기본 사이트에는 페일오버를 용이하게 하고 기본 사이트에 대한 연결 장애 발생 시 사용자에게 XenMobile에 대한 액세스를 제공하기 위한 XenMobile, SQL 데이터베이스 및 Citrix ADC 인프라가 포함됩니다.
재해 복구 사이트의 XenMobile 서버는 정상 작동 중에는 오프라인 상태를 유지하며, 기본 사이트에서 재해 복구 사이트로의 완전한 사이트 페일오버가 필요한 재해 복구 시나리오에서만 온라인 상태가 됩니다. 재해 복구 사이트의 XenMobile 서버를 시작하기 전에 재해 복구 사이트의 SQL 서버는 활성 상태여야 하며 연결을 처리할 준비가 되어 있어야 합니다.
이 재해 복구 전략은 중단 발생 시 MDM 및 MAM 연결을 재해 복구 사이트로 라우팅하기 위해 DNS 변경을 통한 Citrix ADC 액세스 계층의 수동 페일오버에 의존합니다.
참고:
이 아키텍처를 사용하려면 데이터베이스의 비동기 백업을 위한 프로세스와 SQL 인프라의 고가용성을 보장하는 방법이 마련되어 있어야 합니다.
재해 복구 페일오버 프로세스
- 재해 복구 페일오버 프로세스를 테스트하는 경우, 사이트 장애를 시뮬레이션하기 위해 기본 사이트의 XenMobile 서버를 종료합니다.
- XenMobile 서버의 공용 DNS 레코드를 재해 복구 사이트의 외부 IP 주소를 가리키도록 변경합니다.
- SQL 서버의 내부 DNS 레코드를 재해 복구 사이트의 SQL 서버 IP 주소를 가리키도록 변경합니다.
- 재해 복구 사이트에서 XenMobile SQL 데이터베이스를 온라인 상태로 전환합니다. SQL 서버와 데이터베이스가 활성 상태이며 해당 사이트의 XenMobile 서버로부터의 연결을 처리할 준비가 되었는지 확인합니다.
- 재해 복구 사이트의 XenMobile 서버를 웁니다.
XenMobile 서버 업데이트 프로세스
패치 및 릴리스로 XenMobile을 업데이트할 때마다 다음 단계를 따라 기본 및 재해 복구 서버의 코드를 동일하게 유지하십시오.
- 기본 사이트의 XenMobile 서버가 패치되거나 업그레이드되었는지 확인합니다.
- SQL 서버의 DNS 레코드가 기본 사이트의 활성 SQL 서버 데이터베이스로 확인되는지 확인합니다.
- 재해 복구 사이트의 XenMobile 서버를 온라인 상태로 전환합니다. 서버는 업그레이드 프로세스 중에만 WAN을 통해 기본 사이트의 데이터베이스에 연결합니다.
- 재해 복구 사이트의 모든 XenMobile 서버에 필요한 패치 및 업데이트를 적용합니다.
- XenMobile 서버를 다시 시작하고 패치 또는 업그레이드가 성공했는지 확인합니다.
재해 복구 참조 아키텍처 다이어그램
다음 다이어그램은 XenMobile의 재해 복구 배포를 위한 상위 수준 아키텍처를 보여줍니다.
재해 복구를 위한 GSLB
이 아키텍처의 핵심 요소는 트래픽을 올바른 데이터 센터로 전달하기 위해 GSLB(Global Server Load Balancing)를 사용하는 것입니다.
기본적으로 XenMobile용 Citrix ADC 마법사는 재해 복구를 위한 GSLB 사용을 활성화하지 않는 방식으로 Citrix Gateway를 구성합니다. 따라서 추가 단계를 수행해야 합니다.
GSLB 작동 방식
GSLB는 본질적으로 DNS의 한 형태입니다. 참여하는 Citrix ADC 어플라이언스는 권한 있는 DNS 서버 역할을 하며 DNS 레코드를 올바른 IP 주소(일반적으로 트래픽을 수신해야 하는 VIP)로 확인합니다. Citrix ADC 어플라이언스는 해당 시스템으로 트래픽을 전달하는 DNS 쿼리에 응답하기 전에 시스템 상태를 확인합니다.
레코드가 확인되면 트래픽 확인에서 GSLB의 역할은 완료됩니다. 클라이언트는 대상 가상 IP(VIP) 주소와 직접 통신합니다. DNS 클라이언트 동작은 레코드가 만료되는 시기와 방법을 제어하는 데 중요한 역할을 합니다. 이는 Citrix ADC 시스템의 경계를 크게 벗어납니다. 따라서 GSLB는 DNS 이름 확인과 동일한 제한 사항을 따릅니다. 클라이언트는 응답을 캐시하므로 이러한 방식의 로드 밸런싱은 기존 로드 밸런싱만큼 실시간이 아닙니다.
사이트, 서비스 및 모니터를 포함한 Citrix ADC의 GSLB 구성은 올바른 DNS 이름 확인을 제공하기 위해 존재합니다.
게시 서버에 대한 실제 구성(이 시나리오에서는 XenMobile용 Citrix ADC 마법사가 생성하는 구성)은 GSLB의 영향을 받지 않습니다. GSLB는 Citrix ADC의 별도 서비스입니다.
XenMobile에서 GSLB를 사용할 때 도메인 위임의 문제점
XenMobile용 Citrix ADC 마법사는 XenMobile용 Citrix Gateway를 구성합니다. 이 마법사는 세 개의 로드 밸런싱 가상 서버와 하나의 Citrix Gateway 가상 서버를 생성합니다.
두 개의 로드 밸런싱 가상 서버는 포트 443 및 8443에서 MDM 트래픽을 처리합니다. Citrix Gateway는 MAM 트래픽을 수신하여 세 번째 서버인 MAM 로드 밸런싱 가상 서버로 포트 8443에서 전달합니다. MAM 로드 밸런싱 가상 서버로의 모든 트래픽은 Citrix Gateway를 통해 전달됩니다.
MAM 로드 밸런싱 가상 서버는 XenMobile 서버와 동일한 SSL 인증서를 필요로 하며 장치 등록에 사용되는 것과 동일한 FQDN을 사용합니다. MAM 로드 밸런싱 서버는 또한 MDM 로드 밸런싱 서버 중 하나와 동일한 포트(8443)를 사용합니다. 트래픽이 확인될 수 있도록 XenMobile용 Citrix ADC 마법사는 Citrix Gateway에 로컬 DNS 레코드를 생성합니다. 이 DNS 레코드는 장치 등록에 사용되는 FQDN과 일치합니다.
이 구성은 XenMobile 서버 URL이 GSLB 도메인 URL이 아닐 때 효과적입니다. 재해 복구에 필요한 대로 GSLB 도메인 URL이 XenMobile 서버 URL로 사용되는 경우, 로컬 DNS 레코드는 Citrix Gateway가 MDM 로드 밸런싱 서버로 트래픽을 확인하는 것을 방해합니다.
GSLB 재해 복구를 위한 CNAME 메서드 사용
XenMobile용 Citrix ADC 마법사가 생성하는 기본 구성으로 인해 발생하는 문제를 해결하려면, 상위 도메인(company.com)에 XenMobile 서버 FQDN에 대한 CNAME 레코드를 생성하고 Citrix ADC가 권한을 갖는 위임된 서브존(gslb.company.com)의 레코드를 가리키도록 할 수 있습니다. 이렇게 하면 트래픽 확인에 필요한 MAM 로드 밸런싱 VIP 주소에 대한 정적 DNS A 레코드를 생성할 수 있습니다.
-
외부 DNS에서 XenMobile 서버 FQDN에 대한 CNAME을 생성하여 Citrix ADC GSLB의 GSLB 도메인 FQDN을 가리키도록 합니다. MDM 트래픽용 하나와 MAM(Citrix Gateway) 트래픽용 하나, 총 두 개의 GSLB 도메인이 필요합니다.
예시:
CNAME = xms.company.com IN CNAME xms.gslb.comany.com -
각 사이트의 Citrix Gateway 인스턴스에서 CNAME 레코드가 가리키는 FQDN을 가진 GSLB 가상 서버를 생성합니다.
예시:
bind gslb vserver xms-gslb -domainName xms.gslb.company.comXenMobile용 Citrix ADC 마법사를 사용하여 Citrix Gateway를 배포할 때 MAM 로드 밸런싱 서버를 구성할 때 XenMobile 서버 URL을 사용합니다. 이렇게 하면 XenMobile 서버 URL에 대한 정적 DNS A 레코드가 생성됩니다.
-
XenMobile 서버 URL(
xms.company.com)을 사용하여 Secure Hub에 등록하는 클라이언트로 테스트합니다.이 예시에서는 다음 FQDN을 사용합니다.
-
xms.company.com은 MDM 트래픽에 사용되고 장치 등록에 사용되는 URL이며, 이 예시에서는 XenMobile용 Citrix ADC 마법사를 사용하여 구성됩니다. -
xms.gslb.company.com은 XenMobile 서버의 GSLB 도메인 FQDN입니다.
-
공유
공유
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.