Two Netscalers with same URL ? - VServer IP address ?

[Andrew Scott]

Hello, we have two separate Netscalers.

They share a wildcard certificate and single DNS FQDN record which dynamically resolves to two public IP addresses by means of DNS failover i.e. if Netscaler1 is down, then dynamic DNS changes the record to point to the public IP of Netscaler2.

I have joined Netscaler1 to Storefront successfully. Now, I want to add Netscaler2 to Storefront, however I understand Storefront requires the second Netscaler gateway to have a unique FQDN and IP address - which ours does not - ***or could we simply define the vServer IP address on each of the two Netscaler entries ?

How can I overcome this problem i.e. what options do we have?

Note, we do not have a Platinum license if this is required for gateway load balancing.

Thank you for any ideas.  

[Rhonda Rowland1709152125]

On 8/10/2022 at 7:03 PM, Andrew Scott1709153367 said:

They share a wildcard certificate and single DNS FQDN record which dynamically resolves to two public IP addresses by means of DNS failover i.e. if Netscaler1 is down, then dynamic DNS changes the record to point to the public IP of Netscaler2.

This statement implies your IP address IS changing.  And so storefront CAN see the difference between gateway1 vs. gateway2 and any lb vips you have.

 

However, your next statement states you have the SAME VIPs for Gateway vservers and/or Storefront LB vservers.

 

Quick Example for GSLB:

For storefront to be aware of Gateway1 and Gateway2, they must have different FQDNs/VIPs and then you rely on mechanisms like optimal gateway routing.

If the Gateways have the same FQDN but different VIPs (the ips change in other words), then GSLB can get the USERS from "gateway" to VIP1 or VIP2 using the common name during hte authentication phase. Each Gateway will still have a unique/site specific name for the hdx proxy phase such as as gateway-A and gateway-B, this is will be what the StoreFront uses for optimal gateway routing and to map the gateway-A to SiteA resources and gateway-B to SiteB resources in the connection phase.  StoreFront is configured with the gateway (gslb fqdn) as the authentication gateway and the two site specific FQDNs as the HDX Proxy gateways. (3 separate gateway entries).

>> For GSLB to be in use, you will have one common gateway FQDN that can resolve through GSLB-based DNS resolution to SEPARATE VIPS.  If the IP isn't changing then it isn't GSLB.

 

Quick Example that might be RHI (but way more to it on the gateway/storefront side)

If however, you have one Gateway FQDN that resolves to a single VIP and a separate external mechanism resolves which IP owner is the active owner so that the VIP DOES NOT CHANGE between the two datacenters, then this is not a GSLB config.  For two ADC's in separate locations to own a single IP address but to coordinate who is active at one time is often an RHI (route health injection) config or it may be something else altogether. (This isn't exactly what you described above though.)

The two ADC's participate in RHI to ensure only one system is active for a set of IPs at a time to avoid conflicts.

 

In addition, in this case though if a user talks to the SiteA Gateway and the SiteA StoreFront, the storefront only responds with "gateway" which resolves to active datacenter VIP SiteA.  

When failover occurs, then only the SiteB Gateway and SiteB StoreFront vips are active and owned by the SiteB appliance. You do not make the storefront aware of "both" gateways at same time in this case BECAUSE the names/VIPS are not changing. 

 

 

So, before you can get a better answer to your above question, you would need to provide more info to clarify your scenario:

1) Identify the IPS/names involved: your ADC NSIP (management IPS), Gateway FQDN/VIP, and StoreFront FQDN/VIP per location.

2) What type of StoreFront to CVAD Site mapping are you doing and StoreFront to Gateway mapping is needed? Will it just be one storefront with one gateway for one datacenter and then fail over to the other. OR is the StoreFront supposed to be aware of both Gateway and CVAD locations...this will drive what type of configuration you need.

3) If you are relying on an external DNS dynamic decision, understand which Names/IPS are involved and what it is based on.  

 

Then you can try to figure out how to build what you are trying to do.  But the scenario you describe above is confusing as it seems to be doing a little of both at the same time.