第2回 メインフレーム温故知新
日本アイ・ビー・エム株式会社
システムズ&テクノロジー・エバンジェリスト
北沢 強
2008/7/23
メインフレームの仮想化技術
Wikipediaによれば、「仮想化」とはコンピュータにおいてリソースの抽象化を表す用語だとあります。言い換えると、物理的なもの(リソース)を抽象化して論理的なものにすることです。
1つの装置を論理的に分割して複数の装置として使う、あるいは、複数ある装置を論理的に束ねて1つの大きな装置として使えるようにするのが仮想化技術です。メインフレームの実装の中でも最も特徴的なのは、この「仮想化技術」です。仮想化技術は、メインフレームの長い歴史の中で熟成してきたテクノロジだといっても過言ではないと思います。
仮想化技術の種はS/360以前にも存在していましたが、商用として本格的に実装されたのはS/360でした。1967年にS/360上で稼働した「CP-67/CMS」(Control Program-67/Cambridge Monitor System)が起源だといわれており、MITのリンカーン研究所が最初のユーザーでした。このCP-67は、現在のメインフレーム用仮想化OSであるz/VMの源流であり、1988年にハードウェアで実装された「PR/SM機構」(LPAR機能の製品名)は、カーネルであるCPをマイクロコード化したものです。
40年前当時は、コンピュータが非常に高価であったため、限られたハードウェア資源をいかに効率的に使うか、あるいは複数ユーザーでいかに同時並行的に使うかが課題でした。それを解決するために、1960年前後より研究されていたタイム・シェアリング(時分割処理)によってCPUを仮想化し、少ないメモリを効率的に使うために仮想記憶を実装しました。つまり、限られたハードウェア資源を、その機能や特徴を損なわずに効率的に使うテクノロジとして仮想化が生まれたのです。
現在、仮想化が注目されている理由は、当時のメインフレームが目的とした仮想化とは若干異なる文脈からです。サーバやディスクやソフトウェアがたくさんあって複雑になり過ぎたので、サーバ台数を減らして簡素化したい、というような運用管理面からの要件が強いように思います。
ただ、リソースを分割するにしても、共有するにしても、あるいは動的な変更をするにしても、物理的な装置をソフトウェアから抽象化して切り離す必要があります。そこで仮想化技術が必須となるわけで、メインフレームが熟成してきた技術が応用できるのです。
仮想化における課題、オーバーヘッド
仮想化における最大の課題は、仮想化による「オーバーヘッド」です。仮想化するということは、分割するにせよ共有するにせよ、ソフトウェアによって判断したりエミュレーションしたりするため、それが余分な負荷となるのです。
オーバーヘッドがあると、実際に使える能力が減り、正確さを損ねることもあります。特に刻時機能(クロック)に正確性が求められる場合は、それが信頼性にも影響してしまいます。
最近、PC上で仮想化技術を使っていて、不安定になったりハングアップを経験したり、I/Oのオーバーヘッドが異常に大きいという経験をした方もいるのではないでしょうか? PCの世界では、40年前からメインフレームが戦ってきた仮想化オーバーヘッドを、いままさに経験しているのです。
CP-67より以前から、仮想化オーバーヘッドが課題として認識されていました。CPUと同様に高速性が要求されるのがメモリですが、仮想記憶を使うと、メモリ・アドレスの実アドレスと仮想アドレスへの変換が必要となります。そのアドレス変換処理がオーバーヘッドとなって、パフォーマンス劣化が顕著でした。
そこで、CP-67はハードウェアにDAT(Dynamic Address Translation)を実装したS/360モデル67上で稼働することで、メモリの仮想化オーバーヘッドを減らすことに成功し、S/370以降はDATが標準になりました。
当時はまた、仮想マシンのCPUオーバーヘッドも問題でした。特に、実マシンなのか仮想マシンなのかを判断するためのオーバーヘッドが大きく、課題となっていました。
それを解決するために、1983年のVM/XAとともに「SIE(Start Interpretive Execution)」がマイクロコードで実装されました。VMは、ゲストで動く仮想マシンにディスパッチするときにSIE命令を使用します。こうすることで、その後の仮想マシンでの実行はSIE命令の一部として実行される、つまり、VMを介さずマイクロコードが実行するため、30〜40%程度あったVMによる仮想化オーバーヘッドを劇的に減らすことができました。
このSIE命令と同等の機能が、つい最近、PCの世界でも「Intel VT」あるいは「AMD-V」として実装されるようになりました。
I/Oについても、当時は仮想化のオーバーヘッドが顕著でした。メインフレームのI/Oはチャネル・プロセッサによって制御されるのでCPUの負担は小さいのですが、仮想マシンとして稼働するゲストOSからI/Oが実行された場合は、オーバーヘッドが大きくなります。I/O命令を仮想から実装置に変換したり、I/Oバッファ・メモリについても実アドレスと仮想アドレスの間で変換するなど、仮想化の内部処理が複雑になるからです。
そこで、「CP Assist」機能ではマイクロコードの中でI/O命令の変換をしたり、Zone RelocationによってI/OバッファのDAT変換を省略するようにすることで、I/O仮想化オーバーヘッドを20%以下にまで抑えました。
これと同等の機能は、最近になって実装された「Intel VT-d」に該当します。ただ、WindowsやLinuxなどOS側での対応に加え、XenやVMwareのようなソフトウェアでの対応が必要なため、利用可能となるまでには時間がかかるでしょう。
以上のように、メインフレームでは後述するマイクロコードにより、ハードウェア内で仮想化オーバーヘッドを削減する努力をしてきました。これはVMというOS(ソフトウェア)とハードウェアを一体でIBMが開発しているから実現できたのかもしれません。システムとして全体最適化していく過程で、新しい機能をソフトウェアで実装してテストし、それを単純化するためにマイクロコードで実装し、それが安定したら最終的にはCPU内の回路にして高速化するというステージングによりチューニングされていきます。
最近になって再び仮想化が注目され、25年前にメインフレームで実装された仮想化チューニング技術が、いまになってPCやUNIXの世界で使われるようになってきました。あえてメインフレーム側からいわせてもらうと、学ぶことはまだまだたくさんありますね。
メインフレーム上ではLinuxを数百個も稼働できますが、それを実現しているのがこの仮想化技術です(図2)。長い歴史の中でチューニングされたため、ほとんどオーバーヘッドなくLinuxを動かすことができます。
図2 仮想化によるLinuxサーバ統合 |
2/3 |
|
||||||
|
- 【 pidof 】コマンド――コマンド名からプロセスIDを探す (2017/7/27)
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、コマンド名からプロセスIDを探す「pidof」コマンドです。 - Linuxの「ジョブコントロール」をマスターしよう (2017/7/21)
今回は、コマンドライン環境でのジョブコントロールを試してみましょう。X環境を持たないサーバ管理やリモート接続時に役立つ操作です - 【 pidstat 】コマンド――プロセスのリソース使用量を表示する (2017/7/21)
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、プロセスごとのCPUの使用率やI/Oデバイスの使用状況を表示する「pidstat」コマンドです。 - 【 iostat 】コマンド――I/Oデバイスの使用状況を表示する (2017/7/20)
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、I/Oデバイスの使用状況を表示する「iostat」コマンドです。
|
|