株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

Platform9のOpenStackアーキテクチャの中を覗いてみる

本記事の原文:Under the Covers of the Platform9 OpenStack Architectureの公開は2015年の7月7日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

Platform9製品詳細についてはこちら

Fig004

Platform9のミッションはあらゆる規模のエンタープライズプライベートクラウドを簡単にすることです。これは以下の様な我々の顧客にとって重要なメリットを提供するソリューションを作るということに他なりません:

  • 展開が容易というだけのプライベートクラウドではなく、管理も容易でなくてはなりません。Platform9で、我々は顧客にとっては退屈な展開作業や監視、拡張、バックアップ、更新など、クラウド管理システムを管理するということは現実的ではなく、取り除くべきだという決断をしました。我々はクラウド管理自身をSaaSとして提供するというユニークなモデルを成し遂げたのです。
  • インフラストラクチャ、スキルセット、手順などのすでに顧客がお持ちの資産を活用できるプライベートクラウドである必要があります。これはまっさらな環境を必要とする多くのソリューションとは対照的です。Platform9は既存のKVMVMware vSphere環境の上に統合して利用することが出来るのです。
  • 標準的なインターフェイスAPIセットを利用しながら、Linuxコンテナーのような最新のテクノロジーを迅速に、そして簡単に利用できるようなプライベートクラウドである必要があります。これはPlatform9がOpenStackの標準化された技術を我々のクラウド管理プラットフォームに採用した主な理由の一つです。我々はOpenStackがプライベートクラウドにとってデファクトの標準APIを提供しており、柔軟なプラグインアーキテクチャで新しいテクノロジーを簡単にプラットフォームに統合できる用になっていると信じています。

今後、我々の既存環境との統合や、テクノロジーとの統合についてもっと耳にすることが増えてくると思います。この記事はわれわれのSaaSソリューションがどのようにPlatform9のエンジニアを助け、クラウド管理-as-a-serviceを実現しているのかを述べていきます。このソリューションを設計し、実装したPlatform9の輝けるエンジニアリングチームに感謝したいと思います。また、共同創業者であるBich Le氏、Madhura Maskasky氏、そしてRoopak Parikh氏の本記事への寄稿についても感謝致します。さぁ、まずはPlatform9 Managed OpenStackのハイレベルなアーキテクチャから初めましょう。

Platform9 Manged OpenStackのアーキテクチャ

Fig005

Platform9は3つの層からなるアーキテクチャで動作していると考えることが出来ます。この3つの層は:

  • コアサービス ー それぞれの顧客のプライベートクラウドの展開ユニットを一元的な手法で行うためのサービスやツールの集まり
  • 展開ユニット ー Platform9社がそれぞれの顧客に対して展開するOpenStackのクラウド管理インスタンスとそれに紐づく管理サービス。全ての展開ユニット(Deployment Unit - DU)はPlatform9コアサービスによって一元管理されていますが、それぞれのDUはあらゆる顧客において共有されることはありません。
  • オンプレミス層(ホストエージェント) ー 顧客のオンプレミス環境のLinux KVMサーバでデーモンとして動作し、サーバをOpenStackのコンピューティングノードとして機能させます。エージェントはnova-computeやnova-novncproxyバイナリのようなコンピューティングノードとしての要件のインストールについても実施します。エージェントは動作している仮想マシン(VM)、ネットワーク構成、ストレージの容量などのサーバ上で動作しているリソースのディスカバリも可能にします。顧客のDU内で動作しているOpenStackのコントローラーはエージェントを利用して、サーバ上に展開されているリソースの管理などのコミニュケーションも行います。
  • オンプレミス層(ゲートウェイ) ー 顧客のオンプレミスのvSphere環境上に展開されたオープン仮想化アプライアンス(OVA)で、顧客のDUと顧客のvCenterサーバ間のコミニュケーションを実現します。ゲートウェイは顧客のvSphereクラスタ内の動作中の仮想マシン、ネットワーク構成、そしてストレージ容量などの全てのリソースのディスカバリも実現します。顧客のDU内で動作しているOpenStackコントローラーもゲートウェイを利用してクラスタ上の各リソースの管理のためのコミニュケーションを実施します。

記事の残りの部分では、協調してSaaSとして動作し、クラウド管理-as-a-Serviceを実現するPlatform9のコアサービスと顧客の展開ユニット(DU)にフォーカスをあてます。将来の記事でホストエージェントやゲートウェイがどのように顧客のオンプレミスの環境とやり取りしているのかを取り上げる予定です。

コアサービス

Platform9のコアサービスは分散されたサービスとユーティリティで、現在はAmazon Web Services(AWS)上に展開されています。我々がAWSを選択した理由はそのインフラへの展開が簡単で、彼らのグローバルな展開と様々な機能ー例えば可用性ゾーン(Availability Zone)を活用することができるからです。アーキテクチャ的にいえば、コアサービスはどんなインフラストラクチャへの展開にも対応が可能です。

コアサービスを構成するコンポーネントには以下が含まれます:

  • アラーティングサービス(Alerting Service) ー 我々の状態サーバ(Stat Server)、ログ分析(Log Analyzer)をPlatform9のアラーティングやページングシステムと統合するためのソフトウェア
  • ログ分析(Log Analyzer) ー 顧客の展開ユニットからログを集めてパースするためにPlatform9が利用するソフトウェア。ログ分析はアラーティングサービスと統合されており、アクティブに監視を行っています。
  • 状態サーバ(Stats Server) ー 顧客の展開ユニットの健全性を監視し、すべてのサービスが起動し、稼働し続けていることを保証するために利用します。状態サーバはそれぞれの顧客のDUで動作している状態/ヘルスエージェントと通信し、展開状態を受信します。
  • スネイプ(訳注:Platform9らしく、ハリーポッターのキャラクターの名前です) ー それぞれの顧客ごとのDUの管理サービスで、顧客ごとの展開バンドルの作動を含め、利用されている展開ツール群です。
  • 構成リポジトリ(Configuration Repo) ー 展開バンドルを作成するファイルの共有リポジトリで、顧客の展開ユニットの新規作成に利用されます。Ansibleのスクリプトや顧客ごとに固有の識別子が埋め込まれる前の状態の顧客展開バンドルの一部であるゲートウェイRPMパッケージが格納されています。

Fig006上で述べたように、コアサービスはAWS上に展開されています。これによって、顧客のワークロードがセキュアな状態でオンプレミス層の一部としてオンプレミスのプライベートクラウドで動作していることを保証しながら、パブリッククラウドのスケーラビリティとサービスを活用することが出来るのです。Platform9では、AWSサービスを利用し、高可用性(HA)をコアサービス層に提供しています。

  • すべてのコアサービスのコンポーネントは利用している可用性ゾーン(AZ)内に1つ又は複数のAWSインスタンスとして動作しており、そのレプリカが別のAZ内に作成されます。どのAZが展開に利用されるかは顧客のデータセンターの地理的な場所によって決まります。
  • コアサービスは永続データをAWS Relational Database Service(RDS)インスタンスに保管します。このインスタンスもコアサービスのレプリカと同様に同じAZへレプリケーションされています。コアサービスはこのように設計されており、もしも本当にkey-valueストアのソリューションへの移行が必須となった際にはそれが簡単に出来るようになっていることを付け加えておきます。
  • コアサービスのインスタンスやそれがホストされているAZにダウンタイムが発生した際には、AWS Elastic Load Balancer(ELB)を活用して、トラフィックをコアサービスのフェイルオーバーのためのレプリカやAZへと転送します。もちろん、普及後の再転送にもELBを利用します。

展開ユニット(Deployment Unit - DU)

Platform9のアカウントにサインナップが完了すると、展開ユニット(DU)がそれぞれの顧客ごとに作成されます。うえでも述べたように、あらゆる顧客においてDUが共有されるということはありえません。Platform9のコアサービスと同様、顧客のDUも現在はAmazon Web Services(AWS)上に展開されます。我々がAWSを選択した理由はそのインフラへの展開が簡単で、彼らのグローバルな展開と様々な機能ー例えば可用性ゾーン(Availability Zone)を活用することができるからです。アーキテクチャ的にいえば、DUはどんなインフラストラクチャへの展開にも対応が可能です。

展開ユニット(DU)を構成するコンポーネントにはいかが含まれます :

  • OpenStack コントローラー ー 安定版リリースをベースとしたOpenStackの標準のサービスで、顧客のプライベートクラウドインスタンスに対して、クラウド管理機能を提供します。これらのサービスは複数のAWSインスタンスにまたがっており、顧客のリソースの要求に応じて簡単にスケールアウト出来るようになっています。
  • リソースマネージャー(Resource Manager) ー Platform9 OpenStackコントローラーで管理されている顧客のデータセンタ内の全てのコンピューティング、ネットワーク、ストレージリソースの状態を追跡し、カタログ化しています。顧客は新しい環境や既存の環境の両方をいつでもPlatform0の管理下に置くこと出来るため、状態は非常にダイナミックです。リソースマネージャーは他のDUサービスと強調し、OpenStackコントローラーがいつも一貫した、そして最新のリソース管理が行えるようにしています。
  • 認証リポジトリ(Certificate Repo) ー 顧客ごとに様々なDU内のサービスの展開にされる、自己証明書であり、顧客のデータセンタ内のインフラサービスの認証にも利用されます。
  • ログ収集(Log Collector) ー 特定の顧客のDBのログを収集し、コアサービス層内のログ分析へ処理のために送信を行うためにPlatform9が利用するソフトウェアです。
  • 状態/ヘルス エージェント(Stats/Health Agent) ー このエージェントは定期的に中央のコアサービス層内の状態サーバへステータス情報をレポートします。以下のサービス/コンポーネントの状態データの収集を行います:
    • 顧客のDU内に展開されたすべてのサービス
    • 展開されたすべてのホストエージェント
    • 展開された全てのゲートウェイ
  • 構成マネージャー(Configuration Manager) ー 構成マネージャーは以下のタスクを実施しています:
    • DU内、そして顧客のデータセンタ内のオンプレミスに展開されているPlatform9アプリケーションソフトウェアのインストール、構成、更新。この中にOpenStackサービスやホストエージェントやゲートウェイも含まれます。
    • ハイパーバイザーなどの顧客のリソースのディスカバリや、それらのリソースについてのテレメトリーの収集。構成マネージャーはPlatform9が作成したものや、Ansibleによる構成管理、オーケストレーションを含む様々なユーティリティを数多く利用しています。

Fig007

コアサービスと同様、展開ユニットもAWS上で動作しています。これによって顧客のワークロードがセキュアな状態でオンプレミス層の一部としてオンプレミスのプライベートクラウドで動作していることを保証しながら、パブリッククラウドのスケーラビリティとサービスを活用することが出来るのです。Platform9では、AWSサービスを利用し、高可用性(HA)を顧客のDUに提供しています。

  • すべてのDUのコンポーネントは利用している可用性ゾーン(AZ)内に1つ又は複数のAWSインスタンスとして動作しており、そのレプリカが別のAZ内に作成されます。どのAZが展開に利用されるかは顧客のデータセンターの地理的な場所によって決まります。
  • DUは永続データをAWS Relational Database Service(RDS)インスタンスに保管します。このインスタンスもDUのレプリカと同様に同じAZへレプリケーションされています。
  • DUのインスタンスやそれがホストされているAZにダウンタイムが発生した際には、レプリカのRDSインスタンスが対応に当たり、DUのインスタンスのスナップショットが展開され、構成されます。オンプレミス層からの、またはオンプレミス層へのトラフィックはDR DUへと転送されるようになります。

この記事によってPlatform9がどのようにクラウド管理-as-a-Serviceをエンジニアリングし、膨大なプライベートクラウドの展開・管理にかかる作業を簡単にしているかのいくらかでもお伝えできれば幸いです。続いての記事ではオンプレミス層と様々なコアサービスそして展開ユニットそうのコンポーネントについて深く見ていきたいと思います。

記事責任者 マーケティング本部 三好哲生 (@Networld_pf9)