Comments on: Enterprise Computing: Cisco, IBM, Sun & EMC – A Busy Week

By: Enterprise Computing: The Long Term Future of Tape « The Storage Architect

Enterprise Computing: The Long Term Future of Tape « The Storage Architect — Tue, 24 Mar 2009 16:56:12 +0000

[...] funny how a small comment made in a blog post strikes a note with people in different ways. In this post on the potential Sun acquisition by IBM, I made the comment “tape doesn’t have a long-term [...]

By: Chris Evans

Chris Evans — Tue, 24 Mar 2009 15:30:38 +0000

d_ced – I’ll reply to this with a post as I think it your comment merits a more detailed response.

Cheers
Chris

By: Ced

Ced — Tue, 24 Mar 2009 07:34:43 +0000

Hi Chris,

“and tape doesn’t have a long-term strategic future in anyone’s business”

How do see the future of tapes because me, so far, i haven’t found any VTL based solution capable of providing so much storage density per square meters.

With a SL8500 (the one i know), yo have 8500 tapes of up to 1TB (with T10000B). It’s 8.5Pb. Have a look on how much racks of disks you need for this. I’m pretty sure that the floor space will be much higher.

Also in a green strategy to reduce power consumption (to insert more stuff in your DC ), VTL based solution are still far from the power consumption of a library.

The only ‘unknown’ is how tapes will evolve in the futures to provide higher density.

By: Geoff

Geoff — Sun, 22 Mar 2009 22:29:06 +0000

Yes, but we need something more scalable and I/O optimized than VMFS for what you are describing. The RDM with NPIV solution today bypassing VMFS is suboptimal from a management and integration standpoint, but is recommended for structured/ random I/O and performance. For these requirements, I can see the value of FC-8 on the storage channels on the arrays. Again, the interface is irrelevant (between FC native or FCoE), as long as it is a low latency I/O stack (i.e. no TCP/IP in the I/O path) and ~10Gbps for concurrent access requirements. Here is where you continue want to use LUN level intelligence from the array vendors for migrations, snaps, and DR requirements for large structured data sets. DDN and 3Par arrays are good for these workloads with good toolkits. These workloads also do not tend not to run in VMs as of yet. Cisco’s UCS changes that, which leads me to hope that the VMFS scalability limits and feature set will be much further enhanced also. The V-storage API is an interesting convergence point for at least for managing the structured data sets. Still not sure how to properly handle very large unstructured data sets on VMFS. NFS?

By: Chris Evans

Chris Evans — Fri, 20 Mar 2009 08:54:12 +0000

Geoff

I’d agree with you on the consolidation front, however a year ago when FCoE was being discussed, for individual servers, there was no benefit in consolidating into a single “I/O” device due to lack of cost saving, more management overhead etc.

Since then, the Cisco UCS announcement, plus the clear direction we’re headed of having most servers virtualised and sitting above a “Open Systems Mainframe” style architecture means the implementation of FCoE makes perfect sense. In that scenario, I’d agree with you that FCoE is much more preferable than a multiplicity of connections; it’s like going back to ESCON and EMIF of 20 years ago. Personally I think this trend should be sounding alarm bells for the storage vendors. The clear message is that their hardware is not important; higher level intelligent functionality like snapshots and replication will be done at the hypervisor level and/or guest level. So, as long as the hardware delivers and can be managed then who cares where it comes from?

By: Geoff

Geoff — Fri, 20 Mar 2009 01:05:56 +0000

The immediate benefit of FCoE needs to be viewed from the server side–a single I/O interface (CNA) rather than a multiplicity of NICs and HBAs–reducing data center spaghetti. By extension, FCoE provides a single fabric (LAN and SAN) rather than separate networking infrastructures. This vision will be executed over time as networking infrastructures (both LAN and SAN) are upgraded to accommodate unification over DC Ethernet (lossless). DC Ethernet significantly reduces cost, complexity, and overhead.

The storage target will still be delivered FC. Whether the FC frames are delivered over DC Ethernet or directly over Fibre is a fairly moot point right now, but will become relevant once the native channel interfaces on the arrays become FCoE channels. Then it simply is a match of convenience, not necessity as any FC target can plug into an FCoE network. Remember that the payload will not change and will remain FC such that the target retains all its properties and capabilities from a functional standpoint. Nothing really changes on the target.