前言 在跟一个朋友聊天的时候,聊到一个技术问题,他们的一个环境上面小文件巨多,是我目前知道的集群里面规模算非常大的了,但是目前有个问题,一方面会进行一倍的硬件的扩容,而文件的数量也在剧烈的增长着,所以有没有什么办法来 缓解这个增长的压力 当时也没想到太多的办法,只是觉得这么用下去风险太大 后来在思考
前言 在看一个Linux Vault 2017的资料的时候,看到红帽分享的一个测试的过程,里面关于小文件元数据性能测试的,环境准备的还比较好,可以作为一种测试模型 测试用例 测试用例一: 使用find -name 测试 find -size 测试 测试用例二: 使用find -name 测试 fin
前言 在ceph的研发群里看到一个cepher提出一个问题,编译的ceph的二进制文件过大,因为我一直用的打包好的rpm包,没有关注这个问题,重新编译了一遍发现确实有这个问题 本篇就是记录如何解决这个问题的 打rpm包的方式 用我自己的环境编译的时候发现一个问题,编译出来的rpm包还是很大,开始怀疑
前言 之前看过一个朋友一篇文章,讲述的是Vsan为什么使用的是两副本,而ceph则大多数情况下需要三副本,当时个人观点是这个并不是关键点,但是在仔细考虑了问题的出发点以后,这个也可以说是其中的一个点 一个集群数据丢失可以从多方面去看 发生丢失数据的事件,这个来说,出现这个事件的概率是一致的,同等硬件
前言 前一篇介绍了docker在命令行下面进行的ceph部署,本篇用docker的UI进行ceph的部署,目前来说市面上还没有一款能够比较简单就能直接在OS上面去部署Ceph的管理平台,这是因为OS的环境差异化太大,并且包的版本,以及各种软件的适配都可能造成失败,而docker比较固化环境,因此即使
前言 容器和ceph的结合已经在一些生产环境当中做了尝试,容器的好处就是对运行环境的一个封装,传统的方式是集成为ISO,这个需要一定的维护量,而容器的相关操作会简单很多,也就有了一些尝试,个人觉得如果玩的转容器可以考虑,当然得懂ceph,不然两套系统在一起,问题都不知道是哪个的,就比较麻烦了 本篇是
前言 系统中有些地方会进行资源的限制,其中的一个就是open file的限制,操作系统默认限制的是1024,这个值可以通过各种方式修改,本篇主要讲的是如何在线修改,生产上是不可能随便重启进程的 实践 查看系统默认的限制 [root@lab8106 ~]# ulimit -a|grep open op
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号