Keeping with my trend of putting storage companies out of business by buying their products, I've now graduated to storage conference! Storage World Conference, the last of which was held September of 2006, is now a memory. The website is no longer updated and plans for SWC 2008 are in doubt. Previous SWC gatherings were held in conjunction with the Association of Storage Networking Professionals (ASNP). The ASNP merged into the Storage Networking User's Group (SNUG) last year, bolstering the ranks of SNUG.
Is this a preview of things to come? Has the storage industry begun to shrink? What's it all mean?
First and foremost, the loss of SWC reduces the list of storage-specific conferences to just two - Storage Networking World (SNW) and Storage Decisions (SD). SNW is hosted by ComputerWorld and SD is hosted by TechTarget. Both media groups seem relatively stable, with a vast array of IT publications in their collections. Both SNW and SD have a full calendar of events on both coasts, alternating in the Fall and Spring. With, the influx of sponsor dollars necessary for these schedules will be easier with fewer events each year.
Moreover, this could be a sign that the industry is self-correcting. Do we really need three storage conferences each season? Maybe. Maybe not.
Thursday, September 27, 2007
Monday, September 10, 2007
Deduplication
Many storage vendors have jumped on the deduplication bandwagon, promising users incredible improvements in storage space, data recovery and so on. In many environments, dedupe can both shrink backup times and extend the amount of data retained by only copying newly-created blocks in a backup session. By extending the deduplication within and across backup sessions (i.e. only saving one copy of word.exe across servers and one copy of jre.dll within each backup session), backups require much less time and resources than ever before.
The promise of deduplication and the the reality, however, often differ greatly. Dedupe can be performed on the host or at the storage target; in-line during the backup or post-backup. Different combinations are necessary to meet the requirements of some applications. You may find that dedupe performed post-backup may work well for small, flat file backups, especially across multiple server backups. Large databases, might need in-line dedupe (which has a tremendous impact on the backup process) to achieve any level of cost savings or to even return a viable backup file. Vendors offer a Chinese menu of products and features, with an equally confusing array of licenses and software add-ons to make it all work.
So what do we, the customers, actually need from all of these? Basically, we're all after shorter backups with greater granularity in smaller amounts of storage. Add in faster recovery times and user self-service restores and you've got the recipe for an impressive backup solution. Now, all we need is any vendor to offer this as a product - not the morass of loosely-coupled software products offered today.
The promise of deduplication and the the reality, however, often differ greatly. Dedupe can be performed on the host or at the storage target; in-line during the backup or post-backup. Different combinations are necessary to meet the requirements of some applications. You may find that dedupe performed post-backup may work well for small, flat file backups, especially across multiple server backups. Large databases, might need in-line dedupe (which has a tremendous impact on the backup process) to achieve any level of cost savings or to even return a viable backup file. Vendors offer a Chinese menu of products and features, with an equally confusing array of licenses and software add-ons to make it all work.
So what do we, the customers, actually need from all of these? Basically, we're all after shorter backups with greater granularity in smaller amounts of storage. Add in faster recovery times and user self-service restores and you've got the recipe for an impressive backup solution. Now, all we need is any vendor to offer this as a product - not the morass of loosely-coupled software products offered today.
8Gbps FC.... why?
Early this summer, the FibreChannel Industry Association approved signaling standards for an 8Gbps version of the FibreChannel protocol. 8GBps FC switch and HBA products are expected to arrive in early 2008 in test samples, with major shipments by mid-year. What makes this interesting is, for the first time vendors are delivering their wares before disk products are announced! At this time, Seagate and Hitachi have not announced when or if they will ship 8Gbps disks. Why does that matter?
For the first time, we might see infrastructures that are effectively faster than the backing store. In our current generation, we can claim "end-to-end throughput" - 4Gbps disks attached to 4Gbps arrays on 4Gbps switches and so on. Now, that may no longer be true. Worse yet, there's no evidence to support the believe that the current generation of server hardware can effectively leverage the 8Gbps "pipe". This argument was raised with 10Gbps network cards and iSCSI interfaces, but card vendors claim the protocol overhead prevents the server from obtaining full line-rate. As 10Gbps networking prices fall, it looks like iSCSI can finally provide both lower costs and higher performance than FC.
Infiniband, too, is making inroads across the board. Once relegated only to HPC deployments, it is quickly becoming a common storage interconnect. Scalable storage clusters from DataDirect and Isilon use IB for storage-to-storage and storage-to-host interconnects. If pricing models improve, IB will greatly outstrip both the cost and performance of FC.
8Gbps FC comes to market as virtualization is poised for a meteoric rise; some expect it to become the dominating "operating system' in the data center. Does 8Gbps FC enable virtualization? No more than 2Gbps or 4Gbps. The claims that 8Gbps reduces the number of ISL links between switches may hold true, but it's too early to tell what benefit that really holds.
So the big question I'm left with is why do we need 8Gbps FC? Aside from the ISL argument, there are no drives available (or currently scheduled) and Infiniband and 10Gbps FC offer more bandwidth. Maybe it's finally time for FC to go the way of SCSI and IDE.
For the first time, we might see infrastructures that are effectively faster than the backing store. In our current generation, we can claim "end-to-end throughput" - 4Gbps disks attached to 4Gbps arrays on 4Gbps switches and so on. Now, that may no longer be true. Worse yet, there's no evidence to support the believe that the current generation of server hardware can effectively leverage the 8Gbps "pipe". This argument was raised with 10Gbps network cards and iSCSI interfaces, but card vendors claim the protocol overhead prevents the server from obtaining full line-rate. As 10Gbps networking prices fall, it looks like iSCSI can finally provide both lower costs and higher performance than FC.
Infiniband, too, is making inroads across the board. Once relegated only to HPC deployments, it is quickly becoming a common storage interconnect. Scalable storage clusters from DataDirect and Isilon use IB for storage-to-storage and storage-to-host interconnects. If pricing models improve, IB will greatly outstrip both the cost and performance of FC.
8Gbps FC comes to market as virtualization is poised for a meteoric rise; some expect it to become the dominating "operating system' in the data center. Does 8Gbps FC enable virtualization? No more than 2Gbps or 4Gbps. The claims that 8Gbps reduces the number of ISL links between switches may hold true, but it's too early to tell what benefit that really holds.
So the big question I'm left with is why do we need 8Gbps FC? Aside from the ISL argument, there are no drives available (or currently scheduled) and Infiniband and 10Gbps FC offer more bandwidth. Maybe it's finally time for FC to go the way of SCSI and IDE.
Subscribe to:
Comments (Atom)
