There are a few things to consider when doing this.
1. You have to reach the ACE for any redirection to take place. Only one ACE is actively answering for your virtual address. So if that ACE fails or becomes unreachable, then so does your application. The GSS is hosted at each Data Center and every GSS actively returns DNS records. They also share the same sticky database for persistance. So no matter which GSS you query, they will return the same A-record.
2. The ACE is going to setup a TCP handshake and inspect your data to verify it is a candidate for redirection. Once the ACE sends a redirect, another DNS name lookup has to happen to resolve the destination data center before it establishes the connection. The client will do this for every connection because it doesn't cache the http redirection from ACE.
The GSS operates at the name resolution layer. This happens over UDP and doesn't require very much overhead. From the client perspective, it only sends a DNS name query to it's name server. The name server is the device that queries the GSS(s). Once the client resolves the domain name, it establishes a connection with the application in the correct DC the first time.
3. ACE HTTP URL redirection only works for HTTP(s) traffic.
Using the ACE and GSS together gives you a big advantage. The ACE will do local health checks on the servers and applications. The health checks can be as basic as a probe and as detailed as SNMP probe for CPU utilization on the server. Once the application health has been determined locally, the ACE creates a load variable from 0-255.
The GSS sends keepalives to the ACE in each data center. Using Kal-ap we can send 100s of keepalives over a single tcp connection. Using the load variable that the ACE calculated above, we can distribute traffic to the data center that has the least load.
This is just an example of what GSS and ACE can do together. There are more advantages to DNS GSLB than HTTP Redirection.
