Comments
Description
Transcript
IP ストレージ専用ネットワークのメリット
IP ストレージ専用ネットワークのメリット Is Your Business Ready for the Next Big Thing? アプリケーション、ストレージ、仮想化のいずれの分野に おいても、ベンダー各社は安定した低レイテンシを確保す るには IP ストレージ専用ネットワークを構築することを推 奨しています。本書では、アプリケーション性能における レイテンシの重要性について検討します。 さまざまなファイルを利用するアプリケーションがストレージへの依存を高める中で、IP ス トレージの規模は、ブロック型、ファイル型ともに大きく拡大しました。一方で、1 台の 物理サーバが複数のアプリケーションをホストするサーバ仮想化の要求とともに、イーサ ネットの帯域幅も増大しています。また今日、ユーザの環境でアプリケーションに接続す る NAS ストレージの数は、ブロック・ストレージの数を追い越す勢いです。 IP ストレージ が基幹系のティア 1 アプリケーションに採用されることも増えています。これらを背景にし て、アプリケーションのホストと NAS ストレージ・アレイとを接続するネットワークの設計 では、これまでの想定が大きく変化してきています。 ストレージ・チャネルと IP ストレージ・ネットワーク コンピュータの早い時代から、ストレージ I/O は、ディスク・ドライブとホスト OS の間を専 用チャネルで結んで、データをブロック伝送していました。1980 年代の半ばに、SCSI が オープンなストレージ I/O チャネルのプロトコルとして登場し、今日ではこれが広く使用され ています。SCSI は、ホスト側がイニシエータになり、ディスクやテープのドライブ側がター ゲットになります。I/O は、OS カーネルによって制御され、データを読み書きするアプリケー ションから、OS の SCSI デバイス・ドライバを呼び出すと、ドライバがアプリケーションの処 理を実行します。 元々 SCSI は、銅線のパラレル・ケーブルを使用して、1 つのホスト・アダプタに複数の機 器を接続するものです。しかしストレージの容量が大きくなると、この孤立したチャネルで は追いつかなくなり、2 つの解決策が開発されました。1 つは、FC SAN（Fibre Channel Storage Area Network）の利用です。FC SAN は、SCSIトラフィックに対して、ロスレスで 低レイテンシのネットワークになります。もう 1 つは、NFS（Network File System）と、そ の後発の CIFS（Common Internet File System）などの共有ファイル・システムです。デー タ伝送の保証がいわゆるベスト・エフォート型になる、 TCP による IP ネットワークを使用します。 2 ストレージ・ネットワークを SCSI データの伝送に使う場合、SCSI は、ネットワークに一定 の特性を求めます。つまり基本的にクライアント／サーバ型でなく、チャネル型プロトコル である SCSI は、次のことをネットワークに期待します。 • 確定的で小さなレイテンシ • 伝送の保証 ブロック型の専用 I/O チャネルは、1 対 1 のバスから多対多のネットワークに進化すること で、データ・ストレージの規模と伝送帯域幅を大きく拡大するニーズに応えました。同じ意 味でファイル型ストレージでも、多対多の NAS（Network Attached Storage）ストレージ が普及しています。 NAS は、ストレージとの通信にブロック伝送ではなく、NFS や CIFS などのファイル・システムを使用します。 NFS や CIFS は、クライアント／サーバ・アーキ テクチャによって、クライアントからファイル・サーバにリクエストを送り、サーバがクライア ントに代わってファイルにアクセスしてデータを読み書きします。クライアントは、オペレー ティング・システムの TCP/IP ネットワーク・ドライバを呼び出します。サーバには、フォル ダの入れ子構造による階層化ファイル・システムが作られて、これを管理しながらフォルダ に入ったファイル・データが読み書きされ、クライアントにデータが送信されます。 IP ストレージ専用ネットワークの意味 IP ストレージのトラフィックに専用の物理ネットワークを使用することは、多くのベンダーが 推奨しています。そのような中から、主な資料を最初に挙げます。なお、 ここで言う IP ストレー ジとは、ブロック型（iSCSI）とファイル型（NAS）の両方のストレージを含んでいます。 • Apache CloudStack の推奨（英語） http://cloudstack-installation.readthedocs.org/en/latest/choosing_deployment_ architecture.html#separate-storage-network • VMware vSphere を iSCSI 上で稼働させる際のベスト・プラクティス ‒ セキュリティの考 慮点 ‒ プライベート・ネットワーク（英語） http://www.vmware.com/files/pdf/iSCSI_design_deploy.pdf • Citrix ZenServer の設計：ZenServer ネットワーク構成の設計 ‒ 第 6 章：ストレージ・ネッ トワークのコンフィグレーション（英語） http://support.citrix.com/servlet/KbServlet/download/27046-102-666250/XS-design- network_advanced.pdf • EMC Clariion 性能と可用性のベスト・プラクティス：リリース 30.0 ファームウェア・アッ プデート、応用ベスト・プラクティス ‒ 第 3 章：ネットワークのベスト・プラクティス（英語） http://www.emc.com/collateral/hardware/white-papers/h 5773 -clariion-best- practices-performance-availability-wp.pdf • IBM b-type データセンター・ネットワーキング：設計とベスト・プラクティスの初歩（IBM （英語） Redbook）‒ 第 9 章：IP ストレージ・エリア・ネットワーク ‒ 9.4.4 iSCSI SAN の課題点 http://books.google.com/books?id=QVbAAgAAQBAJ&pg=PA375&lpg=PA375 &dq=IBM+separate+iscsi+network+best+practices&source=bl&ots=nX85tC_1z5 &sig=f0Y9561MUr8ZOIVhKYukxVWWiOY&hl=en&sa=X&ei=DSLpU6PzL873y QSL5YDYCA&ved=0CDAQ6AEwAw%23v=onepage&q=IBM%20separate%20 iscsi%20network%20best%20practices&f=false • NetApp と VMware vSphere の スト レ ー ジ・ ベ スト・プ ラ ク テ ィ ス ‒ 第 3 章：ス トレージ・ネットワークの 設 計とセットアップ ‒ 3.3 イー サ ネット・ストレージ・ネッ トワー キング の 基 本 ‒ 切り分 けたイー サ ネット・ストレージ・ネットワーク（ 英 語 ） http://community.netapp.com/fukiw 75442 /attachments/fukiw 75442 / fas-and-v-series-storage-systems-discussions/2645/1/ NetAppandVMwarevSphereStorageBestPracticesJUL10.pdf 3 多くのベンダーが推奨する中でその根拠とされている点は、次のようにまとめることができ ます。 • 確定的で小さなレイテンシ • 伝送の保証 • 管理ドメインの縮小とトラブルシューティングの効率化 • 制約を受けない自由なコンフィグレーション • 障害の隔離 • メンテナンスとアップグレードの簡素化 • コンフィグレーション ストレージ I/O は、低レイテンシであるとともに、確実なものでなければなりません。その ためデータ伝送が保証されることが重要です。ベスト・エフォート型で、基本的には伝送を 保証しないイーサネットや IP をストレージ・トラフィックの伝送に使うときには、まさにこれ が弱点になります。 TCP で、無理に伝送を保証させるため、輻輳がある場合はきわめて困 難になります。ファイバーチャネルのブロック型ストレージ・ネットワークと違って、トラフィッ クが混雑する中で、IP ネットワークが TCP で信頼できる伝送をするには、再送を繰り返す ことになります。フローが増えてポートが停滞したときの TCP スロー・スタートも、ストレー ジ I/O に大きな遅延を引き起こします。 単一のストレージで管理ドメインを区切ることで、管理とトラブルシューティングが簡素化さ れます。専用のストレージ・ネットワークを使うと、ストレージ管理がシンプルになり、ストレー ジ管理者が仕事の切り分けや、責任分担に悩まされながら、ストレージと伝送ネットワーク に気を配る苦労がなくなります。 ストレージが、ほかのネットワーク・トラフィックと一緒になると、ネットワーク設定の調整が 制約を受けて、ストレージ管理が自由にできない問題もあります。例えば、TCP のスライ ディング・ウィンドウや、ラウンド・トリップ・タイマーの設定によって、パケット喪失の回復 にかかる時間が変わってきますが、さまざまなタイプのトラフィックの条件も見合わせなが ら、この調整をしなければなりません。 一般に、何か技術的な問題があって原因を調べるときに、その範囲が小さいほど分析が簡 単になるのは当然です。専用ネットワークのコストが、ストレージ・トラフィックを加えるた めに、既存のネットワークを増強するコストからかけ離れたものでなければ、この点でも、 ストレージ・トラフィックに専用ネットワークを使用するメリットがあります。 アップグレードとメンテナンスの作業も、大きなネットワークほど複雑になります。ストレー ジと普通のネットワーク・トラフィックを一緒に処理する、大規模で複雑なネットワークのメ ンテナンスよりも、ストレージ・トラフィックに限定して小さく抑えたネットワークのメンテナ ンスの方が簡単に行えます。 これらは単純な要件のようでも、複合した大きなネットワークの中で設計をどのようにまと めて、プロトコルをどのように機能させるかとなると、厳しい制約になります。極端な例で すが、人体を巡る血液、神経、リンパ系の「ネットワーク」になぞらえて考えることもでき ます。各々のネットワークは、身体の同じ組織につながっている部分も多いですが、それぞ れは物理的にきちんと切り分けられています。その理由は、全部を 1 つにすると、設計に 課される条件が大きくなって、全体として効率のよい働きが不可能ではなくても、きわめて 難しくなり、いくつもの器官からなる身体の健康な営みを保てないからだとも説明されてい ます。 4 同様に、アプリケーションのトラフィックや、クライアント／サーバのトラフィック、Webトラ フィックを伝送するネットワークに、ストレージ・トラフィックを一緒にすると、それぞれのタ イプのトラフィックが持ち込む制約のために、すべての要件に対応しつつ、コスト効果の高 い効率的なネットワークを設計するのは困難になります。アプリケーションの性能は、さま ざまな条件に制約されますが、ストレージのデータの読み書きの低速化はネットワークにとっ て致命的です。そのため低レイテンシは不可欠です。そしてワークロードが変動しても、ア プリケーションの性能を予測される範囲に収めるために、レイテンシの値が確定的で、変化 の小さいことも要求されます。 小さな輻輳が引き起こす IP ストレージの大きな問題 ここで、データ・パスのどこかで一時的な輻輳が起こった場合の TCP の挙動の観点から、 クライアント／サーバ型設計の NAS ストレージへの影響を考えてみます。大規模なデータ センターのネットワークでは、3 階層トポロジがよく採用されています。スイッチやルータ の間の接続は、スイッチ間リンク（ISL）と呼ばれ、階層間を上下するトラフィックは、スイッ チ間リンクで集約されて多重化されます。そのため、スイッチ間リンクの両端のポートは、 サーバの NIC やストレージにつながるポートよりも輻輳が起こりやすい条件にあります。 さまざまな種類のアプリケーション・ トラフィックがネットワークの階層間を流れているときに、 どこかのアプリケーションのトラフィックに一時的な急増があって、スイッチ間リンクのポー トのフレーム転送にスパイクが生じたとします。スイッチやルータの ISL ポートは、一時的 な輻輳状態になります。このような場合、TCP は、フレームを破棄するとともに、ポートの フレーム転送量を絞ることで、混雑を緩和して輻輳を解消しようとします。そして状況が回 復すると、TCP は、混雑の再発を慎重に避けながら、時間をかけて徐々に転送量を戻して いく動作をします。これを「スロー・スタート」と呼び、輻輳の発生前の状態に戻るまでに、 数秒を要することがあります。 したがって、スイッチ間リンクを流れるフレームに、アプリケーションと IP ストレージのトラ フィックが混在している場合は、TCP のフレーム破棄とともに、ストレージ・データのフレー ムも破棄されて到達できなくなります。続いて TCP がスロー・スタートで回復に入る間は、 ストレージ・トラフィックを含めたポートのトラフィック全体に、大きなレイテンシが生じます。 結果として、この間のデータ伝送の抑制によって、ネットワークにはきわめて大きなレイテ ンシが変則的に発生することになります。 一時的な輻輳から生じるレイテンシの測定 複数のアプリケーションと NAS ストレージのトラフィックが、同じスイッチ間リンクを流れる ときに、データセンターのネットワークにどういうことが起こるかを知るために、ブロケード では、VMware VMmark テスト・ソフトウェアを使用して測定を行いました。定評のある VMmark は、仮想マシン（VM）で稼働する代表的な各種のアプリケーションをシミュレー ションして、それぞれのアプリケーションに典型的なワークロードに対して、変動を加えるよ うにします。クライアントのワークロードの変化に応じて、サーバが生成するストレージ I/O が変動し、ストレージ・トラフィックが変化します。 測定したのは、I/O レイテンシと合計 I/O 帯域幅の 2 項目です。ストレージ処理の性能を 考えた場合、レイテンシが重要となります。レイテンシはトランザクションの応答時間に直 接関係し、1 秒あたりのアプリケーション・トランザクション量に相当するものです。ビジネ スとしてのアプリケーションの価値は、どれだけ多くのトランザクションを処理できるかが大 きな位置を占めます。変動的で大きなレイテンシは、 トランザクション性能が低く、 アプリケー ションのビジネス価値が小さいことを意味します。このことは、とくにアプリケーションの応 答が悪いと短気な顧客をたちまち競争相手のサイトに逃してしまうため、Web の e コマー ス処理では重要視されます。 5 テスト用のネットワークは、2 階層のリーフ・スパイン型トポロジで、Brocade® VCS® ファブリック・テクノロジを使用して構成された Brocade VDX® スイッチを使用しました。 Brocade VCS ファブリック・テクノロジは、ブロケードの開発したイーサネット・ファブリッ ク技術であり、STP（Spanning Tree Protocol）による制約を避けながら、 レイヤ 2トラフィッ クに高度な伝送を行い、高い性能と、耐障害性、シンプルな管理と構成を可能にします。 注：Brocade VCS ファブリックは、トランクの全リンクで、トラフィックをフレームごとに ストライピングする ISL トランクや、エンド・デバイス間で等コスト経路をすべて利用する ECMP などの独自の機能を備えていますが、今回のテストでは使用していません。 図 1 に、テストの構成を示します。 Brocade VDX 6740 ス ト トレ ラ フ ージ ィッ ク Spirent からの トラフィック生成 VMmark による クライアント / サーバ トラフィック 10 GE VCS ファブリック 10 GE ISL Spirent からの トラフィック生成 10 GE 図 1： テストの構成 テスト用ワークロード テスト用ストレージ この構成では、複数のスイッチ間リンクで LAG（Link Aggregation Group）やポート・チャ ネルを構成して、耐障害性を強化する機能は取り入れていませんが、輻輳下での IP ストレー ジ・ トラフィックの挙動の再現に影響はありません。まず STP を使用したレイヤ 2 ネットワー クは、スイッチ間に 1 つの経路しか許しません。また LAG は、1 つのフローを 1 つのリ ンクに割り振り、そのリンクにはほかのフローも流れます。トラフィックの急増によって、あ るリンクに輻輳が起こると、LAG やポート・チャネルの一部であっても、そのリンクを流れ るストレージ・トラフィックは影響を受けます。したがって、テストの構成は、LAG 設定の 複雑さをなくし、IP ストレージのトラフィックが流れる既存の多くのネットワークの代表例と 言えます。 ベース・テスト ベース・テストとして、VMmark で処理負荷を生成して、ESXi の NIC で、アプリケーショ ンごとにディスク・アクセスのレイテンシを測定しました。テストは、アプリケーションのクラ イアントとサーバの仮想マシンを、すべて 1 台の ESXi サーバの上で動作させるため、ク ライアント／サーバ間のトラフィックは、ESXi サーバのハイパーバイザの外には出ません。 しかしサーバとディスクの間のストレージ・トラフィックは、VCS ファブリックを通って流れま す。したがって VCS ファブリックは、NASトラフィックのみを運ぶことになります。ベース・ テストであるため、Spirent テスト・ツールで生成するトラフィックは、VCS ファブリックに送 り込むことはしていません。 6 ベース・テストのレイテンシと帯域幅 VMmark で、DVD ストア（e コマース・ショップのシミュレーション）と Olio（Web 2.0 シミュ レーション）のアプリケーションを実行して、レイテンシを測定した結果を、図 2 と図 3 に それぞれ示しています。 図 2： DVD ストア・アプリケーションでの ESXi か らのディスク I/O レイテンシ：ベース・テスト 図 3： Olio アプリケーションでの ESXi からの ディスク I/O レイテンシ：ベース・テスト 測定値で分かるように、すぐれたディスク・レイテンシが得られています。全体に値が低く、 VMmark のドライバがアプリケーションの処理負荷を上げたときにだけ、所々に軽いスパイ クが出ています。 7 これに対するベース・テストでのディスク帯域幅は、図 4 と図 5 のようになりました。 DVD ストアと Olio の両アプリケーションとも、ストレージ I/O の帯域幅（伝送量）はきわめて小 さく、VMmark の負荷変動に応じて時々 1 MB/s に達しています。 図 4： DVD ストア・アプリケーションでの ESXi からのディスク帯域幅：ベース・テスト 図 5： Olio アプリケーションでの ESXi からの ディスク帯域幅：ベース・テスト スイッチ間リンクの最大帯域幅が、10 ギガビット／秒（Gbps）なのに対して、実際のスト レージ I/O の伝送帯域幅は、2 つのアプリケーションともきわめて低く、20 キロバイト／ 秒（KBps） （160 キロビット / 秒 ; kbps）程度であり、時々 700 ∼ 1,000 KBps（5,600 ∼ 8,000 kbps）のスパイクが、30 秒間ほど見られるだけです。ここには示していません が、VMmark で動作するアプリケーション全体での、ストレージの総帯域幅も、ESXi サー バに装着された 10 ギガビット・イーサネット（GbE）NIC の帯域幅のうち、10 ∼ 20 パー セント程度を占めるだけでした。 輻輳テスト 次に VMmark によるテストを実行しながら、Spirent テスト・ツールを使用して、Brocade VDX スイッチに別のトラフィックを送り込み、スイッチ間リンクに輻輳を発生させる一連の テストを実施しました。送り込んだトラフィックは、1 秒間オン 1 秒間オフの繰り返しから、 20 秒間オン 20 秒間オフの繰り返しまで、矩形波の断続サイクルの形を取っています。1 つの周期の断続サイクルにつき VMmark のテストを 30 分間継続し、まず 1 秒間オン 1 秒間オフの断続サイクル、次に 5 秒間オン 5 秒間オフの断続サイクルという方法で進めて いきました。このような形のスパイクは、例えばデスクトップ・コンピュータのバックアップ や、YouTube のビデオ・ トラフィック、大きな添付ファイルの送付、Dropbox などのクラウド・ ストレージへの大きなドキュメントのアップロードなどのトラフィックで発生するものです。 8 Spirent で生成した トラフィック・スパイク 対する使用率 ISL の 10 GE に 輻輳テストの間、ストレージ・トラフィックと Spirentトラフィックを合計したスイッチ間リンク の伝送帯域幅は、数分間の長周期の平均値で見て、スイッチ間リンク・ポートが備える 10 GbE の帯域幅の 60 パーセントを超えていません。図 6 に、VMmark からのテスト・トラ フィック（青色）と Spirent が生成したトラフィック・スパイク（グレーのバー）の様子を表 わしています。グラフで分かるように、Spirent の生成するトラフィックの平均値（赤色）は、 常に 50 パーセントです。合計トラフィックの長周期の平均値は、リンク帯域幅の 60 パー セントを超えていません。 合計トラフィックの 平均リンク使用率 Spirent 生成トラフィック の平均リンク使用率 図 6： 輻輳テスト：ISL リンクの平均使用率 数分間の長い周期の平均値で見ると、スイッチ間リンクに輻輳はありませんが、Spirent ト ラフィックを送り込んでいる短い周期の内側で見ると、輻輳が起こっているのが分かります。 NASトラフィックと一緒にネットワークを流れる、ほかのアプリケーションのトラフィックにス パイクが起こったときの状況を再現しています。 輻輳テストのレイテンシと帯域幅 図 7 と図 8 には、DVD ストアと Olio を ESXi サーバで実行してレイテンシを測定した結 果から典型的な部分をそれぞれ示しています。 図 7： DVD ストア・アプリケーションでの ESXi か らのディスク I/O レイテンシ：Spirent トラ フィック・スパイク印加 9 図 8： Olio アプリケーションでの ESXi からの ディスク I/O レイテンシ： Spirent トラフィック・スパイク印加 まず DVD ストア・アプリケーションの結果を見ると、ベース・テストのレイテンシに比べて 10 ∼ 70 倍にあたる、50 ∼ 70 ミリ秒（ms）の水準のレイテンシのスパイクが分単位 で続いているのが分かります。中にはレイテンシのスパイクが連続し、ベース・テストの水 準まで戻るのに数分間を要している部分もあります（赤丸で囲んだ部分）。 Olio アプリケーションの結果はさらに悪く、580 ms ものレイテンシが 1 分間も継続してい ます。さらに 40 ∼ 170 ミリ秒のレイテンシの連続が数分間にわたって続く部分もあります。 いずれのアプリケーションもトランザクションの応答は、10 倍から 100 倍近くのオーダー で低下しています。このようなスロー・ダウンが、例えば特別セールのあるときや休日など の繁忙時に起こると、売上げを大きく損なうことになります。 Spirent テスト・ツールでトラフィック・スパイクを加えたときの、帯域幅の測定値は、DVD ストアと Olio のアプリケーションに対して、それぞれ図 9 と図 10 のようになりました。 図 9： DVD ストア・アプリケーションでの ESXi のディスク I/O 帯域幅： Spirent トラフィック・スパイク 10 図 10： Olio アプリケーションでの ESXi のディスク I/O 帯域幅： Spirentトラフィック・スパイク ここで注目するべき点は、帯域幅にはベース・テストと比べて大きな違いが見られないこと です。ネットワークが、アプリケーションのストレージ I/O の要求にどれだけ応えられるかは、 帯域幅だけではよく評価できないことを実証しています。 I/O リクエストのレイテンシも測 定しなければ実態が見えません。ネットワークは、帯域幅を提供することを考えて設計され ますが、重要な IP ストレージのワークロードには、レイテンシのもつ意味の方がずっと大き く、このことは見過ごされがちです。これは例えば、プリンタや Web アプリケーションのた めにネットワークを設計する場合と、ティア 1 アプリケーションのストレージ・トラフィックの ためにネットワークを設計する場合の重要な違いになります。 同じくテスト結果から分かるのは、スイッチ間リンクに、小さな輻輳が一時的に起こっただ けでも、 さらに平均値で見て、 リンク帯域幅の 50 ∼ 60 パーセントしか消費していなくても、 アプリケーションのトランザクション処理に大きな低下が広範囲に起こっていることです。帯 域幅の平均要求量が設備能力を超えていなくても、短時間のトラフィック・スパイクが、ビ ジネス・アプリケーションの応答をスロー・ダウンさせて、技術サポートへの電話や苦情に つながるということになります。 結論 以上をまとめると、大きな環境の IP ストレージは、ブロック・ストレージ（iSCSI）の場合 も NAS ストレージ（CIFS、NFS）の場合も、物理ネットワークを別に用意することによって、 次のような多くのメリットがもたらされます。 • • • • • 確定的で小さなレイテンシ 伝送の保証 管理ドメインの縮小とトラブルシューティングの効率化 制約を受けない自由なコンフィグレーション 障害の隔離 • メンテナンスとアップグレードの簡素化 • コンフィグレーション これらの中で、確定的で小さなレイテンシの確保は、トラフィックのわずかな時間のスパイ クが大きく影響します。わずかなスパイクでも、ストレージ I/O に大きな待ち時間が出て、 アプリケーションのトランザクション処理の能力を低下します。データ伝送の保証のために TCP を使うしかない場合、スロー・スタート機能の副作用によって、I/O レイテンシに数分 のオーダーの増加が起こって、アプリケーションの応答が大きく低下することがあります。 この現象が起こっている場合の診断と解消は、非常に複雑で時間のかかるものになります。 つまりデータセンターの IP ストレージの設計では、ブロック・ストレージでも NAS ストレー ジでも、ストレージ専用の IP ネットワークを使用して簡素化を図ることが、大きなメリット をもたらします。大手のアプリケーション・ベンダーが、設計のベスト・プラクティスとして、 これを推奨する理由もそこにあります。 11 Brocade VCS ファブリックは、IP ストレージ・トラフィックに合った特長をもち、特に NAS サーバや、I/O 量の大きな NAS クライアントの接続に優れています。 VCS ファブリックは、 STP を使用する通常のイーサネットと比べて、一時的な輻輳の影響を最小限に抑えること ができます。従来イーサネットの一連の 802.1 プロトコルや、802.3ad による標準 LAG との相互運用性によって、既存ネットワークの最重要部分を、シンプルに VCS ファブリック へアップグレードすることができます。 ブロケードについて ブロケードのネットワーキング・ソリューションは、企業が重要なビジネスのイニシアティブ を発揮できるよう、アプリケーションと情報が各所に遍在する世界への移行を支援します。 今日ブロケードでは、データセンターで実証された、ネットワーク全体にわたる専門知識を 広げ、オープンで効率的な仮想化ソリューションによって、コンソリデーション、仮想化、ク ラウド・コンピューティングを実現していきます。詳細については、Web サイトをご覧くだ さい。 www.brocadejapan.com ブロケード コミュニケーションズ システムズ株式会社 〒 100-0013 東京都千代田区霞ヶ関 1-4-2 大同生命霞ヶ関ビル TEL.03-6203-9100 FAX.03-6203-9101 Email:[email protected] BROCADE に関するより詳しい情報は、以下の Web サイトをご覧ください。 http://www.brocadejapan.com © 2015 Brocade Communications Systems, Inc. All Rights Reserved. 09/15 GA-WP-1904-00-J ADX、 Brocade、 Brocade Assurance、 B-wingシンボル、 DCX、 Fabric OS、 HyperEdge、 ICX、 MLX、 MyBrocade、 OpenScript、 The Effortless Network、 VCS、 VDX、 およびVyattaは登録商標であり、 米国またはその他の国におけるBrocade Communications Systems Inc.の商標です。 その他の Vplane、 Fabric Vision およびvADXは、 ブランド、 製品名、 サービス名は各所有者の製品またはサービスを示す商標またはサービスマークである場合があります。 注意：本ドキュメントは情報提供のみを目的としており、Brocadeが提供しているか、今後提供する機器、機器の機能、 サービスに関する明示的、暗示的な保証を行うも のではありません。Brocadeは、本ドキュメントをいつでも予告なく変更する権利を留保します。また、本ドキュメントの使用に関しては一切責任を負いません。本ドキュ メントには、現在利用することのできない機能についての説明が含まれている可能性があります。機能や製品の販売/サポート状況については、Brocadeまでお問い合 わせください。