Share via

캐시 서버 유지 관리 고려 사항(Windows Server AppFabric 캐싱)

  • 아티클

Windows Server AppFabric 캐싱 기능은 실제 서버를 사용하여 캐시 클러스터를 지원합니다. 모든 서버는 일정 시점에 유지 관리가 필요하며, 대체로 유지 관리 시 서버를 다시 부팅해야 합니다. 이 항목에서는 유지 관리 시 서버를 다시 부팅해야 하는 경우 캐시 클러스터 가동 중지 시간을 최소화하거나 방지하기 위해 고려할 중요한 사항에 대해 설명합니다.

서버 다시 부팅

단일 서버에 배포된 경우 캐시 클러스터의 단일 실패 지점은 클러스터 구성 저장소 위치입니다. 리드 호스트가 클러스터 관리 역할을 수행하는 경우 잘못해서 다시 부팅한 캐시 서버 수가 너무 많으면 캐시 클러스터가 종료될 수도 있습니다.

클러스터 구성 저장소 위치

클러스터 구성 저장소 위치는 SQL Server 데이터베이스 또는 공유 네트워크 폴더일 수 있습니다. 이 위치에 대한 액세스 권한이 없는 캐시 클러스터는 몇 분 이상 실행할 수 없습니다. SQL Server 또는 파일 서버를 호스트하는 서버를 다시 부팅하기 전에 Stop-CacheCluster 명령을 사용하여 캐시 클러스터를 종료합니다. 이 명령은 모든 캐시 서버에 있는 캐시 호스트 Windows 서비스를 올바른 순서대로 중지합니다. 클러스터 구성 저장소 위치에 대한 자세한 내용은 클러스터 구성 저장소 옵션(Windows Server AppFabric 캐싱)을 참조하십시오.

캐시 서버

일반적으로 한 번에 하나의 캐시 서버만 다시 부팅하는 것이 좋습니다. 다시 부팅하기 위해 서버를 종료하는 경우에는 특별한 절차가 필요하지 않습니다. 캐시 호스트 Windows 서비스만 중지하려는 경우 Stop-CacheHost 명령을 사용합니다. Windows 서비스 콘솔을 사용하여 서비스를 중지하는 기능은 지원되지 않습니다. 다시 부팅한 후 Start-CacheHost 명령을 사용하여 캐시 호스트 Windows 서버가 클러스터에 다시 가입하도록 할 수 있습니다. 자세한 내용은 Windows PowerShell을 사용하여 Windows Server AppFabric 캐싱 기능 관리를 참조하십시오.

리드 호스트가 클러스터 관리 역할을 수행하는 경우 캐시 클러스터를 계속 사용할 수 있으려면 리드 호스트의 과반수가 사용 가능해야 합니다. 이 경우 클러스터에서 한 번에 일부 리드 호스트만 다시 부팅하여 캐시 클러스터가 종료되지 않도록 합니다. 리드 호스트가 아닌 경우 캐시 클러스터의 실행 상태에 영향을 주지 않고 언제든지 다시 부팅할 수 있습니다. 리드 호스트에 대한 자세한 내용은 리드 호스트 및 클러스터 관리(Windows Server AppFabric 캐싱)를 참조하십시오.

참고

Stop-CacheHost 명령은 클러스터 관리 역할을 수행하는 캐시 호스트 Windows 서비스를 중지하지 않으며, 캐시 호스트를 중지하면 전체 클러스터가 종료됩니다.

SQL Server가 클러스터 관리 역할을 수행하는 경우에는 캐시 호스트가 리드 호스트인지 여부를 고려할 필요가 없습니다. 하나의 캐시 호스트에서만 클러스터 실행을 계속할 수 있습니다.

캐시 서버의 캐시 호스트 Windows 서비스가 중지될 때마다 해당 컴퓨터의 메모리에 있는 모든 데이터가 플러시됩니다. 서버 다시 부팅으로 인해 응용 프로그램에서 이러한 데이터 손실이 발생하지 않도록 명명된 캐시에서 고가용성 기능을 사용하도록 설정합니다. 이렇게 하면 성능이 향상되지만 추가 오버헤드가 캐시를 다시 로드하는 비용보다 더 클 수 있습니다.

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

클러스터를 계속 실행하는 데 필요한 최소 서버 수 외에도 응용 프로그램의 메모리 요구를 고려해야 합니다. 응용 프로그램의 캐싱 요구는 대체로 캐시 서버를 다시 부팅했다는 이유만으로 변경되지는 않습니다. 응용 프로그램의 캐싱 요구를 지원하기에 충분한 개수의 캐시 서버가 실행되고 있는 것이 중요합니다.

관리 시 고려할 사항

다시 부팅 시퀀스를 간소화하기 위해 SQL Server 데이터베이스를 사용하여 구성 설정을 저장하고 SQL Server의 해당 인스턴스에서 클러스터 관리 역할을 수행하도록 하는 것이 좋습니다. 이렇게 하면 유지 관리하는 동안 어떤 캐시 서버를 다시 부팅하든 문제가 발생하지 않습니다.

캐시 클러스터의 사용 가능성을 최적화하려면 Windows Server 2008 장애 조치(Failover) 클러스터링을 사용하여 캐시 클러스터 구성 저장소 위치에 대해 "클러스터된" 데이터베이스 또는 폴더 리소스를 호스트하는 것이 좋습니다. 클러스터된 저장소 위치를 사용할 경우 둘 이상의 Windows Server 2008 서버로 "클러스터된" 구성 저장소 위치를 호스트하여 캐시 클러스터 구성 저장소 위치의 사용 가능성에 영향을 주지 않고 한 번에 하나의 장애 조치(Failover) 클러스터링 노드를 다시 부팅할 수 있습니다.

가능한 경우 현재 응용 프로그램에 필요한 개수보다 더 많은 캐시 서버를 추가하여 캐시 클러스터를 확장합니다. 이렇게 하면 캐시 클러스터 성능에 별다른 영향을 주지 않고 적은 개수의 캐시 서버를 다시 부팅할 수 있습니다.

가동 중지 시간이 필요한 작업

캐시 클러스터의 가동 중지 시간이 필요한 여러 작업이 있습니다. 아래에 나열된 모든 작업의 공통된 주제는 캐시 클러스터 구성을 변경해야 한다는 것입니다.

  2011-12-05