nkjmkzk.net

powered by Kazuki Nakajima

Archive for 7月, 2010

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 , ,

オレ流クラウドの定義

先日、ようやくぴったりと自分の感覚にフィットするクラウドの定義を思いつきました。超端的に一文で表現。

「ガチガチに作り込んだ最強システムをみんなで使える形にしたもの」

ガチガチに作り込んだ、ってどんな?ということになります。

イメージし易いのはやはり比較的大規模なWebサービスを提供されている企業の自前システムでしょう。自前でSEを抱えてシステムを構築・運用されているところはいかに安く、安定して、スケーラブルで使い易いシステムを構築するかに創意工夫を凝らされています。そういうシステムの裏側を紹介する勉強会等はえてして面白いですよね。

素早くサーバを追加&システムに組み込むためにPXEブートを駆使したディスクレス構成を組んでみたり、Cobbler等を使って高速なOSインストール環境を整えてみたり、PuppetやFuncを使って多数のサーバを一斉に操作するフレームワークを確立してみたりと、その筋の作り込みはめちゃ楽しいものです。しかしこういったシステムは一朝一夕で出来上がるものではなく、いろんな調査、検証や失敗経験から学んだ成果であり継続的なブラッシュアップがなされて完成度を高めていくものでしょう。

ある程度形になるまでは相当な努力と時間が必要ですが、軌道に乗れば自分たちにとって非常に都合のよい最適化された最強システムになっていきます。

こういったシステムはSIerが案件単位で構築することは現実的ではないでしょう。厳しい納期、各ステークホルダーの私利私欲による提案が交錯し、真に最適な姿を突き詰めるのは至難の業です。そこにはいくつもの妥協という大人の選択があります。

案件単位で個別にシステムを作っていく事はSIerにとっては飯の種かもしれませんが、エンドユーザは毎回システム毎にH/WやS/Wの購入を余儀なくされ、同じように設計、構築、テストという作業を発注することになります。しかもその結果構築されるシステムはWebサービス事業者が長年ブラッシュアップしているシステムと比較して、完成度で見劣りする可能性が多いにあり、また、費用も都度相当なものになることでしょう。国が大手SIerに発注しているシステム、とんでもない金額ですよね。「あんなの、あのイケイケの会社にお願いして作ってもらえば100分の1くらいの費用で済むんじゃないの?」と、納税者としてはクレームしたくもなります。

そう考えると、理想は「最強のオレオレ・システム」を汎用的に使えるようにすることではないかと思います。

これまでの調査・検証と経験、優秀なエンジニアの知見の粋を集めたオレオレ・システムの、、、

  • 高速プロビジョニングの仕組みをシェアする
  • H/W障害時に高速にFailoverすることが検証済みである冗長構成をシェアする
  • ワンタッチで様々なオーダーが完了する運用フレームワークをシェアする

これができればIT業界はもっと政治的な要素がなくなり、純粋な技術的要素が強まるのではないかと思いを巡らせています。

実現するためのテクノロジーは問いません。高速プロビジョニングを仮想マシン+CoWで実装する手法もあるでしょうし、前述のネットワークブートでベアメタルにOSを起動させる手法もあるでしょう。Real Application Clustersで耐障害性を確保するような高度な冗長構成もあるでしょうし、システムコンフィグレーションはシンプルに留め、人間的Failoverなシステムもあるでしょう。各手法によって一長一短あると思いますが重要なのは最終的に如何にサービスレベルが高く、運用が楽ちんで低コストなシステムが構築できるかだと思います。これがガチガチに作り込んだ最強システム。これに汎用性を持たせて第3者に開放できる状態にしたシステムが「クラウド」である、と考えました。

with one comment

Written by 中嶋 一樹

7月 1st, 2010 at 2:23 pm

Posted in Uncategorized