郁闷吧 微信小程序 4188479 63242849 39070147 130690866
还没有任何记录...

懒人建站专注于网页素材下载,提供网站模板、网页设计、ps素材、图片素材等,服务于【个人站长】【网页设计师】和【web开发从业者】的代码素材与设计素材网站。

懒人建站提供网页素材下载、网站模板
这一切都是免费的!
当前位置:懒人建站 > 云计算 >

OpenStack(PDF/WORD)

来源:懒人建站 作者: 懒人建站 日期:2017-07-23 人气:
《openstack架构设计指南》一书详细介绍了openstack架构和原理,从OpenStack通用型、计算型、存储型、网络型、多区域、混合云多个解决方案出发针对性的介绍解决方案并给出OpenStack实例。

《openstack架构设计指南》一书详细介绍了openstack架构和原理,从OpenStack通用型、计算型、存储型、网络型、多区域、混合云多个解决方案出发针对性的介绍解决方案并给出OpenStack实例。
OpenStack

目录

前言 ....................................................................................................... v
约定 ............................................................................................... v
文档变更历史 ................................................................................. v
1. 介绍 ................................................................................................... 1
目标读者 ........................................................................................ 1
本书是如何组织的 .......................................................................... 1
我们为什么及如何写作此书 ............................................................ 2
方法论 ........................................................................................... 4
2. 通用型 ............................................................................................... 9
用户需求 ...................................................................................... 10
技术因素 ...................................................................................... 12
运营因素 ...................................................................................... 23
架构 ............................................................................................. 25
示例 ............................................................................................. 34
3. 计算型 .............................................................................................. 37
用户需求 ...................................................................................... 37
技术因素 ...................................................................................... 40
运营因素 ...................................................................................... 49
架构 ............................................................................................. 51
示例 ............................................................................................. 60
4. 存储型 .............................................................................................. 65
用户需求 ...................................................................................... 66
技术因素 ...................................................................................... 67
运营因素 ...................................................................................... 68
架构 ............................................................................................. 73
示例 ............................................................................................. 81
5. 网络型 .............................................................................................. 87
用户需求 ...................................................................................... 89
技术因素 ...................................................................................... 92
运营因素 ...................................................................................... 99
架构 ........................................................................................... 100
示例 ........................................................................................... 104
6. 多区域 ............................................................................................ 111
用户需求 .................................................................................... 111
技术因素 .................................................................................... 115
运营因素 .................................................................................... 118
架构 ........................................................................................... 121
示例 ........................................................................................... 123
7. 混合云 ............................................................................................ 129
用户需求 .................................................................................... 130
技术因素 .................................................................................... 135
iii架构指南
July 22, 2015
当前最新
运营因素 .................................................................................... 141
架构 ........................................................................................... 143
示例 ........................................................................................... 146
8. 可大规模扩展的类型 ....................................................................... 151
用户需求 .................................................................................... 152
技术因素 .................................................................................... 154
运营因素 .................................................................................... 156
9. 特殊场景 ........................................................................................ 159
多种类型宿主机的例子 ................................................................ 159
特殊网络应用的例子 ................................................................... 161
软件定义网络 ............................................................................. 162
桌面即服务 ................................................................................. 164
OpenStack 上的 OpenStack .......................................................... 166
专门的硬件 ................................................................................. 168
10. 参考 .............................................................................................. 171
A. 社区支持 ........................................................................................ 173
文档 ........................................................................................... 173
问答论坛 .................................................................................... 174
OpenStack 邮件列表 .................................................................... 174
OpenStack 维基百科 .................................................................... 175
Launchpad的Bug区 ...................................................................... 175
The OpenStack 在线聊天室频道 ................................................... 176
文档反馈 .................................................................................... 176
OpenStack分发包 ........................................................................ 177
术语表 ................................................................................................ 179

第 1 章 OpenStack介绍

目录

目标读者 ................................................................................................ 1
本书是如何组织的 .................................................................................. 1
我们为什么及如何写作此书 .................................................................... 2
方法论 ................................................................................................... 4
在云计算技术的“淘金热”中,OpenStack无疑是作为领导者出现的,在云
自助服务和基础设施即服务(IaaS)的市场,为形形色色的>组织发现更大的
灵活性,并加速这个市场。当然,要想知道它的全部好处,云必须要有正
确的架构设计。
一个完美的云架构可以提供一个稳定的IT环境,可轻松访问需要的资源、
基于使用的付费、按需扩充容量、灾难恢复、安全等。但是一个完美的云
架构不会拥有魔法般的自己构建。它需要对多种因素进行精心思考,无论
是技术的还是非技术的。
对于OpenStack云部署来说,还没有所谓的那个架构是“正
确”的。OpenStack可用于多种目的和场景,而每一种都有着自己独特的需
求和架构特点。
本书的初衷是着眼于使用OpenStack云的通用用例(即使不那么通用,至少
是作为好的案例)以及解释什么问题是应该去考虑的,以及为什么这么考
虑,提供丰富的知识和建议,以帮助一些组织设计和构建一个完美架构
的、满足独特需求的OpenStack云。
目标读者
本书是写给OpenStack云的架构师和设计师们。本书不是为那些打算部署
OpenStack的人们写的。关于部署和实战的指南请参考 OpenStack 实战指南
(http://docs.openstack.org/openstack-ops)。
读者需要有云计算架构和原理的知识背景,企业级系统设计经验,linux和
虚拟化经验,以及可理解基本的网络原理和协议。
本书是如何组织的
本书采用多个章节来组织,通过使用案例来帮助用户作出架构选择,
以OpenStack云安装来具体体现。每一章关注一个单一的架构以鼓励读者
1架构指南
July 22, 2015
当前最新
可随意的阅读,但是每一章包含的一些适用场景的信息也是其他章节需要
的。云架构师也许通过阅读所有的案例将此书作为一个全面的参考,但是
很可能仅重复阅读其中适合于某一案例的章节。当选择阅读挑选的使用案
例时,请记住需要阅读更多的章节,以为云制定完整的设计。本指南中覆
盖到的使用案例包括:
•通用型: 使用通用的组件构建一个云,是多数的使用案例,占80%。
•计算型: 专注于计算密集性、高负载的云,例如高性能计算(HPC)
•存储型: 用于存储密集负载的云,例如基于并行文件系统的数据分析。
•网络型: 依赖于网络的高性能和高可靠的云,例如 内容传送网络 (CDN)。
•多站点: 构建一个基于地理分布、可靠性、数据位置等原因的应用程序部
署且需多个站点可供服务的云。
•混合云: 一种多个不同的云相杂的架构,目的是提供可用性,失效切换,
防止单一云的突然崩溃。
•大规模扩展: 专注于云计算服务提供者或其他大规模扩展安装的架构。
章节 特殊用例阐释了上述所定义的使用案例中没有覆盖到的架构信息。
本指南的每一章都会分出以下小节:
•介绍:此架构使用案例的额要介绍
•用户需求:用户所考虑的内容,那些典型的在组织中起关键作用的。
•技术考虑:在实际案例中所处理的技术问题。
•实践考虑:在实际案例中和架构考虑中的那些不断的操作任务。
•架构:总体架构
•实例:架构设计被实际部署的一个或几个场景。
书中所用到的术语词汇表
我们为什么及如何写作此书
OpenStack环境从验证测试迁移到实际生产部署的速度决定着和架构设计相
关的问题的多寡。目前已经存在的文档中,都是定位在特定的部署、配置
以及实际操作的,还没有整体框架式的相关描述。
我们写作此书是希望能够给读者带来抛砖引玉的作用,让读者可以根据自
身所在的组织具体需求来设计OpenStack架构。此指南针对通用情况的使用
2
 
 
架构指南
July 22, 2015
当前最新
案例,抽取了我们认为重要的设计考虑,且根据我们的设计提供了具体的
例子。此指南的目标不是为安装和配置云提供相关介绍,是专注于那些和
用户需求密切相关的设计原理,相比技术和操作上的考虑也少了许多。在
OpenStack文档相关的板块中关于安装和配置的相关向导/指南已经有很多
资料了,寻找想要的即可。
本书是基于sprint格式书写的,sprint格式是一种针对写书的便利、
快速开发的一种方法。想得知更多信息,请访问Book Sprints官方站点
(www.booksprints.net)。
本书的写作共花了5天的时间,在2014年的7月份,中间当然历经辛勤的汗
水、激情以及合理的饮食。在帕洛阿尔托的VMware公司总部午饭时我们
庆祝了本书的完成。整个过程我们在Twitter中使用#OpenStackDesign 直
播。Faith Bosworth 和 Adam Hyde帮助我们轻松驾驭Book Sprint。
我们非常感谢VMware的盛情款待,以及我们的雇主,Cisco,
Cloudscaling,Comcast,EMC,Mirantis,Rackspace,Red Hat, Verizon和VMware,能
够让我们花时间做点有意义的事情。尤其感谢Anne Gentle 和 Kenneth Hui,
由于二位的领导和组织,才有此书诞生的机会。
作者团队成员有:
•Kenneth Hui (EMC) @hui_kenneth
•Alexandra Settle (Rackspace) @dewsday
•Anthony Veiga (Comcast) @daaelar
•Beth Cohen (Verizon) @bfcohen
•Kevin Jackson (Rackspace) @itarchitectkev
•Maish Saidel-Keesing (Cisco) @maishsk
•Nick Chase (Mirantis) @NickChase
•Scott Lowe (VMware) @scott_lowe
•Sean Collins (Comcast) @sc68cal
•Sean Winn (Cloudscaling) @seanmwinn
•Sebastian Gutierrez (Red Hat) @gutseb
•Stephen Gordon (Red Hat) @xsgordon
•Vinny Valdez (Red Hat) @VinnyValdez
3
 
 
架构指南
July 22, 2015
当前最新
方法论
云的魅力在于它可以干任何事。无论从健壮性还是灵活性,都是这个世界
上目前来说最好的。是的,云具有很高的灵活性,且可以做几乎任何事,
但是想要充分发挥云的威力,定义好云将如何使用是非常重要的,否则创
建和测试的使用案例意义就不复存在。此章讲述的是那些设计最适合、用
户最关注的云架构背后的思考过程。
上图展示了在获取用户需求和构建使用案例过程中的抽象流程。一旦用例
被定义,它就可以被用于设计云的架构。
用例选择规划看起来是反直觉的,比如,使用Amazon的服务,从注册到
使用也就是花5分钟的时间而已。难道Amazon真的不关心用户的计划?错
了,Amazon的产品管理部门花了大量的时间去研究吸引他们典型用户的究
竟是什么,也在琢磨着交付更好的服务。对于企业来说,计划的流程没有
什么不同,只是不会去规划外部的付费用户罢了,举例来说,用户仅仅是
内部的应用程序开发者或者是web门户。下面所列的目标在考虑创建用例时
用的到。
总体业务目标
•开发务必清晰定义,符合业务目标和需求
•增加项目的支持,积极的和业务相关人员、客户以及最终用户保持沟
通。

4架构指南

July 22, 2015
当前最新

技术

•协调OpenStack架构中各个项目,努力的通过社区获得更多的支持。
•为自动化设计好的架构可大大的加速开发和部署。
•使用恰当的工具可增加开发的效率。
•创建更好的、更多的测试指标和测试工具,以支持开发的持续集成、测
试流程和自动化。

组织

•选用好多消息工具,良好的管理支持团队。
•增强文化氛围,诸如对于开源的理解,云架构,敏捷开发,持续开发/测
试/集成等,总而言之,涉及到开发的所有环节都需要。
举例来说明上述的一切,想想一个业务目标是将其公司的电子商务站点使
用云来构建。此目标意味着应用程序将要支持每秒成千上万的会话,各种
负载以及大量复杂和瞬息完变的数据。通过识别诸如每秒并发事务,数据
库的大小等关键指标,相信构建出一个基于假设的测试方法是可行的。
基于用户场景开发功能. 基于用户场景开发功能,可轻松开发测试用例,
即可在项目的整个过程中有个掂量。假如组织没有准备好一个应用,或者
没有准备好一个用于开发用户需求的应用,那么就需要创建需求,以构建
合适的测试工具和开发可用的指标。一旦指标确认,即使遇到需求变更,
也可轻松面对快速变化,而且无须过度担心提前具体需求。将此类比于使
用创新的方法配置系统,不能因为需求的变化而每次都重新设计。
云的局限特性集. 建立需求是发掘用户痛点,而不是重新创建OpenStack
已经有的工具集。认为建立OpenStack的只有一种好办法,那只能弄巧成
拙。在开发一个平台中通过限制集中带来的慢速是非常重要的,因为它会
导致需求转变为处理工具本身,所以请不要重新创建一整套的工具。欲成
功的部署云,与技术产品负责人一起建立关键功能显得不可或缺。
为云准备好应用程序
尽管云被设计出来是让事情变得更简单,但是要意识到“使用云”不仅仅
是建立一个实例然后将应用丟进去就这么简单是非常重要的。这种一夜之
间平地起高楼的事情是需要确定的情况的,要明白在云和过去的基于服务
器硬件环境以及过去虚拟化环境是有着本质上的区别的。
在过去的环境中,还有那些过去的企业级应用,服务器和应用的运行都是
被当作“宠物”看待的,他们被精心的照看和爱护,甚至每台服务器都有

5架构指南

July 22, 2015
当前最新
自己的名字如“甘道夫“或”哆啦唉梦“,一旦他们生病了,则需要人去护
理直到恢复健康。所有的这些设计表明应用是不可以停止。
在云的环境中,打个比方,服务器更像是牛群中的某一头牛。它们太多
了,成千上万,命名的方式可能是类似的编号 NY-1138-Q,如果它们中的一
个出问题了,管理员会直接抛弃它,再重新安装和启动一个即可。遗留的
应用还没有准备好运行在此云环境中,所以很自然的会遭遇停运,丢失数
据,甚至更加糟糕的。
在为云设计应用还有另外一些原因需要注意。一些是防御性的,例如一些
应用并不能准确的确定在什么地方或什么样的硬件去启动,所以他们需要
灵活性,即使做不到至少应该保持适应性更强。另外一些则是主动性的,
例如,使用云的一个优点是其有高扩展性,所以应用需要被设计的能够使
用这些优点,当然云还有更多的优点,也得一并考虑。
决定那些应用程序是可在云中运行
寻找适合于在云中运行的应用,还是有几种方法可以考虑的。

结构

那些大型的、单层次的、铁板一块的旧的应用是非常典型的不适
合云环境的。将负载分割为多个实例会获得高效,所以部分系统
失效不会特别影响其他部分的系统,或者说随应用的需要而横向
扩展。

依赖

如果应用程序依赖特别的硬件,比如特别的芯片或者是类似指
纹识别等外设,是不适合于云计算的。除非使用特别的方式来实
现。同样的,如果应用依赖于操作系统或一组程序库不能用于云
环境,或者无法在虚拟化环境中运行,这就真的成了问题了。

连通性

自包含的应用或它们所依赖的资源在云的环境无法实现,将无法
运行。也许在一些情况下,通过自定义网络解决了这些问题,但
是运行是否良好还得看选择云的环境。

耐久性和弹性

尽管有服务水平协议(SLA)的存在,但是还是会有一些坏的事情发
生:服务器宕机,网络连接发生紊乱,多个租户无法访问服务。
应用程序必须足够的稳固,以应对上述事情的发生。

设计云

这里有一些原则忠告,在为一个应用设计云的时候请时刻铭记:
•做一个悲观主义者:承担一切失败,基于目标选择手段。善待那些将系
统搞坏的程序。
•将鸡蛋放在多个篮子里:考虑多个供应商,基于地理分区不同的数据中
心,多可用的zones以容纳本地存在的隐患。可移植性的设计。

6架构指南

July 22, 2015
当前最新
•考虑效率:低效的设计将不可扩展。高效的设计可以无须花费多少钱即
可轻松扩展。去掉那些不需要的组件或容量。
•保持偏执:深度设计防御,通过构建在每一层和每个组件之间的安全确

保零差错。不信任任何人。

•但是也不要太偏执:不是所有的应用都需要钻石级的解决方案。为不同
的服务水平协议、不同的服务层和安全级别等分别设计不同的架构。
•管理数据:数据通常是最为灵活的也最复杂的一块,尤其是在云中或云
集成的架构中。要在分析和传送数据付出更多的努力。
•放手:自动化可以增加一致性、质量以及减少响应的时间。
•分离和征服:尽可能分区和并行的分层。尽可能的确保组件足够小且可
移植。在层之间使用负载均衡。
•保持弹性:随着增加的资源,确保结果是增加的性能和扩展。减少资源
要没有负面影响。
•保持动态:激活动态配置变化诸如自动扩展,失效恢复,资源发现等,
以适应变化的环境,错误的发生以及负载的变化。
•贴近原则:通过移动高度密切的组件和相似数据靠近以减少延迟。
•保持松散:松耦合,服务接口,分离关注度高的点,抽象并定义好的应
用程序接口,交付灵活。
•注意开销:自动扩展,数据传输,虚拟软件许可证,保留的实例等等均
会快速增加每月的使用支出。密切监测使用情况。

第 2 章 通用型
目录
用户需求 .............................................................................................. 10
技术因素 .............................................................................................. 12
运营因素 .............................................................................................. 23
架构 ..................................................................................................... 25
示例 ..................................................................................................... 34
OpenStack通用型云通常被认为是构建一个云的起点。它们被设计为平衡的
组件以及在整体的计算环境中不强调某个特定的领域。云的设计必须对计
算、网络、存储等组件作必要的公平权衡。通用型云可以是私有云,也可
以是公有云,当然也可以混合的环境,自身可以适用于各种用例。
注意
通用型云基于很普通的部署,不适用于特殊的环境或边缘案例
的情况。
通常使用通用性的云包括:
•提供一简单的数据库
•一个web应用程序运行时环境
•共享的应用开发平台
•测试实验平台
在通用型云架构中,用例能够明确感受到横向扩展带来好处远远大于纵向
扩展。
通用型云被设计为有一系列潜在用途或功能,不是为特殊的用例特殊设
计。通用型架构是为满足80%用例而设计的。基础设施其本身就是一非常特
别的用例,在设计过程将之用于基本模型未尝不可。通用型云被设计为适
合通用应用的平台。
通用型云被限制在了大部分的基本组件,但是可以包含下面增加的资源,
例如:
•虚拟机磁盘镜像库
9架构指南
July 22, 2015
当前最新
•Raw 块存储
•文件或对象存储
•防火墙
•负载均衡器
•IP 地址
•网络覆盖或者(VLANs)
•软件集合
用户需求
当构建通用型云时,用户需要遵循 Infrastructure-as-a-Service (IaaS)模
式,基于简单的需求为用户寻求最合适的平台。通用型云的用户需求并不
复杂。尽管如此,也要谨慎对待,即使项目是较小的业务,或者诸如概念
验证、小型实验平台等技术需求。
注意
以下用户考量的内容来自于云构建者的记录,并非最终用户。
成本 财务问题对任何组织来说都是头等大事。开销是一个重要的标准,
通用型云以此作为基本,其它云架构环境以此作为参考。通用型云
一般不会为特殊的应用或情况提供较划算的环境,除非是不赚钱或
者成本已经定了,当选择或设计一个通用架构时开销才不是唯一考
虑的。
上线 当构建一个通用型云时,有能力在灵活的时间内交付服务或产品,
时间 是业务普遍的一个情形。在今天高速发展的商务世界里,拥有在6
个月内交付一款产品去替代2年完成的能力,这驱动着背后的决策
者们决定构建通用型云。通用型云实现用户自服务,按需求获得访
问计算、网络、存储资源,这将大大节省上线时间。
赢利 赢利空间对于云来说是个最基本的义务。一些通用型云为商业客户
空间 构建产品,但也有替代品,可能使通用云的正确选择。例如,一个
小型的云服务提供商(CSP)会构建一个通用云而放弃大规模的扩展
云,也许是因为没有足够的财力支撑,有或许是因为无法得知客户
使用云的目的是什么。对于一些用户来说,高级云本身就意味着赢
利。但是另外一些用户,通用型云所提供的基本功能会阻碍使用,
导致潜在的收入机会的停滞。
10架构指南
July 22, 2015
当前最新
法律需求
很多辖区对于云环境中的数据的保管及管理都有相关的法律上或者监管上
的要求。这些规章的常见领域包括:
•确保持久化数据的保管和记录管理以符合数据档案化需求的数据保留政
策。
•管理数据的所有权和责任的数据所有权政策。
•管理位于外国或者其它辖区的数据存储问题的数据独立性政策。
•数据合规性-基于常规某些类型的数据需要放在某些位置,同样的原因,
不能放在其他位置更加的重要。
Examples of such legal frameworks include the data protection framework
of the European Union and the requirements of the Financial Industry
Regulatory Authority in the United States. Consult a local regulatory
body for more information.
技术需求
技术云架构需求相比业务需求,比重占得更多一些。
性能 作为基础产品,通用型云并不对任何特定的功能提供优化
性能。虽然通用型云希望能够提供足够的性能以满足所以
用户的考虑,但是性能本身并不是通用型云所关注的。
非预先定义的 由于缺少预先定义的使用模型,导致用户在根本不知道应
使用模型
用需求的情况运行各式各样的应用。这里(OpenStack 通
用型云,译者注)提供的独立性和灵活性的深度,也就只
能是这么多了,不能提供更多的云场景。
按需或自服务 根据定义,云提供给最终用户通过简单灵活的方式自适应
应用
的计算能力、存储、网络和软件的能力。用户必须能够在
不破坏底层主机操作的情况下扩展资源到满足自身。使用
通用型云架构的一个优点就是,在有限的资源下启动,随
着时间的增加和用户的需求增长而轻松扩张的能力。
公有云
对于一家公司对基于OpenStack构建一个商业公有云有兴趣
的话,通用型架构模式也许是最好的选择。设计者毋须知
道最终用户使用云的目的和具体负载。
内部消费(私
有)云
组织需要决定在内部建立自己的云的逻辑。私有云的使
用,组织需要维护整个架构中的控制点以及组件。
11架构指南
July 22, 2015
当前最新
注意
用户打算既使用内部云又可访问外部云的组
合。假如遇到类似的用例,也许值得一试的
就是基于多个云的途径,考虑至少多个架构要
点。
设计使用多个云,例如提供一个私有云和公有云的混合,
有关“多云”的描述场景,请参考第 6 章 多区域 [111]。
安全性
安全应根据资产,威胁和脆弱性风险评估矩阵来实现。对
于云领域来说,更加增加了计算安全、网络安全和信息安
全等的需求。通用型云不被认为是恰当的选择。
技术因素
通用型云通常实现所包括的基本服务:
•计算
•网络
•存储
这些服务中的每一个都有不同的资源需求。所以,提供所有服务意味着提
供平衡的基础设施,直接关系到最终的服务,依据这些作出设计决定是非
常重要的。
考虑到每个服务的不一致方面,需要设计为分离的因素,服务的复杂性,
都会影响到硬件的选择流程。硬件的设计需要根据下列不同的资源池生成
不同的配置,
•计算
•网络
•存储
许多额外的硬件决策会影响到网络的架构和设施的规划。这些问题在
OpenStack云的整个架构中扮演非常重要的角色。
规划计算资源
当设计计算资源池时,有很多情形会影响到用户的设计决策。例如,和每
种hypervisor相关的处理器、内存和存储仅仅是设计计算资源时考虑的一
12架构指南
July 22, 2015
当前最新
个因素。另外,将计算资源用户单一的池还是用户多个池也是有必要考虑
的,我们建议用户设计将计算资源设计为资源池,实现按需使用。
一个计算设计在多个池中分配资源,会使云中运行的应用资源利用的最为
充分。每个独立的资源池应该被设计为特定的类型的实例或一组实例提
供服务,设计多个资源池可帮助确保这样,当实例被调度到hypervisor节
点,每个独立的节点资源将会被分配到最合适的可用的硬件。这就是常见
的集装箱模式。
使用一致的硬件来设计资源池中的节点对装箱起到积极作用。选择硬件节
点当作计算资源池的一部分最好是拥有一样的处理器、内存以及存储类
型。选择一致的硬件设计,将会在云的整个生命周期展现出更加容易部
署、支持和维护的好处。
OpenStack支持配置资源超分配比例,即虚拟资源比实际的物理资源,目前
支持CPU和内存。默认的CPU超分配比例是16:1,默认的内存超分配比例是
1.5:1。在设计阶段就要想要是否决定调整此超分配比例,因为这会直接
影响到用户计算节点的硬件布局。
举例说明,想像一下,现在有一个m1.small类型的实例,使用的是1
vCPU,20GB的临时存储,2048MB的内存。当设计为此类实例提供计算资
源池的硬件节点时,考虑节点需要多少个处理器、多大的磁盘、内存
大小才可以满足容量需求。对于一个有2颗10个核的CPU,并开启超线程
的服务器,基于默认的CPU超分配比例16:1来计算的话,它总共能运行
640(2x10x2x16)个m1.small类型的实例。同样,基于默认的内存超分配比例
1.5:1来计算的话,用户则需要至少853GB(640x2048/1.5x1048)内存。当基
于内存来丈量服务器节点时,考虑操作系统本身和其服务所需要使用的内
存也是非常重要的。
处理器的选择对于硬件设计来讲实在是太过重要了,尤其是对比不同处理
器之间的特性和性能。一些近来发布的处理器,拥有针对虚拟化的特性,
如硬件增强虚拟化,或者是内存分页技术(著名的EPT影子页表)。这些特性
对于在云中运行的虚拟机来说,有着非常关键的影响。
考虑到云中计算需求的资源节点也是很重要的,资源节点即非hypervisor
节点,在云中提供下列服务:
•控制器
•对象存储
•块存储
•联网服务
13架构指南
July 22, 2015
当前最新
处理器核数和线程数和在资源节点可以运行多少任务线程是有直接关联
的。结果就是,用户必须作出设计决定,直接关联的服务,以及为所有服
务提供平衡的基础设施。
在通用型云中负载是不可预测的,所以能将每个特别的用例都做到胸有成
竹是非常困难的。在未来给云增加计算资源池,这种不可预测是不会带来
任何问题的。在某些情况下,在确定了实例类型的需求可能不足以需要单
独的硬件设计。综合来看,硬件设计方案是先满足大多数通用的实例来启
动的,至于以后,寻求增加额外的硬件设计将贯穿整个多样的硬件节点设
计和资源池的架构。
规划网络资源
传统的OpenStack云是有多个网段的,每个网段都提供在云中访问不仅是
操作人员还可以是租户的资源。此外,网络服务本身也需要网络通讯路径
以和其他网络隔离。当为通用型云设计网络服务时,强烈建议规划不论是
物理的还是逻辑的都要将操作人员和租户隔离为不同的网段。进一步的建
议,划分出另外一个网段,专门用于访问内部资源,诸如消息队列、数据
库等各种云服务。利用不同网段隔离这些服务对于保护敏感数据以及对付
没有认证的访问很有帮助。
基于云中实例提供的服务的需求,网络服务的选择将会是影响用户设计架
构的下一个决定。
在作为OpenStack计算组件的部分遗留网络(nova-network)和OpenStack网络
(neutron)之间作出选择,会极大的影响到云网络基础设施的架构和设计。
传统联网方式(nova-
network)
遗留的网络服务(nova-network)主要是一个
二层的网络服务,有两种模式的功能实现。
在遗留网络中,两种模式的区别是它们使用
VLAN的方式不同。当使用遗留网络用于浮动
网络模式时,所有的网络硬件节点和设备通
过一个二层的网段来连接,提供应用数据的
访问。
当云中的网络设备可通过VLANs支持分段时,
遗留网络的第二种模式就可操作了。此模式
中,云中的每个组户都被分配一个网络子
网,其是映射到物理网络的VLAN中的。尤其
重要的一点,要记得在一个生成树域里VLANs
的最大数量是4096.在数据中心此限制成为
了可能成长的一个硬性限制。当设计一个支
持多租户的通用型云时,特别要记住使用和
VLANs一起使用遗留网络,而且不使用浮动网
络模式。
14架构指南
July 22, 2015
当前最新
另外的考虑是关于基于遗留网络的网络的管理是由云运维人员负责的。租
户对网络资源没有控制权。如果租户希望有管理和创建网络资源的能力,
如创建、管理一个网段或子网,那么就有必要安装OpenStack网络服务,以
提供租户访问网络。
OpenStack 网络 (neutron)
OpenStack网络 (neutron) 是第一次实现
为租户提供全部的控制权来建立虚拟网络
资源的网络服务。为了实现给租户流量分
段,通常是基于已有的网络基础设施来封
装通信路径,即以隧道协议的方式。这些
方法严重依赖与特殊的实现方式,大多数
通用的方式包括GRE隧道,VXLAN封 装以及
VLAN标签。
首先建议的设计是至少划分三个网段,第一个是给租户和运维人员用于访
问云的REST 应用程序接口。这也是通常说的公有网络。在多数的用例中,
控制节点和swift代理是唯一的需要连接到此网段的设备。也有一些用例
中,此网段也许服务于硬件的负载均衡或其他网络设备。
第二个网段用于云管理员管理硬件资源,也用于在新的硬件上部署软件和
服务的配置管理工具。在某些情况下,此网段也许用于内部服务间的通
信,包括消息总线和数据库服务。介于此网段拥有高度安全的本质,需要
将此网络设置为未经授权不得访问。此网段在云中的所有硬件节点需要互
联互通。
第三个网段用于为应用程序和消费者访问物理网络,也为最终用户访问云
中运行的应用程序提供网络。此网络是隔离能够访问云API的网络,并不能
够直接和云中的硬件资源通信。计算资源节点需要基于此网段通信,以及
任何的网络网关服务将允许应用程序的数据可通过物理网络到云的外部。
规划存储资源
OpenStack有两个独立的存储服务需要考虑,且每个都拥有自己特别的设
计需求和目标。除了提供存储服务是他们的主要功能之外,在整个云架构
中,需要额外考虑的是它们对计算/控制节点的影响。
规划OpenStack对象存储
当为OpenStack对象存储设计硬件资源时,首要的目标就尽可能的为每个资
源节点加上最多的存储,当然也要在每TB的花费上保持最低。这往往涉及
到了利用服务器的容纳大量的磁盘。无论是选择使用2U服务器直接挂载磁
盘,还是选择外挂大量的磁盘驱动,主要的目标还是为每个节点得到最多
的存储。
15架构指南
July 22, 2015
当前最新
我们并不建议为OpenStack对象存储投资企业级的设备。OpenStack对象存
储的一致性和分区容错保证的数据的更新,即使是在硬件损坏的情况下仍
能保证数据可用,而这都无须特别的数据复制设备。
OpenStack对象存储一个亮点就是有混搭设备的能力,基于swift环的加权
机制。当用户设计一个swift存储集群时,建议将大部分>的成本花在存储
上,保证永久可用。市场上多数的服务器使用4U,可容纳60块甚至更多的
磁盘驱动器,因此建议在1U空间内置放最多的驱动器,就是最好的每TB花
费。进一步的建议,在对象存储节点上没必要使用RAID控制器。
为了实现数据存储和对象一样的持久和可用,设计对象存储资源池显得非
常的重要,在硬件节点这层之外的设计,考虑机柜层或区域层是非常重要
的,在对象存储服务中配置数据复制多少份保存(默认情况是3份)。每份
复制的数据最好独立的可用区域中,有独立的电源、冷却设备以及网络资
源。
对象存储节点应该被设计为在集群中不至于区区几个请求就拖性能后腿的
样子。对象存储服务是一种频繁交互的协议,因此确定使用多个处理器,
而且要多核的,这样才可确保不至于因为IO请求将服务器搞垮。
规划OpenStack块存储
当设计OpenStack块存储资源节点时,有助于理解负载和需求,即在云中使
用块存储。由于通用型云的使用模式经常是未知的。在>此建议设计块存储
池做到租户可以根据他们的应用来选择不同的存储。创建多个不同类型的
存储池,得与块存储服务配置高级的存储调度相结合,才可能为租户提供
基于多种不同性能级别和冗余属性的大型目录存储服务。
块存储还可以利用一些企业级存储解决方案的优势。由硬件厂商开发的插
件驱动得以实现。基于OpenStack块存储有大量的企业存储写了它们带外的
插件驱动(也有很大一部分是通过第三方渠道来实现的)。作为通用型云使
用的是直接挂载存储到块存储节点,如果未来需要为租户提供额外级别的
块存储,只须增加企业级的存储解决方案即可。
决定在块存储节点中使用RAID控制卡主要取决于应用程序对冗余和可用性
的需求。应用如果对每秒输入输出(IOPS)有很高的要求,不仅得使用RAID控
制器,还得配置RAID的级别值,当性能是重要因素时,建议使用高级别的
RAID值,相对比的情况是,如果冗余的因素考虑更多谢,那么就使用冗余
RAID配置,比如RAID5或RAID6。一些特殊的特性,例如自动复制块存储卷,
需要使用第三方插件和企业级的块存储解决方案,以满足此高级需求。进
一步讲,如果有对性能有极致的要求,可以考虑使用告诉的SSD磁盘,即高
性能的flash存储解决方案。
16架构指南
July 22, 2015
当前最新
软件选择
软件筛选的过程在通用型云架构中扮演了重要角色。下列的选择都会在设
计云时产生重大的影响。
•选择操作系统
•选择OpenStack软件组件
•选择Hypervisor
•选择支撑软件
操作系统(OS)的选择在云的设计和架构中扮演着重要的角色。有许多操作
系统是原生就支持OpenStack的,它们是:
•Ubuntu
•红帽企业Linux(RHEL)
•CentOS
•SUSE Linux Enterprise Server (SLES)
注意
原生并非是限制到某些操作系统,用户仍然可以自己选择
Linux的任何发行版(甚至是微软的Windows),然后从源码安装
OpenStack(或者编译为某个发行版的包)。尽管如此,事实上多
数组织还是会从发行版支持的包或仓库去安装OpenStack(使用
分发商的OpenStack软件包也许需要他们的支持)。
操作系统的选择会直接影响到hypervisor的选择。一个云架构会选择
Ubuntu,RHEL,或SLES等,它们都拥有灵活的hypervisor可供选择,同时也被
OpenStack 计算(nova)所支持,如KVM,Xen,LXC等虚拟化。一个云架构若选择
了Hyper-V,那么只能使用Windows服务器版本。同样的,一个云架构若选择
了XenServer,也限制到基于CenOS dom0操作系统。
影响操作系统-hypervisor选择的主要因素包括:
用户 选择操作系统-虚拟机管理程序组合,首先且最重要的是支持用户的
需求 需求。
支持 选择操作系统-虚拟机管理程序组合需要OpenStack支持。
互操 在OpenStack的设计中,为满足用户需求,需要操作系统的
作性 hypervisor在彼此的特性和服务中要有互操作性。
17架构指南
July 22, 2015
当前最新
虚拟机管理程序
OpenStack支持多种Hypervisor,在单一的云中可以有一种或多种。这些
Hypervisor包括:
•KVM (and QEMU)
•XCP/XenServer
•vSphere (vCenter and ESXi)
•Hyper-V
•LXC
•Docker
•裸金属
支持hypervisor和它们的兼容性的完整列表可以从
通用型云须确保使用的hypervisor可以支持多数通用目的的用例,例如KVM
或Xen。更多特定的hypervisor需要根据特定的功能和支持特性需求来做出
选择。在一些情况下,也许是授权所需,需要运行的软件必须是在认证的
hpervisor中,比如来自VMware,微软和思杰的产品。
通过OpenStack云平台提供的特性决定了选择最佳的hyperviosr。举个例
子,要使通用型云主要支持基于微软的迁移,或工作人员>所管理的是需要
特定技能的去管理hypervisor或操作系统,Hyper-V也许是最好的选择。即
使是决定了使用Hyper-V,这也并不意味着不可以去管理相关的操作系统,
要记得OpenStack是支持多种hypervisor的。在设计通用型用时需要考虑到
不同的hypervisor有他们特定的硬件需>求。例如欲整合VMware的特性:活
迁移,那么就需要安装安装vMotion,给ESXi hypervisor所使用的VCenter/
vSphere,这即是增加的基础设施需求。
在混合的hypervisor环境中,等于聚合了计算资源,但是各个hypervisor定
义了各自的能力,以及它们分别对软、硬件特殊的需求等。这些功能需要
明确暴露给最终用户,或者通过为实例类型定义的元数据来访问。
OpenStack 组件
通用型OpenStack云的设计,使核心的OpenStack服务的互相紧密配合为最
终用户提供广泛的服务。在通用型云中建议的OpenStack核心服务有:
•OpenStack 计算 (nova)
•OpenStack 网络 (neutron)
18架构指南
July 22, 2015
当前最新
•OpenStack 镜像服务 (glance)
•OpenStack 认证 (keystone)
•OpenStack 仪表盘 (horizon)
•Telemetry module (ceilometer)
通用型云还包括OpenStack 对象存储 (swift).。选择OpenStack 块存储
(cinder) 是为应用和实例提供持久性的存储,
注意
尽管如此,依赖于用例,这些是可选。
增强软件
通用型OpenStack的软件部署不仅仅是OpenStack特定的组件。一个典
型的部署,如提供支撑功能的服务,须包含数据库,消息队列,以及为
OpenStack环境提供高可用的软件。设计的决定围绕着底层的消息队列会
影响到控制器服务的多寡,正如技术上为数据库提供高弹性功能,例如在
MariaDB之上使用Galera。在这些场景中,服务的复制依赖于预订的机器
数,因此,考虑数据库的 节点,例如,至少需要3个节点才可满足Galera节
点的失效恢复。随着节点数量的增加,以支持软件的特性,考虑机柜的空
间和交换机的端口显得非常的重要。
多数的通用型部署使用硬件的负载均衡来提供API访问高可用和SSL终端,
但是软件的解决方案也要考虑到,比如HAProxy。至关重要的是软件实
现的高可用也很靠谱。这些高可用的软件Keepalived或基于Corosync的
Pacemaker。Pacemaker和Corosync配合起来可以提供双活或者单活的
高可用配置,至于是否双活取决于OpenStack环境中特别的服务。使用
Pacemaker会影响到设计,假定有至少2台控制器基础设施,其中一个节点
可在待机模式下运行的某些服务。
Memcached是一个分布式的内存对象缓存系统,Redia是一个key-value存储
系统。在通用型云中使用这两个系统来减轻认证服务的负载。memcached
服务缓存令牌,基于它天生的分布式特性可以缓减授权系统的瓶颈。使用
memcached或Redis不会影响到用户的架构设计,虽然它们会部署到基础设
施节点中为OpenStack提供服务。
性能
OpenStack的性能取决于和基础设施有关的因素的多少以及控制器服务的多
少。按照用户需求性能可归类为通用网络性能,计算资源性能,以及存储
系统性能。
19架构指南
July 22, 2015
当前最新
控制器基础设施
控制器基础设施节点为最终用户提供的管理服务,以及在云内部为运维提
供服务。控制器较典型的现象,就是运行消息队列服务,在每个服务之间
携带传递系统消息。性能问题常和消息总线有关,它会延迟发送的消息到
应该去的地方。这种情况的结果就是延迟了实际操作的功能,如启动或删
除实例、分配一个新的存储卷、管理网络资源。类似的延迟会严重影响到
应用的反应能力,尤其是使用了自动扩展这样的特性。所以运行控制器基
础设施的硬件设计是头等重要的,具体参考上述硬件选择一节。
控制器服务的性能不仅仅限于处理器的强大能力,也受限于所服务的并发
用户。确认应用程序接口和Horizon服务的负载测试可以>承受来自用户客
户的压力。要特别关注OpenStack认证服务(Keystone)的负载,Keystone为
所有服务提供认证和授权,无论是最终用户还是OpenStack的内部服务。如
果此控制器服务没有正确的被设计,会导致整个环境的性能低下。
网络性能
通用型OpenStack云,网络的需求其实帮助决定了其本身的性能能力。
例如,小的部署环境使用千兆以太网(GbE),大型的部署环境或者许多用
户就要求使用10 GbE。运行着的实例性能收到了它们的速度限制。设计
OpenStack环境,让它拥有可以运行混合网络的能力是可能的。通过利用不
同速度的网卡,OpenStack环境的用户可以选择不同的网络去满足不同的目
的。
例如,web应用的实例在公网上运行的是OpenStack网络中的1 GbE,但是
其后端的数据库使用的是OpenStack网络的10 GbE以复制数据,在某些情况
下,为了更大的吞吐量使用聚合链接这 样的设计。
网络的性能可以考虑有硬件的负载均衡来帮助实现,为云抛出的API提供前
端的服务。硬件负载均衡通常也提供SSL终端,如果用户的环境有需求的
话。当实现SSL减负时,理解SSL减负的能力来选择硬件,这点很重要。
计算主机
为计算节点选择硬件规格包括CPU,内存和磁盘类型,会直接影响到实例的
性能。另外直接影响性能的情形是为OpenStack服务优化参数,例如资源的
超分配比例。默认情况下OpenStack计算设置16:1为CPU的超分配比例,内
存为1.5:1。运行跟高比例的超分配即会导致有些服务无法启动。调整您的
计算环境时,为了避免这种情况下必须小心。运行一个通用型的OpenStack
环境保持默认配置就可以,但是也要检测用户的环境中使用量的增加。
20架构指南
July 22, 2015
当前最新
存储性能
当考虑OpenStack块设备的性能时,硬件和架构的选择就显得非常重要。块
存储可以使用企业级后端系统如NetApp或EMC的产品,也可以使用横向扩展
存储如GlusterFS和Ceph,更可以是简单的在节点上直接附加的存储。块存
储或许是云所关注的贯穿主机网络的部署,又或许是前端应用程序接口所
关注的流量性能。无论怎么,都得在控制器和计算主机上考虑使用专用的
数据存储网络和专用的接口。
当考虑OpenStack对象存储的性能时,有几样设计选择会影响到性能。用户
访问对象存储是通过代理服务,它通常是在硬件负载均衡之后。由于高弹
性是此存储系统的天生特性,所以复制数据将会影响到整个系统的性能。
在此例中,存储网络使用10 GbE(或更高)网络是我们所建议的。
可用性
在OpenStack架构下,基础设施是作为一个整体提供服务的,必须保证可用
性,尤其是建立了服务水平协议。确保网络的可用性,在完成设计网络架
构后不可以有单点故障存在。考虑使用多个交换机、路由器以及冗余的电
源是必须考虑的,这是核心基础设施,使用bonding网卡、提供多个路由、
交换机高可用等。
OpenStack自身的那些服务需要在跨多个服务器上部署,不能出现单点故
障。确保应用程序接口的可用性,作为多个OpenStack服务的成员放在高可
用负载均衡的后面。
OpenStack其本身的部署是期望高可用的,实现此需要至少两台服务器来完
成。他们可以运行所有的服务,由消息队列服务连接起来,消息队列服务
如RabbitMQ或QPID,还需要部署一个合适的数据库服务如MySQL或MariaDB。
在云中所有的服务都是可横向扩展的,其实后端的服务同样需要扩展。检
测和报告在服务器上的使用和采集,以及负载测试,都可以帮助作出横向
扩展的决定。
当决定网络功能的时候务必小心谨慎。当前的OpenStack不仅支持遗留网络
(nova-network)系统还支持新的,可扩展的OpenStack网络(neutron)。二者
在提供高可用访问时有各自的优缺点。遗留网络提供的网络服务的代码是
由OpenStack计算来维护的,它可提供移除来自路由的单点故障特性,但是
此特性在当前的Openstack网络中不被支持。遗留网络的多主机功能受限于
仅在运行实例的主机,一旦失效,此实例将无法被访问。
另一方面,当使用OpenStack网络时,OpenStack控制器服务器或者是分离
的网络主机掌控路由。对于部署来说,需要在网络中满足此特性,有可能
使用第三方软件来协助维护高可用的3层路由。这么做允许通常的应用程
序接口来控制网络硬件,或者基于安全的行为提供复杂多层的web应用。从
21架构指南
July 22, 2015
当前最新
OpenStack网络中完全移除路由是可以的,取而代之的是硬件的路由能力。
在此情况下,交换基础设施必须支持3层路由。
OpenStack网络和遗留网络各有各的优点和缺点。它们有
效的和支持的属性适合不同的网络部署模式,详细描述
见\"http://docs.openstack.org/openstack-ops/content/
network_design.html#network_deployment_options">OpenStack
确保用户的部署有足够的后备能力。举例来说,部署是拥有两台基础设施
的控制器节点,此设计须包括控制器可用。一旦丢失单个控制器这种事件
发生,云服务将会停止对外服务。当有高可用需求的设计时,解决此需求
的办法就是准备冗余的、高可用的控制器节点。
应用程序的设计也必须记入到云基础设施的能力之中。如果计算主机不能
提供无缝的活迁移功能,就必须预料到一旦计算节点失效,运行在其上
的实例,以及其中的数据,都不可访问。反过来讲,提供给用户的是具有
高级别的运行时间保证的实例,基础设施必须被部署为没有任何的单点故
障,即使是某计算主机消失,也得马上有其他主机顶上。这需要构建在企
业级存储的共享文件系统之上,或者是OpenStack块存储,以满足保证级别
和对应的服务匹配。
关于OpenStack高可用更多信息,请阅读 OpenStack 高可用指南.
安全性
一个安全域在一个系统下包括让用户、应用、服务器和网络共享通用的信
任需求和预期。典型情况是他们有相同的认证和授权的需求和用户。
这些安全域有:
•公有
•客户机
•管理
•数据
这些安全域可以映射给分开的OpenStack部署,也可以是合并的。例如,
一些部署的拓扑合并了客户机和数据域在同一物理网络,其他一些情况的
网络是物理分离的。无论那种情况,云运维人员必须意识到适当的安全问
题。安全域须制定出针对特定的OpenStack部署拓扑。所谓的域和其信任的
需求取决于云的实例是公有的,私有的,还是混合的。
公有安全域对于云基础设施是完全不可信任的区域。正如将内部暴露给整
个互联网,或者是没有认证的简单网络。此域一定不可以被信任。
22架构指南
July 22, 2015
当前最新
典型的用户计算服务中的实例对实际的互联互通,客户安全域,在云中掌
握着由实例生成的计算机数据,但是不可以通过云来访问,包括应用程序
接口调用。公有云或私有云提供商不会严格的控制实例的使用,以及谁受
限访问互联网,所以应指定此域是不可信任的。或许私有云提供商可以稍
宽松点,因为是内部网络,还有就是它可以控制所有的实例和租户。
管理安全域即是服务交互的集中地,想一下“控制面板”,在此域中网络
传输的都是机密的数据,比如配置参数、用户名称、密码等。多数部署此
域为信任的。
数据安全域主要关心的是OpenStack存储服务相关的信息。多数通过此网络
的数据具有高度机密的要求,甚至在某些类型的部署中,还有高可用的需
求。此网络的信任级别高度依赖于其他部署的决定。
在一个企业部署OpenStack为私有云,通常是安置在防火墙之后,和原来的
系统一并认为是可信任网络。云的用户即是原来的员工,由公司本来的安
全需求所约束。这导致推动大部分的安全域趋向信任模式。但是,当部署
OpenStack为面向公用的角色时,不要心存侥幸,它被攻击的几率大大增
加。例如,应用程序接口端点,以及其背后的软件,很容易成为一些坏人
下手的地方,获得未经授权的访问服务或者阻止其他人访问正常的服务,
这可能会导致丢失数据、程序失效,乃至名声。这些服务必须被保护,通
过审计以及适当的过滤来实现。
无论是公有云还是私有云,管理用户的系统必须认真的考虑。身份认
证服务允许LDAP作为认证流程的一部分。Including such systems in an
OpenStack deployment may ease user management if integrating into
existing systems.
理解用户的认证需要一些敏感信息如用户名、密码和认证令牌是非常重要
的。基于这个原因,强烈建议将认证的API服务隐藏在基于硬件的SSL终端
之后。
更多关于OpenStack安全的信息,请访问OpenStack 安全指南。
运营因素
在构建过程中的规划和设计阶段,能够考虑到运维的内容显得异常的重
要。对通用型云来说,运维因素影响着设计的选择,而且运维人员担任着
维护云环境的任务,以及最初大规模的安装、部署。
服务水平协议(SLA)的设定,就是知道何时以及何地实现冗余和高可用会直
接影响到预期。SLA是提供保证服务可用性合同义务。他们定义的可用性级
别驱动着技术的设计,若不能实现合同义务,则会得到相应的惩罚。
影响设计的SLA术语包括:
23架构指南
July 22, 2015
当前最新
•由多基础设施服务和高可用负载均衡实现API可用性保证。
•网络运行时间保证影响这交换机的设计,需要交换机的冗余,以及其电
源的冗余。
•网络安全规则的需求需要在部署时被处理。
支持和维护
为了能够在安装之后能够支持和维护,OpenStack云管理需要运维人员理
解设计架构内容。运维人员和工程师人员的技能级别,以及他们之间的
界限,依赖于安装的规模大小和目的。大型的云服务提供商或者电信运营
商,会有针对性的培训,专门的运维部门,小型的实现的话,支持人员通
常是工程师、设计师、和运维人员的合体。
维护OpenStack安装需要大量的技术技能。例如,如果用户既做架构有设计
试图减轻运维的负担,那一定建议运维自动化。或许用第三方管理公司的
专长去管理OpenStack部署也是不错的选择。
监控
OpenStack云需要合适的检测平台来确保错误可以及时捕获,能够更好的管
理。一些特别的计量值需要重点监测的有:
•镜像磁盘使用
•计算API的响应时间
借助已有的监测系统是一种有效的检查,确保OpenStack环境可以被监测。
宕机时间
为有效的运行云,开始计划宕机包括建立流程和支持的架构有下列内容:
•计划内(维护)
•计划外(系统出错)
保持弹性的系统,松耦合的组件,都是SLA的需求,这也意味着设计高可用
(HA)需要花费更多。
举例来说,如果计算主机失效,这就是运维要考虑的;需要将之前运行在
其上的实例从快照中恢复或者重新建一个一模一样的实例。整个应用程序
24架构指南
July 22, 2015
当前最新
的设计都会被影响,通用型云不强求有提供将一个实例从一台主机迁移到
另外一台主机的能力。假如用户期望其应用是被设计为容错的,那么就要
额外考虑支持实例的迁移,也需要额外的支持服务,包括共享存储挂载到
计算主机,就需要被部署。
容量计划
在通用型云环境中的容量限制包括:
•计算限制
•存储限制
计算环境的规模和支撑它的OpenStack基础设施控制器节点之间的关系是确
定的。
增加支持计算环境的规模,会增加网络流量、消息,也会增加控制器和网
络节点的负载。有效的监测整个环境,对决定扩展容量很有帮助。
计算节点自动挂接到OpenStack云,结果就是为OpenStack云添加更多的计
算容量,亦即是横向扩展。此流程需要节点是安置在合适的可用区域并且
是支持主机聚合。当添加额外的计算节点到环境中时,要确保CPU类型的兼
容性,否则可能会使活迁移的功能失效。扩展计算节点直接的结果会影响
到网络及数据中心的其他资源,因为需要增加机柜容量以及交换机。
通过评估平均负载,在计算环境中调整超分配比例来增加运行实例的数量
是另外一个办法。重要的是记住,改变CPU超分配比例有负面影响以及引起
其它实例故障。加大超分配的比例另外的风险是当计算节点失效后会引发
更多的实例失效。
计算主机可以按需求来进行相应的组件升级,这就是传说中的纵向扩展。
升级更多核的CPU,增加整台服务器的内存,要视运行的应用是需要CPU更紧
张,还是需要内存更急切,以及需要多少。
磁盘容量不足会给整个性能带来负面影响,会波及到CPU和内存的使用。这
取决于后端架构的OpenStack块存储层,可以是为企业级存储系统增加磁
盘,也可以是安装新的块存储节点,也可以是为计算主机直接挂接存储,
也可以为实例从共享存储中添加临时空间。都有可能。
有关这些题目的更加深入的讨论,请参考 OpenStack 运维实战
架构
硬件选择分为三大块:
25架构指南
July 22, 2015
当前最新
•计算
•网络
•存储
为通用型OpenStack云选择硬件,印证了云是没有预先定义的使用模型的。
通用型云为运行广泛的应用而设计,而每种应用对资源利用有着各自不同
的需求。这些应用不会是下面分类以外的类型:
•内存密集型
•CPU密集型
•存储密集型
为通用型OpenStack云选择硬件必须提供所有主要资源的平衡性。
确定硬件的形式,也许更适合通用型OpenStack云,因为通用型有对资源的
对等(接近对等)平衡的需求。服务器硬件须提供如下资源平衡细节描述:
•计算容量(内存和CPU)对等(或接近对等)
•网络容量(连接数量和速度)
•存储能力(每秒输入/输入操作(IOPS),GB或TB)
服务器硬件是围绕4个冲突的维度来进行评估的。
服务器 关于多少台服务器能够放下到一个给定尺寸的物理空间的量度,
密度
比如一个机柜单位[U]。
资源容 一个给定的服务器能够提供的 CPU 数目、内存大小以及存储大
量 小。
延伸性 服务器上还能够继续添加直到到达其限制的资源数目。
成本
相对硬件的购买价格,与构建系统所需要的设计功力的级别成反
比。
增加服务器密度意味这损失资源容量和扩展性,同理,增加资源容量和扩
展性会增加开销和减少服务器密度。结果就是,为通用型OpenStack架构决
定最合适的服务器硬件意味着怎么选择都会影响到其他设计。从以下列表
元素中作出选择:
•刀片服务通常都支持双插槽多核的CPU,对于通用型云部署此配置通常被
考虑为“甜点“。刀片拥有卓越的密度。举例,无论是 HP BladeSystem
26架构指南
July 22, 2015
当前最新
还是 Dell PowerEdge M1000e,均支持在占用10U的机柜空间下达到16台服
务器的密度。尽管如此,刀片服务器本身具有有限的存储和网络容量,
另外扩展到多台刀片服务器也是有局限的。
•1U机架式服务器仅占用1U的机柜空间,他们的有点包括高密度,支持双
插槽多核的CPU,支持内存扩展。局限性就是,有限的存储容量、有限的
网络容量,以及有限的可扩展性。
•2U的机架式服务器相比1U服务器,提供可扩展的存储和网络容量,但是
相应的降低了服务器密度(1U机架式服务器密度的一半)
•高U的机架式服务器,比如4U的服务器,可提供更多的CPU容量,通常可
提供四个甚至8个CPU插槽。这些服务器拥有非常强的可扩展性,还拥有
升级的最好条件。尽管如此,它们也意味着低密度和更高的开销。
•“雪撬服务器”亦是机架式服务器的一种,支持在单个2U或3U的空间放
置多个独立的服务器。此种类型增加的密度超过典型的1U-2U机架服务
器,但是单个服务器支持的存储和网络容量往往受到限制。
支持通用型OpenStack云的服务器硬件最佳类型,是由外部的业务和成本因
素所驱动的。没有那个单一的参考架构可以满足所有的实现,决定一定要
依据用户需求,技术因素,以及运维因素。这里有一些能够影响到服务器
硬件的选择的关键的因素:
实例密 对于通用型OpenStack云来说规模大小是一个很重要的考虑因素。
预料或预期在每个hypervisor上可以运行多少实例,是部署中衡
量大小的一个普遍元素。选择服务器硬件需要支持预期的实例密
度。
主机密 物理数据中心【相对应的有虚拟数据中心,译者注】受到物理空
间、电源以及制冷的限制。主机(hypervisor)的数量需要适应所给
定的条件(机架,机架单元,地板),这是另外一个重要衡量规模
大小的办法。地板受重通常是一个被忽视的因素。数据中心的地
板必须能够支撑一定数量的主机,当然是放在一个机架或一组机
架中。这些因素都需要作为主机密度计算的一部分和服务器硬件
的选择来考虑,并需要通过。
电源密 数据中心拥有一定的电源以满足指定的机架或几组机架。老的数
据中心拥有的电源密度一个低于每机架20AMP。近年来数据中心通
常支持电源密度为高于每机架120 AMP。选择过的服务器硬件必须
将电源密度纳入考虑范围。
网络连 已选择的服务器硬件必须有合适数量的网络连接,以及恰当的类
通性
型,目的是支持建议的架构。为了确保这点,最小的情况也需要
至少为每个机架连接两条网络。如果架构要求更多的冗余,也许
27架构指南
July 22, 2015
当前最新
就需要和电信供应商确认有多少线路可以连接。大多数的数据中
心具备这个能力。
形式因素或体系结构的选择会影响服务器硬件的选择,例如,假如设计一
个横向扩展的存储架构,那么服务器硬件的选择就得小心谨慎的考虑需
求,以匹配商业解决方案的需求。
确保选择的服务器硬件的配置支持足够的存储容量(或存储扩展性),以满
足所选择的横向扩展存储解决方案的需求。举例,如果需求是基于集中存
储解决方案,比如存储厂商的集中存储阵列需要InfiniBand或FDDI连接,那
么服务器硬件就需要安装对应的网卡来兼容此特定厂商的存储阵列。
同样的,网络架构会影响到服务器硬件的选择,反之亦然。举例,确保服
务器配置了足够的网络端口和扩展卡,以支持所有的网络需求。因为有网
络扩展卡的兼容性问题,所以要意识到潜在影响和兼容性问题,以及架构
中的其他组件。
选择存储硬件
存储硬件结构主要是由所选择的存储体系结构来确定。存储架构的选择,
以及相应的存储硬件, 通过评估可能的解决方案,即针对关键的因素,用
户需求,技术因素和运维因素来做决定。需要被并入存储体系架构的因素
包括:
成本 存储在整个系统的开销中占有很大一部分。对于一个组织来说关心
的是提供商的支持,以及更加倾向于商业的存储解决方案,尽管它
们的价格是很高。假如最初的投入希望是最少的,基于普通的硬件
来设计系统也是可接受的,这就是权衡问题,一个是潜在的高支持
成本,还有兼容性和互操作性的高风险问题。
可扩 可扩展性是通用型OpenStack云主要考虑的因素。正因为通用型云
展性 没有固定的使用模式,也许导致预测最终的使用大小是很困难的。
也许就有必要增加初始部署规模以应对数据增长和用户需求。
延伸 对于通用型OpenStack云存储解决方案来说,可扩展性也是主要的
架构因素。一个存储解决方案能够扩展到50PB,而另外一个只能扩
到10PB,前者明显比后者的扩展性强好多倍。此扩展与scalability
有关,但是不一样,scalability更加倾向于解决方案的性能衡量。
举例,一个存储架构为专注于开发者平台的云和商业产品云在
expandability和scalability上就不可能一样。
使用在服务器直接挂接存储(DAS)来作为横向扩展存储解决方案,是比较适
合通用型OpenStack云的。举例,无论是采用计算主机类似的网格计算解
决方案,还是给主机提供专用的块存储,这样的存储方式是可能的。当在
28架构指南
July 22, 2015
当前最新
计算主机合适的硬件上部署存储时,需要支持存储和计算服务在同一台硬
件。
正确理解云服务的需求对于决定该使用什么横向扩展解决方案有非常大的
帮助。假如现在需要一个单一的,高度可扩展,高度垂直化,可扩展的性
能等需求,那么在设计中采用中心化的存储阵列就应该被考虑。一旦一种
方法已经被确定,存储硬件需要在此基础上的标准来进行选择。
这个列表扩展了在设计通用型OpenStack云可能产生的影响,包括对特定存
储架构(以及相应的存储硬件)
连通性
确保连通性,如果存储协议作为存储解决方案的一部分使用
的是非以太网,那么选择相应的硬件。如果选择了中心化的
存储阵列,hypervisor若访问镜像存储就得能够连接到阵列。
用量
特定的存储架构如何使用是决定架构的关键。一些配置
将直接影响到架构,包括用于hypervisor的临时实例存
储,OpenStack对象存储使用它来作为对象存储服务。
实例和镜
像存放地
实例和镜像存放在哪里会影响到架构。
服务器硬
如果是一个囊括了DAS的横向存储架构的解决方案,它将影响
到服务器硬件的选择。这会波及到决策,因为影响了主机密
度,实例密度,电源密度,操作系统-Hypervisor,管理工具
及更多。
通用型OpenStack云有很多属性,影响存储硬件的选择的关键因素有以下:
对于资源节点的硬件选择来说,须为云服务提供足够的存储。定义初
始的需求和确保设计是支持增加的能力是很重要的。为对象存储选择
硬件节点须支持大量的廉价磁盘,无须冗余,无须RAID控制卡。为块
存储选择硬件节点须具备支持高速存储解决方案,拥有RAID控制卡保
证性能,以及在硬件层的冗余能力。选择硬件RAID控制器,是其可以
自动修复损坏的阵列,以帮助人工的介入,替代及修复已经降级或损
坏的存储设备。
对于对象存储的磁盘选择来说,不需要速度太快的磁盘。我们建议对
象存储节点利用最佳的每TB开销比即可。与此相反,为块存储服务
选择磁盘,则须利用提高性能的特性来选择,比如使用SSD或flash磁
盘来提供高性能的块存储池。即使是为实例运行的临时的磁盘也得考
虑性能。如果计算池希望大量采用临时存储,或者是要求非常高的性
能,就需要部署上述块存储硬件的解决方案。
对象存储资源节点对于硬件容错或RAID控制器没有任何的要求。没必
要为对象存储硬件规划容错是因为对象存储服务本身就提供了在zone

本文链接:OpenStack(PDF/WORD)http://www.51xuediannao.com/yunjisuan/OpenStack.html

OpenStack(PDF/WORD)由懒人建站收集整理,您可以自由传播,请主动带上本文链接

懒人建站就是免费分享,觉得有用就多来支持一下,没有能帮到您,懒人也只能表示遗憾,希望有一天能帮到您。

(责任编辑:懒人建站)