For most people, Oracle Exadata is synonymous with performance; many don’t realize that this is not the only natural symbiosis.
Oracle Exadata, since its inception more than a decade ago, goes further than just performance; Oracle Exadata on-premises or in the Cloud, being it ExaDB-D, ExaDB-C@C, Oracle Database@Azure or any Autonomous Database offers out-of-the-box benefits from a wide range of Maximum Availability Architecture (MAA) and High Availabilty (HA) features.
This blog post series will show you what the Oracle Exadata platform offers on the MAA and HA front and that “Hardware and Software Engineered to Work Together” is not just a slogan but a necessity to achieve world-class performance and reliability.
An Oracle Exadata machine is an engineered system specifically developed for Oracle Database workloads; it comes completely preassembled in an industry-standard rack and consists of compute nodes, storage servers, power distribution units, and network infrastructure, all connected with full redundancy.
Can I achieve the same with generic hardware?
At first sight, you might think that redundantly connecting standard generic servers, storage, and networking equipment will achieve the same, but do you remember the premisses “Hardware and Software Engineered to Work Together”?
Mixing and matching the standard of the shelf components will not only make you miss out on HA and MAA features that Oracle Exadata offers but also will make you end up with a very unique system; having a unique system in the IT world is never a good idea.
All these components come with device drivers and firmware and each layer has timeouts that need to be set; maintenance on these systems is not an easy task; each version update of drivers or firmware requires going through a certification list and requires you to do a lot of testing.
With Oracle Exadata, we take care of all this, and more importantly, we learn from the experience of thousands of customers. At Oracle, we have a dedicated team that loves to break things and see how a system behaves, the MAA team.
The Exadata MAA team has weekly meetings discussing observations at customers and in the field; these insights lead to added checks in the Exachk tool, recommendations, and improvements in the product. Since we know the full stack, those changes can be done on the Exadata software layer, Grid Infrastructure, or Database layer.
The following posts in this series will go over what makes Oracle Exadata so different and how Exadata solved a lot of issues in the area of HA and MAA; we do a deep dive component per component, we will start with the compute nodes, the discuss the storage servers and inter RDMA over Converged Ethernet (RoCE) switches and lastly show how Exadata prevents for human error and other extra features.
I would like to thank the great Mike Nowak from the MAA team for giving me the inspiration for this series and his input.
Further reading:
Exadata MAA detailed presentation
Other parts in this series :
More than Just Redundant Hardware: Exadata MAA and HA Explained – Introduction
More than Just Redundant Hardware: Exadata MAA and HA Explained part I, the compute node
More than Just Redundant Hardware: Exadata MAA and HA Explained – Part II, the Exadata Storage Cell
More than Just Redundant Hardware: Exadata MAA and HA Explained part III, RoCE Fabric / Human Error