What’s the quickest and slowest deployment in your career?
Minutes? Hours? Days? Months? Years? Let’s hear it! Don’t settle for months, you’ve got Equinix within minutes. Be the first to test drive Equinix Deploy and use our self-service capabilities across Equinix Metal, Equinix Network Edge and Equinix Fabric.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.
Great video to share with anyone new to interconnection and data centers
Hi All - New to the community and looking forward to connecting and learning! If you or any new hires on your team (or your mom!) are new to interconnection, ecosystems and data centers, this short “Where is the Physical Internet?” video from investment company Cowen is an excellent intro from the consumer perspective. It's a 9-minute walk-through of Equinix’s NY5 facility that includes insight into the physical infrastructure responsible for securing, cooling/powering, and connecting a modern data center. During the tour, you’ll also learn about the ecosystems at the NY5 data center that attract companies to interconnect there. The video is meant for anyone interested in learning more about where and how data is stored and exchanged. Hope you like it as much as I do!
New Term-Based Discounts for Equinix Fabric Are Here
We're excited to introduce Equinix Fabric Term-Based Discounts for inter-metro i.e. remote virtual connections (VCs) between your own assets and to your service providers including hyperscalers such as AWS, Azure, Google Cloud and Oracle. This new pricing option is designed to help you save more while enjoying the high-performance connectivity you rely on. What's New? You now have the option to select 12, 24, or 36-month contracts for inter-metro VCs from your Fabric ports, Network Edge virtual devices and Fabric Cloud Router instances. Here's how you'll benefit: Lower Monthly Rates: Save between 15% and 50% compared to on-demand pricing. For example, a 1 Gbps inter-metro virtual connection between London to New York drops from $1005/month to just $503/month with a 36-month term-based plan. See how much you can save using the Fabric pricing calculator, accessible via the Fabric portal. Simple Provisioning: No approvals required. Just select your term in the self-service portal or Fabric API and enjoy the savings. Broad Capability Support: Applicable across Point-to-Point (EPL & EVPL), Multipoint-to-Multipoint (EP-LAN & EVP-LAN) and IP-WAN services supported by Fabric Cloud Router. Also supported for Z-side service tokens. Predictable Cost Structure: Term based contracts provided set monthly rates, making it easier for you to manage your annual budget. Things to Note Discounts are available only for inter-metro VCs (intra-metro i.e. local VCs are not eligible. Discounts are currently not supported on Network Edge virtual devices to AWS, but are coming soon. Term-based discounts cannot be added to existing VCs, so you’ll need to create a new VC with your chosen term. Why This Matters By locking in discounted rates, you can optimize costs and achieve predictable spending without sacrificing performance, reliability, or flexibility. This is the perfect opportunity to create cost-efficient connectivity solutions tailored to the demands of your business. We'd Love to Hear From You Tap into these savings today by selecting a term-based discount during your next VC provisioning. We’d love to hear how this pricing option benefits your operations. Share your feedback with the team!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.Network Edge Interface Statistics
Now you can monitor your Network Edge device utilization traffic by accessing your device details. In your Virtual Device Inventory, click on the device you want to monitor. In the Device Details, click the Interfaces tab. Expand the arrow next to the port you want to monitor and a graph will display showing Inbound and Outbound traffic for the last 7 days. Refresh the graph by clicking Refresh. Change the duration using the drop-down. Choose Last 7 days or Last 24 hours.Want to help us improve Metal, Fabric, and Network Edge?
We're actively working to make your experience with products like Metal, Fabric, and Network Edge better. We've put together a fairly short survey (it'll take 10 minutes) to get your input on what's working (or not!). The survey will be open through Feb 19th. Beyond helping us help you, the first 100 respondents will receive a $50 credit to the Metal store. Start the survey here.
