High Availability and Redundancy for Google Cloud Interconnect
PacketFabric’s infrastructure supports redundancy in both dedicated and partnered connections with Cloud Interconnect. Google recommends multiple ports to prevent traffic from being interrupted in the case of a failure. To this end, users should duplicate connections for dedicated interconnects and VLAN attachments for partnered interconnects.
Provisioning a secondary connection
When provisioning a secondary connection for redundancy, follow the process as outlined in Create a Dedicated Connection and Create a Partner Connection.
Users must create redundant connections in the same metro as the existing port in order to achieve redundancy.
Ensure that connections have sufficient capacity
Users should make sure that the capacity is the same across connections and that each connection has the capacity to sustain all traffic in the event of a failover. Additionally, each Google Cloud Virtual Private Cloud (VPC) network should have enough VLAN attachment capacity to carry all traffic in the case of a failover.
Examples
This connection is redundant. In the case of a failover on Connection A, all 10 Gbps of traffic is diverted to Connection B, which has sufficient capacity.
This connection is not redundant. In the case of a failover on Connection A, all 100 Gbps of traffic is diverted to Connection B, which has insufficient capacity. Connection B may experience slowed traffic and packet loss in this case.Selecting ideal availability zones
When creating VLAN attachments, users should select Google’s metros and availability zones to minimize the risk of outages and decrease latency. Both Google and PacketFabric use the term “availability zone” but they may not mean the same thing. This document’s use of “availability zone” only applies to Google’s use of the term.
Each metropolitan area (metro) contains at least two availability zones. These represent important measures to ensure redundancy; no two domains within the same metro will shut down for scheduled maintenance at the same time. However, because Google does not coordinate maintenance windows between metros, singular connections between metros do not establish redundancy.
Examples
Pairing keys for VLAN attachments
Google issues pairing keys that correspond to individual VLAN attachments. These pairing keys contain:
- Randomized key
- VLAN attachment metro
- Edge availability domain
PacketFabric offers users the option to purchase diverse services. For customers purchasing Google Cloud Interconnect services, diverse services constitute services that must be properly connected to at least two access ports in different edge availability domains within a metro.
Google recommends using active/active VLAN attachments
While it is possible to configure redundant VLAN attachments as either active/active or active/passive, active/active attachments are strongly recommended. Although active/passive attachments can also prevent interruptions to service, it is easier to make sure active/active attachments are working correctly.
For more information on configuring active/active and active/passive forwarding, see Configuring devices for active/active forwarding.
Graceful restart and redundant on-premises routers
While not required, Google’s Cloud Router can receive graceful restart messages from a user’s on-premises router, limiting disruptions to traffic in the case that a router must be restarted. By default, Cloud Router sets the timer for expecting new keepalive heartbeats at 1 second. Users should set their own router’s graceful restart timers to an appropriate value for their needs.
If graceful restarts are not supported on the user-end, then restarts on either side of the BGP session cause the session to fail. Google’s Cloud Router sets its BGP timeout at 60 seconds by default, after which routes are withdrawn and traffic is redirected.
Users should configure two separate devices with one connection each, in case a Cloud Router or on-premises router fails.
Additional resources
Google documentation
Best practices for Cloud Interconnect
Dedicated Interconnect Overview