nkjmkzk.net

powered by Kazuki Nakajima

Archive for 12月, 2009

Developers Summit 2010

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

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

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

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

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

with 3 comments

Written by 中嶋 一樹

12月 23rd, 2009 at 11:29 am

Posted in Uncategorized

年明けにオラクル青山センターでOracle VMセミナーやります

年明けの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時間)

without comments

Written by 中嶋 一樹

12月 16th, 2009 at 11:17 am

Posted in Uncategorized

Tagged with

Oracle VM Forum 2010 in 大阪

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したらご案内しまっス。

without comments

Written by 中嶋 一樹

12月 9th, 2009 at 4:31 pm

Posted in Uncategorized

Tagged with ,

仮想化環境ではiSCSIとFibre Channel, どっちがお薦め?

よく「仮想化ではストレージはどの接続形態がお薦めですか?」と質問を受けます。つまりはFC (Fibre Channel), iSCSI, NFSのうち、どれ?ということです。今回はNFSは置いといてFCとiSCSIについて考察してみます。

多くの場合争点となるのは以下のポイントだと思います。

  • 性能

一般にFCの方が性能的に優れていると認識されています。これはFC DiskかSAS Diskかというディスクの違いもありますが、明らかに違うのはネットワークの帯域でしょう。iSCSIが利用するバックボーンはEthernetであり現在ほとんどのiSCSIネットワークは1GbpsのEthernetで構成されています。10Gbpsの機材も販売されはじめていますが、コストがまだまだ高いのが現状です。一方FCのネットワークでは4Gbpsが主流で、理論値ではGigabit Ethernet約4倍の差があります。(また、8GbpsのFCも出てきつつありますね) ということでそもそもはこの帯域の差をもって「iSCSIだと性能が不安だ」ということになっていると思います。

*ドライバの安定に関する不安も少しあるかもしれませんね。

10Gbpsを使わない限りこの差があるのは事実ですが、ストレージの性能とはネットワーク帯域だけではありません。ストレージの性能にはボトルネックになり得るポイントがいくつかありますよね。

①サーバ側のネットワークポートの帯域幅

②ストレージ側のネットワークポートの帯域幅

③サーバのCPU

④ストレージのコントローラ

⑤ストレージのディスク

この中で①と②の「ネットワーク帯域幅」がiSCSiとFCで性能に明らかな差がある部分です。しかしこの中には帯域幅よりも先にボトルネックとなりがちなポイントがあります。

⑤ストレージのディスクです。

ディスクの本数にもよりますが12本程度のディスクでランダムRead/Writeの負荷をかけると、帯域幅という面では1Gbpsにも到達しないでしょう。実際はストレージには複数のポートが装備されているので帯域的にはかなり余裕のある状態です。となるとFCとiSCSIの差はなくなります(ディスク自体がFC, SASと違う場合にはその部分は依然として残る)。実際とあるストレージ機器ではFCモデルとiSCSIモデルでシーケンシャルRead/WriteではFCが勝るものの、ランダムRead/Writeではどちらも同じIOPSになっています。となると「うちはストレージの負荷がかなり高いからiSCSIなんて無理だよー」と思っている人もその負荷がランダムRead/WriteであるならばFCにこだわるよりもより「ディスクの本数を増やす」ことに注力すべきでしょう。あるいはSSDというのも熱い選択肢だと思います。

  • コスト

FCストレージ自体がそもそもはハイエンドというイメージがあり、iSCSIは廉価というイメージがあります。実際はFCストレージでも価格のこなれたローエンドの機種も存在します。しかしFCスイッチやHBAはEthernetのL2スイッチやNICと比べて相当に高価であることは間違いありません。HBA等はたかだかカードだと思って見積もりをとってみるとその価格に驚きます。結果的にFCの方がコスト高になる傾向にあることは事実だと思います。

そしてこれはあまり注目されることはありませんが、特に仮想化環境で重要な要素に「管理性」があると思っています。

  • 管理性

例えば一つのVM Server(ホストの方)上で20個のゲストOS(仮想マシン)を起動するとします。そしてそれぞれのゲストOSに対して専用のボリューム(Logical Unit)を作成して割り当てる場合、2通りの方法があります。一つは一度dom0でボリュームを認識し、それをゲストOSに貸し出す方法。これはFC, iSCSIともに可能です。もう一つはdom0は関知せずゲストOSが直接ストレージに接続してボリュームを認識する方法です。

詳しくはこのあたりの記事をご覧ください。

http://www.oracle.com/technology/global/jp/pub/jp/seminar/nakajima_ovm_bp1.html

後者はPCIパススルー等の特殊な手法を除いてFCでは実装できません。iSCSIのみで実現可能です。後者はdom0で貸し出すボリュームをマネージする必要がなくなるので管理作業(ボリュームをゲストOSに貸し出すという作業)を一つ省くことができ、よりシンプルです。そして重要なのがアクセス制御です。前者のdom0でボリュームをマネージする形態では20個のゲストOS用のボリュームをすべてdom0が「仕分け」しなければいけません。このボリュームはこのゲストOS、このボリュームはこのゲストOS・・・といった具合です。数が多くなるほどオエッとなる作業ですよね。一方iSCSIであればイニシエータIQN等で簡単にアクセス制御をかけることができます。つまりあらかじめストレージ側でボリュームの設定さえしておけば、すべてのゲストOSは同じようにストレージに接続するだけで自分用の領域だけが見える、という状態にできます。この場合仕分けは必要なくなるのでかなり管理が楽になるはずです。Linuxでは通常iSCSIイニシエータIQNはOS毎にランダムな値が自動生成されて/etc/iscsi/initiatorname.iscsiに設定されています。ただしこれは任意に設定することが可能です。僕は自分のVMテンプレートに、起動時にホスト名を元にイニシエータIQNを自動設定するロジックを組み込んでいます。例えばnkjm-001というホスト名だとすると、/etc/iscsi/initiatorname.iscsiは起動時に次のように自動生成されます。

InitiatorName=iqn.com.oracle.jp:nkjm-001

そうすることでいちいちゲストOSのイニシエータIQNを調べなくても、あらかじめ予測してストレージ側で設定しておくことが可能です。

*ちなみにこのイニシエータIQNによるアクセス制御は「セキュリティ」を意識したものではなく、「適切なボリュームに間違いなく接続するため」のものです。セキュリティを意識するのであればさらにCHAP認証等が必要でしょう。

ということで僕は特にFCを必要とする要件(シーケンシャルReadだらけ。帯域命。みたいな。)がない限りはiSCSIの方がお薦めだと思っています。

ただしサーバ側のネットワークポートの帯域が詰まった場合には少し工夫が必要です。最も単純なのはゲストOS毎にアタッチする物理ネットワークポートを切り替えることですが、これは少しばかりモサい運用であると言わざるを得ません。Bondingで帯域を増やせれば一番楽ですが、スイッチを冗長化した構成でActive/ActiveのBondingを動かすには注意が必要で、Active/Standbyのようにおいそれとは動きません。方式も単純なラウンドロビンから802.3adのようなプロトコルまであるため、機器の相性を確認しながらネットワークを慎重に構成する必要があるでしょう。あとはBondingではなくDevice Mapper Multipath等を使ったマルチパス。ただしマルチパスもストレージとの相性があり、とあるストレージは「このマルチパスドライバじゃないとダメ」とかいろいろあるので少し混沌としています。

このあたりは一口にどればベストと言い切るのは難しいところです。

共通して言えることは、

  • iSCSIは試してみるべき。食わず嫌いは勿体ない。
  • 負荷の特性を知るべき。その結果によって帯域が必要なのかディスクのスループットが必要なのか見極める。
  • ディスクのスループットが必要な場合は単価の低い機器でディスク本数を増やすのがベスト。SSDも素晴らしい選択肢。
  • 並べて増やしたディスクはASMで一つの大きなストレージに変身させる(ASMはOracleデータベースのすべてのエディションに基本機能として付属しているストレージ管理機構です)。ASMはデータベースだけでなくファイルシステムにも使えるあり得ないストレージ管理機構。複数のディスクをまとめてミラーリング、ストライピングし、さらにホットスワップが可能で自動的にオンラインリバランスする。ハイエンドストレージさん、さようなら。

ということでややもすれば強引な気もしますが最後にASM登場。でもこれ、正直ベースで個人的に最強の構成だと思ってるんですよね。

仮想化+ASM+iSCSIについては近々セミナーで「詳解xxx」みたいな形でお話する予定です。多分関西で。年明けに。

また正式にセッション構成を固めたらご案内させていただきヤス!

with one comment

Written by 中嶋 一樹

12月 6th, 2009 at 1:18 pm

Posted in Uncategorized

Tagged with , , ,