コンピュートノードは OpenStack Compute クラウドのリソースの中核を構成し、インスタンスを動作させるためのプロセッシング、メモリ、ネットワーク、ストレージの各リソースを提供します。
コンピュートノードの CPU 種別は非常に重要な選択です。まず、CPU は Intel チップでは VT-x、 AMD チップでは AMD-v の仮想化に対応している必要があります。
CPU のコア数も選択に影響します。最近のCPUでは最大12コアあるのが一般的です。さらに、CPU がハイパースレッディングをサポートしていれば、12コアは2倍の24コアになります。複数のCPUを持つサーバーを購入すれば、コア数はさらに掛け算で増えます。
CPUでハイパースレッディングを有効にするかどうかはユースケースに依存します。ハイパースレッディングがオン、オフの両方の状態であなたの用途に応じた負荷で性能試験を行い、どちらがユースケースに適しているかを判断することをお薦めします。
OpenStack Compute は多数のハイパーバイザーをサポートしており、その程度も様々です。 サポートされているハイパーバイザーは、KVM, LXC, QEMU, UML, VMWare ESX/ESXi, Xen, PowerVM, Hyper-V です。
おそらく、ハイパーバイザーの選択で最も重要な要素は、現在の使用法やこれまでの経験でしょう。それ以外では、同等の機能の実用上の懸念、ドキュメント、コミュニティでの経験量などあると思います。
例えば、 KVM は OpenStack コミュニティでは最も多く採用されているハイパーバイザーです。 KVM 以外では、Xen、LXC、VMWare、Hyper-V を使っているシステムが、（サポート）リストにある他のハイパーバイザーよりは多いです。しかしながら、これらのハイパーバイザーはどれもある機能のサポートがなかったり、OpenStack と組み合わせての使い方に関するドキュメントが最新版に追従していなかったりします。
ハイパーバイザー選択の参考になる情報は、Hypervisor Support Matrix (https://wiki.openstack.org/wiki/HypervisorSupportMatrix) と レファレンスマニュアル (http://docs.openstack.org/folsom/openstack-compute/admin/content/ch_hypervisors.html) です。
![[注記]](../common/images/admon/note.png) | 注記 |
|---|---|
ホストアグリゲートやセルを使うと一つの OpenStack システムで複数のハイパーバイザーを動かすこともできますが、一つのコンピュートノードで同時に実行できるのは1種類のハイパーバイザーだけです。 |
コンピュートクラスタを調達する際に、作成したインスタンスの（仮想）ディスク用のストレージを決めなければいけません。この一時ストレージの提供方法には主に3つのアプローチがあり、その意味を理解することが重要です。
次の3つの方法があります。
コンピュートノード外のストレージ （共有ファイルシステム）
コンピュートノード上のストレージ （共有ファイルシステム）
コンピュートノード上のストレージ （非共有ファイルシステム）
一般的には、ストレージを選択する際には次のような質問をされます。
実現したいプラッター数（ディスク容量）はどれくらいか？
ネットワークアクセスがあったとしても、ディスク数が多い方が良い I/O 性能が得られるか？
何があなたが目指すコストパフォーマンスのシナリオはどれか？
運用上ストレージをどのように管理したいのか？
多くの運用者はコンピュートホストとストレージホストを分離して使用しています。コンピュートサービスとストレージサービスには異なる要件があり、コンピュートホストでは通常はストレージホストよりも多くのCPUとRAMが必要です。そのため、一定の予算の中では、コンピュートホストとストレージホストで異なる構成として、コンピュートホストに多くのCPUとRAMを持たせ、ストレージホストに多くのブロックストレージを持たせるのは、理にかなっています。
また、コンピュートホストとストレージホストを分離しておけば、コンピュートホストを「ステートレス」（状態を保持しないもの）として扱うことができます。これにより、コンピュートホストの管理を単純にすることができます。コンピュートホスト上で動作しているインスタンスがない限り、クラウドの他の部分に影響を与えずにそのノードをオフラインにしたり取り除いたりすることができます。
一方、クラウドの構築に使用できる物理ホスト数に制限があり、できるだけ多くのホストをインスタンスの実行に使えるようにしたい場合は、同じマシンでコンピュートホストとストレージホストを動作させるのは理にかなっています。
この方法では、実行中のインスタンスの状態を格納するディスクはコンピュートホスト外のサーバーに置かれます。この方法には以下のようなメリットもあります。
コンピュートホストが故障した場合、通常インスタンスは簡単に復旧できます。
専用のストレージシステムを動作させることで、運用がシンプルになります。
ディスク数がスケーラブルになります。
外部ストレージを他の用途と共有できる可能性があります。
この方法の主なマイナス面は以下の点です。
設計次第では、一部のインスタンスの I/O が非常に多い場合に、無関係のインスタンスに影響が出る場合があります。
ネットワークを使用するため、性能低下が起こる可能性があります。
この方法では、各 nova-compute ノードには多数のディスクが接続されますが、分散ファイルシステムにより各コンピュートノードのディスクは1つのマウントポイントにまとめられます。この方法の主なメリットは、追加のストレージが必要になった際に外部ストレージを利用してスケールできる点です。
しかし、この方法にはいくつかマイナス点があります。
分散ファイルシステムを動作させるため、非共有ストレージと比較してデータの局所性が失われます。
複数の物理ホストが関係するため、インスタンスの復旧が複雑になります。
コンピュートノードの筐体サイズによって、コンピュートノードに搭載できるディスク数が制限されます。
ネットワークを使用するため、性能低下が起こる可能性があります。
この方法では、各 nova-compute ノードには、そのホストで動作するインスタンスを収容するのに十分な量のディスクが接続されます。この方法には次の2つのメリットがあります。
あるコンピュートノード上での I/O が非常に多い場合でも、他のコンピュートノードのインスタンスに影響がありません。
I/O アクセスが直接行われるので、性能向上が図れます。
この方法には次のようなマイナス点があります。
コンピュートノードが故障すると、そのノードで実行中のインスタンスが失われてしまいます。
コンピュートノードの筐体サイズによって、コンピュートノードに搭載できるディスク数が制限されます。
あるノードから別のノードへのインスタンスのマイグレーションが複雑になります。また、マイグレーション方法も開発が継続されるか分からない方法に依存することになります。
追加のストレージが必要になった際に、この方法はスケールしません。
我々はライブマイグレーションはクラウドの運用に不可欠なものだと考えています。この機能により、インスタンスをある物理ホストから別の物理ホストに停止せずに移動し、コンピュートホストの再起動を必要とするアップグレードを実行することができるようになります。しかし、ライブマイグレーションを行うには共有ストレージがなければなりません。
ライブマイグレーションは、KVM ライブブロックマイグレーションとして知られる機能を用いて、非共有ストレージでも実行できます。以前のバージョンでの KVM と QEMU におけるブロックマイグレーションの実装は信頼性がないと思われていましたが、OpenStack とも互換性のある QEMU 1.4 と libvirt 1.0.2 には、信頼性が向上した新しいライブブロックマイグレーションの実装があります。しかしながら、このガイドの執筆陣は誰もライブブロックマイグレーションを使用したことがありません。
OpenStack では、コンピュートノードの CPU と RAM をオーバーコミットすることができます。これにより、インスタンスの性能が下がるものの、クラウド上で動作可能なインスタンス数を増やすことができます。 OpenStack Compute でのデフォルト値は次のようになっています。
CPU 割当比: 16
RAM 割当比: 1.5
CPU 割当比のデフォルト値 16 は、スケジューラーが1つのノードで物理コア1つあたり最大16個の仮想コアを割り当てることを意味します。例えば、ある物理ノードのコア数が12の場合、スケジューラが最大で192個の仮想コアをインスタンスに割り当てることになります (例えば、各インスタンスの仮想コアが4個の場合には、48インスタンス割り当てられます)。
同様に、RAM 割当比のデフォルト値 1.5 は、インスタンスに割り当てられた RAM の総量がその物理ノードで利用できるメモリ量の1.5倍未満であれば、スケジューラーがその物理ノードにインスタンスを割り当てることを意味します。
例えば、物理ノードに 48GB の RAM がある場合、そのノード上のインスタンスに割り当てられた RAM の合計が 72GB に達するまでは、スケジューラーはそのノードにインスタンスを割り振ることになります (例えば、各インスタンスのメモリが 8GB であれば、9 インスタンス割り当てられます)。
あなた自身のユースケースに合わせて、適切な CPU と RAM の割当比を選択しなければなりません。
ロギングについては 「ロギング」 で詳しく説明しています。しかし、ロギングはクラウドの運用を開始前に考慮しておくべき重要な検討事項です。
OpenStack は非常に多くの有用なログ情報を出力しますが、運用時にログ情報を有効活用するためには、ログを集積するログサーバーや、(logstash といった) ログ解析/分析システムを用意することを検討すべきでしょう。
OpenStack のネットワークは複雑で、検討すべき点がたくさんあります。 6章ネットワーク設計 を参照して下さい。
