The Joys of MAA...

Oracle's Maximum Availability Architecture


Greetings All,

This is my first post for the Red Room. My name is David Centellas and I'm a field consultant specialising in Oracle Database and options with Maximum Availability Architecture and Datawarehousing on the side. I recently had the pleasure of sitting through a presentation given by Alex Gorbachev (MD of Pythian Group) at InSync '09' at the Hilton hotel in Sydney. Alex touched on some key points that many clients are asking today; mainly around Maximum Availability Architecture, Dataguard and Automatic Storage Management.

Here is a snippet in case you missed it:



One of the most interesting points that Alex pointed out was the uptake of Extended RAC into 'production' at client sites. He does go on to say it is a fairly advanced configuration; however it is working and working well in production. I thought I would take a bit of time to chat about what to think about when thinking about an Extended RAC. Here are some guidelines that need to be taken into account. As usual priority should be given to the following Oracle Best Practices in the implementation of such architectures and as Alex mentions in the video “Identifity what you really need for your business or organisation.”

Steven Chan had a really good diagram of MAA on his blog:

http://blogs.oracle.com/stevenChan/images/maa-target-architecture.png


All we would have to do is think of Extended RAC as an extension of the “Database Tier”. All the rest of the principals remain the same. http://blogs.oracle.com/stevenChan/

As mentioned by Alex “The hardest part (is) as you separate the datacenters, the latency between the site(s) increase and this is where the challenges are coming from.” Network latency is one of the biggest issues when coming to extended cluster type scenarios however there are other rules of thumb that need to be addressed;

i) Extended RAC over distances of 10-20 KM's are possible without being project inhibitive (cost of a fibre link is another story ;)). It's not to say longer distance Extended RAC's are not possible, there are some customers with Extended RAC's over 50 KM's in distance, however there are specific measures and QOS in place to ensure this configuration is viable (as well as the use of Dark Fibre technologies for maximum throughput).

ii) Redundancy is key! Make sure there is never a single point of failure, this includes the remote link! Dual NIC's, multiple RAC nodes, Disk redundancy, power redundancy, UPS, etc...

iii) Amount of Data? Is the amount of changing data too much for the link to keep up with? If we get this one wrong then you will forever be chasing your tail trying to catch up with the primary RAC.

As Alex mentions “Try to be as simple as possible” in architecting such solutions.


Let's not forget:

1 Gbit
= 1 000 000 000 bits /sec
= 125 000 000 Bytes /sec
= 119.209 MegaBytes /sec

This is the theoretical limit of gigabit, however real world scenarios usually show a significant impact of up to 50% on this theoretical limit. Calculate Calculate Calculate. I remember I was at a client site couple of years back trying to diagnose a throughput problem that was occurring on the systems. We bet the pizza we had ordered (was about midnight in a government department in New Zealand) on what was the cause of the problem. I threw up that it was a gigabit bottleneck and he threw up that it was Hard Disk latency.

At the end of the day we performed our calculations and figured out it was a big of a mixture of both so we split the costs of the pizza; however this points out one of the classic schools of thought that ‘there’s no way we’ll be flooding a gigabit link’ and now I see it most of the time.

Breathing Life into Applications with Middleware

Oracle recently published a special report on what strategies business can explore in uncertain times.

I would like to add further commentary on what the authors stated.

Businesses have, for the most part, invested heavily in acquiring and building applications to assist them in driving business efficiencies. With the widespread adoption of ERP though, I feel that differentiation has begun to fade. So maybe the question we could ask ourselves is, what can we do today to deliver rapid value, utilising existing applications investments, and provide a sustainable platform for future growth? In addressing the challenge above, a number of key organisations I know of are reevaluating the role middleware performs in their architectures. They have achieved remarkable short-term results in areas such as consolidation and business process efficiencies, while at the same time underpinning their broader business transformation strategies.

Cost reduction through consolidation is high on the priority list of CIO’s. Adopting a service-oriented approach can support application consolidation. By identifying key business services delivered by existing applications and key processes that will drive business value, organisations can determine which of their applications they can retire, retain, or build out to agile composite applications.

Replacing expensive and unmanageable point-to-point integration with reusable services can further reduce architectural complexity and associated costs, allowing for more effort and funding to be injected into projects that would contribute towards the differentiation of the business.

In the longer term, application upgrades prove to be costly due to the level of customisation and extension conducted during its lifespan. Moving an application to a major point release could cost 20% (see document under whitepapers) of the original implementation cost. Performing customisations in an upgrade resilient services layer supports application upgrade pain reduction!

To hear more about how middleware can support and enhance your applications investment, our Oracle Australia team, together with our customers, will be delivering sessions at this years Oracle User Group in Sydney on the 20th and 21st April. I will be there too! Together will Debra Lilley, an Oracle ACE from the UK, we will discuss and demonstrate how businesses can use process management to facilitate transformation and how easy it is to extend your Oracle applications using Oracle BPEL Process Manager. See you there!