Home Networking service Isn’t it time for a consumable network fabric?

Isn’t it time for a consumable network fabric?


Data centers have been built around consumable compute and storage resources for decades. However, the network and switches needed to support this were not included. Because of this, hyperscalers encountered scalability limits and, for a time, built networks that attempted to meet compute and storage demands. Network equipment suppliers have been slow to follow suit; maybe because their businesses were built around selling specially designed equipment.

About the Author

Erwan James is Senior Solutions Architect and Regional Product Line Manager for Nokia Global enterprise on a web scale.

Now is the time for network providers to change their thinking. As data center interconnection and distributed edge clouds become the norm, especially for service companies embracing Industry 4.0, it’s time for switches to become more consumable. In other words: having the ability to adapt to the ever-changing needs of the IT environment.

Emerging demands

COVID-19 has illustrated that, even with consumption of basic IT services, network traffic patterns can change dramatically due to sudden large-scale transitions; in this case, towards remote working and an explosion of consumer-led video and gaming services.

However, the network demand patterns for edge cloud services will be much more variable with Industry 4.0. And, with the shift to enterprise 5G wireless services, the network will need to adopt cloud-native principles to provide the elastic scalability necessary to meet these new business demands. Cloud, colocation and interconnection providers will only be able to successfully capture this market if they can, like today’s hyperscalers, scale the network in the same way they currently manage compute resources. and storage.

Ideally, the network will follow many of the same practices established by data centers for other consumables. Network functions and applications need to be delivered using distributed microservices on platforms like Kubernetes that are intent-based, while automating much of the lifecycle of those microservices. Functions and applications need to be observable, which means telemetry needs to be more granular and sophisticated when capturing network performance. And, finally, the network structure must be able to fail smoothly with limited service impact and recover automatically.

Network fabric

Large-scale data center IT infrastructures typically have a large number of servers hosting distributed cloud applications. To provide a consumable network with both scalable connectivity and automated lifecycle operational management, the switch groups in the data center network must be managed as a logical unit, called a fabric, with Automation for all phases of the operational matrix lifecycle – including Day-0 design, Day-1 deployment, and Day-2 + operations.

To provide large-scale automation, fabric operations must have access to model-based abstract design intents. As an option, network providers can also pre-certify these models in their own laboratories. With these models, network creation can be automated according to verified and validated designs. In this model, the structural design models would automate much of the repetitive and mundane configuration tasks, following higher-level design inputs or intentions. The abstract intention should focus on generic constructs of the data center infrastructure, such as “number of racks”, “servers per rack”, “dual hosting”, etc.

To provide seamless connectivity for Virtual Network Service (VNS) or Converged Network Service (CNS) based application workloads over a multi-layered CLOS network, standards-based Layer 2 or Layer 3 connectivity is required. required. Everything should be “open to the wire”, relying on standard protocols, such as EVPN-VxLAN; which becomes a constitutive element of the networking of services.

As with DevOps, there must also be a NetOps methodology that ensures that intent-based automation can be expressed in declarative form or as “infrastructure as code”. This is important for solutions covering on-premises and off-premises hybrid clouds. It should also be possible to make frequent changes to the network configuration, while managing the risk of a change within a digital twin of the actual network – a digital network sandbox. This should allow NetOps to experiment, test, and validate various automation steps and, more importantly, validate failure scenarios and the associated closed-loop automation without the risk of trying them out on the production network. A digital sandbox can also be used to test and validate new network applications, activate new protocols, or when migrating to a new network topology.

Automation involves observability, but it has to go beyond the usual telemetry logs that capture uninterpreted network performance data. As distributed fabrics evolve, complexity requires more than usual business logic to understand what is going on. A baseline and advanced machine learning analytics should be used to provide easy-to-understand observations. Extracting and providing contextual information will allow the operator to understand the root cause of a problem and perform corrective actions as well as closed-loop automation in a programmable manner.


Finally, with a truly open system architecture, network automation should be able to integrate into a surrounding ecosystem by enabling pluggable “integrations” with SDDC (Software-Defined Data Center) stacks, such as VMware or Kubernetes stacks. . Here, the network has to align so closely with the ecosystem that it follows the needs of the applications and becomes invisible until a problem arises.

The mantra of the consumable network structure should be the same as data center operations in general: be simple, more agile, merge changes frequently, drive changes using automation, and validate the end state using the management stack. Deploy workflows or applications directly over the network, consume previously idle CPU cycles, gain relevant information locally, and take action immediately, all supported by a robust development environment for network applications supporting a wide range programming languages. This is the key to ensuring that the network is an integral part of the data center innovation platform, as a catalyst, not an inhibitor, to meet customer demands.

Source link


Please enter your comment!
Please enter your name here