コラム

サーバ仮想化の運用で気をつけること

第3回はLPAR方式とVM方式の仮想化の違いとLPAR方式の利用シーンについて紹介しました。今回は運用面に焦点をあて、何に気をつけないといけないかを考えてみましょう。少し難しい話になりますが思い当たる節があれば気をつけるといった形で参考にしてください。

以下、物理サーバにおける運用と仮想化環境での運用を比較する形で概要を説明します。仮想化環境の中でVM方式の運用とLPAR方式の運用が異なる場合には、それぞれの特徴を説明します。

（1）仮想サーバ管理

ａ．仮想サーバの物理的な管理の複雑化

サーバ管理で当たり前に必要な項目は物理サーバとして、どこにあるか、そしてそれがどの業務に用いられているかの管理です。保守やトラブル対応の基本情報です。

　[物理サーバの場合]　各サーバの生死状況は一般的にネットワーク管理ソフトなどを用いてIPアドレスをキーにして監視することが多くなっています。したがって業務システムのIPアドレスを元にそのサーバの設置位置を一覧表に記載するといった管理をします。サーバ配置を変更するときには一覧表を修正します。

　[仮想化の場合]　物理サーバと同様にVMやLPARをひとつの業務システムとして扱い、そのIPアドレスを元に管理します。しかし、仮想化ではさらに、

• 仮想化ソフトの管理が必要
• VMやLPARを別物理サーバに移動させることが簡単なので、物理サーバのときのような一覧表記載／修正といった方法では物理位置を管理できなくなる

といった課題がでてきます。

運用上、あまり頻繁にVM、LPARを別物理サーバに移動しないよう、運用に気をつける必要があります。

ｂ．仮想サーバスプローリングとならないように注意

サーバ仮想化では物理サーバ台数の大幅な削減が期待できますが、簡単に設定できるという点から仮想サーバの台数は増加する傾向にあります。無秩序にサーバが増加していく現象をサーバスプローリング（server sprawling）といいますが、仮想サーバが無秩序に増加する仮想サーバスプローリングが起き、仮想サーバ管理の手間が増加する恐れがあるのです。

　[物理サーバの場合]　新システムの追加、開発・保守用システムの追加など、要求にしたがって物理サーバを追加する状況を考えてみましょう。物理サーバの追加には予算確保や見積り、発注、納品、検収といった面倒な作業が必要となり、納期の制約もあり実際に利用可能となるまで時間がかかります。それでも、近年はPCサーバの低価格化により多数のサーバが導入されてサーバスプローリングが発生する傾向にあります。

　[仮想化の場合]　サーバ仮想化により物理サーバの増加を抑制することができますが、VM、LPARの追加は画面上で設定するだけで簡単なので、システム数（OS数）という観点では物理サーバしか利用できなかった時代に比べると返って増えてしまう傾向にあります。簡単に増やせるからといって仮想サーバスプローリングが発生しないように、必要なシステムだけを厳選して設定するという考え方が必要です。

ｃ．ネットワーク、ストレージ、サーバ管理者の分離

大きなデータセンタや情報システム部門では、ネットワーク管理者、ストレージ管理者、サーバ管理者が別に機器を管理する体制になっています。各々多種類の機器が存在し、それぞれに専門の知識が必要となるため分業せざるを得ないのが実態でしょう。

　[物理サーバの場合]　ルータやLANスイッチの管理者、ストレージ装置やFCスイッチの管理者、サーバの管理者が明確に分かれ、機器の管理者用パスワードや構成情報など固有情報を独自に管理できます。サーバ管理者が新たにストレージを割当てて欲しいとき、LANのセグメントを割当てて欲しいとき、ストレージ管理者やネットワーク管理者に依頼します。

　[仮想化の場合]　VM方式の仮想化ではストレージは仮想ファイルシステムに、LANは仮想スイッチが使われておりサーバ管理者が管理する必要があります。ストレージ管理者やネットワーク管理者は仮想化されたサーバ内で使用しているリソースに手出しができなくなり、センタ全体に対する責任を負うのが難しくなるという課題があります。

LPAR方式の仮想化では仮想ファイルシステムといった概念はありません。LANについては仮想NICという考え方で外部LANのネットワークポリシーを阻害することがなく、占有NICを利用する場合はネットワークの仮想化の概念も存在しません。したがって、LPAR方式の場合はストレージ管理者やネットワーク管理者は従来（物理サーバのとき）通りの仕事と責任を負うことができます。

（2）障害管理

ａ．サーバハード障害に対する管理

ハードウェアというものはある確率で障害が発生するものです。また、年月が経過すると寿命により障害が発生し始めるということもあります。障害に対してはどういった備えをすれば良いのでしょう。

　[物理サーバの場合]　サーバの予備機を用意して障害が発生したときには予備機を立ち上げます。予備機には予め回復用のシステムをインストールしておいたり、障害になったサーバのディスクを予備機に接続替えしたりして回復することもあるでしょう。重要なシステムならWSFCといったクラスタソフトウェアを用いてホットスタンバイシステムを組むかもしれません。日立のBladeSymphonyではJP1/SC管理ソフトと組合わせてN+１コールドスタンバイという回復構成がとれ、予備サーバの台数を減らす構成が可能です。いずれにしても、サーバ障害時にダウンするシステム（OS）はひとつだけなので障害時の対処法もそれほど複雑ではないでしょう。

　[仮想化の場合]　サーバハードウェアが障害になるとその上で動作していたVM、LPARが全てダウンすることになります。そういったとき予備サーバを仮想環境丸ごと立ち上げればそれぞれのサーバの機能は回復可能です。物理サーバでサポートしている日立のN+1コールドスタンバイ機能は仮想環境でも利用可能で万一のハードウェア障害の場合でも仮想環境丸ごと自動的に回復することができます。

しかし、比較的安価に構成できるコールドスタンバイ方式はエンドユーザへのサービスが数十分停止するので、それが許されない厳しいシステムでは利用できません。そういった場合にはVM、LPAR単位で別物理サーバ上にホットスタンバイ構成による予備サーバを動作させておく必要があります。

また、このような障害では複数VM、LPARが一斉にサービスを中断することから、複数のサービスに同時に影響が出てしまい、エンドユーザへの連絡が大変になります。いくらリソースが余っているからといっても、VM、LPARを何十台も1台の物理サーバに搭載するのは避けた方が良いでしょう。

ｂ．ゲストＯＳ／ＡＰのソフトウェア障害に対する管理

ソフトウェアの障害の場合はゲストOSにだけ影響を与えます。物理サーバは全く正常に動作している状態ですので、これを助ける手法には注意が必要です。

　[物理サーバの場合]　物理サーバ上のOSでソフトウェア障害が発生したとき、OSが障害を認識可能な場合は自動的にリブート処理を実行し物理サーバの再起動により回復を図ります。データベースやトランザクション処理システムなど、基幹業務用のミドルだけがハングアップする障害を検出する場合にはアプリケーションレイヤの障害検出手段を用意してWSFCや日立のHAモニタのようなホットスタンバイシステムを利用して別物理サーバにシステムを切り換える方法が有効です。

　[仮想化の場合]　1台の物理サーバの上に複数のゲストシステム（OS）が動作しているので、そのひとつがソフトウェア障害だからといって物理サーバ全体を切り換えるようなことをしては問題です。正常に動作している別システムをわざと倒してしまうことになるからです。こういった事態はOS自身が障害を検出してリブートするような障害ではVM,LPAR上で勝手にリブートしてくれるため発生しませんが、ミドルのハングアップ対策が要注意です。１台のVM、LPAR毎に別ブレード上（対ソフトウェア障害の場合だけなら同じ物理ブレード上でも良いが）に交代VM,LPARを用意し、それらの間でホットスタンバイ構成を組む必要があります。VM方式ではVM対VMでホットスタンバイ構成を組むために構成が難しくなることがありますが、LPAR方式の場合はI/O装置接続が物理サーバと同じなのでLPAR対LPARのホットスタンバイ構成が容易に実現可能です。

ｃ．負荷分散構成を利用した障害時のサービス継続性実現のための注意

万一のサーバハードウェア障害の際、サービスをできるだけ継続するためには、前述のハード、ソフトの障害に対する管理で述べたように壊れたサーバの交代機をどのように準備するか、という考え方がありますが、そのほかに、複数のサーバを同じ処理に用いる負荷分散構成を採用し、1台のサーバがダウンしてもサービスが縮退継続するという考え方があります。

　[物理サーバの場合]　物理サーバで負荷分散構成をとる場合にはロードバランサのような適当な手法で複数のサーバに負荷を振り、1台ダウンしても他の何台かが生き残る構成をとることができます。

　[仮想化の場合]　仮想化環境でこのような負荷分散構成をとる場合、複数のVM、LPARに分散したつもりなのに、依存関係のあるサーバがある物理サーバの障害と同時にダウンしたというようなことが起きないよう、物理サーバへの配置に注意する必要があります。例えばweb-AP-DBサーバの3台で1セットになっているweb３階層システムが2システムで負荷分散していたときに、webサーバ１とwebサーバ2は別々の物理サーバに配置したのに、webサーバ１とセットになっているAPサーバ１がwebサーバ2が動作している物理サーバに載っていた、というような構成を組んだとします。このとき、webサーバ２の物理サーバがダウンするとAPサーバ１が同時にダウンするのでwebサーバ１の処理も進まなくなってしまうのです。どの仮想サーバがどの負荷分散系列になっているか、しっかり管理する必要があります。

VM、LPARを別物理サーバに移動するような場合でも、この関係を崩さないよう注意する必要があります。

ｄ．仮想化環境におけるアプリケーションソフト障害時の原因調査

システム構築の際にはソフトウェアベンダ各社が開発・販売しているパッケージソフトなどを利用することが多いでしょう。ソフトウェアベンダによっては自社ソフトを明示的には仮想化環境でサポートしていないという場合があり、また、物理サーバ上で同じ現象が発生することをユーザ側で証明しないと原因調査をサポートしないというベンダもあります。そのような場合、どういった点に注意が必要でしょうか。

　[物理サーバの場合]　どのOSの上でそのソフトをどのように使っていたかを連絡するとソフトウェアベンダは既知の問題か未知の問題かを判別し、既知なら対応方法を教えてくれますし未知ならソフトウェアベンダが自分で調べて結果を連絡してくれる、といった対応が多いでしょう。

　[仮想化の場合]　アプリケーションソフトウェアは通常、OSの機能を利用するだけで動作するようにできているので仮想化環境であってもOS認証が取れている環境であればそのままサポートするといった考え方が多くなっています。しかし、一部の、ハードウェアに近いところの仕様が影響するソフトでは仮想化環境をサポート対象とせず、物理サーバで同じ問題が起きたときのみ物理サーバ環境における問題としてサポートするというベンダがあります。この種のソフトウェアを利用する場合にはソフトウェアベンダのサポートを受けるため、仮想サーバと同じソフトを物理サーバ上で同じ構成で動作可能とする必要があります。

VM方式の仮想化ではディスクの記録形式として仮想ファイルシステムを採用することが多いので物理サーバでは直接動作させることができません。物理サーバを持ってきて仮想化環境と同じ組合わせや構成になるようにソフトウェア一式の再インストールをする必要があるのです。

VirtageのLPAR方式ではディスク記録形式が物理サーバと全く同じなので特にソフトウェアの再インストールは必要としません。物理サーバモードのサーバを持ってくるか、いま使っているサーバの動作モードをVirtageから物理サーバの動作モードに切り換えて障害が起きたディスクを接続してブートするだけで再現テストが可能となります。ソフトウェアの再インストールは不要なのです。

ｅ．ディザスタリカバリシステム対応

ディザスタリカバリシステムとはメインのデータセンタが地震や火災のような災害で機能を停止したときに遠隔地の別センタで代替システムを運用するためのシステムという考え方です。サーバ仮想化を用いることでディザスタリカバリシステムをコストパフォーマンス良く構築できます。

　[物理サーバの場合]　遠隔地のセンタにあるディザスタリカバリシステムは、メインのセンタと同じ台数のサーバハードウェアを設置する考え方が標準的です。メインセンタで提供中のサービスを全て代替して提供するためには、同じOS、アプリケーションソフトウェア構成を用意する必要があるためです。災害時の運用ではある程度性能を落としても良い、という場合は性能の低い、安いサーバを同じ台数だけそろえるという対応になります。

　[仮想化の場合]　災害時にはある程度性能を落として良いというポリシーのディザスタリカバリシステムであれば、1台の物理サーバに複数の仮想サーバを搭載し、仮想サーバとして必要な台数だけ揃えることにより代替システムの構築が可能となります。サーバハードウェアの台数を削減することが可能であり、また、平常時は開発用仮想サーバを立てて利用するなどサーバハードリソースの有効利用を図ることができるのでコストパフォーマンスの良いシステムができます。

ディザスタリカバリシステムでは、メインのセンタと遠隔地センタの間のストレージを定期的に同期し、遠隔地でも短期間に業務の再開始ができるようにします。ストレージ間の同期のための機能として日立ストレージではURやTrueCopyと呼ぶストレージ間データコピー機能がありますが、LPAR方式ではVM方式に比べると、この機能を簡単に利用できます。

ｆ．部分障害発生後の部品交換

サーバハードウェア障害の中にはサーバ全体はダウンしないで運用を継続できる部分障害という状態があります。例えばLANカードを二重化してあるがそのうちの１個が壊れて一重状態で動作し続けているというような状態です。壊れたLANカードを正常な物に交換するためにはどうしたら良いのでしょうか。

　[物理サーバの場合]　部分障害となったサーバについて、そのシステムを停止可能な時期を決め、停止したときにカードを交換します。正常な部品との交換を実施するまでは二重化されていない状態で動作するので、残りの部分が障害となると全体のシステムが停止します。したがって停止時期をあまり先送りしないように注意が必要です。

　[仮想化の場合]　仮想化では１台の物理サーバの上に複数のシステムが搭載されているため事態はより深刻になります。システムを停止する時期を決めようと思っても、ある仮想サーバのシステムの停止可能時期と別の仮想サーバのシステムの停止可能時期が異なり、物理サーバとしては停止できないといった事態が起きるのです。

ひとつの解決策は仮想サーバを別の物理サーバに移動するマイグレーション機能を利用して、１台の物理サーバ上の仮想サーバを全て異なる物理サーバ上に追い出すというやり方です。追い出した後、空いた物理サーバの部品交換を行なうわけです。

しかしマイグレーション操作は常に可能なわけではありません。マイグレーション元とマイグレーション先の物理的なネットワーク構成が異なるとか、マイグレーション元の負荷の重い時期が続いているため移行対象にできないとか、マイグレーション先としてリソースの余っているサーバが無いといった状況です。このような状況の中でマイグレーションをしなくてもI/Oカードを交換可能とするため、日立のBladeSymphony BS2000では物理サーバも仮想サーバ（VirtageのLPARの場合）も停止することなく障害となったI/Oカードを交換可能とする機能を提供しています。

（３）資産管理

ａ．減価償却期間を意識した資産管理を仮想化により容易化

多くの企業ではサーバについて、税務上の耐用年数の間減価償却を行いその後滅却するような運用としていますが、耐用年数の5年の間にはいくつもの開発プロジェクトが始まったり終了したりします。本番運用に入るシステムは5年以上利用すれば良いのですが、開発用のサーバはこの間種々の開発に流用されます。どんなことが起きるでしょう。

　[物理サーバの場合]　開発用のサーバは開発部門や内容によって必要なスペックが異なります。したがってある開発目的でそのサーバを最初に購入した部署にとっては思い通りの仕様を持ったサーバを入手することができます。しかし、2年ほど経って別の開発にそのサーバを流用しようとするとメモリが足りないとかディスクが足りないなどの問題があり、現場の担当者が一時的に部品を流用するといったことが起きてしまいがちです。そうなると滅却時期になり、廃棄しようとしたサーバが購入した時点と異なる仕様になっているということが起きて資産管理上の問題となる可能性があります。

　[仮想化の場合]　物理サーバにおける資産管理上の問題は、複数の物理サーバの間に必要なリソースの過不足、アンバランスが発生するために起きるのです。開発用に十分大きいサーバを用意し、それを仮想化により分割利用することにより、ある開発が終了したらその仮想サーバのリソースを開放し別の開発用仮想サーバに転用するといった運用が可能になります。現場の担当者が勝手に部品を入れ替えるといったことは起きなくなるので資産管理が容易になるという効果があるのです。

ｂ．サーバ保守期間切れに対する対応

税法上の耐用年数は5年とされていても、5年でサーバの新機種入れ替えをすることは容易ではありません。もちろん新しいサーバの方が性能も機能も良くなりますので入れ替えをすれば効率的なシステムに生まれ変わります。しかし、5年前に導入したOSは既にOSベンダーのサポート外となり新しいサーバでの動作が保証されなくなっていることが普通なのです。自己責任でOSを利用したいと思っても新しいサーバに装備された新しいハードウェアに対応するデバイスドライバがOSベンダから提供されないなど、OSが使えなくなってしまうこともあるのです。どのように対応すれば良いのでしょう。

　[物理サーバの場合]　通常、新サーバへの入れ替えの際には、新OSを導入し、アプリケーションプログラムが新OSで動作可能かを検証し、もし問題があればアプリケーションを修正するといったSE作業が必要となります。絶対に必要な作業ですがこれ自身はユーザの本業に新しい価値を生み出す作業ではないので、なかなか費用の理解を得られません。

日立のBladeSymphonyではロングライフサポートメニューを提供し、7年または10年（機種、サポート契約によります）間のサポートを保証しており、サーバ入れ替え頻度を少なくすることができます。

　[仮想化の場合]　仮想化を利用している場合でも、物理サーバの保守期間についてはまったく同じ課題があります。サーバ仮想化ソフトはその名の通りソフトウェアでありせいぜい3年程度のサポート期間しかないため、5年も経って新しいサーバが出てきて入れ替えようとすると、新バージョンのサーバ仮想化ソフトに入れ替える必要があるのです。そうすると、やっぱりそのための評価が必要になりSE作業が必要となるのです。サーバ仮想化ソフトベンダは主としてVM方式を用いているので新バージョンの仮想化ソフトウェアでも比較的安心して動作保証が可能ですが、あるベンダの状況では仮想化環境の運用まわりでいくつかの機能を廃止したりしているため、少なくとも運用まわりの機能を再構築する必要がでてくるでしょう。

日立のBladeSymphony＋Virtageではハードウェアに組込まれたファームウエアとして仮想化の機能を提供しています。したがって、BladeSymphonyのロングライフサポートメニューを適用していただければ、その間、仮想化環境も一切手を加える必要がなくSE作業の発生頻度を抑えることができます。

（４）性能管理

ａ．業務システムの性能変動への対応

最初のシステム設計の際には、その業務システムの負荷がそのシステム寿命の期間の中でどれくらいまで上昇する可能性があるかを検討して必要なサーバ台数を見積もります。しかし、システム寿命に達する前に当初予想より負荷が大きくなるサーバが出てきたり、予想以上に負荷の少ないサーバがでてきたりするものです。そのような場合の対処を考えてみましょう。

　[物理サーバの場合]　最初の設計から2、3年後に特定のシステムの負荷が予想より大きく上昇し性能不足が生じたとしましょう。その業務のサーバを追加するとか、その業務用のサーバをより高性能な物と交換するという手段が考えられます。前者は複数のサーバに負荷を分散するための仕組みを追加する必要があり、システム再設計が大変です。後者はシステム再設計の必要はほとんどありませんが、高性能サーバと交換した旧サーバが余ってしまい、次の利用場所として適当なものを見つけられない可能性があります。

　[仮想化の場合]　仮想化を利用すれば、予め高性能なサーバに複数の仮想サーバによる複数業務の実行を割当てることができるので、特定のサーバで性能不足が生じた場合でも他のサーバで性能が余っているものを見つけてリソースの配分を見直すことにより性能不足を解消することができます。

ｂ．他業務システムとの競合による性能変動への対応

データセンタ内に種々のシステムが同居している場合には、特に仮想化環境でのシステム間の影響が課題になります。他社・他部門のシステムの負荷が高くなったからといって、自社のシステムに性能上の影響がないのかが気になるわけです。

　[物理サーバの場合]　会社、部門毎に物理的にサーバが分かれている場合、ある会社のシステムの負荷が増加したからといっても他のシステム用のサーバに影響が及ぶことはありません。

　[仮想化の場合]　仮想化の場合、1台の物理サーバ上に複数の会社、部門のシステムが同居するケースが考えられます。事業者として、あるいは情報システム部門としてSaaS、PaaSを安価に提供しようとするとできるだけ詰め込んだ方が効果的だからです。1台のサーバの中で複数のシステムがCPUを共有しているとある会社のシステムの負荷が重くなったときに他の会社のシステム性能が低下してしまう可能性があるためリソース割当に注意が必要です。

Virtageによる仮想化ではCPU占有モード、CPU性能キャッピング、プロセッサグループ機能など種々のリソース割当方式を提供して、他社LPAR間の分離／自社LPAR間でのリソース有効活用を両立可能としています。

ｃ．仮想化特有の性能チューニング

リソースを有効利用するための性能チューニングは難しいものです。負荷を大きめに見積もって十分にリソースを用意すれば性能問題を起こすことはありませんがリソース利用率が上がないというトレードオフがあるのです。

　[物理サーバの場合]　高い性能が必要なシステムには高性能のサーバを使用し、性能がそれほど必要でないシステムには安価で性能の低いサーバを使用する、といった形で性能チューニングを実施します。リソースの有効利用を重視するなら、大変ですが、性能の変化によって利用するサーバ種を変更する（入れ替える）といった作業が必要かもしれません。

　[仮想化の場合]　仮想化環境では、いわゆるリソースプールの位置付けで高性能で大きなサーバを1台用意し、その中をいくつかのシステムで分割利用することにより比較的容易に必要な性能の確保とリソース利用率の向上の両方を図ることができます。とはいうものの、IAサーバにおける仮想化技術はまだそれぞれの仮想マシン（VM、LPAR）が物理サーバと全く同じ動きをするというところまでは進んでいません。ごく少数のケースですが、仮想化固有のチューニングノウハウが必要となる場合があります。

例えば、アプリケーションプログラムによっては性能対策として割当てるCPUコア数を増加しても性能が増加しないとか、返って性能が低下するといった現象が起きることがあります。こういう場合はCPUコア数を減らした方が性能が増加することもあるのです。

ｄ．仮想サーバ移動時のネットワーク性能管理

仮想化環境ではVM、LPARを別物理サーバにマイグレーション（移動）して保守、省電力、性能チューニングに活用することが可能ですが、マイグレーションする際にはサーバ側だけでなくネットワーク側の負荷や信頼性の確保にも注意をする必要があります。

　[物理サーバの場合]　物理サーバではマイグレーションが不可能なので、特に問題は発生しません。物理的な設置位置変更（ネットワークトポロジー的に異なる場所に）をすると、同様な問題が発生しますが、そのような変更は予め綿密な計画を立てるのが普通でしょう。

　[仮想化の場合]　仮想化環境におけるVM、LPARのマイグレーション機能では当然のことながら物理的なLANケーブルの接続までは変更できないので、異なる物理サーバ上にVM、LPARが移動した結果ネットワーク上のトラフィックが変わります。その結果特定のスイッチやルータ、ファイアウォールに負荷が集中するという可能性がある点に注意しマイグレーション先を管理する必要があります。また、チーミング、ボンディング機能を利用している場合マイグレーション後のサーバ側設定とネットワークスイッチ、ルータ側の設定とが整合性がとれるよう注意が必要です。

（５）データセンタ運用

ａ．物理サーバ、種々の仮想化基盤混在の運用

データセンタではできるだけ運用を統一したいものです。しかしデータセンタのユーザニーズに効率よく応えようとすると、異なる考え方のサーバを導入せざるを得ない場合もあります。高負荷のデータベースマシンは物理サーバで構築し、Windows NTやWindows 2000のような古いOSを用いるシステムではVM方式の仮想化を利用、高信頼で高性能が必要なシステムにはLPAR方式の仮想化を用いる、といった使い方です。このような環境での運用はどう考えるべきでしょうか。

　[物理サーバの場合]　物理サーバの場合でも異なるアーキテクチャのサーバをひとつの部署で管理する場合には同様な課題があります。メインフレーム、UNIX系サーバ、IAサーバが混在しているようなケースです。実態としてはサーバ毎に異なるツールを用いて運用しているのではないでしょうか。

　[仮想化の場合]　IAサーバで物理、VM方式、LPAR方式が混在するようなシステムでは、まず全体の状況監視をひとつのツールで行い、特定の物理サーバの問題であるとか仮想サーバの問題であるとかが特定された時点で個別の管理ツールを利用して詳細解析にあたるといった考え方が有効です。

日立ではBladeSymphony向けに、物理サーバ管理および仮想サーバ混在環境を一括管理可能なJP1/SC（Server Conductor）を提供し、個別の管理ツールとしてVirtageの詳細管理をするためのVirtage Navigatorを提供しています。

ｂ．期間トータルの電力使用量を削減する省電力運用

データセンタ運用において省電力運用が社会的使命となってきました。どのような手法が考えられるでしょう。

　[物理サーバの場合]　物理サーバではアプリケーションプログラムの負荷が減るとCPUのクロック周波数や電源電圧を自動的に変更し消費電力を削減するというDBS（Demand-Based Switching）といった省電力機能があります。サーバの中でCPUの消費電力は大きな部分を占めるので有効です。

　[仮想化の場合]　仮想化環境では上記物理サーバでの省電力機能以外にも省電力効果があります。まずは単純に現状多数の物理サーバで構築されている複数システムを1台の物理サーバに集約することによりサーバ台数を削減することです。仮想化を使うこと自身が省電力だ、という意味合いです。さらに、週末、月末、四半期に一度だけ負荷が増加するといったシステムは、通常は他システムと同じ物理サーバに同居させておき、必要な時期だけ独立した物理サーバにマイグレーションするといった運用をすることにより、通常空いている物理サーバの電源を切り省電力運用をすることができます。

ｃ．瞬間最大電力を低減する省電力運用

電力消費量の削減目標として瞬間最大消費電力がある制限値を超えないこと、という条件が与えられることがあります。極端に言うと、その条件を満たしさえすれば期間トータルの消費電力は大きくても良いという考え方です。

　[物理サーバの場合]　もっとも単純には、サーバ1台あたりの最大消費電力を足し算して、目標値を超えない範囲でサーバを利用するといった考え方ができます。しかし、これでは必要なシステムまでもが立上げできないといったことになりかねません。日立のBladeSymphonyはPower Cappingという機能を備えており、1台のサーバあたりの消費電力の上限を設定することができ、必要なサーバ台数を稼働しつつ、安心して基準を守ることができます。

　[仮想化の場合]　このタイプの電力削減要求に対しては仮想化による特長的な対応ということは特にありません。BladeSymphonyを利用する場合には物理サーバのPower Capping機能がVirtageによる仮想化でも有効に働くので安心して電力削減基準を守ることができます。

ｄ．仮想サーバのディスクバックアップ運用

システム運用の中で古くて新しい問題はディスクバックアップ手法でしょう。ここではLTOを装備したバックアップサーバを用意して各サーバのディスクバックアップを採る構成を考えてみます。

　[物理サーバの場合]　大きく分類して、LAN経由バックアップ方式とLANフリーバックアップ方式（SAN経由バックアップ方式）が考えられます。

LAN経由バックアップ方式はバックアップ対象のシステム上にバックアップソフトのエージェントを搭載し、そのエージェントとバックアップサーバのマネージャが通信することにより対象システムのディスクデータをLANを通して転送しLTOに書き込みます。

LANフリーバックアップ方式はSAN接続のディスクを使っていることを前提とし、バックアップ対象のサーバが使っているディスク（SANストレージのLU）のコピーをバックアップサーバが直接読みこんでLTOに書き込みます。

　[仮想化の場合]　仮想化環境の場合、LAN経由バックアップ方式は物理の場合と同様の構成で動作します。しかし、バックアップ実行時のLANのトラフィックは非常に大きいので性能設計に注意する必要があります。

仮想化環境、特にVM方式におけるLANフリーバックアップ方式の適用はなかなか困難です。LANフリーバックアップでは単にバックアップサーバからターゲットのストレージのLUをアクセスできれば良い、というだけではなく、バックアップ対象サーバ上のアプリケーションプログラムを一瞬停止してディスクキャッシュデータをディスクに書き込んだ後に副ボリューム（コピー）を作るというディスクデータのコピー作業が必要になるためです。VM方式では１つのLUに複数のOSイメージが格納されることが多く、同時に同期点を作るのが大変です。VM方式のディスクは仮想ファイルシステムの形式になっておりバックアップサーバから直接Windows、Linuxのファイルシステムとしてアクセスできないという問題もあります。

LPAR方式のVirtageではディスクを仮想化しないので物理サーバの場合と同様にディスクデータのコピー作業が可能で、LANフリーバックアップシステムであっても構築が容易です。前記VM方式のような問題はありません。

ｅ．Active Directoryサーバのバックアップ運用

最近、特によく聞くのはActive Directoryのサーバをバックアップ／リストアを普通の方式で実施して良いか？という課題です。

　[物理サーバの場合]　Active Directoryサーバは他のActive Directoryサーバやクライアントと連係をとって動作しており、登録情報の変更の時間順序的な整合性をとるなどしているため、過去のある時点で取得したバックアップを現時点のActive Directoryサーバとして回復すると管理データを破壊してしまう可能性があります。Active Directoryサーバのバックアップリストアは正式に対応可能と保証されているバックアップソフトウェアで実行する必要があります。

　[仮想化の場合]　仮想環境であっても上記事情は同じなのですが、VM方式の仮想化環境ではOSを含むシステム／アプリケーションの一括バックアップをコマンドひとつで実行できてしまう場合があるため、そのような環境ではActive Directoryサーバもそのコマンドでバックアップをとって良いのではないかと誤解されることがあります。しかし、Active Directoryサーバのバックアップ／リストアが単純でないのは上記理由によるものなので、そうしたコマンドでのバックアップ／リストアをしてはいけません。

LPAR方式のVirtageの場合は物理サーバとまったく同じで、きちんとActive Directoryのバックアップ機能があることを保証するバックアップソフトウェアを用いれば可能です。

ｆ．ゲストＯＳのバージョンアップと仮想化基盤のバージョンアップ運用

仮想にしろ物理にしろ、サーバ群はできるだけ停止したくないものですが、OSのパッチ適用やバージョンアップなどリブートが必須となることがあります。仮想化環境の場合にはさら仮想化ソフトのパッチやバージョンアップが必要になる場合があります。

　[物理サーバの場合]　OSのパッチ適用やバージョンアップを行なう場合、そのサーバは短時間ですが停止する必要があります。リブートをせざるを得ないケースが多いためです。

　[仮想化の場合]　仮想化環境においてもOSのパッチやバージョンアップの際にはその仮想サーバを停止する必要があります。マイグレーション機能で別物理サーバに移動するというようなことをしても、OSから丸ごと移動するのであって、OSが換わるわけではないからです。しかし、仮想化ソフトウェアのパッチやバージョンアップが必要になる場合にはマイグレーションで別物理サーバの仮想化環境に移動することにより、元の物理サーバで動作している仮想化ソフトウェアのパッチ適用やバージョンアップが可能になります。

ｇ．クラウド環境提供時のマルチテナントへの考慮

1台の物理サーバ上に、本来独立な運用を求められる複数の会社や複数の利用部門の仮想サーバを搭載するマルチテナント環境では、その物理サーバ上で動作している全ての仮想サーバを一斉に停止することは不可能です。あるユーザは月初には止めていいが、別のユーザは月中でないと止められない、といった運用スケジュールのずれがあるからです。

　[物理サーバの場合]　物理サーバ環境でもマルチテナント環境が問題となることがあります。同一ラック内に複数の会社のサーバが搭載されているというマルチテナント環境です。なんらかの都合でそのラックに引き込んである電源を一時的に切る必要があるといった場合に同一ラック内のサーバに関連した全ての会社と停止日、時間を合意する必要があり難しい運用となります。

　[仮想化の場合]　仮想化環境の場合、運用はもう少し楽になります。物理サーバを停止しなければならない保守などの事情が発生したら、リソースが余っている物理サーバを探してVM,LPARをそのサーバにマイグレーション（移動）し、空いたところでその物理サーバを保守すれば良いのです。VM、LPARをマイグレーションするときには、そのサーバを利用している会社に日時の了解をとる必要がありますが、1社の了解を取り付けるだけで済むので大きく現実味がでてきます。

ｈ．クラウド環境提供時の課金の考え方

クラウドではユーザの利用量に応じて料金を取る運用にしたいことがあります。過去のメインフレームコンピュータ全盛の時代ではシステムが高価だったこともあり、使用したCPU時間、割当てたメモリの容量、ディスクへのアクセス回数などを元にしてユーザに課金することが一般的な時代もありました。現代のIAサーバではサーバ単位でユーザに課金をすることが一般的です。１サーバあたり月額○○円、といったイメージです。仮想化環境ではどう考えれば良いのでしょう。

　[物理サーバの場合]　一般的なホスティングの考え方では、物理サーバあたり月額○○円という考え方でしょう。物理サーバの場合はあまり頻繁にユーザ（借主）を変えるわけには行きませんし、利用率が低くリソースが空いていても誰か他の人に貸すわけにいかないので値段を下げるわけにはいかないのです。業務量の少ないサーバ用には安くて性能の低いサーバを用意して安価に貸し出すといった対応は考えられますが、いろいろな種類のサーバを用意するのは需要予測が難しくなるという課題があります。
　[仮想化の場合]　仮想サーバホスティングの考え方なら、サーバ1台に割当てるリソース量を自由に設定できるので自由な料金設定が可能になります。CPUを1コア割当てた1台は月額○○円、2コア割当てた1台はその2倍といった考え方です。利用率が低くリソースが空いているようならさらに仮想サーバを追加して貸し出すことができ、自由度の高いビジネスが可能になります。

さらに、各仮想サーバのCPU使用率の履歴を採っておけばCPUを使った分だけ料金を取るという課金も可能になります。このとき、仮想サーバ上で動作するゲストOSで測定するCPU使用率ではなく、仮想化ソフトが提供する性能モニタ機能により測定したCPU使用率を用いて課金計算をしなければならないという点に注意が必要です。ゲストOSで測定したCPU使用率は仮想化ソフトが仮想サーバに割当てたリソースの中での部分的な使用率になっているためです。

サーバの運用管理ソフトウェア

上記「データセンタ運用」の「物理サーバ、種々の仮想化基盤混在の運用」でご紹介しましたが、データセンタ内では業務の性質によって物理サーバ、VM方式の仮想化環境、LPAR方式の仮想化環境が混在することがあります。このようなセンタでは物理サーバのほか各種仮想化環境の管理を統合して管理できるツールで全体の生死監視など概要レベルの監視を行い、なんらかのトラブル発見された時点で対象サーバ固有の管理ツールを用いて詳細な調査や対処を行なうという運用が必要です。

日立製作所ではBladeSymphonyにおける物理サーバと各種仮想化環境全体の管理を可能とするJP1/SC (Server Conductor)とVirtage固有の環境を管理するVirtage Navigatorを提供しています。

JP1/SCでは、物理サーバの考え方と同じ考え方でVirtageのLPARを管理することが可能であり、物理／仮想が混在していてもサーバブレード障害時にはJP1/SCがサポートするN+1コールドスタンバイ機能により予備サーバブレードに交代できます。また、物理サーバの場合と同様、Virtage上のLPARに対してもシステムディスクのバックアップ／リストア機能をサポートしています。

Virtage NavigatorはVirtage固有情報を詳しく見るツールで、性能モニタ、構成ビューア、LPARマイグレーション、LPAR操作・設定などの機能を持っています。

性能モニタ機能ではブレード全体や各LPAR内の論理CPU使用率、NIC性能などを表示します。これらの情報は管理サーバに蓄積でき分析が可能な他、CSV形式に変換し必要に応じて独自の分類・集計を行なうなど、データセンタでの運用報告書作成に利用することができます。構成ビューアは各ブレードのVirtageに関する構成情報を一括して収集・表示します。人手による管理は誤りを生じる可能性もありますから、機械的な情報収集機能はクラウドにおける構成管理の正確化、効率化に有効でしょう。

図1 Virtage環境固有の管理機能を持つVirtage Navigato

今回は仮想化環境の運用で考慮すべき項目についていくつかのポイントを挙げてみました。慣れない方にとっては心配毎が多いという印象を持たれるかもしれませんが、十分な技術力を持ったベンダーからサポートを受ければすぐ自分たちのノウハウとして身につく範囲ですので、ぜひ恐れずに仮想化への挑戦をしていただきたいと思います。

次回は最終回です。簡単におさらいをしてみましょう。

第5回コラム「サーバ仮想化のまとめ」に続く