NetApp 双活架构与EMC双活架构比较
- 格式:docx
- 大小:117.27 KB
- 文档页数:3
NetAp统一存储双活方案NetApp统一存储双活方案1、双活存储架构建设目标系统灾难是指IT系统发生重要业务数据丢失或者使业务系统停顿过长时间(不可忍受)的事故。
可能引发系统灾难的因素包括:•系统软、硬件故障,如:软、硬件缺陷、数据库或其他关键应用发生问题、病毒、通信障碍等;•机房环境突发性事故,如:电源中断、建筑物倒塌、机房内火灾等;•人为因素,如:因管理不完善或工作人员操作不当、人为蓄意破坏、暴力事件等;•自然灾害:如火灾、地震、洪水等突发而且极具破坏性的事故。
其特点是突发性、高破坏强度、大范围。
在灾难性事故的影响下,计算中心机房的硬件设备会部分或完全损坏,造成业务的停顿。
请参见下图:当前用户IT系统缺乏有效的灾难防范手段,难以在灾难发生后,不间断或者迅速地恢复运行。
灾难恢复就是在IT系统发生系统灾难后,为降低灾难发生后造成的损失,重新组织系统运行,从而保证业务连续性。
其目标包括:●保护数据的完整性、一致性,使业务数据损失最少;●快速恢复业务系统运行,保持业务的连续性。
灾难恢复的目标一般采用RPO和RTO两个指标衡量。
技术指标RPO、RTO:RPO (Recovery Point Objective): 以数据为出发点,主要指的是业务系统所能容忍的数据丢失量。
即在发生灾难,容灾系统接替原生产系统运行时,容灾系统与原生产中心不一致的数据量。
RPO是反映恢复数据完整性的指标,在半同步数据复制方式下,RPO等于数据传输时延的时间;在异步数据复制方式下,RPO基本为异步传输数据排队的时间。
在实际应用中,同步模式下,RPO一般为0,而在非同步模式下,考虑到数据传输因素,业务数据库与容灾备份数据库的一致性是不相同的,RPO表示业务数据与容灾备份数据的时间差。
换句话说,发生灾难后,启动容灾系统完成数据恢复,RPO就是新恢复业务系统的数据损失量。
RTO (Recovery Time Objective):即应用的恢复时间目标。
一、总体架构图为了进一步保障核心应用的高可用性,提高生产的安全级别,计划对目前的存储系统进行虚拟化整合,并搭建双活存储系统,保证关键业务所使用的存储系统即使有一台存储系统出现故障,也不会出现业务停顿,达到更高的生产安全保障。
经讨论分析,结合系统目前的现状,我们建议存储整合的架构设计,如下图所示:如上图所示,在生产中心的SAN网络中配置一套存储虚拟化设备——EMC VPLEX,将目前的存储系统接入VPLEX,所有应用系统只需要访问VPLEX上的卷即可,接入VPLEX上的存储可以做到镜像关系(即双活)或级联关系。
建议对重要应用的数据存储在镜像的两台存储系统上。
整个方案的组成部分为:A.中心机房-光纤交换网络:由两台速度为8Gbps的光纤交换机组成光纤交换网络,为所有系统提供基于光纤协议的访问;两台光纤交换机之间互为冗余,为系统的网络提供最大的可靠性保护。
用户可自行建设冗余SAN网络。
B.中心机房-主存储系统:配置一台EMC存储系统,与当前的EMC存储通过虚拟化存储进行本地数据保护,对外提供统一的访问接口;重要应用系统的数据都保存在这两台的存储系统上;➢EMC存储系统可同时提供光纤SAN、IP SAN、NAS等多种存储模式,支持光纤盘、闪存盘、SATA盘、SAS盘、NL-SAS盘等多种磁盘混插,大大增强存储系统的可扩展性;➢支持将闪存盘作为可读写的二级缓存来使用,同时支持自动的存储分层(FAST),提高存储系统的整体性能;➢支持LUN的条带化或级联式扩展,以将数据分散到更多的磁盘上;C.中心机房-存储虚拟化:以EMC VPLEX Local作为存储虚拟化;应用系统只需要访问虚拟化存储,而不需要直接管理后端的具体的存储系统;通过存储虚拟化,可以达到两台存储之间双活,可以支持异构的存储系统,对数据进行跨存储的本地及远程保护,统一管理接口和访问接口;D.中心机房-利旧存储:除了用来做“存储双活”的存储系统外,如果还有其他的SAN存储系统,EMC建议,通过VPLEX虚拟化功能,将这些旧存储系统挂接到VPLEX虚拟化存储中,加以利用;这些存储资源将作为存储资源池共享,按需使用;(注:挂接到VPLEX后端的其他存储品牌需要在VPLEX的兼容列表内。
“两地三中⼼”和“双活”简介--容灾技术⽅案当前市场上常见的容灾模式可分为同城容灾、异地容灾、双活数据中⼼、两地三中⼼⼏种。
1、同城容灾同城容灾是在同城或相近区域内( ≤ 200K M )建⽴两个数据中⼼ : ⼀个为数据中⼼,负责⽇常⽣产运⾏ ; 另⼀个为灾难备份中⼼,负责在灾难发⽣后的应⽤系统运⾏。
同城灾难备份的数据中⼼与灾难备份中⼼的距离⽐较近,通信线路质量较好,⽐较容易实现数据的同步复制,保证⾼度的数据完整性和数据零丢失。
同城灾难备份⼀般⽤于防范⽕灾、建筑物破坏、供电故障、计算机系统及⼈为破坏引起的灾难。
2、异地容灾异地容灾主备中⼼之间的距离较远(> 200KM ) ,因此⼀般采⽤异步镜像,会有少量的数据丢失。
异地灾难备份不仅可以防范⽕灾、建筑物破坏等可能遇到的风险隐患,还能够防范战争、地震、⽔灾等风险。
由于同城灾难备份和异地灾难备份各有所长,为达到最理想的防灾效果,数据中⼼应考虑采⽤同城和异地各建⽴⼀个灾难备份中⼼的⽅式解决。
本地容灾是指在本地机房建⽴容灾系统,⽇常情况下可同时分担业务及管理系统的运⾏,并可切换运⾏;灾难情况下可在基本不丢失数据的情况下进⾏灾备应急切换,保持业务连续运⾏。
与异地灾备模式相⽐较,本地双中⼼具有投资成本低、建设速度快、运维管理相对简单、可靠性更⾼等优点;异地灾备中⼼是指在异地建⽴⼀个备份的灾备中⼼,⽤于双中⼼的数据备份,当双中⼼出现⾃然灾害等原因⽽发⽣故障时,异地灾备中⼼可以⽤备份数据进⾏业务的恢复。
本地机房的容灾主要是⽤于防范⽣产服务器发⽣的故障,异地灾备中⼼⽤于防范⼤规模区域性灾难。
本地机房的容灾由于其与⽣产中⼼处于同⼀个机房,可通过局域⽹进⾏连接,因此数据复制和应⽤切换⽐较容易实现,可实现⽣产与灾备服务器之间数据的实时复制和应⽤的快速切换。
异地灾备中⼼由于其与⽣产中⼼不在同⼀机房,灾备端与⽣产端连接的⽹络线路带宽和质量存在⼀定的限制,应⽤系统的切换也需要⼀定的时间,因此异地灾备中⼼可以实现在业务限定的时间内进⾏恢复和可容忍丢失范围内的数据恢复。
双活数据中心方案(华为)目录1 灾备建设的挑战与趋势....................................... 错误!未定义书签。
2 华为双活数据中心解决方案介绍 (2)2.1双活数据中心架构 (3)2.2 双活数据中心部署 (4)2.3 客户价值 (5)3双活数据中心关键技术 (6)3.1存储层双活 (6)3.1.1 AA双活架构 (6)3.1.2 高可靠技术 (8)3.1.3高性能技术 (15)3.1.4 高可扩展性 (17)3.2 计算层双活 (19)3.3应用层双活 (20)3.3.1 B/S应用双活 (20)3.3.2 C/S应用双活 (21)3.3.3数据库双活 (22)3.4.网络架构 (26)3.4.1 网络架构 (26)3.4.2跨数据中心网络 (26)3.4.3业务访问网络架构 (27)3.4.4二层互联 (28)3.4.5负载均衡技术 (29)3.5传输层技术 (31)3.6安全层技术 (31)4可视化容灾管理 (34)4.1总体部署 (35)4.2应用支持矩阵 (35)4.3 SAN双活场景 (36)4.3.1 SAN双活场景 (36)4.3.2 SAN双活+快照场景 (37)5. 故障场景 (39)5.1 GSLB 故障 (39)5.2 SLB故障 (40)5.3Web服务器故障 (41)5.4应用服务器故障 (42)5.5 Oracle RAC 故障 (42)5.6 IBM DB2 故障 (43)5.7 阵列单控故障 (43)5.8广域网链路故障 (44)5.9站点间链路故障 (44)5.10站点故障 (45)1 灾备建设的挑战与趋势随着信息化技术的飞速发展,信息系统在各种行业的关键业务中扮演着越来越重要的角色。
在通讯、金融、医疗、电子商务、物流、政府等领域,信息系统业务中断会导致巨大经济损失、影响品牌形象并可能导致重要数据丢失。
因此,保证业务连续性是信息系统建设的关键。
nettapp双活方案劣势NetApp的ONTAP很早就支持双活,叫MetroCluster。
但是,大家也支持MetroCluster有很多限制:1、站点之间必须采用FC链路,不支持IP2、需要FC-SAS转换设备,组网复杂3、本地的控制器和磁盘框不能用SAS链接,必须通过FC-SAS 转换器,FS-SAS容易成为性能瓶颈NetApp也意思到自己的问题,现在推出了新的MetroClusterIP 双活解决方案。
NetApp的MetroClusterIP和业界很多主流双活方案的连接方式一样了:1、可以通过IP进行站点的互联,适用范围更广2、本地磁盘框不需要和远端的控制器相连,因此,本地连接可以恢复为SAS直连,效率提高。
不过,目前这个组网需要满足下列条件:1、ONTAP9.3以上版本2、只支持最高端的AFF700和FAS90003、必须是4节点的配置下4、IP交换机采用数据中心交换机(如Nexus3132Q),建议40G 端口,最少10G端口。
5、站点间跑iSCSI协议,但是采用RDMA技术(iWARP)6、老的MetroClusterFC不能升级到MetroClusterIP7、站点的距离不能超过100km大家可以看到,虽然NetApp的双活方案越来越完善,但是还有改善空间:1、还不支持对称双活2、不支持通过FC但是磁盘框只做本地SAS链接的方式3、IP双活支持的型号太少不过,相信其未来的版本应该都会支持这些特性。
因为存储双活已经成了一个普遍特性了,大家都在上面有较大的投入,比如华为这块的投入就比较大,不仅SAN支持双活,NAS也支持双活,甚至分布式存储也支持双活,而且SAN都是对称式双活,FC/IP链路都支持,应该是主流厂商里面双活支持得最全面的了。
双活(Active-Active)架构是一种高可用性的系统设计模式,其基本原理和设计思路如下:基本原理:1. 冗余并行运行:双活架构的核心是通过在两个或多个地理位置分散的站点部署相同的应用系统和服务,并且这些系统都处于活动状态,能够同时处理用户请求和业务操作。
2. 数据实时同步:在数据库层面,采用数据库集群、分布式数据库或者数据库复制等技术实现跨站点的数据实时同步,确保任一时刻两个站点的数据一致。
3. 负载均衡与故障切换:通过负载均衡器对用户请求进行智能分发,使得不同站点可以承担业务流量。
当某个站点发生故障时,负载均衡器能够自动将流量导向其他正常运行的站点,实现故障切换。
4. 仲裁机制:针对可能出现的数据冲突等问题,通常会有一个仲裁机制来决定在特定情况下哪个站点有写入权限,以保证数据的一致性和完整性。
设计思路:1. 地理分布:根据容灾和业务连续性需求,选择合适的地理位置部署双活节点,确保在单一地点出现灾难时,另一个地点仍能继续提供服务。
2. 资源隔离与分配:对各个节点的计算、存储和网络资源进行合理分配,保证每个节点都有足够的能力独立承载全部业务。
3. 网络优化:采用高速低延迟的网络连接,如专用线路、SD-WAN、广域网优化技术等,确保数据在各节点间快速、准确地传输。
4. 监控与管理:建立完善的监控体系,实时监测各节点的运行状态、资源使用情况及网络状况,并在出现异常时及时告警,自动触发相应的故障恢复策略。
5. 业务逻辑处理:考虑到双活环境下的数据一致性问题,需要在业务层面对并发控制、事务处理等方面进行特殊设计,确保在多点写入的情况下也能保持数据的一致性。
通过上述原理和设计思路,双活架构能够在保证业务连续性的同时,提高系统的整体可用性与资源利用率。
大总结:双活数据中心建设系列之---基于SVC的三种主流双活数据中心架构深入探讨作为业务系统的最后一道防线,IT数据灾备中心必须在极端状况下确保重要业务系统稳定运行。
灾备方案的出现给业务系统提供了完备的数据级保护。
然而,传统的灾备方案中存在着资源利用率低、可用性差、出现故障时停机时间长、数据恢复慢、风险高等问题。
数据是否安全、业务是否连续运行无中断成为用户衡量灾备方案的关键。
作为灾备方案中的高级别的双活数据中心解决方案,成为应对传统灾备难题的一把利剑。
传统的数据中心环境下,灾备生产中心长年处于休眠状态,并不参与前端应用的数据读写工作。
如果数据中心环境良好,没有突发性灾难的发生,灾备中心资源就一直处于闲置状态,造成用户投资浪费。
而在双活解决方案中,分布于不同数据中心的存储系统均处于工作状态。
两套存储系统承载相同的前端业务,且互为热备,同时承担生产和灾备服务。
这样不仅解决了资源长期闲置浪费的大问题,还能使数据中心的服务能力得到双倍提升。
在这样的背景下,传统的数据灾备中心越来越不能满足客户的要求,用户希望在成本可控的同时,建立高可靠性、高可用性、高可切换性的双活数据中心。
IBM SVC在双活数据中心建设的虚拟化存储解决方案中,有三种主流的双活基础架构可以满足我们搭建新形势下高要求的双活数据中心,值得我们深入探讨,分别为:SVC Stretch Cluster、SVCHyperSwap和SVC Local VDM+SVC PPRC。
这三种架构方案针对不同的企业需求均能发挥最大的效用,本期专题讨论会就是要把这三种架构方案聊透彻,讲明白,让企业在选择时有所依据,有的放矢,并充分挖掘自身企业的思维方式,选择最适合自身企业发展的双数据中心虚拟化存储解决方案。
在本期讨论会上,大家针对“基于SVC的三种主流双活数据中心架构”的话题踊跃发言,提出了许多宝贵的观点和意见,现在我将分享、各类议题观点和各类问题及回答进行梳理总结,如有疏漏,还请不吝赐教。
双活数据中心概念及优缺点介绍 01、热备 热备的情况下,只有主数据中心承担用户的业务,此时备数据中心对主数据中心进行实时的备份,当主数据中心挂掉以后,备数据中心可以自动接管主数据中心的业务,用户的业务不会中断,所以也感觉不到数据中心的切换。 02、冷备 冷备的情况下,也是只有主数据中心承担业务,但是备用数据中心不会对主数据中心进行实时备份,这时可能是周期性的进行备份或者干脆不进行备份,如果主数据中心挂掉了,用户的业务就会中断。 03、双活 双活是觉得备用数据中心只做备份太浪费了,所以让主备两个数据中心都同时承担用户的业务,此时,主备两个数据中心互为备份,并且进行实时备份。一般来说,主数据中心的负载可能会多一些,比如分担60~70%的业务,备数据中心只分担40%~30%的业务。
A—P AP 双活通过将业务分类,部分业务以数据中心 A 为主,数据中心 B 为热备,而部分业务则以数据中心 B 为主,数据中心 B 为热备,以达到近似双活的效果。 A—A AA 双活则是真正的双活,同一个双活 LUN 的所有 I/O 路径均可同时访问,业务负载均衡,故障时可无缝切换。 04、什么是双活数据中心 ? 首先我们要知道双活就是Active-Active,故名思义就是两边都是活动在线提供服务的,是相对于传统的主备模式Active-Standby模式的。一个真正的双活方案是应该涵盖基础设施、中间件、应用程序各个层次的。 双数据中心同时对外提供业务生产服务的双活模式,两个数据中心是对等的、不分主从、并可同时部署业务,可极大的提高资源的利用率和系统的工作效率、性能,让客户从容灾系统中获得最大的价值。 a.两个生产中心部署相同的业务系统,结合网络层、主机层或应用的负载均衡技术,实现业务系统在两个数据中心并行工作和负载分担。 b.两个生产中心部署不同的业务系统,互相实时灾备接管。 数据中心双活又分为:同城双活、异地双活。 传统主备模式的缺点
NetApp 双活架构与EMC双活架构比较:
1,拓扑图架构比较
从拓扑图可以看到,EMC是采用vplex存储网关的方式实现,主机到存储的数据流需要经过vplex网关,然后再写入到后端的存储,需要通过两个SAN网络,数据的通路比较长。
NetApp则摈弃了存储网关模式,直接将双活的metrocluster软件集成到存储的控制器内,直接通过存储控制器实现双活功能,数据的通路比较短。
2,两种模式的性能比较:我们分别比较读写模式下,两种架构的性能比较:
a.写数据:
VPLEX Local对于数据写入采用“直写模式”,也就是主机写入数据的流程为:
主机发起数据写入→数据写入VPLEX→VPLEX写入2个后端存储→2个后端存储均
写入完成→报告主机写入完成。
可见在这个过程中,VPLEX的缓存无法发挥任何作用,反而因为数据多经过了一个
通路,导致写入速度变慢。
总的主机写入时间=VPLEX写入时间+后端存储写入时间。
而相比NetApp MetroCluster,写入数据时并无类似的网关设备,所以写入时间=存
储写入时间。
b.读数据:
VPLEX的引擎内存分为本地内存和全局内存,全局内存在local模式无效,
数据LUN如果在引擎上找不到缓存,需要从存储缓存中寻找;如果存储缓存也无
法找到数据,则从存储硬盘中读数据。
NetApp的模式,读数据直接从存储缓存中寻找,如果存储缓存无法找到数据,可
以在两个存储节点中同步读出数据(类似LUN的RAID 1)而提升读性能。
c.总结
以上可见,应用的写入IO速度是最影响应用响应速度的环节,而在写数据环节,
VPLEX的缓存非但不能发挥作用(因为采用直写技术),反而因为数据多流经一个
网关设备而造成额外的延迟。
从本质上讲,VPLEX仅仅是数据通道上的一个网关,数据最终还是需要从存储上进
行读写,网关性能标称的再高也不可能提升后端存储的速度,仅仅只能做到不影响
后端的存储性能而已,但是由于多一个数据路径环节,所以对整体速度有额外的延
迟。
3,双活功能比较:EMC VPLEX网关型架构与NetApp Metrocluster的架构比较
a.增加的网关设备导致更多连线,复杂的拓扑,引入的新的故障点。
相比netapp
metrocluster而言架构比较简洁。
b.VPLEX网关对外仅能提供FC SAN功能,无法支持iSCSI和NAS,对未来统一存储
整合不利,netapp metrocluster可支持各种统一存储协议。
c.VPLEX网关采用按容量许可的方式,后续扩容还需收取vplex扩容费,netapp
metrocluster后续无需收容量许可
d.VPLEX网关因为采用了最简单的FC仿真模式(对后端存储而言,它模拟自己为
一台服务器),这样实际上屏蔽了后端存储的特色软件功能(存储池、去重、
存储分层等功能均没有了)
e.VPLEX网关需要一个独立的管理工具
4,后端存储自身性能比较
EMC的VNX5600,标称缓存为48GB,但是实际可用内存仅为10多G,写缓存则更少,仅为2G多(可在EMC unisphere管理界面内看到,其余均被系统所开销),
而netapp FAS8020存储设备拥有专用的48GB读缓存、8GB的专用写缓存(系统开销均已除外),读写性能均高于VNX5600存储设备。