分布式存储

前天，著名分布式存储项目FileCoin放出消息，FileCoin挖矿将来极大可能会使用到GPU。消息一出，存储行业一片哗然。使用GPU挖矿，说明需要大量的计算资源，就像比特币和以太坊的POW挖矿一样。大家一直都认为，存储挖矿主要是要使用硬盘的存储资源，为什么现在需要用到算力资源呢？ 其实，了解FileCoin的设计，和这个项目的发展路线图，就应该看到，使用GPU是必然趋势。现在我们就这个项目来讨论一下，为什么FileCoin挖矿需要GPU。 首先在FileCoin发布的设计规格书里，算法这一章，时空证明这一节里早就写明了需要用到Election PoSt，即新的节点选举算法在区块生成时，必须提供PoST的证明。这个设计就导致对PoST证明的性能有要求。而GPU是目前加速PoST证明生成的一个可行方案。 4.3.1.2 选举时空证明 为了缩短时空证明的响应时间，被选中的出块矿工必须提交时空证明，所以叫做选举时空证明。当矿工赢得一个区块时，他们需要立即生成时空证明，并将其与被选证明一起提交。 StoragePowerConsenusSubsystem 在区块验证的同时也要检查被选证明和时空证明。当一个块被选中时，会出现一条特殊消息，该消息会去调用 SubmitElectionPoSt ，它将以提交 SubmitSurprisePoSt 成功的相同的方式处理扇区更新。 简单的说

2019年中国迈入新数据时代元年，IDC最新发布的《2025年中国将拥有全球最大的数据圈》显示，中国各类型数据呈几何级数增长，预计在2025年中国数据圈将增至48.6ZB。数据带来前所未有的商业红利的同时也带来了前所未有的风险。数据泄露水平指数显示，2018年每天有超过2500万条数据遭到入侵或泄露，涵盖医疗、信用卡、财务数据、个人身份信息等。 　　存储介质作为如此庞大数据量的承载者，在这样的背景下，安全显得尤为重要。当下，我国正在全力推进党政信息化建设，《“十三五”国家信息化规划》提出：到2020年，“数字中国”建设取得显著成效，具有国际竞争力、安全可控的信息产业生态体系基本建立。 　　 　　杉岩数据在数据存储技术发展的道路上始终心怀担当，坚持走国产化技术路线，专注在分布式存储领域深耕，历时多年研发出全国产化分布式统一存储平台USP。 　　 Sandstone USP作为一款国产分布式存储软件产品，技术架构上采用业内领先的全分布式高可用设计，全平台无单点故障，并且可以提供文件存储、块存储和对象存储三种不同类型的存储模块，这些存储模块可以灵活的组合搭配，提供快速简便的访问方式，满足新一代应用的敏捷开发需求，能够根据应用的发展进行灵活的弹性扩展。提供了全语义、跨协议数据访问，帮助企业打通数据孤岛、实现传统应用间的数据共享，一体化极简架构与分钟级扩容、秒级数据检索，加速企业上云转型

一 、Hadoop 简介： 1. 大数据略知一二： 1）大数据（big data），指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产，需要在合理的时间内达到提取、管理、处理、并且整理成为帮助企业运营决策更积极目的的信息； 2）在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》 中大数据指不用随机分析法（抽样调查）这样捷径，而采用所有数据进行分析处理； 3）大数据的5V特点（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）、Veracity（真实性）。 图解大数据： http://www.ruanyifeng.com/blog/2017/07/iaas-paas-saas.html 3. 项目起源： Hadoop由 Apache Software Foundation 公司于 2005 年秋天作为Lucene的子项目Nutch的一部分正式引入。它受到最先由 Google Lab 开发的 Map/Reduce 和 Google File System(GFS) 的启发。2006 年 3 月份，Map/Reduce 和 Nutch Distributed File System (NDFS)

废话不说直接来一张图如下： 从JVM的角度看Map和Reduce Map阶段包括： 第一读数据：从HDFS读取数据 1、问题:读取数据产生多少个Mapper？？ Mapper数据过大的话，会产生大量的小文件，由于Mapper是基于虚拟机的，过多的Mapper创建和初始化及关闭虚拟机都会消耗大量的硬件资源； Mapper数太小，并发度过小，Job执行时间过长，无法充分利用分布式硬件资源； 2 、 Mapper 数量由什么决定？？ （ 1 ） 输入文件数目 （ 2 ） 输入文件的大小 （ 3 ） 配置参数 这三个因素决定的。 涉及参数： mapreduce.input.fileinputformat.split.minsize //启动map最小的split size大小，默认0 mapreduce.input.fileinputformat.split.maxsize //启动map最大的split size大小，默认256M dfs.block.size//block块大小，默认64M 计算公式：splitSize = Math.max(minSize, Math.min(maxSize, blockSize)); 例如 默认情况下：例如一个文件800M，Block大小是128M，那么Mapper数目就是7个。6个Mapper处理的数据是128M，1个Mapper处理的数据是32M

　本文只是一个概念，具体配置太多，这里不做细节描述。 　　1、分布式应用的概念和优势 　　分布式数据库是指利用高速网络将物理上分散的多个数据 存储 单元连接起来组成一个逻辑上统一的数据库。分布式数据库的基本思想是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获得更大的存储容量和更高的并发访问量。近年来，随着数据量的增长，分布式数据库技术也得到了快速的发展，传统的关系型数据库开始从集中式模型向分布式存储，从集中式计算走向分布式计算。 　　分布式数据库系统的主要目的是容灾、异地数据备份，并且通过就近访问原则，用户可以就近访问数据库节点，这样就实现了异地的负载均衡。同时，通过数据库之间的数据传输同步，可以分布式保持数据的一致性，这个过程完成了数据备份，异地存储数据在单点故障的时候不影响服务的访问，只需要将访问流量切换异地镜像就行。 　　分布式数据库应用的优势如下： 　　(1)适合分布式数据管理，能够有效提高系统性能。 　　(2)系统经济性和灵活性好。 　　(3)系统的可靠性和可用性强。 　　2、mysql分布式应用的主要技术 　　(1)mysql数据切割 　　数据切割(sharding)是指通过某种特定的条件，将存放在同一数据库中的数据分散存放到多个数据库(主机)上面，以达到分散单台设备负载的效果。数据切分还可以提高系统的总体可用性，因为单台crash之后

1.动态库问题以及解决方案 1.1问题发现 在Linux环境下编写C程序时，经常需要使用动态库，这里给出常见动态库问题的解决方案。 开源项目使用redis中的examples.c程序 直接使用指令对example.c进行编译 gcc example .c 出现以下错误 提示缺少头文件hiredis.h，使用查找指令 find /usr/ local / include -name "hiredis.h" 导入头文件继续进行编译 gcc examples . c -I /usr/ local /include/hiredis -o example 出现动态库未找到错误 找到动态库文件的目录 1.2 解决动态库问题的三种方案 1. 使用环境变量LD_LIBRARY_PATH 将动态库的绝对路径添加到该环境变量中 LD_LIBRARY_PATH = /usr/include/xxx: $LD_LIBRARY_PATH export LD_LIBRARY_PATH 写入到配置文件当中 ~/ .bashrc -用户级别 /etc/profile -系统级别 2. 给动态库设置软连接 /usr/USERNAME/fastdfs 将软连接放到 /usr/lib /usr/lib64 /lib /lib4 sudo ln -s /usr/USERNAME/fastdfs/XXX.so /usr

分布式存储 — 硬盘容量不均衡导致的缓存盘寿命急速衰减分析 Ceph 分布式存储在扩展性、可靠性、性能上具备独特的优势，可以实现快速扩展多台服务器，动态伸缩到 PB 级容量，多副本机制保障数据高可靠，数据均衡分布，并发性能高等场景。目前广泛应用于互联网、科研、教育、制造业、政府等诸多领域。 ZStack 云平台目前支持对接 Ceph 分布式存储，使用的是分布式块存储，即使用 librbd 的块设备接口提供给 Qemu 访问，进行云主机、云盘的 IO 读写。 虽然 Ceph 分布式存储具备上述的优势特点，但在实践中，对硬件的选择及配置均存在特别要求，尤其是硬盘、网络上，如果配置不当，存储的可靠性和性能均会受到影响。 最近在日常巡检一套 ZStack 生产环境的 Ceph 分布式存储时，我们发现客户新购的五台服务器的 SSD 寿命损耗存在异常。具体的现象是使用半年后，服务器带外管理界面看到 SSD 的寿命损耗只剩下 89% ，但使用 smartctl 读取介质损耗参数依然显示为 100% 。 此时会很疑惑，到底哪个数据更可靠，如果 SSD 寿命只剩下 89% ，那么如何去调整优化 Ceph 分布式存储？ 问题回顾 针对这个问题，我们回顾一下这套分布式存储的架构。当时采用了新购 + 利旧的方案来部署分布式存储。 相应的配置信息如下： 其中，新购的 5 台机器采用了 Intel Xeon

FastDFS搭建分布式文件系统 1. 什么是分布式文件系统 分布式文件系统 （Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。 通俗来讲： 传统文件系统管理的文件就存储在本机。 分布式文件系统管理的文件存储在很多机器，这些机器通过网络连接，要被统一管理。无论是上传或者访问文件，都需要通过管理中心来访问 2. 什么是FastDFS FastDFS是由淘宝的余庆先生所开发的一个轻量级、高性能的开源分布式文件系统。用纯C语言开发，功能丰富： 文件存储 文件同步 文件访问（上传、下载） 存取负载均衡 在线扩容 适合有大容量存储需求的应用或系统。同类的分布式文件系统有谷歌的GFS、HDFS（Hadoop）、TFS（淘宝）等。 3. FastDFS的架构 3.1 fast架构 FastDFS两个主要的角色：Tracker Server 和 Storage Server 。 Tracker Server ：跟踪服务器，主要负责 调度 storage节点与client通信，在访问上起 负载均衡 的作用，和记录storage节点的运行状态，是连接client和storage节点的 枢纽 。 Storage Server ：存储服务器， 保存 文件和文件的meta data（元数据），每个storage

FastDFS搭建分布式文件系统 1. 什么是分布式文件系统 分布式文件系统 （Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。 通俗来讲： 传统文件系统管理的文件就存储在本机。 分布式文件系统管理的文件存储在很多机器，这些机器通过网络连接，要被统一管理。无论是上传或者访问文件，都需要通过管理中心来访问 2. 什么是FastDFS FastDFS是由淘宝的余庆先生所开发的一个轻量级、高性能的开源分布式文件系统。用纯C语言开发，功能丰富： 文件存储 文件同步 文件访问（上传、下载） 存取负载均衡 在线扩容 适合有大容量存储需求的应用或系统。同类的分布式文件系统有谷歌的GFS、HDFS（Hadoop）、TFS（淘宝）等。 3. FastDFS的架构 3.1 fast架构 FastDFS两个主要的角色：Tracker Server 和 Storage Server 。 Tracker Server ：跟踪服务器，主要负责 调度 storage节点与client通信，在访问上起 负载均衡 的作用，和记录storage节点的运行状态，是连接client和storage节点的 枢纽 。 Storage Server ：存储服务器， 保存 文件和文件的meta data（元数据），每个storage

两大主流开源分布式存储的对比： GlusterFS vs. Ceph 存储世界最近发生了很大变化。十年前，光纤通道SAN管理器是企业存储的绝对标准，但现在的存储必须足够敏捷，才能适应在新的基础架构即服务云环境内运行。 GlusterFS和Ceph是在现代云环境中表现最出色的两个敏捷存储系统。 在讲述GlusterFS和Ceph的相同点和区别之前，我们先谈一谈云环境中敏捷存储的一些关键点。 纵向升级和横向扩展。在云环境中，很容易向服务器添加更多存储空间和扩展可用存储池。Ceph和GlusterFS都符合这一需求，让新的存储设备可以轻松融入现有存储产品环境。 高可用。GlusterFS和Ceph都会使用复制方法将数据同时写入不同存储节点。这种运作模式会增加读写次数，但同时也确保了数据的可用性。以Ceph为例，数据在默认情况会被复制到三个不同的节点，确保数据副本一直可用。 通用的硬件。GlusterFS和Ceph的开发基础都是Linux操作系统(OS)。因此，对于硬件的唯一要求就是：能够正常运行Linux即可。由于几乎任何商品硬件都能运行Linux操作系统，只要选择这些存储技术，这些技术的使用单位就可以大幅节省硬件投入。实际上，有许多公司也正在投资专用于GlusterFS或Ceph的硬件平台，因为专门优化的硬件可以更快速高效地访问存储空间。 去中心化