ceph

前言 提起大数据，不得不提由IBM提出的关于大数据的5V特点： Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）、Veracity（真实性） ，而对于大数据领域的从业人员的日常工作也与这5V密切相关。大数据技术在过去的几十年中取得非常迅速的发展，尤以Hadoop和Spark最为突出，已构建起庞大的技术生态体系圈。 下面我们通过一张图来了解一下目前大数据领域常用的一些技术，当然大数据发展至今所涉及技术远不止这些。 下面自底向上介绍各个层的主要项目。 1 采集层和传输层 Sqoop 在hadoop和关系型数据库之间转换数据。 Flume Flume是一个分布式的高可用的数据收集、聚集和移动的工具。通常用于从其他系统搜集数据，如web服务器产生的日志，通过Flume将日志写入到Hadoop的HDFS中。 Canal 数据抽取是 ETL 流程的第一步。我们会将数据从 RDBMS 或日志服务器等外部系统抽取至数据仓库，进行清洗、转换、聚合等操作。在现代网站技术栈中，MySQL 是最常见的数据库管理系统，我们会从多个不同的 MySQL 实例中抽取数据，存入一个中心节点，或直接进入 Hive。市面上已有多种成熟的、基于 SQL 查询的抽取软件，如著名的开源项目 Apache Sqoop，然而这些工具并不支持实时的数据抽取。MySQL Binlog

以键值对（Key-Value，简称KV）作为数据的存储方式，已经在很多场合得到了成功的应用。 KV存储以其直观性，降低了很多应用程序调用数据的复杂度，可以获得更高数据的存取效率，但也有其局限性。宝存科技的Open-Channel SSD（OCS）定义了一种通用的，高效率的主机端直接访问 FLASH 的标准接口，百度基于此开发出一套高性能KV存储引擎，有效减少写放大对设备性能的影响。 01 当前KV的不足之处 目前KV的成熟应用场合有： 内存数据库及其持久化，如Redis、Pika； 分布式文件存储系统底层存储接口，如Ceph中使用Bluestore； 关系数据库存储引擎，如MySQL中的MyRocks引擎。 由于单机内存总量的限制，内存KV有持久化到硬盘的需求，而基于硬盘的KV数据库多使用LSM Tree的方式在文件系统中实现（如RocksDB）， 在实际应用中会出现以下问题： 极高的写放大。由于WAL的机制，一份数据落盘即出现“双写”的效果，产生1倍写放大。WAL(Write-ahead logging)记录了数据持久写入DB之前的变更，是传统数据库保证数据安全性的必要动作。由于compaction机制的存在，新数据的写入会导致旧数据被反复合并，最终一份数据的写入实际会造成2倍以上的写入量。业界存储设备已经全面转向SSD，而SSD的寿命是有限的

ceph 配置文件. 来源： oschina 链接： https://my.oschina.net/innovation/blog/4282647

如何在线关闭一个tcp socket连接？ 你可能会说，简单，netstat -antp找到连接，kill掉这个进程就行了。 # netstat -antp|grep 6789 tcp 0 0 1.1.1.1:59950 1.1.1.2:6789 ESTABLISHED 45059/ceph-fuse # kill 45059 连接确实关掉了，进程也跟着一起杀死了。达不到“在线”的要求。 有没有办法不杀死进程，但还是可以关闭socket连接呢？ 我们知道，在编码的时候，要关闭一个socket，只要调用 close 函数就可以了，但是进程在运行着呢，怎么让它调用 close 呢？ 在 superuser 上看到一个很棒的方法，原理就是 gdb attach 到进程上下文，然后 call close($fd) 。 1、 使用 netstat 找到进程 # netstat -antp|grep 6789 tcp 0 0 1.1.1.1:59950 1.1.1.2:6789 ESTABLISHED 45059/ceph-fuse 如上，进程pid为45059。 2、 使用 lsof 找到进程45059打开的所有文件描述符，并找到对应的socket连接 lsof -np 45059 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME ceph

PV,PVC概述 PV的全称是: PersistentVolume (持久化卷)，是对底层的共享存储的一种抽象，PV由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如Ceph、GlusterFS、NFS等，都是通过插件机制完成与共享存储的对接. PVC的全称是: PersistenVolumeClaim (持久化卷声明)，PVC是用户存储的一种声明，PVC和Pod比较类型，Pod是消耗节点，PVC消耗的是PV资源，Pod可以请求CPU的内存，而PVC可以请求特定的存储空间和访问模式。对于真正存储的用户不需要关心底层的存储实现细节，只需要直接使用PVC即可. 但是通过PVC请求一定的存储空间也很有可能不足以满足对于存储设备的各种需求，而且不同的应用程序对于存储性能的要求也能也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes又为我们引入了一个新的资源对象: StorageClass,通过StorageClass的定义，管理员可以将存储资源定义为某种类型的资源，比如快速存储、慢速存储等，用户根据StorageClass的描述就可以非常直观的知道各种存储资源特性了，这样就可以根据应用的特性去申请合适的存储资源了. PV和PVC生命周期 PV可以看作可用的存储资源，PVC则是对存储资源的需求，PV和PVC的互相关系遵循如下图 资源供应

清晨北京 再大的雾霾也会过去 今天正好北京的雾霾散去，空气瞬间变好，也赶上了Ceph中国社区公众号变更，我来讲述下Ceph中国社区的故事——一项开源技术和一群充满朝气的年轻人之间的故事。一个开源社区从建立到发展壮大，就像一个创业公司的奋斗史，跌宕起伏。谨以此文献给在过去两年多的时间中支持Ceph中国社区成长的每一个人。 美好的展望 —— Ceph中国社区雏形 2014年7月份，随着我开始接触OpenStack和Ceph，当初发现国内关于Ceph的资料是少之又少，唯一有几个QQ群还都是潜水员。当初讨论问题还都是在OpenStack群和CloudStack群，索性我就建立了一个Ceph中国社区的QQ群，把大家都召集到了一个比较专一的群来进行讨论Ceph问题。随着Ceph在国内的发展越来越多的人开始接触Ceph，随之而来的是很多入门级问题，QQ群不便于记录和保留问题和答案，所以2015年初决定用论坛形式来保留和记录一些常见的问题和答案。当初我的决定，既然是社区那么就要有完善的体系架构，例如：微信/微博、网站/论坛、QQ群/微信群、Mail List等展示、推广平台。接着加入了几位早期成员，分别来负责几大平台。然而我的定位就是对接几大平台负责人即可，然而理想是美好的，现实是残酷的。先从微信公众号说起，自从某人注册了微信公众号之后就再也没维护过，当初推三阻四说不会运营，我说好没事，我来负责

本文主要介绍on_applied、on_commit、on_applied_sync、on_all_commit、on_all_applied在数据IO处理流程中的回调代码梳理。写的比较简单，不过关键点都已经整理。以filestore为例： OSD端详细程分析： https://blog.51cto.com/wendashuai/2497104 主端： PrimaryLogPG::execute_ctx()->issue_repop(repop, ctx)->pgbackend->submit_transaction()->issue_op(); parent->queue_transactions() 1. void PrimaryLogPG::issue_repop(RepGather *repop, OpContext *ctx) { Context *onapplied_sync = new C_OSD_OndiskWriteUnlock() Context *on_all_applied = new C_OSD_RepopApplied(this, repop); Context *on_all_commit = new C_OSD_RepopCommit(this, repop); pgbackend->submit_transaction(//->

https://zhuanlan.zhihu.com/p/45084771 分布式存储系统通过将数据分散到多台机器上来充分利用多台机器的资源提高系统的存储能力，每台机器上的数据存放都需要本地的单机存储系统，它是整个分布式存储系统的基础，为其提供保障。设计高性能、高可靠的分布式存储系统离不开高效、一致、稳定、可靠的本地存储系统。 ceph是目前业内比较普遍使用的开源分布式存储系统，实现有多种类型的本地存储系统；在较早的版本当中，ceph默认使用FileStore作为后端存储，但是由于FileStore存在一些缺陷，重新设计开发了BlueStore，并在L版本之后作为默认的后端存储。BlueStore的一些设计思想对于设计满足分布式存储系统需求的本地存储系统具有参考意义，因此我们将分多个章节对BlueStore的一些原理进行剖析，供读者进行参考和探讨。 在这一章中，我们将要了解BlueStore的诞生背景，以及它的一些设计思想。 为什么需要BlueStore 前面提到，BlueStore的诞生背景是由于FileStore存在的一些缺陷，这些缺陷具体是什么？ IO放大 FileStore底层使用POSIX规范的文件系统接口，例如xfs、ext4、btrfs，然而这类文件系统本身不支持数据或元数据的事务操作接口（btrfs提供事务钩子的接口，但是测试过程中发现会导致系统宕机）

https://www.micron.com/about/blog/2018/may/ceph-bluestore-vs-filestoreblock-performance-comparison-when-leveraging-micron-nvme-ssds BlueStore 是 Ceph 的新存储引擎 ，是社区版的默认配置。 BlueStore性能数字不包含在我们当前的 Micron Accelerated Ceph存储解决方案 参考架构中，因为 Red Hat Ceph 3.0 目前不支持它 。 我在 Ceph参考架构硬件上 对社区版 Ceph Luminous（12.2.4） 进行了 性能测试， 并将结果与​​我们在此博客中在RHCS 3.0中实现的FileStore性能进行比较。 4KB随机写入IOPS性能提高18％，平均延迟降低15％，尾部延迟降低99.99％高达80％。 使用BlueStore，在更高的队列深度下，4KB随机读取性能更好。 该解决方案针对块性能进行了优化。 使用Linux中的Rados Block Driver进行随机小块测试 ，在2插槽存储节点 中使铂级8168 Intel Purley 处理器 饱和 。 每个存储节点有10个驱动器，该架构具有232TB的可用存储容量，可通过添加额外的1U存储节点进行扩展。 参考设计 - 硬件 测试结果和分析