The Looming Challenge

Grid computing figures prominently in the IT agenda of most organizations today, embodying a cost-effective compute paradigm that virtualizes heterogeneous system resources such as CPU, memory and storage to meet the dynamic needs of critical business applications. The spectrum of business applications planned for Grid deployment range from batch processes such as overnight risk calculations in investment banks or numerical analyses in life sciences research to more real-time applications like client exposure/risk modeling in capital markets or fraud detection in telecom. More recently, Grid computing has also been considered in transactional environments like J2EE application servers. While the hype and noise about the promise of Grid computing has been significant, real-world deployments have not always been smooth. An August 2005 report by the 451 Group's Grid Adoption Research Services (GARS) revealed that many large enterprises have delayed broadening their Grid deployments due to limitations in data management capabilities. This is not a total surprise when one recognizes the fact that the word “grid” very often refers to a compute grid with no explicit reference to data semantics. As such, data management is typically an afterthought in many of these deployments.

A typical grid workflow is illustrated in Figure 1. Tasks from grid clients are received by a grid scheduler, which then routes and manages these client requests on a set of compute nodes. The compute nodes in turn access the necessary information from backend data sources. The challenge with most grids is that the computations supported by them are fairly data intensive and have to be executed with a high degree of parallelism, such as Monte Carlo simulations for options pricing and risk analysis in capital markets. Often times, there is also a need to share intermediate results between a set of interdependent grid tasks. Traditional data sources like databases or file systems are disk-based and can neither guarantee low latency nor handle concurrent loads from grid nodes in a scalable fashion. Further, data sharing is also extremely cumbersome with such data infrastructures. Grid implementations like Globus (www.globus.org) offer mechanisms like GridFTP and Global Access to Secondary Storage (GASS), but these do not address the real-time requirements of a grid, instead catering more to large volume data movement and batch replication. As a result, most enterprise grid deployments suffer from data latency, scalability, consistency and quality of service issues. While these issues are seldom noticeable in small-scale pilot deployments (10-20 nodes), the moment an organization plans a grid expansion both in functionality and scale (hundreds of nodes), such data management issues become painfully obvious. To combat these issues, firms today must recognize the need for an advanced and innovative data architecture.

Figure 1: A typical grid architecture

Enter EDF – Enterprise Data Fabric

Over the last 25 years, compute applications have undergone a transition from “green-terminal” mainframes to client-server systems to the modern day distributed grid model. Hardware systems have also undergone a similar evolution, with mainframes giving way to Symmetrical Multi-Processor (SMP) machines, which, in-turn, are being replaced with more distributed form factors like blades. Noticeably absent is any type of similar progression or advancements in data infrastructure technologies to support this emerging class of applications and hardware.  Databases and file-systems still serve as the underlying data infrastructure even in the most demanding Grid environments, leading to the issues previously discussed. These environments require a distributed data platform to manage large volumes of information across a grid with almost zero-latency. An Enterprise Data Fabric (EDF) can deliver this critical functionality and enable intelligent, on-demand delivery of actionable information to the appropriate compute node. By primarily managing data in memory, an EDF enables extremely high-speed data access and sharing that turns a network of machines into a single logical unit, with data managed in a format (objects, relational or XML) that is readily consumable by a Grid application.

Figure 2 highlights the architectural fit of an EDF in a grid deployment. As seen in this illustration, an EDF acts as a distributed data façade for the backend systems and provides consistent data access to the compute nodes.

Figure 2: Enterprise Data Fabric in a Grid Environment         

Enhancing the Grid Data Architecture

The new data architecture paradigm created by EDF technology is anchored on three key concepts, which accurately detail the specific internal functioning of an EDF in the context of grid deployments:

• Data Virtualization: By dynamically managing data in memory partitions across multiple physical nodes (Figure 2), an EDF converts every compute node in a grid into a “data node,” as well. These physically disparate data partitions are exposed to a consuming application as a unified logical entity that appears to originate from a single source. The application is not concerned with the actual data location, nor does it adhere to different access protocols. Rather, it uses the EDF as an access layer, as data is delivered to the application through a high-speed transport layer with a maximum of one network hop. This concept is often referred to as “location transparency” in Grid vernacular. An EDF also offers “format neutrality” by providing multiple access APIs like Java, C++, XML:DB and SOAP, ensuring expensive transforms do not impede the path of real-time data access. Applications can then deal with their API of choice to access data of any kind, from any source.

• In-memory Data Caching and Distribution: The latency and performance requirements of a real-time grid are best addressed by adopting in-memory caching strategies that employ active memory across distributed nodes. To that end, an EDF supports several sophisticated caching topologies. In certain instances, repeatedly used data elements are held in a cache that is embedded (co-location) within a grid compute applications process. Multiple such embedded caches can be linked together in a distributed peer-to-peer model. Alternatively, a set of grid compute processes can be connected as clients to a large data cache (server cache). Such a server cache can be deployed on 64-bit machines with large Random Access Memory (RAM) and linked to other server caches even over a Wide Area Network (WAN), together serving a grid deployment spanning hundreds or even thousands of compute nodes. When data is modified on a grid node, updates are propagated only to nodes that are affected by the changes, thereby avoiding unnecessary network traffic. Based on the data consistency requirements, the underlying distribution layer can be configured to operate with or without acknowledgements while propagating these updates. An EDF can also be configured to overflow data elements to disk using Least Recently Used (LRU) or Most Frequently Used (MFU) algorithms, so that only relevant and most requested data entities are held in RAM.

• High Availability: While blazing performance is indeed a major benefit of managing data in memory with an EDF, it should not come at the price of inconsistent data availability. High availability without perceivable loss in performance is guaranteed with an EDF through a memory-based replication scheme. Any number of data mirrors or replicas can be configured to ensure the required level of data availability. When a primary data node fails, a replica can handle client requests and also reload data into the primary once it restarts. To guarantee data recovery, even in a case where all in-memory nodes have failed, an EDF can be configured to persist data to disk. When an application is restarted, the disk data copy is used to recover its state.  

A Collaborative Grid Ecosystem — Compute-Data Confluence

The ability of an EDF to position and distribute data in a dynamic fashion facilitates intelligent interactions with other technologies in a Grid ecosystem. For instance, a grid scheduler like DataSynapse GridServer or Platform Symphony and an EDF can be configured to enable “data-aware routing.” In other words, by recognizing the data placement strategy of an EDF, a grid scheduler can route certain tasks to nodes that already have the required data available to complete a specific task. Conversely, by understanding the data requirements of a computation being repeatedly executed on a node, an EDF can intelligently pre-load the data required for that task often resulting in significant performance benefits. A grid workflow engine, in turn, can use an EDF as a data layer for storing intermediate results in a sequential workflow involving task dependencies. Using a disk-based data store such as a database for such a purpose often results in unacceptable latencies and negates the benefits offered by a grid. An EDF can also work synergistically with grid provisioning engines like a Sun N1 to enable “just-in-time” data and hardware provisioning. Based on data access, load concurrency and quality of service requirements, an EDF and a provisioning engine can work in concert to position data on a set of grid nodes that are equipped with the requisite CPU and memory.    

Risk Management — A Reality Check

The practical application of an EDF is better appreciated by the following use-case, which pertains to the risk calculation grid of a leading investment bank. Prior to the adoption of a data fabric approach, this firm was confronted with significant latency (more than eight hours) in its overnight risk calculations and often faced the predicament of not being able to complete these prior to start of trading the subsequent morning, placing them at risk for substantial monetary loss. The firm embarked on an EDF strategy to provide their risk grid applications instant access to data from backend systems, including market data, historical data and securities reference data.  By deploying an EDF, the firm effectively supported approximately 3 billion calculations across two compute grids, one dealing with pre-processing and theoretical calculations, and the other performing risk analysis on the security portfolios. This fabric layer also acted as an intermediary store to manage and distribute data that was constantly enriched by calculations and analyses. The net result of introducing an EDF was a 4-fold reduction in process time (down to two hours). This lead-time improvement enabled additional calculations and iterations to be run, thereby increasing the accuracy of the results, guaranteeing high data availability and paving the way for intra-day risk computations at this firm.  

Summary

Grid computing, which has traditionally been confined to scientific and numerical analysis, is now considered a viable deployment model in more data-intensive and transactional environments such as Service Oriented Architectures (SOA) and J2EE applications. However, such a trend demands a closer examination of data infrastructure technologies, particularly in large-scale deployments. Successful adoption of grids in such environments hinges on a data architecture that can virtualize and distribute large data volumes at extremely low latencies while guaranteeing high throughput, reliability and high availability. An EDF provides such a scalable infrastructure for Grid computing by moving away from the traditional tier-based approach, wherein the data and compute tiers are often “siloed.” New age grid deployments that support real-time business-processes require a model, which promotes the “confluence of compute and data” through advanced data co-location and caching strategies. An EDF enables such strategies by leveraging innovations and breakthroughs in hardware (memory and network) and application infrastructure technologies. As a result, an EDF-enabled grid serves as a solid foundation to deploy critical processes that impact business profitability while eliminating the need for additional hardware, software and personnel investments, leading to a dramatic reduction in total cost of ownership.

About Bharath Rangarajan

Bharath Rangarajan is director of product marketing at GemStone Systems, where he oversees product positioning and market strategy for the GemFire product line. He has more than seven years of experience in enterprise software, dealing with data management issues in functional areas such as EAI, B2B collaboration and supply chain management. He has led technical and product teams at companies including i2 Technologies, SeeBeyond Corp. and Candle Corp. You can reach him at [email protected].