Azure Stack の容量計画Azure Stack capacity planning

Azure Stack ソリューションを評価するときに、Azure Stack クラウドのキャパシティ全体に直接影響するハードウェア構成を選択することができます。When evaluating an Azure Stack Solution, there are hardware configuration choices that have a direct impact on the overall capacity of the Azure Stack Cloud. CPU、メモリ密度、ストレージ構成、全体的なソリューションの規模 (つまり、サーバー数) といった従来の選択肢があります。These are the classic choices of CPU, memory density, storage configuration, and overall solution scale or number of servers. 以前の仮想化ソリューションとは異なり、これらのコンポーネントを単純に計算して使用可能なキャパシティを決定することはできません。Unlike a traditional virtualization solution, the simple arithmetic of these components to determine usable capacity does not apply. その 1 つ目の理由は、Azure Stack が、ソリューション自体の中でインフラストラクチャまたは管理コンポーネントをホストするように設計されているためです。The first reason for this is that Azure Stack is architected to host the infrastructure or management components within the solution itself. 2 つ目の理由は、ソリューションのキャパシティの一部が、回復性をサポートするために予約されることです。つまり、テナントのワークロードの中断を最小限に抑える方法で、ソリューションのソフトウェアが更新されます。The second reason is that some of the solution’s capacity is reserved in support of resiliency; the updating of the solution’s software in a way to minimize disruption of tenant workloads.


容量計画の情報と、付属のスプレッドシートがガイドとしてのみ提供されており、Azure Stack の計画と構成を決定するのに役立ちます。The provided capacity planning information, and accompanying spreadsheet, are intended only as a guide to help you make Azure Stack planning and configuration decisions. これらは、独自の調査や分析に代わるものとしては利用できません。They are not intended to serve as a substitute for your own investigation and analysis.

コンピューティングおよびストレージ容量の計画Compute and storage capacity planning

Azure Stack ソリューションは、コンピューティング、ネットワーク、およびストレージのハイパーコンバージド クラスターとして構築されています。An Azure Stack Solution is built as a hyper-converged cluster of compute, networking, and storage. これにより、可用性とスケーラビリティを提供する方法で、クラスター (Azure Stack 用のスケール ユニットと呼ばれる) 内のすべてのハードウェア容量を効率的に使用したり、共有したりすることができます。This allows effective use or sharing of all hardware capacity in the cluster, referred to as a Scale Unit for Azure Stack, in a way that provides availability and scalability. すべてのインフラストラクチャ ソフトウェアは一連の仮想マシン (VM) 内でホストされ、テナント VM と同じ物理サーバーを共有します。All infrastructure software is hosted within a set of virtual machines (VMs) and shares the same physical servers as the tenant VMs. その後、すべての VM はスケール ユニットの Windows Server クラスタリング テクノロジと個々の Hyper-V インスタンスによって管理されます。All VMs are then managed by the Scale Unit’s Windows Server clustering technologies and individual Hyper-V instances. この方法では、Azure Stack ソリューションの取得と管理が簡素化され、スケール ユニット全体のすべてのサービスの移動とスケーラビリティに有効です。This approach simplifies the acquisition and management of an Azure Stack solution and affords for the movement and scalability of all services (tenant and infrastructure) across the entirety of the Scale Unit.

Azure Stack ソリューションでオーバープロビジョニングされない唯一の物理リソースは、サーバーのメモリです。The only physical resource that is not over-provisioned in an Azure Stack solution is server memory. 他のリソース、CPU コア、ネットワーク帯域幅、およびストレージ容量は、利用可能なリソースを最大限活用するためにオーバープロビジョニングされます。The other resources, CPU cores, networking bandwidth, and storage capacity, will be overprovisioned to make the best use of available resources. ソリューションで、利用可能な容量を計算するときの主要因子は物理サーバー メモリです。When calculating available capacity for a solution, physical server memory is the main contributor. したがって、その他のリソースの使用率で、考えられるオーバープロビジョニングの比率と、対象ワークロードで受け入れられる内容が判断されます。The utilization of other resources is then understanding the ratio of overprovisioning that is possible and what will be acceptable to the intended workload.

約 28 個の VM が Azure Stack のインフラストラクチャをホストするために使用され、合計で約 208 GB のメモリと 124 個の仮想コアが消費されます。Approximately 28 VMs are used to host Azure Stack’s infrastructure and, in total, consume about 208 GB of memory and 124 virtual cores. この VM の数の論理的根拠は、セキュリティ、スケーラビリティ、サービス提供および修正プログラムの適用に関する要件を満たすために必要なサービス分離を行うことです。The rationale for this number of VMs is to satisfy the needed service separation to meet security, scalability, servicing and patching requirements. この内部サービス構造により、今後、新しいインフラストラクチャ サービスが開発されたときに、そのサービスを導入できるようになります。This internal service structure allows for the future introduction of new infrastructure services as they are developed.

すべての物理サーバーおよびインフラストラクチャ ソフトウェア コンポーネントの自動更新をサポートするため、あるいは修正プログラムおよび更新プログラムを適用するために、インフラストラクチャとユーザーの VM の配置でスケール ユニットのすべてのメモリ リソースが消費されることはありません。To support the automated update of all physical server and infrastructure software components, or patch and update, infrastructure and user VM placements will not consume all memory resources of the Scale Unit. スケール ユニットのサーバー全体の合計メモリ量は、ソリューションの回復性要件をサポートするために未割り当てとなります。An amount of the total memory across all servers of a Scale Unit will be unallocated in support of the solution’s resiliency requirements. たとえば、物理サーバーの Windows Server イメージが更新された場合、そのサーバーの Windows Server イメージの更新中に、サーバーでホストされている VM がスケール ユニット内の別の場所に移動されます。For example, when the physical server's Windows Server image is updated, the VMs hosted on the server are moved elsewhere within the Scale Unit while the server’s Windows Server images is updated. 更新が完了すると、サーバーは再起動され、サービス ワークロードに戻されます。When the update is complete, the server is restarted and returned to servicing workloads. Azure Stack ソリューションの修正プログラムと更新プログラムの目標は、ホストされている VM を停止する必要をなくすことです。The goal for the patch and update of an Azure Stack solution is to avoid the need to stop hosted VMs. その目標の達成に努めるため、スケール ユニット内の VM が移動できるように、1 つのサーバーの最小限のメモリ容量が未割り当てになっています。In striving to meet that goal, a bare minimum of one server’s memory capacity is unallocated to allow for the movement of VMs within the Scale Unit. この配置と移動は、Azure Stack ソリューションのユーザーまたはテナントに代わって作成される VM とインフラストラクチャの VM の両方に適用されます。This placement and movement applies to both infrastructure VMs and VMs created on the behalf of the user or tenant of the Azure Stack solution. 最終的な実装の結果として、VM にさまざまなメモリ要件がある場合に配置に関する課題があるため、単一サーバーの容量よりも必要な VM の移動をサポートするために予約されるメモリ量をはるかに多くすることができます。The final implementation results are such that the amount of memory reserved to support the needed VM movement can be much more than a single server’s capacity because of placement challenges when VMs have varying memory requirements. メモリ使用量のカテゴリ内の追加のオーバーヘッドは、Windows Server インスタンス自体のものです。An additional overhead in the category of memory use is that of the Windows Server instance itself. サーバーごとの基本的なオペレーティング システムのインスタンスでは、オペレーティング システムとその仮想ページ テーブル用のメモリと、ホストされている各 VM を管理するために Hyper-V で使用されるメモリが消費されます。The base operating system instance for each server will consume memory for the operating system and its virtual page tables along with the memory used by Hyper-V in managing each of the hosted VMs.

キャパシティ計算の複雑さについては、このセクションの後半で詳しく説明します。A further description of the complexities of capacity calculations is describe later in this section. この概要では、以下の例を提供します。これは、さまざまなソリューション サイズの利用可能なキャパシティについて理解するのに役立ちます。In this introduction, the following examples are provided to assist in understanding the available capacity of varying solution sizes. これらは概算です。したがって、運用インストール環境には当てはまらない可能性があるテナント VM メモリ使用量についての憶測となります。These are estimates and as a result make assumptions about tenant VM memory use that may not be true for production installations. 次の表では、Standard D2 という Azure VM のサイズが使用されています。For this table, the Standard D2 Azure VM size is used. Azure の Standard D2 VM は、2 つの仮想 CPU と 7 GB のメモリで定義されています。Azure Standard D2 VMs are defined with 2 virtual CPUs and 7 GB of memory.

サーバーあたりの容量Per Server Capacity スケール ユニットの容量Scale Unit Capacity
メモリMemory CPU コアCPU Cores サーバーの数Number of servers メモリMemory CPU コアCPU Cores テナント VM1Tenant VMs1 コア比2Core ratio2
例 1Example 1 256 GB256 GB 2828 44 1,024 GB1024 GB 112112 5454 4:34:3
例 2Example 2 512 GB512 GB 2828 44 2024 GB2024 GB 112112 144144 4:14:1
例 3Example 3 384 GB384 GB 2828 1212 4,608 GB4608 GB 336336 432432 3:13:1

1 Standard D2 VM。1 Standard D2 VMs.

2 仮想コア対物理コア比。2 Virtual core to physical core ratio.

前述のように、VM の容量は利用可能なメモリによって決まります。As mentioned above, the VM capacity is determined by available memory. 仮想コア対物理コア比は、ソリューションが多くの数の物理コアで作成された (別の CPU が選択された) 場合を除き、VM 密度によって利用可能な CPU 容量がどのように変わるかを例示するものです。The virtual-cores to physical-core ratios exemplify how the VM density will change available CPU capacity unless the solution is constructed with a larger number of physical cores (another CPU is chosen). 同じことが、ストレージ容量とストレージ キャッシュ容量にも当てはまります。The same is true of storage capacity and storage cache capacity.

VM 密度の上記の例は単に説明するためのものです。The above examples of VM density are for explanation purposes only. サポートされる計算ではさらに複雑になります。There is further complexity in the calculations in support. 容量計画の選択肢および結果として得られる利用可能な容量についてさらに理解するには、Microsoft またはソリューション パートナーに連絡する必要があります。Contact with Microsoft or a solution partner is required to further understand capacity planning choices and the resulting, available capacity.

このセクションの残りの部分では、コンピューティングおよびストレージに関する Azure Stack デプロイ要件について説明します。The remainder of this section describes Azure Stack deployment requirements for compute and storage. この情報を利用して、必要なコンポーネントとその最小構成値の基本を理解します。Use this information to gain a base understanding of what components are required and their minimum configuration values. 利用可能な容量に関するソリューションの構成方法、およびテナントの容量とパフォーマンス能力に関するシステムの潜在的な制限について説明するために、追加情報も提供されます。Additional information is also provided to describe how the solution is configured with regards to available capacity and potential limits of the system with regard to tenant capacity and performance capability.


ネットワークに関する容量計画要件は、パブリック VIP のサイズが構成可能である場合にのみ、最小要件となります。The capacity planning requirements for networking are minimal as only the size of the Public VIP is configurable. Azure Stack にパブリック IP アドレスをさらに追加する方法については、「Add Public IP Addresses」 (パブリック IP アドレスの追加) を参照してください。For information about how to add more Public IP Addresses to Azure Stack see Add Public IP Addresses.

次の手順Next steps

コンピューティング能力の計画Compute capacity planning