LPAR仮想化環境の運用管理

サーバー管理ツール

第1回では、サーバー仮想化の特徴として「物理サーバーの台数を減らすことができるので、運用管理が容易になる」という点を解説しました。

実は、このシナリオには落とし穴があります。確かに、既存のサーバー構成をそのまま仮想化環境に移行するだけであれば、運用は単純に楽になります。しかし、話はそう簡単ではありません。物理サーバーが減る一方、仮想サーバーの台数が増えてしまうため、かえって管理の負荷が大きくなるのです。

例えば、開発用サーバーは、設置スペースの関係から、これまでは数人で1台でした。これが、仮想サーバー環境では、一人1台になります。そもそも、サーバー機の調達にともなう作業（予算の確保、発注／納入など）を必要とせずに短時間で新規の仮想サーバーを追加できる手軽さから、仮想サーバー台数は増加していく傾向にあります。

サーバーの台数が著しく増加した環境下では、サーバーをいかに運用管理するかが重要です。

日立製作所のブレード・サーバー「BladeSymphony」は、サーバー管理ソフト「JP1/SC」（JP1/ServerConductor）を用いて管理します。特徴は、物理サーバー環境と仮想サーバー環境を1つの画面で管理できることです。一般的な運用管理ソフトとは異なり、物理と仮想で別個の管理ソフトを使い分ける必要がありません。

図1は、JP1/SCシリーズの1つである「JP1/SC/BSM」（Blade Server Manager）の管理画面です。

図1の左端は、サーバー仮想化環境であるHVM（Hitachi Virtualization Manager）の構成画面です。画面によれば、1台のシャーシに2枚のブレードが装着されており、このうち1枚目のブレードに3台のLPAR（論理パーティション）が定義されています。

図1の左から右にかけて展開する画面の流れは、新たに4台目のLPARを定義する操作の遷移です。LPARの名称を決め、メモリーを割り当て、I/Oを設定するなど、LPARごとに必要な個別のパラメータを決めていきます（図1では、説明のために簡単化しています）。

N+1コールド・スタンバイとデプロイメント管理

第3回で、HA（高可用性）構成のための機能として、N+1コールド・スタンバイを解説しました。これは、「1台の予備サーバー・ブレードを用意しておけば、サーバー障害の際に、仮想化環境の予備にもなるし、物理環境の予備にもなる」という機能です。

N+1コールド・スタンバイも、JP1/SCが提供する、障害検出の機能や切り替え制御の機能によって実現しています。「仮想化環境と物理環境を統合して管理できる」というJP1/SCの特長が、ここでも生きています。一方で、一般的な仮想化環境では、物理サーバー専用の予備機と仮想化環境専用の予備機を、それぞれ別個に用意しておく必要があります。

JP1/SCには、デプロイメント管理製品として「JP1/SC/DPM」（Deployment Manager）があります。管理対象の物理サーバーや仮想サーバー（LPAR）に対し、LAN経由でOSイメージを配布したり、バックアップをとったりするソフトです。ここでも、物理サーバーと仮想サーバーを区別することなく、配布（デプロイメント）やバックアップが可能です。

実際問題として、仮想サーバーに対してデプロイメントを実行するのは、それほど簡単なことではありません。なぜなら、OSを含むシステム・イメージを配布するためには、対象システムを停止した状態で、リモートからLAN経由でデプロイメント制御用のプログラムを送り込む必要があるからです。

物理サーバーの場合、対象システムのOSが停止していても、LANボードが物理的に存在しています。このため、デプロイメント制御用のプログラムを送り込むことができます。しかし、仮想化環境の場合、仮想サーバーが停止していると、そのLANボードは（仮想的なものなので）存在しなくなり、制御用のプログラムを送り込むことができなくなってしまいます。

JP1/SCでは、Virtageと連携することで、この問題を解決しています。JP1/SCでは、仮想サーバーへのデプロイメントが可能なのです。