“見てわかる” ファイバーチャネルSAN基礎講座（第1弾）～まず理解しよう！基本の “キ”～

ブロケード WEBセミナーシリーズ第4回
“見てわかる” ファイバーチャネルSAN基礎講座
(第1弾)
～まず理解しよう！基本の “キ”～

本日の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/Ja
panese
• そんななかのWEBセミナーです！
3

講師のご紹介
• 辻哲也つじてつや
• 2002年ブロケード入社
‒ ブロケード日本法人では「古株」です。
‒ 最近はバックエンドの支援業務が中心です
が、昔はいろいろとマーケティング活動も
やってました。
• ブログ連載してますので、よろしければ
アクセスしてみてください。
‒ http://community.brocade.com/t5/Brocad
e-Japan/bg-p/Brocade-Japan
4
(@ITさんより)

“見てわかる” ファイバーチャネルSAN基礎講座
シリーズ構成 (案)
• 第1弾 (今回): 「検討」編
‒ まず理解しよう！基本の “キ”～
• 第2弾: 「設計」編
• 第3弾: 「導入」編
• 第4弾: 「運用」編
※上記は変更される可能性もありますので、あらかじめご了承ください。。。
5

本日のテーマ
• テーマ
‒ FC SANを導入する「前」の話
‒ ストレージ・インフラの選定に悩みぬいた、”あるIT管理者の物語”
• セミナーの目的・主旨
‒ “これからの”ストレージ・インフラを検討する上での参考材料をご提供。
‒ Brocadeのセミナーなので、やっぱり「FC SANの良さ」を訴求します！
‒ 今日のセミナーでは、デモはありません。
• 次回以降 (おそらく第3弾くらいから)、デモを行うつもりです。
6

“登場人物”のご紹介
• 出得多千太 (でえたせんた)
‒ とある製造業のIT部門で勤務する、中堅のITインフラ管理者
• 将来のビジネスを支えるIT基盤の選定から構築・運用までを任される見込み
• ストレージ・インフラの更改プロジェクトを担当
‒ 新人時代にはデータセンター内のストレージ・インフラの運用を担当
• 「データセンター内でのみ生きることができる」という謎の人物 (?)と出会う
7

千太くんの悩み
• 「仮想化」環境でのストレージ・イ
ンフラはどうすればいい?
‒ サーバーは仮想化 (ハイパーバイザー)
‒ クライアントも仮想化 (仮想デスク
トップ: VDI)
‒ 自社でプライベート・クラウド環境を
構築 (?)
8

データ・ストレージの選択肢
ITの技術革新に伴い、選択肢が多様化 (2016年時点)
• ブロック・アクセスのストレージ
‒ HDD、フラッシュ、ハイブリッド etc.
• ファイル・アクセス
‒ NAS (スケールアウト型)
• 分散ファイルシステムを使用したSDS (Software Defined Storage)
‒ ハイパー・コンバージド・インフラストラクチャ (HCI)
• Nutanix, VMware Virtual SAN (VSAN) etc.
• クラウド・ストレージ
‒ AWS, Azure, Google, Box etc.
9
HCI?SDS?
フラッシュ?
AWS?

ストレージ・インフラの要件
“とある製造業”の場合
• 「データ = 企業ノウハウ」の塊
‒ 設計情報や顧客情報の消失や流出は、絶対に避けたい。
‒ “ストレージ (=データ)アクセス”のためのネットワークには、高いパフォーマ
ンスと信頼性が欲しい。
• データの増加量は予測不可能
‒ 無尽蔵 (?)に増え続けるデータを、効率よく管理できるインフラが必須。
• 運用・保守の負荷を最小化
‒ 「より少人数の管理者」で「より大規模」なインフラを管理したい。
‒ ネットワークに関わるオペレーションは、出来る限り自動化したい。
10

ストレージ・インフラの要件 (続き)
“とある製造業”の場合
• 技術の変化は予測不可能
‒ 今後登場する新技術にも、柔軟に対応できるインフラが望ましい。
• インフラ投資の「見える化」
‒ インフラに関わるさまざまなデータを可視化し、投資効率を最大化したい。
‒ 投資計画の判断材料となる情報を取得したい。
‒ 初期コストだけではなく、運用コストも含めたコスト総額を抑えたい。
11

結局、千太くんが選んだのは・・・
12

結局、千太くんが選んだのは・・・
13
FC SAN (スイッチ)とオール・
フラッシュ・ストレージをベース
にした、ストレージインフラ

千太くんはなぜ、FC SANとフラッシュ・
ストレージを選んだのか？
14

1. なぜファイバーチャネル？
15

「クラウドからオンプレミス」への動き
• 世の中の流れ (主流)は、「オンプレミスからクラウド」
• 一部には「クラウドからオンプレミス」への動きも・・・
‒ 大規模になってくると、クラウドはコスト面でデメリットも。
‒ 大規模になってくると、クラウドは管理面でデメリットも。
16

サーバー仮想化環境でのパフォーマンス
高パフォーマンスを求めるならFC (VMmarkベンチマークより)
17
VMmarkのトップ20の
構成は、すべてファイバ
チャネル (FC)を使用
Source: VMware VMmark 2.x— www.vmware.com/a/vmmark/
17

VDIのアクセスにおける問題
• 多数の仮想マシン (VM)からストレージに対して、同時に大量のRead/Writeアクセスが発生
‒ 「ブートストーム」: 始業時などに、大量のクライアントVMが一斉に起動
‒ クライアントVMの定期的なメンテナンス
• Windows Update
• ウィルス・チェック、パターンファイルの更新 etc.
• ストレージリソースはCPU、メモリと異なり、共有ストレージ上に存在
‒ 「複数のハイパーバイザー (=物理リソース)」間で共有
• 「インフラ全体として」高いパフォーマンスを発揮するには、低遅延かつ高スループットのストレージと
十分なパフォーマンスを確保できるネットワークが必要
‒ 複数のドライブ/コントローラーにアクセスを分散することで、仮想デスクトップのI/O負荷を平準化 (HDD)
‒ ストレージ自体の高速化 → フラッシュベースのストレージ
• シーク動作がないために、ランダム・アクセスが高速
• HDDベースのストレージに比べて高いIOPS性能
‒ より広帯域のネットワーク・インフラ: 16Gbps Fibre Channel
18

インフラに求められるパフォーマンス
どのようなストレージ・テクノロジーを使用すべきか?
• 高速なストレージアクセスを実現するには、ネットワーク (I/Oトランスポート)とストレージ
の両方が高パフォーマンスであることが必要
‒ ネットワーク帯域: 8-16Gbps (Fibre Channel), 1-10Gbps (Ethernet) etc.
‒ ストレージ (IOPS): 100-200 (HDDベース), 数千-数万 (SSDベース) 1,000,000+ (All Flashベース)
• I/Oトランスポートに求められる帯域 (bps) = IOPS x 転送サイズ
‒ より省スペース/統合されたインフラを実現するには、高IOPSのストレージと広帯域のネットワークが
必要
19
低IOPSストレージ (HDD)
→ ディスク/コントローラーの分散による性能向上
低帯域ネットワーク (1Gbps Ethernet)
→ 多数のスイッチ/ケーブルによる性能向上
高IOPSストレージ (フラッシュ)
→ 少数の筐体で高性能
広帯域ネットワーク (16Gbps FC)
→ ケーブル本数の減少

“フラッシュ化”でボトルネックが変わった!!
1回の読み込みアクセス処理にかかる時間の積み上げ比較
アプリの処理
プロトコルの処理@Server
ネットワーク遅延
プロトコルの処理@Storage
ストレージアクセス処理
アプリの処理
ストレージ内
アプリの処理
ストレージアクセス処理
アプリの処理
従来型ストレージ
フラッシュストレージ
サーバ内
サーバ内
ストレージが高速なほど、
この色の部分の処理を
高速化する必要がある
※図中の処理の割合は、イメージです 20

どのように改善するか?
21
アプリの処理
サーバを速くすることで改善
スイッチのカスケードが増えると悪化
パケットドロップや入れ子で大幅に悪化
(特にIP系はここが保証外)
プロトコルの処理@Storage よりストレージ処理に適した低遅延な
プロトコルの選択
ファイバーチャネルを使用することで改善

FCストレージ/SANに対するよくある”誤解”
• 「そんなに広帯域のネットワーク、要らないんじゃ
ないの?」
‒ [回答] そんなことはありません。なぜなら、FCネット
ワーク (ファブリック)に対するニーズはますます高く
なっているからです。
• “オール・フラッシュ”ストレージの普及
• 仮想サーバーのさらなる高密度化
• 「ファイバーチャネルって、高いんじゃないの?」
‒ [回答] ファイバーチャネルは高信頼・低遅延のネット
ワークを提供することができ、高い付加価値があります。
• 「ファイバーチャネルって、難しいんじゃないの?」
‒ [回答] ファイバーチャネルは、実はとっても簡単です。
22

なぜFC”スイッチ”をつけるのか？
FCスイッチがあるからこそのネットワークの”見える化”
• よく言われる話： “サーバーとストレージを直結すればいいんじゃない?”
‒ Direct Attached Storage (DAS)での構成
‒ 「FCスイッチを買わなくていいから、コストが下がる！」
‒ 「最近はストレージ装置にもたくさんFCポートがあるから、スイッチは不要！」
‒ 「FCスイッチがつくと、障害点が増える！」
‒ 「FCスイッチがつくと、遅延が増加する！」
24
???

なぜFC”スイッチ”をつけるのか？
FCスイッチがあるからこそのネットワークの”見える化”
• よく言われる話： “サーバーとストレージを直結すればいいんじゃない?”
‒ 「FCスイッチを買わなくていいから、コストが下がる！」
• 【回答】初期コストだけではなく、運用・保守コストも検討に入れましょう。
‒ 「最近はストレージ装置にもたくさんFCポートがあるから、スイッチは不要！」
• 【回答】ストレージは1台だけでいいですか？用途に合わせて、ストレージ・ベンダーや
機種を使い分けませんか？
‒ 「FCスイッチがつくと、障害点が増える！」
• 【回答】設計によって障害点は排除できます。そもそも、ネットワークの世界ではノー
ド間を”直結”していませんよね？
‒ 次回、詳しくご説明する予定です。
‒ 「FCスイッチがつくと、遅延が増加する！」
• 【回答】ストレージの遅延と比べれば、スイッチの遅延は無視できるレベルです。
25

SANスイッチ = ネットワーク監視の「窓」
• DAS (Direct Attached Storage)
‒ ネットワーク (SCSI/ファイバケーブル)で障害、パフォーマンスを確認できない
• SAN環境
‒ ネットワーク (=ファブリック/スイッチ)から障害、パフォーマンスを確認可能
26
SCSI/ファイバケーブル
??
SAN

実は簡単なFC SAN
• 「プラグ・アンド・プレイ」での構成
‒ 「ケーブルをつなぐだけ」で、以下の全ての手続きを”自
動的に”実行して構成
• ノード (N_Port) - スイッチ (F_Port)間接続
‒ デバイスのファブリックへの参加: スイッチがFCアドレスを付与
‒ デバイスがファブリックに情報を登録 (ネームサーバー)
‒ ファブリックを通じて、通信したいデバイスを認識
‒ 設定したアクセス制御リスト (=ゾーン)に基づいて、デバイス間通信を
フィルタリング
• スイッチ (E_Port) – スイッチ (E_Port)間接続
‒ スイッチ間で識別番号 (ドメインID)の重複の有無を確認
‒ ファブリックにおける“プリンシパル”スイッチの決定
‒ 経路情報の交換・決定 (FSPF: Fabric Shortest Path First)
‒ アクセス制御情報 (=ゾーン情報)を交換、統合
27
FCスイッチ
FCスイッチ
“ファブリック”を
自動形成！
E_Port
E_Port
N_Port
F_Port
サーバー/HBA
ケーブルを
つなぐだけ！
ファブリックに
ログイン！

FC SANの技術的な話
FCファブリックにおけるデバイスの”ログイン” (ノード-スイッチ間)
• ネットワークへのログイン
‒ Fabric Login (FLOGI)
• FCネームサーバーへの登録
‒ Port Login - PLOGI
• 通信する許可を得る
‒ Port Login - PLOGI
28
ファブリック
(F_Port)
ネームサーバー
(FCスイッチ)
ログインサーバー
(FCスイッチ)
サーバー
(N_Port)
ストレージ
(N_Port)
PLOGI
Accept

FCファブリックの形成プロセス (スイッチ-スイッチ間)
29
Step1:
リ
ン
ク
の
初
期
化
ファブリック
初期化
Step2:
ポ
ー
ト
操
作
モ
ー
ド
の
検
出
Step3:
プ
リ
ン
シ
パ
ル
ス
イ
ッ
チ
選
択
Step4:
ド
メ
イ
ン
ア
ド
レ
ス
配
布
Step5:
経
路
選
択
(FSPF)
ファブリック
作動可
CLASS F通信
(Switch Fabric内部リンクサービス)

Fabric Shortest Path First (FSPF)
 FSPFはリンクにおけるパス選択プロトコル
(OSPFから派生)
‒ リンクコスト/ウェイトを使用
‒ ホップカウントの考慮
‒ 利用可能な帯域の認識
‒ 複数の同コストリンク間で負荷分散
• ファブリックアドレス (スイッチのドメイン
番号)によるルーティング
 容易な6つのステップ
1.隣接スイッチ間で“Hello”
2.全体のリンク状況を隣接ノードと交換
3.リンク状況記録を更新
4.ソースと宛先間の最短パスを計算
5.ルートをセットアップ
6.稼働 ! 30
Hello!
Hello!
Hello!
Hello!
Hello!
1000
1000
1000
500
500
※パスコストは横切る
リンクコストの合計
すべてのスイッチが他のスイッチへの
最短パスを計算
※それぞれの丸はスイッチを表す

ゾーニング
•ゾーン (Zone)とは？
‒ 「アクセスを互いに可能にするFCノード群」を1つに
まとめたグループ
‒ ゾーンを構成すること = ゾーニング (Zoning)
• ファブリック内の任意のノード間のアクセスを制御
‒ 1つのファブリックを論理的なアクセスグループに分割
• Ethernet (L2スイッチ)におけるVLAN (Virtual LAN)と似た機能
•ゾーニングの目的
‒ セキュリティの向上
• ストレージへのアクセスを制御することでデータの一貫
性を保証
‒ 障害伝搬範囲の低減
• RSCNやLIPの伝達範囲を、影響のあるゾーン内に制限 31
0 1 2 3 4 5 6 7
8 9 10 11 12 13 14 15
zone2 zone3
zone4zone1

本日のまとめ
• 千太くんがFC SANベースのフラッシュ・ストレージを
選択した理由
‒ サーバー仮想化環境に最適
‒ デスクトップ仮想化環境に最適
‒ ストレージに対する高パフォーマンスのニーズ
‒ ネットワーク・インフラの可視化
• ファイバーチャネル (FC)で、かつSAN (Storage Area Network)
だからこそ実現
‒ ネットワーク・インフラ構成の自動化
‒ 過去20年に渡る実績と安定性
• メインフレームにおけるストレージ・インフラとしても使用
32
！！！

次回の予告
33
• FC SANをベースにした、オール・フラッシュ・ス
トレージ環境を構築することを決定した千太くん。
• FC SAN/ストレージ・インフラの設計に際して、
気をつけるべきポイントとは?
• 次回 (第2弾)は「設計」編！
‒ 開催日時は、別途ご案内します。
‒ 是非、お楽しみに！
？？？

Thank you
本件に関するお問合せ
http://www.brocade.com/ja/forms/contact-us.html
ブロケードコミュニケーションズシステムズ株式会社

“見てわかる” ファイバーチャネルSAN基礎講座（第1弾）～まず理解しよう！基本の “キ”～

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to “見てわかる” ファイバーチャネルSAN基礎講座（第1弾）～まず理解しよう！基本の “キ”～

Similar to “見てわかる” ファイバーチャネルSAN基礎講座（第1弾）～まず理解しよう！基本の “キ”～ (20)

More from Brocade

More from Brocade (20)

Recently uploaded

Recently uploaded (9)