Future Storage Systems: A pause in workflow

October 17, 2008

Since I started this article series, I’ve had the awesome opportunity to have my ideas (well, some of the early articles at least) reviewed by person(s) who deal with the actual infrastructure of storage systems day in, day out.  The benefit of such peer review is that you get to learn at the symbolic “feet” of the masters and discover flaws, omissions, and understated features that need to be understood and incorporated.  This post is dedicated to some of those discussions and, where applicable, my understanding of how the FSS either incorporates or misses the boat.

Read the rest of this entry »


Future Storage Systems: Part 4: Operating System - Conceptual Overview

October 13, 2008

In the previous Future Storage System articles, we’ve covered the basic hardware foundation for what I envision to be a powerful future-oriented storage solution for the commercial midrange.  However, as you’re probably aware, hardware is meaningless without software to provide the operational capabilities that are needed to mange information.  In this article, I will focus on a general design for an extensible software layer (an OS) that will provide future-oriented capability expansion as well as robust analytics, capabilities, and integration with business continuity principles.  As always, please reference the diagram below.

Future Storage System - Operating System - Conceptual

Future Storage System - Operating System - Conceptual

Read the rest of this entry »


Why wouldn’t the following work? (Future Storage System: Part 1)

October 7, 2008

So, I’ve been toying around with this in my mind for some time.  Essentially, I’ve tried to understand the basic “Storage Processor” limitation of current storage systems and propose an admittedly simplistic design to get around some of the difficulties.  The biggest hurdle, in my mind, is to have cache coherency, low latency memory access to other nodes in a “cluster,” and have a communications “bus” between nodes that is extensible (or at least will grow bandwidth with more devices on the signal chain).  Staring at that problem, then, look at the image below.

A case for Hypertransport connected nodes...

A case for Hypertransport connected nodes...

Read the rest of this entry »


Search Term Tuesday - May 26th Edition

May 27, 2008

This is the second edition of the same post. Evidently, WordPress doesn’t like it when I fat-finger in Firefox 3.0 Beta 5. Grrrrr…..

So, what is “Search Term Tuesday” (or any other day of the week, even)? The principle of it is this: grab some of the focused searches out there that land on this site (i.e Flickerdown) and attempt to respond to them with more data. Deal? Let’s begin, then.

Read the rest of this entry »


It’s not about the money…

May 5, 2008

…or is it?

Sometimes, I think we spend too much time worried about how much X solution is going to cost without looking at the big picture. I’ll be quite honest with you: a $25,000.00 array IS expensive to SMB, regardless if a Commercial or Enterprise account rep thinks otherwise. “What’s the value that the $25,000 array is going to bring you? Is it truly worth that cost? etc. etc.” have to be the questions swirling through the minds of any competent IT Director/Admin, etc. After all, the last thing you need in your Data Center is deadweight.

Read the rest of this entry »


More on the SAS vs. Fibre debate

March 25, 2008

Connectivity Reliability

At some point, I had typed in a bit about the physical interfaces present on both the SAS and Fibre drives. I appears that I ran roughshod over that particular point which, upon thinking about it, is a very important dimension of drive reliability.

As noted previously, SAS drives use an amended SATA data+power connectivity schema. Instead of a notch between the data and power connections as present on SATA drives, SAS drives simply “bridge” that gap with an extra helping of plastic. This not only turns the somewhat flimsy SATA connectors into a more robust solution, it also requires that the host connector support that bridging. Interesting note here is that the SAS host connector supports SATA drives but SATA host connectors will not support SAS. This is somewhat assuaged by various host implementations (i.e. using a SAS connector on a backplane with discrete SATA data connectivity from the backplane to the mainboard) but generally, this is the rule. The SAS drives feature a male connectivity block which is mated to a female SAS connectivity block on the host system. Pretty basic stuff.

Fibre drives, on the other hand, use a SCA (single connector edge) medium that is again male on the drive side and female on the host side. Definitely more simplistic in design and implementation (and is featured within all current EMC arrays) and honestly, when push comes to shove, something I would trust inherently more with protection. The same idea is present with SCA80 Ultra320 SCSI drives as well. The fitment here is definitely more secure with less design stress placed on the physical connector (and thusly the PCB itself) than with the SAS solution.

There are always caveats with distinct designs, however, and I’d like to highlight some below.
a.) The SAS data+power connector is inherently MORE secure than the standard SATA interface. Truth be told, I’ve broken SATA data connectors. It’s really not hard since the data connection is a discrete “tab” from the power interface (which I’ve broken as well). The addition of the plastic “bridge” between data and power connections on SAS drives promotes a stronger bond between the connector (whether that be SFF or backplane based) and the drive itself. It also keeps folks from mistakenly connecting SAS drives to SATA ports. ;)
b.) The SAS interface is still prone to breakage as compared to SCA40/80 connections. There’s a reason why we do a conversion within our drive caddies from SATA to Fibre (outside of the obvious protocol translation and sniffer obligations): it’s more secure. The mating mechanism within the SCA interface provides no single point of stress on the connector as there is a nesting process that takes place. Not so with the SAS interface: you have a significant protrusion into the caddy area that, if improperly aligned, can cause damage. If you misalign the SCA interface, you can’t make the connection and there’s no protrusion difficulties.

Note: The good news in all of this (at least from my perspective @ EMC) is that we’re not going to allow you to screw this connectivity up. ;) We mount the drives in our carriers, put them in the array and, well, we’ve got you covered. ;)

In any case, this is really for further clarification from yesterday’s post. Hopefully that will give a little more food for thought.

Technorati Tags: , , , , , , , , , , , , , , , , ,


SAS vs. Fibre, Seagate’s SSD dilemna, and Sun’s “Freakin’ Laser Beams”

March 24, 2008

SAS vs. Fibre

One thing I hear about constantly (within the hallowed halls of EMC and elsewhere), is the general “inferiority” of SAS drives vs. Fibre. This usually comes complete with a somewhat stale argument that because SAS is a natural extension of SATA, it is therefore a “consumer” drive and not “good enough” for the Commercial or Enterprise disk space.

Really?

What most people fail to realize is the following:
a.) The platters, drive motors, heads, etc. are the same. If people actually spent the time looking into these products (vs. cutting at them with a wide swath of generalized foolishness), they’d actually see that the same mechanical “bits” make up both the “enterprise” class fibre and SAS drives. Looking at the Seagate Cheetah 15k.5 drive line, we see that they’re offered in SCA-40 (Fibre), SAS, SCA-80 (u320), and 68pin interfaces. The spec sheet shows that outside of differing transfer rates (and, lower power draws at load/idle than Fibre), both the SCSI and SAS drives are the same.
b.) The primary differentiators are the PCBs, ASICS, Physical Connectors to the “host” system, and Transfer Rates. Flipping the drives over, you’ll obviously note the differences in PCBs, onboard ASICs, and physical connectors. That’s a wash as it has little to nothing to do with reliability. So, what you’re left with is the transfer rate conundrum. Honestly, given how particularly bad customers are at actually filling a 4 gigabit per second pipe with data (esp. in the commercial side of the house), a 1 gigabit per second difference (roughly 100mb/s) is minimal. Oh, for the record, our STEC SSDs will only have a 2gb/s connection to the Symmetrix, last I heard. ;)

I think those two points about cover it. ;) MTBF, etc. are the exact same, btw, so, don’t expect any differences from hardware longevity.

Seagate and SSDs: WE SUE YOU!

Engadget is one of my favourite reads during the day and consequently, I need to blog about articles located there more often. That being said, I almost fell out of my seat this morning when I read one of the latest postings: “Seagate warns it might sue SSD makers for patent infringement.” Yippee. In my opinion, this is more of the same “sue happy” nitwitery (is that a word?) that happens every single time Apple decides to release a new “product.” Some Rip van Winkle patent hound comes out of years of slumber and states “I patented the EXACT same technology using specious language and vague intimations of what I thought could work” much to the chagrin of everyone around. Now, in the case of Seagate and Western Digital, I believe that they’re just looking to diversify their holdings in the emerging SSD market. Remember, at the price per gigabyte/terabyte mark, spinning disk is still the king and will be for quite some time. However, in terms of power draw and raw IOPs, you can’t beat them. In any case, file this whole article under the “we want in (and the money wouldn’t be a bad thing either)” category. ;)

EDIT: (4/10/08 @ 1103pm EST) New entry added above on the Seagate vs. STEC lawsuit

Sun: We’re going optical (with LASER BEAMS!!!!)

Next on the hitlist is the re-emergence of Optical interconnects between processors as noted by Sun (and it’s recent DARPA grant). Great news for Sun, really, but IBM has already been doing this for some time. Optical interconnects ARE the wave of the future for processor interconnects, etc. especially as quantum computing (and it’s massive data loads) are concerned. Definitely something to pay attention to. Who knows? Maybe EMC will use optical transmission in its Symmetrix line between the blades. ;) A boy can hope.

That’s all for now.

Peace,

Dave

Technorati Tags: , , , , , , , , , , , , , , , , ,


Piggy-back concepts of “Greening” the datacenter

March 21, 2008

I’ve had a LOT of fun, lately, reading Mark Lewis’ blog (found here) as he delves into the green data center concepts. To rehash some of what has already been talked about to “green” your data center:

a.) Tier your storage. Higher speed spindles, by nature, consume more power. (Compare the specs for the Seagate Barracuda ES.2 Enterprise SATA drive to those of the Seagate Cheetah 15K.5 FC/SAS drives). By moving your data from higher speed spindles to lower speed spindles based on usage/access patterns within a larger system policy framework, you can keep power consumption low overall. Better yet, archive it off to a Centera and remove the need for tiering within the array to begin with. ;)
b.) Virtualize, Virtualize, Virtualize. Sure, it’s the “trendy” thing to do these days but, with the ability to collapse 30:1 (physical to virtual) in some cases, simply investing in VMWare (of course) will cut down on your power footprint and requirements. From the host side, using devices like Tyan’s EXCELLENT Transport GT28 (B2935) with AMD’s quad core Opteron processors allow for rack dense ESX clusters to be created that can scale to (get ready for it): 160 physical sockets/640 cores per 40U rack and 320 Gigabit Ethernet ports. I also forgot to mention that within these 1Us, you can install low profile 2port Qlogic QLE2462 4GB/s fibre cards to allow for multi-protocol attached storage to be used. *hint, hint* I think this would be a GREAT platform for the next EMC Celerra. ;)
c.) Use different storage media. By “different storage media,” I am referring to the availability of SLC/MLC flash drives and the pervasive use of 2.5″ fibre/SAS drives within the data center. I’ve already waxed eloquent before on the merits of using 2.5″ drives (lower power consumption, less moving parts, typically faster access times than comparable 3.5″ drives, etc.) and I’m anxiously waiting to see if EMC will adopt these drives for their arrays. With 2.5″ drives coming close in platter densities (500gb 2.5″ SATA drives are already available in the market), I think there is less of a reason to continue to use 3.5″ drives for nearline storage. Flash, on the other hand, while available in smaller quantities, takes the speed and power equation to a whole different level. I’ll let the Storage Anarchist explain the details:

“As you’ve probably read by now, the STEC ZeusIOPS drives themselves are in fact optimized for random AND sequential I/O patterns, unlike the lower cost flash drives aimed at the laptop market. They use a generously sized SDRAM cache to improve sequential read performance and to delay and coalesce writes. They implement a massively parallel internal infrastructure that simultaneously reads (or writes) a small
amount of data from a large number of Flash chips concurrently to overcome the inherent Flash latencies. Every write is remapped to a different bank of Flash as part of the wear leveling, and they employ a few other tricks that I’ve been told I can’t disclose to maximize write performance. They employ multi-bit EDC (Error Detection) and ECC (Error Correction) and bad-block remapping into reserved capacity of the drives. And yes, they have sufficient internal backup power to destage pending writes (and the mapping tables) to persistent storage
in the event of a total power failure.”

In any case, these are some quick notes from me this AM. Definitely am looking forward to delving into the Tyan GT28/AMD Quad Core stuff in the next few days.

Happy friday!

Technorati Tags: , , , , , , , , , , , , , , , , , , , ,


Thoughts #2

February 19, 2008

So, in an effort to simplify my life, i’ve taken to keeping the subject lines on my posts as simple as possible (well, that an the fact that I’m usually responding to 15 different blogs within the context of one big post). Today, I’ll try to break things out as cleanly as I can. Deal?

Storagezilla: Where PCs go to Die
:
Grand title, as you’re aware and I definitely feel that there are two different threads to take a look at. Like Storagezilla, I maintain an active subscription to National Geographic. In last month’s issue, there was an article regarding computer disposal and the accompanying issues that arise once your Mac/PC/Whatever are picked up at the curb.  The most damning information came forth regarding where your electronic waste is ending up; typically, in 3rd world countries (sovreign African nations most notably) with little to no import restrictions in place regarding hazardous material.  To put this into context (as Storagezilla so notably explains), we’re having a little issue with a US Spy satellite that has 1,000 pounds of Hydrazine in its fuel cells.  All this furor is being created about the relative toxicity of Hydrazine when, just a scant 5,000 miles away from the US, we have millions of folks that are being exposed to hazardous fumes, lead, mercury, and any other number of chemicals/carcinogens that can (and do) cause birth defects, cancer, etc.  While I won’t go so far as to say “Don’t buy a computer,” I think that Green Peace (toxicity report is here) is on to something by releasing toxicity reports for some mainstream consumer electronic gadgets.  So, what can we do?

The answer is both simple and complex.  The simplistic approach dictates mandated recycling programs that keep commercial, consumer, enterprise “trash” within the US (or host country).  Tax the hell out of the things if you need to maintain the programs but, constrict the ability of exporters to dump our waste to other locales.  The complex answer is…well, tighten export controls on electronic waste, audit recycling companies for compliance to federal/international “waste” standards (RoHS, et al.), tax the hell out of consumer electronic waste (even $5.00 per sale of every computing system would be enough, I’m sure), and actually MONITOR the process.   Not to turn this political at all, but this is a bipartisan matter that won’t survive if it’s strictly a Republican or Democratic or Green Party thing.

Thoughts?

Rough Type: EMC’s “very massive” Storage Cloud

So, this is a new blog that I got turned on to (the leap came from Storagezilla to O’Reilly Radar to Rough Type) has a lead article on EMC’s Cloud storage initiative. While Nick Carr spends most of the blog post regurgitating news from Chuck Hollis, I did find it refreshing to read the following comment:

“Like other traditional IT component suppliers, EMC sees cloud computing as both
threat and opportunity. On the one hand, it could put a large dent into
individual businesses’ demand for on-site storage systems, EMC’s bread and
butter. On the other hand, somebody has to build and run the storage cloud, and
EMC has the scale and expertise to be a big player in this new business.” (Nick Carr)

Quite simply, Cloud storage (if that’s the defined term that we’re using) is a natural extension of Software as a Service and Storage as a Service (both are SaaS, right? ;) ).  EMC’s first foray into this world was through the acquisition of Mozy and now, with a more SMB focus in hand, they’re moving to other avenues of the “as a Service” model.  The purported integration with SAP, for example, would promote the Software service end, while EMC quite easily could pickup the Storage service end.  Is it a perfect union? Time will really tell, but, like Amazon found out, service based storage/grid/etc. isn’t a bed of roses. What EMC needs to plan for (similar to any array that they manufacture) is redundancy, availability, and performance.  Literally, we need to practice what we preach when it comes to the deliverables. We’re constantly injecting ourselves into the customer’s ILM strategies and advising them on best practices, but if we can’t implement them ourselves (and at a wider scale than we have ever done), we’re hypocrites of the greatest kind.  I’ll leave it up to the smarter people I work with the figure that mechanism of protection out, but…let it be known that the world’s gauntlet has been thrown in our direction.

Thoughts?

I’ll update later as time permits.

cheers,

Daved

Technorati Tags: , , , , , , , , , ,


Symmetrix Recycling…

February 14, 2008

This was too good to pass up….



BAAAAAAAAD SYMM!
!!!!

cheers,

Dave

Technorati Tags: , , ,

Powered by ScribeFire.