ADSM-L

Re: [ADSM-L] Lun versus logical volume for DB volumes

2014-07-16 10:49:53
Subject: Re: [ADSM-L] Lun versus logical volume for DB volumes
From: "Rhodes, Richard L." <rrhodes AT FIRSTENERGYCORP DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 16 Jul 2014 14:47:50 +0000
> allocating one big lun, with multiple AIX VGs on it
In AIX, a lun is part of a vg.  A single lun can only be part of a single vg.

Our experience with big databases is with Oracle on AIX.

AIX has 2 levels of queues:  
   - on the hba (lsattr -El fcsX   | grep num_cmd_elems)
   - on the lun (lsattr -El hdiskY | grep queue_depth) 

Your backend with SVC/XIV means that you shouldn't hit disk hot spots on the 
storage array.  This is really good.

One problem you can hit is to max out the queue of the host hba, SVC hba or XIV 
hba. The AIX fcs depth can be seen in the above lsattr cmd.  If the AIX fcs 
queue is full, AIX waits.  If the queue at the SVC/XIV is full, that system 
sends a cmd back to the host saying to stop sending.  This causes a slowdown.  
Since multiple servers probably share the SVC ports, there can be a problem if 
the aggregate server I/O's fill the SVC  port queue.  AIX iostat has a stat for 
tracking if this occurs (sqfull???).  This is one reason for having multiple 
hba's on a server into the SAN, feeding multiple ports on the SVC, into 
multiple ports on the XIV is really helpful.  Be sure the luns are set to 
algorithm round-robin to make use of multiple paths to the lun.  I assume the 
SVC has the same idea for the backend I/O's to the XIV via multiple paths.

There is also a queue for each lun.  If your AIX application (DB2, Oracle, 
whatever) pounds a single lun (hdisk), you can max out this queue.  So while 
you may have lots of backend IOPS in the SVC/XIV, you may not be able to get 
I/O's through to them.  This is why a single big lun in AIX isn't really good.  
You can raise the queue size of the lun.  You can also spread your 
database/application across multiple luns.  For our big systems we allocate 
lots of luns and spread the AIX VG physical partitions across all the luns 
(maximum parm of the vg).  When we add a lun to a server like this, we then do 
a reorgvg to re-spread the physical partitions so that all luns are performing 
I/O.  (If you have a hot spot that fits within a single physical partition, 
there's not much you can do about it!)  Think of a lun as having two 
characteristics:  capacity and IOPS.  Capacity is easy to get and use up, IOPS 
can be much harder to get and use.

With your SVC in the middle you have 3 levels of virtualization to figure out 
and handle:  AIX LVM (vg's and lv's), the SVC (IOGROUPS, pools, mdisks???, not 
sure what all), and finally the XIV (different heads and extents spread across 
all disks).    This multiple levels of stripping is called a PLAID.  It's 
really good for random workloads, but can be bad for sequential processing!   
Interesting . . . doesn't DB2 do some kind of stripping across the separate 
filesystems you can give the db, and, has limits on concurrent I/O's per 
filesystem????  That would make a 4th levels of stripping and tuning!! 

Ahhhh, things are so simple!  (not)




Rick




-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Steven Harris
Sent: Wednesday, July 16, 2014 8:43 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Fwd: [ADSM-L] Lun versus logical volume for DB volumes

Thanks Ron for the reply

Its actually moot as the back end is XIV behind SVCs.  But the SAN guys like to 
allocate standard size luns and my DB luns are all a bit small for their 
liking, so if I could get the same multithread effect by allocating one big 
lun, with multiple AIX VGs on it, that would be happiness.

Regards

Steve.


On 16 July 2014 13:05, Ron Delaware <ron.delaware AT us.ibm DOT com> wrote:

> Steven,
>
> The logical volumes are not dedicated disks in most cases, which means 
> that other applications may be using the same disks at the same time. 
> With our new "TSM Server Blueprint" standards, TSM database's over 1TB 
> require
> 16 luns.
>
> You can go to this link to find out more
>
>
> https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki
> /Tivoli%20Storage%20Manager/page/NEW%20-%20Tivoli%20Storage%20Manager%
> 20Blueprint%20-%20%20Improve%20the%20time-to-value%20of%20your%20deplo
> yments
>
>
>
> Best Regards,
>
> _________________________________________________________
> * Ronald C. Delaware*
> IBM Level 2 - IT Plus Certified Specialist – Expert IBM Corporation | 
> Tivoli Software IBM Certified Solutions Advisor - Tivoli Storage IBM 
> Certified Deployment Professional Butterfly Solutions Professional
> 916-458-5726 (Office
> 925-457-9221 (cell phone)
>
> email: *ron.delaware AT us.ibm DOT com* <ron.delaware AT us.ibm DOT com>
>
> From:        Steven Harris <steve AT STEVENHARRIS DOT INFO>
> To:        ADSM-L AT vm.marist DOT edu
> Date:        07/15/2014 06:55 PM
> Subject:        [ADSM-L] Lun versus logical volume for DB volumes
> Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu>
> ------------------------------
>
>
>
> Hi,
>
> I've specced a design for a new TSM server and as recommended have 
> specified multiple luns for the database.  The folklore is that DB2 
> will start one thread per lun so for a big database you use 8 luns and 
> hence get
> 8 threads.
>
> My AIX guy is asking whether I really need 8 luns or will 8 AIX 
> logical volumes have the same effect.
>
> Does anyone know or can tell me where to look?
>
> Thanks
>
> Steve.
>
> Steven Harris
> TSM Admin
> Canberra Australia
>
>
>

-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
<Prev in Thread] Current Thread [Next in Thread>