Planning for deploying and provisioning OpenStack

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.

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

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

Automated deployment

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

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

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

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

Disk partitioning and RAID

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

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

  • パーティショニング。以下に説明されている通り、オペレーティングシステムと Swap 領域のレイアウトにおける柔軟性がはるかに高くになります。
  • 使用可能なディスクの数をもとに、RAID 配列 (RAID は Redundant Array of Independent Disks の略) に追加します。 こうすることで、クラウドが大きくなった場合も容量を追加できます。オプションは、以下で詳しく説明しています。

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

  • ファイルやディレクトリを格納するファイルシステム。システムを起動、実行する root パーティションなど、全データが設置される場所。
  • プロセス用にメモリーを空ける Swap 領域。物理ディスクから独立した、スワップのみに使用される領域。

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

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

オプション 1

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

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

_images/osog_0201.png

Partition setup of drives

この例では、ディスク 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 パーティションははるかに小さくなります。

ちなみに

パーティショニング自体を自動化可能であることが分かります。例えば、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 パフォーマンスの長所、短所をベースに意思決定していく必要があります。

Network configuration

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

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

Automated configuration

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

また、これらのツールでは、完全に繰り返しが可能であるため、変更のテストやロールバックが可能です。従来、OpenStack コミュニティーにより多くの作業が行われていました。Puppet (設定管理ツール) は、 Puppet OpenStack <https://wiki.openstack.org/wiki/Puppet> __ で知られる OpenStack インフラストラクチャーシステム内の OpenStack の公式モジュールも提供しています。 Chef の設定管理は、 https://github.com/openstack/openstack-chef-repo で提供されています。他の設定管理システムには、Juju、Ansible、Salt などがあります。また、PackStack は Red Hat Enterprise Linux のコマンドラインユーティリティーで、SSH 接続を使用して既存のサーバーに OpenStack を迅速にデプロイできるように Puppet モジュールを使用する派生プロダクトです。

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

Remote management

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

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

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

Other considerations

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

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

ちなみに

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.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.