Rackscale applications like Hadoop, Spark, Cassandra and others count on using commodity storage that is typically internally available to the node processing the data. The idea is to reduce storage costs and network complexity. The problem is these designs create storage silos that reduce data reliability and data efficiency. Shared storage systems have tried to edge their way into the modern application space but if the organization adopts those strategies they risk compromising the original design of a simple, cost-effective storage layout.
Modern application architectures are made up of a cluster of servers acting as nodes. The nodes typically have storage internal to them and data is replicated between nodes of the cluster to meet availability demands. But each cluster requires its own storage and organizations quickly run into situations where one cluster is running out of capacity while another has plenty of excess capacity.
Separation of servers & storage has traditionally been an important way to achieve efficiency and flexibility in the data center. However, with the rise of data intensive applications such as Hadoop, NoSQL, Kafka, etc – none of the traditional SAN or NAS solutions make sense anymore – neither the cost or performance is viable for these new applications. In addition, most storage solutions offer a glut of features that are not relevant to applications built for DAS.
DriveScale offers “Software Composable Infrastructure” – a new approach to separation of servers & storage, and software to manage, at cluster scale, the relations between them. DriveScale leverages commodity servers, ethernet switches, and dumb SAS JBODs of the customers’ choice, leaving the cost benefits of commodity hardware in place. Performance derives from the ever increasing bandwidth of ethernet switches, and location/topology aware binding of drives to servers.
DriveScale delivers an adaptor that acts as a SAS to Ethernet bridge, connecting JBOD shelves to compute nodes within each rack. The solution also includes software that will discover available storage resources, create or compose volumes from those resources and monitor their use. We detail the DriveScale solution in our briefing note, “Breaking Down Hadoop, Spark, Cassandra Silos”.
Improving Hadoop Reliability and Integration
In its latest release, DriveScale added several vital capabilities, which show the solution maturing and the company responding to the needs of its customers. The first new feature is “HDFS Block Placement.”
The Hadoop Distributed File System (HDFS) implements a block placement policy to ensure data availability. The default policy is to have three copies of each data block. The typical policy calls for the storing of one copy of data on the node where users adds or modifies the data. The second and third copies, according to the policy, will typically be stored in different racks.
The assumption behind this distribution of data is the failure domain of the storage is the same as the failure domain of the server. If the server fails, then the storage fails with it because it is internal to the server. In a DriveScale use case, the storage is external to the node, so the failure domain is separate. To make better use of the DriveScale design in Hadoop environments, the solution created a block placement plugin for HDFS, which enables Hadoop to be aware of the separate storage failure domain. The block plug-in extends the HDFS BlockPlacementPolicy class and does not require a custom Hadoop distribution.
The plugin relies on DriveScale storage groups, introduced in DriveScale 2.0. Storage groups are used to group a set of JBODs together and ensures that all resources assigned to a server or node belong to the same storage group. The DriveScale block placement plug-in then ensures that as HDFS does its replication that the replicas are placed in three (or as many storage groups as there are replicas) distinct storage groups.
DriveScale best practice is to divide each storage rack into two storage groups. With a two rack configuration, the first two copies will be in one rack, and the other copy will be on the second rack providing the desired redundancy but doing so seamlessly to HDFS. The result is that availability of each block is guaranteed in the case of a storage failure, compute failure or rack failure.
Quick Cluster Feature
One of the complaints of users of modern applications is the time it takes for IT to get a cluster ready for use. The fall release of DriveScale adds a Quick Cluster feature. The quick cluster capability allows the administrator to create a new cluster quickly without having to first set up the node or cluster templates. The wizard allows the admin to create a cluster from a spreadsheet like interface. The administrator only needs to indicate the number of servers by type and the number of disk drives per server by type, and then the cluster is created automatically, reducing cluster setup to a single step process.
Incremental Cluster Modification
A final feature in the Fall 2017 release is the addition of a feature within the DriveScale GUI to modify running clusters. Administrators can add or remove servers as well as add or remove drives through a simple set of steps.
DriveScale continues to make implementing modern applications like Hadoop, Spark and Cassandra easier. Instead of traditional shared storage, which requires that the application be restructured and maybe even a custom distribution of the application, DriveScale makes the nodes think that they are dealing with internal capacity while providing all the benefit of a shared storage system.