On 2/7/13 10:46 AM, Matt Simmons wrote:
> Hi,
>
> So, my current situation is that I'm working in a datacenter with 21
> racks arranged in three rows, 7 racks long. We have one centralized
> distribution switch and no patch panels, so everything is run to the
> switch which lives in the middle, roughly. It's ugly and non-ideal and I
> hate it a bunch, but it is what it is. And it looks a lot like
> this:
> http://www.flickr.com/photos/bandman614/7835443304/in/set-72157604826850180
>
> Anyway, so given this really suboptimal arrangement, I want to be able
> to more easily identify a particular patch cable because, as you can
> imagine, tracing a wire is no fun right now.
>
> While everyone that I've talked to agrees that both ends need labeled.
> The question is what do you put on them. The schools of thought as far
> as I am aware are:
>
> 1) Every cable end's label says exactly what the other end is connected
> to, including hostname and port number
>
> 2) Every cable end's label is uniquely identified to that cable, because
> things move and relabeling sucks.
>
> 3) <insert your other viewpoint here>
>
> Is there actually some best practice that I'm unaware of? How would you
> do it in this case?
>
> --Matt
I am strongly in favor of labeling the cables at both ends with both of
the ports they connect to. This falls into the "label for emergency use"
camp, but it also covers "label to avoid causing an emergency", like
unexpected downtime because the "redundant" paths turn out not to be.
- - If you have a working system, you can stop reading now... - -
I'm going to mention the following since no one else has suggested it,
and it should be brought up for completeness. At my institution, we use
ANSI/TIA/EIA 606-A. It may be overkill for most people, but it scales
well. >8^)
In particular, I can walk into any of our thousand-plus buildings (I
have servers in #38 and #3115) and look at a cable, and I know where
both ends are with a high degree of certainty _and_ without consulting
the database.
Actual copper patch cables are usually labelled with a truncated
version, which drops the building number and the room number, while
riser fiber cables have room numbers and inter-building fiber cables
include the building numbers. The database has the full path with the
long labels, and there are automated error checks in case someone enters
a patch panel, port number, or switch name that are undefined.
With out size, we're always touching some cables in a given week, and we
simply re-label them if they are moved. The database ties to monitoring,
asset tracking, and several other systems, so we recoup the time we
spend on cable path inventory many times over during the life of a pathway.
Patch cables with labels like
36.A.22 - 49.D.18
36.A.23 - 49.D.19
are very easy to trace from either end, since you're either looking at
the end in rack 36, or rack 49. In rack 36, there is only one patch
panel, but it's labelled "A" for clarity. Rack 49 has patch panels
through "J" at least, but they're all labelled so it's easy to find "D".
>From the patch panel to the switch, you introduce names which match
labelled devices
49.D.18 - 50.svr3.g1/0/33
49.D.18 - 50.svr1.g1/0/26
so I know the first run terminates at a switch labelled "svr3" in port
33, and the second in switch "svr1" port 26. Both switches are in rack
50, which is also labelled. The only thing I really need to speed up
tracing cables is a map of the rack numbers on the floor grid.
My operating principles for the data center include:
- It's worth investing time on documentation while you know what you're
installing, to save time and potential errors later.
- Labels are cheap, and so are label makers.
- A couple minutes printing and attaching a label to a cable is cheaper
than tugging tightly-bundled cables for 15 minutes while it hits the fan.
- The database will _not_ be available to the tech on/under the data
center floor when they really need it.
When your infrastructure gets large enough, it's actually helpful to
have a "stupid label guy" or three:
http://dilbert.com/strips/comic/1995-11-07/
and supporting policies. People have accused me of being him, but I
always identified more with the unix user:
http://dilbert.com/strips/comic/1995-06-24/
I don't work for a pointy haired boss, so I can laugh at Dilbert.
Allan
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
