News

2/22/2011
12:25 PM
George Crump
George Crump
Commentary
50%
50%

Solving Scale Out Storage's Dark Side

In a recent entry we discussed a concern with scale out storage, making sure the utilization of processing, power and resources remains efficient. The last thing you want is a storage system that, while it can scale to limitless capacity, also requires limitless power and data center floor space? The good news is that some vendors are aware of these concerns and have some solutions for you to consider.

In a recent entry we discussed a concern with scale out storage, making sure the utilization of processing, power and resources remains efficient. The last thing you want is a storage system that, while it can scale to limitless capacity, also requires limitless power and data center floor space? The good news is that some vendors are aware of these concerns and have some solutions for you to consider.Scale out storage gets its name because typically as you add another node to the cluster, processing performance and capacity scale in unison. The advantage being that you don't need to buy all the horsepower upfront in expectation of future storage I/O or capacity needs.The problem is that as the node count continues to grow one of those variables often gets out of balance. Most environments either a heavier need for capacity or a heavier need for performance, not both equally. Typically as the node count increases the average utilization of the processing power of the cluster declines. The problem will continue to get worse as these nodes, which are typically Intel servers with internal storage, increase the processing performance capabilities though standard technology upgrades. The result is an increasing amount of these systems resources may go unused.

For many storage managers though the trade-off of efficiency is worth the gain in cost effective scalability. After all processing performance is relatively cheap today and power is a budget-able item that many can choose to live with. However, when scale out storage systems grow in size or as they try to appeal to small to mid-range data centers, suppliers need to address the challenges of poor resource utilization. The goal should be to increase the efficiency of each node in terms of processing resources, power and foot print.

There are ways to make scale out storage systems more resource, space and power efficient. First, if the scale out storage system is going to be focused on a nonperformance sensitive environments like most file sharing use cases then using a lower power processor might be a good alternative. For example we recently were briefed by a supplier that used Intel's ATOM processors. Using this processor increases the utilization per node while it decreases power utilization. Utilizing smart packaging will allow these cooler (from a temperature perspective) processors to run in tighter spaces which would lead to better floor space efficiency as well.

Another option is to, instead of making all the CPU resources of the physical server a node, subdivide that server into multiple nodes. For example we see increasing popularity to make each processor core a node as we discuss in a recent briefing report. That means for the same investment in server hardware you could end up with four or more nodes, all working much harder and being more efficient in their utilization. We also were recently briefed on another way to accomplish this which would to be able to run the clustered storage software as a virtual machine and allocate one virtual machine on each physical host to assemble your scale out storage. This would mean zero additional footprint.

A final option is to just make the expected workload of the node higher. Typically when you need more performance out of scale-out clustering the answer is to add more nodes so that more drives are available to respond to I/O requests. The individual nodes are not working harder, there are just more nodes to process the I/O. Mechanical storage inside a node will struggle with keeping that node's processor busy. There is too much latency. By comparison, zero latent technology like solid state drives can keep the node's processors very busy. The result is you have less nodes working harder, delivering the same or better I/O rates.

The other option is to provide better scaling within traditional non scale out (often called scale up) architectures. We will cover those options in an upcoming entry.

Track us on Twitter: http://twitter.com/storageswiss

Subscribe to our RSS feed.

George Crump is lead analyst of Storage Switzerland, an IT analyst firm focused on the storage and virtualization segments. Find Storage Switzerland's disclosure statement here.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Want Your Daughter to Succeed in Cyber? Call Her John
John De Santis, CEO, HyTrust,  5/16/2018
Don't Roll the Dice When Prioritizing Vulnerability Fixes
Ericka Chickowski, Contributing Writer, Dark Reading,  5/15/2018
New Mexico Man Sentenced on DDoS, Gun Charges
Dark Reading Staff 5/18/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "Security through obscurity"
Current Issue
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-2607
PUBLISHED: 2018-05-21
jenkins before versions 2.44, 2.32.2 is vulnerable to a persisted cross-site scripting vulnerability in console notes (SECURITY-382). Jenkins allows plugins to annotate build logs, adding new content or changing the presentation of existing content while the build is running. Malicious Jenkins users...
CVE-2018-1108
PUBLISHED: 2018-05-21
kernel drivers before version 4.17-rc1 are vulnerable to a weakness in the Linux kernel's implementation of random seed data. Programs, early in the boot sequence, could use the data allocated for the seed before it was sufficiently generated.
CVE-2018-11330
PUBLISHED: 2018-05-21
An issue was discovered in Pluck before 4.7.6. There is authenticated stored XSS because the character set for filenames is not properly restricted.
CVE-2018-11331
PUBLISHED: 2018-05-21
An issue was discovered in Pluck before 4.7.6. Remote PHP code execution is possible because the set of disallowed filetypes for uploads in missing some applicable ones such as .phtml and .htaccess.
CVE-2018-7687
PUBLISHED: 2018-05-21
The Micro Focus Client for OES before version 2 SP4 IR8a has a vulnerability that could allow a local attacker to elevate privileges via a buffer overflow in ncfsd.sys.