MSSQL高可用性和扩展性

欢迎转载但请保留出处

MSSQL高可用性和扩展性

 

在众多主流关系型数据库中Oracle的集中型(Rac), Mysql 的分布型(Repl)

前者往往依赖于主流厂商的硬件,纵向扩展负载CPU,面对IO的压力只能水平垂直拆分业务.

后者未被Oracle收购前版本在面对存储单点故障时M_M_S的结构又不那么灵活.而Mssql属于2者中间.在面对不同业务需求时候 Mssql同时提供Nothing Share和 Everything Share 模式.

所谓的Nothing Share 即: 横向扩张,读写分离.用多台便宜的Server + Sas盘来替代高端服务器和存储.而面对服务器级别的故障时Mssql同时提供了故障转移群集.群集的个数跟Windows 版本有关.生产环境中往往考虑到成本采用AA群集或者 2+1群集.

 

Windows Server 2003 最多支持 8 个故障转移群集节点

Windows Server 2008 最多支持 16 个故障转移群集节点

 

                           

                                                 　　　　　　　　　　　　(图:2) Everything Share (AA Cluster)

 

MSSQL 扩展性

 OLTP 讲究的是快进快出.因此在面对千万乃至亿级的的数据量.水平拆表成了上上之选

同时通过Replication 分发到多台便宜的Server + Sas盘来做读.

相对于Mysql的主机Repl,Mssql可以采用远程分发机来减少Repl本身带来的性能压力.

同时Mssql从2005 开始支持 乐观事务隔离,配合远程分发机,同时对分发机做AAcluster.

从主机性能压力和高安全都有完善的保障. 前端访问通过F5分配到多台SUB上,一旦出现SUB故障或者延迟较高时.可以从F5的虚拟ip池中把故障服务器从中Offline.等恢复故障后在Online.

分布式的扩展不仅能负载CPU同时也能对IO负载起到个很好的效果. (图:3)是Mssql Repl 配合水平拆分的扩展.

　　　　　　　　

                                                        (图:3) MSSQ基于Repl和水平拆分的扩展性

MSSQL的高可用性

Mssql用Cluster 来解决服务器级别高可用.通过存储做Raid10 和Mssql Mirror来保障

单点存储的故障.

   Mssql Cluster 把 OS的 IP和 MS的 IP 分开.一旦出现服务器故障.群集管理器自动把出现故障的节点的MSSQL服务转移到另一正常节点上.同时Mssql的IP 不变,因此不会对前端web服务器的写入有任何影响.相对于Mysql的Master_Master 模式不用担心前端数据写入的丢失和故障转移后的Repl的延迟.同时针对于存储级单点故障 Mssql还有Mirror来解决.

一般正常情况下存储做 Raid10后损坏的概率相对较小.但也不排除异常情况.比如存储上的控制器异常导致宕机. 一般中端存储的Raid控制器都是2个.当然也不排除某些厂商高端3par 多控制器.最近影响面大的一次宕机非属于艺龙了.

 

 

 

                                                                (图4:Mssql AAcluster故障转移)

     

 

                                                                   (图5:单点Storage故障转移)

 

 基于MSSQL常用结构

         前端web通过负载均衡器分担流量.DATABASE层用来写入和承当cash的读.Search层来用来承当普通的读. DATABASE层 由于多套AACluster 组成.存储为FC盘或者SSD.数据文件存放在Raid10的FC上,读文件存放在SSD上.Search层为单Server (如HP580 DellR710 HP380等) 配上 Sas 或者低端的存储(HPEVA 系列 EMC Cx 系列等).SnapShot层 是通过 AACluster Mirror搭通常情况下作为DATAJOB或者OLAP ODS层,同时也能起到对单点储存的保障.

 

 

 

以上种种,在一个大型互联网企业内只是冰山一角.同时结构随着数据量和性能压力不停在的变动.