Solaris 10 オペレーティング・システムで導入された Solaris Process Rights Management を使用すると、管理者は、アプリケーション機能の実行に必要なだけのシステム・リソースを利用できるように、アプリケーションの動作を制限したり、一部だけを有効にしたりできます。この機能により、システムへの不正なアクセスを排除できるため、欠陥のあるアプリケーションが原因で攻撃を受ける可能性が大幅に減少します。また、ハッカーがアプリケーション・サーバにアクセスしたとしても、操作権限を広めることはできないため、不正なコードを仕込んだり、データを破壊したりする可能性が制限されます。

Process Rights Management は、実行中のプロセスに関連付けられたユーザに関係なく、すべてのプロセスの権限を制限するので、アプリケーションの制御を獲得したハッカーがいたとしても同じように実行権限が制限されます。

典型的な例として Web サーバがあります。UNIX システム上では通常、TCP のポート 80 (Web ポート) に接続するために、Web サーバを root ユーザ（スーパーユーザ）権限で実行する必要があります。このため、Web サーバは攻撃者にとって格好のターゲットになります。ハッカーはよく、バッファ・スタック・オーバーフローなどの攻撃を用いて、root ユーザになり、サーバに対するフルアクセス権を獲得ます。Process Rights Management を使用すれば、ハッカーがシステムのセキュリティを変更したり迂回したりして、重大な、またはプライベートなシステム・リソースにアクセスするのを阻止できます。

別の例として、Solaris Container モデルがあります。革新的な Solaris Container テクノロジを使用すると、1 つの Solaris 10 OS インスタンス内に、セキュリティ保護され障害分離性を備えた何千というコンテナを作成できます。各 Solaris Container は互いに分離されているため、あるコンテナ内のユーザまたはアプリケーションが別のコンテナ内のコンテンツを参照したり、それらにアクセスしたりすることはできません。Process Rights Management を使用したシステムでは、たとえ特権を持つアプリケーションでも、自身の Solaris Container 内のリソースだけにアクセスが制限されます。

Solaris Role Based Access Control (RBAC) ソフトウェアの改良版 (Solaris 10 OS では Solaris User Rights Management ソフトウェアと呼ばれている) を使用すると、管理者は、各プログラムおよびコマンドに対して、ユーザごとに固有のアクセス権を与えることができます。これにより、管理者がミスを犯したり、IT リソースが誤って、または悪意によって利用されたりする可能性が低くなります。これに対して、User Rights Management は集中管理によってコストを削減し、柔軟性を高めます。

つまり、Solaris RBAC ソフトウェアがユーザのアクションを制限するのに対して、Process Rights Management はプロセスの機能を制限します。

Process Rights Management による制限をアプリケーションが認識することはないため、既存の Solaris アプリケーションを変更する必要はありません。開発者は、Process Rights Management によって与えられる権限を明示的に使用するアプリケーションを書くこともできますが、そのようにしなければならないというわけではありません。

管理者は、Solaris 10 OS に含まれている ppriv ユーティリティを使用して、既存のアプリケーションに Process Rights Management の機能を追加できます。ppriv ユーティリティを使用すると、プロセスが必要とする特権を判断し、アプリケーションを変更せずに必要な特権を設定できます。

顧客向けアプリケーションとの互換性を最大限維持するため、アプリケーションはこれまでと同じように動作しますが、特権ポリシーの管理下に置かれます。

Process Rights Management は、Solaris 10 OS の新機能です。Solaris 10 OS に無償で含まれており、デフォルトで有効化され、常に動作しています。

Solaris OS の開発チームは、Linux で実験的に行われた特権モデルのパッチやその他の UNIX が採用している特権モデルを詳細に検討しました。しかし、これらの既存のソリューションでは、既存のファイルシステムを扱うだけの柔軟性を提供できない上、アプリケーションを再コンパイルする必要がありました。また、規模が固定されている（スケーラビリティがない）ため、たとえば、許可される特権の数に上限がありました。また、Solaris Process Rights Management の特権モデルには、Trusted Solaris オペレーティング・システムが提供する実績のある広範な機能を基に開発されたという利点もあります。

Solaris Secure Execution は、Solaris システム上のほとんどすべてのアプリケーション、ドライバ、モジュールの実行可能部分の整合性を検証することで、変更されたコードや無署名のコードの実行を禁止します。

Sun は、ユーザ自身のアプリケーションまたはサードパーティ製のアプリケーションに、アプリケーションを変更せずに署名するためのツールを提供しています。Solaris 10 OS では現在、手動で署名を確認するツールが用意されていますが、今後のリリースで、実行時に自動的に署名を検証する機能の導入を計画しています。この機能は、Solaris 10 だけで使用可能な機能であり、業界でも他に類を見ません。

Solaris Basic Audit and Reporting Tool (BART) を使用すると、システム管理者は、データファイルおよびメタ情報 (ファイルの所有権、サイズなど) の整合性を確認できます。BART は、任意の一時点におけるシステム上のすべてのファイルの整合性を監視するツールを提供することで、Solaris Secure Execution テクノロジを補完します。システム管理者は、簡単なスクリプトを書くだけで、BART を使用して整合性チェックを自動化できます。

Solaris IP Filter ファイアウォールは、ステートフルなパケット・フィルタリングを可能にするソフトウェアです。ネットワーク・アドレス変換 (NAT) 機能を実現するのにも使用できます。IP Filter は、1 つのサーバまたはサーバとクライアントのネットワークを保護します。Solaris 10 OS に含まれている IP Filter テクノロジは、次世代のバージョン 4.x オープンソース IP Filter に基づいています。Solaris の開発中に行われた改良は、このオープンソース版の IP Filter にフィードバックされています。

オープンソース IP Filter は、現在、最も広く使用されているパケット・フィルタリング・ソリューションです。Linux や他の UNIX オペレーティング・システムを稼働しているユーザは、同じ機能を実現するのに、複数のソリューションを使用することを好みません。IP Filter を Solaris OS に統合したのは、そうしたニーズに応えるためです。

Solaris IP Filter ファイアウォールの主な利点は次のとおりです。

• プライベートなコンピュータやネットワークに対する不正アクセスを禁止することで、Solaris のセキュリティを強化します。
• Solaris システムを包含するネットワークの整合性を高めます。
• 安定したインタフェースを使用するように設計されているため、Solaris ソフトウェアのユーザに高いパフォーマンスとすぐれた管理性を提供します。

以下の機能も提供します。

• ネットワーク・アドレス変換 (NAT): I/O パケットが NAT を通過すると、構成ルールに従って、そのパケットの送信元および宛先 IP アドレスが変更され、実際の IP アドレスがマスクされます。
• フィルタリング: 構成ルールに基づいて、ネットワークに送信されてきたパケットを許可または拒否できます。
• アカウンティング: ネットワークに着信したパケットおよびネットワークから送出されたパケットのバイト数を記録するルールを設定することで、統計的な分析が可能になります。

Sun の IP Filter テクノロジは、他のベンダーの製品と以下の点が異なります。

• Solaris サーバ上に配備された IP Filter をフルにサポートします。このサポートは、Solaris サーバがインターネット・アプリケーションをホスティングしているのか、内部サーバのネットワークを保護しているのか、1 つのデスクトップ・クライアントを保護しているのかといった、サーバの用途とは無関係に提供されます。
• IP Filter 機能のパフォーマンスと安定性を向上することで、質の高いユーザ使用感を提供します。
• Sun は、Solaris OS の IP Filter ファイアウォール機能とステートフル・パケット・フィルタリング全般の管理機能を向上させるよう引き続き研究調査を行なっています。

Solaris 10 オペレーティング・システムでは、多くのネットワーク機能が改良されています。これらは、大半のアプリケーションのパフォーマンスを改善するために設計されたものです。また、Sun の顧客ベースにおける多様なニーズに応えるために、多くの主要なプロトコルも実装されています。このリリースでは、ルーティングの効率化とネットワーク可用性の向上が実現され、Voice over IP (VoIP) などの通信アプリケーションをサポートする各種プロトコルに対応しています。また、アジア太平洋地域の市場と米国国防総省 (DoD) にとって重要な最新の IPv6 仕様もサポートされています。

Solaris 10 OS は、以下のプロトコルをサポートしています。

• Berkeley Internet Name Domain (BIND9)
• Solaris Stream Control Transmission Protocol ソフトウェア
• Session Initiation Protocol (SIP)
• Open Shortest Path First (OSPFv2) および Border Gateway Protocol 4 (BGP-4) の各ルーティング・プロトコル
• 仮想 IP ソースアドレス選択 (VIPA)

Solaris 10 の TCP/IP スタックは、シングル CPU システムで高いパフォーマンスを実現すると同時に、複数の CPU がある場合のスケーラビリティも改善されています。非常に多くの CPU がある場合には必要な CPU 間の同期と相互通信に伴うオーバーヘッドが、IP クラシファイアに基づいてロックのない設計を用いた、垂直方向の負荷分散により軽減されています。また、負荷分散、10 ギガビット Ethernet、Remote Direct Memory Access (RDMA) といったこれからのテクノロジを Solaris にシームレスに取り込めるように設計されています。

Solaris 10 オペレーティング・システムでは、ネットワークの第 3 層に冗長性を追加することで、回復性の高いサービスおよび革新的なアプリケーションのための高可用性ネットワーク・ソリューションを実装できるようにしています。第 3 層のマルチパス機能は、システム間のエンドツーエンドの冗長性を実現し、ネットワーク障害 (インターネット上の障害も含む) からの保護機能を強化します。この標準ベースのマルチパス機能は、仮想 IP アドレス選択と Open Shortest Path First-Multipathing (OSPF-MP) の組み合わせによって実装されています。仮想 IP アドレス選択によって、システム管理者は、パケットの IP 送信元アドレスをネットワークごとに指定できます。一方、OSPF-MP は、障害の発生したネットワーク・インタフェースを迂回してトラフィックをルーティングするプロトコルを使用します。これらに加えて、Solaris 10 OS は、OSPFv2 および BGP-4 ルーティング・プロトコルも実装しています。これにより、複雑なルーティング・ポリシーの管理が簡素化されます。

Solaris 10 オペレーティング・システムが現在提供している主要なデータ管理テクノロジは、NFS、UNIX ファイルシステム (UFS)、Solaris Volume Manager などです。今後のアップデートで、Solaris ZFS (Zettabyte File System) もサポートされる予定です。

• Sun が開発し普及させたファイルシステム Network File System (NFS) は、コンピュータ間のファイル共有を実現する業界初の標準ファイルシステムです。Solaris 10 に含まれている NFS v4 では、従来のファイルアクセス機能に加えて、セキュリティ機能の強化、インターネット経由のアクセスとパフォーマンスの改善、異なるプラットフォーム間の相互運用性の向上などが実現されています。
• UNIX File System (UFS) は、汎用の Solaris OS 向けに統合されている Sun 推奨のファイルシステムです。広範なアプリケーションでの利用が可能で、キャッシング可能な小さなファイルを個々のプロセスがランダムにアクセスするという処理形態に合わせて設計されています。UFS は、ソフトウェア開発やネットワーク・サービスなどの負荷を処理するのに最適です。
• Solaris Volume Manager ソフトウェアは、エンタープライズクラスの配備に適した堅牢なディスクおよびストレージ管理ソリューションです。Solaris Volume Manager は、ストレージ要素をボリュームにプールしてから、アプリケーションに割り当てることで、冗長性とフェイルオーバー機能を実現します。これにより、デバイスで障害が発生しても継続的なデータアクセスを提供できます。また、使いやすいインタフェースによってストレージ管理が大幅に簡素化される上、多くの管理作業 (ボリュームの復旧やファイルシステム・サイズの拡張など) をオンラインで実行できるので、ダウンタイムに伴うコストを最小限に抑えることができます。
• 新しい 128 bit ファイルシステムである Solaris ZFS は、セルフヒーリングおよび自己管理機能を提供すると同時に、データが破壊されないように保護します。

Solaris ZFS は、Solaris 10 の新しいファイル・サービスです。Sun の次世代ファイル・ストレージ・ソリューションである Solaris ZFS は、最近の汎用のホストベース・ファイルシステムに求められる要件を満たすように設計されています。Solaris ZFS は、Solaris 10 のアップデート版で提供される予定です。

Solaris ZFS は、UFS および SVM の後継製品となるよう設計されています。既に提供されている UFS および SVM 製品とは共存し、Sun StorageTek QFS および Sun StorageTek SAM-FS 製品を補完する製品として提供される予定です。

Solaris ZFS の主な利点は次のとおりです。

• 管理のしやすさ: 管理モデルが非常に簡単で、大部分は自動化されます。
• セキュリティと整合性: データの整合性は常に維持されます。データは 64 bit のチェックサムで保護されます。
• スケーラビリティ: 128 bit のファイルシステムです。現在使用可能な 32 bit および 64 bit のファイルシステムの 160 億倍の容量を提供できます。

いいえ。現在使用されているほとんどのファイルシステムは、1 つのディスクまたはボリュームしか扱えないため、ボリューム・マネージャが必要です。このため、ファイルシステムとボリューム・マネージャ間のインタフェースが必要となり、ファイルシステムを拡張および縮小したり、スペースを共有したり、実データを移行したりするのが困難です。Solaris ZFS は、ボリューム・マネージャを別途用意しなくて済むように設計されています。具体的には、多くのディスクを 1 つのストレージ・プールに保管し、そのプールを複数のファイルシステム間で共有します。これにより、ストレージ・プールを効率的に使用できます。たとえば、スペースはプール内のファイルシステム間で動的に共有されるため、ファイルシステム自体を拡張または縮小する必要はありません。その上、すべてのファイルシステムで、プールが提供する最大のスループットを実現できます。

Solaris ZFS でのストレージ管理は非常に簡単です。Solaris ZFS の設計では、複雑なストレージ管理の概念の多くが完全に排除されています。たとえば、ストレージ内のスペースはプール内のファイルシステムに動的に割り当てられるため、ストレージをスライス、ボリューム、およびファイルシステムに静的に分割する必要がありません。Solaris ZFS のディスク上の構造は常に整合性がとれているため、正しい手順に従わないシャットダウンが行われたときでもファイルシステム・チェックを実行する必要はありません (ファイルシステムの一貫性を保つためにログをとる必要もありません)。また、Solaris ZFS のコマンドライン・インタフェースを使用することで、実行したい作業を簡単に入力できます。暗号じみたコマンドを覚えたり調べたりする必要はありません。

Solaris ZFS は、copy-on-write のファイルシステムなので、Solaris ZFS のディスク上の構造は常に整合性がとれています。システムが正しい手順に従わずにシャットダウンされた場合でも、再起動時に、Solaris ZFS の一貫性を保つために (たとえば、fsck を実行して) リカバリを実行する必要はありません。すべての操作はトランザクションとして実行されるため、その操作に伴なう変更は操作全体として成功するか失敗するかのどちらかであり、すべてのデータは 64 bit チェックサムで保護されています。データの読み込み時には、アプリケーションが書き込んだデータとアプリケーションが読み戻すデータが一致していることが、チェックサムによって確認されます。ミラー化されたプールの一方でチェックサム・エラーが検出されると、他方のミラーから正しいデータが読み込まれ、破壊されたデータが修復されます。

Solaris ZFS は、128 bit のアドレス空間を使用します。つまり、現在、UFS でサポートされているファイルシステムの 160 億倍を超えるサイズのファイルシステムをサポートできます。

Solaris ZFS は、POSIX (Portable Operating System Interface) ファイル・インタフェースをサポートしているので、アプリケーションを変更する必要はありません。

はい。ただし、グローバルなファイルシステムとして使用することはできません。Solaris ZFS は、クラスタ内の各ノード上でローカルなファイルシステムとして機能します。つまり、Solaris ZFS を使用するのか、Sun Cluster ソフトウェアを使用するのかを選択する必要はありません。

Sun Cluster 製品情報にアクセスしてください。

はい。Solaris ZFS は DTrace に完全に対応しています。Solaris の開発者は、デバッグ・ツールとして、またパフォーマンス向上のために DTrace を使用できます。

現在のところ、Solaris の旧バージョンやその他のオペレーティング・システムに Solaris ZFS を移植する予定はありません。

Solaris 10 は、Linux との相互運用性を維持するために以下の機能を提供しています。

• Solaris と Linux ベースのシステム間のシームレスな相互運用性
• バイナリおよびソースコードの互換性
• Java テクノロジとの高い移植性
• 標準化された Java ベースのネットワーク・サービスのための Sun Java Enterprise System ソフトウェア
• 主要なオープンソース・アプリケーションの統合
• 無償かつ高品質の移植用ツール
• Sun Java Desktop System による共通デスクトップ環境
• LSB (Linux Standard Base) 仕様に準拠した設計

Solaris 上で Linux アプリケーションをネイティブに実行可能にする Solaris Linux Application Environment が、Solaris 10 アップデート版で提供されます。

ユーザからの強い要望に応え、Sun は、この技術の開発範囲を拡大し、一部のユーザと協力して、この機能の最高の設計と配布方法を決定していく予定です。さらに開発が進んだ Solaris Linux Application Environment を基に、2 回目の技術プレビューが今年後半に行われることになっています。

DTrace は、Solaris 10 の包括的な動的トレース・フレームワークです。DTrace は、管理者、開発者、保守担当者が、オペレーティング・システムとユーザ・プログラムの動作に関するあらゆる質問に簡潔に答えられるようにするための強力なインフラを実現します。この強力なツールを使用すれば、システム管理が初心者であるか経験者であるかに関係なく、従来なら解決に何日もかかっていたようなシステムおよびアプリケーションのパフォーマンス低下の問題を、数時間あるいは数分で解決できます。DTrace は、開発、テスト、および本稼働システムで安全に使用できます。

DTrace を使用すると、システム管理者は、一時的なパフォーマンス低下の根本原因を、本稼働システム上で、迅速かつ確実に特定できます。また、開発者は、自分の書いたコード内でパフォーマンス低下の原因となる箇所を、製品の開発/テスト中に特定できます。DTrace から得られた情報を使用してパフォーマンスを最適化すれば、既存のシステム上で、より多くのユーザまたはトランザクションをサポートできるようになります。

DTrace な主な特長な次のとおりです。

• カーネル内だけで 30,000 を超える計測点 (プローブ・ポイント) を持つ完全に計測可能なオペレーティング・システムを提供します。
• アプリケーションとカーネルの統一されたビューを提供します。
• アプリケーションを変更する必要がありません。
• DTrace セッション前、セッション中、またはセッション後に、システムをリブートしたりアプリケーションを再起動する必要がありません。
• ユーザが誤ってシステム・パニックを引き起こす可能性がないため、本稼働システム上でも安全に使用できます。
• 問い合わせに対して正確な応答を返します。
• 事前に用意されている DTrace ルーチンを使用して、DTrace を簡単に使い始めることができます。

DTrace の未使用時には、システムのパフォーマンスが低下したり、その他の動作に悪影響が及ぶことはありません。DTrace の使用中に発生するオーバーヘッドは、プローブ・ポイントの数によって異なりますが、大半の場合、その影響はほとんどありません。

DTrace を使用すると、システム管理者は、システムのプローブを動的に開始できます。プローブの内容は、基本的に、Solaris ソフトウェア全体に分散配置されたプログラム可能なセンサーのようなものです。プローブをオンにすると、DTrace がデータを収集し、集計して、システム管理者にリアルタイムで報告します。

DTrace は、Solaris 10 オペレーティング・システムに含まれています。

いいえ。DTrace は、Solaris 10 の機能の一部なので、別途ライセンス料を支払う必要はありません。

DTrace では、競合製品と違って、イベント・データを収集して処理する必要がないことです。これは、市場に出ている動的トレース・ツールの中で、DTrace だけが持つ利点です。DTrace を使用すると、システム管理者は、発生している問題を本稼働中のシステムにリアルタイムで問い合わせて、問題箇所に関する正確な情報を取得できます。ログファイルも生成されず、後でデータを解析する必要もありません。ユーザは、最初の問い合わせに対する応答を基に次の問い合わせを行い、最終的に、問題の根本原因を特定できます。DTrace を使用して根本原因を突き止めることにより、問題箇所の特定にかかる時間が、数時間から数日短縮されます。

いいえ。DTrace はアプリケーションを動的に計測するため、アプリケーション自体を変更する必要はありません。

予測的セルフヒーリング機能 は、ハードウェアまたはソフトウェアの障害が発生次第、自動的に検出、管理、修復することで、システム障害を未然に防ぎます。エラーが発生次第、自動的に自己修復することを目的として設計されており、システム障害に関する豊富な診断情報をシステム管理者に通知します。つまり、予測的セルフヒーリング機能 の目的は、システムを継続的に稼働すること、すなわち、ハードウェアおよびソフトウェア障害が発生したときの可用性を向上することです。したがって、手動による介入も不要です。一方、DTrace は、システムおよびアプリケーションの動作を把握するために、必要に応じて使用します。システム管理者および開発者は、DTrace から得られた情報を用いて、システムおよびアプリケーションのパフォーマンスを最高の状態にチューニングできます。DTrace は障害を管理するわけではなく、システムで発生していることをユーザに知らせるだけです。パフォーマンスの向上を実現するためのアクションを実行するのは、あくまでユーザです。

DTrace は、特定のプラットフォーム固有の機能には依存しないため、Solaris 10 オペレーティング・システムがサポートされている任意のシステム上で動作します。したがって、SPARC、x64/x86 のいずれのマシン上でも動作します。

いいえ。DTrace に含まれている D プログラミング言語を使用してスクリプトを書き、後で使用したり、ユーザ間で共有したりできます。これにより、DTrace を簡単に使い始めることができます。Sun BigAdmin システム管理者ポータルにはスクリプトのリポジトリが充実しつつあり、ユーザはこれらのスクリプトを無償で利用できます。

もちろんです。たとえば、Sun BigAdmin ポータルで公開されている他のユーザが開発したスクリプトを利用できます。ただ、D 言語を習得することは難しくありません。ANSI C にトレースを容易にするための専用の関数と変数のセットが追加されただけで、構文などはほとんど同じです。

従来、一時的な障害のデバッグには、truss のようなプロセス中心型のツールが使用されてきました。しかし、これらのツールはシステム全体の問題を解析するようには設計されていません。システム全体の問題を解決するツールは、問題発生後の分析を行えるように設計されます。DTrace は、本稼働システム上でリアルタイムにシステムの動作を把握するように設計されています。

DTrace は、Solaris Process Rights Management 機能と密接に統合されています。デフォルトではスーパーユーザだけが DTrace を使用できますが、特定のユーザに対して、特権のセットを定義して与えることもできます。これらの特権を使用すれば、ユーザが所有するプロセスからシステムの監視や相互作用の確認まで、システムをより詳細にユーザに見せることができます。

いいえ。DTrace 自体で、使用可能なプローブ・ポイントをリストできます。また、Solaris Dynamic Tracing Guide に、プローブ・ポイントの優れた使用例が公開されています。興味のある方は、OpenSolaris プログラムで、DTrace のソースコードを入手できます。

まずは、Sun BigAdmin システム管理者ポータルの DTrace セクションを参考にしてください。このセクションには、Solaris Dynamic Tracing Guide、サンプル・スクリプト、DTrace ディスカッション・グループへのリンクがあります。

簡単に言うと、Sun のオペレーティング・システム戦略とは、中期および長期のニーズに応えるさまざまなシステム・ソリューションをユーザに提供することです。そのために、Sun はオペレーティング・システム、ソフトウェア、ハードウェアを密接に統合し、ターゲット市場に最高の利益をもたらすサービス製品をリリースしてきました。こうした「システム全体を考えた」アプローチをとることで、競合他社よりも、費用効果が高く統合されたソリューションを提供しています。必要とされる広範なソリューションを実現するために、Sun は、SPARC アーキテクチャを採用したシステムと x64/x86 ベースのシステムに同じ Solaris ソフトウェアを提供しています。また、x64/x86 ベースのシステム向けにのみ標準の Linux ディストリビューションも提供しています。すべてのプラットフォーム上に、Java テクノロジ、Sun Java Enterprise System、Sun Services が共通基盤として統合されているため、ユーザは、SPARC および x64/x86 アーキテクチャを採用した一連のハードウェア群全体に簡単にアプリケーションを配備し、優れたソフトウェアとサービスでそれらのハードウェアをサポートすることができます。

Solaris 10 は現在、AMD Opteron 、Intel Nocona の各プロセッサ搭載システム、およびその他数百のAthlon および Pentium プロセッサ搭載システム上で動作します。

Solaris 10 は、Sun の x64 および x86 ベースのシステムに加えて、増え続けているサードパーティ製のハードウェア (Dell、Hewlett-Packard、IBM など) もサポートしています。BigAdmin のサイトに、Solaris ハードウェア互換性リストが公開されています。

Solaris 向けサードパーティ製アプリケーション一覧にあります。この一覧は、x64/x86 版 Solaris 市場の拡大に伴い、日々更新されています。

Solaris オペレーティング・システムはすべてのシステムについて 1 つのコードベースから開発されています。つまり、x64/x86 版 Solaris は、SPARC 版 Solaris と同じ特長と機能を備えており、Sun の通常のソフトウェア・ライフサイクル・ポリシーに従っています。そのため、x64/x86 版 Solaris は SPARC 版 Solaris と同じロードマップを共有し、両方のプラットフォームに同じ特長と機能を備えています。ただし、Sun のハイエンド・サーバで提供されている動的再構成機能など、x64/x86 ハードウェアでサポートされていない特定のシステム固有の機能もあります。

Solaris 10 は、高性能を実現するように設計されています。改善された TCP/IP スタックだけでも、すぐに利用できる大半のアプリケーションの性能が Solaris 9 よりも 20 〜 40% 向上しています。Solaris のソフトウェア・エンジニアは、開発プロセスを通して性能の向上を重視してきました。その結果、典型的なシステム機能の実行速度を高めることに成功しました。Network World 誌上で最近行われた Solaris と Linux の性能比較で、Solaris 10 と Red Hat Enterprise Linux 4.0 が同等の性能を実現していることが実証されています。

Sun は、業界標準のベンチマークで多くの世界記録 (2005 年 4 月現在で 20 件) を達成しています。詳細については、Solaris 10 ベンチマークのページを参照してください。

詳細については、Solaris 10 ベンチマークのページを参照してください。

はい。Solaris OS に統合されているオープンソース製品についてはサポートしています。たとえば、BIND、Sendmail、Apache、Tomcat、Samba などです。また、Solaris Software Companion CD には、GNU ツール、squid、GIMP といった、広く使われている多くのオープンソース・パッケージも収録されていますが、これらは、現時点では Sun Services のサポート対象に含まれていません。オープンソース・パッケージのサポートの詳細については、sun.com/solaris/freeware を参照してください。

AMD の Web サイトと Sun の Web サイトを参照してください。

はい。既存の 32 bit アプリケーションと Java プログラムは、64 bit 版 Solaris カーネルで完全にサポートされています。

AMD Opteron 版 Solaris の最適化された 64 bit の実装が製品ラインに加わったことで、リニアな 64 bit のアドレス空間を活用した新しいアプリケーションを開発できるようになります。これは、従来の 32 bit の x86 システムでは不可能だったことです。また、64 bit カーネルは、既存の 32 bit x86 バイナリとの互換性を保証しています。

異なるアーキテクチャ間にまたがるバイナリ互換は維持されないものの、たとえば、SPARC プラットフォーム上で開発されたソースコードを、単純に、x64/x86 ベースのシステム上で再コンパイルして実行することは可能です。Sun は、多くの ISV と協力して、AMD Opteron 版 Solaris 向けに広範なアプリケーションをサポートしています。

2005 年 1 月にリリースされた Sun Studio 10 があります。

2005 年 1 月にリリースされた Sun Studio 10 があります。

いいえ。ドライバは、カーネルのアドレス空間で実行されるため、64 bit カーネルには 64 bit 用のドライバが必要です。AMD Opteron 搭載システム上で 32 bit カーネルを起動した場合は、32 bit のドライバが必要です。

Solaris 10 オペレーティング・システムに統合された機能の 1 つである Solaris Container は、ソフトウェアで定義される柔軟な境界を用いて、ソフトウェア・アプリケーションとソフトウェア・サービスを分離します。仮想化とワークロード管理を行うための画期的なアプローチである Solaris Container を使用すると、多くのプライベートな実行環境を、Solaris OS の 1 つのインスタンス内に作成できます。各実行環境はそれぞれ個別のアイデンティティを持ち、使用しているハードウェアから分離されていますが、専用のシステム上で動作しているかのように振る舞うため、シンプルで整合性に優れた、セキュアな統合を実現します。

重要なことは、Solaris 10 では、Solaris Container が、アプリケーションおよびワークロードの管理に重点をおいていることです。Solaris Container は、CPU やメモリ使用量、IP アドレス、ユーザといった適正な属性を持つ固有の環境においてアプリケーションを分離するツールを提供します。これにより、共有システム上にアプリケーションを簡単に配備できます。

Solaris Container には次のような利点があります。

• 統合の簡素化によるシステム・リソース使用率の向上
• 複数のアプリケーションが 1 つのシステムを共有しながら、互いに完全に分離された環境を実現
• オペレーティング・システム全体を再起動する必要がないため、コンテナの迅速な再起動が可能
• コンテナ管理者が特定のアプリケーション向けにカスタマイズ可能な環境を、システム管理者が作成可能

Solaris Zone とは、セキュリティとアプリケーション障害を封じ込めるための仮想環境です。この環境は、そこで実行されるアプリケーションに合わせてカスタマイズ可能な固有の名前空間を持ちます。Solaris Zone には、固有のノード名、IP アドレス、ユーザ、グループ、ディスク領域、ネットワーク・ポート、ネームサーバなどを与えることができます。Solaris Zone におけるセキュリティと障害の封じ込めとは、ネットワークや共有ディスクを介して他のシステムにアクセスする場合を除いては、セキュリティを侵害したり、あるいは外の環境を見ることさえもできないことを意味します。

Solaris Zone は Solaris Container の一部であり、セキュリティ、アプリケーション障害、名前空間の分離を実現します。Solaris Container に Solaris Zone の機能を追加することで、アプリケーション向けにフルにカスタマイズされた Solaris Container の作成が可能になります。

Solaris Zone 以外のコンポーネントとして、Solaris OS のリソース管理ツールがあります。これらのツールは、CPU サイクル、物理メモリ、ネットワーク帯域幅など、アプリケーションに割り当てられるリソースの量を制御します。また、アプリケーションの使用率を計測する場合にも使用されます。これは、健全性の監視、容量計画、および課金や請求にも使用できます。

Solaris Zone は、Solaris 10 の一部としてすでに使用可能です。

オーバーヘッドは一般に極めて低く、Solaris Container 1 つにつき 1% 未満です。

いいえ。Solaris Container は、複数の Solaris インスタンスにまたがって存在することはできません。

Sun Cluster ソフトウェアは現在、Solaris Container のリソース管理機能をサポートしています。アップデート版では、Solaris Zone もサポートされる予定です。

はい。設定は、コマンドライン・インタフェースから直接、またはスクリプトか cron を使用して、いつでも変更できます。

各 Solaris Container は、異なるシステム上に存在するかのように、ネットワークまたは共有ディスクを介してやり取りします。たとえば、コンテナ同士がネットワークを介してやり取りする場合、システムは、ある Solaris Container が別のコンテナと通信していると認識するため、通信はネットワーク・スタック経由で行われます。Solaris Container 間の通信は、パケットがシステムから出たり、ネットワーク・インタフェース・カードを経由することもないため、非常に高速です。

違いはありません。N1 Grid Container は、Solaris 10 のコンテナ機能の旧名称です。N1 Grid Container から Solaris Container に名称が変更されました。

Trusted Solaris は、ラベリング機能やすべての強力な root の削除など、特定のセキュリティ追加機能によって、極めて厳しいセキュリティ認証レベル B1 に合格しています。これは、Common Criteria では、LSPP (Labeled Security Protection Profile) に相当します。Solaris 10 では、これらの機能がオペレーティング・システムに組み込まれており、その一部が Solaris Container の構築に使用されています。Trusted Solaris の次のリリースは、Solaris Container によって導入された新しい機能を基盤として構築される予定です。

Solaris Container の目的はアプリケーションのための仮想環境を構築することであり、Trusted Solaris の目的は B1/LSPP レベルの認証を受けたオペレーティング・システムを提供することです。

はい。Sun からホワイトペーパーが公開されています。

はい。Solaris Zone と Solaris リソース管理機能は、どちらも Solaris Container の一部であり、一緒に使用できるように設計されています。

Solaris Container は、セキュリティ、アプリケーション障害、名前空間の分離を実現します。つまり、Solaris Container 内で作業を行うと、ネットワークや共有ファイルシステムを介するなどの通常の方法を除いて、コンテナのセキュリティを侵害したり、あるいは Solaris Container の外を見ることさえもできなくなります。また、名前空間の分離によって、Solaris Container は、固有のユーザ、および自身の Solaris Container 内でのみ root 権限を持つ固有の root ユーザを持つことができます。

はい。Solaris Container の root ユーザは、自身の Solaris Container 内に対してのみ変更や構成を行う権限を持ちます。

はい。Solaris Container ごとに異なるタイプのネームサーバからの応答を待機させることもできます。たとえば、ある Solaris Container は NIS サーバからの応答を待機し、別の Container は LDAP サーバからの応答を待機するといった具合です。

telnet、rlogin、ssh といった標準のプロトコルを使用してログインします。基本オペレーティング・システム (グローバルゾーンと呼ばれる) 内からは、zlogin と呼ばれる新しい方法でもログインできます。zlogin を使用すると、Solaris Container に直接ログインできます。

インストール・プロセスに変更はありません。Solaris Container 内でも、通常と同じツールとプロセスが使用できます。ただし、Solaris Container 内では、特定のコンテナにインストールするのか、システム全体にインストールするのかを選択できるようになります。

パッチ適用手順に変更はありません。

はい。ただし、これはデフォルトの動作ではありません。というのは、raw デバイスにアクセスするとセキュリティの分離を侵害することがあるためです。グローバル管理者は、raw デバイスを Solaris Container に個別に追加することができます。

動的システムドメインはハードウェアに基づく機能です。動的システムドメインは、ドメインごとに異なるバージョンのオペレーティング・システムを稼働できる、物理的な分離を実現します。ドメインの数はシステムごとに制限されます。一方、Solaris Container はソフトウェアに基づく機能です。Solaris Container は、それぞれに同じオペレーティング・システムを稼動できる、論理的な分離を実現します。Solaris Container のスケーラビリティは非常に高く、ハードコーディングされた制限はありませんが、OS イメージごとに最大 8000 個のコンテナを作成できます。これは、現在、通常必要とされている数をはるかに上回る数です。

動的システムドメインには、ハードウェアのホットプラグ機能、ドメインごとに異なるバージョンの Solaris オペレーティング・システムを稼働する機能が含まれています。一方、Solaris Container を使用すると、アプリケーションの実行や参照を非常に詳細に管理することができます。独立したオペレーティング・システムで提供されるようなタイプの分離をアプリケーションが必要としている場合は、動的システムドメインを使用するべきです。それ以外の場合は、Solaris Container を使用できます。真の利点は、動的システムドメイン内で Solaris Container を使用すると得られます。

Solaris オペレーティング・システムの予測的セルフヒーリング機能は、ソフトウェアおよびハードウェア障害の発生時に Sun のシステムとサービスの可用性を最大にし、システム管理者のために、より簡単で効率的なエンドツーエンドの使用感を提供します。最初のセルフヒーリング機能である Solaris Fault Manager と Solaris Service Manager も、Solaris 10 OS の一部として利用できます。

予測的セルフヒーリングは、Sun のサーバ・ハードウェアと協調して、次の利点が得られるよう設計されています。

• 予測的な診断と障害が発生したコンポーネントの分離によってシステムとサービスの可用性を向上
• 自動診断とコンポーネントの再起動をミリ秒単位で自動的に実行
• サービス管理モデルの簡素化
• 技術情報へのリンクを活用して問題箇所を迅速かつ容易に修復可能
• ダウンタイムを発生させずに、新しい問題に対する迅速なアップグレードと適応が可能なスケーラブルなアーキテクチャ

ミッションクリティカルなシステムを稼働していて、システム停止のリスクを軽減したい場合、予測的セルフヒーリングによって余分なコストを一切かけずにこれを実現できます。複雑なシステムやミッションクリティカルなアプリケーションを実行する場合も、予測的セルフヒーリングを使用することで、リスクが軽減され、結果としてシステムの稼働率を大幅に向上させることができます。

予測的セルフヒーリングの主な特長は次のとおりです。

• 障害の予測的防止と管理
• 一貫した初期障害診断
• 障害からの迅速なリカバリと復元

予測的セルフヒーリングはハードウェア (CPU、メモリ、I/O) とソフトウェアに起因する障害を管理できます。このテクノロジは、ハードウェア、Solaris オペレーティング・システム、および Solaris Fault Manager インタフェース向けに作成されたソフトウェアと密接に連携して、迅速かつ効率的な障害の診断とリカバリを実現します。

予測的セルフヒーリングの使用に伴うパフォーマンスの低下はほとんどありません。

予測的セルフヒーリングは Solaris 10 に含まれています。

いいえ。予測的セルフヒーリングに対して別途ライセンス料が発生する予定はありません。

Sun の予測的セルフヒーリング技術には、次のような優位性があります。

• HP-UX、Red Hat Linux、および Microsoft Windows と違って、Solaris には履歴データを監視する機能があります。これにより、障害を予測し、予防策を講じることで障害を回避できます。
• Solaris には、エラー履歴を追跡し、根本原因を分析し、障害が発生したサービスやコンポーネントに依存するすべてのコンポーネントをシャットダウンする機能が用意されています。この機能は、HP-UX、Red Hat Linux、および Microsoft Windows の製品が提供する機能よりもはるかに優れています。
• Solaris は、障害が発生したコンポーネントまたは障害が発生しているコンポーネントが及ぼす影響について、価値の高い情報をわかりやすいフォーマットで迅速にシステム管理者に提供します。システム管理者は、この情報を使用して今後実行するアクションを決定できます。競合他社の製品と違って、Solaris は、発生した障害に関する参考情報をさらに提供しています。

予測的セルフヒーリングは、既存のシステムおよびアプリケーションと協調してシステム停止のリスクを軽減し、システムの可用性を向上します。

DTrace では、システム管理者と開発者がアプリケーションとシステム間の動作を理解できるようにし、必要に応じて起動されます。予測的セルフヒーリングでは、ハードウェアおよびソフトウェア障害を管理し、すべてのシステムで自動的に使用できます。

予測的セルフヒーリングは、Sun Fire 3800 から Sun Fire E25K の各サーバ製品の自動診断/リカバリ機能で利用されており、これらのサーバ製品ラインの稼働時間を向上します。このテクノロジは、ハードウェア・コンポーネントでソフト・エラーのしきい値を超えるか障害が発生すると、それを検出して、サービスを中断させずに、そのコンポーネントをサービスから自動的に削除します。また、自動診断／リカバリは有用なサービス情報を Sun にフィードバックし、特に再生システムにおいて今後のエラーの発生を防ぎ、製品の品質を向上します。

Solaris 10 の 予測的セルフヒーリング機能の主な利点は次のとおりです。

• コンポーネント健全性ステータス: 障害の発生したコンポーネントをシステムから自動的に削除して、予定外のダウンタイムを短縮します。
• メッセージングによる自動診断: 詳細なエラー・メッセージによって迅速に問題を解決し、保守時間を短縮します。
• CPU のオフライン化: 潜在的な CPU 障害を検出し、欠陥のある CPU をオフラインにすることで、システムを継続稼働し、アプリケーションの可用性を維持します。
• 自動復元: 動的システムドメインを自動的に復元して、障害の発生したコンポーネントがシステムの可用性に与える影響を軽減します。
• メモリ・ページの待避: 潜在的なメモリ・チップの障害を検出し、疑わしいメモリ・アドレス範囲に存在するデータを自動的に移行して、システムを継続稼働し、アプリケーションの可用性を維持します。

予測的セルフヒーリング機能は、ファームウェア・レベル FW 5.16 の Sun Fire 3800 および Sun Fire 4800 サーバで使用可能です。また、サービス・プロセッサのソフトウェア・レベルが SMS 1.4.1 の Sun Fire E20K および Sun Fire E25K システムでも使用できます。Sun の Opteron 搭載システムでは、Solaris 10 の今後のアップデートで使用可能になる予定です。

Solaris 10 の Support & Services のページを参照してください。自習用の参考資料と追加の Sun Services も利用できます。

Sun は、OSI に承認された Common Development and Distribution License (CDDL) というライセンス条件のもとで、2005 年のより、Solaris オペレーティング・システムのソースコードを公開しています。詳細は、OpenSolaris プログラムのサイト を参照してください。