最終回 メインフレームLinuxの今後
日本アイ・ビー・エム株式会社
システムズ&テクノロジー・エバンジェリスト
北沢 強
2009/2/16
データセンターが抱えるさまざまな課題と解決策
ITに掛かるコスト全体(TCO)の変化を見ると、ここ数年、新規投資は対前年度比で横ばいが続いていますが、運用管理に掛かるコストは年々増加し、TCO全体を押し上げる傾向にあります。運用管理コストは、いい換えれば運用・管理にかかわる人件費です。運用管理の生産性・効率性を高めることができれば、運用要員を投資すべきエリアにシフトでき、全体としてコスト削減効果が見込めます。
ムーアの法則により価格性能比が高まる中、サーバの取得コストは低下しています。一方で安易にサーバを増やしていくと、それを運用する要員コストは増大し、消費電力や空調、設置スペースなども増えてしまうことが課題として認識されるようになりました。その解決のために、近年は仮想化技術の適用によるサーバ統合が一般的になってきました。
以前の記事で、このような状況は、統合と分散を繰り返すというITの歴史の流れの中で必然的に起こっているものととらえることもできると解説しました(第5回「広がるメインフレームLinuxの適用領域」参照)。
しかしながら、分散したものを仮想化によって物理統合しただけでは、論理的あるいはソフトウェアの観点では、開発においても運用管理においても大きな削減効果は期待できません。そこにはトップダウンによる長期ビジョンと戦略が必要になります。IBMでは統合をどのように進めるべきかについて、「次世代エンタープライズ・データセンター(New Enterprise Data Center:NEDC)」というコンセプトに基づいて、以下の3段階で進めていこうというビジョンを示しています。それをちょっと紹介しようと思います。
ステージ1:物理統合による簡素化
ステージ2:資源プールによる共有化
ステージ3:サービス仮想化によるダイナミック
仮想化技術を適用した物理統合は最初のステップであり、メインフレームLinuxによって分散しているUNIXやWindowsサーバを統合し、サーバのハードウェア台数を減らすことでデータセンターを簡素化します。
すでにメインフレームLinuxを採用しているユーザー企業の多くは、ステージ2である共有資源プールを持つ段階にあるでしょう。共有化は、複数の仮想サーバが存在するインフラ全体で最適化するもので、個別のサーバ管理よりも資源プール管理やサービス管理に運用主体が移ります。できるだけリソースの共有効率を高めて冗長性を減らし、共有環境における制御性を強化すると同時に自動化も行うことで、運用管理にかかわるところを省力化していきます。共有プールによって、柔軟性を確保し、変化に強いシステムを実現するわけです。
共有化においてはアンサンブルと呼ばれる管理方法を用います。アンサンブルは今年から来年にかけてデータセンターに普及していくと予想され、これにより仮想資源プールによる運用が一般的になるかもしれません。
クラウド・コンピューティングへの方向性
NEDCでは、最終段階としてクラウド・コンピューティングの世界を想定しています。
インターネットの世界ではGoogleやAmazonなどがすでにサービスを開始しています。今後は企業が利用するデータセンターにおいてもクラウド化が進んでいくと予想されており、IBMも含めた多くのITベンダが、クラウドへの取り組みを始めています。
メインフレームは、Linuxによってクラウドにおける先進技術を取り込みやすくなりました。もともと集約統合型を指向しているメインフレームは、1台の筐体の中でクラウド・コンピューティングを実現し、マルチテナンシー基盤を統合型で構築することを狙ったものともいえます。
メインフレームが向かう道
メインフレームを解体するとよく分かるのですが、筐体の中には、メインフレームのプロセッサ以外にたくさんのプロセッサが使われています。
例えばI/Oアダプタカードを見ると、1枚につき2個のPowerPCプロセッサが搭載されており、そのカードが蛇腹のように何十枚も刺さっています。暗号化プロセッサも専用で搭載していますし、ハードウェアの制御にはIntelプロセッサも使っています。
メインフレームというのは、さまざまなテクノロジを高度な集積技術によって統合し、全体を1つの箱としてメーカーが保証するという製品なのです。この考え方は今後も変わらないでしょう。
ですから今後、大量の高速演算処理が必要になれば、さらに高速な演算専用プロセッサをメインフレームに搭載するかもしれませんし、SOAにおけるSOAPを大量に処理する必要が生じれば、SOAPアクセラレータを搭載するようになるかもしれません。基幹システムとしての重要なデータとアプリケーションがメインフレーム上にあるわけですから、そのデータに一番近いところで処理するのが、パフォーマンス上もセキュリティ上も最適なはずです。そして、それらの新しい処理機能を含めて一体でメーカーが品質保証することには、メリットがあるといえるでしょう。
IBMメインフレームの中には、マイクロコードとして、複数の組み込みLinuxが内蔵されています。ハードウェアを制御するHMC(Hardware Management Console)はLinuxで動いていますし、List Directed IPLというブート機能でもLinuxをスタータとして使用しています。これからさらに、メインフレームとLinuxの相性はどんどん良くなっていくかもしれませんね。
まとめに代えて
6回の連載を通して、メインフレームLinuxの特徴を知っていただけたのではないかと思います。できるだけ歴史的経緯や背景を説明するように努力しました。おそらくメインフレーム以外のプラットフォームにおいても同様な課題があるでしょうから、ここで紹介した解決策が何かの参考になれば幸いです。
世界的な不況もクラウド化の波も、メインフレームLinuxにとっては追い風です。ぜひこれからの進撃を見守ってください。
コラム■メインフレームLinuxが動くのはIBMだけ? |
時折、メインフレームLinuxはIBMメインフレームでしか動かないのか、という質問をいただきます。連載第1回のコラムでも紹介したとおり、「メインフレーム」という言葉の解釈にもいろいろあるのですが、ここではIBM互換メインフレームに限定して紹介します。 富士通、日立、アムダールなどで製造・販売されてきたIBM互換メインフレームは、現在でも世界中に多数存在し、稼働しています。ハードウェア・アーキテクチャが同等ですから、非互換部分に対するわずかな修正追加だけでLinuxは稼働できます。具体的には、各メーカー独自のI/O装置をサポートするためのデバイスドライバを用意すれば、Linuxカーネルはブートできるでしょう。 例えば、アムダールのメインフレームはIBMメインフレームと完全互換であり、アムダール製メインフレーム上でLinuxを稼働させているユーザー企業もすでに存在します。また、日立では2000年ごろからコンソール用デバイスドライバを開発し、メインフレームLinuxを日立製メインフレームに対応させていました。当時の日立のエンジニアは、Marist CollegeにあるメインフレームLinuxコミュニティの中で積極的に活動していました。TurboLinux社から日立メインフレーム用のディストリビューションが販売されていたこともあります(筆者注:現在は販売されていないようです)。 各社のメインフレームでLinuxを動かすこと自体の技術的なハードルは、それほど高くありません。しかしそれがビジネスモデルとして成立するかどうかという観点から、高度な判断、戦略が求められることは想像に難くありません。 |
3/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」コマンドです。
|
|