Configuring the symAinst requestor instance for dynamic provisioning

Configure the built-in symAinst requestor instance for dynamic cloud provisioning.

Before you begin

Python 2.7 or later must be installed on all management hosts in your cluster.
If you are using Red Hat Enterprise Linux 8, complete the following steps to set up Python:
1. Log on to your primary host as root.
2. Change to the /usr/bin directory and create a soft link called python:
```
cd /usr/bin
ln -s python2.7 python
```
  If you do not want to change /usr/bin, create a separate folder, create the link in it, and add the folder to the path. For example:
```
mkdir /myfolder
cd /myfolder
ln -s /usr/bin/python2.7 python
export PATH=/myfolder;$PATH
```
Your environment must be set up to connect to one or more cloud service providers. For more information, see Configuring your cluster for cloud bursting.

About this task

IBM Spectrum Symphony provides a built-in requestor instance, called symAinst, which you can enable for dynamic provisioning in the default POLL mode. symAinst monitors the workload of cloud-enabled applications in the cluster and triggers cloud bursting based on a default throughput policy for scale-out and scale-in computations. The HostFactory service periodically polls the symAinst requestor for cloud scale-out or scale-in requests and provisions resources from the configured cloud providers. When the resource is no longer required, the symAinst requestor instance gracefully removes the resource from the cluster (using the egosh resource close command) and returns it to HostFactory for release back to the cloud provider. Cloud resources that are closed by HostFactory include comments (Closed_by_symA), which you can view in the ego.audit.log file (see Enabling IBM Spectrum Symphony event logging for auditing).

Note: Optionally, you can enable symAinst in REST mode to manually provision cloud resources through RESTful APIs. For more information, see Submit requests for cloud hosts.

Requestor instance configuration can be customized to suit a set of your cloud applications and different requestor instances can use different policies for scale out and scale in. If you want to enable applications with different scale-out and scale-in policies for cloud bursting, you can create multiple requestor instances in POLL mode to monitor the different sets of applications. For more information, see Creating requestors based on symAinst.

Procedure

Enable the symAinst requestor instance for your cluster in the hostRequestors.json file at:
- %HF_CONFDIR%\requestors\ on Windows.
- $HF_CONFDIR/requestors/ on Linux®.
Set the enabled parameter in the symAinst section to 1, as follows:
```
{
    "requestors":[
        {
            "name": "symAinst",
            ...
            "enabled": 1,
            ...
}
    ]
}
```
For more information, see the hostRequestors.json reference.
Configure the symAinst requestor instance at:
- %HF_CONFDIR%\requestors\symAinst\conf\ on Windows.
- $HF_CONFDIR/requestors/symAinst/conf/ on Linux.
1. Update the symAinstreq_config.json file to specify the applications that must be monitored for cloud bursting, in the cloud_apps parameter. For more information, see the symAreq_config.json reference.
2. Update the symAinstreq_policy_config.json file to specify the cloud-bursting threshold. For more information, see the symAreq_policy_config.json reference.

What to do next

Cloud hosts that join the cluster are, by default, added to the ComputeHosts resource group. To add cloud hosts to different resource groups, add resource attribute tags to cloud hosts and create resource groups to which they can be dynamically added. See Adding cloud hosts to different resource groups.
Enable the HostFactory service; then, submit workload for cloud-enabled applications. See Starting host factory for cloud bursting.