Howard Marks

Network Computing Blogger


Upcoming Events

Where the Cloud Touches Down: Simplifying Data Center Infrastructure Management

Thursday, July 25, 2013
10:00 AM PT/1:00 PM ET

In most data centers, DCIM rests on a shaky foundation of manual record keeping and scattered documentation. OpManager replaces data center documentation with a single repository for data, QRCodes for asset tracking, accurate 3D mapping of asset locations, and a configuration management database (CMDB). In this webcast, sponsored by ManageEngine, you will see how a real-world datacenter mapping stored in racktables gets imported into OpManager, which then provides a 3D visualization of where assets actually are. You'll also see how the QR Code generator helps you make the link between real assets and the monitoring world, and how the layered CMDB provides a single point of view for all your configuration data.

Register Now!

A Network Computing Webinar:
SDN First Steps

Thursday, August 8, 2013
11:00 AM PT / 2:00 PM ET

This webinar will help attendees understand the overall concept of SDN and its benefits, describe the different conceptual approaches to SDN, and examine the various technologies, both proprietary and open source, that are emerging. It will also help users decide whether SDN makes sense in their environment, and outline the first steps IT can take for testing SDN technologies.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

See more from this blogger

Rethinking The Midrange Array

New midrange array architectures challenge the dominance of the old model using two controllers with coherent non-volatile RAM caches. In addition to scale-out systems, vendors have recently started offering hybrid systems that move RAID to the drive shelves and, most interestingly, shared cache systems.

Ever since Data General set the mold for the midrange array with the first Clariion in the 1990s, mainstream midrange arrays have followed a similar design: a pair of controllers sharing control of a group of dumb drive shelves and some amount of battery backed up NVRAM cache.

More Insights

Webcasts

More >>

White Papers

More >>

Reports

More >>

Regardless of whether the two controllers are running in an active-active or active-standby configuration, the write cache has to be kept coherent across the two controllers. If it wasn't and a controller acknowledged a disk write and failed before flushing it to disk, the data would be lost. And when the other controller took over, the application's data would be corrupt.

This requirement to maintain cache coherency means array vendors have to engineer a high-bandwidth, low-latency link between the controllers. This limits the size of the write cache and consumes controller CPU cycles that could be used to implement more advanced features such as replication or data reduction. The complexity of maintaining a shared cache is also why we haven't seen systems with more than two controllers, like HP's 3PAR and EMC's vMAX, in the midrange.

Rather than putting a few gigabytes of NVRAM cache in each controller, some of the latest systems I've seen are using solid-state drives (SSDs) in the drive shelves as the top-level cache. These are either high-performance SLC flash SSDs, like STEC's ZuesIOPS, or ultra-high-speed RAM SSDs with internal ultra-capacitors to allow them to dump their contents to internal flash in the event of a power failure.

Since the cache is now in the shared drive shelf--or, even better, mirrored across SSDs in multiple drive shelves--it's available to all the controllers in the array without the overhead required to maintain coherency. In a dual-active controller system where each controller "owns" some volumes, the controllers just need to exchange messages to adjust the allocation of cache space between them, rather than the data itself.

When I first saw systems with this architecture, I was concerned that putting the cache at the end of a SAS connection would create a bottleneck and limit cache performance. Truth is, the kind of transactional applications that actually see a significant benefit from caching don't send enough data to saturate the 6 Gbps of a SAS channel. And the performance hit of a few microseconds of additional latency doesn't seem to matter much as the shared cache system I’ve seen are still blazingly fast.

An application like SQL Server or Exchange typically reads and writes 8K pages to and from its storage. It would take more than 90,000 8K IOPS to saturate a single 6-Gbps SAS channel, and a vendor looking to provide even greater performance from an all-solid-state array could simply use more NV-RAM SSDs on additional channels.


Related Reading


Network Computing encourages readers to engage in spirited, healthy debate, including taking us to task. However, Network Computing moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Network Computing further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | Please read our commenting policy.
 
Vendor Comparisons
Network Computing’s Vendor Comparisons provide extensive details on products and services, including downloadable feature matrices. Our categories include:

Research and Reports

Network Computing: April 2013



TechWeb Careers