예전에 낄낄님께서 뉴스 게시판에 올리신 이 있지만 이게 더 자세하고 볼게 더 많은 것 같아서 올려봅니다.

출처:http://it.anandtech.com/IT/showdoc.aspx?i=3532&p=1
============================================
번역한 시간이 주로 늦은 밤이나 새벽이라 비몽사몽한 상태에서 한 부분이 꽤 됩니다.(..............)

거기다 실력도 부족해서 많이 이상할 텐데, 지적해 주시면 감사하겠습니다.
========================================

1장. 서문

 몇년 전의 "Enterprise SATA" 디스크의 도입은 모든 기업들이 갈망하던 저장 공간에 대한 훌륭한 대안이었습니다. 드라이브마다 1테라바이트에 이르는 용량과 함께, "레이드가 허락된"  SATA 디스크는 높은 신뢰성과 함께 대용량의 전자기적 저장 공간을 가능케 했습니다. 만약 당신이 저장 공간을 원했다면 기가바이트당 20센트에 이르는 저렴한 가격으로 마그네틱 디스크는 값싼 해결책을 제공했지만, 곧 실패하고 말았습니다. 탐색 시간이나 레이턴시와 같은 성능이 가히 절망적인 수준이었고 더 비싸지만 더 빠른 SCSI가 대안으로 떠올랐기 때문이지요. 그 속도는 속도가 나노초로 표현되는 CPU나 RAM에 비해 1만배에서 10만배 정도 느렸습니다. 더 절망적인 것은 지난 10년 동안 대역폭이 10배나 커진 반면에 탐색 시간과 레이턴시 같은 시간이 2.5배밖에 향상되지 못했다는 점이었습니다. 거기다, CPU는 60배 이상이나 빨랐다는 사실입니다.(기준점으로 제시하자면 당시 정상급 서버는 2MB의 L2 캐쉬를 지닌 450MHz Xeon으로 구동되고 있었습니다.)

 이 일방적인 성능의 향상은 병목 현상을 일으키는 주요 원인이 되었으며, 특히 OLTP 데이터베이스나 e-mail 서버가 무작위로 접근된다는 것을 감안하면 그 문제는 심각했습니다. 어플리케이션 캐쉬와 레이드 컨트롤러의 캐쉬, 하드 디스크의 캐쉬와 레이드 설정은 현재의 하드 디스크의 끔찍한 성능을 부분적으로나마 숨길 수 있게 해 주었지만 우리는 부분적으로라는 점을 주목해야 합니다. 캐쉬 메모리가 항상 올바른 데이터를 가지고 있는 것은 아니었고 수많은 독립적이고 개별적인 I/O 쓰레드를 발생시키는 데이터베이스 관리 체계의 개발을 위해 많은 조사와 소프트 엔지니어링을 필요로 했습니다. 뛰어난 I/O 쓰레드 시스템이 없이는 디스크의 성능을 향상시키기 위한 레이드 설정조차 불가능했으니까요.

 한번 생각해 봅시다. 수많은 회전하는 디스크를 구매하고, 설치하고, 전원을 공급해서 월요일 아침마다 메일 서버를 확인하고 상호작용하는 어플리케이션을 설치하는 것은 디스크 용량과 전력, 그리고 결정적으로 돈 낭비일 뿐입니다. 거기다, 이 옛날부터 존재하던 문제를 해결하기 위한 돈이 덜 들고 덜 효율적인 방법에 필요한 것은 디스크 용량과 전력뿐만이 아닙니다. 당신은 모든 디스크에서 전원이 하나라도 차단되는 것을 방지하기 위한 UPS(무정전 전원 소스)와 비싼 소프트웨어, 그리고 수많은 디스크를 관리하기 위한 인력을 필요로 합니다. 인텔의 slc SSD인 X25-E는 엄청난 속도로 OLTP 어플리케이션을 돌리는 데 걸리는 시간을 줄여줍니다. 성능에 대한 깊은 분석을 통해, 우리는 차세대 제품인 SSD가 언제쯤 합리적인 선택이 될지 알아낼 수 있도록 노력하겠습니다.

 2장. 디스크 전략들

 마그네틱 디스크를 사용하면서 OTLP나 메일 서버에서 뛰어난 성능을 느낄 수 있는 방법은 두 가지가 있습니다. "전통적인 방법"은 모두 병렬적으로 작동하는 수많은 15,000rpm SAS 디스크를 사용하는 것입니다. 좀 더 "반항적인 방법" 혹은 "구글스러운 방법"으로는 값싼 SATA 디스크를 엄청나게 많이 사용하는 것입니다. 두번째 전략은 비록 이것이 엑세스 타임에서는 손해를 보지만 SATA 디스크가 SAS 디스크보다 훨씬 값싸다는 사실에 근거합니다. 구글이 데스크탑 드라이브를 선택했을 때, 우리는 연구소에서 16개의 1TB enterprise WD 드라이브들이 사용된 것을 보았습니다. 이것들은 시장에서 구할 수 있는 7200rpm 디스크들 중에서 가장 빠른 것 중 하나이기 때문에, 수많은 SATA 디스크들의 묶음은 SAS 디스크들과 비교해보기에 충분할 것입니다.

 SSD는 위의 두 가지 전략 외에 또다른 전략을 제시합니다: 만약 당신에게 공간이 문제가 되지 않는다면, 당신은 저장 공간 대신 동일한 초당 랜덤 I/O 작업 성능을 얻기 위해 더 적은 공간과 더 많은 공간을 필요로 하는 드라이브를 선택할 수 있습니다. SSD는 읽기 성능에선 탁월하지만 상대적으로 쓰기 성능에선 덜 인상적입니다.

 우리-Anandtech를 말해요-가 지적했던 대로, 특히 수많은 요구가 병렬적으로 발생하는 서버 시장에서, 값싼 SSD 컨트롤러는 읽기 성능에 악영향을 끼칩니다. EMC는 이 문제를 STEC에서 생산되는 400G까지 저장할 수 있고 훌륭한 SRAM 캐쉬를 지닌 컨트롤러와 슈퍼 캐패시터를 지닌 하이엔드 Enterprise Flash Disk로 해결했습니다. 이 슈퍼 캐패시터는 컨트롤러가 상대적으로 큰 DRAM 캐쉬를 비울 수 있게 해 주고 갑작스런 전원 차단에서도 기록을 쓸 수 있게 해 줍니다.
 
 Intel은 미드 레인지 시장에서 자사의 컨트롤러에 16MB라는 적은 캐쉬를 주었습니다. 그러나 이 컨트롤러는 값싼 JMicron의 JMF602 컨트롤러 정도는 가볍게 부숴버릴 정도로 강력하고 뛰어납니다. 우리는 SLC 버전인 X25-E 32GB 제품을 살펴보겠습니다.

 Intel의 최신형 SSD는 0.075ms의 엑세스 타임과 0.15W의 전력 소모로 OLTP 데이터베이스 시장의 흐름을 바꿔놓을 수 있는 물건입니다. 그러나  SLC 드라이브는 최고의 SAS 드라이브들에 비교하면 몇 가지 단점을 가지고 있습니다.

 1. 듀얼 포트를 제공하지 않는다.
 2. 용량 대비 가격이 13배 가량 높다.

 아래의 요약된 표에서 비교해 보실 수 있습니다.
표 1.jpg

 만약 당신이 많은 용량을 필요로 한다면 SATA나 SAS 드라이버가 최고의 선택일 것입니다. 반대로 말하면, 만약 당신이 많은 초당 I/O 연산량을 원한다면 SLC 드라이브에 비해 얼마나 많은 SATA나 SAS 드라이버가 필요할 지 비교해 보는 것도 재미있을 것입니다. Intel의 X25-E의 가장 매력적인 점을 꼽으라면 극도로 짧은 랜덤 엑세스 시간과 0에 가까운 idle상태에서의 전력 소모와 full load 상태에서도 낮은 전력 소모, 그리고 높은 안전성 정도를 꼽을 수 있겠습니다.

표2.jpg

 안전성 테스트는 글의 의도와 어긋나는 부분이지만, 인텔의 주장이 절반 정도만이라도 사실이라면 X25-E SLC는 마그네틱 디스크를 가볍게 능가할 것입니다. 첫번째로 MTBF(Mean Time Between Failure-평균 무 고장 시간)입니다. X25-E는 2백만 시간인데 반해 시장의 최상위 SAS 디스크는 1.6백만 시간입니다. 인텔은 또한 66%의 읽기와 33%의 쓰기로 구성된 7000번의 8KB 초당 랜덤 엑세스를 보장하고, 이것은 5년 동안 계속될 것입니다. 즉, 하루당 2.9TB의 데이터를 쓸 수 있다는 것을 의미하며 1800일 동안 지속될 수 있습니다. 어떤 드라이브도 저정도의 데이터량을 저정도 기간 동안 유지할 수 없다는 것을 고려할 때 실로 경이적이라 할 수 있습니다.

 3장. 구성과 벤치마킹 준비.

 우선, 감사의 말씀을 올립니다. 여러분들의 도움으로 이 리뷰를 작성할 수 있었습니다.(나열은 생략하겠습니다.)

 S3S는 저희에게 대량의 저장 용량을 가진 서버로 사용될 수 있는 Supermicro SC846TQ-R900B를 제공해 주었습니다. 이 서버는 두개의 제온(하퍼타운) CPU와 그것을 감당하기 위한 총 900와트(1+1)의 파워, 그리고 3.5인치의 드라이브를 장착할 수 있으며 핫 스왑을 지원하는 24개의 베이를 가지고 있습니다.

 
서버-01.jpg

 우리는 컨트롤러의 영향을 줄이기 위해 두 개의 다른 컨트롤러를 사용했습니다. 8개의 SLC 카드를 Raid 0으로 묶어서 사용할 때, 레이드 카드를 통해 초당 250MB까지 전송할 수 있기 때문에 HBA(Host Bus Adapter)가 차이점을 만들 거라는 것은 분명합니다. 두개의 컨트롤러를 비교하겠습니다.

Adaptec 5805 SATA-II/SAS HBA
Firmware 5.2-0 (16501) 2009-02-18
1200MHz IOP348 (Dual-core)
512MB 533MHz/ECC (Write-Back)

ARECA 1680 SATA/SAS HBA
Firmware v1.46 2009-1-6
1200MHz IOP348 (Dual-core)
512MB 533MHz/ECC (Write-Back)


 두 컨트롤러는 동일한 I/O CPU와 동일한 캐쉬 메모리를 가지고 있습니다만, 보시면 아실 테지만 펌웨어의 차이가 영향을 미칠 것입니다. 아래에서 서버의 내부를 보실 수 있습니다. 특징으로는

  • 1x quad-core Harpertown E5420 2.5GHz and X5470 3.3GHz
  • 4x2GB 667MHz FB-DIMM (the photo shows it equipped with 8x2GB)
  • Supermicro X7DBN mainboard (Intel 5000P "Blackford" Chipset)
  • Windows 2003 SP2

inside.jpg
작은 2.5인치의 드라이브들이 3.5인치 베이에 장착되어 있습니다.
 inside-2.jpg

우리는 다음과 같은 디스크를 사용했습니다.
  • Intel SSD X25-E SLC SSDSA2SH032G1GN 32GB
  • WDC WD1000FYPS-01ZKB0 1TB (SATA)
  • Seagate Cheetah 15000RPM 300GB ST3300655SS (SAS)
4장. IOMeter/SQLIO 소프트웨어 설정.

 "현실에 더 가까이" OLTP 테스트를 시행하기 이전에, 데이터베이스의 구성요소로서의 디스크의 성능을 측정하기 위해 우리는 IOMeter와 SQLIO로 테스트했습니다. 우리는 레이드 컨트롤러에서 병목 현상이 일어나기를 바라지 않았으므로 컨트롤러를 사용하지 않고 Raid 0 상태에서 시행했습니다. 때때로 레이드 컨트롤러에서 병목현상이 일어나기 때문에 우리의 바램은 헛된 거라는 걸 보여주는 벤치마크도 있었습니다. 우리는 데이터베이스용 어플리케이션에서 순차/무작위 읽기/쓰기(sequential and random reads/writes)가 64KB에서 일어난다고 주로 가정했으므로(주: 어렵네요 ㅜㅡㅜ)축소된 64KB에서 수행하기로 정했습니다. 

 MS SQL server 2005를 위한 Microsoft의 I/O 테스트 툴인 SQLIO로 측정하면서, 우리는 SQL 서버 데이터베이스에 무작위 방식으로 접근할 때 8KB의 묶음으로 수행된다는 것을 알게 되었습니다. 순차적 접근(읽기부터)은 16KB에서부터 1024KB까지 다양하게 일어나기 때문에 우리는 적정한 타협점으로 64KB를 정했습니다. 모든 테스트는 각 두개의 드라이브에서(각 열마다 8개씩 총 16개가 있습니다) DQL(Disk Queue Length)하에서 수행되었습니다. DQL은 특정 디스크에서 진행 중인 요구 사항과 대기 중인 두드러지는 대기 사항의 수를 보여주며 또한 평균 2개 또는 그 이상의 시스템에서 해당 디스크가 병목 현상에 처해 있다는 것을 알려줍니다.

 우리는 리뷰를 신뢰적으로 만들기 위해 다음의 기준 하에 수행했습니다.

 ㆍRaid 0, Raid 10 또는 Raid 5
 ㆍ읽기를 우선하고 그 다음에 듣기를 수행했으며 레이드 컨트롤러를 사용.
 
ㆍNTFS에 클러스터는 64KB를 기준.
 
ㆍ랜덤 엑세스는 8KB, 순차적 엑세스는 64KB에서.

 이것은 우리가 어떻게 테스트했는가에 대해 좋은 인상을 줄 것입니다. 컨트롤러는 8개의 드라이브까지만을 지원했습니다. 우리는 "싼 SATA 디스클 사용하자"는 철학을 시험하고 싶었기 때문에 16개의 드라이브를 테스트하기 위해 두개의 컨트롤러와 MS의 소프트웨어 컨트롤러를 사용했습니다. 우리가 Intel의 IOP 348 controller 대신 강력한 2.5GHz의 쿼드코어 Xeon을 사용하기 때문에, 하드웨어 컨트롤러에 크게 밀리지 않는 모습을 보여주었습니다.

 그래프를 읽기 쉽게 하기 위해 SATA 디스크는 오렌지색, 
SAS 디스크는 녹색, SATA-SSD는 푸른색을 사용했습니다.

5장. I/O Meter 성능

 IOMeter는 Intel에 의해 개발되던 오픈 소스 툴로서, 상상 가능한 거의 모든 방법의 I/O 성능을 측정할 수 있습니다. 당신은 순차적 엑세스 또는 무작위 엑세스(또는 둘의 혼합), 읽기와 쓰기 작업(또는 둘의 혼합), KB에서 몇몇 MB까지에 이르는 묶음을  측정할 수 있습니다. 목표가 무엇이든 I/O Meter는 작업로를 형성하고 얼마나 I/O 시스템이 빠르게 동작하는지를 측정할 수 있습니다.

 우선, 우리는 마그네틱 디스크에서 상상 가능한 최선의 시나리오로서 20GB 파일에 대한 순차적 접근만을 테스트해 보았습니다. SLC SSD 드라이브가 32G밖에 안 되므로 우린 더 작은 파일을 사용하도록 강요받았습니다. 그러나 이 방법이 가장 많은 섹터를 지닌 바깥족 트랙을 사용하므로 가장 이상적인 조건입니다.
18576.jpg

 Intel SLC SSD는 약속했던 250MB/S보다 높은 266MB/S를 보여주었습니다. 사실, 단순한 순차 전송은 돈이 많이 드는 편은 아니고 하나의 SLC SSD가 두개의 SAS 디스크나 4개의 SATA 디스크와 동급이라는 점을 감안하면 매력적이라고 할 수 있습니다. SAS 디스크가 10배나 크고 SATA는 30배나 크기 때문에(주-용량 부분을 말하는 것 같습니다), 비디오 스트리밍을 SSD를 이용한 서버로 사용하는 것을 보긴 힘들 것입니다.

  Adaptec의 컨트롤러는 SLC SSD의 대역폭 측면에서 별반 이점을 드러내지 못하는데, 4개의 드라이브에서 8개의 드라이브로 전달하는 과정에서 근소한 이점밖에 존재하지 않는 걸 보면 알 수 있다. 8개의 SAS 디스크가 1GB/s 가까이 접근하는 데 아무런 무리가 없는 걸 보면 SATA 쪽에 관련된 문제인 것 같습니다. 이것은 레이드 컨트롤러의 첫 병목 현상입니다. 그러나 이것은 서버 환경에서는 아주 드문 일이기 때문에 Raid 0으로 최고 속도를 이끌어내지 못한다고 비난하기는 힘듭니다. 사람들은 보통 8개나 되는 디스크를 불안정한 Raid 0으로 묶지 않고, 이것은 디스크가 250MB/s 혹은 그 이상을 감당할 수 있을 때의 경우이기 때문입니다.

 16개의 SATA 디스크는 두개의 Adaptec 컨트롤러와 함께 가장 높은 전송률을 자랑했습니다. 레이드 컨트롤러의 영향을 좀 더 알아보기 위해 우리는 4개의 SLC SSD에는 Adaptec의 컨트롤러를 사용하고 나머지 4개에는 다른 회사의 컨트롤러를 사용했습니다. 첫번째는 그 사진이과 두번째는 그 결과입니다.
TwoAdaptec.jpg
18585.jpg

결과는 정말 놀라웠습니다. 성능이 하나의 컨트롤러를 사용할 때보다 60% 가까이 향상된 것입니다. 우리는 레이드된 시스템이 1.2GB/s까지 전달할 수 있다는 결론을 내렸습니다.

6장. I/O Meter 성능(Con't d)(주: Con't d가 뭐지요..?)

 다음으로 우리는 순차적 읽기/쓰기 성능에 대해 평가하겠습니다. 몇몇 프로세서들은(Netapp라던가. http://en.wikipedia.org/wiki/NetApp) 무작위 쓰기라도 순차적으로 쓰는 경우가 있기 때문에 뒤섞인 상황에서 디스크가 어떻게 대처하는지 보는 것도 재밌을 것입니다.
18574.jpg

 4개의 SAS 디스크는 8개의 SATA 디스크와 비슷한 속도로 읽을 수 있지만, 읽기와 쓰기를 섞어버리면 SAS 디스크는 SATA 디스크보다 근소한 차이지만 느려지는 것을 확인할 수 있습니다. 이것은 별로 놀랍지 않은데 왜냐하면 SAS 디스크와 SATA 디스크는 모두 4장의 플래터를 사용하기 때문입니다. 즉, SAS디스크가 더 높은 회전수를 지님에도 불구하고 WD 1TB가 더 높은 데이터 밀도를 지닌다는 것을 의미합니다. 접근은 순차적이기 때문에 면적 밀도가 승리의 요인입니다.

 우리가 명시했던 대로, SSD는 메일과 OLTP 서버에 매력적입니다. 실제 테스트는 대부분 무작위 읽기와 쓰기로 구성됩니다. 특히 읽기가 쓰기보다 두배 가량 많기 때문에 우리는 테스트를 66%의 무작위 읽기와 33%의 무작위 쓰기로 구성했는데 이것은 OLTP 데이터베이스의 성능과 유사한 조건을 만들기 위해서입니다.
18575.jpg
 
Intel SSD의 우월성은 그저 놀라울 따름입니다. 심지어 가장 빠른 8개의 SAS 드라이브도 한개의 SSD조차(!) 따라잡지 못하고 있습니다. WD의 높은 탐색 시간도 문제입니다. 16개의 드라이브가 4개의 SAS 드라이브보다도 느립니다. WD의 8개의 드라이브의 성능은 얼마나 많은 SATA 드라이브가 필요할지 상상할 수 있게 해 줍니다. 8개의 SAS 드라이브를 따라잡기 위해서는 26개에서 30개의 SATA 드라이브가 필요하고 하나의 SLC SSD를 이기기 위해선 무려 40개의 SATA 드라이브가 필요할 것입니다. 당신의 어플리케이션이 더 많은 무작위 읽기/쓰기를 요구할수록 "많은 SATA 디스크를 구매한다"는 전략은 나빠집니다.
================================
 여기까지, 뭔가 이상한 점을 느끼셨나요? 좋군요. 글에 주목하고 있다는 증거입니다. Raid 5 테스트에서 그것을 설명할 거에요. 모르겠다구요?
커피 한잔 마시고 다시 한번 보고 오세요.
================================
7장. SQLIO 성능.

 SQLIO는 Microsoft에서 제공되는 특정 시스템의 I/O 가용량을 측정하는 도구입니다. 우리는 MS SQL 2000/2005가 어떻게 디스크에 엑세스하는지 시뮬레이팅해야 합니다. 아래의 테스트는 Raid 0에서 진행되었습니다. 우리는 1,000초까지 테스트를 진행해 보았지만 우리의 기준이었던 120초까지의 결과와 별반 차이가 없었습니다. 그러므로 모든 테스트는 120초까지의 결과입니다.
18581.jpg

IOMeter와 비교해서 딱히 놀랍거나 한 점은 없습니다.

18582.jpg

 Intel은 순차 쓰기에서의 전송률을 170MB/s라고 약속했고, 우리의 측정 결과는 SSD가 그 이상도 전달할 수 있다는 것을 보여주었습니다. 그리고 하나의 컨트롤러에 8개의 드라이브를 사용할 때에 있어서 한계점을 드러냈습니다. 무작위 읽기를 보시죠.

18583.jpg

우리의 IOMeter 테스트가 무작위 읽기와 쓰기의 혼합에 있어서 8개의 SAS 디스크로 하나의 SSD에 근접할 수 있다는 것을 보여주었고, 이것은 무작위 읽기에서만의 현상이 아닙니다. 최선의 선택은 SLC SSD라는 것이 분명해졌고 이것은 그 어떤 마그네틱 디스크와의 비교에서도 승리합니다.

18584.jpg

 무작위 쓰기는 무작위 읽기보다 좀 느립니다. 그리고 이 부분이 SSD의 단점이라고 지목되었던 걸 생각하면 그리 놀라운 결과는 아닙니다.

 8장. Raid 5에서의 실제.

 Raid 0은 디스크를 추가함으로써 성능이 얼마나 늘어나는지를 저울질해 볼 수 있는 좋은 방법입니다. 그러나 중요한 어플리케이션을 쓰면서 Raid 0을 쓰는 사람은 거의 없습니다. 만약 우리가 Raid 5를 사용한다면 어떤 결과가 나올까요?

18630.jpg

우리는 Raid 0에서 보던 것과 비슷한 결과를 볼 수 있습니다. SAS 프로토콜은 SATA 방식보다 더 효율적입니다. 4개의 SLC SSD는 Adaptec HBA가 SATA에서 이끌어낼 수 있는 대역폭 한계에 가까운 대역폭을 자랑합니다. 4개의 SSD를 더하면 700MB/s가 병목 현상으로 희생될 것입니다.
4개일 때의 결과보다 두배 이상 빠르다는 걸 생각해 보면 8개의 SSD를 사용할 때의 결과는 이상합니다. 4개의 드라이브를 사용할 때는 컨트롤러가 3개의 덩어리의 파일과 1개의 미완성 덩어리를 완성합니다. 8개의 드라이브를 사용할 때는 7개의 덩어리의 파일을 완성하고 한개의 덩어리만 남겨두었습니다. 그래서 우리는 7과 2/3개까지의 덩어리의 파일을 완성할 거고 이것은 2배로 하는 것보다 뛰어다는 정책에 따른 것입니다.
18628.jpg

 읽기와 쓰기를 뒤섞었더니 우리는 8개의 SLC SSD가 4개의 SSD보다 조금이지만 느려지는 현상을 발견했습니다. 우리는 Adaptec이 펌웨어를 만들었을 시점 외에는 딱히 이유는 모르겠습니다. 그래서 우리는 똑같은 스펙에 다른 펌웨어를 가진 Areca 1680 컨트롤러로 테스트해 보기로 결정했습니다.

Arec1680vsAdaptec_Seqrw.jpg
Areca 1680 컨트롤러는 4개의 SLC SSD를 Raid 0에서는 20% 가량 느렸지만, 8개를 묶을 때는 4개를 묶을 때와 비교해 78%의 성능 향상이 있었습니다. 반면에 Adaptec의 컨트롤러는 4개를 Raid 0으로 묶을 때와 비교해 8개를 묶었을 때에는 19%의 성능밖에 향상되지 않았습니다. Raid 5에서는 그 변화가 더욱 뚜렷합니다. 여분의 4개의 카드를 같이 묶음으로서(주:4개에서 8개로 만드는 것을 의미합니다.) Adaptec 컨트롤러에서는 오히려 성능 하락이 발생합니다. 반면에 Areca의 컨트롤러에서는 동일한 조건에서 47%의 성능 향상이 있습니다. 그러므로 우리는 Adaptec의 펌웨어에 문제가 있다는 결론을 내렸습니다. 우리는 1.44(08년 8월)와 1.46(09년 2월) 버전을 사용해 보았고 최신 펌웨어에서 약간의 성능 향상이 있었지만 우리는 동일한 결론을 도출해냈습니다.

9장. 더 많은 Raid 5

 이것이 OLTP 데이터베이스와 유사한 방식을 지니기 때문에 66%의 읽기와 33%의 쓰기는 여전히 흥미로운 방식입니다.
18629.jpg

 또다시, 우리는 괴상한 결과를 얻었고 이것은 이전 벤치마크와의 차이에서 온다고 생각합니다. 8개의 드라이브에서 각각의 쓰기 때마다 패리티 덩어리를 계산하기 위해 7번의 추가적인 읽기를 수행해야 하기 때문에 4개의 드라이브 때보다 성능 하락이 있지 않나 싶습니다.

 수정) 우리는 잘못된 가정을 하고 있었습니다. 한 덩어리의 패리티 드라이브를 읽는 데 있어서 하나의 드라이브로 충분하지 7개의 덩어리를 읽어야 할 필요는 없었습니다. 8개의 Raid 5로 묶인 드라이브에 있어서 2번의 읽기는 2번의 쓰기만으로 충분했던 것입니다. 지적해준 Tobias에게 감사드립니다. 하지만 우리는 4개의 드라이브에서 8개의 드라이브 사이의 성능 하락에 대한 원인을 확신하지는 못했습니다.

 다시 한번 우리는 Areca 1680을 가지고 더 많은 것을 알아보기 위해 테스트했습니다.
Arec1680vsAdaptec_randrw.jpg
 Adaptec 컨트롤러가 Raid 0에서 약간의 성능 하락을 보였지만, 두개의 컨트롤러 모두 4개를 Raid 5로 묶을 때보다 현격한 성능 차이를 보이지는 못했습니다. 이것은 우리의 의심을 증명합니다. 즉, SLC SSD가 엄청난 속도의 읽기와 쓰기를 보장하기 때문에 레이드 컨트롤러에서 매번의 쓰기 때마다 밀려들어오는 대량의 읽기 정보에 마비되어 버리는 것 같습니다. 4개의 드라이브 때보다 8개의 드라이브일 때의 읽어야 하는 양이 두배 이상이므로 성능이 하락하는 것이지요. 이것은 훨씬 느린 속도로 읽고 훨씬 느린 속도의 성능을 자랑하는 마그네틱 디스크에선 문제가 되지 않습니다. 레이드 컨트롤러가 SSD의 성능을 붙잡고 있는 듯 한데, 아직은 추측에 가깝습니다. 우리는 4개의 드라이브에 컨트롤러로 묶고 3.33GHz의 제온을 레이드 컨트롤러로 만들어 보았습니다.(즉, Windows 2003에서 소프트웨어 레이드 컨트롤러를 사용한다는 말입니다.)

표 3.jpg

 Xeon을 저장장치용 프로세서로 사용함에 따라, 병목 현상은 없어졌습니다. 순차적 읽기 성능은 4개의 디스크를 사용할 때보다 두배 가까이 올랐고, 무작위 읽기/쓰기는 부정적인 모습을 적어도 보이지는 않습니다.

 우리는 Adaptec을 비난해야 할까요? 아니에요. 대역폭이나 그 속도에 있어서 지원 가능한 최대 숫자인 8개의 마그네틱 드라이브를 사용할 때 이것은 훌륭합니다. 당신은 최신 저장장치용 프로세서로 구형 디스크를 Raid 6으로 묶었을 때 아무런 문제가 없었다는 기사를 기억해야 합니다. 그러나, X25-E의 엄청난 성능은 이번에도 병목 현상을 불러오고야 말았습니다.

10장. SQL 서버와 Raid 5.

 IOMeter에서의 Raid 5 테스트는 흥미로웠고 SQLIO에서의 테스트는 독특한 모습을 보여주었습니다. 우선, 순차적 읽기와 쓰기를 테스트해 보겠습니다.
18631.jpg18632.jpg

별로 놀랍지는 않지만 두 테스트는 SSD가 SATA 인터페이스와 컨트롤러에 발목이 잡혀 있다는 것을 보여줍니다.

18633.jpg

무작위 읽기는 예상했던 수치가 나왔습니다. SLC SSD는 마그네틱 디스크를 몰살시킵니다.

18634.jpg

Raid 5에서의 무작위 쓰기는 저장장치용 프로세서가 SLC SSD가 필요로 하는 만큼의 데이터를 전달해 주지 못하므로 성능향상을 위해 SSD의 갯수를 늘리는 것은 의미없다는 우리의 이론을 증명해 주었습니다.

11장. 실제 상황에서의 테스트.

 SQLIO와 IOMeter의 흥미로운 점은 이 테스트가 오로지 저장 장치로서의 성능을 테스트했다는 것입니다. 실제로는 데이터베이스나 메일, 또는 파일 서버로서의 성능을 살펴야 합니다. 궁금한 것은 I/O 성능이 초당 메일이나 상호작용의 성능으로 얼마만큼이나 변환되느냐입니다. 우리는 64bit의 MySQL 5.1.23과 수세 리눅스 SLES 10 sp2의 SysBench로 확인해 보기로 했습니다.

 우리는 23GB의 데이터베이스를 사용했고 my.cnf 설정 파일을 조심스럽게 활용했습니다. 우리의 목표는 메인 메모리에서 맞지 않는 데이터(즉, 캐쉬에서) 의 성능에 대한 결과를 얻는 거고 특히 위의 설정이 SLC SSD에서 어떻게 반응할지에 대한 것도 포함됩니다. 데이터베이스 내부의 버퍼 메모리는 1GB로 정해졌습니다. 일반적으로 서버에서는 4G에서 32G(혹은 그 이상도 사용합니다) 정도를 사용하고 MySQL이 램의 60% 정도를 버퍼로써 사용할 것을 권장하는 것에 비하면 적은 양입니다. 우리의 테스트 장치에는 8G의 램이 있기 때문에 6G 혹은 그 이상을 사용해야 옳지만 우리는 메모리 캐쉬의 양만 일치하는 큰 데이터베이스와 버퍼 용량의 20배 정도 되는 데이터베이스를 비교해 보고 싶었습니다. 32GB의 SLC SSD에 있어서 6.5G를 버퍼와 130GB의 넓은 데이터베이스를 사용하는 것은 선택 사항이 아니었습니다. 그러므로 우리의 버퍼 용량에는 제한이 있을 수밖에 없습니다.

 우리는 23GB의 데이터베이스에 SysBench가 가능한 한 모든 것을 채워 놓도록 허락했습니다. (자료가 하나 더 있어야 하는데 안 나와서 뺄게요)

 교환이 끝나고 나서, 디스크로의 급격한 쏠림에 의한 "pwrite"가 시행되었습니다. 그렇기 때문에 실제 교환 시간은 레이턴시의 영향을 받았습니다. 이것은 SSD가 자신의 가치를 보여주는 매우 흥미로운 경우가 될 것입니다. 우리는 다음 4가지 구성에 따라 실시했습니다.

 ㆍ"Classical SAS"-우리는 4개의 SAS 디스크를 데이터용으로, 2개를 로그용으로 사용했습니다.
 ㆍ"SAS data with SSD logging"-우리는 빠른 로그용 디스크를 사용하는 것만으로 데이터베이스의 속도를 끌어올릴 수 있을지도 모릅니다. 만약
                                             이 설정이 "Classical SAS"보다 빠르다면, 데이터베이스 운영자들은 SSD에 투자하는 것 만으로 OLTP 어플리-
                                             -케이션의 성능을 끌어올릴 수 있을 것입니다.
 ㆍ"SSD 6+2"-SAS를 SSD로 대체했습니다. 6개의 SSD는 데이터용으로, 2개의 SSD는 로그용으로 사용합니다.
 ㆍ"SSD data with SAS logging"-데이터 디스크를 SSD로 대체하고 로깅 자체는 계속 SAS를 사용합니다.
                                           (주: 기본은 'Classical SAS"인 것 같습니다.)로깅이 순차적이란 걸 생각하면 이것은 합리적인 듯 합니다.

  무작위 쓰기에 대해서 우리는 많은 방법을 가지고 있지만 Raid 5 또는 Raid 10이 합리적인 방법이라고 생각하였습니다. 우리는 6개의 X25-E에서 SysBench를 실시하였습니다. 병목 현상을 방지하기 위하여 Raid 0으로 묶은 두개의 SSD에 로깅하였습니다.

 18636.jpg
 Raid 10이 Raid 5보다 23% 정도 빨랐기 때문에, 우리는 데이터베이스를 Raid 10 LUN(Local Unit Number, http://en.wikipedia.org/wiki/Logical_Unit_Number)로 지정했습니다.
18635.jpg

교환되는 로그는 동기적 방식 하에 순차적으로 쓰여집니다. SAS가 순차적 데이터 전송에는 강한 면모를 보이기 때문에 로깅 디스크를 SAS 대신 SSD로 대체한다 하더라도 큰 향상을 보이지 않는 것은 그리 놀랍지 않습니다. 그러나 데이터 디스크를 SSD로 택한 것은 놀라운 전략이라고 보여집니다. 하나의 X25-E는 8개의 15,000rpm의 SAS 드라이브보다도 빠릅니다(!!!). 이것은 만약 당신이 용량을 고려하지 않는다면 한 개의 SSD로 13개의 SAS를 대체할 수 있다는 뜻입니다. 뛰어난 로깅 성능을 유지하면서 값싼 방법을 원한다면 SAS가 해답일 것입니다.

 12장. 에너지 소모.

 성능 테스트에서는 120W의 TDP에 3.3GHz의 Core2 X5470을 사용했기 때문에, 우리는 약간 편집증 환자스러워졌고 그만큼의 처리 능력을 요구하게 되었습니다. 단순히 저장에 관한 문제라면 CPU 로드는 소프트웨어 레이드의 경우에 절대 15%를 넘지 않습니다. 오로지 SysBench만이(주: 여태까지 실시한 테스트 중에서) CPU 로드를 80%까지 끌어 올릴 수 있었지만 우리의 SC-836TQ의 전력 소모량을 측정하기 위해선 SysBench는 적절하지 못합니다. 대부분의 경우 서버는 데이터베이스를 운영하고 상호교환을 행합니다. 서버에 부착된 저장 장치는 오로지 I/O 프로세싱만을 수행합니다. 그러므로 우리는 더 예민한 80W의 TDP를 지닌 2.5GHz의 E5420과 IOMeter를 이용하였습니다. EMC와 같은 고성능을 요구하는 경우에는 Xeon을 사용하였습니다.

 SC-836TQ의 경우 파워로 Ablecom PWS-902-1R 900W 75A,CPU로 Xeon E5420 "Harpertown", 4x2GB 667MHz FB-DIMM의 메모리와 레이드 컨트롤러로 Adaptec 5085 RAID controller를 사용합니다. 풀 로드란 IOMeter 무작위 읽기/쓰기 테스트를 시행하는 것을 의미하고, SAS와 SSD 모두 순차적 접근이나 무작위 접근에 따른 전력 소모의 차는 적었습니다.

 표 4.jpg

 SLC X25-E가 아이들 상태에서는 0에 가까운(0.06W) 전력 소비를 하며, 하드웨어 레이드 컨트롤러에 의해 묶여 있기 때문에 저런 소모량이 나옵니다. 컨트롤러는 각 드라이브를 연결해야 하기 때문에 약간의 전력을 소모합니다. 8개의 SLC가 8개의 SAS보다 129W나 적은 전력을 소모하면서 3배에서 13배에 이르는 OLTP 성능을 낸다는 것은 저장 분야의 혁명이라 할 수 있습니다.

 간단한 실험을 해 보도록 하죠. 당신이 성능이 제한된 100GB의 데이터베이스를 가지고 있다고 해 봅시다. 우리의 SysBench 결과는 8개의 X25-E가 10개의 15,000rpm의 SAS와 비교해서 3배에서 13배에 이르는 성능임을 보여주었습니다. SSD와 동일한 성능을 내기 위해선 최소 30개의  SAS 디스크가 필요합니다. 30개를 설치할 수 있는 공간 마련에 드는 비용은 무시하고,  8개의 SSD의 설치 비용 대 30개의 SAS 설치 비용만 비교해 보도록 하죠.

 미국의 에너지 담당 부서에서는 자국 내에서 소모되는 전력량과 그 가격을 표시합니다. 실제 소모량은 더 크지만, 그래도 실제값과 제일 비슷한 값이고 우리는 이것을 기준으로 삼도록 하겠습니다. 디스크에서 발생하는 열을 제거하기 위해 50% 가량의 전력량을 추가로 소모한다는 사실을 우선 짚고 가겠습니다. 우리는 풀로드 상태에서 8시간, idle 상태에서 16시간을 기준으로 삼겠습니다.
표 5.jpg

 만약 당신이 Raid 10으로 묶인 6개의 드라이브를 사용한다면(2개는 로그용으로), 당신은 X25-E 64GB 제품을 필요로 하게 됩니다. 왜 이 계산에서 그것들을 사용하는지 설명하겠습니다. 사실, 우리의 계산은 SAS에 불리합니다. SLC SSD는 idle 상태에서도 SAS보다 뛰어난 성능을 자랑하기 때문에 30개의 SAS 드라이브로도 8개의 SSD에 비교될 수는 없습니다. 이러한 편파적이라고밖에 할 수 없는 결과 앞에서, 답은 간단합니다. 만약 당신이 공간이 부족한 게 아니라 성능이 부족하다면, 그것들이 더 낮은 소유비용이 들기 때문에 많은 돈을 아낄 수 있습니다.

최종장. 결론.

 하이엔드급 시스템의 소유자와 매우 중요한 어플리케이션의 운영자에게 있어서 X 25-E Extreme SLC SSD는 계륵과 같은 존재입니다. 듀얼 포트를 지원하지도 않고, 전원이 끊기는 비상시에 컨트롤러가 캐쉬 메모리의 데이터를 저장할 수 있게 하는 강력한 수용 장소도 존재하지 않습니다. 이런 사람들에게는 EMC의 EFM(Enterprise Flash Memory)가 답이 되겠지만, 가격이 X25-E SLC SSD의 열배가 넘습니다.

 이런 사람들을 제외하고 시장의 90%의 사람들에게는, X25-E는 경탄하기만 할 대상은 아닙니다. 기존의 SAS 드라이브와 비교해서 OLTP 성능은 3배에서 13배나 되고 전력 소모량은 1/10보다 적습니다. 당신의 데이터베이스가 정말로 넓다면 몰라도 OLTP 성능을 위해 SAS나 FC 드라이브를 사는 것은 정말로 멍청한 짓입니다. 당신이 많은 드라이브를 가지고 있지만 그 대부분이 비어 있다면, SSD가 당신께 해답을 제공해 줄 것입니다.

 하지만 이 너무나 빠른 드라이브 때문에 병목현상이 일어날 수도 있다는 것은 주의하셔야 합니다. 현재의 저장 장치에 쓰이는 프로세서로는 4개에서 8개의 드라이브를 감당해 낼 능력이 없습니다. 우리는 극한의 상황에서 성능 저하가 일어난 경우를 알고 있는데, Raid 5에서 100% 무작위 쓰기를 실행한 것을 예르 들 수 있겠습니다만, 당신이 이런 일을 실제로 경험할 일은 없겠습니다. 만약 당신이 16개나 그 이상의 SLC SSD를 Adaptec의 51645나 특히 52445를 달았음에도 성능이 안 좋을 수도 있습니다. 그것은 이 컨트롤러들이 최대 24개까지의 드라이브를 지원하지만 그 프로세서는
Adaptec 5805 (1.2GHz의 IOP348)와 전부 똑같기 때문입니다. 우리는 최대 8개의 드라이브마다 IOP348을 장착하는 것을 추천하며, 특히 당신이 Raid 5나 Raid 6을 사용하려 한다면 특히 그렇습니다. Intel과 다른 회사들은 빨리 강력한 저장 장치용 프로세서를 출시해야 할 것인데, 빠른 SLC SSD에게 있어서 현재의 프로세서는 너무 괴롭기 때문입니다.

 우리의 시험은 "싸지만 많은 수의 SATA 드라이브" 전략이 주로 순차적 접근을 하는 어플리케이션에서만 효율적이라는 것 또한 검증해냈습니다. 무작위 접근의 경우 성능 향상을 위해서는 2~3배의 드라이브가 필요로 하고 그 갯수에 따른 성능 향상 또한 한계가 있습니다. 마지막으로, 최고의 성능을 누리고 싶다면 Raid 10에서 SLC SSD, 특히 X25-E를 사용하십시오.

참조
[1]Dave Fellinger, "Architecting Storage for Petascale clusters",
http://www.ccs.ornl.gov/workshops/FallCreek07/presentations/fellinger.pdf

[2] US Department of Energy. Average retail price of electricity to ultimate customers by end-use sector, by state. http://www.eia.doe.gov/cneaf/electricity/epm/table5_6_a.html


기글하드웨어(http://gigglehd.com/zbxe)에 올라온 모든 뉴스와 정보 글은 다른 곳으로 퍼가실 때 작성자의 허락을 받아야 합니다. 번역한 뉴스와 정보 글을 작성자 동의 없이 무단 전재와 무단 수정하는 행위를 금지합니다.