Chris,
You do not need ASM for OCR and voting disks. These can be on a supported
cluster file system or over standard NFS.
You are correct that ASM disk groups are all or nothing for storage
snapshots. However, it is not necessary that each database be in its own
disk group. For example, I have two databases in the same disk group, I
snap the storage of that disk group, mount it up to another server and just
delete the files of the other database. This way, you've reduced the
management overhead and used the space more efficiently without using any
extra space or losing the ability to do snapshots. This addresses points 2
and 3.
It is unclear to me why storage snapshots for ASM disk groups required you
to use RDMs. Could you not snap multiple VMDKs at the same time?
All that being said, dNFS has lots of benefits over ASM as well and as I
assume you were alluding to, is not mutually exclusive to ASM. NFS in
general is obviously much more flexible than ASM including the ability to
use CloneDB.
Don't forget that you have a third option which may include just enough of
either option to be worth trying, ACFS.
Seth Miller
On Tue, Feb 23, 2016 at 9:35 AM, Ruel, Chris <Chris.Ruel@xxxxxxx> wrote:
This is sort of long so bear with me…
*TL;DR:* *Who has compared ASM vs. dNFS (not used together) and what did
you choose and why?*
I was wondering if anyone on the list has opinions on, or has evaluated,
ASM vs. dNFS in a mutually exclusive configuration for
datafile/arch/ctl/redo storage?
We have been using ASM on NetApp over fiber channel for many years now
with great success. We particularly like the ability to add/remove
spinning disks or SSD on the fly. We can even "upgrade" our filers with no
down time by adding in and removing LUNs and letting ASM do it's rebalance
thing.
Recently, some new technology changes have become available for us. These
changes are in the form of moving our compute platform to UCS/Flexpod
environments and the introduction of VMware. Operating on the UCS gives us
access to 10gE (currently our infrastructure is primarily 1gE) which brings
the option of using dNFS to the table.
Now, I am just starting down the path of comparing the two for pluses and
minuses and I do not have all the data yet. Thought I would reach out to
the list.
There are a few things that attract us to dNFS:
1. Less complication…maybe? In RAC environments, I still think we
need ASM for OCR/Voting…someone correct me if I am wrong. But, we will not
have to manage ASM disk groups like we do now. However, after so many
years of using ASM, our team is pretty well versed in it…so, is it really
an added complication?
2. Better ability to use NetApp snapshots:
a. We can do file level recovery with dNFS which cannot be done
with ASM
b. Right now we have to manage separate disk groups for each
database (when we have multiple databases on a node/cluster) if we want to
use NetApp snaps since restore is done all-or-nothing at the disk group
level. In some cases, we have hit the maximum number of disk groups (63)
in ASM. I think multiple disk groups like this also results in more
overheard managing and monitoring. Furthermore, more disk groups seems to
waste more space as it is sometime hard to predict storage needs…I think in
the end the best approach is to over allocate storage instead of having to
manage it constantly.
3. Our primary OS platform is OELinux x86-64. Linux has a LUN path
limit of 1024. That sounds like a lot, but, with multiple LUNs per disk
group and multipathing in place, each disk group takes up a minimum of 8
LUNs. This is not to mention LUNs supporting the OS and shares. Since we
need to have separate disk groups for each database to support snaps, a
cluster with a lot of compute power will either hit the LUN path limit or
the ASM disk group limit before we run out of compute. My understanding is
that we do not have this limit problem with dNFS.
4. It seems that dNFS will lend itself better to VMware:
a. Setting up snaps with ASM on VMware led us down the path of
using RDM's (which have limits feature wise) instead of VMDK's.
b. VMDK's with dNFS seems like less configuration which will allow
for quicker provisioning on VMware. VMDK's are also the preferred approach
according to VMware.
c. Using ASM and LUNs with VMware still is an issue with the 1024
LUN path limit. However, it moves to the physical hosts in the ESX
cluster...not just the guest OS. Therefore, we are seriously limiting the
number of guest OS's on our ESX clusters before we run out of compute
because will hit the LUN path limit first.
So, that's it in a nutshell. I am sure there is a lot more to it but I
appreciate any input people may have.
Thanks,
Chris..
_____________________________________________________________________
Chris Ruel * Oracle Database Administrator * Lincoln Financial Group
cruel@xxxxxxx * Desk:317.759.2172 * Cell 317.523.8482
Notice of Confidentiality: **This E-mail and any of its attachments may
contain
Lincoln National Corporation proprietary information, which is privileged,
confidential,
or subject to copyright belonging to the Lincoln National Corporation
family of
companies. This E-mail is intended solely for the use of the individual or
entity to
which it is addressed. If you are not the intended recipient of this
E-mail, you are
hereby notified that any dissemination, distribution, copying, or action
taken in
relation to the contents of and attachments to this E-mail is strictly
prohibited
and may be unlawful. If you have received this E-mail in error, please
notify the
sender immediately and permanently delete the original and any copy of
this E-mail
and any printout. Thank You.**
