This article applies to vTM generally, on any platform, cloud or on-prem.
It includes notes specific to Microsoft Azure and may be updated in future with other platform-specific notes.
Follow all steps if vTMs are in separate private networks and NAT is used.
Follow only steps 6 and 7, if vTMs are configured with public IPs with no NAT involved.
Once a vTM in each desired region has been deployed, follow the below 4 steps on only one of them (other vTMs will join to this one):
1) Disable REST in System > Security.
2) Enable Multi Site Manager (MSM) in System > Traffic Managers.
3) Create a configuration location, in Catalogs > Locations, and assign the vTM to this location in System > Traffic Managers.
4) Set the External IP to the vTM's public IP.
Once done, follow the below 2 steps on all vTMs including the first:
5) The vTMs need to be able to talk to each other on tcp port 9080 and 9090 via their public IPs, so the network needs to be configured to route traffic going to the public IP (on those ports) to hit the vTM's private IP (NAT).
6) Ensure the security groups/firewall are setup to allow communication on tcp port 9080 and 9090 between the vTMs. This can be tested prior to clustering e.g. on vTM1:
nc -v <other vTM's public IP> 9080
If this gives an immediate "connection refused" error, that means it's working. If it hangs with no response, then packets are being dropped before hitting vTM. The reason for the connection refused is that access to this port within vTM is controlled with the System > Security > Cluster Communication > control!allow setting. Once clustered together this setting is automatically changed to 'all' and port 9080 will be open completely (vTM to vTM communication is encrypted, of course). The security groups/firewall can also be used to lock down access to this port to just the vTMs in the cluster.
To create the cluster, follow this step on all vTMs except the first:
7) Open the cluster join wizard, give it the public IP and public admin port of the first vTM, and follow the rest of the steps in the wizard.
· If the REST API, vWAF or Service Discovery features are required, and NAT is used (i.e. if NAT is used to connect from one vTM to another, steps 1-5), then the above steps aren't possible, because the External IP setting is only available when MSM is enabled, and MSM is incompatible with these 3 features.
In this case with NAT, if the vTMs need to load balance traffic to backend pools, then it's likely vTMs in one location cannot route traffic to backends in another, hence would see health monitor failures. In this case MSM features can be used, to have per-location config, but be aware that this would preclude using the above 3 features.
· The use case for requiring External IP, with REST, without any MSM features, is when vTM is performing only Global Load Balancing (aka Optimal Gateway Selection), where vTM serves DNS records from its builtin DNS server, and you want to manage this configuration with the REST API. If you need this then please raise a support case or talk to your account manager so that we can register your interest in RFE-1482, which is for exposing the External IP setting without MSM. Another option is to set up a VPN between the locations so that the vTMs can connect to each other without using NAT, then the External IP setting isn't needed.
· Services Director licensing does not require REST, because it can use Legacy FLA licenses which don't use REST.
|Microsoft Azure specific notes:
· vTM in Azure is published and deployed as an Azure Application through the Azure Marketplace. This uses an ARM (Azure Resource Manager) template to deploy one or more vTMs into a virtual machine scale set. Multiple vTMs within a single scale set can be clustered together, normally. A scale set exists only in a single region, so in order to have a cluster of vTMs in separate regions, multiple scale sets must be created, one in each region. However note that only one vTM in each scale set is possible, because each scale set has a public IP, and vTM requires other vTMs in the cluster to have a unique IP each. Having 2 vTMs in a scale set would appear to be at the same public IP to a 3rd vTM. If multiple vTMs per region are required, then deploy vTM from the Marketplace multiple times, resulting in one vTM per scale set.
· The ARM template used by the vTM Azure Application can be provided if other customizations to it are required, please raise a support case to request this. Pulse will provide the template but without assistance for modify/extending it, if assistance is needed then please talk to your account manager to request prof-serv work.
· For point 5, in the Azure console, in the Load balancer configuration, add a new load balancing rule for port 9080 to be "load balanced" to the single vTM in the scale set. (Other methods may be possible, e.g. adding an inbound NAT rule).
· For point 7, the external admin port is 50100 by default.