コラム

SEのためのストレージ講座

第5回 ストレージ統合の考え方 その2 ~アプリケーションサーバ(SAN)統合~

更新

IT基盤のストレージの役割や課題から仮想化・統合化まで、CTCのエンジニアが解説します

著:クロスファンクショングループ プロダクトマーケティング室
インフラソリューション推進部 菅 博

アプリケーションサーバはSANを使う事が多いため、アプリケーションサーバの統合とSANストレージの統合は同じ意味合いを持ちます。1990年代には単純にストレージの統合が促進されて、単に物理サーバを最新の大容量ストレージに繋ぎ直すのが主流でしたが、最近のサーバ仮想化の風潮から、アプリケーションサーバの統合の際にサーバ仮想化技術を使うことが一般的となってきました。

SAN統合の鍵はサーバ仮想化

この章では、こうした風潮の中で、それぞれのアプリケーションサーバに繋がれていたDASやSANといったデータ部分を統合する場合の考え方について説明します。特に「システム統合」、「分散から統合へ」という考え方が浸透しつつあり、アプリケーションサーバの統合とSANストレージの統合は、どちらがトリガーになったとしても最終的には「システム統合」に発展するのは間違いありません。システム統合の全体工数を削減し、確実に動作するシステムを構築するための鍵は「サーバの仮想化技術」を最大限に利用することですが、順を追って説明していくことにします。

分散システムの問題点

システムのオープン化とネットワークの普及、さらにはサーバの低価格化により業務毎にサーバを購入してシステムを構築してきたことが現在の分散環境を作り出してきたことは明らかです。

そしてその結果として、文字通りにTCOが問題になってきました。つまり、それらのシステムを所有していること自体が、場所・電力・人件費などの観点から無視できない出費となっているという点です。さらに、CPUやディスクの使用率が低かったり不均衡だったりすることも問題視されており、明らかに無駄な部分が管理者や利用者にも見えてくるようになりました。追い打ちをかけるように、昨今の社会事情からセキュリティやDRの対応を検討しようにも、分散環境で個別に方法論を論じるのは非効率であり、ここにきて分散環境の短所が目立つようになっています。

システム統合のゴールイメージ

こうした背景から、システムを統合して最低限度のH/Wリソースによりある程度の使用率を維持することでTCOを削減すべきという「システム統合」の考え方が指示されるのも不思議ではありません。実際、集積度の高いブレードサーバをどのサーバメーカもリリースをしており、それらは結線済みのIPや結線済みのファイバチャネル・ネットワークをバックボーンに備えています。それらのブレードサーバを受け入れ可能な大容量ストレージも多彩なラインアップがあり、システム統合のための必要機材はすでに十分に整っている状況です。

「まず物理統合から」は正しいのか?

システム統合の方法論としてまず「物理統合」を行い、仮想化技術は部分的に様子を見ながら導入するのが良いという見方がありますが、実際には「物理統合」という考え方は現実的ではありません。「分散」から「統合」へという考え方は常に正しいとしても、これは単純にIT環境を述べているだけであり、分散から統合を装置やアプリケーションのレベルで考えると、最新の装置の上で既存のサービス(アプリケーション)を動作させることになります。

少し考えただけでもどの辺りに問題点が出るのかは明らかですが、図に書くと次のようになります。

左の図は一般的なアプリケーションサーバのスタックを表しています。青い部分は陳腐なH/Wなので棄ててしまうとしても、黒い文字の部分は統合先のシステムに載せ変える必要がありますが、最新の装置で古いOSやミドルウェアがそのまま受け入れられることは非常に難しいといえます。仮にどこかのスタックのバージョンアップが必要になった場合には、そこと隣接するミドルウェアのバージョンアップも必要になるのは明らかです。しかも、それに連動してアプリケーションのバージョンアップも必要になった場合には、データの互換性も確認しなければなりません。

このように、単純に物理統合を実行しようとした場合には、膨大な量の調査と労力が発生するだけでなく、動作保証をどこが行うのかという疑問さえ出てきます。従って、安全策を取ってまずは物理統合からというのは考えとしては正しいように思えても、実際には実現不能と考えるべきです。

仮に物理統合を無理矢理に実行できたとしても、「システム統合」の本来の目的である「コスト削減」を実行できるわけでもありません。500台のサーバがあった場合に、それらのために500枚のブレードサーバを準備しなければならず、ブレードサーバの宿命である熱と消費電力の問題は以前より大きくなっているかもしれません。また、それまでのサーバよりも明らかに高速なCPUを搭載しているブレードサーバ上では、CPUのアイドルがさらに顕著になってしまい本末転倒という結果になります。

アプリケーションサーバの統合には仮想化技術が必須

ここまでくると、サーバ統合を行う場合にサーバ仮想化技術が非常に有用であることが理解できるはずです。基本的には既存アプリケーション環境をOS毎移行が可能であることや、物理ブレードに対して複数の論理サーバを載せることができるために、統合の過程が簡素化されるだけでなく、真の意味でのコスト削減に繋がります。

さらに、サーバ仮想化技術を使用することは、SANストレージ側の統合にも非常に役立ちます。この場合、ストレージ側がサポートの有無としてチェックするのはブレードサーバと仮想化ミドルウェア(VMwareの場合にはESXのバージョン)だけになるからです。逆に、既存環境を最新のSANストレージに接続することはサーバの物理統合以上に敷居が高くなります。古いサーバやHBAを最新のSANストレージがサポートしていることは稀であり、しかもストレージを統合するためにサーバ側のバージョンアップやパッチの適用が要求される場合、既存サーバの管理者としては納得のいかないことが多く、統合に対しての協力が得られないなどの人的な二次被害を引き起こすこともあります。

アプリケーションサーバの統合を行う場合には、必ずSANストレージの統合も平行して行われます。その時に、サーバの仮想化技術を導入することはサーバ統合・ストレージ統合を円滑に進める鍵となることは覚えておきましょう。

コラム一覧のページに戻り、続きをお読み下さい。

  • このページについてツイッターでツイート(新しいウィンドウで開く)
  • このページをフェイスブックでシェア(新しいウィンドウで開く)

このコラムに関するお問い合わせはこちら

※記載内容は掲載当時のものであり、変更されている場合がございます。