网络安全和数据安全:资讯、技术、法规、趋势。

忘记密码
“游侠安全网”创建了网络安全从业者QQ大群(群号:389710688) ,欢迎各位同仁加入!有其它问题,请联系站长“网路游侠”,QQ:55984512


论数据库防火墙的自我修养之二丨高性能和可扩缩

2016-09-30 14:51 推荐: 浏览: 70 字号:

摘要: 上周,我们开始讨论数据库防火墙的“自我修养”。作为一个技术人,对于文字的造诣远不及对代码的掌控,笔者不擅长用华丽的辞藻表达数据库防火墙所背负的重任,在大部分人眼中,它只是一个冰冷的盒子,但笔者依然希望依靠有限的语言能力,用技术人的思维把这样一个盒子的自我进阶之...

上周,我们开始讨论数据库防火墙的“自我修养”。作为一个技术人,对于文字的造诣远不及对代码的掌控,笔者不擅长用华丽的辞藻表达数据库防火墙所背负的重任,在大部分人眼中,它只是一个冰冷的盒子,但笔者依然希望依靠有限的语言能力,用技术人的思维把这样一个盒子的自我进阶之路讲给你们听。

实现了高可用性,解决了最基本的能不能串接部署的问题,数据库防火墙的“人生”可以说成功了一小半,下一个人生挑战随之而来:高性能和可扩缩性

在这里,我们还是有必要先介绍一下数据库防火墙和传统网络防火墙的根本性差异,关于深度协议解析和内容分析的复杂性挑战

传统网络防火墙:通常只分析网络层的包头和部分协议特征,不会对通讯包进行深度分析,一般不会对应答包进行分析。

数据库防火墙:需要对数据库通讯协议的请求包和应答包(双向包)进行深度分析:

1、对于请求包,需要解析出包中的SQL语句、参数化语句、参数值、跟踪语句游标。

2、对于应答包,需要解析出返回字段信息、结果集、应答信息等。

3、对于SQL语句,需要进行词法和语法分析(下一篇文章会介绍为什么需要进行语法分析,而不是简单的关键词匹配)。

4、对于参数值,和结果集,需要进行格式转换,并根据策略进行必要的内容过滤。

很明显,二者对通讯包的处理工作量存在很大差异。面对这样的工作强度,我们必须赋予数据库防火墙一颗强大的“心”,对其进行专门的处理逻辑优化和性能优化,能够实现低延迟,保证数据库操作的高吞吐量要求。

核心业务数据库的高吞吐量和扩缩性挑战

在以银行、保险、电信为代表的大型企业,以税务、海关、航空为代表的行业,和以快递业为代表的新兴领域中,相比大规模的WEB应用服务器集群,数据库服务器基本上采用的是少量高端设备支撑大规模的核心应用,无论采用的是RAC集群还是分布式数据库集群,核心业务场景多数都是采用非常高端的小型机来搭建,动辄上百甚至几百个CPU,几百GB的内存,高端磁盘阵列,支撑起强大的数据库事务吞吐量(TPS)。

在这种场景下,对于串联接入的数据库防火墙,面临“小马拉大车”的局面,高吞吐量和可扩缩性挑战有多严峻?下面两个实例充分体现:

首先,介绍一个数据库防火墙的实际经典案例:

20160926-1.jpg
数据库防火墙经典案例 拓扑图

在这个经典案例中,业务系统采用两套RAC节点进行负载均衡(双活)运行,常规稳定运行的情况下,单套RAC节点的性能指标需求如下:

SQL吞吐量(SQL/秒) 50000(5万)
通讯包吞吐量(包/秒) 25万
会话数 8000
通讯包延迟 <50微秒(us)

当有一路网络环境出现故障,原来分散在2套RAC节点上的的压力将集中在一个数据库防火墙上,也就是说,异常情况下,单台数据库防火墙面临的是支撑2倍的吞吐量和会话量压力,同时通讯包的延迟仍然需要保持在50微秒以内。

另外一个想拿来说说的案例,是截止到目前,数据库防火墙面临的最高端性能案例:

20160926-1.jpg
数据库防火墙高端案例 拓扑图

在这个案例中,整体的数据库集群的性能需求是:

整体数据库集群性能指标
SQL吞吐量(SQL/秒) 200000(20万)
并发会话数 100000(10万)
数据库集群数量 4个

折合到单个DBFirewall设备,考虑到设备故障情况,需要支撑的性能指标:

单台DBFirewall性能指标
SQL吞吐量(SQL/秒) >120000(12万)
并发会话数 >60000(6万)
最多支撑数据库集群数量 2个

 

高性能和可扩缩性解决方案

通过介绍这两个经典案例和高端案例,相信不用多说,大家已经能够感受到数据库防火墙必须具备怎样一颗强大的心:低延迟、高吞吐量、高可扩缩性能力

我们确立了这一目标,下一步要做的是制定具体的解决方案,核心技术点有四:

1:极小化每个SQL操作的处理过程

众所周知,SQL语法分析非常耗时,需要专门进行优化:基于词法和语法分析,对业务系统的SQL语句进行抽象化处理,形成软解析结果,并对SQL语句进行序列化、标签化,这样就只需要对语法特征不一样的SQL语句进行解析,而应用系统中SQL语法特征不一样的SQL语句是有限的,这样,就能够极大的减少应用系统SQL语句的语法解析量。

2:无锁化设计,支撑高并发下的线性性能

随着系统并发量的增加,互斥锁会成为主要的性能瓶颈点;无锁化的实现方式是必然,必要时可以通过异步处理来提升吞吐量。

3:低延迟网络处理技术

随着吞吐量的增加,串联的网络处理开销会成为主要的延迟;推荐采用基于Intel DPDK的透明网卡通讯包处理技术,跳过操作系统内核协议栈的处理,实现低延迟。

4:推荐采用经典的多进程机制

在关系型数据库领域中,最经典的设计要数Oracle数据库的多进程架构,每个数据库的连接会话对应一个独立的Oracle进程来处理,这样的机制为数据库带来了两个典型优势:

高可扩缩性:随着硬件性能的提升,可以实现接近线性的处理性能提升。

高安全性:一个会话(进程)的处理异常,不影响其他会话(进程)。

安华金和数据库防火墙,正是基于以上四点核心技术设计开发的一款成熟的数据库防火墙产品,且已经经过了社保,金融,运营商等高端行业的验证。

至此数据库防火墙的自我修养之二——高性能和可扩缩性介绍完毕,欢迎广大用户继续关注数据库防火墙的自我修养系列文章。

名词术语解释

[1]DPDK:全称Data Plane Development Kit,是intel开发的x86芯片上用于高性能网络处理的基础库;是一款数据包转发处理套件;适合网络数据包分析,处理等操作;对于大数据包的转发,多核操作有一定的性能提升。

联系站长租广告位!

中国首席信息安全官
Copy link