OpenStack運用管理編（GUI管理、テナントの作成、テナントでのWebサービス提供の確認まで）
事前準備で考えるべきこと
事前準備その1：仮想マシンか物理マシンか
packstackによるOpenStackのインストールが完了したら、早速テナントを作成し、クラウドの運用を行いたいところですが、事前準備があります。Packstackのアンサーファイルにおいて、ironicによる物理サーバーへのベアメタル配備（計算ノードでKVMの仮想マシンのゲストOS上でサービスを稼働させるのではなく、物理サーバー上でサービスを直接稼働させる）を有効にしているかによって、novaの設定が異なります。OpenStackおいて、実行中の仮想マシンのことを「インスタンス」と呼びます。以下では、計算ノードで稼働するKVM環境でインスタンスが稼働することを前提に説明します。KVM環境のゲストOSとしてインスタンスを稼働させるには、計算ノードのnovaの設定に注意が必要です。まずは、novaの設定ファイル「/etc/nova/nova.conf」で以下のパラメーターを確認します。ironicに関するパラメーターに先頭の「#」が入っているかどうかを確認してください。
# less /etc/nova/nova.conf
...
#compute_manager=ironic.nova.compute.manager.ClusteredComputeManager //comment{←コメントアウト//}
...
scheduler_host_manager=host_manager //comment{←scheduler_host_managerにhost_managerを使用
#scheduler_host_manager=nova.scheduler.ironic_host_manager.IronicHostManager //comment{←コメントアウト//}
...
compute_driver=libvirt.LibvirtDriver //comment{←compute_driverにlibvirtを使用
#compute_driver=ironic.IronicDriver //comment{←コメントアウト//}
...
#virt_type=kvm
virt_type=qemu //comment{←仮想化のタイプは「qemu」を選択//}
...
cpu_mode=host-model
設定ファイルを編集したら、計算ノードのOSを再起動するか、openstack-nova-computeサービスを再起動します。
# systemctl restart openstack-nova-compute # systemctl status openstack-nova-compute |grep running Active: active (running) since 日 2016-05-01 15:31:59 JST; 8s ago
これで、計算ノードでは、インスタンスを仮想化基盤上のゲストOSとして稼働させることができます。
事前準備その2：OpenStack自体を仮想化基盤のゲストOSで稼働させる場合
一般的に、OpenStackクラウド基盤の本番システムは、物理サーバー上に構築されますが、開発環境やOpenStackそのものの機能確認を簡易的に行うために、OpenStackクラウド基盤自体を仮想マシン上で稼働させる場合もあります。この場合、ゲストOS上でOpenStackが稼働し、さらにそのうえでゲストOSがインスタンスとして稼働することになります。この場合、インスタンスは、物理サーバー上で稼働するKVMの「仮想マシン上の仮想マシン」、すなわち、「仮想マシンの入れ子」の状態になります。一般的には、「ネストされたKVM」（Nested KVM）、あるいは、「ネストされた仮想化」（Nested Virtualization）と呼びます。ネストされたKVMの環境を実現するには、事前に物理マシン側のカーネルモジュールの設定が必要です。以下に、ネストされたKVM環境におけるカーネルモジュールの設定手順を述べます。まず、物理サーバーで稼働中のすべてのゲストOSを停止します。以下は、物理マシン上でKVMのゲストOS「n0121」を停止させる例です。
# virsh list --all Id 名前 状態 ---------------------------------------------------- 5 n0121 実行中 ... # virsh shutdown n0121 ドメイン n0121 はシャットダウン中です ... # virsh list --all Id 名前 状態 ---------------------------------------------------- - n0121 シャットオフ
次に、物理マシンで稼働するLinuxのKVM仮想化に関するカーネルモジュールの状態を確認します。物理マシンがIntel社製のCPUを搭載している場合とAMD社製のCPUを搭載している場合で手順が異なります。以下は、CentOS 7.2で確認する場合の例です。まず、物理サーバー上で、KVMの入れ子（ネストされたKVM）の設定状況を確認します。
●Intel社製CPUを搭載している場合：
# cat /sys/module/kvm_intel/parameters/nested N
●AMD社製CPUを搭載している場合：
# cat /sys/module/kvm_amd/parameters/nested 0
Intel社製のCPUの場合、KVMの入れ子の機能が無効の場合は「N」、有効の場合は「Y」と表示されます。AMD社製のCPUの場合、KVMの入れ子の機能が無効の場合は「0」、有効の場合は「1」と表示されます。次に、現在のカーネルモジュールの状況を確認します。
●Intel社製CPUを搭載している場合：
# lsmod |grep kvm kvm_intel 162153 0 kvm 525409 1 kvm_intel
●AMD社製CPUを搭載している場合：
# lsmod |grep kvm kvm_amd 65072 0 kvm 525409 1 kvm_amd
上記より、kvm_intelまたは、kvm_amdがカーネルモジュールでロードされていますので、カーネルモジュールを取り外します。
●Intel社製CPUを搭載している場合：
# modprobe -r kvm_intel # lsmod |grep kvm #
●AMD社製CPUを搭載している場合：
# modprobe -r kvm_amd # lsmod |grep kvm #
KVMの入れ子を有効にする設定を記述します。
●Intel社製CPUを搭載している場合：
# vi /etc/modprobe.d/dist.conf options kvm_intel nested=1
●AMD社製CPUを搭載している場合：
# vi /etc/modprobe.d/dist.conf options kvm_amd nested=1
再びカーネルモジュールをロードし、設定状況を確認します。
●Intel社製CPUを搭載している場合：
# modprobe kvm_intel # lsmod |grep kvm_intel kvm_intel 162153 0 kvm 525409 1 kvm_intel # cat /sys/module/kvm_intel/parameters/nested Y
●AMD社製CPUを搭載している場合：
# modprobe kvm_amd # lsmod |grep kvm_amd kvm_amd 65072 0 kvm 525409 1 kvm_amd # cat /sys/module/kvm_amd/parameters/nested 1
これで、ネストされたKVMが稼働できるようになりました。
Horizonへのログイン
OpenStackの管理GUIであるHorizonにログインできるかを確認します。Horizonにadminアカウントでログインするために、adminアカウントのパスワードを確認します。adminアカウントのパスワードは、/root/keystonerc_adminファイル内に記述された環境変数「OS_PASSWORD」の値です。
# cat /root/keystonerc_admin export OS_USERNAME=admin export OS_TENANT_NAME=admin export OS_PASSWORD=password1234 export OS_AUTH_URL=http://172.16.1.121:5000/v2.0/ export OS_REGION_NAME=RegionOne export PS1='[\u@\h \W(keystone_admin)]\$ '
図1: OpenStackのHorizonのログイン画面（図の説明： OpenStackが提供する管理GUIのログイン画面。最初はadminユーザーでログインする。パスワードは、/root/keystonerc_adminに記載されている）
● 注意 ●
adminユーザーで正しいパスワードを入力してもログインができない場合、KeystoneのAPIのバージョンをv2.0に変更し、httpdサービスを再起動するかOSを再起動してください。# vi /etc/openstack-dashboard/local_settings...OPENSTACK_API_VERSIONS = {'identity': 2.0}...===[/column]
# reboot
図2: Horizonからユーザーやプロジェクト（テナント）の作成を行う。仮想マシンの作成や起動もHorizonのGUI管理画面から行える
以下では、CentOS 7で構築したOpenStack環境にプロジェクト（テナント）を1つ作成します。さらに、プロジェクト内でインスタンスを作成し、インスタンスへのログイン、インスタンスからインターネットへのアクセス、さらに、インスタンスでWebサーバーを構築し、外部からインスタンスが提供するWebコンテンツを閲覧するまでの手順を述べます。物理的にはシンプルな構成ですが、マルチテナントによるセルフサービス提供を行うOpenStackクラウド基盤構築、運用の基本となりますので、以下の作成手順は必ずマスタするようにしてください。
テナントの作成
OpenStackは、クラウド基盤ソフトウェアであるため、マルチテナントによるネットワークサービスの提供が可能です。そのため、OpenStackで各種サービスを利用するには、まずは、テナントを作成する必要があります。テナントは、OpenStackのHorizonの管理GUIにおいて「プロジェクト」と呼ばれます。プロジェクト（テナント）を作成するため、「ユーザー管理」→「プロジェクト」をクリックします。
図3: プロジェクトの一覧
「プロジェクトの作成」をクリックしたら、ポップアップしたウィンドウ内の「名前」にテナント名を入力します。今回、テナント名は、「tenant0001」としました。
図4: プロジェクトの作成
「クォータ」タブをクリックし、tenant0001テナントに関するクォータ情報を入力します。このクォータは、tenant0001テナントで利用できる最大の仮想CPU数やインスタンス数（仮想マシンの数）、付与できる浮動IPアドレスの数などを指定します。浮動IPは、インスタンスに割り当て、クライアントからアクセスする際に利用します。今回は、仮想CPU数を4、インスタンス数を6、ボリュームとスナップショットの合計サイズを100GB、メモリ容量を32768MB、外部のクライアントからインスタンスにアクセスする際に、インスタンスに付与するFloating IP（浮動IP）の最大付与数を40に設定しました。このパラメーターは、作成したいテナントの規模やサービスモデルによって大きく異なります。
図5: OpenStackでプロジェクトのクォータ設定
パラメーターを入力したら、ウィンドウ右下の「プロジェクトの作成」をクリックします。すると、tenant0001プロジェクトが作成されていることがわかります。
図6: 図の説明：テナントtenant0001が作成された
作成したテナントのクォータ情報を再度編集することも可能です。
図7: OpenStackでプロジェクトのクォータを再編集
フレーバの作成
作成したテナント上では、複数の仮想マシンが「インスタンス」として稼働し、ユーザーにサービスを提供しますが、インスタンスが利用する仮想ハードウェア（仮想CPU数、メモリ容量、ディスク容量等）をあらかじめ定義しておく必要があります。OpenStackにおいては、このインスタンスの仮想CPU数、メモリ容量、ディスク容量などをひとまとめに定義したものを「フレーバ」と呼びます。OpenStackをインストールした直後には、あらかじめサンプルとなるフレーバがいくつか用意されています。現在登録されているサンプルのフレーバは、adminユーザーでログインした場合、HorizonのGUI画面の左の「管理」→「システム」→「フレーバ」をたどることで確認できます。
図8: フレーバのサンプル
標準で用意されているフレーバを使ってもよいのですが、ここでは、フレーバを新たに1つ作成してみます。まず、ウィンドウ右上にある「フレーバの作成」をクリックします。
図9: フレーバの作成
すると、フレーバのパラメーターを入力するウィンドウが表示されます。今回は、フレーバ名を「sales0001」、仮想CPU数を1、メモリ容量を1280MB、ルートディスクを8GB、スワップディスクを512MBにしました。パラメーターを入力したら、ウィンドウ右下にある「フレーバの作成」をクリックします。
図10: フレーバの作成直後
以上で、フレーバが作成できました。テナントに所属するユーザーがインスタンスを生成する際にフレーバを指定する必要がありますので、この段階でOpenStackの管理者がクラウド基盤でユーザー提供するフレーバを適切に作成しておく必要があります。
クラウド基盤におけるユーザー
OpenStackでは、adminアカウントと同様の管理者権限を持つユーザーや、管理者権限のない一般ユーザー（テナントに所属するクラウドの利用者）のアカウントを作成することができます。今回は、一般ユーザーの「koga」を作成します。このユーザーは、OpenStackクラウド基盤全体の管理者権限はありませんが、管理者（クラウド基盤提供側のadminアカウント）から用意されたテナント上に独自のソフトウェア定義型ネットワークやインスタンスを稼働させることができます。OpenStackにおける管理者権限のユーザーや一般ユーザーの概念をしっかりと理解してください。どのようなユーザーが登録されているかは、HorizonのGUI上で確認することができます。Horizonの管理GUIの左側から「ユーザー管理」→「ユーザー」をたどると、現在OpenStackに登録されているユーザーの一覧が表示されます。すでに標準で用意されているユーザーは、各種サービスを提供するために必要なシステム用のアカウントですので、削除してはいけません。
図11: ユーザーの一覧表示（図の説明：インストールしたコンポーネントによって表示されるユーザーが異なる）
ユーザーの作成
ユーザーを作成するには、Horizonの管理GUIの左側から「ユーザー管理」→「ユーザー」をたどり、ウィンドウの右上にある「ユーザー作成」をクリックします。
図12: 一般ユーザーkogaに関するパラメーターを入力
ユーザー作成のためのウィンドウが表示されますので、ユーザーkogaがHorizonにログインするためのパスワード、所属させたい主プロジェクト名（テナント名）を入力します。今回、ユーザーkogaは、先ほど作成したtenant0001テナントに所属させるとします。また、ユーザーkogaを管理者権限ではなく、一般ユーザー権限にしますので、ロールは「_member_」を選択します。このように、OpenStackでは、ユーザーの所属するテナント（プロジェクト）、ロールを厳密に管理する必要があります。一番下の「有効」にチェックをいれます。パラメーターを入力したら、ウィンドウ右下の「ユーザーの作成」をクリックします。ユーザー作成されるとユーザーの一覧に表示されます。パスワードの変更やユーザーの無効化設定、削除も可能です。
図13: 一般ユーザーkogaのパスワード変更、無効化、削除も可能
以上で、tenant0001に所属する一般ユーザーkogaの作成は完了です。一般ユーザーkogaを作成したらHorizonのGUIをログアウトします。ログアウトは、Horzionの画面右上の「admin」をクリックし、プルダウンで表示された「ログアウト」をクリックします。
図14: Horizonをログアウトする
glanceによるイメージファイルの登録
一般ユーザーkogaが作成できましたので、ここからは一般ユーザーでクラウド基盤を利用してみましょう。この一般ユーザーkogaにより、セルフサービスポータル画面でどのようなことができるかを理解するようにしてください。Horizonのログイン画面になったら、一般ユーザーkogaでHorizonのGUIにログインしてください。
ここでログインができない場合は、一般ユーザーの「主プロジェクト」が作成したテナントに所属しているかを再度確認してください。ユーザーkogaでログイン後に、「利用可能リソース概要」の円グラフには、管理者から付与されたテナントの各コンピュータ資源の最大値が表示されているはずです。
図15: ユーザーkogaでログインした直後は、所属テナントの利用可能リソースが表示されている
一般に、ユーザーのOS環境は、OpenStackが管理するコンピュートノードで稼働する仮想化基盤のゲストOSとして稼働させる必要があります。ユーザーに割り当てられて起動したゲストOSは、クラウド基盤において「インスタンス」と呼ばれます。インスタンスを作成するには、その元となるOSの雛型のイメージファイルを登録する必要があります。今回は、CentOS 7.2、Fedora 23、テスト用のミニOSであるCirrOSのイメージファイルを以下のURLから入手します。
CentOS 7.2のqcow2形式のイメージファイルの入手先URL：
http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2
Fedoraのqcow2形式のイメージファイルの入手先URL：
CirrOSのqcow2形式のイメージファイルの入手先URL：
http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
CentOS 7.2のqcow2形式のイメージファイルを編集する
OpenStack Mitakaにおいて、CentOS 7.2やCentOS 6.xをインスタンスとして起動する場合、FedoraやCirrOSでは不要とされる「ブートパラメーターの付与」が必要な場合があります。実行環境に依存しますが、CentOSのコミュニティが提供しているqcow2形式のイメージをそのままOpenStackのインスタンスとして起動すると、OSの起動途中において「trying to set up timer as Virtual Wire IRQ」というメッセージが表示され、OSのブートシーケンスが停止してしまう現象が報告されています。筆者のテスト環境でも同様の現象が再現されましたので、以下に回避策を示します。この不具合を回避するためには、インスタンスの起動時のブートパラメーターに「no_timer_check」を付与する必要があります。ブートパラメーターを追加するには、ブートパラメーターの設定を追加したGRUB2の設定ファイルをqcow2形式のイメージに埋め込みます。まず、CentOSのqcow2形式のイメージを保管しているCentOS 7.2のホスト上で、qcow2形式のイメージに含まれるファイルを編集するためのvirt-editコマンドをインストールします。virt-editコマンドは、libguestfs-toolsパッケージに含まれています。
# yum install -y libguestfs-tools
CentOSのコミュニティが提供するqcow2形式のイメージ「CentOS-7-x86_64-GenericCloud.qcow2」に含まれる/boot/grub2/grub.cfgファイルをvirt-editコマンドで編集します。このコマンドは、オプションにqcow2形式のイメージファイルと編集対象のファイルをフルパスで指定し、viエディタと同様の操作で当該ファイルを編集することができます。virt-editで指定する「CentOS-7-x86_64-GenericCloud.qcow2」のパスは問いませんが、今回は、/rootディレクトリに保管しているとします。
# virt-edit -a /root/CentOS-7-x86_64-GenericCloud.qcow2 /boot/grub2/grub.cfg ... linux16 /boot/vmlinuz-3.10.0-327.13.1.el7.x86_64 root=UUID=8a9d38ed-14e7-462a-be6c-e385d6b1906d ro console=tty0 console=ttyS0,115200n8 crashkernel=auto console=ttyS0,115200 LANG=en_US.UTF-8 no_timer_check ...
上記のように、linux16から始まる行に、カーネルイメージvmlinuzファイルと、「root=」でルートパーティションのUUIDが指定されており、その後にブートパラメーターが続いて記述されていますので、一番後ろに半角スペースを入れ、「no_timer_check」を追記します。ファイルを保存したらvirt-editによる編集作業は終了です。これで、OSのブートシーケンスが停止する問題を回避したCentOS 7.2のqcow2形式のイメージファイルが用意できました。
CentOS 6.xのqcow2形式のイメージファイルの場合は、/boot/grub/grub.confファイル内の、「kernel」行の最後に「no_timer_check」を追記します。===[/column]
# virt-edit -a /root/CentOS-6-x86_64-GenericCloud.qcow2 /boot/grub/grub.conf ... kernel /boot/ vmlinuz-2.6.32-573.22.1.el6.x86_64 ... KEYTABLE=us rd_NO_DM no_timer_check ...
イメージファイルをWebサーバーに保管する
イメージファイルは、OpenStack基盤とは別に用意したWebサーバーに保管し、HTTP経由でダウンロードできるように配置しておくとよいでしょう。qcow2形式のイメージファイルを保管したWebサーバーのIPアドレスは、172.16.31.8/16とします。Webサーバーのコマンドプロンプトを「websvr #」で表します
websvr # ip -4 a|grep inet
inet 127.0.0.1/8 scope host lo
inet 172.16.31.8/16 brd 172.16.255.255 scope global eth0
websvr # systemctl start httpd
websvr # systemctl status httpd
websvr # systemctl enable httpd
websvr # export http_proxy=http://proxy.yoursite.com:8080
websvr # export https_proxy=http://proxy.yoursite.com:8080
websvr # cd /var/www/html
websvr # wget http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2
websvr # wget https://download.fedoraproject.org/pub/fedora/linux/releases/
23/Cloud/x86_64/Images/Fedora-Cloud-Base-23-20151030.x86_64.qcow2
websvr # wget http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
次に、OpenStackのHorizonのGUI画面で、一般ユーザーkogaでWebサーバーに配置したイメージファイルを登録します。イメージファイルの登録は、HorizonのGUI画面の左側の「プロジェクト」→「コンピュート」→「イメージ」をクリックします。
図16: イメージ作成前の画面（図の説明：一般ユーザーkogaは、自分が所属するtenant0001テナント内で利用する仮想マシンのためのOSの雛型のイメージファイルを準備する必要がある）
上図から、現在、tenant0001テナントに登録されているイメージファイルはないことがわかります。イメージファイルを作成するため、ウィンドウ右上あたりにある「イメージの作成」をクリックします。すると、イメージ作成のためのウィンドウが出ますので、イメージファイルに関するパラメーターを入力します。今回は、例として、grub.confに「no_timer_check」のパラメーターを追記したCentOS 7.2のqcow2イメージファイルを登録します。イメージファイルの名前は「centos72」とします。このイメージに関する補足説明を文章で入力することも可能です。今回は、ブートパラメーターをgrub.confファイルに追記したことがわかる文章を入力しておきました。補足説明はなくてもかまいませんが、イメージファイルが増えた場合に、補足説明があると整理しやすくなりますので、記述しておくことをお勧めします。イメージファイルの場所は、先述のWebサーバーに配置したイメージファイルを指定します。今回は、別途用意したWebサーバー側で、以下のURLでクライアントにファイルを提供できるようにしておきましたので、上記URLを「イメージファイルの場所」に入力します。
http://172.16.31.8/CentOS-7-x86_64-GenericCloud.qcow2
Webサーバーが別途用意できない場合は、HorizonのGUI画面を操作しているクライアント上にイメージファイルを保管しておき、クライアントのブラウザ経由でイメージを登録することも可能です。形式は、「QCOW2」にします。CentOS 7の起動には、最低でも1GBのメモリが必要ですので、最小メモリは、1024MBにします。登録したイメージファイルを他のテナントに公開する場合は、「パブリック」にチェック「?」を入れますが、OpenStack Mitakaの標準設定では、一般ユーザーが「パブリック」に設定することはできません。イメージファイルを他のテナントにも公開する場合は、管理者権限を持つユーザーで操作する必要があります。
図17: イメージファイルのパラメーターを入力。Webサーバーが提供するイメージファイルのURLを指定する
入力が終わったら、ウィンドウ右下の「イメージの作成」をクリックすると、ユーザーkogaがtenant0001テナントで利用できるOSの雛型のイメージファイルが登録されます。イメージのファイルサイズにもよりますが、登録完了まで、しばらく時間がかかります。
図18: OSの雛形となるイメージファイルをOpenStackクラウド基盤に登録している様子。OSの雛形となるイメージファイルのサイズが大きい場合は、登録完了までにしばらく時間がかかる
CentOS 7.2のOSイメージファイルがOpenStackクラウド基盤に登録されると、ステータスが「稼働中」になります。これで、CentOS 7.2のOS環境をクラウドの利用者に提供できるようになりました。
図19: イメージファイルの登録が完了した様子。イメージファイルの登録が完了すると、「ステータス」が稼働中になる
Fedora 23、CirrOSについても同様に登録してみてください。インスタンス起動時の問題の切り分けのためにも、CentOS以外にFedoraやCirrOSなどの種類の異なるOSイメージを複数登録することをお勧めします。以上で、インスタンスの起動に利用されるOSイメージの登録が完了しました。
