Exchange 客户端带宽预测 – 时区问题…

Artikel
07/23/2012

原文发布于 2012 年 6 月 20 日（星期三）

2012 年 6 月 22 日更新 - 本文和相应下载内容已更新。

最新发布的 Exchange 客户端网络带宽计算器（该链接可能指向英文页面）包含若干更新，但可以说时区支持是最重要的。我在过去一年左右的时间内一直在考虑如何处理时区问题，而实际解决方案却在顷刻间应运而生。但我讲得过快了点，我们还是先来看看时区问题实际上是什么问题。

什么是时区问题？

我假定大家都知道时区是什么，以及我们为什么会遇到时区，但对于想了解更多内容的人，我建议阅读下面的 Wikipedia 文章；

https://en.wikipedia.org/wiki/Time_zone（该链接可能指向英文页面）

从网络带宽预测角度而言，实际时区问题是，我们可能要尝试对世界其他地区中共享同一网络连接或同一端服务的用户的工作负荷建模。此问题将使我们遇到自大多数用户高峰使用时间后与其本地时区相关的问题；

例如，如果我们着眼于平均 1000 个用户的组织的正常工作日，我们将看到两个典型高峰，一个高峰是早上 10 点左右，此高峰将持续 2 小时，随后的高峰是下午 2 点左右，此高峰将持续 4 小时。当我们绘制出此情景时，其图形如下所示；

现在，我们想象，我们将对世界 5 个不同位置的需求建模，每个位置支持 1000 个用户访问纽约的共享资源。我们暂时假定此共享资源是面向 Exchange 2010 本地部署的负载平衡器（我想我需要为更改选择一个本地部署示例）

伦敦 (GMT) = 1000 个用户
华沙 (GMT+1) = 1000 个用户
雅加达 (GMT+7) = 1000 个用户
雷蒙德 (GMT-8) = 1000 个用户
纽约 (GMT-5) = 1000 个用户

如果我们使用旧方法预测每组用户的峰值并将其加在一起来建模，我们会获得以下结果；

此图显示的内容是，每个地点的 1000 个用户每天在高峰时间大约需要 1.56 MB/秒的带宽，因此当我们将其加在一起来表示共享纽约负载平衡器的所有用户时，我们将获得高峰需求值 7.81 MB/秒。这就是我们过去如何处理分散用户的带宽计划，预测其高峰需求值，然后将这些值粘贴到表格中，并将其加在一起。

此处的问题是，当雷蒙德的用户刚醒来，雅加达的用户准备上床时，欧洲用户准备回家了！

如果我们考虑到这些地点的时区，则图表将发生巨大变化；

此图显示这些工作负荷实际如何形成与我们过去计划大相径庭的使用情况图。此处的确引人注目的是，我们的高峰工作负荷现在低得多，只有 3.78 MB/秒（初始预测值为 7.81 MB/秒）。使用情况图也与初始预测大相径庭。

我们如何处理此问题？

正如您根据上图猜想的一样，我们已扩展网络计算器，从而使您可以包含时区详细信息！

为此，我们实际需要放弃仅预测高峰工作负荷的想法，现在要根据使用模式预测每天每小时的带宽使用率，但前提是要了解何时是早上高峰时间以及下午高峰时间等。这样，计算器不仅要知道何时是高峰使用时间，而且要知道每天非高峰时间的使用情况。当我们知道此曲线的外观后，则可以将数据加在一起，以便表示不同时区。

是否任何人都需要完成此唯一整合？

此问题的答案是肯定的，许多组织都要整合尽可能多的工作负荷。这就需要设计团队根据分散的用户计划服务工作负荷；通常使用不同配置文件，并使用不同时区。特别常见的是将工作负荷移到云服务中，因为 Office 365 只能提供单个地区租户位置，因此使用 Office 365 的全球组织必须计划其大部分用户在完全不同的地区和时区访问服务（通常通过共享基础结构）。

与我合作的许多客户也要将许多较小的数据中心整合为较少的大数据中心，这些整合现场必须能够处理前述分散用户的工作负荷，而这些用户通常处于不同时区，因此当我们尝试容纳其工作负荷时，我们需要使用特定方法来解决如何将这些工作负荷与其他分散工作负荷合并在一起。

显而易见，如果所有用户都位于同一时区，则不需要关心此类问题，只需正常使用计算器即可。

使用新时区功能

如果您的情况需要时区支持，您究竟如何使用新功能？

首先，也是最重要的是，我们需要在输入表中配置“时区配置”(TimeZone configuration) 表。在此输入的参数可控制合并工作负荷使用的使用曲线的形状。此处的值需要反映组织内的平均使用模式，我通常会从运行 Exchange 服务器查看性能数据来创建此内容，同时会询问客户其用户的工作情况及其高峰时间。