캐시 서버 업데이트

아티클
03/05/2012

Windows Server용 Microsoft AppFabric 1.1 캐시 클러스터는 함께 작동하여 통합 메모리 내 캐시를 제공하는 하나 이상의 서버로 구성됩니다. 캐시 클러스터에 있는 하나 이상의 서버를 업데이트해야 하고 이러한 업데이트가 다시 부팅을 필요로 하는 경우가 있습니다. 이 섹션에서는 이러한 패치 시나리오에 대한 캐시 클러스터 지침을 제공합니다.

예약된 유지 관리

이 문제의 가장 쉬운 해결 방법은 모든 캐시 서버에서 업데이트를 수행하는 유지 관리 기간을 예약하는 것입니다. 이 시나리오에서는 Stop-CacheCluster 명령으로 캐시 클러스터를 중지하고 컴퓨터를 업데이트한 다음 Start-CacheCluster 명령으로 캐시 클러스터를 시작합니다. 이 방법은 요구가 적은 기간의 캐시에 가장 잘 작동합니다. 클라이언트 응용 프로그램이 캐시 클러스터에 대해 일관된 요구를 가지는 경우 업그레이드 동안 캐시 클러스터가 작동 상태를 유지하는 다른 옵션을 고려할 수 있습니다.

순차적 캐시 서버 업데이트

캐시 클러스터가 실행되고 있는 동안 개별 캐시 서버를 업데이트할 수 있습니다. 이렇게 하려면 캐시 클러스터에 최소 두 개의 캐시 호스트가 있어야 합니다. 기본 프로세스는 다음 단계로 구성됩니다.

Stop-CacheHost 명령으로 클러스터에 있는 서버 하나를 중지합니다. 가능한 경우 Graceful 스위치를 사용하여 캐시된 데이터를 중지되기 전에 해당 캐시 호스트에서 이동하십시오.
해당 서버를 업데이트한 다음 다시 부팅합니다.
Start-CacheHost 명령을 사용하여 서버를 시작합니다.
순차적으로 각 캐시 서버에 대해 이 단계를 반복합니다.

이러한 단계가 간단하기는 하지만 다음 섹션에 설명되어 있는 몇 가지 고려 사항이 있습니다.

리드 호스트 업데이트

클러스터 관리 역할은 캐시 클러스터의 캐시 호스트를 성공적으로 관리하기 위해 존재합니다. 캐시 클러스터 구성 설정을 저장하는 데 XML 공급자를 사용하는 경우 일부 캐시 호스트를 리드 호스트로 지정하여 이 역할이 수행됩니다. 캐시 클러스터가 작동 상태를 유지하도록 하려면 리드 호스트의 과반수가 실행 중이어야 합니다. 이는 순차적으로 캐시 서버를 업데이트하는 데 영향을 줍니다. 다음 두 서버 캐시 클러스터를 고려해 봅시다.

호스트 이름	리드 호스트 여부
CacheServer1	예
CacheServer2	아니요

이 예에서 CacheServer1은 이 2 노드 캐시 클러스터의 리드 호스트입니다. 과반수의 리드 호스트가 실행되고 있어야 하므로 캐시 클러스터를 중지하지 않고는 CacheServer1을 중지할 수 없습니다. 이 예에서 두 서버를 모두 리드 호스트로 지정하는 것은 도움이 되지 않습니다. 서버 중 하나를 다운 상태로 만들면 과반수의 리드 호스트가 실행 중이지 않게 되기 때문입니다. 이 문제를 해결하려면 Export-CacheClusterConfig 및 Import-CacheClusterConfig 명령으로 다른 캐시 호스트 서버를 추가하고 모든 서버를 리드 호스트로 지정합니다. 지정된 리드 호스트를 변경하는 방법에 대한 자세한 내용은 클러스터 관리 역할 및 리드 호스트 지정 설정을 참조하십시오. 이러한 변경 사항을 따르는 캐시 클러스터를 고려해 봅시다.

호스트 이름	리드 호스트 여부
CacheServer1	예
CacheServer2	예
CacheServer3	예

이 새 구성에서는 세 서버 모두가 리드 호스트입니다. 이제 업데이트를 수행하기 위해 한 번에 캐시 서버 하나를 다운 상태로 만들 수 있습니다.

SQL Server가 리드 호스트 대신 클러스터 관리 역할을 수행하므로 System.Data.SqlClient 공급자는 이 문제를 겪지 않습니다. 리드 호스트에 대한 자세한 내용은 리드 호스트 및 클러스터 관리를 참조하십시오.

고가용성을 사용하는 캐시로 캐시 호스트 업데이트

고가용성은 다른 캐시 호스트에 캐시된 항목의 보조 복사본을 만듭니다. 기본 캐시 호스트를 사용할 수 없는 경우 캐시된 항목이 보조 캐시 호스트에서 제공됩니다. 따라서 캐시된 데이터가 손실되지 않습니다. 이 기능에 대한 자세한 내용은 고가용성을 참조하십시오. 정의된 대로, 고가용성은 캐시 클러스터에 세 개 이상의 서버가 있어야 한다고 요구합니다. 캐시된 항목은 한 서버에 있고 다른 서버에 보조 복사본을 가지며 기본 또는 보조 서버가 다운 상태가 된 경우 세 번째 서버에 의존하여 고가용성 요구 사항을 수행할 수 있습니다. 두 캐시 호스트만 실행 중인 경우 고가용성을 유지하기 위한 세 번째 서버가 없기 때문에 두 캐시 호스트 중 어느 한쪽을 개별적으로 중지할 수 없습니다.

Windows PowerShell 스크립트를 사용하여 하나 이상의 캐시가 고가용성 기능을 사용하는지 확인할 수 있습니다. 다음 PowerShell 스크립트는 각 캐시를 순환하며 Secondaries 속성을 확인하는 예를 제공합니다.

Import-Module DistributedCacheAdministration

Use-CacheCluster

$Caches = Get-Cache -MaxRegions 0
$HighAvailability = $false

foreach ($Cache in $Caches)
{
   $CacheConfig = Get-CacheConfig $Cache.CacheName
   if ($CacheConfig.Secondaries -eq 1)
   {
      Write-Host $CacheConfig.CacheName
      $HighAvailability = $true
   }
}

if ($HighAvailability -eq $true)
{
   Write-Host "One or more caches use high availability (Secondaries = 1)"
}
else
{
   Write-Host "No caches use high availability (Secondaries = 1)"
}

캐시 클러스터에 서버가 셋 이상 있더라도 이러한 서버를 순차적으로 업데이트하기 전에 Get-CacheHost로 해당 실행 상태를 확인해야 합니다.

클라이언트 응용 프로그램 고려 사항

캐시 클러스터를 중지하지 않고 캐시 호스트를 순차적으로 업데이트하는 경우 캐시 클러스터에 액세스하는 클라이언트 응용 프로그램에 대한 몇 가지 중요한 고려 사항이 있습니다.

응용 프로그램은 처음 캐시 클러스터에 연결하기 위해 하나 이상의 캐시 호스트를 이름으로 참조합니다. 이는 응용 프로그램 구성 파일 또는 프로그래밍 방식으로 이루어집니다. 클라이언트 응용 프로그램이 하나의 캐시 호스트만 가리키는 경우 해당 호스트가 다운 상태인 동안에는 캐시 클러스터에 대한 새 연결을 만들 수 없습니다. 클라이언트 응용 프로그램은 가능한 경우 둘 이상의 캐시 호스트를 참조해야 합니다. 클라이언트 응용 프로그램이 모든 캐시 호스트를 참조해야 하는 것은 아닙니다. 참조된 캐시 호스트는 전체 클러스터에 대한 게이트웨이 역할을 합니다.
캐시 호스트가 중지되면 응용 프로그램이 중지된 캐시 호스트에 이전에 있던 항목을 찾을 수 없습니다. 응용 프로그램이 해당 항목을 다시 채워야 합니다.
캐시 호스트가 중지되면 응용 프로그램에 일시적으로 여러 DataCacheException 예외가 표시될 수 있습니다. 이러한 예외는 캐시 클러스터가 캐시 호스트 손실에 적응함에 따라 자동으로 해결됩니다. 응용 프로그램은 일반적인 예외를 예상할 수 있도록 설계되어야 합니다. 클라이언트는 다시 시도 논리를 구현하도록 결정하거나 예외가 해결될 때까지 원본 데이터를 사용할 수 있습니다. 자세한 내용은 오류 처리를 참조하십시오.
캐시 호스트가 중지되면 응용 프로그램이 고가용성을 사용하는 캐시에 일시적으로 쓸 수 없을 수 있습니다. 캐시 호스트가 중지된 후 캐시된 항목(보조)의 새 복사본이 다른 캐시 호스트에 만들어집니다.

참고 항목

개념

일반 캐시 클러스터 관리 작업(Windows Server AppFabric 캐싱)

2012-03-05

다음을 통해 공유