We try to migrate our Platform from classical IIS hosting to a service fabric micro service architecture. So fare we learned that a service fabric lives in a virtual machine scale set and uses Load balancer to communicate to the outside world.
The Problem we now facing is that we have different access points to our application. Like one for browser, one for mobile app. Both use the standard https port, but are different applications.
In iis we could use host headers to direct traffic to one or the other application. But with service fabric we can’t. easiest way for us would be multiple public IP’s. With that we could handle it with dns.
We considered a couple solutions with no success.
Load balancer with Multiple public ip’s. Problem: it looks like that only works with Cloud Services and we need to work with the new Resource Manager World there it seems to be not possible to have multiple public ip’s.
Multiple public load balancer. Problem: Scale Sets accept only on load balancer instance pert load balancer type.
Application Gateway. Seems not to support multiple public ip’s or host header mapping.
Path mapping. Problem: we have the same path in different applications.
My questions are:
Is there any solution to use multiple IP’s and map the traffic internally to different ports?
Is there any option to use host header mapping with service fabric?
Any suggestion how I can solve my problem?
Piling on some Service Fabric-specific info to Eli's answer: Yes you can do all of this and use an http.sys-based self-hosted web server to host multiple sites using different host names on a single VIP, such as Katana or WebListener in ASP.NET Core 1.
The piece to this that is currently missing in Service Fabric is a way to configure the hostname in your endpoint definition in ServiceManifest.xml. Service Fabric services run under Network Service by default on Windows, which means the service will not have access to create a URL ACL for the URL it wants to open an endpoint on. To help with that, when you specify an HTTP endpoint in an endpoint definition in ServiceManifest.xml, Service Fabric automatically creates the URL ACL for you. But currently, there is no place to specify a hostname, so Service Fabric uses "+", which is the strong wildcard that matches everything.
For now, this is merely an inconvenience because you'll have to create a setup entry point with your service that runs under elevated privileges to run netsh to setup the URL ACL manually.
We do plan on adding a hostname field in ServiceManifest.xml to make this easier.
It's definitely possible to use ARM templates to deploy a Service Fabric cluster with multiple IPs. You'll just have to tweak the template a bit:
Create multiple IP address resources (e.g. using copy) - make sure you review all the resources using the IP and modify them appropriately
In the load balancer:
Add multiple frontendIPConfigurations, each tied to its own IP
Add loadBalancingRules for each port you want to redirect to the VMs from a specific frontend IP configuration
Add probes
As for host header mapping, this is handled by the Windows HTTP Server API (see this article). All you have to do is use a specific host name (or even a URL path) when configuring an HTTP listener URL (in OWIN/ASP.NET Core).
Related
Currently we own an application (App-A) which is hosted on Service Fabric cluster using VMSS instances. The VMSS instance has a public IP which points to App-A to route customer traffic. I want to add a new application (App-B) to the same service fabric cluster. How can I use the same VMSS instance to route customer traffic between App-A and App-B?
You can deploy AppB to listen on a different HTTP / HTTPS, that way the applications can run side by side on the same VM instance.
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-service-manifest-resources
You can use the built-in reverse proxy for this, or a more hardened product like Traefik.
A reverse proxy can look at the requested URL path, querystring parameters or headers, and route the request based on pre-defined rules.
E.g. /svc1/ goes to service 1 and /svc2/ goes to service 2.
I have a use case where my cluster has 3 VMs working as head node in HPC Pack and a bunch of other VMs working as compute nodes.
So basically, after creating this cluster, i must install a special HCP client, from this client, i type the DNS name of each of VMs to access the HPC management interface.
For example: https://head-node-1.azure.com
Of course, if i access this DNS from Chrome, i only see IIS page.
I wants to create a load balancer with its DNS name. Let's say https://load-balancer.azure.com
So from my client, every time i access load balancer DNS name, i can see the management interface, not IIS page.
How can i do that?
Not sure I'm understanding you correctly. Basically, Azure Application Gateway supports URL path-based routing rules.
Actually, Application Gateway supports web-based traffic load balancing. [Azure load balancer][2] supports stream-based traffic. If you want to listen to the protocol HTTP or HTTPS, you can use Application Gateway. Per your description, you could not access HPC management interface from web explorer, you could use a 4 layer load balancing based on TCP/UDP.
So you could create a public-facing load balancing and add the head node VMs as the backend pools. Create a health probe and load balancing rules to specify the ports you want to listen for your HPC management interface on the each of VMs.
Hope this helps, let me know if you have any concerns.
I received in hands a project where an Azure Application Gateway (AGW) uses as backend pool an Internal Load Balancer (ILB) App Service Environment (ASE) containing multiple apps.
The AGW is setup up using several multi-site listeners, where the host of the each multi-site listener matches a custom domain in an App Service instance running in the ILB ASE. Like this:
I need to add a new app to the ASE and corresponding configuration to the AGW.
The problem is that the AGW can have at maximum of 20 listeners, which has been reached in the project I received in hands. So I can't add more apps to the AGW with this setup.
To work around the listener limitation, with minimal changes, I would like to make use of multi-site path-based routing with the ILB ASE as backend pool.
I would like something that looks like the following:
I have spent some time going over the docs as well as other StackOverflow questions. I also have gone over the multi-site app service docs https://learn.microsoft.com/en-us/azure/application-gateway/create-web-app, including playing around with the -PickHostNameFromBackend switches.
I have made a few experiments without success so far.
I believe that what I want to do is currently not supported by the AGW. I think I understand why. The hostname passed from the AGW to the ILB ASE (api.example.com) is not present as custom domain in any of the App Service instances in the ASE, so the request will not be fulfilled. Correct me if I am wrong please.
Is my desired setup (Figure 2) possible ?
If not possible, what would be alternative solutions, with only one AGW as I have today?
Firstly you can open a support ticket to increase the listener/backend pool count from 20 to 40. That should offer you some expansion room immediately.
The second scenario should be possible as well. You should use api-aaa.example.com and api-bbb.example.com as backend pool members. And use the switch PickHostNameFromBackendAddress on HTTPSettings and also create a custom probe with PickHostNameFromBackendHttpSettings flag set and associate probe to the HTTPSetting. The you would use this setting in each path based rule while associate paths to backend pools. Please ensure that your internal DNS within VNet, can resolve api-aaa.example.com and api-bbb.example.com to the ILB IP 222.222.222.222.
We've got an API micro-services infrastructure hosted on Azure VMs. Each VM will host several APIs which are separate sites running on Kestrel. All external traffic comes in through an RP (running on IIS).
We have some API's that are designed to accept external requests and some that are internal APIs only.
The internal APIs are hosted on scalesets with each scaleset VM being a replica that hosts all of the internal APIs. There is an internal load balancer(ILB)/vip in front of the scaleset. The root issue is that we have internal APIs that call other internal APIs that are hosted on the same scaleset. Ideally these calls would go to the VIP (using internal DNS) and the VIP would route to one of the machines in the scaleset. But it looks like Azure doesn't allow this...per the documentation:
You cannot access the ILB VIP from the same Virtual Machines that are being load-balanced
So how do people set this up with micro-services? I can see three ways, none of which are ideal:
Separate out the APIs to different scalesets. Not ideal as the
services are very lightweight and I don't want to triple my Azure VM
expenses.
Convert the internal LB to an external LB (add a public
IP address). Then put that LB in it's own network security
group/subnet to only allow calls from our Azure IP range. I would
expect more latency here and exposing the endpoints externally in
any way creates more attack surface area as well as more
configuration complexity.
Set up the VM to loopback if it needs a call to the ILB...meaning any requests originating from a VM will be
handled by the same VM. This defeats the purpose of micro-services
behind a VIP. An internal micro-service may be down on the same
machine for some reason and available on another...thats' the reason
we set up health probes on the ILB for each service separately. If
it just goes back to the same machine, you lose resiliency.
Any pointers on how others have approached this would be appreciated.
Thanks!
I think your problem is related to service discovery.
Load balancers are not designed for that obviously. You should consider dedicated softwares such as Eureka (which can work outside of AWS).
Service discovery makes your microservices call directly each others after being discovered.
Also take a look at client-side load balancing tools such as Ribbon.
#Cdelmas answer is awesome on Service Discovery. Please allow me to add my thoughts:
For services such as yours, you can also look into Netflix's ZUUL proxy for Server and Client side load balancing. You could even Use Histrix on top of Eureka for latency and Fault tolerance. Netflix is way ahead of the game on this.
You may also look into Consul.io product for your cause if you want to use GO language. It has a scriptable configuration for better managing your services, allows advanced security configurations and usage of non-rest endpoints. Eureka also does these but requires you add a configuration Server (Netflix Archaius, Apache Zookeeper, Spring Cloud Config), coded security and support accesses using ZUUL/Sidecar.
I am evaluating the convenience of moving to azure. Currently, I am trying to figure out how to balance the load and make routing for different websites on the same machine. I saw tutorials where a user created a separate LB on a different VM. I also found many articles about the possibility to balance the load using Azure load balancing.
So I assume both are possible, is that correct?
I would like to know how to connect between machines on azure. Would it be possible to do so using a local ip, machinename, or dns?
I also need to figure out how to forward traffic to different ports based on http header, is that possible without a seperate machine as load balancer? I see the endpoint config in my azure dashboard and found the official documentation, but unfortunately it's not enough for my understanding.
Currently, I am trying to figure out how to balance the load and make
routing for different websites on the same machine.
You can have different web sites on the same machine by configuring virtual hosting on IIS. This is accomplished using host header. VM, Cloud Service or even Websites supports this functionality. VMs and Cloud Services should be pretty straight forward. Example using websites:
Hosting multiple domains under one Azure Website
http://blogs.msdn.com/b/cschotte/archive/2013/05/30/hosting-multiple-domains-under-one-azure.aspx
I also found many articles about the possibility to balance the load
using Azure load balancing.
LB for VMs are as easy as creating a load balance set inside endpoint configuration wizard. Once you create a balance set, for example, enpoint HTTP port 80, you can assign this balance set to any VM on the same cloud service. All requests to port 80 would be automatically balanced across all VMs in the set.
So I assume both are possible, is that correct?
Yes.
I would like to know how to connect between machines on azure. Would
it be possible to do so using a local ip, machinename, or dns?
You just have to create a virtual network and deploy the VMs to it. Websites (through preview portal only), Cloud Services and VMs supports VNet.
Virtual Network Overview
https://msdn.microsoft.com/library/azure/jj156007.aspx/
I also need to figure out how to forward traffic to different ports
based on http header, is that possible without a seperate machine as
load balancer?
Not at this moment. Best you can have with native Azure Services is a 3-tuple (Source IP, Destination IP, Protocol) load balance configuration.
Azure Load Balancer new distribution mode
http://azure.microsoft.com/blog/2014/10/30/azure-load-balancer-new-distribution-mode/
depending on how you're deploying there's a couple of options:
first of all: LB sets in VM's in a cloud service. For this the Cloud service acts as the LB. this can only be achieved when using a standard sku VM.
second of all in Azure WebApps : load balancing is achieved automagically when deploying through standard means, since scaling is foreseen here.
Third of all there's Cloud Services with roles, who also do this "automagically".
Now none of that seem to apply to your needs. you can also start thinking about using traffic manager, something with a little more bite :-)
have you read this article by any chance? http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-load-balance/
I'd like to advise you to add different endpoints to your VM's work with traffic manager and ake sure you IIS has all the headers on the correct ports (cause i'm assuming that's what you're doing already)