Windows Server 2008的七个应用场景，其中很重要的一个就是高可用性，也许有人会说，在Windows Server 2003中也有关于高可用的特性，比如群集、网络负载均衡、灾难恢复等。既然作为Server 2008一个重要的应用场景，高可用性的改进和变化自然也是很大的，到底会有怎样的变化呢
首先我们要明确，什么是可用性，可用性包括可靠性、故障和恢复。一个系统的可靠性，故障发生时间间隔和故障恢复速度，共同决定了这个系统的可用性。那么我们通常都如何来衡量一个系统的可用性呢最常用的方法就是使用数字“9”，通常我们会以几个“9”来说明系统的可用性，让我们看看下面这张表吧：
通过这张表，我们不难发现，要做到3个“9”级别的系统可用性，每年只允许我们有877个小时的停机时间。当然，可用性是只能用“9”，而不可能用“8”或者“7”来衡量的。一个系统的高可用性，需要很多方面共同实现，如硬件、网络、操作系统、应用层面都需要有相应的高可用解决方案，在操作系统层面上，微软的Windows Server已经为我们提供了很好的高可用解决方案：Cluster(群集，一种并行或分布式的系统，由全面互连的计算机集合组成，可以作为一个统一的计算机资源使用)。
相信很多人都已经了解了Windows Server的群集，我就不再详细解释什么是群集，如何实现群集了，主要想谈一谈Windows Server 2008中群集的变化。首先，最明显、最直观的就是名称的变化，群集在Windows NT4时代就已经有了，那是叫做Microsoft Cluster Services(MSCS)，到了Windows 2000时代，改叫做Server Clustering，而在Windows Server 2008中，群集有了个更为形象的名称，Failover Clustering(WSFC)，我觉得名字起的很形象，Fail-服务器故障了，Over-转移到其它机器上，正好叫做Failover。当然，名称的改进是不会对企业用户有很大实际意义的，那就让我来看看它在技术上的改进吧。
在这里我还是想讨论一下高可用性方案对企业用户的价值，我们经常说，或者经常会听到各个厂商说，高可用方案能够降低TCO，可很多企业都对这个有所质疑，本来一台服务器能完成的工作，现在需要购买额外的服务器，明明硬件成本、维护成本甚至人员成本都增加了，怎么还能降低TCO呢那就让我们回想去年发生的一件事情吧，那是2007年的10月底的一天，时值2008年奥运会门票第二阶段发售之日，记得当时的售票策略是先到先得，于是乎，在发售门票开始时，便有成千上万乃至上百万的用户蜂拥到奥运门票销售网站，霎时间网站就因为并发连接过大而无法响应了。在那之后的一天时间里，服务器也没能恢复正常工作，以至于后来不得不改变了门票的分配方式。我想这件事情大家可能都了解，也许是售票系统的软件设计问题，也许是硬件性能的问题，总之这套售票系统既不可靠，还发生了故障，而且没能恢复，可用性的三大方面一项也没满足，自然谈不上高可用啦。那么我们想一想，没有高可用带来的损失吧，要知道奥运可是当前我们伟大祖国的大事，而且也是全世界瞩目的大事，在如此之大的事情上出现了这么重大的失误，我想这件事造成的损失很难用几千、几万的钱来衡量了，如果当初高可用方案做得很好，当然也就没有损失了，甚至可能带来很高的信誉。由此可见，高可用性方案决不是只会给企业增加成本的，而是真正的降低了企业面临的风险，降低了TCO。
既然看到了高可用性的价值所在，让我们来看看Windows Server 2008故障转移群集还带给了我们哪些惊喜吧。
我们很多企业已经意识到了实现高可用性方案的重要性，也有很多企业希望尽快实现这样的高可用方案，但在实施的时候经常会遇到各种各样的问题，其中很大一部分是因为之前在创建Windows Server Cluster的时候，过程非常复杂，还受到了很多条件的限制，造成了群集实施的困难。在Windows Server 2008中，对于群集的创建和管理都有了很多改进，能够让企业的IT管理员更轻松的实现高可用的方案。
群集安装前的准备：我们知道群集的安装不仅需要有软件的准备，还需要对硬件做好配置，如配置好共享存储设备，配置好群集心跳线等等，由于配置众多，往往我们无法去判断当前的条件是否能够满足群集的安装要求，即使能够满足，在部署了群集之后，又是否能够安全可靠，实现自动切换呢。在Windows Server 08的群集创建前，增加了一个“验证”的步骤，这个步骤会对操作系统的一致性(每个节点)、基础架构(如CPU、内存)、配置(是否是域成员)、硬件设备(HBA、NIC)、节点连通性、兼容性、共享存储、软件(如IP地址的配置)做出必要的检测和验证，并且还会模拟群集创建完成后的故障转移，以确保群集的安装万无一失。相信大家对群集的安装条件都很了解，在这特别提示一点，就是群集节点的内、外网卡一定要设置在不同的网段，否则在群集管理器中只能够看到节点的一块网卡哦。另外还有，就是群集是否可以安装在DC上的问题，首先说这是可以的，但是我们包括微软绝对不推荐的，最近就因为客户将DC作为群集节点遇到了各种怪异的问题，总之，还是按照微软推荐的Best Practice进行配置。
企业在配置群集时，另外一个主要的考虑就是共享存储，要知道共享存储设备是很贵的，不是所有企业都愿意为了实现高可用去购买昂贵的存储设备的。(当然，中石油、中移动一类的企业刨除在外，记得在给移动做项目的时候，被人家告知，刚刚买了多少多少存储，才花了600多万，真便宜。汗!无语了)昂贵的存储设备，限制了群集在企业中的部署，并且还有个致命的问题：单点故障，也就是说，一旦群集的共享存储有幸休个假的话，整个群集也要跟着去休假了。在Windows Server 2003时代，就通过更新引入了一种新的群集仲裁模式，可以在没有共享存储的情况下，使用共享文件夹作为群集的仲裁资源(需要安装kb921181更新)。在Windows Server 2008中将会包含四种群集仲裁模式，这既可以帮助没有共享存储的企业实现高可用，也可以消除单点故障的问题。这四种模式分别是：多数仲裁模式、多数节点模式、磁盘仲裁、文件共享仲裁。
群集中的每个节点和磁盘存储均有投票权，当有节点或者存储发生故障时，由群集中的所有节点和存储进行投票，决定群集资源如何进行切换，这种模式中，即使共享存储设备发生故障(当然需要共享存储中只有仲裁资源，而没有其它数据资源，如Exchange mailbox store)，群集仍然能够正常运行，这就有效避免了群集的单点故障问题。
与多数仲裁模式的区别是群集节点连接的存储设备是没有投票权的，这种模式通常采用的存储设备是iSCSI的存储设备，这样能够实现异地的高可用解决方案(这在Windows Server 2003中是很难实现的，不仅因为受到了仲裁模式的限制，还因为群集心跳线之前采用的是广播的方式，是无法跨越路由的，自然也就无法实现异地高可用啦)。
最后提示一点，在Windows Server 2003群集的文件共享仲裁模式中，仅能够支持两节点的群集，而在Windows Server 2008中，将可以支持更多的节点。
随着Windows Server 2008的正是发布，现在大家对它的兴趣也越来越浓了，越来越多的企业希望能够了解它有哪些新的特性，其实企业是否会升级到08，主要考虑的一个方面是它是否具有足够的吸引力。
刚刚和同事讨论完Windows Server 2008的群集，发现其中还是有很多有意义的改变。之前我们讨论过了08群集的仲裁模式，通过对仲裁模式的改进，彻底消除了之前群集的一大诟病：单点故障。很多企业在部署群集的时候，都会考虑到单点故障的问题，如果投入了巨大的成本，实现了服务、应用的高可用，可却因为存储设备的单点故障而造成整个系统的崩溃，企业肯定是不希望看到的。Windows Server 2008故障转移群集彻底解决了这个问题，让我们可以轻松地面对发生的各种故障。
当然，在之前做过的很多项目中，客户都提到过这样一个问题，能否做异地的高可用。其实这是很现实的问题，特别是对于一些大型企业，通常不会在一个地点办公，可能在全国、全世界都有分支机构，那么他们就需要实现异地的高可用，一旦某一地点发生了诸如停电、着火、地震、山崩、海啸、911撞楼(当然概率比较小，不过也不是没可能啦J)这样的灾害，可能就会对整个企业的业务和应用系统造成破坏，如果这时候企业无法进行系统的异地切换，就可能会长时间停机，从而损失巨大。在之前的Windows群集中，实现异地的高可用很困难，因为群集的节点之间是需要进行通讯的，而这种通讯采用的是UDP多播方式，是无法跨越路由器进行传输的，这就限制了企业实现异地高可用。在Server 08中，群集的节点通讯不再采用UDP多播，而是使用了TCP单播的方式，可以跨越路由，并且Server 08群集能够很好地支持IPv6，这就使实现异地群集成为可能，并且只要节点之间可以通讯，就很容易实现。
另外在Windows Server 2008群集中的很重要一项功能就是与虚拟化的结合，虚拟化也是Server 08的一个很重要特性，后面我也会对虚拟化技术做相应的介绍。其实虚拟化技术的实现，是无法脱离高可用的，甚至可以这么说，没有高可用，虚拟化技术就没有意义!。通过虚拟化，我们可以将很多服务和应用放置在同一物理服务器上，但这无疑增加了这些应用和服务所面临的风险，因此企业必然需要在实现虚拟化的同时，有很好的高可用方案。我们在一些已经实现了虚拟化的企业客户中，也遇到了类似的问题，我想虚拟化可能是未来服务器发展的一个趋势，但高可用永远都会是服务器所必不可少的。
如何更改 SQL Server 故障转移群集实例的网络 IP 地址
在“计算机名称”屏幕中，选择"虚拟服务器"并指定要从中删除群集实例的服务器名。单击“下一步”按钮。在“安装选择”屏幕中，单击“对现有 SQL Server 实例进行升级、删除或添加组件”。在“实例名称”屏幕上，对于默认实例，单击“默认”按钮。对于命名实例，指定要删除的实例名。单击“下一步”按钮。 在“现有安装”屏幕上，单击“卸载现有安装”按钮。单击“下一步”按钮。 在“远程信息”屏幕中，指定对此群集所有节点都有效的管理员密码。单击"下一步"按钮。 出现“安装”信息的“成功卸载实例……”后，单击“确定”按钮。 在“安装完成”屏幕中，单击“完成”按钮。 如果安装程序指示重新启动计算机，则立即进行此操作。完成安装后，阅读来自 SQL Server 安装程序的消息是很重要的。未能重新启动任何指定的节点可能导致将来在故障转移群集中的任何节点上运行安装程序失败。
SQL Server 2000故障转移群集如何更改ip地址
从“开始”菜单中单击“运行”
，然后键入cluadmin以启动群集管理器并连接到本地实例。
在左侧窗格中，展开“组”节点，然后选择要更新的组。
在右侧窗格中，右键单击“SQL IP Address1”（故障转移群集实例名称）并选择“属性”。
单击“参数”选项卡，然后在“地址”字段中更新 SQL IP Address1（SQL Server 名称）的 IP 地址。
单击“应用”以实现更改。可能会显示下面的警告对话框：
“群集管理器标准扩展: 尝试设置属性时出错: 已存储属性，但是只有在下次资源联机时所有更改才会生效。错误 ID: 5024 (000013a0)。”单击“确定”清除“群集管理器标准扩展”
对话框，此时您将返回到“群集管理器”。若要使资源脱机，然后再使其重新联机，请使用下列步骤。
在右侧窗格中，右键单击“SQL IP Address1”（故障转移群集实例名称）并选择“脱机”
。将会看到 SQL IP Address1（故障转移群集实例名称）、SQL Network Name（故障转移群集实例名称）和 SQL Server 的状态从联机更改为脱机挂起，然后再更改为脱机。
注意将 IP 更改传播到整个企业网络可能需要 30 分钟或更长的时间。应该尝试将 SQL IP Address 1（故障转移群集实例名称）和 SQL Network Name（故障转移群集实例名称）联机，然后尝试 ping 该故障转移群集实例名称并等待 DNS 将其解析为新的 IP 地址。
在右侧窗格中，右键单击 SQL Server，然后选择“联机”
。将会看到 SQL IP Address1（故障转移群集实例名称）、SQL Network Name（故障转移群集实例名称）和 SQL Server 的状态从脱机更改为联机挂起，然后再更改为联机。
关闭“群集管理器”。
If you must change the IP address of your existing SQL Server 2000 failover cluster instance, whether it is a default instance or a named instance, you can use the AdvancedMaintain Virtual Server for Failover Clustering option in the SQL Server 2000 Setup program>>To use the AdvancedMaintain Virtual Server for Failover Clustering option, follow these steps:1 Insert the SQL Server 2000 Enterprise Edition CD, and then click SQL Server 2000 Components 2 Click Install Database Server 3 On the Welcome screen, click Next4 Type the name of the failover cluster instance that you want to modify, and then click Next 5 Click the Advanced options tab, and then click Next 6 Click Maintain a Virtual Server for Failover Clustering, and then click Next 7 In the Failover Clustering dialog box, you can: Add an IP address for additional networksRemove and replace an existing IP addressRemove IP addresses that you do not need After you make these changes, click Add, and then click Next>>Note Assign only one IP address for each network and one network for each network adapter SQL Server requires that each IP address that is assigned to it have its own unique subnet mask SQL Server does not support multiple IP addresses on the same subnet because this may result in duplicated names on the network For example, if you have a public network and a private network and you want to assign an additional IP address to your SQL Server failover cluster instance, you must add another network adapter to each node to create a new network You can then assign the additional IP address to the new network 8 Make any changes to the nodes, and then click Next 9 Verify the requested user information and password, and then click Next>>To verify that the changes were made, see the SQL Server 2000 IP resource properties in Cluster Administrator for the failover cluster instance10 Click Finish>> If the subnet mask for the resources in Windows cluster is changed, the steps that are mentioned earlier cannot be used to change the IP address of a SQL Server failover cluster instance
以上就是关于Win2008高可用性之FailoverCluster全部的内容，包括:Win2008高可用性之FailoverCluster、如何删除 SQL Server 故障转移群集实例、如何更改 SQL Server 故障转移群集实例的网络 IP 地址等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
