目次


Software Defined Networking を使用して IaaS を最適化する

クラウド・インフラストラクチャーを強化するためにソフトウェア抽象化層を介してネットワーキングの管理を行う

Comments

SDN (Software Defined Networking) とは、管理者がネットワーク・サービスを管理できるように、下位レベルの機能を抽象化する、ネットワーキング手法です。SDN は C-Plane (制御プレーン)— トラフィックの送信先を決定します — と D-Plane (データ・プレーン)— 選択された宛先にトラフィックを転送します — を分離します。

この記事では、IaaS の最適化を目的とした、SDN とクラウド・インフラストラクチャー・サービスとの組み合わせについて、以下の点に重点を置いて説明します。

  • IaaS の相互運用性の確保
  • IaaS クラウド・サービス・モデルのフル活用
  • OpenStack Foundation プロジェクトと OpenDayLight プロジェクトを利用した、ユーザー、開発者、プロバイダー、保守担当者の期待値を満たすための対応
  • IaaS 最適化に伴うリスクを軽減するコスト効果の高い方法の提供

IaaS の相互運用性

ネットワーク管理者は、SDN アーキテクチャーと NFV (Network Functions Virtualization) を併せて使用することで、IaaS の相互運用性の目標を達成することができます。NFV アーキテクチャーの概念では、仮想化テクノロジーを使用して、あらゆるクラスのネットワーク・ノード機能をビルディング・ブロックに仮想化することを要求しています。このようにすれば、ビルディング・ブロックを相互に接続して通信サービスを作成できるようになります。このような仮想化されたネットワーク機能のそれぞれは、クラウド・インフラストラクチャー上でそれぞれに異なるソフトウェアやプロセスを実行している可能性がある 1 つ以上の仮想マシンで構成することもできます。

SDN アーキテクチャーを使用すると、管理者は中央コンソールから、IaaS におけるネットワーク機器間のトラフィックの動向の全体像を把握することができます。また必要であれば、互換性のある IaaS へトラフィックを移す前に、トラフィックをどのようにして最適化すればよいかを SDN アーキテクチャーに詳述することもあります。

SDN アーキテクチャーの中核となるのは、コントローラーです。コントローラーはオープンソースのアプリケーションであり、専用のネットワーク機器の制御機能をデータ機能から切り離します。あるネットワーク機器にトラフィックが集中してきた場合、管理者はコントローラーを使用して、そのネットワーク機器に対し、パケットをリダイレクトまたは再送信する宛先を指示します。管理者は必要に応じて、IaaS に VM を追加することもできます。VM を追加するのは、例えばパフォーマンスが低下しているネットワーク機器から、正常に動作しているネットワーク機器へ大量のデータを移す場合などです。

NFV は、ネットワーク・アドレス変換 (NAT)、ファイアウォール、侵入検知、ドメイン・ネーム・サービス (DNS)、キャッシングなどの機能を専用のハードウェア・アプライアンスから切り離し、これらのネットワーク機能をソフトウェアで制御できるようにします。NFV が、完全に仮想化されたネットワーキング・インフラストラクチャーをサポートするために必要なネットワーキング・コンポーネントを統合するというわけです。

SDN/NFV コントローラーが適切に構成されていなければ、管理者がネットワーク・トラフィックのフローを最適化したり、その他の変更をしたりすることはできません。不適切な構成によって、IaaS のサービス停止やセキュリティー攻撃という結果に至る恐れがあるからです。適切な構成にするには、OpenStack や OpenDayLight などのオープンソース・プロジェクトを利用することができます。

OpenDayLight では、ネットワーキングの専門家のうち、どれだけ多くの人が SDN ソリューションに、営利団体が提供するオープンソースを選んでいるかを把握するために調査を行いました。その調査レポートでは、北米の企業 (300 社) の中規模から大規模の組織と、サービス・プロバイダー (300 社) の組織に属する 600 人の IT 意思決定者および技術者を対象としました。調査の結果、SDN ソリューションにオープンソースを使用したいと答えたネットワーキングの専門家は全体の 95% に上った一方、そのうちの 76% は、営利団体が提供するオープンソースを選んでいることがわかりました (「SDN, NFV, and Open Source: The Operator's View」を参照)。

営利団体が提供するオープンソースを選択する場合、SDN/NFV コントローラーを利用して IaaS を最適化することができます。

IaaS クラウド・サービス・モデル

SDN を使用した場合に IaaS の最適化がどのように機能するかをよりよく理解するには、IaaS クラウド・サービス・モデルで重要な役割を果たす複数のプレイヤーを、IaaS クラウドの制御という点で互いに比較するとどのようであるかを理解する必要があります。このモデルの重要な参加者には、以下のプレイヤーが含まれます。

  • IaaS クラウド・サービスのユーザー
  • PaaS/IaaS クラウド・サービスの開発者
  • IaaS クラウド・サービスのプロバイダー
  • SDN 管理者

IIaaS クラウド・サービスのユーザー

IaaS クラウド・サービスのユーザーが IaaS クラウドを制御できる範囲を調べてみましょう。このグループには、IaaS ユーザーと SaaS ユーザーが含まれます。

IaaS ユーザー (通常は、ネットワーク・スペシャリスト/インフラストラクチャー・スペシャリスト):

  • オペレーティング・システム、ネットワーク機器、デプロイ済みアプリケーションを仮想マシン・レベルで制御します。
  • インフラストラクチャー・スペシャリストは、ストレージ域のブロックや、仮想サービスをスケール・アップまたはスケール・ダウンすることができます。
  • インフラストラクチャー・スペシャリストが SDN 管理者も兼ねていて、機器間のトラフィック・フローを最適化するためにコントローラーを使用する場合もあります。

一方、SaaS ユーザーが制御できるのは (ユーザーが個人、企業、または政府機関であるかに関わらず)、SaaS アプリケーションへのアクセスだけに限られ、SDN 管理者よるトラフィック・フローの制御は、SaaS ユーザーには見えません。SaaS ユーザーが、SaaS プロバイダーであることもあります。SaaS プロバイダーは、アクセス制御、システム応答時間 (スループット)、問い合わせの応答に対するユーザーの期待値を満たすように配慮します。

PaaS/IaaS クラウド・サービスの開発者

PaaS/IaaS クラウド・サービスの開発者には、どの程度の制御が許されているのでしょう?

PaaS 開発者は、ビジネス・ライフサイクル全体におけるすべてのアプリケーションを制御し、保護します。開発者がビルド、デプロイ、実行するアプリケーションには、例えばカスタムのウェアハウス管理アプリケーションなどがあります。開発者はまた、ビジネス・ライフサイクルの一貫として、スプレッドシート、ワード・プロセッサー、課金、給与処理、請求などのサービスを使用します。PaaS 開発者は、SDN 管理者が制御するネットワーク内で、アプリケーションが正常に機能することを確実にする必要があります。

IaaS 開発者は、IaaS のパブリック・クラウドまたはプライベート・クラウドのライフサイクル開発を制御します。これらのクラウドは、別のサービス・プロバイダーがホストする別の IaaS クラウドと相互運用することがあります。その場合、IaaS 開発者は、その IaaS が OpenStack ベースであることを確認します。IaaS 開発者は PaaS 開発者と協力して、テスト環境の IaaS または PaaS 上で SaaS アプリケーションを実行します。

IaaS クラウド・サービスのプロバイダー

IaaS プロバイダーは、少なくとも、仮想マシンのベースにある従来のコンピューティング・リソースのインフラストラクチャーを制御します。プロバイダーは、ユーザー・リクエスト、リソース・リクエスト、およびデータ・リクエストのしきい値レベルを設定します。しきい値レベルの変更については、PaaS 開発者との交渉を許可する場合もあります。また、プロバイダーが、ネットワーク機器間のトラフィックを制御する SDN 管理者を兼ねることもあります。

SDN 管理者

IaaS クラウドでは、管理者が、D-Plane から切り離された SDN 機能、そして専用のハードウェア・アプライアンスから分離された NFV 機能を制御します。オープンソースの IaaS の最適化に取り組むために、管理者は IaaS クラウド・サービス・モデルのプレイヤーと協力する必要があります。

期待値を満たす方法: OpenStack Foundation

将来および現在のクラウド・サービスの顧客は、別のプロバイダーがホストする別の IaaS との相互運用を可能にする、クラウド・サービスのオープン・スタンダードを求めています。その期待値を満たすために、OpenStack は先を見越した措置を講じました。その結果、OpenStack Foundation プロジェクトでは、開発者とクラウド・コンピューティング技術者が、IaaS パブリック/プライベート・クラウド用のオープンソース・クラウド・コンピューティング・プラットフォームの作成に協力して取り組めるようになっています。

それでは OpenStack Foundation の概要と、この団体がこれまで IaaS を標準化するために OpenStack で行ってきた取り組みについて、少し詳しく見ていきましょう。その後で、モジュール式のアーキテクチャー・コンポーネント、共有サービス、そして Neuron および SDN について取り上げます。

Foundation の取り組み

OpenStack は、コンピュート、ストレージ、およびネットワーキングのリソースの大規模なプールと、データ・センター全体で共有されるサービスを制御する IaaS クラウド・オペレーティング・システムです。管理者はこのすべてを管理するためにダッシュボードを使用する一方、ユーザーと開発者は Web インターフェースを通じてリソースをプロビジョニングします。

OpenStack Foundation が監督する OpenStack プロジェクトは、NASA の Nebula プラットフォームのコードを Rackspace のプラットフォームに統合したものです。このプロジェクトのコード変更は、2011年に Rackspace から独立した OpenStack Foundation のメンバーが提供しています。パブリック/プライベート・クラウドを対象としたオープンソース・クラウド・コンピューティング・プラットフォームを作成するために、開発者とクラウド・コンピューティング技術者の世界的なコラボレーションが行われています。

2012年 4月に IBM と Red Hat はプラチナ・メンバーとして OpenStack Foundation への参加に同意しました。つまり、以降の 3 年間は、年に 500,000 米ドル (1 ドル 100 円換算で約 5,000 万円) の資金援助を行うことになります。他にも AT&T、Canonical、HP、Nebula、Rackspace、SUSE などの企業が、プラチナ・メンバーとして参加する予定です。

モジュール式アーキテクチャーのコンポーネント

OpenStack のモジュール式アーキテクチャーには、IaaS の標準化に向けた取り組みの一貫としてのコンポーネントが 3 つ含まれています。それぞれのコンポーネントには、コード・ネームが付けられています。

  • Compute (Nova): 自動的にプロビジョニングされる仮想コンピュート・インスタンスの大規模なデプロイメントに対応するオープンソース・ソフトウェアと標準を提供します。
  • Object Storage (Swift): 静的オブジェクトの大規模な冗長ストレージに対応するオープンソース・ソフトウェアと標準を提供します。
  • Networking (Neuron): 他の OpenStack サービス (Nova など) で管理されるネットワーク・インターフェース・デバイス (vNIC) 間の「サービスとしてのネットワーキング (Networking as a Service)」を提供します。

共有サービス

OpenStack が提供している共有サービスは、コンピュート、ストレージ、ネットワーキングの 3 つの中心コンポーネントで共有されています。これらのサービスには、以下のものが含まれます。

  • Identity: すべての OpenStack プロジェクトにわたって統一された認証を提供します。
  • Image: 仮想ディスク・イメージのデリバリー・サービスを提供します。
  • Telemetry: OpenStack クラウドにデプロイされたサービス全体の使用状況およびパフォーマンスに関するデータを集約して提供します。
  • Orchestration: アプリケーション開発者がインフラストラクチャーのデプロイメントを記述して自動化できるように、テンプレート駆動型エンジンを提供します。
  • Dashboard: Nova および Swift を含む OpenStack サービスに対する Web ベースのユーザー・インターフェースを提供します。

これらの共有サービスはいずれも、OpenStack コンポーネントを互いに統合します。

Neuron と SDN

SDN を使用した IaaS の最適化には、Neuron (ネットワーキング・サービスのコード・ネーム) を利用することもできます。ネットワーク管理者は、上位レベルでのマルチテナンシーと、ネットワーク機器間を移動する大規模なデータに対応するために、OpenFlow のような SDN テクノロジーを利用することができます (OpenFlow は、オープンソース標準の通信プロトコルです。この通信プロトコルは、ネットワーク・スイッチまたはネットワーク・ルーターの転送プレーンへのネットワーク経由のアクセスを提供し、リモート・コントローラーが複数のスイッチで構成されるネットワークを介したネットワーク・パケットのパスを判断できるようにします)。

ユーザーは SDN テクノロジーを利用して、独自のネットワークを作成し、トラフィックを制御して 1 つ以上のネットワークにサーバーと機器を接続することができます。

Neuron には、侵入検知システム (IDS)、ロード・バランシング、ファイアウォール、仮想プライベート・ネットワーク (VPN) などのネットワーク・サービスを、追加でデプロイして管理できるようにするための拡張フレームワークが用意されています。

期待値を満たす方法: OpenDayLight

OpenFlow 標準を使用した Neuron と SDN テクノロジーの組み合わせは、十分とは言えません。それよりも IaaS を最適化するのに適しているのは、OpenDayLight という Linux Foundation プロジェクトす。OpenDayLight は、SDN/NFV コントローラーを利用したオープンソースのフレームワークであり、管理者が OpenStack Neuron でこのフレームワークを使用することで、ユーザーは先を見越した IaaS 最適化の措置を講じられるようになります。

それでは OpenDayLight の概要と、これまで OpenDayLight が IaaS を標準化するために行ってきた取り組みについて詳しく見ていきましょう。

SDN/NFV コントローラーは、専用の JVM (Java Virtual Machine) 内に収容されます。これは、OpenDayLight は Linux だけを対象としているのではないことを意味します。OpenDayLight は、Java コードをサポートするあらゆるハードウェアとオペレーティング・システムで使用できるように設計されているオープン・プラットフォームです。

OpenDayLight は、Cisco、Dell、Juniper、IBM、Intel をはじめとする 18 の企業によって発足されました。このプロジェクトのメンバーは、今では 36 社を数えます。OpenDayLight の最初のリリースとなった Hydrogen には、150 名を超える開発者が積極的に貢献しました。

Hydrogen

Hydrogen は、企業、サービス・プロバイダー、機器プロバイダー、学究機関が利用できるようになっていて 1 つのパッケージに 3 種類のエディションが用意されています。

  • Base Edition: ノート PC 上で動作し、実際のネットワークを模倣したネットワークを提供するテスト・ツールに接続します。
  • Virtualization Edition: データ・センター仮想化テクノロジーが追加されています。ベースとなっているのは、Base Edition です。
  • Service Provider Edition: サービス・プロバイダーと通信事業者が SDN および NFV への移行計画を立てるのを支援するとともに、トラフィック・エンジニアリングをサポートします。このエディションは、SNMP プロトコルをサポートしており、レガシー・ネットワーク機器を管理するための API も提供しています。

ネットワーク機能の仮想化

前に説明したように、NFV はネットワーク機能を専用のハードウェア・アプライアンスから分離して、ネットワーク機能をソフトウェアで実行できるようにします。NFV は、仮想サーバー、仮想ストレージ、さらには他のネットワークも含め、完全に仮想化されたネットワーク・インフラストラクチャーをサポートする上で必要なネットワーキング・コンポーネントを統合するように設計されています。NFV が利用する標準的な IT 仮想化テクノロジーは、サービスおよびストレージ用の大容量ハードウェアの上で実行されてネットワーク機能を仮想化します。

ここで NFV が SDN と連動する仕組みを見てみましょう。OpenDayLight の概要レベルで見ると、SDN は 3 つの層で表されます。

  • ネットワーク・アプリケーションおよびオーケストレーション: 最上位の層は、ネットワークの動作を制御して監視する、ビジネスおよびネットワーク・ロジックのアプリケーションで構成されます。これらのアプリケーションには、ネットワーク・トラフィックを全体的に制御する上で必要なオーケストレーション・アプリケーションも含まれます。
  • コントローラー・プラットフォーム: 中間層は、SDN のノースバウンド・インターフェースとサウスバウンド・インターフェースの間に位置します。ノースバウンド・インターフェースは、アプリケーション層に対する共有 API 一式を提供します。ノースバウンド・インターフェースが接続するサウスバウンド・インターフェースは、ネットワーク内の物理ハードウェアを制御するための 1 つ以上のプロトコル (OpenFlow など) を実装します。
  • 物理的および仮想的なネットワーク機器: 最下層は、物理的および仮想的な機器、スイッチ、ルーターなどからなり、これらがネットワーク内のすべてのエンドポイント間の接続を提供します。

コンロトーラーに伴うリスクの軽減

SDN には、ハッカーが悪用する可能性のある脆弱性 (SDN コントローラーのハッキングなど) が伴います。コントローラーのリスクを軽減するには、以下の 4 つのステップに従う必要があります。

  • アセットを識別する
  • 脆弱性と脅威を識別する
  • リスクを評価する
  • 予防対策を講じて修正する

Iアセットを識別する

リスクを軽減するプロセスは、そのコントローラーに関連するアセットを識別するところから始めます。アセットが属するカテゴリーを判断してください。以下に、いくつかのカテゴリーの例を挙げます。

  • ハードウェア: ネットワーク機器、スイッチ、SDN 管理者のコンソール
  • セキュリティー: 暗号化メカニズム、セキュリティー・テスト・ツール、ファイアウォール
  • 管理: OpenStack や OpenDayLight のガイドライン
  • 資料: SDN 管理者の連絡先、トレーニング・マニュアル、ネットワーク標準、災害復旧計画、サービス・レベル・アグリーメント

脆弱性と脅威を識別する

コントローラーの脆弱性を悪用する可能性のある脅威の主体は、ハッカーだけではありません。脅威の主体となりうるものには、コントローラー (およびファイアウォール) を不適切に構成することができる SDN 管理者も含まれます。

コントローラーやファイアウォールの不適切な構成は、IaaS のサービス停止やセキュリティー攻撃という結果を招く恐れがあります。あるリージョンから別のリージョンへの IaaS フェイルオーバー・メカニズムのポリシーが確立されていなければ、ユーザーは別の IaaS ホスト・プロバイダーに移ってしまうでしょう。

リスクを評価する

ユーザーは、IaaS が常に相互運用可能で利用できるという保証、そして IaaS を最適化することでトラフィックの需要の増加に対処できるという保証を求めるものです。IaaS が利用不可になるリスクを評価する 1 つの方法は、定量化です。その例としては、以下のものが挙げられます。

  • IaaS が利用不可になる推定頻度
  • 不適切なコントローラーの構成が原因でネットワーク攻撃が発生する推定頻度
  • サービス・レベル・アグリーメントに記述されたパフォーマンスの保証が満たされない推定頻度
  • ネットワーク・ルーターおよびスイッチのフェイルオーバーが失敗する推定頻度

予防対策を講じて修正する

コスト効果の高い予防対策は、コントローラーのリスクを軽減する方法の 1 つです。SDN 管理者は、以下のことを確実にする必要があります。

  • コントローラーが適切に構成されてセキュアであること。それには少なくとも、コントローラーにアクセスしたユーザーの監査、トラフィックの暗号化、ロギング・オプションの有効化が必要です。
  • ネットワーク攻撃をブロックするためのネットワーク・サービスが用意されていること。これらのサービスには、侵入検知システム (IDS)、ロード・バランサー、ファイアウォールが含まれます。
  • 正常でないネットワーク・ルーターやスイッチを正常なものに素早くフェイルオーバーするフェイルオーバー・メカニズムが用意されていること。
  • SDN/NFV 管理者が適切なスキルを持ち、システムを管理するための指導を受けていること。

まとめ

SDN を使用した IaaS の最適化を計画する際には、IaaS の相互運用性の問題を解決して IaaS クラウド・サービス・モデルをセットアップする上でのベスト・プラクティスを検討する必要があります。IaaS の最適化計画には、OpenDayLight とともに OpenStack ベースの IaaS を使用して IaaS を最適化できるようにする方法について先を見越した措置を講じることも含まれます。コントローラーに伴うリスクを軽減するための計画も必ず用意してください。IaaS クラウド・サービスのプレイヤー、管理者、ビジネス・アナリスト、システム・エンジニアからなるチームを編成して、SDN を使用して IaaS を最適化するという作業を行いやすい環境を作る必要があります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Open source, セキュリティ, Java technology, Linux, DevOps
ArticleID=982647
ArticleTitle=Software Defined Networking を使用して IaaS を最適化する
publish-date=09182014