Embed Size (px)
Citation preview
ブロケード 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/Japanese
• そんななかのWEBセミナー です！3
講師のご紹介
• 辻 哲也 つじ てつや
• 2002年 ブロケード入社
‒ ブロケード日本法人では「古株」です。
‒ 最近はバックエンドの支援業務が中心ですが、昔はいろいろとマーケティング活動もやってました。
• ブログ連載してますので、よろしければアクセスしてみてください。
‒ http://community.brocade.com/t5/Brocade-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
ストレージアクセス処理
ネットワーク遅延
プロトコルの処理@Server
アプリの処理
プロトコルの処理@Storage
ストレージ内
アプリの処理
プロトコルの処理@Server
ネットワーク遅延
プロトコルの処理@Storage
ストレージアクセス処理
ネットワーク遅延
プロトコルの処理@Server
アプリの処理
プロトコルの処理@Storage
従来型ストレージ
フラッシュストレージ
サーバ内
サーバ内
ストレージが高速なほど、この色の部分の処理を高速化する必要がある
※図中の処理の割合は、イメージです 20
どのように改善するか?
21
プロトコルの処理@Server
アプリの処理サーバを速くすることで改善
ネットワーク遅延スイッチのカスケードが増えると悪化パケットドロップや入れ子で大幅に悪化(特にIP系はここが保証外)
プロトコルの処理@Server
プロトコルの処理@Storage よりストレージ処理に適した低遅延なプロトコルの選択
ファイバーチャネルを使用することで改善
FCストレージ/SANに対するよくある”誤解”
• 「そんなに広帯域のネットワーク、要らないんじゃないの?」
‒ [回答] そんなことはありません。なぜなら、FCネットワーク (ファブリック)に対するニーズはますます高くなっているからです。
• “オール・フラッシュ”ストレージの普及
• 仮想サーバーのさらなる高密度化
• 「ファイバーチャネルって、高いんじゃないの?」
‒ [回答] ファイバーチャネルは高信頼・低遅延のネットワークを提供することができ、高い付加価値があります。
• 「ファイバーチャネルって、難しいんじゃないの?」
‒ [回答] ファイバーチャネルは、実はとっても簡単です。
22
2. なぜFC SAN？
23
なぜ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 SANの技術的な話FCファブリックの形成プロセス (スイッチ-スイッチ間)
29
Ste
p 1:
リンクの初期化
ファブリック初期化
Ste
p 2
:
ポート操作モードの検出
Ste
p 3
:
プリンシパルスイッチ選択
Ste
p 4
:
ドメインアドレス配布
Ste
p 5
:
経路選択(F
SP
F)
ファブリック作動可
CLASS F通信(Switch Fabric内部リンクサービス)
FC SANの技術的な話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
※パスコストは横切るリンクコストの合計
すべてのスイッチが他のスイッチへの最短パスを計算
※それぞれの丸はスイッチを表す
FC SANの技術的な話ゾーニング
•ゾーン (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弾)は「設計」編！
‒ 開催日時は、別途ご案内します。
‒ 是非、お楽しみに！
？？？
Q&A
34
Thank you
本件に関するお問合せ
http://www.brocade.com/ja/forms/contact-us.html
ブロケード コミュニケーションズ システムズ株式会社
