nkjmkzk.net

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

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

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

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

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

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

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

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

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

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

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

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

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

Catch Up !! Oracle VM 2.2

Storage GRID詳解