Working with Flexible Scaling
Use in-built flexible scaling in Analytics Manager to meet the following objectives:
• Check if the existing capacity fulfills the current computation needs, and if addition or reduction in resources is required.
• Decide where, when, and how compute capacity can be added or reduced.
Analytics Manager achieves flexible scaling by following these steps:
1. The Quality of Service (QoS) rules evaluate whether an addition in resources or reduction in resources is required. This evaluation is done based on the following parameters:
|
Parameter
|
Description
|
|---|---|
|
QoS indicator
|
Represents the computational activity in Analytics Manager and is a performance indicator of execution of user activity.
For example: Waiting time, waiting jobs, execution time, number of sessions, session duration, and so on.
|
|
Threshold
|
Specifies a fixed value or indicates the availability of the system that can be computed dynamically.
For example: Number of client instances
|
|
Synthesizing function
|
Specifies a mathematical function that is applied to the QoS indicator and the threshold value is computed dynamically.
For example: Count, sum, average, and so on.
|
|
Margin
|
Specifies the value that is used to alter the QoS indicator. Depending on the value of margin, the QoS indicator is increased or decreased by an absolute value or percent value of the QoS indicator.
|
|
Operator
|
Specifies the comparison operator that is used to compare the altered QoS indicator and the threshold.
|
|
Frequency
|
Specifies the count of time period for which the rule must be consecutively met before an addition or reduction in resources is requested.
|
2. Once the QoS evaluation is complete and an action is warranted, the flexible engine returns which agent is available for increase or decrease in capacity based on the following parameters:
|
Parameter
|
Description
|
||
|---|---|---|---|
|
Process metrics
|
Specifies the performance indicator of the individual compute instance.
For example: CPU used, memory used, threads, paging, and so on.
|
||
|
Platform metrics
|
Specifies performance indicators that represent the availability of the platform on which the client instances are run.
For example: CPU availability, memory availability, disk availability, and so on.
|
||
|
Required compute capacity per client instance
|
Specifies the minimum compute capacity that is required to launch and support a compute instance.
|
Request for addition in resources
Before a request for addition in resources is made, the flexible engine tries to satisfy the capacity needs in one of the following ways:
• Add more capacity to an existing host by launching another process.
• Deploy the software to a managed host that has available capacity.
If the above methods satisfy the capacity needs, then the flexible scaling engine returns the agent where a new instance can be started.
If there is no suitable agent that can satisfy the capacity needs, an event is thrown for an external component to add more resources. In order for the system to act on this event, you must first create a custom Thing and subscribe to the NeedCapacity event in ThingWorx. For more information, see Subscribe to the NeedCapacity Event.
Subscribe to the NeedCapacity Event
In order for resources to be added by the flexible engine, you must create a new Thing and subscribe to the NeedCapacity event:
1. In ThingWorx Composer, create a new Thing as follows:
◦ In the left navigation panel click the 
icon and select the Thing option.
icon and select the Thing option.◦ Enter a Name for the Thing and select a Base Thing Template.
◦ Click Save.
2. On the new Thing, subscribe to the NeedCapacity event as follows:
◦ Click on the Subscription tab at the top of the page.
◦ Next to My Subscriptions click Add.
◦ On the left, click to expand Subscription Info and enter a Name for the subscription.
◦ For Source, select Other entity.
◦ For Entity, click the plus sign and select the TW.AnalysisServices.CapacityManager Thing
◦ Click to expand Inputs.
◦ For Event, click the down arrow and select NeedCapacity.
◦ In the panel on the right, enter any code logic that you want to be executed when the NeedCapacity event is triggered. This custom logic could include instructions for your scaling mechanism about when, how, and where to add resources.
◦ Click Save and Continue. The new subscription is saved.
3. On the new Thing, add permissions as follows:
◦ Click on the Permissions tab at the top of the page.
◦ On the Visibility tab, click the plus icon on the Search Organizations field.
◦ Select the TW.AnalyticsManager.AnalyticsManagerOrgUnit organization.
◦ On the Run Time tab, click the plus icon on the Search Users or Groups field.
◦ Select the TW.AnalyticsManager.Admin user.
◦ Click the check icons for the Service Execute and the Event Subscribe permissions.
4. Click Save at the top of the page. The new permissions are saved.
Your new Thing now has the necessary permissions and is subscribed to the NeedCapacity event. When the event is triggered, the flexible engine will follow your custom instructions for scaling resources.
Request for reduction in resources
When a request for reduction in resources is made, the flexible scaling engine returns the agent where an instance can be shut down. Typically, the agent that has the least load is returned. When all clients on an agent are shut down, no new jobs or sessions are assigned to this agent. This particular node is available for other computations.
The Quality of Service (QoS) rules can be completely customized. For more information about customizing these rules, see Managing Customized Flexible Scaling.
Redundant Agents
The agent is a critical component to use capacity and maintain operational continuity. An agent must run all the time on a system that runs computations in Analytics Manager. Thus, the Analytics Manager framework implements the concept of redundant agents.
Redundant agents are used to maintain continuous connectivity to the compute resources. At agent startup, a pair of agents (primary agent and secondary agent) is started and registered with the server.
The primary agent is responsible to run compute operations. The secondary agent is used to restart the primary, if the primary agent is killed at run time.
If the secondary agent is killed at runtime, the primary agent restarts the secondary agent.
 | This feature is optional. To enable this feature, set the value of the UseRedundantAgent parameter in the config.properties file of your agent to true. By default, this value is set to false. |