キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
1625
閲覧回数
0
いいね!
0
コメント
DCNhowtoAdmin
Level 2
Level 2

この文章の使い方

 

この文書では、ACIについてすでにご存じの方もまだあまり深く馴染みがない方も含め、改めてACIの概要を数年前からの技術トレンドを振り返りながら説明していきます。ACIが開発されるまでのコンテキストを念頭のおいた上で、ACIがどのような課題を解決するために開発されたのかを理解することは、ACIの導入検討や設計の方向性を決定するための助けになるでしょう。

 

また、このACI How ToはACIを実際に「動かす」ことを目的にしているラーニングポータルですが、様々なACIの機能や設定について学んでいくうちに、そもそも何故ACIを使おうとしているのか・使っているのかについてわからなくなることもあるかと思います。そうした際には、一度ACIを一歩引いた立場から見直すことも重要です。その際にこの文書が役に立つのではないかと思います。

 

しかし、このポータルを使う上で、この文章は必読ではありません。必要に応じて斜め読みなり、無視するなり、暇つぶしにじっくり読んで見るなり自由に使っていただければ、幸いです。

 

 

データセンターネットワークにおける新たなトレンド

それではまず、簡単に昨今の歴史を振り返りましょう。データセンターに関わるインフラエンジニアであれば、2000年台中盤からデータセンタにおいてサーバの仮想化がホットトピックになったことは記憶に新しいと思います。アプリケーション集約率の効率化、ハードウェアコストの削減という観点において大きな実績を上げ、現在でもサーバの仮想化は随時進められています。しかしながら、サーバの仮想化が進むにつれ、今までのオペレーションモデルが立ちゆかなくなり、それはオペレーションコストの増大という形でエンタープライズITやデータセンター事業者にとって大きな負担としてのしかかってきています。そのオペレーション上の問題の1つとして、データセンターネットワーク管理も大きな課題に直面しています。従来型のSTPベースのネットワークでは拡張性、信頼性などに問題があり、10年前とは比べ物にならないほどに増えたアプリケーションを支えきれなくなってきています。また、サーバが仮想化され、VMのモビリティの機能の活用が一般化されてくると、従来型のネットワークではサイロ化による不自由な運用、リソースの非効率性といった課題も浮き彫りになってきました。

 

サーバの仮想化に伴い顕在化したデータセンターネットワークの課題をいくつか上げてみましょう。

  • STPベースのネットワークの不安定性、帯域の利用効率や拡張性の欠如、サイロ化
  • 頻繁なアプリケーションの追加、削除に伴うネットワークの複雑な設定追加変更、新たなアプリケーション、サービス展開の遅延
  • 大量のVMをサポートするための拡張性、集約力の欠如、それに伴うコストの増大
  • 増大する物理ネットワーク機器の運用管理

 

こうした問題を解決するため、ネットワーク業界では2つの大きな技術的なトレンドが2010年頃に生まれます。

 

イーサネット・ファブリック

 

まずはイーサネット・ファブリック技術。シスコではこれを Cisco FabricPath として提供し、すでに多くのデータセンターネットワークで稼働、現在も新たなデータセンターに導入され続けているソリューションです。ファブリック技術はIS-ISベースのコントロールプレーンをL2ネットワークに適用し、迅速な収束、ECMPによる帯域の有効活用をデータセンターL2ネットワークにもたらしました。これにより、従来のSTPベースのL2ネットワークに比べ、パフォーマンス・スケーラビリティともに大幅に向上させることに成功しました。

 

しかしながら、うしたファブリック技術でも解決できない問題が幾つかあります。まず、L2/L3ネットワーク境界におけるL3ゲートウェイの拡張性の問題です。HSRPやVRRPによって提供されるこの機能は基本的にペアのコアスイッチによって提供されますが、非常に多くのL3ゲートウェイを提供する場合にはコアスイッチのCPUのパフォーマンスの制限により、思うようにスケールしません。これは従来のL3ゲートウェイがスケールアップ型であり、筐体に縛られるためです。もう1つは4000 VLANの制限です。ファブリック技術によってトポロジカルな制限はかなり改善されましたが、802.1Qベースのカプセル化を使っている限り、マルチテナント環境では必要十分な数のL2ネットワークが確保できず、テナントの集約率をサービスコストに見合う形まで上げることができないなどの問題がありました。この問題は最近リリースされている最新のハードウェアではSegment IDやVXLANといった新たなカプセル化方式がサポートされているため、改善されつつありますが、ファブリック技術が普及し始めた2011-2012ではファブリック技術の大きな弱点の1つでした。

 

SDN:OpenFlowとエッジオーバレイ

もう一方のトレンドとしては、SDNにカテゴライズされるテクノロジーです。ひとつはOpenFlow, もう一つはエッジオーバレイ・ソフトウェアオーバレイです。

 

まずはOpenFlowについて振り返りたいと思います。OpenFlowはOpenFlowコントローラからOpenFlow対応のコントロールプレーンのないスイッチを集中管理することにより、管理の集中化と、廉価なホワイトボックススイッチの活用によって運用コストと設備の導入コストを減らすことのできる画期的なテクノロジーとして注目されました。しかしながら、OpenFlowが管理できるのはあくまで各ノード間の通信フローだけであり、ファームウェアの管理などデータセンターネットワーク周りのすべてが管理できるわけではありません。また、OpenFlowコントローラを実際に利用しようとすると、OpenFlowコントローラ上でOpenFlowスイッチを適切に構成、管理するためのアプリケーションを開発・メンテナンスする必要があり、一般の企業ユーザが使いこなすことは簡単ではありません。結果、ネットワークソリューションベンダーが開発・提供する製品を購入するという形となります。こうなってしまうと、実際のところはOpenFlowで管理がシンプルになるかという点についても、ベンダーのコントローラーソフトウェアの実装次第、また導入コストについてもベンダーの提供するソリューションのライセンスなどの価格次第ということになってしまい、市場がOpenFlowに寄せていた期待には答えられないという状況に現在は陥っています。さらに、OpenFlowはコントロールプレーンをコントローラに集めている性質上、コントローラ自体がパフォーマンスのボトルネックになることと、コントローラの障害時には非常に大きな影響があるという問題があります。OpenFlow自体はネットワークプログラミングのツールとして優れているところもあり、CiscoもOpenFlowの特性を活かしたソリューションを提供していますが、今日のデータセンターネットワークに求められる要件を満たすのにOpenFlow単体で適切なソリューションの開発は非現実的と言えるでしょう。

 

もう一方のSDNの主力技術であるエッジオーバレイの代表例はCisco/VMwareによって提唱、ソリューションが提供され始めたVXLANです。VXLANの特徴として、イーサネットフレームをUDPでカプセル化することにより、ハイパーバイザ上で動作する仮想スイッチ間で仮想的なL2ネットワークを物理ネットワークの制限に縛られずに構成できることが上げられます。また、もうひとつの特徴は802.1QのVLANが12bit, 4096のL2ネットワークアドレスフィールドであるのに対し、24bitのVNI(Virtual Network Identifier)をもつ VXLANは、論理的には1600万もの仮想L2ネットワークを構築するできます。

 

この2つの特徴により、大量のテナントを物理ネットワークの制限に左右されずに、自由にL2ネットワークを構成できるという強みを持ちます。また、エッジオーバレイ技術は多くの場合VMwareやMicrosoft社などサーバ仮想化のソリューションを提供しているベンダから提供されている場合も多く、その場合サーバ仮想化ソリューションと統合されている場合もあり、完全に仮想化されている世界での運用性、機能性では多くのアドバンテージもあります。また、物理ネットワークがすでに存在し、その上に新たに機能を導入する場合にも既存ネットワークに変更を加えることなく新たな機能を導入できるというメリットもあります。さらにソフトウェアベースのコントローラ、アーキテクチャのため柔軟性が非常に高く、仮想ルータ、仮想ファイヤウォール、仮想ロードバランサなどをサービスチェーンのフレームワークと合わせて活用することも可能で、またスケールアウトのアーキテクチャを取りやすいというメリットもあります。こうして見ると、昨今のデータセンターが直面している様々な課題の大部分が解決されるように一見見えますが、やはり実環境での利用に耐えうるためには大きな課題があります。

 

まず、VXLANを動作させるためには物理ネットワーク側でマルチキャストを動作させる必要がある場合があります。マルチキャストは非常に優れたテクノロジーですが、ネットワークエンジニアでもマルチキャスの十分な経験・知識を持っているエンジニアはそれほど多くないため、マルチキャスト依存のコントロールプレーンを必要とするVXLANの使用に大きな抵抗がある担当者は多いです。VXLANにはマルチキャストを必要としないコントローラベースの動作方式もあり、こちらの場合はVXLANを導入するという点でかなり敷居は下がります。しかしながら、コントローラベースのVXLANにも課題があります。まず、単一のコントローラでVXLANや、仮想ネットワークに存在するVMなど様々なリソースを管理する必要があり、このことがスケーラビリティ不足の要因となります。論理的に1600万のL2ネットワークをサポートできるVXLANですが、コントローラの制限により実際に1つのドメインでサポート可能なVMは実際数千から多くても数万というオーダとなり、このスケールはVLANベースのファブリック技術と比較しても見劣りするレベルに留まります。

 

もう1つの問題としては、仮想ネットワークを構築しても実際の通信のためには物理ネットワークが必要となり、異なる2つのネットワークを管理する必要があるということです。また、仮想ネットワークで問題が発生した場合、その問題が仮想ネットワークのソフトウェアの問題なのか、物理ネットワークの問題なのかを様々な観点からトラブルシューティングする必要があり、複雑になるという問題も考えられます。また、データセンターが100%仮想化されているケースは非常に少なく、データベース等のベアメタルアプリケーションと通信するためにはVLAN/VXLANゲートウェイを用意し、細かな設定を必要とします。これらのゲートウェイの設定管理、パフォーマンス管理はネットワークエンジニアに大きな運用負荷を要求します。さらに、サーバ仮想化製品と高い親和性を発揮しますが、単一のベンダから単一のハイパーバイザとインテグレーションされた形で提供される形が主流であり、マルチハイパーバイザ環境ではそれぞれのハイパーバイザ向けに仮想ネットワークを構築する必要がある場合が大半で、ネットワークのサイロ化に起因する問題も出てきます。マルチハイパーバイザ対応のオーバレイソリューションも存在しますが、その成熟度、導入の進み具合はまだこれからでしょう。

 

 
イーサネット・ファブリックとSDNについて簡単に振り返ってみましたが、それぞれの強み・弱みをまとめると以下のようになります。
 
 
テクノロジー 強み 弱み
イーサネット・ファブリック
  • ハードウェア・パフォーマンス
  • 高速なコンバージェンス
  • 従来型ネットワークのオペレーション知識・経験が活かしやすい
  • 4000 VLANの壁
  • サービスチェーンのためのフレームワークがない
OpenFlow
  • エンドツーエンドのフロー設定管理
  • マルチベンダ(OpenFlow対応のスイッチから様々なベンダが選べる)
  • 大規模なコントローラ・アプリケーションの開発が必要
  • コントローラがボトルネック
  • コントローラ障害の影響が大きい
エッジ・オーバレイ
  • 既存ネットワークに制限されずに新たな機能を導入可能
  • 迅速なプロビジョニング、コントローラから自由に仮想ネットワークを構築、変更、削除ができる
  • サービスチェーンの実装が容易
  • サーバ仮想化プラットフォームとの親和性が高い
  • ソフトウェアパフォーマンス(遅延などの問題)
  • スケール
  • トラブルシューティングの困難性
  • マルチハイパーバイザ環境

 

こうしてみると、それぞれのソリューションにはそれぞれの強みがありますが、どのソリューションもモダンなデータセンターに必要とされる要件を十分に満たすことができません。また、物理ネットワーク、ノード管理の観点ではどのソリューションも基本的には従来のモデルと何ら変わらず、機器の交換、ファームウェアのアップグレードなどの作業は基本的にマニュアル作業になります。

 

さらに、現在のネットワークの管理モデルには非常に大きな課題があります。これはSTPベースのネットワークからエッジオーバレイも含めて共通の課題です。現行のネットワークでは、アプリケーションに必要な各ノード間の接続性を提供するために、多岐にわたる設定が必要となります。IPアドレス、VLAN、アクセスリスト、プロトコル様々な機能・パラメータが存在しますが、現在のデータセンターは頻繁にアプリケーションの追加、変更、削除が発生し、それに対応するためネットワークエンジニアは既存のアプリケーションに影響を与えないよう、注意深く時間をかけて作業を行います。しかし、例えば数百数千というアクセスリストの整合性を保ちつつ作業を進めるのは極めて困難です。実際の現場では、設定ミスによる通信断や気が付かないうちに不要な穴をネットワークに開けてしまうなどの問題が日々発生しています。

 

この問題が指し示すことは、ネットワーク自体のコントロールの方法が極めて複雑であり、その管理モデル自体が、現在の動的なアプリケーションの追加、削除そしてスケールに全く追い付いていないことを示します。これは例えて言うならば、もともと小さな会社で、社長が数人の部下に対して細々と支持を送り日々の業務を行っていたが、やがて会社が大きくなり、部門も増え業務が複雑化してきているのにもかかわらず、社長もしくは数少ないマネージャ陣が多数の従業員に対してマイクロマネージメントを続け、実際にはうまく業務が回せていない状況に似ています。組織では、そのサイズ・特性に応じてマネージメントモデルを変える必要があり、当たり前ですが、適切な階層と権限の委譲をし、上層部はシンプル化された会社の方針、各業務のゴールを設定、メトリックに基づいた達成度による管理を行う必要があります。現在のネットワークでも同じことが言えます。現行のネットワークは細々としたパラメータを逐一マイクロマネージメントする必要があり、これは従来のネットワークも、OpenFlowによるフロー毎の管理も、仮想化されたとはいえパラメータやコンセプト自体はそのままであるエッジオーバレイも同じで、この問題に対する解決策は提供していません。SDNに期待される要件として大きなものの1つとしてネットワークの自動化が挙げられますが、設定の変更・管理のプロセス自体が複雑な状況では、それもままなりません。ネットワークはよりシンプルかつユーザフレンドリーになる必要があります。

 

現在のデータセンターが抱える課題は大きく2つに分けることができます。前段で提出したネットワークの機能・性能(スケール、柔軟性、サービスチェーン等)の不足・欠落の問題がひとつ。もう一つは、複雑かつめまぐるしく変わるネットワークに全くついていけなくなった従来型のネットワークの管理モデルです。この2つの課題を解決することができればデータセンターに求められる機能要件である、自動化・高密度化・柔軟性が提供でき、その上で提供されるサービス・ビジネスに大きな利益をもたらすことが可能になります。

 

Cisco ACI

 

Cisco ACIはこのことを受けて開発されたソリューションです。大きなコンポーネントは2つ、柔軟性・拡張性・パフォーマンスに優れた新設計のASICを搭載したNexus 9000によって構成されるACIファブリックと、従来の管理モデルではない、高度に抽象化され、アプリケーションの通信要件をそのままネットワークインフラに投影可能なポリシーベースの管理モデルです。

 

01.png

 

ACIのファブリック部分はNexus 9000という10/40Gベースの新しいハードウェアによって構成され、スパイン・リーフの2階層の構成をとります。ハードウェアベースのファブリックでありながら、VXLAN, NVGRE, VLANの3つのカプセル化に対応し、またこれらの異なるネットワークに存在するノード間のL2/L3通信を単一のファブリックでサポートします。L3のゲートウェイも自由にスケールアウトが可能なAnycast ゲートウェイを搭載し、ハードウェア処理によるハイパフォーマンスかつ低遅延という特徴を活かし、仮想ワークロードからベアメタルアプリケーションまでサポートします。ACIのファブリックはIS-IS/VXLANをベースに構成され、エッジオーバレイでしか提供できなかった、自由なノードのモビリティと大量のテナントを収容可能なネットワークセグメンテーションを提供します。また、IS-ISによるECMP、あるいは単一フローでもロードバランシング可能な新しい機能が提供され、いわゆるファブリックテクノロジーとしてもより進んだアーキテクチャと機能を提供します。

 

インフラ、設定の管理の観点からもAPIC(Application Policy Infrastructure Controller)による一元管理が可能で、各スイッチノードのディスカバリー、ファームウェア管理なども可能です。しかしAPICはファブリックコントローラでありながら、いわゆるコントロールプレーンには一切関与しないポリシーコントローラのため、万が一APICが障害に見舞われたとしても、ACIファブリックは自律的にオペレーションを継続し、トラフィックが止まることはありません。

 

もう一つの重要なコンポーネントはACIの管理手法の核心となるポリシーモデルです。

 

02.png

 

ACIはアプリケーション・ネットワーク・プロファイルというアプリケーションの通信要件をモデル化したものを、いわゆる設定方法として用います。アプリケーションを構成する、同じ通信特性を持つホストをグループ化し、それぞれのグループ間を必要な通信方法(プロトコル、L4-7サービス)でつないでいき、プロファイルを作成します。この作業はAPIC上で行われ、プロファイルの作成が完了するとAPICからACIファブリックの各ノードに対し、ポリシーが渡されます。ここで重要なのは、APICはACIファブリックのノードに対し詳細なコマンドや設定を渡しているのではなく、高度に抽象化されたポリシーのみを渡しているということです。ACIファブリックはそのポリシーを理解し、そこに記述されたネットワーク要件を実行するために必要な分析を行い、実際の接続・セキュリティ・サービスチェーンなどの設定を自律的に行い、ネットワークサービスを自律的に提供開始します。このモデルにより、ACIは優れた拡張性を提供します。APICは複雑なノード間の接続、セキュリティといった設定をACIファブリックノードにオフロードできるため、自身はポリシーの管理、ユーザインターフェース、ノースバウンドとのやりとりに貴重なリソースを割くことが可能です。ACIのファブリックも分散型アーキテクチャととっているため、万一1つのノードのリソースが不足してきた場合には、新たなノードを追加することにより、アーキテクチャを変えることなく簡単にスケールアウトできます。

 

このように、ACIのポリシーモデルと、ACIファブリックを組み合わせることにより、今までのネットワークに存在していた制限・問題が解決され、高度に洗練された自動化を提供します。ACIの構成要素、そしてそれぞれが提供する機能、解決可能な問題を把握した上で、ACIのそれぞれの設定や使い方の理解に取り組めば、より有機的かつ効率的にACIというソリューションを活用できると思います。

 

Good Luck!

 

Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします