Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

4,949 views

Published on

本webセミナーでは、ブロケードFCスイッチのオペレーションを通して、FC SANの設計・導入・運用を学んでいきます。
まず第1弾は基本的な考え方や設定・操作を、もしかしたらデモも交えながら(現在検討中)、判りやすく解説します。

----------

第1回~まず理解しよう! 基本の “キ”~
https://www.slideshare.net/brocade/san1-62678292
第2回~FC SAN設計における勘所とは?~
https://www.slideshare.net/brocade/san2fc-san
第3回~間違わない!FC SAN導入のヒントとコツ~
https://www.slideshare.net/brocade/san3fc-san
第4回~続・間違わない!FC SAN導入のヒントとコツ~
https://www.slideshare.net/brocade/san4fc-san
第5回~さあ、いよいよ、運用です!~
https://www.slideshare.net/brocade/san5
第6回~困った時もこれで安心(?)、FC SANにおけるトラブルシューティングのコツとは?~
https://www.slideshare.net/brocade/san6-fc-san-71206812

Published in: Technology
  • Be the first to comment

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

  1. 1. ブロケード WEBセミナーシリーズ 第4回 “見てわかる” ファイバーチャネルSAN基礎講座 (第1弾) ~まず理解しよう! 基本の “キ”~
  2. 2. 本日のWEBセミナーの注意点とお願い • 【質問】タブ、および【チャット】タブで随時質問を受け付けます。 ‒ 【質問】タブへの記載は、講師のみが閲覧できます ‒ 【チャット】タブへの記載は、参加者全員が閲覧できます • セミナー終了後、アンケート画面に遷移します。ぜひご協力お願い します! ※メールアドレス記載の上、ご回答いただいた方の中から抽選でブ ロケードロゴグッズプレゼント! 2
  3. 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. 4. 講師のご紹介 • 辻 哲也 つじ てつや • 2002年 ブロケード入社 ‒ ブロケード日本法人では「古株」です。 ‒ 最近はバックエンドの支援業務が中心です が、昔はいろいろとマーケティング活動も やってました。 • ブログ連載してますので、よろしければ アクセスしてみてください。 ‒ http://community.brocade.com/t5/Brocad e-Japan/bg-p/Brocade-Japan 4 (@ITさんより)
  5. 5. “見てわかる” ファイバーチャネルSAN基礎講座 シリーズ構成 (案) • 第1弾 (今回): 「検討」編 ‒ まず理解しよう! 基本の “キ”~ • 第2弾: 「設計」編 • 第3弾: 「導入」編 • 第4弾: 「運用」編 ※上記は変更される可能性もありますので、あらかじめご了承ください。。。 5
  6. 6. 本日のテーマ • テーマ ‒ FC SANを導入する「前」の話 ‒ ストレージ・インフラの選定に悩みぬいた、”あるIT管理者の物語” • セミナーの目的・主旨 ‒ “これからの”ストレージ・インフラを検討する上での参考材料をご提供。 ‒ Brocadeのセミナーなので、やっぱり「FC SANの良さ」を訴求します! ‒ 今日のセミナーでは、デモはありません。 • 次回以降 (おそらく第3弾くらいから)、デモを行うつもりです。 6
  7. 7. “登場人物”のご紹介 • 出得多 千太 (でえた せんた) ‒ とある製造業のIT部門で勤務する、中堅のITインフラ管理者 • 将来のビジネスを支えるIT基盤の選定から構築・運用までを任される見込み • ストレージ・インフラの更改プロジェクトを担当 ‒ 新人時代にはデータセンター内のストレージ・インフラの運用を担当 • 「データセンター内でのみ生きることができる」という謎の人物 (?)と出会う 7
  8. 8. 千太くんの悩み • 「仮想化」環境でのストレージ・イ ンフラはどうすればいい? ‒ サーバーは仮想化 (ハイパーバイザー) ‒ クライアントも仮想化 (仮想デスク トップ: VDI) ‒ 自社でプライベート・クラウド環境を 構築 (?) 8
  9. 9. データ・ストレージの選択肢 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. 10. ストレージ・インフラの要件 “とある製造業”の場合 • 「データ = 企業ノウハウ」の塊 ‒ 設計情報や顧客情報の消失や流出は、絶対に避けたい。 ‒ “ストレージ (=データ)アクセス”のためのネットワークには、高いパフォーマ ンスと信頼性が欲しい。 • データの増加量は予測不可能 ‒ 無尽蔵 (?)に増え続けるデータを、効率よく管理できるインフラが必須。 • 運用・保守の負荷を最小化 ‒ 「より少人数の管理者」で「より大規模」なインフラを管理したい。 ‒ ネットワークに関わるオペレーションは、出来る限り自動化したい。 10
  11. 11. ストレージ・インフラの要件 (続き) “とある製造業”の場合 • 技術の変化は予測不可能 ‒ 今後登場する新技術にも、柔軟に対応できるインフラが望ましい。 • インフラ投資の「見える化」 ‒ インフラに関わるさまざまなデータを可視化し、投資効率を最大化したい。 ‒ 投資計画の判断材料となる情報を取得したい。 ‒ 初期コストだけではなく、運用コストも含めたコスト総額を抑えたい。 11
  12. 12. 結局、千太くんが選んだのは・・・ 12
  13. 13. 結局、千太くんが選んだのは・・・ 13 FC SAN (スイッチ)とオール・ フラッシュ・ストレージをベース にした、ストレージインフラ
  14. 14. 千太くんはなぜ、FC SANとフラッシュ・ ストレージを選んだのか? 14
  15. 15. 1. なぜファイバーチャネル? 15
  16. 16. 「クラウドからオンプレミス」への動き • 世の中の流れ (主流)は、「オンプレミスからクラウド」 • 一部には「クラウドからオンプレミス」への動きも・・・ ‒ 大規模になってくると、クラウドはコスト面でデメリットも。 ‒ 大規模になってくると、クラウドは管理面でデメリットも。 16
  17. 17. サーバー仮想化環境でのパフォーマンス 高パフォーマンスを求めるならFC (VMmarkベンチマークより) 17 VMmarkのトップ20の 構成は、すべてファイバ チャネル (FC)を使用 Source: VMware VMmark 2.x— www.vmware.com/a/vmmark/ 17
  18. 18. VDIのアクセスにおける問題 • 多数の仮想マシン (VM)からストレージに対して、同時に大量のRead/Writeアクセスが発生 ‒ 「ブートストーム」: 始業時などに、大量のクライアントVMが一斉に起動 ‒ クライアントVMの定期的なメンテナンス • Windows Update • ウィルス・チェック、パターンファイルの更新 etc. • ストレージリソースはCPU、メモリと異なり、共有ストレージ上に存在 ‒ 「複数のハイパーバイザー (=物理リソース)」間で共有 • 「インフラ全体として」高いパフォーマンスを発揮するには、低遅延かつ高スループットのストレージと 十分なパフォーマンスを確保できるネットワークが必要 ‒ 複数のドライブ/コントローラーにアクセスを分散することで、仮想デスクトップのI/O負荷を平準化 (HDD) ‒ ストレージ自体の高速化 → フラッシュベースのストレージ • シーク動作がないために、ランダム・アクセスが高速 • HDDベースのストレージに比べて高いIOPS性能 ‒ より広帯域のネットワーク・インフラ: 16Gbps Fibre Channel 18
  19. 19. インフラに求められるパフォーマンス どのようなストレージ・テクノロジーを使用すべきか? • 高速なストレージアクセスを実現するには、ネットワーク (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) → ケーブル本数の減少
  20. 20. “フラッシュ化”でボトルネックが変わった!! 1回の読み込みアクセス処理にかかる時間の積み上げ比較 アプリの処理 プロトコルの処理@Server ネットワーク遅延 プロトコルの処理@Storage ストレージアクセス処理 ネットワーク遅延 プロトコルの処理@Server アプリの処理 プロトコルの処理@Storage ストレージ内 アプリの処理 プロトコルの処理@Server ネットワーク遅延 プロトコルの処理@Storage ストレージアクセス処理 ネットワーク遅延 プロトコルの処理@Server アプリの処理 プロトコルの処理@Storage 従来型ストレージ フラッシュストレージ サーバ内 サーバ内 ストレージが高速なほど、 この色の部分の処理を 高速化する必要がある ※図中の処理の割合は、イメージです 20
  21. 21. どのように改善するか? 21 プロトコルの処理@Server アプリの処理 サーバを速くすることで改善 ネットワーク遅延 スイッチのカスケードが増えると悪化 パケットドロップや入れ子で大幅に悪化 (特にIP系はここが保証外) プロトコルの処理@Server プロトコルの処理@Storage よりストレージ処理に適した低遅延な プロトコルの選択 ファイバーチャネルを使用することで改善
  22. 22. FCストレージ/SANに対するよくある”誤解” • 「そんなに広帯域のネットワーク、要らないんじゃ ないの?」 ‒ [回答] そんなことはありません。なぜなら、FCネット ワーク (ファブリック)に対するニーズはますます高く なっているからです。 • “オール・フラッシュ”ストレージの普及 • 仮想サーバーのさらなる高密度化 • 「ファイバーチャネルって、高いんじゃないの?」 ‒ [回答] ファイバーチャネルは高信頼・低遅延のネット ワークを提供することができ、高い付加価値があります。 • 「ファイバーチャネルって、難しいんじゃないの?」 ‒ [回答] ファイバーチャネルは、実はとっても簡単です。 22
  23. 23. 2. なぜFC SAN? 23
  24. 24. なぜFC”スイッチ”をつけるのか? FCスイッチがあるからこそのネットワークの”見える化” • よく言われる話: “サーバーとストレージを直結すればいいんじゃない?” ‒ Direct Attached Storage (DAS)での構成 ‒ 「FCスイッチを買わなくていいから、コストが下がる!」 ‒ 「最近はストレージ装置にもたくさんFCポートがあるから、スイッチは不要!」 ‒ 「FCスイッチがつくと、障害点が増える!」 ‒ 「FCスイッチがつくと、遅延が増加する!」 24 ???
  25. 25. なぜFC”スイッチ”をつけるのか? FCスイッチがあるからこそのネットワークの”見える化” • よく言われる話: “サーバーとストレージを直結すればいいんじゃない?” ‒ 「FCスイッチを買わなくていいから、コストが下がる!」 • 【回答】初期コストだけではなく、運用・保守コストも検討に入れましょう。 ‒ 「最近はストレージ装置にもたくさんFCポートがあるから、スイッチは不要!」 • 【回答】ストレージは1台だけでいいですか?用途に合わせて、ストレージ・ベンダーや 機種を使い分けませんか? ‒ 「FCスイッチがつくと、障害点が増える!」 • 【回答】設計によって障害点は排除できます。そもそも、ネットワークの世界ではノー ド間を”直結”していませんよね? ‒ 次回、詳しくご説明する予定です。 ‒ 「FCスイッチがつくと、遅延が増加する!」 • 【回答】ストレージの遅延と比べれば、スイッチの遅延は無視できるレベルです。 25
  26. 26. SANスイッチ = ネットワーク監視の「窓」 • DAS (Direct Attached Storage) ‒ ネットワーク (SCSI/ファイバケーブル)で障害、パフォーマンスを確認できない • SAN環境 ‒ ネットワーク (=ファブリック/スイッチ)から障害、パフォーマンスを確認可能 26 SCSI/ファイバケーブル ?? SAN
  27. 27. 実は簡単な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 ケーブルを つなぐだけ! ファブリックに ログイン!
  28. 28. FC SANの技術的な話 FCファブリックにおけるデバイスの”ログイン” (ノード-スイッチ間) • ネットワークへのログイン ‒ Fabric Login (FLOGI) • FCネームサーバーへの登録 ‒ Port Login - PLOGI • 通信する許可を得る ‒ Port Login - PLOGI 28 ファブリック (F_Port) ネームサーバー (FCスイッチ) ログインサーバー (FCスイッチ) サーバー (N_Port) ストレージ (N_Port) PLOGI Accept
  29. 29. FC SANの技術的な話 FCファブリックの形成プロセス (スイッチ-スイッチ間) 29 Step1: リ ン ク の 初 期 化 ファブリック 初期化 Step2: ポ ー ト 操 作 モ ー ド の 検 出 Step3: プ リ ン シ パ ル ス イ ッ チ 選 択 Step4: ド メ イ ン ア ド レ ス 配 布 Step5: 経 路 選 択 (FSPF) ファブリック 作動可 CLASS F通信 (Switch Fabric内部リンクサービス)
  30. 30. 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 ※パスコストは横切る リンクコストの合計 すべてのスイッチが他のスイッチへの 最短パスを計算 ※それぞれの丸はスイッチを表す
  31. 31. 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
  32. 32. 本日のまとめ • 千太くんがFC SANベースのフラッシュ・ストレージを 選択した理由 ‒ サーバー仮想化環境に最適 ‒ デスクトップ仮想化環境に最適 ‒ ストレージに対する高パフォーマンスのニーズ ‒ ネットワーク・インフラの可視化 • ファイバーチャネル (FC)で、かつSAN (Storage Area Network) だからこそ実現 ‒ ネットワーク・インフラ構成の自動化 ‒ 過去20年に渡る実績と安定性 • メインフレームにおけるストレージ・インフラとしても使用 32 !!!
  33. 33. 次回の予告 33 • FC SANをベースにした、オール・フラッシュ・ス トレージ環境を構築することを決定した千太くん。 • FC SAN/ストレージ・インフラの設計に際して、 気をつけるべきポイントとは? • 次回 (第2弾)は「設計」編! ‒ 開催日時は、別途ご案内します。 ‒ 是非、お楽しみに! ???
  34. 34. Q&A 34
  35. 35. Thank you 本件に関するお問合せ http://www.brocade.com/ja/forms/contact-us.html ブロケード コミュニケーションズ システムズ株式会社

×