data-awareness and low- latency on the enterprise grid getting the most out of your grid with...
TRANSCRIPT
Data-Awareness and Low-Latency on the Enterprise GridGetting the Most out of Your Grid with Enterprise IMDG
Shay Hassidim
Deputy CTO
Oct 2007
Overall Presentation Goal
• Understand the Space Based Architecture model and its
4 verbs.
• Understand the Data contention challenge and the
latency challenge with Enterprise Grid based
applications.
• Understand why typical In-Memory-Data-Grid can’t solve
the above problems and why the Enterprise IMDG can.
GigaSpaces in a Nutshell• Founded in 2000
• Founder of The Israeli Association of Grid Technologies (IGT) – OGF affiliate.
• Provides infrastructure software for applications characterized by:
• High volume transaction processing
• Very Low latency requirements
• Real time analytics
• Product: eXtreme Application Platform – XAP. 6.0 released few months ago.
• Enterprise In Memory Data Grid (Caching)
• Application Service Grid
• Customer base – about 2000 deployments around the world.
• Financial Services
• Telecom
• Defense and Government
• Presence
– US: NY (HQ), San Francisco, Atlanta
– EMEA: UK, France, Germany, Israel (R&D)
– APAC: Japan, Singapore, Hong Kong
About myself – Shay Hassidim
• B.Sc. Electrical, Computer & Telecommunications engineer. Focus on Neural
networks & Artificial Intelligence , Ben-Gurion University , Graduated 1994
• Object and Multi-Dimensional DBMS Expert
• Extensive knowledge with Object Oriented & Distributed Systems
• Consultant for Telecom, Healthcare , Defense & Finance projects
• Technical Skills: MATLAB , C, C++, .Net , PowerBuilder , Visual Basic , Java ,
XML , CORBA , J2EE , ODMG , JDO , Hibernate, SQL , JMS , JMX, IDE , GUI , Jini
, ODBMS , RDBMS , JavaSpaces
• In the past:
– Sirius Technologies Israel - VMDB Applications & Tools team Leader
– Versant Corp US. - Tools Lead Architect , R&D
• Since 2003 - GigaSpaces VP Product Management (Based in Israel)
• Since 2007 – GigaSpaces Deputy CTO (Based in NY)
GigaSpaces – Technical overview
The Basics… Data Grid: Caching Topologies
Partitioned CacheReplicated Cache
Master / Local Cache
So. . .What is Space-Based Architecture?
• Utilizing a single logical/virtual resource to share:
– Data
– Logic
– Events• Services:
– Interact with each other through the space
– Can be co-located with data/events for faster results
– Are deployed and managed in an adaptive and fail-safe way
} Objects! Data Provisioning
Event Propagation
Logic Processing
8
Space Based SOA using 4 Simple Verbs
Write TakeRead Write Notify
Write + Read = IMDG (Caching)
Write + Notify = Messaging
Write + Take = Parallel Processing
Take
Write
Read
Take
Notify
IMDG Distributed In-Memory Query Support
• Enable aggregation of data
transparently
• Support SQL Query
semantics
• Continues query via
notifications
• Local view – client side
cache
Partitioned Clustered Space
Read
Space proxy
Parallel Query
Local View updated using Continues Query
Data virtualization– IMDG Accessed by all popular API and programming languages
JDBC
Clustered Space
Map/JCache
Space
Ap
plic
ati
on
s• Provides true data grid that
supports variety of
standard based data API
• API Becomes just a view
– Same data can be
accessed via multiple API
• Combine the benefits of
the relational model with
OO model
CPP/.Net
Integration with External Database – 2 basic models
•Write/Read Through and Write behind enables lazy load of data from DB to the cache and async persistency• Complete mirroring cache data into the DB• Support also for black box persistency into RDBMS and index file (light embedded ODBMS)•Sync/Async
Hibernate Cache plug-in provides 2nd level cache for hibernate based applications
Seamless Integration with External Data Sources
The Mirror service ensures Reliable synchronization with
minimal performance overhead
Mirror Service
Data is propagated seamlesslyfrom the IMDG to the external Data source and visa versa
Through the CacheStore.
load
loadload
store store store
External Data Source
Reliable Async Replication
13
Services can be Java, C++, .Net
Content-Based Routing
Shared state to enable stateful services
SBA – Real-time SOA for Stateful Services
Enterprise Data Grid unique features
FeatureBenefits
Extended and Standard Query based on SQL, and ability to connect to IMDG using standard JDBC connector.
- Makes the IMDG accessible to standard reporting tools.- Makes accessing the IMDG just like accessing a JDBC-compatible database, reducing the learning curve.
SQL-based continuous query support.Brings relevant data close to the local memory of the relevant application instance.
Central management, monitoring and control.Allows the entire IMDG to be controlled and viewed from an administrator’s console.
Mirror Service—transparent persistence of data from the entire IMDG to a legacy database or other data source.
Allows seamless integration with existing reporting and back-office systems.
Real-time event notification—application instances can selectively subscribe to specific events.
Provides capabilities usually provided by messaging systems, including slow-consumer support, FIFO, batching, pub/sub, content-based routing.
GigaSpaces solution for Enterprise Grid
What is the Enterprise Grid?
• Improve utilization of HW resources through:
– Multiple applications can share a pool of hardware resources.
– Resources are allocated to each application as needed.
– Applications can scale up very easily.
– The Grid provides parallelization for heavy computing jobs.
• How can I bring front office application to the
grid?
– The Latency challenge
Great, But…
• What about stateful applications?
– Data Contention challenge
The Data Contention Challenge
• Only stateless applications can scale up freely on the Grid.
• Any application that needs to:
a. Share state between more than one instance (service/process)
b. Store state using a central database
Could not scale easily!Could not scale easily!• This implies
– Partial analysis results checkpoints to enable recovery.
– Managing a workflow involving more than one process.
– Common data need to be shared between processes
The Latency Challenge
• Enterprise Grid designed for batch applications
– Each client request is submitted as a job.
– Hardware resources are allocated.
– Relevant software instances (service/process) are scheduled to run on the
resources and perform the work.
Impracticable with low-latency environments!Impracticable with low-latency environments!
• Why?
– An interactive application receives thousands of client requests per second, each
of which needs to be fulfilled within milliseconds.
– It is impossible to respond fast enough in a “job” approach.
– Throughput would be severely limited due to the need to schedule and launch
large numbers of application instances.
Three Stages Approach to the Solution
1. In Memory Data Grid (IMDG)
2. Data Aware Grid using SLA driven containers
3. Adding front office application to the Grid using
Declarative Space Based Architecture (SBA)
In Memory Data Grid (IMDG)
• Data stored in the memory of numerous physical
machines instead of, or alongside, a database.
– Eliminates I/O, network and CPU load.
– Partitions the data and moves it closer to the
application.
However, IMDG in an Enterprise distributed environment, However, IMDG in an Enterprise distributed environment,
is only a partial solution!is only a partial solution!
Stage 1
Stage 1
Data Aware Grid using SLA driven containers
Common wisdom holds that it is much easier to bring the business logic to the data than to bring the data to the business logic.
But… Not all IMDG support data & business logic co-locality! But… Not all IMDG support data & business logic co-locality!
This results:
• Unnecessary overhead caused by remote calls from business logic to IMDG instances.
• Data duplication, because business logic elements that use the same data are not necessarily concentrated around the relevant IMDG instance.
• And worst of all, data contention, because several business logic elements might access the same IMDG instance - leading to exactly the problem the IMDG was meant to solve!
Requirements for a Data-Aware Grid
• The Enterprise Grid must know which data is stored on which IMDG instances.
• There must be a way to guarantee data affinity - tasks must always be executed with the relevant data coupled to them.
Stage 2
Stage 2
Enterprise IMDG Deployment requirements
• Deploying a shared IMDG rather than specific IMDG per
application requires:
– Improved resource utilization
• With the IMDG as a shared resource, memory and CPUs available
to the IMDG instances can be shared between different applications,
depending on their current data loads. It is also much easier to scale
the IMDG to respond to changing data needs
– Lower total cost of ownership
• Installation, testing, configuration, maintenance and administration of
the IMDG is performed centrally for all the applications on the Grid.
Stage 2
Stage 2
Enterprise IMDG requirements for grid environments
• Sensitivity to Demand for Data vs. Available Resources
– Free (Memory) resources when there is no need for them
• Multi-Tenancy
• Continuous High-Availability
– Hot fail-over
– Versioning—it should be possible to upgrade or update the IMDG instances without affecting the
data or interrupting access.
– Configuration changes—it should be possible to change configuration without affecting availability
of the IMDG instances.
– Schema evolution—changing the data structure (i.e. adding or modifying classes) should not affect
the existing data and should not require downtime.
• Isolation (Groups, instances, Data)
• Content-Based Security
• Explicit Control over IMDG Instance Locations (manual relocation while the system is
running)
• Integration with Existing Systems
Stage 2
Stage 2
Strategies for adding data awareness to the grid
ScenarioMethod of Providing Data Awareness
IMDG instances deployed directly by Enterprise Grid (without SLA-Driven Containers).
Integration using affinity keys—the Enterprise Grid and users submitting tasks share special keys that identify the data relevant to each task. In this way the Enterprise Grid can execute tasks on the same machine as the relevant data.
SLA-Driven Containers are launched by Enterprise Grid (each container launches relevant IMDG instances).
Provides data awareness implicitly—data-intensive procedures can run in the SLA-Driven Container, together (co-located) with the IMDG instances. Because the container itself is data aware, data affinity can be guaranteed, without making the Enterprise Grid itself data aware.
Stage 2
Stage 2
Stage 3
Stage 3
Adding front-office to the grid using Declarative SBA
• All services are collocated on the same machine
• Transparent data affinity via content based routing (i.e. hash based load-balancing)
• Sharing can be done in local memory => the lowest possible latency.
Stage 3
Stage 3
Processing unit
27
Declarative SBA (cont.)
• So what it this “processing unit”?
– A mini-application which can perform the
entire business process.
– Accept a user request, perform all steps of
the transaction on its own, and provide a
result.
– Removes the need for sharing of state and
partial results between different
components of the application running on
different physical machines.
Stage 3
Stage 3
• Provides built-in support for deployment of Spring based
applications
• Virtualize the network and physical resources from the
application
• Handles Fail Over, Scaling and Relocation policies using SLA
based definitions.
• Provides distributed dependency injection to handle partial
failure and deployment dependency.
• Provides single point of access for monitoring and management
SLA Driven Application Service Container Stage 3
Stage 3
SLA:• Failover policy• Scaling policy• Ststem requirements• Space cluster topology
PU Services beans definition
SLA Driven Deployment Stage 3
Stage 3
Fail-OverFailure
Continuous High Availability Stage 3
Stage 3
VM 1 ,2GGSCGSC
VM 3 , 2GGSCGSC
Dynamic Partitioning = Dynamic Capacity Growth
VM 2 ,2GGSCGSC
Max Capacity=2GMax Capacity=4GMax Capacity=6G
E FPartition 1Partition 1
A BPartition 2Partition 2
C D
Partition 3Partition 3
In some point VM 1 free memory is below 20 % - it about the time to increase the capacity – lets move Partitions 1 to another GSC and
recover the data from the running backup!
Later .. Partition 2 needs to move… After the move ,
data is recovered from the backup
VM 5 , 4GGSCGSCVM 4 ,4GGSCGSCA B
Partition 2Partition 2
E FPartition 1Partition 1
C D
Partition 3Partition 3
P - PrimaryP - Primary
B - BackupB - Backup
PP
PP
PP
BB
BB BB
A closer look at OpenSpaces and Declarative
SBA Development
• Step 1:• Implement POJO domain model
• Step 2:• Implement the POJO Services
• Step 3:
• Wire the services through spring
• Step 4:
• Packaging
• Deploy to Grid (Scale-Out)
Declarative Spring-SBA – How it works.
@SpaceClasspublic class Data {
@SpaceId(autoGenerate = true) public String getId() { return id; }
@SpaceRouting public Long getType() { return type; }
public void setProcessed(boolean processed) { this.processed = processed; }
}
SpaceClass indicate that this is a SpaceEntry – SpaceClass includes classlevel attributes such as FIFO,Persistent…
SpaceId used to define the key for that entry.
SpaceRouting used to set the data affinity i.e. define the partition where this entry will be routed to.
The POJO Based Data Domain Model
public class DataProcessor implements IDataProcessor {
@SpaceDataEvent public Data processData(Data data) { data.setProcessed(true); data.setData("PROCESSED : " + data.getRawData()); // reset the id as we use auto generate true data.setId(null); System.out.println(" ------ PROCESSED : " + data); return data; }}
SpaceDataEvent annotation marks the processData method as the one that need to be called when an event is triggered
Order Processor Service Bean
<bean id="dataProcessor“ class="com.gigaspaces.pu.example1.processor.DataProcessor" />
<os-events:polling-container id="dataProcessorPollingEventContainer" giga-
space="gigaSpace">
<os-events:tx-support tx-manager="transactionManager"/>
<os-core:template>
<bean class="org.openspaces.example.data.common.Data">
<property name="processed" value="false"/>
</bean>
</os-core:template>
<os-events:listener> <os-events:annotation-adapter>
<os-events:delegate ref="dataProcessor"/>
</os-events:annotation-adapter> </os-events:listener>
</os-events:polling-container>
The PollingEventContainer will implicitly call take with template defined in the template property and invoke the method marked with @SpaceDataEevent on dataProcessor bean.
Wiring Order Processor Service Bean through Spring
Write
Space BUS
OrderProcessor
Service Bean
Polling EventContainer
Notify EventContainer
ProcessedOrders
RoutingService Bean
Take Write Notify
Data Loader
Space Proxy
Direct Data Loader Client
Order Proxy
Order ProcessorClient
SpaceServiceProxyFactoryBean
Invoke
Write
SpaceInvokeData OrderProcessorDelegator
Space BUS
OrderProcessor
Service Bean
SpaceServiceExporter
TakeSpaceInvokeData
Writeresult
ProcesData
Space Based Remoting
Order Proxy
Order ProcessorClient
SpaceServiceProxyFactoryBean
Invoke
WriteSpaceInvokeData
OrderProcessorDelegator
Space BUS
OrderProcessor
Service Bean
SpaceServiceExporter
TakeSpaceInvokeData
Writeresult
ProcessData
Space Based Remoting – Inherent Scalability/Reliability
Looking into the Future… Many Enhancements!
• Enhance Performance
– Built in infiniband support – Voltaire , Cisco
• Enhance Database integration
– Enhance the Space Mirror support (async persistency)
• Enhance partnership and integration with grid vendors
– DataSynapse , Platform Computing , Sun Grid Engine, Microsoft
Compute Cluster Server
• Enhance CPP and .Net support
– Performance optimization – first goal – same as java
– Support for complex object mapping
Conclusions and Summary
• Typical IMDG won’t help you
– You need Data Aware Enterprise IMDG to solve the data
contention and latency challenges.
– Data affinity need its twin: data & business locality
• The Enterprise IMDG co-locates the data with the
business logic
– Using self-sufficient autonomic processing unit deployed into
SLA based container that scales via the Enterprise Grid
• The Enterprise IMDG bring the Front-office into the grid
– Makes the grid a utility model for wide spectrum of applications
across the organization
Case Studies
A Dynamically Scalable Architecture for Data IntensiveTrading Analysis Applications
• Most financial organizations today use
Excel™ or Reporting Databases as the
main trading analysis tools. These are very
difficult to scale.
• The solution is to create a shared In-
Memory Data Grid (IMDG) which stores the
trading data in a shared pool of machines.
Common data calculation and analysis run
on that pool as well, leveraging the available
memory and CPU resources.
• JavaSpaces is a powerful model for
distributed persistence. GigaSpaces is a
JavaSpaces vendor providing Enterprise
features.
• Spring hides the details of the JavaSpaces
model, allows effort to be focused on
requirements rather than frameworks.
Using shared data grid for all users
Running analytics close to the data to improve performance and leverage the available resources
Reconciliation Calculation
Questions?
Thank [email protected]