SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

最新イベントはこちら!

Data Tech 2024

2024年11月21日(木)オンライン開催

EnterpriseZine Day Special

2024年10月16日(火)オンライン開催

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

システム担当者のための今さら聞けないストレージ再入門

IPがあれば大丈夫~IPを利用したストレージとSAN(2)

第8回

 コモディティ化した技術であるIPを利用したストレージ・ネットワークに注目が集まっている。今回は「IP SAN」の種類と特徴を解説する。(前半はこちら)

iSCSIイニシエーター

 iSCSIイニシエーターなどソフトウェアを利用する場合、サーバー側には特別なハードウェアを用意する必要はない。通常のネットワークで利用するNICを利用できる。このNICは普通のネットワーク・アプリケーションでも利用できるし、iSCSIデバイスへのアクセスにも共用して利用することができる。

 SCSIコマンドが発行されると、普通このコマンドはSCSIカード、もしくはFCカードに送られて処理されるのであるが、iSCSIイニシエーターはこのコマンドを横からさらい、IPの箱の中に押し込めてネットワーク経由でiSCSIデバイスに送り出す。IPネットワーク上を通過する時点では何処から見ても普通のIPの箱であるため、途中のスイッチやハブに不審がられる事はない。そのまま普通の転送が行なわれる。iSCSIだからといって特別な機能を持ったスイッチが必要になるわけではない。目的地となるiSCSIデバイスは、IPの箱の中からSCSIコマンドを取り出し、そのコマンドを実行する。例えばそれが読み込み命令であったなら、必要となるデータをやはりIPの箱の中に詰め、同じようにIPネットワークを経由してサーバーへとデータを送り返すのだ。

 ソフトウェアを利用する場合、特別な機器が要らないというメリットがある反面、I/O処理のためにネットワーク処理が実行されてしまうため、通常の利用形態に比べてCPU負荷が増大するという欠点が生ずる。実行するI/O処理の種類にもよるが、FCを使った場合に比べ、筆者の経験ではCPU全体に対し数%から15%弱程度余計にCPU使用率が上がってしまう可能性がある。従ってiSCSIを使う場合は後述するオフロード・エンジンが必須アイテムであると主張する方もいるほどだ。オフロード・エンジンが利用できると、CPUの負荷が相当軽減できるので、確かに効果は大きいが、CPUのパワーは技術進歩と共に年々コスト・パフォーマンスを向上させているので、そのような細かなことは気にすることはないという考え方もある。筆者はどちらかと言うと後者の意見に賛成だ。

iSCSIオフロード・エンジン

 iSCSIに必要となるTCP/IPやiSCSIにかかわる処理を、サーバーのCPUではなくカード(NIC)側で実行してしまおうというのがオフロード・エンジンである。当然ながらiSCSIだけの機能を備えていても仕方がないため、通常はTCP/IPの機能とセットで提供される。

 因みにTCP/IPの機能だけを装備したオフロード・エンジン(TCP/IP offload engine :TOE)も存在するが、これを用いてiSCSIデバイスへアクセスする場合、CPU負荷はある程度軽減できるが、iSCSIイニシエーターをサーバーへ導入せねばならない。iSCSIデバイスへのアクセスはiSCSIオフロード・エンジンに搭載されたNICを使った場合でも、ソフトウェアを使った場合と全く変わりはない(図8-6)。

図8-6 iSCSIイニシエーターとiSCSIオフロード・エンジン
図8-6 iSCSIイニシエーターとiSCSIオフロード・エンジン

 iSCSIオフロード・エンジンが搭載されたNICはiSCSI専用に使われることが多いので、この観点で言うとFC用のHBAと大差はない。まだiSCSIが出て間もない頃、オフロード・エンジンを使わないとiSCSIは使い物にならないのだ!とまで言い切った方は多数おられたが、筆者の感覚としてはそこまで言うほどの必須アイテムではないという印象だ。

 この理由として現在CPUのパワー向上は非常に目覚しく、かつWindowsサーバーなどで利用されるIA(Intel Architecture)サーバーであっても、マルチコアのプロセッサーが多数出現しているという事実が見逃せない。マルチコアのプロセッサーであればCPUはiSCSI処理のために適用業務処理がピタッと止まってしまうことはない。そうは言ってもiSCSIオフロード・エンジンがないよりはあったほうが望ましいという点は否定できない。CPUパワーをiSCSI処理で消費されてしまうのは如何にも勿体ないと考えるのは至極当然のことだからだ。

 現在、iSCSIオフロード・エンジンを採用する最大の価値はCPUの負荷分散目的よりも、「iBoot」と呼ばれるiSCSIを使ったシステム・ブートが容易になる点が大きい。NASでは実現できていないシステム・ブートがiSCSIでは可能なのだ。

 ソフトウェアによるiSCSIイニシエーターの利用では当然ながら普通はOS上で稼動するTPC/IPが起動しないとその上で動くiSCSI処理は実行できない。これに対してiSCSIオフロード・エンジンではOSの起動前にTPC/IPとiSCSIをカード上で実行できるので、OSを立ち上げるIPL用途ではオフロード・エンジンを使うほうが使いやすく簡単であり安心感が大きい。

 FCカードやSCSIカードと使い勝手を比べてみてもほぼ同じなので、iSCSIオフロード・エンジンを使ってみると意外に今までと違和感がないというのが実感であろう。iSCSIを利用したSAN環境でiBootを利用する形態は、FC SANにおけるSANブートと区別するため、特に「iSCSI SANブート」と呼ばれている。

次のページ
iSCSIに対応したデバイス

この記事は参考になりましたか?

  • Facebook
  • X
  • Pocket
  • note
システム担当者のための今さら聞けないストレージ再入門連載記事一覧

もっと読む

この記事の著者

佐野 正和(サノ マサカズ)

1986年日本アイ・ビー・エムの入社、本社SE技術部門で13年間ストレージ製品を中心に技術サポートを行なう。1999年にストレージ製品事業部に移り、以後、IBMストレージ製品の営業推進やソリューション推進、製品企画などの業務に携わる。現在、システム・ストレージ事業部でソリューション担当部長を拝任し、...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/292 2008/02/15 12:00

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング