《VMware vSphere设计（原书第2版）》—

本节书摘来自华章出版社《VMware vSphere设计（原书第2版）》一书中的第1章，第1.1节，作者：[美] 福布斯·格思里（Forbes Guthrie）斯科特·罗威（Scott Lowe）肯德里克·科尔曼（Kendrick Coleman），更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.3　设计原则

本节介绍设计的基本原则，即为了满足功能需求，我们在每个层面（技术、组织和运维）进行决策时需要参考的一些指导性观点。
概括地讲，vSphere 设计有5个基本原则：
可用性（availability）。
可管理性（manageability）。
性能（performance）。
可恢复性（recoverability）。
安全性（security）。
随后，我们会用AMPRS这个缩略语来指代上述5个基本原则。这些原则大体上都可以顾名思义，无需多加解释，但我们还会逐个详细介绍。

1.3.1　可用性

当在vSphere 设计中进行各种决策时，首先要考虑的一个原则就是可用性。可用性囊括了诸多领域：正常运行时间和故障时间、可靠性、冗余以及弹性。需要注意的是，有时候一些性能方面的原则也会关系到可用性，例如，在已签署服务级别协议（SLA）的情况下，可用性还可能包括应用响应时间或应用延迟时间。后面会单独讨论性能原则。就设计的几个层面而言，可用性原则对技术层面的决策影响最大。
在某些情况下，功能需求会直接描述可用性，例如，vSphere 设计实施后必须达到99％的可用性。此时，功能需求已经很清楚地提出了可用性要求，因此必须包含到vSphere设计中。但有的时候，功能需求中并不会直接描述可用性需求。此时，架构师就不得不在设计中加入适当的可用性级别，以进行更多的设计决策。功能需求中可能只要求虚拟环境必须使用10GB的以太网。只部署一个10GB的以太网交换机就能满足这个需求，但是这样这个10GB的以太网交换机就成了单一故障点。当功能需求中没有清晰地描述可用性需求时，为了简单地满足其描述的需求而设计的可用性级别会是合理的吗？
在上述情况中，架构师需要做一个假设。这个假设会考虑更广泛的功能需求和设计约束（请参见1.1节中的“注意”），从而让vSphere设计者所做的决策更加合理。如果没有直接说明可用性需求，那么架构师设计时应该使用这样的假设：vSphere环境的可用性要在项目资金允许的范围内做得尽可能高。

1.3.2　可管理性

架构师还必须考虑可管理性。可管理性原则最直接影响到的是运维层面的决策，因为它涉及了环境的持续管理和维护。可管理性主要包括以下内容：
兼容性。（兼容性可以作为设计的一部分被管理吗？）
适用性。（如何轻松管理适用性呢？）
互操作性。（可操作性和环境中的其他管理结构是集成在一起的吗？）
可扩展性。（随着环境的不断增长，如何很好地保证可扩展性呢？）

1.3.3　性能

功能需求中一般都会很清晰地描述性能要求。性能要求会影响到技术和运维层面的决策。从服务器的类型、网络交换机的类型到存储解决方案的选择，性能要求会影响到技术层面决策的方方面面。在运维层面，通常是在服务级别协议中定义性能要求的，比如响应时间、每秒事物处理次数以及支持的最大用户数等（如之前所述，请牢记在某些情况下性能需求和可用性是有关系的）。
显然，即使性能需求描述并不明显，设计vSphere环境的架构师在决策时也应该充分考虑性能。

1.3.4　可恢复性

可恢复性原则通常会涉及的概念包括：平均恢复时间（Mean Time To Recover，MTTR）、可维护性以及灾难恢复或业务持续性（DR/BC）。显然，这样看起来可恢复性和可用性是相关联的，但是可用性关注的是防止服务中断，而可恢复性的目标是环境如何更快地从故障中恢复正常。
各个组织会采用各种不同的指标来度量可恢复性。这些度量指标就是恢复点目标（Recovery Point Objective（RPO），重大故障或灾难发生的情况下，可以接受多大程度的数据丢失）和恢复时间目标（Recovery Time Objective（RTO），多长时间环境能恢复运行）。通常，功能需求都会包含设计需要满足的RPO/RTO度量指标。

1.3.5　安全性

安全性影响到设计的每个层面：技术、组织和运维，所以做每个决策时都要考虑到安全性。
上述5个基本原则是形成设计决策的基础。可以满足功能需求的方法有很多，但是作为vSphere机构，你必须用这5个基本原则来衡量决策的每个选项。这个选项对可用性有正面还是反面影响？对可管理性有正面还是反面影响？同样，对性能、可恢复性和安全性呢？这些原则指引我们沿着正确的方向以最好的方式来满足功能需求。
在结束本章开始研究VMware ESXi（见第2章）前，我们还得重点讨论另一个问题：VMware vSphere的设计流程。