RE: To use SAME or NOT for High End Storage Setup ?
- From: "Kevin Closson" <kevinc@xxxxxxxxxxxxx>
- To: "Oracle-L" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 11 May 2006 08:45:11 -0700
>> Do vol mgr's nowadays have the ability to "rebalance" the volumes ala
>> ASM to avoid this? And if so, presumably you're still up for a nasty IO
>> spike whilst it occurs ?
Great question. Sadly, few will read this response.
The challenge of accommodating "adding a few more disks" to a huge
diskfarm is valid, but the topic was S.A.M.E. I say any technology that
addresses the need to occasionally add some disks and rebalance (ODDR) should
do so...while maintaining the SAME methodology.
ODDR (online dynamic data re-distribution) and any associated "rebalancing"
I/O spike is not a fundamental problem with ODDR...it is an implementation
detail. It seems the only ODDR technology you have exposure to is ASM.
If you aren't happy with how ASM does it, just be happy that
ASM can't do ODDR for, say, Petabytes of flat files ala bio-informatics,
seismic,
etc...
Do volume managers do rebalancing? They always have, at least all the ones
I've worked with. You change the geometry of one of the mirror plexes and
resilver, but that is crude. However, while it may be crude, it works for
ANY and ALL data and ASM doesn't. Some people have mentally ascended to accept
the fact that not all of the worlds data goes into any (more less Oracle) RDBMS.
In fact, by good estimate, only 15% of it does.
Solving the problem of ODDR is not an Oracle problem. If you choose the ASM
approach
to solving this problem, you will eventually have to figure out how to do it
for all the other data in your datacenter. That is why a general purpose
approach
is better in the end.
I'll use our products as an example. We support online volume growth and online
filesystem growth. Our upcoming release will support ODDR and much more
storage QOS technology than ODDR. ODDR is a hammer when a scalpel is more often
needed. I'll explain (chirp chirp, you can hear a cricket chirp, the room is
silent and empty).
If you have data in a 100 disk volume and add 5, you have added 5% capacity
(provided all are the same size), but did you add 5% bandwidth? Most likely not.
The 5 disks are likely behind the same overloaded array controller so you
really are just talking about 5% more round-brown capacity. The question
becomes whether it is actually smart to redistribute for the sake of 5%
capacity addition. What if, on the other hand, the 5% capacity you added
was from some newer generation storage or device type that was, say, 300%
faster than the old 100 drives? Do you want to do a generic ODDR? Or
pick out the hardest hit data and ODDR it?
It goes like this, just because ASM has some RAID characteristics, that
doesn't make it a volume manager. Likewise, just because it stores
"files" that doesn't make it a filesystem. Finally, just because it
has rudimentary ODDR, it is not storage QOS.
PolyServe QOS will not be done in the volume manager anyway. Storage
QOS is best implemented in the filesystem level. Ours will certainly
support ODDR, but more importantly it will support adding different
storage speeds to an existing volume and the ODDR action will be to
redistribute data that actually would benefit by being redistributed.
And, all this for all files. Not just thingies that comprise an
Oracle database.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
