Нумерація кабелів: чому «найбільший плюс один» є неправильним правилом

Кожна команда дата-центру погоджується, що кабелі треба нумерувати. Набагато менше погоджуються щодо того, звідки беруться номери, і саме тут маркування кабелів тихо розвалюється. Звичний метод: подивитися найбільший cable ID у DCIM і додати один. Виглядає безпечно. Це не так. Ця стаття пояснює чому, і як вести cable ID так, щоб номер завжди означав рівно один кабель, назавжди.

Для чого потрібен cable ID

Cable ID є обіцянкою: цей номер стосується цього кабелю і нічого іншого. Обіцянка дозволяє інженеру, який стоїть перед стійкою, за секунди зіставити фізичний кабель із записом, підтвердити обидва кінці й діяти, нічого не простежуючи вручну. Вона також дозволяє старим тікетам, записам змін, фотографіям і кресленням зберігати сенс роками.

Обіцянка ламається тієї миті, коли один номер з’являється на двох кабелях. Відтоді кожне посилання на цей номер неоднозначне, а неоднозначна мітка на кабелі є саме тим способом, яким висмикують не той кабель.

Чому «найбільший плюс один» не працює

Правило «найбільший плюс один» припускає, що поточний список link у DCIM є повною історією кожного номера, який коли-небудь використовувався. Майже ніколи це не так.

Видалені link. Коли кабель прибирають, його link видаляють із DCIM. Якщо він випадково ніс найбільший номер, наступний інженер використовує цей номер повторно, тоді як стара мітка може досі бути на кабелі в шухляді, на фотографії або в торішньому тікеті.

Надруковано, але ще не записано. Мітки часто друкують до роботи, а DCIM оновлюють після. Між цими двома моментами номери існують на стрічці, але не в базі даних, і хтось інший може їх забрати.

Двоє людей одночасно. Двоє інженерів, які планують дві роботи того самого дня, обидва читають той самий найбільший номер і обидва додають один.

Поля вільного тексту. У більшості інструментів DCIM поле кабелю є вільним текстом. Ніщо в базі даних не заважає тому самому значенню потрапити на два link, тож унікальність має забезпечувати процес.

Кожна з цих ситуацій рідкісна сама по собі. За роки й тисячі кабелів вони неминучі.

Правило, яке працює: монотонно, із резервуванням, без повторного використання

Ставтеся до cable ID як до номерів рахунків-фактур. Вони походять від одного allocator, вони лише зростають, і номер, який був виданий, ніколи не видається знову.

Рахуйте все, що коли-небудь існувало. Уявлення allocator про «найбільший номер» має включати живі link у DCIM, link в історії змін DCIM, які відтоді видалено, кожне завдання друку міток у записах і власні резервування allocator. Наступний номер є на один більшим за найбільший з усіх цих.

Резервуйте перед друком. Ніхто не пише мітку чи link, доки не зарезервує блок номерів для названої мети («збірка стійки, другий ряд, кабелі даних»). Резервування записується разом з тим, хто просив і навіщо.

Анулюйте, ніколи не повертайте. Якщо зарезервований номер не використано, позначте його анульованим. Він лишається спаленим. Прогалини в послідовності нешкідливі; повторне використання ні.

Відмовляйте за замовчуванням (fail closed). Allocator перечитує DCIM при кожному резервуванні. Якщо не може, не видає нічого. Трохи повільніший день є набагато кращим результатом, ніж дублікат.

Мінімальний реєстр є однією таблицею, де cable ID є первинним ключем, тож база даних сама відмовляє у другому використанні:

CREATE TABLE cable_id (
  cid        INTEGER PRIMARY KEY,
  status     TEXT NOT NULL CHECK (status IN ('RESERVED','IN_USE','VOID')),
  purpose    TEXT NOT NULL,
  reserved_by TEXT NOT NULL,
  reserved_at TEXT NOT NULL
);

Тримайте DCIM чесним

Allocator є лише половиною системи. Друга половина полягає в перевірці того, що насправді потрапляє в DCIM.

Відмовляйте в незарезервованих записах. Будь-який інструмент, який пише cable ID у DCIM, має спершу перевірити, що номер зарезервований, і відмовити, якщо ні, або якщо allocator недоступний.

Стежте за дрейфом. Запускайте періодичну перевірку, яка читає кожен link і підіймає тривогу за трьох умов: номер на двох або більше link, номер вище за верхню позначку allocator, який ніколи не був зарезервований, і анульований номер у використанні. На схемі в стилі RackTables перевірка дублікатів є одним запитом:

SELECT cable, COUNT(*) AS links
FROM Link
WHERE cable IS NOT NULL AND cable <> ''
GROUP BY cable
HAVING COUNT(*) > 1;

Запускайте його кожні кілька хвилин, надсилайте будь-який результат людині й ставтеся до кожної тривоги як до знахідки, яку треба розслідувати, а не до шуму.

Зберігайте голий номер. Визначте один формат для збереженого значення, наприклад голі цифри, і тримайтеся його. Якщо деякі link кажуть CID1234, а інші 1234, перевірка унікальності за текстом пропустить пару. Коли ви запроваджуєте таке правило на наявному парку, зробіть так, щоб allocator і перевірки читали обидві форми, щоб історичні значення й далі рахувалися.

Мітки, які відповідають на наступне питання

Мітка, яка каже лише «1234», каже інженеру, який запис відкрити. Мітка, яка також каже, куди йде інший кінець, часто взагалі позбавляє потреби його відкривати. Ми друкуємо дворядковий макет на ламінованій стрічці, обгорнутій прапорцем:

1234 RK-A SRV7 NIC1
RK-A SW1 Eth1/9 [2M]

Верхній рядок є cable ID зі стійкою, пристроєм і портом цього кінця. Нижній рядок є стійкою, пристроєм і портом дальнього кінця та довжиною кабелю. Та сама мітка йде на обидва кінці, а обгортання прапорцем означає, що її можна прочитати з будь-якого боку кабелю.

Два практичні зауваження з багатьох сесій друку: друкуйте мітки одного кабелю на одне завдання друку з короткою паузою між завданнями, бо великі партії можуть переповнити буфер принтера міток і видати порожню стрічку; і зберігайте кожне завдання друку як скрипт разом із проєктом, бо ці скрипти є частиною запису про те, які номери існують.

Спершу збудуйте на папері

Найсильніша звичка: зарезервувати ID, записати link у DCIM як план і надрукувати повний набір міток до того, як прибуде обладнання. Уночі інженери прокладають кабелі за мітками, які вже існують, і за записом, який уже збігається. Перевірка після цього стає порівнянням, а не реконструкцією.

Чекліст для вашого власного парку

• Звідки беруться ваші cable ID? Якщо відповідь «найбільший плюс один», як щодо видалених link?
• Чи заважає щось тому, щоб той самий номер зберігся на двох link?
• Коли ви востаннє шукали у своєму DCIM дублікати cable ID?
• Чи кажуть ваші мітки інженеру, куди йде інший кінець?
• Чи зберігаються десь ваші завдання друку міток?

Нумерація кабелів не гламурна. Зроблена правильно, вона є одним із найдешевших способів тримати руки подалі від не того кабелю.

Якщо ви хотіли б допомоги з наведенням порядку в записах про кабелі, наші інженери радо поділяться методом. Поговоріть з інженером

Related

Пов’язане: Унікальний ID на кожному кабелі, без повторного використання · DCIM: кожен об’єкт, порт, кабель і адреса відстежені