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

0 views
3,219 views

Published on

講師:日本仮想化技術 宮原
日時:2014/06/05
タイトル:OpenStack環境構築入門 Havana編
概要:
- OpenStackの概要
- OpenStackの環境設計 入門編
--- 今回のネットワーク設計 解説
- Ubuntu Server 12.04LTSのインストールと設定
- Keystoneの設定の勘所
- Neutronの設定の勘所

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
0
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
86
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

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

  1. 1. OpenStack環境構築入門 Havana対応版 日本仮想化技術株式会社 VirtualTech.jp
  2. 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. 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. 4. EnterpriseCloud.jp •  OpenStackで始めるエ ンタープライズクラウ ドの情報サイト •  OpenStack導入手順 書のダウンロード •  各種プレゼン資料 •  その他ブログ記事 4
  5. 5. OpenStack最新情報セミナー開催中 •  OpenStackに関する最新情報セミナーを隔月 開催 –  第4回:『OpenStack環境構築入門』&『ネットワー ク仮想化の最新動向 – Software Defined Infrastructure(SDI)を目指して』(2014年4月10日 (木)) –  第5回:『OpenStack環境構築入門』&『OpenStack のストレージ』(2014年6月5日(木)) •  費用:無償 •  資料もすべて公開中 •  詳細はEnterpriseCloud.jpをご覧下さい 5
  6. 6. @IT:たまおきのOpenSatck Watch 6 •  OpenStackを中心にク ラウド関係の最新情 報を@ITにて毎月発 信 •  たまおき@VTJ責任 編集 http://bit.ly/1areUHP
  7. 7. ベアメタルOpenStackの特徴 7 従来のOpenStack ベアメタルOpenStack 物理サーバ群 サーバ 仮想化 技術 クラウド サービスA クラウド サービスB クラウド サービスC 物理サーバ群 クラウド サービスA クラウド サービスB クラウド サービスC サーバ仮想化技術 を利用しない 状況に応じて 仮想/物理の 切替可能
  8. 8. 次期バージョン “Icehouse” 2014年4月17日リリース •  TripleO(OpenStack on OpenStack) –  OpenStackでOpenStack環境自体をインストール •  Ironic –  仮想マシンだけでなく物理マシン(Baremetal)も管理 •  Macaroni –  メッセージサービス •  Trove –  DBaaS •  Sahara(aka Savanna) –  Hadoop環境 8
  9. 9. 最近やっていること •  OpenStackデプロイツールの評価検証 –  UbuntuのJuJu/MaaSを使ったOpenStack環境 構築 –  RDOを使ったOpenStack環境構築 •  Icehouse導入手順書の作成 –  Havanaと手順がかなり入れ替わった –  相変わらずNeutron周りが・・ •  DevStackの検証 –  最近、ネットワークがうまく繋がらなくなった・・ 9
  10. 10. 本日のアジェンダ •  OpenStackの概要 •  OpenStackの環境設計 入門編 –  今回のネットワーク設計 解説 •  Ubuntu Server 12.04LTSのインストールと設定 •  Keystoneの設定の勘所 •  Neutronの設定の勘所 10
  11. 11. OpenStackの概要
  12. 12. OpenStack概要 12 仮想マシン ネットワーク ストレージ Web管理画面 IaaS環境を実現するソフトウェアスタック
  13. 13. OpenStack構成図 13 MQやRESTで 相互接続 http://docs.openstack.org/havana/install-guide/install/apt/content/ch_overview.html
  14. 14. OpenStackの構成要素 サービス 役割 Nova 全体をコントロール Nova Compute 仮想マシンインスタンス管理 Message Queue AMQP Keystone 認証系 Glance ゲストOSイメージ管理 Cinder ブロックストレージ管理 Horizon Web管理画面 Swift オブジェクトストレージ Ceilometer リソース利用量監視 Heat 自動化 14
  15. 15. 今回の設計の方針 •  Ubuntu Server 12.04LTSをベースに構築 •  3ノード構成 –  コントローラー(以下の2つ以外全部) –  ネットワーク(Neutron+Open vSwitch) –  仮想マシンインスタンス(Nova Compute+Open vSwitch) •  今回はSwift、Ceilometer、Heatは未使用 –  Ceilometer、Heatは今回の手順が理解できれ ば導入手順は概ね同じ 15
  16. 16. OpenStack環境の設計 入門編
  17. 17. OpenStack環境設計時の考慮点 •  ネットワーク構成 –  物理設計 –  論理設計(Open vSwitchやOpenFlowなど) •  ストレージ構成 –  マスターイメージ管理(Glance) –  ブロックストレージ管理(Cinder+外部ストレー ジ) –  共有ストレージ領域の準備(NFSなど) –  オブジェクトストレージの利用(Swift) 17
  18. 18. 今回の環境 •  ネットワーク構成は2系統 –  管理系(eth0) –  サービス系(eth1) •  Neutron+Open vSwitch(GREトンネリング) •  Floating IPで物理ネットワークと仮想マシンネット ワークを接続 •  ストレージ構成はファイルベース –  コントローラーにLVM領域を作成し、ゲストOS イメージはファイルとして保管 18
  19. 19. Fixed IPとFloating IPの仕組み ①  FIXED_RANGEで 割り当てられる。 ①同士は通信できる が、③とは通信でき ない ②  FLOATING_RANG Eで割り当てられる。 実際には②と①との 間で静的NATを行っ ている。 ③→②→①と繋がる 19 ① ② サービス クライアント ③ インスタンス ①
  20. 20. ネットワーク構成図 20 controller ノード network ノード compute1 ノード インスタンス クライアント 管理系(eth0) サービス系(eth1) eth0 eth0 eth0 仮想スイッチ セグメント eth1
  21. 21. Open vSwitch接続図 21 network ノード compute1 ノード クライアント br-int br-ex eth1 eth0 eth0
  22. 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. 23. Ubuntu Server 12.04LTSの インストールと設定
  24. 24. Ubuntu Server 12.04LTSの導入(共通) 1.  ベースOSとしてのインストール –  OpenSSHのみインストール 2.  IPアドレスの設定 3.  静的名前解決の設定 4.  sysctlによるシステムの設定(ネットワーク) 5.  aptの設定 6.  NTPのインストール 7.  Python用MySQLクライアントのインストール 24
  25. 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. 26. Keystoneの設定の勘所 26
  27. 27. テナント(demo) OpenStackのアカウント構造 •  テナントは複数の ユーザーを束ねるグ ループのような役割 –  従来はプロジェクト •  ユーザー権限はロー ルとして各ユーザー に権限付与 •  ロールの定義は policy.jsonに記述 27 テナントadmin ユーザー admin ロール admin Member 権限付与 demo service
  28. 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. 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. 30. policy.jsonの記述方法 •  ポリシーとルールで記述 –  ポリシー:[[“ルール”]] と記述する •  ポリシー:操作とリソース –  リソースは現在ネットワーク関係のみ •  ルール:ロール、フィールドと一般 –  ロールは role:admin と記述 –  フィールドは is_admin:True と記述 –  一般は tenant_id:%(tenant_id)s と記述 30
  31. 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. 32. Neutronの設定の勘所
  33. 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. 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. 35. 参考:Neutron+その他のSDN •  OpenContrail –  ネットワーク仮想化とNFVに特化 –  Juniperのサポートが受けられる –  OpenStackへの統合を中心に開発されている •  OpenDaylight –  Virutalization EditionがOpenStack対応 –  機能が豊富だがリリースされたばかり 35
  36. 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. その他 37
  38. 38. Glanceの動作 ephemeralな場合 1.  インスタンス起動で指定されたイメージを Glanceノードからcomputeノードの “/var/lib/nova/instances/_base”にコピー 2.  コピーしたイメージをベースとしてqcow2 差分ディスクを”/var/lib/nova/インスタンス ID/disk”として作成 3.  作成したqcow2差分ディスクを/dev/vdaと してインスタンスにアタッチ 38
  39. 39. Cinderの動作 39 controller compute1 インスタンス eth0 eth0 /dev/vda LVM volume ボリューム iscsid tgt Glance イメージ イメージからボリュームを 作成し、そのボリューム から起動することも可能
  40. 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. 41. いくつかの宿題 •  不要な設定の排除 –  GrizzlyからHavanaへのバージョンアップの際に不要 になった設定がまだ残っている –  docs.openstack.orgのドキュメントも結構引きずってる –  とりあえず影響は無いレベルだが、認証関係の設定 の記述は極力少なくしたい •  Ceilometer、Heatのインストール –  基本的な手順はその他のサービスと同じ •  Swiftのインストール –  Glanceのバックエンドとしても使用可能 •  Icehouse対応版手順書の公開 41

×