この連載では、サーバOSとして十数年発展してきた「Solaris」をオープンソース化した「OpenSolaris」を紹介し、ブログサーバ「Roller」と組み合わせて運用していくうえで有用なさまざまな知識を紹介していきます。(編集部)
この連載では、ブログサーバの導入と運用というテーマを軸に、OpenSolarisの紹介に始まり、実際に運用していくうえで有用なさまざまな知識を紹介していきます。第1回は、OpenSolarisとブログサーバ「Apache Roller」について紹介しましょう。
まず、「そもそもOpenSolarisとは何か」というところから始めましょう。すでにご存じの方も多いと思いますが、OpenSolarisとは名前のとおり、Solarisをオープンソース化するプロジェクトの総称です。ソースコードを公開し、幅広くコミュニティの力を得ることで、ユーザーにとってより高度で便利な環境を提供することを目指しています。
公開されてからすでに2年以上経過しましたが、OpenSolarisはその間、オープンソースのプロジェクトとして着実に成長してきました。具体的には、複数のバイナリディストリビューションが出現しているほか、後述するとおり、OpenSolarisの機能をSolarisやMac OS、BSDといった別のOSへ移植するといった形で成果が生まれています。
以下の連載では、OpenSolarisの歴史など、すでに語られていることは省き、最近の動向や運用していくうえでの注意事項など、実践的な内容を中心に述べていきたいと思います。
関連記事
▼ラベルベースのアクセス制御機能を備えた新Solaris 10
http://www.atmarkit.co.jp/news/200701/31/solaris.html
▼ノートPCでこそ使いたいZFS
http://www.atmarkit.co.jp/news/200706/29/zfs.html
でもやっぱり、初めに少しだけ歴史に触れておきましょう。
OpenSolarisの原点はSolarisです。そしてSolarisの源流は、BSDを基に、サン・マイクロシステムズが1980年代にリリースした「SunOS」に始まります。これに徐々に機能が追加され、1992年にはGUI環境などを追加した「Solaris 2.0」としてリリースされました。以来十数年、SolarisはサーバOSとして着実に発展してきました。これはちょうど、当初ワークステーション上でのビジネスを志向していたサン・マイクロシステムズの戦略が、次第にサーバ向けに軸足を移してきた道のりと軌を一にしています。
さて、この十数年の間に、サーバのリソースは飛躍的に拡大しました。
例えば当初のSMP(注1)サポート数は4CPUまで(SPARCserver 690)でした。当時はこれがハイエンドのシステムだったのですが、その後、20個(1991年のSPARCcenter 2000、SuperSPARC)、64個(Sun Enterprise 10000、UltraSPARC I)を経て、現在では144CPU core(Sun Fire 25K、UltraSPARC IV+)にまで拡張しています。
同じように、ネットワーク帯域は10Mbpsイーサネットから最新の10Gbpsイーサネットへ、またメモリも64Mbytes(SPARCstation 2)程度から現在の2Tbytes(Sun SPARC Enterprise M9000)へと拡張しています。しかし、ハードウェアリソースの拡張に伴うシステム全体のスケーラビリティの拡大は、大変な苦労を伴う道のりでした。
例えば、仮想記憶を採用しているOSでは、ページフォルト(注2)がさまざまな理由によって始終発生しますが、このとき、仮想記憶システムは複数のCPUにまたがって効率よく稼働していなければなりません。というのもSMPの場合、たとえ144 CPU coreであっても、すべてのメモリのマップをシステムで共有するからです。この処理を複数のCPUで効率よく処理できるようにしないと、時間のほとんどが、1つのCPUの仮想記憶の処理待ちに費やされることになってしまいます。
また同様に、仮想記憶では実メモリが足りなくなってくると、最も利用されていないと思われるページを再利用します。そのページを探すアルゴリズムにも工夫が必要です。Solaris 2.0のアルゴリズムのまま、2Tbytesのメモリを搭載したマシンで稼働させたとすると、システムは、空きページを決めるために1日中時間を使ってしまうかもしれません。
これほど大規模なシステムを安定稼働させるためには、信頼性の確保も必要です。
例えば、2Tbytesのメモリを搭載した大規模システムを「年」単位で連続稼働させることを考えてみましょう。この場合、メモリチップの数だけでも膨大になるため、ハードウェア故障の確率は、メモリ2Gbytesの場合よりも高くなってしまいます。そこで最新のSolarisには、エラー発生の兆候を見せたメモリを早期に検出し、自動的にシステムから切り離す機能が備わっています。
ほかに、ワークステーションにおけるGUI環境の整備など、ユーザビリティの面での改善も図られてきました。
このようにSolarisは、複雑なテーマをこなしながら、SMP環境で効率よく動作するように長年鍛えられ、発展してきました。いまではワークステーションだけでなく、教育・研究機関や企業基幹システムなど、さまざまな場所で導入されています。基本的なバイナリの互換性を保ちながら、さまざまな要件に応えるべく拡張、発展を行ってきたことが、Solarisの商業OSとしての価値と地位を確保してきた鍵であるといってよいでしょう。
ごく最近では、CPUのクロック周波数の向上が鈍化し、代わりに、1つのCPUチップに複数のコアを集約する方向が目指されています。IntelやAMDからも4コアのチップが出ていますし、サンも、8コアで64スレッドの同時実行が可能な「UltraSPARC T2」を出荷しています。
1つのチップに複数のコアが載ったものも、ソフトウェア的にはSMPに近いといえます。そのように考えると、誕生初期からSMPへの最適化が行われてきたSolaris、そしてその発展系であるOpenSolarisの時代がやって来たといってもいいでしょう。
OpenSolaris(http://jp.opensolaris.org)は、こうして発展してきたSolarisを基に、ソースコードを公開し、オープンソース化して開発を進めていくことを目的としたプロジェクトです。
ただし、OpenSolaris自体は、Linuxでいう「ディストリビューション」とは異なります。OpenSolarisはあくまでもプロジェクトの名称であり、「BeleniX」「NexentaOS」、あるいは「Solaris Express」などが各ディストリビューションに相当します。
最初のステップとして、2005年1月に「DTrace」関連がオープンソース化されました。DTraceは、システムの動きを動的に解析するためのツールで、アプリケーションやシステムのパフォーマンス解析に極めて有効です。このDTraceは、当時、Solaris 10が備える最新技術として注目を集めていました。
その後もカーネル本体やZFS、あるいはOpenGrokなど、多くのコードが順次公開されてきました。いずれも、Mozilla Public Licenseをベースにした「Common Development and Distribution License」(CDDL)に基づいてライセンスされており、その数は1000万行以上に上ります。
これはすべてのソースコードに関して、法的に問題のないことを逐一確認しながら進められてきた作業でした。というのも、Solarisはもともと、ソースコードを開示することを前提にしていません。結果として、その中にはさまざまな理由から他社のコードや知的財産が含まれることになりました。それらまでオープンソースとして公開するわけにはいきません。
日本の皆さんには、日本語入力システム「ATOK」の例が分かりやすいかもしれません。サンは、ジャストシステムからのライセンスを受けてATOKのバイナリをSolarisに含め、リリースしています。しかし、そのソースコードをサンが買い取って、オープンソースソフトウェアの1つとして開示する……となるとなかなか難しい話です。
そうはいっても、OpenSolarisでは、「SolarisがSolarisたり得る」ためのコードがほとんど開示されていますので、ご安心ください。
さらに、一部のコードは、ソースコードの公開にまでは至らなくても、バイナリとして提供されています。これを用いて、例えば、OpenSolarisのソースコードを使ったカーネルを作ることも可能です。また、後述するZFSのように、OpenSolarisプロジェクトでの開発の成果をSolaris 10に還元するといったことも行われています。
Copyright © ITmedia, Inc. All Rights Reserved.