Find Communities by: Category | Product

今年のEMC Worldにおいて vVNX が正式リリースとなりました。

 

Project Libertyとして昨年のEMC Worldでプレアナウンスされたものですが、

プロジェクトが1年の熟成を経てプロダクトになりました。

 

header-image-vvnx.png

 

vVNXは"Virtual VNX" と読めますが、コードは現行のVNXではなくVNXe2ベース(Unityアーキテクチャー)となっています。

ロゴにある通り、VMware(ESXi)上の仮想アプライアンスとして展開します。

主なストレージプロトコルとしてCIFS/NFSに加えiSCSIが利用できますので、Unifiedストレージを実現できます。

 

 

今回のリリースは「vVNX Community Edition」という位置づけで、サポートはCommunity(ECN)で行います。

EMC VNX Community

 

日本の皆さまへの朗報として 日本語コミュニティ でも質問を受け付けますので、英語は苦手という方も安心です。

ストレージシステム

 

主用途はテストや開発環境となっていて、Production(本番環境)での利用は今後サポート予定となっています。

将来はクラウドやコンバージドインフラ上での展開の他、レプリケーション・ターゲットなど、幅広い応用が期待できます。

 

下図はVirtualGeekより抜粋(VMAXと組込NASは実装済)

vVNX_03.jpg

 

 

ダウンロードや関連資料はこちらから。環境要件やインストール方法など充実しているので不便は感じないと思います。

http://www.emc.com/products-solutions/trial-software-download/vvnx.htm

 

デモ動画:POOL,LUN,Filesystem,Share作成など3分程度で紹介しています。

https://www.youtube.com/watch?t=15&v=HFr1QpHMtXI

 

ライセンス入手はこちら。(評価ライセンスの入力が必要です)

https://community.emc.com/docs/DOC-43352

 

 

サポートする機能はVNXe3200との比較が役立ちます。(シングルSP、FCなし)

vVNX_02b.jpg

 

 

起動した画面はこちら。 現バージョンではOE 3.1.2 となっています。

 

vVNX_0514b.jpg



EMC製品全般でソフトウェア化が進み「試してみる」ハードルが随分と下がりました。

vVNX 是非お試し下さい!


EMC World 2015の中で、さりげなくVMAX3のエンハンスが発表されています。

VMAX3では、Data Domainに2次バックアップを20倍も高速化できる、ProtectPointという新しい連携ソリューションが提供されています。

EMC_World_2015_VMAX3_News_1.jpg

今回新しく発表されたData Domainの最新モデルDD9500も当然サポートされる予定です。VMAX3と同じで、DataDomainの見た目もかっこいいですよね。

 

VMAX3の発表では、既存EMC製品とのより密な統合を目指していることが見て取れます。既にNASの機能はNASヘッド(ゲートウェイ)がVMAX3の中に取り込まれていますが、更にXtremIOやクラウドとの連携が強化される予定です。

EMC_World_2015_VMAX3_News_2.jpg

VMAX3とAll FlashストレージのXtremIOの連携は、お客様に更なる選択肢を提供できる点でメリットがあります。SRDFやTimeFinderといった、高い実績を持つ高度なレプリケーション機能がAll Flashストレージでも利用でき、お互いの製品が持つ良いところが合わさり、大きな相乗効果が期待できます。

 

ステージ上の実機を使って、具体的に統合された製品の中身が披露されていました。

EMC_World_2015_VMAX3_News_3.jpg

VMAX3のキャビネットの中に、XtremIOとCloudArrayというアプライアンスも一緒に入っています。

 

CloudArrayは、その名の通りクラウドへデータを安全に移動できる製品です(EMCのECSなどの大容量な低コストストレージとも連携でき、日本でも単体で製品販売が開始されています)。

このCloudArrayの機能を自動階層化の一部に取り込み、ほとんどアクセスの無いデータを安価なストレージへ自動的に移動できます。

EMC_World_2015_VMAX3_News_4.jpg

単にアーカイブしているのではなく、アクティブな領域として階層の一部に組み込まれますので、必要な時にはクラウドからアクセスしてデータをすぐに取り出せます。このソリューションをうまく活用できると、一時的に搭載容量以上のストレージ容量が必要になるケースにおいて、ディスクを買わなくても良くなりそうです。

今までは、容量が不足するとベンダーから必要容量分のディスクを購入し、使わなくなった後は無駄になっていました。

これからは、一時的に必要な容量はCloudArrayの機能を有効活用してクラウドから調達し、必要無くなればすぐに容量を解放してコストがかからない状態にできます。

 

無駄な投資が回避できるのは、クラウドならではのメリットですよね!

 

ユーザ主導でクラウドとの容量配分を制御できる様になれば、ストレージ環境の自由度は今と比べ物にならない程に高まります。

運用する側としても、容量枯渇や予算化に悩む要素が減るので、間違いなく運用は楽になっていくでしょう。ユースケース含め、詳細は今後出て来る予定ですので是非ご期待ください。

以下LinkのEMCジャパンのサイトで公式にアナウンスされていますが、VMAX3は今年後半に目を見張る様な進化を続けて行く予定です。今後もEMCのフラグシップVMAX3からは目が離せないですね。

http://japan.emc.com/about/news/press/japan/2015/20150512-2.htm

こんにちは、SDS製品担当の平原です。

 

前回のViPR Controllerオープンソース化に続いて、もう1つとてもホットなニュースがありました。それはIAサーバでSoftware-Defined SANを実現するソフトウェア製品「ScaleIO」の無償版ダウンロードの公開です。

 

ScaleIOは多くのお客様が既に保有している遊休サーバを活用し、簡単にSANストレージ環境を構築できることから、これまでも非常に多くのお問い合わせや評価のご依頼をいただいておりました。この無償版ダウンロードによって、お客様は思い立ったときに、機能や期間制限を気にすることなく自由に評価いただけるようになります。また、製品が満足のいくものであれば、有償版のライセンスを購入いただくことで、現在の環境をそのまま本番環境への移行も可能です。もちろん、無償版にはないテクニカルサポートのサービスも提供されます。

fig7.png

 

現時点での発表内容は以下のとおりです。(公開時点で予告なく変更されることもあるのでご注意ください)

  • 容量無制限にて提供
  • 使用期間の制限なし
  • 提供バージョンは公開時点の最新版
  • サポートはEMC ScaleIO Communityを利用(EMCの有料構築・保守サービスはなし)
  • Non-production use(商用環境での使用は不可)

 

ScaleIOの無償版ダウンロードは、US時間で529日開始を予定していますが、メールアドレスを登録いただければ、情報をいち早くみなさまにお届けします。それまでは、みなさんの会社で活用できそうな休眠サーバを探してみて、ダウンロード公開の日まで指折り数えて待っていてください!

 

関連リンク

ScaleIO無償版ダウンロードサイト

http://www.emc.com/products-solutions/trial-software-download/scaleio.htm

 

ECN (EMC Community Network) ScaleIOサイト

https://community.emc.com/community/products/scaleio

今年のEMC Worldにおいて DSSD がTechプレビューでお披露目となりました!

これをベースにDSSDの製品概要を紹介します。


*** この記事はTech Previewベースのため、正式リリース時の内容とは異なる可能性があります ***

 

D5.png


DSSDは「ラックスケール・フラッシュ」という位置づけで、大量データを高速に処理するための製品です。

サーバのPCIバスをエクステンドし、DSSDと直結するのが特長です。

 

外部ストレージのインターフェース(FC,iSCSI等)はCPUやメモリ環境から見ると、大きなオーバーヘッドがありましたが、PCIバス直結により低遅延を実現し、外部アプライアンスとすることで大容量化とデータ共有を可能にしています。


DSSD D5 製品外観(5Uのラックマウント)

IMG_1509.JPG.jpg

 

 

DSSDはDRAMメモリとAFA(外部ストレージ)の間を狙っています。

新たなカテゴリーのゲームチェンジプロダクトということができます。

 

DSSD_chad_201405.png

 

 

DSSD D5製品概要

5Uラックマウント

・デュアルコントローラ

IOポート PCIe3.0 48ポート/コントローラ

・接続サーバmax 48

・フラッシュモジュールmax 36枚(144TB raw

・電源、ファン冗長化(ホットプラグ)



フラッシュモジュール(2TBと4TBのカスタム仕様)

 

DSSD_card1.JPG.jpg DSSD_card2.JPG.jpg

 

実機を見る機会があったので動画で紹介!

 

 

サーバには専用のPCIカードを使用しDSSDと接続します。

OSからはAPPに応じたプラグイン(ドライバ)が提供される予定です。

 

キーノートセッションではHadoop によるDASDSSDの性能比較を行うデモを披露しました。

DASはノード40HDFSを構成し、DSSDはノード14での比較です。

50TBの処理を同時スタート!

 

DSSD_chad_1c.jpg

 

DSSDが終了するころに、DAS2%の進行状況となっています。

 

DSSD_chad_2c.jpg

 

 

結果として50TBHadoop処理にDSSD22秒、DAS30分以上となりました。

処理が速いだけでなく、ノード数も削減できることがわかります。


ビッグデータ系の処理におけるDSSDの効果が期待できます。

HDFSのストレージとしてIsilonは定番ですが、メモリに近い処理速度がDSSDのメリットとなります。

 

用途は、大量データの高速処理を要求されるもの全てがターゲットです。

正式リリースはまだ先ですが、Hadoop、HPC、ゲノム・医療分野など高速化に興味のあるアプリケーションがあればEMC担当者まで!


DSSD_Biz.jpg

EMC Day 3: ScaleIO – Unleashed for the world!

僕は情報を出し惜しむ気なんてさらさらないんだ。ビッグニュースを伝えよう、ScaleIOは自由に無料で制限なくダウンロードして利用することが出来る。

 

もう一回言おう:

  • 業界で最高の、
  • 最も高性能な、
  • 最もスケーラブルである、
  • 最も広範囲に適用可能な、
  • 最も多機能な、
  • オープンなソフトウェアデファインドストレージ(SDS)のトランザクショナル ストレージ スタックが...

 

...自由に無料で制限なくダウンロードして利用することが出来る。

 

ワオッ

 

何で「ワオッ」かって?

 

ScaleIOは多分EMCが持っている兵器の中で最も破壊的なテクノロジーだ、パフォーマンスでもスケーリングでも我々の持つ他の製品を凌駕する力を持っている、しかも全く異なる経済モデルでだ(ソフトウェアであり、みんなが持っているハードウェアを利用して―そして少しずつ増やしていくという融通がきくんだ)。これは革新的だから破壊的だというだけではない。ストレージエコシステムのとてつもなく大きな「基礎」を破壊するんだ。

 

さらに、これは我々が持っている唯一のSDSデータプレーンというわけではないのだけれども―ScaleIOは我々の(そして業界の)儲けの源泉、様々な用途で利用可能なトランザクショナルブロックストレージマーケット、を奪う可能性があるものなのだ。それとは別のものとして、新たな第3のプラットフォームや非構造データの利用例なんかの急増に応えるECSソフトウェア(Object/HDFSをカバーするSDSスタック)がある。

 

うーん...我々はある特定のワークロードを孤立化させることによって、そのビジネスを守ることが出来るかもしれない...この考え方が上手くいくか確認してみよう:

 

ScaleIO―これがvSphereをサポートするかって?答えはYesだ。Hyper-V、KVM、Openstack Cinderとの統合は?この答えもYes。一般的なLinuxでの利用(Redhat、SLES、CentOS、そしてもうすぐUbuntu TLSリリース版とCore OS)、Yes。Oracleや他のデータベース、Yes―そしてそのパフォーマンスに圧倒されるはずだ。ハイパーコンバージドが欲しいって?もちろんYesだ。2レイヤのSDS(ブレードで利用される密度の高いラックマントのストレージ/IOpsプールで、個別にスケールアウトするようなもの)が欲しい?Yes。

 

何がそんなにも素晴らしいものにしてるのかって、破壊的になる可能性を持ったものが無料で自由に利用できるってことはとても大胆でとんでもない動きなんだ―そしてそれこそがこの素晴らしさをつくっている

 

これはまた我々の新たに出現してきている知的財産に関する明確な理解の表れなんだ:もしもそれについて知る唯一の方法がセールスの人と話をして、要約を得て、マーケティング施策をみてから大きな金額にサインをすることだったら...まぁその場合にはお客様は正直言って自由で簡単に使える二流のスタックを選択してしまう傾向がある。

 

そして―EMCとしてもこのリスクを持ってるんだけど―これは我々の独りよがりとかじゃない:-) 我々は確実に言うことが出来る、ScaleIOのコア知的財産は素晴らしく、売り物になる。

 

(もちろん)無料版にサポートはつかないけど(Fedora/RHELみたいにコミュニティを利用したベストエフォートでのサポートのみだ)―みんながScaleIOを大好きになってくれてエンタープライズレベルのフルサポート付きで購入をしてくれるようになるということに自信がある。ところで―あまりStupidにはなってもらいたくないんだが―僕は個人的に商用環境において明確なサポートモデルを持っていないどんなソフトウェアもオープンソースも利用することはないだろう:-)

 

現状では、白黒をつけるというよりも普通に言って(とはいえいつも言っているようにネガティブにはならずに!):

  • トランザクショナルな使い方においてはどんな要素においてもScaleIOはCephに勝る:利用の容易さ、パフォーマンス、遅延、障害時の振る舞い
  • スケールアウト時のパフォーマンス、全体的なスケーラビリティ、遅延、復元力においてScaleIOはNDFS(Nutanixのストレージスタック)を凌駕する
  • ScaleIOはOracleが持つExadataのパフォーマンス結果を打破する
  • VMwareの利用例についてはどうなのだろうか?vSphereだけの利用例を考えるのであれば、VSAN以上にシンプルによりよくvSphereに統合できるものは無い。VSANの制限(クラスターサイズ、ワークロードサポート)とセンターのデザイン(データローカリティなんかだ)は意味があると思うし、もしも将来的に発生しうるすべてのワークロードがvSphere上の仮想マシンにあるのだとしたら、それらは制限にはならないだろう。でも...ScaleIOのパフォーマンスとスケーリングは異次元のものなんだ。もしもオープンなSDSレイヤ(vSphereを含むけどそれだけに制限されないようなもの)、リッチなQoSの仕組み、パーティショニング/マルチテナンシー機能、そして無限大にスケールアウトするような仕組みが必要なら...ScaleIOが欲しくなるはずだ。

 

まだ信じられないって?

 

もう少し読んでみてもらいたい―データを共有するから。さらに弱点もリストしちゃう!どんなベンチマークデータかって?もう入手してるのさ!100万IOpsってすごいと思うかい?じゃあ128ノードクラスターで3千100万IOps(!)って言ったらどう思う あなたが使っているOracle 12c環境って速いと思う? 8ノードのUCS B-seriesが20GBpsの帯域(!)で1000万IOps、そして~700μsのIOWAIT時間っていったらどうだろう。

 

あまり読み進む気が起きないかな?こんな強気なパフォーマンスやスケーリングの話について懐疑的になってる? そうだよね:-) やっぱりダウンロードしてみて自分で調べてみないと。

 

5月29日に、ScaleIO 1.32がここからダウンロード可能になる予定。ScaleIOのコミュニティはここ。是非試してみて。

 

皆がどんな反応をするのか本当に待ちきれない(是非良い/悪い/醜い!なんて意見を共有してほしい)。EMCのグレートなSE(Matt Cowger)が過去にScaleIOを手に入れて、AWSの何百というEC2インスタンス上で走らせて何が出来るのかを見たりしてるんだけど(彼は無限にスケールするって主張は受け入れなかった)。あなただったらどんなことをしてみる?

 

僕は通常マーケ―ティングビデオはそれほど好きではないんだけど、こいつはどれだけ実際にScaleIOが凄いのかってことを上手くまとめてくれてる、かっこいいドラマチックな音楽もつかってね:-) もしも読むのが面倒くさいのなら(そして詳細情報を必要としていないのなら)、このビデオを見て、5/29にソフトウェアをダウンロードしてみてほしい。

 

逆にもっと知りたいって人、ホワイトペーパーを確認したい、素晴らしいデモを見たい、どうやって動いているのかを理解したい(そして弱点も―完璧なものなんてないもんね)、今後はどんな風に進化していくのかを知りたい(今日EMC WorldでScaleIO 2.0について話したよ)なんて人は読み進めてもらいたい!

 

そのコアに持っているもの―ScaleIOの魔法はそのシンプルさにある。デザイン時のコアとなる原則として決めているのはシンプルスケールということだけなんだ(複雑なものは複雑なものの上に出来るんだ―そしてそういうものは最終的にひどいところにたどり着く)。ScaleIOはとてもシンプルだ。

 

このことについていくつか例をださせてもらおう。まずはどうやってScaleIOが動いているのかだ(virtual geekフォロワーのみんなはこれも参照してみてほしい―ScaleIOは"Type III loosely coupled cluster" persistence model)。

 

6a00e552e53bd2883301b8d10d662f970c.pngコアには2つのシンプルなコンポーネントがある―SDS(サーバ)とSDC(クライアント)。

 

SDSはローカルHDD、SDD(persistence/read/write cache)、PCIe NANDデバイス(persistence/read/write cache)を利用して、またローカルホストのRAMをreadキャッシュとして活用する。

 

ユーザは欲しいサーバリソースをどんなに少量でも、どんなに大量でも規定することができる。それでいながらノードは対称性なんかを取る必要はないんだ。

 

SDCは軽量のクライアントで超軽量に設計された特殊なプロトコル(iSCSIじゃない)を利用して、EthernetやIBネットワークを経由していくつものSDSノードとコミュニケーションを行う。

 

第3のコンポーネントとしてマネージメントクラスタ(これはどのノード上でも動作させることが出来る)があり、これはクラスタの管理やスプリットブレインの解決に利用される。マネージメントクラスタはIOパスとは関係がない。その他のスケールアウトするSDSのアーキテクチャでは、時々"centralized mapper"が取られている―これはスケーリングの観点から言ってよろしいものではない。ScaleIOは完全なるdistributed mapモデルを採用している(SDCそれぞれがデータがどこにあるのかを知っているってことだ)。

 

ScaleIOは多種多様な方法で展開をすることが出来る―コンピューティングとストレージを一緒に、全く別個に、もしくはその中間の任意の状態で。

left.pngcenter.pngright.png

 

更に、いつもはやらないことなんだけどアーキテクチャ的な強みと弱みの一覧表を紹介しよう。

 

要素
強み
弱み
ScaleIOはクライアント(SDC)とサーバ(SDS)間に連結がない。
  • フレキシビリティ:ScaleIOはハイパーコンバージドモデル(persistenceのプロバイダーはまたコンシューマにもなる)、もしくは切り離された2階層モデル(コンシューマのプール、persistentのプロバイダプール)で展開することができる。
  • コンピューティング/メモリ/NAND/キャッシュ/HDDを好きなようにスケールさせることができる。
  • クライアントを好きなように展開できる。クライアントのOSはサーバに合わせる必要はない。Windows Hyper-VホストとvSphere ESXホストが一つのScaleIO Linux SDSクラスタにアクセスするようなプールも作成できるだろう。

 

    • ScaleIO SDCはvmkernel、linuxカーネル、windowsカーネルと結合する。
    • サーバを好きなように展開することが出来る。ScaleIO SDSはvmkernel、linuxカーネル、windowsカーネルと結合する。
  • vSphere環境ではSDSはVMkernelに組み込まれない。これは、VSANとは異なりScaleIOはサーバの観点から直接ローカルストレージを利用することが出来ないということを意味している―ESX/VMFSスタック(VMFS/RDMの利用)を利用する必要があるということだ。これはSDSのパフォーマンスに関する考慮ということでは全くない。バージョン1.31とカーネルにロード可能なSDCによってSDCのパフォーマンスは大幅に改良された。しかしそこにSDSのベネフィットはあまりない。正直に言うと、誰かにScaleIOのベンチマーク試験を実施してもらいたい―5/29に簡単に手に入るようになるからね:-)  どちらかというとこれは管理に関する問題なのだろう(SDS VMsのコンフィグレーションやそれらをVMDKやRDMに見せるとか)。これら全てを自動化してシンプルにするためのvCenterプラグインが存在している。
  • 我々の経験上、スケールを必要とするお客様はまぁ問題ないと言ってくれている。スケールが必要なクラウドコンピューティングを利用しているお客様は、物事を広範囲でまとめていく(hyper-converge)というよりも分離していく(disaggregate)という傾向にある。スケールの観点(ここでは数千から数万より多いくらいの仮想マシン/ホストを想定している)では、ESXホストのように業界でスタンダードとなっている一種類のサーバを選ぶ傾向がある―主にコンピューティング/メモリ/ネットワークの集約密度をベースにしているからだ。彼等はシンプルな管理と早くてシンプルなIOパスの実現のためにvmkernel内でSDCを運用している。逆の考え方として、理想的なSDS業界の標準サーバ―、そこではGBとIOpsの集約密度がベースになっていて、ラックマウントが好まれるようなものでは、彼等はSDSノードを利用した効率的なLinuxを実行するだろう。

ScaleIOはデータローカリティがないとてもシンプルでランダムなデータ分布を持っている。

 

ScaleIOはそれぞれのボリュームを中間サイズのスライスに分割し、それらをショットガンのように利用し、クラスタ全体にミラー化も行う。

  • これは中規模の仮想マシンにフォーカスしたエコシステムにおいて「データローカリティは良い」と直感的に思われているものへの反論に見えるかもしれないが、もしもデザインをする際に「スケール」と「仮想マシンだけではない」ということを考えると、以下のことに気が付くだろう:
  • どこにでも弾力性(Elastic)がある。全てのデータがクラスタ全体に分布されているために、ScaleIOは完全に(!)リニアにスケールアウトする。ノード/デバイスを追加すると、パフォーマンスは向上する。以上。それらを取り外すと、パフォーマンス/キャパシティは低下する。シンプルだ。
  • スケールの観点でのパフォーマンスは異常に高い、そして分配可能である、そのために一人のお客様に対して全てを提供することも、分割して提供することも可能だ。
  • 可用性:リビルドにかかる時間は信じられないくらいにとてつもない。データローカリティを持った複雑なモデルとは異なり、100ノードクラスタがあり、その中の一つがくたばってしまった場合なんかでも、リビルドに必要なものを把握するのはとても簡単になっている。また、残っている99全てのホストそれぞれがサブセットとしてではなくリビルドへ参加して処理をする。
  • とてもとても低いレイテンシととてもシンプルなIOパス。IOパスにおける最も長い距離はSDCからSDSへのシングルネットワークスイッチホップで、たいていマイクロ秒レベルの集まりだ。これらのSDSモデルでの書き込みはローカルモデルではないにも関わらず、最低で1ホップなのだ。
  • サービスプロバイダ/クラウド データサービス:いくつかのデータサービスは簡単にできている―これらはWebスケールクラウドではとても重要なことであり、サービスプロバイダでの利用例は簡単である。何を意味してるのかって?言いたいことは:パーティショニング/Tierリング/マルチテナンシーについてだ。ある一つの問題のあるドメインのプールを分離することが簡単に出来るし、リッチなQoSモデルの構築も比較的簡単にできる。スナップショットの方法をつくることなんかもScaleIOが既に持っている機能を使って比較的簡単に出来る。
  • スケールのことを考えると最高に上手く動作するが、小さなクラスタ構成の場合にはそれほどでもない。ScaleIOの最小構成は小さい(3ノード、3ストレージデバイス、OSサポート)のだけれども、ScaleIOはスケールのことを考えた時に初めて輝き始める。8から10ホストで鼻歌を歌う感じで調子が出はじめて、50で歌声に、50を超えてくるとロックスター並の大声で歌いはじめる。100ノードなんか超えた日にはまるでボーイング747が頭の上を200デシベルの騒音をまき散らして飛んでいるくらいの叫び声に聞こえるんじゃないかな:-)
  • もしも全てが1つの仮想マシンで処理されるような場合―ほとんどのIOがローカルで発生、つまり読み込みにネットワークを介したやり取りが発生しなく、ある特定の処理に対して特別なことをするような場合―にはデータローカリティの利点がある。とはいえ逆にデータローカリティに注力するということは一人の消費者が一つのホストのパフォーマンスを独り占め(そしてあるケースでは制限)することであり、そしてそれはまた、クライアントとサーバの仕組みに複雑さを追加することにもなる。
  • データサービスの中にはScaleIOのパフォーマンス最適化―すなわち全体的に分布されたデータの削減サービス群―に対抗するような動作をするものがある。我々の例でいうとXtremIOであり、それは密に接続されたクラスタでメモリを共有するようなモデルを持っている(僕のストレージ種別分類ではType Ⅱ)。とはいっても逆に言えばそれはXtremIOはScaleIO(これはType Ⅲ、緩やかにつながったクラスタ)のように何百ものノードを利用したスケールアウトは絶対にしないことを意味している。データローカリティに関するデザインをする際には、ローカルデータの低減ということを加えることが出来るが、それはまた、そのデザインではScaleIOが実現しているようなスケールもパフォーマンスも期待できない。今日では、ScaleIOのデザインはトランザクショナルワークロード、例えばパフォーマンス、に最適化されている。
ScaleIOはとてもとても軽いクライアントを持っている。SDCとSDS間は常にシングルホップである。
  • 非常に低いクライアントの(メモリ)確保領域とロード。それぞれのSDCはとても小さなインメモリハッシュを管理していて、それによって数MB単位のRAMでPBクラスのデータマッピングを管理することが出来る。
  • ボトルネックとなりうる中央集約的な検索機能がない。すべての検索はローカルメモリで行われとてつもなく高速だ。ScaleIOはアホみたいにスケールアウトする:-)
  • とてもシンプルで低いレイテンシのIPパス。検索のマッピングやクラスタ範囲でのノード間通信に「ホップ」はない。真っ先に思いつくNASスタック(IsilonのOneFSとか)、オブジェクトスタック(ECSソフトウェアやCeph)などとは異なり、書き込みに対してノード間の密なコミュニケーションは必要としない。「erasure coding」や「geo dispersion」なんかも必要ない。オブジェクト/ファイルを分散させる必要がないのだ(ブロックボリュームレベルでスライス化されていて分布されているため)。つまり書き込みはSDC->SDS1+SDS2(ミラー)+ACKという動きをして、読み込みはもっと簡単で:SDC->SDS1となる。とても基本的でとても高速だ。書き込みは通常数ミリ秒程度で、読み込みは約その半分ですむ。
  • データサービスの中には超軽量のクライアントモデルの利用が難しいものがある。重複排除と圧縮をScaleIOそれぞれのSDSノードに追加させることが可能だろうが、クラスタ全体に対する重複排除/圧縮は難しいだろう(SDSだけが何がどこにあるのか知っているので)。VVOLみたいなものも難しい(コンシューマ側にマップするものなので)。クライアントをもっと「ヘビーに」することがいくつかのデータサービスに対しては反する動きになるという事象を見ることが出来る。
ScaleIOは緩やかにつながったSDSスタックであり、何百/何千ものノードにまでスケールする。
  • 「無限、さらにそれを超えて」スケールする。数百ノードレベル?簡単すぎ。スケールに対するアップデート?退屈そうだけど、試してみようか。とりあえず冗談は置いておいて、これが何故ScaleIOを利用するVxRackコンバードインフラストラクチャープロジェクトのコードネームが「Buzz Lightyear」だったかってことなんだ:-)
  • 他のスケールアウトSDSスタックと比較して(似たようなものなんて存在していないくらい)とても、とても、とーーーても高速であり、とても、とても、とーーーっても低レイテンシである一方、ScaleIOには、まだ緩やかなつながり(Type Ⅲ)強固なつながり(Type Ⅱ)のアーキテクチャ固執がある。これがアホみたいにスケールさせることにつながっているのだけれども、それはまたレイテンシが低くても、多くの変動要素があるということで、例えばXtremIOでは強固なつながりのアーキテクチャを採用している(スケールアウトはするが16ノードまで)。XtremIOの強固なつながりで共有メモリを利用するアーキテクチャは、インラインデータ削減や超高速のスナップショットなんかを容易に実現させている。

 

もしもまだこれを読んでくれているのなら、あなたはこう思っているに違いない:「これは素晴らしい」。そうなんだよ。でもこうも考えているはずだ「ちょっと信じられないな...」。だから僕のいう事を聞いているだけじゃなくて、是非ダウンロードして試してみてもらいたい:-)

 

もっと情報はないかって?いくつかのベンチマーク結果なんてどうだろう?これはEMC Worldのbreakoutセッションで利用したデータだ。

 

6a00e552e53bd2883301b8d10d663a970c.png最初の質問は:SDSが一つ参加するたびにどれくらいのパフォーマンスを期待することが出来るのか?

 

答えは、もちろんホストの構成によって様々だ。

 

ここでは、UCS C240M3(とても新しいソリッドサーバだけどまぁ特に特別なものではないやつだ)の一つのSDSノードを使ってみた。

 

「NULL」デバイスは変数としてストレージサブシステムを取り除くことが出来る、つまり特定のホストに対する上限まで利用が出来るようになる、このケースの場合約200K reads/sec と90 writes/secだ。

 

このNullデバイスの例は当然のことだけどその特定ホストの理論上の最大値であって、実際のスループットはIOデバイスそのものの機能による。それがPCIeフラッシュドライブだろうが、SSDだろうが、HDDだろうがだ。オールフラッシュアレイは全てのIOがNAND上にあると仮定して、ライトアンプリフィケーション、ガーベジコレクション、そして摩耗度レベルなんかを最少にするようにデザインされる。ちなみに―これはオールフラッシュアレイかハイブリッドなんだけれども全てSSDを搭載することによってオールフラッシュアレイのように見せているものなのかを確認する簡単なテストでもある。

ScaleIOは大量のNANDで構成することが出来るが、オールフラッシュアレイではない。このような場合、NANDデバイスは慎重に選択する必要がある(いくつか驚くほど書き込みが遅いやつとかがいるからね)、そして摩耗度についても十分に考慮する必要が出てくる。ScaleIOはあなたのデータをもちろん保護しているのだけど(データは分散されているからね)、これがいつも単一の回答にならない理由を際立たせているんだ。

 

6a00e552e53bd2883301bb0827e9bc970d.png次の質問は:一つのSDCだとどれくらいのパフォーマンスが期待できるの?

 

SDSの時みたいに、答えは構成によって様々だ、だけど同じホストを利用してみたら、その最大値は一つのSDCで約260K reads/secとwrite/secを記録している。

 

端的に言うと―えらく速ぇ。

 

 

CPUリソースは消費してるかって?そうだね、でもそれほどでもない。ScaleIO SDCとSDSはとても小さくて軽いからね(このチャートのピーク時の最大CPU使用率は大体20%くらい)。ネットワーク帯域は使うのかって?もちろん、でもみんなが思うよりは少ない、スケールする際のデータ分散のためのロードは完全に水平展開としてスケールアウトされるからね。

 

次の質問:スケールアウトは本当にリニアに実現されるの?回答:もちろん。もちろんこれについては懐疑的な意見があることは知っている、だったらテストしてみればいいよね?これが我々が32-64-128ノードを利用して行った試験の結果だ(今までと同じCisco UCS C240M3構成を利用している)。

6a00e552e53bd2883301b8d10d6646970c.png

直線的に並んでるよね。

 

ちょっとした遊びで(といかにScaleIOが破壊的なものであるのかを強調するため、および何故我々がみんなに使ってほしいと言い続けているのかを分かってもらうために)エンタープライズの「Type Ⅱ」(強固なつながりを持ったクラスタ)ストレージアレイ(VMAX3なんかと比較出来ちゃうようなリッチなエンタープライズデータサービスだ)とパフォーマンスの比較をしてみた。これがScaleIOというトランザクショナルスケールアウトSDSの他に類を見ることができないパワーなんだ。

 

このトピックは懐疑的にとられる可能性があるので、我々はESGの監視の下で注意深く実施をしてみた―これがESGが書き上げたものだ:

6a00e552e53bd2883301bb0827e9c6970d.png

お客様がトランザクショナルワークロードとして利用する可能性のある他のオープンSDS、例えばCephなんかはどうだろう?ちなみにこれが我々が発見したことだ。

6a00e552e53bd2883301b7c783deb8970b.png

現状でCephは本当に早いし、さらにオブジェクトのスタックを持っている、つまりは実際の競合としてはECSソフトウェアスタックになるだろう(そして実際に競い合っている)。でも我々は多くのお客様がCephをトランザクショナルなストレージモデルとして利用しようとしているのを見てきている。そして「なんでそんなに動かすのに苦労する上にパフォーマンスは本当に悪いのに使おうとするの?」と聞くと、その答えは大体「えーっと、入手が簡単だし、オープンに利用可能だから」というものだ。

 

ScaleIOも簡単に入手できるし、オープンに利用可能になった。そしてサポートを含めたTCO(利用するのに必要なトータルコスト)を比較してみると、ScaleIOはCeph Enterpriseよりも安価なんだ。上記のパフォーマンステスト結果が信用できないって?明らかに僕の意見にはかなりバイアスがかかっているよ!だからこそみんなに両方ともダウンロードして実際に試してみてもらいたいんだ。

 

TPC-CやTPC-Hなんかのクラシックなトランザクショナルワークロードに対するベンチマークについてはどうだろう?

 

OK。ここではOracle 12cを取り上げてみた、そしてこんな感じのハイパーコンバージドな構成で走らせてみたんだ:

6a00e552e53bd2883301bb0827e9d0970d.png

結果はどうだったかって?20GB/s強のフルテーブルスキャン、約1M IOPS、690μsのIOWAIT時間といったところだ。これは偉く早いよね。同じ位のコストを使って他の方法で同じことをしようとしてごらん(多分出来ないから)。

 

ここに詳細に書かれた情報をリンクしておく:

6a00e552e53bd2883301bb0827e9d8970d.png

お客様からの声っていつでも一番強力なんだよね。僕のいう事は聞かなくてもいいから、彼等の声に耳を傾けてほしい(そしてソフトウェアをダウンロードしてみて!)

 

見てごらん、ScaleIOは世界平和のための答えではないけどさ:-)

  • NAS/オブジェクトのようなことはしない。NAS/HDFS向けのスケールアウトについてはIsilonでマーケットをリードしていく。
  • どんな状況下でもリニアにスケールするものではないし、人々がオールフラッシュアレイ(AFA)に期待しているようなリッチなデータサービスでもない。AFAが持つ摩耗性やライトアンプリケーションの低減機能などは持っていない。AFA向けのスケールアウトにはXtremIOでマーケットをリードしていく。
  • オブジェクト/HDFSのようなことはしない。Geo dispersionを実現しているオブジェクト/HDFSに関しては、我々はECSアプライアンスやECSソフトウェアを持っている。
  • 多くのアプリケーションが利用しているクラシックなエンタープライスデータサービスのようなことはしないしメインフレーム、iSeriesをサポートするようなこともしない。そういった目的にはVMAX3でマーケットをリードしていく。
  • 小さな設置面積でたくさんの異なる処理をさせるようなことはしない。そういった目的にはVNX/VNXeでマーケットをリードしていく。
  • データ保護のストレージターゲットとして振舞ったりしない。そういった目的にはData Domainでマーケットをリードしていく。
  • インメモリデータベース向けのPersistenceレイヤとして振舞ったりしない。そういった目的に対してはDSSDと共にイノベーションを起こしていく。

...とはいってもさ、すごいんだよ、、ScaleIOはいろんなことに使うことが出来る。

 

これが何故EMCがPersistenceレイヤ、とコンバージドインフラストラクチャ(CI)エリアでポートフォリオ会社と言われるかなんだ。一つのツールで全てが出来るなんていうものはない。大切なことはPersistentレイヤとCIアーキテクチャから必要としているものだけを選択することなんだ。Persistentレイヤに関しては、その抽象化と自動化をViPRコントローラを利用して行うことが出来る。

 

ScaleIOの今後の展開は?そうだな、まずは5/29に自ら試してみることからだ!:-) おっと、もしかしてロードマップみたいなものを期待している?あまり明確になりすぎない範囲でだけど、今年みんなは以下のようなことを目にすることになるだろう:

 

  • ScaleIO 2.0は以下のようなものだ:
    • ESRSとの統合
    • エンドtoエンドのより深い統合メカニズム
    • Recoverpointとの統合(リッチなレプリケーション能力のために)―vSphere環境において、vSphere Replicationや、更にはRecoverpoint for Virtual Machineを利用しているお客様がいることを知っているんだ。あとはOracle環境でScaleIOを高速なストレージレイヤとして利用し、Oracle DataGuardをリモートレプリケーションに使っている何人かのお客様も知ってる。
    • ...これら以外にももっとある。
  • OpenstackとScaleIOのさらなる統合。現状でもSDCはCinderに対する多大なサポートを得られている、でもそれはコアTrunkではなく(EMCから)配布されているものなんだ。我々は恐らくこの分野でも直接貢献を受ける方がいいだろうと考えている。更なる努力が必要なんだけどね。
  • さらなる「P3」プラットフォームサポート。UbuntuやMirantisがCinderだけじゃなくてそれ以上のことについて次々とOpenstack展開しているのを見ていると、彼等のマネージメントツールと結合させていくことがいいんじゃないかと思えるんだ。さらには、非常に小さくて軽いコンテナ化スタックのためのCoreOSを利用した、色々な面白いお客様の利用例なんかにも注目している。

 

ScaleIOを無料で自由にした我々についてあなたはどう思ってる?

 

待つ必要なんてないから、ScaleIOをダウンロードして試してみようよ!そして是非フィードバックをしてコミュニティに貢献してほしい!!!

May 06, 2015

EMC World Day 3: DSSD Tech Preview

 

今日僕らはDSSDについて世界に知らしめた。垂涎の的であることは間違いない!

 

DSSDって?

それは・・・・・

従来のStorage Arrayではない。しかしコンセプトとしてはStorageであることには間違いない。

途方もなく高濃度なNANDパッケージである、GB/RUIOps/RUの点では他の何よりも。

途方もなくlow latency NVMである。百万分の一の世界。DRAMではないけれどNANDに限りなく近いレベル。

 

どんな場合に使うの?たとえば・・・

HDFSを基本とした戦略にするhyper-transactional data fabricにおいて

一部統合が必要なmodern hyper-transactional data fabricにおいて

一部統合が必要な主要基幹システムにおいて

強大なHPCHighPerformance Computer)環境において(TACの例を参考に:http://insidehpc.com/2015/04/taccs-wrangler-uses-dssd-technology-for-data-intensive-computing/

storage target (a LUN/filesystem)をドレスアップしたいならそれもいいよ(しかし馬車にTesla(電気自動車)をつなげるようなものだとは思う)

 

DSSDのマジックはソフトウェア、ハードウェア両面だということをはっきり言いたい。

これは“Software Defined Storage”と一緒にしてはいけない。これは“hardware defined”なんだ。

 

事実、ソフトウェアの革新とハードウェアは周期的に推移する。ソフトウェアとハードウェアが同一線上、ではない。一つの革新がまたほかの革新の起爆となり、またそれが一方の革新になり。。といった形で連続していく。図にあるようにハードウェア革新=SINX)とソフトウェア革新はCOXX)だ。これは波だ。

コアハードウェアの革新がきっかけでソフトウェアの革新を促し、結果ハードウェアの革新そのものが最大にまで上がる、そして同じことがソフトウェアにも起きる。

 

DSSDそのものについて語る前にバックステージの話をしようと思う。エンジニアリングではお客様への提供の最終準備段階に入っている。

 

トップシークレットツアーに招待するよ・・・・

 

何週間か前、お客様訪問とEMC Worldの準備でカルフォルニアに行ったんだがDSSDオフィスに行きたくなってね。。挨拶したい、、といっても迎えに来てもらったんだけどさ。

DSSDキャンパスはMenlo Parkにあって古い倉庫をリノベーションしたところなんだ。僕が到着したのは朝早くなんだが結構ざわついていた。ロビーのすぐそばにはコンファレンスルームがあってそこにはSEとして、またCSとしてのイロハを叩き込まれている新入社員がいっぱい。

そこには明確な「初志!」の雰囲気があって素晴らしかったのは彼らはすでにぶれていない、ってことだった。160人のチームだけどものすごい速さで成長してる。

DSSDの開発者の一人であるBill Mooreにそのツアーをお願いしたんだ。

彼は僕の中で共鳴する情熱あった。いいやつさ!

彼は19995月にあった3PARでの雇用者で(16年前のことだなんて信じられんけど!)

その前はSunZFSの開発をしていた。

(習得パーティーでは家族サービスをしていたBillは写真になっていたけれどね。。(写真→))

 

さて、Billと僕はsystem integrationhand-assemblyラボへ行った。そこにはすごいものがあった。

手作りのDSSD prototypes componentさ。すべての componentは手製のマザーボードにシルクスクリーンでニックネームが書いてあり、

graphic novel villainsのコミックから名前が付けられていた。ほらこれ、、DSSDのプロトタイプ。

 

僕は“power supply levitation system”が好きだな。

“power supply levitation system”はそれが熱くなるのを防ぐ。(扇風機・・・・)

 

これはホスト(クライアント)PCIアダプタ。これでPCIe gen3 4 lane インターフェースでDSSDへのアクセステストをした。

 

これは“Isley” で知られるclient PCIe card。(正式名称は“Poison Ivy”だけど)

このようにばらばらのアーキテクチャが新しいコアサーバートポロジとして素晴らしいlow latencyhigh-bandwidth network

ハンドルするのかとても興味深い。

 

DSSDアプライアンスは“Flash Modules”の連続なんだ。このシルバーの板的なものにパッケージされているのは狂っているくらいに高密度。512 flash NANDが死にもの狂いで並行に起動していると思ってくれ。

SRAM cacheとコントローラ。高密度なNAND設計は狂気の並行処理、しかしそれぞれのカードは4560W の電力消費なのでCoolingはとても大切。flash module package自身は熱の塊。SSDじゃない。

 

flash moduleをはがして。。。。出てきたのはかなり、かなり高濃度のNANDパッケージ。

6a00e552e53bd2883301b8d10eaa04970c.png

 

 

こっちはシステムレベルでの主要な考慮点であったPowerCoolingテストUnit

フルセットのDSSD gen 1の電力消費量は2000W/5Uに匹敵する。だからこれらを冷やすには風通し(気流)が必要。だからカスタムエンジニアリングでのCoolingFanの開発がなされ、30%の使用でハリケーン並みの風量を感じることができるものまで作ったそうな・・・

十分な気流を生み出すにはどうすればいいのか。僕は若いときにRFデザインをしていたけれど

あれはある意味Artなんだよね。どんなに数学的にうまく組み立てできてもだめ。気流ってそんなもんさ、小さなことがでっかい問題、成果をもたらすんだ。

 

3D printingでプロトタイプの作成、そして計算上の物理パーツのテストをDSSDチームは繰り返す。ラボではいくつか稼働中の試作品もある。

これこれ。。ちゃんと動いているやつ。。。

試作品がなかなか手ごわい事をするにしてもこうやって新しい製品が

生まれ新たな革新の波になってるのを見るのは本当に喜ばしいことだよ。

 

 

ラボから出て、通りを隔てた建物には(昔Sunのオフィスだったらしい)強烈にソフトウェアスタック、システムレベル統合、テストしている人達がいた。写真には誰も写っていないけれど多くのメンバーがそれぞれのチームで頑張っている。ガラスの向こうに見えるシステムレベルテストラボだよ。

システムレベルテストラボといえば・・・

DSSD D5ユニットが様々な構成で(そしてそれが実際の用途だしね)テストされているかわかると思う。想定される使用状況であるrack-scaleで、48ホスト構成、そしてKVHDFSで用いられるような高負荷でのトランゼクションWorkLoadツールを使う。

 

後ろから見るとそれぞれのホストがPCIファブリックで冗長接続されているのがわかるだろ。

 

Billはツアーで沢山のものを見せてくれたけど、一つ彼らが本当に情熱をもってこの開発に取り組んでいるという例を教えてくれた、それはLED。彼らはPCIポートのLEDが気に入らなかったので自分たちで気に入るものを作ってしまったんだってさ!

 

別の場所は歴史的にご機嫌なところでもあった。Sunがかつてここにあった事彷彿とさせるようなね。。halcyon daysさ。

Andy Bechtolsheim, Bill Moore, Jeff Bonwick その他大勢がSunとの歴史を持っているからね。壁紙を張り替えても一つの壁だけはSunを思い出させる色、紫になってたりしてさ。

もう一つ、それぞれのパーツにコミックからの名前が引用されてるって話しただろ、PCIe switch fabricプロトタイプ、Ultron. Bad-a$$ :-)

 

DSSDのデモを今日やったけど、もうちょっと焼きの時間が必要だから、まだみんなにはそんなに盛り上がってほしくないんだ。。もう少し待って・・・・でも本当にこれは素敵でかっこよくて素晴らしい製品だからみんなが盛り上がらないほうが難しいよな。。

 

Near DRAM インスタンス、throughput, bandwidthを通じた爆発的な高密度性能 – KV store API、MemcacheD,HDFSのnative support

ああ!SUPERCOOLだああ!

もうちょっとで君のそばに来るからね!

May 06, 2015

EMC World Day 3: Project Caspian

 

今日は“Project Caspian”の発表と論証をしました。

 

それは何か?

“Project Caspian”は業界で一番の産業化されたソフトウェアスタックであることを目的としている。ソフトウェアのみ提供し、 platform 3のデザインセンタであるオープンソース+コモディティーハードウェア環境を目指すお客様へ“cloud native applications”を展開するための産業化コンバージドインフラを提供。

 

ハードウェアはこのプロジェクトで一番プライオリティーが低い。(コモディティーハードウェアはVxRackのそれにかなり似ている)

ソフトウェア面が面白い。“clean sheet”(まっさらな形での意味)アプローチとしてP3へ特に特化した形になっている。

このプロジェクトはOpenStack 環境の即時導入ソリューションとして『業界標準化』を目指している。発表ではCloud Foundry (クラウド基盤)、代表的なHadoop環境(Cloudera /Hortonworks/Pivotal ODPなど)への即時導入プラットフォームとしてのプロジェクトCaspian ロードマップも発表した。

 

なぜその流れになるのか?

一つ、このプロジェクト自身すごいから。オープンソースのコアといってもいい。

2つ、これはfederationの新しいWorkloadをはかる2つ目の方法を表している。(一つ目はVMware VIO と “Cloud Native Apps” (クラウドアプリ)開発)そしてこれは僕らの言う“Choice”(選択権)の証でもある。ある人はVIO + Photon +  CFを選択し、またある人は.  100% open source modelを選択する、かもしれない。

 

そして一番大切なこと、大切な次元での話。これが新しいWorkloadのトラッキングを可能にし、エンタープライズ環境でのOpenSource の産業化を始めるもの、だということだ。各方面がそれに参入しようとしているがEMCが頭一つ出ている。

 

背景の説明をしよう・・・・

僕の経験からだけど・・・興味深い“fork”(分岐点)がお客様のインフラストラクチャへの考え方のなかで起きている。

1.ある人は既存の“platform 2”アプリケーション要求やvirtualizedされたインフラを見て、

a) ‘software defined’で運用費の向上を進められるし、設備投資費はSDS/SDNなどの業界標準の新しいテクノロジの導入で向上させることができる!これを“platform 2.5と呼ぶ!b)このご機嫌なplatform 3を同じインフラでそして同じチームでやるにはcloud native Appを使えばうまくいく!

などと、考えている。

2.ある人は既存の“platform 2”アプリケーション要求と“platform 3”のアプリケーション要求を見て、これらは全然違う類(アーキテクチャ的にもオペレーション的にも)なのでplatform 2とplatform 3それぞれのの最適化を図って2つの柱を立てる。またそういう場合は2つの思想も同時に必要になるから、「プロセス重視でリスク回避」(ITILの類)と「速さと反復」(DevOps戦略などの融合)という2つの柱、2つの思想、そして2つの運用形態、が生まれてしまう。

 

これは本当に重要な分岐点だ。そして「正しい答え」は様々だ・・・

 

今年初めのVMwareの発表と今日のCaspianプロジェクトの発表を思い出してくれれば、federationが両方の道を模索しようとしていることがわかると思う。

 

最初のルートを選択するお客様にはVMwareがOpenstackとの融合として“Cloud Native Applications”(これはProject Photonとして詳細確認可能)をfirst of the two approaches(2つのアプローチの最初のもの)として位置付けている。これはコンテナも内包できるkernel-mode VM

抽出モデルでWorkloadはかるものでVSAN/ScaleIOといったtransactional layerでの戦略をベースにする。“One Cloud”としてのアプローチの表れでEMCはhyperconverged offerでこれをサポートする。(具体的にはVxRackとappliances=EVO programのこと)

 

2つめのルートを選択するお客様にはCaspianプロジェクトが本当の意味での“pure platform 3”となる。

以下のイラストでもっとイメージしやすくなるだろうと思う。

 

 

ここで何かの良し悪しを言うのは無意味だ。なぜならプリウスは素晴らしいし、テスラだって素晴らしいから。

Evolution(進化)が答えの人もいるしrevolution(革命)が答えの人もいる。

大事な点として、このプロジェクトCaspianはinfrastructure resilience(インフラ汎用性)が必要なAppには

フォーカスしていないということだ。固有のペットを囲うのではなくどちらかというと家畜を囲うイメージなのだ。

これは“open source always”(常にオープンソース)を使ってビルドされているモデルだ。

WorkloadをNova インスタンス、コンテナ(Rocket, Docker, Diego)、ベアメタルをlow level abstraction layerとして認識する。

またVxRackより少ないトランザクションOpen SDSを併せ持つ。

そして多くのObject ,ECS経由や将来のDSSD経由のHDFSをも内包する。ObjectとHDFS は“pure platform 3 App”において

persistence layer的な役割を持つ。

 

そういったお客様の決断を表示するとこんな感じ。右に行くにしても左に行くにしても価値の判断はつかない。

 

プロジェクトCaspianはコンバージドインフラ“RACK”分類と親和性がある(月曜に話したこれ

プロジェクトCaspianのソフトウェア群は規模が問題だ。ある程度の規模がないととその最適化が難しい。小さくできないというわけではないがSweetSpot(利点を最大限に生かす場面)が見つけにくいということだ。しかも規模、だけの問題ではなかったりする。

“RACKS” や “APPLIANCES”はhyper-converged storage/compute designsを用いることを思い出してほしい。しかし“RACKS”は“Flexibility” に傾向しがちだし、(言葉を変えると広い選択肢のpersona、ハードウェア、導入例ということ)“Appliances”は “Simplicity” に傾向しがちである。(選択肢の狭い personas 、ハードウェア、導入例ということ). プロジェクトCaspianはこういったばらばらの要素をweb-scaleでカバーするのだ。例えば、Open Compute Projectの例にあるようなばらばらで広いサービスを一緒に確認できるようにする、ということだ。

 

今日発表したプロジェクトCaspian Demoはこちら・・・・

 

EMC World 2015: "Project Caspian" Demo - YouTube

 

 

繰り返していうようだけどProject Caspianではハードウェアはメインのポイントではない。メインはソフトウェア。

OpenStack

CloudScaling の獲得はいくつかの目的がある。一つはEMC がopen source softwareに強い、ということ。またOpen Stackの“industrializing”(産業化)への注入をプロジェクトCaspianで行う、ことだ。Openstack のCloudScalingアプローチはそのコアである “vanilla” に近づくことに尽きる。

 

The Fabric

これはまたの機会に話すとしよう。しかしこういったものを成功させるにはElastic、Cluster Managerが必要になる。どういう意味か。KubernetesやMesosがCluster Managerの例として挙げられるがコアはCloud Foundryだ。Cluster managerはインフラの導入や、設定、などを管理するものでこれらは毎日最適化されているものだ。

何が言いたいかというと・・・Redis インスタンスを処理するときにおかしなことが一つでもあったら君は新しくリスタートをするだろう。しかし他のはおかしくなかったら、そしておかしいものとおかしくないものの間に関連性があったら。。こういうことはobject系ではよくある。最初のインスタンスをここへ、そして次を他のRackへ、3つ目は他のDataCenterへ。そして夜中に105番目のインスタンスがハードウェア障害でおかしくなった場合・・・リスタートしたいのにできない・・・なぜならリスタートはどこかにある管理システムでやらなきゃいけないから・・・・こういった例からも

cluster managerというのはもうすこし相互関係においてソフィスティケートされたものでなければいけないということを意味する。

プロジェクトCaspianではFabricはソフィスティケートされたホームメードの

stateful cluster managerなのだ。もちろんwebscaleにたけた人達は自分たちで作ったstateless なopen-sourceを持っている(GoogleのKubernetesがその例)この話はまた今度。しかしこれはまだまだ可能性を秘めた大事な面でもあるんだ。

 

The Persistence Layer(持続性レイヤ)

Platform2 のWorkloadで“platform 3”のアイデアを使いたいとなると、(スケールアウトSDSとコモディティーハードウェア=持続性の実現とか)様々な業務処理との兼ね合いが必要なることが多い。だからVxRack 1000(open persona)やVxRack EVO:RACK 、VSPEX BlueなどはPlatform2.5 のベストな選択として設計されているし、プラットフォーム3での使用も可能。プラットフォーム3をターゲットにしてしまうと起動、そして小規模DataBaseをハンドルできるような transactional storage(ScaleIO)などだけを持つことになってしまう。しかしHDFSなどのメモリーhyper-performance持続性を持つプロジェクトのような広い選択肢がやっぱり欲しいでしょ。プロジェクトCaspianは少しのScaleIOをオープンなtransactional persistence layerとして使っているから(Novaインスタンスをサポートするだけに十分なCinderを持つ)プライマリのpersistence layerはあくまで進化したECS Softwareで提供されることになるObject/HDFS layerとなる。

 

The Hardware Abstraction layer(抽象的なハードウェアレイヤ)

この点に関してはあまりにも興味深いので独立した書き込みをしよう思う。ま、プロジェクトCaspianはOnRackを使うことになるんだけどね。

 

ハードウェアそのものは?

以下の図がプロジェクトCaspianの3つのビルドの例になる。それぞれ違うcore/memory/persistenceの混合なんだ。

オレンジ色の部分はVSPEX BLUEに使われている4 module/2U デザインのnext-generation version(Haswell/Broadwellベース)を使っている。これは一般的な目的の用途に適しているしScaleIO やECS Object/HDFSなどをpersistence layer(これはある程度storage/IOpsも稼ぐし)のとして混合される。これのpersonaはOpenstack, CF,そして巨大ではない程度のHadoop/Objectをターゲットにしている。 

 

黄色の部分はもっと高密度なコア部分。そして小さなpersistence キャパシティーを持つ(しかしローカルSSDを介して高いIOps)personaは高い割合でのOpenstack, CF, 小規模な Hadoop/Objectをターゲットにしている。

 

青色の部分はpersistence capacity design centerをターゲットにしている。そして2つのことに気が付くだろう。

1:プロジェクトCaspianはECSアプライアンスにビルドされているという事実

2:next-generation ECSはプロジェクトCaspianのバリエーションの一つであるということ。容量に特化したという点で・・

これだけのキャパシティーはなかなかクレイジーだろ!これは小規模なOpenstack,CF,大規模Hadoop/Objectをターゲットにしている。

 

将来的に persona mixが 大容量の in-memory data fabricや hyper-transactional workloadを含むようになれば DSSD を含むことになる。図の上部を見るとわかるようにラック内スペースがあるけれど(実際ネットワークやドメイン障害のために別ラックでデザインした)そこにDSSDもぴったり収まるってわけさ。そしてPCIe/NVMe接続でラック内のホストをつなげる、DSSD D5は“Rack Scale Flash”になる。そしてIOps/latency persistence layersが素晴らしく高機能になることは間違いない。

 

 

Netting it out – 総括すると

プロジェクCaspian は目的として: full bi-modal路線(P2P3混合)をたどるお客様にとって完全なるオープンソースでコモディティーハードウェアモデルでの、業界一の強固な、そして産業化されたPlatform 3のプラットフォームを提供することに焦点を絞っている。

これは“tech preview”だけれど僕らは大真面目だ。第一回目のお客様相談会は6月にあるし、Capian はもうすこししたらもっと機能向上することも請け合う。

 

このOpenStackの新しい局面, Cloud Foundry, Hadoop community, lifecycle –といったものはエンタープライズでオープンソースモデルをどううまく機能させていくか、の競争だ。

 

オープンソースソフトウェアからどうやって利益を追求するかは誰もわからない、という間違ったメモがある。それは嘘だ。

ある会社は “services” 中心のモデルを選択する(Mirantisみたいなもの).   これは素晴らしい、うまくいくよ。

ある会社は.   “support”モデルを選択する。(RedHatとかね) これもいい。うまくいく。

ある会社は“value in proprietary on top of opensource”(オープンソース所有性)(Clouderaを見て)を選択する。これもいいね。大丈夫。

ある会社は“appliance” モデルを選択する。(Barracudaかな)

 

最近僕らは初期的な“industrialized OpenStack”(産業化されたOpenStack)スタイルでのオファーをよく見るが(Nebulaみたいなもの)マーケットはエンタープライズレベルでのそれを望んでいる。

エンタープライズでOpenStackを導入してメンテナンスしようとすることがどんなに難しいか、ということが強調されてきたよね。たとえばCloud Foundryを導入構築した人が「走り出せば素晴らしいシステム!」しかしOpenStackよりそれは難しい、、、と言っていたりしてさ。

 

プロジェクトCaspianはvanilla OpenStack, Cloud Foundry,  主要なHadoop Distributionを通じて“industrialized”(産業化された)platform 3 のプラットフォーム、そして“cloud native apps”を一番いい方法で展開する方法を作り出す僕らの努力の結晶だ。

 

“P3 purists”(P3信奉者)のために主要企業の人たちがどううまくことを運んでいくか興味深い。結果的にはお客様の選択。EMCを選択する人達は「彼ら自身の道」をたどることになる。真のプラットフォーム3がプロジェクトCaspian。P2.5 の上のP3はVIO, VMware  Cloud Native Apps ,そしてCF、 vSphere 上のHadoop を走らせる。

 

As a federation, we’re all in, and playing to win!

フェデレーションとして僕らはまっただ中にいる、そして勝つ。

 



このスレッドはVirtual Geek の作者の許可をもらって日本語訳にしています。


参考:

CF (Pivotal CF)https://www.vmware.com/products/pivotal-cf

May 04, 2015

EMC World Day 1: Data Protection – Beyond Backup, Cloud, Simpler.

 


EMCにとってBackupがただ単にバックアップだったことはない。Backuprecoveryでありcopy managementであり、

必要悪をいかにシンプルにそして経済的にしていくか、という深い側面を持ち続けている。経済的な面では

Tapeが有用でないという大前提を元に業界では変革が求められている。

 

“Backup”は2つの面にフォーカスされる、「backup App」と「backup Target」だ。

僕らにとっての“beyond backup”(バックアップを超えて)は以下のモットーで進めている。

 

1,backup recovery に使われるようなbackup Appを作るのではなく、検索、インデックス付け、そしてCopy Policy

徹底できる道具を作ること。(RMANBR*Tools,vCenter といったものはすでにApp自身がバックアップ機能を備えている)

2.それとわからないbackup/archive storageを作ること。(魔法みたいな話ではあるけれど)hyper-scale object storeなどに含まれるような

一体化した類を作ることが必要。

 

そしてその両方を兼ね備え、かつシンプルにすればバックアップにまつわる煩雑さや必要悪を取り除くことができる。

僕らはまだまだだけれど、それが僕らの夢なんだ。

僕らの進行形の夢を今日、発表した。

 

ProtectPoint

Oracle RMANの延長でSAP (BR*Tools integration)DB2 (ACS integration)をサポート。これはArrayで作成されたコピーを

Hostにロードしなくてもコピーとして使えることを意味する。(そしてマニュアルでのFullBackupよりも20倍の速さを誇る!

そしてさらにもっとお得なTierのData Domain(これもすでにpublic cloud object storageとしての認知をされているが)

にそれと知らせずに保存することも可能。ただし現状ProtectPointVMAX3 でのみ使用可能。(DataDomainとの関係から)

しかし将来的にはXtremIOVNXでも対応させるべく開発中。

 

Data Domain

どんどん改良が進んでいる。(Version1.6 ~16%のパフォーマンス改良を実現)そして、どんどん小さくなって(Project Falconではvirtual Data Domain Applianceの開発が進んでいる。)そしてどんどん大きくなっている。(DD9500は従来型よりも1.6xの速さと4xの大きさを誇る)プロジェクトFalconについて:https://www.youtube.com/watch?v=9MQRbQa3bN4 

 

CloudBoost

これはpublic cloud copy management のために開発されたMaginatics meta-data engineとオブジェクトアクセスの融合を可能にしたもの。EMC でのCloudArrayはプライマリストレージに対して“Tier to cloud”の体を擁しているが、CloudBoostdata protection ストレージ(Data Domain など)に対しての“Tier to cloud”なるものだ。CloudBoostData Domain Networkerとの融合を果たす。

 

Making backup simpler(バックアップの簡素化)

NetworkerProtectPointの融合。これによりリカバリのためのカタログとしての役割が果たせるようになる。

Data Protection Softwareポートフォリオがエンタープライズ系のサーチ機能を持つようになる。(google searchのエンタープライズコピー版と考えてくれればいい)

 

copy managementの簡素化、低価格化、backup の不可視化、を進めていくことでBakcUpBackUp以上のものに進化させていることが

お分かり頂けたかな・・・

 

EMC Data Protection Customerとしてどう思う? 僕らは正しい道をたどっている?


このスレッドはVirtual Geek の作者の許可をもらって日本語訳にしています 

May 06, 2015

EMC World Day 3: OnRack

 

月曜に発表されたVxRackと、水曜のProject Caspianについての発表のなかでちょっとしたスパイスがあったのに気が付いたかな?OnRackのことなんだけど・・・・・

何かって?答えは業界標準のthin/ low-level hardware abstraction layer= HALのことだよ。まだプロダクトとして完成していない。しかし僕らが有機的に、そして非有機的にずっどかかわってきたものだ。

これはHardware Software業界にかかわっていなければ、もしくはDataCenter管理関係等をしていなければ(もしくはhyper-scale player)

でなければあんまり考えない部分の話さ。

 

たとえば・・・

  • 問:遠隔でサーバーをブートするのは簡単? 答:サーバがすべて同じ系統なら簡単だけど サーバがすべて異種系統もしくはhyper-scaleならすごく難しい。なぜ? IPMI といったものは業界によってかなり違いがあり専用のツールがベンダーごとにがっちり組まれているから。そしてそういったものはhyper-scale 向けに柔軟性をもったデザインではないから。
  • 問:1000ホストのファームウェアアップデートは簡単?答: 恐ろしいくらいに難しい
  • 問:1000ホストにlow-level persona を導入するのは簡単?(例vSphere + VSAN)、もちろんnetworkサポート、COTS disk enclosuresサポートなどを考慮して。答: すごーく難しいこれには沢山のエンジニアリングを必要とする。
  • 問:EVO:RAIL ベーシックレベルでのアラートモニター機能 的なものを導入するのは簡単? A: 難しい。僕らはそういったベーシックレベルな機能 を導入するため、EMC VSPEX BlueBMCハードウェアmodifyしなければならなかった。何度も何度もね・・・・

 

  こういったことはまだまだLow Level (ベーシックレベル)な話、Puppet/AnsibleとかvSphere’sbare metalで構築するとかそういうこと以前の問題。しかしこれはマネージメント/オーケストレーション/抽象レベルの話。

これらに対する回答は“Software Defined”時代のあおりでかっこよく話だけは進むけれど、やっぱり業界標準とかOpenソースとかいったものの中ではすごく重要で難しい。大体Low Level (ベーシックレベル)のハードウェア標準化は次のうちのどちらかに巻き取られている。

  1. ハードウェア順応性をぎりぎりまで狭めて、アプライアンス、そしてきつい束縛を良しとする。
  2. hyper-scale な人々が自ら“bare metal as a service” スタンダードを立ち上げODM系での解決策を模索する。

 

業界標準のハードウェアをふんだんに使っている僕らにもこういったベンダーの壁、的な問題はまだまだ沢山ある。Isilonでのinfiniband controllerファームウェアアップデートでどんなに僕らが苦労したことか。。。もっというと同じようなことをXtremIO Xbrickでやればおそらく仕事量はその倍。。。。決して少なくはならない。

不思議なことにこういうことに対してのOpenなプロジェクトというのは存在しない。OpenComputeOpenstack(皮肉にもこれに関してもいろいろやらなきゃいけない事は山積なんだが)くらいがそれかもしれない。

VxRack とかProject Caspian を数百数千のサーバー上で運用したいとなるとこういった話は必ずついてくる。

OnRack はそれまでhyper-scale な人たちが内部的に進めてきた取組を、業界標準で、そしてOpenに、みんながプログラムできるような

形にするプロジェクト、技術だ。(low level hardwareレイヤでね)

 

OnRack なら広い範囲でhardware の融合を可能にできる。異なる persona (KVM, vSphere, ベアメタルScaleIO、CoreOS, など).   そしてスイッチやサーバー、HDD/SSD/NAND enclosuresでも。.  ベーシックレベルでのアラートモニター機能や情報収集管理も可能。遠隔での測定も可能。そして事実スケールアウトも可能。だってデザインターゲットはhyper-scale deploymentなのだから。


これを見たらもっとイメージがわくと思う。

https://www.youtube.com/watch?feature=player_embedded&v=atJuFBEhLA4


僕らはこれを一つのプロダクトとは思っていない。どっちかというとプロダクトの一要素、だと思っている。そして正直に言うとインパクトを期待するのであれば業界の努力としてオープンソースすることだろう。

どうやってやっていくかなど、改善がまだまだ必要だけれどViPR Controllerがオープンソースになったようにね・・・・

結構いいでしょ?

 

 

このスレッドはVirtual Geek の作者の許可をもらって日本語訳にしています。

May 05, 2015

EMC World Day 2: Data Lakes + Splunk + Hadoop + EMC = Awesome.

 

EMC World 2015の2日目、(というか今週中ずっとだけど)ClouderaHortonworksSplunkPivotal 、などビックデータ エコシステムで

活躍する友達が集まってくれた!

 

「ビッグデータ」はBuzz(流行)な言葉というだけじゃない。これはオープンな(みんなで情報共有して考える)エコシステム

にしていくことも必要なんだ。

 

僕らはIsilon HDFS DataLake Use Caseで大きな局面に遭遇している。しかもそれはIsilonビジネスそのものと

言っても過言ではないし、HDFSの使用だってインストールベースで爆発的に増えている。

売上がそれを物語っている。。。人々はEnterprise Data Lakeへの投資を始めているんだ。

 

Isilonはただの“Scale-out NAS”じゃない、非構造化DataのためのScale-out Enterprise Data Lake”. だといえる。

Isilonはすべてにおいてすぐれている。(早い!安い!うまい!)

それまでのDAS接続HDFS環境よりもすぐれているといえる。(IDCも同じ意見なので嘘じゃないよ!)

それだけじゃない、HDFS snapshots, replicas, そしてmulti-protocolアクセスに関してもIsilon は優れている。

もちろんNASとしても使えるしね。


内輪な話ではあるけれど、Big Dataの話でみんなにお知らせしたい話がある・・・

Midmarket むけEMC SEチームの話さ。 彼らが作ったbig data デモのIoT Internet of Things )の話。これはAWS, HAWQ/Tableau/SpringXD などのvCloud Air上でPivotal Web Servicesを走らせて作ったもの。。ビデオで見てもらったほうがおそらくよくわかる!

 

これこれ・・・・https://www.youtube.com/watch?feature=player_embedded&v=K1Frpra2nUg 

その上、自分で試してみることもできるんだ。君のスマホを取り出して、http://tilt.cfapps.io にアクセスして。

GPS dataをシェアしたい場合はメンバー登録が必要だけどね。

彼らはいろいろ面白い施策を加えてお手製のArduinoのようなIoT sensorを改良して作っているよ。

 

 

じゃ他のタイプのビックデータ、たとえば、Splunkのようなシステムからの情報はどうやって料理されているのか見てみよう。

答えは。。。僕らは強力して素晴らしい仕組みを作っている!

 

つい最近Splunkに関連するSolution Guideをリリースしたばかりだし。



またANZのチームがXtremIO , Isilon の組み合わせの導入例をブログで紹介してるからこれも必見! 

 

まとめると・・・・

なぜEMC Splunkなのか。。。。絵を見ると一目でわかる。

それ自身もスケールアウト型のSplunk Serverflexible Scale-Out でかつHot/Warm Bucket storage であるXtremIO ScaleIO、もしくは

Cold Bucket StorageであるIsilonでもペアリングする価値がある。

その流れはこちらの図で・・・

     Storage Tierの最適化            スケールアウト性と経済性         Data Services の充実性

 

シンプル、そしてお墨付き。そして充実したData Services ,そしてパフォーマンス…これが答え。

 

 

 

SplunkCloudera, Hortonworksや、XtremIO, Isilon, ScaleIOを導入して運用している人、ぜひぜひその感想を聞かせてほしいな!

 

 

 

 

補足情報 Hot/Warm/Cold  Bucket の話・・

Bucket Type
StateBackup
HotRead/WriteNO*
WarmRead onlyYES
ColdRead onlyYES

*Unless using snaphot aware FS ( VSS,ZFS ) or roll to warm first ( which is introduces performance penalty)   


このスレッドはVirtual Geek の作者の許可をもらって日本語訳にしています。

こんにちは、SDS製品担当の平原です。

 

さて、EMCSoftware-Defined Storage戦略の中核をなすソフトウェアであるViPR Controller。今年のEMC World 2015ではどんな進化を見せてくれるだろうかと期待された方もいらっしゃったかと思います。しかし、その発表はこれまでとは少し毛色の変わったものでしたね。そう、ViPR Controllerのオープンソース化です。

fig1.png

 

ところで、オープンソース化と聞くと、ViPR Controllerの無償化を想像されるかもしれませんが、今回の発表は異なる意味合いがあります。というのも、無償版という意味では、既に我々は商用版ViPR Controllerの全ての機能を試すことができるフリートライアルを提供しているからです。

 

実はこのオープンソース化が発表される以前、2年前のEMC World でのViPR Controller発表時にも「コミュニティ化」というのがキーワードとして語られていました。しかし、それは今日に至るまで目立った進捗が見られなかったのも実状でした。これまでのEMC(正確にはEMC Federationの一社であるEMC II)の文化を考えると、自社のテクノロジーをオープンなコミュニティに出すということにあまりノウハウもなく、社内的にも色々な議論があったのかもしれません。

 

そして、その状況を大きく変えた背景には、ある人物が影響していると私は推測するのです。それは、EMC World 3日目のジェネラルセッションに登壇していた、エマージング・テクノロジー部門バイスプレジデントのランディ・バイアスという人物です。彼は、EMCが昨年買収したOpenStack関連新興企業Cloudscaling社のCEOOpenStackコミュニティのファウンダーでもあった人。いわば、根っからのOSSスピリッツを持ったエンジニアというわけですね。そんな彼がOpenStackでの成功体験に基づいた確固たる信念をEMCに持ち込み、この短期間に社内の文化や思考を変えるほどの影響力を及ぼしたのではないかと。今回の出来事は、EMCのソフトウェアビジネスを根本から変えるエポックメイキングとなるかもしれません。

fig2.png

 

さて、このオープンソース版ViPR Controllerプロジェクトは「CoprHD」Copperhead:カッパーヘッドと発音)という名称で、githubから6月を目標にMPL (Mozilla Public License) 2.0に基づいてソースコードが公開される予定です。公開されるソースコードは商用版のViPR Controllerから一部の機能を取り除いたものとなりますが、これらはEMCとのオンラインサポート、ライセンス管理およびソフトウェアの自動アップデート機能といったものですので、ViPR Controllerの核となる機能は全て公開されると考えて良いでしょう。

fig3.png

 

では、公開されるソースコードの中で特にコミュニティによる開発が期待される部分はどこでしょう?それは、ViPR Controllerのインターフェース領域である、Northbound APISouthbound APIになるでしょう。Northbound APIはオーケストレータや各種アプリケーションと連携した新たなデータサービスの開発、Southbound APIEMCの開発リソースだけではフォローしきれなかったストレージ機種の対応追加が期待されます。もちろん、この他の部分でも利用者目線で画期的なイノベーションがもたらされることをEMCは大きな期待を持っています。

fig4.png

 

そして、大事なことは、このプロジェクトにおいて意味するオープンソース化というのは、単なる無償化ではなく「開発モデル」そのものであるということです。すなわち、コミュニティ内で改修・新たに開発されたソースコードは適切にコミットされ、次のバージョンのソースコードに新機能として取り込まれていくことになります。この機能をコミットするためのプロセスや、どのようにコミットに関与するメンバーを選定するのかなど、開発の中立性やガバナンス担保のための細かな議論も6月の公開時期までにはクリアになっているはずです。

また、EMCもこのソースコードをベースに商用版としてViPR Controllerを継続して開発・販売していきます。商用版はテクニカルサポートサービスとの一体化やEMCが開発したプラグインソフトウェアの利用権といった部分で差別化を図りながら、お客様に最適な選択肢を提供していくことになります。

fig5.png

 

それにしても、私はこの発表に非常にワクワクしています。日頃、私はViPR ControllerSEとしてお客様と会話の機会が持つことが多いのですが、そこではEMC視点で製品を見ている私にとって、お客様が非常に興味深いアイデアや期待をViPR Controllerに抱いていることにハッとさせられます。その中には、それらアイデアの実現にEMCだけでは困難なことも、他社もしくは他のOSSテクノロジーとの組み合わせでは意外に容易に出来そうかなということがいくつかありました。私は「CoprHD」プロジェクトがそんな利用者の夢を叶えるエコシステム実現の触媒となることを期待したいと思います。今後の「CoprHD」プロジェクトの展開をどうぞお楽しみに!

fig6.png

関連リンク

CoprHD公開予定サイト (Github) 

http://coprhd.github.io/

 

Randy Biasblog記事

http://www.cloudscaling.com/blog/cloud-computing/introducing-coprhd-copperhead-the-cornerstone-of-a-software-defined-future/

EMC World 2015において、The Beastの愛称で呼ばれている「XtremIO 4.0」の発表や、ラックスケールフラッシュ「DSSD」のお披露目がありました。これら2製品もちろんそれぞれ特性は異なり棲み分けがなされるべきなので、一言でまとめること自体が間違っているのですが、あえてまとめるとどちらも「低遅延」であることです。

 

なぜ、データレイクに関するタイトルなのにいきなりXtremIODSSDの話をしているかというと、データレイクを中心としたビッグデータ分析基盤には必要不可欠なものと考えられるからです。

 

 

Isilon Data Lake

 

EMCは以前から「Isilonデータレイク」の提案をしています。

そもそも「Isilonデータレイク」は、SMBNFSはもちろんHDFSOpenStack Swiftと言った異なるプロトコル、手法でファイル共有可能な「IsilonスケールアウトNAS」を従来のNASとしての単純なデータ置き場ではなく、多種多様で膨大なビッグデータを効率よく一元管理する場として用いるものです。

例えば、NFS経由でIsilonに書き込みをしたログファイルをそのままHDFSにて分析することも可能です。


 

datalake.PNG.png

 

 

 

適材適所


しかしビッグデータの活用、分析には様々な手法や目的があります。

その中には、ゴールデンウィークに発生する渋滞傾向を分析して次の年の渋滞を防ぐ為の策を分析するようなある程度時間をかけて行うことのできるものがあります。また、為替のように一瞬一瞬判断で数億ドルを得るあるいは失うような取引の分析、これらは瞬間的な判断がものをいうので、極めて短い時間での分析が必要です。

 

先にあげた渋滞情報のようなある程度時間をかけて分析可能なビッグデータはIsilonに保存したまま分析をすることができます。また、後者の為替取引のような瞬間的に分析が必要なビッグデータに関しては、少しの遅延も許されません。この少しの遅延も許されない分析においては、EMCに限らずどのメーカの製品についても言えることですが、Diskベースアレイには向いていない

ワークロードとなります。

 

このようなワークロードに関しては、分析ホストのブロックデバイスとしてXtremIOや、さらに高速な分析が必要なものは今まではインラインメモリで処理を行ってきましたが、今後はPCIeバス直結のDSSDの様な製品も利用されるようになると考えられます。


 

datalake2.PNG.png


このようにIsilonの様なデータレイクにて一元管理されているビッグデータを、それぞれの用途に適したソフトウェア、インフラで処理をさせるということがビッグデータの活用を成功させるための鍵ではないでしょうか。

 

この度、ビッグデータ分析に関してXtremIOIsilonSplunkのホワイトペーパーがリリースされました。

パフォーマンスやコストのバランスの取れたビッグデータ分析基盤の構築ノウハウが記載されています。是非ともご覧ください!


splunk画像.PNG.png


<ホワイトペーパーリンク>

EMC SOLUTION FOR SPLUNK

May 04, 2015

EMC World Day 1: XtremIO 4.0 – the best AFA gets better.

 

XtremIO 4.0の発表! 数週間でその一部はお客様へ無料で開放される。

おまけにこれはXtremIO 3.0からのNDU(オンライン)アップグレード!だから安心して!

 

何がイイって?この広大なプラットフォームがもっともっとパワーアップしたってことさ。身震いするくらいにいい感じでね。

だから僕らはXtremIO 4.0のリリースを愛をこめて“The Beast”と呼んでいる。

 

新しい機能その①

5TBから320TB (8x40TB X-bricks)までならオンラインでのcluster拡張が可能。また将来的には40TB 6,8 node clusterQ3 はじめにはリリースされる予定。なぜスケールアウトがそんなに重要かって? Flash Storageにおいてはシンプルにスケールアウトする方が簡単だ、という結論に大多数のお客様がたどりついたからさ。XtremIO 4.0ではオンラインでのダイナミックなスケールアップが可能。もう一つ!X-brickでは- 1-2-4-6-8でスケールアップが可能!

12thmay4.jpg

オンラインでのcluster拡張を詳しく知りたいならこれ!

 

https://www.youtube.com/watch?v=***2KLrkm-Y&feature=player_embedded


新しい機能その②

remote replicationの充実。Recoverpointとの融合で何千デバイス、コンシスタンシーグループのReplicationsub 60-second RPOで可能。

これはトライアルではないよ、XtremIO clusterのスケールアウトが可能であればreplicationだってそうならないといけない。RPOの充実のために

“Beast’s”ではやっとの思いで1M IOpsを実現した。XtremIO customerVPLEX RecoverpointもしくはRecoverpoint for Virtual Machinesreplication

をしている一方で XtremIO“platform”なしのremote replicationをしていた。この新しい機能は異種サポートも含んでいる。

vSphere SRM, Appsync support, そしてViPR automationだってサポートする・・・そしてもっと他のものも!

そうXtremIOno “platform”ReplicationからAFA 業界では一番のBest Remote Replicationを提供できるようになったんだ。


こっちのデモビデオでそれを体感して!

https://www.youtube.com/watch?v=IJBeQiGgntI&feature=player_embedded&list=PLDoAsI7hhKMfnefdeAW0eeUsMoW8c3_Qu

https://www.youtube.com/watch?feature=player_embedded&v=8nd12_TKVa8

https://www.youtube.com/watch?list=PLDoAsI7hhKMfnefdeAW0eeUsMoW8c3_Qu&v=PPlCc4dJpYw&feature=player_embedded

 

新しい機能その他・・・・

  • 40TB X-brick。もっとたくさんのRAMにMetaDataを入れて $/GB を稼ぎ、IOps をも勝ち取る。そしてそう、その恩恵はすべてXtremIO cluster に詰まっている!
  • 8 X-brick (16 node) cluster サポート。これは平均で1PB ほどのdata reductionが一つのXtremIOで可能、ということを意味している。
  • パフォーマンスの向上(すでにパフォーマンスはすごいいいけどね)
  • 障害耐久性の強化。X-Brick 当たりN+2 SSD 障害、16 SSD (同時)障害に耐えうることが可能。Xbrick でのDual SSD 障害は業務に何ら影響を与えない。これはXDP RAID-6との大きな違い。この dual parity は初代X-Brick のころからの伝統でこれが今回のバージョンで完結した。XtremIO には単一障害スポットが無い。(NO SPOF

  Note:面白いことに(ありがたいことに、、、か!)僕らはまだ大きなお客様でのdual SSD failureというのに遭遇していない。

Rebuild時間はHDDよりずっと早く障害状態も短時間のはず。

  • snapshot 機能の充実(すでに結構いいものだけどもっとよくなった!)4倍の snapshot ボリューム機能、リフレッシュ機能の充実、などなど。Appsync サポートによるMicrosoft, VMware, Oracle などのエコシステムとの融合も実装! .


わおー、さっすがBeast !

僕らがXtremIOに注目しているわけがわかると思う。適切なアーキテクチャ、素晴らしいエンジニアリング、ここ数年の投資とサポートを

受けうるに足りるプロダクトだよ。

 

ところでXtremIO 4.0のアップデートは以下…いっぱいあるので一応列挙しておくね

 

注意:もしかしてこのリストにちょっとしたプロダクトチームからのユーモアがみつけられるかも!

 

UIでの改善もあるので是非こっちをチェック!

https://www.youtube.com/watch?feature=player_embedded&v=MUgos1Fa8sY 

 

 

 

XtremIOはマーケットでの成功を収めている、誰が何というおうともね。そう、数がそれを物語っている。

マーケティングじゃない、お客様がその選択をして流れを作ってくれている。

low latency と安定性が必要なtransactional workloads に今や hybridを導入する必要はないんだ・・・

僕の中にあるSEの血がこれだけは別だろう、って白黒つけているのは以下。

  • RDFMainframeiSeriesサポートの必要なWorkload, それにはSSD搭載のVMAX がいいだろう。
  • 物理的にも経済的にも小さい規模、それにはVNXe, もしくは2U $25K 3TB all-flash かな。 
  • data reductionの必要ないDataでSDS + commodity タイプであればNAND の充実したScaleIOがイイのでは・・・。

XtremIO 4.0の素晴らしさはこういうこと(上記参照)じゃない・・・・・

本当に大切なのはこういった成功例ではなくもっと大人な話

僕らはAFA業界の leader 的な地位を築いて、これからももっと成長していくけれど、それはつまり数多くのXtremIO を野生に返す、ということに

他ならない、つまりXtremIO の持つ機能性を沢山の人に(もちろん競合各社にも)公明正大に知らしめていかねばならないってことだ。

競合各社が盗もうとしたって、そもそも僕らに隠す気はないからね。。無駄ってもんだ。

とにかく。。。。。

ここからはメインストリームになりつつあるXtremIO AFA関連情報。やっと導入実績も統計が取れるくらいに増えたからね。

上記がその一部情報。これがEMCを含む各ベンダーの数字。

Run Rate(前期の稼働実績)×4の売り上げってことは全体でみると$1B規模での成長。といってもお客様が$1BXtremIoを買ったのではなく計算で言うと$250Mの収益を得た計算になる。

Growth rates(伸び幅)これは小さなビジネスについて考えるのではなく、大きな枠で計算したほうが正確な数字が出る。だってもし$200Kを売ってその次のQ$20M売れば、結局10,000xの成長って言えちゃうだろう・・・・


で、どこまで話したっけか。。。


他に大切なのはお客様満足度・・・・

customer satisfaction これはいってみればリピート率。どれだけお客様がその製品をすきになってくれたか、ということに尽きる。


他の点としてAFA “Tier 0” もしくは“VDI” storageという認識から 広いData圧縮率、エコシステムへの浸透、などにより “broad transactional workload use”へと変革したか・・・ってことも重要なポイントではある。

僕が信頼する競合他社もthinプロビジョニングはdata-reduction技術ではない、というだろう。オペレーションをシンプルにはするけれど。

とにかくdata-reductionってのはそんなものじゃない。

僕の書き物に関してその競合他社はきっと「僕らのことだ。。」なんて思うかもしれない。

しかしカーリーサイモン(アメリカの歌手。サイモンシスターズ)のの名言に「この歌が自分のことをうたっているなんて

思うあなたはかなりの自惚れやだわ」にあるように、僕は誰かのことを言っているわけではない。

ただ、data reduction に関して鉄拳の決まりやスタンダードは無い。ってことを言いたいだけなんだ。

 

興味深いのはthinプロビジョニングを使っているお客様ってのはそれを止めることができない。。。ってことだよ。

下の表を見て。。。

 

thinプロビジョニングは今や広く採用され浸透している。しかしthick使用のプラットフォームだって同じころに紹介されたのに

そんなに使っている人がいない。これは長年培ってきたものへの馴れ、信頼みたいなもんで、なかなか違うものへの発想の転換ができない、

ということだと思う。

もちろんXtremIOのデザインは最高。これはアーキテクチャの機能追加、というよりもその追求結果としての意味合いが強いからね。



結局、data reduction って何?

先週素晴らしいお客様との出会いがあった。

彼らはすべてをEMC製品にしてくれている素晴らしいお客様なんだけどね。VMAXVNX,CX4,(この間やっとCX300 を引退させた・・・!)

ローカルチームはVMAXに変わるストレージとしてXtremIOをおすすめしている状況なんだ

AFAにおいて一番の魅力は$/GB、すなわちdata reduction機能だ。というのもきちんと設計されたAFAdata reductionを通常のオペレーション

として常に行うからだ。一日の書き込み量(WPD)とそのNAND media費用は日々さがっていく一方でこれ無しではTCOはそこまでクリアにはならない。とはいっても・・・・このお客様はdata reductionに関してかなり懐疑的だった。ローカルチームはMitrend dataを使って実際彼らのData4:1になるであろうことを示唆した。お客様的には、コンサバティブに3:1の試算で落ち着いたけれど。またそれまで稼働していたVNX/VMAXWorkloadXtremIOへ移行するのも簡単にできることを示し、その他に関しては、MainFrameRDFはそのままVMAXにVNX NAS に関してはIsilon へ、そして小規模なNAS系はそのままVNXに適宜対応することでお客様の不安をやっとのことで取り除くことに成功したんだ。


お客様の懐疑的な思いは十分にわかる、、だからこれを読んでいる君にもDataを示してその不安を取り除こうと思う。

これは1,400以上のお客様とCluster の導入実績からとったData。おそらく君の考えもそれで変わるだろう。。。。


重複排除:書かれたものってのはすべてオリジナルでユニークなものということだ。XtremIOの重複排除は機能ではなく仕様。これは常時インラインで行われている、そのRate2:1から3:1 10:120:1と数値の出ているお客様もいるけれどこれもまた真実。

圧縮:きれいに配列されたDataはもっと整理された形で配置される。ほとんどの場合41-60%のスペース有効活用が可能になる。(あくまで物理スペースの話でコストの話ではない。)

何が重複排除に最適(Server Image等)で、向いていないのは何か。(databasesなど)

何が圧縮に向いていて(databaseなど)、そうじゃないのはなにか。(Server Image等)ということはよく知られている。

しかしWorkloadというのは一定ではないから,結局トータルでのdata reductionがその目安、としかならない。


だから、XtremIOのようなproven technology(証明された技術)が君の環境をもっと経済的にするんじゃないのか・・・・

Data reductionにはスタンダードはない。あるベンダーでは“eliminated repeat zeroes”0計算部分の抹殺!)が圧縮の一部であったりする。

僕らはそうじゃない。またほかのベンダーはSnap機能にそれが含まれていたりする。僕らは違う。僕らがはっきり示すことができるのは混合されたWorkload全体でその圧縮率が3:1から5:1だということ、それだけだ。


Data reductionから先のことって? –ロード、書き込み、消耗について(お客様の興味のポイントは今これら)


(これは今時のDataCentreやお客様環境の状況を表にしたもの・・・)

上記の表真ん中にあるような極例として125K IOpsで無停止、というお客様が存在する。また一方でR/Wが1PB以上というお客様もいる。

平均的なXtremIO 30TBのフラッシュを保有しているので平均、6か月間に30倍以上の書き込みを可能にする。僕らはXtremIOを一年くらい

販売しているけれどほとんどの販売がQ3/4だ。

 

NANDWriteに弱いのは知っているだろう。だからあの手この手でAFAへのWrite少なくするように工夫がなされている。

XtremIOの特色としてすべてのWirteにある固有のobject data distribution modelの抽出を行うことだ。これにより不要なWriteが発生することを防ぐ。そしてCluster内でその情報(Write)は公表される(シェアされるので同じように不要なWriteの発生が無い)


 

これはClusterOverWriteをするまでのグラフになっている。平均で6か月以内。


こちらは真面目な機能説明のためのスライド・・・

 

Writesは完全に分散される。SSDHotSpare はないし、hot spot もない。そこから考えるとXtremIO NANDmagnetic mediaとして

使っていない事を意味している。すべてのWriteは固有にhashe計算され、分散される。その方法で無用なWriteは避けられる。

無用なWriteを避けることでSSDのLifeを長持ちさせる。

中には6PB のwritesがあった客様で、各SSD98Write Life が残っていたという記録もある。正常じゃないって思うかもしれないけど

本当にあった事・・・全てのお客様で見ると“life left”な状態というのは案外多い、95%から100%のWriteLeftがその大半だ。

 

 

じゃあavailabilityは?

 

XtremIO 3.0のお客様からのコメントはこれ・・・

僕らだってパーフェクトではないんだ。。。

障害対応はどんなプロダクトでも起きる、ただそれをどうやって対応するかによってお客様の印象や信頼は変化してくる。

僕らはいつでもベストを尽くす!


障害はエピソードであって統計ではない。XtremIOはお客様満足度において上位の部類だけれどそれは製品が素晴らしいからだ。

XtremIO 4.0からはAFA marketでベストのRemoteReplicationがサポートされる。これはRDFではないけれどそれに匹敵するとおもう。


これからの課題として、絹の様なスムーズアップグレードを可能にするための技術を開発中。

Native Remote Replicationの実装に向けての開発。


改良はXtremIOmission criticalな環境には不向き、ということではない。金融系でXtremIOを採用している

お客様を僕は知っているしね、そしてほら、full sync replicaその上、FAST.X VMAX3 XtremIOサポートが必要だって?

僕たちならそれができるよ。そしてActive-ActivevSphere clusterXtremIOのサポートも可能だ、さらにVPLEXとだって大丈夫。

 

XtremIO 4.0ではAFA業界ではベストな製品だ。そしてオンラインでのアップグレードが可能(XtremIO 3.0から)

そして僕らはそれだけでは止まらない。。2015年を通じて様々なアップデートを加えていくつもりだ。もちろんVVOL supportも含めてね。



このスレッドはVirtual Geek の作者の許可をもらって日本語訳にしています。

 

 

こんにちは。吉田です。

 

今回は「VxRack」の真価とも言える優れた管理機構についてお伝えします。

 

尚、ここで紹介する内容は「Tech Preview」段階のものであり、正式リリース時における製品仕様や画面構成等は異なる可能性があることを予めご了承ください。

 

前回のブログで、VCEが提供する予定のコンバージドインフラ「VxRack」は、拡張性に優れており柔軟性も兼ね備えるアーキテクチャーであることをお伝えしました。しかし、IT部門のインフラ管理者としては、実運用レベルでの管理手法やツールが気になるところでしょう。当然ながら、ノードの拡張に比例して管理が複雑になってしまうと、管理コストが増える結果となり本末転倒の事態に陥ってしまうためです。

 

ご安心ください。

 

VxRackは、ハードウエアの管理とリソースのオーケストレーションを統合的に管理する仕組みが備わっており、そのような管理者の不安を一掃します。ここでは、具体的な操作画面イメージを見ながらご紹介しましょう。

 

 

 

ハードウエアの管理

 

VxRackは、ラックやノードの単位でビジュアルに管理できます。ノード毎にハードウエアの詳細情報も確認できます。また、ノードやラックを追加する際も、簡単なオペレーションで自動的に認識され追加作業が完了します。

vxrack_01.jpg

 

 

 

リソースプールの管理

 

VxRack は、VMwareとKVMなど同一ラックに異なるプラットフォームを混在させることができます。各基本コンポーネントは、ハイパーバイザーやベアメタル(OS)レベルで認識されます。下図ではVMwareとKVMのクラスターとRed Hat(ベアメタル)が認識されている状態を示しています。また、ストレージはEMC ScaleIO(2つのプロテクションドメイン)が認識されており、ネットワークはVLAN(2つのVLAN)が認識されています。

vxrack_02.jpg

 

 

 

デプロイメント

 

認識されているハードウエア(ノード)に対して、簡単な操作でハイパーバザーやストレージ、ネットワークを展開できます。下図のようにコンピュートリソース(ハイパーバイザー等)やストレージ(ScaleIO)、ネットワーク(VLANやネットワーク仮想化技術等)の展開タイプを選択して、実行すると自動的に展開される仕組みです。大規模な環境ではこのようなオーケストレーション機能が必須だと言えるでしょう。

vxrack_03.jpg

 

 

 

モニタリング

 

ハードウエアレベルの監視機構も備わっています。ノードやネットワークレベルの状態と使用状況が確認でき、物理的な接続構成も把握できます。具体的には、ネットワーク帯域、スループット(IOPS)、ストレージ容量、コンプライアンス、ノードタイプ、アラート等が確認できるようになりそうです。

vxrack_05.jpg

vxrack_04.jpg

 

 

 

アップグレード

 

実装されているシステムのアップグレードも容易に対応できます。

vxrack_06.jpg

 

 

 

このように、VxRackの優れた管理機構によって、管理者の負担を減らすだけではなく規模に関わらず迅速な導入が実現され、大幅に管理コストを削減できます。高い拡張性が求められる環境には、このような仕組みを備えたコンバージドインフラも導入対象として十分検討に値するのではないでしょうか!

 

 

<関連記事>

VxRack Management Prototype @YouTube

KZ

XtremIO 解き放たれた野獣

Posted by KZ May 12, 2015

先日開催されたEMC World 2015でEMCのオールフラッシュアレイであるXtremIOの新製品が発表されました。EMCは、2014年のワールドワイドにおけるオールフラッシュアレイ市場においてシェアNo.1を獲っていますが、今回の発表はさらなるシェア拡大に繋がる内容となっています。

 

発表の主な内容は、「新しいハードウエアのリリース」と「新しいソフトウエアバージョン(4.0)のリリース」です。

 

 

新しいハードウエアの登場


XtremIO は、X-Brickと呼ばれる単位で増設するスケールアウトアーキテクチャのオールフラッシュアレイです。X-Brickは、主に2台のコントローラーと 25本のフラッシュドライブを搭載するディスクエンクロージャーから構成されています。X-Brickを増設することでコントローラーとフラッシュドライ ブが増え、クラスタの性能と容量がリニアに増える仕組みになっています。

今回、40TB X-Brickモデルが発表されました。これまでの10TBモデルと20TBモデルに加えて3モデルのラインナップになります。40TBモデルは、容量増 に合わせて実はコントローラーも増強されています。新しいCPUが搭載され、メモリが倍増されています。

image371.jpg


新しいソフトウエアバージョン(4.0)

 

今回のバージョン4.0では、オンラインでX-Brickを増設できる機能やRecover Pointと 連携したリモートレプリケーション機能、スナップショット機能の強化、さらなる信頼性の向上などが含まれています。これまでもXtremIOはエンタープ ライズストレージとしての機能強化が加えられ続けてきていましたが、今回のバージョンでエンタープライズ用途で必要とされる様々な機能が全て備わったと言 えます。XtremIOは性能が優れているだけではないのです!

バージョン4.0は、40TBモデルを含む全てのモデルで利用することがで きます。また、バージョン3.0を搭載した10TBモデルや20TBモデルの場合、サービスを止めることなく4.0へバージョンアップすることが可能で す。(※ 40TBモデルはバージョン4.0のみをサポート)

image370.jpg


野獣たる所以

 

今回発表した40TBモデルは「野獣(Beast)」と呼ばれて発表されました。これは、X-Brick単体の容量増とバージョン4.0でクラスタを構成するX-Brickの最大数が8になったことによるものです。

まず容量の観点で見てみましょう。クラスタが40TB X-Brickの8台構成で、サーバー仮想化環境のような重複排除率が6倍となる環境で利用した場合、2PB近くの大容量を持つストレージになります! しかも44U分のスペースで!!

image372.jpg

 

次 に性能の観点ではどうでしょうか。ReadとWriteが混在するワークロードでX-Brickあたり15万IOPS、100% Readのワークロードで25万IOPSの性能を持っています。つまり、X-Brick 8台でそれぞれ120万IOPS、200万IOPSもの処理が可能なのです! しかも1ms以下という高速な応答時間で! その上、重複排除が利けば利く ほどI/O処理性能はさらに向上します。

image373.jpg

 

大容量&高性能な野獣ですが、エンタープライズ向けの様々なことができる多才な野獣であることも覚えておいてください。

 

EMCは、XtremIOを戦略的製品の一つとして位置付けており、XtremIOへの投資を強化しています。この先、野獣を超えるどのような怪物が出てくるのだろうかと想像すると今からワクワクしてしまいます。気が早すぎですね(汗)

EMC World Day 2: Federation Enterprise Hybrid Cloud 3.0

Enterprise Hybrid Cloudとはフェデレーションスタックに関連する、開発、試験済みのクラウドのスタックをパッケージ化したものなんだ:センター向けにvSphereとvRealizeスイート、パブリッククラウドに対してはvCloud Air、そしてViPRがストレージの抽象化/自動化レイヤーに利用される。

 

BLOCKS、RACKS、APPLIANCESのポストで言ったように、コンバージドインフラストラクチャは「クラウドへの簡単なボタン」なんかじゃない。全ての形態(Vblock、VxRack、VSPEX Blue)でコンバージドインフラストラクチャーが行うことは、インフラストラクチャがごちゃごちゃになることを防ぎ、もっと重要なこと、例えばきちんと動作するEnterprise Hybrid Cloudを構築することにフォーカスさせることなんだ。

 

クラウドを本当にクラウドとするものはクラウドマネージメントやクラウドオーケストレーションレイヤーにある―すなわちvSphere vRealizeスイート(その他にもOpenstackなんかも)なんだ。とはいってもこれらのどのスタックも「鍵を回しただけでスタートする」ようなものでも簡単に組み立てられるようなものでもない。これまでもお客様に僕はそう話してきた。

 

フェデレーションが提供するEnterpise Hybrid Cloudは一つの開発されたクラウドマネージメントスタックだ。これには多大な開発が必要だった。なんせ他のITサービスマネージメントツールやバックアップ、災害対策、セキュリティ、NSX、ViPRやその他のインフラストラクチャー要素と統合させるっていうことに対し、我々の経験をタイトなスケジュールに詰め込んで行う必要があったんだ。そしてやっと準備が出来た。ほとんどのお客様はまるでハンバーガーを注文するかのように何万もの仮想マシンを準備出来る:-)

 

世界中にいる大規模なお客様(本当に何万っていう仮想マシンのスケールで利用しているところだ)に対して、フェデレーションのEHCは素晴らしいスタートポイントになる。その程度の規模になってしまうと、まず間違いなくハンバーガーを買うようなものではなくなってしまう。しかしながら我々はサービスを提供した全てのお客様に対して、フェデレーションEHCスタックに対する学びを還元できるような仕組みを構築しているんだ。

 

そしてEMCと認定を受けたEMCパートナーがそれを提供することが出来る。

 

...素晴らしいことに、物理レイヤーにおいて、EMC/VCEのコンバージドインフラストラクチャファミリであるBLOCKS(Vblock/VxBlock)の上に、EHCは最高で最速に展開される。将来的にはEHCはRACKS(VxRACK)上、さらにはAPPLIANCES(VSPEX Blue)上でも動作するようになる予定だ。

 

宣伝文句は本当にシンプルなんだ:Enterprise Hybrid Cloudより早く、より良く、より素晴らしいセキュリティ/フレキシビリティ/特性をもつものなんて存在しない―根本的に全てのお客様は俊敏性とイノベーションをドライブしていく必要があるんだ。そしてその公式はもう証明されている。使ってごらん、そうすればIaaSハイブリッドクラウドを数週間で手に入れることが出来る。

 

EHC 3.0の新しいポイント:

  • ViPRコントローラなどのEMCコンポーネントやVMware vSphere、NSX、vRealizeスイートのアップデート
  • VCEは工場でVblockやVxBlock上にフェデレーションEHCスタックを組み込むことが出来るようになる―従ってより簡単に、鍵を回しただけでスタートするようなものになり、デプロイメントのコスト低減がはかれる
  • Application as a Service―新しくリッチなアプリケーションの青写真が出来るようになる(Puppet Manifestsの利用を含む)
  • Hadoop as a Service
  • ストレージターゲットとしてのScaleIOのサポート、VMAX3、VPLEXとIsilonターゲットに対するアップデートも同様(Vblock/VxBlockとmix-and-machの両方)
  • Puppetとの更なる統合
  • Service Nowとの統合
  • Data at REST Encryption as a serviceのためのCloudlinkとの統合(異なる表現を使うと、クラウドをまたがった運搬性)

 

ドキュメント類(ソリューションガイド、アーキテクチャリファレンス資料、サイジング等)は間もなくここで公開予定。

 

Application as a Serviceの可能性に関する素晴らしいデモがあるのでここで紹介しよう!

このBlogはVirtual Geek の作者の許可をもらって日本語訳にしています。

May 04, 2015

EMC World Day 1: vVNX (Project Liberty) and VNXe 3200 Update

 

12thmay1.jpg

追記(5/5/15 - 10:08am PT)– 現行vVNX code はVVOLsのサポートをしていない。僕の意図としてはQ3くらいにはVNX family でのVVOLs試乗がかなうんじゃないかな、、と思っただけ。Download, try, use でVVOLs はすぐにvVNXに追いつき、そのあと, native support も続くだろうってことなのでそれは追記させてもらう。

 


プロジェクトLiberty。世界はsoftwareタイプのVNXをダウンロードして使えるようになる!

そう、無料。時限爆弾とかもなし。本当の意味での無料。コミュニティーで沢山のuserに使ってその良さをわかってもらいたいから。

 

Step 1 - Download こちら

Step 2 –コミュニティーをびっくりさせる。

Step 3 – 楽しんで使う!

僕らがこういうことをするのは初めてではないけれど(virtual NAS stackの無料配信を随分昔にやった・・・)

今回VNXの機能を余すとこなく提供出来るということは本当に喜ばしいことだよ。

 

vVNXは学んで、使ってみて試してみて、APIsを開発したりするのに最適

vVNXOEM use case向けにStorageを提供するのに最適

vVNXは何をするにしろPublic Cloud 上でのテスト等に最適

vVNXdata servicesとして最適。FileSystem として、そしてdedeup/compression engineとしても使える。

 

で、これがほかにできること!

12thMay2.jpg

 

いくつかのUse Case はすでに提供されていたりする。(VMAX3上のvVNXだとかね)

VNX/VNXeなどのFull プロダクトとvVNXの間にはちょいと差があり、(FAST Suite無、FC, Recoverpoint無、HA variation無、など)

パフォーマンスに関しても使用するハードウェアの性能によってかなり左右されるけれども・・・・

 

これがVNXで今起きていること。ちょっと説明するよ。

 *それはvVNXが明確なUnity codebaseを持っているということ。VNXe 3200Unified でコンテナ化されたlightweight linux kernel

上のCodeだけれどこれで様々なData Services を提供することができる。

vVNXをダウンロードするとVNXeよりもそれが新しいと感じるかもしれない。これはUnisphere ManagerHTML 5使用の(no Java!)完全なる

証明だし、VVOLサポートがvVNXで最初に実装されることにも通じている。

Note: vVNXではまだVVOLサポートは始まっていない。これはQ3 vVNX updateで実現する予定。そしてそのあとにNativeVNX,VNXe自体 supportに続くvVNXはいわば新機能のテストフィールドとしての役割を担っている。

 

vVNX のデモビデオ

https://www.youtube.com/watch?feature=player_embedded&v=HFr1QpHMtXI 

 

話題のvVNX VVOLs のビデオ

https://www.youtube.com/watch?feature=player_embedded&v=3jakAqiS1HQ

 

 

 

Unity transitionはそこまで来ている。integrated/containerized codebaseが羽ばたこうとしている。

つまりVNXe 3200 all flash variationのリリースだ・・・・

 

VNX/VNXeはハイブリッドの代表だけれど少ない費用で小さなパッケージで Block/NASなどの異なる

Data Services を提供することができる。しかし早いわけではない、しかしすごいことをやってのける!

 

VNXe …3TB Flash, 75,000 IOps ,そしてもちろんblock/NAS対応、2U ラックがなんと$25,000.

お客様やチャネルパートナのために、ことをなるべくシンプルに、そして単一価格設定を実現。

だからパートナーはEMCの顔をうかがうことなく自由に見積もりが取れるってわけ。

 

以下の表はall-flash構成の値段表。“*”street pricehttp://store.emc.com でオーダー可能。

12thMay3.jpg

 

この2Uの小さなシャーシに25のスピンドルを入れたのがわかると思うが、それでHDD追加がどんどんできるんだ。小さいのにとってもパワフル!

 

VNXe 3.1OEは強力なperformance boostも追加されているし、(SSD IOpsなら30-50%増SSD bandwdith10-20%増)さらにFAST Cacheの増加(400GBまで)も組み込まれている。iSCSI接続に関しては今まで通りなのでそこはもうちょっと改善の予知あり。。

 

またVNXe 3.1は次世代VNX transactional filesystem であるUFS64に対応している。初代なのでそんなにメインで使うって

ことはないだろうけれどこれは64TBuse caseをサポートしFileSystemshrink/reclaimする。UFS64に関しては改善しなければいけない

点がまだまだあるけれどVNXコードも含めて将来を見据えた形として進んでいるのはわかるだろう。

 

ところでVNXeだけが追加機能などの恩恵を手にしたわけじゃない、VNXVDMではVDMNASに対してMetrocluster alternative

を実装することになった。これだけじゃなくVNXへの機能追加も2015年中に起きるよ!

 

と、ここまで話しておいてStorage業界全体の流れについて話をしないのはフェアじゃない、そしてVNXeのようなSMBStorage

を柱にしているようなベンダーへの影響も話したほうがいいよね。。(そうそう、おっきい会社だけじゃなくてさ・・・・)

 

VNX/VNXeのようなtransactional storage architectures$10-1M規模のストレージ業界は多方面からのテコ入れを受けている。

SDS + serversという組み合わせと“Tier 2”ストレージであるVNXでの容量の差。たとえばScaleIO/commodityVNX

を比べた場合、経済的な面、Data層の深さ、また柔軟性と水平性を保つスケールアウト機能等がその判断の材料となり、ScaleIOに軍配は上がる可能性が高い。

block workloadでのlatencyについて。AFAの抜群の処理能力は注目すべきで、たとえばXtremIOtransactional workloaddatabase, virtualization, EuC, EPIC,)に導入され人々の支持を得ている。

*小さなNAS 諸島的なサービス提供から、scale-outで飛躍的に拡張が可能なNAS サービスへの変換、またObject Storage への融合をも可能にしてしまうIsilon の登場。(1顧客で100PB購入という嬉しい出来事も発生した!)またElastic Cloud Storage AtmosといったObject系の浸透。

VNXserver接続で可能だった仮想化がhyper-converged applianceVSPEX Blue(VSAN使用) VxRack(ScaleIO使用)の出現でより柔軟性拡張性に優れてきたこと。

 

つまり・・・・

上記のVNX逆風状況の中でどこがVNXSweetSpot(強み)なのか、ということになると・・・・・

 

小規模な範囲で多目的業務を担う、そして頻繁にスケールアウト、ダウンが必要となってしまうような環境がコスト面、業務形態の推移、パフォーマンス、などを加味するとVNXVNXeの強みが一番よく出るフィールドではなかろうか。

 

hyper-convergedがそんなにData層の厚さを持っていなかったり、AFAがスケールダウンには強くなく、またスケールアウト型NASNAS機能そのものには強くない、というのは留意すべき点だと思う。

 

もっと簡単に、vSphere/Hyper-V/ Block/NAS,が使えて2-8TB の flash , 50-100,000 IOps, 充実したsnapshot, compression, dedupe などの機能が2Uにまとめられたもの!


それは何か。ここまで読んだ君ならわかるだろう。

 

 

 

このスレッドはVirtual Geek の作者の許可をもらって日本語訳にしていますhttp://virtualgeek.typepad.com/virtual_geek/ 

May 04, 2015

EMC World Day 1: VMAX Update

 

 

VMAX 3は今ノリノリのプロダクトだ。Q4 2014にはTier 1 storageとしての指標機能であるSnapVXSRDFの完全装備も果たし、コアdata service

としての地位を確立した。EMC Worldではenterprise data serviceとしてのVMAX3の新しい動きを発表させてもらった。

 

僕らがたどってきた外と内での戦いの道のりを振り返ることはこの話には必要かもしれない・・・

 

“consolidate all your workloads in one place”(すべてのWorkLoadをひとところに)的な時代はずいぶん前に終わった。エンタープライズ系で

壮大なRDBMSを一つのプラットフォームにまとめるというのは多言語時代に生きる僕らにとって愚行でしかない。

*そして“Tier 1 Enterprise arrays”は様々なWorkload 環境でmaximum performanceを長いこと期待されてきた(コスト面では目をつぶりてきたが)

*上記から“Tier 1 Enterprise arrays”は絶対に止まらないサービスの提供、構築環境による様々なWorkloadへの対応の道のりを歩み、それは

どこまでも続いていくものなのだ。

 

僕が強調したいのは最後の点だ。

 

VMAX 3はただの“reliable”をなストレージではない。もちろんAFASDSモデルだって“reliable”であり“available”である。

特にXtremIOの導入実績などは99.9995% availablityを記録しているし、VNXScaleIOもそしてIsilonだってhighly availableなのだ。

 

VMAX 3における“reliable”がどういうことかというと・・・・

3 site replication0 RPO(即時性)もしくは0 asyncのリプリケーションが可能である。そしてそれも大きな規模下で。(何千デバイス、それに伴う変更、使用帯域に耐えうるということ)

*大きな規模でのconsistency groupのサポート

*数千terabytes petabytes規模のOracle databasesのための T10DIFの導入

*リモートでのreplica起動、(active/active remote replicaも採用)

MainframeiSeries platformのサポート

 

上記がすべて可能なAFAは無い。もちろんAFAの様にドレスアップしてそれっぽく動くハイブリッド系もある、がそういったものが上記のような動きができるか、というとそれも怪しい。

 

上記にあげたようなEnterprise availability services“Enterprise availability data services”)はちょっと新しいものかもしれない。

“Tier 2 storage market”にはなかなかないものだし大げさに見えたりするから。。。しかし“Enterprise Tier 1 storage”においては

これは決して大げさな話ではない。

 

僕らはVMAX3“Enterprise Data Service Platform”なのか“monster workload consolidator ”(高負荷処理機構)なのか、といった議論に巻き込まれるつもりはない。XtremIOScaleIOで処理するようなWorkload VMAX3 でとってかわる、といった話でもない。

 

つまりVMAX3 にはVMAX3に最適なdata service形態があるということだ。そしてそれはbanking/financial/healthcareなどのミッションクリティカルな

環境だけでなくSaaSsoftware as a services )環境でも必要とされていることに驚いてはいけない。

 

こういった背景を元に恒久的に安定したサービスを様々な環境でEnterprise Data Services platformとして提供するためにVMAX3は改良を

重ねた。特記すべきはsoftware updateだ。

 

FAST.X

RDF, Host IO QoS, ProtectPoint, SLO based managementなどのData ServiceCloudArray 経由でXtremIO public cloud object storageへ拡張可能

SRDF/Metro

active/activeモデルの実装(VMAX<->VMAX

HyperMax model機能への対応、またコンテナ機能の増加、つまりはViPR Controllerへの対応。embedded NAS (eNAS)機能に始まるコア機能の追加。

ProtectPointへのサポート拡大。

VMAXはもちろん従来の機能に関しても抑えるところは抑えている。高負荷なRDFへの対応、mainframeサポート、T10DIFサポートなどなど。


これが世界中の絶え間ない動きに対しての答えではないけれど(一つのプロダクトでしか勝負しないなら別だけど)ある方面においては

これが絶対の答えにになることは間違いない、と思う。

 

このスレッドはVirtual Geek の作者の許可をもらって日本語訳にしています 

EMC World Day 2: ViPR Controller is now Open-Source.

僕はこれがEMC Worldで(VxRack、XtremIO 4.0なんていう全くもって素晴らしいものたちのように)大きなプレスリリースになるとは思わないんだけど、これは恐らく最大の戦略的なアナウンスメントなんだと思う(Manuvir Dasがそれについて話をしているここを見てもらいたい)。

 

これは単にViPRコントローラがオープンソース化するっていうだけの話じゃない。これは基本的なEMCの戦略のシフトと積極的なオープンソースの受け入れを意味しているんだ。これはその最初であって、今後はもっとたくさん出てくる。

 

昨年の5月にもどろう、西海岸と東海岸の本社をつないだテレプレゼンスで、エグゼクティブチームは我々が十分に早く動けていないことに気が付いた、つまり新たな世界は我々が追いつき追い越さなくっちゃいけないイノベーションのスピードを加速していたんだ。

 

その新たな世界(違う言葉でこれを言うなら-IDCはこれを「第3のプラットフォーム」と呼び、Gartnerは彼等が呼ぶBimodal ITモデルでの「mode2」と呼ぶ)とは以下のように定義できる:

 

 

  • 異なるスケール:100万 対 10億
  • 異なるキャパシティ:テラバイト/ペタバイト 対 エクサバイト
  • 異なるアプリケーション構造:Monolithic 対 複数の要素からなるmicroservices
  • 異なるデータpersistenceモデル:リレーショナルデータベース "single version of truth" 対 "Polyglot Persistence"
  • 異なる抽象化/開発モデル:仮想マシン 対 コンテナ
  • 異なるスケーリングモデル:スケールアップ 対 スケールアウト
  • 異なるマネージメントモデル:ペット 対 家畜(の牛)
  • 異なるオペレーション/組織/文化モデル:IT Ops+ITIL 対 DevOps

 

 

でもそれはまた別の言い方をしても違いがわかるんだ。一般的に...

6a00e552e53bd2883301b8d10d661c970c.png

...が勝利する。Pivotalもまた学んでいたんだ(CF ガバナンスのためのLinuxファンデーションのプロジェクト作成+GreenPlum、HAWQ、Gemfire、Hortonworksと共に活動したODPなどのオープンソース化を通じて)、そしてVMwareもそう(VIO、NSXを通じたNeutron workそして今はProject PhotonProject Lightwaveだ)

 

何で「第3のプラットフォーム」にとってオープンソースがそんなにも重要なのかって?このクローズソース対オープンソースの原動力について、我々が持っている結論―そしてライセンシングモデルの正確な詳細、ガバナンス、どこからその全ての要素を得るのか、などなどについて... もっと学ぶためにも是非読み続けて!僕は行く先々で実験をしてきているんだ―ちょっとゲームをしてみよう :-)

 

目を閉じて。

 

次のいくつかの言葉を読んでみて、そしてあなたの心に最初に浮かんだ言葉についてコメントしてほしい...準備はいいかい?

 

“OPEN SOURCE”.

 

多くの国や多くの異なる言語や文化で何千人もの人にこれをやってきたんだけど、僕はその最初に浮かんだ言葉は「無料」であるって賭けるね。このゲームをすると、面白いこと人々は作業、コード、スタックという言葉にまとまっていくんだけど、実はそんなことを彼等は言っているわけじゃないんだ。彼等はこんな言葉を言っているんだ:

  • コミュニティ
  • 摩擦がない
  • 簡単
  • イノベーション
  • 貢献
  • コントロールされない=ロックインされない

このモチベーションは「のり(糊)」であるIPスタックに対しても当てはまるものだ(なんせそれらはロックイン/コントロールポイントになるものだからね)。これが何故我々がViPRコントローラを最初に対象としたのかの理由なんだ、だってそれは「のり」だからね。データプレーンに関することはあまりクリティカルなものではないようにみえるのだけどさ(でもやっぱり重要だ)。

 

それから2、3ヶ月後(もう既に我々はこの路線で行くと決めていた時だ)、我々は最大のViPRコントローラカスタマーをこのトピックの審議会に連れて行ったんだ、彼らに我々の方向性を聞いてもらいたかったからね。ViPRコントローラは成功している。約1,000のカスタマ―がいるし、ほとんどみんなオープンストレージ抽象化/自動化レイヤーの考え方は正しくて必要なものだと言ってくれている。そしていつでもそうなんだけど、物事をもうちょっと上手くやるってことはいくつもあって、それについて彼等は話をしてくれたんだ:-)  彼等はさらに複雑化したレイヤ化されたスタックをより速く処理する機能を求めていた。それにCisco UCS Director、Service MeshとService Now、その他にもPuppet、Ausibleなんかの上位との更なる連携を求めていたし、その他多くのストレージターゲットとの下位連携についても求めていた。もう使われなくなったストレージに対するよりよいサポートなんかも求めていたんだ。

 

でも最も大きなリクエストは次の通り:「この考え方は今や我々のスタックの中でクリティカルなものになっている、そのためにあなたがたはこれをオープンソース化する必要がある。その3つの理由は:1)我々が貢献することが出来る;2)コミュニティが貢献することができる;3)それによってコントロール/ロックインのポイントにはなりえなくなる」

 

耳を傾けてみると、カスタマーの声というものはほとんど常に正しいんだ。この場合は、我々が進もうとしている方向が正しいってことを確認する作業になったってことだ。

 

さて、ここに我々のスコープを書いてみることにする:

  • オープンソースプロジェクトはCoprHD("Copperhead")と呼ぶことにする。ここ2、3ヶ月でViPRコントローラチームは開発モデルをCoprHDをTrunkとして利用するものにシフトさせてきた。そしてViPRコントローラは「EMC配布の」CoprHDであるというgoing forwardモデルになる。
  • CoprHDコードとCI/CDツールの入っているgithub repoが30日以内に準備される。そのrepoが準備され次第、そのリンクをこのポストにアップデートする。そこはEMCの全てのオープンソースプロジェクト(ここにあるもの:EMC{code})が利用する場所になる。
  • CoprHDはMozilla Public License (MPL) 2.0モデルに従う。これで我々が本気の対応をしていることがわかるだろう。技術的に、他のディストリビュ―ション達を見ることができ、それが他のプロダクトに利用されていることも見ることができるだろう―まぁそれらも全てMPLライセンスに従うわけなのだけど。
  • ViPRコントローラは定期的にCoprHDのTrunkから切り出され(branch off)、いくつかの追加機能(より強固な認証、EMC Secure Remote Servicesなどなど)と共にEMCから商用品として提供される。これはViPRの経済モデルを変えるものではなく、ソフトウェアライセンスと保守/サポートの要素がつくものだ。カウンシルやNDAに従った議論からのカスタマーフィードバックは、オープンソースプロジェクトを通してViPRを更に価値のあるものにしてくれる、でも我々はそれによって価格を上げるようなことはしない。
  • CoprHDに貢献出来るようなプロジェクトは存在しなかったが、Openstackであれば恐らく出来るだろう(ViPRコントローラはCinderの考え方ととても似ている)。我々はEMCとしてCinderに貢献するし、その他多くのOpenStackに関するものと同じで、Cinderは他のOpenStackフレームワークの他のパーツと密にリンクしており、この方向性はそのままであった方がよいだろう。もちろんViPRとCoprHDはオープンでOpenStack以外にもその他多くの上位のフレームワークをサポートしている、利用してくれるものはNovaだけなんかではなくもっとたくさんある。我々はCoprHDのコードに貢献してくれる人々に対するガバナンスモデルも構築している。
  • 開始時点から我々はエコシステムを持っている。それにはIntel、SAPやその他の会社達が含まれている。このオープンソースプロジェクトの成功はこのエコシステムに参加する会社(競合も含めて)の数で計測される。

 

そう、今が我々にとってオープンソースの道への大きな最初の進出の時なのだ。我々はもう始めている―でも多くの学ぶべきことが待っている。我々は全てのどんな学びでもCoprHDとその他のオープンソースに還元する。ところでなんだが―Cloudscalingの買収の裏にあるいくつかのドライバの中の一つ(唯一のではない、その他のドライバとしてはProject Caspianのヘルプのためというものもある)は、会社の中にこのオープンソースの領域における経験とリーダーシップを吹き込むことにあったんだ。

 

ViPRチームは今このモデルを如何に繰り返し、より早い発明が出来るようにするかについて学んでいるところだ。

 

...そして我々はこのCoprHDに対する取り組みを通じて多くのことを学んでいく―これは多くのことの始まりに過ぎないということを我々は知っているんだ。

このBlogはVirtual Geek の作者の許可をもらって日本語訳にしています。

May 04, 2015

EMC World Day 1: BLOCKS, RACKS, APPLIANCES.

 

みんなに聞いてみたい!

 

Q:君は一つのコンバージドインフラがすべてのお客様に対してあると思うか?

Q:その答えはハイパーコンバージド、もしくはいつもコンバージド、なのか、それとも状況によって変わる、って思うか?

Q:大きなスケール(何千というVMとか何万とかいうコンテナの規模)がハイパーコンバージド(compute/network/memory/storage の混合)で、そうじゃなあい場合は非集中系(compute/network/memory/storage が独立)だと思うか?

Q:もし君が「コンバージドインフラ」戦略を採用しているなら、Workloadにそれが適応してしているべきなのか、それともWorkloadがコンバージドインフラの性能に適応しているべきだと(適応しないなら採用しない、もしくは目をつぶる、もしくはビジネスの形態を変える)考えるのか?

Q:どのコメントが君の行く道?

「vSphere一つをcompute/storage/networkのレイヤとして使いたい、すべての要素を統一できればすべてがうまくいく!」

「VMwareは素晴らしいけれど様々な概念もシステム構築には必要だし、まだまだ物理的な要素も将来必要だ」

「VMwareなんて大嫌いだ!XXXのほうがいい!(KVM/Openstack, Hyper-V、もしくはPlatform 2系何てくそくらえだ!)みんなPlatform 3に移行してベアメタルのcontainerに乗っけてしまえ!」

 

僕は真面目にみんなの今の気持ちを知りたい、、是非回答してほしい。集計は後日紹介するよ。

http://www.surveygizmo.com/s3/2126084/EMC-World-2015-Converged-Infrastructure-Survey 

 

ポイントはいたってシンプル。でもとても大事なこと。

コンバージドインフラとそれぞれのインフラ形態が避けられない簡素化集約化の結果だとしても、コンバージドインフラは一つの型としては形成できない。しかし時を経て経験を経てそれが進化を遂げていくことは間違いない。

コンバージされたインフラストラクチャーの多様化と増加は避けられない、と思っている。なぜか。

network/server/storage/abstraction/automationのエリアで様々な先進技術や改良がなされてはいても人々は基本的なところをきちんと見据え始めている。差分的なハイパーエンジニアリングの利益は最低限教授しているが(別枠というのはいつでもあるが)

正直hyper-scale public cloudへの理解度の加速がこういった副作用をもたらしたと思っている。恩恵はもちろん結果から来るものだけれどIaaS (Infrastructure as a Service)レイヤでのlock-in(がんじがらめ)のリスクは愚かなものだ。

そう、こういったことは熾烈な戦いだよ。だって人ってものはいつだって自分の「縄張り」を守りたいから。

今や様々な形のコンバージドインフラストラクチャーが市場には出回っている。そしてすべて異なる。

Vblock や VSPEX Blueや他のものはハイパーコンバージド基盤だし、(それぞれクラウド環境のIaaSレイヤとして)そうそう、IaaSレイヤであればvCloud Air, Azure, AWSなども同じようにサービスを提供している。

これらをそれぞれ最適化して管理しようとするならそれは時間の無駄ってもんだ。。そういうことは誰かにそれをしてもらってあなたにとって大切な何かをするべきじゃないのか・・・

しかしおそらくアンケート結果でも割れるだろうけどこのコンバージドインフラってのに関する一つの形、ってのはなかなかない。

言葉を変えればこれはコンバージドインフラ基盤の分類が必要だってことだ。ストレージでそれが起きたように。

 

僕は分類者としては不適格。。。これは沢山の議論や、EMC、VMware VCEといった要素が長年かけて作っていくものだ。これは「Invention」ではないしむしろ流れの中で自然とお客様の間で作られていくものなんだ。

 

その中でコンバージドインフラのシステムレベルでの3つの柱として取り出せるならBLOCKS, RACKS, APPLIANCESではないかと思う。

EMC/VCEはBlockカテゴリではVblocks と VxBlocksでCI(converged infrastructure )リーダーだ。そしてその中で初めてAPPLIANCE

としてVSPEX Blueを生み出した。そして業界のリーダとして初の RACK system architectureとしてVxRackを発表した。

BLOCKS, RACKS, APPLIANCESの概念を書いてみたので読んで君の意見を聞かせてほしい。

 

まずは前提・・・・・

•    ここでの話題はSYSTEM アーキテクチャ。“phylum” (XX型としての分類)もしくは別型として分けても大本が一緒、というわけではない。VSPEX Blueや他のハイパーコンバージドインフラをAPPLIANCEとして分類してもそれらすべてが一緒ってわけじゃない。これらのSYSTEMデザインに一貫した同一性はあるとしても。

•    ここでは SYSTEMアーキテクチャについて話すのであって hardware対softwareではない。 Softwareは大概にしてSYSTEMアーキテクチャを定義するが (Chuckが言うようにSoftwareがSoftwareを定義し、様々なパッケージを作り出すという考えには同意するけどいくつかの CI variationではsoftware + 自分の好きなコモディティーハードウェアや、softwareとアプライアンスhardwareの形態もある。僕の経験からするときょうびのお客様は自分持ちの機器との融合に心を砕いている気がする。これらの動きに関しての考察は大切だけれどここでいうSYSTEM level architectureの部分にはかぶっては来ない。

 

さあ、一つづつみていこう。

BLOCKS:

•    デザインセンタ= “Proven”(証明済み)

•    最優先事項=十分なインフラサービス– P2 Applications – 専門的なUseCase

•    System アーキテクチャ = 独立した個別のcompute/memory/network/storage – 様々なバリエーション、従来のアプライアンス基盤 (従来の安定性とネットワーク効用性が必要)

RACKS:

•    デザインセンタ= “Flexible” (フレキシブル)

•    最優先事項=異なるパーソナリティータイプ(P2, P2.5, P3, kernel mode VMs, containerなどなど) –広い範囲でのパフォーマンス、安定性、そしてオペレーションの簡素性

•    System アーキテクチャ =大部分が SDS layer での定義。SDS+ Commodity off the Shelf (COTS) hardwareで構成され狭い範囲からの構築が可能(しかしもちろん拡大性もあり)

APPLIANCES:

•    デザインセンタ=“Simple” (シンプル)

•    最優先事項=上記次項よりも小さいスケールからの構築、そして簡素化

•    System アーキテクチャ =大部分が SDS layer での定義。SDS + Commodity off the Shelf (COTS) hardware. で構成され狭い範囲からの構築が可能(しかしもちろん拡大性もあり)

VGday1-2.jpg

 

ここで一言。。。BLOCKが“flexible” “simple”ではないといってるわけではないよ。そしてAPPLIANCESが“FLEXIBLE”じゃないってわけじゃない。これがBLOCKのデザインセンタなんだ。「やっぱり確立されたWorkloadを変えることなくフレキシブルなサポートを確立し、なおかつ簡素化も出来なきゃね」といった議論は間違っている。聞こえはいいがそれは昔から言われている【早い、安い、安定している】このどれか2つをとれ、ってのと一緒だ。

例えばAPPLIANCE構築でシンプルにするためにハードウェア選択の幅とスケールをはかりにかけた場合、正しい選択としては選択の幅を狭めてシンプルさを取るしかなくなる・・・

他の例としてはBLOCKのデザインをしている場合、オペレーションの簡素化と従来のUseCaseをはかりにかけるとする、結局もっと複雑なオペレーションで従来のUseCaseをサポートするはめになる。 

注意 – BLOCKSの熱烈な信奉者の話ではないよ、これは。RACKの話でもない、これはAPPLIANCESについても言えることでもある。

僕の経験からするとこれって意識的にしろ無意識的にしろこういった議論は避けられることが多い。クラシックな例だよね・・・

「NASだ!Blockなんてだめだ!」「Private Could だ!Publicなんてくそくらえだ!」なんてね・・・

 

こういうのはパッションとか狂信的な熱狂から来ることが多い。これを書く前にちょうどChuckのブログ(“The Cults Among Us”)を見てたけど・・・

確かに狂信すればLife is simple ….(何も考えなくていいので楽)

 

しかしこういった狂信ってのはその人の信念やパッションから来るわけじゃない、もっと根深いものから来ることもある。たとえば

「僕にはハンマーしかないから釘で打てるもんは打てる時にうってしまえ」的な。。。僕だってそう考えるときだってある。

 

僕はこのスレッドを投入石としてみんなの議論のきっかけにしてほしい。こういった分類方法(BLOCKS, RACKS, APPLIANCESの意味も含め)が正しいのかどうか、そして自らの回答を出してほしい。。僕らの中から狂信者を出さないように!

 

Storageの分類の様にベンダー枠を取り払って考えることはとても有益だ、だって分類するときに純粋な機能や類似点をグルーピング

することができるから。同じようにSYSTEM architectureを見てみよう。構築の現場ではその違いが強みにもなり弱みにもなる。 

そしてその上でVendor枠での分類が可能になる。

 

VGday1-6.jpg

 

興味深い例がある・・・・

人々はBLOCK設備費ははAPPLICANCES やRACKS に劣る、なぜならAPPLICANCES/RACKは業界スタンダードのコンポーネントだからだ、ということを信じがちである。

しかし現実問題としてそれは違う。上記は基本的な考え方をシンプルにした表。

BLOCKのSystem architectureの設備投資費は大きなカーブを描いており、RACKS/APPLIANCEになると

それは小さな階段状になっている。

どこにボーダーラインを引くかによって変わってくるがBLOCKのそのカーブはRACKS/APPLIANCEよりも

大きくもなり、小さくもできる、、また表にない密度(capacity/IOps/compute/memory)的なところものちのち加味されなければいけない。

 

そして次の話・・・

このグラフは基本的な設備投資費であり、Price(実際の支払額)ではない。

またarchitecture本来のコストも表している、もちろん環境によって必要なものは異なるので一概には言えないが

基本の動きとして判断してくれていい。

 

他の要素…..僕としてはもっと重要なことだと思うが・・・運用費

BLOCKSはその従来型基盤を継承するため運用費に関してはそれまでのものと、コンバージドインフラ系で

あったとしても大きな差異はない。すなわち設備費のグラフ推移と同じようなカーブを描く形になる。

一方でRACKS /APPLIANCESは、もっとシンプルでスケールアウト型なのでグラフは対数的な推移になる。

 

EMCでのCIポートフォリオはこちら・・・・・


BLOCKS    Vblock とVxBlock

細分化されたハードウェアの段階的なスケールアウト

デザインセンタ= “Proven”

*広く知られ使われている。Vblock/VxBlockをリフレッシュして使っているUserもあり。

*Main FrameでなければすべてのDataCenter環境で利用可能

*SDSモデルで提供出来ないサービスを提供できる

*“Block”アーキテクチャと経済的なスケールアウト型

 


RACKS          VxRack

ハードウェアとそのLinerの機能はスケールアウト。

デザインセンタ = “Flexible”

*他のどのタイプよりもシンプル、そして構成も簡単。

*engineered system

 



APPLIANCES     VSPEX Blue

固定されたハードウェアとpersona デザインセンタ = “Simple ”

*シンプルにシンプルを重ねたもの。オペレーションだけでなく構築からシンプル

*そして経済的な構成でスケールアウトも可能なAPPLIANCEを提供可能

 

 

 

そしてこれが本日リリースの VxRack

これはRACKSのデザインセンタにより近い形、で開発された。

 

 

ちなみにこれが EMC/VCEプロダクトのコードネーム早見表・・・・・

*__Block = “BLOCK”・・・・big block消費が多いモデルでCompute/network/storage が独立している。

*__Rack = “RACK” ・・・Compute/network/storageが融合型。“open” persona としてVxRack 1000があり、VMware特化はEVO 

*In _V__Block and _Vx__ Rack・・・・V= Cisco、Vx=EMC もしくは他のネットワークタイプ。

*VSPEX ____ = “APPLIANCE”・・・・チャネル、ディストリビューターの GTM model。(ってことはパートナー販売を示す)

(VxRackに関してはのちの章でくわしく話すよ)

 

そしてこれがCI portfolio (converged infrastructure portfolio)・・・・buy as a system,(システムとして買い) support as a system,(システムとしてサポートし) manage as a system.(システムとして管理する)

上記に沿ってフローチャートを作るとするとこうなる・・・・

 

①   全てのWorkloadsに対して同一タイプのLayerでの定義を採用するのかどうか。

 

②  Applicationの種類は多いがConverged Infrastructureを使うか使わないのか(SDS layer、ネットワークの問題から)

 

③Platform2.5とPlatform3 を使うが場合によって使い方を分けたい人

 

④    もっと簡単なのが好きな人・・・・

 

VSPEX BLUEは10分以下で火を入れ動かす音ができる。

デザインセンタ= Simple であることを忘れずに。

 

 

そして最後に・・・・・

罠にはまるな! ストレージの多種多様性と同様、コンバージドインフラにもそれぞれの理由があり、種類がある。

正しい種類、そして適度な規模での選択が成功のカギだ。僕の思うCI 戦略は以下・・・・

 

•    “このCI は僕にあっているのか?”  ヒント:従来型のサイロ構造にしがみついて『違う』という人に限って大体間違っていることが多い。

•    “自分の組織化にどれくらいの時間をかけるのか? ”  個人的に言うと『なし!』だけどね 。

•    “BLOCKS系のworkloadの割合は? そしてどのモデルを使用してるのか? ”

•    “RACKS系のworkload の割合は? そしてどのpersona?オープン?もしくはVMware-centric?”

•    “APPLIANCES系のworkloadsの割合は? ”

 

自分の状況を確認してどのCIモデルがいいのか判断して。CIの選択を何も考えずに拒否するということは「臭いものには蓋」的なことだと思うからね・・

 

このスレッドはVirtual Geek の作者の許可をもらって日本語訳にしています。

こんにちは。吉田です。

 

5月4日~7日にラスベガスで開催されたEMCのイベント(EMC World 2015)にて、新しく発表された製品やサービスについてご紹介します。

今回は、新しいコンバージドインフラとしてVCEから発表された「VxRack」にフォーカスしてお伝えします。

 

 

 

時代に適したコンバージドインフラ

 

テ クノロジーの進化とモバイルデバイスの浸透により、Webやモバイルチャネルを活用したビジネスの展開がこれまで以上に重要視されるようになりました。ま た、新しいビジネスを創造する上では、ビッグデータの活用がカギとなる時代が到来しています。そのようなビジネスを支えるITインフラには、非常に高い拡 張性と柔軟性が求められます。さらに、変化の激しい環境の中で企業の競争力を高めるには、短時間でビジネスを立ち上げることも重要な要素です。今回発表さ れた「VxRack」は、今後必要とされるITインフラの要素を兼ね備えた新しいコンバージドインフラと言えるでしょう。

 

vxrack.jpg

 

 

比類なき拡張性と柔軟性

 

VxRack は複数ノードのセットで構成されおり、ストレージは内蔵ディスク(DAS)を使用します。最小1/4ラック構成からスタート可能で、1/2ラック、1ラッ ク、最大1000ノードまで拡張できます。VMwareだけではなくKVMなど他のハイパーバイザーでも使用でき、ベアメタルにも対応します。ストレージ は、VMware VSANやEMC ScaleIOが使用可能。10Gのネットワークスイッチも装備されています。

 

新しいビジネスを展開するインフラとして小規模から導入でき、アプリケーションのワークロードやリソースの需要に応じて随時拡張できる。正に、これからのITインフラに最適なシステムと言えるでしょう。

 

 

 

コンバージドインフラのラインナップ

 

EMCグループであるVCEは、従来から提供しているコンバージドインフラ「Vblock」に加え、今回発表したVxRackの提供を開始します。一方、EMCはハイパーコンバージドインフラの「VSPEX Blue」を提供しています。

 

vxrack2.jpg

 

予 めアプリケーションに最適化され規模に応じて構成が選べるVblockは、主にTier 1アプリケーション環境に適しています。また、Tier 2アプリケーションや中小企業向けのシステムには、シンプルで迅速にセットアップできるVSPEX Blueが最適です。一方、VxRackはTier 2アプリケーションや分散システムなど高い拡張性が求められる環境に最適です。

 

今後もより具体的な情報が発信される予定です。是非ともご期待ください!

 

 

 

<関連記事>

VxRack System 1000 Series @VCE Official Site

Press Release @VCE Official Site

May 04, 2015

EMC World Day 1: VxRack 1000 Technology Preview

 

 

EMCWorld一日目。VCEにより開発されたEMC hyper-converged RACK systemVxRackが紹介された。

おそらくこっちでいったようにVCEConverged Infrastructure portfolioが色濃く反映されている。こっちのブログを先に読んでもらったほうがおそらくBLOCKS, RACKS,  APPLIANCESのコンセプトがよくわかるからいいのかもしれないけれど・・・

 

とにかく、VxRackのポイントはこれ・・・

  • VxRack RACK system で、FLEXIBILITYをコアに設計されている。
  • VxRack engineered system である。APPLIANCESではない。(のちに説明する)
  • VxRack は様々なpersona=人格(特色)を持っている。たとえば最初のpersonaはVxRack 1000 vSphere, KVM, baremetal, ScaleIO storage-onlyの混合が可能。これは vSphere という選択肢がほしいお客様がSDS data service layer としてScale IO を使用したい場合などに便利。
  • VxRackは今年後半にvSphereだけのpersonaとして登場する。これはVMware EVO:RACK プロジェクトとのコラボレーションでVSAN SDS data service レイヤで採用。
  • VxRack“Vx”VxBlockのそれのように固定されないでCisco UCSNexus networkingの選択があるということを指す。これらはすべてODM partnersからの供給でVCEでよく知られるsingle support model。
  • VxRack EMC CIとの融合を企図して作られており、VCE VblocksVxBlock、そして将来的にはVSPEX Blue などともCI portfolioの共有をするはず。これはCIが将来的にはBLOCKS, RACKS, APPLIANCES などの異なるタイプで提供されることをみこして、その融合や、共有はお客様にとって大事なファクタだという認識があるからだ。
  • VxRackは業界標準Hardware を使用しているので安価にhardwareの管理、ができるしレイヤの融合が簡単にできる。そのため僕らは“hardware abstraction level”(抽象的なハードウェアレベル)に関してもっと考えなければいけない(この話はDay3 で)。
  • VxRack まだまだ未発表のpersonaを併せ持つ。これに関してはDay3 をお楽しみに!

 

まず最初にVxRack開発には結構時間がかかっていた。一部の人EVOを使ったVSPEX Blueを見たときにScaleIOに対する結論を決めつけたのは興味深い。ScaleIOopen VxRack 1000のコアだからね

一世代目のVxRack 1000open personaだ。ということはフレキシブルであるということが言える。

vSphereKVMbaremetal、もしくはStorageのみを選択するってこともその反対で全部選択することも可能。

NodeToR switche、マネージメントネットワークだけの小さな環境からの構築が可能(大体1/4 ラック)しかしスケールアウトは永遠にできる。もちろん違うタイプのVxRackもある。これはone leveraging EVOも含んでいて純性hyper-integrated VMware stackまたはvSphereなどを含むOpenシステムも含むことができる。

 

Workloadに関してはplatform 2のそれと同様だけど僕らはplatform 3 toolsを付加できるようにした。たとえば標準サーバ

SDSストレージの組み合わせといったもの…これこそ‘platform 2.5’だけどね。それにより異種間での要求や組合せを摺合せができてベストなOpenSDSとしてScale IOみたいなものを作ったんだ。事実VxRack 1000Code Name“Buzz Lightyear” - “scale to infinity and beyond!”だったしね・・・

VxRackは何百何千というNodeにスケールアウトできるように設計されている。物理的なラックスケールでね。

たしかにcompute/memory/network という面では問題もいろいろある、しかしSDS layerでは成層圏だと250M IOpsくらい出せる、そして38ペタのキャパを持つ。。1/4ラックからそれが始まるってことを忘れないでね。

みんなどんなハードウェアを使ってるのか知りたがるけれどこれはまだTechプレビュ-のレベルだってことを忘れないでくれ。

だから設計や使われるハードウェアが変わることだってある。しかしこれだけはいえるよ、業界標準でしかもスケールアウトが簡単にできるハードウェアが使われるってことを。UCSサーバではなくwhiteboxって言ったところかな。

VxRack 1000hyper-convergedだけれどもエンジニアの粋を集めたものでもある、これってどういう意味かって?まさにここで僕が話したいRACKS APPLIANCESに尽きる、「オーダーメード」と「吊の服」の違いだよ。

つまり・・・・

*吊の服を買う場合、スタイルと色を選択して試着するよね。もちろんお直しもできるけどそんな程度で数分で買うことを決めるよね。簡単だし。それがAPPLIANCEなんだよ。

*既製品を買う場合、まず採寸するよね、サイズ確認のために。そして素材を選ぶときは色も含めてじっくり考えたりする。これは吊の服を買うよりも時間がかかるけれどその分「あなただけ」の洋服になる、これこそRACK Engineeredのことをいう。

ある程度のハードウェア構成のあるapplianceと違い、 VxRackはそれぞれのNode CPU/Memoryの組み合わせがすでにある。VCE vArchitectpartnerはその最適な組み合わせを貴方のために選ぶために存在している。そしてVCE experience としてVxRack 1000がラックされ、結線され、スイッチとも接続されることになる。もちろんNode追加も簡単で貴方だけのシステムがこれで構築可能になる。

一方でVSPEX BlueのようなappliancesPlanningをする必要がない、すでに構成された形で貴方の元に届くのだから。そして結線して火を入れて数分で稼働することが可能なんだ。

これがRACK (“Flexible!”)と APPLIANCE (“Simple!”)の大きな違いなのさ。

これがVxRackmanagement orchestration レイヤのKey・・・・

  • インフラがカバーしてもクラウドにはならない

何がmanagement orchestration レイヤレベルのクラウドを作っているのか。IaaSを例に挙げるとFederation Enterprise Hybrid Cloud (Federation EHC)VMware vRealizeViPR suiteを使っている、といえる。EHCIaaSCloud そのものであり、PaaSでもある。EHC Solutionは今やVSPEX Blue applianceと一緒に使うことはできなくなったわけだ。

 

  • management orchestrationって何か・・・

1、 基本レベルの管理形態とオーケストレーション。後記のデモビデオでのVCE VxRack powered by OnRack (tm) technologyではその一例を示している。もっと詳しいのはDay3で。

2、 次のレベルではinfrastructure pools management(インフラレベルでのPool管理)orchestration layer(オーケストレーションレイヤ)これはvSphere onlyの選択をしていればvSphereで完結するし、混合のpersona、その場合bare-metalもしくはScaleIO-only、またはKVMなどの混合もあるけれど、そうなるとそれぞれのレイヤ層での完結が必要となる、すなわちそれがVxRack Managerということになる。これならVxRackの管理、Node追加、削除、logical resource poolの作成、persona自体の比較確認も可能。デモビデオでもそのプロトタイプが確認できる

3、 VCE Visionのようなコンプライアンス系VCE Release Certification Matrix (RCM)の移行についてもデモビデオでイメージがつかめる。

百聞は一見にしかず・・・デモビデオを確認するとわかる・・・ 


EMC World 2015: VxRack Management Prototype - YouTube


コンバージトインフラストラクチャーマーケットリーダー(長期的には年間2Billion成長)がここまでのCIポートフォリオを持っているのがわかったと思う。VCEファミリの期待の星VxRack 1000は君のすぐそばまで来てるんだ。

 

どうだろう、僕らの進んでいる道はこれでいいのか?Vblock/VxBlockVxRackでは使用環境が重なっている部分があるのは否めない・しかしその違いが分かってもらえただろうか。FeedBack求む。


このスレッドはVirtual Geek の作者の許可をもらって日本語訳にしています。

Filter Blog

By date:
By tag: