首页  ·  知识 ·  测试
性能和容量规划2
佚名  本站原创  综合  编辑:dezai  图片来源:网络
硬件故障可能会在任何时候发生。 这类故障包括环境故障,如天灾和火灾等。 在硬件实现的设计中将单点故障降到最低是降低这种风险的最安全方式

硬件故障可能会在任何时候发生。 这类故障包括环境故障,如天灾和火灾等。 在硬件实现的设计中将单点故障降到最低是降低这种风险的最安全方式。 在部署计划阶段中,MSIB 2.0 站点的实施人员应当编制一份硬件地图,给出存储器、网络和软件逻辑的所有连接点。 之后可以制定解决潜在单点故障的方案并进行成本和风险对比分析。 这方面可以有很多不同的解决方案,从自始至终对关键数据进行简单磁带备份到可以容灾的系统防护系统不一而足。

软件故障

软件故障是可能导致您的站点无法工作的第三类事件。 为了避免因软件故障造成总的功能损失,MSIB 2.0 使用了群集技术以提高可用性。 站点代码和基本部件的设计允许在发生临时故障的时候进行重试操作。 MSIB 2.0 解决方案中执行交易的部分利用了 Distributed Transaction Coordinator (DTC)、Microsoft Message Queue (MSMQ) 和交易以保证数据的完整性。

高可用性技术和建议
 这一部分介绍了一些技术和建议,帮助您部署一个高可用性的 MSIB 2.0 站点。

本部分包括:

用于高可用性的群集和负载均衡技术

旨在获得高可用性的软件建议

旨在获得高可用性的硬件建议

用于高可用性的群集和负载均衡技术

群集是指一组相互独立的计算机,它们共同合作运行公共的一套应用程序或服务,对客户端和应用程序来说像是单个系统一样。 群集计算机在物理上通过网线连接到一起,在程序上则通过群集软件连接到一起。 这些连接使得这些计算机可以使用单独的计算机无法使用的一些问题解决功能,例如负载均衡和故障切换等。

负载均衡功能将负载在所有配置的服务器之间分配,防止某一台服务器负载过度。 通过这种方式从而又让您能够逐步增大容量以满足自己的需求。 故障切换功能可以自动将资源从故障的或脱机的群集服务器上转移到正在运行的一台服务器上,从而为用户提供了恒定的支持。 这样用户就始终都可以访问 MSIB 站点的资源了。 目前,Windows Clustering 可以提供如下的群集和负载均衡技术:

  • 网络负载均衡
  • Microsoft 群集服务
  • 组件负载均衡

网络负载均衡

网络负载均衡(NLB)技术可以把多达 32 台运行 Windows 2000 Advanced Server 组合到经负载均衡的单个群集中,从而可以提供基于 TCP/IP 的应用和服务的可扩展性和高可用性。

在本文测试的 MSIB 2.0 企业部署中,MSIB 项目组利用 NLB 技术将下表所列的服务器群集了起来。


 Microsoft 群集服务

在 Windows 2000 Advanced Server 中使用 Microsoft Cluster Service (MSCS) 您可以将两台服务器组合到一起作为一个服务器群集工作,确保客户端始终可以使用到任务关键性应用和资源。 服务器群集使得用户和管理员可以把它们作为一个单一的系统而不是独立的计算机,对服务器的某些资源或节点进行访问。

在 MSIB 2.0 的企业部署中,MSIB 项目组使用了可感知群集的 Commerce Server 2002 和 SQL Server 2000 的组件。

Content Management Server 2002

Microsoft Content Management Server (MCMS)2002 不支持群集和故障切换。 特别需要指出的是,MCMS 2002 的组件在故障切换时数据库连接断开的时候不会自动重试操作。 这样一来,在被动节点变为活动节点的过程中,指向启用了 MCMS 的页面的页面请求将会产生 ODBC 错误。 当系统处于 DEBUG 模式时,或者当浏览器会话是发起自正在与数据库断开连接的 Web 服务器时,这些错误只会返回到客户端的浏览器上。

注: 这些错误只是在 MCMS 站点的页面请求失败的时候发生。

Commerce Server 2002

关于如何群集每个 Microsoft Commerce Server 2002 组件的详细介绍可以在 Planning for Reliability and High Availability 中找到,地址在 http://go.microsoft.com/fwlink/?LinkId=15044。

SQL Server

SQL Server 为 MSIB 解决方案主管运行数据库、管理数据库和数据仓库。 另外,SQL Server 2000 还为报告和分析solution 提供了联机分析处理(OLAP)引擎。

MSIB 2.0 解决方案中所有的服务器产品都要与一台群集 SQL 服务器一起工作,因此在 MSIB 2.0 的企业部署中, MSIB 项目组实施了一个两节点的群集。

如需了解群集选项和故障切换群集方面的详细信息,参见 SQL Server 2000 Resource Kit 中的第 12 章。 MSIB 项目组为本文实施的群集选项在 MSIB 2.0 随带的 MSIB Deployment Guide 中有详细介绍。

组件负载均衡

Microsoft Application Center 可以提供组件负载均衡(CLB)技术,供管理员创建一个服务器群集,对组件请求做出响应。

为了实现高可用性,MSIB 项目组未配置的组件

出于编写本文的考虑, MSIB 项目组决定以单点故障(SPOF)配置实施本部分前面所述的几个软件组件。 这只不过是一个设计决策,并不能反映出使用 CLB 部署的组件能力。

在 MSIB 2.0 解决方案中,有多个 Microsoft Operations Manager Consolidator /Agent Manager 未被 MSIB 实施。 关于如何添加这项功能的详细介绍可以在 Configuring Microsoft Operations Manager 2000 to Manage Complex Distributed Environments 一文中找到,地址在 http://go.microsoft.com/fwlink/?LinkId=15101.

此外,MSIB 项目组还没有在一个高度可用的环境中实施 Commerce Server 2002 Direct Mailer 。 关于如何安装这项功能的详细介绍可以在 Planning for Reliability and High Availability 一文中找到,地址在 http://go.microsoft.com/fwlink/?LinkId=15102.

OLAP 解决方案同样未被 MSIB 项目组以一种高度可用的方式加以安装。 如需了解关于如何实现 OLAP 解决方案高可用性的方面的信息,参见 Creating Large-Scale , Highly Available OLAP Sites 一文, http://go.microsoft.com/fwlink/?LinkId=15103.

旨在获得高可用性的软件建议

建议您在运行 IIS 5.0 的 Web 服务器上使用以下软件将资源消耗问题降到最低程度,以免这些问题影响到您的 MSIB 2.0 部署的性能和可用性。

IIS5Recycle

IIS 5.0 Process Recycling Tool,IIS5Recycle 是作为一项服务运行在运行着 Windows 2000 和 Internet Information Services (IIS) 5.0 的计算机上的。 IIS5Recycle 的目的是要重复利用过程,在资源消耗问题影响到性能和可靠性之前将其影响降到最小程度。 这一工具可以根据存储在 Windows 注册表中的配置对 IIS 过程进行重复利用。 管理员还可以利用 IIS5Recycle 收集信息以便在排除故障过程和应用中使用。

在重复利用 IIS 过程之前, IIS5Recycle 会在启用了 Windows Network Load Balancing (NLB)的系统中从群集(Web 群)中将 Web 服务器删除掉。 每次把某一服务器从群集中删除的时候,到这个 Web 服务器的连接也将会断掉。 一旦连接号降至配置的阈值之下或已经达到了给定的时间, IIS 服务就得到了循环利用。

如需下载该工具及其随带的文档,可参见 http://go.microsoft.com/fwlink/?LinkId=15077。

旨在获得高可用性的硬件建议

MSIB 项目组为本文所用的 MSIB 2.0 企业部署方案中包括了以下旨在实现高可用性的硬件建议。

存储系统

部署中所用的每台服务器都有其相应的存储需求。 为了消除单点故障,MSIB 项目组部署了一个存储区域网(SAN)。 该 SAN 单元本身带有冗余的驱动器、控制器和电源。 SAN 甚至还可以通过与另一个数据中心之间的远程光纤连接将自身复制一份。 可以通过冗余的主机总线适配卡实现 SAN 的连接,这样适配卡本身就不会成为一种单点故障了。

网络系统

网络可以具备几个层次的冗余。 对非冗余服务器中的每块网络接口卡(NIC)都进行 分组目的是为了防止 NIC 本身成为一种单点故障(SPOF)。 在本文后面的部分中对单点故障以及如何避免的问题进行了讨论。

为了避免因单个路由器故障造成的网络停用,您可以部署冗余的路由器。 还可以在设计上使路由器最少有两个到外部网络,即 Internet 的连接。 这种层次上的设置不在 MSIB 2.0 版本介绍范围之内。

服务器系统

如本文前面部分所述,为了实现高可用性,MSIB 项目组使用 NLB 和 Microsoft Cluster Service (MSCS)以群集的方式部署了物理服务器。

避免单点故障
这一部分中列出了 MSIB 2.0 部署中典型的单点故障并提供了用于解决每种 SPOF 的高可用性技术。

以下这些方面是 MSIB 2.0 部署中常见的故障点:

  • 网络
  • 服务器硬件
  • 磁盘子系统
  • 应用程序
  • 数据库和数据库连接

下表所列的技术可以用来在您的 MSIB 2.0 部署中提供高可用性,并且介绍了它们能够解决哪些故障点。 这些高可用性技术可以解决本文前面介绍的问题。 建议您在部署 MSIB 2.0 site 站点的时候在较宽基础结构的层次上(如附录A“Hardware and Network Topology Details”给出的企业部署)采用这些技术。 在您的部署中遇到的单点故障越少,这种部署就更加具有高可用性。


 典型的易发故障点和建议采用的解决方案

这一节详细介绍了 MSIB 2.0 企业部署中典型的易出故障的点(如前表所列)并为避免这些故障提出了建议。

网络

网络是将所有的服务器、内联网、Internet 和用户连接到一起的结构。 没有网络连接的话,整个系统都会瘫痪。 网络故障可能会由网络硬件故障、套接字故障或远程过程调用(RPC)连接造成的。

网络硬件故障

网络故障的主要原因有:

  • 交换机/路由器故障
  • 网络接口卡 (NIC) 故障
  • 电缆媒质故障,如网线故障等

建议采用的解决方案

建议采用的高可用性解决方案如下:

  • 利用 TCP/IP 协议。
  • 启用路由和管理协议,如 Routing Information Protocol 2 (RIP2)、Open Shortest Path First (OSPF)和 Internet Control Message Protocol (ICMP)等。 启用这些协议可能需要配置防火墙策略。
  • 部署冗余的交换机、路由器、电缆和分组的网络接口卡。

套接字故障

许多可感知网络的应用程序都是利用传输控制协议(TCP)或用户数据报协议(UDP)的套接字与运行在多个服务器之间的应用程序相互通信的。 要实现 Windows 2000 高可用性所需的通信协议为 TCP/IP 。 连接是利用 TCP 或 UDP 模式的套接字建立起来的。 TCP 套接字是一种状态连接,用于需要数据的决定性定购和保证交付的情形(例如 SQL 查询和 HTTP 查询等)。 UDP 套接字是一种无状态连接,用于定购和交付保证不是非常重要的情况下(如音频流等)。

TCP 套接字是由 MSIB 2.0 所依赖的下列软件使用的:

  • SQL Server 2000
  • Internet Information Server (IIS)
  • SMTP Mail Server
  • Agent 和 Consolidator /agent Manager 之间的 Microsoft Operations Manager (MOM)

以下的 MSIB 2.0 特性利用了 TCP 套接字:

  • Commerce Server 2002 Direct Mail (用于通过 SMTP Server 发送邮件)
  • User Profile System (用于连接到 LDAP 服务器:Active Directory?、Site Server 和第三方。还用于连接到 SQL Server)

UDP 套接字由 Commerce Server 2002 所依赖的以下软件使用:

  • Active Directory (最近的域控制器发现算法)

TCP/IP 套接字可能会因如下原因发生故障:

  • 网络故障
  • 服务器故障

建议采用的解决方案

建议采用两种 Windows 2000 高可用性解决方案:

  • Microsoft 群集服务 (MSCS)。 这种解决方案适用于 SQL Server (工作于主机和发布者模式下)或 IIS (工作于主机和发布者模式下)。
  • 用于 IIS Server 的网络负载均衡(NLB)服务。 这种解决方案适用于 IIS Server (工作于横向扩展模式)、SQL Server (工作于横向扩展模式)、外部 SMTP Mail 服务器和 LDAP 服务器。

远程过程调用(RPC)连接故障

RPC 连接是由访问如下内容的应用程序使用的:

  • 远程资源(映射的驱动器、共享文件夹等)
  • 远程 COM+ 组件(通过 DCOM )

以下的 MSIB 依赖项可能会用到 RPC 连接:

  • 远程 COM+ 应用程序
  • 为 SQL 2000 Server 使用 Distributed Transaction Coordinator (DTC)的管道组件
  • 用于目的地复制的 Application Center 源

RPC 连接可能会因为以下因素发生故障:

  • 网络故障
  • 服务器故障

建议采用的解决方案

建议采用两种 Windows 2000 高可用性解决方案:

  • Microsoft Cluster Service (MSCS)
  • Component Load Balancing (CLB) 服务

在故障切换期间,一个访问群集远程文件系统服务器的应用必需要执行如下的操作:

  • 跟踪文件或正被访问的目录路径内的搜索位置
  • 重新打开正在访问的文件或目录
  • 从故障切换发生的地点开始继续处理,从头开始重新启动处理过程,或返回稳态,令应用程序来决定解决方法

在故障切换期间,正在访问远程 COM+ 服务器(或 MSCS 或 CLB 群集)的应用程序必需要执行如下操作:

  • 跟踪处理点
  • 重新初始化远程 COM+ 对象
  • 从故障切换发生之处开始继续处理,从头开始重新启动处理过程,或返回稳态,令应用程序来决定解决方法

服务器硬件

应用程序、中间层和数据库层都运行在物理服务器上。 尽管 Windows 平台可以使用容错系统,不过这些容错系统往往比较昂贵,而且难以适应大范围的商品市场。

因硬件故障导致的服务器故障有如下几种方式:

  • 随机存取存储器(损坏、耗尽)
  • CPU (过热引起的故障)
  • 内部电源(保险丝故障、冗余电源完全失效)
  • 母板(电子故障)

在每种情况下,任何一个底层服务器组件的故障都会导致整个服务器的故障。

建议采用的解决方案

为实现服务器硬件的高可用性,建议采用如下的 Windows 2000 解决方案:

  • Microsoft 群集服务 (MSCS)。 这种解决方案适用于工作在主机或发布者模式下的服务器。 一般情况下,MSCS 需要对服务器进行读/写访问,其中,客户应用程序从服务器创建、更新和读出数据。 一般情况下这种解决方案适用于 SQL Server 、Exchange Server 和 COM+ Server 。
  • 网络负载均衡(NLB)服务。 这种解决方案适用横向扩展模式。 在这种模式下,多个数据库服务器在一个单一的虚拟 IP 地址之下进行了负载均衡。 一般情况下这些数据库服务器是作为主数据库服务器的用户工作的,这个数据库服务器则作为一个数据发布者工作。 在一个数据库服务器出现故障的时候, NLB 将该服务器从群集中删除并将连接指向其他正常的服务器。
  • 组件负载均衡(CLB) 服务。 这种解决方案适用于 COM+ 应用程序。 远程 COM+ 组件是安装在 CLB 服务上的。 在某一台 COM+ 服务器出现故障的时候, CLB 能够检测到该故障并将请求指向功能正常的服务器上。
  • 多台服务器。 专门为 Active Directory Domain Controller 部署多台服务器。 Active Directory 是通过复制其目录存储和在多个域控制器之间分布请求实现高可用性的。
  • 硬件冗余。 使用内置硬件冗余的计算机系统,例如冗余电源等。

磁盘

磁盘子系统是由 MSIB 2.0 下列的依赖项使用的:

  • IIS Server (包括 IIS 元数据库、Web 站点内容:ASP ,HTML ,GIF ,PCF 等等。)
  • Commerce Server 2002 Direct Mailer 用的 Mail Drop 文件夹
  • 搜索内容的内容索引

文件/磁盘子系统可能会因为如下原因发生故障:

  • 硬盘驱动器中物理磁头失效
  • 电子故障
  • 硬盘驱动器中物理扇区损坏

建议采用的解决方案

在磁盘子系统这一个级别上,建议您使用以下技术中的一个或多个以确保实现高可用性:

  • RAID 5
  • RAID 1
  • RAID 1 + 0
  • 多个 SAN 光纤信道通道(交换机、总线和控制器等)

不过,一旦基础设施级别上的容错功能未能保护子系统,这种故障就会以文件丢失、目录丢失或驱动器句柄的形式反映在操作系统(OS)级别上,引起对文件/磁盘子系统资源的后续访问失败。 如需了解关于 RAID 的更多信息,请在 Windows 2000 Help 中搜索 RAID 。

应用程序

Commerce Server 和 ISA 等应用程序都是由 MSIB 2.0 用以执行该解决方案所需的综合软件功能的。 由于应用程序是运行在平台操作系统(OS)顶部的,因此存在很多引起故障的原因,包括:

  • 磁盘子系统失效
  • 网络故障
  • 二进制失效
  • 服务器故障

建议采用的解决方案

建议采用两种 Windows 2000 高可用性解决方案:

  • Microsoft 群集服务。 这种解决方案适用于那些本身是服务而且支持这一功能的应用程序组件。
  • 网络负载均衡(NLB)。 这种解决方案适用于工作于横向扩展模式下的 Search ,ISA ,MCMS 和 Commerce Server 2002 。 在这种模式下,多个应用服务器在一个单一的虚拟 IP 地址之下进行了负载均衡。 前端应用服务器上运行的组件为那些需要使用持续状态的操作在后端数据库服务器上维护着状态。 在一个应用服务器出现故障的时候, NLB 将该服务器从群集中删除并将连接指向其他正常的服务器。
  • 解决方案部署中应当包括对构成应用程序的其他二进制代码的备份。

数据库

SQL Server 2000 由 MSIB 2.0 及其依赖项用于连接到数据库上。 由于数据库服务器是运行在平台操作系统和服务顶部的,因此存在很多引起故障的原因,包括:

  • 文件/磁盘系统失效
  • 网络故障
  • 数据库应用程序故障
  • 服务器故障

建议采用的解决方案

建议采用两种 Windows 2000 高可用性解决方案:

  • Microsoft 群集服务 (MSCS)。 这种解决方案适用于 MSIB 数据库服务器。 这种解决方案可以提供可靠性,不过却不能提供额外的可扩展性,这是因为其工作负荷并不是分布式的。
  • 网络负载均衡(NLB)。 这种解决方案适用横向扩展模式。 在这种模式下,多个数据库服务器在一个单一的虚拟 IP 地址之下进行了负载均衡。 一般情况下这些数据库服务器是作为主数据库服务器的用户工作的,这个数据库服务器则作为一个数据发布者工作。 在一个数据库服务器出现故障的时候, NLB 将该服务器从群集中删除并将连接指向其他正常的服务器。
  • 解决方案部署中应当包括对数据库和构成数据库的存储过程的备份。

类似地,如果现有的计算机出现了硬件资源的瓶颈,那么您应当为 Web 群添加后端 SQL 服务器。 在添加了更多 SQL 服务器之后,构成 MSIB 2.0 解决方案的数据库应当在 SQL 服务器中分离开来。

 MSIB 2.0 企业部署的恢复模型

 下图给出了 MSIB 2.0 企业部署中典型的单点故障,下表介绍了 MSIB 2.0 企业部署是如何从单点故障中恢复过来的。 为了避免发生这些单点故障,建议您在投入实际运行之前在您的 MSIB 2.0 企业部署中采用本文前面介绍的高可用性技术。

本文作者:佚名 来源:本站原创
CIO之家 www.ciozj.com 微信公众号:imciow
   
免责声明:本站转载此文章旨在分享信息,不代表对其内容的完全认同。文章来源已尽可能注明,若涉及版权问题,请及时与我们联系,我们将积极配合处理。同时,我们无法对文章内容的真实性、准确性及完整性进行完全保证,对于因文章内容而产生的任何后果,本账号不承担法律责任。转载仅出于传播目的,读者应自行对内容进行核实与判断。请谨慎参考文章信息,一切责任由读者自行承担。
延伸阅读