云计算特大新闻爆料 取消关注 私信管理员 签到

管理员 : 宝德云 创建时间 : 2015-12-16 11:27:54

简介 : 有关云计算的重大新闻发布,活动、资讯、技术等。http://www.plcloud.com

3946

话题 云计算数据中心综合布线的七大发展趋势

云计算是最近几年最热门的话题之一,我们的生活越来越离不开云,网络订票、购物、订房、订餐等各种应用层出不穷。云计算改变了人们的生活方式,也改变了数据中心的技术发展路线,为了满足不断涌现的互联网应用和不断增长的数据传输需求,云计算数据中心网络布线正面临以下七大发展趋势:1. 高性能计算(100/40Gbps做主干,25/10Gbps到服务器)传统的以太网以10为倍数来增长,从经济的角度来说,价格和功耗都会很高,难以满足快速增长的数据中心市场需求。下一代的以太网为以4为倍数来增长,100Gbps做主干,25Gbps到服务器,主干采用24芯或者12芯MPO光缆,支持100Gbps或40Gbps到主干; 水平采用Cat.8铜缆或者Cat.6A铜缆,支持25Gbps或10Gbps到服务器。2. 网络架构扁平化(Spine-leaf架构&ToR布线)         传统的数据中心数据流主要在服务器和客户机之间流动,我们形象地称之为南北向的流动,云计算数据中心数据流主要在数据中心服务器之间流动,我们称之为东西向流动。这种东西走向的大量数据的交换要求数据中心采用扁平化的骨干(Spine)和分支(Leaf)两级网络架构,这种“胖树”架构能够实现无阻塞、低延迟、快速交换,也促使网络布线结构做相应的改变。         传统数据中心布线采用主配线区(MDA)和水平配线区(HDA),设备配线区(EDA)三层结构的布线方式,云计算数据中心布线结构趋向扁平化,布线结构简化为主配线区(MDA)和中间配线区(IDA)两层结构,设备机柜则通常采用柜顶 (ToR) 交换机到服务器跳线直连(Direct connect)的方式,这种方式方便统一管理,另外能够显著降低部署时间。3. 模块化         传统的数据中心基建、供电 、制冷 、网络布线分批部署,成本高、部署速度慢、功耗高 。模块化数据中心将机柜、供配电、制冷、布线、安防等基础设施集成为一体  ,一次性交付,有利于数据中心快速部署、灵活扩容、降低功耗。 4. 光进铜退          虚拟化驱动数据中心采用更高性能、更多芯数的光纤,云计算的数据中心由于采用ToR布线结构,不存在水平布线,光缆和铜缆的比重大约是7:3甚至更高。                  随着光纤芯数和密度的不断提高,云计算数据中心需要采用更专业的光纤管理设备,提供熔接保护、弯曲半径保护、余缆存储和物理保护以及路由管理,从而保证网络的7x24小时可靠运营,同时方便日后的跳线管理和维护。 5. 智能化(DCIM&AIM)         云计算数据中心是一个生态系统,它提供基本的基础设施(IaaS)或者统一的管理平台(PaaS),甚至统一的软件服务(SaaS)。随着云计算数据中心投入运营,用户流量不断增多,管理范围不断扩大,管理员面临越来越大的压力:大量的资产管理、频繁的移动、增加、变更(MAC)维护,多站点的管理……。为了有效的管理这个生态系统,云计算数据中心通过采用数据中心基础设施管理(DCIM)以及自动基础设施管理(AIM)等智能化的手段能够实时、远程监控数据中心主要的基础设施包括供电、温度、安防、布线,因而大大提高数据中心可视化和管理效率 。  6. 集中式管理        传统数据中心采用分布式的管理方式,列头柜集中放置接入交换机和水平配线架,用来统一管理一列的设备。云计算的数据中心采用集中管理方式,所有的设备机柜采用光纤上连到主配线区(MDA)/中间配线区(IDA),在主配线区(MDA)/中间配线区(IDA)内集中放置光纤配线机架(ODF)和分支(Spine)交换机。这种集中管理方式有利于统一管理,可以提高交换机设备端口使用率,另外可以减少管理员足迹。 7.交叉连接(Cross-connect)         传统的数据中心布线一般采用互连(Inter-connect)的连接方式,即采用跳线直接连接水平配线架和交换机。互连方式优点是配线架的数量少,缺点是日后管理维护需要在交换机上进行,容易造成有源设备故障,甚至网络宕机。         云计算数据中心一般在主配线区(MDA)或中间配线区(IDA)采用交叉连接(Cross-connect)的连接方式,即交换机采用跳线连接到一个影射配线架上,日常维护中如网络需求变化比如需要对跳线增加、移动或者变更(MAC),管理员无须在交换机上进行插拔,只须在影射配线架和水平配线架之间进行跳线操作。         这种交叉连接(Cross-connect)方式的好处包括:1、 管理界面清晰,有源设备和无源设备放置在不同的管理机柜2、 无须在交换机上进行跳线操作,减少有源设备故障3、 方便日后跳线管理维护(MAC,移动,增加,变更),仅需在配线机柜内操作4、 方便线路查找,配线架上提供清楚的标签系统5、 采用统一长度的跳线,减少服务差别  推荐阅读  1、企业级OpenStack 的六大需求(1)API 高可用、管理和安全  2、企业级OpenStack 的六大需求(2):开放架构和混合云兼容  3、企业级OpenStack 的六大需求(3):弹性架构、全球交付  4、混合托管:第三代云计算  5、你所不知道的大数据、云计算,以及无法计算的价值

上云咯

--

18月前
2553

话题 3.26 Docker Meetup-广州站

【活动简介】三年光阴,如白马过隙。三年里,随着 Docker 引擎的升级,Docker Native(原生)在存储、集群、安全等方面的性能得到极大的提升。Docker Native 是包括 Docker Engine、Docker Swarm、Docker Compose 和 Docker Machine 等在内的一系列 Docker 原生组件,构成了云计算新世代的创新原力。Docker 的强大无需多说,随着 Docker 技术日趋成熟,越来越多的厂商开始拥抱 Docker。宝德云较早开始研究 Docker,以 OpenStack + Docker 为技术基础,为用户提供全面、创新的云解决方案。在这个春暖花开的日子,让我们相约广州,参与 Docker Native 的非凡旅程,一起探讨,一起为Docker庆生。【活动时间地点】活动时间:3 月 26 日 下午 1:30-5:30活动地点:贝塔空间(广州市天河区建中路 24 号)【嘉宾与话题介绍】1. 陈齐彦|DaoCloud 首席执行官,联合创始人话题:《Docker 原生之道》陈齐彦,DaoCloud 首席执行官,联合创始人。负责 DaoCloud 整体战略、产品规划、技术方向和企业级客户营销。陈齐彦曾在 EMC 和 Oracle 任职多年,EMC 中国研究院创始人,总架构师,拥有 30 几项美国专利,复旦大学计算机硕士。2. 郭峰|DaoCloud 首席技术官话题:《打造精益研发流程》郭峰,DaoCloud 首席技术官,联合创始人。管理 DaoCloud 研发团队,把握产品开发进度、功能模块发布,并为企业级客户提供顾问服务。郭峰曾就职于 EMC,担任中国研究院云平台主任工程师,在 PaaS 开源社区拥有很高的声誉,拥有 20 几项美国专利,同济大学计算机硕士。对 PaaS 内核及容器技术有深入研究,是 Java 和企业级微服务架构的业界专家。3. 刘洋:宝德云 Docker 容器技术研发工程师话题:《宝德云容器技术实践分享》刘洋,宝德科技集团云事业群云 Docker 容器技术研发工程师,宝德云应用平台项目产品经理。很早开始接触容器技术,有着丰富的开发和运维经验,参与江苏国税等多项目容器技术支撑。4. 郑和柳 | 机智云软件工程师话题:《Docker 在机智云微信 App Engine 中的应用》介绍:本议题主要介绍机智云微信 App Engine 的技术架构及实现。首先会描述机智云微信 App Engine 的业务背景,然后介绍机智云微信 App Engine 的技术架构,最后讲解如何使用 Docker 实现。(活动话题及其他信息以活动现场为准)【欢迎报名】请点击“原文”,填写您的有效信息,我们将通过邮件/短信方式通知您相关的参会信息。  推荐阅读  1、企业级OpenStack 的六大需求(1)API 高可用、管理和安全  2、企业级OpenStack 的六大需求(2):开放架构和混合云兼容  3、企业级OpenStack 的六大需求(3):弹性架构、全球交付  4、混合托管:第三代云计算  5、你所不知道的大数据、云计算,以及无法计算的价值

宝德云

--

20月前
2474

话题 数据揭秘|容器集群开源项目哪家最强劲?Kubernetes,Swarm,Mesos...

2013年 Docker 大火之后,Kubernetes (K8S),Swarm,Mesos 这些围绕着 Docker 容器展开的集群管理开源项目也是风起云涌!但究竟目前市场上 Docker 容器编排技术,客户最喜欢用哪个?大家最关注哪个?开发者使用最多的是哪个?简而言之,容器集群开源项目,哪家势头最强劲?媒体至今没有任何统计数据。美国一家叫 FlawCheck 的公司,近日发布了一组数据,揭秘了这几大开源项目截止2016年2月为止累计被 pull 数据。FlawCheck 数据收集方法是这样:Swarm 的数据,直接来自 Docker Hub 里被 pull 的总数。Mesos 的数据,来自 mesos-master 和 mesos-slave 被 pull 数据的总和,这个计算方法和 Swarm 的很类似。Kubernetes 的数据,略复杂一些,有两部分。一是 Kubernetes proper,是在 GCR 并不是 DockerHub 上,但 kubelets,是在 Kubernetes/pause 和 Kubernetes/heapster 的 kube master 的 pull。两部分加起来,得出关于 K8S 被 pull 数据。统计结果如何呢? Kubernetes 以 26.1 million 次领先;Swarm 紧随其后,24.8million;Mesos 排第三,被 pull 次数为 13.7 million.(参见下图)Caicloud 补充了几个比较流行的容器集群开源项目,对包括 Kubernetes,Swarm,Compose,Mesos,Docker Machine,Hyper,Containerd 在内的 7 个项目,也做了一个数据统计:截止2016年2月为止,这些开源项目在 github 上被 fork(表示开发使用量)、被 watch(表示受关注)和被 star(表示喜爱)的数据。这次,统计结果又如何呢?1、在 github 被 fork(表示开发使用量)数据Kubernetes 以 3699 次列第一,Compose 974 居次席,然后依次是 Docker Machine (746)、Mesos (738)、Swarm (598), Hyper (68)、Containerd (42)。2、在 github 被 watch(表示受关注)数据Kubernetes 被 watch 1163次列第一,Compose 423次居次席,然后依次是 Mesos (337)、Swarm (305), Docker Machine (242)、Containerd (83)、Hyper (63)。3、在 github 被 star(表示喜爱)数据Kubernetes 依然以12888颗星数雄居榜首,Compose 以7126居次席,然后依次是 Swarm (3462)、Docker Machine (3019)、Mesos (2056)、Hyper (709)、Containerd (344)。虽然获取数据的视角不同,但结论基本殊途同归。结合这些数据来看,K8S 项目相比 Swarm、Mesos、Hyper 等在 GitHub 上有更多的贡献者和更大规模的代码,被开发者使用的也最多。无论是被 pull、被 fork、被 watch、还是被 star 数,目前均遥遥领先,堪称几大容器集群管理开源项目中最为流行、最受关注的一个。当然,Swarm 在短时期内的成长速度也非常快。原文转自:才云科技 韩佳瑶 Caicloud  推荐阅读  1、企业级OpenStack 的六大需求(1)API 高可用、管理和安全  2、企业级OpenStack 的六大需求(2):开放架构和混合云兼容  3、企业级OpenStack 的六大需求(3):弹性架构、全球交付  4、混合托管:第三代云计算  5、你所不知道的大数据、云计算,以及无法计算的价值

宝德云

--

20月前
2470

话题 宝德云邀您免费直通极客邦“技术社群大会”

软件定义世界即技术定义世界,技术极客正如技艺高超的建筑师,互联世界的万花园离不开技术人,技术人生态圈的打造对于互联网行业发展和技术创新有着特别重要的意义,云计算行业对技术有着近乎苛刻的要求,也集结了各方面技术人才。宝德云致力于云计算技术发展创新,早在2012年就投入力量研发 SDN 软件定义网络,SDS 软件定义存储等云计算开源技术。积极参与 OpenStack、Docker、Ceph 等全球社区活动,与各开源技术极客共同拥抱开源技术。为共同推进技术人生态圈的发展,宝德云携手极客邦组办的“技术社群大会”面向纯粹技术人,以及对技术社区感兴趣的社区运营人员,聚焦“社区分享,引领趋势”,以社群的方式把社区领袖,社区爱好者,行业专家联系 一起,形成合力。“技术社群大会”帮助技术人了解前沿技术发展趋势,帮助社区运营者了解社区运营之道,帮助企业了解技术品牌传播经验,营造更加好的技术社区生态圈,让业务更多认识到技术的价值,推进商业发展。3月27日,北京新云南皇冠假日酒店,宝德云邀您与技术大牛、社区领袖共同探讨技术社群发展趋势与未来。您有两种方式获得价值480元的技术社群大会门票:1.报名的整数位将获得幸运票2.通过宝德云取得通票密码。按照报名链接指标报名,您还有可能获得神秘大奖。报名请戳 http://test.shequn.geekbang.org/  推荐阅读  1、企业级OpenStack 的六大需求(1)API 高可用、管理和安全  2、企业级OpenStack 的六大需求(2):开放架构和混合云兼容  3、企业级OpenStack 的六大需求(3):弹性架构、全球交付  4、混合托管:第三代云计算  5、你所不知道的大数据、云计算,以及无法计算的价值

宝德云

--

20月前
2325

话题 宝德云携手安全狗打造云安全堡垒

云安全对于云计算厂商来说是个永恒的话题,云计算厂商可分成两种类型:已经遭受过攻击的厂商和即将遭受攻击的厂商。在安全事故频发的2015,宝德云紧密携手安全厂商做好防备,有惊无险的度过了一年。但安全对于云计算厂商来说是永远不能放松的一件事情,趁着新年伊始,春暖花开,宝德云与众安全厂商来一起探讨“云时代,如何打造最强安全堡垒”。一起来面对这个现实而又骨感的问题。我们一起看看 P2P 金融行业是如何面对云计算时代的企业安全的,学习平安银行是怎样解决APP运营过程中的安全问题的,看看龙珠视频是如何完成亿级流量访问的,还可以听听知名黑客讲讲安全圣经……时间:2016年2月26日 13:30地点:深圳·威尼斯酒店·3F 特维里(深圳市华侨城深南大道9026号)我们在这里期待您的光临。  推荐阅读  1、企业级OpenStack 的六大需求(1)API 高可用、管理和安全  2、企业级OpenStack 的六大需求(2):开放架构和混合云兼容  3、企业级OpenStack 的六大需求(3):弹性架构、全球交付  4、混合托管:第三代云计算  5、你所不知道的大数据、云计算,以及无法计算的价值

宝德云

--

21月前
2324

话题 关于GNU glibc getaddrinfo()堆栈缓冲区溢出漏洞的安全公告

  近日,国家信息安全漏洞共享平台(CNVD)收录了GNU glibc getaddrinfo()堆栈缓冲区溢出漏洞(CNVD-2016-01100,对应CVE-2015-7547)。攻击者利用漏洞可通过构建恶意dns服务或使用中间人的方法对受害者发起攻击,对Linux终端设备构成安全威胁。   一、漏洞情况分析  GNU glibc是一款按LGPL许可协议发布的开源C语言编译程序,是Linux操作系统中C库的实现。  glibc中getaddrinfo函数在处理特定dns response数据包时存在栈溢出漏洞。由于glibc通过alloca()函数在栈中为_nss_dns_gethostbyname4_r函数2048字节的空间,用于托管DNS响应;若响应大于2048字节,程序会从堆中重新分配一个缓冲区,并更新所有信息(缓冲区指针,缓冲区大小和响应大小);在一定条件下,会出现栈缓冲区和新分配的堆内存的错误匹配,导致超过栈缓冲区大小的响应仍然存储在栈中,进而发生缓冲区溢出。攻击者利用漏洞可通过构建恶意dns服务或使用中间人攻击的方法对Linux主机或相关设备发起攻击,导致远程代码执行,进而可获取用户终端控制权。  CNVD对该漏洞的综合评级为“高危”。  二、漏洞影响范围  漏洞影响glibc>2.9的所有版本,glibc是Linux系统中最底层的API,应用于众多Linux发行版本中,因此该漏洞影响范围广泛。所有Debian 系列、Red Hat 系列的Linux 发行版,只要glibc版本大于2.9均受该漏洞影响。  三、漏洞修复建议  目前,互联网上已披露针对该漏洞的利用原理分析及利用代码。厂商暂未发布升级补丁修复该漏洞,CNVD建议用户采取如下临时措施:该漏洞存在于resolv/res_send.c文件中,当getaddrinfo()函数被调用时会触发该漏洞,技术人员可以通过将TCP DNS响应的大小限制为1024字节,并丢弃所有超过512字节的UDP DNS数据包来缓解该问题。        附:参考链接:        https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547        https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html (补丁链接)        http://www.cnvd.org.cn/flaw/show/CNVD-2016-01100  推荐阅读  1、企业级OpenStack 的六大需求(1)API 高可用、管理和安全  2、企业级OpenStack 的六大需求(2):开放架构和混合云兼容  3、企业级OpenStack 的六大需求(3):弹性架构、全球交付  4、混合托管:第三代云计算  5、你所不知道的大数据、云计算,以及无法计算的价值

上云咯

--

21月前
2234

话题 携程、乐视、宝德云、联通等公司使用的 Ceph 存储集群

Ceph 作为软件定义存储的代表之一,最近几年其发展势头很猛,也出现了不少公司在测试和生产系统中使用 Ceph 的案例,尽管与此同时许多人对它的抱怨也一直存在。本文试着整理作者了解到的一些使用案例。1. 携程(Ctrip)携程所使用的各种存储的现状:商业存储:SAN(HP/ HPS),1+ PB,数据库NAS (HW),800+ TB,文件共享开源存储:GlusterFS,1+ PB,数据库备份FastDFS,1+ PB,海量照片HDFS,10+ PB,大数据而在不久的将来,随着公司业务的发展,携程需要的存储容量需要扩大到10倍以上。携程选择 Ceph 的理由:低成本 + SDS + Scale-out + 统一存储 + 企业特性携程目前的Ceph集群的配置:CephVersion: 0.94.2,H releaseob ject Storage: RGW + Swift APISDK: Python/ Java/ C#/ RubyOS: Centos 6.4硬件:CPU(2 channels & 32 Core)、Mem128GB、disk(12*3TB/SATA disk +2*256GB raid1 SSD)、NIC(4*Gigabit LAN, bond 2 in 1 pair)RGW 使用架构:携程有在数据中心之间的同步数据的需求。在研究了 CRUSHmap、Radosgw-agent、Federate gateway(不稳定、不灵活(只支持Zone 之间同步)、不易扩展)后,其自研了 COS 方案,它具有稳定、灵活、扩展性等特点:下一步的计划:Database on Ceph (Dev & QA Farm)Openstack/ DockerIntegrate with CephIT "Dropbox"资料来源:携程在 2015/10/18 SH Ceph Day 上的分享。楼主点评:与互联网公司的通常做法一致:慎重选择、细致测试、分布使用(往往从开发测试环境中使用开始)、开源的不够用就自研希望携程能有更多的分享和回馈社区2. 联通研究院中国联通研究院在使用 Ceph 对象和文件存储:该集群还比较小,更多的是处于做大规模使用前的准备阶段。其测试环境:测试结果:他们认为 SSD 对性能提升的效果一般:资料来源:联通研究院在 2015/10/18 SH Ceph Day 上的分享。楼主点评:尚处于小规模测试和试用阶段使用的测试方法或者调优手段可能没到位,不然性能提高不会那么少3. 宝德云(PLCloud)宝德云使用 Ceph 的理由:Pure SoftwareOpen Source, Commercial SupportUnified Storage: RBD, RGW, CephFSScale OutSelf HealingReplication and Erasure CodingIntegrate well with OpenStack宝德云的用法:OpenStack + Ceph (RDB,CephFS)+ Docker所有 OpenStack 存储都放在 Ceph 上18*(5 OSD+1SSD) / CephRBD / CephFS785VM / 4vCPU32GB per VMUbuntu14.04 / Docker1.6.1 / 150+ Containers per VMAll VM Mount CephFSMount VM Directory as Container’s Data VolumeBoot 1 VM < 5sBoot 1 Container < 1sBoot 150+Containers < 120sCeph Rados Gateway driver for Docker Registry Map RBD device inside DockerContainerCephFS as Data Volume CephFS as NAS StorageRun Ceph in Containers使用案例:宝德云上的i耳目流媒体服务Run media web/app/dbvmover OpenStackand CephRBDUse CephRGW as media resource storagePut video TransportStream/jpg file via c-language programmeManage resource via python-swiftclient400+KB per video tsfileReserved video ts/jpg file 7 days or   30 daysAllow media server temporary access to ob jectsProvide media service for Internet and Intranet User资料来源:宝德云在 2015/10/18 SH Ceph Day 上的分享。楼主点评:够大胆(到目前为止 CephFS 还不稳定呐)、够与时俱进(什么东西新就用什么)没说清楚怎么支持i耳目的超大流数据4. CERN(欧洲核子研究委员会)实验室(http://research.nesc.ac.uk/files/CERN_OpenLab_Report.pdf)4.1 测试环境CERN 的一些实习生搭了一套环境,使用 NetApp Cinder driver 和 Ceph,进行性能比较。NetApp 环境(适应iSCSI驱动):                               Ceph 集群:FAS2040 Storage SystemsData ONTAP 852 DisksBenchmark 环境:做法:在两个存储上分别创建100G,200G,400G的卷,分别挂载到三个虚机上,使用 hdparm、Flexible I/O Tester 和 dd 命令作为测试工具。4.2 测试结果(FIO使用的是 writeback 缓存机制)结论:读上,Ceph 比 NetApp 更快;写上,两者差不多。Ceph 使用缓存的话,对 I/O 性能影响很大。writeback 能较大地提交性能,而 writethrough 只能轻微地提交性能。对单个卷使用不同的条带化参数,能提交其性能。该功能会在 Cinder 中实现。5. 乐视云(http://www.chinacloud.cn/show.aspx?id=21835&cid=81)乐视采用了 Ceph RBD 作为 统一存储,OpenStack 使用的 Cinder,后端接的是 Ceph,Glance 也是共享 Ceph 存储。同时还提供了 S3 对象存储,用作于 CND 源站,存储乐视网的视频以及客户需要分发的资源。S3 也是全国分布式部署,用户可以就近上传,再推送到北京。目前乐视云 OpenStack 规模已达 900 个物理节点,对象存储的数据达到数 PB。乐视认为,“ceph 数据分布,性能方面都很不错,crush 算法是它的亮点”。总结:原文转自:SammyLiu 的博客  推荐阅读  1、企业级OpenStack 的六大需求(1)API 高可用、管理和安全  2、企业级OpenStack 的六大需求(2):开放架构和混合云兼容  3、混合托管:第三代云计算  4、你所不知道的大数据、云计算,以及无法计算的价值  5、为什么CIO们对云计算策略追求最终的对称性

宝德云

--

21月前
2107

话题 基于OpenStack和Docker的私有云平台实践

无Docker 不OpenStack,当前讨论OpenStack 总是离不开Docker。这里我先嚼一下剩饭,下面是OpenStack 上Docker 技术分布的老图。我们包括生产化/测试/调研阶段的Docker 化项目包括了:Heat、Magnum、Sahara、Nova、以及OpenStack 平台本身的自动打包和平台稳定性测试方面。1.Docker OpenStack 平台稳定性测试OpenStack 平台本身是一个SOA 的项目,具体服务的参数设置需要依据集群规模,服务搭建架构等进行相关测试和调优。Fake 是OpenStack Nova Compute 下的一个Driver,绝大多数Compute API 走到这里简单处理后返回成功。我们使用Docker 来封装Nova Compute,并在Nova 配置中使用Fake。这样每个Docker Container 便成为一个虚拟的Nova Hypervisor Node,便可以模拟Controller 集群管理超大量Compute 节点的状况;同时Fake Driver 收到请求直接返回成功的特性,让我们可以测试超大量的VM同时创建和同时销毁时给控制节点和MQ带来的压力状况。这里Docker 模拟了物理服务器,解决了测试服务器不足的状况。这只是一个测试例子,由于测试的不同需求,可能 Nova Fake 需要频繁的变更配置,Docker 的快速启动和快速销毁也提供了变更测试环境的便利,Dockerfile 的定制化需求不仅为镜像频繁变更带来方便也让测试环境本身更易追溯。2. OpenStack 自动打包个人认为私有云平台压力通常没有公有云高,但是个性化定制更强。我们内部的定制化需求也很高(例如集群中计算资源的主机级别和机架级别的反亲和等等)。OpenStack 的平台的组件需要频繁更新。我们内部使用的是Puppet 推送RPM更新的方式进行,且维护了两个OpenStack 的版本,大量编译的依赖和依赖的冲突以及编译后的脏数据成为我们的痛点。于是我们将OpenStack 所涉及的包括Nova、Neutron、Glance、Cinder、Trove、Sahara 等等项目的编译依赖环境统统放进一个Docker Image 中。我们维护了一个脚本,通过参数来指定要编译的OpenStack 的版本和组件。该脚本会自动从Docker Registry 服务器中pull 一个指定版本的的编译环境镜像。并将GIT 服务器其中指定版本的分支代码clone 到容器中,通过挂卷的方式将编译后的RPM包输出到外部打包服务器上。编译结束后输出编译的状态结果。这样我们便不需要再维护一个编译环境了,只需要维护编译镜像和GIT库内部源码。可以在任意笔记本环境来生成打包环境。3. Docker 加速SaharaSahara 是OpenStack 中“大数据即服务”的项目,支持Hadoop、Spark、CDH 5.x 等。通过Heat 编排可以使用KVM 或者Docker 作为计算资源。我们测试使用了Hadoop 的服务,通过运行KVM 和Docker 的测试,Docker 在启动速度、资源利用率、以及性能开销上具有优势,我这里简单罗列一下测试对比。基本测试环境:服务器:2台 24Core 128G memoryhadoop:1.2job:*streaming MapperReduce集群规模10KVM 测试数据Docker 测试数据说明:不同的配置参数,不同的MapReduce 程序,Hadoop 计算的时间都不相同,这里只是给出在相同环境下Docker 和KVM 建的差别。Docker 的测试数据是在Container 内部的。4. Docker Nova 项目这个是大家争议最大的项目,不过对于我们平台来说,服务云化这是第一步。需要其他开发团队逐步熟悉面向容器的开发以及我们对Docker 本身逐步的摸索,才敢真正把环境切换到Kubernetes/Mesos 上来,进而推进Magnum。借用京东鲍永成的那句话:“让能够接受新世界的团队慢慢先适应”。通过Nova API 调度Nova Compute 生产 Nova instance,而Nova instance 的类型由具体配置的hypervisor Driver 来决定,这里我们设置Docker 作为Driver 就可以让Nova Compute 节点生产Docker。Nova Docker 项目来自于社区,我们结合社区代码进行了一定量的修改,并且在镜像定制,具体使用上有一些自己不同的方式。承载业务方面:Nova Docker 这块目前最主要的是Tomcat 的服务,Docker 用于搭建java tomcat 运行环境 dockerfile 中将jdk 和tomcat 安装好,之后Docker 启动后通过ansible-playbook 个性化修改Tomcat 配置,推送war 包至远程容器。镜像方面:引入Supervisor 作为进程管理器。设计了3层的镜像管理格式,最底层为最小化系统,中间层引入了公司yun 源,入侵检测设置、ssh/pam 等安全设置。 上层可以最小化的实现APP 的环境版本管理。支持了Tomcat/Cloudinit/Hadoop 的完全或者初步测试使用。设计了Docker 的hostname、dns、网卡名称每次都重置的问题,提供固化机制。Container 实现了支持类似于物理机的FirstBoot 和init 机制。Glance 管理Docker 镜像和Docker 快照镜像。计算方面:支持Compute 节点配置的超分,Docker 节点能够超分相对KVM更多的CPU/MEM 等资源。Nova 配置文件设置cpushare、cpuset、cpumix 三种cpu 的管理模式,可以针对不同模式的Container 环境来设置CPU 模式。nova 配置为主机预留CPU,保证Container 不会侵占预留资源。上层镜像开机随机生成用户UID,避免映射到宿主机相同的UID。NOVA 配置不同的Docker API 版本。快照、快照恢复、迁移等基本实现。支持通过flavor 配置元数据,生成一组类似于Kubernetes 的pod。存储:使用Direct LVM 代替Docker 默认loop 模式,增强稳定性。初步支持了Container 挂卷的Feature。依据不同的OpenStack Aggregate 设置不同的Contianer 存储空间。网络:Docker 使用OpenStack 的网络组建Neutron 网络提供Vlan 服务。Docker 配置ovs 直连和混在模式。Docker 支持安全组的添加、删除、查询、更新等操作。Switch APR Proxy 老化时间过问题,开机发送free arp。虚拟网卡TSO 的自动关闭。解决Docker 的hostname、dns、网卡名称每次都重置的问题,提供固化机制。网络限流。5. 遇到的问题5.1 幽灵容器问题我们环境中早期的Docker 是1.5版本的,在升级1.7的时候,部分container 的进程从容器逃逸,容器处于Destroyed 状态,容器进行任何stop、remove 都会出现如下报错:Container does not exist:container destroyed。这是个社区已知的问题,目前社区没有完整的解决方案。升级过程中先关闭老的容器后再升级Docker 可以避免该问题。出现问题之后要恢复相对麻烦。5.2 用户隔离不足我们测试环境中,容器密度较大。Container 新建用户对外全部映射为 UID 500或者501,出现了Resource Temporarily unavailable。CentOS 默认用户UID 从500开始,虽然ulimit 设置上限是相对独立的,但是统计已经使用资源时却是一起统计的。所以在密度较大的测试和预生产环境可能会出现这样的问题。我们的解法是在我们添加的FirstBoot 中创建一个随机UID 的用户。这样相同的镜像创建出的用户UID 也不同。大家各自统计,尽可能避免问题。5.3 NFS Server 无法启动这个问题是两个小问题:kernel 模块的reload 设置。kthreadd 创建进程。第一个问题代表了一系列问题,这个是由于因为文件系统没有kernel 的目录,模块依赖关系无从查起。通常此类服务都可以在配置文件中关闭模块的reload 过程,例如NFS 就可以配置。第二个问题是rpc.nfsd 通知kernel 去建立nfsd 服务,kernel 通过kthreadd 来创建nfsd 服务。所以nfsd 进程不会出现在Container 内部,而是暴露在宿主机上。5.4 线程数量上限" fork: Cannot allocate memory"我们的环境中出现过1次,表现为宿主机无法ssh 登录,通过IPMI Console 进行登录闪断。这个问题原因是由于某个应用的问题导致生成大量的线程,达到了系统线程的上线。我们认为:pid_max 和 threads-max 值如何设置不影响单个进程的线程数量,上限目前为32768。pid_max 和 threads-max 影响所有线程的总量,二者较小者为系统上限。超过系统上限后部分系统命令都无法使用。调整系统上限后虽然可以有更多的线程,但是太多的线程将会对系统稳定性造成影响。解决思路:环境中所有宿主机将/proc/sys/kernel/pid-max 设置为65535,并通过nagios 监控告警宿主机上的线程数量。从应用层(tomcat)限制线程上限。5.5 .device mapper discard 导致的宕机这个问题反复出现在某些服务器上,宕机重启后通过IPMI consule 进入时系统已经重新挂载了CoreDump的Kernel,看到CoreDump 生成dump 之前进行Recover 操作和Data Copying 操作,导致恢复时间很慢。通过Coredump 分析属于Kernel 在DM discard 方面的一个BUG,方法为禁用docker devicemapper 的discard。具体为设置Docker 启动参数"--storage-opt dm.mountopt=nodiscard --storage-opt dm.blkdiscard=false”。该问题已经在多个公司分享中看到,解决思路也基本一致。6. 未来Cobbler puppet in Docker 快速部署OpenStack。Magnum + Kubernetes 的微服务架构管理。Neutron 插件服务用Docker 替换 Netns。Q & AQ1:能否详细叙述一下幽灵容器问题?A:从低于1.5(包括1.5)向高于1.6及其以上进行docker daemon 过程中,如果没有关闭所有的Containe。那么当高版本Docker Daemon 启动后再次start 新的Container 时,这些Container 将无法关闭。大量操作都会报错。执行stop 或者remove 命令将会有如下报错:Server Error:Internal Server Error ("Cannot stop container XXX:[2] Container does not exist:container destroyed")Remote API 针对该Contianer的报错如下:json, stats, changes, top, logs returned valid responses;stop, pause, wait, kill reported 404 (!)复现方法:在1.5版本的Docker 中run 一个Container将docker daemon 升级为1.7重新start 该Container尝试执行stop 该 Container高版本Docker 的升级过程:当docker Daemon 非正常关闭的情况下,所有Container 首进程都会失去父进程,从而被 init 收养。此时Contaienr 内部进程逃逸。当docker Daemon 重新启动时,将会针将已经处于关闭状态的Container 原有已经逃逸的进程Kill 掉。1.5版本之前向高版本升级过程:当docker Daemon 非正常关闭的情况下,所有Container 首进程都会失去父进程,从而被 init 收养。此时Contaienr 内部进程逃逸。当docker Daemon 重新启动时,Docker Daemon 无法杀死老版本Docker 创建的现在已经逃逸的进程。当逃逸进程对应的Container 启动时,逃逸进程将会和新进程同时存在。当该Contaienr 关闭时,新进程被杀死,逃逸进程依旧存活。Container 标记Destroyed。解决方案:目前来看方案如下只能重启物理服务器来解决。由于我们内部Contianer首进程一定是Supervisor,可以先关闭Docker Daemon 后杀死全部的幽灵Supervisor 后再重启Docker Daemon 后就没问题了。预防方案还是要在升级过程中,保证关闭所有的Container,首先保证不会有逃逸进程,从而避免形成Ghost Container。Q2:Hostname DNS 贵方用什么方案固定?A:首先Container 创建之初,hostname 和DNS 都是通过Docker API 来设置的。Hostname 是nova instance 的name,DNS 是公司内部设置。如果想修改Container 默认设置也是可以的,我们在内部镜像预留了一个目录,该目录下的hosts、hostname、DNS如果存在都会在Container 启动后主动覆盖Container 外部挂载的内容。Q3:在使用Docker 去封装nova compute 模拟大规模集群测试时,运行一段时间后总出现部分使用Docker 封装的nova compute 服务出现down 的状态,不知道你们是否遇到过这样的问题?A:我们这边没有遇到,有没有可能是模拟的nova compute 进程数量过多消息有所积压。NOVA 方面考虑增加NOVA 时间戳超时设置。Docker 方面建议Docker 的网络使用host 模式,并在NOVA 配置文件中设置不同的host,以便成为不同的hypervisor node。Q4:Sahara 在使用Docker 替代KVM 创建Hadoop 集群时,是直接使用heat 创建Docker,还是使用nova-docker?Sahara 相关的代码是否需要改动,遇到过哪些坑?A:我们是使用nova docker 的driver 创建docker container 的,Sahara 本身相关的代码有部分改动,但是不大,主要改动在使用container 和虚机的差别,比如hostname、cloudinit 的部分配置等等。Q5:Docker 的网络模式中,中间添加一层linux bridge 的原因是什么,这么做是否会有性能问题?A:这个还是为了安全组,实际上我们支持配置两种模式,linux bridge 并不是默认配置的。OpenvSwitch 2.4以后可以根据流表设置安全组。Q6:Container 限速是如何实现的,是否有必要针对Container 进行限速?A:我们的环境中使用的OpenvSwitch,通过veth pair 的方式建立虚拟网络设备的关系。限速主要是使用tc,毕竟OpenvSwitch 的限速也是使用tc 做的。Q7:NOVA 组件中Docker 的高级特性无法使用你怎么看,是否使用docker api 来控制容器?A:上面已经说过这个问题了,其实通过flavor me tadata 的设置,nova docker driver 可以实现生成一组容器。nova docker 这块过去确实是直接调用Docker API 的,但是为了应对不断变化的API,我们使用了docker-py 作为Client,并在nova 配置文件中增加了API 版本的设置。从而尽可能拿到Docker 本身升级带来的福利。Q8:OPS 已经有超分设置,你设置超分的意义是什么?A:我们Docker 和KVM 都在一个openstack 平台中,而nova 的超分实在NOVA Conductor 中生效的。Nova compute Libvirt Driver 是直接上报的服务器核数。而我们认为Docker 在密度上存在比KVM 密度更高的需求,所以在Compute 上支持超分是有必要的。Q9:使用CPU share 是否会出现单个容器负载很高的场景,出现这种情况如何处理?A:还是会出现的,记得有个容器CPU 占用1600%的场景(32核心)。通常这种情况还是应用出现了问题,最简单的方法是通过cgroup 本身的命令进行限制。容器重启之后该限制就会丢失。限制方法例如:cgset -r cpuset.cpus=20-23 cpuset:/docker/91d943c55687630dd20775128e2ba70ad1a0c9145799025e403be6c2a7480cb2Q10:Docker 的监控和scale-auto 是如何实现的?A:监控方面目前主要是通docker stats api 和部分脚本来实现,集成到Zabbix中,后面会考虑使用CAdvisor。后者目前不支持,计划上会在Kubernetes 平台中支持,而非heat 或NOVA 中。毕竟这是Kubernetes、Mesos 它们的专长。Q11:你的三层镜像中,第一层和第二层都是系统层,为什么不合并成为一层?A:首先我们的第一层镜像并不是通过dockerfile 创建的,而是依据官方文档从0建立的最小的镜像,这一层是很少变动的。而第二层的设置是为上层设计的通用层,涉及到进程管理器、SSH 设置、pam 设置、入侵检测设置、开机初始化设置、还是有很大可能变动的,我们希望有关配置都应该放入dockerfile 以便管理。Q12:nova-docker 如何支持cloudinit?A:因为在novadocker 中就是完全模拟KVM 的网络模式,所以cloudinit 除了一些小幅配置变更之外没有什么特殊的。sed -e 's/disable_root./disable_root: 0/' -e 's/ssh_pwauth./ssh_pwauth: 1/' -e '/ssh_pwauth:/adatasource: OpenStack: max_wait: 120 timeout:30' cloud.cfgQ13:能否详细介绍下ARP 问题?A:由于建立的vm 的ip 之前分配给了已经删除的vm,导致mac 被记录在交换机上。数据交换经过3层,3层交换机会将mac 直接返回给ping 的一方,导致无法ping 通、启动container 后通过arping -c 3 -f -U -I eth0 172.28.19.243 -c 3开机发送免费arp来处理。Q14:NOVA Docker 实现了热迁移吗?如何做快照?A:热迁移目前还没有支持,nova docker 快照就是将容器commit 成一个镜像,然后使用glance 的接口上传glance 中。通过快照可以重新建立新的container。Q15:nova-docker 不是早在H版本就废弃了吗?你们自己维护的?A:确实废弃了,我们自己维护。不过GitHub 上有了更新,我们刚刚merge 机那里一些特性。可以再关注一下。Q16:OpenStack 如何对novadocker 环境的container 进行监控?在监控指标上是否与其他hypervisor driver 有区别?A:监控方面目前主要是通docker stats api 和部分脚本来实现,集成到Zabbix 中,后面会考虑使用CAdvisor。监控上有一些区别。主要是pid_max、docker daemon 存活,和Docker 自身存储pool 等Docker 特有的,其他方面没有太大区别。Q17:您好,贵公司只维护Git 代码和镜像容器。请问假如同一个编译环境,能编译不同操作系统版本的库吗?或者镜像。因为同一套代码会部署到不同的系统上?A:我们这条编译环境只是用来编译OPS 本身的,如果需要增加新的编译环境,我们会向Registry 推送一个新的编译镜像。Q18:glance 管理镜像和快照时有没有能用到Docker 的分层?如果有,如何利用的?A:没有,tar 包形式,compute 节点下载之后load 到compute 节点上。Q19:生产环境相比测试环境有什么不同吗?A:Docker 在CPU 超分系数不同,系统pid_max 等调优参数略有不同。Q20:Nova Docker 快照是如何实现的?A:将操作的Container commit 成为一个镜像,并上传到glance 中。原文来源:Dockerone作者:谷锎(思源科技)  推荐阅读  1、企业级OpenStack 的六大需求(1)API 高可用、管理和安全  2、企业级OpenStack 的六大需求(2):开放架构和混合云兼容  3、企业级OpenStack 的六大需求(3):弹性架构、全球交付  4、混合托管:第三代云计算  5、你所不知道的大数据、云计算,以及无法计算的价值

宝德云

--

21月前
2100

话题 为什么CIO们对云计算策略追求最终的对称性

“混合云”是企业计算的最终状态,不再有争议。几乎所有的技术专家,IT经理,分析师都认同在现代企业IT战略中既有公共云计算和本地计算。混合式的云服务终极状态并不是一种基于桥接策略或一种安慰奖性质的妥协产物,而是一种理想的结果。事实上,一个强大的混合云模式可以根据具体的用户场景作出一个最佳混合模式,具有充分的灵活性,有许多情况下,现在和未来可以基于最佳实践映射到最好的私有云或公共云。混合式云计算终极状态的实现方法有:非对称和对称。1. 不对称的方式下,在非对称的方向,一个企业消耗公共云作为一个端点,并建立一个私有云是一个明显的分离端点。例如,我们可以看一下我们的基础设施即服务(IaaS)层,在一个企业内部使用OpenStack,而在公共云的场景中AWS,通过在中间层面使用抽象的代理,帮助企业协调两种IaaS资源更好的为企业服务,无论消费请求是来自防火墙的哪一侧。在非对称混合模式下,用于私有云的技术架构和使用在公共云的技术架构不一致,导致中间代理承担必要的协调和转换工作,整体上造成资源的损耗(即两个技术可能有不同的特征和演化路径),而两者之间的细微差异点,需要被忽视或边缘化,以确保一致性。2. 对称模式;对称的混合云模式意味着私有云和公有云使用相同的技术。一个很常见的例子是平台即服务(PaaS)层,可以在私有云环境中和公有云环境都采用一样的PaaS技术平台,该平台可以跨越底层多个不同的OS以及硬件系统。PaaS平台能够把来自不同供应商的资源进行抽象,只对外暴露一些统一共性(如在定义部署策略等)。在这种情况下,PaaS是统一的平台接口,无论是内部还是外部的资源都基于统一的平台进行抽象,并在PaaS层提供服务。任何组织过程和消费过程都会对资源模型中的代理层存在的边界一无所知。混合云模式中对称和非对称模型的优点和缺点对称模型确保企业内部的任何人,都不知道消耗的云基础设施资源是来自于内部还是外部。如果云基础设施(如开发人员或数据科学家)的最终用户需要对特定的资源进行单独请求,他们将被当做意外的项目处理。这个明确的意外处理需要在云计费设计时设定更多的费用,以经济手段来确保用户进行更优的选择。例如,如果非对称部署的一个资源池比其他的更容易获得,那么最终用户会更倾向于使用该类资源,例如,用户为了响应时间更快,而大量申请本地的云资源,那么这种行为很容易导致本地资源被过量消耗,会给IT管理造成风险。重要的是要了解对称性并不意味着在一个混合云模式中,私有云资源和公有云资源在数量、架构方面完全一致,通常可以容忍小量的差异。当然,工作负载可能需要在私有云或公有云资源中进行特定申请,以满足某些要求,而反之则不可以满足。对称性保证的是对最终用户不会暴露底层资源的来源情况,系统通过设定的策略自动识别和分配适合的云计算资源。 最终对称非对称模型可能是很好的起点或适当的某些底层的基础设施堆栈,但它们并不是最终的理想状态。对称模型在几乎所有其他方面都明显优于它,虽然实现的技术难度也较大。对此,CIO们应该追求的一个最终的对称性策略。最终的对称性意味着任何云战略必须:·在可能的情况下,选择对称模型·如果非对称是目前唯一可能的方法,确保实现的方式能够在将来方便的调整到最终的对称模型。或过程和技术能够被用来优化和实现不对称架构到对称模型架构。通过建立最终的对称性为核心的云核心战略,CIO可以保证在任何时候确保消费者的资源信息是抽象的,从而隐藏资源来自公有云还是私有云等细节。  推荐阅读  1、企业级OpenStack 的六大需求(1)API 高可用、管理和安全  2、企业级OpenStack 的六大需求(2):开放架构和混合云兼容  3、企业级OpenStack 的六大需求(3):弹性架构、全球交付  4、混合托管:第三代云计算  5、你所不知道的大数据、云计算,以及无法计算的价值

上云咯

--

22月前
2099

话题 OpenStack支持哪些容器编排引擎?

容器与OpenStack是云中的两个热门技术,但是哪个容器有编排工具能与开源云平台一起工作?组织通常会使用容器编排工具,有时称为编排引擎,来部署、扩展和连接不同的容器技术组件。这些编排工具还帮助企业监控容器实例,从而缓解容器蔓延到整个企业。OpenStack Magnum模型——用于容器的OpenStack API,它支持三种主要容器编排引擎:Docker、谷歌Kubernetes和Apache Mesos。Docker是其中一个最具管理性、和流行的容器编排引擎,允许软件开发人员在一个镜像中打包并部署整个应用和他们的依赖,且可运行于Linux系统上。Docker还提供了如Docker Machine这样的工具来创新的Docker主机,Docker Compose用于组装复杂的分布式应用, Docker Swarm支持容器集群来弹性扩展基于容器的计算。谷歌Kubernetes是一个开源容器编排引擎,支持Docker容器。Kubernetes使用计算集群部署并管理容器,同时均衡工作负载来维护性能。Apache Mesos是另外一个开源容器编排引擎。它重点在于容错、在规模计算集群和支持千万个节点运行于Docker容器中。Mesos还支持工作和任务的概念。组织常常把Mesos用于类似于Marathon这样的工作系统上中,来运行工作和任务。OpenStack用户可以任意选择这三种容器编排引擎。所选择的引擎都提供可自动编排的主机系统,其内部署着容器。  推荐阅读  1、企业级OpenStack 的六大需求(1)API 高可用、管理和安全  2、企业级OpenStack 的六大需求(2):开放架构和混合云兼容  3、企业级OpenStack 的六大需求(3):弹性架构、全球交付  4、混合托管:第三代云计算  5、你所不知道的大数据、云计算,以及无法计算的价值

上云咯

--

22月前