自从SQL Server 2005以来,微软已经提供了多种高可用性技术来减少宕机时间和增加对业务数据的保护,而随着SQL Server 2008,SQL Server 2008 R2,SQL Server 2012的不断发布,SQL Server中已经存在了满足不同场景的多种高可用性技术。
在文章开始之前,我首先简单概述一下以什么来决定使用哪一种高可用性技术。 依靠什么来决定使用哪一种高可用性技术?很多企业都需要他们的全部或部分数据高可用,比如说在线购物网站,在线商品数据库必7*24小时在线,否则在竞争激烈的市场环境下,宕机时间就意味着流失客户和收入。再比如说,一个依赖于SQL Server的呼叫中心,如果数据库宕机,则所有的呼叫员都只能坐在那里回复客户“对不起,系统故障”,这也是很难接受的。 当然,在一个理想的世界中,所有的关键数据都会时刻在线,但在现实世界中,会存在各种各样的原因导致数据库不可用,由于无法预估灾难出现的时间和形式,需要提前采取措施来预防各种突发情况,因此SQL Server提供了多种高可用性技术,这些技术主要包括:集群、复制、镜像、日志传送、AlwaysOn可用性组以及其它诸如文件组备份还原、在线重建索引等单实例的高可用性技术。使用何种高可用性技术并不是随意挑一个熟悉技术直接使用,而是要基于业务和技术综合考虑。因为没有一项单独的技术可以实现所有的功能。如何根据具体的业务和预算采用这些技术,就是所谓的高可用性策略。 在设计高可用性策略时应该首先考虑下述因素:
预算 –RTO和RPO统称为SLA(服务水平协议),设计高可用性策略时,要根据业务来衡量满足何种程度的SLA,这要取决于预算以及衡量不同SLA在故障时所造成的损失。SLA并不是越高越好,而是要基于业务需求,通常来说,在有限的预算之下很难实现很高的SLA,并且即使通过复杂的架构实现较高的SLA,复杂的架构也意味着高运维成本,因此需要在预算范围之内选择合适的技术来满足SLA。 因此,综合来说,可以通过几个接单的问题确定高可用性的大框架:
冷备份、暖备份和热备份根据主机和备机之间同步数据的程度,备份可以分为三种情况,分别为冷备份、暖备份和热备份。
随着冷备份到暖备份到热备份,成本会直线上升。 SQL Server中所支持的高可用特性SQL Server中所支持的高可用性功能与版本息息相关,企业版支持所有的高可用性功能,这些功能包括:
具体何种版本支持哪些高可用特性,请参阅:http://msdn.microsoft.com/zh-cn/library/cc645993.aspx,值得注意的是免费的Express版本可以作为数据库镜像的见证服务器,从而节省了成本。 故障转移集群 故障转移集群为整个SQL Server实例提供高可用性支持,这意味着在集群上某个节点的SQL Server实例发生了硬件错误、操作系统错误等会故障转移到该集群上的其它节点。通过多个服务器(节点)共享一个或多个磁盘来实现高可用性,故障转移集群在网络中出现的方式就像单台计算机一样,但是具有高可用特性。值得注意的是,由于故障转移集群是基于共享磁盘,因此会存在磁盘单点故障,因此需要在磁盘层面部署SAN复制等额外的保护措施。最常见的故障转移集群是双节点的故障转移集群,包括主主节点和主从节点。 事务日志传送 事务日志传送提供了数据库级别的高可用性保护。日志传送可用来维护相应生产数据库(称为“主数据库”)的一个或多个备用数据库(称为“辅助数据库”)。发生故障转移之前,必须通过手动应用全部未还原的日志备份来完全更新辅助数据库。日志传送具有支持多个备用数据库的灵活性。如果需要多个备用数据库,可以单独使用日志传送或将其作为数据库镜像的补充。当这些解决方案一起使用时,当前数据库镜像配置的主体数据库同时也是当前日志传送配置的主数据库。 事务日志传送可用于做冷备份和暖备份的方式。 数据库镜像 数据库镜像实际上是个软件解决方案,同样提供了数据库级别的保护,可提供几乎是瞬时的故障转移,以提高数据库的可用性。数据库镜像可以用来维护相应生产数据库(称为“主体数据库”)的单个备用数据库(或“镜像数据库”)。 数据库镜像可用于做暖备份和热备份。 复制 复制严格来说并不算是一个为高可用性设计的功能,但的确可以被应用于高可用性。复制提供了数据库对象级别的保护。复制使用的是发布-订阅模式,即由主服务器(称为发布服务器)向一个或多个辅助服务器或订阅服务器发布数据。复制可在这些服务器间提供实时的可用性和可伸缩性。它支持筛选,以便为订阅服务器提供数据子集,同时还支持分区更新。订阅服务器处于联机状态,并且可用于报表或其他功能,而无需进行查询恢复。SQL Server 提供四种复制类型:快照复制、事务复制、对等复制以及合并复制。 AlwaysOn可用性组 AlwaysOn可用性组是SQL Server 2012推出的新功能。同样提供了数据库级别的保护。它取数据库镜像和故障转移集群之长,使得业务上有关联的数据库作为一个可用性组共同故障转移,该功能还拓展了数据库镜像只能1对1的限制,使得1个主副本可以对应最多4个辅助副本(在SQL Server 2014中,该限制被拓展到8个),其中2个辅助副本可以被作为热备份和主副本实时同步,而另外两个异步辅助副本可以作为暖备份。此外,辅助副本还可以被配置为只读,并可用于承担备份的负载。 正因为如此,数据库镜像在SQL Server 2012中被标记为“过时”。 高可用性策略设计在了解了高可用性基本的概念和SQL Server中提供的高可用性技术之后,我们再来看一下高可用性策略的设计。高可用性策略的规划可以分为四个阶段: 收集需求 决定高可用性策略的第一步无疑是收集业务需求来建立SLA。文中之前所述的RTO和RPO是最关键的部分,在此基础之上为可用性需求建立切实可行的期望,并基于该期望建立切实可行的高可用性策略。 评估限制 评估限制不仅仅指的评估是SQL Server中不同的高可用性技术中的限制,还包括那些非技术的限制。如果只有几万元的预算,却要做基于异地数据中心和SAN复制的高可用方案,那无疑是痴人说梦。另一个非技术限制是运维人员的水平,通常来说,复杂的架构意味着需要更高技能的运维人员。其它一些非技术限制包括数据中心的可用磁盘空间、电源供给和空调是否能满足需要,以及实现该可用性策略所需要的时间。 技术限制则包括不同高可用性的功能与限制,不同SQL Server版本所支持的功能以及CPU个数以及内存大小等。强烈建议在实施高可用性策略之前,首先参阅微软MSDN网站上不同SQL Server版本和功能的限制。 选择技术 在收集完需求并评估限制之后,接下来就是选择本文前面所述的技术或技术组合来满足SLA的需求。如果所选技术无法满足SLA,则可以很容易的报告出是由于什么限制无法满足SLA,从而可以申请缺少的资源或在SLA上做出妥协。 测试、验证并文档化 在高可用性策略一开始实施的时候就需要经过严格的测试和验证,从而确保当前的可用性策略能够满足SLA。但当高可用性策略上线之后,也要定期进行测试和验证来确保当前的策略在数据增长、业务或需求变更的情况下依然可以满足SLA。同时,要把可用性解决方案的配置、故障转移的方法和灾难恢复计划同时文档化,以便于出现故障或是未来调整高可用性策略时有迹可循。 小结本篇文章阐述了高可用性的基本概念、SLA的概念、SQL Server中所支持的不同种类的高可用性功能以及设计一个高可用性策略所需的步骤。值得注意的是,虽然本文仅仅讲述了数据库层面的高可用性,但高可用性不仅仅是DBA的事,还包括系统运维人员、网络管理人员、开发人员、管理人员等不同角色的共同协作,才能够更好的满足SLA。 |
|
来自: 贾朋亮博客 > 《高可用,集群,读写分离》