转贴:Microsoft Application Center 2000 组件负载平衡技术概述

80酷酷网    80kuku.com

  application 
组件负载平衡应用
下面的说明可使 CLB 得到迅速应用。这些说明假设将用 stager 来将内容部署到 Web 层和 COM+ 群集上。并假定您掌握了有关 Visual Basic、ASP 和 HTML 的实际使用知识。

  1. 在 stager 上使用 Visual Basic,创建一个导出以下函数的 COM+ 组件。
    Public Function GetName() As String
    Set WS = CreateObject("wscript.network")
    GetName = WS.Computername
    Set WS=nothing


    End Function
  2. 使用 COM+ Services Explorer 将组件打包进 COM+ 应用程序中。
  3. 在 stager 上,创建包括 COM+ 组件的 Application Center 应用程序。
  4. 将 COM+ 组件部署到 COM+ 群集。切记在部署向导中选中 Deploy COM+ applications,否则将不部署组件。
  5. 用下面的脚本创建一个名为 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 "
    "
    set x=nothing
    next

    </script>
  6. 用在第 1 步中创建的组件的 ProgID 替换 ProgID "YourComponent.YourClass"
  7. 在 stager 上创建一个 Application Center 应用程序(包括第 5 步中的 Default.asp 文件和第 1 步中的 COM+ 组件)。
  8. 将应用程序部署到 Web 层群集。
  9. 确保 Web 层路由列表已经建立,COM+ 组件已标记为支持负载平衡。
  10. 从客户机上运行 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 的书面明确许可,不得将本文的任何部分复制、存储或引入到检索系统,或以任何形式或手段(电子、机械、影印、录制等)、或出于任何目的,转发本文的任何部分。 

分享到
  • 微信分享
  • 新浪微博
  • QQ好友
  • QQ空间
点击: