In my previous articles Pattern-type (Part 5): Scaling in/out based on your own monitoring collector with SmartCloud Application Services I explained how to Scale in/out using your own monitoring collect (ie: counting files in a directory). In noticed in the documentation (IWD Infocenter) at the end of the page a mention of a ‘CPU’ category and ‘Used’ metrics. This let me think we can re-use some embedded OS metrics in a scaling policy and I will show here how to do it.
When you define a role in a pattern type, you can associate to this role a number of operations you would like to launch once the pattern is deployed. These operations will be available from the ‘Manage’ panel under the operation tab.
In the new PDK (version 1.0.3) there is a plugin that allows you to create new structure for plugin, OSGI Component, Node parts, parts and and roles…
From the Pattern-type (Part 4): Adding your own monitoring collector to a pattern-type with SmartCloud Application Services, we learned how to add a collector to a pattern-type in order to monitor the deployed services. It was a simple collector counting the number of files in a directory. What I propose in this article is to explain how to leverage this collector to add scaling in/out rules based on the metrics provided by this collector.
Join the SCAS pilot: IBM SmartCloud Application Services
In the previous articles, I explained own to creates pattern-type for a single server, a master-slave and also how to add static scalability to a pattern-type. Now, if we want to have a dynamic scalability, a scalability which react on a monitoring feature, we have to be able to collect information from the server and this exactly what I will explain in this article.