如何设计具有扩展性的虚拟化基础设施

    当规划虚拟化基础设施时，将要进行虚拟化的服务器对处理器和内存的需求通常会作为决定主机服务器的资源需求。但是，这样的数字有可能具有欺骗性，因为他们只代表了在某一个时间点或者最多是某一个时间段内一个应用的资源使用，。

　　设计一个可以处理短期成长的虚拟化基础设施是很有可能的，但是真正建立一个强壮的虚拟环境，长期的成长也必须要加以考虑。这就是为什么应用的扩展性特点不容忽视。

　　所有的应用具有一个共同的标准：如果一个应用的负载超出了节点的能力，那么该应用以及（或者）其节点必须进行扩展，满足增长的需求。但是，并非所有的应用都具有相同方向的扩展能力。有的应用的设计初衷就是为了进行水平扩展；对额外的节点进行自动配置，使得应用能够分布其负载。有的应用在垂直方面做得更好，额外的资源分配到应用所在的节点。

　　本文将讨论如何设计一个虚拟化基础设施，能够让应用同时在水平和垂直方向进行扩展。

　　向上扩展（scale-up）或垂直扩展

　　数据库服务器几乎都要求进行垂直扩展。主流产品，如Oracle 10g,，Microsoft SQL Server和MySQL，都支持各种能够进行水平扩展性的方式，包括连续复制（Continuous Replication），联合数据库设计（Federated Database Design）或数据库负载均衡（Database Load Balancing）。

　数据库负载均衡的工作原理是，同步实现一次性所有的数据库写入到多个节点，读取操作由负载均衡节点的任何成员来进行。但是，如果写入操作完成不恰当，那么读取操作可能会返回错误数据。

　　对一个数据库进行向上扩展为其自身带来挑战。如何为数据库提供更多的资源，最简单的办法就是向上扩展。有一派观点认为采用向上扩展的应用不应该进行虚拟化，因为它们将最终消耗所有可用的主机资源。对于虚拟化向上扩展的应用而言，这种观点是正确的，但仅适合于应用程序只安装在一台物理服务器上的情况。

　　虽然向上扩展存在这些问题，但是，对这种类型的应用进行虚拟化仍然不失为一个好的办法。但是在设计基础设施时，需要认真和谨慎。

　　对于每一个向上扩展的现有应用而言，在单一主机上需确保有足够的资源来处理潜在的应用负载。同时，如果应用需要额外的资源，还需要确保其他节点有足够的资源来应对可能被迫从节点迁移的虚拟机。虚拟化软件允许创建策略，将具有向上扩展的应用的虚拟机与主机服务器相连，最大化利用可用的资源。因为虚拟化创建了一个新的应用移动层，所以，不需要购买一台巨大的服务器。相反，最开始可以使用小型机，随着业务的增长需要应用进行扩展，再将垂直应用的虚拟机迁移到更大的主机服务器。这样同时可以解决水平扩展应用的问题，但是，如果有更好的其他方法，建议不要采用这种解决方案。

　　向外扩展(scale-out)或水平扩展

　　每个人至少都可以意识到一种平行的应用类型，这样的应用可以很好地进行水平扩展：Web服务器。Web服务器的工作是为网页提供服务，这个工作本身是一项资源轻的任务。

　　随着网站使用的增长，Web服务器所在的节点无法分配足够的资源给Web服务器，这个时候，为网页提供服务就变成了一项资源密集型的任务。这种情况下，有两种选择：一，为节点增加更多的资源，或者二，增加另外一个安放Web服务器的节点。

　　像之前提到的数据库应用?谝桓鲅≡袷窍蛏侠┱梗?舛杂谠黾右桓鯳eb服务器能够服务的网页数量是最好的有效方法。但是，与数据库应用不同的是，Web服务器可以很容易就进行向外扩展，几乎没有或有很少的问题。这只是需要一个网站的数据能够放在共享存储上，例如，NAS。而且，由于主要的Web服务器，如Apache和IIS，都可以在共享的文件系统、服务器或过程存储它们的状态（state）。这样，一个Web服务器就成为一个数据访问网关。

　　这让Web服务器易于水平扩展：简单地增加另一个节点，安装在Web服务器上，然后配置Web服务器访问现有的文件和状态数据。

　　像Web服务器这样易于向外扩展的应用最适合于虚拟化，因为它们利用了许多现有虚拟化解决方案的优点，例如，共享内存访问、快速虚拟机自动配置和管理能力。设计一个与向外扩展应用互补的虚拟化基础设施很简单，只是不要太过。只是购买所必需的。向外扩展应用不倾向于需要64GB的RAM和八路处理能量。很多较小的虚拟主机服务器也可以运行良好，较多的节点将提供额外的冗余，以防止主机服务器硬件出现故障。

　　也有一些应用可以采用任何一种的扩展方式，例如文件服务器。如果存在这样的选择时，最好是选择向外扩展，而不是向上扩展。理由是额外的节点会提供额外的冗余性。总之，目前多数的应用可以采用任何一种方式进行扩展，但肯定存在更适合的选择。当设计虚拟化基础设施时，请考虑好应用的扩展性特点，认真计划虚拟环境。重要之重是要注意细节。

　　但是，所有的这些方法都分别存在以下问题：

　　连续复制不使用实时的数据，并不是所有的数据库产品支持冲突解决。

　　联合数据库设计仅以最慢的成员速度来运行，只要有一个服务器宕机，整个数据库就无法工作。设计联合数据库时，有办法确保高可用性（HA），但是成本很高，因为这意味着为每一个联合成员服务器提供一个冗余的节点。