리드 호스트 및 클러스터 관리(AppFabric 1.1 캐싱)

Windows Server용 Microsoft AppFabric 1.1 캐시 클러스터는 응용 프로그램 데이터에 대해 하나의 통합 논리적 캐시를 제공하도록 함께 작동하는 서버의 동적 그룹입니다. 이렇게 하려면 캐시 호스트 간의 클러스터 작업을 조정하는 데 어느 정도의 오버헤드가 발생합니다. 클러스터 관리 역할은 캐시 호스트 및 궁극적으로 캐시 클러스터를 관리해야 합니다.

캐시 클러스터 관리 역할이 수행되는 방식에 관한 두 가지 기본 옵션이 있습니다. 리드 호스트라는 특수 캐시 호스트에 의해 수행되는 방식이 그 첫 번째이며, 이를 보통 "온로딩"이라고 합니다. SQL Server에 의해 수행되는 방식이 그 두 번째입니다. 캐시 클러스터 자체 대신 SQL Server로 책임이 오프로드되기 때문에 보통 "오프로딩"이라고 합니다.

캐시 클러스터 구성 데이터를 공유 네트워크 폴더(XML)에 저장하는 경우 리드 호스트 관리를 통해 온로딩을 사용해야 합니다. 리드 호스트는 리드 호스트로 지정되지 않은 다른 캐시 호스트와 동일한 캐싱 작업을 수행하지만 다른 리드 호스트와 함께 클러스터 관리 역할을 수행할 추가적인 책임이 있습니다.

Windows Server AppFabric 1.0에서 SQL Server에 구성 데이터를 저장한 캐시 클러스터는 기본적으로 캐시 클러스터 관리 역할을 SQL Server로 오프로드하도록 설정되었지만 AppFabric 1.1에서는 변경되었습니다. 새 캐시 클러스터는 기본적으로 캐시 클러스터를 관리할 리드 호스트가 있을 경우 항상 온로딩을 사용하도록 설정되어 있습니다. 이렇게 하면 구성 저장소가 XML 파일 또는 SQL Server 데이터베이스인지 관계없이, 구성 저장소를 사용할 수 없는 경우에도 캐시 클러스터가 부분적으로 작동할 수 있으므로 캐시 클러스터의 가용성이 개선됩니다. 이 상황에서는 캐시 클러스터의 구성을 검사하거나 변경하는 작업이 가능하지 않습니다.

참고

기존의 AppFabric 1.0 캐시 클러스터를 AppFabric 1.1로 업그레이드하는 경우, 업그레이드로 인해 캐시 클러스터 관리 동작이 변경되지 않습니다. 업그레이드된 캐시 클러스터에서 오프로딩을 사용하는데, 이를 변경하려는 경우 Windows PowerShell 명령을 사용하여 캐시 클러스터를 다시 만들어야 합니다. 자세한 내용과 예는 자동 설치(AppFabric 1.1 캐싱)를 참조하십시오. 클러스터를 더욱 쉽게 다시 만들려면 Export-CacheClusterConfig 및 Import-CacheClusterConfig 명령을 사용하면 됩니다. 하지만 leadHostManagement 속성이 "true"로 설정되어 있는지 확인해야 합니다. 자세한 내용은 리드 호스트 및 클러스터 관리(AppFabric 1.1 캐싱)를 참조하십시오.

계속해서 모든 캐시 클러스터 관리 책임을 SQL Server로 오프로드할 수 있습니다. 먼저 New-CacheCluster 명령을 통해 캐시 클러스터를 수동으로 만들고 Offloading 매개 변수를 "true"로 설정합니다. 그리고 Provider는 SQL Server(System.Data.SqlClient)여야 합니다.

다음 표에서는 설치 시 선택 사항과 클러스터 관리 옵션 간의 관계를 보여 줍니다. 이러한 구성 옵션 중 적합한 옵션을 선택하는 방법에 대한 자세한 내용은 클러스터 구성 저장소 옵션을 참조하십시오.

클러스터 구성 저장소 유형	클러스터 구성 저장소 위치	클러스터 관리
XML 파일	공유 네트워크 폴더	리드 호스트
SQL Server 데이터베이스	SQL Server	SQL Server 또는 리드 호스트(기본값)
사용자 지정 공급자	사용자 지정 저장소	리드 호스트

클러스터 관리 역할 작업

클러스터 관리와 관련된 클러스터 기능을 결정하는 두 가지 주요 구성 설정은 다음과 같습니다.

• leadHostManagement: 이 클러스터 수준 설정은 클러스터 관리 역할을 수행할 주체를 결정합니다. true인 경우 리드 호스트가 클러스터 관리 역할을 수행합니다. 공유 네트워크 폴더에 클러스터 구성 설정을 저장하도록 선택한 경우 이 설정에 유효한 값은 true뿐입니다. False이면 SQL Server 또는 사용자 지정 공급자가 클러스터 관리 역할을 수행합니다. SQL Server 또는 사용자 지정 공급자를 사용하여 클러스터 구성 설정을 저장하는 경우에도 이 설정을 true로 설정하여 리드 호스트가 클러스터 관리 역할을 수행하도록 할 수 있습니다.

• leadHost: 이 캐시 호스트 수준 설정은 리드 호스트가 클러스터 관리 역할을 수행할 때 리드 호스트가 될 캐시 호스트를 결정합니다. SQL Server가 클러스터 관리 역할을 수행하는 경우에도 나중에 leadHostManagement 설정을 변경하면 설치 프로그램에서 리드 호스트를 지정합니다.

이러한 설정을 변경하는 방법에 대한 자세한 내용은 클러스터 관리 역할 및 리드 호스트 지정 설정(AppFabric 1.1)을 참조하십시오.

리드 호스트가 클러스터 관리 역할을 수행하는 경우

leadHostManagement 및 leadHost 설정이 true인 경우 캐시 호스트가 클러스터에서 높은 책임 수준으로 권한이 상승되고 리드 호스트로 지정됩니다. 데이터 캐싱과 관련된 일반적인 캐시 호스트 작업 외에도 리드 호스트는 다른 리드 호스트와 함께 클러스터 작업을 관리합니다.

리드 호스트가 실패하는 경우

캐시 클러스터를 계속 사용할 수 있으려면 리드 호스트의 과반수가 사용 가능해야 합니다. 작은 클러스터의 경우 서버 실패 수가 적어도 클러스터가 종료되므로 큰 클러스터보다 위험이 더 큽니다.

참고

리드 호스트가 클러스터 관리 역할을 수행하는 경우 리드 호스트의 과반수가 실패하면 전체 캐시 클러스터가 종료됩니다.

예를 들어, 다음 다이어그램과 같이 6개 서버로 이루어진 캐시 클러스터를 고려해 보십시오. 이 예에서는 리드 호스트가 클러스터 관리 역할을 수행하며 두 개의 캐시 호스트가 리드 호스트로 지정되었습니다.

클러스터의 일반 캐시 호스트가 실패하는 경우 클러스터가 계속 실행될 수 있습니다. 리드 호스트가 아닌 호스트의 데이터는 손실되지만(고가용성이 사용하지 않도록 설정된 경우) 클러스터의 나머지 부분은 계속 데이터를 제공하고 저장할 수 있습니다. 실제로 리드 호스트로 지정되지 않은 캐시 호스트 4개가 모두 실패해도 클러스터는 계속 작동할 수 있습니다.

그러나 리드 호스트 중 하나라도 실패하면 실행 중인 리드 호스트 수가 더 이상 과반수가 아니기 때문에 전체 캐시 클러스터가 종료됩니다. 이러한 위험을 줄이기 위해 리드 호스트를 추가로 지정할 수 있습니다.

추가 리드 호스트 지정

설치 후에 추가 리드 호스트를 지정할 수 있습니다. 그러나 리드 호스트를 너무 많이 할당해도 문제가 발생할 수 있음을 고려해야 합니다.

• 캐시 클러스터를 계속 실행하려면 항상 리드 호스트의 과반수가 사용 가능해야 합니다. 리드 호스트로 지정된 호스트가 많을수록 클러스터에서 견디고 계속 작동할 수 있는 서버 실패 수가 감소합니다.

• 한두 개의 리드 호스트 실패만 발생해도 클러스터가 실패할 수 있는 작은 클러스터에서는 리드 호스트를 추가로 지정하는 것이 좋습니다.

• 큰 클러스터에서는 5-7개의 리드 호스트만 지정하면 50개 캐시 서버 범위의 클러스터가 계속 응답하도록 유지할 수 있습니다.

리드 호스트 지정을 변경하는 방법에 대한 자세한 내용은 클러스터 관리 역할 및 리드 호스트 지정 설정(AppFabric 1.1)을 참조하십시오.

Windows Server용 Microsoft AppFabric 1.1의 변경 사항

캐시 클러스터의 가용성을 높이기 위해 AppFabric 1.1에서는 기본 리드 호스트를 지정하는 데 사용되는 프로세스를 변경했습니다. AppFabric 1.1에서는 캐시 클러스터에 추가된 각 캐시 호스트를 하나의 리드 호스트로 최대 7개를 자동으로 설정합니다. IsLeadHost 매개 변수를 "true"로 설정한 상태에서 Set-CacheHostConfig 명령을 사용하여 리드 호스트를 더 많이 지정할 수 있습니다. IsLeadHost를 "false"로 설정하여 리드 호스트에서 캐시 호스트를 제거할 수도 있습니다.

SQL Server가 클러스터 관리 역할을 수행하는 경우

오프로딩을 사용하도록 설정된 캐시 클러스터가 만들어졌을 때 leadHostManagement 설정은 false입니다. 이 시나리오에서는 leadHost 설정에 관계없이, 각 캐시 호스트가 데이터 캐싱과 관련하여 리드 호스트가 아닌 일반적인 책임만 수행합니다. 클러스터 구성 설정을 저장하는 데 사용되는 SQL Server 인스턴스가 클러스터 관리 역할도 수행합니다.

서버 실패가 발생하는 경우

SQL Server가 클러스터 관리 역할을 수행(오프로딩)할 때 클러스터를 계속 사용할 수 있으려면 하나 이상의 캐시 호스트가 SQL Server 데이터베이스에 액세스할 수 있어야 합니다.

예를 들어, 다음 다이어그램과 같이 6개 서버로 이루어진 캐시 클러스터를 고려해 보십시오.

이 예에서는 SQL Server가 클러스터 관리 역할을 수행하며 6개 캐시 호스트가 모두 캐시 클라이언트의 데이터 액세스에 모든 리소스를 사용할 수 있습니다.

클러스터의 캐시 호스트 중 하나가 실패하는 경우 해당 서버의 데이터는 손실되지만(고가용성이 사용하지 않도록 설정된 경우) 클러스터는 계속 실행됩니다. 캐시 클라이언트는 다른 캐시 호스트의 데이터를 계속 사용할 수 있습니다. 실제로 이 시나리오에서는 6개 캐시 호스트 중 5개가 실패해도 클러스터는 계속 작동할 수 있습니다.

SQL Server가 실패하면 전체 클러스터가 몇 분 내에 종료됩니다. 이러한 위험을 줄이려면 Microsoft Windows Server 2008 장애 조치(Failover) 클러스터링(https://go.microsoft.com/fwlink/?LinkId=130692)을 사용하여 캐시 클러스터 구성 저장소 위치 및 클러스터 관리 역할에 대해 "클러스터된" 데이터베이스 리소스를 호스트하는 것이 좋습니다.

참고 항목

개념

AppFabric 캐싱 실제 아키텍처 다이어그램(AppFabric 1.1 캐싱)
AppFabric 캐싱 논리 아키텍처 다이어그램(AppFabric 1.1 캐싱)

  2012-03-05