We are moving a workflow of our business to Azure. I currently have two VMs as an HA pair behind an internal load balancer in the North Central US Region as my production environment. I have mirrored this architecture in the South Central US Region for disaster recovery purposes. A vendor recommended I place an Azure Traffic Manager in front of the ILBs for automatic failover, but it appears that I cannot spec ILBs as endpoints for ATM. (For clarity, all connections to these ILBs are through VPNs.)
Our current plan is to put the IPs for both ILBs in a custom-built appliance placed on-prem, and the failover would happen on that appliance. However, it would greatly simplify things if we could present a single IP to that appliance, and let the failover happen in Azure instead.
Is there an Azure product or service, or perhaps more appropriate architecture that would allow for a single IP to be presented to the customer, but allow for automatic failover across regions?
It seems that you could configure an application gateway with an internal load balancer (ILB) endpoint. In this case, you will have a private frontend IP configuration for an Application Gateway. The APPGW will be deployed in a dedicated subnet, it will exist on the same VNet with your internal backend VMs. Please note in this case you can directly add the private VMs as the backends instead of internal load balancer frontend IP address because of private APPGW itself is an internal load balancer.
Moreover, APPGW also could configure a public frontend IP configuration, if so, you can configure the APPGW public frontend IP as the endpoints of the Azure traffic manager.
Hope this could help you.
Related
I am trying to load some rest services using cloudformation as ECS Service with Fargate.
I don't want a public domain name for these services. I will access them internally from my AWS Lambda functions.
I realized AWS Fargate needs load balancing and Load balancer needs certificate and certificates needs a domain name.
Probably I am missing something but I tried to load AWS Fargate without a load balancer and I was unable to access it from Lambdas.
The question is; how do I run my services on ECS with Fargate without Load Balancer?
Use ECS Service Discovery to set up private DNS records that allow your application to discover service endpoints without using a load balancer or having to create public DNS records. Service Discovery works by creating private DNS records in Route 53 that are queryable from within your VPC, so that you can find the IP addresses for all of the tasks running in a service. If you're running multiple tasks you will get multiple A records back, one per task, so you will need to do client-side load balancing by picking a random record in the returned set.
The documentation linked above is a little vague so here are some more specific instructions: When creating your service in the console, in Step 2: Configure Network, check the Enable service discovery integration checkbox. Then specify "create new private namespace" and supply a name for your namespace, such as foo.app. Then select the "Create new discover service" radio button, and specify a name for your service (such as service1). Leave the rest of the settings in the Service discovery (optional) section as default.
Now from within your VPC, you'll be able to look up service1.foo.app and get back A records with the IP addresses of all of the tasks running in the service.
This medium article also has a good summary of how to set up service discovery.
I am trying to create a new traffic manager profile of either Performance or Weight configuration but I keep getting stuck when trying to add an Azure Endpoint.
I have a two public IP inside of Azure, one with an optional DNS name, one with out.
When I try to add either of these as an endpoint, I get the following error message:
The one with a dns name on it:
Failed to save configuration changes to Traffic Manager profile 'profilename'. Error: Endpoint target type, 'DomainName', is not allowed for this profile. Valid values are: IPv4Address.
The one without a dns name:
No DNS name is configured.
If i choose External Endpoint and add the IPv4 directly it will work.
I tried with several different Traffice Manager profiles.. Is there a secret that I am missing out on? I am stuck..
Usually, There are three types of endpoint supported by Traffic Manager:
Azure endpoints are used for services hosted in Azure.
External endpoints are used for IPv4/IPv6 addresses, FQDNs, or for services hosted outside Azure that can either be on-premises or
with a different hosting provider.
Nested endpoints are used to combine Traffic Manager profiles to create more flexible traffic-routing schemes to support the needs
of larger, more complex deployments.
...
Azure endpoints are used for Azure-based services in Traffic Manager.
The following Azure resource types are supported:
PaaS cloud services. Web Apps Web App Slots PublicIPAddress resources
(which can be connected to VMs either directly or via an Azure Load
Balancer). The publicIpAddress must have a DNS name assigned to be
used in a Traffic Manager profile.
In this case, when you add a public IP address in the same subscription as an Azure endpoint, it will grey out if no DNS name configured in the Azure portal. You could add it when the public IP address configured with Azure provided DNS name like somedns.westus2.cloudapp.azure.com, this works on my side.
For example, there is a public IP address with the DNS name used for an Azure load balancer frontend.
I want to load-balance my VM scale set in a VNet. My requirements are that:
I do not want public IP accessibility and
I do need https health probes.
While both Azure load balancers (in either basic or standard sku) seem to be capable of balancing also internal traffic, only the standard sku offers https health probes.
When trying to add the VM scale set to the backend pool, I cannot select it, it's not found by the wizard. Both scale set and internal standard sku load balancer are within the same region, VNet, and resource group.
It appears I'm having the same issue as someone here, only with a scale set instead of an availability set.
There is a tooltip stating
Only VMs in region with standard SKU public or no public IP can be
attached to this loadbalancer. A backend pool can only contain
resources from one virtual network. Create a new backend pool to add
resources from a different virtual network.
So I am confused, my internal load balancer is using only private addresses, so the criterion of "with standard SKU public or no public IP" should be met. Also I note, that the tooltip does only explicitly state VMs, not VM scale set. However, I refuse to believe that the standard sku of LB should lacking features compared to the basic sku (I do have it working with a scale set and internal basic LB, albeit without https health probes).
Am I missing something here? I do realise that there's still the "Azure Application Gateway", however I think it's overly complex to set-up and overkill for my scenario. I only want internal load balancing of a scale set with https health probes. And I am starting to think that this is not possible.
Kind regards, baouss
It seems a restriction that you could not select the scale set as the backend for a standard SKU load balancer on the Azure portal. The document states that
One key aspect is the scope of the virtual network for the resource.
While Basic Load Balancer exists within the scope of an availability
set, a Standard Load Balancer is fully integrated with the scope of a
virtual network and all virtual network concepts apply.
So we only could select the eligible VMs in the virtual network as the backend pool for a Standard Load Balancer.
Wait for confirmation from Azure team: VM scale set does not work with internal standard SKU Azure load balancer backend pool
As you mentioned, currently, you could use Application Gateway with health probe Https. If not, you may create a VM scale set and choose a load balancing option--- load balancer. This will automatically associate a public standard SKU load balancer for your scale set.
This is a micro services deployment question. How would you deploy Envoy SDS(service discovery service) so other envoy proxies can find the SDS server hosts, in order to discover other services to build the service mesh. Should I put it behind a load balancer with a DNS name( single point of failure) or just run the SDS locally in every machine so other micro services can access it? Or is there a better way of deployment that SDS cluster can be dynamically added into envoy config without a single point of failure?
Putting it behind a DNS name with a load balancer across multiple SDS servers is a good setup for reasonable availability. If SDS is down, Envoy will simple not get updated, so it's generally not the most critical failure -- new hosts and services simply won't get added to the cluster/endpoint model in Envoy.
If you want higher availability, you set up multiple clusters. If you add multiple entries to your bootstrap config, Envoy will fail over between them. You can either specify multiple DNS names or multiple IPs.
(My answer after misunderstanding the question below, for posterity)
You can start with a static config or DNS, but you'll probably want to
check out a full integration with your service discovery.
Check out Service Discovery
Integration
on LearnEnvoy.io.
I tried to set up a network load balancer on google cloud but the heath check always returns unhealthy.
I give you the steps that i did follow
I created two windows servers 2012 R2 instances
I checked that the port 80 is open to public over both instances
I created the forwarding rules and Google Cloud gave me a External IP
I set up the external IP in a Network loopback interface on both server instances
I created a Network Route that forwarding the traffic on both instances (route menu)
I created another Network Route for the 169.254.169.254/32 (Source of Network load balancer traffic) and Pointing to both windows instances server
I created the same site (example.com) on IIS 8 in both instances server and the site is running correctly.
The DNS settings of the domain example.com is pointing to the external IP google cloud that I using for Network load balancer
I configured the health check
PATH : /
Protocol : HTTP
HOST: example.com
Session Afinity : Client IP
I created a Target Pool and I added both server instances and heath check
I Asigned the target pool to forwarding rule
When I select the Target Pool option, both instances marked as Unhealthy for the external IP that Google cloud gave me and I don't know why this happens.
I see the web page is switching the server instances randomly all the time.
Your Help is apreciated!, thank you!
You don't need to add any GCE Network Route.
The GCE agent is taking care of adding the load balancer IP to the VM's network configuration. There is no need to do it manually. https://github.com/GoogleCloudPlatform/compute-image-windows
IIS must respond to requests on the LB IP:
Check the IIS bindings from IIS manager. Reset IIS.
Confirm from netstat that IIS is listening on 0.0.0.0 or the load balanced IP.
Access the LB IP from one of the servers. It should work.
The GCE firewall must allow traffic from the clients' IPs and also from the metadata server (169.254.169.254). The metadata server is used for healthchecks.
Network Load Balancing tutorial. https://cloud.google.com/compute/docs/load-balancing/network/example