Azure Stack コンピューティング能力の計画Azure Stack compute capacity planning

Azure Stack でサポートされる VM サイズは、Azure でサポートされているもののサブセットです。The VM sizes supported on Azure Stack are a subset of those supported on Azure. Azure では、リソース (サーバーのローカルおよびサービス レベル) の過剰消費を防ぐため、多くのベクターに沿ってリソースの制限を適用します。Azure imposes resource limits along many vectors to avoid overconsumption of resources (server local and service-level). テナントの消費量にいくつかの制限を適用しないと、あるテナントでリソースが過剰消費された場合に、別のテナントのエクスペリエンスに影響します。Without imposing some limits on tenant consumption, the tenant experiences will suffer when other tenants overconsume resources. VM からのネットワーク送信の場合、Azure Stack では Azure の制限と一致する帯域幅の上限が設けられます。For networking egress from the VM, there are bandwidth caps in place on Azure Stack that match Azure limitations. ストレージ リソースの場合、テナントによるストレージ アクセスのためのリソースの基本的な過剰消費を防ぐため、Azure Stack にストレージ IOPS 制限が実装されています。For storage resources, storage IOPs limits have been implemented on Azure Stack to avoid basic overconsumption of resources by tenants for storage access.

VM の配置および物理コアに対する仮想コアのオーバープロビジョニングVM placement and virtual to physical core overprovisioning

Azure Stack には、テナントで、VM 配置のために使用する特定のサーバーを指定する方法はありません。In Azure Stack, there is no way for a tenant to specify a specific server to use for VM placement. VM を配置するときの唯一の考慮事項は、その VM の種類に対して十分なメモリがホスト上にあるかどうかです。The only consideration when placing VMs is whether there is enough memory on the host for that VM type. Azure Stack ではメモリがオーバーコミットされることはありませんが、コア数のオーバーコミットは許容されます。Azure Stack does not overcommit memory; however, an overcommit of the number of cores is allowed. 配置アルゴリズムでは、物理コアに対して仮想コアがどの程度オーバープロビジョニングされているかを考慮しないため、各ホストの比率が異なる可能性があります。Since placement algorithms do not look at the existing virtual to physical core overprovisioning ratio as a factor, each host could have a different ratio.

Azure では、マルチ VM 運用システムの高可用性を実現するため、VM が複数の障害ドメインに分散される可用性セットに配置されます。In Azure, to achieve high availability of a multi-VM production system, VMs are placed in an availability set to be spread across multiple fault domains. つまり、可用性セットに配置された VM は、次の図に示すように、障害からの回復性を考慮してラックで互いに物理的に分離されています。This would mean that VMs placed in an availability set are physically isolated from each other at a rack to allow for failure resiliency as shown in the following diagram:


Azure Stack のインフラストラクチャは障害に対する回復性を備えていますが、基盤となっているテクノロジ (フェールオーバー クラスタリング) では、ハードウェア障害が発生した場合にその影響を受ける物理サーバー上の VM に多少のダウンタイムが発生します。While the infrastructure of Azure Stack is resilient to failures, the underlying technology (failover clustering) still incurs some downtime for VMs on an impacted physical server in the event of a hardware failure. 現在、Azure Stack では、Azure との一貫性がある最大 3 つの障害ドメインを含む可用性セットを用意することがサポートされています。Currently, Azure Stack supports having an availability set with a maximum of three fault domains to be consistent with Azure. 可用性セットに配置された VM は、複数の障害ドメイン (Azure Stack ノード) にできる限り均等に分散させることによって、互いに物理的に分離されます。VMs placed in an availability set will be physically isolated from each other by spreading them as evenly as possible over multiple fault domains (Azure Stack nodes). ハードウェア障害が発生した場合、障害が発生した障害ドメインの VM は他のノードで再起動されますが、可能であれば、同じ可用性セット内の他の VM とは別の障害ドメインに保持されます。If there is a hardware failure, VMs from the failed fault domain will be restarted in other nodes, but, if possible, kept in separate fault domains from the other VMs in the same availability set. ハードウェアがオンラインに戻ると、高可用性を維持するために VM の再配置が行われます。When the hardware comes back online, VMs will be rebalanced to maintain high availability.

高可用性を実現するために Azure で使用されているもう 1 つの概念は、可用性セット内の更新ドメインです。Another concept that is used by Azure to provide high availability is in the form of update domains in availability sets. 更新ドメインは、メンテナンスや再起動が同時に行われる可能性のある、基盤となるハードウェアの論理グループです。An update domain is a logical group of underlying hardware that can undergo maintenance or be rebooted at the same time. Azure Stack では、VM のホストが更新される前に、クラスター内の他のオンライン ホストに VM がライブ マイグレーションされます。In Azure Stack, VMs are live migrated across the other online hosts in the cluster before their underlying host is updated. ホスト更新の際にテナントのダウンタイムは発生しないため、Azure Stack の更新ドメイン機能は、Azure とテンプレートの互換性を保つためにのみ存在します。Since there is no tenant downtime during a host update, the update domain feature on Azure Stack only exists for template compatibility with Azure.

Azure Stack の回復性のあるリソースAzure Stack resiliency resources

Azure Stack 統合システムへ修正プログラムや更新プログラムを適用するため、また、物理的なハードウェア障害に対する回復性を持たせるために、サーバーの合計メモリの一部は予約されており、テナントの仮想マシン (VM) に割り当てて使用することはできません。To allow for patch and update of an Azure Stack integrated system, and to be resilient to physical hardware failures, a portion of the total server memory is reserved and unavailable for tenant virtual machine (VM) placement.

サーバーで障害が発生した場合、障害が発生したサーバー上でホストされていた VM は、残りの利用可能なサーバー上で再起動され、利用可能な状態となります。If a server fails, VMs hosted on the failed server will be restarted on remaining, available servers to provide for VM availability. 同様に、修正プログラムや更新プログラムを適用する際は、サーバー上で実行されているすべての VM が他の利用可能なサーバーにライブ マイグレーションされます。Similarly, during the patch and update process, all VMs running on a server will be live migrated to other available, server. この様な VM の制御または移動は、再起動やマイグレーションを実施可能な予約容量がある場合のみ実現できます。This VM management or movement can only be achieved if there is reserved capacity to allow for the restart or migration to occur.

次の計算では、テナントの VM に利用可能なメモリの合計が算出されます。The following calculation results in the total, available memory that can be used for tenant VM placement. このメモリ容量は、Azure Stack スケール ユニット全体に対するものです。This memory capacity is for the entirety of the Azure Stack Scale Unit.

テナントの VM で利用可能なメモリ = サーバーのメモリ合計 – 回復性のための予約 – Azure Stack インフラストラクチャのオーバーヘッド 1Available Memory for VM placement = Total Server Memory – Resiliency Reserve – Azure Stack Infrastructure Overhead 1

回復性のための予約 = H + R * (N-1) + V * (N-2)Resiliency reserve = H + R * (N-1) + V * (N-2)


  • H = 単一サーバーのメモリ サイズH = Size of single server memory
  • N = スケール ユニットのサイズ (サーバーの数)N = Size of Scale Unit (number of servers)
  • R = OS オーバーヘッドのためのオペレーティング システムの予約2R = Operating system reserve for OS overhead2
  • V = スケール ユニット内で最大の VM (メモリ サイズ)V = Largest VM in the scale unit

1 Azure Stack インフラストラクチャのオーバーヘッド = 208 GB1 Azure Stack Infrastructure Overhead = 208 GB

2 オーバーヘッドのためのオペレーティング システムの予約 = ノード メモリの 15%。2 Operating system reserve for overhead = 15% of node memory. オペレーティング システムの予約値は概算であり、サーバーおよび一般的なオペレーティング システムのオーバーヘッドの物理メモリ容量によって異なります。The operating system reserve value is an estimate and will vary based on the physical memory capacity of the server and general operating system overhead.

値 V (スケール ユニット内で最大の VM) はテナント VM における最大のメモリ サイズで、動的に変動します。The value V, largest VM in the scale unit, is dynamically based on the largest tenant VM memory size. たとえば、V の値は、7 GB、112 GB、または Azure Stack ソリューションでサポートされるその他の VM のメモリ サイズとなる場合があります。For example, the largest VM value could be 7 GB or 112 GB or any other supported VM memory size in the Azure Stack solution.

上記の計算は概算であり、Azure Stack の現行バージョンに基づいて変更される可能性があります。The above calculation is an estimate and subject to change based on the current version of Azure Stack. テナントの VM とサービスをデプロイできるかどうかは、デプロイされるソリューションの詳細に依存します。Ability to deploy tenant VMs and services is based on the specifics of the deployed solution. この計算例は単なるガイドであり、VM をデプロイできるかどうかを保証するものではありません。This example calculation is just a guide and not the absolute answer of the ability to deploy VMs.

次の手順Next steps

ストレージ容量の計画Storage capacity planning