In this blog, I’m going to show you how to deploy a Load Balanced Auto Scaling Web Service on Fujitsu’s K5 IaaS platform, using a Heat stack.
The Heat stack template will create the Virtual Router, Network, Subnet, Security Groups, Load Balancer, monitoring, scale out/in rules, and configure them all together, allowing the full template web service to be deployed in a matter of minutes.
Before you start, you need to deploy, configure and template your web server. This can either be Apache, IIS or other web service of your choosing, as long as the actual web service is stateless, as no new data should be saved within the template. Virtual Servers can and will be deleted during scale-in and out, so it is imperative that your template image is able to automatically connect to, read and write to an external data source using either API calls or an external database. All available operating system patches and updates should also be applied to the VM, before it is templated, with the template regularly refreshed with the latest updates as and when they are released. Make sure you also safely record any passwords that you may have used, so they can be remembered at a later date. If you are wanting to test/demo load on the CPU group, you may want to also install a free tool such as Heavyload
For the purposes of this example, I am using a simple Windows 2012 VM, configured with the default IIS role and displaying the default iisstart.html screen. As the VM is standalone and not part of a domain, I did not bother to run sysprep, although you may want to consider this, if you are deploying your system into a production or AD environment.
Cloning the VM Template
1. Once you are happy with your VM template, then it is necessary to shut the VM down and initiate a clone of its system disk, in order to create a private VM image.
2. Within the IaaS Portal, go to ‘Project | Compute | Storage’ and locate the storage assigned to your VM template (the name of the VM will be shown under ‘Connected Virtual Server’, then click on its hyperlinked ‘Storage Name’
3. Note (Copy) the Storage ID to be used in step 5
4. Establish your API connection and retrieve your authentication token. (This example assumes your token is stored within the variable $OS_AUTH_TOKEN used within K5 guides)
5. Declare the following variables for use within the clone API command:
NAME= e.g. iistemplate-v1.0
6. Use the following command to start the clone process:
Note this can take some time (>1hour) to complete with the progress shown in the ‘Status’ column for the VM system disk, within the ‘List Storage’ screen. Initially the status will be shown as ‘uploading’, changing back to ‘in-use’ when the close process is complete.
7. Once complete, the VM image template will be available for deployment under ‘Project | Compute | Image’. Locate and click the hyperlink Image Name for this image, and note (copy) the Image ID to be used later within the heat stack file.
Using a Heat Stack to deploy your load balanced autoscaling web application
To walk you through the Heat stack, I’ll break it into sections. For the complete example stack, please see the bottom of this blog.
Within the parameters section, please provide your values for AZ, the ID of the external network or ID of the existing router, the IP address of any client computer you may want to use to remote onto the deployed Web Server VMs from (or leave as default to not allow any), the size of the VM to deploy, the ID of the VM image created in step 7 above and the name of the pre-existing keypair to use. You also have the option of changing the default load balancer name.
At the time of writing there is a known issue with creating external connected routers using a Heat stack, in that the router configuration looks correct, but no external traffic can pass through the router. To overcome this, you need to either deploy the router and configure the external gateway manually, then refer to the router ID. within your heat stack or simply reapply the external gateway settings within the router post creation. This example assumes you will do the latter, so the Heat stack creates the router and configures the external gateway for you.
In the next section we begin to declare the resources, starting with the external router, network, subnet and security groups . Again the code can be changed if you want to supply the ID of an existing router, just look at the “****” commented sections for guidance.
For the purpose of this example, I simply hardcoded the names of these resource and subnet information into this section, so you can if you wish changes this or integrate it with the parameters section of the stack.
The stack then creates a Web_Autoscale_Remote_Access Security Group, with 3 rules, two to allow either RDP/SSH for the remote management of your Windows Server/Linux web servers and one to allow outgoing HTTP traffic to 169.254.169.254. This is a special IP address used by the K5 Cloud Init process which must be present during the VM build process. Although technically not required at the moment as this traffic is allowed out anyway by the default outbound rules, you may want to remove these default rules post deployment to secure your environment further (I’m yet to find a way to delete these default rules within a Heat stack. If you do delete these rules manually, you will need to add a further rule to allow the load balancer to send HTTP traffic to the Web_Autoscale_HTTP SG, as this is currently allowed using the default rule.)
The Web_Autoscale_LoadBalancer SG simply allows inbound HTTP from anywhere and the Web_Autoscale_HTTP SG allows only inbound HTTP traffic from members of the LoadBalancer SG, i.e. the Load Balancer.
The next section configures the auto scaling groups and resources such as the load balancer, VM config and policies. See the comments alongside the code for further information and for areas for customisation, such as min/max number of VM to deploy etc.
The final section configures the alarms and triggers used to scale out and scale in the number of VM instances. The periods and thresholds I’ve used are purely an example and you should tailor these to suit your particular environment, VM size, operating system and application. You should also monitor these values and application performance over a period of time, to ensure auto scaling is working correctly for your implemenation. Note that the CPU % rate is the average across all your deployed VMs and not a single VM.
Currently there is a limitation with this stack, in that it will not remove VM instance that the load balance has detected as unhealthy. The tricky bit here will be determining which of the VMs has the problem and then having a trigger which only deletes that VM, rather than scaling down the number of VMs. I might look at this challenge in a future blog, when I have more time.
So putting it all together we have the following. This includes all the parameters I used in my environment, so make sure you update them before you run the stack:
Your completed Heat stack should be saved locally as a *.YAML file. Before running it, ensure that no router, security group or network exists with the same names as specified within your Heat stack, as this can cause unpredicable results
1. To run the Heat stack, within your K5 IaaS portal, browse to ‘Project | Compute | Stack | + Create Stack’.
2. In the resulting screen, enter a Stack Name, select File and browse to your YAML file. Then specify a suitable time value (I’ve specified 40 minutes as it can take around 30mins to deploy this Windows Heat Stack) and specify Delete to remove any deployed resources, if the stack deployment was to not fully complete.
Once the status of the stack is shown as “CREATE_COMPLETE”, you will need to reapply the Router settings as described above. To do this :
1. Select ‘Project | Network | Virtual Router’, then select ‘Action | Gateway Settings’ against the heat stack created router i.e. Web_Autoscale_router
2. Ensuring the ‘External Virtual Network’ drop down box is showing the name of an external network, e.g. inf_az1_ext-net02, click the ‘Set(ting)’ button.
After a few minutes, verify that the web site can be accessed using the load balance DNS name from ‘Project | Network | Load Balancer | i.e. Web_Autoscale_LB
VM instances will be created with an auto generated name based on the following format:
“First 2 characters of the stack name” + “-” + “Last 11 characters of the resource name of the AutoScalingGroup” + “-” + “Random ID (12 characters)” + “-” + “Random ID (12 characters)” + “-” + “Random ID (12 characters)”