Upload
virtualtech-japan-inc
View
2.452
Download
2
Embed Size (px)
DESCRIPTION
講師:日本仮想化技術 宮原 日時:2014/06/05 タイトル:OpenStack環境構築入門 Havana編 概要: - OpenStackの概要 - OpenStackの環境設計 入門編 --- 今回のネットワーク設計 解説 - Ubuntu Server 12.04LTSのインストールと設定 - Keystoneの設定の勘所 - Neutronの設定の勘所
Citation preview
OpenStack環境構築入門 Havana対応版
日本仮想化技術株式会社
VirtualTech.jp
自己紹介
• 本名:宮原 徹 • 1972年1月 神奈川県生まれ • 1994年3月 中央大学法学部法律学科卒業 • 1994年4月 日本オラクル株式会社入社
– PCサーバ向けRDBMS製品マーケティングに従事 – Linux版Oracle8の日本市場向け出荷に貢献
• 2000年3月 株式会社デジタルデザイン 東京支社長および株式会社アクアリウムコンピューター 代表取締役社長に就任 – 2000年6月 (株)デジタルデザイン、ナスダック・ジャパン上場(4764)
• 2001年1月 株式会社びぎねっと 設立 • 2006年12月 日本仮想化技術株式会社 設立 • 2008年10月 IPA「日本OSS貢献者賞」受賞 • 2009年10月 日中韓OSSアワード 「特別貢献賞」受賞
2
日本仮想化技術株式会社 概要
• 社名:日本仮想化技術株式会社 – 英語名:VirtualTech Japan Inc. – 略称:日本仮想化技術/VTJ
• 設立:2006年12月 • 資本金:2,000万円 • 売上高:1億3,573万円(2013年7月期) • 本社:東京都渋谷区渋谷1-8-1 • 取締役:宮原 徹(代表取締役社長兼CEO) • 伊藤 宏通(取締役CTO) • スタッフ:8名(うち、6名が仮想化技術専門エンジニアです) • URL:http://VirtualTech.jp/ • 仮想化技術に関する研究および開発
– 仮想化技術に関する各種調査 – 仮想化技術に関連したソフトウェアの開発 – 仮想化技術を導入したシステムの構築 – OpenStackの導入支援・新規機能開発
ベンダーニュートラルな独立系仮想化技術の エキスパート集団
3
EnterpriseCloud.jp
• OpenStackで始めるエンタープライズクラウドの情報サイト
• OpenStack導入手順書のダウンロード
• 各種プレゼン資料 • その他ブログ記事
4
OpenStack 新情報セミナー開催中
• OpenStackに関する 新情報セミナーを隔月開催 – 第4回:『OpenStack環境構築入門』&『ネットワー
ク仮想化の 新動向 – Software Defined Infrastructure(SDI)を目指して』(2014年4月10日(木))
– 第5回:『OpenStack環境構築入門』&『OpenStackのストレージ』(2014年6月5日(木))
• 費用:無償 • 資料もすべて公開中 • 詳細はEnterpriseCloud.jpをご覧下さい
5
@IT:たまおきのOpenSatck Watch
6
• OpenStackを中心にクラウド関係の 新情報を@ITにて毎月発信
• たまおき@VTJ責任編集
http://bit.ly/1areUHP
ベアメタルOpenStackの特徴
7
従来のOpenStack ベアメタルOpenStack
物理サーバ群
サーバ仮想化技術
クラウドサービスA
クラウドサービスB
クラウドサービスC
物理サーバ群
クラウドサービスA
クラウドサービスB
クラウドサービスC
サーバ仮想化技術を利用しない
状況に応じて仮想/物理の切替可能
次期バージョン “Icehouse”
2014年4月17日リリース • TripleO(OpenStack on OpenStack)
– OpenStackでOpenStack環境自体をインストール • Ironic
– 仮想マシンだけでなく物理マシン(Baremetal)も管理 • Macaroni
– メッセージサービス • Trove
– DBaaS • Sahara(aka Savanna)
– Hadoop環境
8
近やっていること
• OpenStackデプロイツールの評価検証 – UbuntuのJuJu/MaaSを使ったOpenStack環境
構築 – RDOを使ったOpenStack環境構築
• Icehouse導入手順書の作成 – Havanaと手順がかなり入れ替わった – 相変わらずNeutron周りが・・
• DevStackの検証 – 近、ネットワークがうまく繋がらなくなった・・
9
本日のアジェンダ
• OpenStackの概要 • OpenStackの環境設計 入門編
– 今回のネットワーク設計 解説
• Ubuntu Server 12.04LTSのインストールと設定 • Keystoneの設定の勘所 • Neutronの設定の勘所
10
OpenStackの概要
OpenStack概要
12
仮想マシン ネットワーク ストレージ
Web管理画面
IaaS環境を実現するソフトウェアスタック
OpenStack構成図
13
MQやRESTで 相互接続
http://docs.openstack.org/havana/install-guide/install/apt/content/ch_overview.html
OpenStackの構成要素
サービス 役割
Nova 全体をコントロール
Nova Compute 仮想マシンインスタンス管理
Message Queue AMQP
Keystone 認証系
Glance ゲストOSイメージ管理
Cinder ブロックストレージ管理
Horizon Web管理画面
Swift オブジェクトストレージ
Ceilometer リソース利用量監視
Heat 自動化
14
今回の設計の方針
• Ubuntu Server 12.04LTSをベースに構築 • 3ノード構成
– コントローラー(以下の2つ以外全部) – ネットワーク(Neutron+Open vSwitch) – 仮想マシンインスタンス(Nova Compute+Open
vSwitch) • 今回はSwift、Ceilometer、Heatは未使用
– Ceilometer、Heatは今回の手順が理解できれば導入手順は概ね同じ
15
OpenStack環境の設計 入門編
OpenStack環境設計時の考慮点
• ネットワーク構成 – 物理設計 – 論理設計(Open vSwitchやOpenFlowなど)
• ストレージ構成 – マスターイメージ管理(Glance) – ブロックストレージ管理(Cinder+外部ストレー
ジ) – 共有ストレージ領域の準備(NFSなど) – オブジェクトストレージの利用(Swift)
17
今回の環境
• ネットワーク構成は2系統 – 管理系(eth0) – サービス系(eth1)
• Neutron+Open vSwitch(GREトンネリング) • Floating IPで物理ネットワークと仮想マシンネット
ワークを接続
• ストレージ構成はファイルベース – コントローラーにLVM領域を作成し、ゲストOS
イメージはファイルとして保管
18
Fixed IPとFloating IPの仕組み
① FIXED_RANGEで割り当てられる。 ①同士は通信できるが、③とは通信できない
② FLOATING_RANGEで割り当てられる。実際には②と①との間で静的NATを行っている。 ③→②→①と繋がる
19
①
②
サービス
クライアント ③
インスタンス
①
ネットワーク構成図
20
controller ノード
network ノード
compute1 ノード
インスタンス
クライアント
管理系(eth0)
サービス系(eth1)
eth0 eth0 eth0 仮想スイッチ
セグメント
eth1
Open vSwitch接続図
21
network ノード
compute1 ノード
クライアント
br-int
br-ex
eth1
eth0 eth0
仮想ネットワーク図
22
demo-net
ext-net ext-net-subnet(10.0.0.0/24)
インスタンス
demo-net-subnet(10.5.5.0/24)
demo-router
10.5.5.1
Floating IP(10.0.0.200/24〜10.0.0.250/24)
Fixed IP(10.5.5.2/24〜10.5.5.254/24)
クライアント 10.0.0.x
Ubuntu Server 12.04LTSの インストールと設定
Ubuntu Server 12.04LTSの導入(共通)
1. ベースOSとしてのインストール – OpenSSHのみインストール
2. IPアドレスの設定 3. 静的名前解決の設定 4. sysctlによるシステムの設定(ネットワーク) 5. aptの設定 6. NTPのインストール 7. Python用MySQLクライアントのインストール
24
ネットワーク設定(手順書)
eth0 eth1
controller 192.168.0.10 10.0.0.10
network 192.168.0.9 10.0.0.9
compute1 192.168.0.11 10.0.0.11
ゲートウェイ なし 10.0.0.1
ネームサーバー なし 10.0.0.1
25
• eth0側にゲートウェイ、ネームサーバーの設定が無いのは構築環境の制約によるものです
• compute1のeth1(10.0.0.11)は本来不要ですが、aptコマンドによるリポジトリへのアクセスが必要なため設定されています。環境構築後は使用しません。
• controllerのeth1(10.0.0.10)は外部API公開用ですが、今回は使用していません
Keystoneの設定の勘所
26
テナント(demo)
OpenStackのアカウント構造
• テナントは複数のユーザーを束ねるグループのような役割 – 従来はプロジェクト
• ユーザー権限はロールとして各ユーザーに権限付与
• ロールの定義はpolicy.jsonに記述
27
テナントadmin
ユーザー
admin
ロール
admin
Member
権限付与 demo
service
サービスとAPI endpoint
• 各サービスのRESTful APIインターフェースをendpointとしてKeystoneに登録
• endpointには認証が設定される
28
API種別 API URL
admin API http://controller:35357/v2.0
internal API http://controller:5000/v2.0
public API http://controller:5000/v2.0
Keystonのendpoint情報
Keystoneへの接続認証
1. Keystoneにサービスとendpointの作成
2. 各設定ファイル内に以下の記述
29
[keystone_authtoken] auth_host = controller auth_port = 35357
auth_protocol = http auth_uri = http://controller:5000/v2.0
admin_tenant_name = service admin_user = glance ←サービス毎に異なる admin_password = password ←ユーザー毎に異なる
flavor=keystone ←○○-paste.confに渡される
keystone service-create --name keystone --type identity --description 'OpenStack Identity’!keystone endpoint-create --region $KEYSTONE_REGION --service-id $IDENTITY_SERVICE --publicurl 'http://'"$KEYSTONE_HOST"':5000/v2.0' --adminurl 'http://'"$KEYSTONE_HOST"':35357/v2.0' --internalurl 'http://'"$KEYSTONE_HOST"':5000/v2.0'
サービスとendopoint作成はkeystone_init.shスクリプトにまとめてあります
policy.jsonの記述方法
• ポリシーとルールで記述 – ポリシー:[[“ルール”]] と記述する
• ポリシー:操作とリソース – リソースは現在ネットワーク関係のみ
• ルール:ロール、フィールドと一般 – ロールは role:admin と記述 – フィールドは is_admin:True と記述 – 一般は tenant_id:%(tenant_id)s と記述
30
policy.jsonの例
{! "context_is_admin": "role:admin",! #adminロールのユーザーはcontext_is_adminとなる "admin_or_owner": "is_admin:True or project_id:%(project_id)s",! #ユーザー情報のis_adminフィールドがTrueのユーザーかproject_idが同じ場合には #admin_or_ownerとなる
"default": "rule:admin_or_owner",! #指定がない場合、 "cells_scheduler_filter:TargetCellFilter": "is_admin:True",! #ユーザー情報のis_adminフィールドがTrueのユーザーのみに有効
"compute:create": "",! #誰でもインスタンスを作成できる
31
Neutronの設定の勘所
パッケージのインストール
• 各ノードに合わせたパッケージの導入
33
ノード パッケージ
controller neutron-server network neutron-server
neutron-dhcp-agent neutron-plugin-openvswitch-agent neutron-l3-agent openvswitch-datapath-dkms
compute1 neutron-plugin-openvswitch-agent openvswitch-datapath-dkms
openvswitch-datapath-dkmsをnetworkノードとcompute1ノードの双方に インストールすること
Neutron+Open vSwitchの設定
• /etc/nova/nova.conf
• /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
• /etc/neutron/dhcp_agent.ini
• /etc/neutron/l3_agent.ini
34
linuxnet_interface_driver=nova.network.linux_net.LinuxOVSInterfaceDriver firewall_driver=nova.virt.firewall.NoopFirewallDriver security_group_api=neutron
[securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
参考:Neutron+その他のSDN
• OpenContrail – ネットワーク仮想化とNFVに特化 – Juniperのサポートが受けられる – OpenStackへの統合を中心に開発されている
• OpenDaylight – Virutalization EditionがOpenStack対応 – 機能が豊富だがリリースされたばかり
35
Base Network Service Functions
Management GUI/CLI
Controller Platform
Southbound Interfaces & Protocol Plugins
OpenDaylight APIs (REST)
oDMC
Data Plane Elements (Virtual Switches,
Physical Device Interfaces)
Service Abstraction Layer (SAL) (plug-in mgr., capability abstractions, flow programming, inventory, …)
OpenFlow 1.0 1.3
Topology Mgr Stats
Mgr Switch Mgr
VTN Coordinator
Affinity Service
Network Applications Orchestration & Services OpenStack
Neutron
OpenFlow Enabled Devices
VTN Manager
NETCONF
Additional Virtual & Physical Devices
Virtualization Edition
D4A Protection
Open vSwitches
OpenStack Service
OVSDB
FRM ARP Handler Host
Tracker
VTN: Virtual Tenant Network oDMC: open Dove Management Console D4A: Defense4All protection LISP: Locator/Identifier Separation Protocol OVSDB: Open vSwitch Data Base Protocol BGP: Border Gateway Protocol PCEP: Path Computation Element Communication Protocol SNMP: Simple Network Management Protocol
OVSDB Neutron
その他
37
Glanceの動作
ephemeralな場合 1. インスタンス起動で指定されたイメージを
Glanceノードからcomputeノードの “/var/lib/nova/instances/_base”にコピー
2. コピーしたイメージをベースとしてqcow2差分ディスクを”/var/lib/nova/インスタンスID/disk”として作成
3. 作成したqcow2差分ディスクを/dev/vdaとしてインスタンスにアタッチ
38
Cinderの動作
39
controller compute1
インスタンス
eth0 eth0
/dev/vda
LVM volume
ボリューム
iscsid tgt
Glance
イメージ
イメージからボリュームを作成し、そのボリュームから起動することも可能
イメージ登録とcloud-init
• 各種公式OSイメージのダウンロード – http://docs.openstack.org/image-guide/content/
ch_obtaining_images.html • 独自OSイメージを作った場合はcloud-init
を導入すると良い – https://launchpad.net/cloud-init
• さらに設定の自動化を行うのであればHeatの利用、Chef、Puppetとの連動も
40
いくつかの宿題
• 不要な設定の排除 – GrizzlyからHavanaへのバージョンアップの際に不要
になった設定がまだ残っている – docs.openstack.orgのドキュメントも結構引きずってる – とりあえず影響は無いレベルだが、認証関係の設定
の記述は極力少なくしたい • Ceilometer、Heatのインストール
– 基本的な手順はその他のサービスと同じ • Swiftのインストール
– Glanceのバックエンドとしても使用可能 • Icehouse対応版手順書の公開
41