次の方法で共有

Azure で Cloud Services (クラシック) をデプロイするときの割り当てエラーのトラブルシューティング

  • [アーティクル]

重要

Cloud Services (クラシック) は、2024 年 9 月 1 日をもって、すべてのお客様に対して非推奨になりました。 実行中の既存のデプロイはすべて Microsoft によって停止およびシャットダウンされ、2024 年 10 月以降、そのデータは永久に失われます。 新しいデプロイでは、新しい Azure Resource Manager ベースのデプロイ モデル、 Azure Cloud Services (延長サポート) を使用してください。

まとめ

インスタンスをクラウド サービスにデプロイした場合や、新しい Web ロール インスタンスまたは worker ロール インスタンスを追加した場合に、Microsoft Azure によってコンピューティング リソースが割り当てられます。 これらの操作をしているときに、Azure サブスクリプションの制限に達していなくても、エラーが発生する場合があります。 この記事では、いくつかの一般的な割り当てエラーの原因を説明し、可能な改善方法を提案します。 この情報は、サービスのデプロイを計画する場合にも役立ちます。

この記事で Azure の問題に対処できない場合は、「Microsoft Q & A と Stack Overflow」の Azure 関連フォーラムを参照してください。 問題をこれらのフォーラムに投稿するか、または Twitter の @AzureSupport に投稿できます。 Azure サポート要求を送信することもできます。 サポート要求を送信するには、[Azure サポート] ページで [サポートを受ける] を選択します。

背景情報 – 割り当てのしくみ

Azure データセンターのサーバーは、クラスターにパーティション分割されています。 複数のクラスターで、新しいクラウド サービスの割り当て要求が試みられます。 最初のインスタンスを (ステージング環境または運用環境の) クラウド サービスにデプロイすると、このクラウド サービスは 1 つのクラスターに固定されます。 このクラウド サービスでさらにデプロイすると、すべて同じクラスターで処理されます。 この記事では、この状態を "クラスターに固定されている" と言います。次の図は、複数のクラスターで試行される通常の割り当てを示しています。 2 番目の図は、クラスター 2 に固定されている割り当てを示しています。これは、既存のクラウド サービス CS_1 がクラスター 2 でホストされているためです。

Allocation Diagram

割り当てエラーが発生する理由

割り当て要求がクラスターに固定されている場合、利用可能なリソース プールが 1 つのクラスターに制限されるため、空きリソースを見つけられない可能性が高くなります。 さらに、割り当て要求がクラスターに固定されていて、そのクラスターで要求したリソースの種類がサポートされていない場合、クラスターに空きリソースがあっても、要求は失敗します。 次の図は、唯一の候補であるクラスターに空きリソースがないため、固定された割り当てがエラーになる場合を示しています。 図 4 は、唯一の候補であるクラスターに空きリソースがあるものの、要求された仮想マシン (VM) サイズがサポートされていないため、固定された割り当てがエラーになる場合を示しています。

Pinned Allocation Failure

クラウド サービスの割り当てエラーのトラブルシューティング

エラー メッセージ

Azure portal で、ご利用のクラウド サービスに移動し、サイドバーの [操作ログ (クラシック)] を選択してログを表示します。

各例外について、以下のさらなる解決策を参照してください。

例外の種類 エラー メッセージ 解決策
FabricInternalServerError 操作は、エラー コード 'InternalError' とエラー メッセージ 'サーバーで内部エラーが発生しました。 要求をもう一度お試しください。' で失敗しました。 FabricInternalServerError のトラブルシューティング
ServiceAllocationFailure 操作は、エラー コード 'InternalError' とエラー メッセージ 'サーバーで内部エラーが発生しました。 要求をもう一度お試しください。' で失敗しました。 ServiceAllocationFailure のトラブルシューティング
LocationNotFoundForRoleSize 操作 '{Operation ID}' が失敗しました: '要求された VM 層は、現在、このサブスクリプションのリージョン ({Region ID}) では利用できません。 別の層を試すか、別の場所にデプロイしてください。'。 LocationNotFoundForRoleSize のトラブルシューティング
ConstrainedAllocationFailed Azure 操作 '{Operation ID}' がコード Compute.ConstrainedAllocationFailed で失敗しました。 詳細:割り当てに失敗しました。要求の制約条件を満たしていません。 要求されている新しいサービスのデプロイがアフィニティ グループにバインドされているか、仮想ネットワークを対象としています。または、このホストされるサービスに既存のデプロイがあります。 ここに挙げた条件に該当する場合には、新しいデプロイが特定の Azure リソースに制限されます。 後でもう一度やり直すか、VM サイズを小さくするか、ロール インスタンスの数を減らしてください。 可能な場合には、制約条件を削除することや、別のリージョンにデプロイすることもできます。 ConstrainedAllocationFailed のトラブルシューティング
OverconstrainedAllocationRequest デプロイ要求の制約条件のため、このデプロイに必要な VM サイズ (または VM サイズの組み合わせ) をプロビジョニングできません。 可能であれば、仮想ネットワークのバインドなどの制約条件の緩和、他のデプロイがなくアフィニティ グループが異なるホステッド サービスへのデプロイ、アフィニティ グループのないホステッド サービスへのデプロイ、別のリージョンへのデプロイのいずれかを試してください。 OverconstrainedAllocationRequest のトラブルシューティング

サンプルのエラー メッセージ:

"Azure 操作 '{操作 ID}' がコード Compute.ConstrainedAllocationFailed で失敗しました。 詳細:割り当てに失敗しました。要求の制約条件を満たしていません。 要求されている新しいサービスのデプロイがアフィニティ グループにバインドされているか、仮想ネットワークを対象としています。または、このホストされるサービスに既存のデプロイがあります。 ここに挙げた条件に該当する場合には、新しいデプロイが特定の Azure リソースに制限されます。 後でもう一度やり直すか、VM サイズを小さくするか、ロール インスタンスの数を減らしてください。 可能な場合には、上に挙げた制約条件を削除することや、別のリージョンにデプロイすることもできます。"

一般的な問題

以下に、割り当て要求が単一のクラスターに固定される原因となる一般的な割り当てシナリオを示します。

  • ステージング スロットへのデプロイ - クラウド サービスをいずれかのスロットにデプロイすると、クラウド サービス全体が特定のクラスターに固定されます。 つまり、運用スロットにデプロイが既に存在する場合、新しいステージング環境のデプロイは、運用スロットと同じクラスターにしか割り当てることができません。 クラスターが限界に近づくと、要求が失敗する場合があります。
  • スケーリング - 既存のクラウド サービスに新しいインスタンスを追加する場合は、同じクラスターに割り当てる必要があります。 通常、小規模のスケーリング要求は割り当てることができますが、常に割り当てることができるわけではありません。 クラスターが限界に近づくと、要求が失敗する場合があります。
  • アフィニティ グループ - クラウド サービスがアフィニティ グループに固定されている場合を除き、そのリージョン内の任意のクラスターのファブリックによって、新しいデプロイを空のクラウド サービスに割り当てることができます。 デプロイでは、同じクラスター上の同じアフィニティ グループの使用が試行されます。 クラスターが限界に近づくと、要求が失敗する場合があります。
  • アフィニティ グループの仮想ネットワーク - 以前の仮想ネットワークはリージョンではなくアフィニティ グループに関連付けられていたため、これらの仮想ネットワーク内のクラウド サービスはアフィニティ グループのクラスターに固定されました。 このような仮想ネットワークへのデプロイは、固定されたクラスターで試行されます。 クラスターが限界に近づくと、要求が失敗する場合があります。

ソリューション

  1. 新しいクラウド サービスに再デプロイする - この解決方法ではそのリージョン内のすべてのクラスターからプラットフォームを選択できるため、成功する可能性が最も高くなります。

    • 新しいクラウド サービスにワークロードをデプロイします
    • 新しいクラウド サービスへのトラフィックを指すように CNAME または A レコードを更新します
    • 以前のサイトに送信されるトラフィックが 0 個になると、以前のクラウド サービスを削除できます。 この解決方法ではダウンタイムは発生しません。

  2. 運用スロットとステージング スロットの両方を削除する - この解決方法では、既存のドメイン ネーム システム (DNS) 名が維持されますが、アプリケーションでダウンタイムが発生します。

    • 既存のクラウド サービスの運用スロットとステージング スロットを削除し、クラウド サービスを空にします。
    • 次に、既存のクラウド サービスに新しいデプロイを作成します。 この解決方法では、リージョン内のすべてのクラスターで割り当てが再度試行されます。 クラウド サービスがアフィニティ グループに関連付けられていないことを確認します。

  3. 予約済み IP - この解決方法では、既存の IP アドレスが維持されますが、アプリケーションでダウンタイムが発生します。

    • PowerShell を使用して既存のデプロイ用の ReservedIP を作成します

      New-AzureReservedIP -ReservedIPName {new reserved IP name} -Location {location} -ServiceName {existing service name}

    • #2 に従って、サービスの CSCFG で新しい ReservedIP を確実に指定します。

  4. 新しいデプロイのアフィニティ グループを削除する - アフィニティ グループは推奨されなくなりました。 #1 の手順に従って、新しいクラウド サービスをデプロイします。 クラウド サービスがアフィニティ グループ内にないことを確認します。

  5. リージョンでの仮想ネットワークに変換する - アフィニティ グループからリージョンでの仮想ネットワーク (仮想ネットワーク) に移行する方法を参照してください。