调度 Azure 实例
我想按预定的计划（例如，周一至周五，东部标准时间晚上 9 点至 5 点）运行单个 Azure 实例以减少计费，并且想知道最好的方法是什么。
问题分为两个部分：
- Service Management API [1] 能否用于按预定计划将 InstanceCount 设置为 0？
- 如果是这样，您是否仍需要为此服务付费，就像暂停部署的情况一样？
[1]- http://blogs. msdn.com/b/gonzalorc/archive/2010/02/07/auto-scaling-in-azure.aspx
I'd like to run a single Azure instance on a predetermined schedule (e.g. 9-5 PM EST, Mon-Fri) to reduce billing and am wondering what the best way to go about it is.
Two parts to the question:
- Can the Service Management API [1] be used to set the InstanceCount to 0 on a predetermined schedule?
- If so, are you still billed for this service, as is the case with suspended deployments?
[1] -
http://blogs.msdn.com/b/gonzalorc/archive/2010/02/07/auto-scaling-in-azure.aspx
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您无法将实例计数设置为零，但可以暂停并删除部署，然后以编程方式重新部署所有部署。
You can't set the instance count to zero, but you can suspend and then delete the deployment and then redeploy all programmatically.
Microsoft 发布自动缩放应用程序阻止（Wasabi），它将通过根据时间表更改实例计数来保护您的预算。它提供了许多其他功能，包括优化稳定器，该稳定器将处理每小时边界（具体来说，它将限制将操作扩大到一小时开始并将缩小操作限制到一小时结束）。
请参阅此线程上我的详细答案以及支持的方案。
Microsoft shipped the Autoscaling Application Block (Wasabi) which will guard your budget by changing instance counts based on timetables. It offers many other features, including an optimizing stabilizer that will take care of the hourly boundaries (concretely, it will limit scaling up operations to the beginning of the hour and scaling down operations to the end of the hour).
See my detailed answer with supported scenarios on this thread.
史蒂夫涵盖了你的第一个要点。
对于第二个：如果您暂停部署，您仍然需要支付费用。您必须删除部署才能停止计算时间的累积。
Steve covered your first bullet point.
For the second: if you suspend your deployment, you are still billed for it. You have to delete the deployment to stop the accrual of compute-hours.
或者，您也可以使用 Lokad.CQRS 或 Lokad.Cloud 将不需要一直运行的任务组合在一起单个计算实例。
当然，这种方法并不普遍适用，并且根据您的应用程序的具体情况，它可能不适合您的情况。
Alternatively, you could use Lokad.CQRS or Lokad.Cloud to combine the tasks that don't need to run all the time on a single compute instance.
Of course, this approach is not universally applicable and depending on the specifics of your application it may not be suitable for your case.