EVA and Continuous access

[Johan Guldmyr · Accepted solution]

Hi!

"If so, you need to run HP-FC., you set this under the replication settings in CV on the CV server. From the above output, isn't the aptpolicy 1 and not 0? If it is and please pardon my ignorance, should the replication setting be still HP-FC?"

Sorry, That was a typo from me. If it's "0" or port-based routing you need to use HP-FC.

"You gave two CV numbers is it 10.1 on both management modules and 10.0 on the CV server? I am not quite sure as to what is the CV server. I go to the CV gui by directing the browser to <IP address>:2374. The CV version that I provided was the one that was on the login page that is presented when I go to that URL."

1. It sounds to me like you actually do not have Command View installed on the management server, but that you instead from the management server use a web browser to connect to the management modules on the two EVAs.

The management modules have an IP address and they are actually a module in the controller enclosure of the P6000. One definite problem and another potential one:

a) Command View on the management module cannot be used to set up CA - you need to have Command View installed on a server that has FC connectivity to more than one EVA.

b) When you go to <IP>:2374 you do this over TCP/IP - this is not how you confirm FC connectivity between a server and a target.

The files you attached were the supportshow, not the output of "cvutil" (probably cvutil paths is a good place to start confirming connectivity). You could also use the HBA's management tool BCU or HCM).

Before you start installing Command View on a server, it would be a good idea to streamline things, so that you have the same XCS and Command View on all the devices. Generally it's bad to manage the same EVA/P6000 with different versions of Command View.

[Dips123]

Hi Johan

Thanks once again for your valued contribution. 

I think that the server I am logging on to is the CV server. The reason why I say this is because I am RDPing into the server. After logging in I point my browser to an IP address which is the same as the server and to port 2374. I have also seen that the CV is running on the server as a service. Is it sufficient confirmation that this means this is the CV server? This should also confirm that I am not going to the management module of the EVA.

When you go to <IP>:2374 you do this over TCP/IP - this is not how you confirm FC connectivity between a server and a target.

I apologise if I was not clear in my description before. The server which I use to connect to the port 2374 is also connected to the switches using HBA and fibre and on the switches it is zoned to the EVAs. I can see the WWPNs of the HBA of the management server on the switches. This is how I confirmed fibre connectivity.

The output that I attached previously, has the output of supportshow as well as nscamshow and nsshow. Apologies again if I was not clear in description. Do I need to run cvutil from cmd prompt?

Thanks for your suggestion about the XCS version, I am in the process of bringing the version to same in both the arrays.

One other new development that has happened since we last touched bases, 

I checked the switches again and saw that although I was pressing the Save Config on the switches it was not saving the config. I had to manually add the newly created zones in the zone config of the switch and then save. That saved the zones. After that I ran the discover storage again and it found something this time. 

Under the unmanaged storage systems on the prod EVA, it found something which has the same node WWN as the DR EVA. However the screen tells me that the system requires a password. I have tried entering the password that I use to login to the DR EVA CV interface but it has failed. I believe the password needs to be retrieved from the OCP. If this is the case, is there a way to retrieve the OCP password remotely without actually being present near the EVA?

Also it gives me a License alert that the system does not have the required license. However it does have the necessary licenses as per the EVA CV interface. 

I thank you again for your generous support. I can't thank you enough.

Regards,

[Johan Guldmyr]

Hi,

OK yes if you point your browser on the CV-server to <localhost:2374> then yes you have CV installed on it.

"I can see the WWPNs of the HBA of the management server on the switches." This is not how you confirm connectivity between a server and a target either. The above is perhaps how you confirm it between a server and a switch.

Yes, cvutil you need to run from the command prompt. But this should be fine now as you can see the DR EVA in CV.

Perhaps CV cannot see the licensing properly until you've entered the password for the remote EVA.

Do you have access to the WOCP (nowadays called "HP P6000 Control Panel GUI")?

You access it with https://IP.to.management.module:2373

[Dips123]

Hi Johan

Thanks so much for your contribution. I can't thank you enough. Yes going to port 2373, I could change the password and get the replication started. But I have faced another issue. I have created 8 replication groups and they have synced and are working fine. However when I want to create any more I get the error

"Operation failed

Not enough data storage available in the disk groups, or no compatible disk groups available for the requested raid type. If this error occurred during a data replication operation please check if the requested capacity/raid level can be supported in the disk groups on both source and destination."

The error doesn’t make any sense simply because, the destination EVA has not got any disks provisioned. I was always under the impression that once the replication starts the source disks and disk groups are created in the destination EVA. I haven’t created any disk groups in the destination EVA because of that. Any ideas why is it failing? The destination EVA has space, I was under the impression that as soon as the replication is started the destination EVA will have the disks from the source EVA recreated for presentation during a disaster. Why is it then failing?

I would appreciate, once again, any feedback. Thank you so much for your support thus far, I can't thank you enough.

Regards,

[Johan Guldmyr]

Hello Dips!

I'm glad to help :) But I must confess that now we enter subjects where I have not so much experience.

P6000 compatibility reference say that you can have 256 single-member DR groups. 

http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02523047/c02523047.pdf

Some DR methods use a transaction log (wire history log?). Perhaps you do not have enough space for that?

[Dips123]

Hi Johan

I just wanted to inform you that I have successfully managed to start the replication. Thanks to you and other's help and support. You are right, it was a log issue. The default log size is 100 GB and as a result at the source the log file space was used up after creating 8 replication sets. I found this and configured the logs to be 5 GB instead and that fixed it. The logs can be also configured to be in tier 1 or tier 2 disks. Thanks a lot again.

One thing I wanted to ask was, after the initial sync is complete, it shows me that the log is not in use and there is no way to know that the files that are written to the source disk are replicated in the production site. Please find below one test replication set that I've created. It shows that the logs are not in use. But if the replication has started shouldn't the logs be in use? Also if the source disks are thick provisioned, then do the destination disks automatically become thick provisioned or is there a way to create the destination disk as thin provisioned to save space? Lastly, if I have multiple disk groups at the source, for eg: OS, Database, VMs, and I replicate them, is there a way to create separate folders to categorize them at the destination EVA replication set?

Name

Role

Write Mode

Log State

Test

Source

Synchronous

Not in use

Thanks a lot again. I can't thank you enough for the help and support that you have provided already.

Regards,

[Johan Guldmyr]

Hello! Glad you got it working.

It  would be have been good if you would have posted these questions in a new post.

Some comments nonetheless: 

• WHL (Write History Log) is for example used when synchronous or basic asynch replication is stopped or failed. 
• See page 42 on http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02838340/c02838340.pdf