Linuxと iSCSIで SANを構築する〜前置き〜
iSCSIは SAN（ストレージエリアネットワーク）の技術である。1000base-Tや10GbEといった一般的なネットワークのインフラを使用するため、ファイバーチャネルと比較して安価に構成出来るのが特長といえる。そのかわり、比較的高レベルなトランスポートプロトコルである TCPの上に成立しているためオーバーヘッドが大きく、性能が出にくいとされる。
しかしながら、（適切なソフトウェアを組み合わせれば）家電量販店で普通に売っているハードウェアだけで SANが構築出来るわけで、従来ファイバチャネルの守備範囲だったハイエンドの市場がより一般に近いところまで「降りてくる」可能性には注目すべきものがあるだろう。（といわれ続けてはや何年）
そもそも SANは何故必要なのか。いくつかのケースが考えられるが、ひとつは並列コンピューティング（クラスタリング）に関するものだ。
計算機資源のスケーラビリティを求めるときに取り得る戦略はいくつかあるが、いずれの戦略を用いるにせよ単体の計算機ではその計算能力に限界があるため複数の計算機を並列に動作させるという部分では共通する。しかし計算機の処理能力を必要とするビジネス上の諸問題は、多くの場合何らかの共有されたビジネス・オブジェクトの状態を無矛盾に保った上で解決される必要があるため、単純に機械を多く用意して並べれば良いということにはならない。つまり、ある口座へ入金する処理と、同じその口座から出金する処理は別々の計算機で同時に処理されることはあっても、その結果が矛盾しないことを保証されなくてはならない。
この問題に対するアプローチの一つは、記憶領域（ストレージ）を一カ所に集中させつつ計算能能力となる各ノードを分散し、適切な排他制御の元に処理を実行させる方式である。この時、ストレージと各ノードを接続するネットワークが SANである。
普通に各ノードを LANで接続して共有フォルダ（これは現在一般家庭にも普及しつつある形で、NASという）を使うのでは駄目なの？という疑問が沸くかもしれない。面倒なので詳しい理由は説明しないが、高速な並列処理に必要なのは「共有のフォルダ」ではなく「共有のディスク」、もっと言うならば共有のブロックデバイスであり、NASは主に性能上の理由で SANの代わりにならない。
クラスタリング以外にも SANの用途はある。最近急速に普及してきているサーバ仮想化技術がそれだ。仮想サーバに必要なリソースである CPUとRAMとストレージのうち、CPUとRAMは（極端な話をすれば）幾らでも換えの効く使い捨てのものであるのに対し、ストレージだけは中に永続データを保持する以上そういうわけにもいかないため、物理的に一カ所へまとめて集中的かつ大切に運用管理できる方が良い。つまり多数のノード(CPU,RAM)と一つの共有ストレージ、そしてそれらを接続するネットワークという構図が出来る。
この事から、サーバ仮想化技術は SAN、とりわけ iSCSIと組み合わせて用いられるケースが多くなっている。並列コンピューティングと違い仮想化技術は中小規模の事業者にとっても必要かつ導入しやすく、また費用対効果の高い技術であるため、低コストで構築できる iSCSIはこの分野において存在感を増しているのだろう。なおVMWareも商用版Xenも iSCSIをサポートしている（Virtuozzoはストレージを仮想化しないためSANと直接は関係ない）。
さて、SANと iSCSIの話を延々としてきたのは、Linuxの iscsitarget (ited) と open-iscsiを組み合わせて主にXen用に SANを構築運用する方法のメモを記そうと思ったため、その前置きである。前置きだけで終わるかもしれない。続くかもしれない。
しかしながら、（適切なソフトウェアを組み合わせれば）家電量販店で普通に売っているハードウェアだけで SANが構築出来るわけで、従来ファイバチャネルの守備範囲だったハイエンドの市場がより一般に近いところまで「降りてくる」可能性には注目すべきものがあるだろう。（といわれ続けてはや何年）
そもそも SANは何故必要なのか。いくつかのケースが考えられるが、ひとつは並列コンピューティング（クラスタリング）に関するものだ。
計算機資源のスケーラビリティを求めるときに取り得る戦略はいくつかあるが、いずれの戦略を用いるにせよ単体の計算機ではその計算能力に限界があるため複数の計算機を並列に動作させるという部分では共通する。しかし計算機の処理能力を必要とするビジネス上の諸問題は、多くの場合何らかの共有されたビジネス・オブジェクトの状態を無矛盾に保った上で解決される必要があるため、単純に機械を多く用意して並べれば良いということにはならない。つまり、ある口座へ入金する処理と、同じその口座から出金する処理は別々の計算機で同時に処理されることはあっても、その結果が矛盾しないことを保証されなくてはならない。
この問題に対するアプローチの一つは、記憶領域（ストレージ）を一カ所に集中させつつ計算能能力となる各ノードを分散し、適切な排他制御の元に処理を実行させる方式である。この時、ストレージと各ノードを接続するネットワークが SANである。
普通に各ノードを LANで接続して共有フォルダ（これは現在一般家庭にも普及しつつある形で、NASという）を使うのでは駄目なの？という疑問が沸くかもしれない。面倒なので詳しい理由は説明しないが、高速な並列処理に必要なのは「共有のフォルダ」ではなく「共有のディスク」、もっと言うならば共有のブロックデバイスであり、NASは主に性能上の理由で SANの代わりにならない。
クラスタリング以外にも SANの用途はある。最近急速に普及してきているサーバ仮想化技術がそれだ。仮想サーバに必要なリソースである CPUとRAMとストレージのうち、CPUとRAMは（極端な話をすれば）幾らでも換えの効く使い捨てのものであるのに対し、ストレージだけは中に永続データを保持する以上そういうわけにもいかないため、物理的に一カ所へまとめて集中的かつ大切に運用管理できる方が良い。つまり多数のノード(CPU,RAM)と一つの共有ストレージ、そしてそれらを接続するネットワークという構図が出来る。
この事から、サーバ仮想化技術は SAN、とりわけ iSCSIと組み合わせて用いられるケースが多くなっている。並列コンピューティングと違い仮想化技術は中小規模の事業者にとっても必要かつ導入しやすく、また費用対効果の高い技術であるため、低コストで構築できる iSCSIはこの分野において存在感を増しているのだろう。なおVMWareも商用版Xenも iSCSIをサポートしている（Virtuozzoはストレージを仮想化しないためSANと直接は関係ない）。
さて、SANと iSCSIの話を延々としてきたのは、Linuxの iscsitarget (ited) と open-iscsiを組み合わせて主にXen用に SANを構築運用する方法のメモを記そうと思ったため、その前置きである。前置きだけで終わるかもしれない。続くかもしれない。
ラベル: Storage
