Director replacement affecting BCV split operation

Hi Farhan,

Actually this isn't a dumb question at all - the "dual initiator" or "partner director" should have seamlessly taken over control of all drives - including the unprotected BCV device/s. Your TimeFinder operations should not have been interrupted, at least that is how the hardware & TimeFinder are designed.....

However (speaking to a Senior Product Support Engineer) it can depend on what caused the DA director to drop "DD" in the first place... If the hardware failure that caused the director to become unresponsive had also caused the attached drives to go "Not Ready" then the dual initiator would have taken over a "Not Ready" unprotected drive (i.e. to TimeFinder it looks like the unprotected drive itself has failed).

Other protected drives would still have had an available "mirror" elsewhere in the Symmetrix and you would not have noticed any issues...your local EMC Customer Engineer would have to investigate further if you want to confirm this....

O.K. to answer your other question - YES, a mirror protected BCV would definitely prevent any possible future interruption (to TF operations) due to hardware failures.

(But it should only be for those *hopefully rare* occasions when you need both "belts & braces" protection)...

Regards,
Michael.

Thanks for that Micheal. Meanwhile I have learnt that the BCVs were protected. So this strengthen our case that the director replacement should have been seamless to any TF operation. We just needed to split a local drvice group. Our Customer Services Delivery Manager is looking further into this. Might need an RCA I think.

We use protected BCVs and R2s everywhere which has saved us quite a number of times. If a drive fails (or any thing else) there is an extra layer of resiliency. A drawback is that it will, obviously, use more disk space. But if you make everything in the box protected and as identical as possible, management is much, much easier.

Hi Farhan,

Thanks for that...Yes, a formal RCA through your local support team would be the way to go.

Best Regards,
Michael.

Michael,
EMC got back to say the errors have wrapped around so we can't get a definitive RCA. Let me explain things somewhat further.

The split failed when running an rdf split rather than a symmir split.

Prior to this I found out that my colleage ran a symmconfigure script that failed which prompted him to raise a Service Request.

CE came on site to replace a failed director. He wasn't able to complete his replacement script because the symm was locked ( due to the Symconfigure script failing i belieive ? )

However we checked for system locks and device locks at the time the rdf split failed and nothing was evident. Would this type of lock be shown to us using Soluations Enabler ?

Would a symmconfigure script failure cause rdf split to fail even though we have two Disk Directors that work as partners?

Or should we resign to the fact we had a bad spate of double bad luck . In that the symconfigure script locked the box, director went DD. Consequently not allowing to run a rdf split ?

Hi Farhan,

Hmmm, an RDF split? Sorry, I am not quite clear on this, did you mean a remote BCV established on a target Symmetrix (i.e. being split across the link) OR a locally established BCV R1?

In any case, in regards to the failed symconfigure script, the script would not have started if the director had already dropped "DD". So, I expect that the hardware failed during the running configuration change. In this case it would have left the Config Lock #15 set and this would prevent further configuration (bin file) changes. The config lock would be visible thru Solutions Enabler.

BUT I would not expect syscalls for an RDF split to have failed due to the Config Lock (?). This request is not for a configuration change.....

However, this question has gotten somewhat more complicated than I first imagined and without a lot more information I can only guess.... (e.g. the symconfigure script would have issued commands that had not yet completed - due to the hardware failure - these incompleted steps MAY be the cause of the problem rather than just the config lock)....

The lack of log files makes it difficult but I think your local EMC Support Team (local CE, RTS / RSS) should still be involved and they can (at least) make an educated guess of what went wrong (and suggest an appropriate avoidance for the future).

Of course, I will leave this open to more knowledgeable EMC'ers for comment....

Best Regards (and Seasons Greetings),
Michael.

You haven't mentioned what type of DMX you are using and what version of Enginuity. We have had an issue similar to this on a DMX-3 running 5771.92.99 code which I think is now fixed in 5771.94.102. This may have also existed in earlier versions.

Normaly this BCV can are dual initiator, but when you have problem with a card Disk Director, in DD, is very possible this BCV is reserver for this server without answer, the other director can't work for this problem, is necesary to reset this Disk Director, but this process is very dangerous, and the backup in possible is down for this server.

Farhan,
I can answer one of your questions about checking for locks on your symmetrix:

The following will list the locks on your sym: #symcfg -lockn all list

If you have none, you will see similar output to that below:

SymmID Attachment LockStatus Lock # LockUsage TimeHeld (Sec)

000187700234 Local N/A N/A N/A N/A
000187721345 Local N/A N/A N/A N/A

If you have a lock initiated by a failed symconfigure command, you can release it using the following: #symcfg -lockn release

Be sure to double check with your CE if you notice a lock on your sym that you didn't initiate. S/he may have a reason for the lock (code upgrade, etc.)....

Regards,

Julianne