When we speak of cloud we always think of Platform as a service (PaaS), Infrastructure as a service (IaaS) and Software as a Service (SaaS).
In this article we discuss about the IaaS and how to scale websites or applications running in virtual machines that forms a part of IaaS infrastructure. In simple terms, IaaS means we buy a storage from cloud provider and we deploy or create our own machines or provider’s pre-built Images and we control the infrastructure like operating systems, ports and all the software installed on the machines.
Common scenarios for opting to IaaS is when a company wants to setup a testing environment for a particular period of time, or a dev team is doing some R&D and needs a machine with particular configuration for temporary purpose and later those machines will be decommissioned. This way, we do not need to invest on the infrastructure that we use only for a particular amount of time. But this may not be correct always. It always depends upon the requirements.
Before jumping into the details on how to create ILBs, let us try to understand how ILBs differ from typical load balances (F5s).
F5 Load Balancers:
Figure 1: F5 Load balancers (Firewall sitting between is optional)
F5 load balancers primarily sit between clients and the hosts that provide the services.
F5 load balancers typically are used when we expose our services to the outside of our company network. This does not mean they will not be used within the company network. But when we deploy our services or applications in ON PREMISE and want to expose the services/applications to the outside world.
The typical transaction flow will be as follows:
Let us make the following assumptions to understand the transaction flow:
Load Balancer URL – 192.168.89.1
Web Server 1 – 192.168.77.76
Web server 2 – 192.168.77.77 and the service name - weatherinfo
Figure 2: Load balancing flow between the clients and the hosts through Load Balancers
Load Balancers uses the health monitoring mechanism to periodically check the health of the hosts and accordingly will forward the request to the host. A simple health check mechanism will be PINGING to the server and checking for the response. Next level mechanism is to deploy the health check application that provides the health of the intended service and gives accurate information to the Load balancer if it has to forward a request or not.
If health of all the hosts are good then LBs use Round Robin as a simple mechanisms to complex algorithms based on connection counts, host utilization and other important criterion to decide which host needs to be responding to a particular request.
Internal Load Balancers (ILBs):
ILBs comes into picture when we talk about Cloud services created in AZURE, AWS and so on. Unlike Load balancers, ILBs supports the following types of load balancing:
- Load balancing between the virtual machines within a cloud service.
- Load balancing between virtual machines between different cloud services that are contained within a virtual network.
In this article, we would be going through the first type i.e. load balancing of incoming internet traffic to different virtual machines within a cloud service. This is also called as Network Level type of load balancing.
Figure 3: ILB with VMs
Let’s go through the steps to create the ILB by creating two virtual machines and creating a load balanced set to load balance the two VMs. There is no direct way to create Load Balanced set in portal and it should be done as a part of creation of VMs.
Step 1: Create a cloud service first so that we can add the VMs to the cloud service. (I am not using portal instead I am using manage.windowsazure.com for this article)
Figure 4: Creation of cloud service
2. Create a Virtual machine.
Figure 5: Selecting Compute à Virtual Machine
Figure 6: Choosing the image (Windows server 2012 R2 Datacenter)
Figure 7: VM Configuration
Figure 8: Added HTTP and HTTPS endpoints by clicking “Add” button on the bottom of the page
Step 3: Now select HTTPS endpoint and click edit icon and create a LOAD-BALANCED SET. I want to load balance the VMs through the port 443.
Figure 9: Editing the HTTPS endpoint to create a Load Balanced set
Figure 10: Setting the load-balanced set details
In the figure 9, Probe Protocol indicates which protocol does the load balancer should use to probe the health of the VM and the port denotes the port to be used, Probe Interval tells the load balancer to attempt a TCP connect to the specified probe port for every 15 seconds. If it did not get TCP ACK back for two times (Number of probes), then it will consider that the node is offline and will stop traffic to that node.
Figure 11: Check the load-balanced set is created on HTTPS endpoint 443.
Now create another VM by following the above steps and then add a HTTPS endpoint and select option “Add an endpoint to an Existing load balanced set” and proceed.
Figure 12: Adding an endpoint to an existing load balanced set
After completing the above steps, create a website in IIS for both the VMs and expose the sites on port 443. I have created a website with a simple html page in both the VMs. For VM1, the html displays the text “This is from WEBMAC1” and for VM2 it displays “This is from WEBMAC2”.
Now when I browse
Figure 13: Website page
Now browse the cloud service and you should see the web page randomly displaying the messages from the both the boxes. Try to stop the website in one of the box or stop the VM and see if you are still able to browse. It should not be trying to hit the stopped VM or website.
Additional points:
In the figure 6 while creating VMs, I did not add “Availability Set”. But if you create one and assign it to both the VMs, Windows Azure will make sure that the two VMs are created on separate racks in the data center. This will also help during the host patching by not taking down all the nodes at same time and makes sure that your application will always run. This is most critical in any organization that needs 24/7 availability.
Also while configuring load balanced set, I have configured on TCP port. But you can do the same with HTTP port. This will allow you to write your own website or app that informs the health of the application which is more accurate than hitting the TCP port. You can add your custom logic to tell if the application is healthy. For example, if your application is not able to talk to database from the hosted server, you do not want the requests to be forwarded to that server and thus you can eliminate error screens for clients.
One more thing is that I have used same port 443 for both application and probing port. In real time situations they need not be or will not be same. Also for HTTP probes make sure that the application on that port does not support any authentication mechanism. It should respond without providing any credentials.
In real time scenarios, we will not follow the manual steps mentioned in the article. It will be easier to perform these in automated fashion using Powershell. You can check MSDN for more information on using Powershell scripts.
