欢迎转载但请保留出处
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层,同时也能起到对单点储存的保障.
以上种种,在一个大型互联网企业内只是冰山一角.同时结构随着数据量和性能压力不停在的变动.