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

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

분산 캐시 시스템을 배포하는 방법에 따라 클러스터 관리 역할을 수행하는 주체에 대한 두 가지 옵션이 있습니다. 클러스터 구성 설정을 SQL Server 데이터베이스에 저장하는 경우 해당 SQL Server 인스턴스를 사용하여 클러스터 관리 역할을 수행할 수도 있습니다.

공유 네트워크 폴더에 클러스터 구성 설정을 저장하는 경우 클러스터 관리 역할은 항상 리드 호스트라는 특수 캐시 호스트에 의해 수행됩니다. 리드 호스트는 리드 호스트로 지정되지 않은 다른 캐시 호스트와 동일한 작업을 수행하지만 다른 리드 호스트와 함께 클러스터 관리 역할을 수행할 추가적인 책임이 있습니다.

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

클러스터 관리 역할 작업

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

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

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

이러한 설정 변경에 대한 자세한 내용은 클러스터 관리 역할 및 리드 호스트 진단 설정(Windows Server AppFabric 캐싱)을 참조하십시오.

이러한 두 속성을 통해 캐시 호스트의 동작을 결정하는 네 가지 가능한 사례가 발생합니다. 다음 표에서는 이러한 사례에 대해 설명합니다.

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

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

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

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

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

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

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

추가 리드 호스트 지정

AppFabric 구성 마법사는 Cluster Size 드롭다운 목록을 사용하여 클러스터에 포함할 적절한 리드 호스트 수를 결정할 수 있도록 도와줍니다. 필요한 경우 설치 후에 리드 호스트를 추가로 지정할 수도 있습니다. 그러나 리드 호스트를 너무 많이 할당해도 문제가 발생할 수 있음을 고려해야 합니다.

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

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

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

리드 호스트 지정 변경에 대한 자세한 내용은 클러스터 관리 역할 및 리드 호스트 진단 설정(Windows Server AppFabric 캐싱)을 참조하십시오.

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)을 사용하여 캐시 클러스터 구성 저장소 위치 및 클러스터 관리 역할에 대해 "클러스터된" 데이터베이스 리소스를 호스트하는 것이 좋습니다.

참고 항목

개념

Windows Server AppFabric 캐싱 실제 아키텍처 다이어그램
Windows Server AppFabric 캐싱 논리 아키텍처 다이어그램
클러스터 구성 설정(Windows Server AppFabric 캐싱)
클러스터 관리 역할 및 리드 호스트 진단 설정(Windows Server AppFabric 캐싱)

  2011-12-05