Thanks, Tim. I will pass on the caution (that only Data Guard provides
true redundancy).
Iggy
------------------------------------------------------------------------
Date: Wed, 16 Apr 2014 11:51:54 -0600
From: tim@xxxxxxxxx
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Extended RAC and multicast
Sorry to press, but do you know if they had evaluated Data Guard or
Golden Gate at all? Did they really make such a decision based on a
single piece of sales collateral?
I'm always shocked at how Oracle Corporation (and other vendors) will
publish a white paper such as this, including a section on the
"benefits of
<http://www.oracle.com/technetwork/products/clustering/overview/extendedracversion11-435972.pdf#page=6&zoom=auto%2c93%2c519>"
without a balancing (and glaringly absent) "disadvantages of" section,
which might include helpful cross-references to Oracle products Data
Guard or Golden Gate. While there is brief passing mention of Data
Guard in this paper, there is not a breath about Golden Gate. A
"disadvantages of" section would have been the ideal way to steer
customers for whom "extended RAC clusters" were not well-suited toward
Data Guard or Golden Gate, both which are proven and widely
implemented, which "extended clusters" are not.
The presence of only positive information about a product without any
negative information ipso facto makes it a sales document, and
worthless as a technical source.
On 4/16/2014 11:30 AM, Iggy Fernandez wrote:
Hi, Tim,
The customer bought the story (in the Extended RAC white paper)
that Extended RAC provides some measure of Disaster Recovery (with
the emphasis on some). The white paper is at
http://www.oracle.com/technetwork/products/clustering/overview/extendedracversion11-435972.pdf.
"Unlike classic Oracle RAC implementations, which are primarily
designed as scalability and high availability solution that
resides in a single data center, it is possible – under certain
circumstances – to build and deploy an Oracle RAC system in which
the nodes are separated by greater distances. For example, if a
customer has a corporate campus, they might want to place the
individual Oracle RAC nodes in separate buildings. This
configuration provides a higher degree of disaster tolerance, in
addition to the normal Oracle RAC high availability, since a fire
in one building would not, if properly set up, stop the database
from processing. Similar, many customers have two data centers in
reasonable proximity (<100km) which are already connected by a
direct, ideally non-routed, high speed link(s) and are often on
different power grids, flood plains, and the like."
"Oracle RAC on Extended Distance Clusters does not constitute a
different type of cluster, neither is there a special installation
option that one can choose from. This means that as far as the
configuration of the system is concerned, the main goal is to hide
the fact that Oracle RAC is now operating over distance. On the
other hand, this means that the basic configuration remains the
same, including its requirements. Attention must be paid when
configuring the network and storage connectivity for Extended
Distance Oracle RAC environments."
Iggy
--
Iggy Fernandez
Email: iggy_fernandez@xxxxxxxxxxx <mailto:iggy_fernandez@xxxxxxxxxxx>
Cellphone: (925) 478 3161
Blog: So Many Manuals So Little Time
<http://iggyfernandez.wordpress.com/>
Author of Beginning Oracle Database 11/g/ Administration
<http://books.google.com/books?id=pdSLnG66WQkC&printsec=frontcover#v=onepage&q&f=false>
Editor of the /NoCOUG Journal <http://bit.ly/rC2gRA>/
Lecturer at University of Washington Professional and Continuing
Education <http://www.pce.uw.edu/biography/ignatius-fernandez/>
------------------------------------------------------------------------
Date: Wed, 16 Apr 2014 09:36:25 -0600
From: tim@xxxxxxxxx <mailto:tim@xxxxxxxxx>
To: oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx>
Subject: Re: Extended RAC and multicast
Iggy,
Not to open any cans of worms (and please feel free to not answer
this question for any reason), but why did they choose an
"extended RAC" deployment in the first place, as opposed to any of
the Data Guard options? Do they already use Data Guard? Was
there something that "extended RAC" (or "geographically-dispersed
cluster" technology) does better than Data Guard (or database
replication technology) in general?
Just curious...
Thanks!
-Tim
On 4/16/2014 9:21 AM, Iggy Fernandez wrote:
Thank you very much Martin.
We found additional information on the multicast requirement
at the following link:
http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/UCS_CVDs/cisco_ucs_oracle_rac.html#wp439295
Kindest regards,
Iggy
--
Iggy Fernandez
Email: iggy_fernandez@xxxxxxxxxxx
<mailto:iggy_fernandez@xxxxxxxxxxx>
Cellphone: (925) 478 3161
Blog: So Many Manuals So Little Time
<http://iggyfernandez.wordpress.com/>
Author of Beginning Oracle Database 11/g/ Administration
<http://books.google.com/books?id=pdSLnG66WQkC&printsec=frontcover#v=onepage&q&f=false>
Editor of the /NoCOUG Journal <http://bit.ly/rC2gRA>/
Lecturer at University of Washington Professional and
Continuing Education
<http://www.pce.uw.edu/biography/ignatius-fernandez/>
------------------------------------------------------------------------
From: martin.a.berger@xxxxxxxxx <mailto:martin.a.berger@xxxxxxxxx>
Date: Mon, 14 Apr 2014 20:46:39 +0200
Subject: Re: FW: Extended RAC and multicast
To: iggy_fernandez@xxxxxxxxxxx <mailto:iggy_fernandez@xxxxxxxxxxx>
CC: oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx>;
kulkarniravi@xxxxxxxxx <mailto:kulkarniravi@xxxxxxxxx>
Iggy, Ravi,
from all my test I call multicast a requirement from 11.2.0.2
onwards.
Take care about the different Multicast networks possible in
different Patch-Sets!
As you are talking about VLAN_S_ - I'd not do anything than
pure switched private network. Everything else will lead to
troubles sooner or later.
My .02€
Martin
On Mon, Apr 14, 2014 at 8:29 PM, Iggy Fernandez
<iggy_fernandez@xxxxxxxxxxx
<mailto:iggy_fernandez@xxxxxxxxxxx>> wrote:
A friend asked me a question that I could not answer. He
is in the planning stages of an "extended RAC deployment"
and is looking for confirmation that multicasting is optional.
Help would be appreciated.
Kindest regards,
Iggy
--
Iggy Fernandez
Email: iggy_fernandez@xxxxxxxxxxx
<mailto:iggy_fernandez@xxxxxxxxxxx>
Cellphone: (925) 478 3161
Blog: So Many Manuals So Little Time
<http://iggyfernandez.wordpress.com/>
Author of Beginning Oracle Database 11/g/ Administration
<http://books.google.com/books?id=pdSLnG66WQkC&printsec=frontcover#v=onepage&q&f=false>
Editor of the /NoCOUG Journal <http://bit.ly/rC2gRA>/
Lecturer at University of Washington Professional and
Continuing Education
<http://www.pce.uw.edu/biography/ignatius-fernandez/>
------------------------------------------------------------------------
Date: Mon, 14 Apr 2014 11:13:03 -0700
From: kulkarniravi@xxxxxxxxx <mailto:kulkarniravi@xxxxxxxxx>
Subject: Extended RAC and multicast
To: iggy_fernandez@xxxxxxxxxxx
<mailto:iggy_fernandez@xxxxxxxxxxx>
I am looking to setup extended RAC for my client. The
details are as following:
The two data centers are separated by a distance of less
than 20 miles.
They are connected by a high speed dedicated connection.
Operating System: RHEL 6 64 bit
Database version: 11gR2 (11.2.0.3)
Hardware: Four servers with 4x16 configuration
All the documentation I have reviewed so far says
multicast should be enabled on the private interconnect
between all the nodes
of a RAC database. However, my network resources tell me
that multicasting is not enabled across the data centers
and VLANs
do not span across the data centers. The only reference I
have seen to multicasting requirement is in this Oracle
document:
http://docs.oracle.com/cd/E16655_01/install.121/e17888/networks.htm#CWLIN476
Specifically it makes the following assertion:
"You do not need to enable multicast communications across
routers"
Does this mean, multicast is optional?
Regards,
Ravi Kulkarni
