Hello everyone,
after a long time, I am back with a new post. Today I will drive you through the configuration of a load balanced Log Analytics Gateway (formerly OMS Gateway and briefly referred below as LAGW) installed on Azure Virtual machines, using the Azure Load Balancer.
In this post, I am not going to discuss capacity and sizing of the necessary virtual machines nor I am going to discuss the steps to install and configure them in an Availability Set.
Trust me 
, the size I went for is in line with the hardware requirements you can find in the Set up your system page and the availability set configuration was performed following the guidance and principles from the article Manage the availability of Windows virtual machines in Azure.
The topic:
Basically, the Log Analytics Gateway is an HTTP forward proxy dedicated to the outbound Microsoft Monitoring Agent communication with the Log Analytics workspace. Common circumstances in which you could use it are:
- Agents to be connected, do not have Internet access
- Your company proxy or firewall cannot be configured according to the requirements discussed in the page Network firewall requirements
- You might want to configure a single point to collect and send data from all the configured Log Analytics agents
- You are about to configure and run Services Hub On-Demand Assessments using the Agent + Log Analytics Gateway Method scenario
Despite the native redundancy capabilities offered by Azure, installing a single virtual machine acting as LAGW, represents a single point of failure hence you might want to make your LAGW highly available. Of course, Azure gives the ability of configuring load balancing as well as the On-premises does. Since the Network Load Balancing (NLB) configuration is documented in the Configure network load balancing page, below I will only focus on the Cloud part shortly summarizing what’s necessary to get to this configuration.
Planning the configuration:
Implementing this configuration requires you plan for the below items:
- Creation of 1 Availability Set to configure the virtual machines with. Should you already have the virtual machines installed, you can configure them to belong to an availability set using the script attached to this post (Thanks to Samir Farhat who created the previous versions located at https://gallery.technet.microsoft.com/Set-Azure-Resource-Manager-f7509ec4)
- Creation of, at least, 2 virtual machines on which you have installed the LAGW
- Creation of 1 Azure Load Balancer of type Internal (also referred as ILB) since you are making the internal IP Address highly available
- Find #1 available IP Address for the VIP in the virtual network
Configuring the Load Balancer:
Once you’ve finished the virtual machine configuration and installation (including the LAGW for which the installation procedure can found on page Connect computers without internet access by using the Log Analytics gateway in Azure Monitor) you can go ahead with the ILB configuration.
NOTE: the LAGW configuration (TCP port to be used for the gateway, proxy address and user for the company proxy the LAGW needs to communicate through) should be the same
First thing first, you need to create an ILB instance and configure the necessary settings.
- From the Azure Portal, write Load Balancers in the search box on the top of the page and click on the related result (see the blue arrow)
- Click Add to create a new ILB object
- Enter the necessary information as per your infrastructure making sure to select, for this specific purpose, the Internal type and Basic As far as the IP address assignment goes, you could go either Static or Dynamic. I would recommend Static
NOTE: Choosing a Static IP address, will require less changes on the agent configuration later on, making it also easier to associate a DNS Record to it so you can use the FQDN during agents configuration.
Click Review + Create
- Make sure to pass the validation check and to have entered the correct information and click Create
- It will take a while to deploy the new Load Balancer. Once finished you will get a blade similar to this in which you can click on the Go to resource button
- After the load balancer is created, a backend pool needs to be created, which distributes traffic to one or more gateway servers. From the left side menu, select Backend pools and click Add.
- Enter a name, associate it the availability set you created previously
- Click on + Add a target network IP configuration and select the IP corresponding to the virtual machines you want to balance and click OK
- Next you need to configure the Health probes. The health probe dynamically adds or removes the gateway servers from the load balancer rotation based on their response to health checks. On the left menu select Health probes and then click Add. Enter the necessary information according to the LAGW port you configured during the installation (this must be the same port the agents will connect to) and click OK.
- Configuration of Health probes is followed by the definition of a Load Balancing On the left menu, select Load balancing rules and then click Add. Enter the required information bearing in mind the following and the click OK:
- Port and Backend port must be the same
- Session persistence could be set to either Client Ip or Client Ip and protocol (see Configure source IP affinity settings)
- Since this is a dedicated rule and we create only one, Floating IP (direct server return) must be set to Disabled
- Last but not least, configure your agents to use the VIP or (Frontend IP Address) in the Proxy Settings tab and click Apply.
- If the configuration was done correctly, you should get the green check indicating that the agents is connecting to the Log Analytics workspace with no issues.
Hope that this post will make Log Analytics Gateway High Availability configuration smooth and easier.
Thanks,
Bruno Gabrielli
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.