プライベートクラウドを構築するに当たって、ネットワークは数年先を見据えて準備をしておくべきものです。ただし、従来の一般的なネットワーク技術や、その場しのぎで構築した設備では、プライベートクラウドのインフラとしての要件に合うとはいえません。今までのネットワークと違った点を認識し、構築する必要があります。例を三つ挙げます。
・プライベートクラウドは、ユーザーに資源の場所を意識させないなかで、災害対策を施されている必要があります。しかし、メインのデータセンターで稼働しているサーバーと、待機系のデータセンターで稼働しているサーバーが同じIPアドレスを持ち、災害対策時には最低限の対応で切り替えができる機能を持つ高可用性を意識したデータセンターはまだ少ない状況です。
・法規制の順守やTCO削減のために、ますますプライベートクラウドを形成するデータセンターにデータが集中し、重要性が増しているにもかかわらず、従来の機器や技術を流用し、単なる統合とその延長としての仮想化環境を使用することによって、セキュリティに対する弱点や運用コストの増大を招いている、もしくは招く恐れがあります。
・クラウドコンピューティング環境では、今までのデータセンターサービスでは要求されなかったような「急激なトラフィック増」や「即日での変更への対応」などが求められます。そのためには、柔軟に変更できるネットワーク環境や、予測を可能にする情報収集をしておく必要がありますが、十分に整備されていないのが実情です。従来のレベル以上に、資源の使用状況や品質を数値化する必要があると考えられます。
では、これらの課題をどうやって技術的に解決すればよいのでしょうか。「サービスの継続性」「サービスの安定性」「サービスの迅速な提供」の三つの観点において、今後の技術トレンドを踏まえながら解説します。今回は継続性と安定性を取り上げます。
ネットワークサービスの継続性
災害対策のために最低二つのデータセンターを用意し、ユーザーはどちらのデータセンターを使っているか意識せず通信できる必要があります。二つのデータセンターは、「常時稼働（アクティブ・アクティブ）」、もしくは「稼働と常設待機（アクティブ・ホットスタンバイ）」の状態で構成します。対応方法としては、主に二つあります。
（A）トラフィックを接続させたいサーバーが存在するデータセンターへ誘導
（B）複数データセンターを論理的に一つに見せるネットワークを構築
（A）には次のような方法があります。どれを選択するかは、アプリケーションの要件と適用可能かどうかの判断が必要です。
・DNSによって誘導するグローバルサーバーロードバランシング（Global Server Load Balancing：GSLB)
・HTTPのステータスコードを使用したHTTPリダイレクト
・稼働しているサーバーのIPもしくは代表IPアドレス（つまり特定のホストを表すホストルート）とメトリック値をデータセンターまでのルーティングテーブルに注入
（B）は、レイヤー2のネットワークをデータセンター間で接続し、データセンターに届いたトラフィックをローカルやリモートを意識することなく通信可能にする方法です。比較的近距離であればダークファイバーやDWDM装置を使うことで実現できます。
省コスト性を重視する場合、またデータセンター間が長距離の場合には、すでに敷設されていてより低コストな回線を利用できるEoMPLS （Ethernet over MPLS)やVPLS（Virtual Private LAN Service)、さらに安全性と容易性を兼ね備えた新しい技術を使うこともできます。
