NFV動向: NFVとOpenStack③

ビジネス推進本部応用技術部
コアネットワークチーム
井上 勝晴

 前回のコラムではOpenstack TackerをConfigurationする上で必要となるTOSCAの技術概要とその実装方法を紹介しました。TOSCAはXMLベースの共通構造言語です。本コラムでは、Openstack Tackerを実際に操作し、TOSCAベースのVNFディプロイの動作を確認しましたのでご紹介します。

 

i5

参考: https://wiki.openstack.org/wiki/Tacker

 

連載インデックス

Openstack Tacker

 Openstack Tackerでサービスのディプロイや管理を司るカタログについてご説明します。Tackerに内包されるカタログには前回のコラムでご説明したように「VNF」、「Network Service」、「VNF Forwarding Graph」の3種類があります。

 先ずはベースとなるVNFカタログに相当する「VNFD(VND Descriptor )」から見て行きたいと思います。

 

VNFD(VNF Descriptor)
 Tackerを用いたVNFのディプロイやその振舞いは、VNFD(VNF Descriptor)と呼ぶテンプレートで定義されます。このVNFDテンプレートはTOSCAをベースにしたYAML形式で記載されており、このVNFDがVNFのカタログに相当します。

実際にVNFDの構造を見て行きたいと思います。

tosca_definitions_version:
 テンプレートがベースとするTOSCAの定義Versionを記述します。
 現在は、tosca_simple_profile_for_nfv_1_0_0 となります。

tosca_default_namespace:
 スキーマやタイプ等を含むデフォルトのネームスペースを記述します。(オプション)

description:
 このテンプレートに対するディスクリプションを記載します。

metadata:
 template_name: このテンプレートに与えられる名前を記載します。

topology_template:
 Node template下にVNFのトポロジーを記載します。
 node_template:
    VNFのNode Typeを記載します。
    VDU:
     Virtual Deployment Unitのプロパティ(Properties)と
     能力(Capabilities)を記載します。

    CP:
     Connection Pointのプロパティ(Properties)と
     能力(Capabilities)を記載します。

    VL:
     Virtual Linkのプロパティ(Properties)と
     能力(Capabilities)を記載します。

上記がVNFDの基本構造となります。

 このようにVNFDは、「VDU(Virtual Deployment Unit)」、「CP(Connection Point)」、「VL(Virtual Link)」の3つのNode Typeを持ちます。これらはTOSCAで言うNodeを表し、それぞれの特徴を示す属性情報(Type、Capability、Prosperity、Attribute、Requirement等)を持ちます。これらコンポーネントはVNFD Template中のNode Template内で記載されます(Node TemplateはTopology Templateの子供に相当します)。

続いてVNFDの中で定義される各Node templateの説明に移ります。

 

VDU(Virtual Deployment Unit)
 VDUはVNFの基本となるコンポーネントであり、Network Functionを持つVMに相当します。このVDUは、typeやpropertiesと言った複数フィールドを保持する事が出来ます。typeは “tosca.nodes.nfv.VDU.Tacker” が固定値となります。

propertiesには、このVDUで使われるimage、VDUが生成されるアベイラビリティゾーン、マネージメントドライバ、物理的要件(CPUやメモリ等)を示すflavor、VDUに対する監視ポリシー、VDUに対するカスタムコマンド(user data)等が、このVDUの特徴を示すPropertyとして記載されます。

以下にVDUの例を示します。

topology_template:
 node_templates:
  VDU1:
   type: tosca.nodes.nfv.VDU.Tacker
   properties:
    image: cirros-0.3.4-x86_64-uec
    flavor: m1.tiny
    availability_zone: nova

上記の例では、VDU1がアベイラビリティゾーン”nova”、image名”cirros-0.3.4-x86_64-uec”、flavorが”m1.tiny”で生成されることを表しています。

また、VMのComputeリソース指定にflavorを使用しましたが、代わりにcapabilities内でvCPUやメモリを指定する事も可能です。
(後述の例参照)

 

CP(Connection Points)
 CP(Connection Point)はInternal virtual link、またはOutside virtual linkとの接続に使用します。ここで言うVirtual Linkとは、仮想NICやSR-IOVに相当します。

また、各CPはVDUにも接続(Binding)されます。その為、CPは常にVirtual LinkとVirtual Bindingを必要とします。
以下にCPの例を示します。

..
topology_template:
 node_templates:
  VDU1:
   ..
  CP1:
   type: tosca.nodes.nfv.CP.Tacker
   properties:
    mac_address: fa:40:08:a0:de:0a
    ip_address: 10.10.1.12
    type: vnic
    anti_spoofing_protection: false
    management: true
    order: 0
    security_groups:
     - secgroup1
     - secgroup2
   requirements:
     - virtualLink:
       node: VL1
     - virtualBinding:
       node: VDU1
  CP2:
   type: tosca.nodes.nfv.CP.Tacker
   properties:
    type: vnic
    anti_spoofing_protection: false
    management: true
    order: 1
   requirements:
    - virtualLink:
       node: VL2
    - virtualBinding:
       node: VDU1
  VL1:
  ..
  VL2:
  ..

上記より、CPはVDUと同様にtypeやproperties等のフィールドより構成される事が解るかと思います。

この例では、VDU1はCP1とCP2に其々接続(Binding)されており、CP1とCP2は其々のPropertyを持ちながらVL1、VL2に接続されています。

 

VL(Virtual Link)
VL(Virtual Link)はVDU間の接続性を提供します。
以下に “Acme” と言うベンダー機器が “net-01” にアタッチされる例を示します。

..
topology_template:
 node_templates:
  VDU1:
   ..
  CP1:
   ..
  VL1:
   type: tosca.nodes.nfv.VL
   properties:
    vendor: Acme
    network_name: net-01

それでは、以上を踏まえ、具体的なサービスを想定したVNFDを作成してみたいと思います。

 

Openstack Tacker – VNFDを用いたMulti VMのディプロイ

 以下の例では、vCPEサービスをイメージして2つのVM(1つはRouter、もう1つはFirewall)をディプロイしています。各々のVMは対応するCPで接続され、またCPは外部Nネットワークへの疎通を提供するVLに接続されます。
以下はVNFDサンプルです。

tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0

description: Demo with user-data

metadata:
 template_name: sample-vnfd-userdata

topology_template:
 node_templates:
  VDU1:
   type: tosca.nodes.nfv.VDU.Tacker
   properties:
    image: openwrt-3
    flavor: m1.tiny
    config: |
     param0: key1
     param1: key2
    mgmt_driver: openwrt
    user_data_format: RAW
    user_data: |
     #!/bin/sh
     route add -net 1.1.10.0/24 gw 3.3.3.254
     route add -net 2.2.20.0/24 gw 3.3.3.254
  VDU2:
   type: tosca.nodes.nfv.VDU.Tacker
   capabilities:
    nfv_compute:
     properties:
       num_cpus: 1
       mem_size: 512 MB
       disk_size: 1 GB
   properties:
    image: OpenWRT
    config: |
     param0: key1
     param1: key2
    mgmt_driver: openwrt
    user_data_format: RAW
    user_data: |
     #!/bin/sh
     iptables -F
     iptables -X
     iptables -P INPUT DROP
     iptables -P FORWARD DROP
     iptables -P OUTPUT ACCEPT
     iptables -A INPUT -i lo -j ACCEPT
     iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
  CP1:
   type: tosca.nodes.nfv.CP.Tacker
   properties:
    management: true
    order: 0
    anti_spoofing_protection: false
   requirements:
    - virtualLink:
      node: MGMT
    - virtualBinding:
      node: VDU1

  CP2:
   type: tosca.nodes.nfv.CP.Tacker
   properties:
    management: true
    order: 0
    anti_spoofing_protection: false
   requirements:
    - virtualLink:
      node: MGMT
    - virtualBinding:
      node: VDU2

  CP3:
   type: tosca.nodes.nfv.CP.Tacker
   properties:
    management: true
    order: 0
    anti_spoofing_protection: false
   requirements:
    - virtualLink:
      node: SERVICE
    - virtualBinding:
      node: VDU1

  CP4:
   type: tosca.nodes.nfv.CP.Tacker
   properties:
    management: true
    order: 0
    anti_spoofing_protection: false
   requirements:
    - virtualLink:
      node: SERVICE
    - virtualBinding:
      node: VDU2

  CP5:
   type: tosca.nodes.nfv.CP.Tacker
   properties:
    management: true
    order: 0
    anti_spoofing_protection: false
   requirements:
    - virtualLink:
      node: NET0
    - virtualBinding:
      node: VDU1

  CP6:
   type: tosca.nodes.nfv.CP.Tacker
   properties:
    management: true
    order: 0
    anti_spoofing_protection: false
   requirements:
    - virtualLink:
      node: NET1
    - virtualBinding:
      node: VDU1

  MGMT:
   type: tosca.nodes.nfv.VL
   properties:
    network_name: net_mgmt
    vendor: ACME

  SERVICE:
   type: tosca.nodes.nfv.VL
   properties:
    network_name: service_net
    vendor: ACME

  NET0:
   type: tosca.nodes.nfv.VL
   properties:
    network_name: net0
    vendor: ACME

  NET1:
   type: tosca.nodes.nfv.VL
   properties:
    network_name: net1
    vendor: ACME

i1

VNFD概念図

 

起動確認
上述のVNFDにてディプロイした、2つのVMより構成されるVNFサービスを確認したいと思います。
Openstack管理画面より、以下の通り、2つのVNFが意図したネットワークにアタッチされた状態でディプロイされている事が確認出来ました。

i2

Openstack画面

 

また、各々のVMにてUser dataで定義された内容にてVMが起動している事も確認する事が出来ました(各VMにログインして確認)。

i3

※RouterイメージのVM:Static Routeが反映されています。

 

i4

※FirewallイメージのVM:Firewall ruleが適用されています。

 

まとめ

 今回のコラムでは、実際にVNFDをコンフィグレーションして、Openstack Tackerの基本動作を確認しました。

Tackerでは、Service Chainingに代表されるNFVならではのNetwork Serviceをターゲットとした新たなカタログ、VNF Forwarding GraphやNetwork Service Descriptorも、Openstack Newtonより実装が進んでいます。

今後もこの分野を注視していきたいと思います。

 

関連記事

ネットワン NFV の全貌と市場への挑戦①
ネットワン NFV の全貌と市場への挑戦②

 

執筆者プロフィール

井上 勝晴
ネットワンシステムズ株式会社 ビジネス推進本部 応用技術部 コアネットワークチーム
所属
エンタープライズ・サービスプロバイダのネットワーク提案・導入を支援する業務に、10年以上にわたり従事
現在はSDN・クラウドのエンジニアになるべく格闘中
・MCPC1級

イベント/レポート

pagetop