Bind Load Balancer to Services (for hosting ASP.NET projects on limited amount of nodes)
Service Fabric should be able to create/configure Load Balancers for certain services and it should synchronize the Load Balancer in case of placement changes.
Right now there is one load balancer configured for the whole cluster. This means, every service that should be accessible through a public endpoint must be placed on every node. This is a waste of resources in cases where these services don't need this scale-out factor. This means, these services are wasting RAM, disk space and CPU and it also takes longer to update these services.
Desired scenario: The cluster has 5 VMs, WebApp-1 is placed on two nodes and is publically available, WebApp-2 is placed on 3 nodes and is also publically available. There are some other services which are not publically available (e.g. ReliableActor services)
This will get even more important in the future when ASP.NET 5 gets more popular and more people are using Service Fabric to host multiple public web apps.
A first solution could be to bind load balancers to node types. This way, we could create "webserver"-nodes and "backend"-nodes. However there might still be cases where this is too much: Imagine 5 "webserver"-nodes with one very big web app and a second web app which is very small and could easily be hosted on one or two nodes.
Therefore a more flexible solution would be to bind load balancers directly to services and dynamically adjust the load balancer when the services are moved to other/more nodes.
Grahame Horner commented
I believe that nginx running I front of the service fabric cluster would be a good options as a first step; this is a software configurable loadbalancer/reverse proxy the has an api which can be used to update the configuration as/when required by service fabric. IMHO writing an software defined network is not a service fabric task, but service fabric would definitely benefit from communication with a software defined network api that would allow for confirming nlbs etc..
Christopher Boarman commented
Ideally this would be a Service Fabric native load balancer available both in the cloud and on-premises (i.e., local stand-alone cluster support).
Having to place every actor on every node is the main reason we haven't started using Azure Service Fabric. It's the biggest anti-pattern and almost makes the entire architecture useless for some applications which would normally greatly benefit from the distributed system.
Marco Monducci commented
This is exactly what a Large company needs to finally eject its Enterprise Bus in order to create a ServiceFabric playground where anyone can deploy apps without taking care of Reliability because it's offered by the Service Fabric it self
Bishoy Demian commented
I think that since SF takes care of deploying the service and moving it between nodes automatically, then, it really is SF that should be the authority on where to find each service (discovery) and a load balancer should be an integral part of SF.
Christian Weiss commented
> Adam Toth: If you put your services on different ports the azure load balancer can probe which nodes are hosting which services and you don't need to put every service on every node.
Ideally, I wouldn't want to set the ports myself - Service Fabric is an orchestration tool and should deal with that.
Waiting for the load balancer probe expiration to figure out that stuff has moved somewhere else is not acceptable. This introduces way too many user-facing errors. This has to be an active process between Service Fabric and the load balancer.
we looked into service fabric but the current situation to access the services web endpoints from external is a deal breaker for us (on prem). placing every endpoint on every node is overkill.
Adam Toth commented
If you put your services on different ports the azure load balancer can probe which nodes are hosting which services and you don't need to put every service on every node.
Yonatan Leonov commented
Have a look at "Consul Template". It is a service which updates a template file based on changes happens in a Consul cluster. It can be used to reconfigure a load balanced with the current locations of a service in the cluster.
I think service fabric should implement something similar - a service which responsible to publish the current nodes of a service to an external load balancer (not only to the azure load balancer - other as well, F5, etc)
Instead of developing for each such device, the "template" idea is a nice one.
Other option is to have an extension point which let you register a class which will get notifications about each change and developers of each balancer (or other needed components) will be able develop a package to implement the changes.
I think the service manifest should include a parameter that tells whether it should be exposed to the lid balancer, and the cluster manifest should be able to include a global balancer device management endpoint (probably override per environment)
Until such solution exists - it either on the service developer to develop something like this, or to use a tool like Consul in parallel to the Service Fabric cluster - so every service instace will register itself to Consul - and Consul template will update the balancer (of course - only if the balancer supports file / api configuration changes)
This feature is important not only for public facing services, but for internal ones as well - unless the ServiceProxy knows somehow how many calls each active instance of internal service is currently handling / or what is the CPU lid on each service instance - we would still want a smart balancer even for internal communication.
Christian Weiss commented
@Jerome, yes this definitely is a good first step and solves many scenarios. However, I think it would still be great to bind load balancers directly to services.
Jerome Haltom commented
You are free to build the Service Fabric cluster yourself, using your own ARM templates. Multiple Load Balancers are possible, as are custom VM images and everything else.