More Related Content Similar to “見てわかる”ファイバーチャネルSAN基礎講座(第6弾: 最終回)~困った時もこれで安心(?)、FC SANにおけるトラブルシューティングのコツとは??~ (20) “見てわかる”ファイバーチャネルSAN基礎講座(第6弾: 最終回)~困った時もこれで安心(?)、FC SANにおけるトラブルシューティングのコツとは??~3. 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/Ja
panese
• そんななかのWEBセミナーです!
3
4. 講師のご紹介
最終回なので改めて。
• 辻 哲也 (つじ てつや)
• 2002年 ブロケード入社
‒ ブロケード日本法人では「古株」です。
‒ 最近はバックエンドの支援業務が中心です
が、昔はいろいろとマーケティング活動も
やってました。
• ブログ連載してますので、よろしければ
アクセスしてみてください。
‒ http://community.brocade.com/t5/Brocade
-Japan/bg-p/Brocade-Japan
4
(@ITさんより)
5. “見てわかる” ファイバーチャネルSAN基礎講座
シリーズ構成
• 第1弾: 「検討」編
‒ まず理解しよう! 基本の “キ”
• 第2弾: 「設計」編
‒ FC SAN設計における勘所とは?
• 第3弾: 「導入」編
‒ 間違わない! FC SAN導入のヒントとコツ
• 第4弾: 「導入」編 (その2)
‒ 続・間違わない! FC SAN導入のヒントとコツ
• 第5弾: 「運用」編
‒ さあ、いよいよ、運用です!
• 第6弾 (最終回): 「トラブルシューティング」編
‒ 困った時もこれで安心 (?)、FC SANにおけるトラブルシューティングの
コツとは? 5
6. 本日のテーマ
• テーマ
‒ FC SAN導入を決定した”あるIT管理者の物語”
‒ FC SANを実際に導入する手順を、具体的に解説
• セミナーの目的・主旨
‒ FC SANインフラのトラブルシューティングに関する具体的な手法・手順を
紹介
‒ FCスイッチを中心とした、SANインフラにおける障害解析の手順を、実際
の機器を用いて紹介
• 技術解説とデモンストレーションがメインです。
6
7. “登場人物”のご紹介 (おさらい)
• 出得多 千太 (でえた せんた)
‒ とある製造業のIT部門で勤務する、中堅のITインフラ管理者
• 将来のビジネスを支えるIT基盤の選定から構築・運用までを任される見込み
• ストレージ・インフラの更改プロジェクトを担当
• いろいろな技術を検討した上で、FC SANベースのオール・フラッシュストレージを
選択
‒ 新人時代にはデータセンター内のストレージ・インフラの運用を担当
• 「データセンター内でのみ生きることができる」という謎の人物 (?)と出会う
7
8. デモ構成
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
9. FC SANにおける「障害」とは?
• ホストからストレージへアクセスできない (=「見えない」)
‒ FC SANにおける接続性障害
‒ ホスト-ストレージ間の経路を確認
• HBA
• SFP
• 光ファイバーケーブル/パッチパネル
• FCスイッチ
‒ サーバー/FCスイッチ/ストレージの設定に起因する問題
• 本講座の第3弾-第5弾を参照
• ホストからストレージへのアクセスが遅い
‒ FC SANにおけるパフォーマンス問題 9
???
10. トラブルシューティングの基本
プロセスとアプローチの方法
• 問題解決のためのプロセス
• 問題の定義 (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
11. SANスイッチ = ネットワーク監視の「窓」
“第1弾: 「検討」編”参照
• DAS (Direct Attached Storage)
‒ ネットワーク (SCSI/ファイバケーブル)で障害、パフォーマンスを確認できない
• SAN環境
‒ ネットワーク (=ファブリック/スイッチ)から障害、パフォーマンスを確認可能
11
SCSI/ファイバケーブル
??
SAN
13. • スイッチ-スイッチ間でファブリック接続が確立されていない
‒ FCスイッチでファブリックが分離 = “セグメンテーション”
• ファブリックがセグメンテーション状態になっていると、各スイッチに接続されたデバイス間
では通信ができない
• ファブリックの分離が起こる原因
‒ スイッチのドメインIDが重複
‒ スイッチ内で設定/有効化されているゾーン情報が不整合
‒ ファブリック・パラメータがスイッチ間で不一致
ホストからストレージへアクセスできない
ISL接続に関する問題
13
2台のスイッチが1つのファブリックを構成
→ ホストからストレージへアクセス可能
ファブリックが分離
→ ホストからストレージへアクセス不可
14. 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)との間で正常に初期化が完了
15. 実は簡単な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
ケーブルを
つなぐだけ!
ファブリックに
ログイン!
16. 実は簡単な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プ
ロトコル)を多少なりとも
知っておくことが必要!
20. 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ビット)
23. ホストからストレージへのアクセスが遅い
FC SANにおけるパフォーマンス問題
• パフォーマンス問題が発生する要因
‒ トラフィックの輻輳 (Congestion)
• 許容されている以上のトラフィックが、デバイスポートおよびISLポートに流入
‒ リンク障害
• 物理層レベルのリンク障害に伴う、フレーム破棄やデータ再送
• porterrshowコマンド (後述)でエラー発生状況を確認
‒ デバイス・ネットワークレベルでの遅延 (レイテンシ)
• “クレジット” (次頁参照)の不足あるいは枯渇
‒ ファイバーチャネル・プロトコルにおけるフロー制御の仕組み
• スロー・ドレイン・デバイス (Slow Drain Device: SDD)に起因
‒ Queue Depth
• デバイスが同時に処理可能なI/O数: デバイスの設定に依存
• 設定値が大きすぎても、小さすぎてもパフォーマンスに影響
23
24. ファイバーチャネルのフロー制御
• “クレジット”ベース
‒ 受信ポートのバッファを監視するメカニズム: Buffer-to-Buffer (BB)クレジット
‒ ポート初期化時 (FLOGI)に互いのクレジット情報を交換 (ノードースイッチ間)
‒ 送信ポートは受信ポートのバッファ空き容量を知っている = 常に利用可能な最大の速度で
通信を行うことが可能
• ストレージI/Oに適した仕様
受信ポート送信ポート
クレジット 2
↓
送信フレーム 受信バッファ
クレジット 1
↓
送信フレーム 受信バッファ
クレジット 0
↓
クレジット 1
↓
クレジット 2
↓
送信フレーム
クレジット 1
受信バッファ
空になった
受信バッファ
クレジットが0になる
までフレームを送信
クレジットが0のと
きは自律的に送信を
中断
受信ポートから応答
(VC_RDY,R_RDY)を
受け取るとクレジッ
トカウントを増やし、
送信再開
24
25. スイッチ間フロー制御
仮想チャネル (Virtual Channel: VC)
• Brocade FCスイッチのISLでは「仮想
チャネル (Virtual Channel)」という”論理
的な”経路を使用してデータを送受信
‒ 宛先デバイス毎に使用する仮想チャネルを
分散
• 仮想チャネル単位でのフロー制御
‒ VC_RDY Ordered Setを使用
• QoS設定によって、仮想チャネル構成に
違い
‒ トラフィック種別毎に使用する仮想チャネ
ルを分離
25
26. “スロー・ドレイン・デバイス”とは?
Slow Drain Device (SDD)
• SAN全体のパフォーマンスを低下させる原因となるデバイス
‒ 「期待される時間内に応答できない」デバイス
• デバイスに対する過負荷あるいは性能の不足、デバイスの異常
• SDDがネットワーク上に存在すると、仮想チャネル (Virtual Channel:VC)に割り
当てられたBBクレジットが枯渇
→ デバイス本来のパフォーマンスが得られず、フレーム・ロストやI/Oエラーを
引き起こす可能性
‒ 送信できずにスイッチ内で一定時間滞留したフレームは、破棄 (discard)される
• ネットワークが以下のような構成の場合に発生する可能性
‒ スイッチ間接続 (ISL)を含む
‒ 低速なデバイス (1Gbps/2Gbps etc.)と高速なデバイスが混在
‒ 速度の異なるデバイスが同一のVCを使用 26
30. SDD問題発生のメカニズム (続き)
E_Port (スイッチ間接続) Virtual ChannelのBBクレジット枯渇
• 問題のあるデバイスにトラ
フィックを送信している
E_Portの仮想チャネルで、
BBクレジットが枯渇
• 使用されている仮想チャネル
で、トラフィックが流れなく
なる
30
4Gbps 1Gbps
2Gbps
8Gbps
ISL and 同VC
8Gbps
8Gbps
8Gbps
STOP ・・・BBクレジット (正常)
・・・BBクレジット (枯渇)
フレームロスト
可能性
33. 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
34. パフォーマンス問題回避の手法
• 輻輳発生時
‒ デバイス/スイッチのポートを、より広帯域に変更
• Gen5 (16Gbps)/Gen6 (32Gbps)
‒ ISLの帯域を追加
• Brocade FCスイッチの場合は、DLSやISL Trunking (第5弾: 「運用」編参照)により、
簡単に帯域の拡張が可能
‒ デバイスのファブリックへの接続ポートを追加
‒ トラフィックを種別毎に分離
• ISLを通過させずにサーバーとストレージを同じスイッチに収容 (「ローカリティ」)
• Traffic Isolation (TI) Zoneを使用
• 物理リンク異常時
‒ ケーブルあるいはSFPを交換
‒ ケーブルおよび清掃 (クリーニング) 34
35. パフォーマンス問題回避の手法 (続き)
• クレジット不足/枯渇時
‒ ポートにより多くのクレジットを割り当て
‒ SDDへの対処
• ローカリティを高めるSAN設計 (前頁参照)
• SDDの隔離機能 (SDD Quarantine: 後述)を使用
• 不適切なQueue Depth設定
‒ HBAのQueue Depth設定を変更
35
36. 障害時のデータ収集
• supportSaveコマンド
‒ ベンダーサポートが解析に必要な、さまざまな情報を取得するコマンド
• RASlog, トレース, supportShow, Coreファイル等を一つのコマンドで取得
‒ FTP/SCPサーバーに情報をアップロード
• 事前にFTP/SCPサーバー・アカウントを設定しておくことが可能 (supportftpコマンド)
• 各種テキスト/バイナリファイルが大量に生成される
‒ 一つのファイルにまとめてベンダーへ提出
‒ コマンド実行結果も出力される (*.txt.gzで保存)
• Brocade Network Advisor (BNA)から取得することも可能
‒ 複数のスイッチから同時にデータを収集
36
取得結果の一部
37. こんな技術や製品もあります!
少しだけ「宣伝」です
• 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. 総括
38
• FC SANで”障害”に直面した千太くん
• FC SANの導入・運用自体は難しくないが、トラブルシューティングに際
してはファイバーチャネル・プロトコルの理解が必要であることを痛感
‒ ブロケード社からも、技術資料 (日本語もあり: 後述)を提供
• ただ基本さえ抑えれば、FC SANの障害パターンはそれほど多くはない
‒ 大別すれば、「アクセスできない」or「アクセスが遅い」
• 今後の運用およびシステム拡張に向けて、千太くんはさらにFC技術や製品
を勉強中!
‒ FCプロトコル
‒ Fabric Vision, AMP etc.
!!!
40. 参考資料 (日本語)のご紹介 (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-59702212
40