Networkingedit
Virtual networkedit
The template can deploy a new virtual network and attach Elasticsearch and Kibana to it, or can use an existing virtual network in the same Azure region as the resource group being deployed to.
Using an existing virtual network requires a subnet to exist to which to attach the deployed resources and a known available private IP address to use as the static address for the internal load balancer, which Kibana will use to communicate with the cluster. The subnet also needs to have a sufficient number of available IP addresses for all of the resources that will be attached. The following parameters are related to virtual network configuration
-
vNetNewOrExisting -
Select
neworexistingto deploy a new virtual network or use an existing virtual network, respectively. An existing virtual network in another resource group must exist in the same Azure location as the target location to be valid. Default isnew. -
vNetName -
The name of the virtual network. Defaults to
es-net. -
vNetClusterSubnetName -
The name of the subnet to which deployed VMs and load balancers will be attached.
When using an existing virtual network, the subnet must already exist. Defaults
to
es-subnet. -
vNetLoadBalancerIp -
The private IP address to use when configuring the internal load balancer.
Must be an available IP address on
the provided vNetClusterSubnetName. Defaults to
10.0.0.4.
When deploying a new virtual network, the following parameters also apply
-
vNetNewAddressPrefix -
The address space when creating a new virtual network. Defaults to
10.0.0.0/24. -
vNetNewClusterSubnetAddressPrefix -
The address space of the
vNetClusterSubnetNamesubnet. Defaults to10.0.0.0/25.
When attaching to an existing resource group, the following parameter also applies
-
vNetExistingResourceGroup - The name of the resource group in which the existing virtual network is deployed. The resource group must exist in the same Azure location as the target location.
Check private IP address availabilityedit
A private IP address can be checked to see if it’s available within a virtual network with
Azure CLI 2.0.
az network vnet check-ip-address --name "<vnet name>" \ --ip-address "<ip address>" \ --resource-group "<resource group>"
Azure PowerShell.
Test-AzureRmPrivateIPAddressAvailability -VirtualNetworkName "<vnet name>" ` -IPAddress "<ip address>" ` -ResourceGroupName "<resource group>"
Azure DNS resolutionedit
Azure DNS resolution can resolve VMs within a virtual network by hostname, and is relied upon by the template to form an Elasticsearch cluster, by seeding each node with the hostnames of each master-eligible node. IP addresses are not used since they are dynamically allocated to VMs within the template.
The template uses a predictable convention when assigning hostnames to VMs, naming
them master-, data- and client- for master, data and coordinating nodes,
respectively, followed by an incrementing integer starting at 0.
Such a convention is problematic when it comes to deploying more than one cluster to the same virtual network however; Azure infrastructure does not prevent you from creating a new VM with the same hostname as an existing VM attached to the target virtual network, leading to Azure DNS resolving the hostname to the last attached VM.
For this reason, the template exposes the following parameter
-
vmHostNamePrefix - Prefix the name of each hostname in the cluster. The prefix can be up to 5 characters in length, must begin with an alphanumeric character and can contain alphanumeric and hyphen characters.
If a custom DNS is specified, it’s possible to configure your own DNS servers to resolve hostnames correctly, by forwarding DNS queries to Azure to resolve. This should be configured on the virtual network so that if VMs are shut down or moved around, they will have the correct configuration when starting up.