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
(http://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 :-)


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


Other related posts: