As soon as we refer to big Datacenters and Cloud, scalability comes to the mind and becomes a concern. Load balancers and ADCs play critical role in such deployments. While the load on these services goes UP due to the end user demand, service owners bring up new entities and resources to serve the need. These new entities need to have their definition in the load balancer for them to participate in real traffic processing.
Couple releases back NetScaler had introduced the domain based services notion where the service definition on NetScaler is done through the DNS response for the domain. Similarly domain based service group was introduced which consists of members whose IP addresses are obtained by resolving the domain names of servers bound to the service group. Name resolution process can return multiple IP addresses for the same resource but we consider only the first IP returned and ignore the rest.
NetScaler 10, which is a milestone release for all kind of Cloud deployment, introduces the AutoScale feature for domain based service groups. You can configure a domain based service group to scale automatically on the basis of the complete set of IP addresses returned in DNS response. It is added as a quick enable/disable option which gives you the ability to automatic scaling.
Once a domain based server is bound to the service group with AutoScale enabled, NetScaler dynamically creates and binds a TCP and UDP monitor to the service. NetScaler by default uses the UDP monitors for sending DNS queries to the name server. If the DNS response is truncated then NetScaler dynamically falls back to TCP monitor and uses TCP as underlying medium for DNS message exchange ensuring that we receive all the data sent from the server. Once NetScaler starts using TCP monitor it does not switches back to the UDP monitor in real time.
When NetScaler receives multiple IP addresses as part of single DNS response, it polls all the IP addresses individually and does default monitoring. NetScaler ensures that it only adds the multiple IP addresses to service group if they are UP and responding to monitor query. Overall NetScaler takes care of bringing up the infrastructure with caution, ensuring the correct service delivery. Now the question is how do we manage such deployments in real time because the DNS records expire after associated TTL??
Hmmm… interesting and let us see what best NetScaler can do here… once the record expires, NetScaler uses the associated UDP or TCP monitor for sending out resolution query to the same server. After receiving the response it validates for any changes. In case of no change, the deployment continues to run as is. In case of new IP addresses found in the response NetScaler plays the Scale Up role and does the same set of validations for the new IP addresses. After the validation passes, those IP addresses are added to the service group for traffic processing. If the DNS response does not have some IP addresses which were received the last time then NetScaler very well plays the Scale Down role and removes those IP addresses from service group definition. Removing the IPs could be tricky as there may be live transactions and connections. NetScaler does graceful closure of the connections to those IP addresses and does not terminate them abruptly causing bad end user experience. In this duration NetScaler ensures that no new connection and transaction is allowed to be served by these IP addresses thus just existing ones terminate gracefully.
This kind of integrity in handling scalability makes NetScaler special for such deployments…. What else?? … There is some more NetScaler does to provide you enough flexibility with your deployment. You can include static IP based and domain based server at same time in single service group. This provides you with the flexibility that at any given point in time you have the static members serving the clients. This is important from availability standpoint as single NXDOMAIN response can result into removing all the members associated with that domain, resulting in complete outage. Thus a mix mode approach could be better one to have. Interesting… and what more?? You are also allowed to have multiple domain based servers with AutoScale ON within single domain based service…. Now you must be thinking of all those use cases which use to be rare before… 🙂