Azure平台:向上和向下扩展实例 [英] Azure platform: scaling instances up and down

问题描述

注意:如果您熟悉Azure定价模型，只需跳至问题"部分.

Microsoft将自从2010年2月1日起开始收取使用Azure平台的费用.每月账单将取决于带宽，存储空间和其他因素.用于计算帐单的因素包括计算时间. 但是，后一个因素的名称具有误导性:应将其命名为实例托管时间.引用Windows天蓝色定价页面:

在开发和测试您的应用程序时，开发人员将希望删除未用于最小化计算小时计费的计算实例

因此，您认为这不是计算时间，而是正常运行时间.阅读对

在每个实例每小时$ 0.12的情况下，使用N个实例的应用的平均月费为24 * 30 * 0.12 * N/月=〜$ 86/月. 考虑到以下事实，小型网站的情况会更糟:如果您希望99.9％的正常运行时间不能少于2个实例，那么服务水平协议适用.

因此，一个小型，计算能力低廉的网站可能不是Azure的目标市场.但是对于批处理过程，负担可能会减轻.

问题

仅就计算能力和计算小时数" 计费而言，Azure是每月仅运行几个小时的批处理(如果且仅当您满足以下条件时)的不错的托管选项:可以轻松扩展(和缩小！)实例数.所以:

• 是否可以通过编程方式在Azure中增加和减少实例数量?除了手动更改配置文件以外，还有其他选择吗?
• 是否存在减少实例数量的明显问题?
• Azure需要多少时间来确认"应用程序的缩减?

关于后一个问题:在极端情况下，您有大量实例(例如1000个)运行了45分钟.如果Azure在该过程结束后15分钟内无法注意到缩减规模，则会向您收取另外1000个计算时间的费用.

解决方案

您是正确的，您是为正常运行时间付费，而不是为计算时间付费.

需警惕的是，您不按比例分配部分时间的工资，因此，如果您迅速扩大规模和缩减规模，则意味着您在吃饱时间.

正如其他人所提到的，您可以在应用程序内以编程方式向上和向下缩放.但是，通常，特定角色只能访问其自己的指标(除非您将指标保存到存储中)，再加上任何全局资源指标(队列长度等)，因此基于CPU利用率等进行扩展可能会很困难.

在一台机器上花几分钟的时间进行旋转，放大几乎立即开始.当前没有提供提速的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屋！