Enabling Multi-tenancy within Enterprise IT Operations

by: Shehzad Merchant, Chief Strategy Officer at GigamonShehzad Merchant

Multi-tenancy is a well understood term in cloud and carrier environments where multiple customers serve as tenants over a common infrastructure. However, the notion of multi-tenancy, the associated SLAs for each tenant, and the ability to virtualize the underlying infrastructure to isolate individual tenants, is quickly making its way into enterprise IT operations. Today, enterprise IT organizations have multiple departments such as security, networking, applications, among others. Each department is increasingly being held to stringent requirements for ensuring network and application availability, responsiveness, and a good user experience. This is leading to an increasing reliance on various classes of tools that provide the ability to monitor and manage the applications, network, security, as well as user experience.  Many of these tools leverage Gigamon’s Visibility Fabric™ for optimal delivery of traffic from across physical and virtual networks to these tools. As departments are increasingly held to their own SLAs and KPIs, they need to be able to autonomously carve out traffic delivery to the departmental tools, as well as independently configure, manage, and adapt traffic flows to the departmental tools without impacting other departmental traffic flows. And they need to be able to do all of this over a common underlying Visibility Fabric, which leads to a model where the Visibility Fabric needs to support a true multi-tenant environment.

With the GigaVUE H Series 3.1 software release, Gigamon introduces several enhancements to the Visibility Fabric that enable multi-tenancy and enable IT departments to optimize their workflows, reduce workflow provisioning times and provide for both privacy as well as collaboration among departments when it comes to their monitoring infrastructure.

There are three key aspects to these new capabilities.

  1. Enabling departments to carve out their own slice of the Visibility Fabric using an intuitive Graphical User Interface (GUI) that supports the workflow required for multi-tenancy. Empowering multiple tenants to apportion the Visibility Fabric each with their own access rights, sharing privileges and their traffic flows, through a drag and drop GUI-based model is a key step towards simplifying the provisioning model in a multi-tenant environment. Moving away from a CLI based approach to a GUI based approach is a key step towards improving workflows across departmental silos.
  2. Advancing Gigamon’s patented Flow Mapping® technology within the Visibility Fabric Nodes to support multi-tenancy whereby each tenant can carve out their own Flow Maps, ports, and actions, without impacting the traffic flows associated with other tenants. This is a significant architectural advancement that builds on Gigamon’s existing Flow Mapping technology to provision resources within the underlying visibility nodes based on the department’s (or tenant’s) requirements.
  3. Providing role based access control (RBAC) so that departmental users can work both collaboratively as well as privately over the common underlying Visibility Fabric.

These capabilities represent a significant advancement in how IT operations can take advantage of the Visibility Fabric to rapidly deploy new tools, enable real time or near real time tuning of the Visibility Fabric and better meet their individual SLAs and KPIs. Taken together, these key capabilities empower IT organizations to provide Visibility as a Service to their various departments.

For more information, please see the Visibility as a Service Solutions Overview.

Is OpenFlow Going Down the Path of Fiber Channel?

by: Shehzad Merchant, Chief Strategy Officer at Gigamon
The promise of OpenFlow is open, standardized networking. However, recent trends suggest that OpenFlow deployments are straying away from that promise and moving towards end-to-end lock-in, much like the days of fiber channel.
Today, if you take an OpenFlow-enabled switch from one vendor, an OpenFlow controller from another vendor and run an application on top of that, the experience you get will vary significantly from one ecosystem of controller and switch to another. Lack of standardized northbound APIs and lack of consistency in OpenFlow switch implementations are some of the factors causing an “end-to-end lock-in.”
In a post on SDNCentral, I explore some of the reasons why I think that the OpenFlow community is beginning to stray from its promise of open, interoperable and standardized networking, and suggests some key changes that could redirect and positively impact the direction of the OpenFlow initiative.
For the full blog post visit: SDN Central