X

Oracle Solaris, Oarcle ハードウェア製品に関する情報

Recent Posts

Solaris

SPARC の暗号化処理ハードウェアの稼働状況を観察する方法

pre.pre20160219 { color: gray; border: 1px solid #eaeaea; background-color: #f8f8f8; overflow: auto; padding: 6px 10px; border-radius: 3px;}はじめにSPARC M7 チップ には暗号化処理のハードウェアアクセラレータが搭載されています。このブログエントリーでは、CPU 内蔵の暗号化命令が利用されていることを観察する方法をご紹介します。この記事は Eric Reid による ブログ記事 の翻訳版です。翻訳文最近このブログで SPARC M7 チップ内蔵の暗号化機能の素晴らしさについて紹介してきました。実際に Oracle のパートナーさまのソフトウェアでも活用例が出てきています。ある時、読者の方から「自分の動かしているソフトウェアで暗号化機能が使われているかどうか確認するにはどうしたら良いのか?」という質問をいただきました。とても良い質問です。2012 年に ダン・アンダーソン が書いた「SPARC T4 の暗号化機能が使われているかを確認する方法 」を最新情報にアップデートしたいと思います。SPARC T4 の当時は、CPU の暗号化機能へのアクセスはユーザランドからの関数呼び出しで実現されていましたので、DTrace を使って稼働状況を観察することができました。その後、Solaris 11 の暗号化フレームワークでは、より直接的に SPARC の暗号化命令を使用するように実装が改善されました。この変更は OpenSSL など多くのソフトウェアに影響が及ぶものでした。以前に比べて綺麗な実装となった一方で、暗号化機能の稼働状況を DTrace で観察することは難しくなりました。その代わりに cpustat と cputrack コマンドを使うことができます。cpustat と cputrack は CPU のパフォーマンス・カウンターにアクセスするコマンドです。これらを使って SPARC の暗号化機能のカウンターに記録された実行回数を読み出すことができます。SPARC T4 以降の CPU と Solaris 11 では以下のように実行できます。# # シングルソケットの SPARC T4 サーバで実行した例## # 全プロセス、全 CPU からの暗号化命令の呼び出し回数を 1 秒分表示# cpustat –c pic0=Instr_FGU_crypto 1 1 time cpu event pic01.021 0 tick 51.021 1 tick 51.021 2 tick 51.021 3 tick 111.010 4 tick 51.014 5 tick 51.016 6 tick 111.010 7 tick 51.016 8 tick 1061.019 9 tick 3581.004 10 tick 221.003 11 tick 541.021 12 tick 251.014 13 tick 2031.006 14 tick 101.019 15 tick 3851.008 16 tick 26521.006 17 tick 151.009 18 tick 201.006 19 tick 1951.011 20 tick 151.019 21 tick 831.015 22 tick 491.021 23 tick 2061.020 24 tick 4851.019 25 tick 101.021 26 tick 101.021 27 tick 4711.014 28 tick 13961.021 29 tick 101.018 30 tick 261.012 31 tick 101.021 32 total 6868# # 全プロセスからの暗号化命令の実行回数を CPU ソケット単位で表示# cpustat –c pic0=Instr_FGU_crypto –A soc 1 1time soc event pic01.014 0 tick 72181.014 256 total 7218# # プロセス ID 10221 のプロセスが暗号化命令を呼び出した回数をファイルに出力# cputrack –c pic0=Instr_FGU_crypto –p 10221 –o outputfileノート 1 : Oracle VM for SPARC (LDoms) のバージョン 3.2 より前のリリースでは、このコマンドをゲストドメイン内で実行することはできません。バージョン 3.2 以降では perf-counters プロパティを設定することでゲストドメインからのアクセスを許可することができます。ノート 2 : Solaris 11 のデフォルトでは、非大域ゾーンからこれらのコマンドを実行することは許可されていません。limitpriv="default,cpu_cpu" を設定することで変更できます。これで CPU による暗号化処理がどのくらい使用されているかを観察することができるようになりました。もう少し直感的に測定できるように、相対的な使用回数を表示する bash のスクリプトを作成してみました。ご自由にお使いください。以下がスクリプトのソースコードと使用例です(SPARC M7 で実行しました)。# cat crypto_histo.bash#! /bin/bashwhile (true); do echo `cpustat -c pic0=Instr_FGU_crypto -A soc 1 1 | \ grep total | \ awk '{ num=4*int(log($NF)/log(10)); hist=""; for (i=0; i<num; i++) hist=hist"="; print hist }'`done## スクリプトを起動し、別ウィンドウから "openssl speed -evp AES-192-CBC" を実行# ./crypto_histo.bash========================================================================================================================================================================================================================================================================================================================================================================================SPARC に内蔵されたの暗号化処理ハードウェアは、常時有効になっており、驚くほど高速で、容易に観察可能です。

はじめに SPARC M7 チップ には暗号化処理のハードウェアアクセラレータが搭載されています。このブログエントリーでは、CPU 内蔵の暗号化命令が利用されていることを観察する方法をご紹介します。この記事は Eric Reid による ブログ記事 の翻訳版です。 翻訳文 最近このブログで SPARC M7 チップ内蔵の暗号化機能の素晴らしさについて紹介してきました。実際に...

Solaris

Solaris 11.3 に Jenkins をインストールして SMF でサービス化してみる

code{white-space: pre;}Jenkins による継続的インテグレーションサーバの設定本記事は、Automated Application Development and Deployment with DevOps on Oracle Solaris 11をベースに Jenkins のインストール方法について書かれた記事です。Jenkins は、継続インテグレーションシステムを提供するオープンソースソフトウェアです。ユーザは、継続的にビルドとテストソフトウェアによりソフトウェア開発を自動化でき、ビルドやビルドログを通して可観測性を提供します。また、Jenkins は、分散コンピューティングのための能力をサポートする他、様々な組織の要件を満たすために、サードパーティ製のプラグインを追加して拡張することができます。継続なんちゃらとか開発とかは気にせず、なんかいろいろと自動化するのに役に立ちそうくらいが気が楽で良いと思います。なんかリッチな crontab とか誰か良いこと言ってた。## 本文章の目的この文章では、Oracle Solaris 11.3 上に Jenkins をインストールするとともに、SMF によるサービス化の方法を学習することを目的としています。## Solaris 11.3 での SMF 新機能Solaris 11.3 における SMF 関連の新機能をおさらいしてみます。新たに追加された機能は、下記となりますが、今回はこれらの機能は使いません。第 3 章 定期的に実行するサービスの作成periodic_method を追加することで、サービスをスケジューリングすることが可能に。第 2 章 SMF を使用したアプリケーションの制御サービスインスタンスメソッドの作成/usr/lib/python-version/vendor-packages/smf_include.py を提供し、python を利用してサービスメソッドを作成することが可能になりました。## Jenkins ユーザの作成まず、Jenkins 環境を構成するために jenkins ユーザを作成します。root@solaris:~# useradd -m jenkinsroot@solaris:~# passwd jenkinsNew Password:Re-enter new Password:passwd: password successfully changed for jenkinsroot@solaris:~# su - jenkins作成した jenkins ユーザでログインし、環境を確認してみましょう。この記事の環境は、Solaris Kernel Zones であることがわかります。Java がインストールされていないようであれば # pkg install jre-8 でインストールしておきましょう。jenkins@solaris:~$ uname -aSunOS solaris 5.11 11.3 sun4v sparc sun4vjenkins@solaris:~$ virtinfoNAME CLASSkernel-zone currentlogical-domain parentnon-global-zone supportedjenkins@solaris:~$ java -versionjava version "1.8.0_66"Java(TM) SE Runtime Environment (build 1.8.0_66-b17)Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)## Jenkins のインストール現在、Jenkins は Oralce Solaris 11.3 の Image Packaging System (IPS) では提供されないソフトウェアとなります。そのため、Jenkins をインストールするために必要なファイル(この場合は、WAR ファイル) をブラウザやコマンドライン経由でダウンロードします。 http://mirrors.jenkins-ci.org/war/latest/jenkins.war継続的インテグレーションを提供するためには、Jenkins ビルドサーバが常に稼働している必要があります。 そこで、Oracle Solaris 11 が提供する Service Management Facility (SMF) を利用することにより、Jenkins は Oracle Solaris 11 のサービスとして統合することが可能になります。この機能により、何からの理由によりサービスが停止したとしても、SMF が自動的に再起動するなどサービスの信頼性を向上させることが可能となります。## Jenkins の SMF サービス化そのためには、Jenkins のために SMF マニフェストを作成する必要があり、SMF マニフェストは、SMF サービへ登録するために必要になります。このマニフェストの雛形を自動生成するためのツールである svcbundle (1M) ユーティリティが Solaris 11.1 で提供され、これを利用して簡単に作成することができます。 ここでは、Jenkins を依存関係をもたない新しいシングルインスタンスサービスとして作成します。作成されたマニフェストの内容は WAR ファイルを実行するシンプルな内容となります。jenkins@solaris:~$ svcbundle -o jenkins.xml -s service-name=site/jenkins \-s model=child -s instance-name=default \-s start-method="java -jar /export/home/jenkins/jenkins.war"## SMF サービス化した Jenkins に環境変数を参照させて起動させるsvcbundle によりシンプルな SMF マニフェストを作成できましたが、Jenkins を実行するためにもう少し作業が必要です。Jenkins では、設定ファイルや作業ファイルを保存する場所(ホームディレクトリ)を環境変数 JENKINS_HOME で指定できますが、 この環境変数を SMF マニフェストに追加し、Jenkins 起動時に参照されるようにします。この設定は、SMF マニフェストの method_context にて行います。例として JENKINS_HOME を jenkins ユーザのホームディレクトリに設定してみます。jenkins@solaris:~$ gdiff -c jenkins_orig.xml jenkins.xml*** jenkins_orig.xml Wed Dec 9 00:38:45 2015--- jenkins.xml Wed Dec 9 00:39:27 2015*** 15,21 **** <service_fmri value="svc:/milestone/multi-user"/> </dependency> <exec_method timeout_seconds="60" type="method" name="start"! exec="java -jar /export/home/jenkins/jenkins.war"/> <!-- The exec attribute below can be changed to a command that SMF should execute to stop the service. See smf_method(5) for more--- 15,29 ---- <service_fmri value="svc:/milestone/multi-user"/> </dependency> <exec_method timeout_seconds="60" type="method" name="start"! exec="java -jar /export/home/jenkins/jenkins.war">! <method_context>! <method_credential group='nobody'! privileges='basic,net_privaddr' user='jenkins'/>! <method_environment>! <envvar name='JENKINS_HOME' value='/export/home/jenkins'/>! </method_environment>! </method_context>! </exec_method> <!-- The exec attribute below can be changed to a command that SMF should execute to stop the service. See smf_method(5) for more## SMF マニフェストの検証作成された SMF マニフェストをサービスとして実行する前に、マニフェストが正しく記述されているか検証することをお勧めします。SMF マニフェストの検証には、svccfg validate コマンドを実行します。jenkins@solaris:~$ svccfg validate jenkins.xmljenkins@solaris:~$エラーを返さずコマンドが終了したので、マニフェストには構文間違えなどないことがわかりました。## SMF サービスへの登録それでは、作成した SMF マニフェストをサービスとして登録するために、サイト固有のディレクトリに配置します。jenkins@solaris:~$ sudo cp jenkins.xml /lib/svc/manifest/site/Password:jenkins@solaris:~$そして、 サイト固有のディレクトリに配置された SMF マニフェストを取り込むための SMF サービスである、manifest-import:default サービスを再起動します。jenkins@solaris:~$ sudo svcadm restart manifest-import:defaultこの操作で、作成した SMF サービスは Jenkins サービスとして SMF に登録が完了しました。Jenkins に限らず、従来 /etc/init.d や rc2.d などに配置していたサービス起動用スクリプト(Solaris 11.3 でも利用可能。legacy service として扱われます)を SMF にすることで、サービスの並列起動、サービス・リスターターや他サービスとの依存関係を持たせることなどが可能になります。## SMF サービスの確認それでは、Jenkins の SMFサービスがオンラインになっていることを確認してみましょう:jenkins@solaris:~$ svcs jenkinsSTATE STIME FMRIonline 18:10:24 svc:/site/jenkins:defaultSMF サービス site/jenkins が存在し、STATE が online になっていればサービスとして稼働しています。## Jenkins ダッシュボードへのアクセスそれでは Jenkins ダッシュボードへアクセスしてみましょう。Web ブラウザから http://localhost:8080 にアクセスすることで Jenkins のダッシュボードへアクセスすることができます。 図1. Jenkins ダッシュボード画面ここまでの作業で、Jenkins が稼働する環境を手にいれることができました。アクセス制御などのセキュリティ設定や様々なプラグインも提供されますので、サイトにあったカスタマイズが必要になります。次のステップは、Jenkins をベースとしたアプリケーションのビルド環境を構築して行くことになります。(続く・・・かな・・・参考情報Automated Application Development and Deployment with DevOps on Oracle Solaris 11Comparison of continuous integration softwareCommand Line Parameters

Jenkins による継続的インテグレーションサーバの設定 本記事は、Automated Application Development and Deployment with DevOps on Oracle Solaris 11をベースに Jenkins のインストール方法について書かれた記事です。 Jenkins は、継続インテグレーションシステムを提供するオープンソースソフトウェアです。ユーザは...

Solaris

Solaris 11.3 における ZFS ARC のメモリ割り当ての改善

翻訳元の文章Solaris 11.3 から、カーネルのメモリ確保の為のサブシステムの KOM (カーネル・オブジェクト・マネージャ)が実装されました。KOM の最初の使用用途は ZFS の ARC です。Solaris 11.3 以前、ZFS ARC は kmem キャッシュを使用してカーネルヒープからメモリを確保していましたが、この実装にはいくつかの欠点がありました。その一つは、ARC で使用されたメモリが断片化を起こして、システムから回収されなくなってしまう可能性があったことです。この現象は ARC 用のメモリにラージページを使用している場合に顕著でした。一つひとつの ARC バッファはラージページのページサイズに比べて非常に小さいですが、ページの中に一つでも ARC バッファが存在しているとページ全体が解放できないからです。もう一つの欠点は、カーネルヒープが物理メモリ上を移動できない領域で、カーネル・ケージ内に確保する必要があったことです。これにより、ラージページのメモリを新たに確保したい場合や、動的再構成を使用してシステムのメモリを切り離したい場合に、巨大な ARC が存在していると問題が発生する恐れがありました。カーネル・ケージが大きくなってしまうことへの回避策として、/etc/system で ARC キャッシュのサイズを制限する方法がよく行われていました。また、ARC の縮小速度はヒープページのマッピング解除スピードに依存していたため、たくさんのメモリを搭載した SPARC システムでは十分な処理性能が得られないことがありました。Solaris 11.3 では ZFS ARC は KOM を使ってメモリを割り当てます。頻繁に ZFS からのアクセスが発生するディレクトリファイルなどのメタデータは引き続きカーネル・ケージ上に割り当てられますが、キャッシュの大部分のあまりアクセスが発生しないデータはカーネル・ケージの外に配置され、システムの動的再構成やメモリページ結合の際に再配置できるようになりました。KOM は x86 CPU のマシンでは 2MB のスラブメモリを、SPARC マシンでは 4MB のスラブメモリを使用しますが、これにより従来の 256MB 単位のヒープページに比べて断片化の恐れが少なくなっています。また、KOM はアドレス変換に seg_kpm フレームワークを使用するため、64bit システムでスケーラビリティが向上しています。これらの変更でメモリ管理の仕組みが改善されましたので、従来 ARC サイズの制限をおこなっていた多くのシステムで、設定をする必要がなくなっています。ただし ZFS のメタデータへのアクセスが多いシステムや、カーネルゾーンを使用しているシステムでは Solaris 11.3 でも引き続き /etc/system で ARC を制限する必要があります。参考リンクZFS ARC (Adaptive Replacement Cache) およびカーネルケージの削減ZFS のスケーラブルなパフォーマンスの改善参考 - ZFS ARC を調査するコマンド# kstat -p zfs::arcstats:size# echo '::kmastat' | mdb -k | grep zfs# echo ::memstat | mdb -k | grep ZFS# echo ::arc | mdb -k

翻訳元の文章 Solaris 11.3 から、カーネルのメモリ確保の為のサブシステムの KOM (カーネル・オブジェクト・マネージャ)が実装されました。KOM の最初の使用用途は ZFS の ARC です。 Solaris 11.3 以前、ZFS ARC は kmem キャッシュを使用してカーネルヒープからメモリを確保していましたが、この実装にはいくつかの欠点がありました。 その一つは、ARC...

Solaris

Solaris 11.3 をインストールしてみました

pre.pre20151029 { color: gray; border: 1px solid #eaeaea; background-color: #f8f8f8; overflow: auto; padding: 6px 10px; border-radius: 3px;}Solaris 11.3 が リリース されたので早速インストールしてみました。# cat /etc/release Oracle Solaris 11.3 X86 Copyright (c) 1983, 2015, Oracle and/or its affiliates. All rights reserved. Assembled 06 October 2015# uname -srvmpiSunOS 5.11 11.3 i86pc i386 i86pc# pkg list entireNAME (PUBLISHER) VERSION IFOentire 0.5.11-0.175.3.1.0.5.0 i--# pkg info entire Name: entire Summary: Incorporation to lock all system packages to the same build Description: This package constrains system package versions to the same build. WARNING: Proper system update and correct package selection depend on the presence of this incorporation. Removing this package will result in an unsupported system. Category: Meta Packages/Incorporations State: Installed Publisher: solaris Version: 0.5.11 (Oracle Solaris 11.3.1.5.0) Build Release: 5.11 Branch: 0.175.3.1.0.5.0Packaging Date: Tue Oct 06 14:00:51 2015 Size: 5.46 kB FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.1.0.5.0:20151006T140051ZSolaris 11.3 の主要な新機能は、SPARC M7 CPU 上に実装されたセキュリティ機能 (SSM) のサポートKernel Zone のライブ・マイグレーションOpenStack Juno の実装Solaris の管理をシンプルにする REST APIなどですが、それ以外にも非常に多くの新機能が実装されています。Solaris 11.3 の新機能の一覧は What's New にまとまっています。現在 Solaris 10 をお使いの方は Solaris 10 からの移行ガイド をご参照ください。その他、各種機能や構成手順についてのより詳しい情報は ドキュメント・ライブラリ をご利用ください。Solaris 11.3 は こちら からダウンロードできます。インストール用の CD/DVD/USB イメージや Unified Archive のアーカイブファイル、IPS パッケージのリポジトリイメージ、OpenStack がインストールされた状態の Unified Archive ファイル、VirtualBox や Oracle VM 上に Solaris をデプロイする為のテンプレートイメージなどが用意されています。みなさまもぜひ Solaris の最新リリースをお試しください。

Solaris 11.3 が リリース されたので早速インストールしてみました。 # cat /etc/release Oracle Solaris 11.3 X86 Copyright (c) 1983, 2015, Oracle and/or its affiliates. All rights reserved. ...

Solaris

Oracle Solaris 11.3 ついにリリースされました

code{white-space: pre;}Oracle Solaris 11.3 ついにリリースされましたお待たせしました! OOW 2015 にて、下記製品を発表およびリリースすることができました。Oracle Solaris 11.3セキュリティ、スピード、シンプルを掲げ Oracle Solaris 11.3 をリリース。Solaris Zone の動的構成変更や読み込みのみに徹する Solaris Zone 環境を non-global zone から global zone へ拡張、Solaris Kernel Zones では暗号化されたパスによるライブマイグレーションをサポート。 仮想環境のセキュリティコンプライアンスを維持するためのカスタマイズ可能な評価機能、提供する全てのカーネルモジュールを証明書で管理することで不正な書き換えを検知した際にブートを抑制する Verified boot などをサポート。 SPARC M7 プロセッサと組み合わせによりメモリアドレスへの不正なアクセスを即座に検知が可能となる Silicon Secured Memory (SSM)のサポート。 これらの機能を OpenStack と組み合わせることで、OS とハードウェアを連携させたセキュアな環境を構築することが可能です。 (もっとあるけど、書き切れないOracle Solaris Cluster 4.3Solaris に冗長化機能を付加する Solaris Cluster 4.3 を同時にリリース。Cluster Manager GUI の強化、Zone を Zone Cluster へインポート可能となり、HA data service for zones では Kernel Zones の Live Migration と共有ストレージ上への Zones の配置を自動化する ZOSS (Zones on Shared Storage) など、Solaris Zones の機能サポートを強化。 また、Link Aggregation (IEEE802.3ad) や DLMP (Datalink Multipath) を public network でサポート。 Disaster Recovery Service を提供する Geographic Editon では Oracle Solaris ZFS Snapshot Replication, Oracle GoldenGate Replication をサポート。 さらに OpenStack for Solaris に Solaris Cluster を加えることにより HA OpenStack 環境を実現することが可能です。Oracle VM for SPARC 3.3SPARC Server に搭載される Hypervisor 機能を自在にコントロールするためのソフトウェアである Oracle VM for SPARC 3.3 をリリース。 Virtual SCSI host bus adapter (vHBA) をサポートし、ゲスト環境に多彩なタイプの SCSI デバイスを提供することが可能に。 また、ゲストドメイン環境のテンプレートサポートが強化され、テンプレートの作成やデプロイを行うための専用コマンドを新たに追加。 メモリブロック分割機能 (memory block splitting, Solaris 11.3 が稼働する guest domain のみ) により、ライブマイグレーション実行時に連続した空きメモリの確保は必要なくなりました。Oracle Solaris Studio 12.4, 4/15 Platform Specific Enhancement with support for SPARC M7 and Software in Siliconすでに提供済みとなる Oracle Solaris 12.4 では SPARC M7 プロセッサのパフォーマンスを最大限に引き出すだけではなく、Seculity in Silicon で実現される Silicon Secured Memory (Appliacation Data Integrity - ADI) をサポートするために拡張された Code Analyzer を強化するなどの機能拡張を Solaris Studio 12.4, 4/15 Platform Specific Enhancement (PSE)として提供。詳細は MOS Doc ID 1578240.1 にて。そして、これらの機能を余すことなく利用頂くために。Oracle SPARC M7 プロセッサを搭載した SPARC システムの新たなファミリーを同時に発表することができました。 まだまだ続くよー。

Oracle Solaris 11.3 ついにリリースされました お待たせしました! OOW 2015 にて、下記製品を発表およびリリースすることができました。 Oracle Solaris 11.3 セキュリティ、スピード、シンプルを掲げ Oracle Solaris 11.3 をリリース。Solaris Zone の動的構成変更や読み込みのみに徹する Solaris Zone...

Solaris

Solaris 11.3 Beta に関するブログ記事の紹介 Part 2

はじめに前回に引き続き Solaris 11.3 に関連したブログ記事をご紹介します。 今回は、セキュリティとコンプライアンス、システム管理、仮想化、ZFS についてのブログ記事をご紹介いたします。前回の記事をご覧になっていない方は こちら をご覧ください(Solaris 11.3 Beta のアナウンスメント、データベース関連のエンハンス、開発者向けの記事、OpenStack 関連の記事のまとめを紹介しています)。セキュリティとコンプライアンスNew Security Extensions in Oracle Solaris 11.3 (Solaris 11.3 のセキュリティの新機能)https://blogs.oracle.com/observatory/entry/new_security_extensions_in_oracleKris Kooi のブログ記事です。 Solaris 11.1 で実装された ASLR(アドレス空間配置のランダム化) に加えて、Solaris 11.3 では NXSTACK(non-executable stack) と NXHEAP(non-executable heap) の二つの実行領域保護機能が実装され、セキュリティが強化されています。また、sxadm コマンドが変更され、セキュリティ拡張機能の管理がより簡単になりました。 このブログ記事では NXSTACK と NXHEAP の挙動と sxadm コマンドの使い方をご紹介しています。OpenSSL on Oracle Solaris 11.3 (Solaris 11.3 の OpenSSL)https://blogs.oracle.com/observatory/entry/openssl_on_oracle_solaris_11Misaki Miyashita のブログ記事です。 Solaris 11.3 の OpenSSL について、SSLv2 の EOL、マルチスレッドプログラムやマルチプロセスプログラムでの安全性の向上などの変更点についてご紹介しています。 Solaris 版の OpenSSL については Solaris 11.2 の変更点 も合わせてご覧ください。Customising Solaris Compliance Policies (コンプライアンス・ポリシーのカスタマイズ)https://blogs.oracle.com/darren/entry/customising_solaris_compliance_policiesDarren Moffat のブログ記事です。 Solaris 11.2 から コンプライアンス・フレームワーク が実装されています。 Solaris 11.3 では、コンプライアンス要件のカスタマイズを容易にするため、compliance コマンドに tailor サブコマンドが実装されました。カスタマイズを再利用するための export アクションも実装されています。 このブログ記事では tailor サブコマンドの実行例をご紹介しています。Solaris new system calls: getentropy(2) and getrandom(2) (Solaris の新しいシステムコール: getentropy(2) と getrandom(2))https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropyDarren Moffat のブログ記事です。 Solaris 11.3 から getrandom(2) と getentropy(2) というシステムコールが追加されました。getrandom(2) はランダムなビットストリームを生成し、getentropy(2) はランダムビット生成器で使用するためのエントロピーを生成します。どちらも OpenBSD や Linux の同名の API と互換性があります。 このブログ記事では、この二つのシステムコールを使用する際の注意点をご紹介しています。Applying Rights Profiles to RAD Modules in Oracle Solaris 11.3 (Solaris 11.3 の RAD モジュールに権利プロファイルを適用する)https://blogs.oracle.com/gfaden/entry/applying_rights_profiles_to_radGlenn Faden のブログ記事です。 Solaris 11.3 から RAD モジュールごとに RBAC のプロファイルを設定することができるようになりました。User Manager GUI を例にして、新しい RAD とプロファイルの関係をご紹介します。PF for Solaris (Solaris の PF)https://blogs.oracle.com/solarisfw/entry/pf_for_solarisこれまで Solaris にバンドルされている Firewall ソフトウェアは IPF でしたが、Solaris 11.3 から OpenBSD 由来の PF も加わりました。 このブログ記事では IPF から PF に移行する際の注意点や PF を使い始める手順をご紹介しています。Solaris Kernel Zones Verified Boot (Solaris Kernel Zones の Verified Boot)https://blogs.oracle.com/DanX/entry/solaris_kernel_zones_verified_bootVerified Boot は OS の起動時にカーネルモジュールの署名を確認して、不正なモジュールや壊れているモジュールを検知する機能です。Verified Boot は Solaris 11.2 で実装されました。 Solaris 11.3 では、Verified Boot が Kernel Zone の起動にも利用できるようになりました。 このブログ記事では Kernel Zones Verified Boot の構成の仕方とその動作をご紹介しています。 Verified Boot については こちら も合わせてご参照ください。Solaris 11.3: New Immutable Global Zone file-mac-profile: dynamic-zones (Solaris 11.3: Immutable Global Zone の file-mac-profile の新しいパラメータ: dynamic-zones)https://blogs.oracle.com/casper/entry/solaris_11_3_new_immutableSolaris 11.2 で Immutable Global Zone が実装されました。Immutable Global Zone は、ファイルシステムへの変更が制限された Global Zone です。これまで、Immutable Global Zone に指定できる制限のプロファイルは、none, strict, fixed-configuration, flexible-configuration のいずれかでしたが、Solaris 11.3 では新しいプロファイルとして dynamic-zones が追加されました。 dynamic-zones プロファイルは OpenStack Nova から使用されることを想定しており、fixed-configuration プロファイルを Zone の作成・破棄ができるように緩和したプロファイルです。Solaris 11.3: New per-share, per-instance reserved port property for NFS (Solaris 11.3: NFS のシェア毎、インスタンス毎の特権ポートプロパティ)https://blogs.oracle.com/casper/entry/solaris_11_3_new_perNFS_PORTMON は、NFS サーバにアクセスがあった際に、クライアント側のポート番号が特権ポートだった場合のみにアクセスを許可するための設定です。 これまで NFS_PORTMON の設定は /etc/system に nfssrv:nfs_portmon を記載する方式でした。現在の Solaris では Zone 毎に NFS サーバを起動することができるため、NFS_PORTMON もより細かい区切りで有効・無効の制御ができるよう、Solaris 11.3 からは share 毎に NFS_PORTMON を設定できるような方法が追加されました。OpenSSH in Solaris 11.3 (Solaris 11.3 の OpenSSH)https://blogs.oracle.com/darren/entry/openssh_in_solaris_11_3これまで Solaris の SSH は OpenSSH から分岐した SunSSH が標準でした。 Solaris 11.3 からは SunSSH だけでなく OpenSSH のパッケージもバンドルされるようになり、どちらを使用するか OS の管理者が選択できるようになりました。将来的には OpenSSH が標準になる見込みです。システム管理Periodic and scheduled services with SMF (SMF を使った処理の定期実行と定時実行)https://blogs.oracle.com/gman/entry/periodic_and_scheduled_services_withSolaris 11.3 から、プログラムの定期的な繰り返し実行やスクリプトの定時実行を SMF で管理 できるようになりました。これまで Cron に設定していたような内容を SMF のマニフェストファイルで管理できるようになり、IPS との連携もしやすくなりました。 定期実行の場合はマニフェストファイルに periodic_method を定義し、定時実行の場合は scheduled_method を定義します。Cron Begone: Predictable Task Scheduling (さようなら Cron、予測可能なタスク管理)https://blogs.oracle.com/SolarisSMF/entry/cron_begone_predicable_task_schedulingSolaris 11.3 で実装された SMF の Periodic Restarter と Scheduled Services について、Cron に比べて優れている点として、エラーハンドリング、一貫性のあるログ管理、依存関係の解決、ライフサイクルの制御しやすさ、システム停止により実行されなかったタスクの実行管理、タスクの実行が特定の時間に集中して高負荷になることを防ぐためのランダム性を挙げています。Solaris 11.3 beta: Changes to bundled software packages (Solaris 11.3 Beta で更新されたバンドルパッケージ一覧)https://blogs.oracle.com/alanc/entry/solaris_11_3_beta_changesSolaris 11.3 Beta で追加・更新された主なパッケージの一覧です。 Python 3, OpenSSH, Apache 2.4, OpenBSD PF, Puppet Hiera などが新規で追加されています。 pigz は CMT と相性が良いので、ぜひお使いください。Introduction to svcbundle(1M) (svcbundle のご紹介)https://blogs.oracle.com/SolarisSMF/entry/introduction_to_code_svcbundle_code新しい SMF サービスを作成する際のハードルの一つに、マニフェストファイルの作成があります。svcbundle コマンドは、マニフェストファイルの作成を助けてくれるコマンドです。コマンドラインオプションで name=value 形式でパラメータを指定すると、SMF のマニフェストの XML ファイルを生成してくれます。Remote Administration with RAD and Oracle Solaris 11 (RAD を使用したリモートからの管理)https://blogs.oracle.com/gman/entry/remote_administration_with_rad_andこのブログ記事では、Python, C, Java, RESTful API を使ってプログラムから Solaris を管理できる RAD インターフェイスについて紹介しています。RAD については Getting Started with the Remote Administration Daemon on Oracle Solaris 11 もご参照ください。New flowadm features in Solaris 11.3 (flowadm の新機能)https://blogs.oracle.com/yenduri/entry/new_flowadm_features_in_s11Solaris 11.3 で flowadm コマンドに追加された新機能の中から、1. flow 上のパケットに DSCP を設定できるようになった、2. flow に direction 属性を設定して inbound のみや outbound のみの flow を作成できるようになった、3. flow 属性の組み合わせ制限 ("サポートされている属性の組み合わせ") の撤廃、4. 同一リンク上に異なる flow 属性の組み合わせをもった flow を作成できない制限 ("特定リンク上のすべてのフローが同じ組み合わせを保持する必要があり") の撤廃、同一パケットが複数の flow にマッチするような flow の作成が可能になった、flow の適用順を指定する rank 属性の追加、についてご紹介しています。Private VLAN in Solaris 11.3 (Solaris 11.3 のプライベート VLAN)https://blogs.oracle.com/yenduri/entry/private_vlan_in_solaris_11Solaris 11.3 で実装された Private VLAN について、isolated VLAN と community VLAN の構成の仕方、Zone への割り当ての仕方、sub-VLAN に VLAN タグを設定する方法をご紹介しています。Solaris 11.3: rtc(1m) no longer warps the time by default (Solaris 11.3 ではリアルタイムクロックのタイムゾーンを変更する際に、デフォルトではシステムの時間は変更されない)https://blogs.oracle.com/casper/entry/solaris_11_3_rtc_1mSolaris 11.3 では rtc(1M) コマンドに -w オプションが追加されました。x86 Solaris で、リアルタイムクロックのタイムゾーンを変更する際に -w オプションを付けるとシステムの時間がリアルタイムクロックに合わせて変更されます。-w オプションを付けない場合はシステムの時間は変更されず、リアルタイムクロックの時間が更新されます。rcapd enhancements in Solaris 11.3 (Solaris 11.3 におけるリソース上限デーモンの改良)https://blogs.oracle.com/puneetpruthi/entry/rcapd_enhancements_in_solaris_11Solaris 11.3 では rcapd の設定がより簡潔・簡単になり、メモリページ選択のアルゴリズムがより効率的なものに変更され、rcapd の動作がシステム全体の性能を低下させないような挙動になりました。Multi-CPU bindings for Solaris Project (Multi-CPU bindings を Solaris Project で使用する)https://blogs.oracle.com/zoneszone/entry/multi_cpu_bindings_for_solarisMCB (Multi-CPU binding) は、プロセスを特定の CPU のグループに結び付ける機能です。類似の機能にプロセッサーセットがありますが、プロセッサーセットが CPU の排他的な区画を作成するのに対し、MCB では他の MCB に入っている CPU も指定することが可能です。 MCB は Solaris 11.2 で実装されました。Solaris 11.3 からは、MCB がプロジェクトに設定できるようになっています。このブログ記事では、プロジェクトで実際に MCB を使用する例をご覧いただけます。仮想化Introducing Secure Live Migration (安全なライブマイグレーションのご紹介)https://blogs.oracle.com/listey/entry/introducing_secure_live_migrationSolaris 11.3 から Kernel Zone のライブマイグレーションができるようになりました。 このブログ記事では、Solaris 11.3 の Kernel Zone のライブマイグレーションがセキュリティに配慮していること、ライブマイグレーションを実施するにあたっての Tips がまとめられています。Secure multi-threaded live migration for kernel zones (Kernel Zones の安全でマルチスレッド化されたライブマイグレーション)https://blogs.oracle.com/zoneszone/entry/live_migration_for_kernel_zonesKernel Zone のライブマイグレーションの手順と、その背後で行われているネットワーク通信について、実例を元にご紹介しています。Kenel Zone のライブマイグレーションについては こちら もご覧ください。New features in Oracle Solaris Zones (Solaris Zones の新機能)https://blogs.oracle.com/listey/entry/new_features_in_oracle_solarisSolaris 11.3 の Zone の新機能として、Kernel Zone のセキュアなライブマイグレーション、NFS 上に Kernel Zone のルートファイルシステムを作成できるようになったこと、Kernel Zone の稼働中にネットワークとデバイスの構成変更が可能になったこと、Native Zone で仮想クロックが使えるようになったことを紹介しています。PV IPoIB in Kernel Zones in Solaris 11.3 (Solaris 11.3 の Kernel Zones の PV IPoIB)https://blogs.oracle.com/observatory/entry/pv_ipoib_in_kernel_zonesSolaris 11.3 から Kernel Zone で Paravirtualized IP over Infiniband データリンクを使用できるようになりました。このブログ記事では PV IPoIB の構成手順をご紹介します。Managing Orphan Zone Boot Environments (Orphan Zone Boot Environment の管理)https://blogs.oracle.com/puneetpruthi/entry/managing_orphan_zone_boot_environmentsZone のマイグレーションや Zone のアーカイブを attach する際に発生する Orphaned Boot Environment を管理する方法として、beadm list の出力に Orphaned BE であることを示すフラグが追加され、beadm destroy で Orphaned BE を削除できるようになり、zoneadm attach に Orphaned BE の生成を制御するオプションが追加されました。Kernel zone suspend now goes zoom! (Kernel Zones のサスペンドの高速化)https://blogs.oracle.com/zoneszone/entry/kernel_zone_suspend_now_goesSolaris 11.2 には Global Zone が再起動した際に Kenel Zone が自動的にサスペンド、レジュームする機能が実装されています。Solaris 11.3 からはメモリの圧縮・展開、および暗号化・複合がマルチスレッド化され、サスペンド、レジュームの処理時間が改善されました。Shared Storage on NFS for Kernel Zones (Kernel Zones の NFS へのインストール)https://blogs.oracle.com/zoneszone/entry/shared_storage_on_nfs_forSolaris 11.2 から Zone のルートファイルシステムを iSCSI デバイス上に配置できるようになりました。Solaris 11.3 ではさらに NFS 上にも Zone のルートファイルシステムを配置できるようになっています。 このブログ記事では NFS 上に Zone をインストールする手順をご紹介しています。Different time in different zones (Zone 毎に異なる時間の設定)https://blogs.oracle.com/anuthan/entry/different_time_in_different_zonesSolaris 11.3 から Solaris Zones と Solaris 10 Branded Zones で Zone 固有の時間を設定できるようになりました。 このブログ記事では、その設定パラメータと挙動をご紹介しています。ZFSChanges to ZFS ARC Memory Allocation in 11.3 (Solaris 11.3 の ZFS ARC メモリアロケーションの変更点)https://blogs.oracle.com/observatory/entry/changes_to_zfs_arc_memorySolaris 11.3 から ZFS の ARC の管理方法が代わり、キャッシュの大半は Kernel Object Manager によって Kernel Cage の外に配置されるようになりました。 これにより多くのシステムで zfs:zfs_arc_max の設定が不要になり、スケーラビリティも向上しました。Welcome to Oracle Solaris 11.3 ZFS (Solaris 11.3 ZFS のご紹介)https://blogs.oracle.com/zfs/entry/welcome_to_oracle_solaris_11Solaris 11.3 の ZFS の新機能として、LZ4 圧縮、defaultuserquota および defaultgroupquota パラメータによるデフォルトの Quota の設定、zpool monitor サブコマンドによるプールの監視、使用されていないスペアディスクの異常検知、メモリ操作とブロック割り当ての効率化、SMB 2.1 対応を挙げています。まとめ以上、Solaris 11.3 Beta に関するブログ記事をまとめてご紹介いたしました。ご覧いただきました通り、Solaris 11.3 にはとてもたくさんの修正・改善・新機能が含まれています。ぜひ Beta 版をダウンロード、インストールしていただき Solaris の勢いを感じていただけたらと思います。 Solaris 11.3 の正式リリースもどうぞご期待ください。

はじめに 前回に引き続き Solaris 11.3 に関連したブログ記事をご紹介します。 今回は、セキュリティとコンプライアンス、システム管理、仮想化、ZFS についてのブログ記事をご紹介いたします。 前回の記事をご覧になっていない方は こちらをご覧ください(Solaris 11.3 Beta のアナウンスメント、データベース関連のエンハンス、開発者向けの記事、OpenStack...

Solaris

Solaris 11.3 Beta に関するブログ記事の紹介 Part 1

はじめに先日、Solaris 11.3 Beta が 公開 されました。 それに合わせて Solaris 11.3 に関連したブログ記事が多数アップされています。 本稿ではそれらのブログ記事を簡単にまとめてご紹介したいと思います。 ブログ記事の数が多いため、前後半に分けて、今回は Solaris 11.3 Beta のアナウンスメント、データベース関連のエンハンス、開発者向けの記事、OpenStack 関連の記事をご紹介します。 次回の更新では、セキュリティとコンプライアンス、システム管理、仮想化、ZFS についての記事をご紹介する予定です。 Solaris 11.3 の新機能の多さと Solaris の開発の盛り上がりを感じていただけたら幸いです。アナウンスメントRelease of Oracle Solaris 11.3 Betahttps://blogs.oracle.com/markusflierl/entry/release_of_solaris_11_3Solaris 開発責任者の Marcus Flierl のブログです。 Solaris 11.3 は最も先進的なエンタープライズ・クラウド・プラットフォームであるとし、セキュリティとコンプライアンス、仮想化、OpenStack、ネットワーキング、Oracle DB との親和性について注目機能をご紹介しています。Oracle Solaris 11.3 Beta Now Available!https://blogs.oracle.com/gman/entry/oracle_solaris_11_3_betaGlynn Foster のブログです。 Solaris 11.3 の新機能で特に気に入っているものとして、OpenStack Juno 対応、Kernel Zones のライブマイグレーション、Zone を NFS 上に配置できること、LZ4 による ZFS の圧縮率の向上、PVLAN のサポート、RAD モジュールの追加とREST API によるアクセス、Hiera による Puppet のマニフェストの変数の置換、Oracle DB 12c の起動時間の短縮と Optimized Shared Memory による SGA のサイズ変更、不正なメモリアクセスを防ぐ Application Data Integrity を含んだ次世代 CPU の SPARC M7 への対応を挙げています。Oracle Solaris 11.3 Beta is now availablehttps://blogs.oracle.com/partnertech/entry/oracle_solaris_11_3_betaCaryl Takvorian のブログです。 ISV の開発者やアーキテクト向けに Solaris の新機能を紹介しています。 Solaris 11.3 の注目の機能として、セキュリティのツールとコンプライアンスレポート、SPARC M7 に実装された ADI に対応した mdb や DTrace などのコマンドおよび libadimalloc ライブラリ、Kernel Zones のライブマイグレーション、Heat、Ironic、Murano などの OpenStack の新サービスの追加、仮想化、簡単で高速な ライフサイクル管理 を挙げています。Oracle Solaris 11.3: Securing and Simplifying the Enterprise Cloudhttps://blogs.oracle.com/solaris/entry/solaris_11_3_betaLarry Wake のブログです。 Solaris 11 は既に OS のプロビジョニングやメンテナンス に関する優れた機能を持っており、システムへの攻撃に対する徹底的な防御機能 も更なる進化を遂げています。コンプライアンスのフレームワーク や OpenStack の統合、Unified Archive なども実装されています。 Solaris 11.3 では、それらに加えて、OpenStack Juno への対応、Kernel Zone の安全なライブマイグレーション、Zone の動的構成変更、Verified Boot、NFS 上に Zone を作成する機能、Oracle DB の起動時間の短縮、コンプライアンス機能の拡張、SPARC M7 の ADI への対応、LZ4 を使った ZFS の圧縮率の向上、異なる ZFS スナップショット間の差分の再帰的な比較、SMB プロトコルのバージョンアップなど、多数の新機能が加わったことを紹介しています。Here's Your Oracle Solaris 11.3 List of Blog Postshttps://blogs.oracle.com/solaris/entry/solaris_11_3_bloglistブログ記事へのリンク集です。この記事の英語版です。Oracle Solaris 11.3 Blog Posts, Part Twohttps://blogs.oracle.com/solaris/entry/11_3_bloglist_the_sequelブログ記事へのリンク集の Part 2 です。データベース関連Oracle Instant Client: now available in IPShttps://blogs.oracle.com/jmcp/entry/oracle_instant_client_now_availableOracle Instant Client に含まれている sqlplus や wrc などの Oracle DB のクライアントツールが http://pkg.oracle.com/ から pkg コマンドでインストールできるようになりました。Oracle Instant Client のバージョンが上がるごとに pkg.oracle.com の IPS のパッケージも更新されていきます。 Solaris の開発が Sun の Bugster から Oracle の Bug DB に移行した際の話もお読みいただけます。Virtual Address Reservation in Solaris 11.3https://blogs.oracle.com/observatory/entry/virtual_address_reservation_in_solarisVA Reservation はプロセスのメモリ空間内の特定の領域を予約する機能です。プログラムのコンパイル時に予約したいアドレスとサイズを指定することで、その領域がライブラリのロードなど、他の用途で使用されないようにします。Oracle DB の SGA のように、メモリ領域を特定の場所に確保したい場合に使用する機能です。 このブログエントリーでは VA Reservation の使い方と注意点を紹介しています。Solaris 11.3: Optimized Shared Memory (OSM)https://blogs.oracle.com/jwadams/entry/solaris_11_3_optimized_sharedSolaris には巨大な共有メモリ領域を効率的に確保する方法として ISM や DISM が実装されて来ました。OSM は ISM や DISM の後継機能として Solaris 11 や Solaris 10u11 で実装され、Oracle DB では 12c 以降で使用されています。Solaris 11.3 からはこの OSM のインターフェイスが公開され、Oracle DB 以外でも使用可能になりました。 このブログ記事では OSM インターフェイスの使用方法をご紹介しています。 また、Solaris 11.3 では OSM の実装に改善が加わり、このおかげで Oracle DB の shutdown 時間が改善された事も紹介されています。開発情報Better performing pthread reader-writer locks for NUMA architectureshttps://blogs.oracle.com/observatory/entry/better_performing_pthread_reader_writerSolaris 11.3 から lock cohorting 技術を使用した、NUMA システム上で効率的に動作するプロセス内 reader writer lock が実装されました。Sai Nanduri がこの rwlock の使い方と使いどころをご紹介しています。APIs for handling per-thread signals in Solarishttps://blogs.oracle.com/observatory/entry/apis_for_handling_per_threadSolaris 11.3 から別のプロセスの特定のスレッドにシグナルを送る API が実装されました。Sai Nanduri がそれらの API をご紹介します。Named threads in Oracle Solaris 11.3https://blogs.oracle.com/observatory/entry/named_threadsSolaris 11.3 からスレッドに名前を付ける機能が実装されました。 スレッドに命名する API が実装されたほか、ps や prstat コマンド、DTrace などの既存の解析ツールにもスレッド名を表示する修正が施されています。多くの OS 組み込みのプロセスでは既にスレッドに名前がつけられており、解析がしやすくなっています。 また、カーネルのスレッドにも名前が付けられており、DTrace の kthreadname 変数でカーネルのスレッド名を確認することができます。OpenStackUpgrading OpenStack from Havana to Junohttps://blogs.oracle.com/openstack/entry/upgrading_openstack_from_havana_toDrew Fisher の記事です。 Solaris 11.3 に含まれている OpenStack のバージョンは Juno です。Solaris 11.2 GA 版の Havana からは Icehouse をスキップして二つ先のバージョンになります。Havana から Juno へのアップグレード方法を提供する際に体験した問題点と、Solaris の BE を利用した『完全に安全なアップグレード("upgrade to Juno is completely safe")』をご紹介しています。 Solaris の Boot Environment 機能は本当に便利です。What's New in Solaris OpenStack Juno Neutronhttps://blogs.oracle.com/openstack/entry/what_s_new_in_solarisSolaris 11.3 の OpenStack Juno で加わった新機能について、1. テナントネットワークの IPv6 対応、2. Source NAT、3. メタデータサービス、4. Flat L2 ネットワークタイプ、5. neutron コマンドの新しいサブコマンドの 5 点を解説しています。Configuring the Neutron L3 Agent in Solaris OpenStack Junohttps://blogs.oracle.com/openstack/entry/configuring_the_neutron_l3_agentSolaris 11.3 の OpenStack Juno で Neutron を使用してネットワークセグメントとルーターを構成する手順を解説しています。Oracle Solaris gets OpenStack Juno Releasehttps://blogs.oracle.com/openstack/entry/oracle_solaris_gets_openstack_junoSolaris 11.2 SRU10 で OpenStack Juno が実装された際のアナウンスメントです。Solaris 11.3 の OpenStack Juno はここから更に改良と新機能が加わったものになっています。OpenStack Juno in Solaris 11.3 Betahttps://blogs.oracle.com/openstack/entry/openstack_juno_in_solaris_11Oracle 社内の Solaris のテスト・開発環境が OpenStack を使ったクラウドで運用されていること、Solaris 11.3 の OpenStack の始め方や新機能が紹介されています。Upgrading Solaris Engineering's OpenStack Cloudhttps://blogs.oracle.com/dminer/entry/safely_updating_a_solaris_openstackhttps://blogs.oracle.com/openstack/entry/upgrading_the_solaris_engineering_openstackDave Miner の記事です。 Solaris の開発環境を OpenStack Havana から OpenStack Juno にアップグレードした際の手順と体験談が紹介されています。このブログの過去の記事には、Solaris の開発環境を OpenStack で構築した際の手順も紹介されていますので、合わせてご覧ください。以上、Solaris 11.3 Beta のアナウンスメント、データベース関連のエンハンス、開発者向けの記事、OpenStack 関連のブログ記事をご紹介しました。Solaris 11.3 がどのような位置づけのリリースかご理解いただけたのではないかと思います。 次回の更新では、セキュリティとコンプライアンス、システム管理、仮想化、ZFS についてのブログ記事をご紹介する予定です。どうぞご期待ください。 このブログエントリーは vim -u NONE で Markdown ファイルを作成し、変換フィルターを使って HTML を生成しました。やはり素の vi が一番ですね。

はじめに 先日、Solaris 11.3 Beta が 公開 されました。 それに合わせて Solaris 11.3 に関連したブログ記事が多数アップされています。 本稿ではそれらのブログ記事を簡単にまとめてご紹介したいと思います。 ブログ記事の数が多いため、前後半に分けて、今回は Solaris 11.3...

Solaris

Oracle Solaris の SAS ドライバについて

code{white-space: pre;}Solaris の SAS driverSolaris が標準で持っている SAS driverSolaris が持っている SAS driver を整理してみる。 色々あるが、これからは lmrc か lsc を選択するのが良いかと思い、手元では LSI SAS9300-4i (lsc driver) と LSI MegaRAID SAS 9341-4i (lmrc: Solaris 11.2 SRU 12 or Solaris 11.3 Beta でサポート) が動いていますが、どちらも Oracle のオプションとして販売されているものではありません。 pmcs という謎ドライバもありますが、これは、Adaptec by PMC 製品用の driver になり、何をサポートしているかは良くわかっていません。SAS versiondriver namedesc.3.0lmrcLSI MegaRAID SAS 3.0 Controller HBA driver3.0lscLSI SAS 3.0 host bus adapter driver2.0pmcsPMC-Sierra SAS 2.0 HBA driver2.0mpt_sasSAS-2 host bus adapter driver2.0mr_sasLSI MegaRAID SAS2.0 Controller HBA driver2.0scuIntel SAS2.0 storage controller unit driver2.0imraid_sasLSI MegaRAID FALCON SAS2.0 Controller HBA driver1.0aacSCSI HBA driver for Adaptec AdvancedRAID Controller1.0arcmsrSAS and SATA HBA driver for Areca Hardware Raid devices1.0cpqary3provides disk and SCSI tape support for HP Smart Array controllers1.0mega_sasSCSI HBA driver for LSI MegaRAID SAS controller1.0mptSCSI host bus adapter driver ちなみに、lmrc/lsc driver が認識する device id はこちら。 lmrc "pciex1000,5d" LSI MegaRAID SAS 9341-4i lmrc "pciex1000,5f" lsc "pciex1000,96" SAS9300-4i lsc "pciex1000,97"driver.conf の格納場所についてSolaris 11 から /etc/driver/drv ディレクトリが用意された。 このディレクトリに配置された driver.conf ファイルは最優先で読み込まれる。 /kernel/drv/ や /platform/kernel/drv に配置されるファイルを直接編集せず、/etc/driver/drv に集約することで管理が楽になるので積極的に利用することをオススメ。 デフォルトで、SAS 関連の driver.conf があるので注意。 とにかく、driver の設定を変更する場合は、/kernel/drv や /platform/kernel/drv から、ここにファイルをコピーして編集して運用すればいい。 参考:管理者が提供する driver.conf ファイルのサポート (Oracle Solaris 11 Information Library)SAS HBA 関連のユーテリティ/usr/sbin/sasinfoSolaris 11 から追加されたコマンド。 sasinfo は SAS HBA やそれに関連する情報を収集するためのコマンド。 LSI SAS9300-4i の例# sasinfo hba -vHBA Name: SUNW-lsc-0Manufacturer: LSI LogicModel: SAS9300-4iFirmware Version: 1.0.2.0FCode/BIOS Version: not availableSerial Number: Driver Name: lscDriver Version: lsc driverNumber of HBA Ports: 1Avago (LSI) MegaRAID SAS 9341-4i の例$ sasinfo hba -vHBA Name: SUNW-lmrc-0Manufacturer: LSI LogicModel: AVAGO MegaRAID SAS 9341-4iFirmware Version: 4.280.01-4227FCode/BIOS Version: not availableSerial Number: Driver Name: lmrcDriver Version: LMRC Driver 1.3.0.0Number of HBA Ports: 0StorCliAvago (LSI) が提供する RAID 機能を持つ SAS HBA 向けのユーテリティ。 Solaris の lmrc driver をサポートしている。# ./storcli /c0 show Generating detailed summary of the adapter, it may take a while to complete.Controller = 0Status = SuccessDescription = NoneProduct Name = AVAGO MegaRAID SAS 9341-4iSerial Number = SVSAS Address = 500605b00700d600PCI Address = 00:0a:00:00System Time = 07/10/2015 08:24:55Mfg. Date = 11/12/13Controller Time = 07/09/2015 23:24:47FW Package Build = 24.8.0-0020BIOS Version = 6.24.05.0_4.17.08.00_0x060D0200FW Version = 4.280.01-4227Driver Name = lmrcDriver Version = LMRC Driver 1.3.0.0Vendor Id = 0x1000Device Id = 0x5FSubVendor Id = 0x1000SubDevice Id = 0x9343Host Interface = PCIEDevice Interface = SAS-12GBus Number = 10Device Number = 0Function Number = 0Drive Groups = 1TOPOLOGY :========--------------------------------------------------------------------------DG Arr Row EID:Slot DID Type State BT Size PDC PI SED DS3 FSpace -------------------------------------------------------------------------- 0 - - - - RAID0 Optl N 232.375 GB dflt N N dflt N 0 0 - - - RAID0 Optl N 232.375 GB dflt N N dflt N 0 0 0 62:0 10 DRIVE Onln N 232.375 GB dflt N N dflt - --------------------------------------------------------------------------DG=Disk Group Index|Arr=Array Index|Row=Row Index|EID=Enclosure Device IDDID=Device ID|Type=Drive Type|Onln=Online|Rbld=Rebuild|Dgrd=DegradedPdgd=Partially degraded|Offln=Offline|BT=Background Task ActivePDC=PD Cache|PI=Protection Info|SED=Self Encrypting Drive|Frgn=ForeignDS3=Dimmer Switch 3|dflt=Default|Msng=Missing|FSpace=Free Space PresentVirtual Drives = 1VD LIST :=======-----------------------------------------------------------DG/VD TYPE State Access Consist Cache sCC Size Name -----------------------------------------------------------0/0 RAID0 Optl RW Yes NRWTD - 232.375 GB -----------------------------------------------------------Cac=CacheCade|Rec=Recovery|OfLn=OffLine|Pdgd=Partially Degraded|dgrd=DegradedOptl=Optimal|RO=Read Only|RW=Read Write|B=Blocked|Consist=Consistent|R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack|AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=ScheduledCheck ConsistencyPhysical Drives = 1PD LIST :=======--------------------------------------------------------------------EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp --------------------------------------------------------------------62:0 10 Onln 0 232.375 GB SATA HDD N N 512B VB0250EAVER U --------------------------------------------------------------------EID-Enclosure Device ID|Slt-Slot No.|DID-Device ID|DG-DriveGroupDHS-Dedicated Hot Spare|UGood-Unconfigured Good|GHS-Global HotspareUBad-Unconfigured Bad|Onln-Online|Offln-Offline|Intf-InterfaceMed-Media Type|SED-Self Encryptive Drive|PI-Protection InfoSeSz-Sector Size|Sp-Spun|U-Up|D-Down|T-Transition|F-ForeignUGUnsp-Unsupported|UGShld-UnConfigured shielded|HSPShld-Hotspare shieldedCFShld-Configured shieldedsas3ircu (Avago)Avago (LSI) が提供する RAID 機能を持たない SAS HBA 向けのユーテリティ。# ./sas3ircu 0 displayAvago Technologies SAS3 IR Configuration Utility.Version 09.00.00.00 (2015.02.03) Copyright (c) 2009-2015 Avago Technologies. All rights reserved. Read configuration has been initiated for controller 0------------------------------------------------------------------------Controller information------------------------------------------------------------------------ Controller type : SAS3004 BIOS version : 8.03.00.00 Firmware version : 1.00.02.00 Channel description : 1 Serial Attached SCSI Initiator ID : 0 Maximum physical devices : 1023 Concurrent commands supported : 10240 Slot : 3 Segment : 0 Bus : 10 Device : 0 Function : 0 RAID Support : No------------------------------------------------------------------------IR Volume information------------------------------------------------------------------------------------------------------------------------------------------------Physical device information------------------------------------------------------------------------Initiator at ID #0Device is a Hard disk Enclosure # : 1 Slot # : 2 SAS Address : 4433221-1-0100-0000 State : Ready (RDY) Size (in MB)/(in sectors) : 2861588/5860533167 Manufacturer : ATA Model Number : WDC WD30EFRX-68E Firmware Revision : 0A80 Serial No : WDWMC4N2751827 GUID : 50014ee059248293 Protocol : SATA Drive Type : SATA_HDD------------------------------------------------------------------------Enclosure information------------------------------------------------------------------------ Enclosure# : 1 Logical ID : 500605b0:06cce680 Numslots : 4 StartSlot : 0------------------------------------------------------------------------SAS3IRCU: Command DISPLAY Completed Successfully.SAS3IRCU: Utility Completed Successfully.MPxIO (マルチパス)SAS もマルチパスの対象となる。Solaris 11.2 まで:プラットフォーム状態x86デフォルトで有効SPARCオプションSolaris 11.3 から:プラットフォーム状態x86デフォルトで有効SPARCデフォルトで有効mpxio が有効になっていると scsi_vhci (7d) driver でデバイスが管理される。root@solaris:~/solaris~on-src# formatSearching for disks...doneAVAILABLE DISK SELECTIONS: 0. c0t0d0 /scsi_vhci/disk@g600605b00700d6001cddfb8a0bcf23c4/etc/driver/drv/lmrc.conf に mpxio-disable="yes"; を追加して reboot すれば良いがコントローラ番号が変わってしまうので注意(device path が変更になるため)root@solaris:~# formatSearching for disks...doneAVAILABLE DISK SELECTIONS: 0. c2t0d0 /pci@0,0/pci8086,8c10@1c/pci1000,9343@0/iport@v0/disk@v600605b00700d6001cddfb8a0bcf23c4,0参考情報LSI SAS 9300-4i Host Bus AdapterMegaRAID SAS 9341-4iDoc ID 1622636.1: How to Disable MPxIO (Oracle Solaris Storage Multi-Pathing Software, AKA STMS, SCSI_VHCI) on a Single Port SAS ControllerTodopkg search pkg.fmri:driver/storage | sort -u他、なにか忘れてないか確認まったく Solaris とは関係ないのですが、この記事、友人イチオシ無償だけど今からチュウモクシテオケ的な Visual Studio Code の Markdown mode を使って書いてみました。tasks に pandoc を仕掛けて HTML に変換したものをコピペしたのですが、入力も軽快で良い感じに使えています 。code を書くためのものですが便利に使えています。

Solaris の SAS driver Solaris が標準で持っている SAS driver Solaris が持っている SAS driver を整理してみる。色々あるが、これからは lmrc か lsc を選択するのが良いかと思い、手元では LSI SAS9300-4i (lsc driver) と LSI MegaRAID SAS 9341-4i (lmrc: Solaris 11.2...

Solaris

Solaris 11.3 Beta が公開されました

pre.pre20150708 { color: gray; border: 1px solid #eaeaea; background-color: #f8f8f8; overflow: auto; padding: 6px 10px; border-radius: 3px;}Solaris 11.3 の Beta 版が 公開 されましたので早速インストールしてみました。# cat /etc/release Oracle Solaris 11.3 SPARC Copyright (c) 1983, 2015, Oracle and/or its affiliates. All rights reserved. Assembled 22 June 2015# uname -srvmpiSunOS 5.11 11.3 sun4v sparc sun4v# pkg list entireNAME (PUBLISHER) VERSION IFOentire 0.5.11-0.175.3.0.0.25.0 i--# pkg info entire Name: entire Summary: Incorporation to lock all system packages to the same build Description: This package constrains system package versions to the same build. WARNING: Proper system update and correct package selection depend on the presence of this incorporation. Removing this package will result in an unsupported system. Category: Meta Packages/Incorporations State: Installed Publisher: solaris Version: 0.5.11 (Oracle Solaris 11.3.0.25.0) Build Release: 5.11 Branch: 0.175.3.0.0.25.0Packaging Date: June 22, 2015 02:27:46 PM Size: 5.46 kB FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.0.0.25.0:20150622T142746ZSolaris 11.3 Beta は こちら からダウンロードしていただけます。インストール用の OS イメージや Unified Archive のファイル、Kernel Zones の Live Migration に必要なファームウェア、パッケージのリポジトリイメージ、OpenStack お試し用の Unified Archive ファイル、VirtualBox や Oracle VM 用のテンプレートイメージなどが用意されています。Solaris 11.3 Beta のドキュメントは こちら にあります。新機能の一覧は こちら の What's New をご覧ください。 いくつかの新機能について紹介したスライドも用意しました。 【特別編】【第七回 ゼロから始める Solaris 11.X】01 仮想化関連アップデート ~Solaris ゾーンでもついにアレが可能に?~ from SolarisJP 【特別編】【第七回 ゼロから始める Solaris 11.X】02 OpenStack on Solaris アップデート 〜 更に高まる Solaris の可能性 〜 from SolarisJP 【特別編】【第七回 ゼロから始める Solaris 11.X】03 セキュリティ関連アップデート ~改ざんからシステムを守る!~ from SolarisJP Solaris の最新機能をぜひお試しください。

Solaris 11.3 の Beta 版が 公開 されましたので早速インストールしてみました。 # cat /etc/release Oracle Solaris 11.3 SPARC Copyright (c) 1983, 2015, Oracle and/or its affiliates. All rights reserved. ...

Solaris

[ホワイトペーパー] Solaris Zone によるハードパーティションの構成

Solaris Zone を使用してハードパーティションを構成する方法がホワイトペーパーとして公開されました。Hard Partitioning With Oracle Solaris ZonesSolaris 上で Oracle 社製ソフトウェアを稼働させるシステムの導入・設計・提案をご検討されている方は是非ご一読ください。ハードパーティションについてはこちらをご参照ください。Oracle Partitioning Policy (英語)Oracle Partitioning Policy (日本語)Solaris Zone ではなく OVM for SPARC を使用してハードパーティションを構成する場合については以下をご参照ください。Hard Partitioning With Oracle VM Server for SPARC (英語)Oracle VM Server for SPARCを使用したHard Partitioning (日本語)Oracle® VM Server for SPARC 3.1 Administration Guide : Configuring the System With Hard Partitions (英語)Oracle® VM Server for SPARC 3.1 管理ガイド : ハードパーティションによるシステムの構成 (日本語)Solaris 11 のホワイトペーパーはこちらからアクセスしていただけます。Oracle Solaris 11 White Papers (英語) Oracle Solaris 開発者向けリソース (日本語) Oracle Solaris 11.2 マニュアル検索もご活用ください。※ 上記は 2014/10/31 時点の情報です。

Solaris Zone を使用してハードパーティションを構成する方法がホワイトペーパーとして公開されました。 Hard Partitioning With Oracle Solaris Zones Solaris 上で Oracle 社製ソフトウェアを稼働させるシステムの導入・設計・提案をご検討されている方は是非ご一読ください。 ハードパーティションについてはこちらをご参照ください。 Oracle...

Storage

ZFS Storage Appliance が OpenStack Cinder の block storage resource として利用可能に

Oracle ZFS Storage Appliance の RESTfull API サポートを紹介しましたが、これには続きがありました。というわけで、RESTfull API が利用できる Oracle ZFS Storage Appliance は、OpenStack Cinder の block storage resource として利用可能になります。iSCSI を利用した block volume をインスタンスに提供することが可能となり、Oracle ZFS Storage Appliance が提供する機能(暗号化など)と組み合わせることが可能になります。   下記に必要な条件をまとめてみました。 Oracle ZFS Stoarge Appliance の条件 OS 8.2 以降をサポート REST サービスが有効化 cinder.akwf を ZFS Storage Appliance にアップロード cinder.akwf の入手先 https://java.net/projects/solaris-userland/sources/gate/show/components/openstack/cinder/files/zfssa Oracle Solaris 11.2 の /usr/lib/python2.6/vendor-packages/cinder/volume/drivers/zfssa ディレクトリ Workflow の実行: Configuration for OpenStack Cinder Driver を実行し、REST API の認証に利用するユーザを作成 Cinder Host の条件 Oracle Solaris 11.2 を利用する Oracle Solaris 11.2 の Cinder パッケージに含まれる Oracle ZFS Storage Appliance iSCSI Cinder Driver version 1.0.0 を利用 Solaris 11.2 以外の OpenStack Grizlly, Havana リリースの Cinder が動作しているホスト https://java.net/projects/solaris-userland/sources/gate/show/components/openstack/cinder/files/zfssa から Driver を入手し、Cinder Host の所定ディレクトリ(<openstack>/cinder/volumes/drivers/zfssa/)に配置 /etc/cinder/cinder.conf に ZFS Storage Appliance の情報を追加 と、このような流れで block storage resource として利用できるようになります。 下記は、Oracle Solaris 11.2 上にて cinder コマンドを利用し volume を作成した例となります。 利用する際には、README (https://openstack.java.net/ZFSSACinderDriver.README) を参照してくださいね。先に紹介した ZFS Storage Appliance Simulator でも動作すると思います。  Oracle's Sun NAS Storage Downloadshttp://www.oracle.com/technetwork/server-storage/sun-unified-storage/downloads/index.html Cinder Driver for the Oracle ZFS Storage Appliancehttps://openstack.java.net/ZFSSACinderDriver.README OpenStack Cinder Driver Download herehttps://java.net/projects/solaris-userland/sources/gate/show/components/openstack/cinder/files/zfssa OpenStack on Oracle Solarishttps://openstack.java.net Oracle ZFS Storage Appliance iSCSI Driverhttps://github.com/openstack/cinder-specs/blob/master/specs/juno/oracle-zfssa-cinder-driver.rst Horizon からインスタンスを作成すると ZOSS (Zones on Shared Storage) を利用した Solaris Zone (iSCSI を利用した volume 上に non-global zone を配置)が作成されることを確認できました。色々と確認しなければならないことは多いですが、cinder コマンドから ZFS Storage Appliance を操作および利用できるようになったことで、また一つ可能性が広がりました。        

Oracle ZFS Storage Appliance の RESTfull API サポートを紹介しましたが、これには続きがありました。 というわけで、RESTfull API が利用できる Oracle ZFS Storage Appliance は、OpenStack Cinder の block storage resource として利用可能になります。iSCSI を利用した...

Storage

Oracle ZFS Storage Simulator で RESTfull API を使って情報を参照してみる

2014/8/1 に Oracle ZFS Storage ZS3 シリーズに関する下記リリースを発表させて頂きました。 「Oracle ZFS Storage ZS3」シリーズの仮想化とクラウド機能の強化を発表 その中で気になったのが下記の一文です。 「Oracle ZFS Storage OS 8.2」のクラウド機能の拡張により、「OpenStack Cinder *3」対応のドライバーが追加され、REST対応APIも提供されました。 なんとか試してみたいなぁというわけで、Oracle ZFS Storage Simulator を確認すると、OS 8.2 版に更新されていました。これは、VirtualBox が動作する環境であれば Oracle ZFS Storage の機能を評価できる優れもの。クラスタなどの機能は専用の機構を利用しているため評価できませんが、ハードウェアに依存しないストレージの機能や Analytics などのほぼ全ての機能評価することが可能という素晴らしい Simulator です。 Oracle ZFS Storage Simulatorhttp://www.oracle.com/technetwork/server-storage/sun-unified-storage/downloads/sun-simulator-1368816.html これを利用することで、RESTfull API の動作確認はできるはず。また、ZFS Storage Appliance の RESTfull API については、下記のマニュアルに情報が記載されています。ストレージのほとんどの操作が API 経由で可能なようです。 Oracle® ZFS Storage Appliance RESTful Application Programming Interfacehttp://docs.oracle.com/cd/E51475_01/html/E52433/index.html 早速、Simulator をダウンロードし、VBox 上で起動。デフォルトでは REST サービスが disable になっていますので、これを enable にします。手っ取り早く確認したいので、VIrtualBox のポートフォワーディング機能を使い、Simulator VM の Port: 215 をホスト OS の Port: 10215 にマッピングし、https://localhost:10215 経由でのアクセスしています。 さっそく、curl を使ってアクセスしてみます。これは、/api/system/v1/version から ZFS Storage Appliance 環境のバージョン情報を取り出したものです。 $ curl --user root:password -k -i https://localhost:10215/api/system/v1/version HTTP/1.1 200 OK Date: Sun, 10 Aug 2014 00:07:36 GMT Server: TwistedWeb/10.1.0 Content-Length: 814 X-Zfssa-Version: ak/generic@2013.06.05.2.0,1-1.10 X-Zfssa-Api-Version: 1.0 X-Zfssa-System-Api: 1.0 Content-Type: application/json; charset=utf-8 {"version": {"href": "/api/system/v1/version", "nodename": "unknown", "mkt_product": "Oracle ZFS Storage VirtualBox", "product": "Sun Storage 7000", "version": "2013.06.05.2.0,1-1.10", "install_time": "Mon Jun 23 2014 09:33:16 GMT+0000 (UTC)", "update_time": "Mon Jun 23 2014 09:33:16 GMT+0000 (UTC)", "boot_time": "Sat Aug 09 2014 23:24:29 GMT+0000 (UTC)", "asn": "de217be8-104f-6106-db7f-9c9f7789faf6", "csn": "unknown", "part": "Oracle 000-0000", "urn": "urn:uuid:11da4018-a79e-11dd-a2a2-080020a9ed93", "navname": "aksh 1.0", "navagent": "aksh", "http": "Apache/2.2.24 (Unix)", "ssl": "OpenSSL 1.0.0k 5 Feb 2013", "ak_version": "ak/SUNW,ankimo@2013.06.05.2.0,1-1.10", "os_version": "SunOS 5.11 ak/generic@2013.06.05.2.0,1-1.10 64-bit", "bios_version": "innotek GmbH VirtualBox 12/01/2006", "sp_version": "-" }} もう少し出力を見やすく整形できればと調べたところ、python 2.6 から含まれる json.tool module を利用することで、ぐっと見易くなりました。curl の -i オプションで出力される protocol header がふくまれると解析に失敗してしまいますので、-i オプションを外し、パイプで python -m json.tool に渡してあげるおとで、先ほどの出力よりもさらに見易くなった結果を手に入れることができます。 $ curl --user root:password -k https://localhost:10215/api/system/v1/version | python -m json.tool   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                  Dload  Upload   Total   Spent    Left  Speed 100   814  100   814    0     0    507      0  0:00:01  0:00:01 --:--:--   507 {     "version": {         "ak_version": "ak/SUNW,ankimo@2013.06.05.2.0,1-1.10",         "asn": "de217be8-104f-6106-db7f-9c9f7789faf6",         "bios_version": "innotek GmbH VirtualBox 12/01/2006",         "boot_time": "Sat Aug 09 2014 23:24:29 GMT+0000 (UTC)",         "csn": "unknown",         "href": "/api/system/v1/version",         "http": "Apache/2.2.24 (Unix)",         "install_time": "Mon Jun 23 2014 09:33:16 GMT+0000 (UTC)",         "mkt_product": "Oracle ZFS Storage VirtualBox",         "navagent": "aksh",         "navname": "aksh 1.0",         "nodename": "unknown",         "os_version": "SunOS 5.11 ak/generic@2013.06.05.2.0,1-1.10 64-bit",         "part": "Oracle 000-0000",         "product": "Sun Storage 7000",         "sp_version": "-",         "ssl": "OpenSSL 1.0.0k 5 Feb 2013",         "update_time": "Mon Jun 23 2014 09:33:16 GMT+0000 (UTC)",         "urn": "urn:uuid:11da4018-a79e-11dd-a2a2-080020a9ed93",         "version": "2013.06.05.2.0,1-1.10"     } } さらにさらに、jq なる json processor が色付けしてくれたり整形してくれたり色々加工できるということで試してみた。 jqhttp://stedolan.github.io/jq/ 今回は出力を得るのは Mac OS X 環境となりますので、Mac OS X binary を利用してみました。バージョン情報の他、pool の情報や、プロジェクトの情報も取ってみましたがキレイに出力されますね。python -m json.tool と jq があることを覚えておくと良いようです。 $ curl --user root:password -k https://localhost:10215/api/system/v1/version | ~/opt/bin/jq '.'   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                  Dload  Upload   Total   Spent    Left  Speed 100   814  100   814    0     0    548      0  0:00:01  0:00:01 --:--:--   548 { "version": { "href": "/api/system/v1/version", "nodename": "unknown", "mkt_product": "Oracle ZFS Storage VirtualBox", "product": "Sun Storage 7000", "version": "2013.06.05.2.0,1-1.10", "install_time": "Mon Jun 23 2014 09:33:16 GMT+0000 (UTC)", "update_time": "Mon Jun 23 2014 09:33:16 GMT+0000 (UTC)", "boot_time": "Sat Aug 09 2014 23:24:29 GMT+0000 (UTC)", "asn": "de217be8-104f-6106-db7f-9c9f7789faf6", "csn": "unknown", "part": "Oracle 000-0000", "urn": "urn:uuid:11da4018-a79e-11dd-a2a2-080020a9ed93", "navname": "aksh 1.0", "navagent": "aksh", "http": "Apache/2.2.24 (Unix)", "ssl": "OpenSSL 1.0.0k 5 Feb 2013", "ak_version": "ak/SUNW,ankimo@2013.06.05.2.0,1-1.10", "os_version": "SunOS 5.11 ak/generic@2013.06.05.2.0,1-1.10 64-bit", "bios_version": "innotek GmbH VirtualBox 12/01/2006", "sp_version": "-"   } } $ curl --user root:password -k https://localhost:10215/api/storage/v1/pools/vboxpool | ~/opt/bin/jq '.'   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                  Dload  Upload   Total   Spent    Left  Speed 100  2308  100  2308    0     0  22349      0 --:--:-- --:--:-- --:--:-- 22407 { "pool": { "status": "online", "profile": "stripe", "errors": [], "scrub": { "errors": 0, "repaired": 0, "complete": true     }, "name": "vboxpool", "usage": { "available": 80026824704, "total": 80027320320, "dedupratio": 100, "used": 495616     }, "peer": "00000000-0000-0000-0000-000000000000", "vdev": [       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 1"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 2"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 3"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 4"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 5"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 6"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 7"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 8"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 9"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 10"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 11"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 12"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 13"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 14"       },       { "size": 5368709120, "state": "healthy", "chassis": "00a62383-eb97-c48c-f88b-ea9afe7b89a5", "type": "disk", "label": "HDD 15"       }     ], "owner": "unknown", "asn": "de217be8-104f-6106-db7f-9c9f7789faf6"   } } $ curl --user root:password -k https://localhost:10215/api/storage/v1/pools/vboxpool/projects | ~/opt/bin/jq '.'   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                  Dload  Upload   Total   Spent    Left  Speed 100  1765    0  1765    0     0  39935      0 --:--:-- --:--:-- --:--:-- 40113 { "projects": [     { "default_volblocksize": 8192, "logbias": "latency", "creation": "20140809T23:28:30", "nodestroy": false, "dedup": false, "sharenfs": "on", "href": "/api/storage/v1/pools/vboxpool/projects/default", "sharesmb": "off", "default_permissions": "700", "mountpoint": "/export", "snaplabel": "", "id": "f4c572c1-20d9-400a-0000-000000000000", "readonly": false, "space_data": 31744, "compression": "off", "sharetftp": "", "source": { "logbias": "inherited", "dedup": "inherited", "sharenfs": "local", "sharesmb": "local", "mountpoint": "local", "rrsrc_actions": "local", "compression": "inherited", "sharetftp": "local", "snapdir": "inherited", "sharedav": "local", "copies": "inherited", "aclinherit": "inherited", "shareftp": "local", "readonly": "inherited", "secondarycache": "inherited", "maxblocksize": "inherited", "exported": "local", "vscan": "inherited", "reservation": "local", "atime": "inherited", "recordsize": "inherited", "checksum": "inherited", "sharesftp": "local", "nbmand": "inherited", "aclmode": "inherited", "rstchown": "inherited"       }, "default_sparse": false, "snapdir": "hidden", "aclmode": "discard", "copies": 1, "aclinherit": "restricted", "compressratio": 100, "shareftp": "", "canonical_name": "vboxpool/local/default", "recordsize": 131072, "space_available": 78776401920, "secondarycache": "all", "space_snapshots": 0, "space_unused_res": 0, "quota": 0, "maxblocksize": 1048576, "exported": true, "default_volsize": 0, "vscan": false, "reservation": 0, "atime": true, "pool": "vboxpool", "default_user": "nobody", "space_unused_res_shares": 0, "name": "default", "checksum": "fletcher4", "space_total": 31744, "default_group": "other", "sharesftp": "", "nbmand": false, "sharedav": "", "rstchown": true     }   ] } curl を使った参照のみによる簡単な RESTfull API の動作確認でしたが、Oracle ZFS Storage Appliance も OS 8.2 によりおもしろくなってきました。 Oracle ZFS Storage Appliance は、この RESTfull API を利用することで、OpenStack のブロックストレージリソース (Cinder) として利用することができるようになっています。(Cinder Host に ZFS Storage Appliance 用の driver を別途インストールが必要)このへんも整理できたらまとめてみたいと思います。

2014/8/1 に Oracle ZFS Storage ZS3 シリーズに関する下記リリースを発表させて頂きました。 「Oracle ZFS Storage ZS3」シリーズの仮想化とクラウド機能の強化を発表 その中で気になったのが下記の一文です。 「Oracle ZFS Storage OS 8.2」のクラウド機能の拡張により、「OpenStack...

Solaris

TCP トラフィックの輻輳制御の実装について (Congestion Control)

Solaris の TCP 輻輳制御の実装 (Congestion Control) が、Solaris 10 から変更になっていました汗 Solaris 10 までは、RFC 2581 に準拠したアルゴリズムを採用し固定でしたが、Solaris 11 からは、このアルゴリズムの実装を Pluggable にし複数の実装を提供できる Pluggable TCP Congestion Control と呼ばれる実装に変更されています。Solaris 11 以降では、NewReno をデフォルトのアルゴリズムとし、New Reno の改良版である High Speed, Linux 2.6 以降で利用される CUBIC, Round-Trip Time による輻輳管理を行う Vefas の 4 つのアルゴリズムをサポートし、ipadm set-prop コマンドで変更でます。  バージョン  アルゴリズム  Solaris 10 まで  RFC 2581 準拠のアルゴリズム (ハードコード)  Solaris 11 以降  Pluggable TCP Congestion Control 機能によりアルゴリズムを plugin で実装し選定可能に newreno デフォルトアルゴリズム。制御メカニズムには、送信側の輻輳ウィンドウ、スロースタート、および輻輳回避があります highspeed 高速ネットワーク用のもっとも有名かつシンプルな NewReno の修正版の 1 つ cubic Linux 2.6 の現在のデフォルトアルゴリズム。輻輳回避フェーズを線形的なウィンドウ増加から cubic 関数に変更します vegas 実際のパケットロスを発生させずに輻輳を予測しようとする典型的な遅延ベースのアルゴリズム 確認方法は、ipadm show-prop で出力される下記のプロパティを参照してください。変更は、ipadm set-prop -p cong_default=cube tcp のように実行します。詳細は、下記のマニュアルで。Oracle Solaris 11.1 での固定ネットワーク構成を使用したシステムの接続> トラフィックの輻輳制御の実装http://docs.oracle.com/cd/E37932_01/html/E36462/ggtvn.html#gkkdvTCP: # ipadm show-prop -p cong_default tcpPROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLEtcp cong_default rw newreno -- newreno newreno,cubic, highspeed,vegas# ipadm show-prop -p cong_enabled tcpPROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLEtcp cong_enabled rw newreno,cubic, newreno,cubic, newreno newreno,cubic, highspeed, highspeed, highspeed,vegas vegas vegasSCTP (Stream Control Transmission Protocol) :root@havana-mgt01:~# ipadm show-prop -p cong_default sctpPROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLEsctp cong_default rw newreno -- newreno newreno,cubic, highspeed,vegasroot@havana-mgt01:~# ipadm show-prop -p cong_enabled sctpPROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLEsctp cong_enabled rw newreno,cubic, newreno,cubic, newreno newreno,cubic, highspeed, highspeed, highspeed,vegas vegas vegas

Solaris の TCP 輻輳制御の実装 (Congestion Control) が、Solaris 10 から変更になっていました汗 Solaris 10 までは、RFC 2581 に準拠したアルゴリズムを採用し固定でしたが、Solaris 11 からは、このアルゴリズムの実装を Pluggable にし複数の実装を提供できる Pluggable TCP Congestion Control...

Solaris

Oracle Solaris 11.2 と Oracle Solaris Cluster 4.2 がリリース!

本日、日本時間 8/1 に Oracle Solaris 11.2 と Oracle Solaris 4.2 がリリースとなりました。アナウンスではないですよ。 Solaris 11.1 から .1 繰り上がっただけですが、すでに Open Beta 時からお知らせしているように、OpenStack (Open Beta は Grizzly でしたが、Havana ベースとなりました), Krenel Zones, Elastic Virtual Switch, Unified Archive など様々な新機能が盛り込まれています。そして、これらの新機能を使うために、アプリケーションの修正は必要ありません。 また、Oracle Solaris に高可用性と DR 機能を提供する Oracle Solaris Cluster 4.2 も合わせてリリースされました。Solaris Cluster 4.2 の HA Zone では新しい Kernel Zone をサポート。Solaris がサポートする仮想化機能に高可用性を付加します。更に、ブラウザベースの管理インターフェースを新たに提供。また、Solaris 11.2 の統合アーカイブ機能と連携することで、物理クラスタ環境や仮想クラスタ環境を迅速にデプロイ可能です。 Oracle Solaris 11.2 Oracle Solaris Cluster 4.2  ちなみに、さとかず & いとかづが作成している OpenStack on Solaris 環境を絵にしてみるとこうなります。奥が深い。初物なので色々と試行錯誤していますが、新機能との連携を理解できると中々楽しいです。

本日、日本時間 8/1 に Oracle Solaris 11.2 と Oracle Solaris 4.2 がリリースとなりました。アナウンスではないですよ。 Solaris 11.1 から .1 繰り上がっただけですが、すでに Open Beta 時からお知らせしているように、OpenStack (Open Beta は Grizzly でしたが、Havana ベースとなりました),...

Solaris

Solaris Zones で GDM (GNOME Display Manager) を動かす Xvnc 編

Xephyr よりVNC だろ?と言われ、言い返せなかったので Xvnc について書き加えて行きたいと思います。前回のエントリとなる「Solaris Zones で GDM (GNOME Display Manager) を動かす」ですが、この設定を完了後、Xvnc の SMF サービスを有効にするだけです。Xvnc も SMF サービスで管理されていますが、こちらは inetd にてコントロールされるサービスで、標準では disable となっています。Xvnc を有効にするには、下記のコマンドを実行します。 # svcadm enable xvnc-inetd# svcs -a | grep xvnconline 11:16:56 svc:/application/x11/xvnc-inetd:default (online になったことを確認します) サービスが開始されるので、後は VNC クライアントから接続するだけです。ちなみに、inetd でコントロールされるので、inetadm の出番です。  root@solaris:~#   inetadm -l xvnc-inetdSCOPE    NAME=VALUE         name="vnc-server"         endpoint_type="stream"         proto="tcp"         isrpc=FALSE         wait=FALSE         exec="/usr/bin/Xvnc -inetd -query localhost -once securitytypes=none"         user="noaccess"default  bind_addr=""default  bind_fail_max=-1default  bind_fail_interval=-1default  max_con_rate=-1default  max_copies=-1default  con_rate_offline=-1default  failrate_cnt=40default  failrate_interval=60default  inherit_env=TRUEdefault  tcp_trace=FALSEdefault  tcp_wrappers=FALSEdefault  connection_backlog=10default  tcp_keepalive=FALSE いえ、、、特になにかしたかったわけでもなく・・・接続にパスワードを用いたり、Xvnc のオプションを変更する場合は、exec プロパティを書き換えます。たとえば、デスクトップのデフォルトの大きさを 1280x800 に指定する(大抵の場合は、クライアントから操作できるが、できないクライアントもあります)には、下記のように実行します。inetd からキックされるサービスなので、特にリフレッシュも必要ありません。(svccfg でも変更できます) # inetadm -m xvnc-inetd exec="/usr/bin/Xvnc -inetd -query localhost -once securitytypes=none -geometry 1280x800" また、default では、VNC クライアントを終了させると同時にセッションも終了し、毎回ログインのしなおしとなります。クライアントとのコネクションが切れても、セッションを継続動作させるには、下記を追加で実行します。なんちゃって SunRay 環境っぽくなります。 # inetadm -m xvnc-inetd wait=true # inetadm -m xvnc-inetd exec="/usr/bin/Xvnc -inetd -query localhost -once securitytypes=none -geometry 1280x800 -DisconnectClients=no" Mac OS X 10.6.8 の画面共有アプリケーションにはクライアント機能があり、FInder に統合されているのですが、うまく接続することができず、TightVNC Java Viewer version 2.6.2 で。また、Solaris 11.1 の TigerVNC クライアント(/usr/bin/vncviewer) も問題なく接続できました。 このあたりの設定も、カスタマイズしはじめるとキリがありませんね。というわけで、Xephyr に続き VNCクライアントでの接続方法の紹介でした。 後日追加:使い方に注意点があるので、気がついたら追加してゆきます。 コピー & ペーストができないSolaris 側で、/usr/bin/vncconfig を実行してください。このプログラムが起動中は、コピー & ペースト可能です。正しく動作することを確認できたら、バックグラウンドで動作させておきます。 UltraVNC クライアントから接続すると、"The Server running as Application" と表示されてしまう。とりあえず、既存セッションへの接続の場合は、クライアント側で接続速度を低いものにしてみる Mac OS X 10.6.8 の画面共有クライアントから接続できなかったのは、Xvnc 側でパスワードを設定していないためでした。パスワーファイルを設定し認証を行うようにすることで問題なくアクセスできます。

Xephyr よりVNC だろ?と言われ、言い返せなかったので Xvnc について書き加えて行きたいと思います。前回のエントリとなる「Solaris Zones で GDM (GNOME Display Manager) を動かす」ですが、この設定を完了後、Xvnc の SMF サービスを有効にするだけです。 Xvnc も SMF サービスで管理されていますが、こちらは inetd にてコントロー...

Solaris

Solaris Zones で GDM (GNOME Display Manager) を動かす

今回は、Solaris 11.1 の非大域ゾーン(non-global zone)の中で、GDM を動かす。そして、Xephyr (Xnest などの XDMCP クライアント) から非大域ゾーンのデスクトップ環境を利用するというお話です。 なんで、今更こんなことを書くかというと、実は GDM は非大域ゾーンの中で動作させることができません。Solaris 10 では CDE のコンポーネントである dtlogin を非大域ゾーンで利用する方法が提供されていましたが、Solaris 11 からは dtlogin が提供されなくなりました。GDM も使えないため、非大域ゾーンにデスクトップ環境を構成し利用することが難しい状態となっています。 GDM を動かすことができない理由ですが、まず、GDM は Solaris が誇る予測的自己修復機能を構成する SMF で管理されるサービスとして提供されています。GDM の SMF サービスは svc:/application/graphical-login/gdm:default となりますが、この SMF サービスは、svc:/system/hal と svc:/system/consolekit, svc:/system/dbus に依存関係を持っており、この 3 つのサービスが正常に動作している必要があります。(他のサービスにも依存関係を持っていますが、今回のお話ではこの 3 つが重要)しかし、非大域ゾーンでは、次の理由により GDM は SMF サービスとして offline となります。 svc:/system/hal は、non-global zone でサービスとして提供されない(存在しない) svc:/system/dbus は、non-global zones では disable になるように設定されている svc:/system/consolekit は、dbus に依存している。dbus は動作していないので、consolekit も動作しない おぅ・・・思った以上にクリティカルです。 # svcs -l gdmfmri         svc:/application/graphical-login/gdm:defaultname         GNOME Display Managerenabled      truestate        offlinenext_state   nonestate_time   Sat Jan 19 22:27:28 2013restarter    svc:/system/svc/restarter:defaultmanifest     /lib/svc/manifest/application/graphical-login/gdm.xmlmanifest     /etc/svc/profile/generic.xmlmanifest     /lib/svc/manifest/application/opengl/ogl-select.xmlmanifest     /lib/svc/manifest/application/desktop-cache/gconf-cache.xmlmanifest     /lib/svc/manifest/application/desktop-cache/pixbuf-loaders-installer.xmlmanifest     /lib/svc/manifest/application/desktop-cache/icon-cache.xmlmanifest     /lib/svc/manifest/application/desktop-cache/desktop-mime-cache.xmlmanifest     /lib/svc/manifest/application/desktop-cache/input-method-cache.xmlmanifest     /lib/svc/manifest/application/desktop-cache/mime-types-cache.xmldependency   optional_all/none svc:/application/opengl/ogl-select (online)dependency   require_all/none svc:/system/filesystem/local (online)dependency   require_all/error svc:/milestone/multi-user:default (online)dependency   require_all/none svc:/milestone/self-assembly-complete (online)dependency   require_all/none svc:/application/font/fc-cache (online)dependency   require_all/none svc:/system/utmp (online)dependency   require_all/none svc:/system/hal ()dependency   require_all/none svc:/system/dbus (disabled)dependency   require_all/none svc:/system/consolekit (offline) dependency   optional_all/none svc:/application/desktop-cache/gconf-cache (online)dependency   optional_all/none svc:/application/desktop-cache/pixbuf-loaders-installer (online)dependency   optional_all/none svc:/application/desktop-cache/icon-cache (online)dependency   optional_all/none svc:/application/desktop-cache/desktop-mime-cache (online)dependency   optional_all/none svc:/application/desktop-cache/input-method-cache (online)dependency   optional_all/none svc:/application/desktop-cache/mime-types-cache (online) というわけで、何らかの意図があり、故意に動作させないようになっているような気がしないでもないです。。。ちなみに、依存関係については、svcs -l で確認できます。 ここからサポートされる手順ではなく利用者の自己責任となります。SMF のマニフェストを書き換えたりしますので、動作になんらかの影響を与える可能性がありますのでご注意ください。この点を理解していいただけるという前提で、動作させる手順をご紹介いたします。(サポートされる手順でもなんでもなく、欲望を満たせるなら手段は問わない手順となります) 1. 非大域ゾーンの作成について 非大域ゾーンの作成時点では、何か特別なことをする必要はありません。ここでは、非大域ゾーンを作成してたからデスクトップ環境をインストールする作業(パッケージのインストール)をゾーン作成時に行ってしまう方法をご紹介します。/usr/share/auto_install/manifest/zone_default.xml のコピーを作成し、下記のようにゾーンにインストールされるグループパッケージ(default は solaris-small-server)を solaris-desktop に書き換えます。  *** zone_default.xml2012-09-20 05:10:44.000000000 +0900--- /export/home/kazus/zone_default.xml2013-01-19 16:55:13.001233748 +0900****************** 67,73 ****                  </image>              </destination>              <software_data action="install">! <name>pkg:/group/system/solaris-small-server</name>              </software_data>          </software>      </ai_instance>--- 67,73 ----                  </image>              </destination>              <software_data action="install">! <name>pkg:/group/system/solaris-desktop</name>              </software_data>          </software>      </ai_instance> 書き換えた  zone_default.xml を下記のように zoneadm コマンドに渡すことで solaris-desktop グループパッケージをインストールした非大域ゾーンを作成することができます。下記は、修正した zone_default.xml を使い、ゾーンをインストールした実行例です。 # zoneadm -z gdm-test install -m `pwd`/zone_default.xmlThe following ZFS file system(s) have been created:    micropool/zones/gdm-test02Progress being logged to /var/log/zones/zoneadm.20130119T131318Z.gdm-test02.install       Image: Preparing at /micropool/zones/gdm-test02/root. AI Manifest: /tmp/manifest.xml.48aGch  SC Profile: /usr/share/auto_install/sc_profiles/enable_sci.xml    Zonename: gdm-test02Installation: Starting ...              Creating IPS imageStartup linked: 1/1 done              Installing packages from:                  solaris                      origin:  http://localhost:1008/solaris/32e0c0654802140a8e3b152a1a6bbabda1816a3a/              Please review the licenses for the following packages post-install:                runtime/java/jre-7                       (automatically accepted)              Package licenses may be viewed using the command:                pkg info --license <pkg_fmri>DOWNLOAD                                PKGS         FILES    XFER (MB)   SPEEDCompleted                            839/839 115085/115085    1051/1051  3.6M/sPHASE                                          ITEMSInstalling new actions                   168817/168817Updating package state database                 DoneUpdating image state                            DoneCreating fast lookup database                   DoneInstallation: Succeeded        Note: Man pages can be obtained by installing pkg:/system/manual done.        Done: Installation completed in 656.696 seconds.  Next Steps: Boot the zone, then log into the zone console (zlogin -C)              to complete the configuration process.Log saved in non-global zone as /micropool/zones/gdm-test02/root/var/log/zones/zoneadm.20130119T131318Z.gdm-test02.install solaris-desktop は、solaris-small-server より多くのパッケージが導入されるため、ディスク容量やインストール時間を必要とします。ゾーン作成後は、起動と初期設定などを済ませておきます。 2. svc:/system/dbus のメソッドファイルを修正 ここからの作業は、すべて非大域ゾーンでの作業となります。続いて、svc:/system/dbus をサービスとして動作するようにメソッドファイルとなる /lib/svc/method/svc-dbus を修正します。非大域ゾーンではサービスを disable にする処理をコメントに変更するのが修正内容となります。 *** /usr/tmp/svc-dbus.orig Sat Jan 19 17:48:22 2013--- /lib/svc/method/svc-dbus Sat Jan 19 17:49:02 2013****************** 20,31 ****        /usr/bin/dbus-uuidgen --ensure  fi! if smf_is_nonglobalzone; then! /usr/sbin/svcadm disable -t svc:/system/dbus! echo "dbus-daemon cannot be run in non-global zones"! sleep 5 &! exit $SMF_EXIT_OK! fi  case "$1" in  'start')--- 20,31 ----        /usr/bin/dbus-uuidgen --ensure  fi! #if smf_is_nonglobalzone; then! # /usr/sbin/svcadm disable -t svc:/system/dbus! # echo "dbus-daemon cannot be run in non-global zones"! # sleep 5 &! # exit $SMF_EXIT_OK! #fi  case "$1" in  'start')  3. /lib/svc/manifest/application/graphical-login/gdm.xml の修正 gdm のサービスとなる svc:/application/graphical-login/gdm:default を構成するマニフェストを修正します。修正箇所としては、svc:/system/hal と svc:/system/consolekit への依存関係を定義している部分となります。この定義をコメントとすることで、依存関係なんてはじめから無かったんだという状態にします。gdm のマニフェストは、/lib/svc/manifest/application/graphical-login/gdm.xml となり、このファイルのバックアップを取り直接書き換えます。 *** /usr/tmp/gdm.xml.orig       Sat Jan 19 17:40:35 2013--- /lib/svc/manifest/application/graphical-login/gdm.xml       Sat Jan 19 17:41:06 2013****************** 53,58 ****--- 53,59 ----                <service_fmri value='svc:/system/utmp'/>        </dependency>+ <!--        <dependency            name='hal'            grouping='require_all'****************** 60,65 ****--- 61,67 ----            type='service'>                <service_fmri value='svc:/system/hal' />        </dependency>+ -->          <dependency              name='dbus'****************** 69,74 ****--- 71,77 ----                  <service_fmri value='svc:/system/dbus' />          </dependency>+ <!--        <dependency            name='consolekit'            grouping='require_all'****************** 76,81 ****--- 79,85 ----            type='service'>                <service_fmri value='svc:/system/consolekit'/>        </dependency>+ -->        <exec_method            type='method' 4. /etc/gdm/custome.conf の [xdmc] セクションに下記を追加 GDM への XDMCP 接続を許可する設定となります。/etc/gdm/custom.conf の [xdmcp] セクションに、Enable=true を追加します [xdmcp]Enable=true 5. 非大域ゾーンのリブートと Xephyr からの接続 非大域ゾーンをリブートすることで、修正したマニフェストやメソッドが反映され GDM に接続可能になります。Xephyr からの接続は、下記のようにリモートホストから実行することで可能です。  # /usr/bin/Xephyr :1 -query 192.168.100.24 -screen 1280x800 6. その他 Mac OS X 10.6.8 (Snow Leopard) の Xephyr から接続した際、GDM からのログイン時は特におかしなところはないのですが、ログイン後のキーマップが崩壊している現象に遭遇しました。利用したのは、XQuartz 2.7.4 です。同様の現象が発生する場合は、現象が発生するアカウントにてssh などを使い非大域ゾーンにログインし、下記コマンドを実行してから Xephyr から再ログインしてください。 $ /usr/bin/gconftool-2 -s /apps/gnome_settings_daemon/plugins/keyboard/active --type boole false Solaris 11.1 の Xephyr では、この設定は必要ありませんでした。お楽しみください。では、Oracle Database 11g R2 を Solaris Zones へインストールする作業に戻ります。

今回は、Solaris 11.1 の非大域ゾーン(non-global zone)の中で、GDM を動かす。そして、Xephyr (Xnest などの XDMCP クライアント) から非大域ゾーンのデスクトップ環境を利用するというお話です。 なんで、今更こんなことを書くかというと、実は GDM は非大域ゾーンの中で動作させることができません。Solaris 10 では CDE...

Solaris

Oracle Solaris 11.1 日本語マニュアルが公開!と小ネタ

Solaris 11.1 ファンの皆様!お待たせいたしまた。Oracle Solaris 11.1 の日本語マニュアルが公開されました。Solaris 11 11/11 から 11.1 といっても、新しい機能等もたくさん追加されていますので、ぜひ参考にして頂きたく。Oracle Solaris 11.1 Information Library (日本語) Released: 2012-11-15 http://docs.oracle.com/cd/E37932_01/また、少しだけうけた Solaris 11.1 の小ネタをご紹介します。 ipadm コマンドと dladm コマンドをオプションなしで実行するとヘルプが出力されなくなった!dladm コマンドと ipadm コマンド実行時に、デフォルトの動作モードが割り当てられました。dladm では、オプションなしで実行すると dladm show-link と同じ結果が。ipadm では、show-if と show-addr を組み合わせたわかりやすい出力結果を得ることができます。 /usr/bin/ps コマンドが /usr/ucb/ps スタイルのオプションが実装/usr/bin/ps コマンドに - (ハイフン) なしでオプションを渡すと、/usr/ucb/ps の動作をエミュレートした出力となります。特に将来のリリースにおいて、/usr/ucb/ps 含む UCB 互換パッケージの廃止がアナウンスされていますので、これを機会に /usr/ucb/ps を使っているスクリプトなどを洗い出し、/usr/bin/ps の USB 互換モードで対応可能か精査しておくと良いかと思います。 End of Features (EOF) Planned for Future Releases of Oracle Solarishttp://www.oracle.com/technetwork/systems/end-of-notices/eonsolaris11-392732.htmlお試しアレ。

Solaris 11.1 ファンの皆様!お待たせいたしまた。 Oracle Solaris 11.1 の日本語マニュアルが公開されました。 Solaris 11 11/11 から 11.1 といっても、新しい機能等もたくさん追加されていますので、ぜひ参考にして頂きたく。Oracle Solaris 11.1 Information Library (日本語) Released:...

Goods

Oracle Solaris 11.1 日本語ページとダウンロードページ公開!

Oracle Solaris 11.1 リリース時には、OTN Japan Blog に負けてしまいましたが、本日、Oracle Solaris 11.1 の日本語ページとダウンロードページが配備されましたので、お知らせいたします。Oracle Solaris 11http://www.oracle.com/technetwork/jp/server-storage/solaris11/overview/index.htmlOracle Solaris 11 ダウンロードhttp://www.oracle.com/technetwork/jp/server-storage/solaris11/downloads/index.htmlただ、日本語ページが公開されたわけではありません。この流れで、日本語版の Waht's New も公開です!Oracle Solaris 11.1の新機能http://www.oracle.com/technetwork/server-storage/solaris11/documentation/solaris-11-1-whats-new-jap-1866363.pdfまずは、こちらのドキュメントから新機能を拾いつつ、Oracle Solaris 11.1 Information Library Released: 2012-10-25 のマニュアルを。ちなみに、google せんせーに聞くときには、site:docs.oracle.com/cd/E26502_01/ を入れてから keyword を入れると捗ります。こちらの blog でも情報を小出しにしていきます!ちなみに、直近ではこのような記事もありますので、併せて読みあさってみてくださいね。What's new in Solaris 11.1?High Resolution Timeouts Solaris 11 の Zone にインストールされるパッケージ (Solaris 11.1 でも同様の手順です)ちなみにリンク先の内容は、時間をかけて日本語化して行きますのでお待ちください!

Oracle Solaris 11.1 リリース時には、OTN Japan Blog に負けてしまいましたが、本日、Oracle Solaris 11.1 の日本語ページとダウンロードページが配備されましたので、お知らせいたします。Oracle Solaris 11http://www.oracle.com/technetwork/jp/server-storage/solaris11/overvi...

Solaris

Oracle Solaris 11.1 がリリースされました

Oracle OpenWorld 2012 にてアナウンスされた Oracle Solaris 11.1 が、無事リリースされました。Oracle Solaris 11.1 では、エンタープライズアプリケーションにおける No.1 UNIX 環境はもちろん、クラウド基盤の構築、オラクルが提供する様々なソフトウェアに最適な環境というメッセージはそのままに、更なる機能強化がなされています。ダウンロード等については、下記 OTN Blog を参照ください。 祝!Solaris 誕生20周年。 そして、Solaris 11.1がついに出ました! また、ドキュメントも機能毎に細分化されていますが、ついにパッケージリストが纏められたドキュメントも追加されています。こちらのドキュメントは、グループパッケージである group/system/solaris-large-server, group/system/solaris-small-server, group/system/solaris-desktop にどのようなパッケージが含まれるかを纏めたものとなりますのでご活用ください。Oracle Solaris 11.1 Package Listhttp://docs.oracle.com/cd/E26502_01/html/E36136/index.htmlまた、ご利用前には必ず下記のリリースノートの一読をお願いいたします。重要な情報が満載です。Oracle Solaris 11.1 Release Noteshttp://docs.oracle.com/cd/E26502_01/html/E28978/index.html現時点では、英語版のみの提供となります。日本語版につきましては、準備中となりますのでもうしばらくおまちください。。。では、みなさま、お楽しみください

Oracle OpenWorld 2012 にてアナウンスされた Oracle Solaris 11.1 が、無事リリースされました。 Oracle Solaris 11.1 では、エンタープライズアプリケーションにおける No.1 UNIX 環境はもちろん、クラウド基盤の構築、オラクルが提供する様々なソフトウェアに最適な環境というメッセージはそのままに、更なる機能強化がなされています。ダウンロード...

Solaris

Oracle Solaris ナイトセミナー #6 開催します!

8 月はお休みを頂いてしまいましたが。。。お待たせしました、Oracle Solaris ナイトセミナー第 6 回目の告知です!今回は、サービスの実行を超えた新しいサービス管理アーキテクチャ「Service Management Facility (SMF)」特集です。SMF は、Solaris 10 から提供されている特徴的な機能である「予測的セルフヒーリング技術」の一機能となり、Solaris 上で動作している様々なソフトウェアサービスを管理する機能です。今回は、この SMF の概要や Solaris 11 で更新された機能などを紹介致します!そして、好評の Solaris 3 分クッキングでは、Solaris 11 におけるネットワーク設定に関する特集となります。Solaris 11 では、ネットワーク設定についても大きく変更されていますが、基本のコマンドとなる ipadm, dladm, netadm コマンドを取り上げてみます。お待ちしております。勉強会としてゆる~くやっていますので、Solaris 初心者の方や単なる情報収集でも、お気軽にご参加ください!参加登録はこちらからっ! Oracle Solaris ナイトセミナー #6 参加登録 開催日時: 9/26 水 18:30 〜http://atnd.org/event/solarisns6みなさま、お待ちしています!来月は・・・ふふふ・・・--過去のセミナー資料は、slideshare.net/SolarisJPNight にて公開中です。日中に行われている Solaris ディープダイブの資料はこちら slideshare.net/SolarisJP

8 月はお休みを頂いてしまいましたが。。。お待たせしました、Oracle Solaris ナイトセミナー第 6 回目の告知です! 今回は、サービスの実行を超えた新しいサービス管理アーキテクチャ「Service Management Facility (SMF)」特集です。SMF は、Solaris 10...

Storage

Sun ZFS Appliance Monitor登場

システム運用管理にも、スマートフォンやタブレットの時代が到来!?去る2012年8月1日に、Sun ZFS Storage Appliance(以下、ZFSSA)の管理を目的としたiOS向けのアプリ、『Sun ZFS Appliance Monitor』(以下、ZMA)がリリースされました。iTunesに紹介がありますので、こちら参考にしてみてください。http://itunes.apple.com/jp/app/sun-zfs-appliance-monitor/id546494906ZMAは、どこでも手軽にZFSSAの状況を確認出来ることを目指して開発されました。アプリ上に複数台のZFSSAを登録することが可能で、専用のBUIで表示可能な画面を、簡単にiPhone等で確認出来ます。但しこのアプリは主に確認での用途を想定していて、このアプリを通してZFSSAの設定を変更することは出来ません。揺れる通勤中でタッチパネルに意図せず触れてしまい、本番環境の構成が変わってしまった!なんてことは起こらないので、安心して利用出来ます。尚、このアプリは無料です。ここではZFSSAシミューレーターを使って、iPhoneへインストールしてアプリの画面を見ていきたいと思います。【事前準備】①アプリの入手iPhone等でアプリを入手するには、App Storeで『zfs』の3文字で検索すれば一番上に出てくるはずです。アプリのインストール方法はiOS共通でタッチするだけです。②ZFSSAシミュレーターを準備シミュレーターの準備に関しては、過去に実施しましたオラクル・ダイレクトセミナーのセミナー資料が、現在はOTNセミナー オンデマンド コンテンツとして掲載されております。一部内容に古さが見られますが、セットアップの手順については基本同じですので参考にしてください。http://www.oracle.com/technetwork/jp/ondemand/hardware/storage/ord-s7000-1-20101109-302076-ja.pdf③シミュレーターセットアップZMAでは確認がメインになりますので、ZFSSAのBUIを通して以下の項目をあらかじめ設定しておきます。・Poolを作成・Shareを作成・いくつかの項目を選択してAnalyticsのワークシートをセーブ【画面イメージ】それでは、いくつかの画面を見ていきたいと思います。アプリを初めて起動すると、以下の様な画面が表示されて、管理するZFSSAの登録を促されます。左上の「Edit」をタッチし、新しく管理対象となるZFSSAの情報を入力します。「Hostname」はアプリ上の管理用としての名前を設定します。アプリ上の管理用途ですので、ZFSSA本体に設定をしたホスト名とは異なった名前にすることが出来ます。その他、接続情報としてIPアドレスやユーザー名、パスワード等を入力し、「Save」をタッチします。設定が完了し、ZFSSAへの接続が確立されると、システム全体のサマリーが表示されます。無事に登録が完了したら、いよいよ各項目を見ていきます。最初に「Status」の項目が表示されます。これはBUIでログインした時と同じですね。BUIの場合、「Status」ではグラフと共に画面が表示されますが、ZMAでは画面の大きさの都合もあり、グラフは「Dashboard Graphs」をタッチして画面を遷移させます。グラフは次の様な画面です。さすがに限られたスペースでは1画面に表示出来る項目は少なくなりますが、画面を下にスライドして見ることが出来ます。画面スライドは、さすがのiPhone(iOS)と言った感じで、非常にスムーズでストレスは感じられません。よく見ると、画面下部に各項目のタブがあります。次に「Hardware」を見てみましょう。「Hardware」タブをタッチすると、次の様な画面が表示されます。Virtual Boxを使ったシミュレーターなので、いくつかの項目が本物のZFSSAとは異なるのですが、モデルやディスクの情報などが見られます。ZMAが発表されてすぐに、一時的に社内検証機の7120を登録したことがあり、その際の画面コピーがこちらです。こちらでは本体のイメージ画像が表示され、またCPUやメモリ、ディスクの情報などが正しく表示されます。画面を進めると各コンポーネント毎の状態を見ることが出来ますので、リモートから簡単に問題が発生している部位を見ることが出来ます。さて、ZFSSAを管理する際に非常に強力なツールが「Analytics」です。ZMAでも、すでに登録がされている「Analytics」の画面を呼び出して表示することが可能です。こちらがその画面です。更新の頻度がBUIとは異なりますが、ここでも見え方は同じで、複数の項目を登録している場合には、画面スクロールで見るこ�����が出来ます。以上、アプリでの画面イメージは伝わりましたでしょうか。すでにご利用のZFSSAがあればそちらで、まずは試してみたいと言う方はシミュレーターで。一度お試しください。

システム運用管理にも、スマートフォンやタブレットの時代が到来!? 去る2012年8月1日に、Sun ZFS Storage Appliance(以下、ZFSSA)の管理を目的としたiOS向けのアプリ、『Sun ZFS Appliance Monitor』(以下、ZMA)がリリースされました。 iTunesに紹介がありますので、こちら参考にしてみてください。http://itunes.apple.co...

Solaris

Oracle Solaris ナイトセミナー #5 開催します!

毎回多くの方にご参加頂いている、Oracle Solaris ナイトセミナー第 5 回目の告知です!ちなみに、当 blog での 3 ,4 回目の告知は都合によりお休みしていました!#後に、エントリの残骸を発見され緊急ミーティングが開催されたことは秘密です。ゴホンゴホン。今回は、題して「夏の Solaris Zones 祭り! その 1 」!!!最近は、"移行をするなら、まずは Solaris Zones から!" と、Solaris Zones をオススメしているわけですが、不安な部分もあると思います。 ・移行に使える Solaris Zones って何? どんなもの? ・移行できる環境ってどんなもの?移行先の環境ってどんなもの? ・どうやって移行すればいいの? ・移行できないものってあるの? ・移行したあとの運用では何を気をつければいいの?など、Solaris Zones で安心して生活するためのポイントを色々とご紹介致します。題材としては、Solaris 8, Solaris 9 を Zones として最新のハードウェア環境にて動作させる Solaris Legacy Containers、実機で動作する Solaris 10 環境を最新の Solaris 10 や Solaris 11 へ移行する方法や、Zones から Zones の移行支援ツール zonesp2vchk、移行後の Zones の運用ポイントなどをご紹介!そして、好評の Solaris 3 分クッキングでは、Solaris 11 ならではの機能 " AI インストール(自動インストール機能)" を使った Solaris Zones の作成方法を解説!Zones って、構成定義して自動インストールじゃないの?と思った、そこの Solaris 11 使いの方!自分好みの Solaris Zones が作れると聞くとワクワクしませんか?!お待ちしております。勉強会としてゆる~くやっていますので、Solaris 初心者の方や単なる情報収集でも、お気軽にご参加ください!Oracle Solaris ナイトセミナー #5 http://atnd.org/event/solarisns5お待ちしています!--過去のセミナー資料は、slideshare.net/SolarisJPNight にて公開中です。日中に行われている Solaris ディープダイブの資料はこちら slideshare.net/SolarisJP

毎回多くの方にご参加頂いている、Oracle Solaris ナイトセミナー第 5 回目の告知です! ちなみに、当 blog での 3 ,4 回目の告知は都合によりお休みしていました! #後に、エントリの残骸を発見され緊急ミーティングが開催されたことは秘密です。 ゴホンゴホン。 今回は、題して「夏の Solaris Zones 祭り! その 1 」!!!最近は、"移行をするなら、まずは...

Sun

Oracle VM Server for SPARC (旧称 LDoms) 2.2 リリース!

SPARC T シリーズサーバーで利用できるファームウェアベースのハイパーバイザー型仮想化ソフトウェアである Oracle VM Server for SPARC の最新バージョン 2.2 がリリースされました! OVM for SPARC 2.2 は前バージョン同様に、UltraSPARC T2, T2+, SPARC T3, SPARC T4 プロセッサが搭載される SPARC T シリーズサーバーにて利用可能です!OVM for SPARC 2.2 は 2012 年 5 月 24 日にリリースが発表されたのですが、このときには Oracle Solaris 10 版のみが実際に利用可能でした。 Oracle Solaris 11 版は、SRU8.5 に含まれてリリースされることになったため、その利用は 6 月 22 日の SRU8.5 のリリースを待たなければいけませんでした。 ついに Solaris 10, Solaris 11 とも OVM for SPARC 2.2 が利用可能となりましたので、その新機能を (OTN のウェブサイト(英語)やマニュアル (Release Note)にも紹介がありますが) 本 Blog にて簡単に紹介したいと思います。 SR-IOV サポート 1つの物理 I/O インタフェースを仮想的に複数のゲストドメインへ割当てることが可能です。OVM for SPARC 2.2 の場合、まずはネットワークインタフェースで利用可能になります。同じことは、OVM for SPARC のもつ、vsw と vnet で構成する仮想ネットワークでも可能ですが、SR-IOV を使うことで、CPU やハイパーバイザソフトウェアのオーバーヘッドなしで I/O を実行できるところが魅力となります。 現時点では制御ドメインとして Solaris 11 が必要、サポートされる NIC としては SPARC T3/T4 サーバーラインナップのオンボードネットワークポートおよび 10Gb Ethernet カード ((X)1109A-Z, (X)1110A-Z, (X)4871A-Z)) となります。 異なる CPU を搭載するシステム間でのライブマイグレーションのサポート Oracle VM Server for SPARC 2.1 でライブマイグレーションがサポートされましたが、このときは同じ種類かつ同じ周波数の CPU を搭載するシステムでのみサポートという制限事項がありました。今回 OVM for SPARC 2.2 では、この制限を取り除く機構が実装されました。ドメインに対して cpu-arch プロパティが用意され、generic に設定したときにゲストドメインが CPU タイプに依存しないマイグレーションを実行できるようになります。 Solaris 11 がゲストドメインとして構成されている場合にこの機能がサポートされます。 仮想ネットワークの Rx Dring モードのサポート ドメインのプロパティとして extended-mapin-space を on にすると、さらなる LDC 共有メモリスペースを使用することで、仮想ネットワークのパフォーマンスとスケーラビリティを向上させます。 こちらは Solaris 10 8/11 (Update 10) および Solaris 11 で利用可能です。以下は、前バージョンの OVM for SPARC 2.1 でもパッチや SRU を適用することで可能なものでしたが、OVM for SPARC 2.2 のリリースのタイミングで改めて紹介されています。 名前付き CPU コアおよびメモリーブロックの割当 この機能により管理者が明示的にこのコアをゲストドメインに割当てる、ということや、この物理メモリアドレスからどれだけのサイズをゲストドメインに割当てる、ということが可能になりました。これは上級者向けの機能ということになります。 この機能は Solaris 11 SRU4 の OVM for SPARC 2.1 から追加された機能です。 この機能は制御ドメインが Solaris 11 の場合にのみ利用可能です。 CPU threading モード UltraSPARC T2 以降の CPU は、コアあたり 8 CPU thread が動作しますが、ドメインに対する CPU threading モードを max-ipc に設定することで コアあたり 1 thread でのみ動作するようにすることができます。これは基本的に SPARC T4 CPU 向けに使用する機能として実装されました。 この機能は Solaris 10 の OVM for SPARC 2.1 に対して Patch ID 147507-01 以降のパッチを適用することでサポートされた機能です。Solaris 11 の場合には SRU4 以降の OVM for SPARC 2.1 からサポートということになっています。最後に、OVM for SPARC は 昨年(2011年) 12 月に Oracle ソフトウェアのライセンスにおいて Hard Partitioning ライセンスとしてみなされ、その場合の構成方法がホワイトペーパーとしてリリースされましたが、OVM for SPARC 2.2 では、CPU のコア全体の割当を ldm set-core/add-core でできるようになっているため、それをベースにマニュアル (管理ガイド) 内に記載され、これも改めてこのリリースの最新情報としてリストされています。

SPARC T シリーズサーバーで利用できるファームウェアベースのハイパーバイザー型仮想化ソフトウェアである Oracle VM Server for SPARC の最新バージョン 2.2 がリリースされました! OVM for SPARC 2.2 は前バージョン同様に、UltraSPARC T2, T2+, SPARC T3, SPARC T4 プロセッサが搭載される SPARC T...

Solaris

Solaris で Active Directory のドメインに参加 してみる

Solaris11 ではそれまでのリリースに比べて、Active Directory のドメインへの参加が簡単になりました。今回はその簡単になった方法を紹介していきたいと思います。とりあえず、Active Directory のドメインコントローラとなるサーバーは起動しているとします。設定するにあたり、Solaris11 のマニュアルの以下のパートが参考になります。How to Configure the SMB Server in Domain Mode手動モード時のネットワーク構成の管理後者のマニュアルには、DNS の設定や nsswitch.conf の設定が記載されています。下記は /etc/resolv.conf と nsswitch.conf を書き換える例です。Solaris 10 までは直接編集したりしてたのですが、Solaris 11 ではこの方法で設定していきます。また、以下では nsswitch.conf の passwd エントリを記載する際、設定では password としないと通らない点に注意してください。# svccfgsvc:> select dns/clientsvc:/network/dns/client> setprop config/search = astring: vbox.oracle.comsvc:/network/dns/client> setprop config/nameserver = net_address: 192.168.56.200svc:/network/dns/client> select dns/client:defaultsvc:/network/dns/client:default> refreshsvc:/network/dns/client:default> validatesvc:/network/dns/client:default> select name-service/switchsvc:/system/name-service/switch> setprop config/password = astring: "files ad"svc:/system/name-service/switch> setprop config/group = astring: "files ad"svc:/system/name-service/switch> select system/name-service/switch:defaultsvc:/system/name-service/switch:default> refreshsvc:/system/name-service/switch:default> validatesvc:/system/name-service/switch:default> 次に smbadm で実際に Active Directory に参加していきます。冒頭に書いた通り、Solaris 11 からは smbadm join だけで /etc/krb5/krb5.conf ファイルの編集は不要になって簡単になりました。マニュアルに書いてあるとおりに進めていくなかで、下記のように smb server のサービスを起動するステップがあります。環境によっては、smb/server のサービスがインストールされていない場合はありますので、確認してインストールされていない場合にはインストールしてから進めていく必要があります。2. Enable the SMB service.# svcadm enable -r smb/serverこれで問題なくサービスが起動するのを確認したら、# smbadm join -u Administrator vbox.oracle.comAfter joining vbox.oracle.com the smb service will be restarted automatically.Would you like to continue? [no]: yEnter domain password: xxxxxJoining 'vbox.oracle.com' ... this may take a minute ...Successfully joined domain 'vbox.oracle.com'という流れでドメインに参加することができます。

Solaris11 ではそれまでのリリースに比べて、Active Directory のドメインへの参加が簡単に なりました。今回はその簡単になった方法を紹介していきたいと思います。 とりあえず、Active Directory のドメインコントローラとなるサーバーは起動しているとします。 設定するにあたり、Solaris11 のマニュアルの以下のパートが参考になります。How to...

Storage

ZFS Storage Appliance を ldap に連携させる

ZFS Storage Appliance を Openldap と連携してみます。まず、ldap サーバーを用意します。今回は Solaris 11 の Openldap を前提に設定していきます。下記の slapd.conf と、ldif ファイルにあるように user01 を作成します。 今回利用した slapd.conf## See slapd.conf(5) for details on configuration options.# This file should NOT be world readable.#include /etc/openldap/schema/core.schemainclude /etc/openldap/schema/cosine.schemainclude /etc/openldap/schema/nis.schema# Define global ACLs to disable default read access.# Do not enable referrals until AFTER you have a working directory# service AND an understanding of referrals.#referral ldap://root.openldap.orgpidfile /var/openldap/run/slapd.pidargsfile /var/openldap/run/slapd.args# Load dynamic backend modules: modulepath /usr/lib/openldap moduleload back_bdb.la# moduleload back_hdb.la# moduleload back_ldap.la# Sample security restrictions# Require integrity protection (prevent hijacking)# Require 112-bit (3DES or better) encryption for updates# Require 63-bit encryption for simple bind# security ssf=1 update_ssf=112 simple_bind=64# Sample access control policy:# Root DSE: allow anyone to read it# Subschema (sub)entry DSE: allow anyone to read it# Other DSEs:# Allow self write access# Allow authenticated users read access# Allow anonymous users to authenticate# Directives needed to implement policy:# access to dn.base="" by * read# access to dn.base="cn=Subschema" by * read# access to *# by self write# by users read# by anonymous auth## if no access controls are present, the default policy# allows anyone and everyone to read anything but restricts# updates to rootdn. (e.g., "access to * by * read")## rootdn can always read and write EVERYTHING!######################################################################## BDB database definitions#######################################################################database bdbsuffix "dc=oracle,dc=com"rootdn "cn=Manager,dc=oracle,dc=com"# Cleartext passwords, especially for the rootdn, should# be avoid. See slappasswd(8) and slapd.conf(5) for details.# Use of strong authentication encouraged.rootpw secret# The database directory MUST exist prior to running slapd AND# should only be accessible by the slapd and slap tools.# Mode 700 recommended.directory /var/openldap/openldap-data# Indices to maintainindex objectClass eq ユーザ等を設定するldifファイルdn: dc=oracle,dc=comobjectClass: dcObjectobjectClass: organizationdc: oracleo: oracledn: cn=Manager,dc=oracle,dc=comobjectClass: organizationalRolecn: Managerdn: ou=People,dc=oracle,dc=comobjectClass: organizationalUnitou: Peopledn: ou=Group,dc=oracle,dc=comobjectClass: organizationalUnitou: Group dn: uid=user01,ou=People,dc=oracle,dc=comuid: user01objectClass: topobjectClass: accountobjectClass: posixAccountobjectClass: shadowAccountcn: user01uidNumber: 10001gidNumber: 10000homeDirectory: /home/user01userPassword: secretloginShell: /bin/bashshadowLastChange: 10000shadowMin: 0shadowMax: 99999shadowWarning: 14shadowInactive: 99999shadowExpire: -1ldapサーバーの準備ができたら、ZFS Storage Appliance側の設定です。Configuration > SERVICES > LDAP で、Base search DN とldapサーバーを登録します。こちらは ldap サーバーに登録した user01 用のシェアを作成したところです。認証ができないユーザーを user の欄に記載しても、 Unknown or invalid user という警告とともに設定が失敗します。次にクライアントの設定をします。Solaris 11 の例を簡単に紹介します。サービスの起動と、参照する ldap サーバの登録後、getent コマンドで確認という流れです。# svcadm enable svc:/network/nis/domain:default# svcadm enable ldap/client# ldapclient manual -a authenticationMethod=none -a defaultSearchBase=dc=oracle,dc=com -a defaultServerList=192.168.56.201System successfully configured# getent passwd user01user01:x:10001:10000::/home/user01:/bin/bashあとはマウントして user01 で書き込みのテストをします。# mount -F nfs -o vers=3 192.168.56.101:/export/user01 /mnt# su user01bash-4.1$ cd /mntbash-4.1$ touch aaabash-4.1$ ls -ltotal 1-rw-r--r-- 1 user01 10000 0 May 31 04:32 aaa以上、簡単に ldap サーバーとの連携とクライアントからの接続ができました!

ZFS Storage Appliance を Openldap と連携してみます。 まず、ldap サーバーを用意します。今回は Solaris 11 の Openldap を前提に設定していきます。 下記の slapd.conf と、ldif ファイルにあるように user01 を作成します。 今回利用した slapd.conf ## See slapd.conf(5) for...

Solaris

Solaris11 で Openldap

Solaris11 に入っている openldap を使うための手順を簡単に紹介します。とりあえず、何もしないで起動してみます。#svcs svc:/network/ldap/server:openldap_24STATE STIME FMRIdisabled 10:23:35 svc:/network/ldap/server:openldap_24#svcadm -v enable svc:/network/ldap/server:openldap_24svc:/network/ldap/server:openldap_24 enabled.#svcs svc:/network/ldap/server:openldap_24STATE STIME FMRImaintenance 2:06:57 svc:/network/ldap/server:openldap_24と失敗していますので、ログをチェックします。#cat /var/svc/log/network-ldap-server:openldap_24.log[ May 28 02:06:57 Enabled. ][ May 28 02:06:57 Executing start method ("/lib/svc/method/ldap-olslapd start"). ]/lib/svc/method/ldap-olslapd[30]: exec: /usr/lib/slapd: cannot execute [Permission denied][ May 28 02:06:57 Method "start" exited with status 126. ]slapd の実行パーミッションがないというエラーです。実際見てみると、確かに実行できません。#ls -l /usr/lib/slapd-r--r--r-- 1 root bin 2555316 Oct 20 2011 /usr/lib/slapdパーミッションを変更して、サービスを起動しなおしますがまた起動失敗となります。#svcs svc:/network/ldap/server:openldap_24STATE STIME FMRImaintenance 2:11:06 svc:/network/ldap/server:openldap_24#cat /var/svc/log/network-ldap-server:openldap_24.log [ May 28 02:10:55 Leaving maintenance because disable requested. ][ May 28 02:10:55 Disabled. ][ May 28 02:11:05 Enabled. ][ May 28 02:11:05 Executing start method ("/lib/svc/method/ldap-olslapd start"). ][ May 28 02:11:06 Method "start" exited with status 1. ]これだけだと分かりにくいのですが、status 1 ということで起動できていません。そこで /lib/svc/method/ldap-olsapd と/etc/openldap/slapd.conf の下の方をみてみると、、(下は一部抜粋です)[ldap-olsapd] :typeset -r LDAPUSR=openldaptypeset -r LDAPGRP=openldap :typeset -r SLAPD="/usr/lib/slapd -u ${LDAPUSR} -g {LDAPGRP} -f ${CONF_FILE}" : [slapd.conf] :# The database directory MUST exist prior to running slapd AND# should only be accessible by the slapd and slap tools.# Mode 700 recommended.directory /var/openldap/openldap-data :とあり、database directory の /var/openldap/openldap-data にユーザーopenldap、グループopenldapで書き込みできるようになっている必要があります。ここを見てみると、ls -la /var/openldap total 14drwxr-xr-x 4 root bin 4 Oct 20 2011 .drwxr-xr-x 42 root sys 43 Nov 3 2011 ..drwxr-xr-x 2 root bin 3 Nov 3 2011 openldap-datadrwxr-xr-x 2 root bin 2 Oct 20 2011 runこのようにディレクトリが openldap ユーザで書き込みできないようになっています。このディレクトリの Owner/Group を変更して再度サービスを起動します。# chown -R openldap:openldap openldap# svcs svc:/network/ldap/server:openldap_24STATE STIME FMRIonline 4:56:54 svc:/network/ldap/server:openldap_24以上、無事起動することができました!

Solaris11 に入っている openldap を使うための手順を簡単に紹介します。 とりあえず、何もしないで起動してみます。 #svcs svc:/network/ldap/server:openldap_24STATE STIME FMRIdisabled 10:23:35 svc:/network/ldap/server:openldap_24#sv...

Storage

Sun ZFS Storage Appliance 2011.1.3 ファームウェア

先日、Sun ZFS Storage Appliance / Backup Appliance 用のファームウェアのマイナーアップデートがリリースされました。Release Note などはこちらにあります。 Software Updates マイナーアップデートなので、機能的な拡張はそれほどはいっていませんが、いくつか紹介したいと思います。 Analytics のデータ保持期間設定 Analytics のデータは Boot Disk に記録されていきますが、多数の監視点を長年撮り続けると、かなり膨大なデータ量になり閲覧も大変で、容量も圧迫してしまいます。今回のアップデートで、データの粒度(秒単位、分単位、時間単位のデータ)ごとにどれくらいの期間保存するかを設定できるようになりました。 Analytics のデータセットの部分消去 また、データセットごと(例えば、CPUの使用率や、DiskのIOPSなど)の単位で古いデータを一部削除といったこともできるようになりました。いままでは、全部消去か残しておくかだけでしたので、非常に多くの監視点を設定していても過去のデータによるディスク消費をコントロールできるようになり、より監視・管理がしやすくなっています。 Exadata Backup について Online Help に追加Application Integration の項目に Exadata Backup の際の設定等が追加されました。

先日、Sun ZFS Storage Appliance / Backup Appliance 用のファームウェアのマイナーアップデートがリリースされました。Release Note などはこちらにあります。Software Updates マイナーアップデートなので、機能的な拡張はそれほどはいっていませんが、いくつか紹介したいと思います。 Analytics のデータ保持期間設定 Analytics...

Goods

満を持して登場!! Intel Xeon E5-2600搭載 Sun x86 M3 サーバー

 既にアナウンスされて一月経過している訳ですが、、、さる 2012年4月10日に Intel Xeon processor E5-2600搭載 「Sun x86」 M3 サーバーがアナウンスされました。 そして、昨日の2012年5月16日に「Sun x86」 M3 サーバー製品群の国内提供が開始されました!!。 今回、Oracleから出荷が開始された新型「Sun x86」サーバー群は Intel の Romley プラットフォームアーキテクチャですので、他社がリリースしている E5-2600 プラットフォームと同じだろう?!っていうかどこも x86 サーバーについては基本 HW は同じ?っと思われる方が多いと思います。 しかーし、今回出荷開始された「Sun x86」 M3 サーバーの中でも Sun Fire X4170 M3/Sun Fire X4270 M3 はちょっと違います。 それは、Oracle のエンジニアリングが LVDIMM(メモリ) で Intel の POR (Plan-of-Record) に比べてより低い消費電力で高いパフォーマンス (DDR3-1600)* を提供することを可能にした点です。 < *メモリのスピードは Processor の型番とメモリのランクに依存します > この Oracle 独自のエンハンスメントによって、他社よりも高いアプリケーションパフォーマンスと省電力性が提供できることをサーバーアーキテクチャの点で可能にしています。当然のことながら、オラクルのデータベース、ミドルウェア、業務アプリケーションに最適化することにより、高い性能と信頼性を提供します。 また、通信事業者向け機器の仕様規定で最高レベルの「NEBS Level 3」の認定を受ける、電源安定性、電磁波放射、耐震性など安定運用に関わる高い水準を満たす Netra シリーズもありますので、選択肢はさらに広がります。 そういった点で x86 サーバーのコストパフォーマンスや通信事業者様向け環境仕様にご興味がある方は是非、Oracle の 「Sun x86」 M3 サーバーをご検討いただきたいと思います。 当然、Bladeタイプもありますのでこちらもよろしくです。 M3 製品群を代表して Sun Fire X4170 M3/Sun Fire X4270 M3 の基本仕様を記載しておきます。< Sun Fire X4170 M3 サーバー : 3タイプ > Sun Fire X4170 M3 サーバー 基本仕様 Computing 2 x Intel® Xeon® Processor E5-2600 16 x DDR3-1600/1066 DIMM (Max 512 GB : 32GB DIMM 使用時) I/O and Storage 4 x PCIe 3.0 スロット ( Slot4 : インターナル用 ) SAS-2 & SATA-2 HDD/SSD ならびに DVD Drive の組み合わせは3タイプ(上記イメージ参照) 6 x USB 2.0 ポート ( 2x フロント, 2x インターナル, x2 リア ) 4 x 10Gb Ethernet ポート 可用性 ホットスプラグ対応ディスク HW RAID 0,1,5,6,10,50,60 (w/ HBA) ホットスワップ対応 2N(1+1) 電源, 600W ホットスワップ対応 N+1 ファン 管理 Oracle ILOM Service Processor 3.1 Solaris, Linux, OVM, Windows, VMWare OHMP 2.2.1< Sun Fire X4270 M3 サーバー : 3タイプ > Sun Fire X4270 M3 サーバー 基本仕様 Computing 2 x Intel® Xeon® Processor E5-2600 16 x DDR3-1600/1066 DIMM (Max 256 GB : 16GB DIMM 使用時) I/O and Storage 6 x PCIe 3.0 スロット SAS-2 & SATA-2 HDD/SSD ならびに DVD Drive の組み合わせは3タイプ(上記イメージ参照) 2 x 2.5” SAS-2 & SATA-2 リア HDD/SSD 搭載 (DVD-Drive無しのタイプ) 6 x USB 2.0 ポート ( 2x フロント, 2x インターナル, x2 リア ) 4 x 10Gb Ethernet ポート 可用性 ホットスプラグ対応ディスク HW RAID 0,1,5,6,10,50,60 (w/ HBA) ホットスワップ対応 2N(1+1) 電源, 1000W ホットスワップ対応 N+1 ファン 管理 Oracle ILOM Service Processor 3.1 Solaris, Linux, OVM, Windows, VMWare OHMP 2.2.1USの製品ページはこちら。

 既にアナウンスされて一月経過している訳ですが、、、さる 2012年4月10日に Intel Xeon processor E5-2600搭載 「Sun x86」 M3 サーバーがアナウンスされました。そして、昨日の2012年5月16日に「Sun x86」 M3 サーバー製品群の国内提供が開始されました!!。 今回、Oracleから出荷が開始された新型「Sun x86」サーバー群は Intel...

Solaris

4/26 (木) 開催! Oracle Solaris 11 ディープダイブ第3弾 ~Solaris 11への移行~

海に行っても深いところが怖いので、いつも足首が隠れるくらいの浅瀬で水遊びしている担当です。こんにちは。いきなりですが、好評につき第 3 弾開催決定!この blog で、1 回目と 2 回目の告知をした記憶がないのですが、第 3 弾の告知となります。今回は、4/26 (木) 14:00 (受付開始 13:30) に開催し、「Solaris 11 ディープダイブ第3弾 ~Solaris 11への移行~」というタイトルで Solaris 11 へ移行するために重要となるポイントをご紹介致します。Solaris 11 では、以前のリリースとの互換性を維持しながらも、多数の新しい管理手法が取り入れられました。これを踏まえ、Solaris 10 と Solaris 11 の機能差比較も交えながら、大きく変更された新しい管理方法や移行に関する注意点を「セッション 1: Solaris 10 から Solaris 11 への移行準備とポイント」でご紹介。そして、Legacy Solaris 環境を Solaris 11 へ移行させるメリット!を熱く、そして、Solaris 11 で可能なさまざまな移行方法を事例を交えて解説する「セッション 2: Solaris 11 への移行のススメ」の 2 本立てとなります。申し込みは、こちらから!http://www.oracle.com/goto/jpm120426

海に行っても深いところが怖いので、いつも足首が隠れるくらいの浅瀬で水遊びしている担当です。 こんにちは。 いきなりですが、好評につき第 3 弾開催決定! この blog で、1 回目と 2 回目の告知をした記憶がないのですが、第 3 弾の告知となります。今回は、4/26 (木) 14:00 (受付開始 13:30) に開催し、「Solaris 11 ディープダイブ第3弾 ~Solaris...

Storage

Sun ZFS Backup Appliance 登場!

昨日、Sun ZFS Backup Appliance が発表されました。Exadata の D2D バックアップ用途の位置づけで、 High Capacity と High Performance の 2 つのモデルがあります。いづれも、SunRack 1242 に搭載されています。管理機能などは ZFS Storage Appliance と同じですので、簡単に管理できる Web ベースのツールが使用可能で、Analytics などの機能もばっちり使えます。ハードウェアのスペックは以下のようになっています。High CapacityHigh Performanceコントローラ搭載数2 (クラスタ構成)2 (クラスタ構成)CPUIntel Xeon E7-4820 (8-core, 2GHz)x4Intel Xeon E7-4820 (8-core, 2GHz)x4メモリ 256GB 256GB インターフェースQDR Infiniband, 10Gbe, 1Gbe(それぞれ 4 ポートずつ搭載)QDR Infiniband, 10Gbe, 1Gbe(それぞれ 4 ポートずつ搭載)ディスクシェルフディスク容量(Raw)132TB55TBディスクシェルフ数2 (最大 22 シェルフ増設可能)4 (最大 22 シェルフ増設可能)ディスクタイプ3TB 7200rpm600GB 15000rpm書き込みキャッシュ本数44また、ソフトウェアのプラグインを使うことにより、ZFS Backup Appliance の設定と Exadata の設定がコマンドラインで一括してできるようになります。これにより、さらに簡単にバックアップ・リストアの環境を構築することができます。OTN よりダウンロード可能で、マニュアルもダウンロードパッケージの中に含まれています。Oracle Exadata Backup Configuration Utility v1.0.1 Oracle ZFS Storage Appliance Plugin Downloads USの製品ページはこちら。

昨日、Sun ZFS Backup Appliance が発表されました。 Exadata の D2D バックアップ用途の位置づけで、 High Capacity と High Performance の 2 つのモデルがあります。いづれも、SunRack 1242 に搭載されています。管理機能などは ZFS Storage Appliance と同じですので、簡単に管理できる...

Sun

Oracle Solaris ナイトセミナー #2 開催!

復活!! Oracle Solaris ナイトセミナー #1 に参加頂きありがとうございました。途中、「お前誰だよっ!」的なサプライズがあったり困惑した方も多かったかと思いますが、大きな声で年齢をばらされたりなど不本意ながらも本人は大変喜んでおりました。この場を借りて、お礼を申し上げます。さて、そんな喜びを今頃になって噛み締めている担当者ですが、#1 でお約束したとおり、Mr. Solaris の下に集う Solaris を愛してやまない中の人たちが、手作りでお届けするセミナー 2 回目となる「Oracle Solaris ナイトセミナー #2」開催のお知らせを、やっとお届けできることとなりました!今回は、参加登録に利用するのはイベント開催支援ツール:ATND(アテンド)が提供するイベント ATND です。こちらでは、チケットを利用した申し込みとなり、会員登録せずに申し込みも可能となりました。本セミナー自体は、無料セミナーですのでお気軽にご参加頂ければと思います。第ニ弾となる「Oracle Solaris ナイトセミナー # 2」は、2012/04/20 (金) 18:30 開催です。今回の内容も、昨年行われた「Oracle Solaris 11テクニカル・ディープ・ダイブ第 1 弾」の内容を、ナイトセミナー風にアレンジした、「Oracle Solaris 11テクニカル・ディープ・ダイブ第 1 弾 ナイトセミナー風」となり、ZFS にフォーカスした内容となっています。セッション 1 は、Solaris エバンジェリストである野崎が、「ZFS はストレージをどう仮想化できるのか? Solaris 11 は、なぜ ZFS を必要としたのか? 」を解説する「ZFSによるストレージ仮想化」です!セッション 2 は、「もう一つストレージの仮想化機能 “COMSTAR”概要」です。こちらは、この記事を書いている人が担当しますので、軽く流してください。そして、衣装がパワーアップしてしまった「ナイトセミナーでおなじみ! – Solaris 3 分クッキング」!調理にも節約は大事です。というわけで、ZFS と節約といったら圧縮か?と思わせて重複排除を持ってきた「ZFS, dedup で節約してみる」です!また、ここまで読んでしまいましたね。参加するしかないですよね?というわけで、参加申し込みは下記の ATND でお願い致します!Oracle Solaris ナイトセミナー # 2http://atnd.org/event/solarisns2みなさまのご参加をお待ちしております。あ。。。サブタイトルついてない。。。Solaris 11 深掘り #1 の 2 です!

復活!! Oracle Solaris ナイトセミナー #1 に参加頂きありがとうございました。 途中、「お前誰だよっ!」的なサプライズがあったり困惑した方も多かったかと思いますが、大きな声で年齢をばらされたりなど不本意ながらも本人は大変喜んでおりました。 この場を借りて、お礼を申し上げます。さて、そんな喜びを今頃になって噛み締めている担当者ですが、#1 でお約束したとおり、Mr....

Storage

Enterprise Manager 12c と ZFS Storage Appliance

今回は簡単にではありますが、 Enterprise Manager 12c による Sun ZFS Storage Appliance の監視について紹介していきたいと思います。まず、Enterprise Manager から Sun ZFS Storage Appliance を監視するには、プラグインを Enterprise Manager にインストールする必要があります。3月から Sun ZFS Stoarage Appliance の各種プラグインのダウンロードサイトが My Oracle Support から、Oracle Technology Network に移動しましたので、こちらからダウンロードしてください。一緒に、マニュアルもダウンロードすることができます。Oracle ZFS Storage Appliance Plugin Downloads Sun ZFS Storage Appliance 側で準備することは、先ほど紹介したインストールマニュアルの P.3 に記載されている通り、Appliance 内に最初からはいっている Workflow を実行するだけです。Enterprise Manager 側のインストールと設定は P.10 以降に記載されています。記載の通りに実行していけば、特に問題なく設定できると思います。Enterprise Manager 11g に比べて結構簡単になったかなぁという印象です。以下にいくつか、スクリーンショットを紹介していきます。利用状況のしきい値設定と警告といったことは、Sun ZFS Storage Appliance だけでもできますが、Database をはじめとして各種ソフトウェア等と管理を一元化したいときには、Enterprise Manager を使うことでより簡単に監視することが可能です。

今回は簡単にではありますが、 Enterprise Manager 12c による Sun ZFS Storage Appliance の監視について紹介していきたいと思います。 まず、Enterprise Manager から Sun ZFS Storage Appliance を監視するには、プラグインを Enterprise Manager にインストールする必要があります。3月から Sun...

Sun

SPARC SuperCluster T4-4 日本上陸!

SPARC SuperCluster T4-4 がついに Oracle Solution Center Tokyo に到着しました!今回はその搬入風景を Pillar Axiom 600 の項と同様、紹介したいと思います。トラックから今まさに SPARC SuperCluster T4-4 が運び出されるようとしています。Oracle Solution Center Tokyo へ運び入れ、そしてビニールをとりはずし...位置を調整し、ついに設置完了です。今後 SPARC SuperCluster T4-4 を利用した POC (Proof of Concept) がここ日本で可能となりますので、是非ご利用いただければと思います!と、その前に SPARC SuperCluster T4-4 導入により何がうれしいの?という疑問をもたれた本 blog をお読みの方...是非 4月4日から開催される Oracle OpenWorld Tokyo 2012 にご来場ください。 4/5(木) ゼネラルセッション G2-01 「ビッグデータ&クラウド時代を勝ち抜くITプラットフォーム戦略」(11:50 - 13:20)@ベルサール六本木4/5(木) S2-42 「最新UNIX統合プラットフォーム - SPARC SuperCluster」 (16:30 - 17:15)@グランドハイアット東京4/5(木) S2-53 「Oracle E-Business Suiteのパフォーマンスと可用性を最大化し、導入/運用コストを劇的に削減する最新のシステム基盤”SPARC SuperCluster”」(17:40 - 18:25)@グランドハイアット東京また、グランドハイアット東京には展示ブースがありますので、そちらにも是非お立ち寄りください!EXHIBITION HALL(展示会場)(11:15-18:00)@グランドハイアット東京http://www.oracle.com/openworld/jp-ja/exhibit/index.htmlこれは絶対見逃せません!!Oracle OpenWorld Tokyo 2012 お申込み URL http://www.oracle.com/openworld/jp-ja/index.html招待コードは 7264 を記載してお申し込みください。

SPARC SuperCluster T4-4 がついに Oracle Solution Center Tokyo に到着しました!今回はその搬入風景を Pillar Axiom 600 の項と同様、紹介したいと思います。 トラックから今まさに SPARC SuperCluster T4-4 が運び出されるようとしています。Oracle Solution Center Tokyo...

Sun

SPARC T4 モーメンタム: SPARC T4 サーバーでいいんです!!

 昨年 2011 年 9 月に SPARC T4 プロセッサとそれを搭載した SPARC T4 サーバーラインナップが発表され、更に 2011年 10月に出荷が開始され早くも半年が過ぎようとしています。 正確な数をお伝えすることはできませんが、SPARC T4 サーバーシリーズもおかげさまでワールドワイドで順調に出荷台数を伸ばしており、これをお読みになられている方の中にも既に SPARC T4 プロセッサならびに SPARC T4 サーバーの素晴らしさを実際に体感されている方もいらしゃると思います。 そのような状況の中、更に追い風な事として、4/4, 4/5, 4/6 と 3日間、ここ東京で Oracle OpenWorld Tokyo 2012 が開催されます。 Oracle OpenWorld Tokyo 2012 では Oracle のサーバー&ストレージおよび Oracle Solaris の開発部門トップのジョン・ファウラーを筆頭に SPARC&Solaris のキーパーソンが多数来日し、SPARC&Solaris の現状ならびに将来についての最新情報を聞ける絶好のチャンスですので、システムズ製品にご興味のある方は是非、会場に足を運んでいただきたいと思います。 Oracle OpenWorld Tokyo 2012 お申込み URL http://www.oracle.com/openworld/jp-ja/index.html 招待コードは 7264 を記載してお申し込みください。 そこで、Oracle OpenWorld Tokyo 2012 を直前に控えてという状況ですので、ここでもう一度、SPARC T4 プロセッサのおさらいしておきたいと思います。 SPARC T4 プロセッサは従来の SPARC T3 プロセッサのコア(S2コア)をスクラッチから設計し直した全く新しいプロセッサコア(S3コア)を持つオラクル社の最新プロセッサです。 しかしながら、" T " という冠が付いている関係なのか(?)、どうしても SPARC T1/T2/T3 プロセッサの得意としていた大量データー同時並列処理能力(スループット性能)特性に比重を置いた従来のイメージばかりが先行して、<お客様>「SPARC T4 プロセッサのシングルスレッド性能って本当に早いんですか?」「SPARC T4 プロセッサってDB等のミドルウェアや高速バックアップの用途で使えるんですか?」 というお客様からのご質問が多く、<私>「各種ベンチマーク測定結果から、シングルスレッド性能が要求される用途でも問題ございません」「従来の SPARC T3 プロセッサが得意とするスループット性能もスレッドあたり2倍に高速になっています」 という説明を、何度もお客様先やセミナー等でご説明させていただいたのをつい先日のことのように思い出されます。 最近、こういった問い合わせも SPARC T4 サーバーの出荷台数が増えるに従って、受ける機会が減ってきていることから、SPARC T4 プロセッサならびに SPARC T4 サーバーの素晴らしさが実際にお客様やパートナー様に認知されてきていると確信しています。 繰り返しになりますが、 T4 プロセッサのシングルスレッド性能は弊社 SPARC サーバープロダクトラインにおいて現時点でトップレベルの領域です。更に、マルチスレッド性能は従来同様に折紙つきの素晴らしいパフォーマンス&スケーラビリティです。 既に、各種パフォーマンス測定結果が公開され、多数のワールドレコードを達成しており、見ていただければ分かる通り、WebベースアプリケーションからDBアプリケーションまで幅広くお使いいただける素晴らしいサーバーとなっています。 (各種ベンチマーク測定結果) 前置きはこのくらいにして SPARC T4 プロセッサの特徴について具体的にまとめてみたいと思います。 < T4 プロセッサの概要 > 次世代 SPARC コア(S3コア)の登場 x5倍のシングルスレッドパフォーマンス向上 x2倍のスレッドスループットパフォーマンス向上 Crypto (暗号化機能)のパフォーマンス向上 データーベースアプリケーションに対するハードウェア/ソフトウェアの最適化策の組み込み グルーレスな 1, 2,& 4 ソケットプロセッサ構成  < T4 プロセッサ マイクログラフ > 8x SPARC S3 コア (64スレッド/チップ) 4MB 共有 L3 キャッシュ (8バンク/16ウェイ) 8x9 クロスバー 4x DDR3 メモリーコントローラー @6.4Gbps 6x コヒーレンシーリンク @9.6Gbps 2x8 PCIe 2.0 (5GTS) 2x10Gb XAUI イーサーネット < S3コアブロックダイアグラム > ALU : Arithmetic Logic Unit BRU : Branch Logic Unit FGU : Flouting-point Graphics Unit IRF : Integer Register File FRF : Flouting-point Register File WRF : Working Register File MMU : Memory Management Unit LSU : Load Store Unit Crypto(SPU) : Streaming Processing Unit TRU : Trap Logic Unit < S3コアオーバービュー > 高クロック 8スレッド/コア 二重発行命令 Out-of-Order 実行 16ステージインテジャーパイプライン ダイナミックスレッディング ハードウェアプリフェッチ 新分岐予測機構 ストアパイプライン 64エントリ ITLB と 128エントリ DTLB 64KB 4ウェイ L1 インストラクションキャッシュ 128KB 8ウェイ コア単位 L2 キャッシュ < SPARC T4 コアパイプライン vs SPARC T3 コアパイプライン > SPARC T4 プロセッサパイプライン上の Out-Of-Order ステージ Pick ステージの前まで In-Order 実行 Pick ステージから Commit ステージまでが Out-Of-Order 実行 Commit ステージから In-Order 実行 < SPARC T4 ダイナミックスレッド > シングルスレッドモードvsマルチスレッドモードといったようなモードビットは存在しない 各サイクルごとにActiveなスレッドに動的にリソースを割り当てる ヘテロジーニアスワークロードのスループットの向上 全体的なアプリケーションスケールの改善 < SPARC T4vsT1/T2/T3 パフォーマンス > SPARC T4 サーバー SPARC T3 サーバーが得意としていたWebアプリケーションも得意 DBやバックアップといったシングルスレッドアプリケーションも得意 上記の内容からも分かる通り、SPARC T4 プロセッサ&Solaris の組み合わせはあらゆる処理(アプリケーション)に順応できるサーバー製品になっていますので、是非一度、お試しいただき、その素晴らしさを体感していただければと思います!!。 < Oracle OpenWorld Tokyo 2012 展示会場について >  最後に、Oracle OpenWorld Tokyo 2012 ではグランドハイアット東京にて、SPARC T4 サーバーならびにストレージプロダクトの実機を 4/4, 4/5, 4/6 の 3日間展示しています。説明員も配置されますので実機を見ながら詳細をご確認いただくことが可能ですので、各セッションの間の空き時間等を利用して是非お越しいただければと思います。展示会場に関するインフォメーション URL http://www.oracle.com/openworld/jp-ja/exhibit/index.html

 昨年 2011 年 9 月に SPARC T4 プロセッサとそれを搭載した SPARC T4 サーバーラインナップが発表され、更に 2011年 10月に出荷が開始され早くも半年が過ぎようとしています。 正確な数をお伝えすることはできませんが、SPARC T4 サーバーシリーズもおかげさまでワールドワイドで順調に出荷台数を伸ばしており、これをお読みになられている方の中にも既に SPARC...

Sun

SPARC T4 サーバー省電力機能

節電や電力消費をおさえるといったことが関心事となる昨今、劇的な性能向上を果たし、現在非常に注目が集めている SPARC T4 サーバーでも省電力機能が利用可能です。設定は非常に簡単。T4 サーバーのもつ SP(Service Processor) である ILOM から-> set /SP/powermgmt policy=elastic とするだけ。実は通常サーバー出荷時には電力モードがパフォーマンスモードと呼ばれるモードで届くのですが、上記コマンドによりそれを節電モードとするエラスティックモードへと変更します。ILOM の /SYS/VPS/history/0 からサーバーの消費電力を確認できるのですが、下記は実際に SPARC T4-1 で OS のみが動作しているときにパフォーマンスモードからエラスティックモードにした場合の時間経過と消費電力値の推移です。表示は 日付 時刻 = 消費電力値(W)のようにリストされています。 Mar 26 12:04:54 = 294 Mar 26 12:03:53 = 292 Mar 26 12:02:53 = 292 Mar 26 12:01:53 = 293 Mar 26 12:00:53 = 292 Mar 26 11:59:53 = 293 Mar 26 11:58:54 = 293 Mar 26 11:57:54 = 294 Mar 26 11:56:54 = 293 Mar 26 11:55:54 = 348

節電や電力消費をおさえるといったことが関心事となる昨今、劇的な性能向上を果たし、現在非常に注目が集めている SPARC T4 サーバーでも省電力機能が利用可能です。設定は非常に簡単。T4 サーバーのもつ SP(Service Processor) である ILOM から -> set /SP/powermgmt policy=elastic とするだけ。実は通常サーバー出荷時には電力モードがパフォ...

Sun

「SPARC T4」プロセッサ搭載のエントリ・サーバー : Netra SPARC T4-1

 「SPARC T4」プロセッサを搭載したエントリ・サーバーとして Netra SPARC T4-1 ならびに Netra SPARC T4-2 が2012年1月10日にアナウンスされ、3月15日より提供が開始されました。(発表資料) そして日本のラボにも Netra SPARC T4-1 の 4core モデル( T4 シリーズでは初の 4core モデル)(*)が届いたので、早速実機でプロセッサ周りをみてみました。(*)( Netra SPARC T4-1 システムには 4core モデルと 8core モデルがあります) 以下が prtdiag コマンドと pginfo コマンドの出力結果になります。 8スレッド/1core ですので prtdiag コマンド結果から4core=32スレッドになってますね。また、pginfo コマンド結果を見ればより具体的な各core のスレッドの割り当て状況が見て取れます。 # ./prtdiag -vSystem Configuration: Oracle Corporation sun4v Netra SPARC T4-1メモリーサイズ: 130560 M バイト================================ 仮想 CPU ================================CPU ID Frequency Implementation Status------ --------- ---------------------- -------0 2848 MHz SPARC-T4 on-line1 2848 MHz SPARC-T4 on-line2 2848 MHz SPARC-T4 on-line3 2848 MHz SPARC-T4 on-line4 2848 MHz SPARC-T4 on-line5 2848 MHz SPARC-T4 on-line6 2848 MHz SPARC-T4 on-line7 2848 MHz SPARC-T4 on-line8 2848 MHz SPARC-T4 on-line9 2848 MHz SPARC-T4 on-line10 2848 MHz SPARC-T4 on-line11 2848 MHz SPARC-T4 on-line12 2848 MHz SPARC-T4 on-line13 2848 MHz SPARC-T4 on-line14 2848 MHz SPARC-T4 on-line15 2848 MHz SPARC-T4 on-line16 2848 MHz SPARC-T4 on-line17 2848 MHz SPARC-T4 on-line18 2848 MHz SPARC-T4 on-line19 2848 MHz SPARC-T4 on-line20 2848 MHz SPARC-T4 on-line21 2848 MHz SPARC-T4 on-line22 2848 MHz SPARC-T4 on-line23 2848 MHz SPARC-T4 on-line24 2848 MHz SPARC-T4 on-line25 2848 MHz SPARC-T4 on-line26 2848 MHz SPARC-T4 on-line27 2848 MHz SPARC-T4 on-line28 2848 MHz SPARC-T4 on-line29 2848 MHz SPARC-T4 on-line30 2848 MHz SPARC-T4 on-line31 2848 MHz SPARC-T4 on-line======================= Physical Memory Configuration ======================== 以下省略 # pginfo -p -T0 (System [system,chip]) CPUs: 0-31`-- 3 (Data_Pipe_to_memory [system,chip]) CPUs: 0-31 |-- 2 (Floating_Point_Unit [core]) CPUs: 0-7 | `-- 1 (Integer_Pipeline [core]) CPUs: 0-7 |-- 5 (Floating_Point_Unit [core]) CPUs: 8-15 | `-- 4 (Integer_Pipeline [core]) CPUs: 8-15 |-- 7 (Floating_Point_Unit [core]) CPUs: 16-23 | `-- 6 (Integer_Pipeline [core]) CPUs: 16-23 `-- 9 (Floating_Point_Unit [core]) CPUs: 24-31 `-- 8 (Integer_Pipeline [core]) CPUs: 24-31 T4 プロセッサに関しては既に様々なメディアで既に取り上げていただいており、繰り返しになりますが、従来の T3 プロセッサ(S2 core)と比較してT4 プロセッサ(S3 core)は単一スレッドの処理能力が5倍に向上しており、従来の T3 プロセッサ(S2 core)が得意としていた優れた大量データー同時並列処理能力(スループット性能)を維持し、かつ、シングルスレッド性能を向上させたことにより、あらゆる場面でエンタープライズ・アプリケーションに求められる能力を発揮でき、高速バッチ処理も可能になっています。 よって、T4 プロセッサってどんな感じ?っとご興味がある方はまずはこのT4 プロセッサのエントリ・サーバーである Netra SPARC T4-1 4core モデルをお手にしてみてはいかがでしょうか?。実際に触っていただければ即、T3 プロセッサとの特性の違いを実感していただけると思います。 以下に簡単ですが、Netra SPARC T4-1 のスペックを記載しておきます。 Netra SPARC T4-1 仕様 Computing 1 x SPARC T4 4コア 32スレッド or 8 コア 64 スレッド 2.85GHz CPU (1コアあたり8スレッド) 16 x DDR3 DIMM (最大 256GB 搭載可能、16GB DIMM 実装時) I/O and Storage 3 x Low Profile PCI-Express Gen2 スロット (2 x 10Gb Ethernet XAUI スロットと兼用) 2 x Full-height Half-length PCI-Express Gen2 スロット 4 x 10/100/1000 Ethernet オンボードポート 4 x 2.5” SAS2 HDD 4 x USB ポート (前面 2, 背面 2) RAS and Management and Power Supply ディスク (RAIDサポート), ファン、PSU がホットスワップ可能 ILOMサービスプロセッサによる管理 2N (1+1) , AC もしくは DC 電源 Support OS Oracle Solaris 10 10/9, 9/10, 8/11, Oracle Solaris 11 11/11 Oracle VM Server for SPARC 2.1 (LDoms) サポート その他 NEBS Level3対応 筺体奥行き約21” 19”(EIA-310D),23”,24”,600mmラック対応 ドライ接点(無電圧接点)アラームポート装備 最後に、SPARC T4 サーバーならびにSPARC T4 プロセッサに関して最新情報を入手するチャンスが来月(4月早々)に日本であります。それは Oracle OpenWorld Tokyo 2012 が3日間(4/4(水)、4/5(木)、4/6(金))東京で開催され、その中でもオラクルのサーバ&ストレージのベンチマークを実施し、SPARC T4 サーバーパフォーマンスについて一番良く知る人物、そう、あのブラッド・カーライルが来日し講演を行います。SPARC T4 サーバーにご興味ある方は見逃せませんね!。Oracle OpenWorld Tokyo 2012http://www.oracle.com/openworld/jp-ja/index.html ブラッド・カーライルのセッションは 4/6(金) Develop D3-13 (14:00 - 14:45)六本木アカデミーヒルズ49 にて。招待コードは 7264 を記載してお申し込みください。

 「SPARC T4」プロセッサを搭載したエントリ・サーバーとして Netra SPARC T4-1 ならびに Netra SPARC T4-2 が2012年1月10日にアナウンスされ、3月15日より提供が開始されました。(発表資料) そして日本のラボにも Netra SPARC T4-1 の 4core モデル( T4 シリーズでは初の...

Sun

Solaris 11 に対応! Oracle Solaris Cluster 4.0

2011 年 11 月 9 日に発表された Oracle Solaris 11 に続き、2011 年 12 月 6 日にOracle Solaris 11 に対応した Oracle Solaris Cluster 4.0 がリリースされました。Oracle Solaris Cluster は Solaris 用の高可用性クラスタソフトウェアのことで、Sun 時代は Sun Cluster と呼ばれていた製品です。 オラクルとなり、Oracle Solaris Cluster とリブランディングされました。ライセンスも Oracle データベースのように、プロセッサライセンスとなり、Oracle Solaris Cluster のバージョンに依存せずに、使用するプロセッサ数分のライセンスを購入することにより、Oracle Solaris Cluster のコアコンポーネント、すべてのエージェント、ディザスタ・リカバリ向けの Geographic Edition のすべてが使えるようになりました。現在 Solaris 10 に対応する最新の Oracle Solaris Cluster は 3.3 5/11 (Update 1) となり、Solaris 11 に対応するバージョンが 4.0 ということになります。Oracle Solaris Cluster 4.0 の特長は以下のようになります。 Solaris 11 IPS / AI をサポート Solaris 仮想化環境 (Solaris Zones, Oracle VM Server for SPARC) をサポート Oracle Solaris Cluster Geographic Edition によりディザスタ・リカバリ機能をサポートOracle Solaris Cluster の詳細は今後、本ブログでも取り上げていきたいとおもいますが、Oracle Solaris Cluster の特長は、やはり Solaris のカーネルモジュールとして提供され、Solaris の特長的な機能を Solaris Cluster 環境においても融合され利用できるところにあります。Solaris 11 では、Solaris のさらなる進化が IPS や 仮想化に見られます。そんな Solaris 11 の特長を、Oracle OpenWorld Tokyo 2012 開催期間中の 4/6(金) に六本木アカデミーヒルズ49 で行われる Oracle Develop にて詳細を聞いてみませんか?4/6(金) D3-03 「Oracle Solaris 11デベロッパーが押さえておきたい機能」(13:00 - 13:45)4/6(金) D3-13 「世界新記録を次々と達成する本人が語る Oracle DatabaseをSPARC/Solarisで高性能かつ高いセキュリティで構築するノウハウ」 (14:00 - 14:45)4/6(金) S2-53 「Oracle Solaris 11 でパッケージ管理をシンプルに-IPS パッケージ作成」(16:00 - 17:30)これは絶対見逃せません!! (Oracle Develop の Solaris 関連セッションですでに満席のものについては上記リストから除いています)Oracle OpenWorld Tokyo 2012 お申込み URL http://www.oracle.com/openworld/jp-ja/index.html招待コードは 7264 を記載してお申し込みください。

2011 年 11 月 9 日に発表された Oracle Solaris 11 に続き、2011 年 12 月 6 日にOracle Solaris 11 に対応した Oracle Solaris Cluster 4.0 がリリースされました。Oracle Solaris Cluster は Solaris 用の高可用性クラスタソフトウェアのことで、Sun 時代は Sun Cluster...

Sun

Oracle/Sun の技術を結集 - SPARC SuperCluster T4-4

SPARC SuperCluster T4-4 をご存知でしょうか? SPARC SuperCluster は 2010年12月にラリー・エリソンによりそのコンセプトが発表され、2011 年 9 月に SPARC T4 サーバーシリーズとともに SPARC SuperCluster T4-4 としてリリースが発表されました。SPARC SuperCluster は、汎用エンジニアド・システムとしてラインナップされ、劇的な性能向上をとげた SPARC T4 CPU を 4 台搭載する SPARC T4-4 をコンピュートノードとして、同じエンジニアド・システムの、データベースの最高性能を求めた Exadata のキーコンポーネントである Oracle Exadata Storage Server が利用でき、ミドルウェアや Java の最高性能を求めた Exalogic のキーコンポーネントである Exalogic Software を構成して利用することができます。それに加えて Solaris 10 または 11 をサポートする一般的なアプリケーションも、この SPARC SuperCluster に搭載して使用することを可能としています。以下の搭載製品群をご覧いただくとわかるように、SPARC SuperCluster は Oracle/Sun の技術を結集させた製品であることがご理解いただけるのではないでしょうか。SPARC SuperCluster のハードウェア構成概要 2(Half Rack 時) or 4(Full Rack 時) x SPARC T4-4 サーバー 3 (Half Rack 時) or 6 (Full Rack 時) x Exadata Storage Server X2-2 1 x ZFS Storage Appliance 7320 クラスタ構成 3 x Sun DataCenter InfiniBand Switch 36 1 x Ethernet Management Switch 42U Rack (2 x PDU)SPARC SuperCluster にて利用可能なソフトウェア OS: Oracle Solaris 11 および 10 仮想化: Oracle VM Server for SPARC および Oracle Solaris Zones 管理: Oracle Enterprise Manager Ops Center および Grid Control クラスタリング: Oracle Solaris Cluster および Oracle Clusterware データベース: Oracle データベース 11g R2 (11.2.0.3) およびその他データベース ミドルウェア: Exalogic Software とともに Oracle WebLogic Server, Coherence アプリケーション: Oracle Solaris 11 および 10 にてサポートされる Oracle もしくは ISV、カスタマアプリケーション SPARC SuperCluster はエンジニアド・システムのため、仮想環境を各ワークロードに対しどのように設計するかといった非常に複雑で製品知識を必要とされる点について、事前にオラクルのエンジニアによって十分に考えぬかれ、オラクルによってサポートされテストされた最適な構成をお客様に提供することになります。その結果として、高性能なシステムを迅速に導入することが可能となっています。SPARC SuperCluster には関しては、本ブログにて、その詳細を今後話題にしていきたいと思いますが、もっと早く SuperCluster について把握されたい方は、Oracle OpenWorld Tokyo 2012 の講演にご参加いただくことをお勧めします!4 月 5 日にベルサール六本木またはグランドハイアット東京を会場とする Oracle OpenWorld Tokyo 2012 の以下のセッションでは SPARC SuperCluster の技術面だけではなく、ビジネス面やその利点など幅広く話があります。4/5(木) ゼネラルセッション G2-01 「ビッグデータ&クラウド時代を勝ち抜くITプラットフォーム戦略」(11:50 - 13:20)4/5(木) S2-42 「最新UNIX統合プラットフォーム - SPARC SuperCluster」 (16:30 - 17:15)4/5(木) S2-53 「Oracle E-Business Suiteのパフォーマンスと可用性を最大化し、導入/運用コストを劇的に削減する最新のシステム基盤”SPARC SuperCluster”」(17:40 - 18:25)これは絶対見逃せません!!Oracle OpenWorld Tokyo 2012 お申込み URL http://www.oracle.com/openworld/jp-ja/index.html招待コードは 7264 を記載してお申し込みください。

SPARC SuperCluster T4-4 をご存知でしょうか? SPARC SuperCluster は 2010年12月にラリー・エリソンによりそのコンセプトが発表され、2011 年 9 月に SPARC T4 サーバーシリーズとともに SPARC SuperCluster T4-4 としてリリースが発表されました。SPARC...

Sun

リック・ヘザリントン サイン入り SPARC T4 CPU チップ

昨年(2011年)12月の話になりますが、「SPARC T4 ディープ・ダイブ~ここだけで聞ける詳細情報~」 というセミナーが開催されました。このセミナーでは SPARC T4 CPU の開発責任者のリック・ヘザリントンが来日し登壇しました。写真は、リック本人からこのセミナーの際にいただきましたサイン入り SPARC T4 CPU になります! SPARC T4 CPU の仕様 8 個の SPARC V9 S3 コア 64 スレッド (1コアあたり8スレッド) クロック周波数: 2.85GHz および 3.0GHz コアあたり暗号ストリーム処理ユニット搭載 コアあたり 16KB のデータ・キャッシュと 16KB の命令キャッシュ コアあたり 128KB L2 キャッシュ コア共有の 4MB L3 キャッシュ CPU に 2 x メモリコントローラーユニット内蔵 (1 CPU あたり最大 16 DDR3 DIMM メモリをサポート) CPU に 2 x 10Gb Ethernet ネットワークインタフェースユニット内蔵 CPU に 2 x PCI Express Generation 2 インタフェース内蔵 プロセステクノロジー: 40nm ダイサイズ: 403mm2日本で、プロセッサを開発している本人から直接その話を聞けるというのは本当にまたとない貴重な機会でした。このような本社開発部門の人間から次はいつ話が聞けるのだろうかと思っていましたが、そのような機会はわりと早めにやってきました! そうです、来月開催される Oracle OpenWorld Tokyo 2012 では、Oracle のサーバー&ストレージ、および Oracle Solaris の開発部門トップのジョン・ファウラーが来日して講演を行います!これは絶対見逃せません!!ジョン・ファウラーが登場するセッションは...4/4(水) 基調講演 K1-01 「ENGINEERED FOR INNOVATION 技術の融合が、世界を変える。」 (9:00 - 11:15)4/5(木) ゼネラルセッション G2-01 「ビッグデータ&クラウド時代を勝ち抜くITプラットフォーム戦略」(11:50 - 13:20)Oracle OpenWorld Tokyo 2012 お申込み URL http://www.oracle.com/openworld/jp-ja/index.html招待コードは 7264 を記載してお申し込みください。

昨年(2011年)12月の話になりますが、「SPARC T4 ディープ・ダイブ~ここだけで聞ける詳細情報~」 というセミナーが開催されました。このセミナーでは SPARC T4 CPU の開発責任者のリック・ヘザリントンが来日し登壇しました。写真は、リック本人からこのセミナーの際にいただきましたサイン入り SPARC T4 CPU になります! SPARC T4 CPU の仕様 8 個の...

Sun

SPARC T4 CPU の劇的な性能向上

昨年 2011 年 9 月に SPARC T4 CPU とそれを搭載した SPARC T4 サーバーラインナップが発表されました。過去 SPARC T シリーズといえば、マルチコアかつマルチスレッドで比較的軽いワークロードを大量に処理することを得意としていました。したがって、用途としては、Web 層やアプリケーション層での利用が想定されていました。しかしながら、今度の SPARC T4 はこれまでの SPARC T シリーズの傾向とは異なるようです。引き続きマルチコアかつマルチスレッドでありながら、現代の高性能 CPU コアにはあたりまえとされるアウトオブオーダー実行、二重命令発行、ハードウェア・プリフェッチ 等といった機能に加えて、さらにダイナミック・スレッディングと呼ばれる SPARC T4 ならではの機能を搭載しています。この結果 SPARC T3 CPU と比較して、シングルスレッド性能が 5 倍に、浮動小数点演算の性能が 7 倍に向上し、Web 層、アプリケーション層だけでなく、データベース層での OLTP やバッチ処理といったワークロードにも幅広く対応可能としてます。 SPARC T4 CPU およびそのサーバーラインナップについては、今後本ブログでも序々に紹介していくことになると思います。この SPARC T4 の性能向上を感じてもらうには、やはり実機を使用して実感してもらうことが一番ですが、なかなかそういった機会にめぐまれない場合には、やはりベンチマーク結果もその性能向上をご理解いただくための一助になるのではないでしょうか。オラクルはSPARC T4 に対する各種ベンチマーク結果をホームページで公開をしています。さらにその詳細は BestPerf ブログ においても(どちらも英語ですが)公開していますので、是非チェックしてみてください。さて、このオラクルのサーバ&ストレージのベンチマークを実施、そして BestPerf ブログによる詳細の公開は、オラクルのストラテジック・アプリケーション・エンジニアリングと呼ばれる部門においてなされていますが、なんと Oracle OpenWorld Tokyo 2012 には、このグループをリードするシニア・ディレクタのブラッド・カーライルが来日し、「世界新記録を次々と達成する本人が語る Oracle DatabaseをSPARC/Solarisで高性能かつ高いセキュリティで構築するノウハウ」というタイトルで講演を行うとのこと! SPARC/Solaris の性能に関してご興味のある方には、これは絶対見逃せません!!Oracle OpenWorld Tokyo 2012http://www.oracle.com/openworld/jp-ja/index.html ブラッド・カーライルのセッションは 4/6(金) Develop D3-13 (14:00 - 14:45)六本木アカデミーヒルズ49 にて。 招待コードは 7264 を記載してお申し込みください。

昨年 2011 年 9 月に SPARC T4 CPU とそれを搭載した SPARC T4 サーバーラインナップが発表されました。 過去 SPARC T シリーズといえば、マルチコアかつマルチスレッドで比較的軽いワークロード を大量に処理することを得意としていました。したがって、用途としては、Web 層や アプリケーション層での利用が想定されていました。しかしながら、今度の SPARC T4 はこれ...

Sun

復活!! Oracle Solaris ナイトセミナー # 1

Oracle Solaris 11テクニカル・ディープ・ダイブ第2弾セミナーへ参加頂きありがとうございました。セミナーの中で、Mr.Solaris である大曽根から、Oracle Solaris ナイトセミナーの開催がアナウンスされました!お待たせしました!Oracle Solaris ナイトセミナーの前身である Solaris ナイトセミナーでは、ゆるく楽しく有益に(本当ですよ)をモットーとしていましたが、Oracle Solaris ナイトセミナーでもその精神を忘れずに継続させて行きたいと考えています!また、今回からは色々と試行錯誤しながら、参加者との距離を縮めて行こうということで集客方法をイベント開催支援ツール:ATND(アテンド)にて行います。この方法も実験的ではありますが、まずは、やってみる!ことにしました。経験不足の為、至らない部分があるかもしれませんが、よろしくお願いいたします。Mr. Solaris の下に集う Solaris を愛してやまない中の人たちが、手作りでお届けするセミナーです。さて、第一弾となる「Oracle Solaris ナイトセミナー # 1」は、2012/03/8 (木) 18:30 開催です。第一弾の内容は、昨年行われた「Oracle Solaris 11テクニカル・ディープ・ダイブ第 1 弾」の内容を、ナイトセミナー風にアレンジした、「Oracle Solaris 11テクニカル・ディープ・ダイブ第 1 弾 ナイトセミナー風」となります。よく、わかりませんね。ごめんなさい。セッション 1 は、Solaris エバンジェリストであり Mr. Solaris でもある大曽根が、Solaris の歴史を振り返りながら最新の Solaris 11 を紹介する「Solaris の昨日と今日、そして明日」を。セッション 2 と言いたいのですが、スピーカー本人はその気がなく。。。セミナーのちょっとした息抜きに。と大好評だった「ナイトセミナーでおなじみ! – Solaris 3 分クッキング」!セッション 3 では、外部からスピーカーをお招きしてみました。Solaris 11 だからこそ可能な「省エネ時代のウェブサービスとクラウドの関係」について実例からお話して頂きます!ここまで、読んでしまった方は、参加するしかないよね?というわけで、参加申し込みは下記の ATND でお願い致します!Oracle Solaris ナイトセミナー # 1http://atnd.org/events/25633みなさまのご参加をお待ちしております。あ。。。サブタイトルついてました。。。Solaris 11 深掘り #1の1 です!

Oracle Solaris 11テクニカル・ディープ・ダイブ第2弾セミナーへ参加頂きありがとうございました。 セミナーの中で、Mr.Solaris である大曽根から、Oracle Solaris ナイトセミナーの開催がアナウンスされました! お待たせしました!Oracle Solaris ナイトセミナーの前身である...

Storage

Sun ZFS Storage Appliance 筐体内(ローカル)レプリケーション - LUN

以前紹介した Sun ZFS Storage Appliance の 筐体内でレプリケーションですが、実際には Remote Replication に対する呼び方として local Replication と呼んでいます。前回”筐体内”と紹介しましたが、実はシングルコントローラ構成内だけでなく、クラスタ構成でコントローラヘッド間でレプリケーションすることも可能です。引き続きこの機能について紹介していきますが、今回は iSCSI や Fibre Channel 接続で使う LUN を複製した場合について触れていきたいと思います。ZFS Storage Appliance 内では、LUN を作成するとそれぞれに GUID という個別の ID が割り振られます。このIDは、システム内でユニークである必要があるため、クローンを作成した場合でも、別の ID が割り振られます。レプリケーションの場合はちょっと異なります。ここでは、とりあえずレプリケーションの元を A 、レプリケーション先を B とします。リモートレプリケーションの場合、レプリケーションを構成している間(差分コピーがいつでも送ることができる状態)は、B では GUID が割り振られません。B から A にレプリケーションを戻す(リバースレプリケーション)際に、はじめてGUIDが割り振られ、逆に A のほうの GUID の割り当てがなくなります。もちろん、レプリケーション中であっても、クローンを作成すればそのクローンには別の GUID が割り振られて LUN として使えるようになります。ローカルレプリケーションの場合には、若干動作が異なります。レプリケーションを構成するところまでは一緒なのですが、、リバースレプリケーションをした際に、異なります。そのまま同期をかけると、全て GUID が unknown となり、このままではブロックデバイスとしてホストから使用できません。そこで、先にちょっと触れましたがクローンを使用することで GUID が割り振られますので、これでホストから使うことができるようにします。レプリケーションのターゲット側のクローンを作成します。作成した Clone からレプリケーションを再度構成することも可能です。

以前紹介した Sun ZFS Storage Appliance の 筐体内でレプリケーションですが、実際には Remote Replication に対する呼び方として local Replication と呼んでいます。前回”筐体内”と紹介しましたが、実はシングルコントローラ構成内だけでなく、クラスタ構成でコントローラヘッド間でレプリケーションすることも可能です。引き続きこの機能について紹介し...

Storage

Pillar Axiom 600 搬入風景

Pillar Axiom 600 の搬入に立ち会うことができたので、搬入の様子を紹介します。ラックの木箱です。左上に Pillar と刻印されています。木箱にスロープを取り付けて、取り出すところです。段ボールの中に Brick (ハードディスクや SSD を搭載するトレイ)が入っています。ラックを設置。 Pilot(管理用のサービスプロセッサ的な筐体) と Slammer (ホストと接続する側のコントローラユニット) が搭載されています。Pilot が下にラッキングされています。Brick をラックマウントして、電源を投入した直後の様子。ロゴ部分が点灯しています。システムの状態を示す LED は起動したてのため、点滅中です。(静止画だとわかりませんが)今後、 Private Cloud 対応ストレージの Pillar Axiom についても取り上げていきますので、ご期待ください。

Pillar Axiom 600 の搬入に立ち会うことができたので、搬入の様子を紹介します。 ラックの木箱です。左上に Pillar と刻印されています。 木箱にスロープを取り付けて、取り出すところです。 段ボールの中に Brick (ハードディスクや SSD を搭載するトレイ)が入っています。ラックを設置。 Pilot(管理用のサービスプロセッサ的な筐体) と Slammer...

Storage

Sun ZFS Storage Appliance 筐体内レプリケーション

Sun ZFS Storage Appliance の 2011.1 ファームウェアの新機能の一つになりますが、今回のリリースから筐体内でレプリケーションを構成することができるようになりました。スナップショット/クローンの機能との違いは、簡単にいうとスナップショット/クローンは元のデータのポイントインタイムコピーで、一瞬で作成でき容量としては差分しか消費しませんが、元のデータだけを削除することはできませんレプリケーションは複製を作るため、初期のコピーには容量に応じた時間が必要で、元データと同じように容量を消費しますが、元データを削除しても独立して残しておくことが可能です。更新は従来のレプリケーションと同様、差分のアップデートを手動やスケジュール管理ですることができます。となります。回転数の異なるHDDを使ってデータのライフサイクルを考えた運用をしたり、HDDの世代交代に合わせてデータマイグレーションを行ったりといったことにも使える、便利な機能だと思います。設定方法は至って簡単で、従来からある Remote Replication の設定と手順は全く一緒で、Target にループバックアドレスを設定するだけです。Simulator を使った例を以下に紹介します。まず、Service -> Remote Replication タブから、レプリケーションの設定を開きますこのように、すんなり構成できます。2010.Q3までのファームウェアでは構成できませんでした。Project のレプリケーション設定画面です。ここはいつも通りで、Target に先ほど設定した"local"という名前が選択されています。マニュアルでレプリケーションを実施したところです。ソースとターゲットが両方表示されています。画面上方にもレプリケーションが完了したログがでています。以上、今までレプリケーションを使っていた方でも初めて使う方でも、簡単にセットアップできます。

Sun ZFS Storage Appliance の 2011.1 ファームウェアの新機能の一つになりますが、今回のリリースから筐体内でレプリケーションを構成することができるようになりました。 スナップショット/クローンの機能との違いは、簡単にいうとスナップショット/クローンは元のデータのポイントインタイムコピーで、一瞬で作成でき容量としては差分しか消費しませんが、元のデータだけを削除することは...

Storage

Sun ZFS Storage Appliance アップデート

久しぶりの投稿となる今回は、2011年末から2012年始にかけての Sun ZFS Storage Appliance のアップデートを紹介します。まず、2011年末にファームウェアの最新版 2011.1 がリリースされました。様々な点での性能向上が盛り込まれており、SPC-1 ベンチマークもこのファームウェアを使って計測されています。SPC-1 ベンチマークの詳細については、以下のリンクの Oracle Corporation A00108 SPC-1 の結果をご覧ください。http://www.storageperformance.org/results/benchmark_results_spc1/#oracle_spc1. 今までのファームウェアと同様、今回もZFS Storage Appliance Simulator にもこのアップデートは適用できます。詳細な情報はこちらをご参照ください。リリースノートSoftware Updates マニュアルSun ZFS Storage 7x20 Appliance, Release 2011.1 Documentationまた年明け早々に 3TB のハードディスクドライブが 3 モデル全てでサポートされ、より大容量の構成ができるようになりました。モデル最大物理容量7120177TB7320228TB74201.73PB

久しぶりの投稿となる今回は、2011年末から2012年始にかけての Sun ZFS Storage Appliance のアップデートを紹介します。 まず、2011年末にファームウェアの最新版 2011.1 がリリースされました。 様々な点での性能向上が盛り込まれており、SPC-1 ベンチマークもこのファームウェアを使って計測されています。SPC-1 ベンチマークの詳細については、以下のリンクの...

Sun

ユーザに特権を与える方法

はじめに今回は Solaris 10 の最小特権の仕組みを使用して、ユーザに特権を与える方法をご紹介します。最小特権は、今まで root ユーザに集中していた権限を、必要に応じて一般ユーザに分け与える機能です。非 root ユーザが実行するプログラムでメモリをロックしたい場合や、開発者用アカウントで DTrace を実行させたい場合等、権限を委譲する際に必要となります。 特権を付与する手順それでは早速、ユーザに特権を付与する手順を確認して行きましょう。 特権を付与する対象のユーザ今回特権を付与するユーザはこのように作成した一般ユーザです。 # mkdir /export/home/ # useradd -d /export/home/daleka -m -s /bin/zsh daleka # passwd daleka 現在の特権の確認まずはユーザが現在保持している特権を確認します。使用するコマンドは ppriv <Login Shell PID> です。 # su - daleka % ppriv $$ 1164: -zsh flags = <none> E: basic I: basic P: basic L: allE の欄に表示されているのが現在有効になっている特権です。ここでは basic 特権が設定されています。basic 特権は、幾つかある一般ユーザの基本的な権限をひとまとめにした特権です。続いて、basic 特権の中にどんな特権が含まれているかを調べてみます。basic 特権の内容は ppriv -l basic コマンドで確認することができます。 % ppriv -l basic file_link_any proc_exec proc_fork proc_info proc_session net_accessbasic 特権の中には全部で 6 つの特権が含まれていることが分かりました。それぞれの特権の詳細は ppriv -lv <特権> コマンドで調べることができます。 ppriv -lv proc_fork proc_fork Allows a process to call fork1()/forkall()/vfork()proc_fork はプロセスをフォークさせる特権である事が分かります。ユーザに付与可能な特権の一覧は ppriv -l all で表示することができます。 % ppriv -l all contract_event contract_observer cpc_cpu dtrace_kernel dtrace_proc dtrace_user file_chown file_chown_self file_dac_execute file_dac_read ...(略) proc_audit proc_chroot proc_clock_highres proc_exec proc_fork proc_info proc_lock_memory proc_owner proc_priocntl proc_session proc_setid proc_taskid proc_zone ... (以下略)この様に、沢山の特権が定義されていることが分かります。proc_priocntl は Solaris Container 内で Oracle ASM を動かす際に必要になる特権です。 特権の付与続いて、実際に特権を付与する方法をご紹介します。使用するコマンドは usermod です。ここでは、メモリをロックする際に必要になる proc_lock_memory 特権を付与してみます。 # usermod -K defaultpriv=basic,proc_lock_memory dalekaこのように、元々付与されていた basic 特権の後に、カンマ区切り、空白無しで、新たな特権名を指定して defaultpriv パラメータを設定すると、特権を追加することができます。特権を追加すると /etc/user_attr に変更が反映されます。 # grep daleka /etc/user_attr daleka::::type=normal;defaultpriv=basic,proc_lock_memory特権が付与された事は ppriv コマンドでも確認できます。 # su - daleka % ppriv $$ 1301: -zsh flags = <none> E: basic,proc_lock_memory I: basic,proc_lock_memory P: basic,proc_lock_memory L: all以上で特権付与の手順は完了です。 実験テストプログラムを使用して、特権が正しく有効になっているかを確認してみます。使用するテストプログラムは mlock というコマンドラインプログラムで、この文書の下の方にソースコードを掲載してあります。特権が有効になっているかの確認には ppriv -De コマンドを使用します。mlock プログラムは mlock() 関数を使用してメモリをロックするプログラムです。メモリをロックするには proc_lock_memory 特権が必要になりますが、まずは試しに proc_lock_memory 特権が付いていない状態で実行してみます。 % ppriv -De ./mlock mlock[1726]: missing privilege "proc_lock_memory" (euid = 100, syscall = 131) needed at memcntl+0x14bproc_lock_memory 特権が不足しているというメッセージが表示されました。必要な特権が欠けているため、メモリのロックは失敗してしまいました。なお、メッセージの最後に出力されている memcntl は mlock() 関数の内部で呼び出されるシステムコールです。つづいて、proc_lock_memory 特権を付与してから実行してみます。 # usermod -K defaultpriv=basic,proc_lock_memory daleka # su - daleka % ppriv -De ./mlock今度は必要な特権を全て持っているため、メッセージは何も表示されません。メモリのロックは成功しました。 実験 その 2もう一つの確認方法として truss コマンドを使用する方法もご紹介します。まずは proc_lock_memory 特権が付いていない状態で実行してみます。 % truss -tmemcntl ./mlock ... memcntl(0x08062000, 10, MC_LOCK, 0, 0, 0) Err#1 EPERM [proc_lock_memory]proc_lock_memory 特権が無いので、memcntl システムコールが EPERM エラーになりました。truss コマンドの出力を見ると、proc_lock_memory 特権が付いていないことによるエラーだと分かります。つづいて、proc_lock_memory 特権を持っている状態で実行してみます。 # usermod -K defaultpriv=basic,proc_lock_memory daleka # su - daleka % truss -tmemcntl ./mlock ... memcntl(0x08062000, 10, MC_LOCK, 0, 0, 0) = 0memcntl システムコールが 0 を返してきたので、今度はきちんとロックできました。以上、特権の設定がきちんと効果を発揮していることを確認できました。 テストプログラムこちらが実験で使用した mlock プログラムのソースコードです。 # cat mlock.c /* compile: gcc mlock.c -o mlock */ #include <stdio.h> #include <stdlib.h> #include <sys/mman.h> #define MEMSIZE 10 #define ALI 8192 int main() { int size = MEMSIZE; int align = ALI; caddr_t addr; addr = memalign(align, size); bzero(addr, size); mlock(addr, size); getchar(); munlock(addr, size); } # gcc mlock.c -o mlock 付与した特権を取り除く付与した特権を元に戻すには、元から付与されていた特権のみを指定して usermod コマンドを実行します。 # usermod -K defaultpriv=basic daleka # su - daleka元の通り、basic 特権のみ付与されている事が分かります。 % ppriv $$ 1479: -zsh flags = <none> E: basic I: basic P: basic L: allただし /etc/user_attr のエントリーは消えません。 % grep daleka /etc/user_attr daleka::::type=normal;defaultpriv=basic どんな特権があるか調べたい場合はppriv -lv all で全ての特権とその説明を表示させることができます。 % ppriv -lv all contract_event Allows a process to request critical events without limitation. Allows a process to request reliable delivery of all events on any event queue. contract_observer Allows a process to observe contract events generated by contracts created and owned by users other than the process's effective user ID. Allows a process to open contract event endpoints belonging to contracts created and owned by users other than the process's effective user ID. cpc_cpu Allow a process to access per-CPU hardware performance counters. dtrace_kernel Allows DTrace kernel-level tracing. dtrace_proc Allows DTrace process-level tracing. Allows process-level tracing probes to be placed and enabled in processes to which the user has permissions. ... (以下略) おわりに以上、Solaris の最小特権機能をご紹介しました。この機能を利用して必要な権限だけを委譲する事で、システム全体のセキュリティを保つことができます。更に詳しく調べたい方は マニュアル をご覧下さい。 参考資料http://download.oracle.com/docs/cd/E19253-01/819-0383/prbactm-1/index.htmlhttp://dsc.sun.com/solaris/articles/program_privileges.html

はじめに 今回は Solaris 10 の最小特権の仕組みを使用して、ユーザに特権を与える方法をご紹介します。 最小特権は、今まで root ユーザに集中していた権限を、必要に応じて一般ユーザに分け与える機能です。非 root ユーザが実行するプログラムでメモリをロックしたい場合や、開発者用アカウントで DTrace を実行させたい場合等、権限を委譲する際に必要となります。 特権を付与する手順 それでは...

Sun

Sun Storage 7000 iSCSI 設定方法のご紹介

はじめに今回は、Sun Storage 7000 シリーズ(以下 SS7000) の最新ソフトウェアで、基本的な iSCSI の設定方法についてご紹介いたします。SS7000 の iSCSI 機能は 2009.Q3 で一新され、2010.Q1 で機能拡張がなされています。以下は、リリースノートからの抜粋になります。詳細についてご興味がある方は、リリースノートやマニュアルをご確認いただければと思います。2009.Q3 Enhanced iSCSI support iSCSI management has been enhanced for fine-grained control over target groups and to support multiple LUNs per target. These enhancements have changed the management model for iSCSI LUNs and older configurations will not be migrated. In previous releases, each iSCSI LUN was assigned its own target, and all targets were exported over all network interfaces. In this release, no targets are created by default. Administrators must define targets and target groups and then assign LUNs to those groups. These operations are described in the appliance documentation. LUNs created on earlier releases will be unavailable to iSCSI clients until this configuration update is performed. Target and initiator groups can be configured on the Configuration -> SAN screen. LUNs continue to be managed on the Shares screen.2010.Q1 Multi-interface iSCSI targets iSCSI targets may now be optionally associated with multiple interfaces, allowing for better integration with some multipath initiators.では、本題に入ります。まず、今回使用した環境についてですが、SS7000 側の設定方法を確認する事を目的としたため、実機ではなく次のような環境を使いました。 SS7000 VirtualBox 上の SS7000 シミュレータ ソフトウェアバージョン 2010.Q1 (2010.02.09.0.0,1-1.9) Client Windows XP Professional SP3, Microsoft iSCSI Initiator 2.0次に、大まかな設定の流れですが、おおよそ次のような設定をすれば Client で iSCSI LUN が使えるようになります。SS7000 : iSCSI サービス起動確認SS7000 : iSCSI ターゲットの登録SS7000 : iSCSI イニシエータの登録と LUN 作成SS7000 : 作成された LUN の確認Client : iSCSI LUN の認識とファイルシステムの作成それでは上記の流れで設定方法を見ていきたいと思います。SS7000 : iSCSI サービス起動確認SS7000 で iSCSI の設定をする場合、まず始めに iSCSI サービスが起動されているかを確認しておきます。Configuration -> SERVICES で確認が可能で、下記画面例では Online になっていることが確認出来ます。また、ここでは iSCSI サービスで設定できるプロパティの確認も可能です。今回は環境が用意出来ないので設定はしませんが、ネームサービスとして iSNS サーバや認証システムとして RADIUS サーバを指定出来るようになっています。SS7000 : iSCSI ターゲットの登録ターゲットの登録は、Configuration -> SAN の Targets タブ(画面右上)から行います。登録に最低限必要な情報は、TargetIQN につける Alias 名と LUN をエキスポートする NIC になります。さらに、登録したターゲットを iSCSI Target Groups に設定します。この iSCSI Target Groups は、後に LUN を割り当てる際に使用されます。下記の画面例は、3 つのターゲットを作成した例と iSCSI ターゲット "tgt-grp0" の設定確認画面になります。tgt-grp0 の Target IQN はターゲット登録時に自動的に割り当てることが可能になっており、今回は自動割り当てをしてみました。SS7000 : iSCSI イニシエータの登録と LUN 作成イニシエータの登録は、Configuration -> SAN の Initiators タブ(画面右上)から行います。登録に最低限必要な情報は、Initiator IQN とそれにつける Alias 名になります。Initiator IQN は Client 側で確認する必要があります。下記の画面例では、新規のイニシエータ登録画面になります。イニシエータ登録後、それを iSCSI Initiator Groups に登録し、この iSCSI Initiator Groups と先に設定した iSCSI Target Groups に LUN を作成し割り当てていきます。LUN の作成は、登録したイニシエータグループの右側のアイコンから実行します。SS7000 : 作成された LUN の確認作成された LUN の確認は、Shares メニューの LUN タブで確認することができます。Client : iSCSI LUN の認識とファイルシステムの作成ここまで設定が終われば、あとは Client (イニシエータ)側の作業になります。下記は Microsoft iSCSI Initiator 2.0 の画面ですが、下 2 桁が e4 の iSCSI ターゲットにログオンした状態���す。最初の iSCSI ターゲットを登録した画面で確認できますが、この iSCSI ターゲットは tgt-grp0 で、今回ここには 3 つの 10MB LUN を割り当てておきました。iSCSI LUN が正しく認識されれば、Windows なら ディスクの管理 画面から LUN 上にファイルシステムを構築等してあげれば使えるようになります。

はじめに今回は、Sun Storage 7000 シリーズ(以下 SS7000) の最新ソフトウェアで、基本的な iSCSI の設定方法についてご紹介いたします。 SS7000 の iSCSI 機能は 2009.Q3 で一新され、2010.Q1 で機能拡張がなされています。 以下は、リリースノートからの抜粋になります。詳細についてご興味がある方は、リリースノートやマニュアルをご確認いただければと思い...

Sun

Solaris でハンドアセンブル

はじめに今回は Solaris でハンドアセンブルを行う方法をご紹介します。ハンドアセンブルは、コンピュータの内部で何が行われているのかを勉強するにはとても良い題材ですし、機械語を自在に操るのも面白い体験です。機械語と聞くと難解で面倒だという印象を持たれているかもしれませんが、今回は難しい理屈は抜きで、実際にハンドアセンブルで実行ファイルを生成する例を見て頂きたいと思います。 ndisasmzsh や bash に built-in されている echo コマンドと、NASM の配布物に含まれている ndisasm コマンドを使用すると、気軽にハンドアセンブルの気分を味わう事が出来ます。zsh の echo コマンドには '\\xNN' 形式で指定した 16 進数をバイナリに変換して出力する機能があります。この機能を利用して 16 進数の機械語を入力すると、実際の実行ファイルに含まれている機械語命令と全く同じバイナリ列を生成する事が出来ます。これが最も単純なハンドアセンブルです。ndisasm はディスアセンブラです。ディスアセンブラは、バイナリの機械語命令を読み込んで、人間に理解し易いニーモニックに変換してくれます。ディスアセンブラを使用する事で、ハンドアセンブルが正しく出来ているかを確認する事が出来ます。ndisasm の他にもディスアセンブラは沢山ありますが、ndisasm はデータを標準入力から読み込む機能を持っており、読み込んだデータを何でも x86 の機械語命令と仮定して解釈してくれるので、こういった用途には最適です。試しにハンドアセンブルで nop 命令(何もしない命令)を発行してみましょう。nop 命令を Intel 社のサイトにある "Instruction Set Reference" で引くと、機械語の命令 (Opcode) は 90 番が割り当てられている事が分かります。そこで echo の引数に '\\x90' を 3 つ指定し、ndisasm コマンドに渡してみます。実行結果を見ると、以下の通り、確かに nop が 3 つ続けて出力されました。 # zsh # echo -ne '\\x90\\x90\\x90' | ndisasm -u - <= '\\x90' x3 を ndisasm に渡す 00000000 90 nop <= 正しく nop と認識されました 00000001 90 nop 00000002 90 nopこの様に、実行したい命令があったら、まずマニュアルから Opcode を引く等して機械語の命令を生成します。命令が複数ある場合は単純に続けて記述して下さい。機械語の命令列が完成したら、それを echo コマンドを使ってハンドアセンブルし、ndisasm コマンドでディスアセンブルする事で、正しくハンドアセンブル出来ているかを確認します。 Hello World!!次に定番の Hello World!! をハンドアセンブルで書いてみます。まずは以下の実行例をご覧下さい。 # echo '68210A0000 68726C6421 686F20576F 6848656C6C 8BD4 6A0E FFF2 6A01 6A00 B804000000 CD91 6A00 6A00 B801000000 CD91' | ./hex| ndisasm -u - 00000000 68210A0000 push dword 0xa21 // "!\\n\\0\\0" 00000005 68726C6421 push dword 0x21646c72 // "rld!" 0000000A 686F20576F push dword 0x6f57206f // "o Wo" 0000000F 6848656C6C push dword 0x6c6c6548 // "Hell" 00000014 8BD4 mov edx,esp // save the string address 00000016 6A0E push byte +0xe // arg3 : 14 characters 00000018 FFF2 push edx // arg2 : string address 0000001A 6A01 push byte +0x1 // arg1 : stdout 0000001C 6A00 push byte +0x0 // return address 0000001E B804000000 mov eax,0x4 // 0x4 : write syscall 00000023 CD91 int 0x91 // syscall interuppt 00000025 6A00 push byte +0x0 // arg1 : 0 00000027 6A00 push byte +0x0 // return address 00000029 B801000000 mov eax,0x1 // 0x1 : exit syscall 0000002E CD91 int 0x91 // syscall interuppt今度は echo コマンドに渡す文字列が先ほどより多少長くなりました。機械語の命令を 8bit 毎に '\\x' を付けてエスケープするのが多少大変になって来たので、ここでは 16 進数をバイナリに変換する hex コマンドを作成して使用しています(hex コマンドのソースコードはこの記事の一番最後に載せてあります)。'\\x' を付けない事以外は先ほどの nop の例と基本的に全く同じ手順です。なお、ndisasm の出力のコメント部分は解説の為に後から付け加えた物です。それでは、上から順番に機械語の命令を追って行きたいと思います。冒頭の '68210A0000 68726C6421 686F20576F 6848656C6C' の部分は出力する文字列 ("Hello World!!" + \\n) をスタックに積む命令です。16 進数の 68 は push 命令で、直後にある 32bit 分のデータをスタックに積むという動作を行います。ここでは、'68210A0000' は 68 が push 命令で、続く 210A0000 がデータという事になります。スタックなので文字列の後ろ側から先に積んでおり、最後に "Hell" という文字列がスタックに積まれます。次の '8BD4' は、今スタックに積んだ文字列のアドレスを一時退避しています。退避したアドレスは後で使用します。8B は mov 命令の一部で、8BD4 でスタックポインタを EDX レジスタに保存するという動きになります。'6A0E' は write システムコールの第 3 引数(出力する文字数)をスタックに積んでいます。6A も push 命令です。68 の場合と違い、後続の 8 bit をスタックに積む働きをします。ここでは 0E (10 進数で 14) がスタックに積まれます。積まれたデータは 32bit 幅になります。続いて、'FFF2' で write システムコールの第 2 引数(出力する文字列のアドレス)をスタックに積んでいます。これが先ほど退避したアドレスです。FF も push 命令の一部で、FFF2 は EDX レジスタの中身をスタックに積む命令です。その次の '6A01' は write システムコールの第 1 引数(出力先)を標準出力に設定しています。続く '6A00' はダミーです。'B804000000' は write システムコールを発行する準備をしています。B8 は mov 命令で、後続の 32bit 分のデータを EAX レジスタに格納します。ここで EAX に格納している数値は 4 ですが、これは write システムコールのシステムコール番号です。システムコール番号は /usr/include/sys/syscall.h にあります。最後に 'CD91' で int 0x91 を実行して write システムコールを呼び出しています。x86 Solaris のシステムコール呼び出しは syscall 命令 (AMD) と sysenter 命令 (Intel) を /usr/lib/libc/libc_hwcapN.so.1 の lofs マウント で切り替える様に実装されていますが、この例の様に int 0x91 を使って行う事も可能です。int 0x91 を使用すると AMD/Intel 両方の CPU で動作するコードになります。その後は、同じ様に exit システムコールを呼び出してプログラムを終了させています。以上、たった 15 個の命令だけで Hello World!! という文字列を出力する事が出来ました。ここで使用した命令は全て先ほどの Intel 社のマニュアルに記載されていますので、全てを憶える必要はありません。 実行可能な形式にするここまでご紹介した手順だけではまだ実行可能なプログラムは作成出来ません。もう一工夫加えて、実際に Solaris 上で実行出来るプログラムを作成してみましょう。コマンドとして実行可能なプログラムにするには機械語の列を ELF 形式のファイルにまとめる必要があります。文末に掲載した has.c をコンパイルして、以下の様に実行してみて下さい。 # echo '68210A0000 68726C6421 686F20576F 6848656C6C 8BD4 6A0E FFF2 6A01 6A00 B804000000 CD91 6A00 6A00 B801000000 CD91' | ./has > hello # chmod +x hello # ./hello Hello World!!先ほどと同じ機械語の命令列から、Hello World!! と出力するプログラムが実際に作成出来た事が分かります。has コマンドは 16 進数の機械語をバイナリに変換して、実行形式として出力するプログラムです。先ほどの hex コマンドとの違いは、機械語の命令列に ELF ファイルに必要な ELF ヘッダとプログラムヘッダを付加している点だけです。Hello World!! を出力するだけの単純なプログラムであれば、この様に簡単な仕組みだけで作成する事が可能になっています。 日本語への対応ハンドアセンブルでももちろん日本語を表示する事が可能です。ついでにある程度のランダム性も追加して、おみくじコマンドを作成してみました。 # echo '0F31 31D2 BB05000000 F7F3 83FA00 7511 6890890A00 68E5A4A7E5 89E3 6A08 53 EB47 83FA01 750C 68E590890A 89E3 6A04 53 EB36 83FA02 7511 6890890A00 68E4B8ADE5 89E3 6A08 53 EB20 83FA03 7511 6890890A00 68E5B08FE5 89E3 6A08 53 EB0A 68E587B60A 89E3 6A04 53 6A01 6A00 B804000000 CD91 6A00 6A00 B801000000 CD91' | ./has > omikuji # chmod +x omikuji # while :; do echo -n "本日の運勢は: "; ./omikuji; sleep 1; done 本日の運勢は: 中吉 本日の運勢は: 大吉 本日の運勢は: 凶 本日の運勢は: 大吉 本日の運勢は: 大吉先ほどと比べるとプログラムがだいぶ長くなり、使用している命令の数も増えています。中身の詳しい説明は省きますが、Hello World!! の時と大きく異なるのは、現在時刻に応じて処理の内容を変えている事です。現在時刻は rdtsc 命令で取得しています。それを div 命令で割り算し、余りの数値を cmp 命令で条件と比較し、jnz 命令で実行したいコードに飛んでいます。コメントを振っておきましたので、マニュアルと付き合わせて機械語の成り立ちを調べてみて下さい。 # echo '0F31 31D2 BB05000000 F7F3 83FA00 7511 6890890A00 68E5A4A7E5 89E3 6A08 53 EB47 83FA01 750C 68E590890A 89E3 6A04 53 EB36 83FA02 7511 6890890A00 68E4B8ADE5 89E3 6A08 53 EB20 83FA03 7511 6890890A00 68E5B08FE5 89E3 6A08 53 EB0A 68E587B60A 89E3 6A04 53 6A01 6A00 B804000000 CD91 6A00 6A00 B801000000 CD91' | ./hex | ndisasm -u - 00000000 0F31 rdtsc // 時刻を計測 00000002 31D2 xor edx,edx 00000004 BB05000000 mov ebx,0x5 // 割る数 : 5 00000009 F7F3 div ebx // 時間を 5 で割る 0000000B 83FA00 cmp edx,byte +0x0 // 割った余りが 0 か? 0000000E 7511 jnz 0x21 // 違うなら 0x21 へジャンプ 00000010 6890890A00 push dword 0xa8990 // "大吉" 続き 00000015 68E5A4A7E5 push dword 0xe5a7a4e5 // "大吉" 前半 0000001A 89E3 mov ebx,esp // 文字列のアドレスを保存 0000001C 6A08 push byte +0x8 // arg2 : 文字数 : 8 0000001E 53 push ebx // arg1 : 文字列のアドレス 0000001F EB47 jmp short 0x68 // 0x68 へジャンプ 00000021 83FA01 cmp edx,byte +0x1 // 割った余りが 1 か? 00000024 750C jnz 0x32 // 違うなら 0x32 へジャンプ 00000026 68E590890A push dword 0xa8990e5 // "吉" 0000002B 89E3 mov ebx,esp // 文字列のアドレスを保存 0000002D 6A04 push byte +0x4 // arg2 : 文字数 : 4 0000002F 53 push ebx // arg1 : 文字列のアドレス 00000030 EB36 jmp short 0x68 // 0x68 へジャンプ 00000032 83FA02 cmp edx,byte +0x2 // 以下同... 00000035 7511 jnz 0x48 00000037 6890890A00 push dword 0xa8990 0000003C 68E4B8ADE5 push dword 0xe5adb8e4 00000041 89E3 mov ebx,esp 00000043 6A08 push byte +0x8 00000045 53 push ebx 00000046 EB20 jmp short 0x68 00000048 83FA03 cmp edx,byte +0x3 0000004B 7511 jnz 0x5e 0000004D 6890890A00 push dword 0xa8990 00000052 68E5B08FE5 push dword 0xe58fb0e5 00000057 89E3 mov ebx,esp 00000059 6A08 push byte +0x8 0000005B 53 push ebx 0000005C EB0A jmp short 0x68 0000005E 68E587B60A push dword 0xab687e5 00000063 89E3 mov ebx,esp 00000065 6A04 push byte +0x4 00000067 53 push ebx 00000068 6A01 push byte +0x1 // arg1 : 出力先 : stdout 0000006A 6A00 push byte +0x0 // return address 0000006C B804000000 mov eax,0x4 // 0x4 : write syscall 00000071 CD91 int 0x91 // syscall interrupt 00000073 6A00 push byte +0x0 // arg1 : 0 00000075 6A00 push byte +0x0 // return address 00000077 B801000000 mov eax,0x1 // 0x1 : exit syscall 0000007C CD91 int 0x91 // syscall interruptなお、日本語の文字列に関しても特殊な事はしていません。ただ単に文字列を 16 進数に直して使用しているだけです。日本語の文字列の 16 進数表現は od コマンドで調べる事が出来ます。 # echo "吉" | od -x 0000000 90e5 0a89 0000004 おわりに以上、実行形式のファイルをハンドアセンブルで作成する方法をご紹介しました。ハンドアセンブルは、知っている人はとてつもなく深く知っており、コンピュータを理解する上でもとても役に立ちますが、知らない人は全く知らない、どこから手を付けていいかもよく分からない様な話だと思います。今回は、自分が新入社員だった頃にこんな記事があったらなあと思い、ご紹介させて頂きました。皆さんのご参考になれば幸いです。 使用したプログラム ndisasm のインストール # wget http://www.nasm.us/pub/nasm/releasebuilds/2.08.01/nasm-2.08.01.tar.bz2 # gtar jxf nasm-2.08.01.tar.bz2 # cd nasm-2.08.01 # ./configure # gmake && gmake install Hand Assemble Assistant by C /\* \* Usage: \* # gcc has.c -o has \* # echo -n 6A00 B801000000 0F05 | ./has > foo \* # chmod +x foo \* # ./foo \*/ #include <stdio.h> #include <sys/elf.h> #define PROGRAM_SIZE 2048 int main() { int size = 0; unsigned char prog[PROGRAM_SIZE] = {0}; unsigned int ehdr_size = sizeof(Elf32_Ehdr); unsigned int phdr_size = sizeof(Elf32_Phdr); Elf32_Ehdr ehdr = { {ELFMAG0, ELFMAG1, ELFMAG2, ELFMAG3, ELFCLASS32, ELFDATA2LSB, EV_CURRENT}, ET_EXEC, EM_386, EV_CURRENT, 0x8050000 + ehdr_size + phdr_size, // e_entry ehdr_size, // e_phoff 0, // e_shoff 0, // e_flags ehdr_size, // e_ehsize phdr_size, // e_phentsize 1, // e_phnum 0, // e_shentsize 0, // e_shnum SHN_UNDEF // e_shstrndx }; // 52bytes Elf32_Phdr phdr = { PT_LOAD, // p_type 0, // p_offset 0x8050000, // p_vaddr NULL, // p_paddr 0, // p_filesz 0, // p_memsz PF_R + PF_W + PF_X, // p_flags 0x10000 // p_align }; // 32bytes int c, nibble = 0; while(1) { if(size >= PROGRAM_SIZE) { perror("input too large."); break; } c = fgetc(stdin); if(c == EOF) { break; } else if(('0' <= c) && (c <= '9')) { if(nibble == 0) { prog[size] = (c - 48) << 4; nibble = 1; } else { prog[size] += c - 48; size++; nibble = 0; } } else if(('A' <= c) && (c <= 'F')) { if(nibble == 0) { prog[size] = (c - 55) << 4; nibble = 1; } else { prog[size] += c - 55; size++; nibble = 0; } } else if(('a' <= c) && (c <= 'f')) { if(nibble == 0) { prog[size] = (c - 87) << 4; nibble = 1; } else { prog[size] += c - 87; size++; nibble = 0; } } } phdr.p_filesz = phdr.p_memsz = size + ehdr_size + phdr_size; write(1, &ehdr, ehdr_size); write(1, &phdr, phdr_size); write(1, prog, size); exit(0); } Hex to Binary by C /\* \* Usage: \* # gcc hex.c -o hex \* # echo -n 48656c6c6f | ./hex > foo \* # od -c foo \*/ #include <stdio.h> int main() { int c, out, hasdata = 0; while(1) { c = fgetc(stdin); if(c == EOF) { if(hasdata == 1) { fputc(out, stdout); } break; } else if(('0' <= c) && (c <= '9')) { if(hasdata == 0) { out = (c - 48) << 4; hasdata = 1; } else { out += c - 48; fputc(out, stdout); out = 0; hasdata = 0; } } else if(('A' <= c) && (c <= 'F')) { if(hasdata == 0) { out = (c - 55) << 4; hasdata = 1; } else { out += c - 55; fputc(out, stdout); out = 0; hasdata = 0; } } else if(('a' <= c) && (c <= 'f')) { if(hasdata == 0) { out = (c - 87) << 4; hasdata = 1; } else { out += c - 87; fputc(out, stdout); out = 0; hasdata = 0; } } } }

はじめに 今回は Solaris でハンドアセンブルを行う方法をご紹介します。ハンドアセンブルは、コンピュータの内部で何が行われているのかを勉強するにはとても良い題材ですし、機械語を自在に操るのも面白い体験です。機械語と聞くと難解で面倒だという印象を持たれているかもしれませんが、今回は難しい理屈は抜きで、実際にハンドアセンブルで実行ファイルを生成する例を見て頂きたいと思います。 ndisasm zsh...

Sun

Sun Fire X2270 M2 が発表されました

今回は、今月発表したローエンド X64 サーバ Sun Fire X2270 M2 に関して少し掘り下げてみます。まず、Sun Fire X2270 M2 は、今まで販売していた M2 無しの Sun Fire X2270 と比較して、見た目は右上のロゴが新しく変わっている事以外同じです。全面の 4 つある内蔵ディスクベイには、2TB SATA HDD と、 32GB SSD が搭載可能です。Sun Fire X2270 からの変更ポイントは、まず心臓部の CPU が Intel Xeon 5500 番台 から 5600 番台になった事です。サポート CPU 一覧6 - Core CPU モデルIntel Xeon Model X5670 @ 2.93GHzIntel Xeon Model X5660 @ 2.8GHz4 - Core CPU モデルIntel Xeon Model E5620 @ 2.4GHz6 コアモデルの CPU を搭載すると、高さ 1U の筐体で最大 2 ソケット/ 12 コア/ 24 スレッドの構成が可能です。さらに、ユニークなポイントとして、Sun Fire X2270 M2 は、ラックマウント型サーバでは初めてフラッシュモジュールが 2 枚挿入でるようになりました。 このフラッシュモジュールは、一見、メモリモジュールのように見えますが、インストールすると OS からは 24GB 容量の SATA I/F Disk として認識され、IOPS 性能に優れたストレージデバイスとして使用できます。(ちなみに、このフラッシュモジュールは、F5100 でも使用されております。)I/O 性能が求められるストレージ領域に対して、サーバ全面のディスクスロットに SSD を挿入するのもよいですが、フラッシュモジュールはディスクスロットのトレードオフ無しに高速 I/O デバイスを使用できるメリットがあります。詳細な情報は、下記を参照下さい。"Sun Fire X2270 M2 Server Architecture" http://www.oracle.com/us/products/servers-storage/servers/x86/sun-fire-x2270-m2-wp-070254.pdf(参考情報)過去の 「やっぱり Sun がスキ!」blog 記事一覧はこちらを参照下さい。http://wikis.sun.com/display/yappri/Home

今回は、今月発表したローエンド X64 サーバ Sun Fire X2270 M2 に関して 少し掘り下げてみます。 まず、Sun Fire X2270 M2 は、今まで販売していた M2 無しの Sun Fire X2270 と 比較して、見た目は右上のロゴが新しく変わっている事以外同じです。全面の 4 つある内蔵ディスクベイには、2TB SATA HDD と、 32GB SSD...

Sun

ローカルゾーン上での特権 sys_time の設定例

今回は、Solaris ゾーン(non-global zone)上でシステムの時刻を変更することについて考えてみます。デフォルトではシステムの時刻設定はグローバルゾーン上で行いますが、Solaris ゾーン上で同じ事が出来るでしょうか。もしそれが出来れば、インタネット上の NTP サーバ と時刻を同期するのにグローバルゾーンを隠す一つの方法になると思います。Solaris ゾーンでは、特権(privilege)の割り当てにより、ゾーン上で使用されるリソースを制限しています。例えば、今回の場合ではシステム時刻を変更するには、sys_time 特権が必要となります。Solaris のシステム管理 (Solaris コンテナ : 資源管理と Solaris ゾーン)を確認すると、この sys_time 特権は Solaris ゾーン内の状態は「任意」です。これは、個別に Solaris ゾーンへ指定することが可能なことを意味します。また、sys_time 特権の内容は次のようにして確認することが可能です。global# ppriv -lv sys_timesys_time 適切なシステムコール (stime、adjtime、ntp_adjtime) と x86 固有の RTC 呼び出しのいずれかを使用して、システム時刻を操作できるように します。それでは実際に sys_time 特権を Solaris ゾーンへ割り当ててみます。デフォルトでは sys_time 特権は Solaris ゾーンに割り当てられていませんので、時刻を変更しようとするとエラーとなります。下記の例では、ppriv(1M) コマンドを使用して特権の不足も合わせて確認しています。ppriv(1M) コマンドがない場合は最初の一行目は出力されません。global# ppriv -l zone | grep sys_time

今回は、Solaris ゾーン(non-global zone)上でシステムの時刻を変更することについて考えてみます。 デフォルトではシステムの時刻設定はグローバルゾーン上で行いますが、Solaris ゾーン上で同じ事が出来るでしょうか。もしそれが出来れば、インタネット上の NTP サーバ と時刻を同期するのにグローバルゾーンを隠す一つの方法になると思います。Solaris ゾーンでは、特権(pri...

Sun

Real Time スケジューラで動作する Zone の設定方法

前回、Solaris ゾーン上の CPU リソースは FSS(Fair Share Scheduler) でスケジューリングされる説明をしましたが、今回は、任意のゾーンに対するスケジューリングクラスを FSS 以外に変更する方法を紹介します。ゾーンのスケジューリングクラスをデフォルトの FSS から変更する為には、対象となるゾーンが使用する CPU プールの pool.scheduler プロパティーに有効なスケジューリングクラスを設定します。それでは早速、RT(Real Time Scheduler)で動作するゾーンを作成してみましょう。具体的には、zonecfg の scheduling-class プロパティーを使ってゾーンのスケジューリングクラスを設定します。今回は、CPU プールを作成する手間を省く為、ゾーン起動時に自動でプールを構成する dedicated-cpu プロパティをゾーンに設定しました。下記の例は、ゾーン名 real-zone に、2 CPU 分の CPU プールを割り当て、scheduling-class を RT で定義しております。# zonecfg -z real-zonereal-zone: そのような構成済みゾーンはありません'create' を使用して、新しいゾーンの構成を開始してください。zonecfg:real-zone> createzonecfg:real-zone> set zonepath=/export/zone/real-zonezonecfg:real-zone> add dedicated-cpuzonecfg:real-zone:dedicated-cpu> set ncpus=2zonecfg:real-zone:dedicated-cpu> endzonecfg:real-zone> set scheduling-class=RTzonecfg:real-zone> verifyzonecfg:real-zone> commitzonecfg:real-zone> exit# zoneadm -z real-zone installPreparing to install zone .Creating list of files to copy from the global zone....The file contains a log of the zone installation.# zoneadm -z real-zone bootこれでゾーンのスケジューリングクラスを RT に設定したゾーンが作成できました。現在、検証環境では、下記のように FSS で動作する zone01 と、RT で動作する real-zone が稼働しております。# zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / native shared 1 zone01 running /export/zone/zone01 native shared 2 real-zone running /export/zone/real-zone native sharedpoolstat コマンドで、プールの状態 (real-zone 用にプールが作成されている事) を確認します。# poolstat pset id pool size used load 1 SUNWtmp_real-zone 2 0.00 0.00 0 pool_default 2 0.00 0.00次に、各ゾーン内で priocntl -d にて起動されるプロセスのスケジューリングクラスを確認します。zone01# priocntl -dTIME SHARING PROCESSES: PID TSUPRILIM TSUPRI 6487 0 0real-zone# priocntl -dREAL TIME PROCESSES: PID RTPRI TQNTM TQSIG 6484 0 1000 0今度は実際に各ゾーンに負荷をかけ、起動するプロセスのスケジューリングクラスを確認してみます。今回、zone01 と real-zone それぞれで CPU に負荷をかける nspin を実行した結果が下記となります。zone01 では、PID 6522 と 6523、real-zone では、PID 6524 と 6525 が起動しております。# ps -efl -o pid,zone,comm | grep nspinx の結果6523 zone01 ./nspinx6522 zone01 ./nspinx6524 real-zone ./nspinx6525 real-zone ./nspinxprstat -z の結果より、PRI を確認すると、real-zone で実行しているプロセスの PRI が 60 より大きいので、RT でスケジューリングされている事が確認できます。prstat -z の結果 PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP6525 root 1344K 540K cpu0 100 - 0:01:53 25% nspinx/16524 root 1344K 672K cpu1 100 - 0:01:53 25% nspinx/16522 root 1344K 672K cpu3 20 0 0:01:57 25% nspinx/16523 root 1344K 540K run 20 0 0:01:57 25% nspinx/1........ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE 2 14 17M 20M 0.2% 0:03:59 50% real-zone 1 14 22M 25M 0.3% 0:03:58 50% zone01 0 52 173M 256M 3.2% 0:01:13 0.0% globalTotal: 80 processes, 312 lwps, load averages: 4.92, 5.53, 2.86ご参考で、各スケジューリングクラスに割り当たる PRI 番号は下記コマンドで確認できます。# priocntl -lCONFIGURED CLASSES==================SYS (System Class)TS (Time Sharing) Configured TS User Priority Range: -60 through 60FX (Fixed priority) Configured FX User Priority Range: 0 through 60IA (Interactive) Configured IA User Priority Range: -60 through 60FSS (Fair Share) Configured FSS User Priority Range: -60 through 60RT (Real Time) Maximum Configured RT Priority: 59(補足情報)今回、Real Time スケジューラで動作するゾーンを紹介しましたが、Real Time スケジューラで動作するゾーンでは、FSS 制御下で動作するプロパティ( cpu-share や capped-cpu ) が制御できませんので設計時に注意が必要です。(参考資料)ゾーンのスケジューリングクラス http://docs.sun.com/app/docs/doc/819-0385/gepst?l=ja&a=view (参考情報)過去の 「やっぱり Sun がスキ!」blog 記事一覧はこちらを参照下さい。http://wikis.sun.com/display/yappri/Home

前回、 Solaris ゾーン上の CPU リソースは FSS(Fair Share Scheduler) でスケジューリングされる 説明をしましたが、今回は、任意のゾーンに対するスケジューリング クラスを FSS 以外に変更する方法を紹介します。 ゾーンのスケジューリングクラスをデフォルトの FSS から変更する為には、対象となるゾーンが使用する CPU プールの pool.scheduler...

Sun

dispadmin コマンドの紹介

今回は、プロセスが使用するスケジューラを変更するコマンド dispadmin を紹介します。このコマンドはあまり馴染みがないかも知れませんが、Solaris コンテナで Zoneのリソース制御を行う時に重要なコマンドとなります。Solaris コンテナ上の CPU リソース制御は、FSS(Fair Share Scheduler)を使用しますが、Solaris 10 初期インストールの状態では、スケジューラが FSS をデフォルトで使用する設定になっておりません。その為、zonecfg コマンドで cpu-shares プロパティを設定した Zone を起動すると下記ワーニングメッセージが出力されます。(今回は、Solaris 10 10/09 で検証しております。)# zoneadm -z zone01 bootzoneadm: zone 'zone01': 警告: zone.cpu-shares 資源制御が設定されていますが、zoneadm: zone 'zone01': FSS はこのゾーンのデフォルトのスケジューリングクラスzoneadm: zone 'zone01': ではありません。FSS はゾーン内のプロセスに使用されますが、zoneadm: zone 'zone01': FSS の利点を十分に得るために、FSS をzoneadm: zone 'zone01': デフォルトのスケジューリングクラスにするようにしてください。zoneadm: zone 'zone01': 詳細は、dispadmin(1M) を参照してください。CPU リソース制御プロパティは、FSS の管理下で制御を行いますので、デフォルトのスケジューリングクラスに FSS が設定されていないとワーニングが出てしまいます。ワーニングメッセージを出さないよう FSS をデフォルトのスケジューリングクラスに設定するには、下記設定を行います。まずは、現在のデフォルトスケジューラを確認してみましょう。# dispadmin -ddispadmin: Default scheduling class is not setSolaris 10 の初期インストール状態では、デフォルトスケジューラは何も設定されていない事が確認できます。それでは、デフォルトスケジューラを FSS に設定してみましょう。# dispadmin -d FSSこれで設定が完了しました。最後にデフォルトスケジューラに FSS が設定できたか確認してみましょう。# dispadmin -dFSS (Fair Share)----FSS の設定が完了しましたので、もう一度 Zone を起動してみます。# zoneadm -z zone01 bootzone01 起動時にワーニング出力が消えました。ちなみに、dispadmin でデフォルトのスケジューラを設定すると、下記内容のファイルが /etc/dispadmin.conf に作成されます。# cat dispadmin.conf## /etc/dispadmin.conf## Do NOT edit this file by hand -- use dispadmin(1m) instead.#DEFAULT_SCHEDULER=FSSZone のリソース制御が思うように動作しない場合、一度 dispadminの設定を確認する事をお勧めします。(参考情報)過去の 「やっぱり Sun がスキ!」blog 記事一覧はこちらを参照下さい。http://wikis.sun.com/display/yappri/Home

今回は、プロセスが使用するスケジューラを変更するコマンド dispadmin を 紹介します。 このコマンドはあまり馴染みがないかも知れませんが、Solaris コンテナで Zone のリソース制御を行う時に重要なコマンドとなります。 Solaris コンテナ上の CPU リソース制御は、FSS(Fair Share Scheduler)を使用しますが、Solaris 10...

Sun

システムコール番号の再利用の仕組み

はじめに先日、OpenSolaris からシステムコールが幾つか削除されました。b135 以降の syscall.h からは wait, creat, exec, utime, dup, fork(forkall) 等が無くなっています。システムコール番号 2 番には fork(又は forkall) が割り当てられていましたが、現在は空き番号となっています。また、48 番の signal システムコールも b128 で同じ様に削除されています。こういったシステムコール番号の変更は頻繁に起きる訳では有りませんが、Solaris では過去にも何度かシステムコールの削除と番号の再利用が行われています。もちろん現役で使用されているシステムコールがいきなり消える事はありませんし(今回削除された物も長い間使われていなかったシステムコールです)、creat や fork のシステムコールが削除されたからと言って creat(2) や fork(2) 等のシステムコール関数が呼び出せなくなる訳では有りません。Solaris が以前より重視して来た ABI の互換性はきちんと保たれています。今回はこの辺りのシステムコール関数とシステムコールの関係をご紹介したいと思います。 システムコール番号まずはシステムコール番号がどの様に設定されているのかを見てみましょう。システムコール番号は sysent.c の中の sysent[] テーブルの中で管理されています。sysent[] 配列の添字がそのままシステムコール番号に対応しています。例えば、write システムコールの番号は 4 番なので、sysent[4] には write システムコールを指定する記述 -- SYSENT_CL("write", write, 3) -- が入っています。sysent[] テーブルの中の (was ...) とコメントされているエントリは、削除されたシステムコールです。2 番の forkall や 7 番の wait は SYSENT_LOADABLE() になっており、特定のシステムコールには使用されていない事が分かります。 415 struct sysent sysent[NSYSCALL] = 416 { 417 /\* ONC_PLUS EXTRACT END \*/ 418 /\* 0 \*/ IF_LP64( 419 SYSENT_NOSYS(), 420 SYSENT_C("indir",indir,1)), 421 /\* 1 \*/ SYSENT_CI("exit",rexit,1), 422 /\* 2 \*/ SYSENT_LOADABLE(),/\* (was forkall) \*/ 423 /\* 3 \*/ SYSENT_CL("read",read,3), 424 /\* 4 \*/ SYSENT_CL("write",write,3), 425 /\* 5 \*/ SYSENT_CI("open",open,3), 426 /\* 6 \*/ SYSENT_CI("close",close,1), 427 /\* 7 \*/ SYSENT_LOADABLE(),/\* (was wait) \*/ 428 /\* 8 \*/ SYSENT_LOADABLE(),/\* (was creat) \*/ 429 /\* 9 \*/ SYSENT_CI("link",link,2), 430 /\* 10 \*/ SYSENT_CI("unlink",unlink,1), 431 /\* 11 \*/ SYSENT_LOADABLE(),/\* (was exec) \*/ ...((http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/sysent.c))syscall.h にも sysent[] で振られたシステムコール番号と同じ番号が定義されています。これを include する事で、他のプログラムからもシステムコール番号を利用する事が出来ます。こちらも sysent.c と同様、2, 7, 8, 11 番のシステムコール番号は空いています。 50 #defineSYS_syscall0 51 #defineSYS_exit1 52 #defineSYS_read3 53 #defineSYS_write4 54 #defineSYS_open5 55 #defineSYS_close6 56 #defineSYS_link9 57 #defineSYS_unlink10 58 #defineSYS_chdir12((http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/syscall.h))syscall.h の変更履歴を見てみると、確かに creat 等が削除されている事が分かります。 ... 12 @@ -49,16 +49,12 @@ 13 14 #defineSYS_syscall0 15 #defineSYS_exit1 16 -#defineSYS_forkall2 17 #defineSYS_read3 18 #defineSYS_write4 19 #defineSYS_open5 20 #defineSYS_close6 21 -#defineSYS_wait7 22 -#defineSYS_creat8 23 #defineSYS_link9 24 #defineSYS_unlink10 25 -#defineSYS_exec11 ...((http://hg.genunix.org/onnv-gate.hg/diff/1e7f1f154004/usr/src/uts/common/sys/syscall.h)) システムコールの数次にシステムコール番号の上限について見てみます。システムコールの最大数は NSYSCALL マクロで設定されています。sysent[] の要素数も NSYSCALL が指定されています。現時点では NSYSCALL は 256 に設定されているので、最大 256 個のシステムコールを登録する事が出来る事になります。 347 #defineNSYSCALL 256/\* number of system calls \*/((http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/systm.h#347))256 個に入りきらなかったシステムコールは、複数のシステムコールが一つのシステムコールに統合されます。以下の例では msyget, msgctl, msgrcv, msgsnd, msgids, msgsnap が SYS_msgsys にまとめられています。msgsys() の第 1 引数に 0 を指定して呼び出すと、msgget() に分岐するという仕組みです。 100 #defineSYS_msgsys49 101 /\* 102 \* subcodes: 103 \*msgget(...) :: msgsys(0, ...) 104 \*msgctl(...) :: msgsys(1, ...) 105 \*msgrcv(...) :: msgsys(2, ...) 106 \*msgsnd(...) :: msgsys(3, ...) 107 \*msgids(...) :: msgsys(4, ...) 108 \*msgsnap(...) :: msgsys(5, ...) 109 \*see <sys/msg.h> 110 \*/((http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/syscall.h)) システムコール関数最後に、システムコール関数がどのように実装されているのか、ここでは特に同名のシステムコールが用意されていないシステムコール関数について見てみたいと思います。fork(2) の様に、システムコールを管理している sysent[] に fork という同名のシステムコールが無い(無くなってしまった)場合です。 415 struct sysent sysent[NSYSCALL] = 416 { 417 /\* ONC_PLUS EXTRACT END \*/ 418 /\* 0 \*/ IF_LP64( 419 SYSENT_NOSYS(), 420 SYSENT_C("indir", indir, 1)), 421 /\* 1 \*/ SYSENT_CI("exit", rexit, 1), 422 /\* 2 \*/ SYSENT_LOADABLE(), /\* (was forkall) \*/ <== 無い… 423 /\* 3 \*/ SYSENT_CL("read", read, 3),((http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/sysent.c))まずは fork(2) のソースコードから実装を追い掛けてみます。libc の scalls.c にある fork(2) の実装を見てみると、forkx() を呼び出しているだけの様です。 274 pid_t 275 fork(void) 276 { 277 return (forkx(0)); <== ここ 278 }((http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/scalls.c#fork))fork(2) が呼び出していた forkx() は更に __forkx() を呼び出しています。 161 if (udp->uberflags.uf_mt) { 162 errno = ENOTSUP; 163 return (-1); 164 } 165 pid = __forkx(flags); <== ここ 166 if (pid == 0) {/\* child \*/ 167 udp->pid = getpid(); 168 self->ul_vfork = 0; 169 } 170 return (pid);((http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/scalls.c#forkx))__forkx() は SYSTRAP_2RVALS(forksys) の呼び出しになっています。SYSTRAP_2RVALS() はマクロです。 44 ENTRY(__forkx) 45 movl%edi, %esi 46 xorl%edi, %edi 47 SYSTRAP_2RVALS(forksys) <== ここ 48 SYSCERROR 49 testl%edx, %edx 50 jz1f/\* jump if parent \*/ 51 xorl%eax, %eax/\* child, return (0) \*/((http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/sys/forkx.s#44))x86_64 環境では、SYSTRAP_2RVALS() は一旦 __SYSCALL() に変換され、__SYSCALL() マクロの中で syscall 命令を使ってシステムコールを実行しています。また、__SYSCALL() マクロの中の $SYS_/\*\*/name の name の部分には SYSTRAP_2RVALS() に渡された引数が入るため、展開されると $SYS_forksys になります。結果的に、このコードは %eax に $SYS_forksys を設定し、syscall 命令でカーネルを呼び出している事になります。 54 #define__SYSCALL(name)\\ 55 movq%rcx, %r10;\\ 56 /\* CSTYLED \*/\\ 57 movl$SYS_/\*\*/name, %eax;\\ 58 syscall ... 62 #defineSYSTRAP_2RVALS(name)__SYSCALL(name)((http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/inc/SYS.h))以上、fork というシステムコールは無くなってしまいましたが、他の関数 (forkx()) と別名のシステムコール (SYS_forksys) を経由してカーネルを呼び出している事が分かりました。fork(2) 以外のシステムコール関数も、creat(2) が SYS_openat システムコールを使ってカーネルを呼び出している等、同様の仕組みで実装されています。fork や creat 等のシステムコールが無くなっても fork(2) や creat(2) が問題無く動くのは、この様に内部で別のシステムコールを使用して実装されている為です。 おわりに今回は、OpenSolaris でシステムコールが削除された事、システムコールが削除されてもバイナリ互換は崩れない事、削除されたシステムコールに対応するシステムコール関数がどの様に実装されているかをご紹介しました。更に深く知りたい方向けに関連情報をまとめておきましたので、ご参照下さい。 関連情報 今回のシステムコールの削除は [PSARC/2009/657] で提案されました。提案理由や議論の経緯等も公開されています。http://arc.opensolaris.org/caselog/PSARC/2009/657/mail こちらが syscall.h です。システムコール番号に変更が有れば、必ずこのファイルにも反映されます。http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/syscall.h syscall.h の変更履歴です。過去にも様々な変更が加わっている事が分かります。http://hg.genunix.org/onnv-gate.hg/log/bcacc803343d/usr/src/uts/common/sys/syscall.h /etc/name_to_sysnum にもシステムコール番号が記録されています。http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/os/name_to_sysnum OpenSolaris のプロジェクトの履歴です。Build 135 で PSARC/2009/657 が統合されている事が分かります。http://static.opensolaris.org/on/flagdays/131-135.html PSARC/2009/657 で変更のあったファイルの一覧です。システムコールの変更で、どんなファイルが影響を受けるかが分かります。http://c0t0d0s0.org/codenews/display.php?fragment=30b53f09b8c5aa3233f6a02b8a63386c087801a4 PSARC/2009/657 の概要は Bug Database にも掲載されています。http://bugs.opensolaris.org/bugdatabase/printableBug.do?bug_id=6906485 自分でシステムコールを追加する手順が簡単に説明されています。http://opensolaris.org/jive/thread.jspa?messageID=202074 システムコールの追加方法は Solaris Internals 2nd Edition にも記載があります。http://www.amazon.co.jp/dp/0131482092 システムコール関数を経由せず、システムコールを直接呼び出していたり、古い libc をスタティックリンクしているプログラムは Branded Zone 上で動かす事が可能です。Solaris のバイナリ互換性はシステムコール関数レベルで保たれていますが、更にこういった保護策も用意されています。http://hub.opensolaris.org/bin/view/Community+Group+zones/s10brand_dev_guide システムコール関数に関するマニュアルページです。http://docs.sun.com/app/docs/doc/816-5167/6mbb2jae5 creat は(システムコールとしては) Solaris から無くなりました…http://en.wikiquote.org/wiki/Kenneth%5FThompson Linux のシステムコールは現在 299 まである様です。ここら辺は各 OS で実装が異なっていて興味深い所です。http://lxr.linux.no/linux+v2.6.33/arch/x86/include/asm/unistd_64.h FreeBSD のシステムコールは 522 まであります。http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/syscalls.master?rev=1.262http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/syscall.h?rev=1.235

はじめに 先日、OpenSolaris からシステムコールが幾つか削除されました。b135 以降の syscall.h からは wait, creat, exec, utime, dup, fork(forkall) 等が無くなっています。システムコール番号 2 番には fork(又は forkall) が割り当てられていましたが、現在は空き番号となっています。また、48 番の...

Sun

いろんなツール全員集合

今回はユニークな無償ソフトウェアツール群を紹介します。CMT サーバーをお使いの方なら Cooltst や CoolTuner をすでにご存じかも知れませんし、消費電力が気になるときは Power Calculator が便利ですよね。 http://www.sun.com/systems/tools.jsp には、そんな便利でユニークなツールが集められています。Popular Tools を見ると、やはり上の2つは人気があるようですね。他に人気のツールとしては、Sun Value Tool と Flash Analyzer が載っています。Sun Value Tool とは、現在のお客様のシステムと提案システムを5年間の TCO で比較しメリットを訴求するツールです。サーバー、ストレージやソフトウェアの型と数量を選んで計算させると、いろいろな切り口でグラフ表示してくれます。他社製品もいくつか選べるようになっているので、Sunだとこんなにお得なんですよ、と訴求力アップ間違いなしです。ガートナーや IDC などのインダストリーデータを元に算出しているようですが、納得感がいまひとつの場合でも「ではどういう計算をすべきなのか?」とディスカッションのスタートポイントとして使えますよね。昨今どこもコスト・ROIに厳しくなっていますので、このツールが Popular なのも頷けます。Sun Flash Analyzer は SSD 選択の助けとなるツールです。今ホットな SSD の採用をご検討されている方も多いと思いますが、懸念事項は本当に速くなるのか?どのくらい効果があるのか?ではないでしょうか。HDD と SSD の性能特性が違うために、システムの負荷特性によっては、あまり性能向上を体感できない可能性があるわけです。Sun Flash Analyzer ツールは一定時間、現在のシステムの I/O 負荷を監視して SSD 選択の助けとなるデータを集めます。その他、Data Archive Decision Tool とか Data Encryption Decision Tool なども面白いと思います。スケーラビリティ、セキュリティ、・・・等、重み付けをしていくと、自分に合ったアーカイブ方法、暗号化方法などを助言してくれるというツールです。テープやNAS、Optical Disk に加えて "紙" の選択肢もあるのでどんな結果になるかいろいろ試してみましたが、いずれも真面目な結果となりました。他にもいろいろ便利なツール、面白いツールが盛り沢山です。みなさんも是非お試しください。

今回はユニークな無償ソフトウェアツール群を紹介します。CMT サーバーをお使いの方なら Cooltst や CoolTuner をすでにご存じかも知れませんし、消費電力が気になるときは Power Calculator が便利ですよね。 http://www.sun.com/systems/tools.jsp には、そんな便利でユニークなツールが集められています。Popular...

Sun

DTrace で Java のアプリケーションを解析する

はじめに本記事では DTrace で Java のプログラムを調査する方法をご紹介します。DTrace は Java の HotSpot VM に対応しており、HotSpot VM も DTrace に対応しています。DTrace と HotSpot VM 両方の機能を使う事で Java のプログラムも C や C++ で書かれたプログラムと同様の手順で解析する事が可能です。 jstack() アクションまずは DTrace の Java 対応機能からご紹介します。DTrace には jstack() と言う Java 専用のアクションが用意されています。jstack() アクションはアプリケーションのスタックをダンプしたい時に使用します。同じ様にアプリケーションのスタックをダンプする ustack() というアクションもありますが jstack() は Java のメソッドのアドレスをメソッド名に変換する機能が付いています。その為、Java のプログラムを解析する場合は ustack() アクションの代わりに jstack() アクションを使用します。リスト 1. は jstack() アクションの使用例です。少し長いですが、"# dtrace -x jstackstrsize=2048 -qn 'syscall::lwp_cond_wait:entry { @agg[jstack(10)] = count()} END{trunc(@agg, 3)}' -c 'java -jar dacapo-9.12-bach.jar h2' | ../dem/dem'" というコマンドを実行しています。全体としては、 Java のプログラムでロックが発生したらスタックをダンプしてロックの発生源を探るという処理を行っています。まず jstackstrsize=2048 で jstack() アクションで格納する文字列の最大長を 2048bytes に設定しています。syscall::lwp_cond_wait:entry' の部分は lwp_cond_wait システムコールが呼び出されたら DTrace のスクリプトを実行する事を示しています。続く '{}' の中に実行する処理が記述されています。ここでは、まず @agg[] という集積体を作成しています。@agg[] のキーは jstack() アクションの呼び出しになっており、jstack() アクションの引数は 10 です。これはスタックフレームを 10 段分出力するという意味です。@agg[] の集積関数は count() です。count() は同じキーが何回発生したかをキー毎に集計する関数です。つまり、この @agg[] 集積体はスタックダンプの文字列をキーとし、スタックダンプの中身が同じだった回数を数え上げています。"END{trunc(@agg, 3)}" の部分はプログラム終了時に実行されます。trunc(@agg,3) は上位 3 エントリを残して集積体の中の情報を削除します。最後に -c オプションで DTrace スクリプトで解析する対象のプログラムを渡しています。今回は Java のサンプルプログラムとして DaCapo Benchmark を使用しました。"'java -jar dacapo-9.12-bach.jar h2'" の部分が DaCapo Benchmark の実行部分です。"../dem/dem" の部分は C++ のシンボル名を見易くする為のフィルタです。dem コマンドのソースはこの記事の一番最後に掲載してあります。実行結果は "===== DaCapo 9.12 h2 PASSED in 7209 msec =====" まではアプリケーションの出力で、その下の行からが DTrace の出力です。まずスタックダンプが最大 10 行分とその発生回数が表示され、空白行を開けて次のスタックダンプと発生回数、更に空白行を開けてスタックダンプとその回数が表示されています。つまり、スタックダンプの中身とその発生回数が空白行区切りで三個表示さていることになります。一つ目のスタックダンプのスタックトップは libc.so.1`___lwp_cond_wait+0x15 となっており、これは lwp_cond_wait の呼び出しです。その下の libjvm.so で始まる行は Java VM のルーチンが積んだスタックです。9,10 行目の "org/h2" で始まる 2 行が Java のメソッド呼び出しです。"org/h2/command" は "org.h2.command" パッケージでしょうか。この様に C, C++, Java が入り乱れていて多少見辛いですが、"JdbcPreparedStatement.executeQuery()" という文字から、プリペアドステートメントの実行で条件変数待ちが発生している事が読み取れると思います。 \*\*\* リスト 1. jstack() アクションの使用例 \*\*\* # dtrace -x jstackstrsize=2048 -qn 'syscall::lwp_cond_wait:entry { @agg[jstack(10)] = count()} END{trunc(@agg, 3)}' \\ -c 'java -jar dacapo-9.12-bach.jar h2' | ../dem/dem Using scaled threading model. 16 processors detected, 16 threads used to drive the workload, in a possible range of [1,4000] ===== DaCapo 9.12 h2 starting ===== .... Completed 4000 transactions Stock level ............. 155 ( 3.9%) Order status by name .... 108 ( 2.7%) Order status by ID ...... 65 ( 1.6%) Payment by name ......... 1050 (26.2%) Payment by ID ........... 661 (16.5%) Delivery schedule ....... 167 ( 4.2%) New order ............... 1774 (44.4%) New order rollback ...... 20 ( 0.5%) Resetting database to initial state ===== DaCapo 9.12 h2 PASSED in 7209 msec ===== <-- ここまで DaCapo Benchmark の出力 libc.so.1`___lwp_cond_wait+0x15 <-- スタックトップ libjvm.so`void os::PlatformEvent::park()+0xa9 libjvm.so`void ObjectMonitor::EnterI(Thread\*)+0x1d2 libjvm.so`void ObjectMonitor::enter(Thread\*)+0x2a2 libjvm.so`void ObjectSynchronizer::slow_enter(Handle,BasicLock\*,Thread\*)+0x106 libjvm.so`void ObjectSynchronizer::fast_enter(Handle,BasicLock\*,bool,Thread\*)+0x6c libjvm.so`void InterpreterRuntime::monitorenter(JavaThread\*,BasicObjectLock\*)+0x19e <couldn't find start> org/h2/command/Command.executeQuery(IZ)Lorg/h2/result/ResultInterface; org/h2/jdbc/JdbcPreparedStatement.executeQuery()Ljava/sql/ResultSet; <-- プリペアドステートメントの実行? 2262 <-- これが count() で集計された回数 libc.so.1`___lwp_cond_wait+0x15 libjvm.so`void os::PlatformEvent::park()+0xa9 libjvm.so`void ObjectMonitor::EnterI(Thread\*)+0x1d2 libjvm.so`void ObjectMonitor::enter(Thread\*)+0x2a2 libjvm.so`void ObjectSynchronizer::slow_enter(Handle,BasicLock\*,Thread\*)+0x106 libjvm.so`void ObjectSynchronizer::fast_enter(Handle,BasicLock\*,bool,Thread\*)+0x6c libjvm.so`void SharedRuntime::complete_monitor_locking_C(oopDesc\*,BasicLock\*,JavaThread\*)+0x19b _complete_monitor_locking_Java 5083 libc.so.1`___lwp_cond_wait+0x15 libjvm.so`void os::PlatformEvent::park()+0xa9 libjvm.so`void ObjectMonitor::EnterI(Thread\*)+0x1d2 libjvm.so`void ObjectMonitor::enter(Thread\*)+0x2a2 libjvm.so`void ObjectSynchronizer::slow_enter(Handle,BasicLock\*,Thread\*)+0x106 libjvm.so`void ObjectSynchronizer::fast_enter(Handle,BasicLock\*,bool,Thread\*)+0x6c libjvm.so`void SharedRuntime::complete_monitor_locking_C(oopDesc\*,BasicLock\*,JavaThread\*)+0x19b _complete_monitor_locking_Java 6557先ほどの例で、もし jstack() が使えなかったらどうなるかもご覧頂きましょう。二つ目のスタックダンプでは Java のメソッド呼び出しが解析されずにアドレスだけが表示されています。これは Solaris のコマンドで言うと jstack コマンドの代わりに pstack コマンドを使用した場合と同じ様な状況です。これでは Java のプログラムとして解析する事は出来ません。Java のプログラムを解析する場合は jstack() アクションを使用してください。 \*\*\* リスト 2. jstack() の代わりに ustack() を使用すると... \*\*\* # dtrace -x jstackstrsize=2048 -qn 'syscall::lwp_cond_wait:entry { @agg[ustack(10)] = count()} END{trunc(@agg, 3)}' -c 'java -jar dacapo-9.12-bach.jar h2' | ../dem/dem Using scaled threading model. 16 processors detected, 16 threads used to drive the workload, in a possible range of [1,4000] ===== DaCapo 9.12 h2 starting ===== .... Completed 4000 transactions Stock level ............. 155 ( 3.9%) Order status by name .... 108 ( 2.7%) Order status by ID ...... 65 ( 1.6%) Payment by name ......... 1050 (26.2%) Payment by ID ........... 661 (16.5%) Delivery schedule ....... 167 ( 4.2%) New order ............... 1774 (44.4%) New order rollback ...... 20 ( 0.5%) Resetting database to initial state ===== DaCapo 9.12 h2 PASSED in 7287 msec ===== libc.so.1`___lwp_cond_wait+0x15 libjvm.so`void os::PlatformEvent::park()+0xa9 libjvm.so`int ParkCommon(ParkEvent\*,long long)+0x56 libjvm.so`int Monitor::IWait(Thread\*,long long)+0x9d libjvm.so`bool Monitor::wait(bool,long,bool)+0x7a libjvm.so`GCTask\*GCTaskManager::get_task(unsigned)+0x67 libjvm.so`void GCTaskThread::run()+0x154 libjvm.so`java_start+0xf9 libc.so.1`_thrp_setup+0x9b libc.so.1`_lwp_start 2302 libc.so.1`___lwp_cond_wait+0x15 libjvm.so`void os::PlatformEvent::park()+0xa9 libjvm.so`void ObjectMonitor::EnterI(Thread\*)+0x1d2 libjvm.so`void ObjectMonitor::enter(Thread\*)+0x2a2 libjvm.so`void ObjectSynchronizer::slow_enter(Handle,BasicLock\*,Thread\*)+0x106 libjvm.so`void ObjectSynchronizer::fast_enter(Handle,BasicLock\*,bool,Thread\*)+0x6c libjvm.so`void InterpreterRuntime::monitorenter(JavaThread\*,BasicObjectLock\*)+0x19e 0xfb012b73 <-- これは何らかの Java のメソッドの呼び出し 0xfb002f27 <-- これは何らかの Java のメソッドの呼び出し 0xfb003403 <-- これは何らかの Java のメソッドの呼び出し 3533 libc.so.1`___lwp_cond_wait+0x15 libjvm.so`void os::PlatformEvent::park()+0xa9 libjvm.so`void ObjectMonitor::EnterI(Thread\*)+0x1d2 libjvm.so`void ObjectMonitor::enter(Thread\*)+0x2a2 libjvm.so`void ObjectSynchronizer::slow_enter(Handle,BasicLock\*,Thread\*)+0x106 libjvm.so`void ObjectSynchronizer::fast_enter(Handle,BasicLock\*,bool,Thread\*)+0x6c libjvm.so`void SharedRuntime::complete_monitor_locking_C(oopDesc\*,BasicLock\*,JavaThread\*)+0x19b 0xfb04fc49 <-- これも何らかの Java のメソッドの呼び出し 14112 HotSpot プロバイダと HotSpot_JNI プロバイダ続いて Java VM の側に実装されている DTrace 対応機能を見て頂きます。Java HotSpot VM には HotSpot プロバイダと HotSpot_JNI プロバイダの2 種類が組み込まれています。HotSpot プロバイダは Java VM の動きを解析する為のプロバイダで、HotSpot_JNI プロバイダは Java Native Interface に関するプロバイダです。この記事では HotSpot プロバイダの方を見て行きたいと思います。HotSpot 用のプローブは全部で 500 個程用意されています。 \*\*\* リスト 3. HotSpot VM に含まれるプローブの数 \*\*\* # dtrace -ln 'hotspot\*:::' | wc -l 500その内の大半は HotSpot_JNI プロバイダのプローブで、JNI に関連した調査に使用します。 \*\*\* リスト 4. HotSpot_JNI プロバイダのプローブの数 \*\*\* # dtrace -ln 'hotspot_jni\*:::' | wc -l 474JNI を除いたプローブは 30 個弱あります。 \*\*\* リスト 5. HotSpot プロバイダのプローブの数 \*\*\* # dtrace -ln 'hotspot\*:::' | grep -v hotspot_jni | wc -l 27HotSpot プロバイダには、クラスがロードされた時に発動するプローブやメソッドが呼び出された時に発動するプローブ、GC が開始した時に発動するプローブ、Java のオブジェクトがアロケートされた時に発動するプローブ、スレッドが起動した時に発動するプローブ等、Java のプログラムの解析に便利なプローブが沢山揃っています。リスト 6. は HotSpot プロバイダのプローブの一覧です。それぞれのプローブの機能はプローブ名を見て頂ければ直ぐ予想がつく様になっています。monitor-\* はスレッドの排他処理に関するプローブです。 \*\*\* リスト 6. HotSpot プロバイダのプローブの一覧 \*\*\* # dtrace -ln 'hotspot\*:::' | grep -v hotspot_jni | awk '{print $5}' NAME class-loaded class-unloaded compiled-method-load compiled-method-unload compiled-method-unload gc-begin gc-end mem-pool-gc-begin mem-pool-gc-end method-compile-begin method-compile-end method-entry method-return monitor-contended-enter monitor-contended-entered monitor-contended-exit monitor-notify monitor-notifyAll monitor-wait monitor-waited object-alloc thread-start thread-stop vm-init-begin vm-init-end vm-shutdown HotSpot プロバイダのサンプルスクリプト今ご覧頂いた一覧の中にあるプローブを直に使って DTrace のスクリプトを書く事も可能ですが、幾つかサンプルスクリプトが用意されているのでそれらを見てみましょう。サンプルスクリプトは JDK をダウンロードして展開すると jdk/instances/jdk1.6.0/sample/dtrace/ に入っています。OpenSolaris では /usr/java/sample/dtrace/hotspot/ にインストールされています。簡単に試す事が出来ますので、是非実行してみてください。 \*\*\* リスト 7. HotSpot プロバイダのサンプルスクリプトの一覧 \*\*\* # ls jdk/instances/jdk1.6.0/sample/dtrace/hotspot README.txt method_invocation_stat.d class_loading_stat.d method_invocation_stat_filter.d gc_time_stat.d method_invocation_tree.d hotspot_calls_tree.d monitors.d method_compile_stat.d object_allocation_stat.d 各スクリプトの説明 class_loading_stat.d はロードされたクラス数とアンロードされたクラス数をクラス毎に出力するスクリプトです。デフォルトでは 10 秒毎に出力を行います。このスクリプトは HotSpot プロバイダの hotspot:::class-loaded と hotspot:::class-unloaded プローブを利用しています。 gc_time_stad.d は一定時間毎にガベージコレクションに掛かった時間を出力するスクリプトです。出力はヒープ内のエリア毎に行われます。デフォルトでは 10 秒間隔で出力されますが、出力間隔を指定する事も可能です。このスクリプトは HotSpot プロバイダの hotspot:::gc-begin と hotspot:::gc-end, hotspot:::mem-pool-gc-begin, hotspot:::mem-pool-gc-end の各プローブを利用しています。 hotspot_calls_tree.d は class-loaded, class-unloaded, compiled-method-load, compiled-method-unload, monitor-notify, monitor-notifyAll, vm-init-begin, vm-init-end, gc-begin, gc-end, mem-pool-gc-begin, mem-pool-gc-end, thread-start, thread-stop, method-compile-begin, method-compile-end, monitor-contended-enter, monitor-contended-exit, monitor-wait, monitor-waited の各プローブの発生をトレースして、それをコールフローとして表示します。hotspot_calls_tree.d を実行する際は JavaVM に ExtendedDTraceProbes フラグを設定する必要があります。ExtendedDTraceProbes フラグについては後ほど改めて取り上げます。 method_compile_stat.d はコンパイルされたメソッドのリストをコンパイルに掛かった時間でソートして出力します。デフォルトでは 60 秒毎に、最もコンパイルに時間が掛かったメソッドのトップ 25 と、最もコンパイルに時間が掛からなかったメソッドのトップ 25 を表示します。このスクリプトは method-compile-begin, method-compile-end, compiled-method-load, compiled-method-unload プローブを利用しています。 method_invocation_stat.d は Java の実行時に呼び出されたシステムコール、JNI のイベント、Java のメソッド、クラス、パッケージを、呼び出された回数でソートして出力します。HotSpot プロバイダの method-entry プローブ、HotSpot_JNI プロバイダのプローブからプローブ名が -entry で終わる物を利用しています。method_invocation_stat.d を実行する際は JavaVM に ExtendedDTraceProbes フラグを設定する必要があります。 method_invocation_stat_filter.d は Java のメソッド呼び出しをメソッド毎にカウントするスクリプトです。特定のパッケージ、クラス、メソッドのみを集計する事が出来ます。method_invocation_stat_filter.d は method-entry プローブを利用しています。method_invocation_stat_filter.d を実行する際は JavaVM に ExtendedDTraceProbes フラグを設定する必要があります。 method_invocation_tree.d は Java のメソッドのコールフローを出力します。このスクリプトは HotSpot プロバイダの method-entry, method-return プローブを主に使用しています。method_invocation_tree.d を実行する際は JavaVM に +ExtendedDTraceProbes フラグを設定する必要があります。 monitors.d はスレッドの開始と終了、モニターへの侵入をトレースします。このスクリプトは HotSpot プロバイダの thread-start, thread-stop, monitor-contended-enter, monitor-contended-entered プローブを利用しています。monitors.d を実行する際は JavaVM に +ExtendedDTraceProbes フラグを設定する必要があります。 object_allocation_stat.d は Java のオブジェクトのアロケーションをトレースします。デフォルトでは 60 秒毎に、アロケーションされた総バイト数が最も多かったオブジェクトのトップ 25 とアロケーションされた回数が最も多かったオブジェクトのトップ 25 を出力します。object_allocation_stat.d を実行する際は JavaVM に +ExtendedDTraceProbes フラグを設定する必要があります。 スクリプトの実行例以下は method_invocation_stat_filter.d を実行した結果です。解析対象の Java のプログラムは先ほどと同じ DaCapo Benchmark です。引数でフィルターを指定し、org.h2.engine.Database クラスだけを調査する様にしています。解析結果は isReconnectNeeded() メソッドが 8878365 回で、一番多く呼び出されている事が分かります。 \*\*\* リスト 8. method_compile_stat.d の実行例 \*\*\* # /usr/java/sample/dtrace/hotspot/method_invocation_stat_filter.d \\ -c 'java -server -XX:+ExtendedDTraceProbes -jar ./dacapo-9.12-bach.jar h2 -s small' \\ '"c"' '"org/h2/engine/Database"' BEGIN hotspot method invocation tracing Using scaled threading model. 16 processors detected, 16 threads used to drive the workload, in a possible range of [1,400] ===== DaCapo 9.12 h2 starting ===== Completed 400 transactions Stock level ............. 12 ( 3.0%) Order status by name .... 11 ( 2.8%) Order status by ID ...... 5 ( 1.3%) Payment by name ......... 107 (26.8%) Payment by ID ........... 64 (16.0%) Delivery schedule ....... 18 ( 4.5%) New order ............... 179 (44.8%) New order rollback ...... 4 ( 1.0%) Resetting database to initial state ===== DaCapo 9.12 h2 PASSED in 794614 msec ===== Top packages calls: 11777555 org/h2/engine Top class calls: 11777555 org/h2/engine/Database Top method calls: 1 org/h2/engine/Database:<init>:(Ljava/lang/String;Lorg/h2/engine/ConnectionInfo;Ljava/lang/String;)V 1 org/h2/engine/Database:closeFiles:()V 1 org/h2/engine/Database:closeOpenFilesAndUnlock:(Z)V 1 org/h2/engine/Database:getAllUsers:()Lorg/h2/util/ObjectArray; 1 org/h2/engine/Database:isClosing:()Z 1 org/h2/engine/Database:isMultiThreaded:()Z 1 org/h2/engine/Database:open:(II)V 1 org/h2/engine/Database:openDatabase:(IIZ)V 1 org/h2/engine/Database:opened:()V 1 org/h2/engine/Database:parseDatabaseShortName:()Ljava/lang/String; 1 org/h2/engine/Database:recompileInvalidViews:(Lorg/h2/engine/Session;)V 1 org/h2/engine/Database:reconnectModified:(Z)Z 1 org/h2/engine/Database:removeUnusedStorages:(Lorg/h2/engine/Session;)V 1 org/h2/engine/Database:setMasterUser:(Lorg/h2/engine/User;)V 1 org/h2/engine/Database:stopServer:()V 1 org/h2/engine/Database:stopWriter:()V 2 org/h2/engine/Database:close:(Z)V 2 org/h2/engine/Database:getAllSchemaObjects:(I)Lorg/h2/util/ObjectArray; 2 org/h2/engine/Database:getOptimizeReuseResults:()Z 3 org/h2/engine/Database:getAllTablesAndViews:()Lorg/h2/util/ObjectArray; 6 org/h2/engine/Database:addDefaultSetting:(Lorg/h2/engine/Session;ILjava/lang/String;I)V 8 org/h2/engine/Database:addDatabaseObject:(Lorg/h2/engine/Session;Lorg/h2/engine/DbObject;)V 8 org/h2/engine/Database:getMap:(I)Ljava/util/HashMap; 16 org/h2/engine/Database:checkMetaFree:(Lorg/h2/engine/Session;I)V 16 org/h2/engine/Database:findUser:(Ljava/lang/String;)Lorg/h2/engine/User; 16 org/h2/engine/Database:removeMeta:(Lorg/h2/engine/Session;I)V 16 org/h2/engine/Database:update:(Lorg/h2/engine/Session;Lorg/h2/engine/DbObject;)V 16 org/h2/engine/Database:validateFilePasswordHash:(Ljava/lang/String;[B)Z 17 org/h2/engine/Database:createSession:(Lorg/h2/engine/User;)Lorg/h2/engine/Session; 18 org/h2/engine/Database:removeSession:(Lorg/h2/engine/Session;)V 19 org/h2/engine/Database:getNextModificationMetaId:()J 28 org/h2/engine/Database:addMetaData:(I)V 51 org/h2/engine/Database:addSchemaObject:(Lorg/h2/engine/Session;Lorg/h2/schema/SchemaObject;)V 58 org/h2/engine/Database:allocateObjectId:(ZZ)I 75 org/h2/engine/Database:addMeta:(Lorg/h2/engine/Session;Lorg/h2/engine/DbObject;)V 92 org/h2/engine/Database:setLockMode:(I)V 122 org/h2/engine/Database:findSetting:(Ljava/lang/String;)Lorg/h2/engine/Setting; 139 org/h2/engine/Database:exceptionThrown:(Ljava/sql/SQLException;Ljava/lang/String;)V 141 org/h2/engine/Database:findUserDataType:(Ljava/lang/String;)Lorg/h2/engine/UserDataType; 141 org/h2/engine/Database:getIgnoreCase:()Z 325 org/h2/engine/Database:getAllowLiterals:()I 530 org/h2/engine/Database:getSchema:(Ljava/lang/String;)Lorg/h2/schema/Schema; 571 org/h2/engine/Database:compareTypeSave:(Lorg/h2/value/Value;Lorg/h2/value/Value;)I 634 org/h2/engine/Database:findSchema:(Ljava/lang/String;)Lorg/h2/schema/Schema; 1132 org/h2/engine/Database:compare:(Lorg/h2/value/Value;Lorg/h2/value/Value;)I 2737 org/h2/engine/Database:getSessionCount:()I 140531 org/h2/engine/Database:checkWritingAllowed:()V 142095 org/h2/engine/Database:beforeWriting:()Z 143800 org/h2/engine/Database:getNextModificationDataId:()J 146273 org/h2/engine/Database:getModificationMetaId:()J 147141 org/h2/engine/Database:afterWriting:()V 148024 org/h2/engine/Database:checkPowerOff:()V 153730 org/h2/engine/Database:getTrace:(Ljava/lang/String;)Lorg/h2/message/Trace; 238987 org/h2/engine/Database:getModificationDataId:()J 259850 org/h2/engine/Database:setProgress:(ILjava/lang/String;II)V 1371802 org/h2/engine/Database:areEqual:(Lorg/h2/value/Value;Lorg/h2/value/Value;)Z 8878365 org/h2/engine/Database:isReconnectNeeded:()Z ======================================= JAVA_CALLS: 11777515 Run time: 3415371293436 END of hotspot method invocation tracing HotSpot プロバイダを使用する際の注意点次に HotSpot プロバイダを使用する際の注意点を解説します。注意する必要があるのは Java VM の ExtendedDTraceProbes フラグ、DTrace のゼロ・プローブ・エラー、特定のプローブでの argN 変数の扱い方の 3 つです。 ExtendedDTraceProbes フラグExtendedDTraceProbes フラグは Java VM のオプションです。HotSpot プロバイダのプローブの内、オーバーヘッドが大きく、アプリケーションの実行に影響する物を使用する際にこのフラグを有効にする必要があります。ExtendedDTraceProbes フラグが必要なプローブは monitor-\* プローブ、method-entry, method-return, object-alloc プローブです。デフォルトはこのフラグは有効になっていません。ExtendedDTraceProbes フラグの設定方法は二種類あります。一つは Java VM の起動時に設定する方法、もう一つは jinfo コマンドを使用する方法です。ExtendedDTraceProbes フラグは Java VM の起動時に設定する事が出来ます。 \*\*\* リスト 9. ExtendedDTraceProbes フラグを付けて Java VM を起動する \*\*\* # java -XX:+ExtendedDTraceProbes [ other options ]既に起動している Java VM に大しては jinfo コマンドを使用して、'jinfo -flag +ExtendedDTraceProbes <PID>' の様にフラグを設定する事が可能です。 \*\*\* リスト 10. jinfo コマンドで ExtendedDTraceProbes フラグを設定する \*\*\* # /usr/java/bin/jps 760 Bootstrap 2290 Jps 2289 jar # /usr/java/bin/jinfo -flag ExtendedDTraceProbes 2289 -XX:-ExtendedDTraceProbes <-- デフォルトではフラグは設定されていません # /usr/java/bin/jinfo -flag +ExtendedDTraceProbes 2289 # /usr/java/bin/jinfo -flag ExtendedDTraceProbes 2289 -XX:+ExtendedDTraceProbes <-- フラグが設定されました # /usr/java/bin/jinfo -flag -ExtendedDTraceProbes 2289 # /usr/java/bin/jinfo -flag ExtendedDTraceProbes 2289 -XX:-ExtendedDTraceProbes <-- フラグが無効になりました ゼロ・プローブ・エラーDTrace では dtrace コマンドの -c オプションで実行するコマンドを指定して解析を行う事が良くあります。しかし Java のアプリケーションを引数にして実行を開始しようとするとエラーが発生する場合があります。これは DTrace が実行を開始した時点では Java VM は完全に起動しておらず、HotSpot プロバイダのプローブが一つも用意されていない事に起因します。これを回避する為 dtrace コマンドには -Z オプションが用意されています。-Z オプションはスクリプト開始時にマッチするプローブの数がゼロでもエラーにせず、トレースを開始するという意味のオプションです。リスト 11. は -Z オプションを付けていなかった為にエラーが発生する例です。 \*\*\* リスト 11. ゼロ・プローブ・エラー \*\*\* # dtrace -n 'hostpot$target:::class-loaded' -c 'java -jar dacapo-9.12-bach.jar h2' dtrace: invalid probe specifier hostpot$target:::class-loaded: probe description hostpot2247:::class-loaded does not match any probesdtrace コマンドに -Z オプションを付ければエラーは回避出来ます。Java のプログラムを引数にして dtrace コマンドを実行する場合は -Z オプションを忘れない様にしてください。 \*\*\* リスト 12. -Z オプションでゼロ・プローブ・エラーを回避 \*\*\* # dtrace -Zn 'hostpot$target:::class-loaded' -c 'java -jar dacapo-9.12-bach.jar h2' dtrace: description 'hostpot$target:::class-loaded' matched 0 probes ... method-entry プローブを使用する場合の注意点method-entry プローブを使用したスクリプトを素直に書くと出力が混じってしまい、解析が出来ません。 \*\*\* リスト 13. DTrace の出力にゴミが混じってしまう例 \*\*\* # dtrace -b 256m -Zqn 'hotspot$target:::method-entry { @agg[stringof(copyin(arg1, arg2)), stringof(copyin(arg3, arg4))] = count() } tick-1sec { trunc(@agg, 3); printa(@agg); trunc(@agg) }' -c 'java -XX:+ExtendedDTraceProbes -jar dacapo-9.12-bach.jar h2' ... org/h2/expression/ParameterckParcheckSetetaIdquiredntInternal26_50g checkSetetaIdquiredntInternal26_50g 4354 org/h2/util/ObjectArrayeterckParcheckSetetaIdquiredntInternal26_50g getckParcheckSetetaIdquiredntInternal26_50g 4354 sun/misc/Unsaferrent/atomic/AtomicLong/OcompareAndSetmIntring24_50g compareAndSwapLongLong/OcompareAndSetmIntring24_50g 6208 org/h2/expression/ParameterckParcheckSetetaIdquiredntInternal26_50gbleWarehouse checkSetetaIdquiredntInternal26_50gbleWarehouse 3808 org/h2/util/ObjectArrayeterckParcheckSetetaIdquiredntInternal26_50gbleWarehouse getckParcheckSetetaIdquiredntInternal26_50gbleWarehouse 3808 sun/misc/Unsaferrent/atomic/AtomicLong/OcompareAndSetmIntring24_50gbleWarehouse compareAndSwapLongLong/OcompareAndSetmIntring24_50gbleWarehouse 5442 org/h2/expression/ParameterckParcheckSetetaIdquiredntInternal26_50g checkSetetaIdquiredntInternal26_50g 3864 org/h2/util/ObjectArrayeterckParcheckSetetaIdquiredntInternal26_50g getckParcheckSetetaIdquiredntInternal26_50g 3864 sun/misc/Unsaferrent/atomic/AtomicLong/OcompareAndSetmIntring24_50g compareAndSwapLongLong/OcompareAndSetmIntring24_50g 5518この問題を回避する為に stringof() で文字列に変換する前に、手動で文字の配列を作成します。具体的には以下の様なスクリプトを作成します。ここでは arg1, arg3 変数を copyin() したデータをそのまま stringof() に渡さず、先に (char \*) にキャストし、文字列の終端に自分でヌル文字を入れています。ひと手間掛かりますが、これで問題は解決出来ます。 \*\*\* リスト 14. method-entry プローブを使用する際の回避策 \*\*\* # cat mentry.d #!/usr/sbin/dtrace -Zqs hotspot$target:::method-entry { self->class = (char \*) copyin(arg1, arg2 + 1); self->class[arg2] = '\\0'; self->method = (char \*) copyin(arg3, arg4 + 1); self->method[arg4] = '\\0'; @agg[stringof(self->class), stringof(self->method)] = count() } tick-1sec { trunc(@agg, 3); printa("%@d\\t\\t%s . %s\\n", @agg); printf("\\n"); clear(@agg) }回避策を組み込んだ場合の出力結果は以下の通り、文字は重なり合っていません。これで解析を行う事が可能になりました。 \*\*\* リスト 15. 回避策を講じた場合の出力例 \*\*\* # ./mentry.d -c 'java -XX:+ExtendedDTraceProbes -jar dacapo-9.12-bach.jar h2' ... 25697 java/util/concurrent/atomic/AtomicLong . get 25697 sun/misc/Unsafe . compareAndSwapLong 25698 java/util/Random . next 31307 java/util/concurrent/atomic/AtomicLong . compareAndSet 31307 java/util/concurrent/atomic/AtomicLong . get 31307 sun/misc/Unsafe . compareAndSwapLong 11716 org/h2/util/ObjectArray . get 16041 java/lang/Object . <init> 21066 java/lang/Character . digit object-alloc プローブを使用する場合の注意点method-entry と同じ様に、objec-alloc プローブでも stringof() で直接文字列に変換すると、処理が追いつかずに出力がおかしくなります。 \*\*\* リスト 16. object-alloc プローブで出力が乱れる例 \*\*\* # dtrace -b 256m -Zqn 'hotspot$target:::object-alloc { @agg[stringof(copyin(arg1, arg2))] = count()} tick-1sec {trunc(@agg, 3); printa(@agg); clear(@agg)}' \\ -c 'java -XX:+ExtendedDTraceProbes -jar dacapo-9.12-bach.jar h2' ... java/math/BigDecimaldergFixederrrayIterator 20826 org/h2/value/ValueStringFixederrrayIterator 25735 org/h2/value/ValueStringFixedtArrayIteratorndomdUpdater$AtomicReferenceFieldUpdaterImpl 28359 java/lang/StringBuildergFixedtArrayIterator 14000 [Cva/lang/StringBuildergFixedtArrayIterator 21000 org/h2/value/ValueStringFixedtArrayIterator 146923 java/lang/StringBuildergFixederrrayIterator 21420 [Cva/lang/StringBuildergFixederrrayIterator 32130 java/math/BigDecimaldergFixederrrayIterator 48143 org/h2/value/ValueStringampedKCS11teeermIZE_ARGSte;cry;reamolcReferenceFieldUpdaterImpl 11784 java/math/MutableBigIntegerederrrayIterator 11980 java/math/BigDecimaldergFixederrrayIterator 15178先ほどと同様に、この様なスクリプトを作成すれば回避可能です。 \*\*\* リスト 17. 回避策 \*\*\* # cat oalloc.d #!/usr/sbin/dtrace -Zqs hotspot$target:::object-alloc { self->class = (char \*) copyin(arg1, arg2 + 1); self->class[arg2] = '\\0'; @agg[stringof(self->class)] = count(); } tick-1sec { trunc(@agg, 3); printa(@agg); trunc(@agg) }(それなりに)分かり易い表記になったと思います。クラス名の '[L' や '[C' については http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#84645 をご覧下さい。 \*\*\* リスト 18. 回避策を講じた場合の出力 \*\*\* # ./oalloc.d -c 'java -XX:+ExtendedDTraceProbes -jar dacapo-9.12-bach.jar h2' ... [C 31555 org/h2/value/ValueStringFixed 74362 org/h2/value/ValueString 81814 org/h2/value/ValueString 46835 java/math/BigDecimal 47985 [C 59466 org/h2/value/ValueShort 26387 [C 56711 java/math/BigDecimal 56935 おわりにDTrace で Java のプログラムを解析する際に便利な jstack() アクションと HotSpot プロバイダの使い方をご紹介しました。jstack() アクションでは syscall プロバイダと併せて使用した場合の例を、HotSpot プロバイダではサンプルスクリプトのご紹介と、HotSpot プロバイダを使用する際の注意点をご説明しました。DTrace が Java のアプリケーションの解析にも便利に使える事がご理解頂けたと思います。是非お手元でも実際にお試し頂ければと思います。なお、DTrace は Java だけでなく JavaScript, PHP, Python, Ruby, Perl 等の言語でも使用する事が可能です。JavaScript, PHP, Python, Ruby のプロバイダは既に OpenSolaris にも組み込まれておりますので、是非インストールして試してみてください。 参考文献 プローブとその引数の意味の一覧http://java.sun.com/javase/ja/6/docs/ja/technotes/guides/vm/dtrace.htmlhttp://java.sun.com/javase/6/docs/technotes/guides/vm/dtrace.html DTrace で Java のプログラムを解析する方法に関するオーバービューhttp://www.solarisinternals.com/wiki/index.php/DTrace_Topics_Javahttp://www.devx.com/Java/Article/33943/1954?pf=true DTrace で Java プログラムを解析する方法に関連したブログエントリhttp://blogs.sun.com/ahl/entry/java_debugging_w_dtracehttp://blogs.sun.com/simonri/entry/fun_with_dtrace_and_java 日本語情報 by 原口さんhttp://www.atmarkit.co.jp/flinux/rensai/opensolaris07/opensolaris07b.html DTrace で Java のプログラムを解析する方法に関するホワイトペーパーhttp://java.sun.com/j2se/reference/whitepapers/java-dtrace-whitepaper.pdfhttp://jp.sun.com/developers/solaris/solaris10/dtrace/private/java-dtrace-whitepaper.pdf DTrace を含む Java の Observability についての情報http://www.sun.com/bigadmin/features/articles/j2se5.0_observability.jsp DaCapo Benchmarkhttp://dacapobench.org/ おまけ DTrace で Clojure のプログラムを解析するJava VM の上で動くプログラムであれば Java 以外の言語でも解析対象とする事が出来ます。以下は Clojure を解析する例です。Clojure の REPL から次の様な関数を定義するとします。 \*\*\* リスト 19. Clojure を起動して REPL で関数を定義する \*\*\* # java -XX:+ExtendedDTraceProbes -jar clojure.jar Clojure 1.1.0 user=> (defn foo [] (pr "foo")) #'user/foo user=> \^DClojure が起動したら、関数を定義する前に、別の端末エミュレータから以下のコマンドを実行しておきます。ここで実行している dtrace コマンドは Clojure で関数を定義した時にアロケートされるオブジェクトのサイズの総和を出力します。 \*\*\* リスト 20. HotSpot プロバイダのプローブを利用して調査を行う \*\*\* # /usr/java/bin/jps <-- Clojure のプロセスを探す 761 Bootstrap 6275 jar 6276 Jps # dtrace -qn 'hotspot$target:::object-alloc { @sz = sum(arg3) } tick-5sec { printa("%@d\\n", @sz); trunc(@sz)}' -p 6275 597768出力結果を見ると、全部で 597768 bytes のオブジェクトがアロケートされた事が分かります。小さな関数の定義で 600KB ほどメモリを消費しました。この時、どんなオブジェクトが生成されているかも DTrace で簡単に調べる事が出来ます。 \*\*\* リスト 21. どんなオブジェクトが生成されているかを調べるスクリプト \*\*\* # dtrace -qn 'hotspot$target:::object-alloc { self->m = (char \*) copyin(arg1, arg2+1); self->m[arg2] = '\\0'; @agg[stringof(self->m)] = count()} tick-5sec {trunc(@agg, 5); printa(@agg); trunc(@agg,0)}' -p 6275 [B 205 java/lang/reflect/Method 238 [Ljava/lang/Object; 337 java/lang/String 821 [C 1267左がアロケートされたオブジェクト、右がオブジェクトの個数です。最も多くアロケートされたオブジェクトはキャラクター型の配列で、1267 個アロケートされています。この様に、DTrace を使用すれば、発想次第で様々な情報を取り出す事が出来ます。非常に便利なツールだと思います。 dem コマンドについてdem コマンドは C++ のシンボル名を読み易く加工する為にでっち上げたコマンドです。Sun Studio がインストールされた環境では c++filt というコマンドを代わりに使用出来ますので、なるべくそちらをお使い下さい。 \*\*\* リスト 22. dem コマンドのソースコード \*\*\* # cat dem.c // gcc dem.c -ldemangle -o dem #include <demangle.h> #include <stdio.h> #define LEN 1024 char input[LEN]; char mangled[LEN]; char output[LEN]; int main() { while(fgets(input, LEN, stdin)) { int i, start; i = 0; while((input[i] != '`') && (input[i] != NULL)) { i++; } write(1, input, i + 1); if(input[i] == NULL) continue; start = ++i; while((input[i] != '+') && (input[i] != NULL)) { i++; } bcopy(&input[start], mangled, i - start); mangled[i-start] = NULL; cplus_demangle(mangled, output, LEN); write(1, output, strlen(output)); if(input[i] != NULL) write(1, &input[i], strlen(input) - i); } }

はじめに 本記事では DTrace で Java のプログラムを調査する方法をご紹介します。DTrace は Java の HotSpot VM に対応しており、HotSpot VM も DTrace に対応しています。DTrace と HotSpot VM 両方の機能を使う事で Java のプログラムも C や C++ で書かれたプログラムと同様の手順で解析する事が可能です。 jstack()...

Sun

デスクトップ環境に関するあれこれ

Solaris 10 をインストールした後、Solaris 10 のデスクトップログイン画面から CDE を選択し、ウインドウシステムを起動するとこんなメッセージが立ち上がります。「共通デスクトップ環境(CDE)は推奨されなくなりました。将来の Solaris リリースで削除される予定です。Java Desktop System(JDS)に移行して下さい。」この画面を見ると「とうとう CDE も無くなってしまうのか....」と思うのですが、昔からの Solaris ユーザは、昔もこれに似たメッセージを何処かで見たようなデジャヴ体験をした方も多かったと思います。そう。 Solaris 8 の時代に CDE ではなく OpenWindows を起動すると、「将来は OpenWindows のサポートが無くなりますよ」という旨のメッセージが出てきました。思い返せば Solaris のデスクトップ環境は、OPEN LOOK の OpenWindows から始まり、Motif の CDE を経て GNOME の JDS に至っております。当然、端末画面も cmdtool , shelltool -> dtterm -> gnome-terminal と変わって来ているのですが、コンサバな私は未だに dtterm を愛用しております。懐かしさついでに、 Solaris 10 に標準装備されているウインドウマネージャといえば、twm がまだあった事を思い出し、昔を忍んで起動してみました。(コマンド行ログインから /usr/openwin/xdm と入力してみて下さい。)今回、X11 定番の xlogo, xeyes, xclock, xbiff, maze, xterm を起動しましたが何とも懐かしく癒されました....。とても Solaris 10 が稼働しているとは思えません。また、今回紹介できませんが、twm でアプリケーションを kill する時(ポップアップメニューから kill を選択)に出てくるドクロマークのマウスポインタも久々に見る事ができました。最後に、古いウインドウシステムといえば、SunOS 4.X 時代は Sun View や NeWS を使っていた事があります。キャラクタ端末しか知らなかった当時の私が Sun のマルチウインドウシステムと初めて出会った時の衝撃は今でも忘れられません。(参考情報)過去の 「やっぱり Sun がスキ!」blog 記事一覧はこちらを参照下さい。http://wikis.sun.com/display/yappri/Home

Solaris 10 をインストールした後、Solaris 10 のデスクトップログイン画面 から CDE を選択し、ウインドウシステムを起動するとこんなメッセージが立ち 上がります。 「共通デスクトップ環境(CDE)は推奨されなくなりました。将来の Solaris リリースで削除される予定です。Java Desktop System(JDS)に移行して下さい。」この画面を見ると「とうとう...

Sun

ZFS の READ 用キャッシュチューニング方法

Solaris 10/09 で ZFS の L2ARC(Level 2 Adaptive Replacement Cache)がサポートされましたが、同時に ARC と L2ARC の使用有無に関するチューニングが行えるようになりました。ARC と L2ARC は、それぞれ ZFS の一次用、二次用の READ 用キャッシュとして機能し、READ のパフォーマンスを向上させる仕組みなのですが、RAID アレイ装置や、アプリケーションとの組み合わせによっては、逆にこの READ 用キャッシュがオーバヘッドとなる時もあります。そんな時は、この ARC と L2ARC の働きを OFF にするチューニングが有効です。この ZFS キャッシュのチューニングには、all/none/metadata の3種類があります。all: キャッシュを行うnone: キャッシュを行わないmetadata : メタデータのみキャッシュするそれでは実際に設定してみましょう。まずは、現在の設定を確認してみます。# zfs get all | grep cachetank primarycache all defaulttank secondarycache all defaulttank/home primarycache all defaulttank/home secondarycache all defaulttank/iscsi-vol primarycache all defaulttank/iscsi-vol secondarycache all defaultこの結果より、primarycache と secondarycache のプロパティは、ファイルシステム毎に指定で、デフォルトは all(全てのデータをキャッシュ) である事が分かります。それでは、 tank/iscsi-vol のファイルシステムに対して、primaricache とsecondarycache を none にしてみましょう。# zfs set primarycache=none tank/iscsi-vol# zfs set secondarycache=none tank/iscsi-vol# zfs get primarycache tank/iscsi-volNAME PROPERTY VALUE SOURCEtank/iscsi-vol primarycache none local# zfs get secondarycache tank/iscsi-volNAME PROPERTY VALUE SOURCEtank/iscsi-vol secondarycache none localこれで tank/iscsi-vol ファイルシステムに対して ZFS の READ キャッシュをOFF にする事ができました。ちなみに、ファイルシステム作成時でもプロパティが指定できます。# zfs create -o primarycache=metadata tank/newdatabまた、ARC キャッシュを使用したいが、キャッシュ領域の制限を設定したい時には、/etc/systemsへ set zfs:zfs_arc_max の設定を追加する事で制限が可能です。(例)ARC を 2GB に制限する場合set zfs:zfs_arc_max = 2147483648(参考情報)過去の 「やっぱり Sun がスキ!」blog 記事一覧はこちらを参照下さい。http://wikis.sun.com/display/yappri/Home

Solaris 10/09 で ZFS の L2ARC(Level 2 Adaptive Replacement Cache)が サポートされましたが、同時に ARC と L2ARC の使用有無に関するチューニング が行えるようになりました。 ARC と L2ARC は、それぞれ ZFS の一次用、二次用の READ 用キャッシュとして機能し、READ...

Sun

ZFS 環境をアップグレードする方法

 2010年2月現在、Solaris 10 の最新バージョンは Solaris 10 10/09 (Update 8) ですが、ZFS が構築されている古い Solaris 10 環境から最新の Solaris 10 にアップグレードし、ZFS のユーザ/グループ quota や Hybrid Storage Pool を使用するには、 ZFS のプールやファイルシステムに対する個別のアップグレード作業が必要になります。 そこで今回は、ZFS 環境のアップグレードに関する TIPS を紹介します。まずは、古い Solaris 10 環境で ZFS プールのバージョンを確認してみましょう。今回は、Solaris 10 5/09 (Update 7) で行ってみます。# zpool upgrade -vこのシステムでは現在、 バージョン 10 の ZFS プールが動作しています。次のバージョンがサポートされています:VER 説明--- -------------------------------------------------------- 1 初期バージョンの ZFS 2 Ditto ブロック(複製されたメタデータ) 3 ホットスペアおよびダブルパリティー RAID-Z 4 zpool history 5 gzip アルゴリズムを使用した圧縮 6 bootfs プールプロパティー 7 別のインテントログデバイス 8 委任管理 9 refquota および refreservation プロパティー 10 キャッシュデバイスサポートされるリリースなど、特定のバージョンの詳細については、以下を参照してください:http://www.opensolaris.org/os/community/zfs/version/N'N' はバージョン番号です。zpool upgrade コマンドより、現在使用している ZFS プールのバージョンと、サポートされている機能一覧が確認できます(今回はバージョン 10 でした)。同様に zfs ファイルシステムのバージョンも確認してみます。# zfs upgrade -v次のファイルシステムのバージョンがサポートされています:VER 説明--- -------------------------------------------------------- 1 初期の ZFS ファイルシステムのバージョン 2 拡張されたディレクトリエントリ 3 大文字小文字を区別しない、ファイルシステム固有の識別子 (FUID)サポートされるリリースなど、特定のバージョンの詳細については、以下を参照してください:http://www.opensolaris.org/os/community/zfs/version/zpl/N'N' はバージョン番号です。zfs upgrade コマンドより、現在使用している ZFS ファイルシステムのバージョンと、サポートされている機能一覧が確認できます(今回はバージョン 3 でした)。これらコマンドの結果より、ZFS 環境のバージョンを確認する際は、プールとファイルシステム両方のバージョンを把握する必要があります。次に最新の Solaris 10 10/09 (Update 8) で同様のコマンドを確認してみます。# zpool upgrade -vこのシステムでは現在、バージョン 15 の ZFS プールが動作しています。次のバージョンがサポートされています:VER 説明--- -------------------------------------------------------- 1 初期バージョンの ZFS 2 Ditto ブロック(複製されたメタデータ) 3 ホットスペアおよびダブルパリティー RAID-Z 4 zpool history 5 gzip アルゴリズムを使用した圧縮 6 bootfs プールプロパティー 7 別のインテントログデバイス 8 委任管理 9 refquota および refreservation プロパティー 10 キャッシュデバイス 11 Improved scrub performance 12 Snapshot properties 13 snapused property 14 passthrough-x aclinherit 15 user/group space accountingサポートされるリリースなど、特定のバージョンの詳細については、以下を参照してください:http://www.opensolaris.org/os/community/zfs/version/N'N' はバージョン番号です。# zfs upgrade -v次のファイルシステムのバージョンがサポートされています:VER 説明--- -------------------------------------------------------- 1 初期の ZFS ファイルシステムのバージョン 2 拡張されたディレクトリエントリ 3 大文字小文字を区別しない、ファイルシステム固有の識別子 (FUID) 4 userquota, groupquota propertiesサポートされるリリースなど、特定のバージョンの詳細については、以下を参照してください:http://www.opensolaris.org/os/community/zfs/version/zpl/N'N' はバージョン番号です。Solaris 10 の ZFS は、5/09 から 10/09 にかけて多くの機能がエンハンスされている事が確認できます。それでは、早速古い ZFS 環境を新しい ZFS 環境へアップグレード行ってみます。今回は、 Solaris 10 5/09 (Update 7) で作成した ZFS プールを export し、Solaris 10 10/09 (Update 8) の環境に import しました。実際にアップグレードする前に、まずは現在の状態を確認してみます。# zpool upgradeこのシステムでは現在、バージョン 15 の ZFS プールが動作しています。次のプールは最新ではありませんが、アップグレードが可能です。アップグレードすると、以前のバージョンのソフトウェアからこれらのプールにアクセスできなくなります。VER プール--- ------------10 test-pool使用可能なバージョンおよび関連する機能のリストについては、'zpool upgrade -v' を使用してください。# zfs upgradeこのシステムでは現在、バージョン 4 の ZFS ファイルシステムが動作しています。次のファイルシステムは最新ではありませんが、アップグレードが可能です。アップグレードすると、以前のバージョンのソフトウェアからこれらのファイルシステム (および、これ以降のスナップショットから生成された任意の 'zfs send' ストリーム) にアクセスできなくなります。VER FILESYSTEM--- ------------ 3 test-pool 3 test-pool/homeそれでは、早速 zfs をアップグレードしてみましょう。アップグレードを行うには、-a オプションを付与して実行します。# zpool upgrade -aこのシステムでは現在、バージョン 15 の ZFS プールが動作し�����います。'test-pool' のアップグレードに成功しましたこれで ZFS プールのアップグレードが完了しましたので状態を確認してみましょう。# zpool upgradeこのシステムでは現在、バージョン 15 の ZFS プールが動作しています。このバージョンを使用して、すべてのプールがフォーマットされています。次に、ZFS ファイルシステムのアップグレードを行います。# zfs upgrade -a2 ファイルシステムをアップグレードしました# zfs upgradeこのシステムでは現在、バージョン 4 の ZFS ファイルシステムが動作しています。すべてのファイルシステムが現在のバージョンでフォーマットされています。これで全てのアップグレード作業が完了しました。今回、ZFS 環境のアップグレード方法を紹介しましたが、ZFS のバージョンアップを行った後は、(アップグレード時のメッセージにある通り)古いバックアップは使用できなくなってしまうので、現時点でのバックアップを取得する事をお勧め致します。(参考情報)過去の 「やっぱり Sun がスキ!」blog 記事一覧はこちらを参照下さい。http://wikis.sun.com/display/yappri/Home

 2010年2月現在、Solaris 10 の最新バージョンは Solaris 10 10/09 (Update 8) ですが、 ZFS が構築されている古い Solaris 10 環境から最新の Solaris 10 にアップグレードし、 ZFS のユーザ/グループ quota や Hybrid Storage Pool を使用するには、 ZFS のプールやファイルシステムに対する個別のアップグ...

Sun

OpenSolaris dev b131 Text Installer

すでにリリースされている OpenSolaris 2009.06 では、これまでの Solaris 10 とは違うインストール方法を用い導入しなければなりませんでした。x86 では GUI が必須であり、それ以外のシステム(SPARC やモニタ出力をもたない x86 システムなど)ではネットワーク接続を前提とした環境が必須となっていました。そのため、実験的な導入においても試行錯誤が要求されたり躊躇してしまう機会が多かったかと思います。そのような環境も考慮した従来のテキストベースのインストーラの実装について数多くのリクエストがあったのは言うまでもありません。テキストインストーラについても、下記 OpenSolaris プロジェクトとして実装が待ち望まれていました。 Project caiman: Text Based Installer Project http://hub.opensolaris.org/bin/view/Project+caiman/TextInstallerProjectそして、開発版 OpenSolaris の最新ビルドにて、ついにテキストインストーラが実装されたものがリリースされました。さらに、x86 および SPARC をサポートしており、イメージファイルのサイズも CD-R に収まる容量となっています。さらにさらに、インストール時における必要メモリ容量も 512MB と少なくなっており、導入できる機種の幅が広がりました。これは、試さずにはいられません。というわけで、今回は、このテキストインストーラについてご紹介したいと思います。また、今回ご紹介するテキストインストーラ自体は、まだ、正式なものではなく実装のテストを目的としたものとなります。そのため、将来のリリースにで内容に変更があることも十分考えられます。イメージファイルの入手および詳細情報については、下記の URL にまとめられています。 Text Installer b131-based project gate imageshttp://hub.opensolaris.org/bin/view/Project+caiman/Text+Install+b131+Notes今回は、x86 版の CD イメージである textinstall-131-x86.iso を使い VirtualBox で動作確認したいと思います。それでは、早速、見て行きましょう。起動から keyboard layout, Desktop に使用する言語までは特に変化はありません。ここからテキストインストーラが起動します。インストール先のディスクを選択して行きます。"Use the whole disk" を選択し、ディスク全体を OpenSolaris にて使用します。ホストネームは、opensolaris がデフォルト値となっています。また、ネットワーク設定は NWAM (NetWork Auto Magic)を利用した自動構成とする場合は Automaticaly を。手動で設定する場合は None を選択します。None を選択した場合は、インストール後に手動で設定する必要があります。Time Zone を設定し・・・root ユーザのパスワードと一般ユーザアカウントを作成します。そして、構成情報の確認画面が表示されインストールが開始されます。インストールは、環境にもよりますが 20 分程度で完了。再起動することで OpenSolaris が起動します。今回、お披露目されたテキストインストーラは、GUI インストーラで設定できる内容とほぼ同一となり、Solaris 10 のような細かなパーティション設定などはできません。また、GUI インストーラにはない、軽快な動作でのインストールを体験できます。インストールされた OpenSolaris は開発版となる OpenSolaris dev b131 ですが、GNOME や X11 関連のパッケージはインストールされていない状態となります。必要なパッケージは、pkg コマンドを利用してリポジトリからインストールすることなり、以後、通常の OpenSolaris にて行う同一のオペレーションで利用することが可能となりますので、これを機会に ぜひ OpenSolaris をインストールしてみて頂ければと思います。

すでにリリースされている OpenSolaris 2009.06 では、これまでの Solaris 10 とは違うインストール方法を用い導入しなければなりませんでした。 x86 では GUI が必須であり、それ以外のシステム(SPARC やモニタ出力をもたない x86 システムなど)ではネットワーク接続を前提とした環境が必須となっていました。そのため、実験的な導入においても試行錯誤が要求されたり躊躇...

Sun

DTrace の SDT プロバイダの仕組みに迫る

はじめに今回は DTrace の SDT プロバイダの仕組みをご紹介します。SDT プロバイダは FBT プロバイダや PID プロバイダと並んで、DTrace の基盤となるプロバイダです。SDT プロバイダの仕組みを理解する事で、DTrace への理解も深まる事と思います。 SDT プロバイダとはSDT(Statically Defined Tracing) プロバイダはソースコードの中に DTrace のプローブポイントを埋め込むための仕組みです。SDT 以外のプロバイダは DTrace 用にソースコードを書き換えなくとも全ての機能が使用出来ました。たとえば FBT プロバイダはカーネルの関数の開始、終了を追跡する事が出来ますが、カーネルの関数全てに DTrace 用のコードを埋め込んでいる訳ではありません。その代わりに DTrace が実行イメージにパッチを当てて、プローブのコードを動的に埋め込んでいました。この動的なプローブポイントの作成は DTrace の大きなメリットの一つですが、プローブしたいポイントが常に動的に指定しやすい場所にある訳ではありません。プログラム実行者に取っては意味があるポイントでも、コンピュータが処理する上では他の処理と何の違いも無い場合があります。SDT プロバイダは、その様な動的に指定するのが難しい場所、動的に取得するのが難しいデータをトレースする為に、ソースコード上でプローブポイントとデータを指定する手段を提供しています。ソースコードの特定の場所にプローブを記述するので、Statically Defined Tracing (静的に定義されたトレース)という名称になっています。SDT プロバイダを使用する事で、プログラマはプローブポイントや取得したいデータを自由に決める事が出来ます。埋め込んだプローブは後でプログラムの解析に利用する事が出来ます。Solaris のカーネルの中にも SDT のプローブポイントは既に沢山埋め込まれており、先日ご紹介した IP プロバイダ も SDT プロバイダの一種です。他にも Sched プロバイダや IO プロバイダも SDT プロバイダの機能を利用して実装されています。 SDT プロバイダの使い方SDT プロバイダのプローブの一覧は dtrace コマンドに -lP sdt オプションを付けて実行すると見る事が出来ます。Solaris 10 10/09 では IO, Sched, Proc プロバイダも SDT プロバイダの一種なので、それらも加えて実行した結果が以下の出力です。ここでリストされているプローブを解析に使用する事が出来ます。 \*\*\* SDT プロバイダのプローブの一覧の見方 \*\*\* # dtrace -lP sdt,io,sched,proc ID PROVIDER MODULE FUNCTION NAME 2679 sdt unix cpupm_utilization_event cpupm-ti-ungoverned 2688 sdt unix page_get_replacement_page page-get 2689 sdt unix page_get_cachelist page-get 2690 sdt unix page_get_freelist page-get 2701 sdt unix cpu_set_curr_clock cpu-change-speed 2702 sdt unix cpupm_utilization_event cpupm-lower-req 2703 sdt unix ecc_page_zero page_zero_result 2704 sdt unix cpupm_utilization_event cpupm-tw-governed 2705 sdt unix cpupm_utilization_event cpupm-ti-governed ...プローブの一覧は一行につき一つのプローブが表示されます。今回検証した環境では 864 個の SDT のプローブが組み込まれていました。プローブの数は OS のリリースやプラットフォーム、ロードされているカーネルモジュール等によって変わります。 \*\*\* SDT プロバイダのプローブの数は 864 個 \*\*\* # dtrace -lP sdt,io,sched,proc | wc -l 865 <-- ヘッダ行を含む出力の行数続いて、SDT プロバイダの使用例を見てみましょう。下記の例では SDT プロバイダのプローブを使って、カーネルのタスクキューから毎秒幾つのタスクが実行開始されているかを確認しています。ここで使用されている taskq-exec-start はタスクの処理が開始する直前に呼ばれる SDT プロバイダのプローブです。カーネルの負荷が増加すると処理されるタスクの数も増え、taskq-exec-start プローブが呼び出される回数も増加します。ここでは taskq-exec-start プローブが呼ばれる毎に cnt 変数をインクリメントし、Profile プロバイダの tick-1sec プローブを使用して 1 秒毎に cnt の値を出力しています。また、同じく Profile プロバイダの tick-5sec プローブを使用して、実行開始から 5 秒後にスクリプトが終了する様にしています。 \*\*\* SDT プロバイダの使用例 1 \*\*\* # dtrace -qn 'sdt:::taskq-exec-start {cnt++} tick-1sec{printf("%d\\n", cnt); cnt=0} tick-5sec{exit(0)}' 46 51 52 55 49taskq-exec-start のプローブポイントは Solaris のソースコード中の /usr/src/uts/common/os/taskq.c#1504 に埋め込まれています。taskq-exec-start は関数の入り口や出口ではなく、通常のコードの中に位置しています。この様なポイントを DTrace が自動的に見付けてプローブを挿入するのは難しい為、代わりに SDT プロバイダを使用して静的にプローブを埋め込んでいます。実際に観測したい tqent_func() の呼び出しも、タスク毎に変わる関数ポインタになっている為、SDT プロバイダを使用しないと一括して補足する事は困難です。 \*\*\* taskq-exec-start が埋め込まれているソースコード \*\*\* 1502 rw_enter(&tq->tq_threadlock, RW_READER); 1503 start = gethrtime(); 1504 DTRACE_PROBE2(taskq__exec__start, taskq_t \*, tq, <-- ここ! 1505 taskq_ent_t \*, tqe); 1506 tqe->tqent_func(tqe->tqent_arg); 1507 DTRACE_PROBE2(taskq__exec__end, taskq_t \*, tq, 1508 taskq_ent_t \*, tqe); 1509 end = gethrtime(); 1510 rw_exit(&tq->tq_threadlock);以下は同じく taskq-exec-start プローブを利用して、タスクの処理に使用される関数の名前を出力する例です。dtrace コマンドを実行した 10 秒間で、kmem_cache_reap() 関数が 385 回、callout_execute() 関数が 515 回実行されている事が分かります。taskq-exec-start プローブの中で使用している arg1 変数は taskq_ent_t \* 型の変数です。この変数にはタスクに関する情報が含まれており、その中にはタスクで実行される関数のアドレスも入っています。この関数のアドレスに DTrace の sym() アクションを使って関数名を取得しています。arg1 に格納されていたデータはカーネルモジュール内のローカル変数です。通常はローカル変数を DTrace から自動で取得する事は困難ですが、SDT プロバイダを利用する事で、簡単に手繰り寄せる事が出来る様になっています。 \*\*\* SDT プロバイダの使用例 2 \*\*\* # dtrace -qn 'sdt:::taskq-exec-start {@agg[sym((uintptr_t)((taskq_ent_t \*)arg1) ->tqent_func)]=count()} tick-10sec{printa(@agg);exit(0)}' rpcmod`endpnt_reclaim 1 genunix`kmem_reap_done 1 genunix`kmem_reap_start 1 genunix`kmem_cache_reap 385 genunix`callout_execute 515 ~~~~~~~~~~~~~~~ これが関数名 ~~~ 呼び出し回数以下は SDT プロバイダのプローブを使用して ZFS の ARC のキャッシュヒットとキャッシュミスをカウントする例です。毎秒、キャッシュヒット / ミスが発生した回数を数えて出力しています。この様に、SDT プロバイダを使用するとプログラム内のあらゆるデータを取得する事が出来ます。arc-hit, arc-miss プローブのソースコードは /usr/src/uts/common/fs/zfs/arc.c にあります。 \*\*\* SDT プロバイダの使用例 3 \*\*\* # dtrace -qn 'BEGIN{printf("hit\\tmiss\\n")} sdt:::arc-hit{hit++} sdt:::arc-miss{miss++} tick-1sec{printf("%d\\t%d\\n", hit,miss);hit = miss =0} tick-5sec{exit(0)}' hit miss 2035 60 0 0 1436 10 886 99 1061 164Sched プロバイダも使用してみましょう。以下は Sched プロバイダの preempt プローブを使用して、プリエンプションが発生した回数を CPU 毎に集計しています。preempt プローブのソースコードは /usr/src/uts/common/disp/disp.c#687 にあります。 \*\*\* Sched プロバイダの使用例 \*\*\* # dtrace -qn 'BEGIN{printf("\\tcpu\\t\\tnum\\n")} sched:::preempt{@agg[cpu]=count()} tick-1sec{printa(@agg); clear(@agg)} tick-5sec{exit(0)}' cpu num 3 1 2 4 1 28 0 55 3 0 2 1 1 27 0 46 3 0 2 1 1 12 0 19 3 0 2 1 0 25 1 36 2 0 3 1 0 29 1 36 SDT プロバイダの仕組みここからは SDT プロバイダの仕組みを、先ほどの arc-miss プローブを例にして見て行きたいと思います。 \*\*\* arc-miss プローブ \*\*\* # dtrace -ln 'sdt:zfs:arc_read_nolock:arc-miss' ID PROVIDER MODULE FUNCTION NAME 5628 sdt zfs arc_read_nolock arc-miss DTRACE_PROBE マクロSDT プロバイダを使用する為にはソースコードに SDT 用のコードを埋め込む必要があります。埋め込むコードは、使い易い様にマクロとして定義されています。マクロの定義は /usr/src/uts/common/sys/sdt.h にあります。定義されているマクロの名前は、作成するプローブに渡したい変数の個数に応じて、変数を渡さない DTRACE_PROBE マクロ、変数を一つだけ渡す DTRACE_PROBE1 マクロから、変数を 5 個渡す DTRACE_PROBE5 まで、6 個のマクロが用意されています。このマクロに引数を設定してソースコードに記述すると、SDT プロバイダのプローブになります。 \*\*\* DTRACE_PROBE マクロ \*\*\* 75 #else /\* _KERNEL \*/ 76 77 #defineDTRACE_PROBE(name){\\ 78 extern void __dtrace_probe_##name(void);\\ 79 __dtrace_probe_##name();\\ 80 } 81 82 #defineDTRACE_PROBE1(name, type1, arg1) {\\ 83 extern void __dtrace_probe_##name(uintptr_t);\\ 84 __dtrace_probe_##name((uintptr_t)(arg1));\\ 85 } ...実際にソースコード内に記述されている例を見てみましょう。arc-miss プローブのソースコードは /usr/src/uts/common/fs/zfs/arc.c#2797 にあります。"DTRACE_PROBE4(arc__miss, arc_buf_hdr_t \*, hdr, blkptr_t \*, bp, uint64_t, size, zbookmark_t \*, zb);" が埋め込まれたプローブです。最初の引数の "arc__miss" がプローブ名の指定です。"__" は DTrace によって "-" に変換されます。その為、ソースコードからプローブの実装場所を探す際は、プローブ名の "-" を "__" にして検索してください。 \*\*\* arc-miss プローブのソースコード \*\*\* 2794 mutex_exit(hash_lock); 2795 2796 ASSERT3U(hdr->b_size, ==, size); 2797 DTRACE_PROBE4(arc__miss, arc_buf_hdr_t \*, hdr, blkptr_t \*, bp, <-- ここ! 2798 uint64_t, size, zbookmark_t \*, zb); 2799 ARCSTAT_BUMP(arcstat_misses); 2800 ARCSTAT_CONDSTAT(!(hdr->b_flags & ARC_PREFETCH), 2801 demand, prefetch, hdr->b_type != ARC_BUFC_METADATA, 2802 data, metadata, misses);DTRACE_PROBE4 はプローブに変数を 4 つ渡すマクロです。プローブに渡す変数はマクロに引数として与えます。DTRACE_PROBE4 マクロは全部で 9 つの引数を取ります。先ほどご説明しました通り、最初の引数はプローブ名です。"arc__miss" という文字列は "arc-miss" というプローブ名に変換されます。2 番目以降の引数は、プローブに渡す変数の型と、その値を格納した変数の名前のペアです。ここで言う変数の名前はマクロを埋め込むソースコード内での変数の名前です。プローブに渡された後の変数の名前は、スクリプト内の変数と名前が衝突しない様に DTrace によって argN という形式で作成されます。たとえば DTRACE_PROBE4 マクロの第 2 引数は "arc_buf_hdr_t \*" で第 3 引数が "hdr" なので、arc-miss プローブに渡される最初の変数は "arc_buf_hdr_t \*" 型の "hdr" 変数の値になり、実際に arc-miss プローブから参照する際は arg0 という名前の変数になります。同じ様に、第 4 引数は "blkptr_t \*" で第 5 引数が "bp" なので、arc-miss プローブの arg1 変数は "blkptr_t \*" 型の "bp" 変数の値が格納されます。同じく arg2 には "uint64_t" 型の "size" 変数の値が、arg3 には "zbookmark_t \*" 型の "zb" 変数の値が格納されます。以下のコマンドは arc-miss プローブの arg2 変数を出力していますが、実際にはカーネル内の "uint64_t" 型の "size" 変数が出力されていることになります。 \*\*\* プローブに渡された変数の参照は argN \*\*\* # dtrace -qn 'sdt:::arc-miss{printf("%u\\n", arg2)}' 2890529992504 2890529992504 2890529992504 2890529992504 2890529992504 __dtrace_probe_[name] エントリDTRACE_PROBE マクロを記述したソースコードをコンパイルすると __dtrace_probe_[name] という名前でダミーのシンボルが作成されます。[name] は DTRACE_PROBE マクロの第 1 引数で指定したプローブ名です。また、これと同時にプローブに渡される変数も用意されます。arc-miss プローブの場合は __dtrace_probe_arc__miss という名前のシンボルが作成されます。"arc__miss" になっているのは先ほど見たソースコードで指定されている通りです。nm コマンドで __dtrace_probe_arc__miss の情報を見てみると UNDEF となっているので、実態は無く、シンボルだけが存在している事が分かります。 \*\*\* __dtrace_probe_arc__miss は UNDEF \*\*\* # nm /kernel/drv/amd64/zfs | grep __dtrace_probe_arc__miss [2672] | 0| 0|NOTY |GLOB |0 |UNDEF |__dtrace_probe_arc__miss リロケーション__dtrace_probe_[name] というダミーのシンボルはプログラムがロードされる時に実行時リンカーで書き換えられます。カーネル内のシンボルの場合は krtld がバイナリの書き換えを行います。書き換えの処理は x86_64 Solaris の場合は /usr/src/uts/intel/amd64/krtld/kobj_reloc.c に実装されています。instr が指しているのがダミーのシンボルです。ここではダミーのシンボルの 1 バイト前から、全部で 5 バイトを nop 命令に書き換えています。 \*\*\* ダミーのシンボルは nop x5 に置き換えられます \*\*\* 86 #defineSDT_NOP0x90 87 #defineSDT_NOPS5 88 89 static int 90 sdt_reloc_resolve(struct module \*mp, char \*symname, uint8_t \*instr) 91 { ... 116 for (i = 0; i < SDT_NOPS; i++) 117 instr[i - 1] = SDT_NOP; <-- ここで書き換えています ...elfdump コマンドで zfs モジュールのリロケーションセクションを見てみると、__dtrace_probe_arc__miss がエントリーされています。オフセットは 0x3663 です。 \*\*\* リロケーションセクションの __dtrace_probe_arc__miss シンボル \*\*\* # elfdump -r /kernel/drv/amd64/zfs Relocation Section: .rela.eh_frame type offset addend section symbol ... R_AMD64_PC32 0x3663 0xfffffffffffffffc .rela.text __dtrace_probe_arc__missdis コマンドを使用して 0x3663 に何があるかを確かめてみます。dis コマンドはディスアセンブラで、/usr/ccs/bin/dis にあります。"-n" オプションはシンボル名の代わりに絶対アドレスで表示するオプションです。krtld によって書き換えられるのはダミーのシンボルの 1 バイト前から全部で 5 バイトでした。ここでは 0x3662 からの 5 バイトに相当し、丁度 arc_read_nolock() 関数の中の "call +0x5" という命令の部分です。 \*\*\* __dtrace_probe_arc__miss が指す先には call +0x5 がありました \*\*\* # dis -n /kernel/drv/amd64/zfs ... arc_read_nolock() ... 0x365b: 48 8b 75 a8 movq -0x58(%rbp),%rsi 0x365f: 4c 89 e7 movq %r12,%rdi 0x3662: e8 00 00 00 00 call +0x5 <0x3667> ~~~~~~~~~~~~~~ ここが該当部分 0x3667: be 01 00 00 00 movl $0x1,%esi 0x366c: 48 c7 c7 00 00 00 movq $0x0,%rdi同じ場所をシンボル名込みで見てみると arc_read_nolock+0x3e3 に相当する事が分かります。先ほどの dis コマンドの "-n" オプションを外し、"-F" オプションに関数名の arc_read_nolock を指定して実行します。 # dis -F arc_read_nolock /kernel/drv/amd64/zfs disassembly for /kernel/drv/amd64/zfs arc_read_nolock() ... arc_read_nolock+0x3db: 48 8b 75 a8 movq -0x58(%rbp),%rsi arc_read_nolock+0x3df: 4c 89 e7 movq %r12,%rdi arc_read_nolock+0x3e2: e8 00 00 00 00 call +0x5 <arc_read_nolock+0x3e7> <- これ!! arc_read_nolock+0x3e7: be 01 00 00 00 movl $0x1,%esi arc_read_nolock+0x3ec: 48 c7 c7 00 00 00 movq $0x0,%rdiカーネルにロードされたオブジェクトファイルをディスアセンブルすると、arc_read_nolock+0x3e3 の前後が nop に置き換えられている事が分かります。カーネルにロードされたファイルのディスアセンブルは mdb コマンドを使用します。 \*\*\* ロードされたバイナリをディスアセンブル \*\*\* # mdb -k Loading modules: [ unix krtld genunix specfs dtrace cpu.generic cpu_ms.AuthenticAMD.15 uppc pcplusmp ufs mpt ip hook neti sctp arp usba fcp fctl nca lofs zfs md cpc random crypto fcip logindmux ptm sppp nfs ] > arc_read_nolock+0x3e3::dis arc_read_nolock+0x3b9: call +0x35ed7 <vdev_is_dead> arc_read_nolock+0x3be: testl %eax,%eax arc_read_nolock+0x3c0: je +0x442 <arc_read_nolock+0x802> arc_read_nolock+0x3c6: movq $0x0,-0x60(%rbp) arc_read_nolock+0x3ce: movq -0x30(%rbp),%rdi arc_read_nolock+0x3d2: call +0xc1ee4ce <mutex_exit> arc_read_nolock+0x3d7: movq 0x20(%rbp),%rdx arc_read_nolock+0x3db: movq -0x58(%rbp),%rsi arc_read_nolock+0x3df: movq %r12,%rdi arc_read_nolock+0x3e2: nop <-- ここから nop が 5 つ arc_read_nolock+0x3e3: nop arc_read_nolock+0x3e4: nop arc_read_nolock+0x3e5: nop arc_read_nolock+0x3e6: nop arc_read_nolock+0x3e7: movl $0x1,%esi arc_read_nolock+0x3ec: movq $0xffffffffc046d070,%rdi arc_read_nolock+0x3f3: call +0xc220e8d <atomic_add_64> arc_read_nolock+0x3f8: testb $0x8,0x40(%rbx) arc_read_nolock+0x3fc: jne +0x2b6 <arc_read_nolock+0x6b2> arc_read_nolock+0x402: cmpl $0x1,0x54(%rbx) arc_read_nolock+0x406: movl $0x1,%esiこれで __dtrace_probe_arc__miss がリロケーションされて nop 命令に書き換えられていることが確認出来ました。この nop が DTrace のプローブポイントになる場所です。同じ様な nop は Solaris のカーネルのあちこちに埋め込まれており、DTrace のプローブの発動を待っています。nop 命令が 5 つだけですので、プローブが発動していない間は殆ど性能への影響はありません。 パッチング該当する DTrace のプローブが有効化されると先ほどの nop がメモリ上でパッチされ、DTrace の処理に接続されます。パッチ処理は x86_64 では /usr/src/uts/intel/dtrace/sdt.c に実装されています。x86 では nop の一つが lock プリフィックスに書き換えられます。SDT_PATCHVAL マクロに格納されている 0xf0 が lock プリフィックスです。 \*\*\* メモリ上のプログラムがパッチされて 0xf0 に書き換えられています \*\*\* 42 #defineSDT_PATCHVAL0xf0 ... 182 sdp->sdp_patchval = SDT_PATCHVAL; ... 307 while (sdp != NULL) { 308 \*sdp->sdp_patchpoint = sdp->sdp_patchval; <-- ここで書き換えています 309 sdp = sdp->sdp_next; 310 }'sdt:zfs:arc_read_nolock:arc-miss' プローブを有効にした状態でメモリ上の命令を見てみます。 \*\*\* arc-miss プローブを有効化 \*\*\* # dtrace -n 'sdt:zfs:arc_read_nolock:arc-miss' dtrace: description 'sdt:zfs:arc_read_nolock:arc-miss' matched 1 probe再び mdb コマンドで確認すると、今度は nop の一つが lock nop に変わっています。プローブを有効にしたため、メモリ上のプログラムにパッチが当たり、命令が書き変わっている事が分かりました。 \*\*\* arc_read_nolock+0x3e3 が lock nop に変わりました \*\*\* # mdb -k Loading modules: [ unix krtld genunix specfs dtrace cpu.generic cpu_ms.AuthenticAMD.15 uppc pcplusmp ufs mpt ip hook neti sctp arp usba fcp fctl nca lofs zfs md cpc random crypto fcip logindmux ptm sppp nfs ] > arc_read_nolock+0x3e3::dis arc_read_nolock+0x3b9: call +0x35ed7 <vdev_is_dead> arc_read_nolock+0x3be: testl %eax,%eax arc_read_nolock+0x3c0: je +0x442 <arc_read_nolock+0x802> arc_read_nolock+0x3c6: movq $0x0,-0x60(%rbp) arc_read_nolock+0x3ce: movq -0x30(%rbp),%rdi arc_read_nolock+0x3d2: call +0xc1ee4ce <mutex_exit> arc_read_nolock+0x3d7: movq 0x20(%rbp),%rdx arc_read_nolock+0x3db: movq -0x58(%rbp),%rsi arc_read_nolock+0x3df: movq %r12,%rdi arc_read_nolock+0x3e2: nop arc_read_nolock+0x3e3: lock nop <-- ここ!! arc_read_nolock+0x3e5: nop arc_read_nolock+0x3e6: nop arc_read_nolock+0x3e7: movl $0x1,%esi arc_read_nolock+0x3ec: movq $0xffffffffc046d070,%rdi arc_read_nolock+0x3f3: call +0xc220e8d <atomic_add_64> arc_read_nolock+0x3f8: testb $0x8,0x40(%rbx) arc_read_nolock+0x3fc: jne +0x2b6 <arc_read_nolock+0x6b2> arc_read_nolock+0x402: cmpl $0x1,0x54(%rbx) arc_read_nolock+0x406: movl $0x1,%esi arc_read_nolock+0x40b: movq $0xffffffffc046d0d0,%rdi Undefined Opcode Exception実は、先ほど書き換えに使用した lock nop という命令は CPU には実装されていません。CPU に実装されていない命令は #UD (Undefined Opcode) Exception を発生させます。Solaris では #UD Exception が発生すると invoptrap というハンドラが呼び出され、そのハンドラの中の call dtrace_invop で DTrace に制御を渡しています。invoptrap は /usr/src/uts/intel/ia32/ml/exception.s#379 に実装されています。 \*\*\* invoptrap から dtrace_invop を呼び出しています \*\*\* 379 ENTRY_NP(invoptrap) 380 381 XPV_TRAP_POP 382 383 cmpw$KCS_SEL, 8(%rsp) 384 jneud_user 385 386 #if defined(__xpv) 387 movb$0, 12(%rsp)/\* clear saved upcall_mask from %cs \*/ 388 #endif 389 push$0/\* error code -- zero for #UD \*/ 390 ud_kernel: 391 push$0xdddd/\* a dummy trap number \*/ 392 INTR_PUSH 393 movqREGOFF_RIP(%rsp), %rdi 394 movqREGOFF_RSP(%rsp), %rsi 395 movqREGOFF_RAX(%rsp), %rdx 396 pushq(%rsi) 397 movq%rsp, %rsi 398 calldtrace_invop <-- dtrace_invop() の呼び出しdtrace_invop() は /usr/src/uts/i86pc/os/dtrace_subr.c#dtrace_invop にあります。 \*\*\* dtrace_invop() の実装 \*\*\* 44 int 45 dtrace_invop(uintptr_t addr, uintptr_t \*stack, uintptr_t eax) 46 { 47 dtrace_invop_hdlr_t \*hdlr; 48 int rval; 49 50 for (hdlr = dtrace_invop_hdlr; hdlr != NULL; hdlr = hdlr->dtih_next) { 51 if ((rval = hdlr->dtih_func(addr, stack, eax)) != 0) 52 return (rval); 53 } 54 55 return (0); 56 }これは DTrace に処理を渡す為に、わざと CPU に実装されていない命令を実行させている事になります。何故この様な実装にしているのかと言うと、一つにはオーバーヘッドを最小限にする為です。これまで見て来た方法なら、プローブが有効になっていない間のオーバーヘッドは nop が数命令で済みます。これは殆ど無視して良い量です。プローブが有効になったら nop 命令を一つだけ書き換えれば良いので、影響範囲が小さく、安全でもあります。性能と安全は DTrace の実装ポリシーの大きな柱になっています。 まとめ ソースコードに DTRACE_PROBE マクロを挿入すると SDT プロバイダが使える様になります。 DTRACE_PROBE マクロは、コンパイルされると __dtrace_probe_[name] というダミーのエントリポイントになりました。 バイナリがロードされると、__dtrace_probe_[name] エントリはリンカーのリロケーションにより nop が 5 つに置換されました。 DTrace のプローブを有効にすると 2 番目の nop が lock に書き換えられました。 lock nop は #UD Exception を発生させ、そのハンドラの中で DTrace に制御を移していました。 以上で DTrace に処理が受け渡されました。これが x86_64 環境での SDT プロバイダの動きです。 SDT プロバイダのオーバーヘッドDTrace の重要な特徴の一つに、プローブが有効になっていない時は一切のオーバーヘッドが無いという点があります。SDT プロバイダはこの特徴の殆ど唯一の例外です。既に見た様に、SDT はプログラムに nop を埋め込みます。また、プローブに渡す引数はプローブが有効になっていない場合も用意されます。この 2 つはプローブを disable にしていても発生するオーバーヘッドなので disabled probe effect と呼ばれています。ただし、nop は何もしない命令で、メモリやレジスタを消費しませんし、負荷の量は殆ど無視出来ます。また、プローブに渡す引数も大抵の場合はローカル変数への参照なので、殆ど負荷にはなりません。更に Solaris に埋め込まれた SDT プロバイダのプローブは注意深く場所を選んで配置されており、十分にテストされている為、これらが性能に影響を与える事はありません。一方、プローブが有効になっている場合の負荷は通常の DTrace の負荷と同じです。こちらも、ポイントを絞って常識的な使い方をしていれば問題になる事は無いと思います。 おわりに以上、SDT プロバイダーの使い方、仕組み、オーバーヘッドをご紹介しました。SDT プロバイダーは DTrace の中でも重要なプロバイダーの一つです。是非、使い方をマスターして有効に使ってください。今回はカーネル内の SDT プローブを中心にご説明しましたが、SDT プロバイダが一番効果を発揮するのは実はユーザランドで使用した時です。ユーザランドでの SDT プロバイダの使い方は機会を改めてご説明させて頂きたいと思います。 参考文献http://www.usenix.org/events/usenix04/tech/general/full_papers/cantrill/cantrill_html/index.html はオリジナルの DTrace ペーパーです。http://hub.opensolaris.org/bin/download/User+Group+czosug/events_archive/czosug2dtracex86.pdf に x86 上での DTrace の実装がまとめられています。http://docs.sun.com/app/docs/doc/819-0395/chp-sdt に SDT のマニュアルがあります。http://wikis.sun.com/display/DTrace/sdt+Providerhttp://mediacast.sun.com/users/alan.hargreaves@sun.com/media/sdtprobes.pdf/detailshttp://blogs.sun.com/tpenta/entry/dtrace_using_placing_sdt_probeshttp://www.solarisinternals.com/wiki/index.php/DTrace_Topics_Overheadhttp://aru-and-dhi.blogspot.com/2009_02_01_archive.html ソースコードhttp://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/dtrace/sdt.chttp://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sparc/dtrace/sdt.chttp://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/sdt_impl.h/usr/src/uts/common/sys/sdt.h にプローブ挿入用のマクロがあります。/usr/src/uts/intel/amd64/krtld/kobj_reloc.c にリロケーション関数があります。/usr/src/lib/libdtrace/common/dt_link.c#871 はユーザランドのリロケーションの実装です。

はじめに 今回は DTrace の SDT プロバイダの仕組みをご紹介します。SDT プロバイダは FBT プロバイダや PID プロバイダと並んで、DTrace の基盤となるプロバイダです。SDT プロバイダの仕組みを理解する事で、DTrace への理解も深まる事と思います。 SDT プロバイダとは SDT(Statically Defined Tracing) プロバイダはソースコードの中に...

Sun

GlassFishロードバランサコンフィグレータを使ってみよう

今回は、GlassFishアプリケーションサーバを高可用性構成で利用するときに使用すると便利な、ロードバランサプラグインを設定してみましょう。HADBバンドル版のGlassFish EnterpriseServerを利用する際は、インストーラにてロードバランサプラグインもインストールされますので、それほど導入に煩雑さはありません。しかし、コミュニティ版のGlassFishや、HADBの付属しないGlassFish EnterpriseServerを利用する際は、ロードバランサプラグインを別途ダウンロードしてきて手動でインストール/設定を行う必要がありました。このたび、ロードバランサプラグインのインストール/設定をGUI画面で簡単に実施する為のGlassFish LoadBalancer Configuratorのベータ版がリリースされたので、インストール/設定を紹介いたします。今回使用するバイナリは以下のものです。Sun GlassFish Enterprise Server v2.1.1Sun Web Server 7 update7GlassFish LoadBalancer Configuratorインストール手順インストール環境の確認GlassFish DAS(Domain管理サーバ)のインストールGlassFish nodeagentのインストールGlassFishクラスタの作成GlassFish DASのSSL設定Web Serverのインストールロードバランサプラグイン設定の為のDAS証明書の取り出しロードバランサプラグインのインストール設定ロードバランサの設定接続の確認インストール環境の確認まず、GlassFishによるクラスタ環境を作成しますので、3つのホスト(今回はSolarisゾーン)を用意します。それぞれ、global, node1, node2という名前にしました。このglobalに、GlassFish Domain管理サーバとロードバランサ用のWeb Server。node1とnode2には、GlassFishのnodeagent(+インスタンス)をインストールします。GlassFish DAS(Domain管理サーバ)のインストールそれでは最初にDomain管理サーバをインストールします。global# pwd /shareglobal# ls -l合計 179851-rwxr-xr-x 1 root root 91964589 1月 15日 17:18 sges-2_1_1-solaris-i586-ml.binglobal# ./sges-2_1_1-solaris-i586-ml.bin インストールが完了したら、アプリケーションサーバを起動します。global# /opt/SUNWappserver/bin/asadmin start-domain domain1ドメイン domain1 を起動しています。お待ちください。デフォルトのログの場所は /opt/SUNWappserver/domains/domain1/logs/server.log です。出力を /opt/SUNWappserver/domains/domain1/logs/server.log にリダイレクトしていますドメイン domain1 はクライアントの要求を受信する準備ができています。追加のサービスがバックグラウンドで開始されます。 ドメイン [domain1] はその設定で [Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs)] を実行しています。ログは [/opt/SUNWappserver/domains] にあります。管理コンソールは [http://localhost:4848] で使用できます。"asadmin" コマンドにも同じポート [4848] を使用します。ユーザーの Web アプリケーションは次の URL で使用できます:[http://localhost:8080 https://localhost:8181 ]。次の web-contexts を使用できます:[/web1 /__wstx-services ]。標準の JMX クライアント (JConsole など) はドメイン管理のために JMXServiceURL:[service:jmx:rmi:///jndi/rmi://global:8686/jmxrmi] に接続できます。ドメインは少なくとも次のポートで接続を待機しています:[8080 8181 4848 3700 3820 3920 8686 ]。ドメインはアプリケーションサーバークラスタおよびその他のスタンドアロンインスタンスをサポートしません。global# その後、管理Web画面から、クラスタサポートの追加を実行します。global# /opt/SUNWappserver/bin/asadmin start-domain domain1ドメイン domain1 を起動しています。お待ちください。デフォルトのログの場所は /opt/SUNWappserver/domains/domain1/logs/server.log です。出力を /opt/SUNWappserver/domains/domain1/logs/server.log にリダイレクトしていますドメイン domain1 が起動しました。ドメイン [domain1] はその設定で [Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs)] を実行しています。ログは [/opt/SUNWappserver/domains] にあります。管理コンソールは [http://localhost:4848] で使用できます。"asadmin" コマンドにも同じポート [4848] を使用します。ユーザーの Web アプリケーションは次の URL で使用できます:[http://localhost:8080 https://localhost:8181 ]。次の web-contexts を使用できます:[/web1 /__wstx-services ]。標準の JMX クライアント (JConsole など) はドメイン管理のために JMXServiceURL:[service:jmx:rmi:///jndi/rmi://global:8686/jmxrmi] に接続できます。ドメインは少なくとも次のポートで接続を待機しています:[8080 8181 4848 3700 3820 3920 8686 ]。ドメインはアプリケーションサーバークラスタおよびその他のスタンドアロンインスタンスをサポートします。global# これでドメイン管理サーバ(DAS)が完成しました。GlassFish nodeagentのインストールつづいて、node1, node2にnodeagentをインストールします。nodeagentのインストールでも、バイナリのインストール自体はDASの時と同じです。その後、デフォルトでインストールされるDomainを起動させずに削除して、nodeagentの作成を行います。node1# pwd/net/global/sharenode1# ls -l合計 179851-rwxr-xr-x 1 root root 91964589 1月 15日 17:18 sges-2_1_1-solaris-i586-ml.binnode1# ./sges-2_1_1-solaris-i586-ml.bin Connecting to X11 server 'localhost:10.0'.Java Accessibility Bridge for GNOME loaded.node1# /opt/SUNWappserver/bin/asadmin delete-domain domain1ドメイン domain1 は削除されました。node1# /opt/SUNWappserver/bin/asadmin create-node-agent --host global --user admin nodeagent1管理パスワードを入力してください>コマンド create-node-agent は正常に実行されました。node1# /opt/SUNWappserver/bin/asadmin start-node-agent nodeagent1管理ユーザー名を入力してください>admin管理パスワードを入力してください>マスターパスワードを入力してください [デフォルトを使用する場合は Enter キー]:>出力を /opt/SUNWappserver/nodeagents/nodeagent1/agent/logs/server.log にリダイレクトしていますアプリケーション出力を /opt/SUNWappserver/nodeagents/nodeagent1/agent/logs/server.log にリダイレクトしますコマンド start-node-agent は正常に実行されました。node1# node2# pwd/net/global/sharenode2# ls -l合計 179851-rwxr-xr-x 1 root root 91964589 1月 15日 17:18 sges-2_1_1-solaris-i586-ml.binnode2# ./sges-2_1_1-solaris-i586-ml.bin Connecting to X11 server 'localhost:10.0'.Java Accessibility Bridge for GNOME loaded.node2# /opt/SUNWappserver/bin/asadmin delete-domain domain1ドメイン domain1 は削除されました。node2# /opt/SUNWappserver/bin/asadmin create-node-agent --host global --user admin nodeagent2管理パスワードを入力してください>コマンド create-node-agent は正常に実行されました。node2# /opt/SUNWappserver/bin/asadmin start-node-agent nodeagent2管理ユーザー名を入力してください>admin管理パスワードを入力してください>マスターパスワードを入力してください [デフォルトを使用する場合は Enter キー]:>出力を /opt/SUNWappserver/nodeagents/nodeagent2/agent/logs/server.log にリダイレクトしていますアプリケーション出力を /opt/SUNWappserver/nodeagents/nodeagent2/agent/logs/server.log にリダイレクトしますコマンド start-node-agent は正常に実行されました。node2# GlassFishクラスタの作成Domain管理サーバとnodeagentが用意できたら、クラスタを作成しましょう。クラスタ環境が作成できたら、サンプルアプリケーションを配備しておきましょう。GlassFish DASのSSL設定ここで、GlassFish管理画面への接続にSSLを利用する設定をしておきましょう。global# /opt/SUNWappserver/bin/asadmin stop-domain ドメイン domain1 が停止しました。global# /opt/SUNWappserver/bin/asadmin start-domain domain1ドメイン domain1 を起動しています。お待ちください。デフォルトのログの場所は /opt/SUNWappserver/domains/domain1/logs/server.log です。出力を /opt/SUNWappserver/domains/domain1/logs/server.log にリダイレクトしていますドメイン domain1 が起動しました。ドメイン [domain1] はその設定で [Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs)] を実行しています。ログは [/opt/SUNWappserver/domains] にあります。管理コンソールは [https://localhost:4848] で使用できます。"asadmin" コマンドにも同じポート [4848] を使用します。ユーザーの Web アプリケーションは次の URL で使用できます:[http://localhost:8080 https://localhost:8181 ]。次の web-contexts を使用できます:[/web1 /__wstx-services ]。標準の JMX クライアント (JConsole など) はドメイン管理のために JMXServiceURL:[service:jmx:rmi:///jndi/rmi://global:8686/jmxrmi] に接続できます。ドメインは少なくとも次のポートで接続を待機しています:[8080 8181 4848 3700 3820 3920 8686 ]。ドメインはアプリケーションサーバークラス���およびその他のスタンドアロンインスタンスをサポートします。global# Web Serverのインストール今回は、ロードバランサ用にSun Web Server 7をインストールします。global# pwd/share/sjswsglobal# ls -l合計 591301drwxr-xr-x 2 10 143 6 12月 15日 16:42 Legal-rw-r--r-- 1 10 143 711 12月 15日 16:42 README.txtdrwxr-xr-x 3 10 143 15 12月 15日 18:06 WebServer-rwxr-xr-x 1 10 143 27024 12月 15日 16:42 setup-rw-r--r-- 1 root root 302493184 1月 19日 17:23 sjsws-7_0u7-solaris-x86.targlobal# ./setup 後述しますが、ロードバランサの設定においてWeb ServerでSSLを使う事になりますので、Web Serverのインストールが完了したら、インスタンスのSSL設定を行っておきましょう。SSLの設定までできたら、Web Serverを起動します。ロードバランサプラグイン設定の為のDAS証明書の取り出しロードバランサ用のWeb ServerとGlassFish DASをクライアント認証を利用したSSL接続を行う設定をする事で、GlassFish DASの画面からWeb Server上のロードバランサの設定を自動更新する事が可能になりますので、クライアント認証を行えるようにDASの証明書を用意します。global# which keytool /usr/bin/keytoolglobal# pwd /opt/SUNWappserver/domains/domain1/configglobal# ls keystore.jks keystore.jksglobal# keytool -export -rfc -alias s1as -keystore ./keystore.jks -file s1as.rfcキーストアのパスワードを入力してください: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 警告 警告 警告 \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* キーストアに保存された情報の完全性は検証されて \*\* いません! 完全性を検証するには、キーストアの \*\* パスワードを入力する必要があります。 \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 警告 警告 警告 \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*証明書がファイル に保存されました。global# ls s1as.rfc s1as.rfcglobal# ロードバランサプラグインのインストール設定ここまでは、環境の用意でしたが、今回の記事はここからが本番です。それでは、ロードバランサコンフィグレータを利用してみましょう。global# pwd/share/glassfish-lbconfiguratorglobal# lsUser_Guide.pdf legalglassfish-lbconfigurator.jarglobal# java -jar glassfish-lbconfigurator.jar Java Accessibility Bridge for GNOME loaded.global# ロードバランサの設定これまでの設定でGlassFishからロードバランサの設定を行えるようになりましたので、早速、ロードバランサを設定してみましょう。接続の確認設定が完了しましたので、接続確認してみます。以上でロードバランサの設定が完了しました。GlassFish LoadBalancer Configuratorの登場でHADBバンドル版以外のGlassFishでも比較的容易にロードバランサプラグインの設定が行えるようになりましたので、興味がある方はぜひ試してみて下さい。※参考資料Sun GlassFish Enterprise Server 2.1 高可用性 (HA) 管理ガイド -> 5. HTTP 負荷分散のための Web サーバーの設定Sun GlassFish Enterprise Server 2.1 高可用性 (HA) 管理ガイド -> 2. Enterprise Server でのクラスタの設定To Install the Load Balancing Plug-in (standalone)

今回は、GlassFishアプリケーションサーバを高可用性構成で利用するときに 使用すると便利な、ロードバランサプラグインを設定してみましょう。 HADBバンドル版のGlassFish Enterprise Serverを利用する際は、インストーラにてロードバランサプラグインもインストールされますので、それほど導入に煩雑さはありません。 しかし、コミュニティ版のGlassFishや、HADBの付属しない...

Sun

Sun FlashFire 製品が出揃いました

今月、Sun Flash Accelerator F20 PCIe Card が販売開始になりました。これで Sun FlashFire 製品が一通り揃いましたので、簡単にラインナップを紹介します。フラッシュ・モジュール フラッシュ・モジュールは、サンのブレードサーバ Sun Blade X6275(Intel Xeon Processor 5500 Series X 4 CPU)の内蔵ストレージとして採用されております。 ちなみに Sun Blade X6275 には内蔵ストレージとして HDD 用のベイは存在せず、24GB の Flash Module x 2 のみとなっております。SSD SSD は、T シリーズや X シリーズサーバの内蔵ディスクスロットに挿入して使用します。32GB の SSD は、特定ファイルシステムの IO 性能を高めたい時や、ZFS Hybrid Poolを簡単に作成したい時に便利です。また、サンの SSD は、ストレージアプライアンス製品 Sun Storage 7000 シリーズにも採用されております。 ちなみに、サンの SSD は全てパフォーマンスと信頼性に優れた SLC を採用しております。Sun Flash Accelerator F20 PCIe Card 今月発売開始になりました PCI-express カードタイプの Flash Storage です。総容量は 96 GB ですが、このカードを搭載すると、OSからは 24GB x 4 個の SATA Disk として認識されます。F20 は、Flash Disk を使いたいがサーバの内蔵ディスクベイに SSD を入れるスペースが無い場合や、90 GBぐらいの Flash Disk 領域が欲しい時に活躍します。 ちなみにこの F20 は、今話題の Oracle Exadata V2 にも組み込まれています。Sun Storage F5100高さ 1U で最大 1.92TB の容量を誇り、100 万 IOPS 以上を達成します。この性能は、ディスクドライブに換算すると、 3,000 台以上の IOPS 性能になりますので、IOPS 比でディスクドライブと比較すると低価格/省スペース/低消費電力/のストレージになります。 ちなみに、F5100 の中身は、先ほど紹介した 24GB のフラッシュモジュールが最大 80 枚(24GB x 80 = 1.92TB)搭載可能で、OS からはフラッシュモジュールあたり 1 個の SATA ドライブとして認識されます。最後に、今年は、サンにとって Flash Storage 元年になりました。来年の爆発的な需要を楽しみにしております。(参考情報)過去の 「やっぱり Sun がスキ!」blog 記事一覧はこちらを参照下さい。http://wikis.sun.com/display/yappri/Home

今月、 Sun Flash Accelerator F20 PCIe Card が販売開始になりました。 これで Sun FlashFire 製品が一通り揃いましたので、 簡単にラインナップを紹介します。 フラッシュ・モジュール  フラッシュ・モジュールは、サンのブレードサーバSun Blade X6275(Intel Xeon Processor 5500 Series X...

Sun

ロードアベレージとは何か

はじめに今回は UNIX で伝統的にシステム負荷の指標とされて来たロードアベレージの実装についてご紹介したいと思います。これまでロードアベレージは実行中および実行待ちのスレッドの数を集計した数値と言われており、過去の Solaris でもその様に実装されていました。しかし Solaris 10 以降はロードアベレージの内部実装が変更され、スレッド数をカウントする方式から CPU の処理時間とスレッドの実行待ち時間を加算する方式に変わっています(計算方法が変わっただけで、計算結果としてのロードアベレージの値が変わった訳ではありません)。では、具体的にどの様に変更されたのか見て行きましょう。 ロードアベレージが使用されている例まずロードアベレージが使われている場所を見てみましょう。Solaris ではロードアベレージは prstat, uptime, w などのコマンドで使用されています。ロードアベレージは 3 つの数値で表現されており、それぞれ直近の 1 分間、5 分間、15 分間のシステム負荷の平均値を大まかに反映しています。 prstat の load averages一番下の行の "load averages:" に続く 3 つの数値が、左から 1 分、5 分、15 分のロードアベレージを表しています。 % prstat -n 3 PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 10277 root 8056K 3944K sleep 59 0 10:06:12 0.1% named/5 25401 dh129379 3432K 2944K cpu1 49 0 0:00:00 0.1% prstat/1 25348 root 8672K 2624K sleep 59 0 0:00:02 0.0% sshd/1 Total: 109 processes, 308 lwps, load averages: 0.02, 0.02, 0.01 uptime の load averageロードアベレージを見る一番簡単な方法は uptime コマンドでしょう。見方は prstat コマンドの場合と一緒です。 % uptime 11:41am up 218 day(s), 1:07, 17 users, load average: 0.02, 0.02, 0.01 w の load averagew コマンドでもロードアベレージは表示されます。 % w 3:31pm up 221 day(s), 4:56, 16 users, load average: 0.02, 0.02, 0.02 User tty login@ idle JCPU PCPU what ... ロードアベレージの読み方シングルスレッドのプログラムが 1CPU を占有し続けるとロードアベレージの数値は次第に 1 に近付いて行きます。2 スレッドで 2CPU を占有し続けるとロードアベレージは最終的に 2 になります。また、1CPU しかないマシンで 1 スレッドが 1CPU を占有し、もう 1 スレッドが実行待ちキューに入っている状態が続く場合もロードアベレージは 2 になります。この様に、ロードアベレージは 1 CPU で処理可能な量を 1 とした場合の CPU リソースの要求量を反映した値です。一般に、ロードアベレージの値が CPU 数より多い場合は負荷が高い状態と言われています。Solaris 9 までのロードアベレージはスケジューラのキューに入っているカーネルスレッドの数を元にして計算されていますが、キューの中に CPU の数よりも多いスレッドが入っていた場合は処理待ちが発生しているので負荷が高いと看做せる、というのがその理由です。Solaris 10 以降で言えば、実行中のスレッドが使用した時間に加えて実行待ちをしているスレッドの待ち時間が多ければ負荷が高いという事になります。ロードアベレージはその名の通り負荷の平均値情報であり、短期的な負荷のピークやある時間の正確な負荷の情報を取り出す事は出来ません。Solaris では mpstat コマンドや vmstat コマンドを使用して、より精度の高いシステム負荷情報を取得する事が可能です。また後述する通り DTrace を使ってロードアベレージの元となるデータを取得する事も可能です。 ロードアベレージを取得する為のプログラミングインターフェイスuptime 等のコマンドからではなく、C 言語等で書いたプログラムから直接ロードアベレージ情報を取得する事も可能です。 getloadavg(3C)libc には getloadavg(3C) 関数 が用意されています。後述する通り getloadavg(3C) はシステムコールを呼び出しています。ロードアベレージをダンプするプログラム #include <sys/loadavg.h> int main() { double loadavg[LOADAVG_NSTATS]; getloadavg(loadavg, LOADAVG_NSTATS); printf(" 1MIN : %f\\n 5MIN : %f\\n 15MIN : %f\\n\\n", loadavg[0], loadavg[1], loadavg[2]); }使用方法は以下の通りです。 # ./loadavg 1MIN : 1.968750 5MIN : 1.089844 15MIN : 0.460938 1MIN : 1.968750 5MIN : 1.093750 15MIN : 0.460938 ... pset_getloadavg(3C)プロセッサセット毎のロードアベレージは pset_getloadavg(3C) 関数 で取得します。 ロードアベレージの実装ロードアベレージの値がどの様に算出されているのか、先ほど使用した getloadavg(3C) 関数を起点として実装を見て行きたいと思います。 loadavg.hgetloadavg(3C) を使用する際にインクルードする loadavg.h には LOADAVG_1MIN, LOADAVG_5MIN, LOADAVG_15MIN の 3 つのマクロが設定されており、ロードアベレージの数値が 1 分、5 分、15 分の 3 種類ある事が分かります。 #define LOADAVG_1MIN 0 #define LOADAVG_5MIN 1 #define LOADAVG_15MIN 2 #define LOADAVG_NSTATS 3 getloadavg(3C)続いて getloadavg(3C) の実装を見てみます。getloadavg(3C) の コード は 20 行ほどの簡単な物です。データ格納用のバッファを用意して __getloadavg() を呼び出し、その結果を浮動小数点数に直し、呼び出し元に返しています。なお FSCALE は (1 << 8) == 256 です。元の数値が下位 8bit 小数部の固定小数点数である為、256 で割って浮動小数点数にしています。 36 /\* 37 \* getloadavg -- get the time averaged run queues from the system 38 \*/ 39 int 40 getloadavg(double loadavg[], int nelem) 41 { 42 extern int __getloadavg(int \*buf, int nelem); 43 44 int i, buf[LOADAVG_NSTATS]; 45 46 if (nelem > LOADAVG_NSTATS) 47 nelem = LOADAVG_NSTATS; 48 49 if ((nelem = __getloadavg(buf, nelem)) == -1) 50 return (-1); 51 52 for (i = 0; i < nelem; i++) 53 loadavg[i] = (double)buf[i] / FSCALE; 54 55 return (nelem); 56 } __getloadavg()getloadavg(3C) から呼び出されている __getloadavg() の実装は ここ にあります。__getloadavg をラップしている SYSCALL2_RVAL1 が展開されると __getloadagv() になります。 34 SYSCALL2_RVAL1(__getloadavg,getloadavg) 35 RET 36 SET_SIZE(__getloadavg) SYSCALL2_RVAL1__getloadavg をラップしている SYSCALL2_RVAL1 は ここ にあります。このマクロが展開されると L192 は ENTRY(__getloadavg) になり、__getloadavg() のエントリポイントが作成されます。__getloadavg() の実装は SYSTRAP_RVAL1 の方です。 191 #defineSYSCALL2_RVAL1(entryname, trapname)\\ 192 ENTRY(entryname);\\ 193 SYSTRAP_RVAL1(trapname);\\ 194 SYSCERROR SYSTRAP_RVAL1SYSTRAP_RVAL1 は ここ にあります。引数はそのままで __SYSTRAP に置き換えられているだけです。 75 #defineSYSTRAP_RVAL1(name)__SYSTRAP(name) __SYSTRAP__SYSTRAP は ここ にあります。ここで SYS_/\*\*/name は SYS_getloadavg に展開されます。mov SYS_getloadavg, %g1; でシステムコール番号を設定し、ta SYSCALL_TRAPNUM でシステムコールを呼び出します (http://docs.sun.com/app/docs/doc/816-1681/6m83631kj) 。 70 #define__SYSTRAP(name)\\ 71 /\* CSTYLED \*/\\ 72 movSYS_/\*\*/name, %g1;\\ 73 taSYSCALL_TRAPNUM SYS_getloadavgSYS_getloadavg は ここ にあります。システムコールの 105 番が SYS_getloadavg です。先ほどの __SYSTRAP のマクロではシステムコールの番号に 105 番を指定してシステムコールを発生させていた事が分かります。 289 #defineSYS_getloadavg105 システムコールgetloadavg() システムコールが呼び出された時に実行されるカーネル側の関数の実装は ここ にあります。中で行っている処理は avenrun[] からデータをコピーして返しているだけです。 36 /\* 37 \* Extract elements of the raw avenrun array from the kernel for the 38 \* implementation of getloadavg(3c) 39 \*/ 40 int 41 getloadavg(int \*buf, int nelem) 42 { 43 int \*loadbuf = &avenrun[0]; 44 int loadavg[LOADAVG_NSTATS]; 45 int error; 46 47 if (nelem < 0) 48 return (set_errno(EINVAL)); 49 if (nelem > LOADAVG_NSTATS) 50 nelem = LOADAVG_NSTATS; 51 52 if (!INGLOBALZONE(curproc)) { 53 mutex_enter(&cpu_lock); 54 if (pool_pset_enabled()) { 55 psetid_t psetid = zone_pset_get(curproc->p_zone); 56 57 error = cpupart_get_loadavg(psetid, &loadavg[0], nelem); 58 ASSERT(error == 0);/\* pset isn't going anywhere \*/ 59 loadbuf = &loadavg[0]; 60 } 61 mutex_exit(&cpu_lock); 62 } 63 64 error = copyout(loadbuf, buf, nelem \* sizeof (avenrun[0])); 65 if (error) 66 return (set_errno(EFAULT)); 67 return (nelem); 68 } avenrun[]getloadavg() システムコールの中で参照されていた avenrun[] の実体は clock.c にあります。avenrun[] は int 型の配列です。コメントには実行キューの長さの平均と書かれています。 96 intavenrun[3];/\* FSCALED average run queue lengths \*/avenrun[] の値は clock.c の中で hp_avenrun[] 変数の値をシフトして求められています。hp_avenrun[] は高精度のロードアベレージ情報を格納した変数で、calcloadavg() 関数により更新されています。calcloadavg() 関数は genloadavg() 関数の結果と hp_avenrun[] の現在値を元に hp_avenrun[] 変数を更新しており、genloadavg() 関数は loadavg 変数を元に処理を行っています。loadavg 変数は直近の負荷情報を保持している変数です。loadavg 変数 -> genloadavg() 関数 -> calcloadavg() 関数 <-> hp_avenrun[] 変数 -> avenrun[] 変数の順にデータが加工されています。 811 calcloadavg(genloadavg(&loadavg), hp_avenrun); 812 for (i = 0; i < 3; i++) 813 /\* 814 \* At the moment avenrun[] can only hold 31 815 \* bits of load average as it is a signed 816 \* int in the API. We need to ensure that 817 \* hp_avenrun[i] >> (16 - FSHIFT) will not be 818 \* too large. If it is, we put the largest value 819 \* that we can use into avenrun[i]. This is 820 \* kludgey, but about all we can do until we 821 \* avenrun[] is declared as an array of uint64[] 822 \*/ 823 if (hp_avenrun[i] < ((uint64_t)1<<(31+16-FSHIFT))) 824 avenrun[i] = (int32_t)(hp_avenrun[i] >> 825 (16 - FSHIFT)); 826 else 827 avenrun[i] = 0x7fffffff;avenrun は <sys/systm.h> を通してインクルードされます。 105 extern intavenrun[];/\* array of load averages \*/ clock.cclock.c はクロックルーチンです。一定の時間毎に呼び出されます。clock.c にある genloadavg(), loadavg_update(), calcloadavg() の 3 つの関数で loadavg が計算されています。 loadavg 変数loadavg は <sys/cpuvar.h> に定義されている loadavg_s 構造体型の変数です。loadavg_s 構造体の lg_loads[] はリングバッファになっています。S_LOADAVG_SZ がリングバッファのサイズを表しており、その数は 11 です。lg_cur はリングバッファの中の現在位置を指す変数です。要素の数が 11 個ですので、lg_cur の取りうる値は 0 - 10 の間になります。lg_len はリングバッファの内、データが入力されている要素数を表しています。lg_loads[] は loadavg_update() 関数により、毎秒一要素ずつ書き換えられます。lg_cur も loadavg_update() 関数の中で更新されています。 56 #defineS_LOADAVG_SZ11 57 #defineS_MOVAVG_SZ10 58 59 struct loadavg_s { 60 int lg_cur;/\* current loadavg entry \*/ 61 unsigned int lg_len;/\* number entries recorded \*/ 62 hrtime_t lg_total;/\* used to temporarily hold load totals \*/ 63 hrtime_t lg_loads[S_LOADAVG_SZ];/\* table of recorded entries \*/ 64 }; loadavg_update() 関数loadavg_update() 関数は clock() ルーチンから毎秒一回呼び出されて loadavg 変数を更新する関数です。loadavg_update() 関数は cpu_acct[CMS_USER], cpu_acct[CMS_SYSTEM], cpu_waitrq の値を使用してロードアベレージを計算します。cpu_acct[CMS_USER] はユーザ空間で消費された CPU 時間、cpu_acct[CMS_SYSTEM] はカーネル空間で消費された CPU 時間で、この 2 つを合わせると実行時間になります。cpu_waitrq は CPU 毎の実行キュー (run queue => rq) の待ち (wait) 時間です。従来の実行スレッド数 + 実行待ちスレッド数という計算式を使用する代わりに、実行時間 + 実行待ち時間を使用しているということになります。ロードアベレージを計算する為のデータソースはこの 3 つの数値が全てです。DTrace 等で cpu_acct[CMS_USER], cpu_acct[CMS_SYSTEM], cpu_waitrq の値を取得すれば、自分でロードアベレージを計算する事も可能です。 947 static void 948 loadavg_update() 949 { 950 cpu_t \*cp; 951 cpupart_t \*cpupart; 952 hrtime_t cpu_total; 953 int prev; 954 955 cp = cpu_list; 956 loadavg.lg_total = 0; 957 958 /\* 959 \* first pass totals up per-cpu statistics for system and cpu 960 \* partitions 961 \*/ 962 963 do { 964 struct loadavg_s \*lavg; 965 966 lavg = &cp->cpu_loadavg; 967 968 cpu_total = cp->cpu_acct[CMS_USER] + /\* ここがポイント \*/ 969 cp->cpu_acct[CMS_SYSTEM] + cp->cpu_waitrq; /\* ここがポイント \*/ 970 /\* compute delta against last total \*/ 971 scalehrtime(&cpu_total); 972 prev = (lavg->lg_cur - 1) >= 0 ? lavg->lg_cur - 1 : 973 S_LOADAVG_SZ + (lavg->lg_cur - 1); 974 if (lavg->lg_loads[prev] <= 0) { 975 lavg->lg_loads[lavg->lg_cur] = cpu_total; 976 cpu_total = 0; 977 } else { 978 lavg->lg_loads[lavg->lg_cur] = cpu_total; 979 cpu_total = cpu_total - lavg->lg_loads[prev]; 980 if (cpu_total < 0) 981 cpu_total = 0; 982 } 983 984 lavg->lg_cur = (lavg->lg_cur + 1) % S_LOADAVG_SZ; 985 lavg->lg_len = (lavg->lg_len + 1) < S_LOADAVG_SZ ? 986 lavg->lg_len + 1 : S_LOADAVG_SZ; 987 988 loadavg.lg_total += cpu_total; 989 cp->cpu_part->cp_loadavg.lg_total += cpu_total; 990 991 } while ((cp = cp->cpu_next) != cpu_list); 992 993 loadavg.lg_loads[loadavg.lg_cur] = loadavg.lg_total; 994 loadavg.lg_cur = (loadavg.lg_cur + 1) % S_LOADAVG_SZ; 995 loadavg.lg_len = (loadavg.lg_len + 1) < S_LOADAVG_SZ ? 996 loadavg.lg_len + 1 : S_LOADAVG_SZ; 997 /\* 998 \* Second pass updates counts 999 \*/ 1000 cpupart = cp_list_head; 1001 1002 do { 1003 struct loadavg_s \*lavg; 1004 1005 lavg = &cpupart->cp_loadavg; 1006 lavg->lg_loads[lavg->lg_cur] = lavg->lg_total; 1007 lavg->lg_total = 0; 1008 lavg->lg_cur = (lavg->lg_cur + 1) % S_LOADAVG_SZ; 1009 lavg->lg_len = (lavg->lg_len + 1) < S_LOADAVG_SZ ? 1010 lavg->lg_len + 1 : S_LOADAVG_SZ; 1011 1012 } while ((cpupart = cpupart->cp_next) != cp_list_head); 1013 1014 }cpu_acct[] と cpu_waitrq は共に hrtime_t 型の変数で、経過時間を保持しています。どちらも cpuvar.h に定義されています。 193 volatile hrtime_t cpu_mstate_start;/\* cpu microstate start time \*/ 194 volatile hrtime_t cpu_acct[NCMSTATES];/\* cpu microstate data \*/ 195 hrtime_tcpu_intracct[NCMSTATES]; /\* interrupt mstate data \*/ 196 hrtime_tcpu_waitrq;/\* cpu run-queue wait time \*/ 197 struct loadavg_s cpu_loadavg;/\* loadavg info for this cpu \*/ genloadavg() 関数loadavg_update() 関数によって更新された loadavg 変数を使用しているのは、以下の genloadavg() 関数です。genloadavg() 関数は、loadavg 変数から過去 10 秒間の lg_loads[] の値の平均を取り、ナノ秒単位を秒単位に直した値を返します。ここで見て頂きたいのは genloadavg() 関数はロードアベレージに対して新たなデータを加えていないという事です。genloadavg() 関数は loadavg_update() 関数が用意したデータのみを使用しています。 905 /\* 906 \* Called before calcloadavg to get 10-sec moving loadavg together 907 \*/ 908 909 static int 910 genloadavg(struct loadavg_s \*avgs) 911 { 912 int avg; 913 int spos; /\* starting position \*/ 914 int cpos; /\* moving current position \*/ 915 int i; 916 int slen; 917 hrtime_t hr_avg; 918 919 /\* 10-second snapshot, calculate first positon \*/ 920 if (avgs->lg_len == 0) { 921 return (0); 922 } 923 slen = avgs->lg_len < S_MOVAVG_SZ ? avgs->lg_len : S_MOVAVG_SZ; /\* リングバッッファの長さが 10 以上なら 10 個のサンプルを採る \*/ 924 925 spos = (avgs->lg_cur - 1) >= 0 ? avgs->lg_cur - 1 : 926 S_LOADAVG_SZ + (avgs->lg_cur - 1); /\* 一つ前のリングバッファの位置 \*/ 927 for (i = hr_avg = 0; i < slen; i++) { 928 cpos = (spos - i) >= 0 ? spos - i : S_LOADAVG_SZ + (spos - i); 929 hr_avg += avgs->lg_loads[cpos]; /\* slen の数だけ以前の要素を足し合わせる \*/ 930 } 931 932 hr_avg = hr_avg / slen; /\* 足し合わせた値を要素数で割る \*/ 933 avg = hr_avg / (NANOSEC / LGRP_LOADAVG_IN_THREAD_MAX); /\* 秒単位に直して、128 を掛ける \*/ 934 935 return (avg); 936 }なお、NANOSEC は 1000000000 で LGRP_LOADAVG_IN_THREAD_MAX は 128 です。 237 #defineNANOSEC1000000000 81 #defineLGRP_LOADAVG_IN_THREAD_MAX128 calcloadavg() 関数genloadavg() が計算したロードアベレージを元に hp_avenrun[] の値を更新する関数が以下の calcloadavg() です。calcloadavg() はロードアベレージに対し指数減衰処理を施しています。引数の nrun はその名の通り、元々は run しているスレッド数と run 可能なスレッド数から計算されていましたが、現在は先ほどの genloadavg() 関数の返り値が渡されています。通常、hp_ave には hp_avenrun[] が渡されます。hp_avenrun[] の値は calcloadavg() 内でのみ更新されており、外部のデータには依存していません。calcloadavg() 関数も(genloadavg() 関数経由で)loadavg_update() 関数が用意したデータのみを使用しています。 2090 static void 2091 calcloadavg(int nrun, uint64_t \*hp_ave) 2092 { 2093 static int64_t f[3] = { 135, 27, 9 }; 2094 uint_t i; 2095 int64_t q, r; 2096 2097 /\* 2098 \* Compute load average over the last 1, 5, and 15 minutes 2099 \* (60, 300, and 900 seconds). The constants in f[3] are for 2100 \* exponential decay: 2101 \* (1 - exp(-1/60)) << 13 = 135, 2102 \* (1 - exp(-1/300)) << 13 = 27, 2103 \* (1 - exp(-1/900)) << 13 = 9. 2104 \*/ 2105 2106 /\* 2107 \* a little hoop-jumping to avoid integer overflow 2108 \*/ 2109 for (i = 0; i < 3; i++) { 2110 q = (hp_ave[i] >> 16) << 7; 2111 r = (hp_ave[i] & 0xffff) << 7; 2112 hp_ave[i] += ((nrun - q) \* f[i] - ((r \* f[i]) >> 16)) >> 4; 2113 } 2114 } まとめユーザランドからロードアベレージを取得する方法として getloadavg() 関数が用意されていました。getloadavg() 関数はシステムコールを経由してカーネル内の avenrun[] 変数をコピーしていました。avenrun[] は loadavg 変数から直近のロードの平均を取り、指数減衰を加味した数値でした。loadavg 変数は loadavg_update() 関数が CPU の統計情報を利用して更新していました。loadavg の計算の途中には現在の実行スレッド数や実行待ちスレッド数についての情報は登場しません。代わりに CPU の処理時間と処理待ち時間を使用していました。 さいごに以上、システム全体のロードアベレージが CPU の統計情報を元に計算されている事をご覧頂きました。Solaris 10 以降はロードアベレージの計算に実行スレッドの個数は使用されていません。何故このような実装に変わったかというと、システム負荷を計算する場合にスレッド数を数えるよりも CPU の情報を元にした方がサンプリング誤差に強く、正確な情報が得られるからです。他の OS でも Solaris の様に CPU のマイクロアカウント情報が整備されており、常に利用可能な状態になっているのであれば、ロードアベレージの計算にスレッド数を使用する必要はないと思います。なお、この変更によりロードアベレージの取る値が変わったという訳ではありません。値の読み方は基本的には以前と変わりません。また、単に実行待ちのスレッド数を見たい場合は vmstat の r を使用する事が可能です。 補足情報 検証用プログラム ロードアベレージに関連する変数を全てダンプする DTrace スクリプト以下のスクリプトを loadavg.d という名前で保存してください。DTrace はとても便利ですね。 #!/usr/sbin/dtrace -qs fbt:genunix:loadavg_update:return { printf("time : %d\\n", timestamp / 1000000000); printf("\\n"); printf(" avenrun[0] : %d\\n", `avenrun[0]); printf(" avenrun[1] : %d\\n", `avenrun[1]); printf(" avenrun[2] : %d\\n", `avenrun[2]); printf("\\n"); printf(" hp_avenrun[0] : %d\\n", `hp_avenrun[0]); printf(" hp_avenrun[1] : %d\\n", `hp_avenrun[1]); printf(" hp_avenrun[2] : %d\\n", `hp_avenrun[2]); printf("\\n"); printf(" lg_cur : %d\\n", `loadavg.lg_cur); printf(" lg_len : %d\\n", `loadavg.lg_len); printf(" lg_total : %d\\n", `loadavg.lg_total); printf(" lg_loads[0] : %d\\n", `loadavg.lg_loads[0]); printf(" lg_loads[1] : %d\\n", `loadavg.lg_loads[1]); printf(" lg_loads[2] : %d\\n", `loadavg.lg_loads[2]); printf(" lg_loads[3] : %d\\n", `loadavg.lg_loads[3]); printf(" lg_loads[4] : %d\\n", `loadavg.lg_loads[4]); printf(" lg_loads[5] : %d\\n", `loadavg.lg_loads[5]); printf(" lg_loads[6] : %d\\n", `loadavg.lg_loads[6]); printf(" lg_loads[7] : %d\\n", `loadavg.lg_loads[7]); printf(" lg_loads[8] : %d\\n", `loadavg.lg_loads[8]); printf(" lg_loads[9] : %d\\n", `loadavg.lg_loads[9]); printf(" lg_loads[10] : %d\\n", `loadavg.lg_loads[10]); printf("\\n"); printf("\\n"); }使い方 # ./loadavg.d time : 1208341 avenrun[0] : 4 avenrun[1] : 4 avenrun[2] : 2 hp_avenrun[0] : 1172 hp_avenrun[1] : 1113 hp_avenrun[2] : 691 lg_cur : 7 lg_len : 11 lg_total : 334519769 lg_loads[0] : 46801985 lg_loads[1] : 60175047 lg_loads[2] : 60416778 lg_loads[3] : 60746759 lg_loads[4] : 64462319 lg_loads[5] : 34230600 lg_loads[6] : 334519769 lg_loads[7] : 2024692 lg_loads[8] : 1697770 lg_loads[9] : 6010137 lg_loads[10] : 1915265 ... cpu_acct[] と cpu_waitrq をダンプするシェルスクリプト以下のシェルスクリプトを cpu_acct.sh という名前で保存してください。これも DTrace を利用しています。 #!/bin/sh dscript=`psrinfo | awk '{print $1}' | while read i do /usr/ucb/echo ' tick-1sec { ncpu='$i'; printf("%d\\t\\t%u\\t%u\\t%u\\t%u\\n", ncpu, \\`cpu[ncpu]->cpu_acct[0], \\`cpu[ncpu]->cpu_acct[1], \\`cpu[ncpu]->cpu_acct[2], \\`cpu[ncpu]->cpu_waitrq) }' done` header='tick-1sec{printf("\\nCPU\\t\\tUSER\\t\\tSYSTEM\\t\\tIDLE\\t\\t\\tWaitRunQueue\\n")}' dtrace -qn "${header} ${dscript}"使い方 # ./cpu_acct.sh CPU USER SYSTEM IDLE WaitRunQueue 0 393058730424 3505065319348 6225195707147196 1928374528 1 675458639209 37806347146860 6190196714476028 23251910602 2 295121491846 636804044408 6227742143570932 214512326509 3 134573272271 163389092029 6228370750871859 52309235982 4 114391873741 4868500694500 6223678918587263 4457218207 5 71058590513 31310646602 6228554702708875 4141334771 6 464954088771 142789925351 6227999559480501 8135320823 7 398981333884 97614493289 6228154535173466 8623139580 \^C ロードアベレージのシミュレータ以下のコードの decay と n に適当な数値を設定するとロードアベレージの推移をシミュレートする事が出来ます。decay は減衰処理用の定数です。取りうる値は 135, 27, 9 の何れかで、135 は 1 分間のロードアベレージ用、27 は 5 分間、9 は 15 分間のロードアベレージ用の定数です。n には実行中および実行待ちのスレッド数を指定します。そのままコンパイルするだけでも使用可能ですが、一々コンパイルし直すのが面倒な場合は decay や n の指定をコマンドの引数にする等、適宜書き換えて使用してください。 #include <unistd.h> int main() { int decay = 135; // decay : exponential decay, {135=1min, 27=5min, 9=15min} int n = 2; // n : number of running + runnable threads int i, q, r; uint64_t lavg = 0; n \*= (1 << 7); // LGRP_LOADAVG_IN_THREAD_MAX for(i = 0; i < 1500; i++) { // i : duration, {60=1min, 300=5min, 900=15min} q = (lavg >> 16) << 7; r = (lavg & 0xffff) << 7; lavg += ((n - q) \* decay - ((r \* decay) >> 16)) >> 4; printf("%d:\\t%f\\n", i, (double)lavg / (1 << 16)); } } ロードアベレージに関連するデータロードアベレージその物ではありませんが、Solaris にはロードアベレージに関連するデータが幾つか用意されています。 kstat の avenrunavenrun_\* はロードアベレージの元になっているカーネル内のデータです。この値を 256 で割った結果がロードアベレージになります。pset はプロセッサセット毎のロードアベレージ、system_misc はシステム全体のロードアベレージです。 % kstat -p | grep avenrun unix:0:pset:avenrun_15min 3 unix:0:pset:avenrun_1min 5 unix:0:pset:avenrun_5min 5 unix:0:system_misc:avenrun_15min 3 unix:0:system_misc:avenrun_1min 5 unix:0:system_misc:avenrun_5min 5256 で割るのは getloadavg() の中の FSCALE を反映するためです。小数部 8bit の固定小数点数を浮動小数点数に直しています。 vmstat の run queuevmstat コマンドの出力の kthr の r は run queue に実行待ちのカーネルスレッドが幾つ入っているかを示してします。ロードアベレージとは異なりますが、スレッドのスケジューリングに着目して負荷を判断する場合は、こちらの方がより直接的な指標となります。 % vmstat 1 kthr memory page disk faults cpu r b w swap free re mf pi po fr de sr 1m 1m 1m lf in sy cs us sy id 0 0 0 7687208 6172792 9 10 349 7 7 0 0 7 7 14 2 377 517 366 2 2 97 0 0 0 7314560 5881512 0 18 170 0 0 0 0 0 0 0 0 289 363 249 0 0 100 0 0 0 7314560 5881576 2 2 0 0 0 0 0 0 0 0 0 233 119 152 0 1 99 0 0 0 7314560 5881576 2 2 0 0 0 0 0 0 0 0 0 246 169 176 0 0 100 getloadavg(3C) のマニュアルSolaris 10 の getloadavg(3C) のマニュアルには以下の様に書いてあります。ロードアベレージが取る値が変わった訳ではなく、計算方法が変わっただけなので、このままでも間違いではありませんが、実行時間と実行待ち時間から実行スレッド数と実行待ちスレッド数に換算された数値であると考えると良いかもしれません。 DESCRIPTION The getloadavg() function returns the number of processes in the system run queue averaged over various periods of time. 参考資料http://docs.sun.com/app/docs/doc/817-0547/eyhuuhttp://perfcap.blogspot.com/2007/04/load-average-differences-between.htmlhttp://www.princeton.edu/~unix/Solaris/troubleshoot/cpuload.htmlhttp://www.runningunix.com/2009/01/what-is-load-average-in-solaris/http://members3.jcom.home.ne.jp/katsumi.nuruki/http://www.teamquest.com/resources/gunther/display/5/

はじめに 今回は UNIX で伝統的にシステム負荷の指標とされて来たロードアベレージの実装についてご紹介したいと思います。これまでロードアベレージは実行中および実行待ちのスレッドの数を集計した数値と言われており、過去の Solaris でもその様に実装されていました。しかし Solaris 10 以降はロードアベレージの内部実装が変更され、スレッド数をカウントする方式から...

Sun

DTrace の IP プロバイダの使い方

はじめにOpenSolaris の DTrace には IP プロバイダが用意されています。IP プロバイダを使用するとパケットの送受信をトレースしてアクションを実行するスクリプトを書く事が出来ます。また、snoop や tcpdump, libpcap を使わずとも IP レイヤーの分析が簡単に出来る様になります。今回はこの IP プロバイダの使い方をご紹介します。 用意されているプローブの種類IP プロバイダに用意されているプローブの一覧は下記の通りです。プローブは大きく分けて receive と send の 2 種類があります(NAME のカラムを参照)。receive はパケットの受信時に発動するプローブで、send は送信時に発動するプローブです。これらのプローブをトリガーとした DTrace のスクリプトを書く事で、IP レイヤーの調査を行う事が可能になっています。なお FUNCTION のカラムは該当するプローブが定義されている関数の名前です。どの関数もパケットの送受信に関わっている関数です。IP プロバイダはカーネル内のプロバイダなので、ここに挙っている関数もカーネル内の関数です。大まかに言って、関数名が ip で始まるプローブは IP モジュールの、tcp は TCP モジュールの、udp は UDP モジュールのプローブです。v6 が付いている場合は IPv6 で v4 が付いている場合は IPv4 用の関数です。関数の種類や数はリリースに依って変動します。以下は snv_127 で用意されているプローブです。 # dtrace -ln ip::: ID PROVIDER MODULE FUNCTION NAME 16993 ip ip ip_wput_local_v6 receive 16994 ip ip ip_rput_v6 receive 16995 ip ip ip_wput_local receive 16996 ip ip ip_input receive 17013 ip ip ip_inject_impl send 17014 ip ip udp_xmit send 17015 ip ip tcp_lsosend_data send 17016 ip ip tcp_multisend send 17017 ip ip tcp_send_data send 17018 ip ip ip_multicast_loopback send 17019 ip ip ip_xmit_v6 send 17020 ip ip ip_wput_ire_v6 send 17021 ip ip ip_xmit_v4 send 17022 ip ip ip_wput_ipsec_out send 17023 ip ip ip_wput_ipsec_out_v6 send 17024 ip ip ip_wput_frag send 17025 ip ip ip_wput_frag_mdt send 17026 ip ip ip_wput_ire send 17027 ip ip ip_fast_forward send 用意されているデータの種類各プローブには args[0] から args[5] までの変数が用意されており、それぞれが様々な情報への参照を保持しています。args[0] はパケット情報、args[1] はコネクションステータス情報、args[2] は IP の情報、args[3] はネットワークインターフェイスの情報、args[4] は IPv4 のヘッダ情報、args[5] は IPv6 のヘッダ情報を参照しています。DTrace スクリプトの中からこれらの変数にアクセスして必要な情報を入手してください。 変数参照先の型参照している情報 args[0]pktinfo_t \*パケット情報 args[1]csinfo_t \*コネクションステータス情報 args[2]ipinfo_t \*IP の情報 args[3]ifinfo_t \*ネットワークインターフェイスの情報 args[4]ipv4info_t \*IPv4 のヘッダ args[5]ipv6info_t \*IPv6 のヘッダ各データ構造の詳細は こちら をご覧下さい IP プロバイダの使用例 パケットの送受信イベントの表示DTrace のスクリプト部分に 'ip:::send' だけを指定すると、パケットを送信する度に IP プロバイダの該当するプローブが発動した事が表示されます。'ip:::receive' を指定するとパケットを受信する度に表示されます。'ip:::' または明示的に 'ip:::send,ip:::receive' を指定すると送受信両方で該当するプローブが発動し、表示されます。CPU のカラムは送受信イベントが発生した CPU の番号を表示しています。この情報を使用して、どの CPU でパケットの送受信がハンドルされているかを判別する事が出来ます。 # dtrace -n 'ip:::send' dtrace: description 'ip:::send' matched 15 probes CPU ID FUNCTION:NAME 0 17018 ip_multicast_loopback:send 0 17021 ip_xmit_v4:send 0 17017 tcp_send_data:send 0 17017 tcp_send_data:send 0 17017 tcp_send_data:send \^C パケットサイズを表示するパケットサイズは args[2]->ip_plength で参照出来ます。probename が "send" だった場合は受信パケットなので "S" と表示させています。なお、dtrace コマンドに -q オプションを付けると、どのプローブが発動したかは表示されなくなります。 # dtrace -qn 'ip:ip::send,ip:ip::receive { printf("%s\\t\\t%s\\t%d bytes\\n", probefunc, (probename == "send") ? "S" : "R", args[2]->ip_plength)}' tcp_send_data S 20 bytes ip_input R 68 bytes tcp_send_data S 100 bytes tcp_send_data S 100 bytes ip_input R 20 bytes tcp_send_data S 196 bytes ip_input R 20 bytes \^C パケットの送信元アドレスと宛先アドレスを表示するパケットの送信元アドレスは args[2]->ip_saddr に、宛先アドレスは args[2]->ip_daddr に格納されています # dtrace -qn 'ip:ip::send,ip:ip::receive {printf("%s\\t\\t->\\t\\t%s\\t\\t%d bytes\\n", args[2]->ip_saddr, args[2]->ip_daddr, args[2]->ip_plength)}' 10.16.62.6 -> 10.16.100.16 20 bytes 10.16.100.16 -> 10.16.62.6 68 bytes 10.16.62.6 -> 10.16.100.16 132 bytes 10.16.62.6 -> 10.16.100.16 132 bytes 10.16.100.16 -> 10.16.62.6 20 bytes 10.16.62.6 -> 10.16.100.16 292 bytes 10.16.100.16 -> 10.16.62.6 20 bytes \^C パケットの送受信に使用された NIC を表示するNIC の名前は args[3]->if_name に格納されています。送受信パケット毎にインターフェイス名が表示されるので、複数の NIC を使用している場合はそれぞれのインターフェイス名が表示されます。 # dtrace -qn 'ip:ip::send, ip:ip::receive {printf("NIC: %s\\n", args[3]->if_name)}' NIC: bge0 NIC: bge0 NIC: bge0 NIC: bge0 NIC: bge0 NIC: bge0 パケットの種類を表示するargs[4]->ipv4_protostr に通信プロトコル情報が格納されています。識別可能なプロトコルは ip.d.in に定義されています。具体的には TCP, UDP, IP, ICMP, IGMP, EGP, IPv6, ROUTE, ESP, AH, ICMPv6, OSPF, SCTP, RAW 等です。 # dtrace -qn 'ip:ip::send, ip:ip::receive {printf("proto: %s\\n", args[4]->ipv4_protostr)}' proto: TCP proto: ICMP proto: ICMP proto: TCP proto: TCP ここまでに出て来た全ての情報を出力する以下のコマンドはちょっと長いですが、それでもたったこれだけでちょっとしたトレースツールが作成出来てしまいました。長くなった理由の一つには、出力が見易くなる様に、スクリプト開始時に呼び出される BEGIN プローブを使用してヘッダを付けたという事もあります。 # dtrace -qn 'BEGIN{printf("NIC\\tdir\\tproto\\tfunc\\t\\tsource\\t\\tdestination\\tbytes\\n")} ip:ip::send,ip:ip::receive {printf("%s\\t%s\\t%s\\t%s\\t%s\\t%s\\t%d\\n", args[3]->if_name, (probename == "send") ? "S" : "R", args[4]->ipv4_protostr, probefunc, args[2]->ip_saddr, args[2]->ip_daddr, args[2]->ip_plength)}' NIC dir proto func source destination bytes bge0 S TCP tcp_send_data 10.16.62.6 10.16.100.16 148 bge0 R TCP ip_input 10.16.100.16 10.16.62.6 20 bge0 S TCP tcp_send_data 10.16.62.6 10.16.100.16 132 bge0 S TCP tcp_send_data 10.16.62.6 10.16.100.16 132 bge0 R TCP ip_input 10.16.100.16 10.16.62.6 20 \^C パケットサイズ毎の分布を調べるDTrace の集計機能を使って、受信パケットを送信元アドレスとパケットサイズで分類してみます。どのノードからどんなサイズでパケットが送られて来ているかも簡単に調査する事が出来ます。出力の中の IP Address が送信元アドレスで、value のカラムの数字がパケットサイズ、count のカラムがパケット数です。'@' の数がパケットサイズ毎の分布を表しています。 # dtrace -qn 'ip:::receive {@size[args[2]->ip_saddr] = quantize(args[2]->ip_plength)}' \^C 10.16.100.254 value ------------- Distribution ------------- count 4 | 0 8 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 16 | 0 10.16.62.6 value ------------- Distribution ------------- count 4 | 0 8 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 16 | 0 127.0.0.1 value ------------- Distribution ------------- count 8 | 0 16 |@@@@@@@@@@@@@@@@@@@@ 6 32 |@@@@@@@@@@@@@@@@@@@@ 6 64 | 0 10.16.62.7 value ------------- Distribution ------------- count 32 | 0 64 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7 128 | 0 10.16.62.5 value ------------- Distribution ------------- count 8 | 0 16 |@@@@@@@@@@@@ 11 32 |@@@@@@ 6 64 |@@@@@@@@@@@@@@@@@@@ 18 128 | 0 256 |@@@ 3 512 | 0 パケットを送受信した時間を表示する下記スクリプトでは DTrace に用意されている walltimestamp 変数を使用して、パケットを送受信した時間を表示させています。%Y の代わりに %d 等で出力すれば秒単位以下の細かい時間を表示させる事も可能です。walltimestamp 以外にも DTrace に用意されている豊富な変数を利用して様々なスクリプトを作成する事が出来ます。 # dtrace -qn 'ip:::send,ip:::receive { printf("%s\\t->\\t%s\\t%Y\\n", args[2]->ip_saddr, args[2]->ip_daddr, walltimestamp) }' 10.16.62.6 -> 10.16.62.7 2009 Dec 15 16:29:25 10.16.62.7 -> 10.16.62.6 2009 Dec 15 16:29:25 10.16.62.6 -> 10.16.62.7 2009 Dec 15 16:29:25 10.16.62.6 -> 10.16.62.7 2009 Dec 15 16:29:25 10.16.62.7 -> 10.16.62.6 2009 Dec 15 16:29:25 10.16.62.6 -> 10.16.62.7 2009 Dec 15 16:29:26 10.16.62.6 -> 10.16.62.7 2009 Dec 15 16:29:26 10.16.62.7 -> 10.16.62.6 2009 Dec 15 16:29:26 \^C 1 秒間にどのくらいのパケットを送受信しているかを測定するDTrace の Profile プロバイダと組み合わせると、毎秒何パケット送受信したかを調査する事が出来ます。tick-1sec プローブは Profile プロバイダのプローブで、1 秒毎に発動します。Profile プロバイダ以外にも DTrace の豊富なプローブと組み合わせて様々なスクリプトを作成する事が可能です。 # dtrace -qn 'ip:::send { send++ } ip:::receive { recv++ } tick-1sec { printf("There is/are %d packet(s) sent and %d packet(s) received.\\n", send, recv); send = 0; recv = 0 }' There is/are 1 packet(s) sent and 0 packet(s) received. There is/are 5 packet(s) sent and 5 packet(s) received. There is/are 4 packet(s) sent and 4 packet(s) received. There is/are 4 packet(s) sent and 4 packet(s) received. There is/are 3 packet(s) sent and 3 packet(s) received. There is/are 1 packet(s) sent and 1 packet(s) received. \^C NIC の詳細デバッグ情報を調査するargs[3]->if_addr は NIC に対応するカーネル内データ構造へのポインタになっています。ill_t 構造体の定義は ip.h にあります。ここでは NIC の名前を表示していますが、ill_t 構造体には他にも色々な情報が格納されています。 # dtrace -qn 'ip:ip::send, ip:ip::receive {printf("NIC: %s\\n", stringof(((ill_t \*)(args[3]->if_addr))->ill_name))}' NIC: bge0 NIC: bge0 NIC: bge0 NIC: bge0 NIC: bge0 \^C 既存のサンプルDTrace の デモスクリプト に ipio.d と ipproto.d が用意されています。ipio.d はパケットの送受信に使用した CPU, 直前にパケットを送受信した時間からの経過時間、送信元アドレス、宛先アドレス、使用したインターフェイス、送受信バイト数を表示するスクリプトです。 # dtrace -s /usr/demo/dtrace/ipio.d CPU DELTA(us) SOURCE DEST INT BYTES 1 613 10.16.62.6 -> 10.16.62.7 bge0 132 1 150 10.16.62.6 -> 10.16.62.7 bge0 132 3 270 10.16.62.6 <- 10.16.62.7 bge0 20 1 99507 10.16.62.6 -> 10.16.62.7 bge0 132 1 109 10.16.62.6 -> 10.16.62.7 bge0 132 3 197 10.16.62.6 <- 10.16.62.7 bge0 20 1 99450 10.16.62.6 -> 10.16.62.7 bge0 132 \^Cipproto.d は送信元アドレス、宛先アドレス、プロトコル毎に何パケット送受信されたかを表示するスクリプトです。 # dtrace -s /usr/demo/dtrace/ipproto.d Tracing... Hit Ctrl-C to end. \^C SADDR DADDR PROTO COUNT 10.16.62.6 10.16.62.7 TCP 2 10.16.62.7 10.16.62.6 TCP 2 IP プロバイダの実装IP プロバイダの実装は通常の SDT (静的定義トレース) プロバイダの実装と殆ど変わりありません。SDT プロバイダ用の DTRACE_PROBEn マクロをラップする形で、IP プロバイダ用に DTRACE_IP ~ DTRACE_IP7 までのマクロが用意されています。これらのマクロの第 1 引数がプローブ名 (send/receive) になっています。http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/sdt.h#251現時点では、この内の DTRACE_IP7 だけが使用されています。以下のリンクから DTRACE_IP7 が使用されている場所を探す事が出来ます。http://src.opensolaris.org/source/search?q=DTRACE_IP7&project=%2Fonnv以下は DTrace IP プロバイダが OpenSolaris にマージされた際の ip.c の diff です。DTRACE_IP7 が加えられている事が分かります。http://hg.genunix.org/onnv-gate.hg/diff/360e73ea6b0c/usr/src/uts/common/inet/ip/ip.cIP プロバイダで使用するデータ型やトランスレータは ip.d.in に定義されています。 その他の IP 関連のプローブDTrace には他にも IP に関連するプローブが沢山用意されています。これらも是非お試し下さい。 # dtrace -ln :ip:: | head ID PROVIDER MODULE FUNCTION NAME 16469 sdt ip tsol_ip_forward tx-ip-log-drop-forward-nodst 16470 sdt ip tsol_ip_forward tx-ip-log-drop-forward-nogw 16471 sdt ip tsol_ip_forward tx-ip-log-info-forward-adjust 16472 sdt ip tsol_ip_forward tx-ip-log-drop-forward-mac 16473 sdt ip tsol_ire_match_gwattr tx-ip-log-drop-irematch-nogwsec 16474 sdt ip tsol_ire_match_gwattr tx-ip-log-drop-irematch-nogwtmpl 16475 sdt ip tsol_ire_match_gwattr tx-ip-log-drop-irematch-deftmpl 16476 sdt ip tsol_ire_match_gwattr tx-ip-log-drop-irematch-nogcmatched 16477 sdt ip tsol_receive_local tx-ip-log-drop-receivelocal-no-tnr 参考資料 リファレンスhttp://wikis.sun.com/display/DTrace/ip+Providerhttp://arc.opensolaris.org/caselog/PSARC/2008/302/mailhttp://hub.opensolaris.org/bin/view/Community+Group+dtrace/NetworkProvider IP プロバイダに関する議論のログhttp://opensolaris.org/jive/thread.jspa?threadID=47705http://opensolaris.org/jive/thread.jspa?threadID=63731http://mail.opensolaris.org/pipermail/networking-discuss/2008-May/007546.html TCP プロバイダも予定されていますhttp://wikis.sun.com/display/DTrace/tcp+Provider その他http://blogs.sun.com/hotnets/entry/examining_large_segment_offload_lso おわりに以上、DTrace の IP プロバイダの使用方法をご紹介しました。IP プロバイダは小粒な機能ですが、使い方に依っては色々な可能性を秘めたプロバイダだと思います。ご覧頂いた様な簡単なワンライナーで自分の欲しい情報だけを引き出せるのが DTrace の魅力の一つです。是非ご活用下さい。また、この様な小さなエンハンスも含め、大小様々なアップデートが入っているのが OpenSolaris の魅力です。是非、お手元にインストールして最新環境をお試し下さい。

はじめに OpenSolaris の DTrace には IP プロバイダが用意されています。IP プロバイダを使用するとパケットの送受信をトレースしてアクションを実行するスクリプトを書く事が出来ます。また、snoop や tcpdump, libpcap を使わずとも IP レイヤーの分析が簡単に出来る様になります。今回はこの IP プロバイダの使い方をご紹介します。 用意されているプローブの種類...

Sun

知って得するURL

今回は、Sun に関連する知って得する URL の情報を纏めてみました。いろいろな URL がありますので、何か一つはよいサイトが見つかると思います。気に入ったサイトには是非ブックマークをお願いします。カテゴリ一覧Sun 製品全般Server 関連Storage SS7000 シリーズ関連Thin Client 関連Solaris 関連Software 関連Sun 製品全般  Sun Products Digest  少し古い情報になりますが、写真付きでサンの製品情報、サポートマトリックスが確認できます。   http://jp.sun.com/spdigest/  Sun 製品カタログ  Sun 製品のスペックを知りたい時はここをチェック!「Sun x86 Handbook」はとっても便利です。   http://jp.sun.com/products/catalog/  消費電力計算ツール ( Power Calculator )  エコ時代ゆえに、いろいろと気になる消費電力。様々なサーバやストレージの消費電力の目安を計算出来ます。   http://www.sun.com/solutions/eco_innovation/powercalculators.jsp   オンライン・セミナー  ストリーミングを利用して、サンの各種製品やソリューションをご紹介するオンライン・セミナーを実施中です。   http://jp.sun.com/webcast/#090209  Channel Sun  サンが配信しているビデオサイトです。ハードウェアからオープンソースに関する物まで、いろいろなビデオが配信されています。   http://channelsun.sun.com/video   お客様導入事例  サンのシステムを採用したお客様の導入事例を業種別、製品・ソリューション別で紹介しています。   http://jp.sun.com/solutions/cstudy/archive.html  日本語版 BigAdmin  システム管理者向けの情報サイト BigAdmin の中から人気の高いコンテンツを日本語に訳した記事がまとまっています。   http://www.sun.com/bigadmin/hubs/multilingual/japanese/content.jsp  構成ダイアグラム集  少し古いものもありますが、Sun 製品構成ダイアグラムのテンプレート集です。ご活用下さい。   http://www.sun.com/bigadmin/content/config_diagrams/ Server 関連  徹底検証!Sun SPARC Enterprise M3000 + Oracle 検証資料ダウンロード  Sun SPARC Enterprise M3000 と Sun Storage 7410 の組み合わせによる実証テストとパフォーマンス・テストの結果報告書を配布!   http://jp.sun.com/promotions/m3000/  CMTサーバで実現するOracleバッチ処理の高速化  CMT サーバ T5220 と Oracle を組み合わせた様々な内容の検証結果をご覧頂けます。   http://jp.sun.com/company/partners/oracle/inspection/sun/cmt/vol3/ Storage SS7000 シリーズ   オープン・ストレージに関するホワイトペーパーを公開中  Sun のオープン・ストレージ戦略を詳細に記載したホワイトペーパーを無償公開中です。   http://jp.sun.com/solutions/infra/dm/openstorage/resource.html  Sun Storage 7000 関連 Blog など  SS7000 に関する Blog 情報のリンク集です。性能などテーマ毎に分かれているので参照しやすくなっています。   http://wikis.sun.com/x/ZMvEAw  Sun Storage 7000 シリーズマニュアル  SS7000 シリーズのマニュアルを参照できます。   http://docs.sun.com/app/docs/prod/uni.stor Thin Client 関連  Think Thin  サンの Thin Client and Server Based Computing グループのブログです。英語ですが SunRay に関る面白い記事が満載です。   http://blogs.sun.com/ThinkThin/  Sun Ray Software Information Center  Sun Ray Software 5 の公式ドキュメントなどの情報が集まっています。   http://wikis.sun.com/display/SRS/Home  パンデミック対策特集  決してありえない話ではないパンデミック対策を契機に実現する、投資対効果の高いオフィス環境の構築を紹介しています。   http://jp.sun.com/communities/0902/feature01.htmlSolaris 関連   Solaris 10 チューンアップ・リファレンスマニュアル最新版  Solaris 10 5/09 までの各アップデートリリースにおけるパラメータ変更履歴を簡単に確認することができます。   http://docs.sun.com/app/docs/doc/819-0376?l=ja  Solaris パフォーマンスウィキ  ZFS や Zone 等、Solaris に関連するパフォーマンスチューニングとベストプラクティスを集めたウィキです。今直ぐ活用出来る情報が満載です。   http://www.solarisinternals.com  opensolaris.org: ONNV Flag Days, Heads Ups, and Project Integration History  OpenSolaris の最新のアップデート内容が時系列でまとめられています。次世代の Solaris にどんな新機能が追加されているのか一目瞭然です。   http://hub.opensolaris.org/bin/view/Community+Group+on/flag%2Ddays ソフトウェア 関連   ソフトウェア・ホワイトペーパー公開中  SOA プラットフォームガイド、アイデンティティ管理等、今話題のソフトウェア製品に関するホワイトペーパーが入手できます。   http://jp.sun.com/documentation/whitepaper/software/  Provisioning MySQL Enterprise Server Using Sun xVM Ops Center v2.0  Sun xVM Ops Center 2.0 で MySQL Enterprise Server をプロビジョニングするケーススタディを紹介しております。   http://www.sun.com/bigadmin/features/articles/provision_mysql.jsp  GlassFish vs Tomcat 徹底比較検証  最近注目されているアプリケーションサーバ GlassFish のアドバンテージを Tomcat と比較して分かり易く解説しています。   http://jp.sun.com/newsletters/innercircle/0903/feature.html  アクエリアム The Aquarium (ja)  GlassFish コミュニティからオープンソース、Java EE, XML, SOA 等、様々なトピックのニュースを日本語でお届けしています。   http://blogs.sun.com/theaquarium_ja/  MySQL チューニングポイントのご紹介  MySQL を x86 Solaris 上で構築する際のパフォーマンスチューニングポイントが纏められていますので参考にどうぞ。   http://www.sun.com/blueprints/0208/820-4498.pdf  JVM のチューニングオプションの一覧  JVM のどのバージョンでどのオプションが使用できるかまとまっています。一覧表になっていて便利ですので、ご興味のある方はどうぞ。   http://blogs.sun.com/watt/resource/jvm-options-list.html (参考情報)過去の 「やっぱり Sun がスキ!」blog 記事一覧はこちらを参照下さい。http://wikis.sun.com/display/yappri/Home

今回は、Sun に関連する知って得する URL の情報を纏めてみました。 いろいろな URL がありますので、何か一つはよいサイトが見つかると思います。気に入ったサイトには是非ブックマークをお願いします。カテゴリ一覧 Sun 製品全般 Server 関連 Storage SS7000 シリーズ関連 Thin Client 関連 Solaris 関連 Software 関連 Sun 製品全般    Sun...

Sun

Solaris 10 の failsafe boot-archive 機能

Solaris 10 1/06 以降では、boot archive と呼ばれる OS 起動に必要なファイルを一纏めにした特別なファイルを利用して起動するようになりました。Solaris 10 x86 において新しいブートローダとして GRUB を採用する際に取り入れられた機能となり、boot archive 自体は、小さな / (root) ファイルシステムとして起動に必要となる最小限のファイルにて構成されています。また、Solaris 10 10/08 において ZFS Root Pool 機能の搭載により、SPARC マシンでも利用可能となり、このファイルがシステムの起動に深く関わるものとなります。(SPARC では GRUB は提供されていません)boot に関する情報は、下記のマニュアルに詳細が記載されています。Solaris 10 System Administrator Collection - Japanese Solaris のシステム管理 (基本編) 12. Solaris システムのブート (手順) http://docs.sun.com/app/docs/doc/819-0378/hbsparcboot-79782?l=ja&a=viewこのような起動の仕組みを実装したことにより、boot archive を複数持たせることができるようになったおかげで、通常の起動に利用する boot archive とは異なる、boot archive も提供されるようになりました。それが、failsafe archive です。failsafe archive は、インストールされている OS およびシステムに依存しない専用のアーカイブとなっており、これを利用することで起動のトラブルを切り分けるなど緊急時における最小限のシステムを起動することができるようになります。これで、CD/DVD などので光学ドライブを搭載していないシステムにおいても起動時のトラブルに対応できるようになりました。また、failsafe archive の起動時には、ハードディスクに存在する / パーティションを自動的に認識し mount することも可能です。failsafe archive の実態は、下記のファイルとなります。SPARC/platform/`uname -m`/failsafe x86/boot/x86.miniroot-safefailsafe archive の起動方法は、platform によって異なるため、下記のようになります。SPARCok boot -F failsafex86 GRUB メニューから failsafe を指定また、boot archive を pack/unpack することが可能な root_archive コマンドを使うことで、自分好みの boot archive を作成することも可能です。OS に添付されていない他社製品の HBA ドライバなどを利用している場合など、あらかじめ driver を組み込んだ boot archive を作成しておくとメンテナンスし易くなるかと思います。起動や boot archive についての詳細は、下記のマニュアルなどに記載されていますので、起動トラブルに備えて確認しておくと安心かと思います。Solaris 10 System Administrator Collection - Japanese Solaris のシステム管理 (基本編) 12. Solaris システムのブート (手順) SPARC システムでフェイルセーフアーカイブをブートするhttp://docs.sun.com/app/docs/doc/819-0378/ggqqq?l=ja&a=viewSolaris 10 System Administrator Collection - Japanese Solaris のシステム管理 (基本編) 12. Solaris システムのブート (手順) x86 システムでフェイルセーフアーカイブをブートするhttp://docs.sun.com/app/docs/doc/819-0378/ggqdn?l=ja&a=viewSolaris 10 System Administrator Collection - JapaneseSolaris のシステム管理 (基本編)14. Solaris ブートアーカイブの管理 (手順)http://docs.sun.com/app/docs/doc/819-0378/archive-123?l=ja&a=view特集記事: GRUB と Solaris 10 1/06 OS: x86 プラットフォーム用の新しいブートローダーhttp://www.sun.com/bigadmin/hubs/multilingual/japanese/content/grub_boot_solaris.jsp

Solaris 10 1/06 以降では、boot archive と呼ばれる OS 起動に必要なファイルを一纏めにした特別なファイルを利用して起動するようになりました。Solaris 10 x86 において新しいブートローダとして GRUB を採用する際に取り入れられた機能となり、boot archive 自体は、小さな /...

Sun

ディスクドライブの RAS 機能

SAS ディスクと SATA ディスク の RAS 機能差異についてSAS ディスクは SATA ディスクと比較して、平均故障間隔 (MTBF) が長いことやエラー発生頻度が低いことは周知のことと思います。それでは、通常稼働中のエラー制御機能の違いについてはどうでしょうか。調べ てみるとここにも違いがありました。(下記表内、色塗りされたセル)今回は、次の 2 つのディスクドライブについて確認してみました。SAS ディスク : Seagate ST3450856SSSATA ディスク : Seagate ST31000340NS  ドライブインタフェース SAS  SATA  型番 Seagate ST3450856SS Seagate ST31000340NS 24 時間 x 7 日間フル稼働時の年間故障率 0.55% 0.73%  平均故障間隔 (MTBF) 160 万時間 120 万時間 修正不可能エラー発生頻度 (ビット読み込みあたり) 1 セクタ / 10\^16 1 セクタ / 10\^15  誤り制御/エラー訂正機能 (ECC) 最大 320 ビット 10 ビット Background Media Scan ○ × Media Pre-Scan ○ × Deffered Auto-Reallocation ○ × Idle time Read after Write ○ ○Background Media Scan (BMS)    ディスクドライブが idle 時に読み込みテ ストを行う機能Media Pre-Scan    書き込み前に BMS 済みかを確認し、未実施なら Write Verify を実行する機能Deffered Auto-Reallocation (DAR)    書き込み時に unreadable かどうかを確認し、unreadable な場合に自動で再配置する機能Idle time Read after Write (IRAW)    ディスクドライブが idle 時に最近 書き込まれたデータと発行された Write コマンドのデータとを比較し、必要に応じて修正する機能まとめ SAS ディスクも 600GB@15KRPM モデルがリリースされて大容量化が進んでいますから、 Sun Storage J4200/J4400 のような JBOD ストレージを選定する際は、容量や使用期間の長さ以外にもドライブ単体の RAS 機能の違いから SAS ディスク構成の検討もしてみてはいかがでしょうか。もちろん ZFS にてファイルシステムレベルでデータ整合性を担保するというのもお忘れ無く。

SAS ディスクと SATA ディスク の RAS 機能差異について SAS ディスクは SATA ディスクと比較して、平均故障間隔 (MTBF) が長いことやエラー発生頻度が低いことは周知のことと思います。 それでは、通常稼働中のエラー制御機能の違いについてはどうでしょうか。調べ てみるとここにも違いがありました。(下記表内、色塗りされたセル)今回は、次の 2...

Sun

IPMP でネットワークの負荷を分散する

はじめにSolaris の IPMP には送信パケットの負荷を分散するアウトバウンド・ロード・スプレッディングという機能があります。マニュアル にも記載されていますので、ご存知の方も多いと思いますが、この機能を利用するとサーバからの返信時(アウトバウンド)のネットワークの負荷(ロード)を複数のインターフェイスに分散(スプレッディング)する事が可能になり、結果としてスループットを上げることができる場合があります。今回の記事ではその挙動をご覧頂きたいと思います。 検証環境検証用に次の図の様な環境を用意しました。サーバには igb1 と igb2 という 1 Gigabit のネットワークインターフェイスがあり、どちらも同じネットワークセグメントに接続されています。この 2 つのインターフェイスに負荷を分散することができれば、最大で 2 Gigabit の帯域を使用出来ることになります。igb1 の IP アドレスは 192.168.10.1/24 で、igb2 の IP アドレスは 192.168.10.2/24 です。サーバと同じセグメントにはクライアントマシンが 2 台接続されています。クライアント A の IP アドレスは 192.168.10.3/24, クライアント B の IP アドレスは 192.168.10.4/24 です。なお、サーバにはテスト用に lighttpd をインストールしてあります。サーバもクライアントも OS は Solaris 10 10/09 です。 +-----------------+ o Switching Hub 192.168.10.0/24 | | | | | 192.168.10.1 | | igb1 +-----------------+ | | | 192.168.10.3 +----------+ | Server | +-----------------+ Client A | | | 192.168.10.2 | +----------+ | igb2 +-----------------+ | | | 192.168.10.4 +----------+ | | +-----------------+ Client B | +-----------------+ | +----------+ oサーバ側のネットワークの設定は以下の通り行いました。 # ifconifg igb1 plumb # ifconfig igb1 inet 192.168.10.1/24 broadcast + up # ifconfig igb2 plumb # ifconfig igb2 inet 192.168.10.2/24 broadcast + upなお、ルーティングは停止してあります。 # routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding disabled disabled IPv6 forwarding disabled disabled ...SPARC マシンで試す場合は local-mac-address? を true に設定して下さい。 # eeprom local-mac-address?=true # reboot [検証1] IPMP を組んでいない場合の挙動この検証環境を使って、まずは IPMP を組んでいない場合の挙動から見て行きましょう。 HTTP で接続するテストには HTTP を使用しました。2 台のクライアントからサーバの HTTP ポートに telnet コマンドで同時に接続し、返信パケットの負荷分散が行われるかを確認します。クライアントからの送信時もネットワーク帯域を有効に利用するため、クライアントはそれぞれ別のネットワークインターフェイスを目指して接続する事にします。クライアント A の接続先は 192.168.10.1 の 80 番ポートで、クライアント B の接続先は 192.168.10.2 の 80 番ポートです。これは丁度、複数のウェブサーバの手前にロードバランサーを置いて負荷分散している構成と似ています。今回の構成はサーバが一台だけで済んでいると言う点だけが異なります。物理構成上はサーバとクライアント A の間の通信と、サーバとクライアント B の間の通信は、全く重複しない経路を通る事が可能です。それぞれの通信が完全に別々の経路を通った場合、ネットワーク帯域は最大 2 Gigabit となります。実際にどういう動きになるか見てみましょう。 <<クライアント A から HTTP で接続>> # telnet 192.168.10.1 80 <<クライアント B から HTTP で接続>> # telnet 192.168.10.2 80クライアントから接続したら、意図した通りの接続になっているかを netstat -a コマンドで確認します。コマンドの出力結果を見ると、クライアント A は 192.168.10.3 から 192.168.10.1 の 80 番ポートへ、クライアント B は 192.168.10.4 から 192.168.10.2 の 80 番ポートへきちんと接続されている事が分かります。サーバ側でも同じ IP アドレスのペアで接続を受け取っている事が確認出来ます。 <<クライアント A>> # netstat -a | grep 80 192.168.10.3.42881 192.168.10.1.80 49640 0 49640 0 ESTABLISHED <<クライアント B>> # netstat -a | grep 80 192.168.10.4.37305 192.168.10.2.80 49640 0 49640 0 ESTABLISHED <<サーバ>> # netstat -a | grep 80 192.168.10.1.80 192.168.10.3.42881 49640 0 49640 0 ESTABLISHED 192.168.10.2.80 192.168.10.4.37305 49640 0 49640 0 ESTABLISHED HTTP の通信が実際にどの経路を通るかを確認する次に HTTP の通信を発生させて、実際にどのネットワークインターフェイスを通ってデータがやり取りされるかを確認します。HTTP の通信はクライアント側からファイルを GET する事で発生させます。 <<クライアント A>> # telnet 192.168.10.1 80 Trying 192.168.10.1... Connected to 192.168.10.1. Escape character is '\^]'. GET /001.txt HTTP/1.0 <<クライアント B>> # telnet 192.168.10.2 80 Trying 192.168.10.2... Connected to 192.168.10.2. Escape character is '\^]'. GET /001.txt HTTP/1.0ネットワークインターフェイスの使用状況は、サーバ側で dladm コマンドを使用して確認します。dladm コマンドの出力は rbytes がそのインターフェイスに於ける受信バイト数、obytes が送信バイト数です。この値が 0 以外であればデータ通信が発生している事を示しています。下記の出力結果を見ると igb1 は受信も送信もデータのやり取りが発生しています。一方、igb2 は受信バイト数は上がっていますが、送信バイト数は 0 になっており、データの送信には使われていない事が分かります。igb2 で受け付けた接続の返信パケットはどうなってしまったのでしょうか。 # dladm show-dev -s -i 1 igb1 ipackets rbytes ierrors opackets obytes oerrors igb1 503 32192 0 1893 2797601 0 ipackets rbytes ierrors opackets obytes oerrors igb1 389 24896 0 1975 2931778 0 ipackets rbytes ierrors opackets obytes oerrors igb1 416 26624 0 1644 2438276 0 # dladm show-dev -s -i 1 igb2 ipackets rbytes ierrors opackets obytes oerrors igb2 386 24704 0 0 0 0 ipackets rbytes ierrors opackets obytes oerrors igb2 469 30016 0 0 0 0 ipackets rbytes ierrors opackets obytes oerrors igb2 628 40192 0 0 0 0 パケットの中身を確認するもう少し詳しく状況を調査するため、igb1 を通るパケットを snoop コマンドでキャプチャします。snoop コマンドに -o オプションを付けて、保存先のファイル名を指定するとパケットを保存する事が出来ます。保存したファイルから読み込む場合は -i オプションでファイルを指定します。また、snoop コマンドに port 80 オプションを付けると、80 番ポートを通ったパケットだけを抽出する事が出来ます。同じく src 192.168.10.3 オプションを付けた場合は、送信元アドレスが 192.168.10.3 のパケットだけを抽出します。snoop コマンドのデフォルトの出力は一つのパケットに付き一行ずつ表示されます。出力の内容は、一番左がパケットに順番に振られる通し番号、続いて前のパケットを受け取ってからの経過時間、送信元 IP アドレス、宛先 IP アドレス、残りは通信プロトコル毎の出力です。snoop コマンドを使用して igb1 上で port 80 番のパケットを見ると、192.168.10.2 から送信されるパケットも igb1 を通って外へ出て行っている事が分かります("->" の左側の送信元アドレスが 192.168.10.2 になっているパケットがあります)。src オプションで抽出すると、受信パケットは 192.168.10.3 から送信された物だけです。これで先ほどの dladm コマンドの出力で送信パケットが片方のインターフェイスしか使っていなかった理由が分かりました。サーバに入ってくるパケットは別々のインターフェイスを通っていますが、サーバから出て行くパケットは igb1 のインターフェイスしか使っていない様です。しかし、これでは返信パケットは片方のインターフェイスの帯域しか使用する事が出来ません。また 192.168.10.2 は igb2 に設定された IP アドレスなのに何故 igb1 から出て行っているのでしょうか。 <<サーバ>> # snoop -d igb1 -o /var/tmp/snoop01.dump ... \^C # snoop -i /var/tmp/snoop01.dump port 80 1 0.00000 192.168.10.3 -> 192.168.10.1 HTTP C port=42875 2 0.00012 192.168.10.1 -> 192.168.10.3 HTTP R port=42875 3 0.00010 192.168.10.3 -> 192.168.10.1 HTTP C port=42875 4 2.21303 192.168.10.2 -> 192.168.10.4 HTTP R port=37300 5 16.15477 192.168.10.3 -> 192.168.10.1 HTTP GET /001.txt HTTP/1.0 ... # snoop -i /var/tmp/snoop01.dump src 192.168.10.3 1 0.00000 192.168.10.3 -> 192.168.10.1 HTTP C port=42875 2 0.00023 192.168.10.3 -> 192.168.10.1 HTTP C port=42875 3 18.36780 192.168.10.3 -> 192.168.10.1 HTTP GET /001.txt HTTP/1.0 4 2.85314 192.168.10.3 -> 192.168.10.1 HTTP (body) 5 0.00014 192.168.10.3 -> 192.168.10.1 HTTP C port=42875 ... # snoop -i /var/tmp/snoop01.dump src 192.168.10.4 経路情報を確認する送信元アドレスが 192.168.10.2 のパケットが何故 igb1 から送り出されるのかを調べる為にサーバ側でルーティングテーブルを確認します。netstat -ar コマンドの出力を見ると、クライアント A(192.168.10.3) 宛の経路もクライアント B(192.168.10.4) 宛の経路も igb1 になっている事が分かります。192.168.10.4 宛のパケットの送信元アドレスは igb2 に割り当てた 192.168.10.2 ですが、192.168.10.4 宛の経路は igb1 が選択されています。これが送信元アドレスが 192.168.10.2 のパケットが igb1 から送信されていた原因です。 <<サーバ>> # netstat -ar | egrep '192.168.10.3|192.168.10.4' 192.168.10.3 -- UHA 1 1 igb1 192.168.10.4 -- UHA 1 1 igb1たまたま経路情報が偏っていたという可能性も考えられますので、念の為にルーティングのキャッシュを消去して何度も接続をテストしてみます。結果は以下の通り、何度接続し直しても経路は片方のネットワークインターフェイスにまとめられてしまいます。これが IPMP を使用しない場合の挙動です。 <<サーバ側でルーティングテーブルのエントリを消去する>> # arp -d 192.168.10.3; arp -d 192.168.10.4 192.168.10.3 (192.168.10.3) deleted 192.168.10.4 (192.168.10.4) deleted # arp -d 192.168.10.3; arp -d 192.168.10.4 192.168.10.3 (192.168.10.3) -- no entry 192.168.10.4 (192.168.10.4) -- no entry <<再びクライアントから接続した後にルーティングテーブルを確認>> # netstat -ar | egrep '192.168.10.3|192.168.10.4' 192.168.10.3 -- UHA 2 6 igb1 192.168.10.4 -- UHA 2 6 igb1 まとめ単純にネットワークにインターフェイスを繋いだ場合、クライアントから送られて来たパケットは宛先 IP アドレスの通りのインターフェイスを通り、サーバから返信されるパケットは常に一つのインターフェイスだけを通る事が分かりました。言い換えれば、受信パケットは 2 つのインターフェイスの帯域を有効に利用しているのに対し、返信パケットが使用出来る帯域はポート 1 つ分しかないことになります。 [検証2] IPMP を組んだ場合の挙動ご覧頂きました通り、ここまでの構成では返信パケットは常に片方のポートしか通りませんでした。これでは帯域の利用効率は良くありません。IPMP のアウトバウンド・ロード・スプレッディングを使用する事で両方のポートを利用する様に変更する事が可能です。見てみましょう。 構成これまでの構成に加えて、サーバの igb1 と igb2 で IPMP を組みます。IPMP の構成は簡単です。ifconfig の group オプションに適当な IPMP グループ名を指定するだけで完了します。グループ名は ipmp としましたが、その他の文字列でも構いません。 # ifconfig igb1 group ipmp # ifconfig igb2 group ipmpIPMP を組んで ifconfig でインターフェイスの一覧を見ると groupname ipmp と表示され、インターフェイスが IPMP に参加している事が分かります。 # ifconfig -a ... igb1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 192.168.10.1 netmask ffffff00 broadcast 192.168.10.255 groupname ipmp ether 0:14:4f:cb:16:b1 igb2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4 inet 192.168.10.2 netmask ffffff00 broadcast 192.168.10.255 groupname ipmp ether 0:14:4f:cb:16:b2 HTTP で接続する先ほどと同じ様に HTTP で接続してテストを行います。クライアント A は 192.168.10.1 に、クライアント B は 192.168.10.2 に、同時に接続します。返信パケットが負荷分散されるかどうか確認しましょう。 経路情報を確認するnetstat コマンドで経路情報を見てみると、今度はクライアント A(192.168.10.3) への接続は igb1 を、クライアント B(192.168.10.4) への接続は igb2 を通る様になっている事が分かります。IPMP を組む前は両方とも igb1 を通る様になっていましたが、IPMP を組むと別々のインターフェイスを使う様になりました。 <<サーバ>> # netstat -ar | egrep '192.168.10.3|192.168.10.4' 192.168.10.3 -- UHA 1 1 igb1 192.168.10.4 -- UHA 1 1 igb2 実際にどの経路を通っているかを確認する続いて dladm コマンドを使用して、実際にどの経路を通って通信が行われているのかを見てみます。以下の出力結果を見ると、igb1 の opackets も igb2 の opackets も 0 以外の数値になっています。IPMP を組んだことにより、返信のパケットも 2 つのネットワークインターフェイスに股がって分散される様になりました。 <<サーバ>> # dladm show-dev -s -i 1 igb1 ipackets rbytes ierrors opackets obytes oerrors igb1 369 23616 0 718 1067024 0 ipackets rbytes ierrors opackets obytes oerrors igb1 384 24576 0 746 1107084 0 ipackets rbytes ierrors opackets obytes oerrors igb1 384 24576 0 746 1104508 0 # dladm show-dev -s -i 1 igb2 ipackets rbytes ierrors opackets obytes oerrors igb2 542 34688 0 1056 1555293 0 ipackets rbytes ierrors opackets obytes oerrors igb2 414 26496 0 806 1189420 0 ipackets rbytes ierrors opackets obytes oerrors igb2 452 28928 0 882 1308835 0igb1 を snoop すると、igb1 のインターフェイスはクライアント A(192.168.10.3) と 192.168.10.1 の間の通信のみに使われている事が分かります。 # snoop -d igb1 -o /var/tmp/snoop_igb1.dump # snoop -i /var/tmp/snoop_igb1.dump host 192.168.10.1 1 0.00000 192.168.10.3 -> 192.168.10.1 HTTP C port=42878 2 0.00002 192.168.10.1 -> 192.168.10.3 HTTP R port=42878 3 0.00010 192.168.10.3 -> 192.168.10.1 HTTP C port=42878 4 7.98546 192.168.10.3 -> 192.168.10.1 HTTP GET /001.txt HTTP/1.0 5 0.00001 192.168.10.1 -> 192.168.10.3 HTTP R port=42878 ... # snoop -i /var/tmp/snoop_igb1.dump host 192.168.10.2 <-- 192.168.10.2 との通信には使用されていない # snoop -i /var/tmp/snoop_igb1.dump host 192.168.10.3 1 0.00000 192.168.10.3 -> 192.168.10.1 HTTP C port=42878 2 0.00002 192.168.10.1 -> 192.168.10.3 HTTP R port=42878 3 0.00010 192.168.10.3 -> 192.168.10.1 HTTP C port=42878 4 7.98546 192.168.10.3 -> 192.168.10.1 HTTP GET /001.txt HTTP/1.0 5 0.00001 192.168.10.1 -> 192.168.10.3 HTTP R port=42878 ... # snoop -i /var/tmp/snoop_igb1.dump host 192.168.10.4 <-- 192.168.10.4 との通信には使用されていない一方 igb2 はクライアント B(192.168.10.4) と 192.168.10.2 の間の通信にのみ使用されている事が分かります。 # snoop -d igb2 -o /var/tmp/snoop_igb2.dump # snoop -i /var/tmp/snoop_igb2.dump host 192.168.10.1 <-- 192.168.10.1 との通信には使用されていない # snoop -i /var/tmp/snoop_igb2.dump host 192.168.10.2 1 0.00000 192.168.10.4 -> 192.168.10.2 HTTP C port=37303 2 0.00001 192.168.10.2 -> 192.168.10.4 HTTP R port=37303 3 0.00009 192.168.10.4 -> 192.168.10.2 HTTP C port=37303 4 6.40605 192.168.10.4 -> 192.168.10.2 HTTP GET /001.txt HTTP/1.0 5 0.00001 192.168.10.2 -> 192.168.10.4 HTTP R port=37303 ... # snoop -i /var/tmp/snoop_igb2.dump host 192.168.10.3 <-- 192.168.10.3 との通信には使用されていない # snoop -i /var/tmp/snoop_igb2.dump host 192.168.10.4 1 0.00000 192.168.10.4 -> 192.168.10.2 HTTP C port=37303 2 0.00001 192.168.10.2 -> 192.168.10.4 HTTP R port=37303 3 0.00009 192.168.10.4 -> 192.168.10.2 HTTP C port=37303 4 6.40605 192.168.10.4 -> 192.168.10.2 HTTP GET /001.txt HTTP/1.0 5 0.00001 192.168.10.2 -> 192.168.10.4 HTTP R port=37303 ... まとめIPMP を使用すると、サーバからの返信時もネットワーク負荷が複数のインターフェイスに分散される事が分かりました。これで複数のネットワークインターフェイスの帯域を最大限に有効利用する事が出来ます。 チューニングパラメータ一度クライアントまでの経路が決定されると、その後の接続はキャッシュを元に経路が選択される様になります。既に見た通り、キャッシュは netstat -ar で確認、arp -d で削除する事が可能です。このキャッシュの有効期限は ip_ire_arp_interval と arp_cleanup_interval パラメータで設定する事が出来ます。もし経路に偏りが発生していた場合は有効期限を短く設定すると経路選択の機会が増えて偏りが解消されるかもしれません。ip_ire_arp_interval と arp_cleanup_interval の確認方法と設定方法は以下の通りです。 # ndd -get /dev/ip ip_ire_arp_interval 1200000 # ndd -set /dev/ip ip_ire_arp_interval 60000 # ndd -get /dev/arp arp_cleanup_interval 300000 # ndd -set /dev/arp arp_cleanup_interval 30000 おわりに今回は IPMP のアウトバウンド・ロード・スプレッディング機能による負荷分散をご紹介しました。要件次第では、簡単にネットワークの実行帯域を増やす事が可能です。特にウェブサーバやファイルサーバは、IPMP のアウトバウンド・ロード・スプレッディングだけで十分かもしれません。サンのサーバの多くは最小構成でもネットワークインターフェイスを4ポート装備しています。Solaris の機能を活用し、是非それらのポートを有効利用して下さい。 補足 IPMP の作成は簡単でしたが、削除も簡単に出来ます。ifconfig コマンドの group オプションに空文字を指定してください。groupname エントリが消えていれば IPMP も解除されています。 # ifconfig igb1 group '' # ifconfig igb2 group '' IPMP のアウトバウンド・ロード・スプレッディングでどの経路を通るかはラウンドロビンで決定されます。例えば igb1, igb2 の 2 つのインターフェイスを使用した IPMP で、2 台のクライアントからコネクションが張られていた場合、最初のクライアントからの接続が igb1 を経由して返ったなら、次のクライアントからの接続は igb2 を経由して返ります。この時、クライアントからの接続を受けたインターフェイスとは別のインターフェイスを経由してクライアントに返る事もあります。また、ラウンドロビンで経路が決まるのは、コネクションが一本しか無い場合も例外ではありません。igb1 で受け取ったコネクションが igb2 から出て行くというケースも普通に発生します。その場合も、返信パケットの送信元 IP アドレスが書き変わったりする事はありません。コネクション数が少ない場合は通信が片方のインターフェイスに偏る事があります。例えば 3 台のクライアントから接続があり、その内 2 台への返信パケットが igb1 を通り、残りの 1 台が igb2 を通っていた場合、igb2 を使用していたコネクションが終了すると、クライアントは 2 台あるのに、インターフェイスは片方しか使用されていない状態になります。アウトバウンド・ロード・スプレッディングは、インターフェイスの負荷を監視してロードバランスするのではなく、単純にラウンドロビンでロードスプレッドしているだけなので、インターフェイスの数に対してクライアントの数が多ければ多いほど効率よく帯域を使用する事が出来ます。 IPMP のアウトバウンド・ロード・スプレッディングは片方のインターフェイスにのみ IP アドレスを振った場合にも有効になります。構成の仕方は こちら をご参照下さい。以下の例では、igb2 には IP アドレスが設定されていませんが、192.168.10.4 宛の経路には igb2 が選択されています。サーバ側で受信用の帯域がそれ程必要とされておらず、使用する IP アドレスを減らしたい場合は、この構成が便利です。 # ifconfig -a ... igb1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 192.168.10.1 netmask ffffff00 broadcast 192.168.10.255 groupname ipmp ether 0:14:4f:cb:16:b1 igb2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5 inet 0.0.0.0 netmask ff000000 groupname ipmp ether 0:14:4f:cb:16:b2 # netstat -ar | egrep '192.168.10.3|192.168.10.4' 192.168.10.3 -- UHA 2 25 igb1 192.168.10.4 -- UHA 2 25 igb2 アウトバウンド・ロード・スプレッディングによる負荷分散はクライアントの IP アドレス毎です。コネクション毎ではありません。 クライアントとサーバの間にルータを挟んだ場合もアウトバウンド・ロード・スプレッディングは有効です。パケットの送信に使われるインターフェイスはクライアントの IP アドレス毎に決定されます。以下の例はクライアント A(192.168.11.2) とクライアント B(192.168.12.2) が、ルータ (192.168.10.3) を経由して、IPMP を構成したサーバへアクセスした際の、サーバのルーティングテーブルです。クライアントへの経路が igb1 と igb2 に分かれている事が分かります。 <<サーバ>> # netstat -ar | egrep '192.168.11.2|192.168.12.2' 192.168.11.2 192.168.10.3 UHA 1 1 igb2 <-- ルータ経由のクライアント A 192.168.12.2 192.168.10.3 UHA 1 1 igb1 <-- ルータ経由のクライアント B IPMP に参加出来るポートの数は 2 つに限定されている訳ではありません。オンボードのインターフェイスを全て同一の IPMP に入れる事も可能ですし、もっと多くのポートを参加させる事も可能です。 arp -d で ARP のエントリを削除するとルーティングの情報も削除され、即座に経路が変更されます。netstat -ar で表示される一番上のエントリが経路として使用され、arp -d で一番最初に消去されます。 サーバ側からコネクションを張る場合は IP ソースアドレス・セレクションという別の機能を使って負荷分散されます。サーバがクライアントにコネクションを張る際に、送信元 IP アドレスを自分の複数のインターフェイスからラウンドロビンで決定する事で、クライアントが返信する先の IP アドレスを操作する事が出来、結果的にサーバが受信する際の負荷分散になります。これは IPMP の機能ではなく IP の機能です。コネクションを張る時に IP モジュールより上位で送信元 IP アドレスが設定されていない事が条件です。 IPMP のアウトバウンド・ロード・スプレッディングはリンクアグリゲーション (dladm(1M)) と併用する事も可能です。また、OpenSolaris の ILB(Integrated Load Balancer) と組み合わせて使うと更に便利かもしれません。 参考文献Solaris のシステム管理 (IP サービス)IP アドレスを削減! Link-Base の IPMP 設定方法

はじめに Solaris の IPMP には送信パケットの負荷を分散するアウトバウンド・ロード・スプレッディングという機能があります。マニュアルにも記載されていますので、ご存知の方も多いと思いますが、この機能を利用するとサーバからの返信時(アウトバウンド)のネットワークの負荷(ロード)を複数のインターフェイスに分散(スプレッディング)する事が可能になり、結果としてスループットを上げることができる場合...

Sun

Calendar Server 7 を iPhone から使ってみよう

サンは今年9月末にCommunications Suite 7 を新しく発表しました。今回は、その Communications Suite 7 に含まれる新しい CalDAV 対応カレンダサーバである Calendar Server 7 をインストール・設定し、iPhone,Thunderbird Lightining から利用してみましょう。Calendar Server 7 のインストールシナリオを確認すると、カレンダサーバのインストールには下記の手順が必要になります。Directory Server のインストールGlassFish Enterprise Server 2.1 のインストールCalendar Server と MySQL のインストールMySQL の設定Calendar Server の設定また、Calendar Server のユーザ管理には Delegated Administrator が使えます。Delegated Administrator では、Access Manager を利用する Schema 2 を利用する構成方法と、Access Manager を使わず Directory Server だけで利用できる Schema 1 を利用する構成方法があります。今回は単純に Calendar Server のみ使えれば良いので、Scheme 1 を利用する設定にて Delegated Administrator をインストールしましょう。ソフトウェアの入手Directory Server のインストールGlassFish Enterprise Server 2.1 のインストールDelegated Administrator のインストールCalendar Server と MySQL のインストールMySQL の設定Calendar Server の設定カレンダユーザの作成iPhone からの設定Thunderbird Lightning からの設定 1. ソフトウェアの入手まずは、入手先より Communications Suite 7, GlassFish Enterprise Server 2.1 Patch 02, Directory Server 6.3.1 をダウンロードします。sw-79# pwd/var/tmp/Comm7sw-79# ls126748-05.zip ci-7.0-0.02-SunOS_sparc.zipDSEE.6.3.Solaris-Sparc-full.tar.gz sges_ee-2_1-p02-solaris-sparc.binsw-79# 2. Directory Server のインストールDirecotry Server は、Communications Suite 7 Installation Scenario - Directory Server に沿って、インストールします。インストールログへのリンク 3. GlassFish Enterprise Server 2.1 のインストールGlassFishも同様に、Communications Suite 7 Installation Scenario - GlassFish Enterprise Server に沿って、インストールします。JDK6 がインストールされていない場合は、入手先よりパッケージをダウンロードしてドキュメントを参考にインストールしてください。インストールログへのリンク 4. Delegated Administrator のインストール・設定Delegated Administrator は、Direct LDAP モードで設定するので、下記のログを参考にインストールしてください。インストール・設定が完了したら http://hostname:8080/da にて管理画面にログインできます。インストールログへのリンク 5. Calendar Server と MySQL のインストールインストールログへのリンク 6. MySQL の設定設定ログへのリンク 7. Calendar Server の設定設定ログへのリンク 8. カレンダユーザの作成DAの管理画面(http://hostname:8080/da)より、サービスパッケージを割り当ててユーザを作成しましょう。まず、組織にサービスパッケージを割り当てます。次に、サービスパッケージを割り当てたユーザを作成します。 9. iPhone からの設定※ クライアント設定はこのドキュメントが参考になります。設定 -> メール -> アカウントを追加を選びます。その他を選びます。CalDAV アカウントを追加を選びます。サーバ欄にアカウント URL を設定・ユーザ名とパスワードを設定します。※ 今回のテストではアカウント URL は、http://sw-79.japan.sun.com:8080/davserver/dav/principals/japan.sun.com/test1/ になります。サーバ欄には、URL では無く、サーバ名が表示されます。詳細設定を確認すると、ポート番号と URL が入力されている事を確認できます。カレンダアプリを起動するとサーバが追加されていることが確認できます。テストの予定を追加してみましょう。 10. Thunderbird Lightning からの設定※ クライアント設定はこのドキュメントが参考になります。Lightning から新しいカレンダを登録します。CalDAV を選んで、URL を入力します。※ 今回のテストではアカウント URL は、http://sw-79.japan.sun.com:8080/davserver/dav/home/test1@japan.sun.com/calendar になります。設定を終えると、ユーザ名とパスワードを入力するウィンドウが開きます。ただしく、ログインできると iPhone から入力したテストの予定が確認できます。まとめ以上で設定は終了です。このように、新しいカレンダサーバは標準規格である CalDAV をサポートしているため、今回設定した iPhone, Lightning のほかにも Apple の iCal など多様なクライアントから利用可能です。ぜひ新しい、カレンダサーバをお試し下さい!

サンは今年9月末にCommunications Suite 7 を新しく発表しました。 今回は、その Communications Suite 7 に含まれる新しい CalDAV 対応カレンダサーバである Calendar Server 7 をインストール・設定し、iPhone, Thunderbird Lightining から利用してみましょう。 Calendar Server 7 のインストールシ...

Sun

User/Group単位で ZFS の quota を設定する方法

今回は、前回に引き続き Solaris 10 10/09(Update 8) でサポートされたZFS 新機能の関連記事で、ZFS の quota 管理がユーザ/グループ単位で設定できるようになりましたので紹介します。今まで ZFS のファイルシステムに対する quota による容量制限は、プール内のファイルシステム単位という制約があり、管理者がユーザ/グループ単位で容量制限を行うには、ユーザ/グループ毎にそれぞれファイルシステムを作成するしか方法がありませんでした。しかし、この方法では多くのユーザがいる場合、ファイルシステムの数が多くなってしまい、管理の面であまり実現的ではありませんでした。今までの quota 設定方法(ファイルシステム単位)# zfs set quota=10g tank/home今回、ユーザ/グループ単位で ZFS ファイルシステムの quota を設定できるようになりましたので、その手順を紹介します。ユーザによる quota 設定方法# zfs set userquota@user01=100m tank/home# zfs get userquota@user01NAME PROPERTY VALUE SOURCE tank userquota@user01 none local tank/home userquota@user01 100M local グループによる quota 設定方法# zfs set groupquota@staff=500m tank/home# zfs get groupquota@staffNAME PROPERTY VALUE SOURCE tank groupquota@staff none local tank/home groupquota@staff 500M local最後に、 quota 動作の確認として、ユーザ単位で quota 制限がかかっているか mkfile を使って確認してみます。今回は、上記で設定で user01 に 100MB の quota 制限を設定しましたので、user01 で 150MB のファイルを作成してみます。% /usr/ucb/whoamiuser01 % mkfile 150m /tank/home/aaaaaa: initialized 111108096 of 157286400 bytes: Disc quota exceeded 「ユーザ単位の quota 制限が発生しました」 とメッセージが出てこないのは残念ですが、きちんとユーザ単位で quota 制限が設定されている事が確認できました。(参考情報)過去の 「やっぱり Sun がスキ!」blog 記事一覧はこちらを参照下さい。http://wikis.sun.com/display/yappri/Home

今回は、前回に引き続き Solaris 10 10/09(Update 8) でサポートされた ZFS 新機能の関連記事で、ZFS の quota 管理がユーザ/グループ単位で設定できる ようになりましたので紹介します。 今まで ZFS のファイルシステムに対する quota による容量制限は、 プール内のファイルシステム単位という制約があり、管理者がユーザ/グループ単位で容量制限を行うには、ユー...

Sun

Solaris 10 で ZFS の Hybrid Storage Pool を作る方法

今回は、今月リリースした Solaris 10 10/09(Update 8) でサポートされたZFS の L2ARC(Level 2 Adaptive Replacement Cache) 設定方法を紹介します。L2ARC とは、ZFS Hybrid Storage Pool の Read 用二次キャッシュとして機能し、通常 SSD が使用され Read 速度の向上を促します。今まで Solaris 10 で ZFS のプールをする場合、Write 速度の向上させるZIL(ZFS Intent Log)は作成できましたが、L2ARC を作成する事ができませんでした。(L2ARC を使用したい場合は OpenSolaris を選択するしかありませんでした。)Solaris 10 が 10/09 になり、L2ARC がサポートされましたので、これで Solaris 10 上で完全な Hybrid Storage Pool を作成できるようになりました。それでは早速 Hybrid Storage Pool を作ってみましょう。とっても簡単です。作成方法は、ZFS pool 作成時のオプションに ZIL を log で指定、L2ARC を cache で指定するだけです。(通常、log と cache のデバイスは SSD を使用します。)# zpool create tank raidz c2t0d0 c2t1d0 c2t2d0 c2t3d0 log c2t4d0 cache c2t5d0# zpool status プール: tank 状態: ONLINE スクラブ: 何も要求されませんでした 構成: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 c2t1d0 ONLINE 0 0 0 c2t2d0 ONLINE 0 0 0 c2t3d0 ONLINE 0 0 0 logs c2t4d0 ONLINE 0 0 0 cache c2t5d0 ONLINE 0 0 0 エラー: 既知のデータエラーはありませんはい、これで Hybrid Storage Pool が作成できました。logs(ZIL) と cache(L2ARC) にデバイスが割り当てられております。ちなみに、ZIL をミラーしたい場合は以下のように指定します。# zpool create tank raidz c2t0d0 c2t1d0 c2t2d0 c2t3d0 log mirror c2t4d0 c2t5d0 # zpool status プール: tank 状態: ONLINE スクラブ: 何も要求されませんでした 構成: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 c2t1d0 ONLINE 0 0 0 c2t2d0 ONLINE 0 0 0 c2t3d0 ONLINE 0 0 0 logs mirror ONLINE 0 0 0 c2t4d0 ONLINE 0 0 0 c2t5d0 ONLINE 0 0 0 エラー: 既知のデータエラーはありませんL2ARC に SSD を使用する事により、 DRAM だけでキャッシュを構築する場合と比較して大容量で低価格な構成を提案できるようになります。Read が多い NFS サーバには最適ですね。(参考情報)過去の 「やっぱり Sun がスキ!」blog 記事一覧はこちらを参照下さい。http://wikis.sun.com/display/yappri/Home

今回は、今月リリースした Solaris 10 10/09(Update 8) でサポートされた ZFS の L2ARC(Level 2 Adaptive Replacement Cache) 設定方法を紹介します。 L2ARC とは、ZFS Hybrid Storage Pool の Read 用二次キャッシュとして機能 し、通常 SSD が使用され Read 速度の向上を促します。今まで...

Sun

OpenSolaris 2009.06 で Zone を作成する

今回は、OpenSolaris 2009.06 で Solarisコンテナを作成する手順を纏めてみましたので紹介します。今まで、「やっぱり Sun がスキ!」ブログでは、Solaris 10 ベースの Solarisコンテナに関する TIPS をいろいろ紹介して来ましたが、OpenSolaris 2009.06 では Solaris 10 と少し変わっていますので、Solaris 10 との違いを中心に説明していきます。ステップ1 zonepath 用のディレクトリを作成するZone 作成時に一番重要なプロパティは zonepath ですが、Solaris 10 のように適当なディレクトリを mkdir で作成して zonepath に設定してはいけません。OpenSolaris 2009.06 では、zonepath に ZFS のデータセット名を指定する必要があります。例えば、zonepath に /rpool/zones/test-zone と指定したい場合は、あらかじめ下記の設定が必要になります。# zfs create rpool/zones# zfs create rpool/zones/test-zone# chmod 700 /rpool/zones/test-zoneステップ2 Zone の作成を行う次に zonecfg で Zone名 test-zone の作成を行います。# zonecfg -z test-zonetest-zone: No such zone configuredUse 'create' to begin configuring a new zone.zonecfg:test-zone> createzonecfg:test-zone> set zonepath=/rpool/zones/test-zoneここで設定値を確認してみます。zonecfg:test-zone> infozonename: test-zonezonepath: /rpool/zones/test-zonebrand: ipkgautoboot: falsebootargs: pool: limitpriv: scheduling-class: ip-type: sharedhostid: info の出力結果で注目する箇所は、Solaris 10 と違いブランド名が native でなく ipkg 形式になっている事です。従いまして、inherit-pkg-dir のプロパティも無くなっています。zonecfg の設定を保存した後、zone の状態を確認してみます。# zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / native shared - test-zone configured /rpool/zones/test-zone ipkg sharedtest-zone のブランドが native でなく ipkg になっています。ステップ3 Zone のインストールを行うZone の作成が完了しましたので、インストールを行います。# zoneadm -z test-zone install Publisher: Using opensolaris.org (http://pkg.opensolaris.org/release/). Image: Preparing at /rpool/zones/test-zone/root.Sanity Check: Looking for 'entire' incorporation. Installing: Core System (output follows)DOWNLOAD PKGS FILES XFER (MB)Completed 20/20 3021/3021 42.55/42.55 PHASE ACTIONSInstall Phase 5747/5747 Installing: Additional Packages (output follows)DOWNLOAD PKGS FILES XFER (MB)Completed 37/37 5598/5598 32.52/32.52 PHASE ACTIONSInstall Phase 7329/7329 Note: Man pages can be obtained by installing SUNWman Postinstall: Copying SMF seed repository ... done. Postinstall: Applying workarounds. Done: Installation completed in 1075.241 seconds. Next Steps: Boot the zone, then log into the zone console (zlogin -C) to complete the configuration processZone のインストールを実行すると、パッケージのリポジトリからパッケージのダウンロードが開始されます。そして、ログにはインストールにかかった時間が表示されるようになりました。インストールが完了すれば、後は Solaris 10 と同様に Zone をブートして使用可能になります。# zoneadm -z test-zone boot# zlogin -C test-zoneおまけ Zone のクローンを作成するせっかく zonepath が ZFS ベースなので、Solarisコンテナのクローン機能が ZFS のクローンと連携出来ているか確認してみました。# zoneadm -z test-zone halt# zonecfg -z test-zone export -f /var/tmp/clone-zone.cfgexport したファイル内の zonepath を /rpool/zones/test-zone から /rpool/zones/clone-zone に変更します。# zonecfg -z clone-zone -f /var/tmp/clone-zone.cfg# zoneadm -z clone-zone clone test-zonesys-unconfig started 2009年09月27日 01時29分53秒rm: cannot remove `/rpool/zones/clone-zone/root/etc/vfstab.sys-u': No such file or directorygrep: /rpool/zones/clone-zone/root/etc/dumpadm.conf: No such file or directorysys-unconfig completed Sun Sep 27 01:29:53 2009Zone のクローン作成は、即時に作成できましたので ZFS のクローンときちんと連携できているようです。ZFS の状態を確認してみます。# zfs list -t snapshotNAME USED AVAIL REFER MOUNTPOINTrpool/ROOT/opensolaris@install 146M - 2.82G -rpool/zones/test-zone/ROOT/zbe@clone-zone_snap 0 - 341M -# zfs get origin | grep clonerpool/zones/clone-zone origin - -rpool/zones/clone-zone/ROOT origin - -rpool/zones/clone-zone/ROOT/zbe origin rpool/zones/test-zone/ROOT/zbe@clone-zone_snap -rpool/zones/test-zone/ROOT/zbe@clone-zone_snap origin - Zone と ZFS の連携って素敵です!

今回は、OpenSolaris 2009.06 で Solarisコンテナを作成する手順を纏めてみましたので 紹介します。 今まで、「やっぱり Sun がスキ!」ブログでは、Solaris 10 ベースの Solarisコンテナに 関する TIPS をいろいろ紹介して来ましたが、OpenSolaris 2009.06 では Solaris 10 と少し変わっていますので、Solaris 10...

Sun

DTrace を使ってロックの競合を調査する

はじめに今回は DTrace を使用してロックの競合を調査する初歩的な手順をご紹介したいと思います。DTrace には豊富なプローブが用意されていますので、アイデアさえあれば無限にスクリプトを作成することが可能です。その全てを解説することは難しいですが、DTrace を使ってマルチスレッドプログラムの動きを調べる際の基礎となるスクリプトを幾つかご紹介したいと思います。 plockstat コマンドの実装から先日ご紹介した plockstat コマンド はその機能の殆どを DTrace を利用して実装しています。OpenSolaris.org にある plockstat コマンドの ソースコード を見てみると、1000 行ほどのコードの内の 300 行ほどが DTrace スクリプトの定義で、残りはヘルパー関数になっています。実は、この plockstat コマンドに含まれている DTrace スクリプトは plockstat コマンドと独立して使用することも可能です。まず始めに、その使い方から見ていきましょう。 mutex ロックの競合を調査する DTrace スクリプトplockstat コマンドのソースコードから mutex ロックの競合を検知している部分を抜き出して、単独で実行できる様に修正したのが下記のスクリプトです。plockstat$target::: で始まるプローブが並んでいますが、plockstat コマンドに含まれるスクリプトは DTrace の plockstat プロバイダの機能を利用しています。plockstat プロバイダは mutex ロックと reader/writer ロックを監視する為の DTrace のプロバイダです。plockstat コマンドは plockstat プロバイダの機能を全面的に使用しているため、plockstat コマンドは plockstat プロバイダのラッパーと言って良いかもしれません。続いて個々のプローブを見ていきましょう。plockstat$target:::mutex-block はスレッドが mutex ロックでブロックされる直前に呼び出されるプローブです。一方 plockstat$target:::mutex-blocked はブロックから解放された直後に呼び出されますので、mutex-block と mutex-blocked で timestamp の差分を取ると mutex ロックでブロックされていた時間を割り出す事が出来ます。なお、plockstat$target:::mutex-blocked の arg1 が 0 の場合は何らかのエラーで mutex ロックが取得できなかったことを意味するため、ブロックされていた時間には加算されていません。 #!/usr/sbin/dtrace -s plockstat$target:::mutex-block { self->mtxblock[arg0] = timestamp; } plockstat$target:::mutex-blocked /self->mtxblock[arg0] && arg1 != 0/ /\* arg1 is not 0 => lock is acquired \*/ { @mtx_block[arg0, ustack(5)] = sum(timestamp - self->mtxblock[arg0]); @mtx_block_count[arg0, ustack(5)] = count(); self->mtxblock[arg0] = 0; mtx_block_found = 1; } plockstat$target:::mutex-blocked /self->mtxblock[arg0]/ /\* arg1 is 0 => error \*/ { self->mtxblock[arg0] = 0; } END /mtx_block_found/ { trace("Mutex block"); printa(@mtx_block, @mtx_block_count); } 実際に動かしてみるこのスクリプトを先日の plockstat の記事 で使用したテストプログラムに対して実行してみた結果が以下の出力です。上から、"134614312" が plockstat コマンドの "Lock" のカラムに相当する mutex ロックのアドレス、次のスタックフレームが "Caller" のカラムを作成する為のデータです。"30002403544" は mutex ロックでブロックされていた総時間です。最後の "3" は plockstat コマンドの "Count" のカラムに相当するブロックされた回数です。先ほどの総時間をブロックされた回数で割ると、ブロックされた平均時間となり plockstat コマンドの "nsec" のカラムが求まります (30002403544 nsec / 3 Count = 10000801181 nsec)。きちんと plockstat コマンドに相当する情報が得られている事が分かります。 # ./plockstat_mb.d -c ./mutex_test mtxblock はスレッド毎に一つの値だけを保持すれば良いので、単純なスレッド固有変数にしてあります。tick-1sec は DTrace の profile プロバイダのプローブで、1 秒毎に呼び出されます。ここでは 10 秒間を数えるのに使用しています。 #!/usr/sbin/dtrace -qs int ntick; BEGIN { ntick = 0; } plockstat$target:::mutex-block { self->mtxblock = timestamp; } plockstat$target:::mutex-blocked /self->mtxblock && arg1 != 0/ /\* arg1 is not 0 => lock is acquired \*/ { @mtx_block[tid]= sum(timestamp - self->mtxblock); @mtx_block_count[tid] = count(); self->mtxblock = 0; } plockstat$target:::mutex-blocked /self->mtxblock/ /\* arg1 is 0 => error \*/ { self->mtxblock = 0; } tick-1sec { ntick += 1; } tick-1sec /ntick == 10/ { trace("Count"); printa(@mtx_block_count); trace("nsec"); printa(@mtx_block); exit(0); } DTrace スクリプトの実行結果書き換えたスクリプトを plockstat コマンドの解説で使用した general.c で試してみます。Count 以下がブロックされた回数を表しており、nsec 以下がブロックされた時間を表しています。いずれも測定時間 10 秒辺りの結果です。Count の結果は、左側のカラムがスレッド ID、右側のカラムがブロックされた回数です。スレッド ID が 8 番のスレッドは 10 秒の間に 15197 回ブロックされていた事が分かります。nsec の結果も左のカラムはスレッド ID です。右側のカラムはナノ秒単位でブロックされていた総時間が出力されます。ここではスレッド ID 5 番のスレッドが 10 秒間のうち 5.8 秒間ブロックされていたことが見て取れます。 # ./plockstat_mbt.d -c ./general Count 8 15197 2 15395 3 15397 7 15418 6 15480 4 15604 9 15633 5 16011 nsec 5 5849251426 6 5891593031 9 5904264724 4 5912264400 3 5953877535 2 5983468423 7 6004800234 8 6067032588 plockstat プロバイダでトレースできないケースへの対応plockstat プロバイダはその名の通り mutex ロックと reader/writer ロックを監視対象としており、条件変数でブロックされている場合は監視する事が出来ません。マルチスレッドプログラムでは条件変数も良く利用されていますので、mutex ロックや reader/writer ロックと同様に監視できると便利です。 条件変数のテストプログラム以下のテストプログラムでは、各スレッドは main() 関数の中で res がインクリメントされるまで条件変数でブロックされます。 /\* \* cv_test.c : a test program for cv tracing. \* compile : cc cv_test.c -o cv_test \*/ #include <stdio.h> #include <unistd.h> #include <atomic.h> #include <pthread.h> void \*func(); volatile uint_t res = 0; pthread_mutex_t mp; pthread_cond_t cv; int main() { pthread_t tid1, tid2; pthread_mutex_init(&mp, NULL); pthread_cond_init(&cv, NULL); pthread_create(&tid1, NULL, func, NULL); pthread_create(&tid2, NULL, func, NULL); sleep(10); atomic_inc_uint(&res); pthread_mutex_lock(&mp); pthread_cond_broadcast(&cv); pthread_mutex_unlock(&mp); pthread_join(tid1, NULL); pthread_join(tid2, NULL); pthread_mutex_destroy(&mp); pthread_cond_destroy(&cv); exit(0); } void \*func() { pthread_mutex_lock(&mp); while(res == 0) { pthread_cond_wait(&cv, &mp); } puts("done"); pthread_mutex_unlock(&mp); pthread_exit(0); } コンパイル上記のテストプログラムを cv_test.c という名前で保存し、以下の様にコンパイルして下さい。 # gcc cv_test.c -o cv_test prstat で調査するprstat で見てみると LWPID 1 のスレッドがスリープ ("SLP") し、LWPID 2 と 3 のスレッドがロック待ち ("LCK") しているのが分かります。 # ./cv_test&; prstat -mL -p $! PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID 10189 root 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 cv_test/3 10189 root 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 cv_test/2 10189 root 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 0 0 0 0 cv_test/1 plockstat で調査するcv_test プログラムを plockstat コマンドと共に実行した結果が以下です。prstat コマンドではロック待ちをしていることが明らかに見て取れましたが、plockstat コマンドではロックの競合についての情報は一切出力されていません。 # plockstat -Cv ./cv_test plockstat: tracing enabled for pid 19839 done done plockstat: pid 19839 has exited 条件変数を調査する DTrace スクリプトplockstat コマンドの代わりに以下の様な DTrace スクリプトを作成すれば条件変数を捕捉することが可能です。DTrace の pid プロバイダを使用して pthread_cond_wait() 関数の出入りを監視しています。同様に pthread_cond_timedwait() や pthread_cond_reltimedwait_np() についてスクリプトを作成すれば、汎用的に条件変数を監視することが可能です。 #!/usr/sbin/dtrace -s pid$target::pthread_cond_wait:entry { self->start = timestamp; self->addr = arg0; } pid$target::pthread_cond_wait:return /self->start/ { @time[tid,self->addr] = sum(timestamp - self->start); @cnt[tid,self->addr] = count(); self->start = 0; } END { printf("¥n"); printf("¥n"); printf("tid¥tcv address¥ttime(nsec)¥n"); printa("%d¥t%p¥t¥t%@u¥n", @time); printf("¥n"); printf("tid¥tcv address¥tcount¥n"); printa("%d¥t%p¥t¥t%@u¥n", @cnt); } DTrace スクリプトの実行結果上記スクリプトを cv.d という名前で保存し、実行権限を付けて、以下の様に実行して下さい。結果を見ると、tid 2 のスレッドの time(nsec) が 10000060220 (=> 10 sec)、tid 3 のスレッドの time(nsec) が 10000693754 (=> 10 sec) なので、各スレッドがそれぞれ 10 秒程ずつ待たされている事が分かります。また、tid 2, tid 3 のスレッドの count が 1 なので、両スレッドとも 1 回ずつ pthread_cond_wait() で待たされていたことになります。 # chmod +x ./cv.d # ./cv.d -c ./cv_test <-- トレース対象のプログラムは -c オプションで指定します dtrace: script './cv.d' matched 3 probes done done dtrace: pid 19939 has exited CPU ID FUNCTION:NAME 6 2 :END tid cv address time(nsec) <-- pthread_cond_wait() で待った時間を条件変数とスレッド毎に集計 2 8060fb8 10000060220 3 8060fb8 10000693754 tid cv address count <-- pthread_cond_wait() で待った回数を条件変数とスレッド毎に集計 2 8060fb8 1 3 8060fb8 1 おわりに以上、DTrace を使用してロックの競合を監視する基本的な方法をご紹介しました。ご覧頂きました通り、plockstat コマンドは DTrace の plockstat プロバイダを全面的に使用して実装されています。また、plockstat コマンドに含まれる DTrace スクリプトは DTrace のスクリプトとして単独でも使用可能であることも見て頂きました。更に、plockstat プロバイダでは捕捉できない条件変数のブロックを DTrace の pid プロバイダを使用したスクリプトで監視する方法もご紹介しました。DTrace にはここで紹介した以外にも proc プロバイダの lwp-create, lwp-start, lwp-exit と言ったプローブや、mutex_owned(), rw_write_held() 等のサブルーチンが備わっており、マルチスレッドプログラムの解析には非常に有用なツールです。是非ご活用下さい。 関連文書 マニュアル plockstat プロバイダのマニュアルhttp://docs.sun.com/app/docs/doc/819-0395/chp-plockstathttp://docs.sun.com/app/docs/doc/817-6223/chp-plockstat 『マルチスレッドのプログラミング』http://docs.sun.com/app/docs/doc/819-0390http://docs.sun.com/app/docs/doc/801-6659 (古い版) ソースコード plockstat コマンドのソースコードhttp://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/plockstat/plockstat.c 61-351 行目が DTrace のスクリプトになっています plockstat プロバイダのソースコードhttp://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/plockstat.dhttp://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/synch.c "DTRACE_PROBE1(plockstat, mutex__block, mp)" と "DTRACE_PROBE2(plockstat, mutex__blocked, mp, X)" が mutex ロックの競合をトレースしている箇所です DTrace の解説『Solaris 動的トレースガイド』『DTrace ユーザーガイド』 セミナー資料http://mediacast.sun.com/users/katohisa_824/media/HotTopics_3.pdfhttp://mediacast.sun.com/users/hiroa/media/dtrace-20070727.pdf

はじめに 今回は DTrace を使用してロックの競合を調査する初歩的な手順をご紹介したいと思います。DTrace には豊富なプローブが用意されていますので、アイデアさえあれば無限にスクリプトを作成することが可能です。その全てを解説することは難しいですが、DTrace を使ってマルチスレッドプログラムの動きを調べる際の基礎となるスクリプトを幾つかご紹介したいと思います。 plockstat...

Sun

plockstat コマンドでロックの競合を調べる

はじめに今回は Solaris の plockstat(1M) コマンドを使ってユーザプロセスのロックの競合を解析する方法をご紹介したいと思います。大規模 SMP マシンや CMT マシンで長く運用されて来た歴史柄、Solaris は CPU スケーラビリティに非常に気を使っている OS です。カーネルサービスがスケールするだけでなく、ユーザプロセスの処理の並列度が十分に上がらない場合の分析ツールも揃っています。今回紹介する plockstat もそういったツールの一つで、プロセス内のロックを解析する為のコマンドです。plockstat コマンドを使うことで、プロセス内のロックの取得と競合の回数や原因を調査する事が可能です。plockstat の 'p' はプロセスの 'p' なので私は「ぴーろっくすたっと」と読んでいますが、'p' が付かない lockstat というコマンドもあり、こちらはカーネル内のロックを観測するコマンドです。どちらもベンチマークやトラブルシューティングでは非常に良く使用するコマンドですので、是非ご活用頂ければと思います。 plockstat コマンドについてplockstat コマンドを使用すると、プロセス内のロックの『取得』と『競合』の発生を監視できます。ロックの取得では、1) 取得されたロックのアドレス、2) プログラムのどの部分からロックが取得されたか、3) そのロックが取得された回数、4) そのロックが解放されるまでの平均時間、を見る事が出来ます。一方ロックの競合は、1) 競合が発生しているロックのアドレス、2) プログラムのどの部分がロックの競合を発生させているか、3) そのロックで何回競合が発生したか、4) そのロックでブロックされていた平均時間、を見る事が出来ます。特にロックの競合(あるスレッドが保持しているロックを別のスレッドが取得しようとすること)はプログラムの実行性能に直結する、とても重要な要素です。その為、今回の記事ではロックの競合に重点を置いて見て行きたいと思います。なお、plockstat コマンドで観察できるロックの種類は mutex ロックと reader/writer ロックです。ロックの競合は『コンテンション』と呼ばれる場合もあります。ロックの競合が発生して待たされている状態を『ロック待ち』と呼んだり、『(スレッドがロックで)ブロックされている』と表現する事があります。 plockstat コマンドの使い方 plockstat コマンドを使用する前にplockstat はプロセス内のロックを観察するコマンドです。plockstat コマンドを使用する前にどのプロセスでロックの競合が発生しているかを確認しておく必要があります。ロックの競合が発生しているプロセスは prstat(1M) コマンドで探す事が出来ます。prstat コマンドには "-mL 1" オプションを付けて実行して下さい。"-m" オプションがロック待ちを検出する為のオプションです。prstat コマンドの出力の "LCK" のカラムがロックの競合で待たされている時間で、単位は % です。スレッド数やアプリケーションの実装にもよりますが、この値が定常的に高い値を示していたらロックの競合を気にした方が良いかもしれません。LCK が高くなっているプロセスを見つけたら、プロセス名とプロセス ID を調べてください。LCK の値が高くなっている行の "PROCESS" が該当プロセスのプロセス名、"PID" がプロセス ID、"LWPID" がスレッド ID です。以下は prstat コマンドを実行した例です。ここでは "general" というプロセスのスレッド ID 2 番から 9 番のスレッドで約 50% のロック待ちが発生しています。 # prstat -mL 1 PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID 20904 root 48 4.0 0.0 0.0 0.0 47 0.0 1.1 3K 6 7K 0 general/6 20904 root 45 3.8 0.0 0.0 0.0 50 0.0 1.1 3K 20 7K 0 general/5 20904 root 45 3.9 0.0 0.0 0.0 50 0.0 1.2 3K 28 7K 0 general/3 20904 root 45 3.8 0.0 0.0 0.0 50 0.0 1.2 3K 32 7K 0 general/7 20904 root 45 3.8 0.0 0.0 0.0 51 0.0 1.2 3K 18 7K 0 general/2 20904 root 44 3.8 0.0 0.0 0.0 51 0.0 1.2 3K 12 6K 0 general/8 20904 root 44 3.7 0.0 0.0 0.0 51 0.0 1.2 3K 11 7K 0 general/4 20904 root 44 3.8 0.0 0.0 0.0 51 0.0 1.2 3K 12 7K 0 general/9 20903 root 0.1 0.2 0.0 0.0 0.0 0.0 100 0.0 52 0 365 0 prstat/1prstat コマンドを実行しても "LCK" が出ていない場合はプロセスのロックの競合は問題ない可能性があります。他に問題が無いか検討してみてください。例えばカーネル内のロックが問題である場合は lockstat コマンドを試してみて下さい。また、"LCK" が出ていてもロックが最優先の課題では無い場合もあります。例えば vmstat コマンドで CPU の id が 0 の場合はたとえロックの競合を解消できたとしてもこれ以上は性能が上がらないかもしれません。その場合は CPU を追加する等の処置が必要です。どんな症状の時にロックが問題であるかの判別手順は、別の機会に改めてご紹介したいと思います。 一般的な使い方plockstat コマンドの基本的な使い方は "plockstat -Cve 5 -x bufsize=10k -x aggsize=2m -p <PID>" です。-C オプションはロックの競合の発生を調べる為の基本オプションです。-v オプションは verbose オプションで、トレースの開始を出力する為に付けています。-e <SEC> で plockstat コマンドを実行する時間を指定します。"-e 5" と指定すると 5 秒間計測します。計測が終わると plockstat コマンドは終了しますが、測定対象のプロセスはそのまま稼働を続けます。-e オプションを付け無い場合は、プログラムが終了するまでトレースを続けます。-x bufsize=<SIZE> -x aggsize=<SIZE> でコマンドの内部バッファを増やしています。このオプションが無くても問題の無いことが多いですが、取得する統計情報の量が大き過ぎて溢れてしまうことを予防する為に付けています。-p <PID> で解析対象のプロセスを指定します。<PID> には解析したいプロセスのプロセス ID を指定します。 # plockstat -Cve 5 -x bufsize=10k -x aggsize=2m -p <PID> ... -C は競合を調査 ... -v は冗長出力 ... -e <SEC> は plockstat コマンドの実行時間 ... -x bufsize=<SIZE> -x aggsize=<SIZE> は内部バッファの拡大 ... -p <PID> は調査対象のプロセスを指定 ロック発生時のスタックフレームを記録するplockstat コマンドではロックが発生した際のスタックフレームを記録する事も出来ます。ロックに至るまでの関数コールの履歴を見ることで、ロックの発生原因を詳細に特定することが可能になります。スタックフレームの保存には -s <DEPTH> オプションを付けます。 plockstat -Cvs 5 -p <PID> ... -s <DEPTH> で保存するスタックの深さを指定 出力行数を制限したい場合は出力行数が多すぎてログが見にくい場合は -n オプションを付けてください。 # plockstat -Cve 5 -n 10 -p <PID> ... -n オプションで出力する行数を制限 プログラム実行時に plockstat コマンドを使用するplockstat コマンドの引数にプログラムを指定する事も出来ます。実行時間が短いプログラムや、プログラム開始時のロックを観測したい場合に便利です。<COMMAND> には調査したいコマンドを指定します。 # plockstat -Cv -x bufsize=10k -x aggsize=2m <COMMAND> ... コマンドの最後にプログラム名を指定すると、そのプログラムを実行 ロックの取得を観測するロックの競合ではなくロックの取得を監視したい場合は -H オプションを付けます。ロックの取得は競合に比べて発生頻度が高いため、plockstat コマンドの実行負荷が高くなる事があり、それがプログラムの実行に影響を与えてしまう事があります。注意して使用してください。 # plockstat -Hve 5 -p <PID> ... -H オプションでロックの『取得』を観測 全ての情報を一度に取得したい場合は…ロックの競合と取得の両方を監視したい場合は -A オプションを付けます。-A オプションは -H オプション以上に実行負荷が高いので注意して使用してください。 # plockstat -Ave 5 -p <PID> ... -A オプションでロックの『取得』と『競合』の両方を観測 plockstat コマンドの使用例 その1実際に plockstat コマンドを使用する例をテスト用のプログラムを使ってご覧頂きます。 mutex ロックのテストプログラム以下のテストプログラムでは main() 関数を実行しているスレッドが mutex ロックを保持した状態で 10 秒間休眠し、それ以外のスレッドはその間ブロックされます。これが競合が発生している状態です。ロックの競合は main() のスレッドが停止している間 10 秒ほど続きます。main() のスレッドが mutex ロックを解放すると、ロックの競合は解消され、その他のスレッドがロックを取得します。各スレッドは "done" というメッセージを出力してプログラムは終了します。mutex を保持しながら sleep() したり、エラー処理を省いたりしておりますが、plockstat コマンドのテスト用に分かり易さを優先しました。ご了承下さい。 /\* \* mutex_test.c : a test program for plockstat. \* compile : # cc mutex_test.c -o mutex_test \*/ #include <stdio.h> #include <unistd.h> #include <pthread.h> void \*func(); pthread_mutex_t mp; int main() { pthread_t tid1, tid2, tid3; pthread_mutex_init(&mp, NULL); pthread_mutex_lock(&mp); pthread_create(&tid1, NULL, func, NULL); pthread_create(&tid2, NULL, func, NULL); pthread_create(&tid3, NULL, func, NULL); sleep(10); /\* you should not do this. \*/ pthread_mutex_unlock(&mp); pthread_join(tid1, NULL); pthread_join(tid2, NULL); pthread_join(tid3, NULL); pthread_mutex_destroy(&mp); exit(0); } void \*func() { pthread_mutex_lock(&mp); puts("done"); pthread_mutex_unlock(&mp); pthread_exit(0); } コンパイル上記のテストプログラムを mutex_test.c というファイル名で保存し、以下の様にコンパイルして下さい。 # gcc mutex_test.c -o mutex_test plockstat コマンドの実行次の様に plockstat コマンドにテストプログラムを渡してください。 # plockstat -Cv ./mutex_test 実行結果とその見方plockstat コマンドの実行結果は以下の様になります。一番最後の行が一番重要な行です。左から、ロックの競合が発生した回数 (Count)、競合が発生した時間の平均 (nsec)、競合したロックの名前またはアドレス (Lock)、ロックの競合が発生した関数 (Caller) を示しています。下記の例では mutex_test の実行中にロックの競合は 3 回発生しています。競合が発生してから解消されるまでの時間は平均 10 秒 (10000255945 nsec) で、競合が発生したロックは mutex_test プログラムの "mp" という変数、競合を発生させた関数は mutex_test プログラムの func() です。最後の +0x13 は func() 関数のエントリポイントから mutex_lock() までのオフセットです。以上、プログラムに記述した通りの出力が出ている事が分かります。 # plockstat -Cv ./mutex_test plockstat: tracing enabled for pid 19830 <-- 冗長出力オプションによる出力 done <-- mutex_test プログラムによる出力 done <-- mutex_test プログラムによる出力 done <-- mutex_test プログラムによる出力 plockstat: pid 19830 has exited Mutex block Count nsec Lock Caller ------------------------------------------------------------------------------- 3 10000255945 mutex_test`mp mutex_test`func+0x13 plockstat コマンドの使用例 その2次にプログラムの並列度に関する古典的な問題のひとつである、メモリ割り当ての並列実行について見てみたいと思います。これはヒープコンテンションとも呼ばれている問題で、Solaris では後述の mtmalloc ライブラリによって既に解決されています。 テストプログラムメモリ割り当てのテストに使用するプログラムは OpenSolaris の配布物から流用します。general.c はマルチスレッドプログラムで並列に malloc() を呼び出すマイクロベンチマークです。まずは以下の様にコンパイルしてください。 # mkdir /var/tmp/malloc # cd /var/tmp/malloc # wget http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libmtmalloc/tests/general.c # gcc general.c -o general prstat コマンドで調査するまずは general プログラムの挙動を調べる為に prstat コマンドを使用します。prstat コマンドの -p オプションにプロセス ID を渡すと、そのプロセスだけの統計情報を見る事が出来ます。ここでは general プログラムのプロセス ID を渡しています。general プログラムは 8 つのスレッドを新たに作成し、それぞれのスレッドが 50% 前後の時間をロック待ちに費やしている事が分かります。 # ./general&; prstat -mLp $! 1 PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID 9838 root 48 4.1 0.0 0.0 0.0 47 0.0 1.1 3K 13 7K 0 general/9 9838 root 46 3.9 0.0 0.0 0.0 49 0.0 1.1 3K 3 7K 0 general/7 9838 root 45 3.9 0.0 0.0 0.0 50 0.0 1.2 3K 17 7K 0 general/2 9838 root 45 3.9 0.0 0.0 0.0 50 0.0 1.2 3K 9 7K 0 general/8 9838 root 45 3.9 0.0 0.0 0.0 50 0.0 1.2 3K 8 7K 0 general/6 9838 root 45 3.8 0.0 0.0 0.0 50 0.0 1.1 3K 6 7K 0 general/4 9838 root 43 3.7 0.0 0.0 0.0 52 0.0 1.2 3K 6 7K 0 general/5 9838 root 42 3.7 0.0 0.0 0.0 54 0.0 1.2 3K 9 6K 0 general/3 9838 root 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 0 0 0 0 general/1なお、このプログラムを実行したマシンの CPU 数は 8 つで、general プログラム実行中も CPU リソースに空き (CPU の空き = vmstat コマンドの id) がある状態です。 # psrinfo 0on-line since 09/03/2009 17:11:43 1on-line since 09/03/2009 17:11:54 2on-line since 09/03/2009 17:11:54 3on-line since 09/03/2009 17:11:56 4on-line since 09/08/2009 11:20:06 5on-line since 09/08/2009 11:20:06 6on-line since 09/08/2009 11:20:06 7on-line since 09/08/2009 11:20:06 # vmstat 1 kthr memory page disk faults cpu r b w swap free re mf pi po fr de sr s0 s1 s2 s3 in sy cs us sy id 0 0 0 32014452 31721476 7 53 0 1 1 0 1 -0 0 -0 -0 468 568 577 0 0 100 0 0 0 31950536 31614640 20 6030 0 0 0 0 0 0 0 0 0 671 56769 51060 45 5 50 0 0 0 31926584 31590736 0 5955 0 0 0 0 0 0 0 0 0 561 56962 51203 45 5 50 0 0 0 31902764 31566916 0 5977 0 0 0 0 0 0 0 0 0 550 57824 52201 45 5 50 0 0 0 31878908 31543060 0 5943 0 0 0 0 0 0 0 0 0 606 57476 51873 45 5 50 plockstat コマンドで調査する次に、prstat コマンドで見られたロック待ちの原因を plockstat コマンドで調べてみます。plockstat コマンドの出力から Lock のカラムを見てみると libc.so.1 の libc_malloc_lock で競合が発生している事が分かります。中段に "Mutex block" と書かれている様に、これは mutex ロックの競合です。また、 nsec と Count のカラムを見ると、平均 0.001 秒 (1033533 nsec) のロック待ちが約 6 千回発生していることが分かります。これはプロセス全体で 60 秒 (57903 count \* 1033533 nsec = 59844661299 nsec => 60 sec) ほど待たされている計算になります。plockstat コマンドで測定していたのは 10 秒間ですが、スレッドが 9 つありますので、このプロセスの論理的な演算可能時間は 90 秒間です(CPU 数や他のプログラムの処理のことを考えると実質的な演算可能時間はもう少し少なくなります)。この演算可能な 90 秒のうち 60 秒は mutex のロックで待たされていると言うことになります。このプログラムはかなりの時間をロック待ちに費やしていると言って良いでしょう。 # plockstat -Cve 10 ./general plockstat: tracing enabled for pid 9849 0 Mutex block Count nsec Lock Caller ------------------------------------------------------------------------------- 57903 1033533 libc.so.1`libc_malloc_lock general`be_thread+0x70 スタックフレームを観察するロックの原因をもう少し特定するため、plockstat コマンドに -s オプションも付けてスタックフレームを見てみます。右下の "Stack" のカラムを見ると、general の be_thread() 関数のオフセット 0x70 から libc.so.1 の malloc() 関数が呼び出されており、malloc() から mutex_lock() が呼び出されている事が分かります。このロック待ちは malloc() 関数が原因であることが分かります。これがヒープコンテンションが発生している状態です。 # plockstat -Cve 10 -s 5 ./general plockstat: tracing enabled for pid 9862 0 Mutex block ------------------------------------------------------------------------------- Count nsec Lock Caller 60065 1434766 libc.so.1`libc_malloc_lock general`be_thread+0x70 nsec ---- Time Distribution --- count Stack 2048 | | 836 libc.so.1`mutex_lock_impl+0x102 4096 |@@@ | 9909 libc.so.1`mutex_lock+0x1a 8192 | | 2316 libc.so.1`malloc+0x29 <-- これ 16384 |@@ | 7215 general`be_thread+0x70 32768 |@@@@@@ | 16034 65536 | | 1837 131072 | | 1223 262144 |@ | 2702 524288 |@ | 4505 1048576 |@ | 3721 2097152 | | 2269 4194304 | | 2193 8388608 |@ | 3411 16777216 | | 1671 33554432 | | 219 67108864 | | 4 mtmalloc ライブラリこのヒープコンテンションへの対策として、Solaris にはマルチスレッドプログラム用の mtmalloc ライブラリが用意されており、既に様々なアプリケーションで使用されています。mtmalloc の使用方法は、コンパイル時にライブラリをリンクするか、プログラム実行時に LD_PRELOAD で読み込みます。これにより malloc() 関数がマルチスレッドに最適化された malloc() に置き換わります。 mtmalloc を使用して計測先ほどの general プログラムで mtmalloc を使用してみた所、mutex でブロックされる回数が大幅に減少しました。ロック待ちをしていた時間は、34 count \* 1401746 nsec + 1 count \* 15222 nsec = 47674586 => 0.047 秒です。また、Caller のカラムを見ると、先ほどあった libc の malloc() のロックが消えている事が分かります。 # LD_PRELOAD_32=/usr/lib/libmtmalloc.so.1 plockstat -Cv ./general plockstat: tracing enabled for pid 20828 plockstat: pid 20828 has exited Mutex block Count nsec Lock Caller ------------------------------------------------------------------------------- 34 1401746 libc.so.1`__sbrk_lock libmtmalloc.so.1`morecore+0x81 1 15222 0xfefa2138 libmtmalloc.so.1`setup_caches+0x21 mtmalloc で処理性能が大幅にアップmtmalloc を使ったテストでは、元の libc の malloc() をした場合と比べるとプログラムの実行時間も大幅に減少しています。ptime コマンドで計測した所、だいたい 1/10 程度の時間で処理が終了している事が分かります。plockstat コマンドで入手した情報を元にロックの競合を解消することでアプリケーションの高速化を行う事が出来ました。 # ptime ./general real 27.474

はじめに 今回は Solaris の plockstat(1M) コマンドを使ってユーザプロセスのロックの競合を解析する方法をご紹介したいと思います。大規模 SMP マシンや CMT マシンで長く運用されて来た歴史柄、Solaris は CPU スケーラビリティに非常に気を使っている...

Sun

Sun Desktop Access Client (Sun Ray Soft Client)

Sun Ray 1 Ultra-Thin ClientSun Ray は、1999 年 8 月に発表された製品となり、専用ハードウェアとソフトウェアの組み合わせで構成されるシンクライアントシステムとなります。クライアントとなる Sun Ray 端末には何も情報を持たず、サーバ上に全てのデータが存在する仕組みとなっていますので、ネットワークケーブル 1 本を接続するだけでデスクトップ環境を利用することが可能となります。詳細については、下記の製品紹介をご覧ください。http://jp.sun.com/products/desktop/sunray/ついに実現するソフトウェアクライアント専用のハードウェアが必要となる Sun Ray 環境ですが、現在テスト中の Sun Ray Software 5 では、それ以外にソフトウェアでの利用を実現することが可能となる Sun Ray Soft Client が実装されることになりました。Sun Ray Soft Client は、Windows 上で動作するソフトウェアとなりますが、Windows が動作しているマシンであれば、Sun Ray クライアントとなることが可能となります。よくやった。ついにやってくれた。今回は、この Sun Ray Soft Client を紹介したいと思います。Sun Ray Software 5 EA1 の入手Sun Ray Soft Client を利用するには、現在、Early Access として公開(フィードバックを得るためのテストリリース)されている Sun Ray Software 5 EA1 と Solaris 10 SPARC/x86 が動作するシステム(あるいは、Linux) が必要となります。また、Sun Ray Soft Client を利用するには、Sun Ray Software 5 EA1 の機能が必要になるため、既に稼働している Sun Ray サーバを利用することができない点にご注意下さい。下記 URL からソフトウェアおよびドキュメント類をダウンロードすることが可能です。Sun Ray Software 5 Information CenterSun Ray Software 5 EA1 program ※ Sun Ray Software 5 EA1 は、下記のソフトウェアで構成されています。srss_4.2_solaris.zip (Sun Ray Server Software 4.2)setup.exe (Sun Ray Soft Client 1.0)srwc_2.2_solaris.zip (Sun Ray Connector for Windows Operating Systems 2.2)※ srwc_2.2_solaris.zip は、必須ではありません。まずは、これらを入手しインストールをおこないます。Sun Ray Software 5 EA1 のインストールまずは、アーカイブを展開し、管理用 Web インターフェースを利用するために必要な Tomcat をインストールします。ファイルを展開し、所定のディレクトリに配置するだけです。# pwd/var/tmp/install# unzip -q srss_4.2_solaris.zip# cd srss_4.2/Supplemental/Apache_Tomcat/# /usr/sfw/bin/gtar zxvf apache-tomcat-5.5.20.tar.gz -C /opt# cd /opt# ln -s apache-tomcat-5.5.20 apache-tomcatまた、Java SE 6 が必要になります。幸い Sun Ray Server Software 4.2 のアーカイブに同梱されていますので、インストールされていない場合は、別途、インストールをおこなってください。srss_4.2/Supplemental/Java_Runtime_Environment/Solarisjre-6u13-solaris-i586.shjre-6u13-solaris-sparc.sh続いて、Sun Ray Server Software 本体のインストールをおこないます。いくつか質問される箇所がありますので、確認しつつ作業を進めてください。# cd /var/tmp/install/srss_4.2# ./utinstall::Sun Ray Server Software 4.2 not installedSun Ray Data Store 3.1 not installedDo you want to install Sun Ray Server Software 4.2 French Admin GUI (Y/[N]): Do you want to install Sun Ray Server Software 4.2 Japanese Admin GUI (Y/[N]): YDo you want to install Sun Ray Server Software 4.2 Simplified Chinese Admin GUI (Y/[N]): Kiosk Mode 4.2 not installedEnter Java v1.6 (or later) location [/usr/java]: About to carry out the following operations:Install [ Sun Ray Server Software 4.2 ]Install [ Sun Ray Data Store 3.1 ]Install [ Sun Ray Server Software 4.2 Japanese Admin GUI ]Install [ Sun Ray Server Software 4.2 ]Install [ Kiosk Mode 4.2 ]Install [ Kiosk Mode 4.2 localized files ]Install [ data for utslaunch ]Install [ Sun Ray Server Software 4.2 modules for utsunmc ]Continue? ([Y]/N): ::Installation of Sun Ray Server Software has completed.The system must be rebooted in order to complete this installation andbefore starting the Sun Ray Server Software.Please check for errors/warnings in /var/adm/log/utinstall.2009_08_26_17:57:17.log+++ Done.以上、ソフトウェアのインストールは完了となります。Sun Ray Server Software の設定ここでは、Sun Ray サーバとなるマシンおよび Sun Ray Soft Client を動作させるマシンが、192.168.77.0/24 のネットワークに接続される事を前提とします。また、LAN 共有型 (Shared network) と呼ばれる、専用インターターコネクトを利用しない方法で設定をおこないます。今回は、Sun Ray Software を利用することを目的としているため、なるべく簡単にセットアップするための手順を記載しています。192.168.77.0/24 のネットワークに Sun Ray サービスを提供するには、下記のように設定し、Sun Ray サーバとなるマシンに設定された IP アドレスは、192.168.77.51 となります。utadm コマンドにて共有ネットワークを利用する設定をおこないます。# /opt/SUNWut/sbin/utadm -A 192.168.77.0### Configuring /etc/nsswitch.conf### Configuring Service information for Sun Ray Selected values for subnetwork "192.168.77.0" net mask:255.255.255.0 no IP addresses offered auth server list:192.168.77.51 firmware server:192.168.77.51 Accept as is? ([Y]/N): ### Configuring firmware version for Sun RayAll the units served by "macbook" on the 192.168.77.0network interface, running firmware other than version"4.2_17_2009.06.24.11.48" will be upgraded at their next power-on.### Configuring Sun Ray Logging Functions### Turning on Sun Ray LAN connectionNOTE: utrestart must be run before LAN connections will be allowedDHCP is not currently running, should I start it? ([Y]/N): Y 続いて、サービスを提供するための設定を行います。# /opt/SUNWut/sbin/utconfig Configuration of Sun Ray Core Services SoftwareThis script automates the configuration of the Sun Ray Core Servicessoftware and related software products. Before proceeding, you shouldhave read the Sun Ray Core Services 4.2 Installation Guide and filledout the Configuration Worksheet. This script will prompt you for thevalues you filled out on the Worksheet. For your convenience, defaultvalues (where applicable) are shown in brackets.Continue ([y]/n)? yEnter Sun Ray admin password: Re-enter Sun Ray admin password: Configure Sun Ray Web Administration? ([y]/n)? Enter Apache Tomcat installation directory [/opt/apache-tomcat]: Enter HTTP port number [1660]: Enable secure connections? ([y]/n)? Enter HTTPS port number [1661]: Enter Tomcat process username [utwww]: Enable remote server administration? (y/[n])? yConfigure Sun Ray Kiosk Mode? (y/[n])? Configure this server for a failover group? (y/[n])? About to configure the following software products:Sun Ray Data Store 3.1 Hostname: macbook Sun Ray root entry: o=utdata Sun Ray root name: utdata Sun Ray utdata admin password: (not shown) SRDS 'rootdn': cn=admin,o=utdataSun Ray Web Administration Apache Tomcat installation directory: /opt/apache-tomcat HTTP port number: 1660 HTTPS port number: 1661 Tomcat process username: utwww Remote server administration: EnabledSun Ray Core Services 4.2 Failover group: no Sun Ray Kiosk Mode: noContinue ([y]/n)? ::Creating Sun Ray Core Services Configuration ...Adding user account for 'utwww' (ut admin web server user) ...doneSun Ray Web Administration enabled to start at system boot.Unique "/etc/opt/SUNWut/gmSignature" has been generated.Restarting Sun Ray Data Store ...Stopping Sun Ray Data Store daemon.Sun Ray Data Store daemon stoppedStarting Sun Ray Data Store daemon .Wed Aug 26 18:25 : utdsd startingAdding user admin ...User(s) added successfully!\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*The current policy has been modified. You must restart the authentication manager to activate the changes. \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*Configuration of Sun Ray Core Services has completed. Please checkthe log file, /var/adm/log/utconfig.2009_08_26_19:21:56.log, for errors.再起動することで、Sun Ray Server Software の設定は完了です。Sun Ray Soft Client を利用するための設定 Firefox などの Web ブラウザから下記の URL にアクセスし、管理 GUI を呼び出します。http://SunRayServer_IPaddress:1660/ログインのユーザ名は、admin となり、パスワードは utconfig 実行時に設定したものとなります。ログイン後、ブラウザ内に表示される「詳細」タブ -> 「システムポリシー」タブをクリックします。表示され項目の中に「非カードユーザー」に関する設定項目がありますが、その中にある「Software client Access」の「使用可能」チェックボックスをオンにし、ブラウザ内右上にある「保存」ボタンをクリックすることで設定はが反映されサービスの再起動を促されますので指示に従いサービス再起動を行います。以上で、Sun Ray サーバのセットアップは完了となります。Sun Ray Soft Client のインストールSun Ray Server をインストールしたマシンと同じネットワークに接続した Windows マシン上で作業を行います。 Sun Ray Soft Client は、Windows 用プログラムとなりますので、Windows 環境下で setup.exe を実行する必要がありますが、特に設定など必要なく通常の Windows アプリケーションと同様の扱い方で問題ありません。インストール後は、「スタート」-> プログラム -> Sun Ray から起動することが可能となります。アイコンが味気なく、まだ、開発中であるということを感じさせます。Sun Ray Soft Client を起動すると接続設定用のダイアログが表示されます。まずは、接続だけを目的とするので、下記の項目を設定してください。Connection タブ -> Automatically find server のチェックを外し Connect to Server: に Sun Ray Software を  インストールしたマシンの IP アドレスを入力  します。 Display タブ -> Full Screesn のチェックボックスを外す※ Full Screen において接続を解除する方法  は別途記載します。 上記の設定が完了したら、Connect ボタンをクリックしてください。Sun Ray Server の設定に問題がなければ、接続を開始し、Solaris のログイン画面が表示されます。 Sun Ray Soft Client の利用方法利用については特別な注意事項は特にありませんが、制限事項などについては、付属のユーザガイドを参照してください。Solaris にログインすることで、Solaris 環境を利用可能な他、Sun Ray Windwos connnector を Sun Ray server にインストールしていれば Windows への RDP 接続も可能です。このスクリーンショットでは、Solaris 上で、VirtualBox を利用した Windows 7 Guest の中で Sun Ray Soft Client を起動し、さらにその中で Sun Ray Windows Connector を利用し Windows 7 のリモートデスクトップを表示しています。そして、この環境、実は 1 台の Note PC で実現していたりします。そして、こんなことも可能です・・・6 つの Sun Ray Soft Client が起動しており、それぞれが別々のセッションとして利用可能です。セッションの終了およびフルスクリーンの解除方法  Sun Ray Soft Client で Solaris にログインした状態は、セッションとして管理されます。セッションを終了させる場合は、Solaris 環境からログアウトしてください。セッションを継続させたまま、Sun Ray Soft Client を終了させる場合は、ウィンドウの × ボタンを押してください。Sun Ray の特徴となりますが、サーバ上にセッションを保持できるためクライアントを終了してもログアウトさえしなければ、Sun Ray Soft Client を再起動するだけで即座に前回利用していたセッションを呼び出すことができます。フルスクリーンを解除するには、一度、Sun Ray Soft Client を終了���る必要があります。終了するには、下記のショートカットを入力します。左 Shift + Alt + Control 画面に Disconnect ダイアログが出力されますので、Confirm をクリックすることでクライアントを終了することができます。こちらもセッションは保持されたままとなります。 Sun Ray server のアンインストール # /opt/SUNWut/sbin/utinstall -u # rm -fr /opt/apache-tomcat # rm -fr /opt/apache-tomcat-5.5.20 # pkgrm アンインストール処理完了後、システムを再起動することで Sun Ray Server をアンインストールすることが可能です。最後にSun Ray Soft Client を含む、Sun Ray Software 5 は、現在のところフィードバックを求める Early Access 版となるため、製品としてリリースされるまでは、もう少し時間を要するかと思いますが、ぜひ、この機会に Sun Ray を体験してみてください!

Sun Ray 1 Ultra-Thin Client Sun Ray は、1999 年 8 月に発表された製品となり、専用ハードウェアとソフトウェアの組み合わせで構成されるシンクライアントシステムとなります。クライアントとなる Sun Ray 端末には何も情報を持たず、サーバ上に全てのデータが存在する仕組みとなっていますので、ネットワークケーブル...

Sun

vdbench でディスクの性能を測定する

はじめに今回は vdbench というツールをご紹介したいと思います。vdbench は Henk Vandenbergh さんが作ったストレージのベンチマークツールです。Java と JNI で書かれており Solaris(SPARC and x86) の他 Windows や Linux, VMware, Mac OS X 等の主要なプラットフォームで動作する様です。私は主に Solaris と Linux で使用しています。このツールは元々は Sun の社内用のテストツールでしたが、バージョン 5.00 からはオープンソースとして公開されており、自由にお使い頂くことが可能です。ストレージのベンチマークは他にも bonnie-64, bonnie++, Iometer, IOzone, FileBench, IOR 等がありますが、vdbench には以下の特徴があります。使い勝手が良く動作も安定しておりますので、是非お試し下さい。 複数のプラットフォームで同じテストを実行できます RAW デバイスとファイルシステムに対して I/O 負荷を掛ける事が出来ます マルチスレッド、マルチプロセスを使用して並列に I/O を発生させる事が出来ます Read / Write の比率を変更して I/O を発生させる事が出来ます I/O サイズを変更して I/O を発生させる事が出来ます IOPS を指定して負荷を発生させる事が出来ます シーケンシャルかランダムか、I/O の特性を変更して負荷を生成する事が出来ます 複数のディスクに股がって I/O を発生させる事が出来ます 複数のホストから I/O を発生させる事が出来ます Solaris と Linux では O_SYNC, O_DSYNC, O_RSYNC のフラグを設定してファイルを開く事が出来ます テスト時間やテスト回数、I/O 発生パターン等をシナリオとして定義し、テストを自動化する事が出来ますvdbench は http://blogs.sun.com/henk/entry/vdbench_a_disk_and_tape や http://www.sun.com/storage/white-papers/storage_bottlenecks.pdf でも紹介されておりますので、併せてご覧下さい。 vdbench のダウンロードvdbench のソースコードとバイナリは http://vdbench.sourceforge.net/ からダウンロードできます。2009 年 8 月現在の最新バージョンは 5.01 です。 vdbench のインストール Solaris へのインストールダウンロードしたファイルを展開するだけです # mkdir /var/tmp/vdbench # cp vdbench501.zip /var/tmp/vdbench # cd /var/tmp/vdbench # unzip vdbench501.zip Linux にインストールするCentOS(64bit) の場合は付属の OpenJDK で vdbench を動かす事が出来ます。お使いの Linux に JavaVM が入っていない場合は http://java.sun.com から最新の JDK の 64bit Linux 版をダウンロードしてインストールしてください。 # mkdir /var/tmp/vdbench # cp vdbench501.zip /var/tmp/vdbench # cd /var/tmp/vdbench # unzip vdbench501.zip vdbench の使い方ここでは vdbench の基本的な使用方法を解説します。より詳しい使い方を知りたい方は vdbench のアーカイブに含まれている vdbench.pdf をご覧下さい。 vdbench を動かしてみる動作確認の意味も込めて、早速 vdbench を動かしてみましょう。./vdbench -t を実行して下さい。以下の様な出力が得られれば成功です。 # ./vdbench -t Vdbench distribution: vdbench500 For documentation, see 'vdbench.pdf'. 01:07:59.273 input argument scanned: '-f/tmp/parmfile' 01:07:59.327 Starting slave: /var/tmp/vdbench/vdbench SlaveJvm -m 10.16.67.4 -n localhost-10- 090723-01.07.58.208 -l localhost-0 -p 5570 01:07:59.660 All slaves are now connected 01:08:00.763 Inserted 'rd=File_format_for_sd=sd1' to initialize new file for sd=sd1,lun=/tmp/quick_vdbench_test,size=10485760 01:08:02.003 Starting RD=File_format_for_sd=sd1; I/O rate: 5000; Elapsed=(none); For loops: threads=8 01:08:02.089 All sequential workloads on all slaves are done. 01:08:02.089 This triggers end of run inspite of possibly some non-sequential workloads that are still running. Jul 23, 2009 interval i/o MB/sec bytes read resp resp resp cpu% cpu% rate 1024\*\*2 i/o pct time max stddev sys+usr sys 01:08:03.051 1 9.00 9.00 1048576 0.00 11.178 15.601 5.275 2.7 1.4 01:08:03.057 avg_2-1 0.00 0.00 0 0.00 0.000 0.000 0.000 01:08:04.003 Starting RD=rd1; I/O rate: 100; Elapsed=5; For loops: None Jul 23, 2009 interval i/o MB/sec bytes read resp resp resp cpu% cpu% rate 1024\*\*2 i/o pct time max stddev sys+usr sys 01:08:05.009 1 84.00 0.33 4096 53.57 0.009 0.040 0.005 1.1 0.3 01:08:06.047 2 89.00 0.35 4096 50.56 0.008 0.018 0.003 0.1 0.0 01:08:07.048 3 99.00 0.39 4096 50.51 0.008 0.017 0.003 0.1 0.0 01:08:08.047 4 94.00 0.37 4096 51.06 0.008 0.017 0.003 0.1 0.0 01:08:09.047 5 111.00 0.43 4096 53.15 0.008 0.024 0.003 0.1 0.1 01:08:09.050 avg_2-5 98.25 0.38 4096 51.40 0.008 0.024 0.003 0.1 0.0 01:08:09.357 Slave localhost-0 terminated 01:08:09.409 Vdbench execution completed successfully. Output directory: /var/tmp/vdbench/output vdbench -t は /tmp に負荷を発生させます。テスト結果は output ディレクトリにも出力されます。ウェブブラウザで output/summary.html を開いてみてください。 vdbench コマンドのオプションテストの実行時に付けるオプションは、殆どの場合 "./vdbench -f <CONFIG FILE> -o <OUTPUT DIR>+" で十分です。以下の様にコマンドを実行すると myconf.txt から設定を読み込み、測定を実施し、測定結果を /var/tmp/resultXXX ディレクトリに書き出します。結果が出力されるディレクトリは自動的に作成されます。resultXXX の XXX は最初は空文字、2 回目以降は 000 から 999 までの値が自動的にインクリメントされます。これで同じコマンドを繰り返し実行しても(当分の間は)結果が上書きされずに済みます。 # ./vdbench -f myconf.txt -o /var/tmp/result+vdbench の実行時に以下のオプションを渡すことも可能です。詳細はマニュアルをご覧下さい。 usage: ./vdbench [compare][gui] [-f xxx] [-o xxx] [-e nn] [-i nn] [-j] [-jr] [-v] [-vq] [-s] [-k] [- "parmfile parameters"] '-f xxx': Workload parameter file name(s). Default 'parmfile' in current directory 'gui': Start Vdbench Graphical User Interface '-o xxx': Output directory for reporting. Default 'output' in current directory '-e nn': Override elapsed=seconds. '-i nn': Override interval=seconds. '-v': Activate Data validation. '-vq': Activate Data validation, validate lba and data key (saves cpu) '-j': Activate Data validation with Journaling. '-jr': Recover existing Journal, Validate data and run workload '-s': Simulate execution. Do everything but I/O. '-k': Solaris only: Report kstat statistics on console. 設定ファイルの書き方I/O パターンやテスト時間等の負荷シナリオは設定ファイルに記述します。ここではその記述方法を解説します。 サンプル設定vdbench の設定ファイルの中身は以下の様なテキストです。設定は行単位で記述し、\* で始まる行はコメントです。これをファイル保存し、vdbench -f で読み込ませて実行します。他にも vdbench の配布ファイル中にサンプル設定が幾つか含まれていますのでご参照下さい。設定ファイルは生成したい負荷のシナリオを書き下した物なので、負荷シナリオとも呼ばれます。 Example 1 \*Example 1: Single run, one raw disk \*SD:Storage Definition \*WD:Workload Definition \*RD:Run Definition \* sd=sd1,lun=/dev/rdsk/c0t0d0s0 wd=wd1,sd=sd1,xfersize=4096,rdpct=100 rd=run1,wd=wd1,iorate=100,elapsed=10,interval=1 \*Single raw disk, 100% random read of 4k records at i/o rate of 100 for 10 seconds Example 2 \*Example 2: Single run, two raw disk, two workloads. sd=sd1,lun=/dev/rdsk/c0t0d0s0 sd=sd2,lun=/dev/rdsk/c0t0d1s0 wd=wd1,sd=sd1,xfersize=4k,rdpct=80,skew=40 wd=wd2,sd=sd2,xfersize=8k,rdpct=0 rd=run1,wd=wd\*,iorate=200,elapsed=10,interval=1 \*Two raw disks: sd1 does 80 i/o's per second, read-to-write ratio 4:1, 4k records. sd2 does 120 i/o's per second, 100% write at 8k records. Example 3(Filesystem) fsd=fsd1,anchor=/dir1,depth=2,width=2,files=2,size=128k fwd=fwd1,fsd=fsd1,operation=read,xfersize=4k,fileio=sequential,fileselect=random,threads=2 rd=rd1,fwd=fwd1,fwdrate=max,format=yes,elapsed=10,interval=1 Raw デバイスに負荷を掛ける場合の設定手順vdbench は Raw デバイスにもファイルシステムにも I/O 負荷を掛ける事が出来ますが、まずは Raw デバイスに負荷を掛ける場合の設定ファイルの書き方を解説します。 sd の設定まずは負荷生成対象のディスクの定義を行います。ディスクは sd= で始まる行で定義します。sd は Storage Definition の略で、この行がディスクの定義であることを示しています。設定名は後でこの定義を参照するために付けます。 sd=sd1 です。このパラメータに max を指定するとマシンの性能が許す限りの I/O 操作を実行します。format=yes を設定すると、テスト開始前にファイルとディレクトリを作成します。これを設定しない場合は自分でファイルとディレクトリを作成しておく必要があります。ファイル数やファイルサイズが増えるとファイルの作成に時間が掛かる様になるので、一回目のテストでファイルを生成して、以降はそれを使い回すと良いかもしれません。elapsed= を設定すると、テストの実行時間を指定する事が出来ます。デフォルトは 30 秒です。ファイルシステムはキャッシュの影響が大きいので、ある程度長い時間でテストを行ってください。interval= を設定すると、統計情報の出力間隔を指定する事が出来ます。Solaris と Linux では openflags= を設定すると open() に渡すフラグを指定する事が出来ます。設定できるフラグは o_sync, o_dsync, o_rsync です(ソースファイルの Vdb/OpenFlags.java で確認できます)。データベース等を模したテストをする場合は O_DSYNC を付けると実環境により近付くかもしれません。forsizes= を設定すると複数のファイルサイズのテストを一つの設定で実行する事が出来ます。forsizes=(128k,2m,1g) の様に指定すると、まず 128KB でテストを行い、それが終了したら 2MB のファイルサイズで、最後に 1GB のファイルサイズでテストを行います。forfiles= を設定すると異なるファイル数のテストを順番に実施する事が出来ます。forfiles=(300,500,1000) と指定すると 300 個のファイルのテスト、500 個のファイルのテスト、1000 個のファイルのテストを順番に実行します。ここまでの説明で以下の様な負荷生成シナリオができました。これをファイルに保存し vdbench コマンドの -f オプションでそのファイル名を指定することでこの負荷シナリオを実行する事が出来ます。 fsd=fsd1,anchor=/mnt/test01/,files=10,sizes=1g fwd=fwd1,fsd=fsd1,fileio=sequential,stopafter=1000,fileselect=sequential,xfersizes=8k,operation=write,threads=8 rd=rd1,fwd=fwd1,fwdrate=max,elapsed=600,interval=10,format=yes 注意繰り返しテストを実行する場合は、測定条件を合わせるため、なるべく一度ファイルシステムをアンマウントしてから次のテストを実行する様にしてください。 まとめRaw の設定ファイルでは sd, wd, rd のパラメータを設定しましたが、ファイルシステムの設定ファイルでは fsd, fwd, rd のパラメータを設定します。ファイルシステムキャッシュ等の影響があるので、試験時間は長めに、データ量は実環境になるべく近く、テストする度にマウントし直す様にしてください。 vdbench のパラメータ前項まででご覧頂いた通り、Raw デバイスに負荷を生成する場合は SD(Storage Definition), WD(Workload Definition), RD(Run Definition) を設定する必要があります。ファイルシステムの場合は FSD(Filesystem Storage Definition), FWD(Filesystem Workload Definition), RD(Run Definition) を定義する必要がありました。実際にはそれ以外に General Parameters と HD(Host Definition) というパラメータもあります。全てのパラメータはマニュアルに記載されていますので、ご確認下さい。 テスト結果の見方 Raw の場合出力先に指定したディレクトリに summary.html ができます。これをウェブブラウザで開いてください。14:55:08.000 Starting RD=rd1; I/O rate: Uncontrolled MAX; Elapsed=60; For loops: xfersize=32768 Aug 04, 2009 interval i/o MB/sec bytes read resp resp resp cpu% cpu% rate 1024\*\*2 i/o pct time max stddev sys+usr sys 14:55:18.023 1 9978.40 311.82 32768 0.00 0.798 52.837 1.960 4.5 3.8 14:55:28.011 2 8517.60 266.18 32768 0.00 0.936 26.145 2.138 4.0 3.3 14:55:38.011 3 8661.60 270.68 32768 0.00 0.921 33.382 2.112 4.1 3.3 14:55:48.012 4 7870.60 245.96 32768 0.00 1.013 30.333 2.250 3.6 3.1 14:55:58.010 5 8523.80 266.37 32768 0.00 0.935 87.823 2.317 3.9 3.3 14:56:08.011 6 8365.10 261.41 32768 0.00 0.954 34.503 2.170 3.9 3.2 14:56:08.014 avg_2-6 8387.74 262.12 32768 0.00 0.951 87.823 2.198 3.9 3.2 14:56:09.296 Vdbench execution completed successfully interval の値は統計情報の出力回数です。連番になっており一行出力する度に値が一つずつ増えて行きます。 i/o rate は I/O の回数 (IOPS) です。 MB/sec は I/O スループット (megabytes per second) です。 bytes i/o は I/O サイズ(の平均)です。上の例の場合は xfersize=32768 にしましたので、一回の I/O サイズも 32768 bytes になります。 read pct は Read の割合です。Write Only の時は 0 になります。 resp time はミリ秒単位の平均レスポンス時間です。 resp max はもっとも時間が掛かった処理の処理時間(ミリ秒単位)です。 resp stddev はレスポンス時間の標準偏差(ばらつき度合い)です。 cpu% sys+usr は処理に費やした CPU 時間です。 cpu% sys は OS 側の処理に消費した CPU 時間です。 avg_2-6 は、この行が 2 回目の出力から 6 回目の出力の平均であることを示しています。この行の i/o rate と MB/sec をテスト結果として採用すると良いでしょう。 ほぼ同じ内容が標準出力にも出力されます。そちらを見て頂いても構いません。 ファイルシステムテストの場合出力先に指定したディレクトリに summary.html ができます。これをウェブブラウザで開いてください。以下は summary.html の一部を抜き出したものです。 ... 15:15:15.001 Starting RD=rd1; Elapsed=60; fwdrate=max. For loops: None 15:15:25.025 Interval ....Ops..... ...cpu%... ....read.... ...write.... ..mb/sec.. .xfer. ... 15:15:25.025 rate resp total sys rate resp rate resp read write size ... 15:15:25.025 1 10228 0.5 4.6 4.1 0.0 0.0 10228 0.5 0.0 79.9 8192 ... 15:15:35.011 2 3443.1 2.8 1.2 1.0 0.0 0.0 3443.1 2.8 0.0 26.9 8192 ... 15:15:45.013 3 14297 0.6 3.8 3.2 0.0 0.0 14297 0.6 0.0 111.7 8192 ... 15:15:55.009 4 8678.4 0.9 3.5 3.1 0.0 0.0 8678.4 0.9 0.0 67.8 8192 ... 15:16:05.011 5 5030.4 1.0 2.2 2.0 0.0 0.0 5030.4 1.0 0.0 39.3 8192 ... 15:16:15.009 6 3532.8 3.0 1.8 1.6 0.0 0.0 3532.8 3.0 0.0 27.6 8192 ... 15:16:15.012 avg_2-6 6996.5 1.2 2.5 2.2 0.0 0.0 6996.5 1.2 0.0 54.7 8192 ... 15:16:17.044 Vdbench execution completed successfully Interval は出力行の番号です。出力される度にインクリメントされて行きます。 Ops は I/O 操作に関する統計情報です。Ops の rate は秒間の操作回数、resp は平均レスポンス時間です。 cpu% は CPU 使用率を表しています。total が CPU 使用率で sys はその内のシステム時間です。 read は読み出しに関する統計情報です。rate は毎秒の read 回数、resp は平均レスポンス時間です。 write は書き込みに関する統計情報です。rate は毎秒の write 回数、resp は平均レスポンス時間です。 mb/sec は毎秒のデータ転送量 (megabytes per second) です。read は読み出しの転送量、write は書き込みの転送量です。 xfer size は I/O のサイズです。単位は byte です。 avg_2-6 は、この行が 2 回目の出力から 6 回目の出力の平均であることを示しています。この行の read rate, write rate と mb/sec をテスト結果として採用すると良いでしょう。 ほぼ同じ内容が標準出力にも出力されます。そちらを見て頂いても構いません。 実際に使ってみる Solaris の Raw デバイスのテストvdbench を使って Solaris の Raw デバイスの Sequential Write の性能を測定してみます。設定ファイルは以下の通りです。 # cat conf/test01.conf \* START "test01.conf" : sequential write - 8KB, 16KB, 24KB, 32KB sd=sd1,lun=/dev/rdsk/c0t2d0s2,size=733468426240 wd=wd1,sd=sd1,rdpct=0,seekpct=0 rd=rd1,wd=wd1,iorate=max,elapsed=180,interval=10,forxfersize=(8k,16k,24k,32k) \* END実行ログは以下の通りです。出力が長くなるので、一部重要な部分だけ載せています。 # ./vdbench -f conf/test01 -o /var/tmp/output+ ... Aug 17, 2009 interval i/o MB/sec bytes read resp resp resp cpu% cpu% rate 1024\*\*2 i/o pct time max stddev sys+usr sys ... 16:43:16.030 avg_2-18 37145.06 290.20 8192 0.00 0.212 5.279 0.049 16.7 14.1 ... 16:46:17.017 avg_2-18 16963.02 265.05 16384 0.00 0.468 85.172 1.356 7.7 6.5 ... 16:49:18.013 avg_2-18 11330.82 265.57 24576 0.00 0.703 72.644 1.928 5.2 4.3 ... 16:52:19.015 avg_2-18 8746.64 273.33 32768 0.00 0.911 102.431 2.199 4.1 3.5今回は単純に MB/sec の avg を結果として採用しました。まとめると以下の様になります。 8KB write16KB write24KB write32KB write ----------------------------------------------------------- 290MB/sec265.05MB/sec265.57MB/sec273.33MB/sec Linux の Raw デバイスのテストSolaris の場合と同じ様に Linux でも Sequential Write の性能を測定してみます。Linux では Solaris の /dev/rdsk/... に対応するデバイスファイルを手動で用意する必要があります。 # ls /dev/raw ls: /dev/raw: No such file or directory

はじめに 今回は vdbench というツールをご紹介したいと思います。vdbench は Henk Vandenbergh さんが作ったストレージのベンチマークツールです。Java と JNI で書かれており Solaris(SPARC and x86) の他 Windows や Linux, VMware, Mac OS X 等の主要なプラットフォームで動作する様です。私は主に Solaris...

Sun

CrossbowのVirtual NICとQoS制御を試してみる

以前より前評判の高かった Project Crossbow ですが、OpenSolaris 2009.06の目玉機能として晴れて標準機能となり、誰でも簡単に使えるようになりました。簡単に説明しますと、Project Crossbow とはネットワークの仮想化、つまり仮想インターフェースの作成やネットワーク帯域分割、優先制御といった機能を、可能であれば NICデバイスのハードウェアアシストも利用しながら高速かつ低負荷に実現するものです。これを使えば、例えばサーバー仮想化とあわせて、10本の GbE ケーブルを、お互いの帯域に干渉することなく1本の 10GbEケーブルに統合するなど、管理性を向上させかつ複雑性を排除することが可能です。例えば次のようなシチュエーションにも絶大な効果を発揮するはずです。ある金融サービス会社がオンラインで無料情報提供サービスを開始した。人気は上々だが、有料会員のサービスがスローダウンし、お客が離れていった。。。ホスティングサービス会社がCPUコア数やメモリ量による価格体系を用意したが、どのコースでもネットワーク帯域は使い放題。。。バックアップデータ転送中のため、重要な処理がネットワークタイムアウトしてしまった。。。Virtual NIC の作成では早速試してみましょう。必要なものは、OpenSolaris の動作するPC1台とインターネット接続だけです。まず、まだ PC に OpenSolarisを入れてない方は今すぐインストールしましょう。OpenSolaris はLive CD 形式になっているので、とりあえず手持ちのPCで動作確認した後にボタン一発でインストールできるので、とても手軽です。Crossbow では図のように、仮想インターフェース (VNIC: Virtual NIC)を物理インターフェース経由で直接外部ネットワークに接続することも出来ますし、etherstub という仮想 HUB / Switch を使ってプライベートな Virtual Network を作ることも可能です。今回は、後者の構成でプライベート・ヴァーチャル・ネットワークを作成し、NAT 経由でインターネットと通信できるようにしてみます。手順としては、まず、Virtual Network の要となる etherstub を作成し、その上に Virtual NIC (vnic0, 1, 2) を作成します。vnic0 は Private Address 192.168.10.10 で up させます。# dladm create-etherstub etherstub0 … etherstub を作成## dladm show-linkLINK CLASS MTU STATE OVERbfe0 phys 1500 down --etherstub0 etherstub 9000 unknown --## dladm create-vnic -l etherstub0 vnic0 … etherstub0上にvnic0を作成# dladm create-vnic -l etherstub0 vnic1 … etherstub0上にvnic1,2を作成# dladm create-vnic -l etherstub0 vnic2## dladm show-linkLINK CLASS MTU STATE OVERbfe0 phys 1500 down --etherstub0 etherstub 9000 unknown --vnic0 vnic 9000 up etherstub0vnic1 vnic 9000 up etherstub0vnic2 vnic 9000 up etherstub0## ifconfig vnic0 plumb ... VNIC の設定&リンクアップ# ifconfig vnic0 192.168.10.10 upNAT のセットアップvnic1 と vnic2 が、この後作成するコンテナ(zone)に与えられるのですが、zoneを作る前に、NAT サービスを起動しておきましょう。# routeadm Configuration Current Current Option Configuration System State--------------------------------------------------------------- IPv4 routing enabled enabled IPv6 routing disabled disabled IPv4 forwarding disabled disabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default"Routing daemons: STATE FMRI online svc:/network/routing/ndp:default online svc:/network/routing/route:default disabled svc:/network/routing/rdisc:default disabled svc:/network/routing/legacy-routing:ipv4 disabled svc:/network/routing/legacy-routing:ipv6 disabled svc:/network/routing/ripng:default### routeadm -u -e ipv4-forwarding … ipv4-fowardingを活性化# routeadm -u -d ipv4-routing … ipv4-routingを非活性化## routeadm Configuration Current Current Option Configuration System State--------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding enabled enabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default"Routing daemons: STATE FMRI online svc:/network/routing/ndp:default disabled svc:/network/routing/route:default disabled svc:/network/routing/rdisc:default disabled svc:/network/routing/legacy-routing:ipv4 disabled svc:/network/routing/legacy-routing:ipv6 disabled svc:/network/routing/ripng:default### cd /etc/ipf … ipfilter / ipnat の設定## cat ipnat.confmap bfe0 192.168.10.0/24 -> 0/32 portmap tcp/udp automap bfe0 192.168.10.0/24 -> 0/32### svcadm enable network/ipfilter … ipfilterサービスの起動# svcs network/ipfilterSTATE STIME FMRIonline 12:16:34 svc:/network/ipfilter:default### ipnat -lList of active MAP/Redirect filters:map bfe0 192.168.10.0/24 -> 0.0.0.0/32 portmap tcp/udp automap bfe0 192.168.10.0/24 -> 0.0.0.0/32List of active sessions:#これで 192.168.10.0/24 プライベートネットワークからインターネットへ出られるようになりました。Zone と Virtual Network の作成では zone を作りましょう。VNIC を占有するので ip-type は Exclusive IP Zone となります。# zonecfg -z zone1 … zone1を作成 (vnic1をアタッチ)zone1: No such zone configuredUse 'create' to begin configuring a new zone.zonecfg:zone1> createzonecfg:zone1> set zonepath=/export/home/zone1zonecfg:zone1> set autoboot=truezonecfg:zone1> set ip-type=exclusivezonecfg:zone1> add netzonecfg:zone1:net> set physical=vnic1zonecfg:zone1:net> endzonecfg:zone1> verifyzonecfg:zone1> commitzonecfg:zone1> exit## zoneadm -z zone1 verify ... 作成した zone 構成の検証WARNING: /export/home/zone1 does not exist, so it could not be verified.When 'zoneadm install' is run, 'install' will try to create/export/home/zone1, and 'verify' will be tried again,but the 'verify' may fail if:the parent directory of /export/home/zone1 is group- or other-writableor/export/home/zone1 overlaps with any other installed zones.### zoneadm -z zone1 install ... zone1 のインストールWARNING: skipping network interface 'vnic1' which is used in the global zone.A ZFS file system has been created for this zone. Publisher: Using opensolaris.org (http://pkg.opensolaris.org/release/). Image: Preparing at /export/home/zone1/root.Sanity Check: Looking for 'entire' incorporation. Installing: Core System (output follows)...# zoneadm list -iv ... インストールの確認 ID NAME STATUS PATH BRAND IP 0 global running / native shared - zone1 installed /export/home/zone1 ipkg excl## zoneadm -z zone1 boot## zlogin -C zone1 ... Zone の初期設定 Host name: zone1 IP address: 192.168.10.11 System part of a subnet: Yes Netmask: 255.255.255.0 Enable IPv6: No Default Route: Specify one Router IP Address: 192.168.10.10vnic1 を持った zone1 が完成しました。global zone の vnic0 とつながっているか確認してみましょう。zone1# ping 192.168.10.10 … global zoneの vnic0と通信できた192.168.10.10 is alive次に clone 機能を使ってもう1つの zone を作ります。先に zone1 を shutdown しておいてください。# zoneadm list -iv ........ zone1 は停止している ID NAME STATUS PATH BRAND IP 0 global running / native shared - zone1 installed /export/home/zone1 ipkg excl# zonecfg -z zone2 ... zone2 を作成するzone2: No such zone configuredUse 'create' to begin configuring a new zone.zonecfg:zone2> createzonecfg:zone2> set zonepath=/export/home/zone2zonecfg:zone2> set autoboot=truezonecfg:zone2> set ip-type=exclusivezonecfg:zone2> add netzonecfg:zone2:net> set physical=vnic2zonecfg:zone2:net> endzonecfg:zone2> verifyzonecfg:zone2> commitzonecfg:zone2> exit# zoneadm -z zone2 clone zone1 ... zone1 を基に clone を実行sys-unconfig started 2009年07月15日 15時52分03秒rm: /export/home/zone2/root/etc/vfstab.sys-u: No such file or directorysys-unconfig completed Wed Jul 15 15:52:04 2009## zoneadm list -iv ID NAME STATUS PATH BRAND IP 0 global running / native shared - zone1 installed /export/home/zone1 ipkg excl - zone2 installed /export/home/zone2 ipkg exclzone1 と zone2 をそれぞれ起動します。zone2 は初回起動なので、パラメータを与えます。# zoneadm -z zone1 boot# zoneadm -z zone2 boot ... zone2 を起動 Host name: zone2 IP address: 192.168.10.12 System part of a subnet: Yes Netmask: 255.255.255.0 Enable IPv6: No Default Route: Specify one Router IP Address: 192.168.10.10これで Virtual Network が完成しました。ネットワーク構成は次のようになっているはずです。それぞれお互いに接続可能か ping コマンドなどで試してみましょう。global zone vnic0 192.168.10.10zone1 vnic1 192.168.10.11zone2 vnic2 192.168.10.12etherstub に対して snoop コマンドも使えます。# snoop -d etherstub0Flow Control (Network QoS) を設定するProject Crossbow の Flow Control では帯域制御と優先制御が可能ですが、今回は帯域制御により HTTP コンテンツダウンロードの速度を制限してみましょう。global zone 上で Apache2 Web Server を立ち上げ、zone1のクライアントがコンテンツをリクエストします。まず global zone に Apache2 をインストールします。パッケージマネージャを使えば簡単です。\* Apache2 を global zone へインストールする - Package Manager GUI を利用し Apache2.2 をインストール - /etc/apache2/2.2/httpd.conf はデフォルトのまま# svcadm enable apache22 ... Apache2 を起動# svcs apache22STATE STIME FMRIonline 11:15:27 svc:/network/http:apache22DocumentRoot は /var/apache2/2.2/htdocs なので、ここに大きめのファイルを置くこととします。何でも良いのですが、手元にあった OpenSolaris 2009.06 の ISO イメージを使ってみました。次に zone1 へログインし wget をインストールします。パッケージマネージャが外部のサーバへアクセスするので DNS の設定をして置いてください。zone1# pkg install SUNWwget … wgetのインストールDOWNLOAD PKGS FILES XFER (MB)Completed 1/1 41/41 0.60/0.60PHASE ACTIONSInstall Phase 132/132zone1# which wget/usr/bin/wgetできました。とりあえずダウンロードしてみます。zone1# wget http://192.168.10.10/osol-0906-x86.iso ... global zone からデータ取得--11:33:42-- http://192.168.10.10/osol-0906-x86.iso => `osol-0906-x86.iso'Connecting to 192.168.10.10:80... connected.HTTP request sent, awaiting response... 200 OKLength: 709,871,616 (677M) [application/octet-stream]100%[====================================>] 709,871,616 76.01M/s ETA 00:0011:33:51 (73.18 MB/s) - `osol-0906-x86.iso' saved [709871616/709871616]73.18 MB/s ほどの転送速度がでています。ちなみにリアルタイムの I/O statistics を見るには、以下のように dladm コマンドを使います (global zone で実行してください)。(global zone)# dladm show-link -s -i3 vnic0 ... トラフィック監視コマンドLINK IPACKETS RBYTES IERRORS OPACKETS OBYTES OERRORSvnic0 127454 7726611 0 182076 1469324223 0vnic0 0 0 0 0 0 0vnic0 0 0 0 0 0 0vnic0 0 0 0 0 0 0vnic0 8 816 0 16 1248 0vnic0 5339 289972 0 9863 81142533 0vnic0 15542 841460 0 29119 239992394 0vnic0 15484 837928 0 29291 241410706 0vnic0 9836 532824 0 18448 152009568 0vnic0 0 0 0 0 0 0vnic0 0 0 0 0 0 0では、vnic0 に http port 番号で帯域制限をかけてみましょう。(global zone)(vnic0_httpflow の作成)# flowadm add-flow -l vnic0 -a transport=tcp,local_port=80 vnic0_httpflow# flowadm show-flowFLOW LINK IPADDR PROTO PORT DSFLDvnic0_httpflow vnic0 -- tcp 80 --(flow に帯域制限を設定)# flowadm set-flowprop -p maxbw=100 vnic0_httpflow## flowadm show-flowpropFLOW PROPERTY VALUE DEFAULT POSSIBLEvnic0_httpflow maxbw 100 -- 100vnic0_httpflow priority -- --もう一度 wget でダウンロードしてみます。(zone1)zone1# wget http://192.168.10.10/osol-0906-x86.iso--12:15:53-- http://192.168.10.10/osol-0906-x86.iso => `osol-0906-x86.iso.1'Connecting to 192.168.10.10:80... connected.HTTP request sent, awaiting response... 200 OKLength: 709,871,616 (677M) [application/octet-stream]100%[====================================>] 709,871,616 12.41M/s ETA 00:0012:16:47 (12.47 MB/s) - `osol-0906-x86.iso.1' saved [709871616/709871616]確かに 12.47 MB/s (100Mbps) に帯域制限されています。ではもう一度、今度は remote_ip で帯域制限を掛けてみます。zone1(192.168.10.11) からのパケットを flow として切り出し、この帯域を50Mbpsに制限します。(global zone)# flowadm add-flow -l vnic0 -a remote_ip=192.168.10.11 zone1flow (zone1 の IP-address は 192.168.10.11)# flowadm show-flowFLOW LINK IPADDR PROTO PORT DSFLDzone1flow vnic0 RMT:192.168.10.11/32 -- -- --# flowadm set-flowprop -p maxbw=50 zone1flow# flowadm show-flowpropFLOW PROPERTY VALUE DEFAULT POSSIBLEzone1flow maxbw 50 -- 50zone1flow priority -- --zone1 にて wget を実行します。zone1# wget http://192.168.10.10/osol-0906-x86.iso--12:42:32-- http://192.168.10.10/osol-0906-x86.iso => `osol-0906-x86.iso.3'Connecting to 192.168.10.10:80... connected.HTTP request sent, awaiting response... 200 OKLength: 709,871,616 (677M) [application/octet-stream]100%[====================================>] 709,871,616 5.96M/s ETA 00:0012:44:50 (4.92 MB/s) - `osol-0906-x86.iso.3' saved [709871616/709871616]4.92 MB/s (50Mbps) に帯域制限されています。この時の I/O statistics は次の通りです。(global zone でtrafficを確認)# dladm show-link -s -i3 vnic0LINK IPACKETS RBYTES IERRORS OPACKETS OBYTES OERRORSvnic0 315631 18038505 0 541417 4421741359 0vnic0 0 0 0 0 0 0vnic0 0 0 0 0 0 0vnic0 0 0 0 0 0 0vnic0 0 0 0 0 0 0vnic0 0 0 0 0 0 0vnic0 835 47092 0 1625 13252705 0vnic0 1036 57864 0 2035 16657730 0vnic0 935 52282 0 1821 14901278 0vnic0 1012 56712 0 1969 16113494 0vnic0 1064 59392 0 2075 16995762 0vnic0 1004 56136 0 1958 16030980 0vnic0 985 54982 0 1924 15742424 0vnic0 899 50338 0 1751 14332250 0vnic0 959 53450 0 1882 15404284 0....以上、いかがだったでしょうか?Crossbow / Zone 共に高機能かつ軽量な最強コンビです。仮想化統合の定番として是非ご活用ください。

以前より前評判の高かった Project Crossbow ですが、OpenSolaris 2009.06 の目玉機能として晴れて標準機能となり、誰でも簡単に使えるようになりま した。簡単に説明しますと、Project Crossbow とはネットワークの仮想化、 つまり仮想インターフェースの作成やネットワーク帯域分割、優先制御といった機能を、可能であれば...

Goods

Sunグッズ紹介(22)

Sun のロゴ入りグッズ紹介の第二十二弾です。・Sun ロゴ入り腕時計 - Open Source バージョン 文字盤に Duke をあしらったおしゃれな時計です。 ブロック型のケースもセンスがよく、使わないで飾っておきたくなってしまいます。・Sun ロゴ入りキティちゃん人形  コードネーム "Star Kitty" の名前で知られた Sun Fire 12K 発表時に作成された懐かしい Goods です。サンロゴの服を着たキティーちゃんはとてもレアな一品です。・Sun ロゴ入りボールペン - Sun StorageTek 6000 シリーズ グリップの部分が布製になっており、ホールド感のよいボールペンです。・Sun ロゴ入りトートバッグ 紺色の丈夫な生地にサンのロゴが映えます。エコバックとしても使えます。・SUN TECH DAYS 2008 ネームタグ 2008 年に開催した SUN TECH DAYS の記念タグです。

Sun のロゴ入りグッズ紹介の第二十二弾です。 ・Sun ロゴ入り腕時計 - Open Source バージョン  文字盤に Duke をあしらったおしゃれな時計です。  ブロック型のケースもセンスがよく、使わないで飾っておきたくなってしまいます。 ・Sun ロゴ入りキティちゃん人形  コードネーム "Star Kitty" の名前で知られた Sun Fire 12K 発表時に作成された懐かしい Go...

Sun

Solaris Cryptographic Framework を GlassFish から利用する方法

今回のブログでは、GlassFish アプリケーションサーバの HTTP(SSL) リスナーにて、UltraSPARC T1/T2 Crypto Accelerator を利用する設定をまとめます。今回使用するアプリケーションサーバは、Sun GlassFish Enterprise Server v2.1利用するバイナリは、Sun GlassFish Enterprise Server v2.1 with HADB for Solaris SPARC, Multi-languagesges_ee-2_1-solaris-sparc-ml.bin になります。まずは、GlassFish のインストールを行いましょう。 # ./sges_ee-2_1-solaris-sparc-ml.bin -console -savestate /var/tmp/sges_ee-savestate※コンソールログ※savestate ファイルインストールが終了したら GlassFish を起動します。 # /opt/SUNWappserver/bin/asadmin start-domain --user admin domain1Solaris Cryptographic Framework (SCF) を構成するSolaris Cryptographic Framework (SCF) ソフトウェアトークンには非公開情報が含まれているため、pktool(1) コマンドを使用してトークンにパスワードを設定します。このコマンドは、アプリケーション所有者 (今回は、GlassFish を rootとして実行するので、root ユーザ) としてシステムにログインすることで、ユーザーのデフォルトキーストアを初期化します。SCF ソフトウェアトークンのピンを設定する手順pktool setpin コマンドを実行すると、$HOME/.sunw/pkcs11_softtoken/ ディレクトリ内のソフトウェアトークンデータストアが初期化されます。これらのファイルは、その内容を保護するために、所有者だけがアクセスできるように作成されます。つまり、ユーザーが妥当なデータストアにアクセスできるように、GlassFish を実行しているのと同じ root ユーザーとして初期化を実行する必要があります。1. root ユーザーになります。 # su - root2. id コマンドを実行します。 # id uid=0(root) gid=0(root)3. pktool コマンドを実行します。 # pktool setpin トークンパスフレーズを入力してください: admin 管理パスワードを入力してください> server.http-service.http-listener.http-listener-2.ssl.cert-nickname = s1as server.http-service.http-listener.http-listener-2.ssl.client-auth-enabled = false server.http-service.http-listener.http-listener-2.ssl.ssl2-ciphers = server.http-service.http-listener.http-listener-2.ssl.ssl2-enabled = false server.http-service.http-listener.http-listener-2.ssl.ssl3-enabled = true server.http-service.http-listener.http-listener-2.ssl.ssl3-tls-ciphers = server.http-service.http-listener.http-listener-2.ssl.tls-enabled = true server.http-service.http-listener.http-listener-2.ssl.tls-rollback-enabled = true # 2. 次のコマンドを実行し、内部トークンに含まれる s1as の証明書を PKCS#12 形式のファイルにエクスポートします。 # /opt/SUNWappserver/lib/pk12util -o /tmp/s1as -n s1as -d /opt/SUNWappserver/domains/domain1/config Enter Password or Pin for "NSS Certificate DB":

今回のブログでは、GlassFish アプリケーションサーバの HTTP(SSL) リスナーにて、UltraSPARC T1/T2 Crypto Accelerator を利用する設定を まとめます。 今回使用するアプリケーションサーバは、Sun GlassFish Enterprise Server v2.1 利用するバイナリは、Sun GlassFish Enterprise Server...