Zにすべきかせざるべきか、それがIBMメインフレームの問題
| IBMの「MIPS」は、メインフレーム・ファミリー内だけで通用する相対的な指標である。したがって、z900-1G2の速度は476 MIPSであり、実際には239 MIPSのz900-101の約2倍の速度に相当する。しかし、このような数値をSun Fire 15Kの21,000 MIPSと比較するのは無意味なことである。
MIPSはもともとSystem 360の1秒間当たりの命令実行回数を100万回単位で表す尺度であったが、やがてコンピュータの性能指標として使われるようになった。現在、4ウェイのz800は636 MIPSとされているが、だからといって1974年に発表された1 MIPS 370/158の600倍のスループットが得られるわけではない。 |
方向転換という選択に対しては、ハードウェア環境は既存のソフトウェアをサポートしなければならず、既存のソフトウェアは個々の顧客向けにカスタム開発されていて、それぞれの導入環境と切り離すことはできないといった議論がよく聞かれる。しかし、ほとんどの顧客は、100 MIPS以下のVM/VSE System 390か、それ以前のマシン環境にある。
このような旧型マシンを使用している顧客は、ほとんどの場合、WindowsベースのPCサーバやデスクトップも導入しており、コスト、管理、信頼性の問題に悩まされている。
IBMはこうした企業に対する第1の対応策として、メインフレームとLinuxの両方のソフトウェアを、IBMの最小メインフレームであるz800上で稼働させるという方法を提案している。このようにすれば、旧型メインフレームのアプリケーションとMicrosoft Windowsサーバの機能のほとんどを、信頼性が高く比較的低コストな1台のマシン上で統合できるうえに、顧客企業のスタッフは今まで培ってきた知識や経験を新しいマシンにも生かすことができるというのがIBMの売り文句である。
またIBMは、もう1つの選択肢として、メインフレームとLinuxの関係を逆転させた形でLinuxとメインフレームのソフトウェアを1台のマシン上に統合し、同時に稼働させる手段も提供している。つまり、メインフレームのプロセスとしてLniuxを稼働させるのではなく、Intelプロセッサを2つ搭載したIBM Netfinity上のLinuxプロセスとしてメインフレームをエミュレートするのである。
このような2種類のアップグレード・オプションの選択を迫られている企業は、次に示す5つの情報を集める必要がある。
- 組織の情報 — 仕事量、技能、変革への耐性、対応できる人材
- z800を選択した場合のコストと能力の概要
- Netfinityを選択した場合のコストと能力の概要
- この2つの方法の利点の判断方法
- 現在、または近い将来に入手可能なその他の選択肢
この記事は特定の組織を対象としたものではないので、上記の1番については取り上げないが、その他の4つのポイントについて考察していくことにする。
z800を選択した場合
IBMは、アップグレードを検討している企業に対して、Windowsサーバの負荷の多くをLinuxに移行し、従来型のメインフレーム動作環境とLinuxをz800上で並行稼働させれば統合が可能であると主張している。
z800は、IBMがローエンドのzSeriesアーキテクチャとして販売しているHitachi製の製品である（日本ではHitachiブランドとして販売）。現在、フルライセンスのz800（メインフレームは出荷前に完全に構成され、顧客のハードウェア・アクセスはライセンスで制限されている）は、SMP CPUを最大4個まで搭載可能で、最大処理速度は920MHzである。ただし、次世代機は約1.4GHzになるとの噂もある。
z800の最下位モデルである0E1のライセンスでは、40 MIPSの従来型メインフレームCPUサブシステム（IBM風に言えばエンジン）1つと、192 MIPS（770MHz）のLinux専用機構が提供される。後者はIFL（Integrated Facility for Linux）と呼ばれている。この構成の購入価格は、IFLを使用可能にするかどうかに関わらず約240,000ドルである。これに加えて、このユニットの保守料金として月額約2,563ドルを支払う必要がある（32GBメモリが搭載されたフルライセンスの4ウェイz800の場合は、購入価格約140万ドルに加え、月額保守料金が12,800ドルかかる）。
複数のLinuxインスタンスを稼働するために必要なzVMの費用は一括料金の購入価格で22,500ドル。SuSE Linuxがプレインストールされている場合は、サポート付きで一括購入価格約35,000ドルと月額料金1,200ドルが必要となる。
ユーザは既存のESCON（SCSI2など）周辺機器を接続することもできるが、2つのFICON（Fibre Channelコネクタ：約100MB/sec、各16,000ドル）上に840GBのRAID Enterprise Storage Server（ESS）IBM F20アレイを搭載すると、基本システムの購入価格は約480,000ドルになる。
| z800-0E1基本システムのコスト概要 | |||
|---|---|---|---|
| コンポーネント | 初期コスト | 月額料金 | 3年間の合計 |
| Base z800-0E1 | $240,000 | $2,563 | $332,268 |
| zVM, SuSE for IFL | $35,000 | $1,200 | $78.200 |
| 2 x 840GB ESS Disk Arrays | $252,000 | $3,150 | $365,400 |
| 合計 | $775,868 | ||
注：
| |||
この価格表には、マシンのメインフレーム側ソフトウェアの価格は含まれていない。なぜなら、この記事で論じている2つの選択肢では、z800上でネイティブモードで稼働されるか、Intel上のLinuxエミュレータで稼働されるかという違いはあるものの、同じメインフレーム・ソフトウェアが使用されるので、ソフトウェアの価格を比較しても無意味だからである。
ただし、メインフレーム・ソフトウェアのコストは、Unixと違ってハードウェアのコストに応じて決められていることは知っておいた方がよい。ほとんどすべてのソフトウェアは、個別にライセンス料が定められており、その価格はハードウェアの能力によって大きく分類されている。たとえば、ローエンドモデルのz800-0E1は、zELC（zSeriesエントリーライセンス料金）に相当し、その典型的な月額ライセンス料金は、次のようになっている。
- Program 5740-XXH、feature 4004（RACF、基本的なユーザ・アクセス制御機能を提供）：約882ドル
- IBM C/C++コンパイラ：約793ドル
- VM/VSE用のTCP/IP接続機能：89ドル
- DFSORT：309ドル
- IMS V7データベース：3,686ドル
z800-0E1基本モデルでは、メインフレーム側の性能として、40 MIPS（1エンジンの約1/3）と、4つのFibre Channelコネクタ上のディスクを管理するSAP（System Assist Processor）の機能が得られる。ハードウェア・レベルでは、バッファ・ディスク・パック接続用の400MB/secのFireWireコネクタと多数のRAMを装備した330MHzのMacintoshワークステーションの性能にほぼ匹敵すると考えられる。
ただし、従来型アプリケーションをz800上で使用する場合、デスクトップ機とは処理パターンが異なるため、はるかに大きなスループットが得られる。たとえば、メインフレームはバッチ志向の処理方式なので、デスクトップ機のようなプロセス・スイッチングのオーバーヘッドはほとんど生じない。また、通常はOSとアプリケーションが高度に最適化されているので、処理中のマシンのリソース「フットプリント」は最小限で済む。
Linux側の性能は、1「エンジン」のフル機能とI/Oおよび関連タスク用のSAPへのアクセス機能である。zVMを使用する場合の性能は約192 MIPSになる。
IBMの2つの資料を見ると、zVMを使用してzSeriesエンジン上でLinuxを稼働させた場合の性能をおおまかに知ることができる。これらの資料の1つはIBM RedPaperの『Server Consolidation with Linux on Zseries』で、これには次のような数値が記載されている。
単純な計算例（非公式な構成）：
IntelシングルCPUマシン100台
クロックスピード200MHz
CPU利用率5%
上記で実行される負荷は、80% CPU利用率で稼働するz800では、
2〜3個のプロセッサ（CPU）で処理できる。
つまり、100 x 200 x 0.05 = 1,000なので、Intelの1,000メガサイクル/秒がz800の2〜3エンジンに相当する。
IBMのもう1つの資料、『Performance Tuning Linux for the zSeries』は、コアLinuxコードの問題より、プロセス・スイッチングや、デバイス・エミュレーション、Linux I/OをzVMのメモリやストレージ管理に対応づける機能の問題の方が性能への影響が大きいと示唆している。
この資料の著者は、デュアルIFL構成のz900を使用して、ベンチマーキングではなく性能調整を行い、zVM管理のRAMディスクへのスワップを40MB/秒にした。さらに実験的に高性能ドライバを使用して調整し、4つのFibre Channelで接続された8つの物理ディスクへの読み取り速度を120MB/秒にした。
しかし、このような比較は十分なものとはいえない。新しいIntel機とメインフレームの違いは、ハードウェアではなく、考え方の違いなのである。Unixリソースは安価なので、全体の利用率は気にせず、ユーザが求める応答時間に合わせて、規模を調整できる。一方、メインフレームの世界では、リソースが非常に高価であるため、平均需要に基づいて規模を調整し、システムの利用率を高く保つことが重要視される。
このようなメインフレームのアプローチが機能するのは、マシンを個別のジョブに長時間専念させてタスクの切り替えやこれを可能にするOSのオーバーヘッドを相殺できるような負荷パターンが可能な場合である。これは、60年代式のバッチ処理や、そこから派生した現在の処理方法には当てはまるが、MicrosoftやUnixのオペレーティング・システムの設計で想定されている双方向の負荷には当てはまらない。
こうした考え方の違いは、IBMが提唱する統合論に大きな問題を投げかけている。90%以上の利用率を得ることは、高価なマシンの処理能力を無駄にしないという意味でメインフレームの世界では当たり前のことである。この考え方からすると、2GHz CPUが5%の利用率で動作するPCサーバを10台稼働させるというのは、完全にしろうとの発想であり、1台の2ウェイz800に統合して利用率を最大化するのがまっとうなソリューションとなる。しかし、実際には、Intel CPUは低価格なので、無理に利用率を最大化する必要はない。むしろ、無理に利用率を上げれば、ユーザへの応答性能が悪化して、ユーザを怒らせることになる。ユーザをいつも待たせる状態にしなければ利用率の大幅な増加は達成できないからである。
Linuxでメインフレームをエミュレートする場合
Fundamental SoftwareのFlex-ESは、ソフトウェアでzSeriesを実現するIBM認定製品である。この製品を使用するには、少なくとも2プロセッサのマシンが必要となる。一方のCPUはメインフレーム・エンジンをエミュレートし、もう一方では、メインフレームでI/O要求を管理しているSAPのエミュレーションを実行する。
| Flexは現在、SCO Unix版しか販売されていないが、開発者はLinux版を入手できる。IBMの誰かがSCO Unixを既定の選択肢にしようとしているのだろうか。 |
この製品の性能レポートはいろいろあるが、どれを見ても、2プロセッサ構成の1GHz Intel Pentium IIIサーバ上で稼働するFlexは、約20 MIPSのzSeriesと同等の処理能力を持つと考えてよさそうだ。なかには、2プロセッサ構成の2.8GHzマシンなら120 MIPSに相当するというレポートもいくつかある。また、このエミュレータで標準のUnixディスクとI/Oチャネルを使用すれば、同等のメインフレーム（Intel上のFlexの代替として、または補強としてよく使用される製品）よりもはるかに高速のI/Oが実現されることも確かなようである。
この製品のリセラーのなかには、Webサイトで技術情報を提供しているところもある。たとえば、Zframeのサイトでは、重要な機能や問題についてかなり詳細な情報が提供されている。また、T3 Technologiesは、250件以上の導入実績があるとして、同社のサイトでさまざまな顧客導入事例を紹介している。
しかし、Flex-ESの価格は一般には明かされていない。FunsoftのPeter Ward氏によると、製品のライセンスはリセラーを通じて販売されており、顧客はソフトウェアだけでなくサポートも必要としているため、価格はリセラーによって異なるという。
一方、1998年のプレスリリースには、次のように記載されている。
FLEX-ESL（約8 MIPS） – 基本システムには、128メガバイトのメインメモリ、内蔵RAIDディスク・サブシステム、限定ディスク（ミラー化2ギガバイト未満）が含まれる。このモデルは拡張性が高く、手ごろな価格でディスク、チャネル、メモリを増設できる。また、IBMのESLソフトウェア料金のカテゴリに相当する。定価：$15,992FLEX-ESO（約22 MIPS） – 基本システムには、256メガバイトのメインメモリ、内蔵RAIDディスク・サブシステム、限定ディスク（ミラー化5ギガバイト）が含まれる。このモデルも拡張性が高く、手ごろな価格でディスク、チャネル、メモリを増設できる。この製品はFSIが設定したマシン・ソフトウェア・グループのグループ35に相当する。表示価格：$43,978
私が得たその他の情報から考えると、インストール前のFlex-ESの相場はMIPS当たり800ドル程度で、これにハードウェアのコストが追加されているようである。
この価格に基づいて推測すると、2GB、2 x 2.8GHz Xeon、デュアルRAIDコントローラ（各36GB、15K RPMドライブ×8）構成の2プロセッサNetfinity X235で18 MIPS相当のFlexを稼働させる場合のコストは約35,000ドル、80 MIPSバージョンなら約92,000ドルになる。
つまり、上記のx235に40 MIPSのFlex-ESライセンスと2TBのIBM FAStT600 Storage Array（Linux対応ホスト・アダプタ付属）を付けた価格は、約107,000ドルになる。
| 実際にはほとんどの人が2台のマシンを使うに違いない。平時には負荷を分散し、非常時にはオンライン状態のスペアとして利用する便利さを考えれば、ハードウェアの価格は十分に安いからだ。しかも、完全にシステムを二重化したとしても、z800を使用する場合と比べて70%以上もコストを節約できる。 |
保守料金は発表されていないが、これらの資料から考えると、z800を選択した場合と比較して600,000ドル程度節約できそうである。しかも、メインフレームと同等の機能を実現してもシステムの処理能力はほとんど残されているので、z800 IFLの何倍もの速度で常にLinuxの作業を実行できる。
利点の考察
コストと性能のいずれにおいても、Linuxマシン上でFlex-ESメインフレーム・エミュレータを稼働した方がメインフレーム上でLinuxをエミュレートするより有利であるとしたら、z800ソリューションには、これを乗り越えるだけの利点があるのだろうか。
IBM陣営の決り文句は、サービスの信頼性（RAS）と仮想化/パーティショニングである。これらはいずれもメインフレームの世界では非常に重要な問題である。しかし、重要なのはIBMのソリューションにおいてであって、ここで考察している2つの選択肢の判断においては、特に重要視する必要はない。
z800のRAS機構は、ハードウェア、マイクロコード、システムコードのレベルで実装されており、一般的にLinuxではアクセスできない。zVMでは、ちょっとしたハードウェアまたはソフトウェアの障害でマシンが停止することはないが、影響を受けたLinuxインスタンスには障害が発生し、復元が必要となる。
ハードウェア・レベルで見ると、メインフレームのRAS機能のほとんどは、電子機器の信頼性が今よりずっと低かった時代から変わっていない。そのため、これらの機能の設計で想定されている条件は、現在では発生しないような事象が多い。たとえば、CPUやそれに関連した障害は、かつてはよく発生したが、今はめったに発生しない。したがって、Unixが稼働しているSunやハイエンドのIntelマシンよりもメインフレームの方が信頼性に勝っているとしたら、それはハードウェアやソフトウェアの信頼性ではなく、管理方法に関するものだといえる。
さらに、実環境での複数のLinuxインスタンスの稼働に関するIBMの一部の資料（『Linux on IBM zSeries and S/390: Large Scale Linux Deployments』など）は、巧妙にも、インスタンス間でなるべくLinuxを共有し、これらの共有ファイルを直接VMで管理するように勧めている。その目的は性能の向上だが、その通りにすると、次のようなおかしな現象が生じる。
- 仮想インスタンス上のルート・ユーザまたはsetuidプロセスがシステムに介入できるなら、各インスタンスを分離する手段としての仮想化は無効になる。
- ルート・ユーザまたはsetuidプロセスが自分のシステムに介入できないとしたら、それはLinuxではない。真のオペレーティング・システムではなく、よくできたCMS（zVMのインタラクティブ・シェル・レイヤ）と言った方がよい。
仮想化とパーティショニングは、アセンブラ・プログラマが活躍し、メインメモリは64K、マシンへの投資は最低でも数百万ドルかかった1960年代に、実環境と開発環境のユーザを分離するためのソリューションとして発展した仮想マシン技術である。
パーティショニングは、基盤のハードウェアを共有しながら直接的には影響しあうことない複数の仮想マシンを構築するために、マイクロコード・レベルでリソースを区分することによってマシンを分離する技術である。仮想化は、１つ以上の独立した動作環境のコピーを1台のマシン上で稼働させることである。
コンピュータの初期には、これらの技術は、2台目、3台目のマシンを購入しなくても開発やテスト用の安全な環境を構築できる安価な手段であった。もちろん、このようなコストは今日では問題にならない。Sun Blade 2000のようなハイエンドの開発用ワークステーションは20,000ドルするかもしれないが、Dellのようなベンダの4ウェイ・テスト・サーバなら12,000ドル以下で買える。しかし、だからといって、コストの問題は考えなくてもいいというわけではない。たとえば、対称アクセスが可能な192GBのRAMを備えた24 CPUのシステムを得るために120万ドルの24 CPU Sun Fire 6800を購入し、3つのパーティションに区分するとしたら、これと同じ機能は、各125,000ドルの3台のV880によるグリッド・ネットワークでも実現できる。しかも、この種のパーティショニング機能がなければ、誰も大型のメインフレームに関心を示さないのである。
同様に、主要なUnixバージョンにも複数の仮想化ソリューションがあり、すでに仮想化されるOSに組み込まれているものもある。たとえば、Virtuozzoのソフトウェアを使用すれば、FlexでVM/VSEを稼働しながらNetfinity上に2,500もの個別のLinuxインスタンスを作成できるが、すでにボックス上にある基本Linuxでネイティブに2,500の個別ユーザ・プロセスを実行すれば、仮想化のオーバヘッドは生じない。
Linuxのパーティショニングと仮想化が必要な場合もあるかもしれないが、この記事の対象である約14,000社の中小規模の企業が直面している状況に該当するような例は思いつかない。このような企業にとっては、2台のNetfinityでLinuxを稼働し、そのうちの1台用にFlex-ESのライセンスを購入する方が、コスト面でも性能面でも明らかに有利である。
その他の選択肢
今まで論じてきた2種類のアップグレード・オプションの選択においては、メインフレーム・ソフトウェアの価格と同様、スタッフの能力も特に比較する必要はない。z800とInetl上のFlex-ESのどちらからMIPSを得ても、ソフトウェアに支払う料金や必要な技能に差異はなく、またメインフレームのIFLとIntel機のどちらのLinuxサイクルを使用しても同じソフトウェアを使用し、同じ技能が必要になるからである。
しかし、もっと視野を広げて、別のアップグレード方法を検討しようとする場合は、別の選択肢を探して、判断し、導入し、サポートできるだけの能力がITスタッフにあるかどうかがにわかに問題となる。
この点から考えると、Flex-ESの選択は、意外にも組織のITチームに微妙に好影響を及ぼす。他の選択肢を念頭に置いた場合、一般的に企業幹部は、z800ベースのアップグレードを選択すると、少なくともさらに数年間はメインフレーム路線から抜け出せなくなると判断する。しかし、Flex-ESの選択が及ぼす有利な影響はこれだけではない。Linuxが稼働しているIntel機で必要なMIPSを調達すれば、現状を守ろうとする心理的な壁が排除される。さらに、節約された約600,000ドルの資金をメインフレーム以外の人材に投資すれば、今後、飛躍していくための態勢を整えることができる。
比較的自由な発想が可能な組織では、選択肢を検討するにあたって、IT運営委員会のメンバーは次の点を検討することができる。
- 会社をメインフレームに縛り付けているソフトウェアは本当に必要なのか。あるいは、プロセスの変更を制限するようなソフトウェアと、ソフトウェアの変更を制限するようなプロセスがあって、にわとりと卵のどちらが先かというような状況に陥っていないか。
- ソフトウェアや、モデルとしているビジネス・プロセスを市販の代替物やLinuxフリーウェアに変えることはできないか。
- ソフトウェアのソース・コードを所有している場合は、それをUnix（BSD、Linux、またはSolaris）に移植したらどうだろうか。
- 組織に完全なソースがない場合、そのバイナリがかなり古いものであれば、MVS3.8やVM/370R6で実行するようなシステムを構築できるのではないか。その場合、ライセンス料を追加せずにHerculesメインフレーム・エミュレータを使用することによって予算を節約できるかもしれない。HerculesはIBMとは直接関係のないオープン・ソースであるが、これを使用すれば、アプリケーションやIBM動作環境のほとんどすべてをUnix上で実行できる。上記のMVSやVMを含めた一部のIBM OSはパブリック・ドメインになっているので、コードが古ければ、全くライセンス料を支払わずに導入できる可能性もある。
- ライセンスの抜け穴を使用できないか。たとえば、重要なライセンスが無期限に継続されていて総費用額の大きい契約はないか。匹敵する能力を持つハードウェアにそのソフトウェアを移植する権利はないか。障害回復条件を利用して古いメインフレームをブリッジから外し、障害と称して、代わりにHerculesのライセンスを使用できないか。
実際には、Flexやz800-0E1が対象としている100 MIPS以下のメインフレーム上で稼働しているビジネス・アプリケーションは、たいていどれも、簡単にUnixに移植して1,000ドル未満のIntel機のLinuxやBSDなどで稼働できる。しかし、残念なことに、これを実現するために必要な情報や、それを支える環境に恵まれなければ、この種の決断を行う者にとって、こうした現実は何の意味も持たない。
資金が潤沢にあれば、それほど悩むことはないかもしれない。たとえば、Sunは、ハイエンドのSystem 390またはzSeriesを使用している企業を対象として、Sun Fire 6800クラスの装置に数百万ドルかければ、費用を大幅に節約できるというメインフレーム移行プログラムをいくつか展開しているが、これも約1,995ドルのSun Blade 150でメインフレームの演算ニーズが満たされるような規模の企業の移行計画には、全く役立たない。
オープン・ソースのS/390エミュレータであるHerculesは、この状況を変える可能性がある。Flexと違って、しっかりとしたアセンブラ・コンポーネントがあり、SPARCやItaniumベースのマシンのような非x86装置でもコンパイルして実行できる。Herculesが活用されない最大の要因は、IBMが与えている現実のあるいは心理的な圧力である。私はHerculesで稼働するライセンス製品を提供するのかどうかIBMに、問い合わせてみたが、回答は得られなかった。しかし、業界ではIBMは提供しないだろうという噂が広まっている。真実であろうとなかろうと、この噂があるだけで、ほとんどの企業は、重要なアプリケーションにHerculesを使おうとはしない。
Herculesで動作する製品の提供に対するIBMの態度を法的に明確化して、Unixコミュニティに大きく貢献できるのは、SunやRed Hatのような企業だと考えられる。それは、和解命令を無効にする1997年の協定の改訂または明確化を求めることである。この協定がなければ、IBMは提供せざるを得なかったはずである。
Herculesで使用するメインフレーム・ツールの提供を明確に支持するような裁定が得られれば、Unixコミュニティは、14,000以上もの中小規模の企業をLinux界へ、そして小規模で高速かつ安価なコンピューティングの世界に招くことができる。
Paul Murphyは『The Unix Guide to Defenestration』の執筆と発行に携わった。MurphyはITコンサルティング業界で20年間の実績を持つ。
