Test Results

 

마지막으로 수정된 항목: 2011-03-02

이 항목에서는 이 섹션에 제안된 장애 조치(failover) 솔루션에 대한 Microsoft의 테스트 결과를 설명합니다.

중앙 사이트 링크 대기 시간

여기에서는 North와 South 사이에 시뮬레이션된 WAN 링크에 대기 시간을 도입하기 위해 네트워크 대기 시간 시뮬레이터가 사용되었습니다. 권장되는 토폴로지에는 지리적 사이트 간에 최대 20밀리초의 대기 시간이 지원됩니다. Lync Server 2010의 향상된 아키텍처로 인해 대기 시간을 Microsoft Office Communications Server 2007 R2 대도시 사이트 복구 토폴로지에 허용된 최대값 15밀리초보다 더 높게 설정할 수 있습니다.

• 15밀리초.   두 사이트 간의 네트워크 경로와 두 사이트 간의 데이터 복제를 위해 사용되는 데이터 경로 모두에 대한 왕복 대기 시간은 15밀리초부터 시작되었습니다. 이러한 조건 및 부하에서는 토폴로지가 문제없이 계속 작동했습니다.

• 20밀리초.   그런 다음 대기 시간을 늘리기 시작했습니다. 네트워크 및 데이터 트래픽 모두에 대해 왕복 대기 시간이 20밀리초가 되어도 토폴로지는 문제없이 계속 작동했습니다. 20밀리초는 Lync Server 2010에서 이 토폴로지에 대해 지원되는 최대 왕복 대기 시간입니다.

  중요:
  Microsoft는 네트워크 및 데이터 대기 시간이 20밀리초를 초과하는 솔루션을 지원하지 않습니다.

• 30밀리초.   왕복 대기 시간이 30밀리초가 되자 성능 저하가 나타났습니다. 특히 보관 및 모니터링 데이터베이스에 대한 메시지 큐가 증가하기 시작했습니다. 이러한 늘어난 대기 시간으로 인해 사용자 환경도 성능이 저하되었습니다. 로그인 시간 및 회의 생성 시간이 모두 증가했으며 A/V 환경의 성능도 크게 감소되었습니다. 이러한 이유로 인해 Microsoft는 왕복 대기 시간이 20밀리초를 초과하는 솔루션은 지원하지 않습니다.

장애 조치(Failover)

앞에서 설명한 것처럼 이 토폴로지의 모든 Windows Server 2008 R2 클러스터에는 노드 및 파일 공유 과반수 쿼럼이 사용되었습니다. 따라서 사이트 장애 조치(failover)를 시뮬레이션하기 위해서는 South 사이트와 미러링 모니터 사이트 모두에 대한 연결을 해제하여 모든 서버와 클러스터를 격리시켜야 했습니다. 여기에서는 North 사이트에 대한 모든 서버의 "부적절한" 종료가 사용되었습니다.

North 사이트의 오류 이후의 결과 및 관찰 사항은 다음과 같습니다.

• 수동 SQL Server 클러스터 노드가 몇 분 내에 활성화되었습니다. 정확한 시간은 환경 세부 사항에 따라 다를 수 있습니다. North 사이트에 연결된 내부 사용자는 로그아웃된 후 자동으로 다시 로그인되었습니다. 장애 조치(failover) 중에 사용자 상태는 업데이트되지 않았으며 새 IM 세션이나 회의와 같은 새 작업은 해당 오류와 함께 실패했습니다. 장애 조치(failover)가 완료된 후에는 더 이상 오류가 발생하지 않았습니다.

• 피어 간에 유효한 네트워크 경로가 있는 한 지속되는 피어 투 피어 통화는 중단 없이 계속되었습니다.

• UC-PSTN 통화는 해당 통화를 지원하는 게이트웨이가 사용할 수 없게 될 경우 연결이 해제되었습니다. 이 경우 사용자는 통화를 수동으로 다시 설정할 수 있었습니다.

• North 사이트에 연결된 Lync 2010 사용자는 연결이 해제되고 몇 분 이내에 South 사이트에 자동으로 다시 연결되었습니다. 사용자는 그런 다음 이전과 마찬가지로 작업을 계속 수행할 수 있었습니다.

• 다시 연결하기 위해서는 그룹 채팅 클라이언트 사용자가 로그아웃한 후 다시 로그인해야 했습니다. South 사이트에서 정상적으로 중지되었거나 사이트에서 사용하지 않도록 설정된 그룹 채팅 채널 서비스 및 조회 서비스는 수동으로 다시 시작해야 했습니다.

• North 사이트에 호스팅된 회의는 자동으로 South 사이트로 장애 조치(failover)되었습니다. 장애 조치(failover)가 완료된 후에는 모든 사용자에게 회의에 다시 연결하라는 메시지가 표시되었습니다. 클라이언트는 모임에 다시 참여할 수 있었습니다. 모임 기록은 장애 조치(failover) 중에도 계속되었습니다. 핫 대기 보관 서버가 온라인 상태가 될 때까지 보관은 중지되었습니다.

• 관리 기능은 North 사이트가 중지된 상태에서도 계속 작동했습니다. 예를 들어 사용자를 Survivable Branch Appliance에서 프런트 엔드 풀로 이동할 수 있었습니다.

• North 사이트가 오프라인이 된 후 South 사이트의 SQL Server 클러스터 및 파일 공유 클러스터는 몇 분 내에 온라인 상태가 되었습니다.

• 테스트 중에 관측된 사이트 장애 조치(failover) 기간은 몇 분 이내였습니다.

장애 복구(Failback)

테스트 목적에 따라 여기에서는 사용자가 해당 사이트에서 서버에 다시 연결할 수 있도록 모든 기능을 North 사이트로 복원하는 장애 복구(failback)를 정의했습니다. North 사이트가 복원된 다음에는 모든 클러스터 리소스가 North 사이트의 해당 노드로 이동되었습니다.

장애 복구(failback) 절차 중에는 일부 사용자의 작업 중단이 발생할 수 있으므로 장애 복구(failback)는 제한된 방식으로 특히 근무 외 시간 중에 수행하는 것이 좋습니다. North 사이트의 장애 복구(failback) 이후의 결과 및 관찰 사항은 다음과 같습니다.

• 클러스터 리소스를 North 사이트의 해당 노드로 다시 이동하기 전에 저장소를 완전히 다시 동기화해야 했습니다. 저장소가 다시 동기화되지 않은 경우 클러스터가 온라인 상태로 돌아오지 않습니다. 저장소에 대한 다시 동기화는 자동으로 수행되었습니다.

• 사용자에 대한 영향을 최소화하기 위해 클러스터는 자동으로 장애 복구(failback)되지 않도록 설정되었습니다. 장애 복구(failback)는 저장소가 완전히 다시 동기화되었는지 확인한 후 다음 유지 관리 작업 시간까지 연기하는 것이 좋습니다.

• 프런트 엔드 서버는 Active Directory 도메인 서비스에 연결할 수 있을 때 온라인 상태가 됩니다. 프런트 엔드 서버가 온라인이 되었을 때 백 엔드 데이터베이스를 아직 사용할 수 없으면 사용자의 기능이 제한됩니다.

  North 사이트의 프런트 엔드 서버가 온라인 상태가 된 후에는 새로운 연결이 이 서버로 라우팅됩니다. 온라인 상태이고 일반적으로 North 사이트의 프런트 엔드 서버를 통해 연결하는 사용자는 사용자의 일상적인 North 사이트 서버에서 로그아웃된 후 다시 로그인됩니다.

  North 사이트에서 프런트 엔드 서버가 자동으로 온라인 상태로 돌아오지 않도록 방지하려면, 즉 전체 프로세스를 보다 세밀하게 제어하거나 두 사이트 간의 대기 시간이 허용 가능한 수준으로 복원되지 않은 경우에는 프런트 엔드 서버를 종료하는 것이 좋습니다.

• 테스트 중에 관측된 사이트 장애 복구(failover) 기간은 1분 미만이었습니다.