ナレッジセンター
匠コラム

NFV動向： NFVとOpenStack③

匠コラム: ネットワーク; 仮想化

2017.04.26

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

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

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

連載インデックス
NFV動向： NFVとOpenStack① NFV動向： NFVとOpenStack② NFV動向： NFVとOpenStack③

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