2012年12月6日木曜日

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

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

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

今日は、私の好きな Oracle VM のIOのしくみについて考えてみたいと思います。
好きと出来るは別物なので、ちょっと違ったらすみません。(今回はPVMオンリーです)

※Oracle VMといっても、VortualBoxの話ではなく、Xen仮想化エンジンを使っているOracle VM Server の話です。 
  for x86(Linux版)を意識していますが、SPARC版も同様です。

いきなりですが、こんな経験ありませんでしょうか。
 
「仮想マシンのバックアップを取ろうとして、
Oracle VM Server(OVS)にログインして ファイルをtar gzip したら上のVMがスローダウン。
ゲストOSがフリーズしているように見える。」

こんなときに、裏で何が起きているのか考えてみます。

Oracle VM Serverでのファイルコピーについて

まず、サーバ仮想化の世界でのファイルコピーは2種類が考えられます。
  • 仮想マシン内(VMの中)でのファイルコピー
  • 仮想化ソフト内(VMの外側)でのファイルコピー

イメージは、こんな感じです。ここでの仮想化ソフトとは、OracleVMServerのことです。
OVSとVMはざっくり描いてみました。




ちょっと OVS的に見てみる

 このイメージをもうすこしOVS的に分解して考えてみます。
OVS(=Xen)には、Dom0と呼ばれる管理用VMがいます。
一般的に「VM」と言われるものは、このDom0によって起動停止されます。
OVSにコンソールやsshでアクセスするとき、
ログインしてコマンドを打てるLinuxっぽい(というかLinux)環境は、じつは Dom0 です。

もう一つ。
OVSがVMに仮想ディスクを割り当てるとき、まずDom0にディスクを認識させます。
そのうえに Dom0 から見えるファイルとして、VM用の仮想ディスク(OSイメージや ゲストOSから見た /u01 などになる)を作成し、VMに使用させます。



さらに OVS的に見てみる。

実はOVS環境では、Dom0がVMのディスクのRead/Writeを担当しています。
Dom0と、それ以外のVMとは横並びの存在なのですが、Dom0は他のVMとは違った特権を持っています。他のVMのディスクへの読み書きをかわりに処理するのです。
図中で「Front」「Back」と書いているのは、ディスクIOを処理するためのドライバです。
VMの処理を正面から受け取る「フロントエンドドライバ」と
それを、裏側のDom0側で受け取る、「バックエンドドライバ」がセットで動いています。
これは、スプリットドライバ(分割されたドライバ)ともよばれ
Xenの特徴的なアーキテクチャです。


上の図の補足になりますが、
 VMでなにかIO処理が発生した場合・・・
  1. まずVM上のアプリケーションは、普通にOSに対してデータの書き込みを依頼します。
    たとえば、Oracleがデータベースに書き込みをした場合、Oracleは普通にOSに対してデータの書き込みを依頼します。
  2. このとき、OVS上のVMにインストールされているフロントエンドドライバが
    Dom0 のバックエンドドライバに書き込みを依頼します。
  3. Dom0では、バックエンドドライバから受け取った書き込み依頼を
    Dom0自身がもつLinuxドライバで、ディスクに書き込みます。
複数のVMからのIOは、こんなイメージになります。
Dom0は、このように他のいくつかのVMからの処理をさばくことは得意なようです。


複雑な仕組みですが、Xenの世界では、
この仕組みを取ることで
  • IOを仮想化に合わせた方法で処理して性能UP。(準仮想化。PVM)
  • もともとあるLinuxのドライバをうまく流用して使う。
といったことを狙っているようです。

ただし、Dom0 は自分自身のIO処理にはそんなに強くない ようです。
Dom0は他のVMのIO処理をさばく(下の図の緑/黄色の→)のはあるていど得意ですが、
自分自身のIO処理で負荷がかかったりすると、けっこう弱いです。
たとえば、
Dom0 自体が大容量ファイルのコピー(下図の赤い→)をしたりすると、
他のVMの処理をしてくれなくなったりします。
このとき、負荷が大きいと他のVMはフリーズしたように見えることもあります。
これが、冒頭でふれた状況の裏側になります。


どのような時に気にするのか?

例を一つ挙げると、IO負荷が大きい「バックアップ処理」があります。
たとえば、Oracleの稼働しているVMをバックアップするとして、
VMの何を、どこからバックアップするかを考える必要があります。
バックアップ対象とするのを、ファイルか、OSイメージか、DBのデータかと
と考えるわけです。そして、VM側、Dom0側どちらから取得するかも考えます。

VM側からのバックアップ
VM内(ゲストOS内)でコマンドを実行してバックアップします。
たとえばOracleの稼働しているVMなら、VM内からの
  • cp, tar, gzipコマンドなど(OS部分、DB部分どちらでも)
  • Linuxでのdumpコマンド(OSファイル、DB部分どちらでも)
  • データベースファイル コピー(DB)
  • RMAN(DB)
  • imp/exp(DB)
  • DataPump (DB)
などを使うと思います。
(単純に考えるためにOS/DB区別しかしていませんが)
普通の物理Linuxサーバと同じバックアップの仕方です。
一般的に、Dom0 側からのバックアップよりも
他VMに対する影響を少なくすることができます。

Dom0側からのバックアップ
Dom0でログインして、コマンドを実行する方法です。
  • Dom0でのcp, tar, gzipなど(OSのイメージファイル"xxxx.img"をそのままコピー)
といった方法などです。
物理Linuxの入っているハードディスクを丸ごとコピーするような感じです。
とにかく、バックアップもリストアも、ファイルコピーだけなので簡単です。

では、どうしたらよいのか?

引き続き、バックアップを例として説明します。
サービス提供目的でシステム稼働させている場合は
ほかのシステム(VM)に影響を出さないように
VM側からのバックアップを検討することがあります。
検証環境など、サービス提供していない環境でOVSを使っている場合は、
他の仮想マシンに迷惑をかけてもよいことが多いので
ほとんどDom0側でバックアップを取ると思います。

といったように、他VMへの影響と、便利さを天秤にかけてバックアップの方法を考えることが多いはずです。また、OVSだけでなく、ほかのハイパーバイザでも同じように考えます。

会社で怖い人と共用で検証VM環境を使っているときは、
あえてVM側からファイルコピーをして、隣のVMへの影響を小さくしたりする
といった感じです。 

Dom0のために考えられること 

最後におまけてきな話ですが・・・
もともと仮想化環境ではIOがボトルネック(処理性能の問題点)になることが多く、
Dom0側のIO処理負荷に対しては、下記のような対策があります。
  • OCFS2 の reflink機能
  • Oracle VM Server ユーティリティサーバ
  • ストレージ装置のスナップショット & ボリューム複製
  • など
IO性能はどうしても問題になるんで、
いろいろなレイヤで、いろいろな対策がとられています。
(バックアップにしても、結局ストレージ側の機能でとることが多い気も・・・)


以上、OVSの話でした。
わりとマイナーな部類とおもわれるOVSですが、
すこしでも好きな人が増えてくれるとうれしいです。

明日は Keiji Oda さんです。よろしくお願いします。

0 件のコメント:

コメントを投稿