RE: RAC and ASM disk layout

  • To: <kevinc@xxxxxxxxxxxxx>, "Oracle-L Freelists" <oracle-l@xxxxxxxxxxxxx>
  • Date: Mon, 12 Jun 2006 15:16:29 -0400

The NVRAM is active in iSCSI environments for exactly the reasons you
described - an iSCSI target is really just a filesystem file that's
exposed, which does create a whole slew of useful functional pieces.
For example, if you want to back up all of your Fibre Channel and iSCSI
LUNs, you can do so over nfs with a snapshot, etc.

And the iSCSI thing was probably due to using the the full-stack offload
cards, which can make a big performance difference.  We've just started
doing some testing with NFS and the TOE components of those cards, so
we'll see if anything interesting bubbles up performance wise.

I actually really like the NetApp model - its very easy to manage, very
flexible, and the multi-protocol piece works great for us.  We have
several hundred systems (mix of real and virtual) that use netapp as
their storage in our development lab.  With Netapp, we can expose the
same data via fibre channel, iSCSI, and NFS, so we can easily distribute
storage resources among the different environments.  And the WAFL model
is one that is tried-and-true, in that its strengths are well-known, its
weaknesses are pretty-well documented at this point (though they've been
mitigated in OnTap 7).  Because of that, you can expect consistent
results across different versions of OnTAP, and different netapp
hardware platforms.  Compare that with HP, HDS, EMC, where different
families of products (of course) have vagaries, but there are even
fundamental shifts between revisions within the same family.

Thanks,
Matt

--
Matthew Zito
Chief Scientist
GridApp Systems
p: 646-452-4090
mzito@xxxxxxxxxxx

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Kevin Closson
Sent: Monday, June 12, 2006 2:39 PM
To: Oracle-L Freelists
Subject: RE: RAC and ASM disk layout

 
        
        If anybody wants all the bugs out of a product (in this case
ASM) before using it, then let's throw all our softs out the window. If
you look at any patchset (10gR1 or 10gR2), how many patches you find for
ASM, compared to, let's say, CBO? and every body uses CBO. 

... all software has bugs. Not all bugs are created equal. Some are
bourne out of architecture...some are errant pointers... judge according
to your conscience.

        Another point about performance: Netapps say that if you use ASM
with iSCSI configuration to go to their disks, it's faster than using
NAS (NFS mount the disks). They did the tests, not me. So, if you can
live with it, ASM is the way to go. 

...bwahahahaha..that is likely because iSCSI is a lighter protocol than
NFS. I also suspect that the NVRAM might not be active when a filer is
an iSCSI target (somebody in the know please corect me on that point).
In general, however, iSCSI from a Netapp filer is a really weird
situation. I know very few people on this list care about such
subtleties, and thus very few realize that the way NetApp presents an
iSCSI target is as follows. The data is stored in blocks in disk, the
disks are grouped and managed in volumes, the volumes have a WAFL
filesysem with files in it. The Filer presents the files as blocks via
the iSCSI protocol...hmmm..

block->volume->filesystem->block->iSCSI

yippie


--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l


Other related posts: