Ceph

Ceph

有人使用过rancher 1.6.11部署的k8s,连接ceph吗?

回复

overlord 发起了问题 • 1 人关注 • 0 个回复 • 3210 次浏览 • 2017-11-29 10:05 • 来自相关话题

网易视频云:ceph恢复优化

shipinyun2016 发表了文章 • 0 个评论 • 1797 次浏览 • 2016-08-02 09:54 • 来自相关话题

网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术,为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PaaS服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在在线 ...查看全部
网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术,为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PaaS服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在在线音视频平台。

  1.背景

  在对ceph块存储进行性能测试时发现,当有osd重启或者存储机重启时,I/O性能会急剧下降,尤其在随机写的负载下,下降幅度达到90%,并且会持续一段时候才慢慢恢复到正常水平。一开始我们也尝试将恢复相关的参数调低(osd_recovery_max_active=1、osd_recovery_max_chunk=131072、osd_max_backfills=1),以及调整正常I/O和恢复I/O的优先级(osd_recovery_op_priority=10、osd_client_op_priority=63),但是测试结果来看,这些参数的调整没有多大的效果,随机写负载下性能下降仍然很大。

  2.原因分析

  在《ceph基于pglog的一致性协议》一文中分析了ceph的一致性协议,从中我们得知在osd重启、存储机重启等场景下基于pglog的恢复的时候,在peering的时候会根据pglog来构建出missing列表,然后在恢复时根据missing列表逐个进行恢复,恢复的粒度是整个对象大小(默认4MB,有可能有的对象不足4MB,就按对象大小),即使只修改了一个4KB,也需要将4MB的对象拷贝过来,这样100个io就会达到400MB的带宽,对网络及磁盘产生较大的影响。当写io命中正在修复的对象时,也是先修复原来4MB的对象,即需要将4MB的数据通过网络拷贝过来,延迟就会增加很多,然后再写入数据,对于随机写的场景尤其严重,基本都是命中的情况,带来相当大的延迟,从而iops下降(下降幅度80%~90%)。这个影响时间取决于上层的业务量和osd停服的时间。

  

  3.恢复优化

  因为pglog里每条记录里只是记了操作及版本等信息,并没有记录这次操作是修改哪部分数据,所以优化的办法就是在pglog里记录每次操作修改的区间,记为[offset,len](实现时pglog结构里引入dirty_extents来表示),正常写I/O处理时,会写pglog,对应的是一个MODIFY操作,在这条记录里记上修改的区间。

  当一个osd故障重启后,进行peering的时候,合并pglog来构建missing列表时就可以将同一个对象的多次修改的[offset,len]求一个并集,得出故障期间总的修改区间,然后在恢复的时候就能够根据这个范围来恢复这部分增量数据,从而大幅度减少了恢复时的网络和磁盘带宽,以及正常I/O命中恢复对象的等待时间,从而大幅降低对正常I/O的性能影响(尤其是对于随机写I/O的场景)。

  

  针对我们使用的块存储的应用场景,为了减小实现的复杂度,引入一个标记can_recover_partial来表示是否可以进行部分恢复,默认是false,当进行写I/O的处理时记录pglog里的[offset,len],并且标记can_recover_partial为true,然后恢复时就可以根据这个标记只恢复对象内的增量数据。对于无法判断是否可以进行部分优化时,就回退到原有的恢复逻辑去恢复整个对象,需要考虑几种情况,包括:truncate、omap、clone、EC等。

  truncate

  truncate的操作对应的就是截断对象,可以类比于文件系统里的ftruncate的操作(可以将文件截断,或者将文件扩大)。原生ceph的pglog没有TRUNCATE的操作码,它里面的truncate操作都是MODIFY操作,如果一个对象先被修改了,然后又被truncate了,那么在恢复这个对象的时候仍然是按照这整个对象来恢复,有可能因为truncate这个对象变小了(小于4MB),这个不用管, 直接将这个对象读出来拷贝过去就行了。

  但是我们要在pglog里加入[offset, len]来表示修改范围,那么和truncate混在一起后,就需要做区分,为了简单起见,当碰到truncate操作时,将can_recover_partial设置成false,这样truncate的处理就跟原来一样,在我们的使用场景下,trucate操作不常见。

  omap

  omap即objectmap,用来记录对象的扩展属性,因为文件系统的xatrr属性数量及长度都有限制,超过了就需要放到omap中。设置omap属性时,对应到pglog里也是一个MODIFY操作,也就是说omap在多副本间的一 致性也是由pglog来保证的。在恢复的时候合并pglog来构建missing对象时,是不区分属性还是数据,都认为是对这个对象的修改,在恢复的时候都是先恢复恢复属性(xatrr和omap),然后再恢复数据。这样的话,即使一个对象在pglog里只设置了属性,在恢复的时候会连数据一起恢复过来,也即是多了一次数据的拷贝。在块存储的场景下,这个代价是可以接受的,因此不必针对omap做特殊处理。

  clone

  这里的clone指的clone对象操作,就是做了快照之后对原卷进行写入时触发的cow操作。每次clone操作会在pglog里记录一条CLONE的记录,然后在filestore里会根据这个CLONE操作进行clone_range的处理,也就是从原来的head对象(表示卷的数据对象),拷贝数据到新生成的snap对象(即快照的对象)。在peering的时候合并pglog时,没有区分MODIFY和CLONE的,都会构建丢失对象放到missing列表里,也就是说这个missing列表里有可能既包含head对象,也包含snap对象。

  在《ceph rbd快照原理解析》里详细介绍了快照的实现及故障恢复的处理,引入恢复优化后,对于snap对象还是按照原来的逻辑处理,而对于head对象就要做不同处理,按照对象的修改区间来进行恢复。

  EC

  块存储下都是采用多副本的策略,而不会用到纠删码(EC),一般是ceph对象存储里才用到纠删码,因此我们不考虑这种情况,遇到纠删码相关的就就按照原有的逻辑进行恢复。

  4.优化效果

  下面的测试结果对比了优化前和优化后的性能(主要针对随机读写的场景),从结果上来看,效果显著:

  1)减少了重启osd过程中对集群正常存储I/O性能影响,从优化前的I/O性能下降90%到优化后I/O性能只下降10%;

  2)缩短重启恢复所需要的时间,重启单个osd的恢复时间从10分钟减少到40秒左右;

  

  

  更多技术分享,请关注网易视频云官方网站或者网易视频云官方微信(vcloud163)进行交流与咨询

DockOne微信分享(五十一):基于Docker、Mesos、Ceph全新技术栈的三地三中心容灾体系

赵英俊 发表了文章 • 0 个评论 • 9555 次浏览 • 2016-03-30 14:57 • 来自相关话题

【编者的话】以传统的两地三中心容灾体系为基础,将Docker(应用引擎)、Ceph(统一存储)、Mesos(分布式资源调度)这三大主流技术栈,与大二层网络,光纤传输技术结合在一起,实现新一代的三地三中心容灾体系。 @Container ...查看全部
【编者的话】以传统的两地三中心容灾体系为基础,将Docker(应用引擎)、Ceph(统一存储)、Mesos(分布式资源调度)这三大主流技术栈,与大二层网络,光纤传输技术结合在一起,实现新一代的三地三中心容灾体系。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、点融网等公司的技术负责人将带来实践经验分享,4月7日之前购票只需338元,欢迎感兴趣的同学抢购。
#容灾体系架构构想
无标题.png

在设计这个容灾体系架构的时候,我将传统的两地三中心的概念进行了升级,从上图中大家可以看出,其实是一个三地三中心三活的架构。如果不从经济角度考虑,需要在三地之间架设或者租用运营商的裸光纤。在超过3KM以外的距离多模光纤已经存在比较大的损耗,因此可以采用单模裸光纤,将光束以极小的角度打入光纤中,进行长距离高质量的传输。

在分布式资源调度层,Mesos只是作为分布式资源调度,应用的调度交给各种执行框架去做,包括对于如何做到应用的多活高可用,我觉得在这个架构中,只是提供了应用多活的链路、存储、资源调度多活,对于各种应用多活架构都是开放的,都可以在Schedule兼容的情况下进行部署。

最后在应用负载这一块,我选择了负载轮询的方式。其实说实话在这个层面我没有想的特别明白,我所讲的负载轮询是事务处理的负载轮询,就是访问接入是在数据中心A1 A2 A3的,当进行事务操作的时候以一组长连接为颗粒度进行负载轮询。这样设计的目的,是最大程度的避免事务的冲突和数据的瞬时海量并发,当然对于数据并发其实可以使用队列数据库来解决,但是我觉得从底层的机制上需要这种负载轮询的机制来解决。
#容灾体系技术框架
无标题1.png

如之前所说,在设计这个容灾体系的时候,我将两地三中心的概念进行了提升,变成了三地三中心。这样做的原因是当前的光纤传输技术的提升,目前在240KM内是单模裸光纤可以达到10Gb/s的带宽,这已经达到了正常数据中心在汇聚层甚至是核心层设计的带宽。因此,通过DMDW收发设备的转换,可以完全实现在物理层的传输速度上跨地域进行数据的无差别传输。

在统一存储层面,在三个数据中心中分别设立了OSD群和monitor群,在现有体系构想下每个数据中的OSD群包含n个OSD节点,3个monitor节点,这样从三个中心的角度来看,就存在三个OSD群域和9个基于PAXOS服务选举的monitor服务集群.考虑到三中心的的OSD数量规模以及在进行CRUSH算法的数据分布式中的效率,建议设置6副本的模式,即在每个数据中心都存在2个同一个数据的副本。为了保证写操作的效率,可以将最小副本数设置2,这样只要完成2副本的写操作就会返回写成功。这样通过CRUS算法规则的设置,可以保证6副本会平均分布在三个数据中心,在完成最小副本数据的写操作时候也可以保证是写在两个不同的数据中心的。

关于CRUSH算法规则的设置可以看CURSH算法规则

同样在Mesos这一层面也是分为slave群和master群,对于master群来说还是建议每个数据中心采用3个master节点,这样一共9个master节点通过ZooKeeper服务选举来实现多节点的高可用,slave节点可以当成一个统一的集群池,不需要区分不同的数据中心,因为这一层面的高可用是通过PaaS执行框架来实现的,在Mesos层没有必要去考虑,Mesos就是作为最底层的 通用的资源调度平台。

在Docker层,容器镜像作为应用运行的实例,被PaaS执行框架通过Mesos进行调度,在跨数据中心的体系下,需要解决镜像仓库数据一致性和网络的问题。对于镜像仓库数据一致性,我认为有两个方案可以采取,一个是在三个数据中心部署三个镜像仓库,但是镜像仓库对外提供服务可以通过服务代理来进行,也可以继续使用ZooKeeper进行服务选举,这样做的好处就是做到镜像仓库服务的高可用,但是这样也就意味着肯定有两个数据中心的镜像服务是通过远程来获取的,这无疑会增大数据中心间的数据传输压力。另一个方案就是在正常情况下各个数据中心部署的Docker默认是使用自己本地的镜像仓库的,在本地镜像仓库出现问题的时候自动切到next repository server,这种方式我认为是比较好的一种方式,既保证了镜像仓库的高可用性,也可以最大程度减少对珍贵的网络资源的占用。

在容器的网络层面,容器网络面临的最大问题就是跨宿主机通信的问题,而且在我设计的容灾体系中更是变成了跨数据中心通信的问题。因此我认为使用大二层的Vxlan可以很好的解决这一问题。Vxlan的基本原理就是使用UDP来封装TCP数据包,也就是隧道封装技术。其实目前主要的容器网络解决方案如Weave、Fennel也是采用这样的方法。

相关的原理和实现方法,感兴趣的可以参考这篇文章:Vxlan实现原理
#容灾体系的技术选型
##DWDM
DWDM就是所谓密集波分复用(Dense Wavelength Division Multiplexing)技术,指的是一种光纤数据传输技术,这一技术利用激光的波长按照比特位并行传输或者字符串行传输方式在光纤内传送数据。这里简单介绍一下一个关键设备就是OXC,这技术架构图里也提到了这个设备。

OXC是下一代光通迅的路由交换机。在全光网络中的主要功能包括:提供以波长为基础的连接功能,光通路的波长分插功能,对波长通路进行疏导以实现对光纤基础设施的最大利用率,实现在波长、波长组和光纤级上的保护和恢复。OXC设置于网络上重要的汇接点,汇集各方不同波长的输入,再将各路信号以适当的波长输出。目前在电信运营商都在逐步的升级替换成OXC,很快就会进入全光网时代。

在目前的商用单模光纤传输技术中,在240KM以内的单模裸光纤可以达到10Gb/s的带宽。如果需要传输更远的距离则需要一些中继设备,这样的话传输带宽就有所损耗,不过随着后续的技术发展,肯定会可以达到更远的记录和更大带宽,所以这也是在设计容灾体系中更多的是考虑异地双活而不是同城双活,因为在基础硬件设施允许的情况下,异地双活更具有价值。
##Vxlan
Vxlan是由VMware和思科提出的标准,使用了L2oUDP的封装方式,支持16M的tenant ID,主要的与其他的技术不同的是通过OVS来实现大二层网络隧道的起点和终点,隧道的封装在服务器内部的Vswitch就已经打好,然后将物理网络当作大的IP背板加以穿透,大二层范围可以跨DC。以期达到快速部署,灵活创建虚拟化网络的目的。

思科最先提出和推广的是自己的OTV技术,这个技术的是思科在自己的交换机做了修改后实现的,简答来说就是隧道本端的OTV模块会将需要跨越数据中心传输的二层帧完整地打包到一个三层数据包中,然后通过路由交付到对端OTV模块进行处理,再隧道对端的OTV模块经过处理后解析出封装在三层数据包中的源MAC 目的MAC以及所要传输的数据包。这种方式是接触交换机的背板转发能力和解析能力来进行的,性能比较有保障。

VMware作为一家软件厂商,没有自己的硬件网络设备,于是VMware就通过自己的Vswitch来支持实现这种MAC in UDP的数据封装,通过IP的多播技术经过路由来实现跨数据中心通信的目的。具体的在前面的一篇链接中也提到,使用OVS是可以模拟实现大二层网络的。但是从实际使用来说,这种基于OVS的技术还是没有完全的成熟,在性能和稳定性上是存在一定的隐患的。不过,现在SDN这么火爆的情况下,可以相信这是最有前途的解决方案。

需要详细的了解Vxlan的技术可以参考Vxlan的实现实验

关于思科的解决方案介绍可以参考思科解决方案
##Ceph

在这个容灾体系中,统一存储Ceph与Docker结合解决容器存储甚至解决跨数据中心数据一致性的问题都是核心的问题,在构想这个容灾体系的时候我的想法是能够将Docker 的rootfs和volume跑在统一存储Ceph集群上,这也是我选择将Ceph作为面向宿主机提供统一存储服务的原因。在之前一篇腾讯游戏的文章提到了Ceph RBD Graph Driver他们说他们已经完成了这一驱动的开发,将rootfs挂载到RBD结合大二层网络实现容器的带IP飘移。但是他们提交给Docker社区后没有被社区接受。在持久化存储方面可以Docker通过volume driver的方式可以对接Ceph,从而实现容器持久化数据卷的功能,也能轻易实现容器的迁移,但是目前Docker官方还是没有正式支持虽然在一些开源项目已经有了解决方案。

因为Ceph目前作为最主流的统一存储解决方案,所以似乎Ceph在对容器存储的支持没有太多动力,我觉得解决容器持久化存储途径不光是要从容器出发,还要从Ceph项目主动的做一些匹配。因此在这个容灾体系中,在Docker支持将rootfs挂载到RBD上之前,我建议还是使用宿主机的本地存储,至于持久化存储可以使用Ceph挂载到宿主机上的文件目录。
##Docker &Mesos
Mesos的选型我觉得需要根据所选用的执行框架,尤其是非Mesosphere生态的执行框架,需要考虑Mesos对执行框架的兼容性,还有就是对Docker版本的支持,不过这个不是很重要,Mesos和Docker的合作还是比较紧密的。

Docker在1.9版本中加入了很多的新特性来解决网络和存储的问题,其中在网络层面就使用了OVS(Open Vswitch)和VXLAN隧道进行实现,这样完全可以使用OVS的兼容性来实现跨数据中心的大二层网络。不过建议,使用专业的大二层网络的OVS解决方案替代Docker1.9中的OVS。关于Docker与Ceph RBD融合的问题我乐观的认为在Docker2.0版本这个问题应该会得到解决,因为这是Docker进入2.0阶段的一个里程碑,为了更快速的发展和在实际生产中得到应用,这个问题是要必须解决的。
#容灾体系存在的问题和可能的解决方案
在这个容灾体系中使用了大二层网络,但是在大二层应用中有一个很致命的问题就是大二层网络风暴的问题,因为Vxlan技术主要是借助IP多播技术来进行类二层交换的,那么就不可避免的引起网络重启后的网络风暴。大家可以想象三个双活数据中心的上万个容器实例同时发起ARP广播引起的网络风暴是多么的可怕,根据传统网络的情况预估,可以瞬间将三个双活数据中心的网络压垮。

关于这个问题的解决方案,我的想法就是通过SDN的Controller来抑制和屏蔽大规模的启动风暴,如通过策略进行区域性的启动。这个问题供大家讨论。
#Q&A
Q:您这个框架中使用的PaaS执行框架具体是什么?

A:这个是开放的,可以是马拉松也可以Kubernetes,这个都没有具体的限定的。因为我觉得这两个都是比较好的执行框架。



Q: Docker的兴起是否会影响OpenStack云计算的地位会和OpenStack竞争,共存?OpenStack工程师如何面对Docker技术的兴起?Unikernel发展趋势能否取代Docker?

A:竞争肯定是有的,但是共存也是存在的,我认为这是一个灰度的。我觉得OpenStack工程师要拥抱Docker,其实我的主要工作就是向客户设计基于OpenStack的私有云解决方案。Unikernel技术的对手不是Docker,是容器。具体是否会取代,我觉得不一定。



Q3:Vxlan具体怎么实现?是核心交换机旁挂大二层设备吗?另外超远距离,比如北京上海这么做会有什么问题?我们现在遇到延迟问题比较大。

A:VxLan的实现在Vswitch中通过对每次TCP包的UDP封装,Vswitch是在每个宿主机上的。北京到上海的话,就需要通过光纤中继,这会损耗一定的传输带宽,这么远距离的传输只能等待光传输技术的发展以及在应用层面进行弥补。不过在应用层去弥补这不是很好的方案。



Q:ZK集群的部署是怎样?有做哪些调优么?另外网络方面有做哪些监控么?

A:主要是根据实际的请求时延对TIMEOUT进行修改,网络方面的监控是通过专业的安全设备进行。



Q: 那个数据中心部署3机Mesos master,所有数据中心共享一个ZK集群,难道这个ZK集群如何在多数据中心部署,还有因为网络延时导致slave掉了后,或者executor挂了后怎么处理孤儿容器。

A:ZK是每台Master节点上的,由于使用了大二层网络,所以所有的ZK就相当于在同一个局域网内部署的。对于孤儿容器,是Kill掉然后替换的。



Q:请问在你们设计的方案中通常建议用户租用几条裸纤来实现三地三中心,同时考虑过租用长距离裸纤给用户带来的长期运维成本吗?

A:恩,这是个好问题,我在准备这次分享的时候也在考虑这个问题。这个设计方案的前提是客户有这样的需求,需要支付这样的成本去实现。从技术的角度,双纤是性能与经济性的平衡点。



Q:请问关于事务处理的负载轮询,如果使用长连接,如何保证每个连接负载是均匀的,同时这里的事务是指存储层的还是应用层的,如果是应用层是如何保证事务的?

A:这个确实比较难,可以采用类似于一致性哈希环的思想,就是尽可能多的将轮询环进行分割,这样长连接就会尽可能的均衡分配。负载轮询是在应用层面进行轮询的。



Q:你们这套架构上生产环境了吗?Ceph是强一致性的,6个副本延迟会不会大?六个副本是不是有点浪费存储空间?大规模写入的时候IO会不会是瓶颈(Ceph 先写Journal,再写磁盘)?另外,你们是全SSD吗?

A:这套架构没有上生产环境。这是我们公司做的一个前瞻性方案设计研究。在Ceph的副本配置中,有一个最小副本数,可以先设置一个最小副本数实现快速的写操作。之所以6副本,主要是防止避免过度频繁的数据读切换。在这种方案下,建议全部是SSD,当然也可以有选择性的使用SAS。



以上内容根据2016年3月29日晚微信群分享内容整理。分享人赵英俊,来自城云科技企业云事业部,从事云计算大数据云存储的项目咨询和管理工作。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

Kubernetes创建基于Ceph rbd的持久存储问题

回复

一页空纸 发起了问题 • 5 人关注 • 0 个回复 • 5461 次浏览 • 2015-12-21 13:50 • 来自相关话题

Ceph 成立委员会了,不再是 Red Hat 一家主导

kurtzhong 发表了文章 • 0 个评论 • 3718 次浏览 • 2015-10-30 00:17 • 来自相关话题

Red Hat的Ceph是一个广受欢迎的可以支持软件定义对象和文件云存储套件。尽管Ceph的代码是开源的,但其战略方向在过去由Red Hat掌控。然而这即将成为历史。在东京OpenStack峰会(Toyko OpenStack Summit)上,Red Hat ...查看全部
Red HatCeph是一个广受欢迎的可以支持软件定义对象和文件云存储套件。尽管Ceph的代码是开源的,但其战略方向在过去由Red Hat掌控。然而这即将成为历史。在东京OpenStack峰会(Toyko OpenStack Summit)上,Red Hat宣布它的以Ceph为基础,软件定义存储技术的整体技术走向将会转由刚刚成立的Ceph咨询委员会Ceph Advisory Board)来决定。

具体地,“咨询委员会成立的时候,树立的目标即是:与社区广大的技术以及用户委员会携手,扩大并增强社区在Ceph项目中的参与范围和合作”。

除了Red Hat,Ceph咨询委员会的成员还来自Canonical、CERN、Cisco、Fujitsu、Intel、SanDisk和SUSE等公司。可以简单地讲,Ceph以后不再只是Red Hat一家玩了。

然而,这并不令人意外。开源的Ceph已经被证明了能够在单一而统一的存储集群(single, unified storage cluster)里提供对象、块和文件系统的存储。这使得它非常契合云储存基础设施。根据OpenStack Foundation最新的用户调查报告,Ceph是Openstack中用到最多的的块存储解决方案

在一份声明中,Red Hat基础设施工程开发(Infrastructure Engineering Development)的VP Tim Burke说道:

“Red Hat的关键点一直在于在社区之间开展协作,从而取得任何单个公司都不能独立完成的巨大成果。... 尽管这种与社区和合作伙伴的合作,在过去即使是通过非正式的方式进行,也出人意料的强而有力,但是成立Ceph咨询委员会将这种开放的工作关系正式化了。我们期待与Ceph的社区和伙伴成员一起,不仅能为Ceph带来新的功能,还能提升Ceph在新的不同workload下的集成程度和使用简易度。”



Canonocal,Ubuntu Linux的母公司,Red Hat的对手,也对此表示支持。Christian Reis,Canonocal的Storage&Hyperscale的副总,将Ceph的很大一部分功劳归功于Canonocal:

“Canonical从一开始就驱动着Ceph的进步。在Ubuntu Stack和scale-out部署中,我们把Ceph作为一个关键技术。我们很兴奋能成为Ceph顾问委员会的成员,来帮助Ceph扩大决策的来源,推广使用范围和提高成熟度,帮助Ceph成为企业级存储平台。”



Lars Marowsky-Brée,SUSE杰出工程师,又一个Red Hat的对手,补充说:“Ceph咨询委员会是Ceph从一个开源项目走向一个开放的标准并获得行业内协作与采用的关键一步。SUSE很高兴能参与进来,为帮助开源软件定义存储(software-defined storage)革命的实现做贡献。

在此次的进展之前,Ceph代码仓库被攻击。Red Hat的消息人士说,委员会的创建与网站攻击事件没有关联。

欢迎来到Linux和开源的世界,在这里商业对手可以为了代码而手牵手协作。

Ceph社区咨询委员会将会处理Ceph软件定义存储项目的广大问题。而目标是打造Ceph - 人们口中的云存储系统(the cloud storage system.)。

原文:Red Hat opens up Ceph storage to other cloud leaders(翻译:钟最龙 校对:李颖杰)

Kubernetes 使用RBD作为后端存储,无法访问设备。

郑伟-风刃 回复了问题 • 6 人关注 • 2 个回复 • 5380 次浏览 • 2015-08-19 11:59 • 来自相关话题

在Docker里运行Ceph

juliahan 发表了文章 • 1 个评论 • 9317 次浏览 • 2015-08-04 05:11 • 来自相关话题

【编者的话】Ceph是开源社区深受欢迎的存储方案,具有稳定性高、性能好、可扩展性强等特点。原作者的这篇文章展示并探讨了如何将Ceph运行在Docker上,无疑为Docker生态系统的完善迈出了重要一步。存储问题是将Docker应用于生产环境中的备受关注的话题之 ...查看全部
【编者的话】Ceph是开源社区深受欢迎的存储方案,具有稳定性高、性能好、可扩展性强等特点。原作者的这篇文章展示并探讨了如何将Ceph运行在Docker上,无疑为Docker生态系统的完善迈出了重要一步。存储问题是将Docker应用于生产环境中的备受关注的话题之一,这篇文章抛砖引玉,必将激发广大开源和Docker技术爱好者探究现有存储方案与Docker相整合的热情。

Ceph是一个完全开源的分布式存储方案、网络块设备以及文件系统,具有高稳定性、高性能、高扩展性等特点,可应对terabyte到exabyte级别的数据量。通过使用创新性的调度算法(CRUSH)、主动存储节点、以及peer-to-peer的gossip协议,Ceph规避了传统集中控制和lookup table中的扩展性和可靠性问题。Ceph目前在整个开源社区中极受推崇,已被广泛应用与虚拟化平台(Proxmox)、云计算平台(OpenStack、 CloudStack、OpenNebula)、容器技术(Docker)、以及大数据分析系统(Hadoop、作为HDFS的meted服务器)中。

我尝试将Ceph运行在Docker中已经快两年了。直到今天我依然在做这些工作。最近我更是在Docker中部署Ceph方面投入了不小的精力。

(在展开技术细节前,我要特别感谢Sean C McCord对此工作的大力支持,当年的开源ceph-docker项目也的确是基于Sean的早期工作)

现在让我们具体看看如何将Ceph运行在Docker里!
#原理
将Ceph运行在Docker中是一个比较有争议的话题,不少人质疑这样操作的意义。虽然将检测模块、metadata服务器、以及RADOS gateway容器化都没有太大问题,但对于OSD(object storage daemon),事情会变得很棘手。Ceph的OSD专门针对物理机器进行优化,与底层硬件有很多关联。如果物理硬盘失效,OSD也无法运作,这给容器化的场景带来了问题。

坦白地讲,在过去某个时刻我也在想:

“我不知道自己为什么做这个,我只知道有人需要这个功能(当然,他们可能也不知道为什么想要)。我只是觉得想进行技术尝试,那就试试看!”



当然上述想法听起来并不乐观,但这确实是我当时真实的想法。我的观点随后有了一些变化,我来解释下为什么是值得的。希望这个解释也能改变你的看法(我的解释不仅仅是“Docker很酷,所以我们要把所有东西都跑在Docker里!”)。

不少开发者已经花了很多时间将他们的软件容器化。在这个过程中,他们也用过多种不同的工具来构建和管理他们的环境。如果我看到有人用Kubernetes来作为管理工具也一点都不会吃惊。有的人就喜欢将最新潮的技术应用到生产当中,否则他们会觉得工作很无聊。所以当他们看到自己最喜欢的开源存储方案也正在被容器化时,他们会因为这个顺应了“一切容器化”的方式而感到高兴。

与传统的`yum`或`apt-get`不同,容器使得软件的升级和回卷变得容易:我们可以通过`docker stop`或者`docker run`来发布新的daemons版本。我们甚至可以在一台物理机器上运行多个相互隔离的集群。这些都为开发过程提供了极大的便利。
#项目
如上所述,所有的工作都基于Sean C McCord的早期贡献,我们后来都在围绕他的工作做完善。现在如果你用ceph-docker,你可以将每个单一的Ceph daemon运行在Ubuntu或CentOS上。我们在Docker Hub里有很多的镜像,我们使用Ceph的命名空间,因此我们的镜像前缀都是ceph/。我们使用了自动构建,因此每次我们整合一个新的补丁就会触发新的构建,从而生成一个新的容器镜像。由于我们现在在从事代码重构,你会看到有很多的镜像版本。一直以来我们对每一个daemon构建一个单独的镜像(我们整合这些补丁的时候都会这样做)。所以监测、OSD、mds和radosgw各自都有独立的镜像。这个并不是最理想的方案,因此我们在尝试将所有组件都整合到一个叫做`daemon`的镜像中。这个镜像包含了所有的模块,你可以在运行`docker run`的时候通过命令行选择性地激活不同模块。如果你想试用我们的镜像,我们推荐使用`ceph/daemon`镜像。下面我就举例说明如何运行。
#容器化Ceph
##监测
由于监测模块不能在NAT过的网络中进行通信,我们必须使用 `--net=host`来将主机的网络层开放给容器:
$ sudo docker run -d --net=host \
-v /etc/ceph:/etc/ceph \
-v /var/lib/ceph/:/var/lib/ceph \
-e MON_IP=192.168.0.20 \
-e CEPH_PUBLIC_NETWORK=192.168.0.0/24 \
ceph/daemon mon

你可以配置如下选项:

  • `MON_IP`是运行Docker的主机IP
  • `MON_NAME`是你监测模块的名称(默认为$(hostname))
  • `CEPH_PUBLIC_NETWORK`是运行Docker的主机的CIDR。它和`MON_IP`必须是同一个网络。
  • `CEPH_CLUSTER_NETWORK`是运行Docker的主机的备用网口的CIDR,为OSD的备份流量使用。
##Object Storage Daemon我们现在能实现允许每一个OSD进程运行在一个独立的容器里。按照微服务的理念,一个容器里不应该运行超过一个服务。而在我们这里,在同一个容器里运行多个OSD进程,打破了这一理念,当然这也会给系统的配置和维护带来额外的复杂度。在这样的配置下,我们必须使用`--privileged=true`来使得容器中的进程可以访问`/dev`等其他内核功能。然后,我们在开放OSD的目录的基础上也支持其他配置,开放OSD的目录可以让operators来对设备做合适的准备工作。这样我们就可以简单地开放OSD目录,配置OSD(`ceph-osd mkfs`)的工作就会通过Entry Point来完成。我下面介绍的配置方法是最简单的,因为它只需要你指定一个block device,剩下的事情都会由Entry Point完成。如果不想用`--privileged=true`可以采用我的第二个例子。
$ sudo docker run -d --net=host \--privileged=true \-v /etc/ceph:/etc/ceph \-v /var/lib/ceph/:/var/lib/ceph \-v /dev/:/dev/ \-e OSD_DEVICE=/dev/vdd \ceph-daemon osd_ceph_disk
如果你不想使用`--privileged=true`,你也可以使用你喜欢的配置管理工具来手动配置OSD。下面这个例子我假定你已经实现分区并配置好文件系统。运行下面的命令来生成你的OSD:$ sudo docker exec ceph osd create.然后运行你的容器:
docker run -v /osds/1:/var/lib/ceph/osd/ceph-1 -v /osds/2:/var/lib/ceph/osd/ceph-2$ sudo docker run -d --net=host \-v /etc/ceph:/etc/ceph \-v /var/lib/ceph/:/var/lib/ceph \-v /osds/1:/var/lib/ceph/osd/ceph-1 \ceph-daemon osd_disk_directory
可配置的选项如下: - `OSD_DEVICE i`是OSD设备,例如:`/dev/sdb` - `OSD_JOURNAL`使用来储存OSD journal的设备,例如:`/dev/sdz` - `HOSTNAME`是运行OSD的主机(默认为$(hostname) - `OSD_FORCE_ZAP`会强制将制定的设备内容zapping(默认为 0,设为1去开启) - `OSD_JOURNAL_SIZE`是OSD journal的大小(默认为 100)##Metadata 服务器这个组件的设置较为直观。唯一需要注意的地方是在Docker中我们可以访问Ceph管理员密钥。这个密钥会用来生成CephFS pools和文件系统。如果你运行0.87以前的Ceph版本,你就不需要做此配置,然而我们最好运行最新的版本!
$ sudo docker run -d --net=host \-v /var/lib/ceph/:/var/lib/ceph \-v /etc/ceph:/etc/ceph \-e CEPHFS_CREATE=1 \ceph-daemon mds
可配置的选项如下:
  • `MDS_NAME`是Metadata服务器的名字(默认为mds-$(hostname))。
  • `CEPHFS_CREATE`会为Metadata服务器生成文件系统(默认为0,设为1 去开启)。
  • `CEPHFS_NAME`是Metadata文件系统的名字(默认为cephfs)。
  • `CEPHFS_DATA_POOL`是Metadata服务器data pool的名字(默认为cephfs_data)。
  • `CEPHFS_DATA_POOL_PG`是data pool的placement groups的数量 (默认为8)。
  • `CEPHFS_DATA_POOL`是Metadata服务器metadata pool的名字(默认为cephfs_metadata)。
  • `CEPHFS_METADATA_POOL_PG`是metadata pool的placement groups的数量(默认为 8)。
##RADOS gateway我们部署RADOS gateway时默认开启`civetweb`。当然,我们也可以通过指定地址和端口来使用不同的CGI前端:
$ sudo docker run -d --net=host \-v /var/lib/ceph/:/var/lib/ceph \-v /etc/ceph:/etc/ceph \ceph-daemon rgw
可配置的选项如下:
  • `RGW_REMOTE_CGI`指定是否使用嵌入的web服务器(默认为0,设为1去关闭)。
  • `RGW_REMOTE_CGI_HOST`指定运行CGI进程的远程主机。
  • `RGW_REMOTE_CGI_PORT`是运行CGI进行的远程主机端口。
  • `RGW_CIVETWEB_PORT`是civetweb的监听端口(默认为80)。
  • `RGW_NAME`是RADOS gateway实例的名字(默认为$(hostname))。

#后续工作
##后端配置存储
在默认配置下,`ceph.conf`和所有的Ceph密钥都会在监测模块启动阶段生成。这个过程假定了你必须在将集群扩展到多节点的时候去把这些配置传送到所有节点上。这个操作并不灵活,我们希望去改善它。我马上要提出的一个方案就是利用Ansible来生成这些配置文件和密码,并将他们安装到所有机器上。

另一种方法是将所有的配置信息存储到不同的后端服务器上,例如etcdconsul
##部署管理
最直观的方案是使用现成的ceph-ansible,虽然我还需要做一些变动,但主体工作已经完成。另一种方案是使用Kubernetes,他们的预览版本已经发布。
##支持Rocket等其他容器技术
也不需要做什么,因为你可以直接将你的Docker镜像运送到Rocket里,然后运行。

想要知道更多?可以看看视频

原文链接:Running Ceph inside Docker(翻译:Julia Han 审校:魏小红)

========================================
译者介绍:
Julia Han:School of Information Sciences, University of Pittsburgh, USA,硕士,Docker爱好者。

Docker Ceph系列之第二篇:使用灵雀云启动Docker Ceph对象存储(S3或Swift)

Georce 发表了文章 • 0 个评论 • 5060 次浏览 • 2015-06-22 01:45 • 来自相关话题

【编者的话】 我是吴健,来自上海[Hypers ](http://www.hypers.com )国内顶尖的大数据分析公司,参加过“云雀Docker巨好玩”并获得一等奖,年纪尚小请大家多多指教。因为有人提出了这个想法,我之前已经成功实践过这些实验, ...查看全部
【编者的话】 我是吴健,来自上海[Hypers
](http://www.hypers.com )国内顶尖的大数据分析公司,参加过“云雀Docker巨好玩”并获得一等奖,年纪尚小请大家多多指教。因为有人提出了这个想法,我之前已经成功实践过这些实验,自己也就把百度和Google不到的私房菜贡献出来,只有一个要求,希望大家互相帮助,不要自吹自擂就行,多多分享。

顺便向大家推荐下云雀平台 http://www.alauda.cn
还有Daocloud https://www.daocloud.io
希望大家互相扶持,互相帮助,与DockOne&OSchina还有所有的开源社区一起推动国内的Docker商用和技术能力。

用Docker搭建Ceph对象存储非常简单,只需要几条命令就可以搞定,甚至比Ceph出的ceph-deploy还方便,也无需翻墙获得软件包。

上一篇为 使用Docker搭建Ceph集群

我的部署环境是
灵雀云Docker平台
#注册并登陆灵雀云
浏览镜像—》搜索 ceph-demo
ala-1.jpg

#选择georce/ceph-demo
创建服务
ala-2.jpg

#配置必要的参数
ala-3.jpg

#等待运行成功
ala-4.jpg

#服务的URL则为对象存储的API地址
ala-5.jpg

#自带webshell功能
ala-6.jpg

#登陆方式如下
ala-7.jpg

#创建S3用户
root@426debfd7cb7:/opt# radosgw-admin user create --uid="testuser" --display-name="First User"
{
"user_id": "testuser",
"display_name": "First User",
"email": "",
"suspended": 0,
"max_buckets": 1000,
"auid": 0,
"subusers": [],
"keys": [
{
"user": "testuser",
"access_key": "MBFIV44FH7FIV96UM124",
"secret_key": "idSCzjsrHNDXPZdLK2cgOpE2UkM6Jx5lhdMM9DvY"
}
],
"swift_keys": [],
"caps": [],
"op_mask": "read, write, delete",
"default_placement": "",
"placement_tags": [],
"bucket_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
},
"user_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
},
"temp_url_keys": []
}

#创建对象存储桶
root@426debfd7cb7:/opt# sed -i s@archive.ubuntu.com@mirrors.aliyun.com@g /etc/apt/sources.list
root@426debfd7cb7:/opt# apt-get update
root@426debfd7cb7:/opt# apt-get install vim -y
root@426debfd7cb7:/opt# apt-get install python-pip -y
root@426debfd7cb7:/opt# pip install boto

root@426debfd7cb7:/opt# vim s3.py

import boto
import boto.s3.connection
access_key = 'MBFIV44FH7FIV96UM124'
secret_key = 'idSCzjsrHNDXPZdLK2cgOpE2UkM6Jx5lhdMM9DvY'
conn = boto.connect_s3(
aws_access_key_id = access_key,
aws_secret_access_key = secret_key,
host = 'ceph-smoak.myalauda.cn',
is_secure=False,
calling_format = boto.s3.connection.OrdinaryCallingFormat(),
)
bucket = conn.create_bucket('georce')
for bucket in conn.get_all_buckets():
print "{name}\t{created}".format(
name = bucket.name,
created = bucket.creation_date,
)

root@426debfd7cb7:/opt# chmod 755 s3.py

root@426debfd7cb7:/opt# python s3.py

georce 2015-06-21T16:56:07.000Z

#测试成功

Docker Ceph系列之第一篇:使用Docker搭建Ceph集群

Georce 发表了文章 • 13 个评论 • 9940 次浏览 • 2015-06-15 22:38 • 来自相关话题

【编者的话】 我是吴健来自上海[Hypers ](http://www.hypers.com )国内顶尖的大数据分析公司,参加过“云雀Docker巨好玩”并获得一等奖,年纪尚小请大家多多指教。因为有人提出了这个想法,我之前已经成功实践过这些实验,自 ...查看全部
【编者的话】 我是吴健来自上海[Hypers
](http://www.hypers.com )国内顶尖的大数据分析公司,参加过“云雀Docker巨好玩”并获得一等奖,年纪尚小请大家多多指教。因为有人提出了这个想法,我之前已经成功实践过这些实验,自己也就把百度和Google不到的私房菜贡献出来,只有一个要求,希望大家互相帮助,不要自吹自擂就行,多多分享。

顺便向大家推荐下云雀平台 http://www.alauda.cn
还有Daocloud https://www.daocloud.io
希望大家互相扶持,互相帮助,与DockOne&OSchina还有所有的开源社区一起推动国内的Docker商用和技术能力。

用Docker搭建Ceph非常简单,只需要几条命令就可以搞定,甚至比Ceph出的ceph-deploy还方便,也无需翻墙获得软件包。

我的部署环境是
Disk free > 30G
Ceph 0.94.1 hammer
OS Ubuntu 14.04.2
Kernel 4.0.5
overlayfs
eth0 IPADDR=192.168.1.100

#下载mon和osd
[root@ubuntu ~]# docker pull index.alauda.cn/georce/mon:hammer
[root@ubuntu ~]# docker pull index.alauda.cn/georce/osd:hammer

# 一条命令搭建mon
[root@ubuntu ~]# docker run -itd --name=mon --net=host -e MON_NAME=mymon -e MON_IP=192.168.1.100 -v /etc/ceph:/etc/ceph index.alauda.cn/georce/mon:hammer

#查看mon运行日志
[root@ubuntu ~]# docker logs -f mon

2015-06-15 13:48:38.414494 7fd43f5db700 1 mon.mymon@0(leader).osd e1 e1: 0 osds: 0 up, 0 in
2015-06-15 13:48:38.416236 7fd43f5db700 0 mon.mymon@0(leader).osd e1 crush map has features 1107558400, adjusting msgr requires
2015-06-15 13:48:38.416306 7fd43f5db700 0 mon.mymon@0(leader).osd e1 crush map has features 1107558400, adjusting msgr requires
2015-06-15 13:48:38.416391 7fd43f5db700 0 mon.mymon@0(leader).osd e1 crush map has features 1107558400, adjusting msgr requires
2015-06-15 13:48:38.416479 7fd43f5db700 0 mon.mymon@0(leader).osd e1 crush map has features 1107558400, adjusting msgr requires
2015-06-15 13:48:38.416712 7fd43f5db700 1 mon.mymon@0(leader).paxosservice(auth 1..1) refresh upgraded, format 0 -> 1
2015-06-15 13:48:38.418924 7fd43f5db700 0 log_channel(cluster) log [INF] : mdsmap e1: 0/0/0 up
2015-06-15 13:48:38.423753 7fd43f5db700 0 log_channel(cluster) log [INF] : osdmap e1: 0 osds: 0 up, 0 in
2015-06-15 13:48:38.428045 7fd43f5db700 0 log_channel(cluster) log [INF] : pgmap v2: 64 pgs: 64 creating; 0 bytes data, 0 kB used, 0 kB / 0 kB avail

#查看mon生成的集群配置文件
[root@ubuntu ~]# ls /etc/ceph

[root@ubuntu ~]# ceph.client.admin.keyring ceph.conf ceph.mon.keyring monmap

#更改集群配置文件
[root@ubuntu ~]# vi ceph.conf

[global]
fsid = 4efc5ee7-8982-4bf4-808b-15372862fb78 #这个要看你生成的 别抄我的
mon initial members = mymon
mon host = 192.168.1.100
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
osd crush chooseleaf type = 0
osd journal size = 100
osd pool default pg num = 8
osd pool default pgp num = 8
osd pool default size = 1
public network = 192.168.1.0/24
cluster network = 192.168.1.0/24

[root@ubuntu ~]# docker restart mon

#两条命令创建osd
[root@ubuntu ~]# docker exec mon ceph osd create
0

如果不知道上面的0是什么,我解释下 ceph osd 0 /var/lib/ceph/osd/ceph-0

# 创建osd0
[root@ubuntu ~]# docker run -itd --name=osd0 --net=host -e CLUSTER=ceph -e WEIGHT=1.0 -e MON_NAME=mymon -e MON_IP=192.168.1.100 -v /etc/ceph:/etc/ceph -v /opt/osd/0:/var/lib/ceph/osd/ceph-0 index.alauda.cn/georce/osd:hammer

#查看ceph群集状态
[root@ubuntu ~]# docker exec -it mon ceph -s

cluster 4efc5ee7-8982-4bf4-808b-15372862fb78
health HEALTH_OK
monmap e1: 1 mons at {mymon=192.168.1.100:6789/0}
election epoch 2, quorum 0 mymon
osdmap e5: 1 osds: 1 up, 1 in
pgmap v7: 64 pgs, 1 pools, 0 bytes data, 0 objects
3584 MB used, 42028 MB / 48077 MB avail
64 active+clean

雅虎Ceph的Exascale级存储

testA 发表了文章 • 0 个评论 • 2915 次浏览 • 2015-06-12 11:55 • 来自相关话题

【编者的话】像Yahoo、Facebook这样的企业都需要存储数亿级的用户图片,他们都在为实现这个目标而努力,Yahoo将非结构数据的MObStor对象存储系统转移到了Ceph上,并且正在部署最新的基于Ceph的系统—云对象存储,Yahoo在数百个PB级规模上 ...查看全部
【编者的话】像Yahoo、Facebook这样的企业都需要存储数亿级的用户图片,他们都在为实现这个目标而努力,Yahoo将非结构数据的MObStor对象存储系统转移到了Ceph上,并且正在部署最新的基于Ceph的系统—云对象存储,Yahoo在数百个PB级规模上操作,显然已经是业内老大。

任何超级巨头们都不会等待IT产业技术的自我更新,来满足自己应用的需求,但是当一个可替代的开源项目成长足够成熟,巨头们通常会从自己的软件到其他栈上做跨越式部署。从雅虎的门户网站上我们可以清晰的看到,Yahoo的重心从自己研发的对象存储转移到了即将成为exascale级别的系统,这个系统基于开源项目Ceph,一种Swiss army knife的存储。

这样的跨越并不常见,因为这些超级公司更倾向去超越技术规模的限制,不论是他们自己的技术还是开源项目,当然通常是开源项目。但这种情况确实存在。比如说这周早些时候谈到的平台,媒体巨头Netflix,它一直使用Cassandra NoSQL 数据库的一个自定义版本来作为控制流媒体服务和用户交互的后端,去年秋天,它将端口从DataStax转移到Cassandra的商业级别的 variant上。而Yahoo正在进行一次更大的跨越,他们将自己研发的用于非结构数据的MObStor对象存储系统转移到了Ceph上,Yahoo的架构副总监说,他们这次的变化是经过慎重考虑的。
#所有的信息技术都从cat图片开始
雅虎是对象存储领域规模上的创新者,就如同Facebook和他的Haystack系统,Amazon和他的S3系统,Mosso Cloud Files系统曾经是Rackspace Hosting的Swift对象存储的基础,而现在已成为OpenStack云控制器的一部分。Yahoo和Facebook都要存储数亿级别的用户图片,处理PB级别的容量,这就迫使他们开发自己的系统,实现更高效的图片存储功能,亚马逊和Rackspace假设,创建云应用的用户同样希望将丰富的媒体嵌入到图片上,所以他们想将对象存储变成他们公有云的一部分。

上面提到的所有对象存储系统,Haystack、 MObStor、 S3、Cloud Files/Swift, 他们被开发都是因为文件系统中常规存储阵列都存在非常大系统开销,这是因为用来跟踪对象的元数据存在于集群中。对象存储刚好忽略了文件系统,并将所有数据放在同一个bucket里,然后使用一个key,比如文件名或web的地址,在集群中找到该数据。这样可以使元数据的开销更小,因为没有文件系统与之抗衡。

十几年前,早期的雅虎图片服务器是由一个特殊的存储系统来处理非结构数据,其之后是一个由Yahoo开发,被称为MObStor的系统,它是一个用起来更加复杂、更具有普遍性的对象存储系统,Yahoo于2009年的夏天首次公开提及MObStor。2005年,雅虎的图片分享网站Flickr急需一种类似于对象存储的技术,然而当时MObStor被雅虎应用程序用来储存JavaScript和HTML代码以及富媒体,在2010年夏天,雅虎的工程师更新了MObStor,这在当时非常先进,这也是在六个月内系统的处理能力增长了4X(倍)的一个因素。当Yahoo揭露MObSto的时候,它仍在运作,而且运行在专用系统Direct Object Repository Architecture (DORA)上,DORA是针对MObStor的一个新后端,被称作是一个集群对象存储系统,它在很多方面与Ceph非常相似。MObStor是DORA后端系统的接口,Yahoo的程序员写这个系统是因为他们需要存储非结构性内容,比如照片、视频和其他类似的数据。DORA是运行在普通硬件和存储应用上的,雅虎当时还不太明确这些意味着什么,但是DORA后端特点允许Yahoo在更廉价的系统上做对象存储,这也就说明了一切。

我们将在数百个PB级规模上操作,我不知道其他Ceph社区是否还会这样做。如果我们不是最大的,那么我们就会成为最大的产品用户,而且我们很可能会去寻找适合我们规模的版本。你只需要看雅虎这个规模的数据,不用看传统的那些。

经过一些改进,McMillen说贯穿Yahoo所有的服务和中心数据,如果将对象、块和文件存储叠加在一起,这将是一个exabyte级别的存储。在发布过的一篇微博中说到,Yahoo从MObStor迁移到Ceph上是因为Flickr上的照片分享服务,公司说那有250亿个对象,将近500PB的照片、视频、邮件和博客帖子。这些都是为用户存储的,并且存储量仍以每年百分之20-25速度增长。



根据McMillen所述,MObStor具有“完整特性”,它广泛部署于雅虎。那么如果MObStor真的被广泛应用和被看好,为什么Yahoo却热衷于一个新的技术了?不管怎样这些都涉及到了钱。

首先,MObStor是一个闭源项目,这意味着雅虎不得不独立完成创建、扩展和所有支撑工具。与之对应的是Yahoo所创的Hadoop数据分析平台,这是一个开源项目,在这个平台有一群资深的工程师,他们在不断改进平台上的所有的layer,这体现出了社区的价值。

"我想说,转向Ceph的最主要是因为我们仅仅想降低存储费用",McMillen解释,"我们的存储已经增长了许多,我们在尽可能得缩减成本,尽可能得拥有更多的选择,而不是坚守着一个系统,一种技术或一种硬件架构。

原始的MObStor对象存储是运行在存储阵列上,存储阵列上有动态保护RAID数据,保证了文件安全。随着DORA的使用,雅虎增加了选项,用来复制存储集群中阵列之间的数据。RAID和复制带来了一个很大的开销,而 McMillen却不愿意透漏出任何有关MObStor与Ceph在这个方面对比的详细信息。但他却说过,对传统对象存储系统的检查发现,这个开销对三路复制来说为200%,伴随着纠删码技术运用到Ceph及其他的对象存储,能将开销降低到40-60%,这些能在雅虎安装调试Ceph中看到,McMillen说最接近的40%的开销在纠删码保护校验来确定数据的原始性。这个意味着雅虎在Ceph上存储容量的开销是用传统对象存储的一半,而且还是三副本。

MObStor/DORA不支持纠删码,雅虎不得不将这个移植到该系统上,这可意味着大量的开发和测试的工作量的产生。另一方面Ceph是一个exascale级部署设计,它有纠删码技术以确保数据的内建。(有了纠删码,少量无结构数据碎片和分散存储,或者如果一部分丢失,纠删码算法可以重建丢失数据)
#云对象存储
雅虎正在部署最新的基于Ceph的系统,它被称为云对象存储,从去年秋天开始,它已经被雅虎stack的Flickr部门试验。Flickr在管理上有“多PB级别”的Ceph容量,在本年度雅虎计划增加10个基数来达到“轻量过百PB级别”,据McMillen所说,当推出基于Ceph的云对象存储,将其隶属于Flickr、雅虎邮箱、Tumblr(轻量博客)。(McMillen说Flickr会有更多的存储量,其中的一分部还会在MObstor中保留一段时间)

雅虎也曾经关注过swift和Gluster文件系统,还有那些为寻找新的对象存储系统的特有选择,最终他们将注意力放在了Ceph上。首先,McMillen说Ceph有吸引力的地方是将支持对象和块存储两者于一身,如果Ceph社区永远如此高效处理问题,在未来某一天(很有希望)Ceph同样支持文件系统存储。

“并不是所有雅虎的存储都适合对象存储,但是很多却适合”,McMillen说到,“我们正在使用块存储,但是他们却没有对象存储走的远。我们非常喜欢Ceph,除了它因纠删码而产生的低成本和它是一个开源项目,在开发者的社区发展非常迅速外,还因为它是一个同时具有块存储和对象存储能力的单一存储系统。所以代替块、对象分开的存储系统,我们可以灵活掌握一种技术栈而获得两种使用方法。而且如果Ceph有一个稳定的文件系统,我们今天绝对会使用它。”

Ceph社区(后台是Red Hat,其已经在一年前以175 百万获得Ceph管理Inktank)仍在专注它 。

McMillen说,当Ceph可以从单个集群扩展到exabyte级存储系统,雅虎将Ceph应用于pod架构,这会比一个单一集群具有更好的性能预测性和错误隔离性,效果如下:
11.jpg

在雅虎云对象存储上,每一个节点(被称作一个对象存储设备),有60TB的存储,这都是基于X86的服务器。雅虎已经尝试过每个节点配置12-72个设备,对于COS服务,Yahoo没有透露其硬件配置。每个集群有54个这样的节点,总容量可达3.2 pb。为了向外扩展这些服务,雅虎复制pods并使用哈希算法来打破利用纠删码横跨pods和节点的无结构数据。

依赖这些应用,雅虎正在使用常规的硬件驱动和磁盘,他们使用的是shingled magnetic recording (SMR)技术,在容量和花费上都不同;SSDs也被部署到了COS服务来提供更高的I/O率。

雅虎正在Ceph的variant上使用8/3纠删码,这说明8份中的3份共享对象的服务或者驱动可以失败却仍然可以访问的到。这是常规级别的纠删码在Ceph上应用的。但是雅虎已经计划了一个针对Ceph的11/3纠删码variant,这意味着11个中的3个驱动或者服务可以失败,更重要的是这个可以减少40%的读写延迟。(根据McMillen的说法,雅虎计划把这项改进回馈给Ceph社区,通过这个方法,它能让自己参与到“Hummer”代码稀释中)公司已经做出了一系列调整来使Ceph表现出更好的性能,如下图:
222.jpg

加入了纠删码的更改,雅虎已经想出一个共享bucket索引的方法,那就是一个索引保持跟踪对象存储到一个bucket(这是针对对象存储容量单位的亚马逊术语)正常Ceph是在一个单一的服务器节点上实现bucket索引,但是雅虎的工程师为了高可用性和性能方面的改进,已经解决了如何切分和跨节点传播。当有磁盘或服务器失效,数据恢复完成,雅虎想出一个在恢复数据时将延迟的速率限制到60%的方法。

与此同时,雅虎自支持Ceph的实现,但是McMillen说公司与RehHat关系非常好,而且也不反对使用RedHat做一些技术支持。但是雅虎正处于一个大量消耗的时期,而这与超大规模Ceph有关,也许自支持是他们现在唯一的选择。

“我们将在数百个PB级规模上操作,我不知道其他Ceph社区是否还会这样做”,McMillen说。“如果我们不是最大的,那么我们就会成为最大的产品用户,而且我们很可能会去寻找适合我们规模的版本。你只需要看雅虎这个规模的数据,不用看传统级别。我们正致力于解决所有这些问题,我相信社区会从中受益。

原文链接: Inside The Ceph Exascale Storage At Yahoo

Ceph 成立委员会了,不再是 Red Hat 一家主导

kurtzhong 发表了文章 • 0 个评论 • 3718 次浏览 • 2015-10-30 00:17 • 来自相关话题

Red Hat的Ceph是一个广受欢迎的可以支持软件定义对象和文件云存储套件。尽管Ceph的代码是开源的,但其战略方向在过去由Red Hat掌控。然而这即将成为历史。在东京OpenStack峰会(Toyko OpenStack Summit)上,Red Hat ...查看全部
Red HatCeph是一个广受欢迎的可以支持软件定义对象和文件云存储套件。尽管Ceph的代码是开源的,但其战略方向在过去由Red Hat掌控。然而这即将成为历史。在东京OpenStack峰会(Toyko OpenStack Summit)上,Red Hat宣布它的以Ceph为基础,软件定义存储技术的整体技术走向将会转由刚刚成立的Ceph咨询委员会Ceph Advisory Board)来决定。

具体地,“咨询委员会成立的时候,树立的目标即是:与社区广大的技术以及用户委员会携手,扩大并增强社区在Ceph项目中的参与范围和合作”。

除了Red Hat,Ceph咨询委员会的成员还来自Canonical、CERN、Cisco、Fujitsu、Intel、SanDisk和SUSE等公司。可以简单地讲,Ceph以后不再只是Red Hat一家玩了。

然而,这并不令人意外。开源的Ceph已经被证明了能够在单一而统一的存储集群(single, unified storage cluster)里提供对象、块和文件系统的存储。这使得它非常契合云储存基础设施。根据OpenStack Foundation最新的用户调查报告,Ceph是Openstack中用到最多的的块存储解决方案

在一份声明中,Red Hat基础设施工程开发(Infrastructure Engineering Development)的VP Tim Burke说道:

“Red Hat的关键点一直在于在社区之间开展协作,从而取得任何单个公司都不能独立完成的巨大成果。... 尽管这种与社区和合作伙伴的合作,在过去即使是通过非正式的方式进行,也出人意料的强而有力,但是成立Ceph咨询委员会将这种开放的工作关系正式化了。我们期待与Ceph的社区和伙伴成员一起,不仅能为Ceph带来新的功能,还能提升Ceph在新的不同workload下的集成程度和使用简易度。”



Canonocal,Ubuntu Linux的母公司,Red Hat的对手,也对此表示支持。Christian Reis,Canonocal的Storage&Hyperscale的副总,将Ceph的很大一部分功劳归功于Canonocal:

“Canonical从一开始就驱动着Ceph的进步。在Ubuntu Stack和scale-out部署中,我们把Ceph作为一个关键技术。我们很兴奋能成为Ceph顾问委员会的成员,来帮助Ceph扩大决策的来源,推广使用范围和提高成熟度,帮助Ceph成为企业级存储平台。”



Lars Marowsky-Brée,SUSE杰出工程师,又一个Red Hat的对手,补充说:“Ceph咨询委员会是Ceph从一个开源项目走向一个开放的标准并获得行业内协作与采用的关键一步。SUSE很高兴能参与进来,为帮助开源软件定义存储(software-defined storage)革命的实现做贡献。

在此次的进展之前,Ceph代码仓库被攻击。Red Hat的消息人士说,委员会的创建与网站攻击事件没有关联。

欢迎来到Linux和开源的世界,在这里商业对手可以为了代码而手牵手协作。

Ceph社区咨询委员会将会处理Ceph软件定义存储项目的广大问题。而目标是打造Ceph - 人们口中的云存储系统(the cloud storage system.)。

原文:Red Hat opens up Ceph storage to other cloud leaders(翻译:钟最龙 校对:李颖杰)

Docker Ceph系列之第二篇:使用灵雀云启动Docker Ceph对象存储(S3或Swift)

Georce 发表了文章 • 0 个评论 • 5060 次浏览 • 2015-06-22 01:45 • 来自相关话题

【编者的话】 我是吴健,来自上海[Hypers ](http://www.hypers.com )国内顶尖的大数据分析公司,参加过“云雀Docker巨好玩”并获得一等奖,年纪尚小请大家多多指教。因为有人提出了这个想法,我之前已经成功实践过这些实验, ...查看全部
【编者的话】 我是吴健,来自上海[Hypers
](http://www.hypers.com )国内顶尖的大数据分析公司,参加过“云雀Docker巨好玩”并获得一等奖,年纪尚小请大家多多指教。因为有人提出了这个想法,我之前已经成功实践过这些实验,自己也就把百度和Google不到的私房菜贡献出来,只有一个要求,希望大家互相帮助,不要自吹自擂就行,多多分享。

顺便向大家推荐下云雀平台 http://www.alauda.cn
还有Daocloud https://www.daocloud.io
希望大家互相扶持,互相帮助,与DockOne&OSchina还有所有的开源社区一起推动国内的Docker商用和技术能力。

用Docker搭建Ceph对象存储非常简单,只需要几条命令就可以搞定,甚至比Ceph出的ceph-deploy还方便,也无需翻墙获得软件包。

上一篇为 使用Docker搭建Ceph集群

我的部署环境是
灵雀云Docker平台
#注册并登陆灵雀云
浏览镜像—》搜索 ceph-demo
ala-1.jpg

#选择georce/ceph-demo
创建服务
ala-2.jpg

#配置必要的参数
ala-3.jpg

#等待运行成功
ala-4.jpg

#服务的URL则为对象存储的API地址
ala-5.jpg

#自带webshell功能
ala-6.jpg

#登陆方式如下
ala-7.jpg

#创建S3用户
root@426debfd7cb7:/opt# radosgw-admin user create --uid="testuser" --display-name="First User"
{
"user_id": "testuser",
"display_name": "First User",
"email": "",
"suspended": 0,
"max_buckets": 1000,
"auid": 0,
"subusers": [],
"keys": [
{
"user": "testuser",
"access_key": "MBFIV44FH7FIV96UM124",
"secret_key": "idSCzjsrHNDXPZdLK2cgOpE2UkM6Jx5lhdMM9DvY"
}
],
"swift_keys": [],
"caps": [],
"op_mask": "read, write, delete",
"default_placement": "",
"placement_tags": [],
"bucket_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
},
"user_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
},
"temp_url_keys": []
}

#创建对象存储桶
root@426debfd7cb7:/opt# sed -i s@archive.ubuntu.com@mirrors.aliyun.com@g /etc/apt/sources.list
root@426debfd7cb7:/opt# apt-get update
root@426debfd7cb7:/opt# apt-get install vim -y
root@426debfd7cb7:/opt# apt-get install python-pip -y
root@426debfd7cb7:/opt# pip install boto

root@426debfd7cb7:/opt# vim s3.py

import boto
import boto.s3.connection
access_key = 'MBFIV44FH7FIV96UM124'
secret_key = 'idSCzjsrHNDXPZdLK2cgOpE2UkM6Jx5lhdMM9DvY'
conn = boto.connect_s3(
aws_access_key_id = access_key,
aws_secret_access_key = secret_key,
host = 'ceph-smoak.myalauda.cn',
is_secure=False,
calling_format = boto.s3.connection.OrdinaryCallingFormat(),
)
bucket = conn.create_bucket('georce')
for bucket in conn.get_all_buckets():
print "{name}\t{created}".format(
name = bucket.name,
created = bucket.creation_date,
)

root@426debfd7cb7:/opt# chmod 755 s3.py

root@426debfd7cb7:/opt# python s3.py

georce 2015-06-21T16:56:07.000Z

#测试成功

Ceph vs Swift - 架构剖析

崔婧雯 发表了文章 • 0 个评论 • 9602 次浏览 • 2015-05-29 22:57 • 来自相关话题

【编者的话】Ceph和Swift,哪种更好?这个问题上大家争论不休,本文从两者的架构角度分析两种方式各自的优缺点,并且给出如何选择的建议。 当工程师们讨论存储,谈到Ceph和Swift时,他们通常都一致认为其中一个非常棒,另外一个却很 ...查看全部
【编者的话】Ceph和Swift,哪种更好?这个问题上大家争论不休,本文从两者的架构角度分析两种方式各自的优缺点,并且给出如何选择的建议。

当工程师们讨论存储,谈到Ceph和Swift时,他们通常都一致认为其中一个非常棒,另外一个却很糟糕。但问题时,他们在哪个好哪个不好上却意见不一。

经常会有客户问我相同的问题,“我们听说Ceph可以代替其他所有类型的存储。为什么不能用它做所有事情呢?”

我会在Vancouver的OpenStack Summit大会上从架构角度探讨Ceph和Swift,分享在这两者之间到底该如何抉择,也会为两种平台的解决方案都给出建议。本文,我们一起看看他们的架构细节和不同之处。
#深入浅出
Swift在OpenStack开始发展之初就出现了,大概在五年之前。它是OpenStack的核心项目,并且被无数次证明强大且稳定。

问题是,Swift的设计导致在传输速度和延迟时间上都不强。造成这个问题的主要原因是Swift集群进出的流量都要通过代理服务器。

另一个原因,也是很多人认为Ceph更好的原因,是Swift不支持块存储和文件存储。

最后,当对象副本不一定同时更新时延迟的问题便会浮现,这会导致请求者在第一次更新某个对象到新版本之后,读取到的却仍然是旧版本。这种行为被称为最终一致性。

另一方面,Ceph也有自己的问题,特别是在云环境上。它的多地域支持,虽然经常被当做优势来宣传,但实际上还是master-slave模型。因为只能从master到slave进行复制,所以在多于两个地域时,基础架构上的负载分布会很不均衡。

Ceph的两地域设计也不太实际,因为只支持master上的写入,而不阻隔slave上的写入。这样的配置最严重时可能导致整个集群的崩溃。

Ceph的另一个短板是安全性。云计算节点上的RADOS客户端直接与RADOS服务器交互所使用的网络与Ceph用于未加密复制流量的网络相同。如果某个Ceph客户端节点被入侵,攻击者便能得到存储网络的所有流量。

针对Ceph的弱点,你可能会问,为什么不直接构建一个Ceph集群,扩展到两个地域呢?一个原因是Ceph只能同步写入,并且要求写入节点达到quorum数才能成功返回。

了解这些问题之后,我们来假定有一个集群跨越两个地域,相隔数千英里,100ms延时,非常慢的网络连接。假定将两个副本写入到本地地域,另外两个写入到远程地域。这时四次副本的quorum数是三次,这就意味着这次写请求在至少完成一次远程拷贝前都不会返回。也就意味着即使是很小量的一次写入也会延迟0.2秒,而大批量写入则会因为吞吐量限制严重受阻。

另一方面,Swift,在与之相同的两地域架构中,会先在本地写入,然后基于一致性设计在一段时间里复制到远程地域。Swift也要求写入quorum,但是可以在集群上配置write_affinity设置强制限定写入quorum在本地地域,因此本地写入完成后就会成功返回。

那么我们在Ceph和Swift之间如何抉择呢?

#如何选择?
如果部署只在单一地域,没有计划扩展到多个地域的话,Ceph会是很好的选择。Mirantis OpenStack底层可以选择Glance或者Cinder。但是,如果要考虑大规模部署的话,Swift比Glance更适合。它的多地域能力会胜过Ceph的速度和强大的一致性模型。

很多情况下,速度并不是决定因素,安全性则是更大的问题,这时,Swift更适合,它封闭的复制网络更为安全。另一方面,如果云基础架构本身已经很安全,存储安全性优先级便会降低,这时可能Ceph更适合。

与其比来比去,不如在同一个云基础架构里同时拥有这两种选择。比如,可以使用Ceph作为本地高性能存储,而Swift则作为多地域Glance后台,这时复制很重要而速度并不关键。但是,拥有这两种选择的解决方案花费必然更多,因此可能还是需要二选一。

对于很多客户,我的个人建议是,Mirantis提供了架构设计评估来帮助收集所有需求和参数,提供适合特定使用场景和业务驱动的解决方案,会帮助全面评估所有业务,技术和运营因素。然后你可以权衡这些因素,以及这两种选择的优缺点。谁知道呢?你的收获很可能超过预期。

原文链接:Ceph vs Swift – An Architect’s Perspective(翻译:崔婧雯 校对:魏小红)
===========================
译者介绍
崔婧雯,现就职于IBM,高级软件工程师,负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化,中间件技术,业务流程管理有浓厚的兴趣。

理解Ceph:一个开源的分布式存储平台

Doit05 发表了文章 • 5 个评论 • 17513 次浏览 • 2015-04-14 17:41 • 来自相关话题

【编者的话】Ceph是一个符合POSIX、开源的分布式存储系统。最初由Sage Weill于2007年开发,Ceph的主要目标是设计成基于POSIX的没有单点故障的分布式文件系统,使数据能容错和无缝的复制。本文详细介绍了Ceph的历史和架构。 ...查看全部
【编者的话】Ceph是一个符合POSIX、开源的分布式存储系统。最初由Sage Weill于2007年开发,Ceph的主要目标是设计成基于POSIX的没有单点故障的分布式文件系统,使数据能容错和无缝的复制。本文详细介绍了Ceph的历史和架构。

Ceph是一个软件分布式存储平台,可运行在商用硬件上。为了了解Ceph的运行效率,我们首先要弄清什么是商用硬件。商用电脑是由多个硬件供应商提供的硬件组装而成的,供应商们开发这些硬件是基于同一个开放标准的。与超级微型计算机相比,商品电脑的成本更低,并且它的开放标准能减少众多硬件提供商提供的硬件差异性。Ceph存储集群运行在商用机上,为了确保集群中数据的分布式存储和良好的可扩展性,Ceph运用了著名的CRUSH(Controllled Replication Under Scalable Hashing)算法。Ceph开发的主要目标是提供高可扩展性和提供对象存储、块存储和文件系统的存储机制。Ceph提供一个单一的存储平台,可以处理所有类型的数据存储(包括对象、块和文件)。它的高扩展性可以达到PB级,它还拥有高容错性和高一致性数据冗余机制。
## Ceph的历史
在2004年,Sage Weil开发了一个名叫Ceph的开源项目,并于2006年,基于开源协议开源了Ceph。Weil 曾经是“Inktank Storage”公司的创始人。Inktank Storage一直专注于Ceph的研发,直到它被红帽收购。2012年,Ceph的第一个稳定版本发布了。2014年10月,Ceph的开发团队发布了Ceph的第七个稳定版本Giant。为了让Ceph更加成熟与完美,这个项目还在继续开发中。

一个Ceph集群由两种类型的后台进程(Daemon)组成:

* OSD Daemon
* Ceph Monitor

## Ceph OSD Daemon
Object Storage Device(OSD)是Ceph集群中的重要组成部分。OSD可以存储文件或数据的内容,它使用文件系统来存储数据。OSD Daemon主要负责管理集群中的所有磁盘。OSD Daemon还负责在本地文件系统存储数据,并为不同的客户软件或存取媒介通过网络提供数据访问。而且,OSD Daemon还负责添加和删除磁盘,磁盘分区,管理OSD、低层空间管理,提供安全措施和磁盘数据的可复制性。
## Ceph Monitor
Ceph Monitor也是一种Ceph OSD Daemon,它主要负责管理全部集群。当你运行一个Ceph集群时,你就会需要Ceph Monitor每天帮你检查集群的健康情况和状态。管理一个集群需要每天做很多工作比如检测所有OSD的状态和文件系统或块数据的状态。你可以通过Ceph Monitor来管理负载均衡和数据响应的详细信息。为了更好的了解Ceph集群的工作原理,我们来看看它是如何处理三种类型数据存储的机制。

Ceph Object storage

当向Ceph写入数据时,Ceph通过内部机制自动跨集群标记和复制数据。Ceph存储对象数据时,不仅可以通过调用Ceph内部的API来实现,还可以通过亚马逊的S3服务或AWS REST提供的API来实现。Ceph块存储机制提供了RADOS(Reliable Autonomic Distributed Object Store)服务。RADOS服务存储机制中不可或缺的;RADOS服务通过使用节点中安装的软件管理工具能够扩展千级的硬件设备(通常被应用为“Nodes“)。

Ceph Block Storage

Ceph的块存储模式使用户可以像挂载一个小型块设备一样挂载Ceph。在块数据存储级别上,RADOS服务也保证块数据的可扩展性。Librados就是包含在这一级别上的一个python类库,你可以使用librados类库和存储服务器或节点进行通信。Librados是一个开源的应用,你可以调整和增强它。Librados通过“RADOS Block Device“即RBD与后台进行交互。RBD不仅继承了Librados的功能,还能够为集群建立快照和恢复数据。

Ceph File Storage

CephFS 是一个为Ceph集群设计的,且遵循POSIX标准的分布式文件系统。CephFS提供把数据目录和文件映射到存储在RADOS中对象的存储的服务。通过这种方式,CephFS和RADOS可以相互协作。在这里,RADOS动态均等地把数据分布到不同的节点上。这种文件系统支持无限的数据存储和更强的数据安全性。在文件存储集群系统中,Ceph因提供容量大和高可扩展性而闻名。请注意你可以同时把Ceph与btrfs或EXT4一起使用,但Red Hat推荐使用最新Linux内核(3.14版本或者更新版本)。
## 结论
Red Hat下的Ceph文件系统拥有性价比高、操作简单、集群数据高可靠性的特点。RedHat也一直为Ceph投入了很多人力,这也确保了Bug可的跟进速度,以及新特性的引入。由于Ceph是开源的,所以你可以按照你的需求随意修改它。

原文链接:Understanding Ceph - An Open Source Distributed Storage Platform(翻译:占帅兵 校对:李颖杰)

===========================

译者介绍

占帅兵,研究生在读(华南师范大学),主要研究方向云计算与大数据处理。曾在公司做过微信公众平台的开发和参与过开发智能综合公交枢纽科研项目。现对PaaS中Docker技术有浓厚的兴趣。

有人使用过rancher 1.6.11部署的k8s,连接ceph吗?

回复

overlord 发起了问题 • 1 人关注 • 0 个回复 • 3210 次浏览 • 2017-11-29 10:05 • 来自相关话题

Kubernetes创建基于Ceph rbd的持久存储问题

回复

一页空纸 发起了问题 • 5 人关注 • 0 个回复 • 5461 次浏览 • 2015-12-21 13:50 • 来自相关话题

Kubernetes 使用RBD作为后端存储,无法访问设备。

回复

郑伟-风刃 回复了问题 • 6 人关注 • 2 个回复 • 5380 次浏览 • 2015-08-19 11:59 • 来自相关话题

网易视频云:ceph恢复优化

shipinyun2016 发表了文章 • 0 个评论 • 1797 次浏览 • 2016-08-02 09:54 • 来自相关话题

网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术,为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PaaS服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在在线 ...查看全部
网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术,为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PaaS服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在在线音视频平台。

  1.背景

  在对ceph块存储进行性能测试时发现,当有osd重启或者存储机重启时,I/O性能会急剧下降,尤其在随机写的负载下,下降幅度达到90%,并且会持续一段时候才慢慢恢复到正常水平。一开始我们也尝试将恢复相关的参数调低(osd_recovery_max_active=1、osd_recovery_max_chunk=131072、osd_max_backfills=1),以及调整正常I/O和恢复I/O的优先级(osd_recovery_op_priority=10、osd_client_op_priority=63),但是测试结果来看,这些参数的调整没有多大的效果,随机写负载下性能下降仍然很大。

  2.原因分析

  在《ceph基于pglog的一致性协议》一文中分析了ceph的一致性协议,从中我们得知在osd重启、存储机重启等场景下基于pglog的恢复的时候,在peering的时候会根据pglog来构建出missing列表,然后在恢复时根据missing列表逐个进行恢复,恢复的粒度是整个对象大小(默认4MB,有可能有的对象不足4MB,就按对象大小),即使只修改了一个4KB,也需要将4MB的对象拷贝过来,这样100个io就会达到400MB的带宽,对网络及磁盘产生较大的影响。当写io命中正在修复的对象时,也是先修复原来4MB的对象,即需要将4MB的数据通过网络拷贝过来,延迟就会增加很多,然后再写入数据,对于随机写的场景尤其严重,基本都是命中的情况,带来相当大的延迟,从而iops下降(下降幅度80%~90%)。这个影响时间取决于上层的业务量和osd停服的时间。

  

  3.恢复优化

  因为pglog里每条记录里只是记了操作及版本等信息,并没有记录这次操作是修改哪部分数据,所以优化的办法就是在pglog里记录每次操作修改的区间,记为[offset,len](实现时pglog结构里引入dirty_extents来表示),正常写I/O处理时,会写pglog,对应的是一个MODIFY操作,在这条记录里记上修改的区间。

  当一个osd故障重启后,进行peering的时候,合并pglog来构建missing列表时就可以将同一个对象的多次修改的[offset,len]求一个并集,得出故障期间总的修改区间,然后在恢复的时候就能够根据这个范围来恢复这部分增量数据,从而大幅度减少了恢复时的网络和磁盘带宽,以及正常I/O命中恢复对象的等待时间,从而大幅降低对正常I/O的性能影响(尤其是对于随机写I/O的场景)。

  

  针对我们使用的块存储的应用场景,为了减小实现的复杂度,引入一个标记can_recover_partial来表示是否可以进行部分恢复,默认是false,当进行写I/O的处理时记录pglog里的[offset,len],并且标记can_recover_partial为true,然后恢复时就可以根据这个标记只恢复对象内的增量数据。对于无法判断是否可以进行部分优化时,就回退到原有的恢复逻辑去恢复整个对象,需要考虑几种情况,包括:truncate、omap、clone、EC等。

  truncate

  truncate的操作对应的就是截断对象,可以类比于文件系统里的ftruncate的操作(可以将文件截断,或者将文件扩大)。原生ceph的pglog没有TRUNCATE的操作码,它里面的truncate操作都是MODIFY操作,如果一个对象先被修改了,然后又被truncate了,那么在恢复这个对象的时候仍然是按照这整个对象来恢复,有可能因为truncate这个对象变小了(小于4MB),这个不用管, 直接将这个对象读出来拷贝过去就行了。

  但是我们要在pglog里加入[offset, len]来表示修改范围,那么和truncate混在一起后,就需要做区分,为了简单起见,当碰到truncate操作时,将can_recover_partial设置成false,这样truncate的处理就跟原来一样,在我们的使用场景下,trucate操作不常见。

  omap

  omap即objectmap,用来记录对象的扩展属性,因为文件系统的xatrr属性数量及长度都有限制,超过了就需要放到omap中。设置omap属性时,对应到pglog里也是一个MODIFY操作,也就是说omap在多副本间的一 致性也是由pglog来保证的。在恢复的时候合并pglog来构建missing对象时,是不区分属性还是数据,都认为是对这个对象的修改,在恢复的时候都是先恢复恢复属性(xatrr和omap),然后再恢复数据。这样的话,即使一个对象在pglog里只设置了属性,在恢复的时候会连数据一起恢复过来,也即是多了一次数据的拷贝。在块存储的场景下,这个代价是可以接受的,因此不必针对omap做特殊处理。

  clone

  这里的clone指的clone对象操作,就是做了快照之后对原卷进行写入时触发的cow操作。每次clone操作会在pglog里记录一条CLONE的记录,然后在filestore里会根据这个CLONE操作进行clone_range的处理,也就是从原来的head对象(表示卷的数据对象),拷贝数据到新生成的snap对象(即快照的对象)。在peering的时候合并pglog时,没有区分MODIFY和CLONE的,都会构建丢失对象放到missing列表里,也就是说这个missing列表里有可能既包含head对象,也包含snap对象。

  在《ceph rbd快照原理解析》里详细介绍了快照的实现及故障恢复的处理,引入恢复优化后,对于snap对象还是按照原来的逻辑处理,而对于head对象就要做不同处理,按照对象的修改区间来进行恢复。

  EC

  块存储下都是采用多副本的策略,而不会用到纠删码(EC),一般是ceph对象存储里才用到纠删码,因此我们不考虑这种情况,遇到纠删码相关的就就按照原有的逻辑进行恢复。

  4.优化效果

  下面的测试结果对比了优化前和优化后的性能(主要针对随机读写的场景),从结果上来看,效果显著:

  1)减少了重启osd过程中对集群正常存储I/O性能影响,从优化前的I/O性能下降90%到优化后I/O性能只下降10%;

  2)缩短重启恢复所需要的时间,重启单个osd的恢复时间从10分钟减少到40秒左右;

  

  

  更多技术分享,请关注网易视频云官方网站或者网易视频云官方微信(vcloud163)进行交流与咨询

DockOne微信分享(五十一):基于Docker、Mesos、Ceph全新技术栈的三地三中心容灾体系

赵英俊 发表了文章 • 0 个评论 • 9555 次浏览 • 2016-03-30 14:57 • 来自相关话题

【编者的话】以传统的两地三中心容灾体系为基础,将Docker(应用引擎)、Ceph(统一存储)、Mesos(分布式资源调度)这三大主流技术栈,与大二层网络,光纤传输技术结合在一起,实现新一代的三地三中心容灾体系。 @Container ...查看全部
【编者的话】以传统的两地三中心容灾体系为基础,将Docker(应用引擎)、Ceph(统一存储)、Mesos(分布式资源调度)这三大主流技术栈,与大二层网络,光纤传输技术结合在一起,实现新一代的三地三中心容灾体系。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、点融网等公司的技术负责人将带来实践经验分享,4月7日之前购票只需338元,欢迎感兴趣的同学抢购。
#容灾体系架构构想
无标题.png

在设计这个容灾体系架构的时候,我将传统的两地三中心的概念进行了升级,从上图中大家可以看出,其实是一个三地三中心三活的架构。如果不从经济角度考虑,需要在三地之间架设或者租用运营商的裸光纤。在超过3KM以外的距离多模光纤已经存在比较大的损耗,因此可以采用单模裸光纤,将光束以极小的角度打入光纤中,进行长距离高质量的传输。

在分布式资源调度层,Mesos只是作为分布式资源调度,应用的调度交给各种执行框架去做,包括对于如何做到应用的多活高可用,我觉得在这个架构中,只是提供了应用多活的链路、存储、资源调度多活,对于各种应用多活架构都是开放的,都可以在Schedule兼容的情况下进行部署。

最后在应用负载这一块,我选择了负载轮询的方式。其实说实话在这个层面我没有想的特别明白,我所讲的负载轮询是事务处理的负载轮询,就是访问接入是在数据中心A1 A2 A3的,当进行事务操作的时候以一组长连接为颗粒度进行负载轮询。这样设计的目的,是最大程度的避免事务的冲突和数据的瞬时海量并发,当然对于数据并发其实可以使用队列数据库来解决,但是我觉得从底层的机制上需要这种负载轮询的机制来解决。
#容灾体系技术框架
无标题1.png

如之前所说,在设计这个容灾体系的时候,我将两地三中心的概念进行了提升,变成了三地三中心。这样做的原因是当前的光纤传输技术的提升,目前在240KM内是单模裸光纤可以达到10Gb/s的带宽,这已经达到了正常数据中心在汇聚层甚至是核心层设计的带宽。因此,通过DMDW收发设备的转换,可以完全实现在物理层的传输速度上跨地域进行数据的无差别传输。

在统一存储层面,在三个数据中心中分别设立了OSD群和monitor群,在现有体系构想下每个数据中的OSD群包含n个OSD节点,3个monitor节点,这样从三个中心的角度来看,就存在三个OSD群域和9个基于PAXOS服务选举的monitor服务集群.考虑到三中心的的OSD数量规模以及在进行CRUSH算法的数据分布式中的效率,建议设置6副本的模式,即在每个数据中心都存在2个同一个数据的副本。为了保证写操作的效率,可以将最小副本数设置2,这样只要完成2副本的写操作就会返回写成功。这样通过CRUS算法规则的设置,可以保证6副本会平均分布在三个数据中心,在完成最小副本数据的写操作时候也可以保证是写在两个不同的数据中心的。

关于CRUSH算法规则的设置可以看CURSH算法规则

同样在Mesos这一层面也是分为slave群和master群,对于master群来说还是建议每个数据中心采用3个master节点,这样一共9个master节点通过ZooKeeper服务选举来实现多节点的高可用,slave节点可以当成一个统一的集群池,不需要区分不同的数据中心,因为这一层面的高可用是通过PaaS执行框架来实现的,在Mesos层没有必要去考虑,Mesos就是作为最底层的 通用的资源调度平台。

在Docker层,容器镜像作为应用运行的实例,被PaaS执行框架通过Mesos进行调度,在跨数据中心的体系下,需要解决镜像仓库数据一致性和网络的问题。对于镜像仓库数据一致性,我认为有两个方案可以采取,一个是在三个数据中心部署三个镜像仓库,但是镜像仓库对外提供服务可以通过服务代理来进行,也可以继续使用ZooKeeper进行服务选举,这样做的好处就是做到镜像仓库服务的高可用,但是这样也就意味着肯定有两个数据中心的镜像服务是通过远程来获取的,这无疑会增大数据中心间的数据传输压力。另一个方案就是在正常情况下各个数据中心部署的Docker默认是使用自己本地的镜像仓库的,在本地镜像仓库出现问题的时候自动切到next repository server,这种方式我认为是比较好的一种方式,既保证了镜像仓库的高可用性,也可以最大程度减少对珍贵的网络资源的占用。

在容器的网络层面,容器网络面临的最大问题就是跨宿主机通信的问题,而且在我设计的容灾体系中更是变成了跨数据中心通信的问题。因此我认为使用大二层的Vxlan可以很好的解决这一问题。Vxlan的基本原理就是使用UDP来封装TCP数据包,也就是隧道封装技术。其实目前主要的容器网络解决方案如Weave、Fennel也是采用这样的方法。

相关的原理和实现方法,感兴趣的可以参考这篇文章:Vxlan实现原理
#容灾体系的技术选型
##DWDM
DWDM就是所谓密集波分复用(Dense Wavelength Division Multiplexing)技术,指的是一种光纤数据传输技术,这一技术利用激光的波长按照比特位并行传输或者字符串行传输方式在光纤内传送数据。这里简单介绍一下一个关键设备就是OXC,这技术架构图里也提到了这个设备。

OXC是下一代光通迅的路由交换机。在全光网络中的主要功能包括:提供以波长为基础的连接功能,光通路的波长分插功能,对波长通路进行疏导以实现对光纤基础设施的最大利用率,实现在波长、波长组和光纤级上的保护和恢复。OXC设置于网络上重要的汇接点,汇集各方不同波长的输入,再将各路信号以适当的波长输出。目前在电信运营商都在逐步的升级替换成OXC,很快就会进入全光网时代。

在目前的商用单模光纤传输技术中,在240KM以内的单模裸光纤可以达到10Gb/s的带宽。如果需要传输更远的距离则需要一些中继设备,这样的话传输带宽就有所损耗,不过随着后续的技术发展,肯定会可以达到更远的记录和更大带宽,所以这也是在设计容灾体系中更多的是考虑异地双活而不是同城双活,因为在基础硬件设施允许的情况下,异地双活更具有价值。
##Vxlan
Vxlan是由VMware和思科提出的标准,使用了L2oUDP的封装方式,支持16M的tenant ID,主要的与其他的技术不同的是通过OVS来实现大二层网络隧道的起点和终点,隧道的封装在服务器内部的Vswitch就已经打好,然后将物理网络当作大的IP背板加以穿透,大二层范围可以跨DC。以期达到快速部署,灵活创建虚拟化网络的目的。

思科最先提出和推广的是自己的OTV技术,这个技术的是思科在自己的交换机做了修改后实现的,简答来说就是隧道本端的OTV模块会将需要跨越数据中心传输的二层帧完整地打包到一个三层数据包中,然后通过路由交付到对端OTV模块进行处理,再隧道对端的OTV模块经过处理后解析出封装在三层数据包中的源MAC 目的MAC以及所要传输的数据包。这种方式是接触交换机的背板转发能力和解析能力来进行的,性能比较有保障。

VMware作为一家软件厂商,没有自己的硬件网络设备,于是VMware就通过自己的Vswitch来支持实现这种MAC in UDP的数据封装,通过IP的多播技术经过路由来实现跨数据中心通信的目的。具体的在前面的一篇链接中也提到,使用OVS是可以模拟实现大二层网络的。但是从实际使用来说,这种基于OVS的技术还是没有完全的成熟,在性能和稳定性上是存在一定的隐患的。不过,现在SDN这么火爆的情况下,可以相信这是最有前途的解决方案。

需要详细的了解Vxlan的技术可以参考Vxlan的实现实验

关于思科的解决方案介绍可以参考思科解决方案
##Ceph

在这个容灾体系中,统一存储Ceph与Docker结合解决容器存储甚至解决跨数据中心数据一致性的问题都是核心的问题,在构想这个容灾体系的时候我的想法是能够将Docker 的rootfs和volume跑在统一存储Ceph集群上,这也是我选择将Ceph作为面向宿主机提供统一存储服务的原因。在之前一篇腾讯游戏的文章提到了Ceph RBD Graph Driver他们说他们已经完成了这一驱动的开发,将rootfs挂载到RBD结合大二层网络实现容器的带IP飘移。但是他们提交给Docker社区后没有被社区接受。在持久化存储方面可以Docker通过volume driver的方式可以对接Ceph,从而实现容器持久化数据卷的功能,也能轻易实现容器的迁移,但是目前Docker官方还是没有正式支持虽然在一些开源项目已经有了解决方案。

因为Ceph目前作为最主流的统一存储解决方案,所以似乎Ceph在对容器存储的支持没有太多动力,我觉得解决容器持久化存储途径不光是要从容器出发,还要从Ceph项目主动的做一些匹配。因此在这个容灾体系中,在Docker支持将rootfs挂载到RBD上之前,我建议还是使用宿主机的本地存储,至于持久化存储可以使用Ceph挂载到宿主机上的文件目录。
##Docker &Mesos
Mesos的选型我觉得需要根据所选用的执行框架,尤其是非Mesosphere生态的执行框架,需要考虑Mesos对执行框架的兼容性,还有就是对Docker版本的支持,不过这个不是很重要,Mesos和Docker的合作还是比较紧密的。

Docker在1.9版本中加入了很多的新特性来解决网络和存储的问题,其中在网络层面就使用了OVS(Open Vswitch)和VXLAN隧道进行实现,这样完全可以使用OVS的兼容性来实现跨数据中心的大二层网络。不过建议,使用专业的大二层网络的OVS解决方案替代Docker1.9中的OVS。关于Docker与Ceph RBD融合的问题我乐观的认为在Docker2.0版本这个问题应该会得到解决,因为这是Docker进入2.0阶段的一个里程碑,为了更快速的发展和在实际生产中得到应用,这个问题是要必须解决的。
#容灾体系存在的问题和可能的解决方案
在这个容灾体系中使用了大二层网络,但是在大二层应用中有一个很致命的问题就是大二层网络风暴的问题,因为Vxlan技术主要是借助IP多播技术来进行类二层交换的,那么就不可避免的引起网络重启后的网络风暴。大家可以想象三个双活数据中心的上万个容器实例同时发起ARP广播引起的网络风暴是多么的可怕,根据传统网络的情况预估,可以瞬间将三个双活数据中心的网络压垮。

关于这个问题的解决方案,我的想法就是通过SDN的Controller来抑制和屏蔽大规模的启动风暴,如通过策略进行区域性的启动。这个问题供大家讨论。
#Q&A
Q:您这个框架中使用的PaaS执行框架具体是什么?

A:这个是开放的,可以是马拉松也可以Kubernetes,这个都没有具体的限定的。因为我觉得这两个都是比较好的执行框架。



Q: Docker的兴起是否会影响OpenStack云计算的地位会和OpenStack竞争,共存?OpenStack工程师如何面对Docker技术的兴起?Unikernel发展趋势能否取代Docker?

A:竞争肯定是有的,但是共存也是存在的,我认为这是一个灰度的。我觉得OpenStack工程师要拥抱Docker,其实我的主要工作就是向客户设计基于OpenStack的私有云解决方案。Unikernel技术的对手不是Docker,是容器。具体是否会取代,我觉得不一定。



Q3:Vxlan具体怎么实现?是核心交换机旁挂大二层设备吗?另外超远距离,比如北京上海这么做会有什么问题?我们现在遇到延迟问题比较大。

A:VxLan的实现在Vswitch中通过对每次TCP包的UDP封装,Vswitch是在每个宿主机上的。北京到上海的话,就需要通过光纤中继,这会损耗一定的传输带宽,这么远距离的传输只能等待光传输技术的发展以及在应用层面进行弥补。不过在应用层去弥补这不是很好的方案。



Q:ZK集群的部署是怎样?有做哪些调优么?另外网络方面有做哪些监控么?

A:主要是根据实际的请求时延对TIMEOUT进行修改,网络方面的监控是通过专业的安全设备进行。



Q: 那个数据中心部署3机Mesos master,所有数据中心共享一个ZK集群,难道这个ZK集群如何在多数据中心部署,还有因为网络延时导致slave掉了后,或者executor挂了后怎么处理孤儿容器。

A:ZK是每台Master节点上的,由于使用了大二层网络,所以所有的ZK就相当于在同一个局域网内部署的。对于孤儿容器,是Kill掉然后替换的。



Q:请问在你们设计的方案中通常建议用户租用几条裸纤来实现三地三中心,同时考虑过租用长距离裸纤给用户带来的长期运维成本吗?

A:恩,这是个好问题,我在准备这次分享的时候也在考虑这个问题。这个设计方案的前提是客户有这样的需求,需要支付这样的成本去实现。从技术的角度,双纤是性能与经济性的平衡点。



Q:请问关于事务处理的负载轮询,如果使用长连接,如何保证每个连接负载是均匀的,同时这里的事务是指存储层的还是应用层的,如果是应用层是如何保证事务的?

A:这个确实比较难,可以采用类似于一致性哈希环的思想,就是尽可能多的将轮询环进行分割,这样长连接就会尽可能的均衡分配。负载轮询是在应用层面进行轮询的。



Q:你们这套架构上生产环境了吗?Ceph是强一致性的,6个副本延迟会不会大?六个副本是不是有点浪费存储空间?大规模写入的时候IO会不会是瓶颈(Ceph 先写Journal,再写磁盘)?另外,你们是全SSD吗?

A:这套架构没有上生产环境。这是我们公司做的一个前瞻性方案设计研究。在Ceph的副本配置中,有一个最小副本数,可以先设置一个最小副本数实现快速的写操作。之所以6副本,主要是防止避免过度频繁的数据读切换。在这种方案下,建议全部是SSD,当然也可以有选择性的使用SAS。



以上内容根据2016年3月29日晚微信群分享内容整理。分享人赵英俊,来自城云科技企业云事业部,从事云计算大数据云存储的项目咨询和管理工作。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

Ceph 成立委员会了,不再是 Red Hat 一家主导

kurtzhong 发表了文章 • 0 个评论 • 3718 次浏览 • 2015-10-30 00:17 • 来自相关话题

Red Hat的Ceph是一个广受欢迎的可以支持软件定义对象和文件云存储套件。尽管Ceph的代码是开源的,但其战略方向在过去由Red Hat掌控。然而这即将成为历史。在东京OpenStack峰会(Toyko OpenStack Summit)上,Red Hat ...查看全部
Red HatCeph是一个广受欢迎的可以支持软件定义对象和文件云存储套件。尽管Ceph的代码是开源的,但其战略方向在过去由Red Hat掌控。然而这即将成为历史。在东京OpenStack峰会(Toyko OpenStack Summit)上,Red Hat宣布它的以Ceph为基础,软件定义存储技术的整体技术走向将会转由刚刚成立的Ceph咨询委员会Ceph Advisory Board)来决定。

具体地,“咨询委员会成立的时候,树立的目标即是:与社区广大的技术以及用户委员会携手,扩大并增强社区在Ceph项目中的参与范围和合作”。

除了Red Hat,Ceph咨询委员会的成员还来自Canonical、CERN、Cisco、Fujitsu、Intel、SanDisk和SUSE等公司。可以简单地讲,Ceph以后不再只是Red Hat一家玩了。

然而,这并不令人意外。开源的Ceph已经被证明了能够在单一而统一的存储集群(single, unified storage cluster)里提供对象、块和文件系统的存储。这使得它非常契合云储存基础设施。根据OpenStack Foundation最新的用户调查报告,Ceph是Openstack中用到最多的的块存储解决方案

在一份声明中,Red Hat基础设施工程开发(Infrastructure Engineering Development)的VP Tim Burke说道:

“Red Hat的关键点一直在于在社区之间开展协作,从而取得任何单个公司都不能独立完成的巨大成果。... 尽管这种与社区和合作伙伴的合作,在过去即使是通过非正式的方式进行,也出人意料的强而有力,但是成立Ceph咨询委员会将这种开放的工作关系正式化了。我们期待与Ceph的社区和伙伴成员一起,不仅能为Ceph带来新的功能,还能提升Ceph在新的不同workload下的集成程度和使用简易度。”



Canonocal,Ubuntu Linux的母公司,Red Hat的对手,也对此表示支持。Christian Reis,Canonocal的Storage&Hyperscale的副总,将Ceph的很大一部分功劳归功于Canonocal:

“Canonical从一开始就驱动着Ceph的进步。在Ubuntu Stack和scale-out部署中,我们把Ceph作为一个关键技术。我们很兴奋能成为Ceph顾问委员会的成员,来帮助Ceph扩大决策的来源,推广使用范围和提高成熟度,帮助Ceph成为企业级存储平台。”



Lars Marowsky-Brée,SUSE杰出工程师,又一个Red Hat的对手,补充说:“Ceph咨询委员会是Ceph从一个开源项目走向一个开放的标准并获得行业内协作与采用的关键一步。SUSE很高兴能参与进来,为帮助开源软件定义存储(software-defined storage)革命的实现做贡献。

在此次的进展之前,Ceph代码仓库被攻击。Red Hat的消息人士说,委员会的创建与网站攻击事件没有关联。

欢迎来到Linux和开源的世界,在这里商业对手可以为了代码而手牵手协作。

Ceph社区咨询委员会将会处理Ceph软件定义存储项目的广大问题。而目标是打造Ceph - 人们口中的云存储系统(the cloud storage system.)。

原文:Red Hat opens up Ceph storage to other cloud leaders(翻译:钟最龙 校对:李颖杰)

在Docker里运行Ceph

juliahan 发表了文章 • 1 个评论 • 9317 次浏览 • 2015-08-04 05:11 • 来自相关话题

【编者的话】Ceph是开源社区深受欢迎的存储方案,具有稳定性高、性能好、可扩展性强等特点。原作者的这篇文章展示并探讨了如何将Ceph运行在Docker上,无疑为Docker生态系统的完善迈出了重要一步。存储问题是将Docker应用于生产环境中的备受关注的话题之 ...查看全部
【编者的话】Ceph是开源社区深受欢迎的存储方案,具有稳定性高、性能好、可扩展性强等特点。原作者的这篇文章展示并探讨了如何将Ceph运行在Docker上,无疑为Docker生态系统的完善迈出了重要一步。存储问题是将Docker应用于生产环境中的备受关注的话题之一,这篇文章抛砖引玉,必将激发广大开源和Docker技术爱好者探究现有存储方案与Docker相整合的热情。

Ceph是一个完全开源的分布式存储方案、网络块设备以及文件系统,具有高稳定性、高性能、高扩展性等特点,可应对terabyte到exabyte级别的数据量。通过使用创新性的调度算法(CRUSH)、主动存储节点、以及peer-to-peer的gossip协议,Ceph规避了传统集中控制和lookup table中的扩展性和可靠性问题。Ceph目前在整个开源社区中极受推崇,已被广泛应用与虚拟化平台(Proxmox)、云计算平台(OpenStack、 CloudStack、OpenNebula)、容器技术(Docker)、以及大数据分析系统(Hadoop、作为HDFS的meted服务器)中。

我尝试将Ceph运行在Docker中已经快两年了。直到今天我依然在做这些工作。最近我更是在Docker中部署Ceph方面投入了不小的精力。

(在展开技术细节前,我要特别感谢Sean C McCord对此工作的大力支持,当年的开源ceph-docker项目也的确是基于Sean的早期工作)

现在让我们具体看看如何将Ceph运行在Docker里!
#原理
将Ceph运行在Docker中是一个比较有争议的话题,不少人质疑这样操作的意义。虽然将检测模块、metadata服务器、以及RADOS gateway容器化都没有太大问题,但对于OSD(object storage daemon),事情会变得很棘手。Ceph的OSD专门针对物理机器进行优化,与底层硬件有很多关联。如果物理硬盘失效,OSD也无法运作,这给容器化的场景带来了问题。

坦白地讲,在过去某个时刻我也在想:

“我不知道自己为什么做这个,我只知道有人需要这个功能(当然,他们可能也不知道为什么想要)。我只是觉得想进行技术尝试,那就试试看!”



当然上述想法听起来并不乐观,但这确实是我当时真实的想法。我的观点随后有了一些变化,我来解释下为什么是值得的。希望这个解释也能改变你的看法(我的解释不仅仅是“Docker很酷,所以我们要把所有东西都跑在Docker里!”)。

不少开发者已经花了很多时间将他们的软件容器化。在这个过程中,他们也用过多种不同的工具来构建和管理他们的环境。如果我看到有人用Kubernetes来作为管理工具也一点都不会吃惊。有的人就喜欢将最新潮的技术应用到生产当中,否则他们会觉得工作很无聊。所以当他们看到自己最喜欢的开源存储方案也正在被容器化时,他们会因为这个顺应了“一切容器化”的方式而感到高兴。

与传统的`yum`或`apt-get`不同,容器使得软件的升级和回卷变得容易:我们可以通过`docker stop`或者`docker run`来发布新的daemons版本。我们甚至可以在一台物理机器上运行多个相互隔离的集群。这些都为开发过程提供了极大的便利。
#项目
如上所述,所有的工作都基于Sean C McCord的早期贡献,我们后来都在围绕他的工作做完善。现在如果你用ceph-docker,你可以将每个单一的Ceph daemon运行在Ubuntu或CentOS上。我们在Docker Hub里有很多的镜像,我们使用Ceph的命名空间,因此我们的镜像前缀都是ceph/。我们使用了自动构建,因此每次我们整合一个新的补丁就会触发新的构建,从而生成一个新的容器镜像。由于我们现在在从事代码重构,你会看到有很多的镜像版本。一直以来我们对每一个daemon构建一个单独的镜像(我们整合这些补丁的时候都会这样做)。所以监测、OSD、mds和radosgw各自都有独立的镜像。这个并不是最理想的方案,因此我们在尝试将所有组件都整合到一个叫做`daemon`的镜像中。这个镜像包含了所有的模块,你可以在运行`docker run`的时候通过命令行选择性地激活不同模块。如果你想试用我们的镜像,我们推荐使用`ceph/daemon`镜像。下面我就举例说明如何运行。
#容器化Ceph
##监测
由于监测模块不能在NAT过的网络中进行通信,我们必须使用 `--net=host`来将主机的网络层开放给容器:
$ sudo docker run -d --net=host \
-v /etc/ceph:/etc/ceph \
-v /var/lib/ceph/:/var/lib/ceph \
-e MON_IP=192.168.0.20 \
-e CEPH_PUBLIC_NETWORK=192.168.0.0/24 \
ceph/daemon mon

你可以配置如下选项:

  • `MON_IP`是运行Docker的主机IP
  • `MON_NAME`是你监测模块的名称(默认为$(hostname))
  • `CEPH_PUBLIC_NETWORK`是运行Docker的主机的CIDR。它和`MON_IP`必须是同一个网络。
  • `CEPH_CLUSTER_NETWORK`是运行Docker的主机的备用网口的CIDR,为OSD的备份流量使用。
##Object Storage Daemon我们现在能实现允许每一个OSD进程运行在一个独立的容器里。按照微服务的理念,一个容器里不应该运行超过一个服务。而在我们这里,在同一个容器里运行多个OSD进程,打破了这一理念,当然这也会给系统的配置和维护带来额外的复杂度。在这样的配置下,我们必须使用`--privileged=true`来使得容器中的进程可以访问`/dev`等其他内核功能。然后,我们在开放OSD的目录的基础上也支持其他配置,开放OSD的目录可以让operators来对设备做合适的准备工作。这样我们就可以简单地开放OSD目录,配置OSD(`ceph-osd mkfs`)的工作就会通过Entry Point来完成。我下面介绍的配置方法是最简单的,因为它只需要你指定一个block device,剩下的事情都会由Entry Point完成。如果不想用`--privileged=true`可以采用我的第二个例子。
$ sudo docker run -d --net=host \--privileged=true \-v /etc/ceph:/etc/ceph \-v /var/lib/ceph/:/var/lib/ceph \-v /dev/:/dev/ \-e OSD_DEVICE=/dev/vdd \ceph-daemon osd_ceph_disk
如果你不想使用`--privileged=true`,你也可以使用你喜欢的配置管理工具来手动配置OSD。下面这个例子我假定你已经实现分区并配置好文件系统。运行下面的命令来生成你的OSD:$ sudo docker exec ceph osd create.然后运行你的容器:
docker run -v /osds/1:/var/lib/ceph/osd/ceph-1 -v /osds/2:/var/lib/ceph/osd/ceph-2$ sudo docker run -d --net=host \-v /etc/ceph:/etc/ceph \-v /var/lib/ceph/:/var/lib/ceph \-v /osds/1:/var/lib/ceph/osd/ceph-1 \ceph-daemon osd_disk_directory
可配置的选项如下: - `OSD_DEVICE i`是OSD设备,例如:`/dev/sdb` - `OSD_JOURNAL`使用来储存OSD journal的设备,例如:`/dev/sdz` - `HOSTNAME`是运行OSD的主机(默认为$(hostname) - `OSD_FORCE_ZAP`会强制将制定的设备内容zapping(默认为 0,设为1去开启) - `OSD_JOURNAL_SIZE`是OSD journal的大小(默认为 100)##Metadata 服务器这个组件的设置较为直观。唯一需要注意的地方是在Docker中我们可以访问Ceph管理员密钥。这个密钥会用来生成CephFS pools和文件系统。如果你运行0.87以前的Ceph版本,你就不需要做此配置,然而我们最好运行最新的版本!
$ sudo docker run -d --net=host \-v /var/lib/ceph/:/var/lib/ceph \-v /etc/ceph:/etc/ceph \-e CEPHFS_CREATE=1 \ceph-daemon mds
可配置的选项如下:
  • `MDS_NAME`是Metadata服务器的名字(默认为mds-$(hostname))。
  • `CEPHFS_CREATE`会为Metadata服务器生成文件系统(默认为0,设为1 去开启)。
  • `CEPHFS_NAME`是Metadata文件系统的名字(默认为cephfs)。
  • `CEPHFS_DATA_POOL`是Metadata服务器data pool的名字(默认为cephfs_data)。
  • `CEPHFS_DATA_POOL_PG`是data pool的placement groups的数量 (默认为8)。
  • `CEPHFS_DATA_POOL`是Metadata服务器metadata pool的名字(默认为cephfs_metadata)。
  • `CEPHFS_METADATA_POOL_PG`是metadata pool的placement groups的数量(默认为 8)。
##RADOS gateway我们部署RADOS gateway时默认开启`civetweb`。当然,我们也可以通过指定地址和端口来使用不同的CGI前端:
$ sudo docker run -d --net=host \-v /var/lib/ceph/:/var/lib/ceph \-v /etc/ceph:/etc/ceph \ceph-daemon rgw
可配置的选项如下:
  • `RGW_REMOTE_CGI`指定是否使用嵌入的web服务器(默认为0,设为1去关闭)。
  • `RGW_REMOTE_CGI_HOST`指定运行CGI进程的远程主机。
  • `RGW_REMOTE_CGI_PORT`是运行CGI进行的远程主机端口。
  • `RGW_CIVETWEB_PORT`是civetweb的监听端口(默认为80)。
  • `RGW_NAME`是RADOS gateway实例的名字(默认为$(hostname))。

#后续工作
##后端配置存储
在默认配置下,`ceph.conf`和所有的Ceph密钥都会在监测模块启动阶段生成。这个过程假定了你必须在将集群扩展到多节点的时候去把这些配置传送到所有节点上。这个操作并不灵活,我们希望去改善它。我马上要提出的一个方案就是利用Ansible来生成这些配置文件和密码,并将他们安装到所有机器上。

另一种方法是将所有的配置信息存储到不同的后端服务器上,例如etcdconsul
##部署管理
最直观的方案是使用现成的ceph-ansible,虽然我还需要做一些变动,但主体工作已经完成。另一种方案是使用Kubernetes,他们的预览版本已经发布。
##支持Rocket等其他容器技术
也不需要做什么,因为你可以直接将你的Docker镜像运送到Rocket里,然后运行。

想要知道更多?可以看看视频

原文链接:Running Ceph inside Docker(翻译:Julia Han 审校:魏小红)

========================================
译者介绍:
Julia Han:School of Information Sciences, University of Pittsburgh, USA,硕士,Docker爱好者。

Docker Ceph系列之第二篇:使用灵雀云启动Docker Ceph对象存储(S3或Swift)

Georce 发表了文章 • 0 个评论 • 5060 次浏览 • 2015-06-22 01:45 • 来自相关话题

【编者的话】 我是吴健,来自上海[Hypers ](http://www.hypers.com )国内顶尖的大数据分析公司,参加过“云雀Docker巨好玩”并获得一等奖,年纪尚小请大家多多指教。因为有人提出了这个想法,我之前已经成功实践过这些实验, ...查看全部
【编者的话】 我是吴健,来自上海[Hypers
](http://www.hypers.com )国内顶尖的大数据分析公司,参加过“云雀Docker巨好玩”并获得一等奖,年纪尚小请大家多多指教。因为有人提出了这个想法,我之前已经成功实践过这些实验,自己也就把百度和Google不到的私房菜贡献出来,只有一个要求,希望大家互相帮助,不要自吹自擂就行,多多分享。

顺便向大家推荐下云雀平台 http://www.alauda.cn
还有Daocloud https://www.daocloud.io
希望大家互相扶持,互相帮助,与DockOne&OSchina还有所有的开源社区一起推动国内的Docker商用和技术能力。

用Docker搭建Ceph对象存储非常简单,只需要几条命令就可以搞定,甚至比Ceph出的ceph-deploy还方便,也无需翻墙获得软件包。

上一篇为 使用Docker搭建Ceph集群

我的部署环境是
灵雀云Docker平台
#注册并登陆灵雀云
浏览镜像—》搜索 ceph-demo
ala-1.jpg

#选择georce/ceph-demo
创建服务
ala-2.jpg

#配置必要的参数
ala-3.jpg

#等待运行成功
ala-4.jpg

#服务的URL则为对象存储的API地址
ala-5.jpg

#自带webshell功能
ala-6.jpg

#登陆方式如下
ala-7.jpg

#创建S3用户
root@426debfd7cb7:/opt# radosgw-admin user create --uid="testuser" --display-name="First User"
{
"user_id": "testuser",
"display_name": "First User",
"email": "",
"suspended": 0,
"max_buckets": 1000,
"auid": 0,
"subusers": [],
"keys": [
{
"user": "testuser",
"access_key": "MBFIV44FH7FIV96UM124",
"secret_key": "idSCzjsrHNDXPZdLK2cgOpE2UkM6Jx5lhdMM9DvY"
}
],
"swift_keys": [],
"caps": [],
"op_mask": "read, write, delete",
"default_placement": "",
"placement_tags": [],
"bucket_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
},
"user_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
},
"temp_url_keys": []
}

#创建对象存储桶
root@426debfd7cb7:/opt# sed -i s@archive.ubuntu.com@mirrors.aliyun.com@g /etc/apt/sources.list
root@426debfd7cb7:/opt# apt-get update
root@426debfd7cb7:/opt# apt-get install vim -y
root@426debfd7cb7:/opt# apt-get install python-pip -y
root@426debfd7cb7:/opt# pip install boto

root@426debfd7cb7:/opt# vim s3.py

import boto
import boto.s3.connection
access_key = 'MBFIV44FH7FIV96UM124'
secret_key = 'idSCzjsrHNDXPZdLK2cgOpE2UkM6Jx5lhdMM9DvY'
conn = boto.connect_s3(
aws_access_key_id = access_key,
aws_secret_access_key = secret_key,
host = 'ceph-smoak.myalauda.cn',
is_secure=False,
calling_format = boto.s3.connection.OrdinaryCallingFormat(),
)
bucket = conn.create_bucket('georce')
for bucket in conn.get_all_buckets():
print "{name}\t{created}".format(
name = bucket.name,
created = bucket.creation_date,
)

root@426debfd7cb7:/opt# chmod 755 s3.py

root@426debfd7cb7:/opt# python s3.py

georce 2015-06-21T16:56:07.000Z

#测试成功

Docker Ceph系列之第一篇:使用Docker搭建Ceph集群

Georce 发表了文章 • 13 个评论 • 9940 次浏览 • 2015-06-15 22:38 • 来自相关话题

【编者的话】 我是吴健来自上海[Hypers ](http://www.hypers.com )国内顶尖的大数据分析公司,参加过“云雀Docker巨好玩”并获得一等奖,年纪尚小请大家多多指教。因为有人提出了这个想法,我之前已经成功实践过这些实验,自 ...查看全部
【编者的话】 我是吴健来自上海[Hypers
](http://www.hypers.com )国内顶尖的大数据分析公司,参加过“云雀Docker巨好玩”并获得一等奖,年纪尚小请大家多多指教。因为有人提出了这个想法,我之前已经成功实践过这些实验,自己也就把百度和Google不到的私房菜贡献出来,只有一个要求,希望大家互相帮助,不要自吹自擂就行,多多分享。

顺便向大家推荐下云雀平台 http://www.alauda.cn
还有Daocloud https://www.daocloud.io
希望大家互相扶持,互相帮助,与DockOne&OSchina还有所有的开源社区一起推动国内的Docker商用和技术能力。

用Docker搭建Ceph非常简单,只需要几条命令就可以搞定,甚至比Ceph出的ceph-deploy还方便,也无需翻墙获得软件包。

我的部署环境是
Disk free > 30G
Ceph 0.94.1 hammer
OS Ubuntu 14.04.2
Kernel 4.0.5
overlayfs
eth0 IPADDR=192.168.1.100

#下载mon和osd
[root@ubuntu ~]# docker pull index.alauda.cn/georce/mon:hammer
[root@ubuntu ~]# docker pull index.alauda.cn/georce/osd:hammer

# 一条命令搭建mon
[root@ubuntu ~]# docker run -itd --name=mon --net=host -e MON_NAME=mymon -e MON_IP=192.168.1.100 -v /etc/ceph:/etc/ceph index.alauda.cn/georce/mon:hammer

#查看mon运行日志
[root@ubuntu ~]# docker logs -f mon

2015-06-15 13:48:38.414494 7fd43f5db700 1 mon.mymon@0(leader).osd e1 e1: 0 osds: 0 up, 0 in
2015-06-15 13:48:38.416236 7fd43f5db700 0 mon.mymon@0(leader).osd e1 crush map has features 1107558400, adjusting msgr requires
2015-06-15 13:48:38.416306 7fd43f5db700 0 mon.mymon@0(leader).osd e1 crush map has features 1107558400, adjusting msgr requires
2015-06-15 13:48:38.416391 7fd43f5db700 0 mon.mymon@0(leader).osd e1 crush map has features 1107558400, adjusting msgr requires
2015-06-15 13:48:38.416479 7fd43f5db700 0 mon.mymon@0(leader).osd e1 crush map has features 1107558400, adjusting msgr requires
2015-06-15 13:48:38.416712 7fd43f5db700 1 mon.mymon@0(leader).paxosservice(auth 1..1) refresh upgraded, format 0 -> 1
2015-06-15 13:48:38.418924 7fd43f5db700 0 log_channel(cluster) log [INF] : mdsmap e1: 0/0/0 up
2015-06-15 13:48:38.423753 7fd43f5db700 0 log_channel(cluster) log [INF] : osdmap e1: 0 osds: 0 up, 0 in
2015-06-15 13:48:38.428045 7fd43f5db700 0 log_channel(cluster) log [INF] : pgmap v2: 64 pgs: 64 creating; 0 bytes data, 0 kB used, 0 kB / 0 kB avail

#查看mon生成的集群配置文件
[root@ubuntu ~]# ls /etc/ceph

[root@ubuntu ~]# ceph.client.admin.keyring ceph.conf ceph.mon.keyring monmap

#更改集群配置文件
[root@ubuntu ~]# vi ceph.conf

[global]
fsid = 4efc5ee7-8982-4bf4-808b-15372862fb78 #这个要看你生成的 别抄我的
mon initial members = mymon
mon host = 192.168.1.100
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
osd crush chooseleaf type = 0
osd journal size = 100
osd pool default pg num = 8
osd pool default pgp num = 8
osd pool default size = 1
public network = 192.168.1.0/24
cluster network = 192.168.1.0/24

[root@ubuntu ~]# docker restart mon

#两条命令创建osd
[root@ubuntu ~]# docker exec mon ceph osd create
0

如果不知道上面的0是什么,我解释下 ceph osd 0 /var/lib/ceph/osd/ceph-0

# 创建osd0
[root@ubuntu ~]# docker run -itd --name=osd0 --net=host -e CLUSTER=ceph -e WEIGHT=1.0 -e MON_NAME=mymon -e MON_IP=192.168.1.100 -v /etc/ceph:/etc/ceph -v /opt/osd/0:/var/lib/ceph/osd/ceph-0 index.alauda.cn/georce/osd:hammer

#查看ceph群集状态
[root@ubuntu ~]# docker exec -it mon ceph -s

cluster 4efc5ee7-8982-4bf4-808b-15372862fb78
health HEALTH_OK
monmap e1: 1 mons at {mymon=192.168.1.100:6789/0}
election epoch 2, quorum 0 mymon
osdmap e5: 1 osds: 1 up, 1 in
pgmap v7: 64 pgs, 1 pools, 0 bytes data, 0 objects
3584 MB used, 42028 MB / 48077 MB avail
64 active+clean

雅虎Ceph的Exascale级存储

testA 发表了文章 • 0 个评论 • 2915 次浏览 • 2015-06-12 11:55 • 来自相关话题

【编者的话】像Yahoo、Facebook这样的企业都需要存储数亿级的用户图片,他们都在为实现这个目标而努力,Yahoo将非结构数据的MObStor对象存储系统转移到了Ceph上,并且正在部署最新的基于Ceph的系统—云对象存储,Yahoo在数百个PB级规模上 ...查看全部
【编者的话】像Yahoo、Facebook这样的企业都需要存储数亿级的用户图片,他们都在为实现这个目标而努力,Yahoo将非结构数据的MObStor对象存储系统转移到了Ceph上,并且正在部署最新的基于Ceph的系统—云对象存储,Yahoo在数百个PB级规模上操作,显然已经是业内老大。

任何超级巨头们都不会等待IT产业技术的自我更新,来满足自己应用的需求,但是当一个可替代的开源项目成长足够成熟,巨头们通常会从自己的软件到其他栈上做跨越式部署。从雅虎的门户网站上我们可以清晰的看到,Yahoo的重心从自己研发的对象存储转移到了即将成为exascale级别的系统,这个系统基于开源项目Ceph,一种Swiss army knife的存储。

这样的跨越并不常见,因为这些超级公司更倾向去超越技术规模的限制,不论是他们自己的技术还是开源项目,当然通常是开源项目。但这种情况确实存在。比如说这周早些时候谈到的平台,媒体巨头Netflix,它一直使用Cassandra NoSQL 数据库的一个自定义版本来作为控制流媒体服务和用户交互的后端,去年秋天,它将端口从DataStax转移到Cassandra的商业级别的 variant上。而Yahoo正在进行一次更大的跨越,他们将自己研发的用于非结构数据的MObStor对象存储系统转移到了Ceph上,Yahoo的架构副总监说,他们这次的变化是经过慎重考虑的。
#所有的信息技术都从cat图片开始
雅虎是对象存储领域规模上的创新者,就如同Facebook和他的Haystack系统,Amazon和他的S3系统,Mosso Cloud Files系统曾经是Rackspace Hosting的Swift对象存储的基础,而现在已成为OpenStack云控制器的一部分。Yahoo和Facebook都要存储数亿级别的用户图片,处理PB级别的容量,这就迫使他们开发自己的系统,实现更高效的图片存储功能,亚马逊和Rackspace假设,创建云应用的用户同样希望将丰富的媒体嵌入到图片上,所以他们想将对象存储变成他们公有云的一部分。

上面提到的所有对象存储系统,Haystack、 MObStor、 S3、Cloud Files/Swift, 他们被开发都是因为文件系统中常规存储阵列都存在非常大系统开销,这是因为用来跟踪对象的元数据存在于集群中。对象存储刚好忽略了文件系统,并将所有数据放在同一个bucket里,然后使用一个key,比如文件名或web的地址,在集群中找到该数据。这样可以使元数据的开销更小,因为没有文件系统与之抗衡。

十几年前,早期的雅虎图片服务器是由一个特殊的存储系统来处理非结构数据,其之后是一个由Yahoo开发,被称为MObStor的系统,它是一个用起来更加复杂、更具有普遍性的对象存储系统,Yahoo于2009年的夏天首次公开提及MObStor。2005年,雅虎的图片分享网站Flickr急需一种类似于对象存储的技术,然而当时MObStor被雅虎应用程序用来储存JavaScript和HTML代码以及富媒体,在2010年夏天,雅虎的工程师更新了MObStor,这在当时非常先进,这也是在六个月内系统的处理能力增长了4X(倍)的一个因素。当Yahoo揭露MObSto的时候,它仍在运作,而且运行在专用系统Direct Object Repository Architecture (DORA)上,DORA是针对MObStor的一个新后端,被称作是一个集群对象存储系统,它在很多方面与Ceph非常相似。MObStor是DORA后端系统的接口,Yahoo的程序员写这个系统是因为他们需要存储非结构性内容,比如照片、视频和其他类似的数据。DORA是运行在普通硬件和存储应用上的,雅虎当时还不太明确这些意味着什么,但是DORA后端特点允许Yahoo在更廉价的系统上做对象存储,这也就说明了一切。

我们将在数百个PB级规模上操作,我不知道其他Ceph社区是否还会这样做。如果我们不是最大的,那么我们就会成为最大的产品用户,而且我们很可能会去寻找适合我们规模的版本。你只需要看雅虎这个规模的数据,不用看传统的那些。

经过一些改进,McMillen说贯穿Yahoo所有的服务和中心数据,如果将对象、块和文件存储叠加在一起,这将是一个exabyte级别的存储。在发布过的一篇微博中说到,Yahoo从MObStor迁移到Ceph上是因为Flickr上的照片分享服务,公司说那有250亿个对象,将近500PB的照片、视频、邮件和博客帖子。这些都是为用户存储的,并且存储量仍以每年百分之20-25速度增长。



根据McMillen所述,MObStor具有“完整特性”,它广泛部署于雅虎。那么如果MObStor真的被广泛应用和被看好,为什么Yahoo却热衷于一个新的技术了?不管怎样这些都涉及到了钱。

首先,MObStor是一个闭源项目,这意味着雅虎不得不独立完成创建、扩展和所有支撑工具。与之对应的是Yahoo所创的Hadoop数据分析平台,这是一个开源项目,在这个平台有一群资深的工程师,他们在不断改进平台上的所有的layer,这体现出了社区的价值。

"我想说,转向Ceph的最主要是因为我们仅仅想降低存储费用",McMillen解释,"我们的存储已经增长了许多,我们在尽可能得缩减成本,尽可能得拥有更多的选择,而不是坚守着一个系统,一种技术或一种硬件架构。

原始的MObStor对象存储是运行在存储阵列上,存储阵列上有动态保护RAID数据,保证了文件安全。随着DORA的使用,雅虎增加了选项,用来复制存储集群中阵列之间的数据。RAID和复制带来了一个很大的开销,而 McMillen却不愿意透漏出任何有关MObStor与Ceph在这个方面对比的详细信息。但他却说过,对传统对象存储系统的检查发现,这个开销对三路复制来说为200%,伴随着纠删码技术运用到Ceph及其他的对象存储,能将开销降低到40-60%,这些能在雅虎安装调试Ceph中看到,McMillen说最接近的40%的开销在纠删码保护校验来确定数据的原始性。这个意味着雅虎在Ceph上存储容量的开销是用传统对象存储的一半,而且还是三副本。

MObStor/DORA不支持纠删码,雅虎不得不将这个移植到该系统上,这可意味着大量的开发和测试的工作量的产生。另一方面Ceph是一个exascale级部署设计,它有纠删码技术以确保数据的内建。(有了纠删码,少量无结构数据碎片和分散存储,或者如果一部分丢失,纠删码算法可以重建丢失数据)
#云对象存储
雅虎正在部署最新的基于Ceph的系统,它被称为云对象存储,从去年秋天开始,它已经被雅虎stack的Flickr部门试验。Flickr在管理上有“多PB级别”的Ceph容量,在本年度雅虎计划增加10个基数来达到“轻量过百PB级别”,据McMillen所说,当推出基于Ceph的云对象存储,将其隶属于Flickr、雅虎邮箱、Tumblr(轻量博客)。(McMillen说Flickr会有更多的存储量,其中的一分部还会在MObstor中保留一段时间)

雅虎也曾经关注过swift和Gluster文件系统,还有那些为寻找新的对象存储系统的特有选择,最终他们将注意力放在了Ceph上。首先,McMillen说Ceph有吸引力的地方是将支持对象和块存储两者于一身,如果Ceph社区永远如此高效处理问题,在未来某一天(很有希望)Ceph同样支持文件系统存储。

“并不是所有雅虎的存储都适合对象存储,但是很多却适合”,McMillen说到,“我们正在使用块存储,但是他们却没有对象存储走的远。我们非常喜欢Ceph,除了它因纠删码而产生的低成本和它是一个开源项目,在开发者的社区发展非常迅速外,还因为它是一个同时具有块存储和对象存储能力的单一存储系统。所以代替块、对象分开的存储系统,我们可以灵活掌握一种技术栈而获得两种使用方法。而且如果Ceph有一个稳定的文件系统,我们今天绝对会使用它。”

Ceph社区(后台是Red Hat,其已经在一年前以175 百万获得Ceph管理Inktank)仍在专注它 。

McMillen说,当Ceph可以从单个集群扩展到exabyte级存储系统,雅虎将Ceph应用于pod架构,这会比一个单一集群具有更好的性能预测性和错误隔离性,效果如下:
11.jpg

在雅虎云对象存储上,每一个节点(被称作一个对象存储设备),有60TB的存储,这都是基于X86的服务器。雅虎已经尝试过每个节点配置12-72个设备,对于COS服务,Yahoo没有透露其硬件配置。每个集群有54个这样的节点,总容量可达3.2 pb。为了向外扩展这些服务,雅虎复制pods并使用哈希算法来打破利用纠删码横跨pods和节点的无结构数据。

依赖这些应用,雅虎正在使用常规的硬件驱动和磁盘,他们使用的是shingled magnetic recording (SMR)技术,在容量和花费上都不同;SSDs也被部署到了COS服务来提供更高的I/O率。

雅虎正在Ceph的variant上使用8/3纠删码,这说明8份中的3份共享对象的服务或者驱动可以失败却仍然可以访问的到。这是常规级别的纠删码在Ceph上应用的。但是雅虎已经计划了一个针对Ceph的11/3纠删码variant,这意味着11个中的3个驱动或者服务可以失败,更重要的是这个可以减少40%的读写延迟。(根据McMillen的说法,雅虎计划把这项改进回馈给Ceph社区,通过这个方法,它能让自己参与到“Hummer”代码稀释中)公司已经做出了一系列调整来使Ceph表现出更好的性能,如下图:
222.jpg

加入了纠删码的更改,雅虎已经想出一个共享bucket索引的方法,那就是一个索引保持跟踪对象存储到一个bucket(这是针对对象存储容量单位的亚马逊术语)正常Ceph是在一个单一的服务器节点上实现bucket索引,但是雅虎的工程师为了高可用性和性能方面的改进,已经解决了如何切分和跨节点传播。当有磁盘或服务器失效,数据恢复完成,雅虎想出一个在恢复数据时将延迟的速率限制到60%的方法。

与此同时,雅虎自支持Ceph的实现,但是McMillen说公司与RehHat关系非常好,而且也不反对使用RedHat做一些技术支持。但是雅虎正处于一个大量消耗的时期,而这与超大规模Ceph有关,也许自支持是他们现在唯一的选择。

“我们将在数百个PB级规模上操作,我不知道其他Ceph社区是否还会这样做”,McMillen说。“如果我们不是最大的,那么我们就会成为最大的产品用户,而且我们很可能会去寻找适合我们规模的版本。你只需要看雅虎这个规模的数据,不用看传统级别。我们正致力于解决所有这些问题,我相信社区会从中受益。

原文链接: Inside The Ceph Exascale Storage At Yahoo

Ceph vs Swift - 架构剖析

崔婧雯 发表了文章 • 0 个评论 • 9602 次浏览 • 2015-05-29 22:57 • 来自相关话题

【编者的话】Ceph和Swift,哪种更好?这个问题上大家争论不休,本文从两者的架构角度分析两种方式各自的优缺点,并且给出如何选择的建议。 当工程师们讨论存储,谈到Ceph和Swift时,他们通常都一致认为其中一个非常棒,另外一个却很 ...查看全部
【编者的话】Ceph和Swift,哪种更好?这个问题上大家争论不休,本文从两者的架构角度分析两种方式各自的优缺点,并且给出如何选择的建议。

当工程师们讨论存储,谈到Ceph和Swift时,他们通常都一致认为其中一个非常棒,另外一个却很糟糕。但问题时,他们在哪个好哪个不好上却意见不一。

经常会有客户问我相同的问题,“我们听说Ceph可以代替其他所有类型的存储。为什么不能用它做所有事情呢?”

我会在Vancouver的OpenStack Summit大会上从架构角度探讨Ceph和Swift,分享在这两者之间到底该如何抉择,也会为两种平台的解决方案都给出建议。本文,我们一起看看他们的架构细节和不同之处。
#深入浅出
Swift在OpenStack开始发展之初就出现了,大概在五年之前。它是OpenStack的核心项目,并且被无数次证明强大且稳定。

问题是,Swift的设计导致在传输速度和延迟时间上都不强。造成这个问题的主要原因是Swift集群进出的流量都要通过代理服务器。

另一个原因,也是很多人认为Ceph更好的原因,是Swift不支持块存储和文件存储。

最后,当对象副本不一定同时更新时延迟的问题便会浮现,这会导致请求者在第一次更新某个对象到新版本之后,读取到的却仍然是旧版本。这种行为被称为最终一致性。

另一方面,Ceph也有自己的问题,特别是在云环境上。它的多地域支持,虽然经常被当做优势来宣传,但实际上还是master-slave模型。因为只能从master到slave进行复制,所以在多于两个地域时,基础架构上的负载分布会很不均衡。

Ceph的两地域设计也不太实际,因为只支持master上的写入,而不阻隔slave上的写入。这样的配置最严重时可能导致整个集群的崩溃。

Ceph的另一个短板是安全性。云计算节点上的RADOS客户端直接与RADOS服务器交互所使用的网络与Ceph用于未加密复制流量的网络相同。如果某个Ceph客户端节点被入侵,攻击者便能得到存储网络的所有流量。

针对Ceph的弱点,你可能会问,为什么不直接构建一个Ceph集群,扩展到两个地域呢?一个原因是Ceph只能同步写入,并且要求写入节点达到quorum数才能成功返回。

了解这些问题之后,我们来假定有一个集群跨越两个地域,相隔数千英里,100ms延时,非常慢的网络连接。假定将两个副本写入到本地地域,另外两个写入到远程地域。这时四次副本的quorum数是三次,这就意味着这次写请求在至少完成一次远程拷贝前都不会返回。也就意味着即使是很小量的一次写入也会延迟0.2秒,而大批量写入则会因为吞吐量限制严重受阻。

另一方面,Swift,在与之相同的两地域架构中,会先在本地写入,然后基于一致性设计在一段时间里复制到远程地域。Swift也要求写入quorum,但是可以在集群上配置write_affinity设置强制限定写入quorum在本地地域,因此本地写入完成后就会成功返回。

那么我们在Ceph和Swift之间如何抉择呢?

#如何选择?
如果部署只在单一地域,没有计划扩展到多个地域的话,Ceph会是很好的选择。Mirantis OpenStack底层可以选择Glance或者Cinder。但是,如果要考虑大规模部署的话,Swift比Glance更适合。它的多地域能力会胜过Ceph的速度和强大的一致性模型。

很多情况下,速度并不是决定因素,安全性则是更大的问题,这时,Swift更适合,它封闭的复制网络更为安全。另一方面,如果云基础架构本身已经很安全,存储安全性优先级便会降低,这时可能Ceph更适合。

与其比来比去,不如在同一个云基础架构里同时拥有这两种选择。比如,可以使用Ceph作为本地高性能存储,而Swift则作为多地域Glance后台,这时复制很重要而速度并不关键。但是,拥有这两种选择的解决方案花费必然更多,因此可能还是需要二选一。

对于很多客户,我的个人建议是,Mirantis提供了架构设计评估来帮助收集所有需求和参数,提供适合特定使用场景和业务驱动的解决方案,会帮助全面评估所有业务,技术和运营因素。然后你可以权衡这些因素,以及这两种选择的优缺点。谁知道呢?你的收获很可能超过预期。

原文链接:Ceph vs Swift – An Architect’s Perspective(翻译:崔婧雯 校对:魏小红)
===========================
译者介绍
崔婧雯,现就职于IBM,高级软件工程师,负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化,中间件技术,业务流程管理有浓厚的兴趣。

理解Ceph:一个开源的分布式存储平台

Doit05 发表了文章 • 5 个评论 • 17513 次浏览 • 2015-04-14 17:41 • 来自相关话题

【编者的话】Ceph是一个符合POSIX、开源的分布式存储系统。最初由Sage Weill于2007年开发,Ceph的主要目标是设计成基于POSIX的没有单点故障的分布式文件系统,使数据能容错和无缝的复制。本文详细介绍了Ceph的历史和架构。 ...查看全部
【编者的话】Ceph是一个符合POSIX、开源的分布式存储系统。最初由Sage Weill于2007年开发,Ceph的主要目标是设计成基于POSIX的没有单点故障的分布式文件系统,使数据能容错和无缝的复制。本文详细介绍了Ceph的历史和架构。

Ceph是一个软件分布式存储平台,可运行在商用硬件上。为了了解Ceph的运行效率,我们首先要弄清什么是商用硬件。商用电脑是由多个硬件供应商提供的硬件组装而成的,供应商们开发这些硬件是基于同一个开放标准的。与超级微型计算机相比,商品电脑的成本更低,并且它的开放标准能减少众多硬件提供商提供的硬件差异性。Ceph存储集群运行在商用机上,为了确保集群中数据的分布式存储和良好的可扩展性,Ceph运用了著名的CRUSH(Controllled Replication Under Scalable Hashing)算法。Ceph开发的主要目标是提供高可扩展性和提供对象存储、块存储和文件系统的存储机制。Ceph提供一个单一的存储平台,可以处理所有类型的数据存储(包括对象、块和文件)。它的高扩展性可以达到PB级,它还拥有高容错性和高一致性数据冗余机制。
## Ceph的历史
在2004年,Sage Weil开发了一个名叫Ceph的开源项目,并于2006年,基于开源协议开源了Ceph。Weil 曾经是“Inktank Storage”公司的创始人。Inktank Storage一直专注于Ceph的研发,直到它被红帽收购。2012年,Ceph的第一个稳定版本发布了。2014年10月,Ceph的开发团队发布了Ceph的第七个稳定版本Giant。为了让Ceph更加成熟与完美,这个项目还在继续开发中。

一个Ceph集群由两种类型的后台进程(Daemon)组成:

* OSD Daemon
* Ceph Monitor

## Ceph OSD Daemon
Object Storage Device(OSD)是Ceph集群中的重要组成部分。OSD可以存储文件或数据的内容,它使用文件系统来存储数据。OSD Daemon主要负责管理集群中的所有磁盘。OSD Daemon还负责在本地文件系统存储数据,并为不同的客户软件或存取媒介通过网络提供数据访问。而且,OSD Daemon还负责添加和删除磁盘,磁盘分区,管理OSD、低层空间管理,提供安全措施和磁盘数据的可复制性。
## Ceph Monitor
Ceph Monitor也是一种Ceph OSD Daemon,它主要负责管理全部集群。当你运行一个Ceph集群时,你就会需要Ceph Monitor每天帮你检查集群的健康情况和状态。管理一个集群需要每天做很多工作比如检测所有OSD的状态和文件系统或块数据的状态。你可以通过Ceph Monitor来管理负载均衡和数据响应的详细信息。为了更好的了解Ceph集群的工作原理,我们来看看它是如何处理三种类型数据存储的机制。

Ceph Object storage

当向Ceph写入数据时,Ceph通过内部机制自动跨集群标记和复制数据。Ceph存储对象数据时,不仅可以通过调用Ceph内部的API来实现,还可以通过亚马逊的S3服务或AWS REST提供的API来实现。Ceph块存储机制提供了RADOS(Reliable Autonomic Distributed Object Store)服务。RADOS服务存储机制中不可或缺的;RADOS服务通过使用节点中安装的软件管理工具能够扩展千级的硬件设备(通常被应用为“Nodes“)。

Ceph Block Storage

Ceph的块存储模式使用户可以像挂载一个小型块设备一样挂载Ceph。在块数据存储级别上,RADOS服务也保证块数据的可扩展性。Librados就是包含在这一级别上的一个python类库,你可以使用librados类库和存储服务器或节点进行通信。Librados是一个开源的应用,你可以调整和增强它。Librados通过“RADOS Block Device“即RBD与后台进行交互。RBD不仅继承了Librados的功能,还能够为集群建立快照和恢复数据。

Ceph File Storage

CephFS 是一个为Ceph集群设计的,且遵循POSIX标准的分布式文件系统。CephFS提供把数据目录和文件映射到存储在RADOS中对象的存储的服务。通过这种方式,CephFS和RADOS可以相互协作。在这里,RADOS动态均等地把数据分布到不同的节点上。这种文件系统支持无限的数据存储和更强的数据安全性。在文件存储集群系统中,Ceph因提供容量大和高可扩展性而闻名。请注意你可以同时把Ceph与btrfs或EXT4一起使用,但Red Hat推荐使用最新Linux内核(3.14版本或者更新版本)。
## 结论
Red Hat下的Ceph文件系统拥有性价比高、操作简单、集群数据高可靠性的特点。RedHat也一直为Ceph投入了很多人力,这也确保了Bug可的跟进速度,以及新特性的引入。由于Ceph是开源的,所以你可以按照你的需求随意修改它。

原文链接:Understanding Ceph - An Open Source Distributed Storage Platform(翻译:占帅兵 校对:李颖杰)

===========================

译者介绍

占帅兵,研究生在读(华南师范大学),主要研究方向云计算与大数据处理。曾在公司做过微信公众平台的开发和参与过开发智能综合公交枢纽科研项目。现对PaaS中Docker技术有浓厚的兴趣。
Ceph 是一个符合 POSIX (Portable Operating System for UNIX®)、开源的分布式存储系统,依据 GNU 次通用公共许可而运行。该项目最初由 Sage Weill 于 2007 年开发,该项目的理念是提出一个没有任何单点故障的集群,确保能够跨集群节点进行永久数据复制。