这里边既有所有IT系统建设需要考虑的因素，也有私有IaaS云建设的特殊考虑因素。IaaS系统建设会上承载企业内部大量甚至全部业务系统，衔接整个企业的IT发展战略、组织架构和管理制度，根据现有业务系统和遗产接管要求，如何设计IaaS建设方案及其上的云服务就变的尤为重要。
如果不考虑其中的某个因素，都有可能导致项目的失败。举例来说，我曾经亲身经历过一个大型PaaS项目，因为管理和客户组织架构原因导致项目失败。客户在实施云计算建设之前，业务部门是强势部门，IT部门是支撑部门，而在规划和建设中忽略了客户组织架构的影响因素。IT部门变成了云平台的管理者，业务部门成为相对弱势的云服务消费者，导致客户内部组织架构重组、项目停滞，并导致最终失败。
私有云IaaS平台构成
我这里讲的是广义的云平台，我一般认为分成几大部分：门户（管理和自服务）、服务层、统一资源层（含适配器层）、基础设施（含虚拟化），紧密相关的有BSS、OSS子系统；外部可能交互的系统有ITSM、CMDB、外部监控系统、4A系统和通知系统等。我画了一个主要部件的草图，方便大家理解：
(a) 门户分为管理和自服务，分别给管理员和普通用户提供服务；用于展示基础设施、平台及软件服务，并控制用户接入方式，对用户的访问范围、界面的展示方式做设定等。以便于管理员和普通用户获取服务的信息，申请并使用各类服务。
(b) 服务层指服务构建与设计的逻辑组件，它负责定义服务的结构、流程等信息，组装原子服务，生成业务服务，发布到服务目录，监控服务运行状况等，形成完整的服务生命周期管理。业务用户可以通过服务管理层获取云计算服务；管理员可以通过服务管理层监控所有服务实例的整体状况；服务开发人员可以通过服务管理层定义和发布服务。服务管理层将以业务服务的形式对外发布所有的服务操作接口。
(c) 资源层指管理和调度软硬件资源的逻辑组件，它负责构建资源池，生成简单资源供应的技术服务（原子服务），定义资源运维的操作流程。为了组成资源池，一般将同质的设备集中安装，相互连接，并通过一定的管理软件来监管和配置。资源池由同质的一组资源组成，用户可以通过资源管理层软件从资源池中申请资源，指定该资源实例的配置，并管理其运行。管理员可以监控每个资源池的资源使用率，健康状况和性能状况。资源管理层将以技术服务的形式对外发布所有的资源操作接口。这一层要屏蔽掉虚拟化等的差异，使得上层无法感知。
(d) 基础设施包括计算、存储、网络，其中计算含各种异构虚拟化。
(e) BSS和OSS源自电信行业的B和O，BSS负责营销、结算等功能；OSS负责监控、安全等。恕不展开描述。
虚拟化异构
能否支持X86虚拟化异构、异构的支持广度是衡量一个云资源管理平台（区别与云服务管理平台，只做资源统一纳管、不含云服务的编排及供应）的一个重要标准。目前主流的虚拟化软件有几种：
Vmware
Hyper-v
Xen
Kvm
在kvm和xen上演化的各种版本
在此不考虑lxc等。主要的实现思路是在资源层做统一纳管，用一套接口整合，也即适配器模式，每种使用一个适配器。在实际开发中，一般接口做二次抽象。
目前最常见的异构是VMWare和KVM（Openstack纳管），其它异构实现方式也类似。目前有几种途径：
(a) 企业级云管理软件：此一大类涵盖范围较广，通常不是纯粹意义上的云资源管理，而会一并包含云管理平台的功能。典型的如VMWare VCAC，HP CloudSystem等。因不是讨论的重点，从略。
(b) Openstack社区版：Openstack社区本身支持KVM较好，而对于VMWare虚拟化的支持并不完善，开源版本中有两种方式：VMWare提供的VCDriver和Citrix提供的ESXDriver。后者已经基本上被废弃了，前者有很多bug、不完善。
如果有能力、有合适的团队支撑，可以考虑在VCDriver基础上自行完善。
(c) Openstack各企业商业发行版：如，Mirantis、Hp Hellion os商业版、Racespace等，基本上不尽成熟，或者高级功能有缺陷。我把Intel 多虚拟层环境也归到此类。
(d) VIO（VMWare Intergrated Openstack）：很多人向我推荐VIO，我反对，理由有几点：
遗产系统接管。如果对于已有的VMWare虚拟化，VIO无法做遗产系统接管
性能。VIO部署在虚拟机上，作为Vcenter插件，性能无法保障。
VIO本质上还是Openstack的一个实现，没有实现高级功能。
如果需要SDN，要集成NSX，成本等各方面都需要考虑。
(e) 自己实现，调用vCenter或vSphere的接口：推荐使用这种方式。 本部分内容可以参考之后我的另一篇文章《企业级IaaS中异构资源纳管探讨》。
小机与X86异构
除了X86虚拟化异构，还要考虑小机（主要是IBM Power）、物理机、虚拟机的供应，这时也要考虑小机的纳管需求。采用的方式也是在资源层统一纳管，但接口会有独特性，一般用流程引擎调HMC解决。本部分内容也可以参考之后我的另一篇文章《企业级IaaS中异构资源纳管探讨》。
Openstack及其应用场景
Openstack现在持续火热，各大厂商都在积极参与，本人也参加过Openstack峰会。结合工作中的实际，我认为Openstack长期来讲是个好东西，适合一定场景的应用范围，但并不普适。可以应用在：
开发测试环境
非关键业务
科研实验环境
我认为Openstack需要解决的问题有：
稳定性
可升级。目前部分模块已经可以升级，但并不稳定
高级功能，如HA等，一直在Blueprint，但一直未实现。
本文为授权转载文章，任何人未经原授权方同意，不得复制、转载、摘编等任何方式进行使用，e-works不承担由此而产生的任何法律责任! 如有异议请及时告之，以便进行及时处理。联系方式：editor@e-works.net.cn tel：027-87592219/20/21。
需求中心
AI助手
联系我们
返回顶部