Company Separation

do you have a charge back model right now ? If you charge customers based on tier of storage (whatever tiers you have defined) and capacity i am not sure i would start moving customers to their dedicated raid groups, spindles ..etc. That's my personal opinion ..let's see what other think.

does it mean there will be more then one array administrator ?

No, just me. 

As long as you somehow can keep track of whatever LUN belongs to which host and to which company that host belongs to, simply keep it the way it is. When one or both of the companies want dedicated performance, then you might want to move LUNs appart so they don't share raid groups anymore.

I would simply treat all LUN's and hosts the same and spread them out all over all raid groups, just like you would do when it was still 1 company.

If you have the space, you could always move lun's around with the built in lun migration and setup the DAE's so that only one companies data is on a certain shelf.  But that approach may require a bunch of unallocated space to work.

I have had to administer a CX3-80 before where tenets went out and purchased just the amount of DAE's they needed for thier data.  Once the array was full of DAE's, the next company that needed space then had to also purchase the SPE:)

I wish they would implement the ability to name the raid groups. That would also make it easier to find and carve new storage.

Another reason for the seperation by DAE is for performance.  Lets say one company has alot of high IO aplications and the other doesnt.  if you mix them within the same RG/DAE then you might cuase performance hits for one of the companies.

WIth the DAE seperation, one company cant complain that the other is slowing them down.

just my 2cents

Zainal,

A LUN is a separate enough segragation of the data for each business unit. Unless the business units require spindle separation, the LUN is a unit of storage that can securely be accessed only by the host masked to it. So with the data being on separate LUNs for each business unit the data is already segragated.

Now if you have LUNs that host data from both business units then you are looking at host based migrations to migrate data from one file system to another to achieve that segragation. Can you provide more detail on what needs to be segragated?

The ability to give RAID groups friendly names exist if you use Storage Pools and Virtual Provisioning. With FLARE 30 you will also be able to create thick provisioned pools (all with their friendly names of course). This gives you the ability in a situation like this to create pools for each company and carve up LUNs out of that pool for the company as needed.

So with FLARE 30 maybe we'll get to assign friendly names to RAID Groups as well? Not that they will be around much longer ;-)

Kenn,

Agreed, RAID Group separation and/or DAE separation would be ideal to isolate their data sets from impacting one another. Depending on the array configuration it may not be feasible to perform LUN migrations to achieve that separation without purchasing additional storage.

What we need to know is what kind of separation do the business units require? Since they have been one business unit up to this point the co-location of LUNs and/or data doesn't seem to be an issue from a performance standpoint.

> Not that they will be around much longer

What do you mean ? Are you talking about thin provisioning ?

The best solution would be to have 2 separate Clariions, one for each customer.

However..... this is probably not an option, but the next best thing would be to separate them by bus, so each customer has the best performance they can get in one physical Clariion (cpu and cache are still shared). If separating buses isn't possible, the next best thing is dedicated raid groups per customer. Dedicating complete DAE's has no effect as far as I know, since in the end it comes down to the actual raid group performance. For a visible separation using dedicated DAE's per customer indeed looks better

Just repeating rumors from the blogosphere that eventually we won't be using RAID groups any more and will just be using storage pools, thick and thin. Just rumors, but interesting....

RRR wrote: > Not that they will be around much longer What do you mean ? Are you talking about thin provisioning ?

The introduction of thick storage pools in FLARE 30 is supposed to be the first step.

Cool ! Can't wait

I found an article about that: http://www.daymarksi.com/storage-navigator/?Tag=FLARE%2030