将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。
当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。
什么是Microsoft集群服务器
MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。
这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。
MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。
在集群服务器上的SQL Server
SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。
SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”
注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。
单个的大的SQL Server集群还是小的集群
下面是大的、由更多的节点组成的集群的优点：
◆更高的可用新(更多的节点来灾难恢复)。
◆更多的负载均衡选择(更多的节点)。
◆更低廉的维护成本。
◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。
◆增强的管理性和简化环境(需要管理的少了)。
◆更少的停机时间(灾难恢复更多的选择)。
◆灾难恢复性能不受集群中的节点数目影响。
下面是单个大的集群的缺点：
◆集群节点数目有限(如果需要第9个节点怎么办)。
◆在集群中SQL实例数目有限。
◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。
◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。
虚拟化和集群
虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。
在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。
集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。负载均衡
先来简单了解一下什么是负载均衡，单从字面上的意思来理解就可以解释N台服务器平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现，也就是两台以上即可。
测试环境
由于没有服务器，所以本次测试直接host指定域名，然后在VMware里安装了三台CentOS。
测试域名 ：acom
A服务器IP ：1921685149 （主）
B服务器IP ：192168527
C服务器IP ：1921685126
部署思路
A服务器做为主服务器，域名直接解析到A服务器（1921685149）上，由A服务器负载均衡到B服务器（192168527）与C服务器（1921685126）上。
域名解析
由于不是真实环境，域名就随便使用一个acom用作测试，所以acom的解析只能在hosts文件设置。
打开：C:WindowsSystem32driversetchosts
在末尾添加
1921685149 acom
保存退出，然后启动命令模式ping下看看是否已设置成功
从截图上看已成功将acom解析到1921685149IP
A服务器nginxconf设置
打开nginxconf，文件位置在nginx安装目录的conf目录下。
在>1921681100 (电信)
1921681101 (电信)
1921681102 (电信)
101010100 (网通)
101010101 (网通)
并且5台服务器都在为>
负载均衡架构部分转自 58沈剑 [架构师之路]( >西部数码负载均衡EasySLB服务，即在多台云主机间实现应用程序流量的自动分配。可实现故障自动切换，提高业务可用性，并提高资源利用率。
西部数码负载均衡只需要在控制台一键即可添加后端服务器，系统将自动设置好相关路由与网关，让负载均衡集群的搭建变得轻而易举
注：
正向代理，代理的是用户。
反向代理，代理的是服务器
什么是负载均衡
当一台服务器的单位时间内的访问量越大时，服务器压力就越大，大到超过自身承受能力时，服务器就会崩溃。为了避免服务器崩溃，让用户有更好的体验，我们通过负载均衡的方式来分担服务器压力。
我们可以建立很多很多服务器，组成一个服务器集群，当用户访问网站时，先访问一个中间服务器，在让这个中间服务器在服务器集群中选择一个压力较小的服务器，然后将该访问请求引入该服务器。如此以来，用户的每次访问，都会保证服务器集群中的每个服务器压力趋于平衡，分担了服务器压力，避免了服务器崩溃的情况。
负载均衡是用反向代理的原理实现的。
1、轮询（默认）
每个请求 按时间顺序逐一分配 到不同的后端服务器，如果后端服务器down掉，能自动剔除。
upstreambackserver {server192168014;server192168015;}
2、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的
情况。
upstreambackserver {server192168014weight=3;server192168015weight=7;}
权重越高，在被访问的概率越大，如上例，分别是30%，70%。
3、上述方式存在一个问题就是说，在负载均衡系统中，假如用户在某台服务器上登录了，那么该用户第二次请求的时候，因为我们是负载均衡系统，每次请求都会重新定位到服务器集群中的某一个，那么已经登录某一个服务器的用户再重新定位到另一个服务器，其登录信息将会丢失，这样显然是不妥的。
我们可以采用ip_hash指令解决这个问题，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
upstreambackserver{ip_hash;server192168014:88;server192168015:80;}
4、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstreambackserver {serverserver1;serverserver2;fair;}
5、url_hash（第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
upstream backserver { server squid1:3128; server squid2:3128; hash$request_uri; hash_method crc32;}123456
每个设备的状态设置为:
down 表示单前的server暂时不参与负载
weight 默认为1weight越大，负载的权重就越大。
max_fails：允许请求失败的次数默认为1当超过最大次数时，返回 proxy_next_upstream模块定义的错误
fail_timeout:max_fails次失败后，暂停的时间。
backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。
配置实例：
#user nobody;worker_processes4;events {# 最大并发数worker_connections1024;}>
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）