Учет серверов в стойках: инвентаризация юнитов, портов и питания

Учет серверов в стойках строится на одном принципе: у каждой единицы оборудования есть точный физический адрес — площадка, ряд, стойка, номер юнита и его высота в U. К этому адресу привязывается всё остальное: серийный номер и модель, порты коммутатора, розетки PDU и вводы ИБП, IP-адреса, VLAN, договор и дата вывода из эксплуатации. Вести такой учет можно в таблице, но уже с трёх-четырёх стоек надёжнее переходить на DCIM-систему с интерактивной картой размещения. Ключевое требование — единый источник данных, а не пять разрозненных файлов у разных инженеров.

Что фиксировать по каждой единице оборудования

Минимальный паспорт устройства включает инвентарный и серийный номер, вендора и модель, конфигурацию (CPU, объём RAM, диски, RAID-контроллер), MAC-адреса интерфейсов, адрес IPMI/iLO/iDRAC, потребляемую мощность и занимаемые юниты. Отдельно отмечается ориентация: смонтирован сервер спереди или сзади, на каких направляющих, требует ли обслуживания с холодного коридора.

Дальше — связи. Каждый сетевой порт сервера должен быть привязан к конкретному порту коммутатора с указанием скорости и режима (access или trunk), каждый блок питания — к своей розетке PDU и линии ввода. Без этого простая замена сервера превращается в раскопки: инженер вытягивает патч-корд и смотрит, что погасло. Ещё полезно фиксировать резерв — юниты, забронированные под будущую поставку, чтобы их не занял другой проект.

Стандартные размеры, от которых считают ёмкость стойки

Планирование ёмкости опирается на несколько закреплённых стандартом величин. Значения ниже — общепринятые для 19-дюймовых стоек; конкретные модели производителей могут отличаться, особенно по глубине и допустимой нагрузке.

Полезно отдельно вести три счётчика: свободные юниты, доступная мощность на стойку в кВт и свободные порты доступа. Упирается проект чаще в мощность и охлаждение, а не в физическое место — плотные конфигурации с GPU заполняют лимит по питанию задолго до последнего юнита.

Инструменты: от таблицы до DCIM

Схема в электронной таблице работает, пока стоек мало и изменения редки. Её слабое место — рассинхронизация: сервер переехал, таблицу поправить забыли, и через полгода данным никто не верит. Специализированные системы решают это иначе: они опрашивают оборудование по SNMP, IPMI и Redfish и сами подтягивают состояние. Хороший пример подхода — платформа для управления ИТ-инфраструктурой, где интерактивная карта показывает свободные, занятые и зарезервированные юниты, ошибки оборудования, состояние подключений, показания датчиков температуры и потребление электроэнергии, а мониторинг серверов и прогноз отказов компонентов ведётся на физическом уровне без установки агентов.

Практическая ценность такого класса решений — в объединении разных учётных контуров. Управление сетевым оборудованием: подключение устройств к портам, контроль нагрузки, изменение скорости и режима порта (trunk), объединение серверов через VLAN. IPAM: учет свободных и занятых адресов IPv4/IPv6, объединение сетей в пулы, ручная и автоматическая выдача, проверка в DNSBL, история выдачи и освобождений. Работа с ИБП и PDU: учет подключений, включение и выключение портов, контроль состояния батарей, тарификация питания для colocation. Отдельный блок ITAM закрывает жизненный цикл — инвентаризация от закупки до вывода из эксплуатации, приход с накладными и стоимостью, история эксплуатации, сервисные контракты, справочник контрагентов. Подробнее об этом написано на сайте разработчика.

Регламент, без которого учет разъезжается

Данные устаревают не из-за инструмента, а из-за процесса. Работает простое правило: любое физическое действие в стойке отражается в системе до того, как инженер вышел из машзала, а не «в конце недели». Монтаж, демонтаж, перекоммутация, замена диска, освобождение IP — каждое событие с автором и датой.

Маркировка должна совпадать с записями: наклейка с инвентарным номером на корпусе, бирки на обоих концах патч-кордов, нумерация юнитов на стойке. Раз в квартал имеет смысл проводить сверку — выборочно, скажем, по двум стойкам, а не по всему залу; расхождения находятся почти всегда, и чем реже сверка, тем их больше. Ещё один рабочий приём — открыть часть данных владельцам серверов через личный кабинет: самостоятельная установка ОС, перезагрузка, контроль потребления трафика снимают с администраторов поток рутинных заявок. Для крупных площадок пригодится API и готовые модули интеграции с биллингом и Service Desk, чтобы заявка на монтаж и запись в учете создавались одним действием.

Начните с малого: опишите текущее размещение до уровня юнита, промаркируйте кабели и сведите питание и сеть в один документ. Когда карта стойки перестанет расходиться с реальностью, переносите её в DCIM и подключайте автоматический сбор данных. Дисциплина обновления записей даёт больше, чем любая функциональность системы.