如何用SQLServer建立分布式数据库

很多组织机构慢慢的在不同的服务器和地点部署SQLServer数据库——为各种应用和目的——开始考虑通过SQLServer集群的方式来合并。

将SQLServer实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。

当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQLServer实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。

什么是Microsoft集群服务器

MSCS是一个WindowsServer企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。

这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。

MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。

在集群服务器上的SQLServer

SQLServer2000可以配置为最多4个节点的集群，而SQLServer2005可以配置为最多8个节点的集群。当一个SQLServer实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。

SQLServer2000允许在一个集群上安装16个实例。根据在线帮助，“SQLServer2005在一个服务器或者处理器上可以支持最多50个SQLServer实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”

注意SQLServer实例的灾难恢复阶段是指SQLServer服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如logshipping和数据库镜像。

单个的大的SQLServer集群还是小的集群

下面是大的、由更多的节点组成的集群的优点：

◆更高的可用新(更多的节点来灾难恢复)。

◆更多的负载均衡选择(更多的节点)。

◆更低廉的维护成本。

◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。

◆增强的管理性和简化环境(需要管理的少了)。

◆更少的停机时间(灾难恢复更多的选择)。

◆灾难恢复性能不受集群中的节点数目影响。

下面是单个大的集群的缺点：

◆集群节点数目有限(如果需要第9个节点怎么办)。

◆在集群中SQL实例数目有限。

◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。

◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。

虚拟化和集群

虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQLServer实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQLServer实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。

在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQLServer进行负载均衡。比如，使用虚拟机上的SQLServer实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。

集群服务器可以用于SQLServer的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。

由二台或更多物理上独立的服务器共同组成的“虚拟”服务器称之为集群服务器。一项称做MicroSoft集群服务(MSCS)的微软服务可对集群服务器进行管理。一个SQL Server集群是由二台或更多运行SQL Server的服务器（节点）组成的虚拟服务器。如果集群中的一个节点发生故障，集群中的另一个节点就承担这个故障节点的责任。
认为一个SQL Server集群能够给集群中的两个节点带来负载平衡，这是一种常见的误解。虽然这似乎很有用，但却是不正确的。这也意味着集束SQL Server不能真正提高性能。集束SQL Server只能提供故障转移功能。故障转移就是当系统中的一台机器发生故障失去其功能时，另一台机器将接手运行它的SQL Server实例。这种功能失效可能是由于硬件故障、服务故障、人工故障或各种其它原因。
为何要集束SQL Server环境？
在实用性方面，集群SQL Server环境令人满意。在进行故障转移时，将数据库实例由一台服务器转移到另一台服务器的时间非常短暂，一般只需要3至7秒钟。虽然需要重建连接，但对数据库的终端用户而言，故障转移处理通常是透明的。低廉的故障转移成本还可帮助你对集群中的节点进行维护，而不会造成服务器完全无法访问。
SQL Server集群类型
一共有两种类型的SQL Server集群：主动/被动集群和主动/主动集群。下面分别对它们进行说明（说明以两个节点的SQL Server集群为基础）。
主动/被动集群
在这种类型的集群中，一次只有一个节点控制SQL Server资源。另一个节点一直处于备用模式，等待故障发生。进行故障转移时，备用的节点即取得SQL Server资源的控制权。
优点：由于服务器上只有一个实例在运行，所以在进行故障转移时，不需要另外的服务器来接管两个SQL Server实例，性能也不会因此降低。
缺点：由于虚拟服务器上只有一个SQL Server实例在运行，另一台服务器总是处理备用模式与空闲状态。这意味着你并没有充分利用你购买的硬件。
主动/主动集群
在这种类型的集群中，集群中的每个节点运行一个独立且主动的SQL Server实例。发生节点故障时，另一个节点能够控制发生故障节点的SQL Server实例。然后这个正常的节点将运行两个SQL Server实例——它自己的实例和发生故障的实例。
优点：通过这种配置，你能够充分利用你的硬件。在这样的系统中，两个服务器都在运行，而不是只有一台服务器运行，而另一台处于等待故障发生的备用模式，因此你能够充分利用你购买的机器。
缺点：如果进行故障转移，一台服务器运行两个SQL Server实例，性能就会受到不利影响。然而，性能降低总比虚拟服务器完全失灵要强得多。这种配置的另一故障在于它要求购买的许可要比主动/被动集群多一些。因为集群在运行两个主动SQL Server实例，这要求你购买两个单独的服务器许可。在某些情况下，这也可能对你形成阻碍。
集群考虑
在高实用性方面，集群SQL Server环境有一定的优势。然而，高实用性也确实伴随某种折衷。
首先，建立一个集群SQL Server环境非常昂贵。这是因为集群中的节点必须遵照集群节点的兼容性列表。而且，还需要建立一个复杂的网络，机器的配置必须几乎相同，同时需要实现数据库文件磁盘子系统共享。存储区网络(SAN)是建立这种子系统的不错选择，但SAN并非必要，而且十分昂贵。另外，如果你正在运行一个主动/主动集群，你需要为集群中运行SQL Server实例的每台机器的处理器购买一个许可。
因为当地集群主要局限于同一地理区域，自然灾难可能会使集群完全失灵。在那种情况下，你需要转移到灾难恢复站点进行继续 *** 作。你也可以建立地理分散的SQL Server集群，但这样的系统更加复杂与昂贵。

服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。

1、集群是什么？
① 集群（cluster）技术是一种较新的技术，通过集群技术，可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较高的收益，其任务调度则是集群系统中的核心技术。
② 集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群像是一个独立的服务器。
③ 集群组成后，可以利用多个计算机和组合进行海量请求处理（ 负载均衡 ），从而获得很高的处理效率，也可以用多个计算机做备份（高可用），使得任何一个机器坏了整个系统还是能正常运行。集群在目前互联网公司是必备的技术，极大提高互联网业务的可用性和可缩放性。
2、负载均衡集群技术
① 负载均衡（Load Balance）：负载均衡集群为企业需求提供了可解决容量问题的有效方案。负载均衡集群使负载可以在计算机集群中尽可能平均地分摊处理。
② 负载通常包括应用程序处理负载和网络流量负载。这样的系统非常适合向使用同一组应用程序的大量用户提供服务。每个节点都可以承担一定的处理负载，并且可以实现处理负载在节点之间的动态分配，以实现负载均衡。对于网络流量负载,当网络服务程序接受了高入网流量，以致无法迅速处理，这时，网络流量就会发送给在其它节点上运行的网络服务程序。也可根据服务器的承载能力，进行服务请求的分发，从而使用户的请求得到更快速的处理。
3、负载均衡集群技术的实现
负载均衡（Load Balance）
负载均衡技术类型：基于 4 层负载均衡技术和基于 7 层负载均衡技术
负载均衡实现方式：硬件负载均衡设备或者软件负载均衡
硬件负载均衡产品： F5 BIG-IP 、Citrix Netscaler  、深信服 、Array 、Radware
软件负载均衡产品： LVS （Linux Virtual Server）、 Haproxy、Nginx、Ats（apache traffic server）
4、实现效果如图

5、负载均衡分类
负载均衡根据所采用的设备对象（ 软/硬件负载均衡 ），应用的OSI网络层次（ 网络层次上的负载均衡 ），及应用的地理结构（ 本地/全局负载均衡 ）等来分类。本文着重介绍的是根据应用的 OSI 网络层次来分类的两个负载均衡类型。
我们先来看一张图，相信很多同学对这张图都不陌生，这是一张网络模型图，包含了 OSI 模型及 TCP/IP 模型，两个模型虽然有一点点区别，但主要的目的是一样的，模型图描述了通信是怎么进行的。它解决了实现有效通信所需要的所有过程，并将这些过程划分为逻辑上的层。层可以简单地理解成数据通信需要的步骤。

根据负载均衡所作用在 OSI 模型的位置不同，负载均衡可以大概分为以下几类：
二层负载均衡（mac）
根据OSI模型分的二层负载，一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应。
三层负载均衡（ip）
一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应。
四层负载均衡（tcp）
在三层负载均衡的基础上，用ip+port接收请求，再转发到对应的机器。
七层负载均衡（>如果是集群的话，我考虑需要流畅运行的话，2核4G配置是可以满足的。因为这个集群形式，用于适用于物联网、车联网、监控、安全风控、即时通讯、消息存储等行业场景，所以数据量是比较大的，所以配置太低了跑不动，会卡死的。
因为hadoop是海量数据的处理能力，所以服务器一定不能太小配置了，跑不动了就没实际用途了。最好使用4核8G内存及以上配置。
因为这方面内容较多，这里也写不开那么多内容，所以你可以留言或到我的博客上搜索相关内容，老魏有写过教程，还不止一篇，都挺详细的内容，可以帮助你入门。

呵呵 首先 你的2个服务器最好配置很相近 其次是用server2003 或者更高版本
其次 2台服务器是可以群集 但是最好是3台 其中有一个是域控制器，具体如何组件 请查看群集指南 微软官方就有，权威而且准确，又详细

市面上存在两种数据库负载均衡的思路：1

基于数据库连接的负载均衡：例如总共有100个数据库连接，50个连接登录到数据库机器A，另外50个连接登录到数据库机器B，这样每个连接中接下来的所有请求全都是发往同一台数据库机器的

这种数据库负载均衡的思路模拟了WEB上的负载均衡方法，但是由于WEB连接是短时间连接(连接建立后，获取需要的HTML等资源后，连接马上被关闭)，而数据库连接是长时间连接(连接建立后，可长时间保持，客户可不停向数据库发送SQL请求，数据库做出回答，如此不断循环直到连接被人为或因错而断开为止)，因此这种数据库负载均衡思路存在着明显的缺点：有可能会发生绝大部分的请求压力都集中到某台数据库机器上去，从而使得负载均衡效果失效

2

基于批处理请求的负载均衡：在建立数据库连接的时候，会同时与每台数据库服务器建立连接，之后针对客户端的每次请求，都会根据负载均衡算法，独立地选出某个数据库节点来执行这个请求

此种思路符合数据库长时间连接的特征，不存在上面所述的基于连接的负载均衡方法的缺点

市面上的负载均衡厂商，既有基于连接的，也有基于批处理请求的，用户需仔细辨别才能找到自己想要的合适产品

---