可以说时区支持是最重要的。我在过去一年左右的时间内一直在考虑如何处理时区问题，而实际解决方案却在顷刻间应运而生。但我讲得过快了点，我们还是先来看看时区问题实际上是什么问题。
原文发布于 2012 年 6 月 20 日（星期三）
2012 年 6 月 22 日更新 - 本文和相应下载内容已更新。
最新发布的 Exchange 客户端网络带宽计算器（该链接可能指向英文页面）包含若干更新，但可以说时区支持是最重要的。我在过去一年左右的时间内一直在考虑如何处理时区问题，而实际解决方案却在顷刻间应运而生。但我讲得过快了点，我们还是先来看看时区问题实际上是什么问题。
什么是时区问题？
我假定大家都知道时区是什么，以及我们为什么会遇到时区，但对于想了解更多内容的人，我建议阅读下面的 Wikipedia 文章；
http://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 服务器查看性能数据来创建此内容，同时会询问客户其用户的工作情况及其高峰时间。
在填写完输入表后，我们将移到“客户端组合”表，我们可在此两个新区域中配置时区数据。
第一个区域是“模型时区”(Model Timezone)，此区域代表我们计划的资源的时区，即网络链接或负载平衡器。在之前的示例中，您可以看到我已将模型时区设置为 GMT-5（纽约时区），该时区是负载平衡器所在的时区。
其次，我们有一个名为“时区”(TimeZone) 的新列，此列代表相对于 GMT 的每个单独地点的时区（注意，我在英国，因此以此地为 GMT 时区，但如果有太多人抱怨，以后我可能会将此地移到 UTC）。
客户端组合表下的图表中显示了预测结果，如上所示。此表中的值以 MB/秒为单位，且表示预测的每天每小时的网络使用率。
新增功能
其他出色的功能之一是，计算器将提供一个表格，后者可复制到邮箱角色计算器，以帮助 DAG 网络复制预测。
如果您注意网络计算器预测图（客户端组合表）右侧，您将看到一个表，其中包含每天每小时的变化百分比… 如果将此表复制到剪贴板…
然后在邮箱服务器角色计算器中滚动到输入表底部，您将找到一个“日志复制配置”(Log Replication Configuration) 表。请将数字从网络计算器粘贴到此表中。
总之，邮箱服务器角色计算器现在可以根据您的组织数据和时区配置预测 DAG 复制的带宽需求！
结束语
希望此新功能可帮助很多人更准确地预测网络带宽需求；此功能不一定适用于所有部署，但对于努力解决此问题的外部大型企业架构师，希望时区功能可以有所帮助。
请继续提供有价值的反馈，无论是积极还是消极的，电子邮件地址为 netcalc@microsoft.com。我们乐意读到您的评论！
Neil Johnson
MCS UK 高级顾问
这是一篇本地化的博客文章。请访问 Exchange Client Bandwidth Prediction – the time zone problem… 以查看原文
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
