《Windows Azure Platform 系列文章目录》
前面几章我已经给大家介绍了Windows Azure PaaS的好处，总结下来有以下几点：
1.面向应用，而不是面向IT基础。微软作为云计算供应商，让用户将更多的精力放在构建优秀的软件架构；而不必去考虑底层的问题，例如网络、操作系统、虚拟化等IT基础设施上。又比如：PaaS (Platform as a Service) 允许云计算供应商能够自动地升级操作系统，安装补丁；而在IaaS的云平台上，升级操作系统、安装补丁的操作需要用户手动的去进行配置和升级，及时性、可靠性都不高。采用了PaaS后，云计算供应商和软件开发者能够各司其职，将注意力放到自己领域内的问题上。
2.弹性. Windows Azure具有Worker Role和Web Role。 Web Role能够响应前端事件,而Worker Role能够响应Web Role发送过来的请求.这样的架构在保证前端快速响应的同时,又使得云计算架构更加弹性。
IaaS (infrastructure as a Service)在云计算分类上，面向于IT基础设施服务，让用户能够部署了运行自己需要的操作系统、中间件和Runtime。对于传统的商业软件来说，迁移到IaaS平台上所花费的时间、精力相比而言要小很多。IaaS更加适合传统的应用程序。
微软在之前推出了VM Role来实现IaaS的部分功能。但是相比真正的IaaS平台来说，VM Role是远远不够的。2012年6月，Windows Azure最新的对IaaS的支持里，微软引入了Virtual Machine这个功能，来实现Windows Azure对IaaS的支持。
那Virtual Machine相比VM Role做了哪些更新和改进呢？我们来看一看下面这张表：
| VM Role | Virtual Machine | |
| 存储 | 非持久性存储，一旦Windows Azure redeploy，则保存在VM Role本地磁盘上的内容全部消失，必须将文件保存到Windows Azure Storage上。 | 持久性存储，可以将文件保存到磁盘上去。 |
| 部署 | 创建VHD，然后上传到Azure Storage里 | 直接在Cloud里构建VHD，或者先创建VHD，然后上传到Azure Storage里 |
| 网络 | 外部和输入endpoint通过服务来配置 | 内部Endpoint默认开放。输入enpoints可以使用portal，service或者API/Script来配置 |
| 主要用途 | 部署应用长或复杂的安装要求 | 适合那些需要持久化存储的应用程序 |
Virtual Machine可支持的操作系统如下：
Windows
- Microsoft BizTalk Server 2010 R2 CTP (64-bit) on Windows Server 2008 R2 Service Pack 1
- SQL Server 2012 Evaluation Edition (64-bit) on Windows Server 2008 R2 Service Pack 1.
- Windows Server 2008 R2 SP1, August
- Windows Server 2008 R2 SP1, July
- Windows Server 2012, August 2012
Linux:
- OpenLogic CentOS 6.2
- SUSE Linux Enterprise Server
- Ubuntu Server 12.04 LTS
- Ubuntu Server 12.04.1
- openSUSE 12.1
1.1 Microsoft Azure机制
- Microsoft Azure是否由System Center和Hyper-V构成?
Microsoft Azure虽然支持Hyper-V的VHD直接上传至Azure云端进行管理，但是Azure底层技术是微软自己研发的、独有的技术，且不对外提供。如果客户想构建属于自己的私有云平台，可以使用Azure Pack，采用微软的System Center + Windows Server产品，构建自己的私有云平台。
- 我是否可以在Microsoft Azure Virtual Machine中再创建虚拟机呢？
Microsoft Azure数据中心是由成千上万台RACK组成的，每个RACK都安装了Windows Server 2012的操作系统，我们称为Host OS，即物理服务器的操作系统。
这些Windows Server 2012采用特殊版本的Hyper-V虚拟化技术，虚拟出了若干虚拟机，称为Guest OS。
Host OS内含一个Fabric Agent中控软件，以监控目前虚拟机各项信息给Fabric Controller。
Microsoft Azure的最终用户只能接触到Guest OS，而无法接触到Host OS。用户无法在Guest OS中再创建虚拟机。
- 如果Microsoft Azure所在的服务器宕机了，Azure Virtual Machine怎么恢复？
在传统IDC机房托管中，如果物理服务器发生了宕机，那所有的虚拟机都会宕机，需要人工或者监控软件来进行重新部署。
从文件高可用来说，Microsoft Azure虚拟机是以VHD格式保存的，并且在同一个数据中心做了三重冗余(支持跨数据中心的异地冗余)，保证Azure Virtual Machine底层VHD文件的99.9% SLA。
从数据中心架构来说，Microsoft Azure具有自我管理的功能。Azure Fabric Controller是管理Azure数据中心的中控管理系统，你可以认为他是Azure数据中心的大脑。Azure Fabric Controller本身是融合了很多微软系统管理技术的总成，包含对虚拟机的管理(System Center Virtual Machine Manager)，对作业环境的管理(System Center Operation Manager)等，在Fabric Controller中被发挥得淋漓尽致。
Azure Fabric Controller负责自动化的管理数据中心内所有的实体服务器，包含由用户要求的Microsoft Azure Guest OS的部署工作，定时的 Hotfix修补，机器状态的监控，以及管理不同版本的VM镜像等重要核心工作。Fabric Controller本身也具有高可用性。
Fabric Controller也处理虚拟机的健康管理工作(Health Management)工作，当Microsoft Azure Guest OS发生死机时，会由Fabric Controller自动选择不同的实体机器重新部署与启动。
在单台Guest OS的情况下，当Guest OS宕机的时候，重新部署与启动Guest OS会需要花费一定的时间，会引起客户应用的短暂离线，所以Microsoft Azure没有单个实例的SLA。
- 微软有没有单个实例的SLA?
微软没有单个实例的SLA。举个例子，客户有一个应用部署在传统IDC机房中，一台AD Server，一台Web Server，一台SQL Server。
在Microsoft Azure Virtual Machine中，用户也可以选择使用一台Azure Virtual Machine部署AD Server，一台Azure Virtual Machine部署Web Application，使用另一台Virtual Machine部署SQL Server。但是这样的场景是没有SLA保障的。
Microsoft Azure Virtual Machine承诺的99.95%的SLA是需要2台或者2台以上的Azure Virtual Machine同时运行，且所有的Virtual Machine都需要在同一个可用性集中。对于上面实例，用户如果想在Azure中实现99.95%的SLA，需要同时部署：
- 两台AD Server，放在同一个可用性集A中。
- 两台Virtual Machine部署Web Application，且Web Application所在的Virtual Machine需要放在另外一个可用性集B中。
- 两台Virtual Machine部署SQL Server，采用SQL Server 2012 Enterprise提供的Always-On功能，实现High Availability。且SQL Server所在的Virtual Machine需要在另外一个可用性集C中。
补充一点，微软没有单个实例的SLA主要原因有以下两点：
- 从基础设施角度来说，无法预测单台物理服务器的硬件在何时发生故障，即单台物理服务器的CPU故障、网络故障、电源故障等是无法预测的。
- 从物理服务器的维护来说。微软在每个月都会给Azure Virtual Machine做升级和维护，维护期一般是在周五凌晨和周六凌晨(北京、上海数据中心分别维护)。维护期窗口一般为6-8小时左右，在维护期内的虚拟机实例都会被重启，重启时间一般在10分钟左右。
即该维护期是由微软定义的，用户没有办法拒绝维护过程，用户也没办法指定微软在具体哪个时间点，维护哪些虚拟机。在维护期窗口内，任何一台Azure Virtual Machine都会被重启。但是只会影响单个实例的Azure Virtual Machine。
在Azure维护期内，会影响单个实例的Azure Virtual Machine。
- 微软在维护Azure Virtual Machine时会不会影响我的业务？微软是如何来保证99.95%的SLA的?
如果使用单个实例的Azure Virtual Machine，无法保证99.95%的SLA。
Microsoft Azure Virtual Machine承诺的99.95%的SLA是需要2台或者2台以上的Azure Virtual Machine同时运行，且所有的Virtual Machine都需要在同一个可用性集中。
在这种情况下，从基础设施角度来说，微软有机制可以保证同时运行的2台Azure Virtual Machine不会同时宕机。
从服务服务器的维护来说。微软在给Azure Virtual Machine做维护的时候，会监控到这2台Azure Virtual Machine在同一个可用性集中，就知道客户需要这2台Azure Virtual Machine做高可用。微软在重启Azure Virtual Machine，的时候，就不会同时重启。而是先重启其中的一台，等到这台Virtual Machine重启完毕后，再重启另外一台。这样保证在维护期窗口内，同一个时刻至少有一台Virtual Machine在线。
如果客户部署了2台Azure Virtual Machine但是没有设置可用性集，。微软在给Azure Virtual Machine做维护的时候，发现这2台Azure Virtual Machine没有关联，就会同时重启这2台Azure Virtual Machine，造成服务off-line。
- 什么是可用性集?
这里有两个非常重要的概念：故障域(Fault Domain)和更新域(Update Domain)。
我们先说说故障域。先举个例子，笔者的书房有一个插线板，插线板上接了我的笔记本电脑，手机充电器，电视机等电器。如果这个插线板断电了，那这个插线板上的所有电器都会断电。这个插线板和上面的电器组成了一个故障域。
Microsoft Azure数据中心基础设施由很多的RACK组成，每一个RACK都被称为故障域。当RACK出现硬件故障时候，在RACK上的服务，不管是 Azure的计算服务、存储服务等等都会宕机。
当客户部署了2台 Azure Virtual Machine，但是没有设置可用性集的时候，Microsoft Azure可能会把这2个Azure Virtual Machine部署在同一个RACK上，这样就可能会出现单点故障。因为这1个RACK宕机了，上面运行的2个Azure Virtual Machine都会宕机。两个Azure Virtual Machine宕机的概率和一个Azure Virtual Machine的概率是一样。
而设置了可用性集的情况下，Microsoft Azure就会把这2台Azure Virtual Machine部署在2个不同的RACK上。微软从数据中心底层设计上，可以保证这2个不同的RACK不会同时宕机。
然后我们谈谈更新域。比如我有2台Azure Virtual Machine做了负载均衡，名称为VM1和VM2，都部署了我的Web Application，版本为1.0，他们部署在不同的更新域Update Domain中。将来我的软件版本做了更新，升级到了2.0版本，有两种选择：
- 用户同时更新这2台Azure Virtual Machine的软件版本。但是这样如果有客户端发起请求，会造成服务器端的无法响应。
- Azure Fabric Controller监控这2台Azure Virtual Machine。首先更新Update Domain 0中的虚拟机软件。更新完毕后再更新Update Domain 1中的虚拟机软件，一直到所有的Azure Virtual Machine中的Web Application更新完毕，这样保证在同一时刻至少有1台Azure Virtual Machine能够响应客户端的请求。
以下是故障域(Fault Domain)和更新域(Update Domain)的截图：
- Microsoft Azure如何保证CPU、内存、硬盘的性能?
回答：传统的Hyper-V技术，CPU是共享的。比如笔者的ThinkPad T430S是4Core/8GB，安装了Windows Server 2012 R2操作系统，并且使用Hyper-V虚拟出3台虚拟机。那该笔记本的物理操作系统 + 3台虚拟机操作系统本质上都是共享4Core CPU的。
在Microsoft Azure提供的虚拟机类型如下：
|
虚拟机类型 |
CPU |
RAM |
外挂磁盘数量 |
IOPS |
|
A0 |
Share |
768MB |
1 |
500 |
|
A1 |
1 |
1.75GB |
2 |
2 * 500 |
|
A2 |
2 |
3.5GB |
4 |
4 * 500 |
|
A3 |
4 |
7GB |
8 |
8 * 500 |
|
A4 |
8 |
14GB |
16 |
16 *500 |
|
A5 |
2 |
14GB |
4 |
4 * 500 |
|
A6 |
4 |
28GB |
8 |
8 * 500 |
|
A7 |
8 |
56GB |
16 |
16 * 500 |
除了A0的虚拟机类型，它的CPU是和别的用户共享的。其他类型的虚拟机，比如A1-A7，它的CPU是独占的，不是和别的用户共享的。比如物理服务器是20Core，那这个物理服务器只能虚拟出2台A7的Azure Virtual Machine(8Core/56GB)，另外多余的4Core要预留给物理服务器。
关于硬盘的性能保证，微软是保证磁盘的IOPS。