How GSLB works?
Lets say, I have a GSLB for www.test.com and my Load Balancers are running on different Data Centers. So, the requests are routed to the corresponding Load Balancers based on the proximity.
Does GSLB has IP as such?
In general, when we hit an address in the browser, it goes to DNS to get IP address and establish connection.
Check browser cache
Check System cache
Router cache
ISP cache
Root Domain Name Server
Sub Domain Name Server
2nd Level domain Name Server
Get IP - It returns list of IPs if there is more than one for a domain
Browser connect with one of the IP from the list( Mostly with the 1st IP from the list )
But, with GSLB, How the flow works? If it caches, what if the cached Load Balancer becomes slow and How does it route to other Load Balancer?
Where does the GSLB sit in the flow?
TL;DR; Client request is routed through the GSLB appliances. The GLSB appliances use the DNS infrastructure to connect the client to the data center that best meets the criteria set. This is enabled by MEP (Metric Exchange Protocol) that allows the load balancers to exchange data.
From the Citrix Netscaler documentation:
When you configure GSLB on NetScaler appliances and enable Metric
Exchange Protocol (MEP), the appliances use the DNS infrastructure to
connect the client to the data center that best meets the criteria
that you set. The criteria can designate the least loaded data center,
the closest data center, the data center that responds most quickly to
requests from the client’s location, a combination of those metrics,
and SNMP metrics. An appliance keeps track of the location,
performance, load, and availability of each data center and uses these
factors to select the data center to which to send a client request.
From Cloudflare - GSLB Explained:
How does GSLB reduce latency?
Even before an origin server overloads
and stops fulfilling requests, high amounts of traffic to that server
can still cause significant latency issues. A GSLB system can
distribute that traffic among several different locations, ensuring
that no single location is handling so many requests that it causes
delay.
Additionally GSLB can greatly reduce the travel time of requests and
responses between users and servers.
References:
Citrix - How GSLB Works
Cloudflare - What is GSLB? GSLB Explained
Related
I’m investigating a scenario with a live dashboard (Angular web app) that is refreshed every 5 seconds (polling). The API is sitting behind Azure Traffic Manager which will fail over to a second region in the event of a failure in the primary region. Keep in mind, Azure Traffic Manager works at the DNS level.
The problem I am facing is that the browser maintains a persistent connection to the primary region even after the Traffic Manager has failed over. The requests initially fail with 503s, but then continue to fail with 502s. The DNS lookup is never performed again as the requests occur more frequently than the keep-alive timeout. This causes the browser to continue to make requests to the failed region.
Is there anyway to explicitly kill the connection to force a DNS lookup? The only way I’ve found so far is to stop making requests for 2 minutes, or to close and reopen the browser. Neither is an acceptable solution for a dashboard that is supposed to be hands off and always fresh.
What’s interesting is after getting the browser to fail over to the secondary region, if I restart the primary region the browser will automatically switch back to the primary region after about a minute. This tells me the connection is respecting the DNS TTL when the service is functioning properly, but not when the server is unavailable. This makes no sense to me why the browser would lock onto a single IP forever when it’s not found.
Is there something I am missing about implementing georedundant failover with Traffic Manager for a web application? It seems very odd to me that the user would have to stop making requests for 2 minutes in any scenario before the browser would renegotiate the IP to the failed over server. Is it expected to turn of keep-alive to truly support near instant failover?
Here's a diagram that describes this scenario:
Diagram
Generally, Azure Traffic Manager works at the DNS level. Clients connect to the service endpoint directly, not through Traffic Manager. Traffic Manager has no way to track individual clients and cannot implement 'sticky' sessions.
For initial DNS lookup performance impact, you could find the explanation details here1 and here2
DNS name resolution is fast and results are cached. The speed of the
initial DNS lookup depends on the DNS servers the client uses for name
resolution. Typically, a client can complete a DNS lookup within ~50
ms. The results of the lookup are cached for the duration of the DNS
Time-to-live (TTL). The default TTL for Traffic Manager is 300
seconds.
The TTL value of each DNS record determines the duration of
the cache. Shorter values result in faster cache expiry and Longer
values mean that it can take longer to direct traffic away from a
failed endpoint. Traffic Manager allows you to configure the TTL as
low as 0 seconds and as high as 2,147,483,647 seconds. You could
choose the value that best balances the needs of your application.
Like the above, if you want the DNS lookup faster, you could set the TTL value as low as possible. Once the connection set up, the clients persistently connect to the selected endpoint until the endpoint is unhealthy via the health check.
You can enable and disable Traffic Manager profiles and endpoints. However, a change in endpoint status also might occur as a result of Traffic Manager automated settings and processes.. Get more details here.
For Geographic routing method,
The endpoint mapped to serve the geographic location based on the
query request IP’s is returned. If that endpoint is unavailable,
another endpoint will not be selected to failover to, since a
geographic location can be mapped only to one endpoint in a profile
(more details are in the FAQ). As a best practice, when using
geographic routing, we recommend customers to use nested Traffic
Manager profiles with more than one endpoint as the endpoints of the
profile.
We have a cisco load balancer on-premise which routes traffic to our DMZ Servers on-premise
We want to use Azure Load Balancer or Azure Solutions (AG) which can balance traffic to our DMZ Servers on-premise, basically replace the CISCO with Azure
Is it possible? we have SFT/HTTPS sites currently hosted on our DMZ Environment.
TIA
What you're proposing isn't the use-case for Application Gateways. Application Gateways are Layer 7 load balancers / reverse proxies. What you want to do is almost treat them as a one-site forward proxy. It's not a good architecture and even if it were possible would ultimately be more costly in the long-run since you would pay for data egress as your App Gateway accepts requests and then forwards on to your web servers via an outbound connection over the Internet. They then receive the response headers/body from your web servers and again send that result on to the original caller.
In that scenario, you are forced to have to use end-to-end SSL for your applications, removing any possibility of using the App Gateway for SSL offload in the future. If your traffic isn't encrypted or doesn't need to be, the predictability of the source and destination of your traffic increases the security risk to your website's users and your company.
You also have the possible security implications of this type of architecture. Your web servers still need to be accessible at the very least by your Application Gateway, which means they are either freely available on the Internet anyway (in which case why bother with an App Gateways at all) or they're firewalled at a single layer and permit only traffic from the source IP address of your Application Gateway.
The bad news with the firewall approach is that you cannot assign a static public IP address to an Application Gateway, it is forced as Dynamic. Realistically the public IP won't change until the App Gateways are rebooted but you should know that when, not if, they do, your firewall rules will be wrong and your App Gateways won't be able to get to your DMZ servers any more, which means an outage. The only true solution for that is a firewall that can do URI based firewall rules...the impact there is cost (time and CPU) to perform a DNS lookup, see if the traffic is from the App Gateway by its DNS address - something like bd8f86bb-5d5a-4498-bc0c-e1a48b3873bf.cloudapp.net and then either permit or deny the request.
As discussed above, a further security consideration is that your traffic will be fairly consistently originating from one location (the App Gateways) and arriving at your DMZ. If there's a well defined source of traffic, that fact could be used in an attack against your servers/DMZ. While I'm sure attacking this is non-trivial, you damage your security posture by making source and destination traffic predictable across the Internet.
I've configured a good number of Application Gateways now for Enterprise applications and out of morbid curiosity I had a go at configuring a very basic one using HTTP to do what you're attempting - fortunately (yes, fortunately) I received an HTTP 502 so I'm going say that this isn't possible. I'll add that I'm glad it isn't possible because it's a Bad Idea (TM).
My suggestion is that you either migrate your DMZ servers to Azure (for the best performance/network latency) or implement a VPN or (preferably) ExpressRoute. You'll then be able to deploy an Application Gateway using the correct architecture where you terminate your users' connections at the App Gateway and that re-transmits the request within your RFC1918 network to your DMZ servers which respond within the network back to the App Gateway and ultimately back to the requestor.
Sorry it's not what you wanted to hear. If you're determined to do this, perhaps nginx could be made to?
What do you suggest as the best way to protect your web servers IP address for outgoing requests? I'm already using Cloudflare for inbound requests but if my web server (nodejs) is making outbound connections for sending webhooks or something, I would prefer not to expose my origins IP. I have a firewall set up to prevent any connections inbound not coming from Cloudflare but I don't want my IP to expose where I'm hosted only to have my datacenter receive a DDoS.
There actually aren't any good articles I can find anywhere regarding protecting your IP with outbound connections.
Two thoughts:
1) Set up a second datacenter containing proxy servers and route outbound web server traffic through the proxy servers.
2) Set up a webhook queue, send webhooks to the queue and have servers in a 2nd datacenter work the queue.
Ideas?
I have worked at my company with a number of models over the years, including both ones that you listed. We started out using a queue that were available to web hook processors on remote data centers, but we transitioned over to a model that had less emphasis on queues, and instead simplified it; an originating server chooses one of the available notification/web hook senders, that in turns calls the web hook subscriber. The sender also takes care of buffering, resending, alerting and aging of messages.
For the purpose of protecting your IP address, it depends on a number of variables. In our case, we acquire additional IP address ranges for the senders, but you can achieve your goal by having the proxy hosted on AWS or similar.
Why would you want to do this? Your inbound requests are already dropped if they aren't from cloudflare.
I have a webapplication in multiple Regions in the Azure Cloud and i'm using the Traffic Manager in Performance mode zu redirect the user to the closest Region.
What's concerning me is the following:
With this site https://www.whatsmydns.net i checked my Webapplication to see, which Datacenter is selected.
The funny thing is, that people from California gets redirected to the server in Westeurope but there is a Server in US Central too.
So from the site of the traffic manager the ping to the europe server is faster then to US central.
But i believe, that the difference between these too can not be high...
Now i have the fear, that it can happen that a user jumps between US Central and Europe all the time because he is in such a zone where the latencies to the available servers are nearly identical.
I also store files in a Azure Storage account in each region. If the user now jumps, i would have to transfer these files between the regions all the time...
So i was wondering if there is a possibility to redirect the user by his GEOIp to a specific region than by latency?
One of the benefit of the traffic manager is in my eyes that i can use one domain for all regions...
the only solution for my problem i can think of is a own cloudservice which replaces the traffic manager and redirects the user to the different regions by their IP like us-center.DOMAIN.com, we-eu.DOMAIN.com etc...
Are there any other solutions?
Thanks for your help!
Br,
metabolic
If you believe Traffic Manager is routing queries incorrectly, that should be raised with Azure Support.
Traffic Manager 'Performance' mode routing is based on an internal 'IP address to Azure data center latency map. The source IP of the DNS query (which is typically the IP of your DNS server) is looked up in the map to determine which Azure location will offer the best performance. There is an implicit assumption that the IP address of the DNS server is a good proxy for the location of the end user.
The 'Performance' mode in Azure Traffic Manager is deterministic. Identical queries from the same address will be routed consistently. The only exception is that routing may change during occasional map updates, which affect only a small %age of the IP address space.
A more common cause of routing changes is customers moving from place to place. For example, during travel, or simply by picking up a Wifi network that uses a DNS service in a different location, with a different IP address.
A Geo-IP based routing is not currently supported by Traffic Manager. However, please note that it would work in the same way as the 'performance' routing, just that it would use a different map. Users could still be routed to different locations as a result of map updates or changing DNS servers.
As you describe, if your application requires a strong, un-violable association between a user and a region, one option is re-direct users at the application level (e.g. via HTTP 302).
Fast question is it possible to have Azure Traffic Manager
I would like to rent dedicated servers in 3rd party suppler and to load balancer from Azure
Question 1:
Can I setup this scenario? and use the load balancer from Azure?
Question 2:
Will I pay Outgoing bandwidth
Question 3:
Will you share for website with 10 000 000 page views per month how much you pay for DNS look ups as average.
Question 4 please suggest same service competitors... Google, Amazon, Rackspace I already know
The link you provided to the article already answers #1 and #3. Yes you can set this up. Billing is done by DNS lookup at $0.75 per million lookup, so your 10m page views will cost at most $7.50, but this isn't taking into consideration DNS caching which will drastically lower this (already very low) cost.
Question 2 is not an Azure Traffic Manager related question. No bandwidth goes through ATM so there is no charge. I am sure you will pay bandwidth charges with whatever 3rd party datacenter provider you are going to use.
I don't understand question 4. What do you want suggestions for? A cloud provider? There are lots of good ones but it depends on your scenario.
Azure Traffic Manager is a DNS routing system. It is similar to the routing features of AWS Route 53 (although Route 53 is a more full-featured DNS system).
Azure Traffic Manager uses DNS to point incoming traffic to different endpoints, which can be either within Azure or external urls. Because it uses DNS, it doesn't actually see any of the data itself, it just translates something like myapp.trafficmanager.net to 'webserver1.example.comorwebserver2.example.com` based on your rules and setup.
You can use round-robin, weighted or performance (which directs to the geographically closest address you have setup). You can further use Azure's DNS or another DNS system to use your own (sub)domain to CNAME to the trafficmanager.net domain name.
Load balancers like Azure Load Balancers and Amazon's Elastic Load Balancers are used to actually spread the traffic itself to different machines or services. Each work only with services hosted with the cloud provider so Azure Load Balancers can be used to load balance Azure VM's but not some servers you have hosted elsewhere.
Load balancers have bandwidth charges because they actually pass through the traffic. Azure Traffic Manager just has DNS query charges because that's all it does.
In your case, yes you can use Azure Traffic Manager to point to several external endpoints for your dedicated servers. You can also nest Traffic Manager profiles so that you can first use geo-location then round-robin. Azure Traffic Manager does support basic http/https monitoring to make sure the endpoint is still active.
Because it is based on DNS, there will always be a lag between changes with the TTL value and how clients cache DNS addresses. This is inherent with all DNS routing. To be extra safe, you can use Azure Traffic Manager to route to your datacenter and then run your own load balancing software locally to spread the load among servers.