Windows Azure功能更新：弹性伸缩(autoscale)、监控报警、移动服务及网站服务商用、新的虚拟机镜像

Windows Azure功能又更新了。此次更新包括1项重要更新和两个功能更新：

重要更新：云服务、网站支持按策略进行弹性伸缩

功能更新：两个预览版的服务（网站和移动）进入商用，虚拟机服务支持SQL 2014和Win 2012 R2

具体情况可见http://weblogs.asp.net/scottgu/archive/2013/06/27/windows-azure-general-availability-release-of-web-sites-mobile-services-new-autoscale-alerts-support-no-credit-card-needed-for-msdn-subscribers.aspx

其中，个人认为这个重要更新非常有价值。所谓弹性伸缩，就是指系统规模随着负载的高低变化，负载高时，系统自动扩充集群节点数量，反之，则减少规模。这样可以尽可能保持服务质量，同时又不会产生多余的成本。

我们常常会听到PaaS和IaaS的种种比较，而PaaS服务比IaaS服务更好的地方是它管理更简便，隐藏了IaaS的各种细节。就拿Windows Azure的PaaS服务来说，云服务的开发部署都很方便，应用发布基本上可以一键完成。部署时不需要逐一配置虚拟机，不需要登录每个虚拟机安装配置软件，增减集群节点也比较简单，在界面上拖动滚到条即可。但是，之前云服务的集群规模还是人工管理的，管理员必须时刻留意系统运行状况，并根据负载的高低及时调整规模。从这个角度讲，之前的云服务并不完美，尽管部署很方便，但是运维方式跟IaaS一样。它的运维方式暴露了内部的复杂性给用户，用户需要自行架设监控引擎并进行决策。而对大部分不专业的用户来讲，用户可能不会部署任何监控方案，仅仅依靠简单的工具来判断系统负载，然后来设定集群节点数，这样用户不会去经常调整集群规模，让系统没有弹性。而弹性应该是PaaS的一个天然能力。有了弹性，开发人员和管理人员才能真正从基础架构的管理中解脱出来，而这时的PaaS，才能真正成为一个云操作系统。我们开发单机应用的时候，操作系统不会要求我们去选择自己的程序跑在几个CPU上、跑在哪个CPU上，因为这是操作系统需要完成的功能。而微软把Azure定位为云OS，也必然要解决类似的应用调度问题。早在几年前，以IaaS著称的亚马逊AWS就推出了CloudWatch（监控）、Elastic Loadbalancing（负载均衡）和Auto Scaling（弹性伸缩）三项服务，显示了亚马逊向PaaS发展的战略。而微软自然不能落后，弹性伸缩的出现只是时间问题。

如今，弹性伸缩终于成为了Azure的缺省功能，微软在年初收购了MetricsHub（专门做Azure的弹性管理），并将其功能整合到了Azure里。而且，弹性伸缩这些功能是免费的，其配置也相当方便。弹性伸缩对于网站服务、云服务和虚拟机服务均可以应用应用。下面就看下实际的效果：

网站弹性伸缩

首先看网站服务。在网站的“缩放”页，我们可以更改网站模式为“标准”（仅有该模式可以应用弹性伸缩），然后在“自动缩放”属性部分，我们可以点击“CPU”，这样界面就会展开策略配置的信息。

具体的配置内容有3个部分，分别是实例的大小、实例数的范围和目标CPU值。跟以往不同的是，实例数可以指定一个范围，而不是给定一个确定的值。所谓实例实际上就是后台的虚拟机，选择1-2实例意为着Azure会启动1-2个虚拟机运行该网站。当虚拟机CPU大于80%时，Azure会启动扩容动作，将虚拟机增加到2个，而当这两个虚拟机的CPU小于60%的时候，Azure会进行收缩动作，将虚拟机数减少为1个。可见，在Web层，用户只要定好策略，就基本上不用在运行时进行性能的监控和规模的调整了，系统会自动进行处理。

云服务弹性伸缩

下面再看下云服务的配置。云服务下，Azure将每个Role作为一个单独的管理单元，也就是说，每个Role可以独立伸缩。

当我们选择自动伸缩模式为CPU时，其配置与网站服务类似，也是指定实例数范围、目标CPU范围。多出来的两个配置是扩展幅度和冷却时间。分别代表一次伸缩时添加或减少的实例数目，以及两次伸缩动作之间的最小间隔（避免频繁缩放）

除此以外，我们还可以选择自动缩放模式为队列。这时Azure会根据某个存储Queue的长度来判断合适进行缩放，而不是根据CPU利用率。

我们可以进行一个简单的测试。我们首先关闭弹性伸缩，然后指定实例数为2。我们看到下图中WebRole有两个实例在运行

接下来我们修改弹性伸缩模式为CPU，将实例范围设为1-3，目标CPU不变。然后保存。

此时系统没有任何压力，CPU小于60%，因此Azure应该很快会将多余的一个实例停掉。我们发现，几分钟以后，Azure确实自动减少了一个实例

虚拟机弹性伸缩

在虚拟机部分，Azure管理的方式跟云服务类似。Azure会为每个虚拟机生成一个隐藏的云服务，这个云服务只有一个Role，拥有一个实例。此时是没法伸缩的。虚拟机服务的弹性伸缩是动态开机、关机，而不是像虚拟机服务那样创建、删除实例。因此，我们需要首先创建一个可伸缩的集群，其条件是所有虚拟机位于同一个云服务的同一个可用性集。具体创建方式如下：

第一个虚拟机修改配置，在可用性集处创建一个，比如命名为abc

创建新虚拟机时，选择“连接到现有虚拟机”，选中第一台虚拟机

在最后一步，选择之前创建的可用性集

这样新创建的虚拟机会加入原虚拟机的云服务，并且在同一个可用性集中。而且，原本隐藏的云服务也会显现出来。

在云服务列表中找到这个云服务，进入“缩放”页，就可以看到缩放配置

监控报警

除了弹性伸缩，还有一个相当有用的功能是报警。之前Azure在门后可以显示实时的性能监控和可用性监控结果，但是由于没有报警功能，运维人员必须随时留意门户上的性能数据，或者借助其他工具，如System Center进行性能检测并产生故障报警。今天的功能更新弥补了这个不足。报警功能支持云服务、虚拟机服务、网站服务、移动服务这4项计算服务，并且支持性能警报和可用性警报两种方式。该服务目前也是预览阶段，是免费的。

在Azure门户-〉设置-〉警报页，我们可以点击底部的“添加规则”进行警报策略定义。

在下一页，我们可以指定报警条件。其中，云服务和虚拟机支持5种基本的指标：CPU、磁盘读、磁盘写、输入网络、输出网络。此外，还支持“Web 端点状态”指标。而移动服务和网站只能定义“Web 端点状态”指标。针对要监控的指标，我们可以指定报警条件，如大于某个阈值。然后定义操作，如给管理员发邮件。

“Web 端点状态”，可以在每个服务的“配置”页“监视”处进行定义。它的功能是，给定该服务的一个Web地址，然后Azure会通过多个地点去定期访问该地址，将相应时间和可用性结果进行汇总。之前该功能只能监视，无法报警。关于该功能的详细介绍，可以参考http://blog.csdn.net/shaunfang/article/details/8645717#t1。现在，该功能和新的报警功能进行了集成。

下面我们简单实验下监测某个Azure站点的状态并产生故障报警。

以云服务为例，首先，我们记录下这个云服务的Web地址，比如http://guestbook201306.cloudapp.net/，然后进入配置页定义该端点，并在位置处选择“HK”作为检测地点。

接下来在监视器页，我们可以浏览监视的实时结果。结果有响应时间和运行时间两个指标，后者的意思就是Up Time

然后我们再去定义报警策略。此时我们发现除了基本的5个指标，系统又多了两个指标，他们是响应时间和运行时间。

如果我们想产生故障报警的话，可以选择运行时间，然后将报警条件设为< 90%，并要求发邮件通知

条件创建后，系统就会开始检测。如果这个站点发生故障，我们就会在门户右下角看到一个警报图标

点击详细信息后，系统会显示报警细节，包括报警来源、监控对象的历史曲线以及历史警报。

此外，我们也会收到一封邮件，通知我们发生了什么故障