私有云架构连载 - 第三部分 私有云的一些概念

Private Cloud Architecture - Part 3: Concepts

私有云架构 - 第三部分 一些概念

 

 

原贴 :

http://blogs.msdn.com/b/yasserabdelkader/archive/2010/12/25/private-cloud-architecture-part-3-concepts.aspx

 

In this post, I will discuss the main concepts behind Private Cloud. The concepts are guided by and directly support the principles we discussed previously.

在这一章里，我将会讨论一些私有云的主要概念。这些概念是从第二部分讨论的原则的指引下而衍生出来的，是他们的进一步细化。

 

Approaching Availability Holistically: Uptime was the main measure of availability in general, the more you add nines the more your system is available (for example, 99.999 is better than 99.99).

Approaching Availability Holistically: 通常“正常运行时间 (Uptime) ”是衡量“可用稳定性 (Availability) ”的主要衡量标准，小数点后面的 9 越多意味着你的系统越稳定（比方说： 99.999 比 99.99 要好）

 

Let’s define two new terms here: MTBF (Mean Time between Failures) that measures the time between service outages (reliability). MTRS (Mean Time to Restore Service) that measures the resiliency.

让我们在这定义两个术语： MTBF (Mean Time between Failures, 平均故障间隔时间 ) 用来衡量两个故障发生的间隔 (reliability ，可靠性 ). MTRS (Mean Time to Restore Service ，平均服务回复时间 ) 用来衡量服务可承受的弹性 (resiliency).

 

In traditional data centers, the availability is solved by throw in more redundant H/W that could pick up the workload to provide more up time. For example, in Active/Passive SQL Server Cluster or having two or more Web Front End (WEF) servers with a load balancer in SharePoint Farm. Private cloud approach this by mainly two software approaches:

Virtualization: by removing the traditional model of physical redundancy and replacing it with a virtualization layer. This abstract the service from the server layer and allowing the workload to transport or restart smoothly from a failed virtual server to another. To be fair, you will remove the redundancy from the computing layer, but you will still need it in the storage and network layer. Still a significant cost saving while achieves the same or better availability.

Monitoring: Automation of detection and response to failure can reduce MTRS significantly.

在传统的数据中心，可用稳定性 (Availability) 一般通过设置冗余硬件接管故障硬件的任务来提高“正常运行时间 (Uptime) ”，比方说通过在主 / 从模式的设置 SQL 服务器集，或者通过一个负载均衡器来协调两台或者两台以上的 Sharepoint 网站前端服务器，都是很好的例子。然而在私有云里，可用稳定性 (Availability) 的提高主要通过以下两种软件（而非硬件）的方式实现：

虚拟化 ： 通过用虚拟化层代替原来的硬件冗余，它把服务从服务器层中抽象出来，并且提供把任务从一台故障虚拟服务器迁徙到另外一台正常运行的服务器的能力。公平的说，通过这种方法虽然只能减少服务器冗余的开支，而存储和网络方面的冗余设置还依然存在，但是已经可以让我们明显降低成本和获得更好的可持续性。

监控 ：对故障的自动检测和恢复能够提高 MTRS ( 平均服务回复时间 )

 

Using the same physical hardware: to drive predictability, the underlying infrastructure needs to provide a consistent experience to the workloads that it hosts on the computing, storage and network layers. Private cloud provides that by moving server stock keeping unit to the logical level than the physical level. Once we reach that level of homogenize on the compute layer (so all servers have the same processing power, RAM, same connection to storage resources with same network connectivity), then failed servers could move transparently from one failed server to another without impact on the service behavior.

使用相同的硬件配置 ：为了达到更好可预测性，底层的硬件基础架构应该能为上层任务够提供持续一致的在存储、网络和运算上的体验。私有云应该提供以逻辑而不是物理为单位的服务器单元。一旦我们实现了硬件层面的一致性（意味着所有的服务器有着同样的处理器、内存、与网络和存储的链接方式等），这样我们就能顺利的实现从一台故障服务器到另外一台同样硬件服务器的顺利迁徙，而不会影响上层的服务质量。

 

Shared Pool of Resources: this is a key to the success of Private Could. All resources (compute/storage/network) are grouped in a pool that creates a fabric that hosts the virtualized workloads.

共享资源池 ：这对私有云来说是至关重要的。所有的资源（服务器 / 存储 / 网络）应该被组合在一起去形成一层“虚构平台” (Fabric) ，支撑上层任务的运行。

 

Infrastructure Virtualization: to decrease or eliminate downtime, enhance portability, simplify management and be able to share resources you will need to virtualize all infrastructure components (compute/storage/network)

基础架构的虚拟化 ：为了减少故障时间、提升可移植性、简化管理和实现资源共享，你需要对所有的基础架构（服务器 / 存储 / 网络）都实现虚拟化。

 

Fabric Management: Fabric is where all groups of compute, storage and network resources are connected to form the private cloud. It is a different layer above virtualization as an orchestration engine to manage the lifecycle of consumer’s workload. It added a new VM or reduces the number of VMs to the workload according to the need.

“虚构平台（ Fabric ）”管理 ：“虚构平台”用来沟通私有云和所有的服务器、存储以及网络资源的地方。它在虚拟化层（ Virtualization ）之上，是协调户任务和管理工作流程的引擎。它通过增加或者减少虚拟机以适应实际的任务运行需求。

 

Elastic Infrastructure: this enables the perception of infinite capacity by allowing resources to be allocated and released based on demand. Scale down (or releasing resources when not needed) is normally a forgotten practice. It is important to use consumption-based pricing model to incent consumers to be responsible of scaling down their need for resources when not needed.

弹性的基础架构 : 这帮助我们实现“取之不竭”的资源池模式和允许资源根据实际需求分配或者释放。在实际情况中，减少规模（或者说当需求不再的时候释放资源）是经常遗忘的一件事情。所以实行按需付费的方式十分重要，这将促使消费者在需求不再的时候，可以释放他们资源。

 

Shared Resources partitioning: Private Cloud can still provide partitioning if there is a need for that (say by law). Consider you run a multi-tenancy where there is a need to separate between resources on the physical server layer or the logical one. There will be a possibility for a cost here to cover that extra level of physical separation of resources.

允许资源分区存在 : 如果在必要的时候（比如说法律规定），私有云依旧可以提供资源的独享分区。考虑到你运行的是多重租户应用系统 (Multi-Ternacy ，一种架构设计的方式，指一个应用系统用来服务不同的客户，而这些客户用的都是同一台主机，同一个数据库，同一个应用系统，只有透过程序设计的方式来让不同的客户存取不同的资料。更多资料： http://ayende.com/Blog/archive/2008/08/06/Multi-Tenancy.aspx ，译者注 ) ，而同时又有需求需要你在逻辑上或者物理上进行独立的分区操作，这将导致一些额外的开销，用以支付物理层面分区的费用。

 

Allowing resource decay: The resource pool model allows for a failure of some of its resource members without affecting the over model. So you deal with the environment by providing a maintenance schedule for the resource pool itself on periodical bases on when you reach a predefined threshold and not on a server by server basis.

允许资源的老损报废 ：资源池的容错模式保证在某些资源老损报废的情况下，不会影响总体性能。所以你需要准备一个维护机制，在某个影响整体性能的阈值之前，来定期整理你的（私有云）环境。

 

Classification of Services: by providing different classification of services (availability, resiliency, reliability, performance and cost), this will guide the good usage model that private cloud wants to achieve.

服务分类 ：通过定义不同层次的服务（包括持续性、服务可承受的弹性、可靠性、性能和费用），这可以帮助私有云建立好的用例模型。

 

Service Cost Transparency: this is a direct view of taking service provider’s approach to deliver infrastructure. This will provide a more accurate picture of the true cost of utilizing share resources.

透明性的服务成本 ：这是以从服务提供者的角度去看待我们的基础架构交付。这将帮我们在通过共享资源方式产生的实际费用方面有更为清晰的认识。

 

Pay per Consumption: based on classification of services and service cost transparency, business will pay per usage (similar to the electricity utility bill). The main aim is to encourage the business of a good behavior usage of resource based on the pay per need rather than paying a big amount of money for the capital owning without actually a need for all the resources paid for.

按实际消费付费 ：基于服务的分类和透明的服务成本，开展业务将按照实际使用付费，就像我们使用电费的那样。这里的主要目的是鼓励我们根据实际需求的资源更好地开展业务，而不是把一大笔费用支付给那些实际根本用不到的资源上。

 

In the next blog I will discuss the patterns of implementing Private Cloud.

在下一次博客中我会讨论关于私有云实施的一些模式。