VCPUの話。

今日は、仮想CPUの話です。

OVSなどのハイパーバイザ製品上で稼働するVMには、
仮想CPU（VCPU）が割り当てられます。

このVCPUの動きについて説明してみようと思います。

VCPUは、OVSが持っている物理CPUを
VMに使用させるためのものです。
ただし、CPUを 「エミュレーション（ソフトウェアがCPUを再現している）」
しているわけではなく、
ハイパーバイザがVMに直接、VCPU数をもとにした数の
物理CPUを使わせています。


たとえば、
物理CPUを4つ持っているOVS（Xenハイパーバイザ）で、
VCPUが2つ割り当てられているVMがあるとします。



この時、Xenハイパーバイザが物理CPU2つ分（VCPUと同じ数）
をVMに割り当てて、使用させている感じです。
VCPUは、いつも同じ物理CPUに割り当てられるわけではなく、
その時々で、別の物理CPUを割り当てられています。

VCPUと物理CPUの関係は、
ハイパーバイザによって絶えず調整されています。
そのため、あるときのVCPUと物理CPUの割り当てが、上の図のような状態だとしても、
次の瞬間、下の図のようにVMはそれぞれ別の物理CPUを使用しています。



また次の瞬間、
VMはそれぞれ別の物理CPUと紐づけられているわけです。




仮に、ゲストOSが常にVCPUを100%近く使用しているような
状態になっていたとしても
ずっと同じ物理CPUをつかみ続けているというわけではありません。

また、どんなにゲストOSが暴走しても、
1つのVCPUあたり、1つの物理CPUしか使用しません。


以上、VCPUの話でした。（続きはまた後日）

Xenは自宅ハイパーバイザにおすすめ

コンピュータを仮想化するソフトウェアには、

大きく分けて「ホスト型」、「ハイパーバイザ型」 の2種類があります。

 

Oracle VM Server の仮想化エンジンであるXenは、

ハイパーバイザ型と呼ばれる種類のソフトウェアです。

今日は、Xen の活躍できるケースの紹介です。

よくあるハイパーバイザの話について

 

ハイパーバイザ型と呼ばれるものでは

• Xen （有名なのは、OracleVM / Citrix Xen Server）
• Microsoft Hyper-V (Windowsに含まれるハイパーバイザ)
• KVM (Liuxカーネルに含まれる。Redhat の RHEVの基盤となる)
• VMware ESXi （vSphereの基盤として使われるハイパーバイザ）

といったものが有名だと思います。

それぞれアーキテクチャに特徴がありますが、

どれも、「サーバを仮想化する」「仮想マシンを稼働させる」

ことをすることに変わりはありません。

処理性能も、実際はそんなに変わらないようです。

（使い方によると思いますが）

企業やデータセンタで使用される場合は、

性能が決め手、というよりも

技術者の好みやコスト、ベンダの営業力などによって

その時に最適なものが選ばれていると思います。

 

 

ハイパーバイザのかなでも、Xenは「準仮想化」という方式をとることで知られています。 

完全に「仮想的なハードウェア」を作り出そうとする完全仮想化に対して、

準仮想化は、仮想化にするためにゲストOS自体をカスタマイズしています。

 

この完全仮想化/準仮想化の2択は

「どちらが高性能か」といった話題になりやすいですが、

最近はハードウェア（PCやサーバ）の性能も向上していて

そんなに変わることはないと言われます。

実際ちょっと試してみる分にはどの製品も、どっちもどっちな感じです。

 

よほど大規模/高負荷な環境でないかぎり、

ハイパーバイザによってシステム性能が変わることはありません。

 

 

自宅ハイパーバイザ

ただし、自宅ユースとなると Xenに利があると思います。

 

ハイパーバイザ自体、インストールの前提となる

ハードウェア要件が高いものがほとんどで、

• 仮想化支援機構（Intel-VTなど）がないCPUだとNG
• 64bitのCPUじゃないとNG
  OracleVMも、最新の Oracle VM 3 では、64bit 版のみとなってしまいましたが・・・
• 特定ベンダのNICじゃないと動かすのが大変

とインストール自体が難しい（HW要件的に）ものが多いです。

 

 

そんな中、ちょっと自宅のあまったPCで仮想化でもしてみようか

というニーズに一番マッチしているのはXenではないかと思います。

 

ちょっと昔のマシンでVMを動かすとなると

ゲストOS側がハードに合わせているのが「準仮想化」なので

Xenは、多少アレなPCにインストールしても

他のハイパーバイザよりもちょっと軽快です。

 

そういったわけで、余剰PCでの

ハイパーバイザの勉強などにもお勧めです。

以上、毒にも薬にもならない話でしたが、

ロースペック環境でハイパーバイザを試すならXenがおすすめ

という話でした。

仮想化環境の管理サーバをどこに構築するか。

今日は、Oracle VM Server（OVS）の管理サーバの話です。

Oracle VMでは、OVSの管理サーバとして

Oracle VM Manager（OVM）を使用します。

OVMの特徴

  

簡単に、OVMの特徴をまとめてみます。

• Oracle VM システムの管理サーバ（OVSやVMを管理する）
• WebブラウザによるGUI操作が可能
• Linuxサーバに、Oracle VM Managerをインストールして構築する

OVMの役割は、他社製品と対応させて考えると、
VMware vSphere の vCenter Server、
Microsoft Hyper-V のHyper-Vマネージャ などに相当します。

管理サーバをどこに構築するか

OVMは物理サーバでも、VM上にでも、どちらでも構築可能です。
構築場所を考えるときは、下記のパターンがあります。

1. 物理サーバに構築
2. OVS上で稼働するVMの中に構築（管理用のOVSを用意する）
3. OVS上で稼働するVMの中に構築（他のサービス提供するVMと一緒）

それぞれ選ぶ基準（決め手になりそうな理由）は、下記のような感じだと思います。

1. 物理サーバに構築

• 管理するOVSが多くて、性能的に心配
• 管理サーバが管理対象（OVS）の上に乗るのが（気分的に）心配

2. OVS上で稼働するVMの中に構築（管理用のOVSを用意する）

• 管理対象のOVSが少なく、普段はVMの起動停止に使うくらいなので性能も気にしない
• 物理サーバを用意するコストを削減したい

3. OVS上で稼働するVMの中に構築（他のサービス提供するVMと一緒）

• OVMをVMとして構築して、さらにコスト削減したい。サーバ台数を減らしたい。

 実際のところ、ちょっと性能がでなくても（UIの操作がモタつくくらいで）、

管理用サーバ用の物理サーバを用意するのはもったいないので

個人的には、よほどのことがない限り

OVMはVM上に構築するのがよいと思っています。

（事情によるとは思いますが）

OVMをVMにした場合の運用

ただし、仮想マシン上でVMを起動するには、先にOVMを起動する必要があるため、

ちょっと運用手順（VMの起動方法）に矛盾が出ます。

OVM自身がVMのため、

OVM自身（のVM）は、OVMを使用せずに起動する ことになります。

たとえば、

通常のVMを起動する場合は、

1. OVMにログインしてVMを起動
   ※すでにOVSは起動している前提です。

だけでよいのですが、

OVM自身をVMとして構築していると、
OVM用VMの起動のために

1. まず、OVMを使わないで、OVM用のVMを起動
   例：Dom0にSSHログインしてコマンド実行（xm create）する 等
2. 起動したOVMにあらためてログインして、他のVMを起動

することになります。

（実際は、OVS起動にあわせてVMを自動起動することもできますが）

こんな感じで、
コストや、仮想環境の使い勝手を考えながら
OVMをどう構築するか考えます。


以上、OVMの置き場所の話でした。

ユーティリティサーバの話。

Oracle VM には、
ユーティリティサーバという役割を持つOVSサーバが存在します。

まず、

ユーティリティサーバの特徴を簡単にまとめてみます。 

• 高IO処理（VMクローンなど）を担当するOVS
• 通常のOVS同様、ユーティリティサーバ上でVMを起動することが可能
• サーバプールごとに指定しておく必要がある

OVS側（Dom0側）でのIOは、仮想環境に対して影響を出しやすいため

別途、ユーティリティサーバという
IO処理専用OVSサーバ を用意するわけです。

OVSを1台だけで運用しているときは、

そのサーバ自体がユーティリティサーバになります。

OVSを複数台稼働させる環境では、

ユーティリティサーバ専用のOVSを稼働させることもできます。

ユーティリティサーバが存在する意味

従来の物理サーバのみを使用している環境でも、
「サービス影響（性能ダウン）を出さないようにバッチ処理は別のサーバからしよう」

「DBに対するバッチ処理は、別のバックアップ処理サーバから実行しよう」

といった、処理を外のサーバに出すことが多いと思います。

たとえば、下の図のように
ほかのサーバからDBのデータをコピーして、
DBサーバ側のリソースを使うことを避けたりするといった感じです。
（OracleのDBFをなにも考えずにコピーするとひどいことになりますが）

 

それと同じ感覚で、

「他のVMに影響を出しやすい、OVSでのIO処理は専用のOVSにやらせよう」

というのが、OVSのユーティリティサーバです。

ユーティリティサーバがについて考えること

OracleVMでユーティリティサーバを指定するときは、

サーバプール単位で指定します。

また、サーバプールに対して、複数台のユーティリティサーバを
配置することも可能です。
 

そのため、OVSの配置台数などを考えるときは、

• サーバプールに追加するOVSのうち、
  どのOVSにユーティリティサーバの役割をもたせるか
• ユーティリティサーバは何台必要か
  （どういったVM作成、クローンをするかによる）

といったことを考慮しておく必要があります。

サーバプール内でユーティリティサーバに依頼できる処理を

実行するときは、自動的にユーティリティサーバに働いてもらえます。

そのため、普段は（一度 環境構築が終わってしまったら）

ユーティリティサーバの存在はほとんど意識しないかもしれません。

 

以上、ユーティリティサーバの話でした。

  

サーバプールの話。

今日は、OVSのサーバプールの話です。

 

OracleVM Manager環境には、
「サーバプール」という考え方があります。
今日はOVSをプールにすることについての話です。

 

まず、

 

「プール」という用語は、

何かをまとめておくときに使われます。

 

たとえば、

• 泳ぐために水をためておく プール
• データディクショナリや 解析済みのSQLをためておく 共有プール
• AP-DBの接続をまとめておく コネクションプール

など。

 

IT用語としても、資源をためておくものとしてプールという用語は頻繁に使用されます。
ちなみに、Oracle RACにも11gR2からサーバプールという概念が登場してます。

OracleVMの世界では、
Oracle VM Server（OVS） をまとめてサーバプール とします。

 

なぜOVSのサーバプールをつくるのか

 

サーバプールを作っておくと、
サーバ運用を簡略化できるためです。

 

たとえば、OVSが20台、VMが200台くらい稼働するシステムがあったとします。
VM200台を、起動する度に 20台のOVSのどこで起動するかを考えるのは大変です。

 

 

まず、プールがない状態のことを考えてみます。

この場合、VMを起動しようとするたびに

サーバ運用している人がOVSを選んで起動する必要があります。

 

そういったときに

OVSを その上で稼働するVMの用途ごとに役割分けしておき、
あらかじめプールにしておくと、

 

サーバ運用している人が

「どこのプールでVMを起動するか」だけを指定して
実際はそのVMがどのOVSで起動するか気にしないでよい

といったシステム構成をすることができるようになります。

 

 

たとえば、

Webサーバ用VMのOVSをまとめたサーバプールと

DBサーバ用VMのOVSをまとめたサーバプールを作成しておきます。

 

そうすると、

「Webサーバ用VMをもう1台起動したい」ときには

Webサーバプール を指定するだけで、

あとはOracleVMが自動的にプール内の余裕があるOVSを選んで

VMを 起動する、というシステムの作り方ができるようになります。

 

 

 

Oracle VM でプールを作るとき

 

Oracle VMでサーバプールを構成するときは、

OVSの管理サーバとなる、Oracle VM Manager（OVM）が必要になります。

 

OVMでOVSを管理する環境を構築するときは、

1. OVMの構築（インストール）
2. OVMで、サーバプール を作成
3. サーバプールに対して、OVSや共有ストレージを登録する

という手順を踏みます。

 

OVMに、管理対象としてOVSを登録するときは

事前にサーバプールを作成する必要があります。

 

つまり、OracleVMとしては、基本的には「プール」ふまえて

システム構成すべき、という考えのようです。

 

 

以上。OVSのサーバプールの話でした。

 



Oracle VM Server のファイルコピーを考える

このエントリは JPOUG Advent Calendar 6日目への参加記事です。  

超無名で恐縮ですが、勢いで参加、そして勢いでブログも始めてみました。
普段は、Oracleに限らずIT技術者をやっています。
一応 11gR2 RAC Expertだったりしますが 最近仕事ではOracleと疎遠です。

今日は、私の好きな Oracle VM のIOのしくみについて考えてみたいと思います。

好きと出来るは別物なので、ちょっと違ったらすみません。（今回はPVMオンリーです）

ドメインの話。

今日は、ドメインの話です。

OVSでは、VMのことをドメインと呼んでいます。
これは、OracleVM用語というわけでなく、
仮想化エンジンとして使われているXenの用語です。

IT業界では、DNSのドメインや、Active Directoryのドメインなど
ドメインという用語が使われることが多いです。
「ドメイン」自体は 「領土」 や「領域」という意味をもっているので、
アドレスを振ったり、権限などセキュリティ的な境界を説明したりするときに
ドメインいう用語で表現すことが多いようです。
 
Xenの場合は、仮想マシンの部品となる
リソース（プロセスやメモリなど）を仮想マシンごとにまとめて、
ドメイン（領域）とよんでいるのかな、と思います。
 
 
Xen ドメインには主に2種類あります。

ドメイン0（Dom0）
 
Domain-0（Dom0）は、
他のVMを管理するために、必ず最初（ゼロ番目）に起動するので「0」ということのようです。
ただ、これ自体をVMとしてみている人はあまりいないようで、
ハイパーバイザそのものという感覚で使用している場合が多いです。
実際は他のVMと横並びの存在、一つのVMとして動いているようです。
 
 
ドメインU（DomU）
 
Domain-Uは、管理特権を与えられていないドメイン
（Domain Unprivileged。特権を割り当てられていないドメイン）という意味合いのようです。
Dom0だけに許可されている、ほかのVMを管理する権限がないVMです。
通称、ドムユーです。

また、管理用ではない、ユーザ（User）用のドメインなのでDomU
と呼ばれるという説明もあります。
 
一般的にVMと呼ばれているのは、このDomUです。
それぞれのドメインは、OracleVMの外部からアクセスすると
それぞれが独立したマシン（OS）に見えます。


 
ただ、OVSやXenを使っていて、VMのことをドメインという人は
あまりいないように感じます。

たとえば、
 
物理サーバ上に1つのDom0と、4つのDomUが稼働
 
している環境では、ほとんどの場合で
 
「物理サーバ1台のOracleVM上で4台VMを動かしてます」
 
と説明します。Dom0はほとんど空気みたいな扱いです。
OracleVMの「ドメイン」とはこんな感じの存在です。
 
あまり「ドメイン」という呼び方自体へのこだわりは
私も、他の人も そんなに無いのではないかと思いますが
OVSの仕組みを考える上では、大事な用語です。

以上、OracleVMのVMはドメインと呼ばれるという話でした。