Intro
Welcome to Part 11 of the AVI/ALB Lab In the previous post, we configured the creation of the Avi IPAM Profile.
In this post we’ll cover the creation of a basic Virtual Service.
What is a Virtual Service?
Depending on which documentation you read a Virtual Service is described in slightly different ways, the Avi networks documentation on their website describes it as
‘Virtual services are the core of the Avi Vantage load-balancing and proxy functionality. A virtual service advertises an IP address and ports to the external world and listens for client traffic. A virtual service can be thought of as an IP address that Vantage is listening to, ready to receive requests.’
Other docs describe it as below which I think is the better description.
A Virtual Service is the primary software construct that:
- Groups all the software components needed to load balance client traffic
- Provide reporting functionality.
Components
The minimum components required to create a Virtual Service are:
- A name for the Virtual Service
- At least one Virtual IP address and listening port
- An application type or Profile
- System-HTTP or System-Secure-HTTP for example
- At least one network type or Profile
- System-TCP or System-UDP for example
- A Virtual Service is normally associated with a Pool however this is not a requirement
So from our build perspective the Virtual Service is where we configure the settings needed to setup the load balancer service for our application.
The build
OK lets get started after all that pre-config we are finally ready to deploy our first virtual service 🙂
We’ll do a basic setup just to get it up and running quickly. Most of the time you will use the advanced setup however you can use basic and then edit it later adding in advanced settings as needed.
Navigate to Applications and the either Dashboard or Virtual Services both will work, then click CREATE VIRTUAL SERVICE and select Basic Setup
Select the NSX-T cloud and click Next
Give it a name, you can change the Service port / Application Type if you need to I’m just going to leave it at HTTP and port 80, if you setup the IPAM then you will have the tick box to enable Auto Allocate if not you’ll need manually enter an IP for the VIP.
Select the Network for VIP Address Allocation from the dropdown list this is my VIP Network.
Select the Subnet from the IPv4 Subnet dropdown then select the T1 from the Tier1 Logical Router dropdown.
Scroll down.
Here we create our pool of servers that will provide that we will be load balancing you can either type the IP, an IP range the DNS name of the servers, use an IP group or use NSX-T Security Tags which you will need to have setup before hand.
If you use an IP or DNS name then add them in the box and click Add Server
If you are using an NSX-T group then select the Security Groups radial then select the group from the dropdown
When using Security Groups you will not see the servers added in the box below.
Click Save
We will now be taken to the Portal UI of the Virtual Service.
If you hover over the big red ! you can see the status of the deployment.
Here we can initially see that the SE is being created, if you look at the vCenter you will see this happening.
Next it will change to
State: Pending
Reason: Waiting for Service Engine DCA-Avi-se-vqcij to connect to controller
This may take a while as the VM needs to boot up get an IP then talk back to the controller. After this it will get a vNIC added to the VIP Segment and P’s allocated for this vNIC and the VIP.
Once it all complete we will get a nice green health score 🙂
So what just happened on vSphere and NSX-T?
If we take a look at vCenter we can see that Avi has deployed two SE’s into the AVI-SEs folder, the reason there are two SEs is because of the settings on the SE Group that states N+M. N being the min number of SEs and M being the buffer, by default that will deploy 1 + 1 buffer so we end up with 2 SEs.
I’ll get into the HA settings in another blog post as there are a few different options and each leads to different numbers of SEs and VS’s per SE etc
If we look at the VM’s we can see that one of them has been assigned an additional vNIC attached to the AVI-VIPs segment, the reason only one of them is attached is again due to the default HA setting of N+M if we were to change the HA mode to Active-Active which is the preferred but not default then both the SE’s would be attached and participating in the load balancing.
Looking at NSX-T we can see that the DCA-T1 has had a default route added automatically to the Web-VS.
With the next hop being 10.10.0.51
If we take a look on Avi at the VS by hovering over the top left corner it will bring up the info screen shown below here we can see the SE thats assigned and the VIP address of 10.10.0.50
If we switch to Infrastructure, Service Engine select the NSX-T cloud and then edit the DCA-Avi-SE-vqcij SE by clicking the pencil we can see that it now has a Data Network with an IPv4 IP of 10.10.0.51 which is what the T1 static route is point to as the next hop. If the active SE changes for example if we reboot the active one then the route on the T1 will be changed to point to the other SE IP as the next hop.
So lets test our app to make sure its working.
I have a simple 3 tier app with the web servers IP’s being 10.100.1.11 and 10.100.1.12 these VMs are tagged in NSX-T and so a created as a pool in Avi as I used tags to define the pool members.
Lets connect to http:10.10.0.50 which is the VIP. We can see we have hit Web02
So it works 😀 lets refresh to page. We can see that we now hit Web01 thus proving the load balancer is working.
With that the lab guide is done, next up covering the more advanced features of Avi. I hope you enjoyed this series and found it helpful.