P2000 G3 problems ...

[dcy]

Hardware: P2000 G3 MSA FC/iSCSI (2 pieces, both with Remote Snap licenses) - I will call them Storage_1 and Storage_2 in the context of this post. Connectivity is provided via copper (FC ports not in use at this time, plan to implement FC connectivity soonish, but after entry into production). CHAP is required and activated on both storage's host interfaces. At the moment there is no firewall (or any kind of traffic filtering) between the storage arrays. The arrays are able to ping each other without problems (I am able to ping all interfaces (both host and management) from Storage_1 and Storage_2, so IP connectivity is working and has no issues).

Issue #1 - a show stopper for me at the moment:

I am having problems getting communication between Storage_1 and Storage_2 going. This may or may not be related to CHAP issues that I am also encountering. Setting up Remote Systems on both storages I run into the following situation:

Storage_1 has Storage_2 added as a Remote System (username and password have been triple checked, the system has been removed and readded via the management interface).

Storage_2 has Storage_1 added as a Remote System also (again, username and passwords have been triple checked and the system has been removed and readded).

Checking remote links from Storage_1 to Storage_2 shows no ports (A3,A4,B3,B4 should work) being able to connect to Storage_2.

Checking remote link from Storage_2 towards Storage_1 shows all ports having connectivity to all ports on Storage_1. (A3,A4,B3,B4 all having connectivity to A3,A4,B3,B4).

Rather unusual, don't you think?

To add to the problem I am also showing a "zombie" CHAP record (only relevant bits of the printout shown, mind you I tried mutual authentication, but this record was without mutual auth.):

# show chap-records
Chap Records
------------
Initiator Name: iqn.1986-03.com.hp:storage.p2000g3.1notshown9
Initiator Secret: mysecretnotshown
Mutual CHAP Name:
Mutual CHAP Secret:

# show chap-records name iqn.1986-03.com.hp:storage.p2000g3.1notshown9
Chap Records
------------
Success: Command completed successfully.

(so, the system does not see the chap record?)

Predictably, this occurs:

# delete chap-records name iqn.1986-03.com.hp:storage.p2000g3.1notshown9
Error: The CHAP record was not found in the database.

And yes - I see it in the web interface, and no, I am unable to delete it from there either (I get a stop error with the text "Unable to update CHAP entry. The CHAP record was not found in the database."). So I'm stuck with a CHAP record that I cannot edit or erase, but which unfortunately relates to my other array.

Question with regards to Issue #1: What is your advice in regards to the zombie CHAP record? (how to expunge it?) And what else can I possibly do to check the connectivity problems between the storage arrays (and how to fix them?).

Issue #2 (might consider this a bug report):

Flashing Storage_1 with TS230R044 I ended up with controller A having the TS230 firmware and controller B having TS201 (delivery firmware) and no communications between the controllers. A restart of the array (restart sc both and restart mc both were failing apart from the management controller I was connected to) was only possible by a hardware reboot. After the reboot no remote connection was possible to the management interfaces (as defined in Configuration -> System -> Network Interfaces) was possible, luckily at least the host interfaces were responding. By selectively rebooting (again, hard reboot) the array with controller A present first I managed to get at least to the management console of controller A. Hot plugging the controller B however again caused a total loss of communications to the management interfaces (either to A or B). After a hard reboot with only controller B present I got the second management interface working and hot plugging controller A communication to both management interfaces on controller A and B was now possible. The puzzling thing is that both controllers now show the TS230 firmware working normally. While this was happening in the deployment testing phase it was not a big issue, but  I dread flashing any kind of firmwares in a production environment. The puzzling thing is that the Storage_2 flashing process went without any issues at all.

Question in regards to Issue #2: Would it be advisable to reflash Storage_1 with TS230 again? (to make sure both controllers have a proper copy of TS230). "show version" does show both at TS230R044, but I would like to be certain that TS230R044 was applied properly without issues.

Looking forward to any kind of reply or advice. Available for further information :)

D.

[dcy]

Well, this is getting annoying now.

Since I'm rather pressed for time I issued "restore defaults factory" ... the chap records however still remain and are not eraseable ... ^^

For some odd reason I was able to remove the chap records via the CLI:

# delete chap-records all
Success: Command completed successfully. - All CHAP records were deleted.

The communication problems persist...

D.

[Mark Matthews]

Did you ever get to the bottom of the communication issues with Remote Snap?

My company are having similar issues with one of our clients.

It seems to work fine for a few days after we do a 'restart mc' command, then replication will randomly start failing, then we cannot login to the web interface of the controllers etc etc.

HP havent been much help so far... :(

(Edit: We are NOT using any CHAP, and the management LAN is on a seperate VLAN from the rest of the traffic)

Thanks,

Mark...