第1章 プロビジョニングとデプロイメント

自動デプロイメントシステムは、新しいサーバーに対して、物理的なラッキング、MAC アドレスへの IP アドレスの割り当て、電源設定といった必要最小限の手操作の後、人手の介在なしに、オペレーティングシステムのインストールと環境設定を行います。典型的な方法では、PXE ブートと TFTP サーバーを使った仕組みを元にしてオペレーティングシステムの基本的なインストールを行い、その後、自動環境設定管理システムに制御を渡します。

Ubuntu と Red Hat Linux はどちらも、preseed や kickstart といった、ネットワークブートの後に利用できる、オペレーティングシステムを設定するための仕組みを持っています。これらは、典型的には自動環境設定システムを自力で立ち上げるために使われます。他の方法としては、systemimager のようなイメージベースのオペレーティングシステムのデプロイメント手法を使うこともできます。これらの手法は、例えば物理インフラと制御サービスを分離するために仮想マシンを使う時のように、いずれも仮想化基盤といっしょに使うことができます。

デプロイメントの計画を立てる際には、後から修正するのはとても困難な、いくつかの重要な領域に集中してください。

 ディスクのパーティショニングと RAID

どんなオペレーティングシステムでも、もっとも根本的な部分として、それがインストールされるハードディスクがあります。

サーバーのハードディスクに対して、以下の環境設定を完了させなければなりません。

• パーティショニング

• RAID アレイへの追加

もっとも簡単な選択肢は、1 台のハードディスクを 2 つのパーティションに分割することです。

• ファイルシステム

• スワップ領域

この場合は RAID は使用しません。

	注記
	この選択肢は、ハードディスクが故障するとサーバー全体がダウンしてしまうため、商用環境には推奨されません。代わりに、2 台以上のディスクを使用することを推奨します。使用するディスクの台数によって、構成する RAID アレイの種類が決まります。

以下に挙げる複数のディスクの選択肢から選ぶことを推奨します。

• オプション 1: 次の図に示すように、すべてのハードディスクをまったく同じようにパーティショニングします。

  

  このオプションでは、パーティションごとに異なる RAID アレイにおくことができます。例えば、ディスク 1 とディスク 2 のパーティション 1 を /boot パーティションのミラーとして、すべてのディスクのパーティション 2 をルートパーティションのミラーとして、すべてのディスクのパーティション 3 を RAID10 アレイの上の cinder-volumes の LVM パーティションとして割り当てることができます。

  この例にあるディスク 3 と 4 のパーティション 1 のように使用しないパーティションが残ることになるかもしれないとしても、ディスク領域の利用率を最大化することができます。すべてのディスクがすべてのタスクで利用されることにより、I/O 性能が問題になるかもしれません。

• オプション 2: すべてのディスクを 1 つの大きな RAID アレイに追加します。ここでは、ソフトウェア RAID でもハードウェア RAID でもかまいません。この大きな RAID アレイを boot、root、swap、そして LVM 領域に分割します。この選択肢はシンプルですべてのパーティションを利用することができますが、I/O 性能に悪影響があるかもしれません。

• オプション 3: 全ディスク領域を特定のパーティションで占有させます。例えば、ディスク 1 と 2 を RAID1 ミラーで boot、root、swap パーティションに割り当て、そしてディスク 3 と 4 は、すべてをやはり RAID1 ミラーの LVM パーティションに割り当てます。この場合は、I/O を特定の目的に集中させるため、より良いディスク I/O 性能を得ることができるでしょう。ただし、LVM パーティションはだいぶ小さくなります。

ほとんどのアーキテクチャ上の選択のように、正しい答えは環境に依存します。

自動環境設定管理の目的は、人間の介在なしにシステムの一貫性を確立し、維持することにあります。同じクラウド環境を毎回繰り返し作るために、デプロイメントにおける一貫性を維持したいでしょう。自動環境設定管理ツールを正しく利用することによって、デプロイメントと環境設定の変更を全体に展開する作業を単純にすることに加えて、クラウドのシステムを構成するコンポーネントが特定の状態にあるように保証することができます。

これらのツールは、完全に繰り返して動作可能であるため、変更点のテストやロールバックを行うことができます。OpenStack コミュニティでは、この手法で多くの作業が便利に実行されています。設定管理ツールの 1 つである Puppet の場合、OpenStack 用のモジュールも提供されています。

設定管理システムと、それによって管理する項目は、切っても切れない関係にあります。自動的に管理したい項目と管理したくない項目のすべてを注意深く検討するべきです。

経験上、ほとんどの事業者はクラウドを動かすサーバーのすぐ横に席があるわけではありません。また、多くの人が必ずしもデータセンターに行くことを楽しんでいるわけではありません。OpenStack は完全にリモートから環境設定できますが、時にこの通りにならないこともあります。

この場合、OpenStack が動くノードに対して外側からアクセスできるようにすることが重要です。ここでは、IPMI プロトコルがデファクトスタンダードです。完全自動のデータセンタを実現するために、IPMI をサポートしたハードウェアを購入することを強く推奨します。

さらに、リモート電源管理装置も検討してください。通常、IPMI はサーバーの電源状態を制御しますが、サーバーが接続されている PDU にリモートアクセスできれば、すべてが手詰まりに見えるような状況で非常に役に立ちます。