2016-11-22 15:54:34 karamos 阅读数 354

随着科技的发展和网络技术的进步,计算机存储空间显得愈加紧张,大规模的数据增长为文件存储、非结构化数据存储提出了新的挑战。面对这些挑战,对象存储技术将如何帮助企业赢得未来?

图片描述

奥思数据创始人兼CTO 李明宇

2016年11月16日,在中国新一代IT产业推进联盟指导、奥思数据和CIO时代网主办的2016首届对象存储技术及应用大会暨奥思数据OStorage-EOS产品发布会中,奥思数据创始人兼CTO李明宇告诉大家:从NAS文件存储转向对象存储是时代的必然。

NAS文件存储已显乏力,企业开始探索新存储方式

据IDC预测,全球的数据量正面临一个爆炸性增长,到2020年即将达到44ZB,换算成128GiPad的高度,可达地球到月球距离的6.6倍。这些数据中,90%的增量来自于非结构化数据,包括文档、照片、视频、医疗影像、基因测序数据、遥感数据、科学观测数据等,对企业的数据存储能力提出了挑战。

目前我国企业主要采用NAS文件存储方式应对日常的数据存储与数据共享,但由于近年来数据量的持续提高,在NAS的使用中访问数据产生的带宽消耗和其他流量的影响显得愈发严重,大幅度拉低了系统效率,尤其是高并发访问的情况下,这些现象显得格外突出。随着视频行业、金融领域、医疗行业、气象领域等各个行业领域的非结构化数据存储都遇到了高并发访问、数据共享、跨地域数据存取的难题,NAS文件存储将显得更加乏力。于是,企业们纷纷开始寻找满足更大数据存储需求的新存储方式。

为解决数据存储问题而进行探索,淘宝算是国内的先行者之一。最初的几年,淘宝试图通过购买其他厂商的文件系统,扩充企业的数据容纳量,但每年数百上千万的开销并没有带来相匹配的效果。于是淘宝专门针对海量非结构化数据存储问题设计了一套分布式系统TFS,尽管当时对象存储的概念尚未明确,但这套系统已初具对象存储的模型。与传统的文件系统相比,TFS对前者强调的两个特点进行了极大的改变,首先用扁平命名空间取代传统文件系统的目录树,其次将支持随机读写的复杂接口转变为更简洁的数据读写接口,以提高用户访问与数据读写的效率。除淘宝之外,京东、Facebook、twitter等面对数据存储挑战的大型企业,都采用了类似的方式,用新系统来代替传统文件存储系统,为数据寻找更加合理的存储方式。

先行者们针对海量数据存储解决方案进行了一系列探索,但问题并没有得到完美解决,在基因数据、遥感数据、视频数据等大文件存储方面依然存在空白。直到后来企业级对象存储系统面世,大规模数据存储问题才有了更好的答案。

企业级对象存储系统帮助企业迎接未来数据挑战

作为专业的数据存储系统,企业级对象存储系统继承了上述分系统的优点,采用扁平命名空间、简洁的数据读写接口,并在其基础之上做了进一步延伸——一是对大对象的延伸,突破了互联网公司海量小文件存储的范畴,同时支持大小对象的存储;二是在把数据读写接口简洁化的同时服务化,通过HTTP服务的方式把存储的接口暴露出来,更方便在广域网上访问。为了向企业提供更好的企业级对象存储系统,奥斯数据公司在对象存储领域进行了深入研究,以行业尖端技术开发出OStorage-EOS系统,让存储海量数据变得更加简单易行。

OStorage-EOS企业级对象存储产品,核心代码经过广泛验证,稳定可靠。使用软件定义存储技术,通过软件解决存储的可靠性和可用性问题,极大降低了企业硬件成本。其次,采用全分布式架构,不设置集中管理节点,将节点故障对系统的影响降到最低,而且OStorage-EOS能够近乎无限地扩展,性能随规模线性提升,避免了传统文件存储的规模极限效应。此外,OStorage-EOS还支持纠删码,相比分布式系统常用的三副本技术能够大幅度降低存储空间,进一步节约硬件投资50%以上,让用户灵活控制对可靠性、可用性的要求及成本之间的权衡。在跨地域数据存取方面,OStorage-EOS支持跨地域部署,多数据中心做成一个存储系统,互相同步,灵活可靠地实现多地域多数据中心多活。为了满足金融、医疗等多种行业的实际需求,OStorage-EOS还做了安全增强、数据预处理等企业级插件,提供数据加密、集成、双因子和多因子认证等多种安全手段,并对传统文件接口和阿里云OSS全面兼容,以方便多种企业的数据迁移。

在国内相关技术不尽发达的现状下,以OStorage-EOS为代表的企业级对象存储系统填补了空白,给了人们应对大规模数据存储的新思路,为企业面对未来的数据存储挑战,特别是非结构化数据存储挑战提供了很好的解决方案。

每一项技术产生之后,都将在不断创新的过程中进行发展完善,对象存储技术也不例外。作为国内首家对象存储系统及服务提供商,奥思数据深刻洞悉用户需求,以OStorage-EOS系统为用户带来了更多的价值——低成本、高可靠性、自主可控、支持跨地域、多备份等。可能这些价值不久后将成为对象存储系统的基本特点,但奥斯会一直站在行业前列,用最尖端的技术帮助企业和用户赢得一个更好的未来。

本文转载自云头条微信

2016-05-12 13:51:57 karamos 阅读数 204

和李明宇老师认识源于对OpenStack技术峰会的筹办,其实很早之前就知道他在OpenStack领域的卓越贡献,尤其对OpenStack技术在国内的普及和推广。这次有幸邀请到李明宇先生担任我们OpenStack技术峰会的出品人,也是给了我很多的学习机会,事实上,也在他身上学到了很多宝贵的经验。

李明宇老师是一位非常敬业的出品人和创业者,更重要的是OpenStack的积极布道者,他对讲师的邀请和具体议题的把握完全超乎了我的想象,对于每一个细节都力求完美。本次采访,李明宇老师也谈到他对OpenStack的一些思考和未来的走向,可以说是对中国OpenStack发展很好的总结和建议,在这里真的要非常感谢李明宇老师的帮助和指导,以及他对社区的贡献。

图片描述

OpenStack知名布道师

CSDN:李总现在的研究方向有哪些?

李明宇:最近几年我从事的技术方向都是和OpenStack相关的,以前我在中科院主要是承担了一些私有云建设的任务,在虚机的Scheduling、Live Migration、Memory Deduplication等地方都有所创新,发表了一些论文并申请了一些专利,我们当时能够把云上的整个Hadoop集群从一个Data Center到另一个Data Center做Live Migration,而且三年前我们就在研究Cloud Native架构和微服务技术。最近两年离开中科院后我逐渐转向了分布式存储,基于OpenStack Swift做企业级对象存储产品,我在最近两届OpenStack Summit上都有演讲,总共四个,全是和OpenStack Swift及对象存储相关的。就在前不久,我创立了一家公司叫OStorage(奥思数据),专门从事对象存储技术和产品的研发、推广。

CSDN:您一直活跃在OpenStack社区,社群,积极布道OpenStack,从你自己来说,最深的感悟有哪些?

李明宇:一开始参与社区活动,只是处于对开源的兴趣爱好,后来逐渐变成工作的一部分,甚至是很重要的一部分,几年过来感慨良多,最深的感触是国内开源社区的飞速发展。不仅仅是OpenStack,在整个开源界中国工程师和中国公司扮演的角色都越来越重要,就在几年前,我们国内与开源相关的技术工作还主要是会用、做本地化、封一个更漂亮的界面提供给用户……甚至某位业内的大佬曾经开玩笑说“界面是各公司的核心竞争力”,当时如果一个工程师能改开源软件的代码,我们就会说他是“源代码级专家”。现在,我们更多地听到人们在谈论,谁谁又成为了某项目新晋Core(核心开发者和代码审核者),谁谁成为了PTL(开源项目的负责人),事实上,OpenStack M版本国内贡献量第一的工程师,在全球个人贡献量排第三。

每届峰会上中国公司的演讲也越来越多,并且出现了诸如中国移动、国家电网、中国超算广州中心也就是天河二号这样的super user,这些都是非常喜人的进步!这很大程度上得益于国内经济的发展,否则中国移动和国家电网这样的用户也没有能力投入新技术上,OpenStack厂商也就没有收入,国内社区也就无从发展,更谈不上水平的提高。但是,我们也应当看到一些差距,我们在进步的时候国际社区也在进步,纵向比较固然是颇为喜人,但是横向比较,不论是生态还是技术水平,与国外仍然有较大的差距。

CSDN:开源的IaaS云平台,从之前的百花齐放,到现在的OpenStack一家独大,你觉得其中的原因是什么?

李明宇:社区!OpenStack诞生之初就特别重视社区的建设,而社区对于开源软件来说,是极其重要的。

有一个强大的社区,技术上的不足会有全世界最优秀的工程师来帮你补足,比如OpenStack Heat本身在集群管理和Auto-Scaling方面有一些问题,滕启明就提出了Senlin项目来弥补在这里的不足,我们现在还有一些OpenStack工程师在回馈Python社区,帮大家完善Python;

有一个强大的社区,能够吸引到全世界最严格的用户来帮你做验证,比如我们这个会上的中国移动和银联,电信和金融行业都属于对系统的可靠性和性能要求最高的行业,他们现在都在生产环境中用OpenStack,这些用户会提出很高的要求,帮助社区发现问题,甚至自己提交代码来完善OpenStack。

强大的社区还会带来其他一些好处,就不一一列举了,我们也看到有一些开源软件,本来技术上很优秀,但是没有形成社区,所以最后逐渐无人问津。

我还想说的是,强大的社区不是从天上掉下来的,OpenStack基金会在社区运营上有极大的投入,包括每年举办两次的Summit、OpenStack社区本身有一套完备的IT基础设施和游戏规则让全世界的开发者协同起来、董事会和技术委员会的设立与分工、吸引企业级会员加入、打造面向个人的COA认证和面向公司的兼容性认证等。这些都是OpenStack非常值得学习的地方。

CSDN:目前圈内针对OpenStack有着不少的争议,尤其伴随着容器技术的火热,你怎么看?

李明宇:Docker是个伟大的发明,容器技术由来已久,但是一直难以得到广泛的应用,三年前Docker诞生,很快引爆了容器。但是我从来不认为容器技术和OpenStack之间有什么竞争关系,OpenStack是一个集成框架,在云这个领域中的位置相当于计算机中的操作系统,而Docker更多的是通过容器技术支持云应用,其位置相当于计算机中的某个组件,当然这个组件是有跨平台能力的,有没有OpenStack,它都能玩得转。

所以,你会看到这两者并不矛盾,但是因为它们都还在各自的发展阶段,所以它们现在交集还不是很多,有许多用户在考虑选择OpenStack还是Docker,但是很快,用户将发现,这两者中的任何一个都不是银弹,甚至他们结合起来也不能解决我们在新一代IT架构中遇到的所有问题,我们需要结合OpenStack、Docker以及其他优秀的技术去打造一个完美的系统。

CSDN:OpenStack目前在企业中的使用情况如何?企业在使用OpenStack过程中有哪些顾虑?

李明宇:OpenStack在得到越来越广泛的应用,这是毋庸置疑的,从ebay、携程、京东、乐视等互联网公司到如今大量金融、电信、电力、制造等传统行业中的生产级应用,包括很多以前不太看好OpenStack的公司、机构也都纷纷开始使用和支持OpenStack了。

至于说到“顾虑”,主要是面对一个新的环境、新的技术,特别是在一个行业中第一个吃螃蟹的,都会比较谨慎,以防出现问题影响业务的正常运行。企业在把业务往OpenStack云环境中迁移的时候,往往会先做一个POC,再把一些开发测试业务放到OpenStack云上,然后逐渐把生产业务放上去。我觉得这是很正常的,这就好比我们学开车,首先肯定是在驾校里开,再由教练带着去一些特定的路段上开,拿到驾照后自己可以开车出门了,一般会开几次熟练了以后才会带上老婆孩子,等到一年以后才能大刀阔斧地上高速。什么事情都得有个过程,企业从接触OpenStack到把生产业务搬到OpenStack云上,这个过程通常需要一到两年,这也就是为什么前两年会有人质疑问OpenStack到底有没有生产级应用,因为这个过程还没走完,最近一年就好得多了,不论是全球范围还是国内来看,都有了越来越多的生产级案例。对于OpenStack公司来说,这个过程很难熬,但是一旦熬过来了,结果就是好的。

CSDN:OpenStack后续的发展,你认为会朝着一个什么样的方向走下去?

李明宇:OpenStack是一个很大的框架,所以要说发展方向的话,也是多元化的,这里我就国内市场谈两个趋势吧,第一个是我觉得OpenStack厂商还得再过两年苦日子,前面我们说这两年OpenStack需求在不断涌现,越来越多的用户要上生产,这对于OpenStack公司来说是好消息,因为生意越来越多了,但是,同时我们也看到竞争越来越激烈了。从去年开始,我明显感觉到OpenStack市场的竞争越来越激烈,而且出现了越来越多的OpenStack团队和公司,这让OpenStack创业公司的日子过得不太舒服,这个阶段还将持续下去,两三年后,一些小的OpenStack公司和团队由于能力不够,逐渐会被用户淘汰,几个比较有实力的、专业的OpenStack公司会逐渐成熟壮大,几个大而全的IT厂商也会与这些专业OpenStack公司形成稳定的合作,这时候它们才真正迎来他们的春天。但是我说商业上的苦日子并不代表心理上的苦日子,我接触过的OpenStack公司的同仁都过得很有激情,有句话说“痛并快乐着”。

第二个趋势是,我认为国内市场有新一轮的商业机会正围绕OpenStack展开,在各个垂直技术领域。OpenStack由许多项目组成,每个项目都要解决自己的问题,这里就需要专业的公司出马。

首先引起人们关注是Neutron管理的虚机组网和Cinder、Nova管理的虚机块存储,俗称云硬盘,例如,在办我们这个会议期间给予大力支持的博科,他们做SDN,目前非常重视围绕OpenStack打造网络方案以及在中国市场的投入,还有从去年开始逐渐涌现了一批做分布式块存储的公司,为OpenStack云提供超融合方案,一些传统存储公司也在往超融合上转。

除了虚机的组网和块存储之外,我们还可以想一想有没有其他方向的机会,这个趋势在国外已经很明显了,比如硅谷有一家创业公司叫SwiftStack,每届OpenStack Summit上,他都是比较闪耀的明星,他们就是专门围绕OpenStack对象存储Swift这一个项目来做,还有一家公司叫Tesora,他们专门基于OpenStack Trove做Database as a Service,这次奥斯汀峰会上我还看到一家公司专门为OpenStack云环境提供数据保护,思路跟OpenStack Smaug项目类似。从OpenStack中的一个项目切入,深入解决用户的痛点,深耕垂直领域,将成为OpenStack生态中的新一轮商业机会,而各垂直技术领域的市场体量总和,我预测比OpenStack本身还要大很多,非常有想象空间。

CSDN:这次作为OpenStack技术峰会的出品人,对于议题和讲师,您都全程把控,全力为参会嘉宾带去最大的收获,谈谈您的想法吧?

李明宇:去年的会议很成功,演讲嘉宾和内容非常受欢迎,所以今年要想重现去年的辉煌,压力很大。而且这可能是我最后一次以社区中立的身份来组织技术活动了,正如之前说的,后面我要着力做我那家对象存储厂商了,所以,这次也是确实是尽了全力来打造一场盛宴,以期能最大程度上的给OpenStack生态的发展贡献一点绵薄之力,自己也有个完美的谢幕。大家从大会的议程中可以看出,这次会议的内容主要有两类议题组成——super users 和 super developers。

非常荣幸能够请到中国移动、国家电网、银联、ebay、德国电信、顺丰等案例的技术代表来分享他们的实践经验,一方面希望大家能够更多地了解OpenStack的价值,另一方面也是希望能够让其他用户在应用OpenStack的时候有所借鉴少走弯路。我经常会遇到一些OpenStack用户通过微信或者电话找到我,甚至是半夜打电话过来,说自己在使用OpenStack的过程中遇到一些棘手的问题,很着急。有很多都是我们在其他项目中遇到过的问题,有些是一开始架构设计上就有问题,而这些大多是可以总结出来经验有章可循的,我一个个解答,费时费力,我个人知识面也有限,莫不如把国内的一些成功用户叫到这个会上来,给大家讲一讲他们的架构是怎么设计的,怎么发挥OpenStack的优势来提升他们业务的,期间又遇到过哪些问题,怎么解决的。

同时我们也非常荣幸能够邀请到的几位Core,就是我们平时谈论的“社区大神”,Core在OpenStack里面有两个含义:核心开发者和代码审核者,总之是社区里面非常核心的技术人物了,许多人在国际上都享有盛誉。把他们请来,让大家听听国际一流的开发者是如何理解和构建OpenStack的。

特别要提一下Mirantis的高级技术总监Gregory Elkinbard,大家如果关注OpenStack可能知道,Mirantis在中国的活动前几天刚告一段落,所以他们本来近期是没有来中国的安排的,Gregory Elkinbard是专程从美国赶来参加咱们这个会议的,这个非常难得。因为从美国过来开会很辛苦,包括我现在都不太想去美国出差,太远了,坐飞机十几个小时加上完全颠倒的时差,确实很辛苦,我们要感谢Mirantis和Gregory Elkinbard对中国云计算技术大会和OpenStack技术峰会的支持。

距离中国云计算技术大会的开幕只有最后1天,票所剩无几,欲购从速

2018-11-17 13:57:16 csdnnews 阅读数 87

640?wx_fmt=gif

11月10日,UCan下午茶武汉站的活动在武汉青年光谷咖啡馆召开,在此次沙龙上,UCloud文件存储研发工程师邓瑾、块存储研发工程师叶恒、奥思数据创始人兼CTO李明宇、深信服科技存储研发专家卢波四位存储专家为到场的近百位观众详细讲解了分布式文件系统和分布式存储的技术原理和应用实践。

640?wx_fmt=png

UCloud分布式文件系统产品架构解析

UCloud存储研发工程师邓瑾首先就UCloud分布式文件系统产品架构进行了解析。

640?wx_fmt=png

分布式文件系统简介

邓瑾表示,分布式文件系统从概念上来说,就是经典文件系统的一个延伸,通过一些分布式技术,包括现在公有云的规模,带来了传统文件系统所不能达到的功能和特性。分布式文件系统的经典能力,第一是Scale Out,这是分布式系统的经典特性也是其基本门槛,Scale Out能在文件系统上带来线性或者近线性的容量和性能的提升。第二,通过分布式技术,依靠多副本、分布式协议、一致性协议,分布式系统可以提升单节点不能提供的高可用性和高可靠性,让上层系统可以屏蔽硬件上的故障。第三,通过公有云厂商的规模效应,它能够给应用层的用户提供比较低的TCO。

邓瑾接着回顾了比较经典的几种系统,他表示,最早期的分布式文件系统是谷歌File System,以及基于GFS开发的一个开源的文件系统HDFS,它是一种面向高吞吐场景的文件系统,它还有一个特点,就是它是一种索引,并且有一些管控节点是中心化的。

第二类系统是淘宝的TFS或者是Facebook的Haystack,它们是小文件的场景,而且是一类存放图片的对象存储系统,一个图片写入之后就不会修改了。

第三类系统是GluesterFS和CephFS,它们的共同点是都是开源的,设计理念是基于去中心化的,基于动态算法来决定存储系统的寻址,这也是大型系统比较流行的设计理念。

第四类是通用存储系统,一类是以微软Azure Blob Storage为代表的,包括阿里的盘古也是这套系统,它通过一个底层拓展性非常强的一个统一存储的接口,来支撑上面不同的业务,微软的Blob Storage都是靠这套系统来支撑的。

第五类是一些比较特定场景下的文件系统,它也是一种比较典型的设计理念,例如WAFL和PolarFS,它们都是为某些特定场景优化的,PolarFS是阿里云的一款底层的存储系统,支持的就是PolarFS对底层系统的要求所具有的特定的一些特点。

邓瑾还比较了对象存储、KV和文件存储三大类存储系统,他表示,对象存储在设计上其实是比较简单的,它是一种immutable storage,写一次后面再不会改,但是可以多次的读,例如,S3,它天生基于面向Web的优势,现在与CDN的结合,整个生态非常广泛,应用也非常广泛。但是对一些传统的应用,它需要做改造,或者需要在客户端上把这个API传成对象存储的API。对于传统厂商,比如说医院的设备,就不太愿意做这个改造,对象存储可能有一些劣势,但它的优势是文件大小没有上限。

KV的特点就是面向一些递延式场景,因为它通常会用于一些缓存场景,KV系统有非常多的变种,因此在KV选择上提供了非常高的灵活性。但是一般来说,KV系统存储容量不会太大,因为它追求高效性。

文件存储最大的优势是有一套通用的文件API,现在能够比较接近模拟API的是NFS接口。文件存储规模可以很大,而在用单机文件系统的时候,到TB级或者百TB级就会遇到瓶颈,这个瓶颈不仅是容量上的,还有处理能力上的。分布式文件系统系统主要致力于解决消除这些瓶颈,提供一个高可用的服务。

640?wx_fmt=png

UFS发展历程

邓瑾表示,UFS是一个UCloud在前年开始研发的一个完全自主研发,面向公有云设计的一款分布式文件系统,公有云产品有非常多的类型,因为一些特定需求,在公有云场景下,怎么把这些主机融入到分布式文件的访问客户端之内,都在UCloud文件系统设计的范畴之内。

从功能上来说,UFS现在支持V3和V4,2019年会支持Windows SMB系列,UFS的基本使命是给客户提供高可用、高可靠的存储服务。UCloud有一些比较典型的产品,这些产品与对象存储、KV存储有一些区别,它有四类场景,首先是容量型文件存储类场景,即备份场景,  再就是数据分析类场景,像Hadoop数据分析平台,广电的渲染,在高性能的文件存储上都可以得到应用。第三类就是数据共享。第四类对开发者比较有用,适用于实现Layer storage,上层做一个中间层,冗余可以丢到下层,如果文件系统可以提供高可用、高可靠数据服务的话,甚至可以把它当成一个选址服务,这是对开发人员比较大的支持。

邓瑾表示,UFS的设计是利用开源软件GlusterFS快速在公有云环境中进行产品原型验证,然后从运营角度积累分布式文件产品在多租户的公有云环境中的痛点和难点,进行自研产品的设计改进,同时吸收社区经验,经过这样的过程,UFS 1.0诞生了。

640?wx_fmt=png

1.0整体架构

UFS 1.0首先是一个索引和数据分离的架构,它是对传统文件系统一个最直接的延伸,它不采用中心节点存储索引,而是直接把文件系统概念在分布式磁盘上模拟出来。另外,UFS 1.0的索引有一套索引管理系统,有着自定义的索引结构和语义,这将便于后续拓展非NFS协议。同时,它还具有独立设计的存储服务,并支持set管理、灰度等策略,还支持百万级大目录和TB级文件大小,也支持QoS,对多租户场景下用户的访问也做了一些隔离。最后,相比GluserFS来说,UFS 1.0数据安全性较高。       

640?wx_fmt=png

上图是UFS 1.0的整体架构,它有一个管理平面和一个数据平面,在数据平面,左边是用户访问入口,用户在他自己的网络专区,会有自己的很多主机,包括虚拟的云主机,物理云主机,托管云主机等等,都是通过VPC网络来访问接入服务,接入服务会通过UCloud的ULB负载均衡器,然后把流量导入接入服务,接入服务就是图上的NAS。

它的特点非常明确,是一个无状态的服务,包括NFS协议本身,这实际上是为了提升故障恢复的时候,客户端的启动不需要去记忆一些信息。对比单机文件系统,它也有两类功能,一类是索引,包括寻址的功能,另一类就是数据访问操作,UFS 1.0把这两类东西抽象成两个部分,紫色部分叫system index,包括目录索引,文件索引两部分。下面是数据集群,存储文件的数据,在里面做一些多副本、高可靠、高可用的文件。

640?wx_fmt=png

索引层

如下图所示,在索引层主要就是模拟两个概念,一个是目录树,传统文件系统一个比较大的特点,就是它会有一段目录树,在下图右边有一个DIAdex,把整个目录树模拟下来。左边比较简单,它不会有层级结构,而是KV平台的结构,它会把文件需要的一些属性记录下来,这里最关键的是它跟下层的数据层会存在同一个链接中,这里会记一个FH,叫做文件距离。

640?wx_fmt=png

这里面比较重要的一点,是如果去做一个文件或者目录索引,非常简单,就是实现一个文件和目录操作就可以了。但是它面临的一个很大的问题,如何做到水平拓展?在多节点的操作上怎么保证原数据操作的一致性?因此,UFS 1.0会把它分成很多范围,某个文件可能会在A节点上处理,某些文件在B节点上处理。因为在分布式系统当中,经常会遇到宕机,或者网络导致的节点丢失,可能某个节点就没法访问了,这时候就需要维护一个租约,这个租约会定期续约,保证系统对这个节点的某个范围,或者某个文件有处理权限,当失去这个租约的时候,必须把自己从集群当中踢掉,否则会出现两个节点都对同一个文件进行操作,就会破坏后端文件系统的结构。

USF 1.0就是靠这一套系统来实现了之前一些单机文件系统不能提供的一些功能,包括处理能力的线性拓展,因为节点处理空间非常大,几十万甚至上百万的节点对它进行调度,也可以依赖它来实现一个大文件和大目录的支持,这主要还是模拟单机文件系统的概念,UFS 1.0会把一个大文件分成很多二级或者三级的一小段一小段的数据,存到这个索引中。

640?wx_fmt=png

数据层

在数据层,一个文件存储需要经过以下过程,首先,用户从主机发一段数据到NAS接入层,UFS 1.0会把流失的数据,就是FH代表的文件,按4M进行切分,每4M生成一个独立的IO请求发往存储层,存储层会做一个模拟,把这4M进行切分,切成64K。文件切分主要是考虑如果把一个大文件直接往存储集群上落,磁盘空间可能会不足。因此,需要把它打散,打散有两个好处,一是存储会落在各个地方,IO比较平均,也不会有特别大的热点。另外,这样可以充分利用整个集群的容量。

之后在存储层,会把整个集群分成很多个,因为它本身有很多机器,每个机器上有很多磁盘,UFS 1.0把每块磁盘分成很多个chunk,把空间分散之后,还会带来一个好处,当发生某个chunk有热点的时候,可以把它调到别的地方去,但如果chunk非常大,调度也没有特别大的意义,所以要先做一个chunk切分,每个chunk有三个副本,这三个副本组成了chunk group。当一个IO请求进来的时候,这是一个最多4M的文件,会切成64K,每个64K会写到某一个chunk group上,这64K就并发往这些chunk gourp上去写。

下图就是存储层一个简单的模型,右边蓝色的就是多集群灰度管理的系统,它可以暴露给前端业务,说明有多少集群可用。紫色的index是记录4MB分片切成64K的一个对应关系,为什么要存这个呢?因为必须要知道这个64K是存在哪个chunk的,通过查询它在哪个chunk,再去定位到真正的chunk所在的三个副本当中的任意一台机器。

640?wx_fmt=png

640?wx_fmt=png

UFS 1.0的局限

邓瑾介绍,UFS 1.0运营了一段时间后,发现这个存储模型,因为支持NAS的一些随机或者覆盖写引入小分片的概念,但这个分片太小了,导致存储层那边很难模拟一个超大文件。 然后就是底层的存储,它是一个固定的64K,不管写不写满64K,都要占用64K,这在规模很大的时候,会形成一定的空间浪费。第三是存储层支持的文件尺度较小。第四就是对随机写的支持不够,在做FIO,做4K这种写的时候会发现延时会比较高。

640?wx_fmt=png

UFS 2.0存储架构

针对UFS 1.0的局限,UCloud进行了2.0架构的升级,主要对存储层进行了优化,优化不仅仅针对NAS服务,而是进行了面向统一存储场景的整体设计和优化,它支持超大文件,冗余机制也更灵活,同时,它通过与新硬件和软件技术栈的结合来实现低延时高性能的场景。

640?wx_fmt=png

Append-only模型

在底层的Stream layer,是真正的统一存储的概念。每个存储的文件,称为Stream,每个Stream是永远可以追加写的,但是它分成了很多小分片,叫做Extent,UFS 2.0把这个Stream切成了一大段一大段很大的Extent,而且只有最后一个Extent是可以进行追加写的,中间一旦写完之后就再也不能改变。它带来的好处,是这种模型非常简单,不会担心数据篡改或者曾经写过的数据被覆盖掉,或者没有办法回轨,因为Append-only可以很好模拟快照功能,有整个操作的历史记录。每个Extent被分配三个或者N个多副本,会满足一定容灾的要求,来保证副本的高可用。

640?wx_fmt=png

每个Extent是以文件的形式落在存储介质上,文件可能会比较大,现在是4GB一个Extent。用户在写的时候是以Block为单位,往Extent上面追加,这个Block是不固定的,每次往里面追加写之后,Extent觉得达到一定的量就可以关掉,再新开一个,这即是Append-only整个的模型。

640?wx_fmt=png

数据层

Append-only模型里有几个模块,绿色的streamsvr,它管理Stream的功能,做Stream的创建,分配副本,副本所在的位置等。它会把原数据存储在数据库当中,Streamsvr会有一个master对外提供服务。Extentsvr做一些数据的持久化。

640?wx_fmt=png

Extentsvr的存储引擎设计有两个功能,一是消除写入毛刺,另一个是功能持久化一些还没有落地的索引更新或者是更新操作。数据来了之后,会先落,然后更新,把它放在内存里,这个时候就可以返回成功了,业务侧就可以收到,进行访问。FileLayer的机器是高内存的,可以对数据进行缓存,它可以把整个热点给打散,降低单节点访问压力以及数据读取的毛刺。FileLayer还把整个底层Stream提供的存储空间切分成很多个数据单元,以便于做负载均衡。

针对随机写,依然是利用底层的方式,把数据先追加下去,追加是追加在Date Uint(DU)提供的文件上,这样就可以直接反馈给用户这个随机写完成了,而不需要去读老数据进行合并。带来的开销可以通过软件方法去优化它。此外,针对没有办法结束对DU写的问题,会对数据进行分片,每个分片的最小颗粒度是100GB,每个DU只有一个fserver进行处理,从而实现随机写逻辑。

640?wx_fmt=png

分布式存储中的数据分布算法

奥思数据创始人兼CTO李明宇则具体讲解了分布式存储中的数据分布算法,他的讲解分为四部分:一致性哈希算法及其在实际应用中遇到的挑战、典型的“存储区块链”中的数据分布算法、典型的企业级分布式存储中的数据分布算法以及比较和总结。

640?wx_fmt=png

一致性哈希算法及其在实际应用中遇到的挑战

李明宇表示,常见的在分布式系统中的数据分布式算法,就是一致性哈希算法,一致性哈希算法在实际应用中会遇到很多挑战,一方面是应用在云存储或者企业级存储里面的挑战。另外就是在比较新的一些研究方向,比如说区块链或者区块链存储等的方面,也会遇到一些挑战。

640?wx_fmt=png

哈希表及其在分布式系统中的问题

如果用一致性哈希做数据分布,经常会用到数据结构是哈希表,哈希表是把一个空间划成N个区域,比方有一个字符串,假如这个字符串是一个文件名,根据这串字符串,会得到一个哈希。现在假如说有八个存储位置,那么,这些数据会放在哪个存储位置呢?哈希算法正是有着这样的作用,因为哈希具有非常好的随机性,因此,通过哈希算法对文件的文件名字符串进行哈希,就可以把这些数据均匀地分布到六个设备上。

但这种算法看起来很好,却会带来一个问题,因为在分布式存储里面,随着存储的数据越来越多,系统可能就要扩充节点。而这时如果用哈希算法来算,很多数据都需要重新去分布。而当增加的节点越来越多时,几乎所有的数据都要去移动,数据迁移的开销是非常巨大的,系统将会无法承受。为了解决这个问题,有人发明了一种算法,将存储平面圈起来,形成一个哈希圈,首尾相接,这样就可以让增加的数据更均匀的分布在设备上,而且不需要移动太多数据,比传统的哈希表好很多。

640?wx_fmt=png

但即使是这样,如果需要增加一块硬盘,还是要移动很多数据,为此,就引入了虚拟节点的概念,一块盘不再对应一个位置,而是对应多个位置,这样,从概率上,分布的均衡性就会好很多。此外,当有硬盘出现故障需要退出时,这种方法也会分散数据迁移的压力,这就是一致性哈希算法。一致性哈希算法具有不需要查表或通信过程即可定位数据,计算复杂度不随数据量增长而改变,效率高、均匀性好、增加/减少节点时数据迁移量小等优点,但在企业级IT和存储区块链场景,仍然面临很大的挑战。

企业存储会用到一些方式,比方说多副本,如果随机找几个位置去分布,很可能会造成副本落在同一台服务器上的情况,这种情况,企业级IT是无法容忍的。还有在存储区块链场景下,它需要用到全球的资源,让大家自发参与进来,组成一个跨全球的大的分布式存储系统,如果在这里面根本不知道有多少设备,也无法控制所有设备,如果来了一个存储对象,算出了一个哈希值,就不会知道这个哈希值究竟会映射到哪个设备上,因为这个设备可能随时出现,随时退出,是全球参与者自发参与的,无法控制。所以几乎不可能获得一个全局视图,而且一致性哈希环中的设备是随时都会发生变化的,甚至没有一刻是稳定的,这将带来很大的问题。

640?wx_fmt=png

典型“存储区块链”中的数据分布算法

那么,存储区块链刚才说的这种场景,应该怎么解决?在此之前,首先需要清楚存储区块链的概念,它是分布式存储或者去中心存储或者P2P的存储加上区块链,它的目的是通过区块链的机制,通过token的机理,鼓励大家贡献存储资源,一起组成一个大的存储系统。存储区块链的代表项目有Sia,Storj,IPFS+filecoin。

但如果是全球用户自发参与,就没有去中心化的存储系统的寻址和路由的问题,但因为参与者随时可以加入和退出这个网络,就需要解决这个问题,这在历史上已经有一些代表算法,比方说Chord、Kademlia等等。

这些算法,实际上最根本的还是一致性哈希算法,Chord更难理解一些,如果有一个数据要存储,这个数据文件名是K,数据相当于是V,整个P2P存储网络里面有一些节点,这些节点算出来的哈希值是14、21、32、42等,如果算出来哈希值是10,它比8大,比14小,它就应该顺时针放到8和14之间的节点上,以此类推。在一个真正的P2P存储网络中,节点数量是众多的,所以按照这样顺时针存,和一致性哈希没有任何区别。现在问题是,在没有任何节点知道到底有哪些节点参与到这个网络中时到底应该怎么办?Chord采用的方法是,既然没办法维护,就不维护,如果有一个数据,K就是其文件名,算出来的哈希值是54,那么,它先不管数据到底存在哪儿,首先和最近的一个节点比较哈希值,如果比临近的大就继续往下寻找,如果比自己的小,就存储在该位置,并进行反馈。这样,新加的节点并不需要其他节点知道,因为新加入的节点会向周围的节点去广播自己的存在,按道理说,总有概率说有些节点知道是新加入进来的,这样找下去,总是能找出来。

640?wx_fmt=png

Chord

但这样的算法非常低效,一圈下来,延时很高。而降低这个延时有两种办法,一种办法是多存几份,降低延时的同时能提高可靠性,Chord中的一个最大的改进是Finger table,它不仅仅记录自己的下一个节点,最临近的节点,还记录自己的2的i次方加1的那个位置,这个i的最大值就取决于Finger table用几位来表示产生的索引,所以它能够记录最临近的,最远的,或者说是一半远的,1/4远的,等等的节点。这样的话,如果要搜索一个数据,就没有必要像刚才那样挨个去找,可以直接进行跳转,这样就把计算复杂度降低了,这就是Chord算法。

640?wx_fmt=png

640?wx_fmt=png

Kademlia    

在此基础上还有另外一个算法,就是Kademlia,它跟Chord算法比起来有几个不一样的地方,首先计算距离的时候,并不是在用数值的大小去计算,而是用XOR计算,因此计算的复杂度就会降低。另外一方面,它设计了一个数据结构叫做K-桶,比如当前节点的id是0011,最近的节点是0010,所以它就用这种方式来表示距离,而在寻找的时候,其方法是与Chord算法是形同的。

640?wx_fmt=png

另外与Chord相比,它支持并行搜索,这样就解决了没有全球视图的问题。因为不需要掌握全局到底有哪些节点参与的情况,每个节点都会周期性的向周围发请求,如果有节点退出,就会被发现。如果有新节点加入,新加入的节点会往临近节点广播它的存在,所以也会被发现,节点之间互相可以联系上。

640?wx_fmt=png

典型的企业级存储中的数据分布算法

具体到企业级存储里面,这个问题变得更加复杂,关于企业级存储中间典型的数据分布算法也有一些,比如像Dynamo里有Amazon,Ceph里有CRUSH的算法等等。这些算法都有一定的相似度,都是要对数据算哈希,对数据的K算哈希等等,然后再做映射关系。这些算法还引入了对数据中心物理拓扑的建模。比如Cluster Map,一个大的存储集群,分几个数据中心,每个数据中心下面可以再分zone,zone下面再分机柜,机柜下面再分节点等等,它会把这种拓扑结构给记录下来。这样的话,数据的分布就会根据Cluster Map分布到不同的故障域里面,这样当一个故障域出现问题的时候,数据不会丢失,数据仍然可以访问。这些算法中还有对节点划分的权重,数据分布和容量/性能匹配,辅助扩容以及多种存储策略选择。

李明宇最后表示,归根到底,各种算法的源头都是一致性哈希,因为不同的需求,有不同的改进方向。企业级的更注重副本故障域的分布,对于P2P存储更注重在节点随时退出随时加入的情况下,怎么样保证数据能够在有效时间内寻址。

640?wx_fmt=png

云硬盘架构升级和性能提升

UCloud块存储研发工程师叶恒主要就云硬盘架构升级和性能提升进行了讲解。

640?wx_fmt=png

云硬盘架构升级目标

叶恒首先介绍了云硬盘架构的升级目标,第一,解决老架构不能充分使用后段硬件能力的弊端。第二,支持SSD云盘,提供QoS保证,可以用满后端NVME物理盘的IOPS和带宽性能,单个云盘可达2.4W IOPS。第三,充分降低热点问题。第四,支持超大容量盘,一个云硬盘可以支持32T,甚至可以做到无限扩容。最后就是新架构上线之后,怎么样让老架构迁移到新架构。

640?wx_fmt=png

IO路径优化

而叶恒认为要达成这样的目标,首先需要对IO路径进行优化。下图是新老架构的架构图,主要是IO路径上的,左边是旧架构,VM、Qamu,云硬盘是挂在虚机里面的,通过虚机来到Qamu的驱动,然后转化到Client,Client之后会将IO转到后端的存储集群上,分两层,第一层是proxy,IO的接入层,然后再分到chunk,就是读写一块磁盘,后端的chunk是一个副本的形式。

640?wx_fmt=png

640?wx_fmt=png

而在新架构中将IO的接入层去掉,直接将路由的功能做到client,直接连接到后端的存储节点。这样的话,在写的时候,从client直接到chunk,因为三副本内容是完全一致的,读只要读主chunk就可以了。因此,读路径上就减少了一次网络转发,相比于老架构的话,由于软件的升级,随机测下来,写延时也有所降低。

640?wx_fmt=png

元数据优化

在老架构中,分片大小是1G,新架构中,支持了1M大小的分片。1G的分片最多只能发挥一块物理磁盘的性能,对于普通硬盘,它后端的存储介质是机械盘,性能有瓶颈。1M的分片会带来很多好处,首先解决了热点的问题,还可以充分发挥后端集群性能,因为1M的分片,如果客户的写在1G的范围内,端能用到1024的分片,整个集群的性能就会全部发挥出来。

在数据组织方式方面,在老架构中,按索引的方式来组织元数据,申请一块云盘时,所有元数据分配成功,并持久化到元数据模块,挂载云盘时,将所有元数据load到内存中,后续IO访问直接从内存获取路由。这样看起来似乎没有什么问题,但在并发创建和挂载的情况下,如果有几千个盘同时挂载,如果按1G的分片,300G的云盘,300条的元数据,按1M的分片,300G是30万条,它同时创建100块300G的云盘,需要分配3千万条元数据,挂载也是一样的,同时要从元数据模块加载3千万条数据,这对元数据模块的设计难度是极大的,它会成为一个瓶颈。

因此在设计过程中,考虑过多种方案,方案一仍然保持带索引的存储方式,但在创建的时候不分配,把元数据延时分配,只有当云硬盘上某个分片上有读写的时候,才向元数据请求,这样的IO延时分配,好像是能解决问题。但如果这个时候用户开机了,几千台一起开机创建好了,想做个测试,或者开始用了,同时对这100块300G的云盘做一个随机的写,随机的写会落到每个分片上去,这样看,元数据模块仍然是个瓶颈。

第二种方案,选用了一个一次性哈希,一个节点下线了,但是没有机会去迁移或者分配到同一个故障率里面去,这时通过后端的chunk服务,按三个三个一组,组成一个所谓的PG,PG就是备份组,将这个备份组作为物理节点,因此,物理节点就不是一个存储节点了,而是一组备份级。当这个组作为物理节点插到这个环上之后,会作为虚节点放大,放大三、四千倍,保证这个环大概在几十万左右,不能超过百万,因为构建这个环需要时间,如果这个环太大,重启时间就会过长。而且这三个chunk也不是随便写三个chunk,按照容灾的策略,这三个chunk组成一个PG,分别在三个机架中,如果机架断电,最多影响一个。

把这三个chunk组成一个PG作为物理节点插入到这个环上,然后一个节点放大成几千个虚节点,用户创建一块盘,上面每个分片派来IO之后,用这个盘唯一的ID,加上这个分片,去做哈希,哈希之后落到中间,找到了PG之后,它里面包含了三条chunk的路由,将这个IO转发到后端的主节点,由主节点去同步,主节点直接返回就可以了。

640?wx_fmt=png

通过这个方案,以前动辄几千万的数据量,就是PG的个数,后端是chunk的一个路由,然后就是构建这个环的几个参数,一个是映射的算法,一个是虚节点的放大倍数,以及冲突解决参数。这样当云构建起来之后,向元数据模块请求这几个参数,最多是几千条,之后再构建这个环,这个环构建好了之后,有IO过来的时候,只需查这个环。而当查第一次的时候,系统会把计算好的路由记住,最后就可以直接找过去,非常快。这样的话就完全解决了上述问题,同时创造几千个盘是完全没有问题,同时读写也没有问题,这时因为读写过程中不需要去分配,因为全是计算出来的。

640?wx_fmt=png

线程模型设计

具体到软件设计就是线程模型设计,我们知道HDD与NVME性能差别有几百倍。原来的软件设计用一个线程就可以,一个CPU用满的话,一个核跑几万没有问题。但现在的软件没办法去发挥这种硬件的能力,所以需要改变线程的模型。

在新的架构中,在云端,采用了多线程的方式,每挂载一块云盘的时候,会分配一个线程专门用于IO转化,后端是线程池,main eventloop就是IO线程,当某一个分片查这个环,发现要跟后端的某个chunk通信,第一个连接分配到IO路径1,循环派发,整个IO线程负责的连接就是均匀的。假如一个IO线程跑满能跑5万IOPS的话,现在跑130NVME,用它来管理线程30万的NVME的话,六个这样的线程就可以了,完全可以发挥硬件的性能。

640?wx_fmt=png

640?wx_fmt=png

防过载策略

任何一个存储系统,都有一个过载保护的功能,比如说挂载了几千块盘或者几百块盘,用户同时测试,落在存储的某一个硬盘上,并发有几千NVME,如果不做过载保护,IO将会全部超时。在新架构中,对于普通的云硬盘,会限制物理盘上IO提交队列的深度。

在实际代码实现的时候,要考虑到权重,云硬盘的大小不一样,大的云硬盘,用户要多付费,更大的云硬盘,会获得更多的发送机会。对于SSD云盘,传统的单个线程会是瓶颈,难以支持几十万的IOPS以及1到2GB的带宽。新架构会监控每个chunk的IO线程CPU的使用率,如果发现长时间CPU使用率都是95%或者100%,就会去通知这个chunk,断开IO线程里面一部分连接,分配到其他线程,实现了负载均衡的效果,使得每个线程的压力都是均匀的。

640?wx_fmt=png

在线迁移

叶恒介绍,为了帮助用户从老架构向新架构迁移,UCloud为用户提供了一套在线迁移系统,在进行迁移时,首先要把下图中上部的clond old断掉,连上trons cilent,同时写一份到新老架构,然后通过trocs模块,当所有的存量数据都搬迁完成之后,这一次迁移就完成了。迁移完成之后,qemu就可以跟trons cilent断开连接,连上一个新的cilent。这样在迁移的过程中即使出现什么故障,重启之后,老架构仍然可用,从而降低了迁移的风险。

640?wx_fmt=png

640?wx_fmt=png

超高性能云盘

叶恒还介绍了UCloud正在研发的下一代超高性能的云盘,单个延时可以降低到100us,IOPS单盘可以突破百万。而要达到百万的IOPS的话,则需要用到用户态、zero copy、polling mode,这几个技术。用户态就是把原来在内核态做的事情,比如网卡驱动,磁盘驱动,拿到用户态来做,直接在用户态操作设备。polling mode,是为了解决CPU与存储硬件的性能差异,使用polling mode,将会大大提升性能。zero copy,是指原来数据发一个包,需要从这个态拷到那个态,但现在完全在用户态操作硬件的话,就是零拷贝,可以直接发出去。

UCloud是全链路的改造,因此,client端用了VHOST,网络端用RDMA,后端提交用SPDK。分别看一下这三个技术,在clinet端,原来数据从qume拷贝,现在数据直接VM,直接与clinet共享,这样,只要做虚机的物理地址到后端物理地址映射,直接通过共享内存的方式就可以了。    

在网络通信部分,采用RDMA,DMA直接访问内存,绕过CPU,从而降低CPU的使用率。RDMA直接访问远端的内存,这样就实现了通信的作用。

在后端,直接是SPDK,SPDK直接从用户态来操作固态硬盘,当挂一个盘到机器上,在内核里看不到,通过采用polling的方式,实现零拷贝,IO提交的延时非常低。

叶恒透露,在测试中,该高性能云盘,单盘IOPS突破了百万。预计此款超高性能云盘将会在12月底推出公测版。

640?wx_fmt=png

基于Cephfs的改进及优化

深信服科技存储研发专家卢波最后一个登场,他就Cephfs的改进和优化进行了详细的分析。

640?wx_fmt=png

Ceph及CephFS的背景

卢波表示,Ceph是分层的架构,底层基于CRUSH,Ceph分布的策略是针对分级的哈希,跟一致性哈希有区别,它是区分故障域的,分了两级,第一级是对象到PG的映射,就是根据对象进行一个哈希值,然后根据PG数举模,最后得到这个数据对象分布在哪个PG上面。PG到Ceph底下,它的每一个存储设备OSD,叫做对象存储设备,PG到OSD之间,就是通过CRUSH算法来进行的路由。它的底层是基于RADOS,它是可靠,自动的分布式的一个对象存储,具备的特性可以自修复,迁移,容错,上层提供了对象存储、块存储和文件系统访问三种方式。CephFS支持多种协议,最早起源于2007年Sage Weil的博士论文研究,最开始Ceph针对的应用场景更多是针对高性能计算,需要高扩展性大容量的文件系统。

像Ceph这样的分布式操作系统的出现,源于传统单机文件系统的局限,第一是共享没办法在多个机器中提供应用访问。第二就是单个文件系统容量是有限的。第三是性能,传统的文件系统它可能没办法满足应用非常高的读写性能要求,就只能在应用层面做拆分,同时读写多个文件系统。第四是可靠性,受限于单个机器的可靠性以及单个硬盘的可靠性,容易出现故障导致数据丢失。第五是可用性,受限于单个操作系统的可用性,故障或者重启等运维操作会导致不可用。

而这些特点对于企业级的应用或者私有云来说,是无法接受的,在这种情况下,就出现了CephFS。CephFS最早是一个博士论文研究,它实现分布式的元数据管理以及可以支持EB级的数据规模,后续专门成立了一个公司来做CephFS的开发,在2014年被Redhat收购,2016年CephFS发布可用于生产环境的稳定版本发布了,目前主要应用还是单MDS。

640?wx_fmt=png

CephFS的架构

CephFS的架构不只是CephFS,包括Ceph也在里面,第一个部分是客户端,第二部分就是元数据。文件系统最核心的是数据,所有文件的访问,首先离不开源数据的访问,与块存储不一样,块存储就是直接指定哪个硬盘的哪个位置,有了地址,就可以去读取那个固定的数据。但Ceph的文件系统是有目录结构和层级结构,要管理这样的目录结构,需要通过元数据来实现。

640?wx_fmt=png

Ceph MDS也是元数据架构,可以理解为它是一个元数据的缓存,是一个元数据服务,本身并不存储数据,它最终的数据是存在底下的RADOS的集群下面,MDS本身是不存储数据的。当客户端要写一个文件,首先要打开这个文件,这个时候客户端会跟MDS通信,去获取它的距离,客户端拿到之后,通过一个哈希,找到它位于哪个PG里面,直接通过计算的方式,不再需要去跟MDS交付,确定了哪个PG之后,再把数据发到对应的数据值上面去,并且它的元数据和数据是分开的,可以存在不同的存储池中,这种设计也是分布式文件系统设计的跟传统文件系统不一样的地方。

640?wx_fmt=png

MDS的作用

MDS作为元数据的缓存,同时控制元数据的并发处理,主要的作用有下面几个:第一,要提供文件资源,要对客户端以文件的方式,同时兼容POSIX的语义。第二,要提供一个文件系统命名空间,它要通过MDS能够构建出分布式文件系统的一个目录树,一个层级结构。第三,要管理文件的元数据,比如inode、dentry这样的文件元数据。第四,它需要持久化文件元数据,把元数据存储到一个可靠的存储设备上面去,在异常的情况下,保证这个数据是持久化的,可读的,不会丢失数据。

MDS具有并发控制的流程,多个客户端可以同时跟MDS通信,MDS通过一个锁来处理这个请求,同时客户端跟元数据交互的时候,除了获取元数据信息之外,它还要知道客户端是不是一个有效的客户端,这个客户端是不是能进行读或者写操作,以保证数据的一致性。

当MDS收到这样的请求之后,会通过lock machine的模块,去判断这个请求是不是可以正向操作,以及去覆盖刚才访问的权限,最后会把这个请求返回给客户端,然后会返回文件的元数据信息。

MDS是CephFS的一部分,另外CephFS还有三个点,MDS是实现元数据的分离,管理元数据,作为元数据的缓存,另外MDS是一个集群,可以有多个MDS,它是利用动态指数分区的技术,每一个MDS管理一部分的目录,一个MDS可能负责一部分目录层级,另外一个MDS负责另外一部分层级,这样它可以做到很好的扩展性,它的性能也能得到提高,达到一个线性提升的目的。当然,现在还是单MDS的方式相对可靠一些,这是未来的方向。

640?wx_fmt=png

Ceph的优化实践

针对Ceph的问题,最直接和比较常见的想法,是缩短它的IO路径,解决小IO的写放大问题,第二,当前Ceph的IO路径过长,延时高。第三,提升文件的元数据写操作的性能。第四就是支持写缓存的方式。第五,对读也可以通过缓存进行加速。第六,Ceph最早出现是针对廉价的节点或者是服务器来设计的,但是现在的技术发展,有些在设计之初没有考虑到,当然现在也在改进,这个优化也是能够充分利用SSD或者新的网络传输介质这样的优点来提高它的性能。

在业界,在这方面优化的思路有几种,OceanStor9000的缓存,是一个典型的分布式文件系统,它通过全局的缓存,来实现任意节点上的文件,它会对文件进行分条,任意节点收到数据访问请求之后,都会从这个缓存里面去看,是不是这个缓存命中了,如果命中的话,这个时候直接返回客户端。写的话,首先直接也是写到这个缓存里面,通过缓存的全局化,以后后台缓存数据的全局化,去实现性能加速。缓存的一个目的除了缩短IO路径,还有一个好处,是可以把小的IO合并,形成一个大的IO这样一起写下去。

Fusion storage的处理思路是一样的,也是用到了EC,如果是大IO直接写EC,大IO直接用硬盘的存储能力。但是小IO,就会通过EC Cache,写到Cache里面,这次IO结束了,就直接返回到客户端。但后台要保证这个Cache的数据最终持久化到HDD上面去,同时会进行IO的聚合。

Isilon是另外一个,这是NAS最早的一个产品,它里面缓存的分层分三层,第一是内存,第二层用到NVRAM的介质。第三层才是SSD。

Intel的思路是一样的,因为它的IO路径比较长,Intel提出了Hyper Converged Cache的思路,把这个开源了,这个思路是说,在客户端就是由SSD来进行读写加速,它把后端的Ceph作为一个慢存储来使用,在块和RGW场景中,作为读缓存没有问题,如果要作为写缓存,就涉及到冗余的问题,所以在它的设计里面,做写缓存的时候,是用到了DRBD这样的双拷贝,写到缓存里面的时候,会做一个多副本。

通过加了这样的缓存之后,可以看到Datrium公司基于这样的架构,做了一个缓存的实践,给出了一个性能,可以看到对于IOPS提升是非常可观的。这里有一个问题,多了一个缓存对于Ceph来讲是很难受的,为什么?因为通过DRBD的方式,可靠性还是比较差的,对Ceph扩展性是打了折扣的。另外一个,这个缓存要实现数据的持久化,不可能是主备的方式,因为这样也是会降低可靠性的,所以要实现这样的缓存,是要实现分布式的一个管理逻辑。

640?wx_fmt=png

卢波介绍说,针对这些问题,整体的思路跟前面几种产品是一样的,通过增加的块存储,来缩短IO路径,进而提高小IO的性能。但是这个缓存底下是一个分布式的使用场景,所以这个缓存本身也是一个分布式的缓存,下面是此架构的架构图。

640?wx_fmt=png

这个架构与Ceph相比,只是在中间多了一个OCS的缓存服务,缓存是一个独立的服务,从客户端请求,也叫做CA,是NFS过来的请求,都会转化到缓存服务上面来,在缓存服务里面,根据数据分布策略,就知道这一次操作到底要写在哪一个缓存节点上面去,选到这个缓存节点之后,缓存节点实现多副本的数据分发,等多处副本完成之后,再返回给客户端,这次操作完成,这是一个正常的写入流程。

写入之后,这个数据后台是会定期根据水准高低,把缓存的数据直接放到底层的Read存储上面去。一方面利用了缓存加速的性能,另外一方面,可以利用Read的全局化性以及它的扩展性。

读流程也是一样的,因为缓存对于小IO可以最大限度发挥空间的优势,但是对于大IO,不需要经过缓存,直接写到底层的Read上去。另外通过索引的方式,也可以知道具体写到哪个缓存节点上去,大体流程就是这样。而经过这样改进之后,该系统的IOPS确实得到了提升。

640?wx_fmt=png

Ceph未来展望

最后,卢波认为,CephFS最有杀伤力的一个东西,就是多MDS,即动态指数分区这样一个技术,这方面在社区也会有一些深度的开发和讨论,也在进行一些测试。下图就是多MDS的技术原理,多个MDS去负责不同的目录树的元数据访问,当客户端来请求的时候,会去到不同的MDS,在这个MDS里面,它去实现元数据的管理以及数据间的访问。这是多MDS性能的对比,明显可以看到,当8个MDS并发测试的时候,其性能基本上是可以达到线性增长的。

640?wx_fmt=png

640?wx_fmt=gif

640?wx_fmt=gif

2014-11-10 10:32:54 qq_21541063 阅读数 266
/*文件名称:weq 
*作者:李明宇 
*完成日期:2014年11月6日 
*版本号:v1.0 
*问题描述:最大公约数  
*输入描述:无 
*输出:最大公约数
 
*/#include <iostream>
using namespace std;
int gcd(int a,int b)
int r,g;
while (b!=0)
{
    r=a%b;
    a=b;
    b=r;
}
g=a;
return (g);
}
int main()
{
    int a,b,g;
    cin>>a>>b;
    g=gcd(a,b);
    cout<<"最大公约数是: "<<g;
    return 0;

}

没有更多推荐了,返回首页