logo

Oracle has made great strides with Grid/RAC for databases. 10g Grid Release 2 with ASM has performed very well over the last year. It's caught on and many Egenera clients have seen its potential.  But one concern that many database and system administrators have is how the physical infrastructure complexity hurts the stability, scalability and flexibility of larger RAC environments. For example, to set-up a 50 node RAC, an IT organization must string an estimated 200 to 300 Network and SAN Cables together...the very definition of hairball! The resulting infrastructure complexity is not news to those who have experimented with Oracle RAC. Many organizations have purchased RAC but are using it simply for high-availability. They setup 2 nodes and if 1 node fails, the DB remains up. The organization is fearful to scale the RAC and set-up more than 2 nodes because of the growing infrastructure complexity. Once they get the RAC up and running, they're afraid to alter the number of nodes because of the long time to physical deployment and the potential for having the whole RAC fail because of mis-configuration.  I believe RAC adoption for databases has been slowed because of this and there are many naysayers out there. So, what does this all mean? The server platform holding the RAC node really DOES matter. Eliminate the "mess" and get on with achieving GRID. If organizations didn’t have to worry about the physical complexity of stringing boxes together they would setup larger RACs (more nodes) and would add or shrink capacity on-demand.  RACs wouldn't be deployed ONLY for high-availability but for the vision that Larry laid out for us at Oracle World.  When the database requires more horsepower, just add another node.  When it needs less horsepower, remove a node and use that box to run another application.  If you don't have boxes to add another node (many organization can't afford to have idle equipment lying around), order one from your hardware vendor and when it arrives take it out of the box, push it into the cabinet without any cabling, and add it to the cluster in less than 1 hour! Ok...so there's a catch.  Most hardware vendors that offer commodity boxes or blades don't have a solution that solves the physical complexity problem.  Some of the larger SMP machine vendors have solved this but large SMP machines don't make sense for RAC.  The whole TCO equation is lost.  For example, it doesn't make sense to set-up an 8 node RAC with 8 Superdomes.  This defeats the end goal of using commodity based boxes to create a large engine for databases.  Imagine needing to add a ninth node..."Boss, I need to buy another superdome...can you help?" Now there are a handful of vendors (shameless plug for Egenera), that have solutions to counter the physical complexity problem by consolidating IO and leveraging SAN and NAS infrastructure to the fullest.  We still use blades as do HP and IBM.  But, Egenera and Dell PAN blades are very different... For one, they're "stateless" and don't have all the legacy baggage that most blades have.  Most of the physical complexity associated with standard blades (white boxes shrunk into a smaller footprint) has been replaced by virtualization software.  Stateless blades can be virtually strung together and added to the cluster at the click of a button.  Stateless blades can be used to run MS Exchange on Windows one minute and Oracle RAC on Linux the next. So now instead of 300 cables for a 50 node RAC, you end up with 50 cables. After removing the physical complexity of an Oracle Grid by replacing the physical mess with software, clients have successfully setup double digit RAC Node environments and maximized their return on investment. Do you agree?  Weigh-in with your thoughts.