In a few weeks time I’ll be delivering a webinar about Oracle Exalytics. The goal of the webinar won’t be to encourage you to run out and buy an Exalytics server, but rather to educate the public on the pros and cons of Exalytics. As the EPM Infrastructure Practice Manager at CheckPoint, I and my team have been engaged with two of the largest ongoing Exalytics implementations in North America. We have a number of lessons learned about Exalytics and its surrounding technologies, such as ZFS and Exadata.
To grease the wheels for that webinar, I offer a two-part series of blog posts that will address a number of items the layperson might not know about Exalytics. This series will offer several points of interest that will lead and tie into the webinar. Without further ado, here are my first three ideas:
1. Exalytics servers save rack space, enabling clients with complex EPM environments to reduce the amount of hardware and data center bloat associated with commodity environments. Clients typically gain a dramatic reduction in the amount of hardware (and associated software) they need to manage and support. In the implementations we have been involved with so far, clients have seen a 70% reduction in the number of servers required to support EPM environments. With this reduction comes a comparable reduction in network complexity, storage allocations, server rack requirements and even support staff. Something we can all get our minds around pretty quickly are the hard costs involved. For example, Gartner has estimated for years that every single gigabyte of data that can be justifiably removed from the collection saves the company thousands to tens of thousands. With archetypal data storage running into the terabytes and petabytes these days, that savings could amount to millions for the typical sized company.
Having said that, Exalytics servers are REALLY big. Of course there are different flavors of Exalytics servers on the market. They range from the smaller X-series (LINUX) servers to the larger T-series (UNIX) variety. But, any way you slice it, these are larger hosts than traditional commodity hardware. Exalytics servers range from 72 CPU cores to 1024 CPU core threads, 2-4 Terabytes (TB) of RAM and 5-7 TB of Flash storage (with another 7-10 TB of traditional storage). They also possess high-end network capacity and all the redundancy you would expect enterprise class hardware to have. In fact, they’re so big that they’re not practical for some EPM deployments, certainly not for smaller scale clients, or even large clients with a small EPM footprint.
2. When approaching Exalytics, it is important to think about hosting multiple-environments, and/or multiple business segments on the hardware. This allows hardware to be centralized, but business segments to be decentralized. Having one Exalytics server offer separate Essbase instances to multiple business segments can reduce data center overhead (over completely separate EPM environments) while allowing business segments to manage and maintain unique business process timelines. This is possible because given the size and nature of Exalytics, they are typically carved into smaller units. These are termed ‘zones’ and essentially represent the virtualization of the larger Exalytics host. We have learned a lot of important lessons about Exalytics. The first is there is no need to architect it like a traditional EPM product architecture. In historical EPM architecture you would design a multi-server stack with the various EPM products (HFM, Planning, Essbase, etc.) spread-out over an array of servers. In Exalytics, this complexity is both unnecessary and unwarranted. We have found you are better off with a two or three zone configuration where all of the Java and Web-based EPM components reside on one node, and the other node or nodes are used for Essbase. This eases everything from deployment and patching to management and troubleshooting.
3. My third point is largely tied to my second, which is Exalytics deployments require some different thinking. What is different about Exalytics is all the ‘zones’ share the overhead host hardware unless it is specifically allocated and reserved at the operating system level. Since all zones share all of the available CPU and RAM of the host the effect is one of making a traditional EPM architecture unnecessarily messy and pointless. The one exception here is Essbase, which benefits from pinning the hardware to specific CPU/core limits. Architecturally speaking, the end result, depending on your high-availability requirements, your environment would consist of two to four zones, at most.
Tune in these next few weeks for the continuation of this discussion and more ideas about designing and living in an Exalytics world. Also be sure to sign-up for the webinar and bring your curiosity and your questions.