Re: DB Appliance
Date: Sat, 10 Mar 2012 21:14:31 +0000
Message-ID: <CAP=5zEj0KQbrtrKLNKCki=PhQNjotxHB_Lu+ox4GrbVUQeGrXA_at_mail.gmail.com>
We are discussing a particular piece of kit (the ODA). It is a RAC enabled bit of kit and can not be expanded beyond it's built-in two-node setup. That instantly sets the context and boundaries for discussions about HA and DR. It's a bit like me talking about cars and you launching into a discussion about space flight. :)
I don't doubt that the terms HA and DR can be discussed in many different contexts, each altering or removing the line between them, but the context has been set by the kit in question. :)
My point is, if someone is discussing ODA, my mind doesn't instantly turn to designing a multi-datacenter grid solution to support an infrastructure the likes of Amazon or Google would require. :)
In the context of ODA, I think it is a HA solution, but certainly isn't a DR solution. In the context of ODA, I would consider a datacenter failure a disaster situation. Is this a definition that applies to all contexts? Definitely not, but I think it's a pretty safe bet in this context. :)
Cheers
Tim...
On Sat, Mar 10, 2012 at 7:16 PM, Gaja Krishna Vaidyanatha
<gajav_at_yahoo.com> wrote:
> Hi Tim,
> Although the subject line reads - DB Appliance, what I am about to share here is not specific to it. It is more widely applicable. But I do want to address what you shared in your first paragraph.
>
> To Niall's defense, I think the whole definition of HA has changed dramatically since the advent of Cloud Computing. These days data center going down can be considered as an HA issue depending on the context. For example, an organization that utilizes geographically distributed clouds, can have 4 data centers in the mix, 2 on each coast of the US. So, think of US-East-A and US-East-B, which are considered co-locations and are say within 100km apart from each other. And a similar setup for the West Coast, 3000 km away - US-West-A and US-West-B which are co-locations, again within 100km of each other. And for the purposes of our discussion, let's assume that the East Coast is the Primary Region and the West Coast is the DR Region. Data Centers A & B are connected to one another using dark fiber and the network latency is very low (1-5 ms). The above setup is similar to what Amazon EC2 has to offer.
>
> It is imperative that we are talking about 4 independent databases here (2 in each region). Now, when we talk about HA, it is between the US-East-A & US-East-B data centers. The complete disaster of EITHER Data Center A or B, does not cause a DR event. DR is engaged ONLY when BOTH A & B are unavailable. Stretch RAC/Extended RAC is not a viable option due to its high sensitivity to network latency and the inevitable node evictions and the performance aftermath that ensues on the slightest network hiccup. Stretch RAC is really suited more for a campus type implementation for some very specific applications when the data centers are close (say within 10km of each other). The databases in A & B on either region is kept in SYNC using standard replication methods available in Oracle - Active Data Guard in Maximum Protection Mode. The concept of cross-data-center-HA here is without Oracle RAC. In fact, RAC is not even required within the same data center,
> as a server failure in A can automatically failover to the database in B. This design is fundamentally simpler as the 4 databases in question can be single-instnace databases and with a simple yet intelligent network routing between A & B. This setup can (and has) provide (provided) very high levels of uptime (yes 5 nines). I realize that there is much detail that is not covered here, but I wanted to give you another perspective on the subject nevertheless.
>
> Cheers,
>
> Gaja
>
>
> Gaja Krishna Vaidyanatha,
> CEO & Founder, DBPerfMan LLC
> http://www.dbperfman.com
> http://www.dbcloudman.com
>
> Phone - +1-650-743-6060
> http://www.linkedin.com/in/gajakrishnavaidyanathaCo-author:Oracle Insights:Tales of the Oak Table - http://www.apress.com/book/bookDisplay.html?bID14
> Co-author:Oracle Performance Tuning 101 - http://www.amazon.com/gp/reader/0072131454/ref=sib_dp_pt/102-6130796-4625766
> Enabling Cloud Deployment & Management for Oracle Databases
>
>
> ________________________________
> From: Tim Hall <tim_at_oracle-base.com>
> To: "niall.litchfield_at_gmail.com" <niall.litchfield_at_gmail.com>
> Cc: "fuadar_at_yahoo.com" <fuadar_at_yahoo.com>; "mayurpnagarsheth_at_gmail.com" <mayurpnagarsheth_at_gmail.com>; "jreid_at_braintreegroup.com" <jreid_at_braintreegroup.com>; "oracle-l_at_freelists.org" <oracle-l_at_freelists.org>; ora_kclosson_at_yahoo.com
> Sent: Friday, March 9, 2012 2:17 AM
> Subject: Re: DB Appliance
>
> Niall: I slightly disagree with your High-Availability (HA) point, but
> on a terminology issue.
>
> RAC is a HA solution. It is meant to cope with a server going down. A
> data center going bang is not a typical HA issue. It is a disaster
> recovery issue. Unless you are using a stretch cluster, then RAC is
> not really a disaster recovery solution full stop.
>
> With this in mind, I think the claim that ODA is a HA solution is
> valid*. It is most definitely not a disaster recovery solution. If you
> need that, you are going to have to buy more hardware and consider a
> solution like Data Guard or DBVisit Standby etc.
>
> Now I know some people use the term HA to mean different things, which
> is why I said I "slightly disagree". :)
>
> * Complexity is the enemy of high-availability. RAC is complex,
> therefore RAC != HA. :)
>
> Cheers
>
> Tim...
> --
> http://www.freelists.org/webpage/oracle-l
> --
> http://www.freelists.org/webpage/oracle-l
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Sat Mar 10 2012 - 15:14:31 CST