[ English | Indonesia | Deutsch | 日本語 ]

Planning for deploying and provisioning OpenStack

The decisions you make with respect to provisioning and deployment will affect your maintenance of the cloud. Your configuration management will be able to evolve over time. However, more thought and design need to be done for upfront choices about deployment, disk partitioning, and network configuration.

クラウドのスケーラビリティにおける重要な部分の一つは、クラウドを運用するのに必要な労力にあります。クラウドの運用コストを最小化するために、 Puppet や Chef などの設定管理システムを使用して、自動化されたデプロイメントおよび設定インフラストラクチャーを設定、使用してください。これらのシステムを統合すると、工数やオペレーターのミスを大幅に減らすことができます。

このインフラストラクチャーには、オペレーティングシステムの初期設定を自動にインストールするシステムや、全サーバーを自動的かつ一元的に連携、設定するシステムが含まれており、手作業やエラーの発生する可能性を減らします。例えば、Ansible、CFEngine、Chef、Puppet、Salt などのシステムです。OpenStack を使用して、OpenStack をデプロイすることも可能です。これは、TripleO (OpenStack 上の OpenStack) という愛称で呼ばれています。

自動デプロイメント

自動のデプロイメントシステムは、物理ラッキング、MAC から IP アドレスの割当、電源設定など、必要最小限の手作業のみで、介入なしに新規サーバー上にオペレーティングシステムのインストールと設定を行います。ソリューションは通常、PXE ブートや TFTP サーバー関連のラッパーに依存して基本のオペレーティングシステムをインストールして、次に自動設定管理システムに委譲されます。

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

デプロイメントプランを作成する場合、デプロイメント後の修正は困難であるため、いくつかの重要な分野にフォーカスを当ててください。次の 2 章で以下の設定内容について説明していきます。

  • スケーラビリティ確保に向けたディスクのパーティショニングおよびディスク配列設定

  • PXE ブート用のネットワーク設定

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

オペレーティングシステムの基盤は、オペレーティングシステムがインストールされるハードドライブです。

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

  • パーティショニング。以下に説明されている通り、オペレーティングシステムと Swap 領域のレイアウトにおける柔軟性がはるかに高くになります。

  • 使用可能なディスクの数をもとに、RAID 配列 (RAID は Redundant Array of Independent Disks の略) に追加します。 こうすることで、クラウドが大きくなった場合も容量を追加できます。オプションは、以下で詳しく説明しています。

最もシンプルに使用を開始できるオプションは、１台のハードディスクを２つのパーティションに分割することです。

  • ファイルやディレクトリを格納するファイルシステム。システムを起動、実行する root パーティションなど、全データが設置される場所。

  • プロセス用にメモリーを空ける Swap 領域。物理ディスクから独立した、スワップのみに使用される領域。

通常、本番環境のクラウドでは、1 つのディスクに問題が発生した場合、別のディスクが必ず稼働するようにするため、RAID は、このシンプルな、ドライブ 1 つの設定では使用されません。本番環境では、ディスクを 1 つ以上使用します。ディスク数により、どのようなタイプの RAID 配列を構築するか決定します。

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

オプション 1

ドライブのパーティション設定 にあるように、すべてのドライブを同じように並列してパーティショニングにします。

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

_images/osog_0201.png

ドライブのパーティション設定

この例では、ディスク 3 と 4 のパーティション 1 のように未使用のパーティションが残る可能性もありますが、このオプションにより、ディスク領域の使用状況を最大化することができます。すべてのディスクがすべてのタスクで利用されるため、I/O のパフォーマンスが問題になる可能性があります。

オプション 2

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

オプション 3

全ディスク領域を特定のパーティションに割り当てます。例えば、ディスク 1 と 2 すべてを RAID 1 ミラーとして boot、root、swapパーティションに割り当てます。そして、ディスク 3 と 4 すべてを、同様に RAID 1 ミラーとしてLVMパーティションに割り当てます。I/O は専用タスクにフォーカスするため、ディスクの I/O は良くなるはずです。しかし、LVM パーティションははるかに小さくなります。

Tip

パーティショニング自体を自動化可能であることが分かります。例えば、MIT は Fully Automatic Installation (FAI) を使用して、初期の PXE ベースのパーティション分割を行い、min/max およびパーセントベースのパーティショニングを組み合わせてインストールしていきます。

多くのアーキテクチャーの選択肢と同様に、環境により適切なソリューションは変わって来ます。既存のハードウェアを使用する場合、サーバーのディスク密度を把握し、上記のオプションをもとに意思決定していきます。調達プロセスを行っている場合、ユーザー要件などもハードウェア購入決定の一助となります。ここでは AT&T の Web 開発者にカスタムの環境を提供するプライベートクラウドの例をあげています。この例は、特定のデプロイメントであるため、既存のハードウェアや調達機会はこれと異なる可能性があります。AT&T は、デプロイメントに 3 種類のハードウェアを使用しています。

  • コントローラーノードのハードウェア。ステートレスの OpenStack API サービスすべてに使用します。メモリー約 32-64GB、接続された容量の小さいディスク、プロセッサー 1 つ、6-12 個程度のコア。

  • コンピュートノードのハードウェア。通常、メモリー 256 GB または 144 GB、プロセッサー 2 個、コア 24 個、通常 RAID 5 設定のダイレクトアタッチストレージ (DAS)。

  • ストレージノードのハードウェア。通常、ラックスペース効率を確保しつつも、ディスク容量のコストが GB ベースで最も低く最適化されています。

ここでも、環境によって適したソリューションが変わります。スペース使用状況、シンプルさ、I/O パフォーマンスの長所、短所をベースに意思決定していく必要があります。

ネットワーク設定

ネットワーク設定は、本書でも複数の箇所で取り上げられている大きいトピックです。ここでは、お使いのサーバが PXEブートでき、デプロイメントサーバと正常に通信できることを確認しておいてください。

例えば、PXE ブートの際には、通常は VLAN の設定は行えません。さらに、通常は bonding された NIC から PXE ブートを行うこともできません。このような状況の場合、クラウド内でのみ通信できるネットワークで、シンプルな 1Gbps のスイッチを使うことを検討してください。

自動環境設定

自動環境設定管理の目的は、人間の介在なしにシステムの整合性を確保、維持することにあります。毎回、同じクラウド環境を繰り返し作るために、デプロイメントにおける整合性を確保します。自動環境設定管理ツールを正しく利用することによって、デプロイメントと環境設定の変更を伝搬する作業を簡素化するだけでなく、クラウドシステムのコンポーネントが必ず特定の状態にあるようにすることができます。

These tools also make it possible to test and roll back changes, as they are fully repeatable. Conveniently, a large body of work has been done by the OpenStack community in this space. Puppet, a configuration management tool, even provides official modules for OpenStack projects in an OpenStack infrastructure system known as Puppet OpenStack. Chef configuration management is provided within OpenStack Chef Repo. Additional configuration management systems include Juju, Ansible, and Salt. Also, PackStack is a command-line utility for Red Hat Enterprise Linux and derivatives that uses Puppet modules to support rapid deployment of OpenStack on existing servers over an SSH connection.

設定管理システムの不可欠な部分は、このシステムが制御する項目です。自動管理をする項目、しない項目をすべて慎重に検討していく必要があります。例えば、ユーザーデータが含まれるハードドライブは自動フォーマットは必要ありません。

リモート管理

経験上、多くのオペレーターはクラウドを動かすサーバのそばにいるわけではありませんし、多くの人が必ずしも楽しんでデータセンターに訪問してるわけではありません。OpenStackは、完全にリモート設定できるはずですが、計画通りにいかないこともあります。

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

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

Other considerations

作成するクラウドのユースケースを理解することで時間を節約することあできます。OpenStack のユースケースはさまざまで、オブジェクトストレージのみのもの、開発環境設定を加速するために事前設定されたコンピュートリソースが必要なもの、プライベートネットワークでテナントごとにセキュリティが確保されたコンピュートリソースの迅速にプロビジョニングするものもあります。ユーザーは、レガシーアプリケーションが継続して実行されるように、非常に冗長化されたサーバーが必要な場合もあります。おそらく、時間をかけてこれらのクラスターを追加するのが目的ではなく、クラウドの耐障害性を確保したかたちで、複数のインスタンス上で実行するために、レガシーのアプリケーションを構築するのが目的の場合もあります。ユーザーによっては、負荷の高い Windows サーバーを使用するため、スケーリングを考慮する必要があると指定する場合もあるでしょう。

すでに設置済みのハードウェアに最適な方法で使用されていることをチェックすることで、リソースを節約することができます。高濃度のストレージハードウェアがあるとします。このハードウェアをフォーマットして、OpenStack Object Storage 用にサーバーの用途を変更することができます。ユーザーからのこのような検討やインプットすべてをベースにすることで、ユースケースやデプロイメントプランの作成が容易になります。

Tip

For further research about OpenStack deployment, investigate the supported and documented preconfigured, prepackaged installers for OpenStack from companies such as Canonical, Cisco, Cloudscaling, IBM, Metacloud, Mirantis, Rackspace, Red Hat, SUSE, and SwiftStack.