The details behind VMAX Cloud Edition

Anytime there is a product with the name “cloud” it tends to stir up a lot of interest from customers & peers. On one end of the spectrum you have vendors that simply take existing products and rebrand them as “cloud” versions while others that actually make something worthy of the name “cloud”. I believe the VMAX Cloud Edition to be the later, albeit a first step towards the eventual goal of Storage As a Service, Software Defined Storage, Enterprise Cloud-Friendly Storage, <insert any buzz word here>, etc. But, what is it REALLY?

To summarize what is a VMAX CE: its a VMAX system, with a self-service portal, REST API support, chargeback/showback reporting and multi-tenancy built-in. It abstracts away storage requirements into a discrete number of “storage offerings” doing away with the traditional methods of provisioning and thinking around storage.

Architecture:

VMAX CE Architecture

VMAX CE Architecture

A few facts:

  • The VMAX Cloud Edition product is based on the VMAX10K hardware. This means 1-4 engines, D@RE (Encryption) capability, etc. One point to note however is that you can have up to 10 VMAX Cloud Edition frames running behind a single management interface provided by two management appliances connected in a HA fashion. These appliances connect via VPN to EMC’s datacenter as well as via FC to the array / switch fabric.
  • As can be seen above, the portal is actually located in EMC’s data centers. If you or your customer strictly will not allow connectivity externally, this product will not work. This may or may not change in the future to where it can be 100% hosted on-prem. But for now, this is a requirement.– the “consumers” of storage connect to EMC’s Data Centers via secure web access. The storage admins connect to EMC’s datacenter via VPN.
  • You cannot manage the VMAX Cloud Edition using Unisphere. You must use the self-service portal or the REST API. However, managing the VMAX CE through Unisphere would defeat the purpose of it in the first place.
  • From a front-end host connectivity perspective, all it supports is FC (Fiber Channel). There may or may not be plans to support iSCSI/FCoE in the future
  • You absolutely cannot upgrade an existing VMAX to VMAX CE
  • Chargeback style reporting is built-in with a granularity on a per-tenant basis (customer, business unit, department, etc)
  • The service catalog specifies the following storage offering, and each offering has a $/GB cost associated with when purchasing the VMAX CE: Diamond 3-4IOPS/GB, Platinum 1-3IOPS/GB, Gold .5-1 IOPS/GB, Silver .25 -5 IOPS/GB, Bronze .05-.15 IOPS/GB as shown below
VMAX CE Storage Offerings

VMAX CE Storage Offerings

As with any movement towards “cloud” based consumption there are two aspects: a technology enablement and a business process change. The technology enablement on the VMAX CE comes in the form of a portal, service catalog, REST API, chargeback style reporting and multi-tenancy. From a business process perspective, it allows customers to purchase the array on a $/GB basis instead of worrying about the cost of individual components such as drives, engines, cache, etc. To go from XXTB to YYTB on a VMAX may require and engine upgrade and its associated cost, but to go from XXTB to YYTB on a VMAX CE will carry a linear $/GB fee that is pre-determined based on the storage band regardless of what extra components are required beyond drives. Storage planning becomes a simple task of understanding the capacity requirements for each service level and immediately determining a cost — this is huge compared to how storage budgets are forecasted today. And lastly, by providing a service catalog (and REST API) for storage provisioning it allows customers to automate & orchestrate the storage tasks.

It is extremely important that customers turn their frame of thinking towards “service levels” and not RAID groups, # of 15K spindles, and so on to truly provide storage as a service. What will also be of tremendous help is when storage best practices white papers get re-written with service levels in mind and not specific storage configurations. For example, while a customer may buy a VMAX CE today, the Exchange 2010 whitepaper best practices still speaks in terms of # of spindles and an “old school” methodology of storage architecture — not in Gold or Silver bands ala VMAX CE verbiage. This can be a challenge when trying to translate an application architecture into a storage requirements in the above model. There is no doubt this is the way of the future in storage, but we have a long way to go until it’s status quo — Software Defined Storage is at its infancy.



Categories: EMC, storage, VMAX

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: