openstack本番環境の作り方 - interop 2016
Post on 15-Apr-2017
1.709 Views
Preview:
TRANSCRIPT
本邦初公開！OpenStack 本番環境の作り方
日本仮想化技術株式会社VitrualTech.jp
たまおき のぶゆき
自己紹介
• 日本仮想化技術の中の人• オープンスタック関連の
ビジネス創出中– EnterpriseCloud.jp の管理者– 『 OpenStack 最新情報セミ
ナー』の企画・運営
2
日本仮想化技術株式会社• 社名：日本仮想化技術株式会社
– 英語名： VirtualTech Japan Inc.– 略称：日本仮想化技術／ VTJ
• 設立： 2006 年 12 月• 資本金： 3,000 万円• 売上高： 8,700 万円（ 2015 年 7 月期）• 本社：東京都渋谷区渋谷 1-8-1• 取締役：宮原 徹（代表取締役社長兼 CEO ）• 伊藤 宏通（取締役 CTO ）• スタッフ： 9 名（うち、 8 名が仮想化技術専門エンジニアです）• URL ： http://VirtualTech.jp/• 仮想化技術に関する研究および開発
– 仮想化技術に関する各種調査– 仮想化技術に関連したソフトウェアの開発– 仮想化技術を導入したシステムの構築– OpenStack の導入支援・新規機能開発
ベンダーニュートラルな独立系仮想化技術のエキスパート集団
3
OpenStack への取り組み• 通信事業社での OpenStack 基盤の検討支援および構築・運
用– NTT ドコモ (2011 年から技術評価を支援、商用利用に向けた検
討・構築・運用を実施 )– NTT 西日本 ( 商用利用に向けた評価・検討の支援、プロジェクト
マネージメント支援 )– 大手通信事業社 A 社 ( ベアメタルサービスの検討支援 )– 大手通信事業社 B 社 ( ベアメタルサービスの技術評価 )
• ベアメタル OpenStack の開発– 仮想環境と物理環境を OpenStack で一括管理– 単一のイメージで仮想マシンと物理マシンの双方を起動可能– 2013 年 4 月リリースの Grizzly で本体にマージ
4
5
OpenStack Summit での発表実績①
2014/11 OpenStack Summit 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.
6
OpenStack Summit での発表実績②
2015/10 OpenStack Summit Tokyo
We (NTT West, Canonical and VTJ) spoke ”Requirements for Providing Telecom Services on OpenStack-based Infrastructure”.
7
EnterpriseCloud.jp• OpenStack で始める
エンタープライズクラウドの情報サイト
• OpenStack 導入手順書のダウンロード
• 各種プレゼン資料• その他ブログ記事
http://EnterpriseCloud.jp
今日のポイント
8
OpenStack 構築手順書公開中
http://EnterpriseCloud.jp/installguide-openstack/
今日のポイント
Mitaka 版 出版準備中
9
OPENSTACK共同検証ラボ
10
OpenStack 共同検証ラボ
11
ブロードバンドタワー様と立ち上げ。現在４社でコラボ中。
OpenStack 共同検証ラボとは• ブロードバンドタワー様のデータセンター施
設を利用し、検証環境を用意いたします。• 『 OpenStack 共同検証ラボ』に協賛いただく
会社を募り、協賛企業の皆様と共に検証を行います。– 協賛企業の皆様は検証テーマを提案できます。– 本ラボが提案した検証テーマに参画いただくこと
も可能です。• 『 OpenStack 共同検証ラボ』で得たノウハウや知見をドキュメント化し、ドキュメントを一般公開いたします。12
OpenStack 共同検証ラボ 概要• 当初は 2つのゾーンを用意• ゾーンは 3ヶ月 ~6ヶ月の周期で環境構築・調査・報告作成を繰り返していく。
13
• SDN/NFV製品の機能検証
• パフォーマンス検証• 可用性検証• SDN/NFV製品の運
用・トラブルシューティング
など
• 基盤の運用・監視ツールの機能検証
• 自動化ツールの機能検証
• 基盤の運用・トラブルシューティング
など
SDN/NFVゾーン DevOpsゾーン
今回構築した環境
14
今回構築したシステム①
15
サーバ #1 サーバ #2 サーバ #3 サーバ #4 サーバ #5 サーバ #6 サーバ #7
物理サーバ × 7台
HP BladeSystem c3000BL460c G7CPU: Xeon E5540 2P/8CMemory: 32GBDisk: SSD 256GB or HDD 300GB
今回構築したシステム②
16
サーバ #1 サーバ #2 サーバ #3 サーバ #4 サーバ #5 サーバ #6 サーバ #7
Ubuntu14.04
Ubuntu14.04
Ubuntu14.04
Ubuntu14.04
Ubuntu14.04
Ubuntu14.04
Ubuntu14.04
Ubuntu 14.04.1 LTS
今回構築したシステム③
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/openstackansibleopenstack-ha-openstack-20163
コントローラノード
コンピュートノード
18
参考） OpenStack の構成要素サービス 役割 AWSで例えるとNova 全体をコントロール
EC2Nova Compute 仮想マシンインスタンス管理Keystone 認証系 IAM
Neutron 仮想ネットワーク管理 Route 53 / VPC / ELB
Glance ゲスト OS イメージ管理 AMI
Cinder ブロックストレージ管理 EBS
Horizon Web 管理画面 Management Console
Swift オブジェクトストレージ S3
Ceilometer リソース利用量監視 CloudWatch
Heat 自動化 CloudFormation
筆者調べ、 AWS の例えについて適切なものがあれば教えてください
参考）ネットワーク構成図
19
コントローラノード コンピュートノード
参考）実行するコマンド
20
controller$ sudo git clone https://github.com/openstack/openstack-ansible /opt/openstack-ansible
controller$ vi openstack_user_config.ymlcontroller$ vi user_variables.ymlcontroller$ vi user_secret.yml
controller$ cd /opt/openstack-ansible/controller$ sudo scripts/bootstrap-ansible.shcontroller$ cd /opt/openstack-ansible/playbooks/controller$ sudo openstack-ansible setup-hosts.yml –vvvcontroller$ sudo openstack-ansible haproxy-install.yml –vvvcontroller$ sudo openstack-ansible setup-infrastructure.yml –vvvcontroller$ sudo openstack-ansible setup-openstack.yml -vvv
1
234
56789
1011
OpenStack-Ansible で作る OpenStack HA 環境 手順書解説http://www.slideshare.net/VirtualTech-JP/openstackansibleopenstack-ha-openstack-20163
参考）コントローラノードとコンピュートノードのコンポーネ
ント構成
参考）コントローラノードでの
lxc-ls コマンド実行結果
22
root@controller:~# lxc-ls --fancyNAME STATE 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)
123456789
1011121314151617
181920
21222324252627282930
今回構築したシステム④
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
サーバ #1 サーバ #2 サーバ #3 サーバ #4 サーバ #5 サーバ #6 サーバ #7
Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu
コントローラノード
コンピュートノード 監視 ログ
Zabbix エージェントZabbix
3.0
Hatohol 16.04
Redmine3.2.0
SlackZabbix では、プロセス監視やポート監視の他にAPI死活監視やMQ の Queue Depth などを追加Hatohol は、複数の Zabbix監視サーバを束ねる運用ダッシュボード的な使い方を検討中
参考）ログ管理の処理フロー
25
サーバ #1 サーバ #2 サーバ #3 サーバ #4 サーバ #5 サーバ #6 サーバ #7
Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu
コントローラノード
コンピュートノード 監視 ログ
fluentdElastic Search
Kibana
OpenStack のポータル画面
26
ネットワークのトポロジー図
27
Hatohol のダッシュボード画面
28
イベント管理画面
29
Kibana
30
環境を構築して気づいたこと
31
OpenStack
監視 & ログのデータ処理フロー
32
仮想マシン 仮想マシン
サーバ サーバ
L2/L3
今回構築した環境
ログ管理・解析ツール（ ElasticSearch, Kibana ）
監視・モニタリングツール（ Zabbix ） インシデント
管理ツール（ Redmine ）
ナレッジベース
（ Redmine ）
運用ダッシュボードツール（ Hatohol ）
Zabbixエ
ージ
ェン
ト
Ｆｌｕｅｎｔｄ
① 120 万件 / 日
② ダッシュボードに伝えるべきエラーは何か？
33NTT ドコモ様 導入事例 OpenStack Summit 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
OpenStack
監視 & ログにまつわるユーザー処理フロー
34
仮想マシン 仮想マシン
サーバ サーバ
L2/L3
今回構築した環境
ログ管理・解析ツール（ ElasticSearch, Kibana ）
監視・モニタリングツール（ Zabbix ） インシデント
管理ツール（ Redmine ）
ナレッジベース
（ Redmine ）
運用ダッシュボードツール（ Hatohol ）
Zabbixエ
ージ
ェン
ト
Ｆｌｕｅｎｔｄ
③ フィードバックする仕組みをいかに作るか
残作業監視＆ログのデータ処理フロー• 疑似障害を発生させ、監視アイテムや fluentd の対象
ログを確認• Chaosmonky を稼働させ、常に障害を発生させる• ログ解析ツールのユースケースの検討監視＆ログにまつわるユーザー処理フロー• ユーザー処理フローの定義• 運用ダッシュボードツールのユースケースの検討• Black list / White list の追加
35
今後のアクションについて• 管理対象の追加
– Swift や Ceph などのオブジェクトストレージ– Ceilometer などのリソース利用量監視
• 規模の拡大– 構成管理システムと連動したプロビジョニング
• 監視＆ログのデータ処理フローの高度化– Deep Learning を活用したログ管理
36
まとめ
37
38
EnterpriseCloud.jp にて情報発信します
http://EnterpriseCloud.jp
今日のポイント
仲間募集ブロードバンドタワー (BBT) 様と『 OpenStack 共同検証ラボ』を立ち上げました。 OpenStackや SDN/NFV の評価検証から DevOps的運用管理についての知見蓄積までを行います。
参加費用は無料で、本ラボでのアクティビティは基本パブリックにしていきます。今回構築した環境も本ラボの取り組みの一つで、構築手順やノウハウを文書化して公開いたします。
活動に興味のある方は「たまおき」までお声がけいただけますでしょうか。
39
top related