オルタナティブ・ブログ > 情報インフラ24時 眠らないシステム >

「仮想化」をキーワードに情報インフラの世界を考察します。

データセンター同士をつなげたリソースプールを実現するNW技術 座談会@NEC本社

»

障害原因となっている機器をメンテナンスするために一時的にアプリケーションを止めたいが、業務への影響が発生するのでいつも苦労しているという現場は多いのではないかと思います。

以前までは、業務側と計画停止の調整を行って土日祝日にシステムを停止するくらいしか方法がありませんでしたが、仮想化環境が企業内で浸透するにつれ、平日のシステム利用時間外にライブマイグレーション(動的変更)を行って、別の物理サーバ上で仮想サーバを退避&稼働させることをやるようになってきてます。

※ライブマイグレーションの簡単な説明はこちら
http://www.atmarkit.co.jp/fwin2k/operation/livemig01/livemig01_01.html

 

ただ、このとき工数上のネックになりがちなのが、通信経路変更に伴うネットワーク機器の再設定です。特に、物理拠点が異なる場所にあるサーバ上へライブマイグレーションを行う場合、設定が不十分だと通信不能に陥ることもあります。

これら失敗の原因は、論理ネットワークに関する情報が十分に可視化されておらず、ネットワーク管理者が構成情報を把握できていないことが大きく、従来の製品群ではここをワンストップでカバーするものを見つけることは難しかったのです。

ところが、先日NECさんの座談会で説明頂いた「UNIVERGE PFシリーズ」(プログラマブルフロー)というネットワーク機器は、まさにこの点をカバーしているものだったので、このエントリーで紹介したいと思います。
 

『クラウドネットワークプラットフォーム UNIVERGE PFシリーズ
(プログラマブルフロー)』
http://www.nec.co.jp/datanet/pflow/

 

この製品の最大の特徴は、ネットワークのシンプル化を実現するプログラマブル・フローというアーキテクチャです。

概念図は上記の製品紹介リンクを参照すれば分かりますが、OpenFlow(オープンフロー)というNW制御技術を使って、パケット転送機能と経路制御機能を分け、通信トラフィックをフロー単位(通信されるデータ単位)に制御することで、経路制御、ネットワーク仮想化、可視化を実現しているのです。

このあたりの説明は、同じく座談会に参加されていた小俣さんが書かれているので、詳しくはそちらを御覧ください。

『OpenFlowで何が変わるのか?座談会@NEC本社』
http://blogs.itmedia.co.jp/komata/2011/07/openflownec-b3c3.html

ネットワーク技術に詳しくない方は、「ネットワークの管理をシンプルにして耐障害性を高め、かつシステムの管理負荷(工数)を軽減できるソリューション」だと思って下さい。概ね間違っていません。

この製品の説明を受けて、私がスゴイと感じた点を列挙しましょう。

【メンテナンス負荷軽減という観点】

  • 物理ネットワーク構成図に加え、論理ネットワーク構成図にNW機器や仮想ブリッジ、仮想ルータを紐付けてGUIで管理可能。
  • コントローラにスイッチを追加するのはUSBのプラグアンドプレイと同じ感覚。
  • 1週間もあれば、ユーザ企業のネットワーク担当者が習熟可能。

【業務継続性・コンティンジェンシーへの寄与という観点】

  • ディザスタリカバリ(DR)については、ラスベガスのインターロップで受賞した。詳しくは下記リンク先の図を参照。
    http://www.geekpage.jp/blog/?id=2011/6/17/1
  • VMwareを使い、拠点を跨いだライブマイグレーションが可能。ループに強いこの製品だからこそ実用レベルの実装ができた。
  • 仮想化ベンダー(特にVMware)と検証を重ねてきた実績のあるソリューション。

【コスト抑制という観点】

  • NECのSAPシステムのNW環境をOpenFlowにリプレースし、NW機器数を大幅に集約。
  • 1サイトで2台の専用コントローラと2台の互換スイッチが推奨最小構成。最大は25台のスイッチ。ネットワーク機器の通信負荷が高まってきたら、新たなスイッチを追加することで負荷軽減可能。これにより、スモールスタートからネットワークのリソースプールを実現。

もちろん、こういった先進技術は良い点だけではありません。基幹技術は安定しているといえども、それを支える支援技術がまだ実装途中だったりします。それはこのOpenFlowも例外ではありません。

  • マルチサイトのコントローラを一元管理することはできず、サイトごとの管理になる。2012年には対応可能となる。
  • 物理ノードに紐付く論理ノードは簡易に検索する機能をまだ実装していない。
  • (ただし、特定ノードを利用不可とした際、関連する論理ネットワークは当該箇所を迂回するルートを自動再設定する)
  • FCoE(ファイバチャネル・オン・イーサ)への対応は今のところ未定のため、ストレージレベルの拠点間データ同期との組み合わせたソリューションはSIerによるソリューション提案が必要。

これらは時間が解決する問題です。実際、以下のような対応がNEC、標準化団体によって行われていると聞いています。

  • 今はL4レベルまでの通信経路ポリシー決めだが、さらにデータ部の条件組み合わせによるポリシー作成が可能になることを目指している。
  • 他社では、現時点でOpenFlowを商用化できているところはない。世界でNECのみ。規格事態は標準化団体(有力プレイヤーが多数参加)で定められており、今後は世界中で同技術によるNW製品が発表されると思われる。


OpenFlowを用いたUNIVERGEというこの製品のビジネスターゲットは、大量のトラフィックを捌くことが重要なデータセンター業者、もしくはネットワークパフォーマンスに苦労しているユーザ企業です。

興味のある方は、NECへ問い合わせてみてはいかがでしょうか。

Comment(0)