Azure平台：上下调整实例 [英] Azure platform: scalling instances up and down

问题描述

注意：如果您熟悉Azure定价模式，只需跳转到问题部分。

Microsoft将开始收费使用Azure平台启动 2010年2月1日。每月帐单将是带宽，存储和其他功能的函数。用于计算帐单的因素是计算时间。
然而，后一个因素有一个误导性的名称：它应该命名为 instance hosting time 。引用Windows Azure定价页面：

在开发和测试应用程序时，开发人员将要删除不是

因此，您认为这不是计算时间但正常运行时间您将需要支付的费用。这个疑问在阅读对这个问题在MSDN论坛：

我可以确认每个实例）计数，以及您拥有实例活动计数的所有小时（无论它们具有多少活动）。如果应用程式有两个网路角色执行个体和两个工作角色执行个体，系统会向您收取四个执行个体的费用。

每个实例每小时0.12美元，使用N个实例的应用的平均每个实例的费用为24 * 30 * 0.12 * N /月=〜$ 86 /月。
当您考虑到如果您希望99.9％的正常运行时间不能少于2个实例，小型网站的问题就会恶化服务水平协议。

因此，一个小型的计算能力低廉的网站而不是Azure的目标市场。

只有在计算能力和计算时间计费方面，Azure将是一个很好的托管选项，批量过程每月只运行几个小时，当且只有当你可以扩大（和向下！）容易显示实例数。所以：

• 是否可以通过编程扩展和缩小Azure中的实例数量？除了手动更改配置文件之外，还有其他选项吗？


• 是否有任何缩小实例数量的问题？


• Azure需要确认缩小你的应用程序吗？

关于后一个问题：非常大量的实例（例如，1000）运行45分钟。如果Azure无法在过程结束后15分钟内注意到缩小，那么您将需要支付另外1000个计算时间小时。

解决方案

您是正确的，您正在支付正常运行时间，而不是计算时间。

有一件事要注意，

正如其他人提到的，您可以按比例向上和向下编程从您的应用程序。然而，一般来说，特定角色只能访问自己的指标（除非将指标保存到存储中），以及任何全局资源指标（队列长度等），因此基于CPU利用率进行扩展可能很困难。 p>

缩放几乎立即开始，机器需要几分钟才能启动。目前没有提供启动的SLA。微软已经说过，实例会在不同的时间出现，所以如果你做一个非常大规模的操作，在所有实例可用之前可能是相当大的时间;但有些实例几乎立即可用。

缩小比例几乎立即发生，但您无法控制哪个实例用于缩小比例，因此如果50％的实例空闲并且执行了50％的缩小，则可以终止所有活动实例，并且该工作需要在以前空闲的实例上重新启动。您必须确保您的设计支持良好的重新启动工作（如果您使用队列超时，这可能大多是自动发生的）

有几个第三方解决方案开始出现旨在帮助缩小。我看过的一个看起来很有前景的是来自 http://paraleap.com/ 的AzureWatch，它提供了一些自动基于利用率，队长，时间表等的web和工作者角色的上/下缩放。

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.

解决方案

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.

这篇关于Azure平台：上下调整实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！