What the books DON’T tell you about moving from one platform to another

Hi Everyone,

This discussion is now open for you to post your questions, comments, and replies!

Thanks so much for joining in the discussion!

Good morning everyone, and welcome to what I've been told a few times already is a "slightly different" kind of Ask the Expert discussion. For starters, this one spans technology platforms (CLARiiON, VNX, Symmetrix) where so far these discussions have been focused on one technology. That is kind of the point of this though.

Just as some background, my own experience prior to implementing the DMX3s in our enterprise was almost entirely CLARiiON. Suddenly we had a new platform with new methods of management to learn and while some of the concepts were totally different, some of them were close enough to be confusing. I would have loved to be able to take a course called "Beginner Symmetrix Concepts for CLARiiON Experts", but nothing like that existed. Fortunately I found help here on the Support Forums and did A LOT of reading (not to mention some trial and error testing).

In remembrance of those painful days, this discussion will focus on what you may need to know moving from one platform to another (in either direction)... whether you already have that shiny new array on the floor and are still trying to figure out what to do with it or you are still considering if it is the right choice to fit in your support capabilities.

Dynamox and I are here to field your questions and hopefully ease your pain a bit in the transition.

Hello

So far, I knew about moving data from one platform to another is we can use OR to do it. Will you please make a brief discription about the difference among OR OM and SRDF in data moving?

Good morning zj and thank you for your question. I hate to say this with the first question to come up, but you've caught me a bit off guard. When we were planning this discussion we weren't really thinking of it in terms of migrating from one platform to another, but more how do you deal with a new platform in addition to the one you have (and are keeping).

That being said, most of my migration experience is within a given family. I have used SANCopy and host based migrations to go from CLARiiON to CLARiiON and CLARiiON to VNX. I've used SRDF and Host based migrations to go from Symm to Symm. We have done some limited migration from CLARiiON to Symm (and vice versa) but those were Unix hosts. Our Unix support team much prefers to do host based migrations when possible.

Some of the option out there that I have not personally used are Open Replicator & Open Migrator as you mentioned, as well as PowerPath's built in migration capabilities.

Dynamox may have more experience with these, so we'll see if he has anything to add. If not, we'll get Mark to redirect this question to someone else who may be able to provide more technical direction on data migration.

Hi experts,

I would like to know the biggest or essential design change from CLARiiON to VNX, from the perspective like performance, availability, scalability and flexibility. Looks like a big question...

Hello experts,

i have a question regarding the VMAX implementation. as i saw you both used to work on DMX & VMAX. My question is, when you plan the disk capacity, FA & DA design according to the front-end application( RDBMS, OS, VM host) during upgrading DMX to VMAX. is there any difference? as i know the performanc(CPU, memory) and new fearture (VP, FAST) is new in VMAX. will it be considered in your VMAX implementation?

Allen, you mentioned a course "Beginner Symmetrix Concepts for CLARiiON Experts" and I had to laugh about that. In a man's career this course should be a great on: moving up from midrange to enterprise .

But if your company decides to implement a DMX / VMAX while you're still running CX or VNX should have been discussed with you before they actually installed the big box in your DC, right ? So when the big box arrived, that shouldn't be a big surprise anyway, right ? I'd be thrilled when my employer would decide to upgrade from midrange to enterprise and I'd read a lot about the new "toys" and it's capabilities

Cool Allen,

Your cut and paste 阿超 is currect & cool which is a simplefied Chinese name :>)

Henry PAN

Hi 阿超 (I wasn't sure if I could actually cut and paste that, but I knew my keyboard wasn't going to let me type it)

That is definitely a loaded question, and there are a couple of different ways you could look at it. From an engineering and technology perspective I think the biggest changes are to the backend of the array with a shift away from FC drives to SAS and NL-SAS as the workhorse drive technologies. In the end this doesn't really make a huge difference to the end user though. From a customer/end-user perspective I suppose the shift from non-integrated block and file architectures to a much more integrated/unified design is a huge shift, but won't actually impact all customers. You can still use a VNX as a block only array and it really isn't going to be much different from using a CLARiiON.

In the end I have to say that for most users there isn't really a game-changing, life-altering difference between CLARiiON and VNX. I don't mean that as a slight to the engineers that bring us this wonderful new technology, but this is answering the questions from a purely practical average end user's perspective.

If you are moving up from an older model CLARiiON then you can gain functionality like Virtual Provisioning and FAST VP as well as FAST Cache capabilities and a some other bells and whistles, but really, if it were not for the hardware backend changes this would almost qualify as a "CX5" rather than a new product line. That's just my take on it though.

To keep that answer in perspective I will say that if you were asking me the different between a Honda Civic and a Porsche, I would tell you that for the average driver on average city roads with no special requirements, there isn't a whole lot of practical difference. That doesn't mean the Porsche isn't worth the extra money and can handle things that the Civic can't, but that really doesn't affect the average end user.

Thanks Henry,

Sadly I was have no idea what it actually says or how to even begin thinking about pronouncing it, but fortunately it didn't keep me from cutting and pasting :-)

Hi hotcap,

In many ways the VMAX platform can be treated very much the same as a DMX (or at least as the DMX3s I'm used to). That isn't entirely true if you are going to use Virtual Provisioning, FAST VP, etc... but for basic operation the biggest difference I found when we implemented our fist VMAX was the concepts of mapping and masking using masking views. Masking views are a lot more like the concepts of Storage Groups on the CLARiiON/VNX platforms, but with some added granularity and flexibility.

One of the major conceptual differences from the DMX to VMAX architecture was the removal of the full backplane being deployed up front on the DMX. With DMX you would deploy an array and then populate the backplane with a mixture of front end & back end directors as well as memory directors. With VMAX you deploy engines prepopulated with FE & BE directors and cache memory. You do have flexibility in the port counts and types for the FE side of things, but the directors are already there. When you need more directors (of either type) you deploy more engines and they connect through the "virtual backplane". Right now you can expand up to a maximum of 8 engines, but by making the backplane virtual I'm curious if we will soon be hearing about greater growth potential since there is no longer a physical chassis limitation (I've heard rumours, but wondering if there will be more announced at EMC World).

So up to now, (ignoring the VP & FAST VP) that means that even with the hardware platform changes there aren't a lot of differences in the way you plan deployment of hosts and applications on the array. Maybe if you have a super demanding application you might take advantage of some of the optimizations in the new architecture, but I suspect that type of deployment and optimization would involve EMC Professional Services for planning and validation. I'm talking more for the average user base.

All that being said, adding in Virtual Provisioning (which I believe was an option on the DMX4) and FAST VP (which I THINK is limited to VMAX) is a game changer from a planning and configuration perspective. When I qualify my thoughts on the DMX4 you should know that I've never worked on that platform so I'm just going by what I heard and think I remember. VP & FAST VP can fundamentally alter the performance capabilities, disk layout concepts, and provisioning best practices for hosts and applications. What I don't think it really changes is your front end connectivity for hosts (although I guess it could potentially require more FA ports to a host if you are really going to drive higher performance than you COULD before).I'm not going to go into deep dive detail on FAST VP as there are lots of white papers on it, but the whole idea of being able to spread your backend disk load much wider than we could easily do before, as well as adding in the automated capability to ensure that the autotiering has data sitting on the appropriate tiers to meet performance even when it changes over time...   Let's just say I've been looking forward to FAST VP on Symm for a while now, and will finally get to to put it into full play in the next few months (We've been using FAST VP on VNX for some time now).

You are right, RRR... it shouldn't come as a shock (although I talked to one admin once who found out when the vendor arrived onsite to do the install). In some ways I think some of the concepts might be easier to grasp for a less experienced CLARiiON admin moving up to Symm than to a moderate to very experienced admin just because there are things that you may have to unlearn to avoid incorrect assumptions based on your previous experience. I did a lot of reading and asked a lot of questions as well as taking SRDF and TimeFinder courses, but there was no more basic Symmetrix course like the CLARiiON & VNX ones. All the Symm courses were on specific parts of Symm technology (like TimeFinder & SRDF, or performance specific).

Yes, booting from SAN is probably one of the greatest sounding ideas that turns out to be almost more painful than it is helpful once you get into it. We try to avoid it as much as possible, although it tends to go a bit smoother on the Symms than it does on the CLARiiON/VNX line. Something to do with the active/active vs. active/passive pathing (or active/"sort of active" with ALUA )

Yep, I believe the backend architecture is the biggest change just as your answer. thanks a lot!!