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可用性集只是针对逻辑上硬件负载均衡，软件同步数据那块还是需要后台来执行，个人觉得在前端的可用性集的基础上，必然有一个公用数据库以及数据库可用性集。