拡大するSANとそれを実現する最新技術SAN導入実践テクニック(5)

» 2003年05月09日 00時00分 公開
[辻哲也ブロケード コミュニケーションズ システムズ]

 今日多くのユーザーでSANが初期導入されている一方、先進ユーザーではそれをさらに大規模化して、巨大なSANインフラを作り上げる事例が出てきている。SANは初期導入の時期を経て、拡張の段階に達してきているといってもいいだろう。本稿では、SANが拡大するに従って表面化してくる課題とそれらを解決する方法と技術について、現在提供されている、もしくは今後登場するであろう技術に照らし合わせて解説していく。

1. 遠隔地へのデータバックアップおよびリストア

 「大量のデータを効果的にバックアップするにはどのような方法を取ればいいのか」、また「バックアップを取ったデータを、障害時に迅速にリストアするにはどのように行えばいいのか」という課題は、多くのシステム管理者が共通に抱えているものである。システムのバックアップおよびリストアへの対処は、「特集:SAN導入実践テクニック(第2回)」でも説明したとおり、ユーザー企業がSANを検討、導入する一番の理由にもなっている。SANを導入することでバックアップ作業負荷を軽減し、バックアップ時間を短縮することができる。

 一般に、バックアップ作業はテープ装置を用いて行うわけだが、いろいろなユーザーから話を聞くとバックアップテープ、すなわち「バックアップデータ」をディスク装置と同じ場所(サイト)に保管しているユーザーが案外多い。ディスク装置と同じ場所にバックアップデータを保管していた場合には、災害などによりサイト自体が破壊されてしまうとバックアップデータも一緒に消失してしまうことになる。

 このような事態を避けるためにはバックアップデータを外部、しかも離れた場所に保持する必要がある。外部に保持したデータを復元できるようにしておくことで、最大限ビジネスの継続性を確保するわけだ。

 災害などによりITシステムに対する障害が発生した場合に、ビジネスのダウンタイムを“ゼロ”にすることは極めて困難である。ただ、サイト冗長化などの手法を組み合わせれば、ダウンタイムを極小化、最小化することは可能である。その際に注目すべきは、以下の3点である。

  1. データをディスクもしくはテープデバイス上に、「冗長化」して保持していること
  2. バックアップデータを「遠隔地」に保持していること
  3. 保持しているバックアップデータからシステムを「復旧」する手段を確立していること
画面1 ディザスタ・リカバリのポイント 画面1 ディザスタ・リカバリのポイント

 このような考え方を基にして、システムとして上記を実現するのが「ディザスタ・リカバリ」である。その名のとおり「リカバリ」であるからデータだけではなく、システムを復旧できるものでなければならないのだが、まずはデータを消失させないということが何よりも大切である。ハードウェアやソフトウェアなら買い直すことはできるが、失われたデータは二度と復旧できないからだ。業務に直結するデータであれば、絶対に失うことはできない。

 ここではディザスタ・リカバリのレベルとして、以下の4つのパターンを紹介する。おのおののレベルでは「システム復旧時間」と「システム構築・運用に伴う費用」が異なる。この2つはトレードオフの関係があるため、各ユーザーは自分たちの保有しているデータの重要度を見極めたうえで、採用するレベルを決定する必要がある。

●テープ装置の外部保管

 バックアップ作業で保存したテープを外部の倉庫に保管する。テープの移動手段としては、トラックやバイク便などを利用する。バックアップ用のサイトやストレージ装置を保有する必要がないため費用はそれほど掛からないが、システムのリストア時にはテープを倉庫より運び出してからリストア作業を行わなければならない。テープの輸送時間およびテープからのリストア時間を考えると、トータルのシステム復旧時間は非常に長くなることを覚悟しておかなければならない。

画面2 テープ装置の外部保管 画面2 テープ装置の外部保管

●リモートテープバックアップ

 リモートサイト上のテープ装置にバックアップデータを取得する。オンラインで作業を行うため、単純な外部保管に比べるとバックアップおよびリストアの時間を大幅に短縮させることができる。しかしI/Oが低速なテープ装置でバックアップとリストア作業を行っているために、やはりある程度の作業時間は必要になる。

画面3 リモートテープバックアップ 画面3 リモートテープバックアップ

●リモートディスクバックアップ

 ソフトウェアのミラーリング機能またはRAID装置のレプリケーション機能を使って、リモートサイトのストレージ装置にデータをコピーしておく機能である。保護するデータの重要度に応じて、同期ミラーリング(レプリケーション)もしくは非同期ミラーリング(レプリケーション)を行う。これらは通常、ボリューム単位で行われる。

 ここで「同期」と「非同期」の違いを解説しておこう。「同期」処理とは、ローカルとリモートのストレージ装置ともにデータ書き込みが完了したことを確認してから、サーバが次のデータ書き込みを行う方式である。リモートサイトにも確実にデータをバックアップすることが可能であり、高いレベルでのデータ保護を行うことが可能であるが、リモートディスクからの応答を待たなくてはならないため、パフォーマンスは低下しがちである。

 一方、「非同期」処理とはリモートサイトのデータ書き込みが完了する前、すなわちリモートのストレージ装置からの応答を得る前であっても、ローカルストレージ装置へのデータ書き込みは継続的に行う方式である。非同期処理では障害発生のタイミングによってはリモートサイトにデータが書き込まれていない場合があるため、リモートデータの確実性、つまりデータ保護のレベルという観点では同期処理よりも劣るが、システムのパフォーマンスをより向上させることが可能である。

画面4 同期ミラーリング 画面4 同期ミラーリング
画面5 非同期ミラーリング 画面5 非同期ミラーリング

 同期処理を選択するかもしくは非同期処理を選択するかは、MAN/WAN回線の回線種別や回線帯域に依存する。例えばWDM装置経由で1Gbit/sの回線帯域があるようなシステムであれば、同期処理方式を選択しても十分なパフォーマンスを確保できるだろうが、100Mbits/sのIP経由でのWAN接続を行っているシステムであれば、非同期処理の方が現実的な解であるといえる。

 いずれの場合でもディスク装置からのリストアは高速に行うことが可能であるが、リモートディスクバックアップの場合でも復旧できるのは「データ」までである。サーバアプリケーション自体は、別途復旧しなくてはならない。

画面6 リモートディスクバックアップ 画面6 リモートディスクバックアップ

●リモートクラスタリング

 複数のリモートサイト間でクラスタシステムを構成する技術である。一方のサイトに障害が発生しても、もう一方のサイトがそれを短時間(設定によっては瞬時)に検知して、システムをフェールオーバーすることが可能である。リモートサイトにもサーバを用意し、クラスタリングソフトウェアを導入する必要があるため最も高価ではあるが、ミッションクリティカルなシステムでは必要となるだろう。

画面7 リモートクラスタリング 画面7 リモートクラスタリング

 ディザスタ・リカバリという言葉を聞くと「地震」や「テロ」をイメージしがちだと思うが、実際にはほかの用途で使用される場合も多い。典型的な例は「マシンルームの移設(引っ越し)」である。システム停止を最小限に抑えつつマシンルームを移設するためには、バックアップセンターに冗長構成でシステムとデータを保持しておかなければならない。ディザスタ・リカバリという言葉だけに惑わされずに、より広い視野で用途を考えていただきたい。

2. 「エンタープライズSAN」への道

 現在、SANは多くのストレージベンダから提供されているが、これまで構築されてきた多くのSANシステムは、ERP、グループウェアなど個別システムごとに構築されたものが中心だった。このためシステムごとのSANが社内、場合によってはマシンルーム内のあちこちに点在している「SANアイランド」現象が、現在、多くのユーザー環境で発生している。

 これまでの連載でも説明してきたように、SANは本来ストレージやテープ装置を統合し、管理効率を向上する技術である。それにもかかわらず、SANアイランド現象が起こることによって管理が分散してしまっており、SANの本来のメリットを生かせない状況になってしまっている。

 この問題を解決するためには「SANアイランド接続」すなわちSAN間接続が必要である。

 SANアイランド接続により、システムや製品ベンダの枠を超えた本当の「ネットワークとしての」SANが生まれる。このようにして誕生した大規模なSANをここでは「エンタープライズSAN」と呼ぶことにする。

画面8 「SANアイランド」から「エンタープライズSAN」へ 画面8 「SANアイランド」から「エンタープライズSAN」へ

 エンタープライズSANの環境では、ユーザーにも知恵が求められる。ユーザーはSANの障害点を自ら切り分けて、該当するベンダに障害対応依頼をしなければならない。それがサーバハードもしくはストレージ装置の問題なのか、ネットワーク(SAN)上の問題なのかを見分けなければならない。

 また、ハードウェアに起因する問題なのかソフトウェアに起因する問題なのかも調査しなければならない。これらは一見すると、非常に難しい作業に思えるだろう。しかし、読者自身の企業ネットワークをいま一度見直してもらいたい。実はIPネットワークの環境では、ほとんどの企業ですでに同じことをやってきているはずだ。自分たちでそこまでのスキルを持たなくとも、その作業を外部ベンダにアウトソーシングすることもできる。

 SANも「ネットワーク」であるから、本質的に違いはない。SANが大規模化することによって、SANがIPインフラと同じようになってきたのだと考えればよいだけのことである。IPインフラ、LANも昔は部署間で相互接続されずに閉じたネットワークであったことを記憶している読者も多いだろう。SANも同じである。

 また、当初小規模スイッチでSANを構築していたとしても、デバイス、特にサーバの追加によりSANが大規模化するケースも多い。この場合も、接続されるサーバのプラットフォームはさまざまであり、マルチベンダ環境での管理が必要になる。

3. SANにおけるセキュリティ

 「SANのセキュリティとは何なのか」といわれてもピンとこない読者が多いかもしれない。しかし、「特集:SAN導入実践テクニック(第3回)」で紹介したゾーニングの技術などは、SANにおいてセキュリティを担保する典型的な技術である。

 これに加えて、今後はSANデバイスに対する「アクセスコントロール」の概念が求められるようになる。信頼されていない、または認証されていないストレージやサーバ、スイッチなどのデバイスや管理端末が勝手にSANのネットワークに入り込んで、不正に情報へアクセスし、または不正に情報を入手することを防ぐ。

 さらにSAN上に暗号化デバイスを設置して、認証されたユーザーでなければ正しくデータを読めないようにする製品も登場してきている。後述するFCIPやiSCSIといったIP-SAN技術を含むTCP/IP系のネットワークであれば、IPSecによってデータセキュリティを高めることになるだろう。

 これに対してFC-SAN上での暗号化デバイスはファイバチャネルスイッチからフレームを受信し、ファイバチャネルプロトコルのレベルでデータを暗号化して、遠隔地との通信やストレージ装置への暗号化データの書き込みを行うことができる。今後ディザスタ・リカバリやエンタープライズSANが浸透して多くのユーザーで導入されるようになれば、このような技術も必要になってくるだろう。

画面9 セキュアなSAN 画面9 セキュアなSAN

4. ストレージ仮想化

 ストレージ仮想化技術を導入することにより、ユーザーは物理デバイスの種類や配置、個々の装置の容量などに依存することなく、必要に応じて必要な容量のストレージを利用することができるようになる。

 ストレージ仮想化は、すでに多くのユーザーで使用されている技術である。ボリューム管理ソフトウェアはサーバにインストールして使用するサーバベースのストレージ仮想化技術であるし、ストレージ装置が提供しているLUNのマッピング技術などはストレージ装置ベースでのストレージ仮想化技術である。

 現在そして今後は、SANインフラ上でストレージ仮想化を実装する製品が出現してくる。これらの製品は、サーバからは仮想ディスクまたは仮想テープ装置として認識される。具体的にはファイバチャネルスイッチに仮想化アプライアンスを接続し、そのアプライアンスがストレージ仮想化機能を提供することで、サーバやストレージ装置の実装に依存しない形でストレージを仮想化する。さらに、ファイバチャネルスイッチ自体にストレージ仮想化機能を持たせるアイデアもある。こちらも今年後半には製品が提供される見込みである。

画面10 ストレージ仮想化のイメージ 画面10 ストレージ仮想化のイメージ

5. IP-SAN技術

 IP-SANも現在、注目されている技術である。ファイバチャネルのフレームをIPパケットにカプセル化して通信する「FCIP(Fibre

Channel over IP)」やTCP/IPプロトコルスタック上でSCSI通信を行う「iSCSI(internet SCSI)」などが、現在標準規格として規定されており、製品化が進んできている。

 IP-SANの最も優れた点は「長距離伝送」である。ファイバチャネルによるSANが標準で10kmまでという距離の制限があるのに対して、IPによる通信であればその制限を超えることが可能だ。大陸間を横断したSANなども、IPであれば簡単に実装できる。

 一方、IP-SANにおける現在の最も大きな課題はパフォーマンスである。TCP/IPプロトコルスタック自体がファイバチャネルプロトコルに比べてオーバーヘッドが大きく、データ伝送効率が悪いのに加えて、特にiSCSIなどではSCSIとTCP/IPプロトコル処理によるサーバCPUへの負荷が大きくなる。これを回避するために、これらの処理をハードウェア上で行う「TOE(TCP Offload Engine)」が各ストレージベンダから提供されつつある。

 いずれにしても、当初からディスクI/Oを想定して策定されたファイバチャネル技術と、ファイルI/O単位での遠隔通信を前提にしてきたIP-SAN(TCP/IP)は、本来出発点の異なる技術である。これらは用途に応じて使い分けられることになるだろう。

 今日、SANを取り巻く環境は大きく変化してきている。ストレージやファイバチャネルスイッチといった装置単体の機能進化の段階を過ぎて、SAN管理やストレージ仮想化、セキュリティの担保といった「機能」をハードウェアとソフトウェアでどのように実現するかに注目が集まっている。SANに関する技術動向には今後も注意を払っておく必要があるだろう。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。