[ English | Indonesia | Deutsch | 日本語 ]

キャパシティプランニングとスケーラビリティー

Cloud-based applications typically request more discrete hardware (horizontal scaling) as opposed to traditional applications, which require larger hardware to scale (vertical scaling).

OpenStack は水平的にスケーリングできるように設計されています。容量の大きいサーバーに切り替えるのではなく、サーバーを多く調達して同じように設定したサービスをインストールするだけです。理想としては、メッセージバスを通信する、機能的に同じサービス (例: コンピュートノードや nova-api ノード) グループでスケールアウト、負荷分散します。

Determining cloud scalability

Determining the scalability of your cloud and how to improve it requires balancing many variables. No one solution meets everyone's scalability goals. However, it is helpful to track a number of metrics. You can define virtual hardware templates called "flavors" in OpenStack, which will impact your cloud scaling decisions. These templates define sizes for memory in RAM, root disk size, amount of ephemeral data disk space available, and the number of CPU cores.

デフォルトの OpenStack フレーバーは 表: OpenStack デフォルトのフレーバー に表示されています。

表: OpenStack デフォルトのフレーバー

名前

仮想コア数

メモリ

ディスク

エフェメラル

m1.tiny

1

512 MB

1 GB

0 GB

m1.small

1

2 GB

10 GB

20 GB

m1.medium

2

4 GB

10 GB

40 GB

m1.large

4

8 GB

10 GB

80 GB

m1.xlarge

8

16 GB

10 GB

160 GB

まずクラウドのコア数から始めます。比率を適用することで、以下の情報を取得できます。

  • 実行する必要のある仮想マシン数: ((オーバーコミット比率 × コア数) / インスタンスあたりのコア数)

  • 必要とされるストレージ容量: (フレーバーのディスクサイズ × インスタンス数)

これらの比率を使用して、クラウドのサポートに必要なインフラストラクチャーがどの程度必要か判断することができます。

ここでは、期待される仮想マシン数や必要なストレージ数などの拡張性の情報を収集するために、これらの比率を使用した例を紹介しています。以下の数では、 (200 / 2) × 16 = 1600 仮想マシンのインスタンスをサポートし、 /var/lib/nova/instances のストレージ 80 TB が必要となります。

  • 物理コア 200 個

  • ほとんどのインスタンスのサイズは m1.medium (仮想コア数2、ストレージ50GB) とします。

  • デフォルトの CPU オーバーコミット比率 (nova.conf ファイルの cpu_allocation_ratio) は 16:1 とします。

注釈

オーバーコミット比率に関係なく、フレーバーの要求するリソースよりも（オーバーコミットの前に）リソースが少ない物理ノードにはインスタンスは配置されません。

しかし、APIサービスやデータベースサーバー、MQサーバーがおそらく遭遇する負荷を見積もるためには、コア数以外の検討も行う必要があります。クラウドの利用パターンも考慮しなければなりません。

特定の例としては、マネージド Web ホスティングプラットフォームをサポートするクラウドと、コードコミットごとに仮想マシンを１つ作成するような開発プロジェクトの統合テストを実行するクラウドを比較してみましょう。前者では、VMを作成する負荷の大きい処理は数か月に 一度しか発生しないのに対して、後者ではクラウドコントローラに常に負荷の大きい処理が発生します。一般論として、VMの平均寿命が長いということは、クラウドコントローラの負荷が軽いことを意味するため、平均的なVMの寿命を検討する必要があります。

仮想マシンの作成、停止以外に、特に nova-api や関連のデータベースといったサービスにアクセスする際の影響について考慮する必要があります。インスタンスを一覧表示することで膨大な量の情報を収集し、この操作の実行頻度を前提として、ユーザー数の多いクラウドで負荷を大幅に増加させることができます。これはユーザーには透過的に行われます。例えば、OpenStack のダッシュボードをブラウザで開いた状態にすると、仮想マシンの一覧が 30 秒毎に更新されます。

これらの要素を検討した後、クラウドコントローラにどのくらいのコア数が必要なのか決定することができます。上記で説明した留意事項の下、典型的には、ラック 1 本分のコンピュートノードに対して8 コア、メモリ 8GB のサーバで充分です。

また、仮想マシンのパフォーマンスに関する主なハードウェアの仕様や予算、そして、ストレージの性能 (スピンドル/コア)、メモリーの空き容量 (RAM/コア)、ネットワークの帯域幅 (Gpbs/コア)、全体の CPU 性能 (CPU/コア) といった性能の要件を考慮する必要もあります。

Tip

クラウドからメトリクスを抽出する方法など、メトリクスの追跡については、OpenStack Operations Guide を参照してください。

クラウドコントローラーノードの追加

ノードを追加することで、垂直に拡張するのが容易になります。コンピュートノードの追加は単純で、既存のインストール環境から簡単にピックアップすることができます。しかし、高可用性のクラスターを設計するには、重要なポイントを考慮する必要があります。

クラウドコントローラは、異なるサービスを複数実行します。拡張のための新しいサーバには、 nova-scheduler や nova-console のようなメッセージキューのみを使用して内部通信を行うサービスをインストールすることができます。しかし、その他の不可欠な部分はさらに細心の注意が必要です。

ダッシュボード、 nova-api 、Object Storage プロキシなどのユーザーが使用するサービスの負荷分散をする必要があります。標準の HTTP 負荷分散メソッド (DNS ラウンドロビン、ハードウェアロードバランサー、Pound または HAProxy などのソフトウェア) を使用して下さい。ダッシュボードに関しては、L7 ロードバランサーで大変困難となる可能性があるため、VNC プロキシは注意が必要です。 Horizon セッションストレージ も参照してください。

nova-api や glance-api などのサービスは、環境設定ファイルのフラグを変更することによって複数プロセスで処理させるように設定できます。これによって 1 台のサーバー上にある複数のコアの間で処理を共有できるようになります。

Tip

MySQL の負荷分散には複数のオプションがあり、サポートされている AMQP ブローカーにはクラスタリングサポートが含まれています。これらの設定方法やその他多くのサービスに関する情報は、 運用ガイド を参照してください。

クラウドの分離

クラウドの分離は、ユーザがデータストレージについて法的な考慮や地震断層をまたがる冗長性のための異なるリージョン、もしくはAPIコールの低遅延のための要求があるときに必要になります。 cells, regions, availability zones, もしくは host aggregates によって分離されます。

メソッド毎に異なる機能を提供しますが、このメソッドは 2 つのグループに分類すると良いでしょう。

  • セルおよびリージョン。クラウド全体を分離し、個別にコンピュートデプロイメントを稼働します。

  • アベイラビリティーゾーン およびホストアグリゲート。コンピュートのデプロイメントの分割のみを行います。

表: OpenStack 分離の手法 では、OpenStack Compute が現在提供している各分割メソッドの比較ビューを提供しています。

表: OpenStack 分離の手法

セル

リージョン

アベイラビリティゾーン

ホスト・アグリゲート

Use

Shard and scale compute deployment while maintaining a single API endpoint.

リージョンごとに別々のAPIエンドポイントが必要で、リージョン間で協調する必要がない場合

物理的な隔離や冗長性のために、Nova デプロイメントの中で論理的な分離が必要な場合

共通の機能を持ったホストのグループに対してスケジューリングしたい場合

例

複数サイトで構成されるクラウドで、仮想マシンを「任意のサイト」または特定のサイトにスケジューリングしたい場合

複数サイトで構成されるクラウドで、仮想マシンを特定のサイトに対してスケジューリングでき、かつ共有インフラを利用したい場合

分離された電源供給ラインを持つ設備で構成される、単一サイトのクラウド。

トラステッドコンピューティング機能に対応したホスト群に対してスケジューリングしたい場合

オーバーヘッド

Each Cell contains instances of services with overlapping functionality.

各リージョンは完全な nova インストール環境を持ちます。

nova.conf の設定を変更

nova.conf の設定を変更

共有サービス

Keystone, nova-api

Keystone

Keystone、すべての Nova サービス

Keystone、すべての Nova サービス

セルとリージョン

OpenStack Compute Cells are designed to allow running the cloud in a distributed fashion without having to use more complicated technologies, or be invasive to existing nova installations. Hosts in a cloud are partitioned into groups called Cells. Cells are configured in a tree. The top-level Cell ("API cell") has a host that runs the nova-api service, but no nova-compute services. The nova-compute runs in a child Cell. Each Cell has its own message queue and database service.

This allows for a single API server being used to control access to multiple compute installations with the usage of multiple Cells. See Nova Cells V2 Layout for further documentation.

単独の API エンドポイントを持つ場合と異なり、リージョンは、クラウドごとに別々のAPIエンドポイントを持ち、より細かい分離を実現できます。複数の拠点にまたがってインスタンスを実行するユーザーは、明示的にリージョンを指定しなければなりません。しかし、新規サービスを実行するなど、複雑化しなくて済みます。

OpenStack dashboard (horizon) は、複数のリージョンを使用するよう設定できます。これは AVAILABLE_REGIONS パラメーターにより設定できます。

アベイラビリティゾーンとホストアグリゲート

アベイラビリティゾーン、ホストアグリゲート、もしくは両方をnovaデプロイメントを分離するために利用できます。両方の手法は同じような方法で設定、実装されています。

アベイラビリティーゾーン

アベイラビリティーゾーンにより、OpenStack Compute ホストを論理グループにまとめて、（独立した電源系統やネットワーク装置を使うことなどで）他のアベイラビリティーゾーンとの物理的な分離や冗長性を実現できます。

指定したコンピュートホストがローカルでサーバー毎に所属するアベイラビリティゾーンを定義します。アベイラビリティゾーンは一般的に、共通の属性を持つサーバーを識別するために使用されます。例えば、データセンターのラックの一部が別の電源を仕様している場合、このラックのサーバーを独自のアベイラビリティゾーンに入れることができます。アベイラビリティゾーンは、異なるハードウェアクラスを分割することもできます。

リソースのプロビジョニングの際には、インスタンスを作成するアベイラビリティゾーンを指定することができます。これによって、クラウドの利用者は、アプリケーションのリソースが異なるマシンに分散して配置され、ハードウェア故障が発生した場合でも高可用性を達成することができます。

ホストアグリゲートゾーン

これにより、OpenStack コンピュートデプロイメントを負荷分散やインスタンスディストリビューション用の論理グループに分割することができます。ホストアグリゲートを使用して、アベイラビリティゾーンをさらに分割することができます。例えば、ホストアグリゲートを使用してアベイラビリティゾーンをストレージやネットワークなどの共通のリソースを共有するか、信頼済みのコンピューティングハードウェアなどの特別なプロパティを持つホストグループに分割することができます。

ホストアグリゲートの一般的な用途は nova-scheduler で使用する情報を提供することです。例えば、ホストアグリゲートを使って、特定のフレーバーやイメージを共有するホストの集合を作成することができます。

この一般的なケースは、アグリゲートメタデータで key-value ペアを設定して、フレーバーの extra_specs メタデータで key-value ペアを一致させます。フィルタースケジューラーの AggregateInstanceExtraSpecsFilter は、強制的にインスタンスが、同じ値に同じキーが定義されているアグリゲートのホストに対してのみスケジューリングするようにします。

この一般的なコンセプトを高度なレベルで使用すると、集中度の高いコンピュートロードや負荷の低い開発やテストシステムが使用量の多いシステムのリソースが不足したり、使用量の低いシステムでリソースを無駄にしたりしないで、同じクラウドを共有できるように、異なるフレーバーの種別が、異なる CPU および RAM 割当の比率で実行できるようになります。 これは、ホストアグリゲートに metadata を設定して、フレーバー種別の extra_specs と一致させると機能します。

最初のステップは、cpu_allocation_ratio と ram_allocation_ratio のアグリゲートメタデータキーを浮動小数点の値に設定します。AggregateCoreFilter` と AggregateRamFilter のフィルタースケジューラーは、アグリゲートのホストにスケジューリングしている場合、nova.conf のグローバルの初期値を仕様するのではなく、この値を使用します。各ホストは複数のアグリゲートに含まれていますがリソースごとに 1 つの割当比率しか指定されていないため、この機能の使用時は、注意が必要です。同じリソースに対して別の値が定義されている複数のアグリゲートにホストを設置しないように注意してください。

これは前半部分です。特定の比率を保証するフレーバー種別を取得するには、フレーバー種別の extra_specs をアグリゲートでマッチする key-value ペアに設定する必要があります。たとえば、extra_specs cpu_allocation_ratio を 1.0 に定義すると、その種別のインスタンスは、メタデータキー cpu_allocation_ratio も 1.0 と定義されているアグリゲートのみで実行されます。実際は、 cpu_allocation_ratio または core_allocation_ratio で直接マッチさせるのではなく、マッチするアグリゲートメタデータに追加の key-value ペアを定義すると良いでしょう。これにより抽象化が改善されます。たとえば、overcommit キーを定義して、高、中、低の値を設定することで、関連するフレーバー種別をすべて変更する必要なしに、アグリゲートの割合比を調節することができます。

注釈

以前のバージョンでは、全サービスにアベイラビリティゾーンがありました。現在は、nova-compute サービスには独自のアベイラビリティゾーンがあります。nova-scheduler、nova-network、nova-conductor などのサービスは、常にすべてのアベイラビリティゾーンに対応します。

以下の操作のいずれかを実行する場合、サービスは独自の内部アベイラビリティゾーン(CONF.internal_service_availability_zone) に表示されます。

  • openstack host list (os-hosts)

  • euca-describe-availability-zones verbose

  • openstack compute service list

internal アベイラビリティゾーンは、euca-describe-availability_zones (nonverbose) に隠し設定されています。

CONF.node_availability_zone は、CONF.default_availability_zone に名前が変更され、nova-api および nova-scheduler サービスのみで使用されます。

CONF.node_availability_zone は今も機能しますが、非推奨扱いです。

スケーラブルハードウェア

OpenStack のデプロイやインストールの助けとなるリソースがすでに複数存在している場合でも、時間に余裕を持ってデプロイメントの系っ買うを立てることは非常に重要です。本書は、OpenStack クラウド用のラックを 1 つ用意しているとの前提で、何をどのタイミングでスケールするかの提案をしていきます。

ハードウェア調達

「クラウド」とは、サーバーを自由に作成、終了でき、不安定な環境と説明されてきました。これは真実ですが、サーバー自体が不安定なわけではありません。クラウドのハードウェアは、安定して正しく設定されているようにすることで、クラウド環境は稼動状態を保ちます。

OpenStack は、OpenStack と互換性のある Linux ディストリビューションによりサポートされているハードウェアにデプロイすることができます。

ハードウェアに整合性を持たせる必要はありませんが、インスタンスのマイグレーションをサポートできるように、最低限、CPU の種類は同じにする必要があります。

The typical hardware recommended for use with OpenStack is the standard value-for-money offerings that most hardware vendors stock. It should be straightforward to divide your procurement into building blocks such as "compute," "object storage," and "cloud controller," and request as many of these as you need. Alternatively, any existing servers you have that meet performance requirements and virtualization technology are likely to support OpenStack.

キャパシティプランニング

OpenStack is designed to increase in size in a straightforward manner. Taking into account the considerations previous mentioned, particularly on the sizing of the cloud controller, it should be possible to procure additional compute or object storage nodes as needed. New nodes do not need to be the same specification or vendor as existing nodes.

For compute nodes, nova-scheduler will manage differences in sizing with core count and RAM. However, you should consider that the user experience changes with differing CPU speeds. When adding object storage nodes, a weight should be specified that reflects the capability of the node.

Monitoring the resource usage and user growth will enable you to know when to procure. The Logging and Monitoring chapte in the Operations Guide details some useful metrics.

エージング試験

The chances of failure for the server's hardware are high at the start and the end of its life. As a result, dealing with hardware failures while in production can be avoided by appropriate burn-in testing to attempt to trigger the early-stage failures. The general principle is to stress the hardware to its limits. Examples of burn-in tests include running a CPU or disk benchmark for several days.