Solaris Container
サーバおよびアプリケーションの統合

本ガイドは、Solaris Container 技術を使ってアプリケーションを 1 つのサーバに統合する方法を、Solaris 10 OS にあまり慣れていないユーザやシステム管理者、開発者向けに解説したものです。このガイドでは、まず Solaris Container の概略を紹介してから、Solaris Container を使って 2 つの Web サーバ・アプリケーションと 1 つの電子メール・サーバ・アプリケーションを 1 つのサーバに統合する例を説明します。

このガイドでは、統合の過程をコード例や図を使いながら順を追って説明します。したがって、このガイドをお読みになれば、次の手順により Solaris Container を作成できるようになるはずです。

• リソース・プールを作成する
• Solaris Zone を定義する
• Fair Share Scheduler (FSS) を使って CPU 量を割り当てる
• ゾーンをインストールし、ブートする
• ゾーンから raw デバイスへのアクセスを構成する

PDF[514K]

Solaris Container: 概要

Solaris Container (Sun のオペレーティング・システム仮想化手法) は、いくつかの技術が一体となって動作することで、リソース管理の向上や使用している OS から環境を分離することを可能にする技術です。Solaris Container を使用すれば、リソースをさまざまなアプリケーションやサービスに容易に配分できるだけでなく、それらのアプリケーションやサービスが相互に干渉する心配もありません。

このガイドでは、1 つの例として、3 つのアプリケーション (1 つの 電子メール・サーバ・アプリケーションと 2 つの Web サーバ) を 4 つの CPU からなる 1 つのサーバに統合します。

統合の際には、統合システムを共有することになる個々のアプリケーションのニーズを評価することが重要です。この例では、電子メール・サーバ・アプリケーションと Web サーバ・アプリケーションはそれぞれ、あたかも物理的に別々のマシンで実行されているかのように見える分離された環境で動作する必要があります。これを可能にするのが「Solaris Zone」と呼ばれる Solaris Container 技術です。この技術は、同じマシン上に別々の環境を用意し、それぞれのアプリケーションを論理的に分離します。個々のアプリケーションには自身が動作する専用の名前空間を与えられるため、その中の 1 つのアプリケーションから、別のゾーンで動作するアプリケーションを参照したり、監視したり、これに干渉したりすることはできません。図 2 を参照してください。

このガイドで取り上げる例の場合、2 つのタイプのアプリケーションがあります。1 つは、専用の CPU を必要とする電子メール・サーバ、もう 1 つは、複数の CPU を共有することが可能な、より柔軟性のある 2 つの Web サーバです。このような異なるレベルの分離を実現するために、Dynamic Resource Pool と呼ばれる Solaris Container 技術を使用します。この技術を使用すると、CPU リソースを特定のアプリケーションに、専用に割り当てることができます。この例でいえば、電子メール・サーバは専用のリソース・プールを必要としますが、2 つの Web サーバはそれとは別のリソース・プールを共有することができます。この例では、図 3 のように 1 つの CPU を Resource Pool 1 に、3 つの CPU をリソース・プール 2 にそれぞれ割り当てます。

2 つの Web サーバはシステムの残りの CPU を共有しますが、それぞれの Web サーバには、最小限の CPU リソースの割り当てが保証されなければなりません。これを可能にするのが、「Fair Share Scheduler」(FSS) と呼ばれる Solaris Container 技術です。この技術は、それぞれのアプリケーションに CPU リソースを特定の割合で割り当てることができます。つまり、それぞれのアプリケーションには、CPU 全体の中から使用可能な CPU がシェア単位で割り当てられます。図 4 を参照してください。

これらの Solaris Container 技術を新しいサーバに適用することによって、図 5 の環境を構築できます。このシステムには、これで専用の CPU リソースをもつ 1 つの Container と、そのほかの CPU リソースを共有する 2 つの Container の 3 つが含まれます。

Solaris 10 が動作するシステムには必ず、「グローバル・ゾーン」と呼ばれるマスター・ゾーンがあります。このグローバル・ゾーンが、元の (オリジナルの) Solaris OS インスタンスです。このゾーンは、物理ハードウェアにアクセスし、すべてのプロセスを制御するだけでなく、非グローバル・ゾーンと呼ばれる新しいゾーン (そこでアプリケーションが動作する) を作成し制御する権限をもっています。非グローバル・ゾーンはグローバル・ゾーン内で動作するわけではありません。非グローバル・ゾーンとグローバル・ゾーンは並列して動作しますが、グローバル・ゾーンは非グローバル・ゾーンの中を参照してその構成を調べたり、非グローバル・ゾーンを監視したり、制御したりすることができます。

グローバル・ゾーンも、ほかのゾーンと同様に、リソース・プールと関連付けられます。この例では、Resource Pool 2 を割り当てます。したがって、グローバル・ゾーンは CPU リソースを Web サーバと共有します。Fair Share Scheduler を使用すると、グローバル・ゾーンにはデフォルトで 1 シェアが割り当てられます。グローバル・ゾーンを組み込んだ結果、図 5 は図 6 のようになります。

ページ先頭へ

Solaris Container: 例

このセクションでは、上記の電子メールと Web サーバの作成手順を順に説明します。この手順は次のステップからなります。

• 新しいリソース・プールを作成する
• 新しいリソース・プールに対応する電子メール・ゾーンを作成する
• Web サーバ・リソース・プールに対して Fair Share Scheduling を有効にする
• 最初の Web サーバ Container を作成する
• 2 つめの Web サーバ Container を作成する

最後の 2 つの Container を作成する際には、Solaris Zone に対して使用できるほかの構成オプションについてもいくつか説明します。

まず最初に、これらのステップを実行する前のシステムの状態を示します (図 7)。この時点で存在するオブジェクトはグローバル・ゾーンとリソース・プールだけです。グローバル・ゾーンはこの唯一のリソース・プールと関連付けられています。この最初のリソース・プールは「デフォルト・プール」とも呼ばれます。この段階では、システム内にすべての CPU があります。

Solaris OS の場合、「リソース・プール」とは、CPU やメモリなどシステム・リソースのサブセットを所有する論理エンティティを意味します。このようなサブセットを「リソース・セット」と呼びます。現在のところ、Solaris OS のリソース・セットはプロセッサ・セットだけです。リソース・プールは必ずプロセッサ・セットと関連付けられます。したがって、特定のリソース・プールにそれ独自の CPU を割り当てたい場合は、プロセッサ・セットを定義し、そこに含まれるプロセッサの数を指定し、プロセッサ・セットとリソース・プールを関連付ける必要があります。

新たに作成するリソース・プールは、デフォルト・プールのリソースから作成されます。したがって、電子メール・サーバの CPU には、最初にデフォルト・プールに割り当てられた 4 つの CPU の 1 つが使用されます (残りは 3 つ)。リソース・プールの作成や削除は、動作中のシステムに対して動的に行うことができます。ただし、デフォルト・プールには少なくとも 1 つの CPU を残しておかなければなりません。

1. pooladm(1M) コマンドを使ってリソース・プール機能を有効にします。
   
   global# pooladm -e
   
   この例全体を通して global# プロンプトは、このコマンドがグローバル・ゾーンで実行されることを意味します。デフォルトでは、グローバル・ゾーンが現時点で有効なゾーンです。
2. pooladm(1M) コマンドを使って現在の構成をファイルに保存します。
   
   global# pooladm -s
   
   
3. pooladm(1M) コマンドを使って、プールがすでにシステム上にあるか確認します。
   
   global# pooladm

system my_system
   string system.comment
   int system.version 1
   boolean system.bind-default true
   int system.poold.pid 638

   pool pool_default
      int pool.sys_id 0
      boolean pool.active true
      boolean pool.default true
      int pool.importance 1
      string pool.comment
      pset pset_default

    pset pset_default
       int pset.sys_id -1
       boolean pset.default true
       uint pset.min 1
       uint pset.max 65536
       string pset.units population
       uint pset.load 7
       uint pset.size 8
       string pset.comment

       cpu
         int cpu.sys_id 1
         string cpu.comment
         string cpu.status on-line

       cpu
         int cpu.sys_id 0
         string cpu.comment
         string cpu.status on-line

       cpu
         int cpu.sys_id 3
         string cpu.comment
         string cpu.status on-line

       cpu
         int cpu.sys_id 2
         string cpu.comment
         string cpu.status on-line
   
   このシステムには構成済みのプールがまだ存在しないため、プール・エントリとして「pool pool_default」だけが表示されるはずです。
4. poolcfg(1M) コマンドを使って、1 つの CPU をもつプロセッサ・セットを作成します。
   
   global# poolcfg -c 'create pset email-pset (uint pset.min=1; uint pset.max=1)'
   
   このコマンドでは、プール構成を変更して email-pset というプロセッサ・セット (pset) を作成します。 CPU の最小数と最大数はともに 1 です。
5. このプロセッサ・セットのリソース・プールを作成します。
   
   global# poolcfg -c 'create pool email-pool'
   
   
6. プールとプロセッサ・セットをリンクします。電子メール・サーバはこのリソース・プールを使用します。
   
   global# poolcfg -c 'associate pool email-pool (pset email-pset)'


7. 構成を有効にします。
   
   global# pooladm -c
   
   
8. pooladm(1M) コマンドを使ってこのリソース・プールが存在するか確認します。
   
   global# pooladm

system my_system
    string system.comment
    int system.version 1
    boolean system.bind-default true
    int system.poold.pid 638

    pool email-pool
       int pool.sys_id 1
       boolean pool.active true
       boolean pool.default false
       int pool.importance 1
       string pool.comment
       pset email

    pool pool_default
       int pool.sys_id 0
       boolean pool.active true
       boolean pool.default true
       int pool.importance 1
       string pool.comment
       pset pset_default

    pset email-pset
       int pset.sys_id 1
       boolean pset.default false
       uint pset.min 1
       uint pset.max 1
       string pset.units population
       uint pset.load 0
       uint pset.size 1
       string pset.comment

       cpu
          int cpu.sys_id 0
          string cpu.comment
          string cpu.status on-line

pset pset_default
       int pset.sys_id -1
       boolean pset.default true
       uint pset.min 1
       uint pset.max 65536
       string pset.units population
       uint pset.load 7
       uint pset.size 7
       string pset.comment

       cpu
          int cpu.sys_id 1
          string cpu.comment
          string cpu.status on-line

       cpu
          int cpu.sys_id 3
          string cpu.comment
          string cpu.status on-line

       cpu
          int cpu.sys_id 2
          string cpu.comment
          string cpu.status on-line


   この出力に「pool email-pool」セクションと「pset email-pset」セクションがあることに注目してください。さらに、「pset email-pset」セクションでは、このプールに 1 つの CPU が割り当てられていることがわかります (「pset.size 1」)。

プロセッサ・セットとリソース・プールを作成したら、Solaris Zone 技術を使って、電子メール・サーバ・アプリケーション用と Web サーバ・アプリケーション用に別々の環境を作成します。

• 構成—ゾーンのプロパティ (必要なファイル・システムの数やネットワーク・インタフェースの数) を定義します。
• インストール—ファイル・システム階層のうちこのゾーン用に予約された部分をインストールし、そこにデータを割り当てることによって、システムにゾーンを作成します。
• 仮想プラットフォーム管理—ゾーン・ツールを使ってゾーンのブート、停止、リブートを行います。
• ゾーンへのログイン—管理作業のためにゾーンへのログイン／ログアウトを行います。

ここで作成する 電子メール・サーバ用のゾーンは標準的なものです。ほかの 2 つのゾーンではもっと多くのオプションを使用します。以下の手順では、新しいリソース・プールをもつ 1 つのゾーンからなるコンテナを作成します。このゾーンは 「email-zone」という名前で、IPv4 アドレスは 10.0.0.1 です。

1. 1 つの IP アドレス
2. ネットワーク・インタフェースの名前
   注: グローバル・ゾーンで「ifconfig -a」コマンドを実行すれば、システムの物理ネットワーク・インタフェースをすばやく見つけることができます。
3. さらに、使用するファイル・システムに、ゾーンを収容するだけのディスク領域があるか確認してください。
   注: デフォルト構成では、約 100 MB の空きディスク領域とアプリケーション用の領域が必要です。

1. zonecfg(1M) コマンドを使ってゾーン構成ツールを起動します。
   
   global# zonecfg -z email-zone
   
   「そのようなゾーンはまだ構成されていない」ことを示すメッセージが表示され、続いて新しいゾーンの構成を始めるプロンプトが表示されます。「zonecfg:email-zone>」というプロンプトによって、zonecfg シェルであることがわかります。
2. create コマンドを使って新しいゾーン定義を作成します。
   
   zonecfg:email-zone> create
   
   
3. set zonepath コマンドを使ってゾーンをファイル・システムに割り当てます。
   
   zonecfg:email-zone> set zonepath=/export/home/zones/email-zone
   
   注: ファイル・システムには、ゾーンを収容できるだけのディスク領域をもつものを指定してください。デフォルト構成では、約 100 MB の空きディスク領域とアプリケーション用の領域が必要です。
4. システム・ブート時にこのゾーンを自動的にブートするかどうかを指定します。自動的にブートする場合は set autoboot コマンドを使用します。
   
   zonecfg:my-zone> set autoboot=true
   
   システム・ブート時にゾーンを自動的にブートする場合は「True」を、そうでない場合は「no」をそれぞれ指定します。
5. add net コマンドとそのサブコマンドを使ってネットワーキング・パラメータを構成します。
   
   zonecfg:email-zone> add net
zonecfg:email-zone:net> set address=10.0.0.1
zonecfg:email-zone:net> set physical=eri0
zonecfg:email-zone:net> end
   
   この例では、IP アドレス 10.0.0.1 をもつ仮想ネットワーク・インタフェースが eri0 インタフェースに対応付けられます。
6. ゾーンを電子メール・プールに割り当てます。
   
   zonecfg:email-zone> set pool=email-pool
   
   
7. verify コマンドを使って、構成に構文の間違いがないか検査します。
   
   zonecfg:email-zone> verify
   
   構成にエラーが見つかっても、メッセージが返されるだけです。
8. commit コマンドを使って構成を保存し、続いてシェルを終了します。
   
   zonecfg:email-zone> commit
zonecfg:email-zone> exit (または ^D [Ctrl d])
   
   標準のゾーンは、/usr、/lib、/platform、/sbin の各ファイル・システムを自動的にグローバル・ゾーンと共有します。ただし、標準的なゾーン構成では、すべてのグローバル・ファイル・システムが読み取り専用としてマウントされます。そのため、アプリケーションをこれらのディレクトリにインストールしようとしてもできません。書き込み権限付きのグローバル・ゾーン・ファイル・システムを、アプリケーションがインストールされているディレクトリにマウントする方法については、「最初の Web サーバ・コンテナを作成する」を参照してください。

ゾーン構成の過程で使用する verify コマンドは、構成が構文的に正しいかどうかを検証するだけです。このコマンドは、この構成を一般的なシステム上に作成可能かどうかを判断しますが、システムは必ずしもこの特定のシステムと同じであるとは限りません。ターゲット・システムに対する本格的な検証は、ゾーンをインストールする際に自動的に行われます。ゾーンをインストールする zoneadm(1M) コマンドは、構成に指定された物理ネットワーク・インタフェースなどすべてのリソース・プールが使用可能かどうかをチェックします。そして、ゾーンのルート・ファイル・システムに必要なファイルを zonepath 下の正しい場所にインストールし、構成に指定された追加のファイル・システムのマウント・ポイントを作成します。

9. zoneadm(1M) コマンドを使ってゾーンをインストールします。
   
   global# zoneadm -z email-zone install
Preparing to install zone email-zone
Creating list of files to copy from the global zone.
[出力を一部省略]
Zone email-zone is initialized.
   
   この処理には数分かかる場合があります。

インストールが終わったら、次にゾーンをブートします。ただし、ゾーンのインストールが終了していても、ゾーン自体に係わるシステム識別処理はまだ行われていません。この時点で管理者は、ゾーンに対する root パスワードやゾーンを接続すべきネーム・サーバなどを構成することができます。ゾーンを初めてブートすると、このシステム識別を構成するよう自動的に要求されます。

10. zoneadm(1M) ブート・コマンドを使ってゾーンをブートします。
    
    global# zoneadm -z email-zone boot
    
    ゾーンをインストールした後の最初のブートであるため、システム識別に関する標準的な質問に答える必要があります。これらの質問に答えるためにゾーンのコンソールにログインしてください。

11. まず zlogin(1M) コマンドを使ってゾーンの Console にログオンします。システムが起動すると、新しくインストールした Solaris OS インスタンスの通常のシステム識別処理が始まります。煩雑になるためこの処理の出力は省略しますが、ネーム・サービス、タイム・ゾーン、システム・パラメータなどに関する質問に対して、このサイトに応じた答えが必要になります。
    
    global# zlogin -C email-zone
[Connected to zone email-zone console]
[正常なシステムがブートする場合の出力を示します。
システムを識別するための通常の質問が表示されます。
以下は推奨例です。]
Terminal=(12)X Terminal Emulator (xterms)
Hostname for eri0:1 = email-zone
No Kerberos
Name service = None
Time Zone = my-time-zone
root passwd = (任意に指定します)
    
    システム識別が完了すると、root パスワードが設定され、ゾーンがリブートされます。これでゾーンは使用可能な状態になります。

12. tip(1) の場合のように、~. (チルド、ドット) を使ってコンソールとの接続を解除します。これで、標準的な Solaris OS システムと同じように、telnet(1) や rlogin(1)、ssh(1) コマンドを使ってネットワーク経由でゾーンにアクセスできます。

図 9 には、新しいゾーンとそのリソース・プールが定義された後のシステムの状態を示します。この図には、さらにグローバル・ゾーンとデフォルト・プールが示されています。デフォルト・プールには 3 つの CPU が残されていることがわかります。

システム上に作成したゾーンは 1 つずつインストールし、構成し、ブートする必要があります。さらに、識別処理の自動化には sysidcfg(4) ファイルが使用できます。詳細については、http://docs.sun.com をご覧ください。

電子メール・サーバ・アプリケーション用の Container の作成、インストール、ブートが終了したので、次に 1 つめの Web サーバ用の Container を作成します。この新しい Container は 電子メール・サーバ・アプリケーション用に作成したものとほぼ同じですが、この Container ではさらに、Fair Share Scheduler を使って、使用する CPU 量を保証します。

1. poolcfg(1M) コマンドを使ってデフォルト・プールのスケジューラとして Fair Share Scheduler を設定します。
   
   global# poolcfg -c 'modify pool pool_default (string pool.scheduler="FSS")'


2. pooladm(1M) コマンドを使ってこの構成のインスタンスを作成します。
   
   global# pooladm -c


3. デフォルト・プールとそれに対応するすべてのゾーン内にあるすべてのプロセスを FSS の下に移動します。
   
   global# priocntl -s -c FSS -i class TS
global# priocntl -s -c FSS -i pid 1
   
   システムをリブートしない場合は priocntl(1) を使用します。このステップは、システムをリブートすることで行うこともできます。

このゾーンのインストールは以前の手順よりいくらか複雑です。このインストールでは、ゾーンに 3 つの Fair Share のシェアを割り当て、さらに /usr/local ファイル・システムへの読み書き権限を与えます。

1. 電子メール・ゾーンの定義とインストールに使用したのと同じ手順を使って、最初の Web サーバ用のゾーンを定義します。ゾーンの名前や、その場所、使用するプールの名前、IP アドレスには、必ず電子メール・ゾーンとは別のものを使用してください。
   
   global# zonecfg -z Web1-zone
Web1-zone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:Web1-zone> create
zonecfg:Web1-zone> set zonepath=/export/home/zones/Web1-zone
zonecfg:Web1-zone:net> set address=10.0.0.2
zonecfg:Web1-zone:net> set physical=eri0
zonecfg:Web1-zone:net> end
zonecfg:Web1-zone> set pool=pool_default

2 つの Web サーバは、デフォルト・プールの CPU リソースをそれぞれと共有するだけでなく、グローバル・ゾーンとも共有します。したがって、これらのリソースをどのように共有するかを Fair Share Scheduler (FSS) で指定する必要があります。

FSS では、アプリケーションの相対的な重要性を、シェア数という形で CPU リソースを割り当てることで表します。シェア数とは、システムの CPU リソースの内、このアプリケーションに割り当てられる部分のことをいいます。アプリケーションに割り当てるシェアの数を大きくすれば、それだけ多くの CPU リソース (ほかのアプリケーションに比べて) が FSS ソフトウェアからアプリケーションに割り当てられます。アプリケーションが受け取るシェアの数は絶対的な値ではありません。重要なことは、そのアプリケーションのシェア数がほかのアプリケーションに比べてどうかという点と、それらのアプリケーションの間で CPU リソースの競合があるかどうかという点です。

2. 次の各コマンドを使ってこのゾーンに 3 つのシェアを割り当てます。
   
zonecfg:Web1-zone> add rctl
zonecfg:Web1-zone:rctl> set name=zone.cpu-shares
zonecfg:Web1-zone:rctl> add value (priv=privileged,limit=3,action=none)
zonecfg:Web1-zone:rctl> end
zonecfg:Web1-zone> exit

電子メール・サーバのような標準的なゾーン・インストールでは、/usr ディレクトリは読み取り専用として構成されます。しかし、アプリケーションを /usr の下のサブディレクトリ (たとえば、/usr/local) にインストールする必要がある場合があります (オープン・ソース・ソフトウェアはしばしば /usr/local にインストールされる)。標準的なゾーン・インストールではこのようなことはできません。これを可能にするには、ゾーン構成の処理を変更する必要があります。つまり、このゾーンの /usr/local ディレクトリに追加ディレクトリを読み書き可能でマウントするようにゾーン構成を変更します。

この例では、最初の Web サーバを /usr/local/bin にインストールします。したがって、これをサポートするようにゾーンを構成する必要があります。

3. グローバル・ゾーンで、mkdir(1) コマンドを使用して新しいゾーンにエクスポートするディレクトリを作成します。
   
   global# mkdir -p /export/home/zones/Web1-zone/local


4. chmod(1) コマンドを使用して、グローバル・ゾーンの root だけがこのディレクトリに入れるようにアクセス権を設定します。
   
   global# chmod 700 /export/home/zones/Web1-zone


5. ファイル・システムをマウントするディレクトリを作成します。このディレクトリがすでにある場合は、このステップをスキップしてください。
   
   global# mkdir /usr/local


6. zonecfg(1M) を実行して新しいゾーンのゾーン構成ツールを起動します。
   
   global# zonecfg -z Web1-zone


7. add fs コマンドを使って新しいゾーンにファイル・システムを追加します。
   
   zonecfg:Web1-zone> add fs


8. このファイル・システムをマウントできる、新しいゾーン内のディレクトリを指定します。
   
   zonecfg:Web1-zone:fs> set dir=/usr/local


9. グローバル・ゾーンのディレクトリを新しいゾーンにエクスポートします。
   
   zonecfg:Web1-zone:fs> set special=/export/home/zones/Web1-zone/local


10. ファイル・システム・タイプとして loopback ファイル・システムを設定します。
    
    zonecfg:Web1-zone:fs> set type=lofs


11. ディレクトリのアクセス権限として読み書き可能を設定します。
    
    zonecfg:Web1-zone:fs> set options=[rw,nodevices]


12. 構成を終了します。
    
    zonecfg:Web1-zone:fs> end


13. 構成の検査とコミットを行なってから、ゾーンのインストールとブートを行います。さらに、システム構成を行います (「ゾーンのログイン」のステップ 11 を参照)。
    
    zonecfg:Web1-zone> verify
zonecfg:Web1-zone> commit
zonecfg:Web1-zone> exit
global# zoneadm -z email-zone install
global# [output omitted here for brevity]
global# zoneadm -z Web1-zone boot
global# zlogin -C Web1-zone
    
    注: ゾーンがどのような状態にあるかを調べるには zoneadm list -cv が便利です。

この手順の結果は図 10 の通りです。これで 2 つのコンテナが作成されたことになります。一方のコンテナは一定量の CPU をもち、もう 1 つはグローバル・ゾーンと CPU を動的に共有しています。

最初の Web サーバ用コンテナの作成、インストール、ブートが終了したら、2 つめの Web サーバ用コンテナを作成します。このコンテナは最初のコンテナとほぼ同じですが、割り当てられる FSS シェアの数が異なります。さらに、2 つめのコンテナは CD-ROM デバイスと raw ディスク・パーティションにアクセスできます。

1. Web1-zone ゾーンを作成したのと同じ手順を使って 2 つめの Web サイト用のゾーンを作成します。ゾーンの名前や、その場所、使用するプールの名前、IP アドレスには前とは別のものを使用してください。
   
zonecfg -z Web2-zone
Web2-zone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:Web2-zone> create
zonecfg:Web2-zone> set zonepath=/export/home/zones/Web2-zone
zonecfg:Web2-zone> add net
zonecfg:Web2-zone:net> set address=10.0.0.3
zonecfg:Web2-zone:net> set physical=eri0
zonecfg:Web2-zone:net> end...
zonecfg:Web2-zone> set pool=pool_default


2. Fair Share Scheduler の使用を指定し、このゾーンに 2 シェアを割り当てます。
   
   zonecfg:Web2-zone> add rctl
zonecfg:Web2-zone:rctl> set name=zone.cpu-shares
zonecfg:Web2-zone:rctl> add value (priv=privileged,limit=2,action=none)
zonecfg:Web2-zone:rtcl> end

このコンテナのユーザに CD-ROM デバイスへのアクセス権を与える方法

3. add fs を使ってゾーンにファイル・システムを追加します。
   
   zonecfg:Web2-zone> add fs


4. ゾーンの CD-ROM ディレクトリを指定します。
   
   zonecfg:Web2-zone:fs> set dir=/cdrom


5. グローバル・ゾーンのディレクトリを新しいゾーンにエクスポートします。
   
   zonecfg:Web2-zone:fs> set special=/cdrom


6. loopback ファイル・システムを使用します。
   
   zonecfg:Web2-zone:fs> set type=l


7. CD-ROM は読み取り専用であるため、ディレクトリのアクセス権を読み取り専用に設定します。
   
   zonecfg:Web2-zone:fs> set options=[nodevices]


8. 構成を終了します。
   
   zonecfg:Web2-zone:fs> end
   
   注: CD-ROM へのアクセス権を 1 つのゾーンに許可した場合、同じ CD-ROM ドライブへのアクセス権をほかのゾーンには許可しないでください。

raw デバイス (raw ディスク・パーティション) へのアクセス権をゾーンに与えるには次の手順を行います。

9. raw パーティションのブロック型デバイスをゾーンに追加します。
   
   zonecfg:Web2-zone> add device
zonecfg:Web2-zone:device> set match=/dev/dsk/c0t0d0s6
zonecfg:Web2-zone:device> end


10. raw パーティションのキャラクタ型デバイスをゾーンに追加します。
    
    zonecfg:Web2-zone> add device
zonecfg:Web2-zone:device> set match=/dev/rdsk/c0t0d0s6
zonecfg:Web2-zone:device> end
zonecfg:Web2-zone> verify
zonecfg:Web2-zone> commit
zonecfg:Web2-zone> exit
    
    グローバル・ゾーンの管理者は、この処理の間、このディスク・パーティションがほかのゾーンにエクスポートされないように注意しなければなりません。このようなエクスポートが行われると、データが壊れるおそれがあります。
11. インストール、ブート、構成を行います。

このシステム構成の結果は図 11 のようになります。電子メール・サーバはそれ自身の CPU を保証されているため、この CPU がほかのアプリケーションから使用されることはありません。一方、2 つの Web サーバは残りの 3 つの CPU を共有しています。図には FSS シェアの割り当てが示され、最初の Web サーバ・アプリケーションには、合計 6 シェアのうち 3 シェアが割り当てられています。したがって、3 CPU のうち 1.5 CPU 相当 (3*3/6=1.5) を使用する権利があります。2 つめの Web サーバ・アプリケーションには 2 シェアが割り当てられています。これは 1 CPU に相当します。グローバル・ゾーンには、残りの 0.5 CPU 相当が割り当てられます。

最後に Oracle は、これらのタイプの Solaris Container を有効なライセンス範囲として認めています。Oracle の用語では、これらのコンテナは 「Capped Container」と呼ばれ、Dynamic Resource Pool と Solaris Zone の組み合わせに相当します。ライセンスの大きさは、プール内の CPU 量で決まります。

ページ先頭へ

その他の情報

このガイドでは、Solaris Container 技術を素早く設定し実行するための手順を説明しましたが、さらに高度な構成を行うことも可能です。Solaris Container や Solaris Zone に関する詳しい情報については、jp.sun.com/solaris をご覧ください。

ページ先頭へ