私有云建设中的评估

私有云建设一般分为评估，规划设计，实施，运维这几个阶段，本系列文章将会从这几个方面给出IBM PMC团队在这些方面的一些经验，当然这些经验并不是适合于每个客户，在具体项目中，我们要增加，裁剪这些经验，灵活的运用到项目中去。

本文本系列的第一篇，在私有云建设之初，我们要评估客户现有IT基础环境和应用环境，为以后的规划设计打下基础。

术语

工作负载：英文称为workload，指的是运行在各种中间件里面，或者独立运行的应用

用例：usecase，指的是从最终用户的角度来看，系统应该具有的一些功能，每个形成一定业务意义的功能构成了一个独立的用例

产出物：artifact，指的是工作的成果，包括文档，代码，配置文件等等，产出物是对用户的系统建设有意义的。

项目发起人：sponsor，指的是在项目的过程中，有拍板决定一些重要事情的人，这些人一般都是中高层人员。

架构决定：architecture decision，在项目中的一些重要架构上面的决策，这些决策会记录下来，供后面设计和实施的人参考，这些决策也要和客户一起审阅，因为架构中通常会有一些折中，这些折衷要客户知晓并同意。

云生应用：cloud native application，指的是特地为运行在云中而设计的应用，这些应用一般都有分布式，无状态等特点。

评估的意义

提到评估，大家可能有些疑惑，云不是应该动态扩展吗？我们直接把应用迁移到云上就可以了，我们为什么还需要评估现有的工作负载？要回答这个问题要从公有云和私有云的不同谈起。公有云和私有云的不同点很多，这里只是列举的一些影响到我们决策的点：

• 私有云中工作负载基本上是明确的，公有云中有各种各种的工作负载 私有云和公有云有一个非常大的不同点：私有云的工作负载（workload）是确定的，也就是说我们在建设私有云的时候，通常都应该知道我们将要建设的云环境中需要多少的计算能力，需要多少内存，需要多大的存储，网络方面有什么要求等。通过了解当前的工作负载，我们可以对将要建成的私有云环境有个基本准确的估计。 而公有云无法了解这些，一般来说是建设一个通用的云。或者就只能提供一些CPU密集型，存储IOPS密集型等比较宽泛的分类。通过评估，我们可以根据工作负载的需要选择合适的资源来承载。
• 私有云的规模相对公有云较少 私有云一般从规模来说要比公有云的规模小的多，在中国，比较小的公有云的话也至少有1000+的物理服务器，至少两个Region，而私有云的话一般来说在50到200台服务器之间。在这个较少规模的私有云中，我们在服务器，网络，存储上的决策就明显与大规模的公有云有所区别了。规模上的限制导致我们的私有云虽然也有弹性扩展能力，但是这种弹性扩展只能在一定的范围之内。 通过评估，我们可以了解客户弹性扩展的需求，建设一个适合客户需要的私有云平台。

评估的方法

访谈

访谈是一个古老但是很有效的手段，通过访谈我们可以了解到客户的IT的现状。但是要做到一个有效的访谈，还是有很多工作在里面的，首先我们要确定访谈对象：

• IT运维人员，他们对现有系统的基础架构最为了解
• 项目的发起者，通过他们了解这个项目的业务价值和业务目标，业务价值和业务目标是项目的原则性的东西，其他一切架构决定都不能违反这个原则

通过事前发放一些调查表可以提高效率，调查表要精心设计，不要包括废话以免被调查对象产生厌恶情绪。访谈之前，我们一般会向客户发放两个调查表：

• 工作负载调查表 工作负载调查表主要是确定客户现有的环境中有多少应用，这些应用的类型，是否有IO密集型应用等等
• 数据中心调查表 数据中心调查表主要检查客户的数据中心的供电，网络的状况，检查是否满足私有云的部署要求

通过客户反馈的调查表，我们基本上对客户的数据中心有一个大概的了解，遇到不清晰的问题记录下来，在访谈的时候和客户确认。

工具收集

在国内外的私有云项目中,容量规划工具还是用得一般。因为各种各样的原因，国内的私有云项目还较少使用，常见的容量规划工具如下：

• CiRBA商业软件
• VMware Capacity Planner免费，但是需要VMware的授权才能使用

容量规划工具可以帮助企业识别整合的机会，使他们能够缩减过度配置虚拟机，节省了资金。 工具规划工具一般会包括两部分：agent和中央服务器。Agent会部署在客户现有的生产环境中，会在客户的生产环境运行24周，这些agent消耗的资源都比较少，不会影响客户现有的生产环境的使用，它们每隔一段时间就会将收集到数据送到中央的服务器，收集的数据包括：

• CPU利用率
• 内存利用率
• 磁盘IOPS，磁盘使用大小
• 每一个进程对资源的利用率，包括Agent自己的

利用这些收集的数据，容量规划工具可以得出一些关于基础架构的推荐的配置。

当然，工具是死的，这些推荐的配置还是需要有经验的架构师来做检查和提高的，不过这些工具确实提供了给架构师科学决策的工具。

评估的内容

业务价值

业务价值是指客户想要通过建设这个私有云，能够直接给业务带来哪些利益，不同的项目想获得的利益不尽相同，下面是一部分例子：

• 更加敏捷的获得资源
• 在资源紧缺的时候，能够迅速扩张资源
• 节省运维成本
• 。。。。

这是最重要，但是也是最容易被忽略的部分。因为这一部分不涉及到具体的一些工作。但是我们上面提到了，业务价值是指导私有云建设的最高原则，我们在做具体设计的时候，要是要遇到很多的决策决定，这些架构决定一般会提供几个选项，这些选项有的时候是冲突的，如何决定选择哪个？我们第一要看的就是客户的业务价值了。

现有的工作流

现有工作流是现在客户环境中存在的工作流，企业中的业务流程是多种多样的，我们只需识别出和我们私有云建设相关的工作流，一般来说，这些工作流包括：

• IT资源申请，审批，通知用户流程
• 将创建的云资源（包括VM，网络，存储）加入企业现有CMDB的流程
• 将创建的云资源加入企业现有IT基础架构的过程，例如将VM的名字加入DNS等等

以上这些流程根据企业的大小不一，会有不同的变化，这些变化还体现在集成的方式不一样，一些公司已经建成自己的Service Desk，他们往往倾向于利用原有的Service Desk来调用私有云的API，另外一些公司本来没有Service Desk这个平台，他们就想利用私有云平台来做这个工作。 这个工作项的产出物是用例（UseCase），后文中会给出用例的示例。

工作负载

工作负载，从不同的角度看有不同的分类，一般可以分成两类：

• 传统负载
• 云生（Cloud native）负载

传统负载又可以分成：

• web应用负载
• 数据库应用负载
• dev、test负载

虽然负载的类型很多，但是我们如果注意到下面三个方面，那么对负载的评估也就达到要求了：
1. 总的负载对计算，存储，网络能力的要求
2. 特别高的IOPS的负载
3. 负载的高可用性的要求 对于这三点的收集，有利于我们后面做出正确的设计决定。

计算&存储

一般来说，对工作负载的评估完成之后，也就完成了企业对计算和存储能力要求的评估了。当然，存储还是要注意一下备份和灾备的需求。

网络

和计算&存储相比，网络还是稍微有些特殊的，网络评估除了要看工作负载对网络：

1. 吞吐量的要求，也就是带宽的要求，这个带宽包括

   • 外网带宽
   • 内部网络应用之间的带宽
   • 存储网络的带宽（如果是用IP网络的话）

2. 网络的延迟

还需要看：

1. 网络的安全隔离的要求
2. 网络的访问方式
3. 网络的其他要求

系统集成点

1. 认证授权的集成 企业一般有自己的认证授权系统，是否需要和这些认证授权系统集成？
2. 外部应用系统集成，包括：
   
   • 资产管理系统
   • ticket系统
   • Service Desk，例如Service Now等，这个在上文已经说过了

这个评估的产出物是系统上下文图（System Context Diagram），通过这个图我们可以看到客户的系统和外界集成状况，也可以清楚的知道项目的范围。具体示例可以参见下文。

非功能性需求

• 安全

防火墙，IDS，漏洞扫描

• 灾备

为了保证业务连续性，私有云云必须有相应的灾备环境。灾备这个话题在私有云中有点艰难。架构师很难给出很好的选择。桌面云需要灾备的内容包括数据库，用户基础镜像，用户数据和档案，各模块配置信息等。我们需要了解用户现有的灾备环境，包括：

• 现有灾备的流程：包括灾备涉及哪些人员，灾备的 RTO 和 RPO，灾备发生时应有的操作等
• 使用的软硬件：确定备份使用的软硬件是什么，以及这些软硬是否有多余的容量来容纳桌面云项目的备份
• 备份所需的带宽：确定现有备份网络带宽以及桌面云项目所需带宽
• 备份的项目：评估现在数据库是怎么备份的，文件是怎么备份的，配置项是怎么备份的，把桌面云项目拆成不同的项进行备份
• 备份频率：备份的频率是实时的 / 每小时 / 每天 / 每星期 / 每月的，把桌面云中不同的备份项归应到不同的备份频率中

评估的产出物

用例

下面是系统用例的一个例子，这个例子说明了云管理员创建一个新的客户需要的信息，创建好了的后续流程，以及与之相关的业务流程。

虚机申请与使用功能权限：客户管理员，用户功能描述 云管理平台提供虚机申请的自服务功能。

SystemContex

下面是一个系统上下文图实例，通过这个示例我们可以看到，云管理平台需要和哪些使用者以及外部系统做集成：

非功能性需求

非功能性的需求包括安全，性能，高可用性等等方面，在评估阶段通常是列出系统要求达到的目标，具体如何达到这个目标，可以在设计阶段体现，下面是一个非功能性需求的例子：

管理平台的高可用性

描述云管理平台要求提供高可用性，整体可用性要求达到99.95%

想了解更多私有云建设方面的经验？请点击前往

联系作者：史明春 shimch@cn.ibm.com