Automated EMC Clariion snapshots

We have a peculiar situation where running multiple snapview clone sync results in I/O wait on the production application. This is a business requirement where we have to take a backup of the production copy before running the EOD (End of day) process and one copy immediately after the EOD (End of day). The duration for EOD varies between 45 minutes to 1 hour. This is the time when the I/O is maximum. The EOD period is not sufficient to schedule snapview sync for the post EOD after the split of Pre-EOD. Their is always an overlap, and that is the period when the user face extreme slowness. We can stripe the luns over multiple Raid groups for the production luns but space constraint prevents us from doing this.

The solution what we found was to go for snapshot for Post EOD and with the normal sync for the EOD.

1. We add the luns to the reserved clone group. It depends on the size of the snapshot and the percentage change.
2. We create snapshot on the source luns and add it to the destination storage group. We are not activating it right now. If the LUN number is 235, the snapshot name is L235 and the session name is S235. We need to have a session for the snapshot to work.
3. Create custom scripts. The below is for deactivating the snapshot

for name in `cat Luns_list`; do
/opt/Navisphere/bin/naviseccli -secfilepath "$PWD" -address IP snapview -deactivatesnapshot -snapshotname L${name} -o
/opt/Navisphere/bin/naviseccli -secfilepath "$PWD" -address IP snapview -stopsession S${name} -o
done
4. Enable the snapshot

for name in `cat Luns_List`; do
/opt/Navisphere/bin/naviseccli -secfilepath "$PWD" -address IP snapview -startsession S$name -snapshotname L${name}
/opt/Navisphere/bin/naviseccli -secfilepath "$PWD" -address IP snapview -activatesnapshot S$name -snapshotname L${name}
done

Thats it, schedule the scripts 3 and 4 as per your convenience.

Comments

Post a Comment

Popular posts from this blog

zpool and power path partial compatibility

Is power path fully supported with zpools, no. It's partial. You can have the pseudo devices assigned to a pool but it uses the native ctd disk only. Recently I lost 2 paths from the vnx array to m9000 server running Solaris 11.1. When I ran the zpool status -x command some of the pools were online while some of them were un available. Power path was reporting 2 paths only but it was active. So ideally the zpools should be online. But it's not. I enabled the remaining 2 paths and all became online. Internally the pools were pointing to one of the ctd devices that belonged to dead path and it was not coming online. Also few of the emcpower devices were renamed, so I had to do zpool import -d with the alternate disk. It seems power path is not completely supported now but may become in future.
Read more

Recoverpoint replication reporting with vmax splitter

Guys, Have you ever thought of automating the RP replication status and send status via email or post it to any reporting platform. Since the splitter impacts the VMAX FA's and there is an overhead of 13% on the utilization its good idea to see if the replication is driving the utilization of vmax FA. There are ways of pulling iops/read/write using symstat but its utilization (Director CPU utilization etc) which plays a significant role. As it crosses 80% we start seeing the increase in device response time. However, to measure FA utilization we will have to go through SMAS UI then pull out the reports. Its manual effort. But there is a way to automate it through REST API. You can get the details what type of objects are supported by pointing to : https://smc server :8443/univmax/restapi Coming to the point, getting recoverpoint consistency group status fully automated doesn't seems to be tough. Lets get through the steps. 1. Hash your SSH keys of the unix host to ...
Read more

Weird problem post power maintenance, no Powerpath pseudo name for Luns

We had the scheduled power maintenance activity in our data center. Every team was notified and we powered doen the servers through cron job. The servers were powered down first then storage (CX-380). And the reverse was followed during startup. After the power shutdown, the SAN was booted up. we forgot to disable the the snapshots. They were still active. Once it came up, the sessions were not there, but snapshot was active. Tried to deactivate the snapshot, failed with the error the "Failing Command: K10SnapCopyAdmin DBid 0 Op 1051. 71 00 80 43" Tried to create a session and attach the snapshot to the session, still unable to deactivate it, neither was able to attach to any other session. Looked at powerlink: It says the command issued to the snapshot is not owned by the SP. I trespassed all the snapshot source lun to SPA, and then tried to deactivate, nothing happened. Rebooted the SP's one by one through the management console. (http:/SP-IP/setup) Then I was able to...
Read more