【メインフレーム編】時代を先取りするメインフレームの仮想化技術 - 進化するITプラットフォーム Part5

仮想化の起源は40年以上前のメインフレームにある。時代背景こそ違うが、ハードウェア資源をいかに有効に活用するかという狙いは、最近オープン系サーバーで普及し始めた仮想化を先取りしたものだ。オーバーヘッド対策など、メインフレームが培ってきた仮想化技術を解説する。

仮想化技術はメインフレームの進化とともに開発され、熟成されてきたと言っても過言ではない。その歴史は、40年以上も前にさかのぼる。

当時はコンピュータが非常に高価だったため、限られたハードウェア資源をいかに効率的に使うか、あるいは複数ユーザーが同時並行的に使えるかが課題だった。それを解決する方法の1つが、1960年頃から研究が本格化していた「タイム・シェアリング（時分割）処理」である。これによってCPUのアイドル時間を減らし、稼働率を大幅に高められるようになった。

もう1つが、高価ゆえ小容量しか搭載できなかったメモリーを、あたかも大量に搭載しているかのように見せる「仮想記憶」である。仮想記憶を実現するには実（物理）メモリー空間と仮想メモリー空間のアドレス変換を効率よく行う必要がある。そこでIBMは、S/360モデル67に「DAT（Dynamic Address Translation）」と呼ばれるアドレス変換用ハードウェアを実装。アドレス変換のオーバーヘッドを減らすことに成功した。S/370以降はDATが標準になっている。

こうした機能をサポートする仮想化ソフトが1967年にリリースされた、System/360向けの「CP-67/CMS」（Control Program-67/Cambridge Monitor System）である（CMSは後にConversational Monitor Systemに改称）。CP-67は、現在のメインフレーム用ハイパーバイザであるz/VMの源流に相当する。

オーバーヘッドを解消する

仮想記憶の例から明らかなように、仮想化における最大の課題はCPUやメモリーなどの共有・分割に伴うオーバーヘッドだ。オーバーヘッドがあるとシステム全体の実効性能が低下するうえ、場合によっては処理の正確さを損ねることも起こり得る。結果としてメインフレームに求められるRAS（信頼性、可用性、保守性）に影響する。そのためオーバーヘッドを減らす試みや技術開発が行われてきた。

例えば、実マシンなのか仮想マシンなのかを判断するオーバーヘッド。これを解決するために、IBMは仮想化ソフト「VM/XA」のリリースと同じ1983年に、ハードウェアに「SIE（Start Interpretive Execution）」をマイクロコードで実装した。VMは、ゲストで動く仮想マシンに処理を割り当てるときにSIE命令を使用することで、その後の仮想マシンでの実行は「SIE命令の一部として実行される」、つまりVMを介さずにマイクロコードが実行するため、VMによる仮想化のオーバーヘッドを劇的に減らすことに成功した。SIE命令と同等の機能は、IAプロセサの世界でも最近、「Intel VT」あるいは「AMD-V」として実装されるようになっている。

I/Oに関しても、仮想化のオーバーヘッドは大きな問題だった。メインフレームのI/Oはチャネル・プロセサが制御するので、CPUの負担は元々小さい。しかし仮想マシンとして稼働するゲストOSがI/Oを要求した場合は、I/O命令を仮想から実装置に変換したり、I/Oのバッファ・メモリーも実アドレスと仮想アドレスの間で変換したりする必要がある。仮想化の内部処理が複雑になる分、オーバーヘッドが大きくなるわけである。

そこで仮想化ソフトではなく、マイクロコードの中でI/O命令を変換する「CP Assist」、I/OバッファのDAT変換を省略する「Zone Relocation」といった機能を実装。仮想化に伴うI/Oのオーバーヘッドを低減した。これと同等の機能が「Intel VT-d」である。

System zにおける仮想化技術

メインフレームは独自仕様であるがゆえに、アーキテクチャが明確に定義されており、その根幹部分に仮想化がある。CPU、メモリー、I/O、周辺機器など、システム資源のすべてを「完全仮想化（full virtualization）」している（図5-1）。つまり、すべての資源に実アドレスと仮想アドレスがあり、時分割処理やアドレス変換処理などによって実資源と仮想資源を動的にマップすることで、仮想マシンを実マシンと変わらずに使えるようにしている。ソフトウェアによるハードのエミュレーションをすることも容易になった。例えばNIC（ネットワーク・カード）をエミュレートしたり、ディスク装置を、テープ装置代わりに使ってバックアップの時間短縮を図るといったことが簡単にできる。

図5-1　z/VM 仮想化アーキテクチャ（図をクリックで拡大）

ここで最新のメインフレームであるSystem zの仮想化に触れておこう。

具体的な製品には、ハードウェアとして実装されている「PR/SM」（Processor Resource/System Manager＝プロセサ資源/システム管理機構）と、ハイパーバイザ方式の仮想化OSである「z/VM」の2つがある。

1988年に実装されたPR/SMはLPAR（論理区画）の機能名称である。1台のメインフレーム上に複数のLPARを作り、CPU、メモリー、チャネルといった資源をLPARに柔軟に割り当てる。それぞれのLPARでz/OSやz/VM、z/VSE、LinuxなどのOSを稼働する仕組みだ。

PR/SMの実体は、z/VMのカーネルであるCPの機能を絞ってマイクロコード化したものだ。したがってz/VMとPR/SMの設計思想や内部アルゴリズムはほぼ同じ。違いはPR/SMがハードウェア機構であり、LPARの上限数などに制限があること。z/VMはソフトウェアなので、実用上の上限がない。

こうしたSystem zの仮想化技術は現時点でも先端的だが、完成したわけではない。今後は、統合化への対応とクラウドコンピューティングへの対応を果たしていく必要がある。統合化に関しては、仮想化技術に常につきまとうオーバーヘッドの改善がテーマ。その1つが、特定機能を高速化するためのアクセラレータの統合だ。

クラウドへの対応では、運用面における柔軟性や高度な自動化が求められる。そのために今後は、仮想化によってシステムの運用管理面を切り離し、サービス単位で管理していくように変わっていくことになるだろう。将来はSystem z上で統合型クラウドが実現されるようになるが、高信頼で高効率なクラウド環境の実現のために、更なる仮想化技術の実装が進んでいく。