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

Sufficient capacity in a failover scenario

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.

Insufficient capacity in a failover scenario

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:

1. Randomized key
2. VLAN attachment metro
3. 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

SearchCloudComputing

Google Cloud Dedicated Interconnect offers VPN alternative