Downloaded 55 times
Uploaded byVirtualTech Japan Inc.
OpenStack本番環境の作り方 - Interop 2016
アジェンダ - OpenStackとは - 今回構築した環境 - 環境を構築して気づいたこと
More Related Content
Similar to OpenStack本番環境の作り方 - Interop 2016
OpenStack本番環境の作り方 - Interop 2016
- 1.
- 2. 自己紹介 • 日本仮想化技術の中の人 • オープンスタック関連の ビジネス創出中 –EnterpriseCloud.jp の管理者 – 『OpenStack最新情報セミナー』 の企画・運営 2
- 3. 日本仮想化技術株式会社 • 社名：日本仮想化技術株式会社 – 英語名：VirtualTechJapan Inc. – 略称：日本仮想化技術／VTJ • 設立：2006年12月 • 資本金：3,000万円 • 売上高：8,700万円（2015年7月期） • 本社：東京都渋谷区渋谷1-8-1 • 取締役：宮原 徹（代表取締役社長兼CEO） • 伊藤 宏通（取締役CTO） • スタッフ：9名（うち、8名が仮想化技術専門エンジニアです） • URL：http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術に関連したソフトウェアの開発 – 仮想化技術を導入したシステムの構築 – OpenStackの導入支援・新規機能開発 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 3
- 4. OpenStackへの取り組み • 通信事業社でのOpenStack基盤の検討支援および構築・運用 – NTTドコモ(2011年から技術評価を支援、商用利用に向けた検討・構 築・運用を実施) – NTT西日本 (商用利用に向けた評価・検討の支援、プロジェクトマネー ジメント支援) – 大手通信事業社A社 (ベアメタルサービスの検討支援) – 大手通信事業社B社 (ベアメタルサービスの技術評価) • ベアメタルOpenStackの開発 – 仮想環境と物理環境をOpenStackで一括管理 – 単一のイメージで仮想マシンと物理マシンの双方を起動可能 – 2013年4月リリースのGrizzlyで本体にマージ 4
- 5. OpenStack Summitでの発表実績① 2014/11 OpenStackSummit Paris We spoke the knowledge and tips when building and operating OpenStack Cloud on 100 Physical Servers. (Neutron HA, VXLAN performance,,,) 2012/10 OpenStack Summit San Diego We announced baremetal provisioning framework which handles barematel machine like a virtual machine. This is merged upstream in Grizzly. 5
- 6. OpenStack Summitでの発表実績② 2015/10 OpenStackSummit Tokyo We (NTT West, Canonical and VTJ) spoke ”Requirements for Providing Telecom Services on OpenStack-based Infrastructure”. 6
- 7. EnterpriseCloud.jp • OpenStackで始めるエ ンタープライズクラウ ドの情報サイト • OpenStack導入手順 書のダウンロード •各種プレゼン資料 • その他ブログ記事 7http://EnterpriseCloud.jp 今日のポイント
- 8.
- 9.
- 10.
- 11.
- 12. OpenStack共同検証ラボとは • ブロードバンドタワー様のデータセンター施設を 利用し、検証環境を用意いたします。 • 『OpenStack共同検証ラボ』に協賛いただく会社を 募り、協賛企業の皆様と共に検証を行います。 –協賛企業の皆様は検証テーマを提案できます。 – 本ラボが提案した検証テーマに参画いただくことも可 能です。 • 『OpenStack共同検証ラボ』で得たノウハウや知 見をドキュメント化し、ドキュメントを一般公開い たします。 12
- 13. OpenStack共同検証ラボ 概要 • 当初は2つのゾーンを用意 •ゾーンは3ヶ月~6ヶ月の周期で環境構築・調査・報告作成 を繰り返していく。 13 • SDN/NFV製品の機能 検証 • パフォーマンス検証 • 可用性検証 • SDN/NFV製品の運 用・トラブルシューティ ング など • 基盤の運用・監視ツー ルの機能検証 • 自動化ツールの機能検 証 • 基盤の運用・トラブル シューティング など SDN/NFVゾーン DevOpsゾーン
- 14.
- 15. 今回構築したシステム① 15 サーバ#1 サーバ#2 サーバ#3サーバ#4 サーバ#5 サーバ#6 サーバ#7 物理サーバ × 7台 HP BladeSystem c3000 BL460c G7 CPU: Xeon E5540 2P/8C Memory: 32GB Disk: SSD 256GB or HDD 300GB
- 16. 今回構築したシステム② 16 サーバ#1 サーバ#2 サーバ#3サーバ#4 サーバ#5 サーバ#6 サーバ#7 Ubuntu 14.04 Ubuntu 14.04 Ubuntu 14.04 Ubuntu 14.04 Ubuntu 14.04 Ubuntu 14.04 Ubuntu 14.04 Ubuntu 14.04.1 LTS
- 17. 今回構築したシステム③ 17 サーバ#1 サーバ#2 サーバ#3サーバ#4 サーバ#5 サーバ#6 サーバ#7 Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu 今回は OpenStack-ansible Kilo版を使用し、環境を構築 OpenStack-Ansibleで作るOpenStack HA環境 http://enterprisecloud.jp/installguide-openstack-ansible/ http://www.slideshare.net/VirtualTech-JP/openstackansible openstack-ha-openstack-20163 コントローラ ノード コンピュート ノード
- 18. 参考）OpenStackの構成要素 サービス 役割 AWSで例えると Nova全体をコントロール EC2 Nova Compute 仮想マシンインスタンス管理 Keystone 認証系 IAM Neutron 仮想ネットワーク管理 Route 53 / VPC / ELB Glance ゲストOSイメージ管理 AMI Cinder ブロックストレージ管理 EBS Horizon Web管理画面 Management Console Swift オブジェクトストレージ S3 Ceilometer リソース利用量監視 CloudWatch Heat 自動化 CloudFormation 18 筆者調べ、AWSの例えについて適切なものがあれば教えてください
- 19.
- 20. 参考）実行するコマンド 20 controller$ sudo gitclone https://github.com/openstack/openstack- ansible /opt/openstack-ansible controller$ vi openstack_user_config.yml controller$ vi user_variables.yml controller$ vi user_secret.yml controller$ cd /opt/openstack-ansible/ controller$ sudo scripts/bootstrap-ansible.sh controller$ cd /opt/openstack-ansible/playbooks/ controller$ sudo openstack-ansible setup-hosts.yml –vvv controller$ sudo openstack-ansible haproxy-install.yml –vvv controller$ sudo openstack-ansible setup-infrastructure.yml –vvv controller$ sudo openstack-ansible setup-openstack.yml -vvv 1 2 3 4 5 6 7 8 9 10 11
- 21.
- 22. 参考）コントローラノードでの lxc-lsコマンド実行結果 22 root@controller:~# lxc-ls --fancy NAMESTATE IPV4 IPV6 AUTOSTART ---------------------------------------------------------------------------------------------------------------------------------------- controller-01_cinder_api_container-3157cd2c RUNNING 10.0.3.156, 172.29.236.56 - YES (onboot, openstack) controller-01_cinder_scheduler_container-b6a20022 RUNNING 10.0.3.85, 172.29.236.243 - YES (onboot, openstack) controller-01_galera_container-29d52973 RUNNING 10.0.3.157, 172.29.236.46 - YES (onboot, openstack) controller-01_galera_container-2ea457da RUNNING 10.0.3.190, 172.29.236.155 - YES (onboot, openstack) controller-01_galera_container-f8883adf RUNNING 10.0.3.113, 172.29.236.211 - YES (onboot, openstack) controller-01_glance_container-62ebe7a8 RUNNING 10.0.3.155, 172.29.236.55 - YES (onboot, openstack) controller-01_heat_apis_container-9507e331 RUNNING 10.0.3.47, 172.29.236.190 - YES (onboot, openstack) controller-01_heat_engine_container-ee16301a RUNNING 10.0.3.240, 172.29.236.90 - YES (onboot, openstack) controller-01_horizon_container-58bc8110 RUNNING 10.0.3.36, 172.29.236.83 - YES (onboot, openstack) controller-01_horizon_container-a5a061f5 RUNNING 10.0.3.98, 172.29.236.222 - YES (onboot, openstack) controller-01_keystone_container-00302b5e RUNNING 10.0.3.136, 172.29.236.9 - YES (onboot, openstack) controller-01_keystone_container-9aab73a6 RUNNING 10.0.3.173, 172.29.236.129 - YES (onboot, openstack) controller-01_memcached_container-44d75a70 RUNNING 10.0.3.175, 172.29.236.43 - YES (onboot, openstack) controller-01_neutron_agents_container-68879ee5 RUNNING 10.0.3.154, 172.29.240.152, 172.29.236.166 - YES (onboot, openstack) controller-01_neutron_server_container-0cf61dc6 RUNNING 10.0.3.167, 172.29.236.113 - YES (onboot, openstack) controller-01_nova_api_metadata_container-5175080c RUNNING 10.0.3.148, 172.29.236.91 - YES (onboot, openstack) controller-01_nova_api_os_compute_container-debaf1ee RUNNING 10.0.3.180, 172.29.236.220 - YES (onboot, openstack) controller-01_nova_cert_container-f08e46b0 RUNNING 10.0.3.222, 172.29.236.41 - YES (onboot, openstack) controller-01_nova_conductor_container-86281c5d RUNNING 10.0.3.82, 172.29.236.197 - YES (onboot, openstack) controller-01_nova_console_container-cf6d647d RUNNING 10.0.3.109, 172.29.236.196 - YES (onboot, openstack) controller-01_nova_scheduler_container-47255f60 RUNNING 10.0.3.133, 172.29.236.143 - YES (onboot, openstack) controller-01_rabbit_mq_container-4030544d RUNNING 10.0.3.72, 172.29.236.24 - YES (onboot, openstack) controller-01_rabbit_mq_container-9078f6fd RUNNING 10.0.3.181, 172.29.236.236 - YES (onboot, openstack) controller-01_rabbit_mq_container-edf993d7 RUNNING 10.0.3.184, 172.29.236.30 - YES (onboot, openstack) controller-01_repo_container-90aef04e RUNNING 10.0.3.95, 172.29.236.217 - YES (onboot, openstack) controller-01_repo_container-ee57a601 RUNNING 10.0.3.123, 172.29.236.10 - YES (onboot, openstack) controller-01_utility_container-e90a7d93 RUNNING 10.0.3.135, 172.29.236.163 - YES (onboot, openstack) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
- 23. 今回構築したシステム④ 23 サーバ#1 サーバ#2 サーバ#3サーバ#4 サーバ#5 サーバ#6 サーバ#7 Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu 監視に Zabbix 3.0 + Hatohol 16.04 ログ管理・解析に Elasticsearch + Fluentd + Kibana 構築手順については今後公開予定 コントローラ ノード コンピュート ノード 監視 ログ
- 24. 参考）監視の処理フロー 24 サーバ#1 サーバ#2 サーバ#3サーバ#4 サーバ#5 サーバ#6 サーバ#7 Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu コントローラ ノード コンピュート ノード 監視 ログ Zabbixエージェント Zabbix 3.0 Hatohol 16.04 Redmine 3.2.0 SlackZabbix では、プロセス監視やポート監視の他に API死活監視やMQのQueue Depthなどを追加 Hatoholは、複数のZabbix監視サーバを束ねる 運用ダッシュボード的な使い方を検討中
- 25. 参考）ログ管理の処理フロー 25 サーバ#1 サーバ#2 サーバ#3サーバ#4 サーバ#5 サーバ#6 サーバ#7 Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu コントローラ ノード コンピュート ノード 監視 ログ fluentd Elastic Search Kibana
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32. OpenStack 監視&ログのデータ処理フロー 32 仮想マシン 仮想マシン サーバ サーバ L2/L3 今回構築した環境 ログ管理・解析ツール （ElasticSearch,Kibana） 監視・モニタ リングツール （Zabbix） インシデント 管理ツール （Redmine） ナレッジ ベース （Redmine） 運用ダッシュ ボードツール （Hatohol） Zabbix エ ー ジ ェ ン ト Ｆ ｌ ｕ ｅ ｎ ｔ ｄ ① 120万件/日 ② ダッシュボード に伝えるべきエラー は何か？
- 33. 33NTTドコモ様 導入事例 OpenStackSummit 2015 Tokyo 講演「After One year of OpenStack Cloud Operation (NTT DOCOMO) http://www.slideshare.net/VirtualTech-JP/ntt-openstack-summit-2015-tokyo-after-one-year-of-openstack-cloud-operation-ntt-docomo
- 34. OpenStack 監視&ログにまつわる ユーザー処理フロー 34 仮想マシン 仮想マシン サーバ サーバ L2/L3 今回構築した環境 ログ管理・解析ツール （ElasticSearch,Kibana） 監視・モニタ リングツール （Zabbix） インシデント 管理ツール （Redmine） ナレッジ ベース （Redmine） 運用ダッシュ ボードツール （Hatohol） Zabbix エ ー ジ ェ ン ト Ｆ ｌ ｕ ｅ ｎ ｔ ｄ ③ フィードバック する仕組みを いかに作るか
- 35. 残作業 監視＆ログのデータ処理フロー • 疑似障害を発生させ、監視アイテムやfluentdの対象ログ を確認 • Chaosmonkyを稼働させ、常に障害を発生させる •ログ解析ツールのユースケースの検討 監視＆ログにまつわるユーザー処理フロー • ユーザー処理フローの定義 • 運用ダッシュボードツールのユースケースの検討 • Black list / White list の追加 35
- 36. 今後のアクションについて • 管理対象の追加 – Swiftや Ceph などのオブジェクトストレージ – Ceilometer などのリソース利用量監視 • 規模の拡大 – 構成管理システムと連動したプロビジョニング • 監視＆ログのデータ処理フローの高度化 – Deep Learning を活用したログ管理 36
- 37.
- 38.
- 39.