ブロケード WEBセミナーシリーズ第9回

“見てわかる”ファイバーチャネルSAN基礎講座(第6弾: 最終回)～困った時もこれで安心 (?)、FC SANにおけるトラブルシューティングのコツとは? ～

本日のWEBセミナーの注意点とお願い

• 【質問】タブで随時質問を受け付けます。

‒【質問】タブへの記載は、講師のみが閲覧できます

‒質問内容は、講師が読み上げさせていただきます

• セミナー終了後、アンケート画面に遷移します。ぜひご協力お願いします！※メールアドレス記載の上、ご回答いただいた方の中から抽選でブロケードロゴグッズプレゼント！

2

Brocade WEBセミナーシリーズ• 最近、いろいろ情報発信しています

‒ Twitter: https://twitter.com/brocadejapan

‒ Facebook: https://www.facebook.com/brocadejapan/

‒ Brocade Japan Blog: http://community.brocade.com/t5/Brocade-Japan/bg-p/Brocade-Japan

‒ YouTube:https://www.youtube.com/user/brocadejapan

‒ SlideShare: http://www.slideshare.net/brocade/tagged/Japanese

• そんななかのWEBセミナーです！3

講師のご紹介最終回なので改めて。

• 辻 哲也 (つじ てつや)

• 2002年 ブロケード入社

‒ブロケード日本法人では「古株」です。

‒最近はバックエンドの支援業務が中心ですが、昔はいろいろとマーケティング活動もやってました。

• ブログ連載してますので、よろしければアクセスしてみてください。

‒ http://community.brocade.com/t5/Brocade-Japan/bg-p/Brocade-Japan

4

(@ITさんより)

“見てわかる”ファイバーチャネルSAN基礎講座シリーズ構成

• 第1弾: 「検討」編

‒ まず理解しよう！基本の “キ”

• 第2弾: 「設計」編

‒ FC SAN設計における勘所とは?

• 第3弾: 「導入」編

‒ 間違わない！ FC SAN導入のヒントとコツ

• 第4弾: 「導入」編 (その2)

‒ 続・間違わない！ FC SAN導入のヒントとコツ

• 第5弾: 「運用」編

‒ さあ、いよいよ、運用です！

• 第6弾 (最終回): 「トラブルシューティング」編

‒困った時もこれで安心 (?)、FC SANにおけるトラブルシューティングのコツとは? 5

本日のテーマ

• テーマ

‒ FC SAN導入を決定した”あるIT管理者の物語”

‒ FC SANを実際に導入する手順を、具体的に解説

• セミナーの目的・主旨

‒ FC SANインフラのトラブルシューティングに関する具体的な手法・手順を紹介

‒ FCスイッチを中心とした、SANインフラにおける障害解析の手順を、実際の機器を用いて紹介

• 技術解説とデモンストレーションがメインです。

6

“登場人物”のご紹介 (おさらい)

• 出得多 千太 (でえた せんた)

‒とある製造業のIT部門で勤務する、中堅のITインフラ管理者

• 将来のビジネスを支えるIT基盤の選定から構築・運用までを任される見込み

• ストレージ・インフラの更改プロジェクトを担当

• いろいろな技術を検討した上で、FC SANベースのオール・フラッシュストレージを選択

‒新人時代にはデータセンター内のストレージ・インフラの運用を担当

• 「データセンター内でのみ生きることができる」という謎の人物 (?)と出会う

7

デモ構成

8

Windows Server 2012

Fujitsu

ETERNUS DX500

16Gbps FC

16Gbps FC

16Gbps FC

Brocade 6510

(B6510-01)Brocade 6520

(B6520-01)

Qlogic BR-1860 Fabric Adapter

ポート#0 ポート#8

ポート#0

ポート#8

CM#1/CA#0/Port#0

LU: 200GB

FC SANにおける「障害」とは?

• ホストからストレージへアクセスできない (=「見えない」)

‒ FC SANにおける接続性障害

‒ホスト-ストレージ間の経路を確認

• HBA

• SFP

• 光ファイバーケーブル/パッチパネル

• FCスイッチ

‒サーバー/FCスイッチ/ストレージの設定に起因する問題

• 本講座の第3弾-第5弾を参照

• ホストからストレージへのアクセスが遅い

‒ FC SANにおけるパフォーマンス問題9

？？？

トラブルシューティングの基本プロセスとアプローチの方法

• 問題解決のためのプロセス

• 問題の定義 (Define the Problem)

• データ収集 (Gather Data)

• データ解析 (Analyze Data)

• 原因の特定 (Identify the Cause)

• “LLFD”: End-to-Endの通信確立ステップ

1. Link: デバイス/スイッチ間の物理および論理的なコネクション

• 光信号の送受信、スピード・ネゴシエーション、対向ポート間での同期確立

2. Login：デバイス-スイッチ間での接続確立 (=ログイン)

• ファブリック・ログイン (FLOGI)、N_Portログイン (PLOGI)

3. Fabric：ファブリックからの情報取得 (デバイス)

• ネームサーバーへのクエリー

4. Device：デバイス間での接続確立

• PLOGI (ホスト-ストレージ間)、プロセス・ログイン (PRLI) 10

SANスイッチ = ネットワーク監視の「窓」“第1弾: 「検討」編”参照

• DAS (Direct Attached Storage)

‒ ネットワーク (SCSI/ファイバケーブル)で障害、パフォーマンスを確認できない

• SAN環境

‒ ネットワーク (=ファブリック/スイッチ)から障害、パフォーマンスを確認可能

11

SCSI/ファイバケーブル

??

SAN

ホストからストレージへアクセスできないデバイス接続に関する問題

• スイッチ-デバイス (ホスト/ストレージ間)で接続が確立されていない

‒ SFP/ケーブルをチェック

• 注) Brocade FCスイッチの場合、Brocade製SFPのみ使用可能

‒スイッチのポート設定を確認

‒デバイスのポート設定を確認

• ホストからストレージが「見えない」ように設定されている

‒ FCスイッチでのゾーニング

‒ストレージでのLUNマスキング

‒第4弾: 「導入」編 (その2)参照

• リンク障害

‒コンポーネントの不良: 光ファイバーケーブル、SFP12

• スイッチ-スイッチ間でファブリック接続が確立されていない

‒ FCスイッチでファブリックが分離 = “セグメンテーション”

• ファブリックがセグメンテーション状態になっていると、各スイッチに接続されたデバイス間では通信ができない

• ファブリックの分離が起こる原因

‒ スイッチのドメインIDが重複

‒ スイッチ内で設定/有効化されているゾーン情報が不整合

‒ ファブリック・パラメータがスイッチ間で不一致

ホストからストレージへアクセスできないISL接続に関する問題

13

2台のスイッチが1つのファブリックを構成

→ホストからストレージへアクセス可能

ファブリックが分離

→ホストからストレージへアクセス不可

Index Port Address Media Speed State Proto

==================================================

0 0 010000 id N16 Online FC F-Port 10:00:8c:7c:ff:07:f9:01

1 1 010100 -- N16 No_Module FC

2 2 010200 -- N16 No_Module FC

3 3 010300 -- N16 No_Module FC

4 4 010400 -- N16 No_Module FC

5 5 010500 -- N16 No_Module FC

6 6 010600 id N16 No_Light FC

7 7 010700 id N16 No_Light FC

8 8 010800 id N16 Online FC E-Port 10:00:50:eb:1a:99:02:20 "B6520-01"

(upstream)(Trunk master)

9 9 010900 id 2G Mod_Inv FC "Speed Mismatch / Incompatible SFP"

ポートの状態確認例switchshowコマンド (抜粋)

14

ポートの状態が”F-Port” (Online)

= デバイス (N-Port)との間で正常に初期化が完了

ポートの状態が”Mod_Inv” (Invalid Module)

= 挿入されているSFPとポート設定が合っていないリンク速度を2Gbpsに固定

ポートの状態が”E-Port” (Online)

= スイッチ (E-Port)との間で正常に初期化が完了

実は簡単なFC SAN“第1弾: 「検討」編”参照

• 「プラグ・アンド・プレイ」での構成

‒ 「ケーブルをつなぐだけ」で、以下の全ての手続きを”自動的に”実行して構成

• ノード (N_Port) - スイッチ (F_Port)間接続

‒ デバイスのファブリックへの参加: スイッチがFCアドレスを付与

‒ デバイスがファブリックに情報を登録 (ネームサーバー)

‒ ファブリックを通じて、通信したいデバイスを認識

‒ 設定したアクセス制御リスト (=ゾーン)に基づいて、デバイス間通信をフィルタリング

• スイッチ (E_Port) – スイッチ (E_Port)間接続

‒ スイッチ間で識別番号 (ドメインID)の重複の有無を確認

‒ ファブリックにおける“プリンシパル”スイッチの決定

‒ 経路情報の交換・決定 (FSPF: Fabric Shortest Path First)

‒ アクセス制御情報 (=ゾーン情報)を交換、統合15

FCスイッチ

FCスイッチ

“ファブリック”を

自動形成！

E_Port

E_Port

N_Port

F_Port

サーバー/HBA

ケーブルを

つなぐだけ！

ファブリックに

ログイン！

実は簡単なFC SAN“第1弾: 「検討」編”参照

• 「プラグ・アンド・プレイ」での構成

‒ 「ケーブルをつなぐだけ」で、以下の全ての手続きを”自動的に”実行して構成

• ノード (N_Port) - スイッチ (F_Port)間接続

‒ デバイスのファブリックへの参加: スイッチがFCアドレスを付与

‒ デバイスがファブリックに情報を登録 (ネームサーバー)

‒ ファブリックを通じて、通信したいデバイスを認識

‒ 設定したアクセス制御リスト (=ゾーン)に基づいて、デバイス間通信をフィルタリング

• スイッチ (E_Port) – スイッチ (E_Port)間接続

‒ スイッチ間で識別番号 (ドメインID)の重複の有無を確認

‒ ファブリックにおける“プリンシパル”スイッチの決定

‒ 経路情報の交換・決定 (FSPF: Fabric Shortest Path First)

‒ アクセス制御情報 (=ゾーン情報)を交換、統合16

FCスイッチ

FCスイッチ

“ファブリック”を

自動形成！

E_Port

E_Port

N_Port

F_Port

サーバー/HBA

ケーブルを

つなぐだけ！

ファブリックに

ログイン！

トラブルシューティングにおいては、動作の仕組み (FCプロトコル)を多少なりとも知っておくことが必要！

ファブリック・ログイン通信

17

1) ログインサーバーへのログイン処理は、Windowsドメイン等へのログイン処理に該当

2) ネームサーバーへのログイン処理は、DNSサーバへ名前解決のための登録を行う処理に該当

• ネットワークへのログイン (Fabric Login: FLOGI)

• ネームサーバーへの登録 (Port Login: PLOGI)

• 通信する許可を得る (Port Login: PLOGI)

ファブリック

ネームサーバー

(x‘FFFFFC’)

ログインサーバー

(x‘FFFFFE’)サーバ ストレージ

スイッチのポート番号3番に接続

ドメインID = 9

スイッチのポート番号1番に接続

FCアドレス090300配布

サーバ： 090300

ストレージ： 090100

⑪PLOGI (接続要求)

⑫Accept (接続許可)

ストレージのFCアドレスは「090100」！

拡張リンクサービス

FCアドレス090100配布

17

N_Port N_Port

F_Port F_Port

通信確立のフローFCスイッチの起動からデバイス間での通信確立まで

18

POST-

PowerOn

Test

光シグナル

同期信号

リンク初期化

FLOGI

PLOGI

NS 登録

ゾ

|ニング

セキュリティ

ACL

スイッチ電源投入

N_Port同士の通信手順

デバイスがNSに追加

デバイスがリモート

NSに追加

スイッチ上の動作 End-to-Endの動作

Link Login

NS クエリ

|

Fabric Device※

NS: ネームサーバー (Name Server)

ACL: Access Control List

速度ネゴシエ

|ション

ネームサーバーの表示nsshow/nsallshow/nscamshowコマンド

• nsShowコマンド

‒コマンドを発行したFC-Switchに接続しているデバイスの情報を表示

• nsAllShowコマンド

‒相互接続されている全FC-Switchに接続している全デバイスのFCアドレスのみを表示

• nscamShowコマンド

‒ネームサーバー・キャッシュの情報を表示

‒同一ファブリック内の他のFCスイッチに接続しているデバイスの情報を表示

19

nsshowコマンド出力例

20

B6510-01:FID128:admin> nsshow

{

Type Pid COS PortName NodeName TTL(sec)

N 010000; 3;10:00:8c:7c:ff:07:f9:01;20:00:8c:7c:ff:07:f9:01; na

FC4s: FCP

PortSymb: [75] "QLogic-1860-2p | 3.2.6.0 | HP-SERVER | Windows Server 2012 Datacenter | N/A"

NodeSymb: [39] "QLogic-1860-2p | 3.2.6.0 | HP-SERVER | "

Fabric Port Name: 20:00:00:05:33:7a:0d:38

Permanent Port Name: 10:00:8c:7c:ff:07:f9:01

Port Index: 0

Share Area: No

Device Shared in Other AD: No

Redirect: No

Partial: No

LSAN: No

Device link speed: 16G

The Local Name Server has 1 entry }

Pid (Port ID) = FCアドレス (24ビット)

- FCファブリック (スイッチ)から割り当て PortName = Port World Wide Name (WWN)

- デバイスポートの識別子 (64ビット)

スイッチ間接続 (E_Port) 初期化プロセスファブリック・コンフィグレーションプロセス

21

Ste

p 1

:

リンク初期化

ファブリック初期化

Ste

p 2

:

ポート操作モード(E

_P

ort)

検出

Ste

p 3

:

プリンシパルスイッチ選択

Ste

p 4

:

ドメインアドレス配布

Ste

p 5

:

経路選択(F

SP

Fアルゴリズム)

ファブリック動作可能

Class F通信(スイッチ・ファブリック内部リンクサービス)

設定ミスの一例ゾーニング設定の誤り (WWNゾーニング)

22

Host: WWN_a

Host: WWN_b

[ファブリックでのゾーン設定]

cfg: cfg_test

zone_OK

zone: zone_OK

WWN_a; WWN_b結果: ホストからストレージが認識可能

cfg: cfg_test

zone_NG

zone: zone_NG

WWN_a’; WWN_b結果: ホストからストレージが認識不可

ホストからストレージへのアクセスが遅いFC SANにおけるパフォーマンス問題

• パフォーマンス問題が発生する要因

‒ トラフィックの輻輳 (Congestion)

• 許容されている以上のトラフィックが、デバイスポートおよびISLポートに流入

‒ リンク障害

• 物理層レベルのリンク障害に伴う、フレーム破棄やデータ再送

• porterrshowコマンド (後述)でエラー発生状況を確認

‒ デバイス・ネットワークレベルでの遅延 (レイテンシ)

• “クレジット” (次頁参照)の不足あるいは枯渇

‒ ファイバーチャネル・プロトコルにおけるフロー制御の仕組み

• スロー・ドレイン・デバイス (Slow Drain Device: SDD)に起因

‒ Queue Depth

• デバイスが同時に処理可能なI/O数: デバイスの設定に依存

• 設定値が大きすぎても、小さすぎてもパフォーマンスに影響23

ファイバーチャネルのフロー制御• “クレジット”ベース

‒ 受信ポートのバッファを監視するメカニズム: Buffer-to-Buffer (BB)クレジット

‒ ポート初期化時 (FLOGI)に互いのクレジット情報を交換 (ノードースイッチ間)

‒ 送信ポートは受信ポートのバッファ空き容量を知っている = 常に利用可能な最大の速度で通信を行うことが可能

• ストレージI/Oに適した仕様

受信ポート送信ポート

クレジット 2

↓

送信フレーム 受信バッファ

クレジット 1

↓

送信フレーム 受信バッファ

クレジット 0

↓

クレジット 1

↓

クレジット 2

↓

送信フレーム

クレジット 1

受信バッファ

空になった

受信バッファ

クレジットが0になるまでフレームを送信

クレジットが0のときは自律的に送信を中断

受信ポートから応答(VC_RDY,R_RDY)を受け取るとクレジットカウントを増やし、送信再開

24

スイッチ間フロー制御仮想チャネル (Virtual Channel: VC)

• Brocade FCスイッチのISLでは「仮想チャネル (Virtual Channel)」という”論理的な”経路を使用してデータを送受信

‒宛先デバイス毎に使用する仮想チャネルを分散

• 仮想チャネル単位でのフロー制御

‒ VC_RDY Ordered Setを使用

• QoS設定によって、仮想チャネル構成に違い

‒トラフィック種別毎に使用する仮想チャネルを分離

25

“スロー・ドレイン・デバイス”とは?Slow Drain Device (SDD)

• SAN全体のパフォーマンスを低下させる原因となるデバイス

‒ 「期待される時間内に応答できない」デバイス

• デバイスに対する過負荷あるいは性能の不足、デバイスの異常

• SDDがネットワーク上に存在すると、仮想チャネル (Virtual Channel:VC)に割り当てられたBBクレジットが枯渇

→デバイス本来のパフォーマンスが得られず、フレーム・ロストやI/Oエラーを引き起こす可能性

‒ 送信できずにスイッチ内で一定時間滞留したフレームは、破棄 (discard)される

• ネットワークが以下のような構成の場合に発生する可能性

‒ スイッチ間接続 (ISL)を含む

‒ 低速なデバイス (1Gbps/2Gbps etc.)と高速なデバイスが混在

‒ 速度の異なるデバイスが同一のVCを使用26

SDD問題発生のメカニズム通常時

• 3台のホストが、3台のストレージ・デバイスにI/O

‒ ISLはボトルネックではない

274Gbps 1Gbps

2Gbps

8GbpsISL and 同VC

8Gbps

8Gbps

8Gbps

・・・BBクレジット (正常)

SDD問題発生のメカニズム (続き)デバイスボトルネックが発生

• 1Gbpsのデバイスでボトルネックあるいは障害が発生し、BBクレジットが枯渇

‒この時点では、まだ当該デバイスだけの問題

28

4Gbps 1Gbps

2Gbps

8GbpsISL and 同VC

8Gbps

8Gbps

8Gbps

・・・BBクレジット (正常)

・・・BBクレジット (枯渇)

SDD問題発生のメカニズム (続き)F_Port (デバイス接続側)でのBBクレジットの枯渇

• デバイスが接続されているスイッチのポート (F_Port)のBBクレジットが枯渇

‒この時点でも、まだ他のデバイスには影響していない

29

4Gbps 1Gbps

2Gbps

8GbpsISL and 同VC

8Gbps

8Gbps

8Gbps

STOP ・・・BBクレジット (正常)

・・・BBクレジット (枯渇)

SDD問題発生のメカニズム (続き)E_Port (スイッチ間接続) Virtual ChannelのBBクレジット枯渇

• 問題のあるデバイスにトラフィックを送信しているE_Portの仮想チャネルで、BBクレジットが枯渇

• 使用されている仮想チャネルで、トラフィックが流れなくなる

30

4Gbps 1Gbps

2Gbps

8GbpsISL and 同VC

8Gbps

8Gbps

8Gbps

STOP ・・・BBクレジット (正常)

・・・BBクレジット (枯渇)

フレームロスト可能性

SDD問題発生のメカニズム (続き)E_Port内Virtual ChannelのBBクレジットの枯渇

• 対向側スイッチのE_Portで、仮想チャネルのBBクレジットが枯渇

31

4Gbps 1Gbps

2Gbps

8GbpsISL and 同VC

8Gbps

8Gbps

8Gbps

STOP

STOP

・・・BBクレジット (正常)

・・・BBクレジット (枯渇)

フレームロスト可能性あり

SDD問題発生のメカニズム (続き)スイッチポートのBBクレジット枯渇

• ISLを共有し、かつ同じ仮想チャネルを使用するホストが接続されているすべてのスイッチポートで、BBクレジットが枯渇

• 本来は輻輳あるいは障害に無関係なホスト/ストレージにも影響

32

4Gbps 1Gbps

2Gbps

8GbpsISL and 同VC

8Gbps

8Gbps

8Gbps

STOP

STOP

STOP

STOPSTOP

・・・BBクレジット (正常)

・・・BBクレジット (枯渇)

フレームロスト可能性あり

portErrShowコマンド各ポートの信号レベルのエラーを確認

• 各ポートのエラーの「積算」総数を表示

‒ エラーの増加傾向を調査

• 障害調査時にstatsClearコマンドで一度値をクリアして、エラーの増分を確認

‒ 主な項目• frames tx/rx: 転送/受信したフレーム数• crc_err: CRCエラーのフレーム数

‒ このカウンターが上昇する場合、物理層 (ケーブル、パッチパネル、SFP)の異常の可能性

• enc_out: フレーム外で発生したエラー (通常はプリミティブの問題)• disc_c3 (discarded class 3): スイッチでの保持時間を過ぎ、破棄されたフレーム数

33

porterrshow:

frames enc crc too too bad enc disc link loss loss frjt fbsy

tx rx in err shrt long eof out c3 fail sync sig

=====================================================================

0: 464k 968k 0 0 0 0 0 83 0 21 14 0 0 0

1: 626k 488k 0 0 0 0 0 101 1 27 13 0 0 0

2: 392k 75k 0 0 0 0 0 358 0 12 1 0 0 0

3: 909k 547k 0 0 0 0 0 5.0m 0 9 20 0 0 0

4: 83k 276k 0 0 0 0 0 19k 1 15 7.3k 1 0 0

5: 165k 324k 0 0 0 0 0 66 2 9 0 0 0 0

6: 0 0 0 0 0 0 0 0 0 6 0 1 0 0

パフォーマンス問題回避の手法• 輻輳発生時

‒デバイス/スイッチのポートを、より広帯域に変更

• Gen5 (16Gbps)/Gen6 (32Gbps)

‒ ISLの帯域を追加

• Brocade FCスイッチの場合は、DLSやISL Trunking (第5弾: 「運用」編参照)により、簡単に帯域の拡張が可能

‒デバイスのファブリックへの接続ポートを追加

‒トラフィックを種別毎に分離

• ISLを通過させずにサーバーとストレージを同じスイッチに収容 (「ローカリティ」)

• Traffic Isolation (TI) Zoneを使用

• 物理リンク異常時

‒ケーブルあるいはSFPを交換

‒ケーブルおよび清掃 (クリーニング)34

パフォーマンス問題回避の手法 (続き)

• クレジット不足/枯渇時

‒ポートにより多くのクレジットを割り当て

‒ SDDへの対処

• ローカリティを高めるSAN設計 (前頁参照)

• SDDの隔離機能 (SDD Quarantine: 後述)を使用

• 不適切なQueue Depth設定

‒ HBAのQueue Depth設定を変更

35

障害時のデータ収集

• supportSaveコマンド

‒ ベンダーサポートが解析に必要な、さまざまな情報を取得するコマンド

• RASlog, トレース, supportShow, Coreファイル等を一つのコマンドで取得

‒ FTP/SCPサーバーに情報をアップロード

• 事前にFTP/SCPサーバー・アカウントを設定しておくことが可能 (supportftpコマンド)

• 各種テキスト/バイナリファイルが大量に生成される

‒ 一つのファイルにまとめてベンダーへ提出

‒ コマンド実行結果も出力される (*.txt.gzで保存)

• Brocade Network Advisor (BNA)から取得することも可能

‒ 複数のスイッチから同時にデータを収集

36

取得結果の一部

こんな技術や製品もあります！少しだけ「宣伝」です

• Brocade Fabric Vision

‒ エラー/パフォーマンス関連の閾値を設定し、異常発生時に通知

‒ SDDを検知して、該当デバイスを”隔離” (SDD Quarantine)

‒ スイッチ内でSCSI Read/Writeコマンドの遅延をモニタ (I/O Insight: Gen6製品)

• Brocade Analytics Monitoring Platform (AMP)

‒ スイッチで動作するFabric Visionと連携

‒ ファブリックレベルで、全てのSCSIコマンドの遅延をモニタ

‒ スイッチがミラー (vTAP)したトラフィックを解析

• Brocade Network Advisor (BNA)

‒ GUIでエラー、パフォーマンスを可視化

‒ Fabric VisionおよびAMPと連携37

Brocade Analytics Monitoring Platform (AMP)

総括

38

• FC SANで”障害”に直面した千太くん

• FC SANの導入・運用自体は難しくないが、トラブルシューティングに際してはファイバーチャネル・プロトコルの理解が必要であることを痛感

‒ブロケード社からも、技術資料 (日本語もあり: 後述)を提供

• ただ基本さえ抑えれば、FC SANの障害パターンはそれほど多くはない

‒大別すれば、「アクセスできない」or「アクセスが遅い」

• 今後の運用およびシステム拡張に向けて、千太くんはさらにFC技術や製品を勉強中！

‒ FCプロトコル

‒ Fabric Vision, AMP etc.

！！！

[おまけ] 千太くんの“その後”

• 千太くんが導入したFCストレージ・インフラは、その後も順調に拡大

• 管理職に昇進した千太くんは、培ったノウハウを後進に伝授

• 「データセンター内でのみ生きることができる」という謎の人物 (?)との再会を果たしたかも・・・

‒ “DCXマン”と呼ばれていました

39

参考資料 (日本語)のご紹介 (SlideShare)

• Fibre Channel基礎講座

http://www.slideshare.net/brocade/fibre-channe-l

• ブロケード FC ファブリックスイッチオペレーション講座（前編）

http://www.slideshare.net/brocade/fc-48362477

• ブロケード FC ファブリックスイッチオペレーション講座（後編）

http://www.slideshare.net/brocade/fc-48966234

• FCスイッチゾーニング設定ガイド

http://www.slideshare.net/brocade/fc-49314954

• FC SAN Fabric環境におけるパフォーマンストラブルの対処法http://www.slideshare.net/brocade/fc-san-fabric-70690348

• ここまできた！ ”第6世代”ファイバーチャネルがもたらす ストレージ・ネットワークの新たな可能性とは？

http://www.slideshare.net/brocade/6-5970221240

Q&A

Thank you

本件に関するお問合せ

http://www.brocade.com/ja/forms/contact-us.htmlブロケードコミュニケーションズシステムズ株式会社