EMC设备参观

产品： unity500

 

实物拍照：

前面板：

上面是一个扩展柜，下面是一个主机，都是2u的设备

后面板：

从后面来看，扩展柜比主机要短一截

（话说，这布线也够烂的）

其它：

  • unity500就是最多支持500块儿盘，unity400就是最多支持400块儿盘
  • 从前面板可以看到，每个扩展柜（或主机）支持2.5英寸盘25个，（具介绍，如果是3.5英寸盘类型的盘柜的话，可以插15个）
  • unity的web管理界面常用到的功能是池子的创建、lun的创建等；
  • 不满意的地方： 每个磁盘只能属于一个池子

Docker 源码build rpm包

官方文档：

https://github.com/docker/docker-ce-packaging/tree/master/rpm

 

环境搭建：

安装并启动docker就行：

 

命令很简单：

 

打包原理：

从make命令说起，通过docker容器对engine  cli分别进行打包，通过git获取版本号信息，通过docker-ce-packaging/rpm/Dockerfile.x86_64 构建一个基于centos:7 的容器镜像，镜像中安装编译环境（golang），容器挂载外部的一些目录，即，输入来自于外部目录，编译结果输出到外部目录；容器镜像直接启动rpmbuild命令进行构建，构建的详细步骤都在rpm的spec文件中，构建过程中还需要下载有些其他的源码

 

部分细节：

rpmbuild 命令：

 

容器挂载的外部目录：

 

问题记录：

  1. git 版本需要支持 -C 选项
  2. engine 的路径不小心写错了，导致engine的源码文件没有打进去，修改后OK

 

构建优化：

  1. 将github.com 解析到自己的代理服务器，加速下载构建中依赖的代码
  2. 将Dockerfile.x86_64中golang安装包下载地址修改为国内地址，只需将golang.org 修改为golang.google.cn 即可，加速下载golang安装包，当然，更快的办法是改为本地的地址
  3. 更快的办法是，自己build一个自己的环境，用完也不要销毁，每次自己直接执行rpmbuild -ba docker-ce.spec 就行了，不过注意：
    1. 构建过程中需要git clone一些代码，如果目录已经存在，就报错的，所以，可以做一个假的git，使得目录已存在就不再clone，这样还快些

 

owncloud 配置openstack对象存储作为外部存储

本人使用的owncloud版本号： 8.2.8

第一步：

使用admin账号在“管理”部分开启外部存储配置：

第二步：

在任意账号（也可以是管理员账号）配置外部存储：

 

注意：

  • 这里支持的keystone协议版本号只能是v2.0 的，不可配置，所以Identity URI 类似于： http://openstack-controller:5000/v2.0/
  • 其中的swift就是对象存储服务的名字，可以通过openstack endpoint list查到
  • 其中的test（bucket）就是openstack中对象存储部分创建的一个容器的名字，当然，如果没有预先创建的话，会自动创建的，所以，你可以随便写

 

问题：

  • 只要openstack对象存储中的容器被owncloud挂载过，容器根目录就会出现一个名字为 “.” 的文件，该文件在owncloud中看不见的，在openstack-dashboard中可以看见，但是删除总失败，而且，如果不删除该文件的话，容器也是删除不了的; 测试发现，openstack-dashboard中是创建不了一个名字叫做”.” 的目录的，相关issue： https://github.com/owncloud/core/issues/7191
    • 解决办法：
      • 通过openstack命令删除 “.” 文件：
      • end
    • 总结：这里似乎暴露了两个问题：
      • owncloud为什么要创建一个 “.” 文件，真的有必要吗？而且，就算是把 “.” 文件删除掉了，只要owncloud一访问，该文件就又出现了，暂且不太影响，pass
      • openstack-dashboard为什么就删除不了 “.” 文件，应该是个bug吧

 

owncloud + openstack 对象存储的好处：

  • 给owncloud找了一个可靠的存储
  • 给openstack对象存储找了一个比较好的前端
    • 可以通过浏览器直接访问
    • 也可以通过webdav的方式直接mount到各种操作系统和终端（windows、linux、手机端等）
      • linux 上mount，eg：

参考：

ceph 之 choose 和 chooseleaf

语法说明

即： 选择 $n 个不同的bucket， 其中， $n = 0 意味着需要多少个副本就选择多少个bucket， $n = -1 意味着还需要选择多少副本就选择多少副本，返回结果是bucket，如果bucket 是osd自然就是叶子节点

 

即： 选择 $n 个不同的bucket，然后，再从每个bucket中任意选择一个osd，相当于：

 

这种情况下，显然chooseleaf比choose简单许多，表达的意思都是以bucket为故障域，在里面选择$n 个osd， 这也是比较常见的情况

 

情况二：

那么，如果我有多个row，但是期望将3份数据都存放在同一个row下，并且选择3个不同的rack存放呢？表达如下：

等价于：

 

情况三：

假如我有5个row，但是仅仅希望存储的两个副本分别存放在row1和row2（我们知道，每个bucket都是有名字的），而不是随意选择两个，然后以rack为故障域来选择osd，该如何写呢？

这时候，仅仅使用choose和chooseleaf就搞不定了，还记得take语法吧，如下：

 

 

参考：

ceph 之 pg报警

现象：

 

分析：

  1. 哪个pool的问题？
  2. 原因： 某个pool中单个pg的对象数量超过了集群每pg对象数量平均值的10倍； 并不意味着肯定是有问题的
  3. 重现方法：只要你的集群中至少有一个pg是较多使用的，那么你再多创建几个pool，pg设置的大一些，这个报警就可以出现

解决办法：

  1. 删掉没用的pool，或者：
  2. 调整参数：
    1. 如下： （需要重启）
  3. 调整报警的pool的pg数量

 

思考：

  1. 既然pg中对象太多就会报警，那么，创建pool时就指定一个较大的pg值（如： 1024）不就可以了？ 这样也不行，pg数量太大，理论上会影响性能，而且，单个osd上pg数量太多（超过mon_pg_warn_max_per_osd） 也会报警： http://blog.csdn.net/styshoo/article/details/62722679 查看每个osd上pg数量的方法：

    然而，我的osd上的pg数量也超过了300的设置值了，没有报警呢
  2. 具体需要调整的选项需要参考对应版本的文档或代码，如，12.2.1 的release notes 中就有这样的说明：
    The maximum number of PGs per OSD before the monitor issues a warning has been reduced from 300 to 200 PGs. 200 is still twice the generally recommended target of 100 PGs per OSD. This limit can be adjusted via the mon_max_pg_per_osd option on the monitors. The older mon_pg_warn_max_per_osd option has been removed.

 

参考：

ceph 块儿设备之读测试

缘起：

使用dd读取一个大文件时，速度可达 100MB+/s， 但是cat读取大文件时，速度才达到 30MB/s，为何？

由于ceph块儿设备是从网络上读取数据，读取数据的效率和网络的性能由于直接关系，同时也和每次读取的块儿的大小有直接关系：

在块儿大小为100MB的情况下，读取速度可达到 120MB/s

在块儿大小为1MB的情况下，读取速度可达到 70MB/s

在块儿大小为64KB的情况下，读取速度可达到 30MB/s； ，然而cat命令每次read的大小正好是64KB

针对这种情况，如果本机有较大内存的话，不妨先通过dd大块儿的方法使得文件被cache起来，然后再做其它类似cat的操作;

 

另外： 增加IO大小，到达底层之后，会变成多个IO请求，相当于底层同时又多个IO请求，实际上是相当于增加了队列深度。

ceph 之 纠删码操作

通过命令行创建纠删码规则

  • 首先，需要创建 erasure-code-profile ，当然，也可以使用默认的 erasure-code-profile ，列出现有的 erasure-code-profile ：
  • 查看指定erasure-code-profile 的详细内容：
  • 自定义erasure-code-profile ， 创建一个只用hdd的 erasure-code-profile：

    可用的选项有：

    • crush-root: the name of the CRUSH node to place data under [default: default].
    • crush-failure-domain（故障域）: the CRUSH type to separate erasure-coded shards across [default: host].
    • crush-device-class（设备分类）: the device class to place data on [default: none, meaning all devices are used].
    • k and m (and, for the lrc plugin, l): these determine the number of erasure code shards, affecting the resulting CRUSH rule.
  • 根据erasure-code-profile 创建crush rule：
  • 查看crush rule：
  • 创建一个使用纠删码规则的pool

    语法： osd pool create <poolname> <int[0-]> {<int[0-]>} {replicated|erasure} [<erasure_code_profile>] {<rule>} {<int>}
    尽管crush rule 也是根据erasure_code_profile来创建的，但是这里创建纠删码pool的时候，还是需要明确指定erasure_code_profile的
    参考： http://docs.ceph.com/docs/master/rados/operations/pools/
  • 调优：

    目前，这个fast_read 之针对纠删码池有效的
  • 如果需要在该pool创建rbd，则需要：
    • 参考： http://docs.ceph.com/docs/master/rados/operations/erasure-code/
    • 创建一个replication pool来做cache tier

      其实，不仅纠删码池可以做cache tier，replication 池子也能做cache tier，因为，我们可能有一批ssd盘，我们就可以在ssd上创建pool来充当sas盘的cache tier以提高性能；结合纠删码、replication、sas、ssd，我们可以做出多种不同性能的存储用以应对不同的场景。
    • 然后 ceph 会提示： 1 cache pools are missing hit_sets  ， 还要设置 hit_set_count 和 hit_set_type

通过编辑crushmap来添加规则

参考：

 

实战中的问题：

  1. 12个SAS在 60MB/s 的速度evict的时候，磁盘都很慢了，每个盘达到100左右的tps， 20MB/s左右的读写；比较坑的是，我基本没法控制evict的速度，只好静静地等待evict结束
  2. evict 的同时还在promote， promote的速度倒是可控,但是 osd_tier_promote_max_bytes_sec 默认是5242880 字节（并不算很大）； 问题：池子已经没有写入了，为何还在evict和promote？
  3. 修改cache-mode试试： 按说，修改cache-mode为proxy时，就不应该再出现evict和promote了

    果然，修改之后，ceph -s 立刻就看不到evict和promote了 🙂
  4. 查看cache-mode:

vsftp in docker

当vsftpd在容器里面，而且容器IP又是host内部的私有IP的情况，client采用passive模式来下载数据能行得通吗？ 可以的

  1. passive模式下，vsftpd需要listen临时端口来传输数据，所以docker创建容器时，不仅要暴露21端口，还要暴露可能listen的临时端口，为了不映射太多端口，可以在vsftpd的配置文件中配置可能的临时端口的范围
  2. passive模式下，vsftpd需要通过协议内容告知client临时端口及IP地址，然而，容器网卡IP地址显然是不能被client直接访问到的，庆幸的是，vsftpd配置文件中有关于可以告知client的ip地址的配置，该ip地址并不要求本机上必须有的，显然该配置是给类似情况准备的

kvm ceph rbd

每个kvm虚拟机进程，如果挂载N个rbd设备，则会有N个 fn-radosclient 线程，每个fn-radosclient 线程针对特定的osd只有一个connection； 如此，一个rbd设备上的某块儿数据如果落在了相同的osd上，（猜测rados协议不会再同一个连接上同时做多个事务），则意味着不可能并行写入，于是乎，特别是对于随机读写，网络延迟对存储效率有着直接的影响，即使虚拟机内部多线程也无济于事，因为kvm进程中的fn-radosclient 只有一个