转贴：Microsoft Application Center 2000 组件负载平衡技术概述(2)

2024-07-21 02:17:21

字体：大中小

来源：转载

供稿：网友

组件负载平衡应用
下面的说明可使 clb 得到迅速应用。这些说明假设将用 stager 来将内容部署到 web 层和 com+ 群集上。并假定您掌握了有关 visual basic、asp 和 html 的实际使用知识。

在 stager 上使用 visual basic，创建一个导出以下函数的 com+ 组件。
public function getname() as string
set ws = createobject("wscript.network")
getname = ws.computername
set ws=nothing

end function
使用 com+ services explorer 将组件打包进 com+ 应用程序中。
在 stager 上，创建包括 com+ 组件的 application center 应用程序。
将 com+ 组件部署到 com+ 群集。切记在部署向导中选中 deploy com+ applications，否则将不部署组件。
用下面的脚本创建一个名为 default.asp 的 asp 文件。
<script language=vbscript runat="server">

for n=1 to 50
set x=createobject ("yourcomponent.yourclass")
response.write "component created on: "
response.write x.getname
response.write "<br>"
set x=nothing
next

</script>
用在第 1 步中创建的组件的 progid 替换 progid "yourcomponent.yourclass"。
在 stager 上创建一个 application center 应用程序（包括第 5 步中的 default.asp 文件和第 1 步中的 com+ 组件）。
将应用程序部署到 web 层群集。
确保 web 层路由列表已经建立，com+ 组件已标记为支持负载平衡。
从客户机上运行 default.asp。如果一开始不工作，可能是 iis service 在组件部署期间被重启动的结果。请稍候片刻再重试。

如果重试成功，您将看到一个用来创建组件实例的 com+ 群集成员的列表。
何时使用 clb
clb 是用于建立分布式解决方案的一项绝妙的技术。但有些时候，clb 或许不是最好的解决方案。关键问题是性能、可伸缩性和安全性。理解这些问题将有助于建立更好的群集拓扑。
性能
无论一个 web 站点多么吸引人，功能多么强大，如果用户从站点得不到令人满意的性能，这个站点就不会获得成功。有两个问题很重要：

吞吐量 — web 站点所完成的工作。
响应时间 — 给用户提供反馈所需的时间。

两者是相互关联的，clb 也有些问题与它们有关。
吞吐量
当通过网络进行任何类型的调用时，吞吐量性能将有所下降。使用 clb 会明显导致这一现象，所以在决定群集体系结构时需要考虑这个问题。为了进一步阐述该问题，下面的数据显示了每秒钟对一个单线程 visual basic 6 com 组件（该组件以字符串属性返回“hello, world”）的调用次数。客户机早已超前绑定，且不在对检索属性的调用之间发布引用。方案
每秒钟的调用次数
相对速度
com+ server application，运行在 10baset 网络上

625

1.0x

com+ server application，out proc，同一计算机

1923

3.08x

com+ library application，in proc，同一计算机

3333

5.33x

显然，通过网络进行的调用所产生的吞吐量，要低于调用同一台计算机上的软件所产生的吞吐量。在所有的软件通讯中，无论是否通过 microsoft 的软件，都会发生同样的情况。因此，在吞吐量非常关键的地方，clb 没有提出好的解决方案。这种情况下，最好将 com+ 组件本地安装在 web 层群集成员上，这样可以避免网络间的调用。虽然丧失了 clb 支持，但仍可以通过 nlb 提供负载平衡。
file:///f:/my%20work/技术文档/服务器群设置/microsoft%20application%20center%202000%20组件负载平衡技术概述.files/clbovr05.gif
图 5 web 层上的 com+ 组件
响应时间
确保用户在访问 web 站点时得到快速响应显然很重要，而 web 站点的体系结构对响应时间的影响是很大的。运行在 web 层群集上的 com+ 组件可能执行一些明显降低 web 站点的响应性能的操作。如果对于非 com+ 组件的工作来说，响应时间的重要性大于组件吞吐量的重要性，那么有一个解决方案，就是将 com+ 组件转移到一个 com+ 群集层。这将减轻 web 层群集的工作量，以便改进未使用 com+ 组件的客户机的服务时间。例如，访问静态 web 页的客户机。显然，当要求 com+ 组件工作时，看不到响应时间的改进。实际上，性能很可能由于将发生穿越网络的调用而下降。另一个方法是将路由列表移到独立的 com+ 路由群集上。这样做连 web 层的工作量也减轻了，因为其上将不发生任何 clb 特有的工作。此外，这虽然有利于 web 层上的非 com+ 组件工作，但因为有网间调用，所以会导致 com+ 组件的性能进一步下降。
显然，高性能和 clb 未必兼得，web 站点设计人员必须知道这些局限性。
易管理性
使用独立的 com+ 群集有助于提高易管理性。这使得 web 站点的 com+ 组件和 ip 请求能够被轻松、独立地管理。例如，许多组织把它们的 com+ 组件放在位于不同物理位置的服务器上。使用独立的 com+ 群集能够实现对群集的独立管理。此外，可以让多个 web 层群集共享一个 com+ 群集，反之亦然。
安全性
clb 的一个常见用途是增强 web 站点的安全性。当用作访问数据的手段时，com+ 组件可以使用自己的基于角色的（或以编程方式实现的）安全机制来保护数据。如果组件位于 web 层群集，这种安全机制很可能会受到危害。web 层群集收到的调用可能来自一台不可信任的客户机，该客户机试图非法利用安装在群集成员上的 com+ 组件。clb 可以避免这种问题，方法是将 com+ 组件从 web 层群集转移到 com+ 群集。com+ 群集通常由防火墙（图 6 中的防火墙 b）保护，它只允许来自 web 层群集内部的调用创建组件，而不允许来自客户机的调用创建组件。图 6 还显示了一个非军事化区 (dmz)，通过两道防火墙来保护 web 层。
file:///f:/my%20work/技术文档/服务器群设置/microsoft%20application%20center%202000%20组件负载平衡技术概述.files/clbovr06.gif
图 6 防火墙后面的 com+ 群集
小结
clb 是一项用来建立分布式解决方案的绝妙技术，然而在使用它时必须谨慎。在使用它时吞吐量性能会受到负面影响，但是其它一些优点，如安全性、可伸缩性、易于设置、负载平衡等，决定了它仍然不失为一种重要的工具。合理地使用 clb 将有助于制定出很好的基于 .net 的解决方案。
资源
http://www.microsoft.com/applicationcenter — 有关 application center 的最新信息。
microsoft application center 2000 resource kit — 含有对 application center 的深入探讨。给出了有关 clb 的进一步信息，尤其是部署方案。不久即可供使用。
http://www.microsoft.com/com — 有关 com 和 com+ 的信息。
http://www.microsoft.com/net — 有关 .net 的权威信息。
http://www.microsoft.com/windows2000/library/howitworks/cluster/nlb.asp — 有关网络负载平衡的详细信息。
本白皮书是一份初稿，在最终的商业版本之前可能会作重大改动。本文档仅供参考，microsoft 在本文档中未作任何明示的或默示的担保。本文档中的信息可能在未经通知的情况下加以改动。使用本文档带来的风险和后果由用户自己负责。本文作为例子提到的公司、组织、产品、人和事件均是虚构的。决不意指任何实际的公司、机构、产品、人员和事件。遵守所有适用的版权法律是用户的责任。在不对版权法所规定的权利加以限制的情况下，未经 microsoft corporation 的书面明确许可，不得将本文的任何部分复制、存储或引入到检索系统，或以任何形式或手段（电子、机械、影印、录制等）、或出于任何目的，转发本文的任何部分。

收集最实用的网页特效代码！

上一篇：About Public Structure----内详

下一篇：转贴：Microsoft Application Center 2000 组件负载平衡技术概述(1)