Dynamic Service Deployment
Posted 9 October 2008 @ 10:26 am by Owen TaylorI recently created an integration with SunGrid Engine. This was easy to do - requiring only that a listener be written that hears JMX events that are produced by our product. As you may know, with GigaSpaces you can create watches for the services you deploy. These watches are populated with information coming from getter methods on those services.
For example: you could have a service that exposes the method: getBacklog() that returns a long Then in your pu.xml you set up the watch for that property:
<os-sla:sla max-instances-per-vm="2">
<os-sla:scale-up-policy monitor="backlog" max-instances="12" high="200" />
<os-sla:requirements>
<os-sla:cpu high=".65" />
<os-sla:memory high=".75" />
< /os-sla:requirements>
<os-sla:monitors>
<os-sla:bean-property-monitor name="backlog"
bean-ref="adaptiveOrderProcessor"
property-name="backlog"
period="2000" />
< /os-sla:monitors>
< /os-sla:sla>
In this example, when the value returned from the getBacklog method is over 200, it triggers a scaling event which adds another instance of the service named adaptiveOrderProcessor to the running system.
NOTE: that the scaling event effects the entire population of the ProcessingUnit of which that service is a part. To scale one service only, you must define that one service alone in its own pu.xml file. If (as in this example) that service has a limitation on the number of instances that can run in a single GSC that is expressed here: <os-sla:sla max-instances-per-vm="2">and means that at some point, the available GSCs will not be enough to host all the possible instances
<os-sla:scale-up-policy monitor="backlog" max-instances="12" high="200"/>
here we state we want a max of 12 instances so we need 6 GSC instances to host them all.
What I did with SUN was to write a JMX listener that listened for "ProvisionerFailureEvents" which are created by the GSM when it gets a scaling or relocation or failover event that provokes the GSM to seek a host for that service. When the GSM cannot find a suitable host because there are not enough GSCs running, the GSM sends out a ProvisionerFailureEvent which is what my code listens for. When the event hits, my code simply calls the API of the Grid technology in question and asks for the creation of a new GSC. In other words, the service in question says: "help me, I must relocate" or, "Help me, I must failover", or "help me, I must have more of me running on the network because one of me is not enough!" The GSM says, " I will start you somewhere else. . ." but then the GSM says, "Oh, golly! There is no where else to start you!" And then the GSM says, "Help me someone!" and sends the ProvisionerFailureEvent to JMX hoping some force in the universe will care. Once the universe shows an interest and starts a new GSC, the GSM will retry the scaling, failover, or relocation effort and utilize that new resource allowing the declared SLA to be satisfied. Bottom line is: it is simple to integrate GigaSpaces with any grid management solution that exposes an API and in doing that integration, enable the dynamic addition of resources to allow the relocation (or failover or scaling) of an application on the fly. Other watches you might set up include: getLocalTimeOfDay() where the value measured causes a relocation event that could move applications to new machines in different timeZones - allowing you to "follow the sun". getMemoryConsumption() where the value measured causes a relocation event that moves applications to new GSCs that have more memory. getCPULevel() where the value measured causes a relocation event that moves applications to new GSCs with more CPU capacity. etc.. Again, the choice if scaling in response to an event or relocating is yours but is also dependent on the type of service you are affecting. If the service involved has an embedded space in the same PU.xml file, you can not scale it using scaling events. To accomplish this behavior, you must relocate the processing unit which will allow you to scale to the limits of the number of partitions you defined for that space when it was deployed. Example: you deploy a space and worker to the system and define the space as <os-sla:sla cluster-schema="partitioned-sync2backup" number-of-instances="24" number-of-backups="1" max-instances-per-vm="1">This means you have 24 partitions defined. You first deploy this processing unit to 3 GSCs each having 2gb ram where you run 16 instances in each GSC (8 partitions and 8 backups) These instances run happily until they start running low on memory. At that point a watch on one of the workers could trigger a relocation event which asks the GSM to move one of the instances of the PU to a new GSC. Presuming there is a GSC with the necessary memory and CPU available ... (as defined in the following section where it is specified that the PU will not be deployed unless no more than 25% of the CPU and memory is utilized in a target GSC) <os-sla:requirements>
<os-sla:cpu high=".25"/>
<os-sla:memory high=".25" />
</os-sla:requirements>
The GSM will relocate a PU to the new GSC and with that relocation the spreading out of the information and work starts to happen. Eventually, if there are enough GSCs available, the system could span 48 GSCs each having 2gb ram so the system that started with 6gb ram and maybe 6 cores, could grow over time to be housed in 48gb ram and use 96 cores! This kind of relocation could be expanded further by moving the instances to a different class of machine. If you chose to move to 64 bit machine or to an Azul box, the possibilities are almost endless! In my opinion, this relocation is likely to be driven by human operators rather than automated rules, but the rules could be put in place as a last resort for the times when the humans are asleep at the helm. Cheers, Owen.
Read more...
Cloud Summit Event in Sunny Tel Aviv
Posted 8 October 2008 @ 2:46 am by Nati ShalomCloud summit event is coming up with lots of interesting lectures from Google, Yahoo, Amazon, eBay
You can see the full program here.
In my presentation "Getting ready for the clouds" I'm going to talk about the steps that can be taken to bring existing application to the cloud and use a live demo that shows a real life demo on how easy it deploy a production ready application with load-balancing, dynamic-scaling, caching and data-base in just few minutes. I'm also going to show what self-healing really means by killing one of the machines and seeing the impact of that failure on the application.
Another nice thing about this event is that its going to happen at perfect timing for those who want to run away from the real winter clouds and enjoy the sun and beaches of Tel Aviv.
Read more...
Memory Capacity Planning - The Footprint Benchmark
Posted 7 October 2008 @ 3:28 pm by Shay HassidimThe goal of this benchmark is to measure the memory footprint of the indexes the space maintains to boost read/take operations when searching for matching objects.
This should help users to plan the amount of memory to allocate when doing their capacity planning prior deploying the application.
See blow the final Conclusions and the detailed report:
- XAP 6.6 consumes less memory compared to XAP 6.5 with indexed data.
- XAP 6.6 consumes about 85 bytes less per index value with 32 bit JVM and 150 bytes less per index value with 64 bit JVM.
- The footprint reduction is increased when having more indexed fields defined. With a single indexed field the footprint reduction is 15% per object. With every additional indexed field the additional reduction is about 5%.
- With 4 indexed fields the footprint reduction with 6.6 is close to 30%. For 200,000 objects stored within the space it translated to 67 MB less memory used where the original footprint with XAP 6.5 was 227 MB when using 32 JVM. With 64 bit JVM the footprint reduction is 111 MB less where the original footprint was 414 MB (27% reduction).
- 64 bit JVM consumes about 80% additional memory per object compared to 32 bit JVM.
- No major footprint difference observed between 64 1.5 JVM and 64 1.6 JVM.
- XAP 6.6 does not provide any footprint reduction with the space entry object raw data storage footprint.
Detailed report
The indexes are used when a client application performs a query or regular template matching where the space engine using indexed fields data to construct the candidate list of objects to perform the matching phase.
The indexes are updated with write , take and update space operations. An index includes the indexed value and references to the objects that stores the object data. To allow concurrent access to the index, the index object includes some additional objects that ensure the index will be locked in the relevant cases. These objects will determine the footprint of the indexes.
The benchmark had 5 types of classes tested:
- 4 fields – no indexes. Control group.
- 4 fields – 1 indexed field: String type
- 4 fields – 2 indexed fields: String and Integer
- 4 fields – 3 indexed fields: String , Integer , Long
- 4 fields – 4 indexed fields: String , Integer , Long and Double
The benchmark compared XAP 6.5 and 6.6 which went through some changes with its index structure that improved its footprint. With this benchmark each object has a unique value – i.e. each index has only one object associated with.
Here are the results of the benchmark:
See here more detailed results .
Shay
Read more...
Holy .NET Batman! GigaSpaces6.6 for .NET is so cool!
Posted 7 October 2008 @ 11:09 am by Owen TaylorI just installed the GigaSpaces product for .NET found here: Latest Downloads I installed it in two clicks - using the default install and discovered the remarkable and oh so sexy .NET functionality demo that has no parallel (yet) in the Java version of the product. I am now motivated to scrape together a graphical example for Java that shows the same clear and excellent functionality as is in the .NET example. If you are interested - after you download the .NET version go to : "C:\GigaSpaces\XAP.NET 6.6.0\Examples\SpaceTutorial" to execute the charming and educational graphical demo I am speaking of. Cheers, Owen.
Read more...
Closing the gap between multi-core hardware and enterprise applications
Posted 7 October 2008 @ 2:20 am by Amnon RavivCase in point: GigaSpaces and Sun Microsystems recently teamed up to address some aspects of this very problem. We demonstrated how GigaSpace’s eXtreme Application Server (XAP) is able to seamlessly scale a heavy duty transactional application and take advantage of up to 128 threads offered by Sun’s newest 16-core platform, the SPARC Enterprise T5240. Equipped with Sun’s CoolThreads Chip Multithreading (CMT) technology, this is arguably one of the best hardware virtualization technologies in town. When I say “we” I mean Shay Hassidim. See his post for more details on the tests he ran.
This brings up another interesting angle – one that troubles enterprise IT executives, and consequently the hardware vendors who sell multi-core servers to these executives.
In a recent article on Computerworld titled Multicore systems dragged down by lagging software, several enterprise executives and analysts pointed out the gap between advancements in multi core hardware platforms and [single threaded] enterprise applications. While multi-core is clearly helping enterprises drive down footprint in the data center, operating costs and complexity, a big chunk of the CPU utilization is left on the table — at least until the software problem is solved.
According to Cumputerwold Senior Writer Sharon Gaudin, the challenge from an enterprise perspective is not only how to develop new apps for multi-core machines, but also how to justify, in the economic arena we’re in right now, the massive effort needed to rewrite/replace older, internally developed applications.
Sharon, we couldn’t agree with you more. Until GigaSpaces.
Rob Enderle, an analyst at the Enderle Group in San Jose summed it up pretty well in the article: “It’s difficult to take things apart, make them run separately and then have them come together perfectly at the end”.
So, back to our scalability tests with our friends at Sun. The reason this application was able to utilize all 16 cores and 128 threads of this wonderful server [and keep them busy] is the GigaSpaces application server humming below.
Sharon, Rob et al - the missing piece in “multi-core application development” is here.
Read more...
