Downloaded 559 times
Uploaded byBrocade
ストレージネットワーク基礎講座
SAN (Storage Area Network) って一体何だろう？LANやWANと何が違うの？ SANを初めて学ぶ方のための資料です。
ストレージネットワーク基礎講座
- 1.
- 2. 目次 • ストレージ接続の本質と変遷 • SANで実現できること •SAN導入事例紹介 • SANの冗長構成 © 201５ Brocade Communications Systems, Inc. 2
- 3. ストレージ接続の本質と変遷 © 201５ BrocadeCommunications Systems, Inc. 3
- 4.
- 5. ストレージアクセスに求められるもの • 高信頼性（データ整合性・エラー検出） ‒ OS,アプリケーションが読み書きするデータが変質（ビットエラー等）することは 決して許されません •広帯域（高速） ‒ リッチコンテンツのデータ量は増大する一方 • 低遅延 ‒ ストレージアクセスの遅延はアプリケーションのパフォーマンスに直接影響を与 えます CPU（OS,アプリ）とストレージ間 の通信は正確かつ確実にそして速く あるべき。 だから、厳密さが要求されるのです © 201５ Brocade Communications Systems, Inc. 5
- 6. ブロックアクセス - 概要 •ある一定の大きさ 「ブロック」を単位としてデータの入出力 (Input/Output:I/O)を行う • ブロックデバイス ‒ デバイスごとに決まっている複数バイトの「ブロック」を単位として、データの入出力を行う ‒ ディスク、CD-ROM、テープなど • ブロック単位でのアクセスなので、ファイルやディレクトリは意識しない ‒ ディレクトリ/ファイル単位での制御はできない • ファイルアクセスに比べて高速 • ファイルシステムをデバイス上に構築 (基本はOS固有) ‒ Windows: FAT、NTFS ‒ UNIX: UFS、JFS etc. ‒ Linux： ext2、ext3 etc. • ブロックデバイスは、複数コンピュータから同時にアクセスすることは不可 ‒ Global File Sytems (GFS)/OCFS (Oracle Cluster File System)などの分散ファイルシステムを 除く 01101100・・・・・ © 201５ Brocade Communications Systems, Inc. 6
- 7. アプリケーションがディスクにデータを書き込 むためには？ ファイルシステムとブロックアクセス • データを収容するには ‒ 保存場所の情報（アドレス）が必要 ‒メディア毎にアドレスは異なる • ディスクではシリンダ・ヘッド・セクタ • テープではトラック・ブロック ‒ SCSIコマンドでメディアの差異を吸収（抽象化） • Logical Block Address (LBA)でアクセス • 各メディアはLBAからアドレスを特定 • ファイルシステムとは？ ‒ アプリケーションと人間にわかりやすい様データ をファイルという単位で扱えるようにする仕組み • .mp4 や .avi などのレベルで読み書きができるのはファイルシ ステムがブロック単位で読み書きする場所を管理してくれて いるから！ ストレージメディア ストレージ インターフェース ストレージ ドライバー(SCSI) ファイルシステム アプリケーション OS デバイス ハードディスク フォーマット テープメディア フォーマット OSがデバイスに直接データの読み 書きする時はブロックアクセス © 201５ Brocade Communications Systems, Inc. 7
- 8. ファイルアクセス - 概要 NAS/ファイルサーバで使われるアクセス方法 •ディレクトリ 「フォルダ」やファイルを単位としてデータの入出力 (Input/Output :I/O)を行う • ファイルやディレクトリ単位での制御が可能 • ブロックアクセスに比べて低速 (ネットワークプロトコルやファイルシステム を介してアクセス） • TCP/UDP上に構成されるクライアントサーバ型の「アプリケーション」 • 使用するプロトコル ‒ Windows環境: SMB/CIFS ‒ UNIX/Linux環境: NFS • OSが持つファイルシステム (ブロックアクセス)の上位に位置する • OSには依存しない ‒ WindowsでNFSを実装することも、UNIX/LinuxでSMB/CIFSを実装することも可能 • 複数コンピュータから同時に単一ファイルにアクセスすることが可能 • ブロックアクセスの場合よりも、「リソース共有」という観点で有利 Windows Unix/Linux NTFS UFS EXT3 アプリケーション ユーザー CIFS NFS クライアント ファイルサーバ © 201５ Brocade Communications Systems, Inc. 8
- 9. コンピュータとストレージ接続の変遷 • 1990年代はじめ頃まで ‒ SCSI(Small Computer System Interface)やIDE (Integrated Device Electronics)などの相互接続を通じてDAS (Direct Attached Storage)にアク セスするのが一般的 • DAS: ホストとストレージが直接接続されている形態 • SCSIは「パラレル」SCSI • 1990年代後半 ‒ SCSIのパラレルアーキテクチャが性能と距離の限界 • コンピュータシステムの速度が向上 • データストレージへの需要 • 1990年代後半以降 ‒ シリアルアーキテクチャの「ファイバーチャネル」が登場し、SCSIを置 き換え • サーバ-ストレージ間の距離を延長 • ケーブリングが容易 ‒ デバイス間でストレージを共有 = SANのはじまり ファイバーチャネル （～10 km） SCSI / IDE （～10 m） コンピュータ ストレージ FC (SAN)スイッチ コンピュータ ストレージ コンピュータ ストレージ 周辺機器 インターフェース 周辺機器 インターフェース 周辺機器 “ネットワーク“ © 201５ Brocade Communications Systems, Inc. 9
- 10. ストレージ接続形態 DAS (Direct Attached Storage) SAN (StorageArea Network) SAS SATA 外部ストレージ 内蔵ストレージ FCP 分散ストレージ SDS (Software Defined Storage) Ethernet / IPネットワーク Fibre Channel ファブリック iSCSI , FCoE NAS (CIFS/NFS) IPストレージ FCストレージ 一般的にSANといえばブロック ストレージを対象とするスト レージネットワークを意図する ことが多く、SAN=FCが前提に なります。iSCSIと区別するとき にはFC-SAN,IP-SANと明示する こともあります。（狭義の SAN） しかしながら、本来のSANとは ストレージのネットワークとい う意味ですので、NAS (Network Attached Storage) や分散ストレージ/オブジェクト ストレージを構成するネット ワークも広義のSANと言えます。 © 201５ Brocade Communications Systems, Inc. 10
- 11. Fibre Channel ストレージ・ネットワーク ストレージ・サーバー間通信に特化したネットワーク ミッションクリティカルなアプリケーション向けの最も利用さ れているデータセンターネットワーク •統合・共有ストレージ環境の要件を満たす為に特別設計 • エンタープライズクラスの信頼性、拡張性、I/Oパフォー マンスを実現 • 低遅延、順序保証、ロスレス転送、冗長ファブリックで データ配信を保証 • 重要なビジネスアプリケーション用途で広く利用 (ie. Oracle, ERP, CRM) • 重要なアプリケーションに最高のパフォーマンスを与える ティア１ストレージを利用 • 災対、バックアップ機能 • 豊富なストレージ資産との連携 LAN FC Storage FC Storage Network Servers Data Center IP LAN FC Switch Ethernet IP Core © 201５ Brocade Communications Systems, Inc. 11
- 12. Data Center IP LAN IP ストレージ・ネットワーク 非基幹アプリケーション向けのストレージネットワーク •どこにでもあるイーサネットとTCP/IPを活用 • SMB,小規模エンタープライズ及び部門クラスのストレー ジ・ネットワークとして好まれる ‒ 既存のIPツール、スキルセットを利用できる • 非基幹アプリケーションにおいては十分なパフォーマンス、 妥当な価格性能を提供 IP Core LAN IP Storage (NAS/iSCSI) Servers 懸念点: • 従来の共有LAN上で混在したワークロードを実行してパ フォーマンスと可用性のSLAを達成できるのか？ • ネットワーク管理部門とサーバ/ストレージ管理部門の 連携で迅速なパフォーマンス最適化ができるか？ 汎用（業務用）ネット ワークと共用できる ※技術的には可能ですが、 運用に耐えられるかどうか は別問題 © 201５ Brocade Communications Systems, Inc. 12
- 13. LANの“N”etworkはコミュニ ケーション 様々なデバイスが様々なアプリ ケーションで多種多様に通信し 合うためのネットワーク ‒ Web, Mail,VoIP, VOD・・・ “N”に惑わされるな LA”N” とSA”N”のNは似て非なるもの SANの“N”etworkは経路の共同利用 サーバ(OS)の通信対象はストレージのみ。 その昔１対１で繋いでいた補助記憶装置 のインターフェースをスイッチで束ねた もの。言い換えればDAS環境の集合体 © 201５ Brocade Communications Systems, Inc. 13
- 14. SANで実現できること SANを用いたソリューション © 201５ BrocadeCommunications Systems, Inc. 14
- 15. SANが求められる背景 サーバ/ストレージインフラのトレンド • サーバ仮想化による、フロントサーバ(Web /App) における、ストレー ジのネットワーク化 ‒ SAN bootの活用により、OSの起動を容易に ‒ データの共有化（共有ストレージの活用） • ストレージ共有による、利用効率の向上 ‒ ストレージ装置の進化と価格の下落 • TB当たりの容量単価の下落 • ディザスタ・リカバリ (DR)に対する要求 ‒ DRのインフラとして、データの集約は必要 ‒ 集約ストレージ間をWDM/FCIPを用いたDR • 分散処理技術の進展 ‒ Oracle Real Application Cluster (RAC)、グリッド・コンピューティング etc. ‒ SAN上のストレージ (データ)を共有 • ストレージ仮想化技術の登場 ・サーバ仮想化の推進 ・高密度・高性能のサーバ ・分散処理技術の進展 (Oracle RAC, Grid-Computing) など ・容量単価の下落 ・高機能化の進展 ・SAN Bootの普及 ・Flash Storageの普及 ・ストレージ仮想化製品 など データ処理 (サーバ/CPU) データ格納 (ストレージ) © 201５ Brocade Communications Systems, Inc. 15 ストレージ・エリア・ネット ワーク (SAN)
- 16. 市場の大きな変化 仮想化・クラウドの普及 • 効率化や既存資産の有効利用 ‒ CPU/メモリの利用効率向上 ‒統合ストレージによる、データ集約 ‒ 最新機種でサポートされないOS・アプリケーションへの対応 • 高集積なシステムへ ‒ 少数のサーバでの運用が可能 ‒ ITリソースの有効活用 • 仮想化の柔軟性や可用性が注目 ‒ 仮想マシーン毎のDR環境構築 ‒ 物理サーバ間のクラスタ構成 • 多種の仮想化サーバが普及 ‒ VMWare, Hyper-V, Xen, KVMなど © 201５ Brocade Communications Systems, Inc. 16
- 17. SANがもたらすソリューション アプリケーションサーバ群のストレージ統合 •SANソリューション – SANによるストレージ統合の推進 – ストレージの利用効率を高めることにより、ストレージ 投資の効率化による設備投資コストの削減 –ストレージの容量追加作業等が一元的に可能なため運用 負荷の削減 – 集約化により、消費電力・空調対策を実現 •課題 –ストレージの効率的な利用ができていない –管理コストが増大 –データセンターの設置面積を圧迫している –データ可用性を確保できない –導入計画が長期間必要になる –消費電力・空調への負担低減が必要 70% 80% 60% 70% 90% 50% 50% 40% DBサーバファイルサーバ アプリケーションサーバ 追加予定サーバ群 ストレージ 平均利用率 50％程度 ファイル サーバ ファイル サーバ DB サーバ DB サーバ アプリケーション サーバ アプリケーション サーバ アプリケーション サーバ ファイル サーバ DB サーバ アプリケーションアプリケーション アプリケーション サーバ 追加 Notes サーバ ストレージ統合に よる効率利用 © 201５ Brocade Communications Systems, Inc. 17
- 18.
- 19. SANがもたらすソリューション ビジネスをとめない為の遠隔地ミラーリング • 課題 ‒ グローバル化の進展により、従来より 高度・高信頼なシステムが必要になる ‒震災などによる災害時にも、システム 停止を行なえない ‒ データ容量の増加により、テープから のリストアに多大な時間がかかる • SANソリューション ‒ DWDM：光を活用したリアルタイムデータ ミラーリングを実現 • 長距離接続の実現 • Extended Fabric ‒ FCIP：FCをIPでカプセリング化し、IPの ルーティング技術を用いて遠隔地にデータ 転送を実現 • FCのカプセリングにより実現 ‒ ミッションクリティカルデータストレージ のデータセンターへの統合 ‒ バックアップセンターでの集中的なバック アップ DWDM/IP データセンター2 バックアップセンター データセンター1 バックアップの統合 © 201５ Brocade Communications Systems, Inc. 19
- 20. SANがもたらすソリューション ストレージの仮想化を実現 • 課題 ‒ 増大するストレージのボリューム管理が大変 ‒データの種類により、使用するストレージを区別し、 有効利用を行ないたい ‒ 災害対策がなされていない •SANソリューション –ファブリック・アプリケーションを用いた、高速・ 高信頼性のボリューム統合管理 –データの階層管理(ILM)を実現し、使用するスト レージの区別・有効利用を実施 –ストレージ間のミラーリングやレプリケーションを、 バックエンドで実現 仮想化装置 © 201５ Brocade Communications Systems, Inc. 20
- 21. SANブート 統合ストレージからOSイメージを読み込みOSを起動し運用 • OSの起動イメージをSAN上の外部ディ スクへ配置し、サーバの「ディスクレ ス」化を実現 ‒ OSはSAN上のディスクから読み込み、OS起 動を行う ‒アプリケーション/データ領域もSAN上に保 存し共有化 ‒ サーバの変更が容易 ‒ 障害時の復旧が容易 App Data Data Data Data Data Data Data Data OS OS OS OS App 障害等で起動するサーバを変更する際には、 物理サーバとOS (ブート)ディスクの「対応づけ」を変更 SAN X Boot Boot © 201５ Brocade Communications Systems, Inc. 21
- 22. SANがもたらすソリューション ホストからストレージまでの、End to Endの管理環境へ •個々に管理する従来の管理方法 ‒ スイッチ単体の管理 • Brocade Switch標準GUI (WebTools) ‒ ファブリックの全体管理 • Brocade Network Advisor (BNA) • 統合管理を可能にする、今後のEnd to Endの 統合管理へ ‒ パートナーベンダの管理ツールと、連携強化を実 現 • ホスト部分とストレージ部分は、パートナー製品で従来 通り対応 • ファブリック部分と（Brocade） • サーバ、ファブリック、ストレージの統合管理を実現 ‒ 使い慣れた画面での統合管理を実現 WebTools / CLI Fabric Manager HBA Element Manager サーバ管理 ストレージ管理 ファブリック 管理(BNA) デ ー タ セ ン タ ー の 統 合 管 理 （ Policy-Basedorchestrator ） 各 種 サ ー ド ベ ン ダ ー の 各 種 管 理 ツ ー ル © 201５ Brocade Communications Systems, Inc. 22
- 23. SAN導入事例紹介 © 201５ BrocadeCommunications Systems, Inc. 23© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. INTERNAL USE ONLY
- 24. SAN構築事例～コアエッジトポロジ サーバ－ストレージ間のフロアが異なる場合 • 背景 ‒ 契約ユーザ数依存の為サーバ拡張数が不明 ‒サーバフロア、ストレージフロアが異なるが建屋 内FCケーブル敷設作業を減らしたい • 顧客要件 ‒ 契約数増加に応じてシステムの拡張性を止めない ようにしたい ‒ 初期投資を抑えたいが、後々増設する際にコスト 高になる建屋間FCケーブルは予め敷設したい ‒ 障害ポイントがいち早く確認できるように一元管 理を行いたい • 業種、業務 ‒ 通信業、メールシステム • 環境 ‒ OS: HPUX 11i v2, Windows 2008 ‒ Storage: ハイエンドストレージ 数台 • SANデザイン考慮点 ‒ サーバ増設時に既存システムへの影響が少なく、且つ 契約ユーザ数増加に柔軟に拡張性できるコアエッジト ポロジを選定 ‒ 建屋間のFCケーブルは敷設が高価な為、予めFCケー ブルを敷設。その為、事前にFloor Designを決め、配 置場所を確定 © 201５ Brocade Communications Systems, Inc. 24
- 25. SAN構築事例～フルメッシュトポロジ 建屋、フロアが異なる環境でも共通ストレージにアクセスしたい • 背景 ‒ 新規システム導入及び既存システムを新規Storageへ接 続したい ‒既存システムのフロアはすでに置き場所がない為、別フ ロアを用意 • 顧客要件 ‒ どのシステムでも基盤統合システムを使いたいが、建屋 が異なる、また建屋内でもフロアが分かれてしまう ‒ 5年後のサーバパフォーマンス向上、業務量増加を見越 し、広帯域のSANを作りたい ‒ SAN管理を簡易化し、FCパフォーマンス管理を実現し たい • 業種、業務 ‒ 製造業、基幹業務システム • 環境 ‒ OS: HPUX 11i v2, Windows 2008 数十台 ‒ Storage: ハイエンドストレージ 数台 • SANデザイン考慮点 ‒ 3フロアにサーバ、ストレージが分散配備されどのフロア のサーバからもストレージアクセスが必要。SAN Switchの Hop数を減らし最短経路を選択できる為低遅延アクセスが 可能なフルメッシュ構成を実施 ‒ SAN管理ツール（Brocade Network Advisor）により全ての SAN Directorの障害監視、SANパフォーマンス監視、SAN トポロジマップ表示等で一元管理を実現 © 201５ Brocade Communications Systems, Inc. 25
- 26. オンラインSANマイグレーション事例 -1 オンラインでの機器リプレースを実現 • 背景 ‒SAN Switch EOSLに伴い入替が発生 • 顧客要件 ‒ EOSLになるSwitchを業務を止めず新規SAN Switchへ移 行したい ‒ 単純なSAN Switch入替のみならずSAN統合を実現する 事で消費電力、管理工数を低減したい ‒ 簡単に大規模SANを運用したい • 業種、業務 ‒ 通信業 ‒ メール送受信、配信システム • 環境 ‒ OS: HPUX 11i v2, Windows 2008 数百台 ‒ Storage: ハイエンドストレージ 数台 ‒ スケジュール ‒ 移行作業実施期間 3ヵ月 • マイグレーション方法 ‒ 事前にサーバ、ストレージ、マルチパスソフト、アプリ ケーションのサポート環境の確認、バージョンアップ ‒ 新規SAN Switchに既存SAN Switchと同等に設定 （論理Switch, Fabre Channel Addressを割り当て） ‒ アクセスの少ない時間にてサーバ側で冗長化パスの1方を切 断し、シングルパスに変更 ‒ 新規Switchを既存ケーブル接続を切り替え、デバイスの Fabric Login状態、パスの確認、デュアルパスに変更し正常 な状態を確認 ‒ パス切り替えを実施して切り替えていないもう一方の作業 を上記同様に実施 © 201５ Brocade Communications Systems, Inc. 26
- 27. オンラインSANマイグレーション事例 -2 重要なシステムの為停止なんてできる訳がない！ • 背景 ‒仮想サーバ増加に伴い、ポート数は減ったが、既存 2Gbps環境での限界 ‒ 保守期間満了による次期ストレージ基盤構築 • 顧客要件 ‒ ストレージデータをオンラインで移行したい • 業種、業務 ‒ 金融業様 ‒ オンライン資金運用システム • 環境 ‒ OS: AIX and VMware 数十台 ‒ Storage: ハイエンドストレージ 数台 ‒ スケジュール ‒ 移行作業実施期間 1ヶ月 ‒ データ移行切り替え作業 数ヶ月 • マイグレーション方法 ‒ ストレージマイグレーションの為にオンラインにてSAN統 合を実施 ‒ SAN統合によりストレージデータレプリケーションを実施 ‒ 最終的にはサーバ保守期間満了に伴い、新規サーバへ順次 リプレースを実施 © 201５ Brocade Communications Systems, Inc. 27
- 28. SANの冗長構成 • SANとLANの冗長に対する違い © 201５Brocade Communications Systems, Inc. 28
- 29. LAN冗長構成の常識 • 二重化された機器は全て接続しておく ‒ 物理的に全て接続された経路を作る ‒どこか切断しても迂回経路を確保 ‒ Ethernetはスイッチの先のリンクが 切れてもサーバは認識できない WAN Server Edge Switch Core Switch 単一ネットワークを構成 この経路が切断しても サーバには分からない チーミングによるアク ティブ－スタンバイ構成 サーバに直接つながって いる経路が切れたときに 切り替わる © 201５ Brocade Communications Systems, Inc. 29
- 30. SAN冗長構成の常識 • 物理的に独立した複数の経路を確保する ‒ 経路が切れた場合、片方のネットワークがダウ ンした場合、マルチパスドライバで経路を切り 替え継続運用可能 ‒SANを“ネットワーク“ではなく、サーバとスト レージを直結している”経路”とみなします Storage Server SAN Switch SAN Director マルチパスドライバ ファブリック上の経路断を 検知して経路を切り替え 独立した複数ネッ トワークを構成 ＝ Server Storage この経路が切断すると ファブリック全体に通 知される © 201５ Brocade Communications Systems, Inc. 30
- 31. 冗長性と回復性 • 冗長性(Redundancy) ‒ 独立したFabric を複数配備し、アクセスパスの冗長性を確保 する ‒ システム全体の冗長性はOSのマルチパスドライバーの領域 • 回復性(Resiliency) ‒ Fabric 内のデザイン ‒ Fabric としての Single Point of Failure が無い設計 • SAN デザインの大原則 ‒ 冗長性は必ず確保する • ファブリック内の全てのスイッチでファブリックサービス(ゾーニングDBな ど)を共有しているため、デバイスが物理的に異なるスイッチに冗長接続さ れていたとしも、ゾーニングの設定ミスなどのファブリック内全スイッチに 影響を及ぼすような障害には対応できない。 ‒ Resiliency は可能であれば確保する • 大規模なファブリックでは重要な要素 Fabric A Fabric B 経路冗長構成 回復性のある ファブリック 経路切替は マルチパス ドライバー © 201５ Brocade Communications Systems, Inc. 31
- 32. • SANはサーバとストレージのネットワーク接続概念 • ストレージアクセスは高信頼・広帯域・低遅延が最重要 •OSから見ればブロックストレージは全てDAS接続（１対１） ・・・と、考えればSANは難しくないハズ まとめ
- 33.