深信服:解决网络瓶颈 提高灾备效率

网络
在经历了数据完全丢失而导致系统停运的企业中,有2/5再也没能恢复运营,余下的企业也有1/3在两年内宣告破产。为保障数据的安全性,容灾建设必不可少,各种异地灾备中心、同城灾备中心,都在如火如荼的建设中。

随着企业的发展,ERP、CRM、电子商务等应用的部署,在企业效率提高的同时,大量的数据也会伴随着产生,并具有越来越重要的地位。据Gartner Group发布了一份报告,揭示了数据对企业运营的重要性:在经历了数据完全丢失而导致系统停运的企业中,有2/5再也没能恢复运营,余下的企业也有1/3在两年内宣告破产。也就是说,六成企业因数据完全丢失而倒闭。

为保障数据的安全性,容灾建设必不可少,各种异地灾备中心、同城灾备中心,都在如火如荼的建设中。

灾备系统的影响因素

在灾备系统的建设中,主要的影响因素有一下几点:

存储空间:

急速增长的数据量给灾备系统带来的最直观的问题是不足,需要购买更多的存储介质(磁带或磁盘)。

配套设施:

除了购买介质本身的支出外,设备部署空间、降温、电能消耗等等附带需求也随之迅速增长。

处理性能:

与存储介质不同,系统的处理能力(如CPU、I/O总线等)一般较难扩展,通常只能通过硬件整体升级完成,如果不能通过技术手段有效平抑数据量增长对系统处理能力的压力,系统可靠性将面临频繁硬件升级的严峻挑战。

网络传输:

灾备系统通常都需要异地部署。数据量的增加要求远程数据传输具有更高的带宽;由于传输带宽的限制,传输时间的延长可能会降低系统运行效率,甚至无法及时完成异地数据传输,造成灾备系统不能发挥功效。

灾备系统木桶模型

实际的容灾系统设计过程中,我们重点关注的是RTO和RPO两个指标。

RTO全称为:Recovery Time Objective,即:恢复时间目标。RTO表示了从灾难发生直到业务流程再次运行(即被恢复)的时间。RTO有两个组成部分,明确灾难发生后指示恢复流程开始的决策时间(Decision Time)和进行灾难恢复流程的实施时间(Deployment Time)。一般来说,恢复时间(RTO)越短,那么灾难恢复方案的成本就越高,但是由于灾难造成的业务损失就越小;反之,恢复时间(RTO)越长,灾难恢复方案的成本较低,但是由于灾难造成的业务损失就较大;

RPO全称为:Recovery Point Objective,即:恢复点目标。 RPO是灾难发生后业务能够容忍的数据丢失量,或者说灾难发生造成的数据丢失量。一般来说, RPO越高(即,丢失的数据越少),容灾的成本越高,但是由于灾难造成的业务损失就越小;反之,RPO越低(即,丢失的数据较多),容灾的成本越低,但灾难造成的业务损失也越大。

灾备系统的各种因素都会影响到RTO和RPO指标的实现,但是,最终制约RTO和RPO目标实现的将会是各种因素中最弱的因素,即:灾备系统的性能可以用木桶模型来解释。

从存储空间、配套设施、处理性能、网络传输四个方面来分析,可以得到如下结果:

虽然企业对存储空间的需求越来越大,但是随着IOBS、RAIDS技术的发展,磁盘阵列的存储容量和数据安全性都得到了很明显的提高,基本可以满足大多数企业的需求;

配套设置会影响灾备系统的运营成本,但是并不直接影响RTO和RPO指标的实现;

目前,高性能的CPU,处理能力很强,处理性能也比较容易满足。

但是网络传输由于带宽、价格、丢包、时延等问题,往往成为灾备系统中的短板,并直接对RTO和RPO目标的实现产生重要影响。接下来我们着重分析网络传输这个灾备系统存在的瓶颈问题。

[[87159]]

广域网传输问题浅析

由于灾备系统通常需要异地部署,在不同的数据中心,需要采用广域网进行连接。通常广域网的连接,主要有专线接入和VPN两种方式,但是两种方式,在传输过程中,都存在一些需要优化的问题:

1.数据带宽有限,但是传输数据量较大

由于专线的租赁价格比较贵,往往从主数据中心的到灾备中心的专线只有仅仅10Mbps,但是每日需传输的灾备数据量大,经常以百G来计,数据无法在指定时间内完成传输。并且,随着业务的不断增多,数据滞后也越来越多,数据的丢失风险也不断攀升,RPO难保证……

在大多数情况,有限的带宽和较大的传输数据量的矛盾在灾备系统建设中,经常容易出现。

2.公网环境复杂,丢包延时严重

公网环境比较复杂,不可控因素更多,尤其是异地部署的灾备系统,广域网传输,中间节点较多,丢包和延时情况难免,同时由于我国过存在多个运营商,在跨运营商传输的情况下,丢包和延时情况更为严重。

网络环境对传输影响是非常巨大的,一条2Mb/s带宽的ADSL线路,在不同延时情况下的数据吞吐情况如下图所示:

深信服:解决网络瓶颈 提高灾备效率

可见,当延时达到200ms左右,实际的吞吐量只能达到带宽所允许的最高数据吞吐量的10%左右。另外的100Mb/s带宽的线路上面进行相同的测试,得到的结果显示在网络延时大于200ms以后,100Mb/s带宽线路的数据吞吐量和2Mb/s的线路几乎下降到同样的水平,所以说在网络延时较大的时候,网络带宽不论大小,传输能力都会大大降低。

3.传输机制需要优化

广域网中使用最广泛的传输协议就是TCP(Transfer Control Protocol)协议,TCP协议传输数据的时候,一端到另一端所正在传输的数据量受数据报窗口的大小限制,当该窗口满了以后,发送方就无法发送更多的数据,直到接受方确认已经接收了窗口中的部分数据。在部分对数据传输要求非常高的企业,主数据中心和灾备中心之间通过1Gbps的专线互联,延时只有25ms,网络带宽足质量好,但是灾备系统在运作时,速度极限只能跑到尴尬的180Mbps,徒有大带宽却白白浪费,RTO不达标……

所以,广域网中最广泛使用的TCP协议也需要优化。

深信服灾备优化方案

作为国内规模最大、创新能力最强的应用层网络设备供应商,深信服经过十几年的技术积累和对先进网络的深刻研究和认知之后,并结合客户灾备系统遇到的主要问题,率先在国内提出了灾备优化方案,针对广域网传输存在的问题,深信服提出了相对应的解决方案。

高效的流缓存压缩和数据消减技术解决数据量大与窄带宽之间的矛盾。

深信服WOC容灾网络优化方案采高细粒度冗余数据消除技术解决,无损数据削减的方式,减少网络中需要传输容灾数据总量,在有限的带宽内实现高效的传输,从而提升灾备速率。数据削减采用的技术为基于码流特征的数据优化技术,以及无损数据流压缩技术,实现bit级重复数据删除,灾备需传输流量可达到60%-90%的削减。

某检验检疫局,主数据中心在省会城市A,并在地市局B建立灾备中心,A到B之间只有4Mbps的专线互联,每日灾备数据需要从晚上完成到A到B的传输。但由于数据量大,往往在规定的备份时间窗口之内无法完成传输,需要到第二天中午才把灾备数据传输完。而灾备数据和业务链路为共用专线,导致第二天上网B局人员访问业务系统速度非常慢。通过深信服WOC容灾网络优化方案对灾备传输进行优化,原有需要传输整晚甚至到第二天中午才传完的数据,部署后两三个小时既已完成灾备数据的传输,加快了灾备效率,降低数据灾难风险。

优化网络的质量,解决丢包延时等问题对网络传输的影响。

在丢包存在、延时较高的情况下,网络实际吞吐性能将大打折扣;同时,灾备需传输的数据量大,也是耗时长、RTO不达标的一个原因。针对这个问题,深信服WOC容灾网络优化提出链路质量优化+无损数据削减的方案解决。针对公网线路,尤其跨运营商线路中的丢包延时问题,通过链路质量优化功能,采用改进性的HTP算法优化TCP协议,在丢包延时环境下大大提升网络的吞吐性能;并通过基于码流特征的数据优化技术,以及无损数据流压缩技术,大大消除灾备需传输的数据量,提升带宽吞吐、削减传输数据量,从而实现灾备网络的加速。

某媒体集团,主数据中心在北京,灾备中心在广州,出口分别电信和联通的公网线路,主要传输的数据类型为音视频数据。由于受到跨运营商的影响,原有NetApp灾备系统受到网络影响比较严重,传输速度平均为6Mbps,峰值只有10Mbps。通过深信服WOC容灾网络优化方案的部署,解决网络质量问题,传输速度从6Mbps一下提高到了50Mbps,网络性能得到显著的提高。

优化TCP传输机制,提高TCP连接的吞吐量,有效利用带宽。

在一对灾备系统之间,往往是通过单TCP连接或是仅几条TCP连接相连,而TCP本身因为受到传输窗口等协议本身的限制,速度存在上限值。传统的TCP协议传输窗口为64KB,在网络延时为20ms时,单条TCP连接吞吐仅为25Mbps。虽然许多灾备系统基于Unix开发,对TCP协议进行了一部分优化,但相对于1Gbps这样的大带宽,吞吐还是出于160Mbps-200Mbps这样的低位,无法完全利用带宽保障RTO。

针对TCP本身的低效性,深信服WOC灾备优化方案通过TCP协议优化+无损冗余数据削减功能,可大大提升整个网络的吞吐。在某金融机构实际测试中,对于一对灾备设备之间的广域网传输,性能从160Mbps大幅提升至600Mbps,并可扩展提升至2.5Gbps,满足大带宽灾备需求。

责任编辑:蓝雨泪 来源: 51CTO.com
相关推荐

2012-04-12 18:08:21

深信服容灾网络优化方案

2012-04-12 17:42:42

深信服容灾网络

2012-08-06 11:55:10

灾备系统深信服易宝支付

2012-07-04 13:43:07

广域网优化深信服

2011-05-05 13:13:04

深信服Oracle广域网加速

2015-10-08 11:43:10

华为云灾备双活数据

2011-05-05 13:21:39

深信服广域网加速SAP

2011-10-21 15:59:51

深信服负载均衡

2012-08-08 15:34:18

负载均衡深信服

2011-05-13 14:59:05

深信服

2011-08-24 11:21:00

深信服APM

2012-04-27 16:06:30

深信服网络应用行为

2009-08-24 16:15:20

虚拟化灾备

2011-01-04 15:30:26

博科解决方案

2012-07-24 13:36:56

负载均衡WebSphere深信服

2011-12-31 16:36:07

深信服负载均衡

2012-08-03 11:21:50

应用交付深信服

2014-12-09 15:17:59

2023-06-21 18:59:01

点赞
收藏

51CTO技术栈公众号