OpenStack環境構築入門 - OpenStack最新情報セミナー 2014年6月

1. OpenStack環境構築入門 Havana対応版日本仮想化技術株式会社 VirtualTech.jp

2. 自己紹介 •  本名：宮原徹 •  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

3. 日本仮想化技術株式会社概要 •  社名：日本仮想化技術株式会社 –  英語名：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

4. EnterpriseCloud.jp •  OpenStackで始めるエンタープライズクラウドの情報サイト •  OpenStack導入手順書のダウンロード •  各種プレゼン資料 •  その他ブログ記事 4

5. OpenStack最新情報セミナー開催中 •  OpenStackに関する最新情報セミナーを隔月開催 –  第4回：『OpenStack環境構築入門』＆『ネットワーク仮想化の最新動向 – Software Defined Infrastructure(SDI)を目指して』（2014年4月10日 (木)） –  第5回：『OpenStack環境構築入門』＆『OpenStack のストレージ』（2014年6月5日(木)） •  費用：無償 •  資料もすべて公開中 •  詳細はEnterpriseCloud.jpをご覧下さい 5

6. @IT：たまおきのOpenSatck Watch 6 •  OpenStackを中心にクラウド関係の最新情報を@ITにて毎月発信 •  たまおき＠VTJ責任編集 http://bit.ly/1areUHP

7. ベアメタルOpenStackの特徴 7 従来のOpenStack ベアメタルOpenStack 物理サーバ群サーバ仮想化技術クラウドサービスＡクラウドサービスＢクラウドサービスＣ物理サーバ群クラウドサービスＡクラウドサービスＢクラウドサービスＣサーバ仮想化技術を利用しない状況に応じて仮想/物理の切替可能

8. 次期バージョン “Icehouse” 2014年4月17日リリース •  TripleO(OpenStack on OpenStack) –  OpenStackでOpenStack環境自体をインストール •  Ironic –  仮想マシンだけでなく物理マシン（Baremetal）も管理 •  Macaroni –  メッセージサービス •  Trove –  DBaaS •  Sahara（aka Savanna） –  Hadoop環境 8

9. 最近やっていること •  OpenStackデプロイツールの評価検証 –  UbuntuのJuJu/MaaSを使ったOpenStack環境構築 –  RDOを使ったOpenStack環境構築 •  Icehouse導入手順書の作成 –  Havanaと手順がかなり入れ替わった –  相変わらずNeutron周りが・・ •  DevStackの検証 –  最近、ネットワークがうまく繋がらなくなった・・ 9

10. 本日のアジェンダ •  OpenStackの概要 •  OpenStackの環境設計入門編 –  今回のネットワーク設計解説 •  Ubuntu Server 12.04LTSのインストールと設定 •  Keystoneの設定の勘所 •  Neutronの設定の勘所 10

11. OpenStackの概要

12. OpenStack概要 12 仮想マシンネットワークストレージ Web管理画面 IaaS環境を実現するソフトウェアスタック

13. OpenStack構成図 13 MQやRESTで相互接続 http://docs.openstack.org/havana/install-guide/install/apt/content/ch_overview.html

14. OpenStackの構成要素サービス役割 Nova 全体をコントロール Nova Compute 仮想マシンインスタンス管理 Message Queue AMQP Keystone 認証系 Glance ゲストOSイメージ管理 Cinder ブロックストレージ管理 Horizon Web管理画面 Swift オブジェクトストレージ Ceilometer リソース利用量監視 Heat 自動化 14

15. 今回の設計の方針 •  Ubuntu Server 12.04LTSをベースに構築 •  3ノード構成 –  コントローラー（以下の2つ以外全部） –  ネットワーク（Neutron＋Open vSwitch） –  仮想マシンインスタンス（Nova Compute+Open vSwitch） •  今回はSwift、Ceilometer、Heatは未使用 –  Ceilometer、Heatは今回の手順が理解できれば導入手順は概ね同じ 15

16. OpenStack環境の設計入門編

17. OpenStack環境設計時の考慮点 •  ネットワーク構成 –  物理設計 –  論理設計（Open vSwitchやOpenFlowなど） •  ストレージ構成 –  マスターイメージ管理（Glance） –  ブロックストレージ管理（Cinder＋外部ストレージ） –  共有ストレージ領域の準備（NFSなど） –  オブジェクトストレージの利用（Swift） 17

18. 今回の環境 •  ネットワーク構成は2系統 –  管理系（eth0） –  サービス系（eth1） •  Neutron+Open vSwitch（GREトンネリング） •  Floating IPで物理ネットワークと仮想マシンネットワークを接続 •  ストレージ構成はファイルベース –  コントローラーにLVM領域を作成し、ゲストOS イメージはファイルとして保管 18

19. Fixed IPとFloating IPの仕組み ①  FIXED_RANGEで割り当てられる。 ①同士は通信できるが、③とは通信できない ②  FLOATING_RANG Eで割り当てられる。実際には②と①との間で静的NATを行っている。 ③→②→①と繋がる 19 ① ② サービスクライアント ③ インスタンス ①

20. ネットワーク構成図 20 controller ノード network ノード compute1 ノードインスタンスクライアント管理系（eth0）サービス系（eth1） eth0 eth0 eth0 仮想スイッチセグメント eth1

21. Open vSwitch接続図 21 network ノード compute1 ノードクライアント br-int br-ex eth1 eth0 eth0

22. 仮想ネットワーク図 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

23. Ubuntu Server 12.04LTSのインストールと設定

24. Ubuntu Server 12.04LTSの導入（共通） 1.  ベースOSとしてのインストール –  OpenSSHのみインストール 2.  IPアドレスの設定 3.  静的名前解決の設定 4.  sysctlによるシステムの設定（ネットワーク） 5.  aptの設定 6.  NTPのインストール 7.  Python用MySQLクライアントのインストール 24

25. ネットワーク設定（手順書） 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公開用ですが、今回は使用していません

26. Keystoneの設定の勘所 26

27. テナント(demo) OpenStackのアカウント構造 •  テナントは複数のユーザーを束ねるグループのような役割 –  従来はプロジェクト •  ユーザー権限はロールとして各ユーザーに権限付与 •  ロールの定義は policy.jsonに記述 27 テナントadmin ユーザー admin ロール admin Member 権限付与 demo service

28. サービスと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情報

29. 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 'O penStack Identity’! keystone endpoint-create --region $KEYSTONE_REGION --service-id $IDENTIT Y_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スクリプトにまとめてあります

30. policy.jsonの記述方法 •  ポリシーとルールで記述 –  ポリシー:[[“ルール”]] と記述する •  ポリシー：操作とリソース –  リソースは現在ネットワーク関係のみ •  ルール：ロール、フィールドと一般 –  ロールは role:admin と記述 –  フィールドは is_admin:True と記述 –  一般は tenant_id:%(tenant_id)s と記述 30

31. 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

32. Neutronの設定の勘所

33. パッケージのインストール •  各ノードに合わせたパッケージの導入 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ノードの双方にインストールすること

34. 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.OVSHybridIptablesF irewallDriver interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver

35. 参考：Neutron+その他のSDN •  OpenContrail –  ネットワーク仮想化とNFVに特化 –  Juniperのサポートが受けられる –  OpenStackへの統合を中心に開発されている •  OpenDaylight –  Virutalization EditionがOpenStack対応 –  機能が豊富だがリリースされたばかり 35

36. 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. その他 37

38. Glanceの動作 ephemeralな場合 1.  インスタンス起動で指定されたイメージを Glanceノードからcomputeノードの “/var/lib/nova/instances/_base”にコピー 2.  コピーしたイメージをベースとしてqcow2 差分ディスクを”/var/lib/nova/インスタンス ID/disk”として作成 3.  作成したqcow2差分ディスクを/dev/vdaとしてインスタンスにアタッチ 38

39. Cinderの動作 39 controller compute1 インスタンス eth0 eth0 /dev/vda LVM volume ボリューム iscsid tgt Glance イメージイメージからボリュームを作成し、そのボリュームから起動することも可能

40. イメージ登録と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

41. いくつかの宿題 •  不要な設定の排除 –  GrizzlyからHavanaへのバージョンアップの際に不要になった設定がまだ残っている –  docs.openstack.orgのドキュメントも結構引きずってる –  とりあえず影響は無いレベルだが、認証関係の設定の記述は極力少なくしたい •  Ceilometer、Heatのインストール –  基本的な手順はその他のサービスと同じ •  Swiftのインストール –  Glanceのバックエンドとしても使用可能 •  Icehouse対応版手順書の公開 41