注目ブログご紹介

OpenStackはvCPEに使えるのか?


投稿者:Charlie Ashton, 5/3/2016

仮想CPE(vCPE)は、ネットワーク仮想化のビジネスチャンスに力を注ぐ企業にとって、今注目の話題です。IHS Infonetics社が世界のサービス事業者を対象に実施したアンケート調査では、2016年のNFV(Network Functions Virtualization)ユースケースのトップは、仮想ビジネスCPE(vBCPE)でした。Analysys Mason社の報告書によると、vBCPEは先行導入したサービス事業者に、北米と西ヨーロッパだけで5年間に14億ドルの新たな収益を生む可能性があります。運用コストを削減しながら売上高の増大を目指すサービス事業者の経営陣にとって、実に魅力的な話です。

ところが、昨年10月にデュッセルドルフで初めて警鐘が鳴らされました。SDN and OpenFlow World Congressで、BT社のピーター・ウィリス氏が「NFVはクラウドとどう違うのか:分散NFVへのOpenStackの利用」と題したプレゼンテーションを行いました。その中で、vCPEのようなアプリケーションへの利用を制限しかねない、OpenStackの6つの重大な限界が指摘されました。ピーターの見解は広く報じられました。たとえば、Light Reading社のこの記事は、その内容をうまくまとめています。

ウインドリバーでは、OpenStackをベースにして、超高信頼性サービス、最適化されたVNFパフォーマンス、仮想マシンの包括的なライフサイクル管理を実現する、NFV基盤向けソリューションを提供しています。ウインドリバーのポートフォリオには、Titanium Server CPEプラットフォームがあります。その名のとおり、宅内でスモールフットプリントのvCPEを展開するのに最適化されたプラットフォームです。

私たちはウインドリバーのソリューションが、ピーターに指摘されたOpenStackの課題に対処できるように、懸命に取り組んできました。5月17日に私たちはピーターと一緒にウェブセミナーを開催します。課題を詳細に検討し、それらをTitanium Serverによってどのように解決できるかを説明します。

vCPEの話題に興味があれば(なければ、このブログ記事を読んでいないと思いますが)、今すぐ登録して、ぜひこのウェブセミナーに参加するとともに、技術的に詳しく説明したホワイトペーパーをダウンロードしてください。

ウェブセミナーまで待てない方のために、以下にピーターのOpenStackの6つの問題点を手短にまとめます。ウェブセミナーに参加する、またはホワイトペーパーを読んで、これらの課題をいかに解決できるかを知っていただければ幸いです。

課題1:仮想NICとVNFのバインド

VNF(Virtual Network Function)によっては、仮想ネットワークインタフェースカード(vNIC)が決まった順序で初期化され、特定のネットワークに接続される必要があります(例:vNIC0は管理ネットワーク、vNIC1は補助ネットワーク、vNIC2はLAN、vNIC3はWAN)。vBCPEのディターミニスティックな動作を確保するには、常に正しいVNFインタフェースが正しいvNICに接続されていることが重要です。特に、インタフェースが切断して再接続された後は注意が必要です。しかしながら、一般のOpenStackディストリビューションを使ったテストでは、接続が間違って回復されるケースや、VNFが異常停止するケースがあることが判明しています。

課題2:vCPEサービスチェーンの変更

これは、顧客に指示された新しいサービスを追加するために、vCPEサービスチェーンを迅速に再構成する際の俊敏性とニーズに関わる問題です。たとえば、ルータとファイアウォールを導入済みの顧客が、WANアクセラレーションを追加しようとする場合を考えてみましょう。

OpenStackには、ファイアウォールインタフェースをルータからWANアクセラレータに再接続するのに必要なプリミティブがありません。選択肢は次のどちらかです。(1)ファイアウォールインタフェースを削除して再接続する。この場合、ファイアウォールルールは特定の仮想NICに紐付けられているため、曖昧さを生じるおそれがあります。(2)新しいサービスチェーンを新規にプロビジョニングする。この場合、5分以上のサービス停止が生じます。

課題3:数百のコンピュータノードをサポートする際のOpenStackベースコントローラの拡張性

エンタープライズクラスのvCPE実装には、数百のコンピュートノードをサポートするために、OpenStackベースの制御ノードが1つ(または冗長ノードのペアが)必要になる場合があります。制御ノードは宅内の各拠点にリモートに配置したり、サービス事業者のデータセンターやセントラルオフィス(CO)にローカルに配置することができます。OpenStackコミュニティのディストリビューションは、このレベルの拡張性を確保するためのテストが行われていません。そのため、サービス事業者には2つの選択肢しかありません。テストの負担(および必然的にパッチ対応)を自社で担うか、一般のディストリビューションをデプロイして、それに伴うリスクや拡張性を未確認のまま受け入れるかです。どちらも許容できる対応ではありません。

課題4:起動時のストーム(「アクセスの殺到」)

光ファイバーリンクが切断して、その後回復すると、どんな状況が発生するでしょうか。数百、数千のコンピュートノードが、1台の集中コントローラに同時に接続しようとします。

通常、各コンピュートノードは複数のSSHセッションを実行することになります、復旧プロセスは時間がかかり、計算負荷も高くなります。

テストで明らかになったように、標準のOpenStackコントローラは、このシナリオに対応するにはレジリエンスが不十分です。過負荷状態になり、復旧しない可能性もあります。

課題5:インターネット経由でのOpenStackのセキュア化

集中制御ノードがデータセンターやサービス事業者のCOに配置されるvCPEシナリオでは、制御ノードはインターネット経由でコンピュートノードと通信を行います。

BTが参照したラボテストでは、この接続シナリオを運用可能にするには、VNC用のポートやCLI用SSHなど、500以上のピンホールをファイアウォールに開く必要がありました。コンピュートノードの動的IPアドレスが変わるたびに、ファイアウォールの再構成が必要でした(テスト中に数回発生)。

OpenStackは、集中制御と分散コンピュートというこのモデルでは、重大なセキュリティ課題をもたらします。OpenStackの設計は、インターネット経由でのセキュア化を妨げる攻撃ベクトルが多すぎます。

課題6:リリース間の後方互換性

vCPEアプリケーションでは、制御ノードとコンピュートノードの双方で、同一バージョンのOpenStackを実行する必要があります。OpenStackの新バージョンは約半年ごとにリリースされます。ダウンタイムやサービス停止を招くことなく、制御ノードとコンピュートノードを同時にアップデートできることが重要です。

5月17日のウェブセミナーでは、上記の問題の解決方法について検討します。ぜひ、今すぐ登録してください。皆さまのご参加をお待ちしています。vCPE導入の成功に非常に重要なテーマだと考えています。