云运维、容器、培训是2016年云计算三个趋势

发表于2015/12/16由风河

As the new year approaches, it’s a good time to look forward to what the key trends will be, so we can take advantage of them thoughtfully and effectively.

Here are three key cloud trends I’m certain you’ll see unfold in 2016.

继续阅读 →

发表在 Common | 标签为 | 云运维、容器、培训是2016年云计算三个趋势已关闭评论

ZDX和C180对比使用感受

发表于2015/12/06由风河

风哥并不热爱驾驶，平时也挺宅的，假期偶尔会跑个小长途。因为有讴歌ZDX和奔驰C180这两款风格完全不同的车，日常中也经常使用，因此对比写一下两者的使用感受。

twocars

两车停到一起的合影。这款ZDX和C180都停产了。ZDX最后一批引进国内应该是2012年，而C180也是老款，2013年底是最后一批。不过，ZDX是彻底停产了，而C180是更新换代。新一代的C级外观更加漂亮，但新C180的发动机换成了1.6T，我这款是1.8T。

继续阅读 →

发表在 Common | 标签为 , | ZDX和C180对比使用感受已关闭评论

监控ceph

发表于2015/12/03由风河

ceph管理里最常输入的命令可能是ceph health，它输出ceph的健康状态。

$ ceph health
HEALTH_OK

如果返回不是HEALTH_OK就要注意，可能有PG处于非active + clean状态。对于有问题的PG，还可进一步运行ceph health detail命令，输出它们的详情。

$ ceph health detail
HEALTH_OK

当然我这里没有问题PG存在，返回都是OK。

继续阅读 →

发表在 Common | 标签为 , | 监控ceph已关闭评论

管理ceph的pool

发表于2015/11/30由风河

pool是ceph存储数据时的逻辑分区，它起到namespace的作用。其他分布式存储系统，比如Mogilefs、Couchbase、Swift都有pool的概念，只是叫法不同。每个pool包含一定数量的PG，PG里的对象被映射到不同的OSD上，因此pool是分布到整个集群的。

pool有两种方法增强数据的可用性，一种是副本（replicas），另一种是EC（erasure coding）。从Firefly版本起，EC功能引入。在EC里，数据被打散成碎片，加密，然后进行分布式存储。ceph由于其分布式能力，处理EC非常成功。pool在创建时可以设置这两种方法之一，但不能同时设置两者。

继续阅读 →

发表在 Common | 标签为 , | 管理ceph的pool已关闭评论

调整ceph的PG数

发表于2015/11/26由风河

PG全称是placement groups，它是ceph的逻辑存储单元。在数据存储到cesh时，先打散成一系列对象，再结合基于对象名的哈希操作、复制级别、PG数量，产生目标PG号。根据复制级别的不同，每个PG在不同的OSD上进行复制和分发。可以把PG想象成存储了多个对象的逻辑容器，这个容器映射到多个具体的OSD。PG存在的意义是提高ceph存储系统的性能和扩展性。

继续阅读 →

发表在 Common | 标签为 , | 调整ceph的PG数已关闭评论

调整ceph的CRUSH布局

发表于2015/11/25由风河

CRUSH的全称是Controlled Replication Under Scalable Hashing，是ceph数据存储的分布式选择算法，也是ceph存储引擎的核心。在之前的博客里介绍过，ceph的客户端在往集群里读写数据时，动态计算数据的存储位置。这样ceph就无需维护一个叫metadata的东西，从而提高性能。

ceph分布式存储有关键的3R: Replication（数据复制）、Recovery（数据恢复）、Rebalancing（数据均衡）。在组件故障时，ceph默认等待300秒，然后将OSD标记为down和out，并且初始化recovery操作。这个等待时间可以在集群配置文件的mon_osd_down_out_interval参数里设置。在recovery过程中，ceph会重新产生受故障影响的数据。

继续阅读 →

发表在 Common | 标签为 , | 调整ceph的CRUSH布局已关闭评论

维护ceph的crushmap

发表于2015/11/23由风河

在安装ceph的文档里，也提到了如何查看、编辑和更新crushmap。crushmap与ceph的存储架构有关，在实际中可能需要经常调整它。如下先把它dump出来，再反编译成明文进行查看。

$ ceph osd getcrushmap -o crushmap.original
got crush map from osdmap epoch 56
$ crushtool -d crushmap.original -o crushmap

继续阅读 →

发表在 Common | 标签为 , | 维护ceph的crushmap已关闭评论

安装ceph测试环境

发表于2015/11/16由风河

刚开始我手头有2个虚拟机，系统是Ubuntu 12.04，因此用其中一个安装所有ceph服务（包括mon、osd），一个作为admin节 点。后来尝试把admin节点也作为ceph client，发现Ubuntu 12.04的默认内核版本太低，不兼容rbd 。于是让同事新分配了一个新的虚拟机，Ubuntu 14.04系统，用作ceph client。3台vm都只有一个内网IP。测试服务的架构如下：

clustermap

上述节点的作用说明如下：

  • admin node: 仅作集中部署用途，运行ceph-deploy命令
  • ceph node: 运行所有ceph服务，不过我这里只启用了mon、osd
  • client node: 运行ceph的块存储客户端（rbd client）

继续阅读 →

发表在 Common | 标签为 , | 安装ceph测试环境已关闭评论

ceph对象的存储结构

发表于2015/11/09由风河

对一个已知对象，可以根据CRUSH算法，查找它的存储结构。比如data这个pool里有一个文件resolv.conf：

$ rados -p data ls
resolv.conf

显示它的存储结构：

$ ceph osd map data resolv.conf
osdmap e43 pool 'data' (0) object 'resolv.conf' -> pg 0.9f1f5993 (0.13) -> up ([1,2,0], p1) acting ([1,2,0], p1)

输出结果说明：

  • osdmap e43: 这是osdmap的epoll版本
  • pool ‘data’: 这是pool名字
  • object ‘resolv.conf’: 这是对象名字
  • pg 0.9f1f5993 (0.13): 这是PG号
  • up ([1,2,0], p1): 存储该PG的3个OSD都是活跃的，这是一个有序数组，第一个是primary OSD
  • acting ([1,2,0], p1): 说明该PG存储在哪3个OSD里，同上也是有序数组

ceph osd map命令只是自己计算一遍CRUSH，它并不确认目标pool里是否真有这个对象，所以随便输入什么文件名，它总是返回成功。

继续阅读 →

发表在 Common | 标签为 , | ceph对象的存储结构已关闭评论

荷包岛

发表于2015/11/08由风河

荷包岛位于珠海西南端，从高栏港过去，坐船大约20分钟。下船后再坐大巴翻过一座小山，到达美丽的大南湾。整个岛很小，才13平方公里。岛上也没多少商业开发，原始生态保护较好。大南湾的沙滩不错，海水也干净。挨着海边有酒店、餐厅、烧烤场。基研中心在此度过一个休闲的周末，白天游泳，晚上烧烤、抓螃蟹，消化掉几箱啤酒，留下几多欢声笑语。

下大巴后，站在半山腰俯视大南湾，天高云淡、碧海银滩： 继续阅读 →

发表在 Common | 标签为 , | 荷包岛已关闭评论