RE: Question on LUN Sizes for storage migration
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <k3nnyp@xxxxxxxxx>, <ksmadduri@xxxxxxxxx>
- Date: Wed, 21 May 2014 16:49:04 -0400
Good advice about developing a relationship with your storage team. Telling
them WHY things matter and the information you have to give ASM should help the
relationship.
Now, at the margin it is probably best to give ASM whole disk (or disk pairs or
triplets if you have external redundancy). If you carve disks up and present
them to ASM as different LUNs, then ASM does not have a way to understand that
two or more LUNs actually reside on a single spindle.
You’ve given us no idea of the underlying number of spindles making up these
LUNs. With recent storage densities the new ones could be fractional disks and
the old 90’s could be 10 9 GB disks in a stripe. If that is the case and we’re
talking spinning rust for all the devices, then your new LUNs will support far
fewer I/O operations per second per GB of storage. Of course if the old
bottleneck was the connection from the computer to the storage and the new LUNs
are connected by a much faster interface.
Okay, long winded again. Without knowing the whole stack of i/o from computer
memory to the persistent device before and after, a predictions for changes in
behavior cannot be made.
The changing size of a LUN presented to ASM is probably the least of your
worries. If someone carved up a 2 TB disk and presented it to you as 4 500GB
LUNS, now I’d be really worried about that. You absolutely do need to know the
components to tell ASM reasonable values for redundancy and recovery groups.
Good luck.
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Kenny Payton
Sent: Wednesday, May 21, 2014 3:47 PM
To: ksmadduri@xxxxxxxxx
Cc: oracle Freelists
Subject: Re: Question on LUN Sizes for storage migration
The size of the lun is not as important as the IO characteristics of it. The
performance difference of the two luns could be identical or drastically
different, it really depends on a lot of variables.
My recommendation is to attempt to build the best relationship you can with
your Storage Team and understand the configurations to the best of your
ability. While doing this also share the database workloads and behaviors with
them. Together you have the best chance of creating a sustainable and
performant environment not to mention a relationship that will pay you back 10x
over time.
On Wed, May 21, 2014 at 6:13 AM, Kumar Madduri <ksmadduri@xxxxxxxxx> wrote:
We were originally given 90 GB LUNS.
As part of storage migration to another vendor, we are being provisioned with
500 GB LUNS.
From a migration point of view, is it ok to move the data from 90 GB LUNS ton
500 GB LUNS. We would have 20 90 GB LUNS (old storage) and 4 500 GB LUNS (new
storage)
alter diskgroup DATA
drop disk
'/dev/old-lun1 -90-gb', '/dev/old-lun2-90-gb' ...., '/dev/old-lun20-90-gb'
add disk
‘/dev/new-lun1-500gb’, ‘/dev/new-lun2-500gb, ’, ‘/dev/new-lun3-500gb, ’,
‘/dev/new-lun4-500gb, ’ ;
Concern is, would it be better to stick to 90 G LUNS on new storage as well or
move to 500 GB LUNS as above (as part of migration). Our concern is would it
slow down migration if we alter the lun sizes as part of migration process.
Our Unix/Storage admin prefers the 500G LUN because they say it will reduce the
time for reboot (when required) if we have fewer number of LUNS.
Thanks again for time.
- Kumar
Other related posts:
