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.

First thoughts on the Oracle Database Machine in Australia

Well its been a little over 4 months now since i started been involved with the Oracle Database Machine or DBM as i will call it here. The DBM is Oracle's first foray into the hardware appliance market.

In this tough economic climate its no surprise that every organisation wants to drive cost out of the business, in the front end and especially at the back end. The DBM couldn't have arrived at a better time to the market for our customers, here is an appliance datawarehouse designed for massive throughput from loading data, executing queries and presenting the important business intelligence back to the business. Speed in everything is essential but speed alone doesn't reduce costs, the real value in the DBM is the fact its an appliance. This is underrated IMHO especially now in this economic cliamate.

This week i needed to re image my laptop, Oracle gives you the option of Linux or Windows and being a secret techno i thought i would give Linux a try. Now i used to dabble in Unix but it was 20 years ago, and i was hoping not to venture near the text based utility vi. Anyway Linux did install pretty easy, actually i was surprised but then when i wanted to tailor it with dual head display, tool bars, gadgets, desktop search and adobe air for tweekdeck (the coolest twitter app) i suddenly realised all is not what it seemed. Suddenly i was thrust upon with desperate searches to see how to install RPM/BIN and remembering syntax for commands that mean nothing to me like chmod, bash and sudo. Wow i cant tell you how many hours i have sat at home getting this just right. Its hard since building Linux desktops isn't my profession so i wasted a lot of time taking in the knowledge of configuring a Linux.

This now takes me back to the appliance concept and specifically the DBM. Customers initially look at this box and dont appreciate the sum of the parts is far greater than any bill of materials can suggest. The DBM contains 8xHP DL360's, 14 Exadata Storage Cells with 12 disk in each, Infiniband,Oracle Unbreakable Linux, Enterprise Edition Database, RAC and Partitioning. So if you wanted an new warehouse and went to the effort of procuring the hardware, software and then looked and building the hardware units, loading drivers, os, database, RAC and ensuring its all up to date you are talking abut serious hours here. And in reality for most organisations its months not hours because your never going to dedicate resourcing 100%.

In these economic times we need to look at efficiency and productivity closer than ever. IT departments are there to make sure the user community and the business have the tools at their disposal to be productive, to automate repeatable processes and build a secure and compliant infrastructure. Its such a drain on resources to build a linux desktop as in my case or to procure a crate of hardware and a library of software to build something when you can just plug in an appliance.

The DBM offers great value when you consider Oracle with HP has done all this work for you, you can then focus on getting the most out of your new datawarehouse with new queries for the business, better ETL performance and headroom to cover the expected growth when the world recovers.

So today i have just touched on the appliance value of the Database Machine, over the next few weeks i will look at what really makes this box scream. The "Secret Sauce" will be my next post when i will discuss how the Storage Cells in the Database Machine are accelerating customers queries by factors over x100 times.
 

The Oracle Database Machine