活动预告:Hold 住高并发,唯架构与运维不可辜负

laura 发表了文章 • 0 个评论 • 443 次浏览 • 2015-12-25 12:07 • 来自相关话题

双十一,双十二,
你欢喜清空购物车,我坐等零点秒杀,
他们通宵盯代码,求心理阴影面积…

春节回家抢票,
刚开放购买,立马被抢光,
我们和回家只隔了一张 12306 验证码的距离…

当架构与运维遇上“高并发”,「宜人贷」讲述系统演化,「当当」谈谈交易系统重构上线的经验,「京东」解读京东分布式数据库支撑百亿数据量探索与实践,「数人云」分享使用 Go 开发秒杀系统的实践 ,不只是一次技术交流,他们多年的经验都在这里了,数人云带你一场活动看完所有你关心的“高并发”问题。

分享嘉宾

孙军,宜人贷架构师  
2015 年 5 月加入宜人贷,主要从事宜人贷 P2P 借款与出借业务的架构设计与重构相关工作。10 年的 Java 开发经验,先后在人民银行、1 号店、人人网、当当网从事软件开发与技术架构工作。

王胜军,当当网交易系统开发经理
2014 年 11 月加入当当,主导了整个交易平台重构项目。针对交易系统代码量大、业务逻辑复杂的特点,重构采用了比对、分流等策略,确保切换过程平滑稳定。经过 2015 双 11 和双 12 的考验,从各方面验证了新交易系统的可靠性。

彭安,京东架构师
2014 年加入京东,京东资深开发工程师,从事京东分布式数据库的相关研发工作, 擅长大规模数据,高并发高性能服务器开发以及大型分布式系统设计。喜欢写代码,喜欢读代码,善于将优秀开源项目的经典实现运用到自己的系统中。    

肖德时,数人云 CTO
负责云计算的研发及架构设计工作。关注领域包括 Docker,Mesos 集群, 云计算等领域。 肖德时之前为红帽Engineering Service 部门内部工具组 Team Leader。

议程安排
13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:50  《宜人贷高并发系统演化》孙军 
14:50 - 15:25  《当当交易系统重构上线谈》王胜军
15:25 - 15:40    茶歇
15:40 - 16:15  《京东分布式数据库支撑百亿数据量探索与实践》彭安 
16:15 - 16:50  《使用 Go 开发秒杀系统的实践》肖德时
16:50 以后        自由交流

时间:1月10日 14:00 - 17:00
地点: P2 联合创业办公社 • 北京市海淀区中关村大街11号亿世界财富中心A座B2

数人云是做什么的
数人科技创立于 2014 年,其核心团队来自于 Google、Redhat 和 HP。专注于提供基于分布式和容器技术的 PaaS 服务,帮助用户搭建大规模、高可用、高并发的集群化服务。
旗下产品数人云是国内第一家基于 Mesos 和 Docker 的云操作系统,可以管理公有云和私有云数千节点的集群,部署和管理 Docker、Spark 和用户自行开发的集群化服务。








报名地址:
http://form.mikecrm.com/f.php?t=aebQyy#rd
  查看全部
segmentfault.png

双十一,双十二,
你欢喜清空购物车,我坐等零点秒杀,
他们通宵盯代码,求心理阴影面积…

春节回家抢票,
刚开放购买,立马被抢光,
我们和回家只隔了一张 12306 验证码的距离…

当架构与运维遇上“高并发”,「宜人贷」讲述系统演化,「当当」谈谈交易系统重构上线的经验,「京东」解读京东分布式数据库支撑百亿数据量探索与实践,「数人云」分享使用 Go 开发秒杀系统的实践 ,不只是一次技术交流,他们多年的经验都在这里了,数人云带你一场活动看完所有你关心的“高并发”问题。

分享嘉宾

孙军,宜人贷架构师  
2015 年 5 月加入宜人贷,主要从事宜人贷 P2P 借款与出借业务的架构设计与重构相关工作。10 年的 Java 开发经验,先后在人民银行、1 号店、人人网、当当网从事软件开发与技术架构工作。

王胜军,当当网交易系统开发经理
2014 年 11 月加入当当,主导了整个交易平台重构项目。针对交易系统代码量大、业务逻辑复杂的特点,重构采用了比对、分流等策略,确保切换过程平滑稳定。经过 2015 双 11 和双 12 的考验,从各方面验证了新交易系统的可靠性。

彭安,京东架构师
2014 年加入京东,京东资深开发工程师,从事京东分布式数据库的相关研发工作, 擅长大规模数据,高并发高性能服务器开发以及大型分布式系统设计。喜欢写代码,喜欢读代码,善于将优秀开源项目的经典实现运用到自己的系统中。    

肖德时,数人云 CTO
负责云计算的研发及架构设计工作。关注领域包括 Docker,Mesos 集群, 云计算等领域。 肖德时之前为红帽Engineering Service 部门内部工具组 Team Leader。

议程安排
13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:50  《宜人贷高并发系统演化》孙军 
14:50 - 15:25  《当当交易系统重构上线谈》王胜军
15:25 - 15:40    茶歇
15:40 - 16:15  《京东分布式数据库支撑百亿数据量探索与实践》彭安 
16:15 - 16:50  《使用 Go 开发秒杀系统的实践》肖德时
16:50 以后        自由交流

时间:1月10日 14:00 - 17:00
地点: P2 联合创业办公社 • 北京市海淀区中关村大街11号亿世界财富中心A座B2

数人云是做什么的
数人科技创立于 2014 年,其核心团队来自于 Google、Redhat 和 HP。专注于提供基于分布式和容器技术的 PaaS 服务,帮助用户搭建大规模、高可用、高并发的集群化服务。
旗下产品数人云是国内第一家基于 Mesos 和 Docker 的云操作系统,可以管理公有云和私有云数千节点的集群,部署和管理 Docker、Spark 和用户自行开发的集群化服务。


合作伙伴.png



报名地址:
http://form.mikecrm.com/f.php?t=aebQyy#rd

 

基于Mesos的操作系统之RogerOS

杨y 发表了文章 • 1 个评论 • 629 次浏览 • 2015-12-23 16:38 • 来自相关话题

【编者的话】本篇译文将介绍基于Mesos的RogerOS。其已成为Moz工程技术发展的基础,并将开发人员生产力与资源使用效率提升至新的高度。数人云是国内基于Mesos的云操作系统。在设计思路上,和RogerOS有着异曲同工之妙。同样的思路,解决类似的问题,再次说明Mesos是云操作系统(数据中心操作系统)的内核首选。
 

内容简介

一年之前,我们为Moz Engineering设立了一个新的平台构建项目。项目的目标非常简单——打造下一代平台,将其作为Moz工程技术发展的基础并将开发人员生产力与资源使用效率提升至新的高度。尽管目标如此单纯,但实际操作起来却困难重重。而今天的博文就将向大家展示我们在推进项目开发当中的心路历程。


背景情况

过去十年以来,技术领域的发展变化可谓迅猛且影响深远。软件创新已经成为一股不可回避的浪潮,而且有越来越多行业开始利用软件作为其主要创新实现手段,这意味着软件系统已经在全球经济增速放缓的时代背景下逆流而上、继续保持着可观的发展进度。

计算基础设施在发展速度方面已经将“迅猛”一词作为常态。我们也由以往的内部、专有、耦合、单一性的平台转向开源、分布式且松散耦合性质的新环境。与此同时,世界的发展脚步也可谓一刻不肯停歇。不过相比之下,基础设施系统的更新周期往往无法同这种前进节奏相匹配,这意味着对于大多数企业而言,让新型软件同现有基础设施进行对接已经成为运营工作当中的核心挑战之一。

在Moz公司,我们当然也遇到了同样的难题。对产品核心进行持续创新已经成为我们在Moz的主要任务,而我们的客户也应当能够享受到由此带来的各类成果。不过正如在去年的一篇博文中所提到,我们的现有系统已经处于负载能力的临界点。其带来的最为直观的影响体现在我们的开发速度领域。目前产品的迭代周期变得越来越长,而工程师们则需要耗费更多时间来打理整套系统。另外一些外部问题也开始凸显,这意味着我们获得尝试新鲜技术成果所必需的原始资源开始变得愈发困难。实验是创新的生命基础,而我们也希望能让自己的工程师及产品经理尽可能多地尝试其新鲜想法。由于缺少对资源的支配空间,这就意味着整个团队需要继续“坚守”现有资源——即使其尚未得到充分利用——并在这一有限的范畴之内满足各类潜在的未来需求。

对于我们的技术运维团队而言,这项工作绝不简单。他们需要对数量惊人的各类语言、框架、数据库以及其它种种组件加以支持。从规划的角度来看,来自开发团队的每一项资源请求都会成为运维工作中既有资源使用习惯的恐怖噩梦。举例来讲,某个团队可能需要大量内存与计算核心资源,但却无需使用规模可观的高速磁盘驱动器——这样的要求与传统采购习惯显然完全背离。而且实际情况是,硬件采购是个耗时极长的过程——至少从软件开发周期的角度来衡量是这样。虽然Amazon Web Services等按需平台的出现能够在很大程度上解决此类难题,但着眼于Moz的业务规模,运行自己的硬件体系显然更具成本效益。而从运维工作的角度出发,理想的场景则是将采购划分成数个大规模批次,从而统一硬件规格与具体交货日期。但这种作法显然直接损害了开发人员的实际要求,他们更希望能够以频繁且种类各异的方式在极短的交货周期之内获得自己需要的资源。

另外,与初创企业不同,我们没有那种从零开始的能力或者说可能性空间。任何一套解决方案都必须能够同时应对新型开发项目与传统工作负载,且拥有足以适应Moz未来需求的出色灵活性。


RogerOS

RogerOS正是我们在面对上述问题时给出的答案。这一名称其实是种误读,因为其事实上并不算是真正的操作系统。不过它确实与操作系统存在着一定程度的相似之处。在开发过程当中,我们选择了这个名称并认为其完全能够代表这套平台的特性。开发团队参考了ClusterOS(DCOS)之类的项目。而且与桌面操作系统一样,RogerOS也会对物理硬件进行抽象化处理,并在用户面前体现为一套统一的高级界面——ClusterOS在数据中心或者设备集群当中也扮演着同样的角色,即对集群硬件加以抽象并提供一套特殊的高级界面。这种概念并不是什么新生事物,类似的系统也已经拥有相当长的发展历史。事实上,RogerOS还从谷歌公司的Borg系统当中汲取到了大量设计灵感。

以下几个章节将详细介绍这套系统的具体细节。


设计目标

其实第二篇博文才负责对设计目标的相关细节进行说明,不过幸运的是我们在这里可以先对其加以总结。我们希望能够为开发人员提供一套系统,从而帮助他们:

·在五分钟以内在笔记本设备上实现代码运行或者在数据中心内启动原型设计。

·在一天之内将能够正常运行的原型方案转化为能够接受一定程度外部流量的进阶版本。

·在一周之内将以上进阶版本转化为一套完全成熟的生产系统。

·能够在十分钟之内完成新版本的部署工作。

·不会对系统之上实际运行的具体工作负载类型做出限制,这意味着其能够彻底替代那些只能够承载虚拟机、容器或者批量工作负载的传统系统方案。

·尽可能多的专注于应用程序代码。这套系统应该能够对运行当中的应用程序进行各类必要处理,具体包括负载均衡、监控、日志记录、故障处理以及规模伸缩等等。


设计

RogerOS的核心为Apache Mesos。考虑到既定设计目标以及对该系统的灵活性要求,Mesos可以说是目前惟一合适的可选项目。不过Mesos的核心定位是一套通用型资源调度工具。要想真正实现RogerOS项目的既定目标,我们需要围绕Mesos建立起完整的生态系统。Mesos在以下架构示意图当中对应的是“ClusterOS Kernel”。






上图展示的是完整架构。正如我们提到,从核心角度来看,RogerOS采用Mesos调度机制,但同时又整合进大量协同服务并与之紧密集成。本系列博文的第二篇对这些设计细节做出了进一步说明。


使用体验

通过以上叙述大家应该能够想见,RogerOS是一款非常复杂的系统,而且已经经历了相当长的开发周期。在着手构建之初,我们其实并不太确定选择Mesos作为系统核心是否正确。当时我们已经通过实践证明了Mesos的适用性,不过其在Moz这类混合型环境下的表现却让我们有点担心。不过幸运的是,我们最终还是选择了Mesos,这一决定让我们至今都相当自豪。其不仅实现了既定承诺,还为我们带来更多惊喜。事实上,我们在系统稳定性、可扩展性以及性能表现方面都没有遇到任何问题。另外,Mesos还允许我们利用一小部分开发资源分步实现目标。目前,一套小型设备集群已经足以为Moz运行多种应用程序。关于这方面内容的具体细节,还请大家参阅本系列的第二篇博文。
开发人员对这套系统的反馈也相当积极。Moz Content项目就是从零开始在RogerOS之上打造而成的,开发团队对于这套平台给出了极高评价。具体来讲,通过硬件抽象与高级服务交付,RogerOS能够让开发团队将精力集中在对产品本身的琢磨之上。另外,除了各类新产品之外,相当一部分传统产品也已经能够在这套系统当中成功运行。

总结总体而言,RogerOS已经成为Moz一个极具野心的项目,而且其能够满足很大一部分我们在立项之初为其设定的发展目标。当然,发展完善的道路仍然漫长,但我们对于目前获得的成果感到相当满意!


另外同样重要的是,我们要向各位为当前成果做出贡献的参与者表示感谢:Jord Sonneveld、Manish Ranjan、Amit Bose、Chris Whitten、Josh Gummersal、Evan Battaglia、Tyler Murray以及整个Moz Content团队,谢谢你们!没有你们的参与,RogerOS根本不可能实现如今的成就。


点击可查看英文原文

对RogerOS的详细技术架构感兴趣?关注我们,本周会推出第二篇文章,为您详细介绍RogerOS。 查看全部
编者的话】本篇译文将介绍基于Mesos的RogerOS。其已成为Moz工程技术发展的基础,并将开发人员生产力与资源使用效率提升至新的高度。数人云是国内基于Mesos的云操作系统。在设计思路上,和RogerOS有着异曲同工之妙。同样的思路,解决类似的问题,再次说明Mesos是云操作系统(数据中心操作系统)的内核首选。
 

内容简介

一年之前,我们为Moz Engineering设立了一个新的平台构建项目。项目的目标非常简单——打造下一代平台,将其作为Moz工程技术发展的基础并将开发人员生产力与资源使用效率提升至新的高度。尽管目标如此单纯,但实际操作起来却困难重重。而今天的博文就将向大家展示我们在推进项目开发当中的心路历程。


背景情况

过去十年以来,技术领域的发展变化可谓迅猛且影响深远。软件创新已经成为一股不可回避的浪潮,而且有越来越多行业开始利用软件作为其主要创新实现手段,这意味着软件系统已经在全球经济增速放缓的时代背景下逆流而上、继续保持着可观的发展进度。

计算基础设施在发展速度方面已经将“迅猛”一词作为常态。我们也由以往的内部、专有、耦合、单一性的平台转向开源、分布式且松散耦合性质的新环境。与此同时,世界的发展脚步也可谓一刻不肯停歇。不过相比之下,基础设施系统的更新周期往往无法同这种前进节奏相匹配,这意味着对于大多数企业而言,让新型软件同现有基础设施进行对接已经成为运营工作当中的核心挑战之一。

在Moz公司,我们当然也遇到了同样的难题。对产品核心进行持续创新已经成为我们在Moz的主要任务,而我们的客户也应当能够享受到由此带来的各类成果。不过正如在去年的一篇博文中所提到,我们的现有系统已经处于负载能力的临界点。其带来的最为直观的影响体现在我们的开发速度领域。目前产品的迭代周期变得越来越长,而工程师们则需要耗费更多时间来打理整套系统。另外一些外部问题也开始凸显,这意味着我们获得尝试新鲜技术成果所必需的原始资源开始变得愈发困难。实验是创新的生命基础,而我们也希望能让自己的工程师及产品经理尽可能多地尝试其新鲜想法。由于缺少对资源的支配空间,这就意味着整个团队需要继续“坚守”现有资源——即使其尚未得到充分利用——并在这一有限的范畴之内满足各类潜在的未来需求。

对于我们的技术运维团队而言,这项工作绝不简单。他们需要对数量惊人的各类语言、框架、数据库以及其它种种组件加以支持。从规划的角度来看,来自开发团队的每一项资源请求都会成为运维工作中既有资源使用习惯的恐怖噩梦。举例来讲,某个团队可能需要大量内存与计算核心资源,但却无需使用规模可观的高速磁盘驱动器——这样的要求与传统采购习惯显然完全背离。而且实际情况是,硬件采购是个耗时极长的过程——至少从软件开发周期的角度来衡量是这样。虽然Amazon Web Services等按需平台的出现能够在很大程度上解决此类难题,但着眼于Moz的业务规模,运行自己的硬件体系显然更具成本效益。而从运维工作的角度出发,理想的场景则是将采购划分成数个大规模批次,从而统一硬件规格与具体交货日期。但这种作法显然直接损害了开发人员的实际要求,他们更希望能够以频繁且种类各异的方式在极短的交货周期之内获得自己需要的资源。

另外,与初创企业不同,我们没有那种从零开始的能力或者说可能性空间。任何一套解决方案都必须能够同时应对新型开发项目与传统工作负载,且拥有足以适应Moz未来需求的出色灵活性。


RogerOS

RogerOS正是我们在面对上述问题时给出的答案。这一名称其实是种误读,因为其事实上并不算是真正的操作系统。不过它确实与操作系统存在着一定程度的相似之处。在开发过程当中,我们选择了这个名称并认为其完全能够代表这套平台的特性。开发团队参考了ClusterOS(DCOS)之类的项目。而且与桌面操作系统一样,RogerOS也会对物理硬件进行抽象化处理,并在用户面前体现为一套统一的高级界面——ClusterOS在数据中心或者设备集群当中也扮演着同样的角色,即对集群硬件加以抽象并提供一套特殊的高级界面。这种概念并不是什么新生事物,类似的系统也已经拥有相当长的发展历史。事实上,RogerOS还从谷歌公司的Borg系统当中汲取到了大量设计灵感。

以下几个章节将详细介绍这套系统的具体细节。


设计目标

其实第二篇博文才负责对设计目标的相关细节进行说明,不过幸运的是我们在这里可以先对其加以总结。我们希望能够为开发人员提供一套系统,从而帮助他们:

·在五分钟以内在笔记本设备上实现代码运行或者在数据中心内启动原型设计。

·在一天之内将能够正常运行的原型方案转化为能够接受一定程度外部流量的进阶版本。

·在一周之内将以上进阶版本转化为一套完全成熟的生产系统。

·能够在十分钟之内完成新版本的部署工作。

·不会对系统之上实际运行的具体工作负载类型做出限制,这意味着其能够彻底替代那些只能够承载虚拟机、容器或者批量工作负载的传统系统方案。

·尽可能多的专注于应用程序代码。这套系统应该能够对运行当中的应用程序进行各类必要处理,具体包括负载均衡、监控、日志记录、故障处理以及规模伸缩等等。


设计

RogerOS的核心为Apache Mesos。考虑到既定设计目标以及对该系统的灵活性要求,Mesos可以说是目前惟一合适的可选项目。不过Mesos的核心定位是一套通用型资源调度工具。要想真正实现RogerOS项目的既定目标,我们需要围绕Mesos建立起完整的生态系统。Mesos在以下架构示意图当中对应的是“ClusterOS Kernel”。

翻译第一篇图.jpg


上图展示的是完整架构。正如我们提到,从核心角度来看,RogerOS采用Mesos调度机制,但同时又整合进大量协同服务并与之紧密集成。本系列博文的第二篇对这些设计细节做出了进一步说明。


使用体验

通过以上叙述大家应该能够想见,RogerOS是一款非常复杂的系统,而且已经经历了相当长的开发周期。在着手构建之初,我们其实并不太确定选择Mesos作为系统核心是否正确。当时我们已经通过实践证明了Mesos的适用性,不过其在Moz这类混合型环境下的表现却让我们有点担心。不过幸运的是,我们最终还是选择了Mesos,这一决定让我们至今都相当自豪。其不仅实现了既定承诺,还为我们带来更多惊喜。事实上,我们在系统稳定性、可扩展性以及性能表现方面都没有遇到任何问题。另外,Mesos还允许我们利用一小部分开发资源分步实现目标。目前,一套小型设备集群已经足以为Moz运行多种应用程序。关于这方面内容的具体细节,还请大家参阅本系列的第二篇博文。
开发人员对这套系统的反馈也相当积极。Moz Content项目就是从零开始在RogerOS之上打造而成的,开发团队对于这套平台给出了极高评价。具体来讲,通过硬件抽象与高级服务交付,RogerOS能够让开发团队将精力集中在对产品本身的琢磨之上。另外,除了各类新产品之外,相当一部分传统产品也已经能够在这套系统当中成功运行。

总结总体而言,RogerOS已经成为Moz一个极具野心的项目,而且其能够满足很大一部分我们在立项之初为其设定的发展目标。当然,发展完善的道路仍然漫长,但我们对于目前获得的成果感到相当满意!


另外同样重要的是,我们要向各位为当前成果做出贡献的参与者表示感谢:Jord Sonneveld、Manish Ranjan、Amit Bose、Chris Whitten、Josh Gummersal、Evan Battaglia、Tyler Murray以及整个Moz Content团队,谢谢你们!没有你们的参与,RogerOS根本不可能实现如今的成就。


点击可查看英文原文

对RogerOS的详细技术架构感兴趣?关注我们,本周会推出第二篇文章,为您详细介绍RogerOS。

把LinkedIn 的 “中枢神经系统” Kafka 搬上数人云

dataman 发表了文章 • 0 个评论 • 883 次浏览 • 2015-12-18 16:05 • 来自相关话题

什么是Kafka?

Kafka 是一个使用 Scala 编写的分布式基于发布/订阅的消息系统。它最初由 LinkedIn 公司开发,之后成为 Apache 项目的一部分。 Kafka 是一个分布式的,可划分的,冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。

它的架构包括以下组件:
 
话题(Topic):是特定类型的消息流。消息是字节的有效负载(Payload),话题是消息的分类名或种子(Feed)名。生产者(Producer):是能够发布消息到话题的任何对象。缓存代理(Broker),Kafa集群中的一台或多台服务器统称为broker。消费者(Consumer)可以订阅一个或多个话题,并从Broker拉数据,从而消费这些已发布的消息。







Kafka是LinkedIn的"中枢神经系统"

Kreps 将 Kafka 描述为 LinkedIn 的 “中枢神经系统”,管理从各个应用程序汇聚到此的信息流,这些数据经过处理后再被分发到各处。

LinkedIn在2011年7月开始大规模使用Kafka,当时Kafka每天大约处理10亿条消息,这一数据在2012年达到了每天200亿条,而到了2013年7月,每天处理的消息达到了2000亿条。在几个月前,他们的最新记录是每天利用Kafka处理的消息超过1万亿条,在峰值时每秒钟会发布超过450万条消息,每周处理的信息是1.34 PB。每条消息平均会被4个应用处理。在过去的四年中,实现了1200倍的增长。

Kafka 的常见应用场景

传统的消息

对于一些常规的消息系统,Kafka是个不错的选择;partitons/replication和容错,可以使Kafka具有良好的扩展性和性能优势. LinkedIn就使用Kafka作为传统的消息系统实现标准的队列和消息的发布—订阅,例如搜索和内容提要(Content Feed)。

网站跟踪分析

Kafka可以作为"网站活动跟踪"的最佳工具;可以将网页/用户操作等信息发送到Kafka中.并实时监控,或者进行离线统计分析等。例如,为了更好地理解用户行为,改善用户体验,LinkedIn会将用户查看了哪个页面、点击了哪些内容等信息发送到每个数据中心的Kafka集群上,并通过Hadoop进行分析、生成日常报告。

日志收集

Kafka的特性决定它非常适合作为"日志收集中心";application可以将操作日志"批量""异步"的发送到kafka集群中,而不是保存在本地或者DB中;Kafka可以批量提交消息/压缩消息等,这对producer端而言,几乎感觉不到性能的开支.此时consumer端可以使hadoop等其他系统化的存储和分析系统.

有哪些公司使用了神器Kafka?

一些耳熟能详的公司:LinkedIn, Yahoo!, BOX, Twitter, Paypal, Uber, Airbnb,…… 当然还有数人云:)






下面小编就给大家介绍如何在数人云上部署一套Kafka集群,并通过Kafka_manager web端管理工具来管理Kafka集群。让大家和上面这些公司一样玩转神器Kafka。

如何在数人云部署Kafka集群?

1. 建立集群(应用发布环境)

注册数人云,在数人云上建立一个集群。参考:数人云用户手册-建立集群

2. 发布Kafka应用

2.1 发布 Zookeeper

因为 Kafka 集群需要使用 Zookeeper来保证系统的高可用 ,所以需要先在数人云上发布Zookeeper集群。参考:快速搭建ZooKeeper集群指南

2.2 新建 Kafka 应用

1. 选择"应用管理"中的"新建应用",如图所示:






2. 新建应用
 
填写应用名称: kafka选择集群: your-cluster添加应用镜像地址: testregistry.dataman.io/centos7/jdk7-scala2.11-kafka0.8.22填写镜像版本: 20151201应用模式: HOST模式选择主机:your-app-ip(多选)选择容器规格: CPU:0.1 内存:1024 MB容器个数: your-kafka-number

点选:1容器/主机 <- 每个宿主机只能运行1个 app






添加应用地址:











添加环境变量:











3. 检查应用状态

简单的检查应用占用集群资源的情况,点击应用管理 -> 选择监控的 tab 页






至此,Kafka集群已经建立完毕, 可没有一个web界面来管理?别急,下面我们就开始介绍如何搭建一个基于Web的管理工具Kafka_Manager

Kafka_Manager 简介

Apache Kafka 在 Yahoo 内部已经被很多团队所使用,例如媒体分析团队就将其应用到了实时分析流水线中,同时,Yahoo 整个 Kafka 集群处理的峰值带宽超过了 20Gbps(压缩数据)。为了让开发者和服务工程师能够更加简单地维护 Kafka 集群,Yahoo 构建了一个基于 Web 的管理工具,称为 Kafka Manager,日前该项目已经在GitHub上开源。

3. 发布 Kafka_Manager 应用

因为 KafkaManager 是监控 Kafka 的工具,所以在启动 KafkaManager 前,请先按照上面的说明启动 Kafka。

1. 选择"应用管理"中的"新建应用",如图所示:






2. 新建应用
 
填写应用名称: kafka-manager选择集群: your-cluster添加应用镜像地址: testregistry.dataman.io/centos7/jdk8-kafka-0.8.x-manager填写镜像版本: 20151204应用模式: 网桥模式选择主机:your-app-ip(多选)选择容器规格: CPU:0.1 内存:512 MB容器个数: 1

点选:1容器/主机 <- 每个宿主机只能运行1个 app






添加应用地址:











添加环境变量:











3. 检查应用状态

简单的检查应用占用集群资源的情况,点击应用管理 -> 选择监控的 tab 页






4. 打开 Kafka_Manager 页面

游览器输入你的监控地址域名后,按照你的集群情况添加信息






5. 点击 save 后,就可以打开监控页面

可以看到刚才我们加入的 kafka 集群,数量是3个






现在包含web端管理工具的Kafka集群就搭建完成了,大家可以尽情的玩耍和测试了~ 有任何问题,可以在社区里直接提问哦。 查看全部
什么是Kafka?

Kafka 是一个使用 Scala 编写的分布式基于发布/订阅的消息系统。它最初由 LinkedIn 公司开发,之后成为 Apache 项目的一部分。 Kafka 是一个分布式的,可划分的,冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。

它的架构包括以下组件:
 
  • 话题(Topic):是特定类型的消息流。消息是字节的有效负载(Payload),话题是消息的分类名或种子(Feed)名。
  • 生产者(Producer):是能够发布消息到话题的任何对象。
  • 缓存代理(Broker),Kafa集群中的一台或多台服务器统称为broker。
  • 消费者(Consumer)可以订阅一个或多个话题,并从Broker拉数据,从而消费这些已发布的消息。


20151218kafka1.png



Kafka是LinkedIn的"中枢神经系统"

Kreps 将 Kafka 描述为 LinkedIn 的 “中枢神经系统”,管理从各个应用程序汇聚到此的信息流,这些数据经过处理后再被分发到各处。

LinkedIn在2011年7月开始大规模使用Kafka,当时Kafka每天大约处理10亿条消息,这一数据在2012年达到了每天200亿条,而到了2013年7月,每天处理的消息达到了2000亿条。在几个月前,他们的最新记录是每天利用Kafka处理的消息超过1万亿条,在峰值时每秒钟会发布超过450万条消息,每周处理的信息是1.34 PB。每条消息平均会被4个应用处理。在过去的四年中,实现了1200倍的增长。

Kafka 的常见应用场景

传统的消息

对于一些常规的消息系统,Kafka是个不错的选择;partitons/replication和容错,可以使Kafka具有良好的扩展性和性能优势. LinkedIn就使用Kafka作为传统的消息系统实现标准的队列和消息的发布—订阅,例如搜索和内容提要(Content Feed)。

网站跟踪分析

Kafka可以作为"网站活动跟踪"的最佳工具;可以将网页/用户操作等信息发送到Kafka中.并实时监控,或者进行离线统计分析等。例如,为了更好地理解用户行为,改善用户体验,LinkedIn会将用户查看了哪个页面、点击了哪些内容等信息发送到每个数据中心的Kafka集群上,并通过Hadoop进行分析、生成日常报告。

日志收集

Kafka的特性决定它非常适合作为"日志收集中心";application可以将操作日志"批量""异步"的发送到kafka集群中,而不是保存在本地或者DB中;Kafka可以批量提交消息/压缩消息等,这对producer端而言,几乎感觉不到性能的开支.此时consumer端可以使hadoop等其他系统化的存储和分析系统.

有哪些公司使用了神器Kafka?

一些耳熟能详的公司:LinkedIn, Yahoo!, BOX, Twitter, Paypal, Uber, Airbnb,…… 当然还有数人云:)

20151218kafka0.png


下面小编就给大家介绍如何在数人云上部署一套Kafka集群,并通过Kafka_manager web端管理工具来管理Kafka集群。让大家和上面这些公司一样玩转神器Kafka。

如何在数人云部署Kafka集群?

1. 建立集群(应用发布环境)

注册数人云,在数人云上建立一个集群。参考:数人云用户手册-建立集群

2. 发布Kafka应用

2.1 发布 Zookeeper

因为 Kafka 集群需要使用 Zookeeper来保证系统的高可用 ,所以需要先在数人云上发布Zookeeper集群。参考:快速搭建ZooKeeper集群指南

2.2 新建 Kafka 应用

1. 选择"应用管理"中的"新建应用",如图所示:

20151218kafka2.png


2. 新建应用
 
  • 填写应用名称: kafka
  • 选择集群: your-cluster
  • 添加应用镜像地址: testregistry.dataman.io/centos7/jdk7-scala2.11-kafka0.8.22
  • 填写镜像版本: 20151201
  • 应用模式: HOST模式
  • 选择主机:your-app-ip(多选)
  • 选择容器规格: CPU:0.1 内存:1024 MB
  • 容器个数: your-kafka-number


点选:1容器/主机 <- 每个宿主机只能运行1个 app

20151218kafka3.png


添加应用地址:

20151218kafka4.png


20151218kafka5.png


添加环境变量:

20151218kafka6.png


20151218kafka7.png


3. 检查应用状态

简单的检查应用占用集群资源的情况,点击应用管理 -> 选择监控的 tab 页

20151218kafka8.png


至此,Kafka集群已经建立完毕, 可没有一个web界面来管理?别急,下面我们就开始介绍如何搭建一个基于Web的管理工具Kafka_Manager

Kafka_Manager 简介

Apache Kafka 在 Yahoo 内部已经被很多团队所使用,例如媒体分析团队就将其应用到了实时分析流水线中,同时,Yahoo 整个 Kafka 集群处理的峰值带宽超过了 20Gbps(压缩数据)。为了让开发者和服务工程师能够更加简单地维护 Kafka 集群,Yahoo 构建了一个基于 Web 的管理工具,称为 Kafka Manager,日前该项目已经在GitHub上开源。

3. 发布 Kafka_Manager 应用

因为 KafkaManager 是监控 Kafka 的工具,所以在启动 KafkaManager 前,请先按照上面的说明启动 Kafka。

1. 选择"应用管理"中的"新建应用",如图所示:

20151218kafka9.png


2. 新建应用
 
  • 填写应用名称: kafka-manager
  • 选择集群: your-cluster
  • 添加应用镜像地址: testregistry.dataman.io/centos7/jdk8-kafka-0.8.x-manager
  • 填写镜像版本: 20151204
  • 应用模式: 网桥模式
  • 选择主机:your-app-ip(多选)
  • 选择容器规格: CPU:0.1 内存:512 MB
  • 容器个数: 1


点选:1容器/主机 <- 每个宿主机只能运行1个 app

20151218kafka10.png


添加应用地址:

20151218kafka11.png


20151218kafka12.png


添加环境变量:

20151218kafka13.png


20151218kafka14.png


3. 检查应用状态

简单的检查应用占用集群资源的情况,点击应用管理 -> 选择监控的 tab 页

20151218kafka15.png


4. 打开 Kafka_Manager 页面

游览器输入你的监控地址域名后,按照你的集群情况添加信息

20151218kafka16.png


5. 点击 save 后,就可以打开监控页面

可以看到刚才我们加入的 kafka 集群,数量是3个

20151218kafka17.png


现在包含web端管理工具的Kafka集群就搭建完成了,大家可以尽情的玩耍和测试了~ 有任何问题,可以在社区里直接提问哦。

关于 Mesos,你知道多少?

laura 发表了文章 • 0 个评论 • 1210 次浏览 • 2015-12-16 19:16 • 来自相关话题

听过不少人在讨论 Mesos,然而并不是很明白 Mesos 到底能够解决什么问题,使用场景是怎样的,周伟涛(国内较早一批接触使用 Docker,Mesos 等技术的开发者)用一句话形容它, Mesos 能够管理每台机器的 CPU,内存等资源,让你像操纵单个资源池一样来操纵整个数据中心。

周伟涛,现数人科技(主要产品数人云,基于 Mesos 和 Docker 技术的云操作系统)云平台负责人,曾就职于国际开源解决方案供应商 Red Hat, 红帽认证工程师, Mesos Contributor,高级 Python 开发工程师。 是国内较早一批接触使用Docker,Mesos 等技术的开发者。

Apache Mesos 是一个集群管理器,提供了有效的、跨分布式应用或框架的资源隔离和共享,可以运行 Hadoop、MPI、Hypertable、Spark。

13 个问题带你深入了解  Mesos
(问答来自 OSChina 开源中国社区第 100 期高手问答 —— Apache Mesos)

Q1:对大多数人来说还不知道什么是 Mesos,请介绍下他是干什么的,有什么用,怎么用?
A1:你好, Mesos 在国内的资料目前虽然不多,但是你随便百度,谷歌一下,还是有一些的。这里我想拿一个例子来解释 Mesos,假设某公司需要频繁进行大数据计算,该任务运行时需要 N 多 CPU 和内存,为了满足这个需求,我们有两种思路:

思路一)使用小型机,单机即可为任务提供足够  的资源;

思路二)分布式计算,即提供一批普通配置的机器(计算节点),也就是集群,将计算任务拆分到各机器上计算,然后汇总结果。   

思路二是当前正在流行的做法,这种方式的优点不再多说。为了达到思路二的要求,我们需要建立数据中心(集群)。进一步,为了充分利用数据中心(集群)的资源(譬如为不同的任务分配不同资源,按任务优先级分配资源等),我们就需要一个工具来进行整个数据中心资源的管理、分配等, 这个工具就是 Mesos。 与 Mesos 类似的工具还有 YARN.

除此之外, Mesos 不仅为计算任务 Offer 资源, 它也支持运行长时任务(譬如 Web应用)。目前国外好多互联网公司都在使用 Mesos   来作为它们的集群管理工具,这里是一个 Powered by Mesos list:  https://mesos.apache.org/docum ... esos/

Q2:我们现在用  Cloudera 这套,能简单介绍下 Mesos 和 Cloudera 的差别吗?
A2:Mesos 的主要目标就是去帮助管理不同框架(或者应用栈)间的集群资源。比如说,有一个业务需要在同一个物理集群上同时运行Hadoop,Storm及 Spark。这种情况下,现有的调度器是无法完成跨框架间的如此细粒度的资源共享的。Hadoop 的 YARN 调度器是一个中央调度器,它可以允许多个框架 运行在一个集群里。

但是,要使用框架特定的算法或者调度策略的话就变得很难了,因为多个框架间只有一种调度算法。比如说,MPI 使用的是组调度算法,而 Spark 用的是延迟调度。它们两个同时运行在一个集群上会导致供求关系的冲突。还有一个办法就是将集群物理拆分成多个小的集群,然后将不同的框架独立地 运行在这些小集群上。再有一个方法就是为每个框架分配一组虚拟机。正如Regola 和 Ducom 所说的,虚拟化被认为是一个性能瓶颈,尤其是在高性能计算 (HPC)系统中。这正是 Mesos 适合的场景——它允许用户跨框架来管理集群资源。

Mesos 是一个双层调度器。在第一层中,Mesos 将一定的资源提供(以容器的形式)给对应的框架。框架在第二层接收到资源后,会运行自己的调度算法来 将任务分配到 Mesos 所提供的这些资源上。和 Hadoop  YARN 的这种中央调度器相比,或许它在集群资源使用方面并不是那么高效。但是它带来了灵活性——比如说,多个框架实例可以运行在一个集群里。这是现有的这些调度器都无法实现的。就算是 Hadoop  YARN 也只是尽量争取在同一个集群上支持类似 MPI 这样的第三方框架而已。更重要的是,随着新框架的诞生,比如说 Samza 最近就被 LinkedIn 开源出来了——有了 Mesos 这些新框架可以试验性地部署到现有的集群上,和其它的框架和平共处。

Q3:您好,Mesos 有哪些典型的应用场景?看了一些介绍,说是能做 Docker 的编排服务。与 OpenStack 这样的云平台管理物理机 CPU、内存,Cloudera Manager 管理 Hadoop 集群服务有什么区别?
A3:现在 Mesos 的应用场景非常多,譬如
1)Spark on Mesos (这是标配 )
2)Jenkins on Mesos  
3)Mesos 做 docker 的编排服务等。

与 OpenStack 相比, 首先,物理机,虚拟机都可以作为 Mesos  的集群节点;其次, 粒度不同, Mesos 的基本计算单元是容器(LXC) , 而 OpenStack 的是 VM(听说现在也支持Docker  容器技术了),前者资源利用率更高;最后,轻量级,Mesos 只负责 Offer 资源给Framework,不负责调度资源。 OpenStack 更贴近于 IaaS 层,而 Mesos 在 IaaS 之上。所以有人称其为 DCOS,或者分布式操作系统。

Q4:各方面边界在哪,有什么优劣势,谢谢。
A4:优点   
资源管理策略 Dominant Resource Fairness(DRF),  这是 Mesos 的核心,也是我们把Mesos 比作分布式系统 Kernel 的根本原因。通俗讲,Mesos 能够保证集群内的所有用户有平等的机会使用集群内的资源,这里的资源包括 CPU,内存,磁盘等等。很多人拿 Mesos跟 k8s 相比,我对 k8s 了解不深,但是,我认为这两者侧重点不同不能做比较,k8s 只是负责容器编排而不是集群资源管理。不能因为都可以管理 Docker,我们就把它们混为一谈。

轻量级。相对于 YARN,Mesos只负责 Offer 资源给 Framework,不负责调度资源。这样,理论上,我们可以让各种东西使用 Mesos 集群资源,而不像 YARN 只拘泥于 Hadoop,我们需要做的是开发调度器(Mesos Framework)。                 

提高分布式集群的资源利用率:这是一个 Generic 的优点。从某些方面来说,所有的集群管理工具都是为了提高资源利用率。VM 的出现,催生了 IaaS;容器的出现,催生了 K8s,  Mesos 等等。简单讲,同样多的资源,我们利用 IaaS 把它们拆成 VM 与  利用 K8s/Mesos 把它们拆成容器,显然后者的资源利用率更高。(这里我没有讨论安全的问题,我们假设内部子网环境不需要考虑这个。)                 

缺点   

门槛太高。只部署一套 Mesos,你啥都干不了,为了使用它,你需要不同的 Mesos Framework,像 Marathon,Chronos,Spark 等等。或者自己写 Framework 来调度 Mesos给的资源,这让大家望而却步。                 

目前对 Stateful Service 的支持不够。Mesos 集群目前无法进行数据持久化。0.23 版本增加了 Persistent resource 和 Dynamic reserver,数据持久化问题将得到改善。                 

脏活累活不会少。Team 在使用 Mesos 前期很乐观,认为搞定了 Mesos,我们的运维同学能轻松很多。然而,根本不是那么回事儿,集群节点的优化,磁盘,网络的设置,等等这些,Mesos 是不会帮你干的。使用初期,运维的工作量不仅没有减轻,反而更重了。Mesos 项目还在紧锣密鼓的开发中,很多功能还不完善。

Q5:我想请教下,如果要做一个云服务平台,Mesos 和 Kubernates 怎么去选型
A5:目前的现状是 Mesos 和 K8s 的生态圈各自都发展的比较好,丢弃哪一个都很吃亏。不如按你个人的喜好,先选择一个投下去先用起来。比如数人云,www.shurenyun.com,直接一键部署,这样太方便了。可以快速体验 Mesos 的好处。                                                

这个要看你的具体需求。据我所知, K8s 目前只支持 Docker 而且鲜有生产环境的用例; 而 Mesos 不需要你的应用包到 Docker 里面并且其经历过生产环境的考验。 但是, 反过来, K8s 的社区更加活跃,其正在高速发展中,前景非常好。  当然,上述都不是关键, 一个好用的云平台更多的是要有好的产品理念。 请参考 www.shurenyun.com                       
        
Q6:对于长时间任务,有没有好的调度器算法或者策略
A6:长任务是依靠马拉松 Marathon 框架,对于 Docker,Mesos + Marathon 基本上是现在最成熟的分布式运行框架。长任务是依靠马拉松 Marathon 框架,对于 Docker,Mesos + Marathon 基本上是现在最成熟的分布式运行框架。

Q7:请问下 Mesos 和 Docker 结合,Mesos 只是能解决资源分配问题对么?
A7:对的,Mesos 负责资源分配,需要有个东东负责 Docker 的任务调度,这样就能将 Docker实例自动下发到集群中运行。这个组件叫马拉松 Marathon。Mesos + Marathon 基本上现在最稳定的 Docker 集群化调度框架

Q8:Mesos 现在可以逐渐应用到生产环境了?
A8:Mesos 早就可以应用到生产环境了, 国外的 Airbnb, Apple,  Uber, Twitter,国内的携程,爱奇艺,还有我们公司数人科技都在生产环境使用了 Mesos。 你在这里可以看到使用 Mesos 的列表  https://mesos.apache.org/documentation/latest/powered-by-mesos/

Q9:Mesos 和 Zookeeper 有什么关联吗?
A9:Zookeeper 是一个为分布式应用提供一致性服务的软件, 而 Mesos 是一个分布式应用。所以在生产环境,我们需要使用 Zookeeper 来为 Mesos 提供一致性服务。

Q10:Mesos,Swarm,Kubernetes 之间有没有竞争关系?虽然这三家都说互相支持,但是这样做会不会太啰嗦了?
A10:Swarm 与 K8s 有很多交叉。 Mesos 更多的是 Focus 在资源管理上, 只是恰好可以使用 Container 做资源隔离。竞争与否,还需要看社区的走向吧。

Q11:你好,看了看这个框架想请教几个问题:
        1.这个框架是否自带日志搜集模块?
        2.这个框架能否进行性能统计?
        3.这个框架在某个节点资源耗尽时可否自动切换?如果所有节点资源耗尽是否容易崩溃,自恢复能力如何?
        4.这个框架可否配置负载均衡?
        谢谢:)
A11:
1. 带日志模块,但是功能比较简单,没有一个全局的展示
2. 可以进行性能统计
3. Mesos 是根据当前的集群资源统计来决定给调度器分配多少资源的,资源耗尽只会导致新的应用无法部署,不会影响正在运行的东西。
4. 可以配置负载均衡。 并且 Mesos 本身也有多 Master 机制      

Q12:请问 Mesos 怎样决定分配多少资源?分配的资源什么时候回收?
A12:Mesos 与其它的集群管理工具不同, Mesos 本身不负责分配资源,它只是将当前集群的剩余资源提供给注册到它的调度器,由调度器本身来决定使用多少资源,以及合适释放资源。

Q13:假设集群里有 3 台服务器,每台服务器可用内存 16G,现在调度器要运行一个任务需要24G 内存,那么 Mesos 是把整个集群的 48G 内存当成一个整体来提供,还是会向调度器提供每台服务器剩余的内存
        也就是说下面两种情况哪种才是正确的:
        1、调度器先申请节点1的 16G 内存,再申请节点 2 的 8G 内存,用哪个节点的内存完全由调度器控制
        2、调度器一次过申请 24G 内存,由 Mesos 控制具体是用了哪个节点的内存。有可能是每个节点都分配了 8G;也有可能是一个节点 16G,另一个节点 8G

A13:看过 DPark 实现 Mesos 的调度器。你一个任务需要 24G 内存,这个任务就需要拆分才可以调度起来。每个小任务需要 16G 以下的内存。才能通过调度器,调度到具体服务器。 调度器一般都是把任务调度到文件所在的机器上。由调度器控制使用哪里的资源, Mesos 告诉调度器哪些资源可用。

阅读完这 13 个问答,希望可以让你对 Mesos 的认识更深,并用于项目实践,分享更多地经验给 Mesos 爱好者 :)
                                            查看全部
关于mesos你知道多少.png

听过不少人在讨论 Mesos,然而并不是很明白 Mesos 到底能够解决什么问题,使用场景是怎样的,周伟涛(国内较早一批接触使用 Docker,Mesos 等技术的开发者)用一句话形容它, Mesos 能够管理每台机器的 CPU,内存等资源,让你像操纵单个资源池一样来操纵整个数据中心。

周伟涛,现数人科技(主要产品数人云,基于 Mesos 和 Docker 技术的云操作系统)云平台负责人,曾就职于国际开源解决方案供应商 Red Hat, 红帽认证工程师, Mesos Contributor,高级 Python 开发工程师。 是国内较早一批接触使用Docker,Mesos 等技术的开发者。

Apache Mesos 是一个集群管理器,提供了有效的、跨分布式应用或框架的资源隔离和共享,可以运行 Hadoop、MPI、Hypertable、Spark。

13 个问题带你深入了解  Mesos
(问答来自 OSChina 开源中国社区第 100 期高手问答 —— Apache Mesos)

Q1:对大多数人来说还不知道什么是 Mesos,请介绍下他是干什么的,有什么用,怎么用?
A1:你好, Mesos 在国内的资料目前虽然不多,但是你随便百度,谷歌一下,还是有一些的。这里我想拿一个例子来解释 Mesos,假设某公司需要频繁进行大数据计算,该任务运行时需要 N 多 CPU 和内存,为了满足这个需求,我们有两种思路:

思路一)使用小型机,单机即可为任务提供足够  的资源;

思路二)分布式计算,即提供一批普通配置的机器(计算节点),也就是集群,将计算任务拆分到各机器上计算,然后汇总结果。   

思路二是当前正在流行的做法,这种方式的优点不再多说。为了达到思路二的要求,我们需要建立数据中心(集群)。进一步,为了充分利用数据中心(集群)的资源(譬如为不同的任务分配不同资源,按任务优先级分配资源等),我们就需要一个工具来进行整个数据中心资源的管理、分配等, 这个工具就是 Mesos。 与 Mesos 类似的工具还有 YARN.

除此之外, Mesos 不仅为计算任务 Offer 资源, 它也支持运行长时任务(譬如 Web应用)。目前国外好多互联网公司都在使用 Mesos   来作为它们的集群管理工具,这里是一个 Powered by Mesos list:  https://mesos.apache.org/docum ... esos/

Q2:我们现在用  Cloudera 这套,能简单介绍下 Mesos 和 Cloudera 的差别吗?
A2:Mesos 的主要目标就是去帮助管理不同框架(或者应用栈)间的集群资源。比如说,有一个业务需要在同一个物理集群上同时运行Hadoop,Storm及 Spark。这种情况下,现有的调度器是无法完成跨框架间的如此细粒度的资源共享的。Hadoop 的 YARN 调度器是一个中央调度器,它可以允许多个框架 运行在一个集群里。

但是,要使用框架特定的算法或者调度策略的话就变得很难了,因为多个框架间只有一种调度算法。比如说,MPI 使用的是组调度算法,而 Spark 用的是延迟调度。它们两个同时运行在一个集群上会导致供求关系的冲突。还有一个办法就是将集群物理拆分成多个小的集群,然后将不同的框架独立地 运行在这些小集群上。再有一个方法就是为每个框架分配一组虚拟机。正如Regola 和 Ducom 所说的,虚拟化被认为是一个性能瓶颈,尤其是在高性能计算 (HPC)系统中。这正是 Mesos 适合的场景——它允许用户跨框架来管理集群资源。

Mesos 是一个双层调度器。在第一层中,Mesos 将一定的资源提供(以容器的形式)给对应的框架。框架在第二层接收到资源后,会运行自己的调度算法来 将任务分配到 Mesos 所提供的这些资源上。和 Hadoop  YARN 的这种中央调度器相比,或许它在集群资源使用方面并不是那么高效。但是它带来了灵活性——比如说,多个框架实例可以运行在一个集群里。这是现有的这些调度器都无法实现的。就算是 Hadoop  YARN 也只是尽量争取在同一个集群上支持类似 MPI 这样的第三方框架而已。更重要的是,随着新框架的诞生,比如说 Samza 最近就被 LinkedIn 开源出来了——有了 Mesos 这些新框架可以试验性地部署到现有的集群上,和其它的框架和平共处。

Q3:您好,Mesos 有哪些典型的应用场景?看了一些介绍,说是能做 Docker 的编排服务。与 OpenStack 这样的云平台管理物理机 CPU、内存,Cloudera Manager 管理 Hadoop 集群服务有什么区别?
A3:现在 Mesos 的应用场景非常多,譬如
1)Spark on Mesos (这是标配 )
2)Jenkins on Mesos  
3)Mesos 做 docker 的编排服务等。

与 OpenStack 相比, 首先,物理机,虚拟机都可以作为 Mesos  的集群节点;其次, 粒度不同, Mesos 的基本计算单元是容器(LXC) , 而 OpenStack 的是 VM(听说现在也支持Docker  容器技术了),前者资源利用率更高;最后,轻量级,Mesos 只负责 Offer 资源给Framework,不负责调度资源。 OpenStack 更贴近于 IaaS 层,而 Mesos 在 IaaS 之上。所以有人称其为 DCOS,或者分布式操作系统。

Q4:各方面边界在哪,有什么优劣势,谢谢。
A4:优点   
资源管理策略 Dominant Resource Fairness(DRF),  这是 Mesos 的核心,也是我们把Mesos 比作分布式系统 Kernel 的根本原因。通俗讲,Mesos 能够保证集群内的所有用户有平等的机会使用集群内的资源,这里的资源包括 CPU,内存,磁盘等等。很多人拿 Mesos跟 k8s 相比,我对 k8s 了解不深,但是,我认为这两者侧重点不同不能做比较,k8s 只是负责容器编排而不是集群资源管理。不能因为都可以管理 Docker,我们就把它们混为一谈。

轻量级。相对于 YARN,Mesos只负责 Offer 资源给 Framework,不负责调度资源。这样,理论上,我们可以让各种东西使用 Mesos 集群资源,而不像 YARN 只拘泥于 Hadoop,我们需要做的是开发调度器(Mesos Framework)。                 

提高分布式集群的资源利用率:这是一个 Generic 的优点。从某些方面来说,所有的集群管理工具都是为了提高资源利用率。VM 的出现,催生了 IaaS;容器的出现,催生了 K8s,  Mesos 等等。简单讲,同样多的资源,我们利用 IaaS 把它们拆成 VM 与  利用 K8s/Mesos 把它们拆成容器,显然后者的资源利用率更高。(这里我没有讨论安全的问题,我们假设内部子网环境不需要考虑这个。)                 

缺点   

门槛太高。只部署一套 Mesos,你啥都干不了,为了使用它,你需要不同的 Mesos Framework,像 Marathon,Chronos,Spark 等等。或者自己写 Framework 来调度 Mesos给的资源,这让大家望而却步。                 

目前对 Stateful Service 的支持不够。Mesos 集群目前无法进行数据持久化。0.23 版本增加了 Persistent resource 和 Dynamic reserver,数据持久化问题将得到改善。                 

脏活累活不会少。Team 在使用 Mesos 前期很乐观,认为搞定了 Mesos,我们的运维同学能轻松很多。然而,根本不是那么回事儿,集群节点的优化,磁盘,网络的设置,等等这些,Mesos 是不会帮你干的。使用初期,运维的工作量不仅没有减轻,反而更重了。Mesos 项目还在紧锣密鼓的开发中,很多功能还不完善。

Q5:我想请教下,如果要做一个云服务平台,Mesos 和 Kubernates 怎么去选型
A5:目前的现状是 Mesos 和 K8s 的生态圈各自都发展的比较好,丢弃哪一个都很吃亏。不如按你个人的喜好,先选择一个投下去先用起来。比如数人云,www.shurenyun.com,直接一键部署,这样太方便了。可以快速体验 Mesos 的好处。                                                

这个要看你的具体需求。据我所知, K8s 目前只支持 Docker 而且鲜有生产环境的用例; 而 Mesos 不需要你的应用包到 Docker 里面并且其经历过生产环境的考验。 但是, 反过来, K8s 的社区更加活跃,其正在高速发展中,前景非常好。  当然,上述都不是关键, 一个好用的云平台更多的是要有好的产品理念。 请参考 www.shurenyun.com                       
        
Q6:对于长时间任务,有没有好的调度器算法或者策略
A6:长任务是依靠马拉松 Marathon 框架,对于 Docker,Mesos + Marathon 基本上是现在最成熟的分布式运行框架。长任务是依靠马拉松 Marathon 框架,对于 Docker,Mesos + Marathon 基本上是现在最成熟的分布式运行框架。

Q7:请问下 Mesos 和 Docker 结合,Mesos 只是能解决资源分配问题对么?
A7:对的,Mesos 负责资源分配,需要有个东东负责 Docker 的任务调度,这样就能将 Docker实例自动下发到集群中运行。这个组件叫马拉松 Marathon。Mesos + Marathon 基本上现在最稳定的 Docker 集群化调度框架

Q8:Mesos 现在可以逐渐应用到生产环境了?
A8:Mesos 早就可以应用到生产环境了, 国外的 Airbnb, Apple,  Uber, Twitter,国内的携程,爱奇艺,还有我们公司数人科技都在生产环境使用了 Mesos。 你在这里可以看到使用 Mesos 的列表  https://mesos.apache.org/documentation/latest/powered-by-mesos/

Q9:Mesos 和 Zookeeper 有什么关联吗?
A9:Zookeeper 是一个为分布式应用提供一致性服务的软件, 而 Mesos 是一个分布式应用。所以在生产环境,我们需要使用 Zookeeper 来为 Mesos 提供一致性服务。

Q10:Mesos,Swarm,Kubernetes 之间有没有竞争关系?虽然这三家都说互相支持,但是这样做会不会太啰嗦了?
A10:Swarm 与 K8s 有很多交叉。 Mesos 更多的是 Focus 在资源管理上, 只是恰好可以使用 Container 做资源隔离。竞争与否,还需要看社区的走向吧。

Q11:你好,看了看这个框架想请教几个问题:
        1.这个框架是否自带日志搜集模块?
        2.这个框架能否进行性能统计?
        3.这个框架在某个节点资源耗尽时可否自动切换?如果所有节点资源耗尽是否容易崩溃,自恢复能力如何?
        4.这个框架可否配置负载均衡?
        谢谢:)

A11:
1. 带日志模块,但是功能比较简单,没有一个全局的展示
2. 可以进行性能统计
3. Mesos 是根据当前的集群资源统计来决定给调度器分配多少资源的,资源耗尽只会导致新的应用无法部署,不会影响正在运行的东西。
4. 可以配置负载均衡。 并且 Mesos 本身也有多 Master 机制      

Q12:请问 Mesos 怎样决定分配多少资源?分配的资源什么时候回收?
A12:Mesos 与其它的集群管理工具不同, Mesos 本身不负责分配资源,它只是将当前集群的剩余资源提供给注册到它的调度器,由调度器本身来决定使用多少资源,以及合适释放资源。

Q13:假设集群里有 3 台服务器,每台服务器可用内存 16G,现在调度器要运行一个任务需要24G 内存,那么 Mesos 是把整个集群的 48G 内存当成一个整体来提供,还是会向调度器提供每台服务器剩余的内存
        也就是说下面两种情况哪种才是正确的:
        1、调度器先申请节点1的 16G 内存,再申请节点 2 的 8G 内存,用哪个节点的内存完全由调度器控制
        2、调度器一次过申请 24G 内存,由 Mesos 控制具体是用了哪个节点的内存。有可能是每个节点都分配了 8G;也有可能是一个节点 16G,另一个节点 8G


A13:看过 DPark 实现 Mesos 的调度器。你一个任务需要 24G 内存,这个任务就需要拆分才可以调度起来。每个小任务需要 16G 以下的内存。才能通过调度器,调度到具体服务器。 调度器一般都是把任务调度到文件所在的机器上。由调度器控制使用哪里的资源, Mesos 告诉调度器哪些资源可用。

阅读完这 13 个问答,希望可以让你对 Mesos 的认识更深,并用于项目实践,分享更多地经验给 Mesos 爱好者 :)
                                           

利用一容器一IP机制在 Mesos中提高网络隔离效果

杨y 发表了文章 • 0 个评论 • 592 次浏览 • 2015-12-15 10:50 • 来自相关话题

【编者的话】曾经听到不少运维管理人员抱怨,Mesos何时可以为同一集群中的每套容器系统提供不同的IP地址?众所周知,在网络架构领域,没有哪种方案能够一劳永逸地适应全部具体场景。然而,Mesos 0.23.0版本中做出大胆实践,首次实现一容器一IP机制支持原生Mesos容器化方案,而且可满足很多特定需求。

Apache Mesos利用Docker以及Linux cgroups等操作系统容器,旨在实现任务与资源隔离。尽管这种解决方案能够在CPU以及内存等本地资源层面提供良好成效,但却无法作为切实可行的跨容器网络资源管理机制发挥作用。有鉴于此,Mesos如今开始为同一集群当中的每套容器系统提供不同的IP地址(即一容器一IP机制),这项特性于Mesos 0.23.0版本中首次出现。

如果没有一容器一IP机制 ......

容器实现方案会共享全部主机IP地址,并因此共享主机端口。
这意味着应用程序会被分配至非标准端口以避免端口冲突状况,最终导致其实际监听的并非已知端口。这就阻碍了其服务发现能力,并使得其它应用程序很难与容器化应用程序进行对接。
网络隔离能力缺失还会给多租户环境带来安全隐患,尤其是在一套 Mesos集群会被多种不同类型的应用程序所共享的情况下。

举例来说,如果某家金融企业同时在单一Mesos集群当中运行风险分析模拟与面向客户的应用程序,那么相关管理人员将很难解决恶意应用意外访问到敏感信息的难题。另外一种风险在于,性能不佳的应用程序有可能拖累整套网络的速度表现,在这种情况下处于同一节点之上的关键性任务应用将有可能得不到充足的资源供给。

最后,每家企业都拥有不同的网络需求。在网络架构领域,没有哪种方案能够一劳永逸地适应全部具体场景。

为了解决上述难题,Mesos社区已经对Mesos项目进行了强化,确保一容器一IP机制能够支持原生Mesos容器化方案(预计未来面向Docker容器的支持能力也将推出)。这套可插拔解决方案还允许Calico、WeaveWorks以及其它一些第三方网络隔离方案供应商的产品以插件形式作用于我们的Mesos集群。

如何实现一容器一IP机制支持原生Mesos容器化方案?






作为Mesos当中的一容器一IP机制,其设计目标之一在于建立一套可插拔架构,允许用户从现有第三方网络供应商处选择解决方案并作为网络实现基础。为了达成这一目标,其中共包含五项关键性组件:
负责为即将启用的容器指定IP要求的框架/调度标签。这是一项可选服务,能够在不带来任何副作用的前提下将一容器一IP能力引入现有框架当中。由一个Mesos master节点与一个Mesos agent节点共同构建的Mesos集群。一套第三方IP地址管理(简称IPAM)服务器,负责根据需要进行IP地址分配,并在IP地址使用完毕后将其回收。第三方网络隔离方案供应程序负责对不同容器系统加以隔离,并允许运维人员通过配置调整其可达性及路由方式。作为轻量级Mesos模块被加载至agent节点当中的网络隔离模块将负责通过调度程序进行任务要求审查,同时利用IP地址管理与网络隔离服务为对应容器提供IP地址。在此之后,其会进一步将IP地址交付至master节点以及框架。

虽然IP分配与网络隔离功能完全可以由单一单元负责实现,不过立足于概念层面,Mesos提供了两项不同的服务方案。其一设想由两家彼此独立的服务供应程序分别提供IP地址管理与网络隔离服务。举例来说,其中之一利用Ubuntu FAN实现IP地址分配,而另一方则利用Calico项目进行网络隔离。

一容器一IP机制的可选属性使得现有框架能够不受影响,这就使集群滚动升级成为了可能。因此,如果用户以混合模式运行多套容器系统——其中一部分采用一容器一IP机制,另一部分则仍按默认方式运行——那么同一集群之内不会出现任何兼容性问题。

一容器一IP服务的出现使得我们能够对网络隔离进行粗粒度与细粒度调整。尽管仍然需要依赖于第三方网络隔离方案供应程序,但如果只是单纯希望以粗粒度方式进行网络隔离设置,那么大家完全可以使用网络路由表。

一容器一IP机制的最佳实践

如果没有一容器一IP机制,那么应用程序必须注册<localhost, port-assignment>以实现发现服务(包括Consul以及Zookeeper等等)。另外,HAProxy或者类似的反向代理机制必须被部署在每一个计算节点当中,从而确保流量由localhost:指向合适的容器端口。

在一容器一IP机制的支持下,当IP地址被分配至容器且网络隔离与路由功能全部到位,那么Mesos master与调度程序将会获取到IP地址的分配信息。在这种情况下,调度程序能够利用容器IP与应用程序相对接。另外,其还可以将这部分信息用于新启动的容器及应用程序。

除此之外,Mesos master还能够通过自身状态端点实现容器IP可用性。这部分信息能够被各DNS服务供应程序所使用,包括Mesos-DNS以及Mesos-Consul,从而实现域名解析。

凭借着一容器一IP地址所带来的诸多助益,每套容器系统都能够拥有与其IP相符合的完整端口区间,而且我们无需再为端口冲突之类的状况而劳心费力。在其帮助下,如今应用程序已经可以监听标准端口,并因此得以在无需反向代理辅助的情况下轻松实现服务发现。

期待为用户带来全新感受

一容器一IP方案允许我们为每套Mesos容器系统分配一个惟一的IP地址。这不仅解决了长久以来困扰着管理人员的端口冲突问题,允许应用程序对已知常用端口进行监听,同时也能够更为轻松地实现服务发现能力。这套可插拔机制允许用户选择并使用自己喜爱的第三方IP地址管理与网络隔离方案,并确保其切实满足自己的特定需求。

有越来越多的朋友体验了Mesos的一容器一 IP 机制所带来的全新网络控制感受。大家也不妨去试试,与我们一起交流分享试用经验。

原文链接:
https://mesosphere.com/blog/20 ... esos/
  查看全部
【编者的话】曾经听到不少运维管理人员抱怨,Mesos何时可以为同一集群中的每套容器系统提供不同的IP地址?众所周知,在网络架构领域,没有哪种方案能够一劳永逸地适应全部具体场景。然而,Mesos 0.23.0版本中做出大胆实践,首次实现一容器一IP机制支持原生Mesos容器化方案,而且可满足很多特定需求。

Apache Mesos利用Docker以及Linux cgroups等操作系统容器,旨在实现任务与资源隔离。尽管这种解决方案能够在CPU以及内存等本地资源层面提供良好成效,但却无法作为切实可行的跨容器网络资源管理机制发挥作用。有鉴于此,Mesos如今开始为同一集群当中的每套容器系统提供不同的IP地址(即一容器一IP机制),这项特性于Mesos 0.23.0版本中首次出现。

如果没有一容器一IP机制 ......

容器实现方案会共享全部主机IP地址,并因此共享主机端口。
这意味着应用程序会被分配至非标准端口以避免端口冲突状况,最终导致其实际监听的并非已知端口。这就阻碍了其服务发现能力,并使得其它应用程序很难与容器化应用程序进行对接。
网络隔离能力缺失还会给多租户环境带来安全隐患,尤其是在一套 Mesos集群会被多种不同类型的应用程序所共享的情况下。

举例来说,如果某家金融企业同时在单一Mesos集群当中运行风险分析模拟与面向客户的应用程序,那么相关管理人员将很难解决恶意应用意外访问到敏感信息的难题。另外一种风险在于,性能不佳的应用程序有可能拖累整套网络的速度表现,在这种情况下处于同一节点之上的关键性任务应用将有可能得不到充足的资源供给。

最后,每家企业都拥有不同的网络需求。在网络架构领域,没有哪种方案能够一劳永逸地适应全部具体场景。

为了解决上述难题,Mesos社区已经对Mesos项目进行了强化,确保一容器一IP机制能够支持原生Mesos容器化方案(预计未来面向Docker容器的支持能力也将推出)。这套可插拔解决方案还允许Calico、WeaveWorks以及其它一些第三方网络隔离方案供应商的产品以插件形式作用于我们的Mesos集群。

如何实现一容器一IP机制支持原生Mesos容器化方案?

图片5.png


作为Mesos当中的一容器一IP机制,其设计目标之一在于建立一套可插拔架构,允许用户从现有第三方网络供应商处选择解决方案并作为网络实现基础。为了达成这一目标,其中共包含五项关键性组件:
  1. 负责为即将启用的容器指定IP要求的框架/调度标签。这是一项可选服务,能够在不带来任何副作用的前提下将一容器一IP能力引入现有框架当中。
  2. 由一个Mesos master节点与一个Mesos agent节点共同构建的Mesos集群。
  3. 一套第三方IP地址管理(简称IPAM)服务器,负责根据需要进行IP地址分配,并在IP地址使用完毕后将其回收。
  4. 第三方网络隔离方案供应程序负责对不同容器系统加以隔离,并允许运维人员通过配置调整其可达性及路由方式。
  5. 作为轻量级Mesos模块被加载至agent节点当中的网络隔离模块将负责通过调度程序进行任务要求审查,同时利用IP地址管理与网络隔离服务为对应容器提供IP地址。在此之后,其会进一步将IP地址交付至master节点以及框架。


虽然IP分配与网络隔离功能完全可以由单一单元负责实现,不过立足于概念层面,Mesos提供了两项不同的服务方案。其一设想由两家彼此独立的服务供应程序分别提供IP地址管理与网络隔离服务。举例来说,其中之一利用Ubuntu FAN实现IP地址分配,而另一方则利用Calico项目进行网络隔离。

一容器一IP机制的可选属性使得现有框架能够不受影响,这就使集群滚动升级成为了可能。因此,如果用户以混合模式运行多套容器系统——其中一部分采用一容器一IP机制,另一部分则仍按默认方式运行——那么同一集群之内不会出现任何兼容性问题。

一容器一IP服务的出现使得我们能够对网络隔离进行粗粒度与细粒度调整。尽管仍然需要依赖于第三方网络隔离方案供应程序,但如果只是单纯希望以粗粒度方式进行网络隔离设置,那么大家完全可以使用网络路由表。

一容器一IP机制的最佳实践

如果没有一容器一IP机制,那么应用程序必须注册<localhost, port-assignment>以实现发现服务(包括Consul以及Zookeeper等等)。另外,HAProxy或者类似的反向代理机制必须被部署在每一个计算节点当中,从而确保流量由localhost:指向合适的容器端口。

在一容器一IP机制的支持下,当IP地址被分配至容器且网络隔离与路由功能全部到位,那么Mesos master与调度程序将会获取到IP地址的分配信息。在这种情况下,调度程序能够利用容器IP与应用程序相对接。另外,其还可以将这部分信息用于新启动的容器及应用程序。

除此之外,Mesos master还能够通过自身状态端点实现容器IP可用性。这部分信息能够被各DNS服务供应程序所使用,包括Mesos-DNS以及Mesos-Consul,从而实现域名解析。

凭借着一容器一IP地址所带来的诸多助益,每套容器系统都能够拥有与其IP相符合的完整端口区间,而且我们无需再为端口冲突之类的状况而劳心费力。在其帮助下,如今应用程序已经可以监听标准端口,并因此得以在无需反向代理辅助的情况下轻松实现服务发现。

期待为用户带来全新感受

一容器一IP方案允许我们为每套Mesos容器系统分配一个惟一的IP地址。这不仅解决了长久以来困扰着管理人员的端口冲突问题,允许应用程序对已知常用端口进行监听,同时也能够更为轻松地实现服务发现能力。这套可插拔机制允许用户选择并使用自己喜爱的第三方IP地址管理与网络隔离方案,并确保其切实满足自己的特定需求。

有越来越多的朋友体验了Mesos的一容器一 IP 机制所带来的全新网络控制感受。大家也不妨去试试,与我们一起交流分享试用经验。

原文链接:
https://mesosphere.com/blog/20 ... esos/
 

利用数据中心操作系统三天内搭建分布式应用:芝加哥犯罪地图

杨y 发表了文章 • 0 个评论 • 513 次浏览 • 2015-12-09 13:33 • 来自相关话题

【编者的话】技术在不断进步,优秀的组件和开源技术也越来越多,这让搭建一个分布式应用变得日益复杂。比如下文中所说的搭建一个crime-map应用,如果从0开始进行安装配置,并最终开发完成,可能需要几周甚至更长的时间。但如果使用数据中心操作系统(DCOS),则能大大简化应用后台的搭建工作,让整个应用开发周期减少到3天。一键部署分布式应用,让用户像使用单机电脑一样管理集群和云端应用,正是数人云所要做的。

利用数据中心操作系统(即Datacenter Operating System,简称DCOS)的帮助,在几天之内开发并部署一款出色且能够用于生产事务的分布式应用程序已经成为可能。我们在最近的一次公司异地会议上,已经切实证明了这一点——在短短三天之内,一款以DCOS、Marathon、Kubernetes、Kafka、Spark以及InfluxDB等组件作为后端的crime-map应用已然正式上线。

如果没有DCOS的帮助,同样的时间周期恐怕只能够让开发人员完成各独立组件的安装与配置工作——而我们,已经构建起了完整的项目成果。

任务目标
Mesosphere公司最近刚刚在墨西哥召开了一次异地会议。作为Hackathon的一部分,我的团队决定利用真实世界中的犯罪数据构建一套DCOS应用演示。犯罪数据——我们所使用的是由芝加哥市政方面提供的公开数据——能够帮助我们了解多方面细节信息,包括房地产规划到警力调遣等等。很明显,以在线(目前正值犯罪活动的高发期)乃至离线方式访问这些数据能够产生可观的实际价值(从历史角度讲,芝加哥一直是犯罪活动的高发地带)。

参与此次演示方案开发的团队成员依次为Michael Gummelt、Tobi Knaup、Stefan Schimanski、James DeFelice和我自己。我们有三天时间来完成该项目构建,从架构设计到实现再到说明文档编写全部囊括于其中。而且在着手工作之初,我们没有任何现成的代码库可供使用——换言之,我们需要白手起家从零开始。

不过凭借着DCOS在快速迭代与架构模块化方面的出色特性,我们得以及时完成这套演示方案的构建,甚至还能够抽出点时间享受墨西哥那温暖而明媚的日光。

下面来看我们开发出的具体架构:






基本目标是尽可能多地演示并运用一些比较好实践,具体包括:

  ·使用mhausenblas/tsdemo-s3-fetcher等定制化Docker镜像,从而演示如何在DCOS当中轻松实现有效的持续集成/技术交付能力。
  ·通过使用Kubernetes,我们展示了如何在单一pod之内实现Web应用程序交付与S3数据提取机制,外加这种方式在数据存储位置方面带来的优势。
  ·通过使用Kubernetes当中的各种隐私保护能力,我们演示了如何在Secret模式下回避AWS的凭证验证机制。
  ·通过使用Kafka实现在线与离线功能部分,我们展示了如何轻松通过单一可靠数据源对接多种不同工作负载。

总结出的经验
Spark数据流处理技术在我们的实践当中虽然出现了小小的问题,但总体来讲进展顺利,其具体任务包括通过HTTP API将提取到的数据导入InfluxDB以及处理JSON序列化等问题。我们的实现方案——其在线处理部分要求将输出结果导入InfluxDB,而离线处理部分则要求将结果写入至预定义的S3存储桶,且这两部分共同作为单一Spark数据流应用的构成要素——在实践角度看效果并不太好。但之所以出现这样的状况,是因为本次黑客马拉松预设的时间周期太过紧张,如果拥有更为宽裕的可支配时间,相信结果会更加令人满意。

在我们的演示当中,AWS S3扮演着Spark数据流处理与离线报告Web应用之间的对接桥梁。这项服务易于上手且能够被轻松用于为消费型下游Web应用交付数据供应。

我们在使用Kubernetes的过程当中遇到了几项bug(我们利用Kbernetes实现应用项目的离线处理部分),而且具体来讲它们都属于“核心”bug。是的,这些bug完全由Kubernetes自身所产生,与我们在DCOS当中所采取的Kubernetes具体设置方式没有任何关系:

  ·在imagePullPolicy当中存在着与imagePullPolicy相关的已知问题:其始终无法对镜像进行重新提取。
  ·在emptyDirectory mounts当中存在着与 root相关的已知问题,root及其权限被设定为750(详见 k8s-offlinereporting-rc.yaml)。
  ·目前尚无法通过环境变量进行secret设定,因此我们采用了Kubernetes Secrets(具体细节详见install offline reporting Web UI)。
  ·如果pod当中的某一容器运行状态不稳定,则该端点及其相关服务将无法正常起效。举例来说,如果某种情况下来自S3的Docker镜像中包含错误命令,则使用此pod的服务将处于不可用状态。

实践经验总结
在这三天当中,我们完成了整套代码库的构建,并以端到端方式对分布式应用程序成果进行了测试与部署。在DCOS的帮助下,我们得以轻松实现该应用程序当中的无状态部分以及核心数据通道。尽管我们发现了一些仍能进一步改善的地方,例如利用Cassandra+KairosDB取代InfluxDB,但总体而言我们对于自己的工作成果仍然感到相当满意。

原文链接:https://mesosphere.com/blog/2015/11/18/dcos-time-series-demo/ 
 
想在国内找到类似好用的数据中心操作系统?  试用数人云>> 查看全部
【编者的话】技术在不断进步,优秀的组件和开源技术也越来越多,这让搭建一个分布式应用变得日益复杂。比如下文中所说的搭建一个crime-map应用,如果从0开始进行安装配置,并最终开发完成,可能需要几周甚至更长的时间。但如果使用数据中心操作系统(DCOS),则能大大简化应用后台的搭建工作,让整个应用开发周期减少到3天。一键部署分布式应用,让用户像使用单机电脑一样管理集群和云端应用,正是数人云所要做的。

利用数据中心操作系统(即Datacenter Operating System,简称DCOS)的帮助,在几天之内开发并部署一款出色且能够用于生产事务的分布式应用程序已经成为可能。我们在最近的一次公司异地会议上,已经切实证明了这一点——在短短三天之内,一款以DCOS、Marathon、Kubernetes、Kafka、Spark以及InfluxDB等组件作为后端的crime-map应用已然正式上线。

如果没有DCOS的帮助,同样的时间周期恐怕只能够让开发人员完成各独立组件的安装与配置工作——而我们,已经构建起了完整的项目成果。

任务目标
Mesosphere公司最近刚刚在墨西哥召开了一次异地会议。作为Hackathon的一部分,我的团队决定利用真实世界中的犯罪数据构建一套DCOS应用演示。犯罪数据——我们所使用的是由芝加哥市政方面提供的公开数据——能够帮助我们了解多方面细节信息,包括房地产规划到警力调遣等等。很明显,以在线(目前正值犯罪活动的高发期)乃至离线方式访问这些数据能够产生可观的实际价值(从历史角度讲,芝加哥一直是犯罪活动的高发地带)。

参与此次演示方案开发的团队成员依次为Michael Gummelt、Tobi Knaup、Stefan Schimanski、James DeFelice和我自己。我们有三天时间来完成该项目构建,从架构设计到实现再到说明文档编写全部囊括于其中。而且在着手工作之初,我们没有任何现成的代码库可供使用——换言之,我们需要白手起家从零开始。

不过凭借着DCOS在快速迭代与架构模块化方面的出色特性,我们得以及时完成这套演示方案的构建,甚至还能够抽出点时间享受墨西哥那温暖而明媚的日光。

下面来看我们开发出的具体架构:

架构图.png


基本目标是尽可能多地演示并运用一些比较好实践,具体包括:

  ·使用mhausenblas/tsdemo-s3-fetcher等定制化Docker镜像,从而演示如何在DCOS当中轻松实现有效的持续集成/技术交付能力。
  ·通过使用Kubernetes,我们展示了如何在单一pod之内实现Web应用程序交付与S3数据提取机制,外加这种方式在数据存储位置方面带来的优势。
  ·通过使用Kubernetes当中的各种隐私保护能力,我们演示了如何在Secret模式下回避AWS的凭证验证机制。
  ·通过使用Kafka实现在线与离线功能部分,我们展示了如何轻松通过单一可靠数据源对接多种不同工作负载。

总结出的经验
Spark数据流处理技术在我们的实践当中虽然出现了小小的问题,但总体来讲进展顺利,其具体任务包括通过HTTP API将提取到的数据导入InfluxDB以及处理JSON序列化等问题。我们的实现方案——其在线处理部分要求将输出结果导入InfluxDB,而离线处理部分则要求将结果写入至预定义的S3存储桶,且这两部分共同作为单一Spark数据流应用的构成要素——在实践角度看效果并不太好。但之所以出现这样的状况,是因为本次黑客马拉松预设的时间周期太过紧张,如果拥有更为宽裕的可支配时间,相信结果会更加令人满意。

在我们的演示当中,AWS S3扮演着Spark数据流处理与离线报告Web应用之间的对接桥梁。这项服务易于上手且能够被轻松用于为消费型下游Web应用交付数据供应。

我们在使用Kubernetes的过程当中遇到了几项bug(我们利用Kbernetes实现应用项目的离线处理部分),而且具体来讲它们都属于“核心”bug。是的,这些bug完全由Kubernetes自身所产生,与我们在DCOS当中所采取的Kubernetes具体设置方式没有任何关系:

  ·在imagePullPolicy当中存在着与imagePullPolicy相关的已知问题:其始终无法对镜像进行重新提取。
  ·在emptyDirectory mounts当中存在着与 root相关的已知问题,root及其权限被设定为750(详见 k8s-offlinereporting-rc.yaml)。
  ·目前尚无法通过环境变量进行secret设定,因此我们采用了Kubernetes Secrets(具体细节详见install offline reporting Web UI)。
  ·如果pod当中的某一容器运行状态不稳定,则该端点及其相关服务将无法正常起效。举例来说,如果某种情况下来自S3的Docker镜像中包含错误命令,则使用此pod的服务将处于不可用状态。

实践经验总结
在这三天当中,我们完成了整套代码库的构建,并以端到端方式对分布式应用程序成果进行了测试与部署。在DCOS的帮助下,我们得以轻松实现该应用程序当中的无状态部分以及核心数据通道。尽管我们发现了一些仍能进一步改善的地方,例如利用Cassandra+KairosDB取代InfluxDB,但总体而言我们对于自己的工作成果仍然感到相当满意。

原文链接:https://mesosphere.com/blog/2015/11/18/dcos-time-series-demo/ 
 
想在国内找到类似好用的数据中心操作系统?  试用数人云>>

OneSQL 入驻数人云

杨y 发表了文章 • 0 个评论 • 653 次浏览 • 2015-12-07 15:27 • 来自相关话题

 OneSQL 是一款以 MySQL / PostgreSQL 为基础,融合了超过十年的互联网运维、数据、应用三个层面的架构经验,为电子商务、互联网金融等重要场景进行深层定制的数据库版本,作为真正的 Web Scale SQL,可让 MySQL 在高压情况下始终保持平稳的处理能力,DBA 可在秒杀类场景的瞬间流量下保持淡定,在16颗 Interl E5-2680 CPU 的 PC 上测试简单的 Select,可以压测到每秒36万 QPS。
OneSQL 的特点在于由互联网行业(如电商、互联网金融等)工作超过十年的资深架构师精心打造,针对高并发、秒杀、关键数据保护等场景进行深入研究和定制,将原本在应用层实现的数据库保护方案下移到 MySQL 的 Server 层,降低了对上层应用开发的要求,使任何公司都可以轻松地拥有与大型互联网企业一样专业数据库技术服务能力,这才是 OneSQL 版本的关键价值所在。

现在,OneSQL 已经入驻数人云,一起来体验一下吧!

第一步 制作镜像

首先,我们需要在 Docker 环境下制作 OneSQL 的 Docker image,并推送至可访问的 Docker Registry。

· 编写如下配置文件:

config_mysql.sh 
__mysql_config() {
# Hack to get MySQL up and running... I need to look into it more.
echo "Running the mysql_config function."
cp /etc/onesql/my.cnf /data/onesql/data/
/usr/local/onesql/scripts/mysql_install_db --defaults-file=/data/onesql/ data/my.cnf --basedir=/usr/local/onesql/ --user=root
touch /data/onesql/data/mysql_install_db_success
/usr/local/onesql/bin/mysqld_safe --defaults-file=/data/onesql/data/my.cnf --basedir=/usr/local/onesql/ --user=root --socket=/tmp/mysql3306.sock &
sleep 10
}
__start_mysql() {
echo "Running the start_mysql function."
/usr/local/onesql/bin/mysqladmin --socket=/tmp/mysql3306.sock -u root password mysqlPassword
/usr/local/onesql/bin/mysql --socket=/tmp/mysql3306.sock -uroot - pmysqlPassword -e "CREATE DATABASE testdb"
/usr/local/onesql/bin/mysql --socket=/tmp/mysql3306.sock -uroot - pmysqlPassword -e "GRANT ALL PRIVILEGES ON testdb.* TO 'testdb'@'localhost' IDENTIFIED BY 'mysqlPassword'; FLUSH PRIVILEGES;"
/usr/local/onesql/bin/mysql --socket=/tmp/mysql3306.sock -uroot - pmysqlPassword -e "GRANT ALL PRIVILEGES ON *.* TO 'testdb'@'%' IDENTIFIED BY 'mysqlPassword' WITH GRANT OPTION; FLUSH PRIVILEGES;"
/usr/local/onesql/bin/mysql --socket=/tmp/mysql3306.sock -uroot - pmysqlPassword -e "GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'mysqlPassword' WITH GRANT OPTION; FLUSH PRIVILEGES;"
/usr/local/onesql/bin/mysql --socket=/tmp/mysql3306.sock -uroot - pmysqlPassword -e "select user, host FROM mysql.user;"
killall mysqld
sleep 10
}
# Call all functions
if [ ! -e /data/onesql/data/mysql_install_db_success ]
then
__mysql_config
__start_mysql
fi
initDB.sh
#!/bin/bash
sh /config_mysql.sh
my.cnf
[mysqld]
tcc_control_min_connections=32
datadir =/data/onesql/data/
basedir =/usr/local/onesql/
port = 3306
binlog_format=row
max_connections=4096
log_bin=/data/onesql/data/92bin
innodb_data_file_path=ibdata1:12M:autoextend
skip_name_resolve
innodb_log_file_size=1g
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
socket=/tmp/mysql3306.sock
[mysql]
socket=/tmp/mysql3306.sock
[mysqld_safe]
run.shsh initDB.sh /usr/local/onesql/bin/mysqld_safe --defaults-file=/data/onesql/data/my.cnf --datadir=/data/onesql/data/ --user=root --socket=/tmp/mysql3306.sock
· 编写 Dockerfile:FROM centos:centos6 MAINTAINER The CentOS Project <cloud-ops@centos.org> RUN yum -y update RUN yum clean all RUN yum -y install wget RUN yum -y install tar RUN yum -y install perl RUN yum -y update; yum clean all RUN yum -y install epel-release; yum clean all RUN yum -y install pwgen supervisor bash-completion psmisc net-tools; yum clean all RUN wget -P /opt http://www.onexsoft.cn/softwar ... ar.gz RUN cd /opt && tar zxvf onesql-5.6.27-all-rhel6-linux64.tar.gz -C /usr/local/ RUN ln -s /usr/local/onesql5627 /usr/local/onesql RUN mkdir -p /etc/onesql RUN mkdir -p /data/onesql/data RUN mkdir -p /data/onesql/data/92bin ADD my.cnf /etc/onesql/my.cnf ADD ./run.sh /run.sh ADD ./config_mysql.sh /config_mysql.sh ADD ./supervisord.conf /etc/supervisord.conf ADD ./initDB.sh /initDB.sh
· 创建 Docker image:docker build -t DockerRegistryPath/onesql-server:2.6.17
第二步 建立集群

请参见 创建/删除集群 来创建您的集群。

创建集群的实例可以参考第一个应用-2048。

注意:如果您需要从集群外部来访问服务,则需要配置外网 IP 或可访问域名,集群中要配置外部网关和内部代理,以便对外进行服务暴露。

第三步 发布应用

接下来,通过数人云创建应用。

1、新建 onesql 应用:
   ·填写应用名称:onesql
   ·选择集群:your-cluster
   ·添加应用镜像地址:DockerRegistryPath/onesql-server
   ·填写镜像版本:2.6.17 
   ·选择应用类型:有状态应用
   ·添加目录:主机目录:/var/lib/onesql,容器目录:/data/onesql/data
   ·选择容器规格: CPU:0.5 内存:512 MB
   ·容器个数:1
   ·高级设置:
   ·填写应用地址: 端口:3306,类型:对内 TCP,映射端口:3306

主机目录与步骤1中创建的目录保持一致,容器目录与 my.cnf 配置文件中的 datadir字段保持一致。

2、新建 wordpress 应用:
   ·填写应用名称:wordpress
   ·选择集群:your-cluster
   ·添加应用镜像地址:wordpress
   ·填写镜像版本:latest
   ·选择应用类型:无状态应用
   ·选择容器规格: CPU:0.5 内存:512 MB
   ·容器个数:1
   ·高级设置:
   ·填写应用地址: 端口:80,类型:对外 HTTP, 域名:your-website
     参数:WORDPRESS_DB_HOST=proxy-ip:3306
WORDPRESS_DB_USER=root
WORDPRESS_DB_PASSWORD=mysqlPassword
等待应用部署完成,访问 wordpress 地址,可以看到如下界面:






恭喜,现在你的 OneSQL 已经正常运作了! 查看全部
新首图.png


 OneSQL 是一款以 MySQL / PostgreSQL 为基础,融合了超过十年的互联网运维、数据、应用三个层面的架构经验,为电子商务、互联网金融等重要场景进行深层定制的数据库版本,作为真正的 Web Scale SQL,可让 MySQL 在高压情况下始终保持平稳的处理能力,DBA 可在秒杀类场景的瞬间流量下保持淡定,在16颗 Interl E5-2680 CPU 的 PC 上测试简单的 Select,可以压测到每秒36万 QPS。
OneSQL 的特点在于由互联网行业(如电商、互联网金融等)工作超过十年的资深架构师精心打造,针对高并发、秒杀、关键数据保护等场景进行深入研究和定制,将原本在应用层实现的数据库保护方案下移到 MySQL 的 Server 层,降低了对上层应用开发的要求,使任何公司都可以轻松地拥有与大型互联网企业一样专业数据库技术服务能力,这才是 OneSQL 版本的关键价值所在。

现在,OneSQL 已经入驻数人云,一起来体验一下吧!

第一步 制作镜像

首先,我们需要在 Docker 环境下制作 OneSQL 的 Docker image,并推送至可访问的 Docker Registry。

· 编写如下配置文件:

config_mysql.sh 
__mysql_config() {
# Hack to get MySQL up and running... I need to look into it more.
echo "Running the mysql_config function."
cp /etc/onesql/my.cnf /data/onesql/data/
/usr/local/onesql/scripts/mysql_install_db --defaults-file=/data/onesql/ data/my.cnf --basedir=/usr/local/onesql/ --user=root
touch /data/onesql/data/mysql_install_db_success
/usr/local/onesql/bin/mysqld_safe --defaults-file=/data/onesql/data/my.cnf --basedir=/usr/local/onesql/ --user=root --socket=/tmp/mysql3306.sock &
sleep 10
}
__start_mysql() {
echo "Running the start_mysql function."
/usr/local/onesql/bin/mysqladmin --socket=/tmp/mysql3306.sock -u root password mysqlPassword
/usr/local/onesql/bin/mysql --socket=/tmp/mysql3306.sock -uroot - pmysqlPassword -e "CREATE DATABASE testdb"
/usr/local/onesql/bin/mysql --socket=/tmp/mysql3306.sock -uroot - pmysqlPassword -e "GRANT ALL PRIVILEGES ON testdb.* TO 'testdb'@'localhost' IDENTIFIED BY 'mysqlPassword'; FLUSH PRIVILEGES;"
/usr/local/onesql/bin/mysql --socket=/tmp/mysql3306.sock -uroot - pmysqlPassword -e "GRANT ALL PRIVILEGES ON *.* TO 'testdb'@'%' IDENTIFIED BY 'mysqlPassword' WITH GRANT OPTION; FLUSH PRIVILEGES;"
/usr/local/onesql/bin/mysql --socket=/tmp/mysql3306.sock -uroot - pmysqlPassword -e "GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'mysqlPassword' WITH GRANT OPTION; FLUSH PRIVILEGES;"
/usr/local/onesql/bin/mysql --socket=/tmp/mysql3306.sock -uroot - pmysqlPassword -e "select user, host FROM mysql.user;"
killall mysqld
sleep 10
}
# Call all functions
if [ ! -e /data/onesql/data/mysql_install_db_success ]
then
__mysql_config
__start_mysql
fi

initDB.sh
#!/bin/bash
sh /config_mysql.sh

my.cnf
[mysqld]
tcc_control_min_connections=32
datadir =/data/onesql/data/
basedir =/usr/local/onesql/
port = 3306
binlog_format=row
max_connections=4096
log_bin=/data/onesql/data/92bin
innodb_data_file_path=ibdata1:12M:autoextend
skip_name_resolve
innodb_log_file_size=1g
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
socket=/tmp/mysql3306.sock
[mysql]
socket=/tmp/mysql3306.sock
[mysqld_safe]

run.sh
sh initDB.sh /usr/local/onesql/bin/mysqld_safe --defaults-file=/data/onesql/data/my.cnf --datadir=/data/onesql/data/ --user=root --socket=/tmp/mysql3306.sock

· 编写 Dockerfile:
FROM centos:centos6 MAINTAINER The CentOS Project <cloud-ops@centos.org> RUN yum -y update RUN yum clean all RUN yum -y install wget RUN yum -y install tar RUN yum -y install perl RUN yum -y update; yum clean all RUN yum -y install epel-release; yum clean all RUN yum -y install pwgen supervisor bash-completion psmisc net-tools; yum clean all RUN wget -P /opt http://www.onexsoft.cn/softwar ... ar.gz RUN cd /opt && tar zxvf onesql-5.6.27-all-rhel6-linux64.tar.gz -C /usr/local/ RUN ln -s /usr/local/onesql5627 /usr/local/onesql RUN mkdir -p /etc/onesql RUN mkdir -p /data/onesql/data RUN mkdir -p /data/onesql/data/92bin ADD my.cnf /etc/onesql/my.cnf ADD ./run.sh /run.sh ADD ./config_mysql.sh /config_mysql.sh ADD ./supervisord.conf /etc/supervisord.conf ADD ./initDB.sh /initDB.sh

· 创建 Docker image:
docker build -t DockerRegistryPath/onesql-server:2.6.17

第二步 建立集群

请参见 创建/删除集群 来创建您的集群。

创建集群的实例可以参考第一个应用-2048

注意:如果您需要从集群外部来访问服务,则需要配置外网 IP 或可访问域名,集群中要配置外部网关和内部代理,以便对外进行服务暴露。

第三步 发布应用

接下来,通过数人云创建应用。

1、新建 onesql 应用:
   ·填写应用名称:onesql
   ·选择集群:your-cluster
   ·添加应用镜像地址:DockerRegistryPath/onesql-server
   ·填写镜像版本:2.6.17 
   ·选择应用类型:有状态应用
   ·添加目录:主机目录:/var/lib/onesql,容器目录:/data/onesql/data
   ·选择容器规格: CPU:0.5 内存:512 MB
   ·容器个数:1
   ·高级设置:
   ·填写应用地址: 端口:3306,类型:对内 TCP,映射端口:3306

主机目录与步骤1中创建的目录保持一致,容器目录与 my.cnf 配置文件中的 datadir字段保持一致。

2、新建 wordpress 应用:
   ·填写应用名称:wordpress
   ·选择集群:your-cluster
   ·添加应用镜像地址:wordpress
   ·填写镜像版本:latest
   ·选择应用类型:无状态应用
   ·选择容器规格: CPU:0.5 内存:512 MB
   ·容器个数:1
   ·高级设置:
   ·填写应用地址: 端口:80,类型:对外 HTTP, 域名:your-website
     参数:
WORDPRESS_DB_HOST=proxy-ip:3306
WORDPRESS_DB_USER=root
WORDPRESS_DB_PASSWORD=mysqlPassword

等待应用部署完成,访问 wordpress 地址,可以看到如下界面:

尾图.png


恭喜,现在你的 OneSQL 已经正常运作了!

Mesos Meetup 第三期干货PPT下载

dataman 发表了文章 • 0 个评论 • 2025 次浏览 • 2015-11-30 18:31 • 来自相关话题

11月29日,Mesos Meetup 第三期 - 北京技术沙龙成功举行。本次活动由数人科技CTO 肖德时 和 Linker Networks 的 Sam Chen 一起组织发起。周日早晨9点半,睡懒觉的诱惑也完全挡不住大家对Mesos技术的热情。计划30人的小沙龙,现场来了至少70人,没能到现场的朋友,也有近300人通过视频直播观看了本次沙龙。

本次沙龙,演讲嘉宾分享了很多Mesos实践干货,让参会者都收获满满。议题中既有图形化模型设计的应用容器化实践,基于Mesos的持续集成经验分享,也有爱奇艺,浙江移动等重磅企业的Mesos大规模应用实战分享。此外,还有程序媛的分布式数据库开发经验分享,真是巾帼不让须眉啊。





 
干货来袭:
 
1. 基于图形化模型设计的应用容器化实践 - LiuChao
 
来自Linker Networks的LiuChao同学与大家分享了《基于图形化模型设计的应用容器化实践》,从网络和存储两个方面与大家交流了心得体验。之后又详细介绍了如何采用 Controller + Executor 的模式来管理Docker应用之间的关系。





 
基于图形化模型设计的应用容器化实践PPT下载>>
 
2. 基于Mesos的持续集成实践
 
这个话题在本次沙龙上有两位朋友分别做了分享:《Linker CICD Solution on Mesos》by Victor 和 《基于Mesos持续集成的实践》by 陈亮。两位都从各自的实践中总结出了一套使用Mesos来做持续集成和持续发布的最佳实践,现场也做了深入的交流。





 
Linker CICD Solution on Mesos PPT下载>>





 
基于Mesos持续集成的实践PPT下载>>
 
3. 爱奇艺Mesos实践 - 杨成伟
 
爱奇艺的杨成伟分享了爱奇艺在实践Mesos的过程中踩过的坑。爱奇艺是国内互联网企业试用 Mesos 的先行者,最早将 Mesos 用于分布式转码服务,已经达到了800个节点。集群资源利用率已经高于40%,峰值时甚至超过了90%。





 
爱奇艺Mesos实践PPT下载>>
 
4. 程序媛的分布式数据库开发经验-李霞
 
TiDB的90后女程序员给大家分享了TiDB的现状:TiDB的架构优势包括支持MySQL协议,支持分布式事务,支持动态变更schema,支持动态扩容等。演示了使用WordPress时以TiDB做数据库存储,当时大家特别好奇感觉跟使用MySQL基本没有区别。所以用户从MySQL相关解决方案迁移到TiDB时基本没有成本,现在支持了大部分的MySQL指令。










 
程序媛的分布式数据库开发经验PPT下载>>
 
5. 中国移动浙江公司Mesos实践-钟储建
 
浙江移动的运维工程师钟褚建分享了基于Mesos的DCOS的实战经验。浙江移动和合作伙伴从论证到上线只用了半年时间,并且经历了双11的10亿PV压力(http://blog.dataman-inc.com/20151112-1111-zhejiangyidong-mesos/)。 演讲中,钟褚建与大家分享了移动进行Mesos选型的思路,成熟度、自主可控、可扩展性和可持续性。以及对于传统应用进行无状态改造上云的的干货。浙江移动重构了手机营业厅和CRM的少量代码,决心还是够大的。










 
中国移动浙江公司Mesos实践PPT下载>>
 
沙龙PPT整体下载:
 
Mesos Meetup 第三期PPT下载>>
 
下期会与大家分享沙龙视频,一睹嘉宾风采。 查看全部
11月29日,Mesos Meetup 第三期 - 北京技术沙龙成功举行。本次活动由数人科技CTO 肖德时 和 Linker Networks 的 Sam Chen 一起组织发起。周日早晨9点半,睡懒觉的诱惑也完全挡不住大家对Mesos技术的热情。计划30人的小沙龙,现场来了至少70人,没能到现场的朋友,也有近300人通过视频直播观看了本次沙龙。

本次沙龙,演讲嘉宾分享了很多Mesos实践干货,让参会者都收获满满。议题中既有图形化模型设计的应用容器化实践,基于Mesos的持续集成经验分享,也有爱奇艺,浙江移动等重磅企业的Mesos大规模应用实战分享。此外,还有程序媛的分布式数据库开发经验分享,真是巾帼不让须眉啊。

20151129meetup2.png

 
干货来袭:
 
1. 基于图形化模型设计的应用容器化实践 - LiuChao
 
来自Linker Networks的LiuChao同学与大家分享了《基于图形化模型设计的应用容器化实践》,从网络和存储两个方面与大家交流了心得体验。之后又详细介绍了如何采用 Controller + Executor 的模式来管理Docker应用之间的关系。

meetup1.png

 
基于图形化模型设计的应用容器化实践PPT下载>>
 
2. 基于Mesos的持续集成实践
 
这个话题在本次沙龙上有两位朋友分别做了分享:《Linker CICD Solution on Mesos》by Victor 和 《基于Mesos持续集成的实践》by 陈亮。两位都从各自的实践中总结出了一套使用Mesos来做持续集成和持续发布的最佳实践,现场也做了深入的交流。

20151129meetup3.png

 
Linker CICD Solution on Mesos PPT下载>>

20151129meetup4.png

 
基于Mesos持续集成的实践PPT下载>>
 
3. 爱奇艺Mesos实践 - 杨成伟
 
爱奇艺的杨成伟分享了爱奇艺在实践Mesos的过程中踩过的坑。爱奇艺是国内互联网企业试用 Mesos 的先行者,最早将 Mesos 用于分布式转码服务,已经达到了800个节点。集群资源利用率已经高于40%,峰值时甚至超过了90%。

20151129meetup5.png

 
爱奇艺Mesos实践PPT下载>>
 
4. 程序媛的分布式数据库开发经验-李霞
 
TiDB的90后女程序员给大家分享了TiDB的现状:TiDB的架构优势包括支持MySQL协议,支持分布式事务,支持动态变更schema,支持动态扩容等。演示了使用WordPress时以TiDB做数据库存储,当时大家特别好奇感觉跟使用MySQL基本没有区别。所以用户从MySQL相关解决方案迁移到TiDB时基本没有成本,现在支持了大部分的MySQL指令。

20151129meetup7OK.png


20151129meetup6.png

 
程序媛的分布式数据库开发经验PPT下载>>
 
5. 中国移动浙江公司Mesos实践-钟储建
 
浙江移动的运维工程师钟褚建分享了基于Mesos的DCOS的实战经验。浙江移动和合作伙伴从论证到上线只用了半年时间,并且经历了双11的10亿PV压力(http://blog.dataman-inc.com/20151112-1111-zhejiangyidong-mesos/)。 演讲中,钟褚建与大家分享了移动进行Mesos选型的思路,成熟度、自主可控、可扩展性和可持续性。以及对于传统应用进行无状态改造上云的的干货。浙江移动重构了手机营业厅和CRM的少量代码,决心还是够大的。

20151129meetup8.png


20151129meetup9.png

 
中国移动浙江公司Mesos实践PPT下载>>
 
沙龙PPT整体下载:
 
Mesos Meetup 第三期PPT下载>>
 
下期会与大家分享沙龙视频,一睹嘉宾风采。

视频直播:mesos meetup 北京技术沙龙第三期

dataman 发表了文章 • 0 个评论 • 1653 次浏览 • 2015-11-28 21:33 • 来自相关话题

废话不多说,视频直播地址在这里:

Mesos Meetup 第三期视频直播
 
http://www.douyutv.com/mesos 
 
是斗鱼? 没错,谁说斗鱼只能分享游戏心得,当然也能分享高大上技术心得。
 
------------------------------------
 
会议日程:

Service-driven graphic model based on Mesos and Docker  (9:50AM ~ 10:30AM)

    --Speaker :  Sam , LiuChao

CI/CD on Mesos   (10:30AM ~ 11:00AM)

   --Speaker , Victor,Xin

Mesos持续集成的实践 (11:00AM ~ 11:30)

   --Speaker : 陈亮,刘大伟

爱奇艺Mesos实践  (11:30AM ~ 12:00PM)

 --Speaker: 杨成伟

程序媛的分布式数据库开发经验(12:00 ~ 12:30)

  --Speaker: 紫沐夏

浙江移动的Mesos实践 (12:30 ~ 13:00)

  --Speaker: 钟储建

Open Discussion ( 13:00 ~ 13:10)

--All guys
 
 
地点:北京知春里融科资讯中心C座南楼17层 Vmware北京研发中心 





 
  查看全部
废话不多说,视频直播地址在这里:

Mesos Meetup 第三期视频直播
 
http://www.douyutv.com/mesos 
 
是斗鱼? 没错,谁说斗鱼只能分享游戏心得,当然也能分享高大上技术心得。
 
------------------------------------
 
会议日程:

Service-driven graphic model based on Mesos and Docker  (9:50AM ~ 10:30AM)

    --Speaker :  Sam , LiuChao

CI/CD on Mesos   (10:30AM ~ 11:00AM)

   --Speaker , Victor,Xin

Mesos持续集成的实践 (11:00AM ~ 11:30)

   --Speaker : 陈亮,刘大伟

爱奇艺Mesos实践  (11:30AM ~ 12:00PM)

 --Speaker: 杨成伟

程序媛的分布式数据库开发经验(12:00 ~ 12:30)

  --Speaker: 紫沐夏

浙江移动的Mesos实践 (12:30 ~ 13:00)

  --Speaker: 钟储建

Open Discussion ( 13:00 ~ 13:10)

--All guys
 
 
地点:北京知春里融科资讯中心C座南楼17层 Vmware北京研发中心 

沙龙1.jpg

 
 

永洪BI也能在数人云上跳舞

dataman 发表了文章 • 0 个评论 • 948 次浏览 • 2015-11-27 14:24 • 来自相关话题

最近,SaaS是越来越火了,获得了众多资本的追捧,市盈率高达8倍。而传统软件行业却不被大家所关注,市盈率也仅3.2倍。同样是为企业客户提供服务,为什么差距就这么大呢?





 
这就要说到SaaS与传统软件对比的三个特点了:易部署、自动升级迭代、按需付费。 小编琢磨,易部署这条,Docker容器技术不是完美解决么。wordpress, discuz之类的都太小巧,找个大象级别的来试试~

我们就拿BI行业的领头羊——永洪BI的产品做例子吧
 
永洪BI
 
永洪 BI 是目前国内最好用的数据可视化分析软件,具有简单易用、多样化呈现、交互式体验、支持各类移动终端等特色,可以帮助客户提升10-100倍运营效率、实时洞悉业务状况和变化。其客户包括中国移动、国家电网、航天三院、四达传媒、中国风电、浪潮集团、博彦科技、宝宝树、百程旅行网等在内的知名企业。

永洪BI是基于Java环境的传统B/S架构的软件。我们通过两步,就可以将永洪BI在数人云上成功发布啦。
 
第一步:将永洪BI产品Docker容器化
 
首先,获取永洪BI的安装脚本文件,必须选择Linux版本。 (请到永洪BI官网申请试用,获取安装脚本)YonghongBI.sh


下载后,编写一个Dockerfileroot@omegamaster1:/data/yh# cat Dockerfile
FROM java:8
MAINTAINER Xiao Deshi (dsxiao@dataman-inc.com)
ADD YonghongBI.sh /app/
WORKDIR /app接着写一个build.shroot@omegamaster1:/data/yh# cat build.sh
#!/bin/bash
docker build -t yonghongbi:v1并到容器里面安装永洪BIdocker run -it yonghongbi:v1 /bin/bash将永洪BI的安装向导安装到指定的目录,比如 /app/YH,退出把此容器保存为新镜像docker commit 6750d30477ed(此hash为上面container的hashcode) yonghongbi:v2最后把此镜像提交到企业私有仓库,就可以放心使用了。

如果您不熟悉Docker技术,我们可以给您提供培训和咨询,或直接提供Docker镜像打包服务:
 
立即咨询>>
 
第二步:通过数人云一键发布永洪BI应用
 
在数人云上选择一个已建立的集群,填写以下参数后,点击创建应用即可。

点击新建应用后,填写:
填写应用名称:yonghongbi选择集群:your-cluster添加应用镜像地址:/path/to/yonghongbi/image填写镜像版本:version选择应用类型:无状态应用选择容器规格: CPU:0.5 内存:2048 MB容器个数:1





 
高级设置:
填写应用地址: 端口:8080,类型:对外 HTTP,域名:your-website





在CMD中填写:
/app/YH/tomcat/bin/catalina.sh run注:由于 永洪 BI 是 Web 应用,并需要对外服务发现,因此选择对外标准 HTTP,会对外暴露 80 端口;同时,需要填写域名:your-website;

再回到应有管理中,可以看到应用已正常运行。(要耐心等待一会,永洪 BI 的 Docker image 比较大,小编打的有1GB……,所以部署时间会比较长)

打开浏览器,访问地址:www.your-website.com(或网关 IP),看到如下页面,则说明 永洪BI软件已经成功运行。

恭喜,现在你已经完成了一套永洪 BI 的部署!





 
易部署、易扩展
 
一次打包,到处运行。接下来,想部署100套永洪BI的产品实例?很简单,在应用管理中将应用实例的数量修改为100即可。

这需要多长时间?1分钟…… 是的,没错就是1分钟。

1分钟部署100个永洪BI应用实例! 
1分钟部署100个永洪BI应用实例! 
1分钟部署100个永洪BI应用实例! 
重要的事情说三遍~~
 
当然本次部署仅是永洪BI的试用产品,大家对产品感兴趣,请到永洪BI官网申请试用:http://www.yonghongtech.com/

注册试用数人云

软件上云咨询
 
  查看全部
最近,SaaS是越来越火了,获得了众多资本的追捧,市盈率高达8倍。而传统软件行业却不被大家所关注,市盈率也仅3.2倍。同样是为企业客户提供服务,为什么差距就这么大呢?

saas.png

 
这就要说到SaaS与传统软件对比的三个特点了:易部署、自动升级迭代、按需付费。 小编琢磨,易部署这条,Docker容器技术不是完美解决么。wordpress, discuz之类的都太小巧,找个大象级别的来试试~

我们就拿BI行业的领头羊——永洪BI的产品做例子吧
 
永洪BI
 
永洪 BI 是目前国内最好用的数据可视化分析软件,具有简单易用、多样化呈现、交互式体验、支持各类移动终端等特色,可以帮助客户提升10-100倍运营效率、实时洞悉业务状况和变化。其客户包括中国移动、国家电网、航天三院、四达传媒、中国风电、浪潮集团、博彦科技、宝宝树、百程旅行网等在内的知名企业。

永洪BI是基于Java环境的传统B/S架构的软件。我们通过两步,就可以将永洪BI在数人云上成功发布啦。
 
第一步:将永洪BI产品Docker容器化
 
首先,获取永洪BI的安装脚本文件,必须选择Linux版本。 (请到永洪BI官网申请试用,获取安装脚本)
YonghongBI.sh


下载后,编写一个Dockerfile
root@omegamaster1:/data/yh# cat Dockerfile 
FROM java:8
MAINTAINER Xiao Deshi (dsxiao@dataman-inc.com)
ADD YonghongBI.sh /app/
WORKDIR /app
接着写一个build.sh
root@omegamaster1:/data/yh# cat build.sh 
#!/bin/bash
docker build -t yonghongbi:v1
并到容器里面安装永洪BI
docker run -it yonghongbi:v1 /bin/bash
将永洪BI的安装向导安装到指定的目录,比如 /app/YH,退出把此容器保存为新镜像
docker commit 6750d30477ed(此hash为上面container的hashcode) yonghongbi:v2
最后把此镜像提交到企业私有仓库,就可以放心使用了。

如果您不熟悉Docker技术,我们可以给您提供培训和咨询,或直接提供Docker镜像打包服务:
 
立即咨询>>
 
第二步:通过数人云一键发布永洪BI应用
 
在数人云上选择一个已建立的集群,填写以下参数后,点击创建应用即可。

点击新建应用后,填写:
  • 填写应用名称:yonghongbi
  • 选择集群:your-cluster
  • 添加应用镜像地址:/path/to/yonghongbi/image
  • 填写镜像版本:version
  • 选择应用类型:无状态应用
  • 选择容器规格: CPU:0.5 内存:2048 MB
  • 容器个数:1


yonghongbi2.png

 
高级设置:
  • 填写应用地址: 端口:8080,类型:对外 HTTP,域名:your-website


yonghongbi3.png

  • 在CMD中填写:

/app/YH/tomcat/bin/catalina.sh run
注:由于 永洪 BI 是 Web 应用,并需要对外服务发现,因此选择对外标准 HTTP,会对外暴露 80 端口;同时,需要填写域名:your-website;

再回到应有管理中,可以看到应用已正常运行。(要耐心等待一会,永洪 BI 的 Docker image 比较大,小编打的有1GB……,所以部署时间会比较长)

打开浏览器,访问地址:www.your-website.com(或网关 IP),看到如下页面,则说明 永洪BI软件已经成功运行。

恭喜,现在你已经完成了一套永洪 BI 的部署!

yonghongbi1.png

 
易部署、易扩展
 
一次打包,到处运行。接下来,想部署100套永洪BI的产品实例?很简单,在应用管理中将应用实例的数量修改为100即可。

这需要多长时间?1分钟…… 是的,没错就是1分钟。

1分钟部署100个永洪BI应用实例! 
1分钟部署100个永洪BI应用实例! 
1分钟部署100个永洪BI应用实例! 
重要的事情说三遍~~
 
当然本次部署仅是永洪BI的试用产品,大家对产品感兴趣,请到永洪BI官网申请试用:http://www.yonghongtech.com/

注册试用数人云

软件上云咨询