It is the top of the page

Link for moving within the page
To text (c)

このウェブサイトではサイトの利便性の向上のためにクッキーを利用します。サイトの閲覧を続行されるには、クッキーの使用にご同意いただきますようお願いします。
お客様のブラウザの設定によりクッキーの機能を無効にすることもできます。詳細はこちら

The main part starts here.

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

NFV動向: NFVとOpenStack③

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

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

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

参考: 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

VNFD概念図

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

Openstack画面

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

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

まとめ

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

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

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

関連記事

執筆者プロフィール

井上 勝晴

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

  • MCPC1級

Webからのお問い合わせはこちらから

ナレッジセンターを検索する

カテゴリーで検索

タグで検索