ブログのネタとしてはちょっとタイミングを逃しましたが、先週OpenSolarisの日本ポータルが出来上がったそうです。

FAQをはじめ、OpenSolaris 開発者向けリファレンス・ガイドなんかも日本語のものが用意されていますから、OpenSolarisって何なの〜〜？？っていう方から、バリバリ開発してみよう〜！なんて方はぜひともチェックしてみてください。

すでに寺田さんがすでに書かれていますが、Sun Java System Web Server 7がリリースとなったようです。Web Server 6.0がリリースされたのが確か2001年春ごろですから実に約6年ぶりのメジャーアップグレードとなります。
Web Server 7の詳細についてはすでにベータ版のころから寺田さんが詳しく書かれているのでそちらを参照していただくとして、個人的に気になっているWeb Server 7の新機能を挙げると次のようなものがあります。

クラスタリングのサポート

Web Server 6.xには管理を統一するための仕組みとして「クラスタ」というキーワードの機能がありましたが、Web Server 7.0で新たに搭載されたのはサービスをスケーラブルに配置できるようなクラスタリング機能です。これはWeb Server 7.0の管理コンソールから簡単に設定でき、負荷に応じて簡単にマシンを追加することができます。やり方については寺田さんのエントリを参照してください：

• SJS Web Server7.0クラスタ環境の構築(Yoshio Terada's Blog)
• SJS Web Server7.0サンプルWebアプリのデプロイと高可用性の検証(Yoshio Terada's Blog)

Webサーバにこのような機能がついていてうれしいことはたとえば、SSL証明書の管理です。通常、Webサーバはほとんどの場合ステートレスなサービスを提供しているのでこのようなクラスタリング機能がなくても、それほど苦労しなかったのですが、SSL証明書をそれぞれのサーバに設定するのは手間でした。しかしWeb Server 7.0では管理コンソールからクラスタに対してSSL証明書を設定すれば、クラスタ配下のWebサーバ・インスタンスに自動的にSSL証明書が設定されるようになっています。
また、このクラスタリング機能にはJ2EE 1.4準拠のEJBを使わないWebアプリケーションをセッション・レプリケーション(あるマシンがダウンした場合でも、セッション情報を他のマシンに引き継げる)機能が搭載されていて、Seasarを使っていたり、Springframeworkを使っているなどEJBが必要なくJ2EE 1.4レベルのコードサポートでよい場合には最適なデプロイ環境といえます。
もちろん、Webサーバなので従来どおりCGIやPHPアプリケーションをデプロイしたり、Ruby on Railsのデプロイも可能です。

DoS攻撃やDDoS攻撃に対する耐性

Web Server 7.0ではDoS攻撃(サービス不能攻撃)やDDoS攻撃(分散サービス不能攻撃)のような攻撃に対する防御の仕組みが用意されています。DoS攻撃の場合、ある一定のIPアドレスから集中して大量のアクセスが到来しますが、Web Server 7.0はこれを検出してそのIPアドレスからの接続を一定以上受け付けないように設定することができます。また、DDoS攻撃の場合、様々なIPアドレスから大量のアクセスが到来しますが、その場合もたとえば特定のURLに対するアクセスを抑制するなど様々な設定を行うことができます。

ECC(楕円曲線暗号)のサポート

楕円曲線暗号は、公開鍵暗号方式の一つです。現在SSL通信の際には大雑把に言って、(1) 証明書の確認、(2) 共通鍵暗号の鍵を、公開鍵暗号で交換、(3) 共通鍵暗号で通信、という手順をとっています。この際使われている公開鍵暗号方式というのが現在の主流はRSAという暗号です。今回新たにサポートされたECCはこの (2)の共通鍵暗号の鍵を安全に渡すための非対称暗号として使います。
RSAは暗号の性質として「準指数関数時間」のアルゴリズムであるということがわかっているそうです。一方、このECCは「指数関数時間」のアルゴリズムなのだそうです。お叱りを覚悟で簡単に表現すると、ECCの方がより難しい問題なので、量が少なくても計算が大変。というイメージです。
量が少ない、ということは、正しい鍵の組み合わせを知っているクライアントとサーバには負荷が少なくなるということで、携帯やPDAなどのような小型端末への負担がより小さくなります。もちろん、このECCを利用するにはブラウザ側もECCによる通信をサポートしていなくてはならないのですが、最新のInternet ExplorerやFirefoxでは標準でサポートしているそうです。

以上のように個人的な注目ポイントを書きましたが、さすがに6年越しのメジャーアップグレードだけあって、おもしろい機能はまだまだあります。もっと知りたいという方は、実際に使ってみるのが一番良いでしょうから下記のアドレスからダウンロードしてご利用ください。 (無償で利用できますし、サポート契約が不要であれば商用環境でも無償でお使いいただけます)

• ダウンロード

続いて振り返るイベントは12/21(木)のJavaナイトセミナーと連続して次の日に行われた12/22(金)のNSUG Solaris 10 ナイトセミナー (Vol.7) 〜ついに BrandZ がきましたよっ！〜です。こちらもビール片手にリラックスした雰囲気でのセミナーで、Solaris Nevada ビルド49以降に追加されている新機能であるBrandZについての紹介でした。
個人的にはNevadaもちょくちょく触ってはみているんですが、やはりこういうきちんとしたセミナーに出ると理解度が変わりますね。特にインストールするところとかは、自分でいろいろドキュメント読んで・・・というのは結構骨が折れるというか、興味本位程度で触ろうと思っているときには挫折しがちですが、今回のセミナーのようにBrandZによるSolaris Nevada上のZoneをLinux環境にする、という手順をステップ・バイ・ステップで紹介していただけると触ってみようかな〜と思う気持ちがどんどん高まってきます。(でも今年はもう残り少ないので実際に触るのは来年にしようかな・・)。

ではこれで今年最後のブログ・エントリとさせていただきます。来年もよろしくお願いいたします。

Solaris 10の最新アップデート版である、Solaris 10 11/06がリリースされたようですね。早速、Mac OS X上で動作する仮想マシン環境であるParallelsを使ってインストールしてみました。

今回のアップデートからは「Secure by Default」というプロジェクトの成果として、リモートからのアクセスに関して標準的に安全な設定となるようなインストールが選べるようになりました。

Solaris Expressで手に入るNevadaでは文字通りSecure by Defaultで、有無を言わさずこの設定になるのですが、Solaris 10では今まで使っていた方の互換性を配慮してインストール時に選べるようになっています。
Secure by Defaultなのに、デフォルトで選択されているのが「はい」(Secure by Defaultではない)で、Secureではない側なのはデフォルトと呼べるの？なんて疑問もわきますが、よく説明を読めば、ここで、よくわからない方は「いいえ」(Secure by Defaultが有効)を選択する方を推奨していますから、そういう意味ではSecure by Defaultはデフォルトなのかも知れません。

こちらがインストール完了の様子です。これだけではSolaris 10 11/06の新機能がよくわかりませんが、また追ってご報告します。

Jimさんが紹介されていますが、OpenSolarisにおけるユーザグループの一つとして、Japan OpenSolaris User Groupが出来上がったそうです。

こちらのユーザグループ メーリングリストは日本向けですから、メーリングリストへの投稿は当然日本語でOkです。話題も特に限定されていませんので、初心者の方から、バリバリの上級者の方まで情報交換に利用いただけます。

このユーザグループのメーリングリスト購読の方法は、ug-jposug-subscribe@opensolaris.orgに空メールを出して、後ほど送られてくる確認メールにそのまま返信することで購読が完了します。

しばらくチェックしていない間にSolaris Express for Community Releaseはbuild 49というところまで出ていました。今回は久しぶりにParallels for Macを使って試してみることにしました。
さて、インストールについてですが最近のNevadaビルドではインストーラでCD/DVDが認識しない、という問題があってインストールが進まない、という問題があるそうなのですが、それは起動時のGRUBで次のようなオプションを指定してやれば良いようです。

atapi-cd-dma-enabled=0

インストーラの起動時にはすでに-B以降にオプションが指定されているのでカンマ(,)区切りで付け加えてブートします。インストールが完了したら、/boot/grub/menu.lst のメニューに上記のオプションを設定すればOkです。

さて、かわったと感じるところでいえばXsunでもマウスが動くようになったとか、SBD(Secure by Default)によってデフォルトで最小限のサービスしか提供しないような設定になっていたりというあたりでしょうか。もちろん、他にもたくさんかわっているのですがもはや追いかけきれていません・・・。

他に見た目でかわったところではブラウザとメーラがMozillaからFirefox／Thunderbirdにかわったことと、Look and Feelが新しくなっているところでしょうか。

スクロールバーとか、タイトルバーのあたりのデザインと、スタートメニューがJavaロゴだけになっているとか、テーマが全体的にSunカラーになっているとかいろいろ変わっていますね。

先日、車好きの友人につれられてその業界では有名らしいあるチューンファクトリーへお邪魔してきました。残念ながら、車のことに全く詳しくないので詳しくはわかりませんが、そのチューンファクトリーはドラッグレースと呼ばれるような競技で、勝つ、ためのチューニングを施すようなチューン(もちろん、それ以外のチューニングもしているそうですが)をしているそうです。
そこでチューニングに関するいろいろな話をしてくださったのですが、多くは理解できなかったものの、ITシステムに於けるチューニングとの奇妙な共通点を感じました。例えば、車の性能と言えば、安直に考えればすぐエンジンの性能、と考えますが、氏によればマフラーの性能はあなどれない、マフラーは重要だ、とのことでした。これはCPUにおいて最近はクロックよりも、それ以外の要因(例えばCMT化やバス性能の向上)によることもやはりパフォーマンス向上には不可欠である、ということと奇妙な一致を感じました。

さて、アプリケーションサーバやWebサーバにおけるチューニングを考えた場合はパフォーマンス(=レスポンスタイムの短縮)の向上、もさることながらスループット(=時間あたりの処理数)の向上も重要なチューニングポイントです。そういったチューニングの手法は様々な書籍やWeb上の文献がありますが、個人的に有効性を感じているのは渋滞学、という考え方です。
ちなみに、ちょうど大学時代にお世話になった西成先生が最近、その名も「渋滞学」という本を出され、あらためて渋滞学について勉強してみました。
スループットを向上させる、ということは見方を変えればいかにリクエストを渋滞させないか、ということであってこの渋滞学の考え方はパフォーマンスチューニングにおける基本的な考え方の一つになると思います。
たとえば、渋滞学では基本図と呼ばれる図を用います(参照: 渋滞した道路で割り込みながら進むほうが速いか、そうでないか(3))が、アプリケーションサーバ等のパフォーマンスチューニングガイドでも同様のグラフを用いてスループットの計測および最適化をするようにと記述されています。

たとえばこの図はSun Java System Application ServerのDeployment Planning Guideに紹介されているもので、渋滞学での基本図と同じ性質の物です。実際、今まで個人的に関わったパフォーマンスチューニングやベンチマークではこういった図を使って、渋滞学的な解釈をすることで原因を特定したり、最適であるかどうかを判定する、というようなことを行ってきました。
もちろん、渋滞学の専門家というわけではないので、それだけをもとに決定的な判断基準にしている訳ではないので、それ以外の幾つかの統計情報との比較をしながら検討していますが、渋滞学、というある意味ベースの考え方を持っていることによって、直感的にこれはおかしい、とかこれは良さそうということがわかるようになってきました。

このお話はNetBeans Profilerのような、性能測定を行うようなプロファイルではなく、GlassFish v2の新機能となるプロファイル(英語では略称 profile、正式には usage profileと記述しています)についてです。
GlassFishコミュニティーでは毎週User Experience Meetingという勉強会を行っています。ここでは新機能の説明をしたり、またはGlassFishオープンソース・プロジェクトのユーザからのフィードバックを得るというような、開発者とユーザ間のコミュニケーションをより密にするような試みが行われています。
このミーティングは電話会議ですから、日本に居ながらにして参加することは不可能ではないのですが、国際電話の電話代もさることながら、時間帯はサンフランシスコ時間が基準ですから、直接の参加にはちょっと気合いが要りそうです。とはいえ、資料や議事録はWiki上で公開されていますからそれだけでもかなり勉強になります。

プロフィアルとは?

さて今回のプロファイルのお話はちょうど今週のUser Experience Meetingの話題です。このプロファイルとは、アプリケーションの設定をあらかじめよく使いそうなシーンに分けてプロファイル(=設定の集まり)を定義する。というような新しい機能です。
このプロファイルは現在のところ次の3種類が考えられています。

• developer ... 開発者向け。頻繁に再起動が必要であったり、開発PC上で必要以上にリソースを消費しないように最低限の構成にする。
• cluster ... クラスタ環境向け。クラスタ構成を構築するための設定。
• enterprise ... エンタープライズ向け。特に本番環境に適用するような場合に使う。

これを見てカンの鋭い方は気づかれたかもしれませんが、現在もアプリケーション・サーバはPlatform Editon(特に開発者向け)、Standard Edition(本番環境向け)あるいはEnterprise Edition(本番かつクラスタ向け)というようにEditionごとに設定の最適化が行われています。プロファイルとはこのEditionの考え方を、もう少し動的に反映できるように機能強化したものなのです。
では実際の使い方を見てみましょう。

$ asadmin create-domain --user admin --adminport 4848 --profile developer dev-domain

今までのcreate-domainコマンドに加えて --profile というオプションが追加され、ここで developer プロファイルを選んでいます。これによって dev-domainという名前のドメインは開発者向け、つまり起動速度を改善したり、リソースを最小限に利用するような設定によってドメインが作成されます。
このようにプロファイルを導入することのメリットは、GlassFishプロジェクト側としては複数のエディション・バイナリを管理／配布しなくても良いというところです。ユーザ側のメリットとして出荷時点の状態で本番環境向けのパフォーマンスを引き出すようにしたり、開発環境向けの軽快な設定にすることが簡単に選べるようになるということです。

SunのシステムというとOSはSolarisで、その上で動作するSun Java System Application Server等のようなミドルウエアも当然、主なターゲットとしてはSolarisを設定しているのですが、Microsoftとの和解の成果なのか、現在のSun Java Enterprise Systemのミドルウエア郡はちゃんとWindowsをサポートしています。
こういったミドルウエア関連のお仕事をする上で、理屈上はOSに関する知識はほとんど必要ないのですが、パフォーマンスチューニングとかトラブルシューティングという仕事をしなければならない場合には、あった方がかなり良い、と思うことがしばしばあります。
そういったことからも最近、細々とWindowsの勉強をしています。 (藤井さんが紹介されているOpen Service Platformのお話を見ると、時代の流れに逆らっている、というか合って無いのかもなーと感じます・・。)

Windowsというと、普通にユーザとしてブラウザを使ったり、インターネットの設定をしたり、という程度＋αぐらいは知識があるつもりですが、実際のところサーバとして運用するようなWindowsについての知識はまったくありません。また会社はSolaris、家はMacという生活のためWindowsに関する知識は Windows 95で止まっています(もう10年前ですね・・)。
そこで最近読んでいるのがMicrosoft Windows Internals: Microsoft Windows Server 2003, Windows XP, and Windows 2000 (Pro-Developer)という本です(邦訳版はインサイド Microsoft Windows 第4版〈上〉とインサイドMicrosoft Windows第4版〈下〉)。
この本はさすがにInternalsというだけあって、プロセスやスレッドの構造体、スケジューリングの実装あるいはメモリ管理についてモダンなサーバ向けWindowsの各バージョン(Windows 2000, 2003, XP)についてかなり詳細に解説しています。内容が濃いだけあってページ数も相当なものです。

この本の良いところは私のようなWindows初心者にもわかりやすくパフォーマンスモニタの監視項目などを説明している点です。今までSolarisのvmstat相当のことをどうやってモニタすれば良いのか知らず、Windowsといわれた時点でお手上げでしたが、これでなんとかちょっとずつやっていけそうです。

WSRP ProjectはOASISによるWeb Services for Remote Portletsという仕様の実装で、Sun Java System Portal Server 7の一部がオープンソース化されたプロジェクトです。
WSRP(Web Services for Remote Portlets)はポータル・デスクトップに貼り付けられる部品である小さな窓(=ポートレット)をWebサービスを使って遠隔のポータルに対してサービスを提供したり(このようなサービスの提供者をProviderと言います)、遠隔のポートレットを手元のポータルに組み込んだり(このようなサービスの利用者をConsumerと言います)、というようにポータルとして提供されているサービスを一つのサーバや場所に限定しないための言語や環境に依存しないポータルの仕様です。イメージとしてはThe AquariumのEarly Draft of JSR286 (Portlet 2.0 Spec) Availableにある図がわかりやすいですね。
また、このWSRPは現バージョンは1.0ですが、この次のバージョンである2.0もたしかDraft版が出ています。Javaにおけるポータル仕様はJSR 168 Portlet Specificationですが、WSRP 2.0への対応を謳っているJSR 286: Portlet Specification 2.0も現在Early Draftが出ているという状況です。WSRP 2.0の目玉はなんといってもInter-portlet通信でしょうか。
Inter-portlet通信はSun Java System Portal Server 7にも含まれていますが、ポートレット同士がお互いにイベント通知を行い、表示や動作において協調した動作を提供するというような機能です。これによって、たとえば発注ポートレットと在庫表示ポートレットが連携して発注とともに在庫情報が反映されるというようなポータルの構築が可能になります。

さて、このWSRP Projectですが菅谷さんもすでに紹介されていますが、最近WSRP Consumerのコードが公開されたそうです。 WSRPもいろいろ可能性のある仕様なので、ちゃんと使えるようになったら一度これを使ったなんちゃってアプリを作ってみようかなと思っています。

つい先日のことですがSolaris 10のDTraceがWall Street Journal Innovation Awardを受賞したそうですね。Dtrace自身はとくにグラフィカルな機能ではないちょっと地味めの機能ですが、一度使ってしまうと、こんなすごいのはなかなか手放せないなぁーと思うほどパワフルな潜在能力を秘めています。
今日はSun Java System Application Server 8.1のパフォーマンスチューニングにDTraceを使う例を紹介します。アプリケーションサーバのチューニングというと、Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Performance Tuning Guideという結構分厚いマニュアルに広範囲にわたって説明されています。このマニュアルはなかなか内容もよく、そもそもどのようにしてパフォーマンスチューニングをしていけば良いのかといった考え方から、実際にどういう風にチューニングするかまでをよく説明しています。(残念なところは日本語版マニュアルがまだないというところでしょうか・・。)
チューニング箇所はこの分厚いマニュアルにいろいろな視点で載っているのですが、実際にチューニングをする箇所はあまり多くありません。 Java VMのGCエルゴノミクスのような自動調整機能や、Java VMやアプリケーションサーバ自身が出荷時点でチューニングされるようになってきたことが影響しているように思います。 もちろん、アプリケーション・アーキテクチャの見直しとか、コーディング上の調整はまだまだ効果絶大ですが、AppServerの設定という意味ではだいたい次の3点が主なチューニング箇所となります。

• Java VMオプション (特にガーベジコレクションなどメモリ管理関係)
• HTTPリスナの設定
• コネクションプーリングの設定

この3つのうち、目に見えて違うのは最後のコネクションプーリングの設定であるようなケースをよく経験しますので今回はその点についてDtraceでデータを取りながらチューニングをする方法を紹介します。

Java VMとDTraceの準備

実は、現在のJava VMでは標準的にDtraceを使うことはできませんので、別途Java VMのDtraceエージェントを入手します。エージェントはhttps://solaris10-dtrace-vm-agents.dev.java.net/から入手することができます。 次に準備の手順を紹介します。

1. Solaris 10を用意します :-)
2. DTraceのJava VMエージェントの配布ファイルdvm.zipをダウンロードします。
3. dvm.zipを適当な場所に展開します。
4. 次のような環境変数の設定シェルスクリプトを作ります。

   #!/bin/sh
   
   DVM_ROOT=<dvm.zipを展開したディレクトリ>
   JAVA_TOOL_OPTIONS="-Xrundvmti:all"
   
   if [ "`uname -p`" = sparc ] ; then
      LD_LIBRARY_PATH_64=$DVM_ROOT/build/sparcv9/lib
      LD_LIBRARY_PATH_32=$DVM_ROOT/build/sparc/lib
   else
      LD_LIBRARY_PATH_64=$DVM_ROOT/build/amd64/lib
      LD_LIBRARY_PATH_32=$DVM_ROOT/build/i386/lib
   fi
   
   export JAVA_TOOL_OPTIONS
   export LD_LIBRARY_PATH_32
   export LD_LIBRARY_PATH_64
   

5. このシェルスクリプトを実行して環境変数を設定します。
6. 次に、今回の計測ターゲットであるSun Java System Application Serverを再起動します。

これで準備完了です。

DTraceで計測

次にいよいよDtraceで計測を行ってみます。なお、現在のSolaris 10では計測対象となるアプリケーションはローカルゾーンで動作させていてもかまわないのですが、Dtraceはグローバルゾーンで実行する必要があります。
今回はコネクションプールからコネクションを取得する際に同期処理が行われるのですが、コネクションを取得するのに待たされている時間、を計測することによってコネクションプールのサイズと待ち時間の関係を調べてみました。
今回使ったdtraceスクリプトは次のような感じです。
monitor.d

#!/usr/sbin/dtrace -s

dvm$1:::monitor-contended-enter
{
    self->mc[tid, copyinstr(arg0)] = timestamp;
}

dvm$1:::monitor-contended-entered
{
    @mc[tid, copyinstr(arg0)] = sum(timestamp - self->mc[tid, copyinstr(arg0)]);}

dvm$1:::monitor-wait
{
    self->mw[tid, copyinstr(arg0)] = timestamp;
}

dvm$1:::monitor-waited
{
    @mw[tid, copyinstr(arg0)] = sum(timestamp - self->mw[tid, copyinstr(arg0)]);}


pid$1::exit:entry {
   printf("\nMonitor Contended:\n");
   printa(@mc);

   printf("\nMonitor Wait:\n");
   printa(@mw);
   exit(0);
}

ここではmonitor-waitとmonitor-contended-enterというプローブを使って、それぞれのスレッドが同期処理でどの程度待たされているのかを計測しています。(なお、このスクリプトはかなり簡略化しているので、アプリケーション自体が同期処理を行う時間も含まれています。必要に応じて条件を追加してフィルタリングをしてください。)
このスクリプトに実行権を与えて、引数にアプリケーションサーバのインスタンスのPIDを引数として渡します。

 # chmod 755 monitor.d
 # ./monitor.d <AppServerのPID>

これでモニタリングが開始します。この後に負荷試験を行って特性を計測します。 負荷試験が終わったらアプリケーションサーバを停止します。すると、次のように結果が得られます。

CPU     ID                    FUNCTION:NAME
  0  47931                       exit:entry 

       40  ContainerBackgroundProcessor[StandardEngine[com.sun.appserv]]           111876
      113  Timer-4                                                   141871141
      176  service-j2ee                                           142310303401
      168  service-j2ee                                           142381032157
      124  service-j2ee                                           142968651607

この結果は左から、スレッドID、スレッド名、待ち時間(ナノ秒)として表示されます。このようにしてスレッドプールのサイズを変えながら待ち時間を計測し、あとはStarSuiteなどでグラフ化するとその特性を調べることができるようになります。

このグラフは左奥方向にコネクションプールのサイズ(8〜128)、右奥方向にスレッドがコネクションを占有する時間(コネクションの使用時間)と条件を変えたときのそれぞれの平均待ち時間をグラフ化したものです。このように、占有する時間が長い(=重い処理をしている)場合にはコネクション数はそれ相応でなければならないことが一目瞭然です。
すこし説明が長くなってしまいましたが、このようにDtraceはアプリケーションやアプリケーションサーバの特性を知るのにとても有益な情報を与えてくれます。
もちろん、NetBeans Profilerのようなプロファイラはもっと多くの情報を与えてくれます。しかし、どちらかというとプロファイラはアプリケーション・サーバのチューニングという観点では情報が多すぎるのと、オーバーヘッドが大きすぎます。
このため、アプリケーションの構築がほぼ終わり、あとはテスト環境でアプリケーションサーバのテストを！という時にはこのようなDTraceによる計測は真価を発揮してくれます(もちろん、開発中に使っても便利です)。

Sunに入社してからずっとSunRayによるフレキシブルオフィス環境だったためか、自分で自由にいつでも使える個人ワークステーションも無ければ、サーバもありません。もちろん、共有ラボで申請すれば必要な機材は貸していただけるので特別支障はありませんが、それでもやはりちょっとした調べものをしたいなぁ〜と気軽にアクセスできる環境は欲しいときがあります。

今やSolarisはx86版もあって、アプリケーションサーバ、Webサーバ、Portalサーバ等の製品はそれぞれSolaris x86版に対応していますので手元のノートPCでもちゃんと動作し、検証なんかもできるようになってきました。でもお客様から頂く質問はお客様によってバージョンもまちまちで7.1だったり、8.1だったり、Platform EditionだったりStandard Editionだったりと、ひとえにアプリケーションサーバといっても手元に用意しておかなければいけないバリエーションは結構あります。アプリケーションサーバのPlatform Editionなんかは構成ファイルも少ないので、別ディレクトリにどんどんインストールしてしまえば複数バージョンを一台に入れるのも難しくないですが、Standard EditionとかEnterprise Editionのように構成要素が多いものではファイルやポート番号をきちんと管理するのはかなりの手間です。

そこで思いつくのがSolaris Container(いわゆるZone)です。Solaris Containerは論理的なOSイメージをひとつのOSの中に複数作ることができるような機能です。(詳しくは「Sun Developer Connection: Solaris 10, Solarisコンテナ」に載っていますのでこちらをご参照ください。) 今回はこのSolaris ContainerとSolaris 10 6/06に統合されたZFSを使って手元のノートPCにちょっとしたラボ環境を作ってみることにします。今回の目的を果たすにはZFSは必須ではありませんが、このあわせ技の便利さも紹介します。
ちなみに、私はSolarisエキスパートというわけではないので、へぼいコマンドを打ってるかもしれませんがご容赦を・・。

今回はなんちゃてラボ環境ということでノートPCに入れていくことを考えます。(詳しいSolarisのインストールの方法は「実践！ノートPCにSolaris 10を入れてみよう」を参照してください。)。まずはSolaris 10 6/06をインストールするのですが、スライスを作成する際に、ルート / と、swap、あと適当に /exportのような3つを作成します。なぜ /export のようなスライスがいるかというと、ここをあとからZFSで使いたいからです

インストールが完了したら、/export 以下をZFS化してみましょう。

1. /etc/vfstab を編集して /exportにマウントしている部分をコメントアウト
2. (/exportがマウントされていれば) /exportをアンマウント

       # umount /export
   

3. /exportだったところ(今回はc0d0s7)をZFS化

       # zpool create -f c0d0s7 export
   

4. マウントポイントを設定

       # zfs set mountpoint=/export export
   

簡単ですね では、次にZone用のファイルシステムを作っていきましょう。今回は1ゾーンごとにZFSのファイルシステムを作っていきます。ゾーンはそれぞれ /export/zones/[ゾーン名] というように作っていくことにしましょう。

• ファイルシステムの作成

      # zfs create export/zones
      # zfs create export/zones/as71se
      # zfs create export/zones/as81se
      # zfs create export/zones/as81ee0
      # zfs create export/zones/as81ee1
  

• マウントポイントの設定

      # zfs set mountpoint=/export/zones export/zones
      # zfs set mountpoint=/export/zones/as71se export/zones/as71se
      # zfs set mountpoint=/export/zones/as81se export/zones/as81se
      # zfs set mountpoint=/export/zones/as81ee0 export/zones/as81ee0
      # zfs set mountpoint=/export/zones/as81ee1 export/zones/as81ee1
  

これでファイルシステムは完璧です。こうやって使ってみるとZFSって本当に簡単ですね。何せ、プールさえ作ってしまえばこのファイルシステムがミラーだろうが、RAIDだろうが気にせず同じように操作すればいいだけだからです、画期的！
では次は本題のZoneに、といきたいところですがすこし予習をしましょう。

Zoneにはいくつか種類があります。まず、一番基本的なところではつぎの2通りの種類に分けられます。

• 大域ゾーン (Global Zone)
• 非大域ゾーン (Local Zone)

大域ゾーンとは最初にインストールしたOS全体をゾーンとしてみたときの呼び名でシステム全体で1つのみ存在し、非大域ゾーンはひとつのシステムにたくさん作ることができます。大域ゾーンと非大域ゾーンでは実行可能なコマンド(prtdiagとか)や扱えるデバイスに違いがあったりというような違いがあります。今回ラボ環境を作ろうとしているのは非大域ゾーンの方です。また、非大域ゾーンはさらに作成方法の違いから2種類あります。

• 完全ルートゾーン (Whole Root Zone)
• 疎ルートゾーン (Sparse Zone)

Solaris Containerでは論理的にたくさん実行環境を作れる訳ですが、物理的には1台のマシンなわけで、マシンからみればSolarisはひとつです。そしてSolarisカーネルもすべてのゾーンで共有されています(ハードウエアによる仮想化とちがって、共有する部分が多いので無駄が無い)。疎ルートゾーンとはこの共有の度合いをかなり積極的に採用した物で、/usr、/lib、/platform、/sbinなどのディレクトリをパッケージを継承するように大域ゾーンと共有することでディスク容量を節約し、また、パッケージやパッチの管理も共有化するようなものです。

疎ルートゾーンの場合、ゾーンに必要なディスク容量は100MBちょっとです。もう一つの完全ルートゾーンはそういったパッケージの継承を行わないもので、大域ゾーンとは独立したコピーをもつゾーンのことです。完全ルートゾーンは共有しない分をすべて別のコピーとして持ちますので管理も別になり、ディスクも結構つかいます(Solaris 10 6/06インストール直後で試したところ3GBちょっと使いました)。完全ルートゾーンのメリットは異なるパッケージを導入したり、パッチを試してみたいときに独立したコピーを持てるというあたりがメリットになります。

ではこの疎ルートゾーンと完全ルートゾーンをどういうように使い分けたら良いのかというところでは、まずソフトウエアのサポート状況から判断する必要があります。たとえば、Java Enterprise System 2005Q4では次のような制約があります。「このリリースでのゾーンサポート」より

1. 非大域ゾーンがすでに存在する場合、Java ES を大域ゾーンにインストールできます。
2. 非大域ゾーンは、Java ES を大域ゾーンにインストールした後に作成できます。
3. 大域ゾーンに別の Java ES インストールがすでにインストールされていても、Java ES を完全にルートの非大域ゾーンにインストールできます。
4. デフォルトの疎ルート非大域ゾーンへの Java ES のインストールは、サポートされません。疎ルートファイルシステムが検出されると、Java ES インストーラは、インストールを続行できません。
5. 完全にルートの非大域ゾーンに Java ES がすでにインストールされている場合でも、Java ES を大域ゾーンにインストールできます。

こういった制約をクリアしていればなるべくリソースを使わない選択をしていくことになります。

お待たせしました、ではゾーンを作っていきましょう。

• 非大域ゾーンの構成を作成します。

     # zonecfg -z as71se
     as71se: そのような構成済みゾーンはありません
     'create' を使用して、新しいゾーンの構成を開始してください。
     zonecfg:as71se> create
    

  zonecfgで構成を開始します。zonecfg -z [ゾーン名] というようにしてゾーン名を指定して作成していき、まずcreateで構成をつくります。
• 引き続き zonecfgで非大域ゾーンの設定を行っていきます。ゾーンのパスを設定します。

     zonecfg:as71se> set path=/export/zones/as71se
    

• もし完全ルートゾーンを作成するのであればパッケージ継承ディレクトリを削除します。

     zonecfg:as71se> remove inherit-pkg-dir dir=/lib
     zonecfg:as71se> remove inherit-pkg-dir dir=/platform
     zonecfg:as71se> remove inherit-pkg-dir dir=/sbin
     zonecfg:as71se> remove inherit-pkg-dir dir=/usr
    

• パッケージ継承ディレクトリ以外にも大域ゾーンのファイルシステムを共有したければ、ループバックマウントによって継承することもできます。ソフトウエアのインストール用イメージなんかを共有すれば、いちいち非大域ゾーンにftpでファイル転送をするなんてことなくファイルを共有できて便利です。

     zonecfg:as71se> add fs
     zonecfg:as71se:fs> set dir=/export/media
     zonecfg:as71se:fs> set special=/export/media
     zonecfg:as71se:fs> set type=lofs
     zonecfg:as71se:fs> end
    

• ネットワークの設定を行います。非大域ゾーンはDHCPクライアントにもなれないようなので、IPアドレスは事前に決めておく必要があります。今回はラボ構築目的ですから192.168.x.yのようなプライベートアドレスを使うことにします。

     zonecfg:as71se> add net
     zonecfg:as71se:net> set physical=bge0  (ネットワークインタフェース名)
     zonecfg:as71se:net> set address=192.168.1.2
     zonecfg:as71se:net> end
    

• 設定が完了したら検証し、設定をコミットします。

     zonecfg:as71se> verify
     zonecfg:as71se> commit
    

• ここまで設定が完了したら非大域ゾーンにSolarisをインストールします。

     # zoneadm -z as71se install
    

  インストールはコピーされるファイル数によって数分から数十分程度かかりますのでのんびり待ちましょう。
• インストールが完了したら起動してコンソールログインしましょう。

     # zoneadm -z as71se boot
     # zlogin -C as71se
    

  最初のログインで言語の設定、ネットワークの設定などが訊かれますのでその辺りの設定を行えば無事ゾーンの完成です。ちなみにたくさん一気に設定したい場合には、マニュアル「Solaris のシステム管理 (Solaris コンテナ : 資源管理と Solaris ゾーン) : /etc/sysidcfg ファイルを使用して初期ゾーン構成を行う方法」を参考にしてみてください。

おめでとうございます。これで非大域ゾーンができました。あとはソフトウエアをインストールしてラボ環境を作ればいいだけです。ただ、ノートPCだとだいたいの場合inetmenuなんかを使ってDHCPでインターネット接続されていると思います。このためWebブラウザとかで調べものなんかはDHCPを使いたいけど、ラボと接続するときにはプライベートのアドレスを使いたいなあーと思う物です(本当かな?)。ということで、プライベートアドレスを大域ゾーンにも割り当てて強引に1台でひとりラボネットを作っていきましょう。
Solarisは一つのネットワークカードに対して複数のアドレスを割り当てることができるようになっています。非大域ゾーンのネットワークも実際にはこの論理的なインタフェースを使っています。その際には、論理的なインタフェースを作成して、そこにアドレスを作成していきます。論理的なインタフェースはインタフェース名:[n]という命名規則で作成されていきます。ifconfig -aで既に使われている名前を確認してから、新しい割当を行いましょう。今回は bge0:2に割り当てることにします。

 # ifconfig bge0:2 plumb
 # ifconfig bge0:2 192.168.1.1
 # ifcofnig bge0:2 up

これで完了です。ここまでできると、あとはひとりラボネットでいろいろな検証をしていけばOkです。

さて、今回はせっかくZFSを使ってゾーンを配置しましたのでそのメリットを紹介していきましょう。まず、スナップショット機能。ZFSにはスナップショットという機能があり、その時点のファイルシステムの内容を保存しておくことができる機能があります。

 # zfs snapshot export/zones/as71se@monday

こんな感じでコマンドをたたけばいいだけです。これによる恩恵は大きく、たとえばゾーンのなかみがぐちゃぐちゃになったときにこのスナップショットをとった時点に戻したい場合にはロールバックを行えばいいだけです。

 # zfs rollback -r export/zones/as71se@monday

ZFSってすごい！ちなみに、「ゾーンがインストールされている Solaris システムのバックアップについて」にも載っていますが非大域ゾーンのバックアップ＆リストアの注意点がありますので、この辺りも参考にしてください。また、ゾーンはその性質上、いろいろな物を共有していますので 「ゾーンがインストールされている Solaris システムでのパッケージとパッチについて」にもある通り、大域ゾーンにパッチを当てたあとに、リストアをしたりすると非大域ゾーンとの間で不整合がおこる可能性があります。こういったことからあまり、軽率にロールバックをするのはおすすめできませんが、ソフトのインストールに失敗したのを戻すとか、大域ゾーンに何も変更を加えていないのをちゃんと把握した上であればこのZFSスナップショットとZoneの活用は感動的な便利さです。

こんな感じにSolaris 10 6/06を使ったノートPCでなんちゃってラボネットを作ってみましたが、いかがでしょうか。こういった仮想化はVMwareのようにハードウエアごとエミュレーションするような手法ではとてもノートPC上でやろうってことはできませんが、Solarisゾーンならではの低いオーバーヘッドのためにこんな使い道も開拓できるわけです。他にもいろいろ活用方法はあると思いますのでまた思いついたらご紹介しようと思います。

つい先日ですが、Solaris 10のアップデートリリースであるSolaris 10 6/06がリリースされました。早速、手元のノートPCであるMacBook ProにParallels Desktop for Macというエミュレータ(VMwareのようなPCエミュレータのMac版)を使って仮想環境にインストールしてみることにしてみました。

これが出来上がり画面です。Solaris 10 1/06と比べるとログイン画面のデザインがすこし変更されているようですね。それ以外にも大きなところではZFSのサポート！や、RealPlayer 10が追加されたことあたりが挙げられるようです。ちなみにRealPlayerでちょこっとムービーを再生してみましたが音は鳴りませんでしたがちゃんと動画も再生できました。(音はまた今度暇があれば設定方法を探してみます)

インストールはダウンロードしたCDかDVDのisoイメージをマウントしてインストーラを実行するだけなので特に難しいことはないのですが、標準のグラフィックインストーラを使おうとするとマウスが動かないのでテキストインストールをして後からkdmconfigで設定をするといいでしょう。 Solarisのインストーラは搭載メモリが400MB以下の場合はテキストモードのインストーラが起動するようになっていますから、インストール時は仮想マシンのメモリサイズを256MBぐらいにしておいて、後ほど好きな容量にかえるようにします。

ParallelsがBeta版のときにはXsunではディスプレイをうまく認識できなかったような記憶がありますが、現在リリース版がでているものではそのような問題も無くXsunでも使えそうな感じなのですが、マウスの設定がわからず断念・・・。とりあえず従来通りXorgで試すことにしました。グラフィックドライバはVESA、解像度はParallelsで設定したものを、マウスはデバイスに /dev/kdmouse、プロトコルにIMPS/2を選べば問題なくグラフィック環境も使うことができます。

ネットワークの設定はParallelsをインストールすると /Libraries/Parallels/Tools/vmtools.iso というツールのCDが提供されていますので、これをCDとして認識させ次のようにシェルを実行してドライバをインストールして、インストール後に再起動します。

 # cd /cdrom/prltools/drivers/network/rtl8029/solaris
 # ./network.sh

Virtual PC 6を使っていたときはSolarisを入れるなんて言うと結構情報がなくて苦労しましたが、Parallelsではちゃんとベンダー提供のドライバまであって結構すんなり使うことができます。

皆様はBrandZをご存知でしょうか。BrandZとはSolarisコンテナのひとつをLinuxを実行できるような環境として動かすという、ユニークな機能のことです。
この間BrandZ build 35のDVDイメージがリリースされていたのでご存知の方もいらっしゃるかもしれません。実は恥ずかしながら知らなかったのですが、同時にBrandZのVMWareイメージも公開されていました。VMWareのイメージを使えばインストール作業も要りませんし、パーティションのきりなおしもしなくて良いのですぐにでも使えますね! (VMWare Playerも無償で使えるようになりましたし)
何より、うちにはDVDに書き込める機械がなかったのでこれは大助かりです。余談ですが、こういったエミュレータを使うのはものすごく久しぶりのことです。オープンソースのBochsにFreeBSDを入れたり、家の MacにはVirtual PCを買ってインストールしたのですが、iBook PowerPC G3 700MHzという約4年前のPCにはものすごい重量感で、Windows Updateに1日以上かかったのでお蔵入りになりました ;-<
さて、使い方です。

• BrandZのVMWareイメージをダウンロードします。1.2GBもありますので、ここが一番時間がかかるところです・・。ダウンロードしたらbrandz35.zipを展開します。
• VMWareがなければVMWare Playerをダウンロードしてインストールしてください
• あとは、イメージを起動するだけです。起動したら rootのパスワード「root」でログインできます。

この画面はBrandZ入りのSolaris 11を起動して、BrandZを起動してログインしたところです。BrandZのゾーンはこのVMWareイメージでは lxzoneという名前で作成されています。 lxzoneにログインするには次のようにゾーンを起動して、ログインします。

 # zoneadm -z lxzone boot
 # zlogin lxzone

これでLinux環境がSolarisコンテナ上に再現されました。簡単ですね。さて、でも本当にLinuxなのかはどうやって確かめましょうか・・・。とりあえずお決まりの uname -aでチェック。

 # uname -a
Linux lxzone 2.4.21 BrandX fake linux i686 i686 i386 GNU/Linux

名前はfake linuxなんですね。あれ？ BrandX ？まあいいか・・・。
ということで、すぐ使えるBrandZをお試しください!

最近、Sun Java System Portal Serverなどを触るために、ノートPCにインストールしたり、設定をいじって壊したり・・、アンインストールしたりしていますが、ZFSのスナップショットは予想以上に便利です。 いまのところZFSでシステムを起動することはできないので(zfs bootプロジェクトは進行中)、次のパスをZFS配下においています。

• /export
• /etc/opt
• /opt
• /var/opt

一度勢い余って /usr や /var全体をZFSにしようとしたのですが、見事に失敗してシステムが起動できなくなりました

普通、こういう作業を行う際には設定ファイルを server.xmlから server.xml.origとかファイル名を変えてバックアップしたり、ファイルシステムの一部または全部を tarやzipでバックアップしたりするわけですが、ファイル名を変える方は間違えて上書き保存してしまうようなことがあったり、tar/zipでのバックアップも容量が多いと結構めんどうなんで、さぼってしまいがち。そういうときに限って前の状態に戻したいなんてことがよくある訳です。

ZFSのスナップショットは、もう少しミッションクリティカルなデータベースなどをターゲットとしているのかもしれませんが、ちょうどCVSのバージョン管理をしているときにタグを振るようにスナップショットされるのでスナップショットにかかる時間は一瞬であるため、気軽にスナップショットをとれるわけです。これに慣れるともう、UFSやNTFSに戻れません!

いままでで、使い始めてこれは戻れないなと思ったのは、気がついたら手になじむようになっていた vi テキストエディタ、自宅のPCをWindowsからMacにしたとき、C++からJavaに鞍替えしたときのガーベジコレクションといったところです。ZFSはまた新しい「使ったら戻れない」技術であるように思います。

ところで、Windowsを使っていて疑問に思うのはNTFSってジャーナリングしているのに、シャットダウンに失敗した際には必ずCHKDSK(UNIXでいうfsck相当)が走るのはなんでなんでしょうか・・。一瞬で終わるならいいんですが、どうも全チェックしてるように見えます。FATに比べれば壊れることはほとんどなくなったのかもしれませんが、ZFSに慣れたいまではどうも心もとなくてなりません。