Giga Spaces Alternative To GAE_JavaOne 09
•Als PPT, PDF herunterladen•
0 gefällt mir•583 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (18)
Ähnlich wie Giga Spaces Alternative To GAE_JavaOne 09
Ähnlich wie Giga Spaces Alternative To GAE_JavaOne 09 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Giga Spaces Alternative To GAE_JavaOne 09
- 1. Alternative to Google Application Engine for Java™ Technology-Based Applications Nati Shalom CTO GigaSpaces Natishalom.typepad.com Twitter.com/natishalom Francis de la Cruz Manager , Argyn Kuketayev Senior Consultant, Primatics Financial
- 2. About GigaSpaces 2,000+ Deployments 100+ Direct Customers Among Top 50 Cloud Vendors A middleware platform enabling applications to run a distributed cluster as if it was a single machine
- 4. Introduction to cloud computing SaaS PaaS IaaS
- 6. AWS vs GAE Source:Zdnet
- 11. Typical Enterprise Application Business tier Back-up Back-up Back-up Back-up Load Balancer Web Tier Messaging Data Tier Do you see a problem?
- 15. PaaS on top of AWS – Architecture view Application Repository (S3) MT Application Provisioning IaaS Provider (EC2, GoGrid, Sun, VMWhere, Citrix,..) App A App B Application Deployment Configuration 2)Deploy 1)Install Provision 3)Manage
- 17. Understanding the provisioning process GSC Start GSC Join the GSM cluster GSM Start GSM Deploy processing units LB Start the Load Balancer Add/Remove web container DB Initialize the database storage Start the database Deployment manager Machine Parse the deployment configuration Provision the VM with assigned profile Monitor and manage the application Install software packages from repo Assign machine profile Repeat for all machines
- 21. End 2 End Elasticity Load Balancer to Database Embedded Web Container Dynamic Load Balancing HTTP Session Replication In Memory Data Grid Async update to the Database Dynamic SLA Based Scaling
- 22. Design for linear scalability Users Load Balancer Web Processing Units Business Processing Units DB Partition the entire application stack
- 24. Case Study: Evolv ™ Risk: Cloud Computing Use Case for Java One 2009 Francis de la Cruz Manager, Primatics Financial Argyn Kuketayev Senior Consultant, Primatics Financial
- 28. Business Needs: Accounting-Cashflows Risk Analytics Platform Stochastic (Monte Carlo) simulation: for each loan run 100 paths (360 months each) INPUT Loan Portfolio ( 100MB): 100k Loans x 1 KB data Forecast Scenarios (100MB): 1MB per simulation path Market History (<1MB) Assumptions, Setting, Dials (<1KB) OUTPUT Cashflows (3GB): 100k Loans x 360 months x 10 Doubles
- 29. Business Needs: Scale Many jobs by the same user Many users in a firm Many firms More loans, more simulations, longer time horizon Risk Analytics Platform
- 31. Evolv Risk 1.5 vs 2.0 Software Stack GIGASPACES Prior Grid Framework J2EE Platform Loans & securities Loans Web-Interface SSL Reporting Warehouse Model API Scenarios Loss & Valuation Securities Custom Templates Validation Pluggable Client models Model Validation & statistics Cohorts HPI rates Interest rates Market rates Provisioning Monitoring Job Scheduling Failover / Recovery Load Balancing AWS Billing Registration Management Loss Forecasts Valuations Discount rates Node Management OLAP Reports Auto Throttling SLA Space Based Architecture Scaling Manual Process Model Validation & statistics Provisioning Monitoring Billing AWS Registration AWS management Not In Architecture Auto Throttling Space Based Architecture SLA Node Management * Broker (MQ) Sun JMS Discovery Persistence Manager J2EE Platform Inbuilt models
- 32. Performance, Scalability, Data Security, Data Integrity
- 33. Performance, Scalability, Data Security, Data Integrity Primatics Gateway AWS Provisioning
- 40. Nati Shalom Natishalom.typepad.com Twitter.com/natishalom Run your own demo http:// www.gigaspaces.com/mycloud
Hinweis der Redaktion
- <number><number><number><number>
- Enabling to run a single app on a dist. env. Leveraging in memory resources to gain performance
- <number>
- Try to add a machine and see what happens? NothingEvetything is hard wired, staticAssuming we did do that, what the effect? Can you predict
- <number>
- <number>
- <number>
- Remoting over IMDGMessaging over IMDGIMDG as a system of record, async persistency
- PerformanceMust run in a matter of hours and minutes not days.On-demand performance. High priority requests can be run on more machines.Stochastic (Monte Carlo Simulation) or DeterministicScalabilityLinear scalability per additional node.Multiple ScenariosClients may choose to execute 1 to N scenariosHorizon 2 years to 30 yearsStress Tests – unemployment rate rises above 10% and home prices fall by another 25%Data Size can easily run into the tens and hundreds of gigabytes and maybe even terrabytesData IntegrityClient’s data must never reside on the same location as another client’s data.Cashflow or valuation produced cannot be lost.Transacted
- This is primatics’ story.Stress how respectful we are of the open source framework and we are not here to talk about merits and demerits.1.0 to 1.5 to 2.01.0 typical J2EE app. 1 client. 50k loans. Non Enterprise grade models. Few hours. 1.5 1st cloud app. N clients. 160k loans. Enterprise grade models. Few minutes/hours.2.0 NNNN clients. 1MM loans. Enterprise grade models. Few minutes/hours.Start out with 1.5Stress how 1.5 currently in production.What are the things that proved difficult to scale for multiple clients.Things that are missingThings that are not enterprise grade.1.5 not designed to scale over clients.2.0 is designed to scale over N clientsPulled Manual and Things we liked into the application.Replaced the underlying frameworkReplaced with enterprise gradeAdded space based architecture.<number>
- All Jobs are stored in spaces.Cashflow objects in the spaces are backed up to a store on a different PU.Compute PU will load models as needed.Compute PU will also push the cashflows to a MySQL database. Current throughput is at 60MM records in 13 minutes (transacted)1.5 Data PerformanceMax. throughput at 60M records in 30minutes. = 33k records / second on MySQL2.0 Data PerformanceEst. Max. throughput at 60M records in 13 minutes = 77k records / second on MySQL innodb33
- All Jobs are stored in spaces.Cashflow objects in the spaces are backed up to a store on a different PU.Compute PU will load models as needed.Compute PU will also push the cashflows to a MySQL database. Current throughput is at 60MM records in 13 minutes (transacted)
- Importance of integration into the cloud.ProvisioningCould take minutes to set up vs configThrottlingBring up servers, put application on it, have it register vs auto-throttlingStability / monitoringProbably works well on traditional grid environment – didn’t work well on AMZN.When you start out on the cloud. Pick up the tools that you know will work well vs making the tools work well.
- Data had to be pushed into the Grid vs using the spaces for caching and data distributionunicast vs multicast issue in Amazon forced us to create the JMS Broker and Discovery module for pushing data and monitoring.Deployment – bring server up through AMZN console then deploy application. 2.0 allows us to leverage GigaSpaces for deployment.Images can be a versioning nightmare.