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

2016年9月

2016/09/30

「お好きなメニューを選択ください」 - Veritas NetBackup マルチテナント機能

皆さまこんにちは。

今回はエンタープライズバックアップの定番、Veritas社(旧 Symantec社)のNetBackupのマルチテナント機能を紹介してみます。

Photo_2

Veritas NetBackup についてよく知らないという方は以下のURLをご覧ください。

 

NetBackup で実現するバックアップ統合

http://www.networld.co.jp/product/veritas/pro_info/netbackup/

 

機能の紹介の前に、バックアップにおけるマルチテナントとは何ぞやというところをお話しします。

 

バックアップシステムのマルチテナント化は他のシステムのマルチテナントと同様、ひとつのシステムをテナントごとに論理分割して、複数の企業や部署に割り当てることができる機能です。テナントのユーザはまるで自分専用に用意されたシステムであるかのように操作することができます。

3

各企業ごとに用意していたバックアップシステムをひとつに統合して、各企業は用意されたテナント内で自由にバックアップやリストアを行うことができます。その性質からグループ企業の統合バックアップ基盤やIaaSなどのサービスを提供しているプロバイダ向けの機能ですね。BaaS(Backup as a Service)として提供されます。

 

 

マルチテナント機能を有しているバックアップソフトウェアは意外と少なく、代表的なものはCommVault社のCommVault Software、Dell Technologies社(旧EMC社)の Avamar そして、今回紹介する NetBakup です。

それぞれの製品には各社の考え方の違いなど特長がありますがここでは NetBackup に絞って紹介します。

 

「NSS」と呼びます。

NetBackup のマルチテナント機能ですが、NetBackup Self Service が正式名称です。略称で NSS と呼びます。

Self Service ? と思われる方もいるかと思いますが、NetBackup のマルチテナント機能の性質をよく表した名称だと思います。

 

提供機能

NSSが提供する各テナントへの機能は非常にシンプルで、

  • テナントのユーザ自身によるスケジュールバックアップ設定
  • テナントのユーザ自身による主導バックアップ操作
  • テナントのユーザ自身によるリストア操作
  • テナントユーザへのバックアップ状況画面の提供

のみです。

 

「Self Service」という名

先ほど機能の名前がその性質をよく表しているという話しをしましたが、飲食店などの「〇〇はセルフサービスで」によく似ています。

NSSではテナントのユーザがスケジュールバックアップの設定操作を行いますが、自由に設定することはできません。予めNSSの管理者がバックアップメニューを用意しておいて、テナントのユーザは用意されたメニューから、自分の希望するメニューを選択します。

用意されたメニューをセルフサービスで選択する。さながら飲食店のビュッフェのようですね。

 

2_6

 

「メニューを選択させる」メリット

メリットのひとつは運用の簡素化です。

基本的にテナントユーザが選択することで、バックアップシステム管理者とのやり取りが発生しません。管理者への申請にかかる時間やミスオペレーションなどの人為的トラブルのリスクを減らすことができます。

もちろん、間違って他の環境のサーバへリストアしちゃった、ということも防げます。

  

4_2

 

もうひとつのメリットはテナントのユーザが難しいことを考えなくても良いことです!

通常、バックアップの設定を行う場合は主に以下のことを考えて設定しなくてはなりません。

 

  • バックアップ対象:対象サーバ、ディレクトリ、など
  • バックアップ手法:ファイルバックアップ、DBバックアップ、仮想マシンバックアップ、など
  • バックアップ種類:フルバックアップ、増分バックアップ、差分バックアップ、など
  • バックアップスケジュール:毎日 or 週次、開始時間、など
  • バックアップ保存期間:1週間、1か月、1年、など
  • バックアップデータ保存先:ディスク、テープ、など

 

NSSの場合はこれらを設定するのはテナントのユーザではなく、NSSの管理者です。

NSSの管理者がいくつかのバックアップ設定をテンプレートとしてあらかじめ用意しておき、テナントのユーザはバックアップを行うサーバを選択して、テンプレートの中から自分の要求にあったものを選択するだけです。

 

運用がシンプルということは、ドキュメントの用意や教育などのコスト削減も図ることができますね。

 

逆にバックアップを細かく指定したいという方には向いていません。

 

 

以降はNSSの画面ショットです。非常にシンプルで直感的に操作ができます。

  

 操作GUIはWebブラウザベースのGUIです。NSS管理者用の画面とテナントユーザ用の画面が提供されます。

 

5_2

 

 

NSS管理者のダッシュボード画面です。NSS全体の状況がひと目で確認できます。

 

6_2

  

 

テナントユーザのダッシュボード画面です。テナントに登録されているサーバのバックアップ状況が確認できます。

 

7_2

 

 

 

サーバに対する操作はすべてここから行います。

 

8_2

 

 

 

手動バックアップ操作は3 STEP!!!

 

9_2

 

 

リストア操作も3 STEP!!!

 

10_2

 

 

 

いかがですか? NetBackup は難しいと言われていますが、簡単に見えてきませんか?

NetBackup Self Service では

バックアップの変更やリストア時に申請を出している管理者様、申請の手間を省けます!!

サーバ管理者から申請を受け取っているバックアップ管理者様、オペレーションの手間を省けます!!

テナントごとに管理できるため、テナントのユーザは他の企業・部署のサーバはまったく見えません。

 

NetBackup Self Service で バックアップ管理者とユーザのWIN-WINの関係を作ってみませんか?

 

 

担当 齋藤・吉田

2016/09/28

VMware ESXi ストレージ IO パス

本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。

VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。

原文を参照したい方はVMware ESXi Storage I/O Pathをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

私にとってESXiの中をIOがどのように流れていくのは長い間謎に包まれたものでした。もちろん、私はパス選択ポリシー(PSP)がどういうもであるのかや、ストレージアレイタイププラグイン(SATP)がどういうものかということは知っていましたし、vSCSI statsについても聞いたことが有りましたが、それでもI/Oのフローについて深く説明するということは出来ませんでした。仮想マシンから出たI/Oがどうにかしてカーネルに入っていく、というぐらいしか知らないようなものだったのです。それでもESXTOPのようなstatsコマンドで特定のパフォーマンスの値を監視したり、PSPのレベルでベンダーが推奨する通りの設定を行い、パフォーマンスを監視するということは出来ます。そして、そう、RAWデバイスです。これはまた別のストレージプロトコルやキューが登場します。ですが、これは全体でどのようになっているのでしょうか?

このブログの記事はストレージ IO パスについて一定のレベルでの詳細をご説明します。エンジニアリング(製品開発部門)と緊密に動くことの良い点は日々非常に多くの事を知ることが出来ますが、それを自分のものにしていくことが難しくなるのです。ですから、この多くの情報をより深く調べ、最終的にはブログの記事にまとめることにしました。もちろん、ESXi 6 U1にはVAIO(vSphere API for IO Filtering)フレームワークが追加されていますが、これについては別の記事に後でまとめたいと思います。VAIOを利用すればベンダーはユーザーワールドのコンテキストで動作するフィルタドライバーを経由してしっかりとVMwareのコントロール下に置かれたやり方でI/Oに割り込む方法で開発を行うことが出来ます。今日の時点ではVAIOはまだ新しすぎて、殆どのベンダーはVAIOを利用する製品をリリースすることが出来ていません。どうしてこんなことを書くのかって? それはPernixDataの(そして、今はNutanixの)フラグシッププロダクトであるFVPとストレージ分析ソフトウェアであるArchitectはESXiのプラガブルストレージアーキテクチャ(PSA)で統合されています。更にVVOLによってストレージの管理は著しく簡単になろうとしています。ですが、私はテクニカルサポートエンジニアとして日々過ごす中で、VVOLについて考えはじめ、もしくはさらに次のインフラストラクチャが登場するのではないかと考え始めています。VMwareは既にVVOL以前にポリシードリブンストレージマイグレーションで素晴らしい結果を上げており、私の対峙している顧客は十分満足しています。結果として、VVOLについて考えるのが後回しになっているのです。

仮想マシンからの全てのIOはユーザーワールドのコンテキストでvCPU、VMX、MKS、SVGAなどのそれぞれから、異なるスレッド(ワールド)で開始します。ユーザーとカーネルモードのち我について理解するためには私の最初の記事カーネル vs. ユーザーモードをご参照ください。仮想マシン自身のマネージャーはVMM(仮想マシンモニタ)です。

それからIOは基本的にはVMkernelを通じてどんなアクションが行われるか、そのストレージ実装が利用されているかによって様々なジャンクションを通っていきます。

  • Block Storage(ブロックストレージ):
    • Fibre Channel (FC)
    • Internet Small Computer Systems Interface (iSCSI)
    • Fibre Channel over Ethernet (FCoE)
  • File Storage(ファイルストレージ):
    • Network File System (NFS)

すべてのI/OはVMMレベルで開始されるため、ここまではスキップしてvSCSIフロントエンドからのI/Oフローをご説明していきます。I/OがユーザーワールドからvSCSIフロントエンドへ流れていく部分は非常に面白いです。そして、VMXNETやPVSCSI実装などの準仮想化実装とどう違うのかがわかります。

ESXi I/O フロー

  • vSCSI フロントエンド:
    • フラットバックエンド(VMDK)またはRDMバックエンドのIOの両方が流れてきます。
    • それからI/OはFSS(ファイルシステムスイッチ)へと流れ、その後、DevFS(スナップショット関連のI/O)、VMFSレイヤ、NFSレイヤのいずれかへと導かれます。
    • NFSの場合、その後、ESXiのSUNRPC実装とTCP/IPスタックを経由してVMカーネルインターフェイス(vmk)へとI/Oが進んでいきます。
    • VMFSの場合、道はFDS(ファイルデバイススイッチ)へと続き、そこで、ディスク(通常のスナップショットのないI/O)、スナップショットドライバ、またはLVM(ロジカルヴォリュームマネージャー)へと分岐します。
      • ディスク : 通常のVMDKのI/O。
      • スナップショットドライバ : 仮想マシンがスナップショットを発行するか、スナップショット上で動作している場合、すべてのI/Oは再度FSSへと送られ、スナップショットの連鎖はDevFSの実装を通してマウントされます。
      • LVM : ディスクが作成、拡張、結合された場合。
    • I/OはPSA(プラガブルストレージアーキテクチャ)へと進んできます
      • デバイスキューは2つのエリアに別れます:
        • SCSIデバイス
        • SCSI Sched キュー
      • ここへ至ったIOは殆どの場合、NMP(ネイティブマルチパシングプラグイン)かEMCがPowerPathと呼んで提供している完全なプラグイン実装へと流れていきます。今回はNMPのみにフォーカスします。
        • SATP(ストレージアレイタイププラグイン) ストレージシステムとの連携を実現するコントロールプレーン
        • PSP (パス選択ポリシー) ストレージ自身へのI/Oを制御するデータプレーン
      • 最後にI/Oは物理的なHBA、キューイング、SCSIエラーを管理するSCSI Midlayerへと到達します。ESXiのSCSI Midlayerについてもっと詳しく知りたい場合にはこのリンク先のVMware SAN System Design and Deployment Guideの58ページもご参照ください。

以下の図はI/Oフローの詳細をそれぞれのパーツを結合して顕したものです。

Fig028

ESXiのストレージ実装

VMM:

仮想マシンモニタ(x86 CPU、SCSIコントローラをエミュレーション、等)

共有リング:

共有リングはVMMとVMカーネルの間の共有キューで、VMMもしくはVMカーネルの両者はパフォーマンスのペナルティなくこの共有リングへアクセスが可能です。共有リングのサイズは発生させられるI/Oの数を決めてしまいます。VMカーネルが共有リング内のI/Oを見つけるとすぐに、このI/Oをキューから取り出し、vSCSIフロントエンドへと送ります。もっと詳しく知りたい方は以下のKBを参考にしてください。

ソース : VMware KB: 2053145

vSCSI:

VMカーネルのSCSIフロントエンドで、SCSIリクエストと仮想化されたファイルへのI/Oリクエストを送信します。

Flat Backend(フラットバックエンド):

ファイルをエミュレーションします。

RDM Backend(RDMバックエンド):

RAWのLUNへのポインタ/シンボリックリンクです。リンク内に識別子が埋め込まれます。

FSS (ファイルシステムスイッチ):

ファイルシステムのドライバを実装する際に利用できます。APIは公開されていません。

DevFS:

殆どのUNIXベースのファイルシステムと非常によく似ており、実デバイス、非実デバイスをエミュレーションします。

VMFS:

VMFSの3と5の両方を実装した単独モジュール。

NFS:

NFSプロトコルを実装しています。

FDS (ファイルデバイススイッチ - ブロックストレージ):

ディスク、スナップショット、そしてLVMの切り替えに利用されます。

ディスク:

すべてのディスクベースのブロックデバイスをエミュレーションします。ストレージスタックと直接やり取りします。

スナップショットドライバ:

フィルタドライバとして実装されています。フィルタドライバによって、FSSへとIOが戻るため、ディスクが再帰的にDevFSへとマウントされます。

LVM (ロジカルヴォリュームマネージャ):

削除、結合、作成などが発生した場合にはLVMへと司令が送られます。LVMはヴォリュームの結合を行い、論理領域としてヴォリュームを上のレイヤへ見せます。VMFSとしてデータストアをフォーマットすると以下のように動作します:

  • はじめにLVMに論理ボリュームが作成される
  • それから、そのヴォリュームがVMFSでフォーマットされる

このようになる理由はディスクが異なるLUNをまたがって拡張、結合される可能性があるからです。もちろん、再署名 例えば、スナップショットされたLUNでは同一のUUIDが利用されているので、LVMによって再署名される可能性があります。

PSA (プラガブルストレージアーキテクチャ):

SCSI デバイス:

すべてのローカル、そしてリモートのデバイスはSCSIデバイス構造になっています。(ターゲットあたり256以上のLUNは存在し得ない)


SCSI スケジュールキュー:

ストレージスタックは比例型の共有スケジューラ(シェア)を実装しています。SIOC(ストレージ I/Oコントロール)はこれをクラスタベースで行うものですが、SCSIスケジューラーキューを利用しています。シェアの値には全てのSCSIディスクの数が利用されます。

SATP (ストレージアレイタイププラグイン - コントロールプレーン):

ベンダー固有の機能を有しています。例: Trespass : LUNで利用可能なSP(サービスプロセッサ - ストレージシステムのコントローラ)のアクティブ-パッシブを制御します。また、I/Oが異なるSPから流れ込み、そのためにその異なるSPへと接続してI/Oを受けたなどを状態を理解することも可能です。SATPは障害時にもストレージとのコミニュケーションを行います。

PSP (パス選択ポリシー - データプレーン):

PSPはバックエンドのストレージにどのようにReadとWriteを提供するかを司ります。PSPには3つのフレーバがあります : MRU(もっとも直近で利用したパス)、Fixed(固定)、そしてRR(ラウンドロビン)。

  • Most Recently Used (MRU): VMW_PSP_MRUポリシーは利用可能な最初のパスを選択します。このパスはシステムのブート時に検知されます。パスが利用できなくなった場合、ESXi/ESXホストは別のパスへとスイッチし、新しいパスが利用できる限りはそのパスを利用し続けます。これはアクティブ/パッシブのストレージ装置において論理ユニット数(LUNs)の標準ポリシーです。ESXi/ESXは万一、パスが復帰したとしても以前のパスへと復帰しようとはしません。利用している障害が起きないかぎりは、です。
  • Fixed (Fixed): VMW_PSP_FIXEDポリシーは指定された場合にはそのフラグが立っているパスを固定的に利用します。もし指定がない場合、システムのブート時に検知したパスの最初の利用可能なものを利用します。ESXi/ESXがその選択したパスを利用できない、もしくは出来なくなった場合、ESXi/ESXホストは別のパスを選択します。ホストは自動的に事前に定義されたパスが復帰するとすぐさまそのパスへと復帰します。このポリシーはアクティブ/アクティブのストレージ装置を接続したときのLUNsの標準ポリシーです。
  • Round Robin (RR): VMW_PSP_RRポリシーは自動的にパスを選択し、利用可能な全てのパスの中で負荷を分散しながら設定されたパスを利用します。
    • アクティブ/パッシブストレージ装置では、アクティブなコントローラのパスのみがこのラウンドロビンポリシー時には利用されます。
    • アクティブ/アクティブストレージ装置では、全てのパスがこのラウンドロビンポリシーで利用されます。

ソース: VMware KB 1011340

このブログの記事が少しでもあなたのお役に立てば。もちろん質問があれば、いつもどおり気軽にコンタクトください。

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

さて、前回に引き続き、Guidoさんの記事です。VMwareのカーネルの中(といっても、ストレージ部分だけですが・・・)をこんなに解説してくださっている記事はなかなか無いと思いましたので、前回のものと合わせて翻訳させていただきました。前回とは異なって、I/OがESXiの中をどう流れていく?ということを順を追って解説してくれています。さすが、カーネルの中でI/Oを捕まえてぶん回している会社(PernixData/今はNutanix)のサポートチーム・・・詳しい!もちろん、VSANについてはまた上の図の中に別の枝が出て実装されていますし、今後はVAIOでもっと面白い実装も出てくるのではないかと思いますが、あくまでベーシックということで。技術的に深すぎてNutanixもPernixDataもVSANも違いがなくなってきています・・・そんな技術を組み合わせてソリューションを生み出していく各社・・・。そして、我々はそれを理解した上で、お客様に最適なソリューションをご紹介するソリューションディストリビュータです。

次回もGuidoさんのふかーい記事を翻訳予定です。まだまだ続きます。

2016/09/21

カーネル vs ユーザーモード

本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。

VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。

原文を参照したい方はKernel vs. Usermodeをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

私の生まれて初めてのブロク記事へようこそ! この記事はとても前に、ブロクを始めようと思った際に書いたものですが、その時にはいろいろな事情で公開しませんでした。 :) でも、ほら、ようやく公開することが出来ました。記事の内容についてはとても昔の内容から初まります。「ITインフラストラクチャ」という名前の大学の講義で、私がOSのカーネルの深みに初めて踏み入り、CPU内のキャッシュやCPUが実際にどのように計算を行っているとか、もちろんもっと多くの事を知った際の話からです。その時私はOSカーネルの中が非常なめらかで、その一方で非常に複雑であり、時には危険だということに驚きました。例えばメモリの上書き、C言語でのプログラミングで手続き上のオブジェクトが存在しないなどです。もちろん、あらゆるOSのハードウェアを利用するためのドライバーはRing 0で動作しています。ですから、複雑さは実際にはカーネル内で動作しているソフトウェアの機能によって大きく異なります。もちろん、品質についても同じです。さぁ、前置きはこれぐらいにして、記事の中身に入っていきましょう。

オペレーティングシステムは通常は非常に大きなプログラムで、コアコンポーネントはカーネルと呼ばれます。カーネルは全てのハードウェアリソースを司るオーナーでもっとも深いソフトウェアレイヤで動作しており、ハードウェアに直接アクセスを行うことが出来ます。カーネルが行っていることは:

  • アプリケーションへのインターフェイス(API)
  • CPU(中央演算装置)、ハードウェアデバイス、メモリ(スケジューラ、ドライバ、メモリ管理)のコントロール
  • リソースのスケジューリング 例 :アプリケーションの処理時間
  • リソースの構成 例 : ディスクのようなブロック指向のデバイスのファイルシステムへのマッピング
  • リソース競合の解消 例: リソースのキューイング、CPUリソースのロック
  • リソース~プロセッサ(をプロセスへ)、ディスク(をファイルへ)、メモリ(を仮想化メモリへ)~の仮想化
  • ファイルやデバイスのアクセスコントロールの監視

Exokernel、モノリシックカーネル、レイヤードカーネルなどのように、異なる目的に対して非常に多くの種類の異なるカーネルがありますが、それらの詳細の違いについて踏み入ることはしません。今日もっとも利用されている種類のカーネルはマイクロカーネルと呼ばれるものです。マイクロカーネルはすべてのWindowsワークステーション・サーバそして、LinuxをベースとしたOSやVMware ESXiでも利用されています。OSを様々なプロセスに分割、分けていく理由はクライアントが他のOSやアプリケーションでも良くしようというためです。ですからクライアントがリクエストを適切なサーバにメッセージを送信することで実行し、サーバは処理を実行します。マイクロカーネルは結果をクライアントに返します。以下の図にそれを示しました:

Fig026マイクロカーネル

マイクロカーネル固有の特性の幾つかは:

  • OSの一部を容易に置き換え可能
  • ドライバはユーザモードでもカーネルモードでも動作する
  • 物理I/Oアクセスの実装が難しい
  • コンテクストスイッチ(時にはタスクスイッチやプロセススイッチとも呼ばれる。単一のプロセスやプロセスのスレッドが別のCPUへと切り替わること)

ユーザーモード (ユーザープログラムで言う非特権モード) :

全てのユーザープログラムはこのモードで実行されます。ユーザーモードはメモリやハードウェアへの直接のアクセスを行いません。この理由はすべてのプログラムがそれぞれでメモリを書き換えると他のプログラム用のメモリを上書きしてしまい、衝突が起きてしまうからです。ユーザーモードのプログラムは通常はカーネルの観点からは信頼性のないソフトウェアとして取り扱われます。もし、ハードウェアリソースへのリソースが必要な場合にはその下のAPI(システムコール)を経由して手続きが行われます。

カーネルモード (システムモードとも呼ばれる):

このモードは全てのカーネルプログラムで利用されています。カーネルモードではプロセスがその下のすべてのハードウェアに直接アクセスを行います。CPUだけがカーネルとユーザーモードを同時に実行することが出来ます。ユーザーからカーネルモードへのスイッチは自動的に行われ、その際には割り込みが発生します。

マイクロカーネルの詳細への踏み込みはおこなわず、ここでは少々コンテクストスイッチにフォーカスしたいと思います。すべてのプロセスは単一、又は複数のスレッドで実行されます。プログラムはスレッドを利用して事実上の並立実行時間を設け、1つ以上のCPUで実行されます。上で述べたように、マイクロカーネルは全てのリソースを司ります。ですから、もしもプロセスがCPUで動作しようとするととても大きなオーバーヘッドが生じます。既存でCPU上で動作していた環境は以下によって抑制がかかります :

  • プロセスのステータス
  • プログラムカウンタ
  • スタックポインタ
  • ファイルのオープン状態
  • メモリ管理 : 実際の実行環境へのポインタ

メインメモリへの一回のアクセスの全てのステップで、CPU内のこのプロセスのキャッシュは全てが廃棄されます。これはもはや正しいキャッシュではなく、将来的にキャッシュのミスを引き起こすからです。すべてのプロセスがCPUを利用しようとする度にOSのスケジューラーはいつそのプロセスがCPUを利用するかを決め、実際にCPUを利用させるのです。

Fig027プロセスの状態

コンテクストスイッチはカーネル内でしか発生しません。ですから、もしアプリケーションがCPUのプロセスを利用したい場合には、ユーザーモードからカーネルモードへシステムコール経由で移行しなければなりません。ですから、ユーザーからカーネルモードへ恒久的にスイッチするということは非常にコストが高く、多くのCPUサイクルを利用します。カーネル内で直接動作するソフトウェアはオーバーヘッドを著しく減らし、パフォーマンスが向上します。仮想化の世界でのカーネル実装の2つの例は:

  • VMware VSAN
  • PernixData FVP

さぁ、まとめに入りましょう。アプローチの方法はその目的によって様々ですが、一般的には以下が言えるでしょう:

  • カーネルモードのドライバ/ソフトウェアは実際にOSのコアで動作する点や、加えてプログラムの方法も限定されているため非常に複雑ですが、実現できればパフォーマンス面からは非常に大きなメリットが有ります。セキュリティの面から考えても、カーネル内からは外からそれを行うよりはるかに簡単です。
  • ユーザーモードのソフトウェアは非常に強力で、それは安定性の実装が簡単であり、プログラミングフレームワークを数多く選べることからのメリットもあります。ユーザーモードとカーネルモードのソフトウェアを組み合わせた実装も目にすることが有ります。これはカーネルモジュールとのやり取りを必要とするようなケースがあるからです。これはユーザーモードで動作しているコアOS自身のデーモンプロセスなどで見られます。

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

いかがでしたでしょうか? OSの中身まで奥深く分け入らない、と言いながらもCPUの中で何が起きているか、などまで解説していますのでなかなかわかりにくいかもしれませんが、一昔前にある種の「宗教戦争」として勃発したインカーネル対仮想化ストレージアプライアンスをこれ以上ないぐらい低いレイヤからみた話としてご紹介しました。まとめのところにあるように、カーネル実装は強力ですが、複雑で、実装も難しい、けれどもパフォーマンスの観点からは大きくベネフィットが有ります。ユーザーモード実装はフレームワークを様々に選択できるため実装が簡単です。裏返しとしてコンテクストスイッチの発生の際にはCPUのキャッシュを廃棄したり、スケジューラーのサイクルを待たなくてはならないこともあります。また、私がとても気になったのは「ハイブリッド」の実装もあるよ、という一文です。

買収直後の記事ですし、深読みしてしまうところもありますが、宗教戦争のような絶対的な決着があるわけではなく、目的によってカーネル、ユーザーモードを使い分けるのが正しいということを覚えておいてください。そして、カーネルモードの実装例として上げられているPernixData FVPは現在はユーザーモードの実装例の代表格であるNutanix社の手の中にあるのです。さぁ、将来が楽しみですね。Guidoさんの記事は非常に深いレイヤからの知識を教えてくれ、いろいろな意味で面白いので今後も翻訳の対象にしていきます。お楽しみに!

2016/09/14

ウェブスケールインフラストラクチャ上のオールフラッシュのパフォーマンス

本記事の原文はNutanix社のGlobal Engineering / R&D TeamでManager Business Critical Appsを務めるMichael Webster氏によるものです。原文を参照したい方はAll Flash Performance on Web Scale Infrastructureをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

Fig020_2

オールフラッシュストレージアレイは今日では人気を博し、従来からのミッションクリティカルなファイバーチャネルのアレイから大きくビジネスを移行させつつ有ります。そして、従来型の3層構造のアーキテクチャは少しだけですが、シンプルになりました。僅かな数の仮想マシンが大きなパフォーマンスを必要とするようなスケールアップ型のワークロードに対し、優れたパフォーマンスを提供し、さらに、データ削減のテクニックを利用してキャパシティの削減も同時に提供しています。オールフラッシュシステムがさらに優れているのは大きな負荷がかかったり、キャパシティが限界に近い状態であったとしても一貫したパフォーマンスと低遅延を提供するということです。しかし、従来型のアーキテクチャに比べて少しだけシンプルだ、ということはまったくもってシンプルであるとは程遠いのも事実です(FCの管理オーバーヘッドだけ)。そして、まだインフラストラクチャがインビジブルであるともいえません。まだ幾つかの制限があります。オールフラッシュが欲しくて、更に制限のないスケールアウトも欲しい、数千の仮想マシンを動作・サポートしなくてはならない、でも管理を従来型の3層構造よりも簡単にしたいとなったらどうしますか? 効率よくインフラストラクチャをインビジブルにしたいのです。

答えはとても簡単です。インフラストラクチャが将来そうなるのと同じで、Nutanixを選択すればよいのです。Nutanixは1年前にオールフラッシュソリューションを打ち出しました、そして一貫した高パフォーマンスと想定通りの低遅延優先度の高いワークロードに対して望むお客様に大きな人気を博しています。NX 9040ノードは6本のIntel S3700というエンタープライズクラスのSSDとE5 v2を2ソケット、最大で512GBのメモリを融合させています。このソリューションは2ラックユニットのスペースに2ノード(最大でラックあたり364TBの物理フラッシュストレージ)収めることが出来ます。これはOracleデータベースやSQLサーバ、SAP、Temnos T24 core Bankingなどにうってつけのプラットフォームで、これら全てを動作させているお客様までいます。特に、Nutanixのデータ削減機能やデータ回避機能と組み合わせると、同じ物理ストレージ内で更に多くのキャパシティを利用することが出来ます。Josh Odgers氏(NPX #001)はEC-Xと呼ばれる新しい機能(訳注:リンク先は英文、現在のところ翻訳予定なし)についての記事を公開しています。

Nutanixのデータ削減

データ削減には圧縮、データ重複排除そして、EC-Xなどが含まれます。データ回避機能は例えばVAAI統合、シンプロビジョニング、そしてスマートクローンとスナップショットなどで、不必要なデータや重複したデータを最初に作成しない機能です。データベースやビジネスクリティカルアプリケーションでは、圧縮は推奨されています。重複排除については大規模なデータで異なるデータが多い場合にはさほど効果的ではないというケースも有ります。こうした手法によってそのまま利用するよりも、もっと利用できるキャパシティが増える可能性がありますが、その効果はワークロードによって様々です。2:1、3:1もしくはもっと高い割合のことも有ります。単一の手法だけでも、ワークロードに向いている手法であればもっと高い割合になることもあるのです。

データベースにおいてSQLサーバで透過的データ暗号化(TDE)やOracleでアドバンスドセキュリティ暗号化を利用しているような場合、これほどには効果が出ない場合もあります。NX9040を含む、同じプラットフォームでデータ最終暗号化をサポートしており、これによってアプリケーション自身での暗号化を不要にする事も可能です。暗号化されたワークロードにおいてキャパシティを効率的に削減するのは難しいものです。以下のイメージはNX9040の単一クラスタでNutanixのPRISMユーザーインターフェイスから見た際のOracle RAC データベースがどれほどの削減がなされたかを表しています。これは実現出来ていることのほんの一例でもちろん、ワークロードに依存します。効果は様々なのです。

Fig021

上記のイメージからはデータベースが5.57TiBのキャパシティをデータ削減前に利用していたということが分かります。データベース自身は3TBですから、データ保護やデータ保全性のためのオーバーヘッドがあることが分かります。データ削減が行われた後のキャパシティは1.95TiBのみです。この削減効果は圧縮からの効果のみです。もしも圧縮とEC-Xを組み合わせれば、もっと大きな削減効果を得ることが出来るはずです。Nutanixクラスタが大きくなれば、データ削減の手法は更に効率的なものになります。

もう一つ圧縮の例を上げましょう。今回はExchangeにJetStress Databaseで負荷をかけたものです。(注意 : JetStressは実際の世界ではあり得ないワークロードでここでのデータ削減率は実際のExchange環境での物よりも高い可能性があります。)

Fig022

殆どの環境では検証・開発のワークロードが本稼動系とともに動作しています。Nutanixのやり方では、ワークロードのスナップショットの作成やクローンの作成してもストレージ消費は増えることはありません。これ等の操作ではデータに変更がないからです。これはテンプレートを展開する際にもESXiとVAAI(VMware API for Array Integration)で同様に実現されます。新しい仮想マシンを欲しいだけ展開しても、実際にデータが書き込まれるまではストレージの消費は増えないのです。

こうした手法を利用して、100%完全なデータを開発・検証環境で利用しながら、ストレージの消費を抑えることが可能です。高いレベルでコードが動くという確信を持ちながら、本稼動系へとワークロードを移行することができ、いつでも検証環境の状態へと戻ることも出来るのです。全ては数秒で追加ストレージキャパシティを消費するという心配は必要ありません。

Nutanixのデータ削減とデータ除外手法についてはNutanixバイブルの分散ストレージファブリックのセクションもご参照ください。

Nutanixのオールフラッシュのパフォーマンス

データ削減や回避の手法によってワークロードのパフォーマンスも様々に変化します。単一のアプリケーションからのIOパターンが単一であるということはほとんどありません。ですから、パフォーマンスを検証するのにもっともよい方法は実際のアプリケーションを利用することです。実際のアプリケーションは4KBサイズのIOだけを生成するということは一般的にはありません。ですから、今回はNutanixのオールフラッシュのパフォーマンスを検証するためにSLOB(SLOBのオフィシャルページはこちら)、SwingbenchBenchmark Factory for DatabaseHammerDBのようなツールを利用しました。ここではSLOBを利用して取得したイメージを例に提示します。

IOパフォーマンスを検証する際に、文脈を無視して、単独の計測値だけを見てはいけません、そうしなければ検証は意味が無いものになってしまいます。IOPSを例に取ると、IOサイズ、レイテンシ、スループットが異なれば劇的に値が変化します。ですから、IOPS単独だけでは確かな計測ができているとはいえません。今回のテストでは、Oracle RAC環境に対して、SLOBを利用して大量の小さなReadを生成しました。それぞれのReadは8Kで、これはデータベースの生のページサイズです。このIOパターンは100%ランダムです。トランザクションログのIOはかなり大きなIOサイズであり、当然シーケンシャルです。

以下のダイアグラムのテストを行ったシステムは2ノードのOracle RACクラスタ(それぞれのノードで 48 vCPU、192GBメモリ)を2台のNX4170(4 x E-4657L v2, 512GBメモリ)と4台のNX9040(2 x E5-2690 v2 512GBメモリ)で構成されたNutanixクラスタ上で動作させています。いずれのシステムも旧世代のIntelのIvy Bridgeのプロセッサ技術を利用しています。ハイパーバイザーはESXi 5.5を利用しており、後にESXi 6.0にアップグレードしたところ、更によいパフォーマンスを示しました。

Oracle RAC SLOB IOPS

Fig023

上のイメージでは2つのテストが行われています。一つ目は30%がupdate(更新、データ書き換え)であるというワークロード、もう一つは100% select(選択、データ参照)のワークロードです。updateのワークロードではきっかり70K IOPSが生成されています。

Oracle RAC SLOB レイテンシ

Fig024

異なるベンチマークの最中のレイテンシが上に表示されています。updateの多いテストではレイテンシは高くなり4ミリ秒ほどになっており、ピークでは7ミリ秒になっています。selectの多いワークロードに於いてはレイテンシは0.45ミリ秒です。2つ目のテストでのレイテンシが低いのはハイパーバイザーを最新ヴァージョンにアップグレードすることによって更に低くなりました。

Oracle RAC SLOB スループット

Fig025

上のグラフから読み取れるのはupdateが多いテストではスループットはカッチリ800MB/秒で、selectが多いテストでは1.13GB/秒でした。思い出して欲しいのはこれはNutanixのハイパーコンバージドアプライアンスであり、全体で8ラックユニットのスペースにコンピューティングとストレージの両方が収まっているということです。近い将来、Nutanixはもっとこうしたパフォーマンスを実現するための物理的なスペースと電源要件を削減する予定です。もっと小さなスペースで、そして、もっとシンプルな環境でオールフラッシュのワークロードを動作させることができる様になります。

オールフラッシュが必要なのか?

利用するか、利用しないかは当然皆様のご選択です。Nutanixは強力なオールフラッシュのオプションをNX9040で提供しています。将来のプラットフォームではこれをさらに推し進め、もっと極端なワークロードへも対応できるようにしていきます。Nutanixのプラットフォームではあらゆるノードのタイプでいくらかのフラッシュが搭載されています。データはフラッシュとハードディスクにおいてブロックレベルでのアクセス頻度に応じた階層がが行われます。オールフラッシュが必要か、そうでないかということは結局のところ、ソリューション全体のライフタイムの中で予想通りの結果を売ることが出来るか、というところに帰結します。アプリケーションがホットデータしかなく、フラッシュの上にすべてデータが有ることを保証したい場合にはオールフラッシュはそれに答えてくれます。オールフラッシュプラットフォームはオーバーヘッドが小さく、データ階層化の必要性がありません。ですが、ほとんどのワークロードにおいてはデータ階層化は非常に効率的で、充分です。

現段階で、オールフラッシュに向いているのはデータベースやアプリケーションサーバのような、低遅延サービスの保証が必要とされるものです。特に、パフォーマンス以外にも、仮想化によって物理ノードあたりのシステム数を上げることでライセンス上のメリットを受けられるような場合、更に多くのアプリケーションをノードに仮想化することが出来ます。OracleやSQLサーバを考えてみてください。

Nutanixは最近ハイブリッドのノードにおいても、フラッシュピンニングという機能をアナウンスしました。まだリリースされていません(原文執筆時、現在はリリース済み)が、リリースされた暁には仮想マシンや仮想化ディスクをフラッシュ層にピン留めすることが出来るようになります。この機能は標準のハイブリッドとオールフラッシュオプションの中間に位置するようなものです。時が経つにつれ、ほとんどのシステムはフラッシュの寡占状態になり、ハードディスクはスナップショットやバックアップ、アーカイブなどでのみ利用されるようになるのではないかと予想しています。

おわりに

今回の記事に掲載したイメージのとおり、ハイパーコンバージドのウェブスケールプラットフォームのオールフラッシュは特筆すべき管理の簡単さ、低遅延、制限のないスケールアウトが必要な環境において、優れたパフォーマンスを提供します。プラットフォームにより多くの利用可能なストレージキャパシティを提供するデータ削減と回避の手法は他のオールフラッシュアレイと同様にNutanixでも動作します。これが唯一上手くフィットしないところがあるとすれば単一の極端なワークロードまたは仮想マシンがアレイのパフォーマンスの全てを必要とするというようなケースでスケールアウトできない、計画もないというような場合だけです。こうした状況であればPure Storageのような物を選択する方が良いでしょう。それ以外のすべての場合、Nutanixは他のものに比べ遥かにシンプルなソリューションで優れたパフォーマンスと無制限の拡張性を提供することが出来ます。

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

いかがでしょうか? 既に様々なベンダーからオールフラッシュストレージソリューション、オールフラッシュハイパーコンバージドソリューションが提供されていますが、今回あえてこの記事を翻訳したのはいくつかのブロク/ニュースに記載されているように当社が国内で提供を行ってきた(そして私の大好きな!)PernixDataのテクノロジーが上でお見せしてきたような優れたパフォーマンスに加えて利用ができるようになるとの期待からです。PernixData社のソリューションはFlashだけではなく、メモリ、そしておそらくは今後多く登場してくるメモリクラスストレージ(または大容量不揮発性メモリ)のテクノロジーにまで利用することが出来るようになっています。Nutanix社のCVM(VSA)の実装とPernixData社のin-kernelの実装が今後どうなっていくかなど、興味はつきませんが、PernixData社が大好きな私以外の皆様の興味にも答えられるように、今後も面白い記事を選びながら更新していきたいと思います! 引き続きよろしくお願いいたします。

2016/09/09

[最新鋭、IBM FlashSystem A9000を大解剖!]

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

筆者もびっくり!ここまでやるか!何があってもデータは守る!究極の機能っ!


以前のお話で、グリッドコントローラーのワンランク上の堅牢性をお話しましたが
今回少しだけその中身をお見せしましょうっ!

このグリッドコントローラー、冗長電源を搭載してるが、それだけじゃなかった!
フロントのベイにディスク以外の見慣れない謎のモジュールが・・・
1モジュールが2.5インチベイで4スロット分に相当するコンパクトなものだが、き、気になる!!。

Batt

日本アイ・ビー・エムの担当エンジニアさんの “どうぞどうぞっ♪” の一言で、て恐る恐る引き抜いてみると

むむっ、手のひらサイズ?バッテリー?? そう、バッテリーなのだ!!

Grictlbatt01

筆者の見たところ、おそらくハイドレインタイプの高信頼なセルで構成されたバッテリーモジュールではないかと推測しているっ!!

すげー分解してみたかったけどマジで高価な機器なので、お願いする勇気がでませんでした!!

Grictlbatt02*見るからに容量の大きそうなコネクタがっ!!

公開情報から紐解くと、ホットスワップ可能のバッテリーモジュールで
各バッテリーモジュールは電源障害が発生した場合、正常なシャットダウンの完了に十分な電力を供給できるとのことっ!
要は電源障害で冗長電源の両方がダウンという最悪の状況でも
この手のひらにのるバッテリーモジュールによりグリッドコントローラーはそのまま稼動し続け
安全にシャットダウンを完了してくれるっ。
まるで筐体内にUPS内蔵しているかのようだ!!
  

まさかグリッドコントローラーにまでこんな手の込んだ仕掛けがあるとは・・・

  

ちなみに、フラッシュエンクロージャーはストレージ機器なのでこの辺の機能は抜かりなく
フロントのベイに搭載される2個のホットスワップ可能のフラッシュエンクロージャーバッテリモジュールにより
これまた電源障害で冗長電源の両方がダウンしても
システムを正常にシャットダウン(完全にフラッシュされ、同期化されたキャッシュを書き込む)することが可能です。

Ffx408

 

更に~っ!!(これ、筆者もはじめて知りましたっ!!)

A9000Rにいたっては、接続の要となるInfiniBandSwitchにまで同等の機能がっ!!
なんとバッテリーバックアップユニット付きの冗長電源が搭載されているのだ。
冗長電源の両方がダウンしてもバックアップバッテリーにより
システムのシャットダウン完了までオフラインになる事無く稼動を続けることができるっ。
もちろんこのバッテリーはホットスワップも可能だ!

Ib_batt

グリッドコントロ-ラー、フラッシュエンクロージャーのバッテリーと同じようにInfiniBandSwitchのバッテリーも
常時監視され定期的にキャリブレーションが行われているっ。

  

公開情報を読み進めていくと書いてありましたっ♪。

A9000/A9000Rを構成する各モジュールに搭載されるバッテリーバックアップユニットのおかげで
システム全体の主電源の供給が断たれた場合でも
自動的にシャットダウンを実行し、キャッシュ等の全てのデータを書き込むまでオンラインの状態を維持する事が可能との事です。

  

たとえデータセンター全体の電源がダウンするような事態でも守り抜く!
このシステムには大切なデータを守る究極の機能が搭載されているのですっ♪

A915b3e0c728ea1369d7adcf8b3ab712_s

そうなんです!このA9000/A9000Rってここまで考えられているんですねっ♪

そこまでやるか!A9000/A9000R

  
次回は、「キミもエンタープライズを体感してみなイカっ♪」ですっ。 :)

By:まいけル

参考資料
IBM FlashSystem A9000 and IBM FlashSystem A9000R Architecture, Implementation, and Usage

2016/09/08

Nutanix 4.7とAsterixの機能概要(Beyond Marketing)

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

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

AOS 4.6がリリースされて4ヶ月が経ち、新しいNutanixのメジャーリリースとその心機能や改善点がもうすぐ利用できるようになります。Nutanixの新しい機能や改善点のリリースの速度はコンシューマ業界のアプリケーションが更新と同等で素晴らしいペースでユーザーを魅了しています。

このブログ記事はAOS 4.7でリリースされる機能と、さらに、その先のコードネーム「Asterix」と呼ばれているリリースでの機能を幾つか含んでいます。もし、以前のAOSのリリースについて見落としている方は以下を読んでください。

Nutanix 4.6 Features Overview (Beyond Marketing)

Nutanix 4.5 Features Overview (Beyond Marketing)

Nutanix 4.1 Features Overview (Beyond Marketing)

Nutanix 4.0 Features Overview (Beyond Marketing)

(訳注:原文へのリンクです、現時点での和訳予定はありません。)

以下の機能をこの記事でご紹介いたします:

  • 最新Broadwellへの対応とオールフラッシュ
  • SX プラットフォーム (Nutanix Xpress)
  • ノードのダウングレードの振る舞いの検知
  • Foundation 3.2
  • Acropolis ファイルサービス (パフォーマンスの最適化)
  • Acropolis ファイルサービス (TRIMのサポート)
  • Acropolis ブロックサービス (ABSと呼ぶ)
  • AHV ダイナミックスケジューリング
  • Acropolis コンテナサービス
  • Nutanix上でのCPS Standard(プロジェクト La Jolla)
  • Prismでのネットワーク可視化
  • What-If 分析
  • 要素ブラウザの改善 (カスタム重視、ページサイズ、シフトでのセレクト)
  • Nutanix セルフサービス
  • Pulse リマインダ
  • ワンクリック LSI HBA アップグレード

注意: 「Asterix」のリリースに含まれる機能については我々の恐れを知らぬガリア人で印をつけています。

訳注: このマーク

Fig006_4

がどうもそれのようです。 

プラットフォーム

最新Broadwellへの対応とオールフラッシュ

Fig000_2

フラッシュテクノロジーがデータセンタの形を変えつつあることに疑いを挟む人はいないでしょう。一貫した、想定通りの低遅延の応答が必要とされるワークロードはオールフラッシュプラットフォームの恩恵をもっとも受けられるワークロードです。フラッシュに加え、インテルの第5世代のBroadwell CPUが広く採用されつつ有ります。これを考慮して、NutanixはすべてのNXプラットフォームをインテルのBroadwll-EPのCPUに対応致し、さらに殆どのプラットフォームでオールフラッシュのオプションが選択できるようにしました。以下のテーブルはG4とG5ハードウェアでのNXファミリーのハードウェアの変更を表しています。DellとLenovoも彼らのプラットフォームをBroadwell CPUに対応させました。

Fig001

SX プラットフォーム(Nutanix Express)

Nutanix Xpressは新しいNXの製品ラインで小さな組織のITのニーズを管理の簡単さ、低TCO、シンプルさ、展開のリスクの低減とともに、Nutanixの単一コールでインフラストラクチャ全体のスタックをサポートするワールドクラスのサポートをもたらすことで解決するために設計されています。Nutanix XpressはSMBの向けた機能を搭載したXpressソフトウェアエディションを事前に構成して出荷されます。オフィシャルのプレスリリースはこちらです。

Fig002

Fig003

デグレードしたノードの振る舞いの検知

Nutanixはサービスの復元性を前提にして設計され、フェイル・セーフ(障害を無効化)の分散アーキテクチャで実装されています。そうであっても、クラスタとシステムはフェイル・ストップ(障害で停止)してしまう設計が広く利用されています ー これがNutanixが根本的に一から設計されてきた理由です。しかしながら、部分的に利用可能(デグレードしている)ノードは一つのクラスタ全体のパフォーマンスにそれなりの影響を及ぼします。 分散アーキテクチャでは、部分的に利用できるという状態は様々な理由、例えばネットワークの帯域の低下、ネットワークのパケットドロップ、ソフトウェアのフリーズ、部分的に故障したディスク、ECCエラーを発するおかしなDIMMなどで発生します。

AOS 4.7まではクラスタのそれぞれのノードで動作しているサービスはスコア/投票によって他のノードで動作しているサービスに通知されていました。それぞれのノードでのスコアはRPCのレイテンシ、RPC失敗/タイムアウト、ネットワークのレイテンシなどで計算されています。もし、特定のノードで動作しているサービスが一定時間続けて悪いスコアを受信した場合、他のノードはそのノードがデグレードしたと確認します。

ノードがデグレードしたと検知されると、クリティカルなサービスのリーダーシップはそのデグレードされたノードから退避され、そのノードはメンテナンスモードへと移行し、CVMが再起動されます ー ですが、サービスの停止は伴いません。デグレードしたノードについてのアラートが生成されーもし、Pulseが有効になっている場合にはNutanixのサポートへ自動的に状況が通知されます。

これは隠れたプラットフォームの機能が最高のエンタープライズソリューションをさらに良い物にしてくれるという完璧な例の一つです!

Foundation 3.2

Nutanix Foundationは管理者がベアメタルのNutanixクラスタのブートストラップ、展開、構成の最初から最後までを最小限の入力と時間で行うためのツールです。Foundationは自動的にIPMIを構成し、ハイパーバイザとノードを展開/構成し、NutanixコントローラーVMを構成して、選択したノードにクラスタを作成します。今回のFoundationのリリースには以下が含まれます:

  1. IntelのBroadwellのサポート
  2. Nutanix Xpressファミリのサポート
  3. エラーレポートの改善
  4. CVMのサイズの自動構成

分散ストレージファブリック(DFS)

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

Acropolisファイルサービス(もしくはAFS)はDSFにネイティブに統合されたコンポーネントで、Windowsファイルサーバ仮想マシンや外部のNetAppやEMC IsilonなどのNAS装置をを設置する必要をなくします。AOS 4.7では、AFSはノードあたり1千万以上のファイル/ディレクトリのファイルサーバをサポートできるように最適化され、NTACLやファイル属性へのメタデータアクセスへのレイテンシを改善しました。Nutanix AFSの小さな3ノードクラスタ構成でも最大で4千5百万のファイル/ディレクトリのファイルサーバとして拡張することが出来ます。(AFSはまだTech Previewです)

Acropolisファイルサービス(TRIMのサポート)

TRIMのサポートはファイルシステムにとってはその下のストレージレイヤにどのブロックがからであるということを通知するメカニズムです。AFSはNDFS上で動作し、NDFSはストレージの割当を行います。TRIMは空きブロック情報をStargateへ送信し、ストレージの空きと利用状況の最新情報を通知します。(AFSはまだTech Previewです)

[フルスクリーンモード 1080Pで見てください]

Acropolisブロックサービス(またはABS)

Acropolisブロックサービスは高可用性のある、スケーラブルな高パフォーマンスのiSCSIブロックストレージをゲストへ提供します。ABSはAOS 4.5リリース以降利用可能になったAcropolis ヴォリュームグループサービス上に構成されています。ボリュームグループはブロックストレージを提供します。これはNFSデータストアをサポートしないエンタープライズアプリケーション、または展開されたインスタンスに対して「共有の」ブロックストレージが必要なアプリケーションにとってとても重要です。利用の事例として: ESXi上のMicrosoft Exchange、Windows 2008のゲストクラスタリング、Microsoft SQL 2008のクラスタリング、Racle RACなどが上げられます。

AOS 4.5と4.6のヴォリュームグループでは仮想マシンのみがゲストとしてサポートされていましたが、4.7のABSでは物理サーバにも対応されました。ABSを有効にすると仮想ディスクがiSCSI LUNとして物理、又は仮想のゲストに見えるようになります。

ABSでベアメタルのワークロードが効率的にNutanixをストレージソリューションとして利用する事が可能になり、一方でNutanixはハイパーコンバージドのワークロードのためにも使うことが出来ます。ABSは組織がハイパーコンバージェンスを利用しながら、もしも既存のインフラストラクチャに置き換えが必要のない物があればそれも利用するということを簡単にします。従来型からハイパーコンバージェンスへの架け橋としての役割も果たすのです。

ABSの特徴 :

  • ノード障害時もシームレスなReadとWriteを実現する高可用性
  • ワールドワイドにユニークなiSCSIターゲット名をエクスポート
  • ターゲット名は再起動、アップグレード、スナップショット、クローンで不変
  • 複数のゲストでターゲットを共有可能
  • 単一ヴォリュームグループでも負荷を拡張可能
  • ターゲットとCVMノードのアフィニティ
  • iSCSI MPIOクラスタのシームレスなアップグレード

AOS4.7のABSにはクラスタ内のノードのiSCSIターゲットに対して、ハッシュ関数による負荷分散が実装されています。そして、AsterixリリースのABSではそれぞれのノードのリソースの状況を加味した負荷分散も提供される予定です。負荷分散はiSCSIセッションが確立した際に実施されます。例えばiSCSIのイニシエータからターゲットにログインする間です。iSCSIマスタが適切なCVMにログインをリダイレクトします。iSCSIクライアントでもノードを負荷分散して構成することが可能で、そのiSCSIのログインはその状態が健全であるかぎりは選択したノードへとリダイレクトされます。

Fig004

Fig005

AHV ダイナミックスケジューリング(総合的なDRS)

Fig006システム管理者であればDRSのコンセプトはよくご存知でしょう。DRSはコンピューティングのワークロードと仮想環境で利用可能なリソースのバランスを取ります。ー そしてDRSは今日の仮想化スタックのほとんど一部といえるようになっています。DRSはキャパシティプランニングと密接に関連していますーキャパシティプランニングは大抵は長期の展望のことを指しますが、DRSでの最適化はキャパシティに制約がある環境において、もっと短い時間の中で行われます。

AHVダイナミックスケジューリングは既存のDRSの実装と大きな差はないように最初は見えます。ですが、古くからのソリューションと違い、Nutanixではコンピューティング、メモリ、ストレージを考慮に入れ、仮想マシンの初期配置やその後の最適な配置にも利用します。AHVのDRSでは、スタックの単一の包括的なビューの中でアプリケーションや仮想マシンの事前、そして事後のサイジングの推奨も提供できるようになる見込みです。

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

Acropolis コンテナサービス

Fig007_2

AWSによってクラウドのムーブメントにオンデマンド、自動化されたインフラストラクチャとアジャイルでの開発手法がもたらされました。新しいアプリケーションのアーキテクチャ、例えばマイクロサービスやユニカーネルの幕が開こうとしています。そして、運用者と開発者の垣根も消えはじめており、DevOpsの文化が生まれました。

今や、Dockerが生まれ、それを使うことへの抵抗もなくなってきました ー コンテナは古くからありますが、Dockerはアプリケーション環境全体ー開発コード、依存関係、パッケージなど不変のオブジェクトとしてキャプチャし、コンテナとして積みこむことでーにアプリケーションコンテナを利用できるという気づきをもたらしました。これがDockerによるコアイノベーションで、以下の2つの大きなメリットを提供します:

  1. 環境間の移行(開発、QA、ステージング、稼働準備)をしっかりとコントロールすることで、開発パイプラインの一元化、自動化をより簡単にします。
  2. Docker化されたアプリケーションは自身で全てを含むので、アプリケーションの異なる環境でのモビリティを(異なるクラウドであったとしても)非常に簡単なものになります。

コンテナは一時的にしか利用されないことを前提としています。ですから、コンテナ内のファイルはコンテナが停止後は利用できません。しかし、多くのアプリケーションは永続的なユーザーセッションのアクティビティを動作させる要件を持っています。つまり、アプリケーションをある面ではステートフルにしなくてはならないのです。Dockerのオフィシャルリポジトリを少し除いてみると、どんなアプリケーションがよくコンテナ化されたストレージ要件で利用されているのかが分かります。

Fig009

Fig008

Fig010

現在市場にあるコンテナの永続性を実現するものはセットアップも利用するにも複雑で、多くの組織は仮想マシンを利用し続けて状態の永続性を確保しています。エンタープライズはコンテナのための永続ストレージを求めており、Docker化されたワークロードと従来型のワークロードの両方を同じインフラストラクチャ上で管理したいと考えています。

Nutanixのネイティブのコンテナ管理はインフラストラクチャの提供の中でシームレスな継続的なインテグレーション、デリバリ、コンテナ-as-a-サービス、マイクロサービス、ハイブリッドクラウドやマルチクラウドソリューションを提供します。

・・・さらにもっと重要な事は、コンテナをNutanixの永続ヴォリュームを用いて利用していたとしても、スナップショット、クローン、レプリケーションなどのエンタープライズストレージの機能を活用することが出来るのです。

どのように動くのか?

Docker Machine Driver ー Docker MachineはDockerホストをコンピュータ、クラウドプロバイダー、またはご自身のデータセンタ上に作成するための展開ツールです。サーバを作成し、Docker Engineをその上にインストールし、そしてDockerクライアントがそれぞれと通信できるように構成を行います。Docker Machineはエンドユーザ(管理者と開発者の両方)にDocker engineをAHVの仮想マシン上に展開し、その仮想マシンをdocker-machine cliコマンドでの管理を実現します。

Docker Volume Plugin ー Docker Engine Volume PluginはDocker Engineの展開を外部ストレージシステムと統合し、データヴォリュームを単一のEngineホストのライフタイムを超えて利用することを実現します。

Docker Datacenter(UCP)はコンテナのためのDockerの管理ソリューションで、native volume pluginが利用できます。ユーザーはドライバを選択して、Nutanix DSFを活用して、永続ストレージを利用することが可能です。AOS4.7ではCLI経由のコンテナ管理しか利用はできませんが、「Asterix」では完全にPrismに統合されます。

[HDでビデオを見てください]

Nutanix上でのCPS Standard(プロジェクト La Jolla)

Fig013

Hyper-VのユーザはNutanix上で、Windows Azure Packを利用する必要があります。Windows Azure PackはMicrosoft AzureテクノロジーをMicrosoft顧客向けに集約したものです。Windowsサーバ、System Center、そしてSQLサーバと統合されており、セルフサービスポータルと仮想マシンホスティング(IaaS)、データベース-as-a-Service(DBaaS)、スケーラブルなWebアプリケーションホスティング(PaaS)などのクラウドサービスを提供します。

現在、Windows Azure Packの初期化の手順はマニュアルで、面倒、そして、多くの場合失敗しがちです。真のNutanix流では、あらゆるハイパーバイザーとクラウドはワンクリック相当のオプションで展開、構成され、シームレスにソリューションとして提供されます。

Microsoftの友人たちと仕事ができてとても嬉しいです。CPU StandardはMicrosoftとのパートナーシッププロジェクトでWindows Azure Packの展開をシンプルなターンキーソリューションにすることを目的としています。NutanixはHyper-Vを工場出荷時にCPS Standardとともにシステムに組み込んで、Prismとネイティブに統合して出荷します。

ここに公式のプレスリリース(NutanixはMicrosoftとのリレーションシップを共にハイブリッドクラウドソリューションを開発することで拡大)があります。

我々はAzure Packが数時間で展開できるように、できるかぎりシームレスにしました。CPS Standardは顧客のプライベートクラウド(Azure管理者とテナントポータル)にMicrosoft Azureとなじようなエクスペリエンスを提供します。そしてもちろん、パブリックのAzureポータルの運用分析やサイト復旧などの機能を利用することが可能です。

[イメージをクリックして大きく]

Fig011

Fig012

Prism

Prismでのネットワーク可視化

Fig006

御存知の通り、もしネットワークの設定をミスしたら、アプリケーションの仮想マシンは動きを止め、そのパフォーマンスも著しく低下することになります。例えば、VLANを校正ミスすると、同一アプリケーションの仮想マシンはお互いに通信ができなくなります。ネットワークの構成がおかしい場合、例えば、MTUが違ったり、リンク速度が異なったりしているとパケットロスが多く発生することでパフォーマンスの劣化につながります。

ネットワークの問題のトラブルシューティングを難しくしているものは、あらゆるスイッチの構成ミスやネットワークパスが問題につながるからです。そして、トラブルシューティングするために管理者はネットワーク構成をすべて見ていかなくてはなりません。

これを解決しようとしているのがまさにネットワーク可視化です。

ネットワーク可視化はネットワーク全体を俯瞰することを実現します。それぞれの仮想マシンから、仮想化スイッチ、それに接続されているホストの物理NICそしてTORスイッチなどです。ネットワークのそれぞれの機器の構成、例えばVLAN構成もわかりやすく、使いやすいインターフェイスに表示されます。そして、システム管理者はネットワークを簡単に絞り込むことが出来ます。例えばユーザーやプロジェクトやホストなどのグループ情報で絞り込むことが出来ます。

NutanixはLLDPを利用してネットワークトポロジを検知、検証します。また、ESXiの分散仮想スイッチと最新ヴァージョンの標準仮想スイッチをサポートしています。スイッチからの構成情報の検知にはSNMPを利用します。例えば、ネットワークの情報とともに各ポートのVLANの情報はSNMPによって収集されます。

トポロジが仮想と物理のネットワーク要素からの構成と状態情報で確定すれば、Nutanixはその利用しやすいインターフェイス上に情報を表示します。

[クリックで大きく]

Fig014

What-If 分析

Fig006

What-If分析は指定したワークロードが時とともに将来どのように変化していくのかを見ていく手法です。既存の仮想マシンを指定することが出来、例えば既存の仮想マシンのインスタンスを10つ追加するというようなことが出来ます。また、パーセントで既存のワークロードが変化するということを指定することも出来ます。これによって、既存のワークロードの拡張と縮退をサポートすること出来ます。また、事前に定義された一般的なワークロードを指定することも出来ます。

例を挙げると、ビジネスクリティカルな、中規模サイズの、OLTPのSQLサーバワークロードと言う形での指定ができ、what-ifツールがそのワークロードを見積もります。wat-if分析ツールは正確なサイジングをもたらします。というのも、ツール自身がNutanixサイザーと統合されており、サイザーは我々が最初に構成を推薦する際に利用しているものだからです。ですから、what-if分析ツールは様々な事前構成されたSQLサーバ、VDI、Splunk、そしてXenAppなどのワークロードを取り扱うことが出来ます。

AOS 4.6は既にランウェイコンポーネントビューを提供しており、キャパシティプランニングのアルゴリズムで様々なリソースの行く末を予測したり、クラスタ全体の行く末を予測したりすることに利用されています。これをベースとして、what-if分析は管理者がノードを追加すべき日付とそのノードの推奨構成を提示します。これによって長期的な目的にそって常に環境を変化させていくことが可能です。

what-if分析の最後のコンポーネントはノードの追加/削除の画面です。ノードを追加/削除するにつれ、自動的に目的地へのランウェイは更新されます。ワークロードとハードウェアを追加すると、システムはその推奨を示します。何が表示されていたとしても、what-if分析のUIでは、その推奨を微調整や最適化が出来るようになっています。例えば、ハードウェアの利用開始日を調整して、様々なハードウェアの推奨事項を予算の都合と調整したり、同様に、ワークロードの利用開始日を調整したり、特定の優先順位の低いワークロードを後からにしたりなど。最適なプランが表示されるまで、ワークロードやハードウェアのプランを最適化し続けることが出来ます。

[クリックして大きく]

Fig015

属性ブラウザの改善(カスタムフォーカス、ページサイズ、シフトセレクト)

Fig016

Fig017

Fig018

Nutanix セルフサービス

Fig006_2

AOS 4.6では、AHVハイパーバイザーとOpenStackの完全な統合とサポートが登場しました。このためにNova、Cinder、GlanceそしてNeutronのドライバーが提供されています。OpenStackは大きく市場に浸透しており、Nutanixと足並みを揃えて動かすことが出来ますが、OpenStackはネイティブなNutanixのソリューションではなく、多くのNutanixの先進的な能力を活かすことが出来ません。というのも、OpenStackはあらゆるインフラストラクチャをターゲットとして設計されているからです。

NutanixセルフサービスはPrism Proに統合されており、ITへリソース、ポリシーへのアクセス、そしてセキュアなテナントベースのアクセスを提供します。セルフサービスポータルはITとの連携なくテナント自身でのアプリケーションの展開が実現します(仮想マシン、コンテナ、プライベートクラウド、ハイブリッドクラウド)、そして組織はAWSを利用しているかのようなエクスペリエンスを開発者やテナントへ提供することができるのです。

Fig019

管理ポータル

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

テナントポータル

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


AOS 4.7に含まれるその他の機能 :

  • Pulse リマインダ
  • AHVアフィニティ/アンチアフィニティルール
  • 1クリック LSI HBAアップグレード
  • 要素ブラウザの改善(カスタムフォーカス、ページサイズ、シフトセレクト)

これが次の2つのリリースで我々が盛り込もうとしているとても長いリストです。ですが、これで全てではありません。11月の.NEXT Europeで我々は「Asterix」関連のアナウンスを行う予定で、それはまたあなたの心に響くことでしょう。お約束しますよ! 乞うご期待!

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

Nutanix記事はPernixDataの買収関連を除くと最初の記事でした。どの記事が良いかいろいろと考えた末に、この「ネットワールドらぼ」にふさわしい、技術情報満載の記事を翻訳することにしました。原文の著者はVMwareのCTOオフィスで様々なVDI関連記事を書いていた、Andreさんです。一度食事をご一緒したことも有りますが、非常に聡明な方で、我々にわかりやすく、インパクトが有る言い方はどういう言葉か、伸長に選びながらお話してくれていたのを思い出します。

いろいろな経緯があってようやく一緒に仕事をできるようになりましたが、Nutanixの目指す「エンタープライズクラウド」 2バージョン分とはいえさすがのボリュームです。まさに「クラウドのように」どんどん機能が追加されていく、、、こうでなければ今後生き残れないのかもしれません。

11月にまた更新されるようなので、是非期待してお待ち下さい。

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/09/01

大志が共有出来ているということ (Nutanix社によるPernixData買収関連記事)

ネットワールドはPernixData社のNutanix社への合流という経緯もあり、この9月1日より、Nutanix社の国内ディストリビューターとしての活動を開始いたします!

と、言うことで、引き続き、Nutanix社の情報、およびPernixData(だったもの)の行方についても本ブログにて公開してゆきますので、今後もお楽しみください。

本記事はNutanix社のオフィシャルブログの記事:Shared Ambitionをネットワールドが翻訳したものです。著作者はChief Product & Development OfficerのSunil Potti氏です。

このブログはNutanixがPernixDataCalm.ioと合流し、1つの会社となるという素晴らしいニュースについてのものです。

まずはNutanixとその大志についてお話させてください。これまでに働いてきて思うことは、私の全てのキャリアの中の会社の中でNutanixは間違いなくもっとも優れた会社、チームであるということです。以前の会社でもうまくまとまったチームと働くという経験はしてきましたが、毎朝起きる度に何故こんな気分なんだろうと自分自身に語りかけることはそう多くはありませんでした。他の多くの私の働いてきた会社のように、Nutanixは革新的なテクノロジーを生み出し、傑出した人材を育てるというコミットメントは同じです。何が違うのでしょうか? 何が私を毎日の仕事に駆り立てるのでしょうか? 以下の3つに分類されるのではないでしょうか :

一つ目には我々は調和と共感の正しいバランスをもたらす反乱者のチームであるということです。熱烈なまでに問題が発生した際にはお客様にフォーカスしたり、競合他社が我々の機能に圧力をかけてきた際には忠実にその任務をこなしたり、揺るぎない決断で厳しい状況でも諦めなかったりと様々ですが、こうしたやり方の積み上げが我々そのものを構成しています。

二つ目には我々はITの提供の方法、ビジネスがアプリケーションを利用する方法を完全に再想像しようという大きなビジョンによって結ばれています。我々のエンタープライズクラウドへの旅路では、ITはパブリックとプライベートのクラウドの融合の証人になるはずですが、非常に大きな変化が起こりつつ有ります。

そして、最後に、我々は「本能的な感」とも呼べるものを共有しています。ですから、競合が起きた際には常に心の奥にチームが一緒におり、またチームが負けそうなときには倍の共感を得ることが出来ます。

このユニークな組み合わせが我々をここまでの急成長に導き、さらに組織全体の強い安定性と結びつきを産んだのです。

しかし、マーケットにおいて常に勝ち続けるためには、成長に合わせて我々の能力を傑出させ、更にチームにこの大志を共有し続けなければなりません。この独特な空気に合う人を採用するのは非常に難しく、さらにそれがグループになっており、コアを幾つものコードベースに分けたり、水泳プールのレーンを行儀の悪く泳ぐような形にしなくても済むようなテクノロジーを持っているとなると、更に難しくなります。PernixDataとCalm.ioにおいて、我々はそれを2つも見つけることが出来たのです。

PernixData

PernixDataとNutanixはアーキテクチャ上の設計思想を共有しています。それは次世代のデータセンタファブリックは可能な限り高速なパフォーマンスと柔軟性の提供、コスト効率のよい拡張性を実現するためにデータとアプリケーションが近接していなければならないというものです。サーバサイドのストレージテクノロジーはIntelのNVMeやストレージクラスメモリの後押しで100倍も高速になろうとしています。一方で我々はアプリケーションとデータを同一のサーバで動作させていますので、さらにそれらをCPUの側へと押しこみ、ワークロードを様々なクラウドコンピューティング環境を超えて動かすための道筋の提供や、そしてもちろんハイパーバイザに依存しない環境も維持しなくてはなりません。

この4年以上にもわたって、Pernixは非常に強力なスケールアウト型のデータ高速化技術を構築してきました。更に重要な事に、彼らは全てのIOをデータの一貫性に影響を与えることなく「見る」ことが出来ます。これは我々にオンラインのアプリケーションのマイグレーションをNutanixがいつも言っているとおり、ワンクリックだけで成功させるための貴重な地盤となります。

2つのチームは共にこの透過的なIOの視認性を利用して集めたワークロードについてのインテリジェンスと先進的な分析機能をあらゆるワークロード、あらゆるクラウド環境へ提供していく事になります。

Calm.io

Calm.ioはSequoia Capitalが出資するスタートアップでアプリケーションについての深い知見とインフラストラクチャ展開のためのアプリケーションのワークフローのビジュアル設計を行っている会社です。8~9ヶ月もの求婚を経て、我々はCalm.ioの素晴らしさを深く理解することにしました。

Nutanixはその全てがトップダウン設計からインフラストラクチャをインビジブルに変えることです。Prismのデザインはインフラストラクチャのヒューマン化です。我々がITの日常から極端にいろいろなものを取り去ったその方法は、確実に動作、そしてシームレスにワンクリックアップグレードなどの優れた機能を作成することです。我々はCalmのチームがトップダウンのアプローチを変えずにこのインフラストラクチャをインビジブルにする機能をアプリケーションのオーケストレーションにまで開放し、更にその能力を拡張してくれると理解しました。Calmの単一コンソールでの管理はAWS、Azure、Docker、オンプレミスのウェブスケールインフラストラクチャ全てにわたってのアプリケーションの設計とオーケストレーションの手助けになります。優雅にNutanixに彼らのストーリーが統合された際には電球が頭の上で光るのを見ることになるでしょう。

ClamがPrismに統合され、お客様はついに適切なワークロードに対して、適切なクラウドを選択するということが出来るようになり、Nutanixを気に入っていただいたのと全く同じ、シンプルで苦痛のない、一貫したエクスペリエンスでシームレスにアプリケーションの移行が行えるようになるでしょう。

大志の共有

.NEXT 2016で明らかにしてから、我々はエンタープライズクラウドのビジョンの提供へと着実に歩みを進めています。それはエンタープライズのお客様に最高のパブリックとプライベートのクラウドを提供するというものです。そしてこの2つの会社で、我々は優れたテクノロジーを生み出し、それを先に進めようという気概を持った素晴らしい人々からなるチームに出会うことが出来ました。それぞれのチームは既にテクノロジーを持ち、それだけでも素晴らしいものです。今後は一緒に新しい想像力に触発され、次なる舞台を作り上げ、不可能とも思える夢に挑戦していきます。

PernixDataとClam.ioを迎えることを誇らしく思います。2社のそっくりの心、精神、希望をもったチームをファミリーに迎え、次に何が起こるのか待ちきれません。

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