分布式存储

Glusterfs 分布式存储安装部署 Glusterfs 分布式存储部署 是存储当中可以选择的一种 现在很多虚拟化 云计算都在用软件存储 例如 ceph Glusterfs 等等 今天我们部署一下Glusterfs环境 GlusterFs安装 环境信息： Glusterfs-01 10.20.0.200 Glusterfs-02 10.20.0.201 Glusterfs-03 10.20.0.202 硬盘各一块 8G 测试 /dev/sdb 服务器版本信息 # cat /etc/redhat-release CentOS release 6.6 (Final) # uname -r 2.6.32-504.el6.x86_64 软件下载地址 http://download.gluster.org/pub/gluster/glusterfs/3.4/3.4.6/CentOS/epel-6.6/x86_64 依赖包安装 直接用Yum安装 每台都需要安装 # yum -y install libibverbs librdmacm xfsprogs nfs-utils rpcbind libaio liblvm2app lvm2-devel 软件安装 安装服务器端软件包 glusterfs-3.4.6-1.el6.x86_64.rpm glusterfs-api-3.4.6-1.el6

G lusterFS 介绍 GlusterFS是一个开源的分布式文件系统，同时也是Scale -Out 存储解决方案Gluster的核心，在存储方面具有横向扩展能力，通过扩展不同的节点可以支持数PB级别的存储容量。 Gluster FS 借助TCP/IP或lnfiniBand RDMA 网络将分散的存储资源汇聚在一起，统一提供存储服务，并使用单一全局命名空间来管理数据。 Gluster FS 基于可堆叠的用户空间以及无元的设计，可为各种不同的数据负载提供优异的性能。 GlusterFS服务群集的组成： 主要由存储服务器( Brick Server) 、客户端( NFS / Samba 存储网关 ) 。Gluster FS 架构中最大的特点是没有元数据服务器组件，这有助于提升整个系统的性能、可靠性和稳定性。传统的分布式文件系统大多通过元服务器来存储元数据，元数据包含存储节点上的目录信息，目录结构等。这样的设计在浏览目录时效率非常高，但是也存在风险和缺陷，如单点故障，一旦元数据服务器出现故障，即使节点具备再高的沉余性，整个存储系统也将崩溃，而Gluster FS 分布式文件系统是基于无元服务器的设计，数据横向扩展能力强，具备较高的可靠性以及存储效率。 GlusterFS的设计结构： GlusterFS的特点： 扩展性和高性能： GlusterFS利用双重特点来提高容量存储解决方案。

公司有几台就服务器，正好有个项目对磁盘的容量以及性能有一定的要求，故而寻求分布式文件系统方面的知识，最终采用了glusterfs。以下对部署以及测试过程潦做记录。 glusterfs分布式文件系统采用C/S模式，其中客户端作为对外提供服务的点，并且负责分配管理数据在后端多台server间的存储。 实验采用6台服务器做整个分布式架构，其中4台存储端实现类似RAID 10模式的存储池，两台客户端通过挂载至存储池，两台客户端之间通过keepalived做双机热备。 要求：glusterfs禁止在系统分区上创建glusterfs卷，所以需要server端每台机器都要有一个独立于跟分区之外的分区加入glusterfs，并且此独立分区要求大小一致（否则，到后期会遇到问题，导致无法继续支持高可用特性）。 Server端 采用yum方式安装，首先配置glusterfs官方的yum源，执行下面命令 vi /etc/yum.repos.d/glusterfs-epel.repo 添加以下内容 [glusterfs-epel] name= GlusterFS is a clustered file-system capable of scaling toseveral petabytes. baseurl= http: / /download.gluster.org/pub /gluster

TPC-C解析系列05_TPC-C基准测试之存储优化 http://www.itpub.net/2019/10/08/3332/ 蚂蚁金服科技 2019-10-08 11:27:02 本文共3664个字，预计阅读需要10分钟。 TPC-C规范要求被测数据库的性能（tpmC）与数据量成正比。TPC-C的基本数据单元是仓库（warehouse），每个仓库的数据量通常在70MB左右（与具体实现有关）。TPC-C规定每个仓库所获得的tpmC上限是12.86（假设数据库响应时间为0）。假设某系统获得150万tpmC，大约对应12万个仓库，按照70MB/仓库计算，数据量约为8.4TB。某些厂商采用修改过的不符合审计要求的TPC-C测试，不限制单个warehouse的tpmC上限，测试几百到几千个warehouse全部装载到内存的性能，这是没有意义的，也不可能通过审计。在真实的TPC-C测试中，存储的消耗占了很大一部分。OceanBase作为第一款基于shared nothing架构登上TPC-C榜首的数据库，同时也作为第一款使用LSM Tree存储引擎架构登上TPC-C榜首的数据库，在存储架构上有如下关键点： 为了保证可靠性，OceanBase存储了两个数据副本和三个日志副本，而传统的集中式数据库测试TPC-C只存储一份数据； 由于OceanBase存储两个数据副本，再加上OceanBase

TPC-C解析系列01_TPC-C benchmark测试介绍 http://www.itpub.net/2019/10/08/3334/学习一下. 自从蚂蚁金服自研数据库OceanBase获得TPC-C测试第一名后，引起了行业内外大量关注，我们衷心的感谢大家对OceanBase的支持与厚爱，也虚心听取外界的意见和建议。为了让大家更好的了解测试的技术细节，我们特意邀请了OceanBase的核心研发人员对本次测试做专业的技术解读，本文为第一篇，后续文章也将于近日对外发布。 OceanBase于2010年立项，九年来，研发人员一步一个脚印，不断的对OceanBase做出改进以及增加新的功能。OceanBase也从服务于支付宝开始，逐渐对外开放，为广大的各行业客户提供服务。在这个过程中，我们希望外界对OceanBase的实力有更直观的了解，让客户对我们的产品更有信心，TPC-C测试为我们提供了一个绝佳的舞台。 通过本次测试，我们发现了OceanBase的一些不足之处，比如，之前的单机数据库只能通过增加CPU、内存等来提高处理能力，OceanBase通过分布式架构，可以让大量的普通硬件设备像一台电脑一样处理数据，想提高性能只需增加设备即可，但是，OceanBase在每台设备上的性能还有不少提升空间；另外，OceanBase支持的功能、易用性、数据库生态相比业界标杆还有一些差距。 接下来

TPC-C解析系列03_TPC-C基准测试之SQL优化 http://www.itpub.net/2019/10/08/3330/ TPC-C是一个非常严苛的基准测试模型，考验的是一个完备的关系数据库系统全链路的能力。这也是为什么在TPC-C的榜单前列，出现的永远只是大家熟知的那几家在业界有着几十年积累、从关系数据库理论开始发展就差不多同步出现的数据库公司。接下来我们通过这篇文章为您分析在TPC-C测试中OceanBase数据库的SQL模块具体遇到了哪些挑战、做出了哪些优化。 背景 对TPC-C有所了解人都知道，TPC-C是一个典型的OLTP (On-Line Transaction Processing) 场景测试，考察的是数据库在高并发压力场景下的事务处理能力，最终的性能指标以tpmC(transaction per minute，也即每分钟系统处理TPC-C模型中的new order事务的数量)和平均到每tpmC的系统成本作为衡量标准。在OLTP场景中，每条请求的响应时间都是极短的。因此，各个数据库厂商在进行TPC-C测试时，都会尽一切可能将每一个操作时间压缩到最短，不夸张的说，在TPC-C的测试中，一些关键操作的优化往往需要细化到CPU指令级。 在进入我们的主题前，我们先来谈谈TPC-C中的事务模型，主要分为五种事务，订单创建、订单支付、订单查询、订单发货以及库存查询

原文 https://mp.weixin.qq.com/s/6yg_bt5mYKWdXS0CidY6Rg 从用户角度看，存储就是一块盘或者一个目录，用户不关心盘或者目录如何实现，用户要求非常“简单”，就是稳定，性能好。为了能够提供稳定可靠的存储产品，各个厂家推出了各种各样的存储技术和概念。为了能够让大家有一个整体认识，本文先介绍存储中的这些概念。 从存储介质角度，存储介质分为机械硬盘和固态硬盘（SSD）。机械硬盘泛指采用磁头寻址的磁盘设备，包括SATA硬盘和SAS硬盘。由于采用磁头寻址，机械硬盘性能一般，随机IOPS一般在200左右，顺序带宽在150MB/s左右。固态硬盘是指采用Flash/DRAM芯片+控制器组成的设备，根据协议的不同，又分为SATA SSD，SAS SSD，PCIe SSD和NVMe SSD。 从产品定义角度，存储分为本地存储（DAS），网络存储（NAS），存储局域网（SAN）和软件定义存储（SDS）四大类。 DAS就是本地盘，直接插到服务器上 NAS是指提供NFS协议的NAS设备，通常采用磁盘阵列+协议网关的方式 SAN跟NAS类似，提供SCSI/iSCSI协议，后端是磁盘阵列 SDS是一种泛指，包括分布式NAS（并行文件系统），ServerSAN等 从应用场景角度，存储分为文件存储（Posix/MPI），块存储（iSCSI/Qemu）和对象存储（S3

hadoop学习笔记：hadoop文件系统浅析 https://www.cnblogs.com/sharpxiajun/archive/2013/06/15/3137765.html 1.什么是分布式文件系统？ 管理网络中跨多台计算机存储的文件系统称为分布式文件系统。 2.为什么需要分布式文件系统了？ 原因很简单，当数据集的大小超过一台独立物理计算机的存储能力时候，就有必要对它进行分区（partition）并存储到若干台单独计算机上。 3.分布式系统比传统的文件的系统更加复杂 因为分布式文件系统架构在网络之上，因此分布式系统引入了网络编程的复杂性，所以分布式文件系统比普通文件系统更加复杂。 4.Hadoop 的文件系统 很多童鞋会把hdfs等价于hadoop的文件系统，其实hadoop是一个综合文件系统抽象，而hdfs是hadoop旗舰级文件系统，hadoop除了hdfs还能集成其他文件系统。Hadoop的这个特点充分体现了hadoop的优良的可扩展性。 在hadoop里，hadoop定义了一个抽象的文件系统的概念，具体就是hadoop里面定义了一个java的抽象类：org.apache.hadoop.fs.FileSystm，这个抽象类用来定义hadoop中的一个文件系统接口，只要某个文件系统实现了这个接口，那么它就可以作为hadoop支持的文件系统

作者 | 晓土 阿里巴巴高级工程师 姊妹篇阅读推荐 ： 《 云原生时代，分布式系统设计必备知识图谱（内含22个知识点） 》 导读： 本文力求从分布式基础理论、架构设计模式、工程应用、部署运维、业界方案这几大方面，介绍基于 MSA（微服务架构）的分布式知识体系大纲，从而对 SOA 到 MSA 进化有着立体的认识；从概念上和工具应用上更近一步了解微服务分布式的本质，身临其境的感受如何搭建全套微服务架构的过程。 关注“阿里巴巴云原生”公众号，回复“ 分布 ”，即可下载分布式系统及其知识体系清晰大图！ 随着移动互联网的发展和智能终端的普及，计算机系统早就从单机独立工作过渡到多机器协作，集群按照分布式理论构建出庞大复杂的应用服务，在分布式的基础上正进行一场云原生的技术革命，彻底打破传统的开发方式，解放了新一代的生产力。 分布式系统知识体系大图 关注“阿里巴巴云原生”公众号，回复“ 分布 ”，即可下载分布式系统及其知识体系清晰大图！ 基础理论 SOA 到 MSA 的进化 SOA 面向服务架构 由于业务发展到一定程度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯。面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障时会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。 MSA 微服务架构

Google学术论文，这是众多分布式文件系统的起源 ================================== Google File System（大规模分散文件系统） MapReduce （大规模分散FrameWork） BigTable（大规模分散数据库） Chubby（分散锁服务） 一般你搜索Google_三大论文中文版(Bigtable、 GFS、 Google MapReduce)就有了。 做个中文版下载源：http://dl.iteye.com/topics/download/38db9a29-3e17-3dce-bc93-df9286081126 做个原版地址链接： http://labs.google.com/papers/gfs.html http://labs.google.com/papers/bigtable.html http://labs.google.com/papers/mapreduce.html GFS（Google File System） -------------------------------------- Google公司为了满足本公司需求而开发的基于Linux的专有分布式文件系统。。尽管Google公布了该系统的一些技术细节，但Google并没有将该系统的软件部分作为开源软件发布。 下面分布式文件系统都是类