-
Notifications
You must be signed in to change notification settings - Fork 0
大规模高性能分布式存储系统(2月28日)
第六课 大规模高性能分布式存储系统设计与实现安全篇
分布式存储系统安全重要性
提高门槛:窃取数据门槛高;即使窃取数据,内容无法破解
互联网诞生,安全一直威胁着互联网网站,Web攻击,信息泄露
历史故事:2011年6月8日新浪微博“中毒”;2011年12月CSDN600万用户数据泄露(天涯、人人网等);2015年携程宕机8个小时…
安全重要性不言而喻
没有绝对安全,道高一尺魔高一丈
提供数据安全等级:窃取数据门槛高;即使窃取数据,内容无法破解
分布式存储系统如何做到高的安全性:鉴权方式、数据加密方式、数据正确性保证
鉴权方式
1、访问控制:对用户的访问权限进行管理,防止对分布式存储系统中数据的窃取和破坏
2、实现方式:
2.1基于IP:IP白名单、IP黑名单
2.2基于用户授权:一般用户、读写用户、超级用户
2.3基于Token:Token统一登录;登录授权后,再继续操作,否则拒之门外
数据加密方式
怎么保证数据安全性?加密?加密的安全通道建立,解决客户端和服务端实现加密会话问题:客户端(Client)—>C 存储器服务端(Server)—>S
名词解释:
1、对称加密算法:加密和解码使用同一密钥的加密方案(AES)
2、非对称加密算法:加密和解密使用一对密钥(由两个满足一定关系的密钥组成的密钥对)中的不同的密钥的加密方法(RSA)
3、公钥:非对称加密算法中公开给大众保密的密钥
4、私钥:非对称加密算法中留给个人保密的密钥
5、会话状态:描述客户端与服务端的一次连接的所有信息集合
加密技术实现方案:客户端和存储服务器之间的所有请求都必须加密,为了提高效率,使用对称加密算法;对称加密密钥使用非对称加密算法经过两次协商确定;安全信道的建立必须满足:任何第三方无法伪造存储服务器;在破解客户端代码的情况下,即使截获其他用户发送的加密请求,也无法解密
为了满足以上两个条件,客户端和服务端都必须要一个随机生成密钥的过程,具体四步握手如下:
客户段发起请求,请求中包含与服务器约定,接下来使用什么加密算法,客户端收到请求后,就知道了客户端允许采用的加密算法是什么,比如RSA,约定公私钥对:(p0,s0);协商公私钥对(p1,s1);协商公私钥对(p2,s2);对称密钥3:key3;0为事先约定,1和3为服务器随机生成,2为客户端随机生成;第二步,在服务端生成公私钥对,将公钥p1用私钥s0加密返回给客户端,第三步;客户端用公钥p1加密公钥p2,发送给服务端;第四部:服务端用公钥p2加密对称密钥key3发送给客户端
1、约定公私钥对0:写死在代码中的公私钥(公私钥池,存储服务器每次选一个,并告诉客户端每次选中的是池中的哪一个),用于客户端验证请求的确来自服务器
2、协商公私钥对1:存储服务器随机生成的协商密钥
3、协商公私钥对2:客户端随机生成的协商密钥
4、对称密钥3:存储服务器随机生成的对称密钥,用于最终的对称加密
C→S (p0,s0);
S→ C (p1,s1);
C→S (p2,s2);
S→ C (key3);数据通讯使用对称密钥3
非对称加密算法:RSA
对称加密算法:AES
数据加密方式:使用HTTPS,HTTPS提供了数据安全的加密方式;单向加密;双向加密
使用场景:重要数据存储、交易、交付、金融…
HTTPS = HTTP + TLS/SSL
层次:http(明文)、TLS/SSL、TCP
风险:信息窃听、信息篡改、信息劫持
优势:信息加密、完整性校验、身份验证
HTTPS:单向加密是不安全的,可能有中间人攻击
HTTPS:双向加密,安全的,客户端证书,配合;接口分级:HTTPS、 HTTPS+短信验证
数据加密:解决数据明文的问题;即使截获,无法破解明文;篡改无法避免;数据正确性需要保证
数字签名:md5sum做签名;其他双方约定规则做签名;存储服务端收到后,先按照规则生成md5sum值,和数据包里的md5sum值比较是否一致,一致说明没有问题,不一致数据被篡改,需要丢弃
数据签名举例:
第一步,设所有发送或者接收到的数据为集合M,将集合M内非空参数值的参数按照参数名ASCII码从小到大排序(字典序),使用URL键值对的格式(即key1=value1&key2=value2)拼接成字符串stringA
重要规则:参数名ASCII码从小到大排序(字典序);如果参数的值为空不参与签名;参数名区分大小写;验证调用返回或微信主动通知签名时,传送的sign参数不参与签名,将生成的签名与该sign值作校验
第二步:在stringA最后拼接上key得到stringSignTemp字符串,并对stringSignTemp进行MD5运算,再将得到的字符串所有字符转换为大写,得到sign值signValue
安全性进一步提升,约定固定字符串,参与加密;只有双方知道
分布式系统安全攻击及其防范手段:XSS攻击(较常见)、SQL注入攻击(较常见)、CSRF攻击、其他攻击
XSS攻击:跨站脚本攻击(Cross Site Script),较古老的攻击手段,新的花样很多,黑客通过篡改网页,注入恶意JS脚本;用户浏览时,控制浏览器进行恶意操作攻击,攻击类型(反射型、持久型)
XSS反射型攻击:黑客诱使用户点击嵌入恶意脚本的链接,进行攻击;新浪微博攻击属于这种:1、黑客发布的微博中含有恶意脚本的URL;用户点击该URL,脚本会自动关注黑客的微博,发布该恶意微博,病毒式传播
XSS持久型攻击:黑客提交含有恶意脚本的请求;保存到被攻击者的数据库中;用户浏览网页,恶意脚本被包含在正常页面中,执行攻击
XSS防攻击手段:XSS攻击在请求中嵌入恶意脚本,因此需要对这些内容过滤和处理
html特殊字符转义; > => > < <= < ….
注入攻击手段:SQL注入:注入恶意SQL命令;Delete * from Table Drop Table 这些比较常见
OS注入:注入OS命令,语言代码;利用程序漏洞攻击;这些比较少见
SQL注入:黑客在HTTP请求中注入恶意的SQL命令,在数据中执行,达到攻击目的
黑客如何知道数据库结构:1、开源软件,Discuz!搭建论坛;2、错误回显,表的信息显示在页面上;3、暴力,暴力注入
SQL防注入手段:过滤转义:应用层过滤转义可能注入的SQL,Drop Table => “Drop Table”字符串
参数绑定:使用预编译手段,参数绑定;当做SQL的参数,而不是命令执行;较常使用的方法:JDBC PrePareStatmt命令
CSRF攻击:跨站点请求伪造(Cross Site Request Forgery),黑客通过跨站请求,以合法用户的身份进行非法操作;非法交易、转账等等;利用跨站请求,在用户不知情情况下,以用户身份伪造请求;利用了浏览器cookie或者服务器Session,盗取用户身份
CSRF防攻击手段:根本是用户请求身份识别!!!
Token验证,服务端生成,正常请求带着,服务端验证,非法请求没有Token字段;文字验证码;短信验证码,用户体验差;Refer校验,Refer域记录请求来源
其他攻击方式:文件上传(可执行命令);错误回显(获取信息攻击);……
通用防护:1、统一拦截请求;2、过滤恶意参数;3、自动转义;4、ModeSecurity(Java,.net);5、开发网站安全漏洞扫描(定期扫描,发现漏洞,及时修补)
Antispam:解决数据过滤与反垃圾:文本匹配方法、分类方法、规则方法、语义方法、黑白名单…
实践案例: 身份验证、数据加密(通道加密,数据本身加密)、数据完整性校验(传输完整性校验,存储完整性校验)
第七讲 大规模高性能分布式存储系统设计与实现之负载均衡篇
分布式存储负载均衡是什么
分布式存储系统负载均衡类型:客户端请求调度的负载均衡;文件块存储的负载均衡
客户端请求调度负载均衡设计:常见的客户端负载均衡算法,我们如何设计
客户端请求调度调度算法测试:环境部署、性能测试
文件块存储负载均衡设计:文件块分配策略、Rebalance策略
文件块存储负载均衡测试:环境部署、性能测试
Load Balance:均匀分摊到多个操作单元上执行,web服务器、接入层、逻辑层、数据存储层…
负载均衡的实现:可以基于硬件或软件,也可以两者相结合;负载均衡技术提供了一种廉价有效的方式扩展了服务器带宽,增加了吞吐量,缩短了请求处理时间,大大提高了网络的可用性,更重要的是这一切对用户来说都是透明的
重要性:实现各个节点间的负载均衡是任何大型分布式集群系统必须解决的问题!!!
常见的客户端负载均衡:一台服务器所要承担的任务分发到两台或多台服务器上;这些服务器都是等价的,都可以独立的对外提供服务而不需要其他服务器的辅助;与单台服务器相比,在相同的时间内可以完成更多的任务量,并且用户请求可以得到更加快速的处理
文件块存储的负载均衡:
1、文件块分配策略:通过设计算法选取最优的若干台(由用户配置)chunk server存放文件块;对于大文件,要尽量将其文件块分散到不同的chunk server上;对于小文件,要尽量将其存放到文件块数量较少的chunk server上
2、Rebalance策略:将负载较重的chunk server上的文件块转移到负载较轻的chunk server上
客户端负载均衡算法:
1、基于轮循算法的DNS(Round-robin Domain Name Server):客户端通过单一的域名访问集群服务器;RR-NDS通过轮循算法将该域名映射为不同的服务器IP地址;实现服务器端的负载均衡
存在问题:由于客户端和服务器之间可能存在多台DNS服务器;很有可能会将客户端请求转发到相同的服务器上,在大规模客户端访问的情况下,很容易就会导致服务器负载的不均衡现象
2、最小连接数算法:是对RR-NDS算法改进,基于RR-DNS的方式把客户端请求定位到不同的服务器;集群中的所有服务器都保存了其他服务器的连接数情况,当客户端建立TCP连接时,服务器会判断是否需要将该连接进行重定向;如果是,则将该连接重定向到当前连接数最少的服务器;与RR-DNS算法相比,可以使得负载均衡更加动态化
存在问题:并没有考虑到服务的真正负载情况;事实上连接数最小的服务并非一定就是负载最小的服务器,这同服务器执行的具体任务情况相关;因此两种算法都只是在一定程度上实现了服务器间的负载均衡;由于DNS协议本身的一些特性(比如缓存和无效机制),也给负载均衡的实现带来了一定的局限性
客户端请求调度负载均衡设计:
基于存储服务器负载的客户端负载均衡算法:
背景:系统在运行时,集群中每一台服务器的负载情况都是动态变化的,在设计时必须要根据服务器的实际负载情况来进行任务的分配;系统可以通过对服务器上的各项负载参数进行分析来进行调度;负载参数的选择:CPU利用率、内存利用率、网络流量及磁盘容量等。实际选取:CPU利用率、内存使用率、网络流量作为监测对象;通过这些参数可以计算出服务器的负载情况,进行合理调度
设计思路:
1、Master server根据chunk server提供的负载信息来对请求进行集中调度的方式来实现Chunk Server间请求处理的负载均衡;
2、防止集群中chunk server负载普遍都比较重的情况下master server仍向其转发客户端请求,系统额外添加了一个enable参数,当chunk server的负载超过最大负载值(可以由管理员设定)时,会将enable设置为false
3、chunk server负载算法如下:假设系统中有n台chunk server,loadInfo[i][j](1<=i<=n, 1<=j<=3)分别表示第i台Chunk server的CPU利用率,内存使用率及网络流量。wj分别表示CPU利用率,内存使用率及网络流量的权值。则第i台chunk server的负载:load[i]=EloadInfo[i][j]*w[j]
算法说明:
1、各项参数负载信息的获取:由于在某一时间点的负载信息并不能反映整个Chunk Server的实际负载情况,负载信息必须取一段时间内的平均值,在本系统设计中,各项参数会随着Chunk Server的心跳信息一起发送给Master Server,在计算负载时,系统会取最近3次(用户可以通过配置文件设置)的平均负载
2、各项参数权值的设定:对于CPU利用率、内存使用率、网络流量权值的设定及系统最大负载值的设定并不太容易,需要通过多次的实践才能确定比较合理的值;针对服务器用途的不同设置权重:对于一般的web服务器而言,客户端一般对响应速度的要求比较高,可以增加CPU的权重:0.5、0.2、0.3;对于文件服务器而言,需要有较大的带宽来保证文件的传输,将三者设为0.3、0.2、0.5;对于数据库服务器而言,对可用内存的要求比较高,将三者设为0.3、0.4、0.3;用户还可以根据实际情况通过配置文件自行设定
测试:
系统配置及运行环境:系统用4台运行Linux系统的主机服务器,其中3台作为Chunk Server,1台作为Master server,服务器配置信息:Linux version 2.4.20-8;CPU 2.66GHz;DDR 8GB内存;SAS 500G磁盘
测试对比:将RR-DNS轮循算法、最小连接算法和本系统设计的请求调度算法进行比较测试
测试内容:主要包括系统吞吐率和响应时间两项参数
测试结果分析:最小连接数算法和请求调度算法都需要服务器间的频繁通信,在一定程度上增加了网络的流量;从响应时间的百分比我们可以看出,在较低负载的情况下三种算法之间的差别并不是太大;但是在负载较高的情况下,随着请求数量的增加,本算法具有更高的效率
文件块存储负载均衡设计:
文件块大小及存放位置信息设计:
文件块大小设计的合理与否会直接影响到系统的整体性能;设计太小,客户端必须频繁地跟Chunk Server进行连接,增加了网络额外流量;设计太大,在文件块进行迁移或拷贝时需要花费更多的时间和占用更多的带宽;
设计一个相对较大的文件块有以下几点好处:
1、如果客户端连续几次访问的数据都属于同一个文件块,那么客户端只需要向Master Server进行一次文件块位置的查询操作,降低了网络带宽的开销;
2、客户端和Chunk Server间的一次TCP连接可以完成更多的文件块操作,提高了效率
3、把文件分成较大的文件块意味着减少了Master Server需要保存的元数据信息
每一个文件块都会以普通Linux文件的方式存储在Chunk Server上,系统在设计时默认的文件块大小为32MB,用户可以通过配置文件进行重新设定
文件块存放信息则是由chunk server动态向master server汇报,采用这种方式基于以下考虑:
1、由于Chunk Server的文件块会经常发生变动,比如磁盘损坏导致文件块不可用,也有可能文件块被迁移到其他Chunk Server上,或是管理人员操作不当而将文件块误删除
2、只有Chunk Server本身才能最终确定自身所包含的文件块信息
文件块分配策略:
各项参数考虑:
1、磁盘利用率,如果Chunk Server的磁盘容量不够,即使其他各项参数达到最优也是徒劳,防止Chunk Server的所有磁盘空间都被文件块占满,系统会由用户指定最高磁盘利用率
2、网络带宽,如果网络带宽过低,势必会影响客户端上传文件的效率
3、CPU使用情况,同样如果CPU负荷过高也会对客户端性能造成影响
4、内存使用率
5、该文件对应的其他文件块分布情况,大文件来说,应该尽量将文件对应的文件块分散到不同的Chunk Server上,提高并发
6、该Chunk Server当前所拥有的文件块总数,为了避免Chunk Server成为热点,有必要考虑Chunk Server之间文件块数量的均衡
算法设计如下:假设第i台Chunk Server的磁盘总容量为DT[i],已用容量为DU[i],最高磁盘利用率为USABLE_PCT[i]。CPU利用率、内存使用率、网络流量及其权值,参照基于存储服务器负载的客户端负载均衡算法。Chunk Server上已存在的文件块占该文件对应的所有文件块总数的百分比为FCP。Chunk Server当前拥有的文件块占所有文件块总量的百分比为CP。设定磁盘利用率、服务器负载、占该文件对应的所有文件块百分比及占文件块总数的百分比四者对应的权值为P1、P2、P3、P4。
注意点:一般对于存储大文件的服务器来说,应该相应为P3配置更高的权重。这样就可以使得大文件能够尽量分散到不同的Chunk Server上,不仅提高了性能,而且提高了可用性;对于主要存储小文件的系统来说,应该为P4配置更高的权重,这样文件块就能在Chunk Server间比较均匀地分布,避免过多的数据内容集中存储在几个Chunk Server上,造成热点
Rebalance策略:
背景:存储在Chunk Server上的文件块会发生变动,系统经过长时间的运行会出现各个Chunk Server之间负载不均的情况,系统就需要进行负载的重新分配,服务器间负载的迁移是一个典型的组合优化问题,目标就是将负载较重的Chunk Server上的部分文件块迁移到负载较轻的Chunk Server上,负载平衡问题主要研究将N个任务分配到M个处理单元上,其难度堪比Hamilton问题,是一个NP完全问题
如何Rebalance
1、大文件通过Chunk Server间文件块的迁移可以有效的实现负载均衡
2、小文件仅仅对文件块进行迁移有时候并不能实现负载均衡,比如一个小文件只包含一个文件块,那么包含该文件的Chunk Server很可能成为热点,即使将该文件块重新迁移到另一台Chunk Server,势必会导致该Chunk Server成为新的热点,对于这种情况,我们有必要增加该文件块的备份数,来实现Chunk Server间的负载均衡
3、Rebalance策略的关键是重载Chunk Server和轻载Chunk Server的选取。需要考虑的因素很多,磁盘容量、CPU平均负荷、网络带宽的平均使用率、客户端的平均访问量等。根据这些参数我们可以设定两个阀值High和Low,高于High的为重载Chunk Server,低于Low的为轻载Chunk Server
设计:
1、将重载Chunk Server称为提供者,记作P,P中不同Chunk Server的负载信息记录到一个负载矩阵W中,记为W={w1,w2,...,wi,...wm},其中wi表示第i台Chunk Server需要迁移的文件块。轻载Chunk Server称为接收者,记作R,同样,我们将每一个Chunk Server所能接受的负载记录到矩阵C中,记为C={c1,c2,...,cj,...cn},其中ci表示第i台Chunk Server可接受的文件块数。
2、在该模型中,我们假设Ewi = Ecj,其中i属于P,j属于R,负载矩阵W和C均作降序排列,定义负载分配矩阵A,使得C=W×A,则A为m×n阶矩阵
3、为了减少Chunk Server之间的消息通信给整个系统造成的影响,本系统设计的目标是使得每个Chunk Server发送和接收消息的总数量最少。将A的最优解所满足的条件记作O
测试:
系统配置及运行环境:
系统用11台运行Linux系统的主机作服务器,其中10台作Chunk Server,1台作Master Server,服务器配置信息:Linux Version 2.4.20-8;CPU 2.66GHz;DDR 8GB内存;SAS 500G硬盘
测试结果及分析:
系统初始状态下文件块在各Chunk Server上的分布可以看出,文件块的分配策略基本上使得Chunk Server上文件块的总容量保持均衡,但是文件块数量上的差别相对比较大,出现这种情况的主要原因是系统中存在部分小文件,这些小文件可能远小于标准文件块的大小(比如系统默认的32M,而该文件却只有几k),却作为一个单独的文件块存在,这就使得有些Chunk Server虽然文件块数量较多却实际上占文件总容量的百分比并不大;相反,有些Chunk Server上虽然文件块数目较少,但存储的文件块几乎都是标准大小,因此占文件总容量的百分比较大
系统运行一段时间后,由于各种原因比如网络故障、磁盘损坏、Chunk Server宕机等等原因造成Chunk Server之间文件块分布的不均衡现象,以下是某一时刻各Chunk Server上文件块分布情况
文件块的分布基本上毫无规律可言,负载较重的Chunk Server很容易就会出现过载情况而不能提供服务,导致系统性能急剧下降
接下来就需要对整个系统进行Rebalance,由于Rebalance过程会使得系统的整体性能受到影响,而且会占用大量的带宽,因此只有在系统较为空闲的时候才能进行
经过负载的重新分配以后,各个Chunk Server上的文件块数目和文件块总容量基本上分布比较均匀。为了避免存储小文件的Chunk Server成为热点,系统会适当的增加小文件的拷贝数