VMwareユーザー向け

パブリッククラウドインスタンス

移行ガイド（OpenStack編）

著者： John S. Tonello SUSE、Global Technical Marketing Manager

www.suse.com SUSEガイド

p. 2

データセンターの進化 AWSまたは Azureアプリケーションの一部を、データセンターで立ち上げたばかりの OpenStackクラスターに戻すことが決まりました。しかし、あなたとあなたのチームは頭を抱えています。結局のところ、OpenStack は、VMware とはあまり似ておらず、パブリッククラウドとわずかな類似点があるだけなのです。

何から着手すればよいのでしょうか？

この SUSE ガイドでは、環境を安心して使用するためのシンプルな OpenStack 導入方法をご案内します。インフラストラクチャにまず焦点を当てて独自のアプリを導入する方法と、VMware のような典型的な VM 環境との違いについて理解するのに役立ちます。次に、アプリケーションの Software-Defined 実装を順を追って説明します。最終的に、オンプレミスクラウドの構築に関する理解を深め、重要なクラウドアプリケーションをインハウスに戻す取り組みを始めることができるようになります。

必要事項 このガイドを最大限に活用するには、OpenStack のデプロイメントにアクセスする必要があります。すでに自社のOpenStack が稼働していれば完璧です。まだの場合は、SUSE OpenStack Cloud の無料試用版を入手するか、コンテナ化された OpenStack プロジェクトである Kola-Ansible をインストールする、Windows、Mac、Linux 用に作成された

ダウンロード可能なトレーニングラボを利用する、OpenStack Public Cloud Passport でパブリックインスタンスを使用する、DevStackを使用するなどの方法があります。

スタックで、以下を有効にする必要があります。

• Nova (コンピュート)

• Neutron (ネットワーキング)

• Glance (イメージ)

• Heat (スタック構築用)

• Horizon (ダッシュボード)

Cinder ブロックストレージは、この例では厳密には必要ではありませんが、このサンプルプロジェクトを超える規模に拡張する際に有用です。

コマンドラインを使用する場合は、openstack-heat または python-heatclient をインストールする必要があります。これは、“stack create”コマンドは、openstack コマンドの機能ではないためです。インストールのコマンド(pip)は次のとおりです。

$ sudo pip install python-heatclient

ハイパーバイザーを凌駕 VMware に慣れ親しんでいる場合は、基本的なサーバー仮想化の枠を超えて考えることが重要です。VMware と Hyper-V

は、仮想マシンの大規模な展開を容易にするハイパーバイザーを提供します。展開において非常に優れており、KVM やXen よりも堅牢なツールを提供していますが、パブリッククラウドや OpenStack は、VM のハイパーバイザーをはるかに超えたものを提供します。

p. 3

たとえば、VMware クラスター内の特定の ESXi ホストに特定の VM または VM のグループを配置する代わりに、OpenStack は、すべての物理ホストからのリソースをプールし、ハードウェア、ネットワーク、ストレージを抽象化します。また、以前に割り当てられたリソースに基づいて各インスタンスをどこに配置するかを決定し、クラスター内で利用可能なリソースに基づいて CPU、RAM、およびネットワークリソースを割り当てます。以前に構築した VM から導出された VM テンプレートに依存する代わりに、OpenStack は、コードを使用して各インスタンスのコンポーネントを定義するため、コンポーネントの一貫した迅速な起動と複製が可能です。

これは、AWS や Azure (または任意のクラウドプロバイダー)で VM およびアプリケーションの迅速な導入を可能にする方法と非常によく似ています。OS と、インスタンスのフレーバーおよびサイズを選択すれば、すぐにサーバーを使用できます。ネットワークとストレージを含む、基盤となるインフラストラクチャは抽象化されています。

このように、OpenStack インスタンスは、慣れ親しんでいる VMware VM よりも短期的なものです。もちろん、OpenStack インスタンスは、変更したり、必要な長さだけ保持できるだけでなく、簡単なコマンドまたはテキストファイルを使用して、自由に再作成することもできます。イメージ、インスタンスのフレーバー、ネットワーキング、スト

レージなど、主要な構成要素を維持している限り、新しいインスタンスを自由に生成できます。

これは、VMware と対照的です。VMware では、リソースは、vSphere でノードとして識別される特定の各ホストを最終的に配置する VM 間で共有されます。VMware のパラダイムでは、VM とそのリソースは一般に、特定のノードに従い

ます。

図 1.この VMware vSphere の例では、リージョン別に編成された ESXi ノードが VMware クラスターを構成しています。

p. 4

OpenStack では、各ベアメタルサーバー(ノード)のリソースがプールされ、インスタンスがこれら

のリソースを共有します。これらのリソースは、Nova Compute サービスによって管理されます。

Nova は、トラッキングしたリソースを使用して新しい仮想マシン(OpenStack では、インスタンス

と呼ばれます)を生成します。

図 2.OpenStack のこの例では、個々のホストのリソースがプールされ、抽象化されています。

インスタンスの基本 新しいインスタンスを作成するには、まず構成要素を配置する必要があります。これらは通常、ネットワーク、ストレージ、CPU、RAMを決定するときに OpenStack本体とともに導入されます。基本的に必要なものは、次のとおりです。

• ブートするイメージ – 通常、Linuxベースのイメージで、多くの場合、qcow2形式です。目的に応じて、イメージは、ベアボーンで非常に小さい場合もあれば、カスタマイズされていてかなり大きい場合もあります。新しいOS ファイルをアップロードするだけで、新しいイメージをいつでも追加できます。新しい OS ファイルは、一般的に、任意の Linux ディストリビューションの小さな事前構築済み VM で、さまざまな形式があります。OpenStack Glanceサービスは、追加したすべてのイメージをトラッキングします。後で試す例では、Fedoraのイメージを使用しています。このイメージは

https://download.fedoraproject.org/pub/fedora/linux/releases/29/Cloud/x86_64/images/Fedora-Cloud-Base-29-

1.2.x86_64.qcow2からダウンロードできます。選択肢となる OpenStackパブリックイメージは多数あります。

p. 5

図 3.イメージにより、OpenStackインスタンスのベース OSが提供されます。

• フレーバー – OpenStack では、パブリッククラウドと同様に、インスタンスは m1.tiny, m1.small, m1.medium などのフレーバーで提供されます。任意のサイズをユーザーが定義できます。各フレーバーには、一定量の CPU、RAM、ディスクなどの要件があるため、m1.small を選択するときは、2GB の RAM、1 個のCPU、20GBのディスクを持つインスタンスを作成しようとしていることになります。

• ネットワーク – OpenStack を初めて導入するときは通常、OpenStack クラスター内のトラフィックに使用されるプライベートネットワークを追加します(10.0.0.0/24 など)。これにより、インスタンス同士は通信できますが、外部とは通信できません。外部からインスタンスにアクセスするためのフローティング IP アドレスを取得するための外部ネットワークを追加するのが一般的です。OpenStack は通常、さまざまなサブネットのフリーIP アドレスをインスタンスに自動的に割り当て、それらのアドレスをすべてトラッキングします。仮想ルーターは、ネットワーク間のトラフィックを管理します。

これは VMwareや KVMと対照的です。VMを起動するときは通常、割り当てる IPアドレスとホスト名を事前に決定する必要があります。OpenStackは、プールからこれらを自動的に取得します。

図 4.2 つのネットワークによるシンプルなトポロジ。ここでは、demo-net は OpenStack の内部にあり、public1 は外部接続を提供し、demo-routerはそれらを接続しています。

p. 6

• キーペア – スタンドアロン VM とは異なり、ユーザーは通常、OpenStack インスタンスにユーザー名とパス

ワードでログインしません。代わりに、共有鍵を使用します。OpenStack では、ユーザー用の鍵(プライベートな情報を含む鍵をダウンロードして安全に保管する必要がある)を生成することも、~/.ssh/id_rsa.pub など既存の公開鍵をアップロードすることもできます。これらの鍵は、任意の Linux システムで ssh-keygen コマンドを使用して作成する共有鍵のタイプと同一です。これらのキーを使用して、次のように任意のインスタンスにログインします。

$ ssh -i ~/.ssh/id_rsa centos@10.0.0.5

イメージのフレーバーに応じて、「centos」、「opensuse」、「ubuntu」のようなログインユーザー名を使用します。

• セキュリティグループ - ほとんどのバージョンの OpenStack (Rocky を含む)では、デフォルトのセキュリティグループが作成され、これによりインスタンスへのネットワークトラフィックのアクセスが許可されます。たとえば、ssh 用のポート 22 は通常有効化されています。インスタンスとセキュリティグループを関連付けて、

セキュリティグループのネットワークルールを設定しないと、インスタンスのすべてのネットワークポートがすべての受信および送信ネットワークトラフィックに対して閉じられます。つまり、このグループとは通信できません。これはあまり便利とは言えません。

図 5.セキュリティグループに、基本的な入力および出力のルールのセットが含まれており、これを任意のインスタンスに適用できます。

これらの手順を VMwareまたは KVMでの VMの作成と比較します。VMwareや KVMでは、必要な OSの.isoを提供し、コンピューティングリソースを設定して、ネットワークインターフェイスを選択し、結果の VMを保存する場所を選択して、その OS を起動して設定する必要があります。VMware の場合は、その新しい VM を実行するクラスター内のノードを選択します。KVM では、ストレージパスを選択します。リソースを事前に提供することで、OpenStack はこれらの

意思決定のほとんどを抽象化(プリロード)し、各 OS イメージを事前設定してすぐに実行できます。アプリケーションを導入する前に、事前起動やプロビジョニングを行う必要はありません。

p. 7

アプリケーションのデプロイ たとえば SUSE Linux Enterprise Server、openSUSE、CentOS や、他の任意の Linux オペレーティングシステム仮想マシンなど、通常の VM と同様にインスタンスを作成して起動できます。OpenStack がインスタンスを生成するとすぐに、インスタンスは稼働し、RAW システムとしてアクセスできます。使用可能なリソースに応じて、1 つから数百のインスタンスを作成できます。

図 6.OpenStackの Horizonダッシュボードから、1つ以上のインスタンスを作成し、VMのように扱えます。

しかし、OpenStack の長所の 1 つは、実行場所の仮想マシンだけでなく、アプリケーション全体に関連する作成ステップをスクリプト化できることです。たとえば、CentOS インスタンスを起動してから Apache、MariaDB、PHP、WordPressをインストールする代わりに、Heatスクリプトを使用してスタック全体を一度に定義できます。

スタックのデプロイ OpenStack が Heat スクリプトを説明するために使用している例の 1 つに、Web サイトコンテンツ管理システムであるWordPress の単純なデプロイメントがあります。Heat スクリプトの基礎となる YAML を見てみましょう。スタック作成の仕組みをよりよく理解できます。

WordPressのデプロイ

この OpenStackの例では、Fedoraクラウドイメージを使用しています。MariaDBのインストール、My SQLの root資格情報の設定、「wordpress」データベースの作成、WordPress および資格情報のインストール、httpd.service の起動、

デフォルトの内部ネットワークからの IP アドレスの割り当てを行っています。すべて、わずか数分で完了します。これはスタック全体の自動化と考えることができます。スクリプトは、「server」とそこで実行されるすべてのものをデプロイします。

デプロイが完了したら、http://internal-ip-address/wordpress で WordPress を起動して設定するか、フローティング IP アドレスを関連付けて外部ネットワーク http://public-ip-address/wordpress/からアクセスできます。最初からやり直す場合は、スクリプトを再実行するだけです。

完全なスクリプトは、次の場所から入手できます。

http://git.openstack.org/cgit/openstack/heat-templates/plain/hot/F20/WordPress_Native.yaml

p. 8

詳しく見てみましょう。

この YAML ファイルでは、「wordpress」というインスタンスとその必要なすべての可動部分を定義します。インスタンス(基盤となる「server」)と MariaDBを設定するコマンドを定義するリソースセクションがあります。

resources:

wordpress_instance:

type: OS::Nova::Server

properties:

image: { get_param: image_id }

flavor: { get_param: instance_type }

key_name: { get_param: key_name }

user_data:

str_replace:

template: |

#!/bin/bash -v

yum -y install mariadb mariadb-server httpd wordpress

touch /var/log/mariadb/mariadb.log

chown mysql.mysql /var/log/mariadb/mariadb.log

systemctl start mariadb.service

# Setup MySQL root password and create a user

mysqladmin -u root password db_rootpassword

cat << EOF | mysql -u root --password=db_rootpassword

CREATE DATABASE db_name;

GRANT ALL PRIVILEGES ON db_name.* TO "db_user"@"localhost"

IDENTIFIED BY "db_password";

FLUSH PRIVILEGES;

EXIT

EOF

sed -i "/Deny from All/d" /etc/httpd/conf.d/wordpress.conf

sed -i "s/Require local/Require all granted/" /etc/httpd/conf.d/wordpress.conf

sed -i s/database_name_here/db_name/ /etc/wordpress/wp-config.php

sed -i s/username_here/db_user/ /etc/wordpress/wp-config.php

sed -i s/password_here/db_password/ /etc/wordpress/wp-config.php

systemctl start httpd.service

params:

db_rootpassword: { get_param: db_root_password }

db_name: { get_param: db_name }

db_user: { get_param: db_username }

db_password: { get_param: db_password }

Heat スクリプトのこのセクションには、多数の yum コマンド、カスタム値をデータベースや WordPress 設定ファイルに配置する一部の sed コマンド、およびその他のコマンドが含まれています。これらのカスタマイズは、環境ファイルにパラメーターとして入力するか、または手動で入力します。

この YAML ファイルを使用して Horizon ダッシュボードで新しいスタックを起動すると、key_name、instance_type、image_id、db_name、および OpenStack にスタックの構築方法を伝えるその他の要素など、パラメーターセクションで概説されているすべての項目を追加するように要求されます。

p. 9

Horizonダッシュボードから、［Project］ -> ［Orchestration］ -> ［Stacks］の下の［+ Launch Stack］をクリックし、テンプレートソースを「URL」に設定して、WordPress_Native.yaml ファイルに上記の URL を入力することで、このスタックを作成できます。今回は環境ソースファイルをスキップして、［Next］を選択します。

図 7.Horizonダッシュボードと Heatスクリプト(URLから利用可能)を使用してスタックを起動します。

OpenStack はリモート YAML ファイルをダウンロードし、Heat スクリプトで参照されているパラメーターを事前入力します。スタック名、Fedora イメージに付けた名前(上記の例では fedora)、ssh キーペアの名前を追加します。この例では、すべてのデータベースユーザー名とパスワードが「admin」に事前に設定されています。［Launch］をクリックしてデプロイします。

p. 10

図 8.OpenStack環境に合わせて各種パラメーターを入力します。

openSUSE や Ubuntu など、別の OS イメージで同じ Heat スクリプトを試したい場合は、ファイルのコピーをダウン

ロードして編集する必要があります。たとえば、Fedoraは、MariaDBのインストールに yum パッケージマネージャーを使用します。openSUSE を使用する場合は、zypper コマンドを使用するためにこれらの部分を更新する必要があります。Ubuntuの場合は、apt を使用するように変更します。

Horizon の使用に加えて、コマンドラインを使用してスタックを構築できます。同じスクリプトを使用して、python-

heat をインストールします。スタック作成プロセスを実行する権限を自分に付与するには、OpenRC ファイルに対するsourceも実行する必要があります。

OpenStack から独自の openrc ファイルを入手できます。Horizon コンソールの右上にあるユーザー名をクリックします。

図 9.OpenStackダッシュボードから独自の openrcファイルをダウンロードします。

p. 11

ダウンロードが完了したら、それをソースとして指定し、プロンプトが表示されたら OpenStack パスワードを入力します。管理者アカウントを使用している場合、openrcファイルは管理者の資格情報を使用します。

$ source username-openrc.sh

これで、各パラメーターの--parameter フラグを使用して Heat スクリプトを実行し、名前を指定できます(ここでは「teststack」と表示されています)。

$ openstack stack create -t http://git.openstack.org/cgit/openstack/heat-

templates/plain/hot/F20/WordPress_Native.yaml \

--parameter key_name=kingdel \

--parameter image_id=fedora \

--parameter instance_type=m1.small \

teststack

デプロイすると、スタックのさまざまな情報を表示できます。

図 10.デプロイされたアプリケーションインスタンスの詳細。この場合は、WordPressが m1.small で実行されています。

p. 12

まとめ 他のソフトウェアディファインドインフラストラクチャと同様に、OpenStack では、アプリケーションの構築に必要なリソースと、その稼働基盤となる仮想マシンを抽象化します。まず、ストレージ、CPU、RAM、サブネット全体のプールから開始します。このプールから、OpenStack はリソースと IP アドレスを自律的に取得して割り当てることができます。その結果、パブリッククラウドの俊敏性、VMware 単独よりも高い柔軟性と自動化、ユーザーとチームの時間とコストを節約する機能を提供するクラウドインフラストラクチャが実現します。

SUSE OpenStack Cloud により、運用の俊敏性、スピード、スケーラビリティ、および管理性を備えたプライベートクラウドインフラストラクチャを構築し、新たなビジネスチャンスと DevOps やコンテナなど急速に進化するテクノロジーを最大限に活用することが可能になります。業界で最も広範なオープンソースコミュニティのサポートに支えられており、DevOps 環境への対応や従来のデータセンターを変革するための新しい画期的なワークロードの開発に最適です。

将来にわたって投資を保護する、信頼できる機能豊富なプライベートクラウドを提供します。

詳細については、https://www.suse.com/products/suse-openstack-cloud/をご覧ください。