Raid 1+0 vs Raid 0+1

Can some kind person explain the difference between RAID 1+0 (as generally recommended) and RAID0+1 for me? In nice untechnical terms? Or even with a picture? I have a customer who is setting up lots of new disks later this month and I want to be sure I've got them to do what I want them to! TIA -- Surfer!

"Surfer!" wrote: > Can some kind person explain the difference between RAID 1+0 (as > generally recommended) and RAID0+1 for me? In nice untechnical terms? > Or even with a picture? > > I have a customer who is setting up lots of new disks later this month > and I want to be sure I've got them to do what I want them to! Don't feel bad most RAID vendors are confused. RAID01 (or RAID0+1): Build two or more stripe sets (RAID0) and mirror one with the other(s) (RAID1). RAID10 (or RAID1+0): Build N mirrored pairs, or triplets, (RAID1) and stripe them together (RAID0). Note the order of applying the different RAID levels which is the key to the naming convention, or vice-versa the naming is the key to the order of application. PowerPoint picture attached. Art S. Kagel

"Surfer!" wrote: > > Can some kind person explain the difference between RAID 1+0 (as > generally recommended) and RAID0+1 for me? In nice untechnical terms? > Or even with a picture? > > I have a customer who is setting up lots of new disks later this month > and I want to be sure I've got them to do what I want them to! > > TIA > > -- > Surfer! Here's something that helped me . . .. BEGIN (beginning of original message) Subject: RE: RAID10 explanation and mirroring setup From: William Rice <ricew@operamail.com> Date: 2000/04/05 Newsgroups: comp.databases.informix This is my understanding. It has been a couple of years sense I have dealt with the actual configuration of something like this You have Disks A-J RAID 10 Mirror A-F as V Mirror B-G as W Mirror C-H as X Mirror D-I as Y Mirror E-J as Z stripe across V W X Y Z. You lose disks A and H and system is still up RAID 01 Stripe A-B-C-D-E as Y Stripe F-G-H-I-J as Z Mirror Y-Z Lose disk A and H and I dont think the raid controller is smart enough to figure out it can use C instead of H and F instead of A. END -- John Carlson Informix DBA WHSmith USA #include std_disclaimer.h /* These are my opinions, not my company's opinion */

Thanks for the info. I've forwarded it to the hardware people along with an extract of Arts comments from IIUG. I now discover that: 1) They are using Solstice not Veritas 2) That limits them to 7 slices (we will have to use offsets) 3) Solstice also will only do RAID0+1 - it can't do RAID1+0. My reading of Art's article is that 1+0 vs. 0+1 is an integrity issue not a performance one. Is this correct? Or are there some performance issues tucked away as well? I doubt we have a choice - Veritas is quite expensive (though nothing costs as much as overwriting the logical log tapes before the next level 0 archive!) so I reckon we are stuck with Solstice. Thanks for the help anyway. In article <391B1016.586754A3@bloomberg.net>, Art S. Kagel <kagel@bloomberg.net> writes >"Surfer!" wrote: > >> Can some kind person explain the difference between RAID 1+0 (as >> generally recommended) and RAID0+1 for me? In nice untechnical terms? >> Or even with a picture? >> >> I have a customer who is setting up lots of new disks later this month >> and I want to be sure I've got them to do what I want them to! > >Don't feel bad most RAID vendors are confused. > >RAID01 (or RAID0+1): > Build two or more stripe sets (RAID0) and mirror one with the other(s) >(RAID1). > >RAID10 (or RAID1+0): > Build N mirrored pairs, or triplets, (RAID1) and stripe them together >(RAID0). > >Note the order of applying the different RAID levels which is the key to the >naming convention, or vice-versa the naming is the key to the order of >application. PowerPoint picture attached. > >Art S. Kagel > > >[ A MIME application / x-mspowerpoint part was included here. ] > -- Surfer!

> 1) They are using Solstice not Veritas > 2) That limits them to 7 slices (we will have to use offsets) Nope, 8 as long as the entire disk is raw > 3) Solstice also will only do RAID0+1 - it can't do RAID1+0. If you mean DiskSuite, AFAIR it can [cutting] -- Paul Watson # WF Software Ltd # You are only young once Tel: +44 1436 674729 # but you can be immature Fax: +44 1436 678693 # for ever www.wfsoftware.com #

"Surfer!" wrote: > > Thanks for the info. I've forwarded it to the hardware people along > with an extract of Arts comments from IIUG. > > I now discover that: > > 1) They are using Solstice not Veritas I thought Solstice IS Veritas? Or is that DiskSuite? > 2) That limits them to 7 slices (we will have to use offsets) 8 partitions not 7. Since you do not have to reserve the 2nd that Solaris administrators traditionally set up as the whole disk for image archiving, you can use all 8 partitions for chunks. Also note that using offsets will not help since the total of chunksize + offset must be less than 2GB! So the largest array you will be able to use without Veritas or another more capable VM will be a 16GB array. > 3) Solstice also will only do RAID0+1 - it can't do RAID1+0. > > My reading of Art's article is that 1+0 vs. 0+1 is an integrity issue > not a performance one. Is this correct? Or are there some performance > issues tucked away as well? Integrity and safety are the main issue between RAID01 and RAID10 but performance during recovery will be affected tremendously. Since RAID01 must recover the entire stripe to its mirror performance of ALL I/O to/from the array during recovery will be degraded as much as 80% depending on the priority given to recovery -versus- I/O. (Does Solstice permit one to set the priority?) In addition remember that the degradation will last N times as long as N drives must be copied instead of just one. Art S. Kagel > I doubt we have a choice - Veritas is quite expensive (though nothing > costs as much as overwriting the logical log tapes before the next level > 0 archive!) so I reckon we are stuck with Solstice. > > Thanks for the help anyway. > > In article <391B1016.586754A3@bloomberg.net>, Art S. Kagel > <kagel@bloomberg.net> writes > >"Surfer!" wrote: > > > >> Can some kind person explain the difference between RAID 1+0 (as > >> generally recommended) and RAID0+1 for me? In nice untechnical terms? > >> Or even with a picture? > >> > >> I have a customer who is setting up lots of new disks later this month > >> and I want to be sure I've got them to do what I want them to! > > > >Don't feel bad most RAID vendors are confused. > > > >RAID01 (or RAID0+1): > > Build two or more stripe sets (RAID0) and mirror one with the other(s) > >(RAID1). > > > >RAID10 (or RAID1+0): > > Build N mirrored pairs, or triplets, (RAID1) and stripe them together > >(RAID0). > > > >Note the order of applying the different RAID levels which is the key to the > >naming convention, or vice-versa the naming is the key to the order of > >application. PowerPoint picture attached. > > > >Art S. Kagel > > > > > >[ A MIME application / x-mspowerpoint part was included here. ] > > > > -- > Surfer!

The engineer from Morse has since emailed me that Solstice Disk Suite can do RAID1+0 and not RAID0+1 - so that's fine! In article <392019D9.9CCD340E@bloomberg.net>, Art S. Kagel <kagel@bloomberg.net> writes >"Surfer!" wrote: >> >> Thanks for the info. I've forwarded it to the hardware people along >> with an extract of Arts comments from IIUG. >> >> I now discover that: >> >> 1) They are using Solstice not Veritas > >I thought Solstice IS Veritas? Or is that DiskSuite? > >> 2) That limits them to 7 slices (we will have to use offsets) > >8 partitions not 7. Since you do not have to reserve the 2nd that Solaris >administrators traditionally set up as the whole disk for image archiving, >you can use all 8 partitions for chunks. Also note that using offsets will >not help since the total of chunksize + offset must be less than 2GB! So >the largest array you will be able to use without Veritas or another more >capable VM will be a 16GB array. > >> 3) Solstice also will only do RAID0+1 - it can't do RAID1+0. >> >> My reading of Art's article is that 1+0 vs. 0+1 is an integrity issue >> not a performance one. Is this correct? Or are there some performance >> issues tucked away as well? > >Integrity and safety are the main issue between RAID01 and RAID10 but >performance during recovery will be affected tremendously. Since RAID01 >must recover the entire stripe to its mirror performance of ALL I/O to/from >the array during recovery will be degraded as much as 80% depending on the >priority given to recovery -versus- I/O. (Does Solstice permit one to set >the priority?) In addition remember that the degradation will last N times >as long as N drives must be copied instead of just one. > >Art S. Kagel > >> I doubt we have a choice - Veritas is quite expensive (though nothing >> costs as much as overwriting the logical log tapes before the next level >> 0 archive!) so I reckon we are stuck with Solstice. >> >> Thanks for the help anyway. >> >> In article <391B1016.586754A3@bloomberg.net>, Art S. Kagel >> <kagel@bloomberg.net> writes >> >"Surfer!" wrote: >> > >> >> Can some kind person explain the difference between RAID 1+0 (as >> >> generally recommended) and RAID0+1 for me? In nice untechnical terms? >> >> Or even with a picture? >> >> >> >> I have a customer who is setting up lots of new disks later this month >> >> and I want to be sure I've got them to do what I want them to! >> > >> >Don't feel bad most RAID vendors are confused. >> > >> >RAID01 (or RAID0+1): >> > Build two or more stripe sets (RAID0) and mirror one with the other(s) >> >(RAID1). >> > >> >RAID10 (or RAID1+0): >> > Build N mirrored pairs, or triplets, (RAID1) and stripe them together >> >(RAID0). >> > >> >Note the order of applying the different RAID levels which is the key to the >> >naming convention, or vice-versa the naming is the key to the order of >> >application. PowerPoint picture attached. >> > >> >Art S. Kagel >> > >> > >> >[ A MIME application / x-mspowerpoint part was included here. ] >> > >> >> -- >> Surfer! -- Surfer!

Shows what he knows then!! I'm in the process of redoing a Disk Suite install 'cos I'd done RAID0+1 instead of RAID1+0 - a bit of brain fade on my part:-)) "Surfer!" wrote: > > The engineer from Morse has since emailed me that Solstice Disk Suite > can do RAID1+0 and not RAID0+1 - so that's fine! > > In article <392019D9.9CCD340E@bloomberg.net>, Art S. Kagel > <kagel@bloomberg.net> writes > >"Surfer!" wrote: > >> > >> Thanks for the info. I've forwarded it to the hardware people along > >> with an extract of Arts comments from IIUG. > >> > >> I now discover that: > >> > >> 1) They are using Solstice not Veritas > > > >I thought Solstice IS Veritas? Or is that DiskSuite? > > > >> 2) That limits them to 7 slices (we will have to use offsets) > > > >8 partitions not 7. Since you do not have to reserve the 2nd that Solaris > >administrators traditionally set up as the whole disk for image archiving, > >you can use all 8 partitions for chunks. Also note that using offsets will > >not help since the total of chunksize + offset must be less than 2GB! So > >the largest array you will be able to use without Veritas or another more > >capable VM will be a 16GB array. > > > >> 3) Solstice also will only do RAID0+1 - it can't do RAID1+0. > >> > >> My reading of Art's article is that 1+0 vs. 0+1 is an integrity issue > >> not a performance one. Is this correct? Or are there some performance > >> issues tucked away as well? > > > >Integrity and safety are the main issue between RAID01 and RAID10 but > >performance during recovery will be affected tremendously. Since RAID01 > >must recover the entire stripe to its mirror performance of ALL I/O to/from > >the array during recovery will be degraded as much as 80% depending on the > >priority given to recovery -versus- I/O. (Does Solstice permit one to set > >the priority?) In addition remember that the degradation will last N times > >as long as N drives must be copied instead of just one. > > > >Art S. Kagel > > > >> I doubt we have a choice - Veritas is quite expensive (though nothing > >> costs as much as overwriting the logical log tapes before the next level > >> 0 archive!) so I reckon we are stuck with Solstice. > >> > >> Thanks for the help anyway. > >> > >> In article <391B1016.586754A3@bloomberg.net>, Art S. Kagel > >> <kagel@bloomberg.net> writes > >> >"Surfer!" wrote: > >> > > >> >> Can some kind person explain the difference between RAID 1+0 (as > >> >> generally recommended) and RAID0+1 for me? In nice untechnical terms? > >> >> Or even with a picture? > >> >> > >> >> I have a customer who is setting up lots of new disks later this month > >> >> and I want to be sure I've got them to do what I want them to! > >> > > >> >Don't feel bad most RAID vendors are confused. > >> > > >> >RAID01 (or RAID0+1): > >> > Build two or more stripe sets (RAID0) and mirror one with the other(s) > >> >(RAID1). > >> > > >> >RAID10 (or RAID1+0): > >> > Build N mirrored pairs, or triplets, (RAID1) and stripe them together > >> >(RAID0). > >> > > >> >Note the order of applying the different RAID levels which is the key to the > >> >naming convention, or vice-versa the naming is the key to the order of > >> >application. PowerPoint picture attached. > >> > > >> >Art S. Kagel > >> > > >> > > >> >[ A MIME application / x-mspowerpoint part was included here. ] > >> > > >> > >> -- > >> Surfer! > > -- > Surfer! -- Paul Watson # WF Software Ltd # You are only young once Tel: +44 1436 674729 # but you can be immature Fax: +44 1436 678693 # for ever www.wfsoftware.com #

Folks, I am more of a system administrator than a DBA and I am a newbie to Informix, so excuse my naive question. My main question is: Does Informix have any problems with striping, mirroring etc under any version or on any flavour of Unix/NT? The reason I ask this is because I've been told by some source that: 1. Informix does not like striping/mirroring etc because not only it does not improve the performance/integrity, it degrades performance. 2. Informix tables HAVE to be Raw, otherwise the filesystem overhead would result in severe performance penalties. I'd like to know if there is any substance to the above statements, or if any of them was ever true under some particular version of Informix etc. I come from a System Admin background with some Oracle knowledge, and my understanding was: 1. Striping and Mirroring can be applied to just about anything to gain performance/redundancy 2. Raw tables do increase performance by a little, but this should be done as the very last resourt to get performance, because in most cases the administrational overheads outweight the performance benefits. 3. The operating system performs the RAID function, so the RAID details are hidden away from the application that uses it (Informix in this case), so why should Informix even care? Reading through this thread, it seems like Informix does not have any problems with RAID whatsoever. Can someone verify this for me please, or point me to a formal statement that acknowledges/denies the above, or gives a rough indication of how much performance gain a raw table gives as opposed to a filesystem table. I really appreciate any information/comments, Thanks in advance, -- Walter Lolham - walterl@genasys.com.au

Walter wrote: > > Folks, > > I am more of a system administrator than a DBA and I am a newbie to Informix, so > excuse my naive question. > Good to have you aboard. > My main question is: > > Does Informix have any problems with striping, mirroring etc under any version or on > any flavour of Unix/NT? I'm not sure about NT, but under UNIX it shouldn't have any problem, if testimony in this newsgroup is any indication. We're planning to mirror our production server within a month or so, so I'll get to understand first-hand. > > The reason I ask this is because I've been told by some source that: Always good to consider the source . . . 8-) > > 1. Informix does not like striping/mirroring etc because not only it does not improve > the performance/integrity, it degrades performance. Not that I'm aware of. Informix can mirror at the engine level, but it also can handle hardware or software mirroring as well. > > 2. Informix tables HAVE to be Raw, otherwise the filesystem overhead would result in > severe performance penalties. Not that I'm aware of. There would be performance issues (however slight) by going through the Unix file system buffers as well as forcing a flush to disk, but I don't think that it would be classified as severe. > > I'd like to know if there is any substance to the above statements, or if any of them > was ever true under some particular version of Informix etc. Not in the manner which you describe them. Looks like someone really had it out for Informix. > > I come from a System Admin background with some Oracle knowledge, and my > understanding was: > > 1. Striping and Mirroring can be applied to just about anything to gain > performance/redundancy > Agreed. > 2. Raw tables do increase performance by a little, but this should be done as the > very last resourt to get performance, because in most cases the administrational > overheads outweight the performance benefits. > I haven't had a problem with administrational overhead. We initially started with rawspaces five years ago because of some issues with the UNIX disk buffer flushing. Besides, my dbspace structures are not visible to the OS, so no one can accidentally change permissions, delete, etc. > 3. The operating system performs the RAID function, so the RAID details are hidden > away from the application that uses it (Informix in this case), so why should > Informix even care? > Agreed. > Reading through this thread, it seems like Informix does not have any problems with > RAID whatsoever. > Can someone verify this for me please, or point me to a formal statement that > acknowledges/denies the above, or gives a rough indication of how much performance > gain a raw table gives as opposed to a filesystem table. > Such information exists in deja.com, but if memory serves me correctly, there were those users who found up to 20% increase in performance using raw over cooked. > I really appreciate any information/comments, > Thanks in advance, > -- > Walter Lolham - walterl@genasys.com.au -- John Carlson Informix DBA WHSmith USA #include std_disclaimer.h /* These are my opinions, not my company's opinion */

Walter wrote: > > Folks, > > I am more of a system administrator than a DBA and I am a newbie to Informix, so > excuse my naive question. > > My main question is: > > Does Informix have any problems with striping, mirroring etc under any version or on > any flavour of Unix/NT? None. Informix does not care what kind of disk farm is under the hood. > The reason I ask this is because I've been told by some source that: > > 1. Informix does not like striping/mirroring etc because not only it does not improve > the performance/integrity, it degrades performance. Only if the disk farm is poorly designed or the dbspaces poorly laid out across the far, or if it has to share the disk farm with greedy OS processes. No such problem exists that a good SA together with a good Informix DBA cannot fix. > 2. Informix tables HAVE to be Raw, otherwise the filesystem overhead would result in > severe performance penalties. This has nothing to do directly with Informix but with the nature of RAW partitions versus COOKED partitions versus COOKED FS files. There is a 15-25% performance penalty overall using COOKED (block) devices versus using RAW (character) devices. This is caused by the overhead of copying the data a second time to/from the Informix buffers and the OS buffer cache before/after writing/reading disk. This extra step has a fixed cost that varies based on hardware and NO high speed filesystem or OS can improve it. In addition there is another 5-30% performance penalty if Informix chunks are created from filesystem files instead of device files due to the additional overhead of filesystem operations and the noncontiguous nature of filesystem files. This last is VERY variable and here more modern, tunable, database aware, filesystem can minimize the hit somewhat but remember you are still eating the COOKED device hit of the underlying mounted block device and the system cache. > I'd like to know if there is any substance to the above statements, or if any of them > was ever true under some particular version of Informix etc. The COOKED device/file penalties are true but not Informix specific. The statements about Informix not liking/working with RAID is bunk. > I come from a System Admin background with some Oracle knowledge, and my > understanding was: > > 1. Striping and Mirroring can be applied to just about anything to gain > performance/redundancy TRUTH! > 2. Raw tables do increase performance by a little, but this should be done as the > very last resourt to get performance, because in most cases the administrational > overheads outweight the performance benefits. This has always been Oracle's claim, but I've benchmarked it too many times on too many different systems. The penalties for using COOKED devices and files are real and significant on a busy system. > 3. The operating system performs the RAID function, so the RAID details are hidden > away from the application that uses it (Informix in this case), so why should > Informix even care? It does not. If you are using Informix Fragmentation, which has some of the benefits of striping, along with any striped RAID class (0,3,4,5,10) you have to be careful that you are not replacing single disk hot spots with flooded controllers and busses because Informix parallelism is VERY efficient at using multiple dbspaces in parallel. Again any competent DBA with the help of a competent SA can plan and build an awesome Informix system with Fragmentation, RAID (3, 4, or 10), and RAW devices as tools. > Reading through this thread, it seems like Informix does not have any problems with > RAID whatsoever. > Can someone verify this for me please, or point me to a formal statement that > acknowledges/denies the above, or gives a rough indication of how much performance > gain a raw table gives as opposed to a filesystem table. See above. Art S. Kagel

There is one very major problem with raid 5 in that some controllers will read a whole stripe even if you are doing random 2KB reads. Ie reading 128KB and almost never using the rest for every 2KB is a very big hit. raid 5 is just a kludge used because discs were so expensive. raid 0+1 is the only way to go if you dont have hardware limitations. -- Geoff Johnson

Geoff Johnson wrote: > There is one very major problem with raid 5 in that some controllers > will read a whole stripe even if you are doing random 2KB reads. > Ie reading 128KB and almost never using the rest for every 2KB is > a very big hit. > raid 5 is just a kludge used because discs were so expensive. > raid 0+1 is the only way to go if you dont have hardware limitations. > Those would be poor RAID5 implementations indeed since the standard specifies that ONLY the disk containing the desired block and that stripe chunk's parity block should be read. BTW RAID10 (or RAID1+0 if you prefer) is preferable to RAID01 for safety and recovery reasons. Art S. Kagel