SAN運用管理の効果的な方法とは？：SAN導入実践テクニック（4）

　前回「SAN拡張のセオリー（デュアル・ファブリック）」ではSANのスモールスタートの第一歩としてのバックアップ統合（＝LANフリーバックアップ）の後に、SANを拡張していく際のセオリーとしてデュアル・ファブリックについて説明した。SAN導入実践テクニックの最終回となる今回は、SANの管理とは何かを運用と管理の点から解説していく。

●SAN管理とは何か

　前回までの連載で、K社のSANがまずはひととおり完成した。しかしSANに限らず、ITインフラというものは構築したら終わりというわけではない。システム構築後は当然、運用・保守を行っていく必要がある。

　K社のシステム管理者であるS氏は、ここで次の悩みを抱えることになる。それは「SANの管理とは一体どんなもので、どのように行えばいいのか」ということである。SAN上では企業活動に不可欠な重要データが流れており、そこには高い信頼性が求められる。にもかかわらず、SANの運用・保守はベンダに任せきりで自分たちでは何も把握していないというユーザーが非常に多い。筆者も「SANはブラックボックスだ」「ファイバチャネルスイッチ(以下『スイッチ』)があるけれども、監視の仕方がよくわからない」といったユーザーの声をよく耳にする。

　K社の場合、すでにSANは業務に不可欠なインフラとなっている。業務に不可欠なインフラであれば、当然ユーザー自身もそれらに対する知識を持っていなくてはならない。運用保守をベンダにアウトソーシングしている場合もあるだろうが、ほとんどの場合、障害を最初に発見し、最初に障害対応するのはユーザー自身だ。したがって、ユーザー自身の手でSANインフラの管理や障害時の対応をまとめておくべきである。

　SAN管理は「ストレージ管理」と「ネットワーク管理」の2つの側面からとらえることが可能だ。ストレージ管理としては、「データ容量管理」「バックアップ管理」などが挙げられる。一方のネットワーク管理としては、「アクセス管理」「経路管理」などが挙げられる。また両方に共通するものとして「パフォーマンス管理」「障害管理」などを考慮しておくべきであろう。これらを統合して一元的に管理すれば、より効果的にSAN管理を行うことができる。

• LAN／WANネットワーク管理
• サーバリソース管理
• SANネットワーク管理
• ストレージリソース管理
• アプリケーションソフトウェア管理

●SAN管理者（ストレージ管理者）に求められる能力

　SANはその名の通りネットワークであるが、その上ではファイバチャネルプロトコルを介して、データベースやグループウェア、ストリーミング配信などのブロックデータの転送が行われている。

　 前回紹介したようにこれらのデータは内蔵ディスクにアクセスするのと同じイメージで動作するため、TCP/IPやイーサネットのインフラに比べてOS、特にファイルシステムやボリュームとのかかわりが強い。したがって、SANの管理者には「ネットワーク管理能力」と「サーバ／ストレージ管理能力」の両方のスキルがあるとよい。

　SANにおける障害は「ドライブが見えない」「マウントポイントにアクセスできない」といった形で現れてくるため、その原因を切り分けて問題を解決するには、ファイバチャネルネットワークだけでなくOSに関する知識も必要となる場合がある。これはSANが「データ」や「ファイル」といったOSの核となる部分を扱っているからである。

●SAN管理、LAN管理、サーバ管理……

　ITシステムを構成する部品はさまざまだ。LAN／WANネットワークインフラ、サーバインフラ、SAN／ストレージインフラ、市販ソフトウェア部品、開発ソフトウェア部品などである。システムの規模が小さければ単一もしくは少人数の管理者でこれらすべてを管理することができるだろうが、システム規模が大きくなるに従って、それぞれの「部品」ごとに管理者を分ける必要がでてくる。これらの「部品」を統合して管理するのか、あるいは別々に管理するのかはシステムの運用形態や規模に依存する。

　管理者が少ないシステムでは、単一のインターフェイスからすべてを管理できる方がいいだろう。一方、人的リソースが十分にある場合は、それぞれの管理を別に分けたほうがいいかもしれない。

　最近の多くのシステム管理ソフトウェアには統合監視機能があり、LAN／WANネットワークからストレージデバイスまでを単一のコンソールから管理できる機能を提供している。だが、その機能をすべて使う必要はない。管理すべき「部品」に合わせて最適な管理ソフトウェアを選択すれば、ITシステム全体からみればより効率的に管理できることもある。管理作業に専門性をもたせることが可能になり、結果としてより高いレベルでのシステム管理を行うことができるのである。

●SAN管理の方法

　SAN管理といっても特別に考える必要はない。一般的に言われている多くのシステム管理手法はSAN管理においても同じように適用できる。ここでは例として、Brocade社のスイッチで構成したSANを管理手法を具体例を挙げて説明したい。

1． コマンドライン（CLI）による管理

　本連載でもすでに何度か紹介しているが、Brocade社のスイッチには管理用にシリアルインターフェイスが備わっている。ここからスイッチにアクセスして、コマンドライン上から各種コマンドを発行することが可能である。また、イーサネットポートも備えているため、初回ログイン時にIPアドレスを設定しておけば、Telnetによる遠隔操作も可能である。

2． SNMPによる管理

　 Brocade社のスイッチはSNMPエージェント機能があり、SNMPのトラップをSNMPマネージャに発行することが可能となっている。また、各種MIBに対応しているためSNMPマネージャにMIBをインストールしておけば、スイッチ特有の機能の管理も可能である（画面1）。一例としてhttp://www.xolution.ch/mrtg/にフリーのSNMPマネージャソフトである『MRTG』をBrocade

SilkWorm 2800用に設定したものが紹介されているので、参考にしていただきたい。

画面1　SNMP設定画面（WebTools）

3． Syslogによる管理

　Brocade社のスイッチは、Syslogサーバにログを出力することが可能である。また、出力するログのレベルを設定することもできる。スイッチ側ではコマンドラインもしくはWebTools上でSyslogサーバのIPアドレスを指定しておく（画面2）。一方、Syslogサーバ側では、スイッチのログを出力するようにあらかじめ「/etc/syslog.conf」ファイルなどを設定しておく（画面3）。

画面2　『スイッチにおけるSyslogサーバの設定例(WebTools)』

画面3　『SolarisのSyslogサーバへのログ出力例』

4． Webブラウザによる管理

　すでに本連載で何度か紹介してきているように、Brocade社のスイッチでは、Webブラウザ上でスイッチの設定や管理を行う『WebTools』というソフトウェアがある。このツールはJavaを利用してリアルタイムにスイッチの状態を表示することができ、また、スイッチの基本設定やオプションソフトウェアのライセンス管理、ゾーニング設定、ネームサーバの管理なども行うことができる。

5． 専用アプリケーションによる管理

　Brocade社は大規模、複数ファブリックの管理のために『Fabric Manager』というソフトウェアを提供している。このソフトウェアにより大規模SANにおける多数のスイッチを一元的に管理することができる。このソフトウェアは専用アプリケーションとして管理端末上にインストールして使用する。前述のWebToolsの機能を包含し、また複数スイッチの再起動や時刻同期の機能などを備えている（画面4）。

画面4　『Fabric Manager』

6． システム／ネットワーク管理ソフトウェアによる管理

　ユーザーの声を聞くと、SANの導入時点ですでに何らかのシステム／ネットワーク管理ソフトウェアを導入している場合が多い。これらのユーザーにとっては、SAN管理のために新たなソフトウェアを導入して、その使い方を習得することは大きな手間だ。したがって、Brocade社ではスイッチ管理用のAPIを用意して多くの管理ソフトウェアベンダに提供することにより、システム／ネットワーク管理ソフトウェアとシームレスに統合させることを可能としている。

　現在、50を越えるシステム／ネットワーク管理ソフトウェアベンダがBrocade社のAPIを採用しており、それぞれの管理ツールに統合している。これらのソフトウェアではグラフィカルにSANの状態を表示したり、障害をリアルタイムに表示したりすることができる。また、HBAやスイッチ、ストレージなどのデバイス単位で関連する設定を行うことができる（画面5）。

画面5　『システム／ネットワーク管理ソフトウエアの一部』

SANのパフォーマンス問題

　SANのインターフェイス（ファイバチャネル）は、現在利用されている大部分のSCSIの規格に比べて高速である。従って、SCSIのDASからSANに単純に移行するだけでも、ディスクアクセスのパフォーマンスは向上することが多い。さらに、前回紹介した経路制御ソフトウェアなどと組み合わせれば、さらに高速にI/Oを処理することができる。また、仕組み上高速化に限界が見えるSCSIと違って、ファイバチャネルは現時点で10ギガビットへの対応も予定されている（10ギガビットのファイバチャネル技術の標準化作業は進行中）。

　しかし、高速化は無限ではない。データアクセス量が非常に多ければ、たとえSANのインフラであってもパフォーマンス劣化が発生する可能性は否定できない。またカスケード接続するなどして、複数スイッチによるネットワークの形態をとっている場合には、スイッチ間のリンク(Inter

Switch Link：ISL)がパフォーマンス上のボトルネックになる可能性がある。

　このような状態になる前に、SANの「ネットワークとしての」パフォーマンスを把握しておく必要がある。Brocade社では『Advanced

Performance Monitoring』というツール（画面6）を提供しており、それを使用することでSANのネットワーク上のパフォーマンスや、使用しているネットワーク帯域をポート単位で把握することができる。また、それ以外のツールでも、例えば『IOMeter』のようなツール（画面7）を使用すれば、SANに擬似的な負荷を発生させ、その際のパフォーマンスを確認することができる。

画面6　『Advanced Performance Monitoring』

画面7　『IOMeter』

　これらのツールを使用して、サーバに搭載するHBAの枚数やISLの数を決定することが重要である。また、多くのネットワーク管理者の方にとっては当たり前の話だと思うが、ネットワークトラフィックは常時変わるものだ。これはSANの場合でも同じである。したがって、こういったパフォーマンス測定は定常的に行っていかなければならない。

　今回まで4回にわたりSANの導入から管理に至るまでを一通り解説してきた。本連載は今回で終了するが、今回の連載が読者の皆様のSANに対する理解を深め、SAN導入のきっかけとして役立てば嬉しい限りである。