何でもありの備忘録
by takahiro_komiya
S M T W T F S
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
カテゴリ
以前の記事
2017年 10月
2017年 09月
2017年 08月
2017年 07月
2017年 06月
2017年 05月
2017年 04月
2017年 03月
2017年 02月
2017年 01月
2016年 12月
2016年 11月
2016年 10月
2016年 09月
2016年 08月
2016年 07月
2016年 06月
2016年 05月
2016年 04月
2016年 03月
2016年 02月
2016年 01月
2015年 12月
2015年 11月
2015年 10月
2015年 09月
2015年 08月
2015年 07月
2015年 06月
2015年 05月
2015年 04月
2015年 03月
2015年 02月
2015年 01月
2014年 12月
2014年 11月
2014年 10月
2014年 09月
2014年 08月
2014年 07月
2014年 06月
2014年 05月
2014年 04月
2014年 03月
2014年 02月
2014年 01月
2013年 12月
2013年 11月
2013年 10月
2013年 09月
2013年 08月
2013年 07月
2013年 06月
2013年 05月
2013年 04月
2013年 03月
2013年 02月
2013年 01月
2012年 12月
2012年 11月
2012年 10月
2012年 09月
2012年 08月
2012年 07月
2012年 06月
2012年 05月
2012年 04月
2012年 03月
2012年 02月
2012年 01月
2011年 12月
2011年 11月
2011年 10月
2011年 09月
2011年 08月
2011年 07月
2011年 06月
2011年 05月
2011年 04月
2011年 03月
2011年 02月
2011年 01月
2010年 12月
2010年 11月
2010年 10月
2010年 09月
2010年 08月
2010年 07月
2010年 06月
2010年 05月
2010年 04月
2010年 03月
2010年 02月
2010年 01月
2009年 12月
2009年 11月
2009年 10月
2009年 09月
2009年 08月
2009年 07月
2009年 06月
2009年 05月
2009年 04月
2009年 03月
2009年 02月
2009年 01月
2008年 12月
2008年 11月
2008年 10月
2008年 09月
2008年 08月
2008年 07月
2008年 06月
2008年 05月
2008年 04月
2008年 03月
2008年 02月
2008年 01月
2007年 12月
2007年 11月
2007年 10月
2007年 09月
2007年 08月
2007年 07月
2007年 06月
2007年 05月
2007年 04月
2007年 03月
2007年 02月
2007年 01月
2006年 12月
2006年 11月
2006年 10月
2006年 09月
2006年 08月
2006年 07月
2006年 06月
2006年 05月
2006年 04月
2006年 03月
2006年 02月
2006年 01月
2005年 12月
2005年 11月
2005年 10月
2005年 09月
2005年 08月
2005年 07月
2005年 06月
2005年 05月
2005年 04月
2005年 02月
2005年 01月
2004年 12月
2004年 11月
<   2015年 08月 ( 14 )   > この月の画像一覧
Brocade AMP その3
AMPではフロー単位にモニタリングを行う。ではフローの設定は?というと、基本は全フローが対象なので、自動的に学習し、モニタリングする。ITもしくはITLネクサス単位に比較することは可能だ。

また、性能のことばかり書いたが、SCSI Read/Write 以外にも Researve, Release, Inquiry などのコマンドもモニタリングできし、SCSI ERROR などもモニタリングできる。

コマンドラインで情報を確認する例が下記。通常はFabric Visionで通知だけ受ける。

b0068870_1850022.png
b0068870_1850858.png
b0068870_18501880.png
b0068870_18502735.png

by Takahiro_Komiya | 2015-08-31 18:51 | ファイバチャネル
Brocade AMP その2
AMPはリアルタイムモニタリングアプライアンスだ。モニタリングポイントにおいてフローから特徴量を抽出する。前にも書いたが、フローの全量をリダイレクトして分析しているわけではない。各スイッチにおいて前処理をしている。

b0068870_1853873.png


これらの特徴的な情報を Initiator, Target, Fabric において取得することで、どこに問題があるのかを理解することができる。ECTもしくはFRTが Initiator/Target/Fabricのいずれでも大きい値の場合(何より大きいかは言っていない、これは定常的な値との比較になる)、それはおそらく Target が FC Slow Drain Device であることを表す。また、Fabricだけ普通で、Initiator/Target で大きい場合は、Target が SCSI 的に見た Slow Drain であることを示しているはずだ。このようにある一つの事象を抽出するために複数のモニタリングポイントの情報を関連付けしないといけない(しかもリアルタイムに)。これがAMPのやることだ。

一台のスイッチにおいてレイテンシなどの情報を取得することは FOS の bottleneckmon コマンドで可能だ。しかし、アプリケーションフロー的には単一のスイッチの情報だけでは意味を成さない。AMPはファブリックワイドで情報の集積、関連付け、ポリシー比較、通知を行うのが新しい。

これらの情報をつかうことで、AMPはストレージというよりもアプリケーションのコンサルに使える。仮想化の場合は VM ID 的な情報もないとダメだけど。

どういう場合にAMPのようなアプライアンスが必要になるかというと、

1.大規模(ポート数で言うと2000ポートを越えるような構成)
2.複数のストレージ(とりわけ複数ベンダ)がある
3.FCでいうところの世代がまたがる(4GFC, 8GFC, 16GFCなどを混在させている)デバイスが接続されている

とりわけ、2,3の場合はAMPは役に立つだろう。

対象に課題があるとすると、日本では2,3に合致するケースは少ないというところか。
by Takahiro_Komiya | 2015-08-31 18:27 | ファイバチャネル
Brocade AMP (Analytics Monitoring Platform)
ここで性能監視&BIGDATAのことを書いた。これを書いた背景の製品がGAされた。名前は Brocade AMP(Analytics Monitoring Platform)。

今までのpathをタップしてミラーフローを解析するような製品ではないのがポイント。だからスケールさせることが可能。また、Flow Vision/MAPSと組み合わせた監視もできる。いいね。

b0068870_1410517.jpg



MAPSを使った通知例
[MAPS-1003], 5100/4673, FID 128, WARNING, sw0, Flow (SID=010200, DID=010800,VTAP=010200,Lun=1), Condition=sys_mon_analytics (RD_STATUS_TIME_GE_512K/sec>=100), Current Value:[RD_STATUS_TIME_GE_512K, 130us], RuleName=my_custom_rct_rule, Dashboard Category=IO Latency Impact.
by Takahiro_Komiya | 2015-08-26 13:55 | ファイバチャネル
Kinetic Open Storage Project
前にこんなことを書いた。

ITL Nexus + LBA という構造と filesystem という構造と、ファイル/メモリの間にいろいろなレガシーがある。ここを独自に書き換えてしまえば自由を得られる。あとはエコシステムをどう構築するかがポイント。

こんな話は先週知ったのだが、APIを見てもいまいちわからない。

LinuxConで発表されたKOSPは、ストレージサーバによる管理なしに、アプリケーションが直接イーサネット経由でドライブにアクセスすることを可能にする、イーサネット接続とキーバリューストアを提供する。

どうやって?

と思って見てみると、ストレージ・システム管理ソフトウェアが管理する DHCP でIPをアサインすると書いてある。

discovery はサーバ経由か。


なるほど。
by Takahiro_Komiya | 2015-08-24 09:41 | その他 technology
性能管理とBIGDATA
ITL Nexus と LBA の限界の話を書いてしまっているが、この方式だといいのはフローがはっきりみえること。なので、IOフローをモニタしておけば性能も管理できる。

とはいえ、これらの情報は単発では意味が無いので、どこかに集めて Realtime response & Analytics な何時を実現することが必要。昔、Open System Frame Redirection の話でも書いた気がするが、似たような技術を使用してvTAPを構成しモニタすることができるようになる。

モニタだけなら簡単にできそうなきもするが、それだけではインサイトを抽出できない。こんなことをモニタして分析できればインサイトが得られるなと。

b0068870_1720865.png

by Takahiro_Komiya | 2015-08-11 17:33 | ファイバチャネル
Gen5(16GFC) FEC and TTS
IBM z13 と DS8870 では Brocade 製品を利用して Forward Error Correction ができるようになっている。さらに Transmitter Training Signal を使い、End-to-Endでの FEC に役立てている。

TTS は FEC を enable にしてもそれだけでは enable にならない。


switch:admin> portcfgfec --enable -TTS 5
Warning : FEC changes will be disruptive to the traffic
FEC TTS is supported only on F-port.
WARNING: Enabling TTS on E-port, EX-port and D-port will disable the port.
TTS has been enabled.

by Takahiro_Komiya | 2015-08-10 18:07 | ファイバチャネル
glassbeam と ThingWorx
Kumar Malavalli の会社(InMageの次)はこちら

でもって ThingWorx との話はこちら



#2015/8/13
HDS が OEM 契約していたのか!
by Takahiro_Komiya | 2015-08-10 17:07 | その他 technology
SDS 2.0 の定義 by ioFabric
ioFabricというスタートアップがある。彼らいわく、SDS2.0 は QoS がひとつのキーワードであるといっている。個人的にはQoSというキーワードは微妙であるが、言っていることは似ている。


SDS 2.0 takes the next step by eliminating the volume/LUN construct and turning storage allocation into a simple assignment of available capacity, performance and data protection capabilities.


ITL Nexus + LBA という構造と filesystem という構造と、ファイル/メモリの間にいろいろなレガシーがある。ここを独自に書き換えてしまえば自由を得られる。あとはエコシステムをどう構築するかがポイント。


そういやPdはどうしているのだろう(Paradiumじゃないよ)。
by Takahiro_Komiya | 2015-08-07 09:53 | その他 technology
SDN 2.0/SDS 2.0 到来の予感
最近、いくつかの資料を作ったりしていて思うのだが、SDN/SDS には 1.0, 2.0 の generation があるように思う。

SDN でいうと OpenFlow1.0の頃は SDN 0.x で、overlayとかSD-WANが 1.0 だ。この時代の主役は network service planning/network administratorである。同じようにSDSだと、過去のStorage Virtualizationとか今の世代の Object store なども含めて storage administrator の話だ(日本だと微妙)。

SDN 2.0, SDS 2.0 時代はどうなるかというと、もっとアプリケーション担当が主導することになるだろう。例えば、アプリケーション開発の際のSQA担当は様々なテストケースをSDNを使って書くだろうし、APIを使ってデータをメモリに書いたらそれがパーシステントになっている。QoSも含めて制御可能だ、アプリケーション開発者が。

#QoSといった時にそれが誰の提供するサービスなのかは重要。アプリケーション開発者が制御できないものもある

OpenFlow1.0の頃にDC事業者コントローラ、WAN事業者コントローラ、ユーザコントローラが使われるとよくいったものだが、ストレージも含めてこっちのほうに動いていていく力を感じている。

そろそろ仮想インタフェースとか論理ボリュームから発想を切り替える必要が出てきそうな予感。
by Takahiro_Komiya | 2015-08-06 13:35 | その他 technology
Best Practices and Pitfalls for Building Products out of OpenDaylight
ODL summit での弊社 Colin Dixon, Devin Avery による発表

これは弊社での ODL の製品化における知見です。
by Takahiro_Komiya | 2015-08-05 16:47 | IP networking