How to bridge you external url to internal url

Back>

Often times, your external url will look like:
http://greatfun.itworld.com/tutorial/xyznetwork
http://mobile.itworld.com/tutorial/xyznetwork
http://affiliate.itworld.com/tutorial/xyznetwork
http://greatfun.itworld.com/tutorial/xyzcode
http://greatfun.itworld.com/tutorial/cyberjedizen

However internally, you may have server farms with urls like:
http://ohio.internal.prod.kl2217.org/tier1/kwddy/xyznetwork
http://ri.internal.prod.kl2217.org/tier1/kwddy/xyznetwork
http://ohio.internal.prod.kl2217.org/tier1/dqml0/xyzcode
http://ri.internal.prod.kl2217.org/seti/tier1/dqml2/xyzcode
http://us.internal.prod.secure.cloud.com/mmi/cyberjedizen

The question is, how to translate external urls into internal urls so that your clients have simple urls to remember but your internal IT can have name conventions and network details for server farms.

You may think, well, that's easy. A proxy such as apache mod_proxy can easily translate
http://greatfun.itworld.com/tutorial/xyznetwork

to 

http://ohio.internal.prod.kl2217.org/tier1/kwddy/xyznetwork

However, the issue is not that simple if we assume there are lots of requests issued towards those external urls.

First of all, you have to load balance the traffic, distributed them to groups of hosts inside server pools. 

Secondly, the DNS server have to translate the external requests' url to your load-balancer's VIPs fast.

Thirdly, the traffic won't be stable during a day, there could be spikes of requests, for example when there are friendly/unfriendly bots requests arriving your site.

Now think about the issue again.

DNS servers

At least, you need an external DNS for solving the external urls. Your external DNS servers should be the Authoritative-Only DNS Server. They won't response to recursive queries issued by caching DNS name servers, it won't cache because it only dedicated to solve your domain names, as a result it is optimized to respond to the queries for your external urls as fast as possible.

You'd better to have an internal DNS for solving the internal urls. Mixing external and internal DNS's servers won't be good.

While the external dns servers only concern about  the external urls, the internal dns servers need to do more. They contains the authoritative information that the public DNS provides, as well as additional information about internal hosts and services. It might also act as caching dns servers for its internal clients. From a security standpoint, that the public server has no records of the private counterpart is desirable. In case your public DNS servers are compromised, your internal dns zone files won't be exposed to public.

Load Balancers

There are a few types of load balancing:

• round robin
• weighted round robin
• round robin + uptime monitoring

The load balancing decisions can happen at many levels: DNS level, site level, server level and VM level.

load-balancing

DNS level LB

Start from the external DNS, for the queries to the same external url, http://greatfun.itworld.com/tutorial/xyznetwork

the DNS can reply many IPs. The replied ip is one of the VIPs of the load-balancer's server farm. For example, VIPs managed by a F5 BIG IP load-balancer's LTM (local traffic manager). Sometimes, the DNS server and load balancer is the same unit, for example F5 BIG IP have GTM (global traffic manager) for DNS level load-balancing as well as LTM (local traffic manager) for server level load-balancing.

It is a common pitfall to use DNS level load-balancing to switch traffic between sites. The switch won't happen immediately, but happened gradually instead. That is because your clients might cache the DNS response for a period of time. So even though your DNS stops publishing one site's VIP, the traffic can still go to those unpublished VIPs for a while, until your clients' cached dns records expire. Generally browsers don't cache dns records, but web clients could cache the dns records as long as they are configured.

Site level LB

Your F5 BIG IP load-balancer software can provide site level load-balancing. It groups hosts/VMs into Servers, then group servers into cells. A cell could be a site, a functional department, a tier. The BIG IP load-balancer then make load-balance decision at cell level: such as evenly distribute the load between ohio site cell and ri site cell, or switch off ri site cell for maintain, or add pilot cell for testing new release.

Server level LB

You load-balancer should distributes client requests to multiple servers instead of to the specified destination IP address only.

For example, the DNS server returns one of the VIPs of the F5 BIG IP load balancer for the client request. A virtual server is a traffic-management object on the BIG-IP system that is represented by a VIP (virtual IP) address and a service, such as 192.168.20.10:80.

When you create a virtual server, you specify the load balancing pools that you want to use as the destination for any traffic coming from that virtual server. You also configure its general properties, such as iRules.

A load balancing pool is a logical set of devices, such as web servers, that you group together to receive and process traffic. A pool member is a logical object that represents a physical node (server). A node usually have one IP, but may have multiple hosts sharing the IP. An individual pool member can belong to one or multiple pools, depending on how you want to manage your network traffic. The specific pool member to which Local Traffic Manager chooses to send the request is determined by the load balancing method that you have assigned to that pool. The default load balancing method is Round Robin, which evenly distribute requests across the servers in the pool. Advanced load balancing method needs the help of iRule. F5 Big IP LTM is capable of inspecting url, applying iRules to the path (for example looking for certain pattern match) then routing the requests to different server pools.

1. when HTTP_REQUEST {
2.     if { [HTTP::uri] ends_with “xyznetwork” } {
3.     pool xyznetwork_Pool
4. } 
5.     if { [HTTP::uri] ends_with “xyzcode” } {
6.         pool xyzcode_Pool
7.     }
8.     if { [HTTP::uri] ends_with “cyberjedizen” } {
9.         pool cyberjedizen_Pool
10.     }
11.     if { [HTTP::uri] ends_with “kl2217” } {
12.         pool kl2217_Pool
13.     }
14. }

Don't get confused about the word "route", we are actually talking about load balancing based on url, instead of IP layer routing based on IP and subnet mask.

VM level LB

Please notice your physical hosts might have hypervisor running on them. The hypervisor might have multiple VMs hosted in it. Depending on the Hypervisor's configuration, the hardware resources are shared among the VMs. Resources such as cpu cycle, memory, disk space, network bandwidth are all configurable. Load balancing can happen at this level as well. For example, the hypervisor might decide to distribute more loads to the VM with more vCPUs, but distribute less loads to the VM with less vCPUs.

Proxy Servers

There are many reason for using proxy servers. For example, your web application needs to access endpoints located in the public cloud. The requests to those endpoints generally go through the proxy servers for better security. You can put your proxy servers behind the F5 server, then put the proxy servers inside the DMZ. Those proxy servers are heavily guarded, network administrators can apply blacklist as well as whitelist for certain IPs there, these proxy servers can have the certificate installed and inspected, they can have firewall, IDS/IPS running there as well.

Another reason for having proxy servers is to have them act as some sort of reverse DNS servers, for example,
map http://greatfun.itworld.com/tutorial/xyznetwork

to 

http://ohio.internal.prod.kl2217.org/tier1/kwddy/xyznetwork

This url then get response from internal DNS server, which solve the hostname to the VIPs of internal F5 load-balancer.