Highlighted

Re: CX3-20 backplane cables out of sequence - office move jumbled them up!

Jump to solution

Perceived wisdom certainly suggests that DAE order/sequence is a none issue. The rule of thumb seems to be that so long as cables from SPA  run (for instance) to the left most socket on the back of the DAE and those from SPB to the sockets on the right hand side of the DAEs then the actual order of the DAEs 1,2,3,4,5,6,7 or 1,5,2,7,3,4,6 does not seem to matter.

Easy to test I guess - if I'm feeling brave!

I also assume - but do not know for sure, that the two backplane fibre sockets on, say the left of the DAE are interchangeable too - so you can go 'in' or 'out' on either one. Ditto for the RHS - again, easy to test.

So as in my case the SAN 'works' the only bit I'm left with is the question of why the SPs only 'see' the SPs, but no LUNS etc, will not give me any logs/reprots etc and lock up Navisphere if I try. Perhaps time for the CLI version?

Thanks for all suggestions.

0 Kudos
Highlighted
4 Ruthenium

Re: Re: CX3-20 backplane cables out of sequence - office move jumbled them up!

Jump to solution

davidmatthewson wrote:

Perceived wisdom certainly suggests that DAE order/sequence is a none issue. The rule of thumb seems to be that so long as cables from SPA  run (for instance) to the left most socket on the back of the DAE and those from SPB to the sockets on the right hand side of the DAEs then the actual order of the DAEs 1,2,3,4,5,6,7 or 1,5,2,7,3,4,6 does not seem to matter.

Correct, technically there isn't any requirement for the physical cabling to match the logical assignment of the DAE within the bus (however, I would suggest at least DAE 0 being the first in the chain of bus 0; then again I wouldn't recommend them not being in order). 

Keep in mind as you had written above, you are mistaking LCC A and B of the DAE3P.  Note the diagram above and along the left the double headed arrow with the up arrow labelled "B" and the down arrow labelled "A"

a) LCC A is the bottom card (corresponds to ports on the right)

b) LCC B is the top card (corresponds to ports on the left)

Also, as a reminder, in regards to the Storage Processor Enclosure (SPE): SP A is on the right and SP B is on the left when looking at it from the rear which is also represented via labelled double-headed arrows in the middle of the SPE.  So one way to look at it from the back-end cabling perspective for your model: "plane" A is on the right and "plane" B is on the left (again when facing the rear of the cabinet).

Furthermore, the cabling should be EXP port (BE 0 in consideration of the first connection from the SP) to the PRI port of the next DAE.  There also is next to each port a "Primary/Expansion link port active LED".  Written out this would be as follows:

SP A BE 0         -> DAE 0_0 LCC A PRI

DAE 0_0 LCC A EXP -> DAE 0_1 LCC A PRI

DAE 0_1 LCC A EXP -> DAE 0_2 LCC A PRI

and so on, then similarly for "plane" B.

Lastly, as RRR noted, if it truly is a CX3-20, it has just the one bus so would not possible to have DAE's incorrectly cabled to the wrong bus as was originally assigned.

For your reference, here is the URL to the document: "CX3 Model 20 Systems Hardware and Operational Overview"

https://support.emc.com/docu5580_CX3-Model-20-System---Hardware-and-Operational-Overview.pdf

Highlighted

Re: Re: CX3-20 backplane cables out of sequence - office move jumbled them up!

Jump to solution

Brilliant & lucid advice - many thanks.

I'll check this out on Monday when I'm next on the comms room site.

David

0 Kudos
Highlighted

Re: Re: CX3-20 backplane cables out of sequence - office move jumbled them up!

Jump to solution

OK, some feedback on this.

I've confirmed that the backplane cables do indeed run as described above and in the book of words and rebooting the SPs does not seem to have any effect. What actually happens is that the disks go off line as far as the Windows host is concerned and then, after about 20-30 minutes, reappear. This seems far too slow to be normal.

If I have a laptop connected into SPA LAN I see it's IP disappear when I reboot the SP and return in about 45 seconds. So far so good. But if I then try a port scanner or telnet on 80 or 443 I see nothing. Again, it takes 20-25 minutes before I can get a response (& can log in with a web browser) Again this seems far too long. Navisphere, when it eventually comes up, is 2.63, which I know is vv old. It also needs an old version of Java on the laptop to use it - 1.xx - If I use any of the 6.x or 7.x versions Navisphere will not load at all.

So I guess I've got a very large SAN which works - sort of - but which can't be managed and if a disk fails, I'm guessing it won't swap to a hot spare &/or rebuild when I replace the dead drive.

0 Kudos
Highlighted
2 Iron

Re: Re: CX3-20 backplane cables out of sequence - office move jumbled them up!

Jump to solution

Hotspares will replace faulted drives automatically if configured. When connecting to the SP ports  are you using the service lan port or  management lan port ?  If the service lan port remember to talk to SPA  you phyiscally connect to SPB and vis versa .  Ip address is  128.221.1.250  (SPA)  128.221.1.251 (SPB)  for the service lan ports

0 Kudos
Highlighted
5 Rhenium

Re: CX3-20 backplane cables out of sequence - office move jumbled them up!

Jump to solution

Was your question answered correctly? If so, please remember to mark your question Answered when you get the correct answer and award points to the person providing the answer. This helps others searching for a similar issue.

glen

Highlighted
Not applicable

Re: CX3-20 backplane cables out of sequence - office move jumbled them up!

Jump to solution

ASR is correct. If plugged into the SPA Service Port you are talking to SPB and visa versa. Have you tried logging into the peer SP? One thing you could do is bring up one SP at a time and see if there is a difference in Navisphere. It sounds like the Embedded WinXP OS may have been corrupted hence Navisphere not behaving correctly.

15-20 min could be normal for the LUNs to become visible on the SAN to the hosts.

The "Pri" and "Exp" DAE3 ports are intended to be dedicated to input and output respectivley.

If LUNs have R/W access then there is something wrong within the Embedded OS/Navisphere.

You could try an Off Array Navisphere app to see if a difference there.

Oh and yes if old SP Collects are required there is probably a set on each SP under "File Transfer Manager", they could have assisted of there was more than one back end bus for the jumbled DAE's but in your case does not apply due to the one BE bus on CX3-20.

I would have enclosure 0 first on the bus if possible, if it is not could explain the slow boot up.

Network pings respond long before the array can service I/O.

Good luck! and keep trying.

0 Kudos
3 Argentum

Re: CX3-20 backplane cables out of sequence - office move jumbled them up!

Jump to solution

There has been no activity on this question. Can you provide and/or update the status to answered?
Thank you.

Highlighted

Re: CX3-20 backplane cables out of sequence - office move jumbled them up!

Jump to solution

OK, we'll wrap this up now. Many thanks to all who helped out.

Key things we've learnt are that the cable sequence does not matter so long as basic rules about 'in' & 'out' are observed along with not crossing over from 'A' to 'B'.

In the end it seems one of the SPs - SPB - has died so we are currently running on one leg, but can at least now get Navisphere to work and manage the system. It is 'long in the teeth' (5 years old) and out of support so time to be replaced I think.

Thanks again!

David

View solution in original post