如何缓解 index shard 过大造成的影响 下面这些都是属于应急操作，属于快速止血止痛，部分操作属高危，一定要谨慎使用。 1 调整OSD的几个op超时参数 下面的几个参数只是用例，具体根据各位线上情况进行调整，但是不宜过大。 osd_op_thread_timeout = 90 #default is 15 osd_op_thread_suicide_timeout = 300 #default is 150 filestore_op_thread_timeout = 180 #d
要增加一个 OSD，要依次创建数据目录、把硬盘挂载到数据目录、把 OSD 加入集群、然后把它加入 CRUSH Map。
CRUSH 算法通过计算数据存储位置来确定如何存储和检索。 CRUSH 授权 Ceph 客户端直接连接 OSD ， 而非通过一个中央服务器或代理。数据存储、检索算法的使用，使 Ceph 避免了单点故障、性能瓶颈、和伸缩的物理限制。
RGW的index数据以omap形式存储在OSD所在节点的leveldb中，当单个bucket存储的Object数量高达百万数量级的时候，deep-scrub和bucket list一类的操作将极大的消耗磁盘资源，导致对应OSD出现异常，如果不对bucket的index进行shard切片操作(shard切片实现了将单个bucket index的LevelDB实例水平切分到多个OSD上)，数据量大了以后很容易出事。
对象存储以独立的对象的形式管理数据，而不是传统的文件层次结构或块存储的形式。每个对象包括数据、元数据和唯一标识符。元数据是描述数据的信息，比如创建日期、类型和其他相关信息。
CRUSH 算法通过计算数据存储位置来确定如何存储和检索。 CRUSH 授权 Ceph 客户端直接连接 OSD ，而非通过一个中央服务器或代理。数据存储、检索算法的使用，使 Ceph 避免了单点故障、性能瓶颈、和伸缩的物理限制。
关于 Ceph 更详细的介绍和环境部署可以参考这篇文章：分布式存储系统 Ceph 介绍与环境部署
WORM将在08,09,10(月)01,02,03,04,05,06,07,08,09,10(日)周一,周二00:00:00-11:30:39禁用
- 图虽然很复杂，但如果理解了几个基本操作的含义就很好读下来了，这里是三个操作的伪代码，take和emit很好理解，select主要是遍历当前bucket，如果出现重复、失败或者超载就跳过，其中稍微复杂的“first n”部分是一旦遇到失败，第一种情况是直接使用多备份，第二种情况是使用erasing code基本可以忽略。看着下面的图就更好理解具体的算法了
Ceph对象网关是一个构建在librados之上的对象存储接口，它为应用程序访问Ceph 存储集群提供了一个RESTful风格的网关。
bucket index是整个RGW里面一个非常关键的数据结构，用于存储bucket的索引数据，默认情况下单个bucket的index全部存储在一个shard文件（shard数量为0，主要以OMAP-keys方式存储在leveldb中），随着单个bucket内的Object数量增加，整个shard文件的体积也在不断增长，当shard文件体积过大就会引发各种问题。
一、安装 1.1、创建operator # 安装 git clone --single-branch --branch v1.8.7 https://github.com/rook/rook.git cd rook/deploy/examples kubectl create -f crds.yaml -f common.yaml # 修改配置 vim operator.yaml # 自动发现开启 ROOK_ENABLE_DISCOVERY_DAEMON: "true" # 镜像 # 国外
对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回归，是随波逐流，是对内心的恐惧 ——赫尔曼·黑塞《德米安》
Ceph是一种高度可扩展的分布式存储解决方案，提供对象、文件和块存储。在每个存储节点上，将找到Ceph存储对象的文件系统和Ceph OSD（对象存储守护程序）进程。在Ceph集群上，还存在Ceph MON（监控）守护程序，它们确保Ceph集群保持高可用性。
对象存储诞生之初 谈到为什么要有对象存储，必须聊聊对象存储诞生之前的两大存储模型：块存储和文件存储。 块存储主要是将存储介质的空间整个映射给主机使用的，主机如果需要对这些空间进行读写IO操作，需要先进行分区和格式化处理，形成可以被操作系统识别的逻辑命名空间，之后主机才能通过操作系统对这些存储介质进行读写操作。常见的块存储有磁盘，SSD，NAS、SAN等，这些物理设备都或多或少存在物理上的极限，比如存储空间、性能等都存在物理极限。 文件存储立足于物理存储介质之上，是操作系统对数据管理操作的抽象，这些抽象最终汇
参考资料： https://www.cnblogs.com/ytc6/p/7388654.html http://docs.ceph.com/docs/kraken/start/ https://blog.csdn.net/changtao381/article/details/48015623 https://blog.csdn.net/litianze99/article/details/48438877
毫无疑问，乘着云计算发展的东风，Ceph已经是当今最火热的软件定义存储开源项目。如下图所示，它在同一底层平台之上可以对外提供三种存储接口，分别是文件存储、对象存储以及块存储，本文主要关注的是对象存储即radosgw。
作为文件系统的磁盘，操作系统不能直接访问对象存储。相反，它只能通过应用程序级别的API访问。ceph是一种分布式对象存储系统，通过ceph对象网关提供对象存储接口，也称为RADOS网关（RGW）接口，它构建在ceph RADOS层之上。RGW使用librgw（RADOS Gateway library）和librados，允许应用程序与ceph对象存储建立连接。RGW为应用程序提供了一个RESTful S3/swift兼容的接口，用于在ceph集群中以对象的形式存储数据。ceph还支持多租户对象存储，可以通过RESTful API访问。此外，RGW还支持ceph管理API，可以使用本机API调用来管理ceph存储集群。
工作中存储集群使用了 Ceph 技术，所用的是版本是 Luminous 12.2.4，因为刚刚上手 Ceph，不少概念和问题也都是头一次听说，比如这次的自动分片（auto resharding）。不得不说，Ceph 对象存储目前还是不够完善，Luminous 对于 bucket 中存储大量数据的支持还是不够理想，这造成了不小的使用不便。虽然 Ceph 在着手解决，但还没有达到足够理想的状态。
ceph是模块化和可扩展的，并且有容错设计。先进的分布式存储系统。 ceph凭借其高可扩展性、高可靠性、高性能的特点，逐渐成为openstack\cloudstack、opennebula等主流开源云平台后端存储的首选。可靠性、自平衡、自恢复、一致性 软件定义存储。 可以大幅降低企业存储基础设施的成本。 分布式、可大规模扩展，经济 虚拟平台KVM、VMWARE也支持ceph ceph存储介绍 ceph部署实战 ceph架构和组件 ceph内部构建 ceph部署 ceph存储配置 ceph操作及管理 监控ceph集群 ceph与openstack集成 ceph性能调优和基准测试 1、ceph是什么 ceph是一个开源项目，它提供软件定义的、统一的存储解决方案。ceph可大规模扩展、高性能并且无单点故障的分布式存储系统。容量可扩展至EB级别。1EB=1024PB
Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。
Ceph 对象网关是一个构建在 librados 之上的对象存储接口，它为应用程序访问Ceph 存储集群提供了一个 RESTful 风格的网关 。
Ceph亚太峰会RGW部分议题分享 本次Ceph亚太峰会干货最实在的的要数Redhat的《Common Support Issues and How to Troubleshoot Them》这里把RGW部分摘出来，和大家分享一下，本次议题主要是涉及到RGW中Object数量过多导致的OSD异常如何处理。 故障现象描述 Flapping OSD's when RGW buckets have millions of objects ● Possible causes ○ The first issue h
今天来玩下Ceph的对象存储，在开始之前呢，先扯会闲篇，我觉得生活中处处是非结构化数据，最简单的举例，下面两个行业，一个是直播，一个是摄影。
Ceph Mgr Prometheus 的模块没有提供用户数据使用量的指标，而在 Ceph 日常运维中，我们希望知道哪个用户用了多少存储容量，或者距离 Quota 还有多少，方便自动化扩容等等，所以推荐一个开源的 prometheus exeporter 来通过 radosgw 来输出用户在 Ceph 集群使用的量。 再次明确一下，这个 usage 的监控，主要需要两方面的指标。
###前言 一直想弄对象存储，以前弄过一次，不是很理解region是个什么东西，后来时间和工作上的原因没有再折腾，这两天闲了下来，再次折腾了一次。我是参考的ceph的中文翻译文挡进行的部署和测试。传送门,文档里面介绍的和ceph本身的版本存在脱节的现象，可能初次接触的人会因为服务启动的问题摸不着头脑。 ###关于部署 安装ceph必要的软件包，配置好公共密钥和ceph mon的配置，这里我不再谈了。 对象存储额外需要安装的包是：ceph-radosgw和ceph-common 安装完毕你的系统上应该至少存在三个命令：rados 、 radosgw 、 radosgw-admin 其中整个对象网关服务就是由radosgw来启动的，radosgw-admin负责管理对象资源（用户，权限，bucket），rados基本算一个比较简单的s3客户端（？我这里可能理解不是很精确） ####配置 ceph.conf
之前看过一个朋友一篇文章，讲述的是Vsan为什么使用的是两副本，而ceph则大多数情况下需要三副本，当时个人观点是这个并不是关键点，但是在仔细考虑了问题的出发点以后，这个也可以说是其中的一个点 一个集群数据丢失可以从多方面去看
Ceph最早起源于Sage就读博士期间的工作、成果于2004年发表，并随后贡献给开源社区。经过多年的发展之后，已得到众多云计算和存储厂商的支持，成为应用最广泛的开源分布式存储平台。
很多年以前，Sage 在写CRUSH的原始算法的时候，写了不同的Bucket类型，可以选择不同的伪随机选择算法，大部分的模型是基于RJ Honicky写的RUSH algorithms 这个算法，这个在网上可以找到资料，这里面有一个新的特性是sage很引以为豪的，straw算法，也就是我们现在常用的一些算法，这个算法有下面的特性：
CRUSH是ceph的核心设计之一，CRUSH算法通过简单计算就能确定数据的存储位置。因此ceph客户端无需经过传统查表的方式来获取数据的索引，进而根据索引来读写数据，只需通过crush算法计算后直接和对应的OSD交互进行数据读写。这样，ceph就避免了查表这种传统中心化架构存在的单点故障、性能瓶颈以及不易扩展的缺陷。
需求 随着ipv6使用得越来越广，很多网络设施逐步地需要支持ipv6，而ceph作为可大规模部署的分布式存储系统，ipv6的支持是必选的，本文主要介绍ceph over ipv6的场景及其功能使用
默认情况下只有当单个bucket承载的object数量过多，导致omap过大才会要做reshard，所以理论上reshard操作比较少，但是在开启了Multisite的情况下，一旦对bucket进行了reshard操作，则会破坏原有的元数据对应规则，导致对应的bucket无法进行数据同步，官方从L版本的12.2.8开始才有了如何在Multisite场景下的reshard修复方案。值得注意的是开启了Multisite的环境千万不要开auto reshard。
1、ceph介绍、ceph块存储、ceph对象存储、ceph文件系统、用Calamari监控Ceph、操作和管理ceph集群、深入ceph、ceph生产计划和性能调优、ceph虚拟存储管理器、ceph扩展 2、架构： Ceph monitor：监控器 OSD:Ceph对象存储设备 MDS:Ceph元数据服务器 RADOS：负责保存存储对象 librados:为其他编程语言提供RADOS的接口 RBD：RADOS块设备 RGW:RADOS网关接口 CephFS:文件系统 解决方案：
Ceph RGW 会把 bucket 的索引数据存在 index_pool 里，这个索引池，默认叫做 .rgw.buckets.index，如果一个桶有很多对象，比如说成千上万，甚至到百万，如果恰好你没有给每个 bucket 设置可以存储的最大对象数，那么上百万的索引数据，会给这个 bucket 的读写造成很大的性能影响，试想一下，成百万的大 map，从里面找到需要的对象，那是得花多少时间。 Ceph 0.94版本之后，用户可以给索引文件进行 sharding，rgw_override_bucket_index_max_shards，允许用户给桶 bucket 设置最大的分片数。用户可以在 configuration 文件设置这个参数到 [global] 部分。
Ceph客户端的异步IO机制使用了多个线程来执行IO操作并提高存储性能。下面是它的工作流程和如何提高性能的几个方面：
创建账号 进入ceph-tools pod kubectl -n rook-ceph exec -it rook-ceph-tools-6ccb958485-j7pvb bash 查看可用的对象存储 [root@rook-ceph-tools-6ccb958485-j7pvb /]# radosgw-admin realm list { "default_info": "11f77019-6723-4932-9bd4-d253077d8bca", "realms": [
问题描述 社区群里有人说删除bucket以后还有部分数据残留，用的ceph 10.2.x版本做的验证 测试用例 from boto.s3.connection import S3Connection import boto conn = boto.connect_s3( aws_access_key_id = '', aws_secret_access_key = '', host = 's3.cephbook.com',
本文作者 / 阿杜 玩Docker，玩K8s，玩Harbor 爱技术，爱运动，爱生活 “K8s＆云原生技术开放日”特邀讲师 本文内容源于“K8s&云原生技术开放日”主题演讲——Harbor企业级实践。 Harbor作为腾讯企业云中心底层统一的镜像仓库管理组件，其性能很大程度上决定了上层容器应用的发布时延。为此，我们针对Harbor做了很多性能优化，使得镜像下载速度提升了20倍。 本次分享围绕Harbor性能提升展开，依次介绍Harbor存储选型，Harbor高并发压测以及Harbor备份还原方案……
为了使用 REST 接口, 首先需要为 S3 接口初始化一个 Ceph 对象网关用户. 然后为 Swift 接口新建一个子用户.
CRUSH Map是一个树形结构，OSDMap更多记录的是OSDMap的属性(epoch/fsid/pool信息以及osd的ip等等)。
向单个bucket压测2000W个object，默认设置shard数为16，压测到1800W出现large omap,介绍一下错误定位和如何处理。
Rook v1.11 版本[1] 已经发布！v1.11 是一个功能丰富的版本。主要更新如下：
业务上，用户经常大量写，然后大量删，已知 Ceph 删对象的主要是先标记等 GC 才会真正删除数据的。所以如果用户经常大量写伴随大量删，容易导致容量打爆。 解决的方法，主要是两个方面，如果高警时写入的速度已经很快了，再来解决 GC 的问题已经来不及了，最好是跟业务沟通，停掉部分写，以防 Ceph 集群的 OSD 被写满无法读写，其次就是调整 rgw 的 GC 参数，让更多的线程来参与 GC 的过程。 效果可以从下面重启 rgw 时间和 Ceph Pool Available 容量回升的时间看到，调整 GC 参数之后，GC 过程加速。
1 bucket index背景简介 bucket index是整个RGW里面一个非常关键的数据结构，用于存储bucket的索引数据，默认情况下单个bucket的index全部存储在一个shard文件（shard数量为0，主要以OMAP-keys方式存储在leveldb中），随着单个bucket内的Object数量增加，整个shard文件的体积也在不断增长，当shard文件体积过大就会引发各种问题，常见的问题有: 对index pool进行scrub或deep-scrub的时候，如果shard对应的Obj
在我们的ceph集群中，可能不只有sata盘或者ssd盘，有些时候服务器上同时插了ssd和sata盘用作osd，那如果我们按照默认的crush分布规则，那会使所有pg均分在ssd和sata盘上，造成sata盘的存储空间浪费和整个ceph集群的性能浪费，其实我们可以改变ceph的默认存储规则，来使那些io要求较高的数据存储在由ssd的osd组成的存储池上，将备份数据或者时效性要求不高的数据存储在由sata的osd组成的存储池上，既提高了性能，又可以减少较大数据量存储的成本。
上篇文章主要讲了常见的几种数据保护方式，本文我们主要讲下Ceph有哪些常见的灾备设计方式。Ceph在灾备方面有三大神兵利器：故障域、RBD异地灾备、RGW异地灾备。
前提是需要一个 k8s 环境，k8s 环境的部署可以参考这篇文章：32 张配图详解 K8S 1.24 高可用部署，保姆级详细版！
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
云直播
对象存储
