Azure 云服务的部署问题:常见问题 (FAQ)Deployment issues for Azure Cloud Services: Frequently asked questions (FAQs)

本文包含 Azure 云服务的常见部署问题。This article includes frequently asked questions about deployment issues for Azure Cloud Services. 还可以参阅云服务 VM 大小页面,了解大小信息。You can also consult the Cloud Services VM Size page for size information.

如果本文未解决你的 Azure 问题,请访问 MSDN 和 CSDN 上的 Azure 论坛。If your Azure issue is not addressed in this article, visit the Azure forums on MSDN and CSDN. 可以在这些论坛上发布问题。You can post your issue in these forums. 还可提交 Azure 支持请求。You also can submit an Azure support request. 若要提交支持请求,请在 Azure 支持页上提交。To submit a support request, on the Azure support page.

如果生产槽中存在现有的部署,将云服务部署到过渡槽为何有时失败并出现资源分配错误?Why does deploying a cloud service to the staging slot sometimes fail with a resource allocation error if there is already an existing deployment in the production slot?

如果某个云服务在任一槽中存在部署,则会将整个云服务固定到特定的群集。If a cloud service has a deployment in either slot, the entire cloud service is pinned to a specific cluster. 这意味着,如果生产槽中已存在部署,则只能将新的过渡部署分配到与生产槽相同的群集中。This means that if a deployment already exists in the production slot, a new staging deployment can only be allocated in the same cluster as the production slot.

如果云服务所在的群集没有足够的物理计算资源用于满足部署请求,则会发生分配失败。Allocation failures occur when the cluster where your cloud service is located does not have enough physical compute resources to satisfy your deployment request.

有关解决此类分配失败的帮助,请参阅云服务分配失败:解决方法For help with mitigating such allocation failures, see Cloud Service allocation failure: Solutions.

为何纵向扩展或横向扩展云服务部署有时会导致分配失败?Why does scaling up or scaling out a cloud service deployment sometimes result in allocation failure?

部署云服务后,该服务通常会固定到特定的群集。When a cloud service is deployed, it usually gets pinned to a specific cluster. 这意味着,纵向扩展/横向扩展现有的云服务时必须在同一群集中分配新实例。This means scaling up/out an existing cloud service must allocate new instances in the same cluster. 如果群集接近容量限制或所需的 VM 大小/类型不可用,则请求可能会失败。If the cluster is nearing capacity or the desired VM size/type is not available, the request may fail.

有关解决此类分配失败的帮助,请参阅云服务分配失败:解决方法For help with mitigating such allocation failures, see Cloud Service allocation failure: Solutions.

为何将云服务部署到地缘组有时会导致分配失败?Why does deploying a cloud service into an affinity group sometimes result in allocation failure?

进行新的目标为空云服务的部署时,可以通过该区域任何群集中的结构对部署进行分配,除非已将云服务固定到地缘组。A new deployment to an empty cloud service can be allocated by the fabric in any cluster in that region, unless the cloud service is pinned to an affinity group. 将会在相同的群集中尝试部署到相同的地缘组。Deployments to the same affinity group will be attempted on the same cluster. 如果群集已接近容量限制,则请求可能失败。If the cluster is nearing capacity, the request may fail.

有关解决此类分配失败的帮助,请参阅云服务分配失败:解决方法For help with mitigating such allocation failures, see Cloud Service allocation failure: Solutions.

为何更改 VM 大小或将新 VM 添加到现有云服务有时会导致分配失败?Why does changing VM size or adding a new VM to an existing cloud service sometimes result in allocation failure?

数据中心内的群集可能使用不同的计算机类型配置(例如,A 系列、Av2 系列、D 系列、Dv2 系列,等等)。The clusters in a datacenter may have different configurations of machine types (e.g., A series, Av2 series, D series, Dv2 series, etc.). 但是,并非所有群集都一定要包含所有类型的 VM。But not all the clusters would necessarily have all the kinds of VMs. 例如,如果尝试将 D 系列 VM 添加到已在仅限 A 系列的群集中部署的云服务,则会发生分配失败。For example, if you try to add a D series VM to a cloud service that is already deployed in an A series-only cluster, you will experience an allocation failure. 如果尝试更改 VM SKU 大小(例如,从 A 系列切换到 D 系列),也会发生此问题。This will also happen if you try to change VM SKU sizes (for example, switching from an A series to a D series).

有关解决此类分配失败的帮助,请参阅云服务分配失败:解决方法For help with mitigating such allocation failures, see Cloud Service allocation failure: Solutions.

部署云服务时,有时为何由于订阅或服务上的限制/配额/约束而发生失败?Why does deploying a cloud service sometime fail due to limits/quotas/constraints on my subscription or service?

如果需要分配的资源超过区域/数据中心级别的服务允许的默认或最大配额,部署云服务可能会失败。Deployment of a cloud service may fail if the resources that are required to be allocated exceed the default or maximum quota allowed for your service at the region/datacenter level. 有关详细信息,请参阅云服务限制For more information, see Cloud Services limits.

还可以在门户上跟踪订阅的当前使用情况/配额:Azure 门户 => 订阅 => <相应订阅> =>“使用情况 + 配额”。You could also track the current usage/quota for your subscription at the portal: Azure Portal => Subscriptions => <appropriate subscription> => “Usage + quota”.

如何更改已部署的云服务 VM 的大小而不用重新部署它?How can I change the size of a deployed cloud service VM without redeploying it?

在不重新部署的情况下,无法更改已部署的云服务的 VM 大小。You cannot change the VM size of a deployed cloud service without redeploying it. VM 大小内置在 CSDEF 中,只能通过重新部署来更新。The VM size is built into the CSDEF, which can only be updated with a redeploy.

有关详细信息,请参阅如何更新云服务For more information, see How to update a cloud service.

使用 Azure 资源管理器存储帐户时,为什么不能够通过服务管理 API 或 PowerShell 部署云服务?Why am I not able to deploy Cloud Services through Service Management APIs or PowerShell when using Azure Resource Manager Storage account? 

由于云服务不是直接与 Azure 资源管理器模型兼容的经典资源,因此不能将其与 Azure 资源管理器存储帐户相关联。Since the Cloud Service is a Classic resource that is not directly compatible with the Azure Resource Manager model, you can't associate it with the Azure Resource Manager Storage accounts. 下面是几个选项:Here are few options: 

  • 通过 REST API 部署。Deploying through REST API.

    通过服务管理 REST API 部署时,可以通过指定指向 blob 存储(同时使用经典和 Azure 资源管理器存储帐户)的 SAS URL 绕过限制。When you deploy through Service Management REST API, you could get around the limitation by specifying a SAS URL to the blob storage, which will work with both Classic and Azure Resource Manager Storage account. 此处阅读有关 PackageUrl 属性的详细信息。Read more about the 'PackageUrl' property here.  

  • 通过 Azure 门户部署。Deploying through Azure portal.

    这将从 Azure 门户进行,因为调用将通过一个代理/填充程序完成,该代理/填充程序使得 Azure 资源管理器可以与经典资源通信。This will work from the Azure portal as the call goes through a proxy/shim that allows communication between Azure Resource Manager and Classic resources. 

为什么 Azure 门户要求提供存储帐户才能进行部署?Why does Azure portal require me to provide a storage account for deployment?

在经典门户中,用户首先将包直接上传到管理 API 层,然后 API 层会临时将包置于内部存储帐户中。In the classic portal, the package was uploaded to the management API layer directly, and then the API layer would temporarily put the package into an internal storage account. 此过程会引发性能和可伸缩性问题,因为按照设计,API 层不是一项文件上传服务。This process causes performance and scalability problems because the API layer was not designed to be a file upload service. 在 Azure 门户(资源管理器部署模型)中,我们跳过了首先将包上传到 API 层这个中间步骤,加快了部署速度,使部署更可靠。In the Azure portal (Resource Manager deployment model), we have bypassed the interim step of first uploading to the API layer, resulting in faster and more reliable deployments.

这样做的代价很低,而好处则是可以在所有部署中重复使用同一存储帐户。As for the cost, it is very small and you can reuse the same storage account across all deployments. 可以使用存储费用计算器来确定服务包 (CSPKG) 的上传、下载和删除费用。You can use the storage cost calculator to determine the cost to upload the service package (CSPKG), download the CSPKG, then delete the CSPKG.