リソース制御でサービスレベルを確保せよ実践! Xenで実現するサーバ統合(5)(1/3 ページ)

仮想化ソフトウェアの「Xen」を用いてサーバ統合を実践していく手順を具体的に紹介します。最終回ではゲストOSに対する各種リソースの割り当て・制限方法を紹介します(編集部)

» 2008年03月18日 00時00分 公開
[中嶋一樹, 高橋浩和住商情報システム株式会社/VA Linux Systems Japan株式会社]

 Xenを用いてサーバを統合する手順を具体的に紹介してきたこの連載も、いよいよ最終回です。今回は、Xenをインストールして仮想マシンを立ち上げた後に、CPUやメモリ、ネットワーク帯域といったリソースを各ゲストOSにどのように割り当て、必要に応じて制限するかというリソース制御の方法を解説したいと思います。

【関連記事】

http://www.atmarkit.co.jp/flinux/special/xen01/xen01.html
仮想化技術の大本命「Xen」を使ってみよう〜インストール & Debian環境構築編〜

http://www.atmarkit.co.jp/flinux/special/xen02/xen01.html
仮想化技術の大本命「Xen」を使ってみよう〜Xen対応カスタムカーネル構築編〜


ゲストOSのリソース制御はなぜ必要?

 Xenは、デフォルトではゲストOSに対して何らリソースの制限を掛けていません。CPUメモリネットワーク帯域ディスク帯域それぞれについて、ゲストOSがリソースを要求した際には、余裕さえあればできる限り要求元のゲストOSにリソースを割り当てようとします。

 しかしながら、さまざまな種類のゲストOSを1つのホストサーバ上に統合している場合は、これでは不都合なこともあります。VPS(Virtual Private Server)でホスティングサービスを提供している場合を想像してください。たいていのVPSサービスは保証するハードウェアリソース別に、そのサービスレベルを定義しています。

 例えば、以下のように2つのサービスレベルを用意しているとします。

サービスレベル メモリ容量 ネットワーク帯域 ディスク容量
アドバンスド 512Mbytes 1Mbps 20Gbytes
スタンダード 256Mbytes 0.5Mbps 5Gbytes
表1 2つのサービスレベル

 そしてシステムは、図1のように、1台のホストサーバ上に異なるサービスレベルのゲストOSが混在している構成だとします。

図1 異なるサービスレベルのゲストOSが混在している環境 図1 異なるサービスレベルのゲストOSが混在している環境

 メモリとディスク容量については、ゲストOSを作成する時点で必須のパラメータとなるので、特段意識する必要はありません。しかしネットワーク帯域については、デフォルトのままだと均等に割り当てられてしまいます。この結果、ネットワークに余裕があるときにはどのゲストOSでも十分なネットワーク帯域が確保できますが、込み合ってくると各ゲストOSに保証されるべき帯域が確保できないことになります。

 このような環境でサービスレベルに応じたリソース配分を実現するには、ホストOS側で、各ゲストOSのリソース制御の設定を施す必要があります。制御可能なリソースには以下のものがあります。

■CPU関連

  • 仮想CPU数
  • 仮想CPUと物理CPUのマッピング
  • CPU利用率閾値
  • CPUスケジュール優先度

■メモリ関連

  • 割当量/最大値

■ネットワーク関連

  • 帯域幅閾値(Linuxの機能で実現)
    ※ディスクについても優先度設定が可能ですが、ここでは割愛します

 では、上記の各項目について、その動作と設定方法について解説していきます。

CPUのリソース制御

 CPUおよびメモリ関連のリソース設定は、Xenがもともと備える機能として提供されています。設定方法は複数あり、ドメイン設定ファイルによって静的に行う方法と、xmコマンドで動的に行う方法があります。ドメイン設定ファイルは、デフォルトでは/etc/xen/以下に、各ゲストOSのドメイン名で保存されています。

 一方ネットワーク関連はXenの機能ではなく、OS側で提供されている機能に工夫を加えて設定を実現します。

■仮想CPU数

 ゲストOSに割り当てる仮想CPUの数です。これは実際にサーバ機に搭載されているCPU数とは関係ありません。

 例えば、サーバ機に搭載されているCPUがXeonデュアルコア×1ソケットだとすると、実CPU数は2になります(デュアルコアなので)。しかし仮想CPU個数として、例えば「4」のように、実CPU数よりも多い個数を指定することもできます。

図2 ゲストOSに仮想CPUを割り当てる 図2 ゲストOSに仮想CPUを割り当てる

 ゲストOSはここで指定されたCPU数を認識しますが、当然ながら、たとえ実CPU数よりも大きい値を指定してもパフォーマンスは上がりません。従って、実運用では常に仮想CPU数は実CPU数以下にするべきです。設定可能な値は1〜32となっており、稼働中に動的に変更可能です。

設定ファイルでの書式
vcpus = 数

xmコマンドでの書式
# xm vcpu-set ドメイン名 数

確認方法
# xm list ドメイン名
Name       ID Mem(MiB) VCPUs  State    Time(s)
vm01       14      511     2  -b----    379.1

■仮想CPUと物理CPUのマッピング

 前述のとおり、仮想CPU数は物理CPU数には依存しません。しかし実質的には、いずれかの物理CPUにマッピングされることになります。これは静的に固定することもできますし、動的にその場その場で選択されるよう設定することもできます。デフォルトでは動的に選択されるようになっています。

図3 仮想CPUと物理CPUのマッピング 図3 仮想CPUと物理CPUのマッピング

 物理CPU当たりのキャパシティを正確に管理したい場合には、以下のように設定し、サービスレベルを差別化することができます。稼働中にも動的に変更可能ですが、起動時の値より大きい値には変更できません。

図4 仮想CPUと物理CPUのマッピングを変更する 図4 仮想CPUと物理CPUのマッピングを変更する
設定ファイルでの書式
cpus = "物理CPU番号のリスト"

  <例>
  cpus = "0-3,5,^1"
  #CPU番号0,2,3,5が割り当てられる。 ^は除外を示す。
  #設定されなかった場合はすべての物理CPUに動的にマッピングされる。

xmコマンドでの書式
# xm vcpu-pin ドメイン名 仮想CPU番号 物理CPU番号のリスト

確認方法
# xm vcpu-list ドメイン名
Name    ID VCPUs CPU State  Time(s) CPU Affinity
vm01     4  0   0 -b-    0.6   0,2-3,5
vm01     4  1   3 -b-    0.4   0,2-3,5
vm01     4  2   5 -b-    0.0   0,2-3,5
vm01     4  3   2 -b-    0.0   0,2-3,5


       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。