Raw Device setup on SAN disks - suggestions?
Posted in 2007
A user migrating IDS 7.31 from seven local disks with 20 raw devices to a SAN presented as a single LUN asked how to spread hot tables across spindles, whether multiple LUNs would help, and what RAID level to use. Respondents said one LUN means one I/O queue, which IDS's multi-threaded I/O can't saturate, so several smaller LUNs (ideally RAID 10, emphatically not RAID 5, per Art Kagel's long anti-RAID5 rant) are preferred. The poster postponed the migration to have multiple LUNs configured; discussion drifted to RAID 1 vs 10 and whether anyone still uses Informix mirroring, with no further outcome reported.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Performance & Tuning, Platform-Specific Issues, Versions, Editions & End-of-Life
Hello,
We are currently migrating from IDS 7.31.UC2A (32 bit OS) to IDS 7.31.HD9 (64
bit OS).
On our old setup we had 7 physical local disks with 20 raw devices on them.
The raw devices were spread so that the hardest hit tables were on separate
disks to spread the load.
Our new set up is on a SAN and we have we given 1 LUN. Our techincal guys have
advised that this is 1 logical disk spread over many physical disks. We ran
update statistics against the database at the same time as our users conducteda volume test so we could hit it hard and although there didn't seem to be any
degradation in performance we DID get a warning from HP-UX telling us there
was a possible Disk bottleneck.
My questions are:
1. How can we assure that our hardest hit tables are spread over different
disks with a SAN set-up?
2. Could we get the technical guys to set up multiple LUNs for us and would
this make any difference?
3. What does Informix/IBM suggest?
I'll have a look around the release documentation to answer question 3 but I'd
be grateful for you expert opinions.
Many thanks.
Unfortunately, 1 LUN = 1 queue (for all reads and writes). IDS is
multi-threaded. The "many physical disks" does not overcome the 1 queue
in my experience. I would suggest multiple smaller RAID 10 LUNs so IDS
can pump the data through multiple queues.
Bob Roussey
Unix / Informix Administration
Spirit Airlines
Robert.Roussey@SpiritAir.com
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
DAVID GEORGE
Sent: Tuesday, October 02, 2007 10:47 AM
To: ids@iiug.org
Subject: Raw Device setup on SAN disks - suggestions? [10027]
Hello,
We are currently migrating from IDS 7.31.UC2A (32 bit OS) to IDS
7.31.HD9 (64
bit OS).
On our old setup we had 7 physical local disks with 20 raw devices on
them.
The raw devices were spread so that the hardest hit tables were on
separate
disks to spread the load.
Our new set up is on a SAN and we have we given 1 LUN. Our techincal
guys have
advised that this is 1 logical disk spread over many physical disks. We
ran
update statistics against the database at the same time as our usersconducted
a volume test so we could hit it hard and although there didn't seem to
be any
degradation in performance we DID get a warning from HP-UX telling us
there
was a possible Disk bottleneck.
My questions are:
1. How can we assure that our hardest hit tables are spread over
different
disks with a SAN set-up?
2. Could we get the technical guys to set up multiple LUNs for us and
would
this make any difference?
3. What does Informix/IBM suggest?
I'll have a look around the release documentation to answer question 3
but I'd
be grateful for you expert opinions.
Many thanks.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
We're all still feeling our way through the SAN morass. First, make sure that
array of disk is NOT RAID5 but RAID10. RAID5 and databases are a VERY bad
combination (see the articles, including mine, and member comments on the BAARF
web site - www.baarf.com - on the evils of RAID5). If HPUX is warning of a
disk bottleneck it's because the IO waits on the device driver for the one
channel to the SAN were higher then the configured monitoring threshhold. It
probably means that yes, things could be better. See if the SAN can be broken
into 2 or more arrays that will improve throughput and reduce wait times
assuming the network channel between the primary CPU box and the SAN is fast
enough.
Art S. Kagel
----- Original Message -----
From: Robert Roussey <ids@iiug.org>
To: ids@iiug.org
At: 10/02 10:59:29
Unfortunately, 1 LUN = 1 queue (for all reads and writes). IDS is
multi-threaded. The "many physical disks" does not overcome the 1 queue
in my experience. I would suggest multiple smaller RAID 10 LUNs so IDS
can pump the data through multiple queues.
Bob Roussey
Unix / Informix Administration
Spirit Airlines
Robert.Roussey@SpiritAir.com
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
DAVID GEORGE
Sent: Tuesday, October 02, 2007 10:47 AM
To: ids@iiug.org
Subject: Raw Device setup on SAN disks - suggestions? [10027]
Hello,
We are currently migrating from IDS 7.31.UC2A (32 bit OS) to IDS
7.31.HD9 (64
bit OS).
On our old setup we had 7 physical local disks with 20 raw devices on
them.
The raw devices were spread so that the hardest hit tables were on
separate
disks to spread the load.
Our new set up is on a SAN and we have we given 1 LUN. Our techincal
guys have
advised that this is 1 logical disk spread over many physical disks. We
ran
update statistics against the database at the same time as our usersconducted
a volume test so we could hit it hard and although there didn't seem to
be any
degradation in performance we DID get a warning from HP-UX telling us
there
was a possible Disk bottleneck.
My questions are:
1. How can we assure that our hardest hit tables are spread over
different
disks with a SAN set-up?
2. Could we get the technical guys to set up multiple LUNs for us and
would
this make any difference?
3. What does Informix/IBM suggest?
I'll have a look around the release documentation to answer question 3
but I'd
be grateful for you expert opinions.
Many thanks.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Thank-you Robert and Art for your responses. I appreciate that. We have postponed the migration for a little while so that we can set up multiple LUNs. I'm not sure which RAID we are but that's a good question to bring up with our technical support. Thanks.
Information from our technical support suggests that we are using neither RAID 5 nor RAID 10 but rather RAID 1. Does anyone have any opinions on that? Apparently RAID 10 is not an option on HP SAN.
RAID 1 is mirroring; much better than no redundancy at all. Bob Roussey Unix / Informix Administration Spirit Airlines Robert.Roussey@SpiritAir.com -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of DAVID GEORGE Sent: Wednesday, October 03, 2007 10:29 AM To: ids@iiug.org Subject: Re: RE: Raw Device setup on SAN disks - suggestion [10035] Information from our technical support suggests that we are using neither RAID 5 nor RAID 10 but rather RAID 1. Does anyone have any opinions on that? Apparently RAID 10 is not an option on HP SAN. ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.
RAID10 is just a stripe set (RAID0) built from N mirrored pairs (RAID1). Unless you have a single awfully big pair of disks on that SAN they aren't using ONLY RAID1 since it just mirrors one drive to one or more other drives, it's not any kind of array. First I'm fairly certain that HP SANS can handle RAID10 (since HP is very fond of "promoting" RAID10 arrays into RAID5 automagically if they get close to filling up <ARGH!>), second if your SAs have build the SAN using all drives as a single LUN and they're using mirroring then they MUST be using either RAID01 or RAID10. Art S. Kagel ----- Original Message ----- From: David George <ids@iiug.org> To: ids@iiug.org At: 10/03 10:29:17 Information from our technical support suggests that we are using neither RAID 5 nor RAID 10 but rather RAID 1. Does anyone have any opinions on that? Apparently RAID 10 is not an option on HP SAN. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
... which brings up an interesting follow-up question. Does anyone use Informix-based mirroring anymore or just rely on hardware mirroring? If you do use Informix-mirroring, are you mirroring just the critical (root, logdbs, phydbs) dbspaces? Take care. Clifton M. Bean Informix DBA / AIX System Admin Currency Technics & Metrics Phone: (972) 812-1411 x244 -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Robert Roussey(IT) Sent: Wednesday, October 03, 2007 9:36 AM To: ids@iiug.org Subject: RE: RE: Raw Device setup on SAN disks - suggestion [10036] RAID 1 is mirroring; much better than no redundancy at all. Bob Roussey Unix / Informix Administration Spirit Airlines Robert.Roussey@SpiritAir.com -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of DAVID GEORGE Sent: Wednesday, October 03, 2007 10:29 AM To: ids@iiug.org Subject: Re: RE: Raw Device setup on SAN disks - suggestion [10035] Information from our technical support suggests that we are using neither RAID 5 nor RAID 10 but rather RAID 1. Does anyone have any opinions on that? Apparently RAID 10 is not an option on HP SAN. ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.
Hi, Informix-mirroring of root,logdbs,physdbs comes with every SAP R/3 standard Installation (using informix as database). Therefore almost everybody running SAP R/3 on informix will use mirroring For these dbspaces. For other installations - we don't use informix mirroring. Regards Andreas Kutsche > ------------------------------------------- SPAR Österreichische Warenhandels-AG Hauptzentrale A - 5015 Salzburg, Europastrasse 3 FN 34170 a Tel: +43 662 4470 24223 Mobile: +43 664 6259575 E-Mail: Andreas.KUTSCHE@spar.at Internet: http://www.spar.at Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die Informationen in dieser E-Mail sind ausschließlich für den Adressaten bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen. Über das Internet versandte E-Mails können leicht manipuliert oder unter fremdem Namen erstellt werden. Daher schließen wir die rechtliche Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich bestätigt und gezeichnet wird. Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. hieraus entstehende Schäden. Wir danken für Ihr Verständnis. Important notice: The contents of this e-mail may contain confidential and legally protected information that is in particular related to operational and trade secrets, which the recipient is obliged to treat as confidential. The information in this e-mail is made available exclusively for use by the addressee. In the event that the e-mail may have been sent to you in error, we would ask you to kindly delete this communication from your system and to contact us. E-mails sent via the Internet can be easily manipulated or sent out under someone else's name. We therefore do not accept legal liability for the information contained in this communication. The contents of the e-mail are only legally binding if they have been confirmed and signed by us in writing. If, in spite of our using Antivirus protection software, a virus may have penetrated your system through the sending of this e-mail, we do not accept liability for any damage that may possibly arise as a result of this. We trust that you appreciate our position. ------------------------------------------- -----Ursprüngliche Nachricht----- > Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im > Auftrag von Clifton Bean > Gesendet: Mittwoch, 03. Oktober 2007 16:43 > An: ids@iiug.org > Betreff: RE: RE: Raw Device setup on SAN disks - suggestion [10038] > > .... which brings up an interesting follow-up question. > > Does anyone use Informix-based mirroring anymore or just rely > on hardware mirroring? > > If you do use Informix-mirroring, are you mirroring just the > critical (root, logdbs, phydbs) dbspaces? > > Take care. > > Clifton M. Bean > Informix DBA / AIX System Admin > Currency Technics & Metrics > > Phone: (972) 812-1411 x244 > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On > Behalf Of Robert > Roussey(IT) > Sent: Wednesday, October 03, 2007 9:36 AM > To: ids@iiug.org > Subject: RE: RE: Raw Device setup on SAN disks - suggestion [10036] > > RAID 1 is mirroring; much better than no redundancy at all. > > Bob Roussey > Unix / Informix Administration > Spirit Airlines > Robert.Roussey@SpiritAir.com > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On > Behalf Of DAVID GEORGE > Sent: Wednesday, October 03, 2007 10:29 AM > To: ids@iiug.org > Subject: Re: RE: Raw Device setup on SAN disks - suggestion [10035] > > Information from our technical support suggests that we are > using neither RAID > 5 nor RAID 10 but rather RAID 1. Does anyone have any > opinions on that? > > Apparently RAID 10 is not an option on HP SAN. > > ************************************************************** > ********** > ******* > Forum Note: Use "Reply" to post a response in the discussion forum. > > ************************************************************** > ************** > *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ************************************************************** > ***************** > Forum Note: Use "Reply" to post a response in the discussion forum. > >
We have HP XP128 and XP1024 , both are RAID5 ( actually 6/2 , 8 disks by group , using 6 disk and 2 "standby" ) we have 'n' Luns and each lun take a piece of each group ( 50gb each lun , stripe between all groups) . We do not have any kind of performance issue.....2.500 users......SAP and other systems.... Ricardo Manzo Informática / Banco de Dados COSAN Fone: (19) 3403-2159 Fax: (19) 3403-2128 ricardo.manzo@cosan.com.br -----Mensagem original----- De: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Em nome de ART KAGEL, BLOOMBERG/ 731 LEXIN Enviada em: quarta-feira, 3 de outubro de 2007 11:42 Para: ids@iiug.org Assunto: Re: RE: Raw Device setup on SAN disks - suggestion [10037] RAID10 is just a stripe set (RAID0) built from N mirrored pairs (RAID1). Unless you have a single awfully big pair of disks on that SAN they aren't using ONLY RAID1 since it just mirrors one drive to one or more other drives, it's not any kind of array. First I'm fairly certain that HP SANS can handle RAID10 (since HP is very fond of "promoting" RAID10 arrays into RAID5 automagically if they get close to filling up <ARGH!>), second if your SAs have build the SAN using all drives as a single LUN and they're using mirroring then they MUST be using either RAID01 or RAID10. Art S. Kagel ----- Original Message ----- From: David George <ids@iiug.org> To: ids@iiug.org At: 10/03 10:29:17 Information from our technical support suggests that we are using neither RAID 5 nor RAID 10 but rather RAID 1. Does anyone have any opinions on that? Apparently RAID 10 is not an option on HP SAN. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
From: Ricardo Manzo <ids@iiug.org> To: ids@iiug.org At: 10/03 11:10:57 We have HP XP128 and XP1024 , both are RAID5 ( actually 6/2 , 8 disks by group , using 6 disk and 2 "standby" ) we have 'n' Luns and each lun take a piece of each group ( 50gb each lun , stripe between all groups) . We do not have any kind of performance issue.....2.500 users......SAP and other systems.... Ricardo Manzo Informática / Banco de Dados COSAN Fone: (19) 3403-2159 Fax: (19) 3403-2128 ricardo.manzo@cosan.com.br AAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! Time to post my RAID5 Rant again I see: Why Noone should use RAID5 for anything, especially not databases: RAID5 versus RAID10 (or even RAID3 or RAID4) What is RAID5? OK here is the deal, RAID5 uses ONLY ONE parity drive per stripe and many RAID5 arrays are 5 (if your counts are different adjust the calculations appropriately) drives (4 data and 1 parity though it is not a single drive that is holding all of the parity as in RAID 3 & 4 but read on). If you have 10 drives or say 20GB each for 200GB RAID5 will use 20% for parity so you will have 160GB of storage. Now since RAID10, like mirroring (RAID1), uses 1 (or more) mirror drive for each primary drive you areusing 50% for redundancy so to get the same 160GB of storage you will need 8 pairs or 16 - 20GB drives, which is why RAID5 is so popular. This intro is just to put things into perspective. RAID5 is physically a stripe set like RAID0 but with data recovery included. RAID5 reserves one disk block out of each stripe block for parity data. The parity block contains an error correction code which can correct any error in the RAID5 block, in effect it is used in combination with the remaining data blocks to recreate any single missing block, gone missing because a drive has failed. The innovation of RAID5 over RAID3 & RAID4 is that the parity is distributed on a round robin basis so that there can be independent reading of different blocks from the several drives. This is why RAID5 became more popular than RAID3 & RAID4 which must sychronously read the same block from all drives together. So, if Drive2 fails blocks 1,2,4,5,6 &7 are data blocks on this drive and blocks 3 and 8 are parity blocks on this drive. So that means that the parity on Drive5 will be used to recreate the data block from Disk2 if block 1 is requested before a new drive replaces Drive2 or during the rebuilding of the new Drive2 replacement. Likewise the parity on Drive1 will be used to repair block 2 and the parity on Drive3 will repair block4, etc. For block 2 all the data is safely on the remaining drives but during the rebuilding of Drive2's replacement a new parity block will be calculated from the block 2 data and will be written to Drive 2. Now when a disk block is read from the array the RAID software/firmware calculates which RAID block contains the disk block, which drive the disk block is on and which drive contains the parity block for that RAID block and reads ONLY the data drive. It returns the data block . If you later modify the data block it recalculates the parity by subtracting the old block and adding in the new version then in two separate operations it writes the data block followed by the new parity block. To do this it must first read the parity block from whichever drive contains the parity for that stripe block and reread the unmodified data for the updated block from the original drive. This read-read-write-write is known as the RAID5 write penalty since these two writes are sequential and synchronous the write system call cannot return until the reread and both writes complete, for safety, so writing to RAID5 is up to 50% slower than RAID0 for an array of the same capacity. Now what is RAID10: RAID10 is one of the combinations of RAID1 (mirroring) and RAID0 (striping) which are possible. There used to be confusion about what RAID01 or RAID01 meant and different RAID vendors defined them differently. About five years or so ago I proposed the following standard language which seems to have taken hold. When N mirrored pairs are striped together this is called RAID10 because the mirroring (RAID1) is applied before striping (RAID0). The other option is to create two stripe sets and mirror them one to the other, this is known as RAID01 (because the RAID0 is applied first). In either a RAID01 or RAID10 system each and every disk block is completely duplicated on its drive's mirror. Performance-wise both RAID01 and RAID10 are functionally equivalent. The difference comes in during recovery where RAID01 suffers from some of the same problems I will describe affecting RAID5 while RAID10 does not. Now if a drive in the RAID5 array dies, is removed, or is shut off data is returned by reading the blocks from the remaining drives and calculating the missing data using the parity, assuming the defunct drive is not the parity block drive for that RAID block. Note that it takes 4 physical reads to replace the missing disk block (for a 5 drive array) for four out of every five disk blocks leading to a 64% performance degradation until the problem is discovered and a new drive can be mapped in to begin recovery. If a drive in the RAID10 array dies data is returned from its mirror drive in a single read with only minor (6.25% on average) performance reduction when two non-contiguous blocks are needed from the damaged pair and none otherwise. One begins to get an inkling of what is going on and why I dislike RAID5, but there's more. What's wrong besides a bit of performance I don't know I'm missing? OK, so that brings us to the final question of the day which is: What is the problem with RAID5? It does recover a failed drive right? So writes are slower, I don't do enough writing to worry about it and the cache helps a lot also, I've got LOTS of cache! The problem is that despite the improved reliability of modern drives and the improved error correction codes on most drives, and even despite the additional 8 bytes of error correction that EMC puts on every Clariion drive disk block (if you are lucky enough to use EMC systems), it is more than a little possible that a drive will become flaky and begin to return garbage. This is known as partial media failure. Now SCSI controllers reserve several hundred disk blocks to be remapped to replace fading sectors with unused ones, but if the drive is going these will not last very long and will run out and SCSI does NOT report correctable errors back to the OS! Therefore you will not know the drive is becoming unstable until it is too late and there are no more replacement sectors and the drive begins to return garbage. [Note that the recently popular ATA drives do not (TMK) include bad sector remapping in their hardware so garbage is returned that much sooner.] When a drive returns garbage, since RAID5 does not EVER check parity on read (RAID3 & RAID4 do BTW and both perform better for databases than RAID5 to boot) when you write the garbage sector back garbage p