nkjmkzk.net

サーバ仮想化環境では「リソースプール」という概念を実現するために共有ストレージ構成が多く採用されます。しかし、そもそも現在のCPU性能とDISK I/O性能を鑑みれば、そもそもDISK I/O性能はCPU性能の進化に追いついておらず、共有ストレージ構成とすれば追い打ちをかけるようにそこがボトルネックとなります。多くの環境ではこれまでの何倍ものI/O性能が必要という要件に対応するため、ミドル〜ハイエンドのストレージ装置を採用するという選択を行っています。その結果初期導入費用が高価なのはもちろんですが、そのあとも莫大な保守費を支払うことになります。そして拡張できるものの、拡張するためのパーツがまた高価、というスパイラルに陥ります。これはIT関連予算を大きく圧迫することでしょう。

そこで、これまでのストレージ構成を見直し、以下の要件を敷いて仮想化環境でのお薦めストレージ構成を考案してみました。キメの部分にOracleのストレージ管理機構を適用しています。

• コスト意識をもつ
• ユニバーサルに使用可能なこと
• スケーラビリティ- 要求に応じてキャパシティ（I/O性能、容量）の拡張が可能であること
• シンプル – OS、ソフトウェア側ではスケールアウトのためのパーティション設計が不要なこと
• 可用性 – SPOFを排除。ディスク、コントローラ、ストレージ筺体のどれが壊れてもデータ保全とオンラインを維持すること

以下ではストレージにI/Aサーバを採用していますが、応用としてローエンドなストレージ専用機という選択肢もあると思っています。

解は、コモディティなH/Wを並べる、そして高性能・高可用性・高管理性を達成するというStorage GRIDの思想に基づいた構成です。

多数のディスクを搭載できるI/Aサーバをストレージに採用

• ストレージ専用機と比較してI/Aサーバは圧倒的に安価。
• しかもカスタマイズ可能なので必要に応じて大容量のメモリ、10GbEの搭載もできる。（詳しくは後述）
• コントローラの冗長化を行うことは難しいが、それはASMの筺体間ミラーで代用できるため不要。（詳しくは後述）
• OSにはSolarisを採用。ZFS iSCSIを使ってボリュームをエクスポート。これはZFSが多様なRAIDを構成可能なこと、チェックサムによるエンドツーエンドのブロック整合性チェックが可能性でデータの一貫性維持機構が強力なこと、ファイルシステムとボリュームマネージャ、iSCSIがZFSに集約されており管理が用意なことが採用理由。

READはすべてキャッシュで捌くことを前提に大量のDRAMを搭載

• ディスクアクセスは物理的移動がともなうため絶対的に遅い。数年後には「円盤回したりヘッド動かしたりとか有り得ないっスよね」となるかも。
• メモリは数十ナノセカンドでアクセス可能。ディスクは数ミリセカンド。比較にならない。
• I/Aサーバだと構成を自由にカスタマイズできるのでDRAMを大量に搭載することができる。ZFSではDRAMをARCというReadキャッシュにすることができる。これはRead用のキャッシュをストレージ専用機の何倍も搭載できることを意味する。最近の1U, 2Uの一般的なI/Aサーバでは100GBを超えるDRAMを搭載可能。一筺体でも100GBのデータベースをすべてキャッシュすることが可能。
• サーバではなくストレージ側にReadキャッシュを持たせることにより、複数サーバ構成時のサーバ間でのキャッシュコンテンツ重複を排除することができる。
• サーバ再起動時にもキャッシュの内容がクリアされない。
• ただしウォームアップ時間には注意。キャッシュされたことを前提でサイジングを行うことになるが、もしストレージを再起動したときにはキャッシュを温めるために相当な時間がかかることになりその間の性能は劣悪になる。したがってストレージ再起動時にはサービスをオンラインにする前にデータを強制的にキャッシュに載せるようなロジックを組み込むことが望ましい。

SSDでさらなるキャッシュ容量を、より安価に

• もし、コスト的にそれほどのDRAMを購入することはできないという場合、SSDで代用させることができる。
• SSDはDRAMの延長線上に存在するようなRead用キャッシュとなり、DRAMから溢れるデータを受け止める役割を果たす。結果、DRAMと比べて安価に大容量のReadキャッシュを構築できる。

ランダムな同期書き込みをキャッシュで受け止めるためにBBWC（Battery-Backed Write Cache）を装備

• DRAM（ARC）によるキャッシュはRead用。書き込みには利用することができない（させてはならない）。
• 特にRandom Writeが発生するデータベースではREDOログの同期書き込みに要するコストは大きい。そのような環境ではBBWCの効果は絶大。ディスクへの同期書き込みを防ぎ、しかるべきタイミングでまとめてFlushするため大幅な性能向上が約束される。当然BBWC上のデータは突然のシステムダウン時も保護される。（ただしバッテリーが切れる前に起動すること）
• BBWCはRAIDコントローラ依存となるためDRAMのように大量に積むことはできないが、Readキャッシュと比較して少量でも効果が大きく、さらに後述のASMによって増設もできる。

この筺体を複数並べて、ASMによってストライピングすることでより厳しい性能要件に対応させる

• ASMとは「Grid Infrastructure」というOracleが提供するクラスタソフトウェアに付属するストレージ管理モジュール。
• ASMは並べたストレージをOS、データベースに対して「DISKGROUP」として結果的に一つに見せることが可能。

正確にはストレージでエクスポートしている論理ボリュームはOSにそのまま個別のブロックデバイスとして認識される。しかしOSはそのままそのブロックデバイスを使用するのではなく、汎用ファイルシステムとして利用する場合はASMがそのブロックデバイスから作成するファイルシステム（ACFS）をマウントして使うことになる。このファイルシステムに対して行われるI/Oは複数のブロックデバイスに分散して実行され、ストレージが複数台で構成されている場合にはデータは複数ストレージに分散される。つまり、複数台のストレージのDISK, DRAM, BBWCをフル活用できることになる。一瞬、LVMとの違いが気になるかもしれないが、まずASMはデータの「リバランス」をおこなうところが違う。ディスク／ストレージの追加／削除はオンラインで行える上、データのリバランスが自動的に行われる。また、ASMは完全にクラスターアウェアだ。LVMでも別途クラスターLVMのデーモンを設定することでクラスター化（共有）は可能だが、ASMはクラスター機構をはじめから組み込んでいる。

• DISKGROUPに対して発行した書き込みは並べた複数のストレージに対して分散して書き込まれる。DISKGROUPに対して発行した読み込みは、並べた複数のストレージから分割して読み込まれる。
• 結果、並べた複数のストレージは仮想的に一つの大きなストレージ筺体となり、（ストレージあたりのI/O性能、ディスク容量） x ストレージ台数分のキャパシティ提供することができる。これは、ストレージH/Wに依存せずI/O性能と容量を必要に応じてスケールアウト可能であることを意味する。
• また、連結されるのはディスクだけでなく、DRAM, BBWCも同様。結果、100GBのDRAMを積んだストレージを3台並べれば300GBのキャッシュグリッドが出来上がる。

ASMのストライピングモードを「2重化モード」にすることで筺体障害に対応する

• ASMはデータを分散させるだけでなく、複製しながら分散させることが可能。いわゆるネットワークRAID、筺体間ミラーの構成。
• このとき、ストレージAにあるデータはかならずストレージB（またはC）にも存在するようになるため、万一ストレージ筺体がまるごと故障／RAIDが破壊されたとしてもデータは保全される。
• それだけでなく、ストレージ筺体が故障してもオンラインで処理を継続することが可能。（ただし最低ストレージ3台必要）

圧縮でH/W投資を必要最低限に「圧縮」

• さらに圧縮機能を活用することで、必要なH/W（ストレージ筺体、DISK、DRAM、BBWC)をまさに必要最低限にできる。
• 「圧縮はオーバーヘッドがあるのでは？」と思われるかもしれなが、そもそも現在の性能課題はストレージI/Oにあることを思い出して欲しい。つまりストレージI/Oがボトルネックになれば結果としてCPU性能はあまることになる。重要なのはオーバーヘッドがあるかないかではなく、最終的にバランスのとれたシステムを構成すること。バランスがとれたときにシステムの集約密度は最大になる。そのためにはあまっているリソースは積極的に活用すべき。

FAQ. RAIDとASMの双方でデータを二重化するのは実効容量が無駄では？

• 実効容量がどうしても気になる場合は、H/W RAIDをRAID5, 6, 50等比較的容量を確保できるモードとすればよい。しかし（あくまで一般的にだが）「容量」はそれほどコストの高いリソースではない。コストが高く、実現が難しいのは高いI/O性能。繰り返しになるがCPUと同様、余っているリソースはより重要な課題（ここでは可用性）のために積極的に利用すべき。

FAQ. それほどI/O性能が気になるならDISKでなくすべてSSDにしたらどうか？

• 今回の構成は「コスト意識を持ったユニバーサルなストレージ基盤。その前提でスケーラビリティと可用性を実現する。」というもの。
• そのテーマにおいて、すべてをSSDにすることは少なくとも現時点（2010年2月）ではコストと容量の面でオールマイティとは言えない。
• 逆に「SSDは実績が乏しく、寿命や信頼性に懸念がある」という人もいるが個人的にはそうは思わない。可動部があり故障確率の高いHDDよりSSDの方がよっぽど安心だ。寿命に対する懸念も実際にその仕組を理解しないで懸念だけをうたっていることが少なくない。現時点では寿命があるのは事実だが、SLCでは素子あたり5万回の更新が可能な製品が一般的で、一部では50万回という製品もある。そして寿命については事前に知ることができるので計画的にパーツ交換すればよい。SSDに故障がないわけではないが、より故障確率が高いことが想定されるHDDの「いつ壊れるかわからない不安」に比べればSSDの寿命などかわいいもの、と思う。

XXXには各種仮想化ソフトウェアが入ると思って下さい。

お客様からOracle VMの説明の依頼をいただいたときに、ほぼ必ず訊かれるのがこの質問です。この質問にそのままご回答するのはあまり本意ではないのですが、今だと大体このようにお答えします。

1. 最新のXenをEnjoyしたいのであれば、Oracle VMが最適では。Xen 3.4採用でインストールも1CDから10分で完了。Xenの何がいいの？といわれたら、性能と実績。Xenは仮想マシンの性能を劇的に改善したHypervisor型、準仮想化モードのパイオニア。これから主流になりそうな最新のCPU仮想化機構にももちろん対応。性能には定評があり、多くの主要クラウドサービスで採用されている仮想化エンジン。また、今年リリースが見込まれるXen 4.0ではソフトウェアでFT機構を提供するRemusやPage Sharingといった先進機能満載。最近いろいろ仮想化ソフトありますが、Xenってやっぱり最高だと思う。
2. GUIが付属している。GUIがある、ないでは、マニュアルを読まなきゃ始められないか、読まなくてもある程度直感的に操作できるかという点で大きく異なる。Oracle VM Managerは最高のGUIだ！とは言いませんが（オイオイ）、便利な管理ツールであることは間違いない。Oracle VMは最新のXenを最も手軽に使い始めることができ、かつ、複数サーバを管理できるGUIがついている。
3. H/A機能が付いている。VM Serverが意図せずダウンしたときにはそのVM Server上で稼働していたVMは他のVM Serverで自動的に復旧（OS起動）する。このVM H/A機能はVMになんら手を加えずに障害時自動復旧の機構を提供するので、どんなシステムにもすぐに適用することができる。しかも、タダで。VM H/A機能まで完全にタダで利用できるのはOracle VMだけでは。そしてもしサポートが要る、と思ったらサポートも購入できる。これもまた妙に安い。
4. 最高の仮想化エンジンを使うことができて、マネージャーも付属。さらにはライブマイグレーションやH/Aというオプションまで標準で装備しており、、、ライセンスフリー。もし純粋な仮想化ソフトとして他の製品と比較したとしても、僕がエンドユーザだったらかなり気になる。もし僕が中嶋商会をスタートアップしたとして、タダでここまでやれちゃうソフトがあるのに、何百万も払って他の仮想化ソフトを購入するという選択肢はまずないと思われます。（あくまで中嶋商会だったら、の話しですよ）

と、ここまでが単に「仮想化ソフト」としてOracle VMを見た時に思うこと。しかし最初に本意ではない、と書いた通り、あまり仮想化ソフトだけで比較しても大切なことが見えてこないと思っています。最終的にはユーザーはシステムや、サービスを構築／運用するのであって、インテグレートされた姿が最も大切。VM, OS, Database, Application Server, そして監視、管理のシステムがいかにスムースに連携して、最終的に最もコストを抑えてハイパフォーマンスを発揮するかに注目したい。そこには単に「動くはず」といった理論ではなく、実際に検証を行って見い出されるベストプラクティスが不可欠で、その動作の実績というものが重要視されるはずです。例えばRACを仮想化環境上で動かすときにはいくつかの注意点があります。クラスタ間のタイマー同期の問題、ネッワークセグメントの構成方法、安全なvCPU割り当て、VBDの形式等です。Oracleではこれらのコンフィギュレーションについてベストプラクティスを提供しています。サーバ仮想化環境でRACを確実に動作させるために、というものです。Oracle VM, Oracle Enterprise Linux, Oracle Databaseそしてストレージにまたがる全システム構成について言及しています。単に各ソフトウェアレイヤについてオールスターを集めてくる、ということに捕らわれると、一番大事なチームとしてのパフォーマンスが後回しになってしまいます。最初にプレーヤーを個別に選定すると、後々「アレとアレの組み合わせがサポートされない」であるとか、「実績はあるのか？」という問題でもめることになりがちです。オールスターを集めることだけではなく、チームとしての完成度を意識することが重要だと思います。そしてOracleではこのようなベストプラクティス、ノウハウをホワイトペーパーやNoteといったドキュメントで提供しています。あるいはコンサルティングサービスという形で設計のレビューや実際の設計作業も請け負っています。そして、特筆すべきことはベストプラクティスをそのまま「VMテンプレート」という形で提供していることです。例えばOracle DatabaseのVMテンプレートは、Database用に最適化されたOracle Enterprise Linux JeOSにDatabaseがすでにインストールされた状態で提供されています。つまりVMテンプレートを使えばDatabaseのインストールという作業を省略できることはもちろん、同時にそれ以前に必要なDatabase用にOSを設定するという作業（カーネルパラメータ変更、必要なパッケージのインストール）も不要になります。これは作業工程が短縮されるということ以上に、Database用に最適化されたイメージをそのまま適用できることによる「確実なシステム構築」ということを意味しています。VMテンプレートとは最適化された「チーム」をまるごと手に入れて、すぐにゲームを開始できる、ということだと思います。もちろんVMテンプレートを使っても個別に設計が必要な部分は残ります。ストレージ周りの物理構成、論理構成等は入念な設計が必要な最たる例です。しかしVMテンプレートをうまく採用し、自社環境用にカスタマイズすることで得られるメリットは少なくないと思います。

仮想化はいまだにバブっている分野で、その中心を成すサーバ仮想化ソフトウェアには熱い視線が注がれています。しかしふと、着眼点として仮想化ソフトの選定というところから一歩引いて考えると、チームとしてどれが最高なのかという新たなパラダイムが見えてくるかもしれません。OracleはVirtualization＋GRIDという連携で最高のチームを用意しています。これは本気で最高のシステムです。（僕はこのシステムを超高密度インフラストラクチャーと呼んでいます。たぶん僕しか呼んでいません。）＊そのチームって具体的にどんな？という方はお近くの営業までお問い合わせください。

重要なのはソフトウェア？　それとも、システム？

サーバを仮想化すると必然的に一つの物理ネットワークポートを数多くのVMで共有することになりがちです。そんな環境では、セキュリティ的に（こういう表現好きじゃないんだけど）それぞれのVMのセグメントを分離したいという要件がでてきます。または、特にRAC等の検証環境で物理ネットワークポートは一個しかないんだけど、仮想マシンには最低2つのセグメントを与えたい、というような要件がでてきます。そんなときにはVLANですよね。

ということで、Oracle VM環境でVM Serverには物理的なネットワークポートは一つしかないけど、VLANで二つの仮想ネットワークポートを作成して仮想マシンに2つのネットワークセグメントへの接続を与えるという設定方法を紹介します。RACでは最低でもPublicとPrivateの二つのセグメントが必要になるのでそういう場合に便利です。

＊ちなみにOracle VMはバージョンによって内部仮想ネットワークの構成がちょいちょい変わっていますが、この手順は2.1.xでも最新の2.2でもいけるはずです。

＊タグVLAN（802.1q）を使用するので、VM Serverを結ぶネットワークスイッチも適切に設定する必要があります。

まずxend-config.sxpを編集してネットーワーク設定の初期化を行うnetwork-scriptを変更します。

[root@vmserver]# cd /etc/xen/xend-config.sxp
(network-script network-bridge-ovs)

次に先程指定したnetwork-bridge-ovsを作成します。これは実際にはダミーです。つまりVLANを構成する場合は通常のネットワーク初期化機構を放棄するという設定を行っているわけです。

[root@vmserver]# vi /etc/xen/scripts/network-bridge-ovs
#!/bin/sh
/bin/true

そしてVLAN用に仮想スイッチの設定ファイルを作成します。各VLAN毎にxenbr（仮想スイッチ）を作成します。xenbrNNのNNの部分は任意ですが、VLAN IDと紐付けておくのが吉でしょう。ここではVLAN ID:11と、VLAN ID:12に対応するxenbrを作成しています。

[root@vmserver]# vi /etc/sysconfig/network-scripts/ifcfg-xenbr11
DEVICE=xenbr11
ONBOOT=yes
TYPE=Bridge
DELAY=0
STP=off
BOOTPROTO=static
IPADDR=10.0.11.1
NETMASK=255.255.255.0

[root@vmserver]# vi /etc/sysconfig/network-scripts/ifcfg-xenbr12
DEVICE=xenbr12
ONBOOT=yes
TYPE=Bridge
DELAY=0
STP=off
BOOTPROTO=static
IPADDR=10.0.12.1
NETMASK=255.255.255.0

次にVLANインターフェースを作成します。ここではeth0上にVLAN ID:11とVLAN ID:12となるインターフェースを作成しています。このときのeth0.NNのNNがVLAN IDの指定になります。単なる名前ではなくVLAN IDの設定になるので、ここの設定と物理スイッチでのVLAN設定は合わせる必要があります。そして各VLANインターフェースは先程作成した対応するxenbrにそれぞれ接続します。

[root@vmserver]# vi /etc/sysconfig/network-scripts/ifcfg-eth0.11
DEVICE=eth0.11
BOOTPROTO=none
ONBOOT=yes
BRIDGE=xenbr11
VLAN=yes

[root@vmserver]# vi /etc/sysconfig/network-scripts/ifcfg-eth0.12
DEVICE=eth0.12
BOOTPROTO=none
ONBOOT=yes
BRIDGE=xenbr12
VLAN=yes

これで完了です。VM Serverを再起動すればxenbr11が作成され、そこにeth0.11が接続されます。また、xenbr12が作成され、eth0.12がそこに作成されます。

ゲストOSの仮想ネットワークインターフェースを作成するときは、xebr11を指定すればVLAN 11に、xenbr12を指定すればVLAN 12に接続されます。

少し独断と偏見が入っていますがつれづれなるままに。

• up2dateコマンドでULN (Unbreakable Linux Network) へ登録（サポートを購入してないと登録できません）
• ＊サポートを買ってない人はhttp://public-yum.oracle.com/repo/EnterpriseLinux/EL5/3/base/i386/からOEL5.3のパッケージをインストールできます。後述のvim-enhancedとか。
• ULNにログインし、登録したシステムのサブスクリプションに以下のチャネルを追加
  • Enterprise Linux 5 update 3 installation media copy (i386)
  • Enterprise Linux 5 update 3 patch (i386)
• vim-enhanced、screenをインストールし、.bashrcを編集してalias vi=’vim’とする

[root@vmserver]# up2date vim-enhanced screen

• up2date –configureで19番をクリアする
• up2date –updateでパッチをすべて適用

また思いついたら都度更新します。

注）2010年1月現在、OpenSolarisはOracle VMのゲストOSとしてサポートされていません。

Oracle VM 2.2上でOpenSolaris 2009.06をPVM（準仮想マシン）としてインストールする方法を紹介します。まだプロトタイプという位置づけではあるものの、実はOpenSolaris 2009.06にもいわゆるVMテンプレートが存在します。今回はそのテンプレートを使ってOpenSolarisのPVMを作成します。まずはVMテンプレートをダウンロードします。

OpenSolaris 2009.06 JeOS Prototype VM Images

このページからXen用のPVMイメージをダウンロードします。直リンはこちら。（直リンって久しぶりだな。。）

Xen: Oracle VM, OpenSolaris xVM, etc.KVM: (In XEN HVM mode)

そしてこのイメージは7zipという少し耳慣れないツールで圧縮されています。以下のページからご自身のプラットフォームに応じたモジュールをゲットしてインストールしてください。

http://www.7-zip.org/download.html

僕はp7zip for POSIX/Linuxをダウンロードしてビルドしました。そして使い方で一点ハマリポイントがありました。深く考えずに/usr/local/bin/7za e osol-0906-jeos-proto-xvm-zen-para.7z などとしていたのですが、eだと現在のディレクトリ直下にすべてが解凍されてしまい、サブディレクト内に何にもねぇ！ってことになってしまいます。p7zip for POSIX/Linuxを使われる方はくれぐれも/usr/local/bin/7za x osol-0906-jeos-proto-xvm-zen-para.7z で解凍してください。他のプラットフォームはわかりません。また、Oracle VM Serverにはgcc等の開発キットは含まれていないのでmakeはできません。7zipは他のプラットフォームにインストールしてVMイメージは解凍してからVM Serverに格納するのが吉でしょう。

解凍してできたディレクトリをVM Serverの/OVS/running_pool/直下に保存します。

[root@vmserver]# pwd

/OVS/running_pool

[root@vmserver]# ls

OSOL0906JeOSProto

次に設定ファイル生成スクリプトを編集します。というかこのスクリプトを編集して設定ファイルそのものにしたらいいんじゃないかという気もします。どっちでもいい話ですが、結果的に以下のファイルを作成します。（ファイル名はvm.cfgでなくても良いのですが、Oracle VMの慣例にならってvm.cfgとしておきます。

[root@vmserver]# cd OSOL0906JeOSProto/

[root@vmserver]# vi vm.cfg

name = "OSOL0906JeOSProto"

vcpus = 1

memory = "768"

disk = [

'file:/OVS/running_pool/OSOL0906JeOSProto/System.raw/vdisk.raw,xvda,w',

'file:/OVS/running_pool/OSOL0906JeOSProto/instance.raw/vdisk.raw,xvdb,w'

]

vif = ['type=netfront,bridge=xenbr0,mac=00:16:3e:00:00:01']

on_shutdown = "destroy"

on_reboot = "destroy"

on_crash = "preserve"

あとはxmコマンドで以下のように起動すればOpenSolarisがPVMとして起動します。

[root@vmserver]# xm create vm.cfg -c

ただしこのOpenSolaris、Just Enoughと名乗るだけあってほんとに軽量版です。汎用的に利用するにはいろいろとパッケージを追加する必要があるでしょう。しかし手元の環境ではsshがうまく起動せず、疲れてきたので作業終了しました（オイオイ）。

どなたかこのJeOSでsshを普通に起動する方法をご存知でしたら教えてください。

1/26追記：/lib/svc/method/sshd -cしておくと起動できました。@satokazさん、有難うございます！

ここまで書いておきながらなんですが、僕は普通にvirshを使ってPVMをインストールしようと思います。その手順はまた後ほど。

いつも本体のNew Versionリリースと若干時差があって恐縮なのですが、Oracle VM 2.2用のVM Managerテンプレートがリリースされました。

http://www.oracle.com/technology/products/vm/templates/vm-manager.html

ちなみに今までの2.1.5用のVM Managerテンプレートは2.2の環境ではそのままは使えないのでご注意を。今回リリースされた2.2用のテンプレートをお使いください。

今日は遅い時間にも関わらずかなり多くの方々にお越しいただけ、感謝、感謝です、有難うございました！

今日の資料、というか投影していたスライドをUPしました。残念ながらココが味噌、の性能部分についてはご案内させていただいた通り、公開できないため間引きさせていただきました。ごめんなさい。

Catch Up !! Oracle VM 2.2

Storage GRID詳解

来年、2月18〜19日にDevelopers Summit 2010が目黒雅叙園にて開催されます。

8つのテーマで構成されており、僕はその中の「Cloud Development」で1セッション担当します。

オラクルのエバンジェリスト2人が考えるクラウド・プラットフォーム

今回はFusion Middlewareのエバンジェリスト、佐藤直生さんとともにオラクル的クラウドプラットフォームを語ります。このセッションでは単位「クラウドとは？」という概念的な話しに終始するようなものではなく、「で、具体的にそれをどうやって実現すんの？」というところに踏み込んだ話をしようと思っています。

まだ少し先ですが是非ご予定空けておいてください！

年明けの1月21日にオラクル青山センターでOracle VMのセミナーを開催します。いわゆるEvening Seminarという形で、普段日中お忙しい方にも来ていただけるように18:00という少し遅い時間からの開始です。

2セッション構成で、前半のセッションではOracle VMの最新バージョン2.2をベースとしたOracle VMの基本的なコンポーネントのご説明、最新バージョンで追加された機能の解説に加え、性能についていくつかの検証結果の紹介を行います。後半のセションでは仮想化環境で特に重要な設計ポイントであるストレージに焦点を当て、仮想化環境で課題となるストレージ設計についてOracle的考え方、実装方法を検証結果を交えて解説します。

お申し込みはこちらから。

Catch up !! Oracle VM 最新バージョン2.2の実力検証& 仮想化アーキテクチャの要[Storage GRID]詳解　(2セッション　合計2時間)

2010年2月4日にOracle VM Forum 2010を大阪で開催します。

http://www.oracle.co.jp/events/osk100204/

これは基本的には先日東京で行ったOracle VM Forum 2009の大阪開催という形ですが、新しいセッションを一つ設けています。3つ目のセッション「Storage GRID詳解」がそれです。このセッションは前のエントリで最後に触れたヤツです。

Storage GRID詳解

仮想化環境ではストレージが非常に重要な設計ポイントとなります。サーバ集約によってこれまで以上に不足しがちなI/O帯域／スループットをどのように確保すればいいのか？　負荷の増加にあわせて拡張できるスモールスタート構造とは？　ディスク障害のみならずストレージ筐体そのものの障害にも耐え得る冗長構成を達成するにはどうすればよいのか？
Oracleではこれらの課題に対してサーバと同様にストレージを「並べる」（Storage GRID）というアプローチをとっています。
このセッションではこのStorage GRIDのアーキテクチャと構成方法を解説し、性能拡張、障害時の挙動、運用のオペレーションについて検証レポートを交えながら詳しく説明いたします。

関西の皆様、ぜひぜひご来場を。

また、東京でも1月に別の形でこのセッションを行おうと思っています。おそらくOracle VM 2.2最新UPDATEと、このStorage GRID詳解の2本立てで開催することになると思います。こちらもFixしたらご案内しまっス。