群聊服务器容量规划
上一次修改主题: 2012-10-18
Microsoft Lync Server 2010 群聊提供永久保存聊天会话。与即时消息 (IM) 不同,Lync Server 2010 群聊会话将与消息、文件、URL 以及当前对话中的其他数据一起保存。
容量规划是准备部署群聊服务器的重要部分。本主题详细介绍了支持的群聊服务器拓扑和可用于确定部署的最佳配置的容量规划表,并说明了如何最好地管理在高峰期要求更大容量的群聊服务器部署。
要下载群聊服务器,请参阅“Microsoft Lync Server 2010 群聊”,网址为 https://go.microsoft.com/fwlink/?linkid=209539&clcid=0x804。
有关安装群聊服务器的详细信息,请参阅部署文档中的安装和配置群聊服务器。
支持群聊服务器的拓扑
可以在单服务器拓扑或多服务器拓扑中部署群聊服务器。
注意: |
---|
Microsoft Lync Server 2010 和 Microsoft Office Communications Server 2007 R2 的某些组合可以共存。有关详细信息,请参阅迁移文档中的迁移群聊服务器。 |
单服务器拓扑
群聊服务器的最低配置和最简单的部署是单服务器拓扑。该拓扑最多可支持 20,000 个用户。它要求使用一台运行 Microsoft Lync Server 2010 的服务器、一台群聊服务器、一台承载群聊数据库的服务器和承载 Microsoft Lync 2010 群聊的工作站。如果要求具有合规性,您还需要一台承载合规性服务的服务器以及存储合规性数据的数据库。合规性数据库可以与合规性服务并置。
注意: |
---|
Lync Server 2010 部署、群聊服务器和合规性服务必须都位于相同的 Active Directory 域服务 (AD DS) 域中。 |
下图显示了带有可选合规性服务的单服务器拓扑的所有组件。
单台群聊服务器
多服务器拓扑
为提供更大的容量和更强的可靠性,您可以根据规划群聊服务器中的说明部署多服务器拓扑。多服务器拓扑最多可以包含三台群聊服务器,每台服务器最多可以支持 20,000 个用户,因此多服务器拓扑最多可支持 60,000 个用户。多服务器拓扑由多台服务器承载群聊服务器,除此之外与单服务器拓扑都相同。多台群聊服务器应位于与 Lync Server 和合规性服务相同的 AD DS 域中。
下图显示了带多个群聊服务器的多服务器拓扑的所有组件、可选合规性服务和单独合规性服务。
多台群聊服务器
在包含三台服务器的群聊服务器部署中,60,000 个用户可以同时登录并使用 Lync 2010 群聊,负载将平均分布给每台服务器上的 20,000 个用户。如果一台服务器不可用,连接到该服务器的用户将无法访问群聊服务器。断开连接的用户将自动转接到其余的服务器,直到该不可用的服务器恢复使用。该转接过程可能需要几分钟时间,也可能长达一小时,具体取决于网络上群聊的流量大小。由于其余的每台服务器可能都正承载多达 30,000 个用户,因此我们建议您尽快还原不可用的服务器,以避免产生性能问题。
查找服务平衡了群聊服务器上的负载。群聊服务器不能位于硬件负载平衡器之后。如果某台服务器不可用之后导致负载不平衡,则在客户端登录和注销时,查找服务将重新平衡负载,但不会尝试平衡现有连接。
群聊服务器容量规划
下面的表可帮助实施群聊服务器容量规划。这些表说明了更改各种群聊服务器设置如何影响容量功能。斜体数字表示根据部署可以更改的变量。
规划群聊服务器的最大容量
使用下面的示例表决定可以支持的用户数。
群聊服务器最大容量示例
频道服务实例 |
3 |
活动的用户数 |
60,000 |
在上述示例中,计划支持群聊服务器允许的最大用户数:频道服务的三台服务器/实例和每台服务器 20,000 个用户,总计 60,000 个活动用户。
管理聊天室访问的容量规划
下面的示例表可帮助规划管理群聊服务器中的聊天室访问。
管理聊天室访问示例
每个聊天室 30 个用户 | 每个聊天室 150 个用户 | 每个聊天室 12,000 个用户 | 总计 | |
---|---|---|---|---|
聊天室 |
24,000 |
800 |
10 |
|
每个聊天室的活动用户数 |
30 |
150 |
12,000 |
|
每个用户的聊天室数量 |
12 |
2 |
2 |
|
每个聊天室成员列表中用户组的数量 |
10 |
10 |
15 |
|
用户组管理的聊天室比率 |
50% |
50% |
50% |
|
所有聊天室中基于用户组的成员实体数量 |
120,000 |
4000 |
252 |
|
所有聊天室中基于用户的成员实体数量 |
360,000 |
60,000 |
18,000 |
|
每个聊天室的管理者、演示者和范围列表中的用户和用户组数量 |
6 |
6 |
6 |
|
所有聊天室的管理者、演示者和范围列表中的用户和用户组数量 |
144,000 |
4800 |
144 |
|
访问控制项数量 |
624,000 |
68,800 |
18,396 |
711,196 |
最大访问控制项数量 |
50 |
50 |
50 |
1,000,000 |
在上述示例中,根据建议的准则部署群聊服务器时,在启用合规性的情况下,最多可在包含三台服务器的池中处理 60,000 个活动用户。
该示例显示按小(在任何给定时间具有 30 个活动用户)、中(150 个活动用户)和大(12,000 个活动用户)进行分类的聊天室。根据以下总数计算特定大小的聊天室数量:
系统中的活动用户数量
给定大小的聊天室中的活动用户数量
单个用户加入的给定大小的聊天室数量
您可以修改上表中的斜体数字,以估算将在系统中创建的特定大小的聊天室数量,以及系统可能生成的出站聊天消息的速率。在示例中,系统中有 60,000 个活动用户,如果每个用户同时加入 12 个小聊天室、2 个中聊天室和 2 个大聊天室,则系统中将创建 24,000 个小聊天室、800 个中聊天室和 10 个大聊天室。
对于每个聊天室,前面的容量规划表将指定与聊天室关联的访问控制项的数量,包括继承自父类的项和直接分配到聊天室的项。可以使用访问控制列表 (ACL) 控制对单个聊天室的访问,也可以在类别级别控制访问。在 ACL 中,单个访问控制项可以是用户组(例如,安全组、通讯组列表或联盟用户组),也可以是单个用户。您可以为聊天室管理者、演示者和成员定义访问控制项。
为进行规划,必须估算将由分配用户组而非单个用户管理的聊天室的百分比。上述示例中的数据假定包含 50% 小聊天室、50% 中聊天室和 50% 大聊天室的 ACL 将专门由用户组组成,而剩余的聊天室将由单个用户组成。
在上述示例中,对于所有大小的聊天室,管理者组、演示者组和聊天室类别范围的 ACL 将保持不变。该示例假定每个列表中每个聊天室有六个访问控制项。
重要提示: |
---|
规划管理聊天室的策略时,请牢记允许的访问控制项总数是 100 万。如果计算出的访问控制项超过 100 万,服务器性能可能会显著降低。为避免这一问题,请确保在任何时候您的访问控制项是用户组而非单个用户。 |
管理邀请的聊天室访问的容量规划
可以使用下面的容量规划表计算当群聊服务器配置为发送邀请时在群聊数据库中创建和存储的邀请数。在 Microsoft Lync Server 2010 群聊管理工具或群聊服务器客户端(群聊)的“聊天室设置”页面管理邀请。
下表中的示例数据假定在 50% 聊天室的“聊天室设置”页面上,“邀请”选项设置为“是”,并且聊天室以全部容量运行。
重要提示: |
---|
如果计算出的服务器生成的邀请数量超过 100 万,服务器性能可能会显著降低。为避免这一问题,请确保将配置为发送邀请的聊天室的数量降至最低,或者限制可以加入配置为发送邀请的聊天室的用户数。 |
邀请的聊天室访问示例
每个聊天室 30 个用户 | 每个聊天室 150 个用户 | 每个聊天室 12,000 个用户 | 总计 | |
---|---|---|---|---|
配置为发送邀请的聊天室数量 |
12,000 |
400 |
5 |
|
可以访问聊天室的用户数 |
30 |
150 |
12,000 |
|
群聊服务器生成的邀请数量 |
360,000 |
60,000 |
60,000 |
480,000 |
允许的最大邀请数量 |
1,000,000 |
群聊服务器性能用户模型
下表说明了群聊服务器的用户模型。它为容量规划邀请提供了基础,并展示了一个具有 60,000 个并发用户的典型组织。
群聊服务器性能用户模型
活动用户的数量 |
60,000 |
频道服务器的数量 |
3 |
小聊天室的大小 |
30 个用户 |
中聊天室的大小 |
150 个用户 |
大聊天室的大小 |
12,000 个用户 |
聊天室的总数 |
24,810 |
小聊天室的数量 |
24,000 |
中聊天室的数量 |
800 |
大聊天室的数量 |
10 |
每个用户的聊天室总数 |
16 |
每个用户的小聊天室数量 |
12 |
每个用户的中聊天室数量 |
2 |
每个用户的大聊天室数量 |
2 |
峰值加入速率 |
10 个/秒 |
总聊天速率 |
20 个/秒 |
小聊天室的聊天速率 |
18 个/秒 |
中聊天室的聊天速率 |
1.8 个/秒 |
大聊天室的聊天速率 |
0.2 个/秒 |
为邀请配置的聊天室的百分比 |
50% |
直接成员身份的百分比 |
50% |
组成员身份的百分比 |
50% |
AD DS 中上级隶属的平均数 |
100 - 200 |
每个用户的订阅联系人数 |
80 |
可见的聊天室平均数 |
1.5(1 的 50% 加 2 的 50%) |
每个时间间隔轮询的参与者数量 |
每个可见聊天室 15 个 |
轮询间隔时长 |
5 分钟 |
每秒钟轮询的参与者数量 |
4500 |
每个用户每小时的状态更改数量 |
4 |
每秒钟的状态更改数量 |
66.66 |