ストレージ・ネットワークの拡張：上司のためのストレージ・ネットワーキング （5）（1/2 ページ）

ストレージ・ネットワークを利用していると、いずれ拡張しなければならないことが多い。そのときになってあわてないために、今回はストレージ・ネットワーク拡張の方法について説明する

[辻 哲也，ブロケードコミュニケーションズシステムズ]

　前回は「ストレージ・ネットワークの管理」と題して、ストレージ・ネットワークの管理手法の中でも代表的なものを紹介した。今回は、初期導入したストレージ・ネットワークを拡張するきっかけや手法などを解説していきたい。

ストレージ・ネットワーク拡張の背景

　初めに、ストレージ・ネットワークを拡張する理由についてSAN（Storage Area Network）を例に考えてみよう。SANを拡張する契機としては、主に以下の2つの理由が存在する。

　例えばサーバとストレージ間にSANスイッチ（FCスイッチ）が1台だけ存在するような小規模なSAN構成であっても、多くの場合そこに接続されるデバイスの台数が増えていき、SANが拡張していく。ここでいう「デバイス」とはサーバとストレージの両方を指すが、筆者が知る限り、特に日本ではサーバ台数の増加によってSANを拡張することが多い（図1）。SANを一度導入すると、ユーザーは概して「共有ストレージをより多くのサーバで使いたい」と思うようになるものだ。共有ストレージはその名のとおり、より多くのサーバから使用されるほどその効果を増すわけだから、このような形でSANが拡張するのは当然だし、また正常な発展であるともいえる。

図1　サーバ台数の増加に伴うSANの拡張

　もう1つの理由は、このような小規模な複数のSAN同士の「統合」である。部門単位あるいはシステム単位でSANを導入していくと、企業内の各所にこのような「点在化したSAN」が存在することになる。このようなSANを「SANアイランド」と呼ぶが、多数のSANアイランドが存在する企業では、ストレージ機器への重複投資が行われているだけでなく、ストレージおよびSANの管理も重複していることになる。

　このような｢重複した」機器コストと管理コストは、SANアイランドの数が増えるほど大きくなり、企業全体で見るとその額は莫大である。従ってこのような管理コストの無駄を抑えるために、SANアイランド同士を統合することも多い（図2）。上述のとおり共有ストレージはより多くのサーバから「共有」されるほどその価値を増し、特にテープドライブのようなバックアップストレージではその効果は顕著だ。従って、複数のSANを統合することにより、パフォーマンスやデータの重要度などに合わせてストレージを使い分け、企業レベルでストレージ資源の全体最適化を実現することが望ましい。

図2　SANアイランドの統合

　近年はディザスタ・リカバリ（Disaster Recovery:DR）システムのインフラとしてSANを活用するケースも増えている。ディザスタ・リカバリシステムを構築する際には、バックアップデータの一元化とSANインフラの統合は不可欠な要素だ。なぜなら、バックアップとSANの一元化が行われていない場合はSANインフラごとにDRシステムが必要となり、いくらコストを掛けてもきりがないからである。

　つまり、DRシステム導入まで視野に入れてSANを考えると、

1. 小規模にSANを導入
2. バックアップを一元化するために、SANインフラを拡張
3. SANインフラをDRに活用

　という発展形態を見て取れる。DRやBCP（事業継続計画：Business Continuity Plan）を真剣に検討する企業が増えるに従い、WAN回線の低価格化と広帯域化に歩調を合わせる形で、上記3の段階までSANインフラを発展させている事例も多くなってきている（図3）。

図3　ディザスタ・リカバリのインフラとしてのSAN

　さらに「1Uサーバ」や「ブレードサーバ」といった、新しくかつ多様なサーバインフラの登場もSANの拡張に拍車を掛けている。サーバ密度が高いなどメリットが多いことや、近年社会問題化している企業での情報漏えい対策などのため、ブレードサーバ等を利用する企業は増加する一方である。ブレードサーバ（PC）環境ではブレード枚数が飛躍的に増加する。そこで保守性や耐障害性を考慮してOS領域、アプリケーション領域をすべて外部ストレージに配置し、「SANブート」構成を採用することが極めて有効である。この場合、外部／共有ストレージは不可欠の要素となる（図4）。

図4　ブレードサーバとSAN