精华内容
下载资源
问答
  • SQLserver 2016 Alwayson ,windows server 2016 群集 ,biztalk 2013 配置,全程图文详细介绍
  • 关于windows 2003 群集配置的详细步骤,官方文档,中文版,在IBM 服务器和磁阵设备上面操作成功,可以借鉴。
  • windows2003群集配置

    2011-03-19 14:16:03
    群集配置,群集实现的前提,服务器,EXCHANGE,SQL备份
  • windows2003 NLB群集配置

    2012-11-25 10:35:42
    windows2003 NLB群集配置 windows2003 NLB群集配置
  • 2010DD出品必属精品 2010 PAGE PAGE 1 Windows群集配置手册 Windows群集分为网络负载平衡群集和服务器群集两种下面就对两种服务器群集的配置做一个讲解 网络负载平衡群集NLB群集 NLB群集可以增强WebFIPISAVPN等服务...
  • Windows 2003服务器群集配置清单;本清单可帮助您准备安装过程
  • 文档:基于windows server 2016和sqlserver 2...链接:http://note.youdao.com/noteshare?id=4f07c1c3f7d0e32b7631d7d867385bbf&sub=941FBCFD5E2F4A8086FBDD40A214C526

    文档:基于windows server 2016和sqlserver 2...
    链接:http://note.youdao.com/noteshare?id=4f07c1c3f7d0e32b7631d7d867385bbf&sub=941FBCFD5E2F4A8086FBDD40A214C526

    展开全文
  • Windows 2008 群集配置

    2017-11-21 22:20:00
    应网友要求做了一个一步一步配置Windows Server 2008 R2群集配置说明 群集的介绍本版有很多精华贴,此次测试的是Windows Server 2008 R2群集(08配置一样), 环境: DC:192.168.169.30/24 Node1: Lan:192.168.169.31/24 ...
    应网友要求做了一个一步一步配置Windows Server 2008 R2群集配置说明
    群集的介绍本版有很多精华贴,此次测试的是Windows Server 2008 R2群集(08配置一样),


    环境:
    DC:192.168.169.30/24

    Node1:

    Lan:192.168.169.31/24 DNS:192.168.169.30
    XT:10.1.1.1/24
    Storage:192.168.100.1/24

    Node2:

    Lan:192.168.169.32/24 DNS:192.168.169.30
    XT:10.1.1.2/24
    Storage:192.168.100.2/24

    DC安装(略),Node1与Node1网络配置及加域(略)

    服务器操作系统均为Windows Server 2008 R2
    1.jpg 
    相关配置信息:
    2.jpg 

     
     

     

    挂载群集磁盘(iSCSI):

    1.运行 iSCSC发起程程序
    1.jpg 
    2.启动iSCSI服务
    2.jpg 
    3.发现门户
    3.jpg 
    4.输入门户的IP
    4.jpg 
    5.也可以目标中输入门户的IP,快速连接,看到状态是不活动,连接将其配置为活动
    5.jpg 
    6.可以看到相关信息,支持多路径(前段时间做了一个项目,就是采用多路径,负载冗余)
    6.jpg 
    7.在高级里还可以做很多设置,前面的StarWind有说到加密,这里也有。
    7.jpg 
    8.相同有方式连接完成后,可以看到硬盘管理的状态了
    8.jpg 
    9.将其连机,初始化,并分配盘符
    9.jpg 
    10.在Node2做相同操作
    10.jpg

    安装配置群集

    1.为两个节点,添加"故障转移群集"和.Net 3.5.1(为后续SQL2008R2群集做准备)
    3.jpg 
    4.jpg 
    5.jpg 
    2.使用故障转移群集管理器创建群集
    6.jpg 
    7.jpg 
    8.jpg 
    3.将两个节点都添加进来
    9.jpg 
    10.jpg 
    4.进行配置验证测试(有错误会提示)
    11.jpg 
    12.jpg 
    13.jpg 
    14.jpg 
    15.jpg 
    5.定义群集名称,及IP
    16.jpg 
    6.等等群集创建完成
    17.jpg 
    18.jpg 
    19.jpg 
    7.再次看到当前主服务器是Node1,两个节点都添加进来了
    20.jpg 
    8.检查群集存储
    21.jpg 
    9.检查群集网络
    22.jpg 
    10.关机测试
    23.jpg 
    24.jpg

    一步一步配置Server 2008 R2群集(文件服务器)

    1.分别为Node1与Node2添加文件服务角色
    1.jpg 
    2.jpg 
    3.jpg 
    2.故障转移群集管理器里面配置服务或应用程序
    4.jpg 
    3.选择文件服务器
    5.jpg 
    6.jpg 
    4.定义文件服务器群集的名称为IP。
    7.jpg 
    5.为群集配置存储
    8.jpg 
    6.添加成功,可以看到当前所有者为Node1
    9.jpg

    7.添加共享文件夹
    10.jpg 
    11.jpg 
    12.jpg 
    8.修改NTFS权限
    13.jpg 
    9.共享名称及路径
    14.jpg 
    10.启用基于访问权限枚举(这个功能很强)
    15.jpg 
    11.定义共享权限
    16.jpg 
    12.配额策略
    17.jpg 
    13.文件屏蔽策略
    18.jpg 
    14.完成配置(类似方式添加多个)
    19.jpg 
    20.jpg 
    15.查看摘要信息
    22.jpg 
    16.关机测试





    本文转自 149banzhang 51CTO博客,原文链接:http://blog.51cto.com/149banzhang/607397,如需转载请自行联系原作者
    展开全文
  • Windows 2008群集配置

    2014-12-31 09:51:20
    一步一步配置Windows Server 2008 R2群集转载自:bbs.winos.cn应网友要求做了一个一步一步配置Windows Server 2008 R2群集配置说明群集的介绍本版有很多精华贴,此次测试的是Windows Server 2008 R2群集(08配置一样),...

    一步一步配置Windows Server 2008 R2群集
    转载自:bbs.winos.cn
    应网友要求做了一个一步一步配置Windows Server 2008 R2群集配置说明
    群集的介绍本版有很多精华贴,此次测试的是Windows Server 2008 R2群集(08配置一样),


    环境:
    DC:192.168.169.30/24

    Node1:

    Lan:192.168.169.31/24 DNS:192.168.169.30
    XT:10.1.1.1/24
    Storage:192.168.100.1/24

    Node2:

    Lan:192.168.169.32/24 DNS:192.168.169.30
    XT:10.1.1.2/24
    Storage:192.168.100.2/24

    DC安装(略),Node1与Node1网络配置及加域(略)

    服务器操作系统均为Windows Server 2008 R2
     1.jpg
    相关配置信息:
     2.jpg

     挂载群集磁盘(iSCSI):

    1.运行 iSCSC发起程程序
     1.jpg
    2.启动iSCSI服务
     2.jpg
    3.发现门户
     3.jpg
    4.输入门户的IP
     4.jpg
    5.也可以目标中输入门户的IP,快速连接,看到状态是不活动,连接将其配置为活动

     5.jpg
    6.可以看到相关信息,支持多路径(前段时间做了一个项目,就是采用多路径,负载冗余)
     6.jpg
    7.在高级里还可以做很多设置,前面的StarWind有说到加密,这里也有。
     7.jpg
    8.相同有方式连接完成后,可以看到硬盘管理的状态了
     8.jpg
    9.将其连机,初始化,并分配盘符
     9.jpg
    10.在Node2做相同操作

    10.jpg

    安装配置群集

    1.为两个节点,添加"故障转移群集"和.Net 3.5.1(为后续SQL2008R2群集做准备)
     
     3.jpg

    4.jpg

    5.jpg
     
    2.使用故障转移群集管理器创建群集
     
     6.jpg

    7.jpg

    8.jpg
     
    3.将两个节点都添加进来
     
     9.jpg

    10.jpg
    4.进行配置验证测试(有错误会提示)
     
     
     11.jpg
     12.jpg
     13.jpg

    14.jpg

    15.jpg
    5.定义群集名称,及IP
     16.jpg
    6.等等群集创建完成
     
     17.jpg

    18.jpg

    19.jpg
     

    7.再次看到当前主服务器是Node1,两个节点都添加进来了
     20.jpg
    8.检查群集存储
     21.jpg
    9.检查群集网络
     22.jpg
    10.关机测试
     23.jpg

    24.jpg

    一步一步配置Server 2008 R2群集(文件服务器)
    服务器, Server, 群集, 文件
    1.分别为Node1与Node2添加文件服务角色
     
     1.jpg

    2.jpg

    3.jpg
     
    2.故障转移群集管理器里面配置服务或应用程序
     4.jpg
    3.选择文件服务器
     
     5.jpg

    6.jpg
    4.定义文件服务器群集的名称为IP。

    7.jpg
     
    5.为群集配置存储
     8.jpg
    6.添加成功,可以看到当前所有者为Node1

    9.jpg

    7.添加共享文件夹
     10.jpg

    11.jpg
     12.jpg
     
    8.修改NTFS权限
     13.jpg
    9.共享名称及路径
     14.jpg
    10.启用基于访问权限枚举(这个功能很强)
     15.jpg
    11.定义共享权限
     16.jpg
    12.配额策略
     17.jpg
    13.文件屏蔽策略
     18.jpg
    14.完成配置(类似方式添加多个)
     19.jpg

    20.jpg
     
    15.查看摘要信息
     22.jpg
    16.关机测试
    23.jpg

    21.jpg

    转载于:https://blog.51cto.com/11436668/1597999

    展开全文
  • 群集和应用程序部署 以前我们曾经介绍过主动/主动或主动/被动群集和应用程序,由于早期的产品仅支持 2 节点群集,因此这种形式的部署是它的自然结果。但是在一些情况下,这可能会导致混淆,因为这些术语可以用不同...

    群集和应用程序部署

    以前我们曾经介绍过主动/主动或主动/被动群集和应用程序,由于早期的产品仅支持 2 节点群集,因此这种形式的部署是它的自然结果。但是在一些情况下,这可能会导致混淆,因为这些术语可以用不同的方式来解释,具体取决于上下文是 1) 给定的应用程序实例如何运行 2) 不同的应用程序实例如何运行,或是 3) 群集中的节点是否正在执行有用的工作。为了完全了解特定应用程序和群集的部署,我们需要了解以下信息:

    有多少个应用程序实例正在运行?

    在群集中有多少个相同数据的实例?

    数据实例是否会移动?

    相同应用程序的不同实例是否运行在不同的群集节点中?

    不同的应用程序可以运行在不同的群集节点上吗?

    应用程序给服务器带来了何种类型的负载,以及如何在故障转移之后重新分配这些负载?

    在介绍如何部署应用程序之前,我们必须首先定义什么是应用程序。在本文中,应用程序被定义为向终端用户或客户端提供一种服务的运行中的代码和数据。可以用一对不同的示例来解释这一点:工作站上运行的一个 Microsoft Word 实例是一个应用程序实例。如果有多个 Word 实例正在运行,则每个实例会被视为一个不同的应用程序实例。然而,还有更为复杂的应用程序。例如,对于 Microsoft SQL Server 来说,一个数据库被视为一个应用程序实例。而多个独立的数据库则被视为不同的应用程序实例。但是,一个数据库可以分区成多个 SQL Server 实例并使用 SQL Server 查询引擎联系在一起。这种情况下,联系在一起从而提供一个数据库镜像的这组 SQL Server 应用程序实例就可以视为一个应用程序实例。

    基本上,将以下五种属性放在一起就可以全面了解部署的目的,并可以解释部署的原因或是表现部署的特点:

    服务器负载 多少服务器资源被它所支持的应用程序所消耗,以及故障转移会如何影响这种资源利用?

    应用程序样式 应用程序是整个在一个节点上运行,还是被分割成多个较小程序块在群集中运行?

    应用程序部署 在给定部署下应用程序块如何在群集中分配?

    故障转移策略 在故障转移后应用程序会执行何种操作?

    应用程序实施 应用程序本身如何被实施?

    服务器负载

    在部署应用程序时,很重要的一点就是要考虑应用程序会对服务器资源产生什么要求。如果使用群集,则还有一些相关问题需要考虑:在故障转移后如何重新分配负载?

    服务器负载 基础

    让我们来看一个最简单的示例,一个主动/主动式 2 节点文件服务器群集,其中节点 A 和节点 B 各服务于一个共享。如果节点 A 出现故障,它的资源就会移给节点 B,从而增加了节点 B 的负载。实际上,如果节点 A 和 B 在出现故障前都仅运行各自容量的 50%,那么在故障转移完成后,节点 B 将会完全饱和(100% 的容量),这从性能上来说是可以承受的。

    尽管不是最好的情况,但是您要记住的很重要的一点是,如果所有应用程序仍在运行,即使性能有所下降,相对于没有群集提供的高可用性保护的情况来说,这都是一个 100% 的进步。但是这带来了风险的概念,以及为了保护应用程序的性能和可用性,您可以接受多少数量的应用程序的问题。

    为了清楚地说明这个问题,我们有意选择了最坏的情况(一个主动/主动 2 节点群集,每个节点运行一个应用程序,每个应用程序消耗一半的服务器资源)。如果再加上一个节点,这种平衡就会改变:有更多的服务器用来支持负载,但如果三个节点都运行在 50% 的容量,而有两个节点出现故障,则剩下的服务器将无法处理那两个故障节点累积的应用程序负载。当然,两个故障的可能性相对来说小于一个故障,因此风险相对来说也比较小。

    尽管如此,在群集中部署应用程序时仍必须考虑负载/风险平衡。群集中节点越多,就有越多种分配工作负载的选择。如果您要求所有群集应用程序在运行时不能有任何性能下降,那么您可能需要考虑使用某种形式的主动/被动配置。但即使是在这种情况下,您也必须考虑不同配置的风险。如果您在任何情况下都无法接受哪怕是最轻微的性能下降,那么您将需要为每个主动节点配备一个专用的被动节点。

    另一方面,如果您认为多个故障同时出现的风险较小,您也可以有另外的选择。如果您具有 4 个节点或 8 个节点的群集,您可能会考虑 N+I 配置。在 1.4.3 节会详细介绍 N+I,它是主动/被动形式的一种变体,其中 N 个节点是主动节点,I 个节点是被动节点或保留节点。通常,I 的值小于 N,这样 N+I 群集拓扑就可以处理 I 个故障而不会出现任何性能下降。风险就在于,如果出现多于 I 个故障,那么性能就有可能下降,不过再说一次,同时出现多个故障的可能性是很小的。

    因此,N+I 群集是一个非常有用的配置,它在 100% 的被动服务器容量与较低水平的多个群集节点故障风险之间均衡了硬件成本。

    服务器负载 更现实的一些配置

    上述示例比较简单,它假定应用程序将整个负载都加在一台服务器身上,因此在故障转移的情况下,它的资源利用不能分布到其余的多台服务器中。实际情况通常不是这样(尤其是文件和打印服务器),因此,让我们再来看看其他 4 节点群集(就称为 ABCD 吧)的示例,这个群集具有节点 A、B、C 和 D。

    通常情况下,一台服务器将会支持多个应用程序的负载。如果正常情况下每台服务器的负载率为 25%,那么 ABCD 群集就可以在其中三个成员出现故障的情况下存活,而不会丧失应用程序的可用性(这几乎是最坏的情况)。

    以下数字序列说明了 4 节点群集在出现连续节点故障情况下的应用程序负载。阴影区域表示运行中的应用程序的容量要求。更进一步,以下示例假定应用程序在任何给定服务器上的负载都是可分的,可以重新分配到任何存活的节点上。

    Figure 1.1: Cluster under normal operating conditions (each node loaded at 25%)

    图 1.1:正常条件下运行的群集(每个节点的负载率为 25%)

    Figure 1.2: Cluster after a single node failure. Note redistribution of application load.

    图 1.2:一个节点故障后的群集。请注意应用程序负载的重新分配。

    Figure 1.3: Cluster after two node failures. Each surviving node is now approximately 50% loaded.

    图 1.3:两个节点故障后的群集。现在每个存活节点的负载率大约为 50%。

    Figure 1.4: After three node failures, single surviving node is at full capacity.

    图 1.4:在三个节点故障后,剩下的一个存活节点已运行在满容量。

    如果每个节点以 75% 的容量运行,那么在没有合理的故障转移策略的情况下,即使是一个节点故障也可能导致应用程序可用性丢失。然而,您可以根据应用程序来指定在出现服务器故障的情况下,一部分应用程序应当故障转移到节点 A、B、C 和 D。如果应用程序均匀分布到存活节点上,那么现在这个群集在失去一个节点的情况下仍可存活,因为出现故障的服务器负载已被平均分配给三个存活的节点(75% 的三分之一是 25%)。最后的结果就是三个完全负载的服务器(本来每个节点运行 75% 的容量,现在又加上 25%),但所有应用程序仍然可用。

    作为上述示例的变体,以下数字序列将介绍一个 4 节点群集,每个节点大约运行 33% 的容量。更进一步,在这个示例中,应用程序负载是不可分的,在故障转移的情况下也不能分布到多个其他服务器中(这可能是一个应用程序或是多个依赖于相同资源的应用程序)。

    Figure 2.1: Cluster under normal operating conditions (each node loaded at approximately 33%)

    图 2.1:正常条件下运行的群集(每个节点的负载率为 33%)

    Figure 2.2: Cluster after a single node failure. Note redistributed application load.

    图 2.2:一个节点故障后的群集。 请注意重新分配后的应用程序负载。

    Figure 2.3: Cluster after second node failure. Each surviving node is now running at approximately 66% capacity. Note that in the event of another node failure, this cluster will no longer be capable of supporting all four of these applications.

    图 2.3:第二个节点故障后的群集。每个存活的节点现在大约运行在 66% 的容量。请注意,如果再有一个节点出现故障,这个群集将不能支持全部四个应用程序。

    Figure 2.4: After third failure, the single surviving server can only support three of the four applications.

    图 2.4:在出现第三个故障后,唯一存活的服务器只能支持四个应用程序中的三个。

    另外一种故障转移策略是“故障转移对”(Failover Pairs),也称为“伙伴对”(Buddy Pairs)。假定四台服务器中每台服务器的负载率为 50% 或更少,那么一个故障转移伙伴就可以与每台服务器关联。这种配置使得群集在出现两个故障的情况下仍可存活。有关“故障转移对”的更详细信息将在 1.4.1 节介绍。

    利用前面的“故障转移对”示例,我们可以通过使两台服务器的负载达到 100% 容量并配备两台被动备份服务器,将它转为一个主动/被动配置。这种主动/被动配置在两个故障的情况下也可以存活,但是在正常情况下,有两台服务器没有利用。而且,这些 100% 负载的服务器的性能也比不上“故障转移对”配置,后者每台服务器仅运行在 50% 负载。在这两个示例中,请注意您具有相同数量的服务器、相同数量的应用程序以及相同数量的存活率(即可以有多少个节点出现故障而不会危及应用程序可用性)。但是,无论是从性能上还是从经济性来说,“故障转移对”都明显优于主动/被动模式。

    仍旧使用 ABCD 4 节点群集,让我们来看看如果我们将它配置为 N+I 群集(会在 1.4.3 节中详细介绍)——其中三个节点运行在 100% 容量,一个节点作为备用节点——又会怎样。这个群集只能在一个故障的情况下存活。但是与前面一样,跟每台服务器运行在 75% 容量的情况相比,您仍然拥有相同数量的服务器、应用程序以及相同的存活率,但在您让被动节点备份运行在 100% 负载的主动节点时,从性能上和经济性上仍然可以承受。

    应用程序样式

    现在是考虑应用程序设计的一些方面,以及它如何影响应用程序部署的时候了。群集中运行的应用程序可以归纳为:

    单实例

    在单实例应用程序中,在任何时间点上群集中只有一个应用程序实例在运行。这种情况的一个示例就是服务器群集中的 DHCP 服务。在任何时间点上,群集中只有一个 DHCP 服务在运行。利用服务器群集提供的故障转移支持,这个服务具有高度的可用性。单实例应用程序通常具有不能分区到其他节点的状态。在 DHCP 的情况中,已租用的 IP 地址范围相对较小,但在较大的环境中时可能具有较高的不稳定性。为了避免在群集中同步状态的复杂性,这个服务会作为单实例应用程序运行。

    Figure 3: Single instance application

    图 3:单实例应用程序

    在上述示例中,群集具有四个节点。根据定义,单实例应用程序一次只能运行在一个节点上。

    多实例

    多实例应用程序由相同代码的多个实例或代码的多个不同代码块组成,可以在群集中执行这些实例或代码块,并通过集成各自的结果来提供一个服务。这些实例的集成向终端用户或客户端计算机提供了一个服务的假象。根据应用程序和数据的类型,有两种不同类型的多实例应用程序:

    克隆的应用程序。克隆的应用程序是一个逻辑应用程序,由针对相同数据 集运行的两个或多个相同代码 实例组成。每个应用程序实例都是自包含的,从而允许客户端可以向任何一个应用程序实例发出请求,并且无论请求哪个实例,都可以保证客户端收到相同的结果。克隆的应用程序是可以缩放的,因为可以部署其他应用程序来服务于客户端请求,并且这些实例可以部署在不同节点,从而使得应用程序可以超过一个节点的容量。通过将应用程序实例部署在不同的节点上,可使应用程序具有高度的可用性。在承载应用程序实例的节点出现故障的情况下,运行在其他节点上的实例仍然可以服务于客户端请求。

    通常情况下,客户端请求会在群集的节点之间实现负载平衡,以便将客户端请求分配给多个应用程序实例。在这种环境下运行的应用程序不会具有跨越多个客户端请求的长时间在内存中运行的状态,因为每个客户端请求均被视为独立的操作,并且每个请求都可以独立实现负载平衡。此外,数据集必须在整个应用程序内保持一致。作为结果,克隆是一种通常用于具有只读数据或数据不经常更改的应用程序的技术。Web 服务器前端、可伸缩边缘服务器(例如防火墙阵列和中间层业务逻辑)均属此类。

    这些应用程序通常被称为无状态应用程序1,它们可以在可供所有克隆应用程序实例使用的永久存储中省去面向客户端会话的状态,但是,客户端必须在后续请求中提供一个令牌或密钥,这样不管哪个应用程序实例服务于哪个请求,都可以将请求与正确的客户端状态关联。

    Microsoft Windows 平台提供了“网络负载平衡”作为基本的基础结构,用于构建有能力将客户端请求分配到各个节点的扩充群集。Application Center 提供了一个管理这些环境的映像视图。

    Figure 4: Cloned Application

    图 4:克隆的应用程序

    在上述示例中,相同的应用程序 App 运行在每个节点上。每个应用程序实例都访问相同的数据集,即数据集 A-Z。本示例显示每个实例都访问它自己的数据集(使用某种形式的分段或复制技术创建并保持一致),一些应用程序可以共用相同的数据集(群集可使用诸如文件共享的技术访问数据)。

    Figure 5: : Cloned Application using a file share

    图 5:: 使用文件共享的克隆应用程序

    分区应用程序。具有长时间在内存中运行的状态或具有大型、经常更新的数据集的应用程序不容易进行克隆。这些应用程序通常称为有状态应用程序。在应用程序的多个实例中保持数据一致的成本是极为高昂的。

    然而幸运的是,很多应用程序都具有可以方便地进行分区的数据集或功能。例如,一个大型的文件服务器可以根据目录结构层次来划分文件,或者一个大型的客户数据库可以根据客户数量或客户名称范围(例如,从 A 到 L 的客户位于一个数据库中,从 M 到 Z 的客户位于另一个数据库中)来划分。在一些情况下,也可以使用功能来进行分区或组件化。一旦对应用程序进行分区,不同的分区就可以部署在群集内的一组节点中,从而使得一个完整的应用程序可以分布在多个节点上。为了向客户端提供一个应用程序映像,分区应用程序要求具有一个与应用程序无关的分解、路由和聚合机制,以便一个客户端请求可以分配给一组分区,然后这些分区的结果又可以组合成一个响应返回给客户端。例如,就拿分区客户数据库来说吧,一个返回具有应付帐款的所有帐户的 SQL 查询要求这个查询被发送给每个数据库分区。每个分区都包含客户记录的一个子集,这些客户记录必须被组合成一个数据集,然后再返回给客户端。对应用程序进行分区可以令应用程序分散开来,但是无法提供高可用性。如果某个承载应用程序分区的节点出现故障,那么这一部分的数据集或功能就不再可用。

    分区通常特定于应用程序,因为聚合机制取决于应用程序的类型以及返回的数据类型。SQL Server、Exchange 数据存储和 DFS 都是可以进行分区以便获得可伸缩性的应用程序和服务的例子。

    Figure 6: Partitioned Application  Data Partitioning

    图 6:分区应用程序 数据分区

    在上述示例中,每个节点都对完整数据集的不同数据块运行相同应用程序的多个实例。客户端应用程序的一个请求可以分布到多个实例,例如一个要求返回数据库中所有记录的查询。这种将客户端拆分到多个不同的应用程序实例,然后将单个结果进行聚合并返回给客户端的方法可以通过服务器上应用程序之间的相互协作(例如 SQLQuery 引擎)或是通过客户端(例如 Exchange 2000 数据存储)来完成。

    应用程序可以按照功能或数据集进行分区。

    Figure 7: : Partitioned Application - Functional Partitions

    图 7:: 分区应用程序 - 功能分区

    在上述示例中,群集中的每个节点都执行不同的功能;但是,整个群集则提供一个统一的服务。一个节点提供目录服务;一个节点提供记帐服务,等等。而群集则向客户端提供预定购买服务。

    为了支持大量的并行应用程序,我们构建了计算群集。换句话说,这些应用程序会将一个问题分解成多个(可能是成千上万个)子操作,然后在一组计算机中并行执行这些子操作。这类应用程序也是一种分区应用程序。计算群集通常会提供最初为环境而设计的一组库(MPI 就是这种库之一),以便能够在群集内部进行通信和同步。这些群集被称为 Beowulf 群集。Microsoft 已经建立了高性能计算 方案来支持这种类型的群集。

    应用程序部署

    根据部署何种类型的应用程序以及部署在相同群集上的应用程序数量,可以采用多种不同的方式在群集中部署应用程序。这些方式可以归纳如下:

    1.

    一,单实例应用程序

    在这种类型的部署中,一个群集节点用于执行应用程序和服务于客户请求,而其他节点则作为备用节点,等待着在出现故障的情况下承载应用程序。这种类型的部署通常适合于 2 节点故障转移的群集,而不能用于 N 节点群集,因为 N 节点群集只使用 1/N 的总体容量。这也就是一些人所说的主动/被动群集。

    2.

    一些,单实例应用程序

    多个单实例应用程序可以部署在相同群集上。每个应用程序都独立于其他应用程序。在故障转移群集中,每个应用程序都可以独立于其他应用程序进行故障转移,因此如果承载多个应用程序的节点出现故障,这些不同的应用程序可能就要故障转移到群集中的其他节点。这种类型的部署通常用于合并的情况,在这种情况下,多个应用程序分布在一组节点上,并且群集提供了一个高度可用的环境。在这种环境中,需要谨慎地进行容量规划,以便确保在出现故障的情况下,各节点仍具有足够的容量(CPU、内存 IO 带宽等)用以支持增加的负载。

    3.

    单一,多实例应用程序

    在这种环境中,尽管群集仅支持一个应用程序,但应用程序的多个程序块却运行在多个不同的节点上。在克隆应用程序的情况下,每个节点都针对相同的数据运行相同的代码。这是典型的 web 前端情形(群集中的所有节点都是一样的)。在出现故障的情况下,容量会减少。在分区应用程序中,各分区通常部署在群集的多个节点上。发生故障时,可以在一个节点上承载多个分区。需要进行谨慎的规划,以便确保在出现故障的情况下,可以达到应用程序 SLA。以 4 节点群集为例。如果某个应用程序被分为四个程序块,那么在正常运行时,每个节点将承载一个分区。如果有一个节点出现故障,那么有两个节点将继续承载一个分区,而另一个节点则要承载两个分区,从而可能给第 3 个节点造成两倍的负载。如果应用程序被划分成 12 个分区,那么在正常情况下每个节点将承载三个分区。在出现故障的时候,每个分区都可以配置为故障转移到不同的节点,因此剩下来的节点就可以每个节点承载四个分区,从而使得负载均匀分布。但代价就是,支持 12 个分区的开销要比支持 4 个分区来得高。

    4.

    一些,多实例应用程序

    当然,多个多实例应用程序可以部署在相同的群集上(实际上,单实例和多实例可以部署在相同群集上)。在多个克隆应用程序的情况下,每个节点都只运行每个应用程序的一个实例。在分区应用程序的情况下,容量规划以及定义故障转移目标变得更为复杂。

    故障转移策略

    通常,故障转移是单实例应用程序和分区应用程序的多个分区所使用的机制,用来提供高可用性(术语“数据包” (Pack) 用于描述具有高可用性的单实例应用程序或分区)。

    在 2 节点群集中,定义故障转移策略没有什么价值。如果一个节点出现故障,唯一的选择就是故障转移到另外一个节点。随着群集大小的增加,使用不同的故障转移策略随之成为可能,并且每个策略都具有不同的特点。

    故障转移对

    在大型的群集中,可以对故障转移策略进行定义,使得每个应用程序都可以在两个节点之间实现故障转移。以下这个简单的示例显示了一个 4 节点群集中的应用程序 App1 和 App2。

    Figure 8: Failover pairs

    图 8:故障转移对

    这种配置具有以下优缺点:

    sccon18

    非常适合于支持大量2 应用程序的群集,例如数据库。这种配置保证了在出现故障的情况下,两个应用程序不会分布在相同的节点上。

    sccon18

    规划容量是非常容易的。每个节点都可以根据它将要承载的应用程序来设定其容量大小(就像承载一个应用程序的 2 节点群集一样)。

    sccon18

    节点故障对系统可用性和性能的影响很容易确定。

    sccon18

    具有大型群集的灵活性。在一个节点出现故障的情况下,给定应用程序的伙伴可以进行动态更改(最后可能采用下面的备用策略)。

    sccon19

    在一个较简单的配置中(例如上述配置),只有 50% 的群集容量处于使用中。

    sccon19

    在出现多个故障的情况下可能需要管理员干预。

    使用所有版本的 Windows 的服务器群集通过将每个资源的可能的所有者列表限定给指定节点对,从而支持故障转移对。

    热备用服务器

    为了降低故障转移对的开销,可以将每个故障转移对中空闲的节点合并为一个节点,从而形成一个可以在出现故障的情况下承担工作的热备用服务器。

    Figure 9: Standby Server

    图 9:备用服务器

    备用服务器配置具有以下优缺点:

    sccon18

    非常适合于支持大量应用程序的群集,例如数据库。 这种配置保证了在出现故障的情况下,两个应用程序不会分布在相同的节点上。

    sccon18

    规划容量是非常容易的。每个节点都可以根据它将要承载的应用程序来设定其容量大小,空闲节点的大小可以设定为其他节点的最大值。

    sccon18

    节点故障对系统可用性和性能的影响很容易确定。

    sccon19

    配置的目标是为了应付单点故障。

    sccon19

    并不能真的很好地处理多个故障。在计划的维护期间空闲节点可能处于使用中,这时候可能会出现问题。

    目前,服务器群集可以通过结合使用可能的所有者列表和优先的所有者列表,从而支持备用服务器。优先节点应设为应用程序默认会在其上运行的节点,而给定资源的可能的所有者则应设为优先节点和空闲节点。

    N+I

    备用服务器在一些配置情况下可以很好地用于 4 节点群集,但是它处理多个故障的能力比较有限。N+I 配置是备用服务器概念的延伸,其中 N 个节点承载应用程序,I 个节点空闲。

    Figure 10: N+I Spare node configuration

    图 10:N+I 空闲节点配置

    N+I 配置具有以下优缺点:

    sccon18

    非常适合于支持大量应用程序的群集,例如数据库或 Exchange。这种配置确保了在发生故障时,应用程序实例将会故障转移到空闲节点,而不是正在使用的节点。

    sccon18

    规划容量是非常容易的。每个节点的容量大小是根据其将要承载的应用程序来设定的。

    sccon18

    节点故障对系统可用性和性能的影响很容易确定。

    sccon18

    配置在出现多个故障时也能很好工作。

    sccon19

    并不能真的很好地处理运行在相同群集中的多个应用程序。这种策略最适合于运行在转移群集的应用程序。

    在 Windows Server 2003 版本下,服务器群集可利用群集组公用属性 AntiAffinityClassNames,从而支持 N+I 方案。这个属性可以包含由多个字符组成的任意字符串。在发生故障转移时,如果被故障转移的某个组的 AntiAffinityClassNames 属性中含有非空字符串,那么故障转移管理器就会检查所有其他节点。如果在资源的可能的所有者列表中有哪些节点没有承载与 AntiAffinityClassNames 具有相同值的组,那么这些节点就会被认为是最佳的故障转移目标。如果群集中的所有组都承载了含有与 AntiAffinityClassNames 属性相同值的组,那么就会使用优先节点列表来选择故障转移目标。

    故障转移环

    故障转移环允许群集中的每个节点运行一个应用程序实例。在出现故障时,故障节点上的应用程序会移到序列中的下一个节点。

    Figure 11: Failover Ring

    图 11:故障转移环

    这种配置具有以下优缺点:

    sccon18

    对于支持多个小应用程序实例的群集很理想,在这样的群集中,任何节点的容量都足够大,能够同时支持多个实例。

    sccon18

    节点故障对于性能的影响很容易预测。

    sccon18

    规划单一故障的容量较为容易。

    sccon19

    这种配置对于所有类型的多个故障的效果都不是很好。如果节点 1 出现故障,节点 2 将承载两个应用程序实例,而节点 3 和节点 4 将承载一个应用程序实例。如果节点 2 接着出现故障,节点 3 就要承载三个应用程序实例,而 4 仍然只承载一个应用程序实例。

    sccon19

    不太适合于大量应用程序,因为可能存在多个实例最终由同一节点来承载的情况,即使存在负载较轻的节点。

    在 Windows Server 2003 版本下,服务器群集支持故障转移环。这是通过使用优先的所有者列表来定义给定组的故障转移顺序而实现的。应当先选择节点顺序,然后对优先的节点列表进行设置,使得每个组都从不同的节点启动。

    随机

    在大型群集——甚至是运行多个应用程序的 4 节点群集中,为每个应用程序定义具体的故障转移目标或策略会非常繁琐,同时也易于出错。在一些情况下,最好的办法就是让系统随机选择目标,这种办法可保证在统计可能性的前提下,出现故障时负载会分布到群集中。

    随机故障转移策略具有以下优缺点:

    sccon18

    对于支持多个小应用程序实例的群集很理想,在这样的群集中,任何节点的容量都足够大,能够同时支持多个实例。

    sccon18

    管理员不用决定应用程序的故障转移目标。

    sccon18

    只要有足够数量的应用程序或者说应用程序被分区地足够细致,这种办法就可以提供一个良好的机制,在出现故障时将应用程序分布到整个群集中,从而实现统计上的负载平衡。

    sccon18

    配置在出现多个故障时也能很好工作。

    sccon18

    很容易进行调整,可以很好地处理运行在相同群集中的多个应用程序或相同应用程序的多个实例。

    sccon19

    比较难以规划容量。实际上无法真正保证负载会在整个群集中平衡分布。

    sccon19

    节点故障对于性能的影响不容易预测。

    sccon19

    不太适合于大量应用程序,因为可能存在多个实例最终由同一节点来承载的情况,即使存在负载较轻的节点。

    Windows Server 2003 版的服务器群集在出现故障时会随机安排故障转移目标。在承载资源组的节点出现故障的情况下,每个具有空的优先所有者列表的资源组都会被故障转移到群集中的随机节点

    自定义控制

    在一些情况下,某个给定的应用程序实例可能会优先选择特定节点。

    将应用程序与节点关联起来的配置具有以下优缺点:

    sccon18

    在出现故障时,管理员对于将要发生什么事情具有完全控制能力。

    sccon18

    因为故障方案可以预测,因此比较容易规划容量。

    sccon19

    由于群集中有很多应用程序在运行,因此定义一个良好的故障策略会非常复杂。

    sccon19

    难以规划多个、层叠式的故障。

    服务器群集可以利用优先的节点列表功能,完全控制故障转移的顺序。优先的节点列表的全部语义可以定义如下:

    优先的节点列表通过管理员将组移到最可能的节点因为节点或组故障而进行故障转移

    在群集中包含所有节点

    组被移到群集中仍在运行的优先的节点列表中的最高节点。

    组被移到优先的节点列表中的下一个节点。

    在群集中包含节点的子集

    组被移到群集中仍在运行的优先的节点列表中的最高节点。

    如果优先的节点列表中不存在仍在运行的节点,那么就将组移到随机节点。

    组被移到优先的节点列表中的下一个节点。

    如果承载组的节点是列表中的最后一个节点或不在优先的节点列表中,那么就将组移到随机节点。

    组被移到随机节点。

    组被移到随机节点。

    负载平衡

    负载平衡是一个术语,它具有多个不同的意义。在群集环境中,通常以两种不同的方式使用负载平衡:

    在一组克隆中分布客户端请求 在 Windows 中,“网络负载平衡”(NLB) 可以将客户端 TCP/IP 请求分布到一组节点中(通常是 Web 服务器或 ISA 阵列或终端服务器计算机)。也可以通过外部网络基础结构(例如 CISCO 本地定位器)来实现这一功能。

    在故障转移群集中优化计算资源 支持故障转移的群集允许应用程序实例在群集中移动。在以前,这种方法用于确保出现故障时,应用程序可以在其他地方重新启动。但是,现在这种机制可以与性能计数器和应用程序负载方法结合使用,从而提供一种在群集节点中平衡应用程序负载的方法。这可以通过以下两种方式之一实现:

    人工平衡负载:群集中每个组都可以独立于其他群集组在群集中移动。通过尽可能将应用程序分区为较细致的组,可以利用群集管理工具来实现人工平衡负载。如果给定节点的负载高度依赖于群集中的其他节点,则可以将一个或多个组人工移动到其他群集节点中。

    动态平衡负载:目前,服务器群集不要求提供任何负载平衡机制(除了 Windows Server 2003 中的随机故障转移策略以外)。动态平衡负载是一个极为复杂的问题,移动某个应用程序在最初看来可能很有道理,但是移动的成本却难以确定。例如,移动 SQL Server 可能不仅会带来重新装载数据库的成本,它同时会丢失内存中的缓存和状态,而这从客户端的角度看来可能会造成严重的性能影响。

    1 这是一个笔误,应用程序具有状态,但是这个状态不会跨越多个客户端请求。

    2 大量应用程序也是消耗大量系统资源(例如 CPU、内存或 IO 带宽)的一个原因。

    展开全文
  • WINDOWS2016故障转移群集

    万次阅读 2019-04-09 15:51:29
    WIN2016故障转移群集 准备工作: 主机名 IP 域名 WINA 192.168.0.24 WINA.NET WINB 192.168.0.25 WINB.NET ...
  • windows server 2016 与 sql server 2016 都可用允许不许要加入AD ,管理方面省了挺多操作,也不用担心域控出现问题影响各服务器了。 本测试版本: window server 2016 datacenter + sql server 2016 ctp IP规划: ...
  • 安装后配置心跳配置现在,每个节点上的网络都已得到了正确的配置,而且群集服务也已配置完毕,这时您需要配置网络角色,以定义其在群集中的功能。此处是一份“群集管理器”中网络配置选项的列表:为群集应用启用:...
  • 该步骤是通过使用“群集配置向导”来完成的。 如下方流程图所示,“Form(形成)”(创建一个新群集)和“Join(加入)”(添加节点)所采取的路径有所不同,但是它们共有一些相同的设置页面,即“凭证登录”、“分析”以及...
  • windows配置windows群集

    2014-08-30 20:14:05
    所谓群集就是共同为客户机提供网络资源的一组系统在实际应用中 根据群集实现的功能可以分为2大类网络负载平衡群集(NLB) 最多支持32台节点 可以再工作组环境和域环境下搭建故障转移群集 最多16个节点接下来我们来看...
  • 配置WINDOWS群集

    2009-06-02 11:26:42
    配置WINDOWS群集 实验说明:本实验用于配置WINDOWS群集 实验名称:配置WINDOWS群集 实验目的:理解WINDOWS群集服务的工作原理,熟练掌握安装WINDOWS群集服务及配置WINDOWS群集 实验设备:windows server 2003 VM 二...
  • 威哥版MsSQLServer(2016) 无域群集配置 AlwaysON(高可用组),大家可用按照步骤配置。
  • Windows2016 NLB集群配置 Web Farm的软硬件需求 IIS Web服务器Web1与Web2:这两台组成Web Farm的服务器都是Windows Server 2016 Enterprise,且将安装Web服务器,同时我们要建立一个...
  • SQL Server 2016 无域群集配置 AlwaysON 可用性组

    万次阅读 热门讨论 2017-04-09 22:22:53
    windows 2016 与 sql server 2016 高可用允许不许要加入AD ,管理方面省了挺多操作,也不用担心域控出现问题影响各服务器了。
  • Windows Server 2003故障转移群集配置指南
  • 此处配置Windows2008 群集,将用于SQLserver 2008 双机故障转移群集,此处SQLserver 的群集基于Windows群集实现。Windows 2008 集群更容易实现了,只要规划好IP和磁盘分配,可一直按窗口界面进行配置。 服务器要求...
  • Windows2003服务器在IP-SAN下MSCS群集配置指南
  • 本文假设域环境和IIS都已经安装好,然后开始配置群集服务。 配置步骤: 1、在test1下单击开始-管理工具-网络负载平衡管理器,右键网络负载平衡群集点击新建群集。在IP地址处填入虚拟IP地址,我们这里以192.168....
  • WIN2016群集存储

    千次阅读 2019-04-10 13:44:42
    结论: 普通的阵列共享存储通过光纤同时连接到两台主机时...再经过群集验证存储的配置后 添加群集存储 即可用群集来决定存储的使用优先级 当A主机在使用磁盘Z时 B主机时看不到Z磁盘的 同理 B主机使用磁盘Z时A主机也...
  • 使用Windows Server 2016 搭建群集

    千次阅读 2020-03-30 10:31:38
    一、 实验环境 1、 修改每台计算机名称; 2、 更改计算机的IP地址;...使用Windows Server 2016 搭建ISCSI存储 (注:在虚拟机里面添加一块磁盘,这里选择添加一块240G的磁盘,可根据自己需求自...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 15,153
精华内容 6,061
关键字:

windows2016群集配置