组更新提供补充解决方案：

    客户端与 SEPM 心跳通信方式和周期：

    由于 SEPM 利用 IIS 与所有客户端进行基本心跳通信（包括检查是否在线，策略推送，日志收集，以及当选择 客户端从 SEPM 获得内容更新时的内容更新的推送），因此当客户端数目越多，通信周期越短时，对 SEPM 服 务器的 IIS 的负担越大。

    1、推模式和拉模式：在推模式下，客户端首先发起与 SEPM 的通信，进行一次心跳通信后客户端与 SEPM 建 立永久的通信通道直到客户端服务停止。在这种模式下服务器对客户端的命令可以第一时间到达客户端， 但是每一个在线的客户端都会占用 SEPM 的 IIS 的一部分资源。而与之对应的拉模式下，每个客户端与 SEPM 完成一次心跳通信后就会断开与 SEPM 的 IIS 的连接，而下次通信后重新在建立连接。因此我们建 议当一个 SEPM 所管理的客户端数目达到或者超过 200 个时，采用拉模式进行通信。

    2、心跳周期：默认的心跳周期是 5 分钟一次。心跳周期越短，对 SEPM 的 IIS 的负担越重，以及对企业的网 络负担也会越重。建议对于客户端数目超过 1000 台以上的 SEP 部署，增加心跳周期为 1 小时以上（但是 不要超过 3 个小时）。

    在单站点，单服务器模式下，所有的客户端都与 SEPM 通信，以维持心跳状态，上传日志，下载内容更新。在 这些通信当中，下载内容更新无疑是数据量最大，占用带宽比例最大的通信。另外，很多 Symantec Antivirus 的老用户有在各个分支机构部署二级 SAV 服务器，各个分支机构的客户端从该地的二级服务器获得病毒定义更 新的管理习惯。根据以上的情况和需求，在 Symantec Endpoint Protection，引入了组更新提供者。组更新提供者是一个特殊的 SEP 客户端，起到对小规模的 SEP 客户端提供内容更新的作用。

    下面是对于组更新提供者的非常好的实践建议：

    1、对于每一个客户端组，只能设置一个组更新提供者（当然可以不设置组更新提供者，这样的话所有客户端 直接向 SEPM 获得更新），而这个组更新提供者必须是这个客户端组的一个客户端。

    2、在一个客户端组设置了组更新提供者以后，这个客户端组的客户端还是会以心跳周期与 SEPM 进行通信， 维持心跳状态，上传日志等等。客户端一旦发现 SEPM 中有更新的内容更新，会联系组更新提供者要求下 载内容更新。

    3、当客户端无法连接到组更新提供者时，默认情况下会重新连接 SEPM 获得内容更新。SEP11.0 MR3 以后， 有组更新提供者 Bypass 高级选项，以设定即使连不上组更新提供者，也不连接到 SEPM。这样，可以保 证客户端永远只能从组更新提供者获得内容更新，保证 SEPM 的通信性能。

    4、在一个客户端组设置了组更新提供者以后，可以做到这个客户端组中只有组更新提供者一个客户端向 SEPM 获得内容更新，而其它的客户端都向组更新提供者获得更新。因此组更新提供者一般使用在客户端数目不 是很多的分支机构，以减少分支机构与总部 SEPM 之间的通信数据量。

    5、毕竟组更新提供者只是一个客户端，性能有限，建议一个组更新提供者最多为 100 个客户端提供更新。如 果一个分支机构有不超过 100 个客户端，可以划分为一个客户端组，并且从一个组更新提供者获得更新； 如果有超过 100 个客户端，建议划分为多个客户端组，每个组有不同的组更新提供者。

    6、在SEP11.0.5000版本以后，会对于组更新提供者，在功能上和性能上有非常大的提升，使得组更新提供者 能够满足更多的需求。但是以上的建议还是可以满足基本的组更新提供者的需求，并且使用上比较稳定，建议用户使用。

    什么样的情况适合此部署模式？

    这种部署方式下，Symantec Endpoint Protection 只有一个站点，也就是只有一个 SQL server 数据库（通常是 在总部），然后根据需要添加多台 SEPM 与此 SQL server 数据库连接。

    通常情况下，有以下两种需求时可以使用单站点，多服务器解决方案。一是用户有负载均衡，容错的需求；二 是用户的客户端集中分布于若干个地理位置，有统一管理的需求以及各地的服务器之间通信链路比较好。

    服务器系统要求：

    关于最低系统要求，请参考 Installation Guide。基于常见的一些问题，有以下建议：

    1、数据库必须使用 SQL server。 推荐使用 SQL server 2005 64 bit。推荐使用 SQL server Cluster 以提高性 能。
    2、数据库所在的服务器，推荐使用多 CPU，16G 内存，至少 60G 剩余空间。
    3、其他 SEPM 服务器使用双 CPU，4G 内存，20G 剩余空间。
    4、操作系统推荐采用 Windows server 2003 sp2 （如果是 R2，需要使用 IE7）

    网络要求：

    对于容错和负载均衡的需求，建议 SQL server 和一个 SEPM 在本地，并且其它的 SEPM 和 SQL server 在局域 网内。

    对于企业的客户端分布在多个地理位置，并且有需求在不同的地理位置建立不同的 SEPM。要求有较好的网络 带宽，建议 4M 以上的的带宽。

    一个 SQL server 支持多少个 SEPM：

    由于 SQL server 需要对每一个SEPM的连接要分配不同的 Pool，并且每一个 SEPM 每 2 秒钟就会有 query 命 令与 SQL server 交互。因此 SEPM 数目越多，对于 SQL server 的负担就会越大。一个 SQL server 支持的 SEPM的最大极限是 10 个，但是为了增强可用性，建议一个 SQL server 连接不高于 4 个 SEPM。

    管理方式要求：

    在这种单站点，多服务器方式下，由于所有的数据都是保存在总部的 SQL server，因此可以做到第一时间内所 有数据的共享：

    1、可以做到日志集中，统一报表；

    2、只要任何 SEPM 进行内容更新，会把内容更新放入 SQL server 数据库，所有的 SEPM 都会自动获得此内 容更新。

    3、客户端安装包共享，任何一个 SEPM 添加客户端安装包以后，所有 SEPM 都可以获得此安装包。

    4、系统管理员拥有所有的管理权限，包括对客户端组和策略的编辑，以及所有SEPM服务器的策略编辑，以 及所有的连接的 Enforcer 的策略编辑。

    域管理员或者受限管理员只有对本域的客户端组和策略的编辑权限，没有对于 SEPM 服务器和 Enforcer的策略编辑权限。因此对于分部的管理员赋予何种权限需要预先考虑。

    非常好的实践建议

    数据库维护建议：由于在这种单站点，多服务器的架构下，所有的数据都会保存在总部的 SQL Server 中，并且几乎所有的对于SEPM 的操作都会有与 SQL server 的数据交互，因此对于 SQL server 的日常维护工作非常重要。

    1、备份和恢复：请参考第二章单站点，单服务器的备份和恢复建议。
    2、日常维护：

    经常将数据库备份到磁盘中，不是 SQL server 所在的电脑的磁盘；分开各个备份文件；定期删除旧的 备份文件，但是保留升级之前做的备份文件。

    对于管理数据库 sem5，删除事务日志中的非活动部分。如果使用 SQL server 的备份功能，不备份 sem5事务日志文件。

    将数据库文件大小维持在规定的级别上，设置 sem5 数据库中每个逻辑库的最大容量为不受限制（需要 有足够的硬盘空间）；定期观察当发现数据库文件大小突然间有较大增长时，及时分析原因并采取措 施避免。

    利用 SQL server 2005 或者 SQL server 2000 提供的数据库设置向导，根据以上的原则，设置合理的数 据库维护计划。并将数据库维护报告以电子邮件的方式发送给数据库管理员。

    管理服务器列表：

    既然存在多个 SEPM，用户自然会存在容错和负载均衡的需求，而 Symantec Endpoint Protection 可以很容易 做到这点，其关键是建立合理的管理服务器列表：

    1、默认的管理服务器列表是所有的SEPM服务器同一优先级，也就是说，在单站点，多服务器模式下，所有 客户端会随即连接到任何一个 SEPM，起到负载均衡的作用。

    2、如果有其他的客户端连接 SEPM 方式的需求，需要人为的编辑一个新的管理服务器列表，并且把这个管理 服务器列表分配给客户端组。

    3、对于客户端组而言，一个管理服务器列表中可以包含不同站点的 SEPM 服务器（前提条件是这些站点是复制的关系）；但是一个管理服务器列表也可以分配给一个 Enforcer 组，建议这里的管理服务器列表只包含 同一个站点的 SEPM。