请问大神们，用哪些硬件或软件来实现NLBLVSMSCSORACLE RAC？

NLB：可以用硬件（比如：F5）或软件(LVS,Nginx,haproxy等)实现
LVS：LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。百度百科有
MSCS：微软集群服务，windows server 企业版支持
Oracle RAC：oracle 数据库集群，需要两个主机和共享存储。oracle 企业版支持
如果想做这些实验，可以用一台大内存大硬盘的电脑安装esxi 虚拟化后安装多台虚拟机进行实验。

为什么又说是“终于”呢？ 因为花了3个工作日，带加班加一块18个小时的现场安装时间，才最终搞定，辛苦辛苦！

SQL群集手动切换是正常的。


*** 作系统：Windows Server 2008 R2 Enterprise Edition (x64)

群集软件：OS自带的“故障转移群集”

数据库：SQL Server 2008 R2 Enterprise Edition (x64)

共享存储：IBM DS4300 ，8x300GB SAS，划完共4块磁盘，共16TB，RAID 5，阵列卡交换速率4G，双通单控
主要遇到过的问题：
1、存储划错，重划时由于采用另一台电脑划分，群集重启后无法认到，于时MSCS破坏群集不正常，2台节点只好重装

2、不能采用DC作为群集节点，故安装双节点群集至少需要3台主机，另有1台充当DC， *** 作步骤为：
在第3台主机上安装现有域的第3台DC，确认与其他2台DC都可以进行复制 *** 作
将根域DC上的5个FSMO角色传送到第3台DC，确认第3台DC同时为GC
运行dcpromo命令在原先2台DC上反安装DC，在反安装时不要选中“这是最后一台域控制器”
检测域DNS和AD的正确性
检测MSCS的正确性

3、安装SQL2008RTM群集时出错，提示RequireKerberos=1超出范围错误（这是SQL2008RTM在群集安装时会出现的1个BUG，必须采用slipstream方式附带SP1一块安装），不得已反安装，但由于手动将MSCS中失败的SQL资源删除，使得SQL反安装失败，手动删除注册表均未果，只好重装节点1，重装时的正确步骤为：
破坏群集（由于存储正常，很快完成）
将节点1退出域（此时在DC中显示该节点帐号为禁用状态，不要删除它）
重新安装节点1 *** 作系统，配置存储阵列盘、配置IP地址与域DNS，加入域
删除域中有关原群集的信息，包括群集名称在AD数据库中的内容（在Computer容器下），检查DNS中无群集节点解析

微软公司的SQL Server 发布已经有一段时间了 先前作了简单的测试安装 感觉确实有不小的改进 在 *** 作上我还是有些不适应 毕竟我不是专门做数据库管理的 菜啊！

之所以会对SQL 感兴趣 主要是因为很多朋友都在用 而且未来我可能也会接触它 一直以来都想搞一次MDaemon的冗余方案测试 本来打算采用免费的MySQL可是发现目前的 x版本竟然无法正常运行在MSCS上 无奈等待了有数月之久直到微软的SQL 发布 哈哈！机器的内存也升级到 G 所以决定抱着勇于求知的精神开始筹备测试部署SQL 群集 年前最后一天班下午没有太多事情就搭建了一个DC+NodeA+NodeB的群集环境 安装SQL 还是比较顺利的 后来放入第二张盘安装便失败了 以为是因宿主性能造成（在 M内存的虚拟机中安装SQL 群集 真的是非常得慢 我可怜的硬盘） 决定年后上班搭建一个双节点群集环境来做测试 这样一来资源占用应该会小很多 毕竟撤掉一台单独的DC

昨天是年后的第一天班 处理完手上的工作 下午便开始搭建双节点群集环境 这样强烈使用VMware GSX来作为虚拟机软件 不像VSRV R 那样配置方便 但是相对来说整体的 *** 作还是优于VSRV R 的 另外就是运行速度 感觉确实要快很多 新版的GSX搭建MCSC还是比较简便的 不必像网上资料中写的需要什么pln工具 直接生成固定容量磁盘后 修改虚拟机的配置文件添加参数就可以了 关于配置参数的资料可以参考

本文主要总结SQL 的群集部署 所以关于VMware下MSCS环境的搭建步骤就不再重复 直接从主题开始

测试环境 宿主机           硬件配置 PIV G/ G DDR / G PATA pm/ C NIC           *** 作系统 Microsoft Windows XP Pro With SP ENU           虚拟平台 VMware GSX

VirtualHost Microsoft Cluster NodeA           硬件配置 PIV G/ M/ G/vlance NIC/vmxnet NIC           *** 作系统 Microsoft Windows Server EE With SP CHS           网卡信息 vlance NIC M 全速半双工/HeartBeat/IP                           vmxnet NIC M 全速全双工/Public/IP /GW /DNS /WINS            承载服务 DC+DNS+WINS+IIS

VirtualHost Microsoft Cluster NodeB           硬件配置 PIV G/ M/ G/vlance NIC/vmxnet NIC           *** 作系统 Microsoft Windows Server EE With SP CHS           网卡信息 vlance NIC M 全速半双工/HeartBeat/IP                           vmxnet NIC M 全速全双工/Public/IP /GW /DNS /WINS          承载服务 DC+DNS+WINS+IIS

Virtual G Pln Qdisk M/Sdisk M        注意 本次测试将仲裁盘和资源盘放在了一起 实际中最佳的做法应当单独配置一个物理磁盘作仲裁使用 为提高安全性还应该为仲裁磁盘配置RAID

MSCS IP

目标实现 成功部署 SQL Server 群集/HostName SQL /IP

群集实施       我手上的SQL 为企业中文版 CD 首先放入第一张盘 点击 服务器组件 工具 联机丛书和示例 开始SQL 的群集安装 安装程序会自动检测当前是否为群集环境并为群集安装准备 小提示 MSCS默认环境下 群集组资源中缺少MSDTC组件 所以需要先添加MSDTC后再开始SQL 的群集安装 否则会出现警告并停止！

接受软件使用许可协议

SQL 在进行初始检测后开始执行安装 SQL 所需组件

完成所必需组件的安装

安装程序开始执行系统配置检查

进入SQL 的安装向导

向导开始执行系统配置检查 因为是安装群集 会自动检查各节点并给出状态提示 因为虚拟机配置的是 M内存 所以这里会 最低硬件要求 的警告 可以忽略！

选择要安装的组件 如要得到各组件的详细信息可以选择高级项

进入高级项后就来到了详细的各组件的功能选择 这里可以得到详细的组件信息 根据需要选择组件功能

实例名 配置中选择 默认实例

虚拟服务器名称配置中 为此群集命名为sql

为虚拟服务器配置IP 这里我使用Public作为公共访问 并分配一个IP 添加后点击 下一步

在 选择群集组 中选择可以得群集组 因为这里我只有一个默认的群集组 所以点击 下一步 继续

d出警告 提示我此群集组包含仲裁资源 这是因为我之前配置了一块Pln磁盘并分配两个逻辑分区来做群集 因此在这里会提示警告 可以直接忽略

群集节点配置中 选择可用的节点 因为我当前是双节点群集环境 所以安装向导自动为我选择了NodeA节点

配置远程安装的帐户 这里的帐户必须是各节点上有效的管理员帐户

为服务配置帐户 之前我已经添加了一个名为sql 的域用户作为SQL服务帐户 所以这里填写上正确的信息

配置群集服务的域组 这里其实我到现在还没有彻底搞明白是什么意思 参看帮助文件 便在域中为每个SQL服务创建对应的全局组 （希望达人能够帮我解答一下此处的意义！）

身份验证模式中 选择 混合模式 这和SQL 的感念是一样的

排序规则我是按照默认选择的

这里我没有选择微软提供的跟踪服务功能

前期的安装配置完成后就准备开始执行正式的文件安装 激动啊！

SQL 的群集安装进度还是很人性化的 这里你可以切换每个节点来监视安装进度

到这里就是一个漫长的等待了 真是心疼我的硬盘 不过结果很悲惨 在CD 安装完毕后 系统提示我插入CD 记得年前的测试也是在这里出现问题的 感觉会不会是因为磁盘写延迟 导致另外一个节点没有安装完 我就放入第二张CD造成的呢？抱着幻想我就一直等待 并且监视两台节点的日志 直到节点的硬盘和网卡没有强烈的提示后 我才放入CD 点击了确定 谁知道接下来就出现了之前测试相同的错误 安装终止并结束了 郁闷！这是怎么回事？检查系统发现SQL 的服务已经是启动了 这么说服务的安装时成功的 于是进入添加删除程序中 使用更改方式检查SQL 的安装 发现这里只有添加节点和卸载SQL 群集两个选择

重新执行光盘 发现CD 原来是 工具 联机丛书和示例 的安装盘

于是再次执行安装程序 哈哈 记起来了！之前也重新执行过安装不过放入的是CD 所以组件选中服务项等都是不安装 我以为红叉代表删除 所以就没敢继续 如果当时直接从CD 执行安装估计也就成功了

我个人认为 SQL 的管理工具等组件应该在群集安装后再单独为每个节点安装才是最佳的做法 至于为什么之前会失败只能靠其他达人来做试验来验证了！完成了管理工具等组件的安装 怀着兴奋的心情打开了全新的SQL 管理工具 默认启动后显示的是连接到服务器的配置页面 这里配置好登录后 可以在管理工具的选项中修改初始打开页面 在 已注册的服务器 窗体中打开SQL 服务器

哈哈 SQL 的群集算是安装完成了 真是令人兴奋！ 

进入 群集管理器 中检查SQL 群集的安装 发现没有问题 心理已经非常激动了！

最后来验证一下群集是否真的开始正常工作了 我将NodeB节点关闭后 在NodeA上打开 群集管理器 发现SQL 的群集资源已经自动并成功地从NodeB上转移到了NodeA 在NodeA上打开SQL 的管理工具进行服务器连接测试 成功！

至此 SQL 的群集算是圆满测试成功了 其间也是走了不少弯路 不过最后总算是成功了 心理也得到了安慰 其实SQL 的群集还是非常简单的 只不过CD 的安装出错到底是因为其本身不支持群集安装还是因为其他原因目前还不知晓 只能等权威的解释了！另外 SQL 的群集安装需要在拥有活动资源的节点上进行安装

总算是把文章写完了 今天狂停电 真郁闷！害死我了 最后算是一边写一边发布再编辑 真是费神 此实战总结为个人观点 其中有不足或错误之处还希望大家多多指正！

lishixinzhi/Article/program/SQLServer/201311/22067

为了将停机时间减到最少 您很可能必须使用日志传送 除非您的数据库相当小并且在一段时间内没有用户建立连接 在移交之前 您都可以正确执行日志传送 接着 删除这些用户 剪切并传送最后的日志 然后指向新实例上的应用程序 (有关感兴趣的日志传送替代方法 请参阅下面的数据库镜像部分 )如果使用DNS别名 您甚至可能不需要指向新实例上的应用程序 而是只需更新 DNS 别名 这种方法的优点是 如果您的迁移只进行了一部分 但必须要回退到原始状态 那您至少还有原始文件

您还可以采用一种成本较低的方案 但需要您做更多的预先规划 一个群集可以支持多个SQL Server实例 但每个实例必须有其自己的磁盘资源 因此 在划分SAN时 请留出一个LUN 以备将来升级 要执行升级 请在此磁盘资源上安装 SQL Server 二进制文件 您可以演习一下该系统 当您准备好后 关闭当前SQL Server 将磁盘资源从旧的 SQL Server组中移出 更新依赖关系 然后使新SQL Server实例在线 连接旧实例中的数据库 然后启动并运行 (您已提早备份了所有数据 对吗)

这就是成本较低的方法 实行这个方法需要承担一些风险 如果出现故障 您无法将数据库与新实例分离开来并放回原来位置 您的 *** 作已简化为从备份恢复 这意味着需要很长的停机时间

还有一种方法是将两个SQL Server实例都放在您的SAN中 前提是您有足够的磁盘空间 将生产备份(和日志传送)恢复为新实例 然后按前面介绍的步骤继续进行 但现在您有退路了 而且 一旦完成迁移 您还可以释放旧实例占用的SAN资源 您只需增加额外的磁盘

负载平衡

让我们首先揭穿这样一个常见误解 MSCS群集是用于获得高可用性的 而非用于实现负载平衡 此外 SQL Server没有任何内置的 自动负载平衡功能 您必须通过应用程序的物理设计来实现负载平衡 这意味着什么

随着表的逐渐增长 您可能会预料到性能会降低 特别是在涉及到表扫描 *** 作时 当行数达到数百万或数十亿时 传统的解决方案会使用已分区视图 这种视图由若干具有相同结构 使用 union ALL 挂接在一起的表组成 此外 还会在适当位置放置 CHECK 约束来区分这些成员表 而这会阻止跨已分区视图复制数据 如果在 CHECK 约束中使用的列也是主键的一部分 则该视图是可更新的

如果成员表在其自己的文件组中 则如果这些文件组中的文件分别位于不同的物理驱动器上 那么您会获得更佳的磁盘性能 这些表甚至也可以位于不同的数据库中 但是 在SQL Server 中 只要所有数据均在同一个数据库中 您就可以使用表分区 而表分区实现起来就容易得多了

但是 假设您已经尽可能地利用了表分区或(本地)已分区视图 但性能仍然很低 如果您拥有SQL Server 或SQL Server 就可以利用分布式已分区视图了 主要差别在于 成员表可以位于不同的 SQL Server 实例上 而且这些实例可以安装在 N+ 群集上 为什么鼓励您这样做如果已分区视图中的任何一个成员表转入离线状态 则整个视图也将转入离线状态 使这些成员成为群集的一部分可以为您提供支持性能和实现负载平衡所需的可靠性

您真的需要群集吗

或许您有一些备用服务器无事可做 但这些服务器不在 Windows 目录的群集部分中 如果您在这些服务器可用的情况下 只是为了支持群集就必须出去购置新服务器 那么这是一种浪费可耻的行为

数据库镜像可能是最适合替代群集的一种方法 镜像涉及到三个元素 存储镜像数据库的实例称为主体;备份服务器称为镜像;如果要实现自动故障转移 还需要第三台服务器 称为见证方 简而言之 主体上的数据库中的事务会在镜像中再次运行 当主体出现故障时 如果有见证方 数据库会自动故障转移到镜像 您必须为每个应用程序数据库设置镜像 但不能镜像系统数据库

镜像是单独的SQL Server 实例 与群集不同的是 镜像可以位于几千英里以外 其高速缓存中填充的是由于从主体中复制事务而发生的更新活动 当然 还可以假设 除了从主体接收镜像事务之外 镜像上没有其他活动 既然 SQL Server 已经在镜像中运行 所以 故障转移的速度通常要比在群集中快 由于至少有部分高速缓存已准备好 所以 初始性能并不像在群集方案中那样低 另请注意 当镜像数据库发生故障转移时 主体和镜像会互换角色

数据库镜像的不足之处是 需要的总磁盘容量是群集的两倍 如果您想在同步模式下运行且不想丢失任何数据 那么您还会需要更多的 CPU 处理能力 正如我所说的 要想实现高可用性 需要花费很高的成本

组合方法

由于镜像与主体之间的距离可以相当遥远 所以对于灾难恢复 (DR) 计划来说 选择镜像是非常明智的 群集是您的第一道防线 但是 如果您要同时利用群集和镜像 那会出现什么情况呢在群集故障转移中 如果您的镜像配置中有见证方 则当群集 SQL Server 转入在线状态时 镜像会成为主体 但是 请注意 从新主体回到(群集的)新镜像的故障转移不是自动进行的 因此 当与群集结合使用时 最好不要对您的镜像数据库启用自动故障转移

灾难恢复并不是您使用镜像的唯一原因;当您必须向主体应用服务包或修补程序时 镜像也是非常有用的 在这种情况下 您可以手动故障转移到镜像 在应用服务包或修补程序时 旧的主体服务器暂时处于离线状态 在新主体上发生的已提交事务会排队等候 等待被发送回新镜像(旧主体) 在完成服务包或修补程序的安装之后将会进行同步 最终 这两台服务器将完全处于同步状态 现在您便可以在主体和镜像之间转换角色了 故障转移与恢复只需要几秒钟的停机时间 您可以使用这种方法将 SQL Server 迁移到另一台计算机 只是不能实现故障恢复

虚拟服务器添加灵活性

虚拟化允许您在一台物理服务器上并行运行一个或多个 *** 作系统 虚拟化软件为群集概念添加了另外一层功能 因为您可以将软件加入群集 因此 如果主机正在其上运行的服务器出现故障 则主机及其来宾 OS 会故障转移到备份节点 这可能是迁移来宾服务器的最简便方法 补充一点 来宾 OS 不必具有群集功能 因此 您可以在运行于某群集中的 Microsoft Virtual Server 之上的来宾 Windows Server 内部运行 SQL Server Workgroup Edition 实质上 您会间接拥有群集 Workgroup Edition

在控制之下

如果您在负责 SQL Server 实现 您需要确信您的服务器始终处于可用状态 服务器群集会帮助确保您的服务器始终可用 本文提供了一些来之不易的技巧 以帮助您入门 您可以在 群集资源 边栏中找到更多有用信息

lishixinzhi/Article/program/SQLServer/201311/22476

---