注意：如果您熟悉 Azure 定价模型，请跳至“问题”部分。
Microsoft 将于2010 年 2 月 1 日开始对 Azure 平台的使用收费。每月的账单将取决于带宽、存储等。用于计算账单的因素之一是计算时间。
然而，后一个因素有一个误导性的名称：它应该被命名为实例托管时间。引用 windows azure 定价页面：
在开发和测试应用程序时，开发人员将希望删除未使用的计算实例，以最大限度地减少计算时间计费
从而让您认为这不是计算时间，而是< em>正常运行时间您需要支付的费用。在阅读了对 此问题：
我可以确认（任何角色的）每个实例都很重要，并且实例处于活动状态的所有时间都算在内（无论它们有多少“活动”）。如果应用程序具有两个 Web 角色实例和两个辅助角色实例，您将需要为四个实例付费
每个实例的费用为 0.12 美元/小时，使用 N 个实例的应用程序的平均费用为 24*每个实例 30*0.12*N/月 = ~ 86 美元/月。
对于小型网站来说，如果您想要 99.9% 的正常运行时间，则实例数量不能少于 2 个这一事实，情况会变得更糟服务级别协议适用。
因此，计算能力低廉的小型网站可能不是 Azure 的目标市场。但对于批处理，这种负担可能会消失。
问题
仅就计算能力和“计算时间”计费而言，Azure 对于每月仅运行几个小时的批处理流程来说是一个不错的托管选项，当且仅当您可以轻松地（和缩小！）扩大实例数量。那么：
- 是否可以通过编程方式增加和减少 Azure 中的实例数量？除了手动修改配置文件还有其他办法吗？
- 缩减实例数量是否存在任何不明显的问题？
- Azure 需要多少时间来“确认”应用程序的缩减？
关于后一个问题：举一个极端的情况，您有大量实例（例如 1000 个）运行了 45 分钟。如果 Azure 在该过程结束后 15 分钟内无法注意到缩减情况，您将需要另外支付 1000 个计算小时的费用。
Note: if you are familiar with the Azure pricing model, just jump to the "question" section.
Microsoft will begin to charge for the use of the Azure platform starting February 1, 2010. The monthly bill will be a function of bandwidth, storage, and others. Among the factors used to calculate the bill is compute time.
This latter factor, however, has a misleading name: it should be named instance hosting time instead. Quoting the windows azure pricing page:
When developing and testing your application, developers will want to remove the compute instances that are not being used to minimize compute hour billing
Thus making you think it's not compute hours, but uptime hours what you will be charged for. The doubt fades out completely after reading the official response to this question in MSDN forums:
I can confirm that each instance (of any role) counts, and all the hours you have the instance active count (regardless of how much "activity" they have). In the case of an application that has two web role instances and two worker role instances, you'll be billed for four instances
At $0.12/hour per instance, an app using N instances will be billed an average of 24*30*0.12*N/month = ~ $86/month per instance.
The matter worsens for small websites when you take into account the fact that you can't have less than 2 instances if you want the 99.9% uptime service level agreement to apply.
So, a small, compute-power-inexpensive web site is probably not the target market for Azure. But for batch processes, the burden would probably go away.
Question
Speaking only in terms of compute-power and "compute hours" billing, Azure would be a good hosting option for a batch process that runs only a few hours a month, if and only if you can scale up (and down!) the number of instances easily. So:
- Is it possible to programatically scale up and down the number of instances in Azure? Are any other options besides manually changing the configuration file?
- Are there any non-obvious issues of scaling down the number of instances?
- How much time does Azure takes to "acknowledge" the scaling down of your application?
Regarding the latter question: Take an extreme case where you have a very large number of instances (say, 1000) running for 45 minutes. If Azure isn't capable of taking notice of the scaling down within 15 minutes after after the process has ended, you will be charged for another 1000 compute-time hours.
发布评论
评论（4）
您是对的，您支付的是正常运行时间，而不是计算时间。
需要警惕的一件事是，你支付的是部分时间的费用，没有任何比例分配，所以如果你快速增加和减少，你就吃满了时间。
正如其他人所提到的，您可以在应用程序中以编程方式向上和向下扩展。然而，一般来说，特定角色只能访问自己的指标（除非您将指标保存到存储中），以及任何全局资源指标（队列长度等），因此根据 CPU 利用率等进行扩展可能很困难。
扩大规模几乎立即开始，机器需要几分钟才能启动。目前没有提供旋转启动的 SLA。微软表示，实例会在不同的时间出现，因此，如果您进行非常大的扩展操作，可能需要很长时间才能使所有实例可用；但有些实例几乎立即可用。在实例完全启动之前，您无需为其付费。
缩减几乎立即发生，但您无法控制哪些实例用于缩减，因此，如果您的 50% 的实例处于空闲状态并且您执行了 50% 的缩减，您可能会杀死所有活动实例，并且该工作需要在之前空闲的实例上重新启动。您必须确保您的设计支持良好的工作重新启动（如果您使用队列超时，这通常会自动发生）
有一些第三方解决方案开始出现，旨在帮助扩展。我看过的一个看起来很有前途的产品是 http://paraleap.com/ 的 AzureWatch，它提供了一些功能，例如自动根据利用率、队列长度、时间表等向上/向下扩展网络和工作角色。
You are correct, you are paying for uptime hours, not compute hours.
One thing to be wary of is that you pay for partial hours without any proration, so if you rapidly scale up and down, you are eating full hours.
As other people have mentioned, you can programatically scale up and down from within your application. however, in general a particular role will only have access to its own metrics (unless you save the metrics into storage), plus any global resource metrics (queue length, etc) so doing scaling based on CPU utilization etc may be difficult.
Scaling up begins almost instantly with a machine taking a few minutes to spin up. There are no SLAs with spin-up offered currently. Microsoft has said that instances will come up at different times, so if you do a very large scale-up operation, it may be significant time before all instances are available; but some instances will be available almost immediately. You are not charged for an instance until it is fully spun-up.
Scaling down happens almost immediately, but you cannot control which instances are used for the scale-down, so if 50% of your instances are idle and you do a 50% scale-down, you may kill off all of your active instances, and that work would need to be restarted on the previously idle instances. You must make sure your design supports good restarting of work (if you use queue timeouts, this can happen mostly automatically)
There are a few 3rd party solutions starting to appear that aim to help out in scaling. One that I have looked at that looks promising is AzureWatch from http://paraleap.com/ which offers some things like automatic up/down scaling of web and worker roles based on utilization, queuelength, schedule etc.
一点警告，我下面的评论并不是基于在 Windows Azure 上运行生产应用程序；到目前为止，我只是闲逛并阅读文档。
是的，但据我所知 Azure 不会自行扩展和缩小，您必须通过 Web 服务调用来完成此操作（与使用 UI 手动完成此操作非常相似）。请参阅此 MSDN 文档，“托管服务”部分，并阅读从那里开始。
像 Hudson CI 服务器 这样的东西可以很容易地扩展以进行基本的工作队列监控。也许您需要功能更丰富的东西；整个“企业服务总线”世界中有很多这样的系统。
嗯。你需要考虑锁定，即如何确保每个工作人员以一致的状态离开队列并在关闭之前完成其任务？
此外，从 Azure 价目表来看：“部分计算时间按完整时间计费。”。
老实说，我不知道，但假设您的应用程序已经完全退出其工作，我假设最多需要几分钟。他们实例化新服务器的速度足够快，我猜启动新服务器比关闭它们需要更多的时间。
尝试测试一下。创建一个廉价帐户，然后启动一些服务器，关闭它们等。构建应用程序的小型原型（或使用 Azure 示例应用程序之一）并感受一下它。
另一个方面是：您如何保证能够随时扩展？目前，据我所知，任何云计算供应商都没有这样的保证；但亚马逊在这方面有着良好的记录。 Azure是一个新产品，我们不知道微软的容量估计有多好，即我们不知道他们在未来几个月内在此方面的表现如何。我希望这不是问题；微软会很好地处理这个问题——但我还没有证据表明这一点。
A little warning, my comments below are not based on running production apps on Windows Azure; so far I have just fooled around with it and read docs.
Yes, but AFAIK Azure doesn't scale up and down by itself, you'll have to do so via web service calls (much the same as using the UI to do it by hand). See this MSDN doc, the section "Hosted Services", and read on from there.
Something like the Hudson CI server can fairly easily be expanded to do basic work queue monitoring. Perhaps you need something more feature rich; there are quite many such systems from the whole "enterprise service bus" world.
Hmn. You need to think about locking, i.e. how to ensure that each worker leaves the queue in a consistent state and completes its tasks before shutdown?
Additionally, from the Azure price list: "Partial compute hours are billed as full hours.".
Honestly, I don't know, but assuming that your application has cleanly exited its work, I would assume it to be a couple of minutes at most. They instantiate new servers fast enough, and I'm guessing that starting new servers takes more time than shutting them down.
Try testing it. Make a cheap account, and start a few servers, shut them down, etc. Build a small prototype of your app (or use one of the Azure sample apps) and get a feel for it.
Another aspect is: What are your guarantees of being able to scale up whenever you want to? Currently, there is no such guarantee with any cloud computing vendor AFAIK; but Amazon has had a pretty good track record on this. Azure is a new offering, and we don't know how good Microsoft's capacity estimation is, i.e. we don't know how well they'll perform on this over the coming months. I expect this to be a non-problem; that Microsoft will handle this well -- but I have no evidence of this yet.
截至 2013 年 6 月 26 日，Windows Azure 包含了平台中内置的自动缩放功能。目前仅处于预览阶段，仅支持 2 个指标（CPU 利用率和队列长度），它非常直观且易于启用。 查看一下。
As of June 26, 2013, Windows Azure includes the autoscaling capabilities baked into the platform. For now just in preview and with only 2 metrics supported (CPU utilization and queue length), it is very intuitive and easy to enable. Check it out.
是的，现在有了新发布的自动缩放应用程序块，以编程方式扩展和缩减 Azure 中的实例数量比以往更加容易。
请参阅我对此线程的详细回答。
Yes, now with the newly released Autoscaling Application Block, programatic scaling up and down of the number of instances in Azure is easier then ever.
See my detailed answer on this thread.