They say that “nothing is more certain than death and taxes.” And if you are in enterprise IT you know that nothing is more certain than technology obsolescence.  Storage media has rapidly evolved from HDD, to Hybrid Flash, to All Flash, to NVMe, and to Optane. Who knows what will be next. When Datera was founded, the primary goal was to design an architecture that is “built for change,” that eliminates painful forklift upgrades and data migrations, that is elastic, and that organically grows to accommodate customer needs and technology trends.

Datera is a software defined storage platform built with a unique scale-out architecture that enables rapid and flexible adoption of the latest industry-standard server and storage media technologies. Datera autonomously delivers a cloud-like user experience, business model and agility at enterprise scale, with linear performance and continuous availability. Datera has been a game changing technology for some of the largest enterprises in the world. When traditional “scale out storage” was not enough to meet enterprise’s evolving requirements and ability to rapidly adopt new technologies, we innovated to make the architecture scalable, autonomous, dynamic and future proof, learn how…

1 | True Software Defined for Ultimate Flexibility

Storage solutions are generally “software-based” and run on some kind of hardware platform. What differentiates Datera is that the software runs on a broad range of industry standard servers accommodating different storage media types and network ports. The software currently supports HPE, Fujitsu, Dell, Intel, Supermicro, and Quanta server platforms.

Moreover, the software is optimized for the latest storage media technologies including SAS/SATA SSD, NVMe/Optane and Hybrid Flash as well as high performance NICs. Datera will even allow servers with different media types from multiple vendors to be composed into a single cluster to deliver a broad range of storage services for a variety of application price/performance needs. Want to mix and match Gen 9 and Gen 10 from the same vendor? That works as well. This ultimate flexibility allows your storage infrastructure to organically evolve to meet future needs while avoiding vendor lock-in.

2 | Dynamic Data Fabric for Continuous Availability

The foundation of any scale-out storage system is a network of nodes that distributes the data for scale and resiliency. What differentiates Datera is that the data fabric dynamically re-distributes data without requiring downtime or service disruption. A full mesh rebuild process enables fast and transparent data recovery, server maintenance, rolling OS upgrades and workload re-balancing. The more nodes in a cluster the larger the swarm, the greater the durability, the faster the process and the less the system impact. Combined with native, advanced data services like snapshots, failure domains, stretched clusters and cloud backup the system provides continuous availability with protection from operator errors or even site failures.

3 | Optimized IO Stack for Linear Performance at Scale

Every solution will claim that it “scales.” But “scale out” is no longer enough in your rapidly evolving world of changing requirements and new technologies. Can you scale rapidly, and will the system autonomously move workloads based upon new resources?

The Achilles heel of most distributed storage architectures is the implementation of lock mechanisms for managing coherent access to data. This becomes a significant performance bottleneck as the system scales out. Datera is far more advanced, using a patented Lockless Coherency Protocol that completely avoids this problem. Combined with bare metal form factor, sophisticated multi-tiered caching, write coalescing, QoS and other optimizations the system delivers linear performance (sub-200µS latencies) at scale along with other benefits like extending flash media endurance.

Our early architectural design goal was to deliver a dynamic and autonomous scale out software defined solution. Anyone can deliver a scale out solution, but without the right architecture it will be rigid, and inefficient.

4 | Intelligent Management at Cloud Scale

Storage management solutions have recently begun emulating familiar public cloud solutions with web-based REST APIs and graphical user interfaces. What differentiates Datera is the use of sophisticated application templates to precisely define and control storage provisioning policies like media type, data resiliency, and snapshot schedules and more. These templates and polices fully expose the flexibility of the Datera platform. For example, a reusable template can be created for tenants that specifies different copies that combine All Flash and Hybrid Flash media types to provide both performance and resiliency. Combined with cloud orchestration plug-ins and data analytics Datera delivers a cloud-like user experience for provisioning storage with velocity and performance at scale.

5 | Continuous Self-optimization for Simple Operations

Managing a storage service can be challenging. There are competing goals to improve both resource utilization and performance. Other complex demands include setting application service levels while optimizing these results in terms of operational complexity and cost. Datera is once again unique, in that application behavior and storage resources are continuously monitored and intelligently optimized without user intervention. When new storage nodes or applications are added or removed from a cluster, resources are auto-discovered and the system is load balanced to optimize resource utilization to meet the most demanding service levels — making forklift upgrades a thing of the past. Combined with the efficiency of Datera’s full mesh rebuild process, the system is continuously optimized without service disruption or user intervention to enable simple operations.

So, does a future proof storage platform exist?

Of course, the answer is “yes.” For example, you could begin with a simple 4-6 node Datera cluster today, and continuously update and extend with new server/CPU and media technologies for 10-25 years. Always enhancing the resilience and performance, while maintaining the same UUID! If you have struggled with forklift migrations and upgrades every 3-5 years, you do not need to any longer!

You’re ready to take Tier 1 apps into production on Kubernetes, but storage is holding you back. Here’s how to configure Datera to optimize for production and scale.

You’ve containerized apps in Kubernetes and are ready to move to production but accessing storage dynamically has been a roadblock. This is where your choice of underlying storage fabric can make or break your ability to scale.

Your infrastructure is a wide assortment of server and storage classes, generations, and media—each one with a different personality. With the right storage fabric, neither the app developer nor the storage admin needs to be prescriptive about which resources are the best fit—that should be determined in human language terms (e.g. super performant, highly secure) and based on Storage Classes defined in Kubernetes.

Defining Storage Classes

Optimizing storage in Kubernetes is achieved by managing a class of storage against application intent. Just like a Terraform script that defines application needs, the storage platform should supply storage needs using templates whether you are looking for IOPs, latency, scale, efficiency (compression and dedupe), security (encryption).

Dynamic storage provisioning in Kubernetes is based on the Storage Classes. A persistent volume uses a given Storage Class specified into its definition file. A claim can request a particular class by specifying the name of a Storage Class in its definition file. Only volumes of the requested class can be bound to the claim requesting that class.

Multiple Storage Classes can be defined to match the diverse requirements on storage resources across multiple applications. This allows the cluster administrator to define multiple types of storage within a cluster, each with a custom set of parameters.

Your storage fabric should then have an intelligent optimizer that analyzes the user request, matches to resources, and places them appropriately onto a server that matches the personality of the data. It should also be policy-driven and use telemetry to continuously inventory and optimize for application and microservice needs without human involvement.

Let’s say you want to create a Storage Class to access your MySQL data, add extra protection by making 3 replicas, and place it in a higher performance tier to serve reads/writes better. You can set this up in Datera with just a few steps.

Create a Storage Class for the Datera storage backend as in the following datera-storage-class.yaml file example here:

$ cat datera-storage-class.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
     metadata:
          labels:
          name: datera-storage-class
     namespace:
provisioner: io.datera.csi.dsp
reclaimPolicy: Delete
parameters:
     template: “basic”
     secretName: “mysecret”
     secretNamespace: “default”
     fsType: “xfs”

$ kubectl create -f datera-storage-class.yaml

Datera allows the Kubernetes cluster administrator to configure a wide range of parameters in the Storage Class definition. Another way to define a Storage Class is with labels (policies), e.g. gold, silver, bronze. These options convey the storage personality and define necessary policies at Datera Storage System level.

It’s very easy to compose three or 300 Storage Classes on the fly in Datera. To manage data services such as dedupe, compression and encryption for high velocity apps and microservices, you can attach volumes to a storage pool that can be further configured alongside policies for data protection and efficiency. Where typically this is done in a silo, Datera can achieve this level of velocity and scale for Tier 1 workloads.

If you have absolutely no idea what the app requirements will be, that’s ok—Datera uses AI/ML to find the best placement, and the resources and will automatically adjust based on inputs. For mature apps, you can graduate those to policies and templates.

No Scale Without Automation

Kubernetes lets applications scale along with a Storage Class without deviating from the base definition/requirements of resources. Datera keeps that promise intact by binding Storage Classes to templates, and homogeneously extend resources (volumes) to match the intent of applications (consumers).

As application needs change, the storage should adapt alongside it and not rely on human intervention. This is done by defining policies and templates. The storage fabric should also recognize and adapt to new nodes or hardware and automatically adjust to enhance performance, capacity, and resilience of a cluster, as well as making the resources available to all the underlying PVs.

Create the StatefulSet:

$ kubectl create -f consul-sts.yaml

List the pods:

$ kubectl get pods -o wide
NAME         READY   STATUS            RESTARTS    AGE  IP            NODE
consul-0     1/1     Running           0           32s  10.38.3.152   kubew03
consul-1     0/1     PodInitializing   0           15s  10.38.4.4     kubew04

The first pod has been created. The second pod will be created only after the first one is up and running, and so on. StatefulSets behave this way because some stateful applications can fail if two or more cluster members come up at the same time. For a StatefulSet with N replicas, when pods are deployed, they are created sequentially, in order from {0…N-1} with a sticky, unique identity in the form $(statefulset name)-$(ordinal). The (i)th pod is not created until the (i-1)th is running. This ensures a predictable order of pod creation. However, if the order of pod creation is not strictly required, it is possible to create pods in parallel by setting the podManagementPolicy: Parallel option in the StatefulSet template.

List the pods again to see how the pod creation is progressing:

$ kubectl get pods -o wide
NAME	     	READY    STATUS        RESTARTS  AGE    IP             NODE
consul-0      	1/1      Running       0      	 29m    10.38.3.152    kubew03
consul-1      	1/1      Running       0      	 28m    10.38.4.4      kubew04
consul-2      	1/1      Running       0      	 27m    10.38.5.128    kubew05

Now all pods are running and forming the initial cluster.

Scaling the Cluster

Scaling down a StatefulSet and then scaling it up is similar to deleting a pod and waiting for the StatefulSet to recreate it. Please, remember that scaling down a StatefulSet only deletes the pods, but leaves the Persistent Volume Claims. Also note that scaling down and scaling up is performed similar to how pods are created when the StatefulSet is created. When scaling down, the pod with the highest index is deleted first: only after that pod gets deleted, the pod with the second highest index is deleted, and so on.

What is the expected behavior scaling up the Consul cluster? Since the Consul cluster is based on the Raft algorithm, we have to scale up our 3 nodes cluster by 2 nodes at the same time because an odd number of nodes is always required to form a healthy Consul cluster. We also expect a new Persistent Volume Claim is created for each new pod.

Scale the StatefulSet:

$ kubectl scale sts consul --replicas=5

By listing the pods, we see our Consul cluster gets scaled up:

$ kubectl get pods -o wide
NAME	     	READY    STATUS          RESTARTS    AGE IP           	NODE
consul-0      	1/1      Running         0           5m  10.38.3.160	kubew03
consul-1      	1/1      Running         0           5m  10.38.4.10     kubew04
consul-2      	1/1      Running         0           4m  10.38.5.132    kubew05
consul-3      	1/1      Running         0           1m  10.38.3.161    kubew03
consul-4      	1/1      Running         0           1m  10.38.4.11     kubew04

Check the membership of the scaled cluster:

$ kubectl exec -it consul-0 — consul members
NAME	        ADDRESS           	STATUS        TYPE      BUILD   PROTOCOL    	DC SEGMENT
consul-0      	10.38.3.160:8301    	alive         server    1.0.2   2	        kubernetes
consul-1      	10.38.4.10:8301      	alive         server    1.0.2   2               kubernetes
consul-2      	10.38.5.132:8301    	alive         server    1.0.2   2               kubernetes
consul-3      	10.38.3.161:8301    	alive         server    1.0.2   2               kubernetes
consul-4      	10.38.4.11:8301      	alive         server    1.0.2   2               kubernetes

Also check the dynamic Datera storage provisioner created the additional volumes:

$ kubectl get pvc -o wide 
NAME              STATUS VOLUME                                   CAPACITY  ACCESS MODES   STORAGECLASS             AGE 
data-consul-0     Bound  pvc-91df35af-0123-11e8-86d2-000c29f8a512 1Gi       RWO            datera-storage-class     7m 
data-consul-1     Bound  pvc-a010257c-0123-11e8-86d2-000c29f8a512 1Gi       RWO            datera-storage-class     6m 
data-consul-2     Bound  pvc-adaa4d2d-0123-11e8-86d2-000c29f8a512 1Gi       RWO            datera-storage-class     6m 
data-consul-3     Bound  pvc-1b1b9bd6-0124-11e8-86d2-000c29f8a512 1Gi       RWO            datera-storage-class     3m 
data-consul-4     Bound  pvc-28feff1c-0124-11e8-86d2-000c29f8a512 1Gi       RWO            datera-storage-class     2m

Today, companies may be deploying apps by Storage Class. But according to IDC 90% of new applications will be built with a micro-services architecture this year. Data velocity must match micro-services with the right Storage Class, and continually and granularly enhance the storage environment with additional performance and capabilities—not via legacy arrays or monolithic and silo-ed major migrations, but via discrete racks. In other words, autonomous storage is a necessity for any business that needs to scale.

If you are planning to deploy Kubernetes, and experiencing any storage challenges with your legacy infrastructure, please click here to watch how Datera overcomes those challenges.

According to a recent Forbes article, container adoption is growing rapidly in the enterprise—much faster than expected. And according to a recent Gartner report, “By 2023, more than 70% of global organizations will be running more than two containerized applications in production, up from less than 20% in 2020.

Moving to containers, however, presents new challenges for storage provisioning. In particular, using traditional storage solutions for distributed containerized workloads turns out to be too complex and costly. Manual storage provisioning does not address the dynamic storage requirements efficiently at scale. Containers are dynamically created, destroyed, and moved across hosts in the availability zone. The stateful applications running inside these pods would require storage solutions that can automatically attach or detach and provision storage capacities across data-centers where these pods land. In addition the storage infrastructure should facilitate creating back-up and replicas of data to ensure high availability.

Containerized applications require diverse heterogeneous storage solutions such as HDD, SSD, NVME, Optane, block, or object. Thus the storage solution needs to be flexible, hardware-type agnostic, and support tight integration with popular container orchestration such as Kubernetes(K8s). This leads us to a software-defined architecture that abstracts storage software from its hardware, such as Datera.

Datera is a fully dis-aggregated scale-out storage platform, that runs over multiple standard protocols (iSCSI, Object/S3), combining both heterogeneous compute platform/framework flexibility (HPE, Dell, Fujitsu, Intel, and others) with rapid deployment velocity and access to data from anywhere. Datera’s Container Storage Interface (CSI) driver deeply integrates with the K8s runtime. It allows deploying entire stateful multi-site K8s clusters with a single K8s command and pushing application-specific telemetry to the Datera policy engine so that it can intelligently adapt the data fabric. Datera’s powerful storage classes and policy-driven workloads are a natural fit with Kubernetes.

Datera, organically extends Kubernetes concepts , admins do not need to look and match resources for the workloads, instead they can just define the application and type of resources it needs <admin_state> and Datera’s resource optimizer automatically picks the most suitable resources (including media, Optane, NVMe, SAS/SATA Flash or even spinning) <op_state>.

• Scale: Kubernetes has deployment primitives defined for scale, like StatefulSet which defines pod templates that ensure applications can scale up and down dynamically driven by the defined pod template. As a result of this, Kubernetes defines Storage Class, consisting of dynamic resources such as Persistent Volume Claims(PVC) and Persistent Volumes(PV). Datera extends this by defining Policies and Application-Templates. Templates provide consistency across Instances defined using the template, hence mapping the K8s applications to scale up using the consistent behavior of instance provisioning using Datera’s scale-out templates. While scaling the K8s statefulset, Datera can enable transparent data migrations for the provisioned containers on the fly.
• Resource Isolation: Kubernetes provides resource allocation by having hierarchical namespace structure to provide appropriate access control for the workloads. Datera is built on support for multi-tenancy making all the policies, templates and instances tenant-aware allowing for greater granular access control,consistency and resource isolation.
• On-demand Provisioning: Applications on Kubernetes can scale up really quick, using primitives such as StatefulSets, ReplicaSet. This introduces resource bindings of PVC’s , expecting the storage vendor to bind them to a matching resource .Datera uses thin-provisioned clones to achieve meeting the scaling requirements. Thus only reacting to scale up and down on dynamic demands, rather than to pre-provision the resources while fore-casting requirements.
• Keep it Stupid Simple: It is no co-incidence that the Kubernetes compute concepts naturally map into the Datera Data-fabric concepts since both were designed to dynamically grow and shrink, as application demands change over period of time. Some Key extensions of Kubernetes concepts that have organically infused into Datera’s design concepts:

Thus by creating a Just-in-Time Service defined private/hybrid cloud defined platform utilizing Kubernetes and Datera, enables application owners and storage admins to independently optimize the platforms for their needs. This helps achieve unmatched simplicity, efficiency, and business value to enterprise customers while helping reduce overall TCO.

Background reading:

• Datera CSI deployment guide
• 10 Principles for Evaluating Enterprise Storage for Kubernetes & Cloud Native Applications
• Kubernetes for Data
• Datera OpenShift 3.11 Deployment Guide

Traditional enterprise storage architecture had very limited autonomy. The autonomy on these systems was limited to providing spare drives, to automatically replace failed drives. Controller failures required manual intervention and high cost maintenance contracts to maintain storage SLO. Data migrations done to improve performance or provide resiliency were typically disruptive operations which meant a hit for application performance or data unavailability scenarios in extreme conditions.

Datera was designed with one single mantra in mind “The only Constant is Change”.

How did we design Datera to be so dynamic and adaptive? The Datera distributed control plane resolves your objectives into a set of policies that are given to a high-performance data plane as key value stores for execution of the policy. The data plane then maps key value pairs onto the current physical hardware to deliver performance, reliability and accessibility.

Software on the individual nodes, built from commodity infrastructure, utilize resources-specific capabilities depending on the type of storage, CPU, memory and networking that optimize for:

• Transformation – protection, compression, encryption, deduplication…
• Placement – NVMe, SSD, HDD, Cloud…
• Functionality – snapshot, replication, copy data management…

Datera continuously monitors how the cluster is performing relative to the specified application intent, i.e. compares admin_state and operation_state. Application requirements in the form of policies are specified by the application admin, and the control plane works to apply them constantly to a completely programmable data plane based on the availability of physical resources. A policy change to improve performance of a subset of data would involve that data migrating to a node supporting media-types to better fit the policy autonomously with absolute transparency.

The autonomous characteristics of Datera Storage systems include but are not restricted to the following underlying behavior:

• Recovery: A Datera system will autonomously recover and adjust data in a way to meet the policy intent during failure and restoration of a variety of physical and software components.
• Policy Changes: Policies can be changed on the fly and the system will autonomously adjust data placement in an entirely transparent and non-disruptive manner to configure the data plane to meet the policy intent.
• Autonomous Redistribution: Datera allows creation of application intent to be created via AppInstance, even if the capabilities are not currently available on the cluster. When resources such as new storage media, memory are added, as part of closed loop autonomous optimization, the data will be redistributed in a non-disruptive manner to meet intent. Datera allows admins to decide the end-goal and the system strives to meet the goal when resources are made available.
• Scaling: Datera automatically incorporates scale-out a storage node to the cluster, and this would involve adding network configuration and upgrading of the software version on the node to meet the cluster versioning while adding the node. Conversely Datera also allows a cluster to scale-in by decommissioning of storage nodes and data from the nodes will be migrated out and cleansed on the retired node.
• Data Placement: Datera provides an outcome based data placement mapping driven by application intent.
• Re-balance: As part of continuous optimization, as additional capacity is added to the cluster in terms of nodes or additional media-types, Datera will move data workloads over to the added capacity in-order to balance the capacity and targets across the cluster.
• Rolling-Upgrades: When a new software version is available, the cluster will autonomously deploy new software, in a non-disruptive, per node, rolling basis, including managing any networking changes to ensure continuous availability.

Datera’s forward thinking and holistic design approach is to envision these capabilities to be operating in concert to create autonomous operations. It strives to make data movement transparent to all host environments across generations of “x86” server & storage media-types, driven autonomously by “current+future” application intent state. Datera is Built For Change, and is helping the largest Global 1000 enterprises future proof and modernize their storage infrastructure.

If you would like to learn more about Datera’s flexibility and future-proofing capabilities, please read our Built For Change White Paper.

Vikram Desai heads up Datera’s Technical Program Management team, and has been with the company for nearly three years. He has been instrumental in supporting our largest OEM’s and other Partners.  Prior to Datera he worked across IaaS and Cloud Storage products at Cisco & Akamai.

An exciting day at Datera as we welcome Fujitsu, a well respected global brand, as a strategic partner to support enterprises who are rapidly adopting software-defined storage in order to achieve radically better business outcomes. As part of the relationship, Fujitsu will distribute Datera software under the Fujitsu storage brand with immediate availability in Japan and Europe. We are proud of the confidence that Fujitsu has placed in Datera’s technology, and for the technical rigor that Fujitsu has applied in evaluating our software platform.

Enterprises operating at scale have challenging decisions to make

We consistently see customers struggling to efficiently manage data at scale as they operate in a very dynamic and unpredictable environment. As data is critical to value creation and competitiveness, managing it at scale often creates complexity. Choosing the wrong technology can hinder business velocity and developer productivity, and cause missed opportunities and significant financial costs.

The world is no longer confined to just a set of well-known applications, where IT professionals could plan and select the right underlying storage technology to meet that specific set of requirements, and customers would be locked in the selected technology for several years..

The field is a lot broader and more dynamic than it was years ago. There are now more applications, more data, more diversity of requirements, and more storage media technologies available — plus IT data needs change faster than ever. And where is the best location for such data? Private, public or hybrid clouds? Yes, it is complicated!

In this paradigm, IT is challenged to make sense of all of the moving parts and serve the business with two basic goals:

1. To deliver the right data at the right time
2. Provide the data in the most cost effective and secure way all the time

Beyond CAPEX, businesses experience significant operational costs and time to evaluate, select, and manage storage products. Adding to the purchasing complexity, the actual value of the data data set changes over time. While being able to deliver data faster today, by using more expensive technology, could mean a competitive lead and/or create new revenue streams, that data may no longer need to be sitting on an expensive media class six months later.

So how can IT efficiently deal with managing 100s of TBs or PBs, operating at scale while dealing with a number of different point products, that each will lock them in for years, when their applications, requirements and the technology market are constantly evolving? This reality ultimately pushes customers to compromise, which in most cases results in higher costs.
Even though companies’ may have data with different values/requirements, that could benefit from different types of products, the trade off is always a balancing act between operational efforts and cost.. In many cases we see customers consolidating their workloads on the more expensive and performant products capable of accommodating their most demanding workloads. Others choose to optimize around elasticity and flexibility, opting for the public cloud.. Both options require compromises which end up being very expensive when operating at scale.

At Datera, our founders determined that there was a need for a completely new architectural paradigm to radically simplify the data infrastructure, and ultimately give customers unparalleled business agility, operational efficiency, and to radically lower overall costs.

How does Datera do it?

Software-defined storage solutions are dramatically different in spite of being categorized under the same product class. First generation software-defined storage aimed at delivering storage arrays with software running on servers. The concept provided some flexibility and cost savings. However, the performance was often short of expectations, and in most cases the solutions did not address the managerial shortcomings and rigidity of traditional storage products. As a result many first generation SDS solutions were deployed for Tier 2+ use cases.

Datera took a broader approach to the problem to deliver on customers’ expectations.
In the Datera paradigm, the storage infrastructure — composed of servers from multiple vendors with different classes of media that can all co-exist together — becomes invisible!
Everything is automated and orchestrated via APIs to eliminate all of the efforts associated with planning, selecting, deploying and managing storage. A key value in a Datera managerial platform is that customers can direct applications via policies to selected media classes to meet specific SLAs.

Imagine an application that is running on SATA flash, and the customer determined it would benefit from running on a NVMe or even Intel Optane flash technology to get better response times. All that a customer needs to do is to add a couple servers with the desired media to a running cluster, change one policy and data will start migrating live to the new nodes and customers will start seeing immediate performance improvements! If after a while, the customer determines looking at the insights, that the application would benefit to sit on lower cost media again, a simple policy change will move it back! Everything just happens live through advanced automation!

So effortlessly achieving the ability to deliver the right data at the right time at the right cost all the time, can really be possible!

The end result is unparalleled business agility, operational efficiency, and radically lower overall costs. The data infrastructure can now meaningfully raise the bar in supporting IT as a competitive advantage.

In summary, the Datera software defined block and object storage platform is:

• as easy, self service and elastic as the public cloud;
• as performant and feature-rich as enterprise class arrays;
• capable of handling multiple classes of servers and media technology in the same architecture, all orchestrated by policies to meet application intent with live migration between tiers;
• future proof for adopting any new media technology on the fly;
• everything fully AUTOMATED via APIs;
• and foundational for a robust, hybrid cloud world.

Bottom line

Markets, technologies, and requirements evolve. As software is now capable of delivering very high levels of performance, the battleground shifts to automation.

We are seeing software defined continue to mature rapidly, and it poised to become one of those major architectural paradigm shifts that created a lot of value for Enterprises. Similar transformational examples include the transition from mainframes to distributed servers, or from physical to virtualized environments, on prem to hybrid clouds, or even from traditional cell phones to smartphones. During these transitions, there were detractors and naysayers that believed that the status quo would have won in the end. In most cases the world moved on and as long as there was significant new value, customers helped lead that transition as they realized that status quo was not a viable winning strategy. This is one of those times.

At Datera our focus is on delivering the most performant, reliable and automated software-defined architecture for the hybrid cloud data center, eliminating all the complexities of managing storage and enabling customers with the most agile data infrastructure possible. And taking our technology to enterprises via some of the most recognized and trusted brands in the industry.

It’s been three years since I worked up a software-defined comparison between Red Hat Ceph and Datera, which you can see here for reference. That’s 30 years in technology time (one year of human life equals 10 in technology evolution), so it’s more than time for an update. And, as you’d expect, a sea change has occurred during that period not only for each storage offering, but also in the preeminence of containers and Kubernetes as a foundation of future applications.

Setting the Scene

The use of software-defined technologies in storage and other layers of the IT stack has gone mainstream, whereas just over our shoulder it was still a niche, early adopter market. Recently, we profiled just how far software-defined technologies in the data plane have come, outgrowing classical hardware-defined arrays by 5X.

Red Hat is also a different entity altogether, now part of IBM with a heightened ability to reach Big Blue customers and beyond. Both Red Hat and Datera continue to see significantly more customer adoption on the back of powerful new feature development powering performance and usability improvements. Datera has experienced increased adoption in the Global 1000 enterprise space, supporting transactional IO use cases like MySQL databases while Ceph is mainly deployed at service providers and in developer heavy environments.

In the meantime, containers have emerged as the central technology of the future, with now half of the Fortune 100 reporting they have rolled out Kubernetes in production. Red Hat has made a big investment in Kubernetes with its OpenShift platform, and similarly Datera has cemented its support for a variety of container orchestrators including OpenShift.

Technology Strides

Ceph has made strides and has IBM’s support, which is good news for the software-defined storage market, particularly in the following areas: 

Ease of Rollout, Use and Reporting

Ceph has always been viewed as a powerful engine for the right kind of use cases, but considered to be a bit of a mixed bag on the ease of rollout and ease of use fronts. But our friends at Red Hat have taken many steps to emulate other SDS technologies like VMware vSAN and Datera that excel here. A case in point is Ceph’s Admin dashboard, which provides a graphic view of the overall cluster.

Hyperscale

While making our platform easier to implement and improving our real-time analytics using telemetry data from every node remain fixtures on our engineering agenda, our focus in 2019 focused squarely on scaling our deployments and adding a slate of new media and server vendor options to reduce latency even further. On the hardware side, we have improved reporting across all our major supported server platforms including HPE, Fujitsu, Dell, Supermicro, Quanta, and Intel. We also added more predictive features around latency reporting and capacity projections. We are also tracking our customer’s production deployments and are happy to see 70%+ of all write IOs are serviced under 131 µs.

Our Fortune 1000 customers have challenged us to scale to entirely new levels, since our customers typically start with a petabyte of capacity and add from there. To this end, we put ease of rollout on display in multiple forms which are best left to the eye to view rather than discussed:

Demo: 20 Datera Nodes Up and Initialized in 4 Minutes

But getting nodes up and running is useless if the volumes aren’t set to deliver the right capabilities to individual applications or tenants. To this end, our engineering team has made doing this equally easy, which we refer to as developing a storage class—gold, platinum, silver or whatever precious metal or naming convention you prefer.

Datera Demo: 5 Storage Classes in 5 Minutes

Datera has continued to refine and extend our policy approach to management adding node labels and allowing users to craft granular control over volume placement throughout the system:

Kubernetes, OpenShift and Container Acceleration

Big Blue and Datera also share a commitment to supporting containers and container orchestrators. Red Hat has made a big bet on OpenShift and similarly, Datera has made optimizing Kubernetes & OpenShift core in its technology strategy, again better seen than yapped about:

Demo: Persistent Volume Claims and Datera PV Integration

On The Block: Ceph Bluestore and Datera’s Extent Store

Bluestore was released in 2017 and as an alternative to using traditional POSIX file systems (filestore) to manage data on each disk. Using existing file systems provides robust data integrity and block management but comes at a great cost to performance and latency as a block storage backend. Bluestore adds a method of managing the block metadata on the disk. To improve performance, metadata can be placed on separate media, which is a common technique for traditional file systems as well. In Bluestore’s case, it can be placed on an NVDIMM type device or Intel’s new Optane DIMM technology.

The diagram below shows a block diagram of how data, and metadata, flow with the Filestore backend and with the Bluestore backend:

In our case, our founding architects recognized from day 1 that to achieve ultra-low latency, they needed to build a system that did not rely on existing POSIX file system technologies. To this end, the Datera Extent Store is built using log structure techniques to increase performance and reduce wear on flash media. Log structure commits large blocks of data to media at a time, which we refer to as buckets, which can house either the data itself or simply the metadata. These buckets have different behaviors based on the type so that the storage can be further optimized.

Final Thoughts

Ceph has come quite some way in the last 30 technology years, offering a massive number of features and capabilities which regrettably come at a cost exacted in system complexity. Administrators need to thoroughly understand the deployment and operation of these features and the impact on the rest of the system, as well as keeping watch for those which may not yet be production-ready.

As for Datera, we remain focused first and foremost on block software defined storage enterprise-class deployments built and fully tested with industry software and hardware partners. Our goal is to help organizations make the inevitable move to a software-centric approach and remove reliance on aging legacy SAN and FC environments where they see fit.

Red Hat and Datera share a commitment to a software-centric vision for the enterprise data center built on containers. While we offer two different paths, the destination is the same. I like to think of Ceph as an Orange and Datera as an Apple: if you are famished, you can bite into an unwrapped Orange and get nourishment, but you will not enjoy the taste if you do not take the time to carefully peel and prep it; with an Apple, it’s ready to go as soon as you pick it up.

Who, When, How, Why and What’s Coming in 2020

Geekonomics? Yes, we pay homage again to Freakonomics, the National Public Radio Podcast series that reveals the hidden side of everything, applying economic theory and exposing often hidden data to reveal the underlying truth. In Geekonomics, we take the same approach to all things IT to see what is really happening. Let’s do the math.

Our focus in this installment is: “What in the ‘Sam Hell’ happened to storage in 2019?” We piece together a number of the year’s headlines and key developments, how they fit together into an interesting puzzle, and unveil the missing pieces.

January: Datera & Hewlett Packard Enterprise Accelerate Enterprise Transition to Software-Defined Storage

HPE, the #2 player in classical storage arrays, tapped Datera in early 2019 to round out its tier 1 block storage portfolio with the Datera enterprise software-defined storage software platform running HPE ProLiant servers, complementing its line of Mellanox 100 GbE switches. A year later in early 2020, eWeek credited Datera for filling a critical hole for HPE and credited HPE for having some foresight. Something must be afoot…

February: IDC Signaled Increased Services, Pullback From Public Clouds

IDC announced that the massive rush to the public cloud had reversed to a massive repatriation, stating that 80% of enterprises have initiated efforts to repatriate 50% of their applications and workloads due to lack of performance, security, and ultimately the high price of public cloud services from the leaders like AWS and Azure.

IDC further clarified that a majority, or 56%, of data would live over the long haul in on-premises data centers, with the remainder tucked away in public clouds, giving new life to the corporate data center which had been left for dead by most industry commentators.

April: Google Cloud Introduced the Anthos Platform for Multicloud Apps.

Alphabet, the parent company of Google, launched Anthos, its new platform for “write once, run anywhere” applications on-premises and in multiple public clouds, brought on Thomas Kurian from Oracle to get GCP ready for battle in the enterprise, and bought a handful of companies to expand services and capabilities. My colleagues at Google Cloud tell me every employee there knows the cloud game is on, that Google is behind, and is sprinting to catch up.

June & November: Datera Assembles Software-Defined Data Center Leadership Forum and Virtual Symposium

Lead, Follow or Get Out Of The Way. Datera assembled a coalition of leaders in data center infrastructure to drive the industry to the next major wave of adoption, bringing together Scality, WEKA.io, Intel, Hewlett Packard Enterprise, Mellanox and Cumulus to talk requirements, lessons learned, and the criticality of partnership amongst vendors to power the future software-defined enterprise clouds with Mark Peters, longtime industry analyst from Enterprise Strategy Group. Datera livestreamed two virtual tradeshows in a pre-COVID-19 world — the first from HPE Discover, its worldwide customer event, from Las Vegas in June and the second from the Silicon Valley Convention Center in November, to worldwide audiences. (Pardon the interruption, but let me quickly tip my hat to the Datera team that made this happen: well done Eric, Tom, Brett, Dominika, Laura and crew.)

December: Amazon Web Services Announced The Availability of AWS Outposts for On-Premises Hardware Systems.

Amazon made its long-awaited AWS Outposts, an on-premises proprietary compute and storage hardware platform compatible only with AWS cloud services, available and ready to address, as a last resort, the 56% of data not moving to the public cloud. Long live the enterprise data center.

Exiting 2019: Fastest Growing Storage Companies in 2019…Were Software Companies

17 of the 20 fastest growing storage concerns across the landscape in 2019 were software companies. That’s right, software companies. SDS platforms like WekaIO for HPC file use cases and Datera for Tier 1 block led the way while others bit off important albeit important challenges like data protection, file virtualization and multi-cloud access. Marc Andressen, early Internet innovator and VC behind some of the largest and most successful technology startups of the last two decades, said in 2011 that “software is eating the world” and this statement has now clearly touched down in the enterprise storage business. Of the major array players only Pure Storage, with its lead in all-flash arrays, was able to claim a spot on the list. It makes sense given that powerful flash and NVMe drives have hit a production volume that has reduced unit costs to a virtual stalemate with spinning disk drives, making better performance and reliability available in a server package priced at a fraction of the total cost and flash markup charged for classical arrays.

Entering 2020: Software-Defined Storage Market Will Become 3X the Array Market

Industry analyst Dennis Hahn, longtime industry player, launched his inaugural market projection for software-defined storage, projecting an $86B market by 2023 on the back of 28% annual growth. His effort wisely combined the move to hyperconverged infrastructure (HCI), which incorporates a storage layer in the hash, and standalone software-defined storage systems, like Datera, into a single projection, since both are key alternatives to classical storage arrays and deliver a public-cloud like experience on-premises.

Entering 2020: Worldwide Enterprise Storage Systems Market Revenue Down 5.5% to $28.6

Within a week of projected solid growth for software-defined, Eric Burgener and his team over at IDC lowered their original gloomy forecast for classical hardware storage systems from a 1.3% uptick to a decline of 5.5% for 2020, with that trend continuing for the foreseeable future, all against a backdrop of 50%+ growth in data. While many key hardware players struggled with their revenue numbers at the end of 2019, Pure Storage and Huawei stood out for their positive momentum, yet their results couldn’t and won’t reverse the slide at the category level.

So Where Does That Leave Us?

2019 exposed every key macro trend in enterprise storage—software is growing, hardware is slowing, all-flash environments are showing and cloud services are on-going. On the surface, this doesn’t look that complicated, but not many predicted it and stood by it. Geekonomics gives a hearty salute to David Floyer of Wikibon, who five years ago predicted the bifurcation between software and hardware based approaches. He termed the software approach “Server SANs,” a superior term for using software to turn servers into storage area networks — now standalone storage as well as even HCI — and the tapering of hardware-centric storage.

No one is predicting the imminent expiry of any storage category, since my experience over two decades and in particular the last several years in the industry tells me that large organizations from the Fortune 1000 to public and educational institutions will put all of them to use. And let’s not forget that data is growing 61% per year and it’s going to need to go somewhere. But the growth numbers clearly tell us who has the best outlook as we move forward.

So What’s Next?

Andressen’s well-argued thesis is that digital disruption has come or is coming to every industry, from mainstream industries like retail, entertainment and transportation that were offline to now, ironically, even digital storage, an industry that has been online from the onset. Software is simple eating this world too, with the only questions being how fast and by whom. 2020 will be THE seminal year in answering them.

Sources

• Datera Joins HPE Complete to Accelerate Enterprise Transition to Software-Defined Storage
• DC: Increased Services, Pullback From Public Clouds Huge IT Disrupters
• WW Enterprise Storage Systems Market Revenue Down 5.5% to $28.7 billion in 2020
• Why Software Is Eating The World
• AWS Outposts Now Available – Order Yours Today!
• Introducing Anthos: An entirely new platform for managing applications in today’s multi-cloud world
• Server SAN Projections 2016-2026

Hint: Container Storage Interface (CSI) Plug-In doesn’t mean Container Storage-Optimized.

Straight out of DevOps land comes this missive: 90% of the Fortune 1000 are using containers in production, restructuring their architectures to meet the challenges of the next decade, and migrating their applications from virtual and traditional infrastructure to container solutions and Kubernetes (known industry-wide as K8s). It’s going to be an interesting ride fraught with a huge level of misinformation as systems vendors slap a “K8s Ready” label on top of their preexisting products up and down the stack. While the introduction of K8s may not be too challenging at the compute layer, it will offer new complexity to the networking and storage layers which requires a new level of scrutiny on how containers are supported.

To help separate the signal from the noise, we’ve compiled ten key principles for evaluating on-premises, persistent storage platforms to support cloud native applications as you and your organization head down the inevitable path toward a container-centric future.

The Benefits and Challenges of Containers and Kubernetes

We hear a lot about containers and K8s today in conversations with our customers and partners and their desire to achieve the automation, composability, velocity, scalability and efficiency benefits they’ve seen in initial.

Given these potential benefits, it’s obvious why large enterprises, laden with hundreds of applications, are moving aggressively to containers. But selecting the right storage, often the last layer of the stack to move, is essential to realizing them, because hyperscale cloud native applications require persistent storage platforms with very unique characteristics.

As you embark on your journey, you will find systems providers touting their Container Storage Interface (CSI) which marks the most basic form of interoperability. But the storage layer needs more than just interoperability; it should match the dynamism of new applications based on containers and Kubernetes. Here we offer a framework for evaluating storage for cloud native applications that goes beyond buzzwords and is designed to help you get the right storage capabilities to achieve container and cloud native success.

10 Principles for Evaluating Enterprise Cloud Native Storage

1. Application Centric
The storage should be presented to and consumed by the application, not by hypervisors, operating systems or other proxies that complicate and compromise system operation. Your storage system is likely based upon older abstractions of storage such as LUNs, volumes or pools. These once were workable for monolithic applications such as Oracle and SQL databases running on physical servers, but modern storage systems now use an “appinstance” or “storage instance” construct that lets you apply templates programmatically, enabling your container workloads to rapidly consume and release resources as needs ebb and flow. For example, your DevOps team may spin up 100 Kubernetes or Docker containers a day, requiring a stateful, persistent appinstance for just that day and release it after an hour or two. This ensures your application gets what it needs and only when it needs it.

2. Platform Agnostic
The storage should be able to run anywhere in any location, with non-disruptive updates and expansions non-disruptive. While legacy arrays have proved reliable for blinding speed on monolithic applications, tuning them introduces many restrictions, compromises in your usage models and often requires a fleet of highly individualized administrators. Modern, cloud native workloads require a composable platform that can run in racks, aisles and multiple datacenters as YOUR needs grow, without requiring rebuilds and migrations to slow you and your users down. More importantly, in multi-node, scale-out systems, all upgrades MUST be rolling, non-disruptive and minimally impact performance. Look for systems that use standard iSCSI and Ethernet for maximum flexibility as your needs grow to include multiple datacenters, stretch clusters, and other disaster recovery implementations.

3. Declarative and Composable
Storage resources should be declared and composed as required by the applications and services themselves, matching the compute and network layers. Policy-driven systems allow you to make changes to the underlying resources seamlessly from the container perspective. For example, set a policy that includes dedupe, performance and encryption and as you add or remove nodes, the system should autonomously move and re-balance workloads across heterogeneous nodes that comprise the cluster. The system should automatically inventory resources and make split second decisions about the most efficient way to run your containers.

One additional tip is to ensure that these policies are changeable over time. As basic as it may sound, many systems based on policies give the illusion that they are dynamic, but in practice are static. Test the ability to change policies and have those changes ripple through the data so that your storage is as dynamic as possible.

4. Programmable & API Driven
Storage resources must be able to be provisioned, consumed, moved, and managed by API. Even better, these actions should be done autonomously by the system in response to application instantiation, which is at the heart of an infrastructure designed for self-service. Without this capability developers will not be able to generate their own storage when they want it, which becomes a bottleneck in the development process and requires the very thing that containers are designed to eliminate: manual intervention. In practice, programmability allows you to query the storage system to assign and reclaim persistent volumes on an as needed basis.

5. Natively Secure
The security of the storage should be endemic to the system. Storage must fit into the overarching security framework and provide inline and post-process encryption as well as Role Based Access Control. Bolting on security capabilities should be avoided since it often requires extra overhead and impacts storage performance. Your system should be able to programmatically encrypt at the container level and do so programmatically as well as utilized data at rest encryption capabilities to minimize any performance impacts.

6. Designed for Agility
The fundamental goal of a Kubernetes implementation is agility for DevOps and for the application overall. The storage platform should be dynamic in terms of capacity, location, and all other key storage parameters including system performance, availability (controlled via the number of replicas desired), and durability. The platform itself should be able to move the location of the data, dynamically resize, and take snapshots of volumes. Further, it should be easily tunable and customizable for each application or tenant via policy, using policies to create storage classes. The most powerful systems react dynamically when system resources are increased and during datacenter outages, when workloads may need to be shifted to other failure domains.

7. Designed for Performance
The storage platform should offer deterministic performance by application and by tenant to support a range of requirements across a complex topology of distributed environments. Performance is comprised of the IOPs thresholds, media type (flash, NVMe, Optane), data efficiency desires (compression, dedupe) and the dynamic reaction to changes in workload demand or cluster resources. In less dynamic applications, administrators could often set a single service level objective (SLO) and check in on the achievement of those targets intermittently. But in today’s environment, the system itself must “check in” on the achievement of SLOs constantly and react in real-time to orchestrate the changes needed to achieve them.

8. Continuous Availability
The storage platform should ensure and provide high availability, durability and consistency even as application needs change and the environment scales. For example, modern storage systems are leaving RAID behind and moving to shared-nothing designs where data replicas are dispersed to different storage nodes situated across failure domains or metro-geographies, all to maximize availability. This is the new way to drive availability levels at a lower cost.
Having fine-grained, programmatic control over availability levels by workload is essential since a fraction of your applications and data will inevitably be more important than others. Most enterprises will experience wide variances in data availability. While some applications may generate just three replicas for apps and data of lesser import—housing some fraction on the lowest cost media, while others use five replicas for the most important instances stretched across three data centers with an aggressive snapshot schedule. Having options beyond the standard and fixed RAID schemes is often deemed essential for cloud native environments, which is consistent with the architecture of most cloud service providers.

9. Support More than Cloud Native Applications
This is not a typo. The move to containers and cloud native application design is a generational shift, and as such will take many large organizations a generation to complete it. Embracing a storage system that supports more than containers is critical to avoiding the creation of yet another data silo. As you evaluate a new storage platform for cloud native workloads, you should similarly ensure that it serves virtualized and bare metal applications to ensure the freedom of data usage for applications as they transition. In other words, while your organization may be racing toward the future, your system also needs to enable the past without losing a step. The storage platform should serve Kubernetes, Docker, VMware and bare metal workloads.

10. Operate Like Kubernetes Itself — the Modern Way
Carving out traditional LUNs is a tried and true method for providing storage resources to traditional applications. But by embracing storage built on policies that are declarative and built with composability in mind, enterprises can mirror the dynamism of a cloud native compute environment. Storage needn’t be static — DevOps teams should be able to spin up new instances and make new replicas to serve the application as traffic grows.

Conclusion

These 10 principles will help ensure that you make the right choice for modernizing your on-premises storage infrastructure to accommodate containers.

At Datera, we designed our cloud data management platform to utilize commodity servers, allowing you to build an enterprise-grade storage environment with these principles in mind, yielding a system that is:

• Built for Hyperscale: Scale up, scale-out, and scale across the data center on commodity servers. Legacy systems often force organizations to be predictive in storage planning, which often restricts growth. With our approach, organizations start with a set of nodes and, as new nodes are added, performance, capacity and availability grow. At these moments, the system re-inventories itself and autonomously applies the extra performance against workload policies already in place. This yields a horizontally scaling, built for hyperscale environment.
• Built for Autonomous Operations: Using policies to drive the storage requirements minimizes operator overhead and ensures that those requirements can systematically and programmatically adapt as application or tenant needs change and environments scale. These policies are built for change, so that all changes apply retroactively to the data written earlier to the system.
• Built for Constant Change: Datera serves bare metal, hypervisors, and container deployments on a single platform, helping enterprises avoid another island of data in their data operations as they migrate workloads over time.
• Built for Continuous Availability: Datera’s shared nothing architecture eliminates single point of failure challenges, and overcomes multiple component failures and multiple node failures without loss of data or performance. The platform uses telemetry from all nodes to constantly monitor the system, ensuring availability and other parameters in the SLO manifest.
• Built for Tier 1 Performance With Services: Even when enabling dedupe, compression and encryption, Datera supplies sub 200 microseconds latency and can scale to millions of IOPs, which grow as nodes are added to the cluster. Further, Datera can provide this class of performance with essential data services like deduplication and encryption enabled with minimal performance impact.

Lastly, Datera operates like Kubernetes itself, letting you rapidly deploy persistent volume claims to support an application’s distinct requirements and take the appropriate action (e.g., add capacity, add high performance media, make a replica) to meet them. Datera autonomously supports container changes over time, spinning up new services, new tenants, or even recapturing resources automatically as you spin down Kubernetes instances.

Modern workloads may not require a modern approach, but enterprises can gain from new thinking and new capabilities that Datera’s software-driven approach delivers.

About the Author

Brett Schechter is the Sr. Director of Technical Marketing at Datera. He has spent time with many of the most innovative storage vendors of the past decade, as well as running product management for Rackspace storage, where he set the requirements for the first managed public/hybrid cloud storage products on the market. In his current role, he is responsible for collaborating with enterprises on their system requirements and test plans.

When I first saw Scott Sinclair’s recent ESG research indicating that 72% of large enterprises are committed to software-defined storage for their data infrastructure of the future, I thought he had to have transposed the digits: 72% is a big number; the array vendors are, in a word, entrenched, and corporate IT is already fighting multiple wars simultaneously on the security, application transition to containers, and cloud rightsizing fronts.

So with the CIO agenda for 2020 full and then some, why and when are they moving to a software-defined storage future? Scott found that 55% of enterprises have software-defined storage deployed in some capacity now, with a higher percentage indicating they plan to expand and deepen their usage of SDS in 2020. Part of this expansion hinges on adopting a multi-vendor strategy as they’ve done in all other critical parts of operations, from hardware vendors to public cloud vendors.

Our conversations with Fortune 1000 enterprises over the last two years are very consistent with Scott’s findings and reveal the main factors behind the shift to software-defined:

1. INCREASE PERFORMANCE. Software-defined systems are taking advantage of the move to 100Gb+ Ethernet and NVMe drives; throughput and latency problems are solved problems for the data center, but performance can be crippled when essential services like deduplication, compression and encryption are on. One Datera customer boasts that he cut latency by 90% over prior storage arrays by standardizing on SATA Flash and NVMe drives.

2. SIMPLIFY THROUGH AUTOMATION. Aggregating application and tenants into an enterprise cloud and increasing velocity via self-service utilization for application owners requires automation. Policy-based administration and management by application intent—where policies set thresholds like the IOPS needed for an application and the software utilizes the right resources to meet that threshold—eliminate the manual tuning required by legacy approaches, and dramatically simplify the overall environment. Automation is no longer a nice to have, but essential for operating at scale.

3. FLEXIBILITY AND CHOICE IN HARDWARE SELECTION. CIOs overwhelmingly want the ability to choose the hardware they require at the right time from a menu of choices. All too often, storage systems have limited choice to only certain types of media and to the same generation of hardware system, making system design inflexible. But SDS systems like Datera are designed to rapidly incorporate the latest new technologies and enable a broad selection of media types (NVMe, SATA Flash, HDD) as the system expands and of server hardware from a pool of vendors including DellEMC PowerEdge and HPE ProLiant spanning multiple generations, enabling choice that helps overcome the supply chain challenges the industry is currently experiencing and provide leverage to negotiate for procurement to get better pricing and delivery times.

4. SCALE FOR TODAY AND TOMORROW: Enterprises are universal in their desire to scale their systems just-in-time when they need new capacity and capabilities, and to do so granularly (node by node) from a few hundred terabytes to a hyperscale threshold of multiple petabytes. Well architectured systems not only can meet scale requirements but can utilize new capacity to expand performance, durability, and resilience as the environment grows. Datera has worked with several CIOs that embraced hyperconverged infrastructure (HCI) like VMware vSAN and Nutanix to serve a need quickly, but experienced an inability to scale beyond 10 to 20 nodes and achieve acceptable performance, which led them to Datera.

5. REDUCE OPERATING EXPENSES WITH SELF-HEALING SYSTEMS. Combining a distributed data management approach with advanced telemetry to monitor the health of each hardware node and rebalance when appropriate offers the potential to help all users with practical capacity/performance planning and best practices in real-time. One of our customers has, in his words, “eliminated hardware maintenance” by simply swapping in new hardware nodes when an individual server fails rather than take systems offline and deploy specialists to revive the faulty array. With Datera, decommissioning a node and bringing on a new node can be achieved without downtime and in a matter of minutes. And the system, rather than the administrator, rebalances the environment to re-incorporate that node and deploy the right data to it to utilize the media type.

6. INCREASE DATA AVAILABILITY. For Fortune 1000 enterprises, data availability remains paramount in system design. Properly designed software-defined systems shun typical RAID schemes and deliver availability by distributing copies of data across nodes, racks, aisles, and data centers with close attention to fault zones. This enables a higher level of availability than traditional systems. At Datera, each node gets “over-the-air” updates so there is no need to take a system offline to upgrade it, eliminating the biggest downtime culprit—planned downtime.

7. OPTIMIZE FOR CONTAINERS AND KUBERNETES. 90% of enterprises are using containers in production now, revealing cracks in the infrastructure’s ability to keep pace with the transitory nature of the applications. CIOs are actively looking for storage systems optimized for containers providers and tools like Docker, Kubernetes, and Red Hat Openshift. SDS systems can be a good choice when they can autonomous operations and optimize data placement to match the agility afforded with container deployments.

8. MINIMIZE LOCK-IN. The infrastructure industry is notorious for vendors locking customers into an inflexible architecture and an artificially limited set of hardware choices designed around their economics rather than yours. To avoid lock-in, software-defined approaches should support a wide variety of hardware profiles—different server vendors, different server models, different server generations, and a variety of different media—to keep their choice and negotiating power as high as possible. While many SDS systems are simply packaged appliances with narrow options, Datera offers a number of qualified servers from the top server manufacturers, including Dell EMC PowerEdge, HPE ProLiant DL360s and DL380s, Fujitsu Primergy MX2540s and Cisco UCS C240s.

9. REDUCE TECHNICAL DEBT. Enterprise CIOs can significantly reduce technical debt in networking and storage through SDS. Reducing technical debt is often less about total spend than it is about replacing monolithic systems with more fluid and customizable systems that change the paradigm of arrays in two ways—excessive markup and forklift upgrades. First, the raw expense of fibre channel networking and the markup vendors are exacting for all-flash and all-NVMe systems have reached a new peak, but Datera harnesses commodity servers and eliminates the three-year refresh cycle which reduces capital expense upfront and as time goes on. Datera environments are “evergreen,” meaning they are continuously refreshed without downtime.

2020 AND BEYOND

Software-defined storage for enterprise clouds crossed the chasm from early majority to late majority in 2019. As we move to 2020, the Fortune 1000 are engaging multiple software-defined vendors and moving up to SDS from HCI implementations using VMware vSAN and Nutanix that were never meant for enterprise rollouts. Scott summed it up that ESG’s “market research shows that a majority of enterprises are adopting software-defined storage technologies as part of their data strategy and Datera is emerging as one of the central players for mission-critical applications.”

Get a Consultation

Discover the advantages of enterprise software-defined storage with advanced automation: Contact us to schedule a free consultation.

Fortune 1000 companies can use this document to generate a comprehensive Request For Information and a focused and efficient Proof of Concept to test for current and future storage needs. 

Transition was everywhere in 2019. Enterprises that had rushed to get to the public cloud started bringing applications back. They also began to deploy Tier 1 workloads with software-defined technologies instead of storage arrays. Change was the only constant as it related to the storage deployments of the Fortune 1000.

While change was in the data center air, the key requirements for the next-generation of storage infrastructure became very clear. Datera is comprised of the world’s leading SDS architects and former end users, and we have worked with scores of Fortune 1000 companies to understand their data storage needs. 

While we recognize that every organization’s applications and needs are different, from this unique vantage point we developed a set of common requirements and best practices to help you and your organization get a fast start on the path to a new and better data infrastructure. 

Storage Categories and Goals the Fortune 1000 are Evaluating

When getting started we recommend first investigating the four main categories of storage technology that drive different sets of requirements.

1. Enterprise-Class Flash Arrays. Arrays from the leading vendors are strewn all over the floor, whether deployed on a standalone basis or more recently as converged appliances. Enterprises want to retain the pros of arrays—the performance levels, the 9s of availability, while distancing themselves from the cons—the high cost, the inflexibility, the lock-in, the homogeneity of media choices, and even the need for Fibre Channel to achieve performance and stability.
2. Public Cloud Services. The impact of the public cloud cannot be overstated. AWS, Google Cloud and Microsoft Azure—none of which use arrays to build their hyperscale data centers—showed the market that infrastructure could be done in a new, more agile, and more cost-effective way. Similarly, enterprises looked to see if they too could build their infrastructure in this manner to achieve the same level of operational agility and velocity and to do it on Ethernet rather than Fibre like the cloud players do, but they also wanted to avoid the massive cost of inflation they have experienced in their monthly bills, often 5X higher than on-premises infrastructure.
3. Hyperconverged Infrastructure (HCI). HCI growth remains strong, particularly in emerging regions. It provides an easy on-ramp to a shared infrastructure and software-defined approach, but shows inherent system limitations in scale, performance, and hardware utilization. Enterprises would like to retain the simple deployment and procurement models that HCI software vendors provide, but to do so without the common problems that have plagued the leading HCI platforms such as “noisy neighbor” syndrome where certain applications or tenants overtax the infrastructure and compromise other applications, and the inability to scale beyond monolithic orchestration within a single cluster.
4. Software-Defined Storage (SDS). SDS is seen as combining the best attributes of the other storage choices—the dedicated performance of arrays, the agility of the public cloud, and the potential to consolidate applications and tenants of HCI—with the additional benefits of automation, while lessening the vendor lock-in that has pervaded the industry since its inception. While its benefits have long been evident, it’s important to test multiple vendors against one another to understand differences in performance and availability with data management services turned on (e.g. encryption, compression, deduplication). Equally important is a test of the reliability of automation to drive quality of service and to quantify its value in understanding admin resourcing.

The Fortune 1000 test new storage approaches to maintain and expand the benefits they’ve seen in the past while finding new ways to eliminate old headaches and reduce the cost profile. 

Fortune 1000 Requirements for High-Performance Block Workloads at Hyperscale

In this section, we include a list of core requirements the Fortune 1000 should test against to understand which storage category can deliver. You may further refine based on your particular use cases. 

1. LATENCY: The system must provide 1M or more IOPS with under 1-millisecond latencies. Storage needs can change at a moment’s notice, so it is essential that a system can expand rapidly to achieve performance and capacity requirements. SQL and NoSQL databases require high IOPS and low latency storage systems that can scale performance and capacity with ease. Testing 1 Million IOPS under 1 millisecond is a common threshold, so we’d suggest you start there and add more if your specific workloads require it. Also, test the ability to expand this with the fully supported addition of asymmetric media nodes, including NVMe and Storage Class Memory (SCM) such as Intel Optane.
2. THROUGHPUT: The system must support a minimum of 64 GB/s of overall throughput. Throughput has become more important for most organizations than raw storage performance since throughput is the ultimate measure of application (rather than storage) performance and highly valuable in multi-tenant environments. The combination of database and other workloads may push the network’s overall performance as well, which can require the network and storage teams to agree on the testing. This has proven to be valuable in enabling a move to 100GbE and 200GbE networks (similar to the public cloud providers) and can yield massive savings in administration time and costs when compared with complex Fibre Channel networks.
3. ASYMMETRIC SCALING: The system must be able to scale granularly (node by node) to a hyper-scale threshold of multiple petabytes, yielding additional granular capacity, performance, durability, and resilience with each additional node. The system must be able to scale asymmetrically and rapidly—typically from a few hundred terabytes to multiple petabytes—and to do so non-disruptively without downtime. The test should include adding different kinds of nodes along the way to demonstrate that the environment not only incorporates the new capacity and horsepower, but rebalances the system without the need for manual tuning. Scaling the environment should not drive significant new admin time because the savings achieved on the capital side could be offset by extra costs in personnel. Pay close attention here, since many enterprises see massive differences in scaling between systems. At a minimum, test the ability to scale up within a rack and scale-out across racks and across aisles within a single data center, since this is what scale-out architectures must achieve to provide the flexibility enterprises seek.  
4. PERFORMANCE WITH DATA MANAGEMENT SERVICES ENABLED. System should show minimal performance degradation even when more than 60% utilized. Vendors have a habit of painting a very rosy picture of theoretical performance, which is often measured without using features that utilize CPU cycles in storage hardware. Enterprises often see a massive dropoff in system-wide performance in the systems they test when even basic data management services were utilized—including compression, encryption, snapshots and deduplication—that render those systems a non-starter. Be sure to test the systems under loads when application traffic is high to understand how the system would respond. The tests should incorporate both elements—data management off and on, traffic high and low—to give the best picture of real-world performance. Architects testing the system should also record a time sequence of the monitoring tools to show the ebbs and flows of the system over time and how it responds. To not do so would invite trouble in an actual deployment.
5. CONTINUOUS DATA AVAILABILITY. The system must be architected to be available and survive multi-node, multi-rack failures within the data center. More than just data durability or uptime, a system must offer non-disruptive software updates, survive multiple component failures, power outages, rack failures, and unexpected data center events. A real test of availability is possible using a combination of snapshots (replicated locally and remotely to a public cloud), stretch clusters, failure domains, and replica count. All vendors frequently speak about “9s” of availability, but planned downtime is frequently not used in those calculations. The test should incorporate the ability to maintain complete availability while simultaneously making changes to QoS policies, as well as adding new nodes.
6. CLOUD OPERATIONS. The system must support application and tenant aggregation and consolidation with simple provisioning and self-service utilization for application owners. The term “cloud” entails a variety of different needs for the Fortune 1000, and with much less consistency than service providers or software-as-a-service companies. But the common thread is a need to support multiple orchestrators including VMware, Kubernetes, Openstack, and bare metal in order to support a variety of applications and the velocity of stateful and stateless events. It is essential to test these not merely in isolation with a separate cluster for each, but in a common cluster for all. Otherwise, you may run the risk of bringing on a new system that becomes an island on its own with stranded data and hardware accompanied by administrative overhead. Further, we highly recommend that the test include the use of policy-based administration that can allow administrators to set up and administer groups of applications as a class rather than on an individual basis. Testing the ability to support multiple application orchestration is simply a baseline requirement.
7. AUTONOMOUS DATA PLACEMENT. The system must autonomously assign and re-assign workloads to the proper node according to preset requirements. Whether based on application traffic (to move the data as close to the application as possible) and on the storage media resident on the node (for instance, putting the right data on an NVMe drive), the system should automatically self-optimize system-wide performance and availability. Initial testing should include evaluating systems for their ability to place that data based on policy, and advanced tests should examine the quality of service delivered by workload to understand whether the system is delivering proper placement and whether the policy is aligned properly to the SLA required.
8. NEW TECHNOLOGY INCORPORATION. New technologies, at both the server (CPU) and media level, must be able to be rapidly deployed and utilized by the system without adding administration time to put them to use. To test this capability, enterprises start with a variety of server types and media types and then add new and different nodes during the life of the test. Similar to the testing of autonomous data placement, as new nodes are incorporated administrators should determine if data is indeed moved automatically to the new node and specifically what data is moved to utilize the new CPU and media available. Growing an environment can be easy, but if the system does not automatically take advantage of the new capacity and horsepower, that growth generates needless expense.
9. ETHERNET ENABLED BGP PEERING: The system should have the ability to use standard iSCSI deployed over L3 networking at the core for data operations. The test should include a demonstration of BGP integration into the routing fabric, which can drive a new layer of agility in placement of the data across data center and significantly greater agility than Fibre Channel or standard L2 networking.
10. SELF-HEALING. The system should have predictive analytic capabilities that incorporate system-wide information, often called telemetry, into a feedback loop to continuously improve against desired attributes. Testing the system-wide monitoring capability should include an understanding of latency, performance, and availability information from each node, as well as the system’s ability to provide notification to the test administrator of any issue at both the network and storage layers. Advanced systems use telemetry to help all users with practical capacity/performance planning and best practices in real-time. Testing for this capability ensures that you select a system that has the potential to learn from itself and improve your environment over its lifecycle.
11. LOCK-IN. The system should support a wide variety of hardware profiles—different server vendors, different server models, different server generations, and a variety of different media—to eliminate the potential for vendor lock-in. The infrastructure industry is notorious for vendors locking customers in to an artificially limited set of choices designed to enrich their top-lines. Enterprises that experienced this phenomenon with their array purchases and even public cloud contracts are looking for open systems that generate hardware options, not lock-in. Test environments should therefore seek to incorporate a variety of different hardware options from the start. Advanced testing should seek to incorporate multiple variables into a single cluster, including different vendors, node profiles, media types and server generations. Ensuring this variety is key to the long-term value of the system as well as to getting the best terms on hardware purchases at every expansion opportunity.

Fortune 1000 customers have every vendor in the IT industry at their beck and call. Selecting the right technologies to test and using the right test parameters—outlined above—will enable them to make the transition to a more automated, scalable and performant future for their data operations.

To learn more about the Datera platform and why the Fortune 1000 are using our software-defined storage solution to architect a new data future, please examine the following core whitepaper library:

• Built for Change
• Built for Performance
• Built for Continuous Availability 
• Built for Autonomous Cloud Operations