« 2016年6月 | メイン | 2016年8月 »

2016年7月

2016/07/29

【CommVault】次期バージョン v11の国内提供が始まりました!

こんにちは。

今回は、CommVault 最新バージョン V11 の国内提供が開始されましたので、ご紹介します。

最新バージョン V11 のリリース以降、製品名が CommVault Simpana から会社名と同じ "CommVault" に変わりました。Simpana (シンパナ) という製品の名称に慣れていましたので、CommVault社の CommVault と呼ぶにはまだ時間がかかりそうです(苦笑)。

 

2014年 4月 1日の初回のブログでもご紹介しましたが、今年のガートナー社「データセンター バックアップ/リカバリ ソフトウェア」のマジック・クアドラントで、バックアップ/リカバリ分野で6年連続「リーダー」に選ばれており、ワールドワイドで変わらず高く評価されています。

 

Commvault、ガートナー社「データセンター バックアップ/リカバリ ソフトウェア」のマジック・クアドラントで、「ビジョンの完全性」と「実行能力」においてリーダーとして最高評価の位置付け

※「データセンター バックアップ/リカバリ ソフトウェアのマジック・クアドラント」の完全版および詳細は、こちら (英文) をご覧ください。

 

V11 の新機能、V10 からの強化機能など、今後のブログで順次ご紹介していきたいと思いますが、V11では、インストーラー(CommServe インストール手順例:CS_Installtion.pdfをダウンロード )が変更されました。基本的なインスール手順は変わりませんが、インストール先のデフォルトのパスなど変更がありますので、V11 の製品評価の際にご確認ください。

 

CommVault V11 - 新機能
http://documentation.commvault.com/commvault/v11/article?p=new_features/new_features1.htm

 

また、これまでご紹介しておりませんでしたが、"Early Release Features" という将来のバージョンで搭載予定の機能が試験的に搭載され提供されています。V11 の Early Release Features の機能一覧は、こちらのサイトでご覧いただけますが、CommVault 社に Early Release Features の機能の利用を事前に申請して承認を取れば、正式リリース前でもサポートを受けることができます。

 

V10 の Early Release Features (機能一覧はこちら) の中で "Live Sync Replicaiton of Virtual Machines (VMware) (以下、Live Sync)"という災害対策用の機能が正式にサポートされました。

 

Live Sync は、仮想マシン(Source VM) のバックアップから同期先の仮想マシン(Destination VM) に対して、変更ブロック(増分)のデータ転送を可能にします。また、Live Sync は、ベストプラクティスとして、DASH Copy のブロックベースのバックアップ機能と併用する構成になりますが、同期先の仮想マシンに対して最後の同期点以降のソースからの変更ブロックのバックアップを適用します。

 

[Live Sync 機能の利点]

  • 本番環境の仮想マシンへの負荷が最小限(バックアップデータから仮想マシンを複製)
  • リモートサイトへのデータ転送は、重複排除と圧縮機能により最小限
  • ハードウェアに依存しない(災対環境での元のハードウェア環境と同一構成は不要)
  • リストア操作が不要(基本、災対環境上の仮想マシンのパワーオンのみ)
    ※災対環境での新たなネットワーク設定(IPアドレス)を事前に設定しておく機能(設定画面:LiveSync_Settings1.JPGをダウンロード)が提供されています。

  

続きを読む »

2016/07/25

PernixCloud データ : FVPのレイテンシとSANのレイテンシの比較

本ブログエントリーはPernixData社のテクノロジーエバンジェリストだったFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はPernixCloud Data: FVP Latency Compared To SAN Latencyで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

地球全体の仮想化データセンタをポータル化ESXiホストのCPUとメモリの構成についての考察そして、仮想マシンの密度(統合率)についての考察などの記事の中で、我々のPernixCloudの中のデータについて述べてきました。我々は世界中の仮想化データセンタのデータを多く集めることで、様々なアーキテクチャ、会社、運用を理解しようとしています。ですが、もちろん、我々は我々の製品のパフォーマンスについて理解するためにもこのデータを利用します。今回キーとなるメトリックは我々のFVPがどれだけワークロードのレイテンシを改善したか、という点です。Satyam氏Woon Jung氏とSriram Sankaran氏にデータセットへとダイブし、どれだけのレイテンシが改善されたのかを明らかにするように命じました。以下はデータ取得時のSatyamによるコメントです:

データセット

Satyam :我々は日々91000ぐらいの仮想マシンを観察しています。仮想マシンのIOの特性は時刻や曜日によって変わり続けます。ドーナツチャートのそれぞれのセグメントごとの色はx-y%のレイテンシの改善がSANのレイテンシに対して見られた仮想マシンの割合を表しています。例えば、ドーナツチャートの左上の内側の(濃い)ブルーのセグメントはWrite-Thoroughに設定した仮想マシンの全体うち5%は0~19%のレイテンシの改善がFVPによって見られたということです。

以下の記事を読んで、FVPとWriteポリシーについて理解しておいてください:

我々は1382の仮想マシンの数年分のデータについて収集しました。データの表示は標準的に、一時間あたりでどれだけか、という値にしてあります。これはEC-2などのクラウドと比較しやすいようにするためです。

VMFS上のWrite Throughの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig421

NFS上のWrite Throughの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig422

VMFS上のWrite Backの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig423

NFS上のWrite Backの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig424

Satyam : さぁ、準備はいいかい? いっぱいあるけど、以下の様なところが見どころさ、それ以外は読者の楽しみとして取っておきます。

  • VMFS上の仮想マシンでWrite Throughに設定されている場合、35%もの場合で、100%以上のレイテンシの改善が見られています。つまり、SANのレイテンシよりも仮想マシンから見たレイテンシが半分以下になっているということです。
  • Write Throughに設定されている仮想マシンでも、ストレージに対する負荷が下がることで実際にはWriteのパフォーマンスを向上させることができています。14%ものWrite Throughの仮想マシンが80%~90%の割合でWriteのレイテンシの改善をしています。これはとーーーーっても大きい!!
  • NFSのチャートの右上、NFSの仮想マシンはより大きなレイテンシの改善がなされています。これはNFSはダメだからです(パフォーマンスの観点からはね・・・。)
  • Write Backに目を移しましょう。VMFSで動作している仮想マシンの半分はWriteBackで100%以上のレイテンシを改善しています。Write Backはすごいね!
  • 一般的にはほとんどの仮想マシンが50%以上のレイテンシの改善しています。Readでも、Writeでも、Write ThroughでもWrite Backでも、VMFSでもNFSでも。なんという強者っぷり!

実際のデータは見ていただいたとおりです、注目したいのはWrite ThroughでのSANのWriteレイテンシの改善です。これは実際の話しですし、オールフラッシュストレージの上でFVPでRAMによる高速化(DFTM)を実施したことを考えてみてください。最近、Ramboll社 ーグローバルで展開するエンジニアリング会社ー が何故Pureのオールフラッシュストレージの上で、DFTMを利用するFVPを導入したのかという理由を答えてくれています。レコーディングは以下から聞くことが出来ます。Maximize Your All Flash Array Investment With Analytics(訳注:英語ビデオ)

Chethan Kumar氏、我々のパフォーマンスエンジニアもSANのレイテンシがFVPを動作させる前よりも下がったということを述べています。帯域が削減されることにより、ストレージエリアネットワークとストレージコントローラーに対する負荷が下がるからです。もし90,000もの仮想マシンからのIOが発行されたとすると、レイテンシはもっと高いものになっているはずです。そうした意味では、このドーナツチャートで見るよりも実際の結果はもっと優れたものになるはずです。本当のドーナツでは殆どが紫になってしまい、上の方にちょこっと色が出てくるような状態のはずです。

Write Throughで削減される仮想マシンからの帯域の総量を甘く見てはいけません。今週私は32のデータベースを動作させている仮想マシンを高速化されているお客様をご訪問いたしましたが、1日辺りで145TBもの帯域が削減されていました。ストレージエリアネットワークでの帯域はストレージ装置自身のキャッシュにも影響をあたえるのです。

Fig425

我々がFVPによるメリットにどれだけの確信を持っているかを示すために、我々は「Fastest SAN alive(最速のSANの誕生)」キャンペーンを実施しています。最大で10倍の高速な仮想マシンのパフォーマンスをFVPが実現するということを是非チャレンジしてみてください。詳細はこちらです。

Fig426

訳注 : 残念ながら上記のキャンペーンは国内では展開されておりませんが、FVPのパフォーマンス改善とその効果に絶対の自信があるということは上記の統計からの実際のお客様の例からも明らかです。是非無料トライアルをお試しください!

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)

2016/07/22

[最新鋭、IBM FlashSystem A9000 をこっそりレポート]

最近発表されたIBMの最新鋭の超高速フラッシュストレージ FlashSystem A9000をお借りしちゃいましたっ。

FlashSystem A9000 ってなあにっ??


写真:緊張をしながらA9000に灯を入れたところをパシャ!

_20160617_131927

究極の低遅延を誇る 超高速ストレージ
IBM FlashSystem 900 は爆速街道まっしぐらっ!

A9000は、その超高速ストレージに「IBM XIV」で高い実績の 「IBM Spectrum Accelerate」 を組み合わせた
一言で言うと超高速ミニXIVだっ♪

もちろんリアルタイム圧縮、そしてインライン処理での重複排除機能も標準搭載され、アクセスタイム250usという驚異的な応答速度に、最大500,000IOPSを叩き出し、同時に99.999%を超える可用性をも実現しているっ!
リアル何でもアリなのであるっ。

で、更に
QoS+マルチテナンシー というクラウド環境を意識した機能を併せ持つまさに理想のストレージっ。

ちなみに最大2,000,000IOPSに達するモンスターマシンA9000R にいたっては
複数のフラッシュエンクロージャーによるスケールアップにも対応しているよっ。

 

FlashSystem A9000 中身を覗いてみよう♪


FlashSystem A9000はマイクロレイテンシーフラッシュモジュールを12個搭載したフラッシュエンクロージャー1台にIBM Spectrum Accelerateが実装されたグリッドコントローラー3台で構成され
各筐体同士が超広帯域なInfiniband (FDR/56Gbps)で接続されいるんですっ。凄いでしょ♪
裏にまわって、実際の結線をたぐっていったら、下の図のようになっていました!!。

Infiniband_4

次回は「グリッドコントローラーってなに??」の謎に迫ってみまっしょうっ。

by:まいけル

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/18

PDキッド エピソード3 : PDキッドがデータベースのパフォーマンスに挑む

さて、アメコミファンの皆様、そしてストレージのファンの皆様、前回からわずか一週間。PDキッドの第3話の登場です!

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

個性的な登場人物の詳しいプロフィールはこちら。みんな相当ヤバイ奴らですが、なんと今回はPDキッド以外は出てきません!(笑) なぜなら、今回の問題はストレージの問題では無いからです。 ストレージの世界から飛び出したPDキッドの行方は果たして!?

Fig418

続きを読むをクリックして進んでください!

続きを読む »

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/11

PDキッド エピソード2 : PDキッドがキャパシティの難題に挑む

さて、アメコミファンの皆様、そしてストレージのファンの皆様、前回からわずか一週間。PDキッドの第2話の登場です!

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

個性的な登場人物の詳しいプロフィールはこちら。みんな相当ヤバイ奴らです! PDキッドの行方は果たして!?

Fig415

続きを読むをクリックして進んでください!

続きを読む »

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)