MogileFS_系统_应用在EshangTu项目的可行性分析
MooseFS使用总结材料
MooseFS使用总结2010-12-08 12:55 阿炯流行的开源分布式文件系统比较我现在有海量的数据文件(1000万个文件)需要存储，需要让其他计算机可以很容易地访问，数据无价，我还希望这个文件系统带冗余功能。
我首先注意到的是Ubuntu Enterprise Cloud的提供者:Eucalyptus。
它提供了和AWS(Amazon Web Service)几乎完全兼容的云计算接口，看起来似乎是个云存储的靠谱解决方案。
Eucalyptus模仿Amazon的S3服务，提供了一个叫做Walrus的存储服务组件。
可是经过一番探索，我发现Eucalyptus想说爱你不容易。
一方面是因为Eucalyptus配置起来很麻烦，缺乏文档，网上几乎找不到任何相关帮助；另一方面，虽然理论上Eucalyptus和AWS的EC2/S3兼容，但实际上并非如此，很多在AWS上可以用的工具，在Eucalyptus上就无法使用最关键是，直到最后我把Walrus配置完成之后，才发现Walrus根本不像我想的那样，是一个带冗余的云存储系统。
而只是一个实现了S3接口的单机软件而已。
实际上Walrus和Eucalyptus的另一个组件sc(storage controller)没有任何关联，Walrus只是提供了和S3一致的接口，而它的实现方式，既不带冗余，也不能分开部署在多台服务器上。
于是我开始寻找一个真正的分布式文件系统，来解决我的存储难题。
一找才发现，市面上各种分布式文件系统品种繁多，层出不穷。
列举几个主要的：mogileFS：Key-Value 型元文件系统，不支持FUSE，应用程序访问它时需要API，主要用在web领域处理海量小图片，效率相比mooseFS高很多。
FastDFS：国人在mogileFS的基础上进行改进的key-value型文件系统，同样不支持FUSE，提供比mogileFS更好的性能。
mooseFS：支持FUSE，相对比较轻量级，对master服务器有单点依赖，用c编写，性能相对较好，国内用的人比较多glusterFS：支持FUSE，比mooseFS庞大。
基于 SiPESC 的千万节点规模 FEM 可视化系统设计与实现
基于 SiPESC 的千万节点规模 FEM 可视化系统设计与实现徐良寅;李云鹏;陈飙松【摘要】A high performance visual system for finite element model (FEM)with tens of millions of nodes is implemented,and the relevant algorithms,data structures,key techniques and software design framework are presented.Through the analyses of the features of 3D FEM and the general FEM visual system SiPESC.POST, the internal elements culling technology and refined data structures based on topology structure are proposed.And then,in conjunction with VBO rapid display technology,the developed visual system displays the FEM with tens of millions of nodes pared with several large commercial FEM software systems,the proposed system demonstrates its superiority in visual efficiency and feasibility for super large-scale problems.%实现了千万节点规模的有限元模型高效率可视化系统，提出了相关算法、数据结构、关键技术与软件设计方案.研发工作通过分析三维有限元模型特点，在 SiPESC.POST 通用有限元模型可视化系统基础上，提出了基于拓扑结构的内部单元剔除技术与精化数据结构，并基于 VBO 快速显示技术，实现了千万节点规模有限元模型流畅显示.通过与多个大型商业有限元软件系统对比，展示了该系统在可视化效率及大规模问题适用性方面的优越性.【期刊名称】《大连理工大学学报》【年(卷),期】2015(000)004【总页数】6页(P339-344)【关键词】SiPESC.POST;千万节点规模;可视化;内部单元剔除;VBO【作者】徐良寅;李云鹏;陈飙松【作者单位】大连理工大学工业装备结构分析国家重点实验室，辽宁大连116024; 大连理工大学工程力学系，辽宁大连 116024;大连理工大学工业装备结构分析国家重点实验室，辽宁大连 116024; 大连理工大学工程力学系，辽宁大连 116024;大连理工大学工业装备结构分析国家重点实验室，辽宁大连 116024; 大连理工大学工程力学系，辽宁大连 116024【正文语种】中文【中图分类】O242.21随着计算机计算能力的不断提高，多核并行计算技术、GPU(graphic processing unit)计算技术等新技术的不断普及，单机有限元分析规模不再局限于几万、几十万节点规模，达到以往必须借助大型服务器或集群进行分析计算的百万乃至千万节点规模．但与此同时，和有限元分析系统密切相关的有限元模型可视化系统却往往满足不了超大规模有限元模型可视化需求，即使大型商业有限元分析软件如MSC.PATRAN、ANSYS等在显示千万节点规模有限元模型时也十分卡顿，大大降低了用户使用体验．目前，在大规模数据可视化相关领域已开展了较多的研究工作．邹静等[1]针对三维有限元模型的特点，利用基于快速排序的重复元素剔除算法，实现了百万节点规模模型显示；孙青等[2]利用基于线性八叉树的LOD(levels of detail)层次细节技术，实现了海量数据的大规模三维城市模型可视化；邵思睿等[3]采用并行处理和LOD技术，实现了大规模粒子模拟结果的可视化．SiPESC.POST[4-5]系统是由大连理工大学运载工程与力学学部/工业装备结构分析国家重点实验室研发的面向超大规模有限元计算的通用可视化系统，基于平台(微核心)+插件体系结构，具有良好的开放性和可扩展性．SiPESC.POST系统包含用于管理有限元数据的有限元模型模块、用于管理显示所需数据的显示模型模块、用于将有限元数据转换为显示数据的过滤器模块、用于图形显示的渲染器模块和用于整体控制的控制器模块，已实现包括网格模型图、结果云图、位移变形图等常规有限元模型可视化功能．本文在可行性分析的基础上，综合考虑有限元模型特点和当前硬件显示性能，提出基于拓扑结构的内部单元剔除技术对过滤器模块进行优化，利用VBO(vertex buffer object)快速显示技术对渲染器模块进行优化，以实现单机千万节点规模有限元模型流畅显示．从有限元模型特点来看，得益于计算机计算能力的大幅提升，以往用于简化计算而大量使用的梁、杆、壳单元大多被实体单元所取代．这样一来，显示有限元模型时，如果可以剔除模型内部无法看见的点、线、面等元素，会大大降低显示数据量．以图1的标准立方体模型为例．模型完全由六面体单元组成，当节点数目达到千万规模时，总的单元数约为986×104，表面可见单元约为27×104，仅占总单元数的3%左右．其他常规模型，根据单元类型不同，具体形状不同，剔除内部元素后，数据量虽然减幅各不相同，但多能大幅降低显示数据量．计算机显示性能可分为以下3个方面：(a)硬盘容量任何有限元模型文件初始时大多保存在硬盘上，如果硬盘都无法存下，显示就无从谈起．千万节点规模的有限元模型文件(不包括计算结果)大小为1～2 GB．当前动辄TB级的硬盘，完全满足文件存储需要．(b)内存容量模型显示的第一步，就是把模型文件导入内存，并转换成图形应用接口所规定的数据格式，以便显示，因此内存容量也必须考虑．实测千万节点规模的有限元模型内存用量为3～4 GB，考虑数据转换过程中产生的中间数据，内存用量峰值可能达到5～6 GB，当前计算机8 GB内存已经普及，内存容量基本满足．(c)显存容量为了进一步加快显示速度，最好的方法就是把转换好的显示数据保存到显存里，这样避免了显示时频繁的内存、显存数据交换，提高显示效率．参照SiPESC.POST 系统显示数据结构，每个点需15 B，每条边需30 B，每个三角面需57 B．显示一个带边线、顶点的完整三角形面片需192 B，对于目前最常见的1 GB显存理论最多存储约500×104个完整三角形面片．从先前有限元模型特点分析来看，若不剔除内部元素，1 GB显存无法存储所有面片，只能将显示数据保存在内存中，大大影响了显示速度．剔除内部元素后，显存容量基本满足．经过可行性分析可知，想要在单机上流畅地显示千万节点规模有限元模型，有赖于有限元模型内部元素的剔除和显存的有效利用．针对这两点，本文开发和使用了基于拓扑结构的内部单元剔除技术和基于VBO的图形快速显示技术．2.1 基于拓扑结构的内部单元剔除技术有限元模型形状复杂多样，不可能简单通过单元位置坐标进行剔除．常规的有限元模型数据中，单元数据中含有节点连接关系，节点数据中却仅含节点坐标数据，未含共用该节点的单元信息，使得有限元整体结构的拓扑连接关系不全．SiPESC.POST系统使用过滤器管线[6]，如图2所示，通过一个个独立而有序的过滤器对有限元数据进行处理，并最终生成显示所需数据．过滤器模块在设计之初，就考虑到可扩展性，采用了工厂方法设计模式[7]和注册机制，如图3所示，可在不修改已有代码的基础上，进行动态扩展．为了生成节点单元连接信息，可在节点过滤之前，添加拓扑信息生成过滤器．而生成该过滤器仅需由基类Filter类和FilterDescriptor类进行派生，并向FilterManager类进行注册即可．当节点单元连接信息生成后，剔除有限元模型内部元素就变得十分容易．SiPESC.POST中所有的体单元显示时都会离散成三角形面片，剔除模型内部元素，就是剔除模型内部三角形面片．模型内部面片与表面面片的区分标准就是内部面片被相邻的两个单元共用，而表面面片仅被所属单元本身使用．流程示例代码如下：//获取3个顶点的节点单元连接关系，即每个节点上共用该节点的单元号QVector〈int〉 nodeelem1,nodeelem2,nodeelem3;nodeelem1=Node1.getElements();nodeelem2=Node2.getElements();nodeelem3=Node3.getElements();//以第一个节点为基础历遍所有共用该节点的单元号int samenum=0;for(int k=0;k<nodeelem1.count();k++){ //当3个节点同时含有一个单元号时，表明面片属于该单元if(nodeelem2.contains(nodeelem1.at(k))&&nodeelem3.contains(nodeelem 1.at(k))) { samenum++; } //面片同时属于两个单元时，即为内部单元if(samenum>1) break;}内部面片剔除后，显示数据量大大减少，使得单机千万节点规模模型显示成为可能．2.2 精化数据结构为了进一步减少显示数据量，对显示数据结构进行了精化，剔除与显示无关的数据项．精简后的数据分为点、线、三角面3种基础图元．顶点数据保存为顶点坐标数组和顶点颜色数组，结构如下：边线数据保存为边线坐标数组和边线颜色数组，结构如下：面片数据保存为面片坐标数组、面片颜色数组和法线方向数组，结构如下：精简后的显示数据不仅数据量大大减小，而且可以更快地导入显存用于显示．2.3 基于VBO的图形快速显示技术当显示规模很小，如几百、几千个三角形面片，使用下面示例代码依次绘制每个面片即可：glBegin(GL_TRIANGLES); glColor3f(1.0,1.0,1.0); glVertex3f(x1, y1, z1); glVertex3f(x2, y2, z2); glVertex3f(x3, y3, z3); … glEnd();当显示规模提高到几万、几十万个三角形面片，大量且频繁的图形接口调用成为显示瓶颈，大大降低了显示效率，这时如下面代码所示在内存中把显示数据进行整合，整体绘制，就能进一步提升显示效率．void* data=faces.data();glNormalPointer(GL_SHORT, 0, faceNormals.data());glVertexPointer(3,GL_FLOAT, 0, faceVertexes.data());glColorPointer(3, GL_UNSIGNED_BYTE, 0, faceColors.data());glDrawElements(GL_TRIANGLES, faceCount, GL_UNSIGNED_INT, data);当显示规模进一步提高到几百万、近千万个三角形面片，内存中整合好的显示数据量进一步增大，每次图形显示时，由内存到显存的数据交换成为显示瓶颈，大大降低了显示效率．VBO技术正是用来解决这一问题．VBO技术可将显示所需数据预先保存在显卡显存中，显卡绘制图形时直接调用显存中的数据，大大提升显示效率．示例代码如下：//准备VBOglBindBuffer(etarget, vboBuffers[faceIndexBuffer]);glBufferData(etarget, size, data, usage);glBindBuffer(atarget, vboBuffers[faceColorBuffer]);glBufferData(atarget, size, data, usage);glBindBuffer(atarget, vboBuffers[faceVertexBuffer]);glBufferData(atarget, size, data, usage);glBindBuffer(atarget, vboBuffers[faceNormalBuffer]);glBufferData(atarget, size, data, usage);//使用VBOglBindBuffer(atarget, vboBuffers[faceNormalBuffer]);glBindBuffer(atarget, vboBuffers[faceColorBuffer]);glBindBuffer(atarget, vboBuffers[faceVertexBuffer]);glBindBuffer(etarget, vboBuffers[faceIndexBuffer]);glDrawElements(GL_TRIANGLES, faceCount, GL_UNSIGNED_INT, 0);可视化系统基于SiPESC平台设计并实现，因此可与SiPESC平台中的其他模块相互协作，提供更多灵活、强大的功能．3.1 脚本语言调用传统编程语言，如C、C++、Java等，大多为编译式语言，即代码编写完成后无法立即执行，需编译成可执行程序后才能运行．这样一来，当软件规模较大时，完全编译一次耗时较长，给修改、调试带来不便．脚本语言则不同，其为解释式语言，代码编写后可立即执行，简单、灵活．SiPESC平台以C++语言开发，同时也提供了脚本语言支持，现已支持JavaScript 和python两种脚本语言．所有基于SiPESC平台开发的模块都能自动支持脚本语言调用．可视化系统也不例外．利用脚本语言丰富的功能扩展包，可大大增加系统的灵活性．以下面JavaScript代码/** 创建MObjectManager对象 */var omanager=new MObjectManager;/** 获取MesherSelectManager对象 */varselectManager=omanager.getObject(″org.sipesc.ui.mesher.mesherselectm anager″);var selectBuffer=selectManager.getSelectBuffer();var selectItems=selectBuffer.getSelectItems(1);print(″已选中的单元数：″+selectItems.length+″\n″);for(var i=0; i<selectItems.length; i++)print(″模型ID：″+selectItems[i].getModelid()+″ 单元ID：″+selectItems[i].getId()+″\n″);为例，可视化系统提供了点、线、面的拾取操作，通过脚本可获得当前选中的单元，得到模型ID和单元ID．之后，通过模型ID、单元ID既可以得到计算结果进行曲线绘制、模型校核等操作，也可以得到模型坐标进行模型变换、子结构拼装等操作．3.2 工程数据库千万节点规模有限元模型，仅单元网格数据就有几个GB，加上计算结果，常常到达TB(1 024 GB)级，一般的软件很难进行管理．SiPESC工程数据库模型具有TB级数据管理能力．集成工程数据库模块，使得可视化系统无须考虑有限元数据储存，专注于显示性能提升．为验证系统性能，选取了以下算例进行试验．试验机器内存8 GB，显存1 GB．使用Fraps显卡辅助软件，测试显示帧数．4.1 千万节点轮毂模型显示该模型包含1 004×104个节点，725×104个十节点四面体单元，模型文件大小为1.86 GB，整个显示过程中，内存用量峰值为3.8 GB，稳定后内存用量为2 GB．若不进行内部元素剔除，按每个十节点四面体单元离散为16个三角形面片，共有三角形面片11 600×104个，每个完整三角形面片需192 B计算，需显存20 GB，远远超出可用显存容量，无法显示．剔除内部元素后，表面三角形面片数仅为395 241个，需显存72 MB，可流畅旋转、放缩．分别测试了该模型在Patran、HyperMesh 和SiPESC.POST系统中的最大帧数：Patran 3帧，十分卡顿，即使在旋转过程中，取消边线以加速显示，最大帧数也仅为4帧左右；HyperMesh有无边线均为12帧，基本流畅，放缩时略有延迟；SiPESC.POST系统有边线时20帧，流畅，取消边线时38帧，十分流畅．具体见图4．4.2 千万节点发动机模型显示该模型包含1 304×104个节点，931×104个十节点四面体单元，模型文件大小为2.41 GB，整个显示过程中，内存用量峰值为5.1 GB，稳定后内存用量为4.5 GB．若不进行内部元素剔除，按每个十节点四面体单元离散为16个三角形面片，共有三角形面片14 896×104个，每个完整三角形面片需192 B计算，需显存26 GB，远远超出可用显存容量，无法显示．剔除内部元素后，表面三角形面片数仅为654 579个，需显存120 MB，可流畅旋转、放缩．分别测试了该模型在Patran、HyperMesh和SiPESC.POST系统中的最大帧数：Patran 1帧，十分卡顿，即使在旋转过程中取消边线以加速显示，最大帧数也仅为2帧左右；HyperMesh有无边线均为6～7帧，比较卡顿；SiPESC.POST系统有边线时12帧，基本流畅，取消边线时28帧，十分流畅．具体见图5．本文在自主软件平台SiPESC上，进一步研发了面向千万节点有限元模型的可视化系统．在SiPESC平台的插件技术、过滤器设计框架及工厂软件设计模式基础上，提出了基于拓扑结构的内部单元剔除技术，精化了数据结构及管理方案．结合VBO快速显示技术，实现了单机千万节点规模有限元可视化功能．给出了基于SiPESC平台的软件集成思路与功能扩展实例．通过两个千万节点规模的可视化实例，与商业软件进行了对比验证，展示了本文研发可视化系统在显示效率、大规模问题适用性方面的优越性．【相关文献】[1] 邹静,纪洪广. 超大型三维有限元模型的快速可视化算法[J]. 图学学报, 2012, 33(2):13-19. ZOU Jing, JI Hong-guang. Fast visualization algorithm for huge 3D-finite element models [J]. Journal of Graphics, 2012, 33(2):13-19. (in Chinese)[2] 孙青,徐霞. 基于八叉树及LOD视相关大规模三维城市模型研究[J]. 科技通报, 2014,30(2):91-94.SUN Qing, XU Xia. Study of large-scale three-dimensional city model based on octree and view-dependent LOD technology [J]. Bulletin of Science and Technology, 2014, 30(2):91-94. (in Chinese)[3] 邵思睿,郭力. 大规模粒子模拟的后处理与可视化[J]. 计算机与应用化学, 2011, 28(9):1121-1125. SHAO Si-rui, GUO Li. Post-process and visualization for large-scale particle simulation [J]. Computers and Applied Chemistry, 2011, 28(9):1121-1125. (in Chinese) [4] 徐良寅,李云鹏,陈飙松. 面向超大规模有限元计算的通用可视化系统SiPESC.POST的设计与实现[J]. 计算力学学报, 2015, 30(2):220-224.XU Liang-yin, LI Yun-peng, CHEN Biao-song. Design and implementation of general visual system SiPESC.POST for large scale finite element computation [J]. Chinese Journal of Computational Mechanics, 2015, 30(2):220-224. (in Chinese)[5] 张洪武,陈飙松,李云鹏,等. 面向集成化CAE软件开发的SiPESC研发工作进展[J]. 计算机辅助工程, 2011, 20(2):39-49.ZHANG Hong-wu, CHEN Biao-song, LI Yun-peng, et al. Advancement of design and implementation of SiPESC for development of integrated CAE software systems [J]. Computer Aided Engineering, 2011, 20(2):39-49. (in Chinese)[6] Pharr M. GPU精粹2[M]. 北京:清华大学出版社, 2007:336-337.Pharr M. GPU Gems 2 [M]. Beijing:Tsinghua Universtiy Press, 2007:336-337. (in Chinese) [7] Gamma E, Helm R, Johnson R, et al. Design Patterns:Elements of Reusable Object-Oriented Software [M]. Boston:Addison-Wesley, 1994:116-118.。
My_MooseFS与MogileFS性能测试对比
MooseFS与MogileFS的性能测试对比1.1.测试过程测试1 Java_Write_15w_100KMogileFS和MooseFS启动15个进程进行写数据，对比执行所需时间；测试2 Siege_Read_c100_60mins_1storage在192.168.80.15上使用Siege模拟100个并发用户通过http访问前端Nginx，持续60分钟随机访问50万个文件，这50万个文件均只存储在同一个Storage（Chunk）节点下；测试3 Siege_Read_c200_60mins_1storage在192.168.80.15上使用Siege模拟200个并发用户通过http访问前端Nginx，持续60分钟随机访问50万个文件，这50万个文件均只存储在同一个Storage（Chunk）节点下；测试4 Siege_Read_c300_60mins_1storage在192.168.80.15上使用Siege模拟300个并发用户通过http访问前端Nginx，持续60分钟随机访问50万个文件，这50万个文件均只存储在同一个Storage（Chunk）节点下；1.2.测试结果写操作（Replication份数均为3）：文件系统助记号并发数完成时间测试1 MogileFS Java_Write_15w_100K 15 69分钟测试1 MooseFS Java_Write_15w_100K 15 140分钟若MooseFS设置的Replication份数为1，通过15个并发写15万数据只需要48分钟可见MooseFS的写操作速度受到份数设置的影响，如下图：读操作：MogileFS:助记号成功率平均反应时间（秒）平均每秒处理个数（个/秒）平均每秒流量（MBytes/秒）平均并发数（个）磁盘平均tps（个）磁盘平均读速度（Blocks/秒）测试2 Siege_Read_c100_60mins_1storage99.8% 0.70 82.96 8.09 58.24 252.221 17180.2测试3 Siege_Read_c200_60mins_1storage99.8% 1.57 96.38 9.39 151.74 275.235 19811.9测试4 Siege_Read_c300_60m_1storage98.9% 1.53 147.83 14.27 225.73 420.278 27329.0MooseFS:助记号成功率平均反应时间（秒）平均每秒处理个数（个/秒）平均每秒流量（MBytes/秒）平均并发数（个）磁盘平均tps（个）磁盘平均读速度（Blocks/秒）100.00 % 3.64 24.14 2.36 87.83 114.046 5762.24 测试2 Siege_Read_c100_60mins_1storage测试3 Siege_Read97.04 % 6.76 24.43 2.39 165.22 114.582 5793.09_c200_60mins_1storage测试4 Siege_Read88.92 % 7.66 25.14 2.46 192.65 116.7 5982.61_c300_60m_1storage1.3.结果分析●写操作测试同样Replication份数的情况下，MooseFS比MogileFS要慢较多。
mogilefs的读法
mogilefs的读法mogilefs（全称：Mogile Distributed File System）是一种分布式文件系统，用于存储和管理大量的文件数据。
它的设计目标是提供高性能、高可靠性和可伸缩性，以满足大规模Web应用程序的需求。
mogilefs的读法可以简单地按照英文原音读作'mo-gile-fs'，也可以根据个人的习惯读作'mogile-efs'。
Mogilefs的核心设计理念是将文件数据分散存储在多个普通硬盘上，以实现高可靠性和可扩展性。
它使用一组称为'trackers'的服务器来跟踪文件的位置和状态，并使用一组称为'storages'的服务器来存储和提供文件数据。
通过这种方式，mogilefs可以轻松地扩展存储容量和吞吐量，以适应不断增长的数据需求。
mogilefs提供了一组简单而有效的API，使开发人员能够方便地上传、下载和删除文件，以及查询文件的状态和位置信息。
它还提供了可自定义的存储策略，允许根据应用程序的需求灵活地管理文件的冗余和分布。
除了高可靠性和可扩展性，mogilefs还具有良好的性能特性。
它使用了一种称为'非阻塞I/O'的技术，使得文件的读写操作可以并行执行，提高了整体的吞吐量和响应速度。
此外，mogilefs还支持文件的分块存储和传输，可以更快地处理大文件和高并发的访问请求。
总结来说，mogilefs是一种用于存储和管理大量文件数据的分布式文件系统，它具有高可靠性、高可扩展性和良好的性能特性。
通过将文件数据分散存储在多个普通硬盘上，mogilefs可以轻松地应对大规模Web应用程序的需求。
无论是对于开发人员还是系统管理员来说，mogilefs都是一个强大而灵活的工具，可以方便地管理和操作文件数据。
曲飞高校固定资产管理系统项目解决方案
高校资产综合网络管理系统[简称：AIS]解决方案曲飞科技.qufeisoft.目录一、概述 (2)1.1、项目背景 (2)1.2、高校固定资产管理工作中普遍存在的问题 (2)二、解决方案 (4)2.1、方案 (4)2.2、功能介绍 (10)2.2.1、先进的三级管理机制 (11)2.2.2、完善的资产清查与数据上报机制 (12)2.2.3、强大的查询、统计分析功能 (13)2.2.4、完备的财务管理功能 (14)2.3、系统的特点 (14)2.3.1、全面性 (14)2.3.2、高效性 (15)2.3.3、严密性 (15)2.3.4、实时性 (16)2.3.5、规性 (16)2.3.6、先进性 (16)2.4、系统应用状况 (17)2.4.1、完善的管理网络 (17)2.4.2、严格的经济责任 (17)2.4.3、规的工作流程 (18)2.4.4、严密的帐表管理体系 (18)2.4.5、全息、多维、实时的状态控制 (18)2.4.6、灵活调配机制与合理开发利用的自觉性 (19)2.4.7、科学的维修养护 (19)2.4.8、正常的清查盘点 (19)2.4.9、严肃的奖惩制度 (19)2.4.10、现代化的管理手段 (19)2.5、资金预算2.5.1、资金预算一、概述1.1、项目背景随着我国高等教育事业的迅猛发展，高等学校占有、使用的固定资产规模急剧膨胀，其构成日趋复杂，管理难度越来越大。
尤其是随着校际间的合并与调整、学校部推行的后勤、财务、人事、分配等各项改革的深化，对高等学校的固定资产管理工作不断提出新要求。
但是，多年来固定资产管理工作一直是高校管理的一个薄弱环节，管理基础工作不够规，资产安全控制体系尚不完善，家底不清、帐帐、帐实不符、资产流失的现象在不少的学校依然存在，与高等教育发展改革的新形势很不适应。
近几年来，为加强固定资产管理工作，国一些地区和学校进行了有益的探索，开发管理软件,开始使用计算机管理教学仪器、设备等,技术上有了一定的进步。
分布式文件系统luster&MogileFS对比测试
群集文件系统测试介绍分布式文件系统能给用户带来更高的性能、扩展性和可用性，那么构建一个高性能的分布式文件系统又该从何处入手呢？基于Infiniband技术构建Lustre的实例可以让你见识到分布式文件系统的强大性能。
存储系统对于高性能计算平台的性能有重要的影响。
很多关键应用，如天气预报、洋流模拟等都有很高的I/O 吞吐量。
分布式文件系统以其高可靠性、高可扩展性、高性能和高性价比成为高性能计算平台存储系统的首选。
Lustre：该系统是sun公司收购的开源分布式文件系统。
在sun的网站有专门的页面，介绍比较完整，有用户手册和支持文档。
Sun和一些其他公司的存储解决方案均使用该系统。
关键词：→Infiniband 由Mellanox公司提出，是一种新的I/O总线技术，用于取代目前的PCI总线。
→Lustre 它是一个开放源码的基于对象存储的高性能分布式文件系统，由Cluster File System(CFS)公司研发。
→Portals 来源于Sandia大学的Puma轻量内核项目，主要用于高性能的消息传递。
Lustre作为新一代的基于对象的分布式文件系统，同一般的分布式文件系统，如NFS、GFS、PVFS等相比，具有独特的优势：●针对大文件读写进行优化，可以提供高性能的I/O；●数据独立存储；●服务和网络失效的快速恢复；●基于意图的分布式锁管理；●融合了传统分布式文件系统（如AFS和Locus CFS）的特色和传统共享存储集群文件系统（如Zebra、Berkeley XFS、GPFS、Calypso、InfiniFile 和GFS）的设计思想，具有更加有效的数据管理机制；●全局数据共享；●基于对象存储，使存储更具智能化；●系统可快速配置。
网络技术直接影响分布式文件系统的性能。
Infiniband作为一种新的网络类型，其低延迟、高带宽的特点可以为分布式文件系统提供良好的网络支持，提高结点间的通信速度，从而提升整个文件系统的性能。
LINUX文件系统比较
文件系统比较MogileFSMogileFS是一款开源的、高性能的、分布式的文件系统，用于组建分布式文件集群，跟Memcached是同门，都由LiveJournal旗下Danga Interactive公司开发。
MogileFS能干什么最主要的功能就是：用来存取海量文件，而不用关心具体的文件存放位置、存储容量大小，以及文件损坏和丢失等问题。
MogileFS特点1：应用层：不需要特殊的核心组件2：无单点失败：MogileFS分布式文件存储系统安装的三个组件（存储节点、跟踪器、跟踪用的数据库），均可运行在多个机器上，因此没有单点失败。
3：自动进行文件复制：基于不同的文件“分类”，文件可以被自动的复制到多个有足够存储空间的存储节点上，这样可以满足这个“类别”的最少复制要求。
4：比RAID更好：在一个非存储区域网络的RAID中，磁盘是冗余的，但主机不是，如果你整个机器坏了，那么文件也将不能访问。
MogileFS分布式文件存储系统在不同的机器之间进行文件复制，因此文件始终是可用的。
5：传输中立，无特殊协议6：简单的命名空间：文件通过一个给定的key来确定，是一个全局的命名空间MogileFS的适用性——擅长处理海量小文件由于MogileFS不支持对一个文件的随机读写，因此注定了只适合做一部分应用。
比如图片服务，静态HTML服务。
FastDFSFastDFS是一个开源的分布式文件系统，她对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。
特别适合以文件为载体的在线服务，如相册网站、视频网站等等。
FastDFS服务端有两个角色：跟踪器（tracker）和存储节点（storage）。
跟踪器主要做调度工作，在访问上起负载均衡的作用。
存储节点存储文件，完成文件管理的所有功能：存储、同步和提供存取接口，FastDFS同时对文件的meta data进行管理。
关于大型企业成熟套装软件完善提升阶段特点的思考
1引言大型企业通过部署成熟套装软件，推动集约化管理，实现集中管控。
成熟套装软件的部署是一个长期而不断改进的过程，在软件深化应用和完善提升阶段，项目环境发生变化，管理呈现新的特点并面临新的挑战。
要围绕业务管理，推进软件系统与核心业务的自然融合和深度支撑，确保系统柔性适应业务发展，促进业务流程和管理要求的不断深化。
2完善提升阶段项目管理工作的新特点2.1任务来源分散在成熟套装软件试点和推广阶段，项目任务来源主要是信息管理部门，任务内容、项目管理模式相对固定，并有成熟经验可供借鉴，易于管理。
在信息系统完善提升阶段，任务来源遍布多个业务部门，从原来的“一对一”模式转变到目前的“多对一”和“多对多”的局面，增加了项目管理难度[1]。
2.2任务周期紧迫在成熟套装软件的完善与提升阶段，其工作量、工作进度要求远非项目正常开展所能够完成，往往造成项目组人员紧张、项目计划调整频繁，需要大量加班才能按期完成任务。
2.3任务关系复杂企业下达的工作任务通常从任务的来源确定任务归属，如财务的工作任务仅下达给财务项目组，很少将工作任务内容也通知到与工作任务相关的业务部门和项目组，这样就给项目组带来了跨部门、跨系统、跨模块的业务协调及技术配合的困难。
2.4系统连续运行当成熟套装软件已经全覆盖应用，涉及完善提升时，必须考虑现有业务及系统存量数据连续应用需求，保证系统连续运行，业务持续开展。
因此必须制定周密的方案，缩短系统完善提升切换时间，确保切换后相关业务数据的可追溯性和延续性，保障业务数据完整和业务操作的延续性，实现系统与业务平稳切换，最小化系统切换对业务运转的冲击与影响。
3完善提升阶段项目管理面临的新风险3.1项目进度难以把控在成熟套装软件试点和推广阶段，项目各模块的工作开展采取同步推进的方式，按照实施方法论已经明确每个阶段的实施步骤，完成相应的工作任务，在项目管理上所需要的也就是统筹把控项目进度。
但是在系统完善提升建设阶段，成熟【作者简介】祁宏(1978-)，男，辽宁辽阳人，工程师，从事信息化研究。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
MogileFS 系统应用在EshangTu项目的可行性分析[摘要] (2)[关键词] (2)[涉及的关键概念] (2)分布式文件系统 (2)MogileFs (2)正文 (3)选择MogileFs的理由 (3)MogileFS 特性就介绍，官方介绍 (3)MogileFS 的结构 (4)MogileFS 的三个大的部分 (5)MogileFS 的二个服务进程 (7)MogileFS 的其它 (7)MogileFS 中的存储节点 (7)MogileFS 内部的管理关系 (8)MogileFS 的安装与配置详细参考文档 (9)MogileFS 的客户端和API (9)MogileFs应用到eshangtu项目的设想 (14)[摘要]描述了MogileFS 系统涉及的计算机概念，该系统能解决的问题，运行结构，原理。
并讨论了当应用在eshangtu项目上时，要解决的几个问题，和初步的解决方案。
[关键词]MogileFS 分布式文件系统 perl 存储节点(store node) 跟踪节点(tracker) 跟踪数据库[涉及的关键概念]分布式文件系统分布式系统图示分布式+文件系统。
它包含这两个方面的内涵，从文件系统的客户使用的角度来看，它就是一个标准的文件系统，提供了一系列API，由此进行文件或目录的创建、移动、删除，以及对文件的读写等操作。
从内部实现来看，分布式的系统则不再和普通文件系统一样负责管理本地磁盘，它的文件内容和目录结构都不是存储在本地磁盘上，而是通过网络传输到远端系统上。
并且，同一个文件存储不只是在一台机器上，而是在一簇机器上分布式存储，协同提供服务，正所谓分布式。
因此，考量一个分布式文件系统的实现，其实不妨可以从这两方面来分别剖析，而后合二为一。
首先，看它如何去实现文件系统所需的基本增删改查的功能。
然后，看它如何考虑分布式系统的特点，提供更好的容错性，负载平衡，等等之类的。
这二者合二为一，就明白了一个分布式文件系统，整体的实现模式。
MogileFs MogileFS 是一个开源的分布式文件系统，用于组建分布式文件集群，由LiveJournal 旗下Danga Interactive 公司开发，Danga 团队开发了包括Memcached、MogileFS、Perlbal 等不错的开源项目：(注：Perlbal 是一个强大的Perl 写的反向代理服务器)。
目前国内使用MogileFS 的有图片托管网站yupoo 等。
MogileFS由3个部分组成：第1个部分是server端，包括mogilefsd和mogstored两个程序。
前者即是mogilefsd的tracker，它将一些全局信息保存在数据库里，例如站点domain,class,host等。
后者即是存储节点(store node)，它其实是个HTTP Daemon，默认侦听在7500端口，接受客户端的文件备份请求。
在安装完后，要运行mogadm工具将所有的store node注册到mogilefsd的数据库里，mogilefsd会对这些节点进行管理和监控。
第2个部分是utils（工具集），主要是MogileFS的一些管理工具，例如mogadm等。
第3个部分是客户端API，用这个模块可以编写客户端程序，实现文件的备份管理功能。
正文选择MogileFs的理由MogileFS系统的分布式存储可以解决Web服务器负载过大的问题。
Eshangtu项目中需要存储大量的图片，并对用户提供存取服务，IO吞吐量较大。
为了减轻Web服务器压力，考虑采用分布式文件系统，分流图片文件的读写操作。
图片是静态内容，有如下需求：1，需要集中存储，也就是对服务的需求者，只有一个统一的接口。
2，图片需要的存储量比较大3，要稳定，文件不能丢失根据上述要求我们可以采用如下模式：可以使用众多的网络协议来使用File Server 上的文件，可以是NFS或是CIFS，甚至可以是SAN（当然，这东东比较贵的说）。
但是为了满足上面提出的3个要求，我更倾向于用分布式文件来取代File Server。
MogileFS就是这样一种系统。
MogileFS 特性就介绍，官方介绍(1. 应用层–不需要特殊的核心组件(2. 无单点失败— MogileFS分布式文件存储系统安装的三个组件（存储节点、跟踪器、跟踪用的数据库），均可运行在多个机器上，因此没有单点失败。
（你也可以将跟踪器和存储节点运行在同一台机器上，这样你就没有必要用4台机器）推荐至少两台机器。
(3. 自动的文件复制—基于不同的文件“分类”，文件可以被自动的复制到多个有足够存储空间的存储节点上，这样可以满足这个“类别”的最少复制要求。
比如你有一个图片网站，你可以设置原始的JPEG图片需要复制至少三份，但实际只有1or2份拷贝，如果丢失了数据，那么MogileFS分布式文件存储系统可以重新建立遗失的拷贝数。
用这种办法，MogileFS(不做RAID)可以节约磁盘，否则你将存储同样的拷贝多份，完全没有必要。
(4. “比RAID好多了”—在一个非存储区域网络的RAID（non-SAN RAID）的建立中，磁盘是冗余的，但主机不是，如果你整个机器坏了，那么文件也将不能访问。
MogileFS分布式文件存储系统在不同的机器之间进行文件复制，因此文件始终是可用的。
(5.传输中立，无特殊协议— MogileFS分布式文件存储系统客户端可以通过NFS或HTTP 来和MogileFS的存储节点来通信，但首先需要告知跟踪器一下。
(6. 简单的命名空间—文件通过一个给定的key来确定，是一个全局的命名空间。
你可以自己生成多个命名空间，只要你愿意，不过这样可能在同一MogileFS中会造成key冲突。
(7. 不用共享任何东西— MogileFS分布式文件存储系统不需要依靠昂贵的SAN来共享磁盘，每个机器只用维护好自己的磁盘。
(8. 不需要RAID—在MogileFS中的磁盘可以是做了RAID的也可以是没有，如果是为了安全性着想的话RAID没有必要买了，因为MogileFS分布式文件存储系统已经提供了。
MogileFS 的结构在使用前，我们需要对 MogileFS 有个基本的了解，就是他的三个大的部分,Trackerand Database 和 Storage Nodes, Client 组成。
由二个服务进程 MogileFSd 和mogstored .如图:客户端，连接到一个域，然后在域中拿着文件的 key 来查文件的位置，然后通过集群中的位置来打开这个文件。
MogileFS 的结构图MogileFS 的三个大的部分前面提到 Tracker and Database 和 Storage Nodes, Client 组成，我们这先不讲Client.因为Client实际上是一个 Perl 的 pm，可以写程序调用该 pm 来使用 MogileFS 系统，对整个系统进行读写操作。
另外，象 nginx 之类有相关的模块。
另外也有做成象文件系统一样采用fuse方式挂载.(1.Trackers（跟踪器,调度器）-MogileFSd这个是 MogileFS 的核心部分，通俗点讲，就他是一个调度器。
MogileFSd 进程就是trackers程序，类似 MogileFS 的 wiki 上介绍的，trackers 做了很多工作，Replication ，Deletion，Query，Reaper，Monitor等等。
这个是基于事件的( event-based ) 父进程/消息总线来管理所有来之于客户端应用的交互(requesting operations to be performed), 包括将请求负载平衡到“query workers” 中，让 MogileFSd 的子进程去处理. mogadm,mogtool 的所有操作都要跟 trackers 打交道，Client 的一些操作也需要定义好 trackers，因此最好同时运行多个 trackers 来做负载均衡。
trackers 也可以只运行在一台机器上，也可以跟其他程序运行在一起（不建议）注：mogilefsd的子进程有:o Replication —机器间复制文件o Deletion —从命名空间删除是立即的，从文件系统删除是异步的o Query —响应客户端的请求o Reaper —在磁盘失败后将文件复制请求重新放到队列中o Monitor —监测主机和设配的健康度和状态配置文件： /etc/mogilefs/mogilefsd.conf(2. 数据库（MySQL）部分如上图所显示的，数据库用来存放 MogileFS 的元数据 (命名空间, 和文件在哪里). 是 Trackers 来操作和管理它。
你可以用 mogdbsetup 程序来初始化数据库。
因为数据库保存了MogileFS的所有元数据，如果这儿挂了，那么整个 MogileFS 将处于不可用状态。
因此最好是HA结构。
(3. 存储节点(Storage Nodes )-mogstored,Apache,Nginx实际文件存放的地方. 存储节点是一个 HTTP 服务器，用来做删除，存放，重命名等事情，任何 WebDAV 服务器都可以, 不过推荐使用 mogstored 。
MogileFSd 可以配置到两个机器上使用不同端口… mogstored 为所有 DAV 操作 (和流量监测), 并且你自己选择的快速的 HTTP 服务器用来做 GET 操作(给客户端提供文件). 典型的应用是一个挂载点有一个大容量的 SATA 磁盘，它们被挂载到 /var/mogdata/devNN. 只要配置完配置文件后mogstored 程序的启动将会使本机成为一个存储节点。
当然还需要 mogadm 这个工具增加这台机器到 Cluster 中。
配置文件: /etc/mogilefs/mogstored.confMogileFS 的二个服务进程对应上面的部分MogileFSd —MogileFS 的主守护进程，就是上面指的trackers（跟踪器）,由/etc/MogileFS/MogileFSd.conf 这个配置文件控制。
Mogstored — MogileFS 存储守护进程, 这个就是上面指的存储节点(Storage Nodes )，由/etc/MogileFS/mogstored.conf 这个配置文件控制。
MogileFS 的其它有几个小工具，主要就是 mogadm，mogtool 这两个工具了，用来在命令行下控制整个MogileFS 系统以及查看状态等等。
MogileFS 中的存储节点我们先看下面的图下面多了几个存储节点，他们都是单独的，便宜的，多硬盘的机器。