One of the more keenly awaited features with Dell EMC Networking’s Next Gen OS10, is SmartFabric Services. Dell EMC already has both controller based and controller-less fabric solutions in its portfolio via its SDN Ecosystem. SmartFabric Services, as part of OS10, introduces both breadth and depth to its fabric offerings.

This post is the first of the two parts intended to introduce this feature. The intent is to make this introduction in a concise, easily digestible way.

Features

SmartFabric offers a controller-less, distributed control plane model. It satisfies several key criteria/characteristics, deemed crucial for next gen fabric solutions – some of which are listed below. The list is not exhaustive by any means, only representative.

• Automation: SmartFabric Services’ initial focus is on offering an automation-centric fabric for Pod based solutions. The spectrum of such solutions includes everything from DIY (e.g. VxRail), to Integrated (VxRack etc.) as well as Turn key (Isilon, ECS etc.). Over time, SmartFabric Services will expand its capabilities to incorporate solutions for ESX (VM Tracing, vMotion Port Profile Migration etc.), NSX VTEP, EVPN VXLAN as well as Generic LAN fabric. As an example, the first iteration includes enablement for Isilon Backend.
• Life Cycle Management: This will allow
  • Fabric level firmware upgrades for participating nodes,
  • Post upgrade validations and consistency checks, as well as
  • The ability to rollback upgrades across the fabric, in case of issues with a specific node.
• Single Point of Management/Visibility: The fabric is managed as a single logical entity, with all the participating nodes simulating a chassis. Visibility and debugging too are holistic, executed as a fabric function instead of the traditional box-by-box orientation.
• Scale: SmartFabric Services offers both Scale as well as Pay as you grow expansion. The footprint can expand as dictated by requirements, over time.
• Self-Contained Fabric within the Solution Pod, with seamless external connectivity: Pod internals, in the context of networking, remain the jurisdiction or remit of that specific solution. The fabric should connect seamlessly with the External/Core Network. Further, the external network should not be impacted by any issues/instabilities internal to the Pod.

Components

A quick review of some of the key components making up the SmartFabric.

• External Fabric Manager (EFM): An optional component sitting outside the fabric, making management calls into it. For example, an orchestration or management platform like vCenter, VxRail Manger etc. that makes Rest-API calls to the fabric. The component receiving this call is the SmartFabric Master.
• SmartFabric Master: The end-point within the fabric to which the Fabric Manager makes its calls. It exposes the APIs and fabric data models for consumption by Fabric Manager. The Master Services module is hosted by the Master node in the fabric. We will examine this in more detail, subsequently.
• Fabric Agent: Each node in the fabric hosts their own Fabric Agent. When the EFM requests an operation on specific fabric nodes/switches, the command’s first stop within the fabric, is the SmartFabric Master. From there, the commands are retrieved by the Fabric Agents for their respective nodes – to be passed to the implementation level modules for execution.
• Distributed Database: Maintains the configuration, both “is” and “to be”, for the fabric. It is an internal component of Control Plane Service (CPS). The database is identical on ALL nodes within the fabric.

In addition to the above, I feel it would help to have a quick look at the Control Plane Service, and its Distributed Database.

Control Plane Service:

This is the heart of the fabric. It can be thought of as the keystone, the fundamental enabler of SmartFabric Services.

I will cover CPS as part of a separate post on OS10 which I intend to write, permitting bandwidth. However, this post does warrant some commentary on it.

CPS is a Core component of OS10. It provides an object-centric framework that facilitates interactions between applications and OS10 software components. i.e. the API provided by CPS is used by applications, to interface with OS10 software components. CPS classifies applications as Client or Server. Server Applications respond to requests by client apps by executing needed operations. Clients request operations such as get, set etc. on various objects.

CPS has an embedded distributed database, which is internal to it and not accessible externally. As we will see when discussing event handling, it utilizes a publish/subscribe mechanism to facilitate production & consumption of information. Applications classed as Server would publish events taking place on objects, for e.g. their creation or modification. The “Client” applications can subscribe to these events so they get notified whenever there is a change.

In part II of the post, we will have a look at the Operations & Event handling within SmartFabric Services.