Reaching external resources from a Service Fabric cluster is trivial whereas reaching the cluster from the internet requires some configuration. The virtual machine scale set, service endpoint and load balancer comes into play. On the first sight, it could be seen as a complicated as doing a puzzle, but understanding of mechanisms under the hood helps to realize that whole processes is easy.
Cluster setup
Let’s make a simple Service Fabric service which is reachable from a web browser and reports some information about state of its computation. To do this it’s necessary to fill in the port number 80 (which is the port of the HTTP protocol) to custom endpoints in the node type configuration of the Service Fabric cluster.
At this time, we will choose Stateless Web API. (This may not be the right choose for a computation service, but the focus of this example is on networking.) There are many configuration XML files in the solution. The most important of them (at this time) is ServiceManifest.xml.
Don’t make any changes, debug the application first and load the address http://localhost:19080/. You will see a Service Fabric Explorer. Then publish your app to the cluster and open the address http://<name>.<region>.cloudapp.azure.com:19080. You will see a Service Fabric Explorer. How to deny an access to this administration interface to everyone?
Service Fabric Explorer visibility
The Load balancer has a settings called Load balancing rules.
There are two rules that forwards TCP ports 19000 and 19080 to all nodes of the Test node type. If you delete those rules, the Service Fabric Explorer will not be accessible from the internet. But it also causes that the Azure Portal will not be able to show cluster state.
This means that if you wish to have visibility of your cluster via the Azure Portal then your load balancer must expose a public IP address and your Network Security Group must allow incoming traffic on port 19080. This is temporary limitation. Configuration of the publicly inaccessible cluster without any loss of management portal functionality will be possible in the upcoming months.
Health probes & Load balancing rules
The following image describes network scheme of the cluster.
The cluster contains only one node type (called Test). Every node type is de facto a separate virtual machine scale set. Load balancer distributes the traffic to particular node instances in accordance with Round-robin algorithm. When some node or application turns into unhealthy state, the load balancer stops send traffic there. The load balancer is taking advantage of health probes. Health probes actively checks individual endpoints and informs the load balancer about available health endpoints. When all instances are unhealthy the connection is timed out. This is why setting up all endpoints correctly is just not enough. All probes must be set up and running as well.
First, look up the ServiceManifest.xml file in the PackageRoot folder in the WebApi1 project and find the service endpoint (ServiceManifest / Resources / Endpoints). There is the port number of the HTTP protocol, which is in this case 8210.
Second, configure the load balancer in your Service Fabric cluster. It is unreachable from the cluster panel. You must list all resources in the resource group and find load balancer there. In the load balancer panel, select Health probes and configure the AppPortProbe1 probe. Set protocol to HTTP, change port to the number found in the ServiceManifest.xml file and set up correct path. The path is an URL which is called by the probe. If your application responses by HTTP 404 status code to the probe’s request, the application will be considered as unhealthy regardless its actual state. Lastly, click Save.
Third, select Load balancer rules on the load balancer panel and configure the AppPortLBRule1 rule. Change the backend port to the number found in the ServiceManifest.xml file and click Save.
Finally, open the URL of your Service Fabric cluster (http://<name>.<region>.cloudapp.azure.com/api/values) in the browser. You will be connected via load balancer to one of 3 instances of your WebAPI1 service. The service responds according to logic coded in the ValuesController class.
The path called by load balancer’s probe should not respond any data, but return a success or error status code only. Probe’s interval must be short in order to let react load balancer on application failure quickly. The application cannot be stressed just by probe calls.
This article has covered load balancer settings for stateless reliable service partitioned as a singleton (one primary replica). Partitioned or replicated services relies on Service Fabric Naming Service. This topic will be covered by another article.