Availability groups have several important requirements and limitations:
Two instance maximum: Gateway Availability groups can have at most two (2) Gateway instances: a Primary and a Secondary.
DNS Server and FQDNs: Availability groups require that your infrastructure uses a DNS Server. End users will no longer send requests to a specific IP Address. Instead, they'll use a fully-qualified domain name (FQDN), which the DNS Server will redirect to whichever node is currently the Primary in the Availability group.
If your system has a feature or workflow that relies on accessing Gateway through an IP address, those features and workflows will not work with Availability groups.
SOA record: There must be a start of authority (SOA) record that indicates which DNS server is authoritative for the group's address.
NTP Server: You must set up an NTP server to make sure that the clock on both the Primary and Secondary Gateway nodes are synced with each other (and with the Availability group's DNS server).
Tip:BlueCat Address Manager includes an NTP server feature that synchronizes the time on all instances of BlueCat DNS/DHCP Servers (BDDSes) that it manages.
We recommend that the Availability group uses the DNS server on a BDDS that's managed by the same instance of Address Manager as the Gateway nodes. Doing so lets you synchronize the time on both Gateway instances with the DNS server.
-
TSIG key: Each Gateway node within an Availability group requires a TSIG (Transaction Signature) key. This TSIG key must allow authorized users to create and update records on the DNS server.Tip: If you're using a BlueCat DNS/DHCP Server (BDDS) managed by Address Manager, you can set up a TSIG key in Address Manager with the appropriate permissions. For more details, see Setting up a BDDS as the DNS server for an Availability group.
- Compatibility between Gateway instances: Gateway does not check whether the two instances are equivalent or compatible replacements for each other.Important: Make sure that both instances of Gateway are the same version and have the same (or compatible) workflows and configuration. Test your workflows on each instance to make sure that important workflows will work in each environment.
-
Workflow complexity: Depending on its complexity, you may need to modify custom workflows and features to handle the failover between the Primary and Secondary node. As a rule of thumb, if a workflow does not care which specific Gateway node responds to requests, then it might work as-is with Availability groups. If a workflow requires a specific instance of Gateway, then you might need to modify it to check whether a failover occurs and take the appropriate action. (See Using Gateway Availability groups in custom workflows.)
Regardless, make sure you rigorously test your custom workflows under failover conditions before deploying your workflows to a live environment.
Custom workspaces: Custom workspaces should not be shared between the Primary and Secondary nodes in an Availability group.
IPv4 only: Gateway Availability groups currently support only instances on IPv4 networks. Gateway instances hosted on IPv6 networks currently cannot be used in Availability groups.