设为首页 收藏本站
查看: 1095|回复: 0

[经验分享] 存储系统----存储技术(3)

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2014-7-18 09:50:43 | 显示全部楼层 |阅读模式
存储分层(StorageTiering)
         通常,制造非易失性存储器是为了提供高性能或高容量。高性能磁盘和闪存驱动器的成本比高密度存储要高得多。为了最有效地利用容量和性能,SAN阵列允许多种类型的存储,混合在给定的阵列中。SAN阵列中的这种混搭存储被称为存储分层。有些存储阵列提供自动化的存储分层,监视卷或卷片的高性能。当检测到预定的性能特性,阵列会把数据迁移到存储的更高层次。不同的存储厂商都以独特的方式实现存储分层,其中最独特的功能是迁移数据的粒度。有些使用几KB的传输大小,有些是GB的数据。每个系统都有不同的性能表现。存储分层具有改变性能超时的效果。许多金融系统总是需要一致的性能。如果您的特定系统要求可重复的性能(repeatable performance),那么存储分层就不应该被使用。
数据复制(Data Replication)
         SAN阵列提供内部和外部存储的数据复制。内部复制包含数据的快照和克隆。有些存储阵列提供内部阵列的数据迁移功能。快照和克隆都提供时间点数据副本。该数据副本可用于备份或报告(有关提升报表系统性能的更多信息可访问:http://sqlvelocity.typepad.com/blog/2010/09/scalable-shared-data-base-part-1.html)。快照和克隆都需要用数据库日志和数据文件同步创建。为了保持SQL数据完整性,日志文件和数据文件都需要在完全相同的时间被复制。如果日志和数据文件不同步,数据库可以出现不可恢复。在创建时间点数据复制之前,你需要决定所SQL Server需要的恢复类型。您可以使用SQL Server虚拟备份设备接口(VDI)创建应用程序一致的副本。 VDI是一个API规范,负责协调新的写操作冻结,把脏内存缓冲区页刷到磁盘(从而确保日志和数据库文件是一致的),以及分裂克隆或快照卷。分裂是阻止克隆操作,并使快照或克隆卷准备使用的过程。一旦分裂完成,数据库就恢复正常的写操作,读取不受影响。
         SQL Server提供了改善数据装载的功能。这些功能改变数据如何被写入,且能够影响SQL Server复制。Microsoft通过跟踪标志610提供了数据装载的详细信息:http://msdn.microsoft.com/en-us/library/dd425070(v=SQL.100).aspx
         如果数据库在有机会把缓存区页的脏数据刷到磁盘前关闭了,预写日志记录功能使SQL Server能够恢复写到日志文件的数据,这种恢复模式能够采用了先进的复制技术。在克隆被创建的时间点,克隆数据卷创建一个源卷的精确副本(如图4-9)。因为克隆是完全相同的副本,它能够隔离I/O性能。当克隆被装载到不同的主机时,源卷能正常继续运转。这能够把工作负载分配到多台机器,而不影响源卷。这种情况非常有助于高性能报表系统。记住,在存储阵列中,克隆卷需要与原始卷需求相同的空间。
SouthEast.jpg
硬件存储快照,如图4-10所示,是时间点数据复制。该快照不同于克隆数据复制,因为它仅保留更改的数据的原始正本。硬件快照不同于SQL Server数据库快照。SQL Server快照提供基于时间点的数据库的只读状态视图。有关SQL Server数据库快照的更多信息,请访问:http://msdn.microsoft.com/zh-cn/library/ms175158.aspx
SouthEast.jpg
当变化被写入到存储卷,该阵列存储原始数据,然后将新数据写入到磁盘中。所有的变化被跟踪,直到用户请求一个实时数据副本。该阵列关联所有更改的数据块,这些数据块现在代表那个时刻的卷的状态。用户可以继续创建多达阵列支持数量的快照卷。快照利用基于数据变化速率的能力。快照消耗比实际更多的数据是可能的。到期的快照卷可以减少空间消耗的量。快照不隔离性能。任何对快照卷执行的I/O,都要访问源卷和任何保存的更改。如果主数据库服务器太忙,以至于你已经决定利用第二台服务器来执行报告功能,一个克隆卷可能是比快照更好的选择。对于业务连续性和灾难恢复( BCDR ),你还可以考虑分层的方法。克隆卷提供一个唯一的数据副本。请记住,克隆是原始数据的镜像,并会消耗与原始卷相同的容量。保持几个克隆副本可能成本高昂。快照可以提供许多价格便宜点的实时(point-in-time)副本,但如果主数据卷被泄露(compromised),他们将无法正常工作。您可以启用一个数据克隆,以防止灾难性的数据故障。快照可以采取更加频繁,使DBA能够回滚到某个特定的时间点(这在发生用户错误或计算机中病毒时非常有用)。
远程数据复制
SAN和NAS阵列控制器都提供了外部数据复制。这项功能能够使两个或多个阵列控制器同步数据。供应商提供了实时(real-time)或即时点(point-in-time)数据迁移框架。实时框架复制变化是在它们写入阵列的时候。这种复制是同步或异步执行的。同步数据复制对延迟非常敏感,因此不用于超远距离。
同步复制
当SQL Server把变化写到数据或日志文件时,请记住,用户数据库和日志文件都必须复制,同步复制系统把I/O写到电池支持的数据缓存。阵列然后把I/O发送到它的复制伙伴,伙伴把I/O写到自己的缓存,然后发送一个成功确认给源阵列。这时候,基于专有缓存算法,存储阵列把数据动缓存写到磁盘,并且会发送一个成功确认给SQL Server。如果要处理过多的复制数据,或距离太远,数据库就会非常慢。
异步复制
不用等待单个改变提交到两个阵列,异步复制会发送一连串改变在阵列之间。当I/O成功地写入缓存,源阵列会把一个成功确认发送到SQL Server。这种方式写改变不会减缓SQL Server处理。主阵列把改变发送到群组中的远程阵列,远程阵列收到一组改变,确认成功地收到后,把改变写到物理媒体。每个提供异步远程复制的供应商都有一个专属方法来确保成功传送,以及从阵列之间的通讯问题中恢复。从BCDR的期望来看,实施异步复制的缺点是潜在的一些数据丢失。因为写I/O是在源阵列中即刻确认的,一些数据总在阵列中传输,多数计划外的故障转移事件会导致传输数据丢失。由于SQL Server设计,数据丢失并不意味着远程数据库是损坏的。一些存储厂商把即时点技术和远程复制合并在一起。这些功能能够让管理员对用户数据库采取克隆或快照(若需要,可以使用VDI创建一个应用程序一致性的数据副本),并把数据发送到远程阵列。正如异步复制,即时点远程复制对服务器有低影响的优势。远程发送快照使你能够专门控制潜在数据丢失。如果你设置快照间隔为5分钟,你有理由确定万一发生了计划外的故障,你丢失的数据变化不会超过5分钟。确定精确的预期数据丢失的量,在业务商谈BCDR参数时有巨大优势。
Windows故障转移群集
很多SQL Server安装利用Windows Failover Clustering来搭建高可用SQL Server群集。这些系统创建一个虚拟的SQL Server,驻留在一个主动服务器和至少一个被动服务器。SQL Server 2008和2008 R2故障转移群集仅支持共享存储故障转移群集。SAN存储阵列允许所有的SQL Server群集访问同一个物理存储,以及把该存储在节点间转移。SQL Server故障转移群集是基于“shared nothing”的概念,SQL Server实例可以仅存在于一个主动服务器上。SQL Server把一个活动锁放在日志和数据文件上,以防止其他服务器或程序访问文件,防止SQL Server无法察觉的数据改变。除文件锁之外,故障转移群集还会积极地阻止其他系统通过SCSI保留命令使用存储卷。故障转移群集能够设置自动转移,即发生故障时将实例转移到备用服务器。SQL Server故障转移群集还支持使用geo-clustering。geo-cluster使用存储复制来确保远程数据与源数据同步。存储厂商提供专有群集资源DLL,它利用cluster-to-storage-array通讯。使用资源DLL,可以实现站点间快速的故障转移,而很少或不需要管理员介入。传统的故障转移系统需要多个团队的交互。使用geo-cluster可以大大简化故障转移处理,但不幸的是,SQL Server 2008和2008 R2仅支持在共享相同IP子网的两台服务器上实施geo-clustering。这种网络技术被称为stretch virtual local area network(stretch VLAN),它常常需要网络工程师实施复杂的网络技术。SQL Server 2012通过AlwaysOn Failover Cluster Instances解决了这个问题。新功能使每台SQL Server都能使用一个IP地址,这个IP地址如同其他主机,不会绑定到同一个IP子网中。多子网SQL Server故障转移群集网络名称启用属性RegisterAllProvidersIP,这提供了SQL Server配置使用的所有IP地址。
SQL Server AlwaysOn Availability Groups
AlwaysOn Availability Groups的配置和搭建超出本章节的范围,从存储角度看,Availability Groups为复制数据提供了一个新的、基于服务器的方法,复制数据是以应用程序为中心的,而不是以平台为中心。如前面讨论,存储系统能够使用即时点数据副本来实施数据备份和性能隔离。决定故障转移是基于应用程序还是基于硬件,是一个架构选择。
SQL Server早期版本使用日志传送,之后是镜像,来保持备用SQL Server更新信息。至于日志传送和存储复制,远程数据库都必须在数据同步前离线。Availability Groups能够使用接近实时的可读辅助数据库服务器。只读数据副本有利于报表卸载,乃至备份。另外,Availability Groups支持同步或异步数据复制,以及多个辅助服务器。你可以配置一个辅助服务器用于本地的报表系统,第二台服务器可以远程驻留,这样就提供了远程BCDR。每个远程辅助服务器需要和主数据库同样多的存储容量(通常还有性能)。另外,网络要能处理本地及远程复制数据所产生的网络流量。最后,所有的服务器都必须有足够的可用性能来处理复制。如果你的服务器受限于处理器、存储或内存,使用基于存储的复制尝尝是有利的。AlwaysOn Availability Groups作为一个强有力的新工具,现在增强了SQL Server工具包。
风险缓解计划
所有的复制及备份技术都是为了减缓风险。要恰当地定义用于BCDR策略的程序和技术,你需要判定你需要系统多久联机(online)以及处理过程中你的业务愿意丢失多少数据。故障系统恢复到联机所花费的计划时间被称为恢复时间目标(RTO)。执行故障转移时所估算的可能丢失的原始数据量被称为恢复点目标(RPO)。设计一个恢复计划时,谈清楚RTO和RPO目标是重要的。要确保恢复目标满足业务需求。要知道,提供一个快速的故障转移时间,同时很少或没有数据丢失的系统尝尝非常昂贵。一个好的经验法则是,停机时间越短,且预期的数据丢失越低,系统花费越多。




运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-22262-1-1.html 上篇帖子: 存储系统----存储技术(2) 下篇帖子: 存储系统----测量性能(1) 技术
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表