EVA Business Copy questions ...

[Chetan_5]

I have worked extensively in the past using BC with XP disk arrays. I now have to work with EVA disk arrays to design a backup/recovery strategy using BC and from what I understand the EVA is a totally different animal. I need some help with translating XP BC concepts to EVA terminology.

Is XP BCclone = EVA snapclone or Mirror clone? What is more suitable for backup and recovery? I know that snapclone makes the vdisk available immediately while its normalized in the background. Since the copy will be needed for backups, immediate availability is not required. So is MirrorClone a better fit?

What is a Container? I read documentation high and low but I still do not understand the requirement for a container. All I understand is that a creating a clone/mirrordisk is a 3 step process and container establishes the 1st step automatically.

Is SSSU aka RSM aka CLUI? I see different acronyms/tools being used in different posts. I know that SSSU is a host integration tool to run EVA commands. In the XP world, I had a command device zoned to my host and I understand in the EVA since there is no CMD device, the SSSU communicates with the SAN management hosts command view which in turn communicates with the array. Is this correct?

Procedure to restore from backup disk. In the BC world :
you unmount pvols, svols
run pairresync with -restore
change vgid, fsck and mount pvols

Is the procedure similar in the EVA world?

Thanks for your patience!! Points will be awarded generously !!

[Uwe Zessin]

The SnapClone does the copy after you have created it. After completion, you will have two completely independent VDisks.

You can think of a MirrorClone like two VDisks that are continuously synchronized. You can temporarily stop the synchronization and present the copy to a host, e.g. for backup. After that you can do a rather quick re-sync, because the EVA keeps track of changes made to the source VDisk.

The EVA's internal data structures are quite complex and allocation / deallocation of VDisks can take quite some time. For some operations this is not necessary, so the engineers thought about the idea of 'containers'.

You can turn an existing VDisk into a Container which makes all data inaccessible, but it does not deallocate the reserved space. Next, you can do a SnapClone from an existing VDisk to an existing Container. This will save the EVA from searching for free space again.

SSSU (Storage System Scripting Utility) is a command line oriented tool to:
- save the EVA's configuration to an SSSU script
- get configuration and status of EVA-internal objects
- run commands against the EVA

You observation that SSSU does not directly talk to the EVA's LUN-0 is correct - it does a TCP/IP session with the Command View EVA agent.

RSM (Replication Solution Manager) is a more complex framework to automate local (Business Copy) and remote (Continuous Access) replications. It includes a GUI, scripting language with the possibility to handle errors and a task scheduler. RSM also has a command-line user interface (the CLUI).

[Chetan_5]

So based on your reply, it looks like Mirrorclone is more close to the XP S-VOL.

Also the concept of container only applies to SnapShots and SnapClones, NOT MirrorClone as the vdisk for MirrorClone is always allocated, while the Snapclones are re-created everytime a new backup is started? Correct?

I would like to integrate BC commands with the application backup scripts on the UNIX host. So is SSSU good for the job or CLUI OR is CLUI the new SSSU?

Is there a document with examples of recovery scenarios and configurations? The XP had a nice little guide with different RaidManager/XP configs and scenarios.

[Uwe Zessin]

Yes the MirrorClone looks quite similar to a traditional mirror.

I can't test it right now, but I am quite sure that a MirrorClone can be put on a container upon initial creation. It is also possible to permanently 'rip' a MirrorClone into two independend VDisks.

SSSU might be sufficient for easy scripts, but it runs on most if not all supported operating systems. The BC server runs on Windows only, but it has a telnet interface which can be used to trigger jobs and there is the integrated job scheduler.

I might have overlooked something, RSM is heavily depended on built-in documentation. There us a windows help file (.CHM) available for download, though.

[Joseph Algieri]

Snapclone is like an XP BC paircreate with an instant split to simple mode.

Mirrorclone is like a normal XP Business Copy pair. You can suspend it (called a fractiure), update it and then come back an resync it. You can also split it permanently so the mirrorclone becomes a standalone Vdisk (like performing a pairsplit to simplex mode on an XP BC Pair).

The EVA is a vritual array. The container that you create as part of a three-phase snapclone or mirrorclone simply sets up all the metadat space needed to thrack the Snapclone or mirrorclone so that when you actually create it the array only needs to move the data, it does not have to allocate the metadat space which can cause a sever performacne impact on a server using the source Vdisk.

RSM is a GUI for controlling BC and CA on EVA.

SSSU is a ommand line interface for controlling an EVA (kind of like the RaidManager interface on XP).

I hope this helps.

[Chetan_5]

Hi Joseph,

Over the course of time I have figured out most of the terminologies. But what would you use for backups? Mirror clone or snapclone?

Is there a document which describes the BC process with an Oracle DB? I am still not sure how the reverse sync process works ...

Here is what I think of the backup process:
Using Snapclones
1. Unmount the filesystems
2. Un-present the LUNS ? (Documentation says that vdisks which are presented to hosts cannot be converted to containers)
3. Convert Vdisks to containers
4. Put DB in hotbackup mode
5. Start SYNC
6. Present and mount Vdisks upon completion
7. Remove DB from hotbackup mode

I think Mirror clone is different from snapclone in the sense that the DB is only put in backup mode after the copy is complete ala XP . Unlike the snapclone where DB is put into backup mode in the beginning of the copy ...

My test environment is still being built so right now I can only theorize ..
MAke sense?

[Peter Mattei]

You are absolutely right!

You just need to know when the source and target volume start diverting.

On a snapclone it is when you hit clone!
On a mirrorclone it is when you fracture.

On that start of diverting point the DB needs to be in backup mode; thats all.

If you want to use snapclone or mirrorclone depends on several things like:

- performanceimpact
- support of backup application
- backup frequency
- etc.

Performanceimpact:
For a write intensive environment with long backup cycles snapclone could be better.
You need to know that mirrorclone on EVA while in pair state (in contrast to the XP) is actually synchronous RAID1. So if your primary and secondary vdisk are in different disk groups with different performance characteristics your write performance will be that of the slower vdisk.

Support of backup application:
If you want to use the integrated Data Protector ZDB (Zero Downtime Backup) implementation you need to use snaplone because mirrorclone has not been implemented yet!

The beauty of the EVA is that you can choose the BC method that matches best!

Cheers
Peter

[Ivan Ferreira · Accepted solution]

>>> Over the course of time I have figured out most of the terminologies. But what would you use for backups? Mirror clone or snapclone?

Mirror clone is for XP and snapclone for EVA, maybe you can choose between snapshots and snapclones. Snapshots normally are better for backup because they can be "demand allocated".

>>Here is what I think of the backup process:
>>Using Snapclones
>>1. Unmount the filesystems
>>2. Un-present the LUNS ? (Documentation says that vdisks which are presented to hosts cannot be converted to containers)
>>3. Convert Vdisks to containers
>>4. Put DB in hotbackup mode
>>5. Start SYNC
>>6. Present and mount Vdisks upon completion
>>7. Remove DB from hotbackup mode

Your procedure is correct, if you use snapshots, you don't need to use "containers". If you use snapshots you will:

1. Put DB in backup mode
2. Snapshot (Demand allocated) the LUNs
3. Present/mount the luns
4. Remove DB from hotbackup mode
5. Start Backup
6. Remove the snapshot once backup is complete. Unpresent and delte the vdisks

See also the attached file:

[Peter Mattei]

Ivan

When your attached guide was published, you were right!
At that time the EVA could do either snapshot or snapclone; the XP could do just BC where the diversion started when you initiated the split.

In the mean time XP12000 now also supports space saving BC snapshot;and with the arrival of EVA XCS6.0 we introduced mirrorclone which starts off as a snapclone which then can be fractured and resynchronized as many times as you like. So you do not need to delete and recreate the clone anymore like on BC XP.

Cheers
peter

[Chetan_5]

Thanks to all for validating my theories.
Peter, inorder to enable Mirrorclone functionality, a firmware upgrade and Commandview upgrade are required.

Finally my test environment is ready and I have host agents installed and they show up as enabled hosts in RSM.

Now I have 2 more questions :
1. I am getting an error in getting the Java CLUI to work from the host. "Failed while communicating with Clui Framework"
2. In what way should I be using Managed sets in RSM?

Thanks a lot for all your help!