前回「バックアップ統合（LANフリーバックアップ）」はSANのスモールスタートの第一歩としてのバックアップ統合（＝LANフリーバックアップ）を、必要となるパーツや導入方法を具体的に挙げながら紹介した。今回は、SANをさらに拡張し、いよいよストレージ装置の導入やSANの冗長化の手法を具体例とともに解説したい。
「SANの拡張＝ ポート増加？」
まずは前回のおさらいから。
『ある中堅企業K社のシステム管理者S氏は、バックアップ管理の負荷を軽減するため、SANのインフラを導入することにした。SANを導入してテープ装置を共有することにより、サーバごとにバックアップを取るという面倒な作業から解放されることができ、運用担当者の残業時間を減らすことができた』
と、ここまでは前回説明したとおりである。ただ、S氏が抱えていた問題は実はこれだけではない。前回はスモールスタートということで、多くのシステム管理者にとって最も大きな問題である「バックアップ」という切り口でSANを導入したが、別にシステム管理者はバックアップだけに問題を抱えているわけではないのである（図1）。
前回K社に対してSAN導入を提案し、構築を行ったシステム・インテグレータが再度S氏にヒアリングを実施したところ、S氏の口から以下のような問題や要望を聞くことができた。
「各部門ごとにファイルサーバを置いているが、数が多過ぎて管理が非常に面倒だ。サーバの保守費もかなりの額になっているので、これを減らしたい。また、これらの部門サーバは同一スペックのものを使用しているが、部署によってディスクの使用量がバラバラで効率的でない。部門サーバ間で簡単にディスクを融通できないものだろうか……。
また、バックアップについてはLANの負荷が減って作業負荷も減ったのだが、大量のデータをテープ装置にバックアップするのはやはりかなりの時間がかかるし、テープだとリストアに時間がかかってしまうのでその間は業務が停止することになってしまう。最近はディスクが安くなってきているので、ディスクをバックアップ装置として使ってもいいかもしれない。テープのバックアップは別に用意しておいて、どこかの倉庫にでも保管しておこう」
多くの場合、SANを導入することによってある問題は解決され、同時にSANに対する新しい要望が出現する。それらを解決するためにはより多くの機器を接続したり、SAN自体の信頼性を向上させることが必要となる場合もある。多くの場合、SANの拡張は結果として「接続する機器の増加 → ポート数の増加」となる。
ただ、それはあくまで情報システムの問題をSANにより解決した「結果」であって、SANの拡張をポート数の増加という「量的」側面でとらえないでいただきたい。SANの拡張は「SANによって解決できる顧客の要望の広がり」であるという「質的」側面の方がずっと重要であって、それだからこそSANというインフラに投資する価値があるのだ。
必要となるパーツ
前回はテープ装置とサーバのみを接続したSANであったが、S氏の要望を満たすために、システム・インテグレータは今回ストレージ装置を追加導入し、各サーバのデータをストレージ装置内に移行することにした。ストレージ装置の導入によって、下記のメリットを享受することができる。
- ストレージ装置でディスクを一元管理できるため、サーバ間でディスクを柔軟に再配分できる。
- 各サーバから「データ」を分離できるため、サーバの更改が容易になる。
- ディスク拡張がオンラインで簡単に行えるため、保守・運用が簡単になる。
- ストレージ装置の持つ機能により、データバックアップ時間の短縮化が実現する。
ストレージ装置は前回構築したSANに追加することになる。前回のシステムにストレージ装置を追加したものが図2である。
ただ、この構成には実は大きな問題点がある。前回はSAN上を流れるデータが（業務に直結しない）バックアップデータのみであったので、ネットワークの信頼性にまで気を配る必要はそれほどなかった。しかし、重要データを外部ストレージ装置に格納し、企業活動に必要なデータがSAN上を流れるようになると、ファイバチャネルスイッチ（以下、スイッチ）や光ファイバケーブルの障害は直接、業務の停止につながってしまう。
この時点で、SANはすでに「業務に不可欠なインフラ」になったと考えてよい。業務に不可欠なインフラであれば、当然そこには高い信頼性が求められる。つまり、「インフラの冗長化」が必要になってくる。これを実現するのが「デュアル・ファブリック」である。
SANの冗長化＝ 「デュアル・ファブリック」
前回紹介したシステムでは、スイッチは1台しかなかった。この場合、スイッチや光ファイバケーブルに障害が発生すると、サーバはストレージ装置、すなわちディスクにアクセスすることが一切できなくなってしまう。SANが基幹業務に用いられていればいるほど、この間のシステムダウンの影響は大きくなる。またスイッチが1台しかなければ、スイッチのメンテナンス作業を行うこともできない。
これを回避するために「デュアル・ファブリック」構成を組む。デュアル・ファブリックとは言い換えると「SANの二重化」である。デュアル・ファブリック構成によって、片側の経路にあるスイッチやケーブルに障害が発生したとしても、自動的にもう片方の経路に切り替えることができ、サーバとストレージのデータ通信の停止を防ぐことができる。
上記を踏まえて、デュアル・ファブリック構成に修正したものが図3である。なお、ファブリックという用語の説明に関しては、拙著「特集：IP技術者のためのSAN入門 Part. 3 『ファイバ・チャネルとは？』」を参照していただきたい。
デュアル・ファブリックにおいては複数のパス（経路）をサーバ上のソフトウェアで制御する必要がある。これらのソフトウェアはストレージ装置のベンダもしくはソフトウェアベンダから提供されている。これらのソフトウェアはストレージ装置に依存するので、導入前にベンダに確認するようにしておきたい。
ストレージの導入
ストレージ装置を導入する際には、以下の手順を踏む。実際にはストレージ装置を販売しているベンダの担当者が実作業を行う部分が多いが、作業の内容を理解しておくことはSANの仕組みを知るうえでも重要である。
1． ストレージ装置の設置
ストレージ装置の設置環境には十分注意する。温度や湿度、ほこりなどに対してはディスクは特に敏感なので、気を配っておかなければならない。また、大型のRAID装置になると200V（単層／3層）の電源が必要になる場合がある。分電盤の工事が必要になる場合も多く、ベンダにあらかじめ確認しておく必要がある。
一般的にストレージ装置は2つの電源ユニットを持ち、電源の冗長化が可能である。電源系統を分けるなどして、電源障害時にも対応できるようにしておきたい。また当然のことではあるが、大型のRAID装置になるほどファンの音が騒々しい。専用のマシンルームに設置する場合であれば問題ないが、消音装置を提供しているベンダもあるので必要に応じて活用してほしい。
2． ストレージ装置へのケーブル接続
ストレージ装置を設置した後には、光ファイバケーブルを接続する。光ファイバケーブルはスイッチに接続することになる。また前回の繰り返しになるが、ケーブルのコネクタ形状や送受信の方向には十分注意を払う。
3． ストレージ装置の動作確認
初期動作確認を行う。ここはストレージ装置の機種に依存する部分なので詳細は割愛するが、ストレージ装置にハードウェア上の初期不良がないか、あるいはRAID構成や論理ユニット（LUN）の構成に問題がないかどうかなどを確認する。
4． サーバの設定
ストレージ装置が単体で動作できてもサーバから認識できなければ意味がない。ストレージ装置とサーバホストを結び付ける（バインディング）設定をサーバ側で行う必要がある。サーバ上でSANのインターフェイスとなるのはHBAであり、HBAの環境設定ファイルとSCSIドライバ定義ファイル（Solarisの場合は「/kernel/drv/sd.conf」ファイル）を変更することになる。HBAによって多少異なるが、Solarisの場合、一般的には以下のようにサーバ側の設定を行う。
（1）HBAの環境設定ファイルで以下の設定を行う。
- FabricモードあるいはLoopモードの選択。
- OSのターゲットID（Solarisの場合は“cXtX”で表現される）とRAIDコントローラのWWNのバインディング。
以下はEmulex社のHBAの環境設定ファイルである「/kernel/drv/lpfc.conf」ファイルの記述例である。
- FabricモードとLoopモードの選択
topology=2 （Point-to-point Mode ＝ Fabricモード）
- WWPN（World Wide Port Name）とターゲットIDのバインディング（例）
fcp-bind-WWPN="2100123456789abc:lpfc0t0", "21000020370c2855:lpfc0t1", "2100122222222222:lpfc2t2"; fcp-bind-WWPN="2100123456789abc:lpfc0t0", "21000020370c2855:lpfc0t1", "2100122222222222:lpfc2t2";
（2）SCSIドライバ定義ファイルである「/kernel/drv/sd.conf」ファイルを以下のように設定し、ストレージとOSのターゲットIDを関連付ける（Emulex社のHBAの場合の例）。
name="sd" parent="lpfc" target=0 lun=0; name="sd" parent="lpfc" target=0 lun=1; ．．．
5． ゾーニング
まず、「ゾーニング」という言葉を説明しよう。
K社のシステムのようにSolarisとWindowsの混在環境の場合、ストレージ装置を共有することによる大きな問題が存在する。例えばストレージ装置内のあるボリュームをSolarisのホストで利用し、データを書き込んだとしよう。その後にWindowsホストを起動すると、Windowsホストの場合はOS起動時に「自分から見える」すべてのディスクにアクセスしようとするため、Windows形式のデータがSolarisのデータを上書きしてしまう危険性がある。データが上書きされた場合は、それまで使用していたSolarisホストからはそのボリュームに二度とアクセスできなくなり、データが消失してしまうことになる。
このように異機種環境下でストレージを共有している場合には、上記のようなデータ損失の危険性を避けるために、スイッチ上でサーバとストレージのグループ化を行う。これが「ゾーン」と呼ばれるものであり、ゾーンを作成することを「ゾーニング」という（図4）。異なるゾーンにあるデバイスは認識できないようにスイッチが制御するため、結果としてデータの安全性を確保することができる。
このように、ストレージ共有においてゾーニングは非常に重要な技術であり、多くのSANシステムで利用されている。ゾーニングはソフトウェアレベルで行うことが多いが、Brocade社のスイッチではハードウェア（ASIC）レベルでのゾーニングを行うことができ、より高い安全性を確保できる。
Brocade社のスイッチでゾーンを行う場合、以下の2種類のゾーニング方法がある。
- スイッチのポートレベルでのゾーニング
- デバイスのWWNレベルでのゾーニング
（1）のポートレベルでのゾーニングの場合、スイッチのポート単位でゾーニングの設定を行う（図5）。この場合、ゾーンの対象となるポートに接続するデバイスに依存しないゾーン設定が可能となるが、ゾーンがポートに依存するため、デバイスをほかのポートに差し替えて利用することができず、運用上の柔軟性が低い。例えば、障害時などにほかのポートに接続変更した際にゾーン情報も変更しなければならなくなる。
一方、（2）ではデバイス固有のWWNでゾーニングを行うため、スイッチのポートには依存しないが、デバイス障害などで物品を交換した場合には、ゾーンを再設定しなければならない（図6）。
これら2つのゾーンはそれぞれ長所、短所があるため、想定されるシステムの運用形態に合わせて設定を行う必要がある。また、ゾーニング情報を適切に管理するためには、スイッチの各ポートに接続されているデバイスのWWNを管理表（図7）にまとめておくとよいだろう。
| ポートNo | 接続デバイス機種名 | 接続デバイスホスト名 | 接続デバイスのWWN |
|---|---|---|---|
| 0 | |||
| 1 | |||
| 2 | |||
| 3 | |||
| 4 | |||
| 5 | |||
| 6 | |||
| 7 | |||
| 図7 8ポートスイッチの場合のポート管理表（例） | |||
6． スイッチからの接続性の確認
ゾーニングが完了したら、スイッチから正常性の確認を行う。状態確認の際には前回説明した“switchshow” コマンドを利用する。ゾーニング情報を確認する際には上記のように“cfgshow”コマンドを利用するか、もしくはGUIを利用する。
7． 経路制御ソフトウェアの導入
上記のとおり、デュアル・ファブリック構成において必要となるソフトウェアである。ストレージ装置に依存する部分があり、各ストレージ装置に適したソフトウェアをインストールする。このソフトウェアの機能により、パス・フェールオーバーや複数パスでの同時通信などの経路制御の機能が実現する。
8． 複製ボリューム管理ソフトウェアの導入
RAID1によるハードウェアレベルでのボリュームのミラーリングに加え、さらに「第3のボリューム」を作成するソフトウェアである。第3のボリューム用に余計に物理ディスクが必要にはなるが、このボリュームは自由に同期／切り離しを行うことができるため、データのバックアップやテストデータなどに自由に利用することができる。この機能を実現するソフトウェアとしてはEMC社の「Time Finder」が有名であるが、最近は多くのストレージベンダが同様のソフトウェアを提供している。これらのソフトウェアも基本的にストレージ装置に依存する。
9． サーバからの接続性の確認
サーバからのストレージ装置の確認は、Solarisの場合は“format”コマンドで行う（図8）。Windows 2000の場合は「コンピュータの管理」の中の「ディスクの管理」で確認する（図9）。
10． SAN上のディスクへのアクセス
よく尋ねられる質問の中で、「SAN上のディスクにアクセスする際に特別なコマンドなどが必要になるのか」というものがある。この点は勘違いされていることが多いようなので、説明しておきたい。
SANの場合、ディスクへのアクセスは内蔵ディスクやDASのディスクとまったく同じである。従って、Windowsであれば普通に「G:\」などのようにアクセスできるし、SolarisなどUNIX OSであれば、パーティションをマウントして、「/usr」「/home」といった形でアクセスできる。要は非常に容量の大きいディスクが存在していると考えればよいのである。
なぜこのようなことが可能なのかというと、SANはあくまでも「ネットワーク」であり、ファイルシステムには依存しないからである。SANにおいてはその中にNTFS（Windows NT/2000）でフォーマットされたシステムがあろうが、UFS（Solaris）でフォーマットされたシステムがあろうが一切関係ない。これに対してNASの場合は、第1回（スモールスタートからはじめるSAN導入）で触れたように専用のファイルシステムが必要となる。NASの場合はTCP/IPのレイヤの上にNTFSやCIFSといったネットワークファイルシステムのレイヤが存在し、それによってデータ伝送が可能となる。NTFSやCIFSはいずれもクライアント／サーバの仕組みを採用している。例えばWindowsクライアントがUNIXサーバにアクセスする場合、
- Windows用のNFSクライアントソフト
- UNIX用のCIFSサーバソフト
のいずれかが必要となる。マシン台数の関係から後者が選択されることが多いが、この代表的なソフトウェアがフリーソフトの「Samba」である。
データの移行
ストレージ装置の導入が完了したら、内蔵もしくはDAS上のディスク装置からSAN上のストレージ装置へデータを移行する。筆者はよく「データ移行はどのように行うのか」と尋ねられるのだが、これはシステムによってさまざまであり、ひとまとめにして語ることができるようなものではない。K社の場合は以下のような方針でデータを移行した。ここで紹介している方法が必ずしも読者の皆様のシステム環境にとって最適とは限らないが、一例として参考にしていただきたい。
■データベースサーバ（BUMONDB01 : Oracle 8i）
Oracleには大きく分けて、以下の3種類のファイルが存在する。
- 制御ファイル
- Redoログファイル
- データファイル
制御ファイルはOracleの起動にも必要なファイルであり、多重化しておくことが必須であるため、ローカルディスクとSAN上のストレージに分散して格納した。RedoログファイルはSAN上のストレージに格納するが、ほかのファイルと違ってシーケンシャルに書き込まれるため、パフォーマンスを考慮して物理ディスクを分けて格納することにした。データファイルはデータベースのデータを格納しているファイルであり、サイズも大きくなる。従って、データファイルはSAN上のディスクに格納した。
Oracleのファイルの移動方法に関する詳細は、Oracleのマニュアルや関連する参考書などを参照していただきたい。
■WWWサーバ（BUMONWEB01：Apache）
WWWサーバのデータ移行は、基本的にはHTMLファイルやイメージファイルの移動である。従って、ローカルディスクのデータを移動させるイメージで、SAN上のディスクへファイルを移動させればよい。K社の環境ではファイル数もそれほど多くなかったため、今回はごく単純にUNIXの“mv”コマンドでファイルを移動させた。
■ファイルサーバ（BUMONFS01：Windows 2000 Server）
K社のサーバにはWordやExcelなどかなり多くのファイルが存在しており、S氏もファイルの移動方法に頭を悩ませてはいたが、最終的にはWWWサーバと同様に、単純にドライブ間でファイルを移動させた。
■グループウェア（BUMONGW01：Exchange 2000 Server）
Exchange 2000 Serverでは、データベースファイルの移動に「Exchangeシステムマネージャ」を使用した。詳細は、Exchange Serverのマニュアルや関連する参考書などを参照していただきたい。
サーバの集約
ストレージ装置を導入してデータの集約が可能になると、いままで分散していたサーバを集約することも可能となる。例えばファイルサーバなどがいい例だ。部門単位でファイルサーバを用意していたものを、SAN上のストレージ装置にデータを集約すれば、ファイルサーバを減らすことができる。
サーバ集約、つまり「サーバ統合」によって以下のメリットを享受することができる。
- サーバ設置面積の減少
- サーバ使用電力の減少
- サーバハードウェアの保守コストの減少
- サーバにインストールされていたソフトウェアの保守コストの減少
サーバ統合は、投資対効果（ROI：Return On Investment）が非常に高いソリューションなのだ。
今回までで一通りのSANが出来上がった。来月の記事では出来上がったSANをいかに保守・運用していくかについて解説していく。次回の記事もぜひ楽しみにしていただきたい。
Copyright © ITmedia, Inc. All Rights Reserved.