- ライター：井上 勝晴
- 2002年にネットワンシステムズ入社後、応用技術部にてVoIP/Mobile/Telemetry等の通信キャリア様向けの技術を担当
2019年4月より、現職であるNet One Systems USA,Inc.に勤務
米国シリコンバレーに駐在し、Innovation調査と新興企業の発掘業務に従事
妻と娘（6歳）も一緒に渡米しており、家族でのベイエリア生活を奮闘しながらも楽しんでいる。家族で米国の国立公園に行くのが最大の楽しみ。
目次
前回のコラムではOpenStackに実装されているTackerについてご紹介しました。TackerはNFV MANOに含まれる「VNF Manager」と「NFV Orchestrator」の機能を提供しますが、これら2つの機能は「NFV Catalog」にてTOSCAと呼ばれる言語で定義されています。本コラムでは「NFV Catalog」のベースとなるTOSCAとその実装方法についてご紹介します。
| 連載インデックス |
|---|
Tacker Project Specifications
TackerはOpenstack Libertyより実装されていますが、リリースが進む毎に機能実装が行われています。よって目的に合ったリリースを選択する必要があります。また、利用する機能によっては別途プラグインやパッチを適用する必要もあるため、インストールには注意が必要です。
|
Openstackリリース |
Tacker Functions |
|---|---|
|
Octa |
✔ Network Service Descriptorのサポート ✔ Tacker APIフレームワーク ✔ TackerによるVNFコンポーネントサポート実装 ✔ senlin連携によるオートスケール管理 ✔ インラインVNFテンプレート |
|
Newton |
✔ アラームベースのモニタリング機能 ✔ ライフサイクル監査（Life-cycle audit）のサポート ✔ VNFのマニュアル・オートスケーリング ✔ TackerとNetwork-sfcの統合 ✔ Tacker VNF Forwarding Graphの実装 |
|
Mitaka |
✔ VNFテンプレートをベースにした自動Openstackリソースの作成 ✔ VNFの配置（Enhanced） ✔ マルチサイトVIMサポート ✔ TOSCAパーサとHeat Translatorの統合 |
|
Liberty |
✔ VNF Managerへのモニタリングフレームワーク ✔ Tacker API v1 |
TOSCA
上述の通りTackerが提供する機能はOpenstackリリース毎に異なりますが、「NFV Catalog」はTOSCA（Topology and Orchestration Specification for Cloud Applications）と呼ばれるXMLベースで共通な構造言語にて定義されます。
NFV Catalogはさらに「VNFD（VNF Description）」「NSD（Network Service Descriptor）」「VNFFG（VNF Forwarding Graph）」と言ったNFVサービスを規定する主要な3つのカタログを提供しており、これらはいずれもTOSCA形式で記述されています。その為、具体的なTacker設定に入る前に、先ずはTOSCAの概要を理解しておく必要があります。
①TOSCAが生まれた背景
現在のクラウドテクノロジー（OpenstackやNFVなど）には統一した管理手法が不足しており、異なるクラウドベンダー・プロバイダーを跨ぐマイグレーションには時間とコストが掛ってしまう事が課題の1つと言えます。その為、アプリやそれらのマネージメント手法を標準化し、異なるクラウドベンダー・プロバイダー間に対するアプリとその管理手法の可搬性が求められていました。
TOSCAはこの様な背景で策定されたXMLをベースとした構造言語になります。このTOSCAにて、アプリコンポーネントとその関係性をトポロジーを用いて定義する事によってサービスを抽象化し、昨今の複雑なクラウドアプリケーション（例えば、複数サーバから構成されるアプリケーション等）に対し、 「automation（自動化）」「portability（可搬性）」「interoperability and reusability（相互接続性と再利用性）」の3つを提供します。
TOSCAがもたらすこれら3つの性質を利用する事で、クラウドサービス提供者はクラウドベンダー・プロバイダーそれぞれが持つ運用制約（Cloud Platform）に縛られることなくクラウドサービスを利用者へ提供可能となります。
②TOSCA概要
それではTOSCAの構造について説明していきます。TOSCAはService Templateと呼ばれる構造体にて、サービスを規定します。TOSCAコンパチブルな環境においては、サービスを規定するService Templateが異なるCloud Platform間の橋渡しをする翻訳者の役割を担います。
このService Templateは、「Topology Template」と「Plan」より構成されます。
Topology Templateは複数のNode Templateとそれらの関係性を示すRelation Templateより構成され、各々のNode Template・Relation TemplateはNode Type・Relation TypeでPre-defineされた雛形を利用します。
この様にTypeを使用する事はTOSCAの目的の1つである再利用性にも寄与しています。こられの関係性を図1に示します。
③Topology Template
少し具体的なサービスをイメージして、Topology Templateを説明したいと思います。以下の図2は検索機能を持つWebサービスアプリをTopology Templateに沿って記述したものです。
ここには複数のNode Templateが存在しています。これらのNode Templateは各々のNode Typeに属しています。例えば、Ubuntu 12.04 LTSのNode TemplateはOperating SystemのNode Typeに属しており、またApache TomcatはWeb-serverのNode Typeに属している事を表しています。
またNode Template間の関係性を示すRelation Templateの例として、ここではUbuntuOnEC2を定義しています。このUbuntuOnEC2は”host one”のTypeに属しています。各Node/Relation Typeは変数や初期値に相当するプロパティを保持しており、それらはインスタンス起動時のコンフィグレーション等に利用されます。
④Plans
続けてService Templateのもう1つの構成要素であるPlanを説明します。
クラウドアプリ開発者は自身でスクリプトを作る事で、ディプロイや運用負荷を軽減する事も出来ますが、このようなアプローチは異なるCloud Platformを跨るサービスのマイグレーション時に問題となります。
TOSCAが規定するPlanは、サービスのディプロイや運用の簡素化・自動化を目的としたWorkflowと言い換える事が出来ます。TOSCAによるマネージメントプランの最大の利点は、クラウドサービスが簡単に異なるCloud Platform間をマイグレーション出来るよう、ポータブルな運用プラン（可搬性のある管理プラン）を生成する事です。
マネージメントプランには、アプリ内の様々なコンポーネントやリレーションに関連する管理オペレーションをStrategy（図1参照）として記述します。
図3では2ステップでアプリをディプロイするシンプルな管理プランを描いています。1）Ubuntuオペレーションシステム上でApache Tomcatをインストールし、2）そのTomcat server上にアプリをディプロイします。
TOSCAはこれらのプランを実行する為の新たな言語は提供いません。その代り、PMLやBPMN（TOSCA Management Planで推奨されるWorkflow言語）のような既存にあるWorkflow言語を利用する事が出来ます。
TOSCAの概要は以上となりますが、この様にTOSCAは複雑化するクラウドサービスのディプロイ・管理に長けており、Tackerが目指すVNF Management, NFV Orchestrationに親和性が高い事が解ります。
まとめ
今回のコラムでは、Openstack TackerをConfigurationする上で必要となるTOSCAの技術概要を紹介しました。次回のコラムでは、実際にTackerをコンフィグレーションして、その動作を確認したいと思います。
関連記事
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
