RAID 0+1 和 RAID 1+0有什么区别呢？

RAID 0+1 和 RAID 1+0有什么区别呢？

RAID 0+1是先让磁盘组内的成员组成RAID 0条带化，然后磁盘组之间为RAID 1镜像关系。

RAID 1+0是先让磁盘组内的成员组成RAID 1互为镜像，然后磁盘组之间RAID 0条带化。

 

RAID 0+1

 

RAID 1+0

 

 

 

 

 

 

 

 

 

 

 

除了构成先后的差别外，主要的区别还表现在容错性上。

RAID 0+1损坏一块磁盘之后，所在的RAID 0组即认为损坏，RAID 0+1 实际上已经退化为一个RAID 0 的结构，此时，上面那组RAID 0随便坏一块，整个RAID就崩溃了。

 

RAID 0+1 故障演示

相对来说，RAID 1+0 就不会有这个问题，只要同一个RAID 1组内硬盘不全损坏，整个RAID就不会有问题，在图中可以认为，只要右上角的那块磁盘不坏，整个RAID就不会崩溃。

 

RAID 1+0 故障演示

 

 

 

 

 

 

 

 

 

 

 

 

 

所以使用RAID 1+0比RAID 0+1具有更好的容错性，

 

 

RAID10 is "striped mirrors", e.g. (1=2)+(3=4).

 

and that

 

RAID0+1 is "mirrored stripes", e.g. (1+2)=(3+4).

 

 

磁盘 RAID10 / RAID5 配置下的IOPS对比

 

磁盘的IOPS对比

假定一个case，业务的iops是10000，读cache命中率是30%，读iops为60%，写iops为40%，磁盘个数为120，那么分别计算在raid5与raid10的情况下，每个磁盘的iops为多少。

raid5:

单块盘的iops = (10000*(1-0.3)*0.6 + 4 * (10000*0.4))/120

= (4200 + 16000)/120

= 168

这里的10000*(1-0.3)*0.6表示是读的iops，比例是0.6，除掉cache命中，实际只有4200个iops。

4 * (10000*0.4) 表示写的iops，因为每一个写，在raid5中，实际发生了4个io，所以写的iops为16000个

为了考虑raid5在写操作的时候，那2个读操作也可能发生命中，所以更精确的计算为：

单块盘的iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4)*(1-0.3) + 2 * (10000*0.4))/120

= (4200 + 5600 + 8000)/120

= 148

计算出来单个盘的iops为148个，基本达到磁盘极限

raid10

单块盘的iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4))/120

= (4200 + 8000)/120

= 102

可以看到，因为raid10对于一个写操作，只发生2次io，所以，同样的压力，同样的磁盘，每个盘的iops只有102个，还远远低于磁盘的极限iops。

 

 

RAID5与RAID10详细对比

RAID5与RAID10都是当前主流的磁盘阵列方案那么他们有什么不同呢？这里，我就这两种RAID的内部运行原理来分析一下，我们在什么情况下应当适合选哪一种RAID方式。

为了方便对比，这里拿同样多驱动器的磁盘来做对比，RAID5选择3D+1P的RAID方案，RAID10选择2D+2D的RAID方案，分别如图：

 

RAID5选择3D+1P的RAID方案，RAID10选择2D+2D的RAID方案

那么，我们分析如下三个过程：读，连续写，随机写，但是，在介绍这三个过程之前，我需要介绍一个特别重要的概念：cache。

cache技术最近几年，在磁盘存储技术上，发展的非常迅速，作为高端存储，cache已经是整个存储的核心所在，就是中低端存储，也有很大的cache存在，包括最简单的RAID卡，一般都包含有几十，甚至几百兆的RAID cache。

cache的主要作用是什么呢?体现在读与写两个不同的方面，如果作为写，一般存储阵列只要求写到cache就算完成了写操作，所以，阵列的写是非常快速的，在写cache的数据积累到一定程度，阵列才把数据刷到磁盘，可以实现批量的写入，至于cache数据的保护，一般都依赖于镜相与电池(或者是UPS)。

cache的读一样不可忽视，因为如果读能在cache中命中的话，将减少磁盘的寻道，因为磁盘从寻道开始到找到数据，一般都在6ms以上，而这个时间，对于那些密集型io的应用可能不是太理想。但是，如果cache能命中，一般响应时间则可以在1ms以内。

不要迷信存储厂商的iops(每秒的io数)数据，他们可能全部在cache命中的基础上做到的，但是实际上，你的cache命中率可能只有10%。

介绍完cache，我们就可以解释RAID5与RAID10在不同的模式下，工作效率问题了，那么我们来分别分析以上三个问题。

1、读操作

因为RAID5与RAID10的磁盘都可以提供服务，所以，在读上面他们基本是没有差别的，除非是读的数据能影响cache命中率，导致命中率不一样。

 

读操作

2、连续写

连续写的过程，一般表示写入连续的大批量的数据，如媒体数据流，很大的文件等等，这个写操作过程，如果有写cache存在，并且算法没有问题的话，RAID5比RAID10甚至会更好一些(这里要假定存储有一定大小足够的写cache，而且计算校验的cpu不会出现瓶颈)。因为这个时候的校验是在cache中完成，如4块盘的RAID5，可以先在内存中计算好校验，同时写入3个数据+1个校验。而RAID10只能同时写入2个数据+2个镜相。

 

连续写

如，4块盘的RAID5可以在同时间写入1、2、3到cache，并且在cache计算好校验之后，我这里假定是6(实际的校验计算并不是这样的，我这里仅仅是假设)，同时把三个数据写到磁盘。而4块盘的RAID10不管cache是否存在，写的时候，都是同时写2个数据与2个镜相。

但是，我前面也说过了，写cache是可以缓存写操作的，等到一定时期再写到磁盘，但是，写操作不比读操作，这个写是迟早也要发生的，也就是说，最后落到磁盘上的写还是避免不了的，不过，如果不是连续性的强连续写，只要不达到磁盘的写极限，差别都不是太大。

3、离散写

这里可能是最难理解，但是，也是最重要的部分，数据库，如oracle 数据库大部分操作就是离散写，如每次写一个数据块的数据，如8K;联机日志虽然看起来是连续写，但是因为每次写的量不多，不保证能添满RAID5的一个条带(保证每张盘都能写入)，所以很多时候也是离散写入。

 

离散写

我们再接上图，假定要把一个数字2变成数字4，那么对于RAID5，实际发生了4次io，先读出2与校验6，可能发生读命中然后在cache中计算新的校验写入新的数字4与新的校验8

对于RAID10，我们可以看到，同样的单个操作，最终RAID10只需要2个io，而RAID5需要4个io。

但是，这里我忽略了RAID5在那两个读操作的时候，还可能会发生读命中操作，也就是说，如果需要读取的数据已经在cache中，可能是不需要4个io的，也证明了cache对RAID5 的重要性，不仅仅是计算校验需要，而且对性能的提升由为重要。曾经测试过，在RAID5的阵列中，如果关闭写cache，RAID5的性能将差很多倍。

这里，并不是说cache对RAID10就不重要了，因为写缓冲，读命中等，都是提高速度的关键所在，不过的是，RAID10对cache的依赖性没有RAID5那么明显而已。

到这里，大家应当也大致明白了RAID5与RAID10的原理与差别了，一般来说，象小io的数据库类型操作，建议采用RAID10，而大型文件存储，数据仓库，则从空间利用的角度，可以采用RAID5。

 

如果是以大量的事务性的操作，在典型的OLTP 环境里，我们考虑RAID10更好些，因为OLTP 环境，IO 性能上我们考虑的主要方面。对于典型的数据仓库环境，OLAP 环境，我们选择RAID5 ，因为从空间上来说，RAID5更合适。

 

 

 

 

如何为数据库服务器配置存储和内存

随着服务器硬件的功能变得越来越强大，而价格一路急剧下跌，许多公司（尤其是小公司）发现如今购买数据库服务器面临众多选择。这意味着，经验相对欠缺的数据库管理员们也被要求设计功能越来越强大的系统。你在为大型系统设计数据库系统时，能够买到有许多硬盘和充足内存的大型数据库服务器。以下是你在设计系统时应当遵守的一些基本原则。

•存储系统

    人们在设计磁盘阵列时最常犯下的错误就是，只计算所需的闲置容量。闲置容量只是设计存储子系统时要考虑的一部分而已；另一个部分就是存储系统需要支持的输入/输出操作次数。

    应当遵守的一条基本原则就是，写操作频繁的数据库最好使用RAID 10阵列，而读操作频繁的数据库通常最好使用RAID 5阵列。原因在于，如果把数据写到RAID 5阵列，性能会受到影响。由于把数据写到RAID 5阵列上，存储系统必须在写数据之前计算出奇偶检验位，而算出奇偶检验位需要相当长的时间，这意味着写到RAID 5阵列上的性能会降低。

    由于这种性能影响，我们总是建议你应当把事务日志放到RAID 10阵列上。事务日志是写操作始终很频繁的文件，不管数据库是以读操作为主的数据库，还是以写操作为主的数据库。tempdb数据库也应当放在RAID 10阵列上，具体来说放在与事务日志文件所在阵列不同的另一个RAID 10阵列上。

    对每个磁盘阵列进行分区时，应当确保分区正确对齐。默认情况下，Windows 2003及以下版本没有正确对齐分区，这会导致磁盘子系统的性能达不到最理想水平。可以通过使用diskpart.exe实用程序（Windows 2000中的diskpar.exe）创建分区来解决这个问题。这样创建的每个分区其对齐偏移量应为64kb；在默认情况下，创建的每个分区其对齐偏移量为32kb。Windows 2008在默认情况下创建的分区其对齐偏移量为128kb。

•物理数据库构建

    微软最近开始推荐使用的一项比较新的技术就是，针对两个至四个CPU核心当中的每个核心，数据库应当有一个物理数据库文件。应当为数据库里面的每个文件组做到这一点。

    如果你的服务器有两个四核CPU，那么共有八个核心。我们假定数据库有两个文件组，一个名为Data，另一个名为Indexes。那么每个文件组都应当有两个至四个物理文件。这项技术让SQL Server可以对磁盘输入/输出进行优化。可能的话，你应当尽量分散文件，以便位于每个存储阵列上的文件尽可能少。

    tempdb数据库的配置应有点不同。配置tempdb数据库时，建议针对每个CPU核心，数据库应当有一个物理文件。这样系统就可以为tempdb数据库尽量加快输入/输出操作。与用户数据库一样，放在每个磁盘阵列上的文件也应当尽可能少。

    你在数据库里面应当始终至少有两个文件组。第一个文件组包括表，第二个组包括索引。你需要让它们位于不同的文件组，那样查询索引时，装入到表的操作不会受到影响，反之亦然。

•系统内存

    在过去，购买只安装了数GB内存的数据库服务器相当常见。那是因为内存的价格还很昂贵。

    如今，内存价格相当便宜；只要你能承受得了，应当购买尽量多的内存。内存越多，数据库的运行速度几乎总是越快。例外情况就是，如果你安装的内存超过了数据库的大小。举例来说，如果你有3 GB大小的数据库，但安装了8GB内存，那么为服务器添加更多内存对提升数据库的性能没有帮助，因为SQL Server可能已经能把整个数据库装入到内存中。

    在决定为SQL Server分配多大内存时，绝对不要让SQL Server把所有内存都分配给它。因为Windows操作系统需要内存来运行，安装在数据库服务器上的其他任何软件同样需要内存来运行，比如备份软件和反病毒软件等。 建议留出一两GB内存用于操作系统及所用的其他软件。这个内存量的大小取决于安装了哪些软件。

    因为没有两个数据库服务器是一样的，所以没有明确的原则规定你的硬件解决方案应当是什么样子。你有众多选择；要设计一款将来可以使用多年的可靠的解决方案，关键在于明白自己的数据库需求，明白自己使用的硬件，明白这些需求在哪些环节得到了满足，以便既没有购买对现在而言配置过低的硬件，也没有购买对下一年而言配置过高的硬件。

 

·       There is a convention of thought amongst Oracle DBA’s that databases should never be installed on disks that are configured into a RAID 5 array. The argument goes, that since Oracle accesses and writes to random points within relatively large files, the overhead of constantly calculating block-level parity on these files is substantial, resulting in serious performance degradation. They suggest that RAID 1 (mirroring) is the ideal disk configuration since no parity needs to be calculated, and Oracle is more than happy to divide up its database over many smaller mount points.

This way of thinking has largely been correct over the years because most systems have traditionally used software RAID. This means that the CPU of the server itself had the job of doing all those parity calculations, and it really did slow down both the server and the disk when RAID 5 configurations were used. Oracle, in particular, had a hard time with these configurations for the exact reasons the DBA’s point to.

In many cases, software RAID is still used, and to be sure, it is wholly inappropriate to deploy RAID 5 in these environments. However, it is increasingly common to find IT departments using a SAN-type architecture where the RAID type and configuration are invisible to the host operating system. In these environments, the the disk array has a dedicated controller that is singly tasked with handling all read, write, and parity operations. The RAID controller is no longer software running on a generic CPU, but rather firmware that is optimized to handle parity calculations. This results in a system where parity is calculated so quickly by the dedicated controller that differences in speed between RAID 1 and Raid 5 should be virtually nonexistent.

To prove this, I carved up our new InfoTrend EonStor A12F-G2221 into three arrays – a RAID 5, a RAID 1, and a RAID 10. I then set out to run some benchmarks on these different arrays to see what, if any, the differences would be.

The hardware used was as follows:

• • Dell OptiPlex GX260, 2.2 GHz Processor, 256 MB Ram
  • RHEL 4 Linux
  • QLogic QLA2340 HBA
  • InfoTrend EonStor A12F-G2221 with 1GB cache
  • The RAID 5 LUN consisted of 4 drives
  • The RAID 1 LUN consisted of 2 drives
  • The RAID 10 LUN consisted of 4 drives

I then identified the iozone tests that most accurately simulated Oracle disk activity. What I really wanted to do was to simulate select and update queries on various sized files and see how the different RAID types held up under the load. To do this, I ran iozone, a well-respected benchmark utility, with the following arguments:

/opt/iozone/bin/iozone -Ra -g 2G -b /home/sysop/new/raid5-2G-1.wks

This put the disk through its paces, as it ran the iozone tests in automatic mode on a 2 Gb file, but in the end, I was interested in analyzing the following tests because they were the ones our DBA team suggested would most closely represent database activity.

Random Read (select queries)

This test measures the performance of reading a file with accesses being made to random locations within the file. The performance of a system under this type of activity can be impacted by several factors such as: Size of operating system’s cache, number of disks, seek latencies, and others.

Random Write (update queries)

This test measures the performance of writing a file with accesses being made to random locations within the file. Again the performance of a system under this type of activity can be impacted by several factors such as: Size of operating system’s cache, number of disks, seek latencies, and others.

Strided Read (more complex select queries)

This test measures the performance of reading a file with a strided access behavior. An example would be: Read at offset zero for a length of 4 Kbytes, then seek 200 Kbytes, and then read for a length of 4 Kbytes, then seek 200 Kbytes and so on. Here the pattern is to read 4 Kbytes and then %%[Page: 3]%%

I ran several instances of the same tests using the same command line to ensure that there were no anomalies, and the machine was doing nothing else during the tests besides running the host OS. The results were pretty much as I expected, and I found little to no variation between the raid types on this disk subsystem.

Random Read Tests:

 

 

 

 

 

In this test, there seems to be the slightest advantage to the mirror-type RAID arrays when it comes to very small files. This, I suspect can be attributed to actual drive head latency as, in RAID 5 volumes, the correct block needs to be found on a larger number of disks. This advantage quickly falls off, however as the file size grows, meaning that this slight advantage would not be seen in an Oracle database.

Random Write Tests:

 

 

 

 

 

In this test, both RAID 5 and RAID 10 seem to hold a slight advantage over the direct mirror. This, I would imagine can be attributed to the fact that the writes are happening over a larger number of spindles. This indicates that the controller is calculating the parity faster than the 2Gb connection speed to the disk subsystem. Again, the variation is incredibly small, so there is no arguable performance advantage to using one type of RAID over another when using a hardware controller.

Stride Read Tests:

 

 

 

 

 

Here again we see no real advantage to one RAID type over any other. It could be said that the RAID 10 volume held up ever-so-slightly better on this test, but any edge is so slight that it would be hard to imagine how this could translate into a noticeable performance gain in an Oracle database.

In the end, these tests proved my suspicion that hardware RAID controllers have become so efficient and fast that it no longer makes any real difference what type of RAID you decide to use for your Oracle database. Largely gone are the days when your disk space and RAID volumes were inexorably tied to the server itself. So long as you are using hardware RAID, and the LUNS are abstracted from your operating system, you can largely feel free to make the most of your storage dollar by using RAID 5 in your production database environments.

 

 

Is RAID 5 Really a Bargain?

Cary Millsap, manager of Hotsos LLC and the editor of Hotsos Journal found the following facts - Is RAID 5 Really a Bargain?":

• RAID 5 costs more for write-intensive applications than RAID 1.
• RAID 5 is less outage resilient than RAID 1.
• RAID 5 suffers massive performance degradation during partial outage.
• RAID 5 is less architecturally flexible than RAID 1.
• Correcting RAID 5 performance problems can be very expensive.

My practical experience with RAID arrays configuration

To make picture clear, I'm putting RAID 10 vs RAID 5 configuration for high-load database, Vmware / Xen servers, mail servers, MS - Exchange mail server etc:

RAID Level	Total array capacity	Fault tolerance	Read speed	Write speed
RAID-10 500GB x 4 disks	1000 GB	1 disk	4X	2X
RAID-5 500GB x 3 disks	1000 GB	1 disk	2X	Speed of a RAID 5 depends upon the controller implementation

You can clearly see RAID 10 outperforms RAID 5 at fraction of cost in terms of read and write operations.