In the previous part of this blog series we shared three little known points around Exalytics. These discoveries were learned while implementing some of the largest North American deployments of Exalytics. These blogs are meant to be the precursor for a webinar around the entire topic of Exalytics. You can find the first blog here, the following four points are the second part of our open discussion.
4. Tuning an EPM environment is always part science and part art, and that really doesn’t change in an Exalytics world. In particular, we’ve found that addressing the Java Heap sizes for EPM applications is not as straightforward as you’d expect for a 64-bit environment with scads of hardware behind it. Our initial approach was to assign large amounts of RAM (say 32 GB) to each application process, and see where things went. Over time, we came to realize that this resulted in less than optimal performance, especially at the point of garbage collection. Garbage collection of large JVMs leads to significant delays and performance hangs. The conclusion: ‘less is more’ and reduce JVM Heap sizes to 8-12 GB levels. If more horsepower is needed for user concurrency, it is probably time to think about a vertical deployment for the product in question (such as Financial Reporting components or Planning).
5. Think about using shared NAS, SAN or ZFS for all common deployment components. In a clustered world, this shared disk infrastructure is a requirement. However, it can also be useful for purposes such as backup/recovery and disaster recovery. Some areas where this can be critical are the Reporting and Analysis RM1 folder, the FDMEE Application folders, the LCM folder and the Essbase ‘ARBORPATH’ location. In addition, a shared location will allow for clustering to be added-in at a later date with less configuration headache, and allow for easier end-user access as network shares. Since most end-users are on Microsoft Windows client systems, this can relieve the need for additional file-transfer and management software.
6. Avoid naming conventions that denote directories. It has become an EPM wide standard in System 9 and beyond to frequently rename the ‘epmsystem1’ folder and other directories to match the environment or host. As such you would see folder structures that looked like /company/dev/fdmee and /company/prod/fdmee. While naming conventions are handy to know which environment you may be working in, and potentially modifying, they can make scripted processes very problematic. We have found it is better to use generic names and paths. Naming the directories /company/fdmee across all environments is handy and modifying them in this way allows scripted components to move seamlessly between environments, cutting down on the amount of custom code needed to manage a system. This tends to impact two areas in particular: scripts used to run infrastructure processes (log rolling/maintenance, service/daemon startup, LCM backup processes, etc.) and data integration processes (ODI scripted processes, FDMEE scripts, etc).
7. Lastly, depending on your product set for EPM, you may not be done with Microsoft Windows Server as part of your deployment. There are still a number of products that still require Windows Server in the EPM stack. Perhaps the most notable are Enterprise Performance Management Architect or EPMA (still required for the EPMA Dimension Server), Data Relationship Management or DRM (still based on an IIS and ASP engine) and Hyperion Strategic Finance or HSM (still completely bound to Windows Server for all layers of it’s architecture).
Diving into an Exalytics world involves a lot of comprehensive planning. These lessons are the tip of the iceberg, so please join me for the upcoming webinar to learn more about Exalytics and how it can help reduce your company’s IT footprint, accelerate your ROI, reduce TCO and potentially improve your performance.