Raid 10°ú Raid 1ÀÇ ¼º´É

   Á¶È¸ 31664   Ãßõ 0    

Raid 10과 Raid 1. 어느것이 더 빠를까요?
답은 같다 입니다.
http://www.kendalvandyke.com/2009/02/disk-performance-hands-on-part-6-raid.html

그런데, 글쓴이는 "same filegroup"일때는 여러개의 Raid 1을 만드는 것보다 하나의 Raid 10을 더 추천합니다.
이유는 결론에 있습니다.

다른 파일그룹일경우에는???
여러개의 Raid 1 그룹이 더 좋습니다. 최근 현업서버에서 작업한 결과 입니다.
1U 서버에 장착된 4개의 디스크를 Raid 10으로 한것과, 2개 2개 묶어서 2개의 Raid 1으로 한 것.
2개의 Raid 1이 현저하게 빠른 성능과 iostat의 Disk IO의 합이 낮게 나오고 있습니다.

아래의 Plan 1과 2는 서비스하고 있는 웹사이트의 상황에 따라 다르겠지만,
개인적으로는 2를 더 선호 합니다. MySQL의 Data와 Log가 서로 다른 Raid 1에 있거든요.

1U - 4디스크 웹서버 (Plan 1)
Raid 1 : OS + MySQL (log) + Web Page
Raid 1 : MySQL (data)

1U - 4디스크 웹서버 (Plan 2)
Raid 1 : OS + MySQL (data+log)
Raid 1 : Web Page

Conclusion 
The point of these comparisons is to show that, in the most simplistic way, if you are already using multiple RAID 1 drives which hold data files in the same filegroup you’re not as bad off performance-wise as you may think. That said, if you’re setting up a server from scratch I’d recommend RAID 10 over multiple RAID 1’s for two reasons:

  1. Today’s hardware based RAID controllers are pretty sophisticated and designed for reading from and writing data to disks in the most efficient way possible. By comparison, SQL Server’s proportional fill algorithm but doesn’t understand much about the physical disks on which files reside, nor does SQL Server employ the hardware based caching techniques that are built into controllers (and which were not factored into any of these tests).
  2. Towards the end of Tony Rogerson’s post he mentions that SQL will only round robin writes if there is equal free space in each file in the filegroup. As soon as the free space is different you’ll have one set of disks taking more IO than the other. That won’t happen with a single data file on a RAID 10 disk.


참조글 입니다.
Raid 10은 믿음일 뿐이고 실제로는 Raid 5가 월등하다는 의견 입니다.
진실은 어디에 있을까요?
- to be continue -


Á¦¸ñPage 15/55
2014-05   4937100   Á¤ÀºÁØ1
2015-12   1474072   ¹é¸Þ°¡
2015-07   32163   hjkhk
2023-06   31821   ¶¥ÀïÀÌ
2013-07   31807   ȸ¿øK
2023-03   31680   chamgileam
2013-04   31665   ȸ¿øK
2013-02   31583   ¹Ú¹®Çü
2015-03   31535   ½ÅÀº¿Ö
2015-01   31338   Aniny
2022-12   31297   JOKO
2014-05   31186   ¸¶½Ã½º
2015-01   31133   ¾Æµå·¹³¯¸°
2015-03   31049   ³ªÀºÀÌ
2015-08   30607   DAQ¸Þ´Ï¾Æ
2013-06   30532   ÀÓ°û¼®
2013-04   30454   ȸ¿øK
2014-09   30424   ÃÖâÇö
2013-03   30409   ȸ¿øK
2014-07   30319   ÁÖ¿ø¾Æºü
2014-12   30317   ¸®º£ÀÌÆ®
2013-03   29795   ȸ¿øK