A recent comment on LinkedIn sparked debate about data and control planes, with reference to modern storage management.  ViPR, the rebranding of iWave Software’s Storage Automator, was EMC’s attempt to separate data and control but, in reality, was more about automated provisioning.  How has the “plane” landscape changed in ten years?

Background

EMC Corporation acquired iWave Software in January 2013, transforming their Storage Automator software via Project Bourne into something called ViPR.  The ViPR solution allegedly implemented storage virtualisation, although actually provided a way to multi-tenant provisioning operations.

Storage Automator was a good product and was useful in large-scale storage environments that needed policy-based provisioning.  I anticipated using the software in managed service scenarios where specific site knowledge wasn’t available.  As such, Storage Automator created a framework around the provision process that enabled a greater control over how resources were allocated out.

EMC had one major problem with Storage Automator – it only supported EMC storage platforms.  The age-old issue with all SRM (storage resource management) products is how a single vendor delivers support for competing storage solutions.  SMI-S was one failed idea.  Unfortunately, vendors offered only lip-service integration on a subset of features.  To get real knowledge of a platform required intimate and long-term use of storage hardware.

So, EMC “open-sourced” ViPR in an attempt to get competing vendor’s customers to write the integration code.  Naturally, this didn’t work, as EMC wanted to take this code and integrate it back into the commercial offering.

Three Planes

As we approach the middle of the 2020s, storage management is seeing some degree of evolution.  We can divide storage solutions into three components – the control, data and service planes.  The addition of the service plane is required for two reasons.  Firstly, storage has transitioned to a service, exemplified by AWS S3 (the Simple Storage Service) first introduced in 2006.  Secondly, storage is now required to offer greater levels of data management capabilities.  For example, APIs provide the capability to protect data, implement data scanning (for ransomware and malware), regulatory controls (finding PII) and to optimise content.  At a high level, the three planes implement the following features.

Data Plane – the physical storage of content.  This layer includes safely storing data with redundancy (such as RAID or erasure coding), data placement, data optimisation (compression, deduplication) while maintaining data availability.  The data plane should understand the capability of storage media and be able to place data on the most efficient platform possible.

Control Plane – the management of storage resources presented to the consumer (typically a host physical/virtual server, container or application).  This layer includes the implementation of security controls and protocols, enablement of provisioning and decommissioning, with other aspects of physical fleet management.  We would also now see this layer offering services for purchasing storage capacity and reporting on capacity utilisation and performance. 

Service Plane – additional services for data management.  This plane ameliorates the data plane by adding service-based functionality that could include data mobility, data protection (integrated snapshots and API-based backups), and APIs for data scanning (ransomware detection, PII detection).

The specific location of some services is debateable.  The telemetry capabilities, for example, could be part of the Service Plane, rather than the Control Plane.

Implementations

Storage vendors haven’t been slow in adopting the requirements of the storage plane model.  NetApp, for example, has been talking about the data fabric concept since the mid 2010s.  Pure Storage had implemented service and control plane capabilities through Pure1 and Fusion.  HPE introduced the Data Services Console as part of the GreenLake framework of storage (and other) offerings.  On the data protection side, Infinidat has introduced automated scanning and snapshot coverage for ransomware mitigation (see this research note for more details).

We’ve written extensively on the evolution of the storage ecosystem and how certain platforms need to build in capabilities of each plane.  For example, HCI, which offers internally supported data storage, needs to have APIs for data protection and other features (see this post from 2018).  We expanded on this discussion in 2019, with this post discussing the need for APIs across all of storage (link here).  However, this topic is not new.  Here’s a post we wrote in 2012 that discusses the need to integrate APIs into storage platforms (link here).

The Architect’s View®

The division of data storage solutions into discrete “planes” is an evolution that addresses modern storage requirements.  Abstracting (and to a degree obfuscating) the underlying hardware from the host/application requirements is necessary in modern hybrid environments where consistency of access is required, irrespective of the physical location of data.  The service model makes storage more dynamically consumable, removing humans from the loop, which is clearly a “good thing”.

You can learn more about our views on the requirements for modern primary storage in the following eBook, available for immediate purchase and download online.

---

---

Copyright (c) 2007-2024 – Post #2c3e – Brookend Limited, first published on https://www.architecting.it/blog, do not reproduce without permission.