*Platform9 Feed

2016/09/02

Platform9 OpenStackでの仮想マシンの高可用性

本記事の原文:Virtual Machine High Availability with Platform9 OpenStackの公開は2016年の8月24日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

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

Platform9について詳しく知りたい方は是非以下のWebセミナーへもアクセスください。

【Webセミナー】Platform9 Managed OpenStack Web&デモセミナー
話題!日本上陸直後のPlatform9 Managed OpenStackを徹底解説 & デモを実施

昨年、OpenStack Summit 東京での開催、先日開催OpenStack Summit Days Tokyo 2016の大成功、大規模な導入事例発表など、OpenStackの熱気はいよいよ日本国内へも押し寄せてきています。
しかし、OpenStackはオープンソースプロジェクトでそのものはフリーで提供されていますが、そもそもインストールが難しい、運用管理していく手間とコストが膨大になる、アップグレードがうまくいかないなど、一般的な企業のお客さまにとっては多くのハードルを抱えています。

本セミナーではOpenStackの5つの展開方法とそのメリット・デメリットを上げた上で、
Platform9社が提供するユニークなOpenStack-as-a-serviceについてご紹介致します。
これまでになかったアプローチでのOpenStackの利用開始、運用、そしてその効果についてあますところなくお伝え致します。
本セミナーへご参加方にのみ、Platform9 Managed OpenStackのフリートライアルアカウントをお渡し致します。是非奮ってご参加ください。

https://networld.smartseminar.jp/public/seminar/view/666

エンタープライズのためのあらゆるクラウド商品において、仮想マシンの高可用性(HA)はアプリケーションの可用性をインフラストラクチャの障害時にも維持するためになくてはならない機能です。高可用性を高所してクラウドを設計すればクラウドネイティブなアプリケーションだけでなく、従来型のアプリケーションの障害からの保護にも役立ちます。これまで、HAの機能はVMwareやHyper-Vなどといった、仮想化インフラストラクチャだけのものでした。Platform9 Managed OpenStackを利用することで同じ機能をKVM環境においても利用できるようになりました。

モダンアプリケーションは複数階層のアーキテクチャとデータ共有で障害時にも一貫したパフォーマンスの提供を保証します。アプリケーションはスケールアウト、もしくは負荷状況に応じて拡張することが可能になっています。各々のインスタンスの障害は大抵はモダンワークロードに影響をあたえることはありません。しかし、大規模なデータセンタの障害ともなると、こうしたアプリケーションの可用性にもまだ影響をおよぼすことが有ります。クラウドスケールのデータセンタはこうしたハードウェアの障害も考慮して設計されているべきなのです。OpenStackでは管理者が障害ドメインを指定して、可用性ゾーン(AZ)を構築することが出来るようになっています。Platform9 manged OpenStackはこうした障害から、クラウドネイティブアプリケーションを複数のAZにわたってワークロードを配置することで保護することが出来るようになっています。

従来型のアプリケーションはインフラストラクチャが常に利用できることを前提としています。アプリケーションのアーキテクチャはハードウェアの障害に耐性をもちません。仮想マシンやハイパーバイザーの障害はこうしたアプリケーションの可用性に影響を及ぼします。Platform9 managed OpenStackを利用すれば、こうしたアプリケーションをもほぼすることが可能です。もしアプリケーションの仮想マシンがクラッシュしたり、その下のハイパーバイザーノードがダウンした場合、こうした仮想マシンはPlatform9のHA機能によって新しいホストを再割当てすることが出来るのです。

クラウドネイティブアプリケーションを保護する

Platform9 Managed OpenStackでインフラストラクチャ管理者とアプリケーション開発者は大規模なハードウェア障害に備えることができます。データセンタの設計によって、AZはサーバのシャーシであったり、ラックであったり、データセンタ環境全体であったりします。アプリケーション開発社はクラウドネイティブアプリケーションをAZの障害に耐性を持つように設計することが出来ます。

OpenStackはクラウド対応アプリケ-ションをリソースの利用状況に応じて自動的に拡張させるためのオートスケーリンググループを構築することが出来るようになっています。Platform9のHA機能を用いれば、オートスケーリンググループに可用性ゾーンの要件を追加することも可能です。例えば、以下のテンプレートは可用性とともにオートスケーリンググループはを記述したものです。

Fig009可用性ゾーンを組み込んだHeatテンプレート

heatテンプレートはアプリケーションのスケールアウトの青写真を記載したものです。複数のインスタンスにまたがるワークロードが増加すれば、それに応じて追加でアプリケーションのインスタンスを展開します。Platform9では、開発者は可用性ゾーン(AZ)を指定してアプリケーションのインスタンスを展開することが出来ます。AZは"availability_zones"というプロパティにコンマで区切られたリストとして指定することが出来ます。Platform9 Managed OpenStackはアプリケーションのインスタンスがテンプレートで指定されたAZに最低1つずつ展開されることを保証します。以下の様な障害イベントに対応がなされます。

  • AZ内のホスト障害 : 同じAZの内の別のホストで新しいアプリケーションのインスタンスが開始される
  • AZ全域に及ぶ障害 : 他のAZ内のアプリケーションのインスタンスがユーザーリクエストに継続対応、クラウドネイティブアプリケーションとしては動作に影響が出ない

従来型アプリケーションを保護する

Platform9 Managed OpenStackはHAを従来型アプリケーションに拡張します。AZは古くからのアプリケーションの保護を構成するためにも利用ができるのです。クラウド管理者は以下のようにして可用性ゾーン上にHAを有効にすることが出来ます。

Fig010Platform9で仮想マシンのHAを管理

仮想マシンを障害ホストから復旧するためには共有ストレージが必要です。HAクラスタに参加する全てのホストは同一の共有ストレージに仮想マシンに固有のストレージパスを利用して接続することで、ノード障害時に適切に仮想マシンを復旧することが出来ます。OpenStackの可用性ゾーンにHAを有効にするため、Platform9は可用性ゾーン内のすべてのKVMホストに分散クラスタリングサービスを展開します。クラスタリングサービスはGossipプロトコルを利用してクラスタ内のすべてのノードの死活を監視します。従来からのハートビートを利用したノードの健全性の監視を行うアプローチと比べ、分散クラスタは以下の様な利点があります。

  • Gossipプロトコルはハートビートベースの手法に比べ、確実にそして素早く障害を検知、仮想マシンのダウンタイムもより短くなる
  • ネットワークパーティション(分断)のようなわかりにくく、ハートビートでは検知できない障害も検知

ホスト障害発生時にはそのホストは隔離され、クラスタから切り離されます。以下に示したように、そのノードで動作している全ての仮想マシンは同じAZ内の他のノードで再起動されます。

Fig011障害時の仮想マシンの避難

AZのサイズと起こりうる仮想マシンの障害の数によって、障害ホストの仮想マシンを復旧するための予備のキャパシティを展開しておく必要があります。

Platform9は分散クラスタを自動的に管理することが出来ます。障害時に手動で構成を行う必要はありません。クラスタはAZにハイパーバイザーのホストが追加されたり、削除されたりする毎に自動的にメンテナンスされます。まとめです。Platform9 Managed OpenStackは現在企業に必要とされるHAの機能を一元的に提供することが出来ます。クラウド対応のみならず、古くからのアプリケーションのための固有のHAの要件に応えることが出来るようにし、ワークロードの可用性について不安を抱えることなくクラウドへ簡単に移行できるようにしてあります。このHAの機能についてのデモは以下のビデオを御覧ください。

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

2016/08/18

サンドボックス化された完全なマネージドOpenStackのテストドライブ(Platform9を体験してみたい方!お待たせ致しました!)

本記事の原文:Test-drive Fully Managed OpenStack in a Sandboxの公開は2016年の8月5日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

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

Platform9はSaaSベースのマネージドサービスを利用して、OpenStackによるプライベートクラウドの展開、稼働、管理そして拡張をご提供しています。展開は数分で済みます。Platform9はSaaSレイヤーにOpenStackのコントロールプレーンを稼働させ、皆様にやっていただくことはKVMホストへエージェントをインストールするか、vSphere環境に(仮想)アプライアンスを動作させるだけです。

展開は非常に簡単で数分で終わりますが、我々はそれをもっとシンプルにし、Platform9をご自身の環境でインストールする前に試してみていただきたいと思っていました。今回、自由に探検いただけるOpenStackのサンドボックス環境をアナウンスできることを誇りに大変喜ばしく思います!

サンドボックスへのアクセスはhttp://www.platform9.comへアクセスし、サインアップしてください。

ログインを終えると、多くはありませんが組み込みのGlanceイメージと仮想マシンのフレイバーにアクセスできるテナントのロールが割り振られます。ここから簡単に仮想マシンを展開し、コンソールにアクセスしたりや起動、シャットダウン、仮想マシンの構成変更などのデイ2(展開が終わった翌日)の運用を試してみていただくことが可能です。ユーザーインターフェイスから殆どのワークフローを実行することが可能となっています。これはサンドボックス環境ですから、ホストの追加やルーターの追加、新しいGlanceイメージのアップロードなどの特定の運用は行えません。我々はサンドボックス環境へ随時新しい機能を加えていきます。

サンドボックスは最初のログインから4時間だけ利用することが可能です。もし、もっと時間をかけてPlatform9 Managed OpenStackインフラストラクチャを試してみたいと言う場合にはいつでもフリートライアルへアクセスいただくことが可能です。

さぁ、まずhttp://www.platform9.comまでアクセスを!

冒険を楽しんでください!

訳注: リソース上の都合で国内ではフリートライアルへのお申し込みを制限しておりました。今回利用可能になったテストドライブ(http://www.platform9.com)はこの制限を受けません。誰でも、いつでも、Platform9 Managed OpenStack環境を4時間好きなように利用することが可能です。上の記事でも述べられている通り、テナントロールでのアクセスを想定しているため、完全な管理者アクセスにて評価を行いたいという場合には以下のWebセミナーへお申し込みください。

【Webセミナー】Platform9 Managed OpenStack Web&デモセミナー
話題!日本上陸直後のPlatform9 Managed OpenStackを徹底解説 & デモを実施

昨年、OpenStack Summit 東京での開催、先日開催OpenStack Summit Days Tokyo 2016の大成功、大規模な導入事例発表など、OpenStackの熱気はいよいよ日本国内へも押し寄せてきています。
しかし、OpenStackはオープンソースプロジェクトでそのものはフリーで提供されていますが、そもそもインストールが難しい、運用管理していく手間とコストが膨大になる、アップグレードがうまくいかないなど、一般的な企業のお客さまにとっては多くのハードルを抱えています。

本セミナーではOpenStackの5つの展開方法とそのメリット・デメリットを上げた上で、
Platform9社が提供するユニークなOpenStack-as-a-serviceについてご紹介致します。
これまでになかったアプローチでのOpenStackの利用開始、運用、そしてその効果についてあますところなくお伝え致します。
本セミナーへご参加方にのみ、Platform9 Managed OpenStackのフリートライアルアカウントをお渡し致します。是非奮ってご参加ください。

さらにここまで読んでくださった方向けのオトク情報!!

@Networld_pf9 アカウントをフォローした上で、本セミナーの登録ページへのツイートをリツイートしてくださった方にはセミナー実施前にも優先的にフリートライアルの割当を行っております。

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

2016/08/10

Platform9上にPlatform9を動作させる

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

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

僕らも自分のケーキを食べてもいい? 数ヶ月のコンセプトから本稼働環境での利用に至るまでの開発を終えた我々が、自分自身と我々のプライベートなPlatform9 Managed OpenStackのインスタンスに問い続けた質問です。我々はこれを親しみの意味を込めて「ドッグフード」と呼び、日々のビジネス ー継続的な統合と検証ー の大部分で活用しています。

少し前置きを。ご存じの方もおられると思いますが、Platform9はエンタープライズの顧客がご自身のインフラストラクチャのリソースを集約し、柔軟なプールへと変えるようなビジネスをしています。プール化されたインフラは最新鋭のオープンソース・ソフトウェアを利用してPlatform9によって稼働、管理されおり、サービスとして提供されています。マネージドOpenStack、これが我々の最初の製品はこのモデルです。そして、顧客に社内のサーバ、ストレージ、そしてネットワークを利用しながら、完全なOpenStackで構成されたプライベートクラウドを提供します。しかも、複雑なソフトウェアのインストール、構成、拡張、バックアップ、アップグレードは顧客からは見えません。これをどうやって実現する? クラウドのメタデータとコントロールソフトウェアを展開ユニット(Deployment Unit - DU)と呼ばれる要素の集合としてホスティングします。セキュリティのために、それぞれの顧客は自分自身の、完全に隔離されたDUを割当て、それをPlatform9が管理します。

最も単純な形では、DUはデータベースとGlanceとNovaの管理要素(API、スケジューラー、コンダクター、ネットワーク)のOpenStackコントローラーサービス群からなります。顧客のニーズが大きくなるにつれ、DUは複数のサーバーへと拡張することが出来、さらには地理的にも広がっていくことが出来ます。これによってパフォーマンスと可用性を上げていくことが出来ます。簡単のため、この記事では1サーバで構成されたDUにフォーカスします。我々はDUがほとんどあらゆるコンピューティングインフラストラクチャ上で動作するように設計しました。例えばパブリッククラウドや自分自身のデータセンタで動作します。若いソフトウェアカンパニーと同様、我々も必要なコンピューティングを得るためにAmazon Web Services(AWS)を利用することにしました。


  +------------------------------------------------------------------+
  |               展開ユニット (Deployment Unit - DU)                | 
  | +-----------------+ +-------------------------+ +--------------+ | 
  | | PF9コントローラ | | OpenStackコントローラ群 | | データベース | | 
  | +-----------------+ +-------------------------+ +--------------+ | 
  +------------------------------------------------------------------+
            /                              
           /                                
          /          インターネット              
- - - - -/- - - - - - - - - - - - - - - - - -  - - - - - - - - - - - - - -
        /          顧客のイントラネット           
       /                                        
+--------------------------------------------------------+    +----------+
| +------------------------+ +-------------------------+ |    |          |
| | PF9 ホストエージェント | | OpenStackエージェント群 | |    |          |
| +------------------------+ +-------------------------+ |....|          |
|                         ホスト 1                       |    | ホスト N |
+--------------------------------------------------------+    +----------+

多くの近年のクラウドソフトウェアの設計に習い、OpenStackはコントローラ/スレーブのアーキテクチャを採用し、インフラストラクチャの要素を管理・監視します。例えば、コンピューティングホストの管理のため、OpenStack Novaはnova-computeと呼ばえるスレーブエージェントを各管理対象ホストに配置します。最初のManaged OpenStackのリリースでは、ホストはサポートされているLinuxディストリビューション(現在はUbuntu 12とCentOS6 ※訳注原文記事執筆当時の情報です)が動作していればどんなホストでも構いません。コンピューティングキャパシティをプライベートクラウドに追加する際には、顧客はまず、それぞれのホストにゼロコンフィグレーションのPlatform9のホストエージェントを展開します。それぞれのホストエージェントは自身がインストールされているホストをセキュアなアウトバウンド接続を利用して顧客の展開ユニットに登録します。承認(authorization)と呼ばれるステップを通じて承認されると、エージェントはDUに対してホストにとって適切なソフトウェアや構成を問い合わせ、自動的にダウンロードしてインストールし、それらのソフトウェアの構成を行います。特定のホストに適切なソフトウェアの分配を決定する際にはホストにアサインされた役割(role)によって決定します。例えば、普通はコンピューティングホストはnova-computeエージェントを受け取ります。一方で、イメージライブラリホストはPlatform9が特別にパッケージしたソフトウェアを受け取り、それをイメージキャッシングサーバとして利用します。一つのホストが複数のロールを持つことも可能です。まとめると、図1になります。これが通常の顧客の目線から見たManaged OpenStackの展開の様子です。

継続的な統合と検証

Platform9のトッププライオリティは製品を高い品質に保つことです。Managed OpenStack(MO)を検証するため、我々は継続的なビルド&統合サーバ(Teamcity)を用いて、要素/機能検証と統合テストを組み合わせて実施しています。我々は大抵は1つのgitリポジトリを機能コンポーネントごとにメンテナンスしています。Managed OpenStackのリリースのために必要なバイナリを生成する際に、全体で12ほどのリポジトリからのコードのビルドと検証が必要です。リポジトリのうち、いくつかはPlatform9ヴァージョンのOpenStackコンポーネントですし、残りは完全なPlatform9だけのソースコードです。標準のOpenStackのコードは広範な機能検証が含まれており、OpenStackのリポジトリにコードがチェックインする度に検証コードが動作します。

統合テストはもっと複雑で、製品全体を検証し、さらにコンポーネントの展開や接続までを最終形として実施する工程までを含むため、完了までに長い時間がかかります。Managed OpenStackの展開トポロジは通常のOpenStackとは異なっていますので、Platform9固有のシナリオー例えば、ユーザーの認証、ホストの認証、イメージライブラリからのインスタンスの展開、ネットワーク機能、NFSのサポートーでの検証のために多くの統合検証コードをスクラッチから書き起こしました。これを書いている最中にも、17の大きな統合テストが成功に終わることをまっています。上手く行けばManaged OpenStackのビルドがうまくいくということです。それぞれの検証は自分自身で1~15ホストー平均的には大体3ホストーの展開ユニットを作成し、多くの項目に渡る、小さな検証を実施しています。標準では検証用の展開ユニットは1台のコンピューティングインスタンスからなっています。大抵の1つのMOで17の展開ユニットを展開しますので 3 x 17 ~= 50ホストのインスタンスが稼働することになります。ピークの時期になると、CI(継続的な統合)サーバは1日に10回はMOの作成を行います。つまり、170の展開ユニットで500ホストインスタンスを稼働させているということになります。

仮想化環境上に作られた検証インフラストラクチャ

上で述べてきた検証の負荷の推測はあくまで本日(訳注:記事執筆当時)のスナップショットです。もちろん、初期には負荷はずっと軽かったです。他の若い会社と同様に、我々のニーズは最初の一年間で劇的に成長しました、そして、幾つもの失敗の中から多くの教訓を学んだのです。我々の検証のニーズに適合するために、今日我々が検証インスタンスを動作させているインフラストラクチャとその検証を自動化している方法は以下のテーブルにまとめてあるように進化してきました。興味を引くポイントは我々がどのように仮想化を活用し、ソフトウェアのレイヤーを積み上げているかです。

Fig008

フェーズ 1

当初、当然のように我々は検証環境を実際に利用される環境にできるだけ近い形で作成しました。つまり、展開ユニットはAWS上で、Platform9のささやかなデータセンタ内におかれた実際のサーバをコンピューティングホストとして利用します。これはたいていのお客様が経験するであろうセットアップの環境を再現するためでした。このアプローチで我々は2つの問題に突き当たります。一つ目はホストが実際のCentOSまたはUbuntuが動作しているLinuxコンピュータですから、それぞれの結合テストの前に初期状態に復元するためのスクリプトを開発しなくてはならなかったことです。「bit rot(訳注:長時間にわたってコンピュータを使うことでメモリやデータに小さな変化が積み重なり、不安定になること)」と呼ばれる概念をご存知の方もおられると思いますが、これは言うほど簡単なことではありません。様々な努力にもかかわらず、何度もサーバはコントロール不能になり、検証の結果は一環したものにならず、バグを診断するのが難しくなってしまいました。もっと大きな問題は拡張性です : 単純に、我々は増え続ける検証の負荷に見合うだけの十分なハードウェアを購入できない状況になったのです。


   +----------------------------------------------------------+
 2 | 統合検証中に Nova インスタンスが作成される               |
   +----------------------------------------------------------+
 1 | 物理サーバ上の Linux KVM ホスト上のPF9 compute/imagelib  |
   +————————————————————————————————--------------------------+

フェーズ 2

これらの問題を解決するため、我々は以下の表に表したとおり、PF9ホストが動作する検証インフラストラクチャをハイパーバイザー上(最初はESX、そしてその後KVMが動作するネイティブのLinuxへ変更)の仮想マシンへと変更しました。これによって、入れ子になった仮想化が追加されることになります。つまり仮想ハイパーバイザー(2層目)が仮想マシンとして実際のハイパーバイザー(1層目)の上で動作するということです。ESXとKVMはいずれも入れ子の仮想化をある程度の信頼性を持ってサポートしています。(我々はESXがやっぱり素晴らしいということと、ですが、非常にパフォーマンスが限られている場合、KVMのほうが高速で、やっぱりバグや不可解な動きがあることを発見しました。これはこれだけでもう一つ記事が書けそうです。)


   +----------------------------------------------------------------+
 3 | 統合検証中に Nova インスタンスが作成される                     |
   +----------------------------------------------------------------+
 2 | それぞれの検証毎に PF9 compute/imagelib Linux KVM ホストを作成 |
   +————————————————————————————————--------------------------------+
 1 | 物理サーバ上の ESX または Linux KVM                            |
   +—————————————————————————————————-------------------------------+

我々はPlatform9 Managed OpenStackホスト(2層目)で保持されている仮想マシンの作成や廃棄を担当する機能ライブラリを開発しました。ちょうどこの頃、我々は最初のエンドツーエンドの統合テストの開発を終えました、さらにPythonベースの検証フレームワークの最初のヴァージョンも完成します。社内のTeamcityの統合サーバはコードの変更イベントが発生すればビルドと検証をすべて行ってくれるようになっています。これはコード、ビルド、検証に至るまでエンドツーエンドで自動化統合が完成した時でした。これによって我々はManaged OpenStackの能力を確信もしましたし、品質の期待値を劇的に改善することになります。

フェーズ 3: 「ドッグフード」の誕生

コンポーネントの成熟し、さらに全体がしっかりと結合してくるにつれ、いよいよエンタープライズプロダクトらしくなってきました。我々は適切な機能についてや、適切なユーザーエクスペリエンス、どれだけの信頼性が必要とされるか、セキュリティ、パフォーマンス、拡張性など、数多くの議論を交わしました。終わりのないホワイトボード、ワイヤフレーム、プロトタイプの末に我々は自分たち自身がユーザーにならなければ多くの問題に答えを出すことは出来ないという結論に達しました。言い換えれば、我々の業務(もしくはその大部分)をPlatform9 Managed OpenStack上で行うということです。アメとムチでいうと、これはムチです。

幸運なことに、我々の継続的なビルド、統合、検証にはアメとなりました。我々のごちゃごちゃしているベアメタルのハイパーバイザー(1層目)の上で動作する仮想PF9ホスト(2層目)を管理するためのbashスクリプトやPythonコード群はどんどん複雑化し、維持していくのはまさに悪夢になってきました。我々はテンプレートイメージやホスト間の論理配置、ハイパーバイザーの違い(ESX、CentOS Linux、Ubuntu Linux)に対処出来るだけの綺麗な抽象化を実現していませんでした。こうした問題を解決するためにOpenStackが優れていることは明らかでした。一貫したAPI、CLI、リソースの抽象化、自動配置のアルゴリズムなどが搭載されているからです。

「ドッグフード」プロジェクトはこうして生まれました、そしてこれは今日までに当社がとったエンジニアリングの決断の中で最も大きなものの一つになります。ドッグフードは単にPlatform9 Managed OpenStackの単一のインスタンスです。その展開ユニットは「クラウド」(今はAWS)で動作しており、公開DNSのアドレスでSaaSとして公開されています。全てのコンピューティング、ストレージ、ネットワークリソースはすべてPlatform9のプライベートデータセンタに配置されています。

最初の実装では、我々はPlatform9ハイパーバイザーホストを仮想化していました。会社においてあるハイパーバイザー上で仮想マシンとして動作させていたのです。これは更にスタックに仮想化レイヤを追加することになります。結果は下の図のとおりです。我々はこの追加のレイヤをハードウェアの仮想化サポート機能を完全に利用できるうまい方法を見つけ出すことが出来なかったため、我々は仮想マシン上でQEMUエミュレーションを動作させるしかありませんでした。これはものすごく遅いのです。我々はパフォーマンスが犠牲になるのはわかっていましたが、幾つかの理由でこれを選択しました。まず、仮想(物理の反対という意味で)ドッグフードのハイパーバイザーホストは簡単に作成、管理、廃棄することが出来、それによって必要に応じてホスト数をスケールアップするような操作を簡単に行なえます。2つ目は、このやり方であればすでに持っている稼働率の低いハードウェアを利用できるので、それによって更に物理サーバを追加する際の選択肢も広くなるということです。3つ目は、この時点ではインスタンスを大量に起動する大部分の検証は単にインスタンスがアクティブ状態に到達することを確認するだけのものがほとんどでした。こうした際には検証は早々に終了させることが出来、インスタンスのゲスト内部のスピードはさほど重要ではなかったのです。


   +----------------------------------------------------------------+
 4 | 統合検証中に Nova インスタンスが作成される                     |
   +----------------------------------------------------------------+
 3 | それぞれの検証毎に PF9 compute/imagelib Linux KVM ホストを作成 |
   +----------------------------------------------------------------+
 2 | ドッグフード PF9で管理された仮想の Linux KVM                   |
   +————————————————————————————————--------------------------------+
 1 | 物理サーバで動作する ESX または Linux KVM                      |
   +—————————————————————————————————-------------------------------+

予定通り、我々は自動化のコードを変更してOpenStack Nova APIやCLIを活用できるようにしました。Bashスクリプトは大抵はCLI(nova utilityなど)を利用するために利用されています。そしてPythonコードはRESTをコールする際に利用しています。テンプレートイメージやコンピューティングインスタンスのライフサイクルは一貫した方法で管理できるようになりました。例えば、我々は「刈り込み」というスクリプトを利用して、ビルドの前や、検証の後の時間に古いテンプレートやインスタンスを削除します。様々な理由から、特定のテンプレートやインスタンスを削除せずに保持しておく必要性が出てきます。この機能を実装するため、我々はNovaとGlanceのオブジェクトメタデータにタグを追加し、テンプレートとインスタンスを同じ方法で取り扱うことを実現しました。メタデータのキーに「dont_delete」を追加しておけばよいのです。

フェーズ 4 : ドッグフード 2世代目

ドッグフードの最初の実装はちょっとした統合テストを行えば良いような、会社が小さいタイミングでは充分によく動いてくれました。これはその後の数ヶ月で多くの新しい開発者がチームに入り、多くの機能が追加され、製品の品質を強化するために動作させるビルドや検証の数が爆発的に増えていくにつれ、変わってしまいました。それだけではなく、レイヤ上で動作するQEMUのエミュレーションのパフォーマンスも、もはやインスタンス内のゲストOで動作する興味深い検証などが新しく生まれてきたため、受け入れられなくなってきました。例えば、ほとんどの我々のネットワーク関連の検証はゲストと他のゲスト、または外部システムとの接続を検証します。結果としてOSとして完全にブートが終わるまで待つ必要があります。こうした問題が重なると、ランダムに操作がタイムアウトし、検証に失敗します。これによって我々のエンジニアリングの生産性は地に落ちてしまいました。

我々はパフォーマンスの問題を解決するために、ドッグフードのための専用のハードウェアを購入しました。これによって以下の図のように1つ仮想化レイヤーを削減できました。Linux/KVMをベアメタル(1層目)にインストール、構成しないといけないという柔軟性の喪失は当然のトレードオフです。それを埋め合わせるために、我々はできうる限りのプロセスの自動化を進めました。例えば最初のOSのインストールにはPXEを利用し、Ansibleの構成管理ツールで各ノードに必要なソフトウェア構成を送り込みました。


   +------------------------------------------------------------------+
 3 | 検証中に Nova インスタンスが作成される                           |
   +------------------------------------------------------------------+
 2 | それぞれの検証ごとに PF9 compute/imagelib Linux KVM ホストを作成 |
   +------------------------------------------------------------------+
 1 | ドッグフード PF9 で管理された 物理 Linux KVM サーバ              |
   +————————————————————————————————----------------------------------+

フェーズ 5: ドッグフード 第3世代

ここに至るまで、すべての統合検証環境の展開ユニットは常にパブリッククラウド(AWS)上に展開されています。最初に述べたように、これは実際に利用される環境に可能なかぎり近づけたいという理由からでした。しかし、日々多くの検証のための展開ユニットが生成されるアプローチで、それが100を超えてくると、我々のAWSからの請求書は快適というレベルをあっという間に超えてきました。インスタンスを動作させているというコストからだけでなく、補助的に利用しているEBSストレージ、ネットワーク帯域、RDSデータベースなどからのコストも含まれている結果です。

我々はそれぞれの統合検証が何をしようとしているのかを見直し、殆どの我々の検証はDUが我々のプライベートなインフラストラクチャで動作していたとしてもその価値を失わないという結論に至ります。ですから、我々は検証をAWSではなく、ドッグフード上に展開ユニットを作成するように変換しました。念のためですが、我々はAWSとドッグフードの両方で様々な検証を行っています。我々は徐々に本日我々が利用している構成にシフトしてきました。ドッグフードでは様々な形で我々の日々の継続的なインテグレーションが動作しており、全てのコードのチェックインの度に実行されています。AWSでは定期的に、もっと小規模に実施しています。我々のAWSのためのコストは劇的に下がり、安定しました。しかしながら、ドッグフードを動作させ、適切なハードウェアのリソースを提供し続けるのも時間とお金がかかります。ですから、正確なコスト比較については詳細の分析を待たなければなりません。これが大きな削減になったようなら、またブログの記事を投稿します。

頻繁な更新

ドッグフードは頻繁にアップグレードやアップデートされます。我々のポリシーは実際に顧客のDUへ提供開始する数週間から数ヶ月すべてのコードの変更と昨日の追加を全て展開するというものです。我々はこうした更新を手動で行っています。今後は夜間に自動でアップグレードされるように変更しようと計画しています。

個人利用

加えて、統合検証などで利用するため、我々のプライベートクラウドは各々の従業員向けに個人利用のために開放されています。我々のMacやLinuxマシン上に、novaコマンドラインユーティリティを簡単にインストールし、標準的なOpenStackに接続する環境変数は:


[leb:/devel/pf9-main/testing]$ env|grep OS_
OS_USERNAME=XXXXXXX
OS_PASSWORD=XXXXXXX
OS_AUTH_URL=https://XXXX.platform9.net/keystone/v2.0
OS_TENANT_NAME=service

殆どの開発者は一時的なインスタンスでバグのトラブルシュートや数日で実装できてしまうような機能の開発を行います。他ではもっと長い期間のプロジェクトのために、長時間利用できるインスタンスを作成するか、単に個人の開発環境をホスティングします。我々はOpenStackのタグ機能を利用して、インスタンスやイメージに所有者や目的などの情報についての注釈を入れたりしています。また、頻繁に既存のインスタンスのスナップショットを取っており、試験を動作させる前の状態へと復帰出来るようにしてあります。ユーザーインターフェースについては社内のほとんど半分のユーザーはCLI互換でのアクセスをしていますが、残りの半分は大体はPlatform9のウェブユーザーインターフェイスを利用しているようです。

実体験からの教訓

我々が自分自身のビジネスをPlatform9 Managed OpenStack上で動作させ、ドッグフードを行うと決めた時、とても重要な予見を持っていました。それは、製品に血管があった場合に、我々の会社にすぐにも影響が出てしまうということです。これが我々にとってはトラブルシュート、原因の根本的な解決、問題の迅速な修正についての強いモチベーションになりました。これはまったくもって、予見したとおりでした。製品を日々利用し、ミッションクリティカルなタスクをそれに依存していく中で、我々が検証だけでは様々な理由で見つけられなかった問題を発見することが出来ました。

我々の例は運用が急激にスケールするものです。我々の最初の世代の結合テストでは5ホスト未満でコンピュートインスタンスも1から10インスタンス程度のもので、日々のビルド・検証では数百インスタンス程度の負荷でした。ですが、直ぐに数千インスタンスにも膨れ上がったのです。我々は全てのコンピューティングホストがアイドル状態であっても、それぞれのnova-computeエージェントのサブシステムのうちの幾つかが定期的にNova controllerに状態のアップデート、たとえばKVMの仮想マシンの数やその状態を送るということを知りました。それぞれのこのステータスメッセージはcontrollerに少しずつながら、負荷を加えてゆき、その負荷が充分に大きくなると、公開APIのリクエストの処理をスローダウンさせるということを発見しました。この問題が積み上がっていくと、APIの呼び出しがタイムアウトし、他のビルドタスクの開始に失敗してしまうのです。

他にも、拡張性関連の問題がブートストーム問題の中から燻り出されてきました。上で書いたように、現在製品全体の統合ビルドを行うと、17種類の結合テストが開始されるようになっています。これらのテストは並行して、初期化シーケンスを経て、最終的には50ほどのコンピューティングインスタンスが同時稼働し始めます。我々の統合ビルドサーバは同時に3つのビルドしか同時に走らないように構成されているので、結果としてピークの際には100異常のインスタンスが同時に走ることになります。適切なほどに能力のあるコンピューティングサーバを利用しなかったので、我々はソフトウェアのサブシステムの幾つかが、このスパイクを我々が期待しているほど上手く取り扱うことが出来ないということを発見しました。リクエストがバッチ的に集中する場合、nova-scheduler サービス(インスタンスの配置を決定する)がしばしば同じホスト上に異様に沢山のインスタンスを配置し、リソースを食いつぶしてしまうことがありました。見る限り、ロードバランシングのアルゴリズムがホストの負荷の変化に十分な速さで対応ができていないように見えます。今のところ、これが構成上の問題なのか、設計上の問題なのか追求を進めているという状況です。また、ホストが同時に多くのリクエストを同時に受信するとインスタンスのディスクの処理のための高いCPUとI/Oの負荷の処理で「libguestfs」のサブシステムでタイミングによるバグが出ることも見つけました。これはゲストOSのネットワーク設定を構成する際に利用されます。このバグは修正済みです。

ドッグフードではさほど負荷がかからない、けれども長期にわたって起動し続けるシステムにおいて発生する不具合も見つけ出すことが出来ました。Novaを構成するサービス群は数多くのバックグラウンドタスクを走らせ、メンテナンス用のためのタスクを定期的に活動させます。それぞれのタスクは自分自身でタイマー期間設定を保持しています。あるタスクはその後のタスクの状況に依存している場合があり、その中に長時間に及ぶタイマー設定のタスクがあると数分から、数時間稼働してしまいます。これは時によって非常に見つけにくいバグで発現するのも数日後、しかも特定の状況においてのみ発生するというものです。

不具合や、パフォーマンスの問題を見つける以外にも、日々自身のプロダクトを使うことで製品の至らなさを見つけ、改善することができ、これは我々だけではなく、お客さまにとっても素晴らしい機会となりました。例えば、ウェブインターフェースを利用している時、ある従業員が誤って大きなインスタンスのグループを選択し、それを消してしまうということが有りました。重要なインスタンスがいくつも失われてしまい、こうしたアクシデントが起こらないようにするためにはどうしたらよいか、という議論をすることになります。これに対するソリューションは我々の問題トラッキングシステムの異なるチケットとして様々な形での提案が寄せられます。他と同様に我々は機能追加についてのプライオリティ付を行い、どの製品ヴァージョンでどのリリースを取り込むかを決めます。上で上げた問題では、UIの改善が実装され、ユーザーが大きな破壊操作を行おうとしていることを理解させることが出来るようになりました。最終確認を終え、この変更は既に製品に取り込まれています。製品のAPIレベルで書き込み禁止のフラグを追加で立てるというもっと先進的な改善実装も出来ますが、これは将来のリリースで実装予定です。

将来の方向性

我々はドッグフードの利用範囲を近日中に更に拡張しようと考えています。まずは我々はプロダクトだけでなく、そのワークロードへも拡張しようと考えています。殆どの我々のビルド・統合サーバはベアメタルのハイパーバイザー(ESXとLinux KVM)として動作しており、手動で管理されています。我々はこのミッションクリティカルなシステムを我々自身のプライベートクラウドへと移行させたいと考えています。他の移行候補としてはインフラストラクチャシステムが有ります(例えば、DHCP、DNS、NFS)そして、従業員の個人開発環境などです。

次に、将来のリリースでDockerコンテナのようなLinuxコンテナの管理をサポートする大規模なリリースを予定しています。(訳注:Platform9 Managed Kubernetesとしてリリースされています!)つまり、我々は革新的な方法でコンテナを我々のビジネスに取り入れることが出来るように考えているんです。例としてはまだ検討中ですが、Dockerの大規模スケールでの小さなオーバーヘッドを活用して、何千ものコンピューティングノードのテストを実現したいと考えています。このテクノロジーを利用することで我々のビルドサーバで発生する初期化が不十分であるという問題を解決し、ライフサイクル管理を簡略化したいと考えています。コンテナは常にそれぞれのサーバがクリーンな初期状態で起動することを保証してくれ、しかも高速に起動します。最初のコンテナの管理はマニュアル操作とカスタムのスクリプトで行いますが、直ぐにPlatform9 Managed OpenStackのAPIを利用して出来るようになると思っています。

最後に

自分自身のビジネスをPlatform9 Managed OpenStackで走らせたことは、疑いようもなく我々の製品の改善に役立ちました。日々の面倒な継続的なビルド・検証のシステムをそこへ任せることで、我々は多くの重要な問題を発見し、修正することが出来ましたし、それは人工的な検証シナリオでは見落としてしまうようなものでした。実際の利用シナリオにおける製品の強さと弱さを理解することが出来、そしてユーザーエクスペリエンスと機能の重大なギャップも埋めることが出来ました。これはこの活動の「ケーキ」とも呼べる収穫ですし、そのように意図したとおりとなりました。

この努力によって我々はより俊敏に、そして効率的になったか? 最初の投資コストは正直な話、非常に高いと言わざるをえないものでした。時間、新しいハードウェア、人件費。しかし、今ではシステムが安定し、鼻歌を歌ってくれています。我々はPlatform9 Managed OpenStackが劇的に我々の開発検証の業務を改善し、大規模な自動化を簡単なものにしてくれたと確信することができています。そして、最終的に見ると、今回の努力はパブリッククラウドのためのコストの削減につながりつつ有ります。その通りです、我々は長期の投資の観点から見て危機に脅かされていたのです。このプロジェクトによってそれは解消し、また、我々と我々のお客様のメリットの観点からはより大きな成果を挙げつつあるのです。

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

2016/07/20

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

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

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

Fig004

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

  • 展開が容易というだけのプライベートクラウドではなく、管理も容易でなくてはなりません。Platform9で、我々は顧客にとっては退屈な展開作業や監視、拡張、バックアップ、更新など、クラウド管理システムを管理するということは現実的ではなく、取り除くべきだという決断をしました。我々はクラウド管理自身をSaaSとして提供するというユニークなモデルを成し遂げたのです。
  • インフラストラクチャ、スキルセット、手順などのすでに顧客がお持ちの資産を活用できるプライベートクラウドである必要があります。これはまっさらな環境を必要とする多くのソリューションとは対照的です。Platform9は既存のKVMやVMware 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)

2016/07/13

24時間365日のOpenStackの監視 : アーキテクチャとツール

本記事の原文:24/7 OpenStack Monitoring: Architecture and Toolsの公開は2016年の5月24日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

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

OpenStackのCeilometerプロジェクトがテレメトリーについて、大きな人気を博している一方で、これ自体は本当の意味でのOpenStackの監視ソリューションにはなりえません。CeilometerはOpenStackで管理されているオブジェクト(インスタンス、ヴォリューム、ネットワークなどの全て)の利用状況のデータを集めるデータ収集サービスであり、OpenStackのエラーや不具合を監視するための、すぐに使えるというソリューションではないのです。我々のコアバリューはお客様のためのOpenStackの監視を提供していることですから、我々はOpenStackのプロアクティブな(事前対応的な)24時間365日の監視をどのように実現するか、考えなくてはなりませんでした。

今回の記事では、Platform9がどのようにOpenStackのマネージドサービスを監視しているのか、そしてどのようなツールを使ってそれを実装しているのかについて解説していきます。プロアクティブな監視は100%の顧客満足度を実現している我々の秘伝のソースのキー要素で、業界をリードするOpenStackのSLAの実現に大きく寄与しています。ご自身のOpenStack環境の監視についての戦術を模索しているのでしたら、この情報は絶対にお役に立つと思います。

監視とは何か? どうしてそれが重要なのか?

監視は収集、分析のシステム化された手順であり、そのデータを例えば、プライベートクラウドのような複雑なシステムの健全性の継続確認に利用することです。もっとシンプルにいえば、監視とは問題となっているものについて警告を上げてくれるという事になります。

クラウドを監視するためには、そのクラウドを構成する物理や仮想のリソースやそのユーザーやサービスの動きについての確固たるデータの収集が必要となります。収集されたデータは殆どの場合、リアルタイムに分析され、事前に定義されたクライテリアに応じて適切なアクションを発行します。また、大抵はそのデータは中長期のトレンド分析のために保存されます。

最低限、監視はシステムを健全な、動作状態へ復旧させるために、障害イベントについて検知できなくてはなりません。しかし、こうした事後対応的な監視では、システムにダウンタイムが発生し、ユーザーの不満を生み出すことになります。プロアクティブな(事前対応的な)監視ではエラーの状態をチェックすることは、システムやユーザーの振る舞いによる不具合だけでなく、システムのパフォーマンスやイベントログについても考慮に入れておかなくてはなりません。

監視によって集められたデータはエラーや問題のトラブルシューティング、そしてユーザーにそれが影響が出る前にその問題を発見するために利用されます。加えて、監視で得られた知見はクラウドのリソースのキャパシティプランニングの役に立ったり、コンプライアンス準拠への監査に利用したり、他にもいろいろなことに利用が可能です。

OpenStackの監視についての現状

最低限で構成されているOpenStackにおいても、最低限、様々なコントローラーサービスの監視が必要となります。 Nova、Glance、Cinder、KeyStone、Neutron、等々です。加えて、全てのコンピューティングノード、ストレージノードの監視も必要です。OpenStackのサービスを使う幅が広がれば完全なOpenStack環境の監視に必要となる監視項目も増えていきます。CeilometerプロジェクトはOpenStackコミュニティ内で活況を呈していますが、これはOpenStackが管理しているオブジェクト(インスタンス、ヴォリューム、ネットワーク等)の利用状況を計測するように設計されており、インフラストラクチャやOpenStackの内部コンポーネントの健全性を監視するようには設計されていません。CeilometerをOpenStack全体の監視が出来るように改造しようという様々な試みが行われていますが、上手く行ったものはありません。理由はそのような目的のためには設計されていないからです。

最も広く利用されている監視ソリューションはNagios、Zabbix、Graphite、ELKStack(ElasticSearch、LogStashに加えてKibana)などのツールを組み合わせたお手製のツールであるというのが実情です。

Platform9にとって何故24時間365日の監視が重要なのか?

Platform9はあらゆるお客さま、あらゆる規模のプライベートクラウドを可能な限り簡単にすることを目指しています。我々のソリューションはOpenStackをマネージドサービスとして提供します。これは、我々はOpenStackクラウドコントローラーを分離されたOpenStack環境としてお客様の代わりに管理し、展開、監視、トラブルシュート、アップグレードについて責任をもって対応することを意味します。我々はお客様のデータセンタ内に完全にデータを残したまま、お客様のインフラストラクチャのリソースを管理しなくてはならないのです。

Fig002ですから、本当の高可用性のある、本稼働環境を想定したサービスを提供するためには我々は24時間365日のOpenStack監視を提供し、顧客のクラウドインフラストラクチャのあらゆる箇所での問題を知っておかなければならないのです。

Platform9は何を監視しているか?

簡潔に言うと : 我々のSLAに影響があり得るものの全て

Platform9は我々がお客様に保証しているOpenStackのSLAに影響を与えうる全てのコンポーネントを常に監視しています。この監視インフラストラクチャは我々の開発環境の物理サーバやクラウドインスタンスの監視も行っており、開発チームの生産性を上げるためにも役立っています。目的は我々のお客様と開発チームの双方が必要なリソースが利用できることを保証することです。

これを保証するために、我々は全てのOpenStackサービス、その下のコンピューティングとストレージ、ネットワークインフラストラクチャ、そしてOpenStackのデータプレーンコンポーネントについての情報を収集しています。こうした情報を収集することによって取るべき対応が明確なイベントを生成することができ、我々のアラートインフラストラクチャーを通じて通知されます。これによって我々のサポートチームはプロアクティブにお客様と連絡をとり、我々が検知した問題をお伝えしたり、お客様のハードウェア側で発生した問題を解決することができるのです。

アラートはその通知の種類や他のパラメーター、例えばその発生箇所によって特定のエンジニアにも通知されるようになっています。例えば、OpenStackのコントローラーノードが期せずして利用できなくなった場合、我々の開発チームに通知が行われます。また、お客様のホストが非計画の停電でダウンした際には我々のサポートチームに通知が行われますので、サポートチームはお客様とのコミニュケーションを開始します。とある女性の開発者が出社して開発にあたっている際には、特定の部分の問題であれば通知を受け取るようにすることも出来ます。これによってアラートを無視してしまうということを防ぐことが出来ますし、そうでなければ重大な問題が発生し、膨大な量のログに本当の問題が飲み込まれてしまうのです。

我々のOpenStack監視のアプローチの主な要件は以下のとおりです :

  • ステータス監視 - メッセージキューとの切断または非応答
  • 健全性監視 - キャパシティやパフォーマンスの欠乏
  • レポート生成 - 1ユーザーが動作させる最大インスタンス数、コンピューティングインスタンスの平均起動時間
  • 不具合検知 - 短時間で顧客の1つの操作が影響するインスタンス数(又はヴォリューム、スナップショット、ネットワーク)
  • ログ分析 - 分析を行うために全てのログ内のエラーを一箇所に格納する
  • サポート性 - サポートチームが特定の顧客の状態にRead-Onlyでアクセス出来るようにする

以下の様なデータを含めておく必要があります :

  • 単純な時系列データ - コントローラーの負荷状況、RabbitMQの健全性状態
  • トランザクションデータ - Nova APIの監視、すべてのユーザーのインスタンスの詳細
  • 重要なオブジェクトの状況の変化 - cinderヴォリュームがエラー状態へ移行した

OpenStackの監視を7つのキーとなるツールで設計する

要件を満たすため、我々はOpenStackの包括的な監視を行うことにしました。Platform9は多くのツールを併用して利用しており、その相関や相互依存関係を図示したのが次の図です。

Fig003

  • VictorOps クラウドサービスに重大な問題が発生した時、連絡に利用するアラートサービス。アラートメッセージはその問題毎に適切にカスタマイズされ、SMSや電話にプッシュ通知を発行します。Platform9はVictorOpsとはWebhookで通信を行います。またSlack channelに直接メッセージを送信することも出来ます。
  • SumoLogic 様々なOpenStackサービスや他のサブシステムが生成するログファイル全てを分析し、知見を提供するデータ分析サービス。GUIでの検索機能やシステムのログファイルの証跡として利用することが出来ます。SumoLogicは更に分析をするために検索を保存する機能やSlack channelにメッセージを発行することも出来ます。
  • ServerDensity 外部から我々のサーバを監視し、様々なイベントをアラートしてくれます。Platform9のサーバへ様々な地理的に隔たった場所からpingを発行し、VictorOps経由でメッセージを送ってくれます。我々はServerDensityを接続のチェック、アラート、チャート、我々のウェブサイトの負荷状態などに利用しています。負荷状態、ディスク利用状況、ネットワークトラフィック、メモリ利用率などの情報も含まれます。
  • Signal Fx 強力なグラフィックスとユーザーインターフェイスでデータのトレンドを分析するのに役立つデータ可視化サービス。データはREST APIで時系列のデータベースに格納されます。問題があるような場合には特定のお客様の利用状況にズームインすることも出来ます。
  • Slack Slackはチーム全体の標準メッセージアプリです。他のツールから生成されたアラートや注目などのメッセージは最終的にはすべてSlack Channelへと流れ込みます。さらに、emailで3rdパーティのシステムもSlack Channelへ取り込んでいます。
  • ZenDesk お客様、そして特定の内部エラーに我々のサポートチームが対処を行うときのサポートチケットを発行するヘルプデスクサービス。ここで得られる知見によって、我々はよりお客様と強い信頼関係を結ぶことが出来るのです。
  • 顧客モニタリングサービス 上の外部サービスに加え、我々は2つのカスタムサービスを独自開発しています:
    • 監視エージェント(社内では「Reachability」というコードネームで呼ばれています) 我々のサービス内で動作し、サービスにpingを打って、OpenStackとPlatform9のAPIの健全性をチェックします。負荷状況、全体のプロセス数、空きメモリ、ディスクスペースなどの確認も行っています。
    • 文脈データサービス(社内では「Whistle」というコードネームで呼ばれています) イベントやエラーの周辺の文脈を収集するように設計されています。例えば、様々な異なるサービスに対して発行されたリクエストIDにアクセスすることで、関連するスタックを追いかけていくことが簡単になり、トラブルシューティングを容易にします。

ご自身で監視をセットアップする際の推奨事項

我々はOpenStackの監視について、そしてその実装について長い時間をかけて取り組んできました。以下はご自身でやってみようと毛細に考えておくべき幾つかのポイントです:

  • 監視ソリューションは1つで全ての規模において万能ということはありえません。継続的にシステムやアラートの見直しを行い、根本的な重要で、しっかりとした状態を保ちます。
  • クラウド上のサービスを利用する際にはインスタンスの不具合やAPIの応答不全を考慮して設計してください。リクエストは何度か再送するようにしなければ、大失敗することになると思います。
  • サーバやREST APIは内部ネットワークからだけでなく、インターネット越しの監視を行ってください。こうしておけばローカルネットワークのエラーが外部にも影響が及ぶエラーなのかを切り分けることが可能です。
  • SaaSソリューションを利用することで、ご自身で作るソリューションのための時間と労力を削減できます。こうしたソリューションは大抵先進的で、REST APIやWeb Hookをサポートしています。セットアップも簡単で、彼らの監視ツールとの接続が終われば利用開始することが出来ます。
  • 既存の製品では特定の機能やご自身のおかれているユニークな場合や状況に対応ができないというケースが有るかもしれません。こうした知見も統合監視のダッシュボードには重要になるので、カスタムで作成する事が必要になるかもしれません。

24時間365日のOpenStack監視をやってみる

もしもより簡単なOpenStackの監視ソリューションを探しているのでしたら、Platform9のようなOpenStackのマネージドサービスをご検討ください。複雑で巨大なOpenStackベースのクラウドの運用・監視の労力を削減できるソリューションを提供している会社はPlatform9だけではありませんが、我々は業界最高のプライベートクラウドのためのサポート提供の実戦経験を積んでいます。もし、もっと詳しく知りたいのであれば製品のデモやご自身でフリートライアルしてみることもご検討ください。

あなたのご意見、お聞かせください

OpenStackの監視について、みなさんのお考えやうまいやり方をお聞かせください。それによって我々のソリューションは更に良くなるのではないかと考えています。フィードバックは@Platform9Sysへのツイートか、お問い合わせページまで。(訳注:日本語でのご意見は↓のTwitterでも受け付けております。)

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

2016/07/07

Container-as-a-Service Platform9 Managed Kubernetes for Docker

本記事の原文の公開は2016年の6月20日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。Platform9関連記事はOpenStack Days Tokyoの終了まで3日間連続で公開予定です。一昨日はKVM昨日はvSphere、本日はKubernetesについての翻訳記事を公開していきます。

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

我々がDocker、コンテナー、Kubernetesについて熱狂しているのには2つの理由があります。

完全にマルチクラウドの展開を実現する

過去10年間、(仮想化インフラストラクチャをりようして)完全にマルチクラウドでアプリケーション開発環境を作成することは非常に難しいものでした。これは仮想マシンやゲストOSが本質的にはポータブルとは呼べなかったからに他なりません。例を挙げると、VMware vSphere上の仮想マシンとしてもしくは、Linux/KVM上の仮想マシンとして作成、展開することは非常に簡単です。しかし、一つの仮想化環境から別の環境へとワークロードをシームレスに動かそうとすると? 不可能です。簡単な一回こっきりのプラットフォーム間のインポート作業や、プライベートクラウドからパブリッククラウドへの移行、その反対でさえ、難しいという状態です。

コンテナーは一方、仮想マシン上でも動作します。ベアメタルと同じようにシームレスです。そして、さらに、コンテナーはJVMのようなポータビリティを発揮し、後ろのインフラストラクチャを完全に抽象化する力を持っています。

コンテナーが人気を集めるにつれ、多くのパブリッククラウドプロバイダーは様々なContainer-as-a-Service(CaaS)をそれぞれで提供し始めています。プロバイダーが提供するクラウドプラットフォーム上で、コンテナ化されたアプリケーションをユーザーが利用できるようにするためです。

でも、ポータビリティとは何でしょうか? 本当のコンテナーを利用することのポータビリティのメリットは個々のクラウドプロバイダーがサポートするコンテナーオーケストレーションのフレームワークにロックインされることなく利用ができることです。そうでなければ、クラウドプロバイダーがサポートするフレームワークに縛られてしまうのです。

完全なContainer-as-a-serviceのモデルは、根本的にはマルチクラウド上に展開されるマルチーコンテナーアプリケーションを実現するということになります。そして、エンタープライズのお客さまにとっては、これはプライベートのインフラストラクチャでコンテナをオンプレミスで実行するということで、仮想化状ではなく、ベアメタルで動作させるということを意味します。

Kubernetesによって、このプライベートとパブリック、ベアメタルから仮想化、VMwareからKVMまでの完全な抽象化が実現されます。

優れたクラウドネイティブアプリケーションを簡単に作成できるようにする

我々のエンタープライズの顧客と密に動きながら、我々は彼らがOpenStackを近年のクラウドネイティブアプリケーションを作るための方法の一部として利用しようとしていることに気が付きました。Kubernetesは近年のクラウドネイティブアプリケーションの作成と動作を簡単に(ある意味では、シンプルに)してくれます。Kubernetesはそれ自身でディスカバリやロードバランス、アプリケーションのライフサイクル管理などの機能をネイティブでサポートしているからです。

Platform9 Managed Kubernetes(ベータ)発表

こうした可能性の全てを解決するため、我々はPlatform9 Managed Kubernetesをベータ版として発表致しました。マルチクラウドのビジョンを実現するSaaSで管理されたKubernetes実装です。「Managed」とある通り、Platform9が根本的な部分でKubernetesの展開、構成、そして同左開始後は監視、トラブルシュート、アップグレードなど全てを実施します。ですから、ソフトウェアの開発者はKubernetes APIを利用して、クラウドネイティブアプリケーションの開発にフォーカスすることが出来るのです。DevOps(運用のための開発者)は組織にマルチクラウドの戦略をもたらすことにフォーカスする事ができるようになります。それに加え、企業としては企業が利用するために必要な機能、例えば、ご自身の永続ストレージや、ネットワークテクノロジーとの統合、RBAC(役割ベースのアクセスコントロール)、SSO(シングルサインオン)統合、マルチテナントと隔離などを利用することも出来ます。

また、ついに、Platform9を利用して、仮想マシンの横にコンテナを配置し、全て一貫したユーザーインターフェイスとAPIで統合管理できるようになります。言葉を変えると以下の図のように、仮想マシンをOpenStackを使ってオーケストレーションし、コンテナはKubernetesを利用してオーケストレーション出来るようになったのです。両方がです!

Fig001

この先進的なビジョンと素晴らしいクラウド利用体験を我々のエンタープライズのお客様にお届けできることをこれまでに無く誇らしく思います。是非ベータにお申し込みください!(日本のお客様向けにはこちらのフォームで受け付けております。)

現在どのようにコンテナを利用していますか? 仮想マシンとコンテナをどのようにクラウドネイティブアプリケーションを展開していますか? 是非 @Platform9Sys 又は @madhuramaskasky までお知らせください! (訳注:日本語でのご意見は↓のTwitterでも受け付けております。)

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

2016/07/06

vSphere with OpenStack : 更に良い方法は?

本記事の原文の公開は2015年の7月28日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。Platform9関連記事はOpenStack Days Tokyoの終了まで3日間連続で公開予定です。昨日はKVM、本日はvSphere、明後日はKubernetesについての翻訳記事を公開していきます。

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

VMware vSphere と OpenStack はそれぞれのフィールドー仮想化とプライベートクラウドーではまばゆく輝く星です。理論上の話をすれば、この2つのテクノロジーが融合することになれば成功は一瞬で手に入ることになるでしょう。しかし、現実はそう上手くは行きません。殆どの今日のOpenStack の実装はカーネルベースの仮想マシン(KVM)をハイパーバイザーとして利用しています。vSphere と OpenStack の両方をお持ちの組織はこれらを別々のサイロとして動作させる傾向にあり、結果としてそれぞれに固有の管理プロセスが必要になっています。

Platform9のエンジニアリングチームの大部分はVMwareで働いた経験を持ったメンバーです。ですから、我々はVMware社自身の仮想化と管理のプラットフォームがこの10年間で成長し、業界標準へと至るまでを見てくる機会に恵まれました。その流れの中で、我々はvSphereとOpenStackがもしも、適切にエンジニアリングされれば、協調して上手く動くということを確信しています。Platform9では、理想的なvSphereとOpenStackの統合の話が、どういうものなのかということを活発に議論しあっています。

プライベートクラウドの我々のビジョン

Platform9のプライベートクラウドのマニフェストはとても直接的です・・・我々はプライベートクラウドの展開をこれ以上ないほどまでに簡単にしたいのです。1月のTech Field Dayに遡ると、我々は理想的なプライベートクラウドがどういうものなのかという、我々のビジョンの背景をご説明しました。我々にとって、理想的なプライベートクラウドに必要な要素は以下の3つです。

  1. 100%自動化された展開ができること
  2. すでにお持ちのインフラストラクチャと統合出来る
  3. 情報システム部のポリシーを満たしつつも、承認されたユーザーは簡単に利用ができる

さぁ、これらについてもう少し掘り下げて見ましょう :

  • 100%自動化された展開ができること ー これはエンドユーザーがIT運用者の手動の承認を減ることなく、セルフサービスでクラウドのリソースへアクセス出来、GUIから、CLIから、APIからでも全体に渡る自動化のためのアクセスが出来るということを意味します。
  • すでにお持ちのインフラストラクチャと統合できる ー 今日、全世界の70%のコンピューティングキャパシティはプライベートなデータセンタに置かれています。プライベートクラウドは既存のインフラストラクチャも差別なく活用できるべきなのです。
  • ITのポリシーを満たしつつも、承認されたユーザーは簡単に利用ができる ー 上記のようなことから、プライベートクラウドは情報システム部門が管理が管理しているハードウェア上で実現されることになります。効率的なプライベートクラウドをつくり上げるためには、適切なポリシーの設定、リソースプールの設定、リソースのひも付け、クオータなどが必要になります。これらによって、情報システム部はエンドユーザーに対して、セルフサービスを快適に開放することができるようになるのです。

何故VMware vSphereをサポートするのか?

VMware vSphereは単に動くだけの仮想化プラットフォームを利用してみたり、検証してみたりすれば分かりますが、やはりゴールデンスタンダートです。世界中のエンタープライズデータセンターの大部分は今日vSphereを利用しています。多くの情報システム部門が選ぶ安定性やリソースのクラスタ化、DRS、vMotionなど本可動での利用を想定した機能の成熟度においては堅牢なハイパーバイザーです。

多くの組織では今日、VMware vSphereを利用していますが、vCenterを通じて利用されています。これは手動でリソースを管理しているということに他なりません。これは、プロセスドリブンのモデル、つまり仮想マシンは仮想化管理者が開発者からリクエストチケットを受け取って、それぞれのリクエストに手動で答えていくという結果に終わります。vSphereの上にOpenStackを配置することで、それぞれの世界の最高の結果を得ることが出来るはずです。 ーAmazon AWSのように俊敏で、セルフサービスが利用できるプライベートクラウドを、今日のデータセンタの大部分のワークロードにとって最適で、本稼働に耐えうる世界最高峰のハイパーバイザーを利用して作ることが出来るのです。

VMware vSphere with OpenStackの前に立ちふさがる困難

わかった。じゃ、vSphere + OpenStackは素晴らしいアイディアだ。OpenStackはすでにvSphereをサポートしているし、そのためのドライバーも提供されている。なぜそれ以上の議論が必要になるんだい?

残念なことに、現在のOpenStackのvSphereドライバーの機能は限定的で、最小限とも呼べるレベルです。多くのハードコードされた前提条件と制限がエンタープライズのユーザーがvSphereとOpenStackをシームレスに統合することを非常に困難にしています。いくつかあるうちの制限事項はOpenStackのコアデザインと結びついているもので、残りのものはvSphere OpenStackのドライバーの作り方に起因しています。

例として挙げると、vSphereをサポートする全てのOpenStack(VMware Integrated OpenStackまたはVIOも対象です)はプライベートクラウドを1から展開するものだという想定に基づいています。これが根本的に利用開始時の問題になるのです。今日vSphereを利用し、大規模なプールで既存のワークロードを動作させているような組織の殆どは、1からOpenStack + VMwareの環境を作る際に、特別な処置を講じなくてはなりません。

今後、様々な記事の中で補足していきますが、まずはvSphereとOpenStackをどのように統合していくのが良いのか、お話していきましょう。もちろん、以下だけに限った話ではありません:

  • ワークロードのディスカバリ : 優れたvSphereとOpenStackの統合では、既存のインフラストラクチャを変更することなく、その上で動作すべきです。ユーザーに更に新しいサイロを作成させるものであってはなりません。
  • 新しいワークロード : ユーザークオータ、ロール(役割)、などを確認した上で、新しいワークロードを作ることが出来ること
  • テンプレートのサポート : vSphereテンプレートはOpenStackでまず動作させなければいけないものです。テンプレートを利用して迅速に仮想マシンを展開させます。
  • ソフトウェア-ディファインド ネットワーク(SDN) : vSphereのユーザーは既存の仮想スイッチ(または分散仮想スイッチ)ベースのネットワークを利用でき、さらに、その上でNeutronベースのソフトウェア-ディファインドネットワーク(SDN)を動作させます
  • 複数のクラスタと複数のvCenter : 複数のクラスタをコンピュートリソースとして利用できるようにします

Platform9は、プライベートクラウドの展開と管理をエンドユーザーにとって下げられるだけ下げることが出来る可能性があると信じています。そして、仮想化インフラストラクチャからプライベートクラウドへの適切な移行も同じようにシンプルにするため、我々はこのvSphereというハイパーバイザーをOpenStackのファーストクラスのハイパーバイザーにすれば展開や管理が簡単になると考えています。

将来投稿する記事で、どのように統合していくべきなのか、我々がPlatform9でそのビジョンをどのように実現しようとしているのか、もっと詳細についてお話したいと思います。さらに、我々はOpenStackサミットにおいて、既存のKVMとvSphere環境の仮想化ワークロードを動的にディスカバリする事を可能にするための新機能を提案する会話の場を設けました。我々は過去に経験した既存の開発/検証のワークロードとインフラストラクチャをvSphereで動作しているOpenStackベースのプライベートクラウドに載せ替えた経験を例として用いています。このユースケースはこの記事の中で述べられている機能の大本となっており、我々はこのコードでOpenStackのプロジェクトへ貢献したいと考えているのです。この議論に参加したい場合には是非ご参加(訳注:すでにOpenStackサミットが終了しておりますので、現在は議論はされていません)ください。

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

2016/07/05

夢の実現 : KVMヴァージョンのリリース

本記事の原文の公開は2015年の1月20日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。Platform9関連記事はOpenStack Days Tokyoの終了まで3日間連続で公開予定です。本日はKVM、明日はvSphere、明後日はKubernetesについての翻訳記事を公開していきます。

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

15ヶ月前、我々は夢とともに、Platform9を創業しました。その夢とはプライベートクラウドはあらゆる組織にとって、もっと、シンプルで、簡単、そして安価なものになるだろうというものです。データセンタのカスタマイズ性、統制、機能が失われてしまってはなりません。コンピューティング環境からこれらのいずれかがかけてしまうと、成功するのは非常に困難を伴うことになります。

我々の創業はあらゆる種の疑いとともに、動き始めました。「データセンタインフラストラクチャを管理するクラウドサービス?」。「OpenStackはいつまでたっても動かない」。「プライベートクラウドなんて、ただ辛いだけ」。「仮想化プラットフォームをまたいだ一元管理:不可能だ」。「もしこれが実現出来たとしたら、もう実現されているはずだ」。

ですが、それを信じる人々がいたのです。我々の初期のお客様は我々からワイヤフレーム(訳注:概念や未完成の状態の製品)以外には受け取れる物がありませんでしたが、今では我々のもとに集い、これを実現しようとしています。RedpointのSatish氏、Scott氏としてチームは我々がまだ、刀の柄しか持っていない頃から支援してくださっています。そして、もっとも重要な点は、こうしたミッションに挑む素晴らしいチームが「よし、やってみるか!」と言ってくださったことです。

今日、我々がPlatform9 Managed OpenStack for KVM環境を正式にリリースできることを喜ばしく思います:

Platform9 Managed OpenStack

フリー(もしくはそれ以外の)Linuxディストリビューションが動作する安価なコモディティのインフラストラクチャだけで、本番環境で利用が可能で、AWS-ライクな、OpenStackベースのプライベートクラウドを数分で利用可能になったのです。価格もケーキの上の粉砂糖のようなものですし、特に、管理ソフトウェアのベビーシッターをもう卒業して、運用コストを下げたいと考える方には特に素晴らしい甘さでしょう。

我々はすでにVMware vSphere向けのベータ版もアナウンスしていますし、将来的にはDockerのサポートについても必ずやり遂げるつもりです。(訳注:翻訳公開2016年7月5日当初では、vSphere向けPlatform9 Managed OpenStackはすでに正式版、ここでDockerのサポートとして上げられているPlatform9 Managed Kubernetesもベータ版が公開されています。お問い合わせはこちらまで。)

何よりもいいことには : 我々はまだ夢を見ることをやめていません。まだまだ始まったばかりなのです。

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

2016/07/04

ネットワールド、OpenStackはじめました。 プライベートクラウドの再創造

皆さん、こんにちは。

本日プレスリリース致しましたが、ネットワールドはPlatform9 Systems, Inc.とディストリビューター契約を行い、グローバルで初のディストリビューターとして国内でPlatform9 Managed OpenStackを提供開始致します。製品詳細ページはこちら

7月6日から開始される「OpenStack Days Tokyo 2016」にも出展し、7月7日にはミニセッションでもプレゼンテーション致します。

これまでとは全く違うアプローチでのOpenStack、是非、聞いて、見て、触りに来てください。

他の製品に負けないように、このブログでもいろいろとご紹介していきたいと思います。

まずは、第一弾の翻訳記事はPlatform9社のブログの1号の記事です。原文はこちら

プライベートクラウドの再創造

ハローワールド! Platform9へようこそ。我々はプライベートクラウド像を再創造しています。

遺伝子

Platform9の遺伝子は我々の創業チームがVMwareの初期のエンジニアだったころの経験に遡ります。VMwareはコンピューティングインフラストラクチャを素晴らしいテクノロジーによってまさに変革した母校と呼べるでしょう。

月日を重ねるにつれ、仮想化インフラストラクチャを管理するのは難しく、それ相応の時間をかけなければならないことだと実感するようになりました。管理者は複雑な管理ソフトウェアのインスタンスをセットアップするだけでなく、しっかりと構成しなくてはなりません。また、重大な修正や新しい機能を利用するために、都度、アップグレードもしていかなくてはなりません。更に、それに加えて、管理者は雪だるま式に膨れ上がるインフラストラクチャの監視も行わなくてはならないのです。

もっといい方法があるはず!

ですから、我々はこれまでのアプローチを考えなおす、つまりお客様の利用体験をより良くしていくという事以外において、制限があるべきではないということに挑戦しました。

結果、Platform9が生まれます。エンタープライズのコンピューティングインフラストラクチャを管理するためのクラウドサービスが生まれました。

今日(原文は2014年の12月12日の投稿です)でPlatform9は創業からほぼ9ヶ月です。β版をリリースして、コミュニティーで利用者を募集できることを誇らしく思います。(※訳注 : 現在はベータではなく、フリートライアルを利用することが可能です。こちらからお申し込みください。)

ご自身の仮想化インフラストラクチャを5分以内に管理し始めることが出来ることを、ご自身で確かめてみてください。ユーザーエクスペリエンスはケーキのよう(に素晴らしい味)ですし、それにまぶしてある粉砂糖は最高のOpenStackの味がするはずです!

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