SSSU Query

[SAKET_5]

Hi All,

I know some of you on this forum have a lot of SSSU expertise, so I thought instead of going too far with exercising my brain cells - I should consult the gurus first:)

Ok, so here is what I am trying to do:
114 Vdisks on one EVA5000 - replicate all these Vdisks to another EVA5000 using CA.
Now for DR purpose, under the assumption that the primary (source) array fails which would require me to present all the replicated disks to the original hosts. Ok, so assume I have zoned the hosts such that they now have access to the destination array and the "hosts" have been created and defined under CV-EVA for the destination array.

Now, I would still need to present the 114 replicated Vdisks to a large number of hosts including changing the "Write Protect" mode to "No". I am wondering if somehow I can automate this part using SSSU or something along those lines. I havent played with SSSU a lot yet...and hence this thread:)

Basically, just thinking out loud ...if I could store all the Vdisks on the storage system in an "array" (our Vdisk naming is "hostname_dg1_001") and then extract the "hostname" from the Vdisk name and then present it to the "hostname" and change the "Write Protect" mode to "NO".


All responses would be greatly appreciated.

Thanks,
Saket.

[Mark Anthony Harding]

Saket,
It sounds like you are trying to create a poor man's Continuous Access. I'm confident that you could accomplish your goal of changing vdisk attributes via SSSU, but Continuous Access (CA) software is the easiest way to data replicate in an automated fashion.

[Uwe Zessin]

Hello Saket,

I think you're fairly up to date on VCS, aren't you?

In that case I strongly recommend that you take a look at the RSM (Replication Solutions Manager). In some areas it provides MUCH better scripting features (e.g. error handling) than SSSU.

If you have seen it already, no: you don't need to 114 commands or more, it is possible to cut&paste from the script field.

[Ivan Ferreira]

With continuous access, the HOME and DESTINATION VDISKS should be always presented. At the moment of the failover, the eva "enables" the access to the vdisks.

We have a set of VDISK replicated with continuous access, and both evas has the same presentation. So, when you don't have to do anything before a failover.

See the CA administration guide, you will find that after you create the DR group, you must present the vdisks on the destination EVA.

[SAKET_5]

Guys,

may be I didnt furnish sufficient details...okay part of the problem is management's paranoia towards disk firmware upgrade on an EVA and thats why I have gone to the trouble of getting a temporary license for CA. We dont use CA for our daily operations. May be after this exercise, management might approve CA purchase, who knows!

So, the idea is I load the CA licenses - replicate the Vdisks from one array to the other - carry out VCS + Disk FW upgrade on the first array as backing up all the data on the first array in a timely fashion is out of the question. CA replication is just about mitigating the EVA disk firmware upgrade risks in our scenario at this stage.

Uwe, yes I have looked at RSM but the thing is I wont have the luxury of deploying RSM agents on a large number of hosts in the timeframe I need to upgrade the EVAs in. That will be a seperate change management issue!! I could install RSM Server component on the SMA, do you think it might help for what I m trying to achieve.

Yes, I agree in some respects its not the optimal way of CA configuration - but then what do you do!!

To the person who indicated that the Vdisks are presented by default - umm...from the tests I have done - the replicated Vdisks are not presented and are Write_Protected. Remember, I am not using RSM agents on the host, may be thats where the confusion is coming from.

Sorry guys, I might be missing something as well...so please ...all feedback is welcome.

Uwe, I know I can always count on your magical responses:)

Regards,
Saket.

[Uwe Zessin]

Ah, your migration project. Sorry, I didn't have that in my mind when I wrote the response.


You don't need any RSM agents on your hosts to present or unpresent virtual disks - at least that is my experience.

If this is a one-shot, yes, I agree that SSSU should be sufficient.


Remember that you can always take a "CAPTURE CONFIGURATION". In fact, I recommend to do that after *every* change to an EVA. If I remember correctly, you are also using Tru64 Unix. As part of a recover strategy I recommend to capture the output of "SHOW VDISK FULL" so that the LUN WWNs can be restored, just in case. That can make recovery a bit easier.

Take a look at the output of "CAPTURE CONFIGURATION". You can always take it, delete parts you don't need, change other parts as necessary and feed the changes to the same or another EVA.

I routinely use CV-EVA for single, one-time changes and SSSU for mass- changes. Once I had to create 30+ virtual disks in 2 EVAs and present them to 4 servers. So I created the VDs (very different names) on one box and did the mapping of all 30+ VDs to one server via CV-EVA. CAPTURE CONFIG to a file and make the changes to map all VDs to the remaining 3 servers. Another CAPTURE CONFIG and feed the commands to create 30 VDs and do 120 mappings into the second EVA - ... done! Time for lunch!

A few month later, the customer bought two more EVAs and more servers - same thing.

--
You can also pull object names via SSSU, e.g. SHOW VDISK, put the output in a file and later create real commands through the use of some tools (see attachment).

" \Virtual Disks\A1-TEST\DATA_A1\ACTIVE" ->
SET VDISK "\Virtual Disks\A1-TEST\DATA_A1\ACTIVE" WRITE_PROTECT