Infrastructure]1
Info picture - all servers should have the same configurations and websites and ports.
The goal is that on all virtual servers in VMSS are running the different websites ( www.xxx.com , www.yyy.com , wwww.zzz.com )
The SSL termination should be done at Front Door that is clear to me.
Questions: Where should i place the public ip? What should i configure that all websites are running and avaiable for users in application pool? I don't find a tutorial which describes my infrastructure. Could someone help me in this case?
Please help me thanks.
Front Door is global load-balancing services which distribute traffic from your end users across your regional backends.
Load Balancers and Application Gateways are regional load-balancing services which provide the ability to distribute traffic to virtual machines (VMs) within a virtual network (VNETs) or service endpoints within a region.
https://learn.microsoft.com/en-us/azure/frontdoor/front-door-lb-with-azure-app-delivery-suite#choosing-a-global-load-balancer
Here is an example of Microsoft Azure DR architecture with Application Gateway, Front Door, Load Balancer and Traffic Manager.
https://learn.microsoft.com/en-us/azure/frontdoor/front-door-lb-with-azure-app-delivery-suite
Considering your solution, you should configure SSL on FrontDoor and configure Application Gateway as backend.
Application Gateway should have VMSS configured as backend.
Related
I am working on following architecture.
We are following hub and spoke topologies
We are looking at having two Application Gateways (1 in the Hub and 1 in the Lab)
a. They really need an App Gateway in the HUB?
b. And Whether customer can consider having may be Azure Front Door in replacement for the App Gateway.
Has anyone done any critical research around this, any case studies or reference Architecture on the same? Any thought?
Azure Application gateway is a regional load-balancing service that distributes traffic within virtual networks across virtual machines (VMs) or zonal and zone-redundant service endpoints within a region.
Whereas Azure Front Door is a global load-balancing service that distributes traffic across regional backends, clouds, or hybrid on-premises services to the closest available backend.
If your hub and spokes are in the same region and you want to load balance traffic between them, you can go with Azure Application gateway.
Refer : https://learn.microsoft.com/en-us/azure/architecture/high-availability/ref-arch-iaas-web-and-db
If your hub and spokes are in different regions and you want to load balance traffic between them, you can go with Azure Front Door.
Refer : https://learn.microsoft.com/en-us/azure/architecture/example-scenario/signalr/#azure-front-door
If you would like to load balance or route traffic within a virtual network or internally, you can use a combination of Application gateway and Front Door OR use the latest Azure Front Door Premium tier where you can enable Private Link to connect to origins behind an internal load balancer over a private endpoint.
Refer : https://learn.microsoft.com/en-us/azure/architecture/example-scenario/multi-saas/multitenant-saas
https://learn.microsoft.com/en-us/azure/frontdoor/private-link
So, it all comes down to your requirement. You can configure any of the below:
1 Application gateway to load balance the traffic in the same region
1 Azure Front Door to load balance traffic between different regions
2 Application gateways and 1 Azure Front Door Classic to load balance
internal traffic in different regions
1 Azure Front Door Premium with private endpoint to load balance internal traffic in different
regions
Just wanted the recommendations in using azure frontdoor or azure traffic manager for my 2 different web apps hosted on different regions? Can we use both together?
Both Azure front door and traffic manager are deployed in a region agnostic way by azure to help load balance instances between region pairs. If you are hosting web applications using azure app service, the recommend solution for load balancing between regions is Front Door since your traffic is Http(s). (whereas a traffic manager would work nice if you are running virtual machines in different regions and want to load balance between them)
And if you want to further load balance traffic between different web apps in the same region, use an azure application gateway. (your front door directs user traffic to a region, and within that region, the application gateway directs traffic to a healthy web app.)
You can read this for a decision tree of the load balancing options provided by microsoft : https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/load-balancing-overview#decision-tree-for-load-balancing-in-azure
IMHO you should use the one that makes more sense. Traffic Manager you can work with different algorithms when routing to the right region, while Front Door you don't have this flexibility.
On the other hand, Front Door offers some features like Web Application Firewall (WAF) and SSL Offloading that may be interesting in your scenario.
Note: I'm still in learning phase.
Question: For the scenario described below, in the Load Balancing Settings for the two VMs for the FrontEnd subnet should I choose Application Gateway or Azure Load Balancer?
In Azure portal, when I create the VMs for FrontEnd, the Networking tab of the wizard, gives me two choices shown below:
Why the confusion:
For Load Balancing Internet Traffic to VMs, this tutorial does not choose Application Gateway. But the 5th bullet of the following scenario seems to indicate I should choose Application Gateway
Scenario
This tutorial from official Azure team describes designing an infrastructure for a simple online store as follows:
The above configuration incorporates:
A cloud-only virtual network with two subnets (FrontEnd and BackEnd)
Azure Managed Disks with both Standard and Premium disks
Four availability sets, one for each tier of the online store
The virtual machines for the four tiers
An external load balanced set for HTTPS-based web traffic from the Internet to the web servers
An internal load balanced set for unencrypted web traffic from the web servers to the application servers
A single resource group
you can use both, its a matter of your needs. load balancer just forwards traffic to your vms, while application gateway can do path based routing, ssl offloading, has WAF capabilities, and so on. But it costs a lot more and is clunky.
Looking at the bullet points you've listed, your case will work with both of these solutions.
ps. Like Rahul mentioned, load balancer works on level 4 and is not HTTP aware, Application Gateway is a level 7 load balancer.
Can we have a single Application Gateway for all VMSS created in different regions?
If yes please share the possible options.
As the comment mentioned, we could not have a single Application gateway for all VMSS created in a different region since Application Gateway is always deployed in a virtual network subnet and it directly supports to deploy the VMSS as the backends in the same region and virtual network as the Application gateway.
As a workaround, you could use a public IP address as the backend for communicating with instances outside of the virtual network as long as there is IP connectivity. Read more details about backend pools. So you may use a public-facing load balancer associated with the VMSS.
Furthermore, you also could use Traffic Manager to distribute traffic across multiple Application Gateways in different datacenters. Or use Azure Front Door Service provides a scalable and secure entry point for fast delivery of your global web applications.
We are tying to achieve this.
From my understanding, we should place the outside interface of the SF loadbalancer on a private network and then connect to the App Gateway's LB internal interface using Azure Virtual Network Peering.
Is this doable, are there any issues with this?
Yes, it's doable. There are multiple approaches you could go with -
Deploy App Gateway pointing at sf nodes directly, like shown here - Fine Granular Microservices Load Balancing with Azure Service Fabric and Application Gateway
Deploy App Gateway pointing at SF LB
Catches:
There are limitations around
how many Backend Address Pools you could have(up to 20), and how many machines and http settings each pool could run with. So, for instance, if you have SF cluster with the thousands
of services hosted at different ports, think through using SF LB and SF Reverse Proxy.
Azure Application Gateway requires its subnet. When creating a virtual network, ensure that you leave enough address space to have multiple subnets. Once you deploy an application
gateway to a subnet, only additional application gateways can be added to the subnet.
While digging into your question, I've found out that App Gateway might not play nice with websockets under certain circumstances. Check out
Communication through Azure Application Gateway blocked for WebSocket traffic for the details.
P.S.
If SF LB of yours is public you don't need VNET peering. The same works for private SF LB and Application Gateway installed into the same VNET.
I think there is better support to abstract Service Fabric by using Azure API management instead of Application Gateway.
I presume your SF is on Azure then API management has built in support for Service fabric so you dont have to do end point resolution or get partition key etc