著：クロスファンクショングループ プロダクトマーケティング室
インフラソリューション推進部 菅 博
コンピューティング・システムは分散をよしとする時代と、統合をよしとする時代が交互にやってくる傾向があります。サーバ・コンピューティングがもてはやされた1980年代から1990年代においては、分散環境による部分最適が流行となって部門単位で多くのシステムが乱立する傾向にありましたが、種々の理由により最近ではシステム統合を進める企業が増えています。それに伴い、必然的にデータ領域としてのストレージ統合も促進されるようになりました。
ストレージ統合を考えるべき理由
サイロ化された分散システムはそれなりの利点もありましたが、企業単位で見ると種々の問題を抱えるようになりましたが、代表的なものを列挙すると次のようになります。
- 専任のシステム管理者の確保が困難
- 技術の細分化が進み、片手間でシステム管理をするのは不可能
- CPUやストレージの利用率が不均等
こうした問題点は全体として人とシステム、そして費用の非効率を作り出しているため、システム統合によってコンピューティング・システムの利便性と効率を高める動きが強まっています。ストレージの領域においても、システム単位に個別にストレージを接続するよりは、複数のシステムや複数のサービスでストレージを共有する方がデータ管理はし易いために、ストレージ統合は今後も進められていくことは間違いありません。
一般にストレージ統合とは言っても、ストレージを統合する背景は大きく次の二通りに別れます。
- コンテンツの増加に対応するためのストレージ統合 (NAS統合)
- サーバ統合がきっかけで引き起こされるストレージ統合 (SAN統合)
実際にストレージ統合を行う場合に、上記のいずれに属するかで統合の方法論や考え方は大きく異なります。この章では、それぞれのケースにおいてストレージ統合をどのように進めていくべきかを考えます。
ストレージ統合の位置付け
統合の具体的な方法を論じる前に、「何のためにストレージを統合」するのかを明確にしておきます。ストレージに限らず、ITシステムの課題として「TCOの削減」とか「内部統制対応」などが言われますが、実際にはこうした課題は同じ階層に属している訳ではありません。従来から存在するIT課題と社会的要因から派生した新たな課題を同じ次元で捉えてしまうと、ストレージ統合の意味合いが曖昧になってしまいます。次の図にあるように、統合ストレージは従来のIT課題の解決策となり、同時に社会的課題に対応するための基礎となっています。
ストレージを統合することによってIT課題のほとんどが解決されると同時に、ストレージの最新技術(階層化、統合バックアップ、災害対策など)が適用可能になります。そして、これらの最新技術が社会的課題に対応していくための具体的な手段となることを意識しておくと、ストレージ統合を機会に見直すべきポイントが明らかになっていきます。
ファイルサーバ(NAS)統合の前に考慮すべきこと
IDCジャパンの調査によると、ストレージ容量は年率1.57%の割合で増加しており、この増加率のまま進むなら5年後のストレージ容量は現在の約10倍になる予測です。データの8割は非構造化データ(つまり、ファイル形式)であるため、ファイルサーバの容量増加は深刻な問題になっています。
こうした背景のゆえに、管理や容量効率を考慮するとファイルサーバの統合は自然な流れであるため、この章ではファイルサーバ統合にあたって、必要となる知識を説明します。
既存ファイルサーバの診断
ファイルサーバの統合前に既存ストレージの内容分析を行うことは有効です。既存ファイルサーバ内の状況に関して、次のような視点で事前分析ができるなら、ファイルサーバを統合する場合の設計に非常に役立ちます。
- ファイル種別毎のファイル数と容量
- 重複ファイル、zipファイルなどのクリーンアップ対象ファイルの総容量
- 所有者不明(AD管理外のユーザ)のファイル数と総容量
- 非活性化(アクセスのないまま置かれている)ファイルの総容量
- データの増加傾向(1年後から5年後の近似値)
こうした情報を事前に入手できるなら、統合先のファイルサーバのサイズを最適化できるとともに、バックアップを含めた運用管理のイメージがわきやすくなります。必須な作業ではありませんが、統合後の総容量が10TBを超える場合にはアセスメントを行うことをお勧めします。
ACL
ファイルを新しいファイルサーバに移行する場合に、ACLやファイルのタイムスタンプを変えたくないという要求が出てきます。同じモデルの専用NASから専用NAS(例: NetApp Filer から NetApp Filer)の場合だと、ファイル属性を保持したままでのオンライン移行(例: SnapMirror)ができますが、問題は異なるファイルサーバ間でデータの移行を行う場合に、どのようにしてACLやタイムスタンプを保持することができるかということです。
UNIX系であればcpioを使うことができますが、Windows環境ではrobocopyコマンドを使うのが一般的なようです。robocopyはもともとWindowsのリソースキットに含まれるツールの一部でしたが、VistaではOSの標準コマンドに含まれています。Windows2000, XP, 2003の場合にはMSのサイトからダウンロードできるので、Windows環境のデータ移行時には非常に便利です。
robocopyもcpioもオフラインの作業となり容量に応じてそれなりの時間がかかってしまいますが、異機種のファイルサーバ間でオンラインでデータ移行を行うことを可能にする製品も出始めています。
セキュリティ
統合するということは共有度が高まるということなので、当然セキュリティについても考慮する必要があります。ネットワークレベルでのセキュリティ構築やADの再構築などは当然ですが、統合先のファウルサーバにおいてもボリュームやフォルダの作成時にはセキュリティを意識した作業が必要になります。
セキュリティの維持と使い勝手を優先する場合に、クライアント側のADを継続使用して今まで通りの方法で新しいファイルサーバにアクセスしたいという要求も出てきます。このときには、NAS上に仮想NASを構築して、クライアント拠点単位で個別な設定を行うことにより対応が可能です(ただし、NetApp, EMC Celerraのように仮想NASの機能を持っている装置であることが前提となります)。
パフォーマンス
クライアント数が増えることから、パフォーマンスについても考慮が必要になります。基本的にはファイルサーバの処理能力とネットワーク帯域の二つが主な考慮点になりますが、特にクライアントと新規ファイルサーバが物理的にかなり離れている場合には、ネットワークの帯域に加えて遅延も考慮しなければなりません。
拠点間のネットワークの遅延を計測するには、pingコマンドを利用するのが最も簡単です。クライアントからファイルサーバ(もしくはファイルサーバと同じサブネットにある装置)に対してpingを実行すると、パケットのRTT(Round Trip Time)が表示されます。下の実行結果はNFSクライアントからファイルサーバに対してのping実行例ですが、RTTは3ms以下であることがわかるので、非常に品質の良いネットワークであることが確認できます。
H0505140% ping -s 10.30.232.100 PING 10.30.232.100: 56 data bytes 64 bytes from 10.30.232.100: icmp_seq=0. time=4.17 ms 64 bytes from 10.30.232.100: icmp_seq=1. time=2.13 ms 64 bytes from 10.30.232.100: icmp_seq=2. time=2.86 ms 64 bytes from 10.30.232.100: icmp_seq=3. time=2.11 ms 64 bytes from 10.30.232.100: icmp_seq=4. time=1.76 ms 64 bytes from 10.30.232.100: icmp_seq=5. time=3.21 ms 64 bytes from 10.30.232.100: icmp_seq=6. time=2.34 ms 64 bytes from 10.30.232.100: icmp_seq=7. time=2.17 ms 64 bytes from 10.30.232.100: icmp_seq=8. time=2.17 ms 64 bytes from 10.30.232.100: icmp_seq=9. time=4.31 ms 64 bytes from 10.30.232.100: icmp_seq=10. time=3.81 ms ----10.30.232.100 PING Statistics---- 11 packets transmitted, 11 packets received, 0% packet loss round-trip (ms) min/avg/max/stddev = 1.76/2.822/4.31/0.914 H0505140%
ネットワークはエンドツーエンドで疎通が確認できても、その間には種々のルータやスイッチ、ハブがリレーをしているため、ある特定の装置のために著しく品質が低下する場合があります。十分に高速なファイルサーバを準備したのに極端にパフォーマンスがでない場合などは、ネットワークを疑ってみてください。
ファイルサーバのパフォーマンスについては、SPEC (http://www.spec.org)のサイトがメジャーなNASの性能検証結果を公表しているので参考になります。
バックアップ
統合されたファイルサーバの容量はかなりの大きさになっているので、バックアップをどのように作成するかは重要な要件となります。基本的にはスナップショット機能を自動的に動かすことで、日次と週次のバックアップを内部に保存しておくことで事足りますが、スナップショット自身はオンライン・ファイルシステムの領域を借り受けた仮想的なファイルシステムなので、ディスク障害によりボリュームが全損した場合にはデータはすべて消失してしまいます(そのために、RAID-6のような二重障害に耐えうるボリューム構成や24H365D保守を活用すべきです)。
スナップショットだけの場合には、データの実態が基本的にひとつしかないのが問題なので、何らかの方法で外部にバックアップデータを作成するのが万全です。ただし、そもそもの容量が大きいために、テープなどのバックアップデバイスに対してフルバックアップを作成しようとするなら、24時間以内に終了する保証はなくなります。VTLのような高速バックアップデバイスもありますが、バックアップジョブを並列にする設計が事前に求められるため、そうしたデバイスの装置性能を完全に引き出すのは現実的にはかなり難しいケースがあります。
そのような場合には、NetAppやEMC Celerraのようなファイルサーバであれば、バックアップとDRを兼用する目的でSnapMirror,Celerra Replicatorのような筐体間ミラー機能を導入するのが、費用はかかるかもしれませんが最も確実な方法です。
HSM導入の検討
階層化ストレージ管理(HSM; Hierarchical Storage Management )自体はデータの活用度や重要度に応じてデータの格納場所を変えて階層管理を行う仕組みですが、実はHSM機能をファイルサーバに導入することは、バックアップを効率よく行うという副次的な効果があります。
仮に、10TBのファイルシステムがあった場合に、10TBのフルバックアップをさけることは出来ません。しかし、HSMの導入によって一次ストレージと二次ストレージの比率を2TB:8TBにできたと仮定すると、フルバックアップの対象は2TBと8TBに分割することができます。しかも、二次ストレージへのデータ移行のエンジンを月末に一度だけ動かすという運用にするなら、二次ストレージの更新タイミングは月に一度ということになります。つまり、8TBのフルバックアップには、次の更新タイミングとなる一ヶ月後まで時間の猶予があることになります。
極端な考え方をすると、そもそも二次ディスクに落ちてきたデータはバックアップを取らない(RAID-6で十分)ということも可能な場合があるかもしれません。重要なデータとそれほどでもないデータが物理的に分かれていれば、バックアップ方法はデータの重要度と総容量に応じて現実的な方法がいくつか出てくるので、データの一括バックアップが難しい段階になったなら、HSMの導入を検討するのがよいでしょう。
コラム一覧のページに戻り、続きをお読み下さい。
