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 astandard 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 Fabricnetwork 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 "SelectDiverse 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 thePrimary Fabric network and thesecondary/passive device is connected tothe 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!
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 devicesandFabric 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. Asof 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 boththe 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 theRedundant Device pair will require a singleconnection to two different EVP-Networks The Primary device on the Primary planewill use the Primary Fabric switch The Secondary device on the Secondaryplane will use the Secondary Fabric switch Clustered Devices Clustered devices are different in that theworkflow allows connections to be built toeither the Primary or Secondary Fabric For proper resiliency, each node in theCluster will require a singleconnection 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 serieshere.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.CFP Readiness for Equinix Demo Day
⛔Closing May 5th The May 5th CFP closing date is fast approaching for Demo Day. Submissions and edits to submissions can be made at Equinix Demo Day 2023 Call for Proposals. Whether you've expressed interest, submitted a draft CFP, or already began working on your demo, here are some considerations to make your CFP standout and make your presentations memorable and actionable. 🔨 Nail the theme The event focus is Equinix integration with talks and demos where the code is shown and is user repeatable. Some example scenarios: A product that includes cloud provider integrations giving it the ability to deploy and manage Equinix resources. This may take advantage of public IaC (Infrastructure as Code), Kubernetes controllers, or SDK (Go, Python, Java) tools for Equinix Metal. Prove your project is resilient. Show it. Destroy it. Show how it can be reprovisioned. Can your project be brought back up without careful attention? A user case story or journey is told. How is this story a unique or common experience? How was integration with the platform utilized? What challenges were presented and overcome by this integration? Tell us more about the developer experience. What made Equinix the right choice for this project? What features would have made this smoother? What features made this shine? How did the developer support, the online community, documentation, tools, or platform features provide value to your organization, product, or project. If the product is a managed service or closed source, these examples would help to make the demo more applicable to the event theme: Helper code and documentation (a tool assisted guide or workshop) reproduces the environment and demonstrates applications running on this product integration. A story about the development process of the integration and the lessons learned Additional routes to explore for this event (fitting open source projects well): How does this solution stack up with alternatives in the ecosystem What design and development choices were made for this project How has the community size and adoption changed What are some of the open challenges past or present, how have they been overcome 🧰 Share your Toolbox There are several ways to publish your integration to get early eyes on it and share it with the community. Our first choice for projects like this is GitHub. Consider the following repositories on the Equinix Labs GitHub organization as a place to park your integration or a template for your project: Equinix Workshop - Create a workshop using this template. Once you've customized the project, enable GitHub Pages and the workshop will be publicly hosted and available. Terraform Template - This template bakes in our best practices and is ready-made for publishing an Equinix Terraform module Terraform Equinix Labs - If you want to share your project with other users of Equinix and turn that project into a workshop, take a look here and open a PR adding your project as a sub-module. Terraform Kubernetes Addons - If your project can run in any Kubernetes environment running on Equinix Metal and has Equinix resource requirements, submit your project as an add-on here so others can take advantage of your integration. Do you have another location in mind? Let us know. 🦺 Pass Inspection As the hosts of the event, we believe the value of any particular product can be demonstrated through open integrations. Our particular focus is on the capability to integrate with Equinix in a user demonstrable and reproducible way, along with the capabilities unlocked through those integrations. The review panel will process CFPs with these considerations. Keep in mind, other CFPs will target common user scenarios especially on network Infrastructure and edge compute automation. While event presentations are not in a product competition, for the purposes of the CFP review, there is a competition of compelling stories. The more engaging we believe those stories fit our user and engineering audience, the more they demonstrate the themes of integrations with Equinix in repeatable ways, the better the chance will be for the CFP to be accepted. The best presentations will be ones where the practitioner viewer is compelled to pull down the discussed project and start experimenting with it to deliver their projects. The presentation, including demos or integrations, does not need to be ready at the time the CFP is submitted. A CFP may be tentatively accepted with the recommendation for a different format or criteria for improving the fit. We will be considering alternate presentation formats for CFPs including panels, lightning talks, and workshops. Tentative acceptance communications will start on May 10th with final acceptance communicated on May 12th. 🧱 Build Your Story Once accepted, we want to have the opportunity to field test your work and storytelling in an advocacy stream or a recorded solution demo. The advocacy live stream is the perfect environment for an early, rough-edges, walkthrough. For demo day, we encourage (but do not require) ironed presentation videos to be submitted no later than two weeks ahead of the event. This will help to avoid any on-air mishaps such as a missed step, flakey builds or runs, and network or availability issues. Presentation windows should leave space for discussion during and after. Another format we can explore is to have the recording voiced over live by the presenter with an event host providing real-time feedback. In this case, the sooner pre-recordings can be offered the better. 🏗️ More Opportunities There are more opportunities for collaboration through presentations and demos on Equinix. This includes streams on Equinix Labs Live and recordings targeted at our solution teams. Future events may provide a better audience for talks and demos that we can't fit into this event. 🚧Demo Site The event page for Demo Day 2023 (equinix.com) is up. As the event nears, we'll be reaching out to CFP submitters with more details on preparation and ways to spread the word. If you haven't already, subscribe to the Equinix Developers YouTube channelwhere you can find playlists of our previous live streamed events: Uncensored GIFEE Day Proximity Dates to remember: CFP Closes: May 5, 2023 Tentative Acceptance: May 10, 2023 Acceptance: May 12, 2023 Pre-recordings submitted: June 7, 2023 Live Streaming: June 21, 2023. See you there! Participants must agree to follow a code of conduct.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 take10 minutes) to get your input on what's working (or not!). The survey will beopen 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.
