2018年11月8日（木）にAzure Stackのセミナーを開催します。

Azure Stackがリリースされてから一年が経ち、そこから見えてきた「リアル」を共有しつつ、ビジネス面とテクノロジーの両側面からAzure Stackの魅力についてご紹介します。パネルディスカッションでは、企業から寄せられた質問や要望などを披露しながら、各社のエキスパートから本音でAzure Stackを語っていただきます。セミナーが終わった後は、ささやかならが軽食とドリンクをご用意していますので、気軽にエキスパートとお話しいただきながら情報収集や貴社ビジネスにお役立ていただければ幸いです。

申し込みはこちらです！！

https://eventregist.com/e/dellemc_20181108

みなさまのご来場をお待ちしております！！

吉田

今回は、DockerのVolume Plugin「REX-Ray」の動作を試してみます。ここで紹介するREX-Rayの操作は、PCでも試すことができます（最短20分でセットアップ完了！）。興味のある方は、こちらをご覧ください。

お試し環境

はじめに、動作環境（こちらでセットアップした環境）を確認しておきましょう。VirtualBox上に三つのVM（CentOS 7.2）を構成し、互いに通信できる状態にしています。全てのVMには、それぞれDockerとREX-Ray、ScaleIOがインストールされています。

一方、REX-Rayの設定ですが、ストレージプロバイダー（ここではScaleIO）の情報を構成ファイル（config.yml）に記載しておきます。記載する内容は、REST APIを受け付けるエンドポイントやログイン情報、プール名などが含まれています（下図参照）。これにより、REX-RayのCLIからボリュームを作成する時、ScaleIOのPoolからボリュームが作成され、そのボリュームをホストからマウントすることもできるようになります。

REX-Rayでボリューム作成

まずは、REX-RayからScaleIOを使ってボリュームを作成してみましょう。ホスト（VM）は、"mdm1" を使います。下図の通り、"rexray" コマンドで16GBのボリュームを "rexrayvol" という名前で作成してみます。コマンドの書式は非常にシンプルです。

ScaleIOのGUIを開いて作成されたボリュームを確認してみると、16GBのボリュームが確認できます。

次に、作成したボリュームをホスト（IPアドレスは "192.168.33.12" ）からマウントしてみます。マウント（アタッチ）は、"rexray" コマンドの "attach" オプションを使います。ボリュームのアタッチ前後を見ると、ホストの/devに新しいデバイス「scinia」が増えていることを確認できます。

この時点で、ScaleIOのGUIから見てもボリュームがホストにマウント（アタッチ）されている事が確認できます。

これで、REX-Rayのシンプルなコマンドを使って外部ストレージのボリューム作成とホストからのマウントを実行できることが分かりました。次に、この環境を逆の手順で削除してみます。ボリュームのアンマウントは "detach" オプション、削除は "rm" オプションを使います。下図で示した通り、簡単な操作で元の状態に戻ります。省略しますが、この時点でScaleIOのGUIから見ても元の状態に戻っています。

Dockerからボリューム作成

次に、DockerからREX-Rayを経由してボリュームを作成してみましょう。"docker volume" コマンドの後に "create" と "--driver" オプションで "rexray" を指定して、"--opt size=" オプションでサイズを指定します。

REX-Rayから見ても、作成したボリュームを確認できます。画面ショットは省略しますが、この時ScaleIOのGUIから見てもREX-Rayで操作した方法と同じようにボリュームの構成状態を確認できます。

作成ができれば、当然削除もできます。削除は、"rm" オプションを使います。

このように、DockerのコマンドでもREX-Rayを経由したボリューム作成は可能です。しかし、現時点ではdocker volumeコマンドのオプションが少ないので、ボリュームの操作（作成や削除など）に関しては、DockerコマンドではなくREX-RayのようなVolume Pluginのコマンドを利用した方が良さそうです。

コンテナからマウント

次に、コンテナからボリュームをマウントするまでの操作を行いましょう。最初にボリューム "volume01" を作成しておき、その後コンテナ起動と共にそのボリュームをマウントします。"docker run" コマンドのVolume Pluginを使うオプションは "--volume-driver=" です。後は、Data Volumeのオプションと同じように "-v" オプションでボリューム名とコンテナ内部のマウント先を指定します。今回は、"-it" オプションでコンテナ起動と同時にコンテナ内部に入り "ls" や "df" コマンドを実行して、ボリュームにマウントしたディレクトリ（/myvol）の存在を確認してみます。

ここで、/myvolにファイルを一つ作成してから、コンテナからexitしてみましょう。尚、このDockerコマンドで起動したコンテナから単にexitすると、抜け出すと同時にコンテナは停止状態になります。この時、ボリュームはホストからアンマウント（detach）されますが、ボリューム自体はScaleIOのPoolに残っています。

別ホストのコンテナからボリュームをマウント

次に、別なホストのコンテナから既存のボリューム "volume01" をマウントしてみましょう。これまでは、ホスト "mdm1" で操作を行ってきましたが、ここから "mdm2" にログインして操作を行います。まず、rexrayコマンドでボリュームが見えていることを確認します。

その後、先ほど "mdm1" で実行したものと同じコマンドでコンテナを起動します。コンテナ名だけ変えています。

先ほどと同じように、起動したコンテナ内部から見ると指定したボリューム（ディレクトリ）をマウントしていることが確認できます。さらに、ディレクトリ（/myvol）を確認すると、先ほど作成したファイル（test.txt）が存在しています。ホストを跨いでデータが永続化されていることが分かります。

ここまでの操作を振り返ってみましょう。どのホストからでも外部ストレージ（ここではScaleIO）に対して同じような操作が可能になる理由は、ホストにそれぞれインストールされているREX-Rayが常にScaleIOの構成情報を参照したり制御ができるためです。

コンテナの停止やDockerデーモンの停止が発生すると、コンテナがマウントしていたボリュームはホストからアンマウントされます。アンマウントされてもデータは外部ストレージ残っているので、別なホスト上のコンテナから再びマウントして使用することができます。

このように、Volume Pluginを活用してホストの外部に永続的データを保持していれば、Dockerの運用環境でも物理ホストをあまり意識せず、コンテナから継続的にデータが使えそうです。

次回は、Dockerのクラスタ機能「swarm mode」とREX-Rayを組み合わせた操作をご紹介します。

参考

• REX-Ray
• REX-Ray YouTube

過去の関連記事

• ScaleIO 2.0をPCで試す！
• DockerのData Volume
• DockerのVolume Plugin「REX-Ray」

こんにちは。吉田です。

今回はDockerの永続的ボリュームとストレージについて紹介します。

永続的ではないコンテナのデータ

ある意味あたり前の話ですが、Dockerコンテナを起動した後でコンテナ内に書き込んだデータは、そのコンテナを削除した時点で同時に削除されます。従来のITインフラ設計とは異なり、Immutable Infrastructureの概念をベースとしてコンテナを活用するアプリケーション環境においては、この仕様自体が問題になることは殆どありません。

しかし、一方でコンテナでデータベースを扱うケースは多く、現場では永続的データの維持管理が必要とされます。このような要求に対して、データを永続的に管理する方法がいくつか提供されています。

コンテナのデータを永続化する方法

Dockerコンテナのデータを永続的に維持管理する方法として以下の四つが挙げられます。

• Data Volumes
• Mount a host directory as a Data Volume
• Data Volume Container
• Volume Plugin (Mount a shared-storage volume as a Data Volume)
  

仕組みはシンプルなのですが、目的や用途によって使い分けた方が良いので、ここでおさらいしておきましょう。尚、こちらで紹介した環境を使えば、コマンドで動作を確認することができます。

Data Volumes

Docker Documentに記載されている通り、Data Volumesとは「１つまたは複数のコンテナ内で特別に設計されたディレクトリであり、 Union File Systemをバイパスするもの」です。Data Volumesのディレクトリは、ホスト上のDockerディレクトリ内に配置されます。コンテナからそのディレクトリに書き込んだデータは、ホスト側からも参照できます。尚、Data Volumes は、Dockerコンテナのライフサイクル（起動や停止、削除など）とは別に管理されるため、コンテナを削除してもデータ（ディレクトリ）は残り続けます。故に、ゴミのようにディレクトリを残したくなければ、コンテナを削除すると同時に使用していたData Volumeも削除するのが良さそうです。

コンテナ起動と共にData Volumeを構成する。その後、コンテナに入ってData Volumeディレクトリ（/myvol）にファイル（hello.txt）を作成する。

ホストから"inspect"コマンドでData Volumeの場所を確認し、先ほど作成したファイルを確認する。

コンテナを削除する際、「-v」オプションを使えばData Volume（/var/lib/docker/volume/<ディレクトリ>）も同時に削除される。

Mount a host directory as a Data Volume

これは非常にシンプルです。単純にホストのディレクトリをコンテナからマウントして使う方法です。

コンテナ起動と共にホストのディレクトリをマウントする方法でData Volumeを構成する。その後、コンテナに入ってData Volumeディレクトリ（/myvol）にファイル（hello2.txt）を作成する。

ホストから先ほど作成したファイルを確認する。

Data Volume Container

Data Volume Containerとは、Data Volumeを構成しているコンテナのディレクトリを他のコンテナでも使えるようにする仕組みです。Data Volume Containerという明示的なコマンドは存在せず、単純にData Volumeを構成したコンテナを起動または作成すれば良いだけです。一方、Data Volume Container機能を使うコンテナは、"--volume-from"オプションを使用するだけです。尚、Data Volume Container自体が停止していても、"--volume-from"オプションは使えます。

二つのData Volumeを構成したData Volume Containerを起動し、作成されたディレクトリを確認する。exitした時点でコンテナは停止している。

"--volume-from"オプションで別なコンテナを起動し、Data Volume Containerと同じディレクトリがマウントされていることを確認する。

Volume Plugin (Mount a shared-storage volume as a Data Volume)

これは、ホスト上のディレクトリではなく外部ストレージを使用する方法です。実データは外部ストレージ上に保持されるので、ストレージ装置の性能や可用性を享受できたり、他のホストからも参照できるなどのメリットがあります。Volume Pluginは、各社またはOSSとして提供されており、Dockerと外部ストレージとのインテグレーションが強化され、ほぼストレージの操作を意識することなく外部ストレージを利用できるというメリットがあります。

次回は、このVolume Pluginとして提供されているOSS「REX-Ray」とそのメリットについて紹介します。

参考

• Docker Documentation
• Docker Blog
  
• REX-Ray
• libStorage

関連記事

• DockerのVolume Plugin「REX-Ray」
  

こんにちは。吉田です。

オープンソースソフトウエア（OSS）の普及は、IT業界の大きな潮流になると言われていますが、私も強くそう感じています。そんな中、今回はほとんど知られていないであろうEMCが中心となって開発・提供しているOSSを三つ紹介したいと思います。

１．物理ストレージ層のコントローラー「CoprHD」

SDNをはじめとした「Software-Defined XX」という言葉は国内でもすっかり定着している感がありますが、この概念は二つの技術要素（「コントロールプレーン」と「データプレーン」）に分解して語られることがあります。ここで紹介する「CoprHD」（カッパーヘッド）は、Software-Defined Storageにおけるコントロールプレーンに相当するものです。

異機種混在ストレージ環境で「CoprHD」を使うと、ストレージのオペレーションが一元化できます。EMCのストレージだけではなく他社製のストレージも「CoprHD」からコントロールすれば、ボリューム作成やサーバーからのマウント操作まで同じオペレーションで実行できるようになります。REST APIもサポートしているので上位層のIaaSコントローラー（OpenStackやVMware vRealize Automation等）から制御することもできます。

EMCは、2013年から「ViPR」という製品を提供していますが、実は「CoprHD」は「ViPR」をOSS化したものです。「CoprHD」の開発にはオレゴン州立大学やインテル社が参加しており、EMCと共に開発を進めています。

尚、「CoprHD」の情報は下記リンクから入手できます。VirtualBoxで試すサンプルスクリプトも公開しています。

• プロジェクトHP　（http://coprhd.github.io/）
• Developer Wiki　（https://coprhd.atlassian.net/wiki/display/COP/CoprHD+Home）
• Google Groups　（https://groups.google.com/forum/#!forum/coprhd）

２．ベアメタルプロビジョニングを支援する「RackHD」

今後、ITインフラのコモディティ化が急速に進むと予測されています。従来のような専用装置を使わず汎用サーバーを並べてサーバーとネットワーク、ストレージリソースを利用する形態です。同様に、ストレージもサーバーベースの利用形態が増えるという予測（出典：Wikibon）があります。コモディティ化は、今後ストレージ業界でも大きな変革をもたらすことは間違いありません。

では、ITインフラのコモディティ化が進むと、インフラの運用と管理はどうなるでしょう？これまでのような専用装置（ハードウエア）の管理はあまり重視されなくなる一方で、ソフトウエアを駆使して汎用サーバーの管理をどこまでシンプルにできるかが運用のカギとなります。例えば、サーバーを追加して使用可能な状態にセットアップするまでの作業は、極限までシンプルにする必要があります。それを支援するのが「RackHD」（ラックエイチディー）です。

「RackHD」は、サーバーやストレージ、スイッチ等の管理ポートからハードウエア情報等を収集し、上位層の管理ソフトウエアと連携してハードウエアの管理を実現します。例えば、サーバーを既存のクラスタ環境に追加するケースでは、サーバーの検知やOSのインストール、電源のOff/Onなど様々なハードウエアそのものの管理が大幅に簡素化できます。

ユースケースの一例として、OpenStack環境でIronicと連携してベアメタルプロビジョニングを実現するシナリオをYouTubeに公開しています。このシナリオでは、サーバーを検知したのちハードウエア情報をカタログ化し、ハイパーバイザーをインストールして使用可能な状態にするまでの流れが確認できます。

尚、「RackHD」の情報は下記リンクから入手できます。こちらもお試しサンプルスクリプトを公開しています。

• プロジェクトHP　（https://github.com/RackHD）
• Document　（http://rackhd.readthedocs.org/en/latest/）
• Shovel [OpenStack+RackHD]　（https://github.com/openstack/shovel）
• Google Groups　（https://groups.google.com/forum/#!forum/rackhd）
• Slack [#rackhd]　（https://codecommunity.slack.com/）

３．プラットフォームに依存せずボリューム操作を共通化する「REX-Ray」

Linux OS向けにボリュームを作成してアタッチするまでのオペレーションは、プラットフォームによって異なります。例えばAWSのLinuxインスタンスの場合、EBSでボリュームを作成してからインスタンスにマウントさせます。この操作はREST APIを呼び出すかマネージメントコンソールから実行するのが一般的でしょう。OpenStack環境ではどうでしょう？Horizonからボリュームを作成してインスタンスにアタッチさせるか、CinderとNovaのCLIまたはREST APIで制御することになります。

REX-Rayは、プラットフォームに依存せず共通のオペレーションでボリューム管理が可能となるソフトウエアです。ブロックストレージのボリュームを作成したり、それをインスタンスからマウントする作業は、rex-rayコマンド（ほとんど同じ書式）で実行できるようになります。

コマンドが共通化できると、当然ながらオペレーションが簡素化できるというメリットがあります。同時に、コードでインフラを管理する際もコード化し易くなるというメリットもあるでしょう。Dockerなどのコンテナ技術もサポートしているので、意外とあちこちで使えるかもしれません。YouTubeに公開している動画（↓）を見ると、具体的にイメージできるかもしれません。

尚、サポートしているプラットフォームは、AWSやGoogle、OpenStack等です。OSはLinuxを中心にサポートしています。こちらもお試しサンプルスクリプトを公開しています。その他の情報は下記リンクから入手できます。

• プロジェクトHP　（https://github.com/emccode/rexray）
• Document　（http://rexray.readthedocs.org/en/stable/）
• Slack [#project-rexray]　（https://codecommunity.slack.com/）

ここで紹介したOSSで、気になったものがあれば是非コミュニティに参加してください。特に、Slackの各チャネルでは、毎日様々なやり取りが行われていますので覗いてみてください。

尚、「EMC{code}」というサイトでこれらのOSSやサンプルコードを公開しています。また、今回投稿した内容はSlideshare（意外と斬新！ストレージやベアメタルまでカバーするEMCのOSSとは？）で公開しています。ご興味上がればそちらもご覧ください。

こんにちは。吉田です。

11月10日～11日の二日間に渡り、ヴイエムウェア株式会社が主催する「vForum 2015」が東京で開催されました。同じく11月19日には大阪で開催されました。

東京の会場ではEMCもダイヤモンドスポンサーとして協賛し、ブースによる出展とセッションを提供しました。EMCのブースには、オールフラッシュストレージ、バックアップソリューション、コンバージドインフラ、クラウドソリューションを展示しました。私は二日間ともブースに滞在したのですが、初日から多くの来場者の方々とお話しすることができました。印象的だったのは、オールフラッシュストレージに関する質問が多かった事です。特に、「フラッシュストレージの導入は決まっている。今は製品選定の段階に来ている」という方が多く、熱心に担当者の説明に耳を傾けていました。

一方、東京と大阪ともにEMCのセッションでは私がスピーカーを務め、EMCのクラウドソリューションである「Federation Enterprise Hybrid Cloud」（以下、FEHC）を紹介しました。このFEHCは昨年から提供を始めたソリューションですが、導入実績は世界中で既に二十社を超えました。ここで、簡単にその内容をご紹介します。

FEHCは、VMwareとEMCの製品を組み合わせてITをサービスとして提供するクラウド基盤を実現し、EMCのインプリメントサービスと保守サービスを一括して提供するソリューションです。

このソリューションを企業のIT基盤に導入すると、エンドユーザーはVMware vRealize Automationが提供するセルフポータルから、必要な時に必要なリソースを即座にプロビジョニングできるようになります。仮想マシンのバックアップ設定もメニューから選択するだけで自動的に設定されます。当然ながら、バックアップしたデータをリストアする作業も、エンドユーザーがポータル画面から簡単な操作をするだけで実行できます。

これを実現しているのは、VMwareとEMCソフトウエアのインテグレーションです。

EMCのViPRは、セルフポータル機能と結合してストレージアレイの制御を実現します。また、EMCのバックアップ製品はVMware vRealize Orchestrator向けにplug-inを提供しているので、それを導入すればOrchestratorを通じてバックアップの制御が可能になります。

更に、様々なオペレーションを実現するOrchestrator向けのワークフローテンプレートを開発・提供します。これを活用すれば、本来企業のIT部門自身が時間を費やして準備しなければならなかった「自動化のための開発」は不要となり、無駄な時間とコストを削減できます。

多くのソフトウエアとハードウエアを組み合わせて構築するプライベートクラウド環境では、製品選定と動作確認だけで膨大な労力と時間を要します。しかし、このソリューションではインフラ全体の基本設計と動作確認は、EMCにて終わらせています。新しいバージョンがリリースされたら、新しい環境でテストを行います。これによって、常に最新の製品バージョンで構築することが可能となります。このような作業は、IT部門の管理者が抱える必要がなくなります。

尚、ソリューションの全体像や設計内容については、弊社サポートサイトから各種ドキュメントがご覧いただけます。ご興味のある方は、是非ともダウンロードしてください！

こんにちは。吉田です。

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

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

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

ご安心ください。

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

ハードウエアの管理

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

リソースプールの管理

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

デプロイメント

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

モニタリング

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

アップグレード

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

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

<関連記事>

VxRack Management Prototype @YouTube

こんにちは。吉田です。

5月4日から4日間に渡り、EMCが主催する今年最大のイベント「EMC World 2015」がラスベガスで開催されます。

EMC World 2015 オフィシャルサイト

http://www.emcworld.com/

本 イベントでは、EMC製品やソリューションのみならず各産業の方向性や企業の事例を含めた300以上の興味深いセッションが開催される予定です。また、最 新テクノロジーが試せるハンズオンラボとインストラクターが指導するトレーニング形式のハンズオンラボも準備されています。さらに、80社以上におよぶ パートナー各社のソリューションが集う「ソリューションEXPO」も開催され、各種イベントも企画されています。

残念ながら日本ではゴールデンウィークの真っただ中ではありますが、本イベントで発表される内容や最新の製品情報、会場の雰囲気など、現地の様々な情報を日本語でリアルタイムにお伝えする予定です。是非とも下記サイトをチェックしてください！！

リアルタイムで情報を発信！！　EMC World 2015（Ask the Expert）@EMC日本語コミュニティ

https://community.emc.com/thread/212270

尚、イベント終了後には、この日本語コミュニティを通じて新しい発表内容をみなさまにお知らせします。

こんにちは。吉田です。

前回に引き続き、VMware vRealize Operations （旧名称 vCenter Operations Manager）からEMCストレージのモニタリングを可能にする「EMC Storage Analytics」（以下ESA）をご紹介いたします。今回は、ストレージで性能問題が発生したことを想定して、vRealize Operations（以下Operations）とESAを用いた問題切り分けのポイントをご紹介します。

問題分析の流れ

性能問題が検知された場合、はじめにOperationsの標準ダッシュボード（下図）を開いてシステム全体の健康状態やワークロード、異常、故障個所を把握します。その後、問題となっているコンポーネントを特定します。もし、問題があると推測されるコンポーネントが仮想マシンやホストであれば、そのまま標準ダッシュボードを使って原因を調べることになります。

一方、データストア（ストレージ）に問題があると推測される場合は、ESAのダッシュボード（下図）に移動して、ストレージ装置内部の分析を行う流れになります。前回簡単に触れましたが、EMCストレージが提供しているOperations向けストレージ アダプター（ESAとして提供されるアダプター）を組み込んでおけば、Operationsの画面にESAのダッシュボードが自動的に作成され、ストレージ内部の情報が確認できるようになります。

ESAによる切り分け

ストレージにおいて、性能のボトルネックになり易いコンポ―ンネントはディスクドライブとコントローラーです。性能問題の切り分けとしては、まずコントローラーの状態から確認すると良いでしょう。例えば、ESAのダッシュボードにコントローラーの稼働状態が確認できるよう設定しておくと便利です。下図のようなダッシュボードを構成すれば、ストレージ全体の問題なのか、または特定のコンポーネント（ドライブやボリュームなど）の問題なのかをある程度切り分けることができます。

ここで確認しておきたい項目は、「CPU Busy」と「Throughput」です。それぞれの項目と内容について説明しましょう。尚、ここでは、EMCのストレージ「VNX」を例に挙げて説明します。

• 「CPU Busy（%）」

CPU Busyは、プロセッサーに実装されているCPUの使用率です。長期間に渡り使用率が70%以上で推移している場合は、負荷が高いと判断できます。CPUの使用率を上昇させる要因としては、I/O処理の負荷が高い状態が続くケースです。それ以外にも、スナップショット、レプリケーション、重複排除など各種機能を同時に利用することで、CPU使用率が若干上昇する場合があります。

• 「Throughput（IOPS）」

Throughputは、ストレージが一秒間に処理するI/O数を示します。ここで確認するポイントは、IOPS値のバランスです。2台あるコントローラー（VNXの場合は ストレージプロセッサーAおよびB）のIOPS値を比べて、概ね同じであれば問題ありません。もし、片方のコントローラーにI/O処理が集中していたら、ボ リューム（LUN）のOwnerを変えることで、負荷が分散される場合があります。ちなみに、Throughputの値を記録しておくと、何かと便利です。例えば、サーバーを増設する際、増設前後で性能面におけるストレージの影響を振り返ることができます。また、ストレージ装置を新しいも のにリプレイスする際などに、サイジングの基礎データとしても活用できます。その点、Operationsは過去1年間のデータが記録されており、いつでもグラフで確認することができるので便利です。読み込みと書き込みI/Oの比率を把握しておくことも、問題分析の役に立ちます。

ちなみに、一世代前のVNXシリーズ（VNX5300やVNX5500など）をご利用いただいている場合は、次に説明する「Dirty Cache Page」もチェックすることをおすすめします。

• 「Dirty Cache Page（%）」

Dirty Cache Pageは、プロセッサーに実装されているキャッシュメモリにおいて、予め確保されている「書き込みデータ用格納領域」の使用率を表しています。ホストからVNXに書き込まれるデータは、必ずこのキャッシュ領域に一旦保持されます。その後、書き込まれたデータは一定の規則に従ってディスクドライブに書き出されます。従って、このキャッシュ領域に空き容量が無くなると、ホストからの書き込み処理が遅くなります。Dirty Cache Pageの値は、60～80%の値で推移していれば正常と判断できます。しかし、常時100%近い値が継続している場合は、ホストからの書き込みが多く、ストレージ全体的に性能が低下している可能性が高いと言えます。この原因としては、概ね2つ考えられます。一つは、実装しているディスクドライブの書き込み処理が遅いためにキャッシュが溢れていること。もう一つは、そもそもコントローラーの性能限界（CPU処理能力とキャッシュメモリ領域不足）に達していることです。

他にも、ESAは便利なダッシュボードを提供しています。次回も問題切り分けを意識しながら、その他のダッシュボードについてご紹介します。

<関連記事>

EMC Storage Analytics (ESA) で運用の効率化を！(1)

VMware Blog "EMCストレージ EMC Storage Analytics と vRealize Operations Manager の連携をご紹介！"