【SAN技術資料】ストレージネットワーク基礎講座

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

Download Report