企业官网建设流程全解析

• 后端
• 网络
• 数据建模

机架（Rack）是 NetBox DCIM 中承载物理设备的核心对象，本指南基于仓库 docs/models/dcim/rack.md 展开，深入讲解机架模型的字段语义、U 单位编号规则、物理属性定义，并结合 netbox/dcim/models/racks.py 的源码剖析Rack、RackType、RackGroup、RackRole之间的继承与校验逻辑。读完本文，你将掌握如何在 NetBox 中正确建模机架、如何利用 Rack Type 统一管理物理属性，以及如何理解 NetBox v5.0 对机架模型字段的废弃与迁移方向。

机架模型定位：物理设备的"安放载体"

机架模型表示一个物理的两柱或四柱设备机架，设备（Device）安装于其中。每个机架必须归属于一个站点（Site），并且可以（可选地）归属于该站点内的一个位置（Location）。机架还可以通过用户自定义的功能角色（RackRole）或按物理部署位置划分的机架组（RackGroup）来组织。

在源码层面，这一层级关系体现得非常清晰（见 netbox/dcim/models/racks.py#L324-L343）：

• site：必填外键，指向dcim.Site，on_delete=models.PROTECT；
• location：可选外键，指向dcim.Location，on_delete=models.SET_NULL；
• group：可选外键，指向dcim.RackGroup，用于按物理放置分组。

其中两个关键约束由数据库唯一约束直接保证（见 racks.py#L405-L415）：

1. 同一 Location 内，机架Name 唯一；
2. 同一 Location 内，机架Facility ID 唯一。

这正是文档所述"每个位置内机架的名称和设施 ID 必须唯一"的数据库级实现。此外，clean()方法（racks.py#L427-L473）还会校验"所属 Location 必须与所属 Site 一致"，防止站点与位置归属错乱。

机架高度与 U 单位编号

机架高度以机架单位（rack units，U）度量，常见机架高度为 42U～48U，但 NetBox 允许定义任意高度的机架。同时提供一个开关来指示机架单位是升序（从地面向上，自下而上编号）还是降序排列。

源码中对应字段（racks.py#L70-L86）：

units属性（racks.py#L498-L505）返回自上而下排列的 U 编号列表，并支持 0.5 步长的半 U 单位（半高设备）：

• 降序（desc_units=True）：从starting_unit开始递增 0.5；
• 升序（默认）：从顶部u_height + 0.5 + starting_unit - 1开始递减 0.5。

这一机制直接支撑了机架正视图（rack elevation）、可用 U 计算（get_available_units，racks.py#L573-L611）与利用率统计（get_utilization，racks.py#L664-L682）——利用率同时把已安装设备占用的 U 与保留（reservation）占用的 U 都计为已用空间。

字段详解

Site 与 Location

• Site：机架所属的站点，必填（racks.py#L324-L328）。
• Location：机架在站点内安装的位置，可选（racks.py#L329-L335）。校验逻辑要求 Location 与 Site 必须匹配。

Rack Group 与 Name

• Rack Group：用于按物理放置组织机架的 组，可选（racks.py#L336-L343）。
• Name：机架名称或标识符，在所属 Location 内必须唯一（由UniqueConstraint(fields=('location', 'name'))保证，racks.py#L407-L410）。name字段还使用了natural_sort排序规则，实现人类直觉的自然序排列。

Rack Type（机架类型）

物理类型（RackType）定义了机架的物理属性，如高度和重量。在 NetBox 中，RackType与Rack共享同一个抽象基类RackBase（racks.py#L58-L161），两者的宽度、U 高度、起始单位、外尺寸、安装深度、重量、冷却能力等字段完全同构——这正是"机架继承类型属性"能够成立的类层次基础。

RackType本身（racks.py#L167-L264）还包含：

• manufacturer：必填的制造商外键（on_delete=models.PROTECT）；
• model：型号名称，与制造商组合唯一；
• slug：唯一标识；
• form_factor：形态因子（2-post frame、4-post frame、4-post cabinet 等，见下文）；
• rack_count：CounterCacheField计数器，缓存引用该类型的机架数量。

⚠️重要变更预告：从 NetBox v5.0 起，机架类型的分配将变为必填，多项物理属性将从机架类型推断而非直接在机架上设置。详见下文"Physical Attributes 与字段废弃"一节。

Status（状态）

机架的操作状态。NetBox 内置以下状态（见 netbox/dcim/choices.py#L102-L117 的RackStatusChoices）：

默认状态为active（racks.py#L351-L356）。该 ChoiceSet 的key为'Rack.status'，因此可通过配置参数FIELD_CHOICES下的Rack.status增加自定义状态，扩展内置状态集。

Role（功能角色）

机架承担的功能 角色（RackRole），可选。RackRole是一个组织模型（OrganizationalModel），额外带有一个color颜色字段，默认灰色（racks.py#L271-L283），用于在 UI 中标识角色。

Facility ID、Serial Number 与 Asset Tag

• Facility ID：由设施运营商（如托管机房）分配的替代标识符（racks.py#L317-L323）。正如文档示例：托管机房往往给机架分配看似任意的编号（如M204.313），而内部则称其为R113——此时 Name 用内部名，Facility ID 记录外部编号。同一 Location 内facility_id同样唯一（racks.py#L411-L414）。__str__在有 Facility ID 时会输出"R113 (M204.313)"形式（racks.py#L422-L425）。
• Serial Number：机架的唯一物理序列号，字符串字段，可为空。
• Asset Tag：本地管理的唯一资产标签，用于标识硬件资源，字段带有unique=True约束（racks.py#L370-L377）。

其他字段

Rack模型还包含tenant（租户外键，可选）与airflow（气流方向，可选）字段，以及用于支持 VLAN 组作用域的通用关系vlan_groups（racks.py#L386-L392）。

冷却能力（Cooling Capability）与冷却容量（Cooling Capacity）

NetBox 对高密度液冷等新型散热场景提供了显式建模支持，文档将其列为机架的核心字段之一：

• Cooling Capability（冷却能力）：描述机架如何冷却其内部设备，从而表明它能容纳何种设备。可选值定义在RackCoolingCapabilityChoices（netbox/dcim/choices.py#L2243-L2252）：

该属性记录了机架的预期用途，从而可以识别"不兼容"的部署——例如把高密度液冷硬件放进仅风冷机架。字段定义见 racks.py#L139-L145。

• Cooling Capacity（冷却容量）：机架的冷却容量，以**千瓦（kW）**为单位，DecimalField（max_digits=10, decimal_places=2），最小值校验为 0（racks.py#L146-L154）。

当机架分配了 Rack Type 时，这两个值都会从机架类型继承——这是由Rack.save()中的copy_racktype_attrs()调用完成的（详见下一节）。

Physical Attributes（物理属性）与 Rack Type 继承机制

机架可以在自身定义多项物理属性：宽度、高度、外部尺寸、安装深度和重量。文档建议这些属性优先定义在 Rack Type 上，而不是直接写在机架上。

源码中RackBase定义的全部物理属性（racks.py#L58-L161）包括：

Rack.save()首先调用copy_racktype_attrs()（racks.py#L475-L496）：一旦分配了rack_type，就按RACKTYPE_FIELDS元组（racks.py#L291-L296）把 Rack Type 上的 15 个物理属性逐一复制到机架实例上。测试用例test_rack_creation（netbox/dcim/tests/test_models.py#L345-L377）正是验证了这一行为：创建机架时只指定rack_type，随后断言rack.width、rack.u_height、rack.starting_unit、rack.desc_units、rack.outer_width/depth/unit、rack.weight/weight_unit、rack.max_weight、rack.mounting_depth以及冷却能力/容量全部与机架类型一致。

反过来，RackType.save()（racks.py#L238-L255）在保存后会遍历所有关联机架（self.racks.all()），逐一执行rack.snapshot()（记录变更日志快照）、rack.copy_racktype_attrs()并重新保存——也就是说，修改机架类型的物理属性会同步传播到所有引用它的机架。

废弃字段与 NetBox v5.0 迁移方向

文档明确警告：以下字段在机架模型上已被废弃，计划在 NetBox v5.0 移除：

• Form factor（形态因子）
• Width（宽度）
• Outer width（外部宽度）
• Outer height（外部高度）
• Outer depth（外部深度）
• Outer unit（外部尺寸单位）

未来版本中，这些属性将从机架分配的 Rack Type 推断，且 Rack Type 将成为必填。建议用户立即将这些属性定义在 Rack Type 上，并为每个机架分配类型。

需要特别注意的是，以下字段会保留在机架模型上，因为它们在同一类型的各个机架之间可能合法地不同：

• U 高度（u_height）
• 起始单位（starting_unit）
• 降序单位（desc_units）
• 安装深度（mounting_depth）

机架高度校验的源码逻辑

Rack.clean()（racks.py#L427-L473）还包含一组关键的容量校验，防止机架容纳不下已安装的设备：

• 有效 U 高度取rack_type.u_height if rack_type else u_height；若最高已安装设备超出机架高度，则校验失败；
• 有效起始单位同理取自 Rack Type 或机架自身；若起始单位大于最低已安装设备的位置，则校验失败；
• 相关测试见test_rack_device_outside_height（netbox/dcim/tests/test_models.py#L416）。

机架的派生能力：利用率、承重与正视图

虽然 rack.md 聚焦于字段建模，但理解这些字段如何驱动下游能力有助于更合理地填写数据：

• 空间利用率：get_utilization()（racks.py#L664-L682）计算已占用 U（含保留 U）占总 U 数的百分比；
• 功率利用率：get_power_utilization()（racks.py#L684-L703）汇总机架下所有 Power Feed 的可用功率，对比已接入 Power Port 的分配功耗；
• 总承重：total_weight（racks.py#L705-L719）累加机架内所有设备的_abs_weight（以克规范化存储，见 utilities/conversion.py 的to_grams）与机架自身重量；
• 正视图渲染：get_elevation_svg()（racks.py#L623-L662）基于RackElevationSVG（netbox/dcim/svg）生成机架正面的 SVG 渲染图。

相关模型速览

实践建议

1. 从 Rack Type 起步：为每个制造商型号建立 Rack Type（制造商 + 型号唯一），把宽度、外尺寸、重量、冷却能力等静态属性全部定义在类型上，然后为机架分配类型。这样既为 NetBox v5.0 的强制要求做好准备，也能享受"改类型自动同步到机架"的便利。
2. 善用 Name 与 Facility ID 双标识：内部名称写入name，托管机房的外部编号写入facility_id，两者在同一 Location 内各自唯一。
3. 冷却能力用于合规检查：在液冷/混合冷却场景中显式设置cooling_capability，可让 NetBox 在规划高密度液冷设备时暴露"仅风冷机架 + 液冷硬件"的不兼容组合。
4. 用状态与角色组织视图：利用status（预留/可用/规划/在役/废弃）与role区分机架的运营阶段与功能定位，并可通过FIELD_CHOICES扩展自定义状态。
5. 关注半 U 与编号方向：starting_unit与desc_units会影响正视图的 U 编号顺序与可用空间计算，按机房实际编号习惯设置，避免设备定位错位。

• 后端
• 网络
• 数据建模