2026 年的一次扩容评审会上，网络组把 phpIPAM 的界面投到屏幕上：某个 /20 的子网还剩 300 个可用地址。机房组紧接着打开 RackTables：A 区还剩 6 个 U 位。会议室里立刻出现两种结论，一边说地址够用，一边说机柜上不下了。会后复盘才发现，两份数据一个字都没错，错的是把它们放进同一张结论表里比较。
那 300 个地址分散在十四个 VLAN 里，其中九个 VLAN 只在各自那台接入交换机上有网关；剩下的 6 个 U 位落在三个不同机柜，一个机柜的电源模块已经满载，一个机柜背板走线槽塞满，第三个机柜空出来的位置在 42U 顶部，抬上去要先拆门。台账真正给出的不是还剩多少，而是还剩的能不能配对。
这也是机房台账类系统最容易被低估的地方：它不产生业务流量，不跑前端页面，机器配置可以很低，但它决定了扩容决策的起点。起点错了，后面买的每台服务器都在补这个错。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
phpIPAM 的主键是网段与地址，RackTables 的主键是机柜、U 位与端口。这两个主键之间没有天然的外键约束，只有业务上的对应关系。一旦把它们混成一本账，最常见的写法就是在 RackTables 的设备备注里手敲一行 IP，或者在 phpIPAM 的地址描述里写"放在 B12 柜"。这两种写法在录入当天都很好用，三个月后就会变成谁也不敢删的历史注释。
混用的代价是可追溯性断裂。当一台设备下线，地址账里那条记录该不该释放、机柜账里那个 U 位该不该清空、交换机端口该不该标记空闲，三件事需要同时发生。写在备注里的信息不具备触发能力，只能靠人记得。人一旦换岗，这些备注就变成了不可验证的传闻。
合理的分工是明确的：地址的权威源只有 phpIPAM，物理位置与端口连通的权威源只有 RackTables，两边各存一个指向对方的标识字段，但任何一方都不允许覆盖另一方的权威字段。判定标准很简单，问一句"这条信息如果错了，谁负责改"，答案唯一，账就分对了。
phpIPAM 记的是子网、VLAN、地址段，以及地址归属于哪个客户、哪台设备。它的结构看起来简单，出问题几乎都出在命名与分层上。一个常见的失控路径是：最初按"用途"建子网，比如办公、测试、生产；后来加了第二个机房，于是变成"机房加用途"；再后来接手了一个收购来的网段，命名规则又多一套。三年后打开地址树，没有人能一眼看出某个 /24 属于哪个站点。
比较稳的做法是四层固定：站点、功能区、VLAN、子网。站点层用机房代号，功能区层只放少量稳定分类，VLAN 层承载真正的隔离边界，子网层才是地址段。四层之上不再加维度，客户归属、设备归属这类信息放进字段，不要放进层级名字里。层级一旦被当成标签用，就再也收不回来了。
这里有一个与直觉相反的地方：地址段划得越细，扫描发现的成本越高。每多一个子网，就多一个探测目标集、多一份网关与掩码的对应关系、多一次误报的可能。把一个 /22 拆成八个 /25 并不会让管理更清晰，只会让扫描任务的目标列表更长、失败重试更多。划分粒度应该跟着隔离需求走，而不是跟着"看起来整齐"走。
VLAN 与子网的关系也要在台账里写清楚是对应还是复用。一个 VLAN 承载多个子网、一个子网跨多个 VLAN，这两种情况在真实机房里都存在，但含义完全不同。前一种是三层接口做在同一个广播域上，后一种往往意味着二层延伸到了别的机柜。台账里如果不区分，排障时会先怀疑错方向。
地址利用率的口径也要在台账里定死，否则每个季度会得出不同的结论。三个数最常被混用：已登记地址数除以子网容量、扫描在线数除以子网容量、已分配但保留的地址数除以子网容量。第一个数偏高，因为登记了没用的地址不会自动消失；第二个数偏低，因为防火墙策略与主机防火墙会让一部分设备不响应探测；第三个数最接近真实可分配余量，但需要额外维护保留标记。台账要做的不是选一个数，而是把三个数都算出来并标明口径，让看数的人自己判断。
phpIPAM 带扫描代理，用 ping 和 SNMP 去做发现，靠 cron 定时触发。很多团队上线第一天就把扫描周期设得很短，理由是"想知道设备在不在"。这一步就把工具用错了方向。台账要的是变更可见，也就是"新出现的地址有没有登记、登记的地址有没有消失"，而不是秒级的在线状态。秒级状态属于监控系统，用同一个机制去做两件事，会同时做不好。
扫描任务的网络代价是可以估算的：单轮探测的报文量大致等于目标地址数乘以每地址探测次数，再乘以单包字节数，需要按压测确认。真正麻烦的不是带宽，而是接入交换机的管理面。SNMP 查询打在几十台接入交换机上，管理 CPU 会被拉起来，而管理面 CPU 一高，生成树收敛、链路聚合协商这些控制面动作的响应就会变慢。业务流量不受影响，但网络会变得"反应迟钝"。
所以扫描范围要分组。核心与汇聚设备一组，接入交换机按机柜或按楼层分组，服务器网段与办公网段分开。每组给独立的执行窗口，不要一次性铺满。ICMP 与 SNMP 也要分开调度，ICMP 便宜且可以放宽频率，SNMP 贵且必须限量。把两者绑在同一个任务里，等于用最贵的那个决定整体节奏。
还有一个常见误判：扫描发现出来的"未知设备"数量，经常被当成安全事件上报。多数情况下它们只是新上架还没登记的机器、临时测试用的虚机、或者同一台机器的第二个网卡。台账的价值在于把这些差异收敛成一条待确认记录，而不是制造一批待处理的告警。
SNMP 这一侧还有一个绕不开的管理问题：凭据怎么存、谁能看。发现任务需要读写凭据才能取到接口与描述信息，这把凭据放在了应用配置里。如果这套配置和业务代码放在同一台机器、同一份备份里，凭据的暴露面就被放大了。合理的做法是给发现任务单独一个只读凭据，权限限制在需要被发现的设备组，并且和业务系统的备份分开管理。这件事与工具本身无关，是部署时就要定的边界。
phpIPAM 的发现任务靠 cron 跑，这就带来一个非常物理的限制：上一轮没跑完，下一轮又被拉起来。表现是数据库连接数缓慢爬升、页面查询变慢、最后连登录都要等。排查时看 CPU 曲线往往很平，因为瓶颈在等待，而不在计算。
单轮任务时长可以按公式粗估：目标地址数除以单地址平均探测耗时，再乘以一加失败重试比例，然后加上 SNMP 遍历的额外开销，需要按压测确认。这个公式的用处不是算出精确秒数，而是判断"这个任务能不能塞进一个窗口"。如果估算结果已经接近窗口长度的一半，就应该拆任务，而不是提高并发。
拆任务的方式是按站点或按 VLAN 分组，把不同组放到一天里不同的时间点。这样做的副作用是台账的"新鲜度"不一致，上午扫的站点和凌晨扫的站点数据时间不同。解决办法是在台账里明确记录每个组的最后扫描时间，让读数的人知道这条数据有多旧，而不是假装全库同一时刻。
重试必须设上限。网络里总有几台设备长期不响应，如果每轮都为它们重试到底，任务时长会被这几台设备决定。更稳的做法是给单地址设最大尝试次数，把连续失败的目标单独列成一张待处理清单，交给人去判断是设备下架了还是地址记错了。
任务日志要能看出"这一轮扫了多少、跳了多少、失败多少"。这三个数比任务成功与否的布尔值有用得多。很多团队只留一个成功标记，出问题时无法判断是全部扫完还是中途退出，于是只能重跑一轮，而重跑又叠加了新的峰值。日志颗粒度这件事，在台账系统里比在业务系统里更值得投入。
RackTables 记的是机柜、机位（U 位）、设备、端口、链路和 IP 分配，这套模型的强项是物理可追溯。它能回答一个非常具体的问题：某台服务器的第一块网卡，插在哪台交换机的第几个口上，这根线经过哪个配线架，另一端在哪个机柜。这类问题在故障定位时值钱，在资产盘点时也值钱。
它的弱项同样明显：电源与承重通常不在工具的核心模型里。一台 2U 双路服务器上架，U 位够不代表能上，还要看这个机柜的 A、B 两路各剩多少安培，看机柜标称承重和实际已装重量，看冷通道这一侧的送风是否被挡住。台账里如果不记这些，扩容评审时给出的"还剩 6 个 U 位"就是一个不完整的结论。
端口记录最常见的错误是只记一端。只写"服务器 eth0 接到 A 柜交换机 1 口"，不写交换机这一侧的对应关系，等于把一条链路记成了一条射线。真正的价值在双向：从设备能查到端口，从端口也能查到设备。RackTables 的链路模型本身支持双向，问题出在录入习惯上，很多团队为了省事只填一半。
另一个容易被忽略的字段是设备的下架时间。机柜账如果只做增不做减，三年后 U 位占用率会虚高，扩容决策会偏保守，最后买了一整排新机柜去放那些其实已经空出来的位置。保留历史记录是必要的，但必须在查询视图里默认过滤已下架设备。
配线架这一层要不要建进台账，是个成本与收益的权衡。建进去，链路可以精确到跳线，故障定位能从设备一路查到另一个机柜；代价是每次跳线变更都要录两次。多数机房的实际做法是核心链路与跨柜链路建到配线架，同柜内的短跳线只记两端设备端口，这样既保住了追溯能力，又不至于让日常变更变成负担。
先看数据量级。三千台设备，每台平均几十个端口，端口表大致在十万行这个量级；子网与地址表按子网数与平均容量估算，通常在几十万行以内；再加上链路、机柜、设备属性，整个库的体积多在几 GB 这个区间。写入极少，一天可能只有几十次到几百次变更，查询很多，但都是小结果集。
这个画像决定了配置方向：单核性能与内存比核数重要，数据库所在磁盘的随机写稳定性比容量重要，扫描任务与页面查询之间的资源隔离比整机峰值性能重要。把这类系统配成一台高核数机器，实际跑起来 CPU 长期在低位，钱花在了用不上的地方。
真正会咬人的是两件事。第一件是扫描任务与页面查询撞在一起，长事务把连接池占住，用户在页面上点一下要等几秒。第二件是 cron 任务堆积，多个任务实例同时持有数据库连接，连接数打满。这两件事都不是加核心能解决的，靠的是任务调度与连接管理。
可用性要求反而比性能要求高。台账挂了不会影响业务，但会影响所有变更流程与故障排查，等于让整个运维团队临时失去地图。所以这类系统的配置重点应该放在磁盘可靠性、备份可恢复性和开机自愈上，而不是压测跑分。预算分配上，一块稳定的企业级盘加一套可靠的备份，优先级高于多两颗 CPU。
内存的估算方式也值得一提。数据库在这类负载下的热数据几乎等于全库，也就是说几 GB 的库配上能完整缓存它的内存，查询就基本不落盘。这个判断可以粗算：全库体积乘以一个放大系数，再留出系统与连接的开销，需按实际库体积确认。反过来，如果给的是一条慢速共享存储，即使内存充足，写入路径上的抖动也会让扫描回填变慢。
对齐的锚点应该是设备本身，而不是 IP 或 U 位。设备有序列号或资产编号，这个编号在两套系统里都存一份，就成为唯一可信的桥。位置信息记在 RackTables，地址归属记在 phpIPAM，两边都通过设备编号指向彼此，而不是互相复制对方的字段。
对账要定期做，方式是比对而不是同步。拿扫描发现的结果去比对 RackTables 的端口与设备表：扫描到有响应的地址，在地址账里有没有登记；登记了地址的设备，在机柜账里有没有位置；机柜账里有位置的设备，对应端口有没有连线记录。三个方向的差集就是当期的待确认清单。
不建议让两个工具互相写。接口能打通，但写入方一旦出错，错误会被复制到两边，且很难判断哪一边是原始值。离线对账加人工确认虽然慢，但每一次修改都有明确的责任人和时间点。台账这种东西，慢一点比错一点好。
如果一定要做自动化，让自动化只做"发现差异并生成工单"，不做"直接改数据"。差异单在流转过程中被人看过一眼，价值就已经产生了；直接改数据省下的那点人力，通常会在半年后以一次账实不符的排查成本还回来。
发现任务扫到响应，第一步通常是把未知地址自动建进库。这一步要不要全自动，取决于这个库被谁信任。全自动的好处是覆盖快，坏处是误报会变成正式记录：一台临时接进来的测试机、一个配错网关的地址、一段来自其他网段的漂移地址，都会被写进正式台账，之后没人分得清哪些是确认过的。
比较稳的分层是：扫描只负责生成候选记录，候选记录带一个明确的状态字段，比如待确认。运维确认之后才转成正式分配。这个状态字段不能省，它决定了后面所有统计口径的干净程度。省掉它，三个月后地址利用率就无法解释，因为里面混着大量从未被确认的候选。
反方向也要防：确认动作太麻烦，人就会绕过它，直接在库里手改，状态字段全部变成确认，等于没有。确认应该是一步操作，能批量处理，能带上默认的责任人。凡是需要填五个字段才能确认的流程，实际执行率都会很低。
还有一个折中做法值得用：按网段设策略。核心设备网段与生产网段走人工确认，临时测试网段与办公网段走自动入库但打标记。同一个工具在不同网段上用不同策略，比全库统一策略更贴近实际。
字段约束是这类系统能不能长期用下去的分水岭。第一条是设备唯一标识：序列号或资产编号必须唯一且有格式校验，不允许空着。空值一旦出现，后面所有跨系统对齐都会在这条记录上断掉。
第二条是位置字段的枚举化。机柜编号不要让人自由填写，用固定列表或固定格式。自由文本的后果是同一个机柜出现三种写法，比如带不带连字符、大小写不同、楼层前缀有无，查询时全部漏掉。这种问题在数据量小的时候看不出来，等到要按机柜统计时才发现无法聚合。
第三条是状态字段的取值集合固定。在用、备用、维修、下架四种状态足够，不要加"临时""待定""观察中"这类模糊值。模糊状态会让统计口径失去意义，也会让下架流程卡住，因为没人知道临时状态该由谁清理。
第四条是时间字段成对出现。上架时间与下架时间必须成对，分配时间与释放时间必须成对。只有开始没有结束，历史就无法切片，任何"某月底的在用数量"这类问题都答不出来。这四条约束都不涉及工具选型，任何一套台账系统都能做到，区别只在于有没有人在上线第一天坚持。
下面这张表把两个工具放在同一组维度上对照，重点不在谁更强，而在每一项该由谁负责。判断依据只有一条：这条信息出错时，谁有能力独立验证它。
| 维度 | phpIPAM | RackTables | 扩容评审时的用处 |
|---|---|---|---|
| 地址空间 | 核心能力，子网、VLAN、地址段与客户设备归属都在这里维护，是地址的唯一权威源 | 只记录设备占用了哪个地址，属于附属信息，不作为地址分配依据 | 先看地址表，能给出“还有多少地址可分配”，但给不出“还能上几台机器” |
| 机柜与 U 位 | 不涉及，无法回答某台设备在第几柜第几 U | 核心能力，机柜、机位与设备占位关系完整，可直接算剩余 U 位 | 先看机柜表，能给出物理空间余量，但不判断地址是否够用 |
| 端口与链路 | 只能通过扫描推断设备在线，看不到物理连接关系 | 核心能力，端口、配线架与链路可双向追溯，能回答哪根线插在哪个口 | 扩容前先查端口余量，避免机器到位却没口可插 |
| 扫描发现 | 自带扫描代理，用 ping 与 SNMP 做发现，由 cron 定时触发，可回填未知地址 | 无主动发现能力，设备与端口靠人工或导入维护，账实差异需外部比对 | 发现任务的结果可用来纠账，但不能替代人工核对 |
| 定时任务 | 发现任务依赖 cron，任务窗口会自造网络与管理面峰值，必须错峰与限速 | 无同类高频任务，压力主要来自页面查询与批量导入 | 排期时把发现任务与业务高峰错开，否则扩容前先出告警 |
| 适用场景 | 多网段、多 VLAN、地址分配频繁、需要按客户或业务追溯归属的环境 | 机柜密集、布线与端口变更频繁、需要按物理位置做资产与故障定位的环境 | 两个工具回答的是两个问题，评审表要把两栏都填上 |
| 主要短板 | 不知道设备物理在哪，地址利用率高估时容易误判可扩容空间 | 地址视角弱，缺少主动发现，长期不做减账会虚高占用率 | 短板对应的是误判方向，不是能用不能用的结论 |
表格里最值得多看一眼的是"主要短板"那一行。两边的短板恰好互为对方的长处，这也是为什么很多机房最后两个都装了，而不是二选一。装两个的成本不高，维持两个都准的成本很高，后者才是真正的门槛。
如果只允许装一个，判断依据是当前最痛的问题在哪一侧。地址分配混乱、客户归属查不清，选 phpIPAM；机柜爆满、端口说不清、故障定位靠猜，选 RackTables。两边都痛的情况下，先把数据量小的那一侧做准，再补另一侧，不要同时开工。
两个都装的时候，还有一个部署细节值得提前定：两套系统要不要放在同一台服务器上。放在一起省机器，但扫描任务的峰值会直接打到主机柜页面的数据库上，用户点一下要等。分开放在两台低配机器上，成本增加有限，体验差别明显。这个判断与规模无关，与是否每天都有人在线查台账有关。
拆实例的理由通常是两个：故障域和权限。台账服务挂掉时，只影响一个机房的相关流程；外包运维只应该看到自己负责的那几个机柜。合实例的理由也是两个：地址去重和全局查询。跨机房的地址规划如果不在一个库里，重复网段会在互联时暴露出来，而那时改造成本最高。
实际经验是三个机房以内，单实例加严格命名空间更省。命名空间包括站点前缀、机柜编号规则、VLAN 编号分段，这三样定死之后，单库的查询优势会明显大于隔离带来的好处。超过五个机房，或者出现跨法域的数据落地要求，再考虑按机房拆。
多租户是另一回事。租户隔离靠的是权限模型，不是靠拆库。用拆库来做租户隔离，会在租户数量增长后变成运维灾难：每加一个租户就多一套备份、一套升级、一套监控。真正需要拆的是那些有独立合规要求、数据不能混存的租户，其余用视图与角色权限解决。
还有一种中间形态值得考虑：主库单实例，扫描任务按机房分布式部署。扫描代理放在各机房本地，探测流量不出机房，只把结果汇总回主库。这样既保住了地址的唯一权威源，又避免了跨机房的探测流量与单点探测的盲区。
权限设计上有一个容易做反的地方：按机房拆权限，而不是按角色拆。真实团队里，网络组通常跨机房管地址，机房组通常只管内网段的物理位置。按机房切权限会让网络组每次都要申请四个库的账号，按角色切则是网络组看全部地址、机房组看全部机柜，各自在自己的域里做加减。角色切分更稳，因为汇报线通常按职能而不是按机房划分。
因为库只有几 GB，很多人默认这类系统不需要认真备份，反正重建一次也就几天。这个判断忽略了一件事：台账里沉淀的是三年的变更历史与人工判断，重建数据库只要几小时，重建那些判断要几个月，而且重建出来的还是猜的。
备份策略上，逻辑备份比物理快照更重要。快照能回到某个时刻，但跨版本恢复时经常因为存储引擎或字符集问题失败；逻辑备份慢，但可读、可裁剪、可只恢复某几张表。两者都做，用逻辑备份做长期留存，用快照做变更前的即时回滚点。
恢复演练比备份本身更关键。台账的系统依赖关系不复杂，但外键引用多：删一台设备会牵连端口、链路、地址分配记录。恢复时如果只导了主表，页面能打开，点进设备详情就报错。演练的目标不是验证备份文件存在，而是验证"恢复到一台干净机器后，页面能查、能改、能导出"。
演练频率不用很高，但每次演练要留下记录：恢复到什么时间点、用了多久、发现哪些表缺失、补了什么配置。这份记录本身就是运维能力的证据，也是下一次扩容或迁移时的施工依据。很多团队在机柜搬迁前一晚才发现台账恢复不了，原因就是从来没演练过。
还有一个细节：扫描任务的配置文件与 cron 条目也要一起备份。这两样东西不在数据库里，恢复时最容易漏，漏了之后表现为"数据都在，但发现任务不再运行"，而这种沉默的失效往往几周后才被发现。
保留周期要按变更频率倒推，而不是按库体积定。库小不代表历史短，恰恰相反，这一类系统的库之所以小，是因为变更记录几乎不占空间。把保留周期定成三十天，等于主动放弃了追溯能力。合理的口径是：主表保留全量，变更历史至少覆盖两个完整的资产盘点周期，具体长度按团队盘点节奏定。这个口径成本极低，因为增长曲线几乎是平的。
下面这几条不是理论上的风险，是实际运维里反复出现的失效路径。每一条单独看都不严重，叠在一起就会让台账从"参考"变成"不敢信"。
这五条里，第四条最容易被容忍，因为它不会立刻出问题。它的问题在于让台账失去了最独特的那部分价值：物理可追溯。地址可以在扫描里重新发现，U 位可以在现场重新数，唯独端口与链路的对应关系，一旦没有记录，就只能靠断电测试去还原。
反过来，如果要判断一个团队的台账是否可信，不用看它字段多不多，看两件事就够：随便挑一台设备，能不能三分钟内查出它的地址、机柜位置、两端端口；随便挑一个网段，能不能说清里面每个地址的归属与最后一次确认时间。两件事都能做到，这套账就是活的。
还有一条不在清单里但同样致命：台账的维护责任没有落到具体的人头上。工具是共用的，责任是模糊的，结果是所有人都能改、所有人都不改。比较有效的安排是每人认领一段地址空间或几个机柜，变更由认领人确认，季度盘点的差异也由认领人解释。这件事不增加任何软件成本，但决定了台账在半年后还剩多少可信度。
五百台设备以内，两套系统可以和轻量业务合用一台机器。这个规模下数据量很小，扫描目标集不大，任务窗口宽松。配置上优先保证磁盘可靠与备份可用，CPU 与内存按常规规格即可，剩余资源留给别的小服务。这个阶段最该做的是把命名规则和字段规范定死，而不是纠结机器配置。
三千台左右是一个分水岭。扫描目标集已经足够大，单轮任务时长会明显拉长，任务窗口开始紧张；页面并发不高但查询频次上升。这时值得把数据库单独放一台，把扫描代理与应用分开，让任务峰值不直接影响页面。带宽方面，机房内部探测流量很小，但跨机房汇总需要稳定的内网互通，带宽规格按探测目标集规模估算，需按压测确认。
一万台以上，重点转向分区与权限。单库仍可支撑，但扫描必须按机房或按网段分区部署，任务调度要能互相隔离，避免一个区域的异常拖慢全局。这个规模下建议把台账的读取路径做一层缓存或只读副本，让报表类查询不去打扰主库。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付，机房台账类系统的部署机型与带宽规格以官网实时信息或咨询确认为准。多机房场景下，跨机房的探测与汇总走内网互联更稳，具体链路规格与参考预算需按目标集规模询价。
三种规模共通的判断是：不要按"未来可能到一万台"去配第一台机器。台账的性能曲线很平，真正会变的是任务调度复杂度与权限复杂度，这两样靠架构调整解决，不靠提前堆硬件。反过来，也不要因为"才五百台"就省掉备份与演练，那部分成本与规模无关。
对不上是常态，关键是查的顺序。第一处查扫描任务本身：最近一轮任务是否完整跑完、有没有因为超时被截断、失败重试是否把部分网段跳过了。任务不完整时，地址账看起来"少了设备"，实际是没扫到，这时候去动机柜账会越改越乱。
第二处查设备的下架与迁移记录。很多差异来自设备换了机柜但只改了其中一本账，或者设备已经下架但两本账都还留着。查这个要看变更时间线，把最近三个月的迁移单、下架单、上架单拉出来，按设备编号对齐，差异通常能解释掉大半。
第三处查端口与链路的记录完整性。设备在、地址在、位置也在，但对不上，往往是因为端口记录只写了一端，导致链路的另一端指向了错误设备。这类差异不会表现为"缺失"，而会表现为"串位"，也就是两台设备的连接关系互换了。
三处查完还有剩余差异，才轮到怀疑数据录入错误。把排查顺序倒过来，先怀疑人，会让团队把时间花在互相核对上，而真正的原因往往在任务调度与变更流程里。台账对不上的本质，多数时候不是记错了，而是没记全。
三千台这个量级，单实例完全撑得住，拆开反而增加负担。理由不在于性能，而在于地址规划需要全局视角。三千台设备通常分布在两到四个机房，跨机房的网段复用、互联地址、带外管理地址都需要在一张表里看，拆开之后每次规划都要人工合并视图。
但单实例不等于单点。可以用一台主库加一个只读副本，主库承担写入与扫描结果回填，副本承担报表与跨机房查询。扫描代理仍然按机房分布部署，探测流量不出机房，只回传结果。这样既保住了唯一权威源，又把故障影响面控制住。
真正需要拆的信号有三个：机房数量超过五个且各自有独立运维团队；出现跨法域的数据落地要求；单个机房的变更频率高到会影响其他机房的页面响应。三个信号都没出现，就不要拆。拆开容易，再合回去要处理网段冲突与历史记录合并，成本高得多。
最后一个提醒与采购有关。台账这类系统的服务器配置需求很低，但机柜托管位、内网互联带宽、备份存储这三项是持续成本，往往比机器本身更值得算清楚。选型时把这三项一起放进预算表，比只比机器月付更能反映真实支出。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
