仮題

学習用

10.インフラストラクチャサービス

インフラストラクチャサービス

10-1★クラウドコンピューティング


 ・NIST national institute of standards technology
  がクラウドコンピューティングの特徴を定義。
  ⇒On-demand/アクセス幅広し/リソース共用/拡張早し/サービス計測可

 ・Saas Paas Iaasの違いとは要するに

 

 アプリ
 データ
 ランタイム
 ミドルウェア
 OS
 仮想化
 サーバ
 ストレージ
 NWデバイス

 

 の層があるとして、

 Gmail,Salesforceなど、全部プロバイダが管理するのがSaaS(ユーザは利用のみ)


 上からアプリ、データまでユーザが管理し、

    ランタイム以下をプロバイダが管理するのがPaaS


 上からアプリ~OSまでユーザが管理し、

    土台の仮想化~NWデバイスのみプロバイダが管理するのがIaaS

 

 

10-2 ★SDN

 

要するに:
 機器ごとにバラバラな設定を一元管理したり、

    機器や通信経路の設定を自動化したい!!
 ⇒SDNを考えよう。

 

 SDN:Software-Defined Networking
 ※ソフトウェアでNWを一元管理することを目的とした技術および設計思想。
 コントロールプレーンとデータプレーン(後述)を分離させる発想で生まれた
 プロトコル「OpenFlow」を発展させた考え方である。

 

・SDNを理解するためにはまず従来の設計思想を知っておこう。

<従来>
 ルータやスイッチの内部で、2つの別個の機能を動作させる。


 1.コントロールプレーン:

     ルーティングテーブルやMACアドレステーブルを管理する制御機能。

 

    2.データプレーン:

     コントロールプレーンが構築した転送テーブルから、
 パケットやフレームの転送処理を行う機能。


  ※コントロールプレーンはソフトウェアとして組み込まれ、

   データプレーンはハードウェア(チップ)

 

 

<SDN>

要するに:新たにアプリケーションプレーンを一元管理用に作り、
     そこから下層のコントローラーに指示を送る。
     コントローラーが物理デバイスを制御する。

 

抽象的な設計思想としては 3層あって、


 <アプリケーション層>

        (ネットワーク全体を管理。コントローラに指示)


 <コントロール層> 

     (SDN制御ソフトウェアとしてコントローラが

      アプリ層から指示を受けてインフラ層を制御。)


 <インフラストラクチャ層> (機器の集合体。)
  層と層をつなぐ仲立ち機能、仕様がAPI
  アプリ-コント間をノースバウンドAPI

      コント-インフラ間をサウスバウンドAPIと呼ぶ。

 

具体的な実装としては上記を反映して3層あって


 <アプリケーションプレーン>
 (NBI)
 <コントロールプレーン>
 (SBI)
 <データプレーン>
 となる。
     
※SBI
(ベンダフリー)

           Openflow(プロトコル) NETCONF(プロトコル)
(Cisco独自)  

   OpFlex(API)、onePK(API)、TelnetとかSSHとかSNMPもサウスバウンドのAPI
 
※NBIには標準インターフェースはなく、それぞれ特定分野のアプリでのみ動作。

 

★3層の中で最重要なのがコントロールプレーン。
次項でまとめるCisco APICもSDNコントローラにあたる。

 

 

★10-3 Cisco APIC-EM

 


Cisco APIC-EMとはそもそも、

            Cisco ACI(application Centric Infrastructure)という製品の機能である。

 

Cisco ACIはNWの設定や機能を抽象化してプロファイルを作成、それを
コントローラであるAPIC( Application polycy infrastructure controller)へ渡し、
NW機器へ適用して制御。同じポリシーを別の機器に横展開できるので
データセンタやクラウドアプリケーションので超有用。

 

APIC-EMは、APICのが大規模DCやクラウドアプリを対象とするのに対して
中でキャンパスとかブランチとかWANのエンタープライズネットワークを
対象にしたCiscoのSDNコントローラになる。


使用APIはプログラム可能でオープン。
サウスバウンドAPI:Openflow,onePK, SNMP, CLI(telnet/SSH)

 

 

APIC-EMの何がいいかって


・ネットワーク機器のデータベース(NIDB)を作ってくれる
・新しい機器を検出するとNIDBに対応する新しいエントリを作ったうえで
 勝手に設定してくれる
・ビジネスポリシーから設定のポリシーを作り、ユーザー、時間帯別で
 NW機器にポリシーを適用してくれる。
ACLを分析し設定ミスに気づかせてくれる
QoSも素早く実装可
Cisco IWAN (intelligent wan)の管理が容易。
  IWAN:WANを通じて使用するアプリケーションの

        優先順位をNW設定に反映させるなどパス選択の最適化、

        セキュリティ担保、可視化機能などを揃えた製品


・Path Trace Appで、特定パケットの流れを可視化
・Path Trace ACLで、どのACLでパケットが破棄されているかもわかる

 

 

★10-4 QoS


要するに:Quality of Service。

     トラフィックに優先順位を振って大事なデータは先に流すようにする。
音声とかビデオのリアルタイムトラフィックは遅延や損失があまり許されない。

 

例: 音声/ビデオ
delay: どっちも150ms以下
jitter.: どっちも30ms以下
loss..: 音声:1%以下 ビデオ:0.1~1%以
band.: 音声:30~128kbps ビデオ:384kbps~20Mbps
特にビデオは一度に集中的に流れるバーストトラフィックなので注意。

 

ーーーーーーー


QoSを理解する前に、Catalystスイッチの基本的なデータ処理方法を確認する、
ハードウェア的にパケットを処理できるL3スイッチを例にとる。

 

そもそもCatalystのL3SW等にはデータ転送用の集積回路
ASIC(Application Specific Intefrated Circuit)が積まれており、こいつがキーになる。


ASICは下記2種のメモリへデータを読みに行く。
CAM( Content Addressable Memory) : MACアドレステーブルの高速検索用メモリ
TCAM(Ternary Content ADdressable Memory):ルーティングテーブルやACLQoSの検索用メモリ
※ASIC、CAM/TCAMはデータプレーンにある。


こいつらにより、CEF(Cisco Express Forwarding)等のデータプレーンオンリーでの
パケット処理が可能になる。

 

データプレーンオンリーでの処理方式がCEFというやつ。

CEFは下記2つのテーブルを、

コントロールプレーンからデータプレーンにロードする、

 

-FIB(forwarding information base)

   ルーティングテーブルをデータプレーンにDLったもの

-Adjacency Table: ARPテーブルをデータプレーンにDLったもの

 

※ルーティングテーブルやARPテーブルはコントロールプレーンにあるからね。

 

⇒L3パケット転送に必要なテーブルが全部データプレーンにロードされているので
スイッチは高速にパケットを転送できるというわけ。

 

なお、コントロールプレーンとデータプレーンを併用する方式として
・プロセススイッチング:パケットごとにCPU処理するので遅い
・ファストスイッチング:パケットをフロー毎にまとめて、

    フローの最初のパケはソフトウェアで
 残りはデータプレーンのキャッシュで処理するので

 プロセススイッチングよりはちょっと早い。

 でも全部データプレーンで処理するCEFよりは遅い。

※なおなお,L2SWはCAMテーブルでMACアドレス解決、

 TCAMテーブルでACLQoSを検索できてやはり高速に転送処理できる。
ーーーーー

 

さて、QoSに戻ると…こいつはやはりデータプレーンで処理する代物である。
しかしルータやスイッチにQoSが実装されているとしても、

デフォルトでは
それを利用しないベストエフォート型のモデルがネットワークに適用される。
つまり優先制御処理は行わず、

到着準にパケットやフレームを処理するFIFO方式になる。

 

これを下記で言うIntServやDiffServというQoSモデルを適用する設定にすることで
初めて、優先制御処理が行える。

 

・IntServ:Integrated Servicesの略。
RSVP(resource ReserVation Protocol)を使って、
 フロー(フローとは、送信元/宛先のIPやポート番号が同じ一連のトラフィック)
 ごとに一定の帯域を予約する。※全部の危機でRSVPを実装する必要があるので
 大規模NWではそんなに使われない。

 

・DiffServ:Differentiated Servicesの略。
 フローという塊を相手にする不器用な処理ではなく
 各パケットのIPヘッダ内やdot.1Q(トランクのやつ)タグ内に設定した
 分類・優先情報をもとに各個撃破で優先処理を行う。QoSとしてはこれがメジャー。


●DiffServモデルに代表されるQoSのメカニズムをもう少し細かくみる。

 


1.分類:トラフィックを識別してクラスに分類し、扱い方を決定。
  送信元/宛のIPアドレスとか、ポートとか、入力I/Fとか、パケサイズとか、
  後述するDSCP/IPP/CoS値とか
  MPLSラベルとか

 

マーキング:分類されたパケットのグループ化:

  要は処理待ち行列(キュー)が複数ある。
  どのキューにぶち込んであげるかがマーキングによって決まる。
  

  ※L2:Ethernetフレームのマーキングは、

  . 1qのVLANIDタグの3ビットのフィールドを使う。
   これをCoS値(class of service)と呼んでる。

   なお無線LANの場合はTID値という別モンを使う。
  
  ※L3: IPv4パケットへのマーキングは

    Tos(Type of Service)という1バイトのフィールドを使う。
    IPv6パケットへのマーキングは

    Tosが改名されて「トラフィッククラス」を使う。

  

  ToSへの書き方は2種類あって、相互互換性がある。
  - DSCP (differentiated Services Code Point) :

   1バイトのフィールドのうち6ビットを使う。
   RFC2474で定義。
   2^6= 64通りの優先順位が表現でき、

   PHB(per hop behavior)という定義で動作を決定。


   PHB: デフォルト=ベストエフォート
      CS:Class Selector=前半3ビットのみ使用しIPPと同様の8段階分類とする
      AF:Assured Forwarding=前半3ビットの大きさで優先度、

        後半3ビットで廃棄優先度
      EF:Expediated Forwarding=緊急転送用クラス。

        最優先のパケットで廃棄なし。主に音声パケットで使う。

 

  -IPP PO precedence: ToSフィールドの上位3ビットで8段階の優先順位をつける。 

 

2.  polishing / shaping.

  輻輳回避術。トラフィックレートが

  閾値(CIR:commited information rate)認定情報速度
  を超えた時にパケットを廃棄するのがポリッシング。
  バッファに格納して下がった時点で出力キューに配置するのがシェーピング

 

3. 輻輳管理:キューイング

  polishing shapingにも関連する。
  出力I/Fのキューがパケットで満杯になった時の動作.
 ⇒トラフィックを分類して、対応するキューを作成してトラフィックを格納し
   各キューからどの順番でどの量だけパケットを送信するかを決める。
   
   例:-FIFO
     -PQ(Priority Queuing :優先度最高/高/低/最低)、
     -WFQ(weighted fair queuing:
        送信-宛先情報から自動的にキューを作成・トラフィックを分類)

     -CBWFQ(class based WFQ

        :管理者が手動で作ったクラスごとにトラフィックを分類)
        ※CQを含む。

       (=Custom queuing:管理差が作成したキューをラウンドロビンで処理)
 
     -LLQ:Low latency Queuing
       CBWFQにPQを追加した。どういうことか?
      →CBWFQには「絶対的に優先するキュー」というのがないので補った。
 

 

   
4. リンク効率化:ヘッダ圧縮とフラグメンテーション

 

  とくに後者はLFIが主要。Link Fragmentatio and Interleaving
  例えば音声パケットは往々にして60バイトほどで細切れだが、
  その処理の間に1500バイト近いデカいパケットの処理が挟まると
  次の音声パケットの送信が遅れてしまう。
  ⇒大きいデータグラムは細切れにして小さいデータを差し込めるようにする。

 

 

 

QoSは、どこからどこまで設定するかが意外と大事。

 だってQoS適用したNW機器は分類したりトラフィックを振り分けたりで

 負荷がかかるし、あと誰が管理してるのか分からない優先度情報を解釈しろと

 言われても困るよね。

 

 →信頼境界を設定しましょう。

  だいたいベストプラクティスは、
  アクセススイッチ(もしくはIP Phone)からコア機器までの間で、
  エッジから先には適用しないのがいいよ。

  ※デフォルトだと、全部untrust。

  Cos値だとかTIDだとかDSCPだとかすべて無視する。
  信頼境界を設定したところで、分類やマーキングがなされる。

 

 

あと知らん用語

 

-NBAR
network basd application recognition


スケジューリングまではしてくれないけど、トラフィックのレイヤ4から7までの
情報を識別し、分類したりアプリを監視してくれるツール。
音声や動画で利用され、動的に使用ポートが変わっちゃう

RTP(real-time transport protocol)みたいなアプリケーションを

分類するのに優れている。

でもスケジューリングはしてくれないので、それはCBWFQやLLQに任せる。

 

-WRED

 

 こいつを理解するのにいくつか前提を理解しよう。

 

 1. テールドロップ キューが満杯で到着したパケが廃棄されてしまう
 2. TCP通信の再送処理 パケットの損失が起こると再送処理が発生する
 3.  スロースタート パケットの損失(廃棄)の頻度が増すと

   転送レートを自動で落とす


要はテールドロップのせいで

沢山のTCPコネクションで一斉にTCP再送処理が起こったり
スロースタートでリンクの使用率が低下しちゃったりするのだ。  

 

 →なので、キューが満杯になる「前に」キューに溜まったパケットを

  ランダムに廃棄しようとなる。なった。

  CiscoだとREDというメカニズム(ツール)がそれにあたる。  
  
  

  ただし、完全にランダムだと都合が悪いということで
  DSCP値を基準に優先度から捨てるパケットを判断する機能を追加させた。
  

 これをWRED(weighted random early detection)という。

 ※あくまでTCPを利用したトラフィックのみに有効。UDPは関係ない。