nkjmkzk.net

powered by Kazuki Nakajima

Archive for the ‘asm’ tag

Storage GRID – 設計の勘所

Automatic Storage Management(以後ASM)を用いてStorage GRID環境を構築する際、「どういう構成がいいのかな?」という問いにお答えする設計の勘所を紹介します。

サーバ機の選び方

  • CPU
    • 特に指定なし。ただしStorage GRIDをデータベース用途でかつDWHに使用する場合は後述の1コアあたりが引き出せるI/O帯域について考慮しておく。
  • メモリ
    • ASMが含まれるGrid Infrastructureのみをインストールする場合は最低1.5GByte。
    • Oracle Databaseもインストールする場合は最低2.5GByte。
    • ただしメモリはもちろん多めに搭載が理想的。
    • 4GByte DIMMと8GByte DIMMを比較した場合、4GByte DIMMの方が容量あたりの価格が安価。したがってメモリ総量72GByte程度まででよければ、DIMMを大量にインストールできるスロットを搭載している機種の方が安価に仕上げることができる。
  • ローカルディスク
    • 最低空き容量10GByte
    • Oracle DatabaseでDB Smart Flash Cacheを利用する場合はSSDを必要量搭載する。SSDの必要量に関しては、データファイルがDRAM + SSDに載りきる容量であればその容量分調達することが望ましい。また、DB Smart Flash Cacheの容量はDatabase Buffer Cacheの2倍から10倍を推奨。また、DB Smart Flash Cacheを有効化するとその管理領域がBuffer Cacheに割り当てられる。その管理領域のサイズは次の式で見積もり可能。db_flash_cache_size / db_block_size x 100 (RACの場合は200)
  • ネットワーク
    • 最低2つのネットワークセグメント(Public, Private)が必要。bondingを考慮すればPublic x 2, Private x 2の合計4ポートの1GbEが必要。
  • HBA
    • Fibre Channelを利用する場合はFC HBAを2ポート。iSCSIを利用する場合は2ポートの1GbEまたは10GbEを搭載する。いずれのAdapterでもマルチパスを前提としている。また、iSCSIで10GbEを採用する場合にはこの2ポートをVLANでセグメント分割し、前述のPublic, Privateセグメントと共有することも考えられる。

ストレージ装置の選び方

  • アプライアンスかI/Aサーバか?
    • Storage GRIDは特定のストレージ装置に依存しないため、任意のアプライアンスまたはディスクを十分に積んだI/Aサーバで構成することができる。
    • I/Aサーバを採用する場合、OSがLinuxであればiSCSI Enterprise Targetを用いてiSCSI Target化し、OSがSolarisであればZFSのビルトインNFSやCOMSTARを用いてiSCSI Target化、Fibre Channel Target化することができる。
    • 極端に容量の多いストレージシステムや完全にSSDで構成されたストレージシステムを構築するといった特殊な要件がある場合にはI/Aサーバを選択し、それ以外の場合には小型のアプライアンスを採用することが望ましい。
  • プロトコル
    • サーバ<–>ストレージ間の通信プロトコルは問わない。現在一般的に利用されているFibre Channel, iSCSI, NFSいずれも選択可能。
  • オプション機能
    • ASMは複数のストレージ装置を束ねることができるため、ストレージ装置側でアレイの拡張やエンクロージャの拡張機能は必要ない。
    • スナップショット、レプリケーション等の機能はサーバソフトウェア側で提供されるためストレージ装置には必要ない。
  • 必要DISK本数
    • 容量だけでサイジングされているケースも散見されるが、実際には容量要件を満たした上でI/O要件も満たす必要がある。
    • DatabaseでOLTP系サービスの提供を行う場合、重要なのはIOPS能力。このときに必要なDISK本数は次のように計算できる。
    • DISK本数 = 一秒あたりのトランザクション処理量 x 5 / DISK1本あたりのIOPS能力

      *上記の「x 5」は一般的なトランザクションは1トランザクションあたりおおよそ5IOPSで処理されるという前提で代入している。
      *15000RPM DISK1本あたりのIOPS能力の目安は、SAS DISKは80〜110 IOPS、SATA DISKは50 IOPSという感覚。本来は実機で測定しておくのが望ましい。

    • DatabaseでDWH系サービスの提供を行う場合、重要なのはI/O帯域。このときに必要なDISK本数は次のように計算できる。
    • DISK本数 = 必要なI/O帯域(MB/s) / 20

      *「20」は一般的なSATA DISK一本あたりのI/O帯域(MB/s)。本来は実機で測定しておくのが望ましい。
      *また一般的な1CPUコアあたりが引き出せるI/O帯域は200MB/s前後。したがって必要I/O帯域から必要となるCPUコア数も算出しておく必要がある。

ネットワーク構成の組み方

非仮想化環境(ベアメタル)、仮想化環境、iSCSIストレージ使用時、Fibre Channelストレージ使用時それぞれのケースでのネットワーク構成を下図にて紹介します。

  • ベアメタル環境 + iSCSIストレージ

Storage GRID実装ガイド(中嶋).002

  • ベアメタル環境 + Fibre Channelストレージ

Storage GRID実装ガイド(中嶋).003

  • 仮想化環境 + iSCSIストレージ

Storage GRID実装ガイド(中嶋).004

  • 非仮想化環境 + Fibre Channelストレージ

Storage GRID実装ガイド(中嶋).005

DISK構成の組み方

  • 台数
    • 完全に内部的に冗長化されたストレージアプライアンスを用いる場合は最低台数1台。ただし万一ストレージ装置が故障した場合、データのロストや可用性が損なわれる可能性がある。
    • 内部が冗長化されていないI/Aサーバ等を用いる場合は最低台数3台。この場合、いずれかのストレージ装置が故障してもデータのロストやストレージシステムの可用性が損なわれることはない。
  • H/W RAIDとASM冗長化モード
    • 多くの環境ではH/W RAIDを有効化するのが望ましい。ASMはソフトウェア側で従来RAIDが担っていたストライピングとミラーリングを提供できるため、H/W RAIDを一切用いずにDISKを構成することも可能。しかしそれなりの頻度で発生することが想定されるDISK障害は、発生することを前提に影響を最小限に留める設計を行いたい。DISK障害発生時、ホットスワップ可能なDISKとH/W RAIDを用いていればDISKを交換するだけで保守作業が完結する。ASMの場合は新しいDISKをDISKGROUPに組み込むという操作が発生する。実質はコマンド一発で完了するので決してタフな作業ではないが、既存の保守員の作業スコープを考慮するとDISK障害時はDISKの交換という物理的な作業で完結できる方がよかろうというのが意図。DISK障害はH/W RAIDで対応、ストレージノード障害はASMの冗長化モードで対応という設計。
    • ASMには3つの冗長化モードが存在する。
      • 冗長化なし -> 実効容量率: 1/1
      • 二重冗長化 -> 実効容量率: 1/2
      • 三重冗長化 -> 実効容量率: 1/3
    • 推奨される各H/W RAIDモードは下記の通り。
      • 性能重視の場合:RAID 1 -> 実効容量率: 1/2
      • 容量重視で単一RAIDアレイを構成するディスクが少ない場合:RAID 5 (RAID-Z) -> 実効容量率: (DISK本数 – パリティDISK数)/DISK本数  *単一のRAIDアレイ中のパリティDISKは1本
      • 容量重視で単一RAIDアレイを構成するディスクが多い場合:RAID 6 (RAID-Z2) -> 実効容量率: (DISK本数 – パリティDISK数)/DISK本数  *単一のRAIDアレイ中のパリティDISKは2本
    • 完全に内部的に冗長化されたストレージを用い、かつ、ストレージノード障害は想定リスク外とする場合は「冗長化なし」を選択。内部が冗長化されていないI/Aサーバ等を用いる場合は「二重冗長化」または「三重冗長化」を用いる。
    • H/W RAIDとASM冗長化を含めた実効容量の計算方式は次の通り。
    • DISK1本あたりの容量 * 1筐体に収容するDISK本数 * H/W RAID実効容量率 * ストレージノード数 * ASM冗長化モード実効容量率

    • 1ストレージノードにつき2つのRAIDアレイを作成する。これは一方をActive、もう一方をBackupとして利用するため。こうすることで一つのStorage GRIDで本番用領域とバックアップ用領域双方をまかなうことができ、かつ、物理的な記憶媒体を完全に分離することができる。このような構成は賛否両論あるところだが、バックアップを別メディアに保存しつつ調達H/Wを最小限にするという要件であれば、非常に効率の良い構成と言える。
  • LU(Logical Unit)
    • 原則として1つのRAIDアレイから1つのLUを切り出す。ただし、ASM DISKGROUPを構成するDISKの容量は2TBが上限のため、LUサイズは2TBを上限としそれを超える場合は1LUサイズが2TBを超過しないようにLUを複数作成する。
    • 切り出したLU上にパーティションを一つ作成する。これはLUを分割して使うという意図ではなく、パーティションを作成しておくことで3rd PartyのソフトウェアがASM DISKを意図せず傷つけないようにするための措置。
  • ASM DISKGROUP
    • 各ストレージノードのActive側のRAIDアレイを束ねるDISKGROUPと、Backup側のRAIDアレイを束ねるDISKGROUP をそれぞれ作成する。
    • Active側のDISKGROUP内に下記を配置する。
      • ファイルシステム:ACFS(本番環境用)
      • Oracle Database:制御ファイル, オンラインREDOログ, データファイル, SPFILE, Change Tracking File
    • Backup側のDISKGROUP内に下記を配置する。
      • ファイルシステム:ACFS(レプリケート先), ACFSスナップショット
      • Oracle Database:制御ファイル, オンラインREDOログ, アーカイブREDOログ, RMANバックアップ, Flashback log
    • 万一、Active側のDISKGROUPが全損するような障害が発生した場合でも、利用するDISKGROUPをActiveからBackupに切り替えることで非常に迅速にリカバリを図ることができる。

Storage GRID設計の際、ヒントになれば幸いです。

without comments

Written by 中嶋 一樹

12月 15th, 2010 at 8:14 am

Posted in Uncategorized

Tagged with

Oracle Database 11.2.0.2公開 ACFSの新機能を少し紹介

ひっそりとOracle Database 11.2.0.2が公開されました。ひっそりと公開している割には新機能が結構あります。Databaseに連動してASM/ACFSが含まれるGrid Infrastructureもアップデートされています。特にACFSの新機能について独断と偏見で選んだ目玉を3つ紹介します。

  • 暗号化

ACFSに格納するデータをリアルタイムに暗号化します。

  • レプリケーション

リモートのACFSにデータを非同期レプリケートします。Data GuardのようにTransaction LogならぬReplication Logを転送することでレプリケーションを実現しています。レプリケートは手動で止めたり、再開したりできます。ただ、暗号化とは併用できないのでご注意を。

  • Solaris対応

ついにSolarisにもACFSがキマシタ。ZFSが超イケてるファイルシステムなのは言うまでもないですがACFSが使えるようになったことで、複数のSolarisノード間でクラスターファイルシステムが構成できるようになり、分散ストレージ環境(Storage GRID)でのデータの共有が簡単に実現できます。

*理論的にはローカルHDD/SSDをZFSからiSCSIでエクスポートして、相互にiSCSIログインしてそれをASMのDISKGROUPとすればストレージ無しで冗長性のあるクラスターファイルシステムを構成するというワケのわからない構成も可能かも。でも相互依存が強過ぎてリブートとかできなくなるのでやめときましょう。

*そういうことをするときはVMでストレージノードとサーバノードを分けるのがオススメです。サポート云々は抜きにして。

新機能の完全なリストと使い方はこちら。

What’s new in Oracle Automatic Storage Management ?

without comments

Written by 中嶋 一樹

9月 14th, 2010 at 10:41 pm

Posted in Uncategorized

Tagged with , ,

ACFSのスナップショットで日次バックアップ & 差分レプリケーション

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に登録しておけば日次でスナップショットを取得して論理障害に備えつつ、リモートホストにバックアップを複製して物理障害に備えることができます。

without comments

Written by 中嶋 一樹

8月 10th, 2010 at 2:20 pm

Posted in Uncategorized

Tagged with ,

iSCSI Initiatorのタイムアウト設定

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ターゲットには反映されないので注意してください。

without comments

Written by 中嶋 一樹

7月 7th, 2010 at 4:20 am

Posted in Uncategorized

Tagged with , ,

phpからASMを管理するためのパッチ

phpからOracleを操作するときは一般的にoci8というAPI群を使います。Oracleに管理者としてログインする際、sqlplusだとconnect /as sysdbaするのはご存知の通りですが、このoci8からOracleに管理者権限接続する際には下記のようにOCI_SYSDBAというフラグを立てて接続することが必要です。
$conn = oci_connect('user', 'password', 'node/service', '', OCI_SYSDBA);
同様にASMに管理者としてログインする際、sqlplusだとconnect /as sysasmすることが必要ですが、このoci8からASMに管理者権限で接続するためのOCI_SYSASMというフラグがないということに気付きました。つまり、phpからASMを管理できないじゃないか、ということになります。
こりゃ困った、ということでいろいろ悩んだ結果、phpにOCI_SYSASM接続モードを勝手に実装することにしました。結果幸運にもphpのソースをちょこっといじるだけでOCI_SYSASM接続モードのサポートをphpに組み込むことができましたのでそれをパッチとして公開しておきます。
php-sysasm.patch
phpのバージョンは5.3.2に対応していますが、多分oci8ってそれほど更新されていないと思うので他のバージョンでもそれほど古くなければ適用可能じゃないかと思います。パッチ適用及びphpのビルド、インストールは下記の手順をご参考に(configureオプションは最小限ですので適宜追加してください)。
[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);

without comments

Written by 中嶋 一樹

6月 24th, 2010 at 7:34 am

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 ,

Oracle 11g R2に最適化したOEL 5.4 VMテンプレート

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’です。

without comments

Written by 中嶋 一樹

3月 11th, 2010 at 11:03 pm

Posted in Uncategorized

Tagged with , ,

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

サーバ仮想化環境では「リソースプール」という概念を実現するために共有ストレージ構成が多く採用されます。しかし、そもそも現在の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によってストライピングすることでより厳しい性能要件に対応させる

Storage GRID recommend.001

  • 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の寿命などかわいいもの、と思う。

with 5 comments

Written by 中嶋 一樹

2月 7th, 2010 at 12:12 pm

Posted in Uncategorized

Tagged with ,

Storage GRIDセミナー終了。有難うございました!

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

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

Catch Up !! Oracle VM 2.2

Storage GRID詳解

with 4 comments

Written by 中嶋 一樹

1月 21st, 2010 at 9:11 pm

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 ,