lxcficon.jpg LXCFのコンセプトと特徴

元のページに戻る

1. LXCFのコンセプト

LXCはMW/アプリケーションの実行のために多数のコンテナ環境を生成できる優れた特徴を持っています。 しかし、業務用システム(エンタープライズシステム)のユーザーには、LXCの既存のツールは十分ではありませんでした。

長期間の運用が容易に行えるフルOS環境のLXCコンテナを容易に生成できる新しいツールが必要です。 そのシステムではアップデートやErrataの適用もできなければなりません。そこで、そのような新しいツールとして、LXCF (LXC Facility) を開発しました。

LXCFのコンテナはホストと同じファイルツリーの環境を提供します。また、各コンテナでは固有の領域を持ち固有のログ領域があり、ホストや他のコンテナとは異なるサービスをsystemdを設定して提供します。 さらに、ユーザはダイナミックにそれぞれのLXCコンテナのCPU、MEMORY、IO、およびNETWORKに関するリソースを変えることもできます。

2. LXCF リソース制御のメリット

1) 従来の問題点

lxcf-prob1.jpg

リソースの取り合い
一つのサーバに一つのアプリに制限(WebサーバやDBなど)
野放し、無法状態、予測できない運用環境
外部からの要求(NETWORK)による応答アプリの際限のない負荷上昇

2) LXCで解決

lxcf-prob2.jpg

コンテナ内の独立資源を配分、使用リソースの制限
1つのサーバに複数の独立した同種アプリの配置が可能
整然とした見通しのよい運用
過負荷をコンテナ内で封じ込め、他のコンテナ中のアプリやホストに影響させない

3) LXCでさらに発展

lxcf-prob3.jpg

リソースの動的更新が可能となる
時間制御運転をコントロールする

− LXC は完全仮想化(KVMやVMwareなど)に比べてオーバーヘッドはほとんどない。
− コンテナ内のCPU、MEMORY、ネットワーク帯域などのリソースをコンテナ単位で制限できる。
− アプリ実行中にリソース量を動的に変更できる。
− リソースの競合するサービスを集約して同じOS上で動作させることが可能になる。

3. 特徴

- 各コンテナ間でMWやアプリが干渉しない
- 高効率、低レイテンシ(オーバーヘッド5%、レイテンシはbare metal同等)
- 省資源(CPU, MEMORY, DISK使用量が極めて少なくても動作可能)、高集積、最小資源量:CPU(25%), MEMORY(1GB), DISK(1GB)
- 個別のコンテナで独立した環境を保持できるモデルがある。SEPARATEモデルと呼ぶ。このモデルでは、インストール作業は個別のコンテナごとに可能で、個別のAPLやMWをインストールできる。
- コンテナ間で共通の環境を保持できるモデルがある。JOINTモデルと呼ぶ。このモデルでは、コンテナではインストール作業は不要。ホストにインストールしたAPLやMWは、LXCFコンテナ内でも動作する。
- 高速生成、高速起動(JOINTモデルのゲストコンテナのシステム生成と起動の目安は1分以内、クローニングと起動の場合も1分以内、起動だけの場合は約3秒、SEPARATEモデルでは、生成と起動が数分以内、クローニング数分以内、起動約3秒)
- リソース制御(CPU番号、CPU使用率、メモリ量、NUMA割当、IO速度(Read, Write)、IOPS、ネットワーク速度)、動的変更が可能

4. 2つのモデル

- SEPARATEモデルは、コンテナ個別のAPLやMWを可能にする。保守管理作業も従来と同様にコンテナ内で個別に行う。
- JOINTモデルは、ホストと同じAPLやMWの環境を全コンテナで共通に使うものであり、インストールやアップデート、ERRATA適用作業をホストから一括して行うことにより保守管理作業が効率的に行える。

どちらのモデルも共通な機能

- IPアドレスやAPLやMWの設定は個別にコンテナ内で変更することができる。
- ログ等はコンテナ個別にロギングされる。
- サービスはsystemctl(systemd機能)によりコンテナ毎にstart/stopさせることができる。

SEPARATEモデルの機能

- 各コンテナ個別にアプリやMWをインストール・アップデートする。
- コンテナ生成前にホストにインストールしたMWやアプリはコンテナ作成時にコピーされる。
- コンテナ生成後にはホストにインストールしたMWやアプリは作成時にコピーされないので、管理者が後から個別にインストールする必要がある。
- 特定のコンテナごとに、個別のAPLやMWをインストール可能。
- アップデート作業については個別にコンテナにログインして作業を行う。
- 特定のコンテナのみにインストールしたAPLやMWは、他のコンテナやホストからは使えない。

JOINTモデルの機能

- LXCFコンテナでは各コンテナ個別にインストールやアップデート作業は不要。ホストから一括して作業する。

5. パスワード

1. HOSTのパスワードはゲストの生成時にコンテナにコピーされHOSTと同じものがコンテナへのログインにおいてデフォルトで有効になる。コンテナ上でこのパスワードを独自のものに変更することもできる。コンテナ作成後、ホスト側での変更とゲスト側での変更は互いに影響しない。
2. コンテナの生成時に、rootのsshの公開鍵をゲストのコンテナに自動的に配送する。HOSTからコンテナへのrootのsshログインはパスワード不要。
3. コンテナ間あるいはコンテナからHOSTへのsshログインはパスワードが必要となる

6. コンテナ起動時のリソースの自動設定

- コンテナの起動時にはLXCFの定義ファイル(ホスト側の/etc/lxcf/rsc/<コンテナ名>)に設定されたリソースが割り当てられる。
- Virt-manager/libvirtによりautostartが設定されているとシステム起動時に上記LXCF定義ファイルに設定されたリソースが割り当てられる。

7. ネットワーク

- libvirt上でdefault(virbr0)とは異なる新しいネットワークlxcfnet1(virbr1)をインストール時に自動で作成してLXCFコンテナを接続する。
- ネットワークlxcfnet1は、NAT接続。デフォルトで192.168.125.0/24, gatewayは192.168.125.1
- DHCPは使用せず、LXCFコンテナ作成時に固定IPアドレスを自動で割り当てる。割り当てたIPアドレスはコンテナ名と対応させて、ホストの/etc/hostsに登録する。
- lxcfnet1は主にコンテナ管理用に用い、業務用ネットワークは別途作成して割り当てる。
- 新たなネットワークの作成と割り当てはvirt-managerを使う。

8. アップデート

- SEPARATEモデルでは、コンテナにログインし、個別にアップデート作業を行う。
- JOINTモデルでは、ホスト上でrpm, yumなどを使いアップデートするとコンテナとの整合性がとれなくなるためlxcfが提供するupdateコマンドを用いる。(例えば rpmコマンドを直接使うと/usrに対する変更はLXCFのゲストにも反映されるが、/opt, /var, /etc, /runに対する更新が行われない。)rpmコマンドをホスト上で使用してしまった場合、上記lxcf updateコマンドを改めて使用することで正常な状態(ホストとコンテナで同期がとれた状態)にすることができる。

Updateコマンドについて

JOINTモデルの更新では、updateコマンドを使用する。
アップデートを行う際にはコンテナはすべて停止しておく。
ホスト上で実行されたupdate コマンドの引数に指定されたコマンドで更新、作成または削除されたファイルが、全コンテナ環境およびホスト環境に反映される。
rpmパッケージが必要な場合はdeployコマンドで事前にパッケージファイルを全コンテナに配送してから、updateコマンドでインストールする。
deployコマンドでは、ホストと同じコンテナのパス上にファイルやディレクトリをデプロイする。
updateコマンドでは、コンテナ上のホストと同じパスで引数のコマンドを実行する。
例)

# lxcf  deploy valgrind-3.8.1-30.el7.x86_64.rpm
# lxcf  update rpm -ivh valgrind-3.8.1-30.el7.x86_64.rpm

パッケージなどファイルやディレクトリに依存しなければそのままupdateコマンドを実行する。
例)

# lxcf update yum update -y

全コンテナおよびホストでアップデートが行われる。

9. コンフィグファイル

/etc/lxcf/lxcf.confファイルにコンフィグ情報を設定する。

コンフィグファイル例)

#
# model = joint or separate
#
[Model]
model=separate

#
# lxcfnet1 address range
#
[ipaddr_range]
ipaddr_start=192.168.125.2
ipaddr_end  =192.168.125.254

modelにはseparateモデルを使うか、jointモデルを使うか指定する。
ipaddr_start, ipaddr_endには、lxcfnet1の使うアドレスの範囲を指定する。

10. ipcsリソース

sysctlで設定される以下のカーネルパラメタは、HOSTとは独立した値をコンテナ内からも設定できる。

- kernel.msgmax
- kernel.msgmnb 
- kernel.msgmni
- kernel.shmall
- kernel.shmmax
- kernel.shmmni
- kernel.sem 

LXCコンテナ内ではipcsのリソースは前記のカーネルパラメタ値で制限される。
コンテナ内で大きな値を設定した影響が他のコンテナやホストに影響するのを防ぎたい場合は、LXCFのmemlimitでコンテナの使用するメモリ量を設定する。

11.バッチキューシステム

- 次に示すコマンド実行は、バッチキュー上で順に自動的に実行できる。

   sysgen
   sysgen-n
   clone
   clone-n
   set[
   set-n
   erase
   erase-n
   update
   deploy
- これらのコマンドはコンテナの生成や削除に利用される時間のかかるコマンドである。そのため複数のコマンドの実行を行うためには、前のコマンド実行を待たなければならない。
- バッチキューにこれらコマンドの実行をサブミットするとジョブとしてキューイングされ、順に実行されていく。
- “queue”サブコマンドは別名として”q”をつかうことができる。 - 実行結果は以下のファイルにロギングされる。
    /var/log/lxcf/lxcf-messages

- バッチキューシステムには、3つのキューがある。

H-QUEUE:
- 高優先度キュー。緊急に高い優先度で実行したいジョブを実行する。
- Q-QUEUEやL-QUEUEに未実行のジョブがあっても、H-QUEUEのジョブが優先して実行される。
- ただし、Q-QUEUEやL-QUEUEの処理のすでに実行途中のジョブを止めることはない。実行途中のジョブが終わった後にH-QUEUEのジョブが実行される。
Q-QUEUE:
- 通常優先度キュー。デフォルトで使われるキュー。
L-QUEUE:
- 低優先度キュー。緊急性のない空き時間で実行されればよいジョブを実行する。
- H-QUEUEやQ-QUEUEにジョブが残っている間はこのキューのジョブは実行されない。

- ジョブのサブミットはsubmitコマンドを使う。引数に実行したいsysgenなどコマンドを指定する。ジョブはQ-QUEUEに入る。

    # lxcf submit sysgen euro-srv
    submited : 950201ce-c11f-11e3-9a01-00d068148bd6

サブミットすると、ジョブに割り当てられたuuidが表示される。uuidは、ジョブごとに異なる値になり、ジョブの識別に使われる。

- ジョブをH-QUEUEやL-QUEUEに入れたい場合は、submitコマンドに”-h”や”-l”のオプションを指定する。

    # lxcf  submit  –h sysgen  Emergsrv
    # lxcf  submit  –l sysgen  LowPrisrv
- キューでは、実行中のsubmitされたジョブと作成されたコンテナにもUUIDが付加される。UUIDを指定することにより、cancel, start, stopなどの操作の対象となる。 - キューの操作や状態を確認するにはqueueコマンドを使う。これらコマンドの実行は/var/log/lxcf/lxcf-messagesにロギングされる。

キューの一覧表示(list)
    # lxcf queue list
            <<< Containers >>>
    94b6a94a-e15e-11e3-8f14-00d068148bd6 a-srv running

            <<< JOB under execution >>>
    950201ce-c11f-11e3-9a01-00d068148bd6 sysgen asia-srv

              *** H-QUEUE ***
    007945ac-c120-11e3-b1f9-00d068148bd6 sysgen Emergsrv
              *** Q-QUEUE ***
    db1cb406-c11f-11e3-aa27-00d068148bd6 sysgen euro-srv
              *** L-QUEUE ***
    fb2e7c84-c11f-11e3-b4b8-00d068148bd6 sysgen LowPrisrv
ジョブのキャンセル(cancel)
uuidを指定したジョブをキャンセルする。
    # lxcf queue cancel db1cb406-c11f-11e3-aa27-00d068148bd6
    Canceled : db1cb406-c11f-11e3-aa27-00d068148bd6 sysgen euro-srv
キュー上のジョブの全クリア(clear)
-h, -q, -lオプションを付けるとクリアするキューを選択できる。オプションがなければ、全キューのジョブをクリアする。
    # lxcf queue clear
    canceled : ALL QUEUE
    007945ac-c120-11e3-b1f9-00d068148bd6 sysgen Emergsrv
    950201ce-c11f-11e3-9a01-00d068148bd6 sysgen asia-srv
    fb2e7c84-c11f-11e3-b4b8-00d068148bd6 sysgen LowPrisrv
キュー上のジョブの移動(move)
移動先のキューを、-h, -q, -lで指定する。
    # lxcf queue move -h 950201ce-c11f-11e3-9a01-00d068148bd6
    moved to H-QUEUE : 950201ce-c11f-11e3-9a01-00d068148bd6 sysgen asia-srv

12. 制限、注意事項

- SELinuxはホストでのみON/OFFでき、ホストとゲストの設定を別に設定することは不可
- 調整する必要のあるパラメータや動作サービスの制約。

- 時刻はホストとゲストで同一に固定される。ゲスト内でNTP(Chrony)は起動できない
- タイムゾーンはコンテナ内でホストや他のコンテナと独立して設定できる。
- システム設計時にホストとコンテナのスレッド数、およびプロセス数の合計上限を見積もる必要がある。具体的にはsysctlコマンドのthreads-maxパラメタを調整する。
- その他

- LXCFではホストにswap領域を設定しなければならない。swap領域の見積もりは従来の設定に従う。
- 現状では実装上の制約によりコンテナからは、他のコンテナの状況やホストの状況が見えることがある。コンテナで動作するプログラムはセキュリティ上信用できない不特定多数のユーザに実行させることは望ましくない。

元のページに戻る