分布式系统初步研究.docx
- 文档编号:9732160
- 上传时间:2023-02-06
- 格式:DOCX
- 页数:39
- 大小:480.25KB
分布式系统初步研究.docx
《分布式系统初步研究.docx》由会员分享,可在线阅读,更多相关《分布式系统初步研究.docx(39页珍藏版)》请在冰豆网上搜索。
分布式系统初步研究
分布式系统相关技术初步研究
近期对各种分布式技术进行了初步研究,主要包括:
分布式文件系统(GoogleFS、GFS、Lustre等)、关系数据库集群系统(ORACLERAC、Teradata、MysqlCluster、MysqlMaster-slave、MysqlProxy、C-jdbc、变形虫)、分布式Key-value数据库(BigTable、Dynamo)。
本文档将逐一介绍这些系统思路,并对目前分布式系统技术进行总结。
一分布式文件系统
1.分布式文件系统
最初文件系统只能管理本地磁盘空间。
主机之间文件共享与传输则通过FTP实现。
但FTP没有提供与本地文件系统一致的访问接口和对象模型。
随着计算机应用范围的扩展,通过文件访问接口在不同主机之间共享文件的需求日益增强。
从最早的分布式文件系统NFS开始,到现在经过20多年的发展,目前分布式文件系统的种类很多。
当目前主流分布式文件系统一般包括三类:
NFS、基于共享磁盘分布式文件系统(主要基于SAN)、基于对象存储的分布式文件系统。
2.NFS
NFS从1985年出现至今,已经经历了四个版本的更新。
结构如下:
NFS利用Unix系统中的虚拟文件系统(VFS)机制,将客户机对文件系统的请求,通过规范的文件访问协议和远程过程调用,转发到服务器端进行处理;服务器端在VFS之上,通过本地文件系统完成文件的处理,实现了全局的分布式文件系统。
一般NFS文件系统由一台NFS服务器和多个客户端组成。
所有文件统一存储在NFS服务器上,类似文件服务器。
多个客户端利用mount将位于NFS服务器上的文件系统加载到本地,让客户机利用访问本地文件方式访问远程文件,实现文件共享。
NFS主要缺点是NFSServer会成为整个系统瓶颈和单点,如果采用多个NFSServer则无法实现一个全局统一文件系统,同时NFS在并发访问控制方面也不太好。
3.基于共享磁盘分布式文件系统
基于共享磁盘分布式文件系统包括RedHat的GlobalFileSystem、IBM公司的GeneralParallelFileSystem等。
基于共享磁盘文件系统所有节点通过存储网络(一般是SAN存储网络)与所有块存储设备相连,由安装在所有节点上分布式文件系统程序控制节点间对共享块设备并发访问控制。
基于共享磁盘文件系统一般是对称结构,即所有节点之间角色相同,不存在服务器与客户端区别,也称为“serverless”架构。
节点与块存储设备之间采用直接I/O通道,因此I/O效率会很高。
下面主要介绍GlobalFileSystem,GeneralParallelFileSystem为商业文件系统,不开源。
GFS体系结构如下图:
GFS吸取了对称多处理器(SMP)系统设计和实现原理,将系统中每一个客户机类比于SMP中的一个处理器。
客户机间没有任何区别,可以平等地访问系统中所有存储设备,就像处理器可以机会均等地访问主存一样。
这样设计可以更好地利用系统中资源,消除单个服务器带来性能瓶颈和单点失效问题。
GFS采用特殊设计的锁机制来同步多个客户机对同一设备的访问,具有很高效率。
✓GlobalFileSystem中锁机制
分布式文件系统中关键功能是多节点间并发访问控制。
GlobalFileSystem提供了两种锁机制:
DLM、GULM(还有一种对单节点的no-lock机制)。
GULM是“server/client”模式锁机制。
采用GULM时,必须指定一个或者多个节点作为GULM服务器。
GLUM缺点是GULM服务器成为系统瓶颈。
如果存在3个或者5个GULM服务器,可容忍1或者2个GULM服务器节点失效。
DLM(DistributeLockManager)是全对称结构。
基本思路是:
每个文件第一个打开该文件节点成为该文件“LockMaster”,此后其他节点需要打开或者获取该文件锁,必须通过网络与“LockMaster”协商,所以非“LockMaster”节点访问文件时速度比较慢,但“LockMaster”对文件访问不必要获得其他节点许可,访问速度很快。
因此GlobalFileSystemFAQ建议:
使用DLM时,如果一个三节点GFS存储有30,000个文件,最好让每个节点全权处理其中10,000个文件,尽量减少非“LockMaster”的文件访问。
(类似ORACLERAC中应用分区)
✓逻辑卷管理
使用GFS时,一般利用CLVM(ClusterLogicVolumeManage)将所有物理块设备虚拟化成一个大存储池,然后在该逻辑卷上创建GFS文件系统。
CLVM与LVM区别是CLVM利用DLM锁机制实现跨节点逻辑卷访问控制。
利用CLVM可以实现在线动态增加存储,并提供条带化、镜向等功能。
CLVM与GFS关系好象是GFS利用DLM锁来控制对元数据并发访问,CLVM用来控制对实际数据在各个逻辑卷上的并发访问。
✓OracleRAC认证
RHEL4/GFS6.1通过OralceRAC的认证,但只认证了GULM方式。
同时RAC/GFS节点不能是GULM服务器节点。
✓GFS中的Fencing
所有共享磁盘系统(GFS,ORALCERAC等)保证共享磁盘上数据一致性前提是所有节点之间通讯能畅通无阻,否则会因为通讯不畅通导致多个节点写冲突而破坏数据一致性,导致数据丢失,即所谓“脑裂”。
共享磁盘系统中节点之间不断通过“心跳”来互相检测对方是否健康,一旦发现对方没有响应,必须将故障节点驱逐出集群,即Fencing。
实现Fencing主要包括两种方法:
节点Fencing和I/OFencing。
节点Fencing就是将故障节点电源关闭,I/OFencing就是切断故障节点与共享磁盘之间的I/O通道。
GFS中一旦有节点检测到另外一个节点心跳信号没有反应,则开始执行对该节点Fencing。
在执行Fencing过程成功完成之前,所有GFS节点都不允许新申请锁,在Fencing完成后,锁管理器会回收被Fencing节点拥有的锁和资源,并允许申请新锁。
在Fencing过程中或者Fencing失败之后,整个GFS处于“freeze”,所有需要申请新锁操作都会被挂起,不过对已经获得锁的操作不影响。
因此某个节点故障,会导致整个系统工作短暂不正常(Fencing失败会导致长期工作不正常)。
✓GFS规模大小
GFS节点间访问控制以及Fencing等机制导致GFS一般规模不会很大,在FAQ中提到实际环境中最大规模是6个节点,153TB(FAQ发表日期不确定)。
将GFS作为RedHatClusterSuite一部分进行部署,整个Cluster节点不能超过16。
4.基于对象存储的分布式文件系统
基于对象存储分布式文件系统包括Lustre、GoogleFileSystem等。
基于对象存储分布式文件系统中对象的含义是相比传统文件系统中文件由“Block”组成,存储于基于对象存储分布式文件系统中文件由“Object”组成,并且“Object”存储于“专用存储服务器”,具备一定智能。
基于对象存储分布式文件系统一般包括:
元数据服务器、对象存储服务器、Client。
元数据服务器负责整个文件系统的命名空间、文件与Object映射关系等,对象存储服务器存储Object即真正的数据,Client与元数据服务器和对象存储服务器联系访问文件系统中的文件。
Lustre文件系统有专门文档介绍,下面主要介绍Google公司的GoogleFS。
1)设计动机与假设
Google公司设计GoogleFileSystem的动机是:
✓构建系统任何部件故障概率比较高,而且某些部件可能无法恢复(例如磁盘损坏),必须将系统检测、错误检查、容错、自动恢复设计到文件系统中。
✓文件一般是包括了多个对象(例如web网页)的大文件(GB级别),。
✓对文件修改都是“追加”而不是改写现有数据,基本不存在针对一个文件的随机写。
文件一旦写入,基本只读,而且是顺序读。
✓设计自己的分布式文件系统可以更好满足应用需求。
2)体系结构
✓文件分片与复制
整个GoogleFS由Master、Chunkserver、client组成。
存储在GoogleFS中的文件被切分成固定大小为64MB的片,每个分片在创建时由Master分配全局唯一的编号。
Chunkserver采用本地Linux文件系统存储分片,并执行对分片的读写操作。
为保证可靠性,每个分片被复制并存储于多个ChunkServer中。
Master复制维护文件系统元数据:
命令空间(目录结构与文件名信息)与访问控制信息、文件与分片的映射关系、各分片存储位置。
Master定期利用“心跳”信号与Chunkserver通讯,发布Master指令,监控chunkserver状态。
Client和ChunkServer不缓存数据。
Client因此一般读取数据比较大无法缓存,而ChunkServer因为本地Linux文件系统已经对常用的数据进行了缓存。
✓分片大小的决定策略
采用64MB这种比较大的分片优势:
Google大部分应用是连续读或写大文件,采用较大分片可减少client和master之间交互次数;client操作集中在一个分片上的概率变大,可以保持与一个ChunkServer的长期网络连接,减少通讯连接建立开销;减少元数据的数量。
缺点是如果大量客户同时某个访问小于64MB文件,则存储该分片服务器会成为“热点”。
Google应用以顺序读写为主,因此出现热点概率不大。
✓元数据结构与管理
Master维护的元信息都存储在Master内存中:
命令空间(目录结构与文件名信息)与访问控制信息、文件与分片的映射关系、各分片存储位置。
前两类信息以“操作日志”持久化保存在Master本地磁盘上,并复制到多台远程服务器中。
由于前两类信息丢失会导致整个文件系统破坏,因此只有操作日志在本地磁盘和多个远程服务器写成功后,才返回客户端请求。
为加快恢复时间,减少操作日志大小,同时采用了checkpoint技术。
分片位置信息由Master启动时询问所有ChunkServer来获得,因此不需要持久保存。
✓分片复制与分布策略
选择新建一个分片位置主要考虑以下因素:
优先选择剩余空间较大Chunkserver、限制每个ChunkServer最近新建分片数量(新建分片意味立刻会有大量写操作)、尽量将分片不同复本分散到不同机架。
Master负责检测各个分片复制份数,如果少于复制份数会自动启动对该分片的复制。
Google设计将不同分片分散到不同机架考虑是,一般GoogleFS包括至少上百台服务器,并且分布在多个机架中。
为保证各个chunkserver存储均匀与负载均衡,GoogleFS会定期进行“Rebalance”。
5.分布式文件系统的总结
1)GlobalFileSystem
✓需要SAN等共享磁盘存储支持。
✓系统规模只支持10个左右节点
✓支持存储扩容(CLVM)
✓任何节点故障可能会导致短时间内整个系统挂起
✓存储数据安全性由底层SAN设备保证(CLVM镜向不知是否可提供恢复)
✓提供通用文件访问接口
✓不属于分布式存储系统,其分布体现在计算节点分布,而不是存储分布,存储本身属于集中存储。
2)Lustre
✓为提高性能,需要Infiniband等高速网络支持
✓对小文件处理性能不好
✓可以扩展上千个节点规模
✓提供节点Failover,但是不支持存储设备容错
✓某个存储节点故障,会影响多个节点(即使stripe_count=1,一般全文索引库或者数据库都由多个文件组成情况下,某个文件损坏会导致整个库的损坏)
✓元数据MDT是单点
✓侧重于性能而不是可靠性
✓提供通用文件访问接口
3)GoogleFs
✓主要优势是大文件的顺序读写
✓基本上是写入后不修改的策略
✓将所有数据进行复制,保证数据安全
✓侧重可靠性和大文件的顺序读写性能。
✓大数据量访问时网络可能会成为通讯瓶径。
✓不提供通用文件访问接口。
分布式文件系统对我们而言主要能实现计算节点与存储节点的分离,既解决DAS方式系统扩容时面临新老存储设备容量差异很大时导致计算节点负载不均衡。
分布式文件系统无法解决I/O热点,即以前面临扩容会导致所有新数据会写入新增加的存储设备,导致如果用户一般主要访问新数据时存在I/O热点问题。
GlobalFileSytem必须要求使用SAN等共享存储,必须使用磁盘阵列柜和SAN交换机,增加了存储成本,同时由于GlobalFileSystem中任何一个节点故障会导致整个系统暂时或者长时间不可用(对节点Fencing要求很高),以及GlobalFileSystem扩展性不是很好,因此不适合作为我们使用。
GoogleFS目前不开源,而一些开源项目目使用人少(HDFS、MooseFS)。
(因为上层软件要修改文件访问方式)。
Lustre优势在于性能和规模,而缺点是可靠性,Lustre可以认为是“F1赛车”。
要使用Lustre必须花费大力气来保证数据安全。
个人认为:
Lustre只实现RAID0条带策略,而GoogleFs实现类似Raid1的条带策略,关键点在于GoogleFS假设文件修改基本上是追加而不是修改原有数据,因此复本之间一致性问题会比较容易解决(即使如此GoogleFS论文中关于一致性问题论述也非常复杂,专门有一章内容描述GoogleFS的一致性模型与协议)。
Lustre作为一个分布式通用文件系统,强调数据一致性(consistent)和数据规模扩展性(Partition)。
根据CAP理论(参考第四部分第一节),Lustre只好牺牲可用性(available),这解释了为什么Lustre一直不实现类似GoogleFS的数据分片复制策略。
二关系数据库集群系统
1.分布式数据库与并行数据库基本知识
关系数据库集群系统的实现方式可以分为两大类:
基于关系数据库引擎、基于数据库集群中间件。
利用C-JDBC、Amoeba等数据库集群中间件构建的数据库集群一般如下:
中间件位于Client和多台普通的数据库服务器之间,Client所有数据库操作请求都统一发送给中间件,中间件按数据复制和分割策略来调用相应的后台普通数据库功能完成Client的请求,将多台普通关系数据库对Client虚拟成一台Virutal数据库。
基于中间件数据库集群属于分布式数据库系统。
ORACLERAC、TERADATA等基于引擎的数据集群属于并行数据库系统。
并行数据库系统体系结构分为三类:
✓共享内存:
所有处理器共享一个公共的主存储。
✓共享磁盘:
所有处理器共享公共的磁盘。
✓无共享:
所有处理器既不共享公共的主存储,也不共享公共的磁盘。
分布式数据库系统数据库存储在几台计算机中。
分布式系统中计算机之间通过高速网络相连。
这些计算机不共享公共内存或者磁盘。
无共享并行数据库与分布式数据库之间区别在于,分布式数据库一般是地理上分开,分别管理,并且是以较低速度互相连接(与无共享并行数据库互连速度比较)。
(参考<<数据库系统概念>>)
2.OLTP与OLAP
数据库系统一般从使用模式上讲可分为:
OLTP系统和OLAP系统。
典型OLTP系统包括:
售票系统、计费系统。
典型OLAP系统包括:
电信运行商的数据挖掘分析系统。
这两者区别如下:
OLTP
OLAP
应用特性
事务性,以修改为主
查询报表类,复杂查询
数据变化方式
处于不断变化之中
批量导入,导入后不变化
事务总量
多
少
单个事物时间
短
长
涉及数据量
少数几行
少数几列,但所有行
数据模型
三范式
多维模型
查询涉及字段
一般是所有字段
个别字段
个人认为智能分析系统数据库位于OLTP与OLAP之间,其数据导入类似OLAP,但是数据库查询模式属于OLTP。
3.数据库分片(Sharding)-数据库水平切分
1)eBay关于数据库分片描述
按功能分割对我们的帮助很大,但单凭它还不足以得到完全可伸缩的架构。
即使将功能一一解耦,单项功能的资源需求随着时间增长,仍然有可能超出单一系统的能力。
我们常常提醒自己,“没有分割就没有伸缩”。
在单项功能内部,我们需要能把工作负载分解成许多我们有能力驾驭的小单元,让每个单元都能维持良好的性能价格比。
这就是水平分割出场的时候了。
在应用层次,由于eBay将各种交互都设计成无状态的,所以水平分割是轻而易举之事。
用标准的负载均衡服务器来路由进入的流量。
所有应用服务器都是均等的,而且任何服务器都不会维持事务性的状态,因此负载均衡可以任意选择应用服务器。
如果需要更多处理能力,只需要简单地增加新的应用服务器。
数据库层次的问题比较有挑战性,原因是数据天生就是有状态的。
我们会按照主要的访问路径对数据作水平分割(或称为“sharding”)。
例如用户数据目前被分割到20台主机上,每台主机存放1/20的用户。
随着用户数量的增长,以及每个用户的数据量增长,我们会增加更多的主机,将用户分散到更多的机器上去。
商品数据、购买数据、帐户数据等等也都用同样的方式处理。
针对不同数据,我们分割数据的方案也不同:
有些是对主键简单取模(ID尾数为1的放到第一台主机,尾数为二的放到下一台,以此类推),有些是按照ID的区间分割(1-1M、1-2M等等),有些用一个查找表,还有些是综合以上的策略。
不过具体的分割方案如何,总的思想是支持数据分割及重分割的基础设施在可伸缩性上远比不支持的优越。
数据库Shading其实与数据库中的表分区类似,主要区别在于数据库中的表分区一般是在单个数据库内,不能跨物理服务器,当然也有例外,例如ORALCERAC环境下的表分区也是跨物理服务器。
个人认为ORALCERAC下的表分区与这里提到的数据库shading区别在于:
前者是sharing-disk,而后者是sharing-nothing。
2)Shading策略
Shading的策略目前主要分为以下几类:
✓基于区间方法
根据某个字段按区间来进行划分,例如可根据用户ID来划分。
类似ORALCE数据库分区中的RANGEPartition
✓基于hash方法
根据某个字段采取hash算法来划分,这种方式问题是扩展性不好,增加或者减少服务器涉及数据的重分布。
当然目前有DHT(DistribueHashTable)技术来部分解决该问题。
类似ORALCE数据库中的HASHPARTITON。
✓基于查找表的方法
创建一个
采用该方式需要保证全局查找表的可靠性。
此种策略最灵活,但是存在单点故障。
类似ORACLE数据库中LISTPartiton。
shading策略必须在充分理解应用系统使用模式基础上制定,必须考虑如何避免跨节点分布式事务(代价太大)、避免访问热点。
例如web网站一般按注册用户id进行shading,此时要考虑到active用户与非active用户对shading策略的影响,否则如果把所有active用户数据shading到少数节点时就会出现访问热点。
3)不要误用Shading
Shading实际上借鉴“ShareNothing”概念。
但是有些类型数据粒度之间就不是"ShareNothing"的,比如类似交易记录的历史表信息,如果一条记录中既包含卖家信息与买家信息,如果随着时间推移,买、卖家会分别与其他用户继续进行交易,这样不可避免的两个买卖家的信息会分布到不同的ShardingDB上,而这时如果针对买卖家查询,就会跨越更多Sharding,开销就会比较大。
Sharding也有其不适合场景,比如处理事务型应用就会非常复杂。
对于跨不同DB事务,很难保证完整性,得不偿失。
所以采用什么样的Sharding形式,不是生搬硬套的。
4.Master/Slave与Master/Master
Master/Slave与Master/Master架构是目前中等流量规模的WEB站采用的一种数据库架构。
很多网站随访问量增加,数据库架构演变路线路图是:
单数据库服务器---->Master/Slave、Master/Master------->shading。
Master/Slave架构主要针对目前大部分WEB站Read操作次数大大多于Write操作的情况下的一种读/写分离,示意图如下:
Master/Slave结构下一般有一个Master和多个Slave.所有的写操作和极少量的读操作发生在Master上,而决大部分读操作通过负载均衡分布在多个Slave上。
Master/Slave关键是Replication,一般采用的是基于数据库relog操作日志来进行同步。
Master/Slave一般会在间隔较短一段时间内同步一次。
因此一般是将对一致性不是非常高的查询操作放在Slave上,否则还必须在Master上进行查询。
MysqlReplication即提供数据复制功能。
Master/Salve架构存在一个明显的问题上Master是个单点。
为了解决该问题可以采取Master/Master架构。
目前开源项目“MySQLMaster-MasterReplicationManager”支持该架构。
该项目支持的以下典型的用法:
Ø两节点
该配置有5个IP地址:
Master1和Master2的固定不变IP,两个READ-IP,一个WRITE-IP,后三个IP可根据情况进行迁移。
正常情况下,一个节点有一个WRITE-IP和一个READ-IP,另外一个节点有一个READ-IP。
当出现故障时,所有IP迁移到正常工作的节点上。
ØTwoMaster+one/manySlaves
为了向Client屏蔽Master/Slave中数据库的分布复杂性,可利用开源项目MysqlProxy,MysqlProxy作为代理运行于Client和服务器之间,解析客户端发出的SQL请求,然后路由到相应服务器。
5.数据库集群中间件
数据库集群中间件实质就是一种数据库代理,向客户端屏蔽后端数据分布复杂性,提供一个统一的、虚拟的数据库,也可将这类软件称为“数据库路由器”。
比较有名开源项目包括:
C-JDBC(Cluster-JDBC)、Amoeba。
下面分别介绍
4)C-JDBC
C-JDBC的思路是借鉴磁盘阵列柜的RAID技术,提出并实现一种“RedundantArrayofInexpensiveDatabases”概念。
该项目已经改名为Sequoia,并且目前有一家公司在维护。
该项目目前支持Oracle、SqlServer等多种数据库。
C-JDBC提供了三种RAIDb级别:
✓RAIDb0:
(1)将不同表分布到服务器(不能将一张表分布到多个服务器)。
(2)数据分布模式支持“Random”和“Roundrobin”。
(3)采用“two-phasecommit”来实现跨服务器之间的事务控制。
✓RAIDb1:
(1)所有服务器之间数据都是镜向关系,既全复制。
(2)对读操作负载均衡支持“Roundrobin”、“WeightedRoundrobin”、“LeastPendingRequestsFirst”三种策略。
(3)对写操作WaitForCompletion支持“first”、“majority”、“all”三种策略,分别表示是否要等待多少
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 分布式 系统 初步 研究
![提示](https://static.bdocx.com/images/bang_tan.gif)