스토리지 풀 캐시 이해

적용 대상: Azure Stack HCI, 버전 22H2 및 21H2; Windows Server 2022, Windows Server 2019

Azure Stack HCI 및 Windows Server의 기본 스토리지 가상화 기술인 스토리지 공간 다이렉트는 기본 제공 서버 쪽 캐시를 통해 스토리지 성능을 극대화하는 동시에 비용을 절감합니다. 이는 배포 시 자동으로 구성되는 크고 영구적인 실시간 읽기 및 쓰기 캐시입니다. 대부분의 경우 수동 관리가 전혀 필요하지 않습니다. 캐시의 작동 방식은 존재하는 드라이브의 유형에 따라 다릅니다.

드라이브 유형 및 배포 옵션Drive types and deployment options

저장소 공간 다이렉트는 현재 네 가지 유형의 드라이브에서 작동합니다.

드라이브 유형	설명
	PMem 은 새로운 유형의 짧은 대기 시간, 고성능 스토리지인 영구 메모리를 나타냅니다.
	NVMe (Non-Volatile Memory Express)는 PCIe 버스에 직접 위치하는 솔리드 스테이트 드라이브를 나타냅니다. 일반적인 폼 팩터는 2.5인치 U.2, PCIe AIC(Add-In-Card) 및 M.2입니다. NVMe는 PMem을 제외하고 현재 지원되는 다른 유형의 드라이브보다 더 낮은 대기 시간으로 더 높은 IOPS 및 I/O 처리량을 제공합니다.
	SSD 는 기존 SATA 또는 SAS를 통해 연결되는 솔리드 스테이트 드라이브를 나타냅니다.
	HDD 는 저렴한 비용으로 방대한 저장 용량을 제공하는 회전식 자기 하드 디스크 드라이브를 나타냅니다.

이는 다양한 방법으로 결합될 수 있으며, 이를 "올 플래시"와 "하이브리드"의 두 가지 범주로 그룹화합니다. 모든 HDD를 사용한 배포는 지원되지 않습니다.

비고

이 문서에서는 NVMe, SSD 및 HDD를 사용한 캐시 구성에 대해 설명합니다. 영구 메모리를 캐시로 사용하는 방법에 대한 자세한 내용은 영구 메모리 이해 및 배포를 참조하세요.

All-Flash 배포 가능성

올 플래시 배포는 스토리지 성능을 극대화하는 것을 목표로 하며 HDD를 포함하지 않습니다.

하이브리드 배포 가능성

하이브리드 배포는 성능과 용량의 균형을 맞추거나 용량을 최대화하는 것을 목표로 하며 HDD를 포함합니다.

비고

하이브리드 배포는 단일 서버 구성에서 지원되지 않습니다. 모든 플랫 단일 스토리지 유형 구성(예: 모든 NVMe 또는 모든 SSD)은 단일 서버에 대해 지원되는 유일한 스토리지 유형입니다.

캐시 드라이브가 자동으로 선택됩니다.

여러 유형의 드라이브가 있는 배포에서 저장소 공간 다이렉트 캐싱에 가장 빠른 유형의 모든 드라이브를 자동으로 사용합니다. 나머지 드라이브는 저장 용량을 늘리기 위해 사용됩니다.

어떤 유형이 "가장 빠른" 것인지는 다음 계층에 따라 결정됩니다.

예를 들어 NVMe 및 SSD가 있는 경우 SSD에 대한 NVMe 캐시입니다.

SSD 및 HDD가 있는 경우 SSD는 HDD를 캐시합니다.

비고

캐시 드라이브는 클러스터에 사용 가능한 스토리지 용량을 제공하지 않습니다. 캐시에 저장된 모든 데이터는 다른 곳에도 저장되거나 디스테이징되면 저장됩니다. 즉, 클러스터의 총 원시 스토리지 용량은 용량 드라이브의 합계입니다.

모든 드라이브가 동일한 유형인 경우 캐시가 자동으로 구성되지 않습니다. 동일한 유형의 저내구성 드라이브에 대해 캐시하도록 고내구성 드라이브를 수동으로 구성할 수 있는 옵션이 있습니다 – 방법을 배우려면 수동 구성 섹션을 참조하십시오.

팁 (조언)

경우에 따라 스토리지 풀 캐시를 사용하는 것이 적절하지 않습니다. 예를 들어, 모든 NVMe 또는 모든 SSD 배포에서, 특히 매우 작은 규모에서 캐시에 "사용된" 드라이브가 없으면 스토리지 효율성이 향상되고 성능이 극대화될 수 있습니다. 마찬가지로, 소규모 원격 또는 지점 배포에서는 캐시 드라이브를 위한 공간이 제한될 수 있습니다.

캐시 동작이 자동으로 설정됨

캐시의 동작은 캐시되는 드라이브의 유형에 따라 자동으로 결정됩니다. 플래시 드라이브(예: SSD에 대한 NVMe 캐싱)에 대해 캐싱할 때 쓰기만 캐시됩니다. 회전하는 디스크 드라이브(예: HDD에 대한 SSD 캐싱)에 대해 캐싱할 때 읽기와 쓰기가 모두 캐시됩니다.

모든 플래시 배포를 위한 쓰기 전용 캐싱

캐싱은 예를 들어 NVMe를 캐시로 사용하여 SSD의 성능을 가속화하는 등 모든 플래시 시나리오에서 사용할 수 있습니다. 모든 플래시 배포를 위해 캐싱하는 경우 쓰기만 캐시됩니다. 이렇게 하면 많은 쓰기 및 다시 쓰기가 캐시에 병합된 다음 필요할 때만 스테이징 해제될 수 있으므로 용량 드라이브에 대한 누적 트래픽이 줄어들고 수명이 연장될 수 있으므로 용량 드라이브의 마모가 줄어듭니다. 이러한 이유로 캐시에 대해 내구성이 더 높고 쓰기 최적화된 드라이브를 선택하는 것이 좋습니다. 용량 드라이브는 쓰기 내구성이 합리적으로 낮을 수 있습니다.

읽기는 플래시의 수명에 큰 영향을 미치지 않고 SSD는 보편적으로 낮은 읽기 대기 시간을 제공하기 때문에 읽기는 캐시되지 않고 용량 드라이브에서 직접 제공됩니다(데이터가 너무 최근에 기록되어 아직 스테이징 해제되지 않은 경우 제외). 이렇게 하면 캐시가 전적으로 쓰기 전용으로 사용되어 효율성이 극대화됩니다.

이로 인해 쓰기 대기 시간과 같은 쓰기 특성은 캐시 드라이브에 의해 결정되는 반면 읽기 특성은 용량 드라이브에 의해 결정됩니다. 둘 다 일관되고 예측 가능하며 균일합니다.

하이브리드 배포를 위한 읽기/쓰기 캐싱Read/write caching for hybrid deployments

HDD를 캐싱할 때 읽기 와 쓰기가 모두 캐시되어 둘 다 플래시와 같은 대기 시간(종종 ~10배 더 나은)을 제공합니다. 읽기 캐시는 빠른 액세스를 위해 최근에 읽은 데이터와 자주 읽은 데이터를 저장하고 HDD에 대한 임의 트래픽을 최소화합니다. (검색 및 회전 지연으로 인해 HDD에 대한 임의 액세스로 인해 발생하는 대기 시간과 시간 손실이 상당합니다.) 쓰기는 버스트를 흡수하고, 이전과 마찬가지로 쓰기와 다시 쓰기를 통합하고 용량 드라이브에 대한 누적 트래픽을 최소화하기 위해 캐시됩니다.

저장소 공간 다이렉트 쓰기를 스테이징 해제하기 전에 임의로 설정하는 알고리즘을 구현하여 워크로드(예: 가상 머신)에서 오는 실제 I/O가 임의인 경우에도 순차적으로 보이는 디스크에 IO 패턴을 에뮬레이트합니다. 이렇게 하면 HDD에 대한 IOPS 및 처리량이 최대화됩니다.

NVMe, SSD 및 HDD를 사용한 배포에서 캐싱

세 가지 유형의 드라이브가 모두 있는 경우 NVMe 드라이브는 SSD와 HDD 모두에 대한 캐싱을 제공합니다. 동작은 위에서 설명한 것과 같습니다: SSD에 대해서는 쓰기만 캐시되고 읽기와 쓰기는 모두 HDD에 대해 캐시됩니다. HDD에 대한 캐싱 부담은 캐시 드라이브 간에 균등하게 분산됩니다.

요약

이 표에는 캐싱에 사용되는 드라이브, 용량에 사용되는 드라이브 및 각 배포 가능성에 대한 캐싱 동작이 요약되어 있습니다.

배치	캐시 드라이브	용량 드라이브	캐시 동작(기본값)
모든 NVMe	없음(선택 사항: 수동으로 구성)	NVMe	쓰기 전용(구성된 경우)
모든 SSD	없음(선택 사항: 수동으로 구성)	SSD(솔리드 스테이트 드라이브)	쓰기 전용(구성된 경우)
NVMe + SSD	NVMe	SSD(솔리드 스테이트 드라이브)	쓰기 전용
NVMe + HDD	NVMe	하드디스크	읽기 + 쓰기
SSD + HDD	SSD(솔리드 스테이트 드라이브)	하드디스크	읽기 + 쓰기
NVMe + SSD + HDD	NVMe	SSD + HDD	HDD의 경우 읽기 + 쓰기, SSD의 경우 쓰기 전용

서버 측 아키텍처

캐시는 드라이브 수준에서 구현되며, 한 서버 내의 개별 캐시 드라이브는 동일한 서버 내의 하나 이상의 용량 드라이브에 바인딩됩니다.

캐시는 Windows 소프트웨어 정의 스토리지 스택의 나머지 부분보다 아래에 있기 때문에 스토리지 공간 또는 내결함성과 같은 개념에 대한 인식이 없거나 필요하지 않습니다. "하이브리드"(일부는 플래시, 일부는 디스크) 드라이브를 만든 다음 운영 체제에 제공하는 것으로 생각할 수 있습니다. 실제 하이브리드 드라이브와 마찬가지로 물리적 미디어의 더 빠른 부분과 느린 부분 간의 핫 및 콜드 데이터의 실시간 이동은 외부에서는 거의 보이지 않습니다.

저장소 공간 다이렉트 복원력이 서버 수준 이상이라는 점을 감안할 때(즉, 데이터 복사본이 항상 다른 서버에 기록됨, 서버당 최대 하나의 복사본) 캐시의 데이터는 캐시에 없는 데이터와 동일한 복원력의 이점을 누릴 수 있습니다.

예를 들어 3방향 미러링을 사용하는 경우 모든 데이터의 복사본 3개가 서로 다른 서버에 기록되어 캐시에 저장됩니다. 나중에 스테이징 해제되는지 여부에 관계없이 항상 세 개의 복사본이 존재합니다.

드라이브 바인딩은 동적입니다.

캐시와 용량 드라이브 간의 바인딩은 1:1에서 최대 1:12 이상까지 모든 비율을 가질 수 있습니다. 확장 또는 장애 후와 같이 드라이브가 추가되거나 제거될 때마다 동적으로 조정됩니다. 즉, 원할 때마다 캐시 드라이브 또는 용량 드라이브를 독립적으로 추가할 수 있습니다.

대칭을 위해 용량 드라이브 수를 캐시 드라이브 수의 배수로 만드는 것이 좋습니다. 예를 들어 4개의 캐시 드라이브가 있는 경우 7 또는 9보다 8개의 용량 드라이브(1:2 비율)에서 더 균일한 성능을 경험할 수 있습니다.

캐시 드라이브 오류 처리

캐시 드라이브에 오류가 발생하면 아직 스테이징 해제되지 않은 모든 쓰기는 로컬 서버로 손실되며, 이는 다른 복사본(다른 서버)에만 존재함을 의미합니다. 다른 드라이브 오류 후와 마찬가지로 저장소 공간 남아 있는 복사본을 참조하여 자동으로 복구할 수 있습니다.

잠시 동안 손실된 캐시 드라이브에 바인딩된 용량 드라이브가 비정상으로 표시됩니다. 캐시 다시 바인딩이 발생하고(자동) 데이터 복구가 완료되면(자동) 정상으로 다시 표시됩니다.

이 시나리오는 성능을 유지하기 위해 서버당 최소 두 개의 캐시 드라이브가 필요한 이유입니다.

그런 다음 다른 드라이브 교체와 마찬가지로 캐시 드라이브를 교체할 수 있습니다.

비고

AIC(Add-In Card) 또는 M.2 폼 팩터인 NVMe를 안전하게 교체하기 위해 전원을 꺼야 할 수도 있습니다.

다른 캐시와의 관계

Windows 소프트웨어 정의 스토리지 스택에는 관련이 없는 몇 가지 다른 캐시가 있습니다. 예를 들어 저장소 공간 쓰기 저장 캐시 및 CSV(클러스터 공유 볼륨) 메모리 내 읽기 캐시가 있습니다.

Azure Stack HCI를 사용하면 저장소 공간 쓰기 저장 캐시를 기본 동작에서 수정해서는 안 됩니다. 예를 들어 New-Volume cmdlet의 -WriteCacheSize와 같은 매개 변수를 사용하면 안 됩니다.

CSV 캐시를 사용할지 여부를 선택할 수 있습니다 – 그것은 당신에게 달려 있습니다. Azure Stack HCI에서는 기본적으로 켜져 있지만 어떤 식으로든 이 항목에 설명된 캐시와 충돌하지 않습니다. 특정 시나리오에서는 중요한 성능 향상을 제공할 수 있습니다. 자세한 내용은 Azure Stack HCI에서 CSV 메모리 내 읽기 캐시 사용을 참조하세요.

수동 구성

대부분의 배포에서는 수동 구성이 필요하지 않습니다. 필요한 경우 다음 섹션을 참조하세요.

설정 후 캐시 디바이스 모델을 변경해야 하는 경우 Health Service 개요에 설명된 대로 Health Service의 지원 구성 요소 문서를 편집합니다.

캐시 드라이브 모델 지정

모든 드라이브가 모든 NVMe 또는 모든 SSD 배포와 같이 동일한 유형인 배포에서는 Windows가 동일한 유형의 드라이브 간에 쓰기 내구성과 같은 특성을 자동으로 구분할 수 없기 때문에 캐시가 구성되지 않습니다.

내구성이 높은 드라이브를 사용하여 동일한 유형의 내구성이 낮은 드라이브를 캐시하려면 Enable-ClusterS2D cmdlet의 -CacheDeviceModel 매개 변수와 함께 사용할 드라이브 모델을 지정할 수 있습니다. 해당 모델의 모든 드라이브는 캐싱에 사용됩니다.

팁 (조언)

Get-PhysicalDisk의 출력에 표시되는 것과 정확히 일치해야 합니다.

예시

먼저 실제 디스크 목록을 가져옵니다.

Get-PhysicalDisk | Group Model -NoElement

다음은 몇 가지 출력 예입니다.

Count Name
----- ----
    8 FABRIKAM NVME-1710
   16 CONTOSO NVME-1520

그런 다음 다음 명령을 입력하여 캐시 장치 모델을 지정합니다.

Enable-ClusterS2D -CacheDeviceModel "FABRIKAM NVME-1710"

PowerShell에서 Get-PhysicalDisk 를 실행하고 해당 Usage 속성이 "Journal"인지 확인하여 의도한 드라이브가 캐싱에 사용되고 있는지 확인할 수 있습니다.

수동 배포 가능성

수동 구성을 사용하면 다음과 같은 배포 가능성을 사용할 수 있습니다.

캐시 동작 설정

캐시의 기본 동작을 재정의할 수 있습니다. 예를 들어, all-flash 배포에서도 읽기를 캐시하도록 설정할 수 있습니다. 기본값이 작업 부하에 적합하지 않다고 확신하지 않는 한 동작을 수정하지 않는 것이 좋습니다.

동작을 재정의하려면 Set-ClusterStorageSpacesDirect cmdlet과 해당 -CacheModeSSD 및 -CacheModeHDD 매개 변수를 사용합니다. CacheModeSSD 매개 변수는 SSD에 대해 캐싱할 때 캐시 동작을 설정합니다. CacheModeHDD 매개 변수는 HDD에 대해 캐시할 때 캐시 동작을 설정합니다.

Get-ClusterStorageSpacesDirect를 사용하여 동작이 설정되었는지 확인할 수 있습니다.

예시

먼저 저장소 공간 다이렉트 설정을 가져옵니다.

Get-ClusterStorageSpacesDirect

다음은 몇 가지 출력 예입니다.

CacheModeHDD : ReadWrite
CacheModeSSD : WriteOnly

그런 후 다음을 수행합니다.

Set-ClusterStorageSpacesDirect -CacheModeSSD ReadWrite

Get-ClusterS2D

다음은 몇 가지 출력 예입니다.

CacheModeHDD : ReadWrite
CacheModeSSD : ReadWrite

캐시 크기 조정

캐시는 응용 프로그램 및 워크로드의 작업 집합(지정된 시간에 적극적으로 읽거나 쓰는 데이터)을 수용할 수 있도록 크기를 조정해야 합니다.

이는 하드 디스크 드라이브를 사용하는 하이브리드 배포에서 특히 중요합니다. 활성 작업 집합이 캐시 크기를 초과하거나 활성 작업 집합이 너무 빨리 드리프트되는 경우 읽기 캐시 누락이 증가하고 쓰기를 보다 적극적으로 디스테이징해야 하므로 전반적인 성능이 저하됩니다.

Windows에 내장된 성능 모니터(PerfMon.exe) 유틸리티를 사용하여 캐시 누락 비율을 검사할 수 있습니다. 특히 클러스터 스토리지 하이브리드 디스크 카운터 집합의 Cache Miss Reads/sec를 배포의 전체 읽기 IOPS와 비교할 수 있습니다. 각 "하이브리드 디스크"는 하나의 용량 드라이브에 해당합니다.

예를 들어, 4개의 용량 드라이브에 바인딩된 2개의 캐시 드라이브는 서버당 4개의 "하이브리드 디스크" 개체 인스턴스를 생성합니다.

보편적인 규칙은 없지만 너무 많은 읽기에서 캐시가 누락되면 크기가 작을 수 있으므로 캐시를 확장하기 위해 캐시 드라이브를 추가하는 것이 좋습니다. 원할 때마다 캐시 드라이브 또는 용량 드라이브를 독립적으로 추가할 수 있습니다.

다음 단계

추가 스토리지 지식은 다음을 참조하세요.

• 내결함성 및 스토리지 효율성
• 클러스터 및 풀 쿼럼