Radware Alteon GSLB Health Checks Across Data Centres
Radware Alteon Global Server Load Balancing (GSLB) can direct users to the most suitable application site while removing failed data centres from DNS responses. The design combines DNS control, site selection rules, virtual server status and application-aware health checks.
A reliable implementation starts with the traffic model rather than the appliance menus. Define which hostnames are global, which data centre owns each service, how long DNS answers may be cached and what should happen when every preferred site is unhealthy.
For Australian environments, this often means connecting Sydney and Melbourne facilities, with Perth or Brisbane used for resilience or regional workloads. Latency, cloud-region placement, carrier diversity and data residency requirements all influence the final policy.
Define the GSLB traffic model
List each fully qualified domain name that will use GSLB, such as portal.example.com, api.example.com or login.example.com. For every name, record the application protocol, listening ports, expected URL response, session behaviour and recovery owner. A DNS-based design is usually appropriate for HTTP, HTTPS and many TCP services, but it cannot replace application-level routing inside a site.
Decide whether Alteon will provide the authoritative DNS service for the GSLB domain or whether existing DNS servers will delegate the relevant zone to Alteon ADNS services. The public DNS record must point clients towards the GSLB service, while each site needs a resolvable path to its local virtual server. Keep management, synchronisation and client-facing DNS interfaces separated where the platform and network design allow it.
The selection method should match the business requirement. Common choices include active-standby priority, least connections, geographic preference, proximity or a weighted distribution. A Sydney preference for Australian users may be sensible, while a global application could use latency or geography. Document the fallback order before configuring it.
Prepare sites, virtual servers and DNS
Create a logical GSLB site for each data centre and associate the site with its Alteon device or participating virtual servers. Confirm that each site advertises the correct service IP address, port and protocol. A site object should represent a reachable application location, not simply an appliance that responds to management traffic.
Configure the application virtual servers locally before adding them to global rules. Test the service directly from a monitoring host in each facility, checking TLS negotiation, certificates, routing, authentication and backend dependencies. A virtual server that answers TCP connections but returns an unusable login page must not be treated as healthy.
DNS TTL deserves deliberate attention. A short TTL improves failover speed but increases resolver traffic and can be ignored by some clients or intermediate caches. A long TTL reduces DNS load but leaves users directed towards an unavailable site for longer. Select values based on the application’s recovery objective and validate behaviour with Australian ISPs and enterprise resolvers, not only with an internal DNS server.
Build health checks that reflect user experience
Use the simplest probe that proves the service is usable. A TCP check can confirm that a port is open, while an HTTP or HTTPS check can request a specific path and validate the response code. Where supported, add content matching for a stable response string, but avoid checks that depend on a user session, rapidly changing text or an external service that may fail independently.
For HTTPS services, validate the expected host header and SNI name. A probe sent to the default virtual host can produce a successful status code even when the production hostname is broken. Check certificate expiry, protocol compatibility and redirects as part of deployment testing, while keeping the recurring health probe lightweight.
| Service condition | Recommended check | Failure action |
|---|---|---|
| Port is unavailable | TCP connect | Mark server or service down |
| Web listener responds | HTTP status check | Remove endpoint after retry threshold |
| Correct application is required | HTTPS with host and content match | Exclude site from GSLB pool |
| Login or database dependency fails | Synthetic endpoint or application health URL | Drain site and alert owner |
| Maintenance is planned | Administrative disable or drain | Stop new DNS assignments |
Set probe intervals, timeout values and failure thresholds with care. A single lost packet should not move thousands of clients between Melbourne and Sydney, while a genuinely failed application should be removed promptly. Use consecutive failures and recoveries to prevent flapping, and make sure the health-check source addresses are permitted through firewalls and web application controls.
Configure policy and session behaviour
Create a GSLB service or rule that associates the hostname with the participating site services. Apply the preferred selection method, backup order and health status criteria. If the primary site is healthy, the response should contain its address; if it fails, Alteon should return the secondary site according to the documented policy.
DNS steering does not preserve a browser session by itself. Applications using cookies, server-side sessions or authentication tokens may need persistence at the selected site, shared session storage or a deliberate cross-site failover design. A user moved from Sydney to Melbourne may be forced to authenticate again unless the application supports that transition safely.
Consider the impact of cached DNS answers during a failure. Alteon can stop returning an unhealthy address, but already-cached answers remain valid until their TTL expires. For critical services, combine GSLB with application replication, database recovery procedures and clear maintenance controls. The global rule should never be treated as the complete disaster-recovery plan.
Validate failover from multiple networks
Test normal selection, primary-site failure, secondary-site failure and full-service outage in a controlled window. Stop the application listener or deliberately fail the health endpoint rather than merely disconnecting an internal interface. Confirm that the service is removed only after the expected threshold and returns after the recovery threshold.
Run DNS queries through resolvers located near Sydney, Melbourne, Brisbane and Perth where possible. Compare answers, TTLs and response times, and test both IPv4 and IPv6 if they are published. External checks are valuable because an internal monitoring server may continue to reach a service that customers cannot access through a carrier path.
Capture Alteon event logs, probe results, DNS responses and application logs for every test. Verify that the chosen address is reachable, that TLS presents the correct certificate and that a real transaction succeeds. A practical runbook should state who disables a site, who approves restoration and which alarm indicates that GSLB has changed the active destination.
Operate the design over time
Monitor health-check latency, failure counts, DNS response patterns and the distribution of clients between sites. Alert on repeated transitions rather than only on a final down state. Review probe URLs whenever the application team changes authentication, routing or release health endpoints.
Keep Alteon firmware, signatures and configuration backups under change control. Export configuration before major policy changes and record the dependency between GSLB objects, local virtual servers, DNS delegation and firewall rules. Teams managing virtual infrastructure should also document storage and workload dependencies; a related vSphere storage guide can help frame that operational dependency work.
Australian organisations should account for the Privacy Act 1988 and any contractual data-residency obligations when directing users or replicated application data between facilities. A policy that sends traffic to an overseas cloud region during an Australian outage may be technically effective but commercially or legally unacceptable. Regular reviews should confirm that GSLB behaviour still matches the organisation’s service, security and compliance requirements.