다음을 통해 공유

고가용성(Windows Server AppFabric 캐싱)

  • 아티클

고가용성을 사용하도록 설정한 경우 캐시된 각 개체 또는 영역의 복사본이 별도의 캐시 호스트에서 유지 관리됩니다. 캐시 클러스터는 이러한 복사본을 유지 관리하고 주 복사본을 사용할 수 없는 경우 응용 프로그램에 복사본을 제공합니다. 캐시 사용 응용 프로그램의 가용성을 높이기 위해 코드를 변경할 필요가 없습니다. 다음 그림에서는 고가용성 기능을 사용하도록 설정한 경우 개체 및 영역 복사본이 개별 호스트에 저장되는 방식을 보여 줍니다.

"속도" 고가용성 개요

고가용성 구성

고가용성은 클러스터 구성 설정의 캐시 수준에서 구성됩니다. New-Cache 명령을 사용하고 Secondaries 매개 변수를 1로 설정하면 캐시를 처음 만들 때 캐시의 속성으로 고가용성을 사용하도록 설정할 수 있습니다. 이 명령은 캐시 관리 Windows PowerShell cmdlet에 캐시된 각 개체 또는 영역에 대한 하나의 복사본이 필요함을 알립니다. Secondaries 매개 변수를 0으로 설정하면 고가용성 기능이 사용하지 않도록 설정됩니다. 기본적으로 고가용성 옵션은 새 캐시를 만들 때 사용하지 않도록 설정됩니다. 캐시 구성 설정 편집에 대한 자세한 내용은 Windows PowerShell을 사용한 캐시 구성 설정 편집(Windows Server AppFabric 캐싱)을 참조하십시오.

Windows Server AppFabric 캐싱 기능의 고가용성 기능을 사용하려면 캐시 클러스터의 모든 노드에서 Windows Server 2008 Enterprise Edition 이상 또는 Windows Server 2008 R2가 실행되고 있어야 합니다. 모든 고가용성 캐시 노드가 지원되는 운영 체제에서 실행되고 있는지 확인하십시오. 지원되는 운영 체제에 대한 자세한 내용은 AppFabric 설치 가이드(영문)(https://go.microsoft.com/fwlink/?LinkId=169172)의 "소프트웨어 요구 사항" 섹션을 참조하십시오.

보조 복사본 저장소

캐시 클러스터는 개체와 영역의 보조 복사본을 저장할 위치를 선택합니다. AppFabric이 캐시된 개체를 클러스터의 모든 캐시 호스트에 걸쳐 분산시키는 것과 같이 캐시 클러스터도 해당 개체의 보조 복사본을 클러스터의 모든 캐시 호스트에 걸쳐 분산시킵니다.

일관성 유지 관리 방식

고가용성을 사용하도록 설정했는지 여부에 관계없이 캐시 사용 응용 프로그램은 캐시된 개체의 주 복사본만 존재하는 것처럼 작동합니다. 모든 Add, Put 및 Remove 메서드 호출은 호출이 상주하는 캐시 호스트에 관계없이 먼저 주 개체에 대해 시작됩니다. 주 개체 또는 영역을 유지 관리하는 캐시 호스트에 대한 호출이 시작된 후 수행되는 작업은 고가용성을 사용할 수 있는지 여부에 따라 달라집니다.

고가용성을 사용하도록 설정하면 보조 복사본을 유지 관리하는 호스트에 변경이 수행될 것임을 알리는 단계가 추가됩니다. 그런 다음 개체의 주 복사본이 포함된 캐시 호스트는 작업이 완료되었음을 클라이언트에 다시 승인하기 전에 다른 호스트의 승인을 기다립니다.

예제를 보려면 다음 다이어그램에서 캐시 호스트 A 및 B를 참조하십시오. 캐시 호스트 A는 요청을 수신한 즉시 요청 처리를 시작하고 캐시 호스트 B에 변경에 대해 알립니다. 그러면 캐시 호스트 B는 승인을 다시 캐시 호스트 A에 보냅니다. 승인을 수신하면 캐시 호스트 A는 변경을 완료하고 승인을 다시 캐시 사용 응용 프로그램에 보냅니다. 이 프로세스에서는 개체 또는 영역의 보조 복사본이 항상 주 복사본과 동일한 상태에 있는지 확인합니다. 이 프로세스를 강력한 일관성이라고 합니다.

"속도" 고가용성 일관성

성능 고려 사항

개체나 영역의 보조 복사본을 유지 관리하는 캐시 호스트는 주 복사본에 관한 모든 변경을 승인해야 하므로 캐시 사용 응용 프로그램의 쓰기 응답 시간에는 약간의 성능 저하가 발생합니다. 이 성능 영향은 이미 캐시에 있는 항목의 읽기에는 영향을 미치지 않습니다. 해당 개체의 주 복사본을 유지 관리하는 캐시 호스트가 손실될 경우 개체가 포함된 캐시를 다시 로드하는 데 필요한 시간도 고려해야 합니다.

캐시 호스트가 실패할 경우

클러스터를 계속 실행할 수 있는 충분한 수의 캐시 호스트가 있다고 가정하면 캐시 호스트가 실패할 경우 캐시 사용 응용 프로그램이 전혀 변경되지 않습니다. 캐시 클러스터는 개체에 대한 요청을 개체의 보조 복사본을 유지 관리한 캐시 호스트로 다시 라우팅합니다. 클러스터 내에서 모든 주 개체의 보조 복사본은 권한이 상승되어 새로운 주 개체가 됩니다. 그런 다음 이 새로운 주 개체의 보조 복사본이 클러스터 전체의 다른 캐시 호스트에 분산됩니다. 실패한 캐시 호스트의 보조 개체는 새 보조 개체로 대체되고 클러스터에 분산됩니다. 이 프로세스는 영역에도 적용됩니다.

고가용성 기능을 통해 캐시 호스트 오류로부터 응용 프로그램을 보호하려면 최소한 세 개의 캐시 호스트가 캐시 클러스터의 구성원이어야 합니다. 이는 고가용성 사용 캐시에서는 항상 캐시된 개체 또는 영역의 두 복사본이 있어야 한다는 강력한 일관성 요구 사항 때문입니다. 캐시 또는 영역의 두 복사본을 유지 관리하려면 고가용성 사용 캐시에서 최소한 두 개의 캐시 호스트가 작동해야 합니다.

예를 들어, 다음 표에 표시된 대로 3개 서버로 구성된 캐시 클러스터에서 HACache라는 고가용성 지원 캐시가 만들어졌습니다. 이 예제에서 리드 호스트 손실 가능성을 고려할 필요가 없도록 SQL Server가 클러스터 관리 역할을 수행하도록 구성되었다고 가정합니다.

시간 캐시 호스트 1 캐시 호스트 2 캐시 호스트 3 HACache(고가용성 지원 명명된 캐시)

T1

실행 중

실행 중

실행 중

사용 가능

T2

실행 중

실행 중

중지됨

사용 가능

T3

실행 중

중지됨

중지됨

사용할 수 없음

T1에서 3개 캐시 호스트를 사용할 수 있는 경우 캐시된 개체 또는 영역의 2개 복사본을 사용 가능한 3개 서버 중 하나에 저장할 수 있습니다. T2에서 하나의 캐시 서버가 실패할 경우 캐시된 개체 또는 영역의 2개 복사본을 저장할 수 있는 2개 캐시 호스트가 있으므로 HACache를 계속 사용할 수 있습니다. T3에서 두 번째 캐시 호스트가 실패하면 HACache를 사용할 수 없게 됩니다. 이는 더 이상 캐시된 개체 또는 영역의 두 번째 복사본을 저장할 수 있는 다른 캐시 호스트가 없기 때문입니다.

기타 고가용성 권장 사항

캐시된 데이터의 가용성을 최적화하려면 다음 권장 사항을 고려합니다.

  • 많은 캐시 호스트를 사용합니다.

  • 캐시 클라이언트, 캐시 호스트, 주 데이터 원본 서버 및 클러스터 구성 저장소 위치를 호스트하는 서버를 포함하여 동일한 도메인의 모든 서버 구성원이 포함된 분산 캐시 시스템을 방화벽 경계 내에 배포합니다.

  • SQL Server 또는 사용자 지정 공급자를 사용하여 캐시 클러스터 구성 설정을 저장합니다.

  • 클러스터를 중지해야 하는 비용이 높은 구성 변경을 최소화합니다. 가능하면 클러스터 구성 설정에서 캐시 구성 변경을 수행하기 위해 전체 캐시 클러스터를 중지하지 않고 명명된 캐시를 다시 만듭니다.

  • 항상 Stop-CacheHost 명령을 사용하여 서버가 다시 부팅되기 전에 캐시 서비스를 중지합니다. 리드 호스트가 클러스터 관리 역할을 수행할 때 캐시 서비스 중지 작업으로 인해 전체 캐시 클러스터가 종료되면(실행 중인 리드 호스트가 과반수 미만이 되므로) Stop-CacheHost cmdlet이 실패합니다.

참고 항목

개념

Windows Server AppFabric 캐싱 실제 아키텍처 다이어그램
Windows Server AppFabric 캐싱 논리 아키텍처 다이어그램

  2011-12-05