OpenStack 環境における仮想マシンと仮想ネットワークの統合 … · Abstract Integrated management system of virtual machine and virtual network in OpenStack system

平成 26年度

学士学位論文

OpenStack環境における仮想マシン

と仮想ネットワークの統合管理方式

Integrated management system of virtual machine

and virtual network in OpenStack system

1150305 喜友名光一

指導教員横山和俊

2015年 2月 27日

高知工科大学情報学群

要旨

OpenStack環境における仮想マシン

と仮想ネットワークの統合管理方式

喜友名光一

サーバ仮想化や通信ネットワークの技術進歩に伴い，クラウドコンピューティングが普及

している．このクラウドコンピューティングにおいて，IaaS の需要が高まっており，IaaS

基盤を構築するソフトウェアに OpenStackがある．

OpenStack は，利用者自身が仮想マシンや仮想ネットワークを自由に迅速に利用できる

ことから，システム開発環境に利用される事例も現れている．一般的にシステム開発を行う

場合，サーバとネットワークを含むシステム構成全体をバックアップする必要がある．しか

し，OpenStack でシステムを開発する場合，システム構成全体のキャプチャとリストアを

行うことができない．現状の OpenStackでは，仮想マシンと仮想ネットワークをそれぞれ

個別にキャプチャ及びリストアする方法しかないため，システム構成のキャプチャとリスト

アに，多くの操作回数と操作時間が必要になる．

本論文では，問題点を解決する方法として，仮想マシンと仮想ネットワークを統合的に

キャプチャ及びリストアする統合管理方式を提案し実装内容について解説した．統合管理方

式では，システム構成のキャプチャとリストアを管理画面で行えるようにし，操作回数と操

作時間を削減する．また，提案方式の有効性を評価するために評価実験を実施し，評価実験

の結果より，統合管理方式を用いることで，従来の方法に比べて短時間かつ容易にシステム

構成をキャプチャ及びリストアできることを示した．

キーワード OpenStack, IaaS, SDN, 仮想化技術

– i –

Abstract

Integrated management system of virtual machine and

virtual network in OpenStack system

Koichi Kyuna

Recently, cloud computing became widely used. OpenStack is the software to build

the IaaS infrastructure. OpenStack is used as the system development environment

because OpenStack can be used freely quickly a virtual machine and virtual network

by a user. Generally, we need to take the backup of system configuration when we

are developing a system. However, we can not to do capture and restore a whole

system configuration in OpenStack. It takes much time to capture and restore a system

configuration in current OpenStack because OpenStack captures and restores a virtual

machine and virtual network independently.

In this paper, we propose a integrated management system that captures and re-

stores a virtual machine and virtual network. The integrated management system re-

duces number of operation and operation time because integrated management system

enable to capture and restore with integrated Web interface. Additionally, we evalu-

ate the effectiveness for the proposed method. Experimental result, shows integrated

management system reduce about 80% of the operation time.

key words OpenStack, IaaS, SDN, Virtualization technology

– ii –

目次

第 1章はじめに 1

1.1 IaaSの動向 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 OpenStackの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 現状の問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 問題点の解決方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

第 2章統合管理方式の提案 5

2.1 統合管理方式の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 統合管理方式の要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 統合管理方式で扱うリソース . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 リソースの実体 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 リソースのキャプチャ方法 . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 リソースのリストア方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7 リソースの依存関係を考慮したリストア . . . . . . . . . . . . . . . . . . . 14

第 3章統合管理方式の実装 15

3.1 統合管理方式の構築環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 システム構成のキャプチャ . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 キャプチャの手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.2 キャプチャ画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.3 キャプチャプログラム . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 システム構成のリストア . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.1 リストアの手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.2 リストア画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

– iii –

目次

3.3.3 リストアプログラム . . . . . . . . . . . . . . . . . . . . . . . . . . 23

第 4章評価 31

4.1 評価の目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 操作回数の定量化と評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.1 評価内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.2 評価環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.3 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.4 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3 被験者の操作回数及び操作時間の計測と評価 . . . . . . . . . . . . . . . . 34

4.3.1 評価内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3.2 評価環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3.3 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.4 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

第 5章おわりに 39

5.1 研究のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

謝辞 41

参考文献 42

– iv –

図目次

1.1 世界のクラウドサービス市場予測 . . . . . . . . . . . . . . . . . . . . . . . 1

2.1 統合管理方式の概略図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 システム構成例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 ネットワーク構成情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 サブネット構成情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 ルータ構成情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6 インスタンス構成情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7 ルータ内部インタフェース構成情報 . . . . . . . . . . . . . . . . . . . . . . 11

2.8 インスタンス用ポート構成情報 . . . . . . . . . . . . . . . . . . . . . . . . 11

2.9 展開に使用するネットワーク構成情報 . . . . . . . . . . . . . . . . . . . . 12

2.10 展開に使用するサブネット構成情報 . . . . . . . . . . . . . . . . . . . . . . 12

2.11 展開に使用するルータ構成情報 . . . . . . . . . . . . . . . . . . . . . . . . 13

2.12 展開に使用するインスタンス構成情報 . . . . . . . . . . . . . . . . . . . . 13

2.13 展開に使用するルータ内部インタフェース構成情報 . . . . . . . . . . . . . 13

2.14 展開に使用するインスタンス用ポート構成情報 . . . . . . . . . . . . . . . . 13

2.15 リソースの依存関係 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 コンポーネント構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 キャプチャ画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 キャプチャプログラムのフローチャート . . . . . . . . . . . . . . . . . . . 18

3.4 リストア画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5 リストアプログラムのフローチャート . . . . . . . . . . . . . . . . . . . . 24

4.1 1・3・5セグメント構成における各被験者のクリック数 . . . . . . . . . . . 35

– v –

図目次

4.2 1・3・5セグメント構成における各被験者の画面遷移数 . . . . . . . . . . . 36

4.3 1・3・5セグメント構成における各被験者のフォーム入力項目数 . . . . . . 36

4.4 1・3・5セグメント構成における各被験者のファイル出力数 . . . . . . . . . 37

4.5 1・3・5セグメント構成における各被験者の操作時間 . . . . . . . . . . . . 37

– vi –

表目次

1.1 OpenStackの主要コンポーネント . . . . . . . . . . . . . . . . . . . . . . 2

2.1 統合管理方式に求められる要件 . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Linux既存技術の対応関係 . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 OpenStack環境の詳細情報 . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 評価要素 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 クライアント環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 1・3・5セグメント構成における各要素の最少回数 . . . . . . . . . . . . . 32

4.4 評価要素 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.5 クライアント環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

– vii –

第 1章

はじめに

1.1 IaaSの動向

サーバ仮想化や通信ネットワークの技術進歩に伴い，クラウドコンピューティングが普及

している．一般ユーザ向けに提供されるサービスや，企業内で利用される専用アプリケー

ションなど，多くのサービスがクラウドを用いて提供されており，このクラウドコンピュー

ティングにおいて，IaaSの需要が高まっている．総務省の「平成 26年版情報通信白書」に

よると，図 1.1に示す通り，市場規模における IaaSの割合が 2014年度の 16.5%から 2018

年度には 27.2%に増加すると予測されている [1]．そのため，今後さらに IaaSの需要が高ま

ると考えられる．

図 1.1 世界のクラウドサービス市場予測

– 1 –

1.2 OpenStackの概要

IaaS とは，システムの稼動に必要なサーバやストレージ，ネットワークなどのインフラ

を，インターネット経由で提供するサービスのことである．プロバイダは物理サーバや物理

ネットワーク機器などを仮想化し IaaS基盤を構築してサービスを提供する．一般ユーザや

企業は IaaSを利用することで，仮想化されたリソースを使用して，迅速にシステムを構築

しサービスを提供できるようになる．

IaaS の代表的なサービスに「Amazon Web Services」や「Microsoft Azure」，「Google

Compute Engine」がある．これらサービスは各プロバイダが独自仕様で開発している IaaS

基盤を用いているため，ベンダロックインが起こる可能性がある．

一方，多くのプロバイダが参加するコミュニティによって開発される IaaS基盤構築ソフ

トウェアに OpenStack がある [2]．OpenStack は，IaaS 基盤を構築するためのオープン

ソースソフトウェアで，コミュニティに参加しているプロバイダは，OpenStack をベース

に，IaaS を提供している．今後，OpenStack をベースとした IaaS プロバイダが増えるこ

とで，単一のプロバイダによるサービスだけでなく，複数のプロバイダによるサービスを取

捨選択できるようになる．

1.2 OpenStackの概要

OpenStack は，機能別にコンポーネントが分かれており，各コンポーネントが相互に連

携して動作する [3]．OpenStackの主要コンポーネントを表 1.1に示す．

表 1.1 OpenStackの主要コンポーネント

コンポーネント機能

Keystone 統合認証サービスの提供

Nova 仮想マシンの生成と起動停止の管理

Glance 仮想マシンテンプレートイメージの管理

Cinder ブロックストレージの管理

Neutron 仮想ネットワークの管理

Horizon OpenStackの操作管理を行うWebUIの提供

Swift オブジェクトストレージの提供

– 2 –

1.3 現状の問題点

OpenStackは，2010年 10月に公開された初期バージョンから，2014年 10月に公開さ

れた最新バージョンに至るまで，パブリッククラウドやプライベートクラウドの構築に多く

利用されている．

アメリカ国家安全保障局 (NSA)では，OpenStackをベースにプライベートクラウドを構

築し，研究者にオンデマンドで計算機資源を入手できる環境を提供している [4]．従来は計

算機資源を利用するまでに，申請，工事，設置のプロセスが必要で，研究者の要望に応じて

迅速に計算機資源を提供できないという問題が発生していた．そこで，OpenStackをベー

スにプライベートクラウドを構築することで，研究者自身が計算機資源である仮想マシンを

自由に迅速に利用できるようになった．

このように，OpenStack を用いることで，利用者自身が仮想マシンを自由に迅速に利用

できる IaaSサービスを提供できる．

1.3 現状の問題点

OpenStack は，利用者自身が仮想マシンや仮想ネットワークを自由に迅速に利用できる

ことから，システム開発環境に利用される事例も現れている [5]．OpenStackを用いること

で，システム開発環境を利用するまでの，申請，工事，設置のプロセスを省くことができ，

迅速にシステムの開発が行える．

一般的にシステムの開発を行う場合，サーバとネットワークを含むシステム構成全体の

バックアップやバージョン管理が行われる．バックアップを取ることで，設定変更時に問題

が発生した場合でも，バージョンを戻すことができ，問題の原因も特定できるためである．

そのため，OpenStack でシステムを開発する場合，システム構成全体のキャプチャとリス

トアが行える必要がある．しかし，OpenStack には仮想マシンと仮想ネットワークを含む

システム構成全体のキャプチャとリストアを行う機能がない．

現状の OpenStackでシステム構成全体をキャプチャ及びリストアする場合，仮想マシン

と仮想ネットワークをそれぞれ別々にキャプチャ及びリストアする必要がある．仮想マシン

– 3 –

1.4 問題点の解決方法

の保存は，各仮想マシンのスナップショットを作成し，仮想ネットワークの保存は，各仮想

ネットワークの設定情報をファイルへ出力する．仮想マシンの展開は，各スナップショット

から仮想マシンを起動し，仮想ネットワークの展開は，ファイルの各設定情報から仮想ネッ

トワークを再構築する．そのため，システム構成全体のキャプチャとリストアに，多くの操

作回数と操作時間が必要になる．

1.4 問題点の解決方法

1.3 節で述べた通り，現状の OpenStack における問題点は，システム構成全体をキャプ

チャ及びリストアする場合，クリック数や画面遷移数，フォーム入力項目数が増え，多くの

操作時間が必要になることである．

問題点の解決方法として，1つ目にインタフェースの改良策を提案する．従来の方法では，

システム構成全体をキャプチャ及びリストアする場合，所属するリソースごとに別の画面で

キャプチャ及びリストアする必要があった．そこで，統合管理方式では，1つの画面でシス

テム構成に所属するリソースを選択しキャプチャできるようにする．また，1つの画面で保

存されたシステム構成をリストアできるようにする．

2つ目に，仮想マシンと仮想ネットワークの自動統合保存策を提案する．従来の方法では，

システム構成全体をキャプチャ及びリストアする場合，所属するリソースの相互対応関係を

ユーザ自身で記録する必要があった．そこで，統合管理方式では，システム構成に所属する

リソースを選択しキャプチャを実行すると，選択されたリソースの対応関係を自動で分析し

保存する．また，システム構成のリストア時には保存された対応関係をもとに自動で各リ

ソースを対応付けてリストアする．

本研究では，2 つの解決策をもとに，仮想マシンと仮想ネットワークを統合的にキャプ

チャ及びリストアする統合管理方式を提案し，この方式を実装して有効性を評価する．

– 4 –

第 2章

統合管理方式の提案

2.1 統合管理方式の概要

統合管理方式では，システム構成のキャプチャとリストアを管理画面で行えるようにし，

操作回数と操作時間を削減する．統合管理方式の概略図を図 2.1に示す．

図 2.1 統合管理方式の概略図

システム構成全体のキャプチャは，キャプチャ画面で行う．キャプチャ画面にて保存する

リソースを選択し，選択された仮想マシンや仮想ネットワークを関連付けて保存する．シス

– 5 –

2.2 統合管理方式の要件

テム構成全体のリストアは，リストア画面で行う．リストア画面にて展開するシステム構成

を選択し，選択されたシステム構成に所属する各リソースを展開する．

2.2 統合管理方式の要件

統合管理方式の実装方法を検討するにあたり，統合管理方式に求められる要件を表 2.1に

示す．

表 2.1 統合管理方式に求められる要件

要件理由

操作インタフェースは GUI (Open-

Stackダッシュボード)

複雑なシステム構成を視覚的に表現できるため

利用対象者は一般ユーザ GUI(OpenStackダッシュボード)の利用者は一

般ユーザが多いため

扱うシステム構成のネットワーク規

模は 2から 5セグメント

一般的に 2 から 5 セグメント構成でシステムが

構築されているため [6]

システム構成内から指定した範囲の

キャプチャ及びリストアが可能

システム構成内から特定の仮想マシンや仮想ネッ

トワークを保存できるようにするため

同一設定情報を持つシステム構成の

複数構築が可能

1つのシステム構成から複数のバージョンを作成

して比較できるようにするため

階層ネットワークセグメントを含む

システム構成のキャプチャ及びリス

トアは不可

OpenStackでは階層ネットワークセグメントを

構築できないため

複数テナントを跨ったシステム構成

のキャプチャ及びリストアは不可

一般ユーザは別テナントの仮想マシンや仮想ネッ

トワークにアクセスできないため

同一設定情報を持つシステム構成同

士での通信は不可

同一設定情報を持つシステム構成同士が通信を

行うと IPアドレスの重複が発生するため

外部ネットワーク及びルータ外部

ゲートウェイの保存は不可

一般ユーザは外部ネットワークを構築すること

ができないため

– 6 –

2.3 統合管理方式で扱うリソース

2.3 統合管理方式で扱うリソース

統合管理方式では，システム構成のキャプチャとリストアを行う．システム構成内のリ

ソースには仮想マシンと仮想ネットワークがあり，仮想ネットワークの実態は，ネットワー

クとサブネット，ルータとルータ内部インタフェース，インスタンス用ポートである．その

ため，統合管理方式で扱うリソースは以下の通りとなる．

(A) ネットワーク

(B) サブネット

(C) ルータ

(D) インスタンス (仮想マシン)

(E) ルータ内部インタフェース

(F) インスタンス用ポート

統合管理方式で扱うリソースが全て含まれるシステム構成例を図 2.2に示す．Aから Fの

各リソースは図 2.2内の Aから Fの各リソースと対応している．

図 2.2 システム構成例

– 7 –

2.4 リソースの実体

2.4 リソースの実体

OpenStack の各リソースは，Linux 既存技術の組み合わせによって実現されている [7]．

各リソースと Linux既存技術の対応関係を表 2.2に示す．

表 2.2 Linux既存技術の対応関係

リソース利用される Linux既存技術

ネットワーク及びサブネット Open vSwitch，ネットワークネームスペース

ルータ Open vSwitch，ネットワークネームスペース，IP Tables，IP Forward

ルータ内部インタフェース Open vSwitch，ネットワークネームスペース

インスタンス用ポート Open vSwitch，Linux Bridge

インスタンス KVM

各リソースの実体は，リソース構成情報と実行プロセス及びプロセス内設定情報に分けら

れる．リソース構成情報は，リソースの作成時に，リソースの定義情報としてデータベース

に保存される情報のことである．一方，実行プロセス及びプロセス内設定情報は，リソース

の作成時に，リソース構成情報をもとに作成されるアプリケーション内のプロセスや設定情

報のことである．

OpenStack では，一度作成したリソースの構成情報を使用して，同一のリソースを作成

することができる．そこで，統合管理方式でのリソースのキャプチャは，リソース構成情報

の取得保存で実現する．また，統合管理方式でのリソースのリストアは，保存されたリソー

ス構成情報の取得展開で実現する．

– 8 –

2.5 リソースのキャプチャ方法


統合管理方式では，リソースのキャプチャを行う場合，リソース構成情報を取得して保存

する．構成情報の取得には OpenStack APIを使用し，取得した構成情報からリストアに必

要な情報を抽出してデータベースに保存する．インスタンスについては，OpenStack API

を使用してイメージファイルも作成する．

ネットワーク構成情報の例を図 2.3に示す．

図 2.3 ネットワーク構成情報

サブネット構成情報の例を図 2.4に示す．

図 2.4 サブネット構成情報

– 9 –


ルータ構成情報の例を図 2.5に示す．

図 2.5 ルータ構成情報

インスタンス構成情報の例を図 2.6に示す．

図 2.6 インスタンス構成情報

– 10 –


ルータ内部インタフェース構成情報の例を図 2.7に示す．

図 2.7 ルータ内部インタフェース構成情報

インスタンス用ポート構成情報の例を図 2.8に示す．

図 2.8 インスタンス用ポート構成情報

– 11 –

2.6 リソースのリストア方法


統合管理方式では，リソースのリストアを行う場合，保存されたリソース構成情報を取得

して展開する．データベースに保存された構成情報を取得し，OpenStack APIを使用して

リソースを展開する．インスタンスについては，OpenStack APIを使用してイメージファ

イルから起動する．

展開に使用するネットワーク構成情報の例を図 2.9に示す．

図 2.9 展開に使用するネットワーク構成情報

展開に使用するサブネット構成情報の例を図 2.10に示す．

図 2.10 展開に使用するサブネット構成情報

– 12 –


展開に使用するルータ構成情報の例を図 2.11に示す．

図 2.11 展開に使用するルータ構成情報

展開に使用するインスタンス構成情報の例を図 2.12に示す．

図 2.12 展開に使用するインスタンス構成情報

展開に使用するルータ内部インタフェース構成情報の例を図 2.13に示す．

図 2.13 展開に使用するルータ内部インタフェース構成情報

展開に使用するインスタンス用ポート構成情報の例を図 2.14に示す．

図 2.14 展開に使用するインスタンス用ポート構成情報

– 13 –

2.7 リソースの依存関係を考慮したリストア

2.7 リソースの依存関係を考慮したリストア

2.3節で述べた通り，統合管理方式で扱うリソースは全部で 6つある．これらリソースを

リストアする場合，図 2.15に示すリソースの依存関係を考慮して，リストアの順番を決め

る必要がある．

例えば，ネットワークとルータは依存するリソースが無いため，容易に作成することがで

きる．しかし，サブネットを作成する場合，ネットワーク IDが必要になる．また，インス

タンス用ポートを作成する場合，ネットワーク IDとサブネット IDが必要になる．

図 2.15 リソースの依存関係

リソースの依存関係より，リストアの順番を以下の通り決定した．この順番の通りにリス

トアを行うことで，セグメント数が多い場合や，インスタンス数が多い場合でも，正確にリ

ストアすることができる．

(1) ネットワーク

(2) サブネット

(3) ルータ

(4) ルータ内部インタフェース

(5) インスタンス用ポート

(6) インスタンス

– 14 –

第 3章

統合管理方式の実装

3.1 統合管理方式の構築環境

OpenStack 環境は，コントローラノード 1 台とコンピュートノード 1 台の構成である．

OpenStack環境の詳細情報を表 3.1に示す．

表 3.1 OpenStack環境の詳細情報

ノード使用機器 CPU メモリ OS OpenStack

コントローラノード HP ProLiant

ML350e Gen8

Intel Xeon CPU

E5-2420

8GB CentOS7 Juno

コンピュートノード HP ProLiant

ML350e Gen8

Intel Xeon CPU

E5-2420

16GB CentOS7 Juno

各ノード内のコンポーネント構成を図 3.1に示す．

図 3.1 コンポーネント構成

– 15 –

3.2 システム構成のキャプチャ

統合管理方式の実装は，コントローラノード内にて行った．Web インタフェースは

OpenStack ダッシュボード (Django) を使用し，プログラミング言語は Python2.7.5 を使

用した．


3.2.1 キャプチャの手順

統合管理方式におけるキャプチャの手順は以下の通りである．

(1) キャプチャ画面にて，保存するリソースの選択後，保存実行

(2) 選択された各リソース (ネットワーク，ルータ，インスタンス)の IDをキャプチャプロ

グラムへ受け渡す

(3) キャプチャプログラムは，受け取った IDと OpenStack APIを使用して，各リソース

の構成情報を取得しデータベースに保存 (インスタンスはイメージファイルも作成)

– 16 –


3.2.2 キャプチャ画面

統合的にキャプチャを行うキャプチャ画面を図 3.2に示す．キャプチャ画面では，保存す

るシステム構成の名前を入力後，保存するシステム構成に所属するリソースを選択し，実行

ボタンをクリックすることで，統合キャプチャが行える．

図 3.2 キャプチャ画面

3.2.3 キャプチャプログラム

統合的にキャプチャを行うキャプチャプログラムのフローチャートを図 3.3に示す．プロ

グラムの流れは，ネットワーク及びサブネットの保存，ルータ及びルータ内部インタフェー

スの保存，インスタンス及びインスタンス用ポートの保存となっている．キャプチャプログ

ラムは，初めにシステム構成として統合的に保存する各情報を受け取る．情報には，システ

ム構成名とテナント ID，3つのリソース IDがある．3つのリソース IDは，配列として受

け取る．以下にフローチャート内の各定義済処理の内容を示す．フローチャート内の Aから

Jの各定義済処理は，以下に示す Aから Jの各定義済処理と対応している．

– 17 –


図 3.3 キャプチャプログラムのフローチャート

(A)システム構成名とテナント IDの保存処理

システム構成名とテナント IDをデータベースに保存する．保存されたシステム構成の ID

を返却する．

– 18 –


(B)ネットワークの保存処理

ネットワーク ID を使用して，OpenStack API でネットワーク構成情報を取得し，シス

テム構成 IDとネットワーク構成情報をデータベースに保存する．保存されたネットワーク

の IDを返却する．

OpenStack APIを使用したネットワーク構成情報取得のプログラム例を以下に示す．

ネットワーク構成情報取得� �from neutronclient.v2_0 import client as neutronclient

from openstack_dashboard.api import base

neutron = neutronclient.Client(token=request.user.token.id, auth_url=

base.url_for(request, ’identity’), endpoint_url=base.url_for(request,

’network’))

net_detail = neutron.show_network(ネットワーク ID)� �(C)サブネットの保存処理

サブネット ID を使用して，OpenStack API でサブネット構成情報を取得し，システム

構成 IDとサブネット構成情報をデータベースに保存する．保存されたサブネットの IDを

返却する．

OpenStack APIを使用したサブネット構成情報取得のプログラム例を以下に示す．

サブネット構成情報取得� �from neutronclient.v2_0 import client as neutronclient




’network’))

subnet_detail = neutron.show_subnet(サブネット ID)� �

– 19 –


(D)保存されたネットワークと保存されたサブネットの対応保存処理

システム構成 IDと保存されたネットワーク ID，保存されたサブネット IDを対応付けて

データベースに保存する．

(E)ルータの保存処理

ルータ IDを使用して，OpenStack APIでルータ構成情報を取得し，システム構成 IDと

ルータ構成情報をデータベースに保存する．保存されたルータの IDを返却する．

OpenStack APIを使用したルータ構成情報取得のプログラム例を以下に示す．

ルータ構成情報取得� �from neutronclient.v2_0 import client as neutronclient




’network’))

router_detail = neutron.show_router(ルータ ID)� �(F)ルータ内部インタフェースの取得処理

OpenStack APIでポート一覧を取得して，ルータ IDから，ルータに接続されているイ

ンタフェースを取得し，保存されているサブネットの IDを返却する．

OpenStack APIを使用したルータ内部インタフェース構成情報取得のプログラム例を以

下に示す．

ルータ内部インタフェース構成情報取得� �from neutronclient.v2_0 import client as neutronclient




’network’))

router_port_all = neutron.list_ports()� �

– 20 –


(G)保存されたルータと保存されたサブネットの対応保存処理

システム構成 ID と保存されたルータ ID，保存されているサブネット ID を対応付けて

データベースに保存する．

(H)インスタンスの保存処理

インスタンス IDを使用して，OpenStack APIでインスタンス構成情報を取得し，イン

スタンスのイメージファイルを作成する．システム構成 IDとイメージファイル ID，インス

タンス構成情報をデータベースに保存する．保存されたインスタンスの IDを返却する．

OpenStack APIを使用したインスタンス構成情報取得とイメージファイル作成のプログ

ラム例を以下に示す．

インスタンス構成情報取得とイメージファイル作成� �from novaclient.v1_1 import client as novaclient


nova = novaclient.Client(request.user.username, request.user.token.id

, project_id=request.user.tenant_id, auth_url=base.url_for(request, ’

compute’))

nova.client.auth_token = request.user.token.id

nova.client.management_url = base.url_for(request, ’compute’)

server_detail = nova.servers.get(インスタンス ID)

snapshot = nova.servers.create_image(server=インスタンス ID, image_nam

e=作成するイメージファイル名)� �

– 21 –

3.3 システム構成のリストア

(I)インスタンス用ポートの取得処理

OpenStack APIでポート一覧を取得して，インスタンス IDから，インスタンスに接続

されているポートを取得し，保存されているサブネットの IDを返却する．

OpenStack APIを使用したインスタンス用ポート構成情報取得のプログラム例を以下に

示す．

インスタンス用ポート構成情報取得� �from neutronclient.v2_0 import client as neutronclient




’network’))

instance_port_all = neutron.list_ports()� �(J)保存されたインスタンスと保存されたサブネットの対応保存処理

システム構成 IDと保存されたインスタンス ID，保存されているサブネット IDを対応付

けてデータベースに保存する．


3.3.1 リストアの手順

統合管理方式におけるリストアの手順は以下の通りである．

(1) リストア画面にて，展開するシステム構成の選択後，展開実行

(2) 選択されたシステム構成の IDをリストアプログラムへ受け渡す

(3) リストアプログラムは，受け取った IDを使用して，データベースから各リソースの構

成情報を取得し OpenStack APIで展開 (インスタンスはイメージファイルから起動)

– 22 –


3.3.2 リストア画面

統合的にリストアを行うリストア画面を図 3.4に示す．リストア画面では，展開するシス

テム構成を選択し，実行ボタンをクリックすることで，統合リストアが行える．

図 3.4 リストア画面

3.3.3 リストアプログラム

統合的にリストアを行うリストアプログラムのフローチャートを図 3.5に示す．プログラ

ムの流れは，ネットワーク及びサブネットの展開，ルータ及びルータ内部インタフェースの

展開，インスタンス及びインスタンス用ポートの展開となっている．リストアプログラムは，

初めに展開するシステム構成の IDを受け取る．以下にフローチャート内の各定義済処理の

内容を示す．フローチャート内の Aから Lの各定義済処理は，以下に示す Aから Lの各定

義済処理と対応している．

– 23 –


図 3.5 リストアプログラムのフローチャート

– 24 –


(A)ネットワークの取得処理

システム構成 IDを使用して，データベースからシステム構成に所属するネットワークを

取得し，保存されているネットワークの IDを返却する．

(B)ネットワークの展開処理

保存されているネットワーク IDを使用して，データベースからネットワーク構成情報を

取得し，ネットワーク構成情報をもとに OpenStack APIでネットワークを展開する．展開

されたネットワークの IDを返却する．

OpenStack APIを使用したネットワーク展開のプログラム例を以下に示す．

ネットワーク展開� �from neutronclient.v2_0 import client as neutronclient




’network’))

net_detail = {’network’: {’name’: ネットワーク名, ’admin_state_up’: Tr

ue, ’tenant_id’: テナント ID, ’provider:network_type’: gre, ’router:ex

ternal’: False, ’shared’: False}}

crt_net = neutron.create_network(body=net_detail)� �(C)ネットワークに所属するサブネットの取得処理

システム構成 IDと保存されているネットワーク IDを使用して，データベースからシス

テム構成に所属するネットワークに対応するサブネットを取得し，保存されているサブネッ

トの IDを返却する．

– 25 –


(D)サブネットの展開処理

保存されているサブネット ID を使用して，データベースからサブネット構成情報を取

得し，展開されたネットワーク IDとサブネット構成情報をもとに OpenStack APIでサブ

ネットを展開する．展開されたサブネットの IDを返却する．

OpenStack APIを使用したサブネット展開のプログラム例を以下に示す．

サブネット展開� �from neutronclient.v2_0 import client as neutronclient




’network’))

subnet_detail = {’subnet’: {’name’: サブネット名, ’enable_dhcp’: True

または False, ’network_id’: 依存するネットワークの ID, ’tenant_id’: テナ

ント ID, ’dns_nameservers’: DNSサーバの IPアドレス, ’allocation_pools’

: IPアドレスの割り当て範囲, ’gateway_ip’: ゲートウェイの IPアドレス, ’ip

_version’: 4, ’host_routes’: 別ネットワークの宛先, ’cidr’: ネットワーク

アドレス}}

crt_subnet = neutron.create_subnet(body=subnet_detail)� �(E)ルータの取得処理

システム構成 IDを使用して，データベースからシステム構成に所属するルータを取得し，

保存されているルータの IDを返却する．

– 26 –


(F)ルータの展開処理

保存されているルータ IDを使用して，データベースからルータ構成情報を取得し，ルー

タ構成情報をもとに OpenStack APIでルータを展開する．展開されたルータの IDを返却

する．

OpenStack APIを使用したルータ展開のプログラム例を以下に示す．

ルータ展開� �from neutronclient.v2_0 import client as neutronclient




’network’))

router_detail = {’router’: {’name’: ルータ名, ’admin_state_up’: True,

’tenant_id’: テナント ID, ’distributed’: False, ’ha’: False}}

crt_router = neutron.create_router(body=router_detail)� �(G)ルータと対応するインタフェースの取得処理

システム構成 IDと保存されているルータ IDを使用して，データベースからシステム構

成に所属するルータに接続するサブネットを取得し，保存されているサブネットの IDを返

却する．

– 27 –


(H)ルータ内部インタフェースの展開処理

保存されているサブネット IDに対応する展開されたサブネット IDと，展開されたルー

タ IDをもとに OpenStack APIでルータ内部インタフェースを展開する．

OpenStack APIを使用したルータ内部インタフェース展開のプログラム例を以下に示す．

ルータ内部インタフェース展開� �from neutronclient.v2_0 import client as neutronclient




’network’))

add_port = {’subnet_id’: 依存するサブネットの ID}

neutron.add_interface_router(依存するルータの ID, body=add_port)� �(I)インスタンスの取得処理

システム構成 IDを使用して，データベースからシステム構成に所属するインスタンスを

取得し，保存されているインスタンスの IDを返却する．

(J)インスタンスと対応するポートの取得処理

システム構成 IDと保存されているインスタンス IDを使用して，データベースからシス

テム構成に所属するインスタンスに接続するサブネットを取得し，保存されているサブネッ

トの IDを返却する．

– 28 –


(K)インスタンス用ポートの展開処理

保存されているサブネット IDに対応する展開されたサブネット IDと，展開されたネッ

トワーク IDをもとに OpenStack APIでインスタンス用ポートを展開する．展開されたイ

ンスタンス用ポートの IDを返却する．

OpenStack APIを使用したインスタンス用ポート展開のプログラム例を以下に示す．

インスタンス用ポート展開� �from neutronclient.v2_0 import client as neutronclient




’network’))

port_detail = {’port’: {’admin_state_up’: True, ’network_id’: 依存す

るネットワークの ID, ’tenant_id’: テナント ID, ’fixed_ips’: [{u’subnet_id

’: 依存するサブネットの ID}]}}

crt_port = neutron.create_port(body=port_detail)� �

– 29 –


(L)インスタンスの展開処理

保存されているインスタンス IDを使用して，データベースからインスタンス構成情報を

取得し，展開されたインスタンス用ポート IDとイメージファイル ID，インスタンス構成情

報をもとに OpenStack APIでインスタンスを展開する．

OpenStack APIを使用したインスタンス展開のプログラム例を以下に示す．

インスタンス展開� �from novaclient.v1_1 import client as novaclient


nova = novaclient.Client(request.user.username, request.user.token.id

, project_id=request.user.tenant_id, auth_url=base.url_for(request, ’

compute’))

nova.client.auth_token = request.user.token.id

nova.client.management_url = base.url_for(request, ’compute’)

use_image = nova.images.find(id=依存するイメージファイルの ID)

use_flavor = nova.flavors.find(id=依存するフレーバの ID)

use_nics = [{’port-id’: 依存するインスタンス用ポートの ID}]

nova.servers.create(name=インスタンス名, image=use_image, flavor=use_f

lavor, nics=use_nics)� �

– 30 –

第 4章

評価

4.1 評価の目的

本研究では，システム構成全体のキャプチャとリストアに，多くの操作回数と操作時間が

必要になる問題を解決する方法として，統合管理方式を提案し実装した．そこで，統合管理

方式の有効性を評価するために，評価項目 1「操作回数の定量化と評価」，評価項目 2「被

験者の操作回数及び操作時間の計測と評価」を行う．

4.2 操作回数の定量化と評価

4.2.1 評価内容

従来の方法または統合管理方式で，システム構成をキャプチャ及びリストアする場合の，

表 4.1に示す各要素の最少回数を算出する．

表 4.1 評価要素

要素定義

クリック数キャプチャ・リストアの実行に必要となる左クリックの回数

画面遷移数キャプチャ・リストアの実行時に別画面へ移動する回数

フォーム入力項目数キャプチャ・リストアの実行に必要となるフォームの入力項目数

ファイル出力数キャプチャ・リストアの実行時にリソース情報をファイルへ出力する回数

– 31 –


4.2.2 評価環境

評価を行うにあたり，使用したクライアント環境を表 4.2に示す．

表 4.2 クライアント環境

使用機器 CPU メモリ OS Webブラウザ

富士通 ESPRIMO D582/G Intel Core i5-3470 CPU 4GB Windows7 Firefox 35.0

評価にて行うキャプチャ及びリストアの対象とするシステム構成を以下に示す．

(A) 1セグメント構成

(ネットワーク 1つ，サブネット 1つ，ルータ 1つ，インスタンス 1つ)

(B) 3セグメント構成


(C) 5セグメント構成


4.2.3 結果

1・3・5セグメント構成における各要素の最少回数を表 4.3に示す．

表 4.3 1・3・5セグメント構成における各要素の最少回数

1セグメント構成 3セグメント構成 5セグメント構成

要素従来の方法統合管理方式従来の方法統合管理方式従来の方法統合管理方式

クリック数 22 10 50 10 78 10

画面遷移数 21 9 49 9 77 9

フォーム入力項目数 19 6 53 10 87 14

ファイル出力数 6 0 16 0 26 0

– 32 –


4.2.4 考察

4.2.3項の結果より，統合管理方式を用いることで，4つの評価要素全てを削減できたこと

が分かる．従来の方法では，セグメント数が増えるにつれて全ての要素が増加した．一方，

統合管理方式では，フォーム入力項目数以外の 3つの要素を一定に保つことができた．

フォーム入力項目数以外の 3つの要素を一定に保つことができた理由としては，統合管理

方式がキャプチャ画面とリストア画面にて，一括でキャプチャ及びリストアできるためだと

考えられる．また，フォーム入力項目数のみが増加した理由としては，統合管理方式のキャ

プチャ画面にて全てのリソースを保存する場合，全てのチェックボックスを選択する必要が

あるためだと考えられる．

そのため，統合管理方式のキャプチャ画面に全てのチェックボックスを自動選択できるボ

タンなどを用意することで，フォーム入力項目数も一定に保つことができるようになる．

– 33 –

4.3 被験者の操作回数及び操作時間の計測と評価


4.3.1 評価内容

OpenStackの操作方法を事前学習した被験者 5人に，従来の方法または統合管理方式で，

システム構成のキャプチャ及びリストアを実行してもらい，表 4.4に示す各要素の回数と操

作時間を計測する．

表 4.4 評価要素

要素定義

クリック数キャプチャ・リストアの実行に必要となる左クリックの回数

画面遷移数キャプチャ・リストアの実行時に別画面へ移動する回数

フォーム入力項目数キャプチャ・リストアの実行に必要となるフォームの入力項目数

ファイル出力数キャプチャ・リストアの実行時にリソース情報をファイルへ出力する回数

操作時間キャプチャ・リストアの実行から終了までに必要となる操作の時間

4.3.2 評価環境

評価を行うにあたり，使用したクライアント環境を表 4.5に示す．

表 4.5 クライアント環境

使用機器 CPU メモリ OS Webブラウザ

富士通 ESPRIMO D582/G Intel Core i5-3470 CPU 4GB Windows7 Firefox 35.0

– 34 –


評価にて行うキャプチャ及びリストアの対象とするシステム構成を以下に示す．

(A) 1セグメント構成


(B) 3セグメント構成


(C) 5セグメント構成


4.3.3 結果

1・3・5セグメント構成における各被験者のクリック数を図 4.1に示す．

図 4.1 1・3・5セグメント構成における各被験者のクリック数

– 35 –


1・3・5セグメント構成における各被験者の画面遷移数を図 4.2に示す．

図 4.2 1・3・5セグメント構成における各被験者の画面遷移数

1・3・5セグメント構成における各被験者のフォーム入力項目数を図 4.3に示す．

図 4.3 1・3・5セグメント構成における各被験者のフォーム入力項目数

– 36 –


1・3・5セグメント構成における各被験者のファイル出力数を図 4.4に示す．

図 4.4 1・3・5セグメント構成における各被験者のファイル出力数

1・3・5セグメント構成における各被験者の操作時間を図 4.5に示す．

図 4.5 1・3・5セグメント構成における各被験者の操作時間

– 37 –


4.3.4 考察

4.3.3 項の結果より，統合管理方式を用いることで，クリック数と画面遷移数，フォーム

入力項目数とファイル出力数を削減でき，操作時間を短縮できたことが分かる．従来の方法

では，セグメント数が増えるにつれて全ての要素が増加しており，ユーザによって大きな差

も開いていた．一方，統合管理方式では，クリック数と画面遷移数，ファイル出力数を一定

に保つことができ，ユーザによって大きな差も開いていなかった．また，操作時間は増加し

ているが，従来の方法に比べると大幅に短縮でき，ユーザによって大きな差も開いていな

かった．

クリック数と画面遷移数，ファイル出力数を一定に保つことができた理由としては，統合

管理方式がキャプチャ画面とリストア画面にて，一括でキャプチャ及びリストアできるため

だと考えられる．また，ユーザによって大きな差が開いていなかったことから，ユーザの

能力に依存することなく，容易にシステム構成をキャプチャ及びリストアできることが分

かった．

従来の方法に比べて大幅に操作時間を短縮できた理由としては，統合管理方式がキャプ

チャ画面とリストア画面にて，一括でキャプチャ及びリストアできるためだと考えられる．

また，ユーザによって大きな差が開いていなかったことから，ユーザの能力に依存すること

なく，短時間でシステム構成をキャプチャ及びリストアできることが分かった．

– 38 –

第 5章

おわりに

5.1 研究のまとめ

本研究では，システム構成全体のキャプチャとリストアに，多くの操作回数と操作時間が

必要になる問題を解決する方法として，仮想マシンと仮想ネットワークを統合的にキャプ

チャ及びリストアする統合管理方式を提案し実装した．

4章の評価より，統合管理方式を用いることで，操作回数を削減し，操作時間を短縮でき

ることが分かった．また，ユーザによって操作回数や操作時間に大きな差が開いていなかっ

たことから，ユーザの能力に依存することなく，短時間かつ容易にシステム構成をキャプ

チャ及びリストアできることが分かった．

よって，統合管理方式を用いることで，従来の方法に比べて短時間かつ容易にシステム構

成全体をキャプチャ及びリストアできる．

5.2 今後の課題

統合管理方式の改良点としては，4.2.4項の考察で述べた通り，フォーム入力項目数を一

定に保つことができるインタフェースの追加がある．このインタフェースを追加することで，

現時点の統合管理方式より僅かに操作回数を削減し，操作時間を短縮できる．

今後，追加することで統合管理方式がより良くなる機能として，差分保存機能や，仮想

ネットワーク機器保存機能がある．差分保存機能は，システム構成の変更された部分のみを

差分で保存する機能である．この機能によって，保存されているシステム構成を展開して改

– 39 –

5.2 今後の課題

変し再度保存する場合に，保存容量を抑え保存実行時間を短縮できる．また，仮想ネット

ワーク機器保存機能は，仮想ロードバランサや仮想ファイアウォールも統合的に保存する機

能である．この機能によって，OpenStack 環境での商用利用に特化したシステム構成を統

合的に保存できる．

– 40 –

謝辞

大学生活及び研究活動にて多くの方々に協力して頂き，4年間の学生生活を無事に過ごす

ことができました．大学生活の最後に，本論文にて，お世話になった皆様に感謝の意を述べ

させていただきます．

本研究を進めるに当たり，研究指導および論文審査の主査として，横山和俊教授には多く

のご指導を頂きました．また，研究活動だけでなく，就職活動や社会人としての心構えにつ

いてもご指導を頂きました．心より感謝致します．本研究の副査をお引き受けいただき，多

くのご助言を頂きました情報学群島村和典教授と福本昌弘教授に心より感謝致します．

横山研究室の 1期生として共に切磋琢磨し研究活動に励んだ池添誠氏，川崎雄司氏，篠田

北斗氏，高崎龍太郎氏，高田僚介氏，谷村直哉氏，畑翔太氏には，多くの事でお世話になり

ました．心より感謝します．横山研究室に新たに配属された学部 3年の大崎康平氏，川口貴

大氏，小池主馬氏，別役速斗氏には，研究室行事や評価実験で多くの協力を得ました．心よ

り感謝します．

最後に，私の大学生活を支えてくれた両親にも感謝します．また，大学生活にて私に関わ

り協力して頂いた全ての方々に感謝します．ありがとうございました．

– 41 –

参考文献

[1] 総務省，“平成 26年版情報通信白書”，2014．

[2] OpenStack，https://www.openstack.org/．

[3] 中井悦司，中島倫明，“オープンソース・クラウド基盤 OpenStack 入門”，アスキー，

2014．

[4] CTC 教育サービス，“クラウド時代のオープンソース実践活用第 49 回エンタープ

ライズ企業に OpenStack は使いこなせるのか? (中井悦司)”，http://www.school.

ctc-g.co.jp/columns/nakai/nakai49.html，2015年 2月 20日．

[5] ITpro，“見えてきた先行企業の IT インフラ戦略ヤフーが OpenStack を採用したワ

ケ”，http://itpro.nikkeibp.co.jp/article/COLUMN/20140708/569822/，2015

年 2月 20日．

[6] 株式会社 NTT データ，杉原健朗，吉田一幸，岩崎賢治，三浦広志，吉田佐智男，“イ

ンフラデザインパターン安定稼動に導く 127の設計方式”，技術評論社，2014．

[7] 中井悦司，“解説と実践で理解する OpenStack 最終回仮想ネットワークに SDNを適

用する”，日経 Linux，2014/08号，pp.138-143，2014．

– 42 –

Documents

OpenStack 環境における仮想マシン と仮想ネットワークの統合 … · Abstract Integrated management system of virtual machine and virtual network in OpenStack system

OpenStack 環境における仮想マシンと仮想ネットワークの統合 … · Abstract Integrated management system of virtual machine and virtual network in OpenStack system