Find Communities by: Category | Product

1 2 Previous Next

日本語コミュニティ

17 Posts authored by: Naotake Yoshida

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

 

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

 

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

https://eventregist.com/e/dellemc_20181108

 

 

日 時 

2018/11/8(木)
【セッション】14:00-17:00 (13:30受付開始)
【懇親会】17:00-18:00

会 場

EMCジャパン株式会社 東京本社セミナールーム(新宿マインズタワー20階)

主 催

DELL EMC

対 象

エンドユーザ企業及びその情報システム会社のITインフラ企画・運用ご担当者様
パートナー企業ご担当者様

*競合企業の方のご登録につきましては、原則参加はお断りさせていただきます。

費 用無料(事前登録制)
定 員60 

 

 

 

セッション

『マイクロソフトのハイブリッド クラウド戦略の最前線 “Azure Stack” が切り開く未来』

 

日本マイクロソフト株式会社

インテリジェントクラウド統括本部 グローバルブラックベルトセールス部

テクノロジーソリューションズプロフェッショナル

中村幸児様

 

 

パブリッククラウド市場の占有率が上昇しているMicrosoft Azure。本セッションでは、Azureが選ばれる理由とその最新動向を紹介するとともに、Azure Stackによるハイブリッドクラウドが企業にもたらす真の価値について、海外の導入事例を含めビジネスとテクノロジーの両面から解説します。ビジネス部門やクラウド戦略立案を担う方々にとって、今後の IT 戦略を検討する際の価値ある情報をお伝えします。

『実際にAzure Stackを検証、運用して分かったこと』


三井情報株式会社

ソリューション技術グループ チーフアーキテクト

養老利紀様

 

Microsoft Azureに関する多くの魅力的なサービスが発表され、ますます目が離せない状況になってきました。そんなAzureクラウドを自社のデータセンターで使えるようにするのがAzure Stackです。三井情報株式会社は、国内で最も早くからAzure Stackを導入し、様々な検証を経て運用しています。本セッションでは、そのリアルな経験から感じたことをお話しします。ハイブリッドクラウド化の動向調査やAzure Stackの導入を本気で考えている方々に最適なセッションです。


『最新ハイブリッドクラウドプラットフォームのリアルな価値と選び方』


EMCジャパン株式会社

アドバンスドテクノロジーソリューションズ事業部

クラウド プラットフォーム スペシャリスト

平原一雄

 

ハイブリッドクラウドと称するものが市場にひしめく状況で、Azure Stackというプラットフォームを選択すべき理由は何か?また、インフラを選定、設計する方々にとってAzure Stackを導入することの何が嬉しいのか?このセッションでは、ハイパーコンバージドインフラ市場でNo.1の実績を誇るDell EMCだからこそ実現できる最新プラットフォームの姿をご紹介します。クラウドインフラの設計やプラットフォームを選定する方々に有益なセッションです。


パネルディスカッションとQ&A 『ここでしか聞けない本音トーク!』


パネリスト

  日本マイクロソフト 中村幸児様

  三井情報 養老利紀様、芦田信太郎様

  EMCジャパン 平原一雄


ファシリテーター

  EMCジャパン 吉田尚壮


企業の皆様から寄せられたAzure Stackに関するリアルなご意見やご要望、懸念点などを披露しながらディスカッションを進めます。それぞれの企業で何が課題になっているのか?ハイブリッドやマルチクラウドに何を期待しているのか?ディスカッションを通じてビジネスとテクノロジーの両面からITのあるべき姿を模索します。


懇親会

 

軽食とドリンクをご用意しております。気軽にエキスパートと直接お話しください!!

 

 

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

 

吉田

2018年1月31日(水)にAzure Stackのセミナーを開催します。

 

今回は三井情報開発株式会社とPivotalジャパンの共催で実施し、各社のAzure Stackの取り組みやソリューションについて紹介する予定です。


将来のITを設計したり企業の戦略にどう活用できるのかなど、Azure Stackの適用領域や活用方法がわかるセッションで構成しています。参加費用は無料!是非とのご参加ください!! 


申し込みはこちらからどうぞ!

 

 

 

開催概要

日 時

2018/1/31(水) 14:30-17:00 (14:00受付開始)

会 場

御茶ノ水ソラシティ sola city Hall [EAST]

主 催

DELL EMC (EMCジャパン株式会社)

共 催

Pivotalジャパン株式会社 / 三井情報株式会社

対 象

-Azureへの移行やハイブリッドクラウド化を検討されているお客様

-既にAzureを使用している中で課題を抱えているお客様

*競合企業の方のご登録につきましては、原則参加はお断りさせていただきます。

費 用

無料(事前登録制)

定 員

100

 

告知サイト→ 【東京開催】『デジタル変革を加速する! Azure Stackでつくるハイブリッドクラウド』~統一されたハイブリッドクラウド運用で効率性とアプリ開発・展開のスピードを最大化する~|EventRegist(イベントレジスト)

 

 

アジェンダ

14:30-15:10

『デジタル変革を促進するAzureハイブリッドクラウド

~Azure Stackによるハイブリッドクラウドの融合がスピードと運用を変える』


EMCジャパン株式会社  クラウドプラットフォームスペシャリスト

吉田 尚壮

15:20-16:00

『Azureハイブリッドクラウドの本当の価値を引き出すPaaSの活用

~Cloud Foundry on Azure & Azure Stackがもたらすメリット』

 

Pivotalジャパン株式会社

16:10-16:50

『デジタルトランスフォーメーションを支える、ハイブリッドクラウドシナリオのご紹介』


三井情報株式会社

デジタルトランスフォーメーションセンター R&D部 研究開発室 

室長 青木 賢太郎

16:50-17:00

Q&A

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



お試し環境


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

rex-ray_env.jpg


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

rex-ray_yml2.jpg

rex-ray_env2.jpg




REX-Rayでボリューム作成


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

rex-ray_ope1.jpg


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

rex-ray_ope1-1.jpg


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

rex-ray_ope2.jpg


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

rex-ray_ope2-2.jpg


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

rex-ray_ope3.jpg




Dockerからボリューム作成


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

rex-ray_ope4.jpg


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

rex-ray_ope5.jpg


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

rex-ray_ope6.jpg


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




コンテナからマウント


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

dockerrun-rexray.jpg


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

dockerrun-rexray2.jpg




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


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

dockerrun-rexray3.jpg


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

dockerrun-rexray4.jpg


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

dockerrun-rexray5.jpg


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

dockerrun-rexray6.jpg


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

dockerrun-rexray7.jpg


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


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



参考


過去の関連記事



こんにちは。吉田です。

 

今回は、DockerのVolume Pluginとして活用すると便利な「REX-Ray」について紹介します。

 



DockerのVolume Plugin


簡単に言うと、外部ストレージの管理を仲介してストレージを使い易くするソフトウエアがVolume Pluginです。Volume Pluginを使えば、ストレージを操作する際、ストレージ製品(またはサービス)の専用コマンドを実行しなくても、ボリュームの作成や削除、マウント、アンマウント等の操作が可能になります。コンテナは、Volume Pluginで構成したボリュームをマウントして使用することが出来ます。

docker_vp1.jpg

Docker Documentによると、現時点(2017年2月)でVolume Pluginとして認識されているものは20種類以上あります。これらのVolume Pluginの中には、NAS(NFS)やブロックストレージだけではなく、パブリッククラウドのストレージサービスとのインテグレーションを実現するものも含まれています。




REX-Rayとは


Dell EMCのOSSプロジェクトで開発している「REX-Ray」は、DockerのVolume Pluginとして動作します。このREX-Rayを例に挙げながらVolume Pluginを活用するメリットを再確認しましょう。

rex-ray1.jpg

REX-Rayは、Dell EMCのストレージ(ScaleIO、XtremIOなど)の他にOpenStackやVirtualBox、AWS、Azure等のパブリッククラウドサービスでも使うことができます。さらに、REX-RayはMesosやKubernetesなどのクラスタ管理フレームワークと連携することもできます。ちなみに、細かい話をするとREX-Rayは「libStorage」(Dell EMCのOSSプロジェクト)をストレージ制御のエンジンとして活用しています。故に、REX-Rayをインストールすると、もれなくlibStorageも同時にインストールされます。見方によっては、REX-RayはlibStorageにCLIやエンドポイントとしての役割を追加して、より使い易くしたものと言えます。




DockerとREX-Rayの関係


REX-Rayは、Dockerのホストにインストールして使用します。インストールはコマンド一行で終わるので非常に簡単です(下図)。その後、"/etc/rexray/config.yml"ファイルでストレージ側のエンドポイント(REST APIを受け付けるストレージプロバイダーのURI)などを登録してサービスを再起動すれば、REX-Rayからストレージの操作が可能となります。詳細はこちらをご覧ください。

rex-ray4.jpg


一方、Dockerのコンテナを起動する際、"--volume-driver=rexray"オプションを使用することで、REX-Rayで構成したボリュームをコンテナからマウントして使用することができます。そのボリュームへ書き込んだデータは、外部ストレージ内に保持されます。

rex-ray2.jpg

 


そもそも外部ストレージを利用するメリットは?

 

コンテナであってもMySQLやPostgreSQLなどのデータベースを使用するシーンは多くあります。この時、ホストの内蔵ディスクだけでは賄えない高い性能が必要だったり、データの可用性も担保したい場合は、外部ストレージの方が適していると言えます。


また、Volume Pluginの多くは外部ストレージに構成したボリュームをDockerのホストへ簡単にマウント(またはアンマウント)できます。この仕組みを利用するとDockerのImmutable Infrastructure的な特性を活かしつつ、データベースアプリケーションの継続的な運用が実現します。

rex-ray3.jpg

例えば、あるホストでPostgreSQLのコンテナが起動しているとしましょう。この時、PostgreSQLはVolume Pluginで構成された外部ストレージのボリュームを使っているとします。この環境であれば、仮にホスト障害でコンテナがダウンしても、別なホストでPostgreSQLのコンテナを起動し、Volume Pluginを使ってボリュームを指定すれば、継続して既存のデータを使い続けることができます。


次回は、DockerとREX-Rayのコマンドを使いながら、具体的なオペレーションについて紹介します。



参考


次の記事


過去の関連記事



Naotake Yoshida

DockerのData Volume

Posted by Naotake Yoshida Jan 31, 2017

こんにちは。吉田です。


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

DataVolume1.jpg

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

DataVolume2.jpg

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

DataVolume3.jpg

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

DataVolume4.jpg




Mount a host directory as a Data Volume


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

DataVolumeHost2.jpg

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

DataVolumeHost1.jpg

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

DataVolumeHost4.jpg




Data Volume Container


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

DataVolumeCont1.jpg

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

DataVolumeCont2.jpg

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

 



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


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

 

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



参考


関連記事



こんにちは。吉田です。


今回は、VirtualBoxでScaleIO V2.0を試す方法を紹介します。この環境を作ればScaleIOをベースとしたDockerのPersistent Volumeを確認することもできますので、是非お試しください!


Dell EMCは多くのOSSプロジェクトを推進しており、GitHubにコードを公開しています。同様に、それらのOSSを簡単に試せるようなサンプルコードを公開していたり、OSSと組み合わせてストレージ管理を自動化するコードも公開しています。以前ブログで紹介した通り、ScaleIO(現在はScaleIO V2.0)をVirtualBox上に展開するサンプルコードが公開されているのですが、先日試したところ私のPCではうまく動かなかったため、独自にコードを書き起こしてみました。今回はこれを使って試す方法を紹介します。



全体の構成


Vagrantコマンドを使ってVirtualBox上にCentOS7.2の仮想マシンを三つ作成します。その後、ScaleIOのInstall Manager(IM)を使ってScaleIOをインストールします。最後に、DockerとREX-Rayをインストールするスクリプトを実行すれば完了します。ちなみに、「REX-Ray」とはDockerのVolume Pluginとして動作するDell EMCのOSSです。一方、PCとVirtualBox上の仮想マシンはポートフォワーディングされて通信します。尚、仮想マシンのプライベートネットワーク構成では敢えてVirtualBoxの "Host Only Adapter" を使っていません。

virtualbox_config1.jpg



準備するもの


PC(Windows or Mac)に、下記ソフトウエアをPCにインストールします。PCはインターネット接続されていることが前提で、メモリは3GB以上空いているのが望ましいです。

  • VirtualBox (5.1以上)
  • git    (2.11以上)
  • Vagrant  (1.9以上)


 

操作手順


GitHubにあるこちらリポジトリをコピーしておき、gitコマンドでPCのワークスペースにcloneします。その後、ディレクトリを変えてvagrant upコマンドを実行し、VirtualBox上に仮想マシンを作成します。仮想マシンを作成するまでの処理は、インターネットとの通信(下り)が2MB/s程度確保できていれば20分程度で完了します。


1. 任意のターミナル(Windowsであればコマンドプロンプト、gitbash等)を起動し、下記コマンドを実行する

  [PC]$ git clone https://github.com/naotakeyoshida/scaleio2.0-rexray.git

  [PC]$ cd scaleio2.0-rexray

  [PC]$ vagrant up

 

  gitclone.jpg

 

もし、インターネットとの通信が遅い場合(目安としては1MB/s以下)、上記手順の「vagrant up」を実行する前に、ScaleIOのインストールファイル(ScaleIO Linux版)をこちらから事前にダウンロードしておくと、仮想マシンの展開時間が短くなります。ダウンロードしたファイルは、上記手順で作成された「scaleio2.0-rexray」フォルダに保存しておきます。この時、ファイル名を "ScaleIO_Linux_v2.0.zip" に変更してください。その後、「vagrant up」コマンドを実行してください。


   git cloneコマンドを実行した直後の状態(↓)

  scaleiozip1.jpg

   ScaleIOのインストールファイルを事前にダウンロード/保存した状態(↓)

  scaleiozip2.jpg


   仮想マシン作成後の画面(↓)

  virtualbox.jpg


 

VirtualBox上に仮想マシンが三つ(TB, MDM1, MDM2)作成されたら、ScaleIO IMにアクセスしてScaleIOを仮想マシンにインストールします。ScaleIOのインストールで必要なパッケージファイルは、「scaleio2.0-rexray」フォルダに展開されています。


2. PC上のブラウザを起動して「https://127.0.0.1:4431」へアクセスする。ユーザー名 "admin"、パスワード "Password123!" でScaleIO IMにログインする

  scaleioim.jpg


3. ログイン後、画面上部の「Packages」をクリックしてScaleIOのLinux向けパッケージファイル(rpm)を全て読み込ませる(パッケージは「scaleio2.0-rexray/scaleio」フォルダ配下の「ScaleIO_2.0.1.2_RHEL_OEL7_Download」フォルダに格納されています)。その後、画面下部の「Proceed Install」をクリックする

  rpm.jpg


4. 「Install」フェーズ画面に移り、ここでScaleIOの構成ファイル "ScaleIO_3Nodes_Config.csv" を読み込ませる(構成ファイルは「scaleio-rexray」フォルダに格納されています)

  csv.jpg  


5. 構成ファイルを読み込ませた後の画面で、四か所にパスワード "Password123!" を入力し、License項にチェックをいれてから「Start Installation」ボタンを押す。その後、画面上部の「Monitor」リンクをクリックして「Start Upload Phase」→「Start Install Phase」→「Start Configure Phase」をクリックしてインストールプロセスを進める

  pw.jpg


6. インストールが完了したら、「Mark Operation Completed」ボタンをクリックしてブラウザを閉じる

  complete.jpg



次に、ScaleIO GUIでアクセスを試みます。


7. PCにScaleIO GUIをインストールする(インストールファイルは「scaleio2.0-rexray/scaleio」フォルダにあります)

8. ScaleIO GUIを起動して、「127.0.0.1:6611」に接続します。その後、ユーザー名 "admin"、パスワード  "Password123!" でログインする

  gui1.jpg

9. ScaleIO GUIのダッシュボードでSDS(三つ)とSDC(三つ)、およびProtection Domainが構成されていれば、ScaleIOのインストールは完了



最後に、DockerとREX-Rayをインストールします。


10. 「scaleio2.0-rexray」フォルダへ移動する。その後、「vagrant ssh」コマンドで仮想マシンにログインし、スクリプトを実行する

  [PC] $ vagrant ssh tb

  [TB] $ sudo bash /vagrant/scripts/rexray-tb.sh

  [TB] $ exit

  

11. 他の仮想マシンでも同様にスクリプトを実行する

  [PC] $vagrant ssh mdm1

  [MDM1] $ sudo bash /vagrant/scripts/rexray-mdm.sh

  [MDM1] $ exit

  [PC] $ vagrant ssh mdm2

  [MDM2] $ sudo bash /vagrant/scripts/rexray-mdm.sh

  [MDM2] $ exit


 

ここまでスクリプトが止まらずに進められたら環境構築は成功です。この後は、ScaleIOのコマンドを実行して色々試すことができますし、REX-RayやDockerを試すことも出来ます。尚、ScaleIOのマスターMDMは、"MDM1"に定義されています。

   

    インストール後の構成(↓) 

  virtualbox_config2.jpg

その他の注意点


もし、途中でエラーが出て止まることがあれば、PCから「vagrant destroy」コマンドで一度仮想マシンを削除してから再度「vagrant up」コマンドで処理を進めてください。

 

また、この環境を維持したままPCをシャットダウンする際は、予め「vagrant suspend」コマンドで仮想マシンをサスペンド状態にして下さい。次回PCを起動した後で、「vagrant resume」コマンドを実行すれば、仮想マシンが起動して元の状態に戻ります。

 

次回は、この環境を使いながらDockerのPersistent VolumeとREX-Rayについて紹介します。



関連記事

こんにちは。吉田です。

 

 

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

 

 

 

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

 

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

coprhd01.jpg

 

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

coprhd02.jpg

 

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

 

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

 

 

 

 

 

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

 

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

 

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

 

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

rackhd01.jpg

 

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

rackhd02.jpg

 

 

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

 

 

 

 

 

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

 

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

 

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

rex-ray01.jpg

 

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

rex-ray02.jpg

 

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

 

 

 

 

 

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

 

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

こんにちは。吉田です。

 

今回は、PCで簡単に「ScaleIO」を試す方法を紹介します。

操作の流れはYouTubeに公開していますので、まずはそちら(↓)をご覧ください。




準備するもの

 

みなさんがお使いのPC(Windows or Mac)に、下記三つのソフトウエアをダウンロード&インストールします。VirtualBoxは仮想マシンを展開できるソフトウエアです。gitは、 ソースコード管理ソフトウエアで有名なOSS。Vagrantは、HashiCorp社が提供している仮想環境構築を支援するOSSです。尚、PCの空き 容量は「最低5GB」必要ですのでご注意ください。

 

 

  • VirtualBox (ダウンロードはこちら
  • git (ダウンロードはこちら
  • Vagrant (ダウンロードはこちら

 



操作手順

 

上記ソフトウエアの準備ができたら「EMC {code}」(EMC {code} | Community Onramp for Developer Enablement) にブラウザでアクセスします。「EMC {code}」はEMCのOSSを公開しているコミュニティサイトで、OSSのソースコードだけではなく、他のOSSと組み合わせてお試しできるサンプル コードも公開しています。この中から「vargant-scaleio」のアイコンをクリックしてサンプルコードのリポジトリへ移動します。

 

scio01.jpg

 


そこで、リポジトリのURLをコピーしておきます。


scio02.jpg



次に、PCに戻ってターミナル(Windowsであればコマンドプロンプトなど)を開き、サンプルコードをCloneするディレクトリ(ワークスペース)へ 移動します(ここでは、Windows版Gitにオプションで付属している「Git Bash」を使います)。その後、"git clone"コマンドを実行します。リポジトリがコピーされたら、ディレクトリを移して"vagrant up"コマンドを実行します。

 

$ git clone <リポジトリURL>

$ cd vagrant-scaleio

$ vagrant up

 

scio03.jpg

scio04.jpg

 

 

すると、CentOSのBoxイメージがPCにコピーされ、VirtualBoxにCentOS6.5ベースの仮想マシンが三つ作られると同時に、 ScaleIOが自動的にインストールされます。その過程でScaleIOのインストールファイルもPCにダウンロードされます。ネットワークの速度によ りますが、早ければ7、8分程度で処理が完了します。ネットワークが遅い場合は、20分以上かかってしまう場合もありますが、途中で失敗した場合は VirtualBox上の仮想マシンを削除して、"vagrant up"コマンドからやり直しができます。

 

scio20.jpg

 

 

 

ScaleIOを試す!

 

VirtualBox 上に三つの仮想マシンが立ち上がったら、"vagrant ssh"コマンドで仮想マシン(CentOS)へログインします。仮想マシンホスト名はそれぞれ「mdm1」、「mdm2」および「tb」です。ここでは ScaleIOのプライマリ管理ノードである「mdm1」へログインします。

 

$ vagrant ssh mdm1

 

 

CentOSにログインできたら、ScaleIOのコマンドを実行できるようにするため、下記コマンドでScaleIOの管理コンポーネントの認証を行います。下記コマンドでログインしたのち、いくつかのコマンドを試してみましょう。

 

$ scli --login --username admin --password Scaleio123

 

scio05.jpg


はじめに、下記コマンドでScaleIOのクライアントノードとサーバーノードを確認してみましょう。クライアントとサーバーはそれぞれ三つ定義されています。つまり、この環境では三つの仮想マシンがそれぞれクライアントとサーバーとして動くということになります。


$ scli --query_all_sdc

$ scli --query_all_sds


scio06.jpg



次に、下記コマンドでボリュームを一つ作成してみましょう。この環境では、予め"pdomain"という名前のプロテクションドメインが定義されています。 プロテクションドメインとはScaleIOノードをグループ化する仕組みです。同じく"pool1"という名前のプールも定義されているので、このプール を使って8GBのボリューム(ボリューム名は"vol2")を作成してみます。


$ scli --add_volume --protection_domain_name pdomain --storage_pool_name pool1 --size_gb 8 --volume_name vol2


scio07.jpg



下記コマンドでボリュームが作成されたことを確認します。


$ scli --query_all_volume


scio08.jpg



ボリュームが作成されたら、それをクライアントに見せる処理(マッピング)を行います。ScaleIOでは、下記コマンドでボリュームを特定のクライアントだけに見せる処理を行います。


$ scli --map_volume_to_sdc --volume_name vol2 --sdc_ip 192.168.50.12



ボリュームが公開されたクライアント側から見てみると、/devにデバイスが一つ増えていることが確認できます。この後は通常の操作と同じくデバイスをマウントして使用できます。



<マッピング前>

scio09-1.jpg


<マッピング後>

scio09-2.jpg




ちなみに、サンプルリポジトリをcloneしたディレクトリには、ScaleIOのインストールファイルがダウンロードされています。その中に、ScaleIOのGUIが含まれていますので、それをインストールすればGUIも試すことができます。


scio12.jpg



同じディレクトリに、ユーザーガイドやリリースノードもありますので、そちらもご覧いただきながら他のコマンドも是非お試しください。



こんにちは。吉田です。

 

 

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

 

 

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

 

 

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

FEHC.jpg

 

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

FEHC2.jpg



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

FEHC3.jpg

 

 

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

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

FEHC4.jpg

 

 

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

FEHC5.jpg

FEHC6.jpg

 

 

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

FEHC7.jpg

 

 

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

FEHC8.jpg


こんにちは。吉田です。


10月27日より「OpenStack Summit」が品川で開催されます。


OpenStack Summitは、年に2回開催されるOpenStackの公式イベントですが、2015年は5月のバンクーバー開催に引き続き、東京で開催されることになりました。バンクーバーの来場者は6000人でしたが、今回はそれを上回ることが期待されています。

 

さて、EMCはOpenStack FoundationのGold MemberとしてOpenStackプロジェクトに参画していますが、今回のイベントではセッションおよびブースを通じて、最新情報を来場者のみなさまへ提供する予定です。EMCが提供するセッションは下記4セッションですが、それ以外にもEMCの開発エンジニアがパネルディスカッション等に参加して意見交換を行います。OpenStackのストレージ関連情報を収集している方は、ぜひチェックして下さい!セッションのスケジュールはこちら

 

 

 

<EMCセッション>

  • 10月27日(火) 14:50-15:30     「Battle of the Titans」~ ScaleIOのリアルタイムデモンストレーションを通じてCephとの違いをを紹介します
  • 10月28日(水) 15:40-16:20     「Orchestrate ALL The (Storage) Things」~ オープンソースのSDSコントローラ(CoprHD)によるOpenStackのデータ可用性を紹介します
  • 10月28日(水) 16:40-17:20     「Operating at Web-scale」~ OpenStack環境におけるContainerの拡張性や可用性についてディスカッションします
  • 10月28日(水) 17:30-18:10     「Cloud Storage in your datacenter」~ Amazon S3やSwift、およびHadoopなど大容量クラウドストレージにおけるオープンソース管理ツールを中心とした活用方法について紹介します

 

 

 

一方、ブースではOpenStackに関連するEMCのソリューションを展示しています。特に、Software-Defined Storageとして注目されている「ScaleIO」のデモもご覧いただけます。

 

EMC ScaleIO.jpg

 

 

「ScaleIO」は、汎用サーバーにインストールして使うストレージソフトウエア。セットアップがとても簡単でノード拡張もシンプルです。評価版は、誰でもダウンロードしてフル機能が試せるので、これからOpenStack環境を検証する管理者や本格導入を検討しているシステム選定者にオススメの製品です。評価版ダウンロードサイトはこちら

 

尚、イベント会場のEMCブースには、EMCの日本人スタッフも常駐していますので、お気軽にお声掛け下さい。

 

こんにちは。吉田です。

 

今回は「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

こんにちは。吉田です。

 

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

こんにちは。吉田です。

 

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

 

 

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

http://www.emcworld.com/

EMCW_Top.png

 

 

 

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

EMCW_ShowCase.png

 

 

 

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

 

 

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

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

EMCW_AskTheExpert.png

 

 

 

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

こんにちは。吉田です。

 

先日、品川で開催されたOpenStackのイベント「OpenStack Days Tokyo 2015」にてEMCもブースを構えると共に、40分間のセッションを行いました。セッションでは、EMCのOpenStackに対する取組みやソリューションについて紹介しました。お陰様でセッションは立ち見が出るほど多くの方々にお集まりいただきました。また、デモンストレーションを交えて紹介した「ScaleIO」と言う製品に関しては、驚くほど問い合わせが殺到し一次的にEMCブースが大混雑する場面も見られました。

 

今回は、セッションの概要を紹介します。

 

セッションでは、弊社若松がEMCの取り組みと関連製品、及びソリューションを紹介しました。EMCは、エンタープライズが求める信頼性や安定性をOpenStackでも実現できるよう、ストレージレイヤーでコミュニティに貢献したり、製品開発に力を入れています。例えば、CinderやManilaの開発プロジェクトに参画してバグフィックスや機能拡張に寄与しています。また、各種ストレージドライバーを提供しており、現在では主要EMCストレージ製品が全てOpenStack環境で利用可能となっています。

OpenStack_EMC1.png

 

 

さらに、OpenStack環境において利用者の選択肢を広げ、さらなる効率化を実現する製品も紹介しました。まずは、スケールアウト型ブロックストレージであるScaleIOを紹介。ソフトウエアベースであるため、コモディティサーバをストレージとして活用できます。オンラインでスケールイン/アウトが可能であり、OpenStack環境に最適なストレージと言えます。

 

もう一つは「ViPR」です。ViPRはストレージを統合的に管理できる機能を持っているソフトウエアですが、オブジェクトストレージとしても利用できます。このオブジェクトストレージは、Swiftと互換性のあるAPIを提供しており、OpenStack環境でも活用の幅を広げます。

 

一方、ソリューションとしても新しい取り組みを計画しています。昨年、EMCは「cloudscaling」という会社を買収しました(2014年10月に正式発表)。cloudscalingはOpenStackのスペシャリストが集結している企業ですが、彼らが提供していたOpenStackベースのエンタープライズ向けリファレンスアーキテクチャーをEMCのクラウドソリューションに取り込む計画があります。未だ詳細は公表できませんが、正式発表され次第この場でも紹介させていただく予定です。

OpenStack_EMC2.png

 

 

セッションの後半では、私からScaleIOを紹介しました。途中で弊社新宿オフィスのデモ環境にリモート接続し、たった1,2分で初期セットアップが完了する操作のデモをご覧いただきました。ストレージ専用機が不要で、あっという間に導入できる。さらに、スケールアウトも非常に簡単である点がみなさまの高い評価につながったのかもしれません。

 

二日間に渡り、ブースで多くの来場者の方々にScaleIOを紹介させていただきましたが、「早速使ってみたい」とか「まじめに導入を検討してみるよ」など、非常に前向きなコメントを数多くいただきました。今後、ScaleIOの特徴やOpenStack環境で使用するメリットについて、この場でも紹介したいと思います。

 

 

<関連記事>
OpenStackでエンタープライズレベルの信頼性をどう確立するか?(ITproActive)

EMC、Cloudscaling社、Maginatics社、Spanning社を買収(プレスリリース)

こんにちは。吉田です。

 

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

 

 

問題分析の流れ

 

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

 

Ops6.0_ESA_Top.png

 

 

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

 

Ops6.0_ESA_Overview.png

 

 

ESAによる切り分け

 

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

 

Ops6.0_ESA_Controller.png

 

 

ここで確認しておきたい項目は、「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 の連携をご紹介!"

Filter Blog

By date:
By tag: