2

I'm trying to get a proof of concept going for a multi-tenancy containerized ASP.NET MVC application in Service Fabric. The idea is that each customer would get 1+ instances of the application spread across the cluster. One thing I'm having trouble getting mapped out is routing.

Each app would be partitioned similar to this SO answer. The plan so far is to have an external load balancer route each request to the SF Reverse Proxy service.

So for instance: tenant1.myapp.com would get routed to the reverse proxy at <SF cluster node>:19081/myapp/tenant1 (19081 is the default port for SF Reverse Proxy), tenant2.myapp.com -> <SF Cluster Node>:19081/myapp/tenant2, etc and then the proxy would route it to the correct node:port where an instance of the application is listening.

Since each application has to be mapped to a different port, the plan is for SF to dynamically assign a port on creation of each app. This doesn't seem entirely scaleable since we could theoretically hit a port limit (~65k).

My questions then are, is this a valid/suggested approach? Are there better approaches? Are there things I'm missing/overlooking? I'm new to SF so any help/insight would be appreciated!

Joseph
  • 93
  • 1
  • 5
  • Maybe the approach of different ports is not applying for you if you want your solution being scalable. You can map on IPs, on other domains and even work with sockets (which I wouldn't advise here). You even can use combinations (including different ports too) to maximize the amount of possible mappings. – David Jun 05 '18 at 00:06
  • Thanks for the reply @David. Do you have any resources to read up on for those options? I don't think scalability is going to be an issue, especially early on. It just seems to me like there has got to be a better way to do this. – Joseph Jun 05 '18 at 00:58
  • Sorry no. I just mentioned about very general options for network-service related problems and implementation in Service Fabric might give you more restrictions or require special solutions. The question is Interesting related to scalability primary because ports are limited like you explained. I'd stick to the docu of Service Fabric and perhaps azure, it's possible that azure offers a different approach that I never considered. – David Jun 05 '18 at 01:09

2 Answers2

1

I don't think the Ephemeral Port Limit will be an issue for you, is likely that you will consume all server resources (CPU + Memory) even before you consume half of these ports.

To do what you need is possible, but it will require you to create a script or an application that will be responsible to create and manage configuration for the service instances deployed.

I would not use the built-in reverse proxy, it is very limited and for what you want will just add extra configuration with no benefit.

At moment I see traefik as the most suitable solution. Traefik enables you to route specific domains to specific services, and it is exactly what you want.

Because you will use multiple domains, it will require a dynamic configuration that is not provided out of the box, this is why I suggested you to create a separate application to deploy these instances. A very high level steps would be:

  • You define your service with the traefik default rules as shown here
  • From your application manager, you deploy a new named service of this service for the new tenant
  • After the instance is deployed you configure it to listen in a specific domain, setting the rule traefik.frontend.rule=Host:tenant1.myapp.com to the correct tenant name

You might have to add some extra configurations, but this will lead you to the right path.

Regarding the cluster architecture, you could do it in many ways, for starting, I would recommend you keep it simple, one FrontEnd node type containing the traefik services and another BackEnd node type for your services, from there you can decide how to plan the cluster properly, there is already many SO answers on how to define the cluster.

Please see more info on the following links:

https://blog.techfabric.io/using-traefik-reverse-proxy-for-securing-microservices-on-azure-service-fabric/

https://docs.traefik.io/configuration/backends/servicefabric/

Diego Mendes
  • 10,631
  • 2
  • 32
  • 36
  • @Joseph did you ever manage to build something like what Diego suggested? Just wondering if such a management solution is partially shareable, because we are looking into building something exactly like you are suggesting. – Esben Bach Dec 10 '19 at 06:11
0

Assuming you don't need an instance on every node, you can have up to (nodecount * 65K) services, which would make it scalable again.

Have a look at Azure API management and Traefik, which have some SF integration options. This works a lot nicer than the limited built-in reverse proxy. For example, they offer routing rules.

LoekD
  • 11,402
  • 17
  • 27
  • True but with upgrade and fault domains the instances are usually spread across multiple nodes. I'd have to manage which instances can go where. I could at that point add placement constraints for each app to control which nodes the instances can go on. I think just adding another separate cluster might be better at that point? I do agree though at some point I'm going to have to have to ditch the SF reverse proxy for something more robust. – Joseph Jun 06 '18 at 20:37
  • Service Fabric manages proper placement for you, provided you have configured your fault domains correctly. https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-resource-manager-cluster-description – LoekD Jun 07 '18 at 06:22