Re: Subject: RE: ASM - number of LUNS rule of thumb
- From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- To: George Johnson <George.Johnson@xxxxxxx>, oracle-l digest users <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 19 Aug 2010 10:53:19 -0500
IMHO, the big question revolves around capacity management: what if you
need to expand an existing diskgroup? Generally I've seen two strategies:
1) Storage-based capacity management.
When possible, use a single LUN per diskgroup. (More only if exceeding
ASM limitations - but really try to avoid this.) The storage admin -
who knows a lot about this sort of thing - can be responsible for
keeping a balanced configuration. Last time I was involved in setting a
large-scale strategy for ASM was about 1.5 years ago. At that time,
during my conversations with storage guys, it seemed that their storage
systems really didn't handle LUN expansion very well for heavy workloads
and resulted in data being a bit unevenly spread (and thus more
potential hotspots). But we used this strategy at a smaller company I
worked with; it works quite nicely for smaller environments that aren't
very I/O intensive because it's very simple and easy to manage.
One note... there might be some snags with partition tables on Linux and
hot resizing. The 11.2 docs claim that ASM will only detect
partitions. ASMlib might negate that. Test first. :) I think that
this is really a great option for small and mid-size environments.
2) VolumeManager-based capacity management.
For very large/intensive environments I think this is the preferred
approach. Historically there was an OS-based dynamic volume manager -
but it's really best NOT to layer ASM on top of these. (I've had a heck
of a time convincing OS teams at large orgs about this!!) I think I
remember some places in the Oracle docs that reinforce this
recommendation too. ASM *is* a volume manager, best not to layer two
volume managers on top of each other. Makes troubleshooting a bear.
With VolMgr-based capacity management, you choose one or several
"standard" storage building-block configurations. For example, 50G
"type A" LUNs (where "type A" refers to a specific underlying disk
type). The storage guy only gives you storage in 50G chunks. If you
want a 2TB volume then you request 40 of them. The policy says that you
can't mix underlying storage types in a single volume/DiskGroup. At one
company I've worked with, they had gold, silver and bronze storage with
different chargeback rates. Clever naming scheme I think - and helped
app teams understand what they were requesting. :)
But for VolumeManager-based capacity management, you need a much better
grasp of your requirements so you can properly architect the
building-block configuration. There isn't one correct answer.
As far as underlying storage config -- I am a proponent of the BAARF
initiative, but otherwise I think you can work with the storage team and
let them be the experts. Make sure they know your stripe size. (Oracle
defaults to 1MB but explicitly recommends a 4MB stripe size in the 11.2
docs! And you can go bigger for DWs.)
Hope this helps a little,
Jeremy
Jeremy Schneider wrote:
> Sorry for the late response...
>
> This is not true. All LUNs do not have to be the same size in ASM.
>
> However, it is a best practice (and I have recommended it to people
> before). Mainly because it's quite easy to mess things up with ASM and
> storage if everything isn't the same in a diskgroup.
>
> But the actual important thing is not size - it's that the underlying
> storage is balanced. ASM stripes based on capacity. If two LUNS are
> the same size but one uses 7200 rpm drives and the other uses 15000 rpm
> drives, then this can cause difficult-do-diagnose performance oddities.
> (Not to mention different RAID levels!!) But if two LUNS are different
> sizes but both are RAID10 arrays of the exact same size/speed disks,
> then actually ASM will handle it quite well and the data will end up
> being spread evenly across all disk heads. There's storage network
> pipes to think about too, but that's not usually an issue because a
> single LUN typically is a small percentage of the traffic.
>
> -Jeremy
>
>
> David Robillard wrote:
>
>> Hello George,
>>
>> One thing to keep in mind with ASM is that all LUNs in your disk
>> groups must be of equal size.
>> So if you use, say, 100 GB LUNs with ASM. Then when your database
>> needs more storage, you'll need to add a 100 GB LUN to your disk
>> group.
>>
>> There was an interesting presentation on ASM on
>> http://www.oracleracsig.org. Do a search for %ASM% in the documents
>> section of the site.
>>
>> HTH,
>>
>> David
>>
--
http://www.ardentperf.com
+1 312-725-9249
Jeremy Schneider
Chicago
Other related posts:
