IP ルーティング

分散型データセンター向け Cisco Locator/ID Separation Protocol および Overlay Transport Virtualization データセンター インフラストラクチャ ソリューション

ホワイトペーパー





分散型データセンター向け Cisco Locator/ID Separation Protocol および Overlay Transport Virtualization データセンター インフラストラクチャ ソリューション



概要


アプリケーションが異なれば、必要なネットワーク接続も異なります。データセンターが地理的に分散していく中で、異なるアプリケーションをサポートするにはレイヤ 2 とレイヤ 3 を組み合わせたネットワーク接続が必要です。このドキュメントでは、分散型データセンター インフラストラクチャ全体にわたるサポートが必要な場合のあるアプリケーションの種類・その性質について説明します。また、Cisco® Locator/ID Separation Protocol(LISP)テクノロジーと Overlay Transport Virtualization(OTV)テクノロジーの使い分けに関する推奨事項についても説明します。

説明するシナリオは、次のとおりです。

  • LISP および OTV の組み合わせによる分散クラスタのサポート
  • LISP によるディザスタ リカバリの効率化
  • LISP によるサードパーティ(クラウド)施設へのワークロードの移転

このドキュメントは、主に Technical Decision Maker(TDM; 技術的な意思決定者)とネットワーク設計者および運用者を対象としています。また、TDM とコラボレーションする Business Decision Maker(BDM; 業務の意思決定者)にも有益な情報を提供します。

はじめに


昨今のデータセンター展開において主流となっている傾向は、地理的に分散した場所にあるデータセンターを集約する仮想データセンターの構築です。一般に、複数の場所にデータセンターを分散するのはその復元力と容量を向上させることを目的としています。高い復元力と追加の容量を柔軟に使用できるようにするには、複数のデータセンターが 1 つの仮想データセンターとしてモデル化され、ワークロードをさまざまな場所にシームレスに移動、分散可能になっていることが必須条件となります。

また、データセンターのスペースに関するもう一つのトレンドとして、非常に高密度で低コストの汎用サーバの利用が増えていることが挙げられます。このようなサーバは、独立したユニットとしては仮想化を幅広く展開するのに十分な容量を提供し、グループ化すれば高容量で復元力のある分散クラスタ型アプリケーションのメリットが得られる理想的なインフラストラクチャとなります。このトレンドによって、サーバ間のトラフィック量は著しく増加しました。

これらのトレンドは、データセンターのネットワーキング インフラストラクチャに対して高い接続要件を突きつけました。データセンターは、大容量のサーバ間トラフィック、シームレスなモビリティ、無数のエンドポイントでのワークロードの再ローカリゼーションをサポートする地理的に分散したデータセンターに対して、継続的な接続性を提供しなければなりません。

仮想データセンターが現実のものとなれば、地理的に異なる場所にワークロードを移動させることは一般的になります。ワークロードの移動は、状態を保持して行うライブ マイグレーションか、より計画的かつ長距離の移動を可能にするコールド マイグレーションのいずれかの形式で実施します。

次世代の技術である LISP や OTV を併用することにより、こうした新たな IP そしてイーサネットの接続要件に応えることが可能となります。

アプリケーション プロファイル


仮想データセンター内の物理的なデータセンター間で必要なネットワーク接続は、データセンターで利用されるアプリケーション タイプによって決まります。ここに挙げる一般的なアプリケーション パラメータは、さまざまなアプリケーション プロファイルをサポートするために必要なネットワーク接続の理解に役立ちます。

  • ルーティング可能なアプリケーション:現在、データセンター上のほとんどのアプリケーションは IP ベースであると想定できます。
  • ルーティングできない既存アプリケーション:いくつかの既存アプリケーションは IP を使用しておらず、イーサネット ベースか、あるいは、古いプロトコルを使用しています。
  • クラスタ型アプリケーション:いくつかのアプリケーションはクラスタ化され、アプリケーション クラスタ メンバー サーバ間では多くの場合、非 IP のリンクローカル マルチキャスト シグナリングを使用しています。これらのアプリケーションのピア検出・ハートビート以外の通信は、通常、すべてルーティング可能な IP トラフィックです。
  • 仮想化アプリケーション:一般的なアプリケーションは仮想マシン上で実行でき、ライブ モビリティを行う可能性があります。

Cisco LISP 仮想マシン モビリティ


Cisco LISP Virtual Machine Mobility(LISP VM-Mobility; LISP 仮想マシン モビリティ)ソリューションでは、どのホストも IP アドレスを保持しながらネットワーク上のどこへでも移動できます。これによって、ホストの変更を行うことなくサブネットのメンバーをさまざまな場所に分散でき、同時にネットワークの最適なルーティングとスケーラビリティを維持することができます。

Cisco OTV テクノロジー


OTV は、レイヤ 2 接続を複数の場所にセキュアに拡張します。レイヤ 2 接続の拡張には、クラスタ型アプリケーションにとって重要なブロードキャスト トラフィックとリンクローカル マルチキャストの処理が含まれています。レイヤ 2 接続を複数の場所に拡張することで、OTV は関連する IP サブネットを複数の場所に拡張することになります。このレイヤ 2 ネットワークの拡張によって、ルーティング上の問題が発生しますが、これは LISP を使用することで解決可能です。このため、LISP と OTV は相互補完的なテクノロジーになっています。

OTV、LISP、あるいはその 2 つを併用するそれぞれの状況


OTV は、アプリケーションでサーバ間のリンクローカル マルチキャストや非 IP ユニキャスト通信などの非 IP(レイヤ 2)通信が必要なときに、サーバ間通信で使用します。現在、このカテゴリに入るほとんどのアプリケーションはクラスタ型です。そのようなアプリケーションの場合、アプリケーション メンバー サーバが置かれている複数の場所もカバーされるように LAN を拡張する必要があります。OTV により、こうした非 IP トラフィックをサポートするように LAN をセキュアな方法で拡張することが可能になります。

LISP は、仮想データセンター内のモビリティと場所の独立性をサポートしながら最適なルーティングを提供する際に必要になります。この要件は、アプリケーションでレイヤ 2 接続の拡張を必要とすることとは別です。その他のルート最適化のアプローチを採ることもできますが、LISP を推奨します。

OTV と LISP を併用:ライブ仮想マシン モビリティと分散クラスタ


サーバ間でリンクローカル マルチキャスト通信を必要とするアプリケーションは、通常はクラスタ型アプリケーションです。クラスタ型アプリケーションは、ピア検出や Hello メッセージおよびハートビート信号の交換にシンプルなリンクローカル マルチキャスト メカニズムを使用します。クラスタ メンバーが分散している理由には、VMware vMotion などの仮想マシン モビリティ ツールを使ってサイト間で仮想マシンを移動させたか、単純にサーバを静的分散させた可能性が考えられます。クラスタ メンバーの分散方法にかかわらず、クラスタ型アプリケーションでは、仮想化の利用に関係なく、リンクローカル マルチキャスト トラフィックが必要になります(図 1 を参照)。

図 1 アプリケーションはルーティング可能なトラフィックとルーティング不能なトラフィックの両方を活用

図 1 アプリケーションはルーティング可能なトラフィックとルーティング不能なトラフィックの両方を活用


VMware は現在、サイト全体に拡張 LAN がある場合に限り、サイト全体での vMotion のライブ マイグレーションをサポートしています1。OTV と LISP の組み合わせも、似たような方法で使用することで、クラスタのシナリオと VMware vMotion のライブ マイグレーションのシナリオに対応できます。このことから、ここでは両アプローチについて合わせて説明します。これら 2 つのシナリオの組み合わせは、仮想化インフラストラクチャ上で実行するクラスタ型アプリケーションと、そのクラスタ型アプリケーションでサポートされるライブ モビリティでも使用できます。

クラスタ メンバーが複数の場所に分散された場合、それらの場所に LAN を拡張して、ピア検出やハートビートに使用する非 IP トラフィックの転送をサポートする必要があります。OTV は、複数サイトに LAN を拡張しクラスタ内のサーバ間における非 IP 通信をサポートするために必要な機能を提供します。

アプリケーションのどのレイヤが分散されているかによって、クラスタ メンバーは IP ネットワーク経由でクライアントと通信しなければならない場合があります。LAN が複数の場所に拡張されると、この LAN に関連する IP サブネットもこれらの場所に拡張されます。従来のサブネットは、通常、物理的に単一の位置情報を保持しますが、ここでのサブネットは OTV などの LAN 拡張技術により複数の場所に拡張されているため、サブネットに本来付随している位置情報は失われます。従来のルーティングでは、拡張されたサブネットのどこにサーバがあるのかを知ることができません。その結果、多くの場合は最適とは言えないルーティングが起きます(図 2 を参照)。

図 2 拡張サブネット内での仮想マシン モビリティに対するルーティングの最適化

図 2 拡張サブネット内での仮想マシン モビリティに対するルーティングの最適化


サブネットが拡張されると、LISP はさまざまなレベルでの位置情報を処理し、拡張サブネット内の適切な場所にルーティングするための最短パスを提供し、図 2 にあるような最適ではないトラフィック パターンを回避します。このようにして、LISP は LISP を利用しない場合には存在しない、拡張 LAN における位置情報を提供します。LISP と OTV の組み合わせは、アプリケーションの各メンバーの最適なルーティングを維持しながら、アプリケーションを複数の場所に分散させる相互補完的なアプローチを提供します。この LISP と OTV を併用する環境では、VMware vMotion のライブ マイグレーションもサポートされます。これによって、アプリケーション要件がサポートされるだけでなく、ローミングを行う仮想マシンへの到達性が、その移動先にかかわらず保証されます。

LISP によるディザスタ リカバリの効率化


サーバ ロケーションの変更に関する一般的なシナリオには、ディザスタ リカバリもあります。ディザスタ リカバリ用データセンターは一般に、稼動中のメイン データセンターから遠く離れた場所に位置し、メイン データセンターがオフラインになるような危機的状況に陥った場合のみオンラインになります。

メイン データセンターとディザスタ リカバリ用データセンターとの距離は通常、ストレージ データの同期レプリケーションが実行できないほど離れています。さらに、ディザスタ リカバリ手順の性格上、施設がオンラインになるのは大抵の場合、予期せぬ事態が発生したときです。こうした理由から、ワークロードとアプリケーションは、障害発生時のデータ損失を抑制するために設計されたポイントインタイム チェックポイントを使用してディザスタ リカバリ施設に再配置されます。言い換えれば、ディザスタ リカバリ施設へのワークロードのライブ マイグレーションはできませんが、アプリケーションのコールド マイグレーションは、使用可能なアプリケーション データの最新コピーを使って実行できます。

ディザスタ リカバリ施設をオンラインにすることは、複雑なプロセスです。従来の復元手順では、アプリケーションがディザスタ リカバリ用データセンターに再配置されるとアプリケーションの IP アドレスの変更が必要でした。アプリケーション ノード アイデンティティを運用場所から切り離すことによって、LISP はアプリケーションが新たなディザスタ リカバリ用のデータセンターに移動したあとでも、オリジナルの IP アドレスの維持を可能にします。アプリケーションの IP アドレスを維持できることで、ディザスタ リカバリ用データセンターにおける復元手順が効率化され、運用全体が迅速になります。最終的に、合理化されたプロセスによって、障害発生時のダウンタイムの短縮が可能となります。

前述したように、こうした状況での最終目標は、ディザスタ リカバリ用データセンターとメイン データセンターに分散されたクラスタ型アプリケーションの実現や、ライブ モビリティではありません。このシナリオでは、全アプリケーションと全アプリケーション メンバーの完全な再配置が行われます。したがって、レイヤ 2 接続は必要なく、OTV もこのシナリオでは必要ありません。ただし、さまざまなアプリケーションとネットワーク サービスの IP アドレスを維持できることは大きな利点であり、それこそが LISP がディザスタ リカバリにもたらす大きな違いです(図 3 を参照)。

図 3 サブネット全体でのホスト モビリティに対するルーティングの最適化

図 3 サブネット全体でのホスト モビリティに対するルーティングの最適化


LISP によるクラウドの促進


前述のディザスタ リカバリ シナリオでは、マシンを停止させてから別の場所で再開させるコールド マイグレーションを取り上げました。次のシナリオは、既存の接続を必ずしも維持せずにワークロードを再配置するための計画的なコールド マイグレーションに関するものです。

計画的なコールド マイグレーションでは、アプリケーションを停止し、状態およびストレージ データの必要なものすべてを目的の場所にレプリケーションしてから、新しい場所でアプリケーションを再開します。別の場所にワークロードを再配置するこのシンプルなアプローチは、クラウド モデルのインフラストラクチャ サービスとも呼ばれます。現行のデータセンターの容量枯渇を補完するために再配置を実行することはクラウド バーストと呼ばれ、メイン データセンターのリソース容量がオーバーフローした状態を指します。

ワークロードは、企業が管理するデータセンター施設にバーストさせるか、Infrastructure as a Service(IaaS; サービスとしてのインフラストラクチャ)クラウド プロバイダーなどが提供するサードパーティの施設に再配置することができます。いずれの場合も、データセンター間でレイヤ 2 接続を必要としないコールド マイグレーションが実施されます。ただし、IP アドレスが指定されている場所と切り離す形で IP アドレスは使用されます。LISP はこのような形で機能するように設計されており、どこに存在する IP アドレスでも現行のルーティングの再コンバージェンスまたは再構築なしに利用できます。

ストレージと仮想化のテクノロジーが進化する中で、クラウド施設へのライブ マイグレーションは現実的な目標となるでしょう。Cisco LISP VM-Mobility ソリューションでは、こうした施設間でのライブ マイグレーションに今すぐ対応でき、移動するエンドポイントの最適なルーティングを行いながら、異なる場所の異なるサブネットにアクティブなワークロードが移動してもアクティブ セッションを維持できます。

まとめ


LISP と OTV は、地理的に分散したデータセンター間に必要な接続を提供する補完的なソリューションです。サポートするアプリケーションのタイプやデータセンターの場所の役割に応じて、LISP 単独または LISP と OTV を組み合わせて利用することで、IP インフラストラクチャに求められる「ロケーションの柔軟性」を適切に提供することが可能になります。

関連情報


Cisco LISP、OTV、および LISP VM-Mobility ソリューションの詳細については、次のリンクを参照してください。




1 現在のところ、VMware で VMware vMotion のライブ マイグレーションをサポートするにはサイト全体に拡張 LAN が必要です。

お問い合わせ