あなたの知らないメインフレームLinuxの世界
第1回 メインフレームでLinuxが動くまで
日本アイ・ビー・エム株式会社
システムズ&テクノロジー・エバンジェリスト
北沢 強
2008/5/26
メインフレームLinuxの発現経緯
Linuxはその発展の中で、複数のCPUアーキテクチャに対応してきました。このため、マルチプラットフォーム対応のための標準化が進んでおり、1996年ごろからメインフレームへの対応を考えていた技術者も少なからず存在しました。その中には、メインフレームを開発している技術者のみならず、ユーザー企業の技術者やソフトウェアベンダの技術者などもいました。
有名なところでは、Linas Vepstas氏が、1998年からi370アーキテクチャの実装を開始していました。IBM社内でもいくつかの実験プロジェクトが存在しましたが、いずれも実験的なものであり、実用レベルにはありませんでした。
一方1990年代後半になると、インターネットの普及により、JavaやPerlでアプリケーションが開発されるようになりました。同時に、ユーザーインターフェイスとしてNetscapeに代表されるWebブラウザが主流となり、メインフレーム上の既存のCOBOLアプリケーションをどのようにWebやJava化させればいいのかが課題となっていました。
そこでIBM社内で検討されたのが、Linuxをメインフレーム上で稼働させるというアプローチです。
これを実現するため、IBMドイツのBoeblingen研究所の若手が中心となって、1997年より研究が開始され、1998年には実験的に動くカーネルが完成しました。ポーティングは数名で作業して、約3カ月で終わったそうです。Linuxが比較的容易にメインフレームに移植できたのは、以下の4つの理由によるものだと考えています。
- Linuxカーネルがすでに複数のCPUアーキテクチャに対応済みであり、別プラットフォームに対応するための仕組みや方法論が確立していたこと
- S/360の流れを汲むSystem zは、Linuxがリファレンス・アーキテクチャとしてベースにしているIA(Intel Architecture)の命令セットを、ほぼ包含していたこと
- Linuxはgcc(GNU C Compiler)を前提としており、gccが移植されていればLinuxの移植も容易となるが、gccはすでにメインフレームに対応していたこと
- メインフレームが持つ仮想化機能により、移植作業やテストが効率的に実施できたこと
ところが、メインフレームに移植されたLinuxは、すぐには公開されませんでした。顧客がメインフレームに求める品質や信頼性の要件を、Linuxで満たすことができるかどうかが未知数だったためです。
IBMはメインフレームLinuxの存在を1999年末まで社外秘にしていました。この間、パイロットユーザーを募り、限られた顧客にメインフレームLinuxを使ってもらい、評価してもらうことにしました。
その結果、すべてのパイロット顧客がメインフレームLinuxに価値を見いだし「これが欲しい」とコメントしました。顧客が求めるものを提供するのがメーカーの使命ですから、IBMはメインフレームLinuxを公開することに決めました。
これを受けて1999年12月18日に、IBMはdeveloperWorks上でメインフレーム用のLinuxカーネルパッチを公開しました。
Linuxは特定ベンダが提供する製品ではありませんし、著作権などの権利も特定のベンダに帰属するものではありません。しかしいまや、多くのハードウェアおよびソフトウェアベンダがLinuxをサポートし、サービス・ビジネスにおいてもLinuxを活用するようになりました。これは、ユーザー企業の多くがLinuxに価値を認め、Linuxを必要としたからであり、それにはメインフレームLinuxの出現が少なからず影響しているのではないかと筆者は考えています。
メインフレームでLinuxを動かすことの価値
PCで動くLinuxと同じものがメインフレームで動いて、いったい何がうれしいのか。初めてメインフレームLinuxが公開された当時は、この質問をたくさんいただきました。
メインフレームは以前に比べて格段に安くなったとはいえ、入手コスト (Total Cost of Acquisition)で比較すると、PCサーバにはまだまだ及びません。メインフレームは基幹業務を安定的に処理するために、RAS(信頼性・可用性・保守性)に重点が置かれているのに対して、PCは激しいシェア争いと価格競争の中で入手コストが重視されています。そのPCで発展してきたLinuxを、わざわざメインフレーム上で稼働させる価値は何でしょうか。
その答えの1つが、サーバ統合です。
高いスケーラビリティとパフォーマンスを持つメインフレームでは、仮想化技術により複数のシステムを1台のマシン上で並行稼働できます。サーバを統合した環境では、ハードウェア障害が全面障害に至ってしまうリスクが高くなりますが、メインフレームの高い信頼性や可用性、そして無停止での保守性・拡張性は、そのリスクを最小限に抑えてくれます。
また、メインフレームにはたくさんのI/O装置が接続でき、高いI/O能力を持つため、仮想サーバをたくさん稼働させてもI/Oネックとなることを避けられますし、I/Oの制御能力はLinuxのI/O脆弱性を補強してくれます。
メインフレームは長い歴史の中で、運用管理や障害検知・対応機能が洗練されており、ハードウェアに実装されている機能は、そのままLinuxでも享受できます。仮想化OSであるz/VMを使用することで、より柔軟な統合管理がメインフレーム品質で実現できると同時に、高効率な統合が可能となり、数百という数のサーバを仮想的に統合できるようになります。
図1 メインフレームによるLinuxサーバの統合 |
つまり、メインフレームが長い年月をかけて育て上げた高品質・高信頼のためのさまざまな機能と、Linuxのオープン性・経済性の利点の両面を生かし、サーバ統合による集約化によってTCO削減を可能にすることが最大の価値だといえます。
[予告]第2回 |
メインフレームは長い歴史の中で、品質改善と機能追加を繰り返してきました。いわば、究極の信頼性を持つコンピュータだと思います。メインフレームについては、System/360が情報科学の教科書に出てくるアーキテクチャや歴史の説明以外では、書店に並ぶ一般書籍や雑誌で取り上げられることはほとんどないため、実装や機能がどういうものなのか意外と知られていないのかもしれません。そこで、次回は「メインフレーム温故知新」と題して、メインフレームの歴史をひも解きながら、その設計思想や概念、実装における特徴などについて解説します。 |
2/2 |
|
||||
|
- 【 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」コマンドです。
|
|