RE: RAC 10.2 + Sun Cluster 3.1 + QFS
- From: "Kevin Closson" <kevinc@xxxxxxxxxxxxx>
- To: "oracle-l" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 8 Jun 2006 10:20:02 -0700
>>>>Am I correct? Could I use QFS for Oracle datafiles as well
as flash recovery area? If yes, is there a perticular reason to choose
QFS over ASM beside eaiser file management?
...Sun should be answering this, or you can see it in Oracle's words
here:
https://metalink.oracle.com/metalink/plsql/f?p=140:1:156324369626265908
but read on...
Since you are going with Sun Cluster, at least you wont get Oracle's CRS
ATONTRI
(//www.freelists.org/archives/oracle-l/05-2006/msg00834.html),
but you still have to live with braindead SCSI-III Persistent Res for
"fencing" (which isn't fencing at all really). Better than systems
getting
rebooted for lack of anything better to do I guess. Still not very
robust.
As for a CFS, over ASM, well, it depends on how much risk and change
you want to pile into one basket. To a lot of "real datacenters" with
organizational structure, ASM presents concerns.
To system and storage administrators, ASM is a "black box". Unless the
sole usage for
storage in the datacenter is Oracle, and therefore the storage
administrators rely
entirely on Oracle space utilization tools such as Enterprise Manager ,
they
cannot even detect when ASM space is approaching full capacity. A simple
glance at df(1) or third party systems management tools are no longer
sufficient.
So, if there is an unplanned space requirement, the DBA has to ask the
storage administrator for another "chunk of raw disk" to add to ASM.
This
in turn makes the storage administrator take action in a sort of
emergency
reactive mode. The system administrator in turn has to perform the OS
level
configuration and discovery naturally involved with making a raw chunk
of
disk available to an application.
If database administrators are not perfect in their ability to project
future
space requirements, they will make routine, troublesome, last-minute
requests
for storage-not the most harmonious operating conditions by any means.
Contrast
this to the storage model of a cluster filesystem. The storage and
system
administrators have RAC storage utilization levels within plain view
using
the same monitoring tools and methods they use for all the other
applications
they support. Oracle is a very important application, but storage and
system
administrators have a great deal more to think about. Provided the CFS
you
choose is online resizable, storage and system administrators can add
space to
CFS without the database administration staff ever picking up the
telephone.
Action always yields better results than reaction.
There are also a lot of files that must go in shared disk that cannot be
placed into ASM. Some datacenters strive for standardization. Clustered
environments can be confusing enough as it is so changing both the
fundamental
way databases are stored and limiting the effectiveness of the storage
group
in one fell swoop can lead to disaster.
Oracle databases have consisted of filesystem files for nearly 30 years
and storage administrators need to have control. It is for this reason
that datacenters are increasingly choosing to deploy RAC onto CFS
solutions such as PolyServe on Linux/Windows or in your case QFS.
A real CFS (Like QFS or PolyServe and must unlike OCFS1 and Sun GFS)
support
locating ***all*** Oracle files into the cluster filesystem.
Without a general purpose cluster filesystem, applications that use such
features as External Tables, BFILE, and UTIL_FILE will not function the
same, or not at all, with RAC. Administration is simplified as well
since
there is no need to navigate between servers to access ORACLE_BASE
directories
for logging, trace, scripts and so forth. The idea behind a RAC
deployment
on a general purpose cluster filesystem is to get more of a "single
system
feel", which is an important characteristic to a lot of datacenters.
The problem I have, and I still hold a grudge, is that all those
"misfire" CFSs like Sun GFS (proxy) and OCFS1 (not really a filesystem
at all, just a datafile container), Sistina, Lustre, etc is that
they create confusion in the marketplace. Look, people that are
serious about cluster filesystems don't like it when providers
say they have a cluster filesystem then footnote the thousands
of things their CFS diesn't support because it is not POSIX complain
and/or it is architected with a braindead first-to-market approach
like master/slave metadata and lock managers. So when a company (
like PolyServe) that builds a CFS from the ground up to be a real
CFS, battles must be fought against misperceptions. I hate
battling misconceptions and predispositions. That is me,
now you know why I'm crabby sometimes :-)
--
//www.freelists.org/webpage/oracle-l
Other related posts:
