云平台的可维护性
译者注：
最近Eucalyptus公司的联合创始人Graziano Obertelli连续写了几篇关于云服务的可维护性方面的博客文章。译者读后觉得很受启发，并决定花点时间将这几篇文章翻译成中文。这些博客文章的原始出处如下：
[1] http://gobertelli.blogspot.com/2012/12/its-maintainability-stupid.html
[2] http://gobertelli.blogspot.com/2013/01/maintainability-and-eucalyptus.html
[3] http://gobertelli.blogspot.com/2013/01/will-my-internet-be-faster.html
最近我一直在使用FastStart和Silvereye，并参与开发了一个在单台服务器上安装云服务的脚本。我还写了一篇博客文章，介绍如何在一台笔记本上安装Eucalyptus。我甚至用发布推特消息的方法来计时，结果表明只要15分钟的时间就可以完成Eucalyptus的安装。这的确是个不错的成绩，但是我想我们可不能忘记了我们搭建私有云的最终目的。
私有云基础设施（On-Premise Cloud as Infrastructure）
我认为Eucalyptus（或者任何其他私有云管理软件）的安装仅仅是部署私有云过程中的一个环节。它既不是第一个环节，更不是最重要的环节。我所说的私有云，指的是基础设施服务（Infrastructure as a Service, IaaS），其重点在于基础设施而不是服务。当我说起基础设施这个词的时候，我会想起卫星、电网、渡槽、互联网等等。作为基础设施，它们具有一些共同的特征。这里我想要讨论的一个特征是可维护性。
可维护性（Why Maintainability?）
基础设施的作用是提供或者支持最基本的服务。当基础设施崩溃时，其结果通常是非常严重的（想象一下断电、断水、断路）。基础设施必须是可依赖的（你能够在不牢靠的地基上盖房子吗），必须具有很长的声明周期（只有演示原型才是临时性的），在其服役期间能够承受各种不同的负载（想象一下高速公路和互联网，它们现在所承担的负载和设计初衷是完全不同的）。因此，基础设施需要具备适应负载的能力（弹性，elasticity）以及分离或者限制失效范围的能力（可靠性，reliability），保持正常的功能并且能够被正常访问（可用性，availability），能够与多个具有类似设计的基础设施相互操作（互操作性，inter-operability），并且限制操作人员的介入（减少人为故障）。在我看来，如上所述种种都是可维护性的根本。在这里我同意Cloud Admin的观点，可维护性包含了可靠性和可用性，因为从管理的角度来看，一个不可靠也不可用的基础设施根本是不可维护的。
部署私有云（Deploying On-Premise Cloud）
那么，我们如何才能够成功地部署一朵私有云呢？我认为主要的困难集中在早期规划、前期准备、负载预测这些环节。其中最重要的部分是理解未来私有云的实施形式以及负载来源，以及设计一个逐步将硬件资源和软件应用转移到私有云上的迁移路线。这听起来似乎很简单，对吧？
1、理解你的负载（Learn your Workload）
在大多数情形下，一朵私有云是为一组特定应用、特定部门、特定用户、或者是特定场景提供服务的。也就是说，未来私有云上的负载情况基本上是可以预知的。我们需要将这些负载分解为计算、网络、存储几个部分，了解各种负载平行发生的可能性以及峰值范围。在可能的情况下，对未来的负载进行预测。
在这个环节，对真实的负载进行采样或者创建模拟负载 是非常有用的。这样做并不容易，在有些情况下甚至不可能。但是，有了一个负载模型之后，我们就能够对架构设计和部署实施进行验证。
2、“负载－资源”映射（Map Workload to Cloud Resources）
云计算资源有三个基本组成部分：计算（CPU和内存）、存储、网络（带宽、安全、隔离、IP地址）。将系统的负载转换成云计算资源的使用量，能够帮助我们规划私有云的规模和容量。
此外，云计算资源的使用情况与最终用户的成熟度也有很大的关系。刚刚接触云计算的用户，往往严重依赖于EBS（基于EBS的实例，使用EBS卷）；但是当应用具备了云觉知（cloud-aware）能力之后，他们就习惯于使用实例仓库（instance-store）了。
3、准备物理设施（Prepare your Physical Infrastructure）
当我们用云计算资源使用量来定义负载时，我们就可以定位可能的性能瓶颈，并在此基础上准备必要的物理资源来承担这些负载。需要注意的是，某些类别的云计算资源可能同时对不同类别的物理资源都有需求。例如：基于EBS启动的实例可能同时对存储控制器（提供EBS服务）和网络（节点控制器需要调用远程的存储进行启动）都造成压力。
此外，我们还需要将进行某些操作所造成的负载考虑在内。例如，启动实例的时候节点控制器可能需要将虚拟机映像从Walrus服务拷贝到本地磁盘。这些操作可能会对网络（传输虚拟机映像的流量，虚拟机实例本身的流量）、Walrus服务（多个节点同时请求不同的虚拟机映像）、或者本地磁盘（实例的缓存、临时性存储）造成contention压力。
物理设施的准备工作对于私有云的可扩展性是至关重要的。如果不能够轻便地增加存储或者升级网络（或者重新配置网络），就无法根据负载需求对云服务进行动态扩容（除非是停止服务进行重新安装）。
4、部署实施（Deploy）
当物理设施准备停当之后，我们终于可以进行部署了。现在我们开始在对应的服务器上安装各个组件：云控制器（Cloud Controller，CLC）、Walrus、集群控制器（Cluster Controller，CC）、存储控制器（Storage Controller，SC）、节点控制器（Node Controller，NC）。通常来说，做这些事情花不了多少时间，半个小时总可以搞定了吧。当然，在一个配置有多个集群、高可用性、SAN存储的生产环境里面，部署时间还要更长些。
5、运营维护（Maintain）
当一朵云被部署完毕后，它就成了一个基础设施。因此我们需要保证它总是可用的，包括在升级（云管理软件、宿主机操作系统、路由器固件都需要在不关闭整体云服务的前提下进行升级）、失效（单台宿主机或者单个组件的失效不能够影响整体云服务，但是可以影响某些实例和某些请求）、扩容（增加节点、集群、存储、网络）、负载峰值（性能可以逐步恶化，但是不能崩溃）等等情况下。
如上所述各个步骤也可以在部署实施之后进行（你可能需要对有问题的负载进行采样，或者部署新的组件），但是它们依然属于维护的范畴。唯有如此，一个基础设施才能够有条不紊地提供服务，成为人们必不可少但又经常被忽视的一个部分。当一个基础设施存在的时间足够长之后，人们会认为这些服务是利索当然的，只有在出现问题或者是短缺的时候才会引起人们的注意（只有在断电的时候电网才会出现在新闻里）。也就是说，当你的云服务不再是可维护的时候，你就会出现在新闻里。
译者注：
翻译完这篇文章，突然想起最近关于AWS的新闻比较多呢。
Themocracy
[…] link: http://www.qyjohn.net/?p=2852 […]