nkjmkzk.net

OracleではUnified StorageというI/Aサーバ+Solaris ZFSを用いたストレージ製品を販売しています。Unifed Storageは下記のような特徴があります。

• ZFSベースのDedup, Compression, RAID, Snapshot, Replication等が標準機能として使え、かなり直感的な専用のGUIが付属している。
• 機能の追加によるオプションライセンス発生は一切なし。全ての機能がベースの価格に含まれる。

そしてこのUnified Storageの使用感を手軽に試せるシミュレーターが提供されています。
これはVirtualBoxのアプライアンス（VM）として起動させるもので、OracleのWebサイトからフリーでダウンロードできます。

Oracle’s Sun Unified Storage Simulator

リンク先にはセットアップ方法も書いてありますが、基本的には下記の流れですぐに使えるようになります。

1. （まだインストールしてなければ）VirtualBoxをインストールする
2. Simulatorをダウンロードして解凍する
3. VirtualBoxを起動して解凍したSimulatorアプライアンスをインポートする

あとはインポートしたVMを起動し、最初の簡単なネットワーク設定ウィザードに従ってセットアップするだけです。

Simulatorを実際に僕が操作してみた動画を貼付けておきます。これだけでもかなりUnified Storageを使ったボリューム作成等のイメージが湧き、直感的なユーザインターフェースを感じていただけると思います。

昨日、8/19に目黒雅叙園にてOracle Sun Technology Updateが開催されました。3Track x 3でセッションが開催され、各セッションは大きく分けてJavaとSolarisを扱う内容でした。その中でも最新情報の提供を行うようなセッションと、DTraceチュートリアルのような具体的な技術話とかなり幅広い内容が提供されたように思います。

僕はSolaris Trackに一日中入り浸っていましたので簡単にレポートしたいと思います。

B-1 Solaris開発環境のご紹介

大曽根 明さん

Mr.Solarisの異名をとる大曽根さんはOracle Solaris Operating Systemについてこれまでを振り返り、今後のロードマップを紹介しました。

次に新しいH/Wサポートメニュー「Premier Support for Systems」についても紹介しました。Premier Support for SystemsはH/Wの保守プログラムでありながら、同時にOracle Solaris, Oracle Enterprise Linux, Oracle VMが使いたい放題になることを説明。

また、ZFS, Containerについて概要を紹介し、特にZFSについては「非クラスター型で現在最強のファイルシステムだろう」と指摘。そしてSun Studioを使ったデモを披露する等幅広い内容をカバー。

B-2 開発環境でのSolaris ZFS

野崎 宏明さん

先のセッションで「最強」とされたZFSについて、こちらの@IT記事でもわかりやすい解説をされてる野崎さんからプレゼン。End-to-Endの整合性チェック機構、CoW等ZFSの根幹を成す内部アーキテクチャについて説明。

B-3 DTrace活用術

ZFSと並ぶSolarisの代表的な機構であるDTraceについて藤田さん、本間さんからプレゼン。

藤田 勇治さん

藤田さんはDTraceが何であるのか、どういった情報がとれて、どのように活用できるのかという全体象を事例を交えて紹介。端的で軽快なトークでDTraceのメリットを限られた時間ながら非常にわかり易く説明されていました。カーネルを特別なビルドオプション付きでコンパイルしたりする必要がない、特別な起動オプションもいらない、その場でほしい情報を動的に出力させることができる、ということがズドンと理解できる濃密な時間でした。

本間 大輔さん

本間さんはDTraceのHow toを紹介。「こういう情報をとりたいときは・・」という切り口で実際のスクリプトを見せて解説しながら出力結果を確認していくという実践的なセッション。持ち時間は30分足らずであるにもかかわらずDTraceのサンプルスクリプトを含む実用的な資料を120枚作成するというパッション。事実、この資料はこれからDTraceを使ってみたい！という人にはバイブルでしょう。必見です。バイブルのダウンロードはこちら。
DTrace活用術

特別企画トークライブ：「2020年に向けてITエンジニアはどうやって生き残るか？」

ウルシステムズ（株）の漆原様、（株）Preferred Infrastureの太田様、クックパッド（株）大野様によるパネルディスカッション。モデレータは弊社の伊藤さん。
はっきり言って、かなり面白いディスカッションでした。何が面白かったかというと、みなさんそれぞれ強い信念をお持ちで、その信念が名言となって出てくるとことです。僕が特に印象に残った名言を下記に挙げさせていただきました。

• 製品や技術にコミットするかどうかは開発者に会って決める。信頼できるヤツならいける。（漆原様）
• めちゃ難しいプロジェクトを社員に任せる。できたら、目一杯給料を払ってあげる。それを繰り返す。（漆原様）
• 今日欲しいと言われたものは明日提供できなければそこに感動はない。（大野様）
• やりたいことをやる。やりたくないことはやらない。やりたいことを宣言する。（大野様）

それぞれ深い思考や経験を元にしたパワフルな持論です。共感する部分や「なるほど〜」な気付きもあり、非常に有益な時間だったと思います。

個人的には今後SunのテクノロジーとOracleのテクノロジーの合体技をより具体的に訴求するようなセミナーをやりたいなと思っています。Solaris, ASM, ZFS、このあたりがキーワードになるでしょう。楽しくなりそうです。

ACFSにはスナップショット機能が実装されています。

例えば、/u01/acfsにACFSファイルシステムがマウントされている場合下記のようにしてスナップショットを取得することができます。

[root@guest]# acfsutil snap create `date +%Y%m%d` /u01/acfs

スナップショットは/u01/acfs/.ACFS/snaps/YYYYmmdd以下に作成されます。これは通常のディレクトリ／ファイルとしてlsやcatなどで中身を確認することができます。バックアップの中身がすぐに確認できちゃう、というのは便利ですよね。

ただ、これだけだとあくまでもスナップショットによる論理バックアップです。ファイルシステムの改ざんやミスオペレーション時の復旧は可能ですが、RAID損傷等の物理的な障害時には機能しないバックアップです。物理的な障害時にもバックアップできるように異なるH/W間でレプリケーションさせておくことが考えられます。現時点での最新リリースGrid Infrastructure 11.2.0.1にはレプリケーション機能は実装されていません。

ACFSはGrid Infrastructureに含まれます

ということで伝統的なrsyncを使ってACFSスナップショットからリモートホストへ差分レプリケーションを実現するワンライナーを紹介しておきます。

[root@guest]# rsync -ave ssh --delete --exclude='.ACFS' --exclude='lost+found'  /u01/acfs/.ACFS/snaps/`date +%Y%m%d`/  [バックアップサーバのユーザ名]@[バックアップサーバのIP]:[ディレクトリ]

これで先ほど取得したスナップショットの内容をリモートホストに複製（レプリケート）することができます。初回実行時にはまだリモートホスト側にデータがまったく存在しないのでフルレプリケーションになりますが、次回からはレプリケート済みのデータと今回転送するデータとの差分のみが転送されます。また、リモート側には存在するがもうオリジナルには存在しないデータはリモート側から削除されます。つまりオリジナルの最新スナップショットとリモートの複製は一日毎に同期することになります。

なので先ほどのACFSスナップショットのコマンドとrsyncのレプリケーションコマンドをcronに登録しておけば日次でスナップショットを取得して論理障害に備えつつ、リモートホストにバックアップを複製して物理障害に備えることができます。

Linux環境のiscsi-initiator-utilsを用いた際に重要となるタイムアウト関連の設定について。

信頼性の高いシステムでは当然iSCSIストレージへの接続も冗長化するという要件があります。汎用的な実装だとdevice-mapper-multipathを使ってストレージネットワークの障害に対しての冗長構成でとることができます。また、OracleのASMを使ったStorage GRID構成では複数ストレージをストライピング＆ミラーリングし、例えストレージが筐体ごとパワーダウンしてもオンラインで処理を継続することができます。このStorage GRID構成で重要なのがiSCSI Initiatorのタイムアウト設定です。

iSCSIストレージへの接続性に不具合が発生した場合、iSCSI Initiatorが死活監視によってそれを検出します。最終的にはiSCSI InitiatorがiSCSI Targetへの接続障害という判定を行い、それをI/Oエラーという形でOSに報告します。ASMはその報告をもってストレージの切り離しを行い、残るストレージで処理を再開、継続します。障害が起こってからiSCSI InitiatorがI/Oエラーを報告するまでの間は全てのI/Oが一旦保留されます。本番環境ではこの保留される時間を制御したいという要件が出てくるでしょう。

下記のような障害パターンで上記の保留期間を制御するためのiSCSI Initiator設定を紹介します。

• クライアント側のNIC故障
• iSCSIネットワーク断（ケーブル劣化、スイッチ故障）
• iSCSIストレージのパワーダウン、コントローラ故障

ちなみにiSCSI InitiatorはOracle Enterprise Linux 5.4にバンドルされるiscsi-initiator-utils-6.2.0で動作を確認しています。前後のバージョンでもデフォルト値は変更されている可能性はありますが、挙動に大きな違いはないと思います。

重要なパラメータは下記の3つです。

• node.conn[0].timeo.noop_out_interval（デフォルト5秒）

pingによるコネクションの死活監視間隔

• node.conn[0].timeo.noop_out_timeout （デフォルト5秒）

pingによるコネクションの死活監視がコネクションエラーと判定するまでの待ち時間

• node.session.timeo.replacement_timeout（デフォルト120秒）

コネクションエラーが発生してからI/Oエラーを返すまでの待ち時間。この時間までに死活監視がコネクション復帰を報告すればI/Oエラーは返らない。

デフォルト設定で障害が発生した場合、下記のような流れとなります。

1. 死活監視のpingが発行される（タイミングによって障害発生から1〜5秒経過）
2. pingがタイムアウトする（+5秒経過）
3. 継続して死活監視のpingが発行され、最終的にpingが成功しないとOSにI/Oエラーが返る（+120秒経過）
4. ASMがI/Oエラーを検出して障害ストレージを切り離し、残りのストレージで処理を再開する（即時）

経過時間をまとめると、(1〜5）+ 5 + 120 = 126〜130秒程の時間が切り替えまでに必要となります。

これを例えば障害試験等で確実に15秒程で切り替えを発動させたい場合は次のように設定すれば実現できます。

• node.conn[0].timeo.noop_out_interval = 1

• node.conn[0].timeo.noop_out_timeout = 5

• node.session.timeo.replacement_timeout = 10

この場合経過時間は（〜1）+ 5 + 10 = 15〜16秒となります。

このiSCSI Initiatorのパラメータ設定は下記のiscsiadmコマンドで設定できます。ただし、ログイン済みのセッションについては反映されません。反映させるには一旦ログアウトし、再度ログインしてセッションを再確立させる必要があります。

[root@~]# iscsiadm -m node -p [ターゲットのIP] -o update -n [パラメータ名] -v [設定値]

また、/etc/iscsi/iscsid.confを編集しておくことで新たに登録されるiSCSIターゲットについてのデフォルト値を変更することができます。これは既に登録されているiSCSIターゲットには反映されないので注意してください。

ZFSはご存知の通りzvolを作成してiSCSIでエクスポートすることができます。

とある環境でZFSサーバは複数のネットワークセグメントに接続されており、当然それぞれのセグメントでIPアドレスが割り振られているとします（多くの環境ではそのようになっているでしょう）。そのときzfs set shareiscsi=on [ZVOL]としてzvolをエクスポートすると、すべてのセグメントでzvolがエクスポートされてしまいます。

iSCSIセグメントからDiscoveryしにいったiSCSIクライアントにも1zvolにつき複数のターゲットが見えてしまいます。これは多くの環境で望ましくない挙動でしょう。本来はzvolがエクスポートされるのはiSCSIのストレージセグメントだけに留めておきたいはずです。

zvolがエクスポートされるセグメントを設定するにはtpgt (Target Port Group Tag)が有効です。tpgtを使えば下図のようにzvolをエクスポートするセグメントを限定できます。

設定手順です。

まずtpgtを作成します。tpgtの名前には1〜65535の任意の数字を割り当てます。

[root@~]# iscsitadm create tpgt 1

作成したtpgtにzvolをエクスポートしたいIPアドレスを追加します。

[root@~]# iscsitadm modify tpgt -i 10.2.0.1 1

zvolのアクセス制御リストとして作成したtpgtを設定します。

[root@~]# iscsitadm modify target -p 1 [TARGET]

これでtpgt 1に参加している10.2.0.1だけがzvolのエクスポート対象となります。

$conn = oci_connect('user', 'password', 'node/service', '', OCI_SYSDBA);

[root@~]# tar xvfj php-5.3.2.tar.bz2
[root@~]# cd php-5.3.2/ext/oci8/
[root@~]# patch < /PATH/TO/php-sysasm.patch
[root@~]# cd ../../
[root@~]# ./configure --with-oci8
[root@~]# make
[root@~]# make install

ASMインスタンスへの接続は下記のようにOCI_SYSASMフラグを指定して接続します。

$conn = oci_connect('user', 'password', 'node/service', '', OCI_SYSASM);

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割り当て

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

PCI-Passthroughの場合

• 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の機能を存分に活用してスナップショットによるバックアップ／ロールバック、クローンによる高速プロビジョニング、圧縮、重複排除などの高度なストレージ技術がすべて利用できます。それも物理的にはサーバ一台というオールインワンで。検証環境としては最高に高密度なシロモノとなります。

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

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

Oracle Enterprise Linux 5.4 x86_64 PVMのVMテンプレートを作成しました。

Oracle_Enterprise_Linux_5u4_64_for_11gR2.tar.bz2

このテンプレートにはOSしか入っていません。が！少しいじってあります。一番のカスタマイズは次の点です。

• Oracle 11g R2がすぐにインストールできる

11g R2とは、Grid InfrastructureとDatabaseのことです。Storage GRIDでキーポイントとなるASMはGrid Infrastructureをインストールすることで使えるようになります。

• このテンプレートをダウンロードしてVM Server上で起動する
• Grid InfrastructureをOTNからダウンロードして先ほど起動したVMにインストールする

としていただくことでASMが利用可能になります。ASMが使えるということは11gR2から追加されたACFS（ASM Cluster Filesystem）も使えます。ちなみにACFSとはこういうものです。

• クラスターファイルシステム
• 物理ディスクまたはLUN -> DISKGROUP -> ボリューム -> ファイルシステムというアーキテクチャ
• 動的にファイルシステムサイズを変更可能
• 動的に物理ディスクを追加／削除することが可能
• ディスク構成が変更されるとデータの再配置（リバランス）を行う
• データの冗長性を選択できる[冗長化なし | 2重化 | 3重化]　2重冗長以上であればディスクが壊れてもオンラインで運用継続
• スナップショット機能装備

現在これらの機能を全て備えたファイルシステムはACFSだけでしょう。まだあまり名前が売れてないのですが、結構すごいファイルシステムなのです。

通常11gR2のGrid InfrastructureやDatabaseをインストールするには追加のパッケージをインストールしたりカーネルパラメータをいじったりntpの設定ファイルを編集したりudevのルールファイルを編集したりしなきゃいけないわけですが、このテンプレートを使えば11g R2の前提条件チェックを一発でパスします。というわけでこれからASM、ACFSを触ってみたい！とかいう方にお薦めです。（本当はGrid Infrastructureのインストーラもテンプレートに含めておきたいのですが、そこはソフトウェアの配布規約上不可でした。無念）

使い方は以下の通り。

• VM Serverの/OVS/seed_pool以下にテンプレートをダウンロードし、展開する
• VM Managerからインポートする
• VM Managerでこのテンプレートから仮想マシンを作成する
• 仮想マシンを起動する（初回起動時にIPアドレス2つといくつかのネットワーク設定を入力します）
• Grid Infrastructureをダウンロードしてインストールする（runInstaller.shを実行するだけ。事前の環境設定は必要なし。）

VM Manager使うのが面倒な人はテンプレートを/OVS/running_pool以下に保存して展開し、vm.cfgのdiskパスだけseed_poolからrunning_poolに変えていただければxm create vm.cfgでそのまま起動可能です。ただしNICが2個あることが前提のネットワーク設定になっているのでVM ServerにNICが一つしかない場合にはbridge=xenbr1の方のVIF設定を削除する必要があります。

このテンプレートは他にも地味にいくつかカスタムしてあります。rlwrapがインストールされていてoracleユーザの.bashrcにalias sqlplus=’rlwrap sqlplus’と勝手に入れてあったり、とか。4GByte程あるのでダウンロードにそこそこ時間がかかると思いますが、ASM、ACFSを試してみたい方は是非どうぞ。

＊ちなみに解凍後のサイズは20Gbyte強になります。rootのパスワードは’oracle’です。

サーバ仮想化環境では「リソースプール」という概念を実現するために共有ストレージ構成が多く採用されます。しかし、そもそも現在の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の寿命などかわいいもの、と思う。

よく「仮想化ではストレージはどの接続形態がお薦めですか？」と質問を受けます。つまりは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」みたいな形でお話する予定です。多分関西で。年明けに。

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