TL;DR SCCM IP 地址范围边界 0.0.0.0-255.255.255.255 是否会导致重大性能问题？
我们开始推出 SCCM（目前为 1702）作为 Windows 修补解决方案。我们有一个由许多 AD 域和 IP 子网组成的复杂网络，我认为唯一可行的边界解决方案是 IP 地址范围（因为 SCCM 不了解超网），但随着新子网上线，我发现边界管理起来变得繁琐。
目前我们只有一个主站点服务器，所有客户端都向其报告。我阅读了大量有关 SQL 密集型 IP 边界计算的内容，并试图了解最佳选择是什么。更大的范围？还是更多、更小的范围？
现在，我已经获得了我们常用的私有 IP 前缀的 IP 地址范围边界，并且刚刚为整个 /8 范围创建了 IP 范围，以涵盖具有该前缀的所有 /24 子网。
示例：192.0.0.0-192.255.255.255 的边界涵盖多个 192.168.xx 子网。
如果我将边界重新设计为 0.0.0.0-255.255.255.255 的一个边界，这会导致性能问题吗？如果我添加第二个站点服务器，我希望某些子网向该站点服务器报告，那么我会得到类似以下内容：
0.0.0.0-191.168.9.255 > 边界组 1/站点 A
192.168.10.0-192.168.50.255 > 边界组 2/站点 B
192.168.60.0-255.255.255 > 边界组 1/站点 A
在高端，我们关注的是大约 10,000 个客户端，所以我不知道有关这些 SQL 性能问题的文章是否适用于更大规模的安装，或者整个问题是否被夸大了。
答案1
你应该咨询专业人士。我猜你有 10,000 个客户，所以你有几个实体网站，这将是钥匙在设计 SCCM 边界时。此处的一半目的是确保客户端与本地管理服务器通信。另一半目的是确保在管理方面不会失去理智。
我没有看到提到物理站点，而将 IP 子网与物理位置对齐可能需要大量工作。
我还发现您的示例 IP 范围存在问题。您应该首先仅包含您的私人的IP 空间，无论是 10.0.0.0/8、192.168.0.0/16 还是 172.16.0.0/12。
每个组织都是不同的，但如果您的 Active Directory 站点处于“良好”状态，这可能是配置 SCCM 边界的更好选择。
答案2
在我看来，IP 范围边界并不坏，因为：
- 我们不需要手动创建 IP 范围，相反，Active Directory 网络发现将根据 IP 子网为我们创建所有 IP 范围。
- 用于 MP、DP、SMP 或 SUP（新功能）的不是边界，而是边界组。所有站点系统都与边界组相关联，而不是边界。
因此，如果您有许多物理位置，只需创建一些边界组（添加相应的边界作为成员资格）与相应的站点系统服务器关联，我认为这应该在许多场景中发挥作用。