Have you tried the Quick Connect to GCP feature for Equinix Fabric?
Quick Connect to Google Cloud Platform (GCP) is a new Equinix Fabric feature that enhances the creation of L2 connections to GCP. Instead of logging into the GCP portal to create a Google service key, all of the required provisioning steps can be performed from within the Equinix Fabric portal. Prerequisites and detailed instructions can be found in the following on-line resources. Quick Connect for Fabric 2022.3 - YouTube Quick Connect to Google Cloud Platform (equinix.com) This new feature is available today for Fabric customers adding new connections to GCP. Let us know what you think about it!New Feature - Equinix Status
Starting today you can check the status of your network products on the new Equinix Status page. View status by product and metro for Equinix Connect, Equinix Fabric, Equinix Internet Exchange, Equinix Metal, Equinix Precision Time, Metro Connect and Network Edge. Be sure to bookmark the https://status.equinix.com/ page. We'd love to hear your thoughts, give feedback online or comment below. Learn more about Equinix Status by reading the documentationBuilding Highly Resilient Networks in Network Edge - Part 1 - Architecture
This is first part of a series of posts highlighting the best practices for customers who desire highly resilient networks in Network Edge. This entry will focus on the foundational architecture of Plane A and Plane B in Network Edge and how these building blocks should be utilized for resiliency. For more information on Network Edge and device plane resiliency please refer to the Equinix Docs page here. Dual Plane Architecture Network Edge is built upon a standard data center redundancy architecture with multiple pods that have dedicated power supplies and a dedicated Top of Rack (ToR) switch. It consists of multiple compute planes commonly referred to as Plane A and Plane B for design simplicity Plane A connects to the Primary Fabric network and Plane B connects to the Secondary Fabric network The most important concept for understanding Network Edge resiliency: the device plane determines which Fabric switch is used for device connections. Future posts will dive much deeper in the various ways that Network Edge devices connect to other devices, Clouds and co-location. While referred to as Plane A and Plane B, in reality there are multiple compute planes in each NE pod The actual number varies based on the size of the metro This allows devices to be deployed in a manner where they are not co-mingled on the same compute plane, eliminating compute as a single point of failure Network Edge offers multiple resiliency options that can be summarized as device options and connection options Device options are local and provide resiliency against failures at the compute and device level in the local metro This is analogous to what the industry refers to as ”High Availability (HA)” Connection resiliency is a separate option for customers that require additional resiliency with device connections (DLGs, VCs and EVP-LAN networks). This will be discussed in depth in separate sections. It is common to combine both local resiliency and connection resiliency, but it is not required—ultimately it depends on the customer’s requirements Geo-redundancy is an architecture that expands on local resiliency by utilizing multiple metros to eliminate issues that may affect NE at the metro level (not covered in this presentation) Single Devices Single devices have no resiliency for compute and device failures The first single device is always connected to the Primary Compute Plane * Single devices always make connections over the Primary Fabric network Single devices can convert to Redundant Devices via the anti-affinity feature Anti-Affinity Deployment Option By default single devices have no resiliency However, single devices can be placed in divergent compute planes. This is commonly called anti-affinity and is part of the device creation workflow Checking the "Select Diverse From" box allows customers to add new devices that are resilient to each other Customers can verify this by viewing their NE Admin Dashboard and sorting their devices by "Plane" This feature allows customer to convert a single device install to Redundant Devices By default, the first single device was deployed on the Primary Fabric The actual compute plane is irrelevant until the 2nd device is provisioned The 2nd device is deployed on the Secondary Fabric AND in a different compute plane than the first device Resilient Device Options These options provide local (intra-metro) resiliency to protect against hardware or power failures in the local Network Edge pod By default, the two virtual devices are deployed in separate compute planes (A and B) In reality there are more than two compute planes, but they are distinct from each other The primary device is connected to the Primary Fabric network and the secondary/passive device is connected to the Secondary Fabric network Redundant Devices Clustered Devices Deployment Two devices, both Active, appearing as two devices in the Network Edge portal. Both devices have all interfaces forwarding Two devices, only one is ever Active. The Passive (non-Active) device data plane is not forwarding WAN Management Both devices get a unique L3 address that is active for WAN management Each node gets a unique L3 address for WAN management as well as a Cluster address that connects to the active node (either 0 or 1) Device Linking Groups None are created at device inception Two are created by default to share config synchronization and failover communication Fabric Virtual Connections Connections can be built to one or both devices Single connections are built to a special VNI that connects to the Active Cluster node only. Customer can create optional, additional secondary connection(s) Supports Geo-Redundancy ? Yes, Redundant devices can be deployed in different metros No, Clustered devices can only be deployed in the same metro Vendor Support All Vendors Fortinet, Juniper, NGINX and Palo Alto The next post will cover the best practices for creating resilient device connections with Device Link Groups and can be found here.Building Highly Resilient Networks in Network Edge - Part 3 - EVP-LANs
This is the third part of a series of posts highlighting the best practices for customers who require highly resilient networks in Network Edge. This entry highlights how to build resilient EVP-LAN connections in Network Edge. EVP-LAN is another method to connection Network Edge devices EVP-LANs differ from DLGs in that they connect to Network Edge devices and Fabric ports All EVP-LAN connections go to the Fabric, even for devices in the same metro--this is in contrast to DLGs which can be local or remote. As of November 2023, multiple NE devices in the same metro can be part of the same EVP-LAN network, removing the previous restriction of a single NE device per metro. Customers that require maximum resiliency should deploy additional EVP-LANs that span both the Primary and Secondary Fabric networks The same logic applies for EVP-LANs such that they should spread across Primary and Secondary Fabric planes The current maximum bandwidth for all EVP-LAN connections in the same metro is 10GB. This may change in the future. Redundant Devices For proper resiliency, each device in the Redundant Device pair will require a single connection to two different EVP-Networks The Primary device on the Primary plane will use the Primary Fabric switch The Secondary device on the Secondary plane will use the Secondary Fabric switch Clustered Devices Clustered devices are different in that the workflow allows connections to be built to either the Primary or Secondary Fabric For proper resiliency, each node in the Cluster will require a single connection to two different EVP-Networks The next post will cover the best practices for creating resilient Fabric Virtual Connections. You can read the first part of this series here.What is your offsite disaster recovery strategy?
In this blog, we discussed how Equinix customers simplified and strengthened strategies for bringing workloads back online quickly and avoiding downtime. What are the strategies, solutions, and best practices your organization has in place to achieve optimal recovery time and recovery point objectives?Digital Leaders Video Series: HPE
In this episode, Equinix Chief Revenue and Customer Officer Karl Strohmeyer and Keith White, EVP & GM of HPE GreenLake Cloud Services Commercial Business discussing the transformation within HPE as well as the partnership with Equinix that is driving innovation for our customers.NetworkChuck: This is where Internet Lives
Imagine billions of dollars of tech, AI GPUs & LPUs, and the literal backbone of the internet, all humming along in one of the most secure buildings on Earth. We're talking about the secret sauce that makes the digital world go 'round, and NetworkChuck's taking us on an exclusive tour of Equinix DA11 & The Infomart! Be sure to share the LinkedIn post from Equinix!
Building Highly Resilient Networks in Network Edge - Part 4 - Virtual Connections
This is the fourth and final part of a series of posts highlighting the best practices for customers who require highly resilient networks in Network Edge. This entry highlights how to build resilient Fabric Virtual Connections. Virtual connections allow NE devices to connect to CSPs, NSPs and ISPs as well as co-location The same logic still applies: the NE device plane determines which Fabric switch is used The VC connection workflow is very similar to the EVP-LAN workflow with some differences Customers that require VC link resiliency should create two or more VCs to their NE devices with each connection traversing the Primary and Secondary fabric switch Some CSPs like Azure require resiliency but most do not The Fabric portal allows connections to be created as redundant or single-legged The workflow is highlighted in the next few slides for both Redundant and Clustered devices Redundant Devices Clustered Devices This concludes a four part series on building Highly Resilient Networks in Equinix Network Edge. You can read the first part of this series here. For more helpful resources please visit: Architecting for Resiliency https://docs.equinix.com/en-us/Content/Interconnection/NE/deploy-guide/NE-architecting-resiliency.htm NE Geo-Redundancy Options https://docs.equinix.com/en-us/Content/Interconnection/NE/deploy-guide/NE-geo-redund-options.htm NE Device Link Resiliency https://docs.equinix.com/en-us/Content/Interconnection/NE/deploy-guide/NE-device-link-resiliency.htmBuilding Highly Resilient Networks in Network Edge - Part 2 - Device Link Groups
This is the second part of a series of posts highlighting the best practices for customers who require highly resilient networks in Network Edge. This entry highlights how to build resilient Device Link Group (DLG) connections. For more information on Device Link Resiliency please refer to the Equinix docs page here. Device Link Groups are used to connect Network Edge device interfaces to other Network Edge device interfaces They can be local (same metro) or remote and are a shared broadcast domain A single DLG, like a single Ethernet cable, provides no resiliency Local DLGs do not traverse the Equinix Fabric and aren’t susceptible to Fabric switch outages Hybrid DLGs have some devices connected to the Primary Fabric plane and other to the Secondary Customers that require maximum resiliency should deploy additional DLGs that connect to both the Primary and Secondary Fabric networks Redundant Devices can have one or both devices connect to the DLG Clustered devices act as one logical device, therefore the cluster is represented as a single entity Each device will build connections to the Plane to which it is connected as shown here: Redundant Devices show as individual entities in the DLG workflow Clustered Devices are represented as a single logical entity, connecting the DLG to the active node (node 0 is active by default) In October 2023 a new feature was released that allows customers to choose which Fabric plane the DLG is connected to: Primary or Secondary Previously, all connections were made over the Primary Fabric plane by default Customers now have control over the level of resiliency for their DLGs. Single DLGs will have no resiliency but customers may opt to deploy a 2nd, parallel DLG for connections that are business-critical. The 2nd DLG will incur additional Fabric charges and will consume an additional interface on every connected Network Edge device We do not see value in creating multiple, local (same metro) DLGs for resiliency, but we do not restrict customers who want to deploy in this manner Local DLGs do not traverse the Fabric switches and incur no charges today Customers now have the control to deploy resiliency with DLGs based on their requirements and budget as shown below The next post will cover the best practices for creating resilient EVP-LAN connections. You can read the first part of this series here.Rearchitecting a Global Connected-Car Network
A recent deployment by one of our partners, Travelping, demonstrates an interesting use case for solving a cellular carrier issue using edge infrastructure capabilities from Equinix. The Problem? The carrier’s network, while global, was not set up to remove some of the multi-access complexity which then impacted latency, or meet all the data localization requirements for connected vehicle regulations. The Solution? Travelping’s solution was to deploy the PDN Gateway functionality virtually in an Equinix data center in Korea using Equinix Metal, the bare metal cloud service that provides automated dedicated compute infrastructure on demand globally. Check out the full story on our blog
