Researchers: SSDs struggle in virtual machines thanks to garbage collection

   Á¶È¸ 2270   Ãßõ 2    

위 글에서 사용된 SSD가 850 pro라고 하셨는데요. 

850 pro는 consumer SSD 중에서 좋다고 소문난 SSD입니다. 사실 enterprise용 SSD인 SM863과 같은 콘트롤러를 사용합니다.

차이라면 SM863은 기업용이니만큼 수퍼캐퍼시터를 달아서 power loss protection 기능이 있다는 점, overprovisioning을 충분히 한다는 점, firmware가 기업용 특성에 맞게 조정되어 있다는 점(sustained 성능을 높이는 데 중점을 둠) 정도입니다. 두번째 세번째는 모두 garbage collection에 관계된 것입니다.

그런데 이미 850 pro에 충분한 overprovisioning을 했는데도 시간이 지남에 따라 성능이 저하된다고 하셨어요. 솩 정리하고 다시 붙이면 성능이 좋아진다는 것으로 보아 다른 문제도 아닌 것 같습니다.

과연 이 문제가 trim을 하면 해결될 문제인가? 기업용 SSD를 사용하면 해결될 문제인가?

듣보잡 SSD도 아니고, SM863과 같은 콘트롤러를 쓰는 850 pro에 overproviaioning을 충분히 했는데도 저렇게까지나 성능이 degrade될까나? 의문이 생기더군요.


좀 찾아보니 오래된 것이기는 하지만 이런 글이 있었습니다.

Researchers: SSDs struggle in virtual machines thanks to garbage collection

https://www.extremetech.com/computing/206638-researchers-ssds-struggle-in-virtual-machines-thanks-to-garbage-collection


garbage collection 알고리즘으로 인해 하나의 SSD에 많은 수의 가상머신을 돌리게 되면 시간이 지남에 따라 성능이 저하한다는 것입니다. 이 글에서는 consumer SSD라고 했지만 기업용이라고 해서 뾰족한 다른 수는 없을 것 같습니다. 일반용이나 기업용이나 근본적인 차이가 있는 것은 아니니까요.


이 글의 근원은 아래 논문입니다.

Towards SLO Complying SSDs Through OPS Isolation

https://www.usenix.org/system/files/conference/fast15/fast15-paper-kim-jaeho.pdf


한국 사람들이 쓴 논문이네요.


이 글에서 말하는 해결책은 콘트롤러를 새롭게 설계를 해서 가상머신마다 따로 따로 다른 블럭에 쓰기를 하도록 하면 된다는 것인데요. 그런 SSD는 당분간 기대하기 힘들 것 같습니다.


trim을 한다고 해결될 문제도 아니고 기업용을 쓴다고 해결될 문제도 아니고 NVMe SSD를 쓴다고 해결될 문제도 아닌 것 같아요.


해결책은

1. 지금처럼 가끔 한번씩 SSD를 꺼내 초기화 해 주고 다시 집어넣는다.

2. 작은 SSD를 여러개 사서 가상머신을 각각에 집어넣는다. 가상머신 하나마다 SSD 하나가 불가능하다면 SSD 하나마다 들어가는 가상머신 숫자를 최소로 줄임

3. optane SSD를 사서 이것으로 일반 SSD 혹은 하드디스크를 caching한다.

optane SSD가 굉장히 비싼데요. 기업용인 P4800X 뿐만 아니라 일반용인 900P 혹은 905P도 역시 성능은 비슷합니다.


optane SSD는 flash로 만드는 SSD와는 매체가 근본적으로 다릅니다. trim은 지원하지 않는데요. 필요하지 않아서 지원하지 않는 것입니다. garbage collection의 필요성도 굉장히 적습니다.

모든 문제들이 flash chip의 특성에서 비롯되는 것입니다.

읽기는 아주 빠르게 효율적으로 할 수 있는데, 쓰기를 하려면 한 블럭을 일단 지우고 나서 그 블럭을 써야 된다는 문제. 한 블럭에서 약간만 바꾸려면 일단 그 블럭 전체를 다 읽어들인 후 블럭 전체를 지우고 나서 변경된 데이터와 함께 전체 블럭을 써줘야 한다는 것. 이런 것 때문에 garbage collection이 필요하고 trim도 필요한 것입니다.

optane은 그런 문제가 없습니다. 그냥 필요한 그곳만 쓰기해 주면 됩니다. 마치 ram처럼.


위 3번에서 caching용이라면 900P 제일 작은 것이 375GB인데요. 그것으로 SSD를 캐싱한다면 좋을 것 같습니다. cold data는 결국 SSD에 씌여지지만 캐싱을 거친 뒤 나중에 serial화 하여 기록되므로 앞서와 같은 문제는 별로 없을 것 같습니다.


p.s. P4800X 제일 작은 것이 375GB이고, 900P는 280GB가 제일 작은 것이네요. 905P는 480GB가 제일 작은 것. 성능은 900P나 905P도 4800X에 못지 않습니다. 무엇보다 flash가 아니라는 점. trim도 필요 없고 SSD와 같은 garbage collection도 필요 없음. 이것도 수명이 있으니 wear leveling은 필요하겠지만 그냥 mapping table 관리 정도면 충분할 겁니다. clean cell을 만들기 위한 erase 작업이 필요 없음.

좋은 SSD라는 것은 NAND flash의 저러한 단점을 controller나 firmware로 얼마나 잘 극복하느냐에 달려 있는데요. 결국 garbage collection을 얼마나 효율적으로 하느냐입니다. 수백명 수천명이 동시 접속하는 데이터베이스 처리 같은 것도 좋은 기업용 SSD는 잘 처리합니다. 그런데 많은 수의 가상머신이 동시에 입출력하면 특히 가상머신들의 IO 행태가 다른 종류이면 garbage collection을 현재의 콘트롤러들로는 잘 해 내기 어렵다는 것입니다.


-------

저 위 논문에서 말하는 해결책은 가상머신마다 독자적인 블럭에서 입출력을 하도록 하여 한 블럭 안에서 서로 다른 가상머신들이 입출력하지 않도록 만든다는 것인데요.

또 다른 해결책은 현재의 trim을 확장하여 파일 안에서 쓰지 않는 블럭을 trim하여 GC를 효율적으로 해 내는 것입니다.

두가지 중의 한가지만 되면 해결된다기 보다 두가지 모두 이루어지면 훨씬 나아지겠지요. 물론 flash가 아닌 optane에서는 그러지 않아도 됨


https://beowulf.github.io/publications/ftrim-resolve12.pdf

가상머신(게스트)에서 파일을 지워 trim을 하더라도 호스트로 전달되어 trim이 이루어지지 않는다는 것이죠. 그래서 그걸 host로 전달하여 host에서 trim이 되도록 trim을 확장해야 한다는 논문. ftrim : file level trim



ªÀº±Û Àϼö·Ï ½ÅÁßÇÏ°Ô.
¹Ú¹®Çü 2019-01
¼ö°í ¸¹À¸½Ê´Ï´Ù..

ÇÏÀ̺긮µå ·¹ÀÌµå ½Ã½ºÅÛµµ ÇØ°áÃ¥ÀÌ µÉ±î¿ä??
optane SSD°¡ ÀÖ´Ù¸é ´çÀå ½ÇÇèÇØ º¸°í ½Í±º¿ä.

¸çÄ¥ Àü¿¡ eBay¿¡ optane SSD °æ¸Å ³ª¿Â °ÍÀ» ÁÖ½ÃÇÏ°í ÀÖ¾ú´Âµ¥, ¸¶Áö¸· ¼ø°£¿¡ ¾î´À ³ðÀÌ ²Ï ºñ½Ñ °ª¿¡ ä°¡¹ö·È¾î¿ä. Á¤Ç°µµ ¾Æ´Ï°í ¿£Áö´Ï¾î¸µ »ùÇÃÀÌ¶ó¼­ ¼³¸¶ÇÏ°í ¾È½ÉÇÏ°í ÀÖ¾ú´Âµ¥, ¾î¼¸é ±× ³ðÀÌ ¿£Áö´Ï¾î¸µ »ùÇÃÀÎ °ÍÀ» º¸Áö ¸øÇÏ°í ºñ½Ñ °ª¿¡ ä°£ °ÍÀÏÁöµµ ¸ð¸£°Ú½À´Ï´Ù.


QnA
Á¦¸ñPage 4380/5589
2015-12   1029696   ¹é¸Þ°¡
2014-05   4476956   Á¤ÀºÁØ1
2015-06   3081   ÀÓÁ¾¿­
2015-08   3081   ÀÓ½ÃÇö
2020-03   3081   galaxyfamily
2016-02   3081   °í°í¹Ù
2021-01   3081   ½½·¯±×
2017-04   3081   LINKINPARK
2014-04   3081   ȲÁø¿ì
2015-07   3081   ±èȲÁß
2015-03   3081   ³ªºñz
2016-01   3081   ¹«¾Æ
2015-07   3081   SecondToNone
2018-12   3081   BlueApple
2017-06   3081   Sikieiki
2017-04   3081   ½ÂÈĴϵµÄì
2020-05   3081   ³ªÆÄÀÌ°­½ÂÈÆ
2014-11   3081   À̱ԹÎ
2014-02   3081   ¾ç¿µÈÆ
2018-10   3081   ¹Ú¹®Çü
2018-12   3080   ´ÃÆĶõ
2015-07   3080   ÁÒ½´¾Æ