《Windows Azure Platform 系列文章目录》
1.Microsoft Azure底层是否由System Center和Hyper-V构成?
Microsoft Azure虽然支持Hyper-V的VHD直接上传至Azure云端进行管理，但是Azure底层技术是微软自己研发的、独有的技术，且不对外提供。如果客户想构建属于自己的私有云平台，可以使用Azure Pack，采用微软的System Center + Windows Server产品，构建自己的私有云平台。
2.我是否可以在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中再创建虚拟机。
3.如果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。
4.微软有没有单个实例的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。但是不会影响两个或者两个以上的实例(需要正确配置可用性集)。
5.微软在维护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。
6.什么是可用性集?
这里有两个非常重要的概念：故障域(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)的截图：
7.Microsoft Azure如何保证CPU、内存、硬盘的性能?
回答：传统的Hyper-V技术，CPU是共享的。比如笔者的ThinkPad T430S是4Core/8GB，安装了Windows Server 2012 R2操作系统，并且使用Hyper-V虚拟出3台虚拟机。那该笔记本的物理操作系统 + 3台虚拟机操作系统本质上都是共享4Core CPU的。
在Microsoft Azure提供的虚拟机类型如下：
| 虚拟机类型 | CPU | RAM | 外挂磁盘数量 | MAX IOPS |
| A0 | 共享 | 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。
注意：Azure VM CPU和RAM是固定搭配的，不可以按照用户的想法随意更改。