Storage Feed

2016/12/28

Nutanix Acropolis ファイルサービスについて知っておくべき10の事

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のProduct Marketing Managerを務めるShubhika Taneja氏によるものです。原文を参照したい方はTen Things you need to know about Nutanix Acropolis File Servicesをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

我々はすばらしい機能それぞれについて、将来のリリースで含まれる機能をご紹介する新しいブログシリーズ「10の知っておくべき事」をスタートします。以前のリリースで、この将来のリリースの機能の登場は多くの素晴らしい機能、例えばAcropolis ファイルサービス、セルフサービスポータル、ネットワーク可視化、その他たくさんなど、は予告されていたものです。ではまずAcropolis ファイルサービス(AFS - Acroplis File Service)についての10の知っておくべき事から初めましょう:

  1. AFSを利用すれば別途ネットワーク接続ストレージ(NAS)アプライアンスを用意する必要はなくなります。AFSはソフトウェア定義のスケールアウト型ファイルストレージソリューションでSMB/CIFSの幅広いユースケースをカバーできるように設計されており、Windowsユーザープロファイルの格納や、ホームディレクトリ、組織間での共有を実現できます。あらゆるAVHまたはESXiのクラスタ上で有効にすることが出来、Nutanixの管理ソリューションであるPrismから2,3回クリックするだけで利用することが出来ます。
  2. AFSは完全にNutanixのエンタープライズクラウドプラットフォームのコアコンポーネントと統合されています。既存のクラスター上に展開すること、スタンドアローンのクラスタに展開することの療法が可能です。スタンドアローンのNASアプライアンスとは異なり、AFSは仮想マシンとファイルストレージを統合することが出来るため、別々のインフラストラクチャのサイロを作る必要はなくなります。AFSも仮想マシンサービスと同様にNutanix Prismから管理を行うことが出来るため、管理の統合、簡素化を実現します。
  3. AFSはそれを支えるNutanixエンタープライズクラウドプラットフォームからインテリジェントな階層化、重複排除、イレイジャーコーディング、圧縮、そして分散化による自己治癒などの優れたエンタープライズストレージの機能を継承しています。
  4. AFSは最低で3台のファイルサーバ仮想マシンを必要とし、それぞれのファイルサーバ仮想マシンは最低 4 vCPU、12GBのメモリを必要とします。AFSクラスタのパフォーマンスは簡単にスケールアップ(vCPUとメモリをさらにファイルサーバ仮想マシンへ追加する)またはスケールアウト(ファイルサーバ仮想マシンを更に追加する)によって、改善することが出来ます。
  5. AFSはSMBをサポートし、Active Directoryと連携して動作します。
  6. AFSはユーザーと共有のクオータをサポートします。
  7. AFSはアクセスベースのイニューメレーション(Access Based Enumeration - ABE)をサポートします。
  8. AFSはWindowsの以前のヴァージョンの復元をサポートしており、ユーザーによるセルフサービスでの復元を実現します。
  9. 共有領域の3rd パーティによるバックアップについてはCommvault社などのベンダーから提供される従来からのファイルバックアップを利用することが出来ます。バックアップは別のNutanixクラスタまたは、パブリッククラウド(AWSとAzure)に対して行うことも出来ます。
  10. AFSでは別のNutanixクラスタへの統合された自動災害復旧を利用することが出来ます。

Fig148

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

さて、ネットワールドらぼではNutanixコミュニティではじまった「10の知っておくべきこと」シリーズの翻訳を行っていきます。まずはAFS。これ自体はファイルサーバの機能を提供するだけ(もちろん、Nutanix流にスケールアウトしますので、サーバ1台単位でのPay-as-you-growなのは魅力です!)なのですが、素晴らしいのはNutanixクラスタ内に共存させることが出来るということです。仮想マシン用のストレージとファイルサーバストレージ、ほとんど似たような(もしくはユニファイドで同じ筐体にすることもあるでしょうが・・・)ソリューションを別々に管理したいとは誰も思っていないはずです。Nutanixではこれに加えて更に仮想環境の管理も統合することが出来ますので、社内のITインフラの管理をあの優れたPrismだけで行うことが出来てしまうのです。

今後も様々なSMB/CIFSのユースケースに対応するようなロードマップがひかれているようですので、今後ファイルサーバ専用機はなくなっていく、、、正にWikibonのServer-SANについての予測を象徴するような機能についての10の知っておくべきことでした。

2016/12/12

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

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


驚きのデータ削減!あらゆる電力喪失に対応する究極の電源機構!
何処をとってもワンランク上のA9000ですが性能も機能も一味違います!!
その噂の真相を確かめるべく、検証も次のステージへっ。

7vocbqxlurq9an61481180153_148118042


ここからはお待ちかねのA9000の持つ機能や性能について
さらに切り込んでいこうと思うっ♪


で、今回はズバリ QoS ですっ♪

クラウド基盤好きには、ハズせないマストアイテムがこのQoS
このA9000!、次のスケジュールもパンパンで、お借りできる期間もあとわずかっ!
限られた時間内(いろいろな検証の合間を縫ってこっそり決行っ!)に出来る限りの検証をおこなってみたよっ♪

ちなみにQoSってなにっ?って人もいると思うので簡単に説明しようっ。
QoSとは Quality of Service(クオリティ・オブ・サービス) の略でザックリ言うと
その名の通り、「サービスの品質!」 要は「ユーザーを満足させられる度」みたいな意味になりますっ。

したがって、ここで言うQoSは「ストレージアクセスの品質」ですねっ♪
例えば、「社内で野放しのワークロードが蔓延りクリティカルアプリケーションに影響がでてる!」のような
他の利用者の大きなI/Oに影響を受けるいわゆる“ノイジーネイバー”問題っ。
QoS 機能はこういった問題を解消するために無くてはならない機能っ!。

A9000/A9000Rの
QoS機能は、接続先ごとのプライオリティーに応じて
柔軟できめ細やかな設定が可能ですっ。
例えばこの図ように「帯域」または「IOPS」を設定したり、また「その両方」を設定することもできます。
もちろん単一ボリューム単位だけでなく、複数のボリュームでシェアしたり
ストレージプール単位での設定だって出来ちゃいますっ♪

A9000qostest001


更にA9000/A9000Rは管理アカウントまで独立したマルチテナンシー機能も搭載され
クラウド基盤、クラウドサービス、そして流行のVDI環境にも最適な一台です!!

それでは、A9000の QoS機能の検証結果をご覧くださいっ♪

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

検証が進むにつれ

筆者はこの「グリッドコントローラー」の完成度の高さに驚いているっ。
特にパフォーマンスに関しては、驚きの結果(本当に想定外です。)を次々とたたき出してますので

そのへん、次回にでもお見せできればと思いますっ。


                        by:まいけル
        

2016/12/07

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

本記事はNutanix Advent Calendar 2016への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。当社からは私とSEの工藤が寄稿します。

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

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

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

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

すでに東京での開催は終了していますが、大阪での開催もございます!

こんにちわ。このブログ記事は私のNutanix 5.0の機能概要(Beyond Marketing)シリーズの2番目の記事で、もうすぐリリースされるNutanixソフトウェアで利用できるようになる機能をご紹介しています。この記事の1番目の記事はこちらです。

この記事は2番目の記事です。1番目の記事はこちら3つ目4つ目

これまでの記事のシリーズでご紹介してきた機能は以下のとおりです:

  • Cisco UCS B-シリーズ ブレード サーバ サポート
  • Acropolis アフィニティ と アンチ-アフィニティ
  • Acropolis ダイナミックスケジューリング (DRS++)
  • REST API 2.0 と 3.0
  • XenServerのサポート TechPreview
  • ネットワーク可視化
  • 新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)
  • ネイティブのセルフサービスポータル
  • スナップショット - セルフサービスリストアのUI
  • ネットワークパートナーインテグレーションフレームワーク
  • メトロアベイラビリティウィットネス
  • VMフラッシュモードの改善
  • Acropolis ファイルサービス 正式リリース (ESXi と AHV)
  • Acropolis ブロックサービス (CHAP認証)
  • AHVのOracle VM と Oracle Linuxへの認定
  • AHVのSAP Netweaver Stackへの認定
  • (New) Prism サーチの改善(ブール表現のサポート)
  • (New) I/O メトリクスの可視化
  • (New) 1-クリックライセンシング
  • (New) LCM – Lifecycle Manager(ライフサイクルマネージャー)
  • (New) 追加のPrismの改善点
  • (New) AHVの拡張性の改善
  • (New) AHVのCPUとメモリのホットアド(Tech Preview)
  • (New) コールドデータのアドバンスドコンプレッション
  • (New) バックアップベンダーのためのAcropolis チェンジブロックトラッキング(CBT) 
  • (New) 自発的なQoSによる期待通りのパフォーマンス
  • …さらに 3番目となる最後のパートで

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

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

Prism

Prism サーチの改善(ブール表現のサポート)

すでにパート1をお読みいただいているのであれば、Prismがもはやデータセンタを一つの窓からすべて見通せるようになっていることにお気づきでしょう。管理者はコンピューティング、ストレージ、ネットワークをすべて管理出来るようになっています。それだけではありません。ネットワークとセキュリティパートナーが現在彼らのソリューションをREST 3.0でPrismへと統合を進めています。

AOS 4.6ではキーワードベースの検索と文脈を理解した結果表示を導入しました。今回、AOS 5.0ではよりリッチなアラートクエリ、表現クエリ、問題発見、動的なカンペ、全体的な検索エクスペリエンスのシンプル化が行われています。

これらの改善は「サービス品質の劣化」にフォーカスを当てています。今日、IT管理者はインフラストラクチャの問題の発見と隔離に多くの時間を費やしています。もしくはIT管理者は非常に複雑なフローで単純なタスクの実行にあたっているのです。 

  • よりリッチなアラートクエリのサポート
    • アラートのフィルタリング
    • 重要度によって(重大、警告)
    • 影響のタイプによって (可用性、キャパシティ)
    • 解決状態によって(解決済み、未解決)
    • 通知の状態によって(通知済み、未通知)
    • アラートのタイトルやタイトルの一部によって (CVMが再起動した、NICのエラー)
    • 上記の組み合わせ
    • 例) 解決済みの重大なアラート
    • 例) ホスト1の重大なアラート

Fig124

  • 表現クエリのサポート
  • 要素をブール表現(“>”, “<“, “=“, “<=“, そして “>=“)で指定てフィルタリング
    • 計測値をフィルタ (例 VMs IOPS > 100)
    • 属性をフィルタ (例 VMs “power state”=On)
    • 複数のフィルタを組み合わせ
  • 表現内の値を自動補完
    • 特定の属性についての値を自動補完
    • “Block type”= (利用可能なブロックタイプで自動補完)

Fig125

Fig126

Fig127

  • デザインを刷新し、改善されたカンペがPrism Centralで管理されている要素をベースに自動的に生成されます。カンペ、最近の検索履歴、保存した検索のレイアウトがキレイに改善されています。

Fig128

I/O メトリクスの可視化

NutanixはPrism UIで常々ストレージのパフォーマンス監視機能を提供してきました。Nutanixはさらに先進的なストレージパフォーマンス監視機構とワークロードのプロファイルについても全てのCVMのポート2009番で提供をしてきました。そこでは非常にきめ細やかな9日オスディスクの詳細情報を見ることが出来ます。AOS 5.0ではI/Oレイテンシ、I/Oパフォーマンス、分散度合い、ストレージの角層の利用率などの仮想マシンから見た重要なメトリクスをPrism内に表示するようになります。

Fig129

1-クリックライセンシング

AOS 5.0ではサポートとの接続を活用して、1-クリックでPrismから直ぐにライセンスを取得することが出来るようになりました。ポータルライセンシングAPIを利用して、Nutanixは自動的に管理者が行うことの出来るアクションを理解し、そのいずれもをシングルクリックで実行できるようにします。

  • アップグレード – 高いライセンスレベルへの移行
  • ダウングレード – 低いライセンスレベルへの移行
  • リバランス – 現在のノード数とライセンス数の同期
  • リニュー(更新) – 失効していないライセンスへとライセンスを入れ替え
  • 追加 – アドオンを追加
  • 削除 – アドオンを削除

Fig130

LCM – Lifecycle Manager(ライフサイクルマネージャー)

AOS 5.0では全てのクラスタコンポーネントの1-クリックアップグレードのオプションはライフサイクルマネージャーへと移動され、すべてのソフトウェア/ファームウェアのアップデートは単一画面管理で統合されています。この変更によって、インベントリとアップデートのコードがAOSから分離されることになり、全てのソフトウェア/ファームウェア/インベントリのアップデートを汎用的なフレームワークで行えるようになり、各々のクラスタコンポーネントの更新とは切り離してアップデートを当てることが出来るようになります。これらの変更は1-クリックアップグレードの処理を完全にシームレスにPrismへ統合したままで裏側で行われます。 

  • LCM はすべてのソフトウェア/ファームウェアのアップデートを一元管理できる
  • LCM のモジュールはAOS(ディスク/HBAのアップデート)とは別にリリースされる
  • LCM のフレームワークはLCMの操作をコントロールするメインモジュール
  • LCM のフレームワークはLCM アップデートモジュールで自己アップグレード出来る

Fig131

新しい LCM – Lifecycle Manager(ライフサイクルマネージャー)
 

Fig132

追加のPrismの改善点

  • Prism Central内の1年間のデータのリテンション (さらなる分析)
  • メニューとダッシュボードの静的文字列の国際化対応
  • Prism CentralのダッシュボードからPrism Elementのウィジェットへの迅速なアクセス
  • エンティティ(要素)ブラウザの改良:
    • テーブルとタイル表示からのデータのエクスポート(JSON/CSV)機能
    • 保存したクエリをサポート
    • サーチ <> エンティティブラウザの統合
  • Prism CentralのディスクI/Oと利用の削減による改善

 

 

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

AHVの拡張性の改善

Acropolisハイパーバイザの管理は要件の高いワークロードをサポートするために継続的に改善されています。AOS 5.0ではAcropolisハイパーバイザは12,500仮想マシンと150万件のアラートとイベントをサポートしています。

 

AHVの CPU と メモリ のホットアド (Tech Preview)

AHVはCPUとメモリのホットアドをサポートしました。AHVのメモリホットアドとCPUのホットプラグの機能はCPUとメモリを仮想マシンが起動して動作中に追加することが出来るものです。これによって、追加リソースが必要な際にいつでも仮想マシンを止めることなく追加することが出来ます。TechPreviewの最中はACLIでのみ利用可能です。

 

 

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

コールドデータのアドバンスドコンプレッション(圧縮)

AOS 5.0はコールドデータをキャパシティ効率の良いアルゴリズム(lz4とlz4hc)を利用して最高のストレージ効率を実現します。今回のリリースで導入された変更で圧縮率の改善、ゴミデータの削減、圧縮・解凍のスピードの改善がなされています。AOS 5.0ではこのポストプロセスでの圧縮はオールフラッシュクラスタでは標準で有効になり、ハイブリッドのクラスタでは手動で有効にすることが出来ます。

Fig133

バックアップベンダーのためのAcropolis チェンジブロックトラッキング(CBT)

AOS 5.0ではバックアップベンダーはNutanixのCBT(ハイパーバイザに依存しません)の恩恵を存分に活用することが出来、増分バックアップと差分バックアップの両方でディスクおよび仮想マシンを効率的にバックアップすることが出来るようになります。もしもVMware vSphereだけでクラスタを動作させているのであればハイパーバイザ由来のCBTを利用することはこれまでも出来ていました。しかし、NutanixのCBTでは同様の機能がマルチハイパーバイザーに対応したプラットフォームにおいてCBTを利用することが出来ます。管理者は同じバックアップツールと方法を全てのハイパーバイザーにおいて利用することができるようになるのです。

NutanixのCBTは新しいREST 3.0 APIを利用しており、あらゆる2つの仮想ディスク又は仮想マシンのスナップショットの変更メタデータ領域を問い合わせることができます。このアプローチでは増分と差分のバックアップに有益なことはもちろん、フルバックアップにも利用することが出来ます。これはAPIがスペア(ゼロ)の領域も特定することが出来るからで、Read操作を減らすことが出来るからです。

Nutanixは直ぐにプラットフォームにネイティブで統合されたバックアップパートナーをアナウンスします。 

 

自発的なQoSによる想定通りのパフォーマンス

自発的なQosは管理者がフロントエンドとバックエンドの操作のリソースの帯域を調整するその裏側で動作します。負荷の高いタイミングでは、すべてのフロントエンド(ユーザーによる)操作は高い優先順位を割り当てられ、負荷の低いタイミングではバックエンドの操作がより多くのリソースを割り当てられます。自発的なQoSはユーザーからの入力時に想定通りのパフォーマンスをユーザーアプリケーションに提供します。これは機械学習を用いて自動的に意思決定されます。

Fig134

  • 1-ノードのレプリケーションターゲット
  • ストレージヘビープラットフォーム上での1時間のRPOのサポート
  • ノードの削除時のEC保護の保持、保護オーバーヘッドの限定
  • 利用できる全てのノード内のSSDをメタデータに利用し、複数メタデータのディスクをサポート
  • ホストブートディスク(SATADOM)の入れ替え手順のシンプル化と自動化
  • コンテナにたいしてのイレイジャーコーディング(EC)でのレプリケーションファクター(RF)の変更のサポート
  • OpLogへのインライン圧縮
  • QoSによる複合ワークロードサポートの改善
  • 適応型レプリカ選択による混在ノードのサポート
  • Linux カーネルの更新 -  4.4.22

乞うご期待!

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

Part 1翻訳を出した2時間前にすでに公開されていたPart 2の翻訳記事です。Part 2の目玉はやはりPrism Searchの改善ではないでしょうか。ウィーンではNutanixはAWS for the Enterpriseではなく、Amazon for the Enterpriseである!という話でしたが、これはGoogle Search for the Enterprise Infrastractureとも呼べるものだと思っています。優れた(ソフトウェアを含む)インフラストラクチャのアーキテクチャはもちろん大事ですが、優れたエクスペリエンス(この場合は「ググれ」「Google先生」と一般化した言葉が物語るように)を取り入れていくことにも積極的です。こうした発想はやはりWebスケール由来のものでしょうし、インフラを発展させるという発想からは生まれにくいものですね。

また、Part 1のネットワーキング&セキュリティに引き続き、REST 3.0とCBTを利用してバックアップパートナーのソリューションを取り込んでいく方向性もでています。やはり単なるHCIとしての進化ではなく、ここでも「プラットフォーム化」が進んでいます。自発的なQoSに関してはPernixDataのフローコントロールなどを思い出しますが、優れたものはどんどん取り入れる、その中で自分でやるべきもの(HCI=コンピューティング、ストレージ)はもちろん、パートナーシップで実現していくもの(ネットワーキング、バックアップ)がしっかりと分かれてきているように思います。

Part 3の最終パートも待ち遠しいですね。乞うご期待!

2016/10/27

ランサム[身代金ウィルス]ウェアの対策してますか?

身近な言葉になってきた”ランサム[身代金ウィルス]ウェアですが、企業でもアンチ・ウィルスソフト(セキュリティ対策ソフト、振る舞い検知、隔離用のサンドボックスなど)の導入で防御し対策を行っており、セキュリティの面で語られることが多いと思います。

ただ、セキュリティ対策ソフトからすると、常にパターンファイルの更新を行い、おかしな振る舞いを監視する事象を追いかける形になっています。 つまり、新種が出ると、対策についてはイタチごっこ、盾と鋒で新たな攻撃を受けた後の対策となり、即席では直らず時間が掛かることになります。 また進入の経路も多岐(メール、Webアクセス、ファイル転送)に渡り、その対策についての労力も馬鹿にならないものになります。

初期のウィルス・ソフトは悪戯が主目的で、悪意があってもウィルス・ソフト製作者の技量を見せつけるタイプのソフトが多くありましたが、2000年以降のウィルス・ソフトは企業内で問題となる事象(サイト攻撃やスパムメールの踏み台)が増えて来ました。また、サーバやPCに影響を及ぼし、業務に支障がでるようなウィルスも多くありました。昨今のウィルス:特にランサムウェアと呼ばれるものは、ファイルを暗号化することやPCを起動させなくすることで身代金を要求するウィルスであり、1回に要求される金額が小額(平均300米ドル)であっても、デジタルの環境(ビット・コインによる金銭授受)が整っていることもあり、不特定多数に対して金銭要求することでビジネス(ウィルス開発者が儲ける)になっている事が大きな違いであり、1件あたりの被害額は少なくても多数の被害の積み上げで被害額が拡大している事や特定が難しいのが特徴です。 

また、暗号化されたファイルやシステムが立ち上がらないような状態から、自力で元通りに復旧させるには時間も能力も必要です、その費用や労力の割には、要求される金額が小額であることから、一番の解決策が身代金を払う事と言われています。

セキュリティ対策としてアンチ・ウィルスソフトを導入するのは、個人でも、企業でも一般的だと思います。 ただ、アンチ・ウィルス対策は、最後の砦、突破されたらおしまいです。

それ以前の対策として、バックアップ有用性を考えてみてください。 以外と端末のバックアップは個人に任せていることが多くないでしょうか? やはり、怪我や病気、車の事故に対応した保険と同じく、データの保険は、やはり転ばぬ先の杖であるバックアップ(データ・コピー)が対策として有効な手段だと考えます。

ランサムに関しては個人の端末(スマフォ、タブレット)に波及するケースが多く、被害の範囲は狭いものの個人には打撃の大きいものとなります。 攻撃されても補える力(データの2次コピー)を持っていれば、余計なお金(身代金)を払わずに済み、被害の拡散防止にも役立ちます。

データのバックアップは、利益を生み出すことが無いですが、皆さんの心に安心を与えてくれます。 無くなって困らないデータであればコピーは必要ないですが、大事な個人のデータや企業のデータの消失対策としてのバックアップと、アンチ・ウィルスソフトとの2段階で防御/対策するのが望ましいでしょう。

バックアップもサーバ向けのバックアップ・ソフトだけではなく、PCや個人端末に対応したバックアップ・ソフトもあります。

是非、弊社のランサムウェア対策をご覧ください。

ランサムウェア対策: http://www.networld.co.jp/solution/ransomware/

Edit by :バックアップ製品担当 松村・安田

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/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/08/22

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

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

実際に動かしてみようっ♪


いきなりですが、「実際に動かした結果を速く視たいんだけどなぁ♪」 とボスから指令がっ!!
ということで簡単な環境をつくって少しだけ試してみましたっ♪

さっそく、サクッと図のような環境をセットアップ~っ♪

A9000test1

で、何をしようか・・・・・♪

とりあえず、代表的な機能のテストをやってみようかなっ。実機でっ♪


重複排除って本当に効くの!?

**A9000上、単一ボリューム内で複製をした場合**

1個のデータストア内でVMを複製してみましたっ♪

1:ESXiのデータストア用にA9000上に約1TBのボリュームを1個作成
2:このボリューム内に1台目の仮想マシンを作成
3:同じボリューム内に1台目の仮想マシンのクローンを作成して2台目を作成
4:同じボリューム内に、残りの仮想マシンのクローンを作成して合計10台を展開
*(仮想マシンには、WindowsServer2012R2をインストールしました。)

Ffx417

その結果がこちらっ♪

姐さんっ!重複排除、効いてますぜっ!!
(約98パーセントの排除率を確認できました。)

Clonevm


続いてぇ~っ♪

**A9000上、複数のボリューム上に同じデータを複製した場合**

10台のVMそれぞれにRDM(ローデバイスマッピング)の領域を追加してデータをコピーしてみたっ♪

1:A9000上に50GBのボリュームを10個追加作成する。
2:先ほど作成した10台のVMそれぞれに1個づつRDM領域としてDiskを追加する。
3:10台中1台目のVMのRDM領域にダミーデータを書き込む。
4:他のVMにもそのダミーデータをコピーする。
*(ダミーデータは合計約10GBの、pdfやpptなど単体では圧縮の利き辛いアトランダムなドキュメントファイル群です。)

Ffx418

兄貴っ、やはり重複排除、効いてますぜっ!!
(2台目以降の重複排除率が9個平均で約88.4パーセントという結果になりましたっ♪)
おやおや~っ、これってVDI用途なんかには超絶効果が期待できそうじゃなイカっ!!(マジで期待していいと思うっ♪)

Qq

★この「重複排除」はA9000/A9000R上の単一ボリューム内だけでなく複数のボリューム間であってもその効果を実感できるんですっ!



あっ!、そういえば!!圧縮はどうなのよっ?

ということで、実際にデータベースを動かして試してみましたっ♪。
1:今度はサーバーのローカルに3台のVMを作成するっ
2:A9000上に10TBのボリューム3個を作成するっ
3:3台のVMそれぞれに1個ずつRDMでディスクを追加っ
4:RDMの領域にサンプルDBをロードするっ♪
*(各DBの最終的なファイルサイズは平均約1.7TB)

Dbb

ボスっ!重複排除の効きにくいDBのようなファイルでも圧縮効いてますぜっ!!
ファイルサイズ平均1.7TBの状態
(圧縮率3台平均で約47パーセント)

Final01


今回は短時間で行ったほんの一例ですが、どおやらデータ削減の効果は大いに期待できそうであるっ♪

他にも「マルチテナンシーのQoSの効果っ♪」や、「超絶IO負荷地獄」、「帯域の鉄人」、「パターン排除の飽くなき削減」
など、やってみたい事はいっぱいあるので、今後少しづつでもご報告できればと思いますっ♪

次回は、「筆者もびっくり!何があってもデータは守りきるっ!究極の電源機構っ!!」


by:まいけル

2016/08/08

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

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

グリッド・コントローラーってなあにっ??


分散する複数のコンピューティングリソースを並べて一つに見せる「グリッド」という技術があります。

A9000において、この「グリッド」を構成するのがこの「グリッドコントローラー」ですっ。

Grid_2*A9000は「フラッシュエンクロージャー x1台」+「グリッドコントローラー x3台」 で構成されています。

今をときめく超高速フラッシュストレージを、もっともっといろんな用途に使えないかなぁ・・・

沢山ある答えの一つがこのA9000で、その豊富なストレージ機能が詰め込まれているのが
何を隠そう、この「グリッドコントローラー」なのですっ!

観て通り、このグリッドコントローラーのハードウェア自体は
信頼性高いハイエンドサーバーがベースになっています。
ただでさえ複数のグリッドコントローラーによる冗長を提供しながら
このグリッドコントローラー単体もワンランク上の堅牢性を兼ね備えているんですっ♪。

Gridctl

*こちらがグリッドコントローラーですっ。

例えばグリッドコントローラー本体の冗長電源の、両方の電源供給が
同時に断たれてもシステムのシャットダウンを安全に完了できる機能を有します。

ハイエンドサーバーがベースでありながら、こういっためずらしい機能も搭載しています。
むろんストレージ機器であるフラッシュエンクロージャーにもこういった機能が実装されています。


また、自慢のインラインのデータ削減だって、グリッドコントローラーに搭載される余裕のリソースがあってこそっ!
これは「特定パターンの排除」に始まり、流行の「重複排除」、更にデータの「圧縮」で限りあるストレージのリソースを最大限に利用できるのですっ。

ちなみに圧縮には独自の専用ハードウェアアクセラレーターカードがグリッドコントローラー1機あたりなんと2枚も搭載されているんです!だから速いんです!!
高速な大容量メモリー、複数のマルチコアプロセッサーもそのために搭載されているのですっ♪
とにかく、ありとあらゆる手段でデータ量を削減しまくる!それも高速に!!

とまあ、これもA9000の数ある得意技の一部にすぎませんっ。
XIVで培った豊富なストレージ機能の数々が、このグリッドコントローラーに実装されているのですっ。

なかなかやるでしょ、グリッドコントローラーっ♪


次回は「実際に動かしてみようっ♪」へ続きます♪

*参考資料:英語*
IBM FlashSystem A9000 and IBM FlashSystem A9000R Architecture, Implementation, and Usage



by:まいけル

2016/07/25

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

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

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

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

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

データセット

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

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

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

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

Fig421

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

Fig422

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

Fig423

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

Fig424

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

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

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

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

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

Fig425

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

Fig426

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

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