金曜日 4 23, 2010

ローカルゾーン上での特権 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_time
sys_time
        適切なシステムコール (stime、adjtime、ntp_adjtime) と x86 固有の
        RTC 呼び出しのいずれかを使用して、システム時刻を操作できるように
        します。
それでは実際に sys_time 特権を Solaris ゾーンへ割り当ててみます。
デフォルトでは sys_time 特権は Solaris ゾーンに割り当てられていませんので、時刻を変更しようとするとエラーとなります。
下記の例では、ppriv(1M) コマンドを使用して特権の不足も合わせて確認しています。ppriv(1M) コマンドがない場合は最初の一行目は出力されません。
global# ppriv -l zone | grep sys_time   <=== グローバルゾーンで指定できる特権
sys_time
zone0# ppriv -l zone | grep sys_time    <=== Solaris ゾーンで指定できる特権
zone0#                                     <=== デフォルトでは特権 sys_time なし
zone0# ppriv -D -e date 021818502010
date[29958]: missing privilege "sys_time" (euid = 0, syscall = 25) needed at stime+0x21
date: Not owner
usage:  date [-u] mmddHHMM[[cc]yy][.SS]
        date [-u] [+format]
        date -a [-]sss[.fff]
上記出力から sys_time 特権が date(1) コマンドの実行に不足していることが確認できます。
Solaris ゾーンでは、不足している特権をグローバルゾーンから zonecfg(1M) コマンドで limitpriv プロパティを指定することで追加できます。このプロパティに、sys_time 特権を指定します。
global# zoneadm -z zone0 halt
global# zonecfg -z zone0 set limitpriv="default,sys_time"
global# zonecfg -z zone0 info
zonename: zone0
zonepath: /zfs/zpool0/zone0
brand: native
autoboot: false
bootargs:
pool:
limitpriv: default,sys_time   <=== ここ
scheduling-class:
ip-type: shared
inherit-pkg-dir:
        dir: /lib
inherit-pkg-dir:
        dir: /platform
inherit-pkg-dir:
        dir: /sbin
inherit-pkg-dir:
        dir: /usr
net:
        address: 192.168.1.100
        physical: skge0
        defrouter が指定されていません

global# zoneadm list -vc
  ID NAME             STATUS     PATH                           BRAND    IP
   0 global           running    /                              native   shared
   - zone0            installed  /zfs/zpool0/zone0              native   shared
global# zoneadm -z zone0 boot
global# zoneadm list -vc
  ID NAME             STATUS     PATH                           BRAND    IP
   0 global           running    /                              native   shared
   4 zone0            running    /zfs/zpool0/zone0              native   shared
改めて Solaris ゾーン上で時刻を設定してみると、設定出来ることが確認できました。
global# zlogin zone0
[ゾーン 'zone0' pts/5 に接続されました]
Last login: Mon Apr 19 15:18:32 on pts/5
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
zone0#
zone0# ppriv -l zone | grep sys_time
sys_time
zone0# date
2010年04月19日 (月) 16時00分59秒 JST
zone0# ppriv -D -e date 04192359

2010年04月19日 (月) 23時59分00秒 JST
zone0#

global# date
2010年04月19日 (月) 23時59分05秒 JST
うまく設定が出来るようになりましたが、1 点注目すべきポイントがあります。
上記設定はシステムの時刻設定をした事になりますので、グローバルゾーンにも時刻変更の影響を与えます。試してはいませんが、同一サーバ上の他の Solaris ゾーンにも同様に影響が出ることになります。
次の例はデフォルトの動作になりますが、グローバルゾーンで時刻を設定すれば、Solaris ゾーンにも反映されます。
global#  ppriv -D -e date 04191540
2010年04月19日 (月) 15時40分00秒 JST
global# date
2010年04月19日 (月) 15時40分05秒 JST

zone0# date
2010年04月19日 (月) 15時40分03秒 JST
このように、Solaris ゾーンで必要な特権を割り当てることで時刻を設定することが可能でした。グローバルゾーンを含む他のゾーンにも時刻設定の影響が出ることも確認できました。
sys_time 特権は、date(1) コマンドの他に ntpdate(1M) コマンドや xntpd(1M) デーモンでも使用されていますので、冒頭で考えたようにグローバルゾーンをインタネットにさらけ出さずにすみそうです。
最後に、今回の設定と netservices(1M) 等とを組み合わせれば、よりセキュアな Solaris ゾーン環境を構築できることになりますね。

参考ドキュメント
  • Solaris のシステム管理 (Solaris コンテナ : 資源管理と Solaris ゾーン)
  • Solaris 10 - アプリケーションのゾーン対応
  • Shrink-Wrap Security

  • 木曜日 4 22, 2010

    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-zone
    real-zone: そのような構成済みゾーンはありません
    'create' を使用して、新しいゾーンの構成を開始してください。
    zonecfg:real-zone> create
    zonecfg:real-zone> set zonepath=/export/zone/real-zone
    zonecfg:real-zone> add dedicated-cpu
    zonecfg:real-zone:dedicated-cpu> set ncpus=2
    zonecfg:real-zone:dedicated-cpu> end
    zonecfg:real-zone> set scheduling-class=RT
    zonecfg:real-zone> verify
    zonecfg:real-zone> commit
    zonecfg:real-zone> exit
    
    # zoneadm -z real-zone install
    Preparing 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   shared
    

    poolstat コマンドで、プールの状態 (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 -d
    TIME SHARING PROCESSES:
        PID    TSUPRILIM    TSUPRI
       6487        0           0
    
    
    real-zone# priocntl -d
    REAL 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  ./nspinx
     6522   zone01  ./nspinx
     6524 real-zone ./nspinx
     6525 real-zone ./nspinx
    

    prstat -z の結果より、PRI を確認すると、real-zone で実行しているプロセスの PRI が 60 より大きいので、RT でスケジューリングされている事が確認できます。

    prstat -z の結果
       PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
      6525 root     1344K  540K cpu0   100    -   0:01:53  25% nspinx/1
      6524 root     1344K  672K cpu1   100    -   0:01:53  25% nspinx/1
      6522 root     1344K  672K cpu3    20    0   0:01:57  25% nspinx/1
      6523 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% global
    
    Total: 80 processes, 312 lwps, load averages: 4.92, 5.53, 2.86
    

    ご参考で、各スケジューリングクラスに割り当たる PRI 番号は下記コマンドで 確認できます。

    # priocntl -l
    CONFIGURED CLASSES
    ==================
    
    SYS (System Class)
    
    TS (Time Sharing)
            Configured TS User Priority Range: -60 through 60
    
    FX (Fixed priority)
            Configured FX User Priority Range: 0 through 60
    
    IA (Interactive)
            Configured IA User Priority Range: -60 through 60
    
    FSS (Fair Share)
            Configured FSS User Priority Range: -60 through 60
    
    RT (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

    水曜日 4 21, 2010

    dispadmin コマンドの紹介

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

    Solaris コンテナ上の CPU リソース制御は、FSS(Fair Share Scheduler)を使用 しますが、Solaris 10 初期インストールの状態では、スケジューラが FSS を デフォルトで使用する設定になっておりません。

    その為、zonecfg コマンドで cpu-shares プロパティを設定した Zone を起動すると 下記ワーニングメッセージが出力されます。
    (今回は、Solaris 10 10/09 で検証しております。)

    # zoneadm -z zone01 boot
    
    zoneadm: 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 -d
    dispadmin: Default scheduling class is not set
    

    Solaris 10 の初期インストール状態では、デフォルトスケジューラは何も設定 されていない事が確認できます。

    それでは、デフォルトスケジューラを FSS に設定してみましょう。
    # dispadmin -d FSS
    
    これで設定が完了しました。
    最後にデフォルトスケジューラに FSS が設定できたか確認してみましょう。
    # dispadmin -d
    FSS     (Fair Share)
    ----
    


    FSS の設定が完了しましたので、もう一度 Zone を起動してみます。
    # zoneadm -z zone01 boot
    

    zone01 起動時にワーニング出力が消えました。


    ちなみに、dispadmin でデフォルトのスケジューラを設定すると、 下記内容のファイルが /etc/dispadmin.conf に作成されます。
    # cat dispadmin.conf
    
    #
    # /etc/dispadmin.conf
    #
    # Do NOT edit this file by hand -- use dispadmin(1m) instead.
    #
    DEFAULT_SCHEDULER=FSS
    


    Zone のリソース制御が思うように動作しない場合、一度 dispadmin の設定を確認する事をお勧めします。


    (参考情報)
    過去の 「やっぱり Sun がスキ!」blog 記事一覧はこちらを参照下さい。 http://wikis.sun.com/display/yappri/Home
    About

    Search

    Archives
    « 4月 2014
      
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
       
           
    今日