PowerPoint プレゼンテーション

(1)

goo基盤を支えるOpenStack

NTTレゾナント株式会社

ビジネスプラットフォーム事業部サービス基盤部門 2015/12/16

(2)

自己紹介

2 橋本智哉 通山和裕 2010年～2014年6月 NTTコミュニケーションズ OCNフレッツ系NW開発 2014年7月～ (現職) NTTレゾナントサーバ基盤の設計・構築・運用 2001年～2012年 NTTレゾナント gooブログ・教えてgooなど主要サービスの設計・構築・運用 2012年～ (現職) NTTレゾナントサーバ基盤の設計・構築・運用統括 渡邉理恵 2012年～2015年3月インターネットマルチフィード株式会社技術部 2015年4月～ (現職) NTTレゾナントサーバ基盤の設計・構築・運用

(3)

1. NTTレゾナントの紹介

2. OpenStackとは

3. NTTレゾナントのOpenStack

4. PuppetとOpenStackの連携

5. OpenStackとVMの監視

6. 現在の取り組みと将来計画

3 Agenda

(4)

1. NTTレゾナントの紹介

(5)

1. NTTレゾナントの紹介

5

Regional Communications Business Long Distance and International Communications Business

Mobile Communications Business Date Communications Business

$112

billion in total revenue 240,000 employees worldwide

#1

in Data Center floor space

#2

in Global IP Backbone Source: TeleGeography

All facts and figures accurate as of March 2014

(6)

1. NTTレゾナントの紹介

6 個人のお客様 法人のお客様 ポータルサイト等スマホアプリ

goo milk feeder goo防災アプリ

スマホアプリ試験環境災害時安否情報まとめて検索ヘルスケア

(7)

7

Dictionaries ZIP codes Laboratory Bodycloud

Housing and real estate Search Baby-care Movies

Maps Navigation Horoscopes Rankings Car and bike

News Weather Healthcare Smartphone applications Blogs

Job search Love and marriage

Online store Travel 60サービス以上を提供 Webポータルサイト goo http://www.goo.ne.jp/ 18周年！

1. NTTレゾナントの紹介

(8)

ユニークユーザ数：1.7億UU/月

ページビュー数：10億PV/月

8 Yahoo! Google 楽天 _doorLive MSN @Nifty Excite

の規模感

業界的には3番手ポジション

2015.02 NetRatings 月間UU

1. NTTレゾナントの紹介

(9)

2. OpenStackとは

(10)

2. OpenStackとは

10

Googleトレンドより

• いずれかがOpenStackを示すグラフ

(11)

2. OpenStackとは

• オープンソースで開発されているクラウド環境構築のソフトウェア群 • 要するにAWSのようなIaaS/PaaSを自前で作れる • 機能単位に分割されており、必要な機能だけ導入可能 • 各プロセスはAPIで連携する設計 11 OpenStackとは ダッシュボード Horizon Neutron Nova Glance Cinder Swift ネットワークハイパーバイザ /VM制御イメージ管理ブロックストレージオブジェクトストレージ

Virtual Router and LAN Virtual Load Balancer Virtual server VM Template Image snapshot Virtual volume RESTful file store Replication VM VM VM APP OS APP OS APP OS Keystone 認証

(12)

OpenStack操作画面 – ログイン

(13)

2. OpenStackとは

(14)

-OpenStackでVMができるまで

2. OpenStackとは

ダッシュボード Horizon Neutron Nova ネットワークハイパーバイザ /VM制御 Neutron Nova 物理サーバ eth0 eth1 bond0 Keystone 認証指示指示 tap tap bond0.101 bond0.102 VLAN101 VLAN102 VM VM eth0 eth0 テナントA(VLAN101) テナントB(VLAN102) 指示 ※この例ではGUI経由 API経由内部処理 (AMQP) VLAN101～200 trunk linux-bridge linux-bridge

(15)

2. OpenStackとは

• OpenStackコミュニティ最大の会議 • 半年に一度、5000人～の規模で開催される – Main Conference：一般発表 – Design Summit：開発者の会議 – Ops Meetup：運用者の会議 • 2015年10月は東京開催 – 次回はAustin – 次々回はBarcelona OpenStack Summit https://www.flickr.com/groups/1574695@N22/pool/

(16)

• OpenStackを活用しているユーザの表彰

– CERN、Comcastに続き、NTTグループが受賞

16 http://blogs.itmedia.co.jp/business20/2015/10/ntt_openstack_superuser_award.html

OpenStack Superuser Award

(17)

• 2010年から開発がスタート • 大規模コミュニティによる開発 – 30,000人～ • 現在は半年ごとにメジャーバージョンアップ – 弊社はIcehouseを採用 – 2つ前のバージョンまでサポート – それ以前はEOL 17 Austin 2010/10 Bexar 2011/2 Cactus 2011/4 Diablo 2011/9 Essex 2012/4 Folsom 2012/9 Gruzzly 2013/4 Havana 2013/10

Icehouse

2014/4 Kilo 2015/4 Juno 2014/10 Liberty 2015/10 OpenStackリリースサイクル Mitaka 2016/4

2. OpenStackとは

New!

(18)

3. NTTレゾナントのOpenStack

(19)

3. NTTレゾナントのOpenStack

• 2014年10月から運用中のプライベートクラウド(Openstack利用) • 80種類以上のサービスを収容 • 月間 10億PV を支える環境 – 400台の物理サーバ & 4800物理CPUコア – 1800台以上の仮想サーバ • 監視設定・障害管理をできるだけ自動化 – 監視対象サーバをZabbixが検出、ルールに基づき自動監視設定 – Zabbixが障害を検知するとRedmineに自動的にチケット起票 19 NTTレゾナントのメインデータセンタ Launch

(20)

3. NTTレゾナントのOpenStack

• 限られた時間で新データセンタに移転する必要性 – 旧データセンタの契約期限が10ヶ月後に迫っていた – 期限までに移転できないと大変なことになる • サービスリリースまでの時間短縮がしたい – VMの作成・管理を自動化することでスピードアップを狙いたい – 社内基盤はパブリッククラウドと比較される時代 • サービス提供までのすべてのワークフローをサポートしなければならない – Webサービス提供に必要な機能はOpenStackだけではまかなえない – VM作成後のミドルウェアの導入・監視設定方法なども提供できる環境をつくる 20 OpenStackを採用するにあたっての背景・要件

(21)

3. NTTレゾナントのOpenStack

• 新データセンタへの移転に向けてOpenStack(Icehouse)を導入 – 2014/３検討開始 – 2014/10 OpenStack稼働開始 → 商用利用開始 – 2014/10～2015/01 (4ヶ月) 70サービス 1300VMを移転 21 OpenStack導入スケジュール 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2014 2015 旧DCからのサービス移転作業 ★OpenStack商用利用開始 ★移転完了 OpenStack 導入: 設計 / デプロイ要件定義 約6ヶ月 ★旧DCクローズ 約4ヶ月

(22)

ソフトウェアイノベーションセンタ

3. NTTレゾナントのOpenStack

22 体制サービス部隊基盤部隊サービス担当サービス担当 NTTレゾナントサービス担当サービス担当サービス担当サービス担当サービス担当サービス担当～80サービス共通基盤提供運用委託先複数社 … 連携～15人ほど 300人～ … NTT 研究所協力

(23)

3. NTTレゾナントのOpenStack

23 利用コンポーネント (Icehouse Release) ダッシュボード Horizon Neutron Nova Glance Cinder Swift Keystone ネットワークハイパーバイザ /VM制御イメージ管理ブロックストレージオブジェクトストレージ認証

Virtual Router and LAN Virtual Load Balancer Virtual server VM Template Image snapshot Virtual volume RESTful file store Replication 弊社利用コンポーネント VM VM VM APP OS APP OS APP OS designed by Freepik Trove Heat オーケストレーションデータベースサービス Ceilometer 課金 L3以上はNW機器にお任せ VM/HVのNW制御のみ Cinder無し Ephemeral Diskのみ

(24)

3. NTTレゾナントのOpenStack

• ディストリビューション

– RDO (Icehouse) & CentOS 6 • OpenStackの構築自動化

– Puppet

• RDO同梱のPuppetマニフェストを参考に書き起こし – PXE boot & kickstart

• puppetが利用可能になるところまで設定 • コンピュートノード構築 40台/日～ 24 デプロイ方法 class openstack_keystone { package { 'openstack-keystone': ensure => latest, require => [ Class['openstack_yum'], File['/usr/local/bin/deploy_utils/check_keystone_tables.sh']]; } : ※マニフェストの一部 • ユーザ作成・設定ファイルの配布など環境構築をコード化するツール • 誰が、いつ実行しても完全に同じサーバが構築できる（べき等性） Puppetとは

(25)

3. NTTレゾナントのOpenStack

• 運用ルールを強制するためにOpenStackのコードを一部改変 – Web GUI (Horizon) のみ改変

– 利用者は必ずGUIからOpenStackを利用 • APIは利用させない • 改変箇所 –VM命名規則の強制 –セキュリティグループの利用禁止 –他、40箇所程度 – 他のコンポーネントはバグフィックスを除いて未改造 • 今後のメンテナンスを考えると upstream実装に近い方が良い 25 改変後のVM作成画面

(26)

3. NTTレゾナントのOpenStack

• Provider network + VLAN

– NeutronでL3制御は実施しない

(Router, NAT, Load Balancer, Firewall) • ML2 plugin + Linuxbridge agentを利用

– LinuxbridgeはKVM時代から利用 • NWサービス提供モデル

– 基盤部隊側で、各テナントごとに1つのプライベートネットワークを設定 – サービス担当者はネットワークの作成・削除はできない

• 公式ドキュメントの下記が近い

– “Scenario: Provider networks with Linux bridge” in the “OpenStack Networking Guide” [1] 26 [1] http://docs.openstack.org/networking-guide/scenario_provider_lb.html 弊社利用 N eu tron L4-7: Load Balancer, VPN L3: Router, NAT L2: Network, Port Neutron(ネットワーク機能)の割り切り導入

(27)

OpenStackでVMができるまで(再掲)

3. NTTレゾナントのOpenStack

ダッシュボード Horizon Neutron Nova ネットワークハイパーバイザ /VM制御 Neutron Nova 物理サーバ eth0 eth1 bond0 Keystone 認証指示指示 tap tap bond0.101 bond0.102 VLAN101 VLAN102 VM VM eth0 eth0 テナントA(VLAN101) テナントB(VLAN102) 指示 ※この例ではGUI経由 API経由内部処理 (AMQP) VLAN101～200 trunk linux-bridge linux-bridge 1サービス=1テナント=1VLAN 基盤部隊で固定的に設定ネットワーク機能は L2SW, L3SW, LB等のアプライアンス製品で実現 Neutronは • VMへのIPアドレス割当 • Linux-bridge等の設定のみ実施

(28)

4. PuppetとOpenStackの連携

(29)

4. PuppetとOpenStackの連携

29 DC移転におけるVM構築・設定の課題 • サービス移転に使える期間は4ヶ月のみ – サービス担当者がVM構築・設定に使える時間は限られている – 1,300台のVMがOpenStack上に移転する必要があった – 可能な限り、作業は自動化しなければならない • OpenStackはわずか数分でVMを作成できる – だから問題ない？ ⇒×VM作成後の設定作業が必要 • どうやってVMを高速で設定するか？ – 既存DCで利用していたpuppet manifestの再利用が鍵 – OpenStack導入以前から、サービスを提供するサーバ群はpuppet manifestで管理していた

⇒PuppetとOpenStackを連携するしくみを自作して解決

(30)

OpenStack

4. PuppetとOpenStackの連携

30 PuppetとOpenStackの連携 • 弊社のpuppet環境の設計 – 各テナントに1台のpuppet master • Linuxアカウント • ミドルウェア • 設定ファイル他 – 単一のpuppet manifestリポジトリ • Puppetを利用するために必要なもの – DNSで名前解決が可能であること – LDAPにpuppet用ホストグループが定義されていること – ホストグループに対応したPuppet manifestが定義されていること Tenant: A Tenant：A User VM-A VM-B SVN Puppet Master DNS LDAP 必要

(31)

OpenStack

4. PuppetとOpenStackの連携

31 • 連携ツール – 新規VMを発見するため、 Nova APIを定期的にポーリング – 新規VMがあれば、DNS＆LDAPに登録 – Puppet manifestに新規VM用manifestを追加してsvn commit – 上記を5分間隔で実行 • OpenStackでVMを作成すると、自動的にpuppetで構成管理が可能な状態になっている ⇒既存DCからmanifestを移植すれば、同等構成を容易に再現できる Tenant: A Tenant：A User VM-A VM-B SVN 連携ツール NovaAPI をポーリング DNS LDAP 新規VM用に Manifest追加新規VMを登録 Puppet Master PuppetとOpenStackの連携

(32)

OpenStackとPuppetの連携まとめ

4. PuppetとOpenStackの連携

32 • ワークフローの効率化＆劇的なリードタイム短縮 • 1ヶ月で1000VMが構築された – 新しいVMを最速30分でサービスに組み込めるようになった • OpenStack導入前はVM作成が手作業だったので 3～5営業日程度かかっていた – VM管理に関わるオペレータの作業 2人分をまるっと低減 • サービス提供環境を構築する共通手段を全社に提供 – サービス担当エンジニアは環境について考える必要なし – ビジネスに集中できる

(33)

5. OpenStackとVMの監視

(34)

5. OpenStackとVMの監視

• 2種類の監視 1. クラウド基盤の監視 • NW、物理サーバ、OpenStack自体 2. Webサービスの監視 • 基盤部隊から全社に対し、標準的な監視手法を提供 • 利用してツールとトピック – Zabbix • 半自動VM監視 – Redmine と Wiki • チケット管理システム • 1障害1チケットを自動起票 – オペレーションセンタ • 24時間365日の監視＆電話連絡 • 障害時、簡単な一次対応を実施 34 運用監視の概要 オペレーションセンタサービス担当チーム自動チケット起票基盤部隊 24時間監視トラブルシュート・プロビジョニング深刻な障害発生時は電話連絡 designed by Freepik

(35)

• 深刻度（上から順） – API監視

• keystone-api, nova-api, neutron-api, horizon GUI, glance-api, swift-proxy • API停止＝何かが全断＝きわめて深刻

– プロセス死活監視

• nova-*, swift-*, keystone-*, rabbitmq-server, mysqld(MariaDB) 他 – プロセスパフォーマンス監視

• ミドルウェアに依存する

• i.e.) SQLコネクション数、MariaDB Galera Clusterの同期状態などなど – ログ監視 • OpenStack監視における難敵 • 運用開始時、ERROR以上のログをすべて“障害”と扱うことに決定 – 最初はOpenStackの知見がない＝全てを疑う – 出ても障害にならないとわかったログを地道にフィルタリング • DEBUGログもすべて出力させる 35 1. クラウド基盤(OpenStack)の監視

5. OpenStackとVMの監視

(36)

5. OpenStackとVMの監視

• Openstackのログ

– 運用にはDEBUGログが重要 but DEBUGログは…

– 例）Openstack インスタンスを1個起動した（だけ）の正常系ログ

36

223行,119698文字

※DEBUGを除外すると24行しかない ログ監視という鬼門

(37)

5. OpenStackとVMの監視

• 従来 – 監視の内容 ⇒ 全社共通ルール化済み • Webサービスの標準的な監視項目を網羅（Apache, MySQL…) – 共通基盤として監視システムを提供 • 依頼を受けて基盤部隊が手動で監視設定 • 障害検知したら、手動で障害チケット起票＆電話連絡 • Openstackで変わること – サービス側で好きなときにVMを作成可能＝構成変更が容易になる ⇒ 監視設定依頼も頻繁に来る？ – 監視設定がボトルネックになってリリースが遅れてはいけない – データセンタ移転：監視設定に割ける時間2ヶ月 / 対象VM 1000台 37

自動化しないと無理 (

|||

ﾟДﾟ)

2. Webサービスの監視

(38)

運用監視の半自動化サーバ _Zabbix Redmine 深刻度Lv 連絡先ML 1a 社内PC＆ 携帯電話宛て ML 1b 2 社内PC宛て ML 3 4 オペレータサービス担当者サービス緊急連絡先一次対応、復旧作業全社ルールに従い監視項目・深刻度を設定 監視と障害対応の流れ(従来) Apache MySQL … Apache死活障害チケット Apache性能障害チケット MySQL性能障害チケットサービス担当者 監視設定 依頼 監視設定 Apache死活監視監視 Apache性能監視 MySQL性能監視 障害検知 パトライト Zabbix画面！オペレータ 障害チケット起票 監視設定障害検知チケット起票エスカレーション連絡復旧作業障害内容・深刻度に応じてチケットを手動起票深刻度Lv1aの場合、電話連絡 ① ② ③ ④ ⑤ Redmineから 自動メール送信 38

5. OpenStackとVMの監視

(39)

運用監視の半自動化サーバ _Zabbix Redmine 深刻度Lv 連絡先ML 1a 社内PC＆ 携帯電話宛て ML 1b 2 社内PC宛て ML 3 4 オペレータサービス担当者サービス緊急連絡先一次対応、復旧作業全社ルールに従い監視項目・深刻度を設定 監視と障害対応の流れ(従来) Apache MySQL … Apache死活障害チケット Apache性能障害チケット MySQL性能障害チケットサービス担当者 監視設定 依頼 監視設定 Apache死活監視監視 Apache性能監視 MySQL性能監視 障害検知 パトライト Zabbix画面！オペレータ 障害チケット起票 監視設定障害検知チケット起票エスカレーション連絡復旧作業障害内容・深刻度に応じてチケットを手動起票深刻度Lv1aの場合、電話連絡 ① ② ③ ④ ⑤ Redmineから 自動メール送信

手動＝しんどい

39

5. OpenStackとVMの監視

(40)

運用監視の半自動化サーバ Zabbix Redmine 深刻度Lv 連絡先ML 1a 社内PC＆ 携帯電話宛て ML 1b 2 社内PC宛て ML 3 4 サービス担当者サービス緊急連絡先一次対応、復旧作業 監視と障害対応の流れ(半自動化後) Apache MySQL … Apache死活障害チケット Apache性能障害チケット MySQL性能監視チケット Apache死活監視監視 Apache性能監視 MySQL性能監視！オペレータ監視設定障害検知チケット起票エスカレーション連絡復旧作業深刻度Lv1aの場合、電話連絡 ⑤ Redmineから 自動メール送信 監視定義ファイル apache_prod mysql_prod alert_on サービス担当者 監視定義 ファイル作成 ① 障害検知 自動起票 ③④ 自動監視 設定 ② 監視設定ルーチンポーリング監視定義と監視設定の対応 apache_prod = Apache 商用レベル監視 apache_dev = Apache 非商用レベル監視 alert_on = 障害通知ON … 40

5. OpenStackとVMの監視

(41)

Openstack 新規VM 半自動設定のからくり Zabbixが監視対象VMを発見し、監視定義ファイルを読みとり監視設定サーバ Zabbix サーバサーバサーバサーバ Redmine (2) Zabbix Agent経由でホスト内の監視定義ファイルの内容を取得 (1)Zabbixサーバが Openstack VMの利用するIPセグメントをポーリングし、新規Zabbix Agentを検知 ⇒監視対象ホストとして登録 (3)監視定義ファイルに対応した監視設定テンプレートをホストに適用 ※テンプレートは事前に定義 (4)障害を検知したら、 Zabbixが外部スクリプトを起動 ⇒API経由で障害チケットを自動起票 AP I 172.16.X.0/24 監視定義ファイル apache_prod mysql_prod base_prod alert_on Za b b ix A g e n t （例） apache_prod = Apache 商用レベル監視 apache_dev = Apache 非商用レベル監視 base_prod = Linux OS 商用レベル監視 alert_on = 障害通知ON alert_off = 障害通知OFF（メンテ中など） … _{スクリプト} ポーリング障害チケット起票 New! 41

5. OpenStackとVMの監視

(42)

1. クラウド基盤(OpenStack)の監視 – API、プロセス死活監視などなど見るところは多い – 慣れないうちはDEBUGログの保存を推奨（しかし量が…） 2. Webサービスの監視 – VMの監視設定を半自動化 • 基本的な監視設定は手作業なしで可能に – クラウド向けに監視基盤を提供するなら、監視設定自動化は必須 • Zabbixでの自動化にはそれなりに知見が必要オートディスカバリ、LLD、userparameter、自作スクリプト … 42 運用監視のまとめ 導入を決める前に現在のワークフローを精査して、 OpenStackで変わるところ・変えざるを得ないところを見極めましょうあとで気付くと大変なことに

5. OpenStackとVMの監視

(43)

6. 現在の取り組みと将来計画

(44)

44

6. 現在の取り組みと将来計画

• 目的 – VMのサイジングを見直し収容効率を上げる – ハイパーバイザ用物理サーバのOS update(CentOS6→7)を行なう • 背景 – 新しくVMを作成するための割当て可能なディスクリソースが枯渇 – RDO(Juno以降)がCentOS6に非対応のため、 CentOS6のままではOpenStackのアップデートができない割当済率(%) VMに割当済のディスク容量の割合月 80％程度割当済みになった時点で、ディスク割当量が大きいVMを作れなくなった（分割損） 現在の取り組み

(45)

6. 現在の取り組みと将来計画

45 – 既存VMの割当済ディスクの利用率を調査すると、 10～20％しかディスクを利用していないVMが多いことが判明 – 既存VMから割当済ディスクを返してもらうことで、新規VM作成用のディスクリソースの確保を行なうディスク利用率ごとのVM数の積上げグラフ VM数ディスク利用率 VMフレーバ 既存VMのディスク利用状況を調査

(46)

VM VM

6. 現在の取り組みと将来計画

46 ④rsync ①ディスクの小さい VMを用意する既存VM ②ホスト名とIPを付け替える物理サーバ diskイメージ diskイメージ ③guestmount 物理サーバ – OpenStackの標準機能では既存VMのディスクサイズを小さくできないため、ツールを開発 – ディスクサイズの小さいVMを作成してデータをrsyncで同期する方法で、あたかもディスクが小さくなったかのように見せる Hostname: test IPaddr: 10.1.1.1 Hostname: test_org IPaddr: 10.1.1.2 Hostname: test_new Ipaddr: 10.1.1.3 Hostname: test IPaddr: 10.1.1.1 ディスク縮小ツールの開発 ⑤既存VMを削除する

(47)

6. 現在の取り組みと将来計画

47 – VMをすべて移動させて、空になったハイパーバイザのOSをアップデートする » ディスク縮小ツールを使ってハイパーバイザ上にあるVMを移行する » ハイパーバイザのOSをアップデートする物理サーバ VM VM VM VM VM VM 物理サーバ VM VM VM VM VM VM

CentOS6 CentOS7 _CentOS7

同時にcompute nodeのOSアップデートを実施

①VMを移動させる ②既存VMを削除する

③ハイパーバイザの OSをアップデートする

(48)

6. 現在の取り組みと将来計画

48 – 作成済みVMのディスクはOpenStackの機能では小さくすることはできない » 一度VMに割り当てるとリソースの回収は難しいのでサイジングは慎重に – CPU・メモリ・ディスクのいずれかが逼迫すると他が余っていてもVM作成ができなくなる（今回はディスク） » Cinderを使えばCPU＆メモリとディスクのリソース割当を別個に検討可能 – 割当てには分割損が発生する » 物理リソースを100%使い切れるわけではないことに注意 現在の取り組みまとめ

(49)

6. 現在の取り組みと将来計画

• OpenStackのアップグレード

– Load Balancer as a Service (LBaaS) を導入したい • 現状：ロードバランサ(アプライアンス)を手動設定 • LBaaS API v1 は実装がよろしくない • LBaaS API v2対応のベンダ製ドライバに期待 – アップグレード手順の確立 • 自社用パッチの適用と試験が必要 • パッチ適用・試験を自動化しないと頻繁なアップデートは辛い – Mitakaリリースを目指す • なんといってもNTT持ち株研究所は三鷹駅が最寄り 49 将来計画 住所は三鷹市ではなく武蔵野市