Cisco recently reached out to a number of us in the IT infrastructure space, asking for our opinion on UCS as it stands today. Gestalt IT author, Greg Ferro, posted a number of keen thoughts over at his Ethereal Mind blog, and we (Bas Raayman and Stephen Foskett) put our heads together to come up with some additional thoughts. Although clearly directed at Cisco, we look forward to responses from other parties as well!

1. How successful has UCS been in production deployment? What were the expectations of early adopters and have these been met? What do Gestalt IT readers think?
2. What feedback has Cisco received from customers from customers regarding Fibre Channel over Ethernet (FCoE)? What do our readers think of FCoE at this point?
3. Many customers do not require a fully built-up stack, and instead need only a few blades. Are these smaller customers responding to UCS or is the product’s target market exclusively at the high end?
4. Will Cisco introduce a UCS model with multiple blade chassis?
5. What is the added value to a customer comparing a full width UCS blade to a regular 1U server?
6. What is the strategy if a customer needs extra I/O for an individual server within the UCS stack? Are any I/O extensions or upgrades planned?
7. Scalability is one of the key issues. What is the target scale for UCS and what is the biggest UCS deployment currently in use?

The VCE data center partnership resulted in taking the UCS computing system as a basis and integrated a storage unit and VMware to the solution stack. This is a solution that is sold as a “plug and play” virtualization building block and helped to establish UCS as a strategic platform. The Ionix part of the vBlock solution has “overall management” written over it, directed to allow management of all components from a central interface. More questions come to mind regarding VCE and UCS:

1. Are there any plans to provide the option to upgrade to a vBlock solution from a purchased UCS stack? If I currently have a UCS setup, can I add the missing components and have my setup validated so that I can add a storage array and the Ionix management to create my own vBlock?
2. I am putting “all of my eggs in one basket” by solely implementing the UCS solution. Of course I need to plan growth, but what happens if Cisco encounters issues in delivering new hardware? Small and medium enterprise sized companies usually need to have multiple suppliers to avoid such problems, but how does Cisco handle this?
3. How well do the UCS components work with other hardware beyond VCE, and is Cisco also offering a unified management solution for a heterogeneous environment? If not, what interfaces are they offering to implement central management?

We look forward to the response from Cisco and our readers!

© Gestalt for Gestalt IT, 2010. | One Year Later: Questioning Cisco UCS
Read more posts categorized as Exclusive, Featured, Networking, Server Virtualization, Storage, Top Story

At EMC World 2009, one thing we heard over and over was the investment EMC was making into software products. Today, out of the core group of 7000 engineers EMC has in the team, 20% are hardware engineers while all of the rest are software engineers.

EMC’s Unified Hardware Approach

EMC’s focus over the past several years has been on minimizing its different hardware platforms and introducing advanced software functionality in its platforms to deliver end-to-end integration.

As we saw with the next-generation Symmetrix V-Max platform, EMC swiftly moved towards using similar hardware components to those already being used on various other EMC hardware platforms. These common components include disk drives, flash drives, DAE’s, LCC’s, Intel x64 CPU’s, fans, power supplies and other components. Past versions of the Symmetrix have been very different than V-Max or the related CLARiiON platform.

The Celerra NS platform is another example of this unification. Compared to the Celerra of 5 to 7 years ago, the latest generation of Celerra looks like a Clariion CX.

Through sophisticated software, EMC has created the Clariion Disk Library (CDL) and Enterprise Disk Library (EDL), virtual tape libraries (VTLs) that emulate tape drives. This is another possible direction for EMC. It is not a far stretch to envision the company pulling more software into the storage processors of today, as they have done with RecoverPoint/SE. Moving to the Intel x64 platform across the board gives EMC the ability to easily add advanced functionality.

EMC’s Focused Software Approach

The secret sauce is the software. Let’s look at EMC’s formation of a unified storage platform running software/firmware/OS to give it an appropriate identity. Though certain features like redundancy, robustness, performance and flexibility of a platform can only be obtained through added hardware features, the underlying hardware components merely act and perform based on the software orchestration.

Don’t expect this to happen tomorrow. But since hardware these days is becoming a commodity, and based on some early signs of the direction EMC is moving in, we should see this approach in all next generation EMC products.

Today, with the CLARiiON, CDL, EDL and Celerra platforms, we have seen EMC use similar hardware components, while the Centera is based on different hardware architecture. In the near future, we may see the Centera become part of the common storage platform with added software capabilities that will define the next generation product. Data Domain’s future is a bit unknown at this time, but if it integrates to become a platform within EMC, expect similar changes for it as well.

EMC’s first move towards free data movement

The introduction of FAST (Fully Automated Storage Tiering) is around the corner. The first version of FAST may allow the data to move internally within the same subsystem based on various tiers. EMC should take it to the next level, where the data can move freely between multiple systems based on storage tiering, which we may see with a future version of FAST.

Though FAST has been the talk for the town for the Symmetrix V-Max platform, FAST stands for Fully Automated Storage Tiering, not Fully Automated Symmetrix Tiering. Therefore, we could see this data movement enabled between various different subsystems based on policies.

Dave Graham’s post on Why Policy is the Future of Storage, written after this article, seems to give some hints on how EMC might be shaping the cloud infrastructure, with Atmos as the underlying technology that will govern the cloud storage.

Automation vs. Manual

There is a current discussion in the industry on whether or not to automate functionality in storage arrays. There are clearly two distinct segments: One that favors automation and the other that favors manual processes.

For example, in the days before thin provisioning and virtualization, customers absolutely knew where their data sat (down to spindles) within the storage environment. With the introduction of VMware, thin provisioning, and other virtualization features, it has become difficult to pin down the exact location of physical data and thus determine how outages could affect accessibility of that data.

EMC’s move towards Automation

Here is an example illustrating how data can be moved from one system to another based on policies.

Example:

• System One: Symmetrix V-Max SE running flash drives
• System Two: Symmetrix V-Max running 15K FC drives and 7.2K SATA drives
• System Three: CLARiiON CX4 running 15K drives
• System Four: CLARiiON CX4 running 7.2K SATA drives
• System Five: Centera running archivie
• System Six: EDL CLARiiON CX4

Today, the data movement between these boxes can only be accomplished using data migration techniques involving things like zoning switches and creating host groups and permissions within CLARiiON platforms. For data access on a V-Max system, customers will need to perform zoning on switches and provisioning and allocating storage on the required host. As for the Centera, it would need to be configured with archiving settings, and the EDLs would require backup configuration. There is no automated data movement today between these subsystems that can physically move the data based on logic.

However, EMC could make these migrations a piece of cake by creating a new version of FAST that enabled data movement using policy-based software running on the common hardware engine. This could reside on a hardware engine that sat outside of the system on the fabric. It would provision data on demand and enable data migration from system one to system two and so forth based on user-defined policies.

A simple example of such a policy would look like the following:

1. If data is on Tier 1
   1. If >14 days, move to Tier 2
   2. If >30 days, move to Tier 3
   3. If >90 days, archive to Tier 4
   4. Back up every day

A migration example would look like the following:

1. System one LUN 10
2. Move data to system two LUN, select AutoDestination
3. Match tier system one LUN 10 to system two LUN AutoDestination

The above are truly tiers of data and not associations with subsystems. So your data is freely moving towards the cheapest storage (automated) based on policy. Isn’t this automated ILM? Isn’t this what Atmos aims to accomplish with private and public clouds?

The problem this poses is that the policy engine has to logically sit in the middle of the storage environment – between the HBAs, the switch and storage interface. The only way to accomplish something like this would be through some sort of intelligence built into the fabric. This sounds confusing and may be unachievable if policy engines have to be deployed throughout the storage environment, requiring every storage subsystem to have hardware based policy engine.

One possible approach is having a policy based engine and agents or APIs on storage arrays (a software feature) to accomplish the same result. These APIs may provide the necessary interfaces for the policy engine to report and perform automated task as instructed and preconfigured by the users. With the help of Cisco and other storage vendors, EMC should be able to accomplish this very easily.

The use of CMDB will drive this innovation and help discover, manage, implement and provide reporting with SAN / NAS / CAS devices with one centralized database. All of this information can be replicated to other policy engines in the environment for redundancy.

While editing this post, Steve Todd released a blog post on The Center of a Private Cloud, again giving us some further clues into how the entire concept of CMDB might fit into device management and the policy based hardware engine. Following Dave Graham’s post and this recent post on The Register, one can detect an orchestrated move by EMC to set expectations on their next-generation products and features.

Other possibilities: Federation + Tiering + Security + Availability = Utopia

A policy-based engine handling aspects of tiering within a system is just the beginning. EMC is thinking outside the box, literally. The next logical step for them is federation within and between storage systems. For example, Atmos objects are copied, moved, and accessed based on metadata attached to those objects. Imagine adding a wrapper around the data so that information is both available and secure. With EMC’s ownership of RSA, this is a natural fit. As EMC moves away from monolithic architectures and to more modularized distributed ones, expect to see the ability for multiple systems to access objects be it file or block on other systems of the same type.

The underlying method of building what we discussed above comes down to economics and engineering effort required. Initially we would expect to see implementations that use many existing technologies (LUN or block migration, etc) but with more automation.

Summary

We think this is EMC’s strategic direction EMC, given the common hardware technology in the platforms released by EMC over the past few years. Take all of these platforms, roll them into similar hardware components, and use software to create a personality for each platform. This common hardware which will help reduce the hardware engineering cost, allowing EMC to focus more on software platforms (as they have been doing), enhancing overall the concepts of cloud, ILM, and free data movement. This is also what NetApp is doing with ONTAP. The difference is that EMC tiers would be distributed and modular rather than monolithic in terms of architecture.

So when should we expect all this? Not tomorrow, but in the near horizon. We all know for a fact that the storage industry requires a more-consolidated approach to storage over the next few years. EMC might just be there to deliver on it.

© Gestalt for Gestalt IT, 2009. | EMC’s Unified Platform and Storage Tiering
Read more posts categorized as Exclusive, Featured, Storage, Top Story

Update: As of October EMC has officially revealed the Atmos Online Compute Service, and it is as we suggested back in August.

EMC is a storage company, right? Not anymore! Under Joe Tucci, the disk giant from Hopkinton has been diversifying rapidly, with acquisitions like VMware, Documentum, RSA, and Smarts. But is the IT world ready for EMC’s next move? Is EMC itself ready?

EMC introduced Atmos, their platform for private and public cloud storage, in November. Now they are expanding this solution to include virtual servers as well, with Atmos becoming a complete package service providers can use to compete with Amazon’s EC2 and S3. This product introduction is EMC’s first foray into the server market, marking a major departure for the company. Will Atmos prove to be a minor addition to EMC’s portfolio or a step too far for the company and its partners?

Ben Linus on ABC's Lost found out what happens when the rules change. Will the introduction of EMC compute servers leave the company or its partners in shock?

The Atmos Problem

EMC launched the Atmos and Atmos onLine storage products in November of 2008 with a marketing splash. Many observers were puzzled at the time, trying to figure out how Atmos fit with VMware, Centera, and the storage products in the company’s product portfolio. One thing is clear: Atmos is not just another storage product line for EMC.

So what exactly is Atmos? Technically speaking, Atmos is a software product that transforms commodity servers and JBOD disk into an API-driven cloud storage platform. The Atmos offering leverages Dell servers, Gigabit Ethernet switches, and SAS disk shelves, but the hardware isn’t really an important element.

It is the business of Atmos that challenges our expectations of EMC the most. EMC still relies on storage sales for 80% of its revenue, yet Atmos presents a real challenge to that massive revenue stream. Although EMC has been careful to differentiate it from Celerra and Centera, Atmos can certainly be used in their place. Word is that Atmos has already replaced Celerra for basic bulk storage at a major EMC customer. And Atmos will soon also be out of beta as a true public pay-as-you-go service, Atmos onLine, both from partners like AT&T and from EMC itself.

EMC is in the cloud storage business and is actively seeking to expand this presence through private cloud and service provider relationships. This is a bold move for EMC, and it contrasts with their competitors’ timid “ammunition provider” cloud strategies. In the long run, the Atmos plan might be the salvation of the company, but it must be galling for the veteran EMC sales force.

The problem for EMC so far has been how to sell Atmos. These opportunities are said to be few and far between and focused only on the petabyte-scale solutions. The product was launched before there was a clear market in private cloud, and there simply are not many end-user customers who want to buy this sort of offering.

Introducing Atmos Compute?

Reviewers and commentators have long remarked that EMC’s storage base could be strengthened by adding additional capability, especially in the area of computing. We know EMC will be moving towards tighter compute/storage integration, but the company never before indicated that they will introduce their own compute platform. Now we know of two such compute products, and Atmos Compute Service is by far the most challenging for the company.

Widespread reports recently have talked of a joint VMware/Cisco/EMC datacenter product. This alliance even has a name: VCE. Enterprise Storage Forum quoted Linda Connly, EMC’s chief of staff and sales strategy, as saying ”we have been building an integrated ‘stack in a rack,’ which is essentially a virtual data center in one rack.” This seems to be a rack-scale integration of VMware ESX, Cisco UCS, and EMC storage, and was previewed at EMC World. The vPod (1.0) solution integrates EMC storage, Avamar, and ESX to provide backup service. Version 2 is in the works and is said to be a more-complete offering integrating Cisco UCS compute and 2950 switches and EMC V-Max with FCoE all tied up with Ionix/Smarts systems management. This VCE stack in a rack is a good, general-use roll-up of conventional solutions.

Now we hear that EMC is talking openly about launching its own cloud compute platform, called Atmos onLine Compute Service. Riki Fine of EMC’s Cloud Infrastructure Group presented an overview of EMC’s cloud infrastructure offerings last week at the Boston Cloud Services meetup. The presentation, posted at meetup.com, includes a slide (number 15, not marked as confidential) devoted to this Atmos onLine Compute Service, presented here:

It seems clear that this is a different product entirely from the Cisco-based vPod 2.0. We are presented with an integrated compute service similar to Amazon EC2 with persistent block storage like Amazon EBS. Looking closely, we see indications that VMware is used (as opposed to Amazon’s Xen-based EC2), which fits nicely with the vCloud concept presented at VMworld.

Since Atmos already uses commodity server hardware, EMC’s VMware ESX could easily be inserted to virtualize the stack, providing both storage and compute power. As a software product, Atmos (storage) could run within ESX on the same hardware alongside customer compute processes.

It looks like EMC has put together a compelling alternative to EC2:

• They (probably) use VMware ESX, which is more common and familiar than Xen. Atmos Compute Service might even be able to handle existing ESX instances migrated in from private servers!
• Atmos onLine storage supports NFS in addition to the Atmos API, unlike Amazon’s own S3 which is API-only.
• They offer VLANs for enhanced network security, which Amazon lacks lacked until the introduction of VPC.
• They seem to offer per-instance internal persistent IP addresses, another area of frustration for EC2 users.

In short, Atmos onLine Compute Service looks like a real Amazon EC2 challenger.

How Will Atmos Compute Be Sold?

One key question to be answered about Atmos onLine Compute Service is the go-to-market approach. The Boston slide deck places Compute in the “onLine” section, differentiating it from the Atmos products available directly to private/internal corporate users. We expect Atmos Compute to be initially rolled out by EMC itself as part of its Atmos beta program, with a major service provider following shortly.

Will AT&T sign up? They were the pilot customer for Atmos onLine storage, but Compute Service would seem competitive with AT&T’s own Synaptic Hosting offering. Perhaps one reason for the long gestation of this Atmos element is the lack of a partner or ISV for the launch? Given the VMware connection, we’ll be scanning the booths at VMworld in September.

The biggest weakness for Atmos storage thus far has been integration with third-party applications. EMC’s partnerships with application vendors are not strong at the moment, and certainly not in the spaces where API-driven Atmos storage might play. An application ecosystem is more likely to develop if EMC delivers its own Amazon EC2 and S3 competitor platform, especially if it is powered by a SpringSource-infused VMware.

It is extremely likely that Atmos Compute Service will be offered to enterprise customers building their own internal clouds. The cloud strategy of EMC and VMware presents a federated private/public cloud hybrid approach with applications and data moving between internal infrastructure and service providers with ease. This was one reason the company introduced Atmos as a storage platform: To seed their biggest enterprise customers with a cloud federation platform. Therefore, it seems very likely that EMC will soon be providing cloud compute servers to enterprise customers.

Changing the Rules

The availability of Atmos Compute to corporate IT customers places EMC in direct competition with HP, IBM, Dell, and even Cisco in the battle for server dollars.

Assuming it is not simply a branding of the VCE stack, Atmos Compute could be a game-changer for EMC. They already compete bitterly with HP and IBM for storage dollars, so entering their core server space poses little risk. Since it is based on Dell hardware, the suggested Atmos Compute product should not shake their long-term EMC partnership, and a Dell-branded version might even result.

It is the EMC/Cisco relationship that poses the biggest potential issue. Cisco has a history of game-changing product introductions, including their line of storage switches and the UCS server hardware. Cisco has remained willing to work with other storage vendors, announcing it selected NetApp for internal IT. Finally, rumors are flying that Cisco is preparing a storage array of their own for introduction next year.

Atmos Compute could be a response to this: A major rift could be forming in the EMC/Cisco alliance. Many have suggested that Cisco could buy EMC, but it seems more likely that EMC will try to become an integrated datacenter infrastructure provider, competing with Cisco, HP, and IBM.

Cisco is positioning UCS as the best platform upon which to run VMware for cloud/service provider environments due to its strong focus on multi-tenancy, RBAC, etc. Atmos Compute, coming from VMware’s own parent but on a different hardware platform, could be seen a direct competition. Perhaps Atmos Compute might be even more challenging for Cisco than the likes of HP and IBM, since it is positioned specifically for cloud environments.

This represents a major shift for the IT industry in general and the storage industry in particular. EMC has long been the standard-bearer for enterprise storage, but this move raises many questions:

• Does ownership of VMware give EMC a competitive advantage over the others?
• Since this move sounds like something Paul Maritz would come up with, does this make him the heir-apparent to Joe Tucci?
• Does this make a Dell/EMC or Cisco/EMC merger likely?
• Might a new wave of acquisitions result, with NetApp, Brocade, Citrix, and others scooped up and integrated?
• What does this assault by fully-integrated datacenter providers mean for the smaller storage, network, server, and virtualization vendors?
• Most importantly, how will customers react to EMC making a play for their server dollars?

We will be closely watching these developments!

In case you were wondering, EMC is not ready to comment on this product. The official EMC PR response follows:

“Today, EMC provides customers with the cost and flexibility benefits of cloud computing offered from the world’s leader in information infrastructure–building upon our expertise in information security (RSA), virtualization (VMware) and Cloud Infrastructure Services such as the recently introduced EMC Atmos onLine Storage Service. EMC doesn’t comment on futures or product roadmaps, but you can expect EMC to continue innovating to help customers maximize their information and virtual infrastructure IT environments.”

© Gestalt for Gestalt IT, 2009. | EMC Changes the Rules with Atmos Compute
Read more posts categorized as Cloud Computing, Exclusive, Featured, Networking, Server Virtualization, Storage, Top Story

So let’s say a customer decided to purchase a new V-Max system from EMC today. What would they get?

• They would get a freshly-designed cabinet, controllers, and firmware with more cache RAM, faster CPUs, larger disk drives, and support for all of their existing Symmetrix DMX features. Beta customers actually had both components late last year, and customer orders are proceeding. So it is safe to say that the V-Max clustered array itself is currently shipping. Note that the maximum configuration is 8 engines, each with a quad-core CPU, 128 GB of cache RAM, and 16 each of host and drive channels.
• Like the DMX before it, the V-Max supports a variety of disk drive types, from flash to Fibre Channel to Serial ATA. The larger so-called enterprise flash drives (EFDs) also appear to be shipping this quarter.
• Automatic provisioning with templates and management is available now as well.
• Virtual provisioning (thin provisioning and non-disruptive relocation) are enabled and shipping, but they’re mutually exclusive (see more below).
• PowerPath/VE and vSphere Storage plug-ins are shipping, even though VMware vSphere 4 was just released.

So our V-Max customer would be able to buy and deploy a solid, scalable, next-generation enterprise storage array that does everything they expect from existing systems and a little more. This is more than many new or re-engineered storage products can boast.

But our customer does not get everything that has been talked about regarding the V-Max architecture. What don’t they get?

• Future protocols like 10 GbE iSCSI and FCoE and 8 Gb Fibre Channel are not shipping yet. No surprise there.
• One of the most important components of V-Max is its fully-automated storage tiering, called FAST by EMC, which will not be fully realized for years. This technology is a major departure for the Symmetrix, which has long had the capability to manually move volumes but lacked the sub-LUN granularity needed to truly take advantage of the newest storage technologies like flash SSD. Although EMC plans to release “FAST v1″ during the second half of this year, this functionality merely automates the existing LUN relocation capability of all current Symmetrix arrays (for non-thin-provisioned LUNs) and is nowhere near the promise of FAST. Full FAST will not ship until 2010, and we suspect it might be well into that year.
• True Virtual Matrix mode, where multiple V-Max array “clusters” link together virtually to form a system larger than 8 engines. EMC has also talked about extending this mode over distances, creating a geographically dispersed array. None of this is coming any time soon.

So the answer to the core question of whether the EMC Symmetrix V-Max is shipping is yes. Customers can go out and buy one. But they will not get all of the functionality discussed and presented by EMC and its representatives last month.

Not So FAST

Fully-Automated Storage Tiering (FAST) is one of the most significant capabilities of the V-Max platform. As described, FAST will not be available for a year or more. This is not a secret or a scoop – EMC is the first to admit that FAST was pre-announced and is “Coming Next”!

V-Max's FAST technology "automates movement and placement of data based on changing needs" (illustration courtesy of EMC)

What is FAST? It is an automated tiered storage technology that can place data on different tiers of storage based on requirements. High-performance data on flash, bulk data on SATA, and so forth. EMC V-Max marketing materials, and the launch content, spent much time focusing on this technology, telling us that it automatically adjusts tiering of data, not just volumes, and reacts as needs change, rather than statically placing data. We’ve reported some confusion about just how FAST accomplishes this in the past, but we all agree that this would be an awfully nice way for an array to manage data.

At the core of FAST is EMC’s recently-introduced virtual provisioning technology. Why is FAST so much better than VP, and other competing automated storage tiering technologies? According to EMC blogger, Barry Burke, FAST has five key benefits:

1. Change RAID protection types as LUNs and volumes are relocated
2. Relocate a large number of LUNs and volumes concurrently
3. LUN and volume relocation is very quick
4. LUN and volume relocation has low performance impact on the array, and on the applications using the data being moved
5. LUN and volume relocation is done without disrupting replication

Let’s give EMC some credit for its FAST vision, as well as the pieces that have already been shipped. But we’re still quite a way off from seeing this FAST vision realized in production technology:

1. Current DMX and V-Max hardware allows customers to use multiple drive types, including flash SSD EFD, for over a year. Many other vendors are just now getting around to shipping flash disks. No one would claim that this is “FAST”.
2. Current DMX and V-Max also allows thin provisioning (a component of EMC’s Virtual Provisioning). This isn’t FAST either.
3. Current V-Max software allows customers to non-disruptively relocate volumes between disk and RAID types (another component of Virtual Provisioning). This is very nice to have. But this is not fully automated storage tiering. It’s just easier storage tiering. And it doesn’t apply to thinly-provisioned volumes.
4. FAST V1, which EMC plans to ship in the second half of 2009, will automate the selection and migration of volumes to different disk and RAID types. Although this is technically fully automated storage tiering, it does not quite live up to the promise of FAST as described by EMC at the V-Max launch. And it still won’t support thin (Virtual Provisioned) volumes!
5. Finally, EMC claims that they will fully realize the FAST vision with FAST V2, which will ship in 2010. This would enable granular (sub-volume) tiered storage for thinly-provisioned volumes.

Why does it matter that EMC won’t ship FAST V2 until next year? Simply put, anything less than FAST V2 will still not effectively utilize the expensive EFD capacity paid for by EMC customers. Even FAST V1 will take up expensive high-performance flash capacity with the entire contents of a LUN, including empty space! Customers wishing to conserve EFD capacity will use virtual provisioning to only store “used” data on flash. But these cannot be easily relocated if demand does not meet expectations, and not all of that used data requires high-speed flash storage. EMC also lacks thick-to-thin (or thin-to-thick) technology, though we suspect they’re working on that.

So customers have a choice: They can either use their EFDs more efficiently with thin volumes, or move data between EFDs and disks as needs change. They cannot have both.

An open question is how much EMC will charge for FAST V1 and V2. Assuming they are like Apple with the iPod Touch, and their history affirms this, EMC will charge for FAST as each major new capability is delivered. EMC has always charged for major new features. This is due to accounting rules which prohibit a company from charging customers ahead of releasing major features. The only way around this would be for EMC to recognize V-Max revenue as recurring over time, as in the case of the iPhone at Apple. Fat chance of that! Note that EMC is also talking about bringing FAST to CLARiiON and Celerra, but those timetables are not disclosed.

How Big Is Your Virtual Matrix?

Many have wondered about EMC’s choice of a name for this new storage system, some speculating that since the “V” stands for “virtual”, the V-Max was designed for server virtualization environments. EMC CEO Joe Tucci’s comments at the V-Max launch seemed to indicate this as well.

However, while it certainly is targeted at VMware vSphere and similar systems, the “V-Max” name actually has a very specific, and very different, meaning. “V-Max” is actually a reference to EMC’s new “Virtual Matrix” architecture, which allows V-Max engines to combine into a scale-out array with a virtual matrix of interconnects. Like FAST, the Virtual Matrix Architecture is the real vision of revolutionary storage from EMC. And like FAST, this vision is nowhere near being realized.

V-Max is so far being sold as a stand alone machine, not a scale-out cluster. At current GA, EMC is only offering 8 engines that are part of the same system cabinet (physically connected through MIBE and SIB), but there is nothing available that would connect 2 of these system cabinets, where instead of 8 engines you are now running 16 or 32 engines, forming a real V-Max. 

The V-Max name refers to the Virtual Matrix architecture of the array cluster (illustration courtesy of EMC)

EMC’s “vision” clearly extends well beyond 8 engines and a single V-Max.  EMC’s design allows for a federated set of V-Max machines that can all be managed as a single entity, and the company alluded to this in their product introduction.  They suggested that these separate V-Max machines wouldn’t even have to be in the same place, physically.  

Although the vision articulated at the product’s introduction talked about massive scaling in multiple locations, EMC’s maximum current configuration for the V-Max is 8 engines with up to 128 Xeon CPU cores, 1 TB of RAM, and 128 each front-end and back-end storage interfaces linked to 2,400 disk drives. This is no tiny system, to be sure, easily doubling the current DMX-4 array’s scalability as well as besting the competition. In fact, EMC can rightly claim that a V-Max can be configured today to be the largest integrated enterprise storage array available.

But 8 engines linked by local RapidIO connections in a single data center isn’t a revolution. The revolution happens when EMC realizes its vision of linking “dozens” of engines, thousands of ports, and tens of thousands of drives into a geographically dispersed system. Former EMC executive, Dave Donatelli, now controversially linked to HP, claimed that the V-Max can support up to 256 engines in a product launch video that has now been removed. IDC analyst, Benjamin Woo, talked about EMC’s ability to support a “single namespace” across geographies during his launch coverage. EMC’s Chuck Hollis says that “the overall architecture can eventually grow into literally thousands of ports, thousands of processing cores, tens of thousands of disks, and many terabytes of cache memory — all operating as a single, tightly-coupled array.” EMC’s Barry Burke also suggests that future revisions to the Virtual Matrix architecture could scale well beyond anything hinted here.

Again, in that same post, EMC’s Hollis tells us that the architecture delivers four key benefits in terms of scalability (bulleted for your pleasure):

1. “The difference between the two?  The V-Max can grow and grow from that modest starting point — still capturing the economics of mid-tier arrays and linear cost scaling.
2. Second, the V-Max array isn’t limited to a single cabinet with short wires.  Think in terms of multiple cabinets, separated by many meters or — in the future — longer distances using optical connections – all behaving as a single, giant array.
3. Third, the scaling is utterly linear and modular.  As more building blocks are added, the array gets bigger and bigger, and there’s no need to replace the frame, buy a bigger cabinet, etc. — nothing gets thrown away.
4. Fourth, there’s no assumption that all the building blocks are exactly the same.  Some may be big, some may be small, some may be old, some may be new.”

So a reader would look at this and think to himself, “this new V-Max starts as cheap as a competing midrange array and can scale out with different building blocks to span my entire data center, or even my entire enterprise.” This is a great promise, and awfully near to the holy grail of enterprise storage.

The problem is that none of this is possible today.

1. The V-Max starts at “about $250,000″ for a single engine. This is much, much more expensive than competing midrange arrays. It has to be, since a single V-Max engine has a lot more horsepower and componentry than any midrange array!
2. All V-Max connectivity is currently done with RapidIO connections in “a single cabinet with short wires.” Perhaps you could define “cabinet” differently and claim that the V-Max uses multiples, but no one (especially an EMCer who wants to keep his job) would suggest that the V-Max engines can be “separated by many meters or … longer distances.” When Chuck says this is “in the future” he means it!
3. V-Max scales to 8 engines, and initial reports are that scaling is indeed fairly linear. So this is a fair statement. But what if EMC replaces RapidIO with InfiniBand or datacenter Ethernet? Would there really be no need to “throw away” components?
4. There are no “big”, “small”, or “old” V-Max building blocks. They’re all new, and they’re all identical, and you can have up to eight of them. EMC says you will be able to mix and match once new building blocks come out, and we expect them to live up to this promise.

So even today’s V-Max system does use the Virtual Matrix architecture. It’s got a virtualized matrix interconnecting the engines, after all. But it’s nowhere near the scale-out promise of the Virtual Matrix concept. That’s quite a ways off still.

Conclusion: V-Max Is Not Overtaking The Future Yet

It is important to note that EMC sales literature does not claim capability beyond what’s currently on the truck. The V-Max data sheet, for example, makes no mention of FAST or scalability beyond 8 engines. And EMC’s Dave Graham is characteristically straightforward listing what’s in the box. In fact, EMC’s official web site and literature probably errs on the too-cautious side: A casual visitor might well ask himself, “where’s the beef?”

Why might an average storage buyer think there is more “beef” to be had? One only needs to watch EMC’s V-Max launch, and the surrounding coverage. Indeed, EMC’s own theme for the launch was “Overtake the Future!” EMC’s customers expected a revolution, and a revolution is what the company promised.  This isn’t anything new, unexpected, or even out of place. Companies often tout the theoretical future capabilities of their new products but don’t deliver on those promises for some time. Many have accused Microsoft of using this tactic to combat Windows competitors, for example. And let’s not forget the industry’s fascination with legendary vaporware products!

But the company’s boosters seem to want to have their cake and eat it, too. They’ve poured on the verbiage describing FAST, and used this future capability to declare victory in the battle against the likes of HDS, 3PAR, and Compellent. EMC’s Hollis tells us that “there’s nothing remotely like V-Max in the marketplace today”, and other EMC folks have made similar claims. As Wikibon points out, “EMC’s pre-announcement of Fully Automated Storage Tiering (FAST) is an admission that without FAST the answer is essentially no, EMC can’t compete on cost.” In other words, EMC was forced to prematurely unveil their FAST vision to keep their customer base from jumping ship to competitors already offering similar functionality. The same is true of the scale-out capability of the Virtual Matrix architecture.

For now, EMC has merely introduced a solid next-generation enterprise storage array. V-Max without FAST and scale-out is a nice-to-have refresh of the Symmetrix DMX-4. EMC should be especially respected for leaving all of the core Engenuity features like TimeFinder and SRDF intact, since this must have been no small feat. V-Max with FAST V1 is a more attractive proposition, but does not go that far beyond the capabilities of Symmetrix Optimizer. The same can be said of the 8-engine V-Max limit – it’s larger, but nothing to get too excited about.

V-Max with full-on FAST V2 and multi-site heterogeneous scale-out is the real revolution in EMC storage. If everything plays out, you could have several V-Max systems in the same data center, or perhaps even different data centers, all being managed as a single entity.  Then layer FAST on top of that (at the block level), and you have something unlike pretty much anything else on the market today. The question is, when can they achieve this, and will some of the other vendors catch up in the meantime?

This is what observers, analysts, and customers were looking for. And this is what they might think they saw. But in reality, we’ll all just have to wait another year or two and see what develops.

© Gestalt for Gestalt IT, 2009. | EMC Symmetrix V-Max: When Does It Get FAST and Virtual?
Read more posts categorized as Exclusive, Featured, Storage, Top Story

VMware's Simplified licensing for vSphere includes four basic tiers for the enterprise plus two more for small business

Consult VMware’s vSphere 4 Pricing, Packaging and Licensing Overview for yourself and let us know what you think! A poll at VM/ETC shows that readers are decidedly positive. Eric Siebert put together a nice overview of licensing options for TechTarget, as did “the other Scott Lowe” for TechRepublic.

Stephen

The more I think about vSphere’s new tiered licensing, the more I think it’s a big mistake. I understand that there are always compromises involved with licensing and bundling, but I think VMware might have pushed the tiered model to an extreme. Rather than a few tiers and lots of options (as in ESX 3), VMware has created a simple system with six tiers. Want fault tolerance with continuous availability? You have to buy Advanced or above, bundled with the new Data Protection and priced $1,500 more than Standard.

It’s a very typical predicament to anyone who has purchased a car: American makers often let buyers customize their vehicle down to the smallest detail, with dozens of factory option line items, while Japanese makers offer just a few trim lines with bundled features. Want a V6 in your Honda Accord? You have to buy the EX model at least, complete with a premium audio system and fog lights. Honda does this because it’s easier and cheaper to manufacture and distribute standard car models. But Honda is selling hardware, not software!

VMware seems to be copying Microsoft’s Vista: Offer a limited functionality version that appeals to no one apart from its price tag but make users step up to more costly versions to get essential functionality. But Microsoft made a mistake that VMware might also be copying: They restricted desirable features to the top-of-the-line Enterprise and Ultimate versions, resulting in reduced impact and appeal for the product.?When I bought Vista, I had to buy Ultimate in order to get Media Center, EFS, and RDP.

Now consider the VMware vSphere license tiers:?I can see people buying Enterprise Plus just for PSA/PowerPath or Enterprise just for DRA and wishing they didn’t have to step up.?Restricting exciting new technology like third-party multipathing to Enterprise Plus, for example, will greatly diminish its appeal, reduce the installed base, and discourage vendors from developing plug-ins for it!

Although I am glad VMware added a low-cost small-business tier, I think they missed out by not offering a functioning system (without support) for free. Right or wrong, Microsoft is making hay with their claim that Hyper-V is (financially) free, and VMware missed an opportunity to respond. It also makes it very hard for the smallest businesses to experiment with VMware by putting a base price on the system.

Note that the Enterprise level might be going away at the end of the year, forcing all businesses to upgrade to Enterprise Plus!

Martin

I can see the hand of EMC very much in this; ever since Diane was removed, VMware feels more and more like a part of EMC. Even more so than when they were actually part of EMC.

However, tiered license models where you pay for features is becoming increasingly common; we only have to look at what goes on with the desktop apps, you often have a Pro version which adds features and not just scale.

But, vSphere is not a desktop product; I would prefer a license model where you license the features that you require for the capacity that you require. Actually I would be happier with a model where all features are available and you just license for capacity. It simplifies the model, it could get very complex to manage.

For example; my development cloud might have different licenses to my production cloud but in my production cloud, I might have different tiers of app and will I need to actually segragate my production cloud into multiple tiers?

If VMWare are serious about positioning v-Sphere as an OS; they might be as well to look at some of the other enterprise OS providers and some of the experiments that they have tried. IBM in their lunacy stripped out X-Windows and C from AIX in one release and tried to charge for it…it didn’t take and it is part of the OS again.

This license model might have some interesting impacts; for example, smaller shops which want the features but do not want to pay, may look to alternatives…be it other products or public-clouds. Or perhaps third-party add-ons which replicate the functionality of the more advanced editions of vSphere and the support headaches that will bring to both VMware and the end-user.

I’m glad I don’t have to work this out…VMware is the best product out there today and it has an incredibly passionate and loyal userbase but there is competition out there and pragmitism may force people to look elsewhere.

Scott

VMware should have pushed VMotion down the stack. This would sweeten the comparison between VMware and other “free” alternatives that will include (Hyper-V R2) or already include (XenServer) live migration.

Host profiles don’t belong in Enterprise Plus. They should have gone into Advanced or Enterprise. Yes, large organizations will benefit the most from host profiles, but others want it too.

Third-Party Multipathing shouldn’t be an additional licensed fee. As I understand it correctly, you’ll still have to pay the third-party for the actual software (i.e., you’ll have to pay EMC for PowerPath/VE). So what is VMware giving us here? The “ability” to use third-party multipathing? Charging extra for that isn’t the best choice, IMHO.

What’s up with Advanced having a 12-core limit, but Enterprise having a 6-core limit? Because existing VI3 Enterprise customers will be grandfathered into vSphere 4 Enterprise if they have active SnS, this strikes me as nothing more than an attempt to extort more licensing fees.

Even though I clearly disagree with some of their licensing-related decisions, I can kind of see where VMware is coming from on this one. Since every VI3 Enterprise license with active SnS (Support and Subscription) will be grandfathered into a vSphere 4 Enterprise license, VMware needed some way to generate license revenue. So what’s the best way to handle this? How does VMware recoup its development costs? Increase SnS fees? There would be backlash against that as well. If we are going to make a big deal out of how VMware handled this and say that we disagree with it, then I think we also ought to be willing to provide suggestions on how it should have been done. It’s kind of like saying, “Don’t discuss the problem without also discussing a solution.”

Rich

It seems to sit better with me if VMware would offer vSphere hosts (classic and ESxi 4) for free and then license the features individually with editions of vCenter. This puts VMware more in line with the competition and hopefully helps recoup some development costs.

Personally, the argument I’m hearing from VMware (the podcast) is that no one else has these features. This is true, but it can come across to some as gouging. If the only gas station in town gouged on gas, what if everybody decides they are going back to walking for a while until somebody else opens up to compete?

Time will tell, and then will VMware customers have a bad taste in their mouth over this period?

Conclusion

We all agree that licensing is imperfect, and that there were bound to be flaws no matter what VMware decided. Yet we all see serious negatives in the specific implementation chosen by VMware for vSphere 4:

• Certain features like third-party multi-pathing and host profiles are misplaced in the stack regardless (See Vinternals post for more)
• We would generally prefer a base + options system over a tiered system
• The lowest-end product is still too expensive for labs and the smallest businesses
• Time will tell how customers react, and if the forced march to Enterprise Plus puts off business customers

VMware needs to make money on licensing, and they deserve it. They’ve put together an excellent product, after all. But they are risking their market position by relying on such strict tiers!

© Gestalt for Gestalt IT, 2009. | Is Licensing Turning vSphere Into Vista?
Read more posts categorized as Exclusive, Featured, Server Virtualization, Top Story

As large organizations begin to look towards cloud computing, many find themselves questioning the suitability of the infrastructure for their business needs. As consumer-focused services like Carbonite lose data and startup-focused systems like Amazon EC2 and Microsoft Azure suffer outages, the image of the cloud has darkened. How are providers protecting the data? What RTO and RPO is offered? Are these sufficient for the types of applications being considered for the cloud?

Cloud computing providers must�address these issues, put the right systems in place,�and then price their services properly if they are to succeed in the enterprise.�All of the normal systems management disciplines must be included, whether it is by the public cloud provider or by the internal departments using it. The cloud being a by its nature an amorphous and fuzzy entity is going to put greater demand on some of these disciplines: Capacity planning and performance management, for example, become a degree more difficult with such an entity.�The key challenge for cloud providers is not offering enterprise-grade governance but maintaining the pricing edge they have over in-house infrastructure.

This is a major limiting factor to the acceptance of public clouds in the enterprise space. Until a public cloud provider’s service includes customized SLAs that allow their customers to match things like�RTO and RPO for their applications that are running there, enterprise applications will not use these services. It is likely that many of these issues will be resolved in the private cloud first,�since they will be run by IT pros that are used to dealing with these issues and already have these governance systems in place.

© Gestalt for Gestalt IT, 2009. | Governance And Peaks In The Cloud
Read more posts categorized as Cloud Computing, Exclusive, Featured, Top Story

CC-by-SA 2.5 image "Golf Bunker" by Ken123

Today, many companies are considering a compete migration from a physical to a virtual infrastructure. Based on the promises of cost savings, administrative efficiencies, and improved resource utilization, virtualization is seen as the technology that makes it possible to do more with less. However, there are many pitfalls to consider when virtualizing server infrastructure. This article suggests planning decisions to be considered by the CIO, IT Director, design architect, and IT Manager that, if overlooked, could ruin the total cost of ownership (TCO) and the return on on investment (ROI) expected from this virtual infrastructure.
�

Migration pitfalls

Implementing virtualization is not a simple process of building a server. Too often, management makes the mistake of expecting that the administrators and architects of the server team will be solely responsible for virtualization decisions. In reality, the impact of a move to virtualization should be viewed exactly as if a company were moving their physical servers to a new data center. Storage, networking, security, Active Directory, messaging, web presence, and all of the systems and services necessary to the organization must be considered together. Some of these groups should be more involved than others in the actual planning and ultimate design decisions, but virtualization strategy affects everyone. Key members from all of these focus areas must be trained and given panning responsibilities to achieve a collaborative plan and design.

A potentially larger “gotcha” once everyone is involved in the planning process is the temptation to include all of the upgrade and service redesign projects that have been “in the queue” for months (or longer). Although the migration may seem like a great opportunity to upgrade to the latest operating system, separate instances from poorly performing database servers, or build the new CRM system, these added activities bring complexity and could pose road blocks to the core goal of the virtualization initiative: consolidating hardware. These projects should be tabled and taken on later, after the new infrastructure is in place. In fact, the flexibility of a virtual infrastructure will actually make these projects simpler.

Performance pitfalls

Condensation of numerous physical servers into a virtual environment is intended to increase the effective utilization of processing power and other system resources, but it is easy to overshoot the target and overload the new system. Although the average load of a number of servers might be within the capabilities of a new virtual infrastructure, resource spikes can be a serious problem. Consider that periods of high demand tend to cluster across servers through the day and week, as employees begin the workday, the backup process begins, or a software build is kicked off. If performance is not measured and correlated carefully before migrating to a virtual infrastructure, these resource spikes can make the new infrastructure unacceptably slow.

One often overlooked performance challenge is the randomization of demands introduced by virtualization. Traditional computer design assumed that processes would proceed through their steps sequentially, with the system devoting resources from start to end. Multitasking operating systems challenged this assumption, but the allocation of memory, I/O, and storage remained clustered. But highly-utilized virtual servers upset this predictable flow, rapidly switching from one task to another entirely different one. In short, virtualization randomizes accesses that were once sequential and transforms large requests into many tiny ones. CPU manufacturers have responded with clever techniques to save and restore registers and handle memory mapping, but this blender effect is far from solved. I/O and storage systems are particularly affected, as they are optimized to stream large sequential operations rather than small random ones.

Storage pitfalls

Although one might think that virtualization reduces storage requirements as systems are consolidated, the opposite is often true. Many of the functions that help drive down CAPEX and OPEX costs in virtualized environments require the use of shared networked storage like SAN or NAS. Data that had once been scattered around the data center on internal drives is consolidated on these networked storage devices. Thousands of redundant copies of operating system files, for example, end up sitting on the storage array. The ease of creating virtual machines from templates tends to lead to virtual “server sprawl” far worse than in the physical world. Storage array capacity is also needed for swap space or paging files as well as popular enhancements like snapshots, DR copies, and backup images.

The result is a flood of redundant data that must be taken into account when planning capacity needs. Although storage is typically not the top item in an IT budget, virtualization can cause it to rise and chew up some or all of the savings from the project. It is difficult to avoid these issues, but some techniques can help mitigate the problem. For example, deduplication of primary storage and thin provisioning can help reduce the storage footprint of the virtualized infrastructure.

Administration pitfalls

Virtual sprawl can cripple infrastructure support teams if it is not managed. The challenge of administering this new virtual environment is often ignored in the implementation rush. Rather than managing 3,000 servers, many wake up and find that they are managing 30,000 virtual machines. This is partly because server build times are reduced from days to minutes, and partly because server consolidation on virtual infrastructure is so effective that idle guests are barely noticed. If left unmanaged, the “gasoline fire” spread of VMs could create a burden in the form of permissions, backups, upgrades, patches, and monitoring than what existed in the physical infrastructure.

To combat these scenarios, IT departments need to start with process and policies. Change control becomes paramount. Second in importance is a new server request and approval process. Build standards need to be created and adhered to. Finally, virtual servers must to be audited for activity and then powered off or removed if idle. The good news is that there are numerous life cycle management and automation tools now available for helping an organization provision, maintain, report, and decommission virtual machines.

Backup/Restore pitfalls

Backup is another area where TCO and ROI, as well as performance, can be negatively impacted by virtualization without appropriate planning. As mentioned above, virtual server hardware is often sized based on the average server load. For example, consider the impact of combining ten servers with average CPU utilization of just 10% onto a single physical device. The ROI would appear to be excellent, but the large spike in utilization that happens during backup can cause unacceptable performance issues or even application failures. The performance hit during backup can be mitigated through off-machine backup using like VMware VCB or storage snapshots, but the cost and effort of implementing these features must be taken into account when planning the new system. The conventional approach to backup, loading backup agents on each system and backing them up on a schedule, does not translate in the virtual world.

Disaster recovery pitfalls

One of the primary driving factors for moving to a virtualized environment is its potential positive impact on disaster recovery (DR). Although the DR benefits are real, the requirements for the storage system can become a pitfall. Extra DR data is pushed onto storage arrays and then often replicated to another location. All of this extra data requires increased storage capacity, array features, and WAN bandwidth. The capacity issues can potentially be addressed using primary storage deduplication and thin provisioning, and WAN optimization appliances can reduce bandwidth requirements.

While virtualization does make servers more portable, thus making DR easier, the disaster recovery copy process is a major challenge. Some vendors now have tools like VMware Site Recovery Manager (SRM) to assist in this orchestration, but these tools are somewhat immature, and care should be taken when planning to use them. For example, most do not address failback, so administrators may find themselves doing a lot of work to return to operation at their primary data center after a failover.

© Gestalt for Gestalt IT, 2009. | Planning for Virtual Infrastructure: Avoid the Pitfalls
Read more posts categorized as Exclusive, Featured, Server Virtualization, Top Story