Windows Azure体验之VM的可用性集

今天在一个群上看到一个网友发一个问题，问题是这样描述的：

在windows azure上建四台VM，这四台机都要做高可用    
做好后关掉三台，留下一台做生产，当用户数量访问大时cup需求会增大，达到一定的阀值后自动开户一台再再增大再开启一台，类推下去    
当CPU下降到一定的阀值时就自动关闭一台VM，再降低再关闭，按此类推下去

这种机制肯定是公有云必有的机制。而在windows azure上这种机制叫可用性集。

21V上的解释是可以使用多个 Windows Azure 虚拟机来确保应用程序的可用性。在应用程序中使用多台虚拟机可以确保在出现本地网络故障、本地磁盘硬件故障以及平台可能需要的任何计划内停机时，应用程序仍然可用。

具体详情可以参考：http://www.windowsazure.cn/zh-cn/manage/windows/common-tasks/manage-vm-availability/

话就不多说了，好不好用都是验证出来的。

1.我先部署好两个VM配置了负载均衡集，可以参考我之前的文章 http://gshao.blog.51cto.com/3512873/1600667

2. 新建可用性集

3.输入可用性集的名称；

4.保存配置，会对现有的VM进行重新配置重启动作。

5.将第二台VM加入到可用性集组内

6.重新配置完毕

7.配置自动缩放

8.默认情况是无计划时间缩放的

9.设置计划时间

10.配置启用实例多少，CPU检测的阈值多少，当CPU阈值达到扩展多少实例，当CPU降低低于阈值，缩减多少实例。

11.保存后，第二台VM会处于停止状态

12.当CPU处于100%的一段时间后，会触发自动缩放机制，启动新的VM。（PS：据我自己测试的时间，从CPU处于100%到VM启动足足花费了50分钟。这是多么惊愕的时间。）

 

我目前找不到如何修改这个触发机制的时间点，但是目前测试的结果，的确是相当的不好，下次测试会话机制触发的可用性集。而且目前Azure可用性集只是针对逻辑上硬件负载均衡，软件同步数据那块还是需要后台来执行，个人觉得在前端的可用性集的基础上，必然有一个公用数据库以及数据库可用性集。