nkjmkzk.net

powered by Kazuki Nakajima

Archive for 4月, 2010

XenのPCI-Passthroughとは?そのユースケースは?

PCI-Passthroughとは、PCIデバイスをごっそりdomU(ゲストOS)に「あげちゃう」手法です。ちなみにPCIデバイスとは主にディスクコントローラであったり、HBAであったり、ネットワークカードであったり、あるいはグラフィックカードであったりします。わかり易くするためにPCIデバイスをディスクに絞って話を進めます。通常XenではディスクをdomUに割り当てる際にはdom0が物理ディスクを一度認識した上で、そのディスクリソースを分配する形でdomUに割り当てるVBD(Virtual Block Device)という形式をとります。

例えばサーバにSATAディスクが接続されているとします。これはオンボードまたは拡張PCIカードのSATAコントローラにSATAケーブルで接続されています。このディスクがdomUに認識される道筋を通常のVBD形式とPCI-Passthroughとで比較したのが下図です。

通常のVBD割り当て

スクリーンショット(2010-04-25 20.13.03)

  • ディスク(PCIデバイス)はdom0によって管理され、複数のdomUで共有できる
  • domUからのディスクアクセスはdom0を経由して物理デバイスに到達する(一般的に性能劣化が発生する)
  • domUはデバイスドライバを使用しない(厳密にはdom0が提供するダミーデバイスと通信するためのドライバを使用する)

PCI-Passthroughの場合

スクリーンショット(2010-04-25 20.13.32)

  • PCI-Passthrough対象のSATAコントローラ(PCIデバイス)はdom0に認識させない
  • PCI-Passthroughを行うdomUがSATAコントローラ(PCIデバイス)を独占する
  • PCI-Passthroughを行うdomUからのディスクアクセスはは自身のデバイスドライバを使用して直接SATAコントローラ(PCIデバイス)、ディスクに到達する(dom0経由によって発生していた性能劣化から解放される)
  • domUとローカルマシンのデバイスとの静的な紐付けが行われるため、ライブマイグレーションが出来ないといった制約が発生する

ひとことで言えば、

  • PCI-Passthroughを使用すればdomUのディスクアクセスは高速になるが、そのデバイスは一つのdomUによって独占されてしまう。

ということになります。環境によってこれが使えそうかどうかはそれぞれだと思いますが、SATAコントローラが丸ごと一つのdomU専用になってしまうのでは収容できる仮想マシンの台数が大幅に制限されてしまいます。

*厳密には単一のSATAコントローラでもポートがハブ形式になっており複数のPCI識別子(BDF)が割り当てられていることもあるのでその場合はこの限りではない

仮想化とはそもそもH/WとOSを疎結合にすることが大きなメリットの一つでした。その中でPCI-Passthroughのような密結合を引き起こすコンフィグレーションはどのようなシチュエーションで有用なのでしょうか?

僕が考えるユースケースの一つはNASのバーチャルアプライアンスを稼動させる場合です。実際、NexentaStorのようにNAS(NFS, iSCSI)を仮想マシンとして構成することができる製品が存在します。そのような製品では仮想マシンとして高速にディスクにアクセスすることがマストの要件になってきますし、NASバーチャルアプライアンスが使用するディスクを他のdomUと共有するといった必然性は恐らくないでしょう。したがってNASバーチャルアプライアンスのような製品ではPCI-Passthroughは理想的なコンフィグレーションだと思います。

「仮想マシンでNASを構成しようなんて思うか?」という意見が聞こえてきそうですが、例えば僕は今その必要性に迫られています。限られたサーバ資源をフルに活用してフルスペックの仮想化環境を自宅に構築したいと思っています。しかしストレージ専用機、なんてもってのほかですし(費用、スペース、音、電力、等々)、サーバを丸ごとストレージにするのも勿体ない。そんなとき、OpenSolarisのZFSを使ったNASを仮想マシンで構成できればとても効率的ですよね。でも仮想マシンだとI/O系のパフォーマンスに不安がある。そんなときに!このPCI-Passthorughがソリューションになります。具体的にはOpenSolarisをEPT, VT-dが有効なサーバ上にPVHVMとして作成します。そしてSSDをPCI-PassthroughでOpenSolaris PVHVMから直接I/Oできるようにすればベアメタル上のネイティブOSと遜色ないパフォーマンスが確保できます。メモリアクセスや演算処理もVTテクノロジで実際非常に高速に動作します。ネットワークについてもPCI-Passthroughすることは可能ですが、手元の環境ではNICが豊富にあるわけではないのでネットワークアクセスについてはdom0から割り当てたVIFをPVドライバで高速化するという構成です。(そもそも通信は同筐体内という前提ですし)そして同一サーバ上の他のdomUはこのOpenSolaris PVHVMのZFS上に作成します。ZFSの機能を存分に活用してスナップショットによるバックアップ/ロールバック、クローンによる高速プロビジョニング、圧縮、重複排除などの高度なストレージ技術がすべて利用できます。それも物理的にはサーバ一台というオールインワンで。検証環境としては最高に高密度なシロモノとなります。

スクリーンショット(2010-04-25 20.45.57)

また、僕のような変テコな検証環境だけでなく、これからI/Aサーバをストレージとして使用する「Open Storage」という実装が世に広がってくるようになれば、このような構成がフィットするケースが増えてくるのではないかと考えています。

それでは別エントリでこのPCI-Passthroughの構成方法を解説しようと思います。

without comments

Written by 中嶋 一樹

4月 25th, 2010 at 8:36 pm

Posted in Uncategorized

Tagged with ,

pbzip2でマルチコアをフル活用して圧縮しよう

普通のbzip2やgzipでは圧縮が1スレッドで行われます。つまりCPUコアがいっぱいあってもそのマルチコアを活かした圧縮処理ができません。例えばコンパイル処理ではmake -j8などとすることで8スレッドで並列実行することができ、ビルド時間を大幅に短縮できます。これと同じ要領でマルチコアをフル活用して圧縮したい人にはpbzip2がおすすめです。

pbzip2オフィシャルサイト

各OSディストリビューション用にPre-Builtパッケージもあるようですが、今回はソースからビルドします。ビルドにはc++コンパイラ(gcc-c++)とbzip2-develが必要なのでインストールしておきます。これはredhat系ディストリビューションであればyumとかで標準のレポジトリからインストールできます。

そしてまずはpbzip2をゲットします。

$ wget http://compression.ca/pbzip2/pbzip2-1.1.1.tar.gz

展開、解凍して、

$ tar xvfz pbzip2-1.1.1.tar.gz

ビルド、インストールします。

$ cd pbzip2-1.1.1.tar.gz
$ make
$ sudo make install

これでインストールは終了。使ってみましょう。僕は通常ディレクトリ毎tar cvfjで圧縮することが多いので、これと同義のコマンドを一例として。

tar cvf [圧縮後のファイル名] --use-compress-prog=pbzip2 [圧縮するディレクトリ]

こんな感じです。手元のマシンはクアッドコア with HT enabledでOSからは8コア見えている状態ですが、上記コマンドを発行すると最適なスレッド数が自動検出されて8スレッドで実行されます。CPU使用率は700%強となり、全コア・スレッドが活用されていることがわかります。

そして気になる性能ですが、4GByteのスパースファイルをdd if=/dev/zero of=test.img bs=1M count=0 seek=4000として作成し、これを普通のbzip2とpbzip2で圧縮して所要時間を比較してみました。

bzip2vspbzip2

クアッドコアのマシンなので完全に並列実行できれば処理時間は理論上1/4になることが期待されますが、それを若干上回る程の性能がでてます。これはイケてる。

マルチコア圧縮は仮想マシンファイル等かなり容量の大きいファイルを圧縮するときには非常に重宝します。これからの時代に必須のツールですね。

without comments

Written by 中嶋 一樹

4月 24th, 2010 at 4:36 pm

Posted in Uncategorized

Tagged with

今さらですが、「ASMとは?」をあらためて。

ASM、の前に、まずStorage GridというOracle社が考える理想的なストレージ構成についてですが、Storage Gridとは安価な単機能ストレージを並べてストレージI/O性能・容量をスケールアウトさせる、そして可用性を確保するというストレージ構成のことです。

高性能が必要になったとき、サーバ側はクラスタ、レプリケーションといった形で並べてスケールアウトさせることがコモディティ化してきています。これは、ハイエンドマシンを擁して単一サーバでスケールアップを図るより、ローエンドマシンを並べた方が同性能を圧倒的に安価に引き出せる、というのがそのコンセプトの根底にあります。

それではストレージはどうか?というとサーバ程「並べる」という考え方は浸透していないと思います。特にエンタープライズ環境ではその傾向が顕著でしょう。企業は高価な専用ストレージ装置にかなり出費しています。だったら、ストレージもサーバと同じように並べる構成にすればいいんじゃないの?というのがStorage Gridの発想です。ごく自然な着想ですよね。

*ちなみこの辺に関連記事があります。

サーバ仮想化環境でのお薦めストレージ構成 at nkjmkzk.net

OracleではこのStorage Gridを体現する実装としてASM(Automatic Storage Management)という製品を提供しています。これはサーバ側にインストールするソフトウェアで、下記のことが可能になります。

  • 複数ストレージを連結して一つの大きなボリュームを構築する
  • 複数ストレージ間でデータを冗長化し、ストレージ装置の障害時にも完全なデータアクセスを可能にする
  • 需要に応じてオンラインでストレージを追加/削除できる
  • 追加・削除を行った際、ドライブ上のデータは新しい構成に応じて自動的に再配置される
  • 複数クライアントからのアクセスを同時に処理できる(つまり共有ボリュームとして利用できる)
  • ASMが提供するボリュームはデータベースの他、ファイルシステムでフォーマットしたりと汎用的に利用できる

20100330174146

従来ASMはOracle Databaseの一部であり、Database専用のボリュームマネージャでした。しかし現在ASMはDatabaseではなく「Grid Infrastructure」というパッケージに含まれるソフトウェアとなっており、Databaseとは独立してインストールして使用可能です。当然引き続きDatabaseのボリュームとしても使用可能ですが、Database以外の汎用的な用途に利用可能となっています。下図のようなイメージです。(ASMはサーバにインストールして使うソフトウェアです)

ASMとACFS

そして気になるライセンス費用ですが、驚くことにGrid Infrastructureはそれ自体にライセンス費用はかかりません。ざっくり言うと、利用自体は基本的にフリーで(一部スナップショット機能等に制限あり)、サポートが必要な場合はUBL(Unbreakable Linux)契約またはDBのサポート契約を締結していただくということになっています。下記はマニュアルからの抜粋です。

Oracle Grid Infrastructureの以下のコンポーネントは、スタンドアロンのサーバーでもクラスタ構成でも無償で使用することができます。

  • Oracle Automatic Storage Management(Oracle ASM)
  • ASM動的ボリューム
  • ASMクラスタ・ファイルシステム(ACFS)(ACFSスナップショットとその他の付加機能を除く)
  • クラスタ構成において、ASM/ADVM/ACFSのサポートのためのみに使用されるOracle Clusterware
  • スタンドアロンのサーバーで、Oracle DatabaseとOracle ASMのためだけに使用されるOracle Restart

それに加えて、Oracle Clusterwareは、次のいずれかの条件を満たす場合において、アプリケーションを保護する(障害発生時のアプリケーションの再起動またはフェイルオーバー)用途で、無償で使用することができます。

  1. サーバーOSが、有効なOracle Unbreakable Linuxサポート契約でサポートされていること。
  2. 保護対象の製品が次のいずれかであること。
    • オラクル社によって提供された製品(例: Oracle Applications、Siebel、Hyperion、Oracle Database EE、Oracle Database XE)
    • 直接または間接的にOracle Databaseにデータを格納するサード・パーティ製品
  3. クラスタを構成する少なくとも1台のマシンに対して、Oracle Database Enterprise EditionまたはOracle Database Standard Editionのライセンスが購入されていること。

クラスタは、同じOracle Cluster Registry(OCR)および投票ディスクを共有するすべてのマシンが含まれるものと定義されています。

リファレンス:http://download.oracle.com/docs/cd/E16338_01/license.112/b56284/editions.htm

*ちなみに余談ですがOracle Unbreakable Linuxサポートを契約すると他にもEnterprise ManagerのLinux Management Packが利用可能になります。これはOSの監視、インベントリ管理、パッチ適用/アップデート等が一元的に行えるツールです。

ASMを採用したStorage Grid構成と、これまでのスケールアップ型のストレージ構成を性能・可用性・コストの観点で一度比較検討してみてはどうでしょうか。ただしこのようなストレージの組み方は多くのエンジニアにとってこれまでとはことなるやり方、で、気にはなるけどちょっと不安、という人も多いでしょう。そういうときは日本オラクルにご相談ください。出来る限り善処致します。

with one comment

Written by 中嶋 一樹

4月 7th, 2010 at 8:47 pm

Posted in Uncategorized

Tagged with ,