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

Do you have old SP Collects before you moved the Storage Unit? Then I reckon, you can get the old cabling information.

i am amazed that some raid groups apparently still working so not all DAEs got cabled incorrectly.

Will be difficult, surely need support team/CE to be engaged.

Thanks for all of those suggestions. I tried running up Navisphere (Java version) on a directly connected laptop and, after logging in with my creds,  it 'sees' the SP (either A or B) but shows 'F' (fault) against both the 'domain' and the array. RBC should, as you say, bring up a menu which it does. Select 'Connectivity' and the browser just locks up with no result. I get similar results on both SPs.

WRT the backplane cables I'm told that it doesn't matter which 'sequence' the DAEs are in? [so long as SPA goes to 'A' side and v.v.?? I may have the DAEs in the wrong 'stack' order but that would not seem to matter??

Indeed, the Windows host  'sees' all the drives at a Windows level and they are all R/W OK.

So any ideas how to get the SPs (connected via a Brocade 200e) to 'see' the LUNS etc for management?

and no, I did have SP collects but from a couple of years ago so junked.. sigh.

Many many thanks

David

David,

You are correct that on the CLARiiON there isn't any requirement that the DAE's be physically cabled to match the logical assignment.  For instance, it is possible to have DAE 3 physically come before DAE 2 on the bus.  Also, there isn't any technical reason they have to be contiguous.  For example, you can have DAE 0, 1, 4, 5; where DAE 2 and 3 don't exist either because someone accidentally/intentionally manually skipped those numbers upon initialization or later they were removed from the middle of the loop (which, just to mention it, can be done entirely online).

You can obtain the Bus and DAE number for each enclosure via the LED's on the back which will (should) not change once initialized.  You will find two colored LED's:

1) Green = Enclosure Address

2) Blue = Bus number

Also, if the Blue LED is blinking, it can denote invalid cabling in the following situations (however, you can not imply that if it is not blinking that cabling is valid - still verify manually) :

a) LCC A and LCC B are not cabled to the same bus

b) Or the maximum number of DAEs allowed on the bus is exceeded

For reference, here is a diagram of a DAE3P (unless you own an older model) :

Fantastic support & advice! Many thanks - I'll check out on Monday when I'm next in the comms room,.

So if the order is not an issue now ~all~ I have to do is figure out why the SPS are not 'seeing' the DAEs.....

David, did you ever have to upload SPcollects to a service request? You could look for those older SRs and download the SPcollects again to verify which DAE goes where.

Indeed I did upload them for an SR - I'll try to check them out. Thanks

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.

Isn't is so that the CX3-20 only has 1 BE bus so mixing DAEs between 2 or more buses is impossible and since the DAE number is placed IN the DAE instead of in the SPs the sequence of the cables shouldn't matter.

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

Brilliant & lucid advice - many thanks.

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

David

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.

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