Grid-based Storage

When I introduced the Storage Evolution, I shared some topics I talk about when meeting with a customer: Virtualization, Deduplication, Grid and Encryption. That list has grown to include Information Lifecycle Management (ILM), Convergence, Business Continuity, Clouds and Big Data. It’s about time I start writing about more of these.

The world of storage is changing – fast. When I started consulting, I used to install clusters and super-computers. My specialty was IBM’s SP super computer (like Deep Blue the one that played the Russian chess champion Garry Kasparov). My wife asked if they wore capes.

The super computer market fell apart over a decade ago to grid-based systems. What used to cost millions of dollars was swept away by inexpensive commodity Intel-based servers, usually running Linux and grid software. The market changed and super computers started to become extinct. What used to be a scale-up model became a modular massively-parallel model which became a highly distributed model. The market changed.

 

Hot Cloud Apps Miss a Valuable Opportunity with the Enterprise

There are a lot of hot startups creating exciting new cloud applications every day. These apps have made our lives easier, some appear necessary. Dropbox lets us seamlessly move data between devices and networks. Yammer lets us collaborate twitter-style within a company. Evernote and OneNote make note taking during meetings revolutionary. Even photos, video and document networks are becoming harder to ignore and block within the enterprise.

While all of these applications have proven their worth, they often violate IT security policies and companies try to police them. Security is a tricky dance, you try and block things that must not be used, especially the harmful, but tighten the screws too much and people will find a way around them. When some of the apps are blocked in a company, workers will break out cellular cards or worse, jump in their car and head to the closest coffee shop.

EMC World 2012

I had the privilege of attending EMC World last week. While I had a lot of NDA material I can not present, I can say the cool new stuff is on the way soon, or here today: VPLEX, VNX, VMAX and more.

I have a new post ready, but I’m waiting to hear back on where it will land. In the meantime, I’ll leave you with a few short videos from EMC World that I participated in.

EMC World 2012 – Hot New Tech

EMC World 2012 – Automated Tiering Strategies

EMC World 2012 – Cloud in the Enterprise

Proof of Concepts and Bakeoffs

If you’ve got the time, we’ve got the gear.™

Storage is the slowest resource in the datacenter. We measure things in milliseconds, while other components are in micro or nanoseconds. We’re increasingly asked to push more and more data through pipes faster and faster. When storage fails: screens go blue, kernels panic, things get ugly. Some call this a resume generating event.

For this reason, storage professionals as a general rule are a conservative bunch. We resist change. We want things to be safe and mature with low risk and no bugs. We avoid the bleeding edge. Some wait months or years after new products are released before they considering deploying them.

This approach doesn’t always serve us well.

Long-Distance vMotion: Updates

This is an update to the Long-Distance vMotion series I did earlier this year. If you wish to read it all, start with Long-Distance vMotion: Part 1.

The problem with blogging about technology, techniques and architectures is they change. Sometimes that change is rapid, sometimes it takes time over major releases. In a more converged world where multiple components play, they can change quite rapidly.

Since writing my Long-Distance vMotion (LDVM) series, there have been some changes. Here in lies the dilemma, do I go back and change the old articles, or do I post an update like this new entry. I could add a section to the blog with the latest analysis, called Long-Distance vMotion. Part of me feels I should leave old posts unchanged (except correcting typos and erroneous information). The other approach would be changing the old articles preserving search engine entry points that are currently sending people into the articles – they wouldn’t have to go to another place in the blog for the latest updates. I can post-date new entries, I can’t post-date new information. Which is the best approach? Let me know what you think.

vBlocks and FlexPods: is this Coke v Pepsi?

When Cisco came out with their UCS servers, I was impressed. They took the Nexus FCoE switches and modified them into a whole new thing, the UCS: with FCoE, service profiles and an expandable distributed blade server model. What really makes sense is the bottom line, you can save real money by deploying them over traditional blade or standalone servers. They save money with price per port and not having to buy additional switches for every 14-16 servers in a traditional blade enclosure. They simplify rapid deployment of servers. They allow moving workload to new blades without having to rebuild them.

Converged networks suddenly start to make sense with the Cisco UCS. You begin to see Cisco’s master plan in action. It’s not just FCoE in a switch, but a whole system built around best practices: FCoE, boot from SAN, etc. The biggest gain immediately obvious are the service profiles: VMware abstracts servers, service profiles are somewhere in between virtualizing the hardware the VMware is built upon. Firmware, UUIDs, WWPNs, MAC addresses, everything is abstracted. It took things one step farther than HP virtual connect.

Cloud #fail

This is a very brief post on the cloud computing failure of today. I hope to have a guest writer post something better, more lengthy in the future.

I’ve been partaking in some discussions among peers on today’s Amazon EC2 cloud outage – again. I’ve been listening to people say the cloud isn’t ready or is a bad idea. The cloud is the cloud, and continues to be a great decision for a lot of people where it makes sense. The failure people make is in abandoning IT best practices when going to the cloud and going with a single system or provider.

When we design for disaster recovery or business continuity, we usually design in redundant, diverse data paths to the secondary data center with carrier diversity (meaning more than one carrier). When going to the cloud, if you’ve decided to outsource everything, you should continue that diversity with multiple cloud providers and the resiliency to be able to use either. Failure to provide cloud diversity is the same as having one datacenter, you’ve got all your eggs (IT) in one basket.

When going to the cloud, you should either have a hybrid private/public cloud with redundancy, or two public cloud providers with diversity. Those that stray from IT best practices will pay the price – on twitter you’ll get the dreaded #fail associated with your name.