コラム / Sun View 第7回
メインフレームの後継者
渡邉 利和（toshi-w@tt.rim.or.jp） [著]
2001年4月28日
クラスタリング形態
まずはワークステーションSun Blade 1000から搭載が始まった新世代CPU UltraSPARC IIIだが、新シリーズのミッドレンジサーバ群が発表になり、着実に世代交代が進行しつつある。しかしながら、新しいミッドレンジサーバ群ではCPUの比重は相対的に下がっているようだ。CPU性能を追求するよりも、安定性や管理機能を重視する、ということだろう。
米国に続き、日本でも新しいミッドレンジサーバシリーズが発表された、今度のシリーズ名は、「Sun Fire」である。ワークステーションのBlade(刃)に続いてFire(炎)では、まるでよくあるRPGの世界観のようだ。この後、MagicだのRuneだのと続くわけではあるまいが。
現時点で発表になっているSun Fireサーバ群は
の4グループに大別される。このうち、Sun Fire 280Rはもっとも小型の機種で、“ワークグループサーバ”と位置づけられる、4Uサイズのラックマウント型のモデルである。ラックマウント可能かどうかという意味では、3800と4800も19インチラックに対応しているのだが、型番が3桁と4桁で異なっていることからも分かるように、280Rと3800の間にはちょっとギャップがある。そこで、まずは3800〜6800までのモデルについて紹介しよう。
Sun Fire 3800〜6800に対しては、“Midframe Servers”という呼称が新たに与えられている。位置付けとしては、ワークグループサーバの上、ハイエンドサーバの下ということで、従来の「ミッドレンジサーバ」というのと違いはない。では、なにが変わったのか。Midframeという語は、Mid+Frameというところから来ている。Midは従来のミッドレンジのミッドだが、Frameはメインフレームの「フレーム」の意味である。Sunはこの意味について「メインフレームの機能をミッドレンジの価格で提供する」と説明している。
渡邉 利和（toshi-w@tt.rim.or.jp） [著]
メインフレームが実現していたもの
PCユーザーにとって、「メインフレーム」は今や過去の遺物としか思えないだろう。筆者自身にとっても、メインフレームの記憶は大学の計算機実習の思い出と同一である。低機能な端末から苦労しつつFotranプログラムをたどたどしく入力し、実行し、しばらくしてからラインプリンタのところに出力を取りに行く、というロクでもない操作環境の記憶だ。PCのインタラクティブな操作環境を知ってしまえば、メインフレームはうすら馬鹿でかい電卓程度にしか思えなかったものだ。
その後、「ダウンサイジング」や「オープンシステム」という標語が盛んにもてはやされた時期、筆者はUNIXシステムをメインに利用するようになっており、PCよりもUNIXが気に入っていたが、これとてもメインフレームに比べればまだ「個人用コンピュータの匂い」を強く持っており、どう考えてもメインフレームよりもすばらしい環境に思えた。メインフレームが過去の遺物として恐竜扱いされ、主役の座を追われつつある状況を共感を持って眺めていたわけだ。
しかし、あれから10年以上経った今でも、メインフレームは絶滅なぞしてはいない。これは間違いなく、メインフレームに向いた用途が実際に存在し、そこではメインフレームを利用することがよい選択であったからだろう。規模が大きく、大量のリクエストを処理する。しかも、安定性／信頼性を重視し、とにかくダウンしないという特性を実現したのがメインフレームである。Sunが取り組んできたビジネスサーバ市場ではこの特性が求められていたわけだが、現実にメインフレームに匹敵する形でこうした要求に応える目処が経ったのが、ダウンサイジングの提唱から10年以上経った今なのだということなのだろう。
Midframeと呼ばれるSun Fireシリーズの特徴は、Dynamic System DomainとDynamic Reconfigurationの実現にある。これらは、従来のUltraSPARC II世代のシステムでは唯一Sun Enterprise 10000(Starfire)のみが実現していた機能だ。もちろん、これ以外にもほとんどすべての主要コンポーネントが冗長化に対応しているなど、PCとはレベルの違う構成になっているが、ここではもっとも目立つ2つの“Dynamic”機能に注目してみよう。
Dynamic System Domainは、システムの動作中に動的にドメイン分割を可能とする機能だ。ドメインとは、単純化するとCPUのグループ分けと言ってもよいだろう。このクラスのSunのサーバでは、SMP構成がデフォルトである。つまり、最初から複数のCPUが存在するわけだ。この複数CPUをいくつかのグループに分け、仮想的に別のコンピュータのように扱うのがドメインの機能である。ただし、仮想的と言っても実際には物理レベルでの分離がなされている。つまり、単一のOSが複数のOSイメージをエミュレートするような、VMwareのような実装ではなく、ホストOSは存在しない。相互に直接的な依存関係のない独立して動作するOSが1つの筐体内部で複数存在することになる。
Sun FireをはじめとするSunのサーバ群では、CPUとメインメモリ、そしてI/Oが一組のシステムボード上に搭載され、これが複数あるというデザインになっている。PCに例えると、1つの筐体内にマザーボードが複数あるようなイメージだ。このため、Dynamic System Domainとは、最初から物理的に別々のコンピュータとして動作可能なコンポーネントをそのまま別々に動作させるようなものだと言い換えることもできる。
一方、Dynamic Reconfigurationは、このシステムボードを動作中に抜き差しできるという機能だ。もちろん、動作中といってもそれはシステム全体のレベルでの話であり、システムボードレベルで見れば、抜く前にそのシステムボード上で実行されている処理は止めておかないといけないわけだが、この抜き取りに備える準備作業の時間はごく短い。逆に、システムボードを追加する際には既存のシステムボード上で実行されている処理はそのままにしておき、物理的に新しいボードを追加すればよい。この場合、新しいボードを利用する前にシステムが新しいボードの動作チェックなどを実行するため多少時間がかかるが、それでも数分程度の話だという。
この両者を組み合わせると、1台のサーバ内を2つの異なるコンピュータに分割し、それぞれのCPU数の割り当てを動的に調整できるほか、全体の処理能力が不足した場合には新しいボードを追加して増やすことができる。追加した新しいボードは既存の任意のドメインに追加してやれば、そのドメインの処理能力が拡大される。しかも、“Dynamic”というだけあり、こうした作業はすべてシステムの動作中に行なえる。メンテナンスを理由にシステムを停止することも許されない、24時間365日稼働を続けることが期待されるサーバが増えているが、こうした用途にとっては実に便利な機能だといえる。
このドメイン分割の機能も、元はメインフレームで実装されていたものだ。近視眼的には、この機能が実現されたことが“Midframe”という呼称の理由となっていると言うこともできるだろう。
渡邉 利和（toshi-w@tt.rim.or.jp） [著]
サーバに求められる機能
Dynamic System Domainの意味は、PCの延長上にサーバを位置づける発想からは理解しにくい。というのも、PCは本質的にはシングルユーザーシステムであり、その機能強化はフォアグラウンドのタスクの高速化に向けられているからだ。一方、Sun Fireが実現した機能強化は、並列性の向上に主眼を置いていると言ってよい。
PCの場合、性能が向上したかどうかはある特定のアプリケーションの実行速度に注目して考える例が多い。個人ユーザーにとってもっとも身近で分かりやすいのは、3Dグラフィックスを多用した最新のゲームソフトウェアだろう。精細なテクスチャをマッピングした複雑なグラフィックスを高速に動かし、そのフレームレートを測定するようなベンチマークが盛んに行なわれているようだが、こうした処理を高速化するには、CPUやグラフィックスアクセラレータの処理能力の向上が近道だ。もちろんソフトウェアの作り方に依存するのだが、こうした処理を高速化するには、下手にマルチプロセッサ化を目指すよりは単体CPUの性能向上を待つ方が効果が大きい。たとえば、Pentium III-500MHzのPCでのゲームのパフォーマンスに不満を感じている場合、Pentium III-500MHz×2CPU構成のマシンにリプレースするよりも、Pentium III-1GHzのマシンを選ぶほうがよいはずだ。
一方、サーバの場合はそもそも処理すべきタスクが複数並列にあり、しかもその数が大量になることが多い。こうした処理を高速化する際にも、もちろん単体CPUの性能向上は効果がある。しかし、むしろCPU数を増やすアプローチのほうが簡単であることが多い。1つの処理を分割して並列処理し、全体の性能を向上させるより、最初から別々の処理を平行実行するほうが簡単だし、並列実行した分だけ素直に性能が向上する。
とはいえ、それでもSMPでのCPUを増やせば事足りるのであって、システムを内部で複数のドメインに分割する意味はないと思われるかもしれない。実際、ドメインを分割しても性能は向上しないと思われる。とはいえ、逆に元の処理が十分並列性の高いものであれば、ドメイン分割による性能劣化もまた起こらないだろう。イメージしやすい例としてWebサーバのような処理を考えてみよう。インターネットからバラバラに届くリクエストは、相互に関係を持たない独立した処理なので、分散処理がとても有効になる。この場合は、このWebサーバの前段にディスパッチャのような負荷分散機構があれば、ドメイン分割は性能劣化要因にはならない。むしろ、ドメインごとに独立のネットワークインターフェイスを利用することで性能向上があるかもしれない。しかしながら、この部分での性能向上が目的だというわけではない。
ドメイン分割の意味は、信頼性の向上や、トラブルの局所化といった部分にある。サーバが1台しかない環境でも、そのサーバを内部的に分割できれば、万一の障害の際にもその被害はドメインの範囲に限定されることが期待できる。1台のサーバを2つのドメインに分割していた場合、あるCPUボードが故障しても、その影響は故障したCPUボードが属していたドメインにとどまり、もう1つのドメインにはいっさい影響しないというわけだ。これにより、クラスタリングと同様の効果が得られる。つまり、予備サーバを持つ余裕がなくても同レベルの信頼性が実現できるようになるわけだ。
新しいSunのクラスタソフトウェア、Sun Cluster 3.0では、前回紹介したとおりドメインレベルのクラスタリングをサポートしているため、1台のサーバ内でクラスタリングを実現できる。このとき、複数サーバでのクラスタリングよりも高速な接続が実現できるというのも面白いところだ。つまり、通常の複数サーバを利用したクラスタリングの場合、サーバ間の状態確認や処理の引き継ぎなどのためにネットワーク等を利用して相互に接続しておくわけだが、ドメイン分割の場合は、この接続にはシステム内部のインターコネクトを利用できる。Sun Fireの内部インターコネクトはSun Fireplaneと呼ばれるパケットスイッチ方式のクロスバー・アーキテクチャであり、実効バンド幅が9.6GB/sという高速なものである。これを利用すれば、クラスタノード間でのデータのやりとりが処理のボトルネックになることもないはずだ。
渡邉 利和（toshi-w@tt.rim.or.jp） [著]
PCとサーバの大きな違い
PCユーザーから見ると、サーバも大きなPCに見えるかもしれない。実のところ、PCサーバとして販売されているモデルの中には、実際に単にハードディスクを大量に内蔵できるだけのPCでしかないものもあったりする。Sunのサーバも、ごく初期には「グラフィックス機能が貧弱な代わりにディスクがたくさん積めるワークステーション」でしかないものもあった。しかし、これは今となっては当てはまらない。
Sun Fireを見ると、サーバとして重要なのはディスクの量などではなく、並列性の確保だということが分かる。障害に備えた冗長性の確保と、並列的に送られてくる多数のタスクリクエストに高速に応答できることが重要なのだ。これを突き詰めたのが、Sun Fireだと言ってよかろう。これは、PCとはかなり異なる要求仕様であり、結果としてできあがったSun FireはPCとは似て非なるアーキテクチャのマシンである。もはや、サーバは大きなPCではないのである。サーバもまた、特定用途向けの専用機と考えるほうが実情に合っているかもしれない。
実は、Sun Blade 1000では、新たに採用されたUltraSPARC IIIにエラッタが見つかり、ちょっとした問題になっている。CPUの高速化のために導入されたプリフェッチ機構に不具合があるとかで、この機能を停止すれば問題は生じなくなる代わりに、当初公開されたベンチマーク値が達成できなくなる可能性があると報じられた。単純化すると、当初の予定よりも性能が悪くなる、ということである。
一方、サーバ機に関してはこのトラブルは問題にはならないと発表されているが、実際にはSun Fireに使われているCPUもSun Blade 1000と同じものだという。つまり、同じ不具合のあるCPUだということだ。しかし、Sun Fireではシステム制御プロセッサがメインのCPUとは別に存在しており、制御や監視の役割を果たしている。このシステム制御プロセッサはメインのCPUに対して制御を行なうことができ、Sun Fireではシステム制御プロセッサからの命令でプリフェッチ機構をオフにしてしまうことができる。従って、問題が発生しない状態に簡単にできるというわけだ。また、後に不具合が解消されたCPUが出荷されれば、CPUを交換した上でシステム制御プロセッサでプリフェッチ機構をオンにすることができる。
問題が生じないとはいえ、性能は下がるのではないかという懸念はあるだろうが、実のところサーバ市場でこれがあまり問題視されていないのは、結局のところサーバで重要なのは単体CPUの性能よりも高度な並列化の実現だからだ、といえるだろう。Dynamic System Domainなどの機能を実現したシステムデザインがポイントなのであって、UltraSPRAC IIIの採用による性能向上は最優先事項ではないと言ってもよいかもしれない。この点も、数少ないタスクをより高速に実行することが求められるPCやワークステーションとの違いを明瞭に反映している。
サーバは、ビジネスの役に立つ便利な道具だが、個人ユーザーの立場からはその真価が分かりにくい存在であるようだ。車に例えるなら、現在のPCがスポーツカーであるのに対し、サーバは大型トラックのようなものだろうか。詳細に見れば実に高度で興味深いメカニズムであり、業務上きわめて重要な存在でありながら、一見地味でおもしろみが感じられにくい、というあたりもよく似ているという気がする。
渡邉利和
| 
