ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • vSAN 캐시 사이징 가이드의 진실
    스토리지 지식 2021. 1. 18. 23:02

    Virtual SAN (이하 vSAN)은 VMware의 SDS (software-defined storage) 플랫폼으로서, 가상 시스템을 위한 공유 스토리지를 제공한다. ESXi 하이퍼바이저 커널에 직접 구현되어 있으며, ESXi 호스트의 물리적인 로컬 디스크를 가상화한 후, 요구사항에 따라 분할하여 가상 시스템이나 애플리케이션에 할당할 수 있는 스토리지 풀로 변환한다.

     

    vSAN은 Hybrid 또는 All-flash 클러스터로 구성할 수 있다.

    Hybrid에서는 플래시 디바이스를 Cache layer에 사용하고, 자기 디스크를 스토리지 Capacity layer에 사용한다. All-flash에서는 플래시 디바이스가 Cache 및 Capacity 모두에 사용된다.

     

    하이브리드 클러스터에서 Cache layer의 플래시 디바이스인 SSD는 읽기 및 쓰기 캐시에 사용된다. vSAN은 사용 가능한 모든 캐시의 70%를 Read cache에 할당하고, 사용 가능한 캐시의 30%를 Write buffer에 할당한다.
    올플래시 클러스터에서는 하나의 지정된 SSD가 쓰기 캐시로 사용되고, 추가적인 SSD가 용량에 사용된다. 모든 읽기 요청은 SSD 풀 용량으로부터 직접 수신된다.

     

    VMware에서는 Cache sizing에 대해, 올플래시 및 하이브리드 vSAN 구성 모두에서, 플래시 캐시 디바이스는 가상 머신이 사용할 것으로 예상되는 스토리지 공간의 10% 이상을 반드시 제공해야 하는 것으로 가이드한다. 다시 말해, Capacity 공간 대비 최소 10% 이상의 크기로 Cache용 SSD를 구성하라는 것이다.

    Design Considerations for Flash Caching Devices in Virtual SAN

    docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-1D6AD25A-459A-43D6-8FF5-52475499D6A2.html

     

    필자는, 이 가이드에 틀린 점이 있다고 생각한다.

    캐시 크기는 이상적으로, 워크로드에서 반복적으로 사용되는 블록을 보유할 수 있을 만큼 충분히 커야 한다. 그러므로 이 Active working set를 기반으로 Cache를 사이징 해야 한다. 그러나, 일반적인 워크로드는, 시간에 따른 변화를 나타내며 작업 세트 및 관련 캐시 요구 사항을 변경하기 때문에, 워크로드의 Active working set를 얻기는 쉽지 않다. 어쨌든, 캐싱을 위해서는 그 사이즈가 충분히 커야 한다는 것인데, 중요한 것은 All-flash 구성에서는 Cache용 SSD가 Write buffer로만 사용되고 Read cache용으로는 사용되지 않는다는 것이다. 그러므로, 상기 가이드는 하이브리드 구성에만 유효하다.

     

    아래의 가이드를 보면 워크로드 프로파일에 따라 권장 캐시 사이즈가 제시되어 있다. 하지만, 이는 너무 큰 수치라고 생각한다.

    blogs.vmware.com/virtualblocks/2017/01/18/designing-vsan-disk-groups-cache-ratio-revisited/

    core.vmware.com/resource/vmware-vsan-design-guide#sec5-sub6

     

    또한, 하기 페이지에는 vSAN에 Write buffer 사이즈 제한이 있음에도 Capacity SSD의 내구성을 높일 수 있으므로 Cache용 SSD 사이즈를 제한하지 않아도 된다고 말한다. 이 또한, 필자는 완전히 맞는 말은 아니라고 생각한다.

     

    All-Flash Cache Sizing (www.mrvsan.com/cache-sizing/)
    All flash has a lot more factors to consider, Erasure Coding, Dedupe and Compression and the fact that the cache is purely a Write Buffer so we have to take into account write endurance so the usual 10% sizing does not apply here.?

    In reality the typical 70% Read / 30% Write workload means that a lot of the requests are coming from the Capacity Tier which in this case is flash based anyway, so this means that the cache layer can be much smaller than it would have been in Hybrid for the same RAW capacity, however there is the write endurance factor to take into account.?

    We all know there is a write buffer limit in vSAN but that does not mean you should limit the size of the SSD drives based on that, the main reason is to increase the endurance of the drive, vSAN will cycle through all the cells on the drive irrelevant of the Write Buffer Limit.? VMware recently published a new sizing guide for All-Flash which is shown below

     

     


     

     

    Anyway, 위와 같은 공식적인 자료에도 불구하고, 필자가 다르게 생각하는 점을 정리하면 아래와 같다.

    • All-flash 구성의 vSAN Cache size는 전체 용량의 10%까지 불필요하다.
    • 또한, Capacity 용량 대비 Cache 비율을 정하는 것이 적절하지 않다. (Capacity가 크다고 Cache가 반드시 클 필요 없다.)
    • vSAN의 Cache 사이즈가 600GB로 제한되어 있으므로, 그 이상의 Cache SSD 적용은 무의미하다.

     

    좀 더, 설명을 이어가보겠다.

    vSAN의 공식적인 Cache Recommendation이 Capacity disk 사이즈의 10%로 되어 있지만 (AF, Hybrid 공히), 결론부터 말하면 사이즈에 관계없이 최소 사이즈 (400GB SSD)로 구성해도 된다. 

    이를, 이해하기 위해서는, 캐시가 어떻게 동작하는지 알아봐야 한다.
    위에서 언급했듯, All-flash 구성에서는 Cache가 Write 용도로만 사용되고, Read는 Capacity disk에서 바로 읽어오는 구조이다. 그래서 호스트로부터 데이터가 내려오면 Cache disk에 쌓이고, 기본적으로 사용률이 30%가 되면 Capacity Disk로 De-stage 된다. 물론 이것 말고도 정기/주기적으로 디스테이징하는 알고리즘이 있다. 어쨌든, worst case로 생각해서 400GB Cache disk 기준으로 30%를 가정하면 한 번에 내려쓰는 최대 데이터량은 120GB이다.
    그런데, 대부분의 엔터프라이즈 비즈니스 애플리케이션의 Write 데이터는 초당 120GB를 초과하지 않는다. 이 얘기인즉슨, 이보다 큰 캐시 사이즈는 필요 없다는 말이다. 즉, 400GB SSD보다 큰 것은 필요가 없다.
    바꿔 얘기하면, Write 데이터량이 120GB/s를 초과해야만 400GB보다 더 큰 캐시 드라이브 (e.g. 800GB, 1.6TB)를 쓰는 게 의미 있다는 말이 된다.
    초당 120GB가 들어온다고 하면, 100초면 12TB가 차 버린다는 얘기. 이런 일이 생길까? 네버~
    분당, 아니 시간당 120GB의 Write도 잘 일어나지 않는다. 하루 8시간이면 1TB란 얘기인데, 데이터가 이렇게 저장되면 매달 디스크 증설을 해야 할 것이다.
    Make Sense? 

    그리고, Cache에서 de-staging 하는 write 양이 있는데, 이것이 disk size가 크다고 성능이 좋은 것이 아니다. 
    오히려 400GB짜리 cache disk의 30%, 120GB 내리는 것보다 800GB짜리 30%인 240GB를 내리면 그때 부하가 더 걸린다. 즉, 경우에 따라서는 오히려 작은 사이즈가 더 좋을 수도 있다. (일례로, 400GB 드라이브에서 1초마다 120GB 내리느냐, 800GB에서 2초/3초마다 240GB 내리는 게 나으냐는 별도로 판단해볼 문제) 
    성능은 Disk size보다는 더 좋은 디스크를 쓰는 게 더 빠른 것이다. 예를 들면, TLC보다 MLC SSD, SAS보다는 NVMe SSD..
    디스크 사이즈와 성능은 관계가 없다.

    또한, Write 데이터량에 대해서도 한번 생각해보자. Capacity disk 용량이 크다고 write가 많아지는가? 
    전체 공간은 내가 필요한 만큼 정하는 것일 뿐, 내가 그걸 크게 잡았다고 호스트에서 write가 더 많이 내려오는 것이 아니다. 그래서 필자는 cache 사이징을 capacity disk의 10% 이상을 가이드하는 그 전제가 "기술적으로" 맞지 않다고 이야기하는 것이다. (물론, 벤더로서 이렇게 가이드할 수밖에 없는 이유도 이해한다.)
    Write 양은 전체 Capacity disk 용량과는 무관하고 어떤 워크로드냐, 어떤 업무냐에 따라 결정되는 것이다. 
    다시 말하면, IOPS에 따라 결정되는 것이다. 그리고 그 안에서 Read, Write 비율에 따라 다를 것이다.

    지금까지, Cache size와 성능과는 별 관계가 없기에 800GB, 1.6TB짜리의 디스크로 구성할 필요는 없다고 말했는데, 이것은 캐시 메커니즘상, 그리고, 실제 Write 량이 그만큼 안 된다는 게 주된 이유였다.
    이것 말고, 다른 이유도 있다. 바로 vSAN의 write cache 사이즈가 600GB로 제한되어 있다. 물론, 600GB라고 해서 성능상 전혀 문제가 되지는 않는다. 하지만, vSAN 내부적으로 소프트웨어적인 리밋이 있는데, 더 큰 물리 드라이브를 적용하는 것이 도움이 되지 않는 것은 자명하다.

    그래서, 아무리 Cache를 크게 사이징하더라도, 2 Disk Group 기준, 400GB SSD 2개로 구성하면, 그보다 큰 용량은 무의미하다는 결론이 나온다. vSAN의 Buffer/Cache 용량은 600GB까지 밖에 못 쓰니까!

     

    그런데, Hybrid인 경우에는 다르게 생각해볼 수 있다.

    Cache가 Read 70%, Write 30%로 구분되어 있으므로, All-flash 구성보다는 성능 임팩트가 클 수밖에 없다. 특히, Read 성능에 더 영향을 받을 것이다. 대체로, Read의 사용 비율이 압도적이므로, 캐싱되어 있는 데이터량이 많으면 대부분 Cache hit를 일으킬 수 있기에 성능에 유리할 수밖에 없다. (이 역시, 실제로는 성능 영향이 거의 없을 것이라고 보는데, 그 이유는 400GB~600GB의 70%만 해도 캐시가 충분히 크기 때문이다. Oracle 버퍼 캐시 사이즈를 생각해보면 이해가 더욱 쉽다.)

     

     

    이렇게, vSAN의 구조적인 특성과 I/O 메커니즘을 잘 이해하면, 캐시 사이즈와 성능과의 관계를 보다 뚜렷하게 알 수 있고, 오히려 캐시 사이징에 큰 고민이 불필요하다는 것을 알게 된다.

    • 저장 공간이 커진다고 Cache가 커져야 하는 것은 아니다. All-flash 클러스터에서는 Cache를 Write buffer 용도로만 사용한다. 또한, Capacity 공간이 크다고 더 많은 Write I/O가 내려오는 것이 아니다.
    • 일반적인 OLTP/VDI 환경에서 All-flash 클러스터의 Cache sizing 편차로 인한 성능 차이는 없다고 봐도 무방하다. 이미 최소 용량인 400GB SSD 구성으로도 충분한 경우가 대다수이기 때문이다. (거의 모든 워크로드를 커버함)
    • 또한, vSAN Write buffer 캐시가 최대 600GB까지이므로 성능 이슈가 발생할 수 있다는 것도 우스운 소리이다. 600GB의 용량으로 받아내지 못할 정도의 Heavy 한 Write I/O가 지속적으로 내려오지 않는 이상, 캐싱 공간이 그보다 커야 할 이유는 없기 때문이다.
    • Write buffer 사이즈의 제한이 있음에도, 캐시가 크면 플래시 디바이스의 Wear leveling과 수명을 연장시키기는 하나, 실제로는 Write 비율이 매우 높은 (e.g. 90%) 워크로드가 아닌 다음에야, 1 WPD (Write per Day)의 SSD 내구성만으로도 그 시스템의 수명이 다할 때까지는 충분히 버티고도 남을 만한 쓰기 능력을 제공하므로 캐시 사이즈가 크지 않아도 무방하다.

     

    vSAN 성능 이슈에 대해, Cache가 전체 용량의 10% 이상으로 구성되어 있지 않으므로, 캐시 비율을 충족한 후 모니터 해보자고 했다는 이야기를 들은 적이 있는데, 이것은 엔지니어의 자질을 의심케 하는 대목이다.

    필자는, 이런 질문을 던져본다.

    그러면, Capacity disk 하나를 제거하여, 전체 용량 대비 Cache 비율이 9%에서 11%가 되면 성능이 좋아진단 말인가??

    반대로, 운영 중인 클러스터에 Capacity disk 하나를 추가하면, 성능이 떨어질 것이라 보는가??

     

     

    댓글

Designed by Tistory.