MobiledgeX provides several distinctive policies to manage your applications. Setting up these policies provide opportunities to allocate more compute resources, define privacy settings, and more.
Described below are three types of policies to help scale and manage your applications. These policies work independently of each other, unless otherwise noted.
The auto-provision policy can be set to manage the deployment of application instances to different cloudlets providing better service and redundancy. The auto-provision policy works by monitoring FindCloudlet requests for applications across all cloudlets associated with the policy. FindCloudlet returns the best available cloudlet by selecting the most optimal cloudlet based on what is defined for the auto-provision policy. If enough client FindCloudlet counts for a particular cloudlet satisfy both Deploy Request Count and Deploy Interval Count thresholds set on the policy, a new application instance will automatically deploy to that cloudlet. Similar to the auto-scale policy, the min and max settings on the policy work to bound the number of application instances the policy will deploy.
Deploy Request Count: As mentioned earlier, the auto-provision policy works by tracking FindCloudlet requests. Therefore, the Deploy Request Count refers to the FindCloudlet count. Determining whether to scale up (deploy another application instance) is dependent on both the Deploy Request Count and Deploy Interval Count, where at each interval, MobiledgeX measures the number of requests since the last interval for each cloudlet. Each interval is approximately 5 minutes and is adjusted as needed by MobiledgeX. If the number of requests is above the Deploy Request Count threshold for that interval and remains above the threshold for ‘count’ subsequent intervals, MobiledgeX will deploy an instance to that cloudlet. Currently, if the threshold criteria are not met, we would not scale down (un-deploy an app instance), but rather instead not deploy. This behavior will change in a future release.
Deploy Interval Count: The number of intervals that meet the Deploy Request Count criteria to trigger automatic deployment.
Cloudlets: This is a list of available cloudlets in which your policy is limited to deploy your app instances.
Auto-provisioning will not deploy a new application instance on a cloudlet where an instance for the application already exists - regardless of whether that app was created manually or provisioned automatically. Once the auto-provision policy is created, you can reference the policy when you create a new application from the Apps page. Multiple policies may be attached to the same application to provide different levels of automation across different groups of cloudlets.
Note: Currently, only Docker and Kubernetes deployments can be auto-provisioned at this time.
To create an auto-provision policy:
1. Expand the Polices submenu.
2. Select Auto Provision Policy and click the + sign.
3. From the Create Auto Provisioning Policy screen, enter information for the required fields.
4. Click Create. The Step 2 Add Cloudlets page opens.
5. Finally, specify the cloudlets specific to the region you selected. Use the arrow to move your cloudlet selection to the box on the right.
6. Now click Add. Your Auto-Provisioning Policy appears on the Policies page. The quick access menu under Actions let you add cloudlet, delete cloudlet, or delete the entire Auto-Provisioning Policy.
7. Once your auto provision policy is created, apply the policy to your applicaton defintion under the Advanced Settings.
MobiledgeX aims to ensure your application instances are continuously available and operational on cloudlets. In the event that the application(s) experience connectivity issue or one of the cloudlets become unreachable, our high availability feature will ensure that applications and cloudlets remain fully operational with very minimal disruptions to users who are connected to your application.
High availability, which works in concert with the auto-provision policy, lets you specify the number of active application instances on the policy to enable high availability for all applications and cloudlets associated to the policy. This guarantees that the policy will maintain the specified number of active instances among the cloudlets for all applications associated to the policy.
Note: An application instance is not considered active if the health check fails for that instance, if the cloudlet in which the instance is associated with fails health check, or if the cloudlet is under maintenance.
Enable high availability
To enable high availability, specify the Min Active Instances setting on the Create Auto Provision Policy page to set up for either active-standby or active-active high availability.
Specifying a minimum active instance of 1 creates an active-standby approach. This means if the single instance fails, another instance is created on a different cloudlet once the failure is detected.
Specifying a minimum active instance of 2 or more creates an active-active approach, where the policy will always maintain the number of specified instances. This approach ensures that one instance will always be available unless there are multiple concurrent failures.
Application high availability works in conjunction with the FindCloudlet client demand-based deployment. Instances may be deployed in response to client demand, or to meet the minimum active instances requirement in the policy. For demand-based auto deployment, instances are only created on cloudlets that are listed on the policy. To meet the minimum active instances requirement, a cloudlet from the list that has seen recent client activity will be selected. If no such activity exists, then the next available cloudlet on the list will be chosen. With demand-based auto deployment, only one instance of the app will be automatically deployed per cloudlet.
The auto-scale policy governs scaling the number of nodes of a Kubernetes cluster to provide more compute resources for your application by monitoring the CPU load on the nodes [within the Kubernetes cluster]. When the CPU load on all nodes within the cluster rises above the scale-up threshold you set in the policy, another node will be added to the cluster. However, if the CPU load falls below the scale-down threshold set with the policy, that node will be removed from the cluster. These actions are limited to the min and max number of nodes set within the policy, to bound to the size of the cluster. Once the auto-scale policy is created, it can be referenced when creating a new cluster from the cluster instance page.
The ScaleWithCluster setting on your app should be set to true to have Kubernetes scale your app across all nodes within the cluster. Otherwise, your app will only run on one node in the cluster. As a result of that, auto-scale will not trigger, and you won't be unable to take advantage of an auto-scaled cluster.
Note: Auto-scale only supports Kubernetes deployments at this time.
To create an auto-scale policy:
Expand the Policies menu.
Select Auto-Scale Policy and click the + sign,
From the Create Auto Scale Policy screen, enter all required fields.
For the Minimum Nodes, set the minimum number of cluster nodes to scale.
For the Maximum Nodes, set the maximum number of cluster nodes to scale.
For the CPU Thresholds, set, in percentage, the min and max CPU threshold. The percentage range is between 1 and 100.
Set the Trigger Time, in seconds. This Trigger Time defines the time that the sampled CPU threshold must be continuously met before triggering the auto-scale action. Setting the Trigger Time prevents possible anomalies of CPU activity (or lack thereof) from triggering unwanted scale up/down actions, if the anomaly activity occurs as the CPU usage is sampled.
Once your auto-scale policy is created, attach it to your Kubernetes cluster.
Expand the Policies submenu.
To block all outbound communications, select Full Isolation.
To specify the whitelisting of both destination IP and ports and allow for outbound communications:
Select one of the supported Protocols, TCP, UDP, or ICMP.
Specify your port ranges, if TCP or UDP was selected.
Enter the Remote CIDR to specify the range of IP addresses that are allowed as destinations for outbound traffic. The Remote CIDR should use CIDR notation, for example, 220.127.116.11/32.
Click Create Policy.