Concurrent management of a 3PAR suystem

[RUET]

Hello

i'm wondering the behaviour of a concurent management of a 3PAR system.

By example, I've many peopel in charge of 3PAR management (VV, hosts creation ..)

What about if:

- many users from the same ICM (Console management) are connected to the same 3PAR and are sending some changes to the 3PAR

- many users from two different ICMs (Console management) are connected to the same 3PAR and are sending some changes to the 3PAR

- same question if we have CLI scripts running in the same time

I'm wondering about best practices with the number of ICM/CLI severs to implement and the process of a concurrent management of the same 3PAR system..

Thanks in advance

pat

[Dennis Handly · Accepted solution]

>I'm wondering the behaviour of a concurrent management of a 3PAR system.

Depending on your StoreServ model, there are a limited number of connections (min of 64) you can have.

But not all can be actively doing commands.

Each IMC may take 4 to 5.  The command showuserconn can show you how many.

>I'm wondering about best practices with the number of IMC/CLI to implement and the process of a concurrent management of the same 3PAR system

This all depends on whether you are just monitoring at the current status or actively changing things (creating snapshots or physical copies).

[RUET]

Thanks for the information

Our context is more based on 7400 systems

We have many team L1/L2/L3 which are able to monitor of course (I think there is no issue with this) but also to create LUNs, snapshots ... may be in concurency ..

As ICM is a java application, so depending of the content of the cache, I don't explain at the moment the behaviour of some concurent change actions on a single system (there is no lock as in Remote Web Console..)

[Dennis Handly]

>Our context is more based on 7400 systems

Depending on how much memory they have, the min is 96.

>As IMC is a java application, so depending of the content of the cache,

If you are worried about performance, this cache is on the host or some PC and doesn't affect the array.

>the behaviour of some concurrent change actions on a single system (there is no lock

sysmgr does the locking but you shouldn't be trying to change the same object at the same time.