OpenStack Feed

2016/11/29

Nutanix 5.0の機能概要(Beyond Marketing) パート1

本記事の原文はNutanix社のPartner Innovation and Vertical Alliances, Sr. Directorを務めるAndre Leibovici氏によるものです。原文を参照したい方はNutanix 5.0 Features Overview (Beyond Marketing) – Part 1をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

また、以下のセミナーでも本記事の内容を詳しくご説明しますので、是非ご来場ください!

Nutanix/VMware 2大メーカー ヨーロッパイベントからの最前線
ウィーンで開催された「Nutanix .NEXT Conference EUROPE」とバルセロナで開催された「VMworld EMEA」からの情報 2本立て

AOS 4.7のリリースから5ヶ月が立ち、Nutanixは多くの新機能と改善点を備えたメジャーリリースヴァージョンをアナウンスしようとしています。AOS 5.0は社内ではエンジニアリングコードネーム「Asterix」と呼ばれていたものです。Nutanixによるその機能や改善のリリースのスピードはAWSやコンシューマー業界としか比べることが出来ないほどで、その素晴らしい更新のペースがユーザーを感動させています。このブログの記事ではもうしばらくでリリースされるNutanixのソフトウェアについてご紹介していきます。もしも以前のリリースについてのアナウンスを見たいのであれば以下を読んで下さい。

※訳注 4.7以外の記事についての和訳予定はありません。

本記事は本シリーズの1番目の記事です。2つ目3つ目4つ目

本記事では以下の機能についてご紹介していきます:

  • Cisco UCS B-シリーズ ブレード サーバ サポート
  • Acropolis アフィニティ と アンチ-アフィニティ
  • Acropolis ダイナミックスケジューリング (DRS++)
  • REST API 2.0 と 3.0
  • XenServerのサポート TechPreview
  • ネットワーク可視化
  • 新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)
  • ネイティブのセルフサービスポータル
  • スナップショット - セルフサービスリストアのUI
  • ネットワークパートナーインテグレーションフレームワーク
  • メトロアベイラビリティウィットネス
  • VMフラッシュモードの改善
  • Acropolis ファイルサービス 正式リリース (ESXi と AHV)
  • Acropolis ブロックサービス (CHAP認証)
  • AHVのOracle VM と Oracle Linuxへの認定
  • AHVのSAP Netweaver Stackへの認定
  • ・・・さらにパート2で

今後の数週間でプロダクトマネージャやプロダクトマーケティングマネージャチームが数々のブログ記事を書き上げ、もっと詳細なAOS 5.0の情報が出てきます。その一つ目がShubhika TanejaによるTen Things you need to know about Nutanix Acropolis File Servicesです。

免責事項 : あらゆる将来の製品又はロードマップ情報は製品の方向性を示すことを意図しており、Nutanixが提供するあらゆる情報、コード、機能に対してコミット、お約束、法的な義務が生じるものではありません。この情報を用いて、購入を決めるべきではありません。また、Nutanixは将来の製品改善、機能が最終的に利用できるようになった際に追加での課金を行うことや、最終的に改善された製品や機能のために別途の課金を行うことを現時点では決定していません。

機能や時間軸についてのオフィシャルな情報についてはNutanixのオフィシャルなプレスリリースをご参照ください。(こちら)

さて、法的な免責事項に目を通したら、さぁ、初めましょう!

プラットフォーム

Cisco UCS B-シリーズ ブレード サーバ サポート

本日、 .NEXT EMEAの中でNutanixは今後のCisco UCS B-シリーズ ブレード サーバのサポートについてアナウンス致しました、以前にアナウンスしたC-シリーズのラックマウントサーバのサポートに加えてのサポートです。

Fig092

現在、UCS B200-M4ブレードは物理容量3.2TBのオールフラッシュストレージに限定されています。フラッシュの制限によってストレージ容量の要件に見合わないという事が多くの場合でいえます。Ciscoや他のハイパーコンバージド製造メーカーは結果としてそのソリューションをラックマウントサーバに限定してきました。

NutanixはB-シリーズブレードのストレージ容量の不足の問題をストレージ専用ノードをB-シリーズのブレードのクラスタに追加することで解決させました。リリース後はオールフラッシュのC240-M4SXのストレージ専用ノードをクラスタに追加することが出来、最大でノードあたり24本まで1.6TBのSSDを追加することが出来ます。Nutanix固有のコンピューティングとストレージを異なった割合で自由自在に組み合わせられるという能力がこれを実現しました。

ストレージ専用ノードはUCSのお客様のブレードとC240間でのバランスのチューニングも実現することになります。更にはコンピューティングとは独立したストレージの拡張も実現します。古い筐体が容量が一杯になる度に新しいストレージ装置に巨大な投資を行うのではなく、お客様は必要に応じて順次環境を拡張して行けるようになるのです。

ストレージ専用ノードはNutanix AHVを利用して動作しています、ですから、追加で仮想化ソフトウェアのライセンスのためのお金が必要になるということはありません。AHVのストレージ専用ノードはESXiのノードと同じクラスタ内に混在させることが可能です。

Fig093

AMF(Application Mobility Fabric - アプリケーション モビリティ ファブリック)

Acropolis アフィニティとアンチ-アフィニティ

仮想マシン-ホストの固定アフィニティ

管理者が特定のワークロードが同一ホスト内で動作する事を保証したいという場合。例えば、多くの会社では、アプリケーションを仮想マシン内で動作させていますが、特定のアプリケーションはライセンシングの規約から、特定のホストに紐付いているということが有ります。管理者は仮想マシンに対してホストアフィニティルールを設定し、これらの仮想マシンを特定のホストで動作させ、他のホストへと移行しないようにすることが出来ます。

  • Acropolisは以下のHAやメンテナンスモードの最中の仮想マシンをサポートすることが可能です。
    • 予約モードのHAでは、仮想マシンの再起動のためのリソースが別のアフィニティホスト上に予約されます。Acropolisはこの予約が保証されない場合には仮想マシンの電源が入ることを許可しません。
    • ベストエフォートのHAの場合、Acropolisは別のアフィニティホスト上で再起動が出来ない場合、仮想マシンの電源をオフにします。
    • メンテナンスモードの場合、Acropolisは仮想マシンが別のアフィニティホストへと退避できない場合には仮想マシンの退避を行いません。

仮想マシン-仮想マシン 優先的アンチ-アフィニティ

特定の仮想マシン同士が同じホストで動作するべきではないと言う場合です。例えば、殆どの組織ではドメインコントローラーはいかなる場合においても最低一つは残って稼働し続けて欲しいという要件があります。このために組織はパフォーマンスの観点からは同じホストで仮想マシンが動作するほうが良い結果になる場合であっても、仮想マシン同士にアンチ-アフィニティルールを設定し、仮想マシン同士が別々のホストで稼働するようにというルールを設定します。

  • 結果として
    • 仮想マシンは優先的アンチ-アフィニティポリシーを持つ。
    • スケジューラーによる配置の最中はポリシーに違反することもある。
    • もしDRSが違反を解消できない場合、警告が発報される。

アフィニティの説明はこちらも参照ください。http://www.virtualizationadmin.com/blogs/lowe/news/affinity-and-anti-affinity-explained.html

Acropolis ダイナミック スケジューリング(DRS++)

システム管理者はDRSのコンセプトは既にご理解いただいていると思います。DRSはコンピューティングワークロードを利用可能な仮想化環境内のリソースでバランスします。- 今日DRSはほとんどの仮想化スタックの一部といえるようになっています。

DRSはキャパシティプランニングと密接に関係しています - キャパシティプランニングはより長い時間軸を対象としたものであるという例外はありますが、DRSによる最適化はキャパシティの制約がある環境で、もっと短い間隔で実行されます。

AHVのダイナミックスケジューリングは最初は既存のDRSの実装とさほど大きく変わるものでは無いかもしれませんが、Nutanixは要素としてコンピューティング、メモリ、そしてストレージのパフォーマンスをも配置決定の考慮に加えます。Nutanixの管理者はAHVのDRSがリソース(CPU、メモリ、そしてストレージIO)の競合やその後の一時的なリソースCPU、メモリ、ストレージIOの競合を事前に回避(または、回避のための推奨事項の生成)して、仮想マシンの電源を入れてくれるので「心の平穏」をもって管理に当たることが出来ます。

REST API 2.0 と 3.0

NutanixのREST APIについての大きな変更が今回のヴァージョンに含まれており、これにはAPIのヴァージョン、後方互換性、APIの衛生化、そして標準化が含まれています。さらに、新しいREST 3.0もプラットフォームの一部として含まれています。

REST 3.0はスケールアウトを意図して作られているAPIであり、組み込みのロードバランサのゲートウェイとして動作します。実装の実際のスキーマ(これは変わる可能性があります)詳細を実現するのではなく、REST 3.0は高いレベルでのユーザーの意図する実際のユースケースのコンセプトを規定するものです。

ユーザーの意図をマッピングすることで ー つまりユーザーが実現したいことをマッピングすることで、NutanixはAPIをパラメーターをセットするだけで与えられた操作を実行できるようにする機会を得ることが出来るのです。Nutanixがここで実現したことは大変なNutanixに固有のビジネスロジックをその呼出元から削除し、Nutanix内部(あるべき場所)へ配置したということです。

新しいNutanix APIポータルは既に利用できるようになっており、開発者は古いものや新しいREST 3.0の意図する仕様を直ぐに見ることが可能です。ポータルではPython、Java、Go言語、PowerShellのサンプルが提供されており、http://developer.nutanix.comまたはhttps://nuapi.github.io/docsでアクセスできます。

Fig094

XenServerのサポート TechPreview

Fig095

これはアナウンスの再掲載となりますが、NutanixはXenServer上で動作しているXenApp、XenDesktop、NetScaler VPXそして、NetScalerを含むCitrixのアプリケーションに対するサポートをNutanixプラットフォームに上で提供することになります。AOS 5.0からXenServerのお客様はXenServer 7をテクニカルプレビューとしてNutanixプラットフォーム上で動作させることができるようになるのです。

プレスリリースについてはこちらをご参照ください。

Prism

ネットワーク可視化

もしもネットワークが誤って構成されたら、アプリケーションの仮想マシンは動作を止めるか、パフォーマンスの低下が起こります。例えばVLANが誤って構成された場合、アプリケーションはそれぞれお互いに通信ができなくなります。ネットワーク構成の不整合、例えばMTUの不整合やリンクスピードの不整合などが起こると、大量のパケットのドロップによってパフォーマンスの劣化が起こります。

ネットワークの問題のトラブルシューティングを難しくしているのは単一のネットワークのパス上にあるすべてのスイッチの構成のミスが原因を作り出す可能性があるからで、管理者はトラブルシューティングを行う際にネットワーク全体の構成を見なくてはならなくなるからです。

これがまさにネットワーク可視化が解決しようとしていることです。各々の仮想マシンから仮想スイッチ、物理ホストのネットワークカード、TOR(トップオブラック)スイッチなどに至るまでのネットワーク全体の表示を提供します。VLAN構成などのネットワーク構成の要素情報も直感的で使いやすいインターフェイスに表示します。管理者は例えば、ユーザーやプロジェクトやホストにグルーピングしながらネットワークを簡単に探索できます。

NutanixはLLDPと/もしくはSNMPを利用してネットワークトポロジを検証します。構成情報をスイッチから取得するためにSNMPを利用します。例えば、ネットワーク状態に加え、それぞれのポートのVLAN情報を収集するためにはSNMPを利用します。一旦仮想と物理のネットワーク要素から構成や統計とともにトポロジの情報を収集し終わると、Nutanixは利用しやすいインターフェイス上にその情報を表示します。(最初のリリースではAHVのみで動作します。)

Fig096

Fig097

新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)

Pay as you go(必要なだけ支払う)

  • クラスタ内であとどれだけの仮想マシンが動作するか?
  • もし1ヶ月後に新しくSQLサーバを追加するとしたら、クラスタは大丈夫か?
  • もし、現在のペースでワークロードが増え続けたらクラスタはいつまで大丈夫か?
  • 一定のワークロードがあり、新しくクラスタを作りたいがどのようなクラスタが必要か?

What-if分析は新しく将来に追加されるワークロードをその追加の時期とともに指定するものです。既存の仮想マシンを例えば、既存の仮想マシンと同じインスタンスが10つ追加されたとしたら、という具合に指定することも出来ます。または、既存のワークロードとの差異を%で指定することも可能です。そして、ワークロードの拡張と縮退の両方を指定することが出来ます。そして、ついに、事前定義されたよくあるワークロードをその一つとして指定することが出来るようになりました。

たとえば、ビジネスクリティカルな中規模サイズのOLTPのSQLサーバのワークロードを指定したりすることが出来、what-ifツールはそのワークロードのサイズを見積もることが出来ます。what-if分析ツールは正確なサイジングの見積もりを行うことが出来る理由は、このツールが我々が最初の導入時に推奨構成を割り出すためのNutanixのSizerと統合されているからです。つまり、what-if分析ツールは様々な事前定義されたSQLサーバやVDI、Splunk、XenAppなどのワークロードを利用することができるのです。

Nutanixは既にランウェイ(将来予測)コンポーネント表示を提供していますが、これはキャパシティプランニングのアルゴリズムで異なる様々なリソースのランウェイ(将来予測)を予測し、クラスタ全体のランウェイ(将来予測)を予測しているのです。これを下に、what-if分析は管理者にどうしたノードを追加するべきだという推奨事項を、いつまでに追加するべきだという情報とともに提示することが出来、ランウェイ(将来予測)が本来のランウェイ(あるべき姿)にまで拡張されるようにすることが出来るのです。

一度ワークロードとハードウェアを追加すれば、システムは推奨事項を提示します。what-ifのUIに表示されるものを皮切りに変更やチューニングを行うことも可能です。例えば、様々なハードウェアの推奨構成の追加のタイミングを予算上の制限と調整を行い、ランウェイがどのように変化するのかを見たり、同様にワークロードの追加のタイミングを調整したりすることが出来ます。プライオリティの低いワークロードであれば後からということも有りますよね。あなたにとって最適なワークロードとハードウェアのプランが出来るまで好きなだけチューニングを行うことが出来ます。

Fig098

Fig099

Fig100

Fig101

Fig102

Fig103

Fig104

Fig105

Fig106

Fig107

Fig108

ネイティブのセルフサービスポータル

AOS 4.6ではAHVへのNova、Cinder、Glance、そしてNeutronのドライバーの提供によってOpenStackのサポートが導入されました。OpenStackはマーケットに広く受け入れられつつ有り、Nutanixと完璧に協調動作しますが、OpenStackはネイティブなNutanixソリューションではなく、OpenStackはそれを支えるあらゆるインフラストラクチャとともに動くように作られているため、多くのNutanixの先進的な機能を活用できるようにはなっていません。

NutanixのネイティブなセルフサービスポータルはPrismに統合されており、ITリソースへのアクセス、ポリシー、セキュアなテナントベースのアクセスを実現します。ポータルによってテナントはIT(情報システム部)の介在なくアプリケーションを展開でき、組織は開発者やテナントへAWSのセルフサービスに似たエクスペリエンスを提供することが出来るようになります。

管理者ポータル

  • プロジェクトの作成/管理
  • ユーザーとグループの作成/追加
  • リソースのアサイン
  • アクションのアサイン
  • ショーバックレポートの実行

テナントポータル

  • カタログ(仮想マシンテンプレート、vDisk、Docker Hubのイメージ、アプリケーションテンプレート)からのアプリケーションの展開
  • アプリケーションの監視
  • アプリケーションのリソース利用率の監視

Fig109

スナップショット - セルフサービスリストアのUI

Nutanix AOS 5.0はついに仮想マシンのユーザーがファイルレベルでリストアを行うためのユーザーベースのPrism UIを追加しました。この機能によってユーザーは自身の仮想マシンのファイルやフォルダの復元をセキュアにまた、管理者の手をわずらわせることなく行うことが出来ます。

Fig110

Fig111

Fig112

本日、ウィーンで実施された.NEXTカンファレンスでNutanixはネットワーク接続サービスとネットワークパケット処理サービスを統合、拡張された新しいネットワークのフレームワークについてもアナウンスを行いました。

ネットワーキング、セキュリティパートナーの製品を活用することが出来るサービスの挿入、チェイニングそしてウェブフックの組み合わせによって提供される壮大な可能性を秘めた機能です。

パートナーと共に現在開発中の幾つかのユースケースは:

  • ネットワーク展開のワークフローと対応するNutanix上のワークロード展開のワークフローの自動化
  • パートナースイッチへのオンデマンドでのVLAN展開の自動化
    • アプリケーション(幾つかの仮想マシンの組)がNutanix上で起動する際に、対応する物理ネットワークスイッチが自動的にそのワークロードのための適切なネットワーキングポリシーのもとに構成される
    • Nutanix上からアプリケーションが削除される際に、対応したネットワークポリシーが自動的に物理ネットワークスイッチから削除される
    • Nutanix上の仮想マシンがNutanixクラスタ内の別のホストにライブマイグレーションされる際(同じTORの別のポートや別のスイッチへ接続されている可能性がある)に、対応する以前利用していたスイッチとこれから利用するスイッチの両方に変更を適切にネットワーク構成を行う
  • ネットワークの「仮想マシンからみた表示」をNutanixに収集しパートナースイッチベンダーの情報を元に表示、つまりネットワーク管理者がパートナーのスイッチを管理できるように
  • 「仮想マシン中心」のネットワークの運用表示を提供し、ネットワーク管理者による物理ネットワークのトラブルシューティングをより迅速、より正確なものにする。ネットワーク管理者はパス、フローの追跡、仮想マシン名、タグ、ラベルに対応する統計情報によって根本原因の解析を迅速に行えるようになる。このインテリジェンスはNutanixによって、物理ネットワークデータベースへ仮想マシンの特徴(仮想マシン名と紐付けられたラベル、そして仮想マシンのIPアドレスとMACアドレス情報)として提供されます。
  • LLDPによるトポロジのディスカバリのサポート(Nutanixのノードと対応するTORスイッチノードとのマッピング)

Fig113

単一ネットワークパケット処理(Network Packet Processing - NPP)サービス挿入

NPPはクラスタ全体にサービス挿入し、ネット枠サービスがAHVクラスタ上で動作することを実現するネットワークのフレームワークの一つです。NPPは以下をサポートします:

  • パートナーサービスのイメージとプラグインの登録ワークフロー
  • サービスの展開 - クラスタ全体またはクラスタ内のサブセットに対して
  • ネットワークレベル挿入 - 通信内への割り込みとタップモードでの挿入モード
  • ゲストOSのライフサイクルイベントのプラグイン起動によるパートナーサービスへの通知
  • 対象となる仮想マシンのプロパティの通知 - ネイティブなプロパティ(IPとMACアドレス)とメタデータプロパティ(ラベル、カテゴリ、名前)の両方をサポート
  • サービスへの選択的なトラフィックのリダイレクト(ゲストOSの仮想NICの一部を指定)

パケット処理サービスチェイニングフレームワーク

Nutanixのネットワーキングパートナーは今日ではパケットがAHVネットワークを流れていく際にそれを検査し、変更するか、または廃棄してしまう機能を利用できます。サービスチェインフレームワークはAHVの仮想スイッチを自動構成し、パケットをNutanixパートナーによって提供されてるパケット処理(パケットプロセッサ)仮想マシンイメージやサービスへとリダイレクトするようにします。それによって利用できるサービスは:

  • インライン処理 - プロセッサが仮想スイッチ経由で流れてくるパケットの変更又は廃棄
  • タップ処理 - プロセッサが仮想スイッチ経由で流れてくるパケットを検査する
  • プロセッサチェイン - 複数のプロセッサを利用、同一ベンダまたは複数ベンダで利用できる、別々のサービスを提供するそれぞれをつなげて(チェインして)利用できる

ウェブフックベースのイベント通知(ネットワークオーケストレーション)

Nutanixのネットワーキングパートナーはいつであれウェブフックのイベント経由でクラスタ、ホスト、仮想マシンで発生したイベントの通知を受けとり、すぐに対応することが出来るようになりました。例えば、あるネットワーキングパートナーは仮想マシンネットワークのVLANが変更されたり、仮想マシンがライブマイグレーションして別のホストへ移動した際にパケット検査のポリシールールを適応するようにという警告を上げたいとします。ウェブフックを利用することでパートナーは非常に先進的な問題解決方法を実装し、そのワークフローによって全データセンタを自動化することが出来るようになります。

Fig114

既に統合の終わっているパートナーのデモを幾つか御覧ください。

Brocade

Mellanox

分散ストレージファブリック(Distributed Storage Fabric - DSF)

メトロアベイラビリティウィットネス

Nutanixのメトロアベイラビリティはデータセンタ全体に及ぶ復旧に対してもシングルクリックで優れた仕事をしてくれます。しかしながら、いくらかのお客様はサイト障害なのか、もしくはネットワーク接続障害なのかが明言できない問題であるため、自動的な復旧についての機能を欠いていると感じておられました。ビジネスクリティカルアプリケーションを利用しており、DR手順を実行できるITスタッフがいない場合にはことさらです。

以前はNutanixは自動復旧の機能を備えていませんでした。これはサイトの障害とネットワークのそれの区別を行うことができなかったからです。AOS5.0はこの問題をウィットネス(証言者)仮想マシンを障害ドメインの外側に置くことで解決しました。このウィットネス仮想マシンはそれぞれのメトロサイトとメトロサイトの内部通信とは異なる通信を行い、メトロアベイラビリティにおける復旧の決断の自動化に役立てます。ウィットネス仮想マシンはメトロクラスタ間で自動的にリーダー選出を行うことで、スプリットブレーンシナリオの回避にも役立ちます。

Fig115

VMフラッシュモードの改善

VMフラッシュモードはPrism UIに戻って、更に改善されました! 仮想マシンフラッシュモードは管理者がハイブリッドシステムにおいて、レイテンシが重要となるミッションクリティカルなアプリケーションが動作している特定の仮想マシンをSSD層に置くことを実現します。改善点はハイブリッドシステムにおいて、重要な仮想マシンにオールフラッシュの一貫したレイテンシとIOPS、サービスプロバイダのためのQoSによる階層化やより高いIOPSを提供することです。以前VMフラッシュモードについて記事を書いていますので、興味があれば詳細はそちらへ。

Fig116

Acropolis ファイルサービス(AFS)

Acropolis ファイルサービスがいよいよ正式リリース (ESXi と AHV)

Acroplis ファイルサービス(またの名をAFS)はDSFにネイティブに統合されたコンポーネントであり、Windows ファイルサーバや外部のNetAppやEMC IsilonなどのNASストレージ装置を不要にするものです。AFSはAOS 4.6、4.7ではTech Preview扱いでしたが、AOS 5.0ではいよいよESXiとAHVハイパーバイザ上で正式リリースとなり、Nutanixのサポート対象として本稼働環境で利用できるようになります。

Acropolis ファイルサービス (非同期-DR)

AFSはNOSの非同期-DR由来のネイティブのデータ保護を提供します。仮想マシンとヴォリュームグループは保護ドメインを利用して保護され、他のすべてのDR関連の操作と同様にスナップショットのスケジュールやポリシーを保護ドメイン自身に適応することが可能です。

Acropolis ファイルサービス (AFSクオータ)

AFSはハード、およびソフトのクオータ制限が利用でき、メールによる警告の設定もできるようになりました。ハード制限を利用している場合、クオータを超えることは出来ず、もしもクオータ制限を超えるようなファイルの書き込みが発行された場合、その書き込みは失敗に終わります。ソフトクオータ制限を利用している場合、警告が利用者に送信されますが、データの書き込みは許可されます。

クオータのポリシーはクオータがユーザーか又はグループに対するものか、クオータの制限(GBでのサイズ指定)、クオータのタイプ(ハード または ソフト)、そしてクオータイベントをユーザーに通知するかどうかというルールの組み合わせて指定します。ポリシーの適応は1人のユーザーまたはADグループを含む特定のグループのすべてのユーザーで行うことが出来、標準ポリシーはユーザーもグループも指定されていない場合に適応されます。

Fig118

Fig119

Acropolis ファイルサービス (アクセスベースの一覧 - ABE)

AFSのアクセスベースの一覧では、ユーザーがアクセスの出来る権限を持つファイルとフォルダのみが表示されます。もし、ユーザーがRead(もしくはそれ相当)の権限をフォルダに対して持っていない場合、Windowsは自動的にそのフォルダをユーザーの表示から隠します。ABEはユーザーの共有フォルダの表示をREADアクセス権限によってコントロールします:

  • FIND(ディレクトリ一覧)を利用した場合の応答でユーザーがアクセスできるファイルシステムオブジェクトのみを表示
  • 機微なファイル、フォルダのタイトルをREADアクセス権のないユーザーから隠す
  • 共有レベルの構成パラメーター("hide unreadable(Read権がなければ隠す)")
  • トップレベルフォルダであるHOMEシェアの特別な取り回し

Acropolis ファイルサービス(パフォーマンスと拡張)

AFSは4CPU/16GBの仮想マシンのVMFSあたり500以上の接続が出来るように最適化されました。小さな3ノードで構成されるAFSクラスタでも最大6千万のファイル/ディレクトリまでのファイルサーバにまで拡張することができます。

Acropolis ファイルサービス(パフォーマンス最適化の推奨)

AFSは分散システムとして実装されているため、他のFSVMはアイドル状態にあったとしても幾つかのノード(FSVM)に負荷が偏る可能性があります。そのアクセス不可をノード間または追加のリソースで再分配することでAFSはクライアントにより良いパフォーマンスを提供できます。AFSは平均CPU利用率、SMB接続の数、メモリ割り当て構成、ヴォリュームグループのRead/Writeの利用帯域などを含むの多くの計測値を利用して利用状況を把握し、負荷のバランスを取って解決方法を決定します。

解決策には以下の可能性がありえます:

  • ヴォリュームグループの移動 : いくつかのヴォリュームグループを「ホットな」FSVMから対比し、負荷を下げる
  • スケールアウト : 既存のFSVMが忙しい場合には新しいFSVMを作成しヴォリュームグループを保持させます
  • スケールアップ : CPUとメモリリソースを全てのFSVMに追加します

推奨事項が生成された後に、「Load Balancing」というボタンがファイルサーバタブのRecommendationカラムに表示されますが、管理者はその推奨事項を選択することも、別のもので上書きすることも出来ます:

  • ヴォリュームグループの移動をスケールアップで上書き
  • スケールアウトをスケールアップで上書き
  • スケールアップの推奨事項は上書きができません

一度ユーザーがロードバランスアクションを選択するとタスクが生成されアクションが実行されます。

Fig120

Fig121

Acropolis ブロックサービス(スケールアウトSAN)

Acropolisブロックサービスは高い可用性、拡張性、そして高パフォーマンスのiSCSIブロックストレージをゲストへと提供します。ABSはAcropolisヴォリュームグループサービス上に構成され、AOS 4.5以降利用が可能です。ヴォリュームグループはブロックストレージを提供し、NFSデータストアではサポートされない、もしくはブロックストレージのインスタンス間での「共有」が要件となるようなエンタープライズアプリケーションにとってはとても重要な機能です。ユースケースとしてはESXi上のMicrosoft Exchange、Windows 2008ゲストクラスタリング、Microsoft SQL 2008 クラスタリング、Oracle RACなどがあります。

Acropolis ブロックサービス (CHAP 認証)

  1. Challenge-Handshake Authentication Protocol(CHAP認証プロトコル)
  2. 共有の"秘密"の認証コードと接続元
  3. 相互のCHAP – クライアントがターゲットを認証
  • CHAPは識別子とその試行値を順次変更し、接続元が「録画再生」型の攻撃を仕掛けてくることに対する防御を提供します。CHAPを利用する場合、クライアントとサーバが平文の秘密鍵を知っている必要があり、もちろんこれはネットワーク経由で送っては絶対にいけません。
  • 相互のCHAP認証。ターゲットとイニシエータが相互に認証しあうというセキュリティのレベル。別々の秘密鍵を相互にターゲットとイニシエータにセットします。

その他のABSの改善点:

  • ダイナミックロードバランシング
  • ヴォリュームグループのフラッシュモード
  • IPベースのイニシエータのホワイトリスト
  • イニシエータの管理
  • 幅広いクライアントのサポート - RHEL 7, OL 7, ESXi 6
  • オンラインでのLUNのリサイズ

ワークロードの認定

NutanixはAHVがABS上でOracle VMとOracle Linuxの認定を得たこと、そしてSAP Netweaver stackの認定を得たこともアナウンス致しました。これはビジネスクリティカルアプリケーションをNutanixプラットフォーム上に移したいと考え、OracleとSAPのサポートを待っていたエンタープライズのお客様にとって恋い焦がれたニュースでした。

Fig122

また、本日NutanixはAHVの1-クリックでのネイティブなマイクロセグメンテーションをあなうんすしています。しかしながらこの機能は今後のリリースに含まれることになります。機能と公式な時間軸についての情報はNutanixの公式プレスリリースをご参照ください(こちら)。

Fig123

なんとまぁ、長い機能リストでしょうか、しかも、これで全部ではないのです・・・。直ぐに更に多くの機能で満載のこの記事の第2弾をリリースします。お楽しみに!

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

久しぶりのAndreさんの記事ですが、ようやく公開することが出来ました。先週までのPrismの記事ではとことんまで突き詰めるコダワリを感じさせるものでしたが、今回の内容は正に怒涛のようにリリースされる新機能の嵐。

記事の最初の方にも有りますが、これほどの機能追加はコンシューマー向けのアプリケーションやAmazon Web ServiceやSales Force.comなどのクラウドでしか見ることが出来ません。ストレージ機能はブロック、ファイルサービスと既存のストレージベンダーを置き換えるものになりつつありますし、新たに加わったネットワーキングについてもかゆいところに手が届いている感じ、これが一番必要だよね、というどストレートな機能を直球勝負です。エコシステムパートナーとの連携を見ているといよいよHCIというインフラを脱して完全に「プラットフォーム」になってきていると思います。

やっと訳し終えたのに、Andreさんはもう次の記事に取り掛かっているそうです。次はタイムリーに公開できるようにがんばります!

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