Advanced ECS and Isilon Traffic Management

Why EDNS is important

Using DNS for load balancing storage infrastructure has some limitations around visibility of the client device making the DNS request. As a DNS request gets forwarded through upstream DNS servers, the original client IP address is not passed along which means that geographic load balancing is based on the IP address of the last DNS forwarder. This may work in very broad global terms as the last DNS forwarder may be a national ISP allowing geolocation to a specific country. However, this can have implications where DNS load balancing is used within a country or within a private network as all traffic may be seen as coming from a single source or limited number of sources.

EDNS (Extension Mechanisms for DNS) addresses this shortcoming by providing a mechanism to pass the original client subnet along the DNS forwarder chain allowing the DNS resolver to identify the original source of the address. Progress Kemp ECS connection manager supports EDNS which deliver better decision making and control when using DNS for load balancing. This ability to identify the client subnet opens up a number of use cases which go beyond the common use case of connecting a user to a ‘nearby’ service based on their location.

Use Case – Rack based steering for ECS and Isilon

In some industry sectors multiple racks of combined compute and storage are used for tasks such as rendering animations or running financial simulations. While the storage may be replicated across racks, it may be inefficient to have compute resources accessing storage outside the rack. One solution for this is to have a unique namespace for each rack and have the compute nodes explicitly access the name space for their own rack.

Figure 1 – Using a unique namespace to keep traffic in-rack

While the namespace-per-rack approach will ensure storage traffic stays within the rack, any availability issue with the in-rack storage will cause the task running on the compute node to fail. For long-running tasks such as simulations or renderings, this would result in having to restart the task leading to delay and energy waste.

An alternative approach is to have a single namespace with a DNS based load balancer that supports EDNS (Extension Mechanisms for DNS). With EDNS, the client can be identified (the compute node) and based on this information directed to the in-rack storage. Should storage fail, the load balancer will redirect to an alternative storage rack with no impact on the compute task.

Figure 2 – Using a shared namespace to keep traffic in-rack

ECS Connection manager supports this EDNS and shared namespace scenario for ECS and Isilon storage environments. With support for up to 256 entities per namespace (FQDN), organizations can create scalable infrastructures, that are simpler to deploy and manage and that can provide resilience in the event of a storage node outage.

Use Case – Heavy workloads on ECS and Isilon Storage

Storage environments often contain small proportion of clients that generate frequent and sustained high-traffic loads which presents load balancers with a challenge of how to spread this traffic across the storage infrastructure. Using techniques such as round-robin to spread the load could result in uneven traffic levels across the infrastructure. With EDNS, such high-traffic devices can be defined to have a preference for a specific storage node allowing traffic to be spread more evenly across the infrastructure.

ECS Connection manager supports EDNS, and in environments such as medical imaging or media, provides storage administrators with the controls to ensure even distribution of traffic. In the event of a storage failure, devices defined in this way would transparently fail over to remaining storage nodes.