ubuntu juju/maas・openstackを使った検証環境構築 - openstack最新情報セミナー...

COPYRIGHT © 2016 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED 1 COPYRIGHT © 2014 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED COPYRIGHT © 2015 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED

OpenStack 最新情報セミナー

2016-03-02

三菱電機インフォメーションシステムズ

吉川晃平

ご注意

• 本書の内容の一部又は全部を当社に断りなく、いかなる形でも転載又は複製することは、固くお断りします。

• 本文記載の社名、製品名、ロゴは各社の商標または登録商標です。

• OpenStack® のワードマークと OpenStack のロゴは、米国とその他の国における OpenStack Foundation の登録商標/サービスマークまたは商標/サービスマークのいずれかであり、OpenStack Foundation の許諾の下に使用されています。

COPYRIGHT © 2016 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED 2

自己紹介

吉川晃平

(よしかわこうへい) 発表者 • twitter @yosikawako

• 住処：神奈川県藤沢市

• 趣味：スキー

• 好きな食べ物：

ラーメンパスタから肉チーズに改宗

インフラ系

システムエンジニア経歴 • 海底ケーブルの監視GUI

• ISPのホームページ公開システム

• オンプレミスのWebポータル共通基盤

• OpenStack: 勉強中


MDIS 会社概要

三菱電機(株)

の情報システム

事業が分社化

し発足


拠点

鎌倉市(大船

駅)を技術拠点

に本社・支社を

全国配置


主な事業

高い技術力と豊かな発想で、社会に密着した多彩なソリューションを提供


MDISのOSS活用ソリューション

通信キャリア・サービスプロバイダー様向け、OSSを活用したシステムの導入支援。 http://www.mdis.co.jp/solution/oss/

COPYRIGHT © 2016 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED 7 7 COPYRIGHT © 2015 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED

7

発表の概要


本日の内容

Canonical社が開発するサービスオーケストレーター「Juju」、

物理マシン構築ツール「MAAS」の紹介

事例１：社内にOpenStack®の講習やPoCを行うための環境を

つくる

事例２：Juju/MAASを使ったOpenStack環境の構築と運用

例

事例３：Juju環境をOpenStack上に構築し、

WebサービスをJuju on OpenStackで構築・管理


話題とする共用検証環境の概要

Over

Cloud

Under

Cloud

すべてのリソース

OpenStack

OpenStack B1 検証C

(OpenStackを使わない検証)

環境A(メイン) 環境B(構築検証) 環境C

OpenStack B2

OpenStack B3

OpenStack B4

MAAS

Juju(under)

テナントA1 テナントA2 Juju用テナント

検証A1 検証A2 Juju(tenant)

低レベルでの環境分離とアクセス経路提供

Jujuを使った検証

②Juju/MAAS を使った

OpenStack 構築

③OpenStack上の Juju利用

①OpenStack 構築講習

のための環境構築


謝辞

本発表中の環境構築・検証には

日本仮想化技術株式会社様からの

多大なる技術支援・サポートをいただきました。

また、Ubuntu製品群に関する発表をすることを

Canonical様より快くご承諾いただきました。

感謝の意を表します。

発表内容はすべて弊社(MDIS)が独自に実施した構築・検証に基づくMDISの見解です。


11


Canonicalのクラウドソリューション

汎用的な複数のソフトウェアの連携で

柔軟なクラウド・データセンター管理運用を実現

有償サポート(Ubuntu Advantage)に含まれる

Juju

• サービスのモ

デリングとデ

プロイ

• OSS

MAAS

• 物理マシン

のプロビジョ

ニング

• OSS

OpenStack

• クラウド基盤

• OSS

LandScape

• 運用管理

• 運用サービ

ス


Jujuとは？

迅速に「モデリング(*)」「設定」「デプロイ」「管理」をクラウド環境へ実現するサービスオーケストレーションツール画像出典：http://www.ubuntu.com/cloud/juju

(*) Model:公式ページではModelを「サービスの構成設計」のような用語として使っている。

http://www.ubuntu.com/cloud/juju


Jujuでできること

検証済み手順の再

利用(Charm

Store)

サービスの迅速なデ

プロイ

スケールアウト/ダウ

ンサービスの多量展開

クラウド

AWS AZURE OpenStack

オンプレミス

物理サーバー KVM 仮想マシン VMWareESXi 仮想マ

シン

CharmStore Charm Service

Unit

Unit

Service

Unit

Unit Charm

Node

Node

Node

get deploy


MAASとは

データセンター

運用効率化

目的物理サーバー

の自動化

役割

「データセンター運用効率化のための物理サーバーの自動化ツール」


MAASでできること

マシン探索と

インベントリ化電源On/Off

HDDイメージ

をデプロイ

タグ付けによる

グルーピング

物理サーバー KVM 仮想マシン VMWareESXi 仮想マシン

Manager (ex.Juju)

discover nodes

Physical Server

KVM VM

ESXi VM deploy power

Node

Node

Node

list deploy power

MAAS

Node Inventory

HDD image


Juju/MAASが威力を発揮する用途

https://jujucharms.com/openstack

OpenStack

https://jujucharms.com/big-data

BigData

テナントを効率的にデプロイ

CMSやWebサービスのバックエンド

OpenStackだけでなくデータセンター・クラウドサービス運用の効率化を目指している

多量のノード生成が必要なシステム。

よく似たサービスを何度もデプロイするような環境


18

Jujuのしくみ


サービス、ユニット、ノード

Jujuの構成単位の概念。抽象化されているので理解が必要。

サービス(Servie)

• Charmで定義される機能単位。

• JujuGUI上のアイコン=サービス

• サービスにユニットが登録されて初めて実際

のデプロイがはじまる。

• オブジェクト指向言語の「クラス」に近い

ユニット(Unit)

• サービスの実体。1つ以上の複数のユニット

で１つのサービスを構成する。

• 実装はノードそのものまたはノード内のLXC

コンテナ。ユニットをノードにデプロイすると

LXCコンテナが生成され、中でCharmに

記載されたサービス生成がはじまる。

• オブジェクト指向言語の「インスタンス」に近

い。

ノード(Node)/Machine

• サービスのデプロイ先となるサーバーの実体。

(仮想・物理は意識しない)

• 1ノード内に複数のユニットをコンテナとして

格納可能

• MAASの管理する「ノード」やOpenStack

の「インスタンス」と対応する。

• どのノードを利用するかはJujuが自動に決

める。（制約条件で特定のグループを指

定することは可能）

CharmStore Charm Service

Unit

Unit

Service

Unit

Unit Charm

Node

Node

Node

get deploy


サービスのデプロイ

新しいサービス"apache"をJuju上にデプロイするときの動作

$ juju deploy-service apache

１．CharmStoreのリポジトリからチャーム"apache"をダウンロードする

⇒Jujuにサービス"apache"が登録される

２．JujuがMAASに空きノードを問い合わせる

⇒MAASがjujuへ空きサーバーのノードid "1" を応答

３．JujuがMAASへノード"1"へのOSイメージのデプロイを指示

⇒ノード"1"のOSが起動する

４．Jujuがノード"1"へlxcコンテナを作り、その中でapacheのサービス

を有効化する

投入コマンドはこの１つだけ

あとでデモします


サービス間のリレーション構築

$ juju add-relation (サービス名1) (サービス名2)

例：novaとkeystoneを関連づける

$ juju add-relation nova-compute keystone


Charmをつなぐ線がリレーションを表す

あとでデモします


複数Unitで構成されるサービス

あとで詳しく説明します


スケールアウト・スケールダウン

• スケールアウト: $ juju add-unit [-n 追加Unit数] (サービス名)

• スケールダウン: $ juju remove-unit (Unit名)

◆例：nova-compute用サーバーを3台追加

$ juju add-unit -n 3 nova-compute

JujuがMAASに"compute"タグのついた空きノード

を問い合わせる

JujuがMAASへOSイメージのデプロイを指示

JujuがノードへCharmを動かしnova-computeの

サービスを生成・有効化する


あとで詳しく説明します

自動


Juju GUI 2.0

2016-01-25にJuju GUI 2.0リリース。デザインが大幅に変更

https://insights.ubuntu.com/2016/01/25/released-juju-gui-2-0/

# juju本体(Juju core)ではなく、GUIインターフェースのみ

Juju GUI 1.x

Juju GUI 2.0


25

MAASのしくみ


MAASとは？

Manager (ex.Juju)

discover nodes

KVM VM

ESXi VM

deploy power

Physical Server Node

Node

Node

list deploy power

MAAS

Node Inventory

HDD image



KVM VM Node

ESXi VM Node

CLI

GUI


MAAS GUI

GUIによる物理ノードの一元管理

物理マシン

仮想マシン


MAASのマシン登録シーケンス

参考:http://www.slideshare.net/VirtualTech-JP/openstack-45205975

User MAAS Machine

Ship,Power-on

PXE-boot

DHCP, Boot image

Power-on

PXE-boot

DHCP, Boot image

Discover H/W information

Discover power information

Power-off

Power-off

enlisting

commisioning

State:new

State:ready

Edit power type,tag,hostname etc…

inventory

MAAS GUIにマシーンが現れる

デプロイ等に利用可能な状態

iLo,iDRAC,ESXi,virsh等へMAASが指示を出す


MAAS Ver1.9の新機能

MAAS1.9ではストレージやネットワーク周りの高度な設定を管理ノードへ行えるようになった。（以下はリリースノート(http://maas.ubuntu.com/docs/changelog.html)より）

ストレージ

• LVM, Partitionのサポート

• LVM,RAID0,1,5,6設定ＵＩのサポート

• Partitioning, Bcache(LinuxのSSDキャッシュ機構) UIのサポート

ネットワーク

• ノードのネットワーク設定をサポート(以下)。

• Subnets

• fabrics

• VLAN interfaces

• bond interfaces

• interface names

• VLAN,bonding,Alias,Interface nameの設定サポート

• Subnetworrkを拡張し新たな設定をサポート。

Fabrics,Spaces,VLANs in fabrics,Subnets inSpaces

• Network設定UIのサポート


30

デモシナリオ:MAASによるマシン自動探索と登録


デモ MAASによるマシン自動探索と登録

新しいマシンを作り結線と電源投入するとMAASインベントリに登録される

ＫＶＭ管理コンソールから、KVMマシンを作る。

•インストールメディアの場所：PXE,OSの種類=Linux,バージョン=Ubuntu14.04LTS

•CPU=1core,mem=2GB,HDD=20G

「インストール前に設定をカスタマイズ」にチェック

•「NIC→ソースデバイス」を「VMNETxx(br0)」に指定

•boot順をPXE,HDDに変更して「適用」

生成開始後、KVM管理コンソールを開きMAASの様子を確認する。

•起動後GUIのNodeにマシンが追加される(Commisioning -> Power Off -> new)を確認

MAAS GUI上でインベントリのマシン設定を編集する。

•Power>Power type:Virsh (virtual systems)

•Power address: qemu+ssh://(user)@(IP)/system , Power ID: KVMマシン名(nodevmN)

MAASがHW情報を収集しインベントリに表示するのを確認。

•Ready状態になる

•[Option] ホスト名=nodevmN,tag=kvm,nodevm

今回はkvmだが、物理マシン、

VMWareもほぼ同様

MAASが適当にIPとマシン名をつけている


VIDEOデモ：MAASによる自動探索


33


共用検証環境の概要

Over

Cloud

Under

Cloud


OpenStack




OpenStack B2

OpenStack B3

OpenStack B4

MAAS

Juju(under)






OpenStack 構築





これからお話するところ＝①

Over

Cloud

Under

Cloud


OpenStack




OpenStack B2

OpenStack B3

OpenStack B4

MAAS

Juju(under)






OpenStack 構築





環境上の位置づけ

Over

Cloud

Under

Cloud


環境(講習用)

低レベルでの環境分離とアクセス経路提供ココ


37

検証環境を作るための課題


解決したい課題

複数のPoCを干渉なく実施させるネットワーク構成 ① 講習会場や自学先からセキュアにアクセスできるようにしたい

② ネットワーク的に複数のOpenStackを作ったり壊したりしたい

弊社内講習会場弊社検証機器講師

受講者

VPN

弊社


Compute Node

PoCテナントあたりの環境

Public network (Floating IP割当)

Controler

Node

Network

Node

em1 em1 em1

em2 em2 em2

default GW

受講者 VPN

OpenStack 管理用Network

テナント内Net (OvS)

Instance

Instance

Instance

em1

em2

※OpenStack Installation Guide for Ubuntu 14.04 kiloベース ( http://docs.openstack.org/kilo/install-guide/install/apt/content/index.html )

em1

em2

em1

em2


例:ハンズオンを開くとなると

default GW

受講者 VPN

グループ ① グループ ②

グループ ③ グループ ④

グループ ⑤ グループ ⑥

グループ ⑦ グループ ⑧


例:ハンズオンをひらくとなると・・・

1受講グループあたり

① [Controller node] (KVMでglance,nova,horizon,cinder,MQ,RDB格納)

② [Network node] (neutron)

③ [Compute node] (nova-compute )

×８グループ=２４サーバー必要！

※OpenStack Installation Guide for Ubuntu 14.04 kiloベース ( http://docs.openstack.org/kilo/install-guide/install/apt/content/index.html )


リソースたりない

• ハンズオンを開くにはサーバー台数が全く足りない

– （物理サーバー数台）

• 固定IPが1つしかない


43

トライしたこと

(解決策)


トライしたこと

① VMWare vSphere®でネストさせた仮想環境に講習環境を詰め込んだ

② 講習会場-機器間にVPN経路を引いた


トライしたこと①仮想環境のネスト

• 検証に必要なサーバーをVMWare ESXi™上の仮想マシンで提供(KVM on ESXi)

• シンプロビジョニング、オーバーコミットしまくり

• 当然スワップまみれ。性能は考慮しない。

物理サーバ数台+物理SW

VMWare ESXi 、仮想SW (tagged VLAN)

受講グループ1

仮想マシン 1

Controller node

KVM

nova

KVM

glanc

e

KVM

horiz

on

KVM

maria

DB

KVM

rabbit

MQ

KVM

swift

KVM

cinde

r

仮想マ

シン 2

Network

node

neutr

on

仮想マシン 3

Compute

node

KVM

insta

nce 1

KVM

insta

nce N

×８

仮想マ

シン x 3

node

x 3

vCente

r

Server VMWare

で用意

受講者が

作る


トライしたこと②会場から環境へのアクセス

• 検証環境内からは(VPNを介さず)インターネット疎通可能に

• 外部から検証環境へはVPN経由のみ許可

① 国外からのアクセス拒否

② ID/Password認証

③ SSL-VPN

④ ユーザーグループ毎に専用のネットワークスペース

VPNで許可

サーバー環境

外部サイト (リポジトリ

等)

許可

拒否

講習会場


47

で、つくってみた

（構成）


ネットワークスタック

物理配線 (Ethernet)

VLAN (L2SW, VMWare仮想スイッチ)

GREトンネル

[Open vSwitch]

仮想ブリッジ

Tenant

Private

Tenant

Floting

OpenStack

(Kilo)

nodes

vCenter

Server VPN GW

Internet

GW RIP

Internet

◆Global IPが1個しかない。 ⇒がんばってやりくりするしか


受講者へ提供するネットワーク


VLAN(L2SW, VMWare仮想スイッチ)

GREトンネル

[Open vSwitch]

仮想ブリッジ

Tenant

Private

Tenant

Floting

OpenStack

nodes

vCenter

Server VPN GW

Internet

GW

受講者へ提供する環境 [仮想マシンx3,サブネットx2 ]/受講者 × 8 グループ

RIP Internet

OpenStack 構築に専念！！

受講者x8grp


環境へのアクセス経路



GREトンネル

[Open vSwitch]

仮想ブリッジ

Tenant

Private

Tenant

Floting

OpenStack

nodes

vCenter

Server VPN GW

Internet

GW

NAPT

VPN確立 IP・経路リース

NAT RIP

Floating IP

Internet

ログイン時のユーザーIDに応じて接続先VLANを選択

受講者のネットワークアドレスは重複してもよいようにルーティングテーブル分割

受講者x8grp

テキストどおりの IPアドレス！

Tenant 1

Tenant 2

Tenant 3

Tenant 8

・・・


テナント内からインターネットへの経路



GREトンネル

[Open vSwitch]

仮想ブリッジ

Tenant

Private

Tenant

Floting

OpenStack

nodes

vCenter

Server VPN GW

Internet

GW

NAPT

SNAT + Route Domain

SNAT

RIP

Floating IP

Internet

テナント内からInternetへはVPNを経由させず直接アクセスさせる。

テナント内サーバーからはdefaultGWにアクセスしてるだけにみせる。

受講者

apt-get叩けないと講習にならないからね


ルーティングテーブルの分割

• Route Domainという仕組みを使い、受講グループ毎にルーティングテーブルを分割しました。 ①受講グループ向け

GWの設定 ②受講グループ・

Internet間のSNAT

グループ11 ID=1111 グループ10 ID=1110

重複するアドレスを Route Domain idで区別する

重複するネットワークから1つのグローバルIPへSNATさせる


下回り完成

Over

Cloud

Under

Cloud


環境(講習用)

低レベルでの環境分離とVPNアクセス経路提供

OpenStack B1 OpenStack B2

OpenStack B3 OpenStack B4

独立したルートテーブル




ココ


54


これからお話するところ＝②

Over

Cloud

Under

Cloud


OpenStack




OpenStack B2

OpenStack B3

OpenStack B4

MAAS

Juju(under)






OpenStack 構築





環境上の位置づけ

Over

Cloud

Under

Cloud


OpenStack

環境A(メイン)

MAAS

Juju(MAAS用)


API

ココ


OpenStack構築手順

詳しい手順は日本仮想化技術様公開資料

「Ubuntu Juju/MAASを使用した OpenStack構築手順書」 http://enterprisecloud.jp/installguide-juju-openstack/

をご参照ください


Juju/MAASを用いた OpenStack構築

Jujuを用いたOpenStack構築手順はすでに発表事例がいくつかありますので・・・要所だけ。

構築の流れとトラブルシュート

構築後のComputeノード追加

Jujuで作ったOpenStack設定の変更


OpenStack構築の流れ

サービスデプロイまでは設定・手順必要。その後のノード追加・削除はほぼ全自動

１．MAASサーバーの構築

２．Jujuサーバーの構築とMAAS連携設定

３．OpenStack用物理マシン・仮想マシンの

設置・配線

４．JujuへOpenStackサービス群をデプロイ

サービス設定が終わるまではそれなりにハマ

る

MAAS：HWリブート・イメージデプロイを繰り返すので時間かかる Juju:MAAS連携で手こずる。サービスまでくみあがれば、あとはラク

• サービス間のリレーション設定 • neutronネットワーク設定


Juju/MAASトラブルシュート

Jujuからのサービスデプロイに失敗するパターン

パターン１：Jujuに指示してもMAASのDeployがはじまらない

パターン２：MAASのデプロイが終わってもJujuがunitのデプロイをはじめない

パターン３：Juju,MAASへのオーダー投入が多すぎて失敗する

原因は

「juju-core,juju-bootstrap,maasの3サーバー間のタイミングプロブレム（どこかで通信がタイムアウト）」

または

「juju-core,juju-bootstrap,maasのどこかに過去の失敗したインベントリの残骸が残っている」ケースが多い（経験則）


Juju/MAASトラブルシュート

対応策

1. "juju status"コマンドでデプロイの残骸を探しあれば削除する。

1. unit: juju remove-unit (unit名)

2. service: juju remove-service (service名)

3. node: juju remove-machine (node番号) --force

(nodeのlifeがdeadになることを確認する）

2. MAAS GUIでjujuから消したNodeをReleaseし、Ready状態へ戻す。

3. 各マシンの時刻がずれている場合はntpを設定し同期させる。

4. juju-core,juju-bootstrap,maasをリブートする。

5. 上記後、再度デプロイを実施する。


インスタンスのコンソールを表示するJuju設定

juju-coreで以下を実行(プロトコルにnovncを選ぶ場合)

$ juju set nova-cloud-controller console-access-protocol=novnc

(値はspice, xvpvnc, novnc, vncから指定)

以後起動するインスタンスはコンソール表示される。

(クライアントPCからcomputeノードの

名前解決できること)


インスタンスのコンソールを表示するJuju設定

以後起動するインスタンスはコンソール表示される


Juju/MAASでOpenStack環境完成

Over

Cloud

Under

Cloud


65

シナリオ:Juju+MAASで nova-computeをスケールアウト


Jujuでサービスをスケールアウト

作成済みのサービス"nova-compute"(OpenStackのコンピュートノード)へマシンを追加する

$ juju add-unit nova-compute

JujuがMAASへmachine割当とＯＳ生

成を依頼

MAAS GUIで1つのNodeがReadyから

Ready→Deploying→Deployedと変化

JujuがCharmに従い生成したMachineへ

リモート操作しnova computeを生成

OpenStackへnova-computeを登録

20-30分間かかる(OSの生成

からの場合)

MAASに割り振った特定タグの

マシンにデプロイすることも可能

• juju set-constraints tags=(タグ

名) (サービス名)

サービスに振られている

Constraintsの確認方法

• juju get-constraints (サービス名)



追加前のnova-compute

Unit=2つ



追加前のMAAS GUI。Tag=compute,Status=Deployedが2つ。Status=Readyが5つ



Juju でnova-computeサービスに対してadd-unitを実施



juju statusで状況確認

$ juju status nova-compute

Machine"70"として

nodevm3がアサインされた



Juju GUIに構築中Unit数がPendingとして表示される

MAAS GUIではMachineがStatus=Deployingになる



Jujuのデプロイシーケンス完了。

Juju GUIのPendingが消える。juju statusでagent-state=startedになる



さらにしばらく待つと、OpenStackに追加したマシンが現れる。

これですべて完了。


74


これからお話するところ＝③

Over

Cloud

Under

Cloud


OpenStack




OpenStack B2

OpenStack B3

OpenStack B4

MAAS

Juju(under)






OpenStack 構築





76

OpenStack上にJuju環境を作る


Juju on OpenStackの位置づけ

Over

Cloud

Under

Cloud


OpenStack

環境A(メイン)

MAAS

Juju(MAAS用)

テナントA

Juju(tenant)


Jujuを使ったサービスデプロイ

API

テナントB

Juju(tenant)


API

dns dns ココ


構成

private network private-subnet

ext-net (Global)

juju-core juju-bootstrap

juju-gui dns Router

GW

OpenStack Services

API

OpenStack上のプロジェクト"services"

Jujuで作る Service

インスタンス起動


OpenStack上に Juju環境をつくる手順

１．インスタンスにJuju-coreとapacheをインス

トール

２．Juju設定"enviroments.yaml"を編集

３．プライベート環境用metadataを生成し

Web公開する

４．juju bootstrapを実行しbootstrapサー

ビスを作る


Juju coreとapacheをインストール

# Juju coreとapacheをインストール $ sudo add-apt-repository ppa:juju/stable $ sudo apt-get update $ sudo apt-get install juju-core apache2 # Jujuの設定ファイルを生成し編集 $ juju init -f $ vi ~/.juju/environments.yaml


environments.yaml

environments: default: openstack openstack: type: openstack use-floating-ip: true use-default-secgroup: false network: ( Jujuを利用するOpenStackネットワークID ) tools-metadata-url: http://(juju-coreのIP)/stack/tools image-metadata-url: http://(juju-coreのIP)/stack/images auth-url: (keystone APIのURL) tenant-name: services (⇒利用するOpenStackプロジェクト名) region: RegionOne (⇒利用するOpenStackリージョン名) auth-mode: userpass username: (OpenStackプロジェクトのユーザー名) password: (OpenStackプロジェクトのパスワード)

ここがmetadata


metadataを作り公開する

metadata=Jujuが使うクラウド環境のインスタンス情報を記述したカタログファイル。

AWS等Public Cloudのmetadataはあらかじめ用意されているが、

Private Cloudの場合Jujuが参照可能なURLに作る必要がある。

#Jujuが使うglance上にあるUbuntu ServerイメージのIDを控える nova-cloud-contrller$ glance image-list # juju-coreにログインする。 # juju-coreでOSイメージのmetadataを作る。 $ juju metadata generate-image -a amd64 ¥ -i (glance イメージのID) -r RegionOne -s trusty ¥ -d /opt/stack -u (KeystoneAPIのURL) -e openstack # Juju toolsを記述したmetadataを作る $ juju metadata generate-tools -d /opt/stack # 作ったmetadataをDocumentRootへコピーする $ sudo cp -R /opt/stack /var/www/html


テナント用Juju bootstrapと GUIを作る

★bootstrap=Juju coreの指示でクラウド環境にMachineを作ったりUnitを

作ったりする実働サービス。ないとJujuは動かない。環境毎に生成する。

(AWS用、MAAS用、OpenStack用・・・)

juju-core$ juju bootstrap --metadata-source /opt/stack ¥ --upload-tools -v --show-log --debug

★Juju GUI= JujuのGUIサービス。なくてもJujuは動く。でも、ないとさびしい。

# juju-bootstrapを作ったmachine 0にjuju-guiをデプロイする。 juju-core$ juju deploy juju-gui --to 0 (OpenStack でjuju-guiをデプロイしたインスタンスのセキュリティグループに 443と80を許可する。) # GUIにログインするためのID,パスワードを確認する juju-core$ juju api-info user;juju api-info password password


84

本当ならこれでJujuが動く

はずだった・・・


残念な課題

Jujuで作ったOpenStack APIへ、テナント内のJuju bootstrapから疎通しない

残念1:そのそもIP

Reachableにしてなかっ

た

残念2: Juju/MAASが

決めたFQDNをテナント

内から参照できない


残念な個所

Over

Cloud

Under

Cloud


OpenStack

環境A(メイン)

MAAS

Juju(MAAS用)

テナントA

Juju(tenant)



API

API

ココの通信と名前解決 ×


対応1: サービスエンドポイント用IPを公開する

★Cloudのover/underを完全分離したのがアダになった。

⇒エンドポイント各サーバにext-net(Global IP領域)のIPを追加する

以下はkeystoneサーバへ外部API用NIC追加の例

$ sudo vi /etc/network/interfaces

iface eth1 inet manual auto pub-br1 iface pub-br1 inet static bridge_ports eth1 address (ext-net用IP) netmask (ネットマスク) network (ネットワークアドレス) broadcast (ブロードキャストアドレス)

$ shutdown -r now (実施後にOpenStack dashboardのサーバ再起動を必要とするケースがあったので、dashboardにログインできることを確認しつつ各サーバにIPを追加していく)


対応2:テナント内にDNSサーバをたてる

★ JujuだけでなくJujuが生み出すNode(インスタンス)もIPではなく(MAASが適当に決めた)FQDNでAPIアクセスしようとする。

(hosts編集じゃ逃げられない)

⇒今回はテナント内にunboundでローカルDNSを作成し OpenStackサブネットのDNSとしてそのDNSサーバを設定した。

$ sudo apt-get install unbound # unboundのACL定義を編集 $ sudo vi /etc/unbound/unbound.conf.d/server.conf # ローカル環境用DNSエントリ定義を編集 $ sudo vi /etc/unbound/unbound.conf.d/local-data.conf $ reboot

Juju利用するサブネットのDNSサーバに指定


対応2:テナント内にDNSサーバをたてる

◆unboundのACL定義

/etc/unbound/unbound.conf.d/server.conf

◆ローカル環境用DNSエントリ定義

/etc/unbound/unbound.conf.d/local-data.conf

server: local-data: "dns-in.services. IN A XX.XX.0.123" local-data: "vm7.maas. IN A XX.XX.0.10" local-data: "vm6.maas. IN A XX.XX.0.11" local-data: "vm3.maas. IN A XX.XX.0.12" local-data: "cinder.maas. IN A XX.XX.0.13" local-data: "vm1.maas. IN A XX.XX.0.14"

server: interface: 0.0.0.0 access-control: 127.0.0.1/32 allow access-control: (テナントが利用するNetwork Address)/16 allow


前向きな反省

★環境上の制約でUnder Cloud用(MAAS用)JujuとOver Cloud用(テナント用)Jujuを分離せざるを得なかった。 (Jujuはマルチ環境対応してるのに)

⇒ テナントを管理する側のJujuと管理される側のJujuが一緒よりも分かれてるほうが気持ちいい。テナント毎に分離できたほうが使いやすいダロウ？

★構築時のNW的制約でテナント内のJuju環境からOpenStackAPIをたたくのに苦労した。

⇒ テナント内でJuju coreとDNSをいつも立てる手順にすればテナント権限だけで自由にテナント内専用Jujuを構築できて便利ダロウ？

結論：だいたい望んだものができた


Juju on OpenStack完成

Over

Cloud

Under

Cloud


OpenStack

環境A(メイン)

MAAS

Juju(MAAS用)

テナントA

Juju(tenant)



API

テナントB

Juju(tenant)


API

dns dns


92

テナント内にJujuでサービスを構築する


Juju on OpenStackの位置づけ

Over

Cloud

Under

Cloud


OpenStack

環境A(メイン)

MAAS

Juju(MAAS用)

テナントA

Juju(tenant)



API

テナントB

Juju(tenant)


API

dns dns

ココ


94

シナリオ：Juju on OpenStackでWordPressをデプロイ


デモ Juju でWordPressをデプロイ

MAAS管理下のマシンへWordPressをデプロイしアクセスする [所要時間30-40分]

$ juju deploy mysql

$ juju deploy wordpress

$ juju add-relation wordpress mysql

$ juju expose wordpress

http://(nodeのIP)へアクセスしwordpressを設定する。

• 実測でそれぞれ約10-20分かかる。

• デプロイしたマシンのＩＰに外部からアクセス可能になる。

• IPはMAASのGUIから確認する。


VIDEOデモ：Jujuで WordPressを構築


Juju でWordPressをデプロイ

完成


98


やったこと

Over

Cloud

Under

Cloud


OpenStack

環境A(メイン)

MAAS

Juju(MAAS用)

テナントA

Juju(tenant)



API

テナントB

Juju(tenant)


API

dns dns

ココ

ココ

ココ

ココ


やったこと

1. 社内にOpenStack®の講習やPoCを行うための環境をつくりました。

2. Juju/MAASを使ってOpenStack環境を構築しました。

3. OpenStack上のプロジェクト内にJuju環境を構築しました。

4. Juju on OpenStackを使ってプロジェクト内のサービスをモデリング・デプロイしました。


101

なんでこんなことしてるの？


技術に垣根なし

OpenStack KVM

VMW

are

VPN

DNS

OSSとかプロプラエタリとかパブリックとかオンプレとかいっていられない

Juju AWS

AZU

RE

Blue

Mix

MAAS OCP

BMS


ワンストップから選択される専門家へ

• 提案から運用までロックインする「SI」は変化

• IT構築がなくなるわけではない。人やノウハウは必要

• 構築(Dev)と運用保守(Ops)で委託先分離できるように

• ロックできないから「専門家」になることが求められる

業務コンサル構築・教育運用サービス

◆従来：ワンストップ＝ロックイン

業務コンサル構築・教育運用サービス

◆これから：ロックフリー＝専門集団化

選択選択選択

ロックロック

専門化専門化専門化


クラウド活用ですべて社内で賄えるか

コスト：社員を維持するコスト

•有能な社員は本業に集中させたいはず

•不要になったらリリースしたいはず

技術：社員ですべての知見

を賄えるわけじゃない

•有能な社員は限られている

•専門性を社員で賄えない

調達：すべての製品を直接買っ

て面倒みるのか

従来(ワンストップSI)

最近(クラウド,自動化が支援)

SIerに人員をオフロード

クラウドサービス,自動化にオフロード＋社員が管理

SIerがＩＴ・業務専門知識を提供

クラウドサービス（ナレッジ）を活用コンサル利用＋社員が勉強

SIerが調達・保守を代行

調達せずサービスとして利用 +社員が調達・保守

クラウド（的なもの）が選択できるようになった。でも、社員の負担も増える


クラウド時代も私たちが皆様のお役にたてることはいろいろありそうだ

よきパートナーになるための努力をし

これからもがんばってまいります

最新技術をキャッ

チする

PoC(Proof of

Concept)で

顧客業務要件へ

フィッティング

得意な領域を繰

り返し深く専門化

する

現場から湧き出る PoCネタ募集！

ぜひお声掛けください


106

ubuntu juju/maas・openstackを使った検証環境構築 - openstack最新情報セミナー...

Technology